Worklog

[Upgrades] RAHU Groups home

Configured the other half of the first Xserve RAID as a space for groups and classes directories.

fc-raid-00-2 is set up similarly to rc-raid-00-1, but it’s got “groups” and “classes” top level directories, and the /home/groups/foo will be a symlink into the fc-raid-00-2/groups/foo. We’ll be moving over all the groups directories over the course of the fall, target completion by the end of the semester so that we can retire PAX.

[Firefighting] Storm control

Another storm passed through last night. Not much this time, other than a power flicker.

But that took out the servers outside of the machine room.

• The Spectra tape library doesn’t seem to poweron automatically after a power failure. Also seems I don’t recall the access codes for the front panel.

• Changed a couple of Solaris boxes to use UFS logging with the hopes that they’ll be a little more graceful about power flicker resets.

[Firefighting] Machine room A/C

Went out Saturday around 5. The paging network has been flakey, so I didn’t get in until midnight. No immediate damage, but I’m expecting a few disks to die in the next while.

[Firefighting] Index note in LDAP log file

From the Sun blueprint book: to determine whether a search in the LDAP directory server was not answered by an index, look for notes=U in the RESULT section. Then look for the corresponding SRCH and find out what it was searching on; create an index for that.

[Installations] LDAP index notes

A few notes about rebuilding LDAP indices on Sun ONE.

• The proper command is /usr/sbin/directoryserver -s instance db2index-task -D managerDN -w - -n userRoot -v Don’t use the db2index.pl script, since you have to be in the right directory for it to find the shared libs and all.

• Progress of the index can be found in the instance’s error log, the most logical place for it.

• I don’t know whether the database can be in read-only mode. Best to try it without, so set nsslapd-readonly to off in cn=userRoot,cn=ldbm database,cn=plugins,cn=config (see this entry).

• It really does take a little while.

[Research] Calendar groups

There’s a slight drawback in Sun ONE calendar: you can’t define calendar groups that people can, in whatever way, subscribe to. However, I have found that managing one’s individual groups is as simple as setting an LDAP attribute.

It would be really nice if we could create a group of calendars and just tell people to add that group. Changes to the group could then easily propagate into people’s view of it. Like, say, a group with all the employees in Department A, and as people come and go in the department somebody modifies that group.

No such luck.

However, it’s relatively straightforward, through some LDAP manipulation, to add and modify groups on someone’s individual account. It needs to be done for all users who have that group, but it can be done by the administrator. The group stuff is set in an attribute called icsSet, one for each group. The syntax is:

icsSet: name=Group Name$calendar=username1;username2;username3:subcalendar$tzmode=specify$tz=$mergeInDayView=true$description=

It’s just a set of fields separated by $:

• name: the name of the group. May contain spaces.

• calendar: a list of calendars, separated by semicolons. The calendars are referenced by the standard Sun ONE scheme.

• tzmode: timezone information. Set to specify.

• tz: the timezone. May be left empty or set to a particular named timezone.

• mergeInDayView: unknown. Set to true.

• description: theoretically a description could go here, but the groups created by the web interface don’t have this set and when it is set it doesn’t show up in the web interface. Leave it empty.