devil-linux-develop

[Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

[Steve R. <Ste...@sa...>]

Hi there,

I have been working to port some internal configuration scripts to DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from multiple different machines and continue work where I left off.

When I boot from the original install and list the network interfaces (either ifconfig or ip addr show), all seems OK. Once I run save-config, and then boot from different hardware, I have an issue around the assignment of the interface names.

After some investigation, this seems to be because the file "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball created by save-config.  This file links the mac-address to the device name (eg, 00:08:02:01:02:03 is named eth0).

When this file already exists (eg, after save-config has been run), and the usb-key boots on different hardware, udev says eth0 is already assigned
because the mac address of the previous machine is linked to eth0 in 70-persistent-net.rules (even if the listed mac-address is nowhere to be seen on this hardware), and assigns the new mac-address to the next available device, eg, eth1.

If I save-config again the problem is exacerbated! On the second and subsequent hardware, interfaces are assigned after the devices allocated in 70-persistent-net.rules, but any statically configured addresses are assigned to the original network devices.

EG:
        1st machine
                IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
                IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
                IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24

        2nd machine
                IF=eth0 MAC=00:08:02:01:02:06
                IF=eth1 MAC=00:08:02:01:02:07
                IF=eth2 MAC=00:08:02:01:02:08

        When using the saved-config from the first machine on the second machine
                IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24    Interface Not available as MAC address not found!
                IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24    Interface Not available as MAC address not found!
                IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24    Interface Not available as MAC address not found!
                IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned
                IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned
                IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned

This issue could also occur if a pre-saved config file was installed on new kit as part of a hardware only upgrade.

I suggest a fix would be to exclude the file "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with save-config allowing this file to be dynamically created at boot up like on the initial boot.

Before I log a call on mantis I would appreciate a sanity check first, to confirm that I haven't missed anything obvious.

Additionally, although I have had no issues with the CD assignment, should "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the save-config?

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...>

Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

[Heiko Z. <he...@zu...>]

Quoting Steve Ralph <Ste...@sa...>: 

> Hi there, 
>
> I have been working to port some internal configuration scripts to DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from multiple different machines and continue work where I left off. 
>
> When I boot from the original install and list the network interfaces (either ifconfig or ip addr show), all seems OK. Once I run save-config, and then boot from different hardware, I have an issue around the assignment of the interface names. 
>
> After some investigation, this seems to be because the file "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball created by save-config. This file links the mac-address to the device name (eg, 00:08:02:01:02:03 is named eth0). 
>
> When this file already exists (eg, after save-config has been run), and the usb-key boots on different hardware, udev says eth0 is already assigned 
> because the mac address of the previous machine is linked to eth0 in 70-persistent-net.rules (even if the listed mac-address is nowhere to be seen on this hardware), and assigns the new mac-address to the next available device, eg, eth1.  
>
> If I save-config again the problem is exacerbated! On the second and subsequent hardware, interfaces are assigned after the devices allocated in 70-persistent-net.rules, but any statically configured addresses are assigned to the original network devices. 
>
> EG: 
>         1st machine 
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24 
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24 
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24 
>
>         2nd machine 
>                 IF=eth0 MAC=00:08:02:01:02:06  
>                 IF=eth1 MAC=00:08:02:01:02:07  
>                 IF=eth2 MAC=00:08:02:01:02:08  
>
>         When using the saved-config from the first machine on the second machine 
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface Not available as MAC address not found! 
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface Not available as MAC address not found! 
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface Not available as MAC address not found! 
>                 IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned 
>                 IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned 
>                 IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned 
>
> This issue could also occur if a pre-saved config file was installed on new kit as part of a hardware only upgrade. 
>
> I suggest a fix would be to exclude the file "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with save-config allowing this file to be dynamically created at boot up like on the initial boot. 
>
> Before I log a call on mantis I would appreciate a sanity check first, to confirm that I haven't missed anything obvious. 
>
> Additionally, although I have had no issues with the CD assignment, should "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the save-config?

 During an upgrade to a newer DL version we automatically de-select those files. 

On one hand I'm a bit reluctant to remove them in save-config, but then on the other hand I never "upgrade" them either. 

Is anybody actually relying on these files?

-- 

Regards
  Heiko Zuerker
http://www.devil-linux.org

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

[Bruce S. <bw...@re...>]

My concern is if the computer has multiple NIC's of the same
make/model and the interface numbers are dynamically assigned every
time the computer is booted, it may not assign the same NIC to the
same interface every time.

It would probably assign them the same as long as nothing changes.
But what if someone adds another piece of unrelated hardware that
causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
patches or new versions of other network software?  I see a real
possibility of the NIC/interface assignment changing upon boot.  And
now your firewall has reversed NIC's, potentially allowing the
Internet full access to your private network.

 - BS


On Tue, Apr 20, 2010 at 11:00, Steve Ralph <Ste...@sa...> wrote:
> Hi there,
>
> I have been working to port some internal configuration scripts to
> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
> multiple different machines and continue work where I left off.
>
> When I boot from the original install and list the network interfaces
> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
> then boot from different hardware, I have an issue around the assignment of
> the interface names.
>
> After some investigation, this seems to be because the file
> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
> created by save-config.  This file links the mac-address to the device name
> (eg, 00:08:02:01:02:03 is named eth0).
>
> When this file already exists (eg, after save-config has been run), and the
> usb-key boots on different hardware, udev says eth0 is already assigned
> because the mac address of the previous machine is linked to eth0 in
> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
> seen on this hardware), and assigns the new mac-address to the next
> available device, eg, eth1.
>
> If I save-config again the problem is exacerbated! On the second and
> subsequent hardware, interfaces are assigned after the devices allocated in
> 70-persistent-net.rules, but any statically configured addresses are
> assigned to the original network devices.
>
> EG:
>         1st machine
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>
>         2nd machine
>                 IF=eth0 MAC=00:08:02:01:02:06
>                 IF=eth1 MAC=00:08:02:01:02:07
>                 IF=eth2 MAC=00:08:02:01:02:08
>
>         When using the saved-config from the first machine on the second
> machine
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>                 IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>                 IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>
> This issue could also occur if a pre-saved config file was installed on new
> kit as part of a hardware only upgrade.
>
> I suggest a fix would be to exclude the file
> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
> save-config allowing this file to be dynamically created at boot up like on
> the initial boot.
>
> Before I log a call on mantis I would appreciate a sanity check first, to
> confirm that I haven't missed anything obvious.
>
> Additionally, although I have had no issues with the CD assignment, should
> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
> save-config?
>
> Regards - Steve.

Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

