Respecting cloning vm guests, I see in /etc/ssh the following:
ssh_host_dsa_key ssh_host_dsa_key.pub ssh_host_key ssh_host_key.pub ssh_host_rsa_key ssh_host_rsa_key.pub
Is there a simple script somewhere to regenerate all the server host keys for the new guest after cloning?
Hi James,
depending on your use case:
if you source is a template VM: just delete the keys prior to cloning in the source VM
if you source is a production VM: just delete the keys after cloning on the newly cloned VM
The keys will be regenerated on next startup of openssh if they're missing.
am Mittwoch, 4. Januar 2012 um 20:08 schrieben Sie:
Respecting cloning vm guests, I see in /etc/ssh the following:
ssh_host_dsa_key ssh_host_dsa_key.pub ssh_host_key ssh_host_key.pub ssh_host_rsa_key ssh_host_rsa_key.pub
Is there a simple script somewhere to regenerate all the server host keys for the new guest after cloning?
On 1/4/2012 11:31 AM, Thomas Göttgens wrote:
Hi James,
depending on your use case:
if you source is a template VM: just delete the keys prior to cloning in the source VM
if you source is a production VM: just delete the keys after cloning on the newly cloned VM
The keys will be regenerated on next startup of openssh if they're missing.
you should script all that (and the rest of the uinique things you want) into rc.local
On 01/04/2012 07:58 PM, Chaim Rieger wrote:
if you source is a template VM: just delete the keys prior to cloning in the source VM
you should script all that (and the rest of the uinique things you want) into rc.local
isnt rc.local run quite a bit later down the run order ?
Personally, I hate images. Provisioning from fresh is easy enough, fast enough and manageable enough that images are almost always either the wrong solution or a by-product requirement from a third party tool that does not understand provisioning ( hello, all those so-called-cloud solutions .. )
On Thu, 2012-01-05 at 15:05 +0000, Karanbir Singh wrote:
... Personally, I hate images. Provisioning from fresh is easy enough, fast enough and manageable enough that images are almost always either the wrong solution or a by-product requirement from a third party tool that does not understand provisioning ( hello, all those so-called-cloud solutions .. )
I feel this way too. However, many people espousing imaging are so adamant. I don't argue because it just isn't worth it. Whatever they feel comfortable with as long as I'm not responsible for the result.
On 01/05/2012 05:58 PM, Ed Heron wrote:
On Thu, 2012-01-05 at 15:05 +0000, Karanbir Singh wrote:
... Personally, I hate images. Provisioning from fresh is easy enough, fast enough and manageable enough that images are almost always either the wrong solution or a by-product requirement from a third party tool that does not understand provisioning ( hello, all those so-called-cloud solutions .. )
I feel this way too. However, many people espousing imaging are so adamant. I don't argue because it just isn't worth it. Whatever they feel comfortable with as long as I'm not responsible for the result.
It depends heavily on the ending result . If you just need a fresh machine, installing from fresh is ( was for me at least ) the fastest way. OTOH when you also have a ton of additional applications (maybe not all of them available as rpm packages) installed / configured... things might be different.
On Thu, 2012-01-05 at 18:15 +0200, Manuel Wolfshant wrote:
... It depends heavily on the ending result . If you just need a fresh machine, installing from fresh is ( was for me at least ) the fastest way. OTOH when you also have a ton of additional applications (maybe not all of them available as rpm packages) installed / configured... things might be different.
I can accept that custom applications might be easier to include in images. Creating a RPM or install script for a rarely installed program may not make the top of the priority list. However, if it is installed identically on multiple systems, it could be converted to rpm or a scripted install, which could be included in an automated clean install. As an example, I uuencode my current DHCP configuration, DNS files, firewall rules and openvpn certificates into a kickstart file to cleanly install my firewalls. Each is different but is scripted, partly in the scripts that create my kickstart files and partly in the kickstart post section.
On 01/05/2012 07:46 PM, Ed Heron wrote:
On Thu, 2012-01-05 at 18:15 +0200, Manuel Wolfshant wrote:
... It depends heavily on the ending result . If you just need a fresh machine, installing from fresh is ( was for me at least ) the fastest way. OTOH when you also have a ton of additional applications (maybe not all of them available as rpm packages) installed / configured... things might be different.
I can accept that custom applications might be easier to include in images. Creating a RPM or install script for a rarely installed program may not make the top of the priority list. However, if it is installed identically on multiple systems, it could be converted to rpm or a scripted install, which could be included in an automated clean install. As an example, I uuencode my current DHCP configuration, DNS files, firewall rules and openvpn certificates into a kickstart file to cleanly install my firewalls. Each is different but is scripted, partly in the scripts that create my kickstart files and partly in the kickstart post section.
My colleagues from the engineering dept ( I am IT... ) have to use a commercial application which comes as 2 CD images plus 3 sets of 2 isos with updates. All of which have to be installed (at last theoretically ) one after the other and only via their own Java-based installer. Guess who is not going to rpm-ize the process of installing that 8*450 MB piece of wonderful software.
And by the way, there are 50% chances that this piece of software was used in the process of design of your phone. At least if the phone was engineered after 2000.
On Thu, 2012-01-05 at 21:02 +0200, Manuel Wolfshant wrote:
... My colleagues from the engineering dept ( I am IT... ) have to use a commercial application which comes as 2 CD images plus 3 sets of 2 isos with updates. All of which have to be installed (at last theoretically ) one after the other and only via their own Java-based installer. Guess who is not going to rpm-ize the process of installing that 8*450 MB piece of wonderful software.
Nice. The company I work for uses some MS Windows software where the vendor won't even give me install software. They insist the user must call them to install. The user must log into their website to get access to the install software. I don't have a log in, so I don't pre-install that software. The users complain to me and I refer them to the vendor. Yes, some vendors are annoying.
It sounds like maybe you'd prefer clean installs but, due to real world compromises, you can't always do that.
And by the way, there are 50% chances that this piece of software was used in the process of design of your phone. At least if the phone was engineered after 2000.
On Thu, 5 Jan 2012, Karanbir Singh wrote:
Personally, I hate images. Provisioning from fresh is easy enough, fast enough and manageable enough that images are almost always either the wrong solution or a by-product requirement from a third party tool that does not understand provisioning ( hello, all those so-called-cloud solutions .. )
In time trials at PMman, we can deploy a minimal CentOS 5 or 6 base image in under three minutes from a standing start, already configured with local update archive addon, the needed LVM details, the needed network config settings, and all the rest; doing the same with anaconda and puppet takes about 15 minutes
There _are_ reasons for thoughtfully designed deployable 'stock' images
-- Russ herrold
Hi Karanbir,
Personally, I hate images. Provisioning from fresh is easy enough, fast enough and manageable enough that images are almost always either the wrong solution or a by-product requirement from a third party tool that does not understand provisioning ( hello, all those so-called-cloud solutions .. )
well, there IS at least one valid scenario, where you want to deploy an image in an environment not supported by anaconda/kickstart. A prime example is the ALIX mainboard series, where the boards usually come with soldered 128 or 256 MB RAM, CF Flash Reader and a AMD GeoDE processor.
I had fun rebuilding anaconda once to even bootstrap those (AMD GeoDE is somehow falsely recognized as i586 by CentOS 5.7), just to find out I had to add an additional USB key for swap to even get it to install. ( see http://bugs.centos.org/view.php?id=2552 for details )
There are ready-made CentOS images for these type of boards available on the net (ssh keys removed ;-) ) and these actually allow for an easy provisioning of the CF cards.
Sadly CentOS6 does not even support the processor any more.
On Wed, 2012-01-04 at 20:31 +0100, Thomas Göttgens wrote:
Hi James,
depending on your use case:
if you source is a template VM: just delete the keys prior to cloning in the source VM
if you source is a production VM: just delete the keys after cloning on the newly cloned VM
The keys will be regenerated on next startup of openssh if they're missing.
am Mittwoch, 4. Januar 2012 um 20:08 schrieben Sie:
Respecting cloning vm guests, I see in /etc/ssh the following:
ssh_host_dsa_key ssh_host_dsa_key.pub ssh_host_key ssh_host_key.pub ssh_host_rsa_key ssh_host_rsa_key.pub
Is there a simple script somewhere to regenerate all the server host keys for the new guest after cloning?
Is there a process for pre-generating keys so these keys and .ssh/known_hosts can be pre-filled for all users/hosts?
I dislike upgrading servers. I use kickstart from updated sources with integrated configuration files on a new virtual disk to produce an upgraded server without touching the live server. This gives me the chance to test the new server prior to making it live and verifies I can reproduce a failed server at need. Also, this allows me to restage firewalls automatically on a schedule. Let's see a rootkit survive a clean install.
Currently, I'm allowing the keys to be regenerated, but it gets annoying editing my known hosts to remove old entries.
There's got to be a better way.
On 01/04/2012 08:14 PM, Ed Heron wrote:
Is there a process for pre-generating keys so these keys and .ssh/known_hosts can be pre-filled for all users/hosts?
yes there is..
look at the sshd initscript, and poke the do_*_keygen functions; they will tell you exactly what happens when those keys are auto-build on first boot, or when someone removes them.
I use config-management tools in the kickstart %post to drop in pre-built keys, that also means my management infrastructure already knows what key-signature to expect on a remote machine when it boots for the first time and I can do some level of trust management based on that. Keep in mind that you need to have your provisioning happen in a fairly secure environment itself, if you are going to add trust points on signatures like this - specially if they are 'generated' on demand.
On Thu, 2012-01-05 at 15:09 +0000, Karanbir Singh wrote:
... Keep in mind that you need to have your provisioning happen in a fairly secure environment itself, if you are going to add trust points on signatures like this - specially if they are 'generated' on demand.
Other than installing from a separate network, which is difficult with multiple locations and virtual machines (creating them in a central place then transferring them across the Internet seems unwieldy), what steps can we take to secure the provisioning?
On Wed, January 4, 2012 14:08, James B. Byrne wrote:
Is there a simple script somewhere to regenerate all the server host keys for the new guest after cloning?
The init script /etc/rc.d/init.d/sshd handles it.
I discover that simply removing the existing ssh keys from /etc/ssh and restarting the sshd service causes the host keys to be regenerated.
Another step to add to post cloning housekeeping.
-
Chaim Rieger -
Ed Heron -
James B. Byrne -
Karanbir Singh -
Manuel Wolfshant -
R P Herrold -
Thomas Göttgens