krypted.com

Tiny Deathstars of Foulness

There are some commands where you just have to wonder why. Sure, I see what this command does, but why bother? Well, I’m not going to say that xsanadmin is one of those commands, but I’m not going to say that it isn’t. At first glance, you might think that the list, stop, start and other verbs look promising. Like maybe you can actually administer a volume from a much simpler to use command line interface. However, if you want a quick and dirty of what xsanadmin does, look no further than just running the command without any verbs or operators: xsanadmin The result is help information from the serveradmin command: Usage: serveradmin [-dhvx] [list | start | stop | status | fullstatus | settings | command] [<service_key> [ = <value> ]] -h, --help display this message -v, --version display version info -d, --debug print command -x, --xml print output as XML plist Examples: serveradmin list --Lists all services serveradmin start afp --Starts afp server serveradmin stop ftp --Stops ftp server serveradmin status web --Returns current status of the web server serveradmin fullstatus web --Returns more complete status of the web server serveradmin settings afp --Returns all afp configuration parameters serveradmin settings afp:guestAccess --Returns afp guestAccess attribute serveradmin settings afp:guestAccess = yes --Sets afp guestAccess to true serveradmin settings --Takes settings commands like above from stdin serveradmin command afp:command = getConnectedUsers --Used to perform service specific commands serveradmin command --Takes stdin to define generic command that requires other parameters Why’s that? Because all the command is doing is piping information to and from the serveradmin command, thus the verbs are basically the same: list, status, fullstatus, etc. To see which services, let’s pipe settings for all to a file: xsanadmin settings all > xsanadminsettings.txt Here, you’ll notice that you have settings for the xsan/san service, file sharing and info. That’s it. You may be asking yourself, “why did you write this article then?” My answer would be that I’m not really sure. Mostly because I wasted my time trying to see if I could do cool stuff with this command and it turns out I can’t…

October 11th, 2013

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

Tags: , , , , , , , ,

