Re: [Cooker] Re: [CHRPM] cyrus-sasl-2.1.10-2mdk

2003-01-31 Thread Stefan van der Eijk



--=-=-=
Name: cyrus-sasl   Relocations: (not relocateable)
Version : 2.1.10Vendor: MandrakeSoft
Release : 2mdk  Build Date: Mon Jan 20 18:54:47 2003
   


Is this the start of the move to sasl v2?  I hope so.  On my Cooker
system, I show the current dependencies on sasl v1 as being:

$ rpm -q --whatrequires libsasl7
cyrus-sasl-1.5.27-6mdk
nss_ldap-202-1.1mdk
pam_ldap-156-1.1mdk



Yes, the src.rpm that builds libsasl7 is not in cooker anymore. Quite 
some packages way down in the distro require libsasl7 and even basesystem.

Is the move to sasl2 going to be completed? Or is a src.rpm that builds 
libsasl7 going to come back? Just wondering.

Stefan


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [Cooker] Re: [CHRPM] cyrus-sasl-2.1.10-2mdk

2003-01-31 Thread Luca Olivetti
Stefan van der Eijk wrote:


Yes, the src.rpm that builds libsasl7 is not in cooker anymore. Quite 
some packages way down in the distro require libsasl7 and even basesystem.

Is the move to sasl2 going to be completed? Or is a src.rpm that builds 
libsasl7 going to come back? Just wondering.

It depends on the authentication method. If you store your secrets in 
the sasldb, migration is an all or nothing proposition: the database 
format has changed, there's an utility to convert from the old format to 
the new format, but then applications using sasl v1 will be using the 
old database, while applications using sasl v2 will use the new one, and 
there's no way to keep them in sync afterwards. So the only sensible 
thing to do in this case is upgrade all applications using the sasl 
library (provided all of them have been adapted/patched to use sasl v2).

If you use another authentication (e.g. pam, like I'm doing) 
applications using the old and new library can coexist (provided you 
don't use saslauthd for both, you can use pwcheck for the old 
applications and saslauthd for the new ones, or pwcheck for both).
There's some problem using ldap authentication if you mix sasl versions, 
but it seems to be dependent on specific configurarions.
Since I'm not using neither sasldb nor ldap, I'm happily authenticating 
cyrus-imapd with sasl v2 and postfix (only server side, i.e. smtp-auth) 
with sasl v1, but an official mandrake package should take care of all 
possibilities (i.e: upgrade all applications using sasl at once)

Bye
--
Luca Olivetti
Note.- This message reached you today, it may not tomorrow if you
are using MAPS or other RBL. They arbitrarily IP addresses not
related in any way to spam, disrupting Internet connectivity.
See http://slashdot.org/article.pl?sid=01/05/21/1944247 and
http://theory.whirlycott.com/~phil/antispam/rbl-bad/rbl-bad.html


msg89029/pgp0.pgp
Description: PGP signature


[Cooker] Re: [CHRPM] cyrus-sasl-2.1.10-2mdk

2003-01-20 Thread Brian J. Murrell
On Mon, Jan 20, 2003 at 07:46:07PM +0100, Florin wrote:
 --=-=-=
 Name: cyrus-sasl   Relocations: (not relocateable)
 Version : 2.1.10Vendor: MandrakeSoft
 Release : 2mdk  Build Date: Mon Jan 20 18:54:47 2003

Is this the start of the move to sasl v2?  I hope so.  On my Cooker
system, I show the current dependencies on sasl v1 as being:

$ rpm -q --whatrequires libsasl7
cyrus-sasl-1.5.27-6mdk
nss_ldap-202-1.1mdk
pam_ldap-156-1.1mdk

b.

-- 
Brian J. Murrell



msg86990/pgp0.pgp
Description: PGP signature


Re: [Cooker] Re: [CHRPM] cyrus-sasl-2.1.10-2mdk

2003-01-20 Thread Oden Eriksson
måndagen den 20 januari 2003 22.56 skrev Brian J. Murrell:
 On Mon, Jan 20, 2003 at 07:46:07PM +0100, Florin wrote:
  --=-=-=
  Name: cyrus-sasl   Relocations: (not
  relocateable) Version : 2.1.10Vendor:
  MandrakeSoft Release : 2mdk  Build Date: Mon
  Jan 20 18:54:47 2003

 Is this the start of the move to sasl v2?  I hope so.  On my Cooker
 system, I show the current dependencies on sasl v1 as being:

 $ rpm -q --whatrequires libsasl7
 cyrus-sasl-1.5.27-6mdk
 nss_ldap-202-1.1mdk
 pam_ldap-156-1.1mdk

Not to mention the proposed move to db4. If sasl and openldap would be 
compiled against db4, apache2 would not have to require both db3 and db4.

Ohh..., I just realized..., db4 is in contribs, what a drag, then it's a no 
go... (!)


-- 
Regards // Oden Eriksson, Deserve-IT.com