Bug 54042 - Support for "live" network (dis)connect + user control of networked services
Summary: Support for "live" network (dis)connect + user control of networked services
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-09-26 14:38 UTC by Toralf
Modified: 2015-01-04 22:01 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-11-27 22:43:53 UTC
Embargoed:


Attachments (Terms of Use)
Program for user startup/shutdown of network services (1.27 KB, text/plain)
2001-09-26 14:43 UTC, Toralf
no flags Details
New version of (setuid root) connect/disconnect app (1.98 KB, text/plain)
2002-06-14 07:10 UTC, Toralf
no flags Details
Applet wrapper for connect/disconnect (8.33 KB, text/plain)
2002-06-14 07:12 UTC, Toralf
no flags Details
GDM session script (install as Intranet or Standalone under /etc/X11/gdm/Sessions) (1.87 KB, text/plain)
2002-06-14 07:15 UTC, Toralf
no flags Details
Alternate implementation of "intranet" tool (2.48 KB, text/plain)
2002-06-14 12:21 UTC, Toralf
no flags Details

Description Toralf 2001-09-26 14:38:29 UTC
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.

Comment 1 Toralf 2001-09-26 14:43:32 UTC
Created attachment 32640 [details]
Program for user startup/shutdown of network services

Comment 2 Toralf 2001-09-26 14:48:57 UTC
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.

Comment 3 Arjan van de Ven 2001-09-26 15:10:04 UTC
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.....



Comment 4 diego.santacruz 2001-11-30 11:16:36 UTC
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.

Comment 5 Toralf 2002-06-14 07:10:10 UTC
Created attachment 60944 [details]
New version of (setuid root) connect/disconnect app

Comment 6 Toralf 2002-06-14 07:12:12 UTC
Created attachment 60945 [details]
Applet wrapper for connect/disconnect

Comment 7 Toralf 2002-06-14 07:15:08 UTC
Created attachment 60946 [details]
GDM session script (install as Intranet or Standalone under /etc/X11/gdm/Sessions)

Comment 8 Toralf 2002-06-14 07:32:28 UTC
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?


Comment 9 Toralf 2002-06-14 12:21:31 UTC
Created attachment 60964 [details]
Alternate implementation of "intranet" tool

Comment 10 Toralf 2002-06-14 12:28:31 UTC
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


Comment 11 Dave Jones 2004-11-27 22:43:53 UTC
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


Note You need to log in before you can comment on or make changes to this bug.