New Messages
Subject: A Tip I learned today
To: sasub@rdpub.com
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.
To: saletter@rdpub.com
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
leisner@sdsp.mc.xerox.com
leisner@eso.mc.xerox.com
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!lembark@uunet.uu.net>
To: saletter@rdpub.com
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
workhorse.uucp
From: JT the LFM <lfm@avatar.snc.edu>
Subject: killidle alternative
Gentlemen,
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:
lachesis
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 avatar.snc.edu://pub/misc/lachesis.tar.Z
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
lfm@avatar.snc.edu
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 <wahoo.aoml.erl.gov!pujals@uunet.uu.net>
To: saletter@rdpub.com
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.
Thanks,
Gus
To: saletter@rdpub.com
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
tim.herman@gsa.gov
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?
Sincerely,
Gary Rechnitz
Northern Colorado Professional Services, LTd.
1241 Riverside Ave., Suite No. 200
Fort Collins, CO 80524
|