With Yosemite in beta, it’s worth mentioning that older versions of OS X Server are still available on the app store, if you just know where to look. You can access and purchase other versions using these links:
Server 1: If you already own OS X Lion Server from the app store then you can still access it under Purchases.
krypted June 1st, 2014
Posted In: Mac OS X Server
Now that we’ve looked at what you get and what you don’t get in Mountain Lion Server, let’s take a little while to look at what the upgrade path itself looks like. Before we start, let’s just say that upgrading to Mountain Lion Server is probably one of the fastest, easiest and most boring upgrades you’ll ever get to do. And I say this more to the credit of the engineers that made the process so simple. Apparently there are bonuses to your Server just being an app. There is a catch, some of the services are gone. Another catch, you’re gonna’ need to have a system that meets the following specs:
Apple’s official specs are here, outlining the models that Mountain Lion can run on. If Mountain Lion can run, OS X Server can run on it. Next, make a clone of your computer. I use Carbon Copy Cloner, like most sane people, but YMMV with other tools that you may be in love with. Once your clone is done, I personally like to do both an archive and an export of user accounts from Workgroup Manager as a final safety net. You should also have a book. Preferably one of mine, although given that the merging of two such boring topics can create a black hole of boringness (which is similar to turning a bag of holding inside out, btw), you might choose to bring something a bit livelier than either of the two, like some Dostoyevsky or the Chem 111 textbook I used in college.
Next, let’s go to the App Store. Search for Mountain Lion or OS X and then click the Install button for the Mountain Lion app. The button will then say Downloading, as follows:
Once downloaded, make sure your users won’t chase after you with pitchforks for being down for a couple of hours and then run the installer, following the defaults until the download begins and the system reboots. The installation will take a little while. From the time you start the download to the time that the files are unpacked and replaced on the system can be about an hour or two. This is a good time to grab that book, a bag of Doritos and a Dr. Pepper. Once the Doritos are gone, wash your hands and check the progress of the installation. Read some more. Once that’s done, check the progress again. If you think about a second bag of Doritos, stop – it’s not worth it… A second Dr. Pepper is fine though, I hear it helps you write articles about upgrading to Mountain Lion Server in a way that makes optimal sense.
Once the system reboots again, you should be ready to open Server app. Except for the fact that it isn’t there, which is obvious by the fact that it’s got a big annoying white circle over it in the Dock. Remove the Server app (and Workgroup Manager or Server Admin if they’re in there) and then it’s time to install Server itself.
Go back to the App Store and search for & buy Mountain Lion Server (or install these from Purchases if you’ve already purchased them). Once installed, Server appears in the Dock. Use the following command to verify that the IP address and hostname match:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/changeip -checkhostname
Provided that the name of the server checks out clean, click on the Server app in the Dock to be guided through the installation process.
At the Setup Your Server screen, click on Continue.
Agree to the licensing terms (assuming you do agree) by clicking on the Agree button.
Provide the administrative username and password to give Server and services permission upon installation and then click on the Allow button.
At the Apple Push Notifications screen, provide the Apple ID and password for a valid Apple ID and then click on the Continue button.
After a time, you should see a Congratulations screen. Click on Finish and the Server app should automatically open (or the process fails but Server opens anyway, just without some of the stuff working out of the gate).
At this point, you should see the services that were running prior to the upgrade running. Check the logs to verify that there’s nothing out of the ordinary. If you were running a firewall then the rules will be migrated and continue running. To disable if you’re going to move your rules to pf, then use the following command to disable the rules and reboot:
sudo mv /etc/ipfilter /etc/ipfilter.OLD
You don’t need to disable these immediately, although a lack of control over them might cause you to want to… Next, install Workgroup Manager, available at http://support.apple.com/kb/DL1567. You’ve now got a functional server, provided that the entire process went smoothly. In my experience so far (there hasn’t been a ton of this at this point), the service migration is far smoother than from within the Lion Server point releases (e.g. 10.7.2 to 10.7.3, etc). Profile Manager, for example, worked like a charm on upgrade, as did Calendar and Contacts services, which had been a bit persnickety at times previously.
Now, you can get back to that book and instead of a 3rd Dr. Pepper, switch to Jägermeister!
krypted July 28th, 2012
According to Wikipedia, fsevents is an API from Apple that allows applications to register for notifications of changes to a given directory tree. This means that when something changes, an application (or daemon/agent) can see the change and take action or track what happened. For Linux, there’s a similar tool in iNotify.
This time of the year, a lot of imaging and packaging is going on at schools and companies around the world. A lot of people are also moving various settings out of images and into either post-flight packages, automations or managed preferences of some sort. In OS X, it’s easy to make a change on a computer and then isolate what files the change touched. Therefore, you can quickly and easily figure out what changes to make (e.g. to a property list via a management profile if you’re getting away from Managed Preferences or even to a configuration file).
One tool that can help you discover what files were changed on a system is fseventer. This small donateware app is easy to use and quickly informative. To use it, just open and click on the play button at the empty screen.
Once the tool starts running it will show you what’s changing in the background on the computer. Now make the changes that you need to make and click on the pause button.
Click on the middle button beside the play/pause button and you’ll also
Looking at the files changed then tells you what the changes are. Toggling changes back and forth and looking at the impact on the file results in knowing the changes to script/automate/profile manage for each.
You will encounter tons of apps that write generated keys here and there rather than easy to find settings such as what you see above. In those cases there are almost always command line interfaces specifically developed for changing a setting. For example, networksetup should be used to change settings that would otherwise be configured in the Network System Preference pane. This is only one of about 1,000,000,000 ways I’ve seen to do this. Happy to invite others to comment on their favorite way to track what’s changing and script it in OS X and other platforms as well.
krypted July 12th, 2012
JAMF has announced the 2012 rendition of their National User Conference. Having been to two of these, I can say that if you use any JAMF products that it is a great event to attend. It is a lot of very specific information about integrating, mass deploying, mass managing, mass document distributing and mass 3rd partying for Apple products.
The National User Conference will be held October 23-25 2012, 8:00 am – 5:00 pm in beautiful Minneapolis, Minnesota (where all the cool kids live). The venue is one of the best conference spots I’ve seen in the Guthrie theater, overlooking the stone arch bridge. In previous years, there have been announcements, new versions, people discussing their specific integrations, etc. I would also think that if you use another product that you might find the conference helpful, as you get to see whether the grass really is greener on the other side!
Anyway, I recommend coming out to Minneapolis for this one if you can. And if you do, let me know!
krypted June 18th, 2012
Earlier, I wrote an article on enabling some of the settings in SMB that are now unavailable in the GUI, but were still available from the command line. I have now decided to go ahead an document some of the ones for AFP that have been removed during the transition to the Server app. The first to mention is maximum connections. There are a number of reasons that throttling maximum afp connections can be handy. The serveradmin afp setting for it is maxConnections, which by default is set to -1, indicating unlimited. To set this to 500, one would run:
serveradmin settings afp:maxConnections = 500
The second setting to mention is greetings. The default is to send a greeting each time a user connects if one is enabled. I find that just sending the greeting once satisfies the policy most environments would have around such things. I’ve also found that enough environments setup greetings that I’ve had to do this enough times that it’s fresh in my memory. Therefore, to configure, use Server.app to setup a greeting and then run the following command:
serveradmin settings afp:sendGreetingOnce = yes
Another thing that many environments are going to want is activity logs. By default these are disabled. To enable:
serveradmin settings afp:activityLog = yes
And the setting for how frequently to roll those activity logs is gone from the GUI as well. To edit that (let’s just set it to 2 weeks instead of the default of 1 week):
serveradmin settings afp:activityLogTime = 14
The checkboxes for each type of activity to log are gone, so to access each (by default these are all enabled, so enabling the activity log turns them all on, therefore we’ll just disable here, even though as it seems the server team is well aware of, if you use one most use all:
serveradmin settings afp:loggingAttributes:logOpenFork = no
serveradmin settings afp:loggingAttributes:logCreateDir = no
serveradmin settings afp:loggingAttributes:logLogin = no
serveradmin settings afp:loggingAttributes:logLogout = no
serveradmin settings afp:loggingAttributes:logDelete = no
serveradmin settings afp:loggingAttributes:logCreateFile = no
Note: Activity logs are still by IP address rather than userID
Error logs don’t roll (setting of 0), so to set them to do so (again using 14):
serveradmin settings afp:errorLogTime = 14
The disconnect idle users option is also now gone. To enable it:
serveradmin settings afp:idleDisconnectOnOff = yes
This doesn’t edit the tickle time, but then, that was never presented in the GUI anyway (it controls how frequently a client who’s connected via afp checks into the server). To customize the disconnect message:
serveradmin settings afp:idleDisconnectMsg = "Did you fall asleep there bub?"
And of course, you might need to customize the number of hours before a user is considered idle:
serveradmin settings afp:idleDisconnectTime = 1
To globally disable guest access:
serveradmin settings afp:guestAccess = no
And to allow the root user to log into afp:
serveradmin settings afp:allowRootLogin = yes
Finally, to access the masquerade as a user option for administrative accounts, which I’m not sure I like, but which some do:
serveradmin settings afp:attemptAdminAuth = yes
krypted June 9th, 2012
Tags: admin, administrator, AFP, afp settings, diradmin, enable activity log, first attempt, first connection only, lion server, login greeting, logs, Mac OS X Server, masquerade as admin user, missing afp settings, os x lion server, server.app, serveradmin settings afp, set time out, SMB
Thanks to Tedd Kidd for the following article, on automatically managing administrative privileges based on Active Directory groups!
This is a quick and easy way to assign any user to the local admin group in OS X based on their group membership in your Active Directory. This should also work with Open Directory or eDirectory groups if your workstations are bound to those directory services. You’ll need to include this code in the workstation login script so that it runs as root but uses the $@ variable to determine the user that is logging in.
# Set group name to check against
if [ “`/usr/bin/dsmemberutil checkmembership -U $@ -G $groupname`” == “user is a member of the group” ]; then
/usr/bin/dscl . merge /Groups/admin GroupMembership $@
This works in both Snow Leopard and Lion.
If you work for a school (like me) the groupname variable could be changed to staff or teachers, which would allow any staff member or teacher to have admin rights if run on student workstations.
krypted June 4th, 2012
krypted May 20th, 2012
krypted May 14th, 2012