From mjpomery at ucc.asn.au Thu Jun 5 19:14:04 2014 From: mjpomery at ucc.asn.au (Mitchell Pomery) Date: Thu, 5 Jun 2014 19:14:04 +0800 (WST) Subject: [tech] Mitchfish The New Fileserver! Message-ID: People in #committee don't seem to like the name, and would prefer "molmol", like people stated previously. Buut the important thing is that it lives! Through pure magic (with help from [GOZ]), it has been mounted in the machine room. Now all it needs is the softweare to be set up on it. You can currently log in to it at mitchfish at dhcp3 to have a poke around and see how bad I am at installing Ubuntu. Password is the clubroom password. All the hard drives are mounted, and visible from the bios onwards. Have fun playing with it. I tried to set up wheel keys, but they didn't seem to want to work. I can set it up properly another dday, but I should really start this exam study... Mitch /me touches nose From zanchey at ucc.gu.uwa.edu.au Fri Jun 6 23:47:43 2014 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Fri, 6 Jun 2014 23:47:43 +0800 (WST) Subject: [tech] Death of FREENETS, etc. Message-ID: I discovered today that fail2ban wasn't actually protecting our SSH servers at all because of a mistake in the firewall. After fixing this, I did some other maintenance on the firewall, including removing the old FREENETS stuff (which hasn't worked as intended for some time). I checked the changes into RCS (because it's the 1980s) as I made them, so you should be able to pin the blame appropriately if anything is broken. [DAA] From 20361362 at student.uwa.edu.au Thu Jun 12 12:58:35 2014 From: 20361362 at student.uwa.edu.au (Lyndon White) Date: Thu, 12 Jun 2014 12:58:35 +0800 Subject: [tech] Long Running Computations on Motsugo Message-ID: <5399337B.4020700@student.uwa.edu.au> Hi all, I am currently running some computations on motsugo, for my final year project. Inline with the Clubs Objects (sic): "To be an organised association of students attending The University of Western Australia, and supporters, for the advancement of computer science and technologies, both at the University and in the broader community.*" * Motsugo has 8 Physical Cores, and with hyper threading that makes 16 logical cores. I am running 6 processes. You can see them in htop names "python motsugo_*.py" [SZM] is also running a process for his final year project, you can see it in htop as "/tests/calculatepi.test" That means that there is one free physcical core, and 10 free logical cores. However hyperthreading doesn't work well with long running computational tasks like mine, so any processes sharing the physcial cores I am using are going to be in for a unfun time. My current estimation (which is more or less a total guess) is that my processes will run for the next 2 weeks. While it is set up to be mostly resumable if it is terminated (I would loose maybe several hours of work and have to do some minor reconfig). I would really prefer if noone killed them, or rebooted motsugo. When this workload finishes I have 3 more similar loads. I would also recommend anyone considering other similar long running computational workloads, find another server. I am currently setting up to be running similar experiments on SIP lab computers (Signal and Information Processing). I have serveral quad cores waiting for me there (running ubuntu 10 :-( ). However I basically need all the computational power I can get, so will be continuing to use motsugo. If you are interested in the actual computer science I am advancing: Have my project proposal abstract: "After a large amount of time and computational resources have been invested in training a very large neural net, it is desirable to leverage that investment to create new neural nets for related tasks. This is known as domain adaptation. This project seeks to demonstrate a method which can be used for this. To achieve this goal, it is necessary to isolate which par ts of the neural net contain useful reusable information. Such infor mation would be an abstract description of the relationship of features within the input data-space." If anyone is actually interested i can talk about this stuff all day and have a bunch of documents and stuffs. Regards [*OX] From matches at ucc.asn.au Thu Jun 12 12:20:29 2014 From: matches at ucc.asn.au (Sam Moore) Date: Thu, 12 Jun 2014 12:20:29 +0800 Subject: [tech] Long Running Computations on Motsugo In-Reply-To: <5399337B.4020700@student.uwa.edu.au> References: <5399337B.4020700@student.uwa.edu.au> Message-ID: <53992A8D.1070205@ucc.asn.au> On 12/06/14 12:58, Lyndon White wrote: > [SZM] is also running a process for his final year project, you can see > it in htop as "/tests/calculatepi.test" I've killed this because it was really just a waste of resources. Here is a mislabelled graph from several months ago, to which I can now proudly add 5 new data points. http://szmoore.net/ipdf/sam/figures/calculatepi.pdf [SZM] From bob at ucc.gu.uwa.edu.au Sat Jun 21 21:17:39 2014 From: bob at ucc.gu.uwa.edu.au (Andrew Adamson) Date: Sat, 21 Jun 2014 21:17:39 +0800 (WST) Subject: [tech] Fail event on /dev/md/0:medico (fwd) Message-ID: This appears to be the second of the two original SSD's in medico to die, and needs to be replaced ASAP. Andrew Adamson bob at ucc.asn.au |"If you can't beat them, join them, and then beat them." | | ---Peter's Laws | ---------- Forwarded message ---------- Date: Sat, 21 Jun 2014 14:35:53 +0800 (WST) From: mdadm monitoring To: root at ucc.gu.uwa.edu.au Subject: Fail event on /dev/md/0:medico This is an automatically generated mail message from mdadm running on medico A Fail event had been detected on md device /dev/md/0. Faithfully yours, etc. P.S. The /proc/mdstat file currently contains the following: Personalities : [raid1] md0 : active raid1 sda1[3](F) sdb1[2] 125032767 blocks super 1.2 [2/1] [_U] unused devices: From zanchey at ucc.gu.uwa.edu.au Tue Jun 24 18:08:33 2014 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Tue, 24 Jun 2014 18:08:33 +0800 (WST) Subject: [tech] Mantis (old Neomussel) Message-ID: I would like to remove Mantis. The idea was that it would be a replacement for Mussel, hosted on different hardware & VM software, and "cleaner".[1] I don't think that it has fulfilled the goals. In terms of replacing Mussel, it is only running the static website and a secondary IRC server. It has never had the SOE completely installed, it runs a mixture of Debian Stable and Unstable, and I don't think it's been installed in a particularly cleaner manner. Finally, we moved Mussel to the same hardware/VM software which fixed the issues we were having with it. At present it is a 4GB VM on Medico (Mussel is also on Medico) and we could use those resources more wisely. I intend to move the website back to Mussel, stop the VM and then destroy it in a few weeks if there are no objections. [1]: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/2013-July/004318.html David Adam UCC Wheel Member zanchey at ucc.gu.uwa.edu.au From oxinabox at ucc.asn.au Tue Jun 24 20:45:29 2014 From: oxinabox at ucc.asn.au (Frames) Date: Tue, 24 Jun 2014 20:45:29 +0800 Subject: [tech] Mantis (old Neomussel) In-Reply-To: References: Message-ID: <53A972E9.2000607@ucc.asn.au> Agreed. It is also a C-NAME for OCSinventroy.ucc.asn.au (or similar). Change that back and then we should be able to turn ocsinventory on mussel back on, and it should start working again. (It was never setup properly on mantis.) [*OX] David Adam wrote: > I would like to remove Mantis. > > The idea was that it would be a replacement for Mussel, hosted on > different hardware & VM software, and "cleaner".[1] > > I don't think that it has fulfilled the goals. In terms of replacing > Mussel, it is only running the static website and a secondary IRC server. > It has never had the SOE completely installed, it runs a mixture of Debian > Stable and Unstable, and I don't think it's been installed in a > particularly cleaner manner. Finally, we moved Mussel to the same > hardware/VM software which fixed the issues we were having with it. > > At present it is a 4GB VM on Medico (Mussel is also on Medico) and we > could use those resources more wisely. I intend to move the website back > to Mussel, stop the VM and then destroy it in a few weeks if there are no > objections. > > [1]: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/2013-July/004318.html > > David Adam > UCC Wheel Member > zanchey at ucc.gu.uwa.edu.au > > _______________________________________________ > List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech > > Unsubscribe here: http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/oxinabox%40ucc.asn.au From zanchey at ucc.gu.uwa.edu.au Mon Jun 30 10:12:10 2014 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Mon, 30 Jun 2014 10:12:10 +0800 (WST) Subject: [tech] [hwc] IPv6 Outage In-Reply-To: References: Message-ID: On Thu, 19 Jun 2014, Mitchell Pomery wrote: > As mentioned before, UWA is doing a university wide upgrade enabling IPv6 > everywhere. In doing so, UCC will have IPv6 disabled temporarily. > > It is starting on the 30th June (Not the 22nd as previously stated) and the > outage window is two weeks. I edited zonemake and we don't publish AAAA records for our services any more. I don't know if this is going to be a real outage or whether it's been made as an advisory notice, but I'll turn AAAA records back on in a couple of weeks. Presumably IPv6 packets sent upstream will just be dropped once the outage starts; I'm not sure what the best way is of avoiding long timeouts before fallback to IPv4. So I put it on ServerFault. We might have an answer by the time the outage is over (the current winner is "bring up some IPv6 tunnels and then 1:1 NAT your ranges"). David Adam UCC Wheel Member zanchey at ucc.gu.uwa.edu.au