kerberos

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

kerberos

Dan Stratila
Hi,

I was wondering why (MIT) Kerberos is not an official cygwin package? There
are many cons for it:

1) Kerberos is very useful to many people (e.g. MIT, Stanford, government
agencies, large companies). It looks like it is becoming even more popular
with Microsoft and the major Linux distributions incorporating it.

2) Not having krb5 incapacitates all cygwin packages that would otherwise
support it (such as OpenSSH, PostgreSQL). The number of such packages is
bound to grow as more and more applications support it.

3) It looks like there are at least 3 binary sets of various versions of
krb5 available online ( http://cygutils.fruitbat.org/testing/release/krb5/,
and http://www-cdf.fnal.gov/~cplager/kerberos.html, and
http://www-clued0.fnal.gov/~axel/files/). By making this a package, at least
3 people will save time. :)

4) Since MIT's Kerberos for Windows can cache tickets to a file, I was able
to have a cygwin-compiled krb5 and the GUI Windows apps from KfW interface
perfectly! For example, I can get a ticket with a GUI app, and then destroy
it with kdestroy.

5) There are no licensing issues. ;)

Sincerely,
Dan


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: kerberos

Brian Dessent
Dan Stratila wrote:

> I was wondering why (MIT) Kerberos is not an official cygwin package? There
> are many cons for it:

The only reason that it is not an official package is that no one has
volunteered to do it.  The packaging guide on the web site describes
everything necessary.  But nothing will happen until someone actually
follows through and offers to maintain them.  Wishful thinking will not
make it so.

> 3) It looks like there are at least 3 binary sets of various versions of
> krb5 available online ( http://cygutils.fruitbat.org/testing/release/krb5/,
> and http://www-cdf.fnal.gov/~cplager/kerberos.html, and
> http://www-clued0.fnal.gov/~axel/files/). By making this a package, at least
> 3 people will save time. :)

You should be asking those people why they chose to post packages on
their own sites rather than step up and offer to maintain them as
official packages.

By the way, topics about packaging belong on the cygwin-apps (at)
cygwin.com mailing list, not here.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: kerberos

Charles Wilson-2
Brian Dessent wrote:

>> 3) It looks like there are at least 3 binary sets of various versions of
>> krb5 available online ( http://cygutils.fruitbat.org/testing/release/krb5/,
>> and http://www-cdf.fnal.gov/~cplager/kerberos.html, and
>> http://www-clued0.fnal.gov/~axel/files/). By making this a package, at least
>> 3 people will save time. :)
>
> You should be asking those people why they chose to post packages on
> their own sites rather than step up and offer to maintain them as
> official packages.

Well, in my case (cygutils), it's because I was just playing around with
getting krb to compile -- I was trying to get cvsnt to work, and at the
time it explicitly required krb, while the cvshome (now ximbiot)
"official" cvs merely had krb as an optional dependency.

However, I don't use kerberos, so I would be an ineffective maintainer.
  Plus, I had (have) no intention of adding yet ANOTHER package to the
already-too-long list of packages I maintain.  In order to help others
by enabling them to avoid duplicating my efforts, I went ahead on posted
my version where others could use it or take it over and ITP it themselves.

One of the problems I ran into was the conflict between the kerberos
package's versions of telnet, ftp, etc  and those provided by inetutils.
  This conflict is problematic (if krb tools are to go in /usr/bin)
because you can't just say "install krb instead of inetutils" -- not
only does krb DEPEND on inetutils, but krb doesn't provide everything
that inetutils does -- which messes up OTHER packages that currently
depend on inetutils.  e.g. krb is not a FULL replacement.  Plus, setup's
dependency resolution scheme is not robust enough to help with
"capabilities" == 'I need feature 'telnet.exe' and I don't care what
actual package provides it'.  Setup's d.r.s is entirely package-driven:
'I need package inetutils'.

Which is why I posted the following:

"RFD: A modest proposal #1: /opt"
http://www.cygwin.com/ml/cygwin-apps/2003-04/msg00305.html

This was eventually approved IIRC, but to date nobody maintaining an
official cygwin package has found it necessary to use the /opt tree.
I'd recommend any future maintainer intending to ITP kerberos do so.

Also, now that the 'alternatives' package is available, it might be
beneficial to work with the inetutils maintainer to use the
'alternatives' machinery to allow end-users to switch between the
inetutils and kerberos versions of telnet, ftp, etc.  (You'd still IMO
want to use /opt for the "real" kerberos installation.  The inetutils
maintainer would need to agree to relocate the inetutils "real"
executables to /usr/lib/inetutils/ or something, tho.)

> By the way, topics about packaging belong on the cygwin-apps (at)
> cygwin.com mailing list, not here.

IMO, that isn't true in this case.  cygwin-apps is for discussing the
packaging of *existing* apps, or ITP and followon discussion of new
ones.  If the OP decides to ITP kerberos, then THAT should go to
cygwin-apps.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/