How do I get YDL to recongize commands under root?

[NuxIT]

I don't remember having this issue on 5.x YDL. I'm now trying to get my 6.2 YDL configured and am having some issues. When I start a terminal and change to root it won't recognize most commands.
Like, if I type ifconfig -a I get
bash: ifconfig: command not found
So, I have to type the whole path /sbin/ifconfig -a and then it works. I don't know if their is supposed to be some sort of path setting the the root profile or something? Any ideas? thanks..

What's strange is if I type sudo - then it will recognize commands like normal so I guess this is adequate for now.

[billb]

Sounds like you're using the su command by itself -- you need to add a hyphen.

So use:

Code: Select all

su -

(su -l and su --login would also work)

Instead of just:

Code: Select all

su

[NuxIT]

Thanks for the reply billb. I remembered what I had to do under the 5.x load and did the same thing.

I went into /home/"USER"/.bash_profile and added a Colon to the end of the PATH line and added /sbin:/usr/sbin.

Now all command recognized under normal user account.

[ppietro]

Thanks for the reply billb. I remembered what I had to do under the 5.x load and did the same thing.

I went into /home/"USER"/.bash_profile and added a Colon to the end of the PATH line and added /sbin:/usr/sbin.

Now all command recognized under normal user account.

I would be remiss if I did not mention that this solution is not advised per standard Unix usage and configuration. There are cases where you need su by itself, and by editing .bash_profile, you can never do this.

If editing .bash_profile works for you - great - but generally, it's recommended to use su -l or su -login when necessary

Cheers,
Paul

[NuxIT]

I would be remiss if I did not mention that this solution is not advised per standard Unix usage and configuration. There are cases where you need su by itself, and by editing .bash_profile, you can never do this.

If editing .bash_profile works for you - great - but generally, it's recommended to use su -l or su -login when necessary

Cheers,
Paul

Hi Paul. Actually I always use the su - command for using root. I only made the change in .bash_profile to my user account that I created because it didn't recognize commands when opening terminal. I'm pretty sure this should be fine since it's working for me. I didn't modify the root's .bash_profile. Regards, Chris

[ppietro]

Hi Paul. Actually I always use the su - command for using root. I only made the change in .bash_profile to my user account that I created because it didn't recognize commands when opening terminal. I'm pretty sure this should be fine since it's working for me. I didn't modify the root's .bash_profile. Regards, Chris

Wow - that's really weird. I read what you did, but totally transposed it in my mind. What you did is safe, per se.

BUT

Part of what I was saying is true, though. Generally, programs in the /sbin directory are not supposed to be accessed by normal users. They're supposed to be reserved for administrators - i.e. root - only.

From http://www.linfo.org/sbin.html

/sbin is a standard subdirectory of the root directory in Linux and other Unix-like operating systems that contains executable (i.e., ready to run) programs. They are mostly administrative tools, that should be made available only to the root (i.e., administrative) user.

also

/sbin is similar to /bin, which contains executable programs needed to boot (i.e., start) the system, except that /sbin's programs are normally executed only by the root user. Thus, /sbin is by default not in the PATH environmental variable of ordinary users, but it is for the root account.

It's unfortunate that those programs allow normal users to execute them. Either they should be root only and in the /sbin directory, or they should be for all users, and in /bin or /usr/bin.

So - yeah - you're not in danger since you still have to be root to do any damage with them. But - it's unfortunate that you have to do this. It should be thought out better from the Linux side.

Cheers,
Paul

[aguilarojo]

...Generally, programs in the /sbin directory are not supposed to be accessed by normal users. They're supposed to be reserved for administrators - i.e. root - only.

From http://www.linfo.org/sbin.html

It's unfortunate that those programs allow normal users to execute them. Either they should be root only and in the /sbin directory, or they should be for all users, and in /bin or /usr/bin.

So - yeah - you're not in danger since you still have to be root to do any damage with them. But - it's unfortunate that you have to do this. It should be thought out better from the Linux side.

Cheers,
Paul

Hey Paul!

Very interesting point. However I think the difficulty which you brought out or highlighted is not a problem of Linux per se as much as it is a problem or limitations of the bash, Almquist (a/sh) & t/csh shells. The weakness of these shells as seen from a professional programming/system administration view is not all that clear or highlighted for those who have not been deeply interested in the nuances of engineering/programming. For instance, one very important feature of ksh which is critical in a multiuser Unix environment, is the ability of the System Administrator to have users confined to a special ksh environment known as the restricted ksh. An introduction to the K shell is covered, however specifics discussing the restricted ksh is presented in Section 10.4.2. In other words, ksh within the hands of a skilled system administrator is a great security tool to protect the system from unintended user errors and/or from intruders seeking illegal/unapproved access.

For those who are interested in learning more about the Korn shell this text may be useful: http://linuxcentral.com/catalog/index.php3?prod_code=B000-289. For those interested in discovering if ksh and other shells are available for YDL, happily the answer is yes. What follows is what yum found when I ran it:

Code: Select all

$ sudo yum info "*ksh*"
Password:
Loading "protectbase" plugin
Loading "installonlyn" plugin
Excluding Packages from Livna for Fedora Core 6 - ppc - Base
Finished
Excluding Packages from Fedora Extras
Finished
118 packages excluded due to repository protections
Installed Packages
Name   : e_modules-deskshow
Arch   : ppc
Version: 0.0.1
Release: 0.20070820
Size   : 97 k
Repo   : installed
Summary: deskshow module for the Enlightenment window manager

Description:
deskshow module for the Enlightenment window manager.


Name   : ksh
Arch   : ppc
Version: 20080202
Release: 14.2
Size   : 2.8 M
Repo   : installed
Summary: The Original ATT Korn Shell

Description:
KSH-93 is the most recent version of the KornShell by David Korn of
AT&T Bell Laboratories.
KornShell is a shell programming language, which is upward compatible
with "sh" (the Bourne Shell).


Name   : kshutdown
Arch   : ppc
Version: 1.0.1
Release: 1.fc6
Size   : 711 k
Repo   : installed
Summary: KShutDown is an advanced shut down utility for KDE

Description:
KShutDown is an advanced shut down utility for KDE.


Available Packages
Name   : mksh
Arch   : ppc
Version: 32
Release: 1.fc6
Size   : 174 k
Repo   : fedora-extras
Summary: MirBSD enhanced version of the Korn Shell
Description:
mksh is the MirBSD enhanced version of the Public Domain Korn shell (pdksh),
a bourne-compatible shell which is largely similar to the original AT&T Korn
shell. It includes bug fixes and feature improvements in order to produce a
modern, robust shell good for interactive and especially script use, being a
bourne shell replacement, pdksh successor and an alternative to the C shell.

$


Within YDL anyone can move between various shells; this can be done within any Linux or Unix similarly. Here's a simple demo:

Code: Select all

[aguila@arakus Downloads]$ csh
[aguila@arakus ~/Downloads]$ sh
sh-3.2$ ksh
$ bash
[aguila@arakus Downloads]$