July 02, 2015

CentOS Shirt Fridays

July 02, 2015 11:30 AM

Hi Everyone,

Over the last eight years we have handed out literally thousands of CentOS Project Tshirts. From Houston to Bangalore to Edinburgh to Sydney to Johannesburg to Porto Alegre to London and even the 4 that went to Antarctica. Lets get those shirts out every friday and see if we can get a CentOS Shirt Friday going. Get into them and lets get posting on social media! Lets use the #CentOSShirtFriday hashtag.

Thanks to Barton ( https://twitter.com/barton808 ) for the idea. And thanks to the folks at Cpanel ( http://cpanel.net ) for starting us off on this CentOS shirt journey many many years ago.

Dont have a CentOS shirt yet ? We typically have shirts at the events we attend as a project. You can see where we are going in the near future at the Events page ( http://wiki.centos.org/Events ).

So, I’ll see you all tomorrow online, with my CentOS shirt on. Now, lets see if I can find the first one we ever did.

- KB

June 22, 2015

Another Proof of Concept armv7hl Release, this one for the Raspberry Pi2

June 22, 2015 11:41 AM

Ten days ago I wrote an article here about an armv7hl test image for the Cubietruck 32-bit ARM board.  I have just uploaded a similar armv7hl image for the Raspberry Pi2. Both of these images are created with the RootFS Build Factory (a 2015 CentOS GSoC Project from Mandar Joshi sponsored by the CentOS Project).

The Raspberry Pi2 image (as well as the sha256sums for the compressed and uncompressed images) is available here:

http://people.centos.org/hughesjr/armv7hl/rpi2/images/

This RPI2 image actually uses the base kernel and boot files from the Raspberry Pi Firmware github site, and not the CentOS-7 armv7hl kernel.  This RPI2 kernel seems to be causing an issue with firewalld, and one must edit the file /etc/firewalld/firewalld.conf and change the variable IPv6_rpfilter from yes to IPv6_rpfilter=no.

Mandar has been making lots of progress on RootFS Build Factory and other people have reported that images generated from RBF for Odroid C1 and Banana PI are also functional, as is the image for QEMU.  I will be trying to obtain and post workable images from these boards soon.

I want to point out that the current images created are not signed and are taken directly from the output of our armv7hl builders ‘as is’ with no QA testing.  The armv7hl build is still very much a work in progress and the image manifest is based on a CentOS-7 (1503) minimal install from our x86_64 install media.  We have not yet completed the entire tree and the build repositories may at times NOT have complete closure and are only about 85% complete at this time.  We will finish the baseline build and then start the updates repository, but as of now these repos should be considered PRE-ALPHA and not production ready.

To use this image, you first extract it with this command:

unxz rpi2-centos-image.img.xz

Then just dd it to an SD Card and boot it in your Raspberry PI2 using a command like this from linux:

dd if=./rpi2-centos-image.img of=/dev/mmcblk0

(Note:  your SD Card device may vary .. you should be able to find the card device with fdisk -l )

If you are going to be at Red Hat Summit 2015 this upcoming week (June 23rd to 26th, 2015), please stop by the CentOS Booth in the Community Central area and we will have working armv7hl demos of a RPI2, Cubietruck, and Banana Pi .. as well as a working armv8 (aarch64) AppliedMicro X-Gene Server on a Chip  demo machine.  Hope to see you there.

June 17, 2015

AMD Seattle and CentOS on AArch64

June 17, 2015 12:46 PM

About a week after announcing the CentOS 7 alpha build for AArch64 hardware, I got an email from the fine folks at AMD asking for my address. Three days later, a pair of AMD’s Seattle AArch64 development boards showed up at my front door.  Hardware really is the best sort of gift, especially when you’re building for a new platform. I needed to make a couple modifications to my lab (okay fine, my home) network in order to make use of the new AMD gear due to the board layout. The boards I have don’t include USB by default, and I usually cheat and do USB based installs. Instead, I set up a proper pxe environment and loaded the OS up the right way.

Because the hardware was shipped with UEFI by default, there was very little to do in the way of configuration. I simply pointed the serial console at the pxe option and then did a normal vnc based install when the installer loaded. I don’t want to spend too much time here talking about the installation, because it was exceptionally simple. If you don’t have or want PXE, a pcie usb card would work fine. You can even simply yank the drive and dd the disk image directly to it, then power up. The only downside to the last approach is the need to run efibootmgr manually to set up the UEFI boot entry. In the coming days, I’ll be updating our AArch64 documentation to reflect the added hardware and providing more detailed directions for configuration and setup for the hardware.

 

Apart from being able to report that the AMD boards work just fine with the CentOS 7 AArch64 beta, I can also happily report that they’re proving quite useful. Since I have multiple machines, I’m now able to run a number of test cases and multiple configurations without the need to cannibalize my build system or boot from multiple drives. This has given me the ability to run our t_functional testing suite against the AArch64 beta, and identify a few minor build issues that I need to address before we can call the release GA. Thanks AMD!

 

June 16, 2015

Introduction to Cloud SIG talk in FUDCon Pune 2015

June 16, 2015 12:04 PM

FUDCon is the Fedora Users and Developers Conference, a major free software event held in various regions around the world, usually annually per region. This year the event in APAC is happening in Pune, India, from 26th to 28th June. I will be giving an introductory talk about the CentOS Cloud SIG (CCS) in the Openstack track on 27th June at 4:20pm.  CentOS Cloud SIG  is a group of people coming together to focus on packaging and maintaining different FOSS based Private cloud infrastructure applications that one can install and run natively on CentOS. We are a non vendor, non technology and non agent specific focus group, but we will gladly work with and build content to suit relevant niches or vendor ecosystems.

In this talk I will give a brief update about our work related to Openstack releases over CentOS 7 and CentOS 6. We will also see how OpenNebula is working towards a working build on the CBS. Anyone who wants to learn about these technologies or who wants to contribute to the SIG should attend this talk. I will be available all three days during the event. If you want to say hi or want to learn more about the CentOS Cloud SIG, please do ping me over @kushaldas or find me in person there.

June 12, 2015

CentOS IRC Meeting Calendar Now Available

June 12, 2015 12:17 PM

As of now, you can subscribe to a calendar feed (.ical) in your calendar program of choice by adding this feed url:

https://git.centos.org/raw/sig-core!calendar.git/master/output!irc-meetings.ical

New meetings are added via pull-requests against this repository: https://github.com/CentOS/Calendar

Why is this now available?

The number of SIGs and general project work has grown and more and more IRC meetings are
being scheduled. When KB announced he would begin holding office hours a discussion about how to best notify people and keep it on their minds sprang up on the centos-devel mailing list.

How is it implemented?

Louis Taylor mentioned that OpenStack had a yaml file driven calendar that didn’t require a central authentication mechansism. After a quick round of acceptances, I implemented the OpenStack model and the calendar was born.

Our next step is to host a web page that will serve as a landing zone for this information and list all of the scheduled meetings.

For those of you interested in the details, the calendar uses yaml2ical, a python module to convert the meeting yaml files into both an ical feed and an html listing. The current workflow is:

  1. A Pull Request on https://github.com/CentOS/Calendar adds a new meeting yaml file
  2. A project member merges the pull and manually generates the new html and ical files
  3. The files are mirrored to git.centos.org

To Do:

  1. 1. Land the html file somewhere in our web infrastructure (to be tackled next week)
  2. Work with the yaml2ical community to land some patches for meeting duration and urls (in progress – see Issues on github)

Currently the meetings are listed in html with their frequency information. If someone knows of a simple ical->html or ical->text_list processor we can consider hosting a “calendar” view of the calendar.

CentOS-7 (1503) armv7hl Proof of Concept (pre-alpha) Image available for the Cubietruck

June 12, 2015 10:07 AM

As Jim Perrin pointed out in an earlier post here on seven.centos.org, we have commenced an armv7 (actually, armv7hl) open build to try and produce CentOS-7 for arm32 boards like the Cubietruck, Raspberry Pi2, and ODROID-C1 (among others).

We now have a minimal sdcard only image for the Cubietruck from our unsigned (and as yet uncompleted) plague-builder output.

This image has been produced by the RootFS Build Factory (a 2015 CentOS GSoC Project from Mandar Joshi sponsored by the CentOS Project).  While the RBF is not yet close to being a finished product, it was able to be used to create this image.  This is our first published image built using RBF, which looks to be to be a very promising and useful GSoC project for CentOS on ARMv7.

Before I tell you where the image is, I want to point out (with emphasis :D) that THIS IMAGE IS PRE-ALPHA, PROOF OF CONCEPT ONLY !!!.  It is based on the Source Code from CentOS-7 (1503) release with none of the follow on updates and is not suitable for use in any environment that you care about at this point.  In fact, as this article is being posted, we only have 2068 of the 2523 Source Packages even built for armv7hl at this point.  The repositories used for this proof of concept are the unsigned direct output from our ongoing build of armv7hl and while the minimal install works (and should continue to work), there may not always be repoclosure there and some packages outside the minimal install may not have all their dependencies yet built, etc.

If you are interested in helping us get armv7hl working with CentOS-7, please join the Arm-Dev mailing list where we are doing the community build now.

The proof of concept, sdcard only, image is available here:

http://people.centos.org/hughesjr/armv7hl/cubietruck/images/

Install instructions are available from this post to the Arm-Dev mailing list.  If you are going to try this image, you should really join the list as that is going to be where the community can answer questions about it.

Next up on the armv7hl front should hopefully be a minimal install image from the same plague-builder repos for the RaspBerry Pi2 in the next week or so.

As I have already pointed out, we do not yet have an armv7hl release, in fact to date we only have about 82% of the packages for the release that actually build at this point.  We can use the help of people who understand the boards in question … especially vendors.  Join the Arm-Dev list and give us a hand.

June 11, 2015

Rolling ISO Media release 1505 for CentOS 7 (x86_64) Now Available

June 11, 2015 11:00 AM

The rolling ISO media releases for CentOS 7 for May 2015 (1505) are now available.

These rolling ISO media releases are basically just respins of the install media at release time with all bugfix, enhancement, and security updates since release rolled in.  The updated ISOs for 1505 are based on all updates in the CentOS 7 os and updates repositories at 0000 UTC on May 28th, 2015.

The goal is to make these media available on a monthly basis for CentOS 7, in much the same way as we make cloud and container images available.

Users can use the updated ISO images for installs that have far fewer updates required after install.  There is no difference between using these ISOs and the original CentOS 7 (1503) ISOs and a yum update run on May 28th at 0000 UTC.

The new ISOs are available here:

http://buildlogs.centos.org/rolling/7/isos/x86_64/

File: CentOS-7-x86_64-DVD-1505-01.iso
Sha256sum: 70c510b8ae7e742ef12e9378ef49a919361e4f891f8f4ad92b03209f2cbb3638

File: CentOS-7-x86_64-Everything-1505-01.iso
Sha256sum: 1b117390a908467723f166ee22aa300bd4b55c57f05bc37eb58fb6bf3331295e

File: CentOS-7-x86_64-LiveCD-1505-01.iso
Sha256sum: 2310f7d28ed10a9a19d3690378a6f523c666a5ad3bfd428cc2a1f6b7438cc560

File: CentOS-7-x86_64-LiveGNOME-1505-01.iso
Sha256sum: 76a9c62c363cd90d0c8235400498829dfad9fc9bbae85916b26d2346300b649f

File: CentOS-7-x86_64-LiveKDE-1505-01.iso
Sha256sum: b48e8d2798767674f9993929d6899ca8f2f0cb0f420251e5184b3cd047403399

File: CentOS-7-x86_64-Minimal-1505-01.iso
Sha256sum: d9d394dcfa40a73cf0cfad9ebc70b54fcdd29861694791a5b678c57368087306

More information is available from our announcement here:

http://lists.centos.org/pipermail/centos-announce/2015-June/021160.html

June 08, 2015

Regular office hours

June 08, 2015 04:58 PM

Update: I’ve moved the Thurs evening slot to Wednesday so as to not clash with Atomic SIG meeting.

Hi,

Starting this Thursday the 11th June, 2015 – I am going to make myself available to anyone who wants to come along and talk about CentOS Linux, the CentOS Project, the SIGs or anything else that is related to these.

To start things off, I am going to be available on all Wednesdays:

  • 04:00-04:30 pm UTC (5:00pm London, 12noon Eastern, 9am Pacific )

And on all Thursdays:

  • 08:30-09:00 am UTC (9:30am London, 2:00pm, India, 4:30pm Singapore)

During this time, you can find me on #centos-devel irc.freenode.net ( as ‘kbsingh’), and you can also call me on the phone at +44 207 009 4455.

Speak to you then!

- KB

June 02, 2015

Update on CentOS GSoC 2015

June 02, 2015 03:34 PM

Here’s an update on the CentOS Project Google Summer of Code for 2015 posted on the CentOS Seven blog:

http://seven.centos.org/2015/06/centos-and-gsoc-2015-suddenly-come-seven-on-7/

This might be of interest to the Fedora Project community, so I’m pushing my own reference here to appear on the Fedora Planet. Much of the work happening in the CentOS GSoC effort may be useful as-is or as elements within Fedora work. (In at least one case, the RootFS build factory for Arm, the work is also happening partially in Fedora, so it’s a triple-win.)

June 01, 2015

CentOS and GSoC 2015 — suddenly come seven on 7

June 01, 2015 03:32 PM

The CentOS Project is now the proud mentoring organization for seven students to work on projects this summer under the Google Summer of Code (GSoC.)

Below is a quick snapshot of the projects and the communication channels for keeping track or participating in the activities the students will generate around themselves as the get to work. For the most part, these projects are focused on technologies around the latest Linux from the project, CentOS Linux 7.

To keep overall track of what is going on across all the students’ projects, watch the CentOS planet blog aggregator, planet.centos.org; students individual blogs are found at the CentOS 7 blog seven.centos.org.

Getting this all together has been fun — working with the students- and mentors-to-be, organizing processes, all the way back to the idea generation and prep phases, all a whirlwind of activity. I’ve done GSoC as a mentor and administrator since 2006 (second year of GSoC) and other summer coding efforts, and it’s hard not to have things be a bit chaotic with so many moving parts. I’m really looking forward to the benefits newer organizations get from having to prepare and work with students throughout the effort.

May 21, 2015

CentOS 7 armv7hl build in progress

May 21, 2015 12:36 PM

As more and more people were showing interest in CentOS on the ARM platform, we thought that it would be a good idea to start trying building CentOS 7 for that platform. Jim started with arm64/aarch64 and got an alpha build ready and installable.

On my end, I configured some armv7hl nodes, "donated" to the project by Scaleway. The first goal was to init some Plague builders to distribute the jobs on those nodes, which is now done. Then working on a "self-contained" buildroot , so that all other packages can be rebuilt only against that buildroot. So building first gcc from CentOS 7 (latest release, better arm support), then glibc, etc, etc ... That buildroot is now done and is available here.

Now the fun started (meaning that 4 armv7hl nodes are currently (re)building a bunch of SRPMS) and you can follow the status on the Arm-dev List if you're interested, or even better, if you're willing to join the party and have a look at the build logs for packages that failed to rebuild. The first target would be to have a "minimal" install working, so basically having sshd/yum working. Then try other things like GUI environment.

As plague-server required mod_python (deprecated now) we don't have any Web UI people can have a look at. But I created a "quick-and-dirty" script that gathers information from the mysql DB, and outputs that here :

The other interesting step will be to produce .img files that would work on some armv7hl nodes. So diving into uboot for Odroid C1 (just as an example) ....

I'll also try to maintain a dedicated Wiki page for the arm32 status in the following days/weeks/etc ..

May 18, 2015

CentOS 7 with GlusterFS on AArch64

May 18, 2015 06:09 PM

Initially I meant for this to be a much more in-depth blog post about running GlusterFS on AArch64 hardware, but honestly it’s been ridiculously easyto get running. There isn’t much to say about running it that isn’t already covered in the GlusterFS quickstart guide. Even building GlusterFS on AArch64 was a snap; I simply pulled down the glusterfs-3.6.3 src.rpm and ran it through mock on my AArch64 build system. A few seconds later, I had around a dozen glusterfs packages ready for installation. After bringing up a test box, I was confident that this was working entirely too well and something would explode at any minute. I followed the quickstart, and a few minutes later, I had a working test implementation of GlusterFS up and running. There were no explosions, no fireworks, and no errors. The whole thing was incredibly painless to get working, and I can’t wait to see people using it in production.

gluster volume status and installed packages

 

 

Hopefully this means getting an official GlusterFS build for AArch64 will be as simple as asking nicely, and possibly working with the Storage SIG for access to the builders.

May 13, 2015

Firefox 38 and TLS less than 1.2

May 13, 2015 05:19 AM

Red Hat released the source code for Firefox 38.  We have (or willbe
today) releasing this for CentOS-5, CentOS-6, and CentOS-7.

It does not, by default, connect to https sites with TLS less than 1.2.
This means it will not connect to sites on CentOS-5, for example ..
there are many others.

In any event, here is a wiki article that explains potential issues and
workarounds:

http://wiki.centos.org/TipsAndTricks/Firefox38onCentOS

May 08, 2015

Running CentOS Linux 7 on AArch64 hardware

May 08, 2015 09:07 PM

The journey for rebuilding the latest release of CentOS Linux 7 on AArch64 hardware has certainly been an interesting one. After a few bug reports, a couple minor patches, and several iterations through the build system, we finally have a release for community testing and consumption, which we’ll have available for install early next week. There are some differences with a traditional CentOS install that users wishing to experiment should keep in mind. Because AArch64 hardware is still very new, this build requires a newer kernel that we’ll be patching fairly regularly with help from the community as well as various vendors. The initial alpha release will ship with a kernel-4.0.0 based kernel, however we’re working on providing a 4.1 based kernel using ACPI very soon. After the initial kickoff next week, we’ll start setting expectations for fixes, release cycles (I’m thinking monthly, in keeping with other plans) and more. If you want to participate or contribute patches, please join our arm-dev list and say hi.

Teaser screenshots!

In the example below, I copied the boot.iso to USB via dd. For the hardware I have, the installer’s started over a serial interface, and then accessed via VNC. A text mode is available as well, just like the default CentOS 7 installer for x86_64 (you’ll probably want to use VNC initially).

Screenshot from 2015-05-05 18:35:40

The VNC based installer is identical to the one you’re already familiar with for CentOS. The only difference of note here, is that by default only the ‘minimal’ install is available. Additional packages may be installed after the installation completes. This is something we’ll improve on as the AArch64 build matures.

Screenshot from 2015-05-07 11:11:46

 

Just as you’d expect, once the installer completes successfully, you’ll be prompted to reboot.

Screenshot from 2015-05-07 11:19:04

 

After the installation completes and you have rebooted the system, the console login prompt shows the 4.0.0-1 kernel goodness, and you’re ready to deploy additional software and configure the system.

Screenshot from 2015-05-08 15:57:01

May 06, 2015

Signed Repository Metadata is now Available for CentOS 6 and 7 for the Updates Repo

May 06, 2015 02:35 PM

The CentOS Project is now providing a signed copy of the repodata metadata file (repomd.xml.asc) for our Updates Repository for both CentOS-6 and CentOS-7.  To use this feature, you would edit the file /etc/yum.repos.d/ CentOS-Base.repo and locate the [updates] section, the default looks like this:

#released updates
[updates]
name=CentOS-$releasever – Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

You would add in this option:

repo_gpgcheck=1

Currently we only have this option available on the [updates] repos for CentOS-6 and CentOS-7, but we will be rolling it out to all C6 and C7 repos in the future.

Yum will verify that the repo in question is signed with the RPM-GPG-KEY-CentOS-7  (or RPM-GPG-KEY-CentOS-6 for CentOS-6) key .. so you can be sure these updates come directly from the CentOS Project and no one else.

Here is a good read about GPG sign and verify RPM packages and yum repositories . It also explains why we are not rolling it into the CentOS-5 repos.

There is also further information on this CentOS Maillist thread.

 

Hacking initrd.img for fun and profit

May 06, 2015 06:16 AM

During my presentation at Loadays 2015 , I was mentioning some tips and tricks around Anaconda and kickstart, and so how to deploy CentOS , fully automated. I asked the audience about where to store the kickstart, that would be used then by anaconda to install CentOS (same works for RHEL/Fedora), and I got several answers, like "on the http server", or "on the ftp server", which is where most people will put their kickstart files. Some would generate those files files "dynamically" (through $cfgmgmt - I use Ansible with Jinja2 template for this - ) as a bonus point.

But it's not mandatory to host your kickstart file on a publicly available http/ftp/nfs server, and surely not when having to reinstall nodes not in the same DC. Within the CentOS.org infra, I sometimes have to reinstall remote nodes ("donated" to the Project) that are running CentOS 5 or 6 to 7. That's how injecting your ks file directly into the initrd.img really helps. (yes, so network server needed). Just as an intro, here is how you can remotely trigger a CentOS install, without any medium/iso/pxe environment : basically you just need to download the pxeboot images (so vmlinuz and initrd.img), provide some default settings for Anaconda (for the network config, and how to grab stage2 image, and so where is the install tree) On the machine to be reinstalled :

cd /boot/
wget http://mirror.centos.org/centos/7/os/x86_64/images/pxeboot/{vmlinuz,initrd.img}

Now you can generate and copy your kickstart file for that node and send it to the remote node (with scp, etc ..) Next step on that remote node is to "inject" the kickstart directly in the initrd.img :

#assuming we have copied the ks file as ks.cfg in /boot already
echo ks.cfg | cpio -c -o >> initrd.img

So now we have a kernel/initrd.img, containing the kickstart file. You can modify grub(2) to add a new menu entry, make it the default one for next reboot and enjoy. But I usually prefer not doing that, if you need someone to reset that node remotely if something wrong happens, so instead of modifying grub(2), I just use kexec to reboot directly with the new kernel (without having to power cycle the node) :

# can be changed to something else, if for example node is running another distro not using yum as package manager
yum install -y wget kexec-tools 
kexec -l vmlinuz --append='net.ifnames=0 biosdevname=0 ksdevice=eth0 inst.ks=file:/ks.cfg inst.lang=en_GB inst.keymap=be-latin1 ip=your.ip netmask=your.netmask gateway=your.gw dns=your.dns' --initrd=initrd.img && kexec -e

As you can see in the append line, I just tell anaconda/kernel to not use the new nic naming (default now in CentOS 7, and sometimes hard to guess in advance), assuming that eth0 is the one to use (verify carefully that !), and the traditional ks= line in fact now just points to /ks.cfg ( initrd.img being / ). The rest is self-explained.

The other cool stuff, is that you can use the same "inject" technique but for Virtual Machines installed through virt-install : it supports injecting directly files in the initrd.img, so easier than for bare metal nodes : you just have to use two parameters for virt-install :

  • --initrd-inject=/path/to/your/ks.cfg
  • --extra-args "console=ttyS0 ks=file:/ks.cfg”

Hope this helps

May 05, 2015

Last few days in CentOS, May 5th

May 05, 2015 05:32 PM

Just a short recap of some of the things going on around the CentOS Ecosystem.

* We have now got a 5 machine armv7 ( 32 bit ) Buildsystem running. Over the coming days and weeks you should keep an eye out for testing calls. If you can, and have interesting ARM hardware, feel free to join us at the arm-dev list ( http://lists.centos.org/pipermail/arm-dev/ – more information on the build system can be found in this thread: http://lists.centos.org/pipermail/arm-dev/2015-April/000126.html

* There is a lot of work being done to get XFCE in a good state for CentOS-6 and 7, you can track the conversation from this thread http://lists.centos.org/pipermail/centos-devel/2015-May/013326.html

* The RDO Project is running 2 test days for OpenStack on CentOS. You can get details and join the effort ( it runs 5th and 6th May ) at http://lists.centos.org/pipermail/centos-devel/2015-April/013309.html

* There is a Vagrant Box now available for CentOS, for user testing and feedback – if you use Vagrant on VirtualBox or Livbirt or vmware backends, please give this a try and send feedback to the centos devel list ( more info at : http://lists.centos.org/pipermail/centos-devel/2015-April/013297.html)

Events:

* We had a great CentOS Dojo at Bangalore, India on the 29th April. About 70 CentOS users came together to talk about containers. Details of the meeting are at http://www.meetup.com/CentOS-India/events/221769525/ and you can see some pictures at https://www.flickr.com/photos/saifikhan/sets/72157649944407033/

* OpenStack Summit is happening at Vancouver, CA from May 18th to 22nd. CentOS Project will have a presence there. If you are coming to the event, stop by and say hi! We will also have tshirts and stickers, so come along and help yourself to some of those.

* Netherlands UUG Spring Conference is taking place on the 28th May, ( https://www.nluug.nl/index.html ) I will be there speaking about CentOS Linux, The CentOS project and some of the new innitatives we are starting up, along with how people can get involved in these efforts.

In other news, 7 students have taken up the Google Summer of Code slots that were allocated to the CentOS Project, over the next few weeks expect to see some traffic on centos-devel list from those students – and we will be encouraging them to come and join the various SIG meetings and communicate outward their progress, and also ask for help if they get stuck in anywhere. They will be working on things ranging from Kpatch live patching, to Xen and Cloud installs, to improving our
documentation trails! I’m very excited to have these students onboard! Hope they have a great summer ahead and produce some great code.

- KB

April 22, 2015

Some recent news from CentOS : Apr 22 2015

April 22, 2015 11:37 AM

Hi,

This is a summary of some of the major things going on in the project, its not a comprehensive list, but should cover most of the major traction points:

Firstly, lets all welcome Brian Stinson to the fold (http://lists.centos.org/pipermail/centos-devel/2015-April/013211.html )

———-
Updates for CentOS 5/6/7 : All updates from upstream are released into the CentOS Linux mirror network.

———-
* Moving towards Signed Metadata ( ref: http://lists.centos.org/pipermail/centos-devel/2015-April/013210.html )

* Building a downstream CentOS based Atomic Host ( ref: http://lists.centos.org/pipermail/centos-devel/2015-April/013209.html )

———-
Other interesting things:

* The CentOS Mini Dojo in Bangalore April 2015 : http://wiki.centos.org/Events/Dojo/Bangalore2015

* Fabian was speaking at Loadays a few weekends back and did a great session on Installing CentOS, Slides from his presentation are available
here : http://people.centos.org/arrfab/Events/Loadays-2015/CentOS%20Install%20method%20review.pdf

* CentOS Project is participating in the Google Summer of Code for the first time this year, and we have been allocated 7 slots for projects. There are some very interesting projects in the pipeline. The landing page for the ideas is at http://wiki.centos.org/GSoC/2015/Ideas – and conversation around this has been taking place in both centos-devel list and the gsoc list ( http://lists.centos.org/ )

———-
Finally, I am going to try and run this weekly with a few notes from various places. Any and all help is appreciated. You can send me news to post in this at kbsingh centos.org.

Regards,

March 31, 2015

CentOS-7 (1503) is released

March 31, 2015 06:32 PM

Today the CentOS-Project announced the immediate availability of CentOS-7 (1503), the second release of CentOS-7.

 

Find out more about the release announcement here: http://lists.centos.org/pipermail/centos-announce/2015-March/021006.html.

Also don’t forget to read the release notes at the wiki: http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7.

March 20, 2015

CentOS-7 / CR repo has been populated

March 20, 2015 02:41 PM

Waiting for the new package set in the next CentOS-7 release ? A majority of them are now available on every CentOS-7 machine by running the following commands :

yum update
yum --enablerepo=cr list updates

Its important you run a ‘yum update’ first, since the cr repo definitions are only available in the newer centos-release rpms. Once you are happy with the new content that is going to come via the CR repos, you can apply them with :
yum --enablerepo=cr update

For more information on whats been pushed to these CR Repos, look at the announcement email at : http://lists.centos.org/pipermail/centos-announce/2015-March/020980.html

You can get more information on the CR process, the repository and the content inside it at : http://wiki.centos.org/AdditionalResources/Repositories/CR

– KB

March 11, 2015

CentOS-7 next release

March 11, 2015 03:36 PM

Red Hat Enterprise Linux 7.1 was released a few days back, You can go read the release notes now. Its a great way to find out the big changes and enhancements in this release.

On the CentOS side of things, we have been working through last week on getting the sources organised and the builds started up. We are pretty close to finishing the first cycle of builds. The next step would be to get the content into QA repos so people can start poking it. From there on, content will make its way into the CR/ repos, and we will goto work on the distribution media ( ie. the ISOS, Cloud Images, containers, live media etc ). Once that is done, we have another couple of days for QA around those bits, followed by the wider release.

This release for CentOS-7 is going to be tagged 1503 to indicate month of upstream release.

In terms of a timeline, this is where things stand : We hope to start moving content into the CR repos by the 13th/14th of March. This should set us up for releasing the distro around the end of the following week 18th to 20th of March. Ofcourse, this is a projected date and might change depending on how much time and work the QA cycles take up and any challenges we hit in the distro media building stages.

Note that the CR repos contain packages that have not been through as much QA as the content at release time, so while they do give people a path to early-access to next-release rpms and content, they come with the added risk.

Some of the special interest groups in CentOS are keen to get started with the new content, and we are trying to find a way to make that work – but at this time there is no mechanism that bridges the two buildsystems ( the CentOS Distro one, and the Community Build System used by the SIGs ). So for the time being the SIGs will just need to wait a few more days before they can start their trials and builds. For the future, its something we will try and find a solution for, so in the next release SIGs can start doing their builds and testing as the distro packages are being built.

– KB

March 10, 2015

SCALE 13x – no talking, all walking, and a great ally skills workshop

March 10, 2015 02:40 PM

For the first time in-I-can’t-remember I didn’t submit a talk to SCALE, so it was with a different personal energy that I attended SCALE 13x on 19 to 22 February this year. Not having a do-or-die public-speaking-scheduled-thing in front of me allowed for a more relaxed state of mind. Yet it was strange to not be one of the speakers this time. Still, all my old SCALE friends made me feel very welcome and accommodated. As usual, it was nice to have my family there, where so many know them as former speakers and regular attendees.

Rather than focus on talking to an audience, this time I spent my energy walking around the expo hall-and-wherever to talk with as many projects and companies as possible. My goal was to get an idea of who uses CentOS Linux, for what purposes, and get ideas of what people need and want from the project. I also provided information on what the Project has been up to especially around SIGs. That activity was fun, informative, and interesting.

Also I spent my share of time at the booth that housed the CentOS Project, RDO/OpenStack, oVirt, and OpenShift Origin. (I can’t wait to see the next iterations of Ryan’s Raspberry Pi 2 mini-cluster demo for OpenShift Origin.) I watched other people, including my wife, play with instruments and music software at the ever-popular Fedora Project booth (winners once again of a favorite booth award.) With a small rock concert and 3D printer, it was hard not to notice.

There were two sessions I was drawn to the most. The first was Ruth Suehle‘s keynote on Sunday morning, Makers:  The Next Frontier for Open Source. I’ve worked with Ruth a long time, seen her speak multiple times, seen lots of cool stuff that she’s made over the years, and I knew it would be an excellent talk. She used her great bully pulpit to teach and entreat the audience about the needs of the makers communities to get some serious clue and help from open source communities.

The other session was a workshop on Friday to learn skills as a man to be an ally for women when sexist things happen. This is something I’m interested in, being a better ally for people, including in the face of sexism and sexist behavior. For myself, I’ve begun calling myself a born again feminist. To me that means I’ve had a later-in-life realization that while I’ve always supported the ideas and topics around feminism, I wasn’t really aware how deeply pervasive sexism is, how blandly I’d looked past it, and that I could be part of the solution. Part of being part of the solution is not being afraid of being a feminist in name and action.

The workshop (described in detail here) was lead by Valerie Aurora, who’s gone from kernel hacker to executive director of the Ada Initiative. The Ada Initiative “supports women in open technology and culture …” Thus the workshop was primarily for people working in open technology and open culture. It started with a brief introduction that was useful in many ways, such as reminding us about how to best engage with difficult online exchanges (more advanced than ‘don’t feed the trolls’), the reason for needing male allies (hint:  it’s about doing something good with the privileged position and power that one has in society), and keeping it all in a useful context by not having the workshop be a place to debate “is there sexism?” Instead we acknowledge there is something broken, it needs fixing, and we here can do something about it. You can watch an introduction and highlights of the workshop in this video that Valerie gave to the staff at the Wikimedia Foundation, with closed captioned subtitles available for English.

For the majority of the workshop, we were in small groups (4 to 6 people) to discuss approaches we would take to certain scenarios. One scenario (as I recall them) was, “A woman is standing outside of your group at an event and looks as if she might be interested in joining the discussion. How would you handle this?” Another was, “At a work party someone comments that a co-worker with a large number of children must get a lot of sex.” Then the small groups discussed our approaches, and presented some ideas or questions back to the overall group. And then on to the next scenario.

The discussion/collaboration session was really useful in a number of ways. First, it helped give specific and general ideas of how to handle — and not handle — specific scenarios. Second, it also served to give a crosscut of different types of situations that do occur, so you can take skills from one scenario more easily in to another. Not only was it useful for dealing with sexist situations, it was easy to see the same thinking and skills could be applied to any situation where someone is objectified, made to be an Other, treated as a stereotype, and so forth — thus useful for handling racism, ageism, and so forth. Third, it was useful to get a chance to practice what to say in response when we witness sexism, partially because it’s helps us to have something to immediately say rather than being shocked and mute.

The format of the workshop was great. Elements included working in small groups, a person in each group being a gatekeeper who makes sure everyone in the group is heard from, presenting ideas back to the overall group in a discussion format, all the way down to how we introduced ourselves to our small groups. I also appreciated moving across groups at least once, that helped us get fresher perspectives with each scenario.

This is definitely a workshop I’d like to bring to any tech company. All of us can use help and perspective on how to react when someone does something sexist, or we have a chance to do something about systemic sexism. We can agree that it’s unkind to make people feel uncomfortable, and it’s kind to help people by pushing against the discomfort making.

There is something I’ve noticed for most of my life. When talking with my peers — people who are born mainly after the 1960s in a post-feminist-creation era — we are often in agreement about how people should treat each other along the axes of sex, race, gender, and so forth. And while I see in younger generations a huge amount of support for ideas such as “people should be able to legally marry whomever they want”, I still hear a lot of people afraid of the f-word — feminism. It’s as if people are in full agreement with the concepts behind the word, but afraid to use the word itself. This is the other part of my ‘born again’ experience, that I need to embrace the word as well as the concept in order to really align myself correctly, live correctly, and be a good ally of all people.

Building CentOS Linux 7 for ARMv8

March 10, 2015 11:06 AM

As I’d mentioned previously, the fine folks of Applied Micro were kind enough to give us an X-C1 development box to see if it was feasible to build and run CentOS Linux 7. My first attempt through, I realized I hadn’t been taking decent notes, so I scrapped most of the package work and started over. This time I took a few more notes, and hopefully I’ve documented some things that will help everyone. If you’re interested in discussing or joining the ARMv8 process, feel free to join our ARM development mailing list, or find me on Freenode’s irc network in #centos-devel (nick: Evolution ).

 

Initial Steps

The official Linux architecture name for ARMv8 is aarch64. However both terms seem to be in circulation and we use them to imply the same thing.

My plan for the X-C1 box was to install Fedora, and use mock to get a decent buildroot in order. Because the X-C1 box came with a uboot based image by default, I had to replace it with uefi first. The directions for doing that can be found on Fedora’s aarch64 wiki page. Once uboot was successfully replaced with UEFI, I installed Fedora 21 and mock. I chose F21 largely because there I couldn’t find a Fedora 19 image to work from, but there are Fedora 19 packages available to help bootstrap a C7 mock chroot, which is really what I was after. I copied this repository to a local system both to not hammer the remote machine, and to reduce the latency.

 

Host Modifications

While I worked on getting the roughly 150 packages needed for a basic mock buildroot built, I kept running into a recurring problem with failed tests for elfutils. Part of the elfutils test suite tests coredumps and it seems that the buildhost’s systemd-coredump utility was stealing them. After some time digging around with this, I ended up with the following commands:

# echo "kernel.core_pattern=core" > /etc/sysctl.d/50-coredump.conf
# sysctl --system

Once that was done, the elfutils build tests passed without issue.

 

Package Builds

Initially I attempted to work out a build order that would allow me to build from the ground up, but I quickly realized this was foolish. When starting from the bottom like this, everything has a build dependency on something else. Instead I chose to work toward a clean mock init first, and then work up from that point. Since I only have one board to build against, I’m currently abusing bash and cycling things through mock directly. The idea of using koji or plague seemed a bit overkill with just one build host doing the work. Once everything has been built (or thrown out of the build) against the F19 repository, it will be time to do the build again against itself to ensure that everything is properly linked and self-hosting.

 

It’s worth noting that some of the packages in the F19 repository are actually tagged as F20 and are newer than what exists in CentOS Linux 7. I found it necessary to exclude these newer versions, and often to exclude other packages as the build has progressed. While not an exhaustive list, examples are:

  • sqlite-3.8
  • tcl-8.5.14
  • tk
  • Various perl modules

 

Exclusions:

I mentioned that a few packages have been ejected from the build outright. Some of these are because the build dependencies either aren’t, or can’t be met. The prime example of this is ADA support, which requires the same cross-compiled (or otherwise bootstrapped) ADA version to build (yay for circular dependencies). Since nothing appears to explicitly depend on the ADA packages like libgnat, for now I’ve removed them. Down the road, if I’m able to properly add support I will certainly revisit this decision.

 

Substitutions:

There are a few packages from CentOS Linux 7 that I just won’t be able to use. The primary issue is the kernel. The 3.10 kernel just doesn’t have the support for aarch64 that’s needed, so my current plan is to target 3.19 as the kernel to ship for aarch64. This is still speculation, as I’ve been procrastinating on actually building it. I imagine that will happen for the next blog post update :-)

The other problematic package is anaconda. I’m unsure if I can patch the version in 7 to support aarch64, or if I’ll need to ‘forward-port’ and use a more recent version from fedora to handle the installation. If anyone from the community has insights or suggestions for this, please speak up.

I’ll continue posting updates as the build progresses, or as I find interesting things worth mentioning.

 

March 03, 2015

CentOS Linux 7 and Arm

March 03, 2015 11:54 AM

ARMv7

With the growing list of easily accessible ARM hardware like the RaspBerry Pi 2 and the ODROID-C1, several community efforts have sprouted, working out the details for getting CentOS-7 built and available for the new boards. One of our UK based community members has made the most progress so far, posting his build process on the CentOS arm development list. As he progresses, he’s also been keeping some fairly detailed notes about what changes he’s had to make. Once he’s been able to produce an installable (or extractable) image, we’ll see about incorporating and maintaining his changes as branches in git. With a bit more work, we should be able to start rolling out a fully community built and supported 32bit arm build of CentOS-7.armv7-web

ARMv8

Far from stopping there, work is underway on the 64bit ARM front as well. The fine folks at Applied Micro were kind enough to lend us two of their X-C1 ARMv8 development kits. After a bit of work to replace the default uboot with UEFI, and a few early missteps, the work on an aarch64 port of CentOS-7 is progressing along rather nicely as well. I’ll work on documenting the build system, steps to duplicate for anyone who has the hardware and wants to participate, and potential changes required.

 

If you’d like to get involved or want to follow the progress of the work, please join our arm development list, or join us in #centos-devel on freenode irc.

February 20, 2015

Pulp Project : Managing RPM repositories on CentOS – From CentOS Dojo Brussels 2015

February 20, 2015 03:15 PM

At the CentOS Dojo Brussels 2015 Julien Pivotto presented an introduction to Pulp Project and how it makes life easier for people needing to manage rpm repositories, including your own content and syncing down upstream distro content.

In this session he covers:

  • What is pulp?
  • How does it work?
  • Mirrors management
  • Repositories workflows
  • RPM’s deployment and release management

This Video is now online at https://www.youtube.com/video/IkhCvNXWMC4

You can get the slides from this session at the event page on http://www.slideshare.net/roidelapluie/an-introduction-to-the-pulp-project

Regards

Intoduction to RPM packaging – From CentOS Dojo Brussels 2015

February 20, 2015 11:27 AM

At the CentOS Dojo Brussels 2015 Brian Stinson presented an introduction to RPM packaging session, focused on sysadmins looking to make the next step into packaging their own apps as well as dependencies.

In this session he covers:

  • Short overview of the RPM format
  • Setting up an rpmbuild environment
  • Building packages with rpmbuild
  • Building packages with Mock
  • Where to look for further reading

This Video is now online at https://www.youtube.com/video/CTTbu_q2xiQ

You can get the slides from this session at the event page on http://wiki.centos.org/Events/Dojo/Brussels2015

Regards

February 05, 2015

Guide to Software Collections – From CentOS Dojo Brussels 2015

February 05, 2015 11:38 AM

At the CentOS Dojo Brussels 2015 Honza Horak presented on Software Collections. Starting from what they are, how they work and how they are implemented. During this 42 min session he also ran through how people can create their own collections and how they can extend existing ones.

Software Collections are a way to deliver parallel installable rpm tree’s that might contain extension to existing software already on the machine, or might deliver a new version of a component ( eg. hosting multiple versions of python or ruby on the same machine at the same time, still manageable via rpm tools )

This Video is now online at https://www.youtube.com/video/8TmK2g9amj4

You can get the slides from this session at the event page on http://wiki.centos.org/Events/Dojo/Brussels2015

Regards

January 23, 2015

More builders available for Koji/CBS

January 23, 2015 04:54 PM

As you probably know, the CentOS Project now hosts the CBS effort, (aka Community Build System), that is used to build all packages for the CentOSSIGs.

There was already one physical node dedicated to Koji Web and Koji Hub, and another node dedicated to the build threads (koji-builder). As we have now more people building packages, we thought it was time to add more builders to the mix, and here we go: http://cbs.centos.org/koji/hosts lists now two added machines that are dedicated to Koji/CBS.

Those added nodes have 2 * Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz with 8cores/sockets (+ Hyperthreading activated)  , and 32Gb of RAM. Let's see how the SIGs members will keep those builders busy and throwing a bunch of interesting packages for the CentOS Community :-) . Have a nice week-end

January 19, 2015

I do terrible things sometimes

January 19, 2015 12:00 AM

Abandon hope…

This is not a how-to, but more of a detailed confession about a terrible thing I’ve done in the last few days. The basic concept for this crime against humanity came during a user’s group meeting where several companies expressed overwhelming interest in containers, but were pinned to older, unsupported versions of CentOS due to 3rd party software constraints. They asked if it would be possible to run a CentOS-4 based container instead of a full VM. While obviously migrating from CentOS-4 to a more recent (and supported) version would be preferable, there are some benefits to migrating a CentOS 4 system to a Docker container. I played around with this off and on over the weekend, and finally came up with something fairly functional. I immediately destroyed it so there could be no evidence linking me to this activity.

The basics for how I accomplied this are listed below. They are terrible. Please do NOT follow them.

Disable selinux on your container host.

Look, I told you this was terrible. Dan Walsh and Vaclav Pavlin of Red Hat were kind enough to provide us patches for SELinux in CentOS-6, and then again for CentOS-5. I’m not going to repay their kindness by dragging them into this mess too. Dan is a really nice guy, please don’t make him cry.

The reason we disable selinux is explained on the CentOS-Devel mailing list. Since there’s no patch for CentOS-4 containers, selinux has to be disabled on the host for things to work properly.

Build a minimal vm.

Initially I tried running a slightly modified version of our CentOS-5 kickstart file for Docker through the usual build process. This mostly worked, however it was somewhat unreliable. The build process did not always exit cleanly, often leaving behind broken loop objects I couldn’t unmount. The resulting container worked, but had no functional rpmdb. The conversion trick used with CentOS-5 didn’t work properly with CentOS-4, even accounting for version differences.

I finally decided to build a normal vm image using virt-install. You could use virt-manager to do this part, it really doesn’t matter. There have been a number of functional improvements to anaconda over the years, and going back to the CentOS-4 installer hammers this home. I had to adjust my kickstart to use the old format, removing several more modern options I’d taken for granted. I ended up with the following. For this install, I made sure to install to an image file for easy extraction later on.

install
url --url=http://vault.centos.org/4.9/os/x86_64/
lang en_US.UTF-8
network --device=eth0 --bootproto=dhcp
rootpw --iscrypted $1$UKLtvLuY$kka6S665oCFmU7ivSDZzU.
authconfig --enableshadow
selinux --disabled
timezone --utc UTC

clearpart --all --initlabel
part / --fstype ext3 --size=1024 --grow
reboot
%packages
@Base

%post
dd if=/dev/urandom count=50 | md5sum | passwd --stdin root
passwd -l root

rpm -q grub redhat-logos
rm -rf /boot
rm -rf /etc/ld.so.cache

Extract to tarball

Because we’re wiping out /boot and locking the root user, this image really won’t be useful for anything except converting to a container. The next step is to extract the contents into a smaller archive we can use to build our container. In order to do this, we’ll use the virt-tar-out command. This image is not going to be as small as the regular CentOS containers in the Docker index. This is partly due to rpm dependencies, and partly to how the image is created. Honestly, if you’re doing this, a few megs of wasted disk space is the least of your worries.

virt-tar-out -a /path/to/centos-4.img / - | xz --best > /path/to/centos-4-docker.tar.xz

Building the Container

At this point we have enough that we could actually just do a cat centos-4-docker.tar.xz | docker import - centos4, but there are still a few cleanup items that need to be addressed. From here, a basic Dockerfile that provides a vew changes is in order. Since CentOS-4 is End-of-Life and no longer served via the mirrors, the contents of /etc/yum.repos.d/ need to be modified to point to your local mirror as well as /etc/sysconfig/rhn/sources if you intend to still use the up2date utility. To do this, copy your existing yum repo files and sources from your working CentOS-4 systems into the directory with the container tarball, and use a Dockerfile similar to the one below.

FROM scratch
MAINTAINER you <your@emailaddress.com>
ADD centos-4-docker.tar.xz /
ADD CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo
ADD sources /etc/sysconfig/rhn/sources

DELETE IT ALL

All that’s left now is to run docker’s build command, and you have a successfully built a CentOS-4 base container to use for migration purposes, or just to make your inner sysadmin cry. Either way. This is completely unsupported. If you’ve treated this as a how-to and followed the steps, I would recommend the following actions:

  1. Having a long think about the decisions in your life that led you to this moment
  2. Drinking
  3. Sobbing uncontrollably
  4. Apologizing to everyone around you.

January 12, 2015

Provisioning quickly nodes in a SeaMicro chassis with Ansible

January 12, 2015 02:19 PM

Recently I had to quickly test and deploy CentOS on 128 physical nodes, just to test hardware and that all currently "supported" CentOS releases could be installed quickly when needed. The interesting bit is that it was a completely new infra, without any traditional deployment setup in place, so obviously, as sysadmin, we directly think about pxe/kickstart, which is so trivial to setup. That was the first time I had to "play" with SeaMicro devices/chassis though, and so understanding how they work (the SeaMicro 15K fabric chassis, to be precise). One thing to note is that those seamicro chassis don't provide remote VGA/KVM feature (but who cares, as we'll automate the whole thing, right ? ) but they instead provide either cli (ssh) or rest api access to the management interface, so that you can quickly reset/reconfigure a node, changing vlan assignement, and so on.

It's not a secret that I like to use Ansible for ad-hoc tasks, and I thought that it would be (again) a good tool for that quick task. If you have used Ansible already, you know that you have to declare nodes and variables (not needed, but really useful) in the inventory (if you don't gather inventory from an external source). To configure my pxe setup (and so being able to reconfigure it when needed) I obviously needed to get mac addresses from all 64 nodes in each chassis, decide that hostnames will be n${slot-number}., etc .. (and yes in Seamicro slot 1 = 0/0, slot 2 = 1/0, and so on ...)

The following quick-and-dirty bash script let you do that quickly in 2 seconds (ssh into chassis, gather information, and fill some variables in my ansible host_vars/${hostname} file) :

1
2
3
4
5
6
7
8
#!/bin/bash  
ssh admin@hufty.ci.centos.org "enable ; show server summary | include Intel ; quit" | while read line ;  
do  
  seamicrosrvid=\$(echo \$line |awk '{print \$1}')  
  slot=\$(echo \$seamicrosrvid| cut -f 1 -d '/')  
  id=\$(( \$slot + 1)); ip=\$id ; mac=\$(echo \$line |awk '{print \$3}')  
  echo -e "name: n${id}.hufty.ci.centos.org \nseamicro_chassis: hufty \nseamicro_srvid: $seamicrosrvid \nmac_address: $mac \nip: 172.19.3.$ip \ngateway: 172.19.3.254 \nnetmask: 255.255.252.0 \nnameserver: 172.19.0.12 \ncentos_dist: 6" >  inventory/n${id}.hufty.ci.centos.org  
done  

Nice so we have all \~/ansible/hosts/host_vars/${inventory_hostname} files in one go (I let you add ${inventory_hostname} in the \~/ansible/hosts/hosts.cfg file with the same script, but modify to your needs
For the next step, we assume that we already have dnsmasq installed on the "head" node, and that we also have a httpd setup to provide the kickstart to the nodes during installation.
So our basic ansible playbook looks like this :

---  
- hosts: ci-nodes  
  sudo: True  
  gather_facts: False

  vars:  
    deploy_node: admin.ci.centos.org  
    seamicro_user_login: admin  
    seamicro_user_pass: obviously-hidden-and-changed  
    seamicro_reset_body:  
    action: reset  
    using-pxe: "true"  
    username: "{{ seamicro_user_login }}"  
    password: "{{ seamicro_user_pass }}"

  tasks:  
    - name: Generate kickstart file[s] for Seamicro node[s]  
      template: src=../templates/kickstarts/ci-centos-{{ centos_dist}}-ks.j2 dest=/var/www/html/ks/{{ inventory_hostname }}-ks.cfg mode=0755  
      delegate_to: "{{ deploy_node }}"

    - name: Adding the entry in DNS (dnsmasq)  
      lineinfile: dest=/etc/hosts regexp="\^{{ ip }} {{ inventory_hostname }}" line="{{ ip }} {{ inventory_hostname }}"  
      delegate_to: "{{ deploy_node }}"  
      notify: reload_dnsmasq

    - name: Adding the DHCP entry in dnsmasq  
      template: src=../templates/dnsmasq-dhcp.j2 dest=/etc/dnsmasq.d/{{ inventory_hostname }}.conf  
      delegate_to: "{{ deploy_node }}"  
      register: dhcpdnsmasq

    - name: Reloading dnsmasq configuration  
      service: name=dnsmasq state=restarted  
      run_once: true  
      when: dhcpdnsmasq|changed  
      delegate_to: "{{ deploy_node }}"

    - name: Generating the tftp configuration boot file  
      template: src=../templates/pxeboot-ci dest=/var/lib/tftpboot/pxelinux.cfg/01-{{ mac_address | lower | replace(":","-") }} mode=0755  
      delegate_to: "{{ deploy_node }}"

    - name: Resetting the Seamicro node[s]  
      uri: url=https://{{ seamicro_chassis }}.ci.centos.org/v2.0/server/{{ seamicro_srvid }}  
           method=POST  
           HEADER_Content-Type="application/json"  
           body='{{ seamicro_reset_body | to_json }}'  
           timeout=60  
      delegate_to: "{{ deploy_node }}"

    - name: Waiting for Seamicro node[s] to be available through ssh ...  
      action: wait_for port=22 host={{ inventory_hostname }} timeout=1200  
      delegate_to: "{{ deploy_node }}"

  handlers:  
    - name: reload_dnsmasq  
      service: name=dnsmasq state=reloaded  

The first thing to notice is that you can use Ansible to provision nodes that aren't already running : people think than ansible is just to interact with already provisioned and running nodes, but by providing useful informations in the inventory, and by delegating actions, we can already start "managing" those yet-to-come nodes.
All the templates used in that playbook are really basic ones, so nothing "rocket science". For example the only diff for the kickstart.j2 template is that we inject ansible variables (for network and storage) :

network --bootproto=static --device=eth0 --gateway={{ gateway }}
--ip={{ ip }} --nameserver={{ nameserver }} --netmask={{ netmask }}
--ipv6=auto --activate  
network --hostname={{ inventory_hostname }}  
\<snip\>  
part /boot --fstype="ext4" --ondisk=sda --size=500  
part pv.14 --fstype="lvmpv" --ondisk=sda --size=10000 --grow  
volgroup vg_{{ inventory_hostname_short }} --pesize=4096 pv.14  
logvol /home --fstype="xfs" --size=2412 --name=home --vgname=vg_{{
inventory_hostname_short }} --grow --maxsize=100000  
logvol / --fstype="xfs" --size=8200 --name=root --vgname=vg_{{
inventory_hostname_short }} --grow --maxsize=1000000  
logvol swap --fstype="swap" --size=2136 --name=swap --vgname=vg_{{
inventory_hostname_short }}  
\<snip\>  

The dhcp step isn't mandatory, but at least in that subnet we only allow dhcp to "already known" mac address, retrieved from the ansible inventory (and previously fetched directly from the seamicro chassis) :

# {{ name }} ip assignement  
dhcp-host={{ mac_address }},{{ ip }}  

Same thing for the pxelinux tftp config file :

SERIAL 0 9600  
DEFAULT text  
PROMPT 0  
TIMEOUT 50  
TOTALTIMEOUT 6000  
ONTIMEOUT {{ inventory_hostname }}-deploy

LABEL local  
MENU LABEL (local)  
MENU DEFAULT  
LOCALBOOT 0

LABEL {{ inventory_hostname}}-deploy  
kernel CentOS/{{ centos_dist }}/{{ centos_arch}}/vmlinuz  
MENU LABEL CentOS {{ centos_dist }} {{ centos_arch }}- CI Kickstart
for {{ inventory_hostname }}  
{% if centos_dist == 7 -%}  
append initrd=CentOS/7/{{ centos_arch }}/initrd.img net.ifnames=0 biosdevname=0 ip=eth0:dhcp inst.ks=http://admin.ci.centos.org/ks/{{ inventory_hostname }}-ks.cfg console=ttyS0,9600n8  
{% else -%}  
append initrd=CentOS/{{ centos_dist }}/{{ centos_arch }}/initrd.img ksdevice=eth0 ip=dhcp ks=http://admin.ci.centos.org/ks/{{ inventory_hostname }}-ks.cfg console=ttyS0,9600n8  
{% endif %}  

The interesting part is the one on which I needed to spend more time : as said, it was the first time I had to play with SeaMicro hardware, so I had to dive into documentation (which I *always* do, RTFM FTW !) and understand how to use their Rest API but once done, it was a breeze. Ansible by default doesn't provide a native resource for Seamicro, but that's why Rest exists, right and thanfully, Ansible has a native URI module, which we use here . The only thing on which I had to spend more time was to understand how to properly construct the body, but declaring in the yaml file as a variable/list and then converting it on the fly to json (with the magical body='{{ seamicro_reset_body | to_json }}' ) was the way to go and is so self-explained when read now.

And here we go, calling that ansible playbook and suddenly 128 physical machines were being installed (and reinstalled with different CentOS versions - 5,6,7 - and arches i386,x86_64)

Hope this helps if you  have to interact with Seamicro chassis from within an ansible playbook too


Powered by Planet!
Last updated: July 05, 2015 12:00 AM