krypted.com

Tiny Deathstars of Foulness

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 macOS Server 5.4 for High Sierra, all of these are represented by a single ON button, so it really couldn’t be easier, once you can just enter email addresses into the Users section.

But then there’s the ecoysystem and the evil spammers. They’re totally the worst. Like ever. As the former systems administrator of a large number of mail servers, I firmly believe that there is a special kind of hell where only deep fried 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 plenty of chemically induced stamina, enough pills of other types to not be able to use that stamina, plenty of 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, so DUH?!?!?), have their conflicting stamina situation at the top of the search engines and of course, have lost all of the money made from their 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 in the Server app running on Yosemite. Actually, first let’s setup our SSL certificates. To do so, open the Server app and click on Certificates in the SERVER section of the sidebar. Here, use the “Secure services using” drop-down list and click on Custom… 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:
  • Status: Indicates if the server is running.
  • Edit Permissions: Limits the IP addresses capable of connecting to the server.
  • Domains: 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.
  • Push Notifications: If Push is configured previously there’s no need to use this option. Otherwise, use your institutional APNS account to configure Push Notifications.
  • Mail Relay: 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).
  • Mailbox size: Configure the total amount of mail a user can have in the mail store, in Megabytes.
  • Filtering: 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:startedTime = "" mail:setStateVersion = 1 mail:state = "STOPPED" 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 = "STOPPED" mail:protocolsArray:_array_index:0:service = "MailAccess" 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 = "STOPPED" mail:protocolsArray:_array_index:1:service = "MailAccess" 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 = "STOPPED" mail:protocolsArray:_array_index:2:service = "MailTransferAgent" 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 = "STOPPED" mail:protocolsArray:_array_index:3:service = "MailTransferAgent" mail:protocolsArray:_array_index:3:error = "" mail:protocolsArray:_array_index:4:status = "OFF" mail:protocolsArray:_array_index:4:kind = "INCOMING" mail:protocolsArray:_array_index:4:protocol = "" mail:protocolsArray:_array_index:4:state = "STOPPED" mail:protocolsArray:_array_index:4:service = "ListServer" 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 = "" mail:protocolsArray:_array_index:5:state = "STOPPED" mail:protocolsArray:_array_index:5:service = "JunkMailFilter" mail:protocolsArray:_array_index:5:error = "" mail:protocolsArray:_array_index:6:status = "ON" mail:protocolsArray:_array_index:6:kind = "INCOMING" mail:protocolsArray:_array_index:6:protocol = "" mail:protocolsArray:_array_index:6:state = "STOPPED" mail:protocolsArray:_array_index:6:service = "VirusScanner" mail:protocolsArray:_array_index:6:error = "" mail:protocolsArray:_array_index:7:status = "ON" mail:protocolsArray:_array_index:7:kind = "INCOMING" mail:protocolsArray:_array_index:7:protocol = "" mail:protocolsArray:_array_index:7:state = "STOPPED" mail:protocolsArray:_array_index:7:service = "VirusDatabaseUpdater" mail:protocolsArray:_array_index:7:error = "" mail:logPaths:Server Error Log = "/Library/Logs/Mail/mail-err.log" mail:logPaths:IMAP Log = "/Library/Logs/Mail/mail-info.log" mail:logPaths:Server Log = "/Library/Logs/Mail/mail-info.log" mail:logPaths:POP Log = "/Library/Logs/Mail/mail-info.log" mail:logPaths:SMTP Log = "/var/log/mail.log" mail:logPaths:List Server Log = "/Library/Logs/Mail/listserver.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 = "" mail:postfixStartedTime = "" mail:servicePortsRestrictionInfo = _empty_array mail:servicePortsAreRestricted = "NO" mail:connectionCount = 0 mail:readWriteSettingsVersion = 1 mail:serviceStatus = "DISABLED" 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…

September 26th, 2017

Posted In: Mac OS X Server

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

Yosemite brought Xsan 4, which included a whole new way to add clients to an Xsan. Xsan Admin is gone, as of El Capitan, but unchanged from then to macOS Sierra (other than a couple of binaries moving around). These days, instead of scanning the network using Xsan Admin. we’ll be adding clients using a Configuration Profile. This is actually a much more similar process to adding Xsan clients to a StorNext environment than it is to adding clients to Metadata Controllers running Xsan 3 and below. But instead of making a fsnameservers file, we’re plugging that information into a profile, which will do that work on the client on our behalf. To make the Xsan configuration profile, we’re going to use Profile Manager. With macOS Server 5, 5.2, and now 5.4 this trend continues.

To get started, open the Profile Manager web interface and click on a device or device group (note, these are scoped to systems so cannot be used with users and user groups). Then click on the Settings tab for the object you’re configuring Xsan for.
 
Click Edit for the profile listed (Settings for <objectname>) and scroll down until you see the entry for Xsan.

From the Xsan screen, click Configure.
 
This next screen should look a little similar, in terms of the information you’ve plugged into the Xsan 4 setup screen. Simply enter the name of the Xsan in the Xsan Name field, the IP address or host names of your metadata controllers in the File System Name Servers field and the Authentication Secret from the Xsan screen in the Server app into the Authentication Secret field. Click OK to close the dialog.
 
Click Save to save your changes. Then you’ll see the Download button become clickable. Choose the Mac option, and the profile will download to your ~/Downloads directory as Settings_for_<OBJECTNAME>.mobileconfig.

So this was called test and will result in a name of Settings_for_test.mobileconfig. That profile will automatically attempt to install. If this is an MDC where you’re just using Profile Manager to bake a quick profile, or if you don’t actually want to install the profile yet, click Cancel.

 

If you haven’t worked with profiles that much, note that when you click Show Profile, it will show you what is in the profile and what the profile can do.

 

Simply open this file on each client (once you test it of course) and once installed, they’ll automatically configure to join your Xsan. If you don’t have a Profile Manager server, you can customize this file for your environment (YMMV): Settings_for_test.mobileconfig

September 26th, 2017

Posted In: Xsan

Tags: , , , , ,

The statshares option has an -m option to look at a mount path for showing the path to the mount (e.g. if the mount is called krypted this should be something like /Volumes/krypted):

smbutil statshares -m /Volumes/krypted

When run, you see a list of all the attributes OS X tracks for that mount path, including the name of the server, the user ID (octal), how SMB negotiated an authentication, what version of SMB is running (e.g. SMB_1), the type of share and whether signing, extended security, Unix and large files are supported. Additionally, if you’d like to see the attributes for all shares, use the -a option after statshares:

smbutil statshares -a

You’ll then see the SHARE, ATTRIBUTE TYPE, and VALUE for each share mounted. Overall, this is a nice health check type of verb to the smbutil command that can be added to any monitoring or troubleshooting workflow.

September 26th, 2017

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

Tags: , , , , , ,

The latest version of macOS Server (5.4) is now available to be installed. To do so, first backup your server. Then, backup your server again, making sure you have a functional, bootable clone. Once you’re sure you have a solid backup of your server, open the App Store and search for Server. When you find the Server app, click on it.  

Once downloaded, you’ll be prompted that the Server app has been replaced.

Go into Applications and open the Server app. When prompted, click on Install (or Open if the server is already installed).

The download will begin. Once complete, you’ll see a notice that the “Server app replacement detected.” Click OK. Then, open the Server app. When the Server app opens, you’ll be prompted to update the server. Click Continue.  

At the Licensing Agreement screen, click Agree. At the screen to confirm your administrative access, provide a name and password for an account with administrative access and then click on Allow. Services are then upgraded. Once complete, the Server app will open and should have settings consistent with the settings prior to the upgrade. 

September 26th, 2017

Posted In: Mac OS X Server

Tags: , , , , , ,

Push Notifications can be used in most every service that macOS Server 5.4 (for High Sierra) can run. Any service that requiring Push Notifications will often 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. Then click on the Settings screen and click on the checkbox for Notifications.


At the Settings screen for your server, click on the check-box for Apple Push Notifications (APN). Next, click on another screen and then click back to get the Edit Apple ID… button to appear. Click on Edit Apple ID…  



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.
 

As you’ll see, if you’re editing a certificate, you’ll break any systems or services that use that certificate. For example, you would have to re-enroll all of your Profile Manager systems. Instead, use the Renew button whenever possible, prior to the expiration of certificates.  

When renewing certificates, you’ll provide the SAME AppleID and Password you used to generate the original certificate.
 

The certificate is valid for one year, by default. Administrators receive an alert when the certificate is due to expire. If you don’t have the credentials for the AppleID used to obtain the original certificate you can’t renew; in that scenario, open the same screen and click on the Change button. Once you have generated a certificate, you’ll then be able to see the certificate in the Apple certificates portal, but you’ll have to re-enroll devices if using Profile Manager.

September 26th, 2017

Posted In: Mac OS X

Tags: , , , , , ,

Every Mac by default has an application called Contacts. Every macOS Server 5.4, running on High Sierra, has a service called Contacts. While the names might imply very different things that they do, you’ll be super-surprised that the two are designed to work with one another. The Contacts service is based on CardDAV, a protocol for storing contact information on the web, retrievable and digestible by client computers. However, there is a layer of database-driven obfuscation between the Contacts service and CardDAV. 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 macOS 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 Contacts entry in the SERVICES section of Server app.

Click the Edit Notifications button to configure the Apple Push Notification settings for the computer. When prompted, click on Enable Notifications.

If prompted, 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 the Accounts menu and then click on Add Accounts.

At the Add Account screen, scroll down and click Add Other Account… to bring up an expanded menu of account types. Click “CardDAV account”.

At the “Add a Contacts Account” screen, enter the email address and password of the user. Auto discovery doesn’t always work, so you might end up using the manual button to add the account using the server’s address. Alternatively, if you’ve mapped CardDAV to custom ports, you may use the advanced option to have paths and ports available.

When the account is finished creating, you can click on the account again to see the settings used. Otherwise, close the Preferences/Accounts screen and then view the list of Contacts. Click on View and then Show Groups. This will show you the name of the servers that you’re connected to in the sidebar. There won’t be any contacts yet, so click on the plus sign to verify you have write access to the server.
 
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 Account 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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings addressbook:SSLPort = 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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings addressbook:ServerRoot = "/Volumes/Pegasys/CardDAV"

When changing the ServerRoot, you’ll likely need to change the DataRoot, which is usually the Data directory immediately underneath the ServerRoot. To do so, run serveradmin and put the DataRoot entry under the addressbook settings:

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings addressbook:DataRoot = "/Volumes/Pegasys/CardDAV/Data"

The service is then stopped with the serveradmin command:

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin stop addressbook

And started with the serveradmin command:

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin fullstatus addressbook

The output of which should be as follows:

status addressbook
addressbook:state = “RUNNING”
addressbook:setStateVersion = 1
addressbook:readWriteSettingsVersion = 1

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

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings calendar

By default, the Contacts server allows basic authentication. We’ll just turn that off real quick:

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings addressbook:Authentication:Basic:Enabled = no

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

/Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings addressbook:Authentication:Basic:Enabled

September 26th, 2017

Posted In: Mac OS X Server

Tags: , , , , , , ,

