On Sex, 2005-10-14 at 15:19 +0200, Steffen Kaiser wrote:
> On Fri, 14 Oct 2005, Hugo Monteiro wrote:
>
> > - LDAP backend
> >
> > pro - Highly secure connections. (SSL/TLS, certificates, ACLs, etc)
>
> Hmm, you can have SSL und TLS, but where comes the authentification
> information from? Do you sit beside the computer to install and enter the
> passphrase of the private key each time, the computer reboots?
No. The certificate gets copied from the tftp server while booting for
instance, and that can be controled by the client hardware address.
While i refered certificates i was doing just that, refering them and
questioning about the possibilities. The main gain i see is really the
secure channel, even if not using certicate authentication, while
retrieving the csv/mysql/ldap information.
> Do you have the passphrase in the image, ready to be taken by anybody who
> fortunately sit at the next computer in the lab?
To check a client authenticity, the client doesn't have to provide any
passphrase. It has to have a signed certificate by the CA the server
knows about.
>
> I'm thinking that you overexagerate the usefulness of SSL in this
> situation, unless you can secure the install process heavily.
>
It's always better to do an effort than no effort at all. One thing that
i would mind is to have someone nagging me about this guy that's using
an illegal copy of software with a license that's supposed to be mine.
> > 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.
>
> See above.
> Also: The tag in the LDAP server is "passive"; if you want to act on it,
> you have to poll it. I'd thinking about a server waiting for "DONE"
> packets and update and reconfigures the DHCP menu at time.
I like better to have pull solutions rather than push ones. Imagine your
client lives in a private routeless network from the outside. How will
your server tell your clients what to do? Reconfiguring a service is
most times synonim of downtime. Having a dhcpd server running up and
down while installing several dozens (maybe hundereds) of clients
simultaneously is NOT a good idea.
>
> > con - At this time, that i know of, there is no code done to support
> > this.
>
> con - it's "yet another backend". Some will be more familliar with LDAP
> than CSV or mySQL (well, I am, too); but the other ones won't see no
> advantage. I would probably prefer LDAP over CSV, too, but I'm also able
> to put together a script that streams the data from LDAP into CSV.
Whenever i can take a shortcut i do it. Why have a script translating
when systems can easily talk to eachother?
>
>
> > con - At this time, that i know of, there is no LDAP schema to support
> > this.
>
> Well, that's a "pro" actually in my mind. You haven't written that very
> same con with mySQL.
>From my understanding, there IS something done for MySQL, otherwise it
wouldn't work. Might be only a table, but apparently it's all it takes.
It exists and someone took time to do it. Ah ... don't forget the table
by itself does nothing, someone also put some code in the install agent.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/unattended-info
