1 new of 467 responses total.
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.
You have several choices: