[SAMBA4] Python Status

[Jelmer Vernooij]

Am Freitag, den 28.12.2007, 18:47 +1100 schrieb Andrew Bartlett:
> On Fri, 2007-12-28 at 01:06 +0100, Jelmer Vernooij wrote:
> > To try out the Python provision code with make test, export 
> > "PROVISION_PYTHON=yes". Note that this won't show anything different as the 
> > EJS and Python provisioning scripts do exactly the same thing.
> I get:
> 
> PROVISIONING MEMBER...schema_fsmo_init: no schema dn present: (skip
> schema loading)
> naming_fsmo_init: no partitions dn present: (skip loading of naming
> contexts details)
> pdc_fsmo_init: no domain dn present: (skip loading of domain details)
> schema_fsmo_init: no schema head present: (skip schema loading)
> naming_fsmo_init: no partitions dn present: (skip loading of naming
> contexts details)
> pdc_fsmo_init: no domain object present: (skip loading of domain
> details)
Those warnings are always there except they are hidden by EJS somehow
 at the moment. I'll see if I can get them hidden here as well.

> I think you should also test the LDAP mode:
> PROVISION_PYTHON=yes TEST_LDAP=yes OPENLDAP_ROOT=/data/openldap/prefix
> make testenv
> 
> Traceback (most recent call last):
>   File "./setup/provision.py", line 137, in <module>
>     if not opts.ldap_module:
> AttributeError: Values instance has no attribute 'ldap_module'
Thanks, I'll see if I can fix this. Is there some documentation on how
to run with TEST_LDAP? I.e. what should OPENLDAP_ROOT point at? 

> > All of the Python bindings and functions, except for the ones in 
> > samba.samba3.upgrade, have matching tests.
> Is there anything particular getting in the way of upgrade tests, aside
> from time?
It's time. I didn't focus on them for now because upgrade was broken
with EJS anyway and we can always fix it later.

> > The following things also still need to be finished before Python can
> > provide everything that EJS provides right now:
> > 
> > * DCE/RPC bindings: There are no Python bindings generated by pidl
> >   yet. This is probably the biggest thing at the moment.
> Should we have DCE/RPC bindings, or libnet bindings?  While it's more
> work to provide sane APIs, perhaps that is more at the level python
> programmers want?
> 
> (I actually suspect they want both).
I agree. The DCE/RPC bindings can be autogenerated and may be useful for
testing purposes. I would also like to convert my GTK+ utilities to
Python at some point. The libnet bindings will be useful for those that
need higher-level calls and don't care about how.

> > * dsdb/samdb/ldb_modules/tests/samba3sam.py doesn't pass yet (port of
> >  ../testprogs/samba3sam.js)
> > * lib/ldb/tests/python/ldap.py doesn't pass yet (port of 
> >   ../testprogs/ejs/ldap.js)
> > * Install python modules into system. At the moment only the smbpython
> >   binary is installed, but it would be nice if "ordinary" Python users 
> >   could also use the Samba python modules.
> > * SWAT: The web server code still uses EJS. We could probably postpone
> >   this until after the switch to Python.
> I would at least like to see a command-line way to vampire a server
> before we killed SWAT (as there isn't another way to do it in one
> spot). 
I'm not sure we have to kill SWAT just yet. We can keep it in EJS and
 simply call the provisioning code written in Python (didn't think of this earlier).
I'll also see if I can get a command-line vampire going. Does the one in
SWAT work correctly at the moment?

> > However, I'm interested in feedback on the Python code at this point. I
> > will continue working on finishing the support for Python (hopefully done by 
> > the first week of the new year..). And I will of course send a
> > merge request once I'm actually done...
> I don't like the way we no longer use a global dictionary for the
> substitutions.  I would prefer to have all subs available in all files,
> if possible.
> 
> This pattern:
> 
>     setup_add_ldif(samdb, setup_path("provision_rootdse_add.ldif"), {
>         "SCHEMADN": schemadn, 
>         "NETBIOSNAME": netbiosname,
>         "DNSDOMAIN": dnsdomain,
>         "DEFAULTSITE": DEFAULTSITE,
>         "REALM": realm,
> 
> Seems to defeat the purpose of having these consistent subs in the first
> place...
I have no objections going back to a single dictionary per function,
however I would like to not have a global one since it is then possible
to run individual pieces of the provisioning, such as just seting up a
secrets database. That really helps with testing (it allows you to just
test setting up a secrets database) and with the upgrade code.

Cheers,

Jelmer
-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
Jabber: jelmer at jabber.fsfe.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.samba.org/archive/samba-technical/attachments/20071228/0d5af1e6/attachment.bin