You are not logged in. Login Now
 0-24   25-49   50-74   61-85   86-110   111-135   136-160   161-185   186-210 
 211-235   236-260   261-285   286-310   311-335   336-360   361-385   386-410   411-435 
 436-457          
 
Author Message
25 new of 457 responses total.
cross
response 86 of 457: Mark Unseen   Apr 3 21:53 UTC 2005

This response has been erased.

keesan
response 87 of 457: Mark Unseen   Apr 4 15:26 UTC 2005

I have not received any spam since some time yesterday.  Did grex install a
spam filter?  Usually there are floods of it Monday mornings.
gull
response 88 of 457: Mark Unseen   Apr 4 15:55 UTC 2005

I don't know if Grex has done anything, but I find that spam tends to
come and go in cycles.
rcurl
response 89 of 457: Mark Unseen   Apr 4 16:32 UTC 2005

If you're missing your  spam, Sindi, I can send you some.   8^}
keesan
response 90 of 457: Mark Unseen   Apr 4 17:34 UTC 2005

I just got an X-RBL and an img since I last wrote.  So I don't need Rane's
spam.  Rane, try filtering JUST on X-RBL-Warning.  /a/k/e/keesan/mail/filter
has a sample filter that you can modify.  My filter is letting through only
about one spame very 2-3 days now.
rcurl
response 91 of 457: Mark Unseen   Apr 4 18:37 UTC 2005

As I think I mentioned, there is no sense my filtering since my mail at
Grex is 99% spam.  I just have to scan my inbox for any non-spam, just
as you have to do for your spam bucket, since it might catch something
you want. 
naftee
response 92 of 457: Mark Unseen   Apr 4 19:12 UTC 2005

i forward all my mail to gmail, and the gmail spam filter works great.
gull
response 93 of 457: Mark Unseen   Apr 4 19:55 UTC 2005

I forward mine to my home system, where Spamcop does a pretty good job
tagging it.  What's left gets taken care of by Thunderbird's statistical
filtering.

Now, if I could just do something about my ameritech.net account.  It
gets about 60 spams a day.  Has since before I even started using it.
keesan
response 94 of 457: Mark Unseen   Apr 5 00:15 UTC 2005

My earthlink account got nothing but spam in it from day one.  So I asked them
to give me a different email address and then I got two copies of each spam.
They were forwarding from my first address.  Rane, if you use my filter you
won't get 99% spam any more, maybe 5%, less after you add a few of your own
filters.

I have not thrown out any real mail for a while, since I removed filters such
as 'bills' and 'deal' which are too general. (I had written someone with
subject line handbills, for instance).  
rcurl
response 95 of 457: Mark Unseen   Apr 5 00:27 UTC 2005

Don't you look at your "throw-aways" to find messages that may have been
thrown away in error? That's all I do on my inbox. My inbox IS my "throw-away"
box. 
keesan
response 96 of 457: Mark Unseen   Apr 5 01:23 UTC 2005

My filter sets up a log of what went where.  Then you go through the log,
searching on 'opening', and see what went to /dev/null or the inbox.  Use pico
to search, or less (search on Opening).  It shows you which filter caught
which mail, or which mail got through all the filters to the inbox.  
Takes about 30 sec to get through when I check mail.
rcurl
response 97 of 457: Mark Unseen   Apr 5 05:25 UTC 2005

I just look at my inbox. Takes 10 seconds or less to decide if any is real
mail.
naftee
response 98 of 457: Mark Unseen   Apr 5 06:31 UTC 2005

indeed.  why waste time setting up an automated system when the human eye
will do.
ryan
response 99 of 457: Mark Unseen   Apr 5 23:56 UTC 2005

This response has been erased.

russ
response 100 of 457: Mark Unseen   Apr 6 01:46 UTC 2005

Looks like we have edonkey abusers:

duggacone dugga cone           *ft     -     Tue 21:28
duggacone dugga cone           *ft     -     Tue 21:30
duggacone dugga cone           *ft     -     Tue 21:31
duggacone dugga cone           *ft     -     Tue 21:32
duggacone dugga cone           *ft     -     Tue 21:33
duggacone dugga cone           *ft     -     Tue 21:34
duggacone dugga cone           *ft     -     Tue 21:37
duggacone dugga cone           *ft     -     Tue 21:38
keesan
response 101 of 457: Mark Unseen   Apr 6 13:53 UTC 2005

What was making top go up near about 70 a while back?  
janc
response 102 of 457: Mark Unseen   Apr 15 16:07 UTC 2005

I'm going to give an incomplete and partial report on why Grex was down so
long.

