Bug#961481: ceph: Protocol incompatibility between armhf and amd64
Hi Bernd On 2020-05-27 21:22, Bernd Zeimetz wrote: sorry for not replying inline, but I thought I'd just share my general opinion on this. The biggest issue in maintaining ceph is to make it build on 32 bit architectures. This seems not to be supported at all by upstream anymore. First of all, I don't know what your goal is to support 32 bit. I do have a goal: I have loads of armhf machines and only so many amd64 machines that do not even have enough memory to properly support ceph and being able to do something (as the MON uses 1GB of memory alone). I have multiple sites with this situation, and for the foreseeable future, we will still be building infrastructure on armhf. Getting a decent AMD64 setup in any location is additional and probably unnecessary costs. Between 14.2.7 and 14.2.9 I had a longer look into the issue and started to fix some issues, for example the parsing of config options does pretty broken things if the default for the option does not fit into a 32bit integer. Fixing this properly brought me to various other places where size_t is being used in the code, but actually an (at least) uint64_t is being required. Fedora already removed ceph for all 32bit architectures with a "not supported by upstream anymore", but I was not able to find an official statement from ceph upstream. I think the stance of the ceph community in this is: as long as nobody sends in patches they are not going to care. And they can't support it themselves because they have a totally different target (clouds). Also unfortunately I did not yet find the time to collect my findings and send them to the ceph devel mailinglist, but I'd assume that they just don't want to support 32bit anymore, otherwise they'd test it properly. As the work to fix this is properly seems to be a rather long task, I definitely won't do this. But I also don't want to upload maybe-working binaries to Debian anymore. So unless somebody fixes and tests ceph for 32bit (or does this for Debian, also fine for me - running the regression test suite is possible with enough resources and some hardware), I will remove all 32bit architectures with the next upload. My debian karma is bad, really bad. That's why I asked you what your goal is of supporting 32 bit. I have a goal. I might also be able to let 64 bit lxc containers talk to 32 bit lxc containers and real armhf machines so I can test. I am willing to host the armhf releases and maybe the i386 releases on my server, that way there will be 32 bit releases but not official ones. But I do want your involvement. I've been trying to compile it for a time, using sources from ceph and from proxmox, until I realised ceph nautilus is in backports. And it worked. So at least I want your guidance on how you build these... For now I've used an armhf machine, and I needed to limit the number of threads to 1 due to c++ compiler needing more than 1GB of RAM to compile a single source. Not only do I want to make support complete so I can use hardware, I also think it's just bad programming not to use explicit sizes. And I am also on the verge of investing in amd64 clusters, I don't want it to depend on code that's depending on a lot of features. Anyway: I don't know how you build and test on non amd64 systems, do you also use armhf, or do you use a cross compile environment? Regards, Ard van Breemen
Bug#961481: ceph: Protocol incompatibility between armhf and amd64
Hi,
On Tue, May 26, 2020 at 06:35:20PM +0200, Val Lorentz wrote:
> Thanks for the tip.
>
> I just tried downgrading an OSD (armhf) and a monitor (amd64) to
> 14.2.7-1~bpo10+1 using http://snapshot.debian.org/ ; but they are still
> unable to communicate ("failed decoding of frame header:
> buffer::bad_alloc").
>
> So this might be a different issue, although related.
Well, 14.2.7-~bpo something did work on my armhf osd cluster,
with 2 mons running on armhf, and one on proxmox pve 6 running
ceph 14.2.8 .
What Already did not work was OSD's on AMD64 working together
with a 2xarmhf and 1xamd64 mon setup.
I had a lot of problems getting it to work at all, but I thought
it was just my lack of knowledge at that time. 99% of the
problems is with setting up the correct secrets, or in other
words, the handling of the "keyrings". Even between amd64 and
amd64 this has been buggy if I look at the release notes.
Specifically 14.2.6 to 14.2.7 I think.
I assume bugs are in authentication, because as long as I did not
reboot the amd64 it works.
The daemons authenticate using the secrets, and the secret gives
an authentication ticket.
Anyway: the most simple test is to install a system, rsync
/etc/ceph and type in ceph status. It either works (on 32 bits,
fix the timeout in the python script, because if you don't it
won't work at all) or it doesn't return at all.
I will test if it's also the case with armhf ceph cli client to a
amd64 cluster. I only have one working amd64 cluster though, and
it has 2 fake OSD's, because amd64 clusters are too expensive to
experiment with.
I have to do some networking hacks though to connect the systems.
Anyway: the kernel has no problem talking to either OSD types, so
the kernel's protocol handling is implemented correctly, and
cephx works between an rbd amd64 or armhf kernel client and armhf
userspace.
The rbd amd64 userspace utility however does not work at all. As
far as I can see it can't get past authentication, but without
any logs I am a bit riddled.
By the way: the mgr dashboard modules is about 99% correct. The
disk space is obviously calculated incorrectly.
Regards,
Ard
--
.signature not found
Bug#961481: ceph: Protocol incompatibility between armhf and amd64
Hi Guys, I've had working OSD's on armhf using 14.2.7 fixed using the workaround from #956293. The OSD and mon worked on armhf 14.2.7 and amd64 14.2.8 (proxmox install). When I upgraded the 14.2.7 cluster to 14.2.9, everything still worked, until I rebooted the proxmox server. Everything since then just went sauer. So: I have a complete working ceph cluster on 14.2.9 running on arm. ceph status works. Mapping rbd using echo to the /sys/bus/rbd/add_single_major works (using the username, key and monitors from ceph.conf) on kernel 5.6.11 amd64 and any other kernel (armhf or whatever). So, the ceph cluster works and the protocol is still correct. However as soon as I just want to do a ceph status on an amd64, I get an indefinite hanging ceph command line. No way to trace that (please tell me how). This problem is limited to amd64 though. When I install ceph on an i386 image, connecting to the ceph cluster works and the cluster is healthy. So protocol wise amd64 kernel works with 32 bits clusters. But amd64 user space does not work with 32 bits clusters. This might be somewhere in the authentication chain, as 14.2.9 was working (as far as I know) until I rebooted the 64 bit system. And I think that last CVE fix might be the problem. Anyway, I hope this reaches someone... Regards, Ard van Breemen
Bug#452049: Problem with debian vlan package
Hi,
Ryan Castellucci schreef op 2016-05-16 21:47:
What do we need to do to get the fix merged?
The only important stuff is in scripts*.d/{{m}vlan,ip} from 2010
The remainder can be removed.
The mvlan scripts needs to be upped to not use mvconfig anymore.
vconfig needs to be removed, but somehow I still see new bugs using
vconfig...
The 1.9-5 release has been tested on a large testbed (300+ servers) and
at home.
In a response on:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824535
I have explained how to not use the vlan package and actually use ip
link set, as the difference is a single pre-up line.
But in order of importance:
ip is the most important, as it allows to set things in the procfs
(ip-proxy-arp=1 for instance). Unfortunately some things can only be set
when the device is up, and some only when it's down.
vlan is just the ip link add... replacement
mvlan is just the ip link add ... replacement
Same goes for bridge-utils, as brctl is obsolete and vconfig has been
for 10 years, mvconfig (1.9-5 release) has been obsolete for 4 years I
think.
Anyway:
the current 2.0 version is not in git.
Regards,
Ard van Breemen
Bug#824535: vlan: no way to hotplug a VLAN device
Hi, Steinar H. Gunderson schreef op 2016-05-17 10:49: I've got an ARM system where eth0 is hotplugged pretty slowly (it hangs off of USB, and takes a while to initialize), so for networking to work in general, the system needs to be able to hotplug it. Thus, I have: I currently use a few 1000 xu4 ;-) allow-hotplug eth0 iface eth0 inet static address 10.1.0.7 netmask 255.255.255.0 gateway 10.1.0.1 up vconfig add eth0 20 up vconfig add eth0 21 up vconfig add eth0 22 This shouldn't be necessary, though. Perhaps vlan or ifupdown could be modified so that when interface “foo” gets hotplugged, it also takes that as a sign to hotplug every VLAN with “foo” as raw device? 1) This is the only correct solution. 2) After several problems, especially the one you describe, I've noticed that vlan and bridge-utils combined with ifupdown are obsolete. 3) never ever use vconfig, use: For bridges: iface br0 inet static... pre-up ip link add name $IFACE type bridge pre-up ip link set $IFACE address allow-hotplug eth1 iface eth1 inet manual pre-up ifup br0 || true pre-up ip link set $IFACE master br0 pre-up ip link set up dev $IFACE For macvlans use: ip link add link $IFACE name meth0 type macvlan mode bridge For vlans use: ip link add link $IFACE name vlan11 type vlan id 11 And for the vlan config itself use: allow-hotplug vlan11 iface vlan11 inet dhcp So the raw interface has been moved to the allow-hotplug of the raw interface. Another note on allow-hotplug and auto: On our armhf environment, hotplug will usually happen before auto for some interfaces, but after auto for others. About vconfig and such: around 2010 I had a miscommunication with my sponsor, so the new version without vconfig never got uploaded. So remember: vconfig, mvconfig and brctl are obsolete (and so is the vlan and the bridge-utils package) The auto keyword also is more or less obsolete. Ifupdown should be rewritten to accomodate network events (more than just hotplug events), and to allow for reversed dependency traversel and classing of devices and setups. Anyway: I know your pain, but in the current setup it's a wontfix, because any solution would be a single target solution that probably causes more troubles than it fixes. If you need more info you can find me at #odroid on freenode. On another note: I don't use the vlan package on arm based systems, and if I do use it, it's version 1.9-5 which has never made it to debian (although it is used in several companies). I will not close this yet, as this gives a lot to think about (the future direction of ifupdown).
Bug#823240: vlan: Does not work with interfaces named eno*
Hi, Michel Meyers schreef op 2016-05-02 17:39: I recently ran into some VLAN issues on a new server and found that it names all its interfaces eno1, The following vlan scripts appear to only take into account eth, bond and wlan interfaces: /etc/network/if-pre-up.d/vlan /etc/network/if-post-down.d/vlan It would be nice if you could also make them handle eno interfaces. Thanks for your work. I would love to, but this happens: http://anonscm.debian.org/cgit/collab-maint/vlan.git/commit/?id=3eed5b7482eb7952425b7455445df22419346047 It was working in 2010 in version 1.9-5 but it got "rejected". As such, I am only a maintainer by name. I have Cc: the guy that actually really does maintain the latest version. Regards, Ard van Breemen.
Bug#782751: IPv6 support
Package: corkscrew
Version: 2.0-10
Tag: patch
Corkscrew does not support ipv6 as proxy.
Since corkscrew is protocol agnostic, except for the connect part, I've
replaced that with the textbook getaddrinfo.
Attached is the quilt patch that makes it work for me. I hope that's the right
way these days to send patches ;-).
The patch allows to use linklocal%interface, dns, numerical, or whatever as
proxy address.
Regards,
Ard van Breemen
Description: enable AF_UNSPEC connections using getaddrinfo
Change port number into a string since getaddrinfo requires service name
Change connect to a loop around the results of getaddrinfo
Author: Ard van Breemen a...@kwaak.net
Last-Update: 2015-04-17
--- a/corkscrew.c
+++ b/corkscrew.c
@@ -27,7 +27,7 @@
char *base64_encodei PARAMS((char *in));
void usage PARAMS((void));
-int sock_connect PARAMS((const char *hname, int port));
+int sock_connect PARAMS((const char *hname, const char *port));
int main PARAMS((int argc, char *argv[]));
#define BUFSIZE 4096
@@ -132,32 +132,34 @@ void usage ()
}
#ifdef ANSI_FUNC
-int sock_connect (const char *hname, int port)
+int sock_connect (const char *hname, const char *port)
#else
int sock_connect (hname, port)
const char *hname;
-int port;
+const char *port;
#endif
{
int fd;
- struct sockaddr_in addr;
- struct hostent *hent;
-
- fd = socket(AF_INET, SOCK_STREAM, 0);
- if (fd == -1)
+ struct addrinfo hints;
+ struct addrinfo *result, *rp;
+ memset(hints, 0, sizeof(struct addrinfo));
+hints.ai_family = AF_UNSPEC;
+ hints.ai_socktype = SOCK_STREAM;
+ hints.ai_flags = 0;
+ hints.ai_protocol = 0;
+ if (getaddrinfo(hname, port, hints, result)!=0)
return -1;
-
- hent = gethostbyname(hname);
- if (hent == NULL)
- addr.sin_addr.s_addr = inet_addr(hname);
- else
- memcpy(addr.sin_addr, hent-h_addr, hent-h_length);
- addr.sin_family = AF_INET;
- addr.sin_port = htons(port);
-
- if (connect(fd, (struct sockaddr *)addr, sizeof(addr)))
+ for(rp=result;rp!=NULL;rp=rp-ai_next) {
+ fd=socket(rp-ai_family,rp-ai_socktype,rp-ai_protocol);
+ if(fd == -1)
+ continue;
+ if(connect(fd,rp-ai_addr,rp-ai_addrlen)!=-1)
+ break;
+ close(fd);
+ }
+ freeaddrinfo(result);
+ if(rp==NULL)
return -1;
-
return fd;
}
@@ -174,27 +176,27 @@ char *argv[];
#else
char uri[BUFSIZE], buffer[BUFSIZE], version[BUFSIZE], descr[BUFSIZE];
#endif
- char *host = NULL, *desthost = NULL, *destport = NULL;
+ char *host = NULL, *port = NULL, *desthost = NULL, *destport = NULL;
char *up = NULL;
char *tmp = NULL;
- int port, sent, setup, code, csock;
+ int sent, setup, code, csock;
fd_set rfd, sfd;
struct timeval tv;
ssize_t len;
FILE *fp;
- port = 80;
+ port = 80;
if ((argc == 5) || (argc == 6)) {
if (argc == 5) {
host = argv[1];
- port = atoi(argv[2]);
+ port = argv[2];
desthost = argv[3];
destport = argv[4];
}
if ((argc == 6)) {
host = argv[1];
- port = atoi(argv[2]);
+ port = argv[2];
desthost = argv[3];
destport = argv[4];
fp = fopen(argv[5], r);
Bug#782751: Acknowledgement (IPv6 support)
Hi, I just found out (as I needed to use an IPv6 based proxy) that socat can do the same thing: ssh -o ProxyCommand socat - PROXY:[fe80::250:b6ff:fe15:557%%eth0]:%h:%p,proxyport=3128 So even if you do not apply the patch, I leave this here so people know there are alternatives. Regards, Ard van Breemen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520436: iproute: provide ifup/down scripts to allow removal of deprecated vlan package
On Mon, May 24, 2010 at 10:56:15AM +0200, Andreas Henriksson wrote: IIRC Ard has been given access to the pkg-iproute git repo. No other news. PS. You're also welcome to help co-maintain iproute if you're interested. I've uploaded the latest vlan-bug-fix package to http://git.debian.org/?p=collab-maint/vlan.git;a=summary (awaiting sponsors approval and my production testing) which still contains backward compatability binaries. In the changes the phasing out of vlan is mentioned. If all is correct, it will only use the ip command, and warns when it has to use vconfig. The scripts can be added to iproute as is, but at the moment the iproute starts shipping the scripts, the release of a vlan shim package should also be carefully planned. But I do want to ship this last version with the binaries. Makes my life so much easier for now. -- .signature not found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520436: iproute: provide ifup/down scripts to allow removal of deprecated vlan package
On Mon, Feb 08, 2010 at 09:32:07AM +0100, Ard van Breemen wrote: Anyway: current functionality of the internal vlan package: - create vlans with either vconfig or ip depending on vconfig being there. - create macvlans with either mvconfig or ip depending on kernel version - set important network settings like arp_announce, arp_filter, or better: generic /proc/sys/net/ipv4/conf/devicename/setting This functionality is necessary for H.A. level2 failover setups, of which we have a bunch :-). As a matter of fact: there is an official internal ticket at that company that I should fix and upload a new vlan package. I can do a new vconfig and mvconfig less package this week. If anybody is willing to review it, it can either be integrated with or just uploaded as a standalone package. (just a few scripts so...) Either way I will be happy. -- .signature not found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520436: iproute: provide ifup/down scripts to allow removal of deprecated vlan package
Hi, On Sun, Feb 07, 2010 at 05:52:29PM +0100, Marco d'Itri wrote: On Feb 07, Andreas Henriksson andr...@fatal.se wrote: Not that I'm aware of. I'd like to hear from the vlan maintainer what he thinks about the suggested solution. Maybe you have news since you tagged this bug as a blocker for deprecating the vlan (vconfig) packages? No, I have not heard any news from him and I would like to know if we can arrange together for vconfig to be deprecated or we will have to work around him. Sorry, I am not an official debian maintainer, and so the distance to the community is a little far ;-). I'd like the vlan people to continue maintaining vlan related stuff even if they are merged into the iproute package. Ard, are you interested? I am maintaining it, al beit inside the company where I am using it. Since I am not a real debian maintainer I usually let the debian bugs be fixed by a sponsor, but I seem to be out of touch with him. I'm not personally interested in maintaining anything related to vlan as I don't have any use for it and more importantly doesn't have any way to do testing. This is not a great argument, as I am sure that you have no use for many other iproute features as well. Well, packaging existing software and adding scripting functionality that you can't test are two different things ;-). That would be nice. I'd also like to see ifupdown 0.7. In addition to the ifupdown maintainers being unresponsive we now also have kfreebsd - I am not aware of ifupdown having real maintainers, so it cannot be part of any solution until one will step up for real. So this needs to be fixed in iproute at least for the time being. For now I am ignoring that fact ;-). An additional question to all of this is why the vlan support should be provided by iproute and not ifupdown itself? No objections on my part, but I'd rather have a working solution in time for squeeze than a perfect solution in three years. I think all scripts should be integrated into ifupdown, since that's a network framework. iproute and vconfig are just tools. If not integrated, they should be modular addons to ifupdown: ifupdown-bonding, -vlan, etc As far as I know about everything can be down with iproute. At least the creation of macvlans is done with iproute in the internal version of vlan at my work. For now the future will probably be that I continue the vlan package (at least in a backward compatability mode), but without the vconfig binary. Within the vlan package I continue to maintain the more generic scripts to set stuff like arp_filter. Maybe it is better to just rename vlan to ifupdown-advancedrouting or something like that ;-). Anyway: current functionality of the internal vlan package: - create vlans with either vconfig or ip depending on vconfig being there. - create macvlans with either mvconfig or ip depending on kernel version - set important network settings like arp_announce, arp_filter, or better: generic /proc/sys/net/ipv4/conf/devicename/setting This functionality is necessary for H.A. level2 failover setups, of which we have a bunch :-). As a matter of fact: there is an official internal ticket at that company that I should fix and upload a new vlan package. But now without the blah: I am willing to maintain any vlan part that allows me to roll out firewalls fast. So if the scripts in iproute are going to replace the vlan package, I will be willing to maintain that. Especially if that means I don't have to take care of debian specific policies ;-). -- .signature not found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#457196: vlan interface created with _rename suffix
Hello, On Mon, Jan 14, 2008 at 10:21:15AM +0100, Lo??c Minier wrote: Thanks for your report and detailed information, and sorry for not getting back to you earlier; from your data above, it seems like it is either an udev or a kernel bug. I'm tentatively reassigning this to udev seeing that with the latest udev you always get the bug, and with older ones only with some recent kernels (which is more logical). I've been looking around a bit and I came up with the following: http://www.wlug.org.nz/UDev and http://www.linuxjournal.com/article/7316 To be clear: I do not use udev on any of my servers, so I cannot test it myself. But from the config from lionel I guess people are making the mistake into thinking that mac-addressess are unique, but they are not. The only correct method which will probably support *all* variants of pci cards that have the same mac-address (like the sparc), or none at all (there are a lot of cards that came without a valid mac-address, or where it simply isn't possible to look it up, like the lp486e): The match should be (in most cases): BUS=pci, ID=00:0b.0 ... and none of that mac addresses, please :-). In other busses than pci there probably is another valid item, or it is not needed at al. I assume it wil also fix vlan being incorrectly renamed. Regards, Ard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452049: can not use interface name eth0.0 for vlan
Hello, On Tue, Nov 20, 2007 at 06:12:54AM +0100, Eike Jan??en wrote: When I use eth0.0 as an interface name in /etc/network/interfaces the interface won't come up and there is an error message. I located the error in /etc/network/if-pre-up.d/vlan , line 17 where it wrongly gets classified as DEV_PLUS_VID. Well, that should be correct. eth0.0 is actually a special case of a vlan device: a device which only inserts the 802.1P tag. And 802.1P is the same as 1Q, except that the vlan tag is 0 instead of non-zero. What should happen is that eth0.0 get's created from eth0, and that eth0 is brought up. (eth0 should already exist). If something goes wrong there, then we really love to know. (This behaviour is normal since kernel 2.4.14 or so.) If that is not what you expected, then I would love to know why. If that is what you expected, can you send the ifup -v Regards, Ard (Not the official package maintainer) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352991: vlan does not integrate with bridge
Hello, On Tue, Jul 25, 2006 at 02:44:34PM +0200, Lo??c Minier wrote: On Wed, Feb 15, 2006, [EMAIL PROTECTED] wrote: vlan does not integrate well with bridged interfaces/bridge utils. Problems observed: 1. br0.100 and br0.200 is not brought up until /etc/networking/*.d/vlan script cases are extended I'm not sure of what br0.100 is supposed to mean. br0 is not a 100% compatible ethernet device. (See below.) There are two kinds of bridges possible. In this case he probably wants a 802.1D (bridge), with 802.1Q on top of it, especially if he wants to do STP. Anyway: as long as STP is not used, there should be no problem with that, except for that I cannot garantuee it will work kernel-wise. It's als possible to do .1Q and then .1D the .1Q ports, as you already pointed out. The STP is much cleaner then, but can only be undestood by very big/expensive irons that do IVL instead of SVL. But my take on this, is that we can go only go sofar as to support the vlan-raw-device in the interfaces file. Anything more than that is too task-specific, and should be done in preup/up/down/postdown lines in the interfaces fil. Regards, Ard -- begin LOVE-LETTER-FOR-YOU.txt.vbs I am a signature virus. Distribute me until the bitter end -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400827: vlan aliases don't appear to be supported
Hello, The following are stanzas from /etc/network/interfaces: iface vlan0002 inet static vlan-raw-device eth0 address 192.168.3.88 netmask 255.255.255.0 iface vlan0002:0 inet static vlan-raw-device eth0 --^ address 192.168.3.89 netmask 255.255.255.0 For an alias the actual interface must already exist. The vlan-raw-device should therefore not appear on the alias definition, as this tries to create the interface. (This is probably true for all such constructions like tunnels and bridges). So if you remove the vlan-raw-device from the alias definition, it should work as you want it. Regards ard. (I leave the bug open for Loic :-) ) -- begin LOVE-LETTER-FOR-YOU.txt.vbs I am a signature virus. Distribute me until the bitter end -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354933: vlan: vconfig is called again for inet6 stanzas
Hello, On Thu, Mar 02, 2006 at 05:23:30PM +1100, James Harper wrote: with a static inet6 entry in /etc/interfaces, the vlan ifupdown script try and do a second vconfig because they think it is a second interface. I'm not sure of the best way to work around this, but i'd be happy just to be able to add a 'vlan-ignore' entry to make the vlan code ignore something that looks like it should be processed. Is that a new option? Can you give an example interfaces line with plain eth devices? I am not aware of a method of seperating ipv4 and ipv6 in the interfaces file. (Eh, this means I am currently too lazy to aptitude update/install ifupdown and look into the docs myself ;-) ). -- begin LOVE-LETTER-FOR-YOU.txt.vbs I am a signature virus. Distribute me until the bitter end -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354933: vlan: vconfig is called again for inet6 stanzas
Hi, On Thu, Mar 02, 2006 at 09:19:47PM +1100, James Harper wrote: 'man interfaces' will tell all, but to save you the trouble, my config looks like: auto eth0 iface eth0 inet static address 192.168.200.251 netmask 255.255.255.0 dns-search int.sbss.com.au dns-nameservers 127.0.0.1 iface eth0 inet6 static address xxx:::0::1 netmask 64 Thanks! H... This gives a whole new meaning for the interfaces file to me... This is a router, which is why it has a static ip address. In most cases this won't be required as auto-configuration will take care of it, which is probably why this problem hasn't come up before. Correct. Personally I always added the static addresses in the up after the ipv4 stuff. Yours seems like the correct way. Hmmm. I have to look into it. For me it is new behaviour that ifup will handle multiple iface eth0 entries. (I probably didn't read the manpages right). I will experiment with it to try to understand what is going on. Regards, Ard -- begin LOVE-LETTER-FOR-YOU.txt.vbs I am a signature virus. Distribute me until the bitter end -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310734: RV: Debian Sarge ver. 17-05-2005, Bad: scheduling while atomic!, whe Iuse 8021q
reassign 310734 kernel-image-2.6.8-2-386 thanks This is apparently a kernel bug not related to the vlan userspace package. Regards, Ard van Breemen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#272891: vlan aliases and ifup ifdown
Hello, On Wed, Mar 23, 2005 at 02:54:28PM +0100, Lo?c Minier wrote: On mer, sep 22, 2004, Johann Botha wrote: I think it should only try to add/remove the vlan interface if it is not an alias. I came to the same conclusion. I've fixed the scripts in that it ignores (exit 0) any interface which has a colon. (Yes! I am really working on it :-) ) -- begin LOVE-LETTER-FOR-YOU.txt.vbs I am a signature virus. Distribute me until the bitter end -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
