Re: RFC: drop kerberos4-support?
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ You're correct, although it's very close. It will be Russ possible with the 1.4.1 release (and is almost possible Russ right now but openafs-krb5 is too old; I'm waiting for the Russ 1.4.1 release to retire the openafs-krb5 package and package Russ aklog and asetkey with openafs). So it will be possible for Russ etch. The aklog in openafs will also support krb524d. I can't seem to find it in my version ;-( However, I now got krb524 working with Heimdal. I had to insert enable-524 = true in /var/lib/heimdal-kdc/kdc.conf (the man page for kdc lead me to believe this was the default). and add: [login] enable-524 = true in /etc/krb5.conf -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
Brian May [EMAIL PROTECTED] writes: Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ You're correct, although it's very close. It will be Russ possible with the 1.4.1 release (and is almost possible Russ right now but openafs-krb5 is too old; I'm waiting for the Russ 1.4.1 release to retire the openafs-krb5 package and package Russ aklog and asetkey with openafs). So it will be possible for Russ etch. The aklog in openafs will also support krb524d. I can't seem to find it in my version ;-( Are you looking at the original upstream source? aklog isn't included in the openafs packages in Debian because openafs-krb5 still contains aklog. That's one of the things that will change in the 1.4.1 packages. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
Russ == Russ Allbery [EMAIL PROTECTED] writes: Russ Brian May [EMAIL PROTECTED] writes: * Find out what is required to keep AFS support working (assuming I don't already have it). Russ Well, what sort of AFS environment? The answer is different Russ if you mean AFS using kaserver than if you mean AFS using Russ krb524 or native K5. Ideally that would be AFS environment that our users require. However, I would be happy is that was AFS environment that will work without recompilation of Debian packages. My preference would be native K5. However, I get the impression that isn't yet possible with openafs in Debian (unless I am badly confused). So if using krb524 works, then hopefully that would be OK. (when I last tested it I couldn't get it to work with anything except krb4 support in the KDC, but I may have been doing something wrong...) -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
Brian May [EMAIL PROTECTED] writes: Ideally that would be AFS environment that our users require. However, I would be happy is that was AFS environment that will work without recompilation of Debian packages. Right now, the AFS packages in Debian will work with either native K4 or with krb524, although the server support for native K4 isn't in Debian. My preference would be native K5. However, I get the impression that isn't yet possible with openafs in Debian (unless I am badly confused). You're correct, although it's very close. It will be possible with the 1.4.1 release (and is almost possible right now but openafs-krb5 is too old; I'm waiting for the 1.4.1 release to retire the openafs-krb5 package and package aklog and asetkey with openafs). So it will be possible for etch. The aklog in openafs will also support krb524d. However, dropping KTH Kerberos loses the ability to work with native K4 easily because of afslog (klog would still be available, as would the PAM modules, but not something that worked from a K4 ticket cache). We're already building our own version of afslog for K4 at Stanford, though, so I'm not sure how much that would really impact anyone and what sites (if any) would be affected. So if using krb524 works, then hopefully that would be OK. (when I last tested it I couldn't get it to work with anything except krb4 support in the KDC, but I may have been doing something wrong...) README.servers in the openafs-fileserver package explains how to set up OpenAFS with Kerberos v5 authentication via krb524d, and at least with the packages in sid it's been fairly well-tested. The setup scripts needed a bit of work that I just recently finished. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
Steve == Steve Langasek [EMAIL PROTECTED] writes: Not only that, but it conflicts with key krb4 libraries (libroken and libsl) IIRC. Steve More likely: Conflicts/Replaces/Provides. I expect that if Steve the Heimdal versions of libroken and libsl conflict with Steve the existing krb4 versions, it's because they are in fact a Steve compatible replacement. In theory at least... Steve Hmm; looking at the symbol tables of each library, we have Steve the following symbols that were present in the krb4 version Steve of libroken and have been dropped in the heimdal version: Steve get_progname roken_glob roken_globfree set_progname The latest Heimdal version might have renamed these to glob() and globfree(), hence clashing with the libc6 version of these functions. Yuck. There should be configure tests to prevent these, but I am not convinced they are working, as the header files were clashing (I don't know what is going on here). I can't remember now why our workaround was to rename the functions instead of removing them. It is possible the roken version has required features not in libc6. Double yuck. libroken is probably the most important library. I suspect no package other then Heimdal uses the functions in question, but I can't guarantee it. Steve At least get_progname and set_progname were exported as Steve part of the published API, so libroken16-heimdal can't Steve claim to provide libroken16-kerberos4kth. It would be nice Steve if upstream changed the soname, though, to distinguish it Steve from other, known-incompatible versions out there. At least some of these changes look like they are Debian specific, not sure. So upstream changing the soname may not be appropriate. Anyway, here is a quick scan of dependencies, at least in sarge: (note: I filtered out Heimdal and kerberos4kth from these lists) snoopy:~# apt-cache rdepends libroken16-kerberos4kth libroken16-kerberos4kth Reverse Depends: sasl2-bin lsh-server libsasl2-modules-gssapi-heimdal evolution-exchange arla snoopy:~# apt-cache rdepends libsl0-kerberos4kth libsl0-kerberos4kth Reverse Depends: arla snoopy:~# apt-cache rdepends libss0-kerberos4kth libss0-kerberos4kth Reverse Depends: [ none ] snoopy:~# apt-cache rdepends libotp0-kerberos4kth libotp0-kerberos4kth Reverse Depends: [ none ] snoopy:~# apt-cache rdepends libkrb-1-kerberos4kth libkrb-1-kerberos4kth Reverse Depends: sasl2-bin libsasl2-modules-kerberos-heimdal evolution-exchange arla Build-depends kerberos4kth-dev: Package: arla Package: cyrus-sasl2 (note: just because a dependency is listed doesn't mean the library is *used* by application. I suspect many applications blindly link using -lkrb5 -lsl -lroken, etc, because antique versions of libtool couldn't handle interdependencies between shared libraries properly, and there seems to be a lot of code that assumes libtool is still broken - in actual fact -lkrb5 is all that is required). My proposed plan of action seems to be: * Work out this glob() and globfree() business, and make sure I am not creating duplicate symbols or using a version that is incompatible. * Upload Heimdal. * Rebuild above packages. * If packages don't rebuild then it may be because it requires krb4 support = drop krb4 support (cyrus-sasl?), or entire package (arla?). * Drop kerberos4kth. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC: drop kerberos4-support?
Hi, while my regular clean up RC-bugs-work I noticed that the package krb4 is RC-buggy in more than one way. On further investigation, I also noticed that kerberos 4 is dying right now, and also that the bugs are not as easy to fix. Also, upstream doesn't look too active according to http://www.pdc.kth.se/kth-krb/. For this reason, I started to consider to push dropping of the krb4-package from unstable. This has some influence on the heimdal-package, and also on the release notes for migration issue. However, I personally tend to go that way. Please see bug #315059 for some discussion; especially, heimdal in experimental stopped to depend on kerberos 4. Well, my question is simple: should I push packages to go away from kerberos-4-support? Unless there is a good reason to do not, I would start to push into that direction. And of course, feel free to send me things that need to be changed. As usual, the maintainers have a special say in everything (that's why I Cced them). :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
Andreas Barth [EMAIL PROTECTED] writes: Well, my question is simple: should I push packages to go away from kerberos-4-support? Unless there is a good reason to do not, I would start to push into that direction. And of course, feel free to send me things that need to be changed. As usual, the maintainers have a special say in everything (that's why I Cced them). :) I think it's time to encourage maintainers to start thinking about this, as the next major release of MIT Kerberos is also going to drop Kerberos v4 support as of May of 2006. Kerberos 4 support will still be there in the MIT package until at least that time, and there are some sites who are still in the process of transitioning away, so I wouldn't want to see too many things disappear too quickly, but it's certainly time to think about how to drop it over time. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
Andreas == Andreas Barth [EMAIL PROTECTED] writes: Andreas Hi, while my regular clean up RC-bugs-work I noticed Andreas that the package krb4 is RC-buggy in more than one Andreas way. On further investigation, I also noticed that Andreas kerberos 4 is dying right now, and also that the bugs are Andreas not as easy to fix. Also, upstream doesn't look too Andreas active according to http://www.pdc.kth.se/kth-krb/. For Andreas this reason, I started to consider to push dropping of Andreas the krb4-package from unstable. This has some influence Andreas on the heimdal-package, and also on the release notes for Andreas migration issue. However, I personally tend to go that Andreas way. Please see bug #315059 for some discussion; Andreas especially, heimdal in experimental stopped to depend on Andreas kerberos 4. Not only that, but it conflicts with key krb4 libraries (libroken and libsl) IIRC. Andreas Well, my question is simple: should I push packages to go Andreas away from kerberos-4-support? Unless there is a good Andreas reason to do not, I would start to push into that Andreas direction. And of course, feel free to send me things Andreas that need to be changed. As usual, the maintainers have a Andreas special say in everything (that's why I Cced them). :) Ideally I thin the krb4 maintainer should have same say. However I haven't heard from him. I think there several things I want to do before uploading Heimdal to unstable as it is in experimental: * Find out what packages will break. * Find out what packages will still be broken even after recompiling. * Find out what is required to keep AFS support working (assuming I don't already have it). -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
Brian May [EMAIL PROTECTED] writes: * Find out what is required to keep AFS support working (assuming I don't already have it). Well, what sort of AFS environment? The answer is different if you mean AFS using kaserver than if you mean AFS using krb524 or native K5. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
* Russ Allbery ([EMAIL PROTECTED]) [05 21:47]: Andreas Barth [EMAIL PROTECTED] writes: Well, my question is simple: should I push packages to go away from kerberos-4-support? Unless there is a good reason to do not, I would start to push into that direction. And of course, feel free to send me things that need to be changed. As usual, the maintainers have a special say in everything (that's why I Cced them). :) I think it's time to encourage maintainers to start thinking about this, as the next major release of MIT Kerberos is also going to drop Kerberos v4 support as of May of 2006. Kerberos 4 support will still be there in the MIT package until at least that time, and there are some sites who are still in the process of transitioning away, so I wouldn't want to see too many things disappear too quickly, but it's certainly time to think about how to drop it over time. You think that December 2006 (the expected release time of etch) is too early to drop Kerberos 4? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
Andreas Barth [EMAIL PROTECTED] writes: You think that December 2006 (the expected release time of etch) is too early to drop Kerberos 4? I'm not sure. I think it's going to be tight for some people, but on the other hand not shipping etch with MIT Kerberos 1.5 is not exactly appealing. I expect, though, that Stanford will be in a situation where that will be fine with us by December, and we're historically one of the slower sites to migrate, so maybe it will be okay. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
* Russ Allbery ([EMAIL PROTECTED]) [05 23:26]: Andreas Barth [EMAIL PROTECTED] writes: You think that December 2006 (the expected release time of etch) is too early to drop Kerberos 4? I'm not sure. I think it's going to be tight for some people, but on the other hand not shipping etch with MIT Kerberos 1.5 is not exactly appealing. I expect, though, that Stanford will be in a situation where that will be fine with us by December, and we're historically one of the slower sites to migrate, so maybe it will be okay. On the other hand, sarge will be supported till December 2007, so this should give enough time for migration, provided we warn of this scenario properly. But perhaps it's better to reconsider it again, as we have enough time to decide. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
On Fri, Nov 11, 2005 at 11:19:07PM +0100, Andreas Barth wrote: * Russ Allbery ([EMAIL PROTECTED]) [05 21:47]: Andreas Barth [EMAIL PROTECTED] writes: Well, my question is simple: should I push packages to go away from kerberos-4-support? Unless there is a good reason to do not, I would start to push into that direction. And of course, feel free to send me things that need to be changed. As usual, the maintainers have a special say in everything (that's why I Cced them). :) I think it's time to encourage maintainers to start thinking about this, as the next major release of MIT Kerberos is also going to drop Kerberos v4 support as of May of 2006. Kerberos 4 support will still be there in the MIT package until at least that time, and there are some sites who are still in the process of transitioning away, so I wouldn't want to see too many things disappear too quickly, but it's certainly time to think about how to drop it over time. You think that December 2006 (the expected release time of etch) is too early to drop Kerberos 4? Note that dropping the krb4 source package does not require dropping Kerberos 4 support from the MIT Kerberos packages, either; and as the MIT Kerberos version doesn't seem to have any RC bugs at present regarding the status of its Kerberos 4 support, there doesn't seem to be any reason to cut it before upstream does. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFC: drop kerberos4-support?
On Sat, Nov 12, 2005 at 07:36:46AM +1100, Brian May wrote: Andreas == Andreas Barth [EMAIL PROTECTED] writes: Andreas Hi, while my regular clean up RC-bugs-work I noticed Andreas that the package krb4 is RC-buggy in more than one Andreas way. On further investigation, I also noticed that Andreas kerberos 4 is dying right now, and also that the bugs are Andreas not as easy to fix. Also, upstream doesn't look too Andreas active according to http://www.pdc.kth.se/kth-krb/. For Andreas this reason, I started to consider to push dropping of Andreas the krb4-package from unstable. This has some influence Andreas on the heimdal-package, and also on the release notes for Andreas migration issue. However, I personally tend to go that Andreas way. Please see bug #315059 for some discussion; Andreas especially, heimdal in experimental stopped to depend on Andreas kerberos 4. Not only that, but it conflicts with key krb4 libraries (libroken and libsl) IIRC. More likely: Conflicts/Replaces/Provides. I expect that if the Heimdal versions of libroken and libsl conflict with the existing krb4 versions, it's because they are in fact a compatible replacement. Hmm; looking at the symbol tables of each library, we have the following symbols that were present in the krb4 version of libroken and have been dropped in the heimdal version: get_progname roken_glob roken_globfree set_progname At least get_progname and set_progname were exported as part of the published API, so libroken16-heimdal can't claim to provide libroken16-kerberos4kth. It would be nice if upstream changed the soname, though, to distinguish it from other, known-incompatible versions out there. For libsl, the only symbol dropped is get_progname, and that doesn't seem to be part of the exported interface for libsl0 as of 1.2.2-11.3. So it may be valid for libsl0-heimdal to maintain package compatibility with libsl0-kerberos4kth, but this probably needs to be confirmed upstream. For libotp0, no symbols were dropped. So libotp0-heimdal should either Conflicts:/Replaces:/Provides: libotp0-kerberos4kth, or simply keep the same libotp0-kerberos4kth name. The latter is actually more useful, given that existing packages that depend on libotp0-kerberos4kth have a *versioned* dependency that can't be satisfied by the use of Provides. If all this is done correctly (libroken soname change, keep the historical package names of the other two libs), users who still need krb4 support locally should be able to keep around the krb4 packages from sarge as long as they need to while still being able to install heimdal from etch. Ideally I thin the krb4 maintainer should have same say. However I haven't heard from him. Well, normally package maintainers have a say in the removal of their own packages by responding to the RC bugs in them... I think there several things I want to do before uploading Heimdal to unstable as it is in experimental: * Find out what packages will break. By the update of heimdal, it should only be packages depending on libgssapi1-heimdal, I guess? By the removal of krb4: (old) heimdal, and libsasl2-modules-kerberos-heimdal (from cyrus-sasl2). The only other packages in the archive with a dependency on krb4 today are lsh-server, libsasl2-modules-gssapi-heimdal, and sasl2-bin, which pull in the dependency via heimdal; and a build of samba which seems to have picked up a gratuitous krb4 dependency when built on my system... * Find out what packages will still be broken even after recompiling. If anything has to be recompiled which *doesn't* depend on libgssapi1-heimdal, then that's a bug that needs to be fixed in heimdal first... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
