From mitch at ucc.asn.au Thu Apr 1 09:40:27 2010 From: mitch at ucc.asn.au (Mitch Kelly) Date: Thu, 1 Apr 2010 09:40:27 +0800 Subject: [tech] SNAP in the UCC clubroom In-Reply-To: References: Message-ID: <005501cad13c$4e5c5f80$eb151e80$@asn.au> Perhaps we should put in minutes to get a Rocket M5 and put 2 antennas on it, This would extend the range easily to the oak lawn. They also run openWRT Mitch -----Original Message----- From: tech-bounces at ucc.gu.uwa.edu.au [mailto:tech-bounces at ucc.gu.uwa.edu.au] On Behalf Of David Adam Sent: Wednesday, 31 March 2010 9:36 AM To: tech at ucc.gu.uwa.edu.au Subject: Re: [tech] SNAP in the UCC clubroom On Tue, 30 Mar 2010, David Adam wrote: > I reconfigured clearwing (the WRT-54GL wireless AP running OpenWRT) this > evening so that members can get at least some internet in the UCC clubroom > while repairs from the storm are taking place and we argue over how to fix > things. > > It's now set up to repeat VLAN 13 on all of the "LAN" ports (tagged on all and by VLAN 13 I mean VLAN 11. David From danielax at gmail.com Thu Apr 1 13:19:44 2010 From: danielax at gmail.com (Daniel J. Axtens) Date: Thu, 1 Apr 2010 13:19:44 +0800 Subject: [tech] SNAP in the UCC clubroom In-Reply-To: <005501cad13c$4e5c5f80$eb151e80$@asn.au> References: <005501cad13c$4e5c5f80$eb151e80$@asn.au> Message-ID: Why would we want UCC wireless to extend to Oak Lawn? (Especially given that we're going to lock it down shortly.) I thought the clubroom wireless was just there to serve the clubroom? [DJA] On 1 April 2010 09:40, Mitch Kelly wrote: > Perhaps we should put in minutes to get a Rocket M5 and put 2 antennas on > it, This would extend the range easily to the oak lawn. > > They also run openWRT > > Mitch > > -----Original Message----- > From: tech-bounces at ucc.gu.uwa.edu.au [mailto:tech-bounces at ucc.gu.uwa.edu.au] > On Behalf Of David Adam > Sent: Wednesday, 31 March 2010 9:36 AM > To: tech at ucc.gu.uwa.edu.au > Subject: Re: [tech] SNAP in the UCC clubroom > > On Tue, 30 Mar 2010, David Adam wrote: > >> I reconfigured clearwing (the WRT-54GL wireless AP running OpenWRT) this >> evening so that members can get at least some internet in the UCC clubroom > >> while repairs from the storm are taking place and we argue over how to fix > >> things. >> >> It's now set up to repeat VLAN 13 on all of the "LAN" ports (tagged on all > > > and by VLAN 13 I mean VLAN 11. > > David > > From zanchey at ucc.gu.uwa.edu.au Thu Apr 1 13:28:40 2010 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Thu, 1 Apr 2010 13:28:40 +0800 (WST) Subject: [tech] SNAP in the UCC clubroom In-Reply-To: References: <005501cad13c$4e5c5f80$eb151e80$@asn.au> Message-ID: Extending the range to Oak Lawn and running OpenWRT are not really things I am super excited about. But I believe it is a 802.11n/a capable device - I think that would put us curiously ahead of the curve for once. [DAA] On Thu, 1 Apr 2010, Daniel J. Axtens wrote: > Why would we want UCC wireless to extend to Oak Lawn? (Especially > given that we're going to lock it down shortly.) I thought the > clubroom wireless was just there to serve the clubroom? > > On 1 April 2010 09:40, Mitch Kelly wrote: > > Perhaps we should put in minutes to get a Rocket M5 and put 2 antennas on > > it, This would extend the range easily to the oak lawn. > > > > They also run openWRT > > > > Mitch > > > > -----Original Message----- > > From: tech-bounces at ucc.gu.uwa.edu.au [mailto:tech-bounces at ucc.gu.uwa.edu.au] > > On Behalf Of David Adam > > Sent: Wednesday, 31 March 2010 9:36 AM > > To: tech at ucc.gu.uwa.edu.au > > Subject: Re: [tech] SNAP in the UCC clubroom > > > > On Tue, 30 Mar 2010, David Adam wrote: > > > >> I reconfigured clearwing (the WRT-54GL wireless AP running OpenWRT) this > >> evening so that members can get at least some internet in the UCC clubroom > > > >> while repairs from the storm are taking place and we argue over how to fix > > > >> things. > >> > >> It's now set up to repeat VLAN 13 on all of the "LAN" ports (tagged on all > > > > > > and by VLAN 13 I mean VLAN 11. > > > > David > > > > > Cheers, David Adam zanchey at ucc.gu.uwa.edu.au Ask Me About Our SLA! From danielax at gmail.com Thu Apr 1 13:55:05 2010 From: danielax at gmail.com (Daniel J. Axtens) Date: Thu, 1 Apr 2010 13:55:05 +0800 Subject: [tech] Clubroom Machines Message-ID: Hi all, I've set up ucc/ucc login and SNAP on combtail (Win 7) and cephalopod (Win XP). Obviously they don't mount home directories or do anything else particularly useful yet, but they are OK for causal web browsing. (such as writing this email) This brings to 3 the number of machines that can be used with SNAP. That was the good news, and this is the bad news: - Cephalopod's motherboard battery seems to have died - its dates and times are all out. - The three machines are all plugged into clearwing. This is obviously not a fantastic solution, nor is it scalable, but it should be useful until Stuff Gets Fixed. Happy Easter to those of you who observe it; to everyone else, enjoy the holiday! [DJA] From bob at ucc.gu.uwa.edu.au Wed Apr 7 19:45:47 2010 From: bob at ucc.gu.uwa.edu.au (Bob Adamson) Date: Wed, 7 Apr 2010 19:45:47 +0800 (WST) Subject: [tech] UCC Status Update 7/3 Message-ID: Hi All, A number of things have happened over the last few days, here they are in no particular order: -We now have a new air-con in the machine room. It's a 5.3KW Kelvinator in-window unit. It is very heavy. It is very large. It is very cool. And it is white. It shall be called Antarctica. Thanks to Chris Squire and Matt Didcoe for helping with the installation and transport, especially Chris who sacrificed his ute to the cause. -Martello and Mooneye are back at UCC. We had some problems with networking, loose power connectors, and busted fans on martello - but everything is working now! Thanks Matt Didcoe, James French, James Andrewartha, and Matt Johnston. -The clubroom is slowly being pieced back together. The biggest part of this is scrubbing the old glue off the floorboards. One person who I would like everyone to thank is Sam "Matches" Moore. He has come in time after time and been on his hands and knees for hours scrubbing the floor. This is f***ing hard work, and I take my hat off to him. We aim to have the clubroom *finished* on Friday, but we need help. The clubroom will be open a fair bit over the next two days, if you're free, please come and help. -Now that Martello and Mooneye are back, we have a clubroom network again, and wireless should work (or will follow very soon). Most other remote services are back up. -Things that are not up: dispense/snack/door, webcams, co-lo boxes, and printers. This is not an exhaustive list. Bob Adamson UCC Treasurer |"Bureaucracy is a challenge to the be conquered with a righteous | |attitude, an intolerance for stupidity, and a bulldozer when necessary" | | ---Peter's Laws | From zanchey at ucc.gu.uwa.edu.au Wed Apr 7 21:28:49 2010 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Wed, 7 Apr 2010 21:28:49 +0800 (WST) Subject: [tech] UCC Status Update 7/3 In-Reply-To: References: Message-ID: On Wed, 7 Apr 2010, Bob Adamson wrote: > A number of things have happened over the last few days, here they are in no > particular order: > > -Now that Martello and Mooneye are back, we have a clubroom network again, and > wireless should work (or will follow very soon). Most other remote services > are back up. Wireless should be working. I made VLANs and multi-SSID stuff work on the wireless AP, so it now rebroadcasts both UniComputerClub and SNAP. The next step will be to install hostapd and get UniComputerClub secured and authing against RADIUS; I don't know if hostapd and the Broadcom multiple SSID stuff works together, although I see no reason why not. I think the wireless AP software will need upgrading as well - it's still running OpenWRT 7.09 from 2007, for which packages are no longer available. 10.03 has just been released with some useful-looking changes, including a 2.6 kernel for our hardware which actually supports the wireless. I might have a play with this before the LAN. David Adam zanchey at ucc.gu.uwa.edu.au P.S. Big, big thanks to everyone who's busted their guts to get things at UCC fixed. I wish I could have helped more. From bob at ucc.gu.uwa.edu.au Thu Apr 8 20:44:52 2010 From: bob at ucc.gu.uwa.edu.au (Bob Adamson) Date: Thu, 8 Apr 2010 20:44:52 +0800 (WST) Subject: [tech] UCC Update 8/3 Message-ID: Hi All, Todays Events: -every single machine in the machine room is now powered on, with networking. The cable work is also a lot neater than ever before, and we have a couple of new cable runs above and behind the racks. -mermaid has been transplanted into the old proxybox, we have taken a full backup of it just in case. -door and dispense are now working again, no more keys and manual dispensing :-) -robotnik is back, and online - yay music! So we're looking pretty good for the lan on Saturday, all that remains to do is clear the clubroom floor and desks. Bob Adamson UCC Treasurer |"Bureaucracy is a challenge to the be conquered with a righteous | |attitude, an intolerance for stupidity, and a bulldozer when necessary" | | ---Peter's Laws | From danielax at gmail.com Thu Apr 8 20:46:39 2010 From: danielax at gmail.com (Daniel J. Axtens) Date: Thu, 8 Apr 2010 20:46:39 +0800 Subject: [tech] UCC Update 8/3 In-Reply-To: References: Message-ID: > -mermaid has been transplanted into the old proxybox, we have taken a full backup of it just in case. On this note, something I forgot to mention earlier is that I took a full backup of madako just after it was installed into the delta. Congratulations all on an impressive effort. [DJA] From zanchey at ucc.gu.uwa.edu.au Sun Apr 11 13:03:27 2010 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Sun, 11 Apr 2010 13:03:27 +0800 (WST) Subject: [tech] Secure wireless Message-ID: Because 4am is the best time to be doing sysadmin stuff, I managed to get the wireless AP providing a WPA2-Enterprise SSID authenticating using UCC usernames and passwords. Connect to 'UCCsec' and you should get prompted for a username and password, possibly a certificate prompt, and then dumped onto the normal wireless VLAN. Most of the technical details of the RADIUS setup are in http://wiki.ucc.asn.au/LDAP/LazySysadmin#FreeRADIUS - the AP configuration is fairly simplistic too. WPA2-Enterprise uses PEAPv0/MS-CHAPv2, which is complex way of saying 'there's an SSL-based tunnel wrapping the password exchange'. That tunnel is currently set up to use the secure.ucc.asn.au certificates, although switching back to the UCC CA self-signed certificates is straightforward. I'm curious how much effect the actual certficate has on the user experience. The iPhone asks you to confirm the certificate regardless of whether it is signed by a trusted CA or not, but I didn't have a chance to test any other devices. If people with Mac OS and Windows laptops could try it out and let me know how they go I would appreciate it - in particular, whether there is a prompt to accept the certificate and if it provides any useful information in working out whether to trust the connection. David Adam UCC Wheel Member zanchey@ From zanchey at ucc.gu.uwa.edu.au Mon Apr 12 18:44:19 2010 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Mon, 12 Apr 2010 18:44:19 +0800 (WST) Subject: [tech] Secure wireless In-Reply-To: References: Message-ID: On Sun, 11 Apr 2010, David Adam wrote: > WPA2-Enterprise uses PEAPv0/MS-CHAPv2, which is complex way of saying > 'there's an SSL-based tunnel wrapping the password exchange'. That tunnel > is currently set up to use the secure.ucc.asn.au certificates, although > switching back to the UCC CA self-signed certificates is straightforward. > > I'm curious how much effect the actual certficate has on the user > experience. The iPhone asks you to confirm the certificate regardless of > whether it is signed by a trusted CA or not, but I didn't have a chance to > test any other devices. If people with Mac OS and Windows laptops could > try it out and let me know how they go I would appreciate it - in > particular, whether there is a prompt to accept the certificate and if it > provides any useful information in working out whether to trust the > connection. [MRD] suggested that the certificate confirmation prompt might be from the hostname of the RADIUS server (currently mussel) not matching the name on the cert (secure.ucc). I'm not sure about this; my understanding of the WPA2 protocol doesn't extend to how the client knows what authentication server is being used. Next time I'm in the clubroom, hopefully with a more useful device than the iPhone, I might try changing that around. In any case, apparently[1] a stock SSL certificate will not work on Windows XP without a specific extension. If someone with a Windows wireless client could test it out and let me know I would appreciate it, although I'll try and bring my laptop in. David Adam [1]: http://www.smallnetbuilder.com/wireless/wireless-howto/30213-how-to-setting-up-freeradius-for-wpa-a-wpa2-enterprise-part-2?start=1 From blinken at gmail.com Mon Apr 12 23:43:37 2010 From: blinken at gmail.com (Patrick Coleman) Date: Mon, 12 Apr 2010 23:43:37 +0800 Subject: [tech] Secure wireless In-Reply-To: References: Message-ID: On Mon, Apr 12, 2010 at 6:44 PM, David Adam wrote: > > [MRD] suggested that the certificate confirmation prompt might be from the > hostname of the RADIUS server (currently mussel) not matching the name on > the cert (secure.ucc). I'm not sure about this; my understanding of the > WPA2 protocol doesn't extend to how the client knows what authentication > server is being used. Next time I'm in the clubroom, hopefully with a more > useful device than the iPhone, I might try changing that around. >From my (limited) knowledge, the TLS tunnel is established back to the RADIUS server, so it's likely. Freeradius is pretty verbose in debug mode, perhaps it'll tell you? (PEAP/MS-CHAPv2 is MS-CHAPv2 inside EAP inside TLS inside EAP inside RADIUS, proving that when one standard isn't secure enough you should add another four layers). > In any case, apparently[1] a stock SSL certificate will not work on > Windows XP without a specific extension. If someone with a Windows > wireless client could test it out and let me know I would appreciate it, > although I'll try and bring my laptop in. Whoever does this, make sure you're running SP3 or I promise you will actually go insane. -Patrick -- http://www.labyrinthdata.net.au - WA Backup, Web and VPS Hosting From mattman at ucc.gu.uwa.edu.au Tue Apr 13 13:46:46 2010 From: mattman at ucc.gu.uwa.edu.au (Matt Didcoe) Date: Tue, 13 Apr 2010 13:46:46 +0800 Subject: [tech] Secure wireless In-Reply-To: References: Message-ID: Frames and TPG had a play on a Windows XP laptop earlier (version unknown) and it seems to suggest that it cannot find a certificate. Think we'll need to get a new CSR generated for mussel.ucc.gu.uwa.edu.auwith the XP Extensions (outlined here -> http://www.linuxjournal.com/article/8095?page=0,1) [ xpclient_ext ] extendedKeyUsage = 1.3.6.1.5.5.7.3.2 [ xpserver_ext ] extendedKeyUsage = 1.3.6.1.5.5.7.3.1 Going to drop a line to Gareth at ITS and see if they know much about this given the work that's been going on with Eduroam (though I think AARNet may have handled more of the setup there). Matt -- Matt Didcoe [MRD] President / Wheel member University Computer Club mattdidcoe at ucc.gu.uwa.edu.au On Mon, Apr 12, 2010 at 11:43 PM, Patrick Coleman wrote: > On Mon, Apr 12, 2010 at 6:44 PM, David Adam > wrote: > > > > [MRD] suggested that the certificate confirmation prompt might be from > the > > hostname of the RADIUS server (currently mussel) not matching the name on > > the cert (secure.ucc). I'm not sure about this; my understanding of the > > WPA2 protocol doesn't extend to how the client knows what authentication > > server is being used. Next time I'm in the clubroom, hopefully with a > more > > useful device than the iPhone, I might try changing that around. > > >From my (limited) knowledge, the TLS tunnel is established back to the > RADIUS server, so it's likely. Freeradius is pretty verbose in debug > mode, perhaps it'll tell you? (PEAP/MS-CHAPv2 is MS-CHAPv2 inside EAP > inside TLS inside EAP inside RADIUS, proving that when one standard > isn't secure enough you should add another four layers). > > > In any case, apparently[1] a stock SSL certificate will not work on > > Windows XP without a specific extension. If someone with a Windows > > wireless client could test it out and let me know I would appreciate it, > > although I'll try and bring my laptop in. > > Whoever does this, make sure you're running SP3 or I promise you will > actually go insane. > > -Patrick > > -- > http://www.labyrinthdata.net.au - WA Backup, Web and VPS Hosting > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20100413/16f90356/attachment.htm From mattman at ucc.gu.uwa.edu.au Tue Apr 13 14:04:34 2010 From: mattman at ucc.gu.uwa.edu.au (Matt Didcoe) Date: Tue, 13 Apr 2010 14:04:34 +0800 Subject: [tech] Secure wireless In-Reply-To: References: Message-ID: Yeah, Gareth's immediate response was "hand them an Ubuntu disk". He did suggest using a W2 supplicant called "Secure W2", but there's actually not a free version of that. The only other solution, if you're running AD is to use a weak version of 1x which isn't such a good idea. Apparently it's caused a number of headaches for Eduroam and other places have just bought site licences for Secure W2 :( - MRD On Tue, Apr 13, 2010 at 1:46 PM, Matt Didcoe wrote: > Frames and TPG had a play on a Windows XP laptop earlier (version unknown) > and it seems to suggest that it cannot find a certificate. > > Think we'll need to get a new CSR generated for mussel.ucc.gu.uwa.edu.auwith the XP Extensions (outlined here -> > http://www.linuxjournal.com/article/8095?page=0,1) > > [ xpclient_ext ] > extendedKeyUsage = 1.3.6.1.5.5.7.3.2 > > [ xpserver_ext ] > extendedKeyUsage = 1.3.6.1.5.5.7.3.1 > > Going to drop a line to Gareth at ITS and see if they know much about this > given the work that's been going on with Eduroam (though I think AARNet may > have handled more of the setup there). > > Matt > > -- > Matt Didcoe [MRD] > President / Wheel member > University Computer Club > mattdidcoe at ucc.gu.uwa.edu.au > > > > On Mon, Apr 12, 2010 at 11:43 PM, Patrick Coleman wrote: > >> On Mon, Apr 12, 2010 at 6:44 PM, David Adam >> wrote: >> > >> > [MRD] suggested that the certificate confirmation prompt might be from >> the >> > hostname of the RADIUS server (currently mussel) not matching the name >> on >> > the cert (secure.ucc). I'm not sure about this; my understanding of the >> > WPA2 protocol doesn't extend to how the client knows what authentication >> > server is being used. Next time I'm in the clubroom, hopefully with a >> more >> > useful device than the iPhone, I might try changing that around. >> >> >From my (limited) knowledge, the TLS tunnel is established back to the >> RADIUS server, so it's likely. Freeradius is pretty verbose in debug >> mode, perhaps it'll tell you? (PEAP/MS-CHAPv2 is MS-CHAPv2 inside EAP >> inside TLS inside EAP inside RADIUS, proving that when one standard >> isn't secure enough you should add another four layers). >> >> > In any case, apparently[1] a stock SSL certificate will not work on >> > Windows XP without a specific extension. If someone with a Windows >> > wireless client could test it out and let me know I would appreciate it, >> > although I'll try and bring my laptop in. >> >> Whoever does this, make sure you're running SP3 or I promise you will >> actually go insane. >> >> -Patrick >> >> -- >> http://www.labyrinthdata.net.au - WA Backup, Web and VPS Hosting >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20100413/ec18759c/attachment.htm From blinken at gmail.com Tue Apr 13 17:55:38 2010 From: blinken at gmail.com (Patrick Coleman) Date: Tue, 13 Apr 2010 17:55:38 +0800 Subject: [tech] Secure wireless In-Reply-To: References: Message-ID: On Tue, Apr 13, 2010 at 2:04 PM, Matt Didcoe wrote: > Yeah, Gareth's immediate response was "hand them an Ubuntu disk". XP definitely works great with MS-CHAPv2/PEAP on AD machines, and I am 90% sure I've also setup non-AD machines (successfully) on that network here. We're using a self-signed certificate, and we just import the CA using a little batch script on a network share. Having configured a few XP machines, my experience is that it's more likely to work reliably/at all if you're running SP3. I can meet people at UCC to debug/steal working config, if you like. I'll try and find a non-AD-bound machine here in the meantime to test with. -Patrick From zanchey at ucc.gu.uwa.edu.au Tue Apr 13 22:10:56 2010 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Tue, 13 Apr 2010 22:10:56 +0800 (WST) Subject: [tech] Secure wireless In-Reply-To: References: Message-ID: On Mon, 12 Apr 2010, Patrick Coleman wrote: > On Mon, Apr 12, 2010 at 6:44 PM, David Adam wrote: > > [MRD] suggested that the certificate confirmation prompt might be from the > > hostname of the RADIUS server (currently mussel) not matching the name on > > the cert (secure.ucc). I'm not sure about this; my understanding of the > > WPA2 protocol doesn't extend to how the client knows what authentication > > server is being used. Next time I'm in the clubroom, hopefully with a more > > useful device than the iPhone, I might try changing that around. > > From my (limited) knowledge, the TLS tunnel is established back to the > RADIUS server, so it's likely. Freeradius is pretty verbose in debug > mode, perhaps it'll tell you? (PEAP/MS-CHAPv2 is MS-CHAPv2 inside EAP > inside TLS inside EAP inside RADIUS, proving that when one standard > isn't secure enough you should add another four layers). I think you mean PEAPv0/MS-CHAPv2 :-P http://support.microsoft.com/kb/814394 suggests that "the Subject line of the server certificate [must] match the name that is configured on the client for the connection", which I assume means the SSID, and "the Subject Alternative Name (SubjectAltName) extension [must] contain the server's SQDN". I still haven't worked out how the client could possibly verify the FQDN as the EAP-over-LAN (EAPOL) connection isn't IP-based. Anyway, I will poke it a bit when I have some time. > > In any case, apparently[1] a stock SSL certificate will not work on > > Windows XP without a specific extension. If someone with a Windows > > wireless client could test it out and let me know I would appreciate it, > > although I'll try and bring my laptop in. > > Whoever does this, make sure you're running SP3 or I promise you will > actually go insane. Useful advice, but any more details? [DAA] From bob at ucc.gu.uwa.edu.au Mon Apr 19 21:07:33 2010 From: bob at ucc.gu.uwa.edu.au (Bob Adamson) Date: Mon, 19 Apr 2010 21:07:33 +0800 (WST) Subject: [tech] Half Height Rack Message-ID: Hi, [MRD] has organised for us to acquire a half-height, full depth rack from the ?Motorola? building. This will allow us to rack mount some of the newer servers such as maaxen. To put this in, we need to lose one of the racks in the machine room. This is your invitation to argue about it. My personal opinion is that we should remove the right hand (full height) rack, and put the new one in its place. This would allow us to use the window above it for a second in-window aircon, instead of buying an overly expensive dual hose portable. Also, just for the record, we use less than half of the available rack space in the old full height rack, and there are no machines in the middle rack that are actually used. Bob Adamson UCC Treasurer |"Bureaucracy is a challenge to the be conquered with a righteous | |attitude, an intolerance for stupidity, and a bulldozer when necessary" | | ---Peter's Laws | From jacques at chester.id.au Mon Apr 19 21:10:40 2010 From: jacques at chester.id.au (Jacques Chester) Date: Mon, 19 Apr 2010 21:10:40 +0800 Subject: [tech] troppo Message-ID: Hello all; It's high time we did some sort of official handover of troppo. Club Troppo has been bedded down at its new home and the fallback position is no longer required. What I have in mind is to pop in on a weekend and wipe the HDD for a fresh install. Also, if anyone has a good name to suggest, we could rebadge it. I think some sort of tropical fish would do. Failing that, I figured 'jellyfish' would be useful, as I expect it will be repurposed as a VM server. Cheers, JC. From zanchey at ucc.gu.uwa.edu.au Tue Apr 20 08:57:49 2010 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Tue, 20 Apr 2010 08:57:49 +0800 (WST) Subject: [tech] Half Height Rack In-Reply-To: References: Message-ID: On Mon, 19 Apr 2010, Bob Adamson wrote: > [MRD] has organised for us to acquire a half-height, full depth rack from the > ?Motorola? building. This will allow us to rack mount some of the newer > servers such as maaxen. To put this in, we need to lose one of the racks in > the machine room. This is your invitation to argue about it. I'm not sure what you mean by "full-depth". Are the other racks in the server room not full depth? I know we adjusted the rails on the one closest to the door so that it would fit the ex-FSI servers properly, but the other rack should still have the normal depth. > My personal opinion is that we should remove the right hand (full height) > rack, and put the new one in its place. This would allow us to use the window > above it for a second in-window aircon, instead of buying an overly expensive > dual hose portable. Also, just for the record, we use less than half of the > available rack space in the old full height rack, and there are no machines in > the middle rack that are actually used. That sounds like a good idea. Alternatively we could move the terminals onto the bench and put the half-height rack next to the window if we wanted to keep both full-height racks - but, as you say, we already have lots of unused space. [DAA] From trs80 at ucc.gu.uwa.edu.au Tue Apr 20 10:45:02 2010 From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha) Date: Tue, 20 Apr 2010 10:45:02 +0800 (WST) Subject: [tech] Half Height Rack In-Reply-To: References: Message-ID: On Tue, 20 Apr 2010, David Adam wrote: > On Mon, 19 Apr 2010, Bob Adamson wrote: > > [MRD] has organised for us to acquire a half-height, full depth rack from the > > ?Motorola? building. This will allow us to rack mount some of the newer > > servers such as maaxen. To put this in, we need to lose one of the racks in > > the machine room. This is your invitation to argue about it. > > I'm not sure what you mean by "full-depth". Are the other racks in the > server room not full depth? I know we adjusted the rails on the one > closest to the door so that it would fit the ex-FSI servers properly, but > the other rack should still have the normal depth. The working definition is "long enough to properly mount the Sun v20z servers in". > > My personal opinion is that we should remove the right hand (full height) > > rack, and put the new one in its place. This would allow us to use the window > > above it for a second in-window aircon, instead of buying an overly expensive > > dual hose portable. Also, just for the record, we use less than half of the > > available rack space in the old full height rack, and there are no machines in > > the middle rack that are actually used. > > That sounds like a good idea. Alternatively we could move the terminals > onto the bench and put the half-height rack next to the window if we > wanted to keep both full-height racks - but, as you say, we already have > lots of unused space. The right-hand rack has to be the network rack thanks to the length (or lack thereof) of the network cabling to the patch panels. They're currently well-positioned at eye-level, if they were lower you'd be bending down all the time to patch cables. Further, if the rack has a door and sides visibility will be impaired. If the issue is being able to mount a second aircon, then why not just leave a section of the rack empty for the airflow to go through? -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / From matt at didcoe.id.au Tue Apr 20 10:57:04 2010 From: matt at didcoe.id.au (Matt Didcoe) Date: Tue, 20 Apr 2010 10:57:04 +0800 Subject: [tech] Half Height Rack In-Reply-To: References: Message-ID: I'm still unsure about the need for a second unit tbqh - the unit we have now is keeping everything cool with no troubles whatsoever. The rack Mark has available doesn't have sides or doors. As others have pointed out, we could just move the posts on the LH rack, that presents a problem for the Fugro's, but I'd question the need to have those after we get troppo running as a VM server. -Matt On Tue, Apr 20, 2010 at 10:45 AM, James Andrewartha wrote: > On Tue, 20 Apr 2010, David Adam wrote: > >> On Mon, 19 Apr 2010, Bob Adamson wrote: >> > [MRD] has organised for us to acquire a half-height, full depth rack from the >> > ?Motorola? building. This will allow us to rack mount some of the newer >> > servers such as maaxen. To put this in, we need to lose one of the racks in >> > the machine room. This is your invitation to argue about it. >> >> I'm not sure what you mean by "full-depth". Are the other racks in the >> server room not full depth? I know we adjusted the rails on the one >> closest to the door so that it would fit the ex-FSI servers properly, but >> the other rack should still have the normal depth. > > The working definition is "long enough to properly mount the Sun v20z > servers in". > >> > My personal opinion is that we should remove the right hand (full height) >> > rack, and put the new one in its place. This would allow us to use the window >> > above it for a second in-window aircon, instead of buying an overly expensive >> > dual hose portable. Also, just for the record, we use less than half of the >> > available rack space in the old full height rack, and there are no machines in >> > the middle rack that are actually used. >> >> That sounds like a good idea. Alternatively we could move the terminals >> onto the bench and put the half-height rack next to the window if we >> wanted to keep both full-height racks - but, as you say, we already have >> lots of unused space. > > The right-hand rack has to be the network rack thanks to the length (or > lack thereof) of the network cabling to the patch panels. They're > currently well-positioned at eye-level, if they were lower you'd be > bending down all the time to patch cables. Further, if the rack has a door > and sides visibility will be impaired. > > If the issue is being able to mount a second aircon, then why not just > leave a section of the rack empty for the airflow to go through? > > -- > # TRS-80 ? ? ? ? ? ? ?trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ > # UCC Wheel Member ? ? http://trs80.ucc.asn.au/ #| ?what squirrels do best ? ? | > [ "There's nobody getting rich writing ? ? ? ? ?]| ?-- Collect and hide your ? | > [ ?software that I know of" -- Bill Gates, 1980 ]\ ?nuts." -- Acid Reflux #231 / > From mitch at ucc.asn.au Tue Apr 20 11:26:52 2010 From: mitch at ucc.asn.au (Mitch Kelly) Date: Tue, 20 Apr 2010 11:26:52 +0800 Subject: [tech] Half Height Rack In-Reply-To: References: Message-ID: <002401cae039$5361b370$fa251a50$@asn.au> I agree, If it doesn?t have sides then I wouldn?t bother with it. Its no better than the current rack -----Original Message----- From: tech-bounces at ucc.gu.uwa.edu.au [mailto:tech-bounces at ucc.gu.uwa.edu.au] On Behalf Of Matt Didcoe Sent: Tuesday, 20 April 2010 10:57 AM To: James Andrewartha Cc: tech at ucc.asn.au Subject: Re: [tech] Half Height Rack I'm still unsure about the need for a second unit tbqh - the unit we have now is keeping everything cool with no troubles whatsoever. The rack Mark has available doesn't have sides or doors. As others have pointed out, we could just move the posts on the LH rack, that presents a problem for the Fugro's, but I'd question the need to have those after we get troppo running as a VM server. -Matt On Tue, Apr 20, 2010 at 10:45 AM, James Andrewartha wrote: > On Tue, 20 Apr 2010, David Adam wrote: > >> On Mon, 19 Apr 2010, Bob Adamson wrote: >> > [MRD] has organised for us to acquire a half-height, full depth rack from the >> > ?Motorola? building. This will allow us to rack mount some of the newer >> > servers such as maaxen. To put this in, we need to lose one of the racks in >> > the machine room. This is your invitation to argue about it. >> >> I'm not sure what you mean by "full-depth". Are the other racks in the >> server room not full depth? I know we adjusted the rails on the one >> closest to the door so that it would fit the ex-FSI servers properly, but >> the other rack should still have the normal depth. > > The working definition is "long enough to properly mount the Sun v20z > servers in". > >> > My personal opinion is that we should remove the right hand (full height) >> > rack, and put the new one in its place. This would allow us to use the window >> > above it for a second in-window aircon, instead of buying an overly expensive >> > dual hose portable. Also, just for the record, we use less than half of the >> > available rack space in the old full height rack, and there are no machines in >> > the middle rack that are actually used. >> >> That sounds like a good idea. Alternatively we could move the terminals >> onto the bench and put the half-height rack next to the window if we >> wanted to keep both full-height racks - but, as you say, we already have >> lots of unused space. > > The right-hand rack has to be the network rack thanks to the length (or > lack thereof) of the network cabling to the patch panels. They're > currently well-positioned at eye-level, if they were lower you'd be > bending down all the time to patch cables. Further, if the rack has a door > and sides visibility will be impaired. > > If the issue is being able to mount a second aircon, then why not just > leave a section of the rack empty for the airflow to go through? > > -- > # TRS-80 ? ? ? ? ? ? ?trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ > # UCC Wheel Member ? ? http://trs80.ucc.asn.au/ #| ?what squirrels do best ? ? | > [ "There's nobody getting rich writing ? ? ? ? ?]| ?-- Collect and hide your ? | > [ ?software that I know of" -- Bill Gates, 1980 ]\ ?nuts." -- Acid Reflux #231 / > No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.801 / Virus Database: 271.1.1/2819 - Release Date: 04/20/10 02:31:00 From bob at ucc.gu.uwa.edu.au Tue Apr 20 13:16:58 2010 From: bob at ucc.gu.uwa.edu.au (Bob Adamson) Date: Tue, 20 Apr 2010 13:16:58 +0800 (WST) Subject: [tech] Half Height Rack In-Reply-To: <002401cae039$5361b370$fa251a50$@asn.au> References: <002401cae039$5361b370$fa251a50$@asn.au> Message-ID: To Summarise: -The rack Mark has available doesn't have sides or doors. trs80: If the rack has a door and sides visibility will be impaired. Agreed, and this is no different to our current situation -As others have pointed out, we could just move the posts on the LH rack, that presents a problem for the Fugro's. Not just the Fugros, we would have to move the posts to their extremes, which would mean no longer supporting some of the heavier machines, such as Maraena, at the back. I don't think this is really an option. -I'm not sure what you mean by "full-depth". Are the other racks in the server room not full depth? I know we adjusted the rails on the one closest to the door so that it would fit the ex-FSI servers properly, but the other rack should still have the normal depth. trs80: The working definition is "long enough to properly mount the Sun v20z servers in". Have you noticed that not a single machine in the right hand rack is screwed in at the back? That's because you can't. The posts aren't adjustable to a depth that is useful for _any_ of our servers. Why we have kept this rack for so long is beyond me. -The right-hand rack has to be the network rack thanks to the length (or lack thereof) of the network cabling to the patch panels. They're currently well-positioned at eye-level. This is the clincher, and if height is _absolutely_ necessary it closes our options somewhat. One other argument I have in favour of this new rack is that it will allow us to use rails, which would be nice. So from what I can tell, we now have three options: 1. Replace the middle rack, and have no second aircon 2. Replace the right rack, have a second aircon, but patch panel at waist level 3. Try and find a full height rack to suit our needs (which could take a very long time) Bob Adamson UCC Treasurer |"Bureaucracy is a challenge to the be conquered with a righteous | |attitude, an intolerance for stupidity, and a bulldozer when necessary" | | ---Peter's Laws | From mitch at ucc.asn.au Tue Apr 20 13:24:08 2010 From: mitch at ucc.asn.au (Mitch Kelly) Date: Tue, 20 Apr 2010 13:24:08 +0800 Subject: [tech] Half Height Rack In-Reply-To: References: <002401cae039$5361b370$fa251a50$@asn.au> Message-ID: <002801cae049$b53f9d40$1fbed7c0$@asn.au> -I'm not sure what you mean by "full-depth". Are the other racks in the server room not full depth? I know we adjusted the rails on the one closest to the door so that it would fit the ex-FSI servers properly, but the other rack should still have the normal depth. trs80: The working definition is "long enough to properly mount the Sun v20z servers in". Full depth is 1200mm deep (Back to front) And yes Deep/Long enough to PROPERLY mount the servers on the rails they are supplied with, While keeping 10cm at the back for ventilation. Mitch -----Original Message----- From: tech-bounces at ucc.gu.uwa.edu.au [mailto:tech-bounces at ucc.gu.uwa.edu.au] On Behalf Of Bob Adamson Sent: Tuesday, 20 April 2010 1:17 PM To: tech at ucc.gu.uwa.edu.au Subject: Re: [tech] Half Height Rack To Summarise: -The rack Mark has available doesn't have sides or doors. trs80: If the rack has a door and sides visibility will be impaired. Agreed, and this is no different to our current situation -As others have pointed out, we could just move the posts on the LH rack, that presents a problem for the Fugro's. Not just the Fugros, we would have to move the posts to their extremes, which would mean no longer supporting some of the heavier machines, such as Maraena, at the back. I don't think this is really an option. -I'm not sure what you mean by "full-depth". Are the other racks in the server room not full depth? I know we adjusted the rails on the one closest to the door so that it would fit the ex-FSI servers properly, but the other rack should still have the normal depth. trs80: The working definition is "long enough to properly mount the Sun v20z servers in". Have you noticed that not a single machine in the right hand rack is screwed in at the back? That's because you can't. The posts aren't adjustable to a depth that is useful for _any_ of our servers. Why we have kept this rack for so long is beyond me. -The right-hand rack has to be the network rack thanks to the length (or lack thereof) of the network cabling to the patch panels. They're currently well-positioned at eye-level. This is the clincher, and if height is _absolutely_ necessary it closes our options somewhat. One other argument I have in favour of this new rack is that it will allow us to use rails, which would be nice. So from what I can tell, we now have three options: 1. Replace the middle rack, and have no second aircon 2. Replace the right rack, have a second aircon, but patch panel at waist level 3. Try and find a full height rack to suit our needs (which could take a very long time) Bob Adamson UCC Treasurer |"Bureaucracy is a challenge to the be conquered with a righteous | |attitude, an intolerance for stupidity, and a bulldozer when necessary" | | ---Peter's Laws | No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.801 / Virus Database: 271.1.1/2819 - Release Date: 04/20/10 02:31:00 From bob at ucc.gu.uwa.edu.au Wed Apr 21 20:16:08 2010 From: bob at ucc.gu.uwa.edu.au (Bob Adamson) Date: Wed, 21 Apr 2010 20:16:08 +0800 (WST) Subject: [tech] Half Height Rack In-Reply-To: <002801cae049$b53f9d40$1fbed7c0$@asn.au> References: <002401cae039$5361b370$fa251a50$@asn.au> <002801cae049$b53f9d40$1fbed7c0$@asn.au> Message-ID: It looks like the placement of the rack has been decided by geometry - we have to put it next to the left hand rack, otherwise we wont be able to slide out servers with rails (we would hit a bench leg). The rack is currently sitting in the middle of the clubroom with one set of v20z rails on it. We (Frenchie and I) had to move the back posts all the way back due to the posts having an S shaped cross-section and sun rails being retarded. I think it actually makes things easier to mount too, but we'll have to see what happens with the non-railed servers. How does some time this weekend sound for putting it in? Bob Adamson UCC Treasurer |"Bureaucracy is a challenge to the be conquered with a righteous | |attitude, an intolerance for stupidity, and a bulldozer when necessary" | | ---Peter's Laws | On Tue, 20 Apr 2010, Mitch Kelly wrote: > -I'm not sure what you mean by "full-depth". Are the other racks in the > server room not full depth? I know we adjusted the rails on the one > closest to the door so that it would fit the ex-FSI servers properly, but > the other rack should still have the normal depth. > trs80: The working definition is "long enough to properly mount the Sun > v20z servers in". > > > Full depth is 1200mm deep (Back to front) > > And yes Deep/Long enough to PROPERLY mount the servers on the rails they are > supplied with, While keeping 10cm at the back for ventilation. > > Mitch > > -----Original Message----- > From: tech-bounces at ucc.gu.uwa.edu.au [mailto:tech-bounces at ucc.gu.uwa.edu.au] > On Behalf Of Bob Adamson > Sent: Tuesday, 20 April 2010 1:17 PM > To: tech at ucc.gu.uwa.edu.au > Subject: Re: [tech] Half Height Rack > > To Summarise: > > -The rack Mark has available doesn't have sides or doors. > trs80: If the rack has a door and sides visibility will be impaired. > > Agreed, and this is no different to our current situation > > -As others have pointed out, we could just move the posts on the LH rack, > that presents a problem for the Fugro's. > > Not just the Fugros, we would have to move the posts to their extremes, > which would mean no longer supporting some of the heavier machines, such > as Maraena, at the back. I don't think this is really an option. > > -I'm not sure what you mean by "full-depth". Are the other racks in the > server room not full depth? I know we adjusted the rails on the one > closest to the door so that it would fit the ex-FSI servers properly, but > the other rack should still have the normal depth. > trs80: The working definition is "long enough to properly mount the Sun > v20z servers in". > > Have you noticed that not a single machine in the right hand rack is > screwed in at the back? That's because you can't. The posts aren't > adjustable to a depth that is useful for _any_ of our servers. Why we have > kept this rack for so long is beyond me. > > -The right-hand rack has to be the network rack thanks to the length (or > lack thereof) of the network cabling to the patch panels. They're > currently well-positioned at eye-level. > > This is the clincher, and if height is _absolutely_ necessary it closes > our options somewhat. > > One other argument I have in favour of this new rack is that it will allow > us to use rails, which would be nice. > > So from what I can tell, we now have three options: > 1. Replace the middle rack, and have no second aircon > 2. Replace the right rack, have a second aircon, but patch panel at waist > level > 3. Try and find a full height rack to suit our needs (which could take a > very long time) > > Bob Adamson > UCC Treasurer > > |"Bureaucracy is a challenge to the be conquered with a righteous | > |attitude, an intolerance for stupidity, and a bulldozer when necessary" | > | ---Peter's Laws | > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.801 / Virus Database: 271.1.1/2819 - Release Date: 04/20/10 > 02:31:00 > From mattman at ucc.gu.uwa.edu.au Wed Apr 21 20:38:48 2010 From: mattman at ucc.gu.uwa.edu.au (Matt Didcoe) Date: Wed, 21 Apr 2010 20:38:48 +0800 Subject: [tech] Half Height Rack In-Reply-To: References: <002401cae039$5361b370$fa251a50$@asn.au> <002801cae049$b53f9d40$1fbed7c0$@asn.au> Message-ID: Thanks to Bob, Rufus, Frenchie and Tearles for getting this dealt with - much appreciated. I'll be bringing in the rails for the PE2650 that's on the bench so that can be racked up and put to use. Might check with Jacques as well as to whether troppo has/had rails. - Matt [MRD] -- Matt Didcoe President - University Computer Club On Wed, Apr 21, 2010 at 8:16 PM, Bob Adamson wrote: > It looks like the placement of the rack has been decided by geometry - we > have to put it next to the left hand rack, otherwise we wont be able to > slide out servers with rails (we would hit a bench leg). The rack is > currently sitting in the middle of the clubroom with one set of v20z rails > on it. We (Frenchie and I) had to move the back posts all the way back due > to the posts having an S shaped cross-section and sun rails being retarded. > I think it actually makes things easier to mount too, but we'll have to see > what happens with the non-railed servers. > > How does some time this weekend sound for putting it in? > > > Bob Adamson > UCC Treasurer > > |"Bureaucracy is a challenge to the be conquered with a righteous | > |attitude, an intolerance for stupidity, and a bulldozer when necessary" | > | ---Peter's Laws | > > > On Tue, 20 Apr 2010, Mitch Kelly wrote: > > -I'm not sure what you mean by "full-depth". Are the other racks in the >> server room not full depth? I know we adjusted the rails on the one >> closest to the door so that it would fit the ex-FSI servers properly, but >> the other rack should still have the normal depth. >> trs80: The working definition is "long enough to properly mount the Sun >> v20z servers in". >> >> >> Full depth is 1200mm deep (Back to front) >> >> And yes Deep/Long enough to PROPERLY mount the servers on the rails they >> are >> supplied with, While keeping 10cm at the back for ventilation. >> >> Mitch >> >> -----Original Message----- >> From: tech-bounces at ucc.gu.uwa.edu.au [mailto: >> tech-bounces at ucc.gu.uwa.edu.au] >> On Behalf Of Bob Adamson >> Sent: Tuesday, 20 April 2010 1:17 PM >> To: tech at ucc.gu.uwa.edu.au >> Subject: Re: [tech] Half Height Rack >> >> To Summarise: >> >> -The rack Mark has available doesn't have sides or doors. >> trs80: If the rack has a door and sides visibility will be impaired. >> >> Agreed, and this is no different to our current situation >> >> -As others have pointed out, we could just move the posts on the LH rack, >> that presents a problem for the Fugro's. >> >> Not just the Fugros, we would have to move the posts to their extremes, >> which would mean no longer supporting some of the heavier machines, such >> as Maraena, at the back. I don't think this is really an option. >> >> -I'm not sure what you mean by "full-depth". Are the other racks in the >> server room not full depth? I know we adjusted the rails on the one >> closest to the door so that it would fit the ex-FSI servers properly, but >> the other rack should still have the normal depth. >> trs80: The working definition is "long enough to properly mount the Sun >> v20z servers in". >> >> Have you noticed that not a single machine in the right hand rack is >> screwed in at the back? That's because you can't. The posts aren't >> adjustable to a depth that is useful for _any_ of our servers. Why we have >> kept this rack for so long is beyond me. >> >> -The right-hand rack has to be the network rack thanks to the length (or >> lack thereof) of the network cabling to the patch panels. They're >> currently well-positioned at eye-level. >> >> This is the clincher, and if height is _absolutely_ necessary it closes >> our options somewhat. >> >> One other argument I have in favour of this new rack is that it will allow >> us to use rails, which would be nice. >> >> So from what I can tell, we now have three options: >> 1. Replace the middle rack, and have no second aircon >> 2. Replace the right rack, have a second aircon, but patch panel at waist >> level >> 3. Try and find a full height rack to suit our needs (which could take a >> very long time) >> >> Bob Adamson >> UCC Treasurer >> >> |"Bureaucracy is a challenge to the be conquered with a righteous | >> |attitude, an intolerance for stupidity, and a bulldozer when necessary" | >> | ---Peter's Laws | >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.801 / Virus Database: 271.1.1/2819 - Release Date: 04/20/10 >> 02:31:00 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20100421/1243b505/attachment.htm From mattman at ucc.asn.au Thu Apr 22 17:01:13 2010 From: mattman at ucc.asn.au (Matt Didcoe) Date: Thu, 22 Apr 2010 17:01:13 +0800 Subject: [tech] New switches Message-ID: Hi everyone, Thanks to some awesome dealing by Frenchie, we now have two (well one, other one is on its way) new Cisco 2948G-GE-TX switches. They will be called Coconut and Palm. The first (Coconut) has been configured as a near exact replica of Lorenzo (I think) -it still needs a bit of work, but I hope to have it in production tomorrow afternoon. When Palm comes down from Arts some time in the next couple of weeks, the plan is to drop that in the left hand rack. We now return you to your regularly scheduled program and quiz night announcements. Cheers, Matt [MRD] From trs80 at ucc.gu.uwa.edu.au Fri Apr 23 20:02:30 2010 From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha) Date: Fri, 23 Apr 2010 20:02:30 +0800 (WST) Subject: [tech] maraena downtime Message-ID: Hi all, The downtime was caused by shutdown -h now at the wrong prompt, abetted by maraena's lack of molly-guard. The aim was to reboot mylah so it'd come up with the tape library's SCSI controller thanks to Xen PCI passthrough. This is so we could run amanda on mylah instead of maranea. Unfortunately it hasn't really worked - firstly, the aic7xxx module is loaded in maraena before the pciback module and so grabs it despite adding 'pciback.permissive pciback.hide=(00:06.0)' to the kernel command line. Secondly, after manually detaching the PCI device with sysfs[1] and starting mylah, it never properly attaches, just looping forever with the following. Trying rmmod aic7xxx doesn't work, it just hangs. [ 908.400062] Timer Expired [ 908.400085] Recovery code awake [ 908.400095] aic7xxx_abort returns 0x2003 [ 908.400118] scsi 0:0:15:0: Attempting to queue a TARGET RESET message [ 908.400129] CDB: 0x12 0x0 0x0 0x0 0x24 0x0 [ 908.400176] aic7xxx_dev_reset returns 0x2003 [ 908.400242] Recovery SCB completes [ 928.404085] scsi 0:0:15:0: Attempting to queue an ABORT message [ 928.404109] CDB: 0x0 0x0 0x0 0x0 0x0 0x0 [ 928.404161] scsi0: At time of recovery, card was not paused [ 928.404177] >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< [ 928.404179] scsi0: Dumping Card State in Command phase, at SEQADDR 0xa7 [ 928.404196] Card was paused [ 928.404208] ACCUM = 0x80, SINDEX = 0xa0, DINDEX = 0xe4, ARG_2 = 0x0 [ 928.404221] HCNT = 0x0 SCBPTR = 0x0 [ 928.404231] SCSISIGI[0x86]:(REQI|BSYI|CDI) ERROR[0x0] [ 928.404269] SCSIBUSL[0x80] LASTPHASE[0x80]:(CDI) [ 928.404300] SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) [ 928.404324] SBLKCTL[0xa]:(SELWIDE|SELBUSB) SCSIRATE[0x0] [ 928.404357] SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x0] [ 928.404387] SSTAT0[0x7]:(DMADONE|SPIORDY|SDONE) [ 928.404415] SSTAT1[0x3]:(REQINIT|PHASECHG) SSTAT2[0x0] [ 928.404448] SSTAT3[0x0] SIMODE0[0x8]:(ENSWRAP) [ 928.404477] SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) [ 928.404510] SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x4]:(DIRECTION) [ 928.404547] DFSTATUS[0x88]:(HDONE|PRELOAD_AVAIL) [ 928.404570] STACK: 0x35 0x0 0x177 0x35 [ 928.404601] SCB count = 4 [ 928.404610] Kernel NEXTQSCB = 3 [ 928.404619] Card NEXTQSCB = 0 [ 928.404627] QINFIFO entries: [ 928.404639] Waiting Queue entries: [ 928.404652] Disconnected Queue entries: [ 928.404665] QOUTFIFO entries: [ 928.404677] Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [ 928.404842] Sequencer SCB Info: [ 928.404850] 0 SCB_CONTROL[0x0] SCB_SCSIID[0x0] SCB_LUN[0x0] [ 928.404891] SCB_TAG[0x0] [ 928.404901] 1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.404946] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.404974] 2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405019] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405048] 3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405164] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405199] 4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405248] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405279] 5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405326] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405357] 6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405404] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405435] 7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405482] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405513] 8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405561] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405592] 9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405638] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405668] 10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405712] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405740] 11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405784] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405813] 12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405857] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405886] 13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.405930] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.405958] 14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.406002] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.406031] 15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.406075] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.406104] 16 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.406147] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.406176] 17 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.406220] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.406249] 18 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.406293] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.406322] 19 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.406366] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.406394] 20 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.406439] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.406468] 21 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.406513] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.406542] 22 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.406586] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.406615] 23 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.408028] 24 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.408028] 25 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.408028] 26 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.408028] 27 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.408028] 28 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.408028] 29 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.408028] 30 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.408028] 31 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] [ 928.408028] Pending list: [ 928.408028] 2 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xf7]:(TWIN_CHNLB|TWIN_TID) [ 928.408028] SCB_LUN[0x0] [ 928.408028] Kernel Free SCB list: 1 0 [ 928.408028] Untagged Q(15): 2 [ 928.408028] [ 928.408028] <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> [ 928.408028] (scsi0:A:15:0): Device is disconnected, re-queuing SCB [ 928.408028] Recovery code sleeping [1] http://lists.xensource.com/archives/html/xen-devel/2010-03/msg00448.html -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / From adrian at ucc.gu.uwa.edu.au Fri Apr 23 20:49:06 2010 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Fri, 23 Apr 2010 20:49:06 +0800 Subject: [tech] maraena downtime In-Reply-To: References: Message-ID: <20100423124906.GS8564@ucc.gu.uwa.edu.au> Is there an ioapic on that box? is it working? If not, is the aic driver xen-aware? Adrian On Fri, Apr 23, 2010, James Andrewartha wrote: > Hi all, > > The downtime was caused by shutdown -h now at the wrong prompt, abetted by > maraena's lack of molly-guard. The aim was to reboot mylah so it'd come up > with the tape library's SCSI controller thanks to Xen PCI passthrough. > This is so we could run amanda on mylah instead of maranea. > > Unfortunately it hasn't really worked - firstly, the aic7xxx module is > loaded in maraena before the pciback module and so grabs it despite adding > 'pciback.permissive pciback.hide=(00:06.0)' to the kernel command line. > Secondly, after manually detaching the PCI device with sysfs[1] and > starting mylah, it never properly attaches, just looping forever with the > following. Trying rmmod aic7xxx doesn't work, it just hangs. > > [ 908.400062] Timer Expired > [ 908.400085] Recovery code awake > [ 908.400095] aic7xxx_abort returns 0x2003 > [ 908.400118] scsi 0:0:15:0: Attempting to queue a TARGET RESET message > [ 908.400129] CDB: 0x12 0x0 0x0 0x0 0x24 0x0 > [ 908.400176] aic7xxx_dev_reset returns 0x2003 > [ 908.400242] Recovery SCB completes > [ 928.404085] scsi 0:0:15:0: Attempting to queue an ABORT message > [ 928.404109] CDB: 0x0 0x0 0x0 0x0 0x0 0x0 > [ 928.404161] scsi0: At time of recovery, card was not paused > [ 928.404177] >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< > [ 928.404179] scsi0: Dumping Card State in Command phase, at SEQADDR 0xa7 > [ 928.404196] Card was paused > [ 928.404208] ACCUM = 0x80, SINDEX = 0xa0, DINDEX = 0xe4, ARG_2 = 0x0 > [ 928.404221] HCNT = 0x0 SCBPTR = 0x0 > [ 928.404231] SCSISIGI[0x86]:(REQI|BSYI|CDI) ERROR[0x0] > [ 928.404269] SCSIBUSL[0x80] LASTPHASE[0x80]:(CDI) > [ 928.404300] SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) > [ 928.404324] SBLKCTL[0xa]:(SELWIDE|SELBUSB) SCSIRATE[0x0] > [ 928.404357] SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x0] > [ 928.404387] SSTAT0[0x7]:(DMADONE|SPIORDY|SDONE) > [ 928.404415] SSTAT1[0x3]:(REQINIT|PHASECHG) SSTAT2[0x0] > [ 928.404448] SSTAT3[0x0] SIMODE0[0x8]:(ENSWRAP) > [ 928.404477] SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) > [ 928.404510] SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x4]:(DIRECTION) > [ 928.404547] DFSTATUS[0x88]:(HDONE|PRELOAD_AVAIL) > [ 928.404570] STACK: 0x35 0x0 0x177 0x35 > [ 928.404601] SCB count = 4 > [ 928.404610] Kernel NEXTQSCB = 3 > [ 928.404619] Card NEXTQSCB = 0 > [ 928.404627] QINFIFO entries: > [ 928.404639] Waiting Queue entries: > [ 928.404652] Disconnected Queue entries: > [ 928.404665] QOUTFIFO entries: > [ 928.404677] Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 > [ 928.404842] Sequencer SCB Info: > [ 928.404850] 0 SCB_CONTROL[0x0] SCB_SCSIID[0x0] SCB_LUN[0x0] > [ 928.404891] SCB_TAG[0x0] > [ 928.404901] 1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.404946] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.404974] 2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405019] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405048] 3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405164] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405199] 4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405248] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405279] 5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405326] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405357] 6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405404] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405435] 7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405482] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405513] 8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405561] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405592] 9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405638] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405668] 10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405712] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405740] 11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405784] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405813] 12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405857] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405886] 13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.405930] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.405958] 14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.406002] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.406031] 15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.406075] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.406104] 16 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.406147] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.406176] 17 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.406220] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.406249] 18 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.406293] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.406322] 19 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.406366] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.406394] 20 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.406439] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.406468] 21 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.406513] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.406542] 22 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.406586] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.406615] 23 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.408028] 24 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.408028] 25 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.408028] 26 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.408028] 27 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.408028] 28 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.408028] 29 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.408028] 30 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.408028] 31 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) > [ 928.408028] SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] > [ 928.408028] Pending list: > [ 928.408028] 2 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xf7]:(TWIN_CHNLB|TWIN_TID) > [ 928.408028] SCB_LUN[0x0] > [ 928.408028] Kernel Free SCB list: 1 0 > [ 928.408028] Untagged Q(15): 2 > [ 928.408028] > [ 928.408028] <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> > [ 928.408028] (scsi0:A:15:0): Device is disconnected, re-queuing SCB > [ 928.408028] Recovery code sleeping > > [1] http://lists.xensource.com/archives/html/xen-devel/2010-03/msg00448.html > > -- > # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ > # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | > [ "There's nobody getting rich writing ]| -- Collect and hide your | > [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / From bob at ucc.gu.uwa.edu.au Sun Apr 25 14:52:14 2010 From: bob at ucc.gu.uwa.edu.au (Bob Adamson) Date: Sun, 25 Apr 2010 14:52:14 +0800 (WST) Subject: [tech] Ubuntu Wall Port Message-ID: The Ubuntu tap has magically reconnected/rewired itself, according to the port tester anyway - so now we can drink it at 1Gbps. Bob Adamson UCC Treasurer |"Bureaucracy is a challenge to the be conquered with a righteous | |attitude, an intolerance for stupidity, and a bulldozer when necessary" | | ---Peter's Laws | From mitch at ucc.asn.au Sun Apr 25 15:59:00 2010 From: mitch at ucc.asn.au (Mitch Kelly) Date: Sun, 25 Apr 2010 15:59:00 +0800 Subject: [tech] Ubuntu Wall Port In-Reply-To: References: Message-ID: <000501cae44d$2a6cd270$7f467750$@asn.au> I believe the port is just like any ordinary wall port in UCC? You can boot off any of them, Of course however being in the ubuntu port means your coffee beans will be more roasted and taste nicer. -----Original Message----- From: tech-bounces at ucc.gu.uwa.edu.au [mailto:tech-bounces at ucc.gu.uwa.edu.au] On Behalf Of Bob Adamson Sent: Sunday, 25 April 2010 2:52 PM To: tech at ucc.gu.uwa.edu.au Subject: [tech] Ubuntu Wall Port The Ubuntu tap has magically reconnected/rewired itself, according to the port tester anyway - so now we can drink it at 1Gbps. Bob Adamson UCC Treasurer |"Bureaucracy is a challenge to the be conquered with a righteous | |attitude, an intolerance for stupidity, and a bulldozer when necessary" | | ---Peter's Laws | No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.801 / Virus Database: 271.1.1/2832 - Release Date: 04/25/10 02:31:00 From zanchey at ucc.gu.uwa.edu.au Sun Apr 25 16:04:25 2010 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Sun, 25 Apr 2010 16:04:25 +0800 (WST) Subject: [tech] Ubuntu Wall Port In-Reply-To: <000501cae44d$2a6cd270$7f467750$@asn.au> References: <000501cae44d$2a6cd270$7f467750$@asn.au> Message-ID: On Sun, 25 Apr 2010, Mitch Kelly wrote: > I believe the port is just like any ordinary wall port in UCC? You can boot > off any of them, Of course however being in the ubuntu port means your > coffee beans will be more roasted and taste nicer. It's connected to VLAN 8 instead of 3, which was the magical netboot VLAN. As we offer netboot on VLAN 3 anyway, we could kill VLAN 8 without any real concern. [DAA] From adrian at ucc.gu.uwa.edu.au Mon Apr 26 16:29:15 2010 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Mon, 26 Apr 2010 16:29:15 +0800 Subject: [tech] projector for friday? Message-ID: <20100426082915.GV8564@ucc.gu.uwa.edu.au> Howdy, So does UCC have a functional projector? I'd like to organise one for John's talk on Friday. Thanks, Adrian From mitch at ucc.asn.au Mon Apr 26 17:50:45 2010 From: mitch at ucc.asn.au (Mitch Kelly) Date: Mon, 26 Apr 2010 17:50:45 +0800 Subject: [tech] projector for friday? In-Reply-To: <20100426082915.GV8564@ucc.gu.uwa.edu.au> References: <20100426082915.GV8564@ucc.gu.uwa.edu.au> Message-ID: <000901cae525$f1501b30$d3f05190$@asn.au> I have a working one. I think bob got the one at UCC working but the bulb is suspect and probably shouldn't be powered up. -----Original Message----- From: tech-bounces at ucc.gu.uwa.edu.au [mailto:tech-bounces at ucc.gu.uwa.edu.au] On Behalf Of Adrian Chadd Sent: Monday, 26 April 2010 4:29 PM To: tech at ucc.gu.uwa.edu.au Subject: [tech] projector for friday? Howdy, So does UCC have a functional projector? I'd like to organise one for John's talk on Friday. Thanks, Adrian No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.801 / Virus Database: 271.1.1/2835 - Release Date: 04/26/10 02:31:00 From mattman at ucc.gu.uwa.edu.au Mon Apr 26 20:57:09 2010 From: mattman at ucc.gu.uwa.edu.au (Matt Didcoe) Date: Mon, 26 Apr 2010 20:57:09 +0800 Subject: [tech] Management LAN Message-ID: It was mentioned the other day by David I think (when we were talking about switches) - we have servers with LOM and DRAC, so a management LAN doesn't seem like a terrible idea. What are peoples thoughts on the topic? - Matt [MRD] -- Matt Didcoe 2010 President University Computer Club -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20100426/36889bdd/attachment.htm From adrian at ucc.gu.uwa.edu.au Mon Apr 26 21:04:28 2010 From: adrian at ucc.gu.uwa.edu.au (Adrian Chadd) Date: Mon, 26 Apr 2010 21:04:28 +0800 Subject: [tech] Management LAN In-Reply-To: References: Message-ID: <20100426130428.GW8564@ucc.gu.uwa.edu.au> On Mon, Apr 26, 2010, Matt Didcoe wrote: > It was mentioned the other day by David I think (when we were talking about > switches) - we have servers with LOM and DRAC, so a management LAN doesn't > seem like a terrible idea. > > What are peoples thoughts on the topic? We can also put the cisco switches on that management VLAN so they're not internet-accessible. Thumbs up from here. From mattman at ucc.gu.uwa.edu.au Mon Apr 26 21:06:38 2010 From: mattman at ucc.gu.uwa.edu.au (Matt Didcoe) Date: Mon, 26 Apr 2010 21:06:38 +0800 Subject: [tech] Management LAN In-Reply-To: <20100426130428.GW8564@ucc.gu.uwa.edu.au> References: <20100426130428.GW8564@ucc.gu.uwa.edu.au> Message-ID: One thing I hadn't considered is what address space we can put it in. Something else for discussion :-) On Mon, Apr 26, 2010 at 9:04 PM, Adrian Chadd wrote: > On Mon, Apr 26, 2010, Matt Didcoe wrote: > > It was mentioned the other day by David I think (when we were talking > about > > switches) - we have servers with LOM and DRAC, so a management LAN > doesn't > > seem like a terrible idea. > > > > What are peoples thoughts on the topic? > > We can also put the cisco switches on that management VLAN so they're not > internet-accessible. > > Thumbs up from here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20100426/807a9840/attachment.htm From zanchey at ucc.gu.uwa.edu.au Mon Apr 26 21:14:40 2010 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Mon, 26 Apr 2010 21:14:40 +0800 (WST) Subject: [tech] Management LAN In-Reply-To: References: Message-ID: On Mon, 26 Apr 2010, Matt Didcoe wrote: > It was mentioned the other day by David I think (when we were talking about > switches) - we have servers with LOM and DRAC, so a management LAN doesn't > seem like a terrible idea. > > What are peoples thoughts on the topic? We already have one. Most of the switches (except olive) and the LOM kit are already on it. VLAN 1. VLAN 4 was the original management VLAN but that has been killed off as the Alloy gigabit switch required management on VLAN 1. Address space is 192.168.2/24. I've been putting things in DNS as well. This is all in /home/wheel/docs/NetworkTopology (although the rest of that file needs updating) and on http://wiki.ucc.asn.au/Network#InternalVLANs . David Adam UCC Wheel Member zanchey@ From mitch at ucc.asn.au Mon Apr 26 21:56:59 2010 From: mitch at ucc.asn.au (Mitch Kelly) Date: Mon, 26 Apr 2010 21:56:59 +0800 Subject: [tech] QOS and Linux Message-ID: <003b01cae548$57d7d8d0$07878a70$@asn.au> Hi, I have a 40Mbit WAIX link, I need to get QOS working however. Can someone shed some light on how I can do the following: Client A uses the link, he can get 35Mbit (5Mbit Spare) Client B starts using the link, They both get 18~Mbit Client C starts using the link, They all get 12Mbit~ Etc.etc. The links can go from 40 to 30 Without notice (depending on conditions etc, it wireless to Perth city WaFreenet AP) Any Ideas? Mitch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20100426/3e670f62/attachment.htm From davidb at ucc.gu.uwa.edu.au Tue Apr 27 09:47:06 2010 From: davidb at ucc.gu.uwa.edu.au (David Basden) Date: Tue, 27 Apr 2010 11:47:06 +1000 Subject: [tech] Management LAN In-Reply-To: References: Message-ID: <20100427014706.GM17360@wilfred.rcpt.to> On Mon, Apr 26, 2010 at 08:57:09PM +0800, Matt Didcoe wrote: > It was mentioned the other day by David I think (when we were talking about > switches) - we have servers with LOM and DRAC, so a management LAN doesn't > seem like a terrible idea. > > What are peoples thoughts on the topic? LOM-NOM-NOM (I think it's a good idea) .. D From zanchey at ucc.gu.uwa.edu.au Tue Apr 27 23:01:16 2010 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Tue, 27 Apr 2010 23:01:16 +0800 (WST) Subject: [tech] New switches In-Reply-To: References: Message-ID: On Thu, 22 Apr 2010, Matt Didcoe wrote: > Thanks to some awesome dealing by Frenchie, we now have two (well one, other > one is on its way) new Cisco 2948G-GE-TX switches. > > They will be called Coconut and Palm. > > The first (Coconut) has been configured as a near exact replica of > Lorenzo (I think) -it still needs a bit of work, but I hope to have it > in production tomorrow afternoon. Over the last few days I've been slowly moving stuff across, and tonight I bit the bullet and moved just about everything from Lorenzo. There are still a few remaining ports, but I'm out of time, and they're the exciting ones so best left to daytime. I also fixed the port descriptions on Lorenzo so that anyone moving them across should be able to work out what they are reasonably easily. I'll update wiki.ucc.asn.au/Network/SwitchConfiguration at some stage, but they are all labelled in the config (which has been pulled into SVN by rancid - see http://cvs.ucc.asn.au/cgi-bin/viewvc.cgi/rancid). I paid very little attention to the optimal ordering of ports based on the switch internals; I don't actually think this is worth caring about yet. I've also added the switch to Cacti (wheel members only, sorry). > When Palm comes down from Arts some time in the next couple of weeks, > the plan is to drop that in the left hand rack. In the meantime, I've run a cable for Maraena (which hosts Mylah and Mussel) across the back wall so that it has gigabit access. David Adam UCC Wheel Member zanchey@ From zanchey at ucc.gu.uwa.edu.au Wed Apr 28 22:47:27 2010 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Wed, 28 Apr 2010 22:47:27 +0800 (WST) Subject: [tech] Moving dispense & decommissioning Mermaid Message-ID: Mermaid's had a good run, but I think it might be time to send it to the big server farm in the sky. It's running an old version of Debian on old ("temporary") hardware, and most of its functions have been supplanted. The only thing it's still running is the Dispense server (i.e. the binary that does the accounting and interfaces with the Coke machine hardware), which doesn't look too hard to move to a different machine. I'm not sure which machine is a good candidate; Martello's serial port is already in use and it has a pl2303 USB-serial converter also in use. I have no desire to move Dispense to a Solaris machine or do serial passthrough on a Xen VM. That really only leaves Mooneye or Madako. I know there's a plan to put Real PC Hardware into the Coke machine, but that seems to be making little progress at the moment. Thoughts? [DAA] From mitch at ucc.asn.au Thu Apr 29 06:01:33 2010 From: mitch at ucc.asn.au (Mitch Kelly) Date: Thu, 29 Apr 2010 06:01:33 +0800 Subject: [tech] Moving dispense & decommissioning Mermaid In-Reply-To: References: Message-ID: <010c01cae71e$5d59c5c0$180d5140$@asn.au> Would a Mini ITX board work well in the machine? I have a few spare. -----Original Message----- From: tech-bounces at ucc.gu.uwa.edu.au [mailto:tech-bounces at ucc.gu.uwa.edu.au] On Behalf Of David Adam Sent: Wednesday, 28 April 2010 10:47 PM To: tech at ucc.gu.uwa.edu.au Subject: [tech] Moving dispense & decommissioning Mermaid Mermaid's had a good run, but I think it might be time to send it to the big server farm in the sky. It's running an old version of Debian on old ("temporary") hardware, and most of its functions have been supplanted. The only thing it's still running is the Dispense server (i.e. the binary that does the accounting and interfaces with the Coke machine hardware), which doesn't look too hard to move to a different machine. I'm not sure which machine is a good candidate; Martello's serial port is already in use and it has a pl2303 USB-serial converter also in use. I have no desire to move Dispense to a Solaris machine or do serial passthrough on a Xen VM. That really only leaves Mooneye or Madako. I know there's a plan to put Real PC Hardware into the Coke machine, but that seems to be making little progress at the moment. Thoughts? [DAA] No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.801 / Virus Database: 271.1.1/2835 - Release Date: 04/28/10 02:27:00 From mattman at ucc.gu.uwa.edu.au Thu Apr 29 15:59:01 2010 From: mattman at ucc.gu.uwa.edu.au (Matt Didcoe) Date: Thu, 29 Apr 2010 15:59:01 +0800 Subject: [tech] UCC mail hosting Message-ID: Hi everyone, As of May 3, 2010 (this coming Monday), all mail coming through the UWA core routers must be passed through the UWA Ironports. This necessitates some configuration changes in you have your domain's mail being handled by UCC. Outgoing mail is also required to go through the Ironports, which affects the outgoing gateway settings associated with your mail server. All UCC domains (ucc.asn.au, ucc.gu.uwa.edu.au and ucc.guild.uwa.edu.au) have already been updated to reflect this change in ITS policy - no downtime should result from the changeover on Monday. If you have a domain hosted here you need added to the Ironport config, please email me and we'll work it out :-) Please note that from Monday May 3rd, incoming and outgoing email not directed to the new Ironport?gateways will be blocked at the border router. Any issues on Monday sending/receiving email - email wheel at ucc Thanks, Matt [MRD] -- Matt Didcoe 2010 President University Computer Club 0422 899 871 From frenchiephish at gmail.com Fri Apr 30 19:18:02 2010 From: frenchiephish at gmail.com (James French) Date: Fri, 30 Apr 2010 19:18:02 +0800 Subject: [tech] Humpback Updated to Ubuntu 10.04 Message-ID: Hi All, I updated humpback to 10.04 this evening. Enjoy the new garish purple instead of the old garish brown. F. From bob at ucc.gu.uwa.edu.au Fri Apr 30 20:31:45 2010 From: bob at ucc.gu.uwa.edu.au (Bob Adamson) Date: Fri, 30 Apr 2010 20:31:45 +0800 (WST) Subject: [tech] Racks Moved and Stuff Message-ID: Racks Moved: The newly acquired rack has been installed where the old half-height rack was. Maaxen and 'that dell' have been rack mounted *with rails*, while Troppo has taken up residence next to martello. The old rack is now in the corridor, are there any suggestions on what to do with it? Stuff: Cephalopod had some problem that was stuffing up both the linux and windows partitions. It has been formatted and reinstalled with windows 7, with ubuntu lucid to follow. Bob Adamson UCC Treasurer |"Bureaucracy is a challenge to the be conquered with a righteous | |attitude, an intolerance for stupidity, and a bulldozer when necessary" | | ---Peter's Laws |