SSH allows administrators to connect to another computer using a secure shell, or command line environment. ARD (Apple Remote Desktop) allows screen sharing, remote scripts and other administrative goodness. You can also connect to a server using the Server app running on a client computer. To enable any or all of these, open the Server app (Server 5.4 for High Sierra), click on the name of the server, click the Settings tab and then click on the checkbox for what you’d like to enter.

 
All of these can be enabled and managed from the command line as well. The traditional way to enable Apple Remote Desktop is using the kickstart command. But there’s a simpler way in macOS Server 5.4 for High Sierra. To do so, use the serveradmin command. To enable ARD using the serveradmin command, use the settings option, with info:enableARD to set the payload to yes:

sudo serveradmin settings info:enableARD = yes

Once run, open System Preferences and click on Sharing. The Remote Management box is then checked and the local administrative user has access to ARD into the host.


When you enable, you’ll be prompted for what permissions to provide access to:


There are also a few other commands that can be used to control settings. To enable SSH for administrators:

sudo serveradmin settings info:enableSSH = yes

When you enable SSH from the serveradmin command you will not see any additional checkboxes in the Sharing System Preferences; however, you will see the box checked in the Server app. To enable SNMP:

sudo serveradmin settings info:enableSNMP = yes

Once SNMP is enabled, use the /usr/bin/snmpconf interactive command line environment to configure SNMP so you can manage traps and other objects necessary. Note: You can’t have snmpd running while you configure SNMPv3. Once SNMPv3 is configured snmpd can be run.  To allow other computers to use the Server app to connect to the server, use the info:enableRemoteAdministration key from serveradmin:

sudo serveradmin settings info:enableRemoteAdministration = yes

To enable the dedication of resources to Server apps (aka Server Performance Mode):

sudo serveradmin settings info:enableServerPerformanceMode = yes

September 26th, 2017

Posted In: Mac OS X Server

Tags: , , , , , , ,

The software patching configuration built into most operating systems is configured so all that a user has to do is open a box at home, join the network and start using the computer right away. As environments grow from homes to small offices and then small offices grow into enterprises, at some point software updates and patches need to be managed centrally.

macOS heavily leverages the App Store. This allows administrators to pretty much be hands off when it comes to managing updates. But some environments need to control the flow of updates anyway. Apple has had this ability since the early days of OS X and in macOS, you can still control software update servers, which look at XML feeds on Apple servers, and allows or denies access to those updates, and then optionally syncs updates to a server at your office. That’s called the Software Update service. Apple also has a service called Caching, now built into all client operating systems. The Caching service also caches apps from the App Store and optionally content. This is built into the Sharing System Preference pane.

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. 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://osxserver.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 “Automatically 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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin start swupdate

To stop the service, replace start with stop:

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin fullstatus swupdate

The output of which appears as follows:

swupdate:state = "RUNNING" swupdate:lastChecktime = 2015-08-07 01:25:05 +0000 swupdate:syncStatus = "INPROGRESS" swupdate:syncServiceState = "RUNNING" swupdate:setStateVersion = 1 swupdate:lastProductsUpdate = 2015-08-16 04:02:16 +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:pluginVers = "10.11" swupdate:checkError = no swupdate:updatesDocRoot = "/Library/Server/Software Update/Data/" swupdate:hostServiceState = "RUNNING" swupdate:autoMirror = no swupdate:numOfEnabledPkg = 0 swupdate:servicePortsAreRestricted = "NO" swupdate:numOfMirroredPkg = 0 swupdate:autoMirrorOnlyNew = no swupdate:startTime = 2015-08-07 01:25:05 +0000 swupdate:autoEnable = no

There are also a number of options available using the serveradmin settings that aren’t exposed to the Server app. Available Settings include:
  • swupdate:checkError = no
  • swupdate:limitBandwidth = no
  • swupdate:PurgeUnused = yes
  • swupdate:portToUse = 8088
  • swupdate:autoEnable = yes
  • swupdate:valueBandwidth = 0
  • swupdate:syncStatus = “Initializing” swupdate:autoMirror = yes
  • swupdate:syncBandwidth = 0
  • swupdate:updatesDocRoot = “/Library/Server/Software Update/Data/”
  • swupdate:autoMirrorOnlyNew = no
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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings swupdate:autoMirrorOnlyNew = yes

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

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings swupdate:limitBandwidth = yes

