Fwd: udev suggestion (persistent-net)

Fwd: udev suggestion (persistent-net)

[Matthias Schwarzott]

Hi list!

This is a mail I received these days from Martin Vaeth.

Matthias

----------  Forwared Mail  ----------

The problem with net-persistent.rules is of course that there is
trouble when mirroring a system or when e.g. in a server - typically
accessible only over network - a network card has to be exchanged.

This topic came up in de.comp.os.unix.misc and a suggestion was
made which gave me an idea which - when properly elaborated -
would work reliable (keeping essentially net-persistent.rules)
but would simultaneously avoid the above difficulties for most
systems.

Actually there are two similar ideas which can even be combined:

The first idea is to store in net-persistent.rules always one
interface *less* than what is actually found. This works really
reliable: The first "unknown" (i.e. not stored in net-persistent.rules)
interface should simply get the smallest number not associated with any
interface from net-persistent.rules. Of course, if a second "unknown"
interface appears it must get a further number, and that further
interface (and its number) is stored in net-persistent.rules.
This way you get at the next booting *reliably* the same interface
numbering, however, one interface less is needed in net-persistent.rules
[Of course, the interface might be stored nevertheless as a comment,
so that people can easily exchange the interfaces if they want;
the point is that this information is not *needed*].

Hence, in many cases no net-persistent.rules would be necessary at all,
although one still has reliable boot order if the situation changes.
But the solution becomes even more powerful if combined with the
following idea (which can also be used independently if you do not
like the above one):

Instead of storing the full MAC immediately store only a not-so-unique
information like e.g. the used kernel module first: Only if further
interfaces using the same kernel module appear, store the MAC of that
*further* interfaces. Again, this works reliable at the next boot (the
first "unknown" interface is supposed to be the one which had appeared
first at the last boot and gets the corresponding name).
[As for the other idea, the full MAC might be stored nevertheless as a
comment so that people can easily exchange if they want]

Combining both ideas, most setups will require no persistent-net.rules,
and people using typical setups like e.g. if there is only one ethernet
card and e.g. the ieee ethernet interface could easily modify their
persistent-net.rules so that it will still work reliable even if they
exchange the ethernet card (they just have to make sure that they
store *only* the ieee module name and its number in net-persistent.rules).
People using two ethernet cards using different modules could at least
exchange one of these ethernet cards and the other one against at
card using the same module without any problem etc.

So, roughly speaking, in many cases, one could write rules which run
on more than just one setup which avoids many problems (e.g. also
for mirroring setups for a computer park of similar systems).
And the boot order remains reliable even if the hardware completely
changes, because net-persistent.rules will then still be extended...

I would be really glad if udev would be heading into such a direction.
Please feel free to forward this posting also upstream (I do not know
who is most open to such a suggestion).

Regards
Martin

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Fwd: udev suggestion (persistent-net)

[Marco d'Itri]

On Nov 13, Matthias Schwarzott <zzam@gentoo.org> wrote:

> The first idea is to store in net-persistent.rules always one
> interface *less* than what is actually found. This works really
This would still not solve the case of the image of a server with
two interfaces which is moved to a different server.

> Instead of storing the full MAC immediately store only a not-so-unique
> information like e.g. the used kernel module first: Only if further
> interfaces using the same kernel module appear, store the MAC of that
> *further* interfaces. Again, this works reliable at the next boot (the
> first "unknown" interface is supposed to be the one which had appeared
> first at the last boot and gets the corresponding name).
No, because the enumeration order of drivers is not guaranteed to be
stable.

> Combining both ideas, most setups will require no persistent-net.rules,
> and people using typical setups like e.g. if there is only one ethernet
A typical server has two network interfaces.

> I would be really glad if udev would be heading into such a direction.
I would not. This would add a lot of complexity and hard to understand
conditions about when rules are created for little gain.

-- 
ciao,
Marco

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Fwd: udev suggestion (persistent-net)

[Vaeth]

On Tue, 13 Nov 2007, Marco d'Itri wrote:

> > The first idea is to store in net-persistent.rules always one
> > interface *less* than what is actually found. This works really
> This would still not solve the case of the image of a server with
> two interfaces which is moved to a different server.

It is correct that it would not solve all settings - I did not claim
this. But it would never be worse than the current solution and in
most cases be better - only some rare situations would still need
manual interaction.

> > Instead of storing the full MAC immediately store only a not-so-unique
> > information like e.g. the used kernel module first: Only if further
> > interfaces using the same kernel module appear, store the MAC of that
> > *further* interfaces. Again, this works reliable at the next boot (the
> > first "unknown" interface is supposed to be the one which had appeared
> > first at the last boot and gets the corresponding name).
> No, because the enumeration order of drivers is not guaranteed to be
> stable.

This approach does not need any enumeration order of drivers.
Maybe I did not explain clearly enough:

What one needs is a script which is called *always* when a new
interface appears and which checks against the content of
net-persistent.rules; this script will insert new rules typically
at the *beginning* of net-persistent.rules unless matching rules
already exist.

Let me give an example: Assume you have two tulip cards T1,T2 and one
ieee interface I. At the first boot (with empty net-persistent.rules)
the order is of course random. So we have e.g. initialization order
  I=eth0, T2=eth1, T1=eth2
When T2 is initialized here, the script must check that there was already
an interface provided and no other tulip interface is yet provideded by
net-persistent.rules. So it will insert at the beginning of
net-persistent.rules a line like
  DRIVER=tulip, NAME=eth1
Then, when T1 is being initialized, the script will check that there
already is a tulip entry in net-persistent.rules although T1 is a tulip
interface - so it detects a clash and will insert the specific rule
  MAC=[MAC of T1], NAME=eth2
at the beginning of net-persistent.rules (i.e. in front of the
"more general" rule which necessarily was written before).

At the next boot, the script will - independently of any enumeration
order - of course give T1 the number provided by net-persistent.rules,
i.e. T1 becomes eth2. T2 will be detected by the script as the first
tulip interface without any further specification in net-persisitent.ruls
(i.e. the script must check, of course, that all interfaces already
initialized are either non-tulip or have other matching rules specified in
net-persistent.rules) - if these two conditions apply, the script will
add nothing to net-persistent.rules. And, of course, T2 will become eth2
according to net-persistent.rules.
So - independently of the initialization order - there will be
  T2=eth1, T1=eth2
and no extension of the net-persistent.rules file
(and, of course, similarly: I=eth0).

> > Combining both ideas, most setups will require no persistent-net.rules,
> > and people using typical setups like e.g. if there is only one ethernet
> A typical server has two network interfaces.

But often not with the same driver. Even if they have the same driver,
only *one* of these MACs will be stored, i.e. at least the other card
can be exchanged without problems.

> > I would be really glad if udev would be heading into such a direction.
> I would not. This would add a lot of complexity and hard to understand
> conditions about when rules are created for little gain.

The gain is that udev will be running out-of-the-box in most settings
(not in all, I admit, but e.g. after mirroring a harddisk or exchanging
a card without manual interaction, udev will run in many "typical" cases
and not only in some exceptional ones).
From the user's perspective it is not important to understand when
rules are inserted into net-persistent.rules (from the user's perspective,
essentially the only difference is that with my suggestion there will be
less rules in this file and actually less rules are needed here; of
course, udev might still insert the other rules as comments).
The user *can* of course still specify all interfaces, just as now,
but if he omits one, he still gets the first non-specified number for
this omitted rule *without* having the rule automagically re-appear
in the file, as is the case now. So from the user's perspective,
the handling might be even clearer.
Of course, the script itself is rather complex (and needs perhaps even
some extensions of udev to its task).

Anyway, the decision is up to you. These were just my 5c.

Regards
Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Fwd: udev suggestion (persistent-net)

[Bryan Kadzban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Vaeth wrote:
> Let me give an example: Assume you have two tulip cards T1,T2 and one
> ieee interface I. At the first boot (with empty net-persistent.rules)
> the order is of course random. So we have e.g. initialization order
>    I=eth0, T2=eth1, T1=eth2

Let me simplify this example.  Start with just T1 (no IEEE interface, no
second tulip-using interface, just one tulip-using interface).  It will
get eth0 when the machine boots, and the rule that you want to generate
will be:

DRIVER="tulip", NAME="eth0"

Now, the user shuts the machine down and adds a second NIC that also
uses the tulip driver.  At boot, if the old NIC shows up to udev first,
then I think your setup would work fine.  But if the new NIC shows up
first, then *it* will get eth0, and the original NIC will get its own
MAC rule created (and assigned eth1).  (If I understand your idea
correctly, the second NIC would get its own MAC rule.  But you can't
force the newly-added NIC to show up second; the NICs will show up in a
random order.)

I don't see any way to make udev discard the old rule when you replace a
NIC, but keep the old rule when you add a new NIC.  Yes, this isn't
optimal, but I can't come up with any better solution either.  udevd
doesn't know whether any other NICs will show up on the system later
(and fundamentally *can't* know -- think USB NICs), so it has no way to
tell the difference between an additional card and a replacement card.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHOjIPS5vET1Wea5wRA2kKAKClhy0UBBol2xZYfWatAKmrGekQSwCePleC
PyXVzk3/+aldXz44mVfsWu4=7ZpH
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Fwd: udev suggestion (persistent-net)

[Vaeth]

On Tue, 13 Nov 2007, Bryan Kadzban wrote:

> Let me simplify this example.  Start with just T1 (no IEEE interface, no
> second tulip-using interface, just one tulip-using interface).  It will
> get eth0 when the machine boots, and the rule that you want to generate
> will be:
> 
> DRIVER="tulip", NAME="eth0"
> 
> Now, the user shuts the machine down and adds a second NIC that also
> uses the tulip driver.

This is correct: At the *first* boot with an *added* card, that card
which was not (completely) specified might change its name.
This is intentional: Only in this way the newly added card has a chance
to replace the old one (as you write: There is no way to tell whether
a card was replaced or just a new card was added, because you never
know when the kernel has "found" all hardware).
However, at *further* boots the order will remain.
   This should not be confusing from the user's perspective if he looks
at net-persistent.rules: He sees that one tulip card should be eth0,
and this is the case. Of course, if the user dislikes the behaviour,
he can still choose to specify the MAC of the card, i.e. he can still
have the current behaviour. The difference is that he is not forced to
do so (i.e. the rule DRIVER="tulip", NAME="eth0" will not prevent
the user from adding a further tulip card without manual interaction).

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Fwd: udev suggestion (persistent-net)

[Matthias Schwarzott]

On Mittwoch, 14. November 2007, Vaeth wrote:
> On Tue, 13 Nov 2007, Bryan Kadzban wrote:
> > Let me simplify this example.  Start with just T1 (no IEEE interface, no
> > second tulip-using interface, just one tulip-using interface).  It will
> > get eth0 when the machine boots, and the rule that you want to generate
> > will be:
> >
> > DRIVER="tulip", NAME="eth0"
> >
> > Now, the user shuts the machine down and adds a second NIC that also
> > uses the tulip driver.
>
> This is correct: At the *first* boot with an *added* card, that card
> which was not (completely) specified might change its name.
> This is intentional: Only in this way the newly added card has a chance
> to replace the old one (as you write: There is no way to tell whether
> a card was replaced or just a new card was added, because you never
> know when the kernel has "found" all hardware).
> However, at *further* boots the order will remain.
>    This should not be confusing from the user's perspective if he looks
> at net-persistent.rules: He sees that one tulip card should be eth0,
> and this is the case. Of course, if the user dislikes the behaviour,
> he can still choose to specify the MAC of the card, i.e. he can still
> have the current behaviour. The difference is that he is not forced to
> do so (i.e. the rule DRIVER="tulip", NAME="eth0" will not prevent
> the user from adding a further tulip card without manual interaction).
>
Well, the user is not forced to do anything. But with present rules he also 
can change the generated rules to match DRIVER or whatever criteria he wants.

You can also keep the rules and write a script to be called when a card has 
been changed. Once the system is installed finally you can add this rule to 
call your script:

SUBSYSTEM="net", NAME="", IMPORT{program}="hw got exchanged"
this script could then sleep for some time (like 10s) to be sure all other 
existant net-cards got drivers loaded - and then check which assigned card 
misses and create a rule replacing this card.

This is all possible - but I will not vote for adding this rules into default 
udev ruleset.

Matthias

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel