Hi Andy,
I appreciate these comments.
While I recognize that if the root user is properly locked down, sharing a
password would be acceptable. Unfortunately, I cannot wield that level of
control over all our systems.
In the end, I have decided to forgo the /etc/shadow file and depend on the
/etc/passwd to alert me to local user creates. I will re-address it when
either:
* We put up a config management server
* Spacewalk supports logic and/or wildcards in its config management macros
WB
On April 28, 2015 01:25:36 PM Andy Ingham wrote:
> Will --
>
> Your use cases seem similar to what we've implemented here. That is, the
> versioning isn't as full-featured as something like git, but serves the
> purpose well of validating that key files haven't changed across the plant
> (I've got a daily script that leverages the spacewalk API to flag the
> files that are no longer in spec.)
>
> You are also correct that it isn't close to the power of puppet, but
> certainly is much lighter-weight and quicker to deploy (again, for a
> specific use-case).
>
> On the subject of root passwords: is it important to your organization to
> have DIFFERENT root passwords for each of your servers? (Yes, I'm
> serious!) If you disallow remote root login (which you should!), and
> leverage "sudo" for elevating privileges (with users' using their OWN
> password), the root passwords are never really used / exposed. In such a
> case, it's much easier to manage if they are all the same.
>
> (Which leads me back to ansible...) If having them the same makes you (or
> your bosses) insist on CHANGING those passwords more frequently, I'd
> suggest using ansible to do so. It's worked GREAT for us here. (It's a
> fast enough process that you could change your root passwords once a
> MONTH, if that's what would make folks happy.)
>
> Changing root passwords across the plant via ansible:
>
> Create a pseudo-random salt to use for the password hashing:
> [root@HOSTXYZ ~]# python
>
> >>> import os
> >>> os.urandom(32).encode('base_64')
>
> '+Ks4YQAwuHLotW6PX/+9Tzf0B8HQmF43Kr/NpLcyJDE=\n'
>
> The output of the step above provides the INPUT for the next set of
> commands (see right AFTER "$1$" below)
>
> Create a hash of the new password using python's crypt function (see
> also
> http://mjanja.co.ke/2013/01/generate-salted-shadow-hashes-using-python-cryp
>
> t/ ). E.g.:
> >>> import crypt
>
> crypt.crypt("mysupertoughpassword",'$1$+Ks4YQAwuHLotW6PX/+9Tzf0B8HQmF43Kr/N
> pLcyJDE=\n')
> '$1$+Ks4YQAw$l0aKYjp7tZinnU25B.KfN0'
>
> >>> quit()
>
> The output of the step above allows for the needed INPUT to ansible
> below:
> ansible HOSTS_LISTED_HERE -m user -a 'name=root
> password=$1$+Ks4YQAw$l0aKYjp7tZinnU25B.KfN0' -K --sudo
>
>
>
> Just some thoughts...
>
>
> Andy
>
> On 4/27/15, 12:02 PM, "Will Beldman" wrote:
>
> I'm trying to do a better job in my organization managing changes to
> configuration files.
>
> Most of our authentication and authorization I'd like to defer to LDAP so
> I
> figured monitoring some local user management config files would be a good
> start (eg. /etc/passwd, /etc/shadow, /etc/group). My idea was that if a
> sysadmin tried to add a local user, Spacewalk could alert me to the change
> because it would no longer match my centrally manged files.
>
> However, I've already realized that I have a problem with my /etc/shadow
> file
> because the hash associated with the root password will obviously be
> different
> for every machine so I cannot manage it centrally.
>
> I tried to use macros like so:
> =
> root:{| rhn.system.custom_info(root_hash) |}::0:9:7:::
> ...
> =
> and this works but I've realized that this means I am loading the root
> password hash onto every system as a custom info value which is probably
> not a
> good idea security-wise. If my Spacewalk server were compromised, the
> /etc/shadow file for every system is also compromised.
>
> Is there any ability to do things like ignore certain lines or put in
> regex
> wildcards so I can just say "put whatever you want in here"? Or is there a
> feature request for this?
>
>
> Also, can I get some idea, philosophically, on how to leverage config
> management in Spacewalk to it's potential. I think I really need to put up
> a
> config management server (Puppet/Chef/etc) to do what I really want, but
> in
> the interim, I was hoping to get some ideas on common uses for config
> management in Spacewalk.
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
--
*Will Beldman*
*Systems and Database Administrator (ITS)*
*Weste
