Arrfab's blog Some tips and tricks, mostly around CentOS

Just to let you know that I have verified some mirrors last week and sent several mails to the contact info we had for those mirrors (unreachable/far behind).
I've received feedback from some people still willing to be listed as third-party mirror and so they fixed the issue they had (thank you !)

Some other people replied with a "sorry, we can't host a mirror anymore" answer . (Thanks for having replied my email and thank you for having been part of the successful "centos mirror party" !).

For the "unanswered" ones, I've decided that it was time to launch a "Spring clean-up operation" in the mirrors DB/Network.
I've removed them from the DB, meaning that the crawler process we use to detect bad/unreachable mirrors will not even try anymore to verify them.
We actually have more than 500 external (third-party) mirrors serving CentOS to the whole world, without counting the 50+ (managed by CentOS) servers used to feed those external mirrors, and sometimes serving content too for countries less covered.

Thanks a lot for your collaboration and support ! We love you :-)

Comme vous le savez peut-être (ou pas !), nous tiendrons un Dojo CentOS à Lyon le vendredi 11 avril. Si donc vous avez envie de partager votre expérience autour de CentOS, en donnant une présentation par exemple, ou bien si vous désirez seulement venir passer un bon moment avec nous en écoutant les présentations prévues (appel - subliminal - aux candidats volontaires !), sentez-vous libre de vous inscrire.
L'inscription est gratuite ! Plus d'informations sur la page Wiki : http://wiki.centos.org/Events/Dojo/Lyon2014 .

Hi people, are you in the Lyon (France) area around April 11th ? Willing

to come to a CentOS Dojo ? (either to attend it or even better, present

something around CentOS ?) . Feel free to register for this free event !

http://wiki.centos.org/Events/Dojo/Lyon2014

So, everybody now knows the whole story, and so visited the new CentOS website. It's always a good time to keep an eye on statistics and we also added now native IPv6 support ! (Finally ! , we live in 2014, right ? ). And because we "love" stats, here they are (for IPv4 vs IPv6) :

IPv4 traffic for the new website :

IPv6 traffic for the new website :

So clearly not so much IPv6 traffic vs IPv4 one.Join the IPv6 movement !

Recently I had to dive back into Ansible playbooks I wrote (quite) some time ago. I had to add some logic to generate different application templates based on facts/packages being installed on the managed nodes. Long story short (I'll not describe the use case here as it's quite complex), I decided that injecting directly some kind of logic in the Jinja2 templates was enough .. but not.

Let's take a very simplified example here (don't even look at the tasks but rather at the logic explained how to get there, once again this is a 'stupid' playbook) :

---  
- hosts: localhost  
  connection: local  
  user: root  
  vars:  
    - myrole: httpserver

  tasks:  
    - name: registering a variable only if myrole is httpserver  
      command: /bin/rpm -q --qf '%{version}' httpd  
      register: httpd_version  
      when: myrole == 'httpserver'  
    - name: pushing the generated template  
      template: src=../templates/logic.txt.j2 dest=/tmp/logic.txt

 handlers:

Now let's have a look at the (very) simple logic.txt.j2 :

{% if httpd_version is defined -%}  
 You're using an Apache http server version : {{ httpd_version.stdout> }}  
{% else %}  
  You're not using an http server, or not defined in the ansible> machine role  
{% endif -%}

Easy, and it seems it was working when myrole was indeed httpserver :

 cat …

It's not a secret anymore that I use Ansible to do a lot of things. That goes from simple "one shot" actions with ansible on multiple nodes to "configuration management and deployment tasks" with ansible-playbook. One of the thing I also really like with Ansible is the fact that it's also a great orchestration tool.

For example, in some WSOA flows you can have a bunch of servers behind load balancer nodes. When you want to put a backend node/web server node in maintenance mode (to change configuration/update package/update app/whatever), you just "remove" that node from the production flow, do what you need to do, verify it's up again and put that node back in production. The principle of "rolling updates" is then interesting as you still have 24/7 flows in production.

But what if you're not in charge of the whole infrastructure ? AKA for example you're in charge of some servers, but not the load balancers in front of your infrastructure. Let's consider the following situation, and how we'll use ansible to still disable/enable a backend server behind Apache reverse proxies.

