If you mount unix servers via samba you probably end up with .DS_Store files all over the place. A way I found to keep those from showing up is to 'veto' these files in the Samba config. In the [global] section of smb.conf of the server I am mounting I added:
identd is a user identification protocol specific in RFP1413 which many applications require, even though it is untrustworthy and useless and easy to get around. That said, many applications will require that a valid response is received in order to work properly. In my case, it was IRC (Internet Relay Chat) servers.
Normally you can enter a Terminal session and use pico with sudo to edit the /etc/inetd.conf to change the line
However, when you are using an AirPort base station, the process your are responding to won't like the IP address it is getting back. An easy solution is to install Brian Young's nullidentd. Read the rest of the article for the how-to...
This may be simplistic but it was driving me nuts till I solved it. It seems that all past servers are in the list when you hit Command-K to select a location on your network. Over time, some of the servers change ... new names for work stations, new machines, etc. There is no way to delete the old names from the "Connect to Server..." window.
Solution: Go to the ~/Library -> Recent Servers folder and throw away the servers you want to delete. Next time you use "Connect to Server...," they will be gone.
After we subnetted our network, my network parent domain was orphaned (e.g. NetInfo busted). I couldn't get to it through the GUI client. So, I used nicl (which was good, wholesome fun). Here is an output of what I did to fix the problem (NetInfo kept the IP even though I changed the IP in the GUI Directory Services and Netinfo Domain Setup):
One problem -- the passwords were bad (the admin user and two regular users that I tested could not login) . I'm guessing this is because the crypt uses something based on IP?? Hmm. Anyway, I had to delete all the entries and import a backup copy I made.
[Editor's note: You can probably do Very Bad Things to your machine with this program, so be very careful ... "have you hugged your backup today?"]
I have a very nice Epson printer connected to my living room computer running WinXP. I tried every one of the hints posted here designed to let me print to it from my Mac running Jaguar, but no luck. Then I ran across a posting on the internet about how to set up an LPD daemon on XP. Since I use an LPD spool on my Linux server at work, I gave it a shot and it worked perfectly!
For months I was frustrated that a perfectly working Brother laser printer on our home network could not be used from other machines via Printer Sharing. The printer would show up (thanks to Rendezvous) in other machines' Print Centers, but attempts to print to it from them would fail with messages like "IPP0: Undefined error." The machine to which the printer is attached also hosts a domain, betips.net. But I had always referred to the machine as "gong" out of habit, and had set
in /etc/hostconfig. As it turns out, this caused a subtle discrepancy in hostname resolution that had never affected normal operation. The solution was to restore HOSTNAME="-AUTOMATIC-" in /etc/hostconfig and let OS X resolve the hostname automatically to www.betips.net. The fix almost seems obvious in retrospect, but Brother support, Apple Geniuses and I were all barking up the wrong tree, thinking it had to be a problem with the driver or in the CUPS layer.
The key troubleshooting tool turned out to be the semi-secret built-in CUPS http interface. Enable printer sharing and access http://localhost:631 on various machines on your network. From here, it became apparent that the printer was being seen with different names from different machines. Experiments with nslookup led to the hostname being the culprit.
Short lesson: Change your sharing name all you want, but don't mess with the hostname in /etc/hostconfig unless you really have a good reason to - some aspects of OS X would rather resolve hostnames automaticaly.
I found this the hard way, and since I see others have run into the same problem without listing a definite solution, I thought I'd make this easy to find.
OSX (at least 10.2 and on) will not resolve .local names via DNS. lookupd's DNSAgent simply refuses to issue queries for them. This gives the strange situation where nslookup foo.bar.local returns the correct information while ping foo.bar.local returns an 'unknown host' error.
This is documented in Apple's Knowledge Base (article 107174), but if you didn't think to browse the Rendezvous docs for DNS problems, you'd probably never find it. Apple's recommendation is to simply change your domain from .local to .home, .office or .lan. I've done that here, but with well-established kerberos and afs servers in the .local domain, it was anything but simple (or pleasant).
The only other workaround I know of is to populate each Mac's /etc/hosts file with all the local IPs and hostnames (e.g., "10.0.0.1 foo.bar.local foo"), and then change lookupd's search order with the following command (shown on two lines, but the backslash should allow a copy and paste to work):
nicl . -create /locations/lookupd/hosts \ LookupOrder Cache FF DNS NI DS
The tradeoff here is that while names in .local now resolve correctly, you've got the fun of keeping your /etc/hosts files in sync. That's probably why you installed a DNS server in the first place.
Finally, I have no idea how this workaround might affect Rendezvous. I do know that disabling Rendezvous completely had no affect on .local name resolutions.
You don't need to use Linksys' Windows software to upgrade the flash firmware in your Linksys Router. Unix to the rescue! Here's how:
Download the latest firmware from Linksys, and extract the code.bin file from the archive (usually a zip). Place the code.bin file on your desktop.
Go into your router's configuration screen and remove the password.
Open a terminal and type cd ~/desktop
Run the tftp command with your routers IP number:
% tftp 192.168.0.1
At the TFTP prompt, type binary.
Send down the new firmware by typing put code.bin and then hitting return. Voila! If there was a short delay while the code.bin was transferred, and no errors are reported, then you are almost done.
Go back into your router's admin screen and restore your password. Bonus: If you don't know your password, it ships from the factory as admin or if you forgot it, you can do a hard reset (see your manual).
You can also, instead of using the tftp command, log into your router's web admin interface and goto the Update.htm page and use the Java upload applet. TFTP lets you rub the fuzzy UNIX underbelly of OS X, and really isn't that what it's all about? ;)
Earlier this year, Sysadmin Magazine plublished an article I wrote dealing with multi-platform performance monitoring. The article describes how to implement a bare-bones system for remotely monitoring system activity on groups of systems. I covered several Unix and Unix-like systems, including MacOS X (10.1 at the time, but would also apply to 10.2).
It's not specifically written for MacOS X users, but if you need to monitor a room full of MacOS X computers, and know the basics of terminal.app, sudo, and can install gnuplot, it might be of interest.
[Editor's note: I haven't tested any of the things Dale mentions in his article, but it's an interesting read and might be of use to those of you who manage Macs and/or other UNIX boxes for a living...]
For a while now, I have been getting a -36 error when trying to use Mac OS X 10.2.x's Connect to Server to connect to a Windows 2000 server SMB share. After a few weeks of frustration, I figured out what the problem was, or more accuratley, what I did wrong.
On Windows 2000, there are two services which at first glance do not seem to be related to file sharing, however, they are. Be sure to set Network DDE and Network DDE DSDM services to automatically start. If they are off, you will get the infamous -36 error commonly followed by a kernel dump.
I still think Apple has a bug for causing a UNIX core dump just because some expected services are not running on my W2K server.