1st package, needs a sponsor Spec URL: http://www.pingo.org/aai/heimdal/heimdal.spec SRPM URL: http://www.pingo.org/aai/heimdal/heimdal-1.3.3-1.arnes.src.rpm Description: Kerberos 5 is a network authentication and single sign-on system. Heimdal is a free Kerberos 5 implementation without export restrictions written from the spec (rfc1510 and successors) including advanced features like thread safety, IPv6, master-slave replication of Kerberos Key Distribution Center server and support for ticket delegation (S4U2Self, S4U2Proxy). This package can coexist with MIT Kerberos 5 packages. Hesiod is disabled by default since it is deemed too big a security risk by the packager.
I've been meaning to comment on this bug for a while now. Just getting back to it. I recently took the specfile that you came up with and modified it a bit to hopefully bring it more inline with Fedora packaging guidelines, but more importantly to turn it into something I was happy with distributing to our machines here. On that note, I'm sure there are more things that can be done to bring it up to par before inclusion in Fedora. First, the SRPM used to build the packages we're currently distributing to our clients: ftp://ftp.bx.psu.edu/software/yum/centos/5/source/heimdal-1.3.3-3.bx.src.rpm Offhand, a couple of things: 1) Heimdal is up to 1.4.1rc1, with a 1.4.1 release very soon according to Love. 2) Use %configure instead of ./configure 3) Change the way BuildRoot is defined, something like %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) 4) I'm not sure the Provides statements in the sub-packages are standard, or even do anything? Someone else may comment on those. 5) I disabled make check entirely, as it was failing for me on Centos 5.5, and I haven't had a chance to figure out why. 6) I redefine things like _bindir and _sbindir, among others, so that if we should ever someday make heimdal the default, or if someone wants something other than /usr/heimdal, changing that is as simple as changing %define hprefix %{_prefix}/heimdal at the top. Handling the coexistance of Heimdal with MIT krb is tricky either way, and I'm not sure if there's a pre-defined method of dealing with this in Fedora. I don't think using _prefix in %files is the right way to handle that (or rather, redefining _prefix). 7) I moved libexec to sbin. That's just a personal preference though. 8) The scriptlets (preun, postun, etc) should check $1 and modify their behavior accordingly. Side note: Maybe we could talk to the MIT folks at some point and see if they might be interested in using alternatives to handle the userland stuff like kinit, klist, etc? I'd be happy to discuss this further. I will probably be dropping my 1.4.1 specfile somewhere as soon as it's released.
*** Bug 452212 has been marked as a duplicate of this bug. ***
I note that Rok never responded to Andy's comment. A few folks have wanted to get Heimdal into Fedora and this is the second review ticket that's been filed, but for some reason things seem to stall out. What's happening with this one?
I'm keen for Heimdal to make it in to Fedora to make it more practical to have Samba4 in Fedora. This is because Samba4's Active Directory Domain Control functionality is unlikely to support another Kerberos distribution, but it is preferred not to use bundled libraries in Fedora. Currently Samba4 bundles Heimdal because we have custom patches to it, but in Ubuntu our Samba Team member Jelmer Vernooij also co-maintains Heimdal and has arranged that the versions be in sync, so that we can use system versions for at least some parts (with an aim to extend this so we don't bundle at all eventually).
(In reply to comment #3) > I note that Rok never responded to Andy's comment. A few folks have wanted to > get Heimdal into Fedora and this is the second review ticket that's been > filed, but for some reason things seem to stall out. Actually I wrote privately to Andy, I'm attaching a snippet: ================================================================ Regarding the libexec vs. sbin... I think libexec is for executables that are not supposed to be run by a (super)user directly but by other programmes. I'll check with the newest FHS since it's been some time since I've studied it. Other comments I agree with or need to study them closer :)). Fedora does some things differently and I plan to suport bith CentOS latest and Fedora with the same .src.rpm. Looking forward to your specs file as I plan to make use of it ;). ================================================================ > What's happening with this one? I'm just a packager here ;-). Not sure why Fedora ignored this package submission. On the Heimdal front I'm more or less waiting for Heimdal 1.4.1 final and Centos 6. Since it's been quite a long time since 1.4.1rc1 was released and interest seems to have picked up, I've prepared the new release: SRPMS: http://www.pingo.org/aai/heimdal/heimdal-1.4.1rc1-1.arnes.src.rpm Fedora14 i386 and x86_64 build: http://www.pingo.org/aai/heimdal/fedora14/
What's the status here? I'm getting connection timeouts trying to resolve www.pingo.org.
(In reply to comment #6) > What's the status here? I'm getting connection timeouts trying to resolve > www.pingo.org. pingo.org domain is currently unavailable (ISP changed the IP address of primary DNS for pingo.org with no warning). This will be resolved in the next couple of days. You can access the server by IP: http://194.249.18.75/aai/heimdal/
Looks like there are a couple bundled libraries in heimdal - libtommath - modified (packaged in Fedora), imath (not packaged), and apparently modified versions of editline and libgssapi. Also, I think we're going to need to use alternatives in Fedora to handle conflicts with MIT-Kerberos. EL6 may be a pickle, since RedHat is unlikely to make the necessary changes to their package. License audit is going to be fun.
(In reply to comment #8) > Looks like there are a couple bundled libraries in heimdal - libtommath - > modified (packaged in Fedora), imath (not packaged), and apparently modified > versions of editline and libgssapi. > > License audit is going to be fun. I've not reviewd the licenses (yet) :). > Also, I think we're going to need to use alternatives in Fedora to handle > conflicts with MIT-Kerberos. EL6 may be a pickle, since RedHat is unlikely to > make the necessary changes to their package. Hmm... I'd prefer to have the same spec for both Fedora and RHEL/CentOS but if needed I'll split them. In current version Heimdal and MIT coexist, MIT binaries are first in the search path meaning they have precedence. I'm OK with this solution. Alternatives might be nice but I doubt Fedora will want to invest any time in this.
I would also prefer that they stay separate. Using alternatives to switch out things like kinit, kadmin, etc would probably have unintended consequences. The command line options to those tools is very different, for example. Unless Fedora decides to replace MIT with Heimdal entirely, I think keeping heimdal separate under /usr/heimdal would be preferable. Regarding bundled libraries, it might be a good idea to bring this up on the heimdal list and see what folks there have to say.
/usr/heimdal is just not going to be acceptable in Fedora as isn't doesn't follow the FHS. You maybe could try to ask for an exception from FESCO.
Created attachment 474690 [details] License analysis I've attached the output of a fossology license analysis. Most things are BSD or BSD-like, but there are a few things to check out. Most of the GPL items are actually bison generated files. 1127 Show BSD-style 98 Show BSD 79 Show FSF 26 Show Public-domain-claim 21 Show GPL_v2+ 10 Show GPL-exception 8 Show Cisco-style 6 Show IETF 6 Show MIT-style 3 Show MIT 3 Show NetBSD 2 Show GPL 2 Show See-doc(OTHER) 2 Show X11 1 Show BSD-possibility 1 Show Microsoft-possibility 1 Show MIT-possibility 1 Show OSF-style 1 Show Public-domain-ref 1 Show RSA-Security 1 Show Trademark-ref 1 Show UnclassifiedLicense
To actually use the system sqlite library, it appears you need to pass this to configure: --with-sqlite=/usr. I would be more happy with a patch that allowed you to remove lib/sqlite in %prep as well.
Looks like imath has been dropped in git master. readline can be used instead of editline. The gssapi lib is a heimdal library. That leaves libtommath. I've pointed heimdal to the new libtommath upstream so hopefully we can get them integrated.
I would love to get Heimdal into Fedora. Looking at the discussion above, in order to reconcile with MIT, we have the following options: 1. Install to /usr/heimdal. This will require an exception from FESCo. 2. Rename the Heimdal files to not conflict with MIT. Eg. "/usr/bin/kinit.heimdal", "kadmin.heimdal", etc. Use alternatives to switch between the two Kerberos implementations. This allows for side-by-side installations with MIT. 3. Use Conflicts: with the appropriate MIT packages. You have to choose to install one or the other. I imagine that #1 does not have a good chance of passing FESCo. Does #3 break useful things like pam_krb5? #2 seems like the path of least resistance to me... more experienced packagers, please weigh in your opinions. Relevant links FYI: https://fedoraproject.org/wiki/Packaging:Conflicts - Conflicts Guidelines http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482528 - Similar bug in Debian
I think this is exactly why "alternatives" was developed, so #2 is the appropriate solution. This assumes that the commands for heimdal and MIT kerberos take essentially the same command line arguments. Is that correct? Shared libraries may be a trickier issue.
Some of the commands are similar, some aren't. Some are drastically different. kadmin is different, kinit is different, klist is most certainly different. If there are any scripts that use the MIT commands that expect a certain command line syntax, they will most certainly break with Heimdal. Unless the user of alternatives doesn't require that the syntax be identical, then I would be in favor of #2.
Yeah, the commands are certainly different. I'm pretty sure most of the scripts that are distributed with Fedora will specify the full paths. For example, http://pkgs.fedoraproject.org/gitweb/?p=krb5.git;f=kadmind.init;hb=refs/heads/master specifies "/usr/sbin/kadmind". I prefer not to break user-written scripts, but on the other hand, if a user runs "alternatives", imho it is their responsibility to verify that this will not break their own user-written code. (In reply to comment #16) > Shared libraries may be a trickier issue. If I understand the above discussion correctly, the two packages (MIT and Heimdal) can be installed side-by-side "out of the box", and it is only the names of the binaries themselves that conflict. Right?
Fair enough. You use alternatives to switch to heimdal, then you take responsibility for things breaking. I like it. So for binaries that conflict, rename them to foo.heimdal. I guess we would also need the krb5-* package folks to do the same? What about man pages? As far as libraries go, only conflict I see right now is libgssapi. libgssapi currently provides that, and that's the citi nfsv4 version. I'm really wondering if we should just use Conflicts instead. Would avoid the need to use alternatives and the hassle of dealing with man pages and such. If someone installs heimdal, we could assume the user knows what they're doing.
Created attachment 488277 [details] conflicts between MIT and heimdal An attempt at a list of conflicts between MIT and Heimdal.
In my opinion the /usr/heimdal is the most compatible option. Alternatives are used when packages are similar. I dare to say that Heimdal and MIT Kerberos are too different. If nothing else the API in libraries is not binary compatible and applications linked with MIT Kerberos won't be happy with Heimdal libraries. Same goes for using Conflicts. Some applications will need to have MIT Kerberos libraries installed. Of course I'm very interested in getting Heimdal into Fedora and will use whatever option is prefered by Fedora.
(In reply to comment #20) > Created attachment 488277 [details] > conflicts between MIT and heimdal > > An attempt at a list of conflicts between MIT and Heimdal. Thanks, that is a useful list. Looks like it is more complicated than simply renaming the binaries. I've filed https://fedorahosted.org/fesco/ticket/577 so that we can at least know whether /usr/heimdal is viable.
I've put a (heavily) modified version of the package here: http://www.cora.nwra.com/~orion/fedora/heimdal-1.4.1rc2-1.fc14.src.rpm http://www.cora.nwra.com/~orion/fedora/heimdal.spec This starts some of the work needed towards using alternatives in that it renames conflicting files. This is able to be installed in parallel to the MIT krb5-* packages. Many more things need to be done, including: - Set up alternatives. - Set up alternatives for the MIT krb5 package. - Decide what to do about the other utilities (e.g.: ftp, login, pagsh, rcp, rsh, su, telnet) that conflict with other packages. - Heimdal installs a couple items in different locations than MIT does (e.g. /usr/sbin/kadmin vs. /usr/bin/kadmin). Should these be aligned? - test, test, test.
(In reply to comment #23) > I've put a (heavily) modified version of the package here: Cool, thanks for putting this together. Rok, as the official submitter, are you interested in merging these changes in? Here are my initial comments. IMHO it is more straightforward to use what you've done with libdir and mirror that in includedir. The conflicts guidelines on the wiki says "Header Name Conflicts - Put the headers in a subdirectory of /usr/include". So, we should use, eg. /usr/include/heimdal/gssapi/gssapi.h instead of /usr/include/gssapi.heimdal/gssapi.h. This gets even more complicated when there is stuff like /usr/include/krb5.h.heimdal and /usr/include/gssapi.h.heimdal . IMHO, just put these all in a subdirectory and be done with it. I.e. --includedir=%{_includedir}/heimdal There are some other things that were the result of redefining %{_prefix} --with-openssl=/usr \ --with-openldap=/usr \ --with-readline-include=/usr/include/readline \ --with-readline-lib=%{_libdir} \ --with-sqlite3=/usr \ These can go back to using macros. Eg --with-openssl = %{_prefix} , or --with-readline-include = %{_includedir}/readline > - Decide what to do about the other utilities (e.g.: ftp, login, pagsh, rcp, > rsh, su, telnet) that conflict with other packages. MIT puts these utilities in krb5-appl-clients. We could break Heimdal's versions into a similar sub-package.
* Wed Mar 30 2011 Orion Poplawksi <orion.com> - 1.4.1rc2-2 - Move includes to /usr/include/heimdal - Use more macros in configure command http://www.cora.nwra.com/~orion/fedora/heimdal-1.4.1rc2-1.fc14.src.rpm http://www.cora.nwra.com/~orion/fedora/heimdal.spec Interesting that krb5-appl-clients uses /usr/kerberos still.
(In reply to comment #23) > - Heimdal installs a couple items in different locations than MIT does (e.g. > /usr/sbin/kadmin vs. /usr/bin/kadmin). Should these be aligned? Yeah, kadmin and ktutil can move from /usr/sbin to /usr/bin. These don't require local root access, and this matches krb5-workstation's layout. (In reply to comment #25) > * Wed Mar 30 2011 Orion Poplawksi <orion.com> - 1.4.1rc2-2 Thanks. We can also now drop Source4 and 5, heimdal.sh and heimdal.csh, from profile.d in heimdal-libs. I'm looking over http://fedoraproject.org/wiki/Packaging:Alternatives, and I guess if we ever want this to work fully we'll need nalin to agree to use alternatives in MIT as well.
Submitted bug 692606 to ask for alternatives support in krb5.
* Thu Apr 7 2011 Orion Poplawksi <orion.com> - 1.4.1rc2-3 - Use %%{_libdir}/heimdal and environment-modules for kerberized apps - Add appl-{clients,servers} sub-packages http://www.cora.nwra.com/~orion/fedora/heimdal-1.4.1rc2-3.fc14.src.rpm http://www.cora.nwra.com/~orion/fedora/heimdal.spec It builds, but I have done no testing.
Just a note that 1.5 is now released.
I'm currently building with a version from GIT (would be 1.5.1). Need to fix some more things with the merge from Orions changes.
Note also that a number of changes will need to be done for systemd in Fedora 15+.
AFAIK systemd: - has compatibility mode for legacy SysV init scripts - needs changes in upstream source-code to handle inetd style connection passing - is not mandatory - isn't available yet on CentOS 6 / RHEL What do others think about systemd? Do we need it, prefer it or don't like it? :-)
I'm releasing new packages for Fedora 15 x86_64: http://www.pingo.org/aai/heimdal/fedora15/ SRPMS: http://www.pingo.org/aai/heimdal/heimdal-1.5.1.pre20110912git-2.src.rpm Specs: http://www.pingo.org/aai/heimdal/heimdal.spec Quality status: It builds/installs on x86_64 :-) I'm going to test/fix/update in the next couple of days/weeks. Targets are: - Fedora 15 x86_64 - Fedora 15 i386 - CentOS 6 x86_64 Changelog: * Tue Sep 27 2011 Rok Papež, ARNES <aaa-podpora> - 1.5.1.pre20110912git-2 - FESCo updates: https://fedorahosted.org/fesco/ticket/577 - Implicit %Requires removed, rpmbuild can figure them out itself - Implicit %Provides removed, we are NOT compatible with krb5 - Enable hardened build: https://fedoraproject.org/wiki/Packaging:Guidelines#PIE https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags - Merged updates from Orion Poplawski
(In reply to comment #32) > AFAIK systemd: > - has compatibility mode for legacy SysV init scripts But for F16 packages are supposed to migrate to native systemd http://fedoraproject.org/wiki/Features/SysVtoSystemd > - needs changes in upstream source-code to handle inetd style connection > passing No idea > - is not mandatory Hard to say, but it is a goal for F16 and later. > - isn't available yet on CentOS 6 / RHEL True. You're going to need to support both :)
(In reply to comment #33) > I'm releasing new packages for Fedora 15 x86_64: > http://www.pingo.org/aai/heimdal/fedora15/ > > SRPMS: http://www.pingo.org/aai/heimdal/heimdal-1.5.1.pre20110912git-2.src.rpm > Specs: http://www.pingo.org/aai/heimdal/heimdal.spec This is looking good. One suggestion on handling conflicting binaries: With 1.5.1.pre20110912git-2, half the apps are renamed, and half are in /usr/lib/heimdal/bin . I'd rather we just go with ".heimdal" for everything. It will be clearer if everything follows the same convention, and it will be easier to use the man pages when everything's in the same directory. What do you think? Another thing to nail down before a formal review is the license tag. The GPL popped up on Orion's fossology run, but running git grep on master shows there are no GPL sources, so I think we can safely say "BSD and MIT". Still need to look into the bundled libraries listed above, and what would be involved to unbundle.
Heimdal 1.5.1 is released, rpms are here: http://fire1.pingo.org/aai/heimdal/fedora15/x86_64/ SRPMS: http://fire1.pingo.org/aai/heimdal/heimdal-1.5.1-1.fc15.src.rpm Specs: http://fire1.pingo.org/aai/heimdal/heimdal.spec Please test! I'm not sure I want to add .heimdal for everything. It's already too much typing (tabbing) :-). Opinions? Will look into license and bundled libraries.
(In reply to comment #36) > I'm not sure I want to add .heimdal for everything. It's already too much > typing (tabbing) :-). Opinions? Yeah, I am not excited about it. I do think .heimdal is the way to go for the long term... If we try to munge $PATH with /etc/profile.d/heimdal.sh, we're re-inventing the functionality that alternatives provides, in a less flexible way. I'm hoping we can try to get a solution on bug 692606. I mocked the SRPM on F15 i686, looks good here. One note: /etc/profile.d/heimdal.sh adds /usr/lib/heimdal/sbin/, but there's no such directory. Just normal "bin" is appropriate.
Heimdal 1.5.2 for Fedora 17 is released, rpms are here: http://www.pingo.org/aai/heimdal/fedora17/i386/ http://www.pingo.org/aai/heimdal/centos6/x86_64/ SRPMS: http://www.pingo.org/aai/heimdal/heimdal-1.5.2-3.fc17.src.rpm Specs: http://www.pingo.org/aai/heimdal/heimdal.spec Please test! There have been a lot of changes/updates. Changes: ============= - updated to upstream 1.5.2 - added support for Fedora 17 - fixed wrong PATH on x86_64 - fixed IPv6 and multiple interfaces bug in krb5_parse_address: https://bugzilla.redhat.com/show_bug.cgi?id=808147 - added support for .heimdal prefix to kcc - /usr/lib/heimdal/sbin/ is not added to the PATH - Libraries and source files licenses reviewed, everything looks OK - please find bashrc in documentation directory for creating aliases to Heimdal binaries, it makes life much easier
Just some quick comments: - rpmlint: heimdal.spec:425: W: macro-in-%changelog %Requires heimdal.spec:426: W: macro-in-%changelog %Provides heimdal.spec:31: W: mixed-use-of-spaces-and-tabs (spaces: line 31, tab: line 25) heimdal.spec: W: patch-not-applied Patch1: heimdal.missing-map.diff heimdal.spec: W: patch-not-applied Patch2: skip_tests.diff Drop the % from Requires/Provides in %changelog. - You want to use systemd init for Fedora, and probably instead of xinetd as well. - We're moving from db4 to libdb in rawhide - Drop the version requirements on the BRs, they are very old. Even EL5 has much newer versions. - We don't use ,s in License, need and or or and appropriate. Otherwise, nice to see some progress here.
Here's a somewhat different take: SRPMS: https://people.kth.se/~abo/tmp/heimdal/heimdal-1.5.2-3.fc18.kth.15.src.rpm Specs: https://people.kth.se/~abo/tmp/heimdal/heimdal.spec Feel free to use whatever you like from this. Changes/differences: * Installs in /usr/{bin,sbin,libexec}/ * Uses a heimdal- prefix instead of a .heimdal suffix, when necessary. * Binaries also in /usr/lib/heimdal/bin/ without a prefix. (Always /usr/lib, lib64 is only for libraries!) * An optional heimdal-path subpackage which adds the bin directory to PATH. * Split the unified service into multiple services - this makes it much easier to convert to systemd units later. * Add kdc.conf, move KDC config files to /etc, leave symlinks in /var/heimdal * PAM provides a file that's just like login.access, use that. ...and various small changes. I don't think "alternatives" are appropriate in this case because the binaries are not compatible enough. (Compare with java where it's very easy to switch between versions and implementations.)
The above didn't actually build on F18 (used EPEL as my test environment). Also, the prefix munge patch was broken. So here's another try: SRPMS: https://people.kth.se/~abo/tmp/heimdal/heimdal-1.5.2-3.fc18.kth.19.src.rpm Specs: https://people.kth.se/~abo/tmp/heimdal/heimdal.spec This builds on F18, but not on F19 for some texi related reason I don't understand. The patch to hack off "heimdal-" from argv[0] should work now. Also fixed a filename conflict with MIT. I'd rather not take over this request, but I could be comaintainer, especially for EPEL6.
Alexander and I are continuing work on this package. We've decided to try to package 1.5.3. This version is tagged in Git, but upstream did not provide tarballs for this release, so I generated one from the tag and placed it on fedorapeople.org. I've pushed my work here: https://gitorious.org/ktdreyer/heimdal-packaging . You can get it and build it with the following set of commands: $ git clone git://gitorious.org/ktdreyer/heimdal-packaging.git heimdal $ cd heimdal $ wget http://ktdreyer.fedorapeople.org/heimdal/heimdal-1.5.3.tar.xz $ fedpkg --dist f19 mockbuild The package builds fine on el6. Remaining issues before acceptance into Fedora: - Fix texi problems on Fedora 19 - Add systemd unit files - Test that this KDC actually works :) And my own personal TODO: ensure that we also get the recent patches from the tip of the heimdal-1-5-branch, so we're compatible with OpenAFS's rxkad-k5. Alexander (and others), are you ok with using Git/Gitorious to track changes on this package while we work out the remaining issues?
An update: Heimdal upstream is reluctant to issue a another formal 1.5 release, so we're packaging the tip of the heimdal-1-5-branch. Our package in Gitorious is basically ready to go except for a single issue. The final remaining issue is that Heimdal's bundled libtommath has been modified slightly (adding a couple new functions). Apparently this bundling/forking happened when the upstream libtommath author declared the project dead: https://list.sics.se/sympa/arc/heimdal-discuss/2011-01/msg00025.html Heimdal will not build against the libtommath-devel package in Fedora. Alexander has submitted a pull request to libtommath to get Heimdal's patches included: https://github.com/libtom/libtommath/pull/14
Rok - do you want to continue to be the owner of the review/package? Do you still need a sponsor?
Current libtommath pull request https://github.com/libtom/libtommath/pull/18
Hi Rok, Are you ok with Alexander and I taking this package over?
Yes, I'm OK with Ken and Alexander taking over the project. I've done some work on the new 1.5.3 for fedora 19, please feel free to grab whatever you find useable: SRPMS: http://net9.si/~rok/rpms/heimdal-1.5.3-1.fc19.src.rpm Specs: http://net9.si/~rok/rpms/heimdal.spec I'll help with the package as I find the time.... Orion: Can you arrange a sponsor for the RPM? That would really boost this project. I got the impression Fedora project wasn't interested in this package and would prefer for it to... hmm.... sleep forever ;))).
Ken is a packager (and a sponsor) so no worries there.
Excellent, looking forward to seeing Heimdal in Fedora :-)).
Heimdal 1.6 was branched yesterday. When 1.6 is tagged we will ship that. My work-in-progress update to the packaging is on the "1.6" branch in Gitorious. Note that we're still waiting on the merge between upstream libtommath and Heimdal's bundled copy, since this is the one thing that holds up this review. https://github.com/libtom/libtommath/pull/18
Can we consolidate this effort on Github or some similar site for spec files, patches, etc.. I'm planning to do some stuff with Heimdal and 389 server integration in the near future and Id like a uniform rpm file base to work with. The first set would be a mostly Perl based part is a password sync plugin set. The first script would be via a kpasswdd policy check script that would change the password for the user in 389 server and allow 389 server to check it via it's internal policy check. The second would be a slightly more ambitious plugin for 389 server to update the users password in a Heimdal KDC without creating a loop. The next I'm considering writing a Perl based kadmin command proxy script using either Expect or Heimdal::Kadm5 that would try to emulate the MIT kadmin command syntax used by FreeIPA but thats a bit more ambitious.
(In reply to Paul Robert Marino from comment #51) > Can we consolidate this effort on Github or some similar site for spec > files, patches, etc.. Sure. Our latest spec file and package is on Gitorious. https://gitorious.org/ktdreyer/heimdal-packaging Regarding the bundled libtommath, the libtommath library in Heimdal's master branch is much closer to upstream libtommath now, but it's still not 100% there. I've requested a bundling exception from the FPC: https://fedorahosted.org/fpc/ticket/387 I would appreciate it if the interested parties could add themselves as CC's to that FPC trac ticket.
Better waiting for the merge on github and build from snapshot? I'm maintaining dropbear in Fedora which also depends on libtom(I just unbundled libtom* libraries in Sep)
Hi Christopher, Alexander's latest pull request on GitHub (https://github.com/libtom/libtommath/pull/18) is out of date with what's now bundled in Heimdal's 1.6 branch. So that pull request will never be merged as-is. We will need to open new pull requests, which I've done at https://github.com/libtom/libtommath/pull/21 , https://github.com/libtom/libtommath/pull/22 , https://github.com/libtom/libtommath/pull/23 for starters. Please read the FPC ticket in its entirety. The problem is that upstream libtommath's mp_expt_d() function does not operate the way that Heimdal needs it to operate.
The libtommath bundling exception passed the FPC, so there are no more blockers to accepting this into Fedora. I've updated the package to the latest 1.6 git snapshot. Package in Git: https://gitorious.org/ktdreyer/heimdal-packaging Spec URL: http://ktdreyer.fedorapeople.org/reviews/heimdal.spec SRPM URL: http://ktdreyer.fedorapeople.org/reviews/heimdal-1.6.0-0.2.20140429gitd60ba47.fc21.src.rpm F21 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6795654 The package is now ready for review.
So, I did a local build of this on my F20 box and it failed running the tests. I notice that configure picked up a few extra things on my local build: +checking lex library... -lfl +checking whether yytext is a pointer... yes Does not appear to be used though +checking for CAPNG... yes > BuildRequires: libcap-ng-devel -checking for crypto library... included libhcrypto +checking for crypto library... libcrypto So, what to do here. Somehow I missed that heimdal's libhcrypto is a SSL reimplementation, and can be swapped out for openssl. It also appears to be the user of libtommath. Do we want to use libhcrypto or openssl? +checking db.h usability... yes +checking db.h presence... yes +checking for db.h... yes +checking for db_create... yes, in -ldb > BuildRequires: libdb-devel (instead of db4-devel) +checking whether to enable OTP library... yes This comes from having libdb. Other missed items: checking for libintl... no Not sure why it isn't finding this. My rawhide build with this failed with: Installed (but unpackaged) file(s) found: /usr/bin/otp /usr/bin/otpprint /usr/share/man/man1/otp.1.gz /usr/share/man/man1/otpprint.1.gz Which look to be a little too generic. Don't know why my local tests are failing but mock/koji builds are fine.
(In reply to Orion Poplawski from comment #56) > So, I did a local build of this on my F20 box and it failed running the > tests. I notice that configure picked up a few extra things on my local > build: Thanks a lot for investigating this. > +checking for CAPNG... yes > > > BuildRequires: libcap-ng-devel I've added this in. > -checking for crypto library... included libhcrypto > +checking for crypto library... libcrypto > > So, what to do here. Somehow I missed that heimdal's libhcrypto is a SSL > reimplementation, and can be swapped out for openssl. It also appears to be > the user of libtommath. Do we want to use libhcrypto or openssl? Wow, I totally missed this. You're right. I was missing BR: openssl-devel, and the build system wasn't erroring when I used --with-openssl. Now that I've added the BR, libhcrypto (including libtommath) is not present. I haven't tested the OpenSSL backend myself, but the test suite passes at least. That simplifies things from Fedora's perspective. > +checking db.h usability... yes > +checking db.h presence... yes > +checking for db.h... yes > +checking for db_create... yes, in -ldb > > > BuildRequires: libdb-devel (instead of db4-devel) Great catch again. That explains the mystery of why the otp utilities were only building on RHEL 6. I've adjusted the package to use libdb-devel on Fedora and db4-devel on RHEL 6. > +checking whether to enable OTP library... yes > > This comes from having libdb. > > Other missed items: > > checking for libintl... no > > Not sure why it isn't finding this. I can't even find a package that ships libintl.so. I guess Red Hat gettext doesn't have this. > My rawhide build with this failed with: > Installed (but unpackaged) file(s) found: > /usr/bin/otp > /usr/bin/otpprint > /usr/share/man/man1/otp.1.gz > /usr/share/man/man1/otpprint.1.gz > > Which look to be a little too generic. You're right. Once I sorted out the libdb-devel situation I can package those files on both Fedora and RHEL. Here's the new version: * Tue Apr 29 2014 ktdreyer - 1.6.0-0.3.20140429gitd60ba47 - Add BR libdb-devel on Fedora (RHBZ #613001) - Add BR openssl-devel and libcap-ng-devel (RHBZ #613001) - Only set BuildRoot on el5 - Alphabetize non-conditional BuildRequires - Remove duplicate BR openldap-devel Exact changes in Git: https://gitorious.org/ktdreyer/heimdal-packaging/commit/f90e6ff63adad6303174fb27405e0834f30234ae Spec URL: http://ktdreyer.fedorapeople.org/reviews/heimdal.spec SRPM URL: http://ktdreyer.fedorapeople.org/reviews/heimdal-1.6.0-0.3.20140429gitd60ba47.fc21.src.rpm F21 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6797256
I'm still getting sporadic test failures building on my machine, but other builds seem fine, so I'm going to hope for the best. Issues: ======= - Permissions on files are set properly. Note: See rpmlint output See: http://fedoraproject.org/wiki/Packaging/Guidelines#FilePermissions - Texinfo files are installed using install-info in %post and %preun if package has .info files. Note: Texinfo .info file(s) in heimdal-libs See: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Texinfo - Static libraries in -static or -devel subpackage, providing -devel if present. Note: Package has .a files: heimdal-devel. Does not provide -static: heimdal-devel. See: http://fedoraproject.org/wiki/Packaging/Guidelines#StaticLibraries - Package does not contain any libtool archives (.la) Note: heimdal-libs : /usr/lib64/heimdal/libasn1.la heimdal-libs : /usr/lib64/heimdal/libgssapi.la heimdal-libs : /usr/lib64/heimdal/libhdb.la heimdal-libs : /usr/lib64/heimdal/libheimbase.la heimdal-libs : /usr/lib64/heimdal/libheimntlm.la heimdal-libs : /usr/lib64/heimdal/libhx509.la heimdal-libs : /usr/lib64/heimdal/libkadm5clnt.la heimdal-libs : /usr/lib64/heimdal/libkadm5srv.la heimdal-libs : /usr/lib64/heimdal/libkafs.la heimdal-libs : /usr/lib64/heimdal/libkdc.la heimdal-libs : /usr/lib64/heimdal/libkrb5.la heimdal-libs : /usr/lib64/heimdal/libotp.la heimdal-libs : /usr/lib64/heimdal/libroken.la heimdal-libs : /usr/lib64/heimdal/libsl.la heimdal-libs : /usr/lib64/heimdal/libwind.la heimdal-libs : /usr/lib64/heimdal/windc.la See: http://fedoraproject.org/wiki/Packaging/Guidelines#StaticLibraries - Drop %defattr() Rpmlint ------- heimdal-workstation.x86_64: E: missing-call-to-setgroups /usr/libexec/kfd heimdal-workstation.x86_64: E: missing-call-to-setgroups /usr/libexec/popper heimdal-workstation.x86_64: W: manual-page-warning /usr/share/man/man8/heimdal-kadmin.8.gz 119: warning: macro `Q1' not defined heimdal-appl-clients.x86_64: W: dangling-symlink /etc/login.access /etc/security/access.conf heimdal-appl-clients.x86_64: E: invalid-locale-man-dir /usr/share/man/heimdal/man5/login.access.5.gz heimdal-appl-servers.x86_64: E: invalid-locale-man-dir /usr/share/man/heimdal/man5/ftpusers.5.gz heimdal-server.x86_64: E: non-standard-dir-perm /var/log/heimdal 0700L heimdal-server.x86_64: E: non-readable /etc/heimdal-kadmind.acl 0600L heimdal-server.x86_64: E: zero-length /etc/heimdal-kadmind.acl heimdal-server.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/heimdal heimdal-server.x86_64: W: non-conffile-in-etc /etc/logrotate.d/heimdal heimdal-server.x86_64: E: non-readable /etc/heimdal-slaves 0600L heimdal-server.x86_64: E: zero-length /etc/heimdal-slaves heimdal-server.x86_64: E: non-readable /etc/heimdal-kdc.conf 0600L heimdal-server.x86_64: E: non-standard-dir-perm /var/heimdal 0700L heimdal-server.x86_64: W: non-standard-dir-in-var heimdal heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libasn1.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libkrb5.so heimdal-libs.x86_64: E: postin-without-install-info /usr/share/info/hx509.info.gz heimdal-libs.x86_64: E: postin-without-install-info /usr/share/info/hx509.info.gz heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libkdc.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libkafs.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libheimntlm.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libhdb.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libroken.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libsl.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libotp.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libgssapi.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libhx509.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libkadm5clnt.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libheimbase.so heimdal-libs.x86_64: E: postin-without-install-info /usr/share/info/heimdal.info.gz heimdal-libs.x86_64: E: postin-without-install-info /usr/share/info/heimdal.info.gz heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libwind.so heimdal-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/heimdal/libkadm5srv.so heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/krb5_get_creds_opt_set_impersonate.3.gz 136: warning: macro `Fi' not defined heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/krb5_get_creds_opt_set_ticket.3.gz 136: warning: macro `Fi' not defined heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/krb5_get_creds.3.gz 136: warning: macro `Fi' not defined heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/krb5_get_creds_opt_alloc.3.gz 136: warning: macro `Fi' not defined heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/krb5_get_creds_opt_set_options.3.gz 136: warning: macro `Fi' not defined heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/krb5_get_creds_opt_free.3.gz 136: warning: macro `Fi' not defined heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/gssapi.3.gz 451: cannot use character `2' as a starting delimiter heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/gssapi.3.gz 451: cannot use character `8' as a starting delimiter heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/gssapi.3.gz 451: cannot use character `4' as a starting delimiter heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/gssapi.3.gz 451: cannot use character `8' as a starting delimiter heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/gssapi.3.gz 451: cannot use character `1' as a starting delimiter heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/gssapi.3.gz 451: cannot use character `0' as a starting delimiter heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/gssapi.3.gz 451: cannot use character `0' as a starting delimiter heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/gssapi.3.gz 451: cannot use character `0' as a starting delimiter heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/gssapi.3.gz 451: cannot use character `0' as a starting delimiter heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/krb5_get_creds_opt_set_enctype.3.gz 136: warning: macro `Fi' not defined heimdal-devel.x86_64: W: manual-page-warning /usr/share/man/man3/krb5_get_creds_opt_add_options.3.gz 136: warning: macro `Fi' not defined heimdal-path.x86_64: E: explicit-lib-dependency heimdal-libs heimdal-path.x86_64: E: executable-sourced-script /etc/profile.d/heimdal.sh 0755L heimdal-path.x86_64: E: executable-sourced-script /etc/profile.d/heimdal.csh 0755L heimdal.src: W: strange-permission heimdal-generate-autoconf-tarball 0775L heimdal.src: W: strange-permission heimdal-ipropd-slave-wrapper 0775L AutoTools: Obsoleted m4s found ------------------------------ AC_PROG_LIBTOOL found in: heimdal- d60ba47157db86f1996e055a41caf1a9a96e2afe/configure.ac:17, heimdal- d60ba47157db86f1996e055a41caf1a9a96e2afe/lib/libedit/configure.ac:21
Thanks very much for the review. I'm working on addressing the issues you mentioned. We kept %defattr() because we were going to support EL5. I'm on the fence about supporting EL5 now, but let's keep it in for now. I'll post an updated package in the next couple of days.
(In reply to Ken Dreyer from comment #59) > We kept %defattr() because we were going to support EL5. I'm on the fence > about supporting EL5 now, but let's keep it in for now. %defattr() isn't needed even in EL5.
> %defattr() isn't needed even in EL5. More precisely: not for Fedora koji based EL5 builds and not for recent EL5 dist releases either, but only for older 5.x releases.
Here's the new version. This should address the issues in comment #58 (along with other fixes). * Thu May 22 2014 Ken Dreyer <ktdreyer> - 1.6.0-0.4.20140522git229d8c7 - Update git snapshot to latest tip of heimdal-1-6-branch - Drop upstreamed text-fx patch - Install Texinfo files (RHBZ #613001) - Add Provides: heimdal-static to -devel subpackage (RHBZ #613001) - Drop %%defattr (RHBZ #613001) - Add text content to kadmind.acl to help users (and remove a zero-length file) - Install profile.d scripts with non-executable permissions - Remove .la files - Patch to remove AC_PROG_LIBTOOL macro - Reload xinetd when using systemd - Require logrotate and setup, since we drop config files into directories that these packages own. - Add unowned Heimdal directories in %%files - Replace "heimdal" with %%{name} in %%files - Do not BR libcap-ng-devel on EL5 Exact changes in Git: https://gitorious.org/ktdreyer/heimdal-packaging/commit/720db3876630945b2841b354d798827c2ace43df Spec URL: http://ktdreyer.fedorapeople.org/reviews/heimdal.spec SRPM URL: http://ktdreyer.fedorapeople.org/reviews/heimdal-1.6.0-0.4.20140522git229d8c7.fc21.src.rpm F21 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6894313 A couple of comments on the remaining rpmlint issues: - rpmlint found a dangling-symlink, but I don't see how this could be the case, since it Requires: pam, which Provides the symlink destination, /etc/security/access.conf. - invalid-locale-man-dir - this is a result of putting the man pages in a "heimdal" subdirectory so they don't conflict with existing man pages in other packages. - Some files have non-standard-dir-perm or non-readable settings. These files should only be readable by root, so it's ok to ignore rpmlint warnings about these. - The /etc/heimdal-slaves file is zero-length because there's no content to add to it by default. (Deleting the file from the package would leave a dangling symlink in /var/heimdal.) - The devel-file-in-non-devel-package warnings are because Heimdal has plugins that look like shared libraries. - The explicit-lib-dependency error with heimdal-path is a false positive: heimdal-path requires end-user binaries, not shared libaries that could be autorequired. The cleanest solution is to just Require: heimdal-libs.
Great, looking good. (In reply to Ken Dreyer from comment #62) > A couple of comments on the remaining rpmlint issues: > - rpmlint found a dangling-symlink, but I don't see how this could be the > case, > since it Requires: pam, which Provides the symlink destination, > /etc/security/access.conf. Yeah, rpmlint can't figure this out, so it warns about the possibility. > - invalid-locale-man-dir - this is a result of putting the man pages in a > "heimdal" subdirectory so they don't conflict with existing man pages in > other packages. I see two of these: # ls /usr/share/man/heimdal/man5/ ftpusers.5.gz login.access.5.gz ftpusers is essentially a duplicate of ftpusers(5) from man-pages, so I would contemplate just not shipping it. I can't find a login.access man page anywhere else, so it seems like that could be installed normally. I think there are problems with the heimdal-klist and heimdal-kswitch symlinks. Looks like heimtools does not recognize those names and so is asking for a command as if you ran "heimtools" directly: $ heimdal-klist klist, list klist kgetcred kgetcred kswitch, switch kswitch kvno kvno copy_cred_cache copy_cred_cache help, ? help [command]
# systemctl start heimdal-kadmind Job for heimdal-kadmind.service failed. See 'systemctl status heimdal-kadmind.service' and 'journalctl -xn' for details. May 28 12:25:30 barry heimdal-kadmind[26305]: heimdal-kadmind: setpgid: Operation not permitted
Also, the xinetd stuff should be replaced with systemd configs.
Upstream fixed a large bug in the krb5-config utility so I'm updating the Git snapshot again to the tip of 1.6. I've taken your advice and installed login.users(5) into the regular place and removed ftpusers(5) from the package altogether. With these changes, we can avoid shipping %{_mandir}/%{name} entirely. Thank you for catching heimdal-klist breaking. I've fixed that in Patch0. It's small enough that I'm comfortable carrying that one in Fedora. Thanks also for catching the kadmind bug with systemd. I've fixed that in Patch6 and submitted it upstream. I'm a bit hesitant to remove xinted altogether since Alexander put so much work into repairing those bits of the packaging, and I suspect that a number of sites use it. However, I haven't heard from Alexander in a while, and I completely agree that systemd should be the option that we promote going forward. Unless I hear screams I'm going to remove xinted per your suggestion, especially for the platforms that are already have systemd (ie RHEL 7 and Fedora). * Fri May 30 2014 Ken Dreyer <ktdreyer> - 1.6.0-0.5.20140529gitddde77b - Update git snapshot to latest tip of heimdal-1-6-branch - Use /sbin path in %%pre/%%post scripts for EL6 and EL5 - Install login.users(5) normally, since it doesn't conflict with anything (RHBZ #613001) - Don't ship ftpusers(5) (RHBZ #613001) - Patch heimtools to deal with the commands' "heimdal-" prefixes (RHBZ #613001) - Use "simple" systemd service type for kdc, kadmind, kpasswdd - Add "--detach" flag in heimdal-ipropd-slave-wrapper to match the systemd forking service type - Patch kadmind to handle systemd's restrictions on setpgid() (RHBZ #613001) Exact changes in Git: https://gitorious.org/ktdreyer/heimdal-packaging/commit/d337a86fc85ea554ee55616870aab9df9cef0114 Spec URL: http://ktdreyer.fedorapeople.org/reviews/heimdal.spec SRPM URL: http://ktdreyer.fedorapeople.org/reviews/heimdal-1.6.0-0.5.20140529gitddde77b.fc21.src.rpm F21 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6913952
We're going to need xinetd still on <=EL6, so I'm fine with either keeping it for now and then migrating to systemd sockets after import, or adding the systemd socket stuff now with conditionals in the .spec file. Up to you as to how you want to maintain the spec file across the branches.
Looks good. Approved.
Thanks very much for the review! I've updated the package restrict xinetd to EL5 and EL6. EL7 and Fedora will only support systemd https://gitorious.org/ktdreyer/heimdal-packaging/commit/5b650861858c503b914100af9a2c66df7091d4ed New Package SCM Request ======================= Package Name: Heimdal Short Description: Alternative Kerberos implementation Upstream URL: http://www.h5l.org/ Owners: ktdreyer Branches: f19 f20 el5 el6 epel7
Shouldn't it be packaged as heimdal? Upstream tarball name: http://www.h5l.org/dist/src/
New Package SCM Request ======================= Package Name: heimdal Short Description: Alternative Kerberos implementation Upstream URL: http://www.h5l.org/ Owners: ktdreyer Branches: f19 f20 el5 el6 epel7
Git done (by process-git-requests).
Thanks Christopher for the correction. The package is built in Koji and present in updates-testing / epel-testing. http://koji.fedoraproject.org/koji/packageinfo?packageID=18703