I have a number of Macs and Red Hat servers running with sshd and kerberos (using an MIT KDC running on Red Hat). I can log onto any of these servers just fine with Tiger, but with Leopard, I cannot. I've set up kerberos on the Leopard client, and I can acquire a ticket. However, when I try to log on to a server, it appears that the client isn't even trying to send the kerberos ticket.
I will not take credit for the following solutions; they come from Apple Support. However, I've tested them both, and they worked for me.
10.5 disables gssapi authentication by default. You have to edit /etc/ssh_config, uncomment the line containing GSSAPIAuthentication and change no to yes. Engineering claims this change was made in 10.4.9 and later, but 10.4.10 and 10.4.11 allow gssapi authentication by default for me.
You can also run ssh server.com -o GSSAPIAuthentication=yes to force GSSAPI authentication.
First, this is just for fun, and has no practical use at all. Second, see the warning below before trying this...
Everyone knows the old fairground trick of infinite mirrors, where opposing mirrors give an image repeating itself into infinity. This was also replicated famously in Queen's Bohemian Rhapsody video. Well, try this...from Mac #1, connect to Mac #2 using screen sharing in the Finder (not iChat). From within the screen sharing window, connect Mac #2 to Mac #1, again using screen sharing. Stand back and wonder what you can use this for!
Warning: I had trouble getting out of this mode once in it. To do so, I put Mac #1 into sleep mode (press and hold the power button), and as soon as I woke it again, was able to quit screen sharing. YVMV, and I have no idea what effect different window sizings or options may have. Fun for the child within though :)
In reality I think this is actually a bug, or at least an oversight by Apple. With my sensible head on, the app should warn you and/or make this impossible.
This is not quite a hint, hack, or anything, but it's still of interest for those who like me were interested in upgrading their 802.11n-capable iMacs to the rank of 802.11n-enabled iMacs.
Well, I happened to decide only now that I would do that update after many months of resistence. (I didn't have the need for it as my router doesn't support 802.11n, but I am actually thinking of changing my router to a better one, so why not get an "n" one?). To my surprise, the Enabler wouldn't install or work on my iMac, even though it is 802.11n capable. So I looked into some Tech Support Docs, namely this one which describes how to tell if your machine is n-enabled or not.
To my surprise, I found out that when I installed Leopard, my iMac's n-mode was activated automatically! So people with those "borderline" iMacs like mine who never enabled your 802.11n, this is one more reason to upgrade to Leopard -- it will save you the $2 cost of the enabler.
Mac OS X Leopard does not discover and automatically mount NFS shares publsihed via Bonjour/ZeroConf as Tiger did. (If you own a Linux based server, you can publish all kinds of Bonjour servers via a daemon called avahi). 10.5 only discovers AFP and SMB Bonjour published shares as far as I am aware.
To work around this temporary bug/missing feature, I wrote a simple Ruby-based daemon which you can install so it starts up every time Leopard boots. This daemon simply continuously browses for and resolves published NFS shares and will mount them automatically if they are not already mounted for your user account. Let's hope Apple will fix this soon so we do not need anymore workarounds like this.
[robg adds: I have mirrored the source [4KB download] here on hints, but if you're reading this at some point in the future, you may wish to check the link above for a newer version.]
This hint will allow you to use T-Mobile's WPA encrypted connection at T-Mobile hotspots. This is an update to this previous hint.
Open Network Preferences, select AirPort, click Advanced. In the Advanced section, click on the 802.1X pane, then click the 'Enable 802.1x Login' box. In Wireless Network, enter tmobile1x; under Authentication, check these: TTLS, PEAP, EAP-FAST, LEAP, and MD5. Now click OK.
Under Network name, select Join Other Network; in Network Name enter tmobile1x, and under Security, select WPA2 Enterprise. Finally, for 802.1X, select TTLS-PAP. For User Name, enter your T-Mobile Hotspot user name (what you'd enter on the login screen). For Password, enter your T-Mobile Hotspot password.
Now click Join, and you'll be connected and able to surf! NOTE: You will not need to login on a web page when you use this method.
Are you using PPTP to connect to a Microsoft ISA server for VPN? Do your internal machines on the VPN side of the connection no longer resolve except when you use a fully qualified domain name?
The PPTP VPN settings under 10.5 provide some additional options, which you can reach via the Network System Preferences panel. Go to VPN, and click on Advanced, then view the Options tab. The setting is "Send all traffic over VPN connection." If this is unchecked, you will be unable to resolve internal hostnames without typing the fully qualified domain name. If you check it, you will be able to refer to your internal hostnames by the short name. This occurs no matter whether you have your VPN local DNS search domain typed in there or not.
I think this may in fact be a bug in 10.5, since it presumably should work without have to force all the traffic over the VPN.
One thing that I really miss from Tiger is having a shortcut on my Desktop to my network shared volumes, so I don't have to open a Finder window, click on share, and then select the machine or AirPort Extreme entry, and then the volume I want to access.
Leopard won't let you make an alias of a network shared volume, or create one by dragging it to your desktop. What I found out, however, is that you can drag a shared volume to the dock as a Stack folder, and there it is, a direct link to your shared volume. You have to drag it to the area next to the trash; it won't work in the applications zone of the dock.
It also helps when the Shared option won't even appear, and you don't remember the direct link to get to the volume through finder's Go » Connect to Server option. This happens quite often with AirPort Extreme, and now I just have to click the shortcut on the dock and it will come right up.
[robg adds: As noted in this hint, there seems to be either a bug or a feature in the new Finder: using Column view, you can make aliases from networked volumes via a drag to the desktop (or to the sidebar, as in the previous hint). Using other views, though, you cannot. I can only hope that this is a bug is in the 'other' views, and it's not something that's "fixed" in a future update by breaking the column view behavior! Regardless, putting the network share into the Dock as a Stack is an interesting trick.]
After upgrading to Leopard, I found I was unable to mount any of the shares on my Linux file server, getting the following error:
The operation cannot be completed because one or more required items cannot be found.
(Error code -43)
At first I thought this was because of the security configuration I was using on the file server, or perhaps because Leopard had changed the type of authentication method it was expecing from an SMB file server (NTLMv2 for example). It turns out it was a lot simpler -- it was because all of the shares on the file server were set as non-browseable (Browseable = No in /etc/smb.conf. Changing at least one share to be browseable corrected the issue and let me connect to the file server and mount the shares available, regardless of if they were set as Browseable or not.
It should be noted that if you connect to any windows servers, then you will not notice this issue as the default shares for drives (c$, d$, etc) are browseable, but most SMB client implementations will 'hide' them from the end user.
I had been having some problems dealing with Leopard's Screen Sharing feature -- I wasn't able to remotely connect, no matter which ports I opened or prefs I turned on, using a machine from my job running 10.4.
I was attempting to connect with Chicken of the VNC (CotVNC), and according to a few articles across the web, it should have worked flawlessly. It certainly did on my network at home, so I wasn't sure what I was doing wrong. I even DMZ'd my machine at home -- still, nada.
Then I was playing around with the Profiles options in CotVNC, and there's a setting where you can change the resolution of the window on the client's end. The choices are 256 colors, Thousands, Millions, and Let Server Decide. I always had it set to 256 at work, because I was more interested in speed than how pretty my desktop looked from afar. However, I checked out my settings at home and I had the Let Server Decide option selected.
Aha -- I was on to something. I got to work this morning, changed the resolution in the profile settings to Thousands, and sure enough, CotVNC works like a charm again. It also worked fine with Let Server Decide. 256 colors worked perfectly with Tiger, but I'm guessing there's something with Leopard's built-in screen sharing that's not allowing a VNC client to connect at that low of a resolution. Just thought I'd share my findings for anyone possibly having the same difficulties.
For .mac users, the iDisk is fantastic for keeping a folder synchronized between multiple computers. One can turn on local syncing of the iDisk to have hard drive speed access to this folder shared between multiple machines, which is great. I do almost all my document editing on the iDisk and it is the same everywhere I go. For those who do a lot of document editing, doing some form of version control would be great. Time Machine is perfect for this, as subversion is kind of overkill for documents and small projects.
However, there is a problem with using Time Machine on the iDisk in Leopard: the iDisk in Leopard is not locally synchronized on a file to file basis. The local copy exists as a .sparsebundle file in ~/Library/FileSync. This is done so that the local copy only occupies the same amount of space as the files you currently have in your iDisk. Tiger on the other hand would just take up the full 10GB on your hard drive if that is how much space was allocated for your iDisk. This .sparsebundle looks like one giant file, but it is actually a package which contains a whole bunch of 8MB bands.
Time machine does not let you look at your iDisk back in time, but this sparsebundle is backed up, so in principal one could go back in time and recover a previous iDisk. But one could only recover the entire previous contents of the iDisk rather than individual files on the iDisk. (Note here that if you change an individual file on the iDisk, Time Machine will only backup the bands which have changed, which are at most 8MB, rather than the entire iDisk).
However, this does not help with recovering a single file from the past from the iDisk. There is a hack to do this however.