Systems: Recent Entries

Mailing lists for University of Toronto system administrators

Update April 24 2014: please note that the information here is now somewhat out of date, partially incorrect, and partially incomplete.

We have some mailing lists for local sysadmins. In the absence of a better resource page, I'm going to list them here:

ut-admins

This is theoretically for Unix (and general issues, sort of).

Subscription requests: ut-admins-request at the domain utcc.utoronto.ca
Mailing list: hopefully the address is obvious.

nw-admins

This is theoretically for Netware, Windows, and related issues, and has monthly in-person meetings on the main campus (they get announced on the mailing list).

Subscription requests: listserv on listserv.utoronto.ca; note that the actual mailing list is called nw-admins-l.

resadmin-l

This is the 'Residence Network Administrators List', presumably for people who are involved in doing networking for and to on-campus residences. It is another listserv mailing list, resadmin-l on listserv.utoronto.ca.

utweb-l

This is a mailing list for UofT webmasters; it seems to discuss design issues and relatively high-level technical things. It is another listserv mailing list, utweb-l on listserv.utoronto.ca.

ut-redhat-l

This is a mailing list for people running Red Hat Linux machines; I am not sure if this is Red Hat Enterprise only or if it also includes Fedora. It is another listserv mailing list, ut-redhat-l on listserv.utoronto.ca.

network-service-status

This is a mailing list for notifications about network issues. It is another listserv mailing list, so you subscribe on listserv.utoronto.ca.

ut-devel-l

This is a mailing list for (software) developers. This is a newly set up (end of November 2008) listserv mailing list, so you subscribe on listserv.utoronto.ca.

I say 'theoretically' because, as usual, topics can drift somewhat from the nominal topics, and I don't think either primary list has a strict topic.

At the moment, you don't need to be subscribed to either ut-admins or nw-admins to post to them, although this may change in the future. I don't know about the others.

As far as I know, none have publicly accessible archives. (The listserv lists may keep subscriber-only archives you can ask for messages from.)

ut-admins versus nw-admins

From my somewhat slanted perspective:

General technical issues can wind up being discussed on either or both of ut-admins and nw-admins, often crossposted to some degree. Network issues and so on are generally announced to both; to some degree, I think high-level discussions tend to happen more on ut-admins than nw-admins, and as a result ut-admins probably has somewhat more rambling conversations than nw-admins. ut-admins is usually quiet except for periodic eruptions; nw-admins gets more regular traffic.

(If a constant drip of people asking about Windows administrations issues is going to irritate you, you don't want to pipe nw-admins into your primary inbox.)

Since Linux is by now probably the majority Unix on campus, ut-admins is the de facto campus Linux sysadmins mailing list; so far the traffic volume has not been high enough to split that off into a more specialized list. Thus, discussion of things like the merits of various Linux distributions does break out on ut-admins from time to time.

Red Hat Enterprise Linux support periods (again)

Sometime I will merge this information into RHELSupportPeriods, but for now, see here. RHEL 5 has security updates through March 31s 2014.

The UofT's Red Hat Network access

The UofT has a site license for Red Hat Enterprise Linux. However, you don't deal directly with Red Hat; instead you have to go through our local people and the local RHN proxy, which is found here.

(Hopefully this will save me having to re-find this information every time I need it.)

Stuff and notes about the ASUS M2N4-SLI motherboard

See also AMD64Stability.

• the sensors kernel module is it87 (and k8temp for the CPU sensors), but the IT87xx chipset used is only supported in 2.6.19rc and onwards.
• this bug has a lot of discussion about noapic and things that would need it. See also here.

Red Hat Enterprise Linux support periods

It is surprisingly hard to find this information on Red Hat's website; you'd think the support periods for the various Enterprise Linux would be somewhere on the product pages for each EL release, but they're actually hiding off in the Security Updates section.

The short answer is that security updates are done for seven years after the initial release. RHEL 4 was released Febuary 15th 2005, so security updates will be available through the end of February 2012.

This means that CentOS will also have updates for that long, since they build from Red Hat EL's source RPMs. Even if the CentOS project goes away as an organized entity, a CentOS install can just grab the RHEL update source RPMs and rebuild them directly.

What I know about the patchdiag.xref format

The patchdiag.xref file is the patch index file used by various tools, Sun and otherwise, such as the marvelous pca. Here's what I've worked out about its format, much of which comes from reading pca's source code.

Any line starting with a '#' is a comment. In practice, they seem to come only at the start of the file and start with '##', but I wouldn't count on that.

Each patch is one line, with fields separated by '|', and appears to be ordered by increasing patch number, although I wouldn't count on that. The fields are, in order:

id	patch ID, usually a six-digit number
rev	the patch's revision, usually a two-digit number
date	the issue date of the patch, as Mon/DD/YY.
rflag	'R' if the patch is a recommended patch
sflag	'S' if the patch is a security patch
oflag	'O' if the patch is obsolete
byflag	The first character is 'Y' if this is a Y2K patch. The second character is 'B' if this is a bad patch.
os	applicable operating system version, or 'Unbundled' for just stuff.
archs	the machine architectures that the patch is for, plus prerequisite patches.
pkgs	the packages that this patch affects/requires, plus incompatible patches.
synopsis	Human readable (hopefully) patch synopsis.

The os field also sometimes bundles the architecture in, so you will see things like an OS of '8_x86' for Solaris 8 on x86, versus just '8' for Solaris 8 SPARC.

The archs and pkgs fields contains subvalues; each subvalue ends with a ';', even if it is the last (or the only) subvalue in the field. (This helpfully mucks up pretty much any language's 'split' function; you get to split and then throw away the last element.)

Any prerequisite patches are encoded in the archs field, as id-rev values. Incompatible patches are slapped into the pkgs field in the same format.

If a patch has been obsoleted by something, its synopsis says so. There are a number of slightly varied formats that this information can be in.

The subvalues in the pkgs field (apart from incompatible patches) are in the format 'PKG:REV', with REV in the same form that 'pkginfo -x' produces it (more or less, it looks like).

The subvalues in the archs field (apart from prerequisite patches) may be an architecture name ('sparc' or 'i386'), 'all', or '<arch>.<model>' such as 'sparc.sun4u'. Pca's matching code accepts a patch if any of the subvalues match, and you'll frequently see 'redundant' archs values like 'sparc;sparc.sun4u;'.