Tiny Deathstars of Foulness

OS X running the Server app 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 OS X Server. Some of these include the configuration of amavisd, docecot and alerts. These scripts can also be used for migrating services and data. Sometimes the scripts are in bash, sometimes ruby, sometimes perl and other times even python. And the scripts tend to change year over year/release over release. The easiest way to view logs is to use the Server app, clicking on Logs in the sidebar. The dropdown at the bottom of the screen provides quick access to service-based logs.

Screen Shot 2015-09-25 at 8.47.29 PM

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. However, you can also use the Console app from /Applications/Utilities, as with any other Mac, to look at standard logs.

Screen Shot 2015-09-25 at 8.48.50 PM

Looking At Services

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. Global log locations are controlled using the mail:global:service_data_path key, which indicates a path that logs are stored in (as usual many of these are in /Library/Server):

sudo serveradmin settings mail:global:service_data_path = "/Library/Server/Mail"

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 to info:

sudo serveradmin settings mail:imap:log_level = “info”

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 Xsan service 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 OS X  Server’s built-in web service to conform to the standards of most modern web log analyzers.


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…

October 8th, 2015

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

Tags: , , , , , , , ,

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


Once open, click on Edit to enable email notifications of invitations in the Calendar Server. Provide the email address and then click on the Next button.


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


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


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


There are a number of settings that can also be configured. But those are exposed only at the command line. To configure them, open the command line and then review the list of Calendar service settings using the list option of the serveradmin command:

sudo serveradmin settings calendar

There are a number of settings for the Calendar service, including the following:

calendar:SSLCertificate = "/etc/certificates/Server Fallback SSL Certificate.11C002258ECABBFB37846C9B0CEA59391D4759AD.cert.pem"
calendar:EnableCalDAV = yes
calendar:Notifications:Services:APNS:CardDAV:CertificatePath = "/Library/Server/Calendar and Contacts/Config/Certificates/"
calendar:Notifications:Services:APNS:CardDAV:PrivateKeyPath = "/Library/Server/Calendar and Contacts/Config/Certificates/"
calendar:Notifications:Services:APNS:CardDAV:AuthorityChainPath = "/Library/Server/Calendar and Contacts/Config/Certificates/"
calendar:Notifications:Services:APNS:CalDAV:CertificatePath = "/Library/Server/Calendar and Contacts/Config/Certificates/"
calendar:Notifications:Services:APNS:CalDAV:PrivateKeyPath = "/Library/Server/Calendar and Contacts/Config/Certificates/"
calendar:Notifications:Services:APNS:CalDAV:AuthorityChainPath = "/Library/Server/Calendar and Contacts/Config/Certificates/"
calendar:Notifications:Services:APNS:Enabled = yes
calendar:SSLAuthorityChain = "/etc/certificates/Server Fallback SSL Certificate.11C002258ECABBFB37846C9B0CEA59391D4759AD.chain.pem"
calendar:DefaultLogLevel = "warn"
calendar:Authentication:Digest:Enabled = yes
calendar:Authentication:Digest:AllowedOverWireUnencrypted = yes
calendar:Authentication:Kerberos:Enabled = yes
calendar:Authentication:Kerberos:AllowedOverWireUnencrypted = yes
calendar:Authentication:Wiki:Enabled = yes
calendar:Authentication:Basic:Enabled = yes
calendar:Authentication:Basic:AllowedOverWireUnencrypted = no
calendar:ServerHostName = ""
calendar:Scheduling:iMIP:Sending:UseSSL = yes
calendar:Scheduling:iMIP:Sending:Server = ""
calendar:Scheduling:iMIP:Sending:Address = ""
calendar:Scheduling:iMIP:Sending:Username = "admin"
calendar:Scheduling:iMIP:Sending:Password = "Mitroae123"
calendar:Scheduling:iMIP:Sending:Port = 465
calendar:Scheduling:iMIP:Enabled = yes
calendar:Scheduling:iMIP:Receiving:UseSSL = yes
calendar:Scheduling:iMIP:Receiving:Server = ""
calendar:Scheduling:iMIP:Receiving:Type = "imap"
calendar:Scheduling:iMIP:Receiving:Username = "krypted"
calendar:Scheduling:iMIP:Receiving:Password = "Mitroae123"
calendar:Scheduling:iMIP:Receiving:Port = 993
calendar:DataRoot = "/Library/Server/Calendar and Contacts/Data"
calendar:EnableCardDAV = no
calendar:SSLPort = 8443
calendar:LogLevels = _empty_dictionary
calendar:DirectoryAddressBook:params:queryUserRecords = no
calendar:DirectoryAddressBook:params:queryPeopleRecords = no
calendar:SSLPrivateKey = "/etc/certificates/Server Fallback SSL Certificate.11C002258ECABBFB37846C9B0CEA59391D4759AD.key.pem"
calendar:EnableSSL = yes
calendar:RedirectHTTPToHTTPS = yes
calendar:EnableAPNS = yes
calendar:EnableSearchAddressBook = no
calendar:HTTPPort = 8008

One of the more common settings to configure is the port number that CalDAV runs on. To configure HTTP:

sudo serveradmin settings calendar:HTTPPort = 8008


sudo serveradmin settings calendar:SSLPort = 8443

You can then start the service using the start option:

sudo serveradmin start calendar

Or to stop it:

sudo serveradmin stop calendar

Or to get the status:

sudo serveradmin fullstatus calendar

Full status indicates that the three services are running:

calendar:readWriteSettingsVersion = 1
calendar:setStateVersion = 1
calendar:state = "RUNNING"
calendar:contactsState = "RUNNING"
calendar:calendarState = "RUNNING"

Once the Calendar server is configured, use the Calendar application to communicate with the server. Open the Calendar application and click on the Calendar menu and select Preferences. From the Preferences screen, click on Accounts to bring up a list of accounts. Here, click on the plus sign (“+”) to bring up the “Add an Account” screen.


At the “Add an Account” screen, select Add CalDAV Account.


CalDAV from the Account Type menu and then enter the User Name and password configured on the server, and add the address of the server if you don’t have any service records pointing to the server. The User Name is usually the name provided in Server app, followed by @ and then the address of the server.


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


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


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


Click on the Delegation tab to view any accounts you’ve been given access to.


Use the Edit button to configure who has delegated access to calendars, as opposed to configuring subscriptions.

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

October 16th, 2014

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

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: , , , , , , , , , , , , ,

Mountain Lion Server is now available on the OS X App Store and as with the last few updates there are some things missing that you might be expecting and depending on. First up, three major services are gone: Podcast Producer, RADIUS and dhcp. You can still do dhcp as you always did with OS X client as those features work on OS X Server, but the more granular controls available in OS X Server are now gone. The biggest impact of dhcp is probably in testing NetBoot services when there are network issues and you need to prove to network admins that it’s the network and not your server…

I had written an article before about FTP still being in OS X Server from the command line, but now it’s back in the GUI, which should make many an administrator happy. NAT is also gone from the GUI, but natd and natutil are still available from the command line. Might as well just use the Sharing System Preference pane for such things though… Server Admin is now gone (long live Server Admin!) and Workgroup Manager is now a download to be performed and installed following installation. Support for Managed Preferences is gone, even though most manifests technically still work.

Many services also got some pretty nice updates. These include:

  • Calendar – There are a few updates on the client side, but not on the server side. Most notably, the option to publish calendars is now gone. If you used that, it’s time to get used to manually exporting, copying to a share and then distributing links. This is going to likely cause more use of the Calendar server itself, to some degree. Also, it’s not iCal or iCal Server, it’s now Calendar and Calendar server. Seems to me that this isn’t obviously an Apple-centric naming structure as with most other things they do, but sometimes you’re gonna’ have that…
  • Contacts – Nope, it’s not called Address Book server, it’s the Contacts service. Same with the client side application.
  • DNS – DNS management is moved into the Server application. You can also now restrict who you do lookups for in the GUI. Under the hood very little changes.
  • File Sharing – Nothing really changes with file sharing, except the wiki integration described in the Wiki section in a little bit.
  • Firewall – The firewall option is gone, as is the ipfilter at the command line, but pf is easy to configure from the command line.
  • FTP – It’s a quick and easy single share solution from the GUI. Using the sharing command there’s still tons available to administrators.
  • Mail – Authentication mechanisms and domains are in the GUI, but very little changes otherwise.
  • Messages – The service name has changed from iChat to Messages in the GUI but is still jabber from the command line. The big change with this service is that the client side is now able to leverage iCloud to instant message mobile devices as well. Therefore, the text messaging component is client-side and has no impact on the jabber service itself.
  • NetInstall – The “NetInstall” service is NetBoot. It can host NetRestore or NetInstall images, but the heavy lifting for that stuff is done in System Image Utility. And the output of the SIU commands are now more scriptable through the automator command line interface. The NetInstall screen is now in Server app and is a good port from Server Admin in that it’s similar in look and feel to the NetBoot screen in Server Admin. A feature that isn’t in the GUI is diskless NetBoot, which is fine because I documented how to do it when I realized it would be an issue for a few customers.
  • Open Directory – Given that Server Admin is gone, something had to happen with Open Directory. The Open Directory screens have been moved to Server app where it’s fast to setup and tear down Open Directory. Open Directory based Users and Groups are also created through the Server App, although Workgroup Manager can be downloaded and used still. Immediately following upgrades, the add and remove users buttons are gone for previously stand-alone hosts. Also the Manage Network Accounts option is now gone from Server app, replaced with the traditional ON button supplied by Apple for other services.
  • Profile Manager – This deserves its own post, which is in the queue, but suffice it to say that while you can’t tell when looking in Server app, there are a number of upgrades to Profile Manager.
  • Software Update – Management of the service is moved from Server Admin to Server app. There are now fewer options in the GUI, but the same in the command line. Cascading is a little different.
  • Time Machine – Time Machine server is the same… The versions option from the Time Machine Server preference pane is gone and the layout is a little changed, but the server component is identical in functionality as well as look and feel.
  • VPN – Unless you add another supported VPN protocol there’s not much to do after fixing most issues in 10.7.4. Except fixing the last issue with search bases, seemingly resolved as it’s working for me pretty well.
  • Websites – There are more options in the GUI for new sites. The default site appears twice (once for 80 and once for 443), but there are more options, such as the Web App functionality that comes with a default Python “Hello World” app. Also the server is still called web from the serveradmin command line, but is now called Websites through the GUI.
  • Wiki – The wiki has themes again, although they’re just color schemes. And you can create your own custom banners and upload, which brings back two of the most common feature requests from people that hack the look and feel of the wiki in versions previous to Lion. But the most substantial aspect of the Wiki to change to me is the document management options, available to users in WebDAV or through the portal. This allows for a very mobile-friendly file management tool. Blogs and wikis for the most part stay the same and have a very clean upgrade process from Lion. The command line tools also feature some new options for indexing, etc., which many will find helpful.
  • Xsan – cvadmin, cvlabel, cvversions, etc are now stored in /System/Library/Filesystems/acfs.fs/Contents/bin/ and Xsan has its own entry in the Server app. Despite hearing people question its future, I’ve never seen as many questions flying around about how to do things with Xsan than I do now. Storage sales are up, monkey chatter on the web is up, deployments are being booked and Xsan looks here to stay. The Server app only really shows you a status of things, but the Xsan Admin app is now embedded in the Server app and available through the Server app Tools directory.

Configuring Websites in Server app

The Alerts options are much more robust in Mountain Lion than they were previously. You  can now get alerts on a myriad of things, incuding certs, disks, space, storage quotas, virus detection, network changes and software updates.

Configuring Alerts in Mountain Lion Server

The Server commands also moved and in fact the whole file and folder structure mostly fit nicely inside of the Server app. There are certain things that haven’t been dealt with in this regard such as NetBoot’s library, but for the most part Apple is getting Server to the point where it’s very self-contained. The ramification of which is that upgrades for future releases (and from Lion to Mountain Lion for that matter) are much simpler. Simply downloading a new version informs administrators that the app has been replaced and is good to go, service data in tact. In real world, this has been a little hit or miss but should prove to make our lives much easier in the future.

Reducing scope, aligning with better development practices and all the work to merge all of the remaining services into Server app are huge undertakings. I would fully expect no further support or updates to Workgroup Manager, no more testing of managed preferences in deference to profiles and a few other culture shifts that still need to shake themselves out. Most of us are going to seem underwhelmed (if that’s a word, no it’s not ’cause I looked it up -> awesome video below –> ’cause affection has 2 fs, especially when you’re dealin’ with me). But here’s the thing, with an incremental update, you’re not going to get massive changes. Instead we will get slow and steady updates hopefully continuing to build faster towards a better end goal. What’s important is that the foundation is actually better now, given changes to other parts of OS X and so Server is likely now better positioned than ever for great new features in subsequent releases.

Oh, and did I forget to mention that Xgrid is gone. I guess no one really noticed anyway…

July 26th, 2012

Posted In: Mac OS X Server

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

There are a number of ways that you can interact with Google Apps: there is the website, the new Google Cloud Connect and an API that allows you to integrate Google Apps with your own solutions. The API is available for python and java and can take some time to get used to, even though Google has done a good job with making it pretty straight forward (comparably). Therefore, there are a couple of tools that ease the learning curve a bit.

GoogleCL on Ubuntu

The first, and easiest is GoogleCL. GoogleCL is a command line version of Google Apps that will allow you to interact with YouTube, Picasa, Blogger and of course Google Docs. To use GoogleCL you’re going to need python-gdata. If you’re using Ubuntu, you would do an apt-get and install python-gdata:

apt-get install python-gdata

Once installed, you’ll want to then download the deb package from Google Code:


Once downloaded, install it using dpkg with the -i option (assuming you’re still using the same working directory:

dpkg -i googlecl_0.9.11-1_all.deb

GoogleCL on Mac OS X

GoogleCL is also available for the Mac. First, download the gdata-python-client from and then extract the file (ie – unzip gdata-2.0.13). Next, install it using Python (2.0.13 is the latest version) with your working directory set to the previously extracted folder:

python install

Next up, let’s grab GoogleCL from the GoogleCL Google Code page:


Then hop into the newly extracted directory and run the python installer:

python install

Using GoogleCL on Mac and Linux

Once GoogleCL has been installed, the use is the same between Mac OS X and Linux. Simply use the newly acquired google command (this is actually a Python front-end to the API at /usr/bin/google) followed by a service and then a verb. Verbs are based on services (not all services offer the same features and therefore do not have the same verbs). A list of services with their verbs includes the following.

docs – Allows for interaction with Google Docs, with verbs that include the following:

  • edit – Allows you to indicate an application to use as an editor for the given document (ie – vi).
  • delete – Delete a document on Google Docs.
  • list – List documents on Google Docs.
  • upload – Uploads the specified document (options include title, folder and format of the document being uploaded).
  • get – Downloads the specified document in the format specified using the format option.

blogger – Manage content stored using the blogger service.

  • post – Allows you to post content (which is then known as blog).
  • tag – Requires a title (for blog entries) and the tags that you would like to use with the post in question.
  • list – Shows posts (can use blog entry, title and owner as a delimiter, useful when used w/ grep to constrain output).
  • delete – Removes a post specified.

picasa – Allows you to interact with the picasa service for posting and obtaining images used with Google Apps.

  • get – Download specified albums.
  • create – Create an album.
  • list – List images.
  • list-albums – List albums.
  • tag – Tag images
  • post – Add a photo to an album.
  • delete – Delete a photo or an album.

contacts – Manage contacts (given the lack of an edit option, use an add and then a delete to impart an edit).

  • list – Show contacts (can specify fields to constrain output).
  • list-groups – Show the groups for a user.
  • add – Add a contact.
  • add-groups – Create a group of contacts.
  • delete-groups – Remove a group of contacts
  • delete – Remove a single contact

calendar – Manage calendars.

  • add – Create a calendar entry
  • list – Show all events on a given calendar.
  • today – Show calendar events over the next 24 hour period.
  • delete – Remove calendar events.

Beyond GoogleCL

Let’s put this into perspective. Let’s say I have an application, and that application can run a simple shell command. Then, let’s say I create a calendar event in that application. The application could send a command to the shell with a variable. If I had calendar information to create such as “Meeting with KK tomorrow at 9am” then I could send a command as follows:

google calendar add “Meeting with KK tomorrow at 9am”

This would cause the event to appear on my calendar and sync to any devices that were then configured to work with my calendar. But, if I were to issue this command on the server-side then it would attempt to create all events for the same users, which is likely not very helpful for most organizations that have more than one calendar and/or user.

As mentioned /usr/sbin/google is a python script. It makes use of python-gdata and provides a more direct access to the Google Apps API. As such, it allows for far more complex logic than the GoogleCL front-end does. The google script does give savvy developers a look at how Google intends for many of their methods to be used and even allows you to borrow a line or two of code here and there. Simple logic can be parlayed into code quickly using GoogleCL, but you will quickly outgrow what can be done with GoogleCL and move into using the API more directly if you have any projects of substance!

November 28th, 2010

Posted In: cloud, Mac OS X, Mac OS X Server, Ubuntu, Unix

Tags: , , , , , , , , ,