[sf-lug] sudo, sysadmin, ... Re: 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

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [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
> Date: Sat, 13 Apr 2019 01:49:52 -0700

> For those watching at home, that's reported by 'sudo -l -U rick'.

Yep.  Very handy, for those with access (e.g. root), to check what
sudo access any given user/login account has.
"Of course" users can check themselves what sudo access they have,
e.g.:
$ sudo -l
And that may or may not require password to check that, depending upon
configuration.
I not uncommonly get users saying stuff like, "I need sudo access to ...
I try to run
$ sudo /whatever/
And it doesn't work."  And I often reply,
"What does:
$ sudo -l
Show you?"
Very often they already have the access they need, but they're not
entering the command properly to match the sudo access they have.
E.g. they can run:
$ sudo su - some_app_id
but they're trying:
$ sudo su some_app_id
or other semi-random stuff they thought of or made up that just doesn't
(quite) match their actual permitted existing access.

# sudo -l -U /user/
Is also semi-handy for auditing / checking sudo access.  Though one can
(also) look over the sudoers files, depending on (lack of) numbers of
users and other factors, sometimes easier to check one way, rather
than the other - or use
# sudo -l -U /user/
to (at least statistically) validate that users can/can't do what one
is presuming (/ has "concluded") based upon the sudoers files.

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

Not nearly as applicable now, but more so once-upon-a-time, had fairly
effective set of rules/policy for the shared sysadmin access stuff
of vicki (and possibly also whatever predated that) ...
was (much) earlier, a single hardware machine, covering much of SF-LUG,
plus also fair bit of BALUG, and some other stuff too.  Then it went to
another physical host, with (at least) two virtuals therupon - sflug and
balug for SF-LUG and BALUG respectively.  Anyway, that was then
(and "way back" then).
Anyway, most of that older policy stuff can be seen here:
https://www.wiki.balug.org/wiki/doku.php?id=system:system_administration_rules_of_the_road_this_box
and also some of the links/references from there, notably for some
even older historical bits.

Nowadays, it's (mostly?) a fair bit simpler.  SF-LUG resources ...
there's some slaves, there's list - which is mostly benevolently
dictated by Rick on linuxmafia.org, and there's the other SF-LUG
bits - notably web, DNS master(s), etc. - I (benevolently?) dictate
on those - they're on a VM which exists primarily for serving the
purposes of BALUG ... but does also have a bunch 'o SF-LUG
bits (e.g. in addition to the aforementioned, backups of SF-LUG
list mbox and roster data).  As for SF-LUG registrar stuff,
there's SF-LUG.org (thus far, and as far as I'm aware, still canonical
(www.sf-lug.org)), and sf-lug.com, both on Joker.com, with Jim and myself
having access there (and no way to make the customary whois data public
on Joker.com).  The 3 newer, on GoDaddy - Al's got access - don't know
that that's been extended yet.

> 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.

Yeah, I've not done the etckeeper thingy ... mostly backups, & RCS.
Sometimes lots of RCS.
# hostname && find /etc/apache2 -name '*,v' -type f -print | wc -l
balug-sf-lug-v2.balug.org
138
# find /etc/bind*/ -follow -name '*,v' -type f -print | wc -l
17
# find ~balug -name '*,v' -type f -print | wc -l
5
#