Tiny Deathstars of Foulness

Troubleshooting push notification communications between OS X Server and Apple’s Push Notification can be a challenge. Especially with Profile Manager. One great tip I’ve learned over the years is that the APNS daemon, apsd, has a debug mode. To enable APNS debug logging, run these commands: defaults write /Library/Preferences/ APSLogLevel -int 7 defaults write /Library/Preferences/ APSWriteLogs -bool TRUE killall apsd Then use tail -f to watch the apsd.log file at /Library/Logs/apsd.log. Be wary, as this can fill up your system. So to disable, use these commands: defaults write /Library/Preferences/ APSWriteLogs -bool FALSE defaults delete /Library/Preferences/ APSLogLevel killall apsd

May 18th, 2015

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

Tags: , , , , , , ,

With Yosemite in beta, it’s worth mentioning that older versions of OS X Server are still available on the app store, if you just know where to look. You can access and purchase other versions using these links: Server 4: Server 3: Server 2: Server 1: If you already own OS X Lion Server from the app store then you can still access it under Purchases. Screen Shot 2014-11-14 at 10.30.22 PM      

June 1st, 2014

Posted In: Mac OS X Server

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

The caching service in Mountain Lion Server (OS X Server 10.8) by default can use any interface installed on the system. I’ve now seen a couple instances where we have a Small Tree card and when a big update comes up, we loose file services speed due to caching data. To combat this, we can tell the Caching service to use the built-in Ethernet interface exclusively instead. To do so, first use ifconfig to determine which interface is which. Then tell the caching service which to use, using the serveradmin command, followed by settings and then the name of the setting, caching:Interface, setting the value to the en of the interface you’d like to use: serveradmin settings caching:Interface = en1 I’ve had to restart the caching service to have this change take effect: serveradmin stop caching serveradmin start caching Clients will then automatically use the correct interface.

August 22nd, 2013

Posted In: Mac OS X Server

Tags: , , , , ,

These days, new services get introduced in OS X Server during point releases. OS X now has a Software Caching server built to make updates faster. This doesn’t replace Apple’s Software Update Server mind you, it supplements. And, it’s very cool technology. “What makes it so cool” you might ask, given that Software Update Server has been around for awhile. Namely, the way that clients perform software update service location and distribution with absolutely no need (or ability) for centralized administration. Let’s say that you have 200 users with Mac Minis and an update is released. That’s 200 of the same update those devices are going to download over your Internet connection, at up to 2 to 3 gigs per download. If you’re lucky enough to have eaten at the Varsity in Atlanta, just imagine trying to drink one of those dreamy orange goodnesses through a coffee stirrer. Probably gonna’ be a little frustrating. Suck and suck and suck and it’ll probably melt enough to make it through that straw before you can pull it through. For that matter, according to how fast your Internet pipe is, there’s a chance something smaller, like an update to Expensify will blow out that same network, leaving no room for important things, like updates to Angry Birds! Now, let’s say you have an OS X Server running the new Caching service. In this case, the first device pulls the update down and each subsequent device uses the WAN address to determine where the nearest caching service is. If there’s one on the same subnet, provided the subnet isn’t a Class B or higher, then the client will attempt to establish a connection to the caching service. If it can and the update being requested is on that server then the client will pull the update from the server once the signature of the update is verified with Apple (after all, we wouldn’t want some funky cert getting in the way of our sucking). If the download is stopped it will resume after following the same process on a different server, or directly from Apple. The client-side configuration is automatic so provides a seamless experience to end users. Pretty cool, eh? But you’re probably thinking this new awesomeness is hard as all heck to install. Well, notsomuch. There are a few options that can be configured, but the server is smart enough to do most of the work for you. Before you get started, you should:
  • Be running Mountain Lion with Server 2.2 or better.
  • Install an APNS certificate first, described in a previous article I wrote here.
  • Have an ethernet connection on the server.
  • Have a hard drive with at least 50GB free in the server.
  • The server must be in a Class C or smaller LAN IP scheme (no WAN IPs can be used with this service, although I was able to multihome with the WAN off while configuring the service)
Once all of the requirements have been met, you will need to install the actual Caching Service. To do so, open from the /Applications directory and connect to the server with which you would like to install the Caching service. Click on Caching from the SERVICES section of the Server sidebar. Here, you have 3 options you can configure before starting the service. The first is which volume with which to place updates. This should typically be a Pegasus or other form of mass storage that is not your boot volume. Use the Edit… button to configure which volume will be used. By default, when you select that volume you’ll be storing the updates in the Library/Server/Caching/Data of that volume. The next button is used to clear out the cache currently used on the server. Click Reset and the entire contents of the aforementioned Data directory will be cleared. Next, configure the Cache Size. Here, you have a slider to configure about as much space as you’d like, up to “Unlimited”. You can also use the command line to do some otherwise unavailable numbers, such as 2TB. Once you’ve configured the correct amount of space, click on the ON button to fire up the service. Once started, grab a client from the local environment and download an update. Then do another. Time both. Check the Data folder, see that there’s stuff in there and enjoy yourself for such a job well done. Now, let’s look at the command line management available for this service. Using the serveradmin command you can summon the settings for the caching service, as follows: sudo serveradmin settings caching The settings available include the following results: caching:ReservedVolumeSpace = 25000000000 caching:SingleMachineMode = no caching:Port = 0 caching:SavedCacheSize = 0 caching:CacheLimit = 0 caching:DataPath = "/Volumes/Base_Image/Library/Server/Caching/Data" caching:ServerGUID = "FB78960D-F708-43C4-A1F1-3E068368655D" caching:ServerRoot = "/Library/Server" Don’t change the caching:ServerRoot setting on the server. This is derived from the root of the global ServerRoot. Also, the ServerGUID setting is configured automatically when connecting to Apple and so should not be set manually. When you configured that Volume setting, you set the caching:DataPath option. You can make this some place completely off, like: sudo serveradmin settings caching:DataPath = "/Library/Server/NewCaching/NewData" Now let’s say you wanted to set the maximum size of the cache to 800 gigs: sudo serveradmin settings caching:CacheLimit = 812851086070 To customize the port used: sudo serveradmin settings caching:Port = 6900 The server reserves a certain amount of filesystem space for the caching service. This is the only service I’ve seen do this. By default, it’s about 25 gigs of space. To customize that to let’s say, ‘around’ 50 gigs: sudo serveradmin settings caching:ReservedVolumeSpace = 50000000000 To stop the service once you’ve changed some settings: sudo serveradmin stop caching To start it back up: sudo serveradmin start caching Once you’ve started the Caching service in OS X Server and familiarized yourself with the serveradmin caching options, let’s look at the status options. I always use fullstatus: sudo serveradmin fullstatus caching Returns the following: caching:Active = yes caching:state = "RUNNING" caching:Port = 57466 caching:CacheUsed = 24083596 caching:TotalBytesRequested = 24083596 caching:CacheLimit = 0 caching:RegistrationStatus = 1 caching:CacheFree = 360581072384 caching:StartupStatus = "OK" caching:CacheStatus = "OK" caching:TotalBytesReturned = 24083596 caching:CacheDetails:.pkg = 24083596 The important things here:
  • An Active setting of “yes” means the server’s started.
  • The state is “STARTED” or “STOPPED” (or STARTING if it’s in the middle).
  • The TCP/IP port used 57466 by default. If the caching:Port setting earlier is set to 0 this is the port used by default.
  • The CacheUsed is how much space of the total CacheLimit has been used.
  • The RegistrationStatus indicates whether the server is registered via APNS for the service with Apple.
  • The CacheFree setting indicates how much space on the drive can be used for updates.
  • The caching:TotalBytesRequested option should indicate how much data has been requested from clients while the caching:TotalBytesReturned indicates how much data has been returned to clients.
