BALUG-Talk

balug-talk@lists.balug.org

138 discussions

letsencrypt.org wildcard SSL/TLS certs available, now covering balug.org, ... :-)
by Michael Paoli 17 Mar '18

17 Mar '18

Letsencrypt.org recently started making production wildcard certs available. https://community.letsencrypt.org/t/acme-v2-production-environment-wildcard… Now also covering balug.org :-) (and sf-lug.org, sf-lug.com) $ TZ=GMT0 nmap -6 -Pn -r -sT -p 443 --script=ssl-cert www.balug.org | egrep -e '^(Nmap scan report for |Other addresses for |\| (ssl-cert: Subj|Subject Alt|Not valid a))' Nmap scan report for www.balug.org (2001:470:1f05:19e::2) Other addresses for www.balug.org (not scanned): 198.144.194.238 | ssl-cert: Subject: commonName=*.balug.org | Subject Alternative Name: DNS:*.archive.balug.org, DNS:*.balug.org, DNS:*.beta.balug.org, DNS:*.ipv4.balug.org, DNS:*.ipv6.balug.org, DNS:*.new.balug.org, DNS:*.php.test.balug.org, DNS:*.secure.balug.org, DNS:*.test.balug.org, DNS:*.wiki.balug.org, DNS:balug.org | Not valid after: 2018-06-15T07:39:09 $

1 0

Last month's meeting: Perky Planck Prototype (PPLP) - home-brew implementation of the Perky Planck, an open source, blind-optimized portable computer, ...
by Michael Paoli 19 Feb '18

19 Feb '18

Last month's meeting was well attended, many interesting discussions, and we also had developer of the Perky Planck Prototype (PPLP) - home-brew implementation of the Perky Planck, an open source, blind-optimized portable computer, complete with prototype at the meeting, etc. http://wiki.cfcl.com/Projects/Perky/PPLP

1 1

BIOS zapping bug: Ubuntu 17.10 / *buntu 17.10
by Michael Paoli 22 Dec '17

22 Dec '17

Generally not advised to install Ubuntu 17.10 presently, at least on certain hardware. There's a nasty bug that causes serious problems with BIOS (as in prevents ability to boot from USB or alter BIOS settings). https://www.theregister.co.uk/2017/12/21/ubuntu_lenovo_bios/ https://linux.slashdot.org/story/17/12/20/1724244/ubuntu-1710-temporarily-p… etc. Canonical apparently plans to re-release 17.10 (hopefully with a distinguishing point version number?) after this issue is corrected.

3 2

BALUG email is up again (was down 2017-11-30), balug VM updated, ...
by Michael Paoli 02 Dec '17

02 Dec '17

BALUG email was down on 2017-11-30, it's back up again. Sorry for any inconvenience. I may put more details on relevant BALUG list(s) sometime later. In the meantime, for the interested/curious, see: http://linuxmafia.com/pipermail/sf-lug/2017q4/013009.html And as for the balug VM (which hosts most everything BALUG), on 2017-11-30 it was updated from: Debian GNU/Linux 8.9 (jessie) x86_64 (oldstable) to: Debian GNU/Linux 9.2 (stretch) x86_64 (stable) excepting for the (non-Debian caused) email glitch, all went quite smoothly and service interruption was quite minimal. Key among minimizing service downtime in general, under: https://www.debian.org/releases/stretch/amd64/release-notes/ch-upgrading.en… followed the procedures for: "If the system being upgraded provides critical services for your users or the network[2], you can reduce the downtime if you" ... and additionally, obtained/downloaded all needed packages in advance. E.g.: # apt-get -y -d upgrade; apt-get -y -d dist-upgrade ... and that was after pre-filling cache (/var/cache/apt/archives/) with .deb packages I already had (from earlier downloads of package(s) and/or on Debian ISO(s)).

1 0

(forw) [svlug-announce] SVLUG Nov. 1st meeting: Rob Walker on MythTV and Kodi Lecture and Demo
by Rick Moen 31 Oct '17

31 Oct '17

Come if you can, as this should be a really good one. ----- Forwarded message from Rick Moen <rick(a)linuxmafia.com> ----- Date: Tue, 31 Oct 2017 14:20:59 -0700 From: Rick Moen <rick(a)linuxmafia.com> To: svlug-announce(a)lists.svlug.org Subject: [svlug-announce] SVLUG Nov. 1st meeting: Rob Walker on MythTV and Kodi Lecture and Demo WHEN: Wednesday, November 1st, 2017 7 - 8:30pm MAIN PRESENTATION TOPIC: MythTV and Kodi Lecture and Demo PRESENTED BY: Rob Walker TOPIC SUMMARY: MythTV (https://www.mythtv.org/) is a free and open source software digital video recorder (DVR) project, distributed under the terms of the GNU GPL. Kodi (https://kodi.tv/ , formerly XBMC) is a free and open source media player application developed by the XBMC/Kodi Foundation, a non-profit technology consortium. Rob will demonstrate his MythTV and Kodi setup, and show how he's been using it over the years. ABOUT THE PRESENTER: Rob Walker was introduced to Unix in 1995 has been using Linux since 1997. He has helped other people use Linux at companies like VA Research, Silver Spring Networks, and others. He has been using MythTV off and on since 2006, and Kodi since 2014. LOCATION: Cavium cafeteria 2315 N 1st St. (corner of Charcut Ave.) north San Jose Directions on how to get there are listed at: http://www.svlug.org/directions/cavium.php <--- maps here! We've tried our very best for these directions to be accurate. If you have any improvements to make, please let SVLUG's volunteers know! webmaster(a)svlug.org POST-MEETING GATHERING (if you want): La Victoria Taqueria, 1415 N 4th St. near Gish Road, San Jose. Go south 0.7 miles on N. 1st St. under US-101, then turn half-left onto Matrix Blvd., in 0.3 miles a slight right onto N. 4th Street, 0.5 miles to La Victoria on your right just before Gish Road. We look forward to seeing you there! _______________________________________________ svlug-announce mailing list svlug-announce(a)lists.svlug.org http://lists.svlug.org/lists/listinfo/svlug-announce ----- End forwarded message -----

1 0

operation appears to have been a success: hardware issues
by Michael Paoli 31 Oct '17

31 Oct '17

Ah, and appears the operation has been quite successful ... the "patient" got a body transplant, and is doing much better now. Essentially brain of patient (~150 GB SSD) was successfully transplanted out of ailing body (Zareason Strata 6880) into apparently good healthy donor body (Dell P10E001 Precision M6600). Also completed successful live migration of the balug VM back from physical host "vicki" ... which nominally resides under the brain of the patient, but was live-migrated away to "vicki" while the patient's brain was in suspended animation for a while during the patient's operation. More later, but thus far all looking quite well. :-) Also, before the operation, the donor body was well prepped, with a BIOS upgrade - notably covering some critical Intel vulnerabilities, and had been reasonably tested to apparently be suitably healthy donor. Some slight adjustments to /etc/udev/rules.d/70-persistent-net.rules were made to squash any transplant rejection symptoms, and all is looking quite well. > From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > To: "Rick Moen" <rick(a)linuxmafia.com> > Cc: BALUG-Admin <balug-admin(a)lists.balug.org> > Subject: Re: [BALUG-Admin] (forw) [Bug 1707447] Re: Roster should > not lowercase addresses > Date: Thu, 26 Oct 2017 22:34:36 -0700 > In the meantime ... I've also got some hardware issues pestering > me :-/ ... my primary personal laptop ... alas, my last response I > got from Zareason was essentially it's "too old" for them to get > parts (and it's not *all* that old) ... and also one significant > part of the (potential) repair ... well, if part can no longer > be had (GPU/video integrated onto mainboard) - that's effectively > irreparable - even if part was available, it's not economically > feasible. The *first* mainboard failed with GPU failure not long > after the 1 year warranty (at least I think it was before the 2 year > mark). I'm not sinkin' that kind'a money into it yet again if that > manufacturer's (it's an Intel OEM laptop) hardware - or at least for > that particular mainboard and compoenents thereupon, is that unreliable. > At the *moment* the video is working, ... but often when the laptop is > rebooted or powered up ... the video doesn't work (can only > barely/marginally make out / guess what's on the screen when it's > flaking out ... and not OS or the like - the problem even applies to > BIOS screens). So ... that issue bit me again this morning, and took > until many reboots this evening before the video is displaying again > properly ... for now. Not to mention ... keyboard ... both "N" and "O" > keys failed ... and that's 2nd keyboard on the laptop ... using external > USB keyboard on it now. But I did pick up for excellent price > (free, "miracle of the free curbside giveaway") a Dell P10E ... which > as far as I've seen thus far (still need to check it out further) appears > to be fine, and is a good approximate replacement (even better in several > ways - includes eSATA, 4 USB ports (1 more than existing laptop), supports > two internal regular laptop SATA drives (spinning rust and/or SSD) ... > anyway, I'll probably cover more of that else-thread (and/or else-list) > in fairly near future ... but if that hardware checks out good, I'm > exceedingly inclined to move over to that laptop. > But I digress (ah, topic drift) ...

