So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
On Sat, Jan 27, 2007 at 04:04:39PM -0800, Florin Andrei wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
I've never had to execute anything directly in /etc/init.d/ -- there is the "service" command that runs those files for me, at least in fedora. you can always modify $PATH by dropping a file into /etc/profile.d/ if you *really* want this sort of thing to be possible. I would not want to see it in fedora though.
regards, J
jam@zoidtechnologies.com wrote:
On Sat, Jan 27, 2007 at 04:04:39PM -0800, Florin Andrei wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
I've never had to execute anything directly in /etc/init.d/ -- there is the "service" command that runs those files for me, at least in fedora. you can always modify $PATH by dropping a file into /etc/profile.d/ if you *really* want this sort of thing to be possible. I would not want to see it in fedora though.
I'd agree, but it does bring something else to mind.
I don't modify the path on my system from the install default, but when logged in as root via 'su', /sbin is not in the path. I do see something in /etc/profile that is apparently supposed to put it in there if the EUID is zero, but it never seems to happen. I hadn't really thought about it much till now. Is that a bug? Does this happen to anyone else?
It also happens when using sudo, i.e. "sudo service" gets "sudo: service: command not found", whereas "sudo /sbin/service" shows usage for service.
-Ron
On Sat, 2007-01-27 at 16:27 -0800, Ron Johnson wrote:
I don't modify the path on my system from the install default, but when logged in as root via 'su', /sbin is not in the path. I do see something in /etc/profile that is apparently supposed to put it in there if the EUID is zero, but it never seems to happen. I hadn't really thought about it much till now. Is that a bug? Does this happen to anyone else?
when you su you're not 'su -' which opens a login shell and processes bash_profile
try it.
su echo $PATH
su - echo $PATH
-sv
On Sat, 2007-01-27 at 16:27 -0800, Ron Johnson wrote:
I don't modify the path on my system from the install default, but when logged in as root via 'su', /sbin is not in the path. I do see something in /etc/profile that is apparently supposed to put it in there if the EUID is zero, but it never seems to happen. I hadn't really thought about it much till now. Is that a bug? Does this happen to anyone else?
It also happens when using sudo, i.e. "sudo service" gets "sudo: service: command not found", whereas "sudo /sbin/service" shows usage for service.
Both su and sudo only change your effective user ID to that of the root user (in essence giving you root permissions to files/directories/etc.), but your environment (PATH, HOME, TMPDIR, etc.) all remain untouched. If you want to gain a full login shell as the root user (including your own environment and running root's login scripts), you need to use 'su -'.
Once upon a time, Peter Gordon peter@thecodergeek.com said:
Both su and sudo only change your effective user ID to that of the root user (in essence giving you root permissions to files/directories/etc.), but your environment (PATH, HOME, TMPDIR, etc.) all remain untouched. If you want to gain a full login shell as the root user (including your own environment and running root's login scripts), you need to use 'su -'.
The annoying thing about that is that "su -" also changes your current working directory. If you are in a directory and need to do something to a file as root, you either "su" (and possible have to set your PATH or explicitly call /usr/sbin/xyzzy) or you "su -" and hunt down the directory again.
Personally, I drop an extra script in /etc/profile.d that (among other things) adds /usr/local/sbin:/usr/sbin:/sbin to the PATH of all users. It doesn't really hurt anything.
On Sat, Jan 27, 2007 at 09:16:44PM -0600, Chris Adams wrote:
Personally, I drop an extra script in /etc/profile.d that (among other things) adds /usr/local/sbin:/usr/sbin:/sbin to the PATH of all users. It doesn't really hurt anything.
I get a similar result by adding the sbin directories and my $HOME/{s,}bin directories to my .profile. This is something that I can do even when I don't administer a machine, and lets me stay closer to the stock configuration when I do.
Even though this type of $PATH extension seems like a frequently requested feature that many of us have been putting in place on our own with no ill effects for years, there does seem to be some resistance to making this the default.
The only two reasons that I recall for maintaining the status quo are that including sbin could confuse non-admins, and that including sbin could interfere with the operation of the consolehelper program which is used to fire off the system-config-* programs. The first objection doesn't seem very compelling, and the second seems like it could be resolved without much difficulty.
-- John Kodis.
On Sun, 2007-01-28 at 09:18 -0500, kodis@mail630.gsfc.nasa.gov wrote:
The only two reasons that I recall for maintaining the status quo are that including sbin could confuse non-admins, and that including sbin could interfere with the operation of the consolehelper program which is used to fire off the system-config-* programs. The first objection doesn't seem very compelling, and the second seems like it could be resolved without much difficulty.
-- John Kodis.
Straight from the Filesystem Hierarchy Standard, version 2.3 (emphasis mine):
"/sbin : System binaries Purpose Utilities used for system administration (and other *root-only* commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. [...]"
The /sbin/ (and /usr/sbin, et al.) stuff is specifically meant for administrative utilities. Having it in a user's PATH makes no sense when they are not meant to use these. And, if they *are* meant to use them, then it's likely that they need at least limited root privileges, so sudo or something similar should be configured for the purpose, not merely some PATH munging.
Once upon a time, Peter Gordon peter@thecodergeek.com said:
The /sbin/ (and /usr/sbin, et al.) stuff is specifically meant for administrative utilities. Having it in a user's PATH makes no sense when they are not meant to use these. And, if they *are* meant to use them, then it's likely that they need at least limited root privileges, so sudo or something similar should be configured for the purpose, not merely some PATH munging.
There are a number of things in the sbin directories that are NOT root-only. They may be things that are generally only useful to system administrators, but they don't require root access.
Then there are things that are designed specifically to NOT be run as root that are in sbin directories; bonnie++ for example.
Chris Adams wrote:
There are a number of things in the sbin directories that are NOT root-only. They may be things that are generally only useful to system administrators, but they don't require root access.
Then there are things that are designed specifically to NOT be run as root that are in sbin directories; bonnie++ for example.
It that case, I guess it could be argued that bonnie++ could perhaps be more rightfully placed in /usr/bin instead?!?
/Thomas
"TMS" == Thomas M Steenholdt tmus@tmus.dk writes:
TMS> It that case, I guess it could be argued that bonnie++ could TMS> perhaps be more rightfully placed in /usr/bin instead?!?
My most-used /sbin-command without root privileges is /sbin/ip. I wish that one was in /bin, perhaps along with ifconfig for the nostalgic.
Back when there were normal users on the command line, it made sense to have the /sbin vs. /bin distinction, but these days normal users stick with the GUI. The rest of us need access to the stuff in /sbin. I support the move of basically everything that isn't a daemon to /bin.
/Benny
Benny Amorsen wrote:
My most-used /sbin-command without root privileges is /sbin/ip. I wish that one was in /bin, perhaps along with ifconfig for the nostalgic.
Still, ip and even ifconfig is for administration (diagnostics and troubleshooting is administration too), which is a valid reason why they belong in /sbin.
/Thomas
Peter Gordon wrote:
Straight from the Filesystem Hierarchy Standard, version 2.3 (emphasis mine):
"/sbin : System binaries Purpose Utilities used for system administration (and other *root-only* commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. [...]"
The /sbin/ (and /usr/sbin, et al.) stuff is specifically meant for administrative utilities. Having it in a user's PATH makes no sense when they are not meant to use these. And, if they *are* meant to use them, then it's likely that they need at least limited root privileges, so sudo or something similar should be configured for the purpose, not merely some PATH munging.
Absolutely!
/Thomas
2007/1/27, jam@zoidtechnologies.com jam@zoidtechnologies.com:
On Sat, Jan 27, 2007 at 04:04:39PM -0800, Florin Andrei wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
I've never had to execute anything directly in /etc/init.d/ -- there is the "service" command that runs those files for me, at least in fedora. you can always modify $PATH by dropping a file into /etc/profile.d/ if you *really* want this sort of thing to be possible. I would not want to see it in fedora though.
It'll be nice if command-completion in bash and zsh can provide the list of available services .. otherwise, using zsh, there are ease-of-use arguments for having init.d in $PATH
On Sat, 2007-02-03 at 11:13 -0500, Michel Salim wrote:
It'll be nice if command-completion in bash and zsh can provide the list of available services .. otherwise, using zsh, there are ease-of-use arguments for having init.d in $PATH
If you install bash-completion and then type "service TAB" it will show you a list of all of the services.
Jeff
2007/2/3, Jeffrey C. Ollie jeff@ocjtech.us:
On Sat, 2007-02-03 at 11:13 -0500, Michel Salim wrote:
It'll be nice if command-completion in bash and zsh can provide the list of available services .. otherwise, using zsh, there are ease-of-use arguments for having init.d in $PATH
If you install bash-completion and then type "service TAB" it will show you a list of all of the services.
Ah! Would be nice to have it selected by default, now that Core and Extras are merging.
Bill Nottingham wrote:
Michel Salim (michel.salim@gmail.com) said:
Ah! Would be nice to have it selected by default, now that Core and Extras are merging.
Generally, either people swear by, or swear at, bash-completion. Not much middle ground.
I'd be one of those swearing at it. If there is going to be any discussion of selecting it by default, I'd kindly ask that all of the network-based completion rules (*cough* yum <Tab> *cough*) be disabled by default.
--Wart
2007/2/3, Jeffrey C. Ollie jeff@ocjtech.us:
On Sat, 2007-02-03 at 11:13 -0500, Michel Salim wrote:
It'll be nice if command-completion in bash and zsh can provide the list of available services .. otherwise, using zsh, there are ease-of-use arguments for having init.d in $PATH
If you install bash-completion and then type "service TAB" it will show you a list of all of the services.
One reason I did not realized bash-completion already does this is that you have to be root (to have /sbin in your path) for the tab-completion to work.
* [05.Şub.07 12:47 -0500] Michel Salim:
2007/2/3, Jeffrey C. Ollie jeff@ocjtech.us:
If you install bash-completion and then type "service TAB" it will show you a list of all of the services.
One reason I did not realized bash-completion already does this is that you have to be root (to have /sbin in your path) for the tab-completion to work.
Actually you don’t need to have /sbin in $PATH. Completion works fine if you just type “service <TAB>” or modify the completion function as attached.
Florin Andrei florin@andrei.myip.org wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
That those can't be considered "programs for normal use" by any stretch of the imagination...
On 1/27/07, Florin Andrei florin@andrei.myip.org wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
because "/sbin/service" is...
-Mike
Mike McGrath wrote:
On 1/27/07, Florin Andrei florin@andrei.myip.org wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
because "/sbin/service" is...
I know what you mean, but TAB completion doesn't work on the service name when using /sbin/service
On Sat, 2007-01-27 at 21:09 -0800, Florin Andrei wrote:
Mike McGrath wrote:
On 1/27/07, Florin Andrei florin@andrei.myip.org wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
because "/sbin/service" is...
I know what you mean, but TAB completion doesn't work on the service name when using /sbin/service
One problem is that many of the init scripts have names that conflict with programs on the path. For example, if you type "sshd", are you running the binary in /usr/sbin or are you running the init script in /etc/init.d? There are numerous other examples.
As far as TAB completion goes, take a look at bash-completion in Extras.
Jeff
Jeffrey C. Ollie wrote:
One problem is that many of the init scripts have names that conflict with programs on the path. For example, if you type "sshd", are you running the binary in /usr/sbin or are you running the init script in /etc/init.d? There are numerous other examples.
That's a pretty good reason. I agree.
Florin Andrei wrote:
Jeffrey C. Ollie wrote:
One problem is that many of the init scripts have names that conflict with programs on the path. For example, if you type "sshd", are you running the binary in /usr/sbin or are you running the init script in /etc/init.d? There are numerous other examples.
That's a pretty good reason. I agree.
Although I'd hate to go down that path (at least without a few divertions first), distros like SUSE creates a symbolic link to a the init.d/* scripts in /sbin (or /usr/sbin - I can't remember) called rc<scriptname> that can be used for this kind of thing.
But out /sbin/service command creates a locked down environment for the init-scripts to run in, which means that :
service sshd start != /etc/init.d/sshd start
If we wanted something like this, i guess we should try to enforce the source of a env cleaning script as the first line in all scripts.
Just a thought
/Thomas
Florin Andrei wrote:
Mike McGrath wrote:
On 1/27/07, Florin Andrei florin@andrei.myip.org wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
because "/sbin/service" is...
I know what you mean, but TAB completion doesn't work on the service name when using /sbin/service
Try this (you can place it as "/etc/profile.d/service.sh"):
_service_func () { COMPREPLY=( $(cd /etc/init.d; ls ${2}* ) ) } complete -F _service_func service
Regards, Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy
P.S. see /usr/share/doc/bash-*/complete/* for examples...
On 1/29/07, Dmitry Butskoy buc@odusz.so-cdu.ru wrote:
Try this (you can place it as "/etc/profile.d/service.sh"):
_service_func () { COMPREPLY=( $(cd /etc/init.d; ls ${2}* ) ) } complete -F _service_func service
From immediate personal experience, you want to make it:
COMPREPLY=( $(cd /etc/init.d; /bin/ls ${2}* 2>/dev/null ) )
Cheers,
Florin Andrei wrote:
Mike McGrath wrote:
On 1/27/07, Florin Andrei florin@andrei.myip.org wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
because "/sbin/service" is...
I know what you mean, but TAB completion doesn't work on the service name when using /sbin/service
That's because you haven't discovered how wonderful zsh is yet.
Warren Togami wrote:
Florin Andrei wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
/etc/rc.d/init.d/spamassassin /usr/bin/spamassassin
Which should run when you run 'spamassassin'?
Ambiguity is bad.
Correct.
OTOH, if all files in /etc/init.d would be named init-<service-name> or something like that, then the ambiguity would disappear and the /etc/init.d could be added to the default $PATH.
On 1/28/07, Rex Dieter rdieter@math.unl.edu wrote:
OTOH, if all files in /etc/init.d would be named init-<service-name> or something like that, then the ambiguity would disappear and the /etc/init.d could be added to the default $PATH.
Or just use: # service <service-name>
Yes, and bash-completion *will* tab-complete the entries from /etc/init.d for you when you use "service".
Cheers,
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Konstantin Ryabitsev Sent: Sunday, January 28, 2007 7:30 PM To: Development discussions related to Fedora Core Subject: Re: /etc/init.d in the default $PATH ?
On 1/28/07, Rex Dieter rdieter@math.unl.edu wrote:
OTOH, if all files in /etc/init.d would be named init-<service-name>
or
something like that, then the ambiguity would disappear and the /etc/init.d could be added to the default $PATH.
Or just use: # service <service-name>
Yes, and bash-completion *will* tab-complete the entries from /etc/init.d for you when you use "service".
Cheers,
Konstantin Ryabitsev Montréal, Québec
That is interesting. cd /etc/init.d service wi<TAB> works Doesn't seem to matter if /etc/init.d is in the PATH or not. If you aren't in /etc/init.d service wi<TAB> doesn't work even if /etc/init.d is in your PATH.
I dont' think that /etc/init.d should be in your path. Either use the service command or cd /etc/init.d and use ./command. Or /etc/init.d/command.
I seem to always cd to /etc/init.d to look most of the time I can't remember the name of a service anyway.
On 1/28/07, Jerry Williams jwilliam@xmission.com wrote:
I seem to always cd to /etc/init.d to look most of the time I can't remember the name of a service anyway.
Since we seem to have degraded into personal workflow ideas.... I always just do chkconfig --list to review the service names, when i need to.
Now... if service grew a similiar --list option, I wouldn't mind it. If you got me drunk enough, I'd say that we as administrators ( and yes I'm qualified to speak for every last surly one of them ) would get the most benefit in workflow if the functionality of service and chkconfig got magically rolled into the same command.
-jef"and drunk enough here means 1 tequila shot, preferable from a brand that comes from a plastic bottle"spaleta
Florin Andrei wrote:
Warren Togami wrote:
Florin Andrei wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
/etc/rc.d/init.d/spamassassin /usr/bin/spamassassin
Which should run when you run 'spamassassin'?
Ambiguity is bad.
Correct.
OTOH, if all files in /etc/init.d would be named init-<service-name> or something like that, then the ambiguity would disappear and the /etc/init.d could be added to the default $PATH.
notations such as "service init-sshd restart" would be really annoying.
If people think that we should provide some scheme of tab completion for service operations, perhaps a modded rc<initscript> link, like SUSE provides would be the best (?!?) solution.
There's really no way that there should be PATH to /etc/init.d, seriously.
/Thomas
On Sun, Jan 28, 2007 at 04:43:03PM -0800, Florin Andrei wrote:
Ambiguity is bad.
Correct. OTOH, if all files in /etc/init.d would be named init-<service-name> or something like that, then the ambiguity would disappear and the /etc/init.d could be added to the default $PATH.
No one seems to have mentioned this, so I will. It's important to use /sbin/service rather than running /etc/init.d scripts directly for other reasons than its convenience. Namely, it properly sanitizes your environment so a program started that way behaves just as if really started by init at system boot time.
On Sat, Jan 27, 2007 at 16:04:39 -0800, Florin Andrei florin@andrei.myip.org wrote:
So, what it the rationale for /etc/init.d not being in the default $PATH, for root at least?
Wouldn't you use the 'service' command to run things there?
-
Benny Amorsen -
Bill Nottingham -
Bruno Wolff III -
Chris Adams -
Christopher Aillon -
Dmitry Butskoy -
Florin Andrei -
Horst H. von Brand -
Jef Spaleta -
Jeff MacDonald -
Jeffrey Ollie -
Jerry Williams -
John Kodis -
Konstantin Ryabitsev -
Matthew Miller -
Michael Thomas -
Michel Salim -
Mike McGrath -
Peter Gordon -
Rex Dieter -
Ron Johnson -
Sertaç Ö. Yıldız -
seth vidal -
Thomas M Steenholdt -
Warren Togami