Moved to new blog: http://nlfiedler.github.io/2009/02/26/making-netatalk-discoverable-in-opensolaris.html
first of all thanks for this hint. Could you please explain, where to save the shell script “Registers the AFP daemon with dns-sd” above and when to start?
Sorry about that, forgot to mention where the script goes. The shell script could go anywhere, but the convention is to put it in /var/svc/method (you may have to create that directory). I’ve updated the post to include the path. Thanks for your comment.
if i do “/usr/bin/dns-sd -R “test” _device-info._tcp. . 548 model=Macmini” and then “/usr/bin/dns-sd -R “test” _afpovertcp._tcp. . 548″ i get a mac mini icon…
But in the linux docs they point the _device-info._tcp too port 0, so my question is, am i breaking anything by doing it this way?
Thanks for the guide:D
@mads: good question, and I don’t know the answer. According to the dns-sd man page, a port value of zero means the service is not available, and so using that appears to be a no-op. I’ve just set it up as you’ve done and it seems to be working fine. There are no messages in any of the logs, and my Mac sees the server exactly as intended (it’s viewed as a file server with the appropriate icon, Xserve in my case). So, while I don’t have the definitive answer, this approach seems to work just fine. To find out for sure, post your question to the nwam-discuss list on opensolaris.org. There’s at least one person there who works for Sun that should know the answer. Thanks.
This works like a charm – for about five minutes.
After that my Macs seem unable to resolve the addresses of the OpenSolaris machine via mDNS. Pretty weird. Have you experienced anything similar?
@toto: I’m afraid I’ve not come across that situation before. I’d start by making sure the dns-sd process is still running, that the server is still reachable, that it’s IP/hostname hasn’t changed somehow, etc. But yes, that’s a weird symptom. Good luck.
Sweet guide man – appreciate all of the help getting some of us less experienced Solaris guys up to speed!
Regarding where the script should go, the convention is _not_ to put it in /var/svc/method but rather /lib/svc/method. Not sure how I managed to miss that, but wanted to set the record straight.
Great stuff! Works like a charm!
Thanks very much fella. :-)
You might want to incorporate the changes from the comment about how to change your icon into the original script. I worked it out of course, but it’s bound to be a common question so – as the rest of the FAQ is so clear! – it’s probably worth sticking in your script from the word go….?
@Tom: good idea. I’ve added the line to the example script. Thanks.
What is the name of the script “Registers the AFP daemon with dns-sd”?
What name to use for this one.
I’d save under the name /lib/svc/method/svc-dns-sd and did the command: pfexec svccfg -v import /var/svc/manifest/site/dnssd_afp.xml
pfexec svcadm enable dnssd_afp
but svcs dnssd_afp:
maintenance 12:12:05 svc:/site/dnssd_afp:default
I thing that the error is in the filename!
Thanx in advance
@lars: I used the name dnssd_afp for the script and put it in /lib/svc/method. Hope that helps.
Now it works. :
root@TimeMachine:/lib/svc/method# svcs dnssd_afp
STATE STIME FMRI
online 13:43:01 svc:/site/dnssd_afp:default
Renaming to dnssd_afp did the work!
I can now happily announce that I have a working TimeMachine based on OpenSolaris 2009.06 running in 64 bit mode on a AMD Athlon 64 CPU.
Thanx for your help!
Yes – the script name has to be “dnssd_afp”. Otherwise, you get the error:
[ Sep 14 20:56:31 Executing start method (“/lib/svc/method/dnssd_afp”). ]
/sbin/sh: exec: /lib/svc/method/dnssd_afp: not found
Yeah, how about an update to get the right script name into the main body?
Very nice write-up. The only problem I have is that I get an error when trying to browse the server using bonjour. I get an “can’t resolve link-local name” error. Any ideas?
@Mark: that’s a good question, and I don’t know the answer. Hopefully someone out there has encountered it before and found a solution, but I’ve never seen that error myself. Good luck.
I’m a little confused about how this is supposed to work. Does this just implement the bonjour advertisement, or is it intended to actually start the AFP sharing daemon, replacing /etc/init.d/atalk? I expected the latter, but I wasn’t able to get “svcs dnssd_afp” to report other than “offline*” until after I did “/etc/init.d/atalk start”
This is in addition to the atalk daemon, simply making it easier to manage within OpenSolaris. Thanks for the comments, I’ll try to get the blob updated as soon as I can.
So you don’t expect the new service to be able to do anything without first starting atalk? Is starting /etc/init.d/* part of the usual startup sequence for OpenSolaris, or do I need to do something additional for that?
Also, note, it might be a good idea to note in the blog that “chihiro” is the name the fileserver will show up with.
Right, OpenSolaris, as with Solaris and most any Unix-like system that I’ve heard of, processes the init scripts on startup. The preferred solution in OpenSolaris is SMF, but I didn’t bother creating the necessary wrapper for atalk. Regarding the hostname, I thought of that too but figured people would look at the dnssd man page. In any case I’ll make a note of the hostname. Thanks for the feedback.
Pingback: OpenSolaris + TimeMachine backup + network discovery « Matt Connolly’s Blog
You can do the service discovery with the avahi-bridge service. I wrote an article here:
Thanks for your very helpful posts!
Hi, first of all you did a great job. The tutorial helped me a lot.
My issue was a opensolaris afp network share wich works out of the box with time machine, like time capsule do.
Did anybody found a solution how dns-sd offers the afp share like time machine wants to have it ?
take care, Rossi
Pingback: Showing the OpenSolaris netatalk share in your clients Finder « klein2 – technique blog
Pingback: Adding AFP support to Nexenta Core 3.0 | Technical Ramblings
Comments are closed.