Everybody Staze…

At work, we’re looking at a major webpage redesign, and are therefore looking at other similar programs and their websites to see what they are using… and one major thing has struck me in the process. No one uses redirects to force certain URLs. For example: http://www.staze.org vs http://staze.org. Now, in one case, both work, and they present the same content (bad for SEO), in the WORST case, one works, and the other doesn’t. Almost none of the sites we looked at handled this correctly.

Really, it’s extremely easy to fix. Either in .htaccess, or in your virtual host file, just add something like:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^localhost [OR]
RewriteCond %{HTTP_HOST} ^127\.0\.0\.1
RewriteRule ^(.*) – [L]
RewriteCond %{HTTP_HOST} !^www\.example\.com
RewriteRule ^/(.*) http://www.example.com/$1 [R=301,L]

UPDATE: Please see the corrected code above to account for anything referencing your site on the local machine via localhost, or 127.0.0.1…. some of my site broke without me noticing until today. DOH!

Read more…

Since I have been pouring over OD the last few days, I decided to look again at a change in WGM that came with 10.5. Computer records now have a place for Hardware UUID. UUIDs offer a theoretically truly unique identifier as opposed to MAC address, which I’ve seen not be unique (mind you, this was a manufacturing defect that happened when I was working at 3com, where some customers were getting boxes of NICs all with the same MAC address). Trying to populate it, however, results (for me) in a “Attribute not mapped” error, saying I should contact the sys admin. So, self… this doesn’t work.

A quick search around resulted in a Apple mailing list discussion list thread that talks about this very issue. It seems the 10.6 update added these attributes to the schema, but didn’t map them to anything. Cool.

So, here’s the scoop. Open up Directory Utility on the OD Master in /System/Library/CoreServices, then unlock. Open up LDAPv3, then click on 127.0.0.1, then Edit. Now “Search & Mappings”, and scroll down on the left to “Computers”. Open that up, then click “Add”. You should see the option to add “HardwareUUID”. Select and Click “Okay”. Now with that new one selected, on the right, type in “apple-hwuuid”. Now “Write to Server” and authenticate. Hit Okay. Now you should notice that “LDAP Mappings” is set to “Custom” or “From Server”. You should be able to change that back to “Open Directory Server” and click “Okay”.

HardwareUUID in WGM should now work. Have Fun!

I assist other departments on campus with Mac related issues fairly regularly, since I’m one of the few Sysadmin’s on campus that really know Mac OS X Server. The issue they were seeing (and have been seeing since they upgraded to 10.6 about 4 months ago) was any time someone tried to login to a client, or really anything as a user that was part of the OD, it would take about 60 seconds to authenticate. If they used their server’s local admin account, however, it worked instantly.

Everything seemed to be running, but it just took a long time. Investigating further, everything seemed to point to Kerberos just not functioning. It was running, but kinit would take about 60 seconds to come back asking for a password. And for some reason, the REALM for the Kerberos server had been set as SERVERNAME.LOCAL. Which, shouldn’t be an issue in of itself, but it was certainly not “proper”.

Read more…

Our remote tape library has been malfunctioning for the past few months, and our remote location just managed to ship the library down. Powering it up on the bench, I got the wonderfully informative “L:H/W Inoperable Servo Error”. Okay…

So, after a reset, and it still doing that, I figured the next step is to open it up. After removing all 11 screws, removing the lid, and powering it on, I noticed that the carousel wasn’t aligned correctly with the tape drive.

So, I hand rotated the carousel around so the “hole” in the carousel’s metal ring (while off), and fired it back up. Lo-and-behold, it went through it’s initialization process and scanned all the tapes, and works fine.

Guessing it was in the middle of an indexing or something and lost power, but in such a way that it didn’t re-initialize when it came back up. =/

Either way, works now.

So, if you have this issue, remove all the screws (3 on each side, 2 in the back top, and 5 on the top), open the top up, and rotate the carousel around until the hole lines up with the sensor (you’ll see where the hole passes by the sensor). The carousel only rotates one direction by hand… so if you miss it, rotate it back around. Then power it on. It should fire up just fine.

Good luck!

UPDATE: This has been addressed in the nightly build found here: nightly, and the release notes here.

The latest release of Deploystudio (here) introduces a great new feature that creates the master image on the HD that is being imaged, then copies it up to the server. Which is MUCH faster than the old version of things where it would create the image on the server as it was being read off the disk. This took hours and hours. The new method takes probably 1.5 hours to create our master image.

Read more…