[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: scripts and Alternate Root

Circa 2003-01-04 08:12:41 -0800 dixit Kenneth Porter:

: --On Saturday, January 04, 2003 12:12 PM +0100 Rob van der Heij 
: <rvdheij@iae.nl> wrote:
: >The install scripts with some packages are causing me problems in some
: >cases. From what I see they deal with both changes to the files (e.g. add
: >a new user) and doing things to the running system (e.g. start daemons).
: >Obviously I don't want services to be started off that chrooted system. I
: >could run with --noscripts but then I miss required updates.
: Interesting issue. I suppose that things like user-adds should really be 
: done by initscripts and not by %posts. (Sorta like Mozilla's practice of 
: using an intermediary start script to run first-time stuff on behalf of a 
: user.)

Or by separate setup tools that the administrator can run before
enabling a service.  Debian's dpkg/apt system gets this right via a
sort of "configure" stage of package installation (that can
incidentally be run interactively).

There are several points of view regarding starting or restarting
services from within RPM packages.  I myself think it's rather obvious
that services should never be started from within a %post scriptlet;
others may differ.  Whether services should be restarted (only if they
are running on the target system) during an upgrade is a matter of
system policy that ideally ought to be tunable by the administrator.
However, most current Linux systems don't have a reliable method of
telling whether a service is actually running on the target system
(pidfiles in /var/run/ are not a reliable method).  DJB's daemontools
(http://cr.yp.to/daemontools.html) seem to provide useful methods
here[*], but they are unfortunately not in wide use.

Stopping services inside %preun can be even more problematic.  Stopping
a critical services such as sshd could cause an administrator's remote
session to go away (and even abort the package uninstall, if the
command is not SIGHUP-proofed); yet, after the uninstall is complete,
there are generally no initscripts around for the administrator to use
to stop the service manually.  Additionally, if you're installing in a
chrooted environment (i.e., on a filesystem other than the one
belonging to the running system), then how do you know you're stopping
the right service?

Again, DJB's daemontools provide some measure of help here.[**]

: But what about user removals? Where would you put them? How would 
: you know that you're running the script on the target or a separate
: host?

It's probably not a good idea to actually remove users or groups
anyway, since there may well be files on the system---or on system
backups---owned by those users, as well as references to them in
logfiles, system databases, etc.  As long as daemon users are properly
set up (login shell is /sbin/nologin or /dev/null, home directory is /
or some other directory they have no control over, password is locked),
there shouldn't be any problem leaving the users/groups in the
password/group databases.


[*]  'supervise' and the 'svc' tool use named pipes to communicate,
     which is automatically handled in a chrooted environment---if no
     process is listening on the pipe, no service is restarted.

[**] The 'run' scripts and other directory structure under
     /service/sshd (for example) are not generally owned by the
     package, but are created either by a setup tool or by hand; thus,
     they still exist after the package is removed, and critical
     services such as sshd can be stopped manually.

jim knoble  |  jmknoble@pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
"I am non-refutable."  --Enik the Altrusian

Attachment: pgp00004.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []