sf-lug:hayes_valley_community_center_computer_lab
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
sf-lug:hayes_valley_community_center_computer_lab [2007-11-14T21:24:12+0000] – jturner | sf-lug:hayes_valley_community_center_computer_lab [2010-02-22T10:26:03+0000] (current) – corrected image links to proper wiki self-referential links michael_paoli | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Hayes Valley Community Center Project Report ====== | ====== Hayes Valley Community Center Project Report ====== | ||
- | |||
- | |||
Line 10: | Line 8: | ||
//As one might guess, this is the section for the latest and greatest summary report.// | //As one might guess, this is the section for the latest and greatest summary report.// | ||
+ | // | ||
- | //**2007-11-02**// TomH figured out that DansGuardian was preventing download of some fonts and and flash files. | + | //**2008-04-16**// Much hilarity, best described by an email sent to the SF-LUG list: |
- | * at least 24 ports worth of hub/ | + | |
- | * ability to remotely power cycle said network equipment(either through remote login cmd execution or ethernet enabled plug, preferably the former) | + | |
- | * ?? | + | |
- | // | + | A few days ago, myself and Jim Stockford started getting alerts from the |
+ | Nagios instance setup on the sf-lug box telling us that there was a | ||
+ | problem with the server at the Hayes Valley project we (and other people | ||
+ | on this list) have been volunteering at. Fair enough. I was planning to | ||
+ | stop by there on Tuesday in any case, so figured I'd check it out then. | ||
- | Todos: | + | When I arrived, it turns out that the place had been re-painted and |
- | * Configure support number (via GrandCentral) | + | during that process all the computers had been moved around, cables |
- | * Calendar software; something for HVLC admins and community, | + | unplugged, reconnected, |
- | * Setup scanner software | + | all of the workstations in the public area of the community |
- | * Setup color laserprinter | + | more importantly, |
+ | server is configured as the network gateway, providing DNS, DHCP, as | ||
+ | well as " | ||
+ | proxying setup. So basically the fact that this server was down meant | ||
+ | that the entire network was down, so it became my first priority. | ||
+ | First of all I sorted out the cabling mess, and then booted the server. | ||
+ | The boot process didn't complete and I was dropped into a recovery | ||
+ | environment with limited commands available to me. I was able to see all | ||
+ | the drives on the server, mount and inspect each one, and verify that | ||
+ | everything seemed okay. Except that obviously everything wasn't okay. | ||
+ | The recovery console had been preceeded by a message about the mdadm | ||
+ | devices not being correctly configured (software raid). | ||
+ | |||
+ | To make an extremely long story not quite so long, we were able to get | ||
+ | the server back up and running by booting into an older kernel (manually | ||
+ | applied updates had installed a new kernel in the 120+ days since the | ||
+ | server was last rebooted, and we thought it might be worth trying the | ||
+ | older kernel, which sure enough it was). | ||
+ | |||
+ | So at this stage we had a server booting fine. Almost. We realised that | ||
+ | we would want to change the default kernel to be the older one so that | ||
+ | you would be able to perform an unattended reboot. At the moment, the | ||
+ | default kernel was the newer one that was having problems recognising | ||
+ | the software RAID devices, and so couldn' | ||
+ | it would just be a simple matter of editing / | ||
+ | problem is, /boot was empty. How so? We happened to know that /boot | ||
+ | should be /dev/sda1, so we mounted that to the /boot folder, and then | ||
+ | edited the menu.lst file as above to use the correct kernel. We then | ||
+ | edited /etc/fstab, which sure enough had the entry for /dev/sda1 to be | ||
+ | mounted as /boot commented out. Simple case of uncommenting the entry | ||
+ | and rebooting, surely? | ||
+ | |||
+ | Except when we reboot, it fails, saying there' | ||
+ | (don't remember the exact error message) with /dev/sda1. All other | ||
+ | filesystems are mounted, but not /boot. It recommended something like | ||
+ | running fsck against /dev/sda1, but checking for a different superblock. | ||
+ | Unfortunately I don't remember the exact error. | ||
+ | |||
+ | So the questions here are: | ||
+ | • How did the system boot from a device that it failed to mount (we know | ||
+ | it was booting from /dev/sda1 because the changes we'd made | ||
+ | to / | ||
+ | rebooting were applied)? | ||
+ | • How can we mount a partition if it's failing to be mounted as part of | ||
+ | the boot sequence? | ||
+ | • What checks can we do on the filesystem to confirm it's all good? | ||
+ | |||
+ | // | ||
+ | |||
+ | // | ||
+ | |||
+ | // | ||
+ | |||
+ | Jim Stockford suggested clarification for network equipment need. So far we have: | ||
+ | * at least 24 ports worth of hub/ | ||
+ | * ability to remotely power cycle said network equipment(either through remote login cmd execution or ethernet enabled plug, preferably the former) | ||
+ | * ?? | ||
Line 127: | Line 183: | ||
* Gloria ?, SFHA Hayes Valley | * Gloria ?, SFHA Hayes Valley | ||
* DSL Contacts: SBC DSL Support 877-722-3755, | * DSL Contacts: SBC DSL Support 877-722-3755, | ||
+ | ===== Technical Details ===== | ||
+ | === Server Status === | ||
- | + | There is a script in / | |
- | + | ||
- | + | ||
- | ===== Technical Details ===== | + | |
=== Done: === | === Done: === | ||
Line 166: | Line 220: | ||
* Set hard disk as primary boot device, and put a BIOS setup password on the computers (same password as for administrative user) so that someone has to know that password to be able to boot from a different device. | * Set hard disk as primary boot device, and put a BIOS setup password on the computers (same password as for administrative user) so that someone has to know that password to be able to boot from a different device. | ||
* Tested performance of booting from the server (LTSP) - normal applications work fine, but video was a little choppy and no sound (could possibly be overcome, but didn't have time to investigate further). | * Tested performance of booting from the server (LTSP) - normal applications work fine, but video was a little choppy and no sound (could possibly be overcome, but didn't have time to investigate further). | ||
+ | |||
+ | * Got scanner working following the advice of [[https:// | ||
== Time Spent == | == Time Spent == | ||
Line 174: | Line 230: | ||
* Saturday August 11th: 4 x 2.5 hours | * Saturday August 11th: 4 x 2.5 hours | ||
* Sunday September 30th: 3 x 4 hours | * Sunday September 30th: 3 x 4 hours | ||
+ | * Thursday Jan 15th 2009: 2 x 1 hour | ||
=== To Do: === | === To Do: === | ||
Line 209: | Line 266: | ||
* Network layout | * Network layout | ||
* On 2007-09-14 Tom Haddon went to the management company and took the following pictures of their network area, which we believe overlaps with the network setup at HVLC (their building is immediately behind HVLC): | * On 2007-09-14 Tom Haddon went to the management company and took the following pictures of their network area, which we believe overlaps with the network setup at HVLC (their building is immediately behind HVLC): | ||
- | | + | |
- | | + | |
- | | + | |
- | | + | |
* Where/what is that plan for sustainable operation of the lab? | * Where/what is that plan for sustainable operation of the lab? | ||
Line 231: | Line 288: | ||
* [[http:// | * [[http:// | ||
+ | |||
+ | * {{sf-lug: | ||
+ | |||
+ | * {{sf-lug: | ||
Line 238: | Line 299: | ||
^ Date ^ Time ^ Volunteer(s) | ^ Date ^ Time ^ Volunteer(s) | ||
- | | Thursday, 11/ | ||
- | | Thursday, 11/ | ||
- | | Thursday, 11/ | ||
- | | Thursday, 11/ | ||
- | | Thursday, 11/ | ||
- |
sf-lug/hayes_valley_community_center_computer_lab.1195075452.txt.bz2 · Last modified: 2007-11-14T21:24:12+0000 by jturner