Mac OS X Server’s AFP server access logs aren’t the greatest (no full paths is a glaring omission), but if you have them enabled, they can be useful for finding who deleted a file or folder for example.

If the item’s name starts with “Important File”, this command gives us the ip address of the client that deleted the item :
file_server:~ root# grep -i "Delete Important File*" /Library/Logs/AppleFileService/AppleFileServiceAccess.log
IP 10.1.21.6 - - [08/Jul/2008:14:26:14 -0500] “Delete Important File 2009.xls” 0 0 0


Then we pass the ip address into this command to give us the login of the user:
file_server:~ root# grep 10.1.21.6 /Library/Logs/AppleFileService/AppleFileServiceAccess.log | grep Login
IP 10.1.21.6 - - [08/Jul/2008:09:05:43 -0500] “Login mpickens” 0 0 0


Finally we can use dscl to lookup the full name the user:
file_server:~ root# dscl localhost read /Search/Users/mpickens RealName
RealName: Pickens, Mary Ellen


Older logs are available too in zipped form. Use gunzip -c to read the contents.
file_server:~ root# gunzip -c '/Library/Logs/AppleFileService/AppleFileServiceAccess.log 12.11.07.gz' | grep Login | grep mpickens
IP 10.1.21.143 - - [14/Dec/2007:19:12:38 -0500] “Login mpickens” 0 0 0
IP 10.1.21.143 - - [14/Dec/2007:19:24:32 -0500] “Login mpickens” 0 0 0
IP 10.1.21.143 - - [17/Dec/2007:09:21:38 -0500] “Login mpickens” 0 0 0
IP 10.1.21.143 - - [17/Dec/2007:10:37:49 -0500] “Login mpickens” 0 0 0
…


While booted from NetRestore I couldn’t figure out what was launching Terminal.app. Finally found the script that was launching it using an option the ps to show the parent process.

Simple, but useful.

ps auxww -o ppid

It was rc.install.

I’ve been hassling Apple about this issue for quite a while.

Apple has two workarounds for this problem:

1.) Index the macAddress attribute in AD. Even though the macAddress is not part of the Computer class by default, the AD plugin queries on it for joins ( to ensure the the computer that you are adding doesn’t already exist ), and for MCX ( managed client information ). Normally I would frown on any changes to AD since the Enterprise doesn’t like making changes to their infrastructure just to support Macs. However, supposedly in Windows 2008 Server, the macAddress attribute is indexed by default, so at least their is some justification there.

2.) If you’d prefer to make changes on your client machines rather than bother your AD administrators with a Mac-specific fix, remove the ENetAddress mapping from /Library/Preferences/ActiveDirectory.plist. The lines to remove look like this:

<key>1.3.6.1.1.1.1.22</key>
<string>dsAttrTypeStandard:ENetAddress</string>


The key is the OID for the macAddress attribute in AD.
The string value is the mapping to a native Open Directory attribute, which Apple calls ENetAddress.

Update:
You’ll also need to remove /Library/Preferences/DirectoryService/ActiveDirectoryDynamicData.plist as this file also contains the cached mappings.

Then killall -9 DirectoryService or reboot the machine.

I kept getting errors uploading to Google App Engine on Mac.

ERROR appcfg.py:1128 An unexpected error occurred. Aborting.


I run as a normal user. Apparently appcfg.py requires some elevated privileges, as running it as root uploaded without a problem.

Here is the command to run the appcfg.py inside the GoogleAppEngineLauncher app.

sudo /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/appcfg.py update appdirectory/ --noisy -v --email username@gmail.com


Substitute your own appdirectory and username and path to the GoogleAppEngineLauncher.app.

All of the bugs listed here are fixed in 10.5.3.

What isn’t fixed is the slow logins on AD environments with an R2 schema that hasn’t been extended with Mac attributes.

Again, please file bug reports if you are experiencing this issue.

As a Mac sysadmin, I’ve had the need to manipulate the dock on hundreds of systems at a time.

I used to cobble together terrible shell scripts to do the job, but now thanks to plistlib and python, plist manipulation is really easy. I am releasing this utility free under the Apache 2.0 license. Hopefully some other sysadmins will find it useful.

dockutil is a command line utility for managing Mac OS X dock items.
It can add, replace, list, move, find, and delete dock items. It supports Applications, Folders, Stacks, and URLs. It can act on a specific dock plist or every dock plist in a folder of home directories.
It is compatible with Mac OS X Tiger and Leopard.

Download dockutil here.

Here is the usage information:

usage: dockutil -h
usage: dockutil –add (path to item) | (url) [--label (label)] [ folder_options ] [ position_options ] [ plist_location_specification ]
usage: dockutil –remove (dock item label) [ plist_location_specification ]
usage: dockutil –move (dock item label) position_options [ plist_location_specification ]
usage: dockutil –find (dock item label) [ plist_location_specification ]
usage: dockutil –list [ plist_location_specification ]

Contact:
Send bug reports and comments to kcrwfrd at gmail.


AppleScript’s do shell script capability is immensely useful, but if you are sending variable data to do shell script, always validate input and use quoted form of variableName. See the following example:

set dialogResult to (display dialog "Enter a directory name to pass to ls:" default answer ";say boo" buttons {"Cancel", "Quoted Form", "Raw"})

if button returned of dialogResult is “Quoted Form” then
try
set theCommand to “ls ~/” & quoted form of text returned of dialogResult
display dialog “Will execute:” & return & theCommand & return & “Proceed?”
do shell script theCommand
end try
else
try
set theCommand to “ls ~/” & text returned of dialogResult
display dialog “Will execute:” & return & theCommand & return & “Proceed?”
do shell script theCommand
end try
end if

Note you’ll have to fix the quotes to standard double quotes to get this to compile. I couldn’t get wordpress to cooperate.

I recently encountered a command line tool which exposed passwords in the process listing.

The command would also also accept a password as an environment variable. I was concerned with the security of storing a password in an environment variable.

This article at itworld.com does a nice job explaining environment variable scope.

Environment variables are only accessible in the shell in which they are set.

If you export the variable, it is accessible to any subshell of the shell in which it is exported. Simply logging in as another user on the system or even the same user does not allow access to the exported variable.

So, until someone corrects me, I believe that setting and exporting environment variables containing passwords in a script does protect the password from exposure. As soon as the command requiring the password has completed, the variable can be reset to an empty string to prevent any further access to the password.

this class is not key value coding-compliant for the key numbersInput

If you are getting this error after doing the PyObjC averager tutorial called Using PyObjC for Developing Cocoa Applications with Python , import your class in main.py.

After the line:
import PyAveragerAppDelegate

add:
import Averager

This should allow the numbersInput variable to be properly bound to Interface Builder.

I found the solution on macosxhints forum here.

The slow login times in the Leopard AD plugin seem to be related to a search by macAddress.  If you killall -USR1 DirectoryService, and login on a Leopard machine bound to AD, you’ll notice a query on macAddress in the /Library/Logs/DirectoryService/DirectoryService.debug.log. I am not sure the purpose of this query, but our computer objects don’t even use the macAddress attribute, so the query always results in no records found.

I can manually execute the same query and the time almost perfectly matches the delay I see with logins; about 45 seconds.

time ldapsearch -v -w password -x -h domaincontroller.domain.forest.com -D username@domain.forest.com -b "DC=domain,DC=forest,DC=com" "(&(objectCategory=cn=computer,cn=schema,cn=configuration,dc=forest,dc=com)
(macAddress=00:1a:22:ee:31:ac))”

Just substitute your own domain, forest, domain controller, username, password, and mac address etc to test.

I’ve tried manually mapping macAddress to another attribute, but it didn’t make a difference, so I don’t have any workaround to offer. Adding the macAddress attribute to your computer objects in AD might speed things up, but I have not tested this.  I’ve notified Apple of the issue in radar 5752763, which is marked as a Duplicate of 5679705.  If you see this macAddress query taking a long time, please report this to Apple so it can get fixed sooner rather than later.  Actually, this same query is used during the join process, which may explain the long join times while it searches for an existing computer.