STATUS updates
Some links of interest:
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:
#!/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
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.
I took another stab at eliminating the PHP errors being experienced. I may have achieved success.
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§ok=a569363ced996ec2e453fe9922b75482 HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock: ", host: "lab46.corning-cc.edu", referrer: "http://lab46.corning-cc.edu/"
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).
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.
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';
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.
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.
I also updated the wiki to the latest release.
The great data backup of the semester has commenced. VM dumps and user home directories were backed up onto an external drive.
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.