Questions and Answers
I have several sys admins who use root. As a result, I can't tell who does what. I heard there is a way to set up various accounts with root access. Can you tell me how? Is it as simple as setting up a user with UID and GID = "0"?
That approach will work, but you'd be hard pressed to pass any kind of minimal UNIX security audit (in other words, don't do it). It is much more secure if you install sudo. sudo allows you to assign individual users certain administrative rights. You can specify explicit commands such as passwd, mkuser, shutdown, etc. without giving them access to other commands. Also, sudo does extensive logging of each command, providing a clear audit trail of who did what. sudo sessions also have inactivity timers. If someone invokes sudo and walks away from the session, sudo will timeout after 5 minutes (default), so active root accounts are not left accessible. One place to find it is:
I would like to make ksh the default shell for the root account. I heard this may not be a safe thing to do, but don't know why. What do you recommend?
I've always copied /usr/bin/ksh to /sbin/ksh and used that in the password file for root. I've done this for years without a problem. With that said, this is NOT a good idea. (I learn some good stuff researching these questions.) Here's why it's bad (This is from http://www.wins.uva.nl/pub/solaris/solaris2.html#q3.29):
3.29) How do I make ksh or csh be the login shell for root?
Root's shell is /sbin/sh, which is statically linked. Don't just insert a c' before sh as previously, as that would look for /sbin/csh, which doesn't exist. Don't just change it to /bin/csh, since that's really /usr/bin/csh, which is dynamically linked, because:
1) /usr may not be mounted initially, and then you're in deep (the shared libraries are in /usr!), and 2) There is code in the startup scripts that assumes that everything critical is in /etc/lib, not /usr/lib. Approach with caution!
Whenever you change root's shell, make sure you do it using vipw or passwd -e. Both programs will check for a valid (in the sense of /etc/shells) file.
Safer bet -- Have an alternate root account, like rootcsh, with uid 0, and /bin/csh as its shell. Put it after root's entry in the passwd file. Only drawback: you now have to remember to change all of root's passwords at the same time.
Third bet -- In root's .profile, check if /usr is mounted and, if so, exec /bin/ksh or whatever.
An even better bet -- Leave root's shell alone, and use the sudo command for doing things as root.
As far as having two root accounts goes, this is normally not a good idea from a security point of view. Two "root" accounts leave two accounts that can be cracked, no audit trail, etc. (see the question on sudo above).
If you don't want to implement sudo, I recommend adding something like the following to roots .profile:
[ -x /usr/bin/ksh ] && exec /usr/bin/ksh
This will run ksh if it can be found (i.e., /usr is mounted), otherwise the default shell will be used.
I have a Redhat 5.2 box, and I need to make it so users can stay connected via telnet indefinitely without getting logged off. Any help would be appreciated.
I'm pretty certain that if idle sessions are being logged out, it is not telnet doing it. You need to look at the users shell configuration or another process that is logging off idle sessions. Check for a package like "idleout" on your system. I have yet to figure out how to get telnet to timeout idle sessions (anybody else know how?).
Most likely, the shell is terminating itself. Check man ksh to see how to set the TMOUT variable. This tells the Korn shell how long to wait before terminating an idle shell. With Linux, your accounts are probably running bash. Check man bash to see how to set the TMOUT variable for bash.
I'm a DBA and need some feedback from some SAs on this. We need to expand our capacity fairly soon on a machine we use for development. It's a Sun ES3000. We have four internal drives used with six internal drive slots empty. All of the storage array slots (4 GB drives) are being used in a RAID5 configuration (Veritas Volume Manager).
The plan proposed to me is to fill up the remaining six internal slots with 9 GB drives to create a new file system and use RAID5 configuration on it. Is this a good proposal? Does using the internal drives to expand make sense? Are there any issues with having two RAID5 file systems present? Is it worth throwing the additional drives into it, or should we rather think of upgrading the array or machine or both?
I realize an "it depends" sort of answer may apply here, but I'm just looking for some general feedback on whether this is a decent short-term solution.
If the current performance of the box is okay, then add the 9-GB drives and create another RAID Level 5 volume. As far as upgrading goes, there is way too little information to give any solid advice. Here's what to look for:
1. If you are IO bound (look at sar -d to start), then you should get away from RAID Level 5. The major DB players (Oracle, Sybase, etc.) moved away from RAID 5 a while ago. The preferred (fastest) RAID out there for OLTP is RAID level 10 (or 0+1). This is striped mirrors. It is fast and reliable (you can lose up to 50% of your drives and still function). Get a RAID box with some cache and dual attach (at least) it to your system. Databases love more spindles and SCSI channels to spread IO across. If you have lots of resources don't worry about RAID 10. Go with RAID 1 and load the RAID box with cache (you'd be looking at an EMC solution here).
2. If you are memory bound (sar -w), then add more ram to your current box. If you are maxed out, then get a bigger box.
3. If you are CPU bound (sar -q), add more CPUs. If the box is maxed, get a new one. As a bonus, a new box will also probably come with faster CPUs than you have now and cost less than your old one.
I am wondering whether I can mirror a mail server (POP3, IMAP) outside the firewall for the remote users to access their mail? We do have a VPN access, however, we have some users who would like to access their mail from any computer at any time.
If you're not concerned about having internal email flow across the Internet, the easiest thing to do is to have those users set up a free email account (yahoo, hotmail, etc) and configure a .forward file in their home directory to point to this account. All the .forward file needs is one line with their external email address in it. Users could then read their email from any computer connected to the internet.
If users don't have a home directory on the mail server, set up an alias that sends a copy to the external email account. This can be a very tedious administrative task for a large amount of users.
I installed Sun Solaris OS 7 and when the system starts, it tries to start volume management. After that gives the error "Mounting of /vol' failed". I am unable to mount the CD-ROM through vold. I have to manually mount the CD-ROM using the mount command. I installed all patches regarding volume management and Sun OS. Any advice?
When I first read this question I thought "Easy, the /vol directory must be screwed up". To recreate the problem, I logged in to my Solaris 2.6 box, stopped vold (/etc/rc2.d/S92volmgt stop), blew away /vol and restarted vold (/etc/rc2.d/S92volmgt start). Well, vold recreates /vol if it is not there, so that isn't the problem. You may want to remove your /vol and restart vold to see if perhaps your /vol was bad. I get the feeling that vold recreates /vol every time, but it's worth a try.
So, although I don't have an absolute answer for you, I suggest running vold with the -L flag and setting the debug level to 99. Check /var/adm/vold.log for detailed messages. Please post your results on the Q&A Web site or email me to let me know what you discover!
I have installed, with the help of Sun support, what I believed was a default Solaris, SunOS 5.5.1 Generic_103640-27 sun4m sparc SUNW,SPARCstation-5 installation.
I have, as a matter of daily checking, done a pwck and prgck to my mail as a precautionary measure (also do who -u's, etc.). Anyway, some of the responses I received are as follows:
adm - Duplicate logname entry (gid first occurs in passwd entry)
uucp - Duplicate logname entry (gid first occurs in passwd entry)
tty - Logname not found in password file
lp - Duplicate logname entry (gid first occurs in passwd entry)
Is this just a quirk of UNIX in that the install included the group name into its authorized user list and that this check will produce an error? Or am I to remove the group name from the user list -- not the tag, just the list that follows?
This sure sounds like a quirk to me. To get rid of the warning messages (that's all they are -- no need to worry) go ahead and remove adm from the adm group, uucp from the uucp group, etc.
What is the most recent version of Sendmail and BIND? What command do I use to kill ppp connection?
BIND: 8.2.1: http://www.isc.org/view.cgi?/products/BIND/
Sendmail: 8.9.3: http://www.sendmail.org/current-release.html
To kill ppp, it depends on the OS and ppp package you're using. Check in /etc/rc2.d for the scripts that starts ppp at boot time and run that script with the "stop" parameter. If there is no ppp startup script then grep the output of ps for something with "ppp" in it and kill that process (once you verify that it is the correct one).
We have some production Sun servers running Solaris 2.6. How can we restrict some of the users' access to telnet sessions while allowing ftp services?
One way would be to give them access through anonymous ftp and not give them a login id. The easiest way to accomplish this would be to create a user as usual. The $HOME/.profile should contain one word, exit. For csh, .login should have only logout in it. This way, when a user telnets to the system, they immediately get logged off. ftp access will work as normal.
If you want to do the opposite (let people telnet in but restrict ftp access), add the users you want to restrict from ftp to /etc/ftpusers. ftpd authenticates users according to four rules (from man ftpd, see rule 2):
First, the user name must be in the password database, /etc/passwd, and have a password that is not NULL. A password must always be provided by the client before any file operations may be performed.
Second, if the user name appears in the file /etc/ftpusers, ftp access is denied.
Third, ftp access is denied if the user's shell (from /etc/passwd) is not listed in the file /etc/shells. If the file /etc/shells does not exist, then the user's shell must be one of the following:
/usr/bin/sh /usr/bin/csh /usr/bin/ksh
/usr/bin/jsh /bin/sh /bin/csh
/bin/ksh /bin/jsh /sbin/sh
Fourth, if the user name is "anonymous" or "ftp", an entry for the user name ftp must be present in the password and shadow files. The user is then allowed to log in by specifying any password -- by convention this is given as the user's email address (such as user@host.Sun.COM). Do not specify a valid shell in the password entry of the ftp user, and do not give it a valid password (use NP in the encrypted password field of the shadow file).
If you are trying to block certain IP addresses from ftp'ing or telneting, then implement tcp_wrappers.
What are the ethical responsibilities of a systems administrator?
SAGE (the Systems Administration Guild) has a published code of ethics that you could use as a guideline. Check out:
About the Author
Jim is a Technical Analyst specializing in UNIX. He has worked for IBM, Rite Aid, EDS, and is currently working for Sprint Paranet. He can be reached at: firstname.lastname@example.org.