Braindump

I’ve previously written about SSH and ssh-agent on Mac OS X where I mentioned a utility named SSHKeychain that helps manage the agent daemon and your passphrases. Well, Mac OS X 10.5 (Leopard) has been released since that post, and things have changed. The long and the short of it is that ssh-agent is handled much better than before, by default. But its usage can also be a bit confusing (at least it was for me). I’ll try and explain how it all works in Leopard, so you can get the most out of it.

Why Use a Passphrase, Reprisal

I read a rebuttal or two to my previous post, where I mentioned that using a passphrase protects your private key, if someone gains access to your account. Their main argument was that if your system gets hacked, then the bad guy has complete access to your machine and you’re screwed anyways. True, if someone gets root on your machine, the game is pretty much over. As root, they can do really nasty things like steal ssh-agent identities and install key loggers to snoop your passphrase.

The problem is that root exploits are not the only way to get hacked. What if a bug in a web browser’s Javascript exposes local filesystem access? A nasty web page could read your private key file (~/.ssh/id_rsa), and post it to a website, for example. Or what if you accidentally left your laptop unattended (and unlocked) for a few minutes at the coffee shop? Someone could grab the private key file and stick it on a USB drive. If the attacker was even half way smart, they’d grab ~/.ssh/known_hosts along with your key, since that contains host names you’ve connected to.

Without a passphrase, your private key is completely usable to the bad guy. Using a passphrase encrypts your private key, so that they would have to crack your passphrase to get access to it. In summary, an empty passprhase on your private key is a bad idea. It’s just asking for trouble.

The Über-server

Okay, back to the topic at hand: ssh-agent on Leopard. One of the benefits of SSHKeychain (or one of the other ssh-agent apps for OS X) is that it starts ssh-agent at login time. It also sets the SSH_AUTH_SOCK environment variable (which points to a Unix domain socket) to be accessible by all apps (usually by modifying ~/.MacOSX/environment.plist). Leopard gives you the equivalent of this, out of the box. Open up a terminal and see:

% echo $SSH_AUTH_SOCK
/tmp/launch-nZRFjA/Listeners
While this environment variable is automatically set for all processes, this is a little deceiving. ssh-agent does not actually get started when you log in. Go ahead and see for you self, by running this command right after you login:

% ps xa | grep ssh-agent | grep -v grep
You should get nothing back. It turns out that ssh-agent gets started on demand, the first time something tries to connect to the socket:

ps xa | grep ssh-agent | grep -v grep ssh-add -l
The agent has no identities.
% ps xa | grep ssh-agent | grep -v grep
10877 ?? S 0:00.02 /usr/bin/ssh-agent -l
The ssh-add -l tried to connect to the socket, and thus caused ssh-agent to launch. Pretty nifty.

But how can the SSH_AUTH_SOCK be valid without ssh-agent? The magic sauce is launchd. launchd was introduced in Mac OS X 10.4 as a replacement for many traditional Unix daemons such as cron, xinetd, and init. Since (x)inetd is known as a super-server, and launchd replaces xinted plus a few other daemons, I like calling launchd an über-server. In this context, launchd creates the Unix domain socket and listens for connections, on behalf of ssh-agent. When something connects, it automatically launches ssh-agent. Since launchd is always running, it can listen for connections right after you login.

For the curious, this is done with the new SecureSocketWithKey plist key for launchd. From launchd.plist(5):

This optional key is a variant of SockPathName. Instead of binding to a known path, a securely generated socket is created and the path is assigned to the environment variable that is inherited by all jobs spawned by launchd.

Rock! The launchd plist file for ssh-agent is at:

/System/Library/LaunchAgents/org.openbsd.ssh-agent.plist
The benefit of this lazy launching is that ssh-agent is only run if you use ssh. If you never use ssh, the agent never gets launched, and you don’t waste any resources running it.

Keychain Integration

But the awesomeness doesn’t stop there. If you have an SSH key and try to connect to a server, you’ll get this nifty dialog box asking for your passphrase:

The first benefit of this dialog box is that it uses a secure text field for your passphrase. This field is not copiable and not snoopable via universal access or low-level keyboard routines. The real benefit, though, is the second checkbox: “Remember password in my keychain.” While it does store the passphrase in your keychain, it actually does more than that. It also adds the identity to your ssh-agent for you:

ssh-add -l

