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. > 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 :)...). >> 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? > 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... 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"
