Red Hat Bugzilla – Bug 54042
Support for "live" network (dis)connect + user control of networked services
Last modified: 2015-01-04 17:01:27 EST
We are using Red Hat Linux 7.0 or 7.1 on a number of laptops. These are sometimes connected to our office network, sometimes not. When connected, we also want to run services like "netfs" and "ypbind" to access data on our servers. The problem is that this really requires a re-boot and/or manual intervention as super user after the machines are connected to or disconnected from the network. We don't want that, we want the users to be able to boot the machines stand-alone, then connect to the network and access server data, or vice versa (i.e. boot with network, then disconnect and continue working "off-line".) Actually, the PCMCIA card logic means that this very nearly works, but there is one major problem: The card is already gone when the eject signal iis received, so it is really to late to stop the network then. Another work-around is to suspend the machine before connecting or disconnecting, then resuming, but that's not an ideal solution, of course, and there's also the problem reported as bug 54041.
Created attachment 32640 [details] Program for user startup/shutdown of network services
I've also impelmented a partial solution in the form of a C++ program that can be executed by the user (with "start" or "stop" arguments) to start or stop network (or "intranet", if you like, services.) The source code is attached to this report. The binary has to be installed as "setuid root." I'm not sure if I like this solution, though. I guess my main objection is really that it's non-standard, but better integration with chkconfig etc. is also needed, and the setuid requirement is of course a problem.
this is not a trivial problem. PCMCIA only gives a notify when it's basically too late (that's hardware issue); making any kind of "button" on the users' desktop as to allow the user to give notive will need to be a suid program.....
I have a similar setup, I use NFS mounts and such things when I have the network connected and I bring them down when I disconnect the network. Ejecting the card of course does not work, because when pcmcia gets a chance to notify the system the card is not there (hardware problem, since eject is manual). My solution is to issue "cardctl eject" before ejecting the card. Since that needs root privileges I use a "console app". For that I do ln -s consolehelper /usr/bin/cardctl touch /etc/security/console.apps/cardctl and put the following in /etc/pam.d/cardctl #%PAM-1.0 auth sufficient /lib/security/pam_rootok.so auth required /lib/security/pam_console.so account required /lib/security/pam_permit.so That way, any user with "console privileges" (user logged locally or root) can bring down the network. Then just add whatever service adjustments commands you require in /sbin/ifup-local and /sbin/ifdown-pre-local. It's important to use the "pre" for the down event, otherwise any actions will be taken when the network interface is already down.
Created attachment 60944 [details] New version of (setuid root) connect/disconnect app
Created attachment 60945 [details] Applet wrapper for connect/disconnect
Created attachment 60946 [details] GDM session script (install as Intranet or Standalone under /etc/X11/gdm/Sessions)
I've had another look at this now (my C++ program attached earlier has been used in the meantime), and it seems to me that my setup with two different modes is the way to go. One of the reasons is that the users may want to log in with local user (no NIS login, home directory on local disk) even when they are connected to the network (so it's not just a matter of stopping services on network shutdown.) So I've now extended the scheme a bit; an updated version of the "intranet" utility has been attached, along with a GNOME applet that can be used to execute it. There is also a session script for gdm, which when selected via the "Session" menu will start or stop the appropriate services, depending on the name it's installed under, then update HOME variable etc. and execute a different session. Note that all users have one NIS account with a home directory on an NFS-shared volume, and one registered in /etc/passwd that has a home directory on the local disk. NIS accounts will be preferred if available. I'm starting to like the functionality of all this, although I've thought about implementing it differently. For instance, "sudo" or similar could be used instead of a setuid program. And the configuration should perhaps be integrated with chkconfig and/or runlevels. Maybe we could have Runlevel 4 = Runlevel 2 with X11?
Created attachment 60964 [details] Alternate implementation of "intranet" tool
And here is a version of "intranet" that will use runlevels instead of executing init scripts directly. It relies on the correct script setup, of course, and also requires xdm service in level 4. The following RPM triggers from my experimental package for the utility should make the most important changes: %triggerin -n %{name}-laptop -- initscripts perl -pi -e 's/^x:5:/x:45:/; s/# 4 - .*/# 4 - level 2 + X11/' /etc/inittab %triggerun -n %{name}-laptop -- initscripts if [ $1 = 0 -a $2 != 0 ] then perl -pi -e 's/^x:45:/x:5:/; s/# 4 - .*/# 4 - unused/' /etc/inittab fi %triggerin -n %{name}-laptop -- ypbind, nfs-utils, initscripts for service in ypbind nfs nfslock netfs do initScript="/etc/init.d/$service" if [ -r $initScript ] then perl -pi -e 's/#\s*chkconfig:\s*(345|-)+\s+([0-9]+)\s+([0-9]+)/# chkconfig: 35 $2 $3/' $initScript fi # Note: Need to "reset" service to make sure "off" scripts are there if chkconfig --level 5 $service then state="on" else state="off" fi /sbin/chkconfig $service reset /sbin/chkconfig --level 5 $service $state done
closing ancient bug against end-of-life distro. If this is still a problem in current distributions, I'd suggest opening a bug against a component like network-manager