Using Apple Remote Desktop, send the following UNIX Command to as many machines as you like to add an app to the dock. I suggest sending the command as the user whose dock you are modifying while that user is not logged in. Please note that the path to that app must be identical on every machine to which you send the command.
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 (mainly bad if you leave it like "Bob Dole's Computer"), 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. Not only that, but I know many system admins who don't like "chatty" machines, which Macs can be if this is left on.
However, Apple has never given a good way to disable this until desired. In 10.3, I had to move the mDNSResponder StartupItem, and in 10.4, it's a similar situation. You can disable it once by running (shown on two lines, but should be pastable):
However, Bonjour will then relaunch on next startup. According to launchctl's man page, I should be able to put that command (or something like it) in ~/.launchd.conf or /etc/launchd to tell it not to load mDNSResponder when it starts up. However, I tried various combinations of that (with sudo and without, and with the launchctl command and without), and it didn't seem to work.
In the interim, I found that you can either rename /usr/bin/mDNSResponder to .back or whatever, or move the .plist I listed above -- when I renamed it .back, it still launched, so I ended up just moving it up one directory, so it can be easily put back. If anyone finds out the official launchd way of stoppping this from loading at startup, I would be interested in hearing it. In the meantime, it can still be temporarily re-enabled by just using this command:
The changes induced with Tiger seem to be causing great pain to many in regards to sshd and changing the default port. A hint is already on file for doing this in 10.3, which even so, seems to have caused a bit of a stir. To note -- I'm not endorsing security through obscurity, but this is still a useful exercise and one that can reduce the number of people probing the standard ssh port.
In 10.4, the mechanism for launching sshd changed from using xinetd to launchd. This dramatically changed how sshd is launched, what ports are listened to, etc. Logically, you would think you could just edit /etc/sshd_config and be done with it. Sorry, but it's not that easy. sshd_config is read on launch of sshd, but launchd launches sshd when the appropriate port is "tickled." Here's the deal. launchd has an "on-demand" mode, where services that need to be launched upon being "tickled" on a particular port are launched. In /System/Library/LaunchDaemons is a file called ssh.plist which defines the on-demand configuration for sshd.
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:
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.
[robg adds: In my previous day-job, I know a feature like this would have been highly welcomed by our sys admins. I used some of the previous hints here to try to erase my trails, but this is a much nicer solution!]
Using Apple Remote Desktop, send the following UNIX Command to as many machines as you like to log them in. I suggest sending the command as the user you are logging in as. Note that this will only work if the machine is currently at the login screen.
osascript -e 'tell application "System Events" to keystroke "LOGIN_NAME"'; \
osascript -e 'tell application "System Events" to keystroke tab'; \
osascript -e 'tell application "System Events" to delay 0.5'; \
osascript -e 'tell application "System Events" to keystroke "PASSWORDHERE"'; \
osascript -e 'tell application "System Events" to delay 0.5'; \
osascript -e 'tell application "System Events" to keystroke return'
Replace LOGIN_NAME and PASSWORD with the proper values, of course...
[robg adds: I broke the above command by adding backslashes to split the lines; it should work when copied and pasted, but ... I haven't tested this one, lacking both Apple Remote Desktop and more than one machine here in the temporary Boston HQ of macosxhints...]
My setup is pretty simple: iBook with Airport Extreme, which connects to an Airport Express, which in turns connects to a router, cable modem, and then out to the internet. Now, the signal with iStumbler is around 40 and noise is 10. Most of the time, I get a seamless connection to the internet and the rest of the network, but on occasion, I have these awful spates where I'm reconnecting to the Airport Express every five minutes. It makes the internet almost totally unusable and, as a smaller annoyance, it fills up my system logs with rubbish.
After shoveling through plenty of hints and being thwarted each time by my system, I learned it wasn't related to my DNS, routing, internet connection, network connection or the phase of the moon. So I felt risky. I disabled 'Use Interference Robustness' in my Airport menu item. And hey, guess what? I'm flying on the internet again...
The Bonjour Preference Pane provides a user interface for using the wide-area aspects of Bonjour. The customer releases of Mac OS X Tiger and Bonjour for Windows include full wide-area Bonjour functionality for developers to utilize in their applications, but no user interface. The Bonjour Preference Pane allows you to set system-wide defaults that will cause standard unmodified Bonjour applications to browse for and/or register network services in wide-area Bonjour domains, rather than only on the local link.
I haven't had a chance to test this yet because I need to configure dynamic DNS on my server. I hope that the Wide-Area Bonjour includes service discovery, because then I won't have to jump through so many hoops to keep all of my macs on the same local link. Be sure to also check out Setting up a Bonjour Name Server for a description on setting up a server to support wide-area Bonjour.
[robg adds: I haven't tested this one either, but it seems quite cool. Note that you will not be able to browse iTunes shares nor use iChat's Bonjour chats in wide-area mode.]
There's an easier way to access your Mac via SMB than with its IP address. Mac OS X broadcasts the first 15 characters of your hostname via NetBIOS. For instance, my hostname is "Ryan-Govostes-iMac," so to access it by SMB, I would connect to \\Ryan-Govostes-i\.
You can also have the Terminal print out your NetBIOS name by executing grep "netbios" /private/etc/smb.conf. Your hostname can also be changed in the Sharing preference pane. The more adventurous could edit the smb.conf file and broadcast a different name.
Want to see all the Bonjour servcies running on your network? Use iStumbler'sBonjour plug-in, which lets you browse all the computers advertising Bonjour services, see the details of those services, and connect to services which have a related helper application.
There's a lot of conflicting information about how to set networking information (such as DNS resolution configuration) from the terminal. In the course of setting up a VPN package (openvpn) on OS X, I had to set the DNS resolution configuration dynamically from a shell script.
As of (at least) 10.3, /etc/resolv.conf (or /var/run/resolv.conf) is NOT the place to do this. Re-writing /etc/resolv.conf resulted in a system where a DNS lookup with host would work, but dig and ping would not. Sometimes /etc/resolv.conf would be magically restored to its original configuration. I thought the smarter option would be in the NetInfo database, except on my machine, I had no resolver configuration hiding there.
The answer? OS X has a daemon called configd, which magically collects configuration information, sends notifications, and maintains a dynamic database of the current settings. The host command would read my hacked-up /etc/resolv.conf, but smarter DNS lookups would query the network configuration database from configd.
The command-line tools to interface with the configuration daemon are scselect and scutil. scselect provides a list of defined network locations (as in the Network preference pane) and allows you to choose between them. scutil enables much more fine-grained control over the current network configuration. Unfortunately, it only really offers a command-line interface to modify the configuration database. To use scutil from a bash script, you must dynamically create an scutil script as a text file, and pipe it to scutil.