Felipe Alfaro Solana

In Mac OS X Tiger, the Login Window will now show most users, even if the UID is below 500, unless the account is UID 0 (root) or user whose default shell is set to /dev/null.

Tiger’s login window preferences now supports a new setting called HiddenUsersList, which is an array of one or more user’s short account name. To hide a list of accounts from the Login Window, run the following command:

# defaults write /Library/Preferences/com.apple.loginwindow \
  HiddenUsersList -array-add account1 account2 account3 ...

where account1, account2, account3, … are the short user names for the accounts you want to hide. This would add additional names to any that might already exist.

To unhide all the names you may have previously hidden, run:

# defaults delete /Library/Preferences/com.apple.loginwindow \
  HiddenUsersList

As always, make a backup of any preference file you might change so you can move back to it.

I found the following link in macosxhints describing how to disable (or enable) Dashboard in Mac OS X Tiger.

Launch Terminal and then enter the following commands…

To turn Dashboard off:

defaults write com.apple.dashboard mcx-disabled -boolean YES

To turn Dashboard on:

defaults write com.apple.dashboard mcx-disabled -boolean NO

You have to restart the Dock after making either change for it to take effect:

killall Dock

I personally don’t want Bonjour (Zeroconf, mDNSResponder, Rendezvous) running all the time, because I rarely use it and because it gives away information such as your username, what services you’re running, computer name and more, depending on what you’re running. From a security perspective, you’re making it easy for an attacker to enumerate services and usernames without even having to do active scanning a lot of the time.

In order to permanently disabled the mDNSResponder daemon, run the following command:

launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

This will unload the daemon from memory and will modify the .plist file so the service will be permanently disabled and won’t be loaded during next startup. In fact, the previous command adds the lines highlighted in bold to the “/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist” file:

cat /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Disabled</key>
<true/>
<key>Label</key>
<string>com.apple.mDNSResponder</string>
<key>OnDemand</key>
<false/>
<key>ProgramArguments</key>
<array>
<string>/usr/sbin/mDNSResponder</string>
<string>-launchdaemon</string>
</array>
<key>ServiceIPC</key>
<false/>
</dict>
</plist>

To reenable the service, simply issue:

launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

which will, in turn, remove the previously highlighted lines in bold from the “.plist” file.

NOTE: Disabling Bonjour breaks iTunes support for remote speakers.

This KnowledgeBase article explains how to prevent OS X from creating new .DS_Store files when opening folders on remote volumes mounted using SMB/CIFS, AFP, NFS, and WebDAV. The creation of .DS_Store files (and more so, ._AppleDouble files which are not covered in this hint) is frequently the source of complaints against Mac users, who often leave a trail of these files scattered throughout the filesystem when “visiting” a Windows computer. Even with this hint in place, the .DS_Store files will continue to be created on local volumes (which is a good thing).

To prevent the creation of these files, open the Terminal and type:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

It may be necessary to log out and back in, or even to restart the computer (which is what the article states), for the change to take effect.

Note: Most of the settings controlled by data in .DS_Store files are “cosmetic” in nature — for example, Finder window position, view style, icon position, etc. However, .DS_Store files in OS X also store Finder “comments” so in this sense, disabling .DS_Store files may result in loss of data.

Changing the background of the login window has never been so easy.

Look in folder “/Library/Desktop Pictures” for an item named “Aqua Blue.jpg”. This is the resource Mac OS X uses for the login background screen. By editing, or replacing this file, one can easily change the looking of the login window. However, it’s recommended to keep a copy of the old “Aqua Blue.jpg” in case one’s mind changes later.

Login in Mac OS X could stall when nameservers don’t respond to queries or do it slowly. This can happen during network outages, for example.

I discovered this today, with Mac OS X 10.3.9, while trying to log in. It took forever: the Dock started up, but finder would hang. Accidentally, I found that turning off all network interfaces (like AirPort), solved the problem, Further investigations revealed that my ADSL router had stopped forwarding packets and thus, it was impossible to reach any nameserver.

After a reboot, everything started working properly. However, I was intrigued about the reasons of the stalls during log in. By using “tcpdump” to capture traffic, I discover that my PowerBook was sending out some spureous queries against my ISP’s DNS nameserver:

16:05:33.975493 IP 192.168.0.xx.49152 > 195.235.113.3.domain: 30686+ PTR? 91.0.168.192.in-addr.arpa. (43)
16:05:34.034175 IP 195.235.113.3.domain > 192.168.0.xx.49152: 30686 NXDomain 0/1/0 (120)

192.168.0.xx is the IPv4 address assigned to my AirPort Express NIC, while 195.235.113.3 is my ISP DNS IPv4 address.

Why my system is sending out this PTR query is still a mistery to me and I haven’t been able to block it. It turns out that some component of Mac OS X is also sending out IPv4 (A) and IPv6 (AAAA) queries for “idisk.mac.com”. These can be easily blocked by adding the following entries to “/etc/hosts”:

# Mac OS X queries for these entries during log in,
# which can cause stalls if there is no Internet
# connectivity.
17.250.248.77 idisk.mac.com
::1 idisk.mac.com

Now, login is a little bit faster, but I guess it will hang the next time my router stops working properly.

If you use bash as your shell and use filename completion a lot, you can get bash to ignore the case of filenames just like HFS does.

Just put this in your ~/.inputrc file:

set completion-ignore-case on

Then, when you type ls /appli in the shell and force filename completion, you’ll get ls /Applications like you ought to.