A few ideas I had on install:
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.
- 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.
- 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.
- 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.
- 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...
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.
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.
I'd like to help make the install processes for Solaris better.
I'll help any way that I can...
Thanks!
On May 21, 2006, at 5:49 AM, Eric J. Ray wrote:
>
>
> Mike Gerdts wrote:
>> There was some good discussion in a couple threads:
>> [Future] Solaris installation strategy
>> http://www.opensolaris.org/jive/thread.jspa?threadID=7070&tstart=0
>> Install time breakdown
>> http://www.opensolaris.org/jive/thread.jspa?threadID=7660&tstart=0
>> I would be particularly interested in knowing if there has been any
>> progress in the new installation strategy inside Sun. It has gone
>> very noticably silent on this list, even though it seems as though
>> there is a funded project inside Sun that is looking at improving the
>> current state of affairs. Dave Miner - any chance you can provide an
>> update?
>
> Mike, Greg, and all,
>
> I'll let Dave speak to the specifics about Caiman (the installation
> strategy), but I can say that there's a lot happening on the
> install front inside Sun. Caiman is absolutely a priority within Sun,
> and we have every expectation of improving the state of affairs in
> Solaris Install.
>
> Development on Caiman will be done here on opensolaris.org, by
> the way, so you'll be able to participate if you want.
>
> We're also working on getting the rest of the Install
> consolidation code out onto OpenSolaris. We don't have a
> schedule yet, but we're planning on getting that done by
> the end of the calendar year and hopefully sooner.
>
> Mike, what thoughts had you had on Solaris installation? Getting
> the ideas and thoughts in the open would be great.
>
> Eric
>
>
> --
>
> Eric J. Ray
> Software Engineering Manager
> Solaris Install, OPG
> Sun Microsystems
> 303-223-7843 (direct)/x81067
> eric.ray at sun.com
>
-----
Gregory Shaw, IT Architect
Phone: (303) 673-8273 Fax: (303) 673-8273
ITCTO Group, Sun Microsystems Inc.
1 StorageTek Drive MS 4382 greg.shaw at sun.com (work)
Louisville, CO 80028-4382 shaw at fmsoft.com (home)
"When Microsoft writes an application for Linux, I've Won." - Linus
Torvalds
