Patching Changes with ESXi 5.x

updated 12/14/2014

VMware has been pushing people to buy their update manager for a while, but they allowed command line updates through a perl utility in the vSphere cli bundle. To use that procedure on a 4.x ESXi server, look at this post:
Upgrading to ESXi 4.1 from 4.0

To update ESXi 5.x, download the patches from the VMware Patch Portal, upload the patch or patches to a datastore on the ESXi 5.x server. You'll need to update your VMware cli tools. The easiest way to download it is to browse to the web server on the management interface of your ESXi 5.x server (https://ip_address_or_hostname_of_your_esxi5_server)

You'll see it on the upper right:

vSphere Remote Command Line

You'll also need to enable ESXi cli on the ESXi server (it's in the console in the same location that you enable SSH) as well as set the server to maintenance mode.

You can then run the esxicli utility.

You need to know the name of the patch bundle and its location on the datastore. For my server, I was able to list the patch contents of the bundle like so:

G:\Program Files (x86)\VMware\VMware vSphere CLI>bin\esxcli.exe --server=my_server_ip --username=root software sources vib list --depot=/vmfs/volumes/datastore1/patches//ESXi500-201112001.zip

as well as a large list of patches

And I installed it:

G:\Program Files (x86)\VMware\VMware vSphere CLI>bin\esxcli.exe --server=my_server_address --username=root software vib update --depot=/vmfs/volumes/datastore1/patches/ESXi500-201112001.zip
Enter password:
Installation Result
   Message: The update completed successfully, but the system needs to be reboot
ed for the changes to be effective.
   Reboot Required: true

as well as a list of patches. Of course, after that you need to reboot and exit maintenance mode.

vSphere local patching over SSH

 There is no need to even install the esxcli tool. You can simply 1. copy the zip file over 2. enable ssh (security profile - just start the ssh service) and run esxcli after connecting via ssh as an admin user.

The command line is a little different as you have no need for a username or a server name, nor do you need .exe on the command, being a linux binary.

i.e.,

esxcli  software vib update --depot=/vmfs/volumes/datastore1/patches/ESXi550-201410001.zip

RSA SecurID 130 Appliance Basic Setup

I set up one of these years ago and wrote up a short article describing how to use one of these to authenticate against them from a Cisco ASA. I set another of these up recently and figured I'd cover the basic points to get it running.

Assuming your Active Directory domain is called testad.local and you've named the appliance "rsaappliance.testad.local" in DNS...

1. You'll need to do the base configuration and set up the initial license file. It's important that the following is configured correctly:

IP Address (it's probably necessary that you create a PTR record in DNS for the appliance. At the very least, you should have the IP address in DNS with a matching hostname (i.e., rsaappliance.testad.local)

NTP/time sources - you should use the same NTP servers that you're using for your Active Directory domain controllers. If you are running VMware ESX/ESXi and are running the domain controllers as VMs, you can use the ESX/ESXi host(s) as NTP time sources.

2. The next work requires use of the operations-console:

https://rsaappliance.testad.local:7072/operations-console

 Under the admin console -> deployment configuration -> Identity sources -> add new ->

(you'll probably be required to provide administrative credentials to get in)

provide the:

Identity Source Name: descriptive name

Type (Microsoft Active Directory)

Directory URL

directory UL: ldap://dc1.testad.local  (or ldaps://dc1.testad.local, if available)

directory failover URL: ldap://dc2.testad.local

directory user id: you can create a user for this purpose. Assuming you created a user called "rsaauth" in the default users container in Active directory, you'll construct the entry like so:
   cn=rsaauth,cn=Users,dc=testad,dc=local
 
   Of course, you might have OUs set up for these sorts of things. If you had an OU in your domain called "utilityusers," the entry would be:
   cn=rsaauth,ou=utilityusers,dc=testad,dc=local
 
   (for those of you unfamiliar with LDAP, cn should be the full name of the user.)
   2b. click on the "map" tab and set your User Base DN and User Group base DN. If you're not using any OUs, you'll default to the standard cn=users,dc=testad,dc=local... otherwise, put in the appropriate OU. You can fine tune the LDAP search filters and mappings below, but all you need to get started is the User Base DN and User Group DN.
 
  By the way, if you check "Directory is an Active Directory Global Catalog," you'll likely get an error in a later step:
 
  "Cannot link the runtime identity source because no administrative identity sources reference this runtime source"
 
  The easiest way to fix this is to uncheck "Directory is an Active Directory Global Catalog" - or do additional configuration.

3. You'll want to enable the Radius Server, if you're going to authenticate against this appliance from, say, a Cisco ASA:

 Deployment Configuration -> RAIDUS -> Configure Server -> go ahead and create your RADIUS server... the defaults should be fine.


 4. You'll need to link the newly created Identity Source to a realm (newly created or the default SystemDomain realm.)

 Go to the security console:

 https://rsaappliance.testad.local:7004/console-am

 5. From there, go to Administration -> REALMS -> Manage Existing (you can create a new realm, if you have the appropriate licensing)
    select the "SystemDomain" realm (or the realm you created if you chose to create your own.)
    Under Link Identity Source, select the active directory Identity source you created in step one and click the arrow pointing to the right to put it in the linked field. Now, save your entry.
   
    If you get the dreaded "Cannot link the runtime identity source because no administrative identity sources reference this runtime source," this probably means you set the Active Directory Identity Source in step 1 to be a Global catalog.
   
 You should be ready to add tokens. To do so under the security console:

 Authentication ->  Manage existing -> New Import SecurID Tokens Job ->

 

name: just a descriptive name
 

Security domain: SystemDomain (unless you've created your own security domain)
 

Import file: (import the xml file from the CD RSA included with the tokens
 

File password: This password was likely on a scratchoff slip of paper in a separate folder

 Provided the tokens import correctly, you should be able to start assigning them to users.

6. Finally, you'll probably need to add a Radius client if you you enabled the Radius server in step 3. From the Security console ( https://rsaappliance.testad.local:7004/console-am): RADIUS -> RADIUS clients -> add new:

Client Name: use a descriptive name

IP Address: the IP address of the client

Make / Model: Select the appropriate model (i.e., Cisco PIX for Cisco ASA)

Shared Secret: choose a long password

Go ahead and save without RSA agent.

Disk usage not accounted for in Linux

I had a filesystem nearly at full capacity (99%, in this case.) This server had a single root filesystem and du -sh /*listed only about 20% of the used capacity.

I suspected an open file handle that hadn't been released, even though the actual file had been deleted. Normally, if a process dies, it will release the handles, though a child process might still be around. Anyway, I turned to lsof and looked for deleted:

lsof | grep deleted

syslogd   30139      root    7w      REG              253,0 6794843241    1307979 /var/log/ldap.log (deleted)

Syslog was the culprit. After a restart of syslogd, the handle was released and all was well.

Left Join Example - SQL Query

Today, I had to write a MySQL query that found entries in one table that had no corresponding entries in a second table. The schema was written in such a a way that table A's id column corresponded to an id column in  table B (call the column tableA_id.) It's possible that some entries in table A might not have corresponding entries in table B (and vice versa, but I didn't actual care about the unique table B entries.) Table A was constructed with an "id" column and a "name" column. Table B was created like so: "id" "attribute" and "tableA_id"

The query (a rather simple one, at that...)

select A.id, A.name from A left join B  on A.id = B.tableA_id where B.tableA_id is NULL

Oneliner for renaming files

Say you have a series of files you want to rename like so:

 a37.zip to a37-archive.zip
b38.zip to b38-archive.zip
c39.zip to c39-archive.zip

and so on...

Here's a useful oneliner for bash:

for x in `ls`; do echo $x | sed -e 's/\(.*\).zip/\1-archive.zip/g'| xargs -t mv $x ; done

That should to it. Of course, there are other ways of doing it, but this way is fairly simple.

Nagios Group Service Checks and Exclusions

Using hostgroup_name in service checks is very, very useful. However, I find that I often want to include the Nagios server in one of the hostgroups, but don't necessarily want to configure nrpe for the nagios host. An easy way around this is to use Nagios's exclude feature. You can exclude a group (or host) by prefacing it with "!"

For instance:

1. create a group that contains only your nagios host

define hostgroup {

        hostgroup_name localhost-monitor-hosts

        members         mynagiosserver

}

2. create the service:

define service {

        hostgroup_name          unix-hosts,!localhost-monitor-hosts

        use                             critical-service

        service_description             check_disk

        check_command                   check_nrpe!check_disk!80!85

        check_freshness                 1

        register                        1

        }

This will check all hosts in the unix-hosts group, excluding any in localhost-monitor-hosts. You can obviously create multiple groups, each with a different purpose.

Note, you can also define a service with more than one host, and exclude hosts that way:

define service {

         host_name www1, www2, !www3

         use generic-service

         service_description check_ping

         check_command check_ping!100.0,20%!500.0,60%

}

but I find that more taxing, as you have to maintain the host_name... which is kind ignoring the whole point of groups.

Dell OMSA on Linux: disable SNMP

In spite of the fact that the Dell OMSA tools on linux have a config file called omreg.cfg that explicitly allows shut off of SNMP, it doesn't seem to work.

The proper way to disable snmp for the Dell tools is:


cd /opt/dell/srvadmin/var/lib/srvadmin-deng
touch dcfwsnmp.off  dcsnmp.off

You can restart the Dell services again:

/opt/dell/srvadmin/sbin/srvadmin-services.sh restart