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.
krypted September 26th, 2017
Posted In: Mac OS X, Mac OS X Server, Mac Security
Apple, DFS, MAC, macos, SMB, smbutil, statshares
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.
krypted September 26th, 2017
Posted In: Mac OS X Server
Apple, apps, backup, MAC, macos server, upgrade, upgrade server app
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.
krypted September 26th, 2017
Posted In: Mac OS X
APNS, Apple, Apple Certificates, AppleID, MAC, profile manager, server
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:
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
krypted September 26th, 2017
Posted In: Mac OS X Server
Address Book Server, Apple, carddav, cardiac, define servers, macos server, Servers, setup servers
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
krypted September 26th, 2017
Posted In: Mac OS X Server
Apple, enable remote access, enableRemoteAdministration, enableSSH, MAC, macos, Remote Desktop, ssh
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.
krypted September 26th, 2017
Posted In: Mac OS X Server
App Store, Apple, macos, Software Update Service, Software Updates, SUS
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!
krypted September 26th, 2017
Posted In: Mac OS X, Mac Security, Mass Deployment
apfs, Apple, file sharing, high sierra, iMaging, MAC, macos, macos server, Open Directory, profile manager, secure kernel extensions, SKEL, slapconfig, SMB, Software Update, upgrade
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.
krypted September 15th, 2017
Posted In: Mac OS X
Apple, high sierra, MAC, macos, profiles to install at boot, startup profiles
DNS is DNS. And named is named. Except in macOS Server. Sometimes. The configuration files for the DNS services in macOS Server are stored in /Library/Server/named. This represents a faux root of named configuration data, similar to how that configuration data is stored in /var/named on most other platforms. Having the data in /Library/Server/ makes it more portable across systems.
The current version of BIND is BIND 9.9.7-P3 (Extended Support Version). This has been the case for a number of macOS Server versions, and can easily be located by doing a cat of the /Library/Server/named/.version file.
Traditionally, you would edit this configuration data by simply editing the configuration files, and that’s absolutely still an option. In macOS Server 5.2 (for Sierra), a new command is available at /Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/DNSManager.framework called dnsconfig. The dnsconfig command appears simple at first. However, the options available are actually far more complicated than they initially appear.
The verbs available include:
- help: show help information
- list: show the contents of configurations and zone files
- add: create records and zones
- delete: remove records and zones
To view data available in the service, use the list verb. Options available when using the list verb include:
- –acl: show ACLs
- –view: show BIND view data
- –zone: show domains configured in the service
- –rr: show resource records
- –rrtype: show types of resource records
For example, let’s say you have a domain called pretendco.lan and you would like to view information about that zone. You could use the dnsconfig command along with the list verb and then the –zone option and the domain name:
/Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/DNSManager.framework/dnsconfig list --zone=pretendco.lan
The output would show you information about the listed zone, usually including View data:
To see a specific record, use the –rr option, followed by = and then the fqdn, so to see ecserver.pretendco.lan:
/Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/DNSManager.framework/dnsconfig list --rr=ecserver.pretendco.lan
By default views are enabled and a view called com.apple.ServerAdmin.DNS.public is created when the DNS server first starts up. You can create other views to control what different requests from different subnets see; however, even if you don’t create any views, you’ll need to add the –view option followed by the name of the view (–view=com.apple.ServerAdmin.DNS.public) to any records that you want to create. To create a record, use the add verb. You can add a view (–view), a zone (–zone) or a record (–rr). Let’s start by adding a record to the pretendco.lan from our previous example. In this case we’ll add an A record called www that points to the IP address of 192.168.210.201:
/Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/DNSManager.framework/dnsconfig add --view=com.apple.ServerAdmin.DNS.public --zone=pretendco.lan --rr=www A 192.168.210.201
You can add a zone, by providing the –view to add the zone to and not providing a –rr option. Let’s add krypted.lan:
/Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/DNSManager.framework/dnsconfig add --view=com.apple.ServerAdmin.DNS.public --zone=krypted.lan
Use the delete verb to remove the data just created:
/Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/DNSManager.framework/dnsconfig delete --view=com.apple.ServerAdmin.DNS.public --zone=krypted.lan
Or to delete that one www record earlier, just swap the add with a delete:
/Applications/Server.app/Contents/ServerRoot/System/Library/PrivateFrameworks/DNSManager.framework/dnsconfig delete --view=com.apple.ServerAdmin.DNS.public --zone=pretendco.lan --rr=www A 192.168.210.201
Exit codes would be “Zone krypted.lan removed.” and “Removed 1 resource record.” respectively for the two commands. You can also use the –option option when creating objects, along with the following options (each taken as a value followed by an =, with this information taken by the help page):
- allow-transfer Takes one or more address match list entry. Address match list entries consist of any of these forms: IP addresses, Subnets or Keywords.
- allow-recursion Takes one or more address match list entry.
- allow-update Takes one or more address match list entry.
- allow-query Takes one or more address match list entry.
- allow-query-cache Takes one or more address match list entry.
- forwarders Takes one or more IP addresses, e.g. 10.1.1.1
- directory Takes a directory path
- tkey-gssapi-credential Takes a kerberos service principal
- tkey-domain Takes a kerberos realm
- update-policy Takes one complete update-policy entry where you can grant or deny various matched objects and specify the dentity of the user/machine that is allowed/disallowed to update.. You can also identify match-type (Type of match to be used in evaulating the entry) and match-name (Name used to match) as well as rr-types (Resource record types that can be updated)
Overall, this command is one of the best I’ve seen for managing DNS in a long time. It shows a commitment to continuing to make the service better, when you add records or remove them you can instantly refresh the Server app and see the updates. It’s clear a lot of work went into this and it’s a great tool for when you’re imaging systems and want to create records back on a server or when you’re trying to script the creation of a bulk list of records (e.g. from a cached file from a downed host). It also makes working with Views as easy as I’ve seen it in most platforms and is overall a breeze to work with as compared to using the serveradmin command to populate objects so the GUI doesn’t break when you update records by hitting files directly.
Additionally, you can manage bind in a variety of other ways. There are global settings exposed with the bind -v command:
Which returns something similar to the following:
set bind-tty-special-chars on
set blink-matching-paren on
set byte-oriented off
set completion-ignore-case off
set convert-meta off
set disable-completion off
set enable-keypad off
set expand-tilde off
set history-preserve-point off
set horizontal-scroll-mode off
set input-meta on
set mark-directories on
set mark-modified-lines off
set mark-symlinked-directories off
set match-hidden-files on
set meta-flag on
set output-meta on
set page-completions on
set prefer-visible-bell on
set print-completions-horizontally off
set show-all-if-ambiguous off
set show-all-if-unmodified off
set visible-stats off
set bell-style audible
set comment-begin #
set completion-query-items 100
set editing-mode emacs
set keymap emacs
krypted September 10th, 2017
Posted In: Mac OS X Server
Apple, bind, bind view, create zone, DNS, dnsconfig, hoot, macos server, manage dns, named, scripting dns, use, Version
« Previous Page
Server comes with a command called RoomsAdminTool located at /Applications/Server.app/Contents/ServerRoot/usr/bin/RoomsAdminTool. This tool can list available rooms using a -l flag:
You can also create new rooms, using the following format, where krypted is the name of the room, the persistent option means the room is, er, persistent. The description option indicates a description used for the room.
RoomsAdminTool -n krypted -c persistent yes description "This room is for friends of krypted only”
To then delete the room, use the -d option:
RoomsAdminTool -n krypted -d
Add the -v to do it all verbosely. There are lots of other options as well, as follows (from the man page):
Valid Configuration Keys and Values:
| KEY||VALID VALUES||DESCRIPTION
|description||string||A short description for the room
|password||string||Define a password for room entry. An empty string implies no password required.
|membersOnly||yes | no||Only room members are allowed to enter the room.
|subjectLocked||yes | no||Are non-moderators and non-admins prevented from setting the room subject
|logFormat||Disabled | Text | XHTML||Disable room logging, or enable it using Text or XHTML.
|maxUsers||integer; 0 for unlimited||Set the maximum allowed occupants for the room.
|moderated||yes | no ||Make the room "moderated".
|nonAnonymous||yes | no||If "yes", only moderators/owners can discover occupants' real JIDs.
|persistent||yes | no||Persistent rooms stay open until they are explicitly destroyed and their configuration survives service restarts, unlike non-persistent rooms.
|privateMessagesAllowed||yes | no ||Whether or not occupants can exchange private messages within the room.
|roomPublic||yes | no ||Defines whether the room be discovered by anyone
|subject||string||Set a room subject/topic
|usersCanInvite||yes | no ||Defines whether occupants can invite other users to enter the room
|addOwner||valid JabberID||Make the specified user a room owner (ex.: firstname.lastname@example.org). Rooms can have multiple owners.
|removeOwner||valid JabberID||Remove the specified user from the room owner list
|addAdmin||valid JabberID||Make the specified user a room admin
|removeAdmin||valid JabberID||Remove the specified user from the room admin list
|addMember||valid JabberID||Make the specified user a room member
|removeMember||valid JabberID||Remove the specified user from the room member list
|addOutcast||valid JabberID||Make the specified user a room outcast (banned from public rooms)
|removeOutcast||valid JabberID||Remove the specified user from the room outcast list
Ultimately, if you’d like to do Student Information System (SIS) integration, or wait for an AD/OD group and then programmatically generate rooms, this is how you’d do it. Also, it’s worth noting that Messages (and so Jabber if you’re running your own server) is a very basic instant messaging tool. There are more modern ways of interacting with others these days, including Slack and Confluence. Additionally, the Messages app can just use the phone number of people to let address books become a way of managing groups you’d like to message. These do not require a dedicated server, but most strategies will require a monthly fee that’s typically per-user.
krypted September 9th, 2017
Posted In: Mac OS X Server
Apple, create rooms, devices, jabber, MAC, scripting
— Next Page »