<html><center></html>STATUS updates<html></center></html>
Some links of interest:
SNOW DAY!
SNOW DAY!
I felt inspired, and started on a new script to automate many of my class processes. The script is called, simply: gn (you know what that stands for).
So far it can list/count class rosters, and perform some journal checking basics.
The one new feature that has been implemented is a journal reminder notification send to users via e-mail, if their weekly journal entry is not sufficient.
The script utilizes bash functions, along with some nifty logic tricks.
I finished my wildebeest herd migration to squeeze (wildebai and wildgoat were the only two remaining). So at this point, all wildebeest VMs are Debian squeeze.
While debugging the script of a user on lab46, I discovered a potential problem when sending outbound-internet mail using the mail(1) tool.
It would retain the lab46.offbyone.lan in the FROM, which would be summarily rejected by the CCC mail server, and bounce an error back.
I ended up fixing the problem as follows…
On mail.offbyone.lan, in /etc/postfix/main.cf, I added:
smtp_generic_maps = hash:/etc/postfix/generic
Then, in /etc/postfix/generic, I put:
@lab46.offbyone.lan @lab46.corning-cc.edu
Like virtusertable, any changes to this file need to be converted to the hash:
mail:~# postmap /etc/postfix/generic
And of course, a good restart to postfix.
I set about configuring/deploying the lrrd client on koolaid, so as to have a good indication of network activity on that portion of the network.
I copied what appeared to be the existing config from caprisun (from Ian's directory) into mine on koolaid. I didn't see anything that appeared to require using his account (the client contacts the server).
I needed to install some additional software, some of the form of packages:
koolaid:~# pkg_add python-2.5.4p1 ... koolaid:~# pkg_add libstatgrab ...
I also had to install the pystatgrab python module, which was a separate download and install:
koolaid:~# wget ftp://ftp.uk.i-scream.org/pub/i-scream/pystatgrab/pystatgrab-0.5.tar.gz
In the resulting pystatgrab source directory, one installs it as follows:
koolaid:~/pystatgrab-0.5# ./setup.py install ...
After this, I could fire up the lrrdNode client as my user.
I hopped over to web/lrrd and logged in, and configured koolaid.student.lab … something was initially working, as it knew what partitions and network interfaces were available… so I set them up.
However, at this point (almost a day into it), stats don't seem to be sent. Not sure why that is as of yet.
Neat link on the anonymous pwning of HBGary:
I've been meaning to get my commitchk script deployed again to track repository commits and wiki edits for my Computer Organization class. I had to make some general updates (it was hardcoded for '2010'… now variable-ized) along with some previously unencountered logical errors (ie it would run into wiki edits from last spring and avoid my formatting logic.
Ultimately fixed with the following:
26 YEAR="`echo $SEMESTER | sed 's/[A-Za-z]*//g'`" ... 79 wget -q -O - "${WIKI_PAGE}${subpage}?do=revisions&first=${item}" \ 80 | egrep "(^${YEAR}|^[a-z][a-z0-9]*</span>)" \ 81 | sed "s/^\(`date +%Y`\)\/\([0-9][0-9]\)\/\([0-9][0-9]\) \([0-9][0-9]\):\( [0-9][0-9]\).*$/\1\2\3\4\5:/g" \ 82 | sed 'N;s/\n//; s/<\/span>//g' | grep -v '^[a-zA-Z]' \ 83 | grep -v 'wedge' >> /tmp/wikichk.tmp
Where ${YEAR} was originally 2010, and “| grep -v '^[a-zA-Z]'” was added to prune out those old entries that didn't match (which stuck out like a sore thumb at that point in the processing).
I think I'll look into sprucing up the output to make it more intuitive.
I had noticed that, upon creating some new accounts for one of the web classes, that one of those new accounts was being listed as a student needing a journal.
Taking a closer look, I realized that this particular user had the substring 'asm' in their username, which of course matches my 'asm' course designator.
Having experiencing this problem before, I knew it would be a simple matter of making a regex more exclusive.
The original line was:
jchk="`groups $user | egrep -o "$classgrp" | wc -l`"
and it was corrected as follows:
jchk="`groups $user | egrep -o "\<$classgrp\>" | wc -l`"
Some links:
I was successful in getting an extra-LAIR XDMCP connection going to the new gnu this morning.
It turns out that, despite the ongoing drama with regards to XDMCP server support in Ubuntu causing it difficult to discern accurate information about client access from Ubuntu, my problem was actually much simpler- one of routes (or lack thereof).
I had to add a route to capri and jb in order to get things working, and then only Xephyr appeared to want to cooperate (Xnest remains uncooperative).
Routes were as follows.
On capri:
caprisun:~# route add 10.80.81.177 10.10.10.1 add host 10.80.81.177: gateway 10.10.10.1 caprisun:~#
What this basically did, was on the offbyone.lan side of things, know to pass the traffic to jb (10.10.10.1, the backbone network address for jb from capri).
On jb:
juicebox:~# route add 10.80.81.177 10.80.1.30 # my IP when I VPN in, so basically route it through my VPN connection add host 10.80.81.177: gateway 10.80.1.30 juicebox:~#
I could now ping from gnu back to 10.80.81.177 (not sure why it wasn't just opting to use my tun interface address).
From my Ubuntu machine, I established the XDMCP connection as follows:
telstar:~$ Xephyr :1 -query 10.80.2.32 -screen 1280x1024
Albeit a bit slow, but operational.
Related links:
During my initial configuration of gnu, the various xserver-xorg-video packages snuck onto the system. Since these are absolutely unneeded in our current environment (gnu has no real video hardware), I went and removed them. I used the following script logic:
for pkg in `dpkg -l | grep 'xserver-xorg-video' | cut -c5-40`; do pkgs="$pkgs $pkg" done aptitude purge $pkgs
It was brought to my attention earlier in the week that the media manager was not rendering correctly.
Not only was it rendering incorrectly- it was rendering in an unusable manner.
I sat down to take a look at the situation. I quickly ascertained it had something to do with my theme (I customized it, based on the default theme of the previous dokuwiki release). So I set about comparing and contrasting differences.
In the end, the major differences took place in the following three files within the lib/tpl/customname directory:
Everything else could be swapped out for the newer versions.
In footer.html, I merely disable the donation and rss feed buttons from appearing, so a swapout can take place with the appropriate tasks repeated.
In design.css, the main lab46 changes were minor (I upped the body font size to 100% from 80%). But in my wiki, I of course had made more significant changes, so I'm still running with my original design.css.
In main.php, this is where the actual problem resided. There were 3 areas of change:
As it turns out, the flush → tpl_flush was the culprit. Both wikis now have usable media managers once again.
I attempted another flake update, doing a fresh squeeze install on a drive. It looks like I'll need to give it some further attention- it doesn't seem to be loading the udlfb module, causing all the other magic to fail.
I probably just need to install more development tools to pull this off- I was trying to shortcut my way through it, which I probably can still do… but I'd like to at least verify success before optimizing the process further.
Pressly revived the old db, moving it to cobras to live on the lair.lan side of the network, and fixed the necessary database bits to allow successful communication with web to restore the legacy LAIR wiki.
I updated the apt-mirror configuration, doing the following:
In all, 46.8GB of new data will be downloaded. Celebrate accordingly.
With the help of my HPC Fundamentals class, we dismantled the remaining classroom pod table and re-assembled it for use as a 4 person multiseat setup, using my newly setup squeeze-based multiseat system.
All appears to be functioning as intended… and I like it to the point where I'm going to migrate the other pods to this same squeeze configuration (also freeing up the atom box for other purposes).
I've recreated the db.offbyone.lan VM, and intend to have it become the DB resource used by students (phasing out lab46db).
I installed phpMyAdmin and got that working, with some effort.
Some useful links:
The phpMyAdmin db was added via a script located in /usr/share/doc/phpmyadmin/examples … I had to (using the link above) create the phpmyadmin db user, and configure files accordingly.
Also had to reconfigure MySQL to listen on 0.0.0.0 instead of just on localhost.
My install script for lair-backup unintentionally creates an /etc/cron.d/backup.orig with executable permission, leading to a potential “dump race” (not sure if it actually happens or not). I updated the install script to basically run chmod to remove executable permissions on .orig files produced.
Removed repos from the backup config, moved www's timeslot up.
I also configured the backup cron job on lair-backup clients to run twice a month– once on the first saturday of the month, and second on the 3rd saturday of the month. (1-7,14-20).
The syslog-ng noise generated with the squeeze syslog-ng versions was corrected. This created an additional problem in that the lenny and likely etch versions of syslog-ng do not support the syslog-ng 3.x syntax. So I had to update the logic again to check for pre-squeeze distros and use the old version of the config.
I applied an aptitude update; aptitude upgrade to pretty much everything in the LAIR.
I forked my asnsubmit.sh script for use with my cprog class. We'll see if any changes are needed to either with the more flexible dates I've been making with due dates. The first indicator of any need to change the logic will take place… tomorrow :)
I was successful in getting the USB multiseat going on a more barebones debian squeeze system (no gnome, no gdm, just X and kick it into XDMCP).
It should be very possible to convert this into a netboot-style setup… I've begun looking up some things.
In the event of a resource outage (caused intentionally or unintentionally), lrrd will, every 5 minutes, fire off an e-mail, which I receive letting me know something is out of order.
This is all fine and dandy, except when the machine in question is somewhat outside my ability to access:
Something went *POOF* megaweapon.lair.lan probably not responding
So the alternative is to go into lrrd and disable it, which is done by logged into web and doing the following:
In the end, the entry should look like this:
[megaweapon.lair.lan] enable = false nics = ['eth0'] disks = ['/'] nlabel = [] addons = ['acpi', 'smart'] port = 5000 smart = ['hda']
No restarts necessary.
I discovered yesterday that the debian mirror on mirror.rit.edu appears to be out of sync (since sometime last week). After doing some forensics, it would appear it is a problem unique to rit's mirror, and therefore, the LAIR's mirror too. But, the latest package database is being updated, so it will happily complain (with error 500's in the logs) that the file does not exist.
Other mirrors (the main US debian mirror, binghamton's debian mirror) appear to be up to date… and switching sources to those mirrors works.
I contact the mirror admins notifying them of this problem. Just seems like a little shake is needed to restore regular operation, so I've made no changes to the LAIR configuration at this point.
Found an interesting forum thread talking about getting USB touchscreens with the eGalaxy chipset working in ubuntu: