-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FACORAT Fabrice wrote: > Thanks to drakauth we can easily change auth method and even specify > auth method during installation. So setting a client is easy. This is > possible because PAM give use flexibility.
BTW, drakauth is not complete. I have been working with Pixel on some aspects of preparing for AD support (which involves kerberos, so if someone has a Unix kerberos setup to test that could probably be supported quite easily too). Also, we want to test with pam_ldap and kerberos finding the servers via DNS (both support it), we just need to do the work for doing the DNS queries to see if we need to hardcode anything or not. > > Now the remaining part is is sever. We need a wizard that allow us to > set a LDAP/NFS/SMB server very easily. > You can do several things : > > 1°/ user management. > - you can just migrate previously created user in /etc/passwd thanks to > userdrake userdrake isn't the best way to do this. migration-tools is (IMHO), and I have a small script as prototype. > - you can set LDAP auth and then create user in userdrake ( need > reliable LDAP support ) > Userdrake should be the preferred way to manage users in LDAP. At present, the best tools for this are IMHO smbldap-tools and directory_administrator (followed by phpLDAPAdmin). > > 2°/ server configuration : > Now, when you want to set up a LDAP server you have several manipulation > to do ( http://www.mandrakesecure.net/en/docs/ldap-auth2.php ). This > wizard should do all necessary steps ( ACL, ask for users migration from > /etc/passwd, ... ) and just ask for needed information. Some of this can possibly be simplified using regex-based ACLs. For kerberos+ldap, we also need mapping to SASL (which I have looked at briefly but not tested). For LDAP setup, you would also want to do things like: - -setup an LDAP slave (this takes a number of steps to do, although I think I have a working method) - -add more schema files (this is non-trivial, as the schema files must be enabled on all LDAP servers before you add any attributes from the schema files). Schemas are also about the only thing that can't be done via LDAP ;-). - -referral and delegation support. - -Kerberos support for authentication of the master to the slaves for updates (we currently use randomly generated passwords, but Kerberos would be better, however then the tickets need to be renewed also). Of course, you would want to TLS/SSL the whole thing, which also means we need certificate management (since OpenLDAP with TLS now wants to have a verfiable cert for TLS). And for TLS/SSL to work right, you also need working DNS ... For kerberos, we need working NTP also, ideally ntpd should be able to find it's time server via DHCP or DNS (it has support for neither, so maybe some script needs to check for this). > > 3°/ directory export ( NFS/SMB ). > we can easily set remotes share thanks to diskdrake, but we don't have > the server part. You can export shares from Konqueror and Nautilus. Also check out ksambaplugin, and swat-clone from perl-Libconf CVS. > select directory to export, set ACL ( options, authorized hosts ). ACLs should be set in the filesystem instead (even MS "best practices" say so). > As we > may want to set different options for each share, the wizard should > first show actuals share ( directory protocol ), if you double click you > can see the options ( export options, authorized hosts ). Thanks to an > "add Share" button, you can add a share. First you select the directory, > then you select the protocol ( SMB and/or NFS ), depending on your > selection you can select some options ( defaults ones should good ), > then you select which hosts are authorized. Try the directory-properties thing from ksambaplugin. It can do all this for samba shares. > > 4°/ LDAP/Samba server ( optional ) > > Now samba 3 is out, it's time to push out all these NT4/2000 server > using the duo LDAP/Samba to authenticate windows clients. In the wizard > this should be just a matter of select an option ( set LDAP/Samba server > for windows clients ) It's note quite that simple, *yet*. We need group mapping setup, otherwise you don't get working domain groups, and no-one can be a domain admin. > > 4°/ mail server + LDAP > > we could centralise also some settings in LDAP. The same for Squid is > possible, etc ... > > This tool is part of my reflexion about mandrake usage in big network > environment, as prime class server. I agree with most things. However, we can't *just* rely on Wizards. What happens when the user has set up everything with the wizard, and then they need one change? I think the new printerdrake/userdrake framework should be used for all new server admin tools (or something more comprehensive). There is a lot to do, so I think we need to start with some design work on the Wiki .... Regards, Buchan - -- |--------------Another happy Mandrake Club member--------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/faRDrJK6UGDSBKcRAhSDAJkBf1xzGA1SW1PwA3V1Yl+Xg78l4wCgvgPX QWB1l9N7gxfgaN2gIgypjfY= =Rv2t -----END PGP SIGNATURE----- ***************************************************************** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *****************************************************************
