response 75 of 467:

Aug 6 16:39 UTC 2004

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.)

response 79 of 467:

Aug 7 00:48 UTC 2004

 :(

response 81 of 467:

Aug 9 17:20 UTC 2004

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.

response 83 of 467:

Aug 12 03:21 UTC 2004

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.

response 85 of 467:

Aug 28 03:15 UTC 2004

....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.

response 87 of 467:

Aug 28 13:47 UTC 2004

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.

response 89 of 467:

Aug 28 20:29 UTC 2004

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.

response 91 of 467:

Aug 29 02:28 UTC 2004

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.

response 93 of 467:

Aug 29 02:39 UTC 2004

Installed figlet from the ports tree, and added the install script for it to
the CVS archive.

response 95 of 467:

Aug 29 06:00 UTC 2004

Regarding #90; Perhaps you're right, Joe, but isn't that an issue we're
going to have to deal with anyway?

response 97 of 467:

Aug 29 19:14 UTC 2004

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.

response 99 of 467:

Aug 30 15:24 UTC 2004

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.