TODO

update grade not-z scripts to handle/be aware of winter terms
update system page for (new)www
load balance/replicate www/wiki content between LAIR and DSLAB
update system page for db

URLs

Some links of interest:

Other Days

December 26th, 2014

old user removal

I set about removing old/stale users… ended up with a list of 80 candidates.

Each time I do this I effectively re-implement the functionality, although I was surprised to see a rather complete attempt done just last fall hiding out in an ~/ldap/ directory within $HOME.

I wrote a new script to assist in identifying candidates for deletion. I based it on the directory modify times (if any file changes, its parent directory will also change). That script, called userpruning, is as follows:

1

#!/bin/bash
#
# userpruning - a script to identify LAIR accounts that are over 2 years idle
#
 
# meant to be run on the fileserver
cd /export/home
now=$(date +%s)
 
# for each user
for user in `/bin/ls -1Ad [h-z]*`; do
        newflag="off"
 
        logage=$(cat /tmp/LAST | grep "\<${user}\>" | cut -c44-80)
        if [ "${logage}" = "**Never logged in**" ]; then
                oldness="${now}"
                NLI="{NLI}"
        else
                logage=$(date -d "`cat /tmp/LAST | grep \"\<${user}\>\" | cut -c44-80`" +%s)
                oldness=$((${now}-${logage}))
                NLI=
        fi
 
        if [ "${oldness}" -gt 63072000 ]; then
                # for each directory in that user's account
                for dir in `find ${user} -type d | tr ' ' '^' | grep -v 'Maildir' | grep -v '.pinerc'`; do
 
                        dirname=$(echo ${dir} | tr '^' ' ')
                        modate=$(stat "${dirname}" | grep '^Modify:' | cut -d' ' -f2)
                        age=$(date -d "${modate}" +%s)
                        oldness=$((${now}-${age}))
                        if [ "${oldness}" -lt 63072000 ]; then
                                echo -n "${NLI}[${user}] /home/${dirname} has "
                                stat ${dirname} | grep '^Modify:' | cut -d' ' -f2
                                echo -n "Omit? "
                                read answer
                                if [ "${answer}" = "n" ]; then
                                        newflag="on"
                                        break
                                fi
                        fi
                done
        else
                newflag="on"
        fi
 
        if [ "${newflag}" = "off" ]; then
                echo "${NLI}${user}:${oldness}"
                echo "${user}:${oldness}:${NLI}" >> /tmp/usercandidatesfordeletion
        fi
done

ldaptool

I also ran my ldaptool script, although once again I've missed the deadline of the semester, so I was (once again) unable to use the removal logic. But still, getting closer…

class LDAP groups have been emptied.

PHP errors

I took another stab at eliminating the PHP errors being experienced. I may have achieved success.

/var/www/lab46web/lib/plugins/ircpost/action.php

On line 46 of this particular file the web server would regularly report in the logs the following PHP warning:

2014/12/25 06:28:24 [error] 1376#0: *5627 FastCGI sent in stderr: "PHP message: PHP Warning:  Illegal string offset 'save' in /var/www/lab46web/lib/plugins/ircpost/action.php on line 46" while reading r     esponse header from upstream, client: 23.95.18.177, server: 10.80.2.18, request: "GET /start?do=login&sectok=a569363ced996ec2e453fe9922b75482 HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:     ", host: "lab46.corning-cc.edu", referrer: "http://lab46.corning-cc.edu/"

Original code

Here is what originally was present:

 44     function handle_act_preprocess(&$event, $param){
 45 
 46         if(strtolower($event->data['save']) != "save") return;
 47

Apparently due to a change in major versions/evolving functionality, this 2006-era PHP code would no longer work cleanly. It was suggested it was the transition to PHP 5.4 that caused behavioral changes, which could still be true, but I did not specifically test whether this issue was attributed to that (I do suspect it is a versioning thing… going from a squeeze-era PHP to jessie– 4 years of PHP development).

Fixed code

The fix was apparently the inclusion of isset() in my check:

 44     function handle_act_preprocess(&$event, $param){
 45 
 46         if(!isset($event->data['save'])) return;
 47         if(strtolower($event->data['save']) != "save") return;
 48

Useful URLs:

The last one I found most actionable. The first two were informative in providing a good explanation of the particular problem.

/var/www/lab46web/lib/plugins/statdisplay/helper/log.php

On line 53 of this file, another issue was being frequently reported.

2014/12/25 13:17:01 [error] 5058#0: *1 FastCGI sent in stderr: "PHP message: PHP Warning:  filesize(): stat failed for access.log in /var/www/lab46web/lib/plugins/statdisplay/helper/log.php on line 53" while reading response header from upstream, client: 10.80.1.1, server: 10.80.2.18, request: "GET /lib/exe/indexer.php?id=start&1419531421 HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "www", referrer: "http://www/"

Turns out the solution to this was far simpler; in /var/www/lab46web/lib/plugins/statdisplay/conf/default.php, the following line:

$conf['accesslog']  = 'access.log';

merely needed changing to this:

$conf['accesslog']  = '/var/log/nginx/access.log';

December 25th, 2014

www has 2 IPs

To better log connections coming in from RR, I set up www to have 2 network interfaces (one on each subnet), and set up a DNS/DHCP entry on juicebox.

www now answers to .18 on both the .1 and .2 subnets.

December 24th, 2014

wwwnew becomes www

I took advantage of some downtime and kicked www over to wwwold, and wwwnew replaced it as 'www'.

Everything seemed to work just fine, with the exception of repositories.

dokuwiki updated

I also updated the wiki to the latest release.

December 9th, 2014

LAIRbackup fall2014

The great data backup of the semester has commenced. VM dumps and user home directories were backed up onto an external drive.

sokraits reboot

After a semester of near-uninterrupted performance… sokraits suffered a reboot during an attempt to back up backed up home directories.

It turns out the sokraits-halfadder NIC may have gone bad, so the card was replaced.

An additional attempt at running with a 3.16 kernel was tried- no success. I may have to try running both peers at 3.16 to see if it makes any difference.

Previous Month		Current Month		Next Month

Lab46 Wiki

Table of Contents