01
back
topic
We have some really awesome developers here. And they do awesome things.
Here are some recent posts from our employees about Developers:
I was at the doctors office last week for a checkup and was appalled at the data security. First off, their networking closet is actually a closet. I know its the data closet because the door was wide open, and the door was wide open probably because it doesn’t have proper ventilation for the servers and networking gear. Strike one.
Strike two came when I was waiting for the doctor in the examination room. The nurse first came in and logged into the GE medical history software (the actual machine was already logged in, didn’t check to see if it was logged in as administrator but I bet you anything it was/is). Then she left the room. Left the room with the software that contained every medical record of probably every Beth Israel patient logged in. At this point I was a little freaked out, but was happy to see that at least it timed out after 5 minutes of inactivity and logged the nurse out. Oh that and the computer in the room was totally unlocked, I had full physical access to the machine for a good 15 minutes totally unattended. I could have done anything to that machine.
Then strike three came while I was getting blood drawn. Since the office is so small the label printer for samples is in the same room as the “collection” seat. So I sat in the seat and glanced about the room. Then the technician that was drawing my blood and preparing the samples sat at the computer terminal, which is plainly visible to anyone in the waiting room and anyone sitting having their blood drawn, and started to look up my information. There in a list of maybe 6 other people were my DOB, my social security number, my mothers maiden name, and my address. Plenty of information to steal my identity. Not only that but the other records on screen contained the same information for other patients. Great!
Needless to say I was stunned mortified. Actually so mortified that I totally neglected to complain, but how do you even complain about something like that to your doctor? I’m sure they do the best they can, and that their IT department is probably mostly to blame for letting the security get so lax.
Migrating Users from a Tiger server to a clean Leopard server
In a previous post I mentioned that we’ve been testing a new mail server solution. So far so good! I really like Kerio.
Only problem is that our internal authentication setup wasn’t really up to snuff, so I migrated everything over from our current Tiger server to a clean Leopard server. It was kind of a muddled process, and I figure other people might want to do the same thing, so here we go! steps!
What we’ll have at the end of this is a clean Leopard server running as an OD master, with kerberos rockin’ and all of our old users AND their passwords.
First things first, get you Leopard server box up and running, update it, get Open Directory running and set it to Open Directory Master. BE CAREFUL HERE. If you set your search base wrong or your kerberos realm wrong YOU WILL HAVE PROBLEMS LATER. Search base really could be anything, but I highly suggest you keep it as simple as possible, or if you can keep it the same as the search base on your old Tiger server.
Once you have Open Directory running, make damn sure that kerberos is also running before you do ANYTHING else. If its not, check your DNS, you should be able to resolve your server from its hostname AND ip address. If you need help, email me.
Now we need to export our users with their passwords, cause they are important and stuff. So on your old Tiger box get terminal buzzing cause everything we need to do is done there. Oh yeah, and this won’t harm your production server at all, so you can keep everything running live.
Lets export your users into an ldif file, like so:
sudo slapcat -l /path/to/users.ldifWhile we’re here lets make a directory to put our passwords in and then grab our password db, like so:
mkdir /path/to/tiger_passwd_db<br />sudo mkpassdb -backupdb /path/to/tiger_passwd_dbNow you’ve got a flat file with all of your users and a folder with your password database files, but wait, you can’t just go and import this stuff whilly nilly into your clean install. The install is clean, and your old user db is DIRTY.
So lets clean it up! The first thing you’ll want to remove from the ldif file is anything that already exists in your clean Leopard install, so things like the root user and the old diradmin account need to get trashed. These entries will look similar to this:
dn: uid=diradmin,cn=users,dc=barbariangroup,dc=com
uid: diradmin
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: apple-user
objectClass: extensibleObject
objectClass: organizationalPerson
objectClass: top
objectClass: person
sn: 99
structuralObjectClass: inetOrgPerson
entryUUID: 5355461a-cb28-102b-8468-c17ea9eda937
creatorsName: uid=root,cn=users,dc=barbariangroup,dc=com
createTimestamp: 20070720161633Z
gidNumber: 20
uidNumber: 1000
authAuthority: (bunch of junk here)
userPassword::(bunch of junk here)
loginShell: /bin/bash
apple-generateduid: (blahblah more junk)
homeDirectory: /Users/diradmin
cn: Directory Administrator
entryCSN: 20070720161633Z#00000e#00#000000
modifiersName: uid=diradmin,cn=users,dc=barbariangroup,dc=com
modifyTimestamp: 20070720161633Z
uid: diradmin
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: apple-user
objectClass: extensibleObject
objectClass: organizationalPerson
objectClass: top
objectClass: person
sn: 99
structuralObjectClass: inetOrgPerson
entryUUID: 5355461a-cb28-102b-8468-c17ea9eda937
creatorsName: uid=root,cn=users,dc=barbariangroup,dc=com
createTimestamp: 20070720161633Z
gidNumber: 20
uidNumber: 1000
authAuthority: (bunch of junk here)
userPassword::(bunch of junk here)
loginShell: /bin/bash
apple-generateduid: (blahblah more junk)
homeDirectory: /Users/diradmin
cn: Directory Administrator
entryCSN: 20070720161633Z#00000e#00#000000
modifiersName: uid=diradmin,cn=users,dc=barbariangroup,dc=com
modifyTimestamp: 20070720161633Z
Now hopefully you’re asking yourself, “how the hell do i know what to get rid of?” What I did was go to my Leopard server and exported the user database to an ldif file just like I did to the Tiger server and then compared the two, anything that already existed in the Leopard ldif file, I trashed from the Tiger ldif file.
But wait! Still not done cleaning that file up. You’ll need to search and replace your old LDAP search base with the new one for the Leopard server because this gets written to every user record. Annoying right? So for instance, on your Tiger server your search base was dc=server,dc=domain,dc=com and on your new Leopard server you’ve simplified things to just dc=domain,dc=com you’ll need to find/replace the dc=server in the Tiger ldif to match the NEW search string.
Cool, so that’s done, now you’re got a (nearly) perfect ldif file will all of your old user data. hooray! Lets get the Leopard server ready for the transition. Now since you’ve already set up Open Directory and made it the master, you will have already created a diradmin account. Since we don’t want to lose that password, we’ll first export your Leopard password database then import all your Tiger users, and then merge the two password databases.
So lets export that Leopard password database, open up terminal and run:
sudo mkdir passwords_from_leopard_server<br />sudo mkpassdb -backupdb passwords_from_leopard_serverYou’ll notice that’s exactly what we did before to export our passwords from Tiger. Now we need the public key from the Leopard server, grab that by running:
mkpassdb -dumpYou’re looking for a section titled “Public Key.” It’ll start with a 1024 and end with root@yourdomain.com. Hang onto that and head back to your Tiger ldif file, we’ve got some more find/replace-ing to do. The part you’re looking for is the “authAuthority” its a part of every user section of your ldif file and will look something like this:
authAuthority: ;ApplePasswordServer;0×46a0rewe95q184c10000000a0000000a,1024 35
1656695931665909934885529650807878698902444799687544911514204277892750444560
40005936512372916582789463659890238498589238402348023840210107069530617774018
50577252081327366279005303145695496695847004346878374632327359789719986361946
35779287349872349872349872349872347676758484746738357768598768767876313084048
91 root@server.com:ipaddress
1656695931665909934885529650807878698902444799687544911514204277892750444560
40005936512372916582789463659890238498589238402348023840210107069530617774018
50577252081327366279005303145695496695847004346878374632327359789719986361946
35779287349872349872349872349872347676758484746738357768598768767876313084048
91 root@server.com:ipaddress
You need to replace the string that starts with 1024 and ends with root@server.com:ipaddress with the string from the leopard server that starts and ends similarly. Make sense? good.
Now you’re done with that good ol’ ldif file, it should be perfect. Phew! That was a lot of finding and replacing eh? Take a break and get yourself a soda, you deserve it.
Alright lets get those users imported now! Send that Tiger ldif file over to your Leopard server. Since you’ve got Open Directory running already you’ve gotta kill slapd before you can import anything. Like so:
sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plistThen import the Tiger ldif file:
sudo slapadd -c -l users.ldifand then reload slapd
sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plistNow you can launch Workgroup Manager on your Leopard server and make sure all your users made it over, lovely they’re all there! Now time for the passwords, send that whole directory we created earlier from the Tiger server over to the leopard server. Then merge the databases:
sudo mkpassdb -mergeparent /path/to/tiger_passwd_db /path/to/passwords_from_leopard_serverAnd now for the moment of truth, try and authenticate yourself against the new server with the same password you had on the old server. If that goes well, hooray! If not, you’ll need to demote the server to stand-alone and then back to master and repeat everything, mega burn.
If all went well though, and you’re able to authenticate your users just fine, you’ll wanna go ahead and kerberize your server, like so:
sudo mkpassdb -kerberizeand you’re done! you now have a fresh clean Leopard server that is running Kerberos fine, and has all your old user data and passwords imported. Sit back, relax, then get back to work sorting out the rest of your network!
Other tips:
- Check out the inspiration for this post here actually most of these steps are taken straight from there, though this is more Leopard centric in that you need to kill slapd before importing users. Credit to Ian for finding that article in the first place, AFP548.com is a great resource for any Apple sysadmin.
- Have a fellow IT guy/gal near at hand for those frustrating moments, it helps to have someone to bounce ideas off of.
- Take your time. You will fail at least once, everyone does!
Mail Servers
Hey look at that! We’re growing! It’s really awesome because we get to meet and hang out with all these new fun people! but being the IT guy I of course see the stress adding all these people into the mix puts on our network.
Our current mail server/calendar solution just isn’t working anymore.
We rely on iCal pretty heavily for meeting scheduling, and let me tell you, since the last Leopard update it is BROKEN. We don’t use Apple’s CalDAV server, don’t even get me started on that, so the method we’ve adopted is one of subscription/updating flat files on a sever. Which works alright if you have like 30 people in the company all downloading and uploading their flat calendar files all at the same time. but if you double that number, well, you’re just asking for trouble buddy.
So the new thing we’re looking at is this Kerio Mail Server solution, which is just software, but it’ll run on Windows/Linux/Mac OS. Which is pretty awesome if you ask me, course I’m a sucker for flexible software. The best part about this software though is that it’s exchange-esque without having to bow to the whims of Microsoft.
Best Buy Selling Ubuntu
Saw this on slashdot this morning, looks like Best Buy is selling some retail version of Hardy Heron. I was really curious as to how they were getting away with it so I did some looking around.
On Best Buy’s website they claim the software is distributed by a company called ValuSoft, which is actually a division of THQ. Whats particularly curious to me is that neither of these companies is affiliated with Canonical Ltd. the company that owns Ubuntu, or at least not that I can tell.
So I guess that means that ValuSoft must have licensed the Ubuntu name and the software for retail sales? Which doesn’t really make business sense to me. If I were Canonical I would have sold the stuff direct to Best Buy instead of licensing it out, but then again perhaps Canonical doesn’t have the capacity to distribute mass volumes of their software to the ol’ brick ‘n mortars. Nor the capacity to offer the support that probably comes with the $20 price tag of this box.
Anyone seen one of these boxes around in a Best Buy?
Intel Never Deploying Vista Internally
I’m honestly not sure how accurate this article is but it seems legit enough to me. It basically says that Intel will never deploy Vista to its internal corporate machines, ever.
When a company as tech savvy as Intel, with full source code access and having written several large chunks of the OS, says get stuffed, you know you have a problem. Well, everyone knows MS has a problem, but it is nice to see it codified in such a black and white way though. Reassuring, like a warm cup of tea, or a public kick to the corporate crown jewels.
Man that is seriously bad for Microsoft. Article continues on with:
The other one is the big white horse in the corner, Mac OS. If there was ever a company that is loyal to Intel, it is Apple. If there was ever a company that could make MacOS work internally, it is Intel. While any marriage with the turtlenecked sociopath is a match made in hell, don’t count this one out either.
I would love that, MacOS operating better in an enterprise environment? freaking awesome. DO IT INTEL YEA!!!
Latest Attackers

Extremely late in the attackers post, so here’s a round up of the IP addresses that hit us hardest in the past two weeks.
123.212.102.46 ->
211.157.113.37 ->
222.185.245.35 ->
201.116.1.18 -> static.customer-201-116-1-18.uninet-ide.com.mx
200.161.196.95 -> 200-161-196-95.linuxlitoral.com.br
4.78.144.6 -> SUNGARD-NET.car1.Philadelphia1.Level3.net
24.235.98.156 -> wsp04969782wss.cr.net.cable.rogers.com
82.127.4.62 -> LSt-Amand-152-31-5-62.w82-127.abo.wanadoo.fr
211.157.113.37 ->
222.185.245.35 ->
201.116.1.18 -> static.customer-201-116-1-18.uninet-ide.com.mx
200.161.196.95 -> 200-161-196-95.linuxlitoral.com.br
4.78.144.6 -> SUNGARD-NET.car1.Philadelphia1.Level3.net
24.235.98.156 -> wsp04969782wss.cr.net.cable.rogers.com
82.127.4.62 -> LSt-Amand-152-31-5-62.w82-127.abo.wanadoo.fr
photo by flickr user cloneofsnake
Changing screen resolution from the command line on a Mac
So recently I was working on a mirror
and I ran into a problem setting the correct display resolution for the tv that makes up the “reflective” surface of the mirror. Basically the computer would think it was smarter than me and set a stretched resolution instead of a native one on reboot creating more of a fun house mirror effect than anything else.
McLeod Residence Mirror
The Barbarian Group and McLeod
topics: Installations, Processing, and Barbarian Labs
To solve the problem I knew I was going to have to script something so I started poking around in applescript and quickly realized that there was no library to change the resolution, and I’d have to default to using click actions and menu items. Needless to say, this is terrible idea so I gave up on applescript and started looking around for some command line tools.
I found cscreen, but the project has been closed up and the developer took down the app. Shucks. Then I asked the venerable Adam Miller
for a hand. After some google-ing we found this post in which a guy shares his code for a small C app to change the resolution. A few moments and a compile later and we had an app! An app that is super simple and works really well, in leopard even!
Adam Miller
Developer : Boston
topics: Agile and Scrum, Ruby on Rails, Technology Industry, HTML, and Creativity
Here is a zipped up copy of Newscreen, remember its command line only, so you’ll need to put it somewhere on your hard drive and use it from terminal, Mac only.
Here’s a usage example: newscreen -h 1440 -v 900
The other beautiful thing about this is that you can set custom resolutions. For instance, I have a Mac Mini at home that I use as a media hub and it’s hooked to an HDTV. The Mac Mini doesn’t have a decent recommended resolution for the TV so I was able to use this tool to set a custom res, and again it worked like a charm! Now it looks great and actually fits on the screen.
Oh and standard disclaimer here, this works for me but might not for you. Use at your own discretion, this is provided as-is no warranty implied or otherwise at all, ever. And I’m not responsible if it destroys your computer or files. Or if it murders anyone in your family.
UPDATE: as pointed out in the comments, this is intel only! for now. I’ll see if I can compile a universal version later.
Searching for Safari, a Kick in the Eye
Soon after the release of Plainview, we starting hearing about issues viewing pages that employ browser sniffing to look for compatible browsers, sites like abc.com where Safari is allowed, but Plainview is blocked. There was even suspicion that we were using an custom user-agent string which was causing trouble. Well, we weren’t, but we are now. Turns out that the sites mentioned, and many others it seems, are looking for “Safari” in the user-agent string, and WebKit does not identify itself as Safari out-of-the-box so these sites would believe Plainview to be incompatible. This is bad mojo. Apple recommends looking for “AppleWebKit” not “Safari” to ensure compatibility with WebKit powered browsers, and even offers some code to help out.
However, I hardly expect abc.com and their ilk to switch detect scripts overnight. So the next build of Plainview will include a tweaked user-agent string to identify itself as “Plainview (like Safari)” which seems to fix the issues with abc.com and hopefully others as well.