OS X Mountain Lion has a lot of scripts used for enabling services, setting states, changing hostnames and the like. Once upon a time there was a script for OS X Server called server setup. It was a beautiful but too simplistic kind of script. Today, much of that logic has been moved out into more granular scripts, kept in /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup, used by the server to perform all kinds of tasks. These scripts are, like a lot of other things in Mountain Lion Server. Some of these include the configuration of amavisd, docecot and alerts. These scripts can also be used for migrating services and data, such as /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/30-ipfwmigrator. Sometimes the scripts are in bash, sometimes ruby, sometimes perl and other times even python. Additionally, there’s a directory /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/ that is full of scripts for migrating services in OS X Server, helpful for even services that have been seemingly deprecated. One of the things that can can be useful about the scripts scattered throughout the Server app is to learn how the developers of OS X Server intend for certain tasks to occur. One such example is /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/loggather.sh, used to grab logs. Here, you can learn the locations of certain logs as well as rudimentary stackshot commands. This is where I started calling stackshot before I did Server installs (or during), using the following command, which creates a custom text file containing : /usr/libexec/stackshot -i -f /Library/Logs/ServerSetup_StackShot_KRYPTED.txt This is also where I learned that I can tail /tmp/SetupLogs.tgz during some installs to be able to watch what’s going on during the installation process: tail -f /tmp/SetupLogs.tgz Looking At Each Service This is also where I learned that Apple had put an Open Directory backup script in /Applications/Server.app/Contents/ServerRoot/usr/libexec/server_backup/opendirectorybackup (that still requires a password). But what I haven’t seen in all of these logs is bumping up the logging level for services before performing tasks, so that you can see a verbose output of what’s going on. To do this, it looks like we’re going service-by-service. So let’s look alphabetically, starting with Address Book: sudo serveradmin settings addressbook:DefaultLogLevel = "warn" This by defualt logs to /var/log/caldavd/error.log, which is built based on the following, which sets the base: sudo serveradmin settings addressbook:LogRoot=/var/log/caldavd And the following, which sets the file name in that directory: sudo serveradmin settings addressbook:ErrorLogFile=error.log You can change either by changing what comes after the = sign. Next is afp. This service logs output to two places. The first is with errors to the service, using /Library/Logs/AppleFileService/AppleFileServiceError.log, the path designated in the following: sudo serveradmin settings afp:errorLogPath = "/Library/Logs/AppleFileService/AppleFileServiceError.log" The second location logs activities (open file, delete file, etc) rather than errors and is /Library/Logs/AppleFileService/AppleFileServiceAccess.log, defined using: sudo serveradmin settings afp:activityLogPath = "/Library/Logs/AppleFileService/AppleFileServiceAccess.log" The activity log is disabled by default and enabled using the command: sudo serveradmin settings afp:activityLog = yes The events that trigger log entries are in the afp:loggingAttributes array and are all enabled by default. There are no further controls for the verbosity of the afp logs. The next service is calendar. Similar to address book, the caldav server uses DefaultLogLevel to set how much data gets placed into logs: sudo serveradmin settings calendar:DefaultLogLevel = "warn" This by defualt logs to /var/log/caldavd/error.log, which is built based on the following, which sets the base: sudo serveradmin settings calendar:LogRoot=/var/log/caldavd And the following, which sets the file name in that directory: sudo serveradmin settings calendar:ErrorLogFile=error.log You can changing either by changing what comes after the = sign. Profile Manager is called devicemgr in the serveradmin interface and I’ve found no way to augment the logging levels. Nor does its migration script ( /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/80-devicemgrmigration.sh ) point to any increased logging during migration. The dirserv (aka Open Directory) uses the slapconfig back-end, so I use slapconfig to increase logging: sudo slapconfig -enableslapdlog The DNS service uses named.conf, located in /etc to set log levels and has no serveradmin settings for doing so. Here, use the logging section and look for both the file setting (by default /Library/Logs/named.log) for where the log is stored as well as the severity setting, which can set the logging levels higher or lower. By default Messages, or iChat Server, logs a lot. See the following for what is logged: sudo serveradmin settings jabber:logLevel = "ALL" Adding the -D option to the LaunchDaemon that invokes jabber will increase the logs. Logging long-term is handled in each of the xml files that make up the features of jabber. See the Logconfiguration section of the c2s file via: cat /Applications/Server.app/Contents/ServerRoot/private/etc/jabberd/c2s.xml The mail service has a number of options for logging, much of which has to do with the fact that it’s a patchy solution made up of postfix, etc. To see the virus database logging levels (which should usually be set to warn): sudo serveradmin settings mail:postfix:virus_db_log_level To see the spamassassin logging levels: sudo serveradmin settings mail:postfix:spam_log_level To see the actual postfix logging level: sudo serveradmin settings mail:postfix:log_level To enable timestamps on logs: sudo serveradmin settings mail:imap:logtimestamps = yes To set the dovecot logging: sudo serveradmin settings mail:imap:log_level = "warn" To set increased logging per function that dovecot performs, see the config files in /Applications/Server.app/Contents/ServerRoot/private/etc/dovecot/default/conf.d, each of which has a logging section to do so. The NetBoot service is simple to configure logging for, simply set the netboot:logging_level to HIGH (by default it’s MEDIUM): sudo serveradmin settings netboot:logging_level = "HIGH" The Postgres service uses a log directory, configured with postgres:log_directory: sudo serveradmin settings postgres:log_directory = "/Library/Logs/PostgreSQL" The /private/etc/raddb/radiusd.conf has a section (log {}) dedicated to configuring how the radius service logs output. The san service (Xsan) logs output per volume to both the System Log and volume-based log files, stored in /Library/Preferences/Xsan/data. The smb service has a file /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist with a key for log level that can be used for more verbose output of the service. The PPTP VPN service logs output to the file specified in vpn:Servers, configured with these: sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:Server:LogFile = "/var/log/ppp/vpnd.log" sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:LogFile = "/var/log/ppp/vpnd.log" sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:Server:LogFile = "/var/log/ppp/vpnd.log" sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:LogFile = "/var/log/ppp/vpnd.log" By default, verbose logging is enabled, which you can see with: sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:Server:VerboseLogging sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:VerboseLogging sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:Server:VerboseLogging sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:VerboseLogging The last service is web (Apache). The default access logs are per-site, with a key called customLogPath existing for each. The defaultSite uses the following for its logs: sudo serveradmin settings web:defaultSite:customLogPath Swap out the defaultSite with another site to see its log paths. There’s also a key for errorLogPath that shows errors. These are per-site so that administrators can provide access to logs for the owners of each site and not fear them having access to logs for other users. Global error logs are stored in /private/var/log/apache2/error_log as defined in /private/etc/apache2/httpd.conf. Find LogLevel in this file and set it to configure how in depth the logs will be, using debug for the most verbose and info, notice, warn, error, crit, alert, and emerg to get incrementally less information. Additionally the log formats can be set in /private/etc/apache2/httpd.conf, allowing administrators to configure Mountain Lion Server’s built-in web service to conform to the standards of most modern web log analyzers. Conclusion Overall, there’s a lot of information in these logs and administrators can spend as much time reviewing logs as they want. But other than standard system logs, the output is typically configured on a service-by-service basis. Some services offer a lot of options and others offering only a few. Some services also offer options within the serveradmin environment while others use their traditional locations in their configuration files. I’ll end this with a warning. There can also be a lot of output in these logs. Therefore, if you set the logging facilities high, make sure to keep a watchful eye on the capacity of the location you’re writing logs out to. The reason I looked at paths to logs where applicable was because you might want to consider redirecting logs to an external volume when debugging so as not to fill up a boot volume and cause even more problems than what you’re likely parsing through logs looking to fix…

August 21st, 2012

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

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

The traditional way to enable Apple Remote Desktop is using the kickstart command. But there’s a simpler way in OS X Mountain Lion Server. 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. The Server app will also have the “Enable screen sharing and remote management” option checked. 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 To enable SNMP: sudo serveradmin settings info:enableSNMP = yes To enable the dedication of resources to Server apps (aka Server Performance Mode): sudo serveradmin settings info:enableServerPerformanceMode = yes

August 14th, 2012

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

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

Mountain Lion has an application called Contacts. Mountain Lion Server has a service called Contacts. While the names might imply differently, surprisingly the two are designed to work with one another. The Contacts service was called Address Book in Lion and below and is based on CardDAV, a protocol for storing contact information on the web, retrievable and digestible by client computers. The Contacts service is also a conduit with which to read information from LDAP and display that information in the Contacts client, which is in a way similar to how the Global Address List (GAL) works in Microsoft Exchange. I know I’ve said this about other services in Mountain Lion Server, but the Contacts service couldn’t be easier to configure. First, you should be running Open Directory and you should also have configured Apple Push Notifications. To setup Push Notifications, have an Apple ID handy and click on the name of the server in the Server app. Then click on Settings and check the box for “Enable Apple push notifications”. Provide the username and password for the Apple ID and then click on Finish. To enable the Contacts service, open the Server app and then click on Contacts in the SERVICES section of the List Pane. From here, use the “Include directory contacts in search” checkbox to publish LDAP contacts through the service, or leave this option unchecked and click on the ON button to enable the service. The Contacts service then starts and once complete, a green light appears beside the Contacts entry in the List Pane. To configure a client open the Contacts application on a client computer and use the Preferences entry in the Contacts menu to bring up the Preferences screen. From here, click Accounts and then click on the plus icon (“+”). At the Add Account screen, select CardDAV from the Account type field and then provide a valid username from the users configured in Server app as well as the password for that user and the name or IP address of the server. Then click on the Create button.   When the account is finished creating click on the Server Settings tab if a custom port is required. Otherwise, close the Preferences/Accounts screen and then view the list of Contacts. Click on the name of the server in the Contacts sidebar list. There won’t be any contacts yet, so click on the plus sign to verify you have write access to the server. To create additional lists of contacts, hover over the name of the server and a plus sign appears, click on it to create a group on the Contacts service. Next, let’s get access to the LDAP-based contacts. To do so, bring up the Add Account screen again and this time select LDAP from the Account Type field. Provide the name or IP address of the server and then the port that LDAP contacts are available over (the defaults, 389 and 636 with SSL are more than likely the settings that you’ll use. Then click on the Continue button. At the Account Settings screen, provide the name that will appear in the Contacts app for the account in the Description field and then enter the search base in the Search base field. To determine the search base, use the serveradmin command. The following command will output the search base: sudo serveradmin settings dirserv:LDAPSettings:LDAPSearchBase Then set Authentication to simple and provide the username and password to access the server for the account you are configuring. The list then appears. The default port for the Contacts service is 8443, as seen earlier in the configuration of the client. To customize the port, use the serveradmin command to set addressbook settings for BindSSLPorts to edit the initial array entry, as follows: sudo serveradmin settings addressbook:BindSSLPorts:_array_index:0 = 8443 The default location for the files used by the Contacts service is in the /Library/Server/Calendar and Contacts directory. To change that to a folder called /Volumes/Pegasys/CardDAV, use the following command: sudo serveradmin settings addressbook:ServerRoot = "/Volumes/Pegasys/CardDAV" The service is then stopped with the serveradmin command: sudo serveradmin stop addressbook And started with the serveradmin command: sudo serveradmin start addressbook And whether the service is running, along with the paths to the logs can be obtained using the fullstatus command with serveradmin: sudo serveradmin fullstatus addressbook The output of which should be as follows: addressbook:setStateVersion = 1 addressbook:logPaths:LogFile = "/var/log/caldavd/access.log" addressbook:logPaths:ErrorLog = "/var/log/caldavd/error.log" addressbook:state = "RUNNING" addressbook:servicePortsAreRestricted = "NO" addressbook:servicePortsRestrictionInfo = _empty_array addressbook:readWriteSettingsVersion = 1 If you’re easily amused, run the serveradmin settings for calendar and compare them to the serveradmin settings for addressbook: sudo serveradmin settings calendar By default, the addressbook:MaxAllowedInstances is 3000. Let’s change it for calendar: sudo serveradmin serveradmin settings calendar:MaxAllowedInstances = 3001 And then let’s see what it is in addressbook: serveradmin settings addressbook:MaxAllowedInstances If two services share a port and share all the same settings and even a binary then are they in fact the same service?
You know, there’s a million fine looking women in the world, dude. But they don’t all bring you lasagna at work. Most of ’em just cheat on you.

August 3rd, 2012

Posted In: Mac OS X, Mac OS X Server

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

I frequently write about adding entries in OS X Servers configuration database using serveradmin. But there are a lot of causes for various symptoms in OS X and trying some post of mine might end up biting you later, if it doesn’t fix your problem and you end up leaving the keys in place in OS X Server. Therefore, let’s look at something I might tell you to do, such as set a mail relay host from serveradmin: serveradmin settings mail:postfix:smtp_auth_relay_dict:smtp_auth_relay_host = mdm.krypted.com Once the setting has been configured, you might want to get rid of it outright. Now, this one happens to be exposed in the GUI, so you could set it there. But that’s not really any fun. According to the man page, you should be able to delete the keys and array entries using delete as the payload. But this is one place where the man page is actually incorrect. Let’s test by using delete as the entry, as follows: serveradmin settings mail:postfix:smtp_auth_relay_dict:smtp_auth_relay_host = delete Run serveradmin settings for mail to list all the settings: serveradmin settings mail And you’ll note that the key is actually just like you typed in, where rather than expand to function as a “delete the key” command, delete becomes the actual payload as a string: serveradmin settings mail:postfix:smtp_auth_relay_dict:smtp_auth_relay_host = "delete" Many services have a corresponding property list that contains their settings. These are stored in /Library/Server in a Config directory nested inside the service name. So for example, settings for the mail service would be stored in /Library/Server/Mail/Config/MailServicesOther.plist. In the same folder is MailServicesOther.10.8.plist, which references the settings files for a few other services that help to make up the Mail service. Delete the array entry and you’ll have achieved your goal of removing the entry. Some of the service configuration files are .config files instead of property lists. In those cases, look for the keys in the configuration file and restart after you change them, but make sure to check that the changes took as many times you might have something else you need to do. I frequently use fsevents to see which configuration file I’m editing when I run a command in serveradmin and then find the correct value in the plist that I’ve altered once I’ve changed something in serveradmin. Overall, the man page illustrates the most desirable way to delete custom entries. However, in the absence of this working, it’s worth noting other ways to achieve the same result.

July 4th, 2012

Posted In: Mac OS X Server

Tags: , , , , , ,

In the Server Admin application, you need to enable any services before you can actually start them. In order to do so to a lot of servers at once, you want to automate that. Such automation can be done using the serveradmin command line options. The settings would be sent to info. To see all of the settings available there: serveradmin settings info Note that there’s a whole section for info:serviceConfig: info:serviceConfig:roles:com.apple.SimpleServerSetup.ODPlugin:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.DirectoryServices:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.NetBoot:configured = no info:serviceConfig:services:com.apple.ServerAdmin.AddressBook:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.SWUpdate:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.NAT:configured = no info:serviceConfig:services:com.apple.ServerAdmin.Mail:configured = no info:serviceConfig:services:com.apple.ServerAdmin.Notification:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.VPN:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.DHCP:configured = no info:serviceConfig:services:com.apple.ServerAdmin.Calendar:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.AppleFile:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.Jabber:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.Radius:configured = no info:serviceConfig:services:com.apple.ServerAdmin.IPFirewall:configured = no info:serviceConfig:services:com.apple.ServerAdmin.Podcast:configured = no info:serviceConfig:services:com.apple.ServerAdmin.Windows:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.DNS:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.NFS:configured = yes info:serviceConfig:services:com.apple.ServerAdmin.Xgrid:configured = no info:serviceConfig:services:com.apple.ServerAdmin.Web:configured = yes Toggling these will cause the corresponding service to appear in Server Admin. So to enable the VPN service to show in Server Admin: serveradmin settings info:serviceConfig:services:com.apple.ServerAdmin.VPN:configured=yes The server name is also set in info at configuration time and while the wizard changes the name in some places, it doesn’t change the name that appears on client systems for Profile Manager Management Profiles. info:ComputerName is the name that was given to the server when Server.app was installed, which doesn’t necessarily match the output of scutil –get ComputerName or HostName. Anyway, overall, there are a few interesting settings in here and when I’m looking for something I rarely think to look here first. A tip of the hat to Allan Sanderson (@allansan) for pointing this out on the ‘ole Twitter.

June 21st, 2012

Posted In: Mac OS X Server, Mass Deployment

Tags: , , , , , , ,

By default the /Library/Preferences/com.apple.pcastserverd.plist allows basic, digest and Kerberos authentication. Attempts to authenticate will be made in the reverse order, respectively. This is pulled from the http_auth_type array, which you can see using the following command: serveradmin settings pcast You can then remove an entry and edit existing entries to change the supported mechanisms using serveradmin if you cannot stop the Podcast Producer service. If you can stop the service then the easiest way to edit the authentication mechanisms is to edit /Library/Preferences/com.apple.pcastserverd.plist directly. To do so, locate the http_auth_type key as you see it here: <key>http_auth_type</key> <array> <string>basic</string> <string>digest</string> <string>kerberos</string> </array> Here, remove each string that you no longer wish to support. Removing all except Kerberos will provide support for only Kerberos as an authentication mechanism.

October 6th, 2009

Posted In: Mac OS X Server, Mac Security

Tags: , , , , , , , ,