[sf-lug] Documentined!: Re: SF-LUG zones now using dynamic DNS

[Michael Paoli]

[Bcc: SF-LUG DNS editors]

And documented!  :-)
I placed it here:
https://www.balug.org/wiki/doku.php?id=system:dns
It's also linked in fairly visibly appropriate place from:
https://www.balug.org/wiki/doku.php?id=sf-lug:resources_etc
I also updated:
https://www.balug.org/wiki/doku.php?id=system:balug_dns
Most notably indicating that wiki page is mostly outdated historic
information (goes way back to when SF-LUG and BALUG shared a common
host that was primarily intended for SF-LUG, but BALUG also used same host,
and had it's own IPv4 IP on that single host).

Wiki is "pretty good" for SF-LUG/BALUG/BerkeleyLUG/... purposes, most of
the documentation that's [L]UG, etc. specific is there (if it's anywhere!),
can also be edited (notably corrected/improved/updated) by "most anyone*",
and is fairly easy to do so, and also history can be viewed.

*alas, volunteer(s), resources, ... <crickets> I end up doing most all that.

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] Documenting(?): Re: SF-LUG zones now using dynamic DNS
> Date: Wed, 11 Mar 2020 22:45:38 -0700

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> Good points.  :-)
>>
>> And where might you suggest documenting such?
>>
>> For (perhaps?) lack of better, I might think on BALUG's
>> wiki:
>> https://www.balug.org/wiki/doku.php?do=index
>> Perhaps under the "system" namespace,
>
> You can do that provided that you omit (from there) all sensitive  
> information.
> And there's the rub....
>
> SVLUG's situation was different in that it has never had a wiki.
> (Suxors.  Point to BALUG.)  So, instead, /usr/local/site-docs got
> created on each of the two servers (www.svlug.org and lists.svlug.org)
> and gradually populated with process-documentation files.  And, it turns
> out, a _lot_ of what you want to cover there for a sysadmin team ends up
> being at least a little security-sensitive.
>
> Like, one of the site-docs files on www.svlug.org details why the
> installed software is constrained to a minimum (with packages specified
> by name), how the sysadmins should act to keep it that way, and how/why
> we overrode the software architect's bad decision to leave an svn daemon
> running 24x7 under inetd.  The details are matters you really would
> prefer to not have fully public on a wiki page.  (Yes, I know that page
> spaces on DokuWiki can be locked down to particular logged-in users, but
> frankly it's more reassuring to control that access with the same system
> sshd access controls that let the sysadmins in.)
>
> So, it ended up that there's a _small_ amount of process documentation
> on the public www.svlug.org Web pages, somewhat painfully hand-tagged.
> I think it's just this one page:
> http://www.svlug.org/teams/web-team.php
>
> It ended up that, between the pain-in-the-assical nature of cobbling
> together more Web pages (wikis obviously help) and the fact that process
> documentation tends to be marbled with _somewhat_ security-sensitive
> information, everything else (but for one or two things) ended up in
> site-docs.  The one-or-two-things were _very_ sensitive credentials,
> which went into high-security site-docs ASCII files in /root/sensitive/*
> that (obviously) are root-only.  Those get cross-referenced from the
> system site-docs dir.
>
> So, I don't know what to tell you.  Your inclination _obviously_ is to
> build wiki pages.  I predict that, if you do, you'll come to realise
> you're either avoiding covering sensitive subjects or taking risks with
> public access (even to a degree with DokuWiki page ACLs) that ought not
> to be taken.
>
> Personally, I'd once again go for a group-readable site-docs directory
> on the local system.