Look into the /Library/Server/Caching/Config/Config.plist file to see even more information, such as the following: <key>LastConfigURL</key> <string></string> <key>LastPort</key> <integer>57466</integer> <key>LastRegOrFlush</key> <date>2012-12-16T04:33:13Z</date> There are also a number of other keys that can be added to the Config.plist file including CacheLimit, DataPath, Interface, ListenRanges, LogLevel, MaxConcurrentClients, Port and ReservedVolumeSpace. These are described further at As you can see, this provides the host name of the server and path on that server that the Caching server requires access to, the last port connected to and the last date that the contents were flushed. In the Data directory that we mentioned earlier is a SQLite database, called AssetInfo.db. In this database, a number of files are mentioned. These are in a file hierarchy also in that Data directory. Client systems access data directly from that folder. Finally, the Server app contains a log that is accessed using the Logs option in the Server app sidebar. If you have problems with the service, information can be accessed here (use the Caching Service Log to access Caching logs). The Caching Service uses the AssetCache service, located at /Applications/, then starts as the new user _assetcache user. It’s LaunchDaemon is at /Applications/ Note: In my initial testing it appeared that after rebooting devices, that iOS updates were being cached; however, several have reported that this is not yet possible. I’ll try and replicate and report my findings later.

December 17th, 2012

Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Network Infrastructure

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

There are four ways to create users in Mountain Lion Server. The first is using the Server app, the second is using Workgroup Manager, the third is using the Users & Groups System Preference pane and the fourth is using the command line. In this article we will look at creating users in the Server app. To do so, open the Server app and connect to your server. Then click on the Users entry in the ACCOUNTS list. The list of users is displayed, based on the directory domain(s) being browsed. A directory domain is a repository of account data, which can include local users, local network users and users in a shared directory service such as Open Directory and Active Directory. The drop-down list allows you to see objects that are stored locally as well as on a shared directory server. Therefore, clicking All Users will show all of the accounts accessible by the system. Click on the plus sign to create a new account. At this point, if the server has been promoted to an Open Directory Master, the account will be a local network account, with no way of choosing a different location to store the account in the Server app. When prompted, provide the following information about the new user:
  • Full Name: Usually the first and last name of the user.
  • Account Name: A shorter representation of that name with no spaces or special characters.
  • Email address: The email address to use if the account is going over quotas, has calendar invitations sent, or used for email hosted on the server, etc.
  • Password: The password the user will use to access services on the server.
  • Verify: The password a second time to make sure there are no spelling errors.
  • Allow user to administer this server: Optional field that grants the user administrative access to the server.
  • Home Folder: Optional field that by default creates local home directories for users that use the account but that also allows you to select a directory shared using the File Sharing service as a location for home folders. Each user in OS X has a home folder, this option defines whether that folder will reside on their computer or on a central server.
  • Disk Quota: Define the amount of space an account can take up on servers.
Note: Optionally, you can also drag an image onto the image shown in the New User screen if you’d like the user to have an avatar.
Once the account details are as you would like, click on the Done button. The account will then be displayed in the list of available accounts. You can still create local accounts but must do so in the Users & Groups System Preference pane, through Workgroup Manager or through the command line. If the server has not been made an Open Directory server then you would be creating local users through the Server app. Once the account is created, highlight it and click on the cog wheel icon below the list of accounts. Here, you have the option to edit the account you just created, edit their access to services hosted on the server, configure email information and change their password. Click Edit User. Here, you have two new features. You can add the user to groups and use the checkbox for “log in” to disable the account. Click Cancel and then using the cog wheel menu again, click on Edit Access to Services. Here, uncheck each service that the user should not have access to. If the service isn’t running then it’s not a big deal. You can highlight multiple accounts concurrently and then use this option to disable services for users en masse.

September 1st, 2012

Posted In: Mac OS X Server, Mac Security

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

I’ve been doing a number of postings on how to use various features of the latest version of OS X Server. Given that WordPress is pretty much a reverse chronological listing of articles I’ve written, I thought I’d put together a listing of the pages that I’ve done for OS X Server 10.8 (Mountain Lion Server) in order to offer a more pedagogically aligned way of reading these posts. As such, here is the Table of Contents for these posts: Introduction Managing the Server Configuring Services Troubleshooting Command Line Misc

August 28th, 2012

Posted In: Mac OS X Server, Mac Security

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

