Safe Downloads List Info Widget

UPDATE: The AUTOUPDATE code only works as root and so is not useful in the Dashboard environment! This has been removed from the widget.

So I slapped together a widget for the Safe Downloads commands I post at OSXHints:

Safe Downloads Info Widget

Nothing glamorous just the facts and the following code is how it gets it’s values:

defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta LastModification
defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta Version

The auto updates status took a bit more massaging:

eval $(sudo defaults read /private/var/db/launchd.db/com.apple.launchd/overrides com.apple.xprotectupdater | sed 's/ //g')
if [ ${Disabled:=0} -eq 0 ]; then
echo ON
else
echo OFF
fi

All apologies to Dashboard coding perfectionists but the calls for the widget are synchronous, and reading up on Dashboard coding best practices, Apple says a shipping widget should only use asynchronous calls for info… oh well it works well enough for me! :) Perhaps I’ll go back and throw in extra lines of code for asynchronous handlers when I can, if my widget freezes up any other widgets you can simply restart Dashboard by killing to Dock process from Activity Monitor.

Related:
myXprotect Status – a drop down list of threats protected against for the menu bar

Finder’s Nasty Inherited ACL Bug (aka Error -41)

Finder’s Inherited ACL handling is broken

Support for inherited ACLs on folders is still in disarray in 10.6.7 (and has been since 10.6.5), there have been a few reports here and there, some mentioning Error -41, other saying it was AFP, but I’ve whittled it down and it’s a Finder flaw handling inherited ACLs that was introduced in 10.6.3!

Hands On Demo

Let’s create a folder in your home directory using Terminal to make a nice little nested folder set to play with :
mkdir -p ~/ACLShackles/1/2/3/4/5/6/7/8/9/10/11

Now let’s add an entry to the folder’s ACL, in this case  inherited folder and file Read & Write permissions, a common setup for workgroups that share a folder. OS X’s Server Admin sets inheritance by default when adding a user to an ACL, to do this with OS X Client you must use chmod:

chmod +a "$(whoami) allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" ~/ACLShackles/

Make sure the above is all on one line and paste into Terminal.
Now, that the permissions are set double check with: ls -led ~/ACLShackles

Now duplicate folder structure we made called “1” with Command-D, now try and duplicate “1 copy”  — it fails. Finder Error -41.

Looking at the ACL in Terminal isn’t pretty:
ls -leR /Users/brunerj/ACLShackles/1\ copy\ 2

It goes on to 108…

If you don’t like Terminal, I’ve got an Applescript for you: Error41.zip

Just download and, open the resulting Error41.dmg, open and run Error41.scpt to get this result:

Step-by-step illustrated Demo

Let’s try another example and illustrate.

Now, let’s copy in Chess.app, take a look at the permissions with the Inspector (Command-Option-I), notice the Permissions (for this example I added a different user in the ACL to avoid confusion between the Unix permission and the ACL when looking at Finder’s Get Info, it’s the same silhouette):

Looks good, and how it should. Now duplicate Chess.app within this folder with a Command-D:

Uh-oh. Something’s not right. It’s duplicated the original ACE (Access Control Entry) and added one for me the duplicator that seems to mimic my Unix permissions.

Copy the copy.

Much worse. It’s now duplicating my erroneous ACE and the ACE of the test user as well.

Copy the copy.

Oh dear. Fail. Error -41. Checkmate.

Let’s look at that third failed and truncated copy in Finder

Care to see how long an ACL is inside the app?

Yes. 110 ACEs are on “Chess copy 3.app/Contents”!

Comparing other file manager’s behavior

cp doesn’t suffer the same fate as Finder when making copies of copies.

This simulates Finder’s copy of a copy, delete any existing duplicate folders and try this:

cp -Rp 1 1\ copy; cp -Rp 1\ copy 1\ copy\ 2; cp -Rp 1\ copy\ 2 1\ copy\ 3; cp -Rp 1\ copy\ 3 1\ copy\ 4

Take a look inside with ls -leR ~/ACLShackles, nice and clean, one ACE per ACL on each folder the way it should be.

Rixstep’s XFile – doesn’t exhibit this behavior when copying or duplicating either, Rixstep software is quite conscientious about doing the Right Thing™

Path Finder however duplicates ACLs just like Finder, but instead of Error -41 when an ACL gets too long and deep it just hangs instead. What’s interesting is what calls is PathFinder using? They have an SDK but have only taken a cursory look, regardless it’s the same result as Finder.

In conclusion…

For OS X Server environments, this affects crucial workflow behavior where multiple people act upon the same files and folders. ACLs quickly stack up and render Finder unusable. Currently the last known proper behavior for Finder was 10.6.2. Then 10.6.3 and 10.6.4, added the quirk of  adding an ACL entry that mimicked the UNIX permissions of the user doing the copy operation, but at least the ACEs weren’t duplicated ad nauseum. But taking the insanity to new heights was 10.6.5, 10.6.6, and now 10.6.7 with the duplication bug that makes working with inherited permissions unbearable. Luckily for OS X Client, this is minimized since Finder does not enable Inheritance for files or folders, but then you lose out on what inherited ACLs could do for you and your workgroup!

Since 10.6.7 is out now, 10.6.8 might be your last chance to have Snow Leopard’s Finder ACL behavior put back in working order. Let Apple know this is important to you, file a bug report at Apple’s Bug Reporter site, you can reference my bug number: 9160099 (you can view it at OpenRadar )

P.S. If you are wondering why I didn’t file this earlier since I am so detailed in the earlier 10.6 behavior? I actually became aware of something wrong in 10.6.5 but I also wasn’t sure what the cause was, Client, Server, AFP, Active Direcroty? Our UIDs are 10 digits long! During that time I hoped the soon to be released 10.6.6 would fix it, but when it didn’t I spent a lot of time just trying to fix it and clean the ACLs, it wasn’t until last week during the final seed of 10.6.7 that I found time to set up a new server and incrementally test 10.6, 10.6.2, 10.6.3, 10.6.4, 10.6.5, 10.6.6, and 10.6.7, recording QT Screen captures for each one and that took some time! My bug report only got in this Sunday. Oh well better late than never! :/

Remedies

It’s easy to nuke all the ACLs in a given folder, but then you’ll probably want them set back up again to be of any use! Anyway this will recursively wipe the ACLs from everything in the folder you’re in, be careful, you could wipe your own access! So it’s best for the server admin to to run from the server itself, then re-propagate the ACLs for the Share (actually you may not be able to delete ACLs from client anyway):

chmod -RN *

Update (3/23/11):

So I left my ACLShackles folder in my home foder and Time Machine failed to backup (backupd error -41, surprise.) so to avoid that, delete ACLShackles and/or turn off Time Machine while you play around with this…

Update (Sep 2011):
Just posting my comment down at the bottom so you don’t have to scroll all the way down there to read it…

10.6.8 has addressed it for the most part. You’ll still get weirdness when duplicating folders with inherited folders inside a folder with inherited permissions, but it’s a linear rather than geometric and that’s bearable.

More App Store tips for admins

Continuing the tech ramble about how to keep the App Store from your users…

So, I figured out the two ways the App Store icon is added to the dock:

1. Existing users on an upgraded system are affected by this file: /Library/Preferences/com.apple.dockfixup

Looking at the add-app key inside contains the answer:

<key>add-app</key>
<array>
<dict>
<key>path</key>
<string>/Applications/App Store.app</string>
<key>after</key>
<string>begin</string>
</dict>
</array>

We can rid ourselves of  this behavior with defaults:

defaults delete /Library/Preferences/com.apple.dockfixup add-app

However, if you try to use a loginhook to remove the icon, it will not take effect unitl the second login, sine the loginhook runs before Apple’s dockfixup is applied.

The solution to a user never seeing it (and avoiding calls about it) is to use a daemon that runs at system startup and deletes the entry in the plist before it is ever used.

Save as /Library/LaunchDaemon/com.brunerd.dockfixer.plist (or whatever you wish):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.sts.dockfixup</string>
<key>ProgramArguments</key>
<array>
<string>defaults</string>
<string>delete</string>
<string>/Library/Preferences/com.apple.dockfixup</string>
<string>add-app</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>

You could call another script, check for add-app’s presence, but having this run everytime, insures that despite OS updates and reversions of files your user will never have App Store added to their Docks.

2. Suppressing App Store in new user accounts is affected by Dock.app’s default.plist:
/System/Library/CoreServices/Dock.app/Contents/Resources/English.lproj/default.plist

But just deleting this and not com.apple.fixup.plist will not do what you want since fixup will still run, you must delete both. Altering that is the perfect job for removeitemfromdock… if only it worked with a supplied path… now it does! So after installing and downloading you can run this command to alter the default dock:

sudo /sbin/removeitemfromdock -f /System/Library/CoreServices/Dock.app/Contents/Resources/English.lproj/default.plist /Applications/App\ Store.app/

You could make this another Daemon or just have the daemon call an external script, your choice, I can’t do all the work for you :)

App Store tips and tricks for sysadmins

App Store Tips, Tricks, and Hacks for the SysAdmin

App Store, oh, App Store, like all Apple products you are made first for consumers and in time maybe you will be ready for corporate deployment, but for now, here’s some tips for the Mac IT worker needs to wrangle this beast.

Firstly, the App Store, if you’ve noticed, requires admin rights to download and install apps. Not just because it installs to /Applications (it could be ~/Applications if it wanted to…) But most likely due to the new location of the receipts folder in /var/db/receipts. Up until version 10.6 it was /Library/Receipts and this would have made it possible to use the domain system that was the simple genius of OS X, where things can live in /System/Library, /Library, or ~/Library and when the system couldn’t find a pref or support file in one domain it would look in the next. Fonts are a great example of this in action, why didn’t they think it was a good idea for receipts is anyone’s guess. But since there is no way to make an analogous folder structure of /var/db/receipts in a user’s home folder, much less have the system recognize there are receipts there, the App store is not “Standard User” compatible.

Disabling Execution and hiding the App Store with Unix Permissions:

#hide it
sudo chflags hidden /Applications/App\ Store.app/

#keep it from executing for anyone other than root (since it is ownership is root:wheel)
sudo chmod o-x /Applications/App\ Store.app/Contents/MacOS/App\ Store

#to let admin users execute, next change group ownership of executable
sudo chgrp admin /Applications/App\ Store.app/Contents/MacOS/App\ Store

#OR keep anyone from executing it
sudo chmod ugo-x /Applications/App\ Store.app/Contents/MacOS/App\ Store

Keeping the icon from populating the Dock is more troublesome, since Apple has changed this from 10.5, previous versions, it was a matter of altering /System/Library/User\ Template/English.lproj/Library/Preferences/com.apple.dock.plist but this no longer exists. I am searching for where this information is pulled… but in the meantime you could use a utility like RemoveItemFromDock to run for a user when they log in (note: a new user will not have a com.apple.dock.plist file until their first login, this makes it tricky for login scripts on first login…) I had a good lead in /Library/Preferences/com.apple.dockfixup.plist but removing the add-app entry that contains the path to the App Store did not help… wah wah.

Well, so you hidden the App Store, restricted it running, but what can your sneaky users do?

They can buy an App Store app on their home computer and then simply copy it to their work laptop. The app will prompt them to authorize it with their AppleID, boom, done, no problem for a Standard User. However, they will not get updates on the computer, since there is no receipt of its installation, this would need to be done manually. User bringing in paid apps to a work computer creates a quandary for admins who run app inventory on computers (especially if it’s for license compliance)! From my attempts at pruning and tinkering with the Parental controls MCX values in the user’s records there didn’t  seem to be a way to wildcard the white or blacklist, however it is promising that there is a boolean key call appStore that shows up. But for now enabling “Limit Applications” setting involves explicit approval for EVERY app they want to run that’s not on the whitelist, and personally I don’t care if you want to run Primate Plunge to waste time during conference calls – you and I will probably be saner for it. :)

Bottomline MCX doesn’t seem to have a straightforward way to deal with this now that doesn’t involve more admin overhead using Parental Controls.

Perhaps though, you don’t care what your user intalls from the App Store but you care enough that they are still Standard Users, well here’s the hack and slash way to enable them to use the app store…

How to Allow Standard Users to Run the App Store*

*Disclaimer: !!!WARNING!!! Security settings are changed with this action!!!! HACK AT YOUR OWN RISK !!!!!

#Make the App store an SUID binary so it runs as root *

sudo chmod +s /Applications/App\ Store.app/Contents/MacOS/App\ Store

#Change rights in /etc/authorization to allow system.privilege.setugid_appkit right by anyone* **

sudo cp /etc/authorization /etc/authorization.saved
sudo cp /etc/authorization /etc/authorization.plist
sudo defaults write /etc/authorization rights -dict-add system.privilege.setugid_appkit '<dict><key>rule</key><string>allow</string></dict>'
sudo plutil -convert xml1 /etc/authorization.plist
sudo sudo chmod go+r /etc/authorization.plist
sudo mv /etc/authorization.plist /etc/authorization

There you go, your standard users can now install App Store apps.

*Disclaimer: !!!WARNING!!! Security settings are changed with this action!!!! HACK AT YOUR OWN RISK !!!!!

** When you Google this, you’ll find this is the same solution I found for using Flip4Mac with Compressor as a standard user. I just love reusable code ;)

I hope you learned something and even better I hope you might have some insight to add that I’ve missed, please send in your comments, thanks!

Putting it all back the way it was before we started messing around

sudo chmod u=rwx,go=rx /Applications/App\ Store.app/Contents/MacOS/App\ Store
sudo chown root:wheel  /Applications/App\ Store.app/Contents/MacOS/App\ Store
sudo chflags nohidden /Applications/App\ Store.app/
mv /etc/authorization.saved /etc/authorization

Update: My removeitemfromdock script seems to have been thrown by a loop by changes to the dock plist, just like I had to work around Dashboard when it was itroduced to the Dock in a new way. Update to come…

Update-2: removeitemfromdock now works like a charm, my Dashboard hack was taking for granted that Dashboard is not always at position 0 after the Finder, so when App Store snuck in behind, it was getting skipped, now there are some robust kludges to deal with Dashboard’s non standard dock entry

Tearing apart OpinionSpy

Updated: I’ve linked text files of string dumps to the binaries thoughout the article, I suppose not everyone wants to install and run the code to find out themselves! :D

Another OS X malware media darling is out there, but it’s not the DNS changing kind that RSPlug-F was. Rather this one has a lot more code in it, active code that is watching keystrokes, monitoring AIM, MSN, Yahoo, and iChat messengers and more.

So I found a sample (this is the actual installer careful, folks) in the MishInc FLV To MP3 converter. Which is just a .jar file, put .zip at the end and you can see the guts when expanded. However, it’s a self extracting installer using iZPack so it’s easier just to run it and let it unpack. Here’s some screenshots:

Nothing much in there

Jackpot on the 2nd screen, here’s the goods. Note, if you click I disagree, the software is not installed! Not too mal. Here’s the text from VoiceFive‘s agreement:

In order to provide this free download of MiMAC FLV To Mp3 Converter, PremierOpinion software, provided by VoiceFive, Inc., is included in this download. This software allows millions of participants in an online market research community to voice their opinions by allowing their online browsing and purchasing behavior to be monitored, collected, and once anonymized, used to create market reports, materials and other forms of analysis that may be shared with our clients to help our clients understand Internet trends and patterns and other market research purposes. The information which is monitored and collected includes internet usage information, basic demographic information, certain hardware, software, computer configuration and application usage information about the computer on which you install PremierOpinion.

We may use the information that we monitor, such as name and address, to better understand your household demographics; for example, we may combine the information that you provide us with additional information from consumer data brokers and other data sources in accordance with our privacy policy. We make commercially viable efforts to automatically filter confidential personally identifiable information and to purge our databases of such information about our panelists when inadvertently collected.

By clicking I Agree, you acknowledge that you are 18 years of age or older, an authorized user of this computer, and that you have read, agreed to, and have obtained the consent to the terms and conditions of the Privacy Statement and User License Agreement from anyone who will be using the computer on which you install this application.

Does anyone else find it odd that they say your info is anonymized, but then go on to use an example of information they monitor is name and address?! But not worry, commercially viable efforts will be used to filter that out. Does that mean if it’s too expensive they won’t bother doing a really good job? Nonetheless for this installer, if you say I Disagree you are able to continue to install the MP3 converter without PremierOpinion installing.

But let’s say: I agree for the heck of it :)

First it drops two files in /private/tmp: script.sh which simply makes the other file, poinstaller, executable. If you are connected to the internet it then downloads two folders: installtmp and tapinstaller, both folders have the exact same binary called PremierOpinion(496KB), installtmp has a different sized poinstaller binary and tapinstaller contains upgrade.xml, which contains a link to a file called rule14.xml, found on a server at post.securestudies.com. Downloading rule14.xml from them you get a link to the latest PremierOpinion.zip and the version numbers of the expected support libraries and essential files.

pointsaller has some Applescript to open the survey window in Safari and things like getting “campaign ids”, doing shell scripts with admin privileges, references to MacSniffer (a TCP packet sniffer), and more. Also while looking at the strings of poinstaller you’ll find reference not only to post.securestudies.com found but also it.kingroutecn.com which has the same rule14.xml but instead of PremierOpinion you get PermissionResearch. Doing some digging, it can be discovered that VoiceFive, Permission Research (which has many screensavers to download), and Premier Opinion are all in the same network block as ComScore, a multi-headed hydra of consumer buying insight.

Now back to the Chinese server (which is not used to download the payload, perhaps, only in China?) digging it.kingroutecn.com gives you 218.108.8.85, doing a reverse lookup gives  hidden-master.hzman.net, doing a reverse lookup gives you 127.0.0.1 that is you!? Whois on it.kingroutecn.com and hidden-master.hzman.net will point to Hangzhou, China, a very big city just southwest of Shanghai (it looks smoggy in Google Maps). The question is why are their two similar packages being served from the US and China? And why is the Chinese version newer (2.3.0.69 vs. 2.2.0.59)?

Anyway, Woodward and Bernstein aside, during all this unpacking of files in /private/tmp an authentication window asking for system.privelege.admin, that is to say, it wants root privileges. If you say yes, you’ll get a launchd daemon running as root installed to /Library/LaunchDaemons/PremierOpinion.plist, it’s an on-demand daemon that will respawn the PremierOpinion process if you try killing it in Activity Monitor. Respawning calls the RunPremierOpinion.sh script from /Application/PremierOpinion folder, it checks to see if you have Access for Assistive Devices enabled this is essential to logging your keystrokes. It does this by simply touching /private/var/db/.AccessibilityAPIEnabled, which can only be done by root, but it’s already running as that no prob! What’s weird about this file is that when you turn on Access for Assistive Devices via the GUI in System Preferences it creates the file with the single character ‘a’ but OS X will still activate the service if the file is created  and is 0 bytes. After installing a Safari window will pop up asking you who uses the computer, the ages of the folks using it, and other tidbits, you can see here. When this app upgrades itself you will find a folder at /private/tmp/autoupgrade which has the same contents of /Applications/PremierOpinion.

So /Applications/PremierOpinion has quite a few things inside, libraries, scripts, and an Uninstaller (?!), and PremierOpinion.app. Inside the app is some Code Signing, the binary (a much bigger 3.6MB version), and in Resources it contains survey.nib, systemtray.nib and InjectCode.app, which inside has code from Jonathan Rentzsch used for mach code injection*, taken from Growl’s 1.2 source code and recompiled by user huangxianghua as seen in the string: /Volumes/10.5/Users/huangxianghua/Downloads/Growl-1.2-src/external_dependencies/mach_star/mach_inject_bundle/mach_inject_bundle

Further and further down the rabbit hole, but let’s just run the Uninstaller. It deletes the folder in Applications but the process remains as well as the LaunchDaemon and all the files in /private/tmp, however on reboot the process is indeed not running, /private/tmp is cleaned out, but the LaunchDaemon and Assistive Access remains on.

So here’s an uninstall script of my own (disconnect all network conections first, in case it is logging keystrokes, it might grab your password):

sudo launchctl unload -w /Library/LaunchDaemons/PremierOpinion.plist
sudo rm /private/tmp/poinstaller
sudo rm /private/tmp/script.sh
sudo rm -rf /private/tmp/installtmp
sudo rm -rf /private/tmp/autoupgrade
sudo rm -rf /private/tmp/tapinstaller
sudo rm -rf /Applications/PremierOpinion
sudo rm /private/var/db/.AccessibilityAPIEnabled

That should do it.

For extra insight, try running the PremierOpinion or PermissionResearch binary from the command line as root, there is all sorts of info to be found when it writes to stdout, such as when it starts a service port 8254: 2010-06-03 15:59:06.175 PermissionResearch[1658:60f] Starting server on port 8254 and, surf around a little, it’ll  report on the YouTube videos you are watching and other things it deems interesting.

Extra extra credit run a Sample on it from Activity monitor and see what it’s doing: FileInventoryTask::MainTask(void*), file inventory eh, that’s why it’s eating up 30% of my CPU!

Hmmm, enough rabbit hole adventures for today, comments are welcome.

Oh yes, and  PowerPC  folks don’t worry, they didn’t compile for PPC :)

*Update:

To go on further about the injection aka Method swizzling code. This is where you have your code respond to a message call instead of the original code, the power in this is that you can get in the middle of the internal calls and do what you will with their data but then pass them on to the original method. So they probably are swizzling methods in Safari or perhaps at the network layer so they can see what you are downloading, watching, etc. Combined with packet sniffer ‘all your data are belong to them’. However please take note that these the reason this app can do this is because you’ve given them the keys to the castle by authenticating it as root, the technologies it’s leveraging aren’t inherently nefarious, rather fundamental and and essential to system operation, if root can’t do it then who can? This is where either it falls on the user or the OS needs to be better about protecting the user from themselves, perhaps the OS could sandbox downloaded apps with very restrictive settings, alerting you when it attempts something privileged, although this can desensitize a user quickly to clicking Agree. Nonetheless this is a defining conundrum of this century. The power of personal computers is being subverted for the nefarious gain of others and we need to defend against it, the era of curated computing might be ushered in because of this. We’ve seen it so many times, when good things get used for bad purposes, there’s a sea change. Crises precipitates change.

Make Acrobat Pro 9 for Mac shut the hell up!

So, if you deploy Acrobat Pro to a corporate environment you already know what an aggravating experience it is to try and deploy updates to Adobe products. Silent install? Sure. Silent Update? No. Standard Mac .pkg? No.

So you figure out all the files with loggen, Tracker, fseventer, or whatever your tool, then build your own package with Iceberg. Great. Then you find your “standard” users without admin privileges are getting bothered by Adobe’s SelfHeal BS.

Few things going on here that I’ll try and explain, the code formatting should be copy paste-able check it in a text editor, but all line breaks should be preserved.

Make sure you copy in the new Acrobat Internet-Plugin if the user is using that:
if [ -d "/Library/Internet Plug-Ins/AdobePDFViewer.plugin" ]; then
rm -rf "/Library/Internet Plug-Ins/AdobePDFViewer.plugin";
cp -R "/Applications/Adobe Acrobat 9 Pro/Adobe Acrobat Pro.app/Contents/MacOS/SelfHealFiles/Library/Internet Plug-Ins/AdobePDFViewer.plugin" "/Library/Internet Plug-Ins/";
fi

These next keys really make it complain if it can’t find them, and yes even if you don’t use the plugin it looks for WebBrowserUsePath, so make sure it’s there, and NoViewerSelfHealNeeded gets a new date put after it for every release! Wow neato, a fun easter egg hunt, thanks Adobe!
defaults write /Library/Preferences/com.adobe.acrobat.90.sh "NoViewerSelfHealNeeded Dec 21 2009" -bool TRUE
defaults write /Library/Preferences/com.adobe.acrobat.pdfviewer WebBrowserUsePath -string "file://localhost/Applications/Adobe%20Acrobat%209%20Pro/Adobe%20Acrobat%20Pro.app/"
defaults write /Library/Preferences/com.adobe.acrobat.pdfviewer AdobePDFDriver -string "file://localhost/Applications/Adobe%20Acrobat%209%20Pro/Adobe%20Acrobat%20Pro.app/"

Now is the truly ridiculous part: if those files and keys aren’t found Acrobat ask for an administrator password and then proceed to write them in current users ~/Library/Preferences! What your users don’t know is they can click Cancel a couple times and it will still write them out, but your they’ve already called you to remote in and authenticate them – you lose! Why Adobe?! WHY!?! Asking for an admin password when you’ll just write it to ~/Library/Preferences?

PDF Printer – Here’s the files you need:
/Library/Printers/PPDs/Contents/Resources/en.lproj/ADPDF9.PPD
/Library/Printers/PPD Plugins/AdobePDFPDE900.plugin
/usr/libexec/cups/backend/pdf900

They are all found in:/Applications/Adobe Acrobat 9 Pro/Adobe Acrobat Pro.app/Contents/MacOS/SelfHealFiles/AdobePDFPrinter/

After you’ve copied them to their places, you can run Adobe install script:
/Applications/Adobe\ Acrobat\ 9\ Pro/Adobe\ Acrobat\ Pro.app/Contents/MacOS/SelfHealFiles/AdobePDFPrinter/cupshup.pl

I also figured this out in lpadmin too:
lpadmin -p AdobePDF9 -E -P /Library/Printers/PPDs/Contents/Resources/en.lproj/ADPDF9.PPD -v pdf900://distiller/ -D "Adobe PDF 9.0"

Even if you’ve copied in the PPD, the PDE plugin, the cups backend, and setup the printer, it’ll still think its damaged because you don’t have the PPD in Korean, Japanese, and two type of Chinese! So, must use PlistBuddy to correct this (because defaults is tricky to use when a dictionary is nested in an array – WHY Adobe?!)

Quiet the printer “repair”:
/usr/libexec/PlistBuddy -c "set :0:IsInstalledKey NO" /Library/Application\ Support/Adobe/Acrobat/SHExpectedMissingFileTypes.plist
For Tiger users the path is: /Library/Receipts/iTunesX.pkg/Contents/Resources/PlistBuddy

It’s almost shut the hell up, but the Adobe Updater might decide to pop-up and urge your user to call you up to run updates, so shut it up you got to jump through some hoops, its an “XML” file Adobe style so defaults won’t work on it, nor will plistbuddy, that and it’s a per user setting, so they must run it once to make the file, then you can change it:
cat ~/Library/Application\ Support/Adobe/Updater6/AdobeUpdaterPrefs.dat | sed 's/1\<\/AutoCheck\>/0\<\/AutoCheck\>/' > ~/Library/Application\ Support/Adobe/Updater6/AdobeUpdaterPrefs.new; mv ~/Library/Application\ Support/Adobe/Updater6/AdobeUpdaterPrefs.new ~/Library/Application\ Support/Adobe/Updater6/AdobeUpdaterPrefs.dat

Yes, Adobe has a document for this but it seems only to remove the ability to check for updates within the app?!

Trivia: You might want to copy in the new AcroEFGPro90SelfHeal.xml file, although running “repair” from Acrobat will copy in the new file and for some odd Adobe reason, the self heal inside the app uses Mac line endings but when magically moved to /Library/Application Support/, it has Unix line endings changing the size by 2282 bytes (and also the place of a key as well?). This was a read herring in my research.
cp -f /Applications/Adobe\ Acrobat\ 9\ Pro/Adobe\ Acrobat\ Pro.app/Contents/MacOS/AcroEFGPro90SelfHeal.xml /Library/Application\ Support/Adobe/Acrobat/AcroEFGPro90SelfHeal.xml

