I've been thinking of altering (complementing is what i really wanted
to do) config.pl in order to provide LDAP support for lookup values.
The way i see it both actual supported methods have pros and cons;
- CSV file backend
pro - Easy to setup, for those who know what they're doing. It only
requires a basic line editor.
pro - Being accessed through samba, provides a rather good security
layer based on crypted user credentials.
con - Difficult to setup, for those who don't know what they're doing
(fairly big number of operators don't).
con - Difficult to write frontends to. Everything that involves file
read/writing is a PITA to develop.
- MySQL backend
pro - Easy to write frontends to. Almost anyone developing in the web
environment can write a frontend for that.
pro - Having a nice frontend built, one doesn't have to rely on the will
of the operator to learn. He just points and clicks.
con - At this time, that i know of, there is no support for a secure
connection by the install agent and the MySQL database. One using
sniffing software can get MySQL user and passord credentials, database
name, product keys, etc, etc.
My proposal is for another backend scheme support. The LDAP design
seems like a winning bet to me since it's aimed for queries, provides
security access to it's database through ACLs, the use of SSL/TLS and
the hability to query uppon identification, either using login/password
credentials, signed client certificates, SASL support, etc.
That said, i'd like to provide a list of pros and cons for this
approach;
- LDAP backend
pro - Highly secure connections. (SSL/TLS, certificates, ACLs, etc)
pro - Database replication based on subsets of the database hierarchy.
Have one "big" LDAP server at headquarters with all the organization
computers and "smaller" LDAP replicas in regional offices having the
computer configurations for that specific office only.
pro - Great perl-ldap API through the numerous perl modules available
out there (just search CPAN).
pro - Hability for the agent to seamlessly change it's own record state
while installing. One can think of scheduling installs (boot on lan) and
provide installed/not installed state.
pro - Hability to easily write custom frontends (or use already existing
LDAP clients) for machine install administration. The operator doesn't
have to take a college degree anymore, he just points and clicks.
con - At this time, that i know of, there is no code done to support
this.
con - At this time, that i know of, there is no LDAP schema to support
this.
Having all that said, i'd like to know what all you guys think.
I really think this can be a good thing(tm), but i'm also aware that it
can give some work to put all this up. I have a fairly good knowledge of
LDAP and i'm willing to help this coming true, either by clarifying LDAP
related issues or even writting code.
Having all that said, i'd like to know what all you guys think. My
guess is that i'm going to go on with this either way, but not only
having somebody else putting effort on it helps this happen, but also if
there is interest, this can be done in a way to "please" some other
unattended user.
Cheers,
Hugo Monteiro.
--
javali:~# cat .signature
Hugo Monteiro
Email : [EMAIL PROTECTED]
Telefone : +351 916993183
JavaLi - ADSI, Lda.
Madan Parque Edifício VI Campus da FCT/UNL
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212949666 Fax: +351 212948313
www.javali.pt [EMAIL PROTECTED]
javali:~# _
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
unattended-info mailing list
unattended-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unattended-info