[Steve R. <Ste...@sa...>]

During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
This would be a concern. I'd assumed the assignment would be consistent across boots.

Is a valid distinction to say that "/etc/mactab" is for user-control while "70-persistent-net.rules" is under kernel control?

Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.

Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.

A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".

Regards - Steve.
Email: ste...@sa...


-----Original Message-----
From: Bruce Smith [mailto:bw...@re...]
Sent: 20 April 2010 16:47
To: dev...@li...
Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

My concern is if the computer has multiple NIC's of the same
make/model and the interface numbers are dynamically assigned every
time the computer is booted, it may not assign the same NIC to the
same interface every time.

It would probably assign them the same as long as nothing changes.
But what if someone adds another piece of unrelated hardware that
causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
patches or new versions of other network software?  I see a real
possibility of the NIC/interface assignment changing upon boot.  And
now your firewall has reversed NIC's, potentially allowing the
Internet full access to your private network.

 - BS

and :

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:00, Steve Ralph <Ste...@sa...> wrote:
> Hi there,
>
> I have been working to port some internal configuration scripts to
> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
> multiple different machines and continue work where I left off.
>
> When I boot from the original install and list the network interfaces
> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
> then boot from different hardware, I have an issue around the assignment of
> the interface names.
>
> After some investigation, this seems to be because the file
> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
> created by save-config.  This file links the mac-address to the device name
> (eg, 00:08:02:01:02:03 is named eth0).
>
> When this file already exists (eg, after save-config has been run), and the
> usb-key boots on different hardware, udev says eth0 is already assigned
> because the mac address of the previous machine is linked to eth0 in
> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
> seen on this hardware), and assigns the new mac-address to the next
> available device, eg, eth1.
>
> If I save-config again the problem is exacerbated! On the second and
> subsequent hardware, interfaces are assigned after the devices allocated in
> 70-persistent-net.rules, but any statically configured addresses are
> assigned to the original network devices.
>
> EG:
>         1st machine
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>
>         2nd machine
>                 IF=eth0 MAC=00:08:02:01:02:06
>                 IF=eth1 MAC=00:08:02:01:02:07
>                 IF=eth2 MAC=00:08:02:01:02:08
>
>         When using the saved-config from the first machine on the second
> machine
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>                 IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>                 IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>
> This issue could also occur if a pre-saved config file was installed on new
> kit as part of a hardware only upgrade.
>
> I suggest a fix would be to exclude the file
> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
> save-config allowing this file to be dynamically created at boot up like on
> the initial boot.
>
> Before I log a call on mantis I would appreciate a sanity check first, to
> confirm that I haven't missed anything obvious.
>
> Additionally, although I have had no issues with the CD assignment, should
> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
> save-config?
>
> Regards - Steve.

------------------------------------------------------------------------------
Download Intel&#174; 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

Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

[Bruce S. <bw...@re...>]

One solution would be to automatically detect a major hardware change
and prompt the user for what to do.  Kinda like what happens with a
new version of DL.  Although I'm not sure exactly how to detect a
major hardware change, and what constitutes "major".

 - BS


