krypted.com

Tiny Deathstars of Foulness

File Services are perhaps the most important aspect of any server because file servers are often the first server an organization purchases. This has been changing over the past few years, with many a file being hosted by cloud solutions, such as Box, Dropbox, Google Drive, and of course, iCloud. And rightfully so. But many still need a terrestrial server and for predominantly Apple environments, a macOS Server running on Sierra isn’t exactly a bad idea (for many it is, so whatever there). There are a number of protocols built into macOS Server dedicated to serving files, including AFP, SMB and WebDAV. These services, combined comprise the File Sharing service in macOS Server 5.2 running on top of a Sierra Mac.

Note: I’ve got another article looking into FTP a little further but those are basically the services that I’ll stick to here.

File servers have shares. In macOS Server 5.2 (and many other solutions), we refer to these as Share Points. The first step to setting up a file share is to create all of your users and groups (or at least the ones that will get permissions to the shares). This is done in Server app using the Users and Groups entries in the List Pane. Once users and groups are created, open the Server app and then click on the File Sharing service in the SERVICES list in the List Pane. Here, you will see a list of the shares on the server.

screen-shot-2016-09-26-at-9-53-30-pm

If you’re just getting started, let’s go ahead and disable any built-in shares by clicking on the share and then clicking on the minus button (-) while the share is highlighted. When prompted to remove the share, click on the Remove button.

screen-shot-2016-09-26-at-9-54-00-pm

As mentioned, shares can be shared out using different protocols. Next, we’re going to disable SMB for Public, simply as an example. To do so, double-click on Public and then uncheck the SMB protocol checkbox for the share.

screen-shot-2016-09-26-at-9-54-18-pm

When you’ve disabled SMB for the last share, you’ve effectively disabled SMB. Click on the Done button to save the changes to the server. Editing shares is really that easy. Next, we’re going to create a new share for iPads to be able to put their work, above and beyond the WebDAV instance automatically used by the Wiki service. To create the share, first we’re going to create a directory for the share to live in on the computer, in this case in the /Shared Items/iPads directory.

screen-shot-2016-09-26-at-9-55-18-pm

Then from the File Sharing pane in Server app, click on the plus sign (“+”).

screen-shot-2016-09-26-at-9-55-55-pm

At the browse dialog, browse to the location of your iPad directory and then click on the Choose button.

screen-shot-2016-09-26-at-9-56-16-pm

At the File Sharing pane, double-click on the new iPads share. Note that there’s a new checkbox here called “Allow only encrypted connections”. If you check this, you cannot use AFP and WebDAV.

screen-shot-2016-09-26-at-9-56-57-pm

At the screen for the iPads share, feel free to edit the name of the share (how it appears to users) as it by default uses the name of the directory for the name of the share. Then, it’s time to configure who has access to what on the share. Here, use the plus sign (“+”) in the Access section of the pane to add groups that should be able to have permission to access the share. Also, change the groups in the list that should have access by double-clicking on the name of the group and providing a new group name or clicking on the plus sign to add a user or group.

screen-shot-2016-09-26-at-9-57-48-pm

The permissions available in this screen for users that are added are Read & Write, Read Only/Read and Write. POSIX permissions (the bottom three entries) also have the option for No Access, but ACLs (the top entries comprise an Access Control List) don’t need such an option as if there is no ACE (Access Control Entry) for the object then No Access is assumed.

If more granular permissions are required then click on the name of the server in the Server app (the top item in the List Pane) and click on the Storage tab. Here, browse to the directory and click on Edit Permissions.

screen-shot-2016-09-26-at-9-58-28-pm

As can be seen, there are a number of other options that more granularly allow you to control permissions to files and directories in this view. If you make a share a home folder, you can use that share to store a home folder for a user account provided the server uses Open Directory. Once a share has been made an option for home folders it appears in the Server app as an available Home Folder location for users in that directory service.

Once you have created all the appropriate shares, deleted all the shares you no longer need and configured the appropriate permissions for the share, click on the ON button to start the File Sharing service.

screen-shot-2016-09-26-at-9-59-28-pm

To connect to a share, use the Connect to Server dialog, available by clicking Connect to Server in the Go menu. A change that happened back in Mavericks is that when you enter an address, the client connects over SMB by default (which is even better now that those connections can be encrypted). If you’d like to connect via AFP ‘cause you’re all old school, enter afp:// in front of the address and then click Connect.

The File Sharing service can also be controlled from the command line. Mac OS X Server provides the sharing command. You can create, delete and augment information for share points using sharing. To create a share point for AFP you can use the following command:

sharing -a <path> -A <share name>

So let’s say you have a directory at /Shares/Public and you want to create a share point called PUBLIC. You can use the following command:

sharing -a /Shares/Public -A PUBLIC

Now, the -a here will create the share for AFP but what if you want to create a share for other protocols? Well, -F does FTP and -S does SMB. Once created you can disable the share using the following command:

sharing -r PUBLIC

To then get a listing of shares you can use the following command:

sharing -l

You can also use the serveradmin command to manage file shares as well as the sharing service. To see settings for file shares, use the serveradmin command along with the settings option and then define the sharing service:

sudo serveradmin settings sharing

Sharing settings include the following:

sharing:sharePointList:_array_id:/Shared Items/iPads:dsAttrTypeStandard\:GeneratedUID = “54428C28-793F-4F5B-B070-31630FE045AD”
sharing:sharePointList:_array_id:/Shared Items/iPads:smbName = “iPads”
sharing:sharePointList:_array_id:/Shared Items/iPads:afpIsGuestAccessEnabled = no
sharing:sharePointList:_array_id:/Shared Items/iPads:webDAVName = “iPads”
sharing:sharePointList:_array_id:/Shared Items/iPads:smbDirectoryMask = “0755”
sharing:sharePointList:_array_id:/Shared Items/iPads:afpName = “iPads”
sharing:sharePointList:_array_id:/Shared Items/iPads:smbCreateMask = “0644”
sharing:sharePointList:_array_id:/Shared Items/iPads:nfsExportRecord = _empty_array
sharing:sharePointList:_array_id:/Shared Items/iPads:path = “/Shared Items/iPads”
sharing:sharePointList:_array_id:/Shared Items/iPads:smbUseStrictLocking = yes
sharing:sharePointList:_array_id:/Shared Items/iPads:smbIsGuestAccessEnabled = no
sharing:sharePointList:_array_id:/Shared Items/iPads:name = “iPads”
sharing:sharePointList:_array_id:/Shared Items/iPads:smbInheritPermissions = yes
sharing:sharePointList:_array_id:/Shared Items/iPads:ftpName = “iPads”
sharing:sharePointList:_array_id:/Shared Items/iPads:serverDocsIsShared = yes
sharing:sharePointList:_array_id:/Shared Items/iPads:smbIsShared = yes
sharing:sharePointList:_array_id:/Shared Items/iPads:afpIsShared = yes
sharing:sharePointList:_array_id:/Shared Items/iPads:smbUseOplocks = yes
sharing:sharePointList:_array_id:/Shared Items/iPads:webDAVIsShared = yes
sharing:sharePointList:_array_id:/Shared Items/iPads:dsAttrTypeNative\:sharepoint_group_id = “3A1C9DAD-806C-4917-A39F-9317B6F85CCD”
sharing:sharePointList:_array_id:/Shared Items/iPads:mountedOnPath = “/”
sharing:sharePointList:_array_id:/Shared Items/iPads:isIndexingEnabled = yes
sharing:sharePointList:_array_id:/Shares/Public:ftpIsShared = yes
sharing:sharePointList:_array_id:/Shares/Public:smbName = “Public-1”
sharing:sharePointList:_array_id:/Shares/Public:nfsExportRecord = _empty_array
sharing:sharePointList:_array_id:/Shares/Public:afpIsGuestAccessEnabled = no
sharing:sharePointList:_array_id:/Shares/Public:isIndexingEnabled = no
sharing:sharePointList:_array_id:/Shares/Public:dsAttrTypeStandard\:GeneratedUID = “80197252-1BC6-4391-AB00-C00EE64FD4F2”
sharing:sharePointList:_array_id:/Shares/Public:path = “/Shares/Public”
sharing:sharePointList:_array_id:/Shares/Public:smbIsShared = yes
sharing:sharePointList:_array_id:/Shares/Public:afpUseParentOwner = no
sharing:sharePointList:_array_id:/Shares/Public:afpName = “Public-1”
sharing:sharePointList:_array_id:/Shares/Public:smbIsGuestAccessEnabled = no
sharing:sharePointList:_array_id:/Shares/Public:ftpIsGuestAccessEnabled = no
sharing:sharePointList:_array_id:/Shares/Public:afpUseParentPrivs = no
sharing:sharePointList:_array_id:/Shares/Public:afpIsShared = yes
sharing:sharePointList:_array_id:/Shares/Public:name = “Public-1”
sharing:sharePointList:_array_id:/Shares/Public:ftpName = “Public-1”
sharing:sharePointList:_array_id:/Users/krypted/Public:dsAttrTypeStandard\:GeneratedUID = “0D6AF0D1-BA70-4DD4-9256-AC1B51A2761F”
sharing:sharePointList:_array_id:/Users/krypted/Public:smbName = “Public”
sharing:sharePointList:_array_id:/Users/krypted/Public:afpIsGuestAccessEnabled = no
sharing:sharePointList:_array_id:/Users/krypted/Public:webDAVName = “Public”
sharing:sharePointList:_array_id:/Users/krypted/Public:smbDirectoryMask = “0755”
sharing:sharePointList:_array_id:/Users/krypted/Public:afpName = “Public”
sharing:sharePointList:_array_id:/Users/krypted/Public:smbCreateMask = “0644”
sharing:sharePointList:_array_id:/Users/krypted/Public:nfsExportRecord = _empty_array
sharing:sharePointList:_array_id:/Users/krypted/Public:path = “/Users/krypted/Public”
sharing:sharePointList:_array_id:/Users/krypted/Public:smbUseStrictLocking = yes
sharing:sharePointList:_array_id:/Users/krypted/Public:smbIsGuestAccessEnabled = no
sharing:sharePointList:_array_id:/Users/krypted/Public:name = “Public”
sharing:sharePointList:_array_id:/Users/krypted/Public:smbInheritPermissions = yes
sharing:sharePointList:_array_id:/Users/krypted/Public:ftpName = “Public”
sharing:sharePointList:_array_id:/Users/krypted/Public:serverDocsIsShared = yes
sharing:sharePointList:_array_id:/Users/krypted/Public:smbIsShared = no
sharing:sharePointList:_array_id:/Users/krypted/Public:afpIsShared = yes
sharing:sharePointList:_array_id:/Users/krypted/Public:smbUseOplocks = yes
sharing:sharePointList:_array_id:/Users/krypted/Public:dsAttrTypeNative\:sharepoint_group_id = “FF1970EF-0789-49C7-80B5-E9FCABDDBB49”
sharing:sharePointList:_array_id:/Users/krypted/Public:isIndexingEnabled = yes
sharing:sharePointList:_array_id:/Users/krypted/Public:mountedOnPath = “/”

To see settings for the services use the serveradmin command with the settings option followed by the services: afp and smb:

sudo serveradmin settings afp

AFP settings include:

afp:maxConnections = -1
afp:kerberosPrincipal = “afpserver/LKDC:SHA1.66D68615726DE922C1D1760BD2DD45B37E73ADD4@LKDC:SHA1.66D68615726DE922C1D1760BD2DD45B37E73ADD4”
afp:fullServerMode = yes
afp:allowSendMessage = yes
afp:maxGuests = -1
afp:activityLog = yes

October 10th, 2016

Posted In: Mac OS X Server

Tags: , , , , , , , ,

A wiki is a repository of dynamically created and managed content, or content created or edited by multiple users collaboratively. This article is about using the wiki service in OS X Server (the Apple Server app running on 10.10 and 10.11). I reference file services with WebDAV because it is a very nice integration piece that I think a lot of people will find pretty beneficial.

To get started with the Wiki service, first turn it on. This one isn’t heavily dependent on host names (other than being able to access the server from a browser) or directory services (other than being able to authenticate users, but local accounts are perfectly functional) and it doesn’t require the Websites service to be running as well. One should always have good working directory services and host names, still…

To enable the service, open the Server app and click on Wiki in the list of SERVICES in the List Pane.

Screen Shot 2015-09-25 at 9.57.06 PM

There are two configuration options. The first is to select who is able to create wikis. Use the “Wikis can be created by” drop-down list to select “all users” if anyone with an account on the server should be able to create a wiki or “only some users” to bring up the Wiki Creators screen.

Screen Shot 2015-09-25 at 9.57.51 PM

If only some users can create new wikis, use the plus sign (“+”) at the Wiki Creators screen to add users and/or groups to the list of users that can create wikis. Click on OK when all users and groups that can create wikis are added. In a school I would imagine that only teachers or IT staff would be able to create wikis. Once a wiki is created, pages inside the wiki can still be created by non-wiki creators.

The other option available is the handy dandy WebDAV interface to the wikis. When you enable this option, you can connect to a server from OS X or iOS via WebDAV and access files in each wikis document repository. To be clear, this option doesn’t provide access to the user documents, but does provide access to the wiki documents. We’re going to check the box for “Enable WebDAV access to Wiki files” and then click the ON button.

Once the service starts, click on the View Wiki link in the Wiki workspace in Server app.

Screen Shot 2015-09-25 at 10.00.51 PM

Here, click on the Log in button and enter a user with access to the server, preferably one who can create wikis.

Screen Shot 2015-09-25 at 10.01.43 PM

At the Wikis page, you will then see a list of all wikis you have access to. Note that the previous screen showed one wiki and now we see two. That’s because one of the wikis has permissions that allow “All unauthenticated users” access to the wiki, which we’ll describe shortly. The first thing most administrators will do is create a wiki. To do so, click on the plus sign (“+”) icon on the web page and at the resultant screen, click on New Wiki.

Screen Shot 2015-09-25 at 10.02.35 PM

At the “Create a new wiki” prompt, provide a name for the wiki and a brief description for it.

Screen Shot 2015-09-25 at 10.03.12 PM

Click on Continue.

Screen Shot 2015-09-25 at 10.03.53 PM

At the Set permissions screen, enter each user or group to provide access to edit and view wiki pages. Here, you’ll have the options for Read & Write (users can view and edit pages in the wiki), Read only (users can only view the contents of your pages) and No access (users have no access to the wiki). There is a group for All logged in users, which includes every user with access to the server and another for All unauthorized users, which includes guests to the server. Once you’ve given the appropriate permissions, click on Continue.
Note: You don’t have to get this perfect now as you can always edit these later.

Screen Shot 2015-09-25 at 10.04.23 PM

At the Set Appearance screen, you can choose an icon for the wiki (shown in the wiki list and when you open the wiki) as well as a color scheme for the wiki. Choose the appropriate appearance for your wiki (again, you can always change this later) and then click on the Create button.

Screen Shot 2015-09-25 at 10.04.53 PM

Once the setup is finished, you’ll see the Setup complete modal. Here, you can click on Go to Wiki button.

Screen Shot 2015-09-25 at 10.05.33 PM

Once you’ve created your first wiki, let’s edit it and customize the content. To do so, click on it from the list of available wikis. Click on the cog-wheel icon and then Wiki Settings… to bring up the Wiki Settings page.

Screen Shot 2015-09-25 at 10.05.59 PM

Here, you’ll see the previously entered name and description as well as options to enable Calendar (only available if Calendar Server is running on the server) and Blog, which enables  a blog service for the wiki (wiki administrators can post blog entries to the wiki). Click on Appearance.

Screen Shot 2015-09-25 at 10.06.26 PM

Here, you will have the previous two options as well as the ability to upload a banner (which should be 62 pixels high) and background for each wiki.

Screen Shot 2015-09-25 at 10.07.02 PM

Click on Permissions. Here, you’ll see the permissions previously configured as well as options to configure who can comment on articles (nobody disables comments completely) in the wiki and whether comments require approval (moderation).

Click on Save. Now, let’s edit the splash page. To do so, click the pencil icon in the top navigation bar.

Screen Shot 2015-09-25 at 10.07.45 PM

At the edit screen, the top nav bar is replaced by a WYSIWIG editor for managing the page. Here you can justify, link, insert media and of course edit the text you see on the screen. I recommend spending some time embedding links, inserting tables, making text look like you want it to and editing the content to reflect the purpose of the wiki. Click Save when you’re done. Click the pencil again to edit it, and let’s create a new wiki page. Keep in mind that link wikipedia, each page should be linked to from other pages in the order they should be read. Unlike most wikis, there’s actually an index page of all the articles, which can come in handy.

Screen Shot 2015-09-25 at 10.08.34 PM

From the edit page, to create a new page and link to it, enter some text (or lasso some) that you’ll use as the link to access the new page you’re creating. Then click on the arrow and select “New page.”

Note: Use Enter URL to link to an existing page or an external website, instead of creating a new page.

Screen Shot 2015-09-25 at 10.09.03 PM

At the New Page screen, provide a name for the new page (the lasso’d text automatically appears as the Page Title) and click on the Add button.

Screen Shot 2015-09-25 at 10.09.40 PM

Click Save and then click on the newly created link. You can now edit the new page the same way you edited the previous pages. Click on the disclosure triangles in the right sidebar to Comment on articles, link articles to related articles, tag articles and view editing history.

Screen Shot 2015-09-25 at 10.12.44 PM

Now for the fun part. Click on Documents. Here, you’ll see the pages you already created. Click on the plus sign and select the option to Upload File to the wiki.

Screen Shot 2015-09-25 at 10.13.48 PM

At the Upload File dialog, click on Choose File and then select a file to upload.

Screen Shot 2015-09-25 at 10.14.36 PM

Click Upload when selected.

Screen Shot 2015-09-25 at 10.15.35 PM

Then from the Finder of an OS X client, use the Go menu to select “Connect to Server”. Enter the name or IP of the server and then click on Connect.

Assuming you can access the server, you should then be prompted for a username and password. Enter it and click Connect. Eventually, the file(s) will display (it can take awhile according to your network speeds and how many files are in the directory). You can connect to this same screen through an iPad using a 3rd party WebDAV client or the build in options in Pages.

Managing wikis is as easy as its ever been, with the new options for appearance being a nice add-on. Active Directory integration is as easy as binding the server to Active Directory and using the accounts listed in Permissions of pages. Overall, the ability to edit, upload and view documents from the Wiki is a great new feature in OS X Yosemite Server, worthy of checking out if you haven’t already!

Now that iOS devices can edit wikis and many of the traditional word processing options are available in the wiki editor, consider what the Wiki can be. Could it replace text editing apps for iOS? Could the Wiki allow for more collaborative documents than a Word or other document editor? Could it keep from getting eaten like the rest of the homework? Could the comments in the Wiki be a good way for teachers to have students write responses to materials? Could the Wiki and the document management features allow your workers to access human resources documents and employee manuals? I know plenty a tech firm that use wikis to track information about the systems they manage.

Once you have all of this information, upgrading can seem downright scary. But fear not, there’s Carbon Copy Cloner. And once you’ve cloned, there’s wikiadmin. 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


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…

October 9th, 2015

Posted In: Mac OS X Server

Tags: , , , , , ,

I’ve been light on posting here, mostly because I’ve been swamped with work, selling my old house, buying a new house, doing some crazy taxes, wrapping production on a new book and updating the Take Control of OS X Server book to Yosemite Server. Well, earlier this week I sold my house, got the next version of Bushel ready to rock and filed my taxes. Aaaaannnnnndddddd, the Yosemite version of Take Control Of OS X Server is now available at http://tid.bl.it/1xuCJUC.

Screen Shot 2015-02-05 at 2.24.54 PM

Boom. Will get back to my normally scheduled postings shortly!

February 5th, 2015

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , , , , ,

A wiki is a repository of dynamically created and managed content, or content created or edited by multiple users collaboratively. This article is about using the wiki service in Yosemite Server (the Apple Server app running on 10.10). I reference file services with WebDAV because it is a very nice integration piece that I think a lot of people will find pretty beneficial.
To get started with the Wiki service, first turn it on. This one isn’t heavily dependent on host names (other than being able to access the server from a browser) or directory services (other than being able to authenticate users, but local accounts are perfectly functional) and it doesn’t require the Websites service to be running as well. One should always have good working directory services and host names, still…

To enable the service, open the Server app and click on Wiki in the list of SERVICES in the List Pane.

wiki1

There are two configuration options. The first is to select who is able to create wikis. Use the “Wikis can be created by” drop-down list to select “all users” if anyone with an account on the server should be able to create a wiki or “only some users” to bring up the Wiki Creators screen.

wiki2

If only some users can create new wikis, use the plus sign (“+”) at the Wiki Creators screen to add users and/or groups to the list of users that can create wikis. Click on OK when all users and groups that can create wikis are added. In a school I would imagine that only teachers or IT staff would be able to create wikis. Once a wiki is created, pages inside the wiki can still be created by non-wiki creators.

The other option available is the handy dandy WebDAV interface to the wikis. When you enable this option, you can connect to a server from OS X or iOS via WebDAV and access files in each wikis document repository. To be clear, this option doesn’t provide access to the user documents, but does provide access to the wiki documents. We’re going to check the box for “Enable WebDAV access to Wiki files” and then click the ON button.

Once the service starts, click on the View Wiki link in the Wiki workspace in Server app.

wiki3

Here, click on the Log in button and enter a user with access to the server, preferably one who can create wikis.

wiki4

At the Wikis page, you will then see a list of all wikis you have access to. Note that the previous screen showed one wiki and now we see two. That’s because one of the wikis has permissions that allow “All unauthenticated users” access to the wiki, which we’ll describe shortly. The first thing most administrators will do is create a wiki. To do so, click on the plus sign (“+”) icon on the web page and at the resultant screen, click on New Wiki.

wiki5

At the “Create a new wiki” prompt, provide a name for the wiki and a brief description for it.

wiki6

Click on Continue.

wiki7

At the Set permissions screen, enter each user or group to provide access to edit and view wiki pages. Here, you’ll have the options for Read & Write (users can view and edit pages in the wiki), Read only (users can only view the contents of your pages) and No access (users have no access to the wiki). There is a group for All logged in users, which includes every user with access to the server and another for All unauthorized users, which includes guests to the server. Once you’ve given the appropriate permissions, click on Continue.
Note: You don’t have to get this perfect now as you can always edit these later.

wiki8

At the Set Appearance screen, you can choose an icon for the wiki (shown in the wiki list and when you open the wiki) as well as a color scheme for the wiki. Choose the appropriate appearance for your wiki (again, you can always change this later) and then click on the Create button.

wiki9

Once the setup is finished, you’ll see the Setup complete modal. Here, you can click on Go to Wiki button.

wiki10

Once you’ve created your first wiki, let’s edit it and customize the content. To do so, click on it from the list of available wikis. Click on the cog-wheel icon and then Wiki Settings… to bring up the Wiki Settings page.

wiki11

Here, you’ll see the previously entered name and description as well as options to enable Calendar (only available if Calendar Server is running on the server) and Blog, which enables  a blog service for the wiki (wiki administrators can post blog entries to the wiki). Click on Appearance.

wiki12

Here, you will have the previous two options as well as the ability to upload a banner (which should be 62 pixels high) and background for each wiki.

wiki13

Click on Permissions. Here, you’ll see the permissions previously configured as well as options to configure who can comment on articles (nobody disables comments completely) in the wiki and whether comments require approval (moderation).

Click on Save. Now, let’s edit the splash page. To do so, click the pencil icon in the top navigation bar.

wiki14

At the edit screen, the top nav bar is replaced by a WYSIWIG editor for managing the page. Here you can justify, link, insert media and of course edit the text you see on the screen. I recommend spending some time embedding links, inserting tables, making text look like you want it to and editing the content to reflect the purpose of the wiki. Click Save when you’re done. Click the pencil again to edit it, and let’s create a new wiki page. Keep in mind that link wikipedia, each page should be linked to from other pages in the order they should be read. Unlike most wikis, there’s actually an index page of all the articles, which can come in handy.

Wiki15

From the edit page, to create a new page and link to it, enter some text (or lasso some) that you’ll use as the link to access the new page you’re creating. Then click on the arrow and select “New page.”

Note: Use Enter URL to link to an existing page or an external website, instead of creating a new page.

Wiki16

At the New Page screen, provide a name for the new page (the lasso’d text automatically appears as the Page Title) and click on the Add button.

wiki17

Click Save and then click on the newly created link. You can now edit the new page the same way you edited the previous pages. Click on the disclosure triangles in the right sidebar to Comment on articles, link articles to related articles, tag articles and view editing history.

wiki18

Now for the fun part. Click on Documents. Here, you’ll see the pages you already created. Click on the plus sign and select the option to Upload File to the wiki.

wiki19

At the Upload File dialog, click on Choose File and then select a file to upload.

wiki20

Click Upload when selected.

wiki21

Then from the Finder of an OS X client, use the Go menu to select “Connect to Server”. Enter the name or IP of the server and then click on Connect.

Assuming you can access the server, you should then be prompted for a username and password. Enter it and click Connect. Eventually, the file(s) will display (it can take awhile according to your network speeds and how many files are in the directory). You can connect to this same screen through an iPad using a 3rd party WebDAV client or the build in options in Pages.

Managing wikis is as easy as its ever been, with the new options for appearance being a nice add-on. Active Directory integration is as easy as binding the server to Active Directory and using the accounts listed in Permissions of pages. Overall, the ability to edit, upload and view documents from the Wiki is a great new feature in OS X Yosemite Server, worthy of checking out if you haven’t already!

Now that iOS devices can edit wikis and many of the traditional word processing options are available in the wiki editor, consider what the Wiki can be. Could it replace text editing apps for iOS? Could the Wiki allow for more collaborative documents than a Word or other document editor? Could it keep from getting eaten like the rest of the homework? Could the comments in the Wiki be a good way for teachers to have students write responses to materials? Could the Wiki and the document management features allow your workers to access human resources documents and employee manuals? I know plenty a tech firm that use wikis to track information about the systems they manage.

Once you have all of this information, upgrading can seem downright scary. But fear not, there’s Carbon Copy Cloner. And once you’ve cloned, there’s wikiadmin. 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


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…

October 16th, 2014

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , , , , , , ,

A wiki is a repository of dynamically created and managed content, or content created or edited by multiple users collaboratively. This article is about using the wiki service in Mountain Lion. I reference file services with WebDAV because it is a very nice integration piece that I think a lot of people will find pretty beneficial.

To get started with the Wiki service, first turn it on. This one isn’t heavily dependent on host names (other than being able to access the server from a browser) or directory services (other than being able to authenticate users, but local accounts are perfectly functional) and it doesn’t require the Websites service to be running as well. One should always have good working directory services and host names, still…

To enable the service, open the Server app and click on Wiki in the list of SERVICES in the List Pane.

There are two configuration options. The first is to select who is able to create wikis. Use the “Wikis can be created by” drop-down list to select “all users” if anyone with an account on the server should be able to create a wiki or “only some users” to bring up the Wiki Creators screen.

If only some users can create new wikis, use the plus sign (“+”) at the Wiki Creators screen to add users and/or groups to the list of users that can create wikis. Click on OK when all users and groups that can create wikis are added. In a school I would imagine that only teachers or IT staff would be able to create wikis. Once a wiki is created, pages inside the wiki can still be created by non-wiki creators.

The other option available is the handy dandy WebDAV interface to the wikis. When you enable this option, you can connect to a server from OS X or iOS via WebDAV and access files in each wikis document repository. To be clear, this option doesn’t provide access to the user documents, but does provide access to the wiki documents. We’re going to check the box for “Enable WebDAV access to Wiki files” and then click the ON button.

Once the service starts, click on the View Wiki link in the Wiki workspace in Server app.

Here, click on the Log in button and enter a user with access to the server, preferably one who can create wikis.

At the Wikis page, you will then see a list of all wikis you have access to. Note that the previous screen showed one wiki and now we see two. That’s because one of the wikis has permissions that allow “All unauthenticated users” access to the wiki, which we’ll describe shortly.

The first thing most administrators will do is create a wiki. To do so, click on the plus sign (“+”) icon on the web page and at the resultant screen, click on New Wiki.

At the “Create a new wiki” prompt, provide a name for the wiki and a brief description for it.

Click on Continue.

At the Set permissions screen, enter each user or group to provide access to edit and view wiki pages. Here, you’ll have the options for Read & Write (users can view and edit pages in the wiki), Read only (users can only view the contents of your pages) and No access (users have no access to the wiki). There is a group for All logged in users, which includes every user with access to the server and another for All unauthorized users, which includes guests to the server. Once you’ve given the appropriate permissions, click on Continue.

Note: You don’t have to get this perfect now as you can always edit these later.

At the Set Appearance screen, you can choose an icon for the wiki (shown in the wiki list and when you open the wiki) as well as a color scheme for the wiki. Choose the appropriate appearance for your wiki (again, you can always change this later) and then click on the Create button.

Once you’ve created your first wiki, let’s edit it and customize the content. To do so, click on it from the list of available wikis. Click on the cog-wheel icon and then Wiki Settings… to bring up the Wiki Settings page.

Here, you’ll see the previously entered name and description as well as options to enable Calendar (only available if Calendar Server is running on the server) and Blog, which enables  a blog service for the wiki (wiki administrators can post blog entries to the wiki). Click on Appearance.

Here, you will have the previous two options as well as the ability to upload a banner (which should be 62 pixels high) and background for each wiki.

Click on Permissions. Here, you’ll see the permissions previously configured as well as options to configure who can comment on articles (nobody disables comments completely) in the wiki and whether comments require approval (moderation).

Click on Save. Now, let’s edit the splash page. To do so, click the pencil icon in the top navigation bar.

At the edit screen, the top nav bar is replaced by a WYSIWIG editor for managing the page. Here you can justify, link, insert media and of course edit the text you see on the screen. I recommend spending some time embedding links, inserting tables, making text look like you want it to and editing the content to reflect the purpose of the wiki. Click Save when you’re done. Click the pencil again to edit it, and let’s create a new wiki page. Keep in mind that link wikipedia, each page should be linked to from other pages in the order they should be read. Unlike most wikis, there’s actually an index page of all the articles, which can come in handy.

From the edit page, to create a new page and link to it, enter some text (or lasso some) that you’ll use as the link to access the new page you’re creating. Then click on the arrow and select “New page.”

Note: Use Enter URL to link to an existing page or an external website.

At the New Page screen, provide a name for the new page (the lasso’d text automatically appears as the Page Title) and click on the Add button.

Click Save and then click on the newly created link. You can now edit the new page the same way you edited the previous pages. Click on the disclosure triangles in the right sidebar to Comment on articles, link articles to related articles, tag articles and view editing history.

Now for the fun part. Click on Documents. Here, you’ll see the pages you already created. Click on the plus sign and select the option to Upload File to the wiki.

At the Upload File dialog, click on Choose File and then select a file to upload. Click Upload when selected.

Then from the Finder of an OS X client, use the Go menu to select “Connect to Server”. Enter the name or IP of the server and then click on Connect.

Assuming you can access the server, you should then be prompted for a username and password. Enter it and click Connect.

Eventually, the file(s) will display. You can connect to this same screen through an iPad using a 3rd party WebDAV client or the build in options in Pages.

Managing wikis is as easy as its ever been, with the new options for appearance being a nice add-on. Active Directory integration is as easy as binding the server to Active Directory and using the accounts listed in Permissions of pages. Overall, the ability to edit, upload and view documents from the Wiki is a great new feature in OS X Mountain Lion Server, worthy of checking out if you haven’t already!

August 7th, 2012

Posted In: Mac OS X Server

Tags: , , , , , , , , , , ,

Mail is one of the hardest services to manage. Actually, mail is pretty simple in and of itself: there’s protocols people use to access their mail (such as IMAP and POP), protocols used to communicate between mail servers and send mail (SMTP, SMTPS)  and then there’s a database of mail and user information. In Mount Lion Server, all of these are represented by a single ON button, so it really couldn’t be easier. But then there’s the ecoysystem and the evil spammers.

As a systems administrator of a large number of mail servers, I firmly believe that there is a special kind of hell where only spam is served at every meal for spammers. Here, the evil spammers must also read every piece of spam ever sent for eternity. By the end (aka Ragnarok), they should be fairly well hung, have chemically induced stamina of a 16 year old with the latest Sports Illustrated Swimsuit issue, enough pills of other types to not be able to use that stamina, plenty of African princes looking to donate large sums of money if only they can be helped out of their country (which should cost about 100,000 compared to a 5,000,000 payout, not a bad ROI, right?!?!?), have their conflicting stamina situation at the top of the search engines and of course, have lost all of the money made from their African princes due to getting their credit card hijacked by about 9,000 phishing scams. All in all, a special kind of hell…

But back to the point of the article, setting up mail… The things that mail administrators need to focus on to keep that mail server flowing mail to and from everyone else in the world:

  • Static IP address. The WAN (and LAN probably) address should be static.
  • Port Forwards. Port forwards need to be configured on the gateway for the SMTP port at a minimum and more than likely other ports used to access mail on client devices (25, 143, etc)
  • DNS records. An MX record and some kind of mail.domain.com type of record should definitely be configured for the DNS servers that are authoritative for the domain. There should also be reverse records for the address of the server, usually created by the Internet Services Provider, or ISP, that match that record.
  • Check the RBLs. If you have a new IP address you’ll be putting a DNS server on, check all the major Realtime BlackLists to make sure that some evil spammer hasn’t squatted on the IP before you got to it. This is true whether you’re in a colo, hosted on an IP you own or moving into space formerly occupied by a very standup company. A lot of IP addresses are blocked, as are blocks of IPs, so before moving mail to an IP, check it.
  • Mail filtration (message hygiene). OS X Server has a number of mail filters built in, including clam for viruses, the ability to leverage RBLs, block specific addresses and of course RBL checking. However, this is often not enough. Third party services such as MXLogic help to keep mail from coming into your network. You also end up with an external IP to send mail that can cache mail in the event the server is down and keep mail off your network in the event that it’s spam.
  • Backup. I am firmly of the belief that I’d rather not have data than not have that data backed up…

Once all of that is taken care of (I’ll add more as I think about it) then it’s time to enable the mail service. Actually, first let’s setup our SSL certificates. To do so, open the Server app and click on the name of the server in the HARDWARE section of the sidebar. Then click on the Settings tab and then the Edit button beside the SSL Certificate entry. Here, use the Certificate drop-down list for each protocol to select the appropriate certificate to be used for the service.

Click OK when they’re all configure. Now let’s enable the mail service (or outsource mail). To do so, open the Server app and click on Mail in the SERVICES list in the sidebar.

At the configuration screen is a sparse number of settings:

  • Provide mail for: Configures all of the domains the mail server will listen for mail for. Each account on the server has a short name and each domain name will be available for each short name. For example, an account with a shortname of charles will be available for email addresses of charles@pretendco.com and charles@krypted.com per the Domain Name listing below.
  • Authentication: Click Edit for a list of sources that accounts can authenticate against (e.g. Active Directory, Open Directory, Custom, Local, etc) and in some cases the specific password algorithms used for mail.
  • Relay outgoing mail through ISP: Provide a server that all mail will get routed through from the server. For example, this might be an account with your Internet Services Provider (ISP), an account on an appliance that you own (such as a Barracuda) or with an external filtering service (such as MXLogic).
  • Limit mail to: Configure the total amount of mail a user can have in the mail store, in Megabytes.
  • Edit Filtering Settings: Configure antivirus, spam assassin and junk mail filters. The “Enable virus filtering” checkbox enables clam. The “Enable blacklist filtering” checks the RBL (or RBLs) of your choice to check whether a given server is a “known” spammer and the “Enable junk mail filtering” option enables spam assassin on the host, configuring it to block based on a score as selected using the slider.

Once you’ve configured the settings for the Mail service, click on the ON slider to enable the service. At this point, you should be able to telnet into port 25 of the host to verify that SMTP is listening, preferably from another mail server:

telnet mail.krypted.com 25

You can also check that the mail services are running using the serveradmin command along with the fullstatus option for the mail service:

sudo serveradmin fullstatus mail

Which returns with some pretty verbose information about the service, including state, connections, running protocols and the rest of the following:

mail:setStateVersion = 1
mail:readWriteSettingsVersion = 1
mail:connectionCount = 0
mail:servicePortsRestrictionInfo = _empty_array
mail:protocolsArray:_array_index:0:status = "ON"
mail:protocolsArray:_array_index:0:kind = "INCOMING"
mail:protocolsArray:_array_index:0:protocol = "IMAP"
mail:protocolsArray:_array_index:0:state = "RUNNING"
mail:protocolsArray:_array_index:0:error = ""
mail:protocolsArray:_array_index:1:status = "ON"
mail:protocolsArray:_array_index:1:kind = "INCOMING"
mail:protocolsArray:_array_index:1:protocol = "POP3"
mail:protocolsArray:_array_index:1:state = "RUNNING"
mail:protocolsArray:_array_index:1:error = ""
mail:protocolsArray:_array_index:2:status = "ON"
mail:protocolsArray:_array_index:2:kind = "INCOMING"
mail:protocolsArray:_array_index:2:protocol = "SMTP"
mail:protocolsArray:_array_index:2:state = "RUNNING"
mail:protocolsArray:_array_index:2:error = ""
mail:protocolsArray:_array_index:3:status = "ON"
mail:protocolsArray:_array_index:3:kind = "OUTGOING"
mail:protocolsArray:_array_index:3:protocol = "SMTP"
mail:protocolsArray:_array_index:3:state = "RUNNING"
mail:protocolsArray:_array_index:3:error = ""
mail:protocolsArray:_array_index:4:status = "ON"
mail:protocolsArray:_array_index:4:kind = "INCOMING"
mail:protocolsArray:_array_index:4:protocol = "Junk_mail_filter"
mail:protocolsArray:_array_index:4:state = "STOPPED"
mail:protocolsArray:_array_index:4:error = ""
mail:protocolsArray:_array_index:5:status = "ON"
mail:protocolsArray:_array_index:5:kind = "INCOMING"
mail:protocolsArray:_array_index:5:protocol = "Virus_scanner"
mail:protocolsArray:_array_index:5:state = "STOPPED"
mail:protocolsArray:_array_index:5:error = ""
mail:startedTime = "2012-07-30 18:14:26 +0000"
mail:logPaths:IMAP Log = "/Library/Logs/Mail/mailaccess.log"
mail:logPaths:Server Log = "/Library/Logs/Mail/mailaccess.log"
mail:logPaths:POP Log = "/Library/Logs/Mail/mailaccess.log"
mail:logPaths:SMTP Log = "/var/log/mail.log"
mail:logPaths:Migration Log = "/Library/Logs/MailMigration.log"
mail:logPaths:Virus Log = "/Library/Logs/Mail/clamav.log"
mail:logPaths:Amavisd Log = "/Library/Logs/Mail/amavis.log"
mail:logPaths:Virus DB Log = "/Library/Logs/Mail/freshclam.log"
mail:imapStartedTime = "2012-07-30 18:14:26 +0000"
mail:servicePortsAreRestricted = "NO"
mail:state = "RUNNING"
mail:postfixStartedTime = "2012-07-30 18:14:49 +0000"

To stop the service:

sudo serveradmin stop mail

And to start it back up:

sudo serveradmin start mail

To configure some of the settings no longer in the GUI from previous versions, let’s look at the full list of options:

sudo serveradmin settings mail

One that is commonly changed is the subject line added to messages that are marked as spam by spam assassin. This is stored in mail:postfix:spam_subject_tag, so changing would be:

sudo serveradmin settings mail:postfix:spam_subject_tag = "***DIEEVILSPAMMERSDIE*** "

A number of admins also choose to disable greylisting, done using the mail:postfix:greylist_disable option:

sudo serveradmin settings mail:postfix:greylist_disable = no

To configure an email address for quarantined mail to go, use mail:postfix:virus_quarantine:

sudo serveradmin settings mail:postfix:virus_quarantine = "diespammersdie@krypted.com"

The administrator, by default, doesn’t get an email when an email containing a file infected with a virus is sent through the server. To enable this option:

sudo serveradmin settings mail:postfix:virus_notify_admin = yes

I also find a lot of Mac environments want to accept email of pretty much any size. By default, message size limits are enabled. To disable:

sudo serveradmin settings mail:postfix:message_size_limit_enabled = yes

Or even better, just set new limit:

sudo serveradmin settings mail:postfix:message_size_limit = 10485760

And to configure the percentage of someone’s quota that kicks an alert (soft quota):

sudo serveradmin settings mail:imap:quotawarn = 75

Additionally, the following arrays are pretty helpful, which used to have GUI options:

  • mail:postfix:mynetworks:_array_index:0 = “127.0.0.0/8” – Add entries to this one to add “local” clients
  • mail:postfix:host_whitelist = _empty_array – Add whitelisted hosts
  • mail:postfix:blacklist_from = _empty_array – Add blacklisted hosts
  • mail:postfix:black_hole_domains:_array_index:0 = “zen.spamhaus.org” – Add additional RBL Servers

The client side of the mail service is straight forward enough. If you are wondering where in this article we discuss using webmail, er, that’s not installed by default any longer. But the open source project previously used, roundcube, is still available for download and easily installed (the pre-reqs are all there, already). Check out the roundcube wiki installation page here for more info on that. Also, mail groups. I hope to have a post about that soon enough. Unless, of course, I get sidetracked with having a life. Which is arguably not very likely…

July 31st, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security

Tags: , , , , , , , , , , , ,

Mountain Lion Server is now available on the OS X App Store and as with the last few updates there are some things missing that you might be expecting and depending on. First up, three major services are gone: Podcast Producer, RADIUS and dhcp. You can still do dhcp as you always did with OS X client as those features work on OS X Server, but the more granular controls available in OS X Server are now gone. The biggest impact of dhcp is probably in testing NetBoot services when there are network issues and you need to prove to network admins that it’s the network and not your server…

I had written an article before about FTP still being in OS X Server from the command line, but now it’s back in the GUI, which should make many an administrator happy. NAT is also gone from the GUI, but natd and natutil are still available from the command line. Might as well just use the Sharing System Preference pane for such things though… Server Admin is now gone (long live Server Admin!) and Workgroup Manager is now a download to be performed and installed following installation. Support for Managed Preferences is gone, even though most manifests technically still work.

Many services also got some pretty nice updates. These include:

  • Calendar – There are a few updates on the client side, but not on the server side. Most notably, the option to publish calendars is now gone. If you used that, it’s time to get used to manually exporting, copying to a share and then distributing links. This is going to likely cause more use of the Calendar server itself, to some degree. Also, it’s not iCal or iCal Server, it’s now Calendar and Calendar server. Seems to me that this isn’t obviously an Apple-centric naming structure as with most other things they do, but sometimes you’re gonna’ have that…
  • Contacts – Nope, it’s not called Address Book server, it’s the Contacts service. Same with the client side application.
  • DNS – DNS management is moved into the Server application. You can also now restrict who you do lookups for in the GUI. Under the hood very little changes.
  • File Sharing – Nothing really changes with file sharing, except the wiki integration described in the Wiki section in a little bit.
  • Firewall – The firewall option is gone, as is the ipfilter at the command line, but pf is easy to configure from the command line.
  • FTP – It’s a quick and easy single share solution from the GUI. Using the sharing command there’s still tons available to administrators.
  • Mail – Authentication mechanisms and domains are in the GUI, but very little changes otherwise.
  • Messages – The service name has changed from iChat to Messages in the GUI but is still jabber from the command line. The big change with this service is that the client side is now able to leverage iCloud to instant message mobile devices as well. Therefore, the text messaging component is client-side and has no impact on the jabber service itself.
  • NetInstall – The “NetInstall” service is NetBoot. It can host NetRestore or NetInstall images, but the heavy lifting for that stuff is done in System Image Utility. And the output of the SIU commands are now more scriptable through the automator command line interface. The NetInstall screen is now in Server app and is a good port from Server Admin in that it’s similar in look and feel to the NetBoot screen in Server Admin. A feature that isn’t in the GUI is diskless NetBoot, which is fine because I documented how to do it when I realized it would be an issue for a few customers.
  • Open Directory – Given that Server Admin is gone, something had to happen with Open Directory. The Open Directory screens have been moved to Server app where it’s fast to setup and tear down Open Directory. Open Directory based Users and Groups are also created through the Server App, although Workgroup Manager can be downloaded and used still. Immediately following upgrades, the add and remove users buttons are gone for previously stand-alone hosts. Also the Manage Network Accounts option is now gone from Server app, replaced with the traditional ON button supplied by Apple for other services.
  • Profile Manager – This deserves its own post, which is in the queue, but suffice it to say that while you can’t tell when looking in Server app, there are a number of upgrades to Profile Manager.
  • Software Update – Management of the service is moved from Server Admin to Server app. There are now fewer options in the GUI, but the same in the command line. Cascading is a little different.
  • Time Machine – Time Machine server is the same… The versions option from the Time Machine Server preference pane is gone and the layout is a little changed, but the server component is identical in functionality as well as look and feel.
  • VPN – Unless you add another supported VPN protocol there’s not much to do after fixing most issues in 10.7.4. Except fixing the last issue with search bases, seemingly resolved as it’s working for me pretty well.
  • Websites – There are more options in the GUI for new sites. The default site appears twice (once for 80 and once for 443), but there are more options, such as the Web App functionality that comes with a default Python “Hello World” app. Also the server is still called web from the serveradmin command line, but is now called Websites through the GUI.
  • Wiki – The wiki has themes again, although they’re just color schemes. And you can create your own custom banners and upload, which brings back two of the most common feature requests from people that hack the look and feel of the wiki in versions previous to Lion. But the most substantial aspect of the Wiki to change to me is the document management options, available to users in WebDAV or through the portal. This allows for a very mobile-friendly file management tool. Blogs and wikis for the most part stay the same and have a very clean upgrade process from Lion. The command line tools also feature some new options for indexing, etc., which many will find helpful.
  • Xsan – cvadmin, cvlabel, cvversions, etc are now stored in /System/Library/Filesystems/acfs.fs/Contents/bin/ and Xsan has its own entry in the Server app. Despite hearing people question its future, I’ve never seen as many questions flying around about how to do things with Xsan than I do now. Storage sales are up, monkey chatter on the web is up, deployments are being booked and Xsan looks here to stay. The Server app only really shows you a status of things, but the Xsan Admin app is now embedded in the Server app and available through the Server app Tools directory.

Configuring Websites in Server app

The Alerts options are much more robust in Mountain Lion than they were previously. You  can now get alerts on a myriad of things, incuding certs, disks, space, storage quotas, virus detection, network changes and software updates.

Configuring Alerts in Mountain Lion Server

The Server commands also moved and in fact the whole file and folder structure mostly fit nicely inside of the Server app. There are certain things that haven’t been dealt with in this regard such as NetBoot’s library, but for the most part Apple is getting Server to the point where it’s very self-contained. The ramification of which is that upgrades for future releases (and from Lion to Mountain Lion for that matter) are much simpler. Simply downloading a new version informs administrators that the app has been replaced and is good to go, service data in tact. In real world, this has been a little hit or miss but should prove to make our lives much easier in the future.

Reducing scope, aligning with better development practices and all the work to merge all of the remaining services into Server app are huge undertakings. I would fully expect no further support or updates to Workgroup Manager, no more testing of managed preferences in deference to profiles and a few other culture shifts that still need to shake themselves out. Most of us are going to seem underwhelmed (if that’s a word, no it’s not ’cause I looked it up -> awesome video below –> ’cause affection has 2 fs, especially when you’re dealin’ with me). But here’s the thing, with an incremental update, you’re not going to get massive changes. Instead we will get slow and steady updates hopefully continuing to build faster towards a better end goal. What’s important is that the foundation is actually better now, given changes to other parts of OS X and so Server is likely now better positioned than ever for great new features in subsequent releases.

Oh, and did I forget to mention that Xgrid is gone. I guess no one really noticed anyway…

July 26th, 2012

Posted In: Mac OS X Server

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

The 10.7.2 to 10.7.3 update for Lion Server has introduced a few issues in some environments that I’ve seen. It just so happens that the update corrects a lot of behavior with Lion Server while also introducing new features, so it’s something you’re gonna’ need to do eventually. Therefore, before I update, I would strongly recommend backing up all of your services, your service data and Open Directory.

Once you’ve run the 10.7.3 update, there are a few things that I’ve seen happen. The first is that the web server won’t start. If this happens, reset the web server back to factory default:

serveradmin command web:command=restoreFactorySettings

Once it’s reset, you should be able to import any data that was backed up before and get things back to normal. The second is calendar data. On a few different systems I’ve seen users have to nuke iCal and then reimport data. To nuke and pave iCal, see this post: http://krypted.com/mac-os-x-server/nukepave-ical-server-in-lion-server. Once iCal Server has been restored to full working order (after the last step in that article) you can use psql to restore your data from the location of your backups (here called /backup/caldav.sql):

psql -U _postgres -d caldav -f /backup/caldav.sql

There’s also a script located in /usr/share/caldavd/lib/python/calendarserver/tools
called fix calendardata.py that can be used to scan and possibly fix any issues with the data itself. If that doesn’t not work though, you may be starting over. The script does not give root execute permissions by default and so you will need to chmod it to provide execute and then run it.

If you nuke CalDAV and you nuke OD and then restore them both, the GeneratedUIDs can be mismatched. Use the Directory Editor in the new Directory Utility to browse users and attach the GeneratedUID back to the correct entry in CalDAV. To locate all of the entries in CalDAV, run:

psql -U _postgres caldav -c “select * from calendar_home"

If Profile Manager won’t load it could be one of three issues (in the following order seemingly). The first is the web server, which the first command will fix. Another issue I’ve seen is that Open Directory gets a little messed up. The fix for this is to use Server Admin (not slapconfig) to burn OD down and set it back up. You can then promote replicas and finally restore the archive you did before upgrading the server. The third is to reset the Profile Manager database using wipeDB.sh:

sudo /usr/share/devicemgr/backend/wipeDB.sh

After wiping the data, you can re-run the setup in Server app for the Profile Manager service to restore an empty Profile Manager instance to working order. You can restore data into the empty Profile Manager database using the same commands I showed earlier for CalDAV, just use devicemgrd instead.

Note: I am pretty sure you need sudo for most every command I use on this site, but more specifically you need it with this stuff. So sudo is assumed if not explicitly stated.

Finally, be on the lookout for custom designs in the Wiki interface. OS updates are known to change things, but more specifically when things are not documented they can easily change. Hacking the pages nested within /usr/share/collabd is basically not supported any more. Each OS update to 10.7 has broken some of the hacks we’ve done to collabd, making me wonder whether it’s a good idea any more…

Note2: I have had little issues running these updates in walled gardens. It’s production data that is the problem. It seems that most of the issues are data driven (the opposite of data driven design is not devops driven design).

March 6th, 2012

Posted In: Mac OS X Server

Tags: , , , , , , , , , , , , , , ,

Mac OS X Server 10.7, Lion Server, comes with a few substantial back-end changes. One of these is the move from SQLite3 to PostgreSQL for many of the back-end databases, including Wiki and Podcast Producer (collab), Webmail (roundcubemail), iCal Server and Address Book Server (caldav) and as the back-end to the newest service in Lion Server, Profile Manager (device_management). As such, it’s now important to be able to use PostgreSQL the way we once used SQLite3, when trying to augment the data that these databases contains, as there currently aren’t a lot of options for editing this data (aside from manually of course).

Postgres has a number of commands that can be used to interact with databases. The most important is probably psql. Many of the other commands simply provide automated options to psql, and over time I’ve started using psql for most everything. For example, PostgreSQL comes with a command /user/bin/createuser. However, as it’s usually more verbose with errors, I like to use psql to do this. In Lion Server, the only user that can access the Postgres databases is _postgres, installed by default with Lion Server. Because a lot of commands require passwords and we might not always want to provide write access to the databases, we’re going to create a new SuperUser, called krypted with a password of daneel.

To do so, we will have to use the _postgres user to invoke psql. Any time you want to invoke psql with a different user than the user you are currently logged in as, use the -U option. To define a database, use the -d option (device_management providing access to Profile Manager data, caldav to iCal Server data roundcubemail to WebMail data and collar to Wiki data). To string this together, for accessing the device_management database as _postgres:

psql -U _postgres -d device_management

To then create a new user called krypted with a password of daneel we’ll use the create option, defining a user as the type of object to create, followed by the user name and then with password followed by the password (single quoted) and then createuser; as follows:

device_management=# create user krypted with password 'daneel' create user;

Now that there’s a valid user, let’s see what else we can do. To see all of the tables, use d:

device_management=# d

As you can tell, there are a bunch of them. Run the help command to see a list of SQL commands that can be run and ? for a list of psql options. To put some SQL commands into action, we’re going to look at the tasks that have been performed by Profile Manager. These are stored in the tasks table (aptly named), so we’re going to run the following SQL query (note a space followed by a semi-colon is required at the end of this thing):

device_management=# select * from "public"."tasks" limit 1000 offset 0 ;

Or to make it a bit simpler if you don’t have a lot of data in there yet:

device_management=# select * from "public"."tasks" ;

After seeing the output, you’ll probably be a little appreciative of Apple’s formatting. Next, let’s look at dumping the databases. We’re going to create a folder on the root of the volume called db_backups first:

sudo mkdir /db_backups

This is where these backups will end up getting stored. We’ll continue using the _postgres user for now. To do our database dumps, we’re going to use pg_dump, located at /usr/bin. First, we’ll dump the device_management database (but first we’ll stop the service and after we’ll start it – all commands from here on out also assume you’re sudo’d):

serveradmin stop devicemgr
pg_dump -U _postgres device_management -c -f /db_backups/device_management.sql
serveradmin start devicemgr

And the other 3 (stopping and starting each in the process):

serveradmin stop web
pg_dump -U _postgres roundcubemail -c -f /db_backups/roundcubemail.sql
serveradmin start web
serveradmin stop wiki
pg_dump -U _postgres collab -c -f /db_backups/collab.sql
serveradmin start wiki
serveradmin stop addressbook
serveradmin stop calendar
pg_dump -U _postgres caldav -c -f /db_backups/caldav.sql
serveradmin start addressbook
serveradmin start calendar

I haven’t had any problems running the dumps with the services running, but it’s better safe than sorry I guess. I’d probably also add some logging and maybe dump the output of full status for each service to try and track if all is well with each. Any time a service didn’t fire back up I’d then build in a sanity check for that event. There’s also a database for postgres itself, so let’s back that up as well since we’re here:

pg_dump -U _postgres postgres -c -f /db_backups/postgres.sql

These can then be restored using psql with the -d option to define the database being restored into and the -f option to define the file being restored from. For example, to restore collab:

psql -U _postgres -d collab -f /db_backups/collab

The databases are all dumped daily using pg_dumpall. These are stored in /var/pgsql but can be changed using serveradmin settings (for example, to move them to /var/pgsql1):

serveradmin settings postgres:dataDir = "/var/pgsql1"

If you mess up the Profile Manager database (before you put any real data into it) you can always use the /usr/share/devicemgr/backend/wipeDB.sh script to trash the database and start anew (although I’d just use a snapshot of a VM for all this and restore from that).

You can also connect to Postgres remotely, or locally through a network socket (common in Apache uses) by adding a listener. To do so, we’ll need to restart the Postgres LaunchDaemon. First, back up the file, just in case:

cp org.postgresql.postgres.plist org.postgresql.postgres.plist.OLD_CSE

Then stop postgres:

serveradmin stop postgres

Then edit the org.postgresql.postgres.plist file to change the following line:

listen_addresses=

To read:

listen_addresses=127.0.0.1

Then fire up postgres again:

serveradmin start postgres

And now let’s scan port 5432 (the default TCP and UDP port used for postgres) for localhost:

/Applications/Utilities/Network Utility.app/Contents/Resources/stroke 127.0.0.1 5432 5432

We could have used another IP address for the listen_addresses as well, but with that _postgres user not requiring a password it didn’t really seem prudent to do so. Once you’ve enabled a socket, you’ll then be able to use one of the many GUI tools to manage postgres. Navicat is available on the Mac App Store for $5 and PGnJ is a nice, easy to use, free one. There are tons of others, but I don’t spend a lot of time in a SQL GUI and so don’t need more than a cheap app will get me. One nice thing about most of these is that they help you to form SQL queries (or they help me). This can get really nice if you are, for example, trying to get some good reporting on Profile Manager (a feature it’s a bit light on right now).

Finally, don’t do any of this stuff on a production box, except maybe if you want more than nightly backups unless you think pretty hard about what you’re doing and know the exact impact of doing something. If you were to edit the databases on a live boxen, then you can safely assume that with how all of the objects in those databases use GUIDs that you’re probably going to break something, if not bring the whole house of cards tumbling down.

January 4th, 2012

Posted In: iPhone, Mac OS X Server, Mac Security, Mass Deployment, SQL

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

The article I did a few weeks ago on customizing the Mac OS X Server Wiki banner seems to have been a little incomplete. I discussed customizing the banner for a full web browser. However, the banner looks differently when viewed from an iPhone. I’ve had a couple of questions about how to customize the banner for iPhone so I figured I’d finish what I started.

As I mentioned in the last article, you can simply customize (or replace) the banner-bg.png file located in the /usr/share/collaboration/css/serverhome_static/img directory. This will alter the appearance when viewed from a full web browser. You can also simply edit the following files (same directory) to further alter the appearance (including those for iOS):

  • footer-bg.png – The Apple logo on the initial splash page.
  • iphone-banner-bg.png – The banner file to customize for when users are accessing the splash page from iPhone rather than the browser (what this article was originally about). As with the last article, here’s a sample ArtText document for customizing the banner.
  • iphone-footer-bg.png – The footer image from iPhone.
  • iphone-service-button.png – The background for services from iPhone (tip: make sure to leave something in place of the little blue arrows so people know to click on these).
  • iphone-service-icons.png – Smaller version of the service-icons.png, without reflection (Note: you may have seen clips of these in presentations I have done).
  • more-bg.png – The arrow beside the View All per service on the opening page.
  • service-bg.png – The background for the various services you have enabled on the initial landing page.
  • service-icons.png – collection of the service icons that indicate what an item is. These include the icon for blog, wiki, mail, change password, Podcast Producer and iCal. While these may seem generic I have to give the designers who made them credit as I have yet to make anything approaching the quality of these so I almost invariably leave them as-is.

If you want to increase from 320px width for iPhone to 640 for iPad or something like that you’ll need to track down the css files. The css file for the iPhone is in the /usr/share/collaboration/css/serverhome_static directory and called (oddly enough) iphone.css. The css file for overriding body content for standard browsers is the overrides.css in that same directory. These allow you to customize font, text size, background, etc. The iphone css even has a different section for landscape view.

If you want to get even more custom than just messing around with the splash page then go up another directory to /usr/share/collaboration/css. Here, you’ll find images and css files for each of the services exposed through the teamserver, including proxy, mobile, ical, emailrules and directory, including one of my fav 5, spinner.gif (seen below), which is a spinning symbol similar to that used at boot in Mac OS X.

If you like living on the edge (no pun intended) then you can hop up yet another directory and start messing around with live html files. Or in the /usr/share/collaboration/themes you can find the css files and images that make up the default Apple-supplied themes. Apple provides a document on managing the themes, but the gist is that you can copy the wireframe theme you find there and rename the copy. Then open the theme.plist file inside the theme and find the selectable key, making it true instead of false. Once you’ve saved that file, restart the service to see (and use) your new theme.

There are lots of other cool keys in the theme.plist, which allow you to add or remove the search fields, HotList, theme name (and displayName), change the height or width of the banner, add other sidebar items, etc. It’s not WordPress so don’t expect to download awesomeo widgets, but then it’s much more elegant than most Content Management Systems are out of the box and should just work. This isn’t to say it isn’t extensible. You can add JavaScript and XSL (ie – for FileMaker Server integration), but this can start getting somewhat complicated. One interesting note is that much of the Dashboard widget example code will run here…

Be warned, with each level of the hierarchy you traverse upwards you are more likely to find a software update blowing out your code changes (especially when you get to /usr;). Which brings up an interesting point – backup your changes. Make a good backup of the whole thing before you start hax0ring around in there and then, make sure that if you do any customizations in /usr/share/collaboration that you back up that directory (I mean, you are backing up the rest of the server, right?!?!).

The other directory that needs to be backed up is /Library/WebServer. This is where the actual HTML pages are stored. In here, you’ll find the Documents folder, and in there you’ll find the index.html page. If you’ve been monkeying around with the files I mentioned earlier then a key item that you’re going to want to change is the footer, where Apple asserts their copyright. This is down in the div class=”footer” section. You can also use this file to manually disable certain services. For example, you’ll see the podcastcapture section. Now, you would likely rather remove these from Server Admin if you can, but I can see edge cases (doh, again no pun intended) where you might rather edit it here. There are also some css files in here to control various ways that pages appear (although the appearance inside service boxes is configured using the files referenced earlier).

Anyway, I want to end this by saying that out of the box the Wiki, Blogs, Podcast Producer (if you’re using Open Directory) and other parts of the teams server works great out of the box. It’s pretty sleek as it is and other than a footer or banner here and there I’m actually not a huge proponent of heavy customization. But if you must (and many must) then hopefully this article helps get ya’ started!

August 14th, 2010

Posted In: Mac OS X Server

Tags: , , , , , , , ,

Next Page »