[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