Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Use alternatives to allow for heimdal packaging|
|Product:||[Fedora] Fedora||Reporter:||Orion Poplawski <orion>|
|Component:||krb5||Assignee:||Roland Mainz <rmainz>|
|Status:||CLOSED EOL||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||19||CC:||dpal, gholms, ktdreyer, nalin, phalenor, prmarino1, rharwood, rmainz|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-02-17 08:42:20 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Orion Poplawski 2011-03-31 13:01:00 EDT
Description of problem: Heimdal is up for review at bug 613001. For this to not conflict with the MIT krb5 package, we're going to need to use alternatives in both packages. The items I've found to conflict are: kadmin kadmind kdestroy kinit klist kpasswd krb5-config ktutil (binaries and man pages) plus the krb5.conf man page. Thoughts?
Comment 1 Nalin Dahyabhai 2011-03-31 13:55:36 EDT
The kadmin init script would have to point to the non-alternatives location, but before we get that far, there's the problem that different implementations of these tools use disjoint command-line options. How does this avoid breaking scripts and user expectations as soon as people toggle the alternative?
Comment 2 Orion Poplawski 2011-03-31 15:00:21 EDT
I think we're going to have to trust that people installing heimdal know what they are doing. What other choice do we have?
Comment 3 Ken Dreyer 2011-03-31 15:08:50 EDT
Since we are just starting out with Heimdal, I was picturing that we would have MIT have the higher priority in the alternatives list. In order to break their system, a user would need to either uninstall MIT, or else manually manually run "alternatives" to override the priority. At that point it is the user's responsibility to verify that this will not break their own user-written code.
Comment 4 Nalin Dahyabhai 2011-03-31 15:21:15 EDT
We could also decide to not use alternatives, and put the binaries elsewhere (either adding $PATH munging or requiring people to use full paths) or with different names (though as that's not what upstream names things, I'm not really keen on that). We've got packages (parts of IPA, at least) that call utilities with specific flags, and I'm not in favor of using alternatives if it helps people inadvertently break things.
Comment 5 Orion Poplawski 2011-03-31 15:27:56 EDT
As I understand it, not putting the binaries in /usr/bin requires a FESCO exception. We asked and were denied: https://fedorahosted.org/fesco/ticket/577. Comment there if you'd like.
Comment 6 Nalin Dahyabhai 2011-03-31 16:12:02 EDT
I added a note in favor of an exception being made. After looking at the rsh implementation, I'm now convinced that you'll need one.
Comment 7 Ken Dreyer 2011-10-04 19:10:19 EDT
(In reply to comment #4) > We could also decide to not use alternatives, and put the binaries elsewhere > (either adding $PATH munging Right now, krb5-appl-clients.sh sets /usr/kerberos/bin at the front of $PATH. To do this on the Heimdal side, we'd have to do the opposite and put it at the end of $PATH. Otherwise, we'd end up overriding MIT's /usr/bin/kinit, for example. Secondarily, if we manipulate $PATH in /etc/profile.d, we'd have to be sure that "h" in "heimdal.sh" comes before "k" in "kerberos.sh", so we don't accidentally set $PATH in front of MIT. I think alternatives would be a more flexible solution to have the two packages live peacefully. What do you think? > or requiring people to use full paths) Requiring full paths is not really the best option from a usability perspective, and alternatives would be able to save our users' typing. > or with > different names (though as that's not what upstream names things, I'm not > really keen on that). > We've got packages (parts of IPA, at least) that call utilities with specific > flags, Some of the flags (eg. -t for /path/to/keytab) are the same, but you're correct; there will be some differences. (Would you be able to use full paths in IPA?) > and I'm not in favor of using alternatives if it helps people > inadvertently break things. If we kept the MIT alternatives priority higher that Heimdal, people would have to intentionally override that. This could be similar to Java. If you've manually overridden your Java alternatives settings to use Oracle's JRE, then it's your own fault if Java apps are broken :)
Comment 8 Nalin Dahyabhai 2011-10-05 10:36:24 EDT
(In reply to comment #7) > Right now, krb5-appl-clients.sh sets /usr/kerberos/bin at the front of $PATH. > To do this on the Heimdal side, we'd have to do the opposite and put it at the > end of $PATH. Otherwise, we'd end up overriding MIT's /usr/bin/kinit, for > example. > > Secondarily, if we manipulate $PATH in /etc/profile.d, we'd have to be sure > that "h" in "heimdal.sh" comes before "k" in "kerberos.sh", so we don't > accidentally set $PATH in front of MIT. How is there an ordering requirement between two scripts when one prepends to the path and the other appends? > I think alternatives would be a more flexible solution to have the two packages > live peacefully. What do you think? It doesn't solve the things-breaking problem, so I'm not in favor. > > We've got packages (parts of IPA, at least) that call utilities with specific > > flags, > > Some of the flags (eg. -t for /path/to/keytab) are the same, but you're > correct; there will be some differences. (Would you be able to use full paths > in IPA?) IPA was an example, but there's no guarantee that it's the only case.
Comment 9 Paul Robert Marino 2012-03-23 12:37:58 EDT
Hey can I vote for this one lol? for the most part in my experience my experience most applications that make library calls will be fine as long as the MIT Kerberos libraries are intact. The only thing that may potentially break are certain poorly written apps that make system calls which seem to be rare with kerberized applications, and compiles of certain software but for the most part the developers of Heimdal have gone to great lengths to make the two compatible. I also agree with the statement the allowing the user to override with the alternatives option is no different then how java is currently handled.
Comment 10 Fedora End Of Life 2013-04-03 12:27:30 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 11 Fedora Admin XMLRPC Client 2014-10-06 12:37:33 EDT
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 12 Fedora End Of Life 2015-01-09 11:37:42 EST
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Comment 13 Fedora End Of Life 2015-02-17 08:42:20 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.