And configure bandwidth using the syncBandwidth option, as follows:

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings swupdate:portToUse = 80

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

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings swupdate:PurgeUnused = yes

One of the biggest drawbacks of the Software Update service in OS X El Capitan Server in my opinion is the fact that it does not allow for serving 3rd party packages (not that Apple has much control over this, since these aren’t sourced from the App Store), 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 macOS. 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 macOS 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 Jamf Pro (JAMF also makes a reposado-based VM that mimics the swupdate options), FileWave, and others (or a combination of some of these). Overall, the update service in Server 5 is easily configured, easily managed and easily deployed to clients but slowly being replaced with the App Store and release management via MDM-based commands.

September 26th, 2017

Posted In: Mac OS X Server

Tags: , , , , ,

The latest version of the Apple Server app is out (macOS Server 5.4), and before you upgrade, there are a few points to review:
  • As always, make a clone of your computer before upgrading.
  • During the upgrade to High Sierra, if the operating system is running on a solid state drive, the drive will automatically upgrade to APFS. You cannot share APFS volumes over AFP, so if you’re running file services, make sure you’re aware of that. You can choose not to upgrade to APFS using the command line to upgrade a server. Even though the file sharing services are not in the Server app, you can still configure ACLs using the Storage tab under the server’s main screen.
  • The FTP Service is gone.
  • Time Machine service is gone, so if you were relying on that, rethink your backup strategy. Some options:
    • A third party backup tool.
    • A share that Time Machine on client systems can backup to.
    • Don’t upgrade.
  • Xcode Server is gone. You can still leverage third party tools to get build automations in place, but this is no longer a built-in component of macOS Server. 
  • Imaging is dead. But NetInstall still works. Because you need to run a firmware update for High Sierra (and APFS), there are caveats to imaging. You can run a NetInstall to install High Sierra onto clients (which does the firmware update). You can do a NetRestore (and Define NetRestore Sources for NetBoot) from a volume that’s already been converted to APFS to another volume that’s already been converted to APFS. But you can’t NetRestore an HFS+ volume onto an APFS volume or High Sierra on APFS onto a volume running HFS+. Long live DEP.
  • If you’re running Calendar, Contacts, and/or Mail, then you should consider moving to Google Apps or Office 365.
  • Running the Wiki service configures passwords to use a less secure way of storing passwords.
  • Alerts, Certificates, Logs, Stats, creating users, Calendar, Contacts, Mail, Messages, VPN, Websites, Wiki, DHCP, DNS, and Xsan haven’t changed in forevers, and remain pretty static in this version.
  • Open Directory and Software Update aren’t in the Services or Advanced area of the Server sidebar. You’ll access those through the View menu. The slapconfig and other binaries that comprise OD remain pretty much untouched where they are.
  • If you’re running software like anti-virus that has Kernel Extensions, those should work upon upgrade (provided they’re High Sierra compatible). If you reinstall software with Kernel Extensions, you may have to accept the installation of the Kernel Extension, due to a new and more secure way of interacting with Kernel Extensions.
  • There are new options in Profile Manager. 
Provided that you’re ok with all this, we can proceed with the upgrade!

September 26th, 2017

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

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

Startup profiles configure profiles to install at the next boot, rather than immediately. Useful in a number of scenarios. Use the -s to define a startup profile and take note that if it fails, the profile will attempt to install at each subsequent reboot until installed. To use the command, simply add a -s then the -F for the profile and the -f to automatically confirm, as follows (and I like to throw in a -v usually for good measure):

profiles -s -F /Profiles/SuperAwesome.mobileconfig -f -v

And that’s it. Nice and easy and you now have profiles that only activate when a computer is started up.

September 15th, 2017

Posted In: Mac OS X

Tags: , , , , ,

« Previous PageNext Page »