February 3, 1998February 17, 1998
CSuite Workshop Index
Topics:
As idled seems to have been causing many users trouble doing activities
they were used to, such as printing, downloading, opening news, etc. it
was decided that we should try to come up with a version that checked
first for output characters, and only if the system had not been sending
characters to the user, then check for input characters; if neither had
been seen, warn the user, and subsequently kill the session if no further
input. We can't really check for further output, because the warning
message would reset the output time.
-> DT
Topic List
- Need to be more careful about deleting accounts that have been
marked for deletion, and have subsequently returned to good standing,
and are again in arrears.
-> DT
- There is also a need for immediate deletion for certain special
cases.
-> future
- It was noted that recovery of such deleted files would in some cases
be delayed, as it requires root access to restore the user's file
ownership
and permissions.
Topic List
There are several issues related to use and storage of various operation
logs.
- The current practise is based on "agelog", a routine to successively
rename older (daily) logs, and finally archive them after a week.
- Work required includes these areas:
- tq, var/log/idled
- rotation is needed, and archiving.
- info/recent
- this is generated by the IP install process; the query defaults to
listing results for the specified area over the previous 10 days, we
should purge any entries over 30 days old. Archiving the record is
an option. A reason for poor performance included the search through
several years data to find the most recent entries.
- log/webstats
- data on page hits is collected daily, and kept for 30 days.
- At month end, the data are summarized;
- Daily data should then be purged, with optional archiving.
- log/mail
-
- log/test*
-
- private/registration/...
- registrations not activated within 30 (?) days should be purged.
- remove from matchdb
- remove from pending
- remove registration data
- We should develop a general facility to manage disk space and
maintain the logs.
This would probably involve
- gzipping the archived data,
- moving the gz files to a staging area, and
- sending the files to a storage device, e.g. tape.
- sunset for data that has failed to be archived before disk is full
or after specified period.
A configurable policy, to define the staging area, the storage device,
and sunset limits in case the operators fail to store and remove the
staged data.
Topic List
Some special files have no defined edit process. In order to facilitate
this process, a special editing script will be designed to manage this
requirement.
The plan is to use a master script, with a configuration file to define
relevant parameters to control usage of the command.
The configuration file would likely contain
# planned format for suedit.conf (only root writable - fix up the
details :-)
# tag | path | mailto | log | userlist
suedit | ..suedit.conf | root | /root/log/suedit.log | root
money | private/../money | $TREASURER | /root/log/money.log |
blaine,djm
The script would create a temporary copy of the file, with locking,
run pico-p, create a diff on exit, accept a comment, send the diff and
comment to the specified mailto and log file, and return the updated file
to the normal location.
Example: $ sudo suedit money
To complete this we need the patches for pico -p, so the user cannot
change the file name (with root privilege!) -> CG
Topic List
Kassiem reported that he had succeeded in running a complete csuite
install on halifax.
We need to create some test accounts and put it through its paces,
although everything should be considered volatile. David Murdoch
and Kassiem will run the automated test scripts.
All problems should be reported through CSuite RTS.
Chris will try to use halifax as a mail server with IMAP access to the
mailbox. Performance timings are needed. An optimistic view would
have us put in an MX record for chebucto to handle mail through halifax
as soon as next week.
The CVS archive has been reorganized. Since our 1.0 CD image is in
transit to be pressed, the 1.0 branch is now frozen. A Special CD will
be burned with the 1.0 image and 1.0 CVS branch. Differences between
1.0 and 1.1 will be examined by Jamie, to make sure we don't lose
anything.
Changes necessary to run on Solaris will be integrated back into CVS.
Topic List
February 3, 1998February 17, 1998