We are using the free VMware Server on CentOS 4. Almost all of our VMs are CentOS 4 as well. We have 7 VMware hosts with about 40 total virtual machines. It's been a very successful architecture for us.
I'm wondering how the rest of the community is managing updates of root (and other local account) passwords in a virtual sprawl environment (or a physical environment with lots of hosts).
I have read about things like expect, puttycs, centralize with kerberos, etc.
But I'm not looking for "options" here, I want to hear actual experiences! What has worked for you, what hasn't worked? Or do you feel that the chance for failure is to great and the results too catastrophic?
Thanks,
Theres nothing unique about VM's vs. standard machine deployments, you're looking at a standard UNIX admin practice. I personally run cfengine for maintaining everything configuration-related across all *NIX'es, and LDAP/kerberos (via AD) for all non-root logins, across our entire enterprise. There are numerous ways to achieve "it" with varying levels of security, work, and knowledge required, but at the _simplest_ you could just maintain passwd/shadow/group/etc users via cfengine, or set up a basic NIS deployment for users (more trivial and easy to pick up than LDAP/.
The topic is more general than Centos/Xen, and you have an entire world of options in reality. Pick one that you're comfortable with and meets your needs after asking (which you are). If you ask a wide enough audience, you'll inevitably get pros/cons for each and every method, thus the requirement for you to do the research into them after.
So to answer as it sounds you want, I've been immensely happy with cfengine for handling anything you can conceive of as an administrator. If you can do something from a shell, you can do it with cfengine in a very complex manner. For authentication, I actually recommend Active Directory, the ONLY microsoft product I recommend. Unfortunately they don't have a Linux package :)
Cheers,
/eli
Jeff Larsen wrote:
We are using the free VMware Server on CentOS 4. Almost all of our VMs are CentOS 4 as well. We have 7 VMware hosts with about 40 total virtual machines. It's been a very successful architecture for us.
I'm wondering how the rest of the community is managing updates of root (and other local account) passwords in a virtual sprawl environment (or a physical environment with lots of hosts).
I have read about things like expect, puttycs, centralize with kerberos, etc.
But I'm not looking for "options" here, I want to hear actual experiences! What has worked for you, what hasn't worked? Or do you feel that the chance for failure is to great and the results too catastrophic?
Thanks,
-- Jeff _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Jeff Larsen wrote:
We are using the free VMware Server on CentOS 4. Almost all of our VMs are CentOS 4 as well. We have 7 VMware hosts with about 40 total virtual machines. It's been a very successful architecture for us.
I'm wondering how the rest of the community is managing updates of root (and other local account) passwords in a virtual sprawl environment (or a physical environment with lots of hosts).
I have read about things like expect, puttycs, centralize with kerberos, etc.
But I'm not looking for "options" here, I want to hear actual experiences! What has worked for you, what hasn't worked? Or do you feel that the chance for failure is to great and the results too catastrophic?
Puppet can control user attributes like passwords quite easily, provided you set it up right. http://www.reductivelabs.com/trac/puppet/wiki/PuppetRedHatCentos
CFengine can as well but not so elegantly as puppet which implements a provider model (users, group, packages, cronjobs etc)
"Jeff Larsen" jlar310@gmail.com writes:
I'm wondering how the rest of the community is managing updates of root (and other local account) passwords in a virtual sprawl environment (or a physical environment with lots of hosts).
I have read about things like expect, puttycs, centralize with kerberos, etc.
the way I've seen it done at every large installation I've worked is some sort of auto-pushed password files for authorization, but no valid passwords in the password file (except for root as explained below) the authentication is either handled with ssh public keys (authorized_keys files distributed via rsync or NFS) or with kerberos. I like kerberos, personally, but the ssh authorized_keys setup is harder to screw up, and it works fine as well.
As for the root password, the best practice is to make it so that the root password is *only* useful once you have console. (Of course we have all disabled remote root login with password long ago- disable su and prune /etc/securetty - force your SysAdmins to use ksu or sudo instead of su if they log in remotely, and log.) - if you do this correctly, the root password becomes much less sensitive, and you can keep it in the password files you rsync around.
I worked at one place that used the rsync of the password file and ~user/.ssh/authorized_keys setup that had tens of thousands of servers. the copy became a bit more complicated than just an rsync, but the system did scale.