The agent has no identities. ssh dave@example.com
... Type passphrase and check "Remember in my keychain" ...
example.com> exit
Connection to example.com closed.
% ssh-add -l
2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx /Users/dave/.ssh/id_rsa (RSA)
By adding your identity to the agent, you can now log right back into the same machine, without typing any passphrase. However, ssh does not prompt for you passphrase because it gets it from the agent, not your keychain. Remove your identity from the agent, and try again:

ssh-add -D

All identities removed. ssh dave@example.com
You’ll get that same GUI dialog box again. But it stores your passphrase in your keychain, right? Then why is it asking for your passphrase if it’s in your keychain? And, why would it store the passphrase in your keychain if it’s not going to actually use it? I know I was scratching my head at this point. Well, it does use the keychain, just not how you may think.

It turns at that when ssh-agent is started, it automatically adds all identities that have passphrases stored your keychain. So the normal workflow, where identities are not removed from the agent, just works. Since the GUI dialog box added your identity to the agent when it added the passphrase to your keychain, you don’t need enter your passphrase again for the rest of that login session. For all future sessions, the identity is automatically added when ssh-agent starts. And remember from above, that ssh-agent starts on demand, only when needed. Thus, you only enter your passphrase once, and from then on it grabs it from the keychain.

Manually Adding Identities

If you do want to remove your identities, you can manually add all the identities from the keychain with the Apple-specific -k option on ssh-add. From ssh-add(1):

Add identities to the agent using any passphrases stored in your keychain.

Sweet! Let’s try it out:

ssh-add -D

All identities removed. ssh-add -l
The agent has no identities.
ssh-add -k

Added keychain identities. ssh-add -l
2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx /Users/dave/.ssh/id_rsa (RSA)
Beware, the passphrase dialog box is not a GUI version of SSH_ASKPASS, though. Try adding identities without consulting the keychain, and you’ll still get prompted in the terminal:

ssh-add -D

All identities removed. ssh-add
Enter passphrase for /Users/dave/.ssh/id_rsa:
And that covers it. I’m a little too paranoid to use this default behavior, though, as I don’t want my passphrase to be stored in my login keychain. Thus, I’ve written a follow-up article that discusses possible ways to beef up security of your passphrase

Posted by Mario at 01:48 PM | Permalink | Comments (2462)

Hibernation and Sleep

Mac users have become quite familiar with using Sleep mode. In Sleep mode, Macs go into a very low-power mode, while saving the current session for later use. Putting a Mac to sleep will continue to power RAM in sleep mode, so that whatever was in RAM when the computer went to sleep will still be there when the computer wakes. Sleep mode is almost instantaneous, consumes very low power, and as a PowerBook owner its indispensable to me. Still though, it requires a power-source (however low) and there are times when laptop batteries are completely depleted or a user wants to completely power-off their Mac.

Similar to Sleep, Windows “Hibernates,” while Linux “Software Suspends”. They are not as fast as Sleep mode, but they take it a step further by not using any power. When Hibernating, a PC quickly saves the current session to the hard drive, shuts-down, and completely powers-off the computer. Upon powering-on, the user is quickly returns to the previous session.

Safe Sleep

Up until recently, Mac users didn’t have a similar Sleep mode which required no power. When Apple announced new PowerBooks in October 2005, it also introduced Safe Sleep to Mac OS X, an extention to Sleep mode that allows for hibernation without power.

According to an Apple article:

Safe Sleep ensures that data stored in main memory will not be lost should the system shut down due to a loss of power during sleep mode. Prior to your system entering sleep, Safe Sleep automatically saves the contents of main memory […] to the hard drive. In the event the battery becomes completely depleted while the system is asleep, the computer will shut down. But when a power adapter is connected or a freshly charged battery is installed, the PowerBook can be restarted and it will automatically return to the desktop state that existed prior to entering sleep.

When restarting a PowerBook from Safe Sleep, a progress bar indicates that the PowerBook is waking from Safe Sleep. The screen is also in gray-scale and slightly blured.

How to Enable Safe Sleep

Safe Sleep is so-far only officially available on the new PowerBooks. But Safe Sleep is very much software based , not hardware based. With Apple’s release of mac OS 10.4.3, Safe Sleep can be enabled on many Macs thanks to an excellent hack. To do so first insure Mac OS X, is up-to-date to with version 10.4.3 (or above). If not, run Software Update.

