Gregory Shaw wrote: > A few ideas I had on install: > I'll just ask up front: have you read the strategy document posted to this community some weeks back, which Mike referenced in his reply? It outlines what we're planning to do. So my responses below are in that context.
> Jumpstart Ideas: > - I'd like to have more targets for the install. For example, > instead of SUNWCall or SUNWmin, a few different targets: > - Server install (services, little desktop) > - Desktop install (desktop, few services) > - Security install (for a firewall machine, additional security > packages and increased default security settings) > - Laptop install (desktop, focus on portability) > - A custom install target(s) built from a set of packages on an > existing machine. > If the above were available, it would simplify the customization of > installs. We will be attempting to strike a balance between simplicity for new Solaris users vs. meeting the needs of experienced Solaris admin's such as you. For the former, there will be fewer choices on the main path of interactive installation. For the latter, well, we'll see what choices we provide. Mostly, we want to provide better support for automation and replication. How much customization is supportable is a subject of active discussion. > - I think it makes sense to deprecate the old method of install > (rarpd, bootparamd, etc.) and switch to a pure DHCP based automated > install. The restrictions on rarpd (local subnet only, assumes default > route correct even on multi-homed systems), bootparams, etc. can all be > rolled into fields in dhcp. Since dhcp is very common today, it makes > sense to move in that direction. We will certainly be moving to modern, widely used defaults. > - If we go with the previous item this may be irrelevant, but I'd > like to have the ability to hit 'ESC' on the console while using rarpd > on network interfaces. I generally have rarpd available only on one > interface, and it's frustrating to have the kernel walk through the > interfaces and time out on each one before the jumpstart will start. > This is part of the bigger picture of speeding up jumpstart. We will certainly be optimizing for the common case, not the uncommon, and respecting your time, as opposed to wasting it. > - I'd like to be able to configure the jumpstart to log everything > to a centralized log server (via syslog). This would allow the session > to be recorded with minimal effort. Centralized collection of logs seems reasonable. WAN installation offers a form of this already - does it meet the requirement? > - I'd much rather boot from a USB device than a CD/DVD. With 4gb > USB flash devices running ~$130, it should be possible to offer that > instead of a bunch of CDs/DVD. A process for creating the USB device > would be very helpful ongoing. I have to think the install would be > faster with USB instead of DVD. Perhaps even removing the DVD from the > server build would be practical... > The Live Media project which we'll be opening here imminently will be a vehicle for addressing this. > GUI Ideas: > - I really like some of the latest Linux installs. They're easy to > understand, and work really well. An example would be Ubuntu. I can go > into more detail about why or what makes it good if there is interest. > I'd recommend looking at the concept car movie we published with the strategy, it'll give you a better idea of what we want the new Solaris user to encounter than I can describe with words. You're really not the target user for what it covers, but you perhaps can extrapolate some things from it. > Radical Departure Ideas: > Here's an idea for a new install process that is completely > different. If machines switch to using flash memory for their system > disk (a real possibility, especially for desktop/laptop), I'd like to > see something like the following: > - Machine boots prom. > - Prior to kernel boot, the boot loader checks a particular host on > the network for OS updates. This would be configurable in the boot > loader. The host on the network would have a certificate that would be > loaded on the client to allow for secure updates and verification. > - If the updates exist, an image is downloaded containing a diff of > the block-level changes to the OS disk. > - The diffs are applied (rather than patches downloaded and installed) > - The system boots with the new image. > > With the above, a central system image that contains the OS for each > system type (or even system) would be maintained on the 'master' > system. These images could be patched and tested prior to the patched > version being released. > When the system boots via flash the kernel migrates from flash to a > combination of ramdisk (read only data) and disk (read-write, such as > /var and swap). I think this would result in a very fast boot time and > a very fast system, and open the door to reboot-to-update servers. It > would even be possible to patch the flash disk 'live' as it won't be in > use while the system runs. Of course, the memory footprint would be > larger, but memory is far cheaper than it used to be. > Since the system image is generally less than 8gb (today), the idea > of using 4-8gb of flash for the OS (even mirrored) would be reasonable. > Flash is slow to write, but fast to read. > I think with some work, this would be a VERY impressive centralized > install/update/reconfigure solution. > We'll be looking at ideas around how to make things scale better, but at this stage, I'd have to ask: what is the problem you're trying to solve with the above architecture? > I'd like to help make the install processes for Solaris better. I'll > help any way that I can... > Keep participating here. It's your most direct path to contributing, because we'll be running the projects through this community. Thanks for your thoughts! Dave
