| dec99.tar |
Questions and Answers
Jim McKinstry
http://www.courtesan.com/courtesan/products/sudo/
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.
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.
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.
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.
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.
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, 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::4:root,adm,daemon
adm - Duplicate logname entry (gid first occurs in passwd entry)
or
uucp::5:root,uucp
uucp - Duplicate logname entry (gid first occurs in passwd entry)
or
tty::7:root,tty,adm
tty - Logname not found in password file
or
lp::8:root,lp,adm
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?
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).
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 /sbin/jsh 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.
http://www.usenix.org/sage/publications/code_of_ethics.html
About the AuthorJim 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: jrmckins@yahoo.com. |