Reportedly working laptops include (but not necessarily limited to) iBook G4s, Aluminum PowerBook G4s. You may also try Safe Sleep on desktops. For a much more technical look into enabling it, visit the source information on the hack.

Warning: Enabling Safe Sleep is essentially a hack. It is very likely to work on recent Macs, but enabling Safe Sleep may cause your Mac to explode, implode, melt, freeze, have a heart-attack, or develop an inguinal hernia.

1. Apply Safe Sleep Property

To summarize, new PowerBooks have the “has-safe-sleep” property. To apply this property to your Mac, something needs to be run in Open Firmware at boot. In the Terminal enter the folling, hitting return at the end of each line:

sudo nvram nvramrc='" /" select-dev
" msh" encode-string " has-safe-sleep" property
unselect
@'@

sudo nvram "use-nvramrc?"=true

In a Terminal shell it should look as follow:

Last login: Fri Nov 11 11:11:11 on ttyp1
Welcome to Darwin!
computer:~ User$ sudo nvram nvramrc='" /" select-dev
> " msh" encode-string " has-safe-sleep" property
> unselect
> '
computer:~ User$ sudo nvram "use-nvramrc?"=true

The Mac must be restarted to set the changes.

2. Allow Hibernate Mode

To continue, you must have at least as much free disk space as physical memory , plus 750MB. To enable Sleep Safe, in the Terminal enter:

sudo pmset -a hibernatemode 3

If you have secure virtual memory enabled, use 7 rather than 3 to disable encrypted hibernation. Encrypted hibernation does not work. Do not set it to 7 if you do not have secure virtual memory.

This should create the file /var/vm/sleepimage.

When your Mac is set to sleep, it will now enter regular Sleep mode (consuming minimal power) first. If you prefer to enter Safe Sleep mode directly (note: it takes a few seconds more to sleep and wake-up) then instead enter:

sudo pmset -a hibernatemode 1

Use 5 with secure virtual memory.

To disable Safe Sleep:

sudo pmset -a hibernatemode 0

The Mac does not need to be restarted to set the changes to hibernate mode.

3. Verify Sleeping

Put the Mac to sleep and wait for the light to start pulsing. Wait a few more seconds. Wake it normally (by hitting the space bar for example).

Open Console and view system.log, or simply open the file /var/log/system.log. Look for a line indicating that the process worked. It is similar to:

Nov 11 12:15:33 computername kernel[0]: System SafeSleep

4. Verify Safe Sleep

Now attempt to actually Safe Sleep for real. Put the Mac to Sleep, and wait for the light to start pulsing. Remove the power-source plug and the battery. Wait for the light to stop pulsing and turn off, which may take a a couple of minutes. Your Mac should now be in Safe Sleep mode. Plug the power back in and add the battery. Start-up. It should show the previous saved desktop (blurred and in grayscale) along with a progress bar as pictured above. The system should be back to the way you left it.

Troubleshooting

You may have problems with a bad hibernate images, which may repeatedly kernel panic. Try restarting which will start the image again. It may work. It may not, and repeatedly fail. This can happen if you don’t set hibernatemode properly with secure virtual memory (try alternating between 1+5 or 3+7). If a bad hibernate image keeps booting then crashing reboot the mac holding down Command-Option-O-F to get in to Open Firmware. Type:

setenv boot-image
Hit return, then enter:

boot

Disable Safe Sleep

To disable Safe Sleep enter in the Terminal:

sudo pmset -a hibernatemode 0

No need to restart.

For a more full undo, disable all nvramrc variables:

sudo nvram "use-nvramrc?"=false
Enter password, then restart.

Conclusion

Now that Safe Sleep is working for me, I have set my PowerBook to use Safe Sleep, instead of just regular Sleep mode that consumes power. It take about 15 seconds to enter Safe Sleep, and about 40 seconds to wake-up from it. That is way longer than the 2 seconds it takes for regular Sleep and wake-up.

Safe Sleep seems very promising though and it will be interesting to see if Apple supports it with older laptops.

Posted by Mario at 08:10 PM | Permalink

L'installation du NXClient se fait comme suit:
# Désarchiver le package .dmg de NXClient
# Copier les programmes ce situant dans le répertoire Application du client NX dans votre répertoire /Application sur votre MAC.
# Copier le contenu du répertoire usr du client NX dans votre répertoire /usr sur votre MAC. Et le tour est joué !

Posted by Mario at 08:09 AM | Permalink

These instructions are all done at the command line and several of them require administrative privileges. Other than diskutil, these programs are pretty standard on any Unix-like system. An existing UltiFire drive would already be formated, but for completeness we will discuss dealing with both pre-formatted and un-formated drives. Connecting or powering on a drive with a supported file system causes OS X to mount the drive its partitions. These partitions will need unmounting before going any further. Connecting or powering on a drive without a supported file system causes OS X to present the following dialog: "You have inserted a disk containing no volumes that Mac OS X can read. To continue with the disk inserted, click Ignore." Given the choices Initialize..., Ignore, and Eject choose Ignore.

There are several ways to unmount partitions, because the OS X Finder sometimes doesn't deal with umount well, it is best to use diskutil. First we determine the full path to non-root volume(s) in question by typing mount | grep /Volumes. We can then use diskutil to unmount the UltiFire drive.

[kyoto:~] rds% mount | grep /Volumes
/dev/disk0s9 on /Volumes/os9 (local, journaled)
/dev/disk2s1 on /Volumes/ultifire (local, nodev, nosuid)

[kyoto:~] rds% diskutil unmount /Volumes/ultifire/

Any drive formated with Apple's Disk Utility or Drive Setup applications use the Apple partitioning scheme. Drives formated under Windows as NTFS have an improper MBR entry. This won't work for sharing drives, so we need to change the partition scheme to fdisk. Rather than use the interactive mode, we can provide everything at the command prompt. Note that we use the device we saw when calling mount, but with an "r" prefix and without the slice information afterwards (ie. /dev/disk2s1 becomes /dev/rdisk2). After the partition table is changed, OS X will present the dialog mentioned above; choose Ignore.

[kyoto:~] rds% fdisk -ia dos /dev/rdisk2
fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory

-----------------------------------------------------
------ ATTENTION - UPDATING MASTER BOOT RECORD ------
-----------------------------------------------------

Do you wish to write new MBR and partition table? [n] y

We can verify if the MBR is correct, and create a new FAT 32 file system on the partition using newfs_msdos. We use the device name as we saw when we originally called mount | grep /Volumes. The disk will now be usable for any operating system that can deal with FAT 32. A short list includes: Mac OS X and 9, any version of Windows that supports FireWire or USB 2.0, FreeBSD, Linux, and more.

[kyoto:~] rds% fdisk /dev/rdisk2
Disk: /dev/rdisk2 geometry: 10011/255/63 [160836480 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
*1: 0C 0 1 1 - 1023 154 63 [ 63 - 160836417] Win95 FAT32L
2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

[kyoto:~] rds% newfs_msdos -F32 -v ultifire /dev/disk2s1
newfs_msdos: warning: /dev/disk2s1 is not a character device
/dev/disk2s1: 160797120 sectors in 2512455 FAT32 clusters (32768 bytes/cluster)
bps=512 spc=64 res=32 nft=2 mid=0xf0 spt=32 hds=255 hid=0 bsec=160836417
bspf=19629 rdcl=2 infs=1 bkbs=6

[kyoto:~] rds% diskutil mount /dev/disk2

Posted by Mario at 09:11 PM | Permalink

In Cygwin: $ getclip | sort -u $ ls -al | putclip In Mac OS X: $ pbpaste | sort -u $ ls -al | pbcopy

Posted by Mario at 08:25 PM | Permalink

pour partir un serveur VNC par remote shell. - Se connecter SSH - G�n�rer un fichier de password � l'aide de la commande:

/Applications/OSXvnc.app/Contents/MacOS/storepasswd  /tmp/osxvnc-passwd

- ex�cuter la commande:

/Applications/OSXvnc.app/Contents/MacOS/OSXvnc-server -rfbport 5900
 -desktop "OSX VNC 1" -rfbauth /tmp/osxvnc-passwd &

Posted by Mario at 12:03 PM | Permalink

tell application "finder" mount volume "smb://username:password@serverip/sharename" end tell

Posted by Mario at 11:11 PM | Permalink

"MAC OSX shortcuts list":http://www.info.apple.com/kbnum/n75459

Posted by Mario at 10:07 AM | Permalink

MacDevCenter.com: Automated Backups with Existing Tools [Feb. 10, 2004]

Posted by Mario at 12:49 PM | Permalink

Voici mon premier test. Est ce que les accents fonctionnent? ÉéàÀêôç on verra !

Posted by Mario at 11:08 PM | Permalink

"Linux printing on OSX":http://www.linuxprinting.org/macosx/hpijs/

Posted by Mario at 10:34 PM | Permalink

Server Logistics - Complete MySQL

Posted by Mario at 09:34 AM | Permalink

The Tao of Mac - blog/2003-12-21 Tips For New Switchers A lot of people have been moving to the Mac these past few days, so I thought I'd jot down a few notes about my (nigh-on two year) experience. Unpacking & Testing * While unpacking, look at the packaging. There are neat graphical hints of how to unpack every Mac printed on the box. Do leaf through the manual, but (here's the important bit) don't rush it. There are a few important things to know, even if you've had a Mac before. * If you're getting a laptop or flatscreen, boot the Hardware Test off the first install CD (insert the CD and hold down Alt - or Option, as it is called in older keyboards - while the machine boots). Amongst other things, it performs a display test - which is fundamental for picking up "dead" pixels before you start installing stuff (you can also use ScreenQuery). Setting up Mac OS X * The default behavior these days is for the Mac to prompt you for an installation language the first time it boots from the hard disk and, after installing a few files (a few minutes' worth) configure your locale settings. If your Mac boots straight to the Finder or to the login panel, then someone else has used it before. * After setting up your keyboard, language and whatnot, the installer creates the first user account. This is the important bit: it is an administration account, and you're better off calling it "Administrator" (if you're a UNIXhead, this is not root, which is disabled) and creating a "regular" user account later for your own use (you can do it in System Preferences after setup ends). This will not prevent you from making all the silly mistakes people do when using a Mac for the first few months, but it will significantly decrease the odds of you breaking something. (Yes, you can break a Mac OS X install - or files that make subsequent upgrades fail - by mistake when you're the admin user...) Don't: * Use the administration account for anything other than setting up the machine and applications or changing "permanent" settings (if you want to, say, change network settings as a normal user you'll be prompted for the admin password, and since you'll do configuration changes less and less often as time progresses, this isn't a real issue). * Install "toy" applications as the admin user until you're sure you're going to use them. * Ever, ever move Apple applications (such as Mail.app) to other folders. Mac OS X updates are not always very clever at updating built-in apps, so you'll end up with ether two copies of your apps or a single broken one. * Fiddle with the system startup scripts unless you''re sure you know what you're doing. Mac OS X doesn't use runlevels in the same way as "classic" UNIX systems, and things like network configuration, system services, and whatnot are not (necessarily) stored under /etc. You'll figure it out after a while, but don't go in thinking this is "just like any other UNIX system". It both is and isn't like other UNIXes, and like other UNIXes, fiddling under the hood is not to be done lightly. Do: * Get a proper mouse. I've said before that Mac OS X with a single button mouse is like rowing with a single oar, and I mean it: Mac OS X supports multiple-button mice, scroll wheels, etc. I use Microsoft wireless mice (the old kind, not the Bluetooth ones), which work perfectly and can be obtained in white (no sense getting a horrible blue and red mouse, now is there?). Laptop users should get something like uControl or SideTrack to make better use of the trackpad. * Create your own Applications folder inside your home directory and try out new stuff in there. If it breaks, you won't break the machine for other people (and if a Mac OS X app breaks while running under an unprivileged account, it's badly written for sure). * Drag Terminal.app to your dock as soon as possible. UNIX won't bite you, and some things are best done at a terminal. * Spend some time getting used to the accelerator and "special" keys. They make sense after a while, but having the extra Command modifier key and a different meaning for Home and End plays havoc with some people's reflexes. If you're using a desktop Mac with a non-US keyboard, the screen brightness control is often unmarked - try the function keys above the help key. * Install X11 and get Fink, in this order. Set up the placeholder packages to let Fink use Apple's X11 stuff, and then install whatever packages you need to feel at home. Fink is especially nice since it does not, ever, mess around with your Mac OS X system directories (it hangs off /sw, /sw/bin, etc.) and has the most packages available. And that's it for now, really. I have a few friends who are recent Switchers (two each from the Linux and Windows worlds), and will probably edit this post with new hints soon.

Posted by Mario at 11:16 PM | Permalink

Screen Query 1.2

Posted by Mario at 07:59 AM | Permalink

Eastgate Tinderbox: the tool for notes

Posted by Mario at 07:28 PM | Permalink

FreshSqueeze.com

Posted by Mario at 03:46 PM | Permalink

[unsanity] ShapeShifter - Haxies - Freeware and shareware Mac OS X hacks that enhance the way Mac OS X works; includes WindowShade X, FruitMenu, Xounds, Silk, Menu Master, FontCard, ShadowKiller, Dock Detox and more. see also : "Wired":http://www.wired.com/news/mac/0,2125,61441,00.html

Posted by Mario at 03:42 PM | Permalink

Griffin Technology

Posted by Mario at 12:14 PM | Permalink

The Tao of Mac - HOWTO/Enable Rendezvous on Fedora Linux HOWTO/Enable Rendezvous on Fedora Linux

Posted by Mario at 12:12 PM | Permalink

Welcome to Flying Meat Software, home of VoodooPad

Posted by Mario at 09:54 AM | Permalink

The Tao of Mac - blog/2003-11-16 Dancing With Rendezvous So here I am, trying to get my home network into shape, and fiddling around with Rendezvous to figure out how it works. I've had the source code to Apple's latest mDNSResponder sitting on my hard disk for a couple of weeks now, and after setting it up on my RedHat box I decided to get it working under Cygwin. 15 minutes later, I had mDNSResponderPosix running on my XP box under Cygwin. The port mainly consists of brutally hacking out IPv6? support (by studiously removing any references to AF_INET6) and hardwiring if_nametoindex() (which I can't find inside the Cygwin libraries) to always return 1 - I have only the one interface on that box, so this wanton hack works fine for me. (I do seem to have an outstanding issue with the XP port, since it does not advertise some services properly, but I'll check that later. It was a hack, anyway...) While configuring it on either XP or Linux, however, I came across a few interesting issues: * First off, the mDNSResponderPosix configuration file uses an amazingly dumb format. Sure, it's just sample code, but using ^A (Ctrl+A) to separate attributes is just too impractical to be of any real use, even for testing (mine now use semicolons as separators, at least until I find any conflicts). * You can't, in fact, use mDNSResponderPosix to advertise services for other machines - you have to use mDNSProxyResponderPosix, which requires a separate invocation for each service you want to advertise - i.e., no pretty configuration file either, and a non-trivial bunch of RAM wasted for each service. * Panther won't see your nice Rendezvous services if you have the firewall active. That's all well and good, until you realize there is no way to poke a UDP-based hole in your firewall using the GUI. Shame on you, Apple - users may want their firewalls simple, but definetly not dumb. * There is no comprehensive reference of Rendezvous configuration. I had to download Network Beacon and iRoster to understand a bit more about the services I could define and the parameters available. The good news is, it works. Panther picked up on SSH and HTTP services as soon as I added them to a Rendezvous responder, and I'm currently experimenting with SMB and AppleShare? services. Here's a little sample from my Linux box: # cat /etc/rendezvous.conf The Tao Of Mac _http._tcp. path=/ 80 Public CVS _http._tcp. path=/cgi-bin/cvs/index 80 zeus _ssh._tcp. none 22 The _http._tcp. services show up in the Safari Rendezous? menu, and the SSH service inside Terminal.app in the "connect to..." menu. The path attribute is the only one I know of so far, and its meaning is pretty obvious. I had to add none to the attributes line on the SSH entry to have mDNSResponderPosix parse the file at all, but your mileage may vary. And this is the first thing I don't like about Rendezvous - the lack of an attribute reference for each standard service. The other is the lack of a comprehensive way to set up non-local services - for instance, I might want to advertise a remote file server that is on another LAN without mucking about with mDNSProxyResponderPosix. Sure, Network Beacon does that flawlessly, but I want a generic UNIX daemon I can recompile for whatever I'm running, not a GUI app. There are some interesting possibilities I'll be exploring, like dynamically advertising URLs to the latest updated items on my blogroll. I've already discovered Python bindings for Rendezvous, and once I find the time to learn a bit more Python, I'll probably start with this Twisted-Python post. Time will tell, I guess. Now, back to our regularly scheduled programming.

Posted by Mario at 11:36 AM | Permalink