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" <Michael.Paoli@cal.berkeley.edu>
To: "tom r lopes" <tomrlopes@gmail.com>
Cc: BerkeleyLUG <berkeleylug@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" <Michael.Paoli@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" <Michael.Paoli@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" <Michael.Paoli@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" <Michael.Paoli@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