OS X Mountain Lion Server comes with the /usr/sbin/serverinfo command. The serverinfo command can be pretty useful when you’re looking to programmatically obtain information about the very basic state of an OS X Server. The first option indicates whether the Server app has been downloaded from the app store, which is the –software option: serverinfo --software When used, this option reports the following if the can be found: This system has server software installed. Or if the software cannot be found, the following is indicated: This system does NOT have server software installed. The –productname option can be used to determine the name of the software app: serverinfo --productname If you change the name of the app from Server then the serverinfo won’t work any longer, so the output should always be the following: Server The –shortversion command returns the version of the Server app being used: serverinfo --shortversion The output will not indicate a build number, but instead the version of the app on the computer the command is run on: 2.0.23 To see the build, use the –buildversion option: serverinfo --buildversion The output shows the build of server, which doesn’t necessarily match the OS X build number: 12S307 Just because the Server app has been downloaded doesn’t mean the Server setup assistant has been run. To see if it has, use the –configured option: serverinfo --configured The output indicates whether the system is running as a server or just has the app installed (e.g. if you’re using it to connect to another server: This system has server software configured. You can also output all of the information into a single, easy to script against property list using the –plist option: serverinfo --plist The output is a list of each of the other options used: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ""> <plist version="1.0"> <dict> <key>IsOSXServerVolume</key> <true/> <key>IsOSXServerVolumeConfigured</key> <true/> <key>IsServerHardware</key> <false/> <key>LocalizedServerProductName</key> <string>Server</string> <key>ServerBuildVersion</key> <string>12S307</string> <key>ServerPerformanceModeEnabled</key> <true/> <key>ServerVersion</key> <string>2.0.23</string> </dict> </plist> The Server Root can reside in a number of places. To see the path (useful when scripting commands that are relative to the ServerRoot: serverinfo --prefix By default, the output is as follows: /Applications/ You can also see whether the system is running on actual hardware desgnated by Apple for servers using the –hardware option: serverinfo --hardware The output simply indicates if the hardware shipped with OS X Server on it from Apple: This system is NOT running on server hardware. The –perfmode option indicates whether or not the performance mode has been enabled, dedicating resources to binaries within the Server app: serverinfo --perfmode If the performance mode has not been enabled then the output will be as such: Server performance mode is NOT enabled. To enable performance mode, you can also use serverinfo. This is the only task that the command does that can make any changes to the system and as such is the only time you need to elevate privileges: sudo serverinfo --setperfmode 1 Finally, set the boolean value to 0 to disable. sudo serverinfo --setperfmode 0

August 25th, 2012

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

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

Apple’s not going to slow down innovation just to make me happy. I get that. But what have I noticed most about the differences between Mountain Lion and Mountain Lion Server and their predecessors, and maybe what to do to get some of them back?
  1. Podcast Producer: I am going to just put it out there. I liked Podcast Producer. I hope it shows back up in the future, even though I’m controlling my expectations. As someone who deals with a lot of video, there are a number of features that were really helpful to me, with or without Xgrid. I’ve replaced the command line aspects with tools such as ffmpeg, which we used in addition to at times, but some of the ways that pcastaction did things were really elegant comparably. On the graphical side, much of the functionality is available in the various sites that produce video streams and of course, there’s always YouTube. Either way, in regards to Mountain Lion Server, this represents one of the most substantial changes for those of us that deal with video.
  2. DHCP: I know, I know… I wrote an article on how to keep using DHCP. That doesn’t mean that the lack of GUI options is any less irritating. Every time I manually edit a config file that should have a GUI front-end it makes me ornery. Not that I’m not always ornery, but that’s not the point here…
  3. RSS: This is more of a client thing. But and Safari used to give me the ability to quickly and easily look at RSS feeds and handled them in a way that was very streamlined with my experience across the rest of the operating system. I am now using more and more Google Reader along with tools like Reeder, but I liked the fact that everything I needed for RSS madness was installed on even the test systems I used
  4. X11: I know, I know… Use XQuartz. It was nice having it built in though…
  5. Web Sharing: I guess the answer here is to just buy OS X Server. You can still fire up the LaunchDaemon and use Apache, but it’s a bit of a challenge. And the version in Server isn’t identical to Apache in Mountain Lion. There are two ways I’ve handled this. The first is to install Mountain Lion Server and then use the command `webpromotion demote` to switch the Apache configuration back to that of a client computer. The second is to fire up the LaunchDaemon directly using launchctl. If you’d like, there are also a number of free and/or 3rd party web servers, such as MAMP.
  6. Negative Mode: Well, I covered this already, and while the keystroke was gone, the feature never was – but here’s how to fix. Also, @sacrilicious turned me on to nocturne, which is pretty cool as well!
  7. iCal, Address Book and NetBoot: Actually, they’re now called Calendar, Contacts and NetInstall respectively. But still there. I actually like the renaming a lot, so I guess I don’t really miss any of them.
  8. Radius: OK, it’s there. Just command line only (unless you’re using an Apple AirPort). Maybe I should write an article about radius…
  9. The Server command line options: Actually, they just moved to a relative path to /Applications/, as I mentioned here.
  10. Server Admin: I was going to say FTP, then I remembered it’s back. And then I remembered I never missed it in the first place. But dropping the remainder of the GUI tools for servers represents a bit of a challenge, mostly in figuring out how to do a few of the minor things, like enabling Server Side File Tracking, etc.

August 23rd, 2012

Posted In: Mac OS X, Mac OS X Server

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/, 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/ Sometimes the scripts are in bash, sometimes ruby, sometimes perl and other times even python. Additionally, there’s a directory /Applications/ 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/, 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/ (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/ ) 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/ 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/, 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/ 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 = "/var/log/ppp/vpnd.log" sudo serveradmin settings = "/var/log/ppp/vpnd.log" sudo serveradmin settings = "/var/log/ppp/vpnd.log" sudo serveradmin settings = "/var/log/ppp/vpnd.log" By default, verbose logging is enabled, which you can see with: sudo serveradmin settings sudo serveradmin settings sudo serveradmin settings sudo serveradmin settings 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: , , , , , , , , , , , , , ,

Since the early days, OS X Server has supported performing the serveradmin commands through a web interface. This interface was accessible at the address of the server followed by a colon and then 311 in a web browser. This feature was disabled by default in Mountain Lion. But fear causes hesitation, and hesitation will cause your worst fears to come true, so we’re going to turn it back on. To enable, use the following command: sudo defaults write /Library/Preferences/ requireUserAgent -bool false Once done, open in a web browser, or replace with the address of the server if accessing from another location. This is stimulating, but we’re out of here. So, authenticate to be greeted with a list of services.

Lawyers don’t surf.

At the Server Admin Modules page, each service output from `serveradmin list` appears. Clicking each produces the ability to run the commands you can supply using `serveradmin command` along with the service name. For example, to get a list of all of the connected AFP users in OS X Mountain Lion Server, run the following command: sudo serveradmin command afp:command = getConnectedUsers Now, to get the same list, click on the servermgr_afp.html link and then click on getConnectedUsers.

Life sure has a sick sense of humor, doesn’t it?

Click on Send Command to see the output.

Peace, through superior firepower.

You then see an XML output that shows who’s connected (since I’m on a flight right now, luckily no one is connected to mine). Now you also have a URL in the toolbar, which should look something like this:
Rad, unicode. I guess spaces aren’t really compliant in URLs. Before we look at that, let’s take a look at what we can do with these. If you follow what I write, you have probably noticed that I use curl for tinkering with URLs a lot. In many cases, this is not the right tool. But I usually start there and move on if need be. Six seconds. We’re going to be meat waffles. Because we’re going to assume the server is using a self-signed cert that we don’t yet trust, we’re gonna’ use a -k along with curl. Then we’re going to follow that with the link. However, since we need to auth, we’re going to also go ahead and embed the username (in this case johhny) followed by a : and then the password (in this example, bodhi), followed by an @ in between the https:// and the server address, as follows: curl -k https://johhny:bodhi@ The output includes the afp:usersArray which shows active connections. The most interesting options, other than those for services you run in your environment, ar those under servermgr_info. Here, you can get PIDs for processes, kill PIDs, view logs, check file sizes, delete data and even reboot servers. Overall, this option has some security concerns, but provides some good insight into how the Server Admin tool worked under the hood in Mac OS X Lion Server and below while also serving as a functional option as an API for the  product, especially given that output is in XML, similar to the output of most other modern APIs. Vaya con Dios, Brah.

August 20th, 2012

Posted In: Mac OS X Server

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

Next Page »