![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
Welcome
Thanks for checking out my blog. There's a good chance you're here because you had a class with me or met me at a tradeshow. I'm an Apple- and Adobe-certified instructor from Boston, and a full-time trainer for Future Media Concepts.
Feel free to take off your shoes, get comfortable, and have a look around. All of my previous posts can be searched by the keywords along the left side of the page, my resume can be found on the right, and if you care to write me with a question, my address there, too. Please, don't hesitate- your questions give me material to write about (and improve my classes).
And YES, I am available for consulting!
- Build a Mac OS X Server and call it yoursus. We used a headless Mac mini to do the job.
- You must use external DNS servers on this server (so it won't check itself for updates).
- Add a record for your server on your internal DNS, so yoursus.yourdomain.com resolves to your SUS's IP.
- Start Software Update Server (SUS). It may take some time to cache all updates -- our /usr/share/swupd/html/ folder now has almost 9GB of files in it!
- Start Web Service, and add following redirect (Server Admin » Web » Sites » default » Edit » Aliases » URL Aliases and Redirects » Add » Redirect):
- Pattern: /content/catalogs/index-1.sucatalog
- Path: http://yoursus.yourdomain.com:8088/index.s
ucatalog
- Add a zone in your internal DNS, called swscan.apple.com, and point the whole subdomain to the IP of your SUS.
- Flush your DNS cache on the clients: lookupd -flushcache
Now just run Software Update on the clients, and enjoy the speed of downloads!
The only downside of this setup is the mini complaining in system.log that it has no reverse DNS entry for itself. To be honest, I didn't have much time to think how to set it up without extra hardware; I just happened to have a spare mini for this purpose. Maybe there's a way to have the DNS and SUS running on one server, perhaps via two IP addresses and tweaking of config files. I also didn't test it much with Panther clients; it possibly needs different redirects for that. Comments welcomed. Happy updating!
Warning: I emphasized using internal DNS so you won't propagate Apple's own zone to the outside world.
Keep an eye out for another post coming soon, where I show how to do this in the Terminal. But I find this method a bit safer- if you're running your own Software Update server, its not that hard to also run your own Web and DNS.
Keychain Minder
Essentially this app checks to see if the default keychain, which is usually the login keychain, was unlocked during the login process. If it was unlocked the app does not show in the dock or display anything it just quickly quits. The idea is that a user won't even notice this is going on if everything works out well.
If the keychain is not unlocked it will display a dialog box prompting the user to put in the old and new passwords. It will then attempt to reset the default keychain. If successful this will also cause the keychain to be unlocked and usable by any apps on the machine.
If the user has forgotten their old password, they can create a new keychain with their new password and backup the old one.
Also, when entering in their password Keychain Minder checks to make sure it is in fact their login password. This way there is no chance of them mistyping the password.
The app also creates a pref file, com.afp548.KeychainMinder.plist, with one entry. Set this to NO if you don't want the app to check at login. This is useful for when you set this application as a login item through managed preferences but some users want to have a unique login keychain password.
How do I use this?
Run this as a login item for your users. You configure that in the Accounts preference pane of the System Preferences.
Why do this?
The primary function of this application to keep the users from getting confused when they've changed their password through a web interface or from the PC. When logging back into OS X their login password no longer matches their login keychain password so things like Safari start yelling about a locked keychain. This is all rather cryptic and confusing for the user, so this app hopes to help smooth things out.
Essentially this app checks to see if the default keychain, which is usually the login keychain, was unlocked during the login process. If it was unlocked the app does not show in the dock or display anything it just quickly quits. The idea is that a user won't even notice this is going on if everything works out well.
If the keychain is not unlocked it will display a dialog box prompting the user to put in the old and new passwords. It will then attempt to reset the default keychain. If successful this will also cause the keychain to be unlocked and usable by any apps on the machine.
If the user has forgotten their old password, they can create a new keychain with their new password and backup the old one.
Also, when entering in their password Keychain Minder checks to make sure it is in fact their login password. This way there is no chance of them mistyping the password.
The app also creates a pref file, com.afp548.KeychainMinder.plist, with one entry. Set this to NO if you don't want the app to check at login. This is useful for when you set this application as a login item through managed preferences but some users want to have a unique login keychain password.
How do I use this?
Run this as a login item for your users. You configure that in the Accounts preference pane of the System Preferences.
Why do this?
The primary function of this application to keep the users from getting confused when they've changed their password through a web interface or from the PC. When logging back into OS X their login password no longer matches their login keychain password so things like Safari start yelling about a locked keychain. This is all rather cryptic and confusing for the user, so this app hopes to help smooth things out.
Get more info and the download here: http://www.afp548.com/article.php?story=2
Syndicate
