Re: Strange X11 Assersion
Philip Thiem [EMAIL PROTECTED] writes: Recently a friend made the assertion that I want to get some feed back on: if you connect to an x server you have access to the protocol stream of any other user also connected to it I believe that this is more or less correct. If you can connect to an X11 server, you can use either the RECORD, XTrap, or DEC-XTrap extensions to access the protocol stream. You can also take control of input devices using XTEST. There are some limits (eg, I think openGL/GLX stuff that goes through DRI won't get posted). -- /* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463 fax 422-9429 */ /* Computer Scientist, Advanced Simulation and Computing Program */ /* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Strange X11 Assersion
Philip Thiem [EMAIL PROTECTED] writes: Thanks for the clarification. I had posted that I thought it was FUD, but my language was _too_ strong. Yeah, that makes sense, but it was presented to me on such a wide scale, that it didn't make sense to me. The key is that random users shouldn't be allowed to connect to an Xservers. At a minimum you should be set up to use MIT-MAGIC-COOKIE, which is essentially a shared secret. If you are using host-based authentication (eg `xhost myhost`) then anyone on the authorized hosts can connect. If you do `xhost +` then everyone can connect. Would it be correct this this is about as severe, as have a root user at all. (Because the root password could be set to empty and them /proc/mem used to intercept other programs). An issue, but a manageable one (use a real password). Probably a little less severe. If an unwanted user connects to the xserver, they have probably only compromised the actual user of that Xserver, not root. Even though the Xserver runs as root it shouldn't allow users to fork/exec new processes or edit files. So the unwanted user can capture info from the actual user, and _maybe_ use XTEST to launch a process on behave of the actual user, but would need to use some other mechanism to extend the compromise to other accounts. As mentioned above, the solution is to make sure that unwanted users cannot connect to the X server. Make sure authorization is setup and use xauth rather than xhost. -- /* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463 fax 422-9429 */ /* Computer Scientist, Advanced Simulation and Computing Program */ /* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: raw disk access
Is the `dd` command what you are looking for (in combination with /dev/loop?), or is there some requirement that wasn't mentioned in your message? viv [EMAIL PROTECTED] writes: i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). -- /* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463 fax 422-9429 */ /* Computer Scientist, Advanced Simulation and Computing Program */ /* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */
Re: cups security
Luis Gómez Miralles [EMAIL PROTECTED] writes: El jue, 11-04-2002 a las 16:56, Torrin escribió: Good morning everybody, well at least morning over here in Cali. For everybody else, Good afternoon, good evening and good night. I just installed cups and I was wondering if it's possible to have cups run properly without having port 631 open. I don't like having ports open, especially since this computer will be the only one printing to this printer. I looked at some of the doc on http://www.cups.org and didn't see anything. Any ideas? Why don't you cut access to that port via tcp wrappers? At least in my Woody, cups is in inetd.conf: #:OTHER: Other services printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd cups-lpd (actually i'm not sure whether this corresponds to cups or to lpr) It corresponds to the cups server that accepts lpd jobs on port 515, which is an optional part of cups. The primary part of cups is a daemon that accepts IPP jobs (and serves html documentation) on port 631. so you could add printer: ALL BUT LOCAL [or something like that] to /etc/hosts.deny If you are not accepting lpd print jobs from other hosts, there is no reason I am aware of to run cups-lpd. Securing cups itself is done though the /etc/cups/cupsd.conf file. In particular, something like the following will limit access of the printers and documentation to localhost: Location / Order Deny,Allow Deny From All Allow From 127.0.0.1 /Location The cupsd.conf file has lots of goodies that are not turned on by default, including things like SSL/TLS certificates and crypto, restricting of the daemon binding, and lots of other hooks. The manuals are avaiable at http://localhost:631/ or at cups.org. route add -net 224.0.0.0 netmask 240.0.0.0 dev interface What's up with that? I didn't see anything in the doc about that either. Google for the term ``multicast'' and you'll find the answer. It has (to the best of my knowledge, nothing to do with CUPS. -- /* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463, fax 422-9429 */ /* Computer Scientist, Accelerated Strategic Computing Initiative */ /* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */ /* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cups security
Luis Gómez Miralles [EMAIL PROTECTED] writes: El jue, 11-04-2002 a las 16:56, Torrin escribió: Good morning everybody, well at least morning over here in Cali. For everybody else, Good afternoon, good evening and good night. I just installed cups and I was wondering if it's possible to have cups run properly without having port 631 open. I don't like having ports open, especially since this computer will be the only one printing to this printer. I looked at some of the doc on http://www.cups.org and didn't see anything. Any ideas? Why don't you cut access to that port via tcp wrappers? At least in my Woody, cups is in inetd.conf: #:OTHER: Other services printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd cups-lpd (actually i'm not sure whether this corresponds to cups or to lpr) It corresponds to the cups server that accepts lpd jobs on port 515, which is an optional part of cups. The primary part of cups is a daemon that accepts IPP jobs (and serves html documentation) on port 631. so you could add printer: ALL BUT LOCAL [or something like that] to /etc/hosts.deny If you are not accepting lpd print jobs from other hosts, there is no reason I am aware of to run cups-lpd. Securing cups itself is done though the /etc/cups/cupsd.conf file. In particular, something like the following will limit access of the printers and documentation to localhost: Location / Order Deny,Allow Deny From All Allow From 127.0.0.1 /Location The cupsd.conf file has lots of goodies that are not turned on by default, including things like SSL/TLS certificates and crypto, restricting of the daemon binding, and lots of other hooks. The manuals are avaiable at http://localhost:631/ or at cups.org. route add -net 224.0.0.0 netmask 240.0.0.0 dev interface What's up with that? I didn't see anything in the doc about that either. Google for the term ``multicast'' and you'll find the answer. It has (to the best of my knowledge, nothing to do with CUPS. -- /* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463, fax 422-9429 */ /* Computer Scientist, Accelerated Strategic Computing Initiative */ /* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */ /* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cups security summary
Torrin [EMAIL PROTECTED] writes: OK, in summary. 1. I should set it to listen only on the local interface by setting Listen 127.0.0.1:631 in the cupsd.conf file. 2. I should firewall off the port. This part is already done, I just don't like to have ports open. So from what people have said, I guess there isn't a way to run cups and close the port. Step 1 causes cups to bind to only to the loopback interface. After making the change, restart the cupsd and nmap scan your loopback (localhost) and public interfaces -- you shouldn't see 631 open on anything but the loopback. If you've done step 1, step 2 is redundant protection. There shouldn't be anything listening on 631 anyplace except loopback. Is the open port essential to it's operation, like open port 22 is essential to the operation of ssh? In any unix printing architecture, there has to be a way to get the client's data to the host's print server. In traditional lpr and lp, the client command copies or symlinks the data into the spool directory (which is why lp/lpr is usually SUID or SGID). In cups, the print data is transferred to the server via http protocol. This means the client program doesn't need any special privileges, but does require that the server be listening on a port somewhere. Which is ultimately a better idea from a security perspective is a matter of opinion and situation -- /* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463, fax 422-9429 */ /* Computer Scientist, Accelerated Strategic Computing Initiative */ /* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */ /* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh ip address
Eduardo J. Gargiulo [EMAIL PROTECTED] writes:
Hi all.
Is there any way to obtain the IP address of a ssh client and use it on
a shell script? I want to put a crontab like
ssh server script
but I need the IP address i'm connecting from in the shell script and
the address is assigned dynamically.
echo $SSH_CLIENT | awk '{print $1}'
or
echo $SSH2_CLIENT | awk '{print $1}'
--
/* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463, fax 422-9429 */
/* Computer Scientist, Accelerated Strategic Computing Initiative */
/* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */
/* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */
Re: Daemon init scripts and apt-get [was: Re: red worm amusement]
Marko Kreen marko@l-t.ee writes: If the ``do I run service X'' check is done in rcS it means that each init.d script is either on or off. This would eliminate the possibility of having more than one check in a script -- for example, it would be logical to configure the existing Debian networking script with chkconfig options for spoofprotect, syncookies, and ip_forward. This wouldn't be possible if the chkconfig is done in rcS. Well, rcS could do overall 'do I run anything from this package' check, then init script could check lesser variables, but maybe this gets confusing. I think it's easier (or at least more obvious) to put check in the init.d scripts. It also makes things optional -- package maintainers can add support for (and dependence on) chkconfig on an individual basis. IRIX actually leverages this significantly -- there are a dozen or so different chkconfig controls in the IRIX networking script used to enable/disable starting of things like nfs, autofs, timed, gated, etc. Well, we have basically one init script per package. Now I want state, that _nothing_ from this package gets started. Do I need examine the init script then one-by-one disable all vars? Nope, you would likely have a hierarchy of checks in scripts that start more than one service. To use IRIX as an example, chkconfig'ing ``gated'' won't prevent the other networking daemons from starting. But chkconfig'ing ``network'' off prevents all the networking daemons (including gated) from starting. This also allows logical dependencies among related init.d scripts -- for instance there's no point in starting a service that depends on portmap if portmap isn't running. With a chkconfig like system this type of dependence is as simple as two chkconfigs in an clause. As in Debian most of services are nicely split up, this should not matter. Yes and no. The init.d scripts are indeed much better split up in Debian than in IRIX. They need to be, since enabling/disabling a service under Debian is generally done by not installing it or adding/removing rc?.d links. IRIX doesn't need to split out services since the chkconfig system is available to control what is/isn't started. But in Debian there are still some individual options that require editing of init.d scripts to enable or disable (see the mountnfs.sh and networking scripts for examples). Whether or not this makes adding a system like chkconfig ``worth the trouble'' is another question :-) -- /* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463, fax 422-9429 */ /* Computer Scientist, Accelerated Strategic Computing Initiative */ /* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */ /* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */
Re: Daemon init scripts and apt-get [was: Re: red worm amusement]
Marko Kreen marko@l-t.ee writes: On Thu, Aug 09, 2001 at 12:38:52PM -0700, Dale Southard wrote: Marko Kreen marko@l-t.ee writes: Well, we have basically one init script per package. Now I want state, that _nothing_ from this package gets started. Do I need examine the init script then one-by-one disable all vars? Nope, you would likely have a hierarchy of checks in scripts that start more than one service. To use IRIX as an example, chkconfig'ing ``gated'' won't prevent the other networking daemons from starting. But chkconfig'ing ``network'' off prevents all the networking daemons (including gated) from starting. Hmm, currenctly such 'dependencies' are half-done using the SysV 'sequence numbers'. The sequence numbers correctly order the services (in both IRIX and Debian) , but don't actually do anything about disabling things with logical dependencies. Using the IRIX example, `chkconfig network off` turns an IRIX box into a clean standalone machine. In debian, one can remove an rc?.d symlink, but doing so in no way prevents daemons that depended on the service from starting. As in Debian most of services are nicely split up, this should not matter. Yes and no. The init.d scripts are indeed much better split up in Debian than in IRIX. They need to be, since enabling/disabling a service under Debian is generally done by not installing it or adding/removing rc?.d links. IRIX doesn't need to split out services since the chkconfig system is available to control what is/isn't started. But in Debian there are still some individual options that require editing of init.d scripts to enable or disable (see the mountnfs.sh and networking scripts for examples). Whether or not this makes adding a system like chkconfig ``worth the trouble'' is another question :-) Well, then we are on back on square one - how do we disable a service? As I said when I started this thread, IRIX style chkconfig is one option. Redhat style chkconfig is another (I'll admit being biased towards IRIX's implementation, but I've used both and it's useful to compare the two). A third would be some gui/cli for creating/deleting symlinks in the various rc?.d directories (but note that this option wouldn't survive updates). And of course, doing nothing, or something completely different is also an option. :-) If there is an interest in IRIX-style chkconfig, I can probably throw something together from the scripts and docs I have lying around -- /* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463, fax 422-9429 */ /* Computer Scientist, Accelerated Strategic Computing Initiative */ /* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */ /* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */
Re: Daemon init scripts and apt-get [was: Re: red worm amusement]
Marko Kreen marko@l-t.ee writes: On Wed, Aug 08, 2001 at 02:56:46PM -0700, Mike Fedyk wrote: On Wed, Aug 08, 2001 at 08:44:50PM +0200, Marko Kreen wrote: On Wed, Jul 25, 2001 at 11:05:25AM -0700, Dale Southard wrote: Why not use something like the IRIX ``chkconfig'' system: Provide a simple program that takes the ``name'' of a service and then checks an external file/files for ``on'' or off status of each service, and returns 0 if on, 1 if off. Then have each init.d script do something like: case $1 in 'start') if /etc/chkconfig myservice; then ... start myservice ... fi Would not it be better to put this login in rcS script? That way the services can be manually started if needed (eg. for testing). If you want to login before services start in single user mode then change: Uh. Ofcourse I meant 'code'. I have no idea how the word 'login' got there... Dale proposed that each init script checks itself whether it needs to be started, from some central location. Actually, it is how SGI's IRIX works -- so it's not really my idea, only something that I've seen work in practice and seems trivial to implement. I think this is not good, it takes away flexibility. IMHO it would be better if only /etc/init.d/rc ( rcS) checks whether a service should be auto-started on boot. That way the responsibility is also divided better, init-script's business is to start a service and rc/rcS business is start boot-time services. Interesting idea. It certainly simplifies the implementation, but it actually reduces the flexibility, rather than adds to it. If the ``do I run service X'' check is done in rcS it means that each init.d script is either on or off. This would eliminate the possibility of having more than one check in a script -- for example, it would be logical to configure the existing Debian networking script with chkconfig options for spoofprotect, syncookies, and ip_forward. This wouldn't be possible if the chkconfig is done in rcS. IRIX actually leverages this significantly -- there are a dozen or so different chkconfig controls in the IRIX networking script used to enable/disable starting of things like nfs, autofs, timed, gated, etc. One easy hack woud be to replace '-f' with '-x' in following code in rc, rcS: [ ! -f $i ] continue then later you can 'chmod -x' init scripts. Problem with this is that on upgrade your 'settings' will be lost. Exactly the problem we were discussing. The advantage of the IRIX chkconfig system is that it puts the ``on or off'' information for each service in a directory that isn't clobbered by upgrades. The above replacement wouldn't likely survive upgrades. -- /* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463, fax 422-9429 */ /* Computer Scientist, Accelerated Strategic Computing Initiative */ /* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */ /* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */
Re: Daemon init scripts and apt-get [was: Re: red worm amusement]
Mike Fedyk [EMAIL PROTECTED] writes: On Sun, Jul 22, 2001 at 03:27:10AM -0400, Steven Barker wrote: On Sat, Jul 21, 2001 at 11:59:17PM -0700, Mike Fedyk wrote: On Sun, Jul 22, 2001 at 02:50:14AM -0400, Steven Barker wrote: Personally, I think there should either be a /etc/do-not-start/package dir that packages' init scripts check for non-existance before starting, or a commented entry in the config file that the init script checks for non-existance before starting... Well, now we're getting into heavy policy stuff I think it would be hard enough to get all the daemon postinst scripts to work in run and no-run mode. Actually, if we could get them all to source an sh script that contains that logic, all changes to policy would be self-contained. I think I've shot this one out before, but... Why not use something like the IRIX ``chkconfig'' system: Provide a simple program that takes the ``name'' of a service and then checks an external file/files for ``on'' or off status of each service, and returns 0 if on, 1 if off. Then have each init.d script do something like: case $1 in 'start') if /etc/chkconfig myservice; then ... start myservice ... fi [In IRIX, the /etc/config directory has a file for each name chkconfig knows about that contains either ``on'' or ``off'' so adding a new service is as simple as `echo on /etc/config/newservice`, though IRIX actually allows viewing and changing things with the chkconfig program itself (eg, `chkconfig` with no arguments lists every service known to chkconfig, `chkconfig service on|off` changes the state of a service, with a -f flag to ``force'' creation of a new service.)] This prevents ``uptdate surprises'' since updating everything including the init.d script doesn't change the on|off status of the service in the config directory. Of course it also means putting the above bit of logic in every init.d script that is put under chkconfig control and adding the necessary logic to the postinst script to create the config entry if it doesn't exist yet... -- /* Dale Southard Jr. [EMAIL PROTECTED]925-422-1463 */ /* Computer Scientist, Accelerated Strategic Computing Initiative */ /* L-550, Lawrence Livermore National Lab, Livermore CA 94551 */ /* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Daemon init scripts and apt-get [was: Re: red worm amusement]
Mike Fedyk [EMAIL PROTECTED] writes: On Sun, Jul 22, 2001 at 03:27:10AM -0400, Steven Barker wrote: On Sat, Jul 21, 2001 at 11:59:17PM -0700, Mike Fedyk wrote: On Sun, Jul 22, 2001 at 02:50:14AM -0400, Steven Barker wrote: Personally, I think there should either be a /etc/do-not-start/package dir that packages' init scripts check for non-existance before starting, or a commented entry in the config file that the init script checks for non-existance before starting... Well, now we're getting into heavy policy stuff I think it would be hard enough to get all the daemon postinst scripts to work in run and no-run mode. Actually, if we could get them all to source an sh script that contains that logic, all changes to policy would be self-contained. I think I've shot this one out before, but... Why not use something like the IRIX ``chkconfig'' system: Provide a simple program that takes the ``name'' of a service and then checks an external file/files for ``on'' or off status of each service, and returns 0 if on, 1 if off. Then have each init.d script do something like: case $1 in 'start') if /etc/chkconfig myservice; then ... start myservice ... fi [In IRIX, the /etc/config directory has a file for each name chkconfig knows about that contains either ``on'' or ``off'' so adding a new service is as simple as `echo on /etc/config/newservice`, though IRIX actually allows viewing and changing things with the chkconfig program itself (eg, `chkconfig` with no arguments lists every service known to chkconfig, `chkconfig service on|off` changes the state of a service, with a -f flag to ``force'' creation of a new service.)] This prevents ``uptdate surprises'' since updating everything including the init.d script doesn't change the on|off status of the service in the config directory. Of course it also means putting the above bit of logic in every init.d script that is put under chkconfig control and adding the necessary logic to the postinst script to create the config entry if it doesn't exist yet... -- /* Dale Southard Jr. [EMAIL PROTECTED]925-422-1463 */ /* Computer Scientist, Accelerated Strategic Computing Initiative */ /* L-550, Lawrence Livermore National Lab, Livermore CA 94551 */ /* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */
Re: rlinetd security
Actually, your version is a little more complex than the IRIX version. Under IRIX there are seperate files for each service, rather than a single file with on/off entries for each service. In other words `echo on /etc/config/xdm` and `chkconfig xdm on` do exactly the same thing under IRIX. IRIX sometimes uses multiple chkconfig entries in tne same rc script, eg turning off `network' also prevents named, nfs, timed, routed, and lots of other services from starting. All told there are about 50 chkconfig flags on a normal IRIX install. Also note that /etc/rc?.d isn't really guaranteed by anything other than convention. I can easily write init.d scripts that do the wrong thing, and updating/reinstalling can put rc?.d symlinks back in (which is how we got on this subject to begin with). Under IRIX, the chkconfig convention is entrenched and works quite well. Wether or not it would be a useful addition to Debian is another question Joseph Pingenot [EMAIL PROTECTED] writes: From Dale Southard on Tuesday, 19 June, 2001: Hrm. That could be rather easy to implement. The guaranteed way to see if something's going to be started or not, though, is still /etc/rc?.d If you want to, you can replace them and create an easy script, such as --/sbin/chkdconfig-- #!/bin/bash #returns 1 if daemon is enabled, 0 otherwise. if [ -z $1 ]; then echo Error: No daemon process specified exit 0; fi configfile=/etc/checkdconfig line=`grep -i ^$1= $configfile 2/dev/null | head -1` if [ $? -ne 0 ]; then #No such line existed. Return 0. fi setting=`echo $line | sed 's/^.*=//'`; setting=`echo $setting | perl -we '$_ = STDIN; s/\s+//g; print;'` case $setting in 'on'|'ON'|'On'|'oN'|'yes'|'YES'|'Yes'|'YEs'|'yEs'|'yES'|'yeS'|'1') exit 1 ;; *) exit 0 ;; esac exit 0 --end chkdconfig-- please, no comments on my perl or bash-scripting (lack of) abilities. ;) All that would then remain is to alter the rc scripts to check chkconfig and to NOT populate it with daemon=value lines. :) -- /* Dale Southard Jr. [EMAIL PROTECTED]925-422-1463 */ /* Computer Scientist, Accelerated Strategic Computing Initiative */ /* L-550, Lawrence Livermore National Lab, Livermore CA 94551 */ /* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
Actually, your version is a little more complex than the IRIX version. Under IRIX there are seperate files for each service, rather than a single file with on/off entries for each service. In other words `echo on /etc/config/xdm` and `chkconfig xdm on` do exactly the same thing under IRIX. IRIX sometimes uses multiple chkconfig entries in tne same rc script, eg turning off `network' also prevents named, nfs, timed, routed, and lots of other services from starting. All told there are about 50 chkconfig flags on a normal IRIX install. Also note that /etc/rc?.d isn't really guaranteed by anything other than convention. I can easily write init.d scripts that do the wrong thing, and updating/reinstalling can put rc?.d symlinks back in (which is how we got on this subject to begin with). Under IRIX, the chkconfig convention is entrenched and works quite well. Wether or not it would be a useful addition to Debian is another question Joseph Pingenot [EMAIL PROTECTED] writes: From Dale Southard on Tuesday, 19 June, 2001: Hrm. That could be rather easy to implement. The guaranteed way to see if something's going to be started or not, though, is still /etc/rc?.d If you want to, you can replace them and create an easy script, such as --/sbin/chkdconfig-- #!/bin/bash #returns 1 if daemon is enabled, 0 otherwise. if [ -z $1 ]; then echo Error: No daemon process specified exit 0; fi configfile=/etc/checkdconfig line=`grep -i ^$1= $configfile 2/dev/null | head -1` if [ $? -ne 0 ]; then #No such line existed. Return 0. fi setting=`echo $line | sed 's/^.*=//'`; setting=`echo $setting | perl -we '$_ = STDIN; s/\s+//g; print;'` case $setting in 'on'|'ON'|'On'|'oN'|'yes'|'YES'|'Yes'|'YEs'|'yEs'|'yES'|'yeS'|'1') exit 1 ;; *) exit 0 ;; esac exit 0 --end chkdconfig-- please, no comments on my perl or bash-scripting (lack of) abilities. ;) All that would then remain is to alter the rc scripts to check chkconfig and to NOT populate it with daemon=value lines. :) -- /* Dale Southard Jr. [EMAIL PROTECTED]925-422-1463 */ /* Computer Scientist, Accelerated Strategic Computing Initiative */ /* L-550, Lawrence Livermore National Lab, Livermore CA 94551 */ /* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */
