Testing Ansible roles for CentOS on Travis-CI with Docker

Wow that title looks so buzzword-y

Testing your code is always a good thing and ansible-galaxy init(since 2.0) includes a simple test setup using Travis-CI, which is a free service for continuous integration that integrates with GitHub. The problem is their infrastructure is all Ubuntu based, and my recently created role is for CentOS. So how do I test my role in an automated way?

The solution is Travis-CI with Docker. Using a couple different sources online, I pieced together a config that uses the centos images for 6 and 7(not 5 as its too old, using Python 2.4, for ansible) to test my ansible role. And whats nifty is Ansible Galaxy has a webhook that Travis can use to report build status on the role description page.

I also use the env directive to create a build matrix that will launch sub-jobs, in this case the different centos image versions. Take a look at my travis.yml and see for yourself.

Yum Repository Priorities and Ansible

I’ve been investigating setting up a VPN gateway on my home server, but so far my search has only shown implementations that run on Linux or BSD, but not SmartOS/Illumos(Solaris). It’s planted some doubt in my choice in SmartOS as my server’s OS, but so what! I can still run a Linux VM via KVM. I’ve gone with my old standard of CentOS, a very solid OS that I trust to run my eventual VPN gateway securely.

When I get to it, I’ll let you all know how I go about setting up StrongSWAN, but I’m not there yet. I need to first setup some groundwork and that’s installing the EPEL yum repo. I’m very familiar with how to do so manually, adding the repo and then using the priorities plugin, but it’s all about Ansible today. I’ve created an Ansible Galaxy role to install and configure the priorities plugin, go check it out.

davidmnoriega/yum-plugin-priorities

Building exabayes(1.2.1) for Rocks 6.1

To build exabayes(note, this is for version 1.2.1. 1.3 just came out and doesn’t build for me just yet) on Rocks 6.1, which is based on CentOS 6.3, LLVM’s clang and libc++ need to be installed. I have a previous blog post about this.

The available prebuilt binaries do not work on CentOS 6.3, but once clang and libc++ is installed, rebuilding it is fairly straight forward. Download and extract exabayes and go into its directory. Use the following commands to configure and build both the serial and parallel versions of exabayes:

CC=clang CXX=clang++ CXXFLAGS=”-std=c++11 -stdlib=libc++” ./configure
make
OMPI_CC=clang OMPI_CXX=clang++ OMPI_CXXFLAGS=”-std=c++11 -stdlib=libc++” CC=mpicc CXX=mpic++ ./configure –enable-mpi
make clean
OMPI_CC=clang OMPI_CXX=clang++ OMPI_CXXFLAGS=”-std=c++11 -stdlib=libc++” CC=mpicc CXX=mpic++ make

mpicc and mpic++ are just wrappers for gcc, but by using those environment variables, they can be pointed to another compiler without having to build a separate version of openmpi. Now that is done, within the top level directory are all the exabayes binaries. Ignore the ones in bin/bin, those are the prebuilt ones that don’t work.

Building libc++ on CentOS 6

For the cluster I manage, a user needed exabayes(there will be another post on building that later) but their prebuild binaries didn’t work on Rocks 6.1, which is based on CentOS 6.3. GCC is too old to build it as they use C++11, but luckily clang 3.4 is available from EPEL. Only thing, it still wouldn’t compile. I got the following two errors:

/usr/bin/../lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/exception_ptr.h:143:13: error:
unknown type name ‘type_info’
const type_info*
./src/Density.cpp:79:34: error: use of undeclared identifier ‘begin’
double sum = std::accumulate(begin(values), end(values), 0. );

While there was a potential workaround for the first error, nothing viable was to be found for dealing with the second error. But this research pointed in the next direction, building LLVM’s libc++ as these errors have to do with GCC’s old version of the standard c++ library. Its a bit complicated and rather hackish but looks like it works, so here we go.

Download libc++ via svn, but instead of following their directions for building, do this:

cd libcxx/lib
./buildit

Thanks to this blog post, which is in Chinese, but the commands are easy to understand. After building the library, copy it to /usr/lib(or because this is 64bit, I put it in /usr/lib64) and create the needed symlinks. Then copy libcxx/include to /usr/include/c++/v1. Remember this as we’ll be replacing libc++ later with a rebuild version.

Next is building libc++abi. Again download from svn and build it like above and copy the library to /usr/lib64 and make the symlinks. The include directory doesn’t need to be copied. Now time to rebuild libc++ with libc++abi. This requires CMake, and I opted for the newer version available from EPEL. The command is then cmake28. I also started with a fresh download of libc++

cd libcxx
mkdir build
cd build
CC=clang CXX=clang++ cmake28 -G “Unix Makefiles” -DLIBCXX_CXX_ABI=libcxxabi -DLIBCXX_LIBCXXABI_INCLUDE_PATHS=”<libc++abi-source-dir>/include” -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr ../
make

Since I don’t like to mess with the system install, I used DESTDIR during the make install step. This then allows me to build an rpm package using rocks create package. I also create a package for libc++abi.

With this now its possible to compile with clang and c++11. Test it out like so: clang++ -stdlib=libc++ -std=c++11 input.cpp

Setting up LAM Pro with SELinux

Been a while since I had to install LAM Pro and now that I have the new version, I ran into a couple of issues. First there is SELinux, which has saved my butt a couple of times, so I work to always have it enabled. I cringe whenever I see the first step in someone’s howto is to disable it. Its complicated and I do not profess to be anywhere near an expert in it, but I get by. Second is to secure the install, and while SELinux helps in that regard, there are still steps to take.

Installing:

