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 4: https://itunes.apple.com/us/app/os-x-server/id883878097?mt=12 Server 3: https://itunes.apple.com/us/app/os-x-server-3.2.2/id714547929?mt=12 Server 2: https://itunes.apple.com/us/app/os-x-server-2.2.5/id537441259?mt=12 Server 1: If you already own OS X Lion Server from the app store then you can still access it under Purchases.
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
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/changeip -checkhostnameProvided 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.OLDYou 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/CollaborationWhen 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 LegalThe 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/LegalWikiTMPNext, 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/LegalWikiTMPNote: 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 wikiThe service can also be stopped, swapping out the start option with a stop option:
sudo serveradmin stop wikiFinally, 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:FileDataPathThe 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 fixPermissionsAlso use the rebuildSearchIndex option with the wikiadmin command to fix any indexing, once the permissions have been repaired:
sudo wikiadmin rebuildSearchIndexAnd 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 resetQuicklooksWhen 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 = 500The 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 = yesAnother thing that many environments are going to want is activity logs. By default these are disabled. To enable:
serveradmin settings afp:activityLog = yesAnd 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 = 14The 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 = 14The disconnect idle users option is also now gone. To enable it:
serveradmin settings afp:idleDisconnectOnOff = yesThis 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 = 1To globally disable guest access:
serveradmin settings afp:guestAccess = noAnd to allow the root user to log into afp:
serveradmin settings afp:allowRootLogin = yesFinally, 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. #!/bin/bash # Set group name to check against groupname=”domain admins” if [ “`/usr/bin/dsmemberutil checkmembership -U $@ -G $groupname`” == “user is a member of the group” ]; then /usr/bin/dscl . merge /Groups/admin GroupMembership $@ fi 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!