[mosen]

I’m glad that they did continue to release servers at all, although I was kinda hoping they would license the server to run under some different VM hypervisor/hardware.

Having a combined server/client version of the operating system is really not that strange if you think about your average out of the box linux distribution.
It kinda makes sense given that so much of the operating system is common to both the server and client versions. It would reduce a lot of development time on their end. The worst part of it though, is that I’m a bit startled by the possibility of all workstation users to configure their own servers or AirDrops (if they had wifi on).

In that sense, I really hope that the new management tools will give us more control over configuration of the other machines. I’m a bit cynical given that for the past couple of releases, the server version of the operating system boasts a shiny interface, but then you find gaping holes of functionality which invalidate having the interface in the first place (see dns management). In a similar vein, MCX seems to control some aspects of the OS and then inexplicably leave out pretty obvious targets (like sidebar mcx, which is really quite limited for something so central to the operating system).

The profile based management looks reminiscent of the iphone configuration utility and is probably some extension of that idea. Although I can only speculate on how that works 🙂 (im not a registered developer), I’d gamble to say that the xml output of that would be stored in a directory record and then applied via a client process similar to ManagedClient.app, and some equivalent application on the other platforms.

Anyway, it looks like they will keep server alive.. but most of the things they are pushing are driven by their consumer products moreso than needs of the enterprise.

I guess they’re a phone company now, and I’d be wrong to think different 🙂

[mosen]

Hiya,

stdin can be passed through a pipe. so the following might do what you would like:
[code]
echo -n $password | hdiutil convert -quiet $bkpath/$tempname -format UDRO -o $bkpath/$endname -encryption -stdinpass
[/code]
the -n is important for echo because otherwise you will end up with a password having a newline character.

Mo.

[mosen]

[u][b]Manual Deployment of iChat (XMPP/Jabber) accounts in Mac OS X 10.6[/b][/u]

This post describes a method of manually deploying iChat jabber accounts via a custom plist.
Again, a couple of points to note (mostly the same caveats with iCal):

– This works best with a kerberized iChat set up. iChat does not recognise any pre-supplied password.
– MCX normally relies on ManagedClient to transform ‘%@@yourdomain.com’ to ‘[email protected]’. ManagedClient fails (In many environments), so you need your own script/application which will apply the user details and substitute them into the .plist file (I use puppet, you could use LoginHooks or a Package postflight.. there are a lot of options). This post describes the plist after you have substituted login names.
– Some people have posted ways of manually inserting iChat accounts using the plist, but they are not regarded as managed (i.e the user may modify those accounts after they are installed). The method I’m describing is for accounts that will be enforced.

[u][b]Crafting a plist for iChat on 10.6[/b][/u]

ManagedClient is expected to take your manifest keys from XMPPAccount, apply formatting, and then write them as a dictionary called ManagedAccounts.
If you have existing accounts, you need to be careful that you won’t overwrite the “ActiveAccounts” or “Accounts” keys inside com.apple.iChat.Jabber.plist. If you clobber those keys then the users will lose their existing accounts. If you don’t care, then go ahead and wipe out the contents.

The GUID here “00000000-0000-0000-0001-000000000001” is special. It indicates the account type (Managed/Jabber), you can’t use another key for a managed jabber account.

This is what iChat expects for a “Managed” account in com.apple.iChat.Jabber.plist (new entry in the root of the plist dictionary):

[code]
ManagedAccounts

00000000-0000-0000-0001-000000000001

AllowSelfSignedSSL
1
AutoDiscoverHostAndPort
1
Description
account title here
LoginAs
[email protected]
ServerHost
ichat.server.hostname
ServerPort
5222
ServerSSLPort
5223
UseKerberos5
1
UseSSL
1

[/code]

[u][b]A short guide to the dictionary keys:[/b][/u]

[b]AllowSelfSignedSSL[/b] – 0/1 whether to allow self signed SSL certificates. I could go into a discussion about self signed SSL but just do your research. Leave it on if unsure.
[b]AutoDiscoverHostAndPort[/b] – 0/1 whether to auto discover host and port. I believe this uses your DNS SRV records to locate the port and host for a particular jabber domain.
[b]Description[/b] – Description of the account. Appears at the top of the iChat window.
[b]LoginAs[/b] – Jabber username, typically this will be user@domain and not just user.
[b]ServerHost[/b] – Name of the server to use for this account.
[b]ServerPort[/b] – Port to use in non-ssl mode.
[b]ServerSSLPort[/b] – Port to use in SSL mode.
[b]UseKerberos5[/b] – 0/1 Whether to use kerberos as authentication.. I think its the best solution to try and utilize SSO.
[b]UseSSL[/b] – 0/1 Whether to use SSL for the iChat connection.

Some other keys may apply to the managed account, although I haven’t personally tried them yet. (Probably all relevant normal account keys apply to managed ones) such as:

[b]UseMachineName[/b] – Use the computer name as the location
[b]XMPPTLSEnabled[/b] – TRUE/FALSE – TLS encryption.
[b]UseKeychain[/b] – Use the keychain for password authentication.

[u][b]Background Information[/b][/u]

Again, ManagedClient is responsible for processing the XMPPAccount dictionary by applying format strings. The formatting fails because it can’t substitute the token for a null value and the post compositing step fails because of this. End result: iChat prefs are composited and then ManagedClient bails.

Unlike iCal which interacts with its own calendar store API to create new accounts, iChat does not move the managed account from the plist at all. iChat doesn’t do any kind of substitution or key renaming when you add the ManagedAccounts key to the preferences file.

If you would like to try, the iChat post compositing step in ManagedClient allows the administrator to define managed accounts for every type of account. The manifest only defines one account type (Jabber). You can even supposedly supply settings for bonjour accounts, although it seems like there are only 2 valid keys anyway.

If you wanted to try, the key names for other types of accounts are:
00000000-0000-0000-0003-000000000001 – For com.apple.iChat.AIM
00000000-0000-0000-0002-000000000001 – For com.apple.iChat.SubNet (Bonjour)

Another point to note: Managed accounts have two reserved GUIDs. They seem to indicate one being the user domain preference and one being the host domain preference.
The GUIDs for those two types are:
00000000-0000-0000-0001-000000000001 – For a host level Jabber account.
00000000-0000-0000-0001-000000000002 – For a user level Jabber account.

If you don’t understand how to apply these different key names.. you probably only need my first example plist structure.

Cheers, and I hope that this will help you deploying your lab/site.
Feel free to add anything or correct any mistakes too!

Mosen.

[mosen]

[u][b]Manual Deployment of Managed Accounts in iCal (Mac OS X 10.6)[/b][/u]

There are a couple of important points to note before deploying iCal manually:

– This works best with a kerberized iCal set up. The password won’t be filled in by iCal, and iCal does not contain (from what I see) a method to supply passwords from a .plist.
– MCX normally relies on ManagedClient to transform ‘%@@yourdomain.com’ to ‘[email protected]’. ManagedClient fails (In many environments), so you need your own script/application which will apply the user details and substitute them into the .plist file (I use puppet, you could use LoginHooks or a Package postflight.. there are a lot of options). This post describes the plist after you have substituted login names.

[u][b]Crafting a plist for iCal on 10.6[/b][/u]

After ManagedClient has done its job. iCal expects a structure similar to the following, which must exist inside com.apple.iCal.plist in the user (~/Library/Preferences) or host (/Library/Preferences) domain
I.E you should insert this into the existing plist (if there is one existing):

[code]

accountsToImport

00000000-0000-0000-0000-000000000000

PrincipalURL
http(s)://ical.host.name:8443/principals/users/johnsmith/
Login
johnsmith
Kerberos
FullName
John Smith
Title
My Company
UID

[/code]

[u][b]A short guide to the dictionary keys:[/b][/u]