On Tue, Apr 20, 2010 at 12:50, Steve Ralph <Ste...@sa...> wrote:
> During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
> This would be a concern. I'd assumed the assignment would be consistent across boots.
>
> Is a valid distinction to say that "/etc/mactab" is for user-control while "70-persistent-net.rules" is under kernel control?
>
> Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.
>
> Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.
>
> A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".
>
> Regards - Steve.
> Email: ste...@sa...
>
>
> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: 20 April 2010 16:47
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>
> My concern is if the computer has multiple NIC's of the same
> make/model and the interface numbers are dynamically assigned every
> time the computer is booted, it may not assign the same NIC to the
> same interface every time.
>
> It would probably assign them the same as long as nothing changes.
> But what if someone adds another piece of unrelated hardware that
> causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
> patches or new versions of other network software?  I see a real
> possibility of the NIC/interface assignment changing upon boot.  And
> now your firewall has reversed NIC's, potentially allowing the
> Internet full access to your private network.
>
>  - BS
>
> and :
>
> 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:00, Steve Ralph <Ste...@sa...> wrote:
>> Hi there,
>>
>> I have been working to port some internal configuration scripts to
>> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
>> multiple different machines and continue work where I left off.
>>
>> When I boot from the original install and list the network interfaces
>> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
>> then boot from different hardware, I have an issue around the assignment of
>> the interface names.
>>
>> After some investigation, this seems to be because the file
>> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
>> created by save-config.  This file links the mac-address to the device name
>> (eg, 00:08:02:01:02:03 is named eth0).
>>
>> When this file already exists (eg, after save-config has been run), and the
>> usb-key boots on different hardware, udev says eth0 is already assigned
>> because the mac address of the previous machine is linked to eth0 in
>> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
>> seen on this hardware), and assigns the new mac-address to the next
>> available device, eg, eth1.
>>
>> If I save-config again the problem is exacerbated! On the second and
>> subsequent hardware, interfaces are assigned after the devices allocated in
>> 70-persistent-net.rules, but any statically configured addresses are
>> assigned to the original network devices.
>>
>> EG:
>>         1st machine
>>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>>
>>         2nd machine
>>                 IF=eth0 MAC=00:08:02:01:02:06
>>                 IF=eth1 MAC=00:08:02:01:02:07
>>                 IF=eth2 MAC=00:08:02:01:02:08
>>
>>         When using the saved-config from the first machine on the second
>> machine
>>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>                 IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>                 IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>
>> This issue could also occur if a pre-saved config file was installed on new
>> kit as part of a hardware only upgrade.
>>
>> I suggest a fix would be to exclude the file
>> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
>> save-config allowing this file to be dynamically created at boot up like on
>> the initial boot.
>>
>> Before I log a call on mantis I would appreciate a sanity check first, to
>> confirm that I haven't missed anything obvious.
>>
>> Additionally, although I have had no issues with the CD assignment, should
>> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
>> save-config?
>>
>> Regards - Steve.

Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

[Steve R. <Ste...@sa...>]

If we leave save-config exactly as it is, but enable "/sbin/nameif" from init.d/network, do we get the best of both worlds?

Steve.

-----Original Message-----
From: Bruce Smith [mailto:bw...@re...]
Sent: 20 April 2010 17:54
To: dev...@li...
Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

One solution would be to automatically detect a major hardware change
and prompt the user for what to do.  Kinda like what happens with a
new version of DL.  Although I'm not sure exactly how to detect a
major hardware change, and what constitutes "major".

 - BS


