krypted.com

Tiny Deathstars of Foulness

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 macOS Server 5.4 (the Apple Server app running on 10.13/High Sierra). 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 macOS 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 the setup is finished, you’ll see the Setup complete modal. Here, you can click on Go to Wiki 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, instead of creating a new page.



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 a macOS 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.

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 of tech firms 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 /Applications/Server.app/Contents/ServerRoot/usr/bin/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 /Applications/Server.app/Contents/ServerRoot/usr/bin/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 /Applications/Server.app/Contents/ServerRoot/usr/bin/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 /Applications/Server.app/Contents/ServerRoot/usr/bin/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 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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin start wiki

The service can also be stopped, swapping out the start option with a stop option:

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/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 /Applications/Server.app/Contents/ServerRoot/usr/bin/wikiadmin fixPermissions

Also use the rebuildSearchIndex option with the wikiadmin command to fix any indexing, once the permissions have been repaired:

sudo /Applications/Server.app/Contents/ServerRoot/usr/bin/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 /Applications/Server.app/Contents/ServerRoot/usr/bin/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…

September 26th, 2017

Posted In: Mac OS X, Mac OS X Server

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

Apple has slowly been moving us away from the legacy afp file sharing protocol for some time. High Sierra (macOS 10.13) now comes with a new suite of tools to manage WebDAV shares. Most of these are configurable using wfsctl located at /usr/sbin/wfsctl. When run, the tool reports as “WebDAV File Sharing control utility.”

To start the WebDAV service, use the start verb:

wfsctl start

At this point, the service will attempt to lookup the hostname of the server. If the hostname cannot be found (or once found does not match the expected results) then the service will not start. For more on why this might be happening, use the diagnose verb:

wfsctl diagnose

Once started, you can see what shares are running using the shares verb:

wfsctl shares

You can also share a folder via WebDAV using the share verb:

wfsctl share /Volumes/Pegasus/Accounting

Or unshare a directory:

wfsctl unshare /Volumes/Pegasus/Accounting

The wfsctl command doesn’t seem to interact with the web sharing options built into the web sharing services in macOS Server, although when you run diagnose it will look at services and display what’s running. From what I can tell so far, this should not be run on servers that have either of the macOS Server app web services running.

September 26th, 2017

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , ,

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: , , , , , , , , , , , , , , ,

Next Page »