From gozzarda at ucc.asn.au Wed Aug 1 21:30:22 2018 From: gozzarda at ucc.asn.au (gozzarda at ucc.asn.au) Date: Wed, 01 Aug 2018 21:30:22 +0800 Subject: [tech] SMTP Auth Failure Message-ID: Hi all, For a while now I have been unable to authenticate when trying to connect via SMTP. I finally had a chance to dig in a bit today to try figure this out and found that my auth attempt is getting as far as saslauthd, which is reporting that it is failing to connect to the LDAP server. I am somewhat uninformed about the details of our migration to AD, and even less so about specifically how it is wired into SASL auth, but this error seems particularly indirect to me. My best uneducated guess is that it is failing through to some old wiring to try hit LDAP, and should not even be getting that far, but I am at a loss for what to poke next. Suggestions for pokable targets are much appreciated, as is background information on how we have wired SMTP auth in general. Cheers, Gozz P.S: The issue may affect other users, but it is difficult to distinguish between a mistyped password and this issue, so I can't be sure who or how many or if I am alone in being unable to send email. P.P.S: In case anyone was going to ask, this email was sent through roundcube, which still works absolutely fine. From trs80 at ucc.gu.uwa.edu.au Thu Aug 2 00:04:36 2018 From: trs80 at ucc.gu.uwa.edu.au (trs80 at ucc.gu.uwa.edu.au) Date: Thu, 2 Aug 2018 00:04:36 +0800 (AWST) Subject: [tech] SMTP Auth Failure In-Reply-To: References: Message-ID: On Wed, 1 Aug 2018, gozzarda at ucc.asn.au wrote: > For a while now I have been unable to authenticate when trying to > connect via SMTP. > I finally had a chance to dig in a bit today to try figure this out and > found that my auth attempt is getting as far as saslauthd, which is > reporting that it is failing to connect to the LDAP server. > I am somewhat uninformed about the details of our migration to AD, and > even less so about specifically how it is wired into SASL auth, but this > error seems particularly indirect to me. > My best uneducated guess is that it is failing through to some old > wiring to try hit LDAP, and should not even be getting that far, but I > am at a loss for what to poke next. > Suggestions for pokable targets are much appreciated, as is background > information on how we have wired SMTP auth in general. saslauthd is set to use PAM (mooneye:/etc/default/saslauthd). There isn't an /etc/pam.d/saslauthd file so I'm not sure how it works. I came across https://wiki.debian.org/PostfixAndSASL but I don't know how relevant it is these days. It does mention the useful "saslfinger -s" command which hangs at "-- mechanisms on localhost --". Further investigation shows it hangs because it's grepping for AUTH which is not presented. OK that's because we have this in main.cf: # asclepius means we can only use ssl anyway smtpd_tls_auth_only = yes and it does show up when I do $ openssl s_client -connect mooneye.ucc.gu.uwa.edu.au:587 -starttls smtp and EHLO localhost: 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN Trying to auth plain gives this in mail.log warning: SASL authentication failure: Password verification failed stracing the smtpd process while it's authing me shows: connect(29, {sa_family=AF_UNIX, sun_path="/var/run/saslauthd/mux"}, 110) = 0 it then sends my password and receives read(29, "\0\21", 2) = 2 read(29, "NO PAM auth error", 17) = 17 auth.log has Aug 1 23:47:45 mooneye saslauthd[1420]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=trs80 Aug 1 23:47:45 mooneye saslauthd[1420]: pam_ldap(smtp:auth): Authentication failure; user=trs80 Aug 1 23:47:47 mooneye saslauthd[1420]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure Aug 1 23:47:47 mooneye saslauthd[1420]: : auth failure: [user=trs80] [service=smtp] [realm=mooneye.ucc.gu.uwa.edu.au] [mech=pam] [reason=PAM auth error] Further stracing saslauthd shows it's only talking to nslcd.conf, ie LDAP on mussel and mostugo, which of course isn't running, not AD. But /etc/nsswitch.conf has passwd: files ldap winbind (really it should be winbind ldap) so it should be talking to both. But also $ ls -l /etc/nsswitch.conf -rw-r--r-- 1 root root 536 Feb 27 08:22 /etc/nsswitch.conf vs $ ps xua|grep saslauth root 1419 0.0 0.1 14212 2184 ? Ss Feb26 0:29 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5 root 1420 0.0 0.1 14212 2180 ? S Feb26 0:29 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5 root 1421 0.0 0.1 14212 2228 ? S Feb26 0:29 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5 root 1422 0.0 0.1 14212 2184 ? S Feb26 0:29 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5 root 1423 0.0 0.1 14212 2196 ? S Feb26 0:29 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5 So it's unlikely that saslauthd read in a version os nsswitch.conf that included winbind when it started. I invite you to restart saslauthd and see if it then works. However as a shortcut you might be interested in line 117 of mooneye:/etc/postfix/master.cf which I won't quote here but should also solve your problem. -- # 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 frekk at ucc.asn.au Wed Aug 8 23:51:23 2018 From: frekk at ucc.asn.au (Felix von Perger) Date: Wed, 8 Aug 2018 23:51:23 +0800 Subject: [tech] Downtime & R.I.P. Maltair Message-ID: Dear tech subscribers, For those of you who have not been following the committee discussions of the last week or so, there was a total service outage this morning between 8:00 and 10:00 which was due to RCD testing in Cameron Hall. Apologies for any inconvenience. Sadly, in the process of turning things back on after the power was restored, an IMM2 firmware bug on Maltair seems to have rendered it permanently unbootable (see https://support.lenovo.com/au/en/solutions/ht118532). [CFE] performed a firmware upgrade this evening to the latest version (v6.8) from v4.3 however it seems like the damage has already been done and either the entire motherboard or the builtin 5V voltage regulator will need to be replaced or repaired. Due to Maltair being presently out of action, additional downtime may be experienced for certain services that were previously hosted on Maltair. Since Maltair accounted for most of our RAM availability, member VMs with large RAM requirements may remain powered off for the time being or have their maximum RAM reduced. Any suggestions for replacement hardware for Maltair are welcome. The existing server is a 1RU IBM System x3550 M4 (7914/7915), and it is likely that the majority of its parts (CPU, RAM, RAID, 10Gb NIC, PSUs) are still functional despite the system board being fried. Best regards, Felix von Perger [FVP] UCC Secretary & Wheel Member From bob at ucc.asn.au Thu Aug 9 21:49:09 2018 From: bob at ucc.asn.au (Bob Adamson) Date: Thu, 9 Aug 2018 21:49:09 +0800 Subject: [tech] Downtime & R.I.P. Maltair In-Reply-To: References: Message-ID: <000d01d42fe7$c03d9840$40b8c8c0$@ucc.asn.au> Felix and I de-racked maltair tonight and I pulled its mobo out. The Lenovo page lists only a "VT261" 5V regulator as probably being damaged, so I figured we should just be able to find and replace it. Famous last words. Google turns up VT261WFQR-ADJ as (the only) possible candidate for what VT261 refers to. Unfortunately, googling further for the VT261WFQR-ADJ datasheet only shows up a Maxim datasheet, which makes sense since they bought out Volterra in 2013. Just to make things really interesting, the kynix site (the only result that has a datasheet) links to an Intersil datasheet: https://www.kynix.com/uploadfiles/pdf8827/ICL7660ACBA-T.pdf . The maxim site was a bit more forthcoming once I knew a newer part number ( https://datasheets.maximintegrated.com/en/ds/ICL7660-MAX1044.pdf ), but I didn't have any luck looking for 7660 on any of the mobo chips. More googling later, and even turning to countries that have a robust market for *ahem* aftermarket goods, shows up this: https://ru.aliexpress.com/item/VT261WF-VT261MF-VT261WFQX-ADJ-QFN-1-integrate d-circuit/32818058390.html , which is possibly-maybe the thing we should be looking for on the mobo. There were a few shiny chips on the board, but I need to return at a later date with my shiny new USB microscope to check further. If anyone else wants to take a look at it, please be careful about flexing the board while handling (it's very big) and also be careful not to knock off any components (they're very small, and I mean like >.< this big). Oh, and I manually migrated all network-stored VM's to medico today, and I believe Felix did the remaining locally stored VM's this evening. --Bob -----Original Message----- From: tech-bounces+bob=ucc.gu.uwa.edu.au at ucc.gu.uwa.edu.au [mailto:tech-bounces+bob=ucc.gu.uwa.edu.au at ucc.gu.uwa.edu.au] On Behalf Of Felix von Perger Sent: Wednesday, 8 August 2018 11:51 PM To: tech at ucc.asn.au Subject: [tech] Downtime & R.I.P. Maltair Dear tech subscribers, For those of you who have not been following the committee discussions of the last week or so, there was a total service outage this morning between 8:00 and 10:00 which was due to RCD testing in Cameron Hall. Apologies for any inconvenience. Sadly, in the process of turning things back on after the power was restored, an IMM2 firmware bug on Maltair seems to have rendered it permanently unbootable (see https://support.lenovo.com/au/en/solutions/ht118532). [CFE] performed a firmware upgrade this evening to the latest version (v6.8) from v4.3 however it seems like the damage has already been done and either the entire motherboard or the builtin 5V voltage regulator will need to be replaced or repaired. Due to Maltair being presently out of action, additional downtime may be experienced for certain services that were previously hosted on Maltair. Since Maltair accounted for most of our RAM availability, member VMs with large RAM requirements may remain powered off for the time being or have their maximum RAM reduced. Any suggestions for replacement hardware for Maltair are welcome. The existing server is a 1RU IBM System x3550 M4 (7914/7915), and it is likely that the majority of its parts (CPU, RAM, RAID, 10Gb NIC, PSUs) are still functional despite the system board being fried. Best regards, Felix von Perger [FVP] UCC Secretary & Wheel Member _______________________________________________ List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech Unsubscribe here: http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/bob%40ucc.gu.uwa.edu.au From frekk at ucc.asn.au Fri Aug 10 23:50:01 2018 From: frekk at ucc.asn.au (Felix von Perger) Date: Fri, 10 Aug 2018 23:50:01 +0800 Subject: [tech] Proposed new parts to replace Porcupine Message-ID: <9231930d-ccc7-b9ad-ed8e-2166d39d6c2f@ucc.asn.au> Dear tech and committee, Here is a quick parts list which I propose to buy to replace Porcupine (or to replace Cobra/Catfish and swap some bits around to eventually end up with a suitable replacement). This is a fairly high end system using the latest 8th gen Intel CPUs and a reasonable quality motherboard. * Intel i7-8700T - $300 (https://www.ebay.com.au/itm/Intel-Core-i7-8700T-Processor-12M-Cache-up-to-4-00-GHz/223089946483) * ASRock B360M LGA1151-CL mATX motherboard - $110 (https://www.ple.com.au/Products/631588/ASRock-B360M-HDV-LGA1151-CL-mATX-Desktop-Motherboard) o Note: cheaper motherboards use Realtek LAN * 8GB DDR4-2666 RAM - $120 (https://www.ple.com.au/Products/632330/GeIL-8GB-Single-DDR4-Pristine-C19-2666MHz) o if 8GB RAM is not enough, 16GB DDR4-2666 modules can be found for $220 (https://www.ple.com.au/Products/628441/GeIL-16GB-Kit-2x8GB-DDR4-EVO-X-RGB-LED-C16-2400MHz) however this has the potential to go over-budget * 500GB SSD - $170 (https://www.ple.com.au/Products/630702/Crucial-MX500-500GB-SATA-25-7mm-SSD) * Power supply - use existing * Graphics card - use existing * Case - use existing Total cost for this build should be around $700, within the budget as proposed in the minutes here . Please provide feedback on any cost-saving measures, missing components, if this is under or over specced etc. - [FVP] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20180810/295db24c/attachment.htm From gozzarda at ucc.asn.au Sat Aug 11 00:27:12 2018 From: gozzarda at ucc.asn.au (gozzarda at ucc.asn.au) Date: Sat, 11 Aug 2018 00:27:12 +0800 Subject: [tech] SMTP Auth Failure In-Reply-To: References: Message-ID: <7f96de511febe12577eb227d0bb731ab@ucc.asn.au> A bit more digging when time allowed confirmed that PAM on mooneye was still set up to use LDAP and not AD. At first glance the PAM config files look impossible to maintain by hand. Had a look for a management system and found none. Had a chat to Zanchey, turns out there is a management system and it is called pam-auth-update. pam-auth-update confirmed that mooneye was relying on just ldap and unix auth. For comparison motsugo has kerberos, winbind, and unix auth enabled. I installed libpam-winbind and libpam-krb5 on mooneye and configured pam to use them and not ldap at the prompt. Nothing appears to be broken. SMTP authentication now works again for me. I can now send emails from my phone again (and there was much rejoicing https://youtu.be/yciX2meIkXI). If you observe any issues with authentication on mooneye, please report them here so I can figure out what I broke and fix it. Cheers, Gozz On 2018-08-02 00:04, trs80 at ucc.gu.uwa.edu.au wrote: > On Wed, 1 Aug 2018, gozzarda at ucc.asn.au wrote: > >> For a while now I have been unable to authenticate when trying to >> connect via SMTP. >> I finally had a chance to dig in a bit today to try figure this out >> and >> found that my auth attempt is getting as far as saslauthd, which is >> reporting that it is failing to connect to the LDAP server. >> I am somewhat uninformed about the details of our migration to AD, and >> even less so about specifically how it is wired into SASL auth, but >> this >> error seems particularly indirect to me. >> My best uneducated guess is that it is failing through to some old >> wiring to try hit LDAP, and should not even be getting that far, but I >> am at a loss for what to poke next. >> Suggestions for pokable targets are much appreciated, as is background >> information on how we have wired SMTP auth in general. > > saslauthd is set to use PAM (mooneye:/etc/default/saslauthd). There > isn't > an /etc/pam.d/saslauthd file so I'm not sure how it works. I came > across > https://wiki.debian.org/PostfixAndSASL but I don't know how relevant it > is > these days. It does mention the useful "saslfinger -s" command which > hangs > at "-- mechanisms on localhost --". Further investigation shows it > hangs > because it's grepping for AUTH which is not presented. OK that's > because > we have this in main.cf: > > # asclepius means we can only use ssl anyway > smtpd_tls_auth_only = yes > > and it does show up when I do > $ openssl s_client -connect mooneye.ucc.gu.uwa.edu.au:587 -starttls > smtp > and EHLO localhost: > > 250-AUTH LOGIN PLAIN > 250-AUTH=LOGIN PLAIN > > Trying to auth plain gives this in mail.log > > warning: SASL authentication failure: Password verification failed > > stracing the smtpd process while it's authing me shows: > > connect(29, {sa_family=AF_UNIX, sun_path="/var/run/saslauthd/mux"}, > 110) = 0 > > it then sends my password and receives > > read(29, "\0\21", 2) = 2 > read(29, "NO PAM auth error", 17) = 17 > > auth.log has > > Aug 1 23:47:45 mooneye saslauthd[1420]: pam_unix(smtp:auth): > authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= > user=trs80 > Aug 1 23:47:45 mooneye saslauthd[1420]: pam_ldap(smtp:auth): > Authentication failure; user=trs80 > Aug 1 23:47:47 mooneye saslauthd[1420]: DEBUG: auth_pam: > pam_authenticate failed: Authentication failure > Aug 1 23:47:47 mooneye saslauthd[1420]: : auth > failure: [user=trs80] [service=smtp] [realm=mooneye.ucc.gu.uwa.edu.au] > [mech=pam] [reason=PAM auth error] > > Further stracing saslauthd shows it's only talking to nslcd.conf, ie > LDAP > on mussel and mostugo, which of course isn't running, not AD. > > But /etc/nsswitch.conf has > > passwd: files ldap winbind > > (really it should be winbind ldap) so it should be talking to both. But > also > > $ ls -l /etc/nsswitch.conf > -rw-r--r-- 1 root root 536 Feb 27 08:22 /etc/nsswitch.conf > > vs > > $ ps xua|grep saslauth > root 1419 0.0 0.1 14212 2184 ? Ss Feb26 0:29 > /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5 > root 1420 0.0 0.1 14212 2180 ? S Feb26 0:29 > /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5 > root 1421 0.0 0.1 14212 2228 ? S Feb26 0:29 > /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5 > root 1422 0.0 0.1 14212 2184 ? S Feb26 0:29 > /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5 > root 1423 0.0 0.1 14212 2196 ? S Feb26 0:29 > /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5 > > So it's unlikely that saslauthd read in a version os nsswitch.conf that > included winbind when it started. I invite you to restart saslauthd and > see if it then works. > > However as a shortcut you might be interested in line 117 of > mooneye:/etc/postfix/master.cf which I won't quote here but should also > solve your problem. From zanchey at ucc.gu.uwa.edu.au Mon Aug 13 22:47:35 2018 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Mon, 13 Aug 2018 22:47:35 +0800 (AWST) Subject: [tech] Samba/LDAP migration Message-ID: There are still some loose ends from the LDAP to Samba migration needing to be tidied up. LDAP is still in NSS on Mussel and Mooneye until these can all be fixed. * flame - the flame user (UID 10026) did not get migrated into Active Directory. As flame runs only on Mooneye and out of local storage, I've created a local user instead. There's some stuff in /services/flame but it's all Very Old. * Users with UID < 1000 don't work properly on systems using Winbind, which is all of them except Motsugo. These accounts should ideally be renumbered to sensible UIDs. I've also upgraded the DC to 4.8.2 and removed and rejoined Maaxen from the domain. The rejoin failed every time I tried last night and then worked today?! David Adam zanchey at ucc.gu.uwa.edu.au Ask Me About Our SLA! From bob at ucc.gu.uwa.edu.au Tue Aug 14 18:25:34 2018 From: bob at ucc.gu.uwa.edu.au (bob at ucc.gu.uwa.edu.au) Date: Tue, 14 Aug 2018 18:25:34 +0800 (AWST) Subject: [tech] Downtime & R.I.P. Maltair In-Reply-To: <000d01d42fe7$c03d9840$40b8c8c0$@ucc.asn.au> References: <000d01d42fe7$c03d9840$40b8c8c0$@ucc.asn.au> Message-ID: Update: I managed to find the VT261 on the mobo last night. I looks like the one in the aliexpress link in my last email. I've ordered a couple off aliexpress, but they will take a few weeks to get here. When they arrive, we have some Damn Finnicky soldering to do (it's surrounded by 0402 sized components). Oh, and [TPG] had a chat to a rep from Maxim, and apparently datasheets for the Volterra VT261 were never made public, so we kinda just have to hope that this chip is the thing that's broken. Andrew Adamson bob at ucc.asn.au |"If you can't beat them, join them, and then beat them." | | ---Peter's Laws | On Thu, 9 Aug 2018, Bob Adamson wrote: > Felix and I de-racked maltair tonight and I pulled its mobo out. The Lenovo > page lists only a "VT261" 5V regulator as probably being damaged, so I > figured we should just be able to find and replace it. Famous last words. > > Google turns up VT261WFQR-ADJ as (the only) possible candidate for what > VT261 refers to. Unfortunately, googling further for the VT261WFQR-ADJ > datasheet only shows up a Maxim datasheet, which makes sense since they > bought out Volterra in 2013. Just to make things really interesting, the > kynix site (the only result that has a datasheet) links to an Intersil > datasheet: https://www.kynix.com/uploadfiles/pdf8827/ICL7660ACBA-T.pdf . > The maxim site was a bit more forthcoming once I knew a newer part number ( > https://datasheets.maximintegrated.com/en/ds/ICL7660-MAX1044.pdf ), but I > didn't have any luck looking for 7660 on any of the mobo chips. > > More googling later, and even turning to countries that have a robust market > for *ahem* aftermarket goods, shows up this: > https://ru.aliexpress.com/item/VT261WF-VT261MF-VT261WFQX-ADJ-QFN-1-integrate > d-circuit/32818058390.html , which is possibly-maybe the thing we should be > looking for on the mobo. There were a few shiny chips on the board, but I > need to return at a later date with my shiny new USB microscope to check > further. > > If anyone else wants to take a look at it, please be careful about flexing > the board while handling (it's very big) and also be careful not to knock > off any components (they're very small, and I mean like >.< this big). > > Oh, and I manually migrated all network-stored VM's to medico today, and I > believe Felix did the remaining locally stored VM's this evening. > > --Bob > > -----Original Message----- > From: tech-bounces+bob=ucc.gu.uwa.edu.au at ucc.gu.uwa.edu.au > [mailto:tech-bounces+bob=ucc.gu.uwa.edu.au at ucc.gu.uwa.edu.au] On Behalf Of > Felix von Perger > Sent: Wednesday, 8 August 2018 11:51 PM > To: tech at ucc.asn.au > Subject: [tech] Downtime & R.I.P. Maltair > > Dear tech subscribers, > > For those of you who have not been following the committee discussions of > the last week or so, there was a total service outage this morning between > 8:00 and 10:00 which was due to RCD testing in Cameron Hall. > Apologies for any inconvenience. > > Sadly, in the process of turning things back on after the power was > restored, an IMM2 firmware bug on Maltair seems to have rendered it > permanently unbootable (see > https://support.lenovo.com/au/en/solutions/ht118532). [CFE] performed a > firmware upgrade this evening to the latest version (v6.8) from v4.3 however > it seems like the damage has already been done and either the entire > motherboard or the builtin 5V voltage regulator will need to be replaced or > repaired. > > Due to Maltair being presently out of action, additional downtime may be > experienced for certain services that were previously hosted on Maltair. > Since Maltair accounted for most of our RAM availability, member VMs with > large RAM requirements may remain powered off for the time being or have > their maximum RAM reduced. > > Any suggestions for replacement hardware for Maltair are welcome. The > existing server is a 1RU IBM System x3550 M4 (7914/7915), and it is likely > that the majority of its parts (CPU, RAM, RAID, 10Gb NIC, PSUs) are still > functional despite the system board being fried. > > Best regards, > > Felix von Perger [FVP] > UCC Secretary & Wheel Member > > _______________________________________________ > List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech > > Unsubscribe here: > http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/bob%40ucc.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/bob%40ucc.gu.uwa.edu.au > From mtearle at ucc.asn.au Thu Aug 16 02:17:14 2018 From: mtearle at ucc.asn.au (Mark Tearle) Date: Wed, 15 Aug 2018 19:17:14 +0100 Subject: [tech] git.ucc.asn.au - was Re: Samba/LDAP migration In-Reply-To: References: Message-ID: <1534357034.231786.1475294424.7E345DDA@webmail.messagingengine.com> Hi folks Found another service that has experienced issues with this transition. mussel:/etc/apache2/sites-enabled# groups git git : sogo mussel:/etc/apache2/sites-enabled# ls -l ~git/public-html/ total 540 -rw-r--r-- 1 git sogo 246 Nov 7 2015 footer.html -rwxr-xr-x 1 git sogo 252173 Apr 2 22:27 gitweb.cgi .... In /etc/apache2/sites-available/members.conf which is simlink to /home/other/www/members.conf I tweaked the virtualhost entry to change the group for suExec from other (non-existant) to sogo, and it sprung back into life Include ssl-ucc.conf SSLEngine On SSLCertificateKeyFile /var/lib/acme/live/git.ucc.asn.au/privkey SSLCertificateFile /var/lib/acme/live/git.ucc.asn.au/cert SSLCertificateChainFile /var/lib/acme/live/git.ucc.asn.au/chain ServerName git.ucc.asn.au DocumentRoot /home/other/git/public-html #SuexecUserGroup git other SuexecUserGroup git sogo ServerAdmin git at ucc.asn.au allowoverride all Options +SymLinksIfOwnerMatch +Indexes +ExecCGI -FollowSymLinks So what changes do we need to make to fix it permanently? My memory of the horror that is UCC's web config is failing Mark -- Mark Tearle On Mon, 13 Aug 2018, at 3:47 PM, David Adam wrote: > There are still some loose ends from the LDAP to Samba migration needing > to be tidied up. LDAP is still in NSS on Mussel and Mooneye until these > can all be fixed. > > * flame - the flame user (UID 10026) did not get migrated into Active > Directory. As flame runs only on Mooneye and out of local storage, I've > created a local user instead. There's some stuff in /services/flame but > it's all Very Old. > > * Users with UID < 1000 don't work properly on systems using Winbind, > which is all of them except Motsugo. These accounts should ideally be > renumbered to sensible UIDs. > > I've also upgraded the DC to 4.8.2 and removed and rejoined Maaxen from > the domain. The rejoin failed every time I tried last night and then > worked today?! > > David Adam > zanchey at ucc.gu.uwa.edu.au > Ask Me About Our SLA! > _______________________________________________ > List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech > > Unsubscribe here: > http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/mtearle%40ucc.gu.uwa.edu.au From bob at ucc.gu.uwa.edu.au Sat Aug 18 13:35:36 2018 From: bob at ucc.gu.uwa.edu.au (bob at ucc.gu.uwa.edu.au) Date: Sat, 18 Aug 2018 13:35:36 +0800 (AWST) Subject: [tech] Proposed new parts to replace Porcupine In-Reply-To: <9231930d-ccc7-b9ad-ed8e-2166d39d6c2f@ucc.asn.au> References: <9231930d-ccc7-b9ad-ed8e-2166d39d6c2f@ucc.asn.au> Message-ID: Hi Felix, Thanks for putting this together. To start with, it's great that we can re-use some of those parts. I do think the budget is pretty low for this though - we've previously spent around $1100-1200 on a machine, and given the current bank balances, I see no reason to skimp (even if we do end up replacing maltair). With a more reasonable budget, we can sit a little bit ahead of the curve with this machine, and it will hold up better over 5 years. CPU first: The spec looked good, but the ebay item you linked has ended, and I couldn't see another for under $500. A $365 alternative could be an i5 which actually benchmarks slightly higher than the i7 anyway: https://www.ple.com.au/Products/629393/Intel-Core-i5-8600K-36GHz-Coffee-Lake-9MB-No-HSF-Retail-Box Is there any reason you didn't look at AMD? From what I can tell, the Ryzen 7 2700 is more powerful than either of the suggested intel chips, isn't susceptible to spectre/meltdown, and is in the same ballpark price ($379) https://www.ple.com.au/Products/631478/AMD-Ryzen-7-2700-32Ghz-20MB-AM4-Retail-Box---With-Wraith-Spire-LED-Cooler- RAM: ram is ram. Get whatever suits the mobo, but get at least 16GB, so $220 SSD: tricky to decide this without knowing what machine this hardware will end up in. If linux, size is less of an issue, but it would be really nice to get a blazing fast M.2 SSD. If windows, it needs to be at least 1TB...and it would be really nice to get a blazing fast M.2 SSD, but that puts us over the $500 mark for one that is faster than SATA3. My M.2 option is then $273 http://www.msy.com.au/waonline/m2-ssd/21322-samsung-970-evo-mz-v7e500bw-500gb-m2-ssd-solid-state-drive.html and my windows/SATA option is $309 https://www.ple.com.au/Products/630704/Crucial-MX500-1TB-SATA-25-7mm-SSD Mobo: I'm not sure what the issue with Realtek LAN is? I also went for something with a USB-C port (even my work laptop has it these days), $145: https://www.ple.com.au/Products/632874/ASRock-B450M-Pro4-AM4-mATX-Desktop-Motherboard- ...or an intel mobo to suit the i5, $129 https://www.ple.com.au/Products/631567/Gigabyte-B360M-D3H-LGA1151-CL-mATX-Desktop-Motherboard Totals, keeping in mind the AMD benchmarks higher: Linux AMD total: $1017 Linux Intel total: $987 Windows AMD total: $1053 Windows Intel total: $1023 Andrew Adamson bob at ucc.asn.au |"If you can't beat them, join them, and then beat them." | | ---Peter's Laws | On Fri, 10 Aug 2018, Felix von Perger wrote: > > Dear tech and committee, > > Here is a quick parts list which I propose to buy to replace Porcupine (or to replace Cobra/Catfish and swap some bits around to eventually end up with a suitable replacement). This is > a fairly high end system using the latest 8th gen Intel CPUs and a reasonable quality motherboard. > > * Intel i7-8700T - $300 (https://www.ebay.com.au/itm/Intel-Core-i7-8700T-Processor-12M-Cache-up-to-4-00-GHz/223089946483) > * ASRock B360M LGA1151-CL mATX motherboard - $110 (https://www.ple.com.au/Products/631588/ASRock-B360M-HDV-LGA1151-CL-mATX-Desktop-Motherboard) > + Note: cheaper motherboards use Realtek LAN > * 8GB DDR4-2666 RAM - $120 (https://www.ple.com.au/Products/632330/GeIL-8GB-Single-DDR4-Pristine-C19-2666MHz) > + if 8GB RAM is not enough, 16GB DDR4-2666 modules can be found for $220 (https://www.ple.com.au/Products/628441/GeIL-16GB-Kit-2x8GB-DDR4-EVO-X-RGB-LED-C16-2400MHz) however this > has the potential to go over-budget > * 500GB SSD - $170 (https://www.ple.com.au/Products/630702/Crucial-MX500-500GB-SATA-25-7mm-SSD) > * Power supply - use existing > * Graphics card - use existing > * Case - use existing > > Total cost for this build should be around $700, within the budget as proposed in the minutes here. > > Please provide feedback on any cost-saving measures, missing components, if this is under or over specced etc. > > - [FVP] > > > From frekk at ucc.asn.au Wed Aug 29 08:48:56 2018 From: frekk at ucc.asn.au (Felix von Perger) Date: Wed, 29 Aug 2018 08:48:56 +0800 Subject: [tech] Tech Talks Message-ID: <0fd1d824-a02e-7d12-42e7-7fb9bd2b4b03@ucc.asn.au> Hi all! We are hoping to run some more tech talks this semester and thus we are looking for people who would be interested in presenting tech talks or running workshops about something computer science or electronics related for the UCC. The last tech workshop which was successfully run was [GOZ]'s Learn2Linux & Intro to C at the beginning of Semester 1. Suggested topics include: * CAD / Blender tutorials (ie. for 3D printing) * Programming tutorials o Unity (C#/Javascript) o Arduino o Web development o or even PLC programming? * Linux basics * Cryptography / computer security * Lockpicking * Networking (IPv4/6 etc.) Please let me (or committee at ucc.asn.au) know if you are interested, all suggestions are welcome! Best regards, Felix von Perger [FVP] UCC Secretary -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20180829/beded619/attachment.htm From oxinabox at ucc.asn.au Wed Aug 29 09:39:20 2018 From: oxinabox at ucc.asn.au (Lyndon White) Date: Wed, 29 Aug 2018 09:39:20 +0800 Subject: [tech] Tech Talks In-Reply-To: <0fd1d824-a02e-7d12-42e7-7fb9bd2b4b03@ucc.asn.au> Message-ID: <8ef9f3cf-65c9-4ca6-bad4-a9fb61cfb25a@email.android.com> An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20180829/71229670/attachment.htm From ganhua.luo at research.uwa.edu.au Wed Aug 29 09:08:35 2018 From: ganhua.luo at research.uwa.edu.au (Ganhua Luo) Date: Wed, 29 Aug 2018 09:08:35 +0800 Subject: [tech] Enquiry on ipv6 Message-ID: Hi, UCCer, Could you help me to have access to ipv6 network. Is there any convenient place to make that happen. -- Kind Regards Ganhua Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20180829/c8c0e68e/attachment.htm From alastair at ucc.gu.uwa.edu.au Thu Aug 30 22:25:13 2018 From: alastair at ucc.gu.uwa.edu.au (Alastair Irvine) Date: Thu, 30 Aug 2018 22:25:13 +0800 Subject: [tech] Tech Talks In-Reply-To: <0fd1d824-a02e-7d12-42e7-7fb9bd2b4b03@ucc.asn.au> References: <0fd1d824-a02e-7d12-42e7-7fb9bd2b4b03@ucc.asn.au> Message-ID: <20180830142513.dp5mmupjso3aawi3@ucc.gu.uwa.edu.au> On Wed, 29 August, 2018 at 08:48:56AM +0800, Felix von Perger wrote: > Hi all! > > We are hoping to run some more tech talks this semester and thus we are > looking for people who would be interested in presenting tech talks or > running workshops about something computer science or electronics related > for the UCC. The last tech workshop which was successfully run was [GOZ]'s > Learn2Linux & Intro to C at the beginning of Semester 1. I can do an into to Python talk. Or I could do a more advanced talk including wheel packages and 2/3 differences. Late Oct/early Nov preferred. -- ... Who can I blame for my own problems? Give me just a minute . . . I'll find someone. _____________________________________________________________________ | | | -=*Alastair Irvine*=- | | C-monkey/wanderer/board&RPGer MSN/gtalk: unixnut at gmail.com | | Open Source zealot (Linux Counter user #404151) ICQ#: 213191007 | |_____________________________________________________________________| From zanchey at ucc.gu.uwa.edu.au Fri Aug 31 00:04:42 2018 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Fri, 31 Aug 2018 00:04:42 +0800 (AWST) Subject: [tech] Enquiry on ipv6 In-Reply-To: References: Message-ID: On Wed, 29 Aug 2018, Ganhua Luo wrote: > Hi, UCCer, > Could you help me to have access to ipv6 network. Is there any convenient > place to make that happen. Hi Ganhua We offer IPv6 connectivity to all our users via the UCC clubroom and through our VPNs. Our IPv6 transit is provided by UWA, so depending on which faculty/school you are with they may be able to provide you access. Is there something in particular you're trying to achieve with IPv6? David Adam zanchey at ucc.gu.uwa.edu.au