On Tue, Apr 20, 2010 at 12:50, Steve Ralph <Ste...@sa...> wrote:
> During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
> This would be a concern. I'd assumed the assignment would be consistent across boots.
>
> Is a valid distinction to say that "/etc/mactab" is for user-control while "70-persistent-net.rules" is under kernel control?
>
> Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.
>
> Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.
>
> A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".
>
> Regards - Steve.
> Email: ste...@sa...
>
>
> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: 20 April 2010 16:47
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>
> My concern is if the computer has multiple NIC's of the same
> make/model and the interface numbers are dynamically assigned every
> time the computer is booted, it may not assign the same NIC to the
> same interface every time.
>
> It would probably assign them the same as long as nothing changes.
> But what if someone adds another piece of unrelated hardware that
> causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
> patches or new versions of other network software?  I see a real
> possibility of the NIC/interface assignment changing upon boot.  And
> now your firewall has reversed NIC's, potentially allowing the
> Internet full access to your private network.
>
>  - BS
>
> and :
>
> 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:00, Steve Ralph <Ste...@sa...> wrote:
>> Hi there,
>>
>> I have been working to port some internal configuration scripts to
>> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
>> multiple different machines and continue work where I left off.
>>
>> When I boot from the original install and list the network interfaces
>> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
>> then boot from different hardware, I have an issue around the assignment of
>> the interface names.
>>
>> After some investigation, this seems to be because the file
>> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
>> created by save-config.  This file links the mac-address to the device name
>> (eg, 00:08:02:01:02:03 is named eth0).
>>
>> When this file already exists (eg, after save-config has been run), and the
>> usb-key boots on different hardware, udev says eth0 is already assigned
>> because the mac address of the previous machine is linked to eth0 in
>> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
>> seen on this hardware), and assigns the new mac-address to the next
>> available device, eg, eth1.
>>
>> If I save-config again the problem is exacerbated! On the second and
>> subsequent hardware, interfaces are assigned after the devices allocated in
>> 70-persistent-net.rules, but any statically configured addresses are
>> assigned to the original network devices.
>>
>> EG:
>>         1st machine
>>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>>
>>         2nd machine
>>                 IF=eth0 MAC=00:08:02:01:02:06
>>                 IF=eth1 MAC=00:08:02:01:02:07
>>                 IF=eth2 MAC=00:08:02:01:02:08
>>
>>         When using the saved-config from the first machine on the second
>> machine
>>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>                 IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>                 IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>
>> This issue could also occur if a pre-saved config file was installed on new
>> kit as part of a hardware only upgrade.
>>
>> I suggest a fix would be to exclude the file
>> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
>> save-config allowing this file to be dynamically created at boot up like on
>> the initial boot.
>>
>> Before I log a call on mantis I would appreciate a sanity check first, to
>> confirm that I haven't missed anything obvious.
>>
>> Additionally, although I have had no issues with the CD assignment, should
>> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
>> save-config?
>>
>> Regards - Steve.

------------------------------------------------------------------------------
Download Intel&#174; 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

Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

[Dominic R. <dl...@ed...>]

If you want to change NIC[s] or run the same DL configuration on 
different hardware, temporarily remove 70-persistent-net.rules before 
saving the configuration e.g.

mv /etc/udev/rules.d/70-persistent-net.rules /var/tmp/ && save-config -q 
&& mv /var/tmp/70-persistent-net.rules /etc/udev/rules.d/

It is automatically recreated at reboot.

Dominic

On 20/04/2010 18:01, Steve Ralph wrote:
> If we leave save-config exactly as it is, but enable "/sbin/nameif" from init.d/network, do we get the best of both worlds?
>
> Steve.
>
> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: 20 April 2010 17:54
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>
> One solution would be to automatically detect a major hardware change
> and prompt the user for what to do.  Kinda like what happens with a
> new version of DL.  Although I'm not sure exactly how to detect a
> major hardware change, and what constitutes "major".
>
>   - BS
>
>
> On Tue, Apr 20, 2010 at 12:50, Steve Ralph<Ste...@sa...>  wrote:
>    
>> During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>      
>>>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
>>>>>            
>> This would be a concern. I'd assumed the assignment would be consistent across boots.
>>
>> Is a valid distinction to say that "/etc/mactab" is for user-control while "<span class="inlinecode">" is under kernel control?
>>
>> Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.
>>
>> Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.
>>
>> A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".
>>
>> Regards - Steve.
>> Email: ste...@sa...
>>
>>
>> -----Original Message-----
>> From: Bruce Smith [mailto:bw...@re...]
>> Sent: 20 April 2010 16:47
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>>
>> My concern is if the computer has multiple NIC's of the same
>> make/model and the interface numbers are dynamically assigned every
>> time the computer is booted, it may not assign the same NIC to the
>> same interface every time.
>>
>> It would probably assign them the same as long as nothing changes.
>> But what if someone adds another piece of unrelated hardware that
>> causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
>> patches or new versions of other network software?  I see a real
>> possibility of the NIC/interface assignment changing upon boot.  And
>> now your firewall has reversed NIC's, potentially allowing the
>> Internet full access to your private network.
>>
>>   - BS
>>
>> and :
>>
>> 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:00, Steve Ralph<Ste...@sa...>  wrote:
>>      
>>> Hi there,
>>>
>>> I have been working to port some internal configuration scripts to
>>> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
>>> multiple different machines and continue work where I left off.
>>>
>>> When I boot from the original install and list the network interfaces
>>> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
>>> then boot from different hardware, I have an issue around the assignment of
>>> the interface names.
>>>
>>> After some investigation, this seems to be because the file
>>> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
>>> created by save-config.  This file links the mac-address to the device name
>>> (eg, 00:08:02:01:02:03 is named eth0).
>>>
>>> When this file already exists (eg, after save-config has been run), and the
>>> usb-key boots on different hardware, udev says eth0 is already assigned
>>> because the mac address of the previous machine is linked to eth0 in
>>> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
>>> seen on this hardware), and assigns the new mac-address to the next
>>> available device, eg, eth1.
>>>
>>> If I save-config again the problem is exacerbated! On the second and
>>> subsequent hardware, interfaces are assigned after the devices allocated in
>>> 70-persistent-net.rules, but any statically configured addresses are
>>> assigned to the original network devices.
>>>
>>> EG:
>>>          1st machine
>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>>>
>>>          2nd machine
>>>                  IF=eth0 MAC=00:08:02:01:02:06
>>>                  IF=eth1 MAC=00:08:02:01:02:07
>>>                  IF=eth2 MAC=00:08:02:01:02:08
>>>
>>>          When using the saved-config from the first machine on the second
>>> machine
>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>                  IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>                  IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>
>>> This issue could also occur if a pre-saved config file was installed on new
>>> kit as part of a hardware only upgrade.
>>>
>>> I suggest a fix would be to exclude the file
>>> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
>>> save-config allowing this file to be dynamically created at boot up like on
>>> the initial boot.
>>>
>>> Before I log a call on mantis I would appreciate a sanity check first, to
>>> confirm that I haven't missed anything obvious.
>>>
>>> Additionally, although I have had no issues with the CD assignment, should
>>> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
>>> save-config?
>>>
>>> Regards - Steve.
>>>        
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>
>    

Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

