hi Guys,
As we get ready to start publishing Cloud Images ( or rather images consumable in various virt platforms, including public and private clouds ) - it would be great to have a baseline package manifest worked out.
What / how many images should we build. At this time we were thinking of doing :
- CentOS-5 32bit minimal - CentOS-6 32bit minimal
- CentOS-5 64bit minimal - CentOS-6 64bit minimal
- CentOS-5 64bit LAMP - CentOS-6 64bit LAMP
What would be the minimal functional requirements people would expect from these images ? and what rpms should be installed ? Should root login be enabled or should we require people to go in via a 'centos' user. Should the image be self-updating, or should we have a post-login message that indicates outstanding updates ?
On 03.10.2012 17:29, Karanbir Singh wrote:
hi Guys,
As we get ready to start publishing Cloud Images ( or rather images consumable in various virt platforms, including public and private clouds ) - it would be great to have a baseline package manifest worked out.
What / how many images should we build. At this time we were thinking of doing :
CentOS-5 32bit minimal
CentOS-6 32bit minimal
CentOS-5 64bit minimal
CentOS-6 64bit minimal
CentOS-5 64bit LAMP
CentOS-6 64bit LAMP
What would be the minimal functional requirements people would expect from these images ? and what rpms should be installed ? Should root login be enabled or should we require people to go in via a 'centos' user. Should the image be self-updating, or should we have a post-login message that indicates outstanding updates ?
Hi,
Since I've already been messing with such images I kind of know what I need: 1 - acpid, so virsh reboot/shutdown will work 2 - cloud-init for openstack images; also it would be nice if the image could resize itself at first boot 3 - nano & wget to make the life easier for newbies
I don't think it's worth the effort to build Centos LAMP images, since it's just Centos minimal + "yum install httpd mysql-server php-mysql etc".
Greetings,
On Wed, Oct 3, 2012 at 10:18 PM, Nux! nux@li.nux.ro wrote:
What / how many images should we build. At this time we were thinking of doing :
CentOS-5 32bit minimal
CentOS-6 32bit minimal
CentOS-5 64bit minimal
CentOS-6 64bit minimal
CentOS-5 64bit LAMP
CentOS-6 64bit LAMP
How about a build with all the repos (automatically updating itself say using CR) in place... kinda local repo image for remaining images...
Can't describe it precisely...
On 10/03/2012 06:15 PM, Rajagopal Swaminathan wrote:
How about a build with all the repos (automatically updating itself say using CR) in place... kinda local repo image for remaining images...
Do you mean like a mirror.centos.org image ? that you can deploy and then use as an update source for the other images ? That is kinda of in the plan as well...
The idea there was to backload something like this into a mirrormanager sort of interface, so you could set some sort of meta parameters and have your own images only hit your own Mirror image. It needs a bit of working knowledge of the specific cloud its targeting though.
hi,
On 10/03/2012 05:48 PM, Nux! wrote:
Since I've already been messing with such images I kind of know what I need: 1 - acpid, so virsh reboot/shutdown will work 2 - cloud-init for openstack images; also it would be nice if the image could resize itself at first boot 3 - nano & wget to make the life easier for newbies
Great feedback. i think we can make all of those 3 things happen
I don't think it's worth the effort to build Centos LAMP images, since it's just Centos minimal + "yum install httpd mysql-server php-mysql etc".
there is that as well
On 03.10.2012 22:23, Karanbir Singh wrote:
hi,
On 10/03/2012 05:48 PM, Nux! wrote:
Since I've already been messing with such images I kind of know what I need: 1 - acpid, so virsh reboot/shutdown will work 2 - cloud-init for openstack images; also it would be nice if the image could resize itself at first boot 3 - nano & wget to make the life easier for newbies
Great feedback. i think we can make all of those 3 things happen
Lovely! I'm currently working on a kickstart file that would install and prepare images for openstack deployment, will update you when it's done (I'm almost there, need to polish a bit the partition resizing bit).
On 10/03/2012 10:33 PM, Nux! wrote:
I'm currently working on a kickstart file that would install and prepare images for openstack deployment, will update you when it's done (I'm almost there, need to polish a bit the partition resizing bit).
Cool, I've been playing with Euca and ONE the last few days - my cloudstack install hit a bit of a roadblock ( my issue, nothing to do with cloudstack itself ).
kickstarts, along with anything else, appreciated with thanks
On 10/03/2012 10:38 PM, Karanbir Singh wrote:
kickstarts, along with anything else, appreciated with thanks
and we should have git repo's up soon
On 03.10.2012 22:38, Karanbir Singh wrote:
On 10/03/2012 10:33 PM, Nux! wrote:
I'm currently working on a kickstart file that would install and prepare images for openstack deployment, will update you when it's done (I'm almost there, need to polish a bit the partition resizing bit).
Cool, I've been playing with Euca and ONE the last few days - my cloudstack install hit a bit of a roadblock ( my issue, nothing to do with cloudstack itself ).
kickstarts, along with anything else, appreciated with thanks
http://li.nux.ro/download/openstack/ks/centos6_x86_64_minimal.ks
I know, it's a bit rough, but it works; it creates a "virgin", self-resizable image to be deployed on openstack. Suggestions on how to improve it welcome.
On Thu, Oct 04, 2012 at 11:27:40AM +0100, Nux! wrote:
http://li.nux.ro/download/openstack/ks/centos6_x86_64_minimal.ks
Suggestions on how to improve it welcome.
Why do you need to do the "extend filesystem" stuff? I use KVM at home with virt-install and the partitioning automatically gives the right filesystem size: zerombr yes clearpart --all --initlabel part /boot --fstype=ext4 --asprimary --size=100 part swap --asprimary --size=64 part / --fstype=ext4 --asprimary --grow --size=1
Or is this a mis-feature of openstack that you're having to work around?
FWIW, I also have network --onboot yes --device eth0 --bootproto dhcp --ipv6 auto authconfig --enableshadow --passalgo=sha512
Additional useful packages that I like (I'm a ksh user :-)) yum openssh-server openssh-clients ksh dos2unix ntp-perl logwatch wget acpid yum-plugin-priorities bind-utils
I also strip these packages: -efibootmgr -kernel-firmware -aic94xx-firmware -atmel-firmware -b43-openfwwf -bfa-firmware -ipw2100-firmware -ipw2200-firmware -ivtv-firmware -iwl100-firmware -iwl1000-firmware -iwl3945-firmware -iwl4965-firmware -iwl5000-firmware -iwl5150-firmware -iwl6000-firmware -iwl6000g2a-firmware -iwl6000g2b-firmware -iwl6050-firmware -libertas-usb8388-firmware -netxen-firmware -ql2100-firmware -ql2200-firmware -ql23xx-firmware -ql2400-firmware -ql2500-firmware -rt61pci-firmware -rt73usb-firmware -xorg-x11-drv-ati-firmware -zd1211-firmware
On 04.10.2012 11:55, Stephen Harris wrote:
On Thu, Oct 04, 2012 at 11:27:40AM +0100, Nux! wrote:
http://li.nux.ro/download/openstack/ks/centos6_x86_64_minimal.ks
Suggestions on how to improve it welcome.
Why do you need to do the "extend filesystem" stuff? Or is this a mis-feature of openstack that you're having to work around?
Stephen,
This ks will generate a template to be used to deploy virtual machine on openstack (well, can be used anywhere kvm+virtio) and as such the template should be able to expand itself on the new virtual disk (it will basically be dd-ed to a new, larger file to be used for a VM). Indeed it's a "misfeature" of openstack as they could have used virt-resize to do all this..
On Thu, Oct 04, 2012 at 12:31:03PM +0100, Nux! wrote:
On 04.10.2012 11:55, Stephen Harris wrote:
On Thu, Oct 04, 2012 at 11:27:40AM +0100, Nux! wrote:
http://li.nux.ro/download/openstack/ks/centos6_x86_64_minimal.ks
Suggestions on how to improve it welcome.
Why do you need to do the "extend filesystem" stuff? Or is this a mis-feature of openstack that you're having to work around?
Stephen,
This ks will generate a template to be used to deploy virtual machine on openstack (well, can be used anywhere kvm+virtio) and as such the template should be able to expand itself on the new virtual disk (it will basically be dd-ed to a new, larger file to be used for a VM). Indeed it's a "misfeature" of openstack as they could have used virt-resize to do all this..
The kickstart entry, as defined, should define a partition of max size 'cos you only have one --grow value part / --fstype=ext4 --asprimary --grow --size=1
In my tests the partition always fills the disk allocated to it, so there's no need to resize after install.
# fdisk -l
Disk /dev/vda: 4294 MB, 4294967296 bytes 16 heads, 63 sectors/track, 8322 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000666f1
Device Boot Start End Blocks Id System /dev/vda1 * 3 206 102400 83 Linux Partition 1 does not end on cylinder boundary. /dev/vda2 206 1246 524288 82 Linux swap / Solaris Partition 2 does not end on cylinder boundary. /dev/vda3 1246 8323 3566592 83 Linux Partition 3 does not end on cylinder boundary.
Under what circumstances is a resize needed?
On 04.10.2012 14:04, Stephen Harris wrote:
Under what circumstances is a resize needed?
The VMs will not be deployed via ks. The ks role in my case is merely to install an OS template that can be used as an "VM image" on Openstack; that's what makes it complicated. :-) This template then will be used to deploy virtual machines; what happens is something along the lines of: - create file for template disk (1GB is enough to accomodate a minimal Centos 6): fallocate -l1G template.img
- install an OS on it using my ks: virt-install bla bla nux' kickstart
- create a new file for a VM, say 20 GB fallocate -l20G newvm.img
- now use the template to image the new VM's disk dd if=templateinstalledbyks.img of=newvm.img
But in doing so the end result will be a / partition and filesystem of the template's original size, which is very small (1GB as per above); they both need to be expanded to match the new size of 20GB.
Do you understand now?
On Thu, Oct 04, 2012 at 05:15:49PM +0100, Nux! wrote:
On 04.10.2012 14:04, Stephen Harris wrote:
Under what circumstances is a resize needed?
The VMs will not be deployed via ks. The ks role in my case is merely
Ah, OK. You're building an image for deployment. That makes more sense.
On Thu, Oct 4, 2012 at 7:31 AM, Nux! nux@li.nux.ro wrote:
On 04.10.2012 11:55, Stephen Harris wrote:
On Thu, Oct 04, 2012 at 11:27:40AM +0100, Nux! wrote:
http://li.nux.ro/download/openstack/ks/centos6_x86_64_minimal.ks
Suggestions on how to improve it welcome.
Why do you need to do the "extend filesystem" stuff? Or is this a mis-feature of openstack that you're having to work around?
Stephen,
This ks will generate a template to be used to deploy virtual machine on openstack (well, can be used anywhere kvm+virtio) and as such the template should be able to expand itself on the new virtual disk (it will basically be dd-ed to a new, larger file to be used for a VM). Indeed it's a "misfeature" of openstack as they could have used virt-resize to do all this..
The generated template left in /root/anaconda-ks.cfg is mangled fiction. It's what Anaconda deduced the actual ks.cfg contained, and throws out a tremendous amount of useful information, especially but not only the actual '%post' and '%pre' scripting executed. It's one of Anaconda's great flaws.
By default, add this or something like it to your kickstart files to save your actual ks.cfg file.
%post --nochroot cp /tmp/ks.cfg /mnt/sysimage/root/ks.cfg
On 03.10.2012 22:38, Karanbir Singh wrote:
On 10/03/2012 10:33 PM, Nux! wrote:
I'm currently working on a kickstart file that would install and prepare images for openstack deployment, will update you when it's done (I'm almost there, need to polish a bit the partition resizing bit).
Cool, I've been playing with Euca and ONE the last few days - my cloudstack install hit a bit of a roadblock ( my issue, nothing to do with cloudstack itself ).
kickstarts, along with anything else, appreciated with thanks
Qcow2 images & kickstart files at http://li.nux.ro/download/openstack/ There are 2 flavours: minimal and minimal+epel-release. All images resize themselves and have cloud-init installed. SSH password auth disabled, root passwd is some random md5 string so ssh key injection is mandatory to access the VM. Selinux and firewall are active.
I'm willing to build more custom images if requested.
On Wed, Oct 03, 2012 at 10:33:00PM +0100, Nux! wrote:
On 03.10.2012 22:23, Karanbir Singh wrote:
hi,
On 10/03/2012 05:48 PM, Nux! wrote:
Since I've already been messing with such images I kind of know what I need: 1 - acpid, so virsh reboot/shutdown will work
definitely needed
2 - cloud-init for openstack images; also it would be nice if the image could resize itself at first boot 3 - nano & wget to make the life easier for newbies
drop the useless firmware* :D
Great feedback. i think we can make all of those 3 things happen
Lovely! I'm currently working on a kickstart file that would install and prepare images for openstack deployment, will update you when it's done (I'm almost there, need to polish a bit the partition resizing bit).
I have a basic bootstrap procedure that just boots and install itself on the available disk (tested on EC2,Stratuslab,VirtualBox) through a kickstart. Downside: it goes through the whole install procedure. Upside: it's up to date at install time.
Cheers,
Tru
could these be used as vagrant base boxes?
On Oct 3, 2012, at 12:29 PM, Karanbir Singh mail-lists@karan.org wrote:
hi Guys,
As we get ready to start publishing Cloud Images ( or rather images consumable in various virt platforms, including public and private clouds ) - it would be great to have a baseline package manifest worked out.
What / how many images should we build. At this time we were thinking of doing :
CentOS-5 32bit minimal
CentOS-6 32bit minimal
CentOS-5 64bit minimal
CentOS-6 64bit minimal
CentOS-5 64bit LAMP
CentOS-6 64bit LAMP
What would be the minimal functional requirements people would expect from these images ? and what rpms should be installed ? Should root login be enabled or should we require people to go in via a 'centos' user. Should the image be self-updating, or should we have a post-login message that indicates outstanding updates ?
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
On 10/03/2012 06:18 PM, Philip Durbin wrote:
could these be used as vagrant base boxes?
we plan on publishing Vagrant box's as well - I've been talking with Mitchell to get them listed on vagrantup as well, and included in the docs he publishes.
Also, please fix your top posting
On 10/3/12 5:26 PM, Karanbir Singh wrote:
we plan on publishing Vagrant box's as well - I've been talking with Mitchell to get them listed on vagrantup as well, and included in the docs he publishes.
Great news! Thanks, Karanbir!
In the meantime, if anyone knows or trusts any of the CentOS base boxes here, please let me know: http://www.vagrantbox.es
Thanks,
Phil
On Wed, 2012-10-03 at 17:29 +0100, Karanbir Singh wrote:
hi Guys,
As we get ready to start publishing Cloud Images ( or rather images consumable in various virt platforms, including public and private clouds ) - it would be great to have a baseline package manifest worked out.
What / how many images should we build. At this time we were thinking of doing :
CentOS-5 32bit minimal
CentOS-6 32bit minimal
CentOS-5 64bit minimal
CentOS-6 64bit minimal
CentOS-5 64bit LAMP
CentOS-6 64bit LAMP
What would be the minimal functional requirements people would expect from these images ? and what rpms should be installed ? Should root login be enabled or should we require people to go in via a 'centos' user. Should the image be self-updating, or should we have a post-login message that indicates outstanding updates ?
Are you using existing RPMs or creating new ones with stripped dependencies?
What advantages will these images have over a kickstart install from a local repo?
On 03.10.2012 19:25, Ed Heron wrote:
On Wed, 2012-10-03 at 17:29 +0100, Karanbir Singh wrote: What advantages will these images have over a kickstart install from a local repo?
I think it mostly gets down to one: openstack (and maybe other systems who use images for deployment, e.g. OnApp).
On 10/03/2012 07:25 PM, Ed Heron wrote:
Are you using existing RPMs or creating new ones with stripped dependencies?
using existing rpms
What advantages will these images have over a kickstart install from a local repo?
these will be available at release time, and come tested in various cloud environments. We are also going to attempt getting official image status in various vendor clouds ( with an opportunity for every cloud vendor to adopt these into whatever software stack they end up using )
On 10/03/2012 05:29 PM, Karanbir Singh wrote:
As we get ready to start publishing Cloud Images ( or rather images consumable in various virt platforms, including public and private clouds ) - it would be great to have a baseline package manifest worked out.
and.. thoughts on Selinux ? Disable it ? Enable it ? Or should we just leave it in Permissive mode, along with a bit of text on howto enable it for people who want it ?
On 03.10.2012 23:59, Karanbir Singh wrote:
On 10/03/2012 05:29 PM, Karanbir Singh wrote:
As we get ready to start publishing Cloud Images ( or rather images consumable in various virt platforms, including public and private clouds ) - it would be great to have a baseline package manifest worked out.
and.. thoughts on Selinux ? Disable it ? Enable it ? Or should we just leave it in Permissive mode, along with a bit of text on howto enable it for people who want it ?
I usually leave it enforcing; it depends really on what it's for, but in recent years I found selinux to be less intrusive/problematic than it used to be in early 5.x days. I think we should have at least one "official" version the way Red Hat means it, with firewall and selinux on, root access, no 3rd parties. I for one am going to build such images anyway.. :)
On Thu, Oct 04, 2012 at 12:29:57AM +0100, Nux! wrote:
On 03.10.2012 23:59, Karanbir Singh wrote:
On 10/03/2012 05:29 PM, Karanbir Singh wrote:
As we get ready to start publishing Cloud Images ( or rather images consumable in various virt platforms, including public and private clouds ) - it would be great to have a baseline package manifest worked out.
and.. thoughts on Selinux ? Disable it ? Enable it ? Or should we just leave it in Permissive mode, along with a bit of text on howto enable it for people who want it ?
I usually leave it enforcing; it depends really on what it's for, but in recent years I found selinux to be less intrusive/problematic than it used to be in early 5.x days.
I would leave it on too, iptables with ssh only.
I think we should have at least one "official" version the way Red Hat means it, with firewall and selinux on, root access, no 3rd parties. I for one am going to build such images anyway.. :)
root access or ec2-user access with sudo ? or both? I would disable ssh password login completely too.
my 2 cents
Tru
On Thu, Oct 04, 2012 at 11:16:59AM +0200, Tru Huynh wrote:
I would disable ssh password login completely too.
%packages @base lftp sudo screen wget nfs-utils epel-release cloud-init # disable kdump -kexec-tools ntp nano acpid openssh-clients # firmware-- # ...
%end
%post # sudoers ** don't forget to have sudo in the package list echo 'ec2-user ALL = NOPASSWD: ALL' >> /etc/sudoers # sshd sed -i -e 's/^#PermitRootLogin yes.*/PermitRootLogin no/g' /etc/ssh/sshd_config sed -i -e 's/^PasswordAuthentication yes.*/PasswordAuthentication no/g' /etc/ssh/sshd_config # # ec2-users configuration useradd -G wheel ec2-user
# fix network cat <<ETH0 > /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes TYPE=Ethernet USERCTL=yes PEERDNS=yes IPV6INIT=no ETH0
/bin/rm -f "/etc/udev/rules.d/*persistent*"
# fix selinux permissions /sbin/restorecon -rv /home /etc /boot
# turn off fsck *** FIX the device *** tune2fs -c 0 -i 0 /dev/sda1
# cleanup # you will get error messages from anaconda trying to chmod the missing files # if you are reading the console output, these messages are harmless, afaik! /bin/rm -f \ /tmp/ks* \ /tmp/yum* \ /var/log/anaconda* \ /var/log/dracut.log \ /root/install* \ /root/anaconda*
%end
On Wed, Oct 3, 2012 at 12:29 PM, Karanbir Singh mail-lists@karan.org wrote:
hi Guys,
As we get ready to start publishing Cloud Images ( or rather images consumable in various virt platforms, including public and private clouds ) - it would be great to have a baseline package manifest worked out.
What / how many images should we build. At this time we were thinking of doing :
CentOS-5 32bit minimal
CentOS-6 32bit minimal
CentOS-5 64bit minimal
CentOS-6 64bit minimal
CentOS-5 64bit LAMP
CentOS-6 64bit LAMP
Funny you should ask!! I'm on an open source project that does precisely this. It depends heavily on whether you're using standard packages from CentOS itself, or whether you use Perl modules, Nagios, NRPE, or other tools such as git or puppet that are not in the bae upstream packages from the upstream vendor.
So a base LAMP install for me would absolutely contain epel-release, installed by hook or by crook, and the rpmforge-release package with /etc/yum.repos.d/rpmforge.repo disabled by default. It would also include postfix, rather than sendmail, for ease of management, and would include emacs and xorg-x11-xauth to allow X based Emacs sessions, which are often more useful than pure screen sessions, and I'd actually consider installing firefox in order to be able to run a remote web browser and see what shows up on the server itself. That's incredibly useful when people are doing.... odd things to firewalls and you want to make sure it's actually displaying content.
"curl" as well as wget is very useful. So is "lynx", for text based web checking, and the tools for whatever source control you feel useful, especially including the 'rcs' package for local file management. (That was invaluable today, as I was manipulating /etc/sysconfig/network-scripts files for funky network setups.)
What would be the minimal functional requirements people would expect from these images ? and what rpms should be installed ? Should root login be enabled or should we require people to go in via a 'centos' user. Should the image be self-updating, or should we have a post-login message that indicates outstanding updates ?
Root should be disabled, if feasible. I'm afraid that many sites don't handle such passwords well. Local user management can be awkward. Ask sometime about Kerberos authentication and local account management, I've got a lot of recent experience with these and Centrify's AD based account management.
The Nagios "check-updates" plugin is priceless for notifying a central NOC of required updates: rather than self updating.
Post install scripting, or system management, to set the 'root' alias is critical. Again, ask about that if curious: handling Postfix based smarthost setups, but making sure cron jobs for 'root' go to the right external email address, is a bit of an advenure.
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
On 10/04/2012 12:17 AM, Nico Kadel-Garcia wrote:
Funny you should ask!! I'm on an open source project that does precisely this. It depends heavily on whether you're using standard
What project is that ?
Also, while all those are good ideas : I dont think its what we are really targeting here initially. The overall goal is to produce a specific set of images, then ensure they are available across as wide a base as possible ( so, cloud vendors, cloud stacks for public clouds, various virt technologies and as many different file formats as we can )
On 10/03/2012 06:29 PM, Karanbir Singh wrote:
hi Guys,
As we get ready to start publishing Cloud Images ( or rather images consumable in various virt platforms, including public and private clouds ) - it would be great to have a baseline package manifest worked out.
What / how many images should we build. At this time we were thinking of doing :
CentOS-5 32bit minimal
CentOS-6 32bit minimal
CentOS-5 64bit minimal
CentOS-6 64bit minimal
CentOS-5 64bit LAMP
CentOS-6 64bit LAMP
What would be the minimal functional requirements people would expect from these images ? and what rpms should be installed ? Should root login be enabled or should we require people to go in via a 'centos' user. Should the image be self-updating, or should we have a post-login message that indicates outstanding updates ?
Have you considered equipping these with cloud-init? While i don't have any practical experience with myself yet it should allow to build a minimal image yet allow the creation cutomized flavors for users.
The problem I see is that the moment you include say vim-enhanced instead of emacs or postfix instead of sendmail you'll get into a political fight.
The only way I see is to make the minimal images truly as minimal as possible and then allow people to pull in stuff using cloud-init (or alternative mechanisms).
Regards, Dennis
On 10/04/2012 03:48 PM, Dennis Jacobfeuerborn wrote:
Have you considered equipping these with cloud-init?
yes
I'm looking at the EPEL packaging today to see if we can base off from there. For atleast 3 of the large vendors, cloud-init is almost a must-have.
regards,
On Wed, Oct 3, 2012 at 9:59 PM, Karanbir Singh mail-lists@karan.org wrote:
As we get ready to start publishing Cloud Images ( or rather images consumable in various virt platforms, including public and private clouds ) - it would be great to have a baseline package manifest worked out.
Nice to have.
What / how many images should we build. At this time we were thinking of doing :
CentOS-5 32bit minimal
CentOS-6 32bit minimal
CentOS-5 64bit minimal
CentOS-6 64bit minimal
CentOS-5 64bit LAMP
CentOS-6 64bit LAMP
A good starting point. I have been doing something similar - create a bunch of image templates
At present, we have 1. A portable desktop appliance - basically a LXDE desktop install that can be dd'd onto a 4GB pen drive. 2. Min. server with ssh and ntp enabled. 3. LAMP (PHP, Python, MySQL, postgreSQL) for web development platform. 4. Desktop KDE with KDM supporting XDMCP for a quick demo of remote desktop 5. Desktop with Qt SDK 6. Desktop with GTK SDK 7. Server with postfix+dovecot+roundcube for email server deployment 8. DB server (MySQL, postgreSQL) for production deployment.
The above is in a mix of CentOS, Debian, and Ubuntu base. Whenever anyone needs a pristine base, I copy the appropriate image file, boot it with virt-manager, change the network parameters, hostname etc. and hand it over to the developer/sysadmin.
What would be the minimal functional requirements people would expect from these images ? and what rpms should be installed ?
Take a look at the turnkeylinux.org appliances to see what others are doing.
Should root login be enabled or should we require people to go in via a 'centos' user.
I vote for the sudo approach. One can always do "sudo su -" as that user and would be equivalent to ssh root@somehost.
Should the image be self-updating, or should we have a post-login message that indicates outstanding updates ?
I vote for a post login message. The VM sysadmin has more control.
Keep us posted on the progress.
-- Arun Khan
Hi Guys,
Hoping to publish some testing images today late evening ( UTC ) - the targets I hope to hit are :
- CentOS-6/32 bit/s3 backed - CentOS-6/64 bit/s3 backed - CentOS-6/32 bit/ebs backed - CentOS-6/64 bit/s3 backed
- CentOS-5/64 bit/s3 backed - CentOS-5/64 bit/ebs backed
( is there any interest in C-5/32 ? )
Also, whats the best way to publish these images in a way that they can go away once the test-phase is done ( and ideally we really need them to go away )
On 10/15/2012 01:00 PM, Karanbir Singh wrote:
Hi Guys,
Hoping to publish some testing images today late evening ( UTC ) - the targets I hope to hit are :
[...]
Also, whats the best way to publish these images in a way that they can go away once the test-phase is done ( and ideally we really need them to go away )
dev.centos.org ?
On 10/15/2012 11:09 AM, Manuel Wolfshant wrote:
Also, whats the best way to publish these images in a way that they can go away once the test-phase is done ( and ideally we really need them to go away )
dev.centos.org ?
yeah, I guess that might be the best place.
Also, these images target EC2 specifically, so maybe public ami's there as well.
On Mon, Oct 15, 2012 at 3:00 AM, Karanbir Singh mail-lists@karan.org wrote:
Hi Guys,
Hoping to publish some testing images today late evening ( UTC ) - the targets I hope to hit are :
CentOS-6/32 bit/s3 backed
CentOS-6/64 bit/s3 backed
CentOS-6/32 bit/ebs backed
CentOS-6/64 bit/s3 backed
CentOS-5/64 bit/s3 backed
CentOS-5/64 bit/ebs backed
( is there any interest in C-5/32 ? )
Any update on this, please, Karanbir? I'd like to request a virtualbox image as well, if I may, please.
Yours, Aleksey
Hi,
On 11/14/2012 12:01 AM, Aleksey Tsalolikhin wrote:
Any update on this, please, Karanbir? I'd like to request a virtualbox image as well, if I may, please.
There are plans for Vagrant images, would that ( minus the puppet / chef stuff ) be enough for VirtualBox as well ?
On Fri, Nov 16, 2012 at 3:03 AM, Karanbir Singh mail-lists@karan.orgwrote:
There are plans for Vagrant images, would that ( minus the puppet / chef stuff ) be enough for VirtualBox as well ?
Hi! Sorry for the late reply -- yes, a Vagrant box is what I'm really after at this point.
Best, Aleksey
-
Aleksey Tsalolikhin -
Arun Khan -
Dennis Jacobfeuerborn -
Ed Heron -
Karanbir Singh -
Manuel Wolfshant -
Nico Kadel-Garcia -
Nux! -
Philip Durbin -
Rajagopal Swaminathan -
Stephen Harris -
Tru Huynh