Hello everybody,
I'm interested in participating in the Cloud Instance SIG and help provide official CentOS images for the Synnefo open source cloud platform:
which is built on top of Google Ganeti:
https://code.google.com/p/ganeti/
Currently, we are providing to our users our 'system' CentOS image which is just a bundle of the official CentOS iso. The image file is just a raw dump of a disk.
Synnefo does not require any special software running inside the image (e.g.: cloud-init) to take care of customization. All customization (setting passwords, hostnames, injecting files, SSH keys, resizing, etc) is done by Synnefo itself in an isolated, virtualized environment for maximum security before spawning the actual VM.
So, it would be nice to just redirect our users to the CentOS official image for Synnefo and Ganeti :)
Hope to take part in this.
Thanks, Constantinos
Hello again,
after a discussion on #centos-devel, I'm writing down here the way we create our 'system' CentOS image for Synnefo:
[Quoting from our internal wiki]
--- cut here ---
CentOS is a basic (minimal) CentOS 6.5 system which was created using the netinstall CD (CentOS-6.5-x86_64-netinstall.iso).
Extra configuration:
1.Full update
yum update yum upgrade
2.Install and start acpid
yum install acpid service acpid start chkconfig acpid on
3.Clean the yum cache
yum clean all
4.Remove the HWADDR line from /etc/sysconfig/network-scripts/ifcfg-eth0 5.Delete udev rule for persistent nic names
rm /etc/udev/rules.d/70-persistent-net.rules
6.Install and run ntp deamon
yum install ntp chkconfig ntpd on
In /etc/ntp.conf put the servers of a specific zone
7.Disable time dependent file system checking
tune2fs -i 0 /dev/vda1
8.Install network manager
yum install NetworkManager
9.Allow DHCPv6 responses in the firewall 10.Unhide the GRUB menu, by commenting out the hiddenmenu option in /etc/grub/menu.lst
--- cut here ---
After the above steps, the image is ready to get spawned on any Synnefo deployment and will get customized automatically.
So, do you think it is possible for you guys to have such an 'official' CentOS image targeted for Synnefo?
Thanks, Constantinos
On 02/10/2014 04:03 PM, Constantinos Venetsanopoulos wrote:
Hello everybody,
I'm interested in participating in the Cloud Instance SIG and help provide official CentOS images for the Synnefo open source cloud platform:
which is built on top of Google Ganeti:
https://code.google.com/p/ganeti/
Currently, we are providing to our users our 'system' CentOS image which is just a bundle of the official CentOS iso. The image file is just a raw dump of a disk.
Synnefo does not require any special software running inside the image (e.g.: cloud-init) to take care of customization. All customization (setting passwords, hostnames, injecting files, SSH keys, resizing, etc) is done by Synnefo itself in an isolated, virtualized environment for maximum security before spawning the actual VM.
So, it would be nice to just redirect our users to the CentOS official image for Synnefo and Ganeti :)
Hope to take part in this.
Thanks, Constantinos
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 02/18/2014 04:48 AM, Constantinos Venetsanopoulos wrote:
<snip> There doesn't seem to be anything here that couldn't be addressed with a decent post script in a kickstart
After the above steps, the image is ready to get spawned on any Synnefo deployment and will get customized automatically.
So, do you think it is possible for you guys to have such an 'official' CentOS image targeted for Synnefo?
I think we can probably do this, though this is more image customization, rather than code modification. It wouldn't require code changes or custom package inclusion like some of the other cloud sig initiatives.
Hello Jim,
On 02/19/2014 07:28 PM, Jim Perrin wrote:
On 02/18/2014 04:48 AM, Constantinos Venetsanopoulos wrote:
<snip> There doesn't seem to be anything here that couldn't be addressed with a decent post script in a kickstart > After the above steps, the image is ready to get spawned on > any Synnefo deployment and will get customized automatically. > > So, do you think it is possible for you guys to have such an > 'official' CentOS image targeted for Synnefo? I think we can probably do this, though this is more image customization, rather than code modification. It wouldn't require code changes or custom package inclusion like some of the other cloud sig initiatives.
That sounds good. Yes, code modification is not needed for images to run on Synnefo, that's why I thought it will be probably rather easy for anyone of you guys who has experience with kickstart and rpm-based distros to help. We can have an official CentOS image for Synnefo with not so much of an effort.
Unfortunately, my team comes from a Debian background and we have zero experience with kickstart :( However, we are willing to help however we can.
So, what do you think are the next steps?
Thanks, Constantinos
On 02/20/2014 06:18 AM, Constantinos Venetsanopoulos wrote:
Hello Jim,
Unfortunately, my team comes from a Debian background and we have zero experience with kickstart :( However, we are willing to help however we can.
So, what do you think are the next steps?
I'm traveling to scale12x this weekend, but when I get back, I can work with you on generating an appropriate kickstart filed that we can run through our build system. We'll probably go back and forth a bit between generating and testing images, and then we'll be able to push to cloud.centos.org.
If anyone else on the devel list wants to pick this up before Tuesday that would work also.
On 02/20/2014 02:42 PM, Jim Perrin wrote:
On 02/20/2014 06:18 AM, Constantinos Venetsanopoulos wrote:
Hello Jim, Unfortunately, my team comes from a Debian background and we have zero experience with kickstart :( However, we are willing to help however we can.
So, what do you think are the next steps?
I'm traveling to scale12x this weekend, but when I get back, I can work with you on generating an appropriate kickstart filed that we can run through our build system.
That's sounds good. Hope you have a nice time at scale12x.
We'll probably go back and forth a bit between generating and testing images, and then we'll be able to push to cloud.centos.org.
Of course, that sounds reasonable. We will be able to test the images on our demo Synnefo infrastructure too, so that you (or anyone else from your team) can have access and see it working:
Thanks a lot for your help. Hope to work with you soon, Constantinos
If anyone else on the devel list wants to pick this up before Tuesday that would work also.
On 02/20/2014 02:42 PM, Jim Perrin wrote:
On 02/20/2014 06:18 AM, Constantinos Venetsanopoulos wrote:
Hello Jim, Unfortunately, my team comes from a Debian background and we have zero experience with kickstart :( However, we are willing to help however we can.
So, what do you think are the next steps?
I'm traveling to scale12x this weekend, but when I get back, I can work with you on generating an appropriate kickstart filed that we can run through our build system. We'll probably go back and forth a bit between generating and testing images, and then we'll be able to push to cloud.centos.org.
If anyone else on the devel list wants to pick this up before Tuesday that would work also.
Hello
Something along the attached kickstart file should do it. It needs a bit of tweaking ( especially partitions wise and obviously password-wise) and maybe for persuading it to not install all the firmware meant for Wi-Fi cards.
Manuel
Hi,
On Thu, Feb 20, 2014 at 04:00:48PM +0200, Manuel Wolfshant wrote:
#pay attention to the comments inline !!
...
part /boot --fstype ext3 --size=250 part pv.2 --size=5000 --grow volgroup VolGroup00 --pesize=32768 pv.2 logvol / --fstype ext4 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=256 --grow --maxsize=512
http://www.synnefo.org/docs/snf-image-creator/latest/usage.html#some-caveats... Warning
During the installation, you will be asked about the partition scheme. Don’t use LVM partitions. They are not supported by snf-image-creator.
-> Not sure if that applies here.
http://www.synnefo.org/docs/snf-image-creator/latest/usage.html#image-partit...
When image shrinking is enabled, snf-image-creator will shrink the last partition on the disk. If this is a swap partition, it will remove it, save enough information to recreate it during image deployment and shrink the partition that lays just before that. This will make the image smaller which speeds up the deployment process.
During image deployment, the last partition is enlarged to occupy the available space in the VM’s hard disk and a swap partition is added at the end if a SWAP image property is present.
-> Maybe a single / partition and a possible swap space at the end ?
part / --fstype ext4 --size=1000 --asprimary --ondisk=sda part swap --size=128 --asprimary --ondisk=sda --fstype swap
Cheers,
Tru
Hello Manuel, Tru,
first of all thanks for the quick replies. See comments inline.
On 02/20/2014 04:21 PM, Tru Huynh wrote:
Hi,
On Thu, Feb 20, 2014 at 04:00:48PM +0200, Manuel Wolfshant wrote:
#pay attention to the comments inline !!
...
part /boot --fstype ext3 --size=250 part pv.2 --size=5000 --grow volgroup VolGroup00 --pesize=32768 pv.2 logvol / --fstype ext4 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=256 --grow --maxsize=512
http://www.synnefo.org/docs/snf-image-creator/latest/usage.html#some-caveats... Warning
During the installation, you will be asked about the partition scheme. Don’t use LVM partitions. They are not supported by snf-image-creator.
-> Not sure if that applies here.
http://www.synnefo.org/docs/snf-image-creator/latest/usage.html#image-partit...
When image shrinking is enabled, snf-image-creator will shrink the last partition on the disk. If this is a swap partition, it will remove it, save enough information to recreate it during image deployment and shrink the partition that lays just before that. This will make the image smaller which speeds up the deployment process.
During image deployment, the last partition is enlarged to occupy the available space in the VM’s hard disk and a swap partition is added at the end if a SWAP image property is present.
-> Maybe a single / partition and a possible swap space at the end ?
part / --fstype ext4 --size=1000 --asprimary --ondisk=sda part swap --size=128 --asprimary --ondisk=sda --fstype swap
The above docs have to do with the 'snf-image-creator' tool which we use to create our images. After the image is prepared this tool does not get in the path. The image gets deployed and customized by the 'snf-image' tool:
http://www.synnefo.org/docs/snf-image/latest/
However, since snf-image does not operate on LVM partitions, that's why snf-image-creator doesn't support LVM too.
Regarding swap:
The image doesn't need to have a swap partition, since snf-image has a corresponding option to add one dynamically. That's why snf-image-creator removes the swap if it finds it at the end and sets that property accordingly during registration of the image. If the swap is not at the end, it leaves it as is. So, the best thing to do in our case is to *not* have any swap at all in the image.
Thanks, Constantinos
P.S.: snf-image's SWAP property should have been documented here: http://www.synnefo.org/docs/snf-image/latest/interface.html#image-properties... but I just saw it's missing. We'll be patching the docs right away.
Cheers,
Tru
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 02/20/2014 04:55 PM, Constantinos Venetsanopoulos wrote:
Hello Manuel, Tru,
first of all thanks for the quick replies. See comments inline.
I have attached a revised version of the kickstart. This time it really does not install the firmware for Wi-Fi and other exotic cards and the partitioning is adjusted as discussed (one /boot, one / which spawns all disk ( remove --grow if this is not intended ) and no swap). I have also modified vda into sda in the %post section, I assume that if sda is used at install time it's also what should get tuned.
Manuel
On 20.02.2014 16:54, Manuel Wolfshant wrote:
On 02/20/2014 04:55 PM, Constantinos Venetsanopoulos wrote:
Hello Manuel, Tru,
first of all thanks for the quick replies. See comments inline.
I have attached a revised version of the kickstart. This time itreally does not install the firmware for Wi-Fi and other exotic cards and the partitioning is adjusted as discussed (one /boot, one / which spawns all disk ( remove --grow if this is not intended ) and no swap). I have also modified vda into sda in the %post section, I assume that if sda is used at install time it's also what should get tuned.
If this is targeting KVM specifically then I'd look also at other optimizations: 1. leave swap out - I understand this is done already 2. wipe out the SSH keys, the random seed, optionally touch /.autorelabel to force a selinux relabel upon next boot (this takes a time and cpu) 3. install tuned with virtual-guest profile 4. disable tso and gso on the virtual nic and wipe out /etc/udev/rules.d/70-persistent-net.rules 5. run ntp & ntpdate 6. enable serial tty for `virsh console` access if needed etc
Most of the above I do in the following ks for cloudstack http://li.nux.ro/download/cloudstack/ks/CentOS6_64bit_password_sshkey.ks
On 20 februarie 2014 20:31:35 EET, Nux! nux@li.nux.ro wrote:
On 20.02.2014 16:54, Manuel Wolfshant wrote:
On 02/20/2014 04:55 PM, Constantinos Venetsanopoulos wrote:
Hello Manuel, Tru,
first of all thanks for the quick replies. See comments inline.
I have attached a revised version of the kickstart. This time itreally does not install the firmware for Wi-Fi and other exotic cards and the partitioning is adjusted as discussed (one /boot, one / which spawns all disk ( remove --grow if this is not intended ) and no swap). I have also modified vda into sda in the %post section, I assume that if sda is used at install time it's also what should get tuned.
If this is targeting KVM specifically then I'd look also at other optimizations:
- leave swap out - I understand this is done already
Correct. There is no swap.
- wipe out the SSH keys, the random seed,
Right after install there are no keys and seed. All these get created when the sshd service is started for the first time
optionally touch /.autorelabel to force a selinux relabel upon next boot (this takes a time and cpu)
AFAIK, right after install all labels should be correct
- install tuned with virtual-guest profile
That can be done, if needed.
- disable tso and gso on the virtual nic
That can be done,too
and wipe out /etc/udev/rules.d/70-persistent-net.rules
Already done
- run ntp & ntpdate
Already done
- enable serial tty for `virsh console` access if needed
That can be done,too
etc
Most of the above I do in the following ks for cloudstack http://li.nux.ro/download/cloudstack/ks/CentOS6_64bit_password_sshkey.ks
On 02/20/2014 07:26 PM, Manuel Wolfshant wrote:
and wipe out /etc/udev/rules.d/70-persistent-net.rules
Already done
ou need to also create a dummy 75- policy so its not created first instance ( gets in the way of snapshot, re-deploy )
On 20.02.2014 20:37, Karanbir Singh wrote:
On 02/20/2014 07:26 PM, Manuel Wolfshant wrote:
and wipe out /etc/udev/rules.d/70-persistent-net.rules
Already done
ou need to also create a dummy 75- policy so its not created first instance ( gets in the way of snapshot, re-deploy )
What should this dummy policy contain? From what I've seen, `echo > /etc/udev/rules.d/70-persistent-net.rules` does the job.
And yes, it would be a great idea to have a kickstart snippet to apply to all VM images and optimise these things.
On 02/20/2014 11:18 PM, Nux! wrote:
On 20.02.2014 20:37, Karanbir Singh wrote:
On 02/20/2014 07:26 PM, Manuel Wolfshant wrote:
and wipe out /etc/udev/rules.d/70-persistent-net.rules
Already done
ou need to also create a dummy 75- policy so its not created first instance ( gets in the way of snapshot, re-deploy )
What should this dummy policy contain? From what I've seen, `echo > /etc/udev/rules.d/70-persistent-net.rules` does the job.
that would do it, but adding a comment in there might be a good idea eg. : #stop a persistent mac addy being expected for netdev or something such
On 02/20/2014 06:31 PM, Nux! wrote:
Most of the above I do in the following ks for cloudstack http://li.nux.ro/download/cloudstack/ks/CentOS6_64bit_password_sshkey.ks
how does all this tie in with the AWS image optimisation guide and the Red Hat Virt tunning guides ? it would be good to get a snippet of code we just share across all the kickstarts with those bits already done.
Also, i see that root login isnt being locked or key enforced, both generally good things to do here.
On 20.02.2014 20:36, Karanbir Singh wrote:
Also, i see that root login isnt being locked or key enforced, both generally good things to do here.
If you run pure openstack or on amazon, if you sell VPSes, not so good (instantly dubles or triples your support requests). Even Rackspace gives you a root password afaik.
On 02/20/2014 11:16 PM, Nux! wrote:
On 20.02.2014 20:36, Karanbir Singh wrote:
Also, i see that root login isnt being locked or key enforced, both generally good things to do here.
If you run pure openstack or on amazon, if you sell VPSes, not so good (instantly dubles or triples your support requests). Even Rackspace gives you a root password afaik.
I seriously hope you are not right and they dont have a single default password, but use some mechanism to inject one at image instantiation
On 20.02.2014 23:34, Karanbir Singh wrote:
On 02/20/2014 11:16 PM, Nux! wrote:
On 20.02.2014 20:36, Karanbir Singh wrote:
Also, i see that root login isnt being locked or key enforced, both generally good things to do here.
If you run pure openstack or on amazon, if you sell VPSes, not so good (instantly dubles or triples your support requests). Even Rackspace gives you a root password afaik.
I seriously hope you are not right and they dont have a single default password, but use some mechanism to inject one at image instantiation
That's not what you asked. :) My ks does not lock the root password nor does it enforce ssh key only, people want to be able to log in as root. First of all this is a cloudstack template so a root password will be set at first boot, second the root password is set to a random 32 char value (check the ks).
On 02/20/2014 04:54 PM, Manuel Wolfshant wrote:
I have attached a revised version of the kickstart. This time itreally does not install the firmware for Wi-Fi and other exotic cards and the partitioning is adjusted as discussed (one /boot, one / which spawns all disk ( remove --grow if this is not intended ) and no swap). I have also modified vda into sda in the %post section, I assume that if sda is used at install time it's also what should get tuned.
wondering why the multilib policy line - its set to best anyway by default.
- KB
Hello everybody,
On 02/27/2014 06:14 PM, Karanbir Singh wrote:
On 02/20/2014 04:54 PM, Manuel Wolfshant wrote:
I have attached a revised version of the kickstart. This time itreally does not install the firmware for Wi-Fi and other exotic cards and the partitioning is adjusted as discussed (one /boot, one / which spawns all disk ( remove --grow if this is not intended ) and no swap). I have also modified vda into sda in the %post section, I assume that if sda is used at install time it's also what should get tuned.
wondering why the multilib policy line - its set to best anyway by default.
- KB
Just wanted to announce that Synnefo now officially supports CentOS 6.5. You can check it out here:
This image was made by our team with our own tools, though. The procedure described on this thread was followed, to create this image.
So, how do you think we can proceed with an official CentOS image from you guys? Should we start testing some CentOS images built with your kickstart+virt-install mechanism?
Until then, would you like us to somehow provide you our CentOS 6.5 image for you to distribute?
Thanks, Constantinos
On 03/10/2014 12:00 PM, Constantinos Venetsanopoulos wrote:
So, how do you think we can proceed with an official CentOS image from you guys? Should we start testing some CentOS images built with your kickstart+virt-install mechanism?
I will have some testing images up by this weekend, that would be the best place to start from .
On 03/10/2014 02:10 PM, Karanbir Singh wrote:
On 03/10/2014 12:00 PM, Constantinos Venetsanopoulos wrote:
So, how do you think we can proceed with an official CentOS image from you guys? Should we start testing some CentOS images built with your kickstart+virt-install mechanism?
I will have some testing images up by this weekend, that would be the best place to start from .
That sounds great.
Looking forward to start testing, thanks, Constantinos
On 02/20/2014 08:00 AM, Manuel Wolfshant wrote:
On 02/20/2014 02:42 PM, Jim Perrin wrote:
On 02/20/2014 06:18 AM, Constantinos Venetsanopoulos wrote:
Hello Jim, Unfortunately, my team comes from a Debian background and we have zero experience with kickstart :( However, we are willing to help however we can.
So, what do you think are the next steps?
I'm traveling to scale12x this weekend, but when I get back, I can work with you on generating an appropriate kickstart filed that we can run through our build system. We'll probably go back and forth a bit between generating and testing images, and then we'll be able to push to cloud.centos.org.
If anyone else on the devel list wants to pick this up before Tuesday that would work also.
Hello
Something along the attached kickstart file should do it. It needs abit of tweaking ( especially partitions wise and obviously password-wise) and maybe for persuading it to not install all the firmware meant for Wi-Fi cards.
Manuel
Thanks a ton for taking this on and revising it!
-
Constantinos Venetsanopoulos -
Jim Perrin -
Karanbir Singh -
Manuel Wolfshant -
Nux! -
Tru Huynh