LAM Pro is the paid version of LAM, LDAP Account Manager. Starting with a fresh install of CentOS 6.4, I downloaded the LAM Pro source and use its install script:

# ./configure --with-httpd-user=apache \
              --with-httpd-group=apache \
              --with-web-root=/var/www/html/lam
# make install

By default it will install everything into /usr/local/lam and use httpd as user/group name. Here I fix that to use the CentOS default of apache as user/group. Also it’s recommend to separate the web interface from the more sensitive parts, like the config files and session information.

SELinux Configuration:

If you were to start up a browser to load up LAM, even with SELinux disabled, there is the issue of writing config files. They are stored in /usr/local/lam/etc, where the web server doesn’t have permission. Also there is the session and tmp directory in var it uses to cache data from ldap. So use chmod to fix that:

# chmod -R apache:apache /usr/local/lam/etc
# chmod -R apache:apache /usr/local/lam/var/sess
# chmod -R apache:apache /usr/local/lam/var/tmp

But with SELinux enabled, apache still doesn’t have permissions to write outside of its own root directory. We need to tell the system the right context to use to allow apache access.

# semanage fcontext -a -t httpd_sys_content_t "/usr/local/lam/var(/.*)?"
# semanage fcontext -a -t httpd_sys_content_t "/usr/local/lam/etc(/.*)?"

Next is to apply these settings to the files themselves:

# restorecon -R /usr/local/lam/var
# restorecon -R /usr/local/lam/etc

Now apache can run LAM with SELinux enable and not run into any issues.

Apache Configuration:

The next part is to secure the installation. LAM comes with htaccess files ready to use to protect the config files and other sensitive files. Its my preference and you can do it differently, but I start with creating /etc/httpd/conf.d/lam.conf to hold these directives.

<Directory /var/www/html/lam>
   AllowOverride All
</Directory>

Now you could just change the server wide setting in httpd.conf, but I like to follow the principle of least privilege.

Next would be to set it up to use SSL to keep prying eyes from grabbing your passwords and user information, but that’s a whole other topic.

CentOS: Eclipse and PyDev

I’ve usually just used a simple text editor like nano when writing python here and there, but I do like the visual aspect that a good IDE provides and though I’d give Eclipse + PyDev a try. Used yum to install eclipse and then added PyDev’s repo to eclipse to only then run into a problem when I tried to install PyDev. I got this long list of  “No repository found containing” messages. Searching the issue I did not find any useful answers as they were the usual, “Just start fresh,” or, “Don’t use the distribution version, always download from the web site,” kind of messages. Not helpful at all.

Luckily I found the following bug post and discovered the issue was with a missing package. Not really sure why it isn’t just installed be default but what is needed is the eclipse-pde package. That’s plugin development environment that is apparently needed to install other plugins, like PyDev. Once that was installed, I got PyDev installed and now I’m ready to go forth.

CentOS 6.4: NSS, MD5 Certificates, and Authentication Problems: UPDATE

In tinkering with setting up a kickstart script to get a basic workstation installed just like I want I decided to revisit the authentication issue related to certificates with an MD5 signature. Thankfully there is a workaround to enable MD5 support in the nss package that worked for me. Simply add ‘export NSS_HASH_ALG_SUPPORT=+MD5’ to /etc/sysconfig/init and reboot. Thanks go to @NewLifeMark and this blog posting.

CentOS 6.4: NSS, MD5 Certificates, and Authentication Problems

CentOS just released 6.4, so I decided to update the office server and as it was the end of the day, left it at that. Bad form on my end as I come in the next day to find I’m unable to connect to the samba server. Checking the logs I see samba is unable to connect to LDAP via TLS. I also quickly discover that the server itself is unable to get user information. First guess was to check the ldap server, but its running fine.

Second guess is to try ldapsearch from the office server and I get my first hint. Ldapsearch was not accepting my Certificate Authority and was giving a bad signature algorithm error. Researching that lead me to the following bug report: Unable to authenticate to legacy LDAP server due to “not secure” certificate signature.

It becomes clear that due to the decision at Mozilla, who develop the NSS(Network Security Services) library to stop accepting MD5 hashes is the root issue. I then set out to downgrade NSS to pre 6.4 release. The following packages were the ones I downgraded to get my system working again: nss nss-sysinit nss-tools nss-util nss-pam-ldapd mod_nss.

Now some may ask why not just upgrade your certificates to a newer and thus more secure signing algorithm? Well to anyone who has ever worked with OpenSSL and creating certs for a multitude of servers, its not a trivial task. I’ll put it on my todo list, but for now its at the bottom.

Thanks to following blog post by Matt Micene that was the break in this case.

Moving from DKMS Nvidia to latest driver

The dkms version of the Nvidia driver is a great convenience, yet it usually means you wont have the latest version and when the kernel updates, that can be a problem. Like Today.

Running CentOS 6 on our workstations and decided time to update packages and I hoped dkms wouldn’t let me down, but it did. So boot into run level 3 and remove dkms and the dkms nvidia driver to make way for the latest version. Its normally a straight forward process, yet Nvidia can mess up the xorg installation, like it did for me. Some how libwfb.so was missing, so the Nvidia driver will install its own version.

This doesn’t work as you’ll get a message about unknown symbol PictureScreenPrivateIndex. Turns out for some installations that don’t have libwfb, Nvidia brings its own, yet since I’m supposed to have it, this led to trouble. The quick fix is to reinstall the right package. Use yum whatprovides */libwfb.so to find that xorg-x11-server-Xorg is the correct package and yum reinstall restores libwfb. Install the Nvidia driver via the script as usual and you should be good to go.