On 14 Jul 2014, at 16:54, Nux! <nux at li.nux.ro> wrote: > ----- Original Message ----- >> From: "Karanbir Singh" <mail-lists at karan.org> >> To: centos-devel at centos.org >> Sent: Monday, 14 July, 2014 4:32:18 PM >> Subject: Re: [CentOS-devel] Cloud image default login >> >> On 07/14/2014 04:27 PM, Daniel Ankers wrote: >>> As a user, I'd like to be able to take any set of instructions about >>> RHEL and s/RHEL/CentOS/g and have it work (with the exception of all the >>> things people pay RedHat good money for, of course.) >> >> in the cloud images they wont, we built our own images ( always have ) >> and have implemented our own policy. >> >> I guess once rhel images show up for opennebula and in linode, we can >> start trying to work together a bit more. >> >> my point really is - lets find the best place to be, without needing to >> just blindly work with what / where rhel is and what they are doing > > Maybe it would be good, for a while, to have both root and cloud-user accounts active? Not sure how this would actually work in reality (ie how the cloud platforms and supporting scripts would deal with it). > > In my case, building Cloudstack templates, there is a whole lot of people expecting root to be active, changing this behaviour would mean screwing them over. > If CentOS also has this kind of legacy problems - which I expect to be true - then it's something to be thinking about. > > If this is not deemed a problem, then it would be nice to have the same sort of consistency between RHEL, CentOS and Fedora in this regard. > The default in cloud is to have a locked root user and use sudo for root operations from a non-privileged user. That’s how Ubuntu does it, and it is how the Fedora image does it. And it is what cloud-init expects to see which is what will link into the public metadata systems on the public clouds. The default for username should really be ‘centos’ I think. That fits with the other distros who name the user after themselves. The other thing that needs fixing is ‘cloud-init’ which currently doesn’t detect Enterprise Linux clones using systems properly and makes a hash of a few things. I logged a bug today about it: https://bugs.launchpad.net/cloud-init/+bug/1341508 Bear in mind that cloud-init creates the user as specified in the default cloud-config and locks the root user by default. The kickstart script I knocked together today just creates the root user with a default password, locks the password in the %post (to work around a limitation in anaconda which demands a user if you use —lock) and then leaves the user creation to cloud-init. That’s certainly what would make the image most useful here.