2 4

Join me at the Roguelike Celebration (and watch a live nethack speed run)
by Asheesh Laroia 22 Oct '17

22 Oct '17

Hi BALUG-talk! I’m Asheesh, long-time BALUG member. I’ve been volunteering with friends to organize a conference about roguelike video games. Do you want to attend? Some interesting facts about the conference and roguelike games: - These are games where you explore a virtual world, created uniquely (“procedurally”) every time you play. - Early ones, including famous ones like nethack, are purely command line-oriented. - Last year, one of the conference swag items was socks. :) - Our audience is people who enjoy playing the games, rather than technical talks for game developers. You can see that in the speaker lineup! - It’s Nov 11 & 12, and our website is here: https://roguelike.club/ - There will be a live “speed run” of nethack, in which Adeon tries to play this multi-day game in just two hours. - And we use a Let’s Encrypt certificate :) I’d love to see BALUG folks at the conference. I’m happy to answer questions about the conference if people have them! Asheesh.

1 0

http[s]://{www., }{, ipv[46].}balug.org/{myip, srcip, myconnection, *}
by Michael Paoli 07 Oct '17

07 Oct '17

Not for high-volume use, not a high availability nor high bandwidth service, but ... http[s]://{www,}{,.ipv[46]}.balug.org/{myip,srcip,myconnection,*} Want to know your (Internet) source IP address ... for IPv4?: $ curl https://www.ipv4.balug.org/myip 198.144.194.235 $ IPv6?: $ curl https://www.ipv6.balug.org/myip 2001:470:66:76f::2 $ What about source IP and port, and likewise for target: $ curl https://www.ipv6.balug.org/myconnection 2001:470:66:76f::2 50265 2001:470:1f04:19e::2 443 $ Anyway, (notably not that balug.org is also off of DreamHost.com, yay!) implemented similar for BALUG what I'd earlier implemented for SF-LUG with those URLs. If one uses, e.g.: https://www.balug.org/myip one may connect and see IPv4, or IPv6 IP (server is dual stack). $ wget -4 -q -O - https://www.balug.org/myip 198.144.194.235 $ wget -6 -q -O - https://www.balug.org/myip 2001:470:66:76f::2 $ The URLs with ipv4 or ipv6 in the host (DNS) name are *only* IPv4 or IPv6, respectively. That can be handy when, e.g. one has a client where one can't (feasibly) tell the client to only use IPv4 or IPv6. Can also use http instead of https (and will all the further lack of assurances on http with the traffic then in the clear). And balug ... one less character to type than sf-lug. ;-) references/excerpts: > From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > To: SF-LUG <sf-lug(a)linuxmafia.com> > Subject: > http[s]://{www,}{,.ipv[46]}.sf-lug.org/{myip,srcip,myconnection,*} > ... m-net.arbornet.org > Date: Thu, 22 Jun 2017 06:58:06 -0700 > Now also working with https, > and also handy URL portions ending with /myip, /srcip, /myconnection, > e.g.: > $ curl -s https://www.ipv4.sf-lug.org/myip > 99.95.107.156 > $ curl -s https://www.ipv4.sf-lug.org/myconnection > 99.95.107.156 64316 198.144.194.238 443 > $ curl -s https://www.ipv6.sf-lug.org/srcip > 2001:470:66:76f::2 > $ curl -s http://www.ipv6.sf-lug.org/myconnection > 2001:470:66:76f::2 40862 2001:470:1f04:19e::2 80 > $ > (/myip and /srcip are equivalent) > Some of those may be particularly useful when you're behind > layer(s) of NAT/SNAT, and also, as essentially noted earlier, > if/when you want to explicitly check IPv4 or IPv6 - particularly > if you're using a client that one can't (reasonably) specify > which protocol on the client itself (e.g. mobile browser on > "smartphone"). > >> From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > To: SF-LUG <sf-lug(a)linuxmafia.com> >> Subject: http://www.ipv4.sf-lug.org/ http://ipv4.sf-lug.org/ >> Date: Sun, 18 Jun 2017 14:16:13 -0700 > >> And for those that may find it useful, >> if/when you want/need to hit only IPv4, I've also added: >> http://www.ipv4.sf-lug.org/ >> http://ipv4.sf-lug.org/ >> With the former of those two being the canonical form. >> >> So long as you don't have need/reason to restrict to IPv4 only, >> should just use the canonical form: >> http://www.sf-lug.org/ >> or >> https://www.sf-lug.org/ >> >> One can also often restrict to just IPv4 or IPv6 with >> the client ... but not all clients offer such an option >> (e.g. dual stack mobile device may not offer such an option). >> >> What about?: >> https://www.ipv4.sf-lug.org/ >> https://ipv4.sf-lug.org/ >> I don't have corresponding cert added yet, but expect >> I'll have that completed before 2016-08-20T01:30:00+0000. >> Until I add such cert, they "work" - notwihstanding cert >> not having those newer names included. >> >> I didn't add similar for .com, as it's non-canonical anyway. >> >>> Date: Tue, 01 Dec 2015 17:33:28 -0800 >>> From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> >>> To: SF-LUG <sf-lug(a)linuxmafia.com> >>> Subject: [www.]ipv6.sf-lug.{org,com} [Re: SF-LUG & IPv6 :-)] >>> >>> And for those that may be interested, curious, or might find it useful, >>> if one accesses the sf-lug website via any of these DNS names in the URLs: >>> http://www.ipv6.sf-lug.org/ >>> http://ipv6.sf-lug.org/ >>> http://www.ipv6.sf-lug.com/ >>> http://ipv6.sf-lug.com/ >>> One gets IPv6 only access to the site (it won't work if you don't >>> have IPv6). >>> Same content, just alternatives names (with the "ipv6." portion added) >>> to access via IPv6 only if/when one may want to do or test that. >>> If one doesn't include the "ipv6." portion, the site has both IPv6 and >>> IPv4, so one doesn't have to use ipv6 names (unless one wants to exclude >>> IPv4). >>> >>> >>>> From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> >>>> Subject: SF-LUG & IPv6 :-) >>>> Date: Sat, 28 Nov 2015 11:29:32 -0800 >>> >>>> The SF-LUG websites >>>> http://([www.]sf-lug.{org,com}/ >>>> now also have IPv6. >>>> Do use the DNS names, as not only may IPv6 addresses change, >>>> but the web server also uses virtual name hosting, and presently >>>> hosts more than just >>>> SF-LUG content. >>>> >>>> Note that the list host (linuxmafia.com) does not (yet?) have IPv6. >>>> >>>> Also, many of the BALUG.org sites now have IPv6 (notably BALUG >>>> ancillary sites >>>> (e.g. archive & wiki sites), but not yet [www.]balug.org itself), >>>> but these don't >>>> yet have full chain of IPv6 DNS servers (alas, balug.org hosting >>>> provider has no >>>> IPv6 DNS servers).

