I saw zeroconf in action at a Mac based facility a while back and I have to say I was impressed. It makes their networking setup very easy. The biggest downside was that they knew very little about how their network actually worked. That made my life integrating a Linux system in to their environment much more difficult. So, I'd like to see zeroconf really integrated in to FC5. I think it'll make network setup for a lot of users much easier.
For those who don't know, zeroconf provides several functions:
*) Dynamically allocating an IP address to a system when it boots (without requiring a DHCP server) *) Translate between names and IP addresses (without any setup or directory server) *) Allows for the publishing and discovery of services such as DNS, NFS, ftp, http, printers, whatever (without requiring any setup or directory server) *) Allocates multicast addresses (without a MADCAP server). (This part isn't yet supported and I'm not sure I know what it means :))
Fedora ships with Howl which looks to be the framework for doing zeroconf. It seems that what's needed is integrating howl in to all the appropriate places.
- |Daryll
On Thu, 02 Jun 2005 19:36:33 -0700, Daryll Strauss daryll.strauss@gmail.com wrote:
Fedora ships with Howl which looks to be the framework for doing zeroconf. It seems that what's needed is integrating howl in to all the appropriate places.
Although zeroconf looks like a good idea, the bogus entries that it created in our network routing tables were one of many red herrings we faced when debugging bizzare networking problems that were caused by a race condition in the 2.4 kernel that came with RHEL 3.
A mac feature that's really fascinated me is the way that you can boot a mac into a mode where it functions as a firewire target.
I've got an old PC that's getting abused by my toddler that I've been thinking of turning into an iSCSI target: I've been thinking of making a micro linux distribution, probably fedora based, that makes a machine into an iSCSI target. One application would be a 'storage appliance' for a SOHO environment, but another could be a specialized boot mode, that maybe lives on a small partition, that would let you boot a mainstream Linux system into a iSCSI target mode the same way a Mac can boot into firewire target mode -- there are concerns about security, and it would take some work to make a client so that this is 'plug-and-play' with another Linux box, but it would be a fun project and probably useful. Zeroconf would be a great way to make this happen.
The storage appliance project faces the more serious problem that my home network (and many others) is heterogenous: i'd really like a global filesystem that works with Linux, MacOS and Windows, never mind a planned Solaris 10/x86 test machine and a stack of 32-bit and 64-bit SPARC machines that I'm going to install whatever OS I can to run on them. It's for that reason that iSCSI might wind up in the same dustbin as WAP and the fifth-generation computer...
On 6/3/05, Paul A. Houle ph18@cornell.edu wrote:
The storage appliance project faces the more serious problem that my homenetwork (and many others) is heterogenous: i'd really like a global filesystem that works with Linux, MacOS and Windows, never mind a planned Solaris 10/x86 test machine and a stack of 32-bit and 64-bit SPARC machines that I'm going to install whatever OS I can to run on them.
NFS? Samba? ;-)
It's for that reason that iSCSI might wind up in the same dustbin as WAP and the fifth-generation computer...
Ups! Then FAT32? No, seriously, I'd hope for some kind of universal, local filesystem.
On 6/3/05, Paul A. Houle ph18@cornell.edu wrote:
The storage appliance project faces the more serious problemthat my home network (and many others) is heterogenous: i'd really like a global filesystem that works with Linux, MacOS and Windows, never mind a planned Solaris 10/x86 test machine and a stack of 32-bit and 64-bit SPARC machines that I'm going to install whatever OS I can to run on them.
NFS? Samba? ;-)
Global filesystem, not network filesystem.
iSCSI works at the block level: a global filesystem is one where a number of computers can share a block device and all make updates to the filesystem without trashing it. Redhat bought Sistina and makes one (GPL) that works w/ Linux.
In principle, an iSCSI target takes 3-5 times less CPU power to run than NFS does. Also, NFS sucks in a number of ways, performance isn't really that good, filesystem semantics aren't quite right.
Advocates of iSCSI think that iSCSI appliances would appeal to people in the SOHO market, but the lack of a universal filesystem makes that a pipe dream. (+manageability problems)
Yeah, I could configure my extra machine as an NFS or Samba server, but that's not much of a hacking projhect. (If I do do this project, I probably will install GFS, have it mount itself and provide NFS and Samba to the non-Linux machines on the network.) Half of this is about screwing around w/ iSCSI, the other half is evaluation of GFS which we might want to use for a cluster system a few years from now.
Daryll Strauss wrote:
So, I'd like to see zeroconf really integrated in to FC5. I think it'll make network setup for a lot of users much easier.
So get working. There is a lot to do. And don't mention these foolish attempts of integration done by some other distributions.
What is needed is another daemon (or an extended and renamed mDNSResponder) which monitors the network and caches all entries for the appropriate time. The daemon needs a programming interface so that a new NSS module can be used to query the daemon's cache of known addresses and probably also to initiate the daemon to send out requests for information which isn't in the cache.
I talked with the author of the current (unusable) nss_mdns module and he plans to do something like this after I explained it to him. But I haven't seen any progress.
On 6/5/05, Ulrich Drepper drepper@redhat.com wrote:
So get working. There is a lot to do. And don't mention these foolish attempts of integration done by some other distributions.
What is needed is another daemon (or an extended and renamed mDNSResponder) which monitors the network and caches all entries for the appropriate time. The daemon needs a programming interface so that a new NSS module can be used to query the daemon's cache of known addresses and probably also to initiate the daemon to send out requests for information which isn't in the cache.
I talked with the author of the current (unusable) nss_mdns module and he plans to do something like this after I explained it to him. But I haven't seen any progress.
Are you referring to the nss_mdns module that comes bundled with Apple's own implementation of Zeroconf/Rendezvous/Bonjour?
Felipe Alfaro Solana wrote:
Are you referring to the nss_mdns module that comes bundled with Apple's own implementation of Zeroconf/Rendezvous/Bonjour?
No, certainly not. Search freshmeat for nss_mdns, there is a module written for Linux.
Hi Ulrich,
On Sat, 2005-06-04 at 17:21 -0700, Ulrich Drepper wrote:
Daryll Strauss wrote:
So, I'd like to see zeroconf really integrated in to FC5. I think it'll make network setup for a lot of users much easier.
So get working. There is a lot to do. And don't mention these foolish attempts of integration done by some other distributions.
What is needed is another daemon (or an extended and renamed mDNSResponder) which monitors the network and caches all entries for the appropriate time. The daemon needs a programming interface so that a new NSS module can be used to query the daemon's cache of known addresses and probably also to initiate the daemon to send out requests for information which isn't in the cache.
I talked with the author of the current (unusable) nss_mdns module and he plans to do something like this after I explained it to him. But I haven't seen any progress.
It seems like the nss-mdns author has made some progress on this. The latest version allows queries to be directed through Avahi's mDNS responder (the responder in FC5), meaning responses are cached directly etc.
Any opinions on this implementation and whether or not it would be appropriate to include in FC5?
From a quick look at the code, one of my initial concerns is that, for every query, the module opens a new connection with the daemon and opens the /etc/mdns.allow file.
At the very least, though, it looks like progress in the direction you suggested.
Cheers, Mark.
P.S. - Bastien points out his packaging of the 0.6 version:
http://files.hadess.net/redhat/perso/source/nss-mdns-0.6-1.src.rpm
Might be a useful starting point for anyone wanting to package the 0.7 version with --enable-avahi
Mark McLoughlin wrote:
At the very least, though, it looks like progress in the direction you suggested.
Yes, it's certainly a step in the right direction. But I don't think we're there yet. At least the last time I looked. Unfortunately I cannot devote any time on investigating this.
If somebody is really interested, I think the hardest problems are handled now. So, look at it, analyze it, describe the implementation, fix it up/optimize it.
Mark McLoughlin <markmc <at> redhat.com> writes:
Hi Ulrich, It seems like the nss-mdns author has made some progress on this. The latest version allows queries to be directed through Avahi's mDNS responder (the responder in FC5), meaning responses are cached directly etc.
I have posted the latest version of the nss_mdns package in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172869
The nss_mdns module now only works if avahi is present and running (it will not do any lookups by itself).
My colleague Ezio has also written a more solid script to enable/disable the mdns bits in /etc/nsswitch.conf. It might be useful using some config option from /etc/sysconfig/network to know whether to enable it or not.
Hopefully we can get this in Fedora Core itself, rather than the Extras.
-- Bastien Nocera hadess@hadess.net
devel@lists.stg.fedoraproject.org
-
Bastien Nocera -
Daryll Strauss -
Felipe Alfaro Solana -
Mark McLoughlin -
Paul A Houle -
Ulrich Drepper