[b]PrincipalURL[/b] – This will determine the host name, protocol (SSL on or off), port AND the principal path for this user. Replace ‘johnsmith’ with the short
login name of the user. These are separate keys in the manifest, but iCal expects just this URL in the end.
[b]Login[/b] – Short username login for iCal Server.
[b]Kerberos[/b] – TRUE/FALSE. As stated earlier, non-kerberos may not be viable because you need to go back into the account and set the password, so what’s the point of automating the deployment? 🙂
[b]FullName[/b] – Full display name of the user, should be derived from their open directory full name “John Smith”
[b]Title[/b] – Title of the iCal account. This appears in the iCal “Sidebar” (and accounts listing), and is the heading for all of the iCal server based calendars listed for this user.
[b]UID[/b] – Leave as an empty string. iCal will call GenerateUID or something similar to make sure that the new account is uniquely identified by iCal and SyncServices buddies.

[u][b]Background Information[/b][/u]

ManagedClient is the one mechanism responsible for taking care of MCX in 10.6. It also contains the MCX Compositor, which is used to combine all of your mcx into one set.
A certain number of MCX manifests provided by ManagedClient can’t be constant like the dock (for instance). Dock hiding is on or off, on the left or on the right. iCal and iChat accounts are different for each login. For every manifest that describes something variable (account details will be different for every login), there is a post compositing section in ManagedClient.

The failure of ManagedClient to post composite some parts of the MCX and not others explains why dock might work, but not any of the things that need access to the user id, user short login or full name.

The iCal post compositing sequence goes roughly like this:

– Read user defaults (com.apple.iChat.plist)
– If we have a key called “accountsToImport” in there, proceed.
– Go through all the sub keys and make accounts out of them. By default – the manifest will use the special GUID 00000000-0000-0000-0000-000000000000. For multiple accounts i suppose you could just increment by 1.
– Set up a blank dictionary for all the account info
– Get the principal URL
– Grab the login, shove into dictionary
– Grab the ssl,host,port portions of principalURL, shove into dictionary
– Grab the kerberos flag, set that.
– Set the refresh interval based on default(?) Not 100% sure, but it doesn’t reference the .plist.
– Generate a nice GUID string for our account, set that.
– Set the path.
– Set the full name.
– Set the title.
– Set the flag that says the calendar is enabled, hardcoded to TRUE.
– Set the flag that says the calendar is twisted open/expanded, hardcoded to TRUE.
– Take this account info and give it to the principal manager.
– Make the contents of “accountsToImport” empty, because we processed the account(s), and they shouldn’t be re-executed every time you start iCal.

I hope that my investigation of the ManagedClient MCX post composition and iCal account import functionality has helped you in your environment.
Feel free to add anything or correct any mistakes, I will edit the post as necessary.

Mosen.

[mosen]

iCal Update:

What the iCal manifest specifies, and what iCal actually tries to import are two VERY different things. I would say that ManagedClient should perform the transformation from the manifest form, to the form iCal can understand – but it doesn’t (on my system).

And here are the differences in key name (/Library/Preferences/com.apple.iCal.plist):

[b]accountsToImport / 00000000-0000-0000-0000-000000000000[/b]

[b]manifest -> ical expects[/b]
CalDAVDisplayName -> FullName
Use_Kerberos_Key -> Kerberos
CalDAVPrincipalURI -> PrincipalURL
Description -> Title

I had an iCal account that was automatically created using these keys that ical expects, combined with the manifest keys.
Upon launching a second time it has disappeared, and iCal no longer wants to read the file – so I am working on how to ‘reset’ ical (might be SyncServices).

[mosen]

OK well, this post is turning into my blog now.. but it is the same topic (MCX not working under 10.6):

In iCal 10.6, the settings are composited by MCXCompositor and then ManagedClient will apply string formatting so you get a dictionary with real account names instead of the %@ placeholder.

Unlike iChat, iCal does not process a plist into another plist, but reads the prefs file so that it can interact with the API to create our managed account.

iCal is looking for a key “accountsToImport” as a part of its preferences. iCal calls [[NSUserDefaults standardUserDefaults] objectForKey:@”accountsToImport”].
I assumed wrongly that if a key was present in the user domain (~/Library/Preferences/com.apple.iCal.plist:accountsToImport), that iCal would read it. Strangely enough we get a null result if you try to use that .plist file for imported accounts.

With a hunch, i used the host domain (/Library/Preferences) and objectForKey actually returns the NSDictionary!! There’s something seriously wrong here because theoretically it should be able to load preferences from the user domain.

PS. I was wrong in identifying ManagedClient as a separate process to MCX.. ManagedClient (10.6) = MCXD (in 10.5).

[mosen]

I have been working on iCal now.. I’ve discovered that unlike iChat (which converts a plist to its expected format), iCal
reads in the iCal.managed.plist, checks for accountsToImport, and creates the calendar with CalendarStore framework (I think…). The API seems private?

I can’t currently get iCal ManagedClient settings working in either 10.5 or 10.6.. so It’s a little hard to test at the moment, but im working on it 🙂

[mosen]

Hehe, sorry im flooding this topic now 🙂

There are two separate methods for creating the ManagedAccount present in ManagedClient.app.

[MCX_PostComposite(WildcardPrefs) updateiChatDomainWithUsername:withGUIDKey:] and
[MCX_PostComposite(WildcardPrefs) updateUseriChatDomainWithUsername:withGUIDKey:withHome:]

They use different GUIDs for the dictionary name under ManagedAccounts (00000000-0000-0000-0001-000000000001 and 00000000-0000-0000-0001-000000000002 respectively)

I’m not sure why these 2 methods exist. If i had to guess it would just be computer vs user domain preferences. So either GUID is safe to use when creating a custom plist entry.

[mosen]

OK,

I’ve found the exact plist configuration that ManagedClient SHOULD produce, but doesn’t. I have no idea why ManagedClient is stopping halfway through postCompositeiChat, but i will try to debug it.
Here’s an example of what iChat expects.

I will just post the jabber account configuration at the moment. And there are slight differences in the AIM and SubNet plists (they use a different GUID and key/value structure). (They should be less frequently requested configurations)

Managed accounts should be transformed by ManagedClient from the “XMPPAccountToImport” dictionary into the following structure, inside com.apple.iChat.Jabber.plist

Root -> ManagedAccounts (Dictionary) -> 00000000-0000-0000-0001-000000000001 (Special GUID name for managed account dictionary) -> Contents of XMPPAccountToImport (key/values)

To make it clearer: lets say you load ManagedClient into workgroup manager. You edit iChat-10.6 and make a new accountInfo key. You would get the default values of ichat.apple.com for everything. What com.apple.iChat.Jabber.plist should look like in this case (If ManagedClient.app actually converted XMPPAccountToImport into ManagedAccounts entries):

[code]
ManagedAccounts

00000000-0000-0000-0001-000000000001

AllowSelfSignedSSL
1
AutoDiscoverHostAndPort
1
Description

LoginAs
%@@ichat.apple.com
ServerHost

ServerPort
5222
ServerSSLPort
5223
UseKerberos5
1
UseSSL
1

[/code]

I omitted the ActiveAccounts and Accounts keys for brevity.

When you launch iChat on 10.6 it will attempt to use this ‘%@@ichat.apple.com’ account, and fail (of course!). The important thing is that the transformation process undergone by ManagedClient is understood.

What this means now is that we can either attempt to debug ManagedClient, to find out why it’s bailing (the first thing i can see is replacing LoginAs with NULL.. that doesn’t seem like it would work well).. ORR option #2 is that we move away from ManagedClient and develop a script which actually does the same thing (read MCX cache, swap some variables, write iChat dictionary).

I will keep trying to identify the original problem though – as that is the cleanest method.

[mosen]

i wrote a really long post about trying to find out why this is happening, but it got marked as spam 🙁 So time to write another really long post, I hope it will get some people engaged in the problem, or at least provide some information.

I can’t get either iChat or iCal MCX settings to apply in any 10.6 environment – I don’t know if anyone has? I’m trying to find out
why this is happening (if it’s a common thing).

I’m comparing how ManagedClient.app acts between 10.5 and 10.6 to get an idea of why it is happening, and i’m starting to understand the underlying
design behind the ManagedClient.app. For any plist which relies on formatted strings/variable substitution or some other interaction with a system framework, the ManagedClient acts as a ‘post compositor’. The MCXCompositor still resolves the composition of preferences from computer accounts, user accounts etc, but the ManagedClient must transform the cached composition to the end result.

The first thing i did was turn on debug output for ManagedClient. This doesn’t seem to be documented in a lot of places (found it in a textbook), so I’ll repeat here:

[code]sudo defaults write /Library/Preferences/com.apple.MCXDebug debugOutput -2[/code]

This gives you a /Library/Logs/ManagedClient/ManagedClient.log which prints each Post Compositing function as it happens, and some of the variables it is using.
Also note that you can force the postcompositing steps to happen if you use:
[code]sudo /System/Library/CoreServices/ManagedClient.app/Contents/MacOS/ManagedClient -f ‘-u ‘[/code]

Particularly interesting is the debug information regarding the iChat post compositing section:
[code]
MCX -postCompositeiChat
MCX -updateUseriChatDomainWithUsername found user prefs for com.apple.iChat.Jabber
MCX -updateUseriChatDomainWithUsername, found iChatAccount
MCX -ApplyFormatToStringKey, changedString:(null) for key:LoginAs
[/code]
It seems to look like the variable substitution isn’t happening at all with ApplyFormatToStringKey, which i guess is just something like [NSString stringWithFormat:] iirc.

The same goes for iCal on my system.. the login name doesn’t get post-processed. I end up with a composited iChat preference and the loginname doesn’t seem to have been applied to the ‘%@’ formatting variable. This might be a common symptom, or just my machine. Regardless – it needs troubleshooting.

I tried the same thing on a Mac OS X 10.5 Server virtual machine using Local MCX preferences for iChat. I know that the post composition step must be different because the preference filename and preference keys differ for iChat managed preferences. In 10.6 the manifest produces a key XMPPAccountToImport in …iChat.plist, but in 10.5 it produces a key XMPPAccount in …iChat.Managed.plist. iChat works fine on 10.5 of course.

Interestingly enough, neither iChat.app on 10.6 or 10.5 reference their corresponding managed keys (XMPPAccountToImport/XMPPAccount) it seems. It doesn’t look like they call objectForKey: for either of these. From this I could say that either the key gets transformed or, iChat’s binary never attempts to read this key and therefore some other process is responsible for adding the account.

Anyway I’m going to keep tracing through ManagedClient until i find the section where MCX is applied from XMPPAccountToImport.

[mosen]

Thanks again Nate! 😀

[mosen]

Thanks d2s. I didn’t really look into 2011.. having some troubles even getting a base image here 🙂 but thats another story.

[mosen]

Thanks for doing the research on the 2011 installer dead2sin, and pasting up the bash script 🙂

[mosen]

[QUOTE][u]Quote by: akisuan[/u][p]Cheers for the tip, but I was under the impression that the metadata controller handle file locking?[/p][/QUOTE]

I’ve heard that Xsan handles file locking between clients (servers in this case). But AFP doesn’t deal with that… if that makes sense 🙂

[mosen]

Hi there. Not sure if i can be of much help because it’s been a while since i’ve touched on this stuff.

For Office 2008 (Site License) i use the .mpkg supplied by MS with no modification at all.

For Office 2008 Updates, I wrote a small script to remove the file location check which fails with InstaDMG. I patch
my updates and add them into my InstaDMG build.

For iLife i use the supplied package and a choices.xml file to de-select things like garageband that I don’t want.
I haven’t re-packaged iLife to omit the samples, im sorry.

Mostly the office stuff is untouched. Let me know if i’ve totally missed the point or you’re trying to do something different.

mo

[Author]

Posts