janc
response 103 of 457: Mark Unseen   Apr 15 16:14 UTC 2005

That was odd.  Try again.

I first heard Grex was down in an E-mail message from Krj saying that STeve
Andre was in the hospital.  He'd been working on repairing Grex, but had to
be rushed off to the emergency room before he got very far.  I'll leave
detailed reports on STeve's health to people who know a bit more about it,
but it was serious and he spent quite a bit of time in the hospital.  I
presume he's home now, but haven't heard anything since Tuesday, when I think
he was still in the hospital.

mcnally
response 104 of 457: Mark Unseen   Apr 15 16:26 UTC 2005

 That's terrible about STeve.  I hope he recovers quickly.
janc
response 105 of 457: Mark Unseen   Apr 15 16:29 UTC 2005

OK, gate seems to be crashing a lot.  Not good.  But to continue...

It took a bit of time for anyone else to find out what STeve had done.
But he reported that the sd0 drive, which contains the system root,
/usr/local /tmp and /a (half the user directories) had died.  He'd
backed up parts of it.

The disk actually seems to be still mostly readable.  I haven't actually
seen any error messages from it, but haven't tried to use it very much.
I don't know how sick exactly it is.

The initial feeling was that we wouldn't be able to do anything until we
got a new disk.  But on the Grex walk John Remmers and I thought up an
alternate approach.  We have some spare partitions designed to be used
to work on a new installation of OpenBSD while still running off the old
version.  By using those spare partitions to replace the ones from the
dead disk, plus some space on the big (comparitively) slow IDE drive,
we should be able to bring up the system without getting a new disk.
Then in a couple months when the OpenBSD 3.7 release comes out, we could
rebuild with a new OS and a new disk at the same time.

This was supposed to be a speedy way to get Grex up faster.  Didn't
entirely work out that way.

So Saturday afternoon John and I we in and started re-arranging thing.
We restored most things off the mirror partitions on the IDE drive.
Built a new root and a new /usr/local on the sd1 drive.  We didn't
know how to make that new root partition bootable, so eventually we
went home to research it some more.  We figured that out, and on
Monday (I think) John went back, ran the "installboot" we didn't
know about, and created the /dev partition that we had forgotten
about (it's not mirrored for obvious reasons).  This got the system
to a point where we could boot it up, but we still needed to restore
/a.

I think STeve restored /a on Tuesday.  I think he was working with his
laptop from his hospital bed.   By this time I was hopelessly buried in
my taxes and wasn't really paying attention anymore.  (I filed tax returns
for six different entities this year.)  I finished taxes yesterday and
got back to looking at Grex today.  Nothing appears to have happened since 
Tuesday.  I really have no idea why not.  Well, STeve was in the hospital
and I was in my taxes and I presume other people had things to do too.

So this morning I did some re-arranging of where /a was being temporarily
stored, and fixed some problems with mail and with quotas and turned
things back on again.

I hope that nothing was lost in the crash.  There really shouldn't have
been.

I apologize for the excessively long downtime.  It hit at a bad time
for everyone.
janc
response 106 of 457: Mark Unseen   Apr 15 16:32 UTC 2005

Grex is probably a bit slower than it was.  /a has been moved from the fast
SCSI disk to the less fast IDE disk.  So has /tmp.

Everything is scattered over fewer disks.  This means all disks are busier
and overall performance will be slower.

We have less swap space than we used to.

Shouldn't be too bad, but might be enough to be noticable at times.

We do intend to replace the dead disk and get back to something closer to our
old configuration.
mcnally
response 107 of 457: Mark Unseen   Apr 15 16:39 UTC 2005

 Permissions on /tmp are messed up.  This prevents both pine and vi from
 functioning properly.
mcnally
response 108 of 457: Mark Unseen   Apr 15 16:40 UTC 2005

grex% ls -ld /tmp
drwxr-xr-x  2 root  wheel  512 Apr 15 11:57 /tmp/

As you can see, /tmp is currently 755.
It *should* be 1777.
rcurl
response 109 of 457: Mark Unseen   Apr 15 17:02 UTC 2005

Could not delete mail on pine (which I presume is the result of the above?).
mary
response 110 of 457: Mark Unseen   Apr 15 17:27 UTC 2005

Thank you Jan, STeve and John.  
 0-24   25-49   50-74   61-85   86-110   111-135   136-160   161-185   186-210 
 211-235   236-260   261-285   286-310   311-335   336-360   361-385   386-410   411-435 
 436-457          
Response Not Possible: You are Not Logged In
 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss