[SAMBA4] Python Status

Andrew Bartlett abartlet at samba.org
Sun Dec 30 06:20:50 GMT 2007


On Fri, 2007-12-28 at 15:48 +0100, Jelmer Vernooij wrote:
> 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? 

The code currently requires FEdORA_DS or OPENLDAP from their respective
CVS repositories (because I'm integrating memberof support).  It should
point at the --prefix you supply to their configure scripts. 

> > > 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.

That's fine.

> > > 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 thought you said that would be trouble?  I'm happy to have both for
the timebeing.

> I'll also see if I can get a command-line vampire going. Does the one in
> SWAT work correctly at the moment?

I didn't test for alpha2, sorry..

> > > 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.

I really liked the global setup - you can still do bits and pieces, you
just have to call the global setup first.  But I'm happy to work to a
reasonable compromise.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20071230/8bbc24ab/attachment.bin


More information about the samba-technical mailing list