/etc/security/limits.conf nofile absolute maximum

Apparently unlimited != unlimited in the Linux kernel for maximum number of open files. After some extensive digging, I finally found the actual maximum to the nofile setting in /etc/security/limits.conf. Yes I was searching in the context of Oracle (Imagine that) for a maximum number of procs / files. The Linux kernel has a hard upper limit of 1024*1024 (1048576 – a magical number I won’t soon forget).

Consider the following:

[root@localhost ~]# grep mrsmith /etc/security/limits.conf
mrsmith     soft    nofile      unlimited  
mrsmith     hard    nofile      unlimited

Trying to su to mrsmith suddenly casts you aside:

[root@localhost ~]# su - mrsmith
could not open session

Displaying the open file setting for mrsmith shows something odd:

[root@localhost ~]# ulimit -au mrsmith
open files                      (-n) 1024

Why would our number of open files be 1024? This apparently is the default setting for users without a custom nofile set based on the following bugzilla.

Then what is our actual upper bound for nofile in /etc/security/limits.conf? This isn’t well documented anywhere I’ve seen, but based on some research it appears to be 1024*1024. Setting nofile to 1048577 produces the same “could not open session” error as mentioned previously. 1048576 however seems to work just fine. Although you can set your nofile ulimit to this, the effects of such are unknown and I would highly recommend testing any such setting.

kvm-qemu: scripted clones of virtual machines

KVM is quickly becoming a viable competitor to paid vendors given the wide variety of features it offers in comparison (Memory page sharing, live migration, HA clustering, the list goes on and on…). Cloning virtual machines is common practice when deploying large environments with many virtual machines. Here’s a quick and dirty way to clone a virtual machine that could easily be scripted to deploy a large number of virtual machines:
Continue reading

vSphere PowerCLI – slot metrics

We’re not talking about coin slots here people! vSphere 5 uses slot sizes to determine the capacity for high availability (HA) fail-over metrics. Here’s a quick and dirty way to see what your current slot size is:

Connect-VIServer <vCenterServerName>
$Cluster = Get-Cluster -Name <clusterName>
$SlotDetails = $Cluster.ExtensionData.RetrieveDasAdvancedRuntimeInfo()
Write-Host -ForegroundColor Green "`n Slot info for <clusterName> cluster `
`n Number of vCPUs per slot: $($SlotDetails.SlotInfo.NumvCpus) `
`n MHz per slot: $($SlotDetails.SlotInfo.CpuMHz) `
`n Memory (MB) per slot: $($SlotDetails.SlotInfo.MemoryMB) `
`n Total Slots = $($SlotDetails.TotalSlots) `
`n Used Slots = $($SlotDetails.UsedSlots) `
`n Available Slots = $($SlotDetails.TotalSlots - $SlotDetails.UsedSlots)"

Be sure and replace <vCenterServerName> with your vCenter server name and <clusterName> with the HA cluster name for which you need slot information. This can be useful when determining your current fail-over capacity, just be sure your slot size is adequate for your environment. You should see output similar to the following:

Name                           Port  User
----                           ----  ----
<vCenterServerName>            443   <user>

 Slot info for <clusterName> cluster
 Number of vCPUs per slot: 2
 MHz per slot: 500
 Memory (MB) per slot: 1024
 Total Slots = 250
 Used Slots = 32
 Available Slots = 218

PowerCLI C:\temp>

Thanks to Alan over at http://www.virtu-al.net/

OpenLDAP basic initial setup on CentOS 6.2

When I started setting up openldap for centralized authentication purposes I was surprised at the lack of “basic” documentation on the subject. There are several “getting started” guides, however most of them are documented using slapd.conf instead of cn=config. Here’s what you need to setup openldap for authentication using the new cn=config ldap database on CentOS 6.2:

First you’ll need to install the client and server packages for openldap:

[root@openldap-server ~]# yum -y install openldap-servers openldap-clients

This installs all the necessary tools and daemons (slapd) you need to get a base directory setup that you can later modify with your favorite ldap editor.
Continue reading

RHEL extended file and folder permissions (ACLs) using setfacl and getfacl

I’ve heard several people say they thought the application of access control lists (ACLs) in Linux lacked something to be desired. It’s obvious they didn’t know about the setfacl and getfacl tools available in RHEL. Extremely granular file and folder permission structures are possible with these tools and here I’ll give you an example of how to accomplish basic ACL structures that you might not have previously thought possible:
Continue reading

RHEL chkconfig service script example

I’ve put several of these together and a few people have asked me for a generic chkconfig script so here goes. You’ll need to replace /path/to/servicename and anything that says servicename with the actual path of what you want to run. Save the file in /etc/init.d as what you want the <service name> to be then simply run:

# chkconfig --add <service name>

# chkconfig: 35 90 12
# description: My server

#Source function library.
. /etc/init.d/functions

start() {
        echo -n "Starting my server: "
        daemon /path/to/servicename
         ### touch the lock file ###
        touch /var/lock/subsys/servicename
        success $"My server startup"

stop() {
        echo -n "Stopping my server: "
        killproc servicename
         ### Remove the lock file ###
        rm -f /var/lock/subsys/servicename

case "$1" in
        status servicename
        echo $"Usage: $0 {start|stop|restart|reload|status}"
        exit 1
exit 0

how-to: cloning a boot from SAN RHEL LUN

Some prep work goes into setting up a good boot from SAN LUN for use in deploying new physical systems however once you have a well defined structure of LVM and standard disks, the process of cloning a boot LUN can easily be scripted. Here’s the basic steps that go into updating your kernel once you’ve cloned a boot disk.
Some things to keep in mind when preparing a LUN to clone to other systems:

  1. Try to keep the number of LUNs required for the system to boot to 1. This will ensure there are less edits required to update your initrd image.
  2. Avoid cloning a LUN that has multiple volume groups with more than 1 SAN LUN. As of RHEL 5.7 (2.6.18-274.x kernel) udev has problems utilizing a system volume group when say and application volume group (with separate physical disks) is missing.
  3. Prior to cloning your system, update your multipath.conf so that your bindings file is located on the root partition and not on a separate partition as so:
    bindings_file /etc/bindings

Post clone steps for updating your initrd image with the scsi ID for your new boot disk:
Continue reading