STATUS updates
Some links of interest:
In the spring, I had per-user directories where I stored collected class metrics… I just got around to ensuring their recreation (so others things won't break so badly). Script follows:
sudo bash -ls cd /home/wedge/local/attendance/etc/list for user in `cat class.fall2010.* | grep '^[a-z]' | sort | uniq`; do mkdir /home/wedge/local/data/$user chown wedge:$user /home/wedge/local/data/$user chmod 770 /home/wedge/local/data/$user chmod +t /home/wedge/local/data/$user done
Manually pruned the existing carry over directories, removed the old no-longer-students directories.
Continuing my adventures getting the attendance scripts set back up, I've made the following progress:
lab46:~$ sudo ln -s ~wedge/local/attendance/etc /usr/local/etc/attendance lab46:~$ sudo ln -s /usr/local/etc/attendance/fall2010/attendance.conf /usr/local/etc/attendance/attendance.conf lab46:~$ sudo /usr/local/bin/attendance_gen_classes Generating compess unix data in /usr/local/etc/attendance/fall2010... Generating compess... Creating new class... Generating unix... Creating new class... Generating data... Creating new class... lab46:~$
First day of the Fall 2010 semester! My updates from last night seem to be stable. Everything appears to be running as it should.
One of my little side projects has been to try and get mail notification working once again on Lab46. Once one switches to Maildir, getting that to work isn't a direct and easy thing. However, I seem to have made some progress on this.
The following page seems to have some great information:
Basically, change /etc/login.defs, /etc/pam.d/login, /etc/pam.d/ssh, and /etc/profile, as follows:
#MAIL_DIR /var/mail QMAIL_DIR Maildir/ MAIL_FILE Maildir/
session optional pam_mail.so standard noenv dir=~/Maildir
# Print the status of the user's mailbox upon successful login. session optional pam_mail.so dir=~/Maildir standard #session optional pam_mail.so standard noenv # [1]
export MAIL=~/Maildir
This seems to be an area in somewhat of a flux… I have had it partially working, and especially since I am using squeeze, this may continue to break and partially work for some time until things solidify.
Not all may be needed… in fact, some of these changes may hamper successful operation. I just wanted to write it down so as to not repeat myself doing the same thing multiple times.
following the IP switch on juicebox, the VPN just hasn't been working.
I thought to check to see if the old IP was used in the config file, and sure enough it was!
So /etc/openvpn/lair-vpn-server.conf on juicebox was changed accordingly and restarted… VPN now back in action on juicebox!
I do this every semester, and end up doing a lot of rediscovery each semester as a result.. here is an attempt to document it…
To set up attendance…
In /usr/local/bin/attendance_gen_classes, change the previous semester to the current semester (there's like 3 occurrences of this)… this time around, I searched for “spring2010” and replaced it with “fall2010”… obviously some future enhancement to this script should involve implementing some semester detection logic. There also appears to be a copy of these scripts in the base of my attendance data directory… I performed the similar change there… at some point I'll have to investigate to see if these are still used (or if I had put them in /usr/local/bin/ and intended those to be the utilized ones).
In /usr/local/sbin/fortitude.sh, the very first line needs to be changed, as it contains the explicit semester:
cd /usr/local/etc/attendance/fall2010/processing
In my attendance data directories (attendance/etc/list/), the class files need to be created. These go by the following naming convention:
class.SEMESTER.CLASSDESIG.list.orig
So, for my fall2010 UNIX class, there'd be a file in this directory called:
class.fall2010.unix.list.orig
File contents are as follows:
Firstname1 Lastname1 username1 Firstname2 Lastname2 username2 Firstname3 Lastname3 username3 ... FirstnameN LastnameN usernameN
Make one for each class. Even if attendance checking isn't intended to be performed, my journal generation scripts utilize this data.
In this same directory is an “ldif” subdirectory… this contains various LDIF files with class group and host membership attributes (for example, to allow HPC students access to the LAIRstations, UNIX students to be added to the “unix” group, etc.).
I think I had scripts written for these…
Lower down in the attendance data tree (attendance/etc/), are the semester directories. I believe the one for the current semester needs to be manually created. I did this as follows:
cp -a spring2010 fall2010
Within that new directory, I did some pruning, specifically to the tune of:
rm -f *class*
As these are the attendance script-generated files, which do not contain any valid data that is pertinent to the current semester (so they can be safely deleted as they will be regenerated once the scripts run).
In the semester-tagged directory resides the file attendance.conf… this contains the important configuration data letting the scripts know when classes take place so proper attendance taking can take place.
Be sure to edit it and fill it out accordingly, also making sure to exclude any students who will not be counted for attendance. There is semester-specific data here, so be sure to change it as well.
While some of the attendance/journal/class processing bits reside on lab46, others reside on www.
On that resides on www is calcweek.sh in /usr/local/sbin. This is the script that calculates what week of the semester we are on. Clearly this is a script of some importance, so care must be taken to ensure it is configured properly.
Luckily, since extensive development work has already gone into it, only the semester-pertinent information needs to be updated, which is nicely broken out at the top of the script:
## ## Configuration - set dates to the MONDAY of the week in question ## start="20100823" break1="20101004" break2="20101122" duration="14" boffset="0" breakweek=0
bam! Ready to rock and roll with that one. Moving right along.
Another script that needs attention is /usr/local/sbin/journalinit.sh … this is the script that runs the inotify watching session to wait for users to create their journal page, then populates it accordingly. It has a temporal-sensitive variable up top that needs editing:
# Date that journal creation task is due LATE="201008292359"
In this case, for the fall semester, journals needs to be created by 11:59PM on August 29th (before it is Monday, August 30th). If I recall this worked rather well in the spring.
If I recall, execution of this script takes place on Tuesday mornings, but NOT the first week of the semester. Try to remember this when it comes to cron jobs.
This script is good to go for us, but it is worth pointing out it does have some data that over time may need updating– specifically, it is this variable:
classgrp="(unix|hpc|sys|data|asm|discrete|compess)"
As you can see, so long as I'm only teaching any of these classes, the script will find all the appropriate students and update the wiki page accordingly.. but if I ever teach a different course than any of these, and want to utilize the wiki in the same fashion, that class designator will need to be added to this list. It doesn't matter if I do not teach a given class a semester… it just pulls group members and uses them.
In this regard, I think it would then be very important to point out that LDAP groups REALLY NEED to be established, pruning out old memberships (ie prior semester student memberships)… if I'm lucky I wrote some scripts to help with this… some more poking around is in order.
That seems to wrap it up for www specific scripts.
I created the COMPESS mailing list, it is ready for action.
I also flushed all current mailing list memberships… so mailing lists are ready for the new semester.
I spent way too much time wrestling with something that should not have been a problem.. it turns out that grep is, on the surface, appearing not to be working… the regex in question is:
grep '^[a-z]'
against a file of full names on one line, usernames on the next… it returns EVERYTHING.
From what I can tell, there isn't a known bug, but there is a possibility of some LOCALE stuff (it doesn't recognize lowercase). What? Yeah. C-R-A-Z-Y.
So I ended up hacking it and doing a work around like this:
grep '^[^ ]*$'
sheesh. But it works… hopefully not too many other surprises.
The command: ldapmodify -x -W -f master.ldif -D “cn=admin,dc=lair,dc=lan”
The contents:
dn: cn=compess,ou=Group,dc=lair,dc=lan changetype: add objectClass: posixGroup gidNumber: 1737 cn: compess memberUid: wedge dn: cn=compess,ou=Group,dc=lair,dc=lan changetype: modify add: memberUid memberUid: user1 memberUid: user2
Two great bits of knowledge here… one, groups like 'compess' and 'data' didn't exist up to this point, so I had to add them… why not put it all in the same payload? This does that, and quite nicely.
Just find the next available gidNumber, make any assignments… voila! It freaking works.
To make this whole thing work, certain cron jobs need to be scheduled…
On www, we look in /etc/cron.d/dokuwiki, which is responsible for firing off all the wiki-related scripts. One temporal mention that needed changing (spring2010 → fall2010)… overall looking pretty good.
In preparation for the new semester, I applied updates to the following machines:
I ended up rebooting/booting the following:
And booted back up the wildebeest herd.
I ended up copying the lab46 images to sokraits locally, so as to lighten the load on NFS. So lab46 cannot be migrated between sokraits/halfadder… the other VMs technically can.
When playing with the formular plugin, I encountered an error I had in the past when previously attempting to play with it:
Undefined reference to utf_decode
or something like that.
After some poking around, I discovered two solutions:
For each page that uses a form, a php file is created. In the case of lab0:
/var/www/haas/data/formplugin/fall2010/unix/labs/form_lab0.php
is created. If one edits that file, on or about line 8, you'll see the reference to utf8_decode(). Simply remove it, just passing the $text or whatever variable (so there'll be no attempt to decode it).
In /var/www/inc/utf8.php, on or around line 132, you'll find what calls upon the utf8_decode() function. The solution once again is to remove the call to it, just as we did with the previous solution.
if(!function_exists('utf8_strlen')){ /** * Unicode aware replacement for strlen() * * utf8_decode() converts characters that are not in ISO-8859-1 * to '?', which, for the purpose of counting, is alright - It's * even faster than mb_strlen. * * @author <chernyshevsky at hotmail dot com> * @see strlen() * @see utf8_decode() */ function utf8_strlen($string){ // return strlen(utf8_decode($string)); return strlen($string); } }
This in theory should be a much wider and effective fix, but note that it opens up the potential for problems if we actually have utf8 data that would need to be decoded, won't be.
Performed a package update, installed NFS server to serve maildir directories read-only to lab46 to (hopefully) enable new mail notification.
copied over class public directories from the old lab46. Going to NFS mount the maildir directories read-only from mail to hopefully provide new mail notification to users.
Created a ~/Maildir for each user, which is a symlink that points to their corresponding /var/mail/$USER directory. There seems to be success.
<html><center></html>
<html></center></html>