Re: pi.berkeleylug.com ... "Berkeley Pi" ... --> Pi.BerkeleyLUG ? :-)
15 views
Skip to first unread message
Michael Paoli
Jun 21, 2020, 2:09:20 PM6/21/20
to BerkeleyLUG
TLDR first, then rationale/"arguments"/alternatives/considerations.
TLDR: First conclusions/summary/recommendation/suggestions:
So ... what say/think ye all?
Pi.BerkeleyLUG for "branding", Subject:, WordPress page, etc.,
and describing (at least in part):
Pi.BerkeleyLUG is a Special Interest Group (SIG) of BerkeleyLUG.
And relevant redirects to canonical landing page (and with most of
them being case-insensitive on the matching):
{
http[s]://[www.]pi.berkeleylug.com/ (302 - excepting Pi SIG taking it
elsewhere)
http[s]://[www.]berkeleylug.com/pi[[-.]berkeley[lug]][/] (301)
} --> https://BerkeleyLUG.com/Pi.BerkeleyLUG/
... even virtual meet URLs for the SIG could likewise
where/as feasible use URLs ending in /Pi.BerkeleyLUG[/]
So ... I was thinking ... insofar as "Berkeley Pi" - or whatever we
want to call it, continues to use/share BerkeleyLUG.com resources -
and I've no problem with that :-) ...
I was thinking ...
For ease/aid in "branding" / naming / identification, etc.,
it might be best if we agree upon a common way of naming/identifying.
So, we do have available (even if it's not been pressed into use yet)
subdomain pi.berkeleylug.com - that can be pressed into use at most
any time - the DNS infrastructure, sudoers, etc. is pretty much all
there - just would need to add the host login account(s)
(actually just added a piberk utility/role account, but
individual account(s) would be added too) and add said account(s) to
already fully tested sudo capability - then said accounts can fully
manage pi.berkeleylug.com DNS under existing BerkeleyLUG.com DNS
infrastructure - both add/drop/change pi.berkeleylug.com and/or any
subdomains (e.g. www.pi.berkeleylug.com) thereunder, either directly
using BerkeleyLUG.com existing NS infrastructure, or even NS (and DS if
DNSSEC desired) delegating such. Hmmm, heck, Pi.BerkeleyLUG SIG could
even use such account(s) (notably piberk) to have crontab job(s) that
would revert to WordPress page when [www.]pi.berkeleylug.com was
otherwise offline. Then Raspberry Pi based host & web server could
use ssh to update and change DNS to use itself as web server when it was
up and on-line, again leveraging such account(s).
So, there's that ... there's also relevant web page(s) (mostly
notwithstanding the above), and list(s).
Let's start with web page(s)(/site(s)).
It's good for (Linux) User Groups ([L]UGs) to have their own
web site - or at least web page - and/or list(s) ... though those aren't
absolute hard-and-fast requirements. "Berkeley Pi" (or whatever we want
to call it) may be considered a Special Interest Group (SIG) or subgroup
of BerkeleyLUG (there's also how we refer to it in that regard - but
more on that in a bit). Doesn't mean "Berkeley Pi" can't also or
eventually split off into its own totally separate thing and resources
nor preclude it from doing so ... or not so split off. But most notably
at least "in the meantime" (and if it ever does fully split off - for
relevant pointers/referrals - notably since it (essentially?) started
within BerkeleyLUG), would be good to have some relevant location(s)
on BerkeleyLUG about or referring/pointing to "Berkeley Pi".
So, along those lines, I was thinking, already have the
https://berkeleylug.com/ web site, it would be good to create a page on
there for "Berkeley Pi". I/we might have to poke at the existing
(WordPress) site a bit on naming conventions and such,
but we might want to create a page such as:
https://berkeleylug.com/BerkeleyPi or
https://berkeleylug.com/pi.berkeleylug or
https://berkeleylug.com/Pi or the like.
Not sure about case sensitivity (or not) on such with WordPress,
but some added web server redirects could ensure various possible
alternatives/variations all would get (presumably 301) redirected to
some suitable "Berkeley Pi" landing page, such as:
https://berkeleylug.com/BerkeleyPi or
https://berkeleylug.com/pi.berkeleylug
If/once we agreed upon something like that, and set up such a page,
then also, the relevant WordPress editors(+) (there are at least a few
or so of us thus far, we can always add more) could also maintain such
page. That would also give "Berkeley Pi" a consistent canonical
web presence/page/URL to refer to, pass along to folks, etc.
Also, I might suggest "pi.berkeleylug" - or alternatively "BerkeleyPi"
over "Berkeley Pi". Why? Notably URLs and DNS and the like -
a space character is more problematic/annoying - sure, can be escaped
for web, but makes less user-friendly URLs, so without space may
be better. Space would also be a no-go on DNS domain. And, if one went
with pi.berkeleylug, e.g.
https://berkeleylug.com/pi.berkeleylug
that could then also be (relatively) consistent with any DNS use
of pi.berkeleylug.com
And why not instead:
https://berkeleylug.com/pi.berkeleylug.com
? Because I don't think the ".com" part is all that
important as part of the "branding" and such. Besides, too,
if "Berkeley Pi" ever split off into its own totally separate
thing, it might prefer/choose a TLD that's not under com.
So ... I was thinking - and along with that - list(s) and Subject:
headers in lists. I think standardizing on "Berkeley Pi" is (/has been)
a good start - notably so long as is still using the same "list"
(Google Group) ... and at least thus far using same "list" is
probably better than not (has advantages, and I've heard no serious
objections to such thus far).
However, to be (more) consistent with web landing page(s),
potential DNS addition(s) (pi.berkeleylug.com), etc.,
may be more advantageous to standardize on pi.berkeleylug[.com] ...
or use of pi.berkeleylug AND BerkeleyPi ... though, I'm thinking
perhaps the latter of using BOTH might be bit more confusing (and,
especially longer term) may "dilute" recognition/identification
more so than just using one single uniform common string,
namely pi.berkeleylug - and presuming WordPress also works with . in
page name ... well, let me test that out ...
Ah ...
well ... WordPress squashes the . to -, so we end up with:
https://berkeleylug.com/pi-berkeleylug/
However, if I use URL:
https://berkeleylug.com/pi.berkeleylug/
I get the same page/content, and WordPress doesn't redirect to:
https://berkeleylug.com/pi-berkeleylug/
So ... I could probably set up redirect so the canonical would be:
https://berkeleylug.com/pi.berkeleylug/
and accessing:
https://berkeleylug.com/pi-berkeleylug/
would redirect to:
https://berkeleylug.com/pi.berkeleylug/
Looks like the only place where I may not be able to make it:
https://berkeleylug.com/pi.berkeleylug/
instead of:
https://berkeleylug.com/pi-berkeleylug/
is the automagically created WordPress links to the pages, where
it links it to/as:
https://berkeleylug.com/pi-berkeleylug/
... but again, should still be able to set that up to redirect to:
https://berkeleylug.com/pi.berkeleylug/
So, the canonical could be:
https://berkeleylug.com/pi.berkeleylug/
Or could possibly, to avoid - vs. . issues totally there, instead use:
https://berkeleylug.com/pi/
Also, on the WordPress pages, if one omits the trailing /,
WordPress automagically redirects to add it.
Also, on the matter of web pages & DNS,
at least until such time as "Berkeley Pi" sets up any of its own
web server infrastructure, once we have an agreed upon "landing"
page on WordPress, I could always drop infrastructure in place on
web server (and relevant DNS entries), so that
http[s]://[www.]pi.berkeleylug.com/ would (302?) redirect to
the "Berkeley Pi" WordPress landing page.
"Of course" folks having access to update pi.berkeleylug.com DNS
could always change that at any time, but they could also use it as
a fall-back - e.g. if/when [www.]pi.berkeleylug isn't available or
won't be available for a while as its own (Raspberry Pi based! :-))
web server, could just drop the [www.]pi.berkeleylug DNS entry(/ies)
back in place that would hit the berkeleylug.com web server,
and that could then recognize the domain name matches and redirect to
the "Berkeley Pi" WordPress landing page.
And "list"(s) ( / Google Group(s)). I've zero objections to continuing
to use/share the BerkeleyLUG "list" also for "Berkeley Pi" stuff :-)
and may very well continue to be more advantageous and desirable than
not. :-)
However, ... "branding", ease of use, filtering, tagging, etc.
Would be good to standardize on contents of Subject: header for
"Berkeley Pi" stuff. Having noted issues with space character -
notably for URLs, perhaps best to go with something not containing
space character ... that would also likely work better and more
consistently for folks automagically filtering/tagging/sorting/searching
email ... e.g. if someone put multiple spaces, or spaces and/or tabs,
rather than exactly and only one single space. So, without space is
likely to be more goof-resistant and give better more consistent
results. And I think a mere "pi" alone would be too short and may give
false positives on matches. So, probably something much more like
"pi.berkeleylug" or "BerkeleyPi" (and probably case insensitive
would be best for matching purposes, but may want to have
something case-sensitive as canonical for general identification
style, e.g. "Pi.BerkeleyLUG" or "BerkeleyPi".
Anyway, curious what folks think/suggest/recommend.
I'm thinking perhaps best to use "Pi.BerkeleyLUG" throughout,
at least to the extent feasible - then that could be quite consistent
and recognizable, easy to filter on, would match to DNS (at least
portion thereof), etc.
Now, the WordPress wouldn't quite 100% fully match
that, but could come highly close, e.g.:
https://BerkeleyLUG.com/Pi.BerkeleyLUG/
as the (mostly) canonical landing page,
and could also have relevant redirects to get one relatively
consistently to there, e.g.:
{
http[s]://[www.]pi.berkeleylug.com/ (302 - excepting Pi SIG taking it
elsewhere)
http[s]://[www.]berkeleylug.com/pi[[-.]berkeley[lug]][/] (301)
} --> https://BerkeleyLUG.com/Pi.BerkeleyLUG/
... and WordPress mostly doesn't care,
e.g. with
https://berkeleylug.com/pi-berkeleylug/
in place:
https://berkeleylug.com/Pi.BerkeleyLUG/
serves up that same content and doesn't redirect (but we could
probably make it redirect if we wanted it to,
within reason picking whichever we want to redirect to as that
canonical form).
Special Interest Group (SIG) / subgroup.
I'm thinking perhaps, at least so long as it doesn't spit off into
it's own totally separate group and resources, etc.,
we call "Berkeley Pi" (or Pi.BerkeleyLUG) a Special Interest Group (SIG)
of BerkeleyLUG. I think in the general context, SIG is more generally
recognized, and more concise, than "subgroup". And probably less
confusing if we have a consistent way of saying what "Berkeley Pi"
(or Pi.BerkeleyLUG) is.
E.g. describing (at least in part) Pi.BerkeleyLUG as:
Pi.BerkeleyLUG is a Special Interest Group (SIG) of BerkeleyLUG.
Anyway, makes it clear and concise (and not at all unprecedented,
even in the realm of [L]UGs, e.g. BayLISA is a SIG of LISA,
there was a "monitoring" SIG that met in San Francisco (was a SIG
supported/sponsored by Untangle.com). And, comparatively, I don't think
I've heard such more typically referred to as "subgroup" so I'm thinking
SIG would likely be the preferred term. And at conferences,
Birds-of-a-Feather (BoF) or SIG sessions/meetings are common, but not
referred to as "subgroups".)
So, what say y'all? :-) (and have a peek again at the "TLDR" at the
top).
references/excerpts:
nsupdate(1)
https://www.balug.org/~piberk/bin/Nsupdate
$ id; hostname; date -Iseconds
uid=24567(piberk) gid=24567(piberk) groups=24567(piberk)
balug-sf-lug-v2.balug.org
2020-06-21T14:24:54+00:00
$ cat ~/bin/Nsupdate
#!/bin/sh
sudo -g bind /usr/bin/nsupdate -l -k
/var/cache/bind/keys/ddns-key.pi.berkeleylug.com
$ sudo -l | fgrep nsupdate
(piberk : bind) NOPASSWD: /usr/bin/nsupdate -l -k
/var/cache/bind/keys/ddns-key.pi.berkeleylug.com
$ dig +short berkeleylug.com. SOA | awk '{print $1;}'
ns0.berkeleylug.com.
$ dig +short berkeleylug.com. NS | fgrep -i ns0.berkeleylug.com.
ns0.berkeleylug.com.
$ dig @ns0.berkeleylug.com. +norecurse pi.berkeleylug.com. A | fgrep NX
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17880
$ Nsupdate << \__EOT__
> update add pi.berkeleylug.com. 300 IN A 127.0.0.1
> update add www.pi.berkeleylug.com. 300 IN A 127.0.0.1
> send
> __EOT__
$ dig +noall +answer +nottl pi.berkeleylug.com. A www.pi.berkeleylug.com. A
pi.berkeleylug.com. IN A 127.0.0.1
www.pi.berkeleylug.com. IN A 127.0.0.1
$ Nsupdate << \__EOT__
> update del pi.berkeleylug.com. IN A
> update del www.pi.berkeleylug.com. IN A
> send
> __EOT__
$ dig @ns0.berkeleylug.com. +norecurse pi.berkeleylug.com. A | fgrep NX
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7726
$
> Date: Wed, 29 Apr 2020 21:31:24 -0700
> From: "Michael Paoli" <Michae...@cal.berkeley.edu>
> To: "tom r lopes" <tomr...@gmail.com>
> Cc: BerkeleyLUG <berke...@googlegroups.com>
> Subject: Re: pi.berkeleylug.com
> Thomas,
>
> Whenever you wish to proceed ... or have some other/additional
> [pi.]BerkeleyLUG.com folk(s) you may wish to have run with this ...
>
> Anyway, the basic infrastructure for DNS is there - just set up
> you (or whomever(s)) with (ssh) login account, add the (already
> tested) sudo access, then one can do pretty arbitrary things in
> DNS with pi.berkelelylug.com (and any subdomains thereunder),
> all utilizing the existing DNS infrastructure (master and slaves).
> Also have TLS(/"SSL") CA cert for
> *.pi.berkelelylug.com,pi.berkeleylug.com ... no real skin off my nose to
> also get such, as I earlier very highly automated my
> letsencrypt cert request/validate/obtain procedure - so again have such
> a cert (essentially obtain all my new certs pretty much at the same
> time ... just one extra CLI argument to also request and get the
> *.pi.berkelelylug.com,pi.berkeleylug.com
> cert - all very automated).
> Anyway, do also have that if it might be of use ... "of course" with the
> DNS control, one could always use that oneself for validation on
> requesting and obtaining such certs (and including any subdomains anywhere
> under pi.berkeleylug.com, and any wildcards under such). Anyway, just let
> me know when you'd like to proceed on that.
>
> https://lists.balug.org/pipermail/balug-talk/2020-April/000205.html
>
>> From: "Michael Paoli" <Michae...@cal.berkeley.edu>
>> Subject: Re: DNS Dynamic Update: Re: pi.berkeleylug.com.? :-) (cert, ...)
>> Date: Mon, 24 Feb 2020 02:26:32 -0800
>
>> Thomas,
>>
>> Whenever you're ready, we can proceed ... is bit beyond "proof of concept"
>> for dynamic DNS updates for [[*.]pi.]berkeleylug.com.
>>
>> Would just need to coordinate to set up account for you,
>> and add the relevant sudo bits - then would be all set to go.
>>
>> Demo bits (presently active on test account):
>>
>> $ hostname; id -nu; sudo -l | sed -ne '/may run/,$p'
>> balug-sf-lug-v2.balug.org
>> test
>> User test may run the following commands on balug-sf-lug-v2:
>> (test : bind) NOPASSWD: /usr/bin/nsupdate -l -k
>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>> $
>>
>> Via that key and sudo access, the account (presently test account),
>> has access/permissions to do DNS changes to [*.]pi.berkeleylug.com.
>> (the whole berkeleylug.com domain now is set up to be able to use
>> dynamic DNS updates, there are no delegated subdomains,
>> pi.berkeleleylug.com. subdomain, and any subdomains thereof,
>> would remain in the berkeleylug.com zone ... and hence also
>> benefit from its existing master and slave DNS servers, etc.)
>>
>> So, ... example bits. Also, at least from the master, all are allowed
>> to do AXFR, so anyone can pull the whole DNS zone's data.
>>
>> First, lets's see what we have for pi.berkeleylug.com.,
>> first we peek at SOA and NS records for berkeleylug.com.:
>>
>> $ dig +noall +answer +nottl berkeleylug.com. SOA berkeleylug.com. NS
>> berkeleylug.com. IN SOA ns0.berkeleylug.com.
>> Michael\.Paoli.cal.berkeley.edu. 1582499043 10800 3600 3600000 86400
>> berkeleylug.com. IN NS ns1.linuxmafia.com.
>> berkeleylug.com. IN NS ns1.svlug.org.
>> berkeleylug.com. IN NS ns0.berkeleylug.com.
>> $
>>
>> We can see from the above, in the SOA, the MNAME is ns0.berkeleylug.com.,
>> that would customarily be the DNS origin/master, and in this case is in
>> fact so, and we can also see it listed among the NS records.
>> We can also lookup the corresponding IPs, if we need that (may
>> change, ... but not frequently, and should be able to use the MNAME
>> name in DNS queries as server):
>>
>> $ dig +noall +answer +nottl ns0.berkeleylug.com. A ns0.berkeleylug.com. AAAA
>> ns0.berkeleylug.com. IN A 96.86.170.229
>> ns0.berkeleylug.com. IN AAAA 2001:470:1f05:19e::4
>> $
>>
>> And, let's see what (if any) pi.berkeleylug.com. DNS records exist:
>> $ dig @ns0.berkeleylug.com. +noall +answer berkeleylug.com. AXFR |
>>> fgrep -i pi.berkeleylug.com || echo NO MATCHES FOUND
>> NO MATCHES FOUND
>> $
>>
>> Let's add some!
>>
>> $ echo 'update add pi.berkeleylug.com. 300 IN A 127.0.0.1
>>> update add pi.berkeleylug.com. 300 IN AAAA ::1
>>> update add www.pi.berkeleylug.com. 300 IN A 127.0.0.1
>>> update add www.pi.berkeleylug.com. 300 IN AAAA ::1
>>> send' |
>>> sudo -g bind nsupdate -l -k \
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>> $
>>
>> And see what we got!:
>> $ dig @ns0.berkeleylug.com. +noall +answer berkeleylug.com. AXFR |
>>> fgrep -i pi.berkeleylug.com.
>> ns0.berkeleylug.com. 86400 IN NSEC pi.berkeleylug.com.
>> A AAAA RRSIG NSEC
>> pi.berkeleylug.com. 86400 IN RRSIG NSEC 8 3 86400
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> UFpBZWUm3bcYmPuwe2NagMVCMCVu9xuq0CT9HPPOlIanpw08Ll5j1Cip
>> V+3hKcnaYJ1qFMhMaN3YCSAnZxRx2t9VsJj6+RQDsLL/RkzbpViI8UVw
>> BPm9Lh4LXSmdwtGMoHjNAKzqO9fN7HDF522vuLKNJkwiPC0EW1253mHn 3aU=
>> pi.berkeleylug.com. 86400 IN NSEC
>> www.pi.berkeleylug.com. A AAAA RRSIG NSEC
>> pi.berkeleylug.com. 300 IN RRSIG A 8 3 300
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> DaedpxA29N8Q0/EgAGI/coYp9uQntzpw+LT9zQ/fSHODO8X2bC3IOYGI
>> NaCCB53v5ineCukWIMZ1BeenO7iHUO9DMP6+LZ/1J+noMQvXwrj1/LMQ
>> ReKGMhRsWgVZ2Zkz07YB31BOUyZw5Xw5+gScPkx6xU6wQ8EdPdQ+g1C+ UOg=
>> pi.berkeleylug.com. 300 IN RRSIG AAAA 8 3 300
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> Y+MHMHYLtVMv63qYkIZSgA+9VO3oBH6ZGtpetkqDcLft164bh+VOdC3q
>> txA0GgOhsulqLHKIkITsfX5ERYjKQwy62kP5rNjFddDrldcsULGhQqeO
>> lN5sT+P3WvOrAGOeSo22SxI1IGwSfi6NDftuHbXI/aVGBHDMvkz9wGYC lFM=
>> pi.berkeleylug.com. 300 IN AAAA ::1
>> pi.berkeleylug.com. 300 IN A 127.0.0.1
>> www.pi.berkeleylug.com. 86400 IN RRSIG NSEC 8 4 86400
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> JcrifwAnynq3elpDhRmx9QKc/68VECmfeDpCN582dr9HJTLrhrcr0CTh
>> ZHH7gsnz0Jd0GjosEfdvRS/PG6qrA9DDJQbAJZNVJ0ifebVrQ+o/POpK
>> j+VtGRw4VY1EQ+1JrEk7QJlA8HK9uFGi95iZ3xQOzicPfuU9NyQm9rBF WG4=
>> www.pi.berkeleylug.com. 86400 IN NSEC www.berkeleylug.com.
>> A AAAA RRSIG NSEC
>> www.pi.berkeleylug.com. 300 IN RRSIG A 8 4 300
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> NjIvNubS7KbdtJVoQb27JQanq3YUV5Fwvevoj2FkTdWhrcvv8+wspiPT
>> QHAjcf3O3ghDmSEx5OmgVYPE7ocx4VkAZrViWGN1HOcGgzTvEEndMrdb
>> Xc1j9SnQcFIkYjtDDrTUgTuIiJUknL8j2gjQDAe9tn7KeNBmI+0EwyO8 Zr8=
>> www.pi.berkeleylug.com. 300 IN RRSIG AAAA 8 4 300
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> deQEW1SyOXpGR2i/GJMF5MEBK3haYbq5Qq5QoJbbA5I5/GvlraNMTZHW
>> e1O4XONQxSKFWRv0cZE3qMCFt0pTImVorU+quViugzgwGGNhFdYTMQNh
>> df1WAKS6bWHkHKU8KvCFvL+sute/9KUfRWGYdOWc/lWds5L2673psmKu Ay8=
>> www.pi.berkeleylug.com. 300 IN AAAA ::1
>> www.pi.berkeleylug.com. 300 IN A 127.0.0.1
>> $
>> And, there one can see, the added records (NSEC and RRSIG are
>> automatically added as part of the configured DNSSEC).
>>
>> And likewise, if we remove them
>> $ echo 'update delete pi.berkeleylug.com. IN A
>>> update delete pi.berkeleylug.com. IN AAAA
>>> update delete www.pi.berkeleylug.com. IN A
>>> update delete www.pi.berkeleylug.com. IN AAAA
>>> send' |
>>> sudo -g bind nsupdate -l -k \
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>> $
>>
>> We then see that the records are gone:
>>
>> $ dig @ns0.berkeleylug.com. +noall +answer berkeleylug.com. AXFR |
>>> fgrep -i pi.berkeleylug.com. || echo NO MATCHES FOUND
>> NO MATCHES FOUND
>> $
>>
>> Including the removal of the related NSEC and RRSIG records that our
>> DNSSEC configuration had automatically added.
>>
>> And if we try something else in the zone in DNS:
>>
>> $ echo 'update add foobarbaznotallowed.berkeleylug.com. 300 IN A 127.0.0.1
>>> send' |
>>> sudo -g bind nsupdate -l -k \
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>> update failed: REFUSED
>> $
>>
>> That fails, as it doesn't match what our configuration allows
>> by use of that key. In relevant part from our configuration:
>> update-policy {
>> grant ddns-key.pi.berkeleylug.com subdomain pi.berkeleylug.com.;
>> };
>>
>> Oh, also, 86400 (from SOA we showed earlier) is the
>> MINIMUM Negative Cache TTL value for the zone,
>> it's "global" for the zone, can't set that differently for
>> Resource Records (RRs) within. So, to avoid long negative caching,
>> may want to leave at least some record - e.g. a TXT record may suffice,
>> and leave that, thus response won't be an NXDOMAIN, which may be cached
>> up to 86400 (seconds - one day)
>> per MINIMUM Negative Cache TTL value for the zone.
>>
>>> From: "Michael Paoli" <Michae...@cal.berkeley.edu>
>>> Subject: DNS Dynamic Update: Re: pi.berkeleylug.com.? :-) (cert, ...)
>>> Date: Wed, 12 Feb 2020 15:37:23 -0800
>>
>>> So ... [*.]pi.berkeleylug.com and DNS Dynamic updates ...
>>>
>>> Have basic proof-of-concept operational.
>>> And using, for now, a temporary delegated subdomain:
>>> tmp202002.berkeleylug.com.
>>> The "real deal" would use berkeleylug.com.
>>> Otherwise, relatively similar.
>>> So ... subdomain thereof (pi), and Dynamic Updates to that
>>> (and subdomains thereof), but not other DNS data in the zone.
>>> Essentially implemented. Little mini-demo below:
>>>
>>> $ hostname; id; sudo -l | sed -ne '/^User [^ ]* may run/,$p'
>>> balug-sf-lug-v2.balug.org
>>> uid=25322(test) gid=25322(test) groups=25322(test)
>>> User test may run the following commands on balug-sf-lug-v2:
>>> (test : bind) NOPASSWD: /usr/bin/nsupdate -l -k
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>>> $
>>>
>>> So, on the DNS master (host balug-sf-lug-v2.balug.org, this is the
>>> balug Virtual Machine) that also hosts BerkeleyLUG.{com,org}.
>>>
>>> Have a test user set up (can likewise delegate to relevant users as
>>> applicable), and has sudo access set up as seen above, notably:
>>> (test : bind) NOPASSWD: /usr/bin/nsupdate -l -k
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>>> And if user forgets what commands, easy:
>>> $ sudo -l
>>> And they'll be displayed (handy reminder).
>>> So, with the indicated sudo access, we can see that user test can
>>> run the command as group bind.
>>>
>>> Below, we can see the desired records aren't yet present:
>>> $ dig +noall +answer pi.tmp202002.berkeleylug.com. A
>>> www.pi.tmp202002.berkeleylug.com. A
>>> $
>>>
>>> And then user test uses, in this case echo,
>>> to feed the desired data into sudo which in turn runs the nsupdate
>>> command as group bind:
>>> $ echo -e 'update add pi.tmp202002.berkeleylug.com. 300 A
>>> 1.2.3.4\nupdate add www.pi.tmp202002.berkeleylug.com. 300 A
>>> 1.2.3.4\nsend' | sudo -g bind nsupdate -l -k
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>>> $
>>>
>>> We can then see the desired records are present:
>>> $ dig +noall +answer pi.tmp202002.berkeleylug.com. A
>>> www.pi.tmp202002.berkeleylug.com. A
>>> pi.tmp202002.berkeleylug.com. 300 IN A 1.2.3.4
>>> www.pi.tmp202002.berkeleylug.com. 300 IN A 1.2.3.4
>>> $
>>>
>>> Likewise, this user can remove these records (in fact has,
>>> via sudo and that key, permissions to change essentially any DNS
>>> data for pi.tmp202002.berkeleylug.com. and any subdomains thereof):
>>> $ echo -e 'update delete www.pi.tmp202002.berkeleylug.com.\nupdate
>>> delete pi.tmp202002.berkeleylug.com.\nsend' | sudo -g bind nsupdate
>>> -l -k /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>>> $
>>>
>>> And after that, we can see that the removal was processed and those
>>> records are gone:
>>> $ dig +noall +answer pi.tmp202002.berkeleylug.com. A
>>> www.pi.tmp202002.berkeleylug.com. A
>>> $
>>>
>>> We can also see that our user can't change other data in the zone:
>>> $ echo -e 'update add not-allowed.tmp202002.berkeleylug.com. 300 A
>>> 1.2.3.4\nsend' | sudo -g bind nsupdate -l -k
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>>> update failed: REFUSED
>>> $
>>>
>>>> From: "Michael Paoli" <Michae...@cal.berkeley.edu>
>>>> Subject: DNS Dynamic Update: Re: pi.berkeleylug.com.? :-) (cert, ...)
>>>> Date: Mon, 10 Feb 2020 01:05:01 -0800
>>>
>>>> A little bit closer.
>>>>
>>>> So, thing I'd been thinking about and started (test)
>>>> implementation of at BerkeleLUG yesterday (Sunday) ...
>>>> with the (proposed) Raspberry Pi, not having static IPv4
>>>> address, having a means to updated it ([*.]pi.berkeleylug.com)
>>>> in DNS. Ah, thinks I, ... Dynamic Update. That and some
>>>> suitable sudoers(5) entries, and that should then cover it,
>>>> allowing client to update its DNS.
>>>>
>>>> Delegating subdomain (pi.berkeleylug.com) would be more work than
>>>> it would be worth (would need to arrange slaves, etc.), so idea
>>>> is [*.]pi.berkeleylug.com would be in same zone.
>>>> sudoers(5) and/or configuration of Dynamic Updated would be
>>>> used to suitably restrict authorized client to only update
>>>> [*.]pi.berkeleylug.com DNS data.
>>>>
>>>> But ... for initial testing, easier to start with a
>>>> delegated subdomain (easier to test that Dynamics won't
>>>> change data where they're not supposed to) ... once all is
>>>> well tested and configured and such, can apply that to the
>>>> berkeleylug.com zone - with suitable restrictions to
>>>> [*.]pi.berkeleylug.com DNS data.
>>>>
>>>> So, for test zone ... tmp202002.berkeleylug.com.
>>>> And why such a zone? Well, won't later conflict with
>>>> [*.]pi.berkeleylug.com - even if some remnant data hangs out
>>>> for a while (in caches or whatever). Also, I wanted to
>>>> do DNSSEC with it to (as is already the case with
>>>> berkeleylug.com) ... got that covered and validated,
>>>> and with DNSSEC, best practice with (ZSK) key rotation is
>>>> (about) monthly ... already have that covered. But along with
>>>> that, don't want older or possibly conflicting keys hanging
>>>> out too long. Hence, for testing now, separate delegated
>>>> sub-domain, that doesn't conflict, and is quite clearly
>>>> intended to be temporary.
>>>>
>>>> Oh, and since it's just for proof-of-concept / testing, and
>>>> nothin' all that important at the moment ... who needs slaves?
>>>> (yeah, I know, RFCs 'n all that, but for a who cares throwaway
>>>> anyway ...).
>>>> So, DNSSEC ... done: Try this also for a nice view thereof:
>>>> https://dnsviz.net/d/tmp202002.berkeleylug.com/dnssec/
>>>> And of course:
>>>> $ delv tmp202002.berkeleylug.com. SOA +multiline
>>>> ; fully validated
>>>> tmp202002.berkeleylug.com. 291 IN SOA
>>>> ns0.tmp202002.berkeleylug.com. Michael\.Paoli.cal.berkeley.edu. (
>>>> 1581288117 ; serial
>>>> 3600 ; refresh (1 hour)
>>>> 1200 ; retry (20 minutes)
>>>> 604800 ; expire (1 week)
>>>> 180 ; minimum (3 minutes)
>>>> )
>>>> tmp202002.berkeleylug.com. 291 IN RRSIG SOA 8 3 300 (
>>>> 20200311085137 20200210075137 6543
>>>> tmp202002.berkeleylug.com.
>>>> Ub0l4cQnPmt47MvguwCW1YHztF6CpWGksWl6MYHiYDgs
>>>> y3kiyOMAvGd2hmOwQMbU2NndI9DTpfn9iYycxKFZcjP3
>>>> VTPUD/7iKa7yXXvVq+G81q2YfJx7Aqxe0yczCAG+8G0j
>>>> 0Ui3oYdxb2ZxmqT7b8cVRdDAZ9DwUHkRjgWCvjs= )
>>>> $
>>>>
>>>> And ... Dynamic Update, yep, have that implemented too:
>>>> $ dig +noall +answer www.tmp202002.berkeleylug.com. A
>>>> www.tmp202002.berkeleylug.com. AAAA
>>>> www.tmp202002.berkeleylug.com. 300 IN A 96.86.170.229
>>>> www.tmp202002.berkeleylug.com. 300 IN AAAA 2001:470:1f05:19e::4
>>>> # echo -e 'update del www.tmp202002.berkeleylug.com.
>>>> update add www.tmp202002.berkeleylug.com. 300 A
>>>> 10.9.8.7update add www.tmp202002.berkeleylug.com. 300 AAAA
>>>> 2001:470:1f05:19e:babe:face:deaf:beef
>>>> update add
>>>> www.tmp202002.berkeleylug.com. 300 AAAA
>>>> 2001:470:1f05:19e:beef:face:deaf:babe
>>>> update add
>>>> www.tmp202002.berkeleylug.com. 300 AAAA
>>>> 2001:470:1f05:19e:feed:babe:dead:beef
>>>> send' | nsupdate -l
>>>> #
>>>> $ dig +noall +answer www.tmp202002.berkeleylug.com. A
>>>> www.tmp202002.berkeleylug.
>>>> com. AAAA
>>>> www.tmp202002.berkeleylug.com. 300 IN A 10.9.8.7
>>>> www.tmp202002.berkeleylug.com. 300 IN AAAA
>>>> 2001:470:1f05:19e:beef:face:deaf:babe
>>>> www.tmp202002.berkeleylug.com. 300 IN AAAA
>>>> 2001:470:1f05:19e:feed:babe:dead:beef
>>>> www.tmp202002.berkeleylug.com. 300 IN AAAA
>>>> 2001:470:1f05:19e:babe:face:deaf:beef
>>>> $
>>>>
>>>>> From: "Michael Paoli" <Michae...@cal.berkeley.edu>
>>>>> Subject: pi.berkeleylug.com.? :-) (cert, ...)
>>>>> Date: Sat, 01 Feb 2020 09:30:22 -0800
>>>>
>>>>> Tom,
>>>>>
>>>>> Per our earlier communications:
>>>>>
>>>>> Let me know when you check if you can have open TCP ports
>>>>> 80 & 443 with your ISP on IPv4 (and also, if applicable/available,
>>>>> IPv6).
>>>>>
>>>>> We could then:
>>>>> set up page, likely:
>>>>> https://berkeleylug.com/pi/
>>>>> On the BerkeleyLUG web site.
>>>>> And could then also include link(s) from there to:
>>>>> http[s]://[www.]pi.berkeleylug.com/
>>>>> I could also work on setting up dynamic DNS on
>>>>> berkeleylug.com
>>>>> and account and suitable access, so you'd be able to change DNS
>>>>> for [*.]pi.berkeleylug.com.
>>>>>
>>>>> Oh, and do also have TLS(/"SSL") cert ready for you - if you wish
>>>>> to use it, and when we have secure means to transfer key (e.g. via
>>>>> aforementioned above account and ssh/scp/sftp):
>>>>> Not Before: Feb 1 15:32:20 2020 GMT
>>>>> Not After : May 1 15:32:20 2020 GMT
>>>>> Subject: CN = *.pi.berkeleylug.com
>>>>> *.pi.berkeleylug.com,pi.berkeleylug.com
>>>>> I use letsencrypt.org, and generally get new certs a bit
>>>>> more frequently than every 90 days (since they expire after 90 days).
>>>>> Anyway, got such cert covering the above
>>>>> (Subject Alternative Name (SAN) & wildcard)
>>>>> so that would suffice to cover not only
>>>>> pi.berkeleylug.com, but also any subdomain directly thereunder, e.g.:
>>>>> www.pi.berkeleylug.com
>>>>> And you could decide what you'd want the canonical to be
>>>>> (with or without leading www., and https, or http).
>>>>> Anyway, not much extra work for me to obtain such cert when I
>>>>> do all my others (for efficiency, I grab 'em all right around the
>>>>> same time, so all the expirations are fairly closely aligned, and
>>>>> then I effectively process 'em all as a (sequential) "batch",
>>>>> bit more frequent than once every 90 days ... then generally no
>>>>> other such certs to muck with in the time between).
>>>>>
>>>>> see also:
>>>>> http://linuxmafia.com/pipermail/conspire/2020-January/date.html
TLDR: First conclusions/summary/recommendation/suggestions:
So ... what say/think ye all?
Pi.BerkeleyLUG for "branding", Subject:, WordPress page, etc.,
and describing (at least in part):
Pi.BerkeleyLUG is a Special Interest Group (SIG) of BerkeleyLUG.
And relevant redirects to canonical landing page (and with most of
them being case-insensitive on the matching):
{
http[s]://[www.]pi.berkeleylug.com/ (302 - excepting Pi SIG taking it
elsewhere)
http[s]://[www.]berkeleylug.com/pi[[-.]berkeley[lug]][/] (301)
} --> https://BerkeleyLUG.com/Pi.BerkeleyLUG/
... even virtual meet URLs for the SIG could likewise
where/as feasible use URLs ending in /Pi.BerkeleyLUG[/]
So ... I was thinking ... insofar as "Berkeley Pi" - or whatever we
want to call it, continues to use/share BerkeleyLUG.com resources -
and I've no problem with that :-) ...
I was thinking ...
For ease/aid in "branding" / naming / identification, etc.,
it might be best if we agree upon a common way of naming/identifying.
So, we do have available (even if it's not been pressed into use yet)
subdomain pi.berkeleylug.com - that can be pressed into use at most
any time - the DNS infrastructure, sudoers, etc. is pretty much all
there - just would need to add the host login account(s)
(actually just added a piberk utility/role account, but
individual account(s) would be added too) and add said account(s) to
already fully tested sudo capability - then said accounts can fully
manage pi.berkeleylug.com DNS under existing BerkeleyLUG.com DNS
infrastructure - both add/drop/change pi.berkeleylug.com and/or any
subdomains (e.g. www.pi.berkeleylug.com) thereunder, either directly
using BerkeleyLUG.com existing NS infrastructure, or even NS (and DS if
DNSSEC desired) delegating such. Hmmm, heck, Pi.BerkeleyLUG SIG could
even use such account(s) (notably piberk) to have crontab job(s) that
would revert to WordPress page when [www.]pi.berkeleylug.com was
otherwise offline. Then Raspberry Pi based host & web server could
use ssh to update and change DNS to use itself as web server when it was
up and on-line, again leveraging such account(s).
So, there's that ... there's also relevant web page(s) (mostly
notwithstanding the above), and list(s).
Let's start with web page(s)(/site(s)).
It's good for (Linux) User Groups ([L]UGs) to have their own
web site - or at least web page - and/or list(s) ... though those aren't
absolute hard-and-fast requirements. "Berkeley Pi" (or whatever we want
to call it) may be considered a Special Interest Group (SIG) or subgroup
of BerkeleyLUG (there's also how we refer to it in that regard - but
more on that in a bit). Doesn't mean "Berkeley Pi" can't also or
eventually split off into its own totally separate thing and resources
nor preclude it from doing so ... or not so split off. But most notably
at least "in the meantime" (and if it ever does fully split off - for
relevant pointers/referrals - notably since it (essentially?) started
within BerkeleyLUG), would be good to have some relevant location(s)
on BerkeleyLUG about or referring/pointing to "Berkeley Pi".
So, along those lines, I was thinking, already have the
https://berkeleylug.com/ web site, it would be good to create a page on
there for "Berkeley Pi". I/we might have to poke at the existing
(WordPress) site a bit on naming conventions and such,
but we might want to create a page such as:
https://berkeleylug.com/BerkeleyPi or
https://berkeleylug.com/pi.berkeleylug or
https://berkeleylug.com/Pi or the like.
Not sure about case sensitivity (or not) on such with WordPress,
but some added web server redirects could ensure various possible
alternatives/variations all would get (presumably 301) redirected to
some suitable "Berkeley Pi" landing page, such as:
https://berkeleylug.com/BerkeleyPi or
https://berkeleylug.com/pi.berkeleylug
If/once we agreed upon something like that, and set up such a page,
then also, the relevant WordPress editors(+) (there are at least a few
or so of us thus far, we can always add more) could also maintain such
page. That would also give "Berkeley Pi" a consistent canonical
web presence/page/URL to refer to, pass along to folks, etc.
Also, I might suggest "pi.berkeleylug" - or alternatively "BerkeleyPi"
over "Berkeley Pi". Why? Notably URLs and DNS and the like -
a space character is more problematic/annoying - sure, can be escaped
for web, but makes less user-friendly URLs, so without space may
be better. Space would also be a no-go on DNS domain. And, if one went
with pi.berkeleylug, e.g.
https://berkeleylug.com/pi.berkeleylug
that could then also be (relatively) consistent with any DNS use
of pi.berkeleylug.com
And why not instead:
https://berkeleylug.com/pi.berkeleylug.com
? Because I don't think the ".com" part is all that
important as part of the "branding" and such. Besides, too,
if "Berkeley Pi" ever split off into its own totally separate
thing, it might prefer/choose a TLD that's not under com.
So ... I was thinking - and along with that - list(s) and Subject:
headers in lists. I think standardizing on "Berkeley Pi" is (/has been)
a good start - notably so long as is still using the same "list"
(Google Group) ... and at least thus far using same "list" is
probably better than not (has advantages, and I've heard no serious
objections to such thus far).
However, to be (more) consistent with web landing page(s),
potential DNS addition(s) (pi.berkeleylug.com), etc.,
may be more advantageous to standardize on pi.berkeleylug[.com] ...
or use of pi.berkeleylug AND BerkeleyPi ... though, I'm thinking
perhaps the latter of using BOTH might be bit more confusing (and,
especially longer term) may "dilute" recognition/identification
more so than just using one single uniform common string,
namely pi.berkeleylug - and presuming WordPress also works with . in
page name ... well, let me test that out ...
Ah ...
well ... WordPress squashes the . to -, so we end up with:
https://berkeleylug.com/pi-berkeleylug/
However, if I use URL:
https://berkeleylug.com/pi.berkeleylug/
I get the same page/content, and WordPress doesn't redirect to:
https://berkeleylug.com/pi-berkeleylug/
So ... I could probably set up redirect so the canonical would be:
https://berkeleylug.com/pi.berkeleylug/
and accessing:
https://berkeleylug.com/pi-berkeleylug/
would redirect to:
https://berkeleylug.com/pi.berkeleylug/
Looks like the only place where I may not be able to make it:
https://berkeleylug.com/pi.berkeleylug/
instead of:
https://berkeleylug.com/pi-berkeleylug/
is the automagically created WordPress links to the pages, where
it links it to/as:
https://berkeleylug.com/pi-berkeleylug/
... but again, should still be able to set that up to redirect to:
https://berkeleylug.com/pi.berkeleylug/
So, the canonical could be:
https://berkeleylug.com/pi.berkeleylug/
Or could possibly, to avoid - vs. . issues totally there, instead use:
https://berkeleylug.com/pi/
Also, on the WordPress pages, if one omits the trailing /,
WordPress automagically redirects to add it.
Also, on the matter of web pages & DNS,
at least until such time as "Berkeley Pi" sets up any of its own
web server infrastructure, once we have an agreed upon "landing"
page on WordPress, I could always drop infrastructure in place on
web server (and relevant DNS entries), so that
http[s]://[www.]pi.berkeleylug.com/ would (302?) redirect to
the "Berkeley Pi" WordPress landing page.
"Of course" folks having access to update pi.berkeleylug.com DNS
could always change that at any time, but they could also use it as
a fall-back - e.g. if/when [www.]pi.berkeleylug isn't available or
won't be available for a while as its own (Raspberry Pi based! :-))
web server, could just drop the [www.]pi.berkeleylug DNS entry(/ies)
back in place that would hit the berkeleylug.com web server,
and that could then recognize the domain name matches and redirect to
the "Berkeley Pi" WordPress landing page.
And "list"(s) ( / Google Group(s)). I've zero objections to continuing
to use/share the BerkeleyLUG "list" also for "Berkeley Pi" stuff :-)
and may very well continue to be more advantageous and desirable than
not. :-)
However, ... "branding", ease of use, filtering, tagging, etc.
Would be good to standardize on contents of Subject: header for
"Berkeley Pi" stuff. Having noted issues with space character -
notably for URLs, perhaps best to go with something not containing
space character ... that would also likely work better and more
consistently for folks automagically filtering/tagging/sorting/searching
email ... e.g. if someone put multiple spaces, or spaces and/or tabs,
rather than exactly and only one single space. So, without space is
likely to be more goof-resistant and give better more consistent
results. And I think a mere "pi" alone would be too short and may give
false positives on matches. So, probably something much more like
"pi.berkeleylug" or "BerkeleyPi" (and probably case insensitive
would be best for matching purposes, but may want to have
something case-sensitive as canonical for general identification
style, e.g. "Pi.BerkeleyLUG" or "BerkeleyPi".
Anyway, curious what folks think/suggest/recommend.
I'm thinking perhaps best to use "Pi.BerkeleyLUG" throughout,
at least to the extent feasible - then that could be quite consistent
and recognizable, easy to filter on, would match to DNS (at least
portion thereof), etc.
Now, the WordPress wouldn't quite 100% fully match
that, but could come highly close, e.g.:
https://BerkeleyLUG.com/Pi.BerkeleyLUG/
as the (mostly) canonical landing page,
and could also have relevant redirects to get one relatively
consistently to there, e.g.:
{
http[s]://[www.]pi.berkeleylug.com/ (302 - excepting Pi SIG taking it
elsewhere)
http[s]://[www.]berkeleylug.com/pi[[-.]berkeley[lug]][/] (301)
} --> https://BerkeleyLUG.com/Pi.BerkeleyLUG/
... and WordPress mostly doesn't care,
e.g. with
https://berkeleylug.com/pi-berkeleylug/
in place:
https://berkeleylug.com/Pi.BerkeleyLUG/
serves up that same content and doesn't redirect (but we could
probably make it redirect if we wanted it to,
within reason picking whichever we want to redirect to as that
canonical form).
Special Interest Group (SIG) / subgroup.
I'm thinking perhaps, at least so long as it doesn't spit off into
it's own totally separate group and resources, etc.,
we call "Berkeley Pi" (or Pi.BerkeleyLUG) a Special Interest Group (SIG)
of BerkeleyLUG. I think in the general context, SIG is more generally
recognized, and more concise, than "subgroup". And probably less
confusing if we have a consistent way of saying what "Berkeley Pi"
(or Pi.BerkeleyLUG) is.
E.g. describing (at least in part) Pi.BerkeleyLUG as:
Pi.BerkeleyLUG is a Special Interest Group (SIG) of BerkeleyLUG.
Anyway, makes it clear and concise (and not at all unprecedented,
even in the realm of [L]UGs, e.g. BayLISA is a SIG of LISA,
there was a "monitoring" SIG that met in San Francisco (was a SIG
supported/sponsored by Untangle.com). And, comparatively, I don't think
I've heard such more typically referred to as "subgroup" so I'm thinking
SIG would likely be the preferred term. And at conferences,
Birds-of-a-Feather (BoF) or SIG sessions/meetings are common, but not
referred to as "subgroups".)
So, what say y'all? :-) (and have a peek again at the "TLDR" at the
top).
references/excerpts:
nsupdate(1)
https://www.balug.org/~piberk/bin/Nsupdate
$ id; hostname; date -Iseconds
uid=24567(piberk) gid=24567(piberk) groups=24567(piberk)
balug-sf-lug-v2.balug.org
2020-06-21T14:24:54+00:00
$ cat ~/bin/Nsupdate
#!/bin/sh
sudo -g bind /usr/bin/nsupdate -l -k
/var/cache/bind/keys/ddns-key.pi.berkeleylug.com
$ sudo -l | fgrep nsupdate
(piberk : bind) NOPASSWD: /usr/bin/nsupdate -l -k
/var/cache/bind/keys/ddns-key.pi.berkeleylug.com
$ dig +short berkeleylug.com. SOA | awk '{print $1;}'
ns0.berkeleylug.com.
$ dig +short berkeleylug.com. NS | fgrep -i ns0.berkeleylug.com.
ns0.berkeleylug.com.
$ dig @ns0.berkeleylug.com. +norecurse pi.berkeleylug.com. A | fgrep NX
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17880
$ Nsupdate << \__EOT__
> update add pi.berkeleylug.com. 300 IN A 127.0.0.1
> update add www.pi.berkeleylug.com. 300 IN A 127.0.0.1
> send
> __EOT__
$ dig +noall +answer +nottl pi.berkeleylug.com. A www.pi.berkeleylug.com. A
pi.berkeleylug.com. IN A 127.0.0.1
www.pi.berkeleylug.com. IN A 127.0.0.1
$ Nsupdate << \__EOT__
> update del pi.berkeleylug.com. IN A
> update del www.pi.berkeleylug.com. IN A
> send
> __EOT__
$ dig @ns0.berkeleylug.com. +norecurse pi.berkeleylug.com. A | fgrep NX
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7726
$
> Date: Wed, 29 Apr 2020 21:31:24 -0700
> From: "Michael Paoli" <Michae...@cal.berkeley.edu>
> To: "tom r lopes" <tomr...@gmail.com>
> Cc: BerkeleyLUG <berke...@googlegroups.com>
> Subject: Re: pi.berkeleylug.com
> Thomas,
>
> Whenever you wish to proceed ... or have some other/additional
> [pi.]BerkeleyLUG.com folk(s) you may wish to have run with this ...
>
> Anyway, the basic infrastructure for DNS is there - just set up
> you (or whomever(s)) with (ssh) login account, add the (already
> tested) sudo access, then one can do pretty arbitrary things in
> DNS with pi.berkelelylug.com (and any subdomains thereunder),
> all utilizing the existing DNS infrastructure (master and slaves).
> Also have TLS(/"SSL") CA cert for
> *.pi.berkelelylug.com,pi.berkeleylug.com ... no real skin off my nose to
> also get such, as I earlier very highly automated my
> letsencrypt cert request/validate/obtain procedure - so again have such
> a cert (essentially obtain all my new certs pretty much at the same
> time ... just one extra CLI argument to also request and get the
> *.pi.berkelelylug.com,pi.berkeleylug.com
> cert - all very automated).
> Anyway, do also have that if it might be of use ... "of course" with the
> DNS control, one could always use that oneself for validation on
> requesting and obtaining such certs (and including any subdomains anywhere
> under pi.berkeleylug.com, and any wildcards under such). Anyway, just let
> me know when you'd like to proceed on that.
>
> https://lists.balug.org/pipermail/balug-talk/2020-April/000205.html
>
>> From: "Michael Paoli" <Michae...@cal.berkeley.edu>
>> Subject: Re: DNS Dynamic Update: Re: pi.berkeleylug.com.? :-) (cert, ...)
>> Date: Mon, 24 Feb 2020 02:26:32 -0800
>
>> Thomas,
>>
>> Whenever you're ready, we can proceed ... is bit beyond "proof of concept"
>> for dynamic DNS updates for [[*.]pi.]berkeleylug.com.
>>
>> Would just need to coordinate to set up account for you,
>> and add the relevant sudo bits - then would be all set to go.
>>
>> Demo bits (presently active on test account):
>>
>> $ hostname; id -nu; sudo -l | sed -ne '/may run/,$p'
>> balug-sf-lug-v2.balug.org
>> test
>> User test may run the following commands on balug-sf-lug-v2:
>> (test : bind) NOPASSWD: /usr/bin/nsupdate -l -k
>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>> $
>>
>> Via that key and sudo access, the account (presently test account),
>> has access/permissions to do DNS changes to [*.]pi.berkeleylug.com.
>> (the whole berkeleylug.com domain now is set up to be able to use
>> dynamic DNS updates, there are no delegated subdomains,
>> pi.berkeleleylug.com. subdomain, and any subdomains thereof,
>> would remain in the berkeleylug.com zone ... and hence also
>> benefit from its existing master and slave DNS servers, etc.)
>>
>> So, ... example bits. Also, at least from the master, all are allowed
>> to do AXFR, so anyone can pull the whole DNS zone's data.
>>
>> First, lets's see what we have for pi.berkeleylug.com.,
>> first we peek at SOA and NS records for berkeleylug.com.:
>>
>> $ dig +noall +answer +nottl berkeleylug.com. SOA berkeleylug.com. NS
>> berkeleylug.com. IN SOA ns0.berkeleylug.com.
>> Michael\.Paoli.cal.berkeley.edu. 1582499043 10800 3600 3600000 86400
>> berkeleylug.com. IN NS ns1.linuxmafia.com.
>> berkeleylug.com. IN NS ns1.svlug.org.
>> berkeleylug.com. IN NS ns0.berkeleylug.com.
>> $
>>
>> We can see from the above, in the SOA, the MNAME is ns0.berkeleylug.com.,
>> that would customarily be the DNS origin/master, and in this case is in
>> fact so, and we can also see it listed among the NS records.
>> We can also lookup the corresponding IPs, if we need that (may
>> change, ... but not frequently, and should be able to use the MNAME
>> name in DNS queries as server):
>>
>> $ dig +noall +answer +nottl ns0.berkeleylug.com. A ns0.berkeleylug.com. AAAA
>> ns0.berkeleylug.com. IN A 96.86.170.229
>> ns0.berkeleylug.com. IN AAAA 2001:470:1f05:19e::4
>> $
>>
>> And, let's see what (if any) pi.berkeleylug.com. DNS records exist:
>> $ dig @ns0.berkeleylug.com. +noall +answer berkeleylug.com. AXFR |
>>> fgrep -i pi.berkeleylug.com || echo NO MATCHES FOUND
>> NO MATCHES FOUND
>> $
>>
>> Let's add some!
>>
>> $ echo 'update add pi.berkeleylug.com. 300 IN A 127.0.0.1
>>> update add pi.berkeleylug.com. 300 IN AAAA ::1
>>> update add www.pi.berkeleylug.com. 300 IN A 127.0.0.1
>>> update add www.pi.berkeleylug.com. 300 IN AAAA ::1
>>> send' |
>>> sudo -g bind nsupdate -l -k \
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>> $
>>
>> And see what we got!:
>> $ dig @ns0.berkeleylug.com. +noall +answer berkeleylug.com. AXFR |
>>> fgrep -i pi.berkeleylug.com.
>> ns0.berkeleylug.com. 86400 IN NSEC pi.berkeleylug.com.
>> A AAAA RRSIG NSEC
>> pi.berkeleylug.com. 86400 IN RRSIG NSEC 8 3 86400
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> UFpBZWUm3bcYmPuwe2NagMVCMCVu9xuq0CT9HPPOlIanpw08Ll5j1Cip
>> V+3hKcnaYJ1qFMhMaN3YCSAnZxRx2t9VsJj6+RQDsLL/RkzbpViI8UVw
>> BPm9Lh4LXSmdwtGMoHjNAKzqO9fN7HDF522vuLKNJkwiPC0EW1253mHn 3aU=
>> pi.berkeleylug.com. 86400 IN NSEC
>> www.pi.berkeleylug.com. A AAAA RRSIG NSEC
>> pi.berkeleylug.com. 300 IN RRSIG A 8 3 300
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> DaedpxA29N8Q0/EgAGI/coYp9uQntzpw+LT9zQ/fSHODO8X2bC3IOYGI
>> NaCCB53v5ineCukWIMZ1BeenO7iHUO9DMP6+LZ/1J+noMQvXwrj1/LMQ
>> ReKGMhRsWgVZ2Zkz07YB31BOUyZw5Xw5+gScPkx6xU6wQ8EdPdQ+g1C+ UOg=
>> pi.berkeleylug.com. 300 IN RRSIG AAAA 8 3 300
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> Y+MHMHYLtVMv63qYkIZSgA+9VO3oBH6ZGtpetkqDcLft164bh+VOdC3q
>> txA0GgOhsulqLHKIkITsfX5ERYjKQwy62kP5rNjFddDrldcsULGhQqeO
>> lN5sT+P3WvOrAGOeSo22SxI1IGwSfi6NDftuHbXI/aVGBHDMvkz9wGYC lFM=
>> pi.berkeleylug.com. 300 IN AAAA ::1
>> pi.berkeleylug.com. 300 IN A 127.0.0.1
>> www.pi.berkeleylug.com. 86400 IN RRSIG NSEC 8 4 86400
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> JcrifwAnynq3elpDhRmx9QKc/68VECmfeDpCN582dr9HJTLrhrcr0CTh
>> ZHH7gsnz0Jd0GjosEfdvRS/PG6qrA9DDJQbAJZNVJ0ifebVrQ+o/POpK
>> j+VtGRw4VY1EQ+1JrEk7QJlA8HK9uFGi95iZ3xQOzicPfuU9NyQm9rBF WG4=
>> www.pi.berkeleylug.com. 86400 IN NSEC www.berkeleylug.com.
>> A AAAA RRSIG NSEC
>> www.pi.berkeleylug.com. 300 IN RRSIG A 8 4 300
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> NjIvNubS7KbdtJVoQb27JQanq3YUV5Fwvevoj2FkTdWhrcvv8+wspiPT
>> QHAjcf3O3ghDmSEx5OmgVYPE7ocx4VkAZrViWGN1HOcGgzTvEEndMrdb
>> Xc1j9SnQcFIkYjtDDrTUgTuIiJUknL8j2gjQDAe9tn7KeNBmI+0EwyO8 Zr8=
>> www.pi.berkeleylug.com. 300 IN RRSIG AAAA 8 4 300
>> 20200325095614 20200224085614 59679 berkeleylug.com.
>> deQEW1SyOXpGR2i/GJMF5MEBK3haYbq5Qq5QoJbbA5I5/GvlraNMTZHW
>> e1O4XONQxSKFWRv0cZE3qMCFt0pTImVorU+quViugzgwGGNhFdYTMQNh
>> df1WAKS6bWHkHKU8KvCFvL+sute/9KUfRWGYdOWc/lWds5L2673psmKu Ay8=
>> www.pi.berkeleylug.com. 300 IN AAAA ::1
>> www.pi.berkeleylug.com. 300 IN A 127.0.0.1
>> $
>> And, there one can see, the added records (NSEC and RRSIG are
>> automatically added as part of the configured DNSSEC).
>>
>> And likewise, if we remove them
>> $ echo 'update delete pi.berkeleylug.com. IN A
>>> update delete pi.berkeleylug.com. IN AAAA
>>> update delete www.pi.berkeleylug.com. IN A
>>> update delete www.pi.berkeleylug.com. IN AAAA
>>> send' |
>>> sudo -g bind nsupdate -l -k \
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>> $
>>
>> We then see that the records are gone:
>>
>> $ dig @ns0.berkeleylug.com. +noall +answer berkeleylug.com. AXFR |
>>> fgrep -i pi.berkeleylug.com. || echo NO MATCHES FOUND
>> NO MATCHES FOUND
>> $
>>
>> Including the removal of the related NSEC and RRSIG records that our
>> DNSSEC configuration had automatically added.
>>
>> And if we try something else in the zone in DNS:
>>
>> $ echo 'update add foobarbaznotallowed.berkeleylug.com. 300 IN A 127.0.0.1
>>> send' |
>>> sudo -g bind nsupdate -l -k \
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>> update failed: REFUSED
>> $
>>
>> That fails, as it doesn't match what our configuration allows
>> by use of that key. In relevant part from our configuration:
>> update-policy {
>> grant ddns-key.pi.berkeleylug.com subdomain pi.berkeleylug.com.;
>> };
>>
>> Oh, also, 86400 (from SOA we showed earlier) is the
>> MINIMUM Negative Cache TTL value for the zone,
>> it's "global" for the zone, can't set that differently for
>> Resource Records (RRs) within. So, to avoid long negative caching,
>> may want to leave at least some record - e.g. a TXT record may suffice,
>> and leave that, thus response won't be an NXDOMAIN, which may be cached
>> up to 86400 (seconds - one day)
>> per MINIMUM Negative Cache TTL value for the zone.
>>
>>> From: "Michael Paoli" <Michae...@cal.berkeley.edu>
>>> Subject: DNS Dynamic Update: Re: pi.berkeleylug.com.? :-) (cert, ...)
>>> Date: Wed, 12 Feb 2020 15:37:23 -0800
>>
>>> So ... [*.]pi.berkeleylug.com and DNS Dynamic updates ...
>>>
>>> Have basic proof-of-concept operational.
>>> And using, for now, a temporary delegated subdomain:
>>> tmp202002.berkeleylug.com.
>>> The "real deal" would use berkeleylug.com.
>>> Otherwise, relatively similar.
>>> So ... subdomain thereof (pi), and Dynamic Updates to that
>>> (and subdomains thereof), but not other DNS data in the zone.
>>> Essentially implemented. Little mini-demo below:
>>>
>>> $ hostname; id; sudo -l | sed -ne '/^User [^ ]* may run/,$p'
>>> balug-sf-lug-v2.balug.org
>>> uid=25322(test) gid=25322(test) groups=25322(test)
>>> User test may run the following commands on balug-sf-lug-v2:
>>> (test : bind) NOPASSWD: /usr/bin/nsupdate -l -k
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>>> $
>>>
>>> So, on the DNS master (host balug-sf-lug-v2.balug.org, this is the
>>> balug Virtual Machine) that also hosts BerkeleyLUG.{com,org}.
>>>
>>> Have a test user set up (can likewise delegate to relevant users as
>>> applicable), and has sudo access set up as seen above, notably:
>>> (test : bind) NOPASSWD: /usr/bin/nsupdate -l -k
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>>> And if user forgets what commands, easy:
>>> $ sudo -l
>>> And they'll be displayed (handy reminder).
>>> So, with the indicated sudo access, we can see that user test can
>>> run the command as group bind.
>>>
>>> Below, we can see the desired records aren't yet present:
>>> $ dig +noall +answer pi.tmp202002.berkeleylug.com. A
>>> www.pi.tmp202002.berkeleylug.com. A
>>> $
>>>
>>> And then user test uses, in this case echo,
>>> to feed the desired data into sudo which in turn runs the nsupdate
>>> command as group bind:
>>> $ echo -e 'update add pi.tmp202002.berkeleylug.com. 300 A
>>> 1.2.3.4\nupdate add www.pi.tmp202002.berkeleylug.com. 300 A
>>> 1.2.3.4\nsend' | sudo -g bind nsupdate -l -k
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>>> $
>>>
>>> We can then see the desired records are present:
>>> $ dig +noall +answer pi.tmp202002.berkeleylug.com. A
>>> www.pi.tmp202002.berkeleylug.com. A
>>> pi.tmp202002.berkeleylug.com. 300 IN A 1.2.3.4
>>> www.pi.tmp202002.berkeleylug.com. 300 IN A 1.2.3.4
>>> $
>>>
>>> Likewise, this user can remove these records (in fact has,
>>> via sudo and that key, permissions to change essentially any DNS
>>> data for pi.tmp202002.berkeleylug.com. and any subdomains thereof):
>>> $ echo -e 'update delete www.pi.tmp202002.berkeleylug.com.\nupdate
>>> delete pi.tmp202002.berkeleylug.com.\nsend' | sudo -g bind nsupdate
>>> -l -k /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>>> $
>>>
>>> And after that, we can see that the removal was processed and those
>>> records are gone:
>>> $ dig +noall +answer pi.tmp202002.berkeleylug.com. A
>>> www.pi.tmp202002.berkeleylug.com. A
>>> $
>>>
>>> We can also see that our user can't change other data in the zone:
>>> $ echo -e 'update add not-allowed.tmp202002.berkeleylug.com. 300 A
>>> 1.2.3.4\nsend' | sudo -g bind nsupdate -l -k
>>> /var/cache/bind/keys/ddns-key.pi.berkeleylug.com
>>> update failed: REFUSED
>>> $
>>>
>>>> From: "Michael Paoli" <Michae...@cal.berkeley.edu>
>>>> Subject: DNS Dynamic Update: Re: pi.berkeleylug.com.? :-) (cert, ...)
>>>> Date: Mon, 10 Feb 2020 01:05:01 -0800
>>>
>>>> A little bit closer.
>>>>
>>>> So, thing I'd been thinking about and started (test)
>>>> implementation of at BerkeleLUG yesterday (Sunday) ...
>>>> with the (proposed) Raspberry Pi, not having static IPv4
>>>> address, having a means to updated it ([*.]pi.berkeleylug.com)
>>>> in DNS. Ah, thinks I, ... Dynamic Update. That and some
>>>> suitable sudoers(5) entries, and that should then cover it,
>>>> allowing client to update its DNS.
>>>>
>>>> Delegating subdomain (pi.berkeleylug.com) would be more work than
>>>> it would be worth (would need to arrange slaves, etc.), so idea
>>>> is [*.]pi.berkeleylug.com would be in same zone.
>>>> sudoers(5) and/or configuration of Dynamic Updated would be
>>>> used to suitably restrict authorized client to only update
>>>> [*.]pi.berkeleylug.com DNS data.
>>>>
>>>> But ... for initial testing, easier to start with a
>>>> delegated subdomain (easier to test that Dynamics won't
>>>> change data where they're not supposed to) ... once all is
>>>> well tested and configured and such, can apply that to the
>>>> berkeleylug.com zone - with suitable restrictions to
>>>> [*.]pi.berkeleylug.com DNS data.
>>>>
>>>> So, for test zone ... tmp202002.berkeleylug.com.
>>>> And why such a zone? Well, won't later conflict with
>>>> [*.]pi.berkeleylug.com - even if some remnant data hangs out
>>>> for a while (in caches or whatever). Also, I wanted to
>>>> do DNSSEC with it to (as is already the case with
>>>> berkeleylug.com) ... got that covered and validated,
>>>> and with DNSSEC, best practice with (ZSK) key rotation is
>>>> (about) monthly ... already have that covered. But along with
>>>> that, don't want older or possibly conflicting keys hanging
>>>> out too long. Hence, for testing now, separate delegated
>>>> sub-domain, that doesn't conflict, and is quite clearly
>>>> intended to be temporary.
>>>>
>>>> Oh, and since it's just for proof-of-concept / testing, and
>>>> nothin' all that important at the moment ... who needs slaves?
>>>> (yeah, I know, RFCs 'n all that, but for a who cares throwaway
>>>> anyway ...).
>>>> So, DNSSEC ... done: Try this also for a nice view thereof:
>>>> https://dnsviz.net/d/tmp202002.berkeleylug.com/dnssec/
>>>> And of course:
>>>> $ delv tmp202002.berkeleylug.com. SOA +multiline
>>>> ; fully validated
>>>> tmp202002.berkeleylug.com. 291 IN SOA
>>>> ns0.tmp202002.berkeleylug.com. Michael\.Paoli.cal.berkeley.edu. (
>>>> 1581288117 ; serial
>>>> 3600 ; refresh (1 hour)
>>>> 1200 ; retry (20 minutes)
>>>> 604800 ; expire (1 week)
>>>> 180 ; minimum (3 minutes)
>>>> )
>>>> tmp202002.berkeleylug.com. 291 IN RRSIG SOA 8 3 300 (
>>>> 20200311085137 20200210075137 6543
>>>> tmp202002.berkeleylug.com.
>>>> Ub0l4cQnPmt47MvguwCW1YHztF6CpWGksWl6MYHiYDgs
>>>> y3kiyOMAvGd2hmOwQMbU2NndI9DTpfn9iYycxKFZcjP3
>>>> VTPUD/7iKa7yXXvVq+G81q2YfJx7Aqxe0yczCAG+8G0j
>>>> 0Ui3oYdxb2ZxmqT7b8cVRdDAZ9DwUHkRjgWCvjs= )
>>>> $
>>>>
>>>> And ... Dynamic Update, yep, have that implemented too:
>>>> $ dig +noall +answer www.tmp202002.berkeleylug.com. A
>>>> www.tmp202002.berkeleylug.com. AAAA
>>>> www.tmp202002.berkeleylug.com. 300 IN A 96.86.170.229
>>>> www.tmp202002.berkeleylug.com. 300 IN AAAA 2001:470:1f05:19e::4
>>>> # echo -e 'update del www.tmp202002.berkeleylug.com.
>>>> update add www.tmp202002.berkeleylug.com. 300 A
>>>> 10.9.8.7update add www.tmp202002.berkeleylug.com. 300 AAAA
>>>> 2001:470:1f05:19e:babe:face:deaf:beef
>>>> update add
>>>> www.tmp202002.berkeleylug.com. 300 AAAA
>>>> 2001:470:1f05:19e:beef:face:deaf:babe
>>>> update add
>>>> www.tmp202002.berkeleylug.com. 300 AAAA
>>>> 2001:470:1f05:19e:feed:babe:dead:beef
>>>> send' | nsupdate -l
>>>> #
>>>> $ dig +noall +answer www.tmp202002.berkeleylug.com. A
>>>> www.tmp202002.berkeleylug.
>>>> com. AAAA
>>>> www.tmp202002.berkeleylug.com. 300 IN A 10.9.8.7
>>>> www.tmp202002.berkeleylug.com. 300 IN AAAA
>>>> 2001:470:1f05:19e:beef:face:deaf:babe
>>>> www.tmp202002.berkeleylug.com. 300 IN AAAA
>>>> 2001:470:1f05:19e:feed:babe:dead:beef
>>>> www.tmp202002.berkeleylug.com. 300 IN AAAA
>>>> 2001:470:1f05:19e:babe:face:deaf:beef
>>>> $
>>>>
>>>>> From: "Michael Paoli" <Michae...@cal.berkeley.edu>
>>>>> Subject: pi.berkeleylug.com.? :-) (cert, ...)
>>>>> Date: Sat, 01 Feb 2020 09:30:22 -0800
>>>>
>>>>> Tom,
>>>>>
>>>>> Per our earlier communications:
>>>>>
>>>>> Let me know when you check if you can have open TCP ports
>>>>> 80 & 443 with your ISP on IPv4 (and also, if applicable/available,
>>>>> IPv6).
>>>>>
>>>>> We could then:
>>>>> set up page, likely:
>>>>> https://berkeleylug.com/pi/
>>>>> On the BerkeleyLUG web site.
>>>>> And could then also include link(s) from there to:
>>>>> http[s]://[www.]pi.berkeleylug.com/
>>>>> I could also work on setting up dynamic DNS on
>>>>> berkeleylug.com
>>>>> and account and suitable access, so you'd be able to change DNS
>>>>> for [*.]pi.berkeleylug.com.
>>>>>
>>>>> Oh, and do also have TLS(/"SSL") cert ready for you - if you wish
>>>>> to use it, and when we have secure means to transfer key (e.g. via
>>>>> aforementioned above account and ssh/scp/sftp):
>>>>> Not Before: Feb 1 15:32:20 2020 GMT
>>>>> Not After : May 1 15:32:20 2020 GMT
>>>>> Subject: CN = *.pi.berkeleylug.com
>>>>> *.pi.berkeleylug.com,pi.berkeleylug.com
>>>>> I use letsencrypt.org, and generally get new certs a bit
>>>>> more frequently than every 90 days (since they expire after 90 days).
>>>>> Anyway, got such cert covering the above
>>>>> (Subject Alternative Name (SAN) & wildcard)
>>>>> so that would suffice to cover not only
>>>>> pi.berkeleylug.com, but also any subdomain directly thereunder, e.g.:
>>>>> www.pi.berkeleylug.com
>>>>> And you could decide what you'd want the canonical to be
>>>>> (with or without leading www., and https, or http).
>>>>> Anyway, not much extra work for me to obtain such cert when I
>>>>> do all my others (for efficiency, I grab 'em all right around the
>>>>> same time, so all the expirations are fairly closely aligned, and
>>>>> then I effectively process 'em all as a (sequential) "batch",
>>>>> bit more frequent than once every 90 days ... then generally no
>>>>> other such certs to muck with in the time between).
>>>>>
>>>>> see also:
>>>>> http://linuxmafia.com/pipermail/conspire/2020-January/date.html
goossbears
Jun 21, 2020, 6:24:28 PM6/21/20
to BerkeleyLUG
For ease/aid in "branding" / naming / identification, etc.,
it might be best if we agree upon a common way of naming/identifying.
So, we do have available (even if it's not been pressed into use yet)
subdomain pi.berkeleylug.com - that can be pressed into use at most
any time - the DNS infrastructure, sudoers, etc. is pretty much all
there - just would need to add the host login account(s)
(actually just added a piberk utility/role account, but
individual account(s) would be added too) and add said account(s) to
already fully tested sudo capability - then said accounts can fully
manage pi.berkeleylug.com DNS under existing BerkeleyLUG.com DNS
infrastructure - both add/drop/change pi.berkeleylug.com and/or any
subdomains (e.g. www.pi.berkeleylug.com) thereunder, either directly
using BerkeleyLUG.com existing NS infrastructure, or even NS (and DS if
DNSSEC desired) delegating such. Hmmm, heck, Pi.BerkeleyLUG SIG could
even use such account(s) (notably piberk) to have crontab job(s) that
would revert to WordPress page when [www.]pi.berkeleylug.com was
otherwise offline. Then Raspberry Pi based host & web server could
use ssh to update and change DNS to use itself as web server when it was
up and on-line, again leveraging such account(s).
Seems reasonable.
So, there's that ... there's also relevant web page(s) (mostly
notwithstanding the above), and list(s).
Let's start with web page(s)(/site(s)).
It's good for (Linux) User Groups ([L]UGs) to have their own
web site - or at least web page - and/or list(s) ... though those aren't
absolute hard-and-fast requirements.
but we might want to create a page such as:
https://berkeleylug.com/BerkeleyPi or
https://berkeleylug.com/pi.berkeleylug or
https://berkeleylug.com/Pi or the like.
with pi.berkeleylug, e.g.
https://berkeleylug.com/pi.berkeleylug
that could then also be (relatively) consistent with any DNS use
of pi.berkeleylug.com
And why not instead:
https://berkeleylug.com/pi.berkeleylug.com
? Because I don't think the ".com" part is all that
important as part of the "branding" and such. Besides, too,
if "Berkeley Pi" ever split off into its own totally separate
thing, it might prefer/choose a TLD that's not under com.
The KISS principle exhorts one to Keep It Short and Simple (see https://www.techopedia.com/definition/20262/keep-it-simple-stupid-principle-kiss-principle )
Therefore, in order of increasing size and complexity w/ Proper-Case equivalents....
=============================================
https://berkeleylug.com/pihttps://berkeleylug.com/Pi
==
https://berkeleylug.com/berkeleypi
https://berkeleylug.com/BerkeleyPi
==
dot .
https://berkeleylug.com/pi.berkeley
https://berkeleylug.com/Pi.Berkeley
dash -
https://berkeleylug.com/pi-berkeley
https://berkeleylug.com/Pi-Berkeley
==
==
dot .
https://berkeleylug.com/pi.berkeleylug
https://berkeleylug.com/Pi.BerkeleyLUG
dash -
https://berkeleylug.com/pi-berkeleylug
https://berkeleylug.com/Pi-BerkeleyLUG
==
dot .
https://berkeleylug.com/pi.berkeleylug.<tld>
https://berkeleylug.com/Pi.BerkeleyLUG.<tld>
dash -
https://berkeleylug.com/pi-berkeleylug.<tld>
https://berkeleylug.com/Pi-BerkeleyLUG.<tld>
https://berkeleylug.com/pi.berkeleylug.<tld>
https://berkeleylug.com/Pi.BerkeleyLUG.<tld>
dash -
https://berkeleylug.com/pi-berkeleylug.<tld>
https://berkeleylug.com/Pi-BerkeleyLUG.<tld>
=============================================
Anyway, curious what folks think/suggest/recommend.
I'm thinking perhaps best to use "Pi.BerkeleyLUG" throughout,
at least to the extent feasible - then that could be quite consistent
and recognizable, easy to filter on, would match to DNS (at least
portion thereof), etc.
Again, https://berkeleylug.com/pi comes out to be the shortest and simplest
:-)
-Aaron
Michael Paoli
Jun 22, 2020, 7:52:07 AM6/22/20
to BerkeleyLUG
So ... after further communication at the Pi.BerkeleyLUG meeting this
past Sunday, etc., what was proposed has essentially been implemented.
In summary:
"Pi.BerkeleyLUG" - that's the canonical form of the string, (to be)
used in various places to help identify the SIG, filter/search, etc.
Notably includes at least:
o Please use it in Subject: header on list, to help identify relevant
related messages, so folks can recognize, filter/categorize, etc.
(recommended to use case as shown for ease for the humans, but for
programmatic use, e.g. filtering, do case insensitive match). That
doesn't necessarily preclude *also* using additional identifiers, but
Pi.BerkeleyLUG should be primary and is now the canonical.
o Pi.BerkeleyLUG has at least one dedicated web page:
https://BerkeleyLUG.com/Pi.BerkeleyLUG/
That can be used as a primary(/fallback) persistent place for folks to
get at least some basic information about Pi.BerkeleyLUG, and anyone
with >=edit access on WordPress on the BerkeleyLUG site can update it
(several folks already have access, if you want to be added, just
ask). Also, for convenience and ease of use, a range of variations on
that URL will also get one 301 redirected to the canonical above.
E.g.:
http://berkeleylug.com/pi
https://berkeleylug.com/piberkeley
https://berkeleylug.com/berkeleypi
https://berkeleylug.com/pi.berkeley
https://berkeleylug.com/pi-berkeley
https://berkeleylug.com/berkeleylugpi
https://berkeleylug.com/berkeleylug.com-pi
https://www.berkeleylug.com/pi.berkeleylug.com
Or for those that speak Apache2/Perl RE:
(?!(?-i)^/Pi\.BerkeleyLUG/$)^/(?:pi(?:[-.]?berkeley(?:lug(?:\.com)?)?)?|berkeley(?:lug(?:\.com)?)?[-.]?pi)/?$
[NC]
o Pi.BerkeleyLUG is a Special Interest Group (SIG) of BerkeleyLUG (to
remove ambiguity over describing it and make more simple and concise
describing, at least in part, what it is and its (at least current)
relationship to BerkeleyLUG)
o pi.berkeleylug.com & DNS - fair bit has been said on that earlier ...
dynamic DNS, utility/role account (piberk) on host has access to
update that DNS, relevant responsible person(s) can also request and
be granted that access too, so that, e.g. [www.]pi.berkeleylug.com.
DNS could go to, e.g. web server running on a Raspberry Pi or the like.
Also, as suggested/proposed in the earlier there's automagic fallback.
If/when http://pi.berkeleylug.com/ doesn't respond for a while,
DNS goes to fallback to use the berkeleylug.com web server,
and that web server is configured so anything coming in with
Host: matching [www.]pi.berkeleylug.com gets 302 redirected to:
https://BerkeleyLUG.com/Pi.BerkeleyLUG/
Want to peek a little at some of the automagic bits? Have a look at
these bits:
$ hostname; id; crontab -l | grep -v \^#
balug-sf-lug-v2.balug.org
uid=24567(piberk) gid=24567(piberk) groups=24567(piberk)
0,6,12,18,24,30,36,42,48,54 * * * * exec >>/dev/null 2>&1 &&
/home/piberk/bin/pi.berkeleylug; :
$
https://berkeleylug.com/~piberk/bin/pi.berkeleylug
https://berkeleylug.com/~piberk/bin/Nsupdate
Anyway, that gives the Pi.BerkeleyLUG SIG a nice consistent
"Pi.BerkeleyLUG" to use throughout to identify, etc., and a web page,
etc.
past Sunday, etc., what was proposed has essentially been implemented.
In summary:
"Pi.BerkeleyLUG" - that's the canonical form of the string, (to be)
used in various places to help identify the SIG, filter/search, etc.
Notably includes at least:
o Please use it in Subject: header on list, to help identify relevant
related messages, so folks can recognize, filter/categorize, etc.
(recommended to use case as shown for ease for the humans, but for
programmatic use, e.g. filtering, do case insensitive match). That
doesn't necessarily preclude *also* using additional identifiers, but
Pi.BerkeleyLUG should be primary and is now the canonical.
o Pi.BerkeleyLUG has at least one dedicated web page:
https://BerkeleyLUG.com/Pi.BerkeleyLUG/
That can be used as a primary(/fallback) persistent place for folks to
get at least some basic information about Pi.BerkeleyLUG, and anyone
with >=edit access on WordPress on the BerkeleyLUG site can update it
(several folks already have access, if you want to be added, just
ask). Also, for convenience and ease of use, a range of variations on
that URL will also get one 301 redirected to the canonical above.
E.g.:
http://berkeleylug.com/pi
https://berkeleylug.com/piberkeley
https://berkeleylug.com/berkeleypi
https://berkeleylug.com/pi.berkeley
https://berkeleylug.com/pi-berkeley
https://berkeleylug.com/berkeleylugpi
https://berkeleylug.com/berkeleylug.com-pi
https://www.berkeleylug.com/pi.berkeleylug.com
Or for those that speak Apache2/Perl RE:
(?!(?-i)^/Pi\.BerkeleyLUG/$)^/(?:pi(?:[-.]?berkeley(?:lug(?:\.com)?)?)?|berkeley(?:lug(?:\.com)?)?[-.]?pi)/?$
[NC]
o Pi.BerkeleyLUG is a Special Interest Group (SIG) of BerkeleyLUG (to
remove ambiguity over describing it and make more simple and concise
describing, at least in part, what it is and its (at least current)
relationship to BerkeleyLUG)
o pi.berkeleylug.com & DNS - fair bit has been said on that earlier ...
dynamic DNS, utility/role account (piberk) on host has access to
update that DNS, relevant responsible person(s) can also request and
be granted that access too, so that, e.g. [www.]pi.berkeleylug.com.
DNS could go to, e.g. web server running on a Raspberry Pi or the like.
Also, as suggested/proposed in the earlier there's automagic fallback.
If/when http://pi.berkeleylug.com/ doesn't respond for a while,
DNS goes to fallback to use the berkeleylug.com web server,
and that web server is configured so anything coming in with
Host: matching [www.]pi.berkeleylug.com gets 302 redirected to:
https://BerkeleyLUG.com/Pi.BerkeleyLUG/
Want to peek a little at some of the automagic bits? Have a look at
these bits:
$ hostname; id; crontab -l | grep -v \^#
balug-sf-lug-v2.balug.org
uid=24567(piberk) gid=24567(piberk) groups=24567(piberk)
0,6,12,18,24,30,36,42,48,54 * * * * exec >>/dev/null 2>&1 &&
/home/piberk/bin/pi.berkeleylug; :
$
https://berkeleylug.com/~piberk/bin/pi.berkeleylug
https://berkeleylug.com/~piberk/bin/Nsupdate
Anyway, that gives the Pi.BerkeleyLUG SIG a nice consistent
"Pi.BerkeleyLUG" to use throughout to identify, etc., and a web page,
etc.
goossbears
Jun 22, 2020, 8:49:31 PM6/22/20
to BerkeleyLUG
Is there a way or are there ways to possibly track and/or measure any or all pointers/referrals and redirects
*from* other links a.k.a. URLs *to* the canonical landing page of http[s]://[www.]pi.berkeleylug.com/ ??
See below the longer quote as well....
Pi.BerkeleyLUG is a Special Interest Group (SIG) of BerkeleyLUG.
And relevant redirects to canonical landing page (and with most of
them being case-insensitive on the matching):
{
http[s]://[www.]pi.berkeleylug.com/ (302 - excepting Pi SIG taking it
elsewhere)
http[s]://[www.]berkeleylug.com/pi[[-.]berkeley[lug]][/] (301)
} --> https://BerkeleyLUG.com/Pi.BerkeleyLUG/
... even virtual meet URLs for the SIG could likewise
where/as feasible use URLs ending in /Pi.BerkeleyLUG[/]
over "Berkeley Pi".
Similarly, for Michael P and Rick M respectively, Is there a way or are there ways
to possibly track and/or measure any or all all pointers/referrals and redirects from
other URLs to https://www.balug.org and http://linuxmafia.com respectively??
> references/excerpts:
> nsupdate(1)
> nsupdate(1)
> https://www.balug.org/~piberk/bin/Nsupdate
> $ id; hostname; date -Iseconds
> uid=24567(piberk) gid=24567(piberk) groups=24567(piberk)
> $ id; hostname; date -Iseconds
> uid=24567(piberk) gid=24567(piberk) groups=24567(piberk)
>balug-sf-lug-v2.balug.org
> 2020-06-21T14:24:54+00:00
> 2020-06-21T14:24:54+00:00
Michael Paoli
Jun 23, 2020, 2:04:15 AM6/23/20
to BerkeleyLUG
Well ...
As for anything hitting / landing on
http[s]://[www.]berkeleylug.com/Pi.BerkeleyLUG/ etc.
That would generally all be in the (Apache) web server logs.
As to http[s]://[www.]pi.berkelug.com/
... that depends where the DNS goes to and what it is upon.
At present it's got active fallback that goes to
the [www.]berkeleylug.com. IPs ... and webserver there just 302
redirects to https://berkeleylug.com/Pi.BerkeleyLUG/
So, anyway, so long as it's on that host and web server,
that's also logged in those same logs.
Maybe I ought install something that reports some stats from
the Apache log data?
Want to suggest suitable (Debian stable) package?
I did also, long ago, tweak the default log rotation for the
Apache log data ... so generally have data going back about
60 weeks - so should generally have a bit over a year of
data - helps to give some fair bit of history/context,
and for any other relevant logging purposes. Yet older
logs would also exist on backups that are done periodically.
> From: goossbears <acoh...@gmail.com>
> Subject: Measuring pointers/referrals to pi.berkeley.com ?
> Date: Mon, 22 Jun 2020 17:49:31 -0700 (PDT)
> Is there a way or are there ways to possibly track and/or measure any or
> all pointers/referrals and redirects
> *from* other links a.k.a. URLs *to* the canonical landing page of
> http[s]://[www.]pi.berkeleylug.com/ ??
> <http://pi.berkeleylug.com/>
As for anything hitting / landing on
http[s]://[www.]berkeleylug.com/Pi.BerkeleyLUG/ etc.
That would generally all be in the (Apache) web server logs.
As to http[s]://[www.]pi.berkelug.com/
... that depends where the DNS goes to and what it is upon.
At present it's got active fallback that goes to
the [www.]berkeleylug.com. IPs ... and webserver there just 302
redirects to https://berkeleylug.com/Pi.BerkeleyLUG/
So, anyway, so long as it's on that host and web server,
that's also logged in those same logs.
Maybe I ought install something that reports some stats from
the Apache log data?
Want to suggest suitable (Debian stable) package?
I did also, long ago, tweak the default log rotation for the
Apache log data ... so generally have data going back about
60 weeks - so should generally have a bit over a year of
data - helps to give some fair bit of history/context,
and for any other relevant logging purposes. Yet older
logs would also exist on backups that are done periodically.
> From: goossbears <acoh...@gmail.com>
> Subject: Measuring pointers/referrals to pi.berkeley.com ?
> Date: Mon, 22 Jun 2020 17:49:31 -0700 (PDT)
> Is there a way or are there ways to possibly track and/or measure any or
> all pointers/referrals and redirects
> *from* other links a.k.a. URLs *to* the canonical landing page of
> http[s]://[www.]pi.berkeleylug.com/ ??
>
> See below the longer quote as well....
>
> On Sunday, June 21, 2020 at 11:09:20 AM UTC-7, Michael Paoli wrote:
>>
>> Pi.BerkeleyLUG is a Special Interest Group (SIG) of BerkeleyLUG.
>> And relevant redirects to canonical landing page (and with most of
>> them being case-insensitive on the matching):
>> {
>> http[s]://[www.]pi.berkeleylug.com/ (302 - excepting Pi SIG taking it
>> elsewhere)
>> http[s]://[www.]berkeleylug.com/pi[[-.]berkeley[lug]][/]
>> <http://berkeleylug.com/pi%5B%5B-.%5Dberkeley%5Blug%5D%5D%5B/%5D> (301)
> See below the longer quote as well....
>
> On Sunday, June 21, 2020 at 11:09:20 AM UTC-7, Michael Paoli wrote:
>>
>> Pi.BerkeleyLUG is a Special Interest Group (SIG) of BerkeleyLUG.
>> And relevant redirects to canonical landing page (and with most of
>> them being case-insensitive on the matching):
>> {
>> http[s]://[www.]pi.berkeleylug.com/ (302 - excepting Pi SIG taking it
>> elsewhere)
>> http[s]://[www.]berkeleylug.com/pi[[-.]berkeley[lug]][/]
>> } --> https://BerkeleyLUG.com/Pi.BerkeleyLUG/
>> ... even virtual meet URLs for the SIG could likewise
>> where/as feasible use URLs ending in /Pi.BerkeleyLUG[/]
>>
>> But most notably at least "in the meantime" (and if it ever does fully
>> split off - for
>> relevant pointers/referrals - notably since it (essentially?) started
>> within BerkeleyLUG), would be good to have some relevant location(s)
>> on BerkeleyLUG about or referring/pointing to "Berkeley Pi".
>> So, along those lines, I was thinking, already have the
>> https://berkeleylug.com/ web site, it would be good to create a page on
>> there for "Berkeley Pi". I/we might have to poke at the existing
>> (WordPress) site a bit on naming conventions and such,
>> but we might want to create a page such as:
>> https://berkeleylug.com/BerkeleyPi
>> <https://www.google.com/url?q=https%3A%2F%2Fberkeleylug.com%2FBerkeleyPi&sa=D&sntz=1&usg=AFQjCNE-RWDGlnSrxoGVubsYjuXGrJNExw>
>> ... even virtual meet URLs for the SIG could likewise
>> where/as feasible use URLs ending in /Pi.BerkeleyLUG[/]
>>
>> But most notably at least "in the meantime" (and if it ever does fully
>> split off - for
>> relevant pointers/referrals - notably since it (essentially?) started
>> within BerkeleyLUG), would be good to have some relevant location(s)
>> on BerkeleyLUG about or referring/pointing to "Berkeley Pi".
>> So, along those lines, I was thinking, already have the
>> https://berkeleylug.com/ web site, it would be good to create a page on
>> there for "Berkeley Pi". I/we might have to poke at the existing
>> (WordPress) site a bit on naming conventions and such,
>> but we might want to create a page such as:
>> https://berkeleylug.com/BerkeleyPi
>> or
>> https://berkeleylug.com/pi.berkeleylug or
>> https://berkeleylug.com/Pi or the like.
>> Not sure about case sensitivity (or not) on such with WordPress,
>> but some added web server redirects could ensure various possible
>> alternatives/variations all would get (presumably 301) redirected to
>> some suitable "Berkeley Pi" landing page, such as:
>> https://berkeleylug.com/BerkeleyPi or
>> https://berkeleylug.com/pi.berkeleylug
>> If/once <https://berkeleylug.com/pi.berkeleylugIf/once> we agreed upon
>> https://berkeleylug.com/pi.berkeleylug or
>> https://berkeleylug.com/Pi or the like.
>> Not sure about case sensitivity (or not) on such with WordPress,
>> but some added web server redirects could ensure various possible
>> alternatives/variations all would get (presumably 301) redirected to
>> some suitable "Berkeley Pi" landing page, such as:
>> https://berkeleylug.com/BerkeleyPi or
>> https://berkeleylug.com/pi.berkeleylug
Michael Paoli
Apr 3, 2021, 1:17:16 PM4/3/21
to BerkeleyLUG
+cert (CA signed TLS/"SSL" cert)
Since I do a bunch of such certs rather regularly, and have much of that
process automated (very much all the requesting and obtaining of certs),
and also have been, for fair while now, also obtaining such for
pi.berkeleyelug.com ... added wee bit more for piberk account
on the VM host:
$ hostname; id; sudo -l | sed -ne '/may run/,$p'
balug-sf-lug-v2.balug.org
uid=24567(piberk) gid=24567(piberk) groups=24567(piberk)
User piberk may run the following commands on balug-sf-lug-v2:
(root) NOPASSWD: /bin/cat
/etc/letsencrypt/live/pi.berkeleylug.com/cert.pem, /bin/cat
/etc/letsencrypt/live/pi.berkeleylug.com/chain.pem, /bin/cat
/etc/letsencrypt/live/pi.berkeleylug.com/fullchain.pem, /bin/cat
/etc/letsencrypt/live/pi.berkeleylug.com/privkey.pem
$
Notably the piberk ID has access to the pi.berkeleylug.com private key
for the cert, and cert itself (and chain) ... "of course" cert and chain
could also be obtained from web site ... but the above may be more
convenient. And, also, "of course", with piberk able to control DNS
for pi.berkeleylug.com, it can also always obtain it's own CA signed
cert(s) - e.g. from letsencrypt.org.
Anyway, I'll still continue to get the certs as I've been doing, and those
will remain available as noted above ... at least if the pi.berkeleylug.com
domain exists as it is on the present master and slave DNS servers (piberk
account can control relevant DNS on those). But if it's delegated to
elsewhere (e.g. NS record(s), DS, etc. as applicable), then I wouldn't be
able to use my existing setup for getting [www.]pi.berkeleylug.com
cert (and indeed, if both web site are elsewhere and DNS delegated to
other nameserver(s), I wouldn't have the access to request such cert(s)).
Anyway, the existing DNS infrastructure is well established, and with slaves
'n all that, so may be easiest (and most prudent) to not delegate DNS
to elsewhere, but leverage the existing infrastructure ... "of course",
along with that, webserver could be anywhere, ... just update relevant
(e.g. A, AAAA, or CNAME) record(s) as applicable.
And, the fallback/failover crontab job is still in place as noted
earlier ... and that also remains under control of the piberk
account (so, e.g. it can modify that or whatever).
https://groups.google.com/g/berkeleylug/c/YQiQmlxoGd0/m/eAcxaecBCAAJ
Since I do a bunch of such certs rather regularly, and have much of that
process automated (very much all the requesting and obtaining of certs),
and also have been, for fair while now, also obtaining such for
pi.berkeleyelug.com ... added wee bit more for piberk account
on the VM host:
$ hostname; id; sudo -l | sed -ne '/may run/,$p'
balug-sf-lug-v2.balug.org
uid=24567(piberk) gid=24567(piberk) groups=24567(piberk)
User piberk may run the following commands on balug-sf-lug-v2:
(root) NOPASSWD: /bin/cat
/etc/letsencrypt/live/pi.berkeleylug.com/cert.pem, /bin/cat
/etc/letsencrypt/live/pi.berkeleylug.com/chain.pem, /bin/cat
/etc/letsencrypt/live/pi.berkeleylug.com/fullchain.pem, /bin/cat
/etc/letsencrypt/live/pi.berkeleylug.com/privkey.pem
$
Notably the piberk ID has access to the pi.berkeleylug.com private key
for the cert, and cert itself (and chain) ... "of course" cert and chain
could also be obtained from web site ... but the above may be more
convenient. And, also, "of course", with piberk able to control DNS
for pi.berkeleylug.com, it can also always obtain it's own CA signed
cert(s) - e.g. from letsencrypt.org.
Anyway, I'll still continue to get the certs as I've been doing, and those
will remain available as noted above ... at least if the pi.berkeleylug.com
domain exists as it is on the present master and slave DNS servers (piberk
account can control relevant DNS on those). But if it's delegated to
elsewhere (e.g. NS record(s), DS, etc. as applicable), then I wouldn't be
able to use my existing setup for getting [www.]pi.berkeleylug.com
cert (and indeed, if both web site are elsewhere and DNS delegated to
other nameserver(s), I wouldn't have the access to request such cert(s)).
Anyway, the existing DNS infrastructure is well established, and with slaves
'n all that, so may be easiest (and most prudent) to not delegate DNS
to elsewhere, but leverage the existing infrastructure ... "of course",
along with that, webserver could be anywhere, ... just update relevant
(e.g. A, AAAA, or CNAME) record(s) as applicable.
And, the fallback/failover crontab job is still in place as noted
earlier ... and that also remains under control of the piberk
account (so, e.g. it can modify that or whatever).
https://groups.google.com/g/berkeleylug/c/YQiQmlxoGd0/m/eAcxaecBCAAJ
Michael Paoli
Apr 18, 2021, 8:58:50 AM4/18/21
to BerkeleyLUG
Hmmm, could also ...
Pi.BerkeleyLUG.com web page(s) ... needn't be WordPress, e.g. could be
static web pages. Not only on, e.g. a Raspberry Pi,
but also on the existing Virtual Machine (VM) host.
E.g. rather than Pi.BerkeleyLUG.com redirecting to
WordPress page https://berkeleylug.com/Pi.BerkeleyLUG/
could do it the other way around, and have static web page(s) at
http[s]://Pi.BerkeleyLUG.com/ ... and, could always do likewise on
a Pi ... they could potentially even rsync on occasion to keep content
aligned. E.g. there's present automagic failback in place, so if
http[s]://Pi.BerkeleyLUG.com/ doesn't respond, then DNS for that
reverts to the VM.
Well, that could be static page(s) rather than redirecting to the
WordPress page, and likewise, could have the WordPress page redirect
to the static page(s). Anyway, easy enough to do and reconfigure that
on Apache. And easy to set up the existing piberk ID on that host
so it has access to edit such page(s) and content and such.
Pi.BerkeleyLUG.com web page(s) ... needn't be WordPress, e.g. could be
static web pages. Not only on, e.g. a Raspberry Pi,
but also on the existing Virtual Machine (VM) host.
E.g. rather than Pi.BerkeleyLUG.com redirecting to
WordPress page https://berkeleylug.com/Pi.BerkeleyLUG/
could do it the other way around, and have static web page(s) at
http[s]://Pi.BerkeleyLUG.com/ ... and, could always do likewise on
a Pi ... they could potentially even rsync on occasion to keep content
aligned. E.g. there's present automagic failback in place, so if
http[s]://Pi.BerkeleyLUG.com/ doesn't respond, then DNS for that
reverts to the VM.
Well, that could be static page(s) rather than redirecting to the
WordPress page, and likewise, could have the WordPress page redirect
to the static page(s). Anyway, easy enough to do and reconfigure that
on Apache. And easy to set up the existing piberk ID on that host
so it has access to edit such page(s) and content and such.
Reply all
Reply to author
Forward
0 new messages