response 25 of 60:

Oct 24 15:19 UTC 1994

   Reordered the phone to tty sequence, such that we're once again
matched.  So the first line (761-3000) gets to ttyh0, and so on.  Back
when a couple of modei were acting up we changed things, and never
put it back.

response 27 of 60:

Oct 24 20:02 UTC 1994

   Yes, we're back to what we should have been these last few months.
I believe 'phones' lists it.  Yes, here it is:

The phone numbers for Grex are:
        +1 313 761 3000  tty00 modem00
        +1 313 761 3411  tty01 modem01
        +1 313 761 3451  tty02 modem02
        +1 313 761 3554  tty03 modem03
        +1 313 761 3596  tty04 modem04
        +1 313 761 2517  tty05 modem05

response 29 of 60:

Oct 25 04:14 UTC 1994

   Today's report from the battle front:

   It's looking more and more likely that our problem is in the
fact that we have two differenet SCSI controllers here: a SCSI-2
which is the old style, and a SCSI-3 which is the 'new' style.
There is certainly the chance that having both in one system is
the cause of our problems.

   So, we got over to CE tonight to swap out the older SCSI card and
replace it with Greg's SCSI-3 card.  After fighting various things like
SCSI cables, we got the SCSI controller in, and tried booting.  No
go.  A wonderful messages ("invalid status meg = 1") appeared on the
screen and that was it.  After checking that all we had done was
correct, we put the SCSI-2 card back in, and the system came up.
About then Marcus paged me and I explained our problem to him.  He
isn't surprised that our boot disk, which was formatted under one
type of controller isn't booting under a different model.  The theory
goes that the "boot block" of the disk contains just controller-
specific enough information that it can't work under the SCSI-3.
The solution (besides tearing our hair out and aiming a 30-06 at
Grex) is to reformat the two 330M scsi disks (sd0 and sd2) under the
new controller, and restoring the information they held with a
backup (made just before this surgery happens).

   I'm beginning to think the hardware is having fun with us, and
sits around in the wee hours after Grex has crashed, thinking up new
shit to thow in Greg's and STeve's faces.  Who says computers don't
think?

   The next battle will likely take place on Wednesday.

response 31 of 60:

Oct 25 06:45 UTC 1994

...as they wrok away the night... ;-)

response 33 of 60:

Oct 25 11:50 UTC 1994

And *obviously* there's not more than one of her!
Greg, thanks for the hardware loans, once again, BTW.

response 35 of 60:

Oct 25 19:44 UTC 1994

glad it's being tracked down.

response 37 of 60:

Oct 25 23:33 UTC 1994

...a la Doom.

response 39 of 60:

Oct 26 13:42 UTC 1994

Try praising...

response 41 of 60:

Oct 31 16:08 UTC 1994

recently I got email from root (apparently an automatic email) 
saying that while I was editing a file, something WentWrong (tm),
WEntWrng, WxnTWrungg .... and that I could get it all back
if I performed an little Unix incantation ...
 
Ok, fine.
 
This isnot the first time my files have been "protected," and I 
guess I got rather used to this nifty Unixism.

But when I was editing a +critical+ file (that apparently didn;t
even show up in Lost+Found), the system protections VANISHED?
  
Of course it was my mail file.
  
Hoew does Grex "decide" what to protect and what NOT to protect?
  
How does Lost+Found work? 
.

response 43 of 60:

Nov 1 03:15 UTC 1994

While we're on the subject of missing files: a month or more back, a user
pointed to some missing files in the /usr/local/games/lib/nh313adir directory,
rendering the game "nethack" somewhat broken.  If we get this problem
resolved, can this directory be restored from say, a summer backup, or
should I just re-acquire the source and re-install the software?

response 45 of 60:

Nov 4 14:49 UTC 1994

(/bargle isn't on line right now)

response 47 of 60:

Nov 8 02:35 UTC 1994

   Thanks...

   Grex was down today for the reaping of some 3700+ accounts.
We have a new program now, called pwadm which is a general purpose
utility for adding / deleting (and eventually modifying) entries
in the passwd file here.

   It took longer than it will in the future to do account reaping
today because this was pwadm's initial run, such that I had to
spend time making sure it was working correctly and not damaging
the database first, before letting it go whole hog on the rather
massive list of accounts we had.

   So, Grex now have about 3.765 less accounts than it did
earlier today.  The entries on /home are still here for the
moment; we have enough space that it doesn't matter much.  Once
I know that I haven't zapped some entries that I shouldn't have,
I'll be wiping the home directories.  If it does turn out that
we need to resurect accounts, we can, as a level 0 dump was made
of /home before any of this was done.

   The incredible part is that we still have 5700+ accounts here!
Since our dear vandal erased the wtmp file, its going to take
some effort to come up with a definitive list of the accounts to
kill until December.

response 49 of 60:

Nov 8 13:57 UTC 1994

   It will speed up operations that use the password file for
information, like our chief hog, smail.  Because there are still
an incredible number of accounts here, we're still slower than we
could be.  As we regain the history of the wtmp file as it goes
farther back in time, we'll be able to delete more accounts.  Unless
we write some software to traipse through the inodes on /home and
figure out last references that way, but that still can't cover the
case of people who log in and don't modify files.
   Anyway, finger should now be incredibly slow, as opposed to
unbelieveably slow...