Due to logistical problems, I abandoned ptlocal and decided to go with creating an LDAP proxy for ptserver.
Currently, I have a version that seems to work fine with AD4UNIX extended schema Active Directory style LDAP. If you recall, ptproxy was created by Volker Lendecke, but became license encumbered and is more or less on hold as far as I know. Ptproxy works great, but has samba code. Even if the samba vs openafs licensing issue is resolve, openldap is a slightly more universal approach to the same problems. Openldap can successfully connect to an AD server and retrieve the same information as the samba ptproxy implementation, and doesnt require joining the machine to the domain- but granted searching an AD generally requires having an ldap searcher account in the AD that has the right to dump/search the whole tree. I created ptsldap completely from openafs code, and from the ldap.h manpages, but no raw code was copied. As far as I know, it should be compatible with the openafs licensing, but I'd like to know for sure. If it winds up being compatible, my employer (iowa state university) is talking about being willing to release it back into the openafs tree. It's not a guarantee, but I'd say the liklihood is high. One further license question I have is in trying to implement support for reading /etc/ldap.conf, it comes to mind that nss_ldap has a whole section of code devoted towards reading that file and setting up the connection and doing searches - with failover already accounted for.. Rewriting that code wouldn't be my favorite use of time, but obviously copying some of that code might be a problem for the licensing issue, though it appears to be under LGPL. Now keep in mind this code is no where near fully tested, nor optimized. It ditches a lot of support (like creating groups and users, etc), but all that is potentially on the horizon- though in our current implementation, we do not and will not be writing to the active directory from the unix side of things. As far as I know, there are more than a handful of people and organizations looking to integrate OpenAFS with ActiveDirectory and/or ldap. I think this is an important step in the right direction, though by no means a final solution. Are there any people on the list who could comment about these licensing questions? -- Brett Trotter Engineering Computer Support Services Iowa State University - 2240 Hoover Hall tel: 515.294.2897 email: [EMAIL PROTECTED] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
