Monthly Archives: May 2012

Mac OS X Server

Changing Roundcube Max Attachment Size in Lion Server by Duong Nguyen

Thanks to Duong Nguyen for the second user-submitted post on Changing Roundcube Max Attachment Size in Lion Server!

By default, Lion Server’s webmail (Roundcube) has a 5MB max attachment size. The max attachment size is read from php’s “upload_max_filesize” and “post_max_size”. We don’t need to edit php.ini because Lion Server created a .htaccess in Roundcube’s directory that overrides php.ini’s settings.

Please only do this if you are comfortable with the terminal! I start by SSHing to my server as root (or you can open a root terminal).

1. # cd /usr
2. # cd share
3. # cd webmail
4. # vi .htaccess
5. Use your arrow keys to navigate to the end of the 9th and 10th line (“upload_max_filesize” and “post_max_size” respectively)
6. Use your arrow key to highlight the number before M (i.e. 5M)
7. Press i
8. Type 20 (or however large you want) and press delete to remove the 5
9. Press Esc
10. Press :
11. Type x

Now we’re done with the terminal! Restart the Web Server through Server.app, and enjoy your new attachment size!

Active Directory Articles and Books iPhone Mac OS X Mac OS X Server Mac Security Mass Deployment Microsoft Exchange Server

Holy White Papers, Apple?!?!?

For those of you who say Apple doesn’t care about the enterprise, Apple has released a number of assets (technical white papers) on integrating Macs (Lion) into enterprise environments at http://training.apple.com/lion. This is also the page that you’ll find links to all of the official training and certification courses for Lion. The assets up on this page are about as close to a publicly accessible book on integrating OS X into the enterprise as you’ll to see for Lion…

The first covers the basics of integrating Macs into enterprise environments:

The second covers self support:

The third is on evaluating Macs in Enterprise environments:

The fourth is on deployment:

The fifth is on integrating with Active Directory:

The sixth is on managing Macs with Configuration Profiles:

The seventh is on OS X Security:

The last of the papers is on 802.1x authentication:

Mac OS X Mac OS X Server Mac Security Mass Deployment

Setting Up Time Machine Server in Lion Server

Mass Deployment

Deploying and Managing Google Chrome: The Rough Guide

The following is a post from the most excellent Nick McSpadden. It is very well written and I am proud that it is the first article published on this site using the new submissions page. Looks like it’s time to change the banner from my Notes from the Underground, er, I mean, Field, to just Notes from the Field!

Greetings!

This is a sort of follow-up to my guide on managing Firefox, this time focusing on managing Google Chrome. I’m working on current Chrome version 18 (which just today got updated to 19), and I don’t know for sure how far back this will work, but I think anything higher than v16 properly supports the MCX policies.

The good news about Google Chrome is that it supports MCX! Unlike Firefox, which requires specific and somewhat obtuse procedures for managing it (including depending upon an add-on that is independently maintained by a hard working individual), the most important parts of Chrome management can be done with already-existing MCX controls.

First let me start off with a link to a very helpful set of information: http://www.chromium.org/administrators
That link covers just about everything you’ll need to know about Chrome policies and management, though some of it is buried. I discovered (much to my chagrin) that the Chromium site is much more thoroughly documented that Google’s official “Chrome for Administrators” site.

Some important notes about Chrome MCX: all Chrome policies are required to be set to “Always.” They’re like Profiles from Profile Managers – there’s no middle ground. Even if you set it to “Once” or “Often,” Chrome will treat the policy as permanent and prevent the user from changing it. Any policy being managed by MCX in Chrome will be grayed out to user interaction (and there will be a message in the “Options” window about how some settings are being managed by the administrator). So you’re going to have to “Always” manage these settings whether you like it or not.

The good news is, there’s an alternative, the Master Preferences. The downside is that the Master Preferences is a “once” option, and doesn’t prevent the user from changing it. It’s a good way to provide default settings without restricting the users’ ability to personalize it later on. More on that later.

So, following the Mac Quick Start Guide: (http://www.chromium.org/administrators/mac-quick-start)

1. Inside a fresh copy of Google Chrome is a nice fresh copy of the manifest. Access it here: /Applications/Google Chrome.app/Contents/Resources/com.google.Chrome.manifest/Contents/Resources/com.google.Chrome.manifest

2. Load this manifest into WGM

3. Here’s the full description of all policies in the Chrome manifest: http://www.chromium.org/administrators/policy-list-3

4. There are some particularly important settings that will be relevant to most. Here’s what my plist looks like for a lab computer (no individual users):

  • AutoFillEnabled – False (disables the ability to store autofill information)
  • BookmarkBarEnabled – True (forces the bookmark bar to show up on all tabs, all the time)
  • HideWebStorePromo – True (prevents the web store from trying to sell you things, but does not disable the web store)
  • HomePageIsNewTabPage – False (if you don’t disable this, the homepage will be set to the default Chrome tab page, which opens up the “Most Visited/Apps” switcher)
  • HomepageLocation – URL (even if you set this, if HomePageIsNewTabPage is set to true, this URL gets ignored)
  • PasswordManagerEnabled – False (for lab machines, I don’t want them saving passwords, intentionally or accidentally)
  • RestoreOnStartup – 0 (0 forces it to open the homepage URL on startup)
  • SyncDisabled – True (same reason as Password Manager – I don’t want these personalized at any time).

That gives you a basic setup for most things you’ll need to worry about. If you deploy this, you’ll notice a few problems, though. The first time you launch Chrome, it gives you an undismissable dialogue box asking you if you want to make Chrome the default or submit other info. That’s bad. The above manifest also provides no way to control the auto update mechanism, if that’s something you want to do.

This is where the Master Preferences file comes in – http://www.chromium.org/administrators/configuring-other-preferences. By specifying a Master Preferences file, we can load up default preferences for user accounts *when they are created.* Note that the Master Preferences file has absolutely no effect on already existing Chrome profiles – only upon new-user generation does Chrome load this file. It literally copies and pastes the settings in here into the appropriate places in ~/Library/Application Support/Google/Chrome/Default/Preferences.

On Mac OS X, the Master Preferences file must be located at:
/Library/Google/Google Chrome Master Preferences
(yes, really – the file must be named “Google Chrome Master Preferences” with no extension), and must obviously be readable by any user who can launch Chrome (i.e. use 644 permissions).

The Master Preferences file is a JSON file that can contain any of the preferences normally used by Chrome. If you want the full list of all possible preferences, load up a default Chrome profile and take a look at the Preferences file I mentioned at the path above. It has everything you’d ever want (and a lot of stuff you probably don’t). To save you some time, here are some important ones you’ll want to use specifically for deploying Chrome:

{
"homepage_is_newtabpage" : false,
"browser" : {
"show_home_button" : true,
"check_default_browser" : false
},
"bookmark_bar" : {
"show_on_all_tabs" : true
},
"distribution" : {
"skip_first_run_ui" : true,
"show_welcome_page" : false,
"import_bookmarks" : false,
"import_bookmarks_from_file" : "/Library/Google/chrome_bookmarks.html",
"make_chrome_default" : false
},
"sync_promo" : {
"user_skipped" : true
}
}

The chromium.org page I linked above goes into a bit more detail about this, but I want to give a quick note about the interaction between preferences and MCX. MCX always wins. Any policy managed by the MCX and also specified in the Master Prefs will always go the MCX policy. In the example above, if I had set “homepage_is_newtabpage” to true, it would still be false because MCX sets it to false, and that policy is always enforced.

The really import part is the “distribution” section. “skip_first_run_ui” will get rid of that annoying dialog box that comes up when you first launch Chrome. The “import_bookmarks” option asks the user through a UI dialog box if the user wishes to import bookmarks from another browser. Obviously, we want to suppress that. There’s an option instead to silently import bookmarks from an HTML file. You can create this bookmarks HTML file by setting up the bookmarks the way you want, and then Exporting them in the Bookmark Manager. I place that bookmarks file in /Library/Google/ because it’s already used, but you can put it anywhere. There is, however, a known bug that has now been assigned a milestone and a solver in Chromium’s bug list – the “import_bookmarks_from_file” is actually ignored if the “skip_first_run_ui” is set to true. So right now, you can’t silently import your bookmarks in.

The “sync_promo” item doesn’t seem to be necessary if you disable Sync in the MCX settings above, but since MCX policy always wins over Master Prefs, there’s no penalty or downside to including it.

Note that your JSON syntax has to be perfect for this to work. Any incorrect comma placements, and it simply ignores your master prefs file. If you find that your Master Prefs isn’t loading up as expected, run Chrome from the Terminal with the debug log turned on to see what’s happening:
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome –enable-logging –v=1
This places a file called “chrome_debug.log” in ~/Library/Application Support/Google/Chrome/Default/ (i.e. default user data directory). The first line will tell you exactly what went wrong with your Master Prefs file.

Now, there’s still one more problem here: new tabs open up to the default Chrome “New Apps / Most Visited” switcher page (called the newtab page). Unfortunately for us, there’s no way to change this behavior present in the UI. The good news is, this behavior annoys plenty of other users, and there are a million extensions you can use to get rid of it. More good news, is that you can silently include extensions in your MCX manifest!

So simply add this to your MCX settings above (forgive the pseudo XML here, just to indicate type of key):
<array> <string>lcncmkcnkcdbbanbjakcencbaoegdjlp;https://clients2.google.com/service/update2/crx</string> </array>

This silently forces the install of an extension called “Empty New Tab Page,” and specifies an update URL for it (required, since Chrome autoupdates its extensions too if they come from the Chrome Web Store / Extensions pages). The extension does what you think it does – you get a blank page. There are other extensions for customizing the new tab pages, or anything else, so as long as you get the extension ID (it’s the long block of letters in the beginning), you can load whatever you want in here.

There you go! I’ve tested this using Local MCX on my 10.6 and 10.7 machines, and it works perfectly (deployed through Munki as well). On the whole, Chrome is a bit easier to manage and deploy than Firefox, just because it doesn’t require modifying the app itself to do this. Also, the Master Preferences file works for any instance of Google Chrome – even if the users install a copy somewhere other than /Applications. This also does work for Chromium, the open-source version of Chrome.

Hope this helps someone.

Mass Deployment

Deploying and Managing Firefox: The Rough Guide

Another Great Article Submitted From Nick McSpadden:

After working with this for a bit, I’ve come up with a step by step installation process for Firefox 10 ESR + CCK deployment on Mac OS.

Firefox CCK Guide – Part I
Most of the information about add-ons that you’ll need is in Mike Kaply’s blog:

http://mike.kaply.com/2012/02/09/integrating-add-ons-into-firefox/

1) Install CCK Wizard in Firefox 10 ESR
2) Run and configure CCK Wizard the way you want
3) Save the CCK data into a “CCK” folder anywhere you’d like.  This folder will contain:

  • cck.config
  • cck.xpi
  • xpi/ directory

4) When done, open up CCK/xpi.config
5) Copy the contents of the id=<name> key – this is the name you provided when configuring the CCK addon.  In my example, it is “test-sacredsf-cck@extensions.sacredsf.org”.
6) Rename “xpi” folder into the ID key from Step 5
7) Inside Firefox, create: Firefox.app/Contents/MacOS/distribution/bundles/
8) Move renamed xpi folder from Step 6 into Firefox.app/Contents/MacOS/distribution/bundles/
9) Launch Firefox, enjoy CCK!

Now, this is means that Firefox needs to be specially packaged and distributed during deployment. While this is easy for first-time deployment, it does mean that future versions of Firefox will also require repackaging. If you want to avoid this, it means you’ll have to change Firefox’s addon scopes. If you’re already repackaging Firefox for the CCK as above, then it isn’t a big deal, use the instructions in Mike Kaply’s blog:

http://mike.kaply.com/2012/02/21/understanding-add-on-scopes/

Firefox Changing Add-On Scopes – Part II
1) Make a text file named whatever you want as long as it ends in .js, such as “scopes.js”
2) Add these two lines to the file:

pref("extensions.autoDisableScopes", 0);
pref("extensions.enableScopes", 15);

3) This file needs to be saved in Firefox.app/Contents/MacOS/defaults/pref/ (the blog suggests it should be defaults/preferences/, but for me /prefs/ was already created)

4) Now user scopes are changed to the settings above.

However, if you want to avoid repackaging Firefox completely every time an update or a change to your CCK configuration comes out, or you want to have different CCK settings for each user on the system, you’ll need to change things up a bit. One way or the other, you’ll need to change the Addon Scopes, because FF10′s defaults lock out the extra directories. If you don’t want to rebundle/repackage Firefox 10, you can use any script to add in the preferences you need into Firefox.app. You can do it simply with echo:

$ echo -e "pref("extensions.autoDisableScopes", 0);npref("extensions.enableScopes", 15);" > /Applications/Firefox.app/Contents/MacOS/defaults/pref/scopes.js

(obviously double check to make sure the .js file can be read by Firefox, although I didn’t have to do anything for it to work)

Doing this allows Firefox to use any of its valid locations for extensions, listed here:

https://developer.mozilla.org/en/Installing_extensions

In other words, you’ll want to move and rename the “xpi” folder from the CCK Guide Step 6 into this location if you want it to affect all users:

/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/test-sacredsf-cck@extensions.sacredsf.org

This unpacked folder (from CCK Guide Step 4) contains the xpi contents:

  • plugins/
  • modules/
  • install.rdf
  • defaults/
  • components/
  • chrome.manifest
  • chrome
  • cck.config

…and so forth.

Use this location if you want it to affect individual users only:
~/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/
(i.e. /Users/…/Library/…)

To summarize:

I. For an individual user, I’d need to change Firefox’s addon scopes, and I’d need the unpacked xpi contents located here:
~/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/

II. For all users, but not packaged within the application itself, I’d need to change Firefox’s addon scopes, and put the unpacked xpi contents here:
/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/

III. For all users, who will be unable to disable or even see the add-on, inside the Firefox.app bundle itself, I don’t need to change addon scopes. I just need to put the unpacked xpi contents here:
/Applications/Firefox.app/Contents/MacOS/distribution/bundles/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/

That’s how you get the CCK configured and installed in its various permutations on Mac OS X. I hope that helps anyone who was struggling or thinking about adopting the Firefox 10 Extended release into their deployment strategy, as the CCK is a great tool for preconfiguring Firefox to suit your enterprise’s needs.

“But wait!” you might say.  “How do I perform an enterprise-level deployment with this method?”  See my post here for details on incorporating this into Munki: http://krypted.com/mass-deployment/deploying-and-managing-firefox-part-2-working-with-munki/.

Mac OS X Mac OS X Server Mac Security Mass Deployment

Automated Regression Testing Mac OS X Clients Using Sikuli

Imaging can be a complicated task. Many imaging environments have a lot of scripts, packages, base images and other aspects of automation. The more of these that you have, the more potential combinations you have for the state of a system once they’ve been run. This gets complicated when you want to make sure that each possible combination of images will have a consistent result when installed. For example, take something simple, like a property list. Each possible combination of packages, scripts images and even managed preferences might have a different impact on that poor property list.

A simple defaults command can often give administrators the ability to see what settings have been applied to a system. For simple tasks that can be programatically trapped for, this might be enough. You can argue that everything can be programatically discovered, but I would argue that is an immature way to look at such things. The example I used in the Enterprise Mac Administrator’s Guide was looking at Microsoft Word. Let’s say that you install 24 fonts. When you open Word, you end up needing to check and make sure that each font loads. You can verify fonts test clean, but you can’t verify that they show up in Word. Microsoft gives you the ability to list fonts that appear in the font menu programatically. But you would literally need to open Word and look in the fonts menu on each regression of each system image in order to tell if the fonts actually appear in the list and if so, whether they look right. One small example. In many environments, each application will have 10 or more tests, with a lot of applications potentially being deployed – and the list grows as failures are discovered year over year…

Now let’s say you’ve got 80 packages in your self service library. At this point, in order to tell that every combination is cool, you’d need to manually open Word on a lot of image combinations in order to verify that your fonts load properly. EggPlant is a tool that enables administrators to run a script that clicks on things for us and reports back on what happens when we do. Now, AppleScript can do some of this as well. But eggPlant gets very in depth in terms of scripting logic and is cross platform. EggPlant leverages a Vine server that gets installed on clients. Screen shots are then taken through a Vine client and compared to screen shots you make and save in eggPlant to compare to the ones that are captured from Vine. That’s a bit of overs implication, but at the end of the day, bolt some simple scripting on top of that and you’ve got a pretty advanced solution. EggPlant now also supports iOS by jail breaking devices to load the Vine server.

EggPlant is one of the best tools for this kind of thing for the Mac platform. It’s more popular amongst those who do a lot of web testing, but it shoehorns nicely into post-flight imaging regression testing. I had a good conversation with @tvsutton at the Penn State Mac Admins conference about eggPlant and he mentioned a tool called Sikuli that I hadn’t used before, so hat tip to him for the rest of this article. While eggPlant has way more logic in it, for simple regression testing, you can leverage Sikuki in its place, which wouldn’t cause some of the potential conflicts that running a localized Vine server might cause on client systems.

Sikuli is a simple tool that allows administrators to script graphical events. You can effectively automate anything you see on a screen using the same type of screen shots; however, with Sikuli, you dump the screen shots directly into the script via the scripting interface, known as the Sikuli IDE.

The first step to using Sikuli is to download the IDE from their site and run the installer. Once installed, open Sikuli.

The options along the left side are some common commands that can be run, in serial from top to bottom. Not all of the possible methods are exposed in the GUI sidebars, but many of the more common ones are. Let’s go ahead and manually enter switchApp followed by an application you’d like to open with your script. In my example, I’m going to use Server.app:

switchApp("Server.app")

While the command says switchApp, it might as well say openApp, as the application will open when you run the command. Go ahead and see for yourself (assuming you have a Lion Server and can therefore open Server.app. Now, let’s look at some graphical interfacing, go ahead and click on click in the sidebar, which will dim the screen and bring up crosshairs for taking a screenshot. Here, select some part of the screen. I’m using Users for my example:

Once you take the screenshot, it should appear in the parenthesis after click. Next, we’re going to send a screenshot command to the computer itself. To do so, we’re going to use the type command, which conveniently types content into the screen. You can also use this for dialog boxes and other such things, but we’re going to just use it to send a screenshot command to the server. To do so, we’re going to tell it to type the 3 key, along with KeyModifier.SHIFT and KeyModifier.CMD:

type("3", KeyModifier.SHIFT + KeyModifier.CMD)

Now your screen will look something like this:

Running the workflow should result in a screenshot on your desktop, of the users on the system. Next, let’s just repeat this process by clicking on all the screens, grabbing a little screenshot of each and producing results on the desktop. All we’re going to do is cut/copy/paste the actual commands and then loop through each of the services and screens in Server Admin until we’ve gotten a screenshot of each:

Now is when things can start getting a little more interesting. We could have done everything we did up to now using Automator. But Sikuli has some built in logic. Here, we’re going to use the wait option in the Find section of the sidebar to go ahead and wait each screen that can be latent to show content. After we click the services, we’ll wait for a pattern on the screen not specific to any given system but that only appears when the settings appear, as follows:

This is a basic configuration of Sikuli, with a simple task, take some screenshots of the Server application. It can then be anchored to an imaging workflow by invoking the workflow from the command line. The command line is just a shell script sitting in the Sikuli-IDE, which is by default dropped into Applications. Because you won’t need it for standard systems, you can use it in special regression testing workflows from your imaging solution. Save the workflow you’ve been running as some title (I’ll use ServerApp) with the .sikuli extension. Then, to run it from the command line, fire up sikuli along with the actual project and a -r operator to tell it to run:

/Applications/Sikuli-IDE.app/sikuli-ide.sh ~/Desktop/ServerApp.sikuli -r

You can also use the sikuli-ide.jar or sikuli-script.jar to get an even lighter install, documented at http://sikuli.org/docx/faq/010-command-line.html#cmdoption-t on the sikuli.org site. On that page, it also explains how to pass arguments to Jython’s sys.argv using the –args option as well as using -stderr. The scripting environment from there becomes jython, a mashup language that takes python and java and uses a little duct tape to hold them together. Overall, it’s an interesting concept. There isn’t a lot of logic, unless you’re willing to script things. But if you are willing to script things then you can do pretty much anything you might want. For example, you can have it play bejeweled for you, so you can actually get some work done (although perhaps you’d rather play bejeweled and script your meetings…):

iPhone Mac OS X Mac OS X Server MobileMe

Removing A Credit Card From An AppleID

Sometimes you deploy iOS based devices with iTunes. There are a number of factors that can still force you into iTunes based deployments, such as needing the icons to appear a certain way in iOS. It’s not optimal but it happens. And sometimes you need to give an iPad or iPhone to a user leveraging an existing AppleID that will have a password known by multiple users. Again, not the right way, but there are design requirements that cause you to do it from time to time.

And if you’re using a shared account, one of the last things you want is for users to actually buy stuff with that shared account. Because you might have used that account and connected a credit card to it, it can come up from time to time that you then need to disable that card. Again, none of this is optimal, but it happens.

To remove the card, first open up iTunes.

From here, click on the AppleID in the upper right hand corner of the screen (the email address the account was registered with, usually) and select Account from the drop-down list.

Once the account page loads, click on Edit beside the Payment Type.

At the Edit Payment Information screen, click on None (the big red arrow isn’t actually on the screen at this point, btw).

Then click on Done and there won’t be a payment funding source attached to the account any longer. This can cause a few minor issues with deployments, but turns out way better than having tons of explicit content downloaded to devices using your organizations funds…

Mac OS X Mac OS X Server Mac Security Mass Deployment

Video On Setting Up Software Update Services In Lion Server

sites

New User Submission Page

I have now opened up the site to user submissions and built a page to submit content. I’ve also tweaked the layout a little more to make things load faster and cleaned up the nav bar so that the Submit button can take you to the submission page. I hope to see some pretty awesome submissions after slaving away on the forms!

A couple of notes on submissions:

  • Submissions do not require authenticating to the site
  • For any accepted submissions I will create an account for you (unless you already have one) and make sure that submissions are properly attributed
  • Feel free to submit a snippet along with a read more… type of link that kicks to another site. Unless it’s a problem I’ll accept those articles, but would prefer them to be over 2 paragraphs

The submission page is here: http://krypted.com/submissions

cloud Mac OS X

I

Google recently decided that it was time to force some other company to buy cloudy dispositioned upstarts, Dropbox and Box.net. Google also decided that Office365 represented Microsoft being a little too brazen in their attempts to counteract the inroads that Google has made into Microsoft territory. Therefor, Google thumped their chest and gave away 5GB of storage in Google Drive. Google then released a tool that synchronizes data stored on a Google Drive to Macs and Windows systems.

Installing Google Drive is pretty easy. Just browse to Google Docs and Google will tell you that there’s this weird new Google Drive thing you should check out.

Here, click on Download Google Drive for Mac (or Windows if you use Windows). Then agree to give your first born to Google (but don’t worry, they’d never collect on that debt ’cause they’re sworn to do no evil).

Once downloaded, run the installer. You can link directly to your documents now using https://drive.google.com.

The only real question the installer asks is whether you’d like to automatically sync your Google Drive to the computer. I said yes, but if you’ve got a smallish drive you might decide not to. Once the Google Drive application has been downloaded and installed, open it (by default it’s set to open at startup). You’ll then see a icon in the menu bar that looks a little like a recycling symbol. Here, click on Open Google Drive folder.

The folder with your Google Docs then shows up on your desktop. Copy an item in there and it syncs up to Google. It can then easily be shared through the Google Apps web portal and accessed from other systems.

While there are still a number of features that Box.net and Dropbox will give you due to the fact that they’re a bit more mature, I’d expect Google Drive to catch up fast. And given that I already have tons of documents in Google Docs, it is nice to have them saved down to my local system. I’m now faced with an interesting new challenge: where to draw the line in my workflow between Google Drive, Dropbox and Box.net. Not a bad problem to have, really! Given the frustrations of having things strewn all over the place I’ll want to minimize some of the haphazardness I’ve practiced with regards to why I put things in different places in the past. In some cases I need to be able to email to folders, have expiring links or to have extended attributes sync between services, so there are some aspects that are likely to be case-by-case… Overall though, I’m very happy with the version 1 release of Google Drive. I mean, who complains about free stuff!?!?!