On 5/11/07, Vasiliy <vassun at gmail.com> wrote: > Linux is more for Unix ethusiasts who want all latest > changes now! And if it break something - so what?
That describes a certain segment. I would argue that those that really care about things like running Oracle or actually using LSM would disagree. > > Solaris is used by big corporations, banks etc. > Corporate IT do not like changes if they do not need them. > Many of them has procedure to test new software for like 3 > monthes before they deploy it over enterprise and so they > like to have certain fix and nothing else new. If they get > all bunch of new changes then they have to run 3 month test > again. And when a critical remotely exploitable sendmail vulnerability comes about these customers tend to be very unhappy that sendmail is part of the kernel patch[1]. And that the kernel patch includes the source code to various freeware[2]. Having to schedule an outage (and up to several months of testing) to fix critical security problems with sendmail is unacceptable. I haven't seen this problem on the competition. 1. 118833-36 includes sendmail. Additonally, Sun Alert 102664 (sendmail "use after free" bug) requires 125011-01, which in turn requires a kernel patch. 2. 108528-29 delivers /usr/share/src/apache. > This is just matter of responsibility. Patching solution > for Solaris was evolved in what it is now by customer > requests and so serve them well for quite some time. > > It was kshell script. Now it is on steroids with new > C-code pdo which has all new dependency check, > multi-patching already in Solaris 10 FCS. Nevada has > mutual dependancy and recursive patching was almost > ready. With increasing of freshbitted packages support - > so it covers Linux-like installation patches are quite > unique advantage Solaris has to deliver and to track > changes. There is still a lot of work, and I would argue that the recent enhancements to patching have represented "two steps forward and one step back" and there process problems with the creation of patches independent of the (reasonably good) tools that are used. For instance: - I can't programatically tell if all the patches listed in a patch cluster installed properly. This is because the legacy return codes (which were never intended to be a stable interface) no longer work, particularly on a system with zones. - If I use "patchadd -t" on a system with zones, it spits an error message and patchadd exits with status 0, indicating success even though no patches were installed. - The text output of patchadd is inconsistent in its formatting, which makes me think that some future bug fix is going to change the output format. As such, I'd be silly to put too much effort into processing the output with a script. - If I have a system with a fair number of zones (~10) and need to patch it, I should plan on hours (6+) of down time. One horror story that I haven't confirmed indicates that patching has taken days. This is based upon using using install_cluster which for some really stupid reason doesn't do multi-patching. - Recent patch clusters require multiple reboots to install. For instance, if I have S10U3 or before and install today's recommended cluster, I would need to run install_cluster twice, with a reboot in between. This is because 118833-36 creates an lofs mount of a shell script over pdo to enforce reboot after patching. - Even with Update Connection, the previously mentioned problem persists. When I was testing it a couple months back, I had to manually install kernel patches between reboots. Yuck. - With some optimizations to the way that install_cluster does its work (use multi-patching), I have been able to get the patching to be much more efficient with regards to sparse zones - each one only takes about 10 minutes in my test case. I have some servers with well over 20 zones. What would happen if pdo could patch the zones in parallel? This becomes most useful if the zones physically reside on fast storage (e.g. write-cached array). - Patches all too commonly have "reboot after install" "install in single user mode" or "reconfiguration reboot required after install" set on the patch. If this is a legitimate requirement, that is fine. However, patching vmstat should not require single user mode (114990-03) and patching sshd should not require a reconfiguration reboot (113273-11). It's a much easier change control request if I can tell the change control board that "I need to restart the ssh server after patching" than it is to say "I need 1.5 hours of down time on each of the 25k domains in the ERP cluster." > I started some discussions before about patches and > pdo you may just check this forum for last year. Any chance that pdo source is likely to become available? I can pick some enhancements out of the list of complaints above that I would like to work on. Mike -- Mike Gerdts http://mgerdts.blogspot.com/
