October 01, 2015

Progress on the Software Collections SIG

October 01, 2015 10:30 AM


The software collections special interest group ( https://wiki.centos.org/SpecialInterestGroup/SCLo ) has been making great progress and have finished their initial bootstrap process. They are now getting ready to do a mass build for test and release. I’ve just delivered their rpm signing key, so we are pretty close to seeing content in mirror.centos.org.

As an initial goal, they are working on and delivering rpms – but in parallel efforts are on to get container images into the registries as well, so folks using containers today are able to consume the software collections in either format.

The effort is being co-ordinated by Honza Horak ( https://twitter.com/HorakHonza ), and he’s the best person to get in touch with to join and help.


September 24, 2015

CentOS AltArch SIG status

September 24, 2015 02:22 PM

Recently I had (from an Infra side) to start deploying KVM guests for the ppc64 and ppc64le arches, so that AltArch SIGs contributors could start bootstrapping CentOS 7 rebuild for those arches. I'll probably write a tech review about Power8 and the fact you can just use libvirt/virt-install to quickly provision new VMs on PowerKVM , but I'll do that in a separate post.

Parallel to ppc64/ppc64le, armv7hl interested some Community members, and the discussion/activity about that arch is discussed on the dedicated mailing list. It's slowly coming and some users already reported having used that on some boards (but still unsigned and no updates packages -yet- )

Last (but not least) in this AltArch list is i686 : Johnny built all packages and are already publicly available on buildlogs.centos.org , each time in parallel to the x86_64 version. It seems that respinning the ISO for that arch and last tests would be the only things to do.

If you're interested in participating in AltArch (and have special interesting a specific arch/platform), feel free to discuss that on the centos-devel list !

September 17, 2015

CentOS Dojo in Barcelona

September 17, 2015 02:46 PM

So, thanks to the folks from Opennebula, we'll have another CentOS Dojo in Barcelona on Tuesday 20th October 2015. That even will be colocated with the Opennebulaconf happening the days after that Dojo. If you're attending the OpennebulaConf, or if you're just in the area and would like to attend the CentOS Dojo, feel free to register

Regarding the Dojo content, I'll be myself giving a presentation about Selinux : covering a little bit of intro (still needed for some folks afraid of using it , don't know why but we'll change that ...) about selinux itself, how to run it on bare-metal, virtual machines and there will be some slides for the mandatory container hype thing. But we'll also cover managing selinux booleans/contexts, etc through your config management solution. (We'll cover puppet and ansible as those are the two I'm using on a daily basis) and also how to build and deploy custom selinux policies with your config management solution.

On the other hand, if you're a CentOS user and would like yourself to give a talk during that Dojo, feel free to submit a talk ! More informations about the Dojo on the dedicated wiki page

See you there !

September 10, 2015

Our second stable Atomic Host release

September 10, 2015 10:41 PM

Jason just announced our second stable CentOS Atomic Host release at http://seven.centos.org/2015/09/announcing-a-new-release-of-centos-atomic-host/

I’m very excited about this one, and its not only because I’ve helped make it happen – but this is also the first time a SIG in the CentOS Ecosystem has done a full release, from rpms, to images, to hosted vendor space ( AMI’s in 9 regions on Amazon’s EC2 ).

One of the other things that I’ve been really excited about is that this is the first time we’ve used the rpm-sign infra that I’ve been working on these past few days. It allows SIG built content ( rpms or images or ISOs or even text ) to be signed with pre-selected keys. And do this without having to compromise the key trust level. I will blog more around this process and how SIGs can consume these keys, and how this maps to the TAG model being used in cbs.centos.org

for now, go get started with the CentOS Atomic Host!


CentOS Dojo in Barcelona, 20th Oct 2016

September 10, 2015 10:10 PM


We have a dojo coming up in Barcelona, co-located with the OpenNebula conference in late October. The event is going to run from 1:30pm to 6:30pm ( but I suspect it wont really end till well into the early hours of the morning as people keep talking about CentOS things over drinks, dinner, more drinks etc ! ).

You can get the details, including howto register at https://wiki.centos.org/Events/Dojo/Barcelona2015.

Fabian is going to be there, and we are talking to a great set of potential speakers – the focus is going to be very much on hands on learning about technologies on and around CentOS Linux! And as in the past, we expect content to be sysadmin / operations folks specific rather than developers ( although, we highly encourage developers to come along as well, and talk to us and share their experiences with the sysadmin world! ).


timezone mangling

September 10, 2015 09:17 PM

Because of what I do and how / where I do it, there are always online, realtime conversations going on ( irc or IM ); and its never really been a huge issue except for people in the US pacific coast. Its always a case of them starting work when I am finishing for the day, and even when i work late at night for the odd hours, its almost always whack in the middle of their lunch hours. And they finish work, even their late night sessions, just about when I am getting started for the day.

So to everyone on that TZ, just want to remind everyone that the best thing to do is stick with emails. I know its fashionable these days to complain about emails and all that, but by and large there is no other means of comms around these days that is easier to get to, mature and really very productive for async conversations. The other thing to keep in mind is that while there are other services and ideas floating around that help solve specific challenges that email isnt best suited for, none of them do a good enough job to remove the email process from the equation. So if we are still going to have email knocking about, lets just use it.

And I’m not ignoring people on irc :) but with 300+ panes in irssi, sometimes it can get hectic and I will often encourage you to ‘Lets Move to Mail’. Its not because I dont want to have the convo right now, its because I want to have the complete conversation!


Announcing a New Release of CentOS Atomic Host

September 10, 2015 09:16 PM

Today we’re releasing a significant update to the CentOS Atomic Host (version 7.20150908), a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host.

CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, as an installable ISO image, as a qcow2 image, or as an Amazon Machine Image. These images are available for download at cloud.centos.org. The backing ostree repo is published to mirror.centos.org.

Currently, the CentOS Atomic Host includes these core component versions:

  • kernel 3.10.0-229
  • docker 1.7.1-108
  • kubernetes 1.0.0-0.8.gitb2dafda
  • etcd 2.0.13-2
  • flannel 0.2.0-10
  • cloud-init 0.7.5-10
  • ostree 2015.6-4
  • atomic 1.0-108


If you’re running the version of CentOS Atomic Host that shipped in June, you can upgrade to the current image by running the following command:

$ sudo atomic host upgrade

If you’re currently run the older, test version of the CentOS Atomic Host, or if you’re running any other atomic host (from any distro or release in the past), you can rebase to this released CentOS Atomic Host by running the following two commands :

$ sudo ostree remote add centos-atomic-host http://mirror.centos.org/centos/7/atomic/x86_64/repo
$ sudo rpm-ostree rebase centos-atomic-host:centos-atomic-host/7/x86_64/standard



CentOS-Atomic-Host-7-Vagrant-Libvirt.box (393 MB) and CentOS-Atomic-Host-7-Vagrant-Virtualbox.box (404 MB) are Vagrant boxes for Libvirt and Virtualbox providers.

The easiest way to consume these images is via the Atlas / Vagrant Cloud setup (see https://atlas.hashicorp.com/centos/boxes/atomic-host. For example, getting the VirtualBox instance up would involve running the following two commands on a machine with vagrant installed:

$ vagrant init centos/atomic-host && vagrant up --provider virtualbox


The installer ISO (682 MB) can be used via regular install methods (PXE, CD, USB image, etc.) and uses the Anaconda installer to deliver the CentOS Atomic Host. This allows flexibility to control the install using kickstarts and define custom storage, networking and user accounts. This is the recommended process for getting CentOS Atomic Host onto bare metal machines, or to generate your own image sets for custom environments.


The CentOS-Atomic-Host-7-GenericCloud.qcow2 (922 MB) is suitable for use in on-premise and local virtualized environments. We test this on OpenStack, AWS and local Libvirt installs. If your virtualization platform does not provide its own cloud-init metadata source, you can create your own NoCloud iso image. The Generic Cloud image is also available compressed in gz (389 MB) and xz compressed (303 MB) formats.

Amazon Machine Images

Region         Image ID
------         --------
sa-east-1      ami-47ed785a
ap-northeast-1 ami-3458d234
ap-southeast-2 ami-05511e3f
us-west-2      ami-a5b6ab95
ap-southeast-1 ami-dc99938e
eu-central-1   ami-8c111191
eu-west-1      ami-0b6e4d7c
us-west-1      ami-69679d2d
us-east-1      ami-69c3aa0c

SHA Sums

a132d59732e758012029a646c466227f4ecf0c71cc42f0a10d3672908e463c0c CentOS-Atomic-Host-7.20150908-GenericCloud.qcow2
aad5d39e0683dc997f34902b068c7373aac3f7dc9b2c962a6ac0fe7394e2aa58 CentOS-Atomic-Host-7.20150908-GenericCloud.qcow2.gz
c8432175a012e7f13b7005fe9c1fe43e03e47ca433db8230ab6d5d1831d2cbe0 CentOS-Atomic-Host-7.20150908-GenericCloud.qcow2.xz
b222702942d02da2204581de6f877cf93289459a99f9080e29016e3b90328098 CentOS-Atomic-Host-7.20150908-Installer.iso
5531fa99429b38c6e6c4aca87672bd5990ab90f6445cc0e55c9121ad62229141 CentOS-Atomic-Host-7.20150908-Vagrant-Libvirt.box
bdcf58772117dd3a84100e5902f4f345daeea7c04f057c0ab6e29bfef3c82eab CentOS-Atomic-Host-7.20150908-Vagrant-Virtualbox.box

Release Cycle

The rebuild image will follow the upstream Red Hat Enterprise Linux Atomic Host cadence. After sources are released, they’ll be rebuild and included in new images. After the images are tested by the SIG and deemed ready, they’ll be announced. If you’d like to help with the process, there’s plenty to do!

Getting Involved

CentOS Atomic Host is produced by the CentOS Atomic SIG, based on upstream work from Project Atomic. If you’d like to work on testing images, help with packaging, documentation, or even help define the direction of our monthly release — join us!

The SIG meets weekly on Thursdays at 16:00 UTC in the #centos-devel channel, and you’ll often find us in #atomic and/or #centos-devel if you have questions. You can also join the atomic-devel mailing list if you’d like to discuss the direction of Project Atomic, its components, or have other questions.

Getting Help

If you run into any problems with the images or components, feel free to ask on the centos-devel mailing list.

Have questions about using Atomic? See the atomic mailing list or find us in the #atomic channel on Freenode.

Ext4 limitation with GDT blocks number

September 10, 2015 08:14 AM

In the last days, I encountered a strange issue^Wlimitation with Ext4 that I wouldn't have thought of. I've used ext2/ext3/ext4 for quite some time and so I've been used to resize the filesystem "online" (while "mounted"). In the past you had to use ext2online for that, then it was integrated into resize2fs itself.

The logic is simple and always the same : extend your underlaying block device (or add another one), then modify the LVM Volume Group (if needed), then the Logical Volume and finally the resize2fs operation, so something like

lvextend -L +${added_size}G /dev/mapper/${name_of_your_logical_volume} 
resize2fs /dev/mapper/${name_of_your_logical_volume}

I don't know how much times I've used that, but this time resize2fs wasn't happy :

resize2fs: Operation not permitted While trying to add group #16384

I remember having had in the past an issue because of the journal size not being big enough. But this wasn't the case here.

FWIW, you can always verify your journal size with dumpe2fs /dev/mapper/${name_of_your_logical_volume} |grep "Journal Size"

Small note : if you need to increase the journal size, you have to do it "offline" as you have to remove the journal and then add it back with a bigger size (and that also takes time) :

umount /$path_where_that_fs_is_mounted
tune2fs -O ^has_journal /dev/mapper/${name_of_your_logical_volume}
# Assuming we want to increase to 128Mb
tune2fs -j -J size=128 /dev/mapper/${name_of_your_logical_volume} 

But in that case, as said, it wasn't really the root cause : while the resize2fs: Operation not permitted doesn't give much informations, dmesg was more explicit :

EXT4-fs warning (device dm-2): ext4_group_add: No reserved GDT blocks, can't resize

The limitation is that when the initial Ext4 filesystem is created, the number of reserved/calculated GDT blocks for that filesystem will allow to grow it by a factor of 1000.

Ouch, that system (CentOS 6.7) I was working on had been provisioned in the past for a certain role, and that particular fs/mount point was set to 2G (installed like this through the Kickstart setup ). But finally role changed and so the filesystem has been extended/resized some times, until I tried to extend it to more than 2TiB, which then caused resize2fs to complain ...

So two choices :

  • you do it "offline" through umount, e2fsck, resize2fs, e2fsck, mount (but time consumming)
  • you still have plenty of space in the VG, and you just want to create another volume with correct size, format it, rsync content, umount old one and mount the new one.

That means that I learned something new (one learns something new every day !), and also the fact that you then need to take that limitation in mind when using a kickstart (that doesn't include the --grow option, but a fixed size for the filesystem).

Hope that it can help

September 03, 2015

Implementing TLS for postfix

September 03, 2015 08:27 AM

As some initiatives (like Let's Encrypt as one example) try to force TLS usage everywhere. We thought about doing the same for the CentOS.org infra. Obviously we already had some x509 certificates, but not for every httpd server that was serving content for CentOS users. So we decided to enforce TLS usage on those servers. But TLS can be used obviously on other things than a web server.

That's why we considered implementing something for our Postfix nodes. The interesting part is that it's really easy (depending of course at the security level one may want to reach/use). There are two parts in the postfix main.cf that can be configured :

  • outgoing mails (aka your server sends mail to other SMTPD servers)
  • incoming mails (aka remote clients/servers send mail to your postfix/smtpd server)

Let's start with the client/outgoing part : just adding those lines in your main.cf will automatically configure it to use TLS when possible, but otherwise fall back on clear if remote server doesn't support TLS :

# TLS - client part
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache 

The interesting part is the smtp_tls_security_level option : as you see, we decided to force it to may . That's what Postfix official TLS documentation calls "Opportunistic TLS" : in some words it will try TLS (even with untrusted remote certs !) and will only default to clear if no remote TLS support is available. That's the option we decided to use as it doesn't break anything, and even if the remote server has a self-signed cert, it's still better to use TLS with self-signed than clear text, right ?

Once you have reloaded your postfix configuration, you'll directly see in your maillog that it will start trying TLS and deliver mails to servers configured for it :

Sep  3 07:50:37 mailsrv postfix/smtp[1936]: setting up TLS connection to ASPMX.L.GOOGLE.com[]:25
Sep  3 07:50:37 mailsrv postfix/smtp[1936]: Trusted TLS connection established to ASPMX.L.GOOGLE.com[]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Sep  3 07:50:37 mailsrv postfix/smtp[1936]: DF584A00774: to=<>, orig_to=<>, relay=ASPMX.L.GOOGLE.com[]:25, delay=1, delays=0/0.12/0.22/0.71, dsn=2.0.0, status=sent (250 2.0.0 OK 1441266639 79si29025652qku.67 - gsmtp)

Now let's have a look at the other part : when you want your server to present the STARTTLS feature when remote servers/clients try to send you mails (still in postfix main.cf) :

# TLS - server part
smtpd_tls_cert_file = /etc/pki/tls/certs/<%= postfix_myhostname %>-postfix.crt 
smtpd_tls_key_file = /etc/pki/tls/private/<%= postfix_myhostname %>.key
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache

Still easy, but here we also add our key/cert to the config but if you decide to use a signed by a trusted CA cert (like we do for centos.org infra), be sure that the cert is the concatenated/bundled version of both your cert and the CAChain cert. That's also documented in the Postfix TLS guide, and if you're already using Nginx, you already know what I'm talking about as you already have to do it too.

If you've correctly configured your cert/keys and reloaded your postfix config, now remote SMTPD servers will also (if configured to do so) deliver mails to your server through TLS. Bonus point if you're using a cert signed by a trusted CA, as from a client side you'll see this :

Sep  2 16:17:22 hoth postfix/smtp[15329]: setting up TLS connection to mail.centos.org[]:25
Sep  2 16:17:22 hoth postfix/smtp[15329]: Trusted TLS connection established to mail.centos.org[]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Sep  2 16:17:23 hoth postfix/smtp[15329]: CC8351C00C9: to=<fake_one_for_blog_post@centos.org>, relay=mail.centos.org[]:25, delay=1.6, delays=0.19/0.03/1.1/0.31, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as A7299A006E2)

The Trusted TLS connection established part shows that your smtpd server presents a correct cert (bundle) and that the remote server sending you mails trusts the CA used to sign that cert.

There are a lot of TLS options that you can also add for tuning/security reasons, and all can be seen through postconf |grep tls, but also on the Postfix postconf doc

August 24, 2015

A Flashable CentOS Image for the Intel Edison

August 24, 2015 06:56 PM

A Flashable Image for the Intel Edison

The Intel Edison system-on-a-chip boards are pretty cool, a little compute module can plug into a number of different breakout boards. There’s an Arduino-style board, and another form-factor featuring a bunch of stackable modules (GPIO, SD Card, OLED Screen etc.) Since the system is a dual-core Atom, we can easily put CentOS on it! To start with we will focus on the userland components and use the kernel that comes bundled in the Edison toolkit.

If you’d rather not read the whole thing, here are some links to a flashable rootfs image and a yum repo containing the tools that go with it:
Bootable Image: http://people.centos.org/bstinson/edison/edison-image-centos.ext4.xz
Sources and Yum Repo: http://people.centos.org/bstinson/edison/7/

More of the upcoming work (building a kernel, and the rest of the SDK) will be done under the Alternate Architectures SIG once that is in full-swing. In the meantime I’d love to see discussion, bug reports, and collaboration on the centos-devel list.

My Email: brian (at) bstinson (dot) com

IRC: bstinson

Building your own rootfs image

If you’d like to spin your own image (instead of using the prebuilt image above) here are the steps you need to get a flashable image. The Edisons are fairly simple to install to (since the rootfs is simply an ext4 image)

To begin with we need a 1G file that will serve as our ext4 image

# Make a 1G file full of Zeros
root@host# dd if=/dev/zero of=~/projects/edison/edison-image-centos.ext4 bs=1M count=1024

# Put an ext4 filesystem on it
root@host# mkfs.ext4 ~/projects/edison/edison-image-centos.ext4

# Mount it someplace handy
root@host# mount -t ext4 ~/projects/edison/edison-image-centos.ext4 /mnt/edison-image-centos

Now that we have the image mounted in a useful place we can start installing

# Add the centos-release and centos-release-edison files
root@host# rpm --root /mnt/edison-image-centos -Uvh --nodeps http://buildlogs.centos.org/centos/7/os/i386/Packages/centos-release-7-1.1503.el7.centos.2.8.1.i686.rpm\

# Tweak the basearch variable (allows you to do target install from an x86_64 host)
root@host# echo 'i386' > /mnt/edison-image-centos/etc/yum/vars/basearch

# Install the packages
root@host# yum --installroot=/mnt/edison-image-centos install bind-utils bash yum vim-minimal shadow-utils less iputils iproute firewalld rootfiles centos-release edison-modules edison-tweaks wpa_supplicant dhclient

Flashing the rootfs image

You can grab dfu-util for CentOS 7 from here

Connect the OTG port on the Edison breakout board to a USB port and it should show up as a dfu device.

# The dfu VendorID:ProductID is 8087:0a99 for the Edison
root@host# dfu-util -l -d 8087:0a99
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=11, name=”initrd”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=10, name=”vmlinuz”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=9, name=”home”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=8, name=”update”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=7, name=”rootfs”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=6, name=”boot”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=5, name=”u-boot-env1″, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=4, name=”u-boot1″, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=3, name=”u-boot-env0″, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=2, name=”u-boot0″, serial=”UNKNOWN”

# Flash the image
root@host# dfu-util -d 8087:0a99 -a rootfs -D ~/projects/edison/edison-image-centos.ext4

Connect to the newly installed Edison

Plug the Console port into a USB port and fire up your favorite serial terminal

root@host# screen /dev/ttyUSB0 115200
Flashing already done...
GADGET DRIVER: usb_dnl_dfu
reading vmlinuz
5383904 bytes read in 133 ms (38.6 MiB/s)
Valid Boot Flag
Setup Size = 0x00003c00
Magic signature found
Using boot protocol version 2.0c
Linux kernel version 3.10.17-poky-edison+ (sys_dswci@tlsndgbuild004) #1 SMP PREEMPT Wed Apr 29 03:54:01 CEST 2015
Building boot_params at 0x00090000
Loading bzImage at address 00100000 (5368544 bytes)
Magic signature found
Kernel command line: "rootwait root=PARTUUID=012b3303-34ac-284d-99b4-34e03a2335f4 rootfstype=ext4 console=ttyMFD2 earlyprintk=ttyMFD2,keep loglevel=4 g_multi.ethernet_config=cdc systemd.unit=multi-user.target hardware_id=00 g_multi.iSerialNumber=88a7cbd65118ecb7cbe1fde0dd5174df g_multi.dev_addr=02:00:86:51:74:df platform_mrfld_audio.audio_codec=dummy"

Starting kernel …

[ 0.760411] pca953x 1-0020: failed reading register
[ 0.765618] pca953x 1-0021: failed reading register
[ 0.770719] pca953x 1-0022: failed reading register
[ 0.775838] pca953x 1-0023: failed reading register
[ 1.623920] snd_soc_sst_platform: Enter:sst_soc_probe
[ 2.028440] pmic_ccsm pmic_ccsm: Error reading battery profile from battid frmwrk
[ 2.046563] pmic_ccsm pmic_ccsm: Battery Over heat exception
[ 2.046634] pmic_ccsm pmic_ccsm: Battery0 temperature inside boundary

Welcome to CentOS Linux 7 (Beta)!

Expecting device dev-ttyMFD2.device…
[ OK ] Reached target Remote File Systems.
[ OK ] Listening on Delayed Shutdown Socket.
[ OK ] Listening on /dev/initctl Compatibility Named Pipe.
[ OK ] Listening on Journal Socket.
Mounting Debug File System…
Starting Apply Kernel Variables…
Starting Create list of required static device nodes…rrent kernel…
Mounting POSIX Message Queue File System…
Starting Setup Virtual Console…
Mounting Configuration File System…
Mounting FUSE Control File System…
Starting Journal Service…
[ OK ] Started Journal Service.
[ OK ] Listening on udev Kernel Socket.
[ OK ] Listening on udev Control Socket.
Starting udev Coldplug all Devices…
[ OK ] Reached target Encrypted Volumes.
[ OK ] Set up automount Arbitrary Executable File Formats F…utomount Point.
[ OK ] Reached target Swap.
Starting Remount Root and Kernel File Systems…
Expecting device dev-disk-by\x2dpartlabel-home.device…
[ OK ] Created slice Root Slice.
[ OK ] Created slice User and Session Slice.
[ OK ] Created slice System Slice.
[ OK ] Reached target Slices.
[ OK ] Created slice system-getty.slice.
[ OK ] Created slice system-serial\x2dgetty.slice.
[ OK ] Mounted Debug File System.
[ OK ] Started Apply Kernel Variables.
[ OK ] Mounted POSIX Message Queue File System.
[ OK ] Started Setup Virtual Console.
[ OK ] Mounted Configuration File System.
[ OK ] Mounted FUSE Control File System.
[ OK ] Started Remount Root and Kernel File Systems.
[ OK ] Started Create list of required static device nodes …current kernel.
Starting Create static device nodes in /dev…
Starting Load/Save Random Seed…
Starting Configure read-only root support…
[ OK ] Started udev Coldplug all Devices.
[ OK ] Started Create static device nodes in /dev.
[ OK ] Started Load/Save Random Seed.
[ OK ] Started Configure read-only root support.
Starting udev Kernel Device Manager…
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Started udev Kernel Device Manager.
[ OK ] Found device /dev/ttyMFD2.
[ OK ] Found device /dev/disk/by-partlabel/home.
Mounting /home…
[ OK ] Reached target Sound Card.
[ OK ] Mounted /home.
[ OK ] Reached target Local File Systems.
Starting Trigger Flushing of Journal to Persistent Storage…
Starting Create Volatile Files and Directories…
[ OK ] Started Trigger Flushing of Journal to Persistent Storage.
[ OK ] Started Create Volatile Files and Directories.
Starting Update UTMP about System Reboot/Shutdown…
[ OK ] Started Update UTMP about System Reboot/Shutdown.
[ OK ] Reached target System Initialization.
[ OK ] Reached target Timers.
[ OK ] Reached target Paths.
[ OK ] Listening on D-Bus System Message Bus Socket.
[ OK ] Reached target Sockets.
[ OK ] Reached target Basic System.
Starting firewalld – dynamic firewall daemon…
Starting Dump dmesg to /var/log/dmesg…
Starting Disable the watchdog device on the Intel Edison…
[ 7.665241] intel_scu_watchdog_evo: watchdog_stop
Starting Permit User Sessions…
Starting Login Service…
Starting D-Bus System Message Bus…
[ OK ] Started D-Bus System Message Bus.
Starting LSB: Bring up/down networking…
[ OK ] Started Dump dmesg to /var/log/dmesg.
[ OK ] Started Disable the watchdog device on the Intel Edison.
[ OK ] Started Permit User Sessions.
[ OK ] Started LSB: Bring up/down networking.
Starting Getty on tty1…
[ OK ] Started Getty on tty1.
Starting Serial Getty on ttyMFD2…
[ OK ] Started Serial Getty on ttyMFD2.
[ OK ] Reached target Login Prompts.
[ OK ] Started Login Service.
[ OK ] Reached target Multi-User System.

CentOS Linux 7 (Beta)
Kernel 3.10.17-poky-edison+ on an i686

localhost login:

Connecting the WiFi Interface

From here, you can connect using the onboard wireless controller:

# Modify /etc/sysconfig/wpa_supplicant to include your device

# Add your network to the wpa_supplicant config
root@edison# wpa_passphrase MyHomeSSID "PasswordToMYWifi" > /etc/wpa_supplicant/wpa_supplicant.conf

# Start the wpa_supplicant service
root@edison# systemctl enable wpa_supplicant
root@edison# systemctl start wpa_supplicant

# Get an address on the interface
root@edison# dhclient wlan0

Known Issues

  • The disable-watchdog service starts late in the boot process, so touching
    /.autorelabel will result in a bootloop (the watchdog timer times out before
    the selinux relabel is finished)
  • We’re still using and distributing the Kernel from the toolkit, we will be
    working on building a CentOS kernel which may also allow for a 64-bit userland

July 29, 2015

Cloud In A Box: CentOS OpenStack Remix

July 29, 2015 04:58 PM

OpenStack is the current de facto standard for cloud computing platforms and is supported by all major Linux distributions. Coupled with its role as the base technology in the domains of NFV & SDN, it has become one of the hottest softwares for networking community. It is a combination of numerous components and services, which means that deploying openstack is often complex, time consuming and error prone, especially for beginners. Deployment options vary from manual setup i.e., to install and setup each individual component manually, to use of automated tools such as Devstack, Fuel and Packstack.

The easiest way for getting started with openstack is through automated tools but using them properly requires significant forum/manual scavenging effort. This is too daunting for cloud application developers or anyone whose primary concern is to evaluate the cloud technology.

To ease these deployment concerns, our goal is to provide a robust, pre-configured (yet customizable) and easily installed openstack setup. The result will be a “CentOS Remix” with an option to setup openstack during installation. This is implemented by integrating two efforts by the Red Hat community namely RDO and Packstack into the CentOS installer i.e., Anaconda.


The development involves integrating OpenStack from the CentOS Cloud SIG (which also feeds the Red Hat community’s openstack packaging effort, RDO ) and Packstack (openstack deployment tool) with Anaconda. The resulting remix will:

  • Install CentOS along with OpenStack in one installation cycle.
  • Use packstack to configure & deploy openstack (in post-install phase).

The integration will be achieved by developing an add-on for the Anaconda installer. Anaconda add-ons can be used to add support for custom configurations screens in the graphical and text-based user interface. OpenStack support can also be added to anaconda by modifying its source but add-ons are also extensible, maintainable, easier to debug  and test. They also provide an opportunity to extend openstack support to other Linux distributions that use anaconda.

Current Status:

Anaconda has three modes of operation i.e., Kickstart, Graphical and Text User Interfaces. Hence our add-on development is divided into adding openstack installation support for each of these three modes. Uptill now Kickstart support has been implemented i.e., user is able to install openstack through a kickstart file during setup.

Currently GUI support is being developed. After that TUI support and openstack customization options will be added. Final deliverable will be an “CentOS Openstack remix” ISO (~1.2GB) extending CentOS minimal ISO.

Project source along with testing instructions are available at Github

  • Email: asadxflow@gmail.com
  • IRC: asad_ (#centos-devel)



July 24, 2015

RootFS Build Factory: The Story So Far

July 24, 2015 11:04 AM

Johnny Hughes has already posted images for Cubietruck and Raspberry Pi 2 and told you how to use them with your boards. In this post, I would like to tell you all the what has gone into development of RootFS Build Factory so far which includes a bit about the CentOS ARMv7 effort.

When I first started looking up project ideas for GSoC this year, the RootFS Build Factory idea caught my attention because it fit right into my interests and skill set. This was in the first week of March. Back then there was no CentOS ARMv7 and as far as I knew, the only person who had done any work in the area of building ARMv7 packages was Howard Johnson. His post on the CentOS arm-dev mailing list http://lists.centos.org/pipermail/arm-dev/2015-February/000089.html described his efforts of compiling CentOS for ARMv7 using Raspberry Pi 2 and Odroid C1. This was my first introduction to CentOS ARMv7.

Back then it seemed like the RootFS Build Factory project would require building a minimal CentOS ARMv7 first and then working on a set of scripts to re-bundle packages in this minimal build.
I got in touch with members on the CentOS team on #centos-devel and #centos-gsoc on Freenode and interacted with Jim Perrin and Ian McLeod (who later became my mentor for this GSoC project). With their inputs I started thinking of alternatives to Howard’s method of compiling packages and came across work done by msalter from Redhat https://www.redhat.com/archives/fedora-buildsys-list/2009-July/msg00000.html

He had developed plugins to cross compile packages using mock and Koji and a yum plugin for installing non native rpms. This seemed great as I did not have any ARMv7 hardware at that point and the idea of generating ARMv7 on fast x86_64 desktop seemed like a good one. Later on, after discussion with msalter (which happened in the first week of June) and based on his advice we realized that this approach wasn’t going to work for CentOS as the pre/post install scripts in the RPMs wouldn’t run in a cross environment.

My original GSoC Proposal was based on using msalter’s yum plugin to build ARMv7 images on x86_64 but after discussion with msalter and in consultation with my mentor Ian, it was decided not to go forward with the yum cross plugin approach and to focus on the targets in my proposal which would involve building CentOS ARMv7 images using either ARMv7 hardware or QEMU.

There was still the big issue of how, where and who would compile CentOS ARMv7. This is where Fabian Arrotin’s efforts came in and took care of matters. His work using a plague farm he setup on the Scaleway nodes, got us a working set of ARMv7 packages. Until then Ian and I were contemplating doing the build ourselves using hardware we had at our disposal.

We decided that until the ARMv7 CentOS build was ready, we would use Fedora for development. Fabian Arrotin was very quick in creating the repositories which meant we didn’t have to use Fedora for long. Of course the first build of CentOS 7 ARM using the RootFS Build Factory happened on Fedora 21.

The present status of the project is this:

  • Tested generation of images for QEMU (https://github.com/mndar/rbf/blob/master/doc/QEMU_README.md), Cubietruck, Odroid C1, Raspberry Pi 2, Banana Pi, Cubieboard 2. Tests for the last two have been reported by Nicolas [nicolas at shivaserv.fr] and David Tischler [david.tischler at mininodes.com] respectively. The Odroid C1 and Raspberry Pi 2 images do not use the CentOS Kernel.
  • Untested Boards: Cubieboard, Wandboard{solo,dual,quad}, Pandaboard, CompuLab TrimSlice, Beaglebone. Support for these boards has been added based on information on the Fedora Wiki. I do not have these boards with me.
  • For adding support for more boards, you can refer to https://github.com/mndar/rbf/blob/master/doc/ADD_SUPPORT_README.md

Presently there are 3 main components in RootFS Build Factory

  • rbf.py : takes a XML Template and generates an image.
  • rbfdialog.py : dialog based UI using the python2-pythondialog library to load/edit/create XML Templates.
  • rbfinstaller.py : Takes a Generic/QEMU image, writes it to your microSD, then writes board specific U-Boot to microSD. This works for the boards where the CentOS kernel is used since the only difference between images for different boards is U-Boot. In case of Raspberry Pi 2 and Odroid C1, just the image generated by RootFS Build Factory is written to microSD.

The original proposal mentioned writing the UI in PyGTK but because cross development was out of the picture and I didn’t think people would run X11 in QEMU just for RootFS Build Factory, I chose a console based approach. Although the interface loads in the QEMU console, it doesn’t load the colors and there is some text visible on the edges while selecting files/directories. I suggest you set up bridge networking on your host and then SSH into the QEMU instance.

If you have any queries you can post them in the comments below or email me [emailmandar at gmail.com] or discuss it on the CentOS arm-dev mailing list http://lists.centos.org/mailman/listinfo/arm-dev

Introducing Flamingo: A Lightweight Cloud Instance Contextualization Tool for CentOS Atomic Host

July 24, 2015 11:01 AM

When using on-demand instantiation of virtual machines in cloud computing,
users pass configuration data to the cloud and that data is used for
configuring the instances.
This process is called contextualization. Contextualization includes
identity(users, groups), network, system services and disk configuration.

Flamingo is a contextualization tool that is being developed under GSoC 2015

that aims to handle early initialization of cloud instances.

The current de facto standard for instance virtualization is cloud-init.
However, there are some problems with it. The most prominent ones are:

  • The usage of a scripting language (Python in this case), since scripting
    languages have the overhead of the interpreter, its dependencies and
    being slower than compiled ones due to their dynamic nature.
  • The documentation is lacking at best. There are examples of common
    use-cases. However, most of the code-base and plug-ins are undocumented.
    Inspecting the code-base is a prerequisite to extend the functionality or
    even understand it.
  • Test coverage is low. Making it hard to extend, maintain, and improve.

Don`t get me wrong it gets the job done. But, it has a lot of issuses and
these issues make it hard to use, extend and maintain.


Flamingo aims to solve the following problems encountered in cloud contextualization;

  • Speed
  • Dependency
  • Maintainability
  • Extensibility

Go is a very suitable choice for a tool like this. Since, it is fast,
it has cheap concurrency, and dependency management is a breeze (see godep).
It allows the distribution of a single executable binary with its dependencies.


Target Distribution

The first target for Flamingo is the CentOS Atomic Host and CentOS Linux generic cloud images. We would, ofcourse, like to see wider adoption and are interfacing with other projects and image builders to see how best we might collaborate on this moving forward.


Getting Involved
You can find the source code for the tool here.

For more details please check this blog post


In the meanwhile if you’d like to share your opinions, learn more,
or contribute please feel free to open an issue, mail to centos-devel,user-list or come to #centos-devel IRC channel to have a chat.


  • E-mail: contact _ tmrts.com
  • IRC: tmrts


Tamer Tas


July 08, 2015

Continuous Integration (CI) Pre Release Testing for CentOS Linux Updates

July 08, 2015 03:46 PM

The CentOS Project has been performing daily CI testing for quite a while using our t_functional test suite.

This testing has solved numerous issues for us in the past, although since it was being run daily sometimes we needed to re-release problem packages after fixes were rolled in. We have gotten the run time down considerably now (less than 1 hour for all tests) so we have adopted the policy that we will be running this test suite now as a Pre-Release process for updates so that if there are problems, we can address them before release.

The t_functional suite lives on github and we would be happy for people to help us develop new tests or make the current tests better.  You can download and run the tests on a VM or machine that you can afford to reinstall (the tests are destructive and the machine is left in a state that is different than when the tests start, so it should never be run on production/important machines).  You can also submit new tests or updates via github. We use the CentOS-Devel mailing list for discussion of these tests and for requesting changes.

Please help the CentOS Project make CentOS Linux better by testing, designing and submitting to our t_functional suite.

July 07, 2015

CentOS Meetup in Pune, India – Sat Jul 11th 2015

July 07, 2015 11:43 AM


Humble and the guys in the CentOS-India group are organising a meetup in Pune this Saturday, the 11th July 2015. http://www.meetup.com/CentOS-India/events/219329900/ is a link to the meetup page. The Agenda looks great :

  • Basics of Systemd: Praveen Kumar
  • UEFI and secure boot: Yogesh Babar
  • Docker container and Atomic Host: Ranjith Rajaram
  • Debugging Kernel Issues: Gopal Tiwari

The Event kicks off at 9am with a welcome and intro. So if you are in the area and able to make it, sign up for the event and come along. If you are based in India, it would be great to see you sign up to the CentOS-India group anyway, so you can keep an eye on events coming to your areas, and if possible- maybe even help us run an event in your area!


– KB

July 02, 2015

CentOS Shirt Fridays

July 02, 2015 11:53 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:


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:


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:


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:


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:


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.


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:


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


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
name=CentOS-$releasever – Updates

You would add in this option:


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.


Powered by Planet!
Last updated: October 04, 2015 03:00 PM