[Dominic R. <dl...@ed...>]

If you want to change NIC[s] or run the same DL configuration on 
different hardware, temporarily remove 70-persistent-net.rules before 
saving the configuration e.g.

mv /etc/udev/rules.d/70-persistent-net.rules /var/tmp/ && save-config -q 
&& mv /var/tmp/70-persistent-net.rules /etc/udev/rules.d/

It is automatically recreated at reboot.

Dominic

On 20/04/2010 18:01, Steve Ralph wrote:
> If we leave save-config exactly as it is, but enable "/sbin/nameif" from init.d/network, do we get the best of both worlds?
>
> Steve.
>
> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: 20 April 2010 17:54
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>
> One solution would be to automatically detect a major hardware change
> and prompt the user for what to do.  Kinda like what happens with a
> new version of DL.  Although I'm not sure exactly how to detect a
> major hardware change, and what constitutes "major".
>
>   - BS
>
>
> On Tue, Apr 20, 2010 at 12:50, Steve Ralph<Ste...@sa...>  wrote:
>    
>> During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>      
>>>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
>>>>>            
>> This would be a concern. I'd assumed the assignment would be consistent across boots.
>>
>> Is a valid distinction to say that "/etc/mactab" is for user-control while "<span class="inlinecode">" is under kernel control?
>>
>> Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.
>>
>> Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.
>>
>> A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".
>>
>> Regards - Steve.
>> Email: ste...@sa...
>>
>>
>> -----Original Message-----
>> From: Bruce Smith [mailto:bw...@re...]
>> Sent: 20 April 2010 16:47
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>>
>> My concern is if the computer has multiple NIC's of the same
>> make/model and the interface numbers are dynamically assigned every
>> time the computer is booted, it may not assign the same NIC to the
>> same interface every time.
>>
>> It would probably assign them the same as long as nothing changes.
>> But what if someone adds another piece of unrelated hardware that
>> causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
>> patches or new versions of other network software?  I see a real
>> possibility of the NIC/interface assignment changing upon boot.  And
>> now your firewall has reversed NIC's, potentially allowing the
>> Internet full access to your private network.
>>
>>   - BS
>>
>> and :
>>
>> 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:00, Steve Ralph<Ste...@sa...>  wrote:
>>      
>>> Hi there,
>>>
>>> I have been working to port some internal configuration scripts to
>>> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
>>> multiple different machines and continue work where I left off.
>>>
>>> When I boot from the original install and list the network interfaces
>>> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
>>> then boot from different hardware, I have an issue around the assignment of
>>> the interface names.
>>>
>>> After some investigation, this seems to be because the file
>>> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
>>> created by save-config.  This file links the mac-address to the device name
>>> (eg, 00:08:02:01:02:03 is named eth0).
>>>
>>> When this file already exists (eg, after save-config has been run), and the
>>> usb-key boots on different hardware, udev says eth0 is already assigned
>>> because the mac address of the previous machine is linked to eth0 in
>>> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
>>> seen on this hardware), and assigns the new mac-address to the next
>>> available device, eg, eth1.
>>>
>>> If I save-config again the problem is exacerbated! On the second and
>>> subsequent hardware, interfaces are assigned after the devices allocated in
>>> 70-persistent-net.rules, but any statically configured addresses are
>>> assigned to the original network devices.
>>>
>>> EG:
>>>          1st machine
>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>>>
>>>          2nd machine
>>>                  IF=eth0 MAC=00:08:02:01:02:06
>>>                  IF=eth1 MAC=00:08:02:01:02:07
>>>                  IF=eth2 MAC=00:08:02:01:02:08
>>>
>>>          When using the saved-config from the first machine on the second
>>> machine
>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>                  IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>                  IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>
>>> This issue could also occur if a pre-saved config file was installed on new
>>> kit as part of a hardware only upgrade.
>>>
>>> I suggest a fix would be to exclude the file
>>> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
>>> save-config allowing this file to be dynamically created at boot up like on
>>> the initial boot.
>>>
>>> Before I log a call on mantis I would appreciate a sanity check first, to
>>> confirm that I haven't missed anything obvious.
>>>
>>> Additionally, although I have had no issues with the CD assignment, should
>>> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
>>> save-config?
>>>
>>> Regards - Steve.
>>>        
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>
>    

Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

[Stefan E. <ma...@en...>]

I need my firewall box to always assign the nics in the same order I
once configured them, regardless of whether I add new hardware, change
the card's pci slots, add a new kernel, etc. SuSe was once known to mess
up nic order when updating to a new kernel. AFAIK that was the time
before we had udev, but who knows what happens nowadays if you just
remove/do not save 70-persistent-net.rules and change anything on your
firewall machine. I do not want to dig around changing nic-names in
config files (dhcp, firewall scripts, ...), only because my former
interal eth1 is now reported as external eth0 and tries to serve the
internet via dhcp.

So not saving 70-persistent-net.rules or not having any other method to
always ensure that the nics come up in the right order is a no-go for me.

On the other hand, I have a replacement firewall on cold-standby, it's
the same machine, except for the mac-addresses of the nics. If I need
to, I just plug the usb stick with the firewall config into the
standby-box and start it. But ... now I have to be aware of the
persistent mac assignment. So a feature to have multiple sets of machine
specific nic-setups would really be nice. Identifier could be the mac
adresses. If mac address A is found, just use 70-persistent-net.rules
containing mac address A. Or something similar.

Regards,
Stefan

Dominic Raferd wrote:
> If you want to change NIC[s] or run the same DL configuration on 
> different hardware, temporarily remove 70-persistent-net.rules before 
> saving the configuration e.g.
> 
> mv /etc/udev/rules.d/70-persistent-net.rules /var/tmp/ && save-config -q 
> && mv /var/tmp/70-persistent-net.rules /etc/udev/rules.d/
> 
> It is automatically recreated at reboot.
> 
> Dominic
> 
> On 20/04/2010 18:01, Steve Ralph wrote:
>> If we leave save-config exactly as it is, but enable "/sbin/nameif" from init.d/network, do we get the best of both worlds?
>>
>> Steve.
>>
>> -----Original Message-----
>> From: Bruce Smith [mailto:bw...@re...]
>> Sent: 20 April 2010 17:54
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>>
>> One solution would be to automatically detect a major hardware change
>> and prompt the user for what to do.  Kinda like what happens with a
>> new version of DL.  Although I'm not sure exactly how to detect a
>> major hardware change, and what constitutes "major".
>>
>>   - BS
>>
>>
>> On Tue, Apr 20, 2010 at 12:50, Steve Ralph<Ste...@sa...>  wrote:
>>    
>>> During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>>      
>>>>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
>>>>>>            
>>> This would be a concern. I'd assumed the assignment would be consistent across boots.
>>>
>>> Is a valid distinction to say that "/etc/mactab" is for user-control while "<span class="inlinecode">" is under kernel control?
>>>
>>> Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.
>>>
>>> Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.
>>>
>>> A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".
>>>
>>> Regards - Steve.
>>> Email: ste...@sa...
>>>
>>>
>>> -----Original Message-----
>>> From: Bruce Smith [mailto:bw...@re...]
>>> Sent: 20 April 2010 16:47
>>> To: dev...@li...
>>> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>>>
>>> My concern is if the computer has multiple NIC's of the same
>>> make/model and the interface numbers are dynamically assigned every
>>> time the computer is booted, it may not assign the same NIC to the
>>> same interface every time.
>>>
>>> It would probably assign them the same as long as nothing changes.
>>> But what if someone adds another piece of unrelated hardware that
>>> causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
>>> patches or new versions of other network software?  I see a real
>>> possibility of the NIC/interface assignment changing upon boot.  And
>>> now your firewall has reversed NIC's, potentially allowing the
>>> Internet full access to your private network.
>>>
>>>   - BS
>>>
>>> and :
>>>
>>> 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:00, Steve Ralph<Ste...@sa...>  wrote:
>>>      
>>>> Hi there,
>>>>
>>>> I have been working to port some internal configuration scripts to
>>>> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
>>>> multiple different machines and continue work where I left off.
>>>>
>>>> When I boot from the original install and list the network interfaces
>>>> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
>>>> then boot from different hardware, I have an issue around the assignment of
>>>> the interface names.
>>>>
>>>> After some investigation, this seems to be because the file
>>>> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
>>>> created by save-config.  This file links the mac-address to the device name
>>>> (eg, 00:08:02:01:02:03 is named eth0).
>>>>
>>>> When this file already exists (eg, after save-config has been run), and the
>>>> usb-key boots on different hardware, udev says eth0 is already assigned
>>>> because the mac address of the previous machine is linked to eth0 in
>>>> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
>>>> seen on this hardware), and assigns the new mac-address to the next
>>>> available device, eg, eth1.
>>>>
>>>> If I save-config again the problem is exacerbated! On the second and
>>>> subsequent hardware, interfaces are assigned after the devices allocated in
>>>> 70-persistent-net.rules, but any statically configured addresses are
>>>> assigned to the original network devices.
>>>>
>>>> EG:
>>>>          1st machine
>>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>>>>
>>>>          2nd machine
>>>>                  IF=eth0 MAC=00:08:02:01:02:06
>>>>                  IF=eth1 MAC=00:08:02:01:02:07
>>>>                  IF=eth2 MAC=00:08:02:01:02:08
>>>>
>>>>          When using the saved-config from the first machine on the second
>>>> machine
>>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
>>>> Not available as MAC address not found!
>>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
>>>> Not available as MAC address not found!
>>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
>>>> Not available as MAC address not found!
>>>>                  IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
>>>> available as MAC address found but NO IP Address assigned
>>>>                  IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
>>>> available as MAC address found but NO IP Address assigned
>>>>                  IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
>>>> available as MAC address found but NO IP Address assigned
>>>>
>>>> This issue could also occur if a pre-saved config file was installed on new
>>>> kit as part of a hardware only upgrade.
>>>>
>>>> I suggest a fix would be to exclude the file
>>>> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
>>>> save-config allowing this file to be dynamically created at boot up like on
>>>> the initial boot.
>>>>
>>>> Before I log a call on mantis I would appreciate a sanity check first, to
>>>> confirm that I haven't missed anything obvious.
>>>>
>>>> Additionally, although I have had no issues with the CD assignment, should
>>>> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
>>>> save-config?
>>>>
>>>> Regards - Steve.
>>>>        
>> ------------------------------------------------------------------------------
>> Download Intel&#174; 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
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; 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
>>
>>    
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 
> 

Re: [Devil-linux-develop] /etc/udev/rules.d/70-persistent-net.rules and /etc/mactab

[Steve R. <Ste...@sa...>]

OK, thanks everyone.

Taking on board everyone's comments to date, I'll combine my initial bug/feature requests into a new proposal.

As the absence of "70-persistent-net.rules" may not generate the NIC assignments in the same order (which I agree could be disastrous for a firewall) then I now think that the present behaviour of save-config including "70-persistent-net.rules" should be retained.

My test-environment on a usb-stick (used on differing hardware) is conceptually the same as Stefan's requirement to fail-over a saved config onto a cold standby box. While the impact on my usb test-build to correct persistent mac assignment is no real problem, if you are failing over a firewall you want a speedy swapover with as little messing as possible, assuming always that you have configured this upfront.

Just patching /etc/init.d/network to call /sbin/nameif to align interfaces and mac-addresses will not, on it's own, address this scenario.

What enabling a call to nameif and mactab does do is allow an administrator to take control of interface assignment, rather than having to work with whatever udev saves in 70-persistent-net.rules.

My colleague Roy (the "linux-nut" of previous posts) has a proof-of-concept bash-script that reads a separate new config file /etc/mactable.conf pre-populated with multiple interface/mac-address details from *both* the current-active and the cold-standby hardware, and greps to populate /etc/mactab with only the entries relating to addresses discovered by "ifconfig -a". This would need to be called earlier in the startup sequence than network startup, which would then find a valid /etc/mactab for the booting hardware.

Sequencing would need to be as follow (pseudo code):

        if /etc/mactable.conf exists
                then create or overwrite /etc/mactab from /etc/mactable.conf
        fi
        if /etc/mactab exists
                then call nameif to use it
        else
                use the current behaviour (Eg: 70-persistent-net.rules)
        fi

So, if the requirement is to assign mac addresses to specific devices on a single system edit /etc/mactab, or If the requirement is to assign differect mac addresses to specific devices on a failover systems edit /etc/mactable.conf.

Does this sound to be a way forward?

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...

Re: [Devil-linux-develop] /etc/udev/rules.d/70-persistent-net.rules and /etc/mactab

[Bruce S. <bw...@re...>]

Another idea I just came up with is to add an option to save-config to
save a new config file with a different name, omitting all hardware
specific files, who's purpose is to be transferred to a different
machine.

And since the new saved config file has a different name, there is no
chance of it being used upon boot by mistake, without manual renaming.

To do this, we'd need to come up with a list of files to omit.
Probably more than just the NIC related files.  LVM files?  Others?

That might be the quickest and easiest solution.  Thoughts?

 - BS


On Wed, Apr 21, 2010 at 10:40, Steve Ralph <Ste...@sa...> wrote:
> OK, thanks everyone.
>
> Taking on board everyone's comments to date, I'll combine my initial bug/feature requests into a new proposal.
>
> As the absence of "70-persistent-net.rules" may not generate the NIC assignments in the same order (which I agree could be disastrous for a firewall) then I now think that the present behaviour of save-config including "70-persistent-net.rules" should be retained.
>
> My test-environment on a usb-stick (used on differing hardware) is conceptually the same as Stefan's requirement to fail-over a saved config onto a cold standby box. While the impact on my usb test-build to correct persistent mac assignment is no real problem, if you are failing over a firewall you want a speedy swapover with as little messing as possible, assuming always that you have configured this upfront.
>
> Just patching /etc/init.d/network to call /sbin/nameif to align interfaces and mac-addresses will not, on it's own, address this scenario.
>
> What enabling a call to nameif and mactab does do is allow an administrator to take control of interface assignment, rather than having to work with whatever udev saves in 70-persistent-net.rules.
>
> My colleague Roy (the "linux-nut" of previous posts) has a proof-of-concept bash-script that reads a separate new config file /etc/mactable.conf pre-populated with multiple interface/mac-address details from *both* the current-active and the cold-standby hardware, and greps to populate /etc/mactab with only the entries relating to addresses discovered by "ifconfig -a". This would need to be called earlier in the startup sequence than network startup, which would then find a valid /etc/mactab for the booting hardware.
>
> Sequencing would need to be as follow (pseudo code):
>
>        if /etc/mactable.conf exists
>                then create or overwrite /etc/mactab from /etc/mactable.conf
>        fi
>        if /etc/mactab exists
>                then call nameif to use it
>        else
>                use the current behaviour (Eg: 70-persistent-net.rules)
>        fi
>
> So, if the requirement is to assign mac addresses to specific devices on a single system edit /etc/mactab, or If the requirement is to assign differect mac addresses to specific devices on a failover systems edit /etc/mactable.conf.
>
> Does this sound to be a way forward?
>
> Regards - Steve.
>

Re: [Devil-linux-develop] /etc/udev/rules.d/70-persistent-net.rules and /etc/mactab

[Steve R. <Ste...@sa...>]

Bruce,

This does not help  the high speed firewall swap to standby hardware. The NIC sequence as the cold-standby starts up might require manual configuration.

Regards - Steve.

-----Original Message-----
From: Bruce Smith [mailto:bw...@re...]
Sent: 21 April 2010 15:47
To: dev...@li...
Subject: Re: [Devil-linux-develop] /etc/udev/rules.d/70-persistent-net.rules and /etc/mactab

Another idea I just came up with is to add an option to save-config to
save a new config file with a different name, omitting all hardware
specific files, who's purpose is to be transferred to a different
machine.

And since the new saved config file has a different name, there is no
chance of it being used upon boot by mistake, without manual renaming.

To do this, we'd need to come up with a list of files to omit.
Probably more than just the NIC related files.  LVM files?  Others?

That might be the quickest and easiest solution.  Thoughts?

 - BS


On Wed, Apr 21, 2010 at 10:40, Steve Ralph <Ste...@sa...> wrote:
> OK, thanks everyone.
>
> Taking on board everyone's comments to date, I'll combine my initial bug/feature requests into a new proposal.
>
> As the absence of "70-persistent-net.rules" may not generate the NIC assignments in the same order (which I agree could be disastrous for a firewall) then I now think that the present behaviour of save-config including "70-persistent-net.rules" should be retained.
>
> My test-environment on a usb-stick (used on differing hardware) is conceptually the same as Stefan's requirement to fail-over a saved config onto a cold standby box. While the impact on my usb test-build to correct persistent mac assignment is no real problem, if you are failing over a firewall you want a speedy swapover with as little messing as possible, assuming always that you have configured this upfront.
>
> Just patching /etc/init.d/network to call /sbin/nameif to align interfaces and mac-addresses will not, on it's own, address this scenario.
>
> What enabling a call to nameif and mactab does do is allow an administrator to take control of interface assignment, rather than having to work with whatever udev saves in 70-persistent-net.rules.
>
> My colleague Roy (the "linux-nut" of previous posts) has a proof-of-concept bash-script that reads a separate new config file /etc/mactable.conf pre-populated with multiple interface/mac-address details from *both* the current-active and the cold-standby hardware, and greps to populate /etc/mactab with only the entries relating to addresses discovered by "ifconfig -a". This would need to be called earlier in the startup sequence than network startup, which would then find a valid /etc/mactab for the booting hardware.
>
> Sequencing would need to be as follow (pseudo code):
>
>        if /etc/mactable.conf exists
>                then create or overwrite /etc/mactab from /etc/mactable.conf
>        fi
>        if /etc/mactab exists
>                then call nameif to use it
>        else
>                use the current behaviour (Eg: 70-persistent-net.rules)
>        fi
>
> So, if the requirement is to assign mac addresses to specific devices on a single system edit /etc/mactab, or If the requirement is to assign differect mac addresses to specific devices on a failover systems edit /etc/mactable.conf.
>
> Does this sound to be a way forward?
>
> Regards - Steve.
>

------------------------------------------------------------------------------
_______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop