Re: cipux in NEW queue
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I will here answer to the mail of the FTP team directly, because
they should have direct answers to technical questions arising
of the upload of the CipUX packages.
cipux-common
cipux-cibot
cipux-rpc
cipux-cat-web
cipux-samba
The aim of deciding about a REJECTION or not should be based on
technical aspects of the software. So we should make sure, that
we check the software carefully before accepting it.
Since the plan for CipUX is to enter other repositories in the
future it is good thing that we make this software good in concept.
Steffen Joeris wrote:
> The cipux packages were uploaded to the NEW queue[0] 3 days ago.
> After the ftp-team examined the package, we decided to move the discussion
> about its inclusion or rejection to the public developer list.
The public developer list of CipUX is cipux-devel@cipworx.org.
So every technical discussion about CipUX should made there. Not all
of cipux-devel folks are on this list. So every technical discussion
about CipUX should find it's place there.
If there are clear technical reasons, the FTP team can reject
without discussion. So I guess there are no clear technical
problems. If there are some, we should fix them first.
The goal [A] of CipUX is the upload to debian-edu, as preconfigured
software which will be installed on the first CD. That this is
easily possible shows the French add on CD.
When I answer this mail I do not refer to installation of CipUX by
individuals [B] since the goal is that they do not have to do that
(for debian-edu).
Even if [A] is the long term goal, the goal for this discussion
is to make CipUX a Debian-Edu package. Who will use it and when
is a completely different matter.
The FTP team should then tell us (the CipUX team) what we should
improve to make CipUX a Debian-Edu package. I don't think this need
a discussion.
I believe that it make sense to have packages in Debian-Edu, even if
they are used only by the French and German schools. There also
arise the question for future projects and companies: is it possible
to have packages in Debian-Edu which enhance Debian-Edu, but are not
used by all people?
> The current point which needs to be discussed is the use of the
> cipux-rpc.postinst script. This script calls various cipux commands (or a
> cipux command which calls another cipux command ...) which in the end fills
> in LDAP data. Note that I did not completely examine the script, so somebody
> else might want to give an explanation here.
Yes the cipux-rpc fills a subtree of the CipUX subtree with data.
And it do it by installation. This is the configuration data for
cipux-rpc server. You can install several RPC servers (if you like),
so the configuration data for them (for one school) should be
centralized available.
For now the cipux-rpc.postinst do the job. But maybe there are
better solutions, since CipUX is used also on other Distributions,
this should maybe not handled by a Debian mechanism.
> My personal understanding is, to
> put it into a nutshell, that cipux needs to fill in the LDAP data with own
> attributes in order to function.
Yes WLUS and LWAT too. As finnarne agreed, most lwat functions are
not useful if you have a plain LDAP tree from plain Debian. The
filling of the LDAP tree is the obligation of Debian-Edu. So if
Debian-Edu fills the tree cipux-rpc do not have to.
> I would consider this as a violation of the
> debian policy, because it adds (without noticing) ldap data which no admin
> would expect while installing it and it gets not removed during a purge.
If you consider the slapd from plain debian as Debian policy conform
installation with its basic tree layout. Then you must see that
Debian-Edu is a policy violation by it self, since it adds several
objects and 2 schemata for lwat or itself to work.
The discussion shows that adding files to a file system and adding
entries to a LDAP database is no violation.
The LDAP database is under /var/lib/ldap and not under /etc. So it
is not a policy violation. Or tell the paragraph of the Debian Policy.
You said the that "adds ldap [...] data which no admin would expect
while installing" is a problem. If you install Debian-Edu (goal [A])
then you will expect that the LDAP will be filled. If you install
CipUX by yourself (goal [B]) you also would expect that CipUX add
data to the LDAP. The "without noticing" is the character of
Debian-Edu, since we want to provide an easy to install LDAP-Edu server.
Only the point "it gets not removed during a purge" seem to be
a part where we can discuss.
If the majority agrees we can arrange the purge of the data. That is
no problem. But some admins might look very sad, when we do that. We
also could remove every object CipUX creates. But do a lwat purge
delete all lwat created objects? Do we want that? Maybe not.
I think, Steffen if you consider this as a violation, you are wrong.
I would like to hear the other opinions of the FTP team here.
Conclusion:
Debian-Edu is _not_ policy conform. cipux-rpc is policy conform.
debian-edu will install cipux-rpc and not the admin, so there is no
problem. If someone would like to have a purge of what ever we can
arrange that.
> The question here would be, if this is really a violation, if so how can it be
> avoided or in a drastical case, do we want to ignore it and consider it a
> special case, which is possible through our policy[1], but strongly not
> recommended and should only be a temporary solution.
It is clearly not a violation! But we should provide a good
installation procedure.
I also deeply suggest from the bottom of my heart, we should not
make a temporary solution.
> My question now is concerning debian-edu, is it really necessary to change the
> LDAP data and if so why?
The following questions (backwards compatibility, migration, update
path, ...) are not package related questions. They are important for
Debian-Edu. And should be addressed on this list, when we discuss if
CipUX should be the default tool, or lwat or both.
So I will skip the answer to this questions for the moment.
Greetings
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGFCQfrKb2iXSP9HYRAuHvAJ913vvcZ2GUIevuA1/hFa9KofoyKACfUhm/
XtfIT8gprqJn6Q91I3uUT7k=
=tjC/
-----END PGP SIGNATURE-----
Reply to: