KerbMinder updated to v1.3

km_logo_256x

This release brings some significant changes (besides the slick new logo) thanks to a new collaborator, Francois Levaux. All of the original functionality is there, but he made the code much better (you should care about such things!) while adding a killer new feature.

With this release, KerbMinder no longer requires the Mac to be bound to Active Directory. On an unbound Mac, KerbMinder will prompt users for their username and domain information and use it to retrieve a kerberos ticket from the domain.

You can download v1.3 here.

ADPassMon updated to v1.11.4

Download the latest release on GitHub.

New feature:

This version introduces a user-configurable check interval. You can adjust the check interval anywhere from 1 to 24 hours.

checkInterval

Bug fixes:

ADPassMon is designed to poll AD for password expiration info immediately upon launch, 15 seconds after the computer wakes from sleep, and/or every x hours as determined by the check interval. Blog commenter Andy May let me know that the automatic expiration check was not working properly. This release fixes that bug.

ADPassMon v1.11.0 pre-release — please test

This pre-release contains a few significant changes, so I need your help testing it to make sure I haven’t inadvertently broken anything…

I have significantly changed how ADPassMon gets password expiration values. With Windows Server 2008, MS introduced Fine Grained Password Policy, which could potentially make it difficult to determine the expiration date of passwords, so the exact date of account password expirations is computed and stored in a property called msDS-UserPasswordExpiryTimeComputed that you can retrieve in OS X with a simple dscl lookup. Since this may not work in all environments, ADPassMon will fall back to the old method of looking up the information if the new method fails. Manual mode, where you enter the password expiration days, is still an option.

I’ve also added a connectivity check that will disable the Change Password and Refresh Kerberos Ticket menu items if the domain cannot be reached.

Lastly, in addition to a few cosmetic changes, I have added a note to the preferences dialog box that instructs you to hit the Enter key if you change any of the text field values.

Download the pre-release here, and please let me know how this version works for you by either commenting here or at github.

UPDATE: Link now points to the b2 release which adds a 15-second delay upon computer wake before ADPassMon runs its checks.

ADPassMon updated to 1.10.3

This release fixes a long-standing assumption (bug??). Until now, ADPassMon has assumed that your Mac’s primary DNS server is also an Active Directory server that can answer LDAP queries. With this release, AD LDAP server information is retrieved using the ‘dsconfigad’ and ‘dig’ commands. Specifically, the AD domain is retrieved using this command

dsconfigad -show | awk '/Active Directory Domain/{print $NF}'

and the output of this command is used in the following dig command

dig -t srv _ldap._tcp.DOMAIN | /usr/bin/awk '/^_ldap/{print $NF}'

Also new with this release:

I will now be hosting ADPassMon releases on GitHub instead of Dropbox. Please visit my ADPassMon releases page to download version 1.10.3.

ADPassMon has been forked!

A little over a month ago, a fellow from the UK contacted me about adding a few features to ADPassMon. We sent a some emails back and forth and he decided to fork my ADPassMon github repo and take a stab at modifying my code himself. He has just released his project as ADPassMon v2. I gave him a few pointers along the way, but all new features that differentiate it from my project are entirely his own work. I’m frankly impressed with how quickly he was able to wrap his head around AppleScript ObjC and achieve his feature goals.

If you are a current ADPassMon user, I encourage you to take a look at his detailed write-up and see if his fork will fit your environment better.

Monitor Isilon NFS thread counts

Here at [my workplace] we recently noticed that some of the nodes in our Isilon storage cluster were reaching their NFS thread limit. I won’t go into why that’s a bad thing or the reasons it was occurring, but we quickly realized it was something we should be monitoring closely. To see the current NFS thread counts on all nodes in your Isilon cluster, you use the following command:

isi_for_array -s sysctl vfs.nfsrv.rpc.threads_alloc_current

This returns something like the following:

dm11-1: vfs.nfsrv.rpc.threads_alloc_current: 16
dm11-2: vfs.nfsrv.rpc.threads_alloc_current: 16
dm11-3: vfs.nfsrv.rpc.threads_alloc_current: 16
dm11-4: vfs.nfsrv.rpc.threads_alloc_current: 16
dm11-5: vfs.nfsrv.rpc.threads_alloc_current: 16
dm11-6: vfs.nfsrv.rpc.threads_alloc_current: 16
dm11-7: vfs.nfsrv.rpc.threads_alloc_current: 16
dm11-8: vfs.nfsrv.rpc.threads_alloc_current: 16
dm11-9: vfs.nfsrv.rpc.threads_alloc_current: 16
...etc...

The first column gives you the node name and the last column gives you the current thread count. With few connections, the numbers on the left will be low. Our nodes are set with a 16 thread minimum. As more clients connect to a given node, more threads are spawned as needed to service them.

Running this command manually every once in a while is obviously less than ideal. Since Isilon nodes run an OS based on FreeBSD and python is available on them, I wrote a python script called ‘nfs_watcher.py‘ to monitor the thread counts for me. The script lives in /root on one of the nodes in the cluster and runs every 5 minutes via a cron entry in /etc/local/crontab.local on the same node.

When the script runs, it checks to see if any of the nodes is at or exceeding our warning threshold (70% of the max thread count of 256). The script sends an alert email (via smtp/sendmail) if at least one node has hit the warning threshold. Nodes beyond the threshold are identified at the top of the message in a line that starts “WARN” or “CRIT” followed by the node’s name and thread count. The email alert also includes a complete copy of the thread count data at the bottom so you can check to see if is an isolated spike or if the entire cluster is undergoing a heavy load.

You can find nfs_watcher.py on my github page.