Tag Archives: server

Active Directory Windows Server Windows XP

Use Syslog on Windows

There are a number of tools available for using Syslog in a Windows environment. I’ll look at Snare as it’s pretty flexible and easy to configure. First download the snare installation executable from http://sourceforge.net/projects/snare. Once downloaded run the installer and simply follow all of the default options, unless you’d like to password protect the admin page, at which point choose that. Note that the admin page is by default only available to localhost.

Once installed, run the “Restore Remote Access to Snare for Windows” script.

Screen Shot 2014-04-10 at 10.56.43 AM

Then open http://127.0.0.1:6161 and click on Network Configuration in the red sidebar. There, we can define the name that will be used in syslog (or leave blank to use the hostname), the port of your syslog server (we used 514 here) and the address of your syslog server (we used logger here but it could be an IP or fqdn).

Screen Shot 2014-04-08 at 10.58.04 AM

 

Once you have the settings you’d like to use, scroll down and save your configuration settings. Then, open Services and restart the Snare service.

Screen Shot 2014-04-08 at 10.56.22 AM

Then run the Disable Remote Access to Snare for Windows option and you’re done. Now, if you’re deploying Snare across a lot of hosts, you might find that scripting the config is faster. You can send the Destination hostname (here listed as meh) and Destination Port (here 514) via regedit commands (Destination and DestPort respectively) and then restart the service.

Screen Shot 2014-04-08 at 10.56.51 AM

I’ll do another article at some point on setting up a logstash server to dump all these logs into. Logstash can also parse the xml so you can search for each attribute in the logs and with elasticsearch/hadoop/Kibana makes for an elegant interface for parsing through these things.

Microsoft Exchange Server

Selectively Import PST Files Into Outlook

I’ve written plenty about exporting mailboxes from Exchange. But what if you need to perform a selective import into Outlook? This is helpful for importing mail in date ranges, using an import to search for terms (common with litigation holds) and importing contacts and calendars.

To get started, click Open from the File ribbon.

Screen Shot 2014-02-03 at 10.51.01 AM

When prompted, click on Import/Export.

Screen Shot 2014-02-03 at 10.51.11 AM

At the Import and Export Wizard screen, click on “Import from another program or file”

Screen Shot 2014-02-03 at 10.51.27 AM

At the “Import a File” screen, click on “Outlook Data File (pst)”

Screen Shot 2014-02-03 at 10.51.41 AM

 

At the Import Outlook Data File screen, choose the mailbox to import into and then click on the Filter button. Using the filtering options, you can choose to import based on date ranges, using search terms, selecting specific folders or a combination of all of these.

Mac OS X Server

Using the Help Options in OS X Server

Open Server, click Help, then click Server Help. You can then search and browse for information about things you’d like to accomplish using the Help Center.

Screen Shot 2013-11-05 at 4.16.18 PM

Now, click the arrow for each service for information about configuring that service. You will see an arrow for each service.

Screen Shot 2013-11-05 at 4.17.19 PM

Click the arrow for more information on that specific service.

Mac OS X Mac OS X Server Xsan

Installing Final Cut Server on Lion & Mountain Lion Server

Thanks to Allan Sanderson for the following submission, which outlines how to install Final Cut Server in Lion and Mountain Lion Server.

In Server.app

————-
Websites:
Check “Enable PHP web applications”

Install Java
————
Open /Applications/Utilities/Java Preferences.app
You’ll be prompted by Software Update service to install Java, click “Continue”, provide admin credentials when promopted.

Install Final Cut Server
————————
Run Final Cut Server installer.
Then run Software Update to get ProApplications 2010-02 & Final Cut Server v1.5.2 updates.

Check Configuration
——————-
1)
Check fcsvr user has been created:
dscl /Local/Default -search /Users RecordName fcsvr
Output should look something like this:
fcsvr RecordName = (
fcsvr
)

2)
Check “fcsvr” user’s home folder location is set to “/Library/Application Support/Final Cut Server”
dscl /Local/Default -read /Users/fcsvr NFSHomeDirectory
Output should look something like this:
NFSHomeDirectory: /Library/Application Support/Final Cut Server
If it doesn’t, caorrect it with this command:
sudo dscl /Local/Default -create /Users/fcsvr NFSHomeDirectory “/Library/Application Support/Final Cut Server”

Customisations To Make It Work
——————————
A word to the wise, I personally take a backup before making any changes to system files, Time Machine is nice ‘n all, but I’d prefer not to have to go there in the first place.

1)
An out the box FCSvr install doesn’t set an “AUTH_TYPE” key/value pair in the com.apple.FinalCutServer.settings.plist file. Under 10.5 & 10.6 this didn’t cause any issues, but 10.7+ does seem to be an issue. So for Local and Open Directory authentication, this command will do the job:
sudo defaults write /Library/Preferences/com.apple.FinalCutServer.settings “AUTH_TYPE” -int 2
If you’re being more daring and trying to work with an Active Directory, then you’ll want the following:
sudo defaults write /Library/Preferences/com.apple.FinalCutServer.settings “AUTH_TYPE” -int 1

2)
Because of how things have changed between 10.6 and 10.7 & 10.8, its necessary to manually copy the apache site config into a users apache space.
sudo cp “/Library/Application Support/Final Cut Server/Final Cut Server.bundle/Contents/Resources/share/conf/client_apache2.conf” “/etc/apache2/users/fcsvr.conf”

3)
Now in order for the apache site config to be read by apache, we need to add in the necessary direction for httpd.
Append “UserDir Sites” to end of “/etc/apache/httpd.conf”, this can be done as a one-liner if you like:
sudo echo “UserDir Sites” >>/etc/apache2/httpd.conf

4)
Lastly we have to add in the redirection settings for 10.7+ as the installers isn’t able to do this due to file path changes between the OS revisions.
So, in your /etc/apache2/sites/0000_any_80_.conf file, paste in the following lines after the IfModule for mod_ssl.c:
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteEngine On
RewriteRule .* – [F]
RewriteRule ^/FinalCutServer$ /~fcsvr/Sites/webstart/index.php [NC,L]
RewriteRule ^/FinalCutServer/FinalCutServer_mac.jnlp$ /~fcsvr/Sites/webstart/macJnlp.php [NC,L]
RewriteRule ^/FinalCutServer/FinalCutServer_windows.jnlp$ /~fcsvr/Sites/webstart/windowsJnlp.php [NC,L]
RewriteRule ^/FinalCutServer/FinalCutServer_other.jnlp$ /~fcsvr/Sites/webstart/jnlp.php [NC,L]
</IfModule>
ORIGINAL_SOURCES: http://www.linkedin.com/groups/Has-anyone-been-able-get-138082%2ES%2E67319989?view=&srchtype=discussedNews&gid=138082&item=67319989&type=member&trk=eml-anet_dig-b_pd-ttl-cn&ut=2M3_ri588Lslo1

SPECIAL_MENTIONS: Matt Geller, David Colville

Mac OS X Mac OS X Server Mac Security Mass Deployment

Enable Push Notifications In OS X Mountain Lion Server

Push Notifications can be used in most every service OS X Mountain Lion Server can run. Any service that requires Push Notifications will provide the ability to setup APNS during the configuration of the service. But at this point, I usually just set up Push Notifications when I setup a new server.

To enable Push Notifications for services, you’ll first need to have a valid AppleID. Once you have an AppleID, open the Server app and then click on the name of the server. At the Overview screen, click on Settings.

At the Settings screen for your server, click on the check-box for “Enable Apple push notifications.”

At the Apple Push Notification Services certificate screen, enter an AppleID if you have not yet configured APNS and click on OK. The Apple Push Notification Service certificate will then be configured.

The certificate is valid for one year, by default. Administrators receive an alert when the certificate is due to expire. To renew, open the same screen and click on the Renew button.

Enter the credentials for the AppleID again and then click on Renew Certificate button. The certificate will then be valid for another year.

Mac OS X Mac OS X Server

Setting Up And Using Web Services in OS X Mountain Lion Server

Configuring web services is as easy in OS X Mountain Lion Server (10.8) as it has ever been. To set up the default web portal, simply open the Server app, click on the Websites service and click on the ON button.

After a time, the service will start. Once running, click on the View Server Website link at the bottom of the pane.

Provided the stock OS X Server page loads, you are ready to use OS X Server as a web server.

Before we setup custom sites, there are a few things you should know. The first is, the server is no longer really designed to remove the default website. So if you remove the site, your server will exhibit inconsistent behavior. Also, don’t remove the files that comprise the default site. Instead just add sites, which is covered next. Webmail is gone. You don’t have to spend a ton of time looking for it as it isn’t there. Also, Mountain Lion Server adds web apps, which we’ll briefly review later in this article as well.  Finally, enabling PHP and Python on sites is done globally, so this setting applies to all sites hosted on the server.

Now that we’ve got that out of the way, let’s add our first custom site. Do so by clicking on the plus sign. At the New Web Site pane, you’ll be prompted for a number of options. The most important is the name of the site, with other options including the following:

  • Domain Name: The name the site is accessible from. The default sites do not have this option as they are accessible from all names that resolve to the server.
  • IP Address: The IP address the site listens on. Any means the site is available from every IP address the server is configured to use. The default websites do not have this option as they are accessible from all addresses automatically
  • Port: By default, sites without SSL run on port 80 on all network interfaces, and sites with SSL run on port 443 on all network interfaces. Use the Port field to use custom ports (e.g., 8080). The default sites do not have this option as they are configured to use 80 and 443 for default and SSL-based communications respectively.
  • SSL Certificate: Loads a list of SSL certificates installed using Keychain or the SSL Certificate option in the Settings pane of the Server application
  • Store Site Files In: The directory that the files that comprise the website are stored in. These can be placed into the correct directory using file shares or copying using the Finder. Click on the drop-down menu and then select Other to browse to the directory files are stored in.
  • Who Can Access: By default Anyone (all users, including unauthenticated guests) can access the contents of sites. Clicking on Anyone and then Customize… brings up the “Restrict access to the following folders to a chosen group” screen, where you can choose web directories and then define groups of users who can access the contents.
  • Additional Domains: Click on the Edit… button to bring up a simple list of domain names the the site also responds for (e.g. in addition to krypted.com, add www.krypted.com).
  • Redirects: Click on the Edit… button to bring up a list of redirects within the site. This allows configuring redirects to other sites. For example, use /en to load english.krypted.com or /cn to load china.krypted.com).
  • Aliases: Click on the Edit… button to load a list of aliases. This allows configuring redirects to folders within the same server. For example, /en loads /Library/Server/Web/Data/Sites/Default
  • Index Files: Click on the Edit… button to bring up a list of pages that are loaded when a page isn’t directly indicated. For example, when visiting krypted.com, load the wp.php page by default.
  • Advanced Options: The remaining options are available by clicking on the “Edit Advanced Settings…” button.
  • Enable Server Side Includes: Allows administrators to configure leveraging includes in web files, so that pieces of code can be used across multiple pages in sites.
  • Allow overrides using .htaccess files: Using a .htaccess file allows administrators to define who is able to access a given directory, defining custom user names and passwords in the hidden .htaccess file. These aren’t usually required in an OS X Server web environment as local and directory-based accounts can be used for such operations. This setting enables using custom .htaccess files instead of relying on Apple’s stock web permissions.
  • Allow folder listing: Enables folder listings on directories of a site that don’t have an Index File (described in the non-Advanced settings earlier).
  • Allow CGI execution: Enables CGI scripts for the domain being configured.
  • Use custom error page: Allows administrators to define custom error pages, such as those annoying 404 error pages that load when a page can’t be found
  • Make these web apps available on this website: A somewhat advanced setting, loads items into the webapps array, which can be viewed using the following command:  sudo serveradmin settings web:definedWebApps

Once you’ve configured all the appropriate options, click on Done to save your changes. The site should then load. Sites are then listed in the list of Websites.

The Apache service is most easily managed from the Server app, but there are too many options in Apache to really be able to put into a holistic graphical interface. The easiest way to manage the Websites service in OS X Mountain Lion server is using the serveradmin command. Apache administrators from other platforms will be tempted to use the apachectl command to restart the Websites service. Instead, use the serveradmin command to do so. To start the service:

sudo serveradmin start web

To stop the service(s):

sudo serveradmin stop web

And to see the status:

sudo serveradmin fullstatus web

Fullstatus returns the following information:

web:health = _empty_dictionary
web:readWriteSettingsVersion = 1
web:apacheVersion = "2.2"
web:servicePortsRestrictionInfo = _empty_array
web:startedTime = "2012-08-13 23:01:42 +0000"
web:apacheState = "RUNNING"
web:statusMessage = ""
web:ApacheMode = 2
web:servicePortsAreRestricted = "NO"
web:state = "RUNNING"
web:setStateVersion = 1

While the health option typically resembles kiosk computers in the Computer Science departments of most major universities, much of the rest of the output can be pretty helpful including the Apache version, whether the service is running, any restrictions on ports and the date/time stamp that the service was started.

To see all of the settings available to the serveradmin command, run it, followed by settings and then web, to indicate the Websites service:

sudo serveradmin settings web

The output is pretty verbose and can be considered in two sections, the first includes global settings across sites as well as the information for the default sites that should not be deleted:

web:defaultSite:documentRoot = "/Library/Server/Web/Data/Sites/Default"
web:defaultSite:serverName = ""
web:defaultSite:realms = _empty_dictionary
web:defaultSite:redirects = _empty_array
web:defaultSite:enableServerSideIncludes = no
web:defaultSite:customLogPath = "&quot;/var/log/apache2/access_log&quot;"
web:defaultSite:webApps = _empty_array
web:defaultSite:sslCertificateIdentifier = ""
web:defaultSite:fullSiteRedirectToOtherSite = ""
web:defaultSite:allowFolderListing = no
web:defaultSite:serverAliases = _empty_array
web:defaultSite:errorLogPath = "&quot;/var/log/apache2/error_log&quot;"
web:defaultSite:fileName = "/Library/Server/Web/Config/apache2/sites/0000_any_80_.conf"
web:defaultSite:aliases = _empty_array
web:defaultSite:directoryIndexes:_array_index:0 = "index.html"
web:defaultSite:directoryIndexes:_array_index:1 = "index.php"
web:defaultSite:directoryIndexes:_array_index:2 = "/wiki/"
web:defaultSite:directoryIndexes:_array_index:3 = "default.html"
web:defaultSite:allowAllOverrides = no
web:defaultSite:identifier = "37502141"
web:defaultSite:port = 80
web:defaultSite:allowCGIExecution = no
web:defaultSite:serverAddress = "*"
web:defaultSite:requiresSSL = no
web:defaultSite:proxies = _empty_dictionary
web:defaultSite:errorDocuments = _empty_dictionary
web:defaultSecureSite:documentRoot = "/Library/Server/Web/Data/Sites/Default"
web:defaultSecureSite:serverName = ""
web:defaultSecureSite:realms = _empty_dictionary
web:defaultSecureSite:redirects = _empty_array
web:defaultSecureSite:enableServerSideIncludes = no
web:defaultSecureSite:customLogPath = "&quot;/var/log/apache2/access_log&quot;"
web:defaultSecureSite:webApps = _empty_array
web:defaultSecureSite:sslCertificateIdentifier = "com.apple.systemdefault.9912650B09DE94ED160146A3996A45EB3E39275B"
web:defaultSecureSite:fullSiteRedirectToOtherSite = ""
web:defaultSecureSite:allowFolderListing = no
web:defaultSecureSite:serverAliases = _empty_array
web:defaultSecureSite:errorLogPath = "&quot;/var/log/apache2/error_log&quot;"
web:defaultSecureSite:fileName = "/Library/Server/Web/Config/apache2/sites/0000_any_443_.conf"
web:defaultSecureSite:aliases = _empty_array
web:defaultSecureSite:directoryIndexes:_array_index:0 = "index.html"
web:defaultSecureSite:directoryIndexes:_array_index:1 = "index.php"
web:defaultSecureSite:directoryIndexes:_array_index:2 = "/wiki/"
web:defaultSecureSite:directoryIndexes:_array_index:3 = "default.html"
web:defaultSecureSite:allowAllOverrides = no
web:defaultSecureSite:identifier = "37502140"
web:defaultSecureSite:port = 443
web:defaultSecureSite:allowCGIExecution = no
web:defaultSecureSite:serverAddress = "*"
web:defaultSecureSite:requiresSSL = yes
web:defaultSecureSite:proxies = _empty_dictionary
web:defaultSecureSite:errorDocuments = _empty_dictionary
web:dataLocation = "/Library/Server/Web/Data"
web:mainHost:keepAliveTimeout = 15.000000
web:mainHost:maxClients = "50%"

The second section is per-site settings, with an array entry for each site:

web:customSites:_array_index:0:documentRoot = "/Library/Server/Web/Data/Sites/www2.krypted.com"
web:customSites:_array_index:0:serverName = "www2.krypted.com"
web:customSites:_array_index:0:realms = _empty_dictionary
web:customSites:_array_index:0:redirects = _empty_array
web:customSites:_array_index:0:enableServerSideIncludes = no
web:customSites:_array_index:0:customLogPath = "/var/log/apache2/access_log"
web:customSites:_array_index:0:webApps = _empty_array
web:customSites:_array_index:0:sslCertificateIdentifier = ""
web:customSites:_array_index:0:fullSiteRedirectToOtherSite = ""
web:customSites:_array_index:0:allowFolderListing = no
web:customSites:_array_index:0:serverAliases = _empty_array
web:customSites:_array_index:0:errorLogPath = "/var/log/apache2/error_log"
web:customSites:_array_index:0:fileName = "/Library/Server/Web/Config/apache2/sites/0000_any_80_www2.krypted.com.conf"
web:customSites:_array_index:0:aliases = _empty_array
web:customSites:_array_index:0:directoryIndexes:_array_index:0 = "index.html"
web:customSites:_array_index:0:directoryIndexes:_array_index:1 = "index.php"
web:customSites:_array_index:0:directoryIndexes:_array_index:2 = "/wiki/"
web:customSites:_array_index:0:directoryIndexes:_array_index:3 = "default.html"
web:customSites:_array_index:0:allowAllOverrides = no
web:customSites:_array_index:0:identifier = "41179886"
web:customSites:_array_index:0:port = 80
web:customSites:_array_index:0:allowCGIExecution = no
web:customSites:_array_index:0:serverAddress = "*"
web:customSites:_array_index:0:requiresSSL = no
web:customSites:_array_index:0:proxies = _empty_dictionary
web:customSites:_array_index:0:errorDocuments = _empty_dictionary

The final section (the largest by far) includes array entries for each defined web app. The following shows the entry for a Hello World Python app:

web:definedWebApps:_array_index:15:requiredWebAppNames = _empty_array
web:definedWebApps:_array_index:15:includeFiles:_array_index:0 = "/Library/Server/Web/Config/apache2/httpd_wsgi.conf"
web:definedWebApps:_array_index:15:requiredModuleNames:_array_index:0 = "wsgi_module"
web:definedWebApps:_array_index:15:startCommand = ""
web:definedWebApps:_array_index:15:sslPolicy = 0
web:definedWebApps:_array_index:15:requiresSSL = no
web:definedWebApps:_array_index:15:requiredByWebAppNames = _empty_array
web:definedWebApps:_array_index:15:launchKeys = _empty_array
web:definedWebApps:_array_index:15:proxies = _empty_dictionary
web:definedWebApps:_array_index:15:preflightCommand = ""
web:definedWebApps:_array_index:15:stopCommand = ""
web:definedWebApps:_array_index:15:name = "com.apple.webapp.wsgi"
web:definedWebApps:_array_index:15:displayName = "Python &quot;Hello World&quot; app at /wsgi"

Each site has its own configuration file defined in the array for each section. By default these are stored in the /Library/Server/Web/Config/apache2/sites directory, with /Library/Server/Web/Config/apache2/sites/0000_any_80_www2.krypted.com.conf being the file for the custom site we created previously. As you can see, many of the options available in the Server app are also available in these files:

<VirtualHost *:80>
ServerName www2.krypted.com
ServerAdmin admin@example.com
DocumentRoot "/Library/Server/Web/Data/Sites/www2.krypted.com"
DirectoryIndex index.html index.php /wiki/ default.html
CustomLog /var/log/apache2/access_log combinedvhost
ErrorLog /var/log/apache2/error_log

<IfModule mod_ssl.c>
SSLEngine Off
SSLCipherSuite "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM"
SSLProtocol -ALL +SSLv3 +TLSv1
SSLProxyEngine On
SSLProxyProtocol -ALL +SSLv3 +TLSv1
</IfModule>

<Directory "/Library/Server/Web/Data/Sites/www2.krypted.com">
Options All -Indexes -ExecCGI -Includes +MultiViews
AllowOverride None
<IfModule mod_dav.c>
DAV Off
</IfModule>
<IfDefine !WEBSERVICE_ON>
Deny from all
ErrorDocument 403 /customerror/websitesoff403.html
</IfDefine>
</Directory>

</VirtualHost>

The serveradmin command can also be used to run commands. For example, to reset the service to factory defaults, delete the configuration files for each site and then run the following command:

sudo serveradmin command web:command=restoreFactorySettings

The final tip I’m going to give in this article is when to make changes with each app. I strongly recommend making all of your changes in the Server app when possible. When it isn’t, use serveradmin and when you can’t make changes in serveradmin, only then alter the configuration files that come with the operating system by default. I also recommend keeping backups of all configuration files that are altered and a log of what was altered in each, in order to help piece the server back together should it become unconfigured miraculously when a softwareupdate -all is run next.

Mac OS X Server

Using Wikis & WebDAV in OS X Mountain Lion

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!

Mac OS X Mac OS X Server Mac Security Mass Deployment

Using the Software Update Service on Mountain Lion Server

The software patching configuration built into most operating systems is configured to open a box at home, join your network and start using the computer right away. As environments grow from homes to offices and then offices grow into enterprises, at some point software updates and patches need to be managed centrally. Mountain Lion, as with its OS X Server predecessors has a Software Update service. The service in the Server app is known as Software Update and from the command line is known as swupdate.

The Software Update service, by default, stores each update in the /var/db/swupd directory. The Software Update servie is actually comprised of three components. The first is an Apache server, invoked by the /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.host.plist LaunchDaemon. This LaunchDaemon invokes a httpd process and clients access updates from the server based on a manifest of updates available in the sucatalog. These are synchronized with Apple Software Updates via /Applications/Server.app/Contents/ServerRoot/usr/sbin/swupd_syncd, the LaunchDaemon for swupdate at /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.sync.plist. The Apache version is now Apache/2.2.22.

Clients can be pointed at the server then via a Profile or using the defaults command to edit the /Library/Preferences/com.apple.SoftwareUpdate.plist file. The contents of this file can be read using the following command:

defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist

To point a client to a server via the command line, use a command such as the following:

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://updates.krypted.com:8088/index.sucatalog

But first, you’ll need to configure and start the Software Update service. Lucky you, it’s quick (although quick in a hurry up and wait kind of way). To get started, open the Server app and then click on the Software Update service.

By default, updates are set to simply mirror the Apple servers, by default, enabling each update that Apple publishes, effectively proxying updates. You can use the Manual button if you would like to configure updates to either manually be approved and manually synchronized or just manually approved but automatically copied from Apple. Otherwise click on the ON button and wait for the updates to cache to simply mirror the Apple servers.

If you would like to manually configure updates, click on the Manual option and then click on the Updates tab.

The first item in the Updates tab is the “Austomatically download new updates” checkbox. This option downloads all of the updates but does not enable them. The Updates tab also displays all available updates. click on one and then click on the cog-wheel icon towards the bottom of the screen to configure its behavior (Download, Enable, Disable, Remove and View Update).

Note: The only option for updates in an Automatic configuration environment is disable.

The service can be managed using serveradmin. To start Software Update, use the start option, followed by the swupdate service identifier:

sudo serveradmin start swupdate

To stop the service, replace start with stop:

sudo serveradmin stop swupdate

To see the status of the service, including the location of updates, the paths to log files, when the service was started and the number of updates running, use the fullstatus option:

sudo serveradmin fullstatus swupdate

The output of which appears as follows:

swupdate:state = "RUNNING"
swupdate:lastChecktime = 2012-08-04 17:04:45 +0000
swupdate:syncStatus = "DONE"
swupdate:syncServiceState = "RUNNING"
swupdate:setStateVersion = 1
swupdate:lastProductsUpdate = 2012-08-04 17:07:10 +0000
swupdate:logPaths:swupdateAccessLog = "/var/log/swupd/swupd_access_log"
swupdate:logPaths:swupdateErrorLog = "/var/log/swupd/swupd_error_log"
swupdate:logPaths:swupdateServiceLog = "/var/log/swupd/swupd_syncd_log"
swupdate:readWriteSettingsVersion = 1
swupdate:checkError = no
swupdate:pluginVers = "10.8.91 (91)"
swupdate:updatesDocRoot = "/var/db/swupd/"
swupdate:hostServiceState = "RUNNING"
swupdate:autoMirror = no
swupdate:numOfEnabledPkg = 0
swupdate:servicePortsAreRestricted = "NO"
swupdate:numOfMirroredPkg = 0
swupdate:autoMirrorOnlyNew = no
swupdate:startTime = 2012-08-04 17:04:45 +0000
swupdate:autoEnable = no

There are also a number of options available using the serveradmin settings that aren’t exposed to the Server app. These include a feature I used to use a lot in the beginning of deployments with poor bandwidth, only mirroring new updates, which is available to swupdate via the autoMirrorOnlyNew option. To configure:

sudo serveradmin settings swupdate:autoMirrorOnlyNew = yes

Also, the service can throttle bandwidth for clients. To use this option, run the following command:

sudo serveradmin settings swupdate:limitBandwidth = yes

And configure bandwidth using the syncBandwidth option, as follows:

sudo serveradmin settings swupdate:syncBandwidth = 10

To automatically sync updates but not enable them (as the checkboxes allow for in the Server app, use the following command:

sudo serveradmin settings swupdate:autoEnable = no

The port (by default 8088) can be managed using the portToUse option, here being used to set it to 80 (clients need this in their catalog URL from here on out):

sudo serveradmin settings swupdate:portToUse = 80

Finally, administrators can purge old packages that are no longer needed using the PurgeUnused option:

sudo serveradmin swupdate:PurgeUnused = yes

One of the biggest drawbacks of the Software Update service in OS X Mountain Lion Server in my opinion is the fact that it does not allow for serving 3rd party packages, from vendors such as Microsoft or Adobe. To provide those vendors with a manifest file and a quick little path option to add those manifest files, a nice middle ground could be found between the Mac App Store and the built in software update options in OS X. But then, we wouldn’t want to make it too easy.

Another issue many have had is that users need administrative passwords to run updates and don’t have them (technically this isn’t a problem with the OS X Server part of the stack, but it’s related). While many options have come up for this, one is to just run the softwareupdate command for clients via ARD or a similar tool.

Many environments have used these issues to look at tools such as reposado or third party patch management tools such as JAMF Software’s the Casper Suite (JAMF also makes a reposado-based VM that mimics the swupdate options), FileWave, Absolute Manage and others. Overall, the update service in Mountain Lion is easily configured, easily managed and easily deployed to clients. It is what it needs to be for a large percentage of OS X Mountain Lion (10.8) Server administrators. This makes it a very viable option and if you’ve already got a Mountain Lion computer sitting around with clients not yet using a centralized update server, well worth enabling.

Note: Managing multiple Software Update Servers has changed in OS X Mountain Lion Server, see my previous post for more information on these changes.

Mac OS X Mac OS X Server

Configuring Mountain Lion Server's Contacts Server

Mountain Lion has an application called Contacts. Mountain Lion Server has a service called Contacts. While the names might imply differently, surprisingly the two are designed to work with one another. The Contacts service was called Address Book in Lion and below and is based on CardDAV, a protocol for storing contact information on the web, retrievable and digestible by client computers. The Contacts service is also a conduit with which to read information from LDAP and display that information in the Contacts client, which is in a way similar to how the Global Address List (GAL) works in Microsoft Exchange.

I know I’ve said this about other services in Mountain Lion Server, but the Contacts service couldn’t be easier to configure. First, you should be running Open Directory and you should also have configured Apple Push Notifications. To setup Push Notifications, have an Apple ID handy and click on the name of the server in the Server app. Then click on Settings and check the box for “Enable Apple push notifications”.

Provide the username and password for the Apple ID and then click on Finish.

To enable the Contacts service, open the Server app and then click on Contacts in the SERVICES section of the List Pane. From here, use the “Include directory contacts in search” checkbox to publish LDAP contacts through the service, or leave this option unchecked and click on the ON button to enable the service.

The Contacts service then starts and once complete, a green light appears beside the Contacts entry in the List Pane. To configure a client open the Contacts application on a client computer and use the Preferences entry in the Contacts menu to bring up the Preferences screen. From here, click Accounts and then click on the plus icon (“+”).

At the Add Account screen, select CardDAV from the Account type field and then provide a valid username from the users configured in Server app as well as the password for that user and the name or IP address of the server. Then click on the Create button.

 

When the account is finished creating click on the Server Settings tab if a custom port is required. Otherwise, close the Preferences/Accounts screen and then view the list of Contacts. Click on the name of the server in the Contacts sidebar list. There won’t be any contacts yet, so click on the plus sign to verify you have write access to the server.

To create additional lists of contacts, hover over the name of the server and a plus sign appears, click on it to create a group on the Contacts service.

Next, let’s get access to the LDAP-based contacts. To do so, bring up the Add Account screen again and this time select LDAP from the Account Type field.

Provide the name or IP address of the server and then the port that LDAP contacts are available over (the defaults, 389 and 636 with SSL are more than likely the settings that you’ll use. Then click on the Continue button.

At the Account Settings screen, provide the name that will appear in the Contacts app for the account in the Description field and then enter the search base in the Search base field. To determine the search base, use the serveradmin command. The following command will output the search base:

sudo serveradmin settings dirserv:LDAPSettings:LDAPSearchBase

Then set Authentication to simple and provide the username and password to access the server for the account you are configuring. The list then appears.

The default port for the Contacts service is 8443, as seen earlier in the configuration of the client. To customize the port, use the serveradmin command to set addressbook settings for BindSSLPorts to edit the initial array entry, as follows:

sudo serveradmin settings addressbook:BindSSLPorts:_array_index:0 = 8443

The default location for the files used by the Contacts service is in the /Library/Server/Calendar and Contacts directory. To change that to a folder called /Volumes/Pegasys/CardDAV, use the following command:

sudo serveradmin settings addressbook:ServerRoot = "/Volumes/Pegasys/CardDAV"

The service is then stopped with the serveradmin command:

sudo serveradmin stop addressbook

And started with the serveradmin command:

sudo serveradmin start addressbook

And whether the service is running, along with the paths to the logs can be obtained using the fullstatus command with serveradmin:

sudo serveradmin fullstatus addressbook

The output of which should be as follows:

addressbook:setStateVersion = 1
addressbook:logPaths:LogFile = "/var/log/caldavd/access.log"
addressbook:logPaths:ErrorLog = "/var/log/caldavd/error.log"
addressbook:state = "RUNNING"
addressbook:servicePortsAreRestricted = "NO"
addressbook:servicePortsRestrictionInfo = _empty_array
addressbook:readWriteSettingsVersion = 1

If you’re easily amused, run the serveradmin settings for calendar and compare them to the serveradmin settings for addressbook:

sudo serveradmin settings calendar

By default, the addressbook:MaxAllowedInstances is 3000. Let’s change it for calendar:

sudo serveradmin serveradmin settings calendar:MaxAllowedInstances = 3001

And then let’s see what it is in addressbook:

serveradmin settings addressbook:MaxAllowedInstances

If two services share a port and share all the same settings and even a binary then are they in fact the same service?

You know, there’s a million fine looking women in the world, dude. But they don’t all bring you lasagna at work. Most of ‘em just cheat on you.

public speaking

MacTech InDepth In New York

I have been added as a speaker at MacTech InDepth in New York. If you haven’t signed up yet, and you work with Mac OS X Server then you should really check out the sessions that have been planned:

  • The Elephant in the Room: The New Lion OS X is out, now what? There are a lot of differences to contend with between Lion and Snow Leopard. Now with the new Mountain Lion update, what changes can we expect to see? We discuss the differences in advanced services, GUI simplicity, and Apache management GUI’s. We help you understand the updates in the new OS and make the transition easier. We go over the new updates of Lion over the Snow Leopard server.
  • Setting solid foundations: To truly grasp the power of Lion, you need to set up solid foundations. We go over minimum requirements for internet DNS, and tackle router tricks. We discuss open directory and what it was used for.
  • Mobile Device Management 101: Apple’s IPCU/Apple Configurator: Mobile Device Management is vital to businesses, large or small. We have an extensive overview of profile manager and how you can use mobile device management on OS X. For those still using Snow Leopard, we go over your options and discuss the possibility of using third parties as a solution.
  • DNS, Ahh, run away, run away: In this session, we tackle DNS and break it down and show how simple it is to work with. We go over how DNS works and cover different components such as internet DNS and internal DNS.
  • Administering a Server with just Server.app: We show you how to use server.app and control administrative programs. For the services, we go over Address Book, iCal, iChat, and Mail.
  • Web Administration of OS X Server : Web Admin on Lion Server versus Snow Leopard is covered, dealing with the differences and how to use each system effectively. On Lion server, we cover using FTP without a GUI.
  • Going old school, using the old tools: After getting used to Snow Leopard we go over the major differences between Snow and Lion and how you can handle the transition. We go over server admin and what is still left in the program and why it has been left.
  • Deployment Part I: Tools & Concepts: In tools and concepts we learn that there aren’t stark differences between Lion server and Snow Leopard. NetBoot, NetRestore and third party tools are covered; we talk about how NetBoot works and what the differences between NetBoot and NetRestore are. Along with this we cover Network configuration requirements and using software update server.
  • Deployment Part II: DeployStudio: DeployStudio is covered in-depth; we cover creation techniques and management techniques.

Overall, this represents a nice, fast way to update your skills to allow for managing Lion Server and to get up to speed with those new to the platform. One thing I like about the session list is that it goes beyond the stock server implementation and looks at DeployStudio, MDM and other important topics not purely server oriented. I hope to see you all there!

These vagabond shoes, are longing to stray
Right through the very heart of it – New York, New York