Cover V03, I06


New Messages

Subject: A Tip I learned today

Just got my e-mail confirmation about Sys Admin magazine and they said if I had a tip to send it here. Well, I just got a valuable tip this morning that I thought I would send your way.

We run Solaris 2.2 on a SUN 630MP. We don't have enough SCSI ports, so when we want to change devices we have to bring down our system, swap cables, then bring the system back up. We have done this lots, and never had any problems. Yesterday when I went to bring the system up, it booted okay, but when it went to load the services, it froze there for hours. I could remotely login but could not do anything on the console and from the remote login, it was very very slow. After three hours overtime working on this, I could not get it to continue. I left it there and went home very late. This morning when I came in, it had finally finished starting all services. I called SUN and they said there was nothing they could really check hardware wise and just keep an eye on it.

Being the adventurous sole that I am I re-booted to see what would happen. It froze once again (for several hours) I called SUN again and they said it sounded like a software problem instead of a hardware problem, so they gave me software support. The person I talked to was very helpful. He said they get a call like this about once every two months and he knew right away what to do. He had me log on from the remote computer then he had me go into /dev/sbin and issue the "bdconfig status" command. That told me that the status was off. He then had me go SUPER USER and from /usr/sbin issue the "bdconfig on /dev/term/b" command. The moment I did this the services kicked right in and finished loading. He said it may or may not happen again and to keep these commands handy!! Feel free to use this if you think it could help any one else.

John Jones

Thanks for sharing this -- it falls into the "if you need it, you REALLY need it" category.

I found the mirror idea in the January/February issue interesting. The delete feature is nice...

If you don't need to do delete, you can do much of the same with the GNU copy of cp -- it has an update option...

So if the account systems on the two machines are the same, you can do (as root):

cp -a -update /net/<source-machine>/<source-filesystem> <target filesystem>

This will recursively get all files which are newer (or new) on the source machine and copy them to the target. Since your root and the account systems are the same, it automatically changes owners, permissions and data to agree with the source file.

Marty Leisner

A nice addition to Patrick Ryan's resource -- thanks for writing.

Editor's note: In the March/April Publisher's Forum, our publisher and senior editor, Robert Ward, issued an SOS. Robert was trying to get NFS and TCP/IP running using only public domain source code. His project was to connect several DOS/Windows stations to an AT-class machine running Linux. An additional goal was to get PPP running. He hadn't had much luck. One reader wrote with some preliminary steps. For those of you who may be trying to do the same, here's what our reader, Steve Lembark, had to say.

From: Steve Lembark <ntsux2!>

Tell me your problems...

I can try to help you with the pc problem (". . . a blatant, undisguised attempt to elicit some free help").

The problem is that PCs running MSDOS (unlike a real o/s) require an intimate knowlege of the hardware and bios config to install ANYTHING. One common problem with ethernet boards is ethernet/port/bios-address conflicts. The latter show up with either devices stepping on each other (e.g., the ethernet only fails after the internal modem is used) or extended manager conflicts (e.g., the ethernet fails only after using 123 or paradox).

The first thing to try:

1) check all the irq's and make sure they don't conflict.

2) check all the ports [ditto].

3) check all the bios addresses and enter them as 16Kb excluded ranges in the memory manager (qemm386 is better at finding these for itself than emm386).

What ethernet card, tcp/ip, ppp are you trying? I'll try to get some info for you.

Steve Lembark

From: JT the LFM <>
Subject: killidle alternative

I thoroughly enjoy your journal. One of the problems we've got (and as Mr. Reznik pointed out, most sites have) is idle users, particularily those who get up and walk away from login session or are bumped from our network dailins by call waiting. We are running several DEC 5000/240's with Ultrix 4.2a and have not had great success with the publicly available "untamo". It tends to munge Elm and gopher sessions creating no end of heachaches as zombies eat up the system resources. I've been looking for alternatives and as such, I read Mr. Reznik's article on "Timing Out Idle Users" (Nov/Dec 1993) with great interest. Noting that we're using Ultrix, I found the article to bring up several good points and ideas, but to miss the mark on some of the areas where we really need help. So I set out to "improve" on the general idea of killidle while mainting the KISS attitude. The result is a shell program daemon called "lachesis" which uses, at the core, the "w" command for its idle information. In order to keep this message short, I'll just hit the highlights:


  • warns users of impending force logouts after a threshold has been reached

  • logs out overidle users in reverse-pid order

  • maintains logs of everything it does

  • backgrounds itself and includes code to stop its backgrounded daemon at a later time is configurable along the lines of "untamo" in that it allows:

    1) explicit, per-user (or userlist) thresholds for warning and logout

    2) explicit, per-site (or sitelist) thresholds for warning and logout

    3) implicit system-wide userid thresholds for warning and logout

    4) implicit system-wide site thresholds for warning and logout exemptions

    Basically, this allows us to have a simple way to eliminate idle sessions while maintaining the flexibility to configure users, groups of users and sites. For example, the terminal server to which the dialin modem pool is attached has a different set of thresholds from the business office. The PC and Mac labs have different thresholds from the administration, which differs from the faculty.

    You've probably received all sorts of suggestion about killidle, so I'm not going to bother innundating you with the source code. If you'd like, you can pick it up and peruse it at your leisure. It can be obtained via anonymous FTP from

    I'm working on a manpage, but the internal documentation, while not the best (I whipped this together and tested it over breaks) should give you an idea of what it does, should you be so inclined.

    J.T. Vogt
    Systems and Network Manager
    St. Norbert College

    Okay, we had to look it up -- Lachesis: One of the three Fates, the measurer of the thread of destiny (The American Heritage Dictionary, 3 ed.). An awesome concept -- thanks for the work and for letting us know about it.

    Can You Help? Readers Look for Answers

    From: Gustavo Pujals <!> To: Subject: Reproducing "at"

    I have a script that reproduces at commands to the at queue. Basically, the script calls itself since I want it to run everyday. When the script runs the very first time, it sends itself to the queue with no problems. However, when it runs the second time, it does NOT send itself to the queue again.

    I am running Next, which is supposed to be compatible with BSD 4.3.


    Subject: History file.

    I have been trying to find some way to have a "global" history log file that would keep a log of ALL commands entered on a system, from ALL users, all in one file. Since all the users' commands would be mixed together, each command would have to include the username and time stamp along with the command. I'm administering AIX machines, which already have a "history" file for each user. Do you know of anything out there that could accomplish this?

    Incidently, this is just the first subscription I have received, and I am very impressed. My boss says they'll pay for the subscription here, but even if they don't, I'm getting it for myself. It was FULL of good stuff.

    Tim Herman

    Dear Editor,
    I very much enjoyed Don Pipkin's "A Revised sudo." I'm wondering if any of your readers could address a similar problem of root access.

    If one of our terminalson an RS6000 loses a session, it may be necessary to kill a number of processes to clean up after the lost application. Some of the processes are owned by root regardless of the user running the application.

    Is there any way to have a non-root user "kill -9" a process that was owneed by root without giving away the password to su to root?


    Gary Rechnitz
    Northern Colorado Professional Services, LTd.
    1241 Riverside Ave., Suite No. 200
    Fort Collins, CO 80524