[sf-lug] And then there were 5: SFLUG.NET, SFLUG.COM, SFLUG, ORG, SF-LUG.COM, SF-LUG.ORG: Re: SFLUG.COM Re: SFLUG.[...] Re: SFLUG.org

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> Uhm, are we done adding domains for a while now, or ... are we gonna pick up
> yet more?  SF-LUG.NET also seems available, but I don't know that Jim
> specifically suggested that ... nor up to how many domains he's willing
> to be reimbursing folks for.

As you say, the really relevant datum is which ones people are willing
to shell out for.

Back around 1997 when I got linuxmafia.com (as a gift from Penguin
Computing founder Sam Ockman), there was a long period when I could have
snagged linuxmafia.org and linuxmafia.net.  I've never regretted having
given them a pass.

Both have been registered, now, for a long time.  The guy who owns
linuxmafia.net i seems to never do a thing with it.  linuxmafia.org has,
for several years, been an Indonesian online poker site, which boggles
me a bit.

> Anyway, master now available for not only sflug.org.
> but also now sflug.com. and sflug.net.:
> ns1.sf-lug.org.:
> 198.144.194.238
> 2001:470:1f04:19e::2
> Not sure where the slaves may be in the process.

Mine aren't set up yet.  I'll probably get to that later in the weekend.

> Rick - if you want to coordinate with Al, you do also have access to
> edit those zone masters:
> balug-sf-lug-v2.balug.org
> User rick may run the following commands on balug-sf-lug-v2:
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For those watching at home, that's reported by 'sudo -l -U rick'.
(I didn't know that.  Had to look up the answer to 'How do I find out
what sudo rights I have on a system?'  I'm ordinarily, elsewhere, 
able to be super-lazy and do 'sudo su -' and then peek in /etc/sudoers, 
but that's on systems where one has ability to sudo to root priv.
Anyway, more here:
https://unix.stackexchange.com/questions/50785/how-do-i-find-out-if-i-am-sudoer )

>     (root) sudoedit /etc/bind/master/sflug.org
>     (root) /usr/sbin/rndc reload sflug.org
>     (root) /usr/sbin/rndc notify sflug.org
>     (root) sudoedit /etc/bind/master/sflug.com
>     (root) /usr/sbin/rndc reload sflug.com
>     (root) /usr/sbin/rndc notify sflug.com
>     (root) sudoedit /etc/bind/master/sflug.net
>     (root) /usr/sbin/rndc reload sflug.net
>     (root) /usr/sbin/rndc notify sflug.net

Thank you.  Likewise over the weekend, I'll finally make a proper note
of that, so I'm aware that I'm among the DNS admins for that.


FWIW, when we've tried solving the share-administration problem on
www.svlug.org, we used several principles:

1.  Two breadcrumb symlinks to critical places.   It was important
that every shell user, these being only members of the admin team,
know where the site-docs directory is, and where the system httpd
document tree is.  So, /etc/skel includes symlinks to be created in the
user's homedir, pointing to those places.

2.  The site-docs directory.  This is where admins are supposed to 
add dated entries to file ChangeLog about any significant action
they've taken.  Also, this is where, e.g., I wrote docs about how
we use NSD for authoritative DNS, including cheat-sheet tips about
how to do things.  Basically, site-docs houses locally written docs
files describing the www.svlug.org way of doing things, in hopes that
we admins won't trip each other up, and consult the team for consensus
on issues that come up.

The fly in the ointment is that some volunteer sysadmins are only barely
less allergic to reading and writing docs than are coders.
www.svlug.org went through significant breakage at times because one
admin (and I'm tempted to name the offender, but will be nice)
completely ignored site-docs, unilaterally decided to break root-user
login (and did absolutely nothing when I told him later that he'd broken
system backup), and unilaterally decided /var/www, /var/svn, and
/usr/local/site-docs are Bad and Wrong because latter FHS dictates some
/srv bushwah, which he implemented with a forest of symlinks, did NOT
inform everyone else of anything he did, and made zero annotations to
site-docs/ChangeLog.

When I found out much later (because he docmented nothing) about these
actions, I carefully retro-created dated site-docs/ChangeLog entries
describing what he did, then reverted all of his work and documented
that also to ChangeLog.  In short, the system works great except when 
an admin with poor impulse control  runs amok and completely ignores it.

3.  Version control.  Everything significant gets checked into svn
(not my choice of VCS).  



If you're not already using it on balug-sf-lug-v2, etckeeper makes a
dandy way of keeping all /etc/ changes including auth DNS ones recorded
into git.  Any /etc/ changes triggered by apt operations will be logged
there automagically.