generation of persistent network devices rules at install time

generation of persistent network devices rules at install time

[Marco d'Itri]

I have still not found a good solution to this problem, and it's not
practical anymore to emulate the 75-persistent-net-generator.rules logic
in a shell script.

Actually there are two slightly different scenarios in which I need to
generate these rules:
- when the package is installed on an already working system
- when the package is installed in a chroot

The first case is easier since there is a running udevd, and it could be
solved with some creativity by setting an environment variable in a
temporary rule file and checking it at the end of 75-p-n-g.r to stop
further processing of the rules (I do not want this process to wake up
anything else which may be triggered by uevents). But this is a corner
case since udev is installed by default on all Debian systems, and I
could as well ignore it.

I have no good idea about how to solve the second one since the system
already has a running udev process which I cannot mess with.

What do other distributions do?

-- 
ciao,
Marco

Re: generation of persistent network devices rules at install time

[Bryan Kadzban]

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

Marco d'Itri wrote:
> I have no good idea about how to solve the second one since the 
> system already has a running udev process which I cannot mess with.
> 
> What do other distributions do?

In LFS (not that we're a distro, but whatever), after floundering around
for several months and almost ten udev versions, we finally settled on
using udevadm test.  (At least for the moment.)  Works with kernels >2.6.8 if you don't care about the comments, or >= 2.6.18 if you do want
the comments (at least according to the testing we did).

It should work until udevadm test stops running programs specified in
IMPORT{program} keys.  ;-)

See e.g. the first part of
http://www.linuxfromscratch.org/lfs/view/development/chapter07/network.html
- -- that gets run from inside a chroot, after the new udev is installed.

(I'll be the first to admit that it's an abuse of udevadm -- but it
works for now, and unless we can expand IFNAMSIZ and then add the
ability to create by-mac or by-path or whatever symlinks to NICs -- then
you wouldn't need to generate anything -- it's the easiest we could come
up with.  Automatic "symlinks" (multiple names for the same interface)
would work great, but they'd have to be long enough to express the MAC
address or physical device path in the name, and IFNAMSIZ isn't nearly
long enough.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIjowdS5vET1Wea5wRA1kuAJ4qXDsJnMPVY3sqof1KrIiANsgYRACeKMlW
i0ECFhucpfu+xmFo5h3p4ig=YYPc
-----END PGP SIGNATURE-----

Re: generation of persistent network devices rules at install time

[Karl O. Pinc]

On 07/28/2008 09:34:59 PM, Marco d'Itri wrote:
> I have still not found a good solution to this problem, and it's not
> practical anymore to emulate the 75-persistent-net-generator.rules
> logic
> in a shell script.

I'm not sure I'm on-topic here, or whether this has been
discussed before, or whether my sleep deprived brain
is entirely missing the point, but...

I've looked at the persistent-net-generator rules/scripts
(et-al) and find them a kludge.  This is not (necessarily)
because they write rules, but because they attempt
to interpret the udev rule language in order to figure out
what to do.  (Reading and interpreting the udev rules
they generated to do things like figure out the
next device name in the ethN sequence to choose, etc.)

It seems to me that a more robust approach would be
to instead generate a (flat file, text based) database
and have a udev rule/shell script generate the necessary
rules and then execute them every time -- with perhaps
a bit of caching thrown in somehow so that the rules
are not really re-generated every time.

The user/admin would then muck with the text file,
aka database, aka configuration file, when desiring
a change in the the persistent device mapping.

By storing state explicitly in a "database" rather
than in udev rules you open up the possibility of
additional semantics not present in the udev rules.
Maybe the introduction of new semantics (lordy!,
more complication) tailored to the problems of
persistent devices could address the issues raised?

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                  -- Robert A. Heinlein

Re: generation of persistent network devices rules at install time

[Marco d'Itri]

On Jul 29, "Karl O. Pinc" <kop@meme.com> wrote:

> Maybe the introduction of new semantics (lordy!,
> more complication) tailored to the problems of
> persistent devices could address the issues raised?
No.

-- 
ciao,
Marco

Re: generation of persistent network devices rules at install time

[Marco d'Itri]

On Jul 29, Bryan Kadzban <bryan@kadzban.is-a-geek.net> wrote:

> In LFS (not that we're a distro, but whatever), after floundering around
> for several months and almost ten udev versions, we finally settled on
> using udevadm test.  (At least for the moment.)  Works with kernels >This is still suboptimal since it triggers other RUN rules...

-- 
ciao,
Marco

Re: generation of persistent network devices rules at install time

[Kay Sievers]

On Tue, Jul 29, 2008 at 12:23, Marco d'Itri <md@linux.it> wrote:
> On Jul 29, Bryan Kadzban <bryan@kadzban.is-a-geek.net> wrote:
>
>> In LFS (not that we're a distro, but whatever), after floundering around
>> for several months and almost ten udev versions, we finally settled on
>> using udevadm test.  (At least for the moment.)  Works with kernels >> This is still suboptimal since it triggers other RUN rules...

RUN does not get executed by udevadm test, but IMPORT and PROGRAM need
to run, otherwise you have nothing to test in most cases.

Maybe we should add a new command for that case, using "test" seems a
bit dangerous, if we might change the way it works.

Kay

Re: generation of persistent network devices rules at install time

[Bryan Kadzban]

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

Kay Sievers wrote:
> Maybe we should add a new command for that case, using "test" seems a
> bit dangerous, if we might change the way it works.

That's the biggest reason that it's an abuse of udevadm.

Another command would be nice, assuming this is its whole reason for
existing.  ;-)  It would be implemented a lot like test is now, I think,
and it could maybe even use most of the same code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIjvtQS5vET1Wea5wRA/akAJ9WhGNwPGgU9bmj6te6iUGIMvTv/gCgnViy
qM5w07cuJsFwtOU6c8cXVGc=qlE0
-----END PGP SIGNATURE-----