OK, I can't figure out which item to use to report progress on NextGrex, so I'll start a new one.467 responses total.
I've installed OpenBSD 3.4 and completed all setup tasks that have been documented in the grexdoc CVS archive. So /suidbin is set up, things from the ports tree installed, and party, orville-write, backtalk, fronttalk, gate and all the grex-scripts that Dan Gryniewicz ported are back. nethack in the ports tree wouldn't compile with the -no-x11 setting. aspell, which didn't work in 3.3 does work in 3.4 w3m didn't build out of the ports tree.
I think my next focus is going to be: (1) Get Dan Cross's login patch reinstalled and documented. (2) Do a newuser port.
OK, I (easily) found Dan's login_grexpass source. I've moved a copy into the grexdoc archive, together with install instructions and done the install on nextGrex 3.4. Time to look at newuser.
(thanks, Jan.)
Modified the 'passwd' program so that it does kg_pwhash() passwords correctly. Previously it only understood/set crypt() passwords. Of course, openBSD crypt() is an extended version that can handles about six different password encryptions. The really nice way to handle Marcus's passwords would be to fold it into the crypt() function ... but we can't do that. Marcus's needs an extra argument passed in that none of the others do. Fooey. So there are two mods here, one so it understands kg_pwhash() passwords when asking users for their old passwords, and one that it uses kg_pwhash() to set the new password. Constructed install scripts to apply these mods to the stock passwd source. I've got a first draft of a port of newuser to openbsd. Compiles but not tested yet.
I still don't get it; why do we want to switch with the kg_pwhash() stuff?
We don't want to switch to it. We have already switched to it. There has been some discussion of switching away from it, but staff has not come to an agreement on that. Personally I'd prefer using something standard. But I don't feel strongly about it, and I'm not going to decide that unilaterally, and I don't want getting NextGrex on line to have to wait for a decision on that.
What decision? If we can authenticate users with kg_pwhash, and create users with something `standard', how's that holding things up?
That's holding things up because before we can go live with a system so configured, Grex staff has to decide if that's what we want to do. There are people who have strong feelings about both sides of that question and it is not going to be easily resolved.
OpenBSD permits login IDs up to 31 characters long. I'm inclined to modify newuser to permit this as well. With thousands of logins being used, increasing the name space might be nice. OpenBSD also allows underscores, dashs and dots in login names. I'm inclined to have newuser NOT allow any of these. I don't really want to have different users named joecool, joe.cool, joe_cool, and joe-cool.
I think extending the length of login ids is good. I think eliminating special characters from login ids is also good.
I concur.
re 10 HEY I think joe is cool.
Re: 11, 13 - although, w/ 31 characters, you might want to permit uppercase and/or underscores.
NOT underscores. Distinguishing between JoeCool, joeCool and joecool is just asking for trouble. I strongly advise against allowing such things.
New version of newuser successfully created an account. Needs more testing and some fixing up of the default dot files before I'm ready to call it done though. Source code, build and install scripts are in CVS.
NB: The convention in mail is to replace spaces in names with dots, originally underscores. So allowing dots or underscores in a login name is going to lead to confusion in mail, if only in the minds of people writing the messages.
Regarding long login id's, I'd be a little cautious. How much software is out there that retrieves login id's, assumes that they're at most eight characters long, and would then proceed to break in various ways in the presence of longer id's? Come to think of it, I should look at the vote program and see if I'm making an assumption about login id length.
Vote program seems to be okay. I do make the assumption that login id's (and certain other data items) don't exceed a certain #define'd constant that is currently set to 128 and which could easily be changed. Guess I was forward-looking, eh? However, I'm still concerned about other software.
Actually, even the 128 restriction applies only to login id's of candidates. Login id's of voters are obtained from the password database using standard functions, so that part should work right no matter how long login id's can be.
This response has been erased.
It's something I typed in so I'd have a test page. First thing that came into my head. It's probably possible to anonymously read the conferences on NextGrex. Few things could be less interesting. Yes, there is a risk of old software breaking with longer-than- eight-character logins. I think it's a risk worth taking. I'll have to review party and write. I don't think a 31 character login is very desirable, but 9 or 10 would be very useful. There are system constants that tell how long logins can be. I think limits.h provides one called MAXLOGNAME which is one more than the maximum size, and pwd.h provides another one, something like PW_MAX_LOGIN. There is another one around too. This is all from memory and probably not right. Can't look right now.
This response has been erased.
This response has been erased.
Customizing grex too much makes me cringe. Things like login changes scare me a little. Are they slightly more friendly? Yeah, maybe. Do many users notice? Probably not. Is it worth integrating changes into login every time we upgrade grex? I should think definitely not.
It's a definite trade off. Our past experience was that changing "login incorrect" to a more specific message, like "login does not exist" or "password incorrect" or "account locked" reduced the number of requests for help to staff significantly and also made the help requests substantially less confused. That meant that the problem could often be solved in one interation, instead of having to write back and forth a few times before you and the user had figured out why they couldn't log in. I think login actually prints a few lines of explanation for things like locked accounts, together with a url of a page that explains more. So it's a fairly simple change to 'login' that results in a substantial reduction in staff time needed to support users. I package things like this up as a patch applied to the stock login code. Odds are reasonably good that the patch will apply cleanly in the next release. Eventually it will fail and need to be fixed up manually. Such is life. I think this is a mod worth the effort.
I checked that backtalk, party and orville write all handle long login names. They do. Good work on my part. I thought for sure party would have problems, but it's fine. Some of the stock utilities are less than brilliant. Here's finger output: Login Name Tty Idle Login Time Office Office Phone bhoward Bruce Howard p4 49 Sat 20:03 Tokyo cross Dan Cross p0 49 Thu 21:53 gelinas Joe Gelinas p3 - Sat 20:53 janc Jan Wolter p1 49 Sat 01:34 janc Jan Wolter p2 - Fri 12:31 userwithaverylongname User With a Very Lon *p5 - Sat 20:19 I'd have tried harder to keep the columns lined up, truncating gecos more if necessary, like this: Login Name Tty Idle Login Time Office Office Phone bhoward Bruce Howard p4 49 Sat 20:03 Tokyo cross Dan Cross p0 49 Thu 21:53 gelinas Joe Gelinas p3 - Sat 20:53 janc Jan Wolter p1 49 Sat 01:34 janc Jan Wolter p2 - Fri 12:31 userwithaverylongname User Wi *p5 - Sat 20:19 I'm tempted to set newuser's limit at something like 14. This would be no help at all with code problems, but it'd avoid some ugliness in screens formatted with the assumption that login names aren't too long.
I, too, think the changes are worth the effort.
Similarly, the output of `w' is ugly, as is that of `who'. And are we going to modify every utility to deal with our own non-standard login name sizes? Has the lack of support for login names longer than eight characters ever been recognized as a problem before? And if not, why not just leave the limit at eight? It's what most of the rest of the world assumes; why make bother being different if it's not a real problem? If it ain't broke, don't fix it. About the login mods....I read the staff mailing list. Usually, the questions from people who's accounts have been locked say things along the lines of, ``Why can't I login? It says account locked; what gives?'' It strikes me that a quick `grep' can be just as effective in figuring out what's going on with a user. Perhaps a `userstat' command that picks out information and recent actions about and on an account would be helpful (actually, I think it'd be helpful regardless of whether the login mods stay or not). Changing a user's shell to a program that just prints out a message and logs them out would be just as effective and certainly more durable than a patch to login. At anyrate, I don't buy the argument that patching login saves staff a lot of work.
Joe slipped in.
From what I've seen above, the only "modification" needed for long names
is setting a constant.
I've listened to arguments, on other other systems, about customised login
error messages. In general, the customised messages have made life easier
for the users, especially when there are several different reasons for
any particular account to not work. For example:
Your password is correct but you are not authorised to use
this service
Another change was occasioned by the proliferation of a .login trojan
that mimicked the standard failed-login sequence and then collected the
re-entered password and mailed it off to the 'bad guys.' Changing the
error message helped alert users to the real problem and let us track
down the modified files, e'en if we didn't find the perpetrators.
(I'm fairly certain that the trojan was spread as an IRC client: "Telnet
here, log in with this name and password, and it will install IRC on
your account.")
I've usually handled the ``you can't login to this server'' thing with a special shell. In fact, I wrote one once that did the job pretty well. I can kind of see the thwarting trojans thing, but I'm not convinced it's that much of a win.
OpenBSD by default allows 31 character logins. No modification to the system is needed to do that. If we want shorter logins, then we just don't issue long ones. That's mostly up to newuser. Unixes with longer logins are not that unusual these days. I would expect just about any modern, actively maintained software package to include support. Where we are likely to find problems is more in locally written packages that aren't widely distributed. The ones I'd most worry about are Picospan and Marcus's old sendmail. I haven't seen people complain about the 8 character limit, but I've seen hundreds of logins like "unixwzrd" that are in themselves an implicit complaint about short logins. I myself use logins like "janwolter" on many sites. So far we haven't run across any software that has real problems with long logins. If we do, it's a trivial change to newuser to not issue long logins. But I'm hoping we can run with them.
Finished web-newuser. I've placed password protection on the entire cgi-bin directory so it can't be run by non-staff yet. All source and install scripts and instructions are in CVS.
Installed idled from ports tree and set up a config file for it similar to the one on old Grex. Haven't tested it or put it into an rc file yet.
Added a TO_DO file to the CVS archive. Current contents:
--------------------------------------------------------------------------
Disk Quotas -
Somebody set these up on the openbsd 3.3, but I forgot who and have not
got around to searching for the documentation that I think was posted to
the bbs.
- Needs to get into the document archive
- Newuser needs to be modified to initialize quotas correctly.
Fork Bomb Killer -
On Grex this is a kernal mod that kills all a user's processes if he tries
to get too many. An equivalent for OpenBSD would be nice.
Login Mods -
Grex's login program gives more friendly error messages than the stock one.
Are there other mods?
Queuing Telnet Daemon -
We are probably going to skip this
Mail Modifications -
Various customizations to sendmail and mailers:
- Hierarchical mail directories
- mailbox size quotas
- spam filters
Robocop -
Needs to be ported. bhoward is looking at it.
Newuser/web-newuser -
mostly done. Quota code needs work.
Picospan
Menu shell
Help/Change scripts -
How many of these have been done?
Zapuser, lockuser -
Joe is looking at these.
----------------------------------------------------------------------------
There's probably a lot I am forgetting.
ftp daemon? IRC server?
(Just for funzies, I ran useradd on the CVS server and created a longish login id. Yep, it actually did it. Yep, the output of "who" looks sucky.)
Show us!
I don't think I'm going to be able to fix zapuser. As Jan indicated somewhere, it's probably going to need a thorough re-write.
Re #39: remmers ttyp0 Dec 31 08:53 thisisalongloginid ttyp1 Dec 31 08:54 johnremmers ttyp2 Dec 31 08:57
re 41 You're right, that's horrible
This response has been erased.
It's been a while since any one has said anything here. In the interim, we
have:
enabled quotas
set up and started named
started moving the scripts from /usr/local/grex-scripts
made progress on zapuser (thank you, janc. :)
started transferring the grex web site
(try: http://grease.cyberspace.org/ )
and probably some other things I've forgotten.
Where was this linked from?
I just linked this item from garage at the request of a garage participant, gelinas.
(And it was linked _to_ coop. Thank you, cmcgee. :)
Re way back there: Anyone ever considered eliminating case sensitivity in logins?
I think all are agreed that it is NOT a good idea to have Drew, DREW and drew refer to more than one person.
Yes, making them case sensitive creates an opportunity for abuse and confusion with no benefit that I can see.
And IIRC internet mail standards specify case-insensitivity. If so, case-sensitive usernames could really be a problem.
Last I heard, only for the right-hand side of the address, Dave. Way back when, I saw a system that did, indeed, distinguish between people by case-sensitivity.
On yahoo though sending a mail to XYZ@yahoo.com and xyz@yahoo.com is the same.
From RFC 821: Simple Mail Transfer Protocol (Postel, 1982): Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and SMTP implementations must take case to preserve the case of user names as they appear in mailbox arguments. Host names are not case sensitive. That said, I agree that case-sensitive usernames on NextGrex would be a bad idea. (Are upper case characters in login id's even allowed on Unixy systems? I don't think I've ever seen a login id with an upper case character in it.)
Yes, uppercase logins are allowed, but there is some warning about it. Basically, from Unix System Administrator's Handbook, "Uppercase characters are fine as long as the user won't be reciving any e-mail." I wonder what would happen if somebody tried. You will have to experiment.
This response has been erased.
Why? They'd probably improve your overall impression.
re #54 Please don't quote obsoleted rfcs. rfc822 was obsoleted by rfc2822. rfc 821 was obsoleted by rfc2821. (warning, don't look at this url on dialup, http://www.rfc-editor.org/rfc-index2.html) As far as case sensitive usernames, don't allow.
I wonder if postel is still alive.
No, he is not. :(
Is there anyone who's willing to do textual analysis of the world-wide corpus of s-emetic writing, and then write a filter to keep jews off nextgrex?
On some older UNIX systems, logging in with your username in all uppercase would cause it to assume you had a terminal that could not handle lowercase letters, with somewhat unpleasant results.
That's true on the present Grex.
Re #58: Oops, sorry about the obsolete quote. However, rfc2821 says essentially the same thing about case-sensitivity that rfc821 did. I think it would be reasonable on NextGrex not to allow uppercase characters in login id's, and for the login program to map upper to lower case at the "login:" prompt. The behavior that gull refers to in #62 should probably go away. This is the twenty-first century, after all.
Utterly bizarrely, it seems to be true on Debian 3.0, too, although some proggies seem to disregard this rule.
What's the dilly yo?
My plan is to resume work on NextGrex next week. I think the first step is going to be to install OpenBSD 3.5 Well, there are a few other firster steps, like getting the machine turned back on and checking to see if I remember the root password or not.
Er, what's on it now?
OpenBSD 3.4, IIRC. I don't know what is up with grease; I'll plan to visit the pumpkin after supper, unless someone else gets there first.
Yes, the machine was turned off. I don't know why. It's coming up now.
Re: #69. Ah.
Good point, twenex.
I've upgraded Next Grex to OpenBSD 3.5, and reapplied all the
customizations that we'd worked out on previous rounds (except for
quotas which I've delayed reapplying because they make boots slower).
The rebuild process went pretty smoothly. Biggest problem was that
doing ftp installs is very slow over Grex's ethernet (and probably
contributed to some slow connections to Grex over the last couple days).
In the future we should probably burn all the files we need onto a CD
and walk them over to the pumpkin. I want us to be able to rebuild Grex
in under 24 hours.
I haven't actually tested that everything works as it is supposed to.
I'm going to turn now to fresh work. My list:
- port "robocop". It's unclear if we'll have the fork bomb kernal
mods that Marcus did on the current Grex. Without that, having
robocop becomes even more important.
- modify "newuser" to initialize disk quotas for new users.
- port "zapuser" and "lockuser" - these are the admin tools used to
delete/lock user accounts.
Kip is going to work on mail - main issue is mailbox quotas.
Heirarchical mail directories would be nice, but that doesn't
necessarily need to be in place before moving over to the new system.
As much spam filtering as we can afford without eating up the CPU would
be nice too.
If we go to hierarchical mail directories, we need to ensure that all
the mail clients understand them.
I think we need to port over Mic's menu shell, and possibly some of the
change/help scripts that Valerie mostly wrote.
I think that's all. Not really much.
Woo hoo!
Another option for handling mail quotas is to have the individual users' mailboxes in their home directories. (Exim can handle that quite easily using either Maildir or mbox format.)
Re #73: Very nice. Thanks for the update and for all your work on this. Re #75: That's a possibility. Downside: It opens up a new avenue for abuse -- a malicious person could cause someone else's disk quota to be exceeded by bombarding them with mail.
This response has been erased.
Yes, it is. We KNOW that there are people who would quite happily blow many of their acquaintances over quota, given the opportunity. I'm sure you can think of a name or two, if you put your mind to it.
:(
This response has been erased.
I don't think it would be a huge problem either, but getting a mail program that handles quotas set up is not rocket science. I'm sure it would work better than just having the write to the mailbox fail.
I'm currently working on porting robocop. This is the least portable program we have - it pretty much requires a full rewrite and will require more work later to tune it to the new system. It is a process monitor, and the process table is one of the least standardized parts of Unix. It also depends on many other very system-dependent things, like the mapping between device names and major and minor device numbers. I'll likely have to spend a couple days on this. Part of the problem is that because it depends on very system dependent parts of OpenBSD, I'm largely dependent on documentation written by the OpenBSD folks, who generally write sucky documentation.
OK, I have a near approximation to a working robocop. It compiles. It runs. It doesn't kill me. Can't really tune robocop until we have some real users to test it on. It takes some tuning to get it working 100% right. When NextGrex comes up, it'll be running in a diagnostic mode. It'll probably be a few days before it is tuned well enough to turn fully on. Once kip does something about the mail, robocop will need to be adjusted for that. I'm going to go on to a few other admin tools.
Since much of the source code that needs to be ported to nextGrex is no old Grex, I wasn't able to do all that much while Next Grex was down. I did port two admin tools: zapuser and killu. One deletes user accounts and it part of our reap process and the other kills user processes, like fork bombs. I'm currently working on porting Mic's menu shell. I'm not sure if the old menu shell is still being used on old Grex, but I'm not going to port it to new Grex. One menu shell is enough. This is not particularly hard to port. Mainly I'm just going to be reviewing and cleaning it up. Like there appears to be an option to display the latest version of Horst Mann's BBS list for the 313 area code. Horst Mann's BBS list was last updated in 1994 and the 313 area code was split years ago. I'm not convinced this is still useful data. The biggest task that must be done is to install a Mail Transport Agent that does quotas. Kip is planning to install exim. Here'a a page that talks about a scheme for doing mailbox quotas right with Exim: http://www.timj.co.uk/linux/rcpt-time-quota-maildir.php This is based on maildirs, I think, which we don't want to use, I think, but that actually makes things easier, not harder, I think. The basic idea is actually pretty close to Marcus' sendmail mods, and some ideas from Marcus's version could be rolled into it to make it better. Less vital, but still important, is building spam filtering into the MTA. I strongly doubt that we could run SpamAssassin - it's too slow. But we should investigate other off-the-shelf spam filters that could be used on Grex. It wouldn't have to be awfully good to be better than what we had in the past. The other modification to standard mail on old Grex is the hierarchical mail directories. This would be desirable on new Grex, but I think we could come up without it and put it on the list of things to possibly look at in the future. An alternate solution to look at might be to put the mail partition on some sort of file system that handles large directories better. Dunno if that is available for OpenBSD.
....Or just put mail in home directories, which has been suggested before. I'm against using Exim; it's not one of the Big Three: Postfix, Qmail, and Sendmail. Spamassassin can be run in a `daemon' mode that makes it much faster. This is what the OpenBSD people champion doing.
We'd still kind of like to block the spam _before_ it's crossed our WAN link. I really don't know how well that will work. Paying only cursory attention, I've sort of gotten the impression that heirarchical mail directories are becoming standard. I'm opposed to putting mail in home directories. It's one thing to maliciously deny a user access to more mail; it's another to maliciously deny a user access at all. But we've had this argument before. :)
Thanks Jan - great work on porting everything! Like you say, the menu shell (driver program) is readily portable - one or more of the menu template (hence scripts), like you say, will need pointing to the right places on the new system. Thus, the intended design of the new menu system has been met well (i.e. flexibility to change, especially for non-programmer types). Just happens, in this instance, that a very good programmer is updating the links :) I concur with you that there is no good reason to also include the old menu system on Next Grex.
Regarding #86; We have had it before, it's true. But please explain to me how mail in home directories can deny a user access to grex at all? Is your reasoning that someone can mailbomb a user, forcing them to go over quota? I'd say they can just login and clear out their mailbox. Regardless, I'll be surprised if there aren't plugin options to deliver mail to hierarchical directories for any given MTA we'd be likely to pick.
I have no opinion what mailer is the right one to use. However, Kip has
substantial experience with exim, and he's willing to do the configuration.
I've done some basic research on exim, and it appears to be quite possible
to do everything we need to do with exim. So going forward with exim appears
to be a workable plan with a person ready to execute it. I'm not going to
oppose that plan unless there is another option that has a higher probability
of happening sometime soon.
Actually, I did "need" to make a few more changes to the menu shell
interpretor. There were bits of code that worked just fine, but tended to
make me wince. For example I changed the "getHomeDirectory" function from
this:
char homeDir[30] = "";
void getHomeDirectory(void)
{
int notSpace = TRUE;
char c = ' ';
int i = 0;
FILE *crapPtr;
system("finger `whoami` | head -2 | tail -1 > /tmp/newmenu.`whoami`");
system("chmod 777 /tmp/newmenu.`whoami`");
if ((crapPtr = fopen("/tmp/newmenu.`whoami`", "r")) == NULL)
{
/* ignore this case */
}
else
{
while (i < 11)
{
fscanf(crapPtr, "%c", &c);
i++;
}
i = 0;
while (notSpace)
{
fscanf(crapPtr, "%c", &c);
if (c == ' ')
notSpace = FALSE;
else
homeDir[i] = c;
i++;
}
fclose(crapPtr);
system("rm -f /tmp/newmenu.`whoami`");
}
}
to this:
char *homeDir;
void getHomeDirectory(void)
{
struct passwd *pw;
if ((homeDir= getenv("HOME")) == NULL)
{
if ((pw= getpwuid(getuid())) == NULL)
{
fprintf(stderr,"Whoops, who are you?\n");
exit(99);
}
homeDir= strdup(pw->pw_dir);
}
}
The new version is actually overkill. The "HOME" environment variable is
actually always going to be defined, so the failback method is never going
to be used. I could really have done it as:
char *homeDir;
void getHomeDirectory(void)
{
if ((homeDir= getenv("HOME")) == NULL)
{
fprintf(stderr,"Whoops, who are you?\n");
exit(99);
}
}
The old version worked when I tested it, but if you do an "ls /tmp" on Grex,
you'll see numerous newuser.username files there, so it appears that it
fairly often leaves detrious behind. I'm sure that today Mic would never
write code like that - it's clearly a relic of his callow youth, best erased
and forgotten. Pretend you didn't read this item.
There's a hunk of code that captures "!cd" commands. That wasn't working on
the OpenBSD system. I started debugging it, but was struck by a more modest
wince reflex, and decided to rewrite it before debugging it. There was quite
a lot of spurious copying of data from array to array in the original, and
I thought it was easier to clean it up than to figure it all out. There were
some subtle bugs in the original too. Looked like the command "!cdrom" would
be interpreted as a cd to the "rom" directory.
To a naive user, the error messages and other effects of being overquota are, in and of themselves, a denial of service, Dan. You've been too long away from that naivete. :(
Finally figured out how to get robocop checked into the CVS archive. There were some weirdnesses that were preventing a checkin. Completed port of the menu shell, and testing of everything it displays.
Menu shell is in CVS archive.
Installed figlet from the ports tree, and added the install script for it to the CVS archive.
Installed on NextGrex (and in the CVS archive) the extract, forget, partname, and findconf comands. These are useful but little known commands to do some simple bbs operations from the shell some are used in some scripts. See man page for extract/forget. These are derived from the ancient bbsread source. I should replace them with new version derived from Backtalk source (which is distantly related to bbsread source) or based on Fronttalk, but I'm not going to take time to do that right now.
Regarding #90; Perhaps you're right, Joe, but isn't that an issue we're going to have to deal with anyway?
Oh, yes, it wasn't the best C code - sorry. Thanks for the improvements.
Months (years?) ago I'd set up some cron scripts which were supposed to periodically back up everything to the IDE drive using rsync. These weren't working. Repaired them.
Yes, Dan, but there is a difference between going over quota by your own action and being forced over quota by something beyond, not even under, your control.
Currently when we lock a user account, we modify the password field, so it
is no longer possible to log in. This is a non-standard practice that would
require writing custom tools to preserve. I believe that we should instead
shift over to locking accounts by expiring them.
One problem with this is that the authenticator Backtalk uses does not
understand account expiration, and will let people log into expired accounts.
But this is a feature that should be added into that program anyway, together
with the ability to recognize the /etc/nologin file. So the next task I'm
going to take up is making account locking work. This will include:
(1) update the "lockuser" administrative script to use the OpenBSD tool
(I think it's "usermod" to lock accounts instead of Marcus's old
pwadm program).
(2) update the Backtalk authenticator, pwauth, to understand expiration
and such.
I think it is possible that to thoroughly lock an OpenBSD account I might
need to change the shell to some kind of "noshell" thing as well as expire
the account. I'd prefer not to do this if I can get away with it though,
because this makes it much harder to unlock the account - you have to remember
what their original shell was. If anyone has input on this, I'd appreciate
it.
A lower priority related change would be to modify backtalk to do something
better with expired accounts, expired passwords, and /etc/nologin. Currently
backtalk on Grex uses "basic authentication" - that little pop-up login
window. The problem with this is that there is now way to tell a user
why their login failed. Non-existant login ID, wrong password, expired
password, locked account, /etc/nologin turned on - whatever it was you just
get a new login box and no clue what is wrong. Only when you try to telnet
or ssh in will you (I hope) get some kind of sensible message.
I could do better with backtalk if I used the already existing option for
doing form-based authentication. In this configuration instead of the
authentication being worked out between your browser and the Apache http
server, backtalk itself does the authentication, and can thus generate
sensible error messages. The problem is that in this configuration backtalk
uses session IDs to identify logged in users. These session ID's are kept
in a cookie, and cookies are passed by Apache to backtalk in an environment
variable. Any user logged into Grex can do a "ps -e" to see the environment
variables on any process. (Some Unix's prevent this - OpenBSD does not.)
This anyone could grab any other logged-in Backtalk user's session ID and
impersonate them in the conferences. Not a good thing, and not very fixable
on Grex.
Probably I'll look into Apache to see if I can make it redirect to an error
page if logins are expired or prevented by a nologin, as opposed to just
asking the user to try logging in again. I think this should be possible,
but it's going to take some time to figure out. I may let this slide till
after NextGrex comes on line.
To change the shell field in /etc/passwd in a reversible way, add an x to the path: e.g. /bin/bash becomes /bin/bashx. If necessary, /bin/bashx could by a symlink to some standard "no shell" shell.
Speaking from ignorance, wouldn't expiring an account immeidately subject it to being reaped during the next "cycle"?
No and yes. Reaping is based on how long since the account was last successfully logged into. We run a program periodically that removes all accounts more than 90 days old (really two programs - reapcheck finds the accounts to delete, zapuser deletes them). This is based on the "lastlog" file, the same file that is printed when you finger a user and it prints the last login date. In most modern Unixes you can associate an expiration date with each account. This is saved either in the /etc/shadow file (Linux) or in the /etc/master.passwd file (BSD). After that date, it is no longer possible to log into the account. Grex has never used this feature in the past. Normal Grex accounts have no expiration dates. When I say expiring an account, then I mean setting its expiration date to zero - January 1, 1976. It then becomes impossible to log into the account. If a reap is run a few days after the account is locked, it won't be deleted, since it would likely only have been a few days since the account was logged into. But eventually a locked account would be reaped, since it will eventually have been idle for 90 days. Except, come to think of it, I think we normally delete locked accounts faster than that. I forget the rule.
Thanks for the explanation.
I HATE that "password expiration" stuff - and if you ssh, it gets even more weird. Aged, Euthanized accounts are not even remotely a problem ;-) Go, Janc,Go!
Wouldn't changing the shell to notcsh, nobash, ... where these are links to /etc/nologin give a better message than changing the expire of the account? Of course backtalk would have a slightly different check to make in this case.
My concern with changing the shell has more to do with whether or not there are ways to log into accounts that are expired. There are so many way to log in, and I'm not sure all recognize expiration.
I've done a little work on upgrading pwauth, but time has been short. If only one person is going to be working on your system, you'd do better to pick one with less going on in his life. Anyway, the pwauth thing is a bit complex because it's not a Grex-only piece of software like robocop, but something I distribute to many users all over the net, so changes have to be made in a portable, compatible manner. Which is a pain in the keester. Password and account expiration seem to be handled in two different ways by different version so of Unix - BSD derived systems that have a /etc/master.passwd file use one system, while Sun and Linux systems that use a /etc/shadow file use another. In OpenBSD, and many other versions of Unix there is a higher level interface to all of these via the login.conf file, and openBSD has some nice procedure calls where you can directly invoke these, but these calls seem to be unique to OpenBSD, not available on FreeBSD or NetBSD. Of course, Linux and PAM use PAM instead of login.conf (pwauth already supports PAM). FreeBSD somehow seems to have both PAM and login.conf. I haven't figured out yet if this is insane or not. I think for now I'm going to ignore login.conf and write login.conf to use the lower level procedure calls to do checks for account expiration itself. The joy of Unix.
This response has been erased.
This response has been erased.
OK.
OK, it took me too long, but I now have a new version of pwauth, the
authenticator for backtalk installed. It has a couple new features:
* Authenticates through the login.conf method. For Grex this means
that it will recognize both the standard OpenBSD encrypted passwords
and weird Marcus encrypted passwords without us having to do
anything special to teach it about them - the mods we made to make
login work will now automatically work for pwauth too.
* It will now refuse logins if there is a /etc/nologin file in
existance.
* It will not allow logins to expired accounts or to accounts with
expired passwords.
The reason that this took longer is that pwauth is a shareware package
that I maintain. I wanted the Grex mods to be in the standard
distribution, but that means I have to do them in a much more thorough
manner - they need to be portable to non-OpenBSD systems and need to
be fully documented and need to be tested on multiple operating systems.
But this is all done, and checked into Grexdoc now.
I have Orville write configured to keep it's wrttmp file in /var/run on the new system. For some reason, the file disappears from time to time. I haven't a clue why, but it breaks Orville. I moved the wrttmp file to /var/log in hopes that whatever was eating it in the old location would leave that alone.
Correction to one of my previous posts: FreeBSD uses PAM, not login.conf. Having muddled with them both quite a bit now, my vote is for PAM. Though it has some issues (mainly because the original spec writers were vague about some key details), it's really much nicer than login.conf. Of course, they don't actually provide exactly the same functionality.
I think my next step is to update the "lockuser" admin script to expire accounts instead of X-ing their passwords, using usermod instead of pwauth. This should be quite easy. After that, I guess I need to talk to Kip about exim.
I notice that someone in the board minutes says we need to upgrade to OpenBSD 3.6. OpenBSD 3.6 will be out in November, and I fully intend to have nextGrex up before then. Looking down the feature list, I see nothing that we can't live without. I have no plans to upgrade to 3.6.
Applied some more OpenBSD security patches.
You go, Jan!
OH JAN
Thanks, Jan. Can't wait!
Huge thanks, Jan. HUGE.
Yeah, what Mary said- Thank you!!!
Grex was down for backups when I went to work on lockuser yesterday, which stopped me because I couldn't get the old lockuser source off Grex. So I skipped ahead to doing an exim install. Exim is the mail transport agent (MTA) we want to use instead of sendmail. This is the hunk of software that handles all the mail going in and out of the system. It puts your incoming mail into your mailbox file for you to read, and passes your outgoing mail to whatever system it is addressed to for handling. The copy of exim in the OpenBSD 3.5 ports tree is sadly out of date, so I'm doing the install based on the tarball from exim.org. This is going smoothly so far, but slowly since I am following my usual procedure of writing scripts to do the installation/configuration instead of just going in and doing it. But I think I'm close to having it up and running. However, there is one major modification to exim that I think we need - the mailbox quotas. When another system connects to Grex to deliver an email message, it first gives a short description of the message - who it is for, how big it is, etc - and then Grex gets to say if it will accept it or not. If it accepts it, the message is transmitted over Grex's link to Grex. Now exim does have code built in to set limits on how much mail a user may have, but that check is done after the message has been transmitted to Grex. This is not so good. One of the common scenarios where a mailbox is filled up is if someone is getting mailbomb - thousands of messages being sent to them. Probably pretty quickly the mailbox will fill up, and the mailbox quota will prevent it from growing anymore, so the mail disk won't get full and other users will still be able to receive mail. But even after the mailbox is full, all those mail messages will still be going over our net link, which with Grex's rather slow net link is a big problem. A related problem is what to do with the messages that don't fit in a users mailbox. In the case of legitimate emails, we'd prefer to bounce them back to the sender, so the sender knows they didn't go through. To bounce the message after we have accepted it, we'd need to email it back out. So each one goes over our net link twice. Furthermore, we have to mail it back to the address on the "From" line. But, nearly all spam has bogus addresses on the "From" line. It's either a non-functional address or the address of some innocent person who knows nothing about this (you probably occasionally get bounce messages that you never sent - this is why). The mailbox quota system Marcus did for old Grex was smarter. It rejects the message earlier. When a system comes to Grex and asks if we'll accept a message of a given size for a given user, it checks the user's mailbox, and if it is full, rejects the message immediately. So the message never gets transmitted over Grex's connection. Furthermore, the disposal of the undeliverable message is the problem of the other system, not of Grex. Since the other system is very likely the system from which the message originated, it can usually do a much more intelligent job of bouncing it back to the right system. So Marcus's method is obvious far superior to the standard method, which makes you wonder why the standard method is standard. Well, the problem is that modern MTAs are built on a very modular architecture. The part of the program that accepts mail from other computers is completely isolated from the part of the program that delivers mail into local mailbox files. So when we are accepting mail, we are in a piece of software that doesn't know that mailbox files exist, and may not even know exactly what it is going to do with the mail after it accepts it. So to make this work in exim, I need to link these two isolated hunks of code. The general scheme would be to have a database that keeps track of the state of everyone's mailbox. At message accept time, we'd need the ability to check this database to see if a user may recieve mail. Then we need something to watch the user's mailboxes and keep the database up to date. User's mailboxes mostly change in two ways - the MTA adds things to them, and user's mail client programs (pine, etc) take things out. I may well be able to modify exim to update the mailbox everytime it delivers mail. I'm not going to modify all the different mail clients though (heck, It's possible to read your mail with "vi"). So probably there will be a daemon process that periodically scans user mailboxes to update the database. I'm thinking that that should scan all system mailboxes occasionally, but scan recently logged in users more frequently (since on Grex you can only read mail while being logged in). There are a couple web pages around describing how various people did this, but none of the ones I've seen exactly fit our needs. I also thing there were some good ideas in Marcus's version that I'll want to carry over. So I've got some software design work to do. If all of this is too hard, maybe I'll just set up standard exim mailbox quotas and bring nextGrex up with that, with the intention of doing something better later. But I think this is important enough that I'd like to take a shot at doing it now. Another of Marcus's modifications to sendmail on old Grex was to put in a limited amount of spam filtering that all works before accepting the message. There are lots of ways to integrate spam filtering into exim, but I'm uncertain of how well these will work for Grex. Many suck a lot of CPU and could be bad with Grex's mail volume. Also many kinds of spam filtering are best done on a per-user basis. Any message sent to me in Chinese is probably spam, but that may not be the case for a Chinese user. I think Grex needs to seriously think about a spam strategy, but it's a large and complex project, that is going to require a lot of thinking. I don't want it on the critical path to getting up on the new system. So I plan to come up with no spam filtering. Marcus's spam filters are much maligned for their ineffectiveness. I guess we'll see how much spam they were catching after we lose them.
Doesn't the use of a non-OpenBSD copy of exim invalidate the policy of using OpenBSD for security reasons?
Re #122: Thanks for the long explanation, Jan. Couldn't the accepting module of exim just look at the user's mail file to get its size, thus avoiding having to have a database and a scanning daemon? That sounds complicated. Is it really that much slower to look up the size of a file in our heirarchical mail structure than to look up the same thing in a database?
When a system connects to deliver mail to Grex, does each attempt spawn a separate exim process, or are they all sequential and handled by a single process? Could exim be tweaked to spawn a child process for each incoming email, giving the userid as a parameter and returning a boolean indication of whether that user's mailbox is allowed to accept more mail? The configuration for the child process could specify the size limit for inboxes. The child process could check the filesize directly, as aruba suggests, or check a database maintained by a cron task run once daily during a slow usage period and perhaps also updated by the logOUT process.
What happens when a message comes in for two people, and puts one
of them over the quota, but not the other? When Grex accepts a
message, can it do so for just some of the recipients?
Ignoring that for the moment, I agree with Mark. The thing to do
is:
- Wait for sender to send size of message.
- Check the current size of user's mailbox. If this message puts
it over the quota, reject it.
- Otherwise accept the message and process it without further regard
for the quota.
Note this does allow the mailbox to grow above the quota, if two
messages come in in parallel, but this is rare and the maximum overage
is less than the size of one message.
This ought to be as simple as adding a CheckMailboxSize(user) function
to the delivery part of the system, which the accepting part calls.
Actually it should probably be OKtoAdd(user,size) instead of CheckMailboxSize(user) above.
And, if the sender lies about the message size?
The answers to all the questions and comments can be summarized with "I don't know". MTA's are huge complex pieces of software. Generally not all incoming mail is destined for a local mailbox. Aliases and .forward files may direct it elsewhere. Many systems relay mail, accepting it only to send it further. Ordinarily you can't just check the mailbox at accept time because you don't know yet which mailbox, if any, it is destined for. For Grex this may true rarely enough not to matter, but I think a solution like what prp suggests would be driving a stake through the heart of the exim architecture, losing the ability to do all sorts of things that I suspect, without full study, we never do on Grex. Is this OK? I don't know. I'll have to study more. So far I've looked at various people's pages describing what they did, but I haven't looked at the source code. Yes, it should be much simpler, but I suspect that if it was then people would have done it that way. I haven't even started work on this yet. I think I've got exim fully installed and working, if not necessarily in the optimum configuration. Figuring out mailbox quotas is the next step. Or maybe I'll go back and finish up lockuser first.
Jan is wrong on one major point here: MTA's don't *have* to send you the size of a message before they transmit the message. They can, but there's nothing that says they have to. The way Marcus's mailbox quota code worked, it did a stat() of the user's mailbox file, and compared it against some kind of constant (I think he added an option to sendmail.cf to initialize that). If the size returned by stat was greater than the constant, an error was returned in the SMTP transaction sending the mail. If not, then the mail was accepted and appended to the user's mailbox. If the user was subsequently over mail quota, this would be detected the next time he or she got a message. It wasn't that fancy. The only major `optimization' was to stat the user's mailbox during the SMTP transaction (once the recipient was known, but before the data was sent). I don't remember what it did in the case of multiple recipients; probably deliver to those it could and reject the rest. I say put up exim with the existing quota code and work from there. Since we've never measured the network link in any way, any guesses as to where a bottleneck might exist are pure speculation, and not based on any observations based on empirical evidence. Or, since Kip's not doing it, put up postfix instead.
Thanks for the correction. I really know nothing about MTAs. My main
qualification for doing it is that I seem to be doing it.
I spent some time trying to find Marcus's old description of how his
mail quota worked, but didn't succeed. So I have no idea. Sail forward
regardless.
I've been digging though things, and at this point I think I can do it
pretty simply, just by editing exim's config file.
Here's my approximate plan, still not fully worked out:
(1) Turn on exim's built in quota system, with the inclusive option.
Mostly it won't be used, but it'll be there when anything slips
through the accept-time quota check. The inclusive option means
that people can continue to recieve mail until they go over the
quota. So if you are one byte under quota, and receive a 10 Meg
mail file it will be delivered. You'll then be 10 Megs over
quota, but I don't care. With this system I don't need to know
how big the incoming message is to decide whether to reject it.
I just check the size of the file. If it is over quota I reject
the mail, no matter how large or small it is.
(2) In exim's config file, I configure a router rule that gets run
before rule that routes to local delivery. This will use the
${stat operator to get the size of the mail file and compare it
to the quota. If it's too big, it denys. These rules get run
at receive time, so everything is hunky dory.
So, this appears to me to be fairly simple. It only became possible to
do this in fairly recent releases of exim, I think. All the people
devising complex schemes were probably working with older releases.
Either that or I'm missing something. Maybe I don't even need to do
(1), though it makes a nice safety net.
It also looks too me like hierarchical mail directories would be very
easy to configure into exim. The trickier part of getting heirarchical
mail to work would be figuring out how to get users MAIL environment
variable set correctly so that the mail clients will be able to read
their mail. I'm not sure I'll bother though. I really expect this to
be a fairly insubstantial performance improvement.
I'm going to spend a little more time reading exim documentation to make
sure I'm understanding everything and am really able to do this the way
I want. One thing I can say for exim is that it has quite good
documentation, sadly not a common thing for open source software.
I've already spent a couple days working on getting exim up and working,
and am far enough along that I think I see how I can do everything I
need with it. So naturally I'm *thrilled* at the suggestion that I drop
it and start over with postfix.
You might want to take a brief look at the documentation for postfix. If it is even better than exim, that would support switching. Then again, if the exim documentation is as good as it sounds, it might not be worth bothering.
My concern with exim is that we get stuck with another weirdo piece of 0% market share software just because `that's the way we've always done it.' If you want to stick with it, however, fine. But how many exim sites are there out there compared to postfix sites?
I have no idea how many exim sites there are. Let's get this straight. Three years ago we decided to switch Grex to openBSD. It's been a year and a half since the Grex users invested in the new computer. It's time they got someething for their money. I want to get Grex moved to nextGrex as soon as possible. Within the next few weeks if possible. I seem to be the only person doing things. I have limited time. I have limited enthusiasm. I don't want to spend my time fooling with MTAs. I don't care about MTAs. I want to be writting my own software, not futzing around with other people's. I am attempting to stay on a straight line aimed at getting NextGrex up. I am not taking any detours or diversions. At some point when I wasn't in the room some set of staff members decided on exim for reasons I either never knew or have forgotten. Good enough for me. Exim will work. I'll go with exim. I will not engage in any re-examination of that decision, because that would be a diversion from my straight line. If postfix is better, you are welcome to install postfix, either today or at any time in the future. If you can promise me absolutely that you will have it up within a week, then I'll stop working on exim. If not then your plan is not part of my straight line. I am not interested in holding up progress on NextGrex so that we can have a better MTA. No user of Grex cares about exim vs. postfix vs. sendmail. All they want is for their mail to go through. Exim will get their mail through, perform well enough, and be secure enough. After I got exim built, it took five minutes to switch from sendmail to exim - just edit three files and restart one process. We can switch from MTA to MTA twice a day for the rest of eternity for all I care. I'd be sorely disappointed if nobody ever improves on what I'm doing now. In case anyone has any delusions, nextGrex will not be in perfect shape on the day we come up on it. I want it to be reasonably stable and secure. I want all basic services to be basically working. I anticipate months of bug fixing and fine tuning. I'm hoping that the new platform will provide an environment for innovation and development of new and better services for Grex. I've spent years of my life pushing Grex out of ditches. You'll not find me blocking you if you want to change MTAs. Though I'd hope you could find more interesting things to change on Grex.
I'm behind the straight-line approach 100%, Jan.
I also support Jan's approach. As he says, if another staff member wants to improve on his work (but not delay the live public release of NextGrex), you are welcome - but action speaks real volumes.
Jim plans to take a few linux courses at WCC so that some day he can help with the next next grex. In the meantime we are both extremely grateful to Jan and everyone else who has been working on this next grex.
Drift: Does mdw do grex any more?
re #137 If Jim is interested, I have an extra copy of RedHat for Business which includes a book & CD. Send me an address at todd@plesco.us and I'll mail it to him.
OK. I have mail quota working under exim, I think.
The whole thing was done from the exim config file. I like the degree to
which exim can be configured. The syntax isn't super great, but at least
it is well documented and exim gives good error messages when there are
problems. I suspect parsing the whole config file on every start up is rather
slow, but on the new system slow is a relative term.
So I started with a couple macro definitions.
MBOX_QUOTA = 1M
STAFF_GID = 20
MBOX_FILE = /var/mail/$local_part
Pretty clear. We need the staff group id because staff is exempted from
mailbox quotas. I think that makes some sense, since many system error
messages might be mailed to staff. However most Grex staff forward their
mail off Grex.
We use a macro to construct the user's mailbox partly to facilitate a
switch to hierarchical mail directories someday. I think all you now have
to do to make exim do hierarchical mail is change the MBOX_FILE macro to
something like:
MBOX_FILE = /var/mail/${length_1:$local_part}/\
${if == ${strlen:$local_part}{1} {z}{${substr_1_1:$local_part}}/\
$local_part
The real meat of the quota check is done in the route definitions. Routes
decide what is to be done with an incoming mail, but they are also called
to verify each recipient as they are fed to SMTP. The routes definitions are
checked sequentially. First one takes mail addressed to non-grex domains
and delivers them to the appropriate system via SMTP. Next one checks
grex addresses against the system aliases file. Next one checks them
against a .forward file. The last one, run only if all previous ones
weren't appropriate, delivers to the local mailbox file. I replaced that
with three new routes.
First, we do delivery to staff:
localuser_noquota:
driver = accept
check_local_user
condition = ${if == {$local_user_gid}{STAFF_GID} {yes}{no}}
transport = local_delivery_noquota
That says that if the recipient has the staff GID, use the
"local_deliver_noquota" transport.
Next we generate a failure for mail to full mailboxes:
mbox_full:
driver = redirect
verify_only
no_verify_sender
allow_fail
condition = ${if \
and { {exists {MBOX_FILE}} \
{ >= {${extract{size}{${stat:MBOX_FILE}}{$value}{0}}} \
{MBOX_QUOTA} } } \
{yes}{no} }
data = :fail:Mailbox for $local_part is full
This rule is used only when verifying a recipient after an SMTP-client
issues a comand like RCPT TO:<mailhog@grex.org>. It stat's their mail
file, if it exists. If it is full, it forces a failure with the error
message "Mailbox for mailhog is full". Note that the message will still
be delivered to any other recipients. We do a hard fail here because
previous experience says that if we just "defer" then many mail hosts
will retry seconds later and keep hammering us with repeated attempts
to deliver the message.
If that route fails to apply, we can go ahead and deliver the mail normally:
localuser:
driver = accept
check_local_user
transport = local_delivery_quota
cannot_route_message = Unknown user
Now each of the two mail delivery routes referenced a transport to use.
The config file defines those too. Here's the noquota one:
local_delivery_noquota:
driver = appendfile
file = MBOX_FILE
delivery_date_add
envelope_to_add
return_path_add
group = mail
mode = 0660
The quota one just defines a quota:
local_delivery_quota:
driver = appendfile
file = MBOX_FILE
quota_is_inclusive
quota = MBOX_QUOTA
delivery_date_add
envelope_to_add
return_path_add
group = mail
mode = 0660
Note that for mail coming in through SMTP, this does the quota check for the
second time. We did a check at RCPT time, and now we are doing the same check
again as we are deliving the mail. Doing it twice isn't really necessary,
but it is nice, because the second check is being done with a lock on the
mailfile, so it avoids race conditions. The second check is more important
for mail that didn't come in via SMTP - that is mail that was sent by another
user on Grex, because there is no RCPT time check done for such mail.
There is another difference between the SMTP RCPT time check and the
append-time check. If the latter fails, then we defer instead of doing a hard
fail. The system will retry delivery for a few days before bouncing back the
mail, and the mail will be bounced back to the "From" address. Since this
mostly effects only mail sent from Grex, this is fine.
There are probably some other things I should do with the configuration, like
setting up logging through syslog instead of to exim's own private log files.
OK, made some further changes, tightening up security settings and moving the
logging into syslog.
Things still on the To Do List:
- Logging. Grex keeps logs a long time. Need to figure out how to
edit /etc/newsyslog.conf to make the system keep logs Grexishly.
And need to figure out how long we keep logs anyway.
- Newuser needs to be modified to set disk quotas. I also don't think
I've activated disk quotas under OpenBSD 3.5 yet. It boots slower
once you do that, so I was putting it off.
- Need to look at the login program to see if it can be modified to do
a few things:
- Warn users when their mailboxes are full or almost full.
- Display all the alternate motd files (birthday, Grexwalk, etc)
- Print more informative messages when logins fail.
- Set MAIL variable to hierarchical mail file path.
If we can set MAIL variables without too much trouble, then I should
probably go ahead and turn on the hierarchical mail directory code in
exim.
- Port lockuser
I think those are the most important things.
At some point I'm going to open things up to a few friendly users (board, etc)
to let them test things. I'm going to want to start having as many eyes as
I can looking for things that need work.
I wish Mike Myers was still around. He was always great at stumbling into
every bug in the system.
Is that meant as a compliment?
Yes, it is: such testers are great for improving quality but very hard to find.
Yeah. Some people are brilliant at finding ways to make software fail. Combine that with the ability produce useful bug reports and you have a person highly valued by any programmer interested in getting things solid. Though it must be very annoying for Mike. I'm sure he'd prefer if things just worked for him.
I'm not trying to get in your way, Jan. Don't mistake my frustration at the way Grex decides to do things with frustration at you. I'll look at what it takes to get postfix up and running on nextgrex when I get back to California.
I read some postfix documentation when I configured the postfix MTA on my desktop system, but I've forgotten everything about it. I can say that I'm impressed with how easy it finally turned out to be to do everything that I wanted to do with exim, once I slogged through the documentation and thought it out. I had really expected that I would need to hack the source code, but everything I needed to do could be done from the config file. My one concern with exim is performance. I worry that all that configurability was purchased at the price of mediocre performance, though I have no experience to base this on yet. We'll see. I don't think you are in my way. Actually, my way is pretty hard to get into. I think if I made a list of the 100 most interesting projects to work on on Grex, replacing a working MTA with another working MTA wouldn't be on it. But different people have different tastes. Hey, and we don't really know how well my exim configuration will work till we start feeding a lot more mail through it than just my few test messages.
I've been hacking 'login' and 'sshd'. I'm mostly done with login, just starting on sshd. Unlike exim, getting these to behave the way we want is going to require some source code modifications. This list is: - Warn about full / almost full mailboxes. - Display multiple motd files. - Set MAIL environment variables. Customizing the error messages is painful to do with the existing login.c so I'm going to let that slide for now at least. I'm putting the code to set the MAIL variable for hierarchical mail directories in #ifdefs for now. The mods are in the same places as the mods for printing out warnings for full mailboxes, so I may as well put them in now. Likely I'll do some tests to see if the mail clients all respect the MAIL variable. If they do maybe I'll go ahead and do hierarchical mail now.
OK, here's a puzzle. While wandering through the source code of 'sshd' I discovered that there is a "UseLogin yes" option that can be put into the config file. When this is set, sshd uses the 'login' program to start the user's shell after he has been authenticated. This would be very nice for me because I wouldn't have to do all the same hacks to 'sshd' that I already have done to 'login'. We could keep running a generic OpenBSD version of sshd without local patches. However, I noticed that the manual page says nothing of "UseLogin". Web searching shows that historically there have been two major 'ssh' security holes with UseLogin. Both of these, however, were fixed years ago. I found many references suggesting that "UseLogin" was once described in the manual, but it seems to have been removed. However I couldn't find any information on why it was removed from the manual, but left in the code. Is it depreciated? I don't know. I did find a message in which one of the OpenBSD developers said he regretted ever having accepted the UserLogin patch to OpenBSD. So, do I go ahead and use UseLogin, or do I ignore it and patch sshd?
Correction: one of the "OpenSSH" developer, not one of the OpenBSD developers.
Found on the web, on a FreeBSD security list: ...specifying a command to run does ignore UseLogin (and is documented as such), so you'll get an inconsistent environment because of that when doing cvs over ssh, as opposed to logging in over ssh. All in all, the UseLogin option seems to be not very useful, and poorly implemented. But then, we aren't using OpenSSH-portable (well, not in my source tree, anyway). These things ought to be checked against -portable [endquote] I will point out that the first point applies to any non-shell use of ssh, presumably including sftp and scp.
A note about Exim. I run it at work and have it setup to run as a daemon for incoming mail. There are times when large amounts of mail come into our server and I have never noticed any performance hit on any of the other services running on that server. Exim simply sits in the background collecting mail and flushing the outbound queue every so often. I run exim with the options '-bd -q30m'. This makes it a daemon and tells it to start a queue-runner process every 30 minutes. Since most of the mail here tends to go out it big batches this works perfectly, you might set it lower for Grex though. Over all I have never had any problems with Exim.
Jim: I agree that UseLogin is not very useful ... unless you happen to be hacking login to behave in non-standard ways, and want the same behavior under ssh. Basically the only thing it is really good for is exactly what we are doing. I can't think of another use for it. The inconsistancy problem is actually an advantage. Right now, users who telnet in and users who ssh in get different environments, because 'login' and 'sshd' don't intialize the environment in exactly the same way. For instance, stock OpenBSD 'login' does not set the MAIL environment variable, but stock OpenBSD 'sshd' does. If we switched to having 'sshd' run 'login' then the environment would be the same no matter how you connected. This would introduce a useful consistancy. It does, as you quote noted, introduce an inconsistancy between how the environment is set up when doing other commands, like cvs, versus how it is set up when starting a shell, but I think this is vastly less important to Grex's users than consistancy between different login methods. Lorance: Thanks for the data point. That's exactly the way exim is configured on next Grex now. Exim's config files are complex and if they built the interpretor badly, it could be quite slow. Without any experience running it on a busy system, and without having read the source code, I thought it might prove bad. However, the overall architecture and the documentation were good enough that I was hoping they coded well too. Sounds like maybe they did. Good news.
My feeling right now is that I'm going to go ahead with hacking up sshd, and ignore the UseLogin option. This is a security critical piece of software and there is a distinct lack of confidence in UseLogin in the air. The developers of OpenSSH clearly have come to hate it, and appear to be discouraging it's use, albeit in a sideways manner. I just don't feel right in putting my faith in it.
Might it be worthwhile to pass the question to the OpenSSh developers' list? I agree that, this time, it makes sense to hack them both. But maybe if the questions around UseLogin can be answered, it won't be necessary at the next upgrade.
Thanks, gelinas! You didn't really help anything, but thanks anyway!
UYEAH!
Jan, the comment about "not very useful" was not mine but the message I found by Googling. I was not trying to discourage using UseLogin, just making sure that all of the facts were known.
Am I correct about the following? Going from Sun hardare / SunOS to Intel / Linux virtually guarantees that existing binaries won't run on NextGrex. Therefore programs people have will either have to be recompiled from source on NextGrex or equivalent Linux binaries found.
NextGrex is not running Linux. OpenBSD.
However, with that substitution, Kevin is correct. Programs will have to be recompiled from source on NextGrex or equivalent OpenBSD binaries found.
(my ignorance, thinking that OpenBSD was a flavor of Linux)
For the most part, it shouldn't matter. Most of the applications people think of as being written for Linux will actually compile on most any modern Unix system, including OpenBSD. Odds are pretty good that fixing a program written for SunOS to work on OpenBSD will require only very small changes.
I'm strongly opposed to changing either login or sshd; why can't we put this stuff in the global startup scripts, and then source those from within the user's dot files? Won't that achieve the same effect for 99% of users without making changes to the base system.
Most software intended for redistribution in source form is pretty smart about compiling itself for a whole range of Unices. Any programs written in sh, bash, (t)csh, zsh, perl, or python for use on Grex should work pretty much unaltered on NextGrex. Porting software written by Grexers in C or any other compiled language for Grex to any BSD (Open, Free, or Net) should be easier than porting it to Linux or any System V Unix (e.g. Solaris, HP-UX (?)).
I compiled links for our SunOS with the help of an expert and it took a few weeks. OpenBSD would probably be a lot easier to compile for, and the chance of finding things precompiled can't be any lower than for an old SunOS. By the way, could someone compile Links2 (with ssl and javascript) for the next grex? It works for online billing at DTE (local electric/gas company) where lynx does not. It does tables and frames (both optional). It is still text, but is menu driven (or use keyboard shortcuts) with no mouse needed. Lynx is a pain to use with tables and won't do javascript at all. Also a newer version of Pine would be helpful, set up to use lynx or links to read HTML and go to embedded URLs in emails. A friend has an ISP account solely to deal with this HTML stuff (she forwards grex mail to it when needed) because she cannot figure out how to do it manually with the current pine.
new versions of MH and zsh would be nice, too, please.
I'm sure we'll be able to udate almost everything, but please, let's get it up first and then worry about new software.
Can we have a big celebratory potluck when the next grex is up? Any chance of it being for New Year's Day?
Not a chance.
Login and sshd modifications are installed, tested, and cvs'ed. As I was working on this, I discovered that I'd been looking in the wrong place for documentation of the UseLogin option for sshd. It's in sshd_config not in ssh_config. If you look in the right man page, it is still documented. So maybe that would have been a better choice, but what I've done is in and working, so I'm not going to re-examine it right now. Onward!
I'm trying to figure out disk quotas. These are limits on the amount of disk space that each user can use, enforced by the operating system. Quotas are on a per filesystem basis, so we will need to set quotas on any filesystem that users can write to. As always we will be willing to raise user's quotas upon request. I'm planning not to use soft quotas - these allow a user to go over quota for a short period of time. I think they just confuse the issue. Historically our quota has been 1M per user. We may be able to increase this, because we have bigger disks now. My plan for now is to leave it at 1M, and see how things go. Maybe we'll increase it later. A user's quota on the file system where his home directory is will thus be 1M. His quota on all other home file systems will be zero. We will need to set quotas on /tmp. What should they be? /var/tmp also exists. Can we turn this into a symbolic link to /tmp? I don't really want to set quotas on /var. (Quotas have a performance cost.) An idea would be to start newusers out with a low quota, say 10K. Bump it up to 1M after a week. This would stop people from creating a new account, downloading eggdrop, etc. Might not be worth the effort. I think I may want to write a custom tool to manage quotas.
This response has been erased.
I concur
If you haven't yet, you should take a look at /grex/grexdoc/openbsd/09-quotas If you have, but still have questions, let me know, so that I can take another stab at making the document clear, please. I disagree on not having softlimits. A soft limit may permit the current operation to complete when a hard limit would not. For vandals, it probably won't make a lot of difference. For other users, it can make a lot of difference in useability. Re /tmp, as I wrote in my note on quotas in grexdoc: } It looks like we may also be able to use quotas to automatically remove } files from the /tmp directory by setting the soft limit to one and the } hard limit to zero. I wish I could I remember why I thought that. Before you spend too much time rolling your own, you might want to spend some time with edquota, Jan. It really isn't hard to use. With enough disk space, quotas, and a regular reap, we can afford to have folks proving to themselves that we really do know what we are talking about when we tell them their desired software won't work. I'll try to make some time to compare the 'disk hogs' list with the lock log and the list of reaped accounts, to see if I can determine which IRCers had not been locked but had been reaped.
Yes, I've read that.
Yes, I agree that we should set a softlimit just a little smaller than the
hard limit - maybe softlimit 1000K, hardlimit 1050K. This gets you a warning
message 50K before you run out disk and things stop working.
I was baffled by that comment on /tmp too.
I've read the edquota docs and also the setquota docs (it's available from
the source tree) and I think they are too clumsy to use directly for quota
administration. My first thought was a wrapper, something like 'lockuser'
or 'zapuser' that would log the date a user's quota was changed and the
reason. Instead of specifying disk usage on /a, /c, /d, /e, /tmp, etc,
you'd specify usage on 'home' (the partition there home directory is on)
and 'nonhome' (all other home partitions - this would virtually always be
zero), and 'tmp'. You wouldn't have to set both soft and hard limts -
config file would give difference.
I'm not sure, but I think it might be good to have a quota database other
than the raw quota file that would keep track of what user's quotas are
supposed to be, and from which the system's quota database could be generated.
The more I thought about this, the more I though what we really need is a
comprehensive user database, in SQL. As each new account is created, an
initial record would be created for it, including all information about the
user other than passwords. Current quota settings would be there. We'd
also log status changes to the database - creation, deletion, locking,
group change, disk quota change, etc. Maybe monthly we'd log usage info
for each user - time spent logged on, amount of use of ftp, backtalk, etc.
This is all information we already keep, but it is difficult for us to
pull it together now.
We've long wanted something like this so we could do things like send mail
to users who had been here for three months asking them to consider membership.
Things like the project Joe mentions (figuring which IRCers had not been
locked but had been reaped) would be much easier with this. We'd be able to
get a better picture of how people were using Grex.
However, this is not a project to put on the straight line to getting NextGrex
up. It'll keep for later.
Here's my plan for what I'm going to do now:
- Make /var/tmp a symbolic link to /tmp
- Modify newuser so the config file can specify which disks have quotas,
with syntax something like:
qdisk home /a
qdisk home /c
qdisk tmp /tmp
and specify initial settings for soft/hard block/node for new users:
quota home 1000K 1050K 500 510
quota nonhome 0 0 0 0
quota tmp 50K 55K 50 55
I'll spend some time researching sensible values for inode and tmp quotas
but not too much - we can fiddle with that later.
I might also do a simple wrapper for setquota that lets you change a user's
home quota easily and log the reason.
So I investigated. From the edquota manpage:
Setting a soft limit to one with a hard limit of zero indicates
that allocations should be permitted on only a temporary basis
(see -t below).
and
The -t flag can be used to change the grace period.
So *if* this works as described, the files would be removed at the
end of the grace period. 'Twould be worthwhile to test, I think.
Right now, the grace period on the new grex machine is one week.
See /usr/include/ufs/ufs/quota.h
I happen to have used nedquota manpage on vario'puters, and *have* found it to be less than unsatisfactory. Schwa.
Speaking of "home", why are the different user filesystems in the root instead of in /home? (Yes, I know it's so we can split them up so that the system doesn't have to search through thousands of directories corresponding to logins - but why not put ./a, ./b, etc. under /home? I admit it's an asthetic issue - imho, root file systems shouldn't be crowded with non-standard stuff, especially since nowadays we have /root to serve as "root"'s homedir instead of / - but it would also mean that we could also put all the home directories on one disk in one fell swoop if we ever ran out of space on them, just by moving /home. Are there any plans to increase the maximum available amount of space each user gets?
Take a look at Item 62 in coop, twenex. I'd be interested in seeing any new thoughts on the subject.
Thanks.
I went and read the kernel source, and I'm pretty sure I understand all this now. The operating system never automatically removes overquota files. If you perform an operation that hits a quota, then one of two things happens. Either you get a warning message printed to your terminal and the operation continues, or you get an error message and the operation fails. If go over the soft limit, you get the warning message, unless you have been over the soft limit for more than a week, in which case you get the fail. If you attempt to go over the hard limit, you always get a fail, so you can't go over the hard limit. So the "soft limit" is the limit we want to advertize to the users. All users should always be below the soft limit. The higher hard limit provides just a little niceness. If you are doing some complex operation then it has a bit of a better chance of running to the end instead of failing in the middle, but we still expect people to clean up their disk usage after the end of that operation, and we don't really expect ordinary Grex users to be doing lots of operations on really large files. Also nothing is going to automatically bump people down below the soft limit. So I feel we should keep the hard limit only a little higher than the soft limit - maybe an extra 50K or 100K. Joe's notes suggest a block limit of 2000 and a inode limit of 4000. I don't think that makes sense. Every non-empty file and every directory is at least one block. So the only way you could hit that inode limit is to create at least 2000 empty files. No grex user needs 2000 empty files. My thought was to set the inode limit to about 2/3 the block limit. I feel that anyone hitting that is doing something sufficiently weird that maybe they should be talking to staff. But I suppose there would be no particular harm in just setting the inode quota equal to the block quota. Inodes aren't really a scarce resource. Historically, home directories were put under / and given short names to keep the /etc/passwd file smaller. That's certainly ancient history now, but one name is as good as another, and I like having some continuity with Grex history. By the way, the reason there is no /b was that /b was a link to the bbs shell. Writing /b instead of the full path was another way to keep /etc/passwd small.
So I've been working on quota stuff. I've got quota code patched into newuser and web newuser. Marcus had some quota code in there, but it was inadequate for our needs (supported only one filesystem with quotas), and wasn't entirely correct anyway. So you can now edit the initial quotas from the config file and they all get set right. I should note that the OpenBSD manual page for quotactl is completely inadequate. As usual, I had to read the kernel source to figure out the correct way of calling this thing. I've turned up some additional problems with newuser. There was some bad pointer arithmatic that used to squeek by but broke when OpenBSD changed around it's memory mapping for security reasons. It's not safe to assume you can add together two pointer addresses without an overflow, even if you plan to divide the sum by two to get the middle of a region of memory. Another bit of fun occurs because of redundant attempts to disable coredumps. I had modified newuser to do its passwd file editing via the standard OpenBSD routines for this. Those routines start out by setting the hard limit on the coredumpsize to zero. This would be important to do on systems where coredumps are readable, because the coredump could contain fragements of the password file, but OpenBSD does not have readable core dumps, so it's just some redundant paranoia. This starts to cause problems because newuser finishes by running the 'login' program to log the user in. Because of this, the user's shell, on the first login only, inherits a hard coredump limit of zero. Now the default .login file for the menu shell does a 'limit coredumpsize 0' because most menu shell users don't need core dumps. This command sets the soft coredump limit to zero. It ought to be legal, but the OpenBSD setrlimit() call seems to generate an error if you try to set the soft limit to zero when the hard limit is zero. This causes the limit command to fail in a way that terminates the execution of the login script, so the 'menu' shell itself doesn't get run, leaving the bewildered newuser in the csh shell, with an incompletely configured environment. So we've got some stupidity in the kernel and some stupidity in csh (it shouldn't stop execution of the .login file), but I gotta fix it in newuser by resetting the hard limit to infinity before giving up root status so that it can be set back to zero. So I'm making progress, but I'm not exactly willing to give any estimates about when this is all going to be done. It's hard to anticipate problems like these. Oldgrex is the result of thirteen years of tuning by dozens of staff people. I've only got a couple of hours a day I can put into this stuff.
I also wrote up a simple little wrapper script for the 'setquota' utility that lets staff people easily change user's disk quotas and logs what they did. I should look for a tool to list users who are over quota. We'll need that when we move users over from oldGrex. We'll need to manually go through all over-quota users and decide either the up their quota or take other action.
As always, continued thanks to janc for taking this on himself.
Likewise. It's like sweet cognac every time I read a report of progress.
OK, ran into another annoyance. The standard .login file issued to all new users contains this line: tset -m 'dialup:?xterm' -m 'network:?xterm' "$TERM" This does various terminal initialization. If your terminal is "network" or "dialup" when you login in, it will change it to whatever kind of terminal you said you had when you registered, in my case 'xterm'. Notice that the current value of the TERM environment variable is passed in on the command line. In OpenBSD it isn't necessary to pass it in on the command line. If you leave it off, it fetches it from the TERM environment variable all by itself. The problem comes in because when you pass the terminal type in from the command line, it does not do the mappings. So to make the mappings work, I've dropped the last argument from the prototype .login and .profile files on NextGrex. However once we move over the grex users, we are going to have to change some 10,000 user's dot files. Ugh. I suppose we'll write a sed script to do this. Actually, on most telnet and ssh connections these days, the correct terminal type is passed across, so it won't usually say "network" or "dialup" to start with and the mapping won't be needed. However this is never the case with dial-in connections (which actualy probably arrive saying "network" not "dialup" because they all are telnets from the terminal server.
(is Cognac supposed to be sweet? I guess if you mix it with something like Chambord..)
I'm seeing various apparant inconsistancies in the quota stuff. I think it all comes down to the fact that the block size on OpenBSD is really 512 bytes, not 1024 bytes, as I read somewhere. I'm going to have to revise my newuser hacks to suck the correct block size out of param.h. Need to investigate this further. There's also an issue with MANPATH. The one set in most user's dot files on Grex doesn't work on nextGrex. With luck, I'll be able to fix this with a few symlinks. Or another sed script. I don't have my to do list in front of me, but I other tasks that I can think of that still need to be done are updating the log rolling scripts and fixing several recently reported bugs in fronttalk. Sometime soon I want to try to recruit more people to try testing things, and try to run some of that in parallel with some of the pre-move tasks I have to do. Pre-move tasks include copying over all of Grex's web pages, board minute archives and such slowly changing stuff. I want to do this while Grex is still up. I'll be advising the people who routinely maintain such things that they should suspend changes that they don't want lost until we are on the new system. Mostly those only get changed by a small set of people, so this should be OK. The other pre-move tasks are preparing for the actual move. We will need to renumber groupid. I think Dan Cross once built some tools for that that I need to review. I'll need scripts to modify dot files as discussed above. Then it's time to shut down Grex and start the change over, moving bbs, user files, etc. I think we're within a week or two, but it's hard to be sure. I've spent most of the day today dealing with unanticipated problems, who knows how many more await.
I was bluffing - I don't actually know what cognac tastes like. Jan, could we write a wrapper for the tset function which would act like the SunOs 4 function?
Yes, but I'd rather not. I don't want to try to turn a 2004 edition of OpenBSD into an emulation of SunOS. I'd rather take the one time hit of editing 10,000 .login files than forever kludge up tset to behave like an older and more obsolete version. Creating symlinks to make the old MANPATH is different, because it doesn't prevent the new MANPATH from working.
I think I figured out the source of my confusion about block size and quotas.
The 'quota' command says says:
Filesystem blocks quota limit grace files quota limit grace
/a 7 1074 1024 6 1953 1862
The 'edquota' command says
/a: blocks in use: 7, limits (soft = 1074, hard = 1024)
inodes in use: 6, limits (soft = 1953, hard = 1862)
They both say "blocks" but they both lie. The source code for 'edquota' for
example looks like this:
fprintf(fd, "%s: %s %d, limits (soft = %d, hard = %d)\n",
qup->fsname, "blocks in use:",
(int)(dbtob((u_quad_t)qup->dqblk.dqb_curblocks) / 1024),
(int)(dbtob((u_quad_t)qup->dqblk.dqb_bsoftlimit) / 1024),
(int)(dbtob((u_quad_t)qup->dqblk.dqb_bhardlimit) / 1024));
So it prints "blocks in use" then takes the numbers of blocks, feeds them
through dbtob(), which converts "disk blocks to bytes" and divides by 1024
to get kilobytes.
So both 'quota' and 'edquota' say "blocks" but output "kilobytes". Since
on nextGrex a block is half a kilobyte, this makes a big difference.
I've sent a bug report to OpenBSD.
But once again, the only way to figure out what OpenBSD is doing is to
read the source code. I'm begining to miss working on exim. At least on
exim the documentation said what the code did, and the code did what the
documetation said. The OpenBSD folks write very nice code, often with
clear comments, so reading the source isn't as bad as it sounds. But I
wish they wouldn't keep getting sloppy and vague whenever they are
communicating to a user.
Note that this changes my previous notions about inodes. Since blocks are smaller than I thought, you can fit twice as many files into a 2 Meg limit, but one block files are going to be less common than I previously thought. I think I'll start out setting inode limits to 2/3 of the block limit, or 4/3 of the kilobyte limit. If that doesn't work out well, we can always raise it.
Nobody showed for the Grexwalk, so I came home and started fiddling some more. Finished tests of quota code in newuser and finished testing and debugging the new 'upquota' admin command. Need to do more testing on webnewuser. Think I'm going to move over the Grex web pages first.
Sorry we didn't make it for the walk - the weather discouraged us.
Why edit the .login and other files? I would rewrite them (and the common, global) login files to reflect the new reality, and then wholesale replace the old ones with the new ones (backing up the old ones, of course) and advise users who've made customizations to merge them into the new files. That'd also give an opportunity to have a single place to make environment updates (as opposed to hacking login and sshd).
I think many users would have difficulty with this. I would like to make more use of the global files. The default dot files we've given out for years mostly seem to source a global file, with a comment that you shouldn't delete that. But this is redundant because most shells now source a global file automatically. Except I think the "rc" shell doesn't but newuser doesn't offer that one anyway. It could all stand some cleaning up and redesign. Dunno where that falls on the priority list.
I could use a volunteer to update the copy of the Grex web pages on nextGrex.
Changes to be made:
- Talk about 'ssh' as well as telnet. Need to update the instructions
on how to connect to grex to include ssh.
- Deletion of explanation of things like the telnet queue which no longer
exist. Replacement of reference to SunOS with references to OpenBSD.
Checking all commands given to make sure syntax is still the same, etc.
- Addition of discussion of accessing Grex vi https.
- Probably other things I haven't thought of.
You'd need to know a lot about Grex and a bit about HTML to do this. You'd
need to have time to work on it SOON.
I started updating the pages, but felt like this was really a job I could
maybe find someone else to work on. Some changes have been made. Some
pages just have comments in red saying what needs to be change. Some pages
haven't even been looked at.
I'll take a look at them tomorrow.
Thanks Joe and Jan. Can we please have at least 3 days notice when grex will be moving. People have been complaining about a lot of bounced mail when grex was out for longer periods and I want to warn them this time. I use grex as a business address. I also want to warn a few other grexers whom we signed up to tell their friends not to send mail for a few days. Amazing that you have accomplished so much in the past few weeks.
You'll have at least 3 days notice. I fixed some bugs in web-newuser, and that seems to be working right now. Editted up the lynx config file to match the one on Grex. I haven't done any extensive testing of the lynx shell, however. It seems to at least sort of basically work. Installed 'kermit' from the ports tree. I guess we still have dialup users, huh? The 'sx', 'sz', 'rx', rz' commands on Grex do X-modem and Z-modem file transfers. I haven't looked very hard, but I haven't found a copy of them for OpenBSD. There are some things call 'lrz' and 'lsz' in the ports tree that proport to do x-modem, y-modem, and z-modem transfers. I don't know if they are an adequate substitute. Does anyone still care? It's 3am. Time for bed.
(They are an adequate substitute.)
I installed the lrzsz package.
I'm posting this response using Fronttalk on nextGrex. Cool.
I'm posting this using fronttalk from m-net. Even more cool.
I use kermit for file transfer. It is available for DOS, Windows or linux. I look forward to testing out lynx, links, and kermit and doing file transfers.
I did a review of the tools for renumbering GID and UIDs that Dan Cross did. They look fine. I applied some very minor bug fixes and added a wee bit of documentation and stuck them in ~janc/regroup on nextGrex where I can find them when I need them.
I invited a bunch of users to help test nextGrex. We're starting to get close - mostly just fiddly stuff left to do, no big tasks. styles has supplied several good bug reports already. I've only fixed one so far - Picospan was missing it's help files. I copied over the ones from old Grex, though they are slightly munged.
Fixed two more bugs reported by styles: Newuser was setting group ids incorrectly, and MANPATH was not being set right. He raised some questions about the packet filters, which I forwarded to Grex Staff because I've not worked with them at all yet.
Re. 191: Forgive a stupid Q, but couldn't you slip in a calculation to convert Kilo to true block size?
I could not find pine, elm, or links at nextgrex. Have you simply not installed them yet? Are we testing a partial system?
There was an error in the install script for pine. It installed 'pico' but not pine. This is fixed. I forgot to install elm. Should be in now. links appears to work for me.
Cindi reported that the 'change' program was wasn't working right. I tried
it and found that when I changed to 'pico' it editted my .login file, changing
setenv EDITOR pico
to
EDITOR= ; export EDITOR
Uh huh. Not only is it setting the editor to a null string, it's putting 'sh'
shell syntax into a 'csh' startup file.
Fixed a number of bugs in the change_editor script
- Deleted option to change to the 'bbsed' editor. We don't have source
for this and probably don't want it.
- Fixed paths of different shells so it should be better at identifying
which shell a user has.
- nawk now appears to require a "-v" flag before any variable setting
parameters on the command line. Fixed this in change_editor,
change_keys and the chsh wrapper.
Also added bbs to /etc/shells.
Still having problems connecting to nextGrex. After a LONG wait, it says "connection reset by peer"
Copied the pine.conf file from Grex to nextGrex. Added two lines Cindi wanted that enable it to automaticaly view URLs with lynx.
I don't know why twenex is having trouble connecting.
Ported over the 'listcommands' script, which is mentioned in the FAQ.
I just tested ftp from nextgrex to oldgrex and was able to get a file.
Elm works. Pine works and reads URLs with lynx. Is it also supposed to display html mails with lynx (as plain text instead of with tags)? The change program worked to change shells (bash to tcsh and back). It still does not work for changing editors. I tried to change from pico to joe and was told "Unknown shell. Keys not permanently changed".
At sdf pine appears to display html as text rather than as tags. Would you like a copy of their pine.conf?
Sure, why not.
change editors should be fixed - path for bash was configured wrong.
Currently trying to figure inet wrappers out.
I understand that the packet filters test only the user's effective group.
Our internet users don't have their effective group changed, instead they
are only added to the inet group list in /etc/group. This is a supplementary
group, not understood by pf.
Dan had change the wrapper scripts around telnet and ftp to do this:
exec sg inet -c "${REAL_CLIENTS}/${MYNAME} $*"
'sg' is similar to 'newgrp'. It lets you run a command as one of your
supplementary groups. This would work fine, if 'sg' existed for OpenBSD.
Near as I can tell, BSD unix lets you access files based on your
supplementary groups, so people figured they didn't need 'sg' and 'newgrp'.
I've been trying to think of ways to make this work right. One way would
be to turn the wrapper into a C program. It would be permitted set-gid
'inet'. It would check if 'inet' is one of the user's supplementary groups.
If not it would setgid(getgid()), reseting the effective group id to the
user's real uid. Either way, it would then run telnet or ftp or whatever.
(Running it even if the user is not in the inet group leaves the option open
of letting non-members telnet to some places, as determined by the 'pf'
rules).
Maybe I'll take a cut at coding such a wrapper.
what's the url for nextgrex again?
I wrote it, but then discovered that that's not the way pf is configured. I think I'll wait till Joe gets a chance to look at this.
Joe at nextgrex is still not usable. Large sections at starts and end of lines get blocked out (in my case by amber) when I type. No such problem at thisgrex.
Outbound ftp from the new grex machine to the current grex machine works because we let everyone use our own network; pf is configured to allow these connections. I'll change the rules to use the group later today, after I get some sleep.
The URL for the preliminary info about nextGrex is http://www.unixpapa.com/nextgrex.html . nextGrex is web accessible in any useful way yet.
Excuse me. Lost a "not" in that last sentance.
When do I get to have a neXtGreX beta account?
Probably in a couple weeks.
Cindi pointed out that when you run 'lynx' under screen on the new Grex, it becomes very slow. This doesn't happen with 'lynx' outside of screen, nor with lynx/screen on oldGrex. When I run lynx under screen, it seems to paint the whole screen background light grey. Each time you scroll or go to a new page it first paints the whole screen black, one character at a time, and then overwrites the black by reprinting every character of the screen in black-on-grey mode. It also frequently draws screens twice. I'm guessing this is all lynx responding to the particular termcap provided by screen in a gruesome manner. I feel like there may be some additional slowdown just from screen's extra processing, but that is relatively small. I suspect the fix is either a change in lynx's config file or in the termcap. Googling for any information on 'screen' is a dismal task. I'm not going to work on this issue right now. It's just not that high priority. If anyone has any clues about it, I'd be interested though.
Correction: Sindi.
Sindi reports w3m loads slowly. I thought it did fine. Does a nice job of rendering table formatted pages. She also asked about the links browser. It is installed, as 'links'. The version installed is links+-2.1pre14. I think it's a links2 version, and fairly recent.
Your page, janc, says that NextGreX will have Picospan installed for sure. Does that mean that you are effectively nullifying a potential vote issue?
Links works for me now. Lynx and w3m both loaded slowly BECAUSE I was using 'screen'. Lynx pages load twice or even five times in both grex's even without screen. Screen may slow this down enough for you to see it on a faster connection but when I dial in it is very noticeable at all times. A friend said ncurses might be involved. The latest links is links-2.1pre15. Sindi Sindy Syndi Cyndi etc. are all aliases for Cynthia and all work. My grandfather thought I was Cinty. It would be handy to use screen in order to copy between lynx and pine but I can also just send mail from within lynx with pine and mailto:. It would be handy to copy pieces of web pages to bbs and that requires a few more steps without screen (print to a file, exit lynx, start bbs, import the file - edit it at some point).
I'm wondering. Do you actually think that suggestion has any merit, or are you just raising it to make sure there won't be any overlong hiatus in the stream of criticism that any staff person who does anything receives around here? As it happens, Picospan was installed on NextGrex before the vote was proposed. It wasn't installed be me. I just fixed some things that got incidentally broken when it was installed. And I'm reasonably confident that nobody wants to delay working on nextGrex in deference to this vote. The fundamental question is whether we want to move away from Picospan. Whether or not Picospan is installed on nextGrex when we come up on it does not influence that fundamental question. It can always be removed. Is that a good enough defense? Am I cleared of this charge of pursuing a devious anti-democratic conspiracy against Grexers by spending all my scant free time for the last month working on nextGrex? Ah well. It's only natural to suspect that I'd be up to something sneaky to ensure that my conferencing software isn't used on nextGrex. I mean, anybody'd think that.
Sindi Sindy Cindy Cyndi Cinty slipped in.
Jan, I'm curious. Will NeXtGreX allow users to delete their own items, even if they include thousands of responses from hundreds of other users? Also, will NXGX support any sort of mechanism allowing users to easily delete years of their responses, while inconveniencing other users by running up the load averages and making millions of not thousands of items that haven't been used for years seem to be new?
I've now removed the rules permitting specific users (except staff and daemons) Internet access and replaced them with a rule permitting group "inet" that access. I tried chmodding /usr/bin/telnet to set-group-ID, but I still couldn't get an outbound connection. (I also changed the group to "inet.") You might try your wrapper, now, Jan, to see if it works.
(The last part isn't surprising, as /usr/bin is probably mounted nosuid.)
We don't want /usr/bin/telnet to be set-group-id. That would give everyone access. The set-group-id wrapper has the brains to throw away it's set-group-id status if the user isn't actually qualified for it. I'll get this all into CVS if it isn't there already. I think I might want a separate subdirectory for the pf stuff.
I see you've already created the separate directory. :) I updated 01-inet_wrap to reflect Mark's suggestion/request on the group name.
Yeah. I created a 'pf' directory, moved the installation of the pf.conf script into there from the 'openbsd' partition, and moved the symlinking of the various files into there from the 'misc' directory, and added in my new inet_wrap.c program. Thought all this stuff needed pulling together. As I look at it, I think this solution is more restrictive that the previous one, where all the users were listed in the pf.conf file. The only programs that group 'internet' users can run as group 'internet' are the ones linked into the directory, currently ftp, rcp, rsh, scp, sftp, ssh, and telnet. They can't for example, compile their own irc client and be able to run it. I don't think this is a problem. We can certainly link more programs in ther as needed. I notice that nextGrex doesn't have rlogin. I don't think this is necessarily bad. rlogin is pretty obsolete. We should probably get an irc client for members to use. Dunno which one.
Yes, it is more restrictive. However, we _could_ document the use of inet_wrapper, and let them add things they want in their own bin directory. :)
Thanks, Jan!
oh. by the way: for as much as it matters, i would PERSONALLY recommend installing irssi as the irc client. it's neat and popular, in my experience.
BitchX is better.
It really isn't. irssi is, uh, not tacky.
Both bhoward (in Tokyo) and tweenex (in England) have had problems connecting to NextGrex. There has been some speculation among people who know more about these things than I do that it might be due to the packet filter handling fragmented packets incorrectly. This seems to me to be a serious problem, and not one I know anything about. I managed to get nethack to install. The ports tree makefile for the non-x11 version was incorrect - hackdata is not a dependency.
I've turned on "scrub" in pf.conf, which _should_ resolve fragmentation problems.
I'm not sure it's that; it might be a problem with DNS. I've had problems connecting to nextgrex by name, but it works just fine via IP address.
There was some talk recently of settng up a staff wiki where we can document procedures and such like. I thought this was a good idea, and that maybe other, more public, uses for wiki's could be found on Grex. I took a quick look around and decided to try mediawiki, the one that is used for wikipedia. It requires php, so I set out to install php from the ports tree. This was a mistake. The ports tree is a wee bit confused. First problem is that it decided to install quite a few extension modules, and their dependencies. For instance, it decided to install the interface to PostgreSQL, but since I hadn't installed PostgreSQL, it decided that I needed PostgreSQL, so it installed that. In this way it installed quite a few different packages that I don't think we particularly need. I don't mind very much, but I hope we can find a cleaner way to do this on the next OS upgrade. However, it turned out that it did not install the mysql interface, which mediawiki does need. All attempts to install this from the ports tree give an error message saying that the mysql package requires x11, which we don't have and don't want. However, this is absurd. Of course the mysql interface does not require x11. Since this wasn't working, I decided to try to use the php "pear" tool that is used to fetch and install extensions. However, only a small part of pear seems to be installed, although it is supposed to be standard in PHP 4.3.0 and later, which we have. All that is there though is /usr/local/bin/pear which is a short sh script that figures out where php is installed and runs the pearcmd.php program. This program is missing. So this is a pathetic mess. Probably I should back it all out and try to install it from either an OpenBSD package or from the original PHP distribution. Foo. I guess I also don't have any idea how to enable PHP for the system web pages, but not for user web pages.
Why not use PostgreSQL instead of MySQL and be happy? And what's wrong with TWiki? That, to my knowledge, doesn't require a SQL RDBMS.
The inventory database is written to MySQL, so we need to have that whether or not we have PostgreSQL. (I understand it's already there; Jan is talking about the PHP interface to these databases, I think.)
Yes, Jan is referring to the latter. However, it was my understanding that the inventory database was for msql, which is again a different beast (and much older and less widely used). It'd require some tweaking to get running under either; I'd prefer to see it go to pgsql instead of mysql if work hasn't already been done. Regardless, TWiki doesn't need an RDBMS, and it uses CVS for versioning. I'd say let's try that instead of mediawiki.
I got php to work correctly by installing it from the package instead from the ports tree. I should probably do more package installs instead of ports installs. But they are in some ways clumsier to use. It turns out I didn't have mysql fully installed - I only had the client and not the server. I got it fully up and configured. Invent uses MySQL, not msql. Nuget uses msql, and will need to be replaced. Neither mediawiki nor anything else that we now have requires postgreSQL. I'll probably uninstall it. I expect we'll be using MySQL for many things. I got mediawiki working, but I'm not very happy with it. It is rather stupidly configured, with the file containing the MySQL database password residing under the document route. It's a .php file, so you shouldn't be able to see the source under ordinary circumstances, but why put it there in the first place. I'm not entirely happy at the idea of having the Grex Staff Collective Memory buried in a database that can only be easily read via this particular application. If apache, php, mysql and the wiki aren't all working, you can't read it. There're a couple other things I don't much like about it either. Which is too bad. I like way it looks from the outside. Maybe I'll look at twiki.
Looks like Twiki is based on RCS not CVS. Written in Perl. Might be a better fit.
Point.
The new grex machine's name is grease.cyberspace.org. Is that the name people are using? Is that the name giving DNS trouble? At least once a day, I check the name server on grex (dns.cyberspace.org) to make sure it's offering up information. Occasionally, I check some of our secondary name servers, as well. I've not noticed any problems yet. Despite the fact that named is restarting and dumping core (probably not in that order) frequently.
Which named is doing that? On nextGrex? I uninstalled mediawiki and php. I installed Twiki. I haven't figured it out, but I have the impression it will do the job. I set it up to authenticate out of /etc/passwd, just like backtalk. However, it still kind of wants you to register. Ideally I'd set up a Staff Web that can only be modified by staff. Possibly there would be some pages in that that could only be read by staff. Don't really know how to do this though. Don't really want to spend the time figuring it out right now either. Should get back to working on more critical things. If any other staffers want to test this, it's at http://grease.cyberspace.org/twiki/bin/view/
The named on the current grex, Jan. I should probably take a look at the one on grease, too.
Trying 216.93.104.38... Connected to grease.cyberspace.org. Escape character is '^]'. OpenBSD/i386 (grex.cyberspace.org) (ttyp3) User not authenticated. Using plaintext username and password login: newuser Password: Login incorrect
savage.
Oh, is it really RCS? Tom Limoncelli lied to me.
What do you get when you cross a Lemon and a Cello ?
There's always room from JELL-O!
I'd be glad to test connectivity from Seattle..
Doesn't traceroute do that for you?
Point.
Point.
Point.
The named on grease has been up and running since the last reboot.
Point.
soup@m-net-bash-2.05a$ ft grease: FrontTalk 0.3.2 Copyright 2001, Jan Wolter Connect to 'grease' failed. Unknown system 'grease'. :( Point.
Point.
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?
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.
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.
Point.
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?
Re. 277: Take a break, Jan. Nothing worse than working on something you don't enjoy. We can live without NextGrex awhile longer.
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.
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.
He's also good at inserting a tty file into my homedir when I"m trying not to idle out.
Hmm?
Re. 284: ;) (as it were)
re #286 *wink wink* *knudge knudge*
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.
Maybe it's your son.
Would item 4 be more appropriate for this problem?
funny...there doesn't seem to be any over lap in time...must be magic
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.
The tty file wasn't there until someone(other than myself) put it there.
I don't know. What if `tty` printed out `tty device not found` or something?
Yeah?
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.
Let's talk about how the tty file got into my homedir in the first place, shall we?
Short answer: Your script doesn't work. I don't know why it doesn't work, though.
Anyone else care to comment on the likely fate of NextGrex?
NexGrex will come up, eventually. Jan is the only person who seems to have the time, skill and motivation to see to it. And, as with all of us, time and motivation isn't constant. We have no choice but to be patient when it ebbs and thankful when it flows. Meanwhile, the rest of us can do the best we can to keep Grex interesting and enjoyable, despite the lag. How are *we* doing?
Sorry about the fact that my energy for that project ran down. It'll run up again sometime, and there really isn't that much left to do. I'm also sorry that there isn't anyone else working on this.
Gelinas is also working on this and fixed a few things at my request. What is left to do?
chop chop!!!
I volunteer.
I also volunteer.
I would also appreciate a list of things remaining to do on NextGrex.
I posted one here a while back when I decided to take a break. If it has changed, it's news to me.
resp:277 is it.
When was the equipment for NextGrex purchased?
May, 2003, IIRC.
I volunteer to generally test everything.
I volunteer.
I've installed patches 021 through 024 on NextGrex. None were especially
important.
We need a staff member to subscribe to whatever OpenBSD mailing list
announcies new patches and take responsibility making sure that they get
applied in a timely manner (ie, for important security patches, almost
instantly). I don't want to subscribe to the OpenBSD mailing list, though
I'd usually be available to help with applying patches if there are any
problems. (I've never encountered any.)
We need to start doing this even before we move onto the new system.
Applying security patches is pretty straight forward. My procedure is:
(1) Look at the directory /usr/src/patch. All applied patches should
be in here. If a patch is here, you can assume someone else already
applied it.
(2) Download a copy of the patch to /usr/src/patch.
(3) Apply the patch as described by the patch. Usually this is just
a matter of cut/pasting four or five commands.
(4) If necessary, rebuild the kernal. Patches to the kernel source
include a reminder to rebuild the kernel. To do this, follow
instructions in grexdoc/openbsd/04-kernel. Basically, you need to
cut paste 7 commands from that file to do the build, and then copy
the new kernel into place.
(5) Reboot, if needed.
Sounds like Gmail would be a good idea, but as I understand it you can only use it if you've been invited, at the moment. If someone wants to subscribe to the OpenBSD mailing list(s), I'll be happy to send out an invitation. Please include an email address I can send it too.
What is Gmail, and why would it be of any danged use?
Have you been living under a rock?! ;-) Gmail is webmail from Google, with 1000 MB of storage space per user.
But in what way would this help us monitor OpenBSD release notices? All staff members already have email accounts.
Well, I admit it was due to a presumption on my part, the presumption being that you didn't want lots of OpenBSD-related mail clogging up your inbox(en). If you used a Gmail account just for that, that would give you LOTS of room to manoeuvre.
I've got a reasonable first draft of the log rolling set up, and have ported the birthday wisher.
Don't all the OpenBSD security adisories go to announce@OpenBSD.ORG or something similar? Isn't that an extremely low volume list? Why not just subscribe the staff email list to it and go from there?
Beats me. Why not?
Am digging through /usr/local/bin on Old Grex, looking for stuff to move. Does anyone know what /usr/local/bin/charm is?
Running /usr/local/bin/charm --help brings up the following message: Bad switch char <h> Usage: charm olduid newuid newgid paths... This suggests it's a command for changing the (you guessed it) user and group id's for multiple files; it also suggests it needs superuser privilege to run (and thus test) it.
I guess the name is derived from "chown" somehow?
Well, it's probably not moving to the new system, as I can't find any source code for it. Also currently unlikely to move: bbsed chill csplit es dircolors dn factor fullname fv I've gotten as far as the g's in reviewing Old Grex's motd but my brain has melted, so I'm going to stop. The 'board' command on Grex needs to be updated by someone who knows who is on the board now.
bbsed and es appear to be line editors, which probably no-one will want anyway; csplit splits files, and I'm fairly sure we have the technology in OpenBSD or the GNU tools anyway; chill appears to be a bizarre link to gcc; the function of dircolors can probably replicated by a shell-script even if there is no command "dircolors" on OpenBSD (but there may well be, as this sounds familiar); dn is for finding the tld of a country, factor for finding factorials, fullname appears to be for finding full names from finger info (rewrite as shell script or use finger); fv is a binary editor. I don't think we'll miss much on that list.
I'm pretty sure factor actually attempts to find the prime factors of sufficiently small numbers, not factorials! Es was, if I'm not mistaken, written by Marcus Watts, who seems mostly UA these days. The rest seem unlikely to be used.
Thanks for the correction; maths is not my strong point, so I didn't know there was a difference! :-(.
Heh, mee neither. Then again, i lost my strong point in a spanish whore. :-<.
Sorry for not being clear. I knew what those were. I just didn't plan to move them over. A bigger PitA is going to be "watch". This program is actually used regularly by Grex users. I wrote it approximately 20 years ago for System III unix. It has been patched up from time to time to move it from system to system. It's not well written, and its not very portable, but I guess I'll have to look at it. Ick. We have "irc" installed on old Grex. Dunno if anyone ever uses it, but if you are a member it works. There are lots of irc clients in the ports tree. Should I install one? Old Grex is set up with two locate databases, one accessible only by root that indexes everything on the system, and one that indexes only directories readable by regular users, that is used by everyone else. Do we need to replicate this on Next Grex? There's a command called "opt_out" which is apparantly to allow members to opt out of getting membership reminders from the treasurer. Is this still being used? I think "mathom" is not being moved over. I've made it about halfway through /usr/local/bin.
I'll update the 'board' command, and the relevant web pages, on or about New Year's Day, when the membership of the board changes. IIRC, the root-accessible database is used to free up disk-space. With quotas, that won't be as necessary. Especially if we can set up an automated reaper.
What does Grex 'watch' do? I have a program on my Linux system called 'watch' which continuously monitors command execution at defined intervals; it's not a user-defined script or a commercial program, so I bet it's available on OpenBSD too. (Yeah, OK; "continuously" and "at defined intervals" are mutually exclusive.)
irc, hrm. I've used that from time to time. We're losing mathom??? Sad.
the 'watch' program is a background process which informs its invoker of the login and logout of users passed to it as parameters e.g. watch janc srw gelinas would display a message to my terminal when either of those three users logs in and logs out If I recall correctly (been years since I used it), it says something like: "in: janc" "out: gelinas" It is a program commonly invoked in users' login startup scripts.
Ah. Sounds pretty easy to write as a shell-script.
I remember using "bbsed". No loss to the world. 8-) Thanks for this fine work, janc!
I would certainly not let porting of something such as "watch" hold up the nextgrex completion. If some people really like it, hopefully one or more of them have the ability to port it themselves for the benefit of everyone.
Where's the source code? It'd be neat to write it as something that used kqueue to watch the utmp file instead of something that periodically polled. Yeah, that'd be neato.
I think very little of what I am doing now is worth delaying the transition to the new system for. It's all pretty non-critical. I think from a technical stand point we could start the transistion today. However, my kids are out of school and I can't really be sure that I'll have large blocks of time to work on things during the next few weeks. And somehow my faith that other staff members are going to help out with the work isn't very high. So we could shut down Grex now and start the switch over, but it might end up being a longer down time, just because of my limited availability. Or not. I don't know. It'd be nice if more testing had been done.
I finished twiddling through /usr/local/bin. Here's my complete list of puzzling files. They are puzzling in different ways. Some I don't really know what they are for. Some I know what they are for, but don't have source. Some I have source for, but don't plan to move over. killwatch I plan to move over, but it should be done with 'watch'. bbsed: Old line editor. Forget if possible. board: Need updated version. chill: Part of chill compiler. Don't want it. es: Marcus's old line editor. RIP. csplit: Context split. dircolors: sets colors for ls. dn: Convert two-letter country codes into names. factor: Factor numbers fv: Binary editor grabenv: tool to look at other user's environment variables. grabstty: tool to look at other user's stty settings. killwatch: Program to kill watch lastlog: Lastlog dumper mathom: Valerie's old mathom program. Needs work. Not supported. nl: sparc demand paged dynamically linked executable not stripped. opt_out: Something to opt out of treasurer mailings. Is it used? pcprint: Script to print from pc. md: symbolic link to mkdir. Why? rd: symbolic link to rmdir. Why? resize: reset terminal size. rgrep: recursive, highlighting grep program. sdiff: side-by-side display of two files. seq: Looks like a 'jot' variation. showtable: Something to pretty print tables? siggen: Part of Tripwire. tac: Backwards 'cat' tf: Tiny Fugue MUD interpretor. toe: Pretty prints termcap database. ton: Something to do with figuring out how long users have been on. unflash: Probably resets terminal so it doesn't flash? unshar: Extract shar archive from mail. vdir: pretty ls command watch: watch users log on and off termidx: Dunno. charm: Some kind of change ownership thing. deformat-c: Dunno. deformat-sh: Dunno. getfilename: Gets a filename. Why? pqueue: Maybe some kind of priority queue thing? watch: Watch users log in and out.
I have some vague intimation that dan is refering to some previous discussion in his mention of a kqueue based watch, but I don't really remember. Source for watch is in /usr/local/src/watch. If someone wants to work on porting it, they should say so fast and do so fast. If nothing happens fast with it, then I'll do some kind of quick ugly port. I don't think the two locate databases are to save disk space. I think it's for security. I think the public one is generated with updatedb running as some un-privileged "nobody" like account. It means that you can't do "locate janc" and get a complete listing of the files in non-public directories on my account. However, staff wants to be able to do exactly that, so they have a different locate database generated with updatedb running as root. I don't remember how all this works. I might have to figure it out again.
I suspect that the symbolic links for md and rd are for consistency with cd (chdir) and with DOS.
I would help, however I'm in the middle of my Doctoral thesis write-up - writing just under 300 pages of original quality research arguments is not a breeze (at least not for me). And, I'm on a strict scholarship contract schedule (just got a little over a couple more months on my non-extendible funding schedule to finish the draft thesis - nearing half written-up now), then final seminar/oral defence and revisions incorporated into thesis shipped to overseas examiners (another month of work following the draft thesis write-up completion). And, all these bursts of excitement and thrills for the (hopeful granting) of the sexy title of Dr ;) So, please forgive me of my absence on this project at this time :<
No, previously we had talked about a kqueue version of party, but that's different again. I actually wrote something sort of like that at one time, but never finished it. It was designed as the server part of a client/server party package. What would be so difficult about getting watch running under OpenBSD? Hmm, I'll have a quick look at it in a few days.
Nothing much. It has various hardwired assumptions about the mapping between tty names and device ID numbers, if I recall correctly. Those would either have to be generalized or hacked to work on nextgrex.
Current To Do List (most of which is not needed before changeover):
Move /usr/local/grexdoc
More testing of zapuser and lockuser
(zapuser needs to be tested on large sets of users)
Review /usr/games and /usr/local/sbin for other things that should be
moved over.
Test that login correctly reports failed login counts. Telnet and ssh should
both be reporting these.
Port 'watch' and 'killwatch'
priveleged and non-priveleged versions of 'locate'
fork bomb killer.
friendly error messages from login
hierarchical mail directories
spam filtering
testing and tuning of robocop
Games could wait. So could spam filtering as we don't seem to have any now anyway (apart from procmail). I would really like us to move to next grex in the next 10 days so that I don't miss much business-related mail if it does not happen overnight. Maybe next weekend or as soon afterwards as staff has the time to do the switch. Thanks Jan and Joe and any other staff who have taken the time to work on this.
I've announced that Grex will be shut down to start the changeover on December 26. I expect it to be done well before the new year.
Too cool.
Go Jan, Go! Suggestions: Forget the forkbomb killer. I doubt it's needed. Put mail in home directories.
Whoo-HOOOO!
Extremely excellent!
I am soooo excited!
Can we have a celebration party when nextgrex gets online? There is a small chance Jim would agree to cram 10 people into his house for a potluck given a week's chance to clean up a bit first.
that's a pretty small house if you have to "cram" 10 people.
FYI- Regarding `watch'; I looked on mnet, and they're using a clone called `uwatch' that's in the FreeBSD port's collection. It appears to be a rewrite of watch from grex (well, I imagine the original watch as it appeared on mnet and was subsequently ported to grex). Given that it's in the FreeBSD ports collection, I suggest what we do is install it, and then contribute the port back to OpenBSD. Jan, I don't know exactly how you do all this funky stuff; if you tell me, I'll do it in a few days and document it in your CVS tree and go from there. I suggest someone else submit the port to the OpenBSD people, as I don't get along with Theo too well.
You mean some people do? ;-P
Marvelous news, janc!
Well, not to my knowledge, but someone must have gotten along with him at some point as he's still alive. :-)
Heh. Good point.
For a small program like 'watch', I'd probably stick it in the Grexdoc CVS tree in the "misc/src" subdirectory. There are other similar little programs already there. The "misc/build" script (somewhat counterintutively) builds and installs those programs. The "killwatch" program is just an sh script, and should go in "misc/grex-scripts", with a symlink command in "misc/scriptsymlink". (I didn't create the "misc" subtree - DanG did. I just added more to it.) Interesting that my watch has wandered into the FreeBSD ports tree. Getting it in shape for the OpenBSD ports tree is not a task I'm interested in. I just want it on Grex, and getting it into the Grexdoc tree is good enough for me. I haven't ever interacted with Theo, but since I have basic personality conflicts with OpenBSD, I suspect it wouldn't take me long to find some with him. Just for confusions sake, we have the grexdoc CVS tree and /usr/local/grexdoc. They are completely different.
Why are we moving to OpenBSD when the person who is doing all the donkey work doesn't like it/the team?
Well, I argued for FreeBSD. There's nothing wrong with OpenBSD itself. I believe it is more secure than competing operating systems, but not as much so as they'd have you believe. However, it's user community is not fully functional. It is essentially unfriendly to all those who are not of the annointed. I'm a pretty good programmer, I've known few that I consider my superior, but I do not care to be a member of any exclusive guru clubs. I believe that it is part of my job to be able to explain what I am doing to anyone who wants to know, and that few things are more interesting to me as a programmer than the questions a newbie asks about my programs. This difference in attitude is why I say I have a personality conflict with OpenBSD. I think the lack of a fully functioning user community will ultimately be fatal to OpenBSD. It will not be able to keep up with Linux or even FreeBSD. The OpenBSD people have introduced many valuable innovations, especially in the area of security, and will likely continue to do so. The best of these will, in good time, be adopted by the other free OS's. But people actually running production systems will more and more find that OpenBSD doesn't cut it for them. OpenBSD will be regarded more and more as an experimental testbed for various security ideas, rather than a real working OS. When the passage of time claims a few of the current leaders of the OpenBSD effort, no one of equal skill will replace them, and the whole thing will fade away. It will have had an important and lasting influence on other open source operating systems, but it will not, itself, continue to exist. There are already significant cracks showing. I think one of the largest is that there appears to be no native version of Java for OpenBSD - you need to run Linux Java or FreeBSD Java under OpenBSD's emulation mode. It's not completely clear to me how well that works. I don't really think that an operating system that has issues with running Java can be taken entirely seriously in this day and age. Sure, they'll fix this, but will they fix the next thing and the next thing? And how far behind will the be with their fixes? I don't think OpenBSD should change. I think it's particular personality makes it able to contribute to the broader free software effort in a way that would not be possible if it's developer community were just like the Linux or FreeBSD communities. However I think this personality limits its appropriateness for use on Grex. Well, I was out voted. I don't mind. The step from SunOS to OpenBSD is a huge step in the right direction. SunOS was *ancient*. OpenBSD is maybe just a bit off the leading edge in some ways (though it is the leading edge in a few significant ways), and though it may fall further back, it won't fall back as fast as SunOS is falling. If someday we feel the need to step off OpenBSD onto something like FreeBSD, the step will be far smaller than the one we are taking now. Do I wish the people who argued so fervently for OpenBSD where actually here doing something about it? Sure. But what the heck, that's how it goes.
How much effort would it be to switch from OpenBSD to FreeBSD, maybe in a couple of years? Jan, I hope you are learning something useful to yourself from all your work here.
Not that hard. Basically, by that time, we should get a new computer anyhow, and then it wouldn't be terribly difficult to install FreeBSD on it.
Okay, we can stick it in grexdoc. By the way: should we compile it with the built-in party support? That says it's semi-obsolete. I don't know if the uwatch stuff does that or not.
FYI- I changed the links in /usr/local/bin on nextgrex so that `bbs' now runs fronttalk, and `picospan' runs picospan.
Um. A decision was made to start out with Picospan. Because of that decision, I decided that fixing bugs in Fronttalk was not on the critical path to getting up on NextGrex. Therefore bug patches to Fronttalk have been moved to the back burner and have not been done yet. Fronttalk is not ready to replace Picospan on NextGrex. I believe the general sense is that there is strong support for moving to Fronttalk. I expect to do so within a year. I don't remember what the built in party support in watch does. No, I don't really learn anything useful to myself from working on configuring OpenBSD and all the various software packages on Grex. I'm a programmer, not a system administrator.
When was a decision made to start out with picospan? I certainly wasn't aware of that. I do remember a decision being made to install picospan on nextgrex, and have it accessible, but not that it should be the primary choice. Please correct me if I'm wrong.
(Regardless, I switched the symlink for BBS back to picospan. Ugh.)
Item 205:33ff, Dan. You objected then; I didn't expect you to change your mind. :)
Heh, okay, I'll check out the reference.
My motion to bring to a vote by members re: determining that bbs on nextgrex would be fronttalk has stalled, awaiting sufficient support from the membership (10% = ~7 people). Failing that, staff has the freedom to use its own discretion, I guess.
I appreciate the effort. I really think we do have to move beyond Picospan, and I think Fronttalk can be, at least, a good first step on such a path. However, Picospan belatedly appeared on Grex, and that made it possible to move the Fronttalk project off the list of things that needed to get done before the move to the new system. Let's get one thing done at a time.
Very well. Still, I don't see why we can't run ft as the default, with picospan as the backup for those that encounter bugs. Ah well, whatever works best, I guess.
Grex is back in just THREE DAYS! Jan and Joe, I love you. (And everyone else working on the transition).
A few problems using Pine:
1. I type Pine and am told 'Folder vulnerable - must have 1777 protection'.
I get the same message going into another folder besides INBOX ('from' under
/mail which is where I keep my procmail log of what went where).
2. Procmail is not working as expected. First time around it said I had 1
message and I typed Enter and could read the list of what happened to which
mails UP THROUGH DEC 26. I just sent myself a spam (subject line Cialis)
which never arrived in the inbox or in the log. The second time I tried to
look at this log it said 1 message but it was blank when I tried to read the
list of what went where. So I looked at it with less after cd'ing to my /mail
and everything is still there but there is NOTHING listed after Dec 26 so I
don't know where the mail I sent myself went or whether mail is working at
all since I have not received any mails yet today, even spam.
My apologies for not setting up a procmail spam filter while testing NextGrex.
3. There were four mails from late October after the Dec 26 mails, which I
thought I had deleted then.
No need to apologize Sindi. However, I do see grex's mail logs bouncing mail sent to pipes. It appears to be a problem with shell syntax in .forward files; I'm not convinced exim is piping commands from .forward's into sh.
I think I know what the syntax error is; sendmail expected commands to be quoted, and IIRC exim does not. I am testing that now.
OK, I have verified that the following text in a .forward file sends messages through procmail successfully: |/usr/local/bin/procmail
You don't need the -f- any more (or the " ")? It appears to be working okay for me now with -f- (but for some reason mails from keesan@ all go to my inbox despite spammish subject lines - no big deal).
The -f- tells procmail to update the "From " line in the message envelope (not the From: header) with the current timestamp. My personal opinion is that this is not only unnecessary but a poor idea; that original timestamp may be useful in analyzing a message (for example, if it is thought to be a forgery). As I mentioned in the System Problems item in the Winter Agora, the reason the filters are not catching emails from yourself is that you have a whitelisting for From:.*grex in the middle of your /dev/null blocks.
Some of the people who tested the new machine had a mail spool file on the machine. I appended those files to the mail spool files moved over from the old machine. That's why you have some October messages after your December messages, Sindi.
Thanks for the explanation, Joe, which also explains why my four appended mails had to do with next grex. Blaise, I will remove the -f- and I already deleted from my whitelist keesan, grex, org and edu. I go back and forth between having them on the whitelist, depending on how much spam they have caught recently, and how much real mail gets sent to /dev/null. This is great, mail is already working properly and it is not even 2005! (Not counting problems with elm, of course). The file transfer problems are less urgent at least for those of us with ftp (which I ought to test now).
This response has been erased.
This response has been erased.
"older version" shouldn't be hyphenated.
OpenBSD does kqueue; that's not an issue. I rewrote the watch.c used here on grex and it does what's needed. If we want to port uwatch, I'm not opposed to it.
I, contrariwise, am.
Regarding the previous problem of mail stopping up Grex by filling the /var partition... Has Grex ever considered using Qmail for its email system? It has the advantage of storing mail spool files in user home directories, thus subjecting them to quota limits.
We could configure any mail system to deliver to home directories. I, at least, don't think that is a good idea. When mail delivery to a shared space is set up properly, it is hard to deny service to a single user. Right now, we don't have it set up properly, obviously. (We did have it done properly on the old machine, and we will get it set up here eventually.) When mail is delivered to a user's home directory, it is very easy to deny service to a single user by simply flooding them with mail. When they hit quota, a lot of things start going on that novice uers (grex's primary audience, remember) simply don't undeerstand. And some things break in such a way that they can't easily fix it themselves. Let's not go there, 'kay?
If a user gets sent 100 10K spams in half an hour, don't they still get service denied?
Only mail, not everything they do.
I don't see any big advantages to delivery to home directories. What we are doing now can be made secure and reliable. Delivery to home directories can be made secure and reliable. The problem that started this discussion, namely mail filling up /var, was a configuration error that has been fixed and that will never happen again. (I had failed to mount the /var/mail disk partition, so mail was being delivered into the /var partition, which was never intended to have mail on it and so was not sized large enough to accommodate mail.)
(The fault was not all yours, Jan: I put the mail spool files in place; I could and should have checked to make sure the right partition was mounted first.)
I guess this is as good as any item for bringing up the following: I don't recall seeing anywhere in coop or agora the mentioning that the O/S for nextgrex would apparently relax a restriction (I'm assuming it was) from the O/S of old grex such that under nextgrex userIDs could be longer than 8 characters. This may have been considered one of those technical things that only needed to be covered in garage - I don't know. But personally speaking, I would like to retain the 8-character-maximum length for userIDs, under nextgrex, even if the O/S supports longer ones. I have already seen in agora that there are others who already agree that a restriction in userID length is desired (although maybe 12 or 16). How do you recommend that I proceed on this issue? Create another ill-fated membership vote?
Let's start by just discussing it here, before setting bureacratic
mechanisms in motion. If a concensus emerges that people would like
a shorter limit, staff can just *do* it.
My preference would be to retain the old 8-character limit, for a few
reasons, some better than others:
(a) It wasn't broken.
(b) Increasing the limit could break some software that assumes the
old 8-character standard. (No sign of this yet, but it hasn't
been tested.)
(c) Long login id's mess up formatting of column-oriented listings
that include login id's (e.g. who, finger)
(d) Long login id's are inconvenient to reference (e.g. in email
addresses, URL's, and other contexts).
I think 32 characters is way too large a maximum. I'd prefer 8 but
could live with 12.
Keep in mind that the maximum is 31, not 32.
Sub-reason for (c) in #397 above: Party formatting gets messed up. Sub-reason for (d): It's a pain to :ignore someone with a 27-character login, since you have to pass the login as a parameter to :ignore.
keep in mind it's also a pain to use a 27-character login, so don' t expect too many of them.
I would be happy with 6 characters but jdeigert might like 8. I cannot think of a situation where anyone would need more than 8. What is the theoretical minimum needed for 24,000 current and maybe that many past users?
3 characters would be plenty, if minimizing size were the goal.
Re #396: See responses 10ff of this item.
Yes, I stand corrected. I don't know how I could have forgotten that - I mean, it was only a little over a year ago... ;-)
I knew where to start and had the patience to wade through as much as necessary to find it. :)
albaugh> I would like to retain the 8-character-maximum length for userIDs,
> under nextgrex, even if the O/S supports longer ones.
> #397 of 405: by John H. Remmers (remmers) on Fri, Jan 14, 2005 (14:33):
> Let's start by just discussing it here ... If a concensus emerges
> that people would like a shorter limit, staff can just *do* it.
>
> My preference would be to retain the old 8-character limit
So, is there consensus, how is that judged, what does staff need to see to
reinstate the old 8-character limit?
I, for one, prefer a longer limit. It's hard enough expressing a personality on a license plate; why make our online life as difficult?
I don't see why a userid should be used to express a personality. You can always change your name in the bbs (and probably in party). Longer usernames are just more bother to filter. Nobody but twits seems to be using them, they don't print out properly with 'w'.
RE #408- Sindi, names, and thus handles, mean a lot to some people. Names convey a great deal- more than most people think. Just because you see nothing in it does not mean that other people do not.
(Nor does it mean that there is nothing there.)
The long name standard is annoying. I'm with Sindi on this.
Usernames are supposed to be an unambiguous, easy-to-type easy-to-remember way to refer to a specific user. They are not primarily intended to be a creative outlet. Long ones do not serve this purpose better, and I say this as someone with a long name which arguably could "benefit" from longer usernames.
Why are you marcvh instead of mvh?
I tend to think that usernames which are mostly pronouncable sequences work better than usernames where the letters are all consonants. It's also possible that mvh was taken when I registered nineteen years ago; hard to remember. Maybe we should get rid of usernames and just use UIDs for these things.
Hey! That'd be like TOPS-10!
I'm waiting for remmers to comment. I'll try to take things to a vote "if I have to", for all the good it would do. In the mean time, grex mailbox handling is broken, AFAIC.
When I see "ken" and "dmr" and suchlike, that's when I miss having a middle name. It's not as common in the UK as it is in the US.
http://www.humnri.com/HumZone/Jokes/read.asp?id=429&JokesCatid=14
LAME!
LUST!
My personal opinion is that people getting hot and bothered over long names
are letting themselves get overheated by a small number of prank accounts.
Below is a list of all the more-than-eight-character logins on the system
right now. Are they all evil? It is bad for "Ron Jeremy" to have the login
"ronjeremy"? Should "Mark Silverstone" not have the login "silverstone"? Is
"siegfried" an unreasonable login name? Is "intellectual" too hard to type?
Harder than, say "l01010l0"?
Personally, I think everything up to 12 characters is perfectly fine. There
are a total of 17 longer logins which don't bother me much either, if only
because I don't expect people to be logging in to them much. If people
really care I wouldn't object to reducing the newuser limit to 12 (and
increasing the webnewuser to 12). I don't think that would block any
reasonably desireable logins.
However, it's nice to have a nice login name. With tens of thousands of
users, it isn't always easy to find one. Allowing logins longer than
eight characters means more people have more chances of having a nice
login. Yes, it also increases the range of obnoxious logins that obnoxious
users might choose, but if you spend all your time focusing on the obnoxious
people instead of the nice people you are just going to make yourself
miserable. Let's be nice to the nice and not worry so much about the
obnoxious.
ronjeremy Ron Jeremy
jonasyorg Jonas Yorg
thisisgay jason wilson
creative2 Teresa Thomas
pachecosc adriano
rajeev212 rajeev
simulacra Engin Daloglu
maldini03 budi maiden
meskalina Bartosz Ogonowski
amitchell Andrew Mitchell
emyrrdin6 Emrys Myrrdin
testectbc teste
p08020109 Waqas Burney
nullvalue null
mardonius fernando martinez
andrew2iz Andrzej
nightmare NighTmarE
coderjon0 Jon Bryan
indian123 QWERTY
barmaglot B r a n d s m g
pileswasp Iain
poyzunivy Heathyr F Hoffman
athnetius Conrad,,,
giancarlo Juan Carlos
unidade05 Un1d4d3_O5
misiek999 Vlad
jagadeesh Jag
ofitr953r Fuck Hankins
anujpuri1 anuj puri1
siegfried Siegfried Rudzio
centaur78 dan
lnitrousl Harry Pua
silentman faisal
jamespong James Chau
kcfanatic Darren Nichols
selvar911 selvar911
bimaldswer Bimal D Swer
hentaijiji Hentai
satyen4you satyendra
edgarcsosa Edgar Cosme Sosa
starrdruid Aleksey
o123456789 onetwothree
doublechaz Charles Mitchell
etat613613 tate christie
tritobagus Trito bagus
abangbatax abangbatax
juancarlos juan carlos
davidspant Dsavid Sabido Pantoja
sasuandrei sasu andreio
jeffreyuop Jeffrey
sharadstud Sharad
cyberactiv frat
myth1heart Marilyn Giglio
jollyjoker jolly joker
craigcolby Craig Colby
thebrother The Brother
wujeksopel Wujek Sopel
handalatif handalatif
titiritero El titiritero
masturbator fiomger
greenscreen Adam McFillin
littertiger little tiger
admincarlos hans
hatepimples hate pimples
silverstone Mark Silverstone
abcdefghijk Ateste
shakespeare William Shakespeare
ryan1111111 Ryan1 Test
nobitagamer Yahoo Operator
bhatiavarun Varun Bhatia
kcmiata2001 Andrew Kain
elvispresley Elvis Aaron Presley
intellectual The Intellectual
foodrunner44 Fatboy Slim
nharmonthefag nate
terminalhacker terminal
abrahamlincoln Abraham Lincoln
sherlockholmes Sherlock Holmes
hongkongphooey Hong Kong Phooey
thomasjefferson Thomas Jefferson
georgewashington George Washington
asddsaasddsaasddsa sad
zyxwvutsrqponmlkjihgfedcba WWW
abcdefghijklmnopqrstuvwxyz Anotherteste
tridotforwardemailtorichard asdf
triludaaisagheyfrickenfaggot TRILUDAA
triludaaaaaaaaaaaaaaaaaaaaaaa james
mfpmfpmfpmfpmfpmfpmfpmfpmfpmfp klooger
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqq The Name Greater than All Imaginable Names
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq Archaic Revival
mygrexaccountforemailidonotwant Kate Sandler
Judging from the above list, anything more than 12 characters apppears to be the work of vandals, or at the very least of users who don't intend to use these logins - Anotherteste . I would cut it off at 12 or even 11.
I think 12 is good.
How about split the difference, and go with 10. :-) Seriously, though, how is the decision arrived at, what is needed to deploy?
10 or 12 sounds fine by me too. The decision is arrived at when there is a sense of what is reasonable from a reasonable majority. And those who disagree have had a chance to state their case. I think we're moving in that direction. I trust staff's judgement to know when it's time. We really don't need a vote on this, Kevin. Staff can handle it just fine.
I'd say 12 is good.
Incidently, `ronjeremy' is more than likely not really THE Ron Jeremy, who is a guy who holds the current world's record for appearing in the most `adult' movies.
And was pretty cool on The Surreal Life.
Well, it's been 2 weeks now. So when is it soup?
Huh?! you talking to me ?!
12.
I'm opposed to just about any limit. The limit used to be eight, because that is a "word" eight bytes. Now the limit is 32, because there is enough memory for 32, and it's a multiple of two. Eventually, it will probably grow again. Once upon a time, every filename was eight characters long, followed by a dot and three more characters. Do we *really* want to go back to that limit? If not, why are long names could for files but not people? It ain't broke, it don't need fixin'.
I don't like long file names for files either. Difficult to type. Are there any commonly used programs here that need more than 8 characters? lynx pine mutt mail w3m pico which
!fuckyoukeesan
Longer filenames came about as a result of interface modifications which made it such that most people only typed the name once -- when first creating the file. Sometimes not even then. That does not apply to Grex -- in general you type somebody's username if you want to do something relating to that account. But hey, if we want to give people usernames like thomas~3 then I guess that could be workable... :)
Oh boy.
re#429- have a little patience. We rarely ever decide things quickly! ;) re #433- the problem is that while you don't like logins with more than 8 characters- other people do. So do we go with only what you want or try to come to a consensus with more users?
Why don't we just restrict them to eight again and keep everybody unhappy?
re #438- because I don't like that answer. ;)
I only need to deal with these long usernames once, in .cfonce.
re #440 then while it's a nuisance for you to have to type so many extra letters- at least it's only once.
But then I forget to use pico -w and bbs won't work.
then try adding the line alias pico="pico -w" to your .profile file, Then, do source .profile After that, pico will automatically start with the -w option and you'll never have to remember it.
I like twenex's suggestion in #438. :-) I'll give it to the end of January before I boorishly create a member vote.
re 442- are you honestly suggesting that your forgetfullness is really a good reason for the rest of the system to change?
I don't agree with any limit either, but I'm afraid that nothing will ever get done, so I say 12. I think 32 is a better idea. How in the world will we vote on something like this?
Everyone says a number and then all those numbers are summed up and divided by the number of, uh, numbers.
(by the way: i just realized: jan posting that part of /etc/passwd should be seen as tacitly disagreeing with gelinas's absurd assumption that posting /etc/passwd usernames in bbs somehow comprises a danger to the system. despite this, i don't expect gelinas to do the decent thing and restore my accounts, which he froze/killed for the very same thing jan did.)
(well, it depends on which part of the /etc/passwd file gelinas found the MOST incriminating, so to speak. For example, jan's posting contains only usernames drawn from /etc/passwd, and perhaps gelinas felt the username coupled with, say, the UID, constituted the reason for the scribblage. )
Actually the difference is that when you act like an asshole, you shouldn't be surprised when you get treated like an asshole.
If you want a quick resolution of this, I don't see how a vote would help. A vote proposal would probably delay a decision more than just discussing it here. Have a look at the voting timelines specified in the bylaws. Not to mention that a proposal doesn't guarantee that there will even be a vote, since a certain percentage of endorsements is needed for a vote to take place. This is too trivial an issue to subject to that kind of bureaucratic process. Marc, in an early response, echoes my main issue with really long user id's - in the context of Grex, to do something with the account (send email, add it to a list, whatever), you have to type the name. And a long name is harder to remember and easier to mistype than a short one. HOWEVER, it remains to be seen whether that concern will really be a problem in practice. The data Jan entered in #421 is instructive - since the limit was increased, we've seen a bunch of reasonable id's created with 10 or 12 characters or so, and a few prank accounts by folks who like to test the limits. Those folks are going to continue to test limits no matter what. Another downside of a vote at this time would be that we would be trying to solve a problem before we even know the extent of it, or even knowing for sure if it's a problem; this is almost always a bad idea. I'd suggest the following, for now: Leave the limits as they are, and modify the newuser text to recommend that peoople choose id's of no more than about 12 characters or so, pointing out the advantages of having an id that's easy to remember and type. If after a few weeks pass, it's evident that the current limits are a real problem, we can always revisit the decision.
Good call, remmers.
resp: 451 precisely.
This loginID, although being thirty characters, is surprisingly easy to remember, because it is simply asddsa * 5 . One can't say that the length of a UID is related to the simplicity to remember.
Re. 449: He took issue with the usernames themselves, naftee. No-one's quite sure what he thought of how every single BBS post, including the ones he made to speak out against posting usernames, necessarily (iff) includes a username, but oh well.
Nononon, he took issue with the USEABLE usernames. Which, I suppose, if a cracker bothers to read janc's post, could understand that those are useable usernames and, in the manner of posting /etc/passwd, janc's post constitutes something which really should be scribbled, by gelinas.
I think gelinas should scribble it by first ejaculating on it and then using the semen as a sort of paste to hold his shaved pubic hair.
AND he could try to shave the hard drive of the GreX computer with his razor in order to remove the information in the response for good, lest it be un-scribbled. Then he could use the razor on his beard, and replace whatever he shaved from the hard drive with this copious amount of hair. AND THEN tsty can have bearded peace again.
Oh Brother.
http://www.ohbrotherforjesus.org/
For those few who need things like this explained to them, yes, there is a difference between posting a selected portion of the passwd file and the whole password file. The first difference is SIZE, of which little more need be said. The second difference is RELEVANCE. My posting was not only small, but served to clarify the topic under discussion by presenting people with a sample of real date. I carefully stripped out everything irrelevant to the discussion (several thousand logins eight letters or less, plus uid numbers, shells and home directories). I sorted the logins by size, and formatted the data in neat columns, all to make the data readily useful to people interested in the topic at hand. I know it's difficult to appreciate these subtilities of social behavior, like the fact that what is appropriate depends on context, or on small differences in presentation (if 800KB is small), but that's just the way life is sometimes. Good luck.
If you had been paying attention, Jan, you would know that accounts were killed for posting VERY SMALL password files that were QUITE RELEVANT. This is because gelinas WASN"T killing accounts based on size or relevance of posts. He was killing them because he thought /etc/passwd files were an inherant risk to system security. This is all VERY thoroughly documented.
Even /etc/passwd files which were NOT GreX's were scribbled, I believe.
That is true. Even patently FALSE/MADE UP/INVENTED /etc/passwd files were scribbled.
Do the grex bylaws allow a member vote with multiple choices? Or must the proposal wording be strictly something that can be ajudicated pass or fail?
Has to be pass/fail.
TROGG IS DAVID BLAINE
You have several choices: