However, now that flash memory is so cheap, I do think we should also look at solid state boot configs built around a lightweight, readonly filesystem image augmented by TMPFS and a small writable filesystem for configuration purposes (i.e. an extension of the install boot model).
The main limitation of flash memory is the number of update cycles, so we'd need to keep these to a minimum (hence use use of a readonly filesystem and TMPFS).
Flash-only appliances should have better boot reliability, lower power requirements and will generate less noise. They might also provide more convenient update options (e.g. just download the latest image to a PC, put the appliance's flash card in the PC's card reader, update, replace, reboot and you're done).
Phil [EMAIL PROTECTED] wrote:
I think the appliance concept is a great idea! What is first needed is to determine the base install is. Min packages=min vulerabilities.I don't think this is necessarily true; removing packages may make a system harder to maintain and that in the end may cause more vulnerabilities, not fewer. There are a few things I think are more important for appliances: - SMF'ing the services which haven't been SMF'ed yet and which currently cannot be easily disabled (work in progress at Sun) - SMF profiles for certain appliances (which services are needed for which appliance) - Resilient reboots. To understand what I mean with the latter: I have a single disk VIA C3 appliance (5 ethernet ports) running Solaris b29 (all packages!) Recently a blown lightbulb tripped a circuit breaker and the system went down. It did not come back up, why? Because the "boot-archive" was out of date. IMHO, in the appliance space you don't want this to happen so I neutered the boot-archive check. (Made the start/exec string ":true") I'd rather run with yesterday's kernel than not at all. Casper _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
