|
|
| Author |
Message |
| 25 new of 467 responses total. |
mfp
|
|
response 275 of 467:
| 
Oct 25 20:06 UTC 2004 |
Point.
|
gelinas
|
|
response 276 of 467:
|
Oct 26 04:34 UTC 2004 |
It took a bit longer than I expected in #198 above, but I've begun updating
the web pages on the new grex machine. I started with faq.html.
Has java been installed?
|
janc
|
|
response 277 of 467:
|
Oct 26 05:38 UTC 2004 |
I don't think Java has been installed.
I think I need to take a little vacation from nextGrex work. I'm tired. I
have other things I want to work on. And the level of incivility around here
is sapping my enthusiasm. I need to work on something that gives me some
pleasure for a bit.
Need to figure out log rolling. The log rolling program on nextGrex is called
newsyslog. It gets run by cron and is configured through newsyslog.conf.
Need to figure out if all log files are included (things like the newuser logs
probably aren't) and figure out how often to roll each log and how long to
keep them for. Probably whatever is being done on old Grex is a template to
emulate. Some logs we want to keep forever, including newuser logs.
I think configuring the log rolling is the single most important task that
still needs to be done before a switch over.
The 'zapuser' and 'lockuser' commands need more testing. Zapuser has not been
tried on large sets of users, nor has the directory deletion (-d option) been
tested. Note that lockuser doesn't 'x' passwords - instead it expires the
account, since this is more easily reversable.
The birthday wisher hasn't been ported, though login does print out the
birthday motd.
Someone needs to comb through /usr/local/bin on Grex and make sure that
everything there has been ported. I've run across a few things that hadn't
been just at random, and suspect there may be more.
/usr/local/grexdoc probably needs to be moved over.
I wasn't sure that login was correctly reporting counts of failed logins, like
"there have been 15 failed attempts to log into your account since the last
time you tried". Both telnet and ssh should be reporting these.
Generally more testing of everything would be good.
Things that can probably slide till after we change over:
There's something that looks like source to Marcus's fork bomb killer in
Dan Cross's home directory on nextGrex. It'd be nice if that could be
ported into the OpenBSD kernel. It shouldn't be awfully hard.
Need to work out a spam filtering strategy.
Robocop needs more testing and tuning - figuring out what thresholds to set
on numbers of processes and amount of memory to use before knocking out a
user. Probably someone should test out some forkbombs and such.
When changeover day comes, there are tools for renumbering gid and uid
numbers on files moved over from old Grex that Dan wrote and I documented
and slightly fixed in ~janc/regroup
Can't think of anything else.
|
remmers
|
|
response 278 of 467:
|
Oct 26 10:25 UTC 2004 |
Given all the work you've been putting in, you're certainly entitled
to a rest. Understand what you mean about the level of incivility.
I've started looking through /usr/local/bin.
|
mfp
|
|
response 279 of 467:
|
Oct 26 14:11 UTC 2004 |
Point.
|
cross
|
|
response 280 of 467:
|
Oct 27 00:17 UTC 2004 |
Regarding #277; I did write something that would be a forkbomb killer.
The biggest problem is that Marcus decays the number of forks per unit
time over time again. That is, if you're doing something that has
a sudden burst of new process creation, but is otherwise legitimate,
you won't be automatically killed off, and the flags that say, ``wow,
this user is doing a bunch of forks...'' will be slowly reset over time.
He does that on grex by hooking into a timer of some sort, while I
do it at fork time by keeping track of the last second you did a fork
in, and then shifting by the difference of the current time and that.
This isn't optimal; we really should do something else.
But Marcus's code on grex currently left open a fork bomb only
slightly more obscure than the obvious one. In particular, vfork(2)
isn't protected, and yes it *can* be exploited to bring the machine to
its knees (I know because I've done it. I told Marcus about it but he
didn't respond). However, since it hasn't been exploited by anyone other
than me, I'm really tempted to see if we can get away without adding a
forkbomb killer at all (if for no other reason than that the prospect of
adding something to the OpenBSD kernel on every upgrade doesn't really
excite me). Perhaps per-user resource limits combined with robocop
will be enough?
|
gregb
|
|
response 281 of 467:
|
Nov 5 17:39 UTC 2004 |
Re. 277: Take a break, Jan. Nothing worse than working on something
you don't enjoy. We can live without NextGrex awhile longer.
|
dpc
|
|
response 282 of 467:
|
Nov 11 14:22 UTC 2004 |
Jan certainly has gone above and beyond the call of duty on NextGrex.
However, it seems like NextGrex is an "urban myth" rather than something
that will become real any time soon. Too bad, really.
|
keesan
|
|
response 283 of 467:
|
Nov 11 14:29 UTC 2004 |
Gelinas has also been doing a lot of work - such as changing the settings in
Pine so it will read URLs and html, for instance. He is just not being as
verbal about it. When I post bug reports he is the one who answers. Right
now he is trying to help me get links2 (which does javascript) to access my
electric bill. Lynx is hopeless at that.
|
tod
|
|
response 284 of 467:
|
Nov 11 14:50 UTC 2004 |
He's also good at inserting a tty file into my homedir when I"m trying not
to idle out.
|
gelinas
|
|
response 285 of 467:
|
Nov 11 14:57 UTC 2004 |
Hmm?
|
mfp
|
|
response 286 of 467:
|
Nov 11 16:05 UTC 2004 |
Re. 284: ;) (as it were)
|
tod
|
|
response 287 of 467:
|
Nov 11 16:36 UTC 2004 |
re #286
*wink wink* *knudge knudge*
|
tod
|
|
response 288 of 467:
|
Nov 11 16:47 UTC 2004 |
re #285
This file was not inserted by me:
grex.cyberspace.org% ls -al tty
-rw-r--r-- 1 tod denizens 0 Nov 10 19:47 tty
As it were, my connection magically ceased at the moment that file was put
into my directory.
!last tod | more
tod ttysf 65.110.50.10 Thu Nov 11 11:32 still logged in
tod ttyqf 24.16.228.160 Thu Nov 11 09:28 - 09:51 (00:22)
tod ttyt4 65.110.50.10 Tue Nov 9 11:32 - 19:37 (1+08:04)
tod ttyra 24.16.228.160 Tue Nov 9 07:41 - 08:31 (00:49)
I would appreciate an explanation from the hacker that keeps putting the tty
file into my homedir as if I'd created it. Rather than engaging in a dialog
with me, they feel they can just mess with my homedir and Grexing.
|
naftee
|
|
response 289 of 467:
|
Nov 11 19:19 UTC 2004 |
Maybe it's your son.
|
keesan
|
|
response 290 of 467:
|
Nov 12 01:05 UTC 2004 |
Would item 4 be more appropriate for this problem?
|
eprom
|
|
response 291 of 467:
|
Nov 12 04:32 UTC 2004 |
funny...there doesn't seem to be any over lap in time...must be magic
|
cross
|
|
response 292 of 467:
|
Nov 13 21:08 UTC 2004 |
Actually, the mtime of that file is ten minutes after tod's session on
ttyt4 logged off. Though Jeff is strictly speaking correct that there's
no overlap, it's pretty close. I suspect, tod, that the real problem is
a bug in your script, which somehow touched a tty file as opposed to
something else.
|
tod
|
|
response 293 of 467:
|
Nov 15 18:06 UTC 2004 |
The tty file wasn't there until someone(other than myself) put it there.
|
cross
|
|
response 294 of 467:
|
Nov 15 21:11 UTC 2004 |
I don't know. What if `tty` printed out `tty device not found` or something?
|
naftee
|
|
response 295 of 467:
|
Nov 16 02:11 UTC 2004 |
Yeah?
|
blaise
|
|
response 296 of 467:
|
Nov 16 15:55 UTC 2004 |
Tod, the point Dan and Jeff were trying to make is that the tty file did
not *cause* the logoff, because it did not exist until *after* the logoff.
|
tod
|
|
response 297 of 467:
|
Nov 16 16:35 UTC 2004 |
Let's talk about how the tty file got into my homedir in the first place,
shall we?
|
gelinas
|
|
response 298 of 467:
|
Nov 17 01:42 UTC 2004 |
Short answer: Your script doesn't work.
I don't know why it doesn't work, though.
|
dpc
|
|
response 299 of 467:
|
Nov 19 15:25 UTC 2004 |
Anyone else care to comment on the likely fate of NextGrex?
|