So here is the (simplified) situation : two Apache reverse proxies (using the …

Those days, almost everyone uses a laptop as his primary (work)station : I don't remember when I was using something else than a laptop for both work and home usage. I admit that I'm using what I'll describe in the following sentences for quite some time, but it seems some people I spoke to don't know what can be done around NetworkManager, and because I encountered a (small) issue with that process (because of updated selinux policies), I thought it would be a good time to speak about it.

Let me first discuss a (little) bit about NetworkManager : almost everyone (using CentOS/Fedora or other distributions) knows what it's all about : helping you to quickly switch from one network to another, that network being a wired one, a Wifi hotpot, or even a 3G connection through your 3G usb modem or your smartphone being used as a modem, etc, etc .... That's the "visible" part of NetworkManager.  While some people don't seem to like it, I admit myself that I really appreciate it and I use it on a daily basis for \$work and \$home usage (switching from wired to wireless, and so on). A quick read in the NetworkManager man …

You've probably read thatAnsibleuses by default paramikofor the SSH connections to the host(s) you want to manage. But since 0.5 (quite some ago now ...) Ansible can use plain openssh binary as a transport. Why ? simple reasons : you sometimes have complex scenario and you can for example declare a ProxyCommandin your \~/.ssh/config if you need to use a JumpHost to reach the real host you want to connect to. That's fine and I was using that for some of the hosts i have to managed (specifying -c ssh when calling ansible, but having switched to a bash alias containing that string and also -i /path/to/my/inventory for those hosts).

It's great but it can lead to strange results if you don't have a full look at what's happening in the background. Here is the situation I just had yesterday : one of the remote hosts is reachable, but not a standard port (aka tcp/22) so an entry in my \~/.ssh/config was containing both HostName (for the known FQDN of the host I had to point to, not the host i wanted to reach) and Port.

Host myremotehost
HostName my.public.name …

I already know that i'll be criticized for this post, but i don't care :-) . Strangely my last blog post (which is *very* old ...) was about a puppet dashboard, so why speaking about another tool ? Well, first i got a new job and some prerequisites have changed. I still like puppet (and I'd even want to be able to use puppet but that's another story ...) but I was faced to some constraints when being in front of a new project. For that specific project,  I had to configure a bunch of new Virtual Machines (RHEL6) coming as OVF files. Problem number one was that I can't alter or modify the base image so i can't push packages (from the distro or third-party repositories). Second issue is that I can't install nor have a daemon/agent running on those machines. I had a look at the different config tools available but they all require either a daemon to be started, or at least having extra packages to be installed on each managed node. (so not possible to have puppetd nor puppetrun or invoke puppet directly through ssh , as puppet can't even be installed, same for saltstack). That's why i decided to give …

We implemented Puppet as a configuration management system at \$work ,  and Puppet is a great tool. Then I heard about some dashboards that could be used on top of it. I've heard about different dashboards (\$management_people *like* dashboards) like Puppet-dashboard and Foreman.

I was advised by several people to give Foreman a try and it's really simple to install. Their wiki covers basic installation and there is even ayum repo that can be used (Epel has to be enabled too). As i have a small network to manage, I decided to setup Foreman on the same host as puppetmaster. Configuring /etc/foreman/* is easy and missing parts can be configured just by looking at the Foreman website wiki/FAQ. But troubles came when I enabled reports : puppetmasterd config was changed to include :

[master]
reports = store, foreman

and the foreman.rb script (copied and modified from /usr/share/foreman/extras/puppet/foreman/templates/foreman-report.rb.erb) integrated in the correct /usr/lib/ruby/site_ruby/1.8/puppet/reports dir. (Note : don't forget to update \$foreman_url).

But no reports were coming in Foreman. hmmm .... error message was :

Report foreman failed: Could not send report to Foreman at http://puppetmaster.mybeautifuldomain.com …

While Johnny was explaining to the rest of the world how CentOS 6.1 and 6.2 were released, I received quite some questions about the QA tests and how they were performed. Well, let me explain in some words how it's now organized. Previously, there was only a Tests Matrix that was shared between the QA team members : each member of that group had access to the QA bits, could download/rsync the complete tree (with ISO images too) and do his tests, and then reported the results in one way or the other (irc, mailing-list). Of course it didn't scale out very well. Too much manual intervention, and when someone was busy with personal (or work related) issues, no feedback was coming back to the CentOS devteam.

So during Fosdem 2011, I had a meeting with Karanbir to see how we could solve that issue and put automation in the QA loop. We dedicated some (old) machines to be used only for QA, and in a separate VLAN. Basically, here are the steps from the built bits to the QA reports.

• The CentOS buildfarm (using the newly build system called 'reimzul' and using beanstalkd as a queuing system …