ORIGINAL: Today I changed my webcam to an Xbox Live Camera (the ones for the Xbox360). The image is better than my old Intel CS430, but not great. Also, there’s a nice green ring in the image since it’s reflected from the window.

The solution is temporary as I’ll be receiving a Logitech Quickcam Pro 9000 this coming Tuesday that will have an even better image, and not have the silly ring.

So, please be patient. Also, I hope to be adding access to a higher resolution webcam image once the new camera arrives. Though, I’m not sure how high, or how often I want to update it since I don’t want my net connection to be taxed too heavily.

Thanks!

So, looking around online, it appeared that 10.5 just set the max files open per user to an awfully small limit (especially in the server version)… 256 files per user! Since I use a zeo/client setup, and use FileSystemStorage for storing files outside the zodb, I easily had this many files open. Again, why is this just happening after years?

I found a fair amount of info online about this issue. ulimit seemed to be the way to fix this on many *nix’s, but since 10.5 replaced much of this functionality with launchd, so it didn’t seem to actually do much.

First, from the command line, run “launchctl limit”. This will show you 3 columns. The first is the type, then the limit per user, then the limit for the whole system. So, at least in 10.5, you’ll see the maxfiles is 256 per user. To fix this, you have to create a file /etc/launchd.conf. In that, you just want to put “limit maxfiles 2048 unlimited” or something like that. That will raise the limit per user to 2048 (8x the previous limit).

The key, after this, is to reboot. Launchd sets all these limits on boot, and changing them once you’re up and going doesn’t seem to accomplish much (I’m guessing if you closed down everything running as a specific user, then restarted those processes, the new limits would take affect, but it’s just easier to reboot). Once you reboot, you can run “launchctl limit” again and see that the limits are raised.

Me, I set the per user limit to 8192 (32x the original limit), just because I know zope is going to open a lot of files, and this web server doesn’t do anything else.

That’s basically it. If you get errors about too many open files, up the limit, and reboot. Really pretty annoying this limit is so low on a server OS. And looking at my other systems, it’s still 256 per user in 10.6.4. This should be something Apple smartly configures based on usage… the 256 limit seems like something for a multi-user system where people are SSH’ing in and running tasks. Not for something like a web server. =/

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!

This says “if the request isn’t for www.example.com (it’s for example.com, foo.example.com, etc), then redirect it so it’s www.example.com”. Now, if you use HTTPS for your site, and you put the above rule in your .htaccess file, then you’ll need to address that. Probably something like:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteCond %{SERVER_PORT}!443
RewriteRule ^(.*) http://www.example.com/$1 [R=301,L]

#rewrite all HTTPS requests
RewriteCond %{HTTP_HOST} ^example\.com
RewriteRule ^(.*) https://www.example.com/$1 [R=301,L]

Though it might be over kill. Anyway, you should prevent google from indexing HTTPS anyway. Which I do with some trickery like in my HTTPS vhost file that does:

RewriteRule ^/robots.txt$ robots_ssl.txt [P]

Basically, that says “anything requesting robots.txt via HTTPS, give it robots_ssl.txt” which has a simple:

User-agent: Googlebot
Disallow: /
User-agent: *
Disallow: /

Basically, I don’t want it to index anything over HTTPS anyway. That’s duplicate content, and it bogs down my server to be letting google (or any spider) hammer away at https.

So, moral here… fix your site. Don’t let visitors use any URL they want to see your content, and worse, don’t let shit break when they do. Worst case, like, if your domain is example.com, and you don’t want a www on the website URL, then set up a wildcard in DNS to point everything at your webserver. Then setup the above redirects. So someone can type in whosyourmomma.example.com, and still get http://example.com.

Oh, and don’t even get me started on the whole www vs. no www issue. I’m not really of one mind on the issue… and think it varies from case to case. My site, I enforce it. At work, I enforce against it on our website. I honestly think it’s as aesthetics issue. Long URLs suck, and if typing in foo.example.com gives you a department, then you should get a webpage. You shouldn’t need www.foo.example.com. But, I’m sure this discussion is nearly as bad as top vs bottom posting.

For Google’s take, look: here.

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!

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”.

So, last night I spent about 4 hours rebuilding their Kerberos setup. Mainly by following this article, but it didn’t really work as they describe. I’m pretty sure the missing step is, you should reboot after removing all the Kerberos info. Just restarting the services doesn’t seem to be enough.

Anyway, to add to that, for some reason, kerberosautoconfig couldn’t write the edu.mit.Kerberos file in /Library/Preferences, and to really clear things out, I removed the keytab from /etc, and it wasn’t being regenerated.

The first issue I solved with “kerberosautoconfig -f /LDAPv3/127.0.0.1 -o /Users/admin/Desktop/ -r REALM.EXAMPLE.COM -m server.example.com” which outputs the edu.mit.Kerberos to the desktop of the admin user, then I manually copied that into Preferences. Once that was done, I was able to “touch” /etc/krb5.keytab, and run “sh-3.2# sso_util configure -r REALM.EXAMPLE.COM -f /LDAPv3/127.0.0.1 -a diradmin -v 1 all” and get it to populate the keytab file. A reboot later, and things were nearly working.

Last step was to touch these two files in /Library/Preferences that didn’t seem to exist: edu.mit.Kerberos.kadmind.launchd and edu.mit.Kerberos.krb5kdc.launchd. Reboot again, and both kadmin and the kdc were running. kinit was instant, kadmin -p diradmin was instant. Logging into a client, or via AFP, or just WGM as diradmin was instant.

While it probably was only 2 hours of work, it took me 4 because I really didn’t want to reboot before recreating the kerberos info, like the article said, yet for some reason, it just doesn’t work right if you don’t throw a reboot in there. =/

Your mileage may vary, but I’ll chalk this one up to a partially failed 10.6 upgrade. While it worked fine upgrading out OD Master, for some reason, it just hosed Kerberos for this department (even though, like I said, it LOOKED fine… it just didn’t work).

I love helping other departments out, and I’m especially glad my boss actually encourages/demands it.

But the real icing on this whole cake was, right as I finished, and was starting to test everything, my Comcast internet connection went out. This was at 12:15am. During this time, I had no net, or phone. They did this to me about a week ago too. It finally came back up around 1:30am. I had to stay up until then so I could actually finish testing. What I really want to know is, why the hell Comcast takes it’s headend down for over an hour at a time when people are more than likely still up. And why it took over an hour?! Don’t they have the configuration ready to load, and they just reboot the headend after it’s loaded? Or does it really take that long to cycle through and reestablish connections with everyone’s modem after a reset? Further, why on earth couldn’t they let people know they’re doing maintenance ahead of time? Email is not a new thing guys… and you have location info on my account. Email us when you’re going to take shit down. *grumble*