-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FACORAT Fabrice wrote: > Thanks to wizard package, installing an apache/postfix/bind server is > easy. MCC make setting up a system easy. > Now the remaining problem is managing several client from the server, > i.e from one computer manage remotely others computers ( packages > installation/management, menu, printers/scanner management, mount point > + nfs/smb shares, security settings, users management, service > management, backup, log ). In other word, use most of actual drakxtools > remotely. > > Ok, you can use ssh -X, or drakxtools-http ( I wonder if it's still > working ? ). But If you want true network management -> no way. > This Network Mandrake Control Center ( NMCC ) should have : > > 1�/ a client part that will respond to commands, send > informations/status and a server part that will send commands and > display informations/status > > 2�/ server client communication must be encrypt. For example SSL is a > good start. > > 3�/ you should not have to enter a password in order to have access to a > client. We'd better think about something like ssh. On the client you > generate a key ( from client configuration panel ), you grab the key and > on the server you add a client, specify the key and the group. On the > client configuration panel, you enter the IP of the server ( this will > configure in fact /etc/hosts.allow and /etc/hosts.deny ) > > 4�/ you should be able to defined group. Theses groups could share > common configuration and you could have the possibility to apply > settings simultaneously to all client belonging to this group. > > 5�/ from server you should be able to see easily : > computer basics information ( short host name, IP ). If the computer is > down, it should say it ( in fact if the client is not responding you can > consider that the computer is down, unless you have network problem, or > the client crash ). By clicking on "more info", you should be able to > have more details. > As you may want to see some informations when the client is down, the > server should maintain a cache of client configuration/informations. > This cache could be in XML for example. Why XML ? marketing reason for > example. "New Network Mandrake Control Center allow you to manage easily > your network infrastructure securely thanks to SSL support and use > innovative technologie like XML". > On top of that you can then use XML/XSL ( http://www.w3.org/Style/XSL/ ) > to easily generate the page. > > 6�/ you should be able also to scan network to see available computer ( > for example by pinging broadcast ) and know if you have NMCC client > running, or if Windows, or if Linux without NMCC. having the ability to > scan computers from server and see open ports could be really useful > too. > > 7�/ the server should be thread if possible, or at least use one process > per client, each process the communicating with the core which display > informations. > > 8�/ server interface should be HTML/XHTML. Server can use PHP, or Perl > or cgi. Client should be able to use perl drakxtools modules. The > interface should be gtk and very simple as you just need to generate the > key, enter server address. > > > This tool is part of my reflexion about mandrake usage in big network > environment, as prime class server.
I have some issues with your implementation concept. And, before deciding on an implementation concept, we would need to list requirements (and from a Mechanical Design procedure point of view, the weigthing on requirements, engineering requirements, engineering specifications). For instance, you might want to ensure that even if a machine in a group is not accessible when you make the change, that the change should be applied to the machine as soon as it is able to apply the change. Also, if you are going to be applying changes like this, they should also be tied to an authentication database. You may also want to cover the interaction of users in the configuration. Although this is premature from a design procedure point of view, my concept would be to store the configuration in LDAP. Configurations could be grouped by OU. User settings could be stored in LDAP (or at least the defaults for a group). LDAP also gives you authentication, TLS support, dedundancy, rights management (allow a non-root user to set default settings for a certain group of machines or users). In effect, we need something as capable as Netware's NDS/eDirectory or MS AD. Both of those are basically LDAP servers. Real advantages of LDAP right now over other solutions: LDAP is a good standard, it would be feasible to have clients running any OS access the settings in LDAP. LDAP is also read-optimised (which you will likely want). OpenOffice.org was planning on being able to store some settings in LDAP. Netscape could at one stage (and I believe there is a project for Mozilla to re-implement this). KDE should likely also use LDAP. aA gconf backend for LDAP is feasible. The Kolab project uses LDAP for server configuration storage. You can store SSL certs (and maybe even GPG certs) in LDAP. There is a patch for ssh public keys in LDAP. You can store DNS and DHCP configuration in LDAP (may require a patch for DHCP and an extra backed for DNS). Samba stores it's domain-related information in LDAP when using multiple domain controllers. Postfix can store lookup tables in LDAP. Amavisd-new supports per-user settiings in LDAP. autofs supports automount maps in LDAP. I don't think there is a good reason to support something besides LDAP, and LDAP is feasible from about the point where you have >5 machines running Linux. 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/fZT5rJK6UGDSBKcRAqhBAKDFc3PAa2ZPQfesepdcO7eg7FUCqACeLMNg unV+uwZSvyqZ2HMO5bi0N8Y= =QjuS -----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. *****************************************************************
