RE: sun vs. ubuntu issues in dependences ?
you are absolutely right. The implementation of the kerberos which comes with ON bits tightly integrated with NFS and CIFS services, provides pam module, and actively maintained by opensolaris community. What _exactly_ are the differences? If I'm not completley wrong, the Sun kerberos is/should be based on the MIT Kerberos version. If it is, then maybe merge the change into the krb5 package(s) in a way that doesn't make the krb5 package 'unusable'.. We should have it installed and offered by default. I for one could 'care less' about the Sun kerberos and I would be 'very annoyed' if I couldn't get the MIT Kerberos V packages installed. ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
RE: sun vs. ubuntu issues in dependences ?
You could track changes to krb5 here: http://hg.genunix.org/onnv-gate.hg/log?rev=krb5 but this is only for files matching krb5 phrase. In reality it is much more differences then the above link showing. On Mon, 2009-03-09 at 09:18 +0100, Fredriksson, Ulf wrote: you are absolutely right. The implementation of the kerberos which comes with ON bits tightly integrated with NFS and CIFS services, provides pam module, and actively maintained by opensolaris community. What _exactly_ are the differences? If I'm not completley wrong, the Sun kerberos is/should be based on the MIT Kerberos version. If it is, then maybe merge the change into the krb5 package(s) in a way that doesn't make the krb5 package 'unusable'.. We should have it installed and offered by default. I for one could 'care less' about the Sun kerberos and I would be 'very annoyed' if I couldn't get the MIT Kerberos V packages installed. ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: sun vs. ubuntu issues in dependences ?
Am 07. Mar 2009, um 13:12:12 schrieb Tim Spriggs: Tim, As has been pointed out, the sun kerberos package has several extensions that are required to get some solaris features to work. I assume that would include eg. tickets for kerberized NFS for the NFS client in kernel space would need access to the user's ticket for authentication. If this is indeed the case, User Expectation is that after kinit they are authorized to those services. On Ubuntu, this may even mean having gotten the kerberos tickets through logon. Having two sets of kerberos tools, one for this, and another for that means that Nexenta developers will rightfully be bashed for misunderstanding the single in Single-Sign-On. Please someone with detailed Solaris kerberos experience confirm or deny this, for if it is true, there is thus only two ways out: Either Ubuntu Kerberos gets extended with Solaris patches, or Solaris Kerberos gets promoted standard kerberos, and Ubuntu Kerberos goes away (ie. is replaced with a dummy package). This will likely involve changing the location of some binaries (sun krb5-config has to go to /usr/bin then), and a rebuild of all packages linking kerberos libs. (unless the packages are binary compatible which i highly doubt) Mario ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: sun vs. ubuntu issues in dependences ?
Mario, you are absolutely right. The implementation of the kerberos which comes with ON bits tightly integrated with NFS and CIFS services, provides pam module, and actively maintained by opensolaris community. We should have it installed and offered by default. On Sun, 2009-03-08 at 16:46 +0100, Mario Lorenz wrote: Am 07. Mar 2009, um 13:12:12 schrieb Tim Spriggs: Tim, As has been pointed out, the sun kerberos package has several extensions that are required to get some solaris features to work. I assume that would include eg. tickets for kerberized NFS for the NFS client in kernel space would need access to the user's ticket for authentication. If this is indeed the case, User Expectation is that after kinit they are authorized to those services. On Ubuntu, this may even mean having gotten the kerberos tickets through logon. Having two sets of kerberos tools, one for this, and another for that means that Nexenta developers will rightfully be bashed for misunderstanding the single in Single-Sign-On. Please someone with detailed Solaris kerberos experience confirm or deny this, for if it is true, there is thus only two ways out: Either Ubuntu Kerberos gets extended with Solaris patches, or Solaris Kerberos gets promoted standard kerberos, and Ubuntu Kerberos goes away (ie. is replaced with a dummy package). This will likely involve changing the location of some binaries (sun krb5-config has to go to /usr/bin then), and a rebuild of all packages linking kerberos libs. (unless the packages are binary compatible which i highly doubt) Mario ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: sun vs. ubuntu issues in dependences ?
Mario Lorenz wrote: I guess I would prefer ubuntu as a baseline, if only for the reason that all packages that possibly are ported likely have debianish/linuxish expectations. For instance, I still find myself calling ps twice, because the first time it complains -axu aint there. Thank god killall nowadays insists on a signame :) Then again, I dont have enough karma yet to vote on this... Mario Hi Mario, I tend to agree with building gnu packages against gnu packages whenever possible/feasible. The two versions of Kerberos should be compat (afaik) but maybe some basic sanity checks are in order? If you grab a token via sun krb5, can it be used with the debian package krb5 implementation? I tried to do this quickly by grabbing a token via sun krb5 and then installed the krb5-user (debian) package. (I needed to manually add diversions to do this.) Running klist after the install yielded a strange error: klist: Improper format of Kerberos configuration file while initializing krb5 Interestingly, the config file for the sun krb5 implementation is /etc/krb5/krb5.conf while the debian package seems to use /etc/krb5.conf. It's likely that this one (critical) difference alone could lead to confusion if just the libs are installed. I think the krb5 debian package needs a little attention so that it uses the same config file path. I quickly made a symlink and verified that the debian klist works with the token acquired from sun kinit: # cd /etc/ # mv krb5.conf krb5.conf- # ln -s /etc/krb5/krb5.conf indeed it seemed to work. All of this being said, I vote to build against the debian package in general. Unless there are any dissenting opinions I would say just go for it. Cheers, -Tim ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: sun vs. ubuntu issues in dependences ?
On Thu, 2009-03-05 at 20:07 +0100, Mario-Lorenz wrote: Hi, I'm working on some of the mail-related packages, and found some issues that I would like to ask which the better way for a fix would be. a) fetchmail doesnt build because it can not find krb5-config. It can not find it because the sunw kerberos one is in /usr/sun/bin, which is not in its path. It can not find the Ubuntu one because when porting that package, its name was changed to libkrb5-config. situation with libkrb5 is currently not cleared up yet. I'm voting for OpenSolaris krb5 - to be a default in Nexenta. This would preserver compatibility with OpenSolaris distros. The ubuntu packages which are using krb5 are 99% autoconf/automake aware and should be able to detect OpenSolaris diffs. To fix this, do I - change the krb5 package back so it provides krb5-config again, which might cause issues if other packages expect krb5-config to be the sun one (and have usr/sun/bin in their path) or - change the fetchmail package to include usr/sun/bin in its path and thus link against the sun kerberos instead of the nexenta one (are there any specific reasons why we need the two of them, anyway ?) or - change the fetchmail package to use libkrb5-config, which is an unnecessary deviation from ubuntu (and possibly other packages might suffer from a simmilar problem ? if we would have krb5 as I suggested above - the issue wouldn't exists. b) mutt does not build because the permissions of /var/mail differ from ubuntu. (sun var/mail has more lenient permissions, hence the configure stage thinks it can do without the mutt dotlock helper, and doesnt compile it, and the packaging stage wants to pack it in... Again, this has to be fixed in either the sun package owning /var/mail, or the mutt (and possibly other) packages... I'll try to fix that in sunwcsr. What's the permission it needs to be? c) Is there an overriding rationale on when to use Sun userspace vs. Ubuntu userspace ? sendmail, rmail etc. come to mind as examples where this happens... I would prefer to keep OpenSolaris stuff and provide an alternative for Ubuntu ones. ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
Re: sun vs. ubuntu issues in dependences ?
Erast Benson wrote: On Thu, 2009-03-05 at 20:07 +0100, Mario-Lorenz wrote: Hi, I'm working on some of the mail-related packages, and found some issues that I would like to ask which the better way for a fix would be. a) fetchmail doesnt build because it can not find krb5-config. It can not find it because the sunw kerberos one is in /usr/sun/bin, which is not in its path. It can not find the Ubuntu one because when porting that package, its name was changed to libkrb5-config. situation with libkrb5 is currently not cleared up yet. I'm voting for OpenSolaris krb5 - to be a default in Nexenta. This would preserver compatibility with OpenSolaris distros. The ubuntu packages which are using krb5 are 99% autoconf/automake aware and should be able to detect OpenSolaris diffs. I'm not 100% familiar with the situation, but in case you guys aren't aware the krb5 implementation in onnv-gate has several rather important sun related improvements. I've briefly discussed making a patch against vanilla with the maintainer before, but it's simply on my TODO list and not done yet. So is this some choice between ubuntu package without sun enhancements or onnv-gate version? ___ gnusol-devel mailing list gnusol-devel@lists.sonic.net http://lists.sonic.net/mailman/listinfo/gnusol-devel
