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:
Capable of booting a 64-bit kernel, means a 64-bit Intel Core 2 Duo or better
The graphics just keep getting better, so you’ll need an Advanced GPU chipset
The more memory the better, although 2GB is the bare minimum
The more CPU the better, although 8GB of space is required
An Internet connection, or a cached Install Mac OS X Mountain Lion, Server app and Server package – much easier to just have a connection to the Internet…
You should plan on using an Apple ID, although if you don’t supply it at install time, the server can still run
The source computer needs 10.6.8 or 10.7.x
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:
Buy OS X Mountain Lion from the App Store
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.
Set Up Your Server Screen When Installing Mountain Lion Server
At the Setup Your Server screen, click on Continue.
Agree to the Mountain Lion Server Licensing Agreement
Agree to the licensing terms (assuming you do agree) by clicking on the Agree button.
Provide Administrative Credentials When Installing Mountain Lion Server
Provide the administrative username and password to give Server and services permission upon installation and then click on the Allow button.
Configure The AppleID for Push Notifications
At the Apple Push Notifications screen, provide the Apple ID and password for a valid Apple ID and then click on the Continue button.
Congrats, You’re A SysAdmin!
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!
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.
Lion brings with it a few challenges for administrators. One such is migrating the wiki service into the new format. When doing an upgrade in place, the Wiki service is pretty straight forward to upgrade, but in many cases, due to aging hardware, wiki services are moving from an older computer to a newer computer. This can be done in one of two ways. The first is to “migrate” the data by copying the Collaboration folder onto the new system. The second is to “export” and “import” the data. I usually recommend doing a migrate where possible, so we’ll start with that method.
Note: Before getting started, make sure that the directory services side of things is good. If a user or group lookup for an object that owns, edits or has commented on a wiki fails then that wiki probably shouldn’t be migrated. Use the dscl or id commands to confirm that lookups are functioning as intended.
To migrate wikis from one server to another, first copy the Collaboration directory to the new server. In this example, the directory has been dropped onto the desktop of the currently logged in user. To migrate the data once copied, use the wikiadmin command, along with the migration option. The option requires the path to the Collaboration folder, defined with -r, as follows:
sudo wikiadmin migrate -r ~/Desktop/Collaboration
When moving wikis, you can take the opportunity to get rid of a few you don’t want (such as that test wiki from way back when). Or administrators may just choose to move a single wiki to a new server in order to split the load across multiple hosts. When doing so, use the same command as earlier, along with the name of each wiki that is being moved, along with the -g option. For example, if moving the Legal wiki:
sudo wikiadmin migrate -r ~/Desktop/Collaboration -g Legal
The second way of moving wikis around is to export and then import them. To do so, first export wikis on the old server, using the wikiadmin command along with the export option, which requires an –exportPath option and needs to be done, on a wiki-by-wiki basis. So to export that Legal wiki to a file called LegalWikiTMP on the desktop:
sudo wikiadmin export -g Legal --exportPath ~/Desktop/LegalWikiTMP
Next, copy the wiki to the new server and import it, using the import option along with –importPath to identify where the file being imported is located. Using the same location, the command would then be:
sudo wikiadmin import -g Legal --importPath ~/Desktop/LegalWikiTMP
Note: The ability to import a wiki also allows for an API of sorts, as you can programmatically create wikis from other sources. The ability to export also provides a way to move into another wiki tool if you happen to outgrow the options provided in OS X Server and need to move to something more robust.
There is another way to move wikis, using pg_dump, copying the data and then using pg_restore to import the data once you’ve created the tables. This way is, in my opinion, the last resort if the standard wikiadmin commands aren’t working. In my experience, if I’m doing the migration this way then I’ve got other, bigger issues that I need to deal with as well.
These commands work best when the wiki service has been started so that the databases are fully built out. To start the wiki service from the command line, use the serveradmin command instead of the wikiadmin command. The serveradmin command is used with the start option and then wiki is used to indicate the wiki service, as follows:
sudo serveradmin start wiki
The service can also be stopped, swapping out the start option with a stop option:
sudo serveradmin stop wiki
Finally, in a few cases (this is the main reason I’m writing this article), the attachments to wikis don’t come over during a migration. To migrate the files that are used for QuickLook, downloading attachments, etc, use the serveradmin command to locate the directory that these objects are stored in:
sudo serveradmin settings wiki:FileDataPath
The output identifies the directory where these objects are stored. Placing the contents in the same relative path as they are to the output of the same command on the target server usually results in restoring them. Once moved, use the fixPermissions option to repair the permissions of any files from the source (if any changes to account IDs are encountered such as an export/import rather than an archive/restore in OD this can lead to odd issues:
sudo wikiadmin fixPermissions
Also use the rebuildSearchIndex option with the wikiadmin command to fix any indexing, once the permissions have been repaired:
sudo wikiadmin rebuildSearchIndex
And finally use resetQuicklooks to clear any cached Quicklook representations of objects that have been inserted into a wiki and might not display properly using Quicklook (you know you might need to do this if they look fine when downloaded but look bad with Quicklook even though QuickLook on the server can view the files just fine):
sudo wikiadmin resetQuicklooks
When done properly the migration can take awhile. Keep in mind that every tag, every article, every edit to every article and basically everything else is tracked inside the tables that you’re moving. While there might not be a ton of data in the Collaboration directory or in an export, all of the data needs to go to the right location. This can take a little time in environments that have a lot of articles, even if they’re really short articles…
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!
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 = noNote: 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
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.
Thanks to Duong Nguyen for the second user-submitted post on Changing Roundcube Max Attachment Size in Lion Server!
By default, Lion Server’s webmail (Roundcube) has a 5MB max attachment size. The max attachment size is read from php’s “upload_max_filesize” and “post_max_size”. We don’t need to edit php.ini because Lion Server created a .htaccess in Roundcube’s directory that overrides php.ini’s settings.
Please only do this if you are comfortable with the terminal! I start by SSHing to my server as root (or you can open a root terminal).
1. # cd /usr
2. # cd share
3. # cd webmail
4. # vi .htaccess
5. Use your arrow keys to navigate to the end of the 9th and 10th line (“upload_max_filesize” and “post_max_size” respectively)
6. Use your arrow key to highlight the number before M (i.e. 5M)
7. Press i
8. Type 20 (or however large you want) and press delete to remove the 5
9. Press Esc
10. Press :
11. Type x
Now we’re done with the terminal! Restart the Web Server through Server.app, and enjoy your new attachment size!