Adobe: CS5 had better not use InstallerVISE, iNosso, bindiff, Java, XML, or whatever convoluted processes you are clinging to, just use the dang pkg format that Apple has provided – sheesh. Is this overwrought complex system supporting “make-work” jobs for programmers?

iTunes 9.0.3 Zoom and mini Player

Why is iTunes messing with my shortcuts again?

So here’s the deal: since iTunes version who-the-hell-knows it’d go to the mini player when you press Command-Option-Z, then iTunes 9 changed it all and made it fill the screen. iTunes 9.0.1 restored the Zoom functionality, then 9.0.3 took it away. So…

Now for mini Player you have to do a Command-Shift-M
I can’t do that with my left hand alone! That’s how I used to work!
Right hand on the mouse, left hand by the keyboard.
Now it’s two handed operation. Boo.

Update:
It might be possible with a modified “I love you” hand sign to accomplish this, which is ironic since I don’t like this key combo at all!

Snow Leopard AD Binding misnomer

The misnomer being “Server Address”, it should really be “Domain Name”.
When you point to a specific domain controller, it will fail.

This is because it looks for SRV records in DNS that are only available at the domain level.
So trying dc01.meco.com it will look for _ldap._tcp.dc01.pretendco.com and not find it.

However a lookup of _ldap._tcp.pretendco.com if set up properly will work.
dig -t SRV _ldap._tcp.pretendco.com

The misleading label of “Server Address” is the culprit.
It should read Domain Name.

Hope that helps some people…
(Now I just need to get the AD admin at my work to get the _gc._tcp SRV record published!)

10.6_binding

bash architecture mismatch in Tiger intel builds

Tiger, I know, ancient history…
Well, I’ve stumbled on an old oddity with bash on intel builds of Tiger:
Bash thinks its running on a PPC machine!?
At least the environment variables think so…
$ arch
i386
$ echo $HOSTTYPE
powerpc
$echo $MACHTYPE
powerpc-apple-darwin8.0

This might only affect those who are using Fink or building your apps, or those who like things to be right.

Append these lines to /etc/profile, using sudo nano /etc/profile
HOSTTYPE=i386
MACHTYPE=i386-apple-darwin8.0
export HOSTTYPE
export MACHTYPE

Now the one thing this won’t do is affect the 5th element of the BASH_VERSINFO array, it seems to be readonly… so if you are very adventurous you can go into /bin/bash with a Hex Editor and overwrite the first two ‘powerpc’ references with i386 (the second set of powerpc refs are correct that is the ppc portion of the fat binary), don’t move the start of of string, just pad the end with zeros (NULL) and it will affect this variable as well.

Alright, now it’s in “The Google”

Create a standard .pkg for Acrobat Reader

It’s time to patch Acrobat Reader again! And leave it to Adobe to use a patcher app (or Installer Vise, or a downloader, or a some crazy Javascript/XML/AIR based installer) to make things hard for mass deployment to be achieved (and no I don’t think the Deployment Kit for CS4 makes much sense!).

Perhaps soon they’ll have a full version of Reader available for download in a seemingly standard .pkg file, but don’t be fooled! If you admin Macs like I do you might have noticed it uses the iNosso plugin to uncompress it’s payload and it is totally incompatible with ARD’s Install Package. It just fails.

But fear not, I am a big fan of Iceberg and it’s ability to make the painstaking process of installing Adobe apps so much easier. And I want to share the love. So here take this.

I put a small how-to in the zip file with a sparse set of instructions and caveats. Basically you install Acrobat Reader in the normal way, install Iceberg, open the iceberg project, and build. You’ll then have a pkg that ARD can push out.

If you have questions — Google it! ;)
(OK you can leave a comment, but for gawd’s sake not “How do I use this?” — seriously!)