Re: cipux in NEW queue
Kurt Gramlich schrieb:
Hey Guys,
>
> Not ldap date but it builds up a ldap tree. Regard CipUX with its
> functions more as a replace for webmin as a replace for wlus.
>
> AFAIK DebianEdu configures his own LDAP tree since we are using
> Openldap.
>
> Did you test that it gets not removed during a purge?
Yes. As I see it, it is not possible to remove cipux completely from the
system and having everything as before.
=> violation of the debian policy.
>
> To build up a ldap tree has to be, anyway which one. Without you
> are not able to use ldap.
>
> So in my view it is not a violation of our policy.
You modificate things of another package... if we can't use the other
package without doing that or not is not important. The only important
thing is here that config files and data of another package is changed.
So this _is_ an violation of the debian policy.
My aim is it to get every debian-edu specific package RC-Bug free and
include it into debian (and yes: debian-edu-config violates the policy
too, but we are working on this issue and i don't thing we need another
packages which we have to fix afterwards to fullfill the policy, one is
enough)
>
>> My question now is concerning debian-edu, is it really necessary to change the
>> LDAP data and if so why?
>
> Yes, because our users need it. We will fullfill the needs of or
> users.
Yes, The needs of our users are very nice, and should be one(!!) aim.
The other one should be to get everything into debian in order to have
next release everything in the debian archive.
This is very important for us, since we don't have the manpower to
maintain such huge packages on our own if there raise up security issues.
>
> You might discuss if we use another database to store the data.
> But i think its the best to use only one.
>
>> Is there any backwards compatibility with the old LDAP data, e.g. will the old
>> users show up or can an admin just insert an old ldap backup and everything
>> works?
>
> Would be nice to have.
>
>> Do we care about backwards compatibility or how do we want to offer
>> Debian-Edu/Skolelinux 3.0 and keep the admin effort to a minimum while
>> upgrading to the new version?
>
> Yes we care, if the manpower is enough to do it.
You say it:
But we don't have the manpower to do it. So all new packages should fit
perfectly into the existing debian-edu profile.
>
>> Another question I would like to add is if cipux will work with other
>> adminstration systems.
>
> What do you mean? Other ldap trees? lwat? webmin? wlus? ghosa?
>
>> In the debian-edu repository there is lwat and i am
>> not quite sure what debian offers.
>
> It is perhaps a little late to ask this queation? I have checked
> other alternatives and i did not found, what our users need. So i
> believe, CipUX is the choice.
>
> We have CipUX here in german schools running because the admins asked for
> the functionalities. CipUx is running in french schools because
> of the users needs ...
Mh... i had a deep look into cipux the last weeks, and I figure out that
there are many features missing we strongly need:
- a working useradmin tool
-> edit/add userspecific data
-> .... (see my last email for details)
When do you want to include all these features? Of course it is possible
to hack them in one week, but then you don't have enough time to test
and you would upload a software into our archive which i would consider
as "alpha" ... and sorry cipux team... at the moment i consider cipux as
alpha:
I tested it twice and for an tool which should be productive it has
_very_ many errors. In my first test cipux was completely unusable.
And as you write above: It is in my eyes much too late to speak over an
admintool.
Etch will be released in 2-3 weeks. and I remember that we want to
release right after them.... this is not much time to make the necessary
changes to cipux and to test it and to be sure that it works.
>
>> I am bringing this specific question up,
>> just out of interest, please note that it is not the intention of the
>> ftp-team at this stage to make a decision about which administration tool we
>> want to use or if we want to decide in favour of one.
>
> I do not think, that the ftp-team should decide this.
of course, who else?
Greetings
Patrick
ps: Sorry that I so often used the policy as an argument, but this is
indeed very important for us since we, as you above figured out, we
don't have the manpower to maintain and secure a large pool of packages.
To avoid this we must include our packages into debian, so that the
debian security-team can help us with the issues.
--
.''`. Patrick Winnertz <patrick.winnertz@skolelinux.org>
: :' : GNU/Linux Debian-Edu Developer
`. `'` http://www.der-winnie.de http://d.skolelinux.org/~winnie
`- Debian - when you have better things to do than fixing systems
Reply to: