Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> What I'm using right now is:
>>
>> # Ignore Xen virtual interfaces
>> if [ -e /proc/xen ]; then
>> msg="The rules file should not be created in the Xen environment"
>> usage
>> fi
>>
>> I'm not sure if that is right or not. Someone with Xen needs to verify.
>
> Hmm, I don't know much about how Xen actually works for network devices,
> but I can see two ways to do it in general.
>
> First, it could provide exclusively virtual NICs, with effectively
> random MAC addresses at each boot. (Like qemu does AFAIK.) It would use
> tun/tap or something like that to get out to the real network. But
> second, it could provide access to the host's NIC directly to the VM,
> intercepting the actual hardware MMIO operations and watching to make
> sure the VM<->VM isolation is maintained.
>
> If it does only the first, then your method seems like it should work --
> if Xen is running at all, then refuse to write a rules file. But if it
> ever does the second, then the script will have to filter out interface
> by interface, which ones are OK and which ones are not.
>
> The latter (filtering by interface) is what the current rules do, but of
> course that doesn't mean that's the only way to successfully do it.
>
> Anyone run Xen? Should we just try it and see what happens? :-)
It doesn't seem very likely to me that any virtual system would have
more than one virtual NIC. What would be the purpose? The only reason
for the pre-boot installation of network rules is for something like a
server that has multiple NICs on a single card or the motherboard.
That's not a VM scenario.
Actually, the only reason I can think of for pre-boot network rules is
when building remotely where you don't have physical access to the
hardware AND that system has more than one physical network interface.
Otherwise, I can't think of a reason why eth0 would not work for setting
a static IP address.
>> I did find
>>
>> NIC=/sys/class/net/eth0
>> $ basename $(readlink -f $NIC/device/subsystem)
>> pci
>>
>> but I'm not sure how robust that is.
>
> That matches the current libudev code FWIW. In libudev-device.c,
> udev_device_get_subsystem, it caches the subsystem string per device,
> and the way it finds it the first time is by reading the "subsystem"
> symlink (util_get_sys_core_link_value(<udev>, "subsystem", <...>), and
> the code in libudev-util.c shows that doing a readlink() and then some
> string manipulation to do "basename").
OK, that seems to be good then.
>> I'm going to post a new tarball in a few minutes after I finish some
>> testing. Take a look at that.
>
> Are the sources for this tarball in a source control repository
> somewhere? I might have missed where, in the discussion earlier when it
> was being created. I don't see them in the book repository, but that
> repository may not be the best place to keep track of them, either.
No, they are not in a repository, although we could put them in the LFS
svn as, say LFS/trunk/udev-lfs/. What I have been doing is creating the
tarballs and uploading to anduin. I then put that link into the book
or, at this stage, post to the list.
> Anyway, an alternative patch to add indirection to the ifup / ifdown
> scripts is attached.
>
> It needs to add 2 lines to udev-config; one to run the path_id builtin
> on network-subsystem devices, and the other to pull attr{address} into
> the udev database (ENV{ID_ADDRESS} is what I used, but the name doesn't
> matter that much).
>
> The biggest change (in line count) is to the init-functions script; this
> is the central part of the dereferencing, and is used by both ifup and
> ifdown. It handles both mac-based and path-based "persistence", so it
> should handle real physical (broken :-) ) devices whose MAC changes for
> some reason, somewhat better than today, if the user decides to go with
> path-based config and they don't move the device. It will also handle
> replacing a network card, if the new card goes in the same slot that the
> old one came out of.
>
> The boilerplate to call dereference_network_device and use its output
> (on both the main interface and the INTERFACE_COMPONENTS list; no point
> in being able to create br0 if you can't control which physical NIC or
> NICs go into it) is in both ifup and ifdown.
>
> The service scripts are unchanged; $1 and $IFACE are still the interface
> to bring up (though see below). This is tested with ipv4-static and
> dhcpcd (though the dhcpcd script might be older than what we have in
> blfs), plus a service script I wrote for wake on LAN.
>
> HOWEVER: I have *not* tested any bridging (though I believe that should
> work), or much else that's very complicated. I also don't know why $1 is
> separate from $IFACE, with $IFACE being required in every service config
> file; this information was duplicated in the filename before. It's no
> longer required today (and in fact will be overwritten to the interface
> found by udev, if set).
>
> It's possible that $IFACE doesn't mean what I think it means, but if so,
> I think this should continue to work if a system still has ifconfig.ethX
> config files (they get "dereferenced" to ethX directly if
> /sys/class/net/eth* exists).
>
> People who know the service file interface better than I do -- help?
> :-)
When I rewrote the network scripts, I wanted to explicitly remove any
link between the filename and the network device. For instance a
filename of ifconfig.world and ifconfig.internal would work fine.
Adding a device to a bridge device like br0 created a lot more
complications, but by the time that happens, the admin should know what
devices he has. I don't see that as a requirement for setting the
persistent net rules before the first boot.
I'm generally in favor of keeping things as simple as possible. Adding
a level of indirection is not simple. Perhaps we could add this as an
alternative in a contrib section, but I don't see it needed by most LFS
users.
Would you please explain the scenario where you think this indirection
would be useful?
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
