New Messages
From: Michael Hill (mhill@level3.net) “PAM [...] provides [...] authentication in modern Linux systems (and can be implemented in others, such as Solaris)...” In fact, PAM was developed by Sun/SunSoft, i.e., it originated on Solaris (and can be implemented in others, such as Linux).
--Michael True, but Linux seems to really be going with it; yes Solaris uses it, but a lot of the modules simply aren't there (like listfile). From my Solaris 8.0 on the Ultra:
bash-2.03$ ls amiserv pam_ldap.so.1 pam_sample.so.1 pam_ami.so pam_projects.so pam_smartcard.so pam_ami.so.1 pam_projects.so.1 pam_smartcard.so.1 pam_dial_auth.so pam_rhosts_auth.so pam_unix.so pam_dial_auth.so.1 pam_rhosts_auth.so.1 pam_unix.so.1 pam_krb5.so pam_roles.so sparcv9 pam_krb5.so.1 pam_roles.so.1 pam_ldap.so pam_sample.soFrom a Red Hat 6.2 box:
[seifried@mail security]$ ls pam_access.so pam_lastlog.so pam_radius.so pam_unix_acct.so pam_console.so pam_limits.so pam_rhosts_auth.so pam_unix_auth.so pam_cracklib.so pam_listfile.so pam_rootok.so pam_unix_passwd.so pam_deny.so pam_mail.so pam_securetty.so pam_unix_session.so pam_env.so pam_mkhomedir.so pam_shells.so pam_userdb.so pam_filter.so pam_motd.so pam_stress.so pam_warn.so pam_ftp.so pam_nologin.so pam_tally.so pam_wheel.so pam_group.so pam_permit.so pam_time.so pam_xauth.so pam_issue.so pam_pwdb.so pam_unix.soBasically Linux has ~6-7 times as many PAM modules. Admitedly not all are auth, some are for session/etc. That is why there is a Linux bias in my article. --Kurt Seifried
From: Bitt Faulk (wfaulk@beaglebros.com) Upon initial perusal, I noticed many blatant errors in the September 2000 issue. First, in the little quiz on page 30, the answer to question 2 claims that ‘‘who -z 2>&1 > log'' will send stderr and stdout to the file ‘‘log''. This is untrue, as well as a common novice error. The correct command should be ‘‘who -z > log 2>&1''. The command as written will redirect stderr to stdout and then redirect stdout (not including the redirected stderr) to the file. It will not appear any different to the user than simply redirecting stdout (assuming that both stdout and stderr are sent to the tty, as is usual). Second, on page 83, Ron McCarthy suggests the way to shutdown sendmail temporarily is to send it a SIGKILL. And this isn't even to shut it down forever. Sending SIGKILLs to processes indiscriminately is a habit that many intermediate sysadmins fall into, and one that should be broken as soon as possible, not encouraged, especially not in an article whose intended audience is, apparently, such people. He also uses the killall command to do this, without much of a warning that this might not work (or do something else entirely) on many Unices. Since he's basically just giving step-by-step instructions (and ones that appear to be basically reworded from the install instruction distributed with qmail, for that matter), he should try to be much more accurate, or at least elucidate on what he's trying to do and why. Third, Q&A appears to have been an all-Solaris installment. Okay, not all, but certainly many questions were Solaris- (and sometimes Sparc-) specific. Without any warning. This makes much of the article confusing at best for other Unix admins. For example, /etc/default/login appears in no Linuxes I'm aware of, and certainly not all other Unices. Fourth, it is suggested that probe-scsi will show all SCSI devices on a Sparc machine from the PROM monitor. This is true, assuming that only one SCSI chain exists on your machine. A more appropriate command would be probe-scsi-all. In addition, he suggests a reconfiguration boot in order to add a new disk. I've found out the hard way that this can basically destroy a DiskSuite-controlled software RAID device, so I avoid them at all costs. In this case, there's not much of a cost. Simply attach the new device (which in most new Sparc machines with SCA SCSI attachments doesn't require shutting down), then run “drvconfig” to make sure the appropriate drivers are loaded into the kernel (in the case of a drive, they already will be, but this doesn't hurt anything and you might as well, just in case), then run “disks” to create the links in the /dev/ tree. Then proceed with a format as usual. Fifth, he also states that the answer to ftp file transfer corruption is to simply run dos2unix on it. First, a simpler answer is to make sure that the transfer mode in ftp is set to ASCII. Second, the question nowhere states that it is a text file getting corrupted. Perhaps it's a binary. Then dos2unix definitely won't work. Maybe I should simply offer my services as a replacement to Mr. McKinstry as the columnist here. He certainly seems to be burned out. Keep in mind that this was only an initial perusal. This letter has taken a significantly longer time to draft than the time that I spent scanning the magazine. What will I find when I sit down to actually read it? At any rate, I'm starting to wonder if I should trust any of the information I find in this month's SysAdmin. What do you think?
--Bitt
Hi Bitt, As the editors of Sys Admin, Joe Casad and I must trust the columnists and the working sys admins who submit articles to provide solid, technical information. These authors are not infallible, however, and they appreciate useful feedback when they've made errors. Joe and I are not infallible either, and we apologize for not catching these mistakes. You write that you found these errors on “initial perusal”, but later you say drafting your letter took longer than “scanning” the magazine. Using the verb “peruse” incorrectly is a mistake that many writers make. To peruse means to read or examine very carefully. I hope that upon actual careful reading of the September issue, you find that the magazine contains some valuable information. I'm not insensitive to the mistakes you've pointed out, but I'm impatient with your tone.
Sincerely,
Mr. Faulk, You are correct in the poor (wrong) choice of SIGKILL when the SIGTERM signal is the much cleaner choice. Regardless of signal, the command can be used to temporarily disable sendmail. I did not provide the instructions to permanently remove Sendmail from the system start up scripts, but your point is understood, and will make sure I don't make this mistake in future how-to articles. Additionally, the use of the Linux command killall was a poor choice in both places used in the article since I stated earlier that although the instructions were for Linux, the installation steps could generally be used on other versions of Unix. (This did remind me of the speech a previous supervisor in a Solaris shop gave new administrators that had quite a bit of experience on Linux...the speech included their first task to read the Solaris man page for killall :-).) I'm not sure what you mean by the statement “Sending SIGKILLs to processes indiscriminately is a habit that many intermediate sysadmins fall into, and one that should be broken as soon as possible, not encouraged, especially not in an article whose intended audience is, apparently, such people.” System administrators I know, regardless of experience level, do not indiscriminately send SIGKILLs to processes. Depending on the applications supported and situation, applications are generally shut down using the program's instructions or vendor approved procedure. (I've seen some database procedures that scream for scripting, but admins diligently follow the suggestion to follow the steps so that immediate feedback is given and errors can be reported to the DBA or vendor's support service prior to proceeding with further steps.) kill commands are reserved by most system administrators for restarting system daemons and applications that cannot be cleanly shut down. I regret that you feel the article is just a rehash of the installation notes. With how-to articles, I try to provide a closer insight into what is covered by showing a “manual” configuration that will provide the reader more information than simply downloading the latest package in binary form and using canned configurations from the package or from a net posting. Unlike many installation instructions that are incorrect since they are outdated, I do not assume expertise with the language being used or the installation script. I also check and recheck my installation instructions to ensure that the instructions are accurate and provide real world insight where appropriate.
Best regards,
From: Brian Mayo bmayo@clearviewconsulting.net I wanted to comment about this article and the use of EMC to refresh a development database. It saddens me to always see people immediately rush to a solution that includes over a million dollar purchase to obtain a similar result that can be achieved with just a little more work. As most know, HP-UX's LVM, which is based on the OSF LVM, has built-in the exact same functionality of EMC's Timefinder. Considering the unbelievable large price tag the EMC software has on it, why not use what it free with the operating system? On top of the huge price savings, HP-UX LVM does not have the requirement that the physical volumes be the same size when you perform the mirror and then subsequent split since LVM uses an extend-based metric. I see this trend in system administration; instead of having senior administrators spend a little more time and custom-work a solution, the push is to immediately buy some over-priced shrink-wrap package that does not really fit and cannot be customized and is implemented for a few months or a year until it is dropped for the next sales person's pitch. Is it that companys just do not have faith in the system administrations or are the current system administrators just too lazy and dumb to handle the task. It saddens me.
Hi, Brian-- We're always looking for a better way, though. We would be very interested in an article on how to address the same problem using native HP-UX features. Please submit a proposal if you'd care to contribute such an article.
--Joe Casad, Technical Editor
|