write_net_rules all_interfaces

write_net_rules all_interfaces

[Bryan Kadzban]

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

So this was removed in udev-114, in favor of a manual loop like:

for i in /sys/class/net/* ; do
    echo "add" >$i/uevent
done

or something similar.  At least, that's what I gather from the commit
message; I'm not quite sure if it's right or not.

This is fine, mostly.  The problem comes in when installing another
system into (and inside) a chroot from a running host, as we do in LFS.
With the all_interfaces hack (which, admittedly, was ugly), the script
would happily run from inside the chroot, without requiring anything
from the host's udevd.  (If the host was even running udevd.  It wasn't
required.)  And since the script wasn't being called as part of a real
uevent, it would avoid renaming any actual (host-owned!) interfaces.

How should we handle pre-generating the rules from a system when
chrooted to it?  (We need to pre-generate the rules because the user has
to be able to add config files by interface name, so they need to know
what the names will be.)

I suppose it might work to (1) kill the host's udevd, (2) start one up
inside the chroot system, (3) send the uevents, then (4) kill it off,
(5) restart it on the host, and (6) re-send the host's uevents again.
The issue with this is the user may be off the network between steps 3
and 6, depending on firewall rules and whatnot; if the system is being
installed via ssh, this isn't going to work.

Any suggestions?  Thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGyD4dS5vET1Wea5wRA8PmAJ0QyhzyOGboUtw41sQNgQrBUFNgRgCfT/TJ
MnTAyjfuCdx2brU+qNUji7I=u4Ub
-----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: write_net_rules all_interfaces

[Marco d'Itri]

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

> So this was removed in udev-114, in favor of a manual loop like:
> 
> for i in /sys/class/net/* ; do
>     echo "add" >$i/uevent
> done
> 
> or something similar.  At least, that's what I gather from the commit
> message; I'm not quite sure if it's right or not.
> 
> This is fine, mostly.
Not so fine actually, because this will cause spurious events which may
have unwanted side effects.
I agree that trying to duplicate the rules in the shell script is not
going to work in the long period, but the proposed solution has its own
set of problems as well.
So far my plan is to create temporary rules which will disable the RUN
rules while these events are triggered, but I still need to think about
the details.

>  The problem comes in when installing another
> system into (and inside) a chroot from a running host, as we do in LFS.
Debian has a similar problem, but I have not found a solution yet.
I do not consider starting a second udevd a valid solution.

-- 
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: write_net_rules all_interfaces

[Kay Sievers]

On 8/19/07, Marco d'Itri <md@linux.it> wrote:
> On Aug 19, Bryan Kadzban <bryan@kadzban.is-a-geek.net> wrote:
>
> > So this was removed in udev-114, in favor of a manual loop like:
> >
> > for i in /sys/class/net/* ; do
> >     echo "add" >$i/uevent
> > done
> >
> > or something similar.  At least, that's what I gather from the commit
> > message; I'm not quite sure if it's right or not.
> >
> > This is fine, mostly.
> Not so fine actually, because this will cause spurious events which may
> have unwanted side effects.
> I agree that trying to duplicate the rules in the shell script is not
> going to work in the long period, but the proposed solution has its own
> set of problems as well.

Oh, I didn't think of the need of pre-creating rules in a chroot. I
wanted to get rid of the duplicated device whitelist outside of the
rules.
If needed, we can add something back if it doesn't come with its own
device list and can also create the comments that come from the rules.

> So far my plan is to create temporary rules which will disable the RUN
> rules while these events are triggered, but I still need to think about
> the details.
>
> >  The problem comes in when installing another
> > system into (and inside) a chroot from a running host, as we do in LFS.
> Debian has a similar problem, but I have not found a solution yet.
> I do not consider starting a second udevd a valid solution.

Yeah, killing udevd sound like it could cause some trouble.

Maybe we need something that works like udevtest, which runs the rules
and PROGRAM and IMPORT, but not RUN:
  for i in $(udevtrigger -v -n --subsystem-match=net); do
    udevtest $i >/dev/null;
  done

It actually works and creates the rules file, but udevtest is nothing
we want to be part of anything than debugging. :)

Kay

-------------------------------------------------------------------------
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: write_net_rules all_interfaces

[Marco d'Itri]

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

> Would it work to have a "mode" of udevd that makes it ignore RUN keys,
> and also skip all the calls to rename_netif?  As long as it's running
This was my plan, but there is no need to add new code: you can use the 
the recently added support for temporary rules.

-- 
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: write_net_rules all_interfaces

[Bryan Kadzban]

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

Marco d'Itri wrote:
> On Oct 27, Bryan Kadzban <bryan@kadzban.is-a-geek.net> wrote:
> 
>> Would it work to have a "mode" of udevd that makes it ignore RUN
>> keys, and also skip all the calls to rename_netif?  As long as it's
> This was my plan, but there is no need to add new code: you can use
> the the recently added support for temporary rules.

I assume that means the support for honoring rules files that are in
/dev/.udev/rules.d (and all the ancillary stuff with inotify, etc.) from
commit 254d6d3ca2188a396706b363d0840431d360fbd9.

I also assume Debian has a way to pre-generate these files from inside a
chroot, right?  What should I be searching for to find that?  I haven't
been able to find anything obvious via Google, and it doesn't look like
it's part of the udev package itself (at least not 0.114-2).

If Debian doesn't have it, do you have any general idea of what it would
take to get it working?  Any method that I can think of runs afoul of
the requirement to keep only one udevd running (if it runs on the host,
then you can't write rules to the chroot from inside the chroot, and if
it doesn't run on the host, then there's no original problem: you can
just start it up inside the chroot).

Thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHJRvyS5vET1Wea5wRA3AQAJwPoQKDjbmMCdQCZo5ETe+RvwKoYACggHNp
RhZhpgYHsT1Eua8qqDyPPiA=Uikd
-----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