1 0

Re: [BALUG-Talk] [BALUG-Admin] balug.org DNS review
by Michael Paoli 02 Oct '17

02 Oct '17

[moving this to BALUG-Talk - as at least my mostly general responses aren't really all that highly BALUG (admin) specific] Thanks for the excellent review! :-) Some comments, etc, in-line below: > From: "Rick Moen" <rick(a)linuxmafia.com> > Subject: [BALUG-Admin] balug.org DNS review > Date: Wed, 27 Sep 2017 09:25:12 -0700 > Just checking on things, in the wake of the departure from Dreamhost. Yea departing DreamHost.com!!! (A.k.a. nightmare host <sigh>). > 1. We have three nameservers. This is in the recommended range, > barely: RFC2182 section 5 recommends at least 3. RFC1912 section 2.8 > recommends no more than 7. > > If we have one or two more friends running auth nameservers, adding them > would be gravy. Or, ... even not bother a friend and ... There are some free/complementary DNS slave services out there for the taking by any and/or all ... most of 'em suck (perhaps some exceptions?) However, probably of note and worthy of consideration ... balug.org has registrar gandi ... gandi offers complimentary DNS slave services. Now, I wouldn't want to be (too) dependent upon any given registrar, but, as far as I'm aware and what I've seen thus far, gandi's DNS complimentary slave service is basically rock solid and good - only minor thing I've noticed is updates - it either ignores them, or takes some modest bit of time to process them. But it does fully respect the TTLs and relevant SOA times, so as far as I'm aware all is fully within required specifications. I do have at least one (other) domain that uses gandi slave DNS for *one* (and only one) of its slave DNS servers ... so again - not too much in the way of dependencies, and sufficiently easy to break free should there ever be need/reason. Another possible freebie worthy of considering - he.net - with account (which BALUG has, and uses for its IPv6 tunnel), complimentary DNS slave services are also offered. They seem to mostly/basically be quite "good", but come with a few caveats of note. They support *most* - but not *all* - RR types. So ... that's potentially an issue. As for updates, same kind of deal as gandi - except I think he.net explicitly ignores update notifications; but again, works fine regarding TTLs and SOA timing values. But a few more caveats for he.net free DNS. The setup is a bit funky - no way to introduce it without some DNS gotchas when being implemented. Notably (at last I futzed with it), one has to put the delegation in place *first* - so there will be some non-zero time when one has lame NS server(s) - basically after they're delegated, but before they pull and serve the zone data - and they won't pull and serve the zone data until their DNS data checks show that they're delegated - kind'a a Catch-22. Also, don't know that one can feasibly do less than *all* of he.net's DNS servers - they give you a set, they expect you to delegate to them. If they find you're not delegated to them, they drop the service. And ... is that an all or nothing? Doesn't seem to be specified in their documentation, so ... results of delegating less than the full set may be unspecified. *Other* than those few significant caveats, as far as I'm aware, their DNS slave service works perfectly fine - I had (maybe still have?) it on some domain(s) I dealt with. May have dropped it due to the particular limitations and such, though. Oh, and one other possible caveat ... been a while since I read their documents ... there *may* be some traffic limit/caveat? ... or maybe not - I don't recall, I'd have to look over their documentation again. Anyway, yes, those (gandi complimentary and he.net free) DNS slave services, have some potential issues/limitations to consider ... but to give 'em credit too, also have some advantages. Notably they are pretty darn high availability. So that's more than many can offer strung at home on the end of a DSL or cable line or such, or even some host - even if it's in a colo or cloud or the like - if it doesn't have a high availability partner. Then again, for the infrastructure much of such DNS supports, particularly high availability on the DNS can be overkill - when all the services themselves may not be that high in reliability/availability. But still - dang important to have good solid DNS ... as when *that* is down solid - clients on The Internet can't in general even find out that what they're trying to get to is up or down or what the status is, and this also tends to cause or further complicate issues with various services (e.g. SMTP, among others). So ... yes, ... adding a reasonably good reliable (needn't be super high on the reliability) DNS server would be a good thing, ... or more than one, up to total count of about 7 (precise maximum that's still optimal also depends upon the length of the domain name and some other DNS data factors ... e.g. optimal maximum for root (.) is a number larger than 7 ... but root domain (.) also has the shortest possible domain name. For domain names that are highly long, optimal maximum may be somewhat lower than 7 ... but 7 is optimal maximum for *most* typical domain names. > 2. No glue records for one nameserver (ns1.linuxmafia.com), because it > is out-of-bailiwick for the .org TLD nameservers. This means queries to > it are just a little slower than to the other two for which glue > information gets supplied. > > If you want to fix that, assign my nameserver IP (198.144.195.186) the > name NS2.BALUG.ORG in the domain record, removing the entry for > NS1.LINUXMAFIA.COM. That fixes the glue records at the parent (.org) zone. > And then don't forget to make the same switch in the in-zone records > served at master nameserver NS1.BALUG.ORG. Yes, thanks, noted ... will probably get around to that (time, priorities, that one is modest work for only slight/teensy gain ... so ... will likely take longer to get to it). > 3. Information leakage. NS1.BALUG.ORG / 198.144.194.238 answers > (correctly) CHAOS class queries about its version. > > :r! dig version.bind txt chaos @NS1.BALUG.ORG +short > "9.9.5-9+deb8u14-Debian" > > It'd be a good idea to turn this off. I like to return amusing lies, > myself. My stanza in /etc/bind/named.conf.options : > > options { > directory "/var/cache/bind"; > version "Shirley, you're joking"; > hostname "ns1.linuxmafia.com"; > //server-id is essentially redundant to hostname, default is none > //server-id none; > auth-nxdomain no; # conform to RFC1035 > allow-recursion { > [redacted] > }; > allow-query { > [redacted] > }; > dnssec-validation yes; > }; Ah yes. :-) "Of course", there's almost always tradeoffs regarding security. E.g. convenience/speed vs. ... well, security and some information not being so convenient/available. As for DNS server identifying its software/version ... what [il]legitimate uses for that? Well, there's negligible legitimate use, so general best practice is to disable that - or put in some bogus or intentionally misleading string. Legitimate uses of it being there? Mostly negligible ... but there are some slight ones. E.g. for local or secured environments/networks, can be useful/convenient. E.g. not much harm/risk exposing it on 127.0.0.1 and ::1. But ... open to The Internet ... makes it easier for bots/attackers to know the specific target software ... and thus more likely to be able to successfully attack. However, even if the information isn't made available, software can be probed/"fingerprinted", so even if the version information is disabled or altered, attackers may still figure out - if not precisely the target version - at least often approximately the target software and approximate version or some version range. So ... it's bit of tradeoff ... make the information (much) less accessible (or not) - and make attacker's challenge some fair bit more difficult (but not hugely more difficult). Oh, I did say some negligible legitimate uses ... even on The Internet - software surveys - those *can* be used for legitimate purposes. Can also be abused - particularly if the data isn't quickly rolled up into the aggregate, but hangs around (or leaks) with specific IPs and corresponding software information, etc. ... and especially if that is leaked or exposed in bulk. I'm also curious - and don't recall - been long time since I read about it ... txt chaos ... that mechanism was put in BIND many many moons ago. Is it entirely (or mostly) unique to BIND? ... in which case even serving up a "dummy" answer would identify it as some flavor of BIND server. Or ... has other DNS server software adopted that same mechanism for reporting version (most notably if it's in as a default - I think most DNS software can do class CHAOS, though probably almost nobody explicitly implements such). Anyway, depending on the various DNS server software behavior - it may be better to, if feasible, disable that response rather than just put in some dummy response. Anyway, ... I'm curious what current best practice is in that regard for DNS servers - and BIND DNS servers. And I don't think I've any issues with, e.g. disabling it. I think thus so far in my life I've used it one to perhaps a few times. It's a "feature" (offering up its software and version information via DNS query) which is of very close to zero legitimate usefulness.

3 16

scheduled sites outage TOMORROW: [*.]balug.org, [*.]sf-lug.{org, com}, ... >=2017-09-26T09-0700-->~=2017-09-26T15-0700
by Michael Paoli 25 Sep '17

25 Sep '17

As mentioned earlier on the BALUG-Admin list https://lists.balug.org/pipermail/balug-admin/2017-September/000910.html we're anticipating a scheduled sites outage tomorrow, sometime between 9:00 AM and approximately 3:00 PM. PDT. details/references: outage window: >=2017-09-26T09:00:00-0700-->~=2017-09-26T15:00:00-0700 reason: scheduled utility power outage site(s): balug.org - everything on/under that domain sf-lug.{org,com} - everything on/under those domains (does NOT include SF-LUG lists (hosted on linuxmafia.com)) mitigations/controls: Don't have operational UPS presently (even if I did, it probably wouldn't suffice for potential duration of outage). The impacted sites mentioned above are on virtual machine. Prior to outage, I'll (live) migrate that virtual machine onto physical machine that should be able to restart okay after drop of and restoration of power, and likewise virtual machine thereupon should automatically be restarted and recover fine too. With journaling filesystems and such, hopefully this will limit the outage to not much longer than the utility power outage itself. Even in "worst case", I expect sometime tomorrow after 3pm, should some manual intervention be needed, to have the sites up later in that day - I'll also have fresh image on another machine that won't be powering up/down with the utility power, so in all cases, the sites either will come back up, or I'll be able to bring it back up without too much difficulty. https://lists.balug.org/pipermail/balug-admin/2017-September/000910.html http://linuxmafia.com/pipermail/sf-lug/2017q3/012832.html > From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > To: BALUG-Admin <balug-admin(a)temp.balug.org> > Subject: scheduled sites outage: [*.]balug.org, [*.]sf-lug.org, ... > >=2017-09-26T09-0700-->~=2017-09-26T15-0700 > Date: Thu, 14 Sep 2017 19:36:09 -0700 > There's upcoming scheduled sites outage due to some > scheduled electric utility work. > > Scheduled outage window: >> =2017-09-26T09:00:00-0700-->~=2017-09-26T15:00:00-0700 > > sites impacted: > [*.]balug.org (note that it may or may not impact www.balug.org and > balug.org - depending where they are at that time, but will impact at > least all other *.balug.org sites/domains) > > [*.]sf-lug.{org,com} (note that SF-LUG list isn't impacted) > > To the extent feasible, I'll try to minimize the outage time, but > expect it may minimally be up to fair part of an hour, and > "worst case" might be 6 hours or more (notably also if I can > have things automagically recover easily enough unattended upon power > restoration - or not). > > It's also possible this outage may be delayed or rescheduled (notably > depending what electric utility provider gets up to).

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

BALUG-Talk