Steffen Joeris wrote: > Hi fellowers > > 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. > I set the reply-to to [email protected], please keep it on that > list.
I'm not a native english speaker, but please, all, try to make sure you write what you mean. I guess it's not up to the ftp-team to decide if a package should be _included_ or rejected, but rather if the package should be _accepted_ or rejected. I guess it's up to the developers and this list to decide if a package should be included or excluded from the CD/DVD. > 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. 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. 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. > 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. The ldap database as delivered from the debian slapd-maintainers is not suited for using together with neither wlus nor cipux. I'm not even sure it's possible to use with an email-server (for the email to know where to deliver/fetch the emails...), without adding additional ldap-schema's into slapd. I know it's not possible to use it with lwat, the way lwat is preseeded in debian-edu, but that's because lwat (in debian-edu) is set up to replace (or be compatible with) wlus. I would suggest the use of some other schema's (authldap.schema instead ow the custom courier.schema), but that would also require some small rewriting of the configuration for exim and courier. It should not be to much of a problem to rewrite debian-edu-config so that the ldap-db is cipux-compatible when the install is finished. > My question now is concerning debian-edu, is it really necessary to change > the > LDAP data and if so why? I think you should change the schema's used by ldap, to make it more compliant with standard schema's. But I don't think the changes included by cipux is the correct way to go. On a side note, I think a more standard schema-compliant setup would make it easier to be feide-compliant as well. > 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? As long as you don't touch the settings for pam-ldap and nss-ldap, the accounts will work, but they wont show up in cipux. > 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? Upgrading should work, but taking a DB out of the server, installing from scratch, and then adding back the old DB, would require the ldap-db to be rather clean. I think it's the wrong way to do the upgrade. Normally there would be a tool that would adjust the database during the upgrade. Doing a clean install, then adding back the db would require the possibility to run such a script. > Another question I would like to add is if cipux will work with other > adminstration systems. In the debian-edu repository there is lwat and i am > not quite sure what debian offers. 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 know I _could_ make lwat create accounts that cipux can understand. But I wont do it until someone pays me to do it (and then why not just use cipux?) the reasons is: - I think it's wrong to further customize the ldap database layout like cipux does - I think it's wrong to implement another security layer like cipux does (adding dn: cn=cipuxadm,... with the same rights as rootdn), with the password stored on disk I know that accounts created in cipux will shop up in lwat, and it's possible to set a new full name, change password, change group membership etc., but I will not guarantee that the account is cipux-compatible after they have been edited with lwat. > Please note that our intention is not to start any flamewar, but to start a > technical discussion to find out which way we want to go and which way suits > us best. Please also make sure that you all proofread before you send, and also that you read it twice before sending, so that we can rule out misunderstandings. Also, please make sure you read things twice, and give the author some doubts, since very few of us do use english on a daily basis. -- Finn-Arne Johansen [EMAIL PROTECTED] http://bzz.no/ EE2A71C6403A3D191FCDC043006F1215062E6642 062E6642 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
