Archive for June, 2010

There comes a time…

Tuesday, June 29th, 2010

… when you, as a systems administrator, need to just own up to the fact that your favorite pet project, the SAN you bought against your coworker’s recommendation, is in fact the source of significant performance problems and should not have been bought, much less put into production use.  Everybody makes mistakes, yours just happens to be more obvious than most.  Just don’t compound it by trying to justify the purchase by pointing the finger at issues that don’t exist – admit that the hardware you bought is the source of the problem, and move on to figuring out how to decommission the dratted thing to get rid of the performance problems.


Friday, June 25th, 2010

How, by all that you hold holy, do you – an individual user – consume over 1.4 TB of disk space in your home directory (which is not where your project files are supposed to go, dammit!) in just less than a year??  Seriously, how?  I haven’t collected that much shit in over 13 years of being a computer geek – and I’m a complete pack-rat when it comes to saving old useless cruft!!  I have, in total probably 400 GB of data – including all my email, all my code, and everything else I’ve ever touched – over 13 years!  My mind absolutely boggles.

Bigger isn’t always better

Wednesday, June 23rd, 2010

One of my recent complaints about computer hardware has been the size of the various drives available.  Especially for desktop machines or for USB thumb drives.  I don’t want a 4 GB thumb drive to put one stinking web site that’s 700K with images on – I want a 256 MB or smaller thumb drive!  I know most people think “bigger numbers” means “better”, but no, that’s not always the case.  And don’t even get me started on disk sizes versus spindle counts for database backends…

Someone’s trying to fail at life

Monday, June 21st, 2010

When you’re travelling on I-40 at 80mph in fairly dense traffic, you should not be putting mascara on.  Especially if you’re driving a Chevy HHR.  Just don’t do it.  You’re practically begging Darwin to step in and chlorinate the gene pool.

Tell me again why I did that?

Saturday, June 19th, 2010

Just a random thought that’s been bugging me for the better part of a year and a half now…  when I set up a monitoring environment like Nagios, and you’re in my group and get notifications from it, you might want to pay attention to those notification.  Or at least not tell me that you completely ignore them because “it’s too much spam”.

I’m sorry, who are you?

Friday, June 18th, 2010

That’s sort of what I’m saying right now.  We have a consulting group doing some sort of study on IT here at my company, and I’m being told the consultants need unsupervised root access to all my systems.  Consultants who I haven’t been introduced to, who I don’t know from Adam (or Eve), and who want to run a slew of scripts on each and every one of our machines, as root.

Dear consulting companies:  This is not how things are done.  You do not get root access to my servers, you submit your scripts to me and I decide if they will be run after looking at what they actually do.  I know how things work because I was a consultant.  To some very large companies.

I don’t care who you are or what company you’re with – the very fact that you peremptorily demanded I hand over the keys to the castle to you means you are unqualified idiots, unfit to shine my shoes.  No, you do not get root, or even user level access to my systems.

I told you so!

Tuesday, June 15th, 2010

Folks, when your sysadmin, or even when your computer geek friend, tells you to do something a certain way, there is usually a very good reason.  For example, when I tell my group “This directory should be read-only for all developers,” I usually know what I’m talking about.  If people would listen to me the first time, then maybe there wouldn’t have to be a recovery from a mis-typed “rm -rf” command against that directory…

Please, just listen to your sysadmin.  Believe it or not, your sysadmin knows what he/she is doing (well, most of the time, anyway), and really does have your best interests at heart even if you’re not familiar enough with computer to understand why (s)he is asking you do what seems like more work than you should.  Safe computing often does take more effort than unsafe computing.

Safety clown says be smart, don’t be stupid.

Google Voice

Monday, June 14th, 2010

I have a new phone number courtesy of Google Voice…  Heh.  This should be fun.

New Shiny

Monday, June 14th, 2010

I finally got my invite to Google Voice, which I will be setting up in the coming week.  There are a few things I already know I want it to do for me, there are other things which it can do but I haven’t thought about yet.  It’ll be good to finally get that project off the ground.

Poking Windows from PHP

Sunday, June 13th, 2010

This is a rather old article that I posted to Facebook a bit over a year ago now, but I thought it would make a good first entry to this blog.

I want to a bit of bragging, since I’m mentally useless for much else until after lunch.

Background – we have a brand new NetApp filer. We use OpenLDAP for authentication. The two don’t like each other all that much for authenticating CIFS sessions – the NetApp is going to replace Samba, which does talk with OpenLDAP just fine for authenticating CIFS sessions, but had *maybe* 5% of the NetApp’s functionality.

So that’s fact 1. Fact 2 is that we have a number of Window based projects coming in over the summer. Fact 3 is that I flatly refuse to manage 8 different user lists with seven of them being one-server lists.

This leads to a need for Active Directory. AD, at it’s core is nothing but LDAP with a different name, but it does some things strangely. Like storing passwords in Kerberos and making them difficult to change anywhere other than the CTRL-ALT-DEL screen from a domain client.

I didn’t like that, since the OpenLDAP password is still the primary password for our environment. So, screw you Microsoft, I’ll extend my password change page to modify AD passwords.

Except PHP no likey talking to AD for password changes… poo.

Python talks to OpenLDAP… Python talks to AD… Python talks web stuff through mod_wsgi – throw in some CherryPy and Kid, and we’re really gonna have a good time!

Well, there’s still that wierdness with the AD password format… and then there were issues with binding to the LDAP instances with sufficient permissions to perform modifications… and of course you can’t forget the fact that CherryPy doesn’t give you helpful error tracebacks out of the box… this leads to two weeks of banging my head against a wall fighting this stuff.

Today, however, I finally won… everything finally came together like it should, and my nice new fancy AJAX-y WSGI web site can change OpenLDAP and AD passwords simultaneously.

Since it was a tin-plated bitch finding all of the information I needed to do this right, I’ll post the relevant parts of the code here. I should probably post this on some sort of blog, but I don’t have a work-type blog and refuse to pollute my photography blog with computer code.

First, enabling useful error tracebacks in CherryPy version 3:
At the top of the module, do the following:
import cherrypy

I can’t tell you how much aggravation and time that one little config change saved me…

To modify passwords, you’ll need to use an SSL’ed connection, so you need to do two things. First, turn on LDAPS on your AD instance – it isn’t on by default. The Microsoft instructions at actually work as advertised (or did for me on Windows 2003 Server). Second, turn on LDAPS on your OpenLDAP instance – this is documented widely enough that I’ll not waste the space here re-documenting it.

Once you’ve done that, add the following line to your /etc/ldap.conf file to avoid potential issues with trust chains not being verifiable:

Verify you can use SSL with and ldapsearch -ZZ command – this is widely enough documented that I’ll not waste the space here to document it again.

Now for the good parts… the code.
This is it, semi-simplified and santized for usernames and passwords, with comments about what the username or other params should be at various points:

# Import necessary libraries
import ldap
import sha
from base64 import b64encode

# Connect to your LDAPS servers
openldap = ldap.initalize(“ldaps://openldap-server-fqdn:636/”)
adldap = ldap.initialize(“ldaps://ad-domain-controller-fqdn:636/”)

# Bind to OpenLDAP as the LDAP “root” user (not the same as Linux root!) – use the
# full DN, which will look something like:
# uid=ldapadmin,ou=people,dc=mycompany,dc=org
openldap.simple_bind_s(“<ldaproot>”, “<admin-password>”)

# Bind to AD as a Domain Admin, again using the full DN
# <adminname> is the login name of the domain admin
# <domain> is the name of the AD domain
adldap.simple_bind_s(“<adminname>@<domain>”, “<password>”)

# Find the DN’s you wish to change. The capitalization of sAMAccountName
# in the adldap search is VERY IMPORTANT
search = openldap.search_s(“ou=people,dc=mycompany,dc=org”, \
ldap.SCOPE_SUBTREE, “uid=<username>”)
linDN = search[0][0]
search = adldap.search_s(“cn=Users,dc=<domain>”, \
ldap.SCOPE_SUBTREE, “sAMAccountName=<username>”)
winDN = search[0][0]

# Generate the new passwords
newLinPass = “{SHA} + b64encode(“<newpass>”).digest())
newWinPass = unicode(“\”<newpass>\””, “iso-8859-1″).encode(utf-16-le”)

# Set up modification records
linMod = [(ldap.MOD_REPLACE, “userPassword”, [newLinPass])]
winMod = [(ldap.MOD_REPLACE, “unicodePwd”, [newWinPass])]

# Do the actual modification
openldap.modify_s(linDN, linMod)
adldap.modify_s(winDN, winMod)

It’s left as an exercise for the reader to perform sufficient error checking and handling. 🙂