Enable network namespaces in CentOS 6.4

By default, CentOS 6.4 does not support network namespaces. If one wants to test the new virtualization platforms (Docker, OpenStack, & co…) on a CentOS server, all features won’t be available.
For OpenStack for example, Neutron won’t work as expected, since it actually needs network namespace to create networks,

Fortunately, RedHat – through RDO – provides a kernel that get this feature backported.

So, before updating the kernel, if one runs :

#> ip netns list

s/he will be presented with the following error message : Object “netns” is unknown, try “ip help”.

The following steps needs to be realized to install the new kernel and enable the network namespace feature

#> yum install -y http://rdo.fedorapeople.org/rdo-release.rpm
#> yum install kernel iproute
#> reboot

And that’s it. Really.

Now one can run

#> ip netns add spredzy
#> ip netns list

spredzy should get displayed.

If everything is working one should have the following kernel and iproute packages installed :


Note : the openstack mention for kernel and netns for iproute


The Foreman PXE provisioning with Libvirt

More than just a Puppet management interface The Foreman can handle the whole lifecycle of servers, from their creations and provisioning (pxe + kickstart/preseed) to their management (puppet). Today’s blog post will highlight how to use the provisioning feature of The Foreman using Libvirt DHCP server (dnsmasq) for local testing purpose.

Pre Requisite

  • An instance of a VM running foreman on libvirt, for this post version 1.3.0 of The Foreman is used, and CentOS 6.4 will be deployed.

Create the Operating System (The Foreman)

The Operating System

In the first time, simply fill the four first field and click submit. We will get back to it at a later point.

Path : More -> Provisioning -> Operating Systems -> New Operating System

Edit OS

Edit OS

The Architecture

Add an architecture one will be supporting for a set of OSes

Path : More -> Provisioning -> Architectures -> New Architecture

Edit Architecture

Edit Architecture

The Installation Media

For our case, the CentOS installation media already exist, one still have to click on CentOS and specify RedHat as Operating System family.

If you have a local mirror of CentOS repositories you could simply make the path points to it, installation will be much faster.

Path : More -> Provisioning -> Installation Media

Edit Installation Media

Edit Installation Media

The Partion Table

A RedHat default partition tables is already present, for the purpose of the demo we will be using it but you might want to create your own one. Do not forget to specify the Operating System Family.

Path : More -> Provisioning -> Partition Tables

Edit Partition Tables

Edit Partition Tables

The Templates

The provisiong template section is where one defines its kickstart/preseed, PXE, gPXE, etc… scripts.

One can define snippets that can be embedded within scripts.

For the demo purpose we will be using two pre-existing scripts

  • Kickstart Default PXELinux (PXELinux)
  • Kickstart Default (provision)

Once one clicks on the Template, one needs to go the the Association tab on the presented page to associate it with the proper OS. Here it needs to be done twice for the Kickstart Default PXELinux and for the Kickstart Default scripts.

Path : More -> Provisioning -> The Provisioning  Templates

Edit Provisioning Template

Edit Provisioning Template

The Operating System

And back to the Operating System to bind it all together.

Path : More -> Provisioning -> Operating Systems -> CentOS 6.4

First you should be presented with the following page, pick the right options (Architecture, Partition Tables, Installation Media) for your OS

Edit OS - OS

Edit OS – OS

Now go to template and associate the template accordingly

Edit OS - Templates

Edit OS – Templates

You can now save the OS.

Create the domain (The Foreman)

Here nothing fancy, simply fill up what is prompted. In the current scenario we don’t use The Foreman as a DNS.

Path : More -> Provisioning -> Domains -> New Domain

Edit Domain

Edit Domain

Create the Subnet (The Foreman)

Here the Network Address is the one from your libvirt’s dnsmasq configuration. Normally you can guess if from a simple ifconfig eth0, else on the host run virsh net-dumpxml default, assuming you run the default network. Same thing applies for the Network Mask.

Select the appropriate domain (cf. Create The Domain) and then the most important make sure the smart proxy name is selected in the TFTP Proxy box.

Path : More -> Provisioning -> Subnets -> New Subnet

Edit Subnet

Edit Subnet

Create the VM with PXE boot (Libvirt)

Create the New VM with a PXE boot

node1 - PXE

node1 – PXE

For now you can stop the VM since the DHCP server is not configured. Please note the MAC address of the Virtual Machine, it will be needed on the later section

Configure dnsmasq for IP attribution and PXE boot (Libvirt)

Note your foreman VM and your node1 VM MAC addresses.

Stop your foreman VM now.

1. Destroy the network

virsh net-destroy default

2. Edit the current network to assign static ip

virsh net-edit default


<ip address='' netmask=''>
    <range start='' end='' />


<ip address='' netmask=''>
    <range start='' end='' />
    <host mac='52:54:00:CB:C3:C6' name='foreman' ip='' />
    <host mac='52:54:00:89:2A:7E' name='node1' ip='' />
    <bootp file='pxelinux.0' server='' />

3. Restart the network

virsh net-start default

What is being done here at step 2,  is a static assignement of IP addresses by the DHCP server and the configuration of the PXE boot.

Static Assignement of IP address

<host mac='52:54:00:CB:C3:C6' name='foreman' ip='' />

Here we tell dnsmasq that device with MAC address ’52:54:00:CB:C3:C6′ will always be assigned ip ‘’

PXE Boot Configuration

<bootp file='pxelinux.0' server='' />

He we tell devices that wish to do PXE boot, to get the file pxelinux.0 on the tftp server running on

You can now start the foreman VM, not node1 yet.

Create the Host (The Foreman)

Here fill up the information as needed, the specifics to PXE provisioning are the Network and Operating System tabs.

  • In the Network tab, fill up the MAC address, the configured domain, subnet and the IP Address assigned in DHCP server.
  • In the Operating System tab, select the Operating System you want your VM to be. (cf. Configure the Operating System)

Path : Hosts -> New Host

Edit Network Host

Edit Network Host

Edit Operating System Host

Edit Operating Syste

Start the VM (Libvirt)

Simply start the node1 VM, it will be assigned the static IP address  and will retrieve the pxelinux.0 from the foreman server as specified in the DHCP server. It might take some time while the installation is processing.

Once the VM automatically rebooted, one needs to go to the foreman > hosts page and will see that the node1 is in a ‘No Changes’ state, meaning build was successful, puppet connected. The VM is now fully managed by The Foreman.


One can configure as many OSes as one wants with fully configurable kickstart/preseed scripts, themselves dynamically parametrizable. As of today, The Foreman is a solid solution to manage the whole lifcycle of servers, from creation to provisioning to management, providing the user with details – filtrable – reports of what is going on. On a personal note I would say that if you are managing puppet servers and you are not using The Foreman, you are doing it wrong. QED.


Samba standalone + OpenLDAP

On the web there are many tutorials about setting a Samba server as one’s Domain Controller (DC), but really a few about setting a Standalone Samba server relying on an external OpenLDAP for authentication. Actually quite a simple process, it needs a lot of configuration on both ends, the Samba server and the OpenLDAP one, before it can be functionnal.

This post shows how to set up a Samba 3.6 server to rely on an external OpenLDAP 2.4 server, both being hosted on a CentOS 6.4

The Samba Server

Authorize the use of LDAP system-wide

In order for the Samba server to be able to rely on then OpenLDAP one, the use of LDAP needs to be enabled system-wide. To do so the authconfig configuration needs to be updated the following way

authconfig --enableldap --update

This simply edits the /etc/nsswitch.conf file and append ldap on passwd, shadow, group, netgroup and automount items

Install the samba packages

Simply run

yum install samba samba-common

Note : This article is about Samba 3.6 version and not Samba4. So do install the samba* packages and not the samba4* packages.

Copy and install the Samba schema in the OpenLDAP server

Note : Since those steps need to be done before the smb.conf configuration, this section shows here, even if logically it belongs to “The OpenLDAP server”

By default, the OpenLDAP server doesn’t speak the Samba language. One needs to add samba LDAP schema to it. From the Samba server, once the samba packages installed simply copy the samba.ldif file located at /usr/share/doc/samba-3.6.9/LDAP/samba.ldif to your OpenLDAP cn=schema directory

scp /usr/share/doc/samba-3.6.9/LDAP/samba.ldif user@openldap:/etc/openldap/slapd.d/cn=config/cn=schema

On the OpenLDAP server, the file needs to be renamed with the pattern – cn={X}samba.ldif – where X represents the highest number available + 1. On a default OpenLDAP installation, the highest number available is 11 (cn={11}collective.ldif) thus, the samba.ldif file needs to be renamed cn={12}samba.ldif

Edit the cn={12}samba.ldif file at line 1 and 3 so it look like this

dn: cn={12}samba.ldif
objectClass: olcSchemaConfig
cn: cn={12}samba.ldif

Finally, restart the slapd service so the new schema can be loaded correctly.

The smb.conf

In Samba there are 3 backends storage available per default.

  • smbpasswd – it is deprecated,
  • tdbsam – the one enabled by default.  It relies on a local database of user, filled via the smbpasswd -a command
  • ldapsam –  It relies on an external LDAP directory

To make your standalone Samba server rely on OpenLDAP simply change this chunk of code

security = user
passdb backend = tdbuser


security = user
passdb backend = ldapsam:ldap://ldap.serv.er.ip/
ldap suffix = dc=wordpress,dc=com
ldap admin dn = cn=admin,dc=wordpress,dc=com
  • ldap suffix : the suffix of your DIT
  • ldap admin dn : This is optional. If the OpenLDAP server denies anonymous request, then one needs to specify an admin dn entry.  Also if your LDAP tree do not have a SambaDomain entry yet, specifying the ldap admin dn configuration will create it automatically.  If using ldap admin dn, one needs to specify the admin dn password running smbpasswd -W

Save and exit the file, then restart the smb service. After few second one can run net getlocalsid and will be presented with a line looking like

SID for domain SAMBA-SERVER is: S-1-5-21-2844801791-3392433664-1093953107

If you set ldap admin dn in the smb.conf, the SambaDomain was created automatically and net getlocalsid returns this value, if you setted it manually net getlocalsid should return your your SambaDomain informations

Set samba to start automatically at boot time – chkconfig samba on – and the Samba server is all set to receive request from LDAP existing users.

The OpenLDAP server

In order for an OpenLDAP server to be Samba aware, some attributes needs to be added to the appropriate entryies. Make sure the samba schema has been loaded into OpenLDAP, as explained earlier.


This entry can be automatically created  by the Samba server – if one wants  – and contains general informations about the Samba behavior. The most important information that can be found here is the SID, Security IDentifier for the domain. It will be needed for the configuration of Samba Groups and Users entries.


This is an auxiliary objectClass  that should be added to all the posixGroup entry that one wants to work with in Samba. It has only  two mandatory attributes, the SambaSID that is a uniqe ID within the SambaDomain ans the SambaGroupType, that define the type or the group.

The SambaSID is composed of the SID + RID

  • SID : From the SambaDomain entry
  • RID : Relative IDentifier, a unique id within the SambaDomain

The defined SambaGroupType are :

  • 2: Domain Group
  • 4: Local Group (alias)
  • 5: Builtin


This is probably the most touchy, yet scriptable part. This is the auxiliary objectClass that should be added to all the posixAccount entry that one wants to work with in Samba. It contains Samba credentials. For Samba to authenticate a LDAP hosted user, the latter needs to have the the following attributes set

  • SambaAcctFlag : define user type (permissions)
  • SambaLMPassword : The LanMan password
  • SambaNTPassword : The NT password
  • SambaPwdLastSet : Timestamp of the last password update
  • SambaSID : The unique identifier within the SambaDomain

To obtain those informations , one can run this script , this needs the perl module Crypt-SmbHash to be installed

Usage : ./script username password

This will give the following outputs

:0:47F9DBCCD37D6B40AAD3B435B51404EE:82E6D500C194BA5B9716495691FB7DD6:[U          ]:LCT-4C18B9FC

  |            LMPassword          |         NTPassword             |   AcctFlags |

For the SambaSID value, refere to the SambaGroupMapping section the same logic apply here.

Once the SambaDomain, SambaGroupMapping and SambaSamAccount applied where it has to, the Samba server is ready to authenticate against the OpenLDAP server


Making a standalone Samba server rely on an external OpenLDAP , is not a difficult process, but it does involve quite a lot of configuration. In this article, neither the IPtables or the SElinux side of things has been adressed, but you should definetly set them up accordingly.  Go ahead add people on your DIT and see how they can access their own Samba Share. QED