Re: systemd - standard place to run stuff after the network is up?
On Thu, 2011-10-20 at 21:22 +0200, Nicolas Mailhot wrote: Le jeudi 20 octobre 2011 à 13:08 -0500, Dan Williams a écrit : If you architect a system that accounts for networking changing states, then it works for *everyone*. If you depend on networking always being there, then it only works for some subset of users that have one type of installation. Having one architecture and one codebase (that handles both cases) generally means easier maintenance, feature addition, and fewer bugs. Really, the problem with hardware handling changes in Fedora those past years is not improved handling of changing states (which benefit every kind of system), it's the way all those changes have been progressively tied with the desktop session, and all the efforts to shut down everything when no one is moving the local mice, or to make every scenario single-device stopping the old one when a new 'better' one appears. Note that NM has done multiple active devices for 3+ years... really, really old versions (0.6 and earlier) only allowed one active interface, but that was long ago fixed. Dan Servers, desktops and permanent set-top boxes can have transient network links too (typically, when a transient secure link has been established from an admin node somewhere), but the way those transient links is used is very different from the way laptop transient links are used (move everything from wifi to cable and back when ethernet is plugged/unplugged) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Mon, Oct 17, 2011 at 07:10:04PM +0200, Lennart Poettering wrote: In general doing something like this is a bit backwards since networks come and go and come and go in todays world, and we also don't want to This seems like a very desktop-focused view of things. I appreciate that that's important, but please keep the server room in mind as well. In our environment, the network is like electricity -- if it's down, nothing is running. Having the software designed to be robust against unexpected network glitches is very useful, but if design decisions are constantly made with the assumption that networks are a random transient resource, we'll end up conceding our place in the data center in exchange for an incredibly tiny slice of the desktop pie. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Thu, 2011-10-20 at 07:46 -0400, Matthew Miller wrote: On Mon, Oct 17, 2011 at 07:10:04PM +0200, Lennart Poettering wrote: In general doing something like this is a bit backwards since networks come and go and come and go in todays world, and we also don't want to This seems like a very desktop-focused view of things. I appreciate that that's important, but please keep the server room in mind as well. In our environment, the network is like electricity -- if it's down, nothing is running. Having the software designed to be robust against unexpected network glitches is very useful, but if design decisions are constantly made with the assumption that networks are a random transient resource, we'll end up conceding our place in the data center in exchange for an incredibly tiny slice of the desktop pie. From what I've seen, Lennart has always said that things should simply be designed to behave robustly in the absence of the network; I don't think any of his recommendations have ever required a _compromise_ in performance in the case where the network is present. They're often slightly new and different ways of doing things which come with an initial mental 'cost' in terms of grokking the idea and re-writing code to account for it, but I haven't seen him yet suggest a design where the final result would be code that behaved less well in a case where the network is almost always present. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
Le jeudi 20 octobre 2011 à 13:08 -0500, Dan Williams a écrit : If you architect a system that accounts for networking changing states, then it works for *everyone*. If you depend on networking always being there, then it only works for some subset of users that have one type of installation. Having one architecture and one codebase (that handles both cases) generally means easier maintenance, feature addition, and fewer bugs. Really, the problem with hardware handling changes in Fedora those past years is not improved handling of changing states (which benefit every kind of system), it's the way all those changes have been progressively tied with the desktop session, and all the efforts to shut down everything when no one is moving the local mice, or to make every scenario single-device stopping the old one when a new 'better' one appears. Servers, desktops and permanent set-top boxes can have transient network links too (typically, when a transient secure link has been established from an admin node somewhere), but the way those transient links is used is very different from the way laptop transient links are used (move everything from wifi to cable and back when ethernet is plugged/unplugged) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Thu, 2011-10-20 at 21:22 +0200, Nicolas Mailhot wrote: Le jeudi 20 octobre 2011 à 13:08 -0500, Dan Williams a écrit : If you architect a system that accounts for networking changing states, then it works for *everyone*. If you depend on networking always being there, then it only works for some subset of users that have one type of installation. Having one architecture and one codebase (that handles both cases) generally means easier maintenance, feature addition, and fewer bugs. Really, the problem with hardware handling changes in Fedora those past years is not improved handling of changing states (which benefit every kind of system), it's the way all those changes have been progressively tied with the desktop session, and all the efforts to shut down everything when no one is moving the local mice, or to make every scenario single-device stopping the old one when a new 'better' one appears. This is very vague and generally seems like an attempt to attack as much as possible without providing any specifics that can be discussed. Specifically, though, I see and all the efforts to shut down everything when no one is moving the local mice, which reads like a reference to the recent 30-minute suspend timeout, which for about the fiftieth time *was simply a bug in a gsettings schema*, nothing more sinister. It's already been fixed. Please stop referring to it as if it's some sort of Grand Conspiracy. It is not. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
Le jeudi 20 octobre 2011 à 12:27 -0700, Adam Williamson a écrit : On Thu, 2011-10-20 at 21:22 +0200, Nicolas Mailhot wrote: Le jeudi 20 octobre 2011 à 13:08 -0500, Dan Williams a écrit : If you architect a system that accounts for networking changing states, then it works for *everyone*. If you depend on networking always being there, then it only works for some subset of users that have one type of installation. Having one architecture and one codebase (that handles both cases) generally means easier maintenance, feature addition, and fewer bugs. Really, the problem with hardware handling changes in Fedora those past years is not improved handling of changing states (which benefit every kind of system), it's the way all those changes have been progressively tied with the desktop session, and all the efforts to shut down everything when no one is moving the local mice, or to make every scenario single-device stopping the old one when a new 'better' one appears. This is very vague and generally seems like an attempt to attack as much as possible without providing any specifics that can be discussed. No, it's an attempt to explain a general concept and not to point the finger at anyone. Because as soon as you provide specifics, someone will feel offended, get defensive, and refuse to listen to the general message. There's been a huge loss in communication on this list in the past years when people started making everything personnal and it got difficult to discuss a point without being accused of not being nice with X or Y¹. Please stop trying to read nefarious intent between the lines and read what's been actually written. ¹ For whatever value of X or Y again I didn't write X or Y so you could play games putting names here -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Thu, Oct 20, 2011 at 11:51 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: No, it's an attempt to explain a general concept and not to point the finger at anyone. Because as soon as you provide specifics, someone will feel offended, get defensive, and refuse to listen to the general message. I'd honestly like to know the specific usage case that is problematic for you. From the information so far presented I don't have a good understanding of what the network topology looks like nor how you expect traffic to be dynamically rerouted as your network node (in your terminology) becomes or is no longer available on a dynamic basis. -jefIf it helps, you could write up the specifics as an xml specification. Cuz, We all know that xml is the most impersonal form of communication as its designed to be read primarily by emotionless computers and not by peoplespaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
Le jeudi 20 octobre 2011 à 11:59 -0800, Jef Spaleta a écrit : On Thu, Oct 20, 2011 at 11:51 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: No, it's an attempt to explain a general concept and not to point the finger at anyone. Because as soon as you provide specifics, someone will feel offended, get defensive, and refuse to listen to the general message. I'd honestly like to know the specific usage case that is problematic for you. From the information so far presented I don't have a good understanding of what the network topology looks like nor how you expect traffic to be dynamically rerouted as your network node (in your terminology) becomes or is no longer available on a dynamic basis. On a pure client device I expect the system to sort between the available connexions (as they come and go) activate only the one with the best price/performance (price can be power of metered access vs unlimited access, performance can be bandwidth, latency or security) and route everything through this connexion. And eventually to shut everything down when there's no one in front of the client On anything more complex a new connexion will usually be established in addition to the existing ones, and will have a specific pre-set configuration. For example, a port can be dedicated to guest systems, or communication with specific networked devices, or external access, etc Setting up the new connexion does not involve moving the existing configuration to the new connexion but remembering the rules that apply with this connexion is live/plugged/powered up (and in the case of guest access firing dhcp relay or a dedicated dhcp daemon). It's just too convenient for human beings to associate a specific physical connexion with specific rules. In both scenarii one needs to manage transient networks, but the way they are managed is very different I used client here and not desktop because a desktop interface can (and will often) exist on the second kind of system too. And because I think as soon as batteries and power management improve enough, there will be mobile systems of the second kind too. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Thu, Oct 20, 2011 at 12:26 PM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: On anything more complex a new connexion will usually be established in addition to the existing ones, and will have a specific pre-set configuration. For example, a port can be dedicated to guest systems, or communication with specific networked devices, or external access, etc Setting up the new connexion does not involve moving the existing configuration to the new connexion but remembering the rules that apply with this connexion is live/plugged/powered up (and in the case of guest access firing dhcp relay or a dedicated dhcp daemon). It's just too convenient for human beings to associate a specific physical connexion with specific rules. And NM's dispatcher.d capability doesn't allow you to define and remember per connection rules of the complexity you need? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
Le jeudi 20 octobre 2011 à 12:40 -0800, Jef Spaleta a écrit : And NM's dispatcher.d capability doesn't allow you to define and remember per connection rules of the complexity you need? The problem is mostly integration with networked apps, which are either of the 'network can be up or not, if it's up always do foo' kind, or the 'can manage multiple networks, but expects all of them to exist at startup'. There is a dearth of 'can manage multiple networks, that can appear or disapper at any time' apps Though I suppose they could be simulated with apps of the second kind, connected to permanent local or virtual networks, dynamically routed to actual external networks via dispatcher.d, but at this point that gets too hairy for my tastes -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Thu, Oct 20, 2011 at 1:03 PM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: The problem is mostly integration with networked apps, which are either of the 'network can be up or not, if it's up always do foo' kind, or the 'can manage multiple networks, but expects all of them to exist at startup'. There is a dearth of 'can manage multiple networks, that can appear or disapper at any time' apps Are these unspecified applications (I refuse to call them apps, Fedora hasn't turned into a cellphone OS just yet) proprietary or do you have specific applications in our repositories right now that you are trying to work in a dynamic networking environment that you can point me to so I can experience the problem first hand by pulling my wired network cable and watching how a particular reference application fails? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Mon, Oct 17, 2011 at 19:10:04 +0200, Lennart Poettering mzerq...@0pointer.de wrote: So, while my first response to this would be the suggestion to improve the sw in question to make it more robust to today's dynamic networking I do acknowledge that this is not always feasible. So here's what you can do instead: Yeah it would be nice if netconsole allowed you to specify a network interface in advance of it being up. Write a tiny service file /etc/systemd/system/foobar.service: Thanks for the suggestions. I need to get more familiar with systemd scripts for some other stuff as well. Snippets like this provide a way to learn about it in bits and pieces and not have to digest everything at once. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Thu, 20.10.11 07:46, Matthew Miller (mat...@mattdm.org) wrote: On Mon, Oct 17, 2011 at 07:10:04PM +0200, Lennart Poettering wrote: In general doing something like this is a bit backwards since networks come and go and come and go in todays world, and we also don't want to This seems like a very desktop-focused view of things. I appreciate that that's important, but please keep the server room in mind as well. In our environment, the network is like electricity -- if it's down, nothing is running. Having the software designed to be robust against unexpected network glitches is very useful, but if design decisions are constantly made with the assumption that networks are a random transient resource, we'll end up conceding our place in the data center in exchange for an incredibly tiny slice of the desktop pie. If software can deal with networks changing then this benefits everybody, regardless which use case you have, i.e. whether it's a server, a desktop, a laptop, a tablet or whatever else. While network configuration is fairly static for servers, and very dynamic for tablets, it's not a binary thing, and you get everything in between too. Note that while servers seldom move physically, the network configuration might still change from time to time. If we make our software robust to deal with network changes, then we make its usage on servers more robust as well for the cases where the admin accidentaly trips of a cable, or he readjusts the wiring, or he renumbers his hosts, or renames, them or moves them to a different domain, or introduces a new DNS server, and so on, and so on. And that writing software that can deal with network changes is a good thing and doesn't make it useless for the server use case you can see by looking at bind, a service that much of the internet is running on and that is running in numerous enterprises, and that since a long long time listens to netlink and readjusts itself to network configuration changes. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On 10/17/2011 10:20 AM, Bruno Wolff III wrote: I want to try to modprobe netconsole during boot, but it needs to happen after the network is up. Is there any standard place (rc.local and modules-load seem to happen too early) to do this? I filed https://bugzilla.redhat.com/show_bug.cgi?id=746481 against systemd, but it has been closed notabug. So I am looking for simple alternatives to do this. If there aren't any, then it looks like I need to make a custom service that waits for networking to be up. FWIW, I have been struggling with this for awhile. And now, in what seems like magic, it is working fine in rawhide but not in F16 (tho it does in maybe 1 in 20 boots). I followed the procedure in https://fedoraproject.org/wiki/Netconsole. Since the e-net card is renamed to a local bus name (p37p1 in my case), specifying eth0 in the netconsole parms wasn't working and systemd was reporting an error and specifying p37p1 wasn't working since the device was eth0 at the time. Since updating systemd to systemd-37-1.fc17.x86_64, specifying eth0 now works nicely to start netconsole logging well before NetworkManager does its thing and I still get a eth0 network using NetworkManager. Before the systemd update, I would see the following in dmesg: ... [ 12.732929] netconsole: local port [ 12.734575] netconsole: local IP 192.168.0.10 [ 12.735906] netconsole: interface 'eth0' [ 12.737225] netconsole: remote port [ 12.738535] netconsole: remote IP 192.168.0.11 [ 12.739846] netconsole: remote ethernet address 00:1d:60:e5:ee:55 [ 12.741201] netconsole: eth0 doesn't exist, aborting. [ 12.742528] netconsole: cleaning up [ 12.74] mtp-probe[909]: checking bus 8, device 4: /sys/devices/pci:00/:00:1d.2/usb8/8-2/8-2.4 [ 12.749445] mtp-probe[872]: checking bus 2, device 2: /sys/devices/pci:00/:00:1d.7/usb2/2-5 [ 12.751298] mtp-probe[912]: checking bus 8, device 3: /sys/devices/pci:00/:00:1d.2/usb8/8-2/8-2.1 [ 12.752693] fedora-loadmodules[747]: FATAL: Error inserting netconsole (/lib/modules/3.1.0-0.rc8.git0.1.fc16.x86_64/kernel/drivers/net/netconsole.ko): No such device [ 12.754183] systemd[1]: fedora-loadmodules.service: main process exited, code=exited, status=1 [ 12.773096] systemd[1]: Unit fedora-loadmodules.service entered failed state. ... -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Mon, 17.10.11 09:20, Bruno Wolff III (br...@wolff.to) wrote: I want to try to modprobe netconsole during boot, but it needs to happen after the network is up. Is there any standard place (rc.local and modules-load seem to happen too early) to do this? Well, yes and no. In general doing something like this is a bit backwards since networks come and go and come and go in todays world, and we also don't want to make normal system bootup dependent on external circumstances such as a DHCP server responding or so, if we can avoid it. So, while my first response to this would be the suggestion to improve the sw in question to make it more robust to today's dynamic networking I do acknowledge that this is not always feasible. So here's what you can do instead: Write a tiny service file /etc/systemd/system/foobar.service: snip [Unit] After=network.target [Service] ExecStart=... /snip Then symlink it to /etc/systemd/system/multi-user.target.wants/. (That all assuming this is just something to use locally. If you want something you can stick in an RPM add an [Install] section with WantedBy=multi-user.target to the above, and move the unit file from /etc to /lib, and create the symlink with systemctl enable. Also, addding a Description= in [Unit] would be cool too). Note that you might still need to enable NetworkManager-wait-online.servce with systemctl enable so that bootup is delayed until NM configured a network. (more precisely: delay network.target until NM configured a network). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Mon, 2011-10-17 at 19:10 +0200, Lennart Poettering wrote: On Mon, 17.10.11 09:20, Bruno Wolff III (br...@wolff.to) wrote: I want to try to modprobe netconsole during boot, but it needs to happen after the network is up. Is there any standard place (rc.local and modules-load seem to happen too early) to do this? Well, yes and no. In general doing something like this is a bit backwards since networks come and go and come and go in todays world, and we also don't want to make normal system bootup dependent on external circumstances such as a DHCP server responding or so, if we can avoid it. So, while my first response to this would be the suggestion to improve the sw in question to make it more robust to today's dynamic networking I do acknowledge that this is not always feasible. So here's what you can do instead: Write a tiny service file /etc/systemd/system/foobar.service: snip [Unit] After=network.target [Service] ExecStart=... /snip Then symlink it to /etc/systemd/system/multi-user.target.wants/. (That all assuming this is just something to use locally. If you want something you can stick in an RPM add an [Install] section with WantedBy=multi-user.target to the above, and move the unit file from /etc to /lib, and create the symlink with systemctl enable. Also, addding a Description= in [Unit] would be cool too). Note that you might still need to enable NetworkManager-wait-online.servce with systemctl enable so that bootup is delayed until NM configured a network. (more precisely: delay network.target until NM configured a network). If this is done does it mean a potentially high number of services is started only after a user logged in and attached to a wireless spot ? Or will NetworkManager-wait-online.servce wait only for networks marked as to be enable on boot ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On Mon, 17.10.11 13:21, Simo Sorce (s...@redhat.com) wrote: Note that you might still need to enable NetworkManager-wait-online.servce with systemctl enable so that bootup is delayed until NM configured a network. (more precisely: delay network.target until NM configured a network). If this is done does it mean a potentially high number of services is started only after a user logged in and attached to a wireless spot ? I am quite sure it does not wait for network ifaces which need user interaction to work, and it will not wait for network interfaces which haven't shown up yet (which makes the whole thing racy, which is another reason why this is borked), and it will time out after 45s or so. I am sure dcbw knows all the details. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - standard place to run stuff after the network is up?
On 10/17/2011 01:10 PM, Clyde E. Kunkel wrote: On 10/17/2011 10:20 AM, Bruno Wolff III wrote: I want to try to modprobe netconsole during boot, but it needs to happen after the network is up. Is there any standard place (rc.local and modules-load seem to happen too early) to do this? I filed https://bugzilla.redhat.com/show_bug.cgi?id=746481 against systemd, but it has been closed notabug. So I am looking for simple alternatives to do this. If there aren't any, then it looks like I need to make a custom service that waits for networking to be up. FWIW, I have been struggling with this for awhile. And now, in what seems like magic, it is working fine in rawhide but not in F16 (tho it does in maybe 1 in 20 boots). I followed the procedure in https://fedoraproject.org/wiki/Netconsole. Since the e-net card is renamed to a local bus name (p37p1 in my case), specifying eth0 in the netconsole parms wasn't working and systemd was reporting an error and specifying p37p1 wasn't working since the device was eth0 at the time. Since updating systemd to systemd-37-1.fc17.x86_64, specifying eth0 now works nicely to start netconsole logging well before NetworkManager does its thing and I still get a eth0 network using NetworkManager. ... Well, spoke too soon, seems I had a run of good luck with netconsole loading early. No longer true. Need to figure out how to get this working: $ systemctl status fedora-loadmodules.service fedora-loadmodules.service - Load legacy module configuration Loaded: loaded (/lib/systemd/system/fedora-loadmodules.service; static) Active: failed since Mon, 17 Oct 2011 13:36:20 -0400; 16min ago Process: 632 ExecStart=/lib/systemd/fedora-loadmodules (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/fedora-loadmodules.service Sorry for the noise. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
