Blog

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:

http://www.gronau.it/index2.php?option=com_content&do_pdf=1&id=831

 

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.

 

../puppet/modules/samba/manifests/init.pp

class samba {

     file {
          “smb.conf”:
               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

../puppet/modules/samba/files/smb.conf.LAMP

….

 

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

Notes:

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

../puppet/modules/samba/files/smb.conf.dataserver

….

 

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

[data]
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
“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: http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html

1: Http://www.samba.org

 

smb.conf

[global]
log file = /var/log/samba/log.%m
server string = Daniel Samba Server
map to guest = Bad User
workgroup = dhelm
password server = dc1.danielhelm.com
realm = DANIELHELM.COM
max connections = 50
deadtime = 15
#change notify timeout = 60
socket options = TCP_NODELAY
domain master = no
local master = no
preferred master = no
hosts allow = 10.0.0.0/16 127.0.0.0/32 0.0.0.0
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

 NTP
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
ntp.conf

# 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.
 

restrict 127.0.0.1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#broadcast 192.168.1.255 key 42 # broadcast server
#broadcastclient # broadcast client
#broadcast 224.0.1.1 key 42 # multicast server
#multicastclient 224.0.1.1 # multicast client
#manycastserver 239.255.254.254 # manycast server
#manycastclient 239.255.254.254 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 127.127.1.0 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

server dc1.danielhelm.com
restrict dc1.danielhelm.com mask 255.255.255.255 nomodify notrap noquery
server dc2.danielhelm.com
restrict dc2.danielhelm.com mask 255.255.255.255 nomodify notrap noquery

 

step-tickers

dc1.danielhelm.com

dc2.danielhelm.com

Joining Linux to a Windows Domain – NSS

Joining Linux to a Windows Domain 2 of 6


NSS
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 – http://www.softpanorama.org/Solaris/Reference/etc/nsswitch.shtml

 

NSS Configuration File
nsswitch.conf

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

 

PAM
“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.
Resources:
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html
http://linux.die.net/man/5/system-auth
http://linux.die.net/man/8/pam_krb5
http://linux.die.net/man/8/pam_unix

 

1: Andrew Morgan, Thorsten Kukuk – http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-introduction.html

 

PAM Configuration Files

system-auth

auth     required pam_env.so
auth     sufficient pam_unix.so
auth     sufficient pam_krb5.so use_first_pass
auth     required pam_deny.so
account     required pam_unix.so
account     required pam_access.so
account     sufficient pam_succeed_if.so uid < 600 quiet
account     required pam_access.so
account     required pam_ldap.so use_first_pass
password    sufficient pam_unix.so nullok obscure min=4 max=8 md5
password    sufficient pam_krb5.so use_authtok
session     required pam_unix.so
session     optional pam_krb5.so
session     required pam_mkhomedir.so silent umask=0077 skel=/etc/skel

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

 

login

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

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

 

gdm

auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so
auth     required pam_succeed_if.so user != root quiet
auth     required pam_env.so
auth     include system-auth
auth     optional pam_gnome_keyring.so
account     required pam_nologin.so
account     include system-auth
password     include system-auth
session     required pam_selinux.so close
session     required pam_loginuid.so
session     optional pam_console.so
session     required pam_selinux.so open
session     optional pam_keyinit.so force revoke
session     required pam_namespace.so
session     optional pam_gnome_keyring.so auto_start
session     include system-auth

Notes: The auth option “pam_succeed_if.so 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.

 

sshd

auth      include system-auth
account      required pam_nologin.so
account      include system-auth
password      include system-auth
session      optional pam_keyinit.so force revoke
session      include system-auth
session      required pam_loginuid.so

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

 

other

auth     required pam_deny.so
account     required pam_deny.so
password     required pam_deny.so
session     required pam_deny.so

Notes: The module pam_deny.so 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:

nss_ldap
pam_krb5
krb5-workstation
nscd
ntpd

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:

libpam-ldap
krb5-user
krb5-clients
libpam-krb5
ntp
nscd

 

Puppet DNS Client Module

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

 

../puppet/modules/dnsclient/templates/resolv.conf.tmpl

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 -%>

 

../puppet/modules/dnsclient/manifests/init.pp

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).

Infrastructure
“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.

Configuration
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:
· http://docs.reductivelabs.com/guides/language_tutorial.html
· http://docs.puppetlabs.com/guides/configuring.html
· http://docs.puppetlabs.com/guides/modules.html
· http://docs.puppetlabs.com/references/latest/type.html
· Pulling Strings with Puppet, James Turnbull ISBN13: 978-1-59059-978-5
· http://groups.google.com/group/puppet-users

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.

Modules
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 – http://www.puppetlabs.com/
2 Puppet Labs – http://docs.puppetlabs.com/guides/introduction.html

Example Site Manifest

import “classes/*”

$domain_controllers = [ “dc1.danielhelm.com”, “dc2.danielhelm.com” ]
$searchpath = [ “danielhelm.com” ]
$nameservers = [ “10.1.0.10”, “10.1.0.20” ]
$domainname = “danielhelm.com”
$ntp_servers = $domain_controllers
$ldap_servers = $domain_controllers
$fileshare = “no”

filebucket { main : server => “linuxadmin.danielhelm.com” }

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 “linuxadmin.danielhelm.com” {
$nodetype = “linuxadmin”
include basenode_classes::default_node
}

node “lampjoomla.danielhelm.com” {
$nodetype = “LAMP”
include basenode_classes::default_node
include lamp
}

node “fileserver.danielhelm.com” {
$nodetype = “fileserver”
$fileshare = “yes”
include basenode_classes::default_node
}