Menu
▾
▴
devil-linux-develop
|
From: Steve R. <Ste...@sa...> - 2010-04-20 15:31:08
|
Hi,
As part of my investigations to the "/etc/udev/rules.d/70-persistent-net.rules" issue reported just now, I discovered the "/sbin/nameif" program, which reads the file "/etc/mactab" if it exists, and associates interface names with mac-address.
It has to be run prior to the interface(s) starting, so I envisage it hooked into "/etc/init.d/network" to be called only if the file "/etc/mactab" exists. "jiim-barber" on one of the debian lists offers "[ -x /sbin/nameif ] && [ -r /etc/mactab ] && /sbin/nameif " as a code-frag that could be included in "/etc/init.d/network".
The format of "/etc/mactab" is:
#--- /etc/mactab : associate network interfaces with MAC address
#
eth0 00:08:02:01:02:03
eth1 00:08:02:01:02:04
eth2 00:08:02:01:02:05
#
#--- End
I'd assume that the default config would *not* include "/etc/mactab" which would only be created if the default udev-assignment needed to be modified.
If this feature doesn't make it into release 1.4 I'll not be upset.
Regards - Steve.
Stephen H F Ralph
Principal Computer Officer | Integration Team | ICT Services | Transform Sandwell
Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE
Email: ste...@sa...<mailto:ste...@sa...>
|
|
From: Bruce S. <bw...@re...> - 2010-04-20 16:19:25
|
Are you saying that /etc/mactab does the same thing as /etc/udev/rules.d/70-persistent-net.rules ? If so, should we do the same thing two different ways? - BS On Tue, Apr 20, 2010 at 11:30, Steve Ralph <Ste...@sa...> wrote: > Hi, > > As part of my investigations to the > "/etc/udev/rules.d/70-persistent-net.rules" issue reported just now, I > discovered the "/sbin/nameif" program, which reads the file "/etc/mactab" if > it exists, and associates interface names with mac-address. > > It has to be run prior to the interface(s) starting, so I envisage it hooked > into "/etc/init.d/network" to be called only if the file "/etc/mactab" > exists. "jiim-barber" on one of the debian lists offers "[ -x /sbin/nameif ] > && [ -r /etc/mactab ] && /sbin/nameif " as a code-frag that could be > included in "/etc/init.d/network". > > The format of "/etc/mactab" is: > > #--- /etc/mactab : associate network interfaces with MAC address > # > eth0 00:08:02:01:02:03 > eth1 00:08:02:01:02:04 > eth2 00:08:02:01:02:05 > # > #--- End > > I'd assume that the default config would *not* include "/etc/mactab" which > would only be created if the default udev-assignment needed to be modified. > > If this feature doesn't make it into release 1.4 I'll not be upset. > > Regards - Steve. |
|
From: Heiko Z. <he...@zu...> - 2010-04-25 12:39:52
|
I took a quick look at our network init script. I'm not sure about a good place to put the nameif line, since we may required the module to be loaded first. Honestly I'd rather stick with just the udev solution for now, but I'm open to suggestions. Heiko > -----Original Message----- > From: Bruce Smith [mailto:bw...@re...] > Sent: Tuesday, April 20, 2010 10:51 AM > To: dev...@li... > Subject: Re: [Devil-linux-develop] Feature request - Enable > "nameif" to associate MAC address with correct interface name. > > Are you saying that /etc/mactab does the same thing as > /etc/udev/rules.d/70-persistent-net.rules ? > > If so, should we do the same thing two different ways? > > - BS > > > On Tue, Apr 20, 2010 at 11:30, Steve Ralph > <Ste...@sa...> wrote: > > Hi, > > > > As part of my investigations to the > > "/etc/udev/rules.d/70-persistent-net.rules" issue reported just > now, I > > discovered the "/sbin/nameif" program, which reads the file > "/etc/mactab" if > > it exists, and associates interface names with mac-address. > > > > It has to be run prior to the interface(s) starting, so I > envisage it hooked > > into "/etc/init.d/network" to be called only if the file > "/etc/mactab" > > exists. "jiim-barber" on one of the debian lists offers "[ -x > /sbin/nameif ] > > && [ -r /etc/mactab ] && /sbin/nameif " as a code-frag that could > be > > included in "/etc/init.d/network". > > > > The format of "/etc/mactab" is: > > > > #--- /etc/mactab : associate network interfaces with MAC > address > > # > > eth0 00:08:02:01:02:03 > > eth1 00:08:02:01:02:04 > > eth2 00:08:02:01:02:05 > > # > > #--- End > > > > I'd assume that the default config would *not* include > "/etc/mactab" which > > would only be created if the default udev-assignment needed to be > modified. > > > > If this feature doesn't make it into release 1.4 I'll not be > upset. > > > > Regards - Steve. > > ------------------------------------------------------------------- > ----------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
|
From: Frank W. <Fra...@ct...> - 2010-04-26 06:31:19
|
Hi, being a complete ignorant about how udev works internally, I wonder if it would be possible to put multiple entries in 70-persistent-net.rules, eg. ma:cc:ad:dr:es:s1 is eth0 ma:cc:ad:dr:es:s2 is eth0 ma:cc:ad:dr:es:s3 is eth1 ma:cc:ad:dr:es:s4 is eth1 Plan B: If that doesn't work (or can be hacked to work easily) I'd favour a solution which handles multiple etc-mods.tar.bz2 entirely. This would probably be interesting for other people/problems too (someone wanted to be able to roll back to the previous config recently) We'd need the following: *) save-config would need to be able to attach a label (that would go into the filename) and maybe a description. *) a way to specify which config is 'hot': there used to be boot options that specified where the config-file is and what it is called. See if it's still there and if it works. *) a tool to manage config files list, delete, copy, specify 'hot' file at next boot. What do you think? I'd be willing to invest some time into this if this can make us all happy... Frank Heiko Zuerker wrote: > I took a quick look at our network init script. > I'm not sure about a good place to put the nameif line, since we may > required the module to be loaded first. > Honestly I'd rather stick with just the udev solution for now, but I'm > open to suggestions. > > Heiko > -- _______________________________________________ Centre de Technologie de l'Education 29 avenue John F. Kennedy L-1855 Luxembourg-Kirchberg email: Fra...@ct... tél.: +352 247-85973 fax: +352 333797 _______________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2010-04-26 15:13:33
|
Hey, Quoting Dominic Raferd <dl...@ed...>: > Regarding udev, I found info at > http://www.reactivated.net/writing_udev_rules.html#why about how it > works which mentions some udev tools - udevinfo, udevtest, udevtrigger, > udevcontrol - which are missing in DL, and might be worth adding. Those are the old tools, they have been replaced by 'udevadm'. Excecute 'udevadm help' for details. > udevtrigger seems to be the way to reprocess udev rules without > rebooting. Altering (or deleting) 70-persistent-net.rules + udevtrigger > + /etc/init.d/network restart should be a way to fix a broken network > connection after a hardware change. At the moment I think you have to > save-config and reboot instead of udevtrigger. We use the the trigger and settle commands in /etc/init.d/boot. > If this worked, then a new option could be added for the network script, > say '-redetect' which would stop the network, delete > 70-persistent-net.rules, then run udevtrigger before starting the > network again. It should also post an advisory message that the change > will not persist under DL unless configuration is saved. -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Heiko Z. <he...@zu...> - 2010-04-26 18:48:25
|
I think a warning should also be displayed, that the order of the interfaces may have changed and the admin needs to verify. Can you send the patch as an attachment please? Or even better, create a feature request in mantis and attach it there. That way we won't loose track of it. Heiko Quoting Dominic Raferd <dl...@ed...>: > On 26/04/2010 16:13, Heiko Zuerker wrote: >> Hey, >> >> Quoting Dominic Raferd<dl...@ed...>: >> >> >>> Regarding udev, I found info at >>> http://www.reactivated.net/writing_udev_rules.html#why about how it >>> works which mentions some udev tools - udevinfo, udevtest, udevtrigger, >>> udevcontrol - which are missing in DL, and might be worth adding. >>> >> Those are the old tools, they have been replaced by 'udevadm'. >> Excecute 'udevadm help' for details. >> > cool, thanks >>> udevtrigger seems to be the way to reprocess udev rules without >>> rebooting. Altering (or deleting) 70-persistent-net.rules + udevtrigger >>> + /etc/init.d/network restart should be a way to fix a broken network >>> connection after a hardware change. At the moment I think you have to >>> save-config and reboot instead of udevtrigger. >>> >> We use the the trigger and settle commands in /etc/init.d/boot. >> > So I see, and I learn something! >> >>> If this worked, then a new option could be added for the network script, >>> say '-redetect' which would stop the network, delete >>> 70-persistent-net.rules, then run udevtrigger before starting the >>> network again. It should also post an advisory message that the change >>> will not persist under DL unless configuration is saved. >>> >> > To fix a simple broken network connection after a hardware change > (especially if using the autoselect option in Setup/Network i.e. letting > udev choose the network card module), here is a patch for the network > script (DL 1.4RC3): > > --- /etc/init.d/network 1980-01-01 01:01:01.000000000 +0000 > +++ /home/z-shares/scripts/network 2010-04-26 19:21:47.000000000 +0100 > @@ -517,0 +518,15 @@ > + > + redetect) > + $0 stop $ONLY_INTERFACE > + sleep 1 > + echo -n "Removed persistent record(s) for " > + egrep -o "NAME=\"[^\"]*" > /etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}' > + rm /etc/udev/rules.d/70-persistent-net.rules > + udevadm trigger --subsystem-match=net > + udevadm settle > + echo -n "Redetected and recreated persistent record(s) for " > + egrep -o "NAME=\"[^\"]*" > /etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}' > + $0 start $ONLY_INTERFACE > + echo "Network devices redetected. Run save-config to > make changes permanent." > + ;; > + > @@ -519 +534 @@ > - echo "Usage: $0 {start|stop|restart} [interface]" > + echo "Usage: $0 {start|stop|restart|redetect} [interface]" > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Steve R. <Ste...@sa...> - 2010-04-27 09:49:36
|
Hi, >>> On 25/04/2010 13:40, Heiko Zuerker wrote: >>> I took a quick look at our network init script. >>> I'm not sure about a good place to put the nameif line, since we may required the module to be loaded first. We (Roy and I) are currently half-way through patching init.d/network script to call nameif on a per-interface basis; once we have it sorted I'll post both here and log a patch on mantis. Then we'll have two methods of sorting this issue, nameif and udev, and can discuss which is the best to use. Regards - Steve. Stephen H F Ralph Principal Computer Officer | Integration Team | ICT Services | Transform Sandwell Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE Email: ste...@sa... -----Original Message----- From: Heiko Zuerker [mailto:he...@zu...] Sent: 26 April 2010 19:48 To: dev...@li... Subject: Re: [Devil-linux-develop] Feature request - Enable "nameif" to associate MAC address with correct interface name. I think a warning should also be displayed, that the order of the interfaces may have changed and the admin needs to verify. Can you send the patch as an attachment please? Or even better, create a feature request in mantis and attach it there. That way we won't loose track of it. Heiko Quoting Dominic Raferd <dl...@ed...>: > On 26/04/2010 16:13, Heiko Zuerker wrote: >> Hey, >> >> Quoting Dominic Raferd<dl...@ed...>: >> >> >>> Regarding udev, I found info at >>> http://www.reactivated.net/writing_udev_rules.html#why about how it >>> works which mentions some udev tools - udevinfo, udevtest, udevtrigger, >>> udevcontrol - which are missing in DL, and might be worth adding. >>> >> Those are the old tools, they have been replaced by 'udevadm'. >> Excecute 'udevadm help' for details. >> > cool, thanks >>> udevtrigger seems to be the way to reprocess udev rules without >>> rebooting. Altering (or deleting) 70-persistent-net.rules + udevtrigger >>> + /etc/init.d/network restart should be a way to fix a broken network >>> connection after a hardware change. At the moment I think you have to >>> save-config and reboot instead of udevtrigger. >>> >> We use the the trigger and settle commands in /etc/init.d/boot. >> > So I see, and I learn something! >> >>> If this worked, then a new option could be added for the network script, >>> say '-redetect' which would stop the network, delete >>> 70-persistent-net.rules, then run udevtrigger before starting the >>> network again. It should also post an advisory message that the change >>> will not persist under DL unless configuration is saved. >>> >> > To fix a simple broken network connection after a hardware change > (especially if using the autoselect option in Setup/Network i.e. letting > udev choose the network card module), here is a patch for the network > script (DL 1.4RC3): > > --- /etc/init.d/network 1980-01-01 01:01:01.000000000 +0000 > +++ /home/z-shares/scripts/network 2010-04-26 19:21:47.000000000 +0100 > @@ -517,0 +518,15 @@ > + > + redetect) > + $0 stop $ONLY_INTERFACE > + sleep 1 > + echo -n "Removed persistent record(s) for " > + egrep -o "NAME=\"[^\"]*" > /etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}' > + rm /etc/udev/rules.d/70-persistent-net.rules > + udevadm trigger --subsystem-match=net > + udevadm settle > + echo -n "Redetected and recreated persistent record(s) for " > + egrep -o "NAME=\"[^\"]*" > /etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}' > + $0 start $ONLY_INTERFACE > + echo "Network devices redetected. Run save-config to > make changes permanent." > + ;; > + > @@ -519 +534 @@ > - echo "Usage: $0 {start|stop|restart} [interface]" > + echo "Usage: $0 {start|stop|restart|redetect} [interface]" > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------------ _______________________________________________ Devil-linux-develop mailing list Dev...@li... https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
|
From: Dominic R. <dl...@ed...> - 2010-04-29 10:46:22
|
I did that, after making some improvements. Now it provides more warnings and info about the devices it is removing / recreating, backs up the old rules file, and optionally resets ifcfg-eth[n] file(s) (for discovered eth[n] devices) to module="autoselect". It has 2 modes of operation, one of which deletes the rules file (allowing complete redetection of hardware and perhaps successful restart of the network) and the other doesn't, which should allow restart of the network after manual configuration of the rules file. And there is help information. I've done some testing of it but without moving network hardware around / changing network hardware. When I've done that I will post it as an additional comment to the feature request in Mantis. Dominic On 26/04/2010 19:48, Heiko Zuerker wrote: > I think a warning should also be displayed, that the order of the > interfaces may have changed and the admin needs to verify. > > Can you send the patch as an attachment please? > Or even better, create a feature request in mantis and attach it > there. That way we won't loose track of it. > > Heiko |
|
From: Dominic R. <dl...@ed...> - 2010-04-26 08:21:12
|
Regarding udev, I found info at http://www.reactivated.net/writing_udev_rules.html#why about how it works which mentions some udev tools - udevinfo, udevtest, udevtrigger, udevcontrol - which are missing in DL, and might be worth adding. udevtrigger seems to be the way to reprocess udev rules without rebooting. Altering (or deleting) 70-persistent-net.rules + udevtrigger + /etc/init.d/network restart should be a way to fix a broken network connection after a hardware change. At the moment I think you have to save-config and reboot instead of udevtrigger. If this worked, then a new option could be added for the network script, say '-redetect' which would stop the network, delete 70-persistent-net.rules, then run udevtrigger before starting the network again. It should also post an advisory message that the change will not persist under DL unless configuration is saved. Dominic On 26/04/2010 07:32, Frank Weis wrote: > Hi, > > being a complete ignorant about how udev works internally, I wonder if > it would be possible to put multiple entries in 70-persistent-net.rules, > eg. > > ma:cc:ad:dr:es:s1 is eth0 > ma:cc:ad:dr:es:s2 is eth0 > > ma:cc:ad:dr:es:s3 is eth1 > ma:cc:ad:dr:es:s4 is eth1 > > > Plan B: > If that doesn't work (or can be hacked to work easily) I'd favour a > solution which handles multiple etc-mods.tar.bz2 entirely. This would > probably be interesting for other people/problems too (someone wanted to > be able to roll back to the previous config recently) > > We'd need the following: > > *) save-config would need to be able to attach a label (that would go > into the filename) and maybe a description. > > *) a way to specify which config is 'hot': there used to be boot options > that specified where the config-file is and what it is called. See if > it's still there and if it works. > > *) a tool to manage config files > list, > delete, > copy, > specify 'hot' file at next boot. > > What do you think? I'd be willing to invest some time into this if this > can make us all happy... > > Frank > > > Heiko Zuerker wrote: > >> I took a quick look at our network init script. >> I'm not sure about a good place to put the nameif line, since we may >> required the module to be loaded first. >> Honestly I'd rather stick with just the udev solution for now, but I'm >> open to suggestions. >> >> Heiko >> |
|
From: Dominic R. <dl...@ed...> - 2010-04-26 18:24:11
|
On 26/04/2010 16:13, Heiko Zuerker wrote: > Hey, > > Quoting Dominic Raferd<dl...@ed...>: > > >> Regarding udev, I found info at >> http://www.reactivated.net/writing_udev_rules.html#why about how it >> works which mentions some udev tools - udevinfo, udevtest, udevtrigger, >> udevcontrol - which are missing in DL, and might be worth adding. >> > Those are the old tools, they have been replaced by 'udevadm'. > Excecute 'udevadm help' for details. > cool, thanks >> udevtrigger seems to be the way to reprocess udev rules without >> rebooting. Altering (or deleting) 70-persistent-net.rules + udevtrigger >> + /etc/init.d/network restart should be a way to fix a broken network >> connection after a hardware change. At the moment I think you have to >> save-config and reboot instead of udevtrigger. >> > We use the the trigger and settle commands in /etc/init.d/boot. > So I see, and I learn something! > >> If this worked, then a new option could be added for the network script, >> say '-redetect' which would stop the network, delete >> 70-persistent-net.rules, then run udevtrigger before starting the >> network again. It should also post an advisory message that the change >> will not persist under DL unless configuration is saved. >> > To fix a simple broken network connection after a hardware change (especially if using the autoselect option in Setup/Network i.e. letting udev choose the network card module), here is a patch for the network script (DL 1.4RC3): --- /etc/init.d/network 1980-01-01 01:01:01.000000000 +0000 +++ /home/z-shares/scripts/network 2010-04-26 19:21:47.000000000 +0100 @@ -517,0 +518,15 @@ + + redetect) + $0 stop $ONLY_INTERFACE + sleep 1 + echo -n "Removed persistent record(s) for " + egrep -o "NAME=\"[^\"]*" /etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}' + rm /etc/udev/rules.d/70-persistent-net.rules + udevadm trigger --subsystem-match=net + udevadm settle + echo -n "Redetected and recreated persistent record(s) for " + egrep -o "NAME=\"[^\"]*" /etc/udev/rules.d/70-persistent-net.rules|awk -F \" '{print $2}' + $0 start $ONLY_INTERFACE + echo "Network devices redetected. Run save-config to make changes permanent." + ;; + @@ -519 +534 @@ - echo "Usage: $0 {start|stop|restart} [interface]" + echo "Usage: $0 {start|stop|restart|redetect} [interface]" |
