OIT SysCore

Updated our maildir driver code to the latest and greatest that fixes some file descriptor leaks that I'm totally shocked we have never seen here. This patch also logs the target of maildir_open calls, which may help in debugging.

A major upgrade to myUMBC went into production today. The intention, and hope, is that this change will be transparent to users. Please let us know if you encounter any strange behavior.

Our AFS backup system has been moved to the new Public Policy building datacenter! With the exception of the network gear (and our serial-port server installed last week), it's the first production system located there!

Thanks to Steve & Dale for trudging the gear over there!

This position is open to UMBC STUDENTS only!

Position Name: Junior Systems Administrator
Department: UMBC Office of Information Technology, Core Systems
Location: On-campus, ECS201
Hours: Up to 20 hours per week
Compensation: Commensurate with experience

Duty Profile:
The Junior Systems Administrator covers a wide-range of applications and duties in support of the day-to-day operations of the Core Systems (Syscore) group. These duties include:

• Processing and resolving student, staff, and faculty requests and issues pertaining to the systems and services operated by Syscore.
• Programming (Bourne Shell, Perl)
• Installation and maintenance of software packages.
• Installation and maintenance of Syscore server hardware.

The preferred candidate for this position should be able to demonstrate, at the minimum, basic working knowledge in the following areas:

• UNIX OS administration (Linux, Solaris)
• System services (SSH, Sendmail, Apache Web Server)
• Basic concepts of AFS file services
• Security
• Hardware handling
• Problem solving
• Ethics

Please submit your resumé with cover letter in PDF or Word format to Dale Ghent for consideration. Applications will be accepted until the position is filled.

New versions of sudo (for Solaris Sparc 8 and above) and Linux were released, that aren't reliant on the afsutil library. This is to clear up some problems with Solaris 10.

Also, a slight update was made to the openssh daemon deployed on our systems to deal with "*NOLOGIN*" users, an oversight that became visible last week.
(the build tree for the openssh *daemon* is in /afs/umbc.edu/src/afsapps/ssh)

I've built an openssh for OSX that has Kerberos5/GSSAPI enabled for use here @umbc, or logging into UMBC systems with kerberos pre-authentication. It's a tar file, meant to unpack in your Tiger system's root directory -- the ssh stuff will go in /usr/local, and a krb5.conf gets put in /etc.

It's here: openssh-4.1-osx-krb.tar.gz.

After you install it, you should be able to kinit on your mac, and ssh into core-managed systems that have had kerb. host keys assigned to them.

(remember to make sure you're running the /usr/local/bin/ssh, not Apple's ssh. I usually move theirs aside and symlink to the one in /usr/local...)

HFS12 experienced a kernel panic related to filesystem corruption on July 14, at approximatly 3:30pm. A few hours before we had noticed evidence of some filesystem corruption, that seemed to stem from some work earlier in the day attempting to enable LUN masking on the backend storage attached to hfs11 & hfs12.
While no "fatal" errors were noticed on these systems when making the backend storage changes, it seems that some disk writes to the mirror pair that was being worked on were lost, resulting in out of sync mirrors, and hense, not-quite-right filesystem data -- depending on which mirror was being read from.

Attention:

Two of our fileservers will be down for system maintenance on
Sunday, July 17th from 8am until 11am. During this time,
Email and UNIX home directory access for those users who's data is housed on these servers will be unavailable.

During this time, these servers will be brought up to the latest patch level, and various changes will be made to their backend storage configuration.

Update

zlib 1.2.3 was released into beta and gamma for solaris 8 sparc, intel linux 2.4, and solaris 10 intel.

Fixes some apparent security issues, as well as fixes some brokenness in the 1.2.1 zlib build for solaris 10 intel.

First, you need the netscape-ish command line keyutil & certutil stuff. I've got a copy of them in ~banz/work/software/certstuff/solaris. The magic files live in /usr/ns/server4/alias/*

The cert utils are amazingly stupid. Make a new directory (e.g., 'new') and
copy the -whatever.db files in to new/whatever.db.

You'll be updating the cert named "Server-Cert" the database, you can view the current cert with:

certutil -L -d . -n 'Server-Cert'


To load the new cert, do something like:

certutil -A -a -n 'Server-Cert' -t u,u,u -d .

It'll ask for the PIN for the security database; it's stored in the ...-pin.txt file. Then, cut-n-paste the new cert (.pem) file, and ctrl-d it. It might segfault, but it seems to work :)

Stop the directory server, copy the new -cert7 & -key3 files where they're supposed to be, and everything should be golden.

Last night, hfs11 & hfs12 "wigged out" and started returning "busy" for all AFS fileserver requests. This particular event causes certain things on "connected" afs client machines to hang.

Oddly, these machines were rebooted at roughly the same time on Sunday, and had the same (new) version of the AFS fileserver stuff installed on them at that time. Coincidence. Probably not. Anyhow, I've installed the previous version of the volserver/fileserver software so that if they hang again and need to be restarted, they'll restart with the previous (non-hangy) software. Otherwise, a short (15 minute or so) downtime will be scheduled for later this week to switch back to the old code.

The service processor (SP) that is on Sun V20z and V40z servers has a feature called Serial-Over-LAN (SOL) which, when turned on, redirects the serial port traffic to the SP. You can then attach to this like you would a normal serial console connection by issuing a command from the SP prompt.

This has the benefit of not requiring a dedicated serial connection to these servers. Instead of three minimum cables (SP ethernet, main ethernet, and serial), you now only need two (SP ethernet and main ethernet.)

To activate Serial-Over-LAN, log in to the SP of the machine(s) in question and issue:


platform set console -s sp -e -S 9600


Then, whenever you log into the SP, you can access the serial console with the command:


platform console


Once you do that, the serial console will appear like it would with a hardwire serial console connection. All SOL commands begin with control-e c. To bring up the SOL help menu, you would type ctrl-e c ?. To quit out of SOL and return to the SP command line, you would type ctrl-e c ..