Underworld: Awakening Trailer

Watching this trailer the past week makes me very happy, so I thought I’d share!

Posted on January 15, 2012 at 9:41 pm by Charles · Permalink · One Comment
In: personal

Paper.li Test Embed


Posted on January 14, 2012 at 2:57 pm by Charles · Permalink · Leave a comment
In: Articles and Books, Mac OS X, Mac OS X Server, Mac Security · Tagged with: 

Free MacWorld Exhibit Code and iFan Pass Savings

As usual, there are a lot of great events going on at MacWorld | iWorld. If you’re interested in joining us in a couple of weeks in San Francisco for what I’m sure will be a great conference, then you can use my speaker codes to do so. To do so, during the registration process enter a PRIORITY CODE of: BNB35106

This will give 100 FREE Exhibit Only Passes OR $15.00 OFF an iFan Pass. This code is unique to me, so other speakers have codes as well. The code will stop offering free exhibit passes once the 100th person registers for this. The $15.00 savings off an iFan pass will continue through the show.

I hope to see you there!

Posted on January 12, 2012 at 6:00 am by Charles · Permalink · Leave a comment
In: public speaking · Tagged with: , , , ,

The Elements of Style

Strunk & White’s Elements of Style is one of the best works explaining the rules of writing in the English language that has ever existed (and I’m pretty sure that sentence broke at least five of those rules). I’ve given this book to many a budding writer over the years. I’ve also recently noticed that it’s now all over the Internet, for free. For example, Bartleby has posted the 1918 edition of Elements of Style here.

XKCD's Elements of Style

If you haven’t read Elements of Style then I strongly recommend it. It’s short, concise and explains why that apostrophe goes in that one spot as opposed to the other. If you want to be a writer, this is one of your first stops on your journey.

Posted on January 11, 2012 at 7:00 pm by Charles · Permalink · Leave a comment
In: Articles and Books · Tagged with: , , , , , ,

Removing A Domain Name From A Google Search

When you are searching Google, you can restrict your search to a specific domain. For example, if you would like to find a page with the pattern “man touch” on krypted.com then you can constrain a Google search using the site: operator. The search dialog box would then read:

"man touch" site:krypted.com

But if you don’t find my posts helpful then you can remove the domain name from your Google searches, done by running the same, but with a “-” in front of the domain name, which given the above search inverted would be:

"man touch" site:-krypted.com

The resultant URL is then: http://www.google.com/search?q=site:-krypted.com. To take this a step further, you could also use this awesome application called glims from http://www.machangout.com to actually change your default search site from the standard Google.com search to the above URL and eliminate a given domain name from all future searches.

For more on the the available operators: https://sites.google.com/site/gwebsearcheducation/advanced-operators.

lsregister: How Files Are Handled in Mac OS X

The lsregister command is used to query and manage the Launch Services database, or the database that is used to determine the default application used to open files of various types. lsregister is part of Core Services, and stored in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support. To see the options available to lsregister, run the command with no operators:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister

You can dump the database to the screen using the -dump option:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump

You can then grep the database or redirect the output into a text file for parsing:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump > dump.txt

Sometimes applications don’t open with a given file type. When this happens, you can quickly and easily check if the problem has to do with the launchservices database. To do so run the open command and define the application (using the -a option) followed by the app and then the file. For example, to open an XML file called daneel.xml in TextWrangler (assuming your working directory contains bob.xml):

open -a TextWrangler.app bob.xml

You can force an application to re-register file types for that application using the -f option followed by the application path. For example, to re-register Xcode:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -f /Developer/Applications/Xcode.app

You can also unregister a specific application using the -u option. To unregister Xcode you would use the -u option:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -u /Developer/Applications/Xcode.app

The lsregister command is actually just a front-end management tool for the ~/Library/Preferences/com.apple.LaunchServices.plist file. The file’s contents can be read (in an unparsed form) using defaults:

defaults read ~/Library/Preferences/com.apple.LaunchServices

The launchservices database is also responsible for determining whether a file type is quarantined by default (and those files that are quarantined throw a message to users when opened for the first time). To disable such a feature:

defaults write com.apple.LaunchServices LSQuarantine -bool NO

The database can become pretty large and unwieldy. There are applications registered in the local domain, system domain and each user’s domain. You can always clear these out using the following command, which also recursively rebuilds based on the output of a -lint option:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain system -domain user

To check the progress:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -v

To set a specific application to open a file type, use the application’s domain out of the -dump output in an LSHandlerRoleAll and the file extension in an LSHandlerContentType in the LSHandlers array of com.apple.LaunchServices, as follows (to change txt for Text Edit – aka com.apple.textedit):

defaults write com.apple.LaunchServices LSHandlers -array '{ LSHandlerContentType = "txt"; LSHandlerRoleAll = "com.apple.textedit"; }';

You can also set the default application for a network protocol (e.g. smb://, rdp://, vnc://, http:// and https://). Because the options for lsregister leave one wanting in some ways (the commands to set file types to a specific application are a bit overly complicated one could argue), there is an awesome front end app from Andrew Mortensen, aptly called duti, available at http://duti.sourceforge.net/index.php. With duti installed, the command to set the default browser for http would be:

/usr/local/bin/duti -s com.apple.safari http

Note: When working with lsregister, one should first clear the state for that application: http://krypted.com/mac-os-x/controlling-saved-application-states.

Finally, there’s a lot that Launch Services does and is involved in. For more information on LaunchServices, check out the Apple developer library information here.

Replacing the Default SSL Cert For SonicWALLs

The default, self-signed certificate that comes on a SonicWALL causes alerts during a Nessus scan. This is because the device uses a certificate that comes on the device and isn’t signed by a valid CA. Chances are, there are limits around who can load the SonicWALL web interface in the first place. But, if you don’t want Nessus to continue alerting, or if you just want to use a certificate signed by a valid CA because it’s a good security practice, you might want to add a new certificate.

The first step is to generate a new CSR. To do so, open the SonicWALL web interface and then click on System in the SonicWALL sidebar. Then click on Certificates and scroll to the bottom of the screen until you see the New Signing Request button.

At the resultant Certificate Signing Request screen, fill out the fields with your information.

Click on the Generate button to bring up the Export Certificate screen. Click Export and then choose where to save the CSR.

Once you receive the certificate, you’ll want to install it. The easiest way to do so is to go back to the Certificates screen (under System in the SonicWALL sidebar) and then scroll down to the bottom, clicking on Import… Here, use Choose File to pick the cert, provide a name for it and the password for it and click on Import.

Next, click on Administration (also under System in the SonicWALL sidebar). Scroll down to the Web Management Settings section of the screen and use the Certificate Selection field to select the newly installed certificate.

And that’s it. I’ve had to restart the device to get it to work properly, but overall, a pretty straight forward process.

How Exchange’s Autodiscover Works With Mail.app

Autodiscover automatically configures profile settings for Exchange clients. These clients include Microsoft Outlook 2007 or Outlook 2010, Outlook for Mac, Mail.app in Mac OS X, iPhone, iPad and ActiveSync enabled phones. Autodiscover is often made out to be complicated. There’s an Autodiscover service that gets installed when a Client Access Server (CAS) role is setup for Exchange 2010 in the form of a default virtual directory named Autodiscover for the default Web site in Internet Information Services (IIS). You then forward an autodiscover service locater record in DNS in the form of _autodiscover._tcp.

The virtual directory handles Autodiscover requests. But what about other vendors, and even for Exchange, how do you verify that it’s working correctly? If clients automatically configure then it’s working, obviously. But when it isn’t, what do you need to do? The most obvious step is to check that the DNS record responds appropriately. To do so, we can use nslookup. To use nslookup, run it from the command line, followed by the DNS name. For me.com, this might be:

nslookup _autodiscover._tcp.me.com

But note that there’s not a response. This is because me.com doesn’t use _autodiscover (why would it, it’s not EWS/ActiveSync after all. But other domains that are configured for autodiscover would respond. For example, look at the output for 318.com:

nslookup _autodiscover._tcp.318.com

Which looks like this:

Non-authoritative answer:
Name: _autodiscover._tcp.318.com
Address: 66.209.67.173

Provided that the answer section is the address of the CAS Exchange server that sits in front of your organization (the one that runs the Autodiscover virtual directory in IIS) then you are more than likely off to a great start using autodiscover. If not, then that’s the first thing that likely needs to get fixed if you actually want clients to use autodiscvoer. Also keep in mind that you’ll want to check internally and externally, as you will likely have different domain names setup for these. I often find that people will configure the _autodiscover records in their public DNS but not in their private views. Also keep this in mind when acquiring SSL certificates for Exchange’s CAS instance.

Note: Autodiscover, as its implemented in Office Exchange clients, also has the ability to change configurations in Office on the fly as network settings change on internal networks (e.g. users get moved to different information stores, IPs of servers change, etc). This does not seem to work with Apple’s Mail. One could write a script to check for a change in the records nightly (or more frequently of course) if this is needed.

Sometimes the mail clients can interpret things differently than we do manually from the command line, including autodiscover. When the Apple Mail client is attempting to connect to Exchange, you can also get more information about the EWS autodiscovery process by capturing logs about it, not done by default, but invoked by firing up mail using the –LogEWSAutodiscoveryActivity option followed by a YES, as follows:

/Applications/Mail.app/Contents/MacOS/Mail 
--LogEWSAutodiscoveryActivity YES

By reading these logs, you can learn way more than you ever wanted to know (or thought was possible) about Autodiscover. Given that Autodiscover is similar in iOS, most of this rings true in the Mail app there as well. However, given that you can’t view the activity in as granular a detail by invoking Mail through the command line, you can watch it in the logs in iPhone Configuration Utility while you’re setting up Mail, Contacts & Calendars in the Settings app, which should provide information about any connection failures.

While Autodiscover is awesome, you should still be able to connect without it. The only time I really both to troubleshoot Autodiscover itself is when I can install an account but I cannot get Autodiscover to eliminate the need for the second setup screen in Mail on iOS and OS X (possibly with the exception of Lion). If you can setup mail, but it requires two screens then the problem is basically always Autodiscover. If you can’t setup mail at all then the problem is basically never Autodiscover. Good luck, and hope someone finds this useful!

Enable the Debug Menu in the Mac App Store

The Mac App Store has a debug menu. To enable the debug menu, enable the ShowDebugMenu key in com.apple.appstore. To do so:
defaults write com.apple.appstore ShowDebugMenu -boolean YES
Once enabled, there are a number of options to show the folder where apps download, enable logging, clear cookies and reset the Mac App Store.
To turn the Mac App Store debug menu back off:
defaults write com.apple.appstore ShowDebugMenu -boolean NO
Posted on January 5, 2012 at 9:00 am by Charles · Permalink · 2 Comments
In: Mac OS X, Mass Deployment · Tagged with: , , , , , ,

Working with Postgres from the Command Line in Lion Server

Mac OS X Server 10.7, Lion Server, comes with a few substantial back-end changes. One of these is the move from SQLite3 to PostgreSQL for many of the back-end databases, including Wiki and Podcast Producer (collab), Webmail (roundcubemail), iCal Server and Address Book Server (caldav) and as the back-end to the newest service in Lion Server, Profile Manager (device_management). As such, it’s now important to be able to use PostgreSQL the way we once used SQLite3, when trying to augment the data that these databases contains, as there currently aren’t a lot of options for editing this data (aside from manually of course).

Postgres has a number of commands that can be used to interact with databases. The most important is probably psql. Many of the other commands simply provide automated options to psql, and over time I’ve started using psql for most everything. For example, PostgreSQL comes with a command /user/bin/createuser. However, as it’s usually more verbose with errors, I like to use psql to do this. In Lion Server, the only user that can access the Postgres databases is _postgres, installed by default with Lion Server. Because a lot of commands require passwords and we might not always want to provide write access to the databases, we’re going to create a new SuperUser, called krypted with a password of daneel.

To do so, we will have to use the _postgres user to invoke psql. Any time you want to invoke psql with a different user than the user you are currently logged in as, use the -U option. To define a database, use the -d option (device_management providing access to Profile Manager data, caldav to iCal Server data roundcubemail to WebMail data and collar to Wiki data). To string this together, for accessing the device_management database as _postgres:

psql -U _postgres -d device_management

To then create a new user called krypted with a password of daneel we’ll use the create option, defining a user as the type of object to create, followed by the user name and then with password followed by the password (single quoted) and then createuser; as follows:

device_management=# create user krypted with password 'daneel' create user;

Now that there’s a valid user, let’s see what else we can do. To see all of the tables, use \d:

device_management=# \d

As you can tell, there are a bunch of them. Run the help command to see a list of SQL commands that can be run and \? for a list of psql options. To put some SQL commands into action, we’re going to look at the tasks that have been performed by Profile Manager. These are stored in the tasks table (aptly named), so we’re going to run the following SQL query (note a space followed by a semi-colon is required at the end of this thing):

device_management=# select * from "public"."tasks" limit 1000 offset 0 ;

Or to make it a bit simpler if you don’t have a lot of data in there yet:

device_management=# select * from "public"."tasks" ;

After seeing the output, you’ll probably be a little appreciative of Apple’s formatting. Next, let’s look at dumping the databases. We’re going to create a folder on the root of the volume called db_backups first:

sudo mkdir /db_backups

This is where these backups will end up getting stored. We’ll continue using the _postgres user for now. To do our database dumps, we’re going to use pg_dump, located at /usr/bin. First, we’ll dump the device_management database (but first we’ll stop the service and after we’ll start it – all commands from here on out also assume you’re sudo’d):

serveradmin stop devicemgr
pg_dump -U _postgres device_management -c -f /db_backups/device_management.sql
serveradmin start devicemgr

And the other 3 (stopping and starting each in the process):

serveradmin stop web
pg_dump -U _postgres roundcubemail -c -f /db_backups/roundcubemail.sql
serveradmin start web
serveradmin stop wiki
pg_dump -U _postgres collab -c -f /db_backups/collab.sql
serveradmin start wiki
serveradmin stop addressbook
serveradmin stop calendar
pg_dump -U _postgres caldav -c -f /db_backups/caldav.sql
serveradmin start addressbook
serveradmin start calendar

I haven’t had any problems running the dumps with the services running, but it’s better safe than sorry I guess. I’d probably also add some logging and maybe dump the output of full status for each service to try and track if all is well with each. Any time a service didn’t fire back up I’d then build in a sanity check for that event. There’s also a database for postgres itself, so let’s back that up as well since we’re here:

pg_dump -U _postgres postgres -c -f /db_backups/postgres.sql

These can then be restored using psql with the -d option to define the database being restored into and the -f option to define the file being restored from. For example, to restore collab:

psql -U _postgres -d collab -f /db_backups/collab

The databases are all dumped daily using pg_dumpall. These are stored in /var/pgsql but can be changed using serveradmin settings (for example, to move them to /var/pgsql1):

serveradmin settings postgres:dataDir = "/var/pgsql1"

If you mess up the Profile Manager database (before you put any real data into it) you can always use the /usr/share/devicemgr/backend/wipeDB.sh script to trash the database and start anew (although I’d just use a snapshot of a VM for all this and restore from that).

You can also connect to Postgres remotely, or locally through a network socket (common in Apache uses) by adding a listener. To do so, we’ll need to restart the Postgres LaunchDaemon. First, back up the file, just in case:

cp org.postgresql.postgres.plist org.postgresql.postgres.plist.OLD_CSE

Then stop postgres:

serveradmin stop postgres

Then edit the org.postgresql.postgres.plist file to change the following line:

listen_addresses=

To read:

listen_addresses=127.0.0.1

Then fire up postgres again:

serveradmin start postgres

And now let’s scan port 5432 (the default TCP and UDP port used for postgres) for localhost:

/Applications/Utilities/Network\ Utility.app/Contents/Resources/stroke 127.0.0.1 5432 5432

We could have used another IP address for the listen_addresses as well, but with that _postgres user not requiring a password it didn’t really seem prudent to do so. Once you’ve enabled a socket, you’ll then be able to use one of the many GUI tools to manage postgres. Navicat is available on the Mac App Store for $5 and PGnJ is a nice, easy to use, free one. There are tons of others, but I don’t spend a lot of time in a SQL GUI and so don’t need more than a cheap app will get me. One nice thing about most of these is that they help you to form SQL queries (or they help me). This can get really nice if you are, for example, trying to get some good reporting on Profile Manager (a feature it’s a bit light on right now).

Finally, don’t do any of this stuff on a production box, except maybe if you want more than nightly backups unless you think pretty hard about what you’re doing and know the exact impact of doing something. If you were to edit the databases on a live boxen, then you can safely assume that with how all of the objects in those databases use GUIDs that you’re probably going to break something, if not bring the whole house of cards tumbling down.