Menu
▾
▴
python-ldap-dev
|
From: Jacek K. <ja...@bn...> - 2001-11-11 10:45:27
|
On Sun, Nov 11, 2001 at 08:26:57PM +1000, David Leonard wrote:
> Can you give an example of what a python program might look like
> using these?
The only thing I implemented and tested now is the ldap.initialize().
This works like that (this will start LDAP over SSL connection):
import ldap
l=ldap.initialize("ldaps://some.ldap.server")
l.bind("","")
...
I am currently testing those options (OpenLDAP API is not documented
very well).
I think it would work like this (using StartTLS):
import ldap
l=ldap.initialize("ldap://some.ldap.server")
l.tls_cacert_file="cacert.pem"
l.tls_cert_file="mycert.pem"
l.tls_key_file="mykey.pem"
l.tls_require_cert=1
l.start_tls_s()
l.bind("mydn","mypasswd")
Using LDAP over SSL it whould be:
import ldap
l=ldap.initialize("ldaps://some.ldap.server")
l.tls_cacert_file="cacert.pem"
l.tls_cert_file="mycert.pem"
l.tls_key_file="mykey.pem"
l.tls_require_cert=1
l.bind("mydn","mypasswd")
You can use ldap.init() instead of ldap.initialize(). ldap.open()
should not be used as it is depreciated, and it won't work for LDAP over
SSL (as connection would be open before tls options are set).
It seems some of OpenLDAP options (eg. LDAP_OPT_DEBUG_LEVEL) are global
flags, not specific to any LDAPObject. So we need some interface to set
those for whole ldap module. I don't know how to implement this.
Should it be some function like ldap.set_option(), or a global variable
set like attribute of LDAPObject. Is ther C interface for such thing?
I have not yet checked if TLS options all global or connection-specific.
Greets,
Jacek
|
|
From: Michael <mi...@st...> - 2001-11-11 14:20:14
|
Jacek Konieczny wrote: > > On Sun, Nov 11, 2001 at 08:26:57PM +1000, David Leonard wrote: > > Can you give an example of what a python program might look like > > using these? > > The only thing I implemented and tested now is the ldap.initialize(). This whole stuff including your Python examples looks reasonable to me. > You can use ldap.init() instead of ldap.initialize(). ldap.open() > should not be used as it is depreciated, and it won't work for LDAP over > SSL (as connection would be open before tls options are set). Keep the name ldap.initialize(). That makes it easy to find it in ldap.h. BTW: Support for ldapi:// (local domain socket) should be possible with this either. I'd also appreciate if you could manage to use ldap_r and wrap it in such a way that python-ldap is re-entrant. Do you think that's feasible? My module ldapthreadlock is just a weird work-around with some serious deficiencies. > I have not yet checked if TLS options all global or connection-specific. I would assume that TLS/SSL options are connection-specific since you might have different trusted root CA certs, etc. Does the OpenLDAP API expose a call-back interface to implement CRL checking and such? Ciao, Michael. |
|
From: Jacek K. <ja...@bn...> - 2001-11-11 15:13:48
|
On Sun, Nov 11, 2001 at 03:20:06PM +0100, Michael Str=F6der wrote:
> Keep the name ldap.initialize().=20
That is what I have done.
> That makes it easy to find it in
> ldap.h. BTW: Support for ldapi:// (local domain socket) should be
> possible with this either.
I think so.
> I'd also appreciate if you could manage to use ldap_r and wrap it in
> such a way that python-ldap is re-entrant. Do you think that's
> feasible?=20
I don't have any experience with threads. I may try, but I could make it
wrong.
> My module ldapthreadlock is just a weird work-around with
> some serious deficiencies.
> Does the OpenLDAP API expose a call-back interface to implement CRL
> checking and such?
It doesn't seem so. There is no trace of any CRL handling in ldap.h nor
i the openldap sources.
But I hope they will fix it soon.
Greets,
Jacek
|
|
From: Jacek K. <ja...@bn...> - 2001-11-12 10:16:40
|
On Sun, Nov 11, 2001 at 03:20:06PM +0100, Michael Str=F6der wrote:
> > I have not yet checked if TLS options all global or connection-specific.
>=20
> I would assume that TLS/SSL options are connection-specific since
> you might have different trusted root CA certs, etc.
I have checked this and it turned out, that mose TLS options are global,
and cannot be set per LDAPObject.=20
To support global options (which can eventualy be available as object
options) I have moved part of setattr and getattr of LDAPObject to other
functions, which can also be used without object for setting global
options.
Here is (working) fragment of python-ldap program:
import ldap
ldap.set_option("tls_require_cert",1)
ldap.set_option("tls_cacertfile","my_cacerts.pem")
l=3Dldap.initialize("https://some.ldap.server")
l.tls=3Dldap.TLS_HARD
l.bind("","")
Should I commit the changes (as soon as I polish them a bit more)?
And is there any way to make it work like this?:
ldap.tls_require_cert=3D1
It is easy for object (that is the way it is done for LDAPObject), but
is there any way to implement this in module?
And one more thing:
Do we really need suport for OpenLDAP < 2.x?
Now python-ldap compiled with OpenLDAP1 and python-ldap compiled with
OpenLDAP2 are so different as they are different modules. And the code
is quite hard to maintain.
It was long time ago, when OpenLDAP2 was experimental.
Greets,
Jacek
|
|
From: Michael <mi...@st...> - 2001-11-12 11:00:11
|
Jacek Konieczny wrote: > > On Sun, Nov 11, 2001 at 03:20:06PM +0100, Michael Ströder wrote: > > > I have not yet checked if TLS options all global or connection-specific. > > > > I would assume that TLS/SSL options are connection-specific since > > you might have different trusted root CA certs, etc. > > I have checked this and it turned out, that mose TLS options are global, > and cannot be set per LDAPObject. > To support global options (which can eventualy be available as object > options) I have moved part of setattr and getattr of LDAPObject to other > functions, which can also be used without object for setting global > options. Well, if the TLS options are global they should be handled globally. Therefore any global option must not be wrapped by an attribute of the LDAP connection object. The application programmer has to deal with it. > Do we really need suport for OpenLDAP < 2.x? No. It was decided ages ago that we drop support for OpenLDAP 1.x, Netscape SDK and Novell SDK if we have something stable working with OpenLDAP 2.x. > Now python-ldap compiled with OpenLDAP1 and python-ldap compiled with > OpenLDAP2 are so different as they are different modules. And the code > is quite hard to maintain. You're welcome to throw away any code not needed when compiling against OpenLDAP 2.x libs. E.g. I already removed autoconf stuff from CVS. If someone needs that he/she can check out the tagged old version. > It was long time ago, when OpenLDAP2 was experimental. Yes. Ciao, Michael. |
|
From: Jacek K. <ja...@bn...> - 2001-11-12 14:17:16
|
On Mon, Nov 12, 2001 at 11:59:37AM +0100, Michael Str=F6der wrote:
>=20
> Well, if the TLS options are global they should be handled globally.
> Therefore any global option must not be wrapped by an attribute of
> the LDAP connection object. The application programmer has to deal
> with it.
The problem is, that some of the options can be used globally and
locally. Eg. LDAP_OPT_X_TLS.
But we can handle those two cases separately.
Currently I handle the global options as strings (like it was for local
options implemented as attributes). But maybe it would be better to
handle them as constants.
eg.:
ldap.set_option("tls_cacertfile","file")
against:
ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")
The first solution is shorter to use, the second is more like OpenLDAP C
API. Which one should I use? If it is to be separated from "local"
options (implemented as attribute) then IMHO the second would be better.
Currently I have the first one implemented, but it is easy to change.
> You're welcome to throw away any code not needed when compiling
> against OpenLDAP 2.x libs. E.g. I already removed autoconf stuff
> from CVS. If someone needs that he/she can check out the tagged old
> version.
OK. So I will do it. I will add "#error" for LDAP_API_VERSION < 2000
It will be easier to extend the module then.
Greets,
Jacek
|
|
From: David L. <dav...@it...> - 2001-11-12 14:53:48
|
On Mon, 12 Nov 2001, Jacek Konieczny typed thusly:
> ldap.set_option("tls_cacertfile","file")
>
> against:
>
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")
>
> The first solution is shorter to use, the second is more like OpenLDAP C
> API. Which one should I use? If it is to be separated from "local"
> options (implemented as attribute) then IMHO the second would be better.
> Currently I have the first one implemented, but it is easy to change.
the latter is better: lets you catch errors in python faster (same trick
used in Xt)
you might also like to intern the strings so you can use == in C.
> > You're welcome to throw away any code not needed when compiling
> > against OpenLDAP 2.x libs. E.g. I already removed autoconf stuff
> > from CVS. If someone needs that he/she can check out the tagged old
> > version.
> OK. So I will do it. I will add "#error" for LDAP_API_VERSION < 2000
:)
d
--
David Leonard Dav...@it...
Dept of Inf. Tech. and Elec. Engg _ Ph:+61 404 844 850
The University of Queensland |+| http://www.itee.uq.edu.au/~leonard/
QLD 4072 AUSTRALIA ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8
|
|
From: Michael <mi...@st...> - 2001-11-12 15:02:23
|
Jacek Konieczny wrote:
>
> eg.:
>
> ldap.set_option("tls_cacertfile","file")
>
> against:
>
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")
I also vote for the 2nd option.
Ciao, Michael.
|
|
From: Joe L. <jl...@op...> - 2002-01-02 01:16:16
|
On 11/12/01 7:01 AM, "Michael Str=F6der" <mi...@st...> wrote:
> Jacek Konieczny wrote:
>>=20
>> eg.:
>>=20
>> ldap.set_option("tls_cacertfile","file")
>>=20
>> against:
>>=20
>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")
>=20
> I also vote for the 2nd option.
>=20
> Ciao, Michael.
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
After a long departure (illness in the family), I'm finally returning to th=
e
various projects that I was dabbling in. I'm about to make use of
python-ldap and was starting to get my python-ldap RPM back into shape.
Well, I see that configure is now gone in lieu of setup.py (distutils) in
the latest CVS version. Simple enough. However, doing a test "make" brought
up this TLS context stuff that I see came up a bit ago here.
Specifically, a make fails with "LDAP_OPT_X_TLS_CTX" undeclared in
Modules/constants.c (203). From the discussion, it would appear code must
first declare this, but the error smacks of an incomplete implementation as
this is just the c-library and I gather that one would define it in the
runtime. I'm not fully clued in yet, but am I missing something here?=20
|
|
From: Michael <mi...@st...> - 2002-01-02 01:31:52
|
Joe Little wrote:
>
> [..] was starting to get my python-ldap RPM back into shape.
> Well, I see that configure is now gone in lieu of setup.py (distutils) in
> the latest CVS version. Simple enough. However, doing a test "make" brought
> up this TLS context stuff that I see came up a bit ago here.
> Specifically, a make fails with "LDAP_OPT_X_TLS_CTX" undeclared in
> Modules/constants.c (203).
You probably have to upgrade your OpenLDAP 2 libs. (That's what I
had to do.)
> From the discussion, it would appear code must
> first declare this,
I think you have to define all the certificate-related stuff before
you do a LDAP over SSL connect by calling
ldap.initialize('ldaps://..') or before calling method start_tls_s()
of an existing LDAPObject instance.
I did not test it very well up to now.
Ciao, Michael.
|
|
From: Joe L. <jl...@op...> - 2002-01-02 01:49:26
|
Damnit.. your right. I did my build on a virgin redhat 7.2 box with include=
d
OpenLDAP 2.0.11 and not my version of the packages. Treats me right. a beta
OpenLDAP 2.0.19 RPM sailed right through. Does anyone know where this is
fixed so that I can log it?
On 1/1/02 5:31 PM, "Michael Str=F6der" <mi...@st...> wrote:
> Joe Little wrote:
>>=20
>> [..] was starting to get my python-ldap RPM back into shape.
>> Well, I see that configure is now gone in lieu of setup.py (distutils) i=
n
>> the latest CVS version. Simple enough. However, doing a test "make" brou=
ght
>> up this TLS context stuff that I see came up a bit ago here.
>> Specifically, a make fails with "LDAP_OPT_X_TLS_CTX" undeclared in
>> Modules/constants.c (203).
>=20
> You probably have to upgrade your OpenLDAP 2 libs. (That's what I
> had to do.)
>=20
>> From the discussion, it would appear code must
>> first declare this,
>=20
> I think you have to define all the certificate-related stuff before
> you do a LDAP over SSL connect by calling
> ldap.initialize('ldaps://..') or before calling method start_tls_s()
> of an existing LDAPObject instance.
>=20
> I did not test it very well up to now.
>=20
> Ciao, Michael.
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
|
|
From: Michael <mi...@st...> - 2002-01-02 01:56:42
|
Joe Little wrote: > > On 1/1/02 5:31 PM, "Michael Ströder" <mi...@st...> wrote: > > > You probably have to upgrade your OpenLDAP 2 libs. (That's what I > > had to do.) > > > Damnit.. your right. I did my build on a virgin redhat 7.2 box with included > OpenLDAP 2.0.11 and not my version of the packages. Treats me right. a beta > OpenLDAP 2.0.19 RPM sailed right through. Does anyone know where this is > fixed so that I can log it? Hmm, looking into the OpenLDAP libs directory: liblber.so.2.0.13 libldap.so.2.0.13 2.0.13?!? Ciao, Michael. |
|
From: Joe L. <jl...@op...> - 2002-01-02 02:34:45
|
Ok.. almost done here. first, another error. It looks like Lib/ldap.py is not found and a warning is thrown. The generated files are handled differently by setup.py, and I get a different file list. Also, a noticed a version string of python-ldap-2.0.0pre1.. should I use this instead of naming it "python-ldap-cvs-pythonv" where pythonv is the pythonv compiled with (I demand at least 2.x, but people may be using 2.1 or 2.2, and site-packages are different)??? Here is the file list (/usr/share/doc excepted): /usr/lib/python2.1/site-packages .... _ldap.so ldapurl.py ldif.py ldap/__init__.py ldap/async.py ldap/functions.py ldap/ldapobject.py ldap/modlist.py There used to be an ldap.pth generated and other such, and it definitely include an ldap.py before. It also does not pre-compile any .py file. This is all changed behaviour so to speak with distutils. I cannot perform a "install" since it will only generate onto the real directories and not an alternative build root. Checking a real install, the only thing lacking is the precompile of .py files, and I believe that is not necessary. Tell me if the above list of files is insufficient. On 1/1/02 5:57 PM, "Michael Str=F6der" <mi...@st...> wrote: > Joe Little wrote: >>=20 >> On 1/1/02 5:31 PM, "Michael Str=F6der" <mi...@st...> wrote: >>=20 >>> You probably have to upgrade your OpenLDAP 2 libs. (That's what I >>> had to do.) >>>=20 >> Damnit.. your right. I did my build on a virgin redhat 7.2 box with incl= uded >> OpenLDAP 2.0.11 and not my version of the packages. Treats me right. a b= eta >> OpenLDAP 2.0.19 RPM sailed right through. Does anyone know where this is >> fixed so that I can log it? >=20 > Hmm, looking into the OpenLDAP libs directory: >=20 > liblber.so.2.0.13 > libldap.so.2.0.13 >=20 > 2.0.13?!? >=20 > Ciao, Michael. >=20 > _______________________________________________ > Python-LDAP-dev mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev |
|
From: Joe L. <jl...@op...> - 2002-01-02 02:41:24
|
on the subject of python versions.. I dropped my added string, and will rel= y on RPM to do the right thing most of the time. This _could_ break for python2.2 users, but the naming just was getting too weird. Tell me if I should keep the version string in there. It actually had to be like "python-ldap-python2.1-cvs-1.i386.rpm" or -2.0.0pre1-1.i386.rpm... On 1/1/02 6:34 PM, "Joe Little" <jl...@op...> wrote: > Ok.. almost done here. >=20 > first, another error. It looks like Lib/ldap.py is not found and a warnin= g > is thrown. The generated files are handled differently by setup.py, and I > get a different file list. Also, a noticed a version string of > python-ldap-2.0.0pre1.. should I use this instead of naming it > "python-ldap-cvs-pythonv" where pythonv is the pythonv compiled with (I > demand at least 2.x, but people may be using 2.1 or 2.2, and site-package= s > are different)??? >=20 > Here is the file list (/usr/share/doc excepted): >=20 > /usr/lib/python2.1/site-packages .... >=20 > _ldap.so > ldapurl.py > ldif.py > ldap/__init__.py > ldap/async.py > ldap/functions.py > ldap/ldapobject.py > ldap/modlist.py >=20 > There used to be an ldap.pth generated and other such, and it definitely > include an ldap.py before. It also does not pre-compile any .py file. Thi= s > is all changed behaviour so to speak with distutils. I cannot perform a > "install" since it will only generate onto the real directories and not a= n > alternative build root. Checking a real install, the only thing lacking i= s > the precompile of .py files, and I believe that is not necessary. >=20 > Tell me if the above list of files is insufficient. >=20 > On 1/1/02 5:57 PM, "Michael Str=F6der" <mi...@st...> wrote: >=20 >> Joe Little wrote: >>>=20 >>> On 1/1/02 5:31 PM, "Michael Str=F6der" <mi...@st...> wrote: >>>=20 >>>> You probably have to upgrade your OpenLDAP 2 libs. (That's what I >>>> had to do.) >>>>=20 >>> Damnit.. your right. I did my build on a virgin redhat 7.2 box with inc= luded >>> OpenLDAP 2.0.11 and not my version of the packages. Treats me right. a = beta >>> OpenLDAP 2.0.19 RPM sailed right through. Does anyone know where this i= s >>> fixed so that I can log it? >>=20 >> Hmm, looking into the OpenLDAP libs directory: >>=20 >> liblber.so.2.0.13 >> libldap.so.2.0.13 >>=20 >> 2.0.13?!? >>=20 >> Ciao, Michael. >>=20 >> _______________________________________________ >> Python-LDAP-dev mailing list >> Pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev >=20 >=20 > _______________________________________________ > Python-LDAP-dev mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev |
|
From: Michael <mi...@st...> - 2002-01-02 02:58:18
|
Joe Little wrote: > > first, another error. It looks like Lib/ldap.py is not found and a warning > is thrown. Module ldap was turned in a module package. See Lib/ldap/. > The generated files are handled differently by setup.py, and I > get a different file list. Also, a noticed a version string of > python-ldap-2.0.0pre1.. should I use this instead of naming it > "python-ldap-cvs-pythonv" Use a timestamp until a (pre-)release is done. > Here is the file list (/usr/share/doc excepted): > > /usr/lib/python2.1/site-packages .... > > _ldap.so > ldapurl.py > ldif.py > ldap/__init__.py > ldap/async.py > ldap/functions.py > ldap/ldapobject.py > ldap/modlist.py Nothing wrong with that. > There used to be an ldap.pth generated Pre-DistUtils days, was never available on Win32 anyway. > and other such, and it definitely include an ldap.py before. See ldap/__init__.py. > It also does not pre-compile any .py file. Can I pass DistUtils an option to enable byte-compiling before packaging? > This is all changed behaviour so to speak with distutils. Was byte-compiling enabled in your RPM before? How? > I cannot perform a > "install" since it will only generate onto the real directories and not an > alternative build root. What's wrong with using python setup.py bdist_rpm ? BTW: It contains byte-compiled *.pyc files in my case (tested right now). > Checking a real install, the only thing lacking is > the precompile of .py files, and I believe that is not necessary. When installing from source distribution (packaged with python setup.py sdist) this will do the trick: $ python setup.py install -O1 $ python setup.py install -O2 You could also write a small post-install script using compileall.py. Ciao, Michael. |
|
From: Joe L. <jl...@op...> - 2002-01-02 03:15:22
|
ok.. answers below. On 1/1/02 6:59 PM, "Michael Str=F6der" <mi...@st...> wrote: > Joe Little wrote: >>=20 >> first, another error. It looks like Lib/ldap.py is not found and a warni= ng >> is thrown. >=20 > Module ldap was turned in a module package. See Lib/ldap/. >=20 >> The generated files are handled differently by setup.py, and I >> get a different file list. Also, a noticed a version string of >> python-ldap-2.0.0pre1.. should I use this instead of naming it >> "python-ldap-cvs-pythonv" >=20 > Use a timestamp until a (pre-)release is done. >=20 >> Here is the file list (/usr/share/doc excepted): >>=20 >> /usr/lib/python2.1/site-packages .... >>=20 >> _ldap.so >> ldapurl.py >> ldif.py >> ldap/__init__.py >> ldap/async.py >> ldap/functions.py >> ldap/ldapobject.py >> ldap/modlist.py >=20 > Nothing wrong with that. >=20 >> There used to be an ldap.pth generated >=20 > Pre-DistUtils days, was never available on Win32 anyway. >=20 >> and other such, and it definitely include an ldap.py before. >=20 > See ldap/__init__.py. >=20 >> It also does not pre-compile any .py file. >=20 > Can I pass DistUtils an option to enable byte-compiling before > packaging? >=20 Can't seem to find any >> This is all changed behaviour so to speak with distutils. >=20 > Was byte-compiling enabled in your RPM before? How? I did a "make install" into a $DESTDIR (build root) --- make install did everything correctly in the GNU configure days. setup.py is a bit too smart :) >=20 >> I cannot perform a >> "install" since it will only generate onto the real directories and not = an >> alternative build root. >=20 > What's wrong with using python setup.py bdist_rpm ? BTW: It contains > byte-compiled *.pyc files in my case (tested right now). >=20 It fails for me since it finds python is 1.5 (which doesn't include distutils). Even changing the env to /usr/bin/python2 causes things to progress and then die out later when it goes into "Python-LDAP-2.0.0pre1" and runs setup.py again and can't import distutils (its running python1.5 again). There should be a way to handle this without env variables, since I want to be as deterministic as possible. Second, it looks like the current cvs snapshots enforce a 2.0.0pre1 version string. I'd need to diff away fro= m that but then I couldn't use bdist_rpm (you can't use it within another RPM... :) ) >> Checking a real install, the only thing lacking is >> the precompile of .py files, and I believe that is not necessary. >=20 > When installing from source distribution (packaged with python > setup.py sdist) this will do the trick: > $ python setup.py install -O1 > $ python setup.py install -O2 what do -01 and -02 do.. or is that O1 O2 (letter 'O')? Again, this sounds like it invokes actions on its discovered install dirs (/usr/lib instead of /var/tmp/%var/usr/lib). Please tell me I'm wrong :) >=20 > You could also write a small post-install script using > compileall.py. >=20 > Ciao, Michael. |
|
From: Michael <mi...@st...> - 2002-01-02 03:27:52
|
Joe, better you test the current CVS version and my recently sent diffs. IMHO we can think about packaging later... Joe Little wrote: > > >> This is all changed behaviour so to speak with distutils. > > > > Was byte-compiling enabled in your RPM before? How? > > I did a "make install" into a $DESTDIR (build root) --- make install did > everything correctly in the GNU configure days. setup.py is a bit too smart > :) You should definitely avoid using make install. The Makefile was produced by David who cannot stay away from typing make. Buuuh! But as an OpenBSD hacker he does not spend much time with thinking about RPMs... ;-) > > What's wrong with using python setup.py bdist_rpm ? BTW: It contains > > byte-compiled *.pyc files in my case (tested right now). > > It fails for me since it finds python is 1.5 You simply have to type (assuming you used make altinstall when installing the Python 2.1 version): $ python2.1 setup.py bdist_rpm > (which doesn't include distutils) BTW: There are DistUtils for Python 1.5. > Second, it looks like the current > cvs snapshots enforce a 2.0.0pre1 version string. Well, this can be easily solved... > > When installing from source distribution (packaged with python > > setup.py sdist) this will do the trick: > > $ python setup.py install -O1 > > $ python setup.py install -O2 > > what do -01 and -02 do.. or is that O1 O2 (letter 'O')? -O1 -> *.pyc -O2 -> *.pyo > > You could also write a small post-install script using > > compileall.py. And how about this as post-install script? $ python2.1 /usr/lib/python2.1/compileall.py $ python2.1 -O /usr/lib/python2.1/compileall.py Ciao, Michael. |
|
From: Joe L. <jl...@op...> - 2002-01-02 03:50:01
|
Did you just do a new commit on CVS? the -O1 and -O2 both created .pyo files only.. no .pyc files (odd, that). Anywho.. I've generated release 2, which drops the .pyo files and does the post-install compile all, though it feels somewhat wrong since I may be affecting other things on the system. Furthermore, I don't get the free chksums on the .pyo and .pyc files.. Oh well, it definitely makes the build process easier. -2 is up there, and it does dump the compileall output to the screen. Once we move beyond the cvs phase, I'll /dev/null that output since it will make for ugly installations On 1/1/02 7:29 PM, "Michael Str=F6der" <mi...@st...> wrote: > Joe, >=20 > better you test the current CVS version and my recently sent diffs. > IMHO we can think about packaging later... >=20 > Joe Little wrote: >>=20 >>>> This is all changed behaviour so to speak with distutils. >>>=20 >>> Was byte-compiling enabled in your RPM before? How? >>=20 >> I did a "make install" into a $DESTDIR (build root) --- make install did >> everything correctly in the GNU configure days. setup.py is a bit too sm= art >> :) >=20 > You should definitely avoid using make install. The Makefile was > produced by David who cannot stay away from typing make. Buuuh! But > as an OpenBSD hacker he does not spend much time with thinking about > RPMs... ;-) >=20 >>> What's wrong with using python setup.py bdist_rpm ? BTW: It contains >>> byte-compiled *.pyc files in my case (tested right now). >>=20 >> It fails for me since it finds python is 1.5 >=20 > You simply have to type (assuming you used make altinstall when > installing the Python 2.1 version): > $ python2.1 setup.py bdist_rpm >=20 >> (which doesn't include distutils) >=20 > BTW: There are DistUtils for Python 1.5. >=20 >> Second, it looks like the current >> cvs snapshots enforce a 2.0.0pre1 version string. >=20 > Well, this can be easily solved... >=20 >>> When installing from source distribution (packaged with python >>> setup.py sdist) this will do the trick: >>> $ python setup.py install -O1 >>> $ python setup.py install -O2 >>=20 >> what do -01 and -02 do.. or is that O1 O2 (letter 'O')? >=20 > -O1 -> *.pyc > -O2 -> *.pyo >=20 >>> You could also write a small post-install script using >>> compileall.py. >=20 > And how about this as post-install script? >=20 > $ python2.1 /usr/lib/python2.1/compileall.py > $ python2.1 -O /usr/lib/python2.1/compileall.py >=20 > Ciao, Michael. >=20 > _______________________________________________ > Python-LDAP-dev mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev |
|
From: Michael <mi...@st...> - 2002-01-02 12:26:02
|
Joe Little wrote: > > Did you just do a new commit on CVS? Nope. You might want to consider subscribing to list python-ldap-commits to get notification about CVS commits (low-traffic). http://lists.sourceforge.net/lists/listinfo/python-ldap-commits Ciao, Michael. |
|
From: Michael <mi...@st...> - 2001-11-11 19:24:59
|
Jacek Konieczny wrote:
>
> import ldap
> l=ldap.initialize("ldaps://some.ldap.server")
> l.bind("","")
> ...
I really wonder how a validation of the server certificate is done
in this case...
Ciao, Michael.
|
|
From: Jacek K. <ja...@bn...> - 2001-11-12 07:58:36
|
On Sun, Nov 11, 2001 at 08:24:34PM +0100, Michael Str=F6der wrote:
> Jacek Konieczny wrote:
> >=20
> > import ldap
> > l=3Dldap.initialize("ldaps://some.ldap.server")
> > l.bind("","")
> > ...
>=20
> I really wonder how a validation of the server certificate is done
> in this case...
In this case no validation is made. Some validation would be probably
done if l.tls_* flags were set between ldap.initialize() and l.bind().
Greets,
Jacek
|
Thanks for helping keep SourceForge clean.
X