Mike Gerdts wrote: ... > I'm *so* glad to see that this is an area of focus. My comments on > the document and installation related tasks follow. > > Page 6, Bullet 2, sub-item 2: SUNWCXall no longer does the trick... > when SUNWCXall is installed on a sun4u box (15k domain) the sun4v > platform support is not added. This implies that in addition to my > 15k domain used primarily for image development (that ain't cheap), I > now need to have a T1000 or T2000 sitting around for the same purpose. > In a globally distributed jumpstart environment, I now need to > distribute three ~2 GB flash archives to get x86-64, sun4u, and sun4v > support. >
Thanks for pointing this out, as I hadn't noticed it. > Page 8 - Live Upgrade is also hampered by the following in my environment: > > 1) It uses a version of cpio which does not support sparse files. > This causes files like /var/adm/lastlog to balloon in size when large > UID's (100,000,000 - 999,999,999) are used. Similar issues likely > exist if a quotas file happens to be in a partition used for live > upgrade. > 2) It has spotty support for upgrading to metadevices. > 3) It sometimes requires applying patches and new packages to a running system I hope you've filed bug reports on the first two. Using ZFS will make both less of an issue, since we don't need to copy or use metadevices. #3 is kind of a hard problem; I've got some ideas mentioned in the paper about perhaps using VM's to provide the environment in which the upgrade would run, which would limit the need for patches specifically for the upgrade. I need to kick those around with the experts a bit to see if they're actually feasible. > > Page 11 - DHCP, PXE, etc. In Update 1, vendor DHCP options for x86 > became unsupported in favor of maintaining those in menu.lst files. > Note that there was no EOF announcement to help customers prepare for > this change and that all of the required functionality is still in the > miniroot that is TFTP'd. Turning /sbin/dhcpinfo into a wrapper that > does "if [ some_condition] ; then ifconfig bge0 dhcp primary ; fi ; > exec /sbin/dhcpinfo.orig" brings this feature back. This change seems > completely unnecessary and only serves to fragement x86 and SPARC > jumpstart environments. Did I mention there was no EOF announcement > and only one off-handed mention in the release notes? > I expect we'll fix the fragmentation between x86 and SPARC by going to GRUB on SPARC as well. Long term, I think the model is better for most people, but the transition could have been handled better, I agree. > Page 11 - JASS is worth mentioning as well. > Good point. > Page 12 - More DHCP... - Documentation on how to set up Sun's DHCP > server is overly complex and suggests lots of changes for every > machine being installed. It is possible to architect a jumpstart > environment using Sun's DHCP server such that a single pntadm command > can be used to switch between macros that point at distinct jumpstart > releases. > Yeah, I know, we've been doing it in the lab since day 1. Our bad for not fixing the documentation and tools to make that the recommended practice. > It is really hard to find a reference to anyone other than Sun using > Sun's DHCP server for jumpstart. Perhaps Sun should consider > migrating to ISC dhcpd where there is much more mindshare (and support > for vendor options that exceed 255 bytes). > There are some postings on comp.unix.solaris on how to use the ISC server if you wish, and I also have a script that one customer was kind enough to provide which does a similar setup for the Microsoft DHCP server. One of my other hats is that I own the Solaris DHCP server, but we don't have any active development of it going right now. What we might do going forward would be an interesting topic for networking-discuss; we someday will need to support DHCPv6, and that's going to cause some re-examination of the strategy. Right now we're not too clear on the broad requirements. You're right, though, that ISC's server is more up-to-date on features than the Solaris server at the moment. Less reliance on vendor options makes the lack of RFC3396 support less important, so GRUB's you're friend ;-) > setup_install_server and friends assume that a Sun box is going to be > the host for the boot media and refuses to work if it is NFS mounted > from elsewhere. In environments that NAS appliances are leveraged for > all other NFS serving, it is quite likely that the NAS appliance is > the "right place" for the miniroot and other jumpstart data. > Another good point. > When debugging jumpstart installations, it is common to spend more > time waiting for the system to reset than it does to figure out that > the jumpstart is just going to bomb out again. I saved a lot of time > when I learned about using two or more of the following commands: > > rm /tmp/.jumpstart > ifconfig bge0 dhcp renew > suninstall > So, extrapolating a requirement, you want a supported restart of an installation without a reboot, right? Sounds good to me. > Section 2.2.6 - Installing from flash archives whacks all sysidcfg > information. In a disaster recovery scenario, you likely don't want > that to happen. Integration with flash archives and a custom > netbackup agent would be nice... > Agreed about the recovery requirement; can you elaborate on what you're looking for in the integration with a backup system? > Section 4.1.8 - Local caching of Sun software distribution sites > should be viable. Prepopulating with up to date packages, patches, > product stacks, etc. should be possible so as to allow customers to be > "self sufficient" and minimize the risk of WAN outages, Sun outages, > etc. on scheduled maintenance activities. > Yes, that's sort of alluded to in 4.1.7 but a clear statement would be helpful. > Optimization of network performance is sometimes a matter of > optimizing the size of installation media. If something like flash > archives continues to exist, they should use a better compression tool > than compress(1). > Sure, providing options here seems reasonable. > Other ramblings... > > - Options used for debugging the installation process should be part > of the public interface. Custom installation modules should be able > to hook into the debugging framework through a public interface. > Can you tell me more about what you're after? > - Installation DVD should have a slimmed down version (optimize > download/burn time) that is usable as "rescue" media. It should not > need to connect to an external system to become usable in its most > basic form. ISV's should be encouraged to provide customized versions > of this for recovery options. Example customized versions may include > support for importing VxVM disk groups and mounting VxFS file systems, > bare metal restore, etc. > I'd thought about this a bit in the context of the WAN/Jumpstart install problem, as requiring the full live environment that is proposed for the interactive install isn't really necessary. I think it's a reasonable thing to do, it's really sort of a special instance of the custom image support suggested in 4.1.5. > - In the spirit of "sharing" there should be a mechanism that makes it > easy for people to publish software stacks without having to provide > the installation media (bandwidth constraints, legal limitations on > redistribution, etc.). For example, pretend that someone interest in > MythTV figured out what the magic minimal bits were to make it work on > a particular release of Solaris, with a particular driver release that > is available from the IHV, and some other stuff from SourceForge. > Assuming each of those sites provided the appropriate web service for > delivering software via Caiman, I should be able to provide an xml > file on my own web site that ties all of these things together into > the perfect PVR. > Yes, that's what I think a generalized WAN installation model would support. > - One thing that concerns me about creating N ZFS snapshots for N > zones is that they will start out using about X GB, where X is the > size of the source of the source file system. Over time, however, the > zones will get patched independently but will end up with the same set > of patches but will approach N*X in size. There should be some way to > reconverge the various bits on disk that contain the same data, > therefore returning the size back to X. This is likely more of a ZFS > problem than an installer problem. > This was discussed during the recent ARC case for Zones and ZFS integration, and it's certainly noted as something we'd like to address. > Again, I'm very glad to see that this is getting attention. I like > the overall approach and think it is on the right path. > Thanks for the kind words, and the feedback! Dave
