vSphere and PowerVault MD3000i Round Robin Configuration

The best tutorial I’ve found for setting up Round Robin Multipathing for ESX 4 with the iSCSI storage array PowerVault MD3000i:


Using round robin multipathing with 4 gigabit NICs on each end, I did not find, through benchmarking and application use, that enabling jumbo frames made any significant difference. Test it for yourself, but I found the results negligable.


Puppet Samba Module Plus Examples

This puppet module will ensure that Samba is installed, and the server has the correct configuration. If it is a file server (based on the fileshare variable in the site manifest), this module will ensure the samba service is running.



class samba {

     file {
               path => $operatingsystem? {
                    default => “/etc/samba/smb.conf”
               source => $operatingsystem? {
                    default => “puppet:///modules/samba/smb.conf.$nodetype”

     package {
          “samba” : ensure => installed;

     service { “samba” :
          name => $operatingsystem? {
               default => “smb”,
               ‘Ubuntu’ => “samba”,
          ensure => $fileshare? {
               ‘yes’ => “true”,
               ‘no’ => “false”,
          enable => $fileshare? {
               ‘yes’ => “true”,
               ‘no’ => “false”,



These examples will only showcase the additional filesharing section appended to my samba configuration files. For the a full configuration example, please read my “Joining Linux to a Windows Domain -Samba” blog post.


Sharing Apache Log Files




comment = apache log files for webtrends
path = /var/log/httpd
#valid users = webtrends
read only = yes


There are multiple ways to restrict access to a Linux server, and Samba services. The valid users option (commented out here) only allows those specific users to access the share.
SELinux may block Samba access to the /var/log directory. If you are getting access denied errors, yet permissions are correct… temporarily disable selinux by running setenforce 0. This sets SELinux into permissive (logging only) mode, and you can check if this is the cause of the problem.


Different Directory Options




comment = temp space
path = /data/temp
browseable = yes
writeable = yes
inherit permissions = no
create mask = 0664
directory mask = 0775

comment = data
path = /data/data
browseable = no
writeable = no
inherit permissions = yes 

Notes: The browseable option allows/disallows the user to browse to the share using Windows.


Joining Linux to a Windows Domain – Samba

Joining Linux to a Windows Domain Part 4 of 6

“Samba is an Open Source/Free Software suite that provides seamless file and print services to SMB/CIFS clients. Samba is freely available, unlike other SMB/CIFS implementations, and allows for interoperability between Linux/Unix servers and Windows-based clients.”1 Our purpose for using Samba is to join the Linux server to the Active Directory domain. This creates a trust between server and client and allows for Kerberos SingleSign On authentication. Samba can also be used to control user profiles, setup printers, and serve files from a Linux machine to a Windows client. Samba’s main configuration file is /etc/samba/smb.conf.

Note: A suite of Samba programs called Winbind is also a popular solution:

1: Http://



log file = /var/log/samba/log.%m
server string = Daniel Samba Server
map to guest = Bad User
workgroup = dhelm
password server =
max connections = 50
deadtime = 15
#change notify timeout = 60
socket options = TCP_NODELAY
domain master = no
local master = no
preferred master = no
hosts allow =
hosts deny = ALL
dns proxy = no
security = ADS
encrypt passwords = yes
kerberos method = system keytab

Joining Linux to a Windows Domain – NTP

Joining Linux to a Windows Domain Part 3 of 6

Network Time Protocol keeps the server in sync with the time of the domain controller. This is necessary for Kerberos to work properly. A few minutes off and authentication will fail. The main configuration file is /etc/ntp.conf and /etc/ntp/step-tickers tells the daemon what time servers to sync with.


NTP Configuration Files

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.

restrict default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.


# Hosts on local network are less restricted.
#restrict mask nomodify notrap
# Use public servers from the project.
# Please consider joining the pool (
#broadcast key 42 # broadcast server
#broadcastclient # broadcast client
#broadcast key 42 # multicast server
#multicastclient # multicast client
#manycastserver # manycast server
#manycastclient key 42 # manycast client
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.

fudge stratum 10

# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()’ing
# it to the file.

driftfile /var/lib/ntp/drift

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography.

keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42
# Specify the key identifier to use with the ntpdc utility.
#requestkey 8
# Specify the key identifier to use with the ntpq utility.
#controlkey 8

restrict mask nomodify notrap noquery
restrict mask nomodify notrap noquery



Joining Linux to a Windows Domain – NSS

Joining Linux to a Windows Domain 2 of 6

The Name Service Switch (NSS) controls how the server obtains network information needed for authentication. NSS is controlled by /etc/nsswitch.conf. “The name service switch file determines which name services a system uses to search for information, and in which order the name services are searched… The /etc/nsswitch.conf file includes a list of databases that are sources of information about IP addresses, users, and groups. Data for these can come from a variety of sources. For example, host names and host addresses, are located in the /etc/hosts file, NIS, NIS+, LDAP, or DNS. Each database has zero or more sources; the sources and their lookup order are specified in the /etc/nsswitch.conf file.”1 You can configure NSS on Linux servers to omitt LDAP from its sources. This intentionally causes user/group ids to be stored on the local server, thus avoiding a UID/GID conflict with another server; this is also helpful if you do not have a way of storing UID/GIDs on your domain controller. With this set up, Kerberos can still be used with PAM for network password authentication when “*” is in place of the user’s password in /etc/shadow.


1: Dr. Nikolai Bezroukov –


NSS Configuration File

passwd:        files     ldap
group:          files     ldap
shadow:        files     ldap
hosts:           files     dns
networks:      files
protocols:     db     files
services:      db     files
ethers:         db     files
rpc:              db       files
netgroup:     files     ldap
automount:  files     ldap

Joining Linux to a Windows Domain – PAM

Joining Linux to a Windows Domain 1 of 6


“Linux-PAM (Pluggable Authentication Modules for Linux) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users.”1 If you want to change how an application or system resource authenticates, it is good to start here. Located in /etc/pam.d/ , PAM contains a collection of configuration files that are called depending on the application being used. Below are five of the more important PAM services that authenticate users.

PAM Files Purpose
system-auth Common configuration file which provides a base for most services calling the PAM
library and many use an include directive to pull this file’s stack into it’s own.
login Login refers to the local login on a terminal/console of a Linux system.
gdm Gdm refers to the local login on a Gnome X Window of a Linux system.
sshd Sshd is the OpenSSH service. Some of the modules in this stack may be found as
configuration options in the /etc/ssh/sshd_config.conf file. For instance to allow for
root to login using ssh, this needs to be allowed for in it’s config file and PAM.
other If no PAM file exists for the given service, it defaults to this file.

Sometimes it can be necessary to modify these files manually, but beware that running system-configauthentication will blow away any changes.


1: Andrew Morgan, Thorsten Kukuk –


PAM Configuration Files


auth     required
auth     sufficient
auth     sufficient use_first_pass
auth     required
account     required
account     required
account     sufficient uid < 600 quiet
account     required
account     required use_first_pass
password    sufficient nullok obscure min=4 max=8 md5
password    sufficient use_authtok
session     required
session     optional
session     required silent umask=0077 skel=/etc/skel

Notes: Calling checks password / shadow files for user authentication first. Upon failure,
it will try to authenticate over Kerberos using the module. The use_first_pass option will
use the given password from the previous module.



auth     [user_unknown=ignore success=ok ignore=ignore default=bad]
auth     include system-auth
account     required
account     include system-auth
password     include system-auth
# close should be the first session rule
session     required close
session     include system-auth
session     required
session     optional
# open should only be followed by sessions to be executed in the user context
session     required open
session     optional force revoke

Notes: The checks the /etc/securetty file for acceptable terminal locations.



auth     [success=done ignore=ignore default=bad]
auth     required user != root quiet
auth     required
auth     include system-auth
auth     optional
account     required
account     include system-auth
password     include system-auth
session     required close
session     required
session     optional
session     required open
session     optional force revoke
session     required
session     optional auto_start
session     include system-auth

Notes: The auth option “ user != root quiet ” is good to use if you want to limit root from logging in. This is a best practice method as the user should login as him/herself and then change to root when needed.



auth      include system-auth
account      required
account      include system-auth
password      include system-auth
session      optional force revoke
session      include system-auth
session      required

Notes: Here is a good example of the include statement and use of the system-auth file.



auth     required
account     required
password     required
session     required

Notes: The module when called sends an immediate authentication failure back. This file is set up to deny access to all unknown services.

Joining Linux to a Windows Domain Introduction

Joining a Linux server/desktop to a Windows domain can be a very difficult task – I struggled with it for over a year. If you are unfamiliar with Linux I suggest using the open source software, Likewise Open, which is available for both Debian and RedHat based systems. I recommend however, to truely understand all the components that are required for this authentication to work – it makes tailoring the solution to your needs much easier. The purpose of this tutorial is to explain the different modules (with examples) so that the reader has yet another resource for learning how to succeed in integrating Linux into his/her Windows environement.

(Depending on your system, these lists may be different.)

Required Components:

Active Directory
Account Operator Rights
Sudo Rights

Packages Required:


This documentation is based on a Red Hat Enterprise Linux 5 system, however you can apply the concepts, and most of the code in a Debian enviornment.
Debian requires:



Puppet DNS Client Module

This puppet module will automatically populate a client’s DNS resolv.conf



Variables $domainname, $searchpath, and $nameservers are defined in the site manifest.

<% if !domainname.empty? %> domain <%= domainname %>
<% end %>
<% if !searchpath.empty? %> search <%= searchpath.join(” “) %>
<% end %>
<% nameservers.each do |ns| %> nameserver <%= ns %>
<% end -%>



class dnsclient {
      case $operatingsystem {
          default: {
               file { “/etc/resolv.conf” :
                    owner => root,
                    group => root,
                    mode  => 644,
                    content => template(“dnsclient/resolv.conf.tmpl”)

Puppet Introduction

Puppet is the leading open source tool for data center automation. Puppet helps you save time, gain visibility into your server environment, and ensure consistency across your IT infrastructure.1

Puppet has given my Linux environment stability by providing the reliability of a common configuration. There are many benefits when all servers are accessing services in the same manner. Administrators can spend less time tracking changes and isolated server issues. Troubleshooting becomes faster as the source is easier to diagnose. Consistency fosters visibility. Puppet has given Linux administrators a centrally managed system which provides greater efficiency and higher productivity. Automation saves time. Executing common tasks once to many servers saves time. Reducing the complexity of tasks saves time. Having more time allows administrators to perform more system administrative duties such as reviewing log files (from a central source, of course).

“Puppet is typically (but not always) used in a client/server formation, with all of your clients talking to one or more central servers. Each client contacts the server periodically (every half hour, by default), downloads the latest configuration, and makes sure it is in sync with that configuration. Once done, the client can send a report back to the server indicating if anything needed to change.”2 The management server runs the application “PuppetMaster” and manages all information. Each client runs the service “Puppet” and syncs every 30 min (default). Each client is referred to as a node, even the server can be a node (on my network it is). Nodes are defined by what modules they include. Modules are custom written configurations to achieve certain tasks, similar to Windows Group Policies.

Most of what should be covered in this section on the configuration of Puppet can be better explained by Puppet Labs. I recommend these links, book, and Google group:
· Pulling Strings with Puppet, James Turnbull ISBN13: 978-1-59059-978-5

Site Manifest

The site manifest is the file that sets global variables, defines nodes, and classes. Global variables can be used here to specify domain controller names and ip addresses. Other services such as LDAP and Kerberos are also defined and refer back to the domain controller. This allows for changes to be made and instantly modify the modules that use these variables. A default class is useful to include all the modules that every node should inherit. This ensures that every Linux server on my network has the same base configuration. Each node is defined with this default base class and a variable called $nodetype. This variable organizes similar purpose servers for modules with inconsistent configurations. All LAMP servers should have the same configuration, and setting the nodetype to “LAMP” keeps the LAMP environment consistent. but some servers have unique needs and in this case I like to set the nodetype to the hostname. All nodes inherit can inherit the Samba module, but setting the $fileshare variable to “yes” enables the service and Puppet will
make sure that Samba is always running. Additional modules that are not part of the default class are added in some node definitions as well. LAMP servers include a lamp class that installs and manages basic LAMP services.

Each module that is custom written has it’s own folder with the same name. The tree structure is as follows:
../<modulename>/manifests/init.pp – Manifest file to define the module. This file is required.
../<modulename>/files/ – Folder to contain files that are pushed out to the nodes.
../<modulename>/templates/ – Folder to contain templates that are used to create files on the nodes.


1 Puppet Labs –
2 Puppet Labs –

Example Site Manifest

import “classes/*”

$domain_controllers = [ “”, “” ]
$searchpath = [ “” ]
$nameservers = [ “”, “” ]
$domainname = “”
$ntp_servers = $domain_controllers
$ldap_servers = $domain_controllers
$fileshare = “no”

filebucket { main : server => “” }

class basenode_classes {
class default_node {
include system_banners
include ntp
include ldap
include kerberos
include dnsclient
include samba
include pam
include ssh
include hardware
include puppetd
include firewall
include localuser
include logwatch
include hosts_ad
include mail

node “” {
$nodetype = “linuxadmin”
include basenode_classes::default_node

node “” {
$nodetype = “LAMP”
include basenode_classes::default_node
include lamp

node “” {
$nodetype = “fileserver”
$fileshare = “yes”
include basenode_classes::default_node