Distributed File Systems (DFS) are used to easily access multiple CIFS file shares, hosted on separate servers, using a single namespace on your network. The actual shares can either be hosted locally on the DFS server itself or on separate servers.

The benefit of using a single namespace for your users to access your shares is they don’t have to remember the names of each of your file servers; all shares can be accessed through one root name, regardless of where the actual file server resides. The access request will be redirected to the appropriate servers, all without the users’ knowledge.

Another benefit to using DFS, and it’s a major one, is the ability to migrate shared data from one storage platform or server to another, transparently and quickly without your users ever knowing. You simply redirect a DFS hosted share to a new CIFS share, without ever having to change the share’s name.

With standard cifs file servers, you either need to send your users to a new share path after migration or suffer downtime while flipping between the new and old file server hardware, suffering a possible lengthy outage – depending on the complexity of your shares and their permissions.

Before you Begin

This lab will be based on the following configuration.

• One server running CentOS 6.X.
• An Internet connection to access the the CentOS package repository.

Installing and Configuring Samba

1. Install Samba.

   yum install samba

2. Open Samba’s configuration file into a text editor, like VIM or Gedit.

   vi /etc/samba/smb.conf

3. Under the [global] settings, define the following options, modifying the highlighted values to match your environment.
   [global]
    workgroup = WORKGROUP
    netbios = MY-DFS-SERVER
    host msdfs = yes

   Understanding the options we are defining:

   workgroup	The name of your Windows peer-to-peer network. Microsoft’s default is WORKGROUP.
   netbios	This is the single-label computer name used by a Windows on a network. Set this to the name you want your Samba server to have on the network.
   host msdfs	The required parameter which tells Samba to act as a DFS host.

Set Samba Permissions for Selinux

Selinux on CentOS will block connections to Samba shares by default. We’ll need to lift this restriction to allow users to access our DFS and to grant them read/write permissions.

1. Allow read and write permission to our samba shares:

   setsebool samba_export_all_rw yes

Create the DFS Root Directory

The DFS root directory is where you create your DFS targets – links to other CIFS shares. Targets are created by creating symbolic links to your other cifs shares, using the msdfs protocol. The shares can exist on any server. To keep things simple for this lab, we’ll create a cifs share on the DFS Root which we will create a target for.

1. Create the directory that will host the CIFS targets:

   mkdir -p /export/dfsroot

2. Make sure the DFS root directory is owned by Root.

   chown root:root /export/dfsroot

3. Secure the DFS root to protect the DFS targets from changes by unauthorized users:
   chmod 755 /export/dfsroot

Create a Share to the DFS Root Directory

Next we’ll need to share the DFS root directory to allow our users to access our DFS targets from a single name-space. To do this, we’ll need to open up Samba’s configuration file and add a new share.

1. Open Samba’s configuration file in text editor, like VIM:

   vi /etc/samba/smb.conf

2. Near the bottom of the configuration file, create a Samba share to the DFS root by adding these lines to the bottom of the file, replacing the highlight lines to match your environment:
   [dfs]
    comment = DFS Root Share
    path = /export/dfsroot
    browsable = yes
    msdfs root = yes
    read only = no

Create a Share to be Used as a DFS Target

The DFS targets are the CIFS shares that a DFS root server will provide access to from a single name-space. These shares can be hosted on the local DFS root server or, ideally, on a separate server. To keep things simple, we’ll create our first share on the DFS root server.

1. Prepare a directory to be shared out

   mkdir -p /export/samba/finance

2. Define the share by opening Samba’s configuration file into a text editor, like VIM:

   vi /etc/samba/smb.conf

3. Near the bottom of the file, configure you share so it looks similar to the following example:
   [finance]
    path = /export/samba/finance
    public = yes
    writable = yes
    browseable = yes

Add DFS Targets

Finally, it’s time to add some targets to our DFS server. The CIFS shares that we target can be on any host, Linux or Windows. To keep things simple in this tutorial, we’ll create a share on the local DFS host that we’ll use as a DFS target.

1. Create a symbolic link to your DFS target.

   link -s msdfs:my-dfs-server\finance /export/dfsroot/finance

   Warning: The symbolic link file for the msdfs share must be lowercase. If it is not, you will get errors when trying to connect to the share.
2. Restart the Samba’s daemon to apply our changes

   service smb restart

Overview

Bonding is the ability to take two or more network interfaces and present them as one to a client. Depending on the method you use, the bond can create different types of connections. You can, for example, create an aggregate channel to double or even triple your total bandwidth; create a fault tolerant connections to improve server reliability; or load balance connections to handle more requests and to improve response times.

Some of the more advanced bonding methods, like channel aggregation, require switches that support IEEE 802.3ad dynamic link aggregation policy. However, simple load balancing and fault tolerance can be done without.

Server Configuration

To make it easier for you to follow along, the following configuration will be used in this tutorial.

It’s important that you record the MAC address (hardware address) of every interface. Although not required, it is best practice to assign a MAC address to each bond slave. Without doing so, you cannot confidently unplug an interface and know which slave will be offline, potentially causing a service outage.

Prepare the Interfaces

Before we configure the type of bond we’ll be using, we need to prepare the interfaces first. This envolves creating the bond0 configuration file, and then modifying the existing configurations files for each of your physical network interfaces. In this lab, there are only two.

The steps for configuring the different bond types can be found after this section. Choose one and then follow the instructions.

Create the Bonded Interface

This is the interface your clients will be connecting to.

1. Create the configuration file for the first bond, bond0.

   touch /etc/sysconfig/network-scripts/ifcfg-bond0

2. Open the file in a text editor.

   nano /etc/sysconfig/network-scripts/ifcfg-bond0

3. Add the following lines to the file.
   DEVICE=bond0
    IPADDR=172.30.0.34
    NETMASK=255.255.255.0
    GATEWAY=172.30.0.1
    ONBOOT=yes
    BOOTPROTO=none
    USERCTL=no
4. Save your changes and exit the text editor.

Configure Slave 1

1. Open the configuration file for the first interface, eth0, into a text editor.

   nano /etc/sysconfig/network-scripts/ifcfg-eth0

2. Modify the configuration file to look like the following, replacing the highlighted parts to match your environment.
   DEVICE=eth0
    ONBOOT=yes
    BOOTPROTO=none
    HWADDR=00:1F:29:E6:EB:2A
    USERCTL=no
    MASTER=bond0
    SLAVE=yes

Configure Slave 2

1. Open the configuration file for the second interface, eth1, into a text editor.

   nano /etc/sysconfig/network-scripts/ifcfg-eth1

2. Modify the configuration file to look like the following, replacing the highlighted parts to match your environment.
   DEVICE=eth1
    ONBOOT=yes
    BOOTPROTO=none
    HWADDR=00:26:55:35:24:FE
    USERCTL=no
    MASTER=bond0
    SLAVE=yes

Configure a Fault Tolerant Bond

Also called an Active-Passive connection, this bond type will protect you from a failed physical network interface and, depending on your Ethernet configuration, a failure on your physical network.

1. If it doesn’t already exist, create a new file called bonding.conf in /etc/modprobe.d

   touch /etc/modprobe.d/bonding.conf

2. Open the file in a text editor.

   nano /etc/modprobe.d/bonding.conf

3. Add the following lines to the file.
   alias bond0 bonding
    options bond0 miimon=80 mode=1

   TABLE2 – Bonding.conf options

   bond0	Name of the bonded interface being created.
   miimon	Defines how often, in milli-seconds, the interface is checked to see if it is still active.
   mode	Type of bond being created.

4. Save your changes and exit the text editor.

Create Round-Robin Bond

Robin-Robin load balancing splits the connections between the two slaves evenly. The incoming connections alternate between the active slaves, taking the load off of each other, to improve request time.

1. If it doesn’t already exist, create a new file called bonding.conf in /etc/modprobe.d

   touch /etc/modprobe.d/bonding.conf

2. Open the file in a text editor.

   nano /etc/modprobe.d/bonding.conf

3. Add the following lines to the file.
   alias bond0 bonding
    options bond0 miimon=80 mode=0

   TABLE3 – bonding.conf options

   bond0	Name of the bonded interface being created.
   miimon	Defines how often, in milli-seconds, the interface is checked to see if it is still active.
   mode	Type of bond being created.

4. Save your changes and exit the text editor.

Create Aggregate Bond

Network aggregation combines the target network interfaces to create one large network interface. This will multiple the available bandwidth of the server’s network connection by the of NICs installed.

For this bond to work, you need your interfaces to be connected to a switch that supports IEEE 802.3ad dynamic link aggregation policy. Also, the ports have the feature enabled.

1. If it doesn’t already exist, create a new file called bonding.conf in /etc/modprobe.d

   touch /etc/modprobe.d/bonding.conf

2. Open the file in a text editor.

   nano /etc/modprobe.d/bonding.conf

3. Add the following lines to the file.
   alias bond0 bonding
    options bond0 miimon=80 mode=4

   TABLE4 – bonding.conf options

   bond0	Name of the bonded interface being created.
   miimon	Defines how often, in milli-seconds, the interface is checked to see if it is still active.
   mode	Type of bond being created.

4. Save your changes and exit the text editor.

Restart the Network Services

Our bond is created. It’s time to restart the network services to apply our configuration.

1. Restart the sevices

   services network restart

very popular tool for any operational guy’s DevOps utility belt is Puppet – a system configuration management service. It allows you to automate the entire process of system configuration and maintain consistency across groups of servers. Imagine having to deploy 50 servers for a new web farm, with each server requiring the exact same configuration. An especially daunting task when done manually. With Puppet, we simply define a server configuration for the web nodes, including which packages and services are installed and how they themselves are configured. When done we then assign that configuration to those systems.

Another benefit to using a tool like Puppet is the ability to update configurations across your entire infrastructure on the fly. This could mean installation of the latest version of MySQL onto your database servers, or simply modifying DNS configurations for every server in the environment.

Puppet uses a client-server model. By that I mean our configurations are defined and stored on what is called a Puppet master server, and each system that will have its configuration maintained by Puppet has a client  installed. Every 30 mintues, by default, each client communicates with the master server to have its configuration audited. When a discrepancy is discovered between the client’s current configuration and what is defined for it, the appropriate actions are completed to bring the system back into compliance.

This tutorial will guide you through setting up and running a Puppet master server using the open-source version of the software on a CentOS 6 server. Unlike the enterprise version of Puppet, the open-source version requires quite a bit of manual configuration. Nothing overwhelming but definitely not as simple as running a single executable.

Goals

• Deploy a Puppet Master server

Installing Puppet

Disabling SELinux

I am a very strong advocate of always running SELinux on Redhat-based servers. I do not take disabling it lightly and avoid doing so where possible. However, at the time of this writing I was unable to find a satisfactory way of enabling SELinux on a Puppet master server. There are SELinux policies for Puppet that can be found on the Internet. Unfortunately, I cannot recommend using any of them since they are not refined enough to ensure the system is secure.

Outright disabling SELinux is very bad idea. You never know when you’ll be able to re-enable it. And if you do disable it, when it comes time to re-enable SELinx the system will have to relabel every file, directory and port with the appropriate contexts. This a very, very, very time consuming process. Instead, I recommend placing SELinux into Permissive mode. This way SELinux doens’t block Puppet process and communications, and our files, directories, and ports all keep their contexts.

1. Immediately place SELinux into permissive mode.

   setenforce 0

2. The command above is not persistent. It will be undone during the next reboot. To make the change persistent, open the SELinux configuration file into a text editor.

   nano /etc/sysconfig/selinux

3. Change the SELINUX value from enforcing to permissive, as seen in the example below.
    # This file controls the state of SELinux on the system.
    # SELINUX= can take one of these three values:
    # enforcing – SELinux security policy is enforced.
    # permissive – SELinux prints warnings instead of enforcing.
    # disabled – No SELinux policy is loaded.
    SELINUX=permissive
    # SELINUXTYPE= can take one of these two values:
    # targeted – Targeted processes are protected,
    # mls – Multi Level Security protection.
    SELINUXTYPE=targeted
4. Save your changes and exit the text editor.

Install the Puppet Repo

The easiest way to install Puppet is by adding the Puppet Labs repository file to your server. We can install it by using the freely available RPM provided by Puppet Labs.

1. Download and install the PuppetLabs’ repository RPM. At the time of this writing, version 6.7 was available.

   rpm -ivh http://yum.puppetlabs.com/el/6/products/i386/puppetlabs-release-6-7.noarch.rpm

2. If all was successful, you should now have a filled called puppetlabs.repo located in /etc/yum.repos.d/.

   -rw-r--r--. 1 root root 1926 Nov 27  2013 CentOS-Base.repo
   -rw-r--r--. 1 root root  638 Nov 27  2013 CentOS-Debuginfo.repo
   -rw-r--r--. 1 root root  630 Nov 27  2013 CentOS-Media.repo
   -rw-r--r--. 1 root root 3664 Nov 27  2013 CentOS-Vault.repo
   -rw-r--r--. 1 root root 1250 Apr 12  2013 puppetlabs.repo
   

Install the Puppet Master

The Puppet Master is where your nodes get their configuration profiles from.

1. Install the Puppet Master package from the Puppetlabs repository.

   yum install -y puppet-server

2. Start the Puppet Master service.

   service puppetmaster start

3. Ensure the Puppet master starts at boot.

   puppet resource service puppetmaster ensure=running enable=true

Install a Web Server for Puppet Agent Access

Each server being managed by Puppet will have an agent installed. By default, the agent will attempt to connect to a Puppet master server using a HTTPS connection. We need to ensure a web server is available on the master server to allow us to service our clients. You can us any web server, but we’ll be using Apache in this tutorial.

1. Install the web server and some other required packages, like Ruby.

   yum install -y httpd httpd-devel mod_ssl ruby-devel rubygems openssl-devel gcc-c++ curl-devel zlib-devel make automake

2. The web service requires Passenger to process the Ruby files used by Puppet. We install it using Ruby’s gems.

   gem install rack passenger

3. With the Passenger, we need to install and configure its Apache module.

   passenger-install-apache2-module

Prepare Puppet’s Apache directory

1. Create a directory.

   mkdir -p /usr/share/puppet/rack/puppetmasterd

2. Create the document root directory

   mkdir /usr/share/puppet/rack/puppetmasterd/public  /usr/share/puppet/rack/puppetmasterd/tmp

3. Copy the Rack config template to our Apache virtual host’s directory root.

   cp /usr/share/puppet/ext/rack/files/config.ru  /usr/share/puppet/rack/puppetmasterd/

4. Apply the appropriate permissions to the configuration file.

   chown puppet /usr/share/puppet/rack/puppetmasterd/config.ru

Create the Apache Virtual Host for Puppet

1. Create a configuration file for the Apache virtual host.

   touch /etc/httpd/conf.d/puppetlabs.conf

2. Edit the file and add the following contents.
   # And the passenger performance tuning settings:
    PassengerHighPerformance On
    #PassengerUseGlobalQueue On
    # Set this to about 1.5 times the number of CPU cores in your master:
    PassengerMaxPoolSize 6
    # Recycle master processes after they service 1000 requests
    PassengerMaxRequests 1000
    # Stop processes if they sit idle for 10 minutes
    PassengerPoolIdleTime 600
    Listen 8140
    <VirtualHost *:8140>
     SSLEngine On
     # Only allow high security cryptography. Alter if needed for compatibility.
     SSLProtocol All -SSLv2
     SSLCipherSuite HIGH:!ADH:RC4+RSA:-MEDIUM:-LOW:-EXP
     SSLCertificateFile /var/lib/puppet/ssl/certs/puppet.serverlab.intra.pem
     SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/puppet.serverlab.intra.pem
     SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
     SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
     SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
     SSLVerifyClient optional
     SSLVerifyDepth 1
     #SSLOptions +StdEnvVars +ExportCertData
     SSLOptions +StdEnvVars
     # These request headers are used to pass the client certificate
     # authentication information on to the puppet master process
     RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
     RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
     RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
     # RackAutoDetect On
     DocumentRoot /usr/share/puppet/rack/puppetmasterd/public/
     <Directory /usr/share/puppet/rack/puppetmasterd/>
     Options None
     AllowOverride None
     Order Allow,Deny
     Allow from All
     </Directory>
    </VirtualHost>
3. Stop the puppetmaster service.

   service puppetmaster stop

4. Start the Apache service.

   service httpd on

5. Disable the puppetmaster service to prevent it from starting during system boot.

   chkconfig puppetmaster off

6. Enable the Apache service to automatically start it during system boot.

   chkconfig httpd on