On 11/06/2010 01:38, Garrett Cooper wrote:
On Nov 5, 2010, at 11:49 PM, Warner Losh wrote:
On 11/06/2010 00:04, Garrett Cooper wrote:
On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh<i...@bsdimp.com> wrote:
Just to add to that (because I do find it a novel idea), 1) how
are you going to properly prevent man in the middle attacks (SSL, TLS,
etc?), and 2) what webserver would you use?
https or ssh.
We're also toying with the idea of having a partition that you could
'dd' your certs and keys to (so any system can customize the image
with keys to make sure you were talking to who you think you are).
We'd just reserve 1MB of space on partition s3. We'd then check to
see if there was a tar ball. If so, we'd extract it and do the
intelligent thing with the keys we find there.
Wouldn't it be better just to go with a read-write media solution
(USB) like Matt Dillon was suggesting at today then?
That's exactly what I'm doing, i think. I didn't hear matt's suggestion at
all, so I have no idea what you are talking about.
Summary: DVD load times are ridiculous; just go straight for a fat (4GB
uncompressed, 1.7GB compressed) USB image. I think it's a bit big, but with all
of the binary packages in ports, it might be around that size.
ah, ok...
my idea was that you could do this with an image you'd DD to a usb stick. For
the cdrom, you'd need to do more complicated things, which I hadn't though
about earlier... While I thought of this for vm creation mostly, I can see
cdrom booting might be desirable too...
Yeah... I boot from CD by default and so do a number of other users of course
(despite the fact that it's an archaic 1980s technology :)...).
CD's are desirable, if possible, but DVDs as a last resort...
Then again,
determining the root device to date is still a bit kludgy isn't it?
Not anymore. ufs labels and glabel make it almost bulletproof.
Good point -- forgot about that. Which reminds me that I need to test some geom
things related to this.
I bring up the former item because I wouldn't want my data going
unencrypted across any wire, and what BSD compatible web servers did
you guys have in store and who would maintain the server, and what
kinds of vulnerabilities would you be introducing by adding a service
which would be enabled by default at runtime?
The web server would just be there at installation time. You'd run it
out of the ram disk and it would evaporate when the system reboots
after it being installed.
Sure.
Also, I'm not sure we even need to have to have a set of prompts. If
we do the web page right, we likely can just go directly to lynx...
Well... I like the curl idea a lot more for this approach (esp because
it supports more protocols than just http and ftp, whereas lynx is
constrained to ftp and http for the most part), but having both
solutions is more heavyweight for the task than it probably should be.
I must be explaining badly. lynx isn't for downloading anything from the web,
but connecting to the web-server that's running on your box to configure the
box before the install happens. You don't need https for that, and while I
suppose we could offer the uber-geek ftp install via command line extensions to
ftpd, I hadn't planned on that :)
Well... what do you mean by "before the install happens"? What kind of
information would one specify in that state to get the machine from an effectively halted
state to a singing and dancing I'm installing FreeBSD state?
Before the install happens means before the install happens... The
paradigm is that you gather all the info, then write a config file, then
go. 'before install happens' is before the 'go'.
I have no idea what the curl idea is. Maybe you could explain to me what you
are suggesting here.
Summary: push and pull data to and from the backend via curl. There wasn't much
else to it other than that...
ah, ok. so not really relevant to what we have in mind... the web app
for the install runs on this box being installed...
Warner
Thanks,
-Garrett
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
