> On Aug 2, 2017, at 10:02 AM, Chuck Lever <[email protected]> wrote: > >> >> On Aug 1, 2017, at 8:40 PM, Ian Kent <[email protected]> wrote: >> >> On 07/06/17 23:55, J. Bruce Fields wrote: >>> So if it's not too depressing I'd be curious what went wrong--did this >>> turn out to be harder than we thought to get stable, or are people happy >>> enough with automounting, or did we just not do a good job of explaining >>> it to people that might use it, or some combination of all those? >> >> Having had to setup a test environment to check how things work a couple of >> times I must admit I found it a bit difficult to use. But perhaps that's >> because a test setup needs an LDAP server and a DNS forwarding server for >> the SRV records. >> >> Now I'm wondering if it would be worth adding some (quite a bit actually) of >> this to autofs. >> >> The problem that comes to mind is that to eliminate the need for the FedFS >> management utilities would mean a fair amount of work in autofs. Then there's >> the need for an nfsref(8) that supports FedFS referrals which probably >> doesn't >> quite fit in autofs and without it the rest doesn't seem worth doing. >> >> My thoughts about what I can do are still forming and now I'm wondering what >> others that care about this functionality think about it. > > We wouldn't carry all of the FedFS functionality forward. Basically > everything that is related to LDAP would be deprecated. > > There are two main pieces left. > > -> The DNS SRV piece needs either mount.fedfs or equivalent autofs > functionality. The tool for managing domain roots is nothing more > than syntactic sugar. No need to carry it forward. > > -> nfsref can manage basic referrals, which don't require any LDAP > support. nfsref and the junction library could be moved into nfs-utils > to support basic referrals. > > In other words the only piece autofs needs is support for /nfs4. > The NFS-server piece would reside in nfs-utils. > > Walking away from all of it is an option too.
I see that openldap-server is deprecated in RHEL 7.4: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html The FedFS LDAP components relied on openldap-server, so I guess it's a good thing they are going away too ;-) >> Thoughts? >> >>> >>> --b. >>> >>> On Fri, Jun 02, 2017 at 11:01:05AM -0400, Chuck Lever wrote: >>>> Upstream fedfs-utils has not been under active development for >>>> two years or more, and there is a scant user base. I'd like to >>>> propose making 0.10 the final major release of fedfs-utils. >>>> >>>> The plan: >>>> >>>> - Since 0.10 is in at least one major enterprise distribution, >>>> I will remain available to integrate security fixes and make >>>> new minor releases in the 0.10 line, as needed, for one to >>>> two more years. >>>> >>>> - Retire and remove fedfs-utils from upstream mirror distros >>>> such as Fedora rawhide. >>>> >>>> - Transfer utilities such as nfsref into nfs-utils, with >>>> support for FedFS junctions removed. >>>> >>>> - Announcements of the change in status will be made on >>>> fedfs-utils-announce and on the wiki.linux-nfs.org site. >>>> >>>> >>>> >>>> Comments welcome! >>>> >>>> >>>> -- >>>> Chuck Lever >>>> >>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >>>> the body of a message to [email protected] >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> _______________________________________________ >>> fedfs-utils-devel mailing list >>> [email protected] >>> https://oss.oracle.com/mailman/listinfo/fedfs-utils-devel > > -- > Chuck Lever > > > > > _______________________________________________ > fedfs-utils-devel mailing list > [email protected] > https://oss.oracle.com/mailman/listinfo/fedfs-utils-devel -- Chuck Lever _______________________________________________ fedfs-utils-devel mailing list [email protected] https://oss.oracle.com/mailman/listinfo/fedfs-utils-devel
