|
|
|
This item is for system announcements (new computer equipment on Grex, system upgrades, Grex meetings, etc.). Personal announcements should go back in item 2; Grex system *problems* belong in the next item (#4).
44 responses total.
where can i get a online tutorial for linux?
The 6th edition of the Grex Auction is now open for business! "join auction" at the next Picospan prompt, or click on the appropriate buttons in Backtalk.
edit /server 194.119.238.162 6669 spell UK write help /6669/6666 set ok exit
(hmm. I give it a 12... for age.)
What are the clues that suggest that?
There are more items in the Grex auction! I just entered a bunch more books. If you haven't been to the auction conference yet, come look soon!
kennstar.org Done q
This response has been erased.
This response has been erased.
(IWLTA that Grex has now been up, continuously, for over 90 days. that's incredible.)
Hehehhehehhhh....
Yes, what interesting timing you have, carson.
(He jinxed it!)
Damned you Carson! You are the one resposible for this debacle! :-)
(ok. I disappear for year.) (:
Grex had a bizarre problem with the disk that holds /c, which seems to have started about 6am Sunday. Basically, it didn't want to talk to the disk controller. When Scott came by to reboot it, the /c disk sat there in a hung state and wouldn't do anything. Marcus and I got to the Pumpkin late Sunday night and saw what Scott did. Looking at the disk it became clear that it was truly filthy, and got a ton of dust blown off it. After cleaning it as best we could we let it sit on the table cooling down (not that it was really that hot to start with) in the hopes that the electronics was simply in a stange state because of the heat. After about an hour we put it back in the disk box, started Grex up, and waited to see if the disk activity light would stay on permently when being probed, or if it would flash on and off again as it should. It flashed; Marcus and I felt much better about things, and started to make a dump of /c. Once that was done about two hours later, we brought Grex back up so it could deal with mail for about an hour, and then permit people to log in again. It's been about 12 hours since Grex came up and the error log has no record of sd4 (/c) doing anything bad, so we might be OK. We're going to change this disk out anyway, as this was a used disk when we got it, and we've put more than a solid year of continuous use on it. We have a backup of /c right now, and there is a tape in the drive such that I can do a dump of everything that has changed since last night, and we'll be making these incremental backups each night 'till we get a new disk online.
Thanks STeve & Marcus!
Thanks for the hard work. The value of the services provided to grex (and, by extension, to me and others like me) by staffers like Scott, STeve, Marcus, and others, is incalculable.
Well, it's been 20 hours now and Grex hasn't crumbled. This is a good sign.
It's been 34 hours now and no problems with sd4. Thinking about this, we had a problem like this a long time ago, where a scsi disk locked up and did exactly what happend to sd4 this last Sunday. I'm not going to say that sd4 is OK, but I do remember that we've seen this problem once before, on I think this Sun-4/670 card, or perhaps the previous Sun-4/260 system. On monday night I made a level 1 dump of /c, which saved all the files that were modified since the last backup. It took about 20 minutes to do, took up .05 tapes, and is a reasonable form of insurance if we have problems soon. Tonight I'll do another dump at the end of the tape, which will contain all the files modified Monday and Tuesday, and I'll keep doing that 'till we've changed the disk out or decided that sd4 really is OK. Doing a backup when the system is up isn't perfect, in that "active" files aren't backed up quite right, but there are a small number of files open on /c at any given time, so at least 99.9%+ will be correctly saved.
Such fun I wouldnt trust the drive myself... mind you I have killed a few of my own drives (miss my fuji sob sob) Hope it all works out
Thanks steve for the work you're doing :-]
90 hours so far without a disk glitch. I've made two level 1 dumps since Sunday night to catch things that have changed, just in case...
I was getting some strange errors earlier.
Could you provide some details and specifics?
There are no more errors from sd4 since the reboot. The strange errors could be lots of things. Details will help us figure out what they are...
Grex had a vandal attack today which actually managed to do something. It was reminiscent of the old "fork bomb" days of old; I managed to kill it and the vandal, but we still have to figure what this dear little character did. In the mean time, I'd forgotten about the /etc/nlogin file I'd put into place to keep further logins off Grex, so we were disallowing logins for about 50 minutes where we should have been allowing them. Sorry about that... Thanks to dea for informing me both of the initial attack and my successive forgetfulness.
STeve et al... When the "nologin" is in effect, the modems hang up before they've had a chance to dump their data. Because of this, in two calls all I saw of the message that's supposed to be displayed was "Sorry"; the rest of it was lost in noise. Can you please fix this feature so it delays a couple seconds for the data to actually be delivered to the user? Better yet: if you're not allowing logins, just drop DTR to the modems so they don't answer.
Re 27 - The fork bomb is remarkably easy to do - to test it i did it on my
linux machines upstairs. I dunno how to protect a machine from the forkbomb
(apart from disconneting the telnet port) - i'm thinking of setting up a
telnet server in the UK after the exams - but i want to learn how to protect
my computer from these attacks.
I'm wondering if the grex staff (who have a lot of experience with security
etc) might point me in the right direction on the net etc. Thanks for the help
From Lionfish.
We're protected from most ways of doing a fork bomb, thanks to some special code Marcus stuck into the fork() call. But once in a while somebody gets creative and finds a way.
The recent vandal attack wasn't a "fork bomb". Grex has a kernel module that hooks the "fork" call and looks for excessive fork failures. The code is SunOS 4 specific as written; it could probably be ported to OpenBSD and maybe Linux but won't be useful to anyone who isn't interested in or already knows about how to write kernel load modules for their OS.
I was in the pumpkin today with Mark doing an inventory. While I was at it, I snapped some pictures with my digital camera and generated a new, updated Pumpkin tour page. The old one had four-year old pictures. The new one is at http://www.wwnet.net/~janc/grextech/pumpkin/
Lovely!
A very nice page, Jan. Thanks for doing it.
As a special added treat, the tour includes a picture of Mark taking inventory.
great pages, really - thankxx
I have successfully installed a second SCSI controller in Grex. I hooked up to it a recently donated drive bay containing seven disk drives, each holding a bit more than 4 Gig. The drives still need to be formatted, partitioned, and tested before Grex can actually start using them, but I think we are getting pretty close to being able to add a lot more disk to Grex than we'll know what to do with for a while.
% df Filesystem kbytes used avail capacity Mounted on /dev/sd6g 1969885 9 1772888 0% /mnt /dev/sd6h 1971009 9 1773900 0% /mnt2 So now we just have to do some testing to convince us that this drive is really OK, and then figure out what to do with it. One of the two partitions might be a replacement for /c, which gave us a scare a while back (but has shown no signs of problems since).
If /c matches /a or /b, it might be worth thinking to re-assgn
/c, and use the drive as a hot spare for /a and /b.
Why do you call the Mount MNut?
|
|
|
- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss