krypted.com

Tiny Deathstars of Foulness

OS X Server 5 dropped last week. It’s the first time I’ve seen an OS X Server version drop before an OS release. I’m guessing there was an impetus to get it out the door before OS X 10.11 ships, so that caching and software update servers can facilitate quicker adoption and tools like Profile Manager will work on 0-day. But, there are some funny issues that are popping up. One of these is OS X Server usurping some ports that would otherwise potentially be used by other tools. Notably for Casper administrators, this includes port 8443. So here are some issues I’ve seen with Apache in the latest OS X Server. Ports are in use that shouldn’t be This is of particular interest to people running Tomcat sites (e.g. Casper admins). If you have a 3rd party service that isn’t loading, you may find that a port is already in use. For example, let’s say that you’re trying to start a JSS on port 8443. Well, let’s say you run stroke and you see this (when the JSS is stopped): /System/Library/CoreServices/Applications/Network\ Utility.app/Contents/Resources/stroke 127.0.0.1 8443 8443 And let’s say you get this response (again, with the JSS stopped): Open TCP Port:      8443      pcsync-https Well, that means that the server has probably just totally ganked port 8443 for that funky new proxy thing. In /Library/Server/Web/Config/Proxy/apache_serviceproxy.conf there are a few new funny things due to proxy services (that whole proxy folder is new btw). One of which is the fact that the server listens on some ports you might not mean for it to listen on, by default including 80, 443, 8008, 8800, 8443, and 8843. The server always had a default site listening on ports 80 and 443, but now Caldav response is using 8443 for a Virtual Host for the CalendarServer that redirects to /webcal on port 443. Arg. There are a few things you can do to correct this. One would be to comment out one of the lines for the listeners. For this, find the line that reads:
listen 8443
And replace it with:
#listen 8443
This would likely spawn some errors in your apache logs when the virtual hosts that also use 8443 try and load. So you’ll likely also want to comment out the virtual host section of the file. For this, look for <VirtualHost *:8443> to that virtual hosts </VirtualHost> and comment out the whole section. Another option, if you do actually want to use the server as a calendar server as well, might be to replace the asterisk in the definition with an IP address or hostname, which would bind that port to a specific IP address or hostname. This would be true if you have something using 8008, 8800 (think Kerio), etc. Also, consider that there’s a /Library/Server/Web/Config/Proxy/apache_serviceproxy_customsites*.conf entry. For 5.03 and 5.04, this isn’t an issue, but any time you see an include like that, you could be loading up multiple includes in the future. Which could introduce additional tasks. Also, keep in mind that you’ll want to keep a backup of this file handy. It’s in a place in your system where Apple can change things in the file without any concern around customizations you previously made in the file. Therefore, in a subsequent software update, you may need to restore that file. You don’t get prompted that there’s a new version of OS X Server When you install OS X Server 5, the next time you open the Server app, you should get prompted that the Server app has been replaced and then go through a little assistant. If you don’t, reboot, throw the Server.app in the trash, redownload and reopen the app. That should take care of that issue. Certificates don’t get migrated The /Library/Server/Web/Config/Proxy/apache_serviceproxy.conf file will have a number of certificates. These include SSLCertificateFile, SSLCertificateKeyFile, and SSLCertificateChainFile. In /etc/certificates, you’ll have some certificates. For example, on my server, I have: 4A94D0AE-7DD6-4D8D-A721-D62DE2AAE092.C174963A4CB567837EE8B5FD7EC8DCBE03143CCB.cert.pem 4A94D0AE-7DD6-4D8D-A721-D62DE2AAE092.C174963A4CB567837EE8B5FD7EC8DCBE03143CCB.chain.pem 4A94D0AE-7DD6-4D8D-A721-D62DE2AAE092.C174963A4CB567837EE8B5FD7EC8DCBE03143CCB.concat.pem Server Fallback SSL Certificate.AD80FE0DDF4D16419A158AAA901594FF15D48A2A.cert.pem Server Fallback SSL Certificate.AD80FE0DDF4D16419A158AAA901594FF15D48A2A.chain.pem Server Fallback SSL Certificate.AD80FE0DDF4D16419A158AAA901594FF15D48A2A.concat.pem Server Fallback SSL Certificate.AD80FE0DDF4D16419A158AAA901594FF15D48A2A.key.pem odr.krypted.com.00EA9C581A8C85D48D295807946C0703DAF88F67.cert.pem odr.krypted.com.00EA9C581A8C85D48D295807946C0703DAF88F67.chain.pem odr.krypted.com.00EA9C581A8C85D48D295807946C0703DAF88F67.concat.pem odr.krypted.com.00EA9C581A8C85D48D295807946C0703DAF88F67.key.pem One is built based on the promotion of OD, another is a fallback, and the one with the funny GUID in front of it is usually the one that you’d use when defining these fields. If OS X Server doesn’t see the correct pem files that it’s expecting it will just create new ones. The old ones are still there. So, if a service like Profile Manager is totally busted, you can backup the /Library/Server/Web/Config/Proxy/apache_serviceproxy.conf and edit the path to the certificates in the file to correct them. Reboot and see if Profile Manager fires up. On one machine, I also had to trash the Server app again and install it again, but just pointing the paths to the correct location worked for the most part (also, note that I had to use the full path of a file rather than just the name of the file). Oh, don’t forget, this would need to be done for each virtual host with an offending certificate chain.   Apache binds ports to all IPs A final issue I’ll point out is that servers that I’d customized the IP that Apache listens on needed to be reconfigured. This is done in the see /Library/Server/Web/Config/Apache2/httpd_server_app.conf configuration file. Here, look for a line for Listen. It will be commented out as so:
#Listen 12.34.56.78:80
If you want to only have a given port listen on a given IP, use that section of that file to customize how the listener should operate. For example, if you have an IP on your machine of 10.0.0.100 and you only want port 80 listening on that port, use the following
Listen 10.0.0.100:80
Conclusion Overall, I would say that if you haven’t upgraded to Server 5 on a Yosemite system, that I’d hold off. There are some funny kinks that need to be worked out and I’d hate to be the one figuring some of this out if I wasn’t planning on a funky upgrade session (e.g. if I had a limited downtime window).

September 22nd, 2015

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

Tags: , , , , , , , , ,

Web Services in Mac OS X, Mac OS X Server, Linux and most versions of Unix are provided by Apache, an Open Source project that much of the Internet owes its origins to. Apache owes its name to the fact that it’s “a patchy” service. These patches are often mods, or modules. Configuring web services is as easy in OS X Mavericks Server (10.9) 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. Screen Shot 2013-10-07 at 7.06.28 PMAfter a time, the service will start. Once running, click on the View Server Website link at the bottom of the pane. Screen Shot 2013-10-07 at 7.07.01 PM Provided the stock OS X Server page loads, you are ready to use OS X Server as a web server. Screen Shot 2013-10-07 at 7.07.43 PMBefore 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 added web apps, which we’ll briefly review later in this article as well, as those continue in Mavericks Server.  Finally, enabling PHP and Python on sites is done globally, so this setting applies to all sites hosted on the server. Screen Shot 2013-10-07 at 8.04.38 PMNow 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 Mavericks 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 = "2013-10-08 01:05:32 +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:20:requiredWebAppNames = _empty_array web:definedWebApps:_array_index:20:includeFiles = _empty_array web:definedWebApps:_array_index:20:requiredModuleNames = _empty_array web:definedWebApps:_array_index:20:startCommand = "" web:definedWebApps:_array_index:20:sslPolicy = 0 web:definedWebApps:_array_index:20:requiresSSL = no web:definedWebApps:_array_index:20:requiredByWebAppNames = _empty_array web:definedWebApps:_array_index:20:launchKeys:_array_index:0 = "org.postgresql.postgres" web:definedWebApps:_array_index:20:proxies = _empty_dictionary web:definedWebApps:_array_index:20:preflightCommand = "" web:definedWebApps:_array_index:20:stopCommand = "" web:definedWebApps:_array_index:20:name = "org.postgresql.postgres" web:definedWebApps:_array_index:20:displayName = "" 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.

October 22nd, 2013

Posted In: Mac OS X Server

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

Configuring Calendar Server in Mountain Lion Server is a fairly simple and straight forward process. The Calendar Server is a CalDAV Server, leveraging HTTP and HTTPS, running on ports 8008 and 8443 respectively. To enable the Calendar service in Mountain Lion Server, open the Server application and click on Calendar in the SERVICES section of the sidebar.
Enabling the Calendar Server in Mountain Lion Server

Enabling the Calendar Server in Mountain Lion Server

Once open, click on Edit to enable email notifications of invitations in the Calendar Server. Provide the email address and then click on the Next button.
Mountain Lion Server :: Configuring Email Notifications in Calendar Server

Mountain Lion Server :: Configuring Email Notifications in Calendar Server

At the Configure Server Email Address screen, provide the type of incoming mail service in use, provide the address of the mail server and then the port number used, if not a standard port for HTTPS-based IMAP (or POP if you’d prefer), the user name and the valid password for the account. Then click on the Next button.
Mountain Lion Calendar Server :: Configuring IMAP

Mountain Lion Calendar Server :: Configuring IMAP

At the outgoing mail server screen, provide the Outgoing Mail Server address, the port, whether or not SSL is in use (it should be if possible), the password protocol, the user name and the password. Then click on the Next button.
Mountain Lion Calendar Server :: Verify Settings

Mountain Lion Calendar Server :: Verify Settings

At the Mail Account Summary screen, review the settings and if correct, click Finish. Back at the service configuration screen, click on the plus sign (“+”) and provide a type of location, a name for the location, whether or not invitations to the resource are accepted and then enter the account name for any accounts that can manage the location’s calendar (they will auto-complete, so there’s no need to remember users and groups exactly). Click Done to complete the setup. Use the Resource setting in type to configure a resource instead of a location. The two are the same, except the Type field.
Creating Locations in the Calendar Service of Mountain Lion Server

Creating Locations in the Calendar Service of Mountain Lion Server

There are a number of settings that can also be configured. But those are exposed only at the command line. To configure them, open the command line and then review the list of Calendar service settings using the list option of the serveradmin command: sudo serveradmin settings calendar One of the more common settings to configure is the port number that CalDAV runs on. To configure HTTP: sudo serveradmin settings calendar:HTTPPort = 8008 For HTTPS: sudo serveradmin settings calendar:SSLPort = 8443 You can then start the service using the start option: sudo serveradmin start calendar Or to stop it: sudo serveradmin stop calendar Or to get the status: sudo serveradmin fullstatus calendar Once the Calendar server is configured, use the Calendar application to communicate with the server. Open the Calendar application and click on the Calendar menu and select Preferences. From the Preferences screen, click on Accounts to bring up a list of accounts. Here, click on the plus sign (“+”) to bring up the “Add an Account” screen.
Adding An Account In Mountain Lion's Calendar App

Adding An Account In Mountain Lion’s Calendar App

At the “Add an Account” screen, select CalDAV from the Account Type menu and then enter the User Name and password configured on the server, as well as the address of the server. The User Name is usually the name provided in Server app, followed by @ and then the address of the server.
Account Settings In Mountain Lion's Calendar App

Account Settings In Mountain Lion’s Calendar App

Once the server is configured it appears in the list of accounts in the sidebar of the Calendar app. Create calendars in the account and then to share a calendar, right-click on the calendar and click on Share Calendar…
Sharing a CalDAV Calendar

Sharing a CalDAV Calendar

At the Share Calendar screen, provide the name the calendar should appear as to others and click on the plus sign (“+”) and enter any accounts to delegate administration to.
Mountain Lion Calendar Settings

Mountain Lion Calendar Settings

Back at the Calendar Settings screen, use the settings to configure Availability and refresh rate of calendars, as seen above. Click on Server Settings to assign custom port numbers.
Mountain Lion Calendar Address Screen

Mountain Lion Calendar Address Screen

Click on the Delegation tab to view any accounts you’ve been given access to.
Account Delegation In Mountain Lion's Calendar Server

Account Delegation In Mountain Lion’s Calendar Server

Use the Edit button to configure who has delegated access to calendars, as opposed to configuring subscriptions. Overall, the Calendar service in Mountain Lion Server is one of the easiest to configure. Most of the work goes into settings configured on client systems. This, as with Exchange, dedistributes administration, often making administration more complicated than with many other tools. But that’s a good thing; no one wants to access other peoples accounts, for calendars or mail for that matter, without those users knowing that it was done, as will happen when resetting passwords…

July 30th, 2012

Posted In: Mac OS X, Mac OS X Server, Microsoft Exchange Server

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