|
Replies:
73
-
Last Post:
Apr 11, 2006 3:27 PM
by: davidjon
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Solaris installation strategy
Posted:
Mar 23, 2006 9:46 AM
|
|
Greetings, Installation community members!
I've just posted for discussion a document that I've been working on for
the past couple of months: a draft strategy for Solaris installation.
The document discusses the current state of Solaris installation in
relation to customer requirements, and proposes a set of features and
projects designed to address the requirements.
Please understand that this is a proposal; while it's had some
preliminary review by a small number of people in Solaris engineering,
this is the first time it's been widely disseminated and thus I expect
to receive, and incorporate, a great deal of feedback which will evolve
it from this point.
I would appreciate review comments by April 14. I encourage posting
comments to this list, but private comments are of course equally
acceptable.
http://www.opensolaris.org/os/community/install/files/install_strategy.pdf
Thanks,
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
Posts:
6
From:
Menlo Park, CA
Registered:
11/17/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 23, 2006 11:09 AM
in response to: dminer
|
|
Dave:
A pretty detailed document. Nice work.
To ponder the concept and conundrums learned from Linux -
A) we must co-exist on the disk - hence it was imperative to develop filesystem support for as many filesystems out there. ZFS basically has problems because now the data cannot be shared across instances of OS. This has many implications to usability and choice. With Linux, I can do my work and share the files on static slices of the FS. If I need Win32, I boot it, and it has the same/similar access to files. ZFS as a default in Caiman is dictating to users that they must drink all the cool-aid, unless we provide Win32, BSD and Linux equivalents to ZFS modules.
B) Drivers, Drivers, Drivers - The problem with solaris install is that it doesn't have the drivers it needs to install itself, let alone the network drivers for the network install. Chicken and egg problem. We need a quick way to at least enable users to add drivers legally and then to incorporate them into the miniroot. Otherwise, booting PXE might be fine, until the miniroot loads and boots and its game-over, or until we try to touch the SATA-RAID controller and we break again. Linux has an inate advantage here. It's the GPL. Viral in nature and quick to spread. Anyone can incorporated source and rebuild the modules needed. Solaris is encumbered by CDDL and it makes it hard to get that stuff quickly into the source base, let alone the installation image. We need to reduce the barrier to getting drivers into the installation, and that means off-line tools that manipulate the installation methods, whether it be ISO media, FLARs, PXE/nfs images, etc.
C) We need to understand who and what Opensolaris customers are and not make the mistakes that Marketing and many Trade publications make. They [Marketing] still don't understand Linux or BSD users in many aspects, and what is still driving Linux development. Decisions and priorities should be driven by our prized users (i.e. the Higher IQ home/work/school hacker) and not the SMB except when their needs coincide. The SMB are unlikely to be early adopters until Open Solaris has established a stronger hold in the mainstream, but even then, SMB don't drive much of the core architecture of install. That said, catering an install to the SMB such as by providing a fancy GUI, is likely to divert attention to priorities (A) and (B). For example, the Anaconda installer still core dumps on quite a few graphics cards and so text install is safer and more robust on Redhat. That's a fact that many Marketing organizations that don't do their own Linux installs wouldn't know.
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 23, 2006 3:42 PM
in response to: gdude
|
|
James C. Liu wrote:
> Dave:
>
> A pretty detailed document. Nice work.
>
> To ponder the concept and conundrums learned from Linux -
>
> A) we must co-exist on the disk - hence it was imperative to develop
> filesystem support for as many filesystems out there. ZFS basically
> has problems because now the data cannot be shared across instances
> of OS. This has many implications to usability and choice. With
> Linux, I can do my work and share the files on static slices of the
> FS. If I need Win32, I boot it, and it has the same/similar access
> to files. ZFS as a default in Caiman is dictating to users that they
> must drink all the cool-aid, unless we provide Win32, BSD and Linux
> equivalents to ZFS modules.
>
I don't agree that it's attempting to dictate anything in particular -
right now we have exactly one choice for filesystems to which you can
install, UFS, which isn't necessarily readable on any other OS (and
certainly isn't across ISA's with different endianness). In terms of
user data, yes, we're not providing a cross-platform place for them to
drop their data, but ZFS isn't making that requirement any better or
worse initially, though the thought that it will be ported to other
platforms might make it better long-term. What I guess I'm interpreting
here is that you're arguing we should provide some sort of capability to
create a FAT32 or some sort of "interoperable" filesystem for user data
as part of the installer?
> B) Drivers, Drivers, Drivers - The problem with solaris install is
> that it doesn't have the drivers it needs to install itself, let
> alone the network drivers for the network install. Chicken and egg
> problem. We need a quick way to at least enable users to add drivers
> legally and then to incorporate them into the miniroot. Otherwise,
> booting PXE might be fine, until the miniroot loads and boots and its
> game-over, or until we try to touch the SATA-RAID controller and we
> break again. Linux has an inate advantage here. It's the GPL.
> Viral in nature and quick to spread. Anyone can incorporated source
> and rebuild the modules needed. Solaris is encumbered by CDDL and it
> makes it hard to get that stuff quickly into the source base, let
> alone the installation image. We need to reduce the barrier to
> getting drivers into the installation, and that means off-line tools
> that manipulate the installation methods, whether it be ISO media,
> FLARs, PXE/nfs images, etc.
>
I can't do anything about the license situation, but I agree that the
need to add drivers to an image is a requirement; in fact it's #14 on
the list in chapter 3. But I also see I probably should have said more
about it than the rather passing reference that's in 4.1 (end of 3rd
paragraph).
> C) We need to understand who and what Opensolaris customers are and
> not make the mistakes that Marketing and many Trade publications
> make. They [Marketing] still don't understand Linux or BSD users in
> many aspects, and what is still driving Linux development. Decisions
> and priorities should be driven by our prized users (i.e. the Higher
> IQ home/work/school hacker) and not the SMB except when their needs
> coincide. The SMB are unlikely to be early adopters until Open
> Solaris has established a stronger hold in the mainstream, but even
> then, SMB don't drive much of the core architecture of install. That
> said, catering an install to the SMB such as by providing a fancy
> GUI, is likely to divert attention to priorities (A) and (B). For
> example, the Anaconda installer still core dumps on quite a few
> graphics cards and so text install is safer and more robust on
> Redhat. That's a fact that many Marketing organizations that don't
> do their own Linux installs wouldn't know.
I completely agree that a simpler install isn't enough to get Solaris
into an SMB market; it's a necessary condition, but not sufficient. But
even so, I don't regard a GUI as a diversion - it's a requirement, so we
will do it, and do it well. We'll also do a text interface that's
similarly usable, because that's a requirement, too. We're certainly
hostage to the stability of X for the GUI, but I'm sure Sun's X team
(and I'd hope the whole X community, though I don't know any of them at
all) is committed to fixing those things when they know about them.
Thanks for the comments!
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,695
From:
US
Registered:
4/28/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 23, 2006 4:21 PM
in response to: gdude
|
|
James C. Liu wrote:
>B) Drivers, Drivers, Drivers ...
>
> ...
> ...
>Solaris is encumbered by CDDL and it makes it hard to get that stuff quickly into the source base...
>
James -- I'm not sure I understand the argument you're making here.
Could you please elaborate?
Eric
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
6
From:
Menlo Park, CA
Registered:
11/17/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 11:00 PM
in response to: ericb
|
|
For folks internal to Sun who are overloaded with driver development duties, there may seem like there is no end to the volume of drivers we're including into the build trees. But the fact is, each of those that goes into Open Solaris and eventually Solaris has huge encumberences. A tremendous legal effort is expended to negotiate open source under the CDDL to Sun, which controls the terms.
With GPL, the redistribution is automatic and viral. Once a company releases source themselves and attaches a GPL header, it's over. In fact, the architecture of GPL Linux tells companies that they taint the kernel when they don't release truly source built binaries. There is a grey area where many companies are building drivers today that technically derive from the kernel interfaces and headers that are GPL, not LGPL and thus may be subject to some harsh legal action if the Linux folks actually chose to take action, and hence the work proceeding on rewording GPL in latest version 3. But in general, once released as GPL, it's fully redistributable and anyone can look and derive and improve and re-release and propagate the GPL driver code. There are no further legal encumberances - and that was one of the intended benefits of copy left. The GPL isn't about intellectual rights - the authors retain all rights to what they know; but the version they released under the GPL is basically out of their control. Anyone who contributes and improves it gives it back automatically to the community under GPL, and the company that issued it, can't even take that version back and include those new enhancements without re-issuing under the GPL, even though the original work was theirs. That's because those enhancements are GPL.
The net effect is that driver development is MUCH faster and intellectual property gathered benefits everyone. Under CDDL, each company negotiates terms with Sun that usually preserves their ability to re-incorporate joint improvements made under CDDL. They can then combine these improvements and improve upon them in future revisions and not release them to the CDDL under such contracts, and so drivers on Open Solaris may stagnate after the first or second generation, especially if hardware enhancements occur that build on existing code and have some minor new changes to make it work. A re-negotiation happens on the next gen... and this adds viscosity to the whole process and increases frictional drag on development. End results are that it takes more work to get drivers onto Open Solaris.
There is an advantage of course if businesses want to profit; the CDDL is definitely pro-business. But it's a two edged sword for a small growing OS.
If Solaris were MONSTER monopoly OS selling 200 Million units per year world wide, and having only 5% of the market actually ever installing OS, and 95% of the systems coming pre-installed by OEMs, well, then we could sustain a fully proprietary driver program where OEMs submit to the will of MONSTER OS and actually pay to have their driver (which they write) certified and possibly verified and signed for inclusion in MONSTER OS. But OpenSolaris isn;t there....yet, and hopefully will never be closed. I'd much rather see 200Million units installed per year and driver source fully open and viral.
|
|
|
|
|
Posts:
1,695
From:
US
Registered:
4/28/05
|
|
|
|
|
|
Posts:
6
From:
Menlo Park, CA
Registered:
11/17/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 28, 2006 10:37 AM
in response to: ericb
|
|
> I think you're implying that the CDDL grants Sun a
> special position, but
> that's not true.
Actually, I mean quite the opposite. Companies negotiate the ability to reincorporate joint IP back into their stacks. Quite attractive for companies, not Sun, since they have the ability to retain joint IP. But less viral depending on each person's definition of the word. Moreover, perhaps this discussion is orthogonal to the point of a good ITU technique to help others reincorporate new drivers into the install image. I'd more than welcome offline comments.
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 27, 2006 8:02 AM
in response to: gdude
|
|
CDDL has exactly the same "viral" component as the GPL; ie you must
publish your changes. The key difference at this level is what it
applies to. For CDDL it is files for GPL is it the project as a whole.
I really don't think that the choice of license has anything to do with
how many drivers we have on Solaris versus Linux. It has a lot more
to do with the fact that the CDDL and OpenSolaris isn't even a year old
yet and Solaris 10 itself has only be officially released for just over
a year.
I firmly believe that in the long run the CDDL will actually give us
more drivers on Solaris and more drivers in source for OpenSolaris as
well. The reason being that I believe that the file based nature of
OpenSolaris will actually help get drivers developed, they may start
out partially closed but unlike GPL drivers this is a least an option
to get things moving.
Finally the CDDL does NOT require any negotiation with Sun any project
is free to use it and in fact there are non Sun projects using it
already. Any vendor is as free, in fact maybe more so, to use the
CDDL to develop drivers for any operating system including OpenSolaris
without ever contacting Sun or ever having any intent to do so.
I think you are confused about the differences between Solaris, the
OpenSolaris project and source base and the CDDL license.
Please DO NOT continue this topic here it really has nothing that
so ever to do with installation.
Thanks for taking the time to thing about the issues though.
Darren.
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
6
From:
Menlo Park, CA
Registered:
11/17/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 28, 2006 10:49 AM
in response to: darrenm
|
|
> I really don't think that the choice of license has
> anything to do with
> how many drivers we have on Solaris versus Linux. It
> has a lot more
> to do with the fact that the CDDL and OpenSolaris
> isn't even a year old
I agree with the above statement. Kernel modules are like a live-culture yogurt. Licenses are the identifiers of what type of bacterial family we belong to. The GPL is well established and hard to displace, and we, like the lesser bacteria, must be ingenius to stay alive.
> I firmly believe that in the long run the CDDL will
> actually give us
> more drivers on Solaris and more drivers in source
> for OpenSolaris as
> well.
I agree, but note that in the interim, we need to adapt new techniques to include, as quickly and easily as possible, the ability to install alpha, beta, 3rd party, etc. drivers into the ITU than gets folks up and running. For most folks today that take off-the-shelf install ISO images for Solaris, there is little or no methods for them to easily get new drivers into the install image to even boot and install.
|
|
|
|
|
Posts:
1,901
From:
NZ
Registered:
6/16/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 23, 2006 6:57 PM
in response to: gdude
|
|
On Thu, 2006-03-23 at 11:09 -0800, James C. Liu wrote:
> C) We need to understand who and what Opensolaris customers are and
> not make the mistakes that Marketing and many Trade publications
> make.
That's an interesting point - because I got to page 3 and there's
already information that's not publically available, the Solaris Nevada
Marketing Requirements and Product Requirements document.
Given that we're now doing most of our development out in the open, is
there any real reason why we can publish this? [1]
Glynn
[1] Aside from the potential of disclosing confidential customer
information which we could clean up
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 24, 2006 3:21 PM
in response to: gman
|
|
Glynn Foster wrote:
> On Thu, 2006-03-23 at 11:09 -0800, James C. Liu wrote:
>> C) We need to understand who and what Opensolaris customers are and
>> not make the mistakes that Marketing and many Trade publications
>> make.
>
> That's an interesting point - because I got to page 3 and there's
> already information that's not publically available, the Solaris Nevada
> Marketing Requirements and Product Requirements document.
>
> Given that we're now doing most of our development out in the open, is
> there any real reason why we can publish this? [1]
>
Unfortunately, there are several references which aren't public; some of
them may get pushed out later. I felt it was worth including them at
least for the people who could access them, in this particular case
because demonstrating alignment with marketing seemed to be a positive.
Not everybody agreed with even having that reference to the MRD/PRD,
though.
I'll ask marketing, but it's up to them.
Dave
PS: You're a troublemaker, Glynn ;-)
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,901
From:
NZ
Registered:
6/16/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 26, 2006 4:37 PM
in response to: dminer
|
|
Hey,
On Fri, 2006-03-24 at 18:21 -0500, Dave Miner wrote:
> > Given that we're now doing most of our development out in the open, is
> > there any real reason why we can publish this? [1]
> >
>
> Unfortunately, there are several references which aren't public; some of
> them may get pushed out later. I felt it was worth including them at
> least for the people who could access them, in this particular case
> because demonstrating alignment with marketing seemed to be a positive.
> Not everybody agreed with even having that reference to the MRD/PRD,
> though.
That's cool - the reason why I'm asking for this is not only because
we're supposed to be an open community with open communication and
development, but also I believe that it's fundamentally important for
non-Sun people to see what goes on behind the scenes and what influences
in strategy/roadmap there are from a corporate point of view.
Thanks for asking though - you're a brave man ;)
Glynn
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 27, 2006 12:39 PM
in response to: gman
|
|
Glynn Foster wrote:
> Hey,
>
> On Fri, 2006-03-24 at 18:21 -0500, Dave Miner wrote:
>>> Given that we're now doing most of our development out in the open, is
>>> there any real reason why we can publish this? [1]
>>>
>> Unfortunately, there are several references which aren't public; some of
>> them may get pushed out later. I felt it was worth including them at
>> least for the people who could access them, in this particular case
>> because demonstrating alignment with marketing seemed to be a positive.
>> Not everybody agreed with even having that reference to the MRD/PRD,
>> though.
>
> That's cool - the reason why I'm asking for this is not only because
> we're supposed to be an open community with open communication and
> development, but also I believe that it's fundamentally important for
> non-Sun people to see what goes on behind the scenes and what influences
> in strategy/roadmap there are from a corporate point of view.
>
> Thanks for asking though - you're a brave man ;)
>
I talked to Marketing, and the answer is that their requirements
documents will not be released, as they reference specific customers by
name and their feedback is governed by confidentiality agreements.
Perhaps in such future exercises we'll produce scrubbed documents which
are suitable for release (here I'm hoping, they haven't committed), but
that's not the case this time.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
41
From:
Dublin, Ireland
Registered:
6/14/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 23, 2006 1:16 PM
in response to: dminer
|
|
Hi Dave,
I'm about to go off on vacation but here are a couple of initial comments
based on past experience and some recent customer issues we have ran into.
I'll frame them as requirements, and when I say upgrades below, I'm
thinking of the patches we have at present. Perhaps some of these belong
more with redesigning our packaging structure. Anwyay...
* Upgrades must not clobber a users configuration (I've some bugs open at
the moment for .conf files that are type f and are clobbered by
patches). - How do we address significant changes to configuration files
without harassing the user? In particular for changes which we have
backported, the backport of Native LDAP 2 to Solaris 8 in 108993-18 despite
a lot of testing still managed to cause a lot of problems.
* Users should be able to select the minimum set of changes needed to
address their needs. (eg. to get a bugfix, users should not have to upgrade
to the latest features also. If you want to fix libc on s10x FCS you need
to upgrade to grub first.)
* How should reboots and service restarts be handled during an upgrade?
* re 2. ... graphical and _automate-able_ text environments.
* re 25 A user must be able to revert a particular distinct part of an
upgrade. (In current terms, user can apply patch A then B then C; but then
remove A provided there are no dependencies. The present language implies
reverting is a strictly sequential process).
* re 26. In addition to applying the software we need to ensure that it is
correctly patched, or at least show that it is not in whatever update tool
there is. In todays terms: If a user installs package A, then a patch X-01
which applies to packages A and B, patch installation will succeed. If the
user later installs package B, it appears that because patch X-01 is
installed that package B is up to date even though it is not - the user
needs to re-apply X-01.
* re 39. I'm all for speedup! The current situation with patching zones is
not good. However Solaris customers may wish to patch only every six months
say; this may require a slightly different focus than aiming for 'daily
upgrades'.
* The installation interface must allow the user to select a minimised
version of the distribution. In doing so it must automatically satisfy
requirements for what the user has selected.
* The ability to upgrade the installation media rather than post
installation on the system must be provided. Currently flash archives
provide this, but we do not provide any way for a user to freshbit patches
onto an jumpstart install image. The latter would be useful for adding
hardware support, in particular for x86 systems where the current boot disk
ITU process makes installation complicated, eg[1].
* Updates applicable to a minimised system must apply to a minimised
system. We come across patches in testing occasionally which should patch
the minimum solaris cluster, but require patches which only apply to say
SUNWCuser.
- Earlier on you mention that "Solaris user who are not developers are few
and far between these days". I disagree, within Sun we have plenty of non
technical staff using desktops, or at least sunrays. Regardless, we should
provide a 'metacluster' which would be appropriate for a non devleoper end
user. Though I'd agree with the End User metacluster at present being
essentially meaningless; in fact I think that all metaclusters are fairly
meaningless.
Right, time to go to Turkey for an eclipse! I'm sure I'll have thought of
more to add by the time I get back!
Cheers,
~Albert
[1]
http://sunsolve.sun.com/search/document.do?assetkey=1-21-119376-02-1&searchclause=119376-02
--
Albert White - Patch System Test - Sun Ireland
albert dot white at sun dot com http://blogs.sun.com/albertw
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 10:32 AM
in response to: albertw
|
|
Albert White wrote:
> Hi Dave,
>
> I'm about to go off on vacation but here are a couple of initial comments
> based on past experience and some recent customer issues we have ran into.
> I'll frame them as requirements, and when I say upgrades below, I'm
> thinking of the patches we have at present. Perhaps some of these belong
> more with redesigning our packaging structure. Anwyay...
>
Most of your comments I think apply more directly to the Packaging and
Patching strategy, but as there's obvious overlap, I'll take a stab at
them to start with.
> * Upgrades must not clobber a users configuration (I've some bugs open at
> the moment for .conf files that are type f and are clobbered by
> patches).
Agreed, that's certainly my definition of upgrade; what you're
describing specifically are clearly bugs in those packages, but being
clear about the definition of expected upgrade and patch behavior is
important to the architecture.
> - How do we address significant changes to configuration files
> without harassing the user? In particular for changes which we have
> backported, the backport of Native LDAP 2 to Solaris 8 in 108993-18 despite
> a lot of testing still managed to cause a lot of problems.
>
I guess I don't have a good answer initially, other than use SMF
(getting into a standard form with supported upgrade semantics is good
architecture, after all :-) Seriously, those strike me as design flaws,
though I'm unfamiliar with the details of the situation you're
mentioning. If we're upgrading without providing compatibility,
especially in patches, then we're just asking for a world of hurt.
> * Users should be able to select the minimum set of changes needed to
> address their needs. (eg. to get a bugfix, users should not have to upgrade
> to the latest features also. If you want to fix libc on s10x FCS you need
> to upgrade to grub first.)
>
That's a controversial topic. There's the point of view you express,
and then there's the one which says that the combinatorial testing
problem of allowing that granularity is pretty expensive, both for the
vendor and the customer, so that perhaps we're all better off with
coarser granularity. I think the increasingly tight integration between
various pieces of the OS works against fine granularity, though our
preference for well-defined interface boundaries between components
encourages the possibility. In the end, I don't think it's up to this
strategy to define direction for the system in this respect;
installation technology probably needs to support fine granularity, and
the product teams can decide how much to make use of it.
> * How should reboots and service restarts be handled during an upgrade?
>
Our preference would be to eliminate reboots in favor of service
restarts. But I'm not sure what you're looking for here; can you elaborate?
> * re 2. ... graphical and _automate-able_ text environments.
>
My thinking is more that the installation process can be automated
(requirement #18), rather than the actual interactive interface. Is
there a reason you'd like automation support for the UI?
> * re 25 A user must be able to revert a particular distinct part of an
> upgrade. (In current terms, user can apply patch A then B then C; but then
> remove A provided there are no dependencies. The present language implies
> reverting is a strictly sequential process).
>
I can see that for patches, but since the focus here is on an upgrade of
the OS, I'm not seeing the value of such a requirement here - we don't
let you run mixed Solaris 9 and 10 bits, and I don't have any data
saying we should.
> * re 26. In addition to applying the software we need to ensure that it is
> correctly patched, or at least show that it is not in whatever update tool
> there is. In todays terms: If a user installs package A, then a patch X-01
> which applies to packages A and B, patch installation will succeed. If the
> user later installs package B, it appears that because patch X-01 is
> installed that package B is up to date even though it is not - the user
> needs to re-apply X-01.
>
That one's clearly in the Package and Patch strategy's court. It's a
big problem, and was raised by at least one of my preliminary reviewers,
but I'm considering it out of scope for this discussion.
> * re 39. I'm all for speedup! The current situation with patching zones is
> not good. However Solaris customers may wish to patch only every six months
> say; this may require a slightly different focus than aiming for 'daily
> upgrades'.
>
That should be requirement #30, for those trying to follow along. This
particular requirement is aimed at obviating the need for the
per-consolidation upgrade scripts we presently have, such as BFU. Their
existence (for which there are reasons, or at least were when they were
created) means their users don't use the install and upgrade tools we
supply to customers regularly, and that's step 1 on the quality death
spiral - it's one reason why the problem survey in this paper is 17
pages long. That requirement applies to a very small, but very
important, section of the user base. It seems to me that a solution
which is fast enough for that demanding segment will go a long ways
toward satisfying the more typical customer, whose patch/upgrade cycle
times are more likely to be what you describe.
> * The installation interface must allow the user to select a minimised
> version of the distribution. In doing so it must automatically satisfy
> requirements for what the user has selected.
>
Agree. The discussion at the end of 2.2.8 was added relatively late and
didn't get fed into the later sections.
> * The ability to upgrade the installation media rather than post
> installation on the system must be provided. Currently flash archives
> provide this, but we do not provide any way for a user to freshbit patches
> onto an jumpstart install image. The latter would be useful for adding
> hardware support, in particular for x86 systems where the current boot disk
> ITU process makes installation complicated, eg[1].
>
I think this is what I'm saying with requirement #14, but if it could be
made more clear, I'm open to suggestion.
> * Updates applicable to a minimised system must apply to a minimised
> system. We come across patches in testing occasionally which should patch
> the minimum solaris cluster, but require patches which only apply to say
> SUNWCuser.
That's fodder for patching, I think.
> - Earlier on you mention that "Solaris user who are not developers are few
> and far between these days". I disagree, within Sun we have plenty of non
> technical staff using desktops, or at least sunrays. Regardless, we should
> provide a 'metacluster' which would be appropriate for a non devleoper end
> user. Though I'd agree with the End User metacluster at present being
> essentially meaningless; in fact I think that all metaclusters are fairly
> meaningless.
In the grand scheme of things, the numbers of those people are very
small, so they're not a category I think should be catered to in the
mainline experience at this point. Sun Rays are really a server
installation by an administrator, not the end users, and would seem to
often be on servers that are providing more than just a desktop.
>
> Right, time to go to Turkey for an eclipse! I'm sure I'll have thought of
> more to add by the time I get back!
>
Thanks Al.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Henry Jen
slowhog@gmail.com
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 23, 2006 3:04 PM
in response to: dminer
|
|
Dave Miner wrote:
> Greetings, Installation community members!
>
> I've just posted for discussion a document that I've been working on
> for the past couple of months: a draft strategy for Solaris
> installation.
>
> The document discusses the current state of Solaris installation in
> relation to customer requirements, and proposes a set of features and
> projects designed to address the requirements.
>
> Please understand that this is a proposal; while it's had some
> preliminary review by a small number of people in Solaris
> engineering, this is the first time it's been widely disseminated and
> thus I expect to receive, and incorporate, a great deal of feedback
> which will evolve it from this point.
>
> I would appreciate review comments by April 14. I encourage posting
> comments to this list, but private comments are of course equally
> acceptable.
>
> http://www.opensolaris.org/os/community/install/files/install_strategy.pdf
>
>
>
Hi Dave,
Very nice work.
I am interested in knowing the progress of the other "Packaging and
Patching strategy" you mentioned, and wondering where to participate in
that discussion.
For upgrade, we need to be able to do components/packages upgrade as
well as system upgrade. What I am talking about is pretty much like the
difference between a upgrade and a dist-upgrade in apt.
For example, I want to upgrade from gnome 2.10 to 2.14 and capable to
rollback if things don't work out. I guess this maybe covered in
software management as well, but wonder if feature like LU can be
applied for such upgrade or not.
Cheers,
Henry
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
39
From:
Registered:
6/14/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 23, 2006 3:08 PM
in response to: dminer
|
|
Dave Miner wrote:
> Greetings, Installation community members!
>
> I've just posted for discussion a document that I've been working on
> for the past couple of months: a draft strategy for Solaris
> installation.
>
> The document discusses the current state of Solaris installation in
> relation to customer requirements, and proposes a set of features and
> projects designed to address the requirements.
>
> Please understand that this is a proposal; while it's had some
> preliminary review by a small number of people in Solaris
> engineering, this is the first time it's been widely disseminated and
> thus I expect to receive, and incorporate, a great deal of feedback
> which will evolve it from this point.
>
> I would appreciate review comments by April 14. I encourage posting
> comments to this list, but private comments are of course equally
> acceptable.
>
> http://www.opensolaris.org/os/community/install/files/install_strategy.pdf
>
>
>
Hi Dave,
Very nice work.
I am interested in knowing the progress of the other "Packaging and
Patching strategy" you mentioned, and wondering where to participate in
that discussion.
For upgrade, we need to be able to do components/packages upgrade as
well as system upgrade. What I am talking about is pretty much like the
difference between a upgrade and a dist-upgrade in apt.
For example, I want to upgrade from gnome 2.10 to 2.14 and capable to
rollback if things don't work out. I guess this maybe covered in
software management as well, but wonder if feature like LU can be
applied for such upgrade or not.
Cheers,
Henry
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
917
From:
Registered:
4/28/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 23, 2006 4:12 PM
in response to: dminer
|
|
This is wonderful Dave! I love your conclusions and proposals. I'll be the storage zealot with the following points:
1) On page 13 you noted iSCSI. I think that we'll continue to see iSCSI grow in popularity and in many ways be used in the same situations that we currently leverage NFS. For instance, I currently use an iSCSI LUN for my Flash Archives, home directory, backups, etc. In many cases I've already started using ZFS on iSCSI for these purposes. I don't see that this really changes your document at all, but just wanted to add some supporting evidence by the need you already defined in your document. I greatly appreciate you think far enough ahead to consider iSCSI at this early stage in the project.
2) Perhaps I missed it, but I see no mention of SVM. While SVM is a powerful and useful tool, in the context of SMB/Developers, it is extremely difficult to use. Root mirroring can be difficult and error prone even for seasoned Solaris administrators but is considered a standard practice throughout the industry. This is only made worse by the fact that you must be experienced with SVM to know that you need to set aside a small slice for the SVM MetaDB's. I've seen plenty of users and admins get frustrated with SVM immediately because they were unaware of this requirement untill they'd already fully installed the system.
Most Linux administrators would take for granted the fact that installers like Anaconda by default will setup LVM to root mirror. By making root mirroring an option during install we can really ease the burden on a lot of SA's and make it a non-issue for users who just want it but don't care about SVM at all.
As a side note, the current default partitioning scheme is really misleading to new users. Allocating root just slightly larger than they need and then allocating all over free space to /export (something that Linux admins have rarely even heard of or understand). A default of providing all space to root and then letting uses modify from there is a much more friendly approach.
Other issues that I find confuse new uses revolve around "strange" Sun defaults, like AutoFS for /home (new users can't create home directories in /home, and often don't know why) and always booting a new system to a friendly Sendmail error because they don't provide a FQDN for /etc/hosts.
I look forward to watching this project unfold. Your a brave man Dave!
benr.
|
|
|
|
|
Posts:
1,575
From:
GB
Registered:
4/27/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 24, 2006 6:42 AM
in response to: benr
|
|
On Fri, 2006-03-24 at 00:12, Ben Rockwood wrote:
> 2) Perhaps I missed it, but I see no mention of SVM.
I get the impression that zfs is a key component of the
install/upgrade/patch management story in the future.
This is good, in the sense that zfs allows you to do
things differently - and in many cases, better.
However, I think that hitching the whole new install to
the zfs bandwagon is a mistake. Tying the two together
makes the project bigger, and also hinders adoption - it's
bad enough trying to convince some customers that they
ought to start looking at S10 even now, and I can see a
large amount of reticence in adopting a new filesystem
by some customers and ISVs. It's not even been released
yet!
So I think that UFS - and SVM - are going to be around for
a long while. They're going to have to be dealt with on
upgrade systems, at the very least.
--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 24, 2006 3:31 PM
in response to: ptribble
|
|
Peter Tribble wrote:
> On Fri, 2006-03-24 at 00:12, Ben Rockwood wrote:
>> 2) Perhaps I missed it, but I see no mention of SVM.
>
> I get the impression that zfs is a key component of the
> install/upgrade/patch management story in the future.
>
> This is good, in the sense that zfs allows you to do
> things differently - and in many cases, better.
>
> However, I think that hitching the whole new install to
> the zfs bandwagon is a mistake. Tying the two together
> makes the project bigger, and also hinders adoption - it's
> bad enough trying to convince some customers that they
> ought to start looking at S10 even now, and I can see a
> large amount of reticence in adopting a new filesystem
> by some customers and ISVs. It's not even been released
> yet!
>
I disagree with the view that tying the default closely to ZFS
complicates the project. There are a number of things that ZFS
simplifies for installation, and therefore simplifies for the user, and
we have to support it whether it's the default or not. But I doubt it
will prove a real hindrance to adoption - see below.
> So I think that UFS - and SVM - are going to be around for
> a long while. They're going to have to be dealt with on
> upgrade systems, at the very least.
>
Yes, we'll have to deal with upgrades of UFS and SVM, and continue
supporting them for quite some time. Selecting them for a *new* install
is likely to go into an advanced user path, though. I think that's
appropriate, in that they're for old hands who want to stick with the
tried & true and know Solaris already. The newbies, who we hope will
grow to outnumber the existing base, should learn the better way.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 24, 2006 1:24 PM
in response to: benr
|
|
Ben Rockwood wrote:
> This is wonderful Dave! I love your conclusions and proposals. I'll
> be the storage zealot with the following points:
>
> 1) On page 13 you noted iSCSI. I think that we'll continue to see
> iSCSI grow in popularity and in many ways be used in the same
> situations that we currently leverage NFS. For instance, I currently
> use an iSCSI LUN for my Flash Archives, home directory, backups, etc.
> In many cases I've already started using ZFS on iSCSI for these
> purposes. I don't see that this really changes your document at all,
> but just wanted to add some supporting evidence by the need you
> already defined in your document. I greatly appreciate you think far
> enough ahead to consider iSCSI at this early stage in the project.
>
> 2) Perhaps I missed it, but I see no mention of SVM. While SVM is a
> powerful and useful tool, in the context of SMB/Developers, it is
> extremely difficult to use. Root mirroring can be difficult and
> error prone even for seasoned Solaris administrators but is
> considered a standard practice throughout the industry. This is only
> made worse by the fact that you must be experienced with SVM to know
> that you need to set aside a small slice for the SVM MetaDB's. I've
> seen plenty of users and admins get frustrated with SVM immediately
> because they were unaware of this requirement untill they'd already
> fully installed the system.
>
Ignoring SVM is somewhat intentional, in that we'd expect ZFS to
supercede it, especially in the SMB/Developer market because the
simplicity of the administration model is especially attractive there.
Now, that's not to say we can't architect installation in such a way
that SVM or other traditional volume managers could be plugged in, and
perhaps that's the way to approach the problem: storage management is a
choice. Sun's likely to invest heavily in the ZFS choice and make it a
default in the Solaris product, but others might choose to invest in
alternatives for their own products. Thanks for raising the issue.
> Most Linux administrators would take for granted the fact that
> installers like Anaconda by default will setup LVM to root mirror.
> By making root mirroring an option during install we can really ease
> the burden on a lot of SA's and make it a non-issue for users who
> just want it but don't care about SVM at all.
>
Our expectation is that the ZFS pools for root will be mirrored.
>
> As a side note, the current default partitioning scheme is really
> misleading to new users. Allocating root just slightly larger than
> they need and then allocating all over free space to /export
> (something that Linux admins have rarely even heard of or
> understand). A default of providing all space to root and then
> letting uses modify from there is a much more friendly approach.
>
I'd probably split the difference a bit - we certainly have to allocate
more for root than we do, in order to support the best practice upgrade
model, but I don't think I'd put it all there.
> Other issues that I find confuse new uses revolve around "strange"
> Sun defaults, like AutoFS for /home (new users can't create home
> directories in /home, and often don't know why) and always booting a
> new system to a friendly Sendmail error because they don't provide a
> FQDN for /etc/hosts.
>
The latter is something I expect we'll fix in the default configuration.
Using autofs for /home has such a deep history with SunOS that it may
have achieved sacred cow status.
> I look forward to watching this project unfold. Your a brave man
> Dave!
Or possibly stupid. Thanks, though!
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Qingjiang (Bria...
Brian.Yuan@Sun.COM
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 23, 2006 4:36 PM
in response to: dminer
|
|
Hi, Dave,
I didn't find any information about localization packages installation,
do you have any plan to cover it later?
The current situation is, unless you choose customize install and check
some or all GEOs one by one, only C locale plus the locales of one of
the 9 big rules languages (if you manually choose that language instead
of the default English as the installation language) will be installed.
We have got more and more questions about how to add more non English
locales to an English only OS and also a lot of complains or even
escalations, and I think it's the time to revise the localization
packages install strategy. Localization packages include two different
sets of packages:
1. Locale enabling packages for locale shared objects, fonts, input
methods, iconv modules, X11 modules, etc.
2. Pure translation packages for the translations of messages in ON,
Gnome, Firefox, Thunderbird, Realplayer, etc.
The following are some options of the localization packages installation:
1. Current solution, only C locale will be installed unless you choose
one of the big rules language as the installation language or manually
check GEOs from customized install.
2. Install all locales by default, inform customers to deselect some
only if the disk space is limited
3. Separate locale enabling packages from pure translation packages and
install all locale enabling packages by default, and install other
translation packages by manually selection during installation, but this
should be clearly explained to customers before they choose "Default
Install" or "Customize Install".
4. Provide downloadable, easily installable and removable locale patches
or packages so that customers can add/remove locales easily.
Most Linux distros are using the 2nd option, but I prefer the 3rd and
also the 4th :-)
Thanks,
Brian
Dave Miner wrote:
> Greetings, Installation community members!
>
> I've just posted for discussion a document that I've been working on
> for the past couple of months: a draft strategy for Solaris
> installation.
>
> The document discusses the current state of Solaris installation in
> relation to customer requirements, and proposes a set of features and
> projects designed to address the requirements.
>
> Please understand that this is a proposal; while it's had some
> preliminary review by a small number of people in Solaris
> engineering, this is the first time it's been widely disseminated and
> thus I expect to receive, and incorporate, a great deal of feedback
> which will evolve it from this point.
>
> I would appreciate review comments by April 14. I encourage posting
> comments to this list, but private comments are of course equally
> acceptable.
>
> http://www.opensolaris.org/os/community/install/files/install_strategy.pdf
>
>
>
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 3:06 PM
in response to: Qingjiang (Bria...
|
|
Qingjiang (Brian) Yuan wrote:
> Hi, Dave,
> I didn't find any information about localization packages installation,
> do you have any plan to cover it later?
>
I had some basic information on issues from a presentation that our
staff received from globalization engineering a couple of months ago,
but I hadn't gone back to close the loop and fold it into the paper yet.
Thanks for bringing it up! Shows that I usually just install the C
locale, doesn't it? ;-)
> The current situation is, unless you choose customize install and check
> some or all GEOs one by one, only C locale plus the locales of one of
> the 9 big rules languages (if you manually choose that language instead
> of the default English as the installation language) will be installed.
>
> We have got more and more questions about how to add more non English
> locales to an English only OS and also a lot of complains or even
> escalations, and I think it's the time to revise the localization
> packages install strategy. Localization packages include two different
> sets of packages:
> 1. Locale enabling packages for locale shared objects, fonts, input
> methods, iconv modules, X11 modules, etc.
> 2. Pure translation packages for the translations of messages in ON,
> Gnome, Firefox, Thunderbird, Realplayer, etc.
>
> The following are some options of the localization packages installation:
>
> 1. Current solution, only C locale will be installed unless you choose
> one of the big rules language as the installation language or manually
> check GEOs from customized install.
> 2. Install all locales by default, inform customers to deselect some
> only if the disk space is limited
> 3. Separate locale enabling packages from pure translation packages and
> install all locale enabling packages by default, and install other
> translation packages by manually selection during installation, but this
> should be clearly explained to customers before they choose "Default
> Install" or "Customize Install".
> 4. Provide downloadable, easily installable and removable locale patches
> or packages so that customers can add/remove locales easily.
>
> Most Linux distros are using the 2nd option, but I prefer the 3rd and
> also the 4th :-)
>
Clearly there's dissatisfaction with the current solution, so we'll just
rule out #1 right off the bat :-).
#2 is attractive, in that it's similar to the proposed answer to the
driver problem - you may not know you need it until much later, and then
having to hunt around for the right one is a painful experience, so
let's just not make you do it. I'd guess it's the simplest in some ways.
I'm not sure what the engineering implications for #3 or #4 are (how
much restructuring of existing packages, etc.), if you can elaborate on
that it would be helpful. I also don't have the stats for the amount of
disk space that #2 consumes vs. what might be saved by the other
alternatives; if you have some rough guesses, that would be useful data,
too.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Qingjiang (Bria...
Brian.Yuan@Sun.COM
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 4:31 PM
in response to: dminer
|
|
Hi, Dave,
Thanks for the reply, please see below for more information:
Dave Miner wrote:
>> The following are some options of the localization packages
>> installation:
>>
>> 1. Current solution, only C locale will be installed unless you
>> choose one of the big rules language as the installation language or
>> manually check GEOs from customized install.
>> 2. Install all locales by default, inform customers to deselect some
>> only if the disk space is limited
>> 3. Separate locale enabling packages from pure translation packages
>> and install all locale enabling packages by default, and install
>> other translation packages by manually selection during installation,
>> but this should be clearly explained to customers before they choose
>> "Default Install" or "Customize Install".
>> 4. Provide downloadable, easily installable and removable locale
>> patches or packages so that customers can add/remove locales easily.
>>
>> Most Linux distros are using the 2nd option, but I prefer the 3rd
>> and also the 4th :-)
>>
>
> Clearly there's dissatisfaction with the current solution, so we'll
> just rule out #1 right off the bat :-).
>
> #2 is attractive, in that it's similar to the proposed answer to the
> driver problem - you may not know you need it until much later, and
> then having to hunt around for the right one is a painful experience,
> so let's just not make you do it. I'd guess it's the simplest in some
> ways.
Right, it's the simplest way :-).
Oops, I should change the #2 to the following since all of the locales
will also be installed in #3 by default:
2. Install all localization packages by default, inform customers to
deselect some only if the disk space is limited
One problem is you will get translated GUI, error messages and online
help if you login to some locales to do some i18n testing. This is not
what most of the English speaking developers would like to see if they
are only doing some i18n testing for their software products.
Another problem is unless the installed Solaris is something like a
SunRay server for many users speaking different languages from a
multinational company, usually it's not necessary to install the
translations of all languages :-)
>
> I'm not sure what the engineering implications for #3 or #4 are (how
> much restructuring of existing packages, etc.),
The package separation for #3 has already been done in Solaris. Basic
locale enabling packages (locale enabling, minimum fonts, input methods,
iconv, X11) are in Solaris Software CD 1 for CD based installation
purpose, a few are in CD 2, most of the other localization packages (
extra fonts, input methods and pure translations, etc.) are in the
Languages CD. (Document translations are in separate docs CDs)
We are planning on the downloadable locales for #4, but not a lot
progress so far. We need to work together with installation team and
also CNS team to decide the format and how to release those downloadable
packages.
> if you can elaborate on that it would be helpful. I also don't have
> the stats for the amount of disk space that #2 consumes vs. what might
> be saved by the other alternatives; if you have some rough guesses,
> that would be useful data, too.
The current size of all localization files are about 900MB after
installation, the translation packages are about 30MB for each of the 9
big rules languages, so it's about 900MB extra disk space for #2 and
630MB (900MB - 9*30MB) for #3 where only locale enabling packages are
installed by default. And I believe more and more locales and
translations will be added into OpenSolaris very soon :-)
What can be saved in #3 is not only the disk space which I think is not
so significant now, but also the installation time because there are
about 50 or more translation packages for each big rules language :-)
Thanks,
Brian
>
> Dave
> _______________________________________________
> install-discuss mailing list
> install-discuss at opensolaris dot org
> http://opensolaris.org/mailman/listinfo/install-discuss
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 27, 2006 12:32 PM
in response to: Qingjiang (Bria...
|
|
Qingjiang (Brian) Yuan wrote:
> Hi, Dave,
> Thanks for the reply, please see below for more information:
>
> Dave Miner wrote:
>
>>> The following are some options of the localization packages
>>> installation:
>>>
>>> 1. Current solution, only C locale will be installed unless you
>>> choose one of the big rules language as the installation language or
>>> manually check GEOs from customized install.
>>> 2. Install all locales by default, inform customers to deselect some
>>> only if the disk space is limited
>>> 3. Separate locale enabling packages from pure translation packages
>>> and install all locale enabling packages by default, and install
>>> other translation packages by manually selection during installation,
>>> but this should be clearly explained to customers before they choose
>>> "Default Install" or "Customize Install".
>>> 4. Provide downloadable, easily installable and removable locale
>>> patches or packages so that customers can add/remove locales easily.
>>>
>>> Most Linux distros are using the 2nd option, but I prefer the 3rd
>>> and also the 4th :-)
>>>
>> Clearly there's dissatisfaction with the current solution, so we'll
>> just rule out #1 right off the bat :-).
>>
>> #2 is attractive, in that it's similar to the proposed answer to the
>> driver problem - you may not know you need it until much later, and
>> then having to hunt around for the right one is a painful experience,
>> so let's just not make you do it. I'd guess it's the simplest in some
>> ways.
>
> Right, it's the simplest way :-).
> Oops, I should change the #2 to the following since all of the locales
> will also be installed in #3 by default:
> 2. Install all localization packages by default, inform customers to
> deselect some only if the disk space is limited
>
> One problem is you will get translated GUI, error messages and online
> help if you login to some locales to do some i18n testing. This is not
> what most of the English speaking developers would like to see if they
> are only doing some i18n testing for their software products.
That would seemingly only be an issue if you actually set a non-standard
locale as the default, though; you can login under your normal locale
and just set it to an alternate locale for the processes where you're
doing the testing.
> Another problem is unless the installed Solaris is something like a
> SunRay server for many users speaking different languages from a
> multinational company, usually it's not necessary to install the
> translations of all languages :-)
>
Yeah, it seems that the situations where you need all of them are pretty
limited, so it may not be the best default.
>> I'm not sure what the engineering implications for #3 or #4 are (how
>> much restructuring of existing packages, etc.),
>
> The package separation for #3 has already been done in Solaris. Basic
> locale enabling packages (locale enabling, minimum fonts, input methods,
> iconv, X11) are in Solaris Software CD 1 for CD based installation
> purpose, a few are in CD 2, most of the other localization packages (
> extra fonts, input methods and pure translations, etc.) are in the
> Languages CD. (Document translations are in separate docs CDs)
>
> We are planning on the downloadable locales for #4, but not a lot
> progress so far. We need to work together with installation team and
> also CNS team to decide the format and how to release those downloadable
> packages.
>
This does have some commonality with locating and installing additional
drivers, so we may be able to leverage any work that's going to be done
for that realm. One problem I see is that, while Update Connection
might be attractive as a Sun solution, it's not necessarily oriented at
being usable for other OpenSolaris distributions.
>> if you can elaborate on that it would be helpful. I also don't have
>> the stats for the amount of disk space that #2 consumes vs. what might
>> be saved by the other alternatives; if you have some rough guesses,
>> that would be useful data, too.
>
> The current size of all localization files are about 900MB after
> installation, the translation packages are about 30MB for each of the 9
> big rules languages, so it's about 900MB extra disk space for #2 and
> 630MB (900MB - 9*30MB) for #3 where only locale enabling packages are
> installed by default. And I believe more and more locales and
> translations will be added into OpenSolaris very soon :-)
>
So #3 is about a 15% premium for space, where #2 is about 20% vs. a
current Nevada complete installation, I think. Big enough numbers that
we need to think a bit carefully about it, because it does affect both
performance (as you noted subsequently) and ability to install just
based on available space.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
61
From:
Menlo Park, California, USA
Registered:
1/18/06
|
|
|
|
Re: Solaris installation strategy
Posted:
Apr 4, 2006 7:27 PM
in response to: dminer
|
|
I'm not necessarily the target market for Solaris... so take my comments with a grain of salt.
Still, some competitive info at this moment in time:
- The WinXP installers I've worked with install all locale info, but the Asian stuff isn't enabled (and thus I assume compressed somewhere in the installation on the hard disk) by default
- In the Mac 10.3 installer (I forget about 10.4) the east asian locales were not installed by default.
From the experiential standpoint:
I am a user who uses multiple input methods for multiple languages, and so I'm used to having to dig around to install my needed languages. I understand the concerns for disk space which I assume are the primary motivation for the points above. I doubt the installation times are so different as to cause me grief (maybe 32 vs 30min, at worst :-), so I accept the pain the vendors put me through. (the current Solaris installer does make it a bit of a nuisance for me to say "give me all" though)
At the same time, it frustrates me when I walk up to a system and the user didn't put the locale I need on the system. It isn't hard for me to rectify this on Windows, but I do hate mucking with someone's setup just so I can type "hi" to someone. :-)
(but, as a technical person, I understand I'm just being bitten by someone's now-outdated concern about saving disk space)
Strategic concern:
My sense is that the world is getting smaller, and we definitely want more and more folks to be adopting and using OpenSolaris all around the world. To me, that suggests that having all the locales there by default (or getting them there very easily) is strategically important.
Practical point:
At this point, the desktop experience is not fully localized. Last I saw there's a special separate version of OpenOffice for east asian locales.
I don't mean with this post to suggest a particular direction for localization issues. I just wanted to add them to the pot of issues to consier.
david
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Apr 5, 2006 11:29 AM
in response to: davidjon
|
|
David John Burrowes wrote:
> I'm not necessarily the target market for Solaris... so take my
> comments with a grain of salt.
>
> Still, some competitive info at this moment in time: - The WinXP
> installers I've worked with install all locale info, but the Asian
> stuff isn't enabled (and thus I assume compressed somewhere in the
> installation on the hard disk) by default - In the Mac 10.3 installer
> (I forget about 10.4) the east asian locales were not installed by
> default.
>
> From the experiential standpoint:
> I am a user who uses multiple input methods for multiple languages,
> and so I'm used to having to dig around to install my needed
> languages. I understand the concerns for disk space which I assume
> are the primary motivation for the points above. I doubt the
> installation times are so different as to cause me grief (maybe 32 vs
> 30min, at worst :-), so I accept the pain the vendors put me through.
> (the current Solaris installer does make it a bit of a nuisance for
> me to say "give me all" though)
>
> At the same time, it frustrates me when I walk up to a system and the
> user didn't put the locale I need on the system. It isn't hard for
> me to rectify this on Windows, but I do hate mucking with someone's
> setup just so I can type "hi" to someone. :-) (but, as a technical
> person, I understand I'm just being bitten by someone's now-outdated
> concern about saving disk space)
>
I don't know that it's an outdated concern yet. Brian Yuan's numbers
indicate a 10-20% space increase over a full install to add all the
locales if we did it right now; that's a large enough number that I
can't just consider it an easy choice. But the Windows compression
scheme you mention is a creative way of addressing it. We can think
about some options like that.
> Strategic concern: My sense is that the world is getting smaller, and
> we definitely want more and more folks to be adopting and using
> OpenSolaris all around the world. To me, that suggests that having
> all the locales there by default (or getting them there very easily)
> is strategically important.
>
> Practical point: At this point, the desktop experience is not fully
> localized. Last I saw there's a special separate version of
> OpenOffice for east asian locales.
>
> I don't mean with this post to suggest a particular direction for
> localization issues. I just wanted to add them to the pot of issues
> to consier.
>
Yeah, we definitely will need to consider it. I agree that the world is
getting smaller and the expectations in this area are getting higher, so
I don't expect we'll just go with the status quo.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
61
From:
Menlo Park, California, USA
Registered:
1/18/06
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Apr 5, 2006 12:08 PM
in response to: dminer
|
|
On Wed, 2006-04-05 at 11:29, Dave Miner wrote:
> > At the same time, it frustrates me when I walk up to a system and the
> > user didn't put the locale I need on the system. It isn't hard for
> > me to rectify this on Windows, but I do hate mucking with someone's
> > setup just so I can type "hi" to someone. :-) (but, as a technical
> > person, I understand I'm just being bitten by someone's now-outdated
> > concern about saving disk space)
> >
>
> I don't know that it's an outdated concern yet. Brian Yuan's numbers
> indicate a 10-20% space increase over a full install to add all the
> locales if we did it right now;
Sloppy wording on my part :-)
By "outdated" I meant on new/current consumer/developer
laptops/desktops, where disk space seems plentiful. Even as a hoarder of
disk space I'm not going to blink over the loss of several hundred meg.
Probably more is spent on various bundled apps or frameworks or pretty
backdrops that I never use... or a couple videos I've downloaded and
haven't bothered to discard yet.
This certainly isn't the same usage case as many folks have using
Solaris.
david
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,264
From:
US
Registered:
8/5/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 23, 2006 6:28 PM
in response to: dminer
|
|
On 3/23/06, Dave Miner <Dave dot Miner at sun dot com> wrote:
> I would appreciate review comments by April 14. I encourage posting
> comments to this list, but private comments are of course equally
> acceptable.
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.
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
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?
Page 11 - JASS is worth mentioning as well.
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.
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).
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.
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
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...
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.
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).
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.
- 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.
- 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.
- 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.
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.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 11:59 AM
in response to: mgerdts
|
|
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
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
326
From:
DE
Registered:
4/28/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 1:13 PM
in response to: dminer
|
|
Dave Miner <Dave dot Miner at Sun dot COM> writes:
> > 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
I think there's even a JET module (or plugin or whatever) in development
right now to allow use of ISC dhcpd with JET instead of just the Sun server
or manual editing. Probably someone on jet at Sun dot COM can comment?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,264
From:
US
Registered:
8/5/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 25, 2006 6:21 AM
in response to: dminer
|
|
On 3/24/06, Dave Miner <Dave dot Miner at sun dot com> wrote:
> 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.
Is this a bug or accepted limitation for some reason? Has pointing it
out caused it to be noted in an updated version of the document, a bug
filed, or both? I can file the bug through OpenSolaris if this is not
a conscious design decision.
> > 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.
Bug 4480319. I'm not sure if this is the one that I filed or not, but
it's been out there for a while. I've discussed this a bit on
zones-discuss as well because "zoneadm clone" now has the same problem
as live upgrade and flash archives.
> > 2) It has spotty support for upgrading to metadevices.
I am pretty sure that there is a bug on this one, but I am having
troubles finding it. Essentially, it boils down to the following
blowing up:
lucreate -s - -n newbe -m /:d30:ufs,preserve
luupgrade -f -n newbe -s $osmedia -J 'archive_location nfs://somewhere'
To work around this, I have done:
# cp $osmedia/Solaris_10/Tools/Boot/usr/sbin/install.d/pfinstall \
/var/tmp/pfinstall.orig
# mount -F lofs -O /dir/pfinstall-wrapper \
$osmedia/Solaris_10/Tools/Boot/usr/sbin/install.d/pfinstall
The wrapper causes the following change in the profile before calling
/var/tmp/pfinstall.orig
< filesys d30 existing /
filesys mirror:d30 c0t0d0s3 c0t1d0s3 existing /
> metadb c0t0d0s7
> metadb c0t1d0s7
Note that this has worked for me on one machine and just got it to
work in the past 24 hours. By no means am I convinced that it is a
robust workaround yet.
Beyond that, I found the following problems going from S9 to S10:
1) netgroup entries in /etc/shadow were missing but they were in /etc/passwd.
2) Solaris 10 should have more default password entries than Solaris 9
(gdm, webservd, etc.). These were lost.
3) swap and other metadevices were commented from vfstab
4) mount points for lofs file systems were missing
5) Complaints about svc:/system/cvc:default in maintenance mode when
it was not appropriate for the platform (should not have been enabled)
6) SVM related sevices are not enabled
7) JASS to the new boot environment looked kinda scary when it started
out with complaining about shared library problems calling zonename.
> > 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.
#2 is an ongoing issue that a co-worker has a case open on right now.
> #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.
I really like this idea. I suspect that it will be hard to achieve
(lots of dom0 support) if Xen cannot be nested arbitrarily deep.
> 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.
This oughta be interesting... Is this part of making zfs bootable
(that is, is it easier to write the bootstrap code for grub than it is
for openboot?)
> > 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.
The point here is that I need the DHCP server to be supported. I wish
that I could support my Solaris jumpstart environment using a sun
supported ISC dhcp server. My next best option is ISC on Red Hat.
> > 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.
Yes, that would be a good summary. Especially important when trying
to debug 15k-specific problems due to the extremely long POST.
> > 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?
Many backup programs have the ability to do one or more of the following:
1) Call a custom module that will generate a data stream to be backed up.
2) Call a custom script as a "pre-backup" script.
It may be (or may not be) useful to tie those mechanisms in with flash
tools to allow the backup system to manage the retention of old flash
archives (full or differential). Then in a restore situation, the
"special flash" tools on a live CD or network boot would be able to
load the appropriate data from tape, using the backup system as an
intermediary.
Simply doing flash archives to disk, then taking those to tape as
required may be more practical.
> > 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.
A key here may be to devise a file format that chunks a data stream
into lots of somewhat large pieces that are individually compressed,
using the compression algorithm that gives the right mix of speed and
size. When the data stream is being extracted, the various chunks
could be individually uncompressed on multiple hardware threads.
With ZFS promoting compressed file systems, perhaps compression is as
interesting of a use for a customized core as an FPU or encryption
accelerator.
> > 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?
Typical scenarios include:
1) Jumsptart tells me it can't find a matching rule in rules.ok. This
may mean that it could not find the SjumpsCF directory, that I
misspelled a hostname, or a host of other things. To debug, today I
have to exit the installation (ok) see what is mounted, run my custom
"catdhcp" script to show me what DHCP really sent me. Decoding vendor
options using dhcpinfo is non-trivial.
2) When trying to debug jumpstart installations, often times it
involves trying to understand what is really happening because there
is not a lot of documentation about how jumpstart really works. If
jumpstart were not running, I would typically use tools like truss,
snoop, etc. to figure out what is going on. Obviously, Sun has seen
this need too because in various Solaris releases you see other
options in the code that parses the boot command line to take
debugging arguments. However, those are not documented and appear
private.
Tools that would be useful:
1) Create an option that enables sshd during installation.
2) Create boot options that specify the dtrace script to run during
installation.
3) Include dtrace in the miniroot (haven't checked sparc, missing from newboot)
4) Consider having the ability to syslog installation progress.
One thing that I have found very nice on with various Linux distros
and Nexenta is that I have virtual consoles (or approximations
thereof) that allow me to observe the installation process more than
watching a progress bar. This is very helpful when getting to know a
new installer or debugging changes.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 27, 2006 2:13 PM
in response to: mgerdts
|
|
Mike Gerdts wrote:
> On 3/24/06, Dave Miner <Dave dot Miner at sun dot com> wrote:
>> 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.
>
> Is this a bug or accepted limitation for some reason? Has pointing it
> out caused it to be noted in an updated version of the document, a bug
> filed, or both? I can file the bug through OpenSolaris if this is not
> a conscious design decision.
>
Sorry, I should have said a bit more. It's a conscious design decision,
at least in terms of the way installation was designed oh so many years
ago, when sun4, sun4c, sun4d, and sun4u all walked the earth, disks were
small, and so on. sun4v's the first new architecture in SPARC systems
in 10 years. I need to look into the issues a bit, and it'll probably
lead to some more verbiage in the document when I update it in a couple
of weeks.
>>> 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.
>
> Bug 4480319. I'm not sure if this is the one that I filed or not, but
> it's been out there for a while. I've discussed this a bit on
> zones-discuss as well because "zoneadm clone" now has the same problem
> as live upgrade and flash archives.
>
Yeah, you're listed as one of the customers for it. Now that we have
SEEK_HOLE in Nevada, we could probably fix it without too much pain.
>>> 2) It has spotty support for upgrading to metadevices.
>
> I am pretty sure that there is a bug on this one, but I am having
> troubles finding it. Essentially, it boils down to the following
> blowing up:
>
> lucreate -s - -n newbe -m /:d30:ufs,preserve
> luupgrade -f -n newbe -s $osmedia -J 'archive_location nfs://somewhere'
>
> To work around this, I have done:
>
> # cp $osmedia/Solaris_10/Tools/Boot/usr/sbin/install.d/pfinstall \
> /var/tmp/pfinstall.orig
> # mount -F lofs -O /dir/pfinstall-wrapper \
> $osmedia/Solaris_10/Tools/Boot/usr/sbin/install.d/pfinstall
>
> The wrapper causes the following change in the profile before calling
> /var/tmp/pfinstall.orig
>
> < filesys d30 existing /
---
>> filesys mirror:d30 c0t0d0s3 c0t1d0s3 existing /
>> metadb c0t0d0s7
>> metadb c0t1d0s7
>
> Note that this has worked for me on one machine and just got it to
> work in the past 24 hours. By no means am I convinced that it is a
> robust workaround yet.
>
Kind of a scary workaround, but it'll be good input to the bug report.
> Beyond that, I found the following problems going from S9 to S10:
>
> 1) netgroup entries in /etc/shadow were missing but they were in /etc/passwd.
> 2) Solaris 10 should have more default password entries than Solaris 9
> (gdm, webservd, etc.). These were lost.
> 3) swap and other metadevices were commented from vfstab
> 4) mount points for lofs file systems were missing
> 5) Complaints about svc:/system/cvc:default in maintenance mode when
> it was not appropriate for the platform (should not have been enabled)
> 6) SVM related sevices are not enabled
> 7) JASS to the new boot environment looked kinda scary when it started
> out with complaining about shared library problems calling zonename.
>
Was this going to S10 1/06? That last one looks like something that
should occur only in that case.
Seems like a number of class-action scripts didn't work right, though.
Feels like something really basic went wrong in the installation.
>>> 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.
>
> #2 is an ongoing issue that a co-worker has a case open on right now.
>
>> #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.
>
> I really like this idea. I suspect that it will be hard to achieve
> (lots of dom0 support) if Xen cannot be nested arbitrarily deep.
>
Yes, I expect it's well outside the design center, so it'll be an
interesting discussion.
>> 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.
>
> This oughta be interesting... Is this part of making zfs bootable
> (that is, is it easier to write the bootstrap code for grub than it is
> for openboot?)
>
Yes, it's very much related to the zfs boot support. As anyone who
tried to use WAN installation found, getting new OBP features released
on all the platforms is very difficult.
>>> 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.
>
> The point here is that I need the DHCP server to be supported. I wish
> that I could support my Solaris jumpstart environment using a sun
> supported ISC dhcp server. My next best option is ISC on Red Hat.
>
Can't offer you anything in the short term, though the N1 System Manager
product does so for the platforms it supports.
...
>>> 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?
>
> Many backup programs have the ability to do one or more of the following:
>
> 1) Call a custom module that will generate a data stream to be backed up.
> 2) Call a custom script as a "pre-backup" script.
>
> It may be (or may not be) useful to tie those mechanisms in with flash
> tools to allow the backup system to manage the retention of old flash
> archives (full or differential). Then in a restore situation, the
> "special flash" tools on a live CD or network boot would be able to
> load the appropriate data from tape, using the backup system as an
> intermediary.
>
> Simply doing flash archives to disk, then taking those to tape as
> required may be more practical.
>
Thanks for clarifying. I'll think about this some.
>>> 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.
>
> A key here may be to devise a file format that chunks a data stream
> into lots of somewhat large pieces that are individually compressed,
> using the compression algorithm that gives the right mix of speed and
> size. When the data stream is being extracted, the various chunks
> could be individually uncompressed on multiple hardware threads.
>
Seems like it may be overkill based on likely source and destination
bandwidth, but an interesting idea.
> With ZFS promoting compressed file systems, perhaps compression is as
> interesting of a use for a customized core as an FPU or encryption
> accelerator.
>
>>> 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?
>
> Typical scenarios include:
>
> 1) Jumsptart tells me it can't find a matching rule in rules.ok. This
> may mean that it could not find the SjumpsCF directory, that I
> misspelled a hostname, or a host of other things. To debug, today I
> have to exit the installation (ok) see what is mounted, run my custom
> "catdhcp" script to show me what DHCP really sent me. Decoding vendor
> options using dhcpinfo is non-trivial.
>
Yeah, we could easily do more here. Used to be snoop was my primary
debugger of this stuff, but it would be better not to have to go there.
> 2) When trying to debug jumpstart installations, often times it
> involves trying to understand what is really happening because there
> is not a lot of documentation about how jumpstart really works. If
> jumpstart were not running, I would typically use tools like truss,
> snoop, etc. to figure out what is going on. Obviously, Sun has seen
> this need too because in various Solaris releases you see other
> options in the code that parses the boot command line to take
> debugging arguments. However, those are not documented and appear
> private.
>
One of the benefits you'll get out of us doing the future work in the
open is real design documents out on opensolaris.org, so you'll be able
to dig in as deep as you like. Not that we shouldn't also put effort
into making it easy to understand without that level of effort, though.
> Tools that would be useful:
>
> 1) Create an option that enables sshd during installation.
I think that's coming soon with one of the security projects.
> 2) Create boot options that specify the dtrace script to run during
> installation.
> 3) Include dtrace in the miniroot (haven't checked sparc, missing from newboot)
Somebody else pointed this out to me a couple of weeks ago. No reason
we shouldn't have dtrace available and a way to auto-invoke a D script.
> 4) Consider having the ability to syslog installation progress.
>
Reasonable suggestion.
> One thing that I have found very nice on with various Linux distros
> and Nexenta is that I have virtual consoles (or approximations
> thereof) that allow me to observe the installation process more than
> watching a progress bar. This is very helpful when getting to know a
> new installer or debugging changes.
Would some ads during the install help? ;^)
Seriously, I hope we'll be bringing back virtual console support soon.
It's much missed.
Thanks for all your comments, Mike.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,264
From:
US
Registered:
8/5/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 27, 2006 5:25 PM
in response to: dminer
|
|
On 3/27/06, Dave Miner <Dave dot Miner at sun dot com> wrote:
> Mike Gerdts wrote:
> > On 3/24/06, Dave Miner <Dave dot Miner at sun dot com> wrote:
> >> 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.
> >
> > Is this a bug or accepted limitation for some reason? Has pointing it
> > out caused it to be noted in an updated version of the document, a bug
> > filed, or both? I can file the bug through OpenSolaris if this is not
> > a conscious design decision.
> >
>
> Sorry, I should have said a bit more. It's a conscious design decision,
> at least in terms of the way installation was designed oh so many years
> ago, when sun4, sun4c, sun4d, and sun4u all walked the earth, disks were
> small, and so on. sun4v's the first new architecture in SPARC systems
> in 10 years. I need to look into the issues a bit, and it'll probably
> lead to some more verbiage in the document when I update it in a couple
> of weeks.
Is it safe to simply add the few packages that are sun4v or T2000
specific to a sun4u system (15k) to enable building a single sparc
flar? I'm not asking for an in-depth analysis here, just wondering if
you have a strong gut feeling one way or another. I *really* want to
have one sparc flar.
> >>> 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.
> >
> > Bug 4480319. I'm not sure if this is the one that I filed or not, but
> > it's been out there for a while. I've discussed this a bit on
> > zones-discuss as well because "zoneadm clone" now has the same problem
> > as live upgrade and flash archives.
> >
>
> Yeah, you're listed as one of the customers for it. Now that we have
> SEEK_HOLE in Nevada, we could probably fix it without too much pain.
That was also mentioned on the zones-discuss list. One of these days
maybe I'll pick this one up. For right now, I am usually OK with
truncating lastlog or adding it to an exclude list.
> >>> 2) It has spotty support for upgrading to metadevices.
> >
> > I am pretty sure that there is a bug on this one, but I am having
> > troubles finding it. Essentially, it boils down to the following
> > blowing up:
> >
> > lucreate -s - -n newbe -m /:d30:ufs,preserve
> > luupgrade -f -n newbe -s $osmedia -J 'archive_location nfs://somewhere'
> >
> > To work around this, I have done:
> >
> > # cp $osmedia/Solaris_10/Tools/Boot/usr/sbin/install.d/pfinstall \
> > /var/tmp/pfinstall.orig
> > # mount -F lofs -O /dir/pfinstall-wrapper \
> > $osmedia/Solaris_10/Tools/Boot/usr/sbin/install.d/pfinstall
> >
> > The wrapper causes the following change in the profile before calling
> > /var/tmp/pfinstall.orig
> >
> > < filesys d30 existing /
> ---
> >> filesys mirror:d30 c0t0d0s3 c0t1d0s3 existing /
> >> metadb c0t0d0s7
> >> metadb c0t1d0s7
> >
> > Note that this has worked for me on one machine and just got it to
> > work in the past 24 hours. By no means am I convinced that it is a
> > robust workaround yet.
> >
>
> Kind of a scary workaround, but it'll be good input to the bug report.
Very much so. I wish that the source code for live upgrade was available...
> > Beyond that, I found the following problems going from S9 to S10:
> >
> > 1) netgroup entries in /etc/shadow were missing but they were in /etc/passwd.
> > 2) Solaris 10 should have more default password entries than Solaris 9
> > (gdm, webservd, etc.). These were lost.
> > 3) swap and other metadevices were commented from vfstab
> > 4) mount points for lofs file systems were missing
> > 5) Complaints about svc:/system/cvc:default in maintenance mode when
> > it was not appropriate for the platform (should not have been enabled)
> > 6) SVM related sevices are not enabled
> > 7) JASS to the new boot environment looked kinda scary when it started
> > out with complaining about shared library problems calling zonename.
> >
>
> Was this going to S10 1/06? That last one looks like something that
> should occur only in that case.
It was S10 1/06. Running JASS after reboot was just fine, though. It
just speaks to the point that live upgrade could really stand to run
in its own virtual machine.
> Seems like a number of class-action scripts didn't work right, though.
> Feels like something really basic went wrong in the installation.
By class action, I assume you mean post-install scripts, right? My
understanding was that these should run only after a pkgadd, not when
a flash archive is applied. Or are there other scripts that I am not
aware of?
The netgroup thingy seems to be related to a poorly documented feature
that got new behavior with somewhat recent updates to PAM.
Previously, netgroup entries were not required in /etc/shadow.
Frankly, it wouldn't surprise me to see this one fall through the
cracks.
The fact that passwd was missing some entries seems like an
over-zealous sync task.
Mount points and vfstab problems surprised me. I haven't seen this
problem before.
Because the flar was generated on a 15k, having system/cvc enabled was
not terribly surprising.
SVM related services not being enabled is a problem for regular
jumpstarts as well.
> >> 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.
> >
> > This oughta be interesting... Is this part of making zfs bootable
> > (that is, is it easier to write the bootstrap code for grub than it is
> > for openboot?)
> >
>
> Yes, it's very much related to the zfs boot support. As anyone who
> tried to use WAN installation found, getting new OBP features released
> on all the platforms is very difficult.
I got excited about wanboot when I first read about it in ~2002 and
was disappointed to see no OpenBoot updates to support it. The first
platform I have seen ship with network-boot-params as a variable in
nvram is a T2000. In that time I completely gave up on the
technology. There are some cases where I may start looking at it
again.
> >>> 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.
> >
> > A key here may be to devise a file format that chunks a data stream
> > into lots of somewhat large pieces that are individually compressed,
> > using the compression algorithm that gives the right mix of speed and
> > size. When the data stream is being extracted, the various chunks
> > could be individually uncompressed on multiple hardware threads.
> >
>
> Seems like it may be overkill based on likely source and destination
> bandwidth, but an interesting idea.
Within a year I bet my NFS file servers are on 10 gigabit. "Jumpstart
clients" are increasingly getting faster internal disks, using SAN
boot, or possibly using iSCSI to a decent array. At the same time,
single-threaded CPU performance has seemed to hit a brick wall in
favor of multi-threaded designs.
A simple test of "time gzcat /tmp/stuff.tar.gz > /dev/null" indicates
that gzcat can process about 27 MB/s on a Blade 1500 running at 1062
MHz. Rather interestingly, zcat can only do about 19 MB/s. The file
stuff.tar contains about 21 MB of stuff from /sbin and /etc on a S9
box. These data rates will keep pretty much any internal disk today
saturated, especially with the number of small files typically found
in an OS. However, if cache-based arrays are used for the OS disk or
the flash archive contains large files, the single-core performance
can start to get in the way. Obviously, more analysis is needed
before deciding this is the future of decompression.
If you look at the problem from the other direction, however,
compression can benefit greatly from parallel algorithms because even
fastest cores are slower at gzip or bzip2 than moderately fast disks.
> >>> Other ramblings...
> >>>
> > One thing that I have found very nice on with various Linux distros
> > and Nexenta is that I have virtual consoles (or approximations
> > thereof) that allow me to observe the installation process more than
> > watching a progress bar. This is very helpful when getting to know a
> > new installer or debugging changes.
>
> Would some ads during the install help? ;^)
Only if you can come up with no less than 4 different versions of how
Sun's founders decided upon a name. Don't bore me with the "Stanford
Univeristy Network". Talk about their forebearers praying to Helios
or somesuch.
> Seriously, I hope we'll be bringing back virtual console support soon.
> It's much missed.
>
> Thanks for all your comments, Mike.
Not a problem. I'm glad to have an audience that is honestly looking
for feedback to improve the product. It's kinda like therapy for a
grumpy sysadmin - there are a few years of pent-up frustration that I
can now work through. :)
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 27, 2006 11:57 PM
in response to: mgerdts
|
|
>Is it safe to simply add the few packages that are sun4v or T2000
>specific to a sun4u system (15k) to enable building a single sparc
>flar? I'm not asking for an in-depth analysis here, just wondering if
>you have a strong gut feeling one way or another. I *really* want to
>have one sparc flar.
I believe that this was possible before.
(But note that our patch tools were broken for a while which regards
to multiple versions of the same package which is what will happen)
Casper
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,264
From:
US
Registered:
8/5/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 28, 2006 6:49 AM
in response to: casper
|
|
On 3/28/06, Casper.***@sun.com <Casper.***@sun.com> wrote:
>
> >Is it safe to simply add the few packages that are sun4v or T2000
> >specific to a sun4u system (15k) to enable building a single sparc
> >flar? I'm not asking for an in-depth analysis here, just wondering if
> >you have a strong gut feeling one way or another. I *really* want to
> >have one sparc flar.
>
> I believe that this was possible before.
>
> (But note that our patch tools were broken for a while which regards
> to multiple versions of the same package which is what will happen)
>
> Casper
I just noticed another snag on this one. It seems as though
flarcreate does not properly recognize which architectures are
available (or I got sun4v onto the disk in the wrong way...)
As a quick and dirty test, I took a V240 that I had just imaged with a
S10 1/06 SUNWCXall flar. I then...
# cd $media/Solaris_10/Product
# pkgadd -d . *.v
# flarcreate -SHc -n testflar /var/tmp/testflar
In the header of /var/tmp/testflar appears the line:
content_architectures=sun4u
I expect this is going to lead to having jumpstart tell me that the
flar lacks the appropriate architecture support when I go to install
it on a sun4v box.
This could be related to the warnings during pkgadd that "X package
pathnames are already properly installed." I suspect that was for
directories that were common to the *.u and *.v packages but have not
yet checked to be sure there were not more serious conflicts.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 28, 2006 6:57 AM
in response to: mgerdts
|
|
>I expect this is going to lead to having jumpstart tell me that the
>flar lacks the appropriate architecture support when I go to install
>it on a sun4v box.
>
>This could be related to the warnings during pkgadd that "X package
>pathnames are already properly installed." I suspect that was for
>directories that were common to the *.u and *.v packages but have not
>yet checked to be sure there were not more serious conflicts.
The only conflicting file I could find was:
/etc/flash/precreation/caplib.
But it looks like it's the same:
SUNWcar.u/pkgmap:1 f none etc/flash/precreation/caplib 0500 root sys 3376 7288 1142807849
SUNWcar.v/pkgmap:1 f none etc/flash/precreation/caplib 0500 root sys 3376 7288 1142807849
The rest is just in platform specific directories.
Casper
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 28, 2006 8:12 AM
in response to: mgerdts
|
|
Mike Gerdts wrote:
> ***3/28/06, Casper.***@sun.com <Casper.***@sun.com> wrote:
>>> Is it safe to simply add the few packages that are sun4v or T2000
>>> specific to a sun4u system (15k) to enable building a single sparc
>>> flar? I'm not asking for an in-depth analysis here, just wondering if
>>> you have a strong gut feeling one way or another. I *really* want to
>>> have one sparc flar.
>> I believe that this was possible before.
>>
>> (But note that our patch tools were broken for a while which regards
>> to multiple versions of the same package which is what will happen)
>>
>> Casper
>
> I just noticed another snag on this one. It seems as though
> flarcreate does not properly recognize which architectures are
> available (or I got sun4v onto the disk in the wrong way...)
>
> As a quick and dirty test, I took a V240 that I had just imaged with a
> S10 1/06 SUNWCXall flar. I then...
>
> # cd $media/Solaris_10/Product
> # pkgadd -d . *.v
> # flarcreate -SHc -n testflar /var/tmp/testflar
>
> In the header of /var/tmp/testflar appears the line:
>
> content_architectures=sun4u
>
I'm sure that's grabbed directly out of uname; cross-architecture flar's
aren't really accommodated by the current design, as I recall.
> I expect this is going to lead to having jumpstart tell me that the
> flar lacks the appropriate architecture support when I go to install
> it on a sun4v box.
>
Yeah, that's what I'd expect.
> This could be related to the warnings during pkgadd that "X package
> pathnames are already properly installed." I suspect that was for
> directories that were common to the *.u and *.v packages but have not
> yet checked to be sure there were not more serious conflicts.
>
Looks like Casper answered this part.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,264
From:
US
Registered:
8/5/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 29, 2006 5:48 AM
in response to: dminer
|
|
On 3/28/06, Dave Miner <Dave dot Miner at sun dot com> wrote:
> Mike Gerdts***ote:
> > On 3/28/06, Casper.***@sun.com <Casper.***@sun.com> wrote:
> >>> Is it safe to simply add the few packages that are sun4v or T2000
> >>> specific to a sun4u system (15k) to enable building a single sparc
> >>> flar? I'm not asking for an in-depth analysis here, just wondering if
> >>> you have a strong gut feeling one way or another. I *really* want to
> >>> have one sparc flar.
> >> I believe that this was possible before.
> >>
> >> (But note that our patch tools were broken for a while which regards
> >> to multiple versions of the same package which is what will happen)
> >>
> >> Casper
> >
> > I just noticed another snag on this one. It seems as though
> > flarcreate does not properly recognize which architectures are
> > available (or I got sun4v onto the disk in the wrong way...)
> >
> > As a quick and dirty test, I took a V240 that I had just imaged with a
> > S10 1/06 SUNWCXall flar. I then...
> >
> > # cd $media/Solaris_10/Product
> > # pkgadd -d . *.v
> > # flarcreate -SHc -n testflar /var/tmp/testflar
> >
> > In the header of /var/tmp/testflar appears the line:
> >
> > content_architectures=sun4u
> >
>
> I'm sure that's grabbed directly out of uname; cross-architecture flar's
> aren't really accommodated by the current design, as I recall.
I did some more digging on this. In /usr/sbin/flarcreate we can see
how content_architectures is created. Notice that it will make use of
/var/sadm/system/admin/.platform. The flar I created with SUNWCXall
on a 15k contains:
PLATFORM_GROUP=sun4u
INST_ARCH=sparc
PLATFORM_NAME=SUNW,SPARCstation-fusion
PLATFORM_ID=SUNW,SPARCstation-fusion
IN_PLATFORM_GROUP=sun4u
PLATFORM_NAME=FJSV,GP
PLATFORM_ID=FJSV,GP
IN_PLATFORM_GROUP=sun4u
PLATFORM_NAME=FJSV,GPUU
PLATFORM_ID=FJSV,GPUU
IN_PLATFORM_GROUP=sun4u
PLATFORM_NAME=SUNW,Ultra-Enterprise-10000
PLATFORM_ID=SUNW,Ultra-Enterprise-10000
IN_PLATFORM_GROUP=sun4u
If I add the following line to the end:
PLATFORM_GROUP=sun4v
Then the flash archive header says:
content_architectures=sun4u,sun4v
I don't have a T2000 that I can test a fresh installation on, but when
I create a boot environment with live upgrade, it begins to extract
the archive. In my first run at this it complained about a zone that
I had configured. I've uninstalled that zone and have restarted the
luupgrade.
This begs the questions:
Is this a design decision or a bug?
Is this currently and over the next year so far out of the norm that
it will be poorly tested and should be avoided? (My guess is that as
people start ramping up on sun4v platforms they will be requesting
exactly what I am after. As I recall, sun4m was pretty obsolete by
the time that live upgrade was introduced so this has not been a major
topic thus far.)
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 29, 2006 8:02 AM
in response to: mgerdts
|
|
Mike Gerdts wrote:
...
>
> I did some more digging on this. In /usr/sbin/flarcreate we can see
> how content_architectures is created. Notice that it will make use of
> /var/sadm/system/admin/.platform. The flar I created with SUNWCXall
> on a 15k contains:
>
> PLATFORM_GROUP=sun4u
> INST_ARCH=sparc
> PLATFORM_NAME=SUNW,SPARCstation-fusion
> PLATFORM_ID=SUNW,SPARCstation-fusion
> IN_PLATFORM_GROUP=sun4u
> PLATFORM_NAME=FJSV,GP
> PLATFORM_ID=FJSV,GP
> IN_PLATFORM_GROUP=sun4u
> PLATFORM_NAME=FJSV,GPUU
> PLATFORM_ID=FJSV,GPUU
> IN_PLATFORM_GROUP=sun4u
> PLATFORM_NAME=SUNW,Ultra-Enterprise-10000
> PLATFORM_ID=SUNW,Ultra-Enterprise-10000
> IN_PLATFORM_GROUP=sun4u
>
> If I add the following line to the end:
>
> PLATFORM_GROUP=sun4v
>
> Then the flash archive header says:
>
> content_architectures=sun4u,sun4v
>
> I don't have a T2000 that I can test a fresh installation on, but when
> I create a boot environment with live upgrade, it begins to extract
> the archive. In my first run at this it complained about a zone that
> I had configured. I've uninstalled that zone and have restarted the
> luupgrade.
>
> This begs the questions:
>
> Is this a design decision or a bug?
>
I went back and researched the specs.
Flash was intended to support multiple architectures, provided the
master system had them installed. The original project specified adding
an "arch" keyword to Jumpstart profiles, which would allow specifying
additional architectures when installing a system using packages. There
were also to be additional UI pieces for the interactive installer to
accomplish same. These have never been implemented, I'd assume because
by the time Flash came along, everything but sun4u was well on the way
to being removed from support and there was also no plan for anything
called sun4v at the time. Now it's an issue again.
> Is this currently and over the next year so far out of the norm that
> it will be poorly tested and should be avoided? (My guess is that as
> people start ramping up on sun4v platforms they will be requesting
> exactly what I am after. As I recall, sun4m was pretty obsolete by
> the time that live upgrade was introduced so this has not been a major
> topic thus far.)
>
At the moment, we would consider it non-supported, it's certainly not
tested, and therefore you probably want to avoid it for now.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 28, 2006 8:38 AM
in response to: mgerdts
|
|
[snipped down to things not already answered via other email]
...
>>>>> 2) It has spotty support for upgrading to metadevices.
>>> I am pretty sure that there is a bug on this one, but I am having
>>> troubles finding it. Essentially, it boils down to the following
>>> blowing up:
>>>
>>> lucreate -s - -n newbe -m /:d30:ufs,preserve
>>> luupgrade -f -n newbe -s $osmedia -J 'archive_location nfs://somewhere'
>>>
>>> To work around this, I have done:
>>>
>>> # cp $osmedia/Solaris_10/Tools/Boot/usr/sbin/install.d/pfinstall \
>>> /var/tmp/pfinstall.orig
>>> # mount -F lofs -O /dir/pfinstall-wrapper \
>>> $osmedia/Solaris_10/Tools/Boot/usr/sbin/install.d/pfinstall
>>>
>>> The wrapper causes the following change in the profile before calling
>>> /var/tmp/pfinstall.orig
>>>
>>> < filesys d30 existing /
>> ---
>>>> filesys mirror:d30 c0t0d0s3 c0t1d0s3 existing /
>>>> metadb c0t0d0s7
>>>> metadb c0t1d0s7
>>> Note that this has worked for me on one machine and just got it to
>>> work in the past 24 hours. By no means am I convinced that it is a
>>> robust workaround yet.
>>>
>> Kind of a scary workaround, but it'll be good input to the bug report.
>
> Very much so. I wish that the source code for live upgrade was available...
>
We're working on the plan for getting the rest of the install code out.
It's about 10 times the size of the packaging code, so it's not a
trivial task, and there are a couple of legal issues to be researched.
Probably be at least 4 months, and that's perhaps optimistic ;-)
>>> Beyond that, I found the following problems going from S9 to S10:
>>>
>>> 1) netgroup entries in /etc/shadow were missing but they were in /etc/passwd.
>>> 2) Solaris 10 should have more default password entries than Solaris 9
>>> (gdm, webservd, etc.). These were lost.
>>> 3) swap and other metadevices were commented from vfstab
>>> 4) mount points for lofs file systems were missing
>>> 5) Complaints about svc:/system/cvc:default in maintenance mode when
>>> it was not appropriate for the platform (should not have been enabled)
>>> 6) SVM related sevices are not enabled
>>> 7) JASS to the new boot environment looked kinda scary when it started
>>> out with complaining about shared library problems calling zonename.
>>>
>> Was this going to S10 1/06? That last one looks like something that
>> should occur only in that case.
>
> It was S10 1/06. Running JASS after reboot was just fine, though. It
> just speaks to the point that live upgrade could really stand to run
> in its own virtual machine.
>
I wouldn't expect it to have been a problem if the LU required patches
were applied, though.
>> Seems like a number of class-action scripts didn't work right, though.
>> Feels like something really basic went wrong in the installation.
>
> By class action, I assume you mean post-install scripts, right? My
> understanding was that these should run only after a pkgadd, not when
> a flash archive is applied. Or are there other scripts that I am not
> aware of?
>
Class-action scripts (CAS's is how you'll often see them referenced) are
different from postinstall scripts. Every file we install has a class
it's associated with; most are in "none" which means they just get
copied from the package and have their ownership and mode adjusted
appropriately. But when there's special handling required, they are
placed in some other named class and a script is written to do the
special work. Config files usually need to be manipulated in this way
so that customizations are preserved across upgrades.
> The netgroup thingy seems to be related to a poorly documented feature
> that got new behavior with somewhat recent updates to PAM.
> Previously, netgroup entries were not required in /etc/shadow.
> Frankly, it wouldn't surprise me to see this one fall through the
> cracks.
>
> The fact that passwd was missing some entries seems like an
> over-zealous sync task.
>
> Mount points and vfstab problems surprised me. I haven't seen this
> problem before.
>
> Because the flar was generated on a 15k, having system/cvc enabled was
> not terribly surprising.
>
> SVM related services not being enabled is a problem for regular
> jumpstarts as well.
>
One thing I'm realizing here is that you seem to have installed the new
boot environment using a flash archive, right? If so, the class-action
scripts don't get run during that install, as they would have been run
on the original installation of the master system. More likely, some of
this may be the result of the synchronization between boot environments
that LU does for you after you luactivate and reboot (synclist(4) talks
about how this is done). You might see what's in /etc/lu/sync.log.
>>>> 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.
>>> This oughta be interesting... Is this part of making zfs bootable
>>> (that is, is it easier to write the bootstrap code for grub than it is
>>> for openboot?)
>>>
>> Yes, it's very much related to the zfs boot support. As anyone who
>> tried to use WAN installation found, getting new OBP features released
>> on all the platforms is very difficult.
>
> I got excited about wanboot when I first read about it in ~2002 and
> was disappointed to see no OpenBoot updates to support it. The first
> platform I have seen ship with network-boot-params as a variable in
> nvram is a T2000. In that time I completely gave up on the
> technology. There are some cases where I may start looking at it
> again.
>
It should work on all the newer, smaller systems, but I certainly
understand why people may have given up considering the delay in getting
the OBP updates out there. It still doesn't work on 15K's and 6900's
and their ilk.
>>>>> 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.
>>> A key here may be to devise a file format that chunks a data stream
>>> into lots of somewhat large pieces that are individually compressed,
>>> using the compression algorithm that gives the right mix of speed and
>>> size. When the data stream is being extracted, the various chunks
>>> could be individually uncompressed on multiple hardware threads.
>>>
>> Seems like it may be overkill based on likely source and destination
>> bandwidth, but an interesting idea.
>
> Within a year I bet my NFS file servers are on 10 gigabit. "Jumpstart
> clients" are increasingly getting faster internal disks, using SAN
> boot, or possibly using iSCSI to a decent array. At the same time,
> single-threaded CPU performance has seemed to hit a brick wall in
> favor of multi-threaded designs.
>
No disagreement there.
> A simple test of "time gzcat /tmp/stuff.tar.gz > /dev/null" indicates
> that gzcat can process about 27 MB/s on a Blade 1500 running at 1062
> MHz. Rather interestingly, zcat can only do about 19 MB/s. The file
> stuff.tar contains about 21 MB of stuff from /sbin and /etc on a S9
> box. These data rates will keep pretty much any internal disk today
> saturated, especially with the number of small files typically found
> in an OS. However, if cache-based arrays are used for the OS disk or
> the flash archive contains large files, the single-core performance
> can start to get in the way. Obviously, more analysis is needed
> before deciding this is the future of decompression.
>
> If you look at the problem from the other direction, however,
> compression can benefit greatly from parallel algorithms because even
> fastest cores are slower at gzip or bzip2 than moderately fast disks.
>
Thanks for the ideas. I'll keep it on my list of things to consider for
the design stage, we'd certainly do some analysis of several approaches
to try and optimize performance.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
225
From:
CZ
Registered:
3/22/06
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 2:14 AM
in response to: dminer
|
|
Great document Dave,
I'm fairly new to the solaris world (but with a lot of experience from
linux/windows/bsd world) and this document summarizes all the things
that I was just "feeling" for me.
My question is, are there any concrete plans for packaging format? You
seem to have agreed upon going the anaconda way for the installer (by
building caiman), but I have not found any proposal regarding the
underlying package format. Are there any evaluation studies, or are you
planning to do them, or are you planning to invent yet another packaging
format for Solaris world (IMHO a very bad idea).
thanx,
Martin
Dave Miner wrote:
> Greetings, Installation community members!
>
> I've just posted for discussion a document that I've been working on for
> the past couple of months: a draft strategy for Solaris installation.
>
> The document discusses the current state of Solaris installation in
> relation to customer requirements, and proposes a set of features and
> projects designed to address the requirements.
>
> Please understand that this is a proposal; while it's had some
> preliminary review by a small number of people in Solaris engineering,
> this is the first time it's been widely disseminated and thus I expect
> to receive, and incorporate, a great deal of feedback which will evolve
> it from this point.
>
> I would appreciate review comments by April 14. I encourage posting
> comments to this list, but private comments are of course equally
> acceptable.
>
> http://www.opensolaris.org/os/community/install/files/install_strategy.pdf
>
> Thanks,
>
> Dave
> _______________________________________________
> install-discuss mailing list
> install-discuss at opensolaris dot org
> http://opensolaris.org/mailman/listinfo/install-discuss
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 3:35 PM
in response to: mmman
|
|
Martin Man wrote:
> Great document Dave,
>
Thank you.
> I'm fairly new to the solaris world (but with a lot of experience from
> linux/windows/bsd world) and this document summarizes all the things
> that I was just "feeling" for me.
>
> My question is, are there any concrete plans for packaging format? You
> seem to have agreed upon going the anaconda way for the installer (by
> building caiman), but I have not found any proposal regarding the
> underlying package format. Are there any evaluation studies, or are you
> planning to do them, or are you planning to invent yet another packaging
> format for Solaris world (IMHO a very bad idea).
>
There aren't any firm plans yet. Not even soft ones. The evaluation
process is more complex, in that it really gets into many aspects of
Sun's (and our customers') businesses, so you can be sure that there
will be a great deal of planning and evaluation. I hope we'll be able
to say more about it here soon, but since it's someone else leading the
work, I'm not going to pre-empt him with my own opinions or speculation.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,575
From:
GB
Registered:
4/27/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 5:52 AM
in response to: dminer
|
|
On Thu, 2006-03-23 at 17:46, Dave Miner wrote:
> Greetings, Installation community members!
>
> I've just posted for discussion a document that I've been working on for
> the past couple of months: a draft strategy for Solaris installation.
...
> I would appreciate review comments by April 14. I encourage posting
> comments to this list, but private comments are of course equally
> acceptable.
>
> http://www.opensolaris.org/os/community/install/files/install_strategy.pdf
First thoughts:
Section 2
Audience - you're looking at the SMB/Developer segment, and the
enterprise segment. This ignores another important class, specifically
the lone user. (Some use the term "hobbyist", but I want to avoid that.)
The lone user may have the opportunity to play with Solaris - either
installing it themselves, or using a system installed by a friend or
colleague. This class of user may well become a developer or customer
later, and carries their experience with them. They have less
experience and knowledge, less motivation, and much lower tolerance
than developers.
2.1 You say that the scale of operations is not necessarily large
enough to justify complex automation techniques, yet I would argue that
(a) automation shouldn't be complex, and (b) automation is justifiable
even for single-system setups (think recovery). In other words, while
they would not initially have an environment in which automation were
possible, we should ensure that they find it as easy as possible to
automate procedures thereafter.
2.1.1 We should aim that *everyone* finds the software easy to
use. Even "experts" could save time and make fewer mistakes.
I've long argued that Solaris gives a very poor first impression - to
administrators who have to fight past the first install, to users who
get a limited (but improving) environment, to developers whose initial
impression is always one of sloth.
I like the damning indictment, but would make a minor change: Solaris
*interactive* installation is ugly, slow, and difficult. (All Solaris
installations are much slower than they ought to be, but the automated
tools such as jumpstart do have some strengths.)
To be honest, my own experience of the interactive install has been
limited. I have done a couple in the last year, and while it's vastly
inferior to jumpstart, I managed to get it right without problems - and
it wasn't all that much worse than RedHat or FreeBSD.
The two biggest problems *I* have with the install:
1. How abysmally painfully slow it is. More on that later...
2. The software selection system is useless.
Software selection: the fundamental problem is that there are far too
many packages. (Note that the notion of package here does not imply the
SVR4 packaging system - I'm simply using a package as a related group
of files, and a cluster as a related group of packages.) The way the
product is split up into packages and clusters has no relevance to the
end user whatsoever.
For example, (talking about sparc - similar logic applies to x86)
common network drivers such as bge, eri, ce; the fibre channel stack;
fault management; basic graphics drivers; SVM itself; PCI drivers;
picl; should be removed as separate packages and moved into the core
solaris packages. Essentially, any machine up to (say) a V890 should be
installable with the SUNWCcs cluster and run. This saves a lot of
possible choices, makes it more likely that drivers will be already
installed, and removes the urge for administrators to tinker.
I'm sure you could go through the other packages and amalgamate
extensively. I see no justification for my machine to have 1371
distinct packages installed - how can anyone make sense of that?
Then the metaclusters don't make sense. I now start with SUNWCall and
start hacking. What I *want* to do is start with SUNWCcs and start
adding to it, in meaningful chunks. So there should be many more
metaclusters. For example, there should be a JDS metacluster - which
contains all the JDS packages and their dependencies. And an X11
metacluster. And a CDE metacluster. Metaclusters can include other
clusters and metaclusters, and can overlap. I can imagine a developer
metacluster. And a web server cluster. A file server cluster. A mail
server cluster. A SAMP cluster - any number of application-specific
clusters that would make sense in the SMB space (or for
appliances). All metaclusters are complete and self contained - so you
never need to do dependency checks. And you build up - the full install
is simply all metaclusters. Removing a metacluster doesn't remove all
its packages - those packages referenced by other metaclusters (because
they're needed as dependencies) are still included.
The cluster/metacluster definitions should exist throughout the
packages management system, so that I can come along later and add the
printing and fileserver clusters if I wish.
2.1.4 Upgrade.
I recently upgraded several S10 FCS systems to S10U1 simply by sticking
the DVD in the drive, and it was a relatively simple - if slow -
process. My systems worked correctly afterwards, which wasn't the case
many years ago.
Live upgrade is an interesting problem. It's not helped by the fact
that Sun sell many systems (even high-end ones) with small numbers of
disk drives. While I've used it, it wasn't a pleasant experience. (Its
habit of calling sync every few seconds was a killer on one production
system I tried it on.) Still, Live Upgrade should be a compelling
feature - and using zfs snapshots to manage BEs solves many problems
(no need to copy, or allocate space up front).
2.1.7
I can't understand the lukewarm comparison of Solaris install
performance with others. "It's the perception that we're slower." It's
not a perception: -it's reality. And the gap is *huge*. Experience in
the late S9/S10 beta timeframe was that Solaris is slower than (say)
RedHat by a factor 5-10.
I tested the "go-faster" package tools in S10 beta. Given that
comparison with alternative systems indicates that there is a potential
for a factor 5-10 improvement, and comparing many of the pkg* tools
with emulations using shell tools indicates a similar deficiency, the
fact that there was no significant improvement - and in many cases a
significant regression - was a huge disappointment.
Of course, if Solaris was better packaged into a smaller number of
packages, this would also have benefits.
There is another performance bottleneck, which is the SMF manifest
import. This needs to be sped up or eliminated.
2.2.1
Saving jumpstart - not only from an interactive installation -
ideally the install choices would be saved as a jumpstart profile (and
sysidcfg file) to a standard location, but also from an installed
system, so that you can go to a system, and generate a jumpstart
profile and sysidcfg file that would reproduce that system.
Section 3 - Requirements.
20. Or select an alternative nameservice. On the same screen as the
account set up, have an extra entry with a check box "use a network
nameservice for accounts" and a dropdown of NIS/NIS+/LDAP. It may even
be possible to guess. I don't see any nameservice integration mentioned
- it's a crucial component.
29. Absolutely. But this isn't an installation issue so much as
ensuring that the appropriate subsets (metaclusters) are independent of
the underlying OS version.
Section 4 - Caiman
(Let's hope that Caiman doesn't inherit Anacaonda's propensity for
crashing.)
Perhaps the Solaris best practices should be made availabele and
pointed to - are they correct and still relevant?
4.1.1
I talked about metaclusters above. I'm unsure whether a choice of the
entire Solaris release is sensible. What services are enabled or
disabled? Is it advantageous to discriminate based on system type (if
graphical install desktop...)?
--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 6:40 AM
in response to: ptribble
|
|
>2.1.7
>
>I can't understand the lukewarm comparison of Solaris install
>performance with others. "It's the perception that we're slower." It's
>not a perception: -it's reality. And the gap is *huge*. Experience in
>the late S9/S10 beta timeframe was that Solaris is slower than (say)
>RedHat by a factor 5-10.
>
>I tested the "go-faster" package tools in S10 beta. Given that
>comparison with alternative systems indicates that there is a potential
>for a factor 5-10 improvement, and comparing many of the pkg* tools
>with emulations using shell tools indicates a similar deficiency, the
>fact that there was no significant improvement - and in many cases a
>significant regression - was a huge disappointment.
>
>Of course, if Solaris was better packaged into a smaller number of
>packages, this would also have benefits.
The package database flatfile is a serious obstacle to performance.
The file is big and is written to disk one or more times for each
package installation. (And flushed to stable storage and then renamed)
The package database I/O alone accounts for 70+% (i.e., the vast majority!)
or all I/O done during an upgrade or install.
For upgrades, this gets even worse in the presence of unbundled stuff.
The experiment I did consisted of keeping the database in memory
and writing a delta log to the filesystem while "mock package tools"
would perform all updates by calling the particular daemon.
The difference, of course, was between seconds to minutes and
more than an hour (depending on speed of disk, etc). Note that some of
this was on ATA disks with write caches enabled with seriously
increase performance at the cost of reliability.
I think such an implementation is possible without rewriting the package
interfaces and just do the magic under the hood.
The contents file database server I wrote was special purpose; it
has a limited memory footprint (about twice the database).
The one you referred to which was tested in S10 beta was SQL based and
tool about 10 times as much memory (I've witnessed installs on 512
MB systems lasting many additional hours because of the database server
was paging like mad)
After rewriting the contents file backend (too much seems to depend on
the file being there for now), things should be a lot better.
Other low hanging fruits are:
- use of gzip vs bzip2
bzip2 is *so* slow that it actually is a performance bottleneck even on
fast machines; gzip compresses about 10% less but allows you to read data
at DVD speeds; bzip2 does not.
That brings on the issue of DVD installs and lack of streaming; our install
should be able to stream the data; but currently we're hampered by the fact
that the packages are presented in somecases in many small files which make
DVD reading very slow.
>There is another performance bottleneck, which is the SMF manifest
>import. This needs to be sped up or eliminated.
The SMF manifest import situation has somewhat improved in b3x; after
upgrading a later snv build you'll see only the really changed manifests
be reimported rather than all manifest. (b35->b36, e.g., imports something
like 6-10 manifests and not the 100+ you got when going from any build
before s31 to a later build)
This isn't to say that manifest import is not slow. The current
mechanism parses the manifest in svccfg and then hands it to the server
with many door calls; a single door call "here's the parsed manifest,
eat it" which likely fix that handsomly. It is something which needs
fixing.
Casper
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,575
From:
GB
Registered:
4/27/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 1:47 PM
in response to: casper
|
|
On Fri, 2006-03-24 at 14:40, Casper.***@Sun.COM wrote:
> The package database flatfile is a serious obstacle to performance.
>
> The file is big and is written to disk one or more times for each
> package installation. (And flushed to stable storage and then renamed)
Yes, absolutely. Another way to speed this up would be not to commit
changes with every package, but just roll up all the changes and write
it once at the end. This batching approach would help patches as well -
which are just pkgadds of bits of packages, sometimes involving lots
of packages. It's not just perfomance - minimising the time between
installation or patch start and end reduces the risk of corruption due
to system failure while in the middle of the process.
If I (at the risk of sounding like a broken record) go back to clusters
and metaclusters, then imagine clusteradd operating on clusters as first
class objects - so it installs the whole lot in a single operation
(rather
like a single pkgadd of all the combined packages), and only updates the
contents file once.
> Other low hanging fruits are:
>
> - use of gzip vs bzip2
>
> bzip2 is *so* slow that it actually is a performance bottleneck even on
> fast machines; gzip compresses about 10% less but allows you to read data
> at DVD speeds; bzip2 does not.
Yes. I meant to mention that.
Just to illustrate, my W2100z takes 60s to bzcat the SUNWsom archive; if
I
convert it to gzip then gzcat takes 6s - a factor 10 improvement.
--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 25, 2006 12:57 AM
in response to: ptribble
|
|
>If I (at the risk of sounding like a broken record) go back to clusters
>and metaclusters, then imagine clusteradd operating on clusters as first
>class objects - so it installs the whole lot in a single operation
>(rather
>like a single pkgadd of all the combined packages), and only updates the
>contents file once.
I'd much prefer it if we could optimize the operation so that:
pkgadd p1
pkgadd p2
pkgadd p3
is speeded up as much as
pkgadd p1 p2 p3
as that gives the same gain without having to retool everything around it.
Casper
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
165
From:
US
Registered:
6/14/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 26, 2006 4:29 AM
in response to: casper
|
|
>
> >If I (at the risk of sounding like a broken record)
> go back to clusters
> >and metaclusters, then imagine clusteradd operating
> on clusters as first
> >class objects - so it installs the whole lot in a
> single operation
> >(rather
> >like a single pkgadd of all the combined packages),
> and only updates the
> >contents file once.
>
> I'd much prefer it if we could optimize the operation
> so that:
>
> pkgadd p1
> pkgadd p2
> pkgadd p3
>
> is speeded up as much as
>
> pkgadd p1 p2 p3
>
> as that gives the same gain without having to retool
> everything around it.
"pkgadd p1 p2 p3" operation for Solaris has been implemented by TWW's HPMS for Solaris.
Even auto installation for chain of package dependency that exist in other OS (like HP-UX's SD-UX) is avaiable for Solaris already.
tj
> Casper
> _______________________________________________
> install-discuss mailing list
> install-discuss at opensolaris dot org
> http://opensolaris.org/mailman/listinfo/install-discus
> s
>
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 26, 2006 5:29 AM
in response to: tjyang
|
|
>>
>> >If I (at the risk of sounding like a broken record)
>> go back to clusters
>> >and metaclusters, then imagine clusteradd operating
>> on clusters as first
>> >class objects - so it installs the whole lot in a
>> single operation
>> >(rather
>> >like a single pkgadd of all the combined packages),
>> and only updates the
>> >contents file once.
>>
>> I'd much prefer it if we could optimize the operation
>> so that:
>>
>> pkgadd p1
>> pkgadd p2
>> pkgadd p3
>>
>> is speeded up as much as
>>
>> pkgadd p1 p2 p3
>>
>> as that gives the same gain without having to retool
>> everything around it.
>
>"pkgadd p1 p2 p3" operation for Solaris has been implemented by TWW's HPMS for Solaris.
That's not what I was talking about: the pkgadd operation for multiple
packages is already defined; I just want to point out that any performance
work needs to optimize for the serial pkgadd case and not just the
parallel (multiple packages added at once) case because I wouldn't want
the optimization to depend on retooling all the tools that now perform
serial package add (patch tools, upgrade, install)
>Even auto installation for chain of package dependency that exist in other OS (like HP-UX's SD-UX
) is avaiable for Solaris already.
But does it use "pkgadd" and the Solaris native package database?
Casper
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 27, 2006 12:10 PM
in response to: casper
|
|
Casper.***@sun.com wrote:
...
> That's not what I was talking about: the pkgadd operation for multiple
> packages is already defined; I just want to point out that any performance
> work needs to optimize for the serial pkgadd case and not just the
> parallel (multiple packages added at once) case because I wouldn't want
> the optimization to depend on retooling all the tools that now perform
> serial package add (patch tools, upgrade, install)
>
Agreed. My response to the entire thread about pkgadd performance is
that, yes, it's a problem. And since the sources are open now, the
members of this community have the opportunity to contribute to
improving it!
I think there are a number of creative ideas, ideally people would
prototype a few and we can have a runoff and merge to get the results
we'd all like.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
326
From:
DE
Registered:
4/28/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 7:28 AM
in response to: ptribble
|
|
Peter Tribble writes:
> I'm sure you could go through the other packages and amalgamate
> extensively. I see no justification for my machine to have 1371
> distinct packages installed - how can anyone make sense of that?
I don't like this part: just keep the exiting packages as is (which makes
it possible to remove stuff you really don't need/want, e.g. on
appliance-type machines where the installation footprint is important, as
well as on minimized special-purpose machines like a KDC), but turn
clusters and metaclusters into first-class citizens throughout the
packaging system, not only visible during installation. I've filed RFEs
about this in the S10 PlatBeta timeframe.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,575
From:
GB
Registered:
4/27/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 24, 2006 8:38 AM
in response to: rorth
|
|
On Fri, 2006-03-24 at 15:28, Rainer Orth wrote:
> Peter Tribble writes:
>
> > I'm sure you could go through the other packages and amalgamate
> > extensively. I see no justification for my machine to have 1371
> > distinct packages installed - how can anyone make sense of that?
>
> I don't like this part: just keep the exiting packages as is (which makes
> it possible to remove stuff you really don't need/want, e.g. on
> appliance-type machines where the installation footprint is important, as
> well as on minimized special-purpose machines like a KDC)
It was my intention that reducing the number of packages would
make minimization easier. It should certainly reduce the dependency
problem, and the new package structure should be along more
meaningful boundaries. It's not *just* lumping them all together.
Does splitting gnome into over 200 packages help anybody? Or
CDE into over 20? Many other packages deliver 1 or 2 files,
and the package overhead is significant.
Besides, if you want to get down to individual files you can do
that as well. For example, I use removef to get rid of /usr/ucb/cc.
(It's a shame this isn't persistent across updates.)
Is the package the correct fundamental unit of granularity?
--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 27, 2006 10:05 AM
in response to: ptribble
|
|
Peter Tribble wrote:
...
> First thoughts:
>
> Section 2
>
> Audience - you're looking at the SMB/Developer segment, and the
> enterprise segment. This ignores another important class, specifically
> the lone user. (Some use the term "hobbyist", but I want to avoid that.)
> The lone user may have the opportunity to play with Solaris - either
> installing it themselves, or using a system installed by a friend or
> colleague. This class of user may well become a developer or customer
> later, and carries their experience with them. They have less
> experience and knowledge, less motivation, and much lower tolerance
> than developers.
>
We were positing that what you term a hobbyist is a developer for our
purposes, but perhaps that's lumping them too coarsely. We'll consider
it, though I'm not sure how much difference it would actually make in
the requirements and recommendations - if you see places where it would,
I'd appreciate you pointing them out.
>
> 2.1 You say that the scale of operations is not necessarily large
> enough to justify complex automation techniques, yet I would argue that
> (a) automation shouldn't be complex, and (b) automation is justifiable
> even for single-system setups (think recovery). In other words, while
> they would not initially have an environment in which automation were
> possible, we should ensure that they find it as easy as possible to
> automate procedures thereafter.
>
Good points.
>
> 2.1.1 We should aim that *everyone* finds the software easy to
> use. Even "experts" could save time and make fewer mistakes.
>
Agreed, there's every intention that it'll be easier, faster, and less
error-prone for everyone.
...
> The two biggest problems *I* have with the install:
>
> 1. How abysmally painfully slow it is. More on that later...
>
> 2. The software selection system is useless.
>
> Software selection: the fundamental problem is that there are far too
> many packages. (Note that the notion of package here does not imply the
> SVR4 packaging system - I'm simply using a package as a related group
> of files, and a cluster as a related group of packages.) The way the
> product is split up into packages and clusters has no relevance to the
> end user whatsoever.
>
I've taken a fairly weak position on the granularity, because there are
reasons for fine-grained packages, and Solaris isn't particularly unique
in this respect - it seems common in the Linux and BSD realms, too. The
relevance of what's presented to users is the principal issue that I
think this strategy can address, and I agree with your high-level point
that the clusters and other grouping elements need to become first-class
objects within the software maintenance system.
...
>
>
> 2.1.7
>
> I can't understand the lukewarm comparison of Solaris install
> performance with others. "It's the perception that we're slower." It's
> not a perception: -it's reality. And the gap is *huge*. Experience in
> the late S9/S10 beta timeframe was that Solaris is slower than (say)
> RedHat by a factor 5-10.
>
Since we haven't run controlled comparisons to generate objective
numbers, I didn't feel it was justifiable to make too much of anecdotal
data. We will be running those comparisons and baselines to establish
performance objectives.
...
>
> 2.2.1
>
> Saving jumpstart - not only from an interactive installation -
> ideally the install choices would be saved as a jumpstart profile (and
> sysidcfg file) to a standard location, but also from an installed
> system, so that you can go to a system, and generate a jumpstart
> profile and sysidcfg file that would reproduce that system.
>
Agreed.
>
> Section 3 - Requirements.
>
> 20. Or select an alternative nameservice. On the same screen as the
> account set up, have an extra entry with a check box "use a network
> nameservice for accounts" and a dropdown of NIS/NIS+/LDAP. It may even
> be possible to guess. I don't see any nameservice integration mentioned
> - it's a crucial component.
>
Good point.
> 29. Absolutely. But this isn't an installation issue so much as
> ensuring that the appropriate subsets (metaclusters) are independent of
> the underlying OS version.
>
>
> Section 4 - Caiman
>
> (Let's hope that Caiman doesn't inherit Anacaonda's propensity for
> crashing.)
>
We'll apply our usual quality standards, so I assume not.
> Perhaps the Solaris best practices should be made availabele and
> pointed to - are they correct and still relevant?
>
Where they exist, they're usually published under the blueprints
program. We have a number of other recommendations that we've never
formalized, as well. I'm not sure whether we'll have a lot of resources
to put into this, but it's one thing I think the sysadmin community
might be able to help out with here.
> 4.1.1
>
> I talked about metaclusters above. I'm unsure whether a choice of the
> entire Solaris release is sensible. What services are enabled or
> disabled? Is it advantageous to discriminate based on system type (if
> graphical install desktop...)?
>
I think on an advanced path we can offer all sorts of alternatives. But
I really want the main path to be a streamlined, get you running as
quickly as possible, experience. As a first approximation, I think the
whole release is reasonable and avoids some of the sticky software
management problems. As we get those improved, then a cut-down default
might be more feasible.
Thanks for the feedback, Peter!
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,674
From:
Registered:
7/15/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 27, 2006 7:00 AM
in response to: dminer
|
|
Excellent document; the author has nailed it.
However, if I may add two things, which concern me regarding the document:
1. with an increased acceptance of Solaris, I believe that automated installs in the form of flash + JumpStart combination will become the preferred way to install; this combination is already a defacto standard in large enterprises that already have the necessary Solaris expertise.
However, one weak point of this approach remains to be the DHCP and PXE. While DHCP installations provide a platform independent booting environment on both SPARC and i86pc (via PXE), it is currently very painful to implement a DHCP server properly.
I've been working with Solaris for more than ten years now, most of which were spent as either a sysadmin or as a system engineer, and I feel that DHCP server which supports booting / installation via JumpStart is very difficult to properly configure; furthermore, it is overly complicated.
May I therefore suggest to the author of the paper, to revisit the DHCP problem?
2. and I quote:
"Unlike the existing Solaris installer, the user will not be asked to select slices and mount
points for a more detailed filesystem layout. This is because the default installation will use
ZFS pools and filesystems to construct the basic filesystem layout. Advanced user options
will allow the continued use of UFS as the installation filesystem for those customers who
require it, but our direction is to de-emphasize this legacy technology. The usage of ZFS as
the default filesystem simplifies our ability to offer safe patching and upgrades with
rollback, and will allow for faster provisioning of zones."
Exactly this has been my concern throughout the author's essay: while I agree that Solaris will benefit from an easier installer, I suggest that there are also "Advanced" buttons for system administrators which enable one to configure the installation exactly as one sees fit, i.e.:
I don't want the installer being "smart" and deciding for me how many ZFS pools or which FileSystems to configure on top of ZFS; same goes for UFS FileSystems. What I do want and need is very fine grained control over that. I feel that this is critical for an advanced installation.
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 27, 2006 3:10 PM
in response to: ux-admin
|
|
UNIX admin wrote:
> Excellent document; the author has nailed it.
>
Thank you!
> However, if I may add two things, which concern me regarding the
> document:
>
> 1. with an increased acceptance of Solaris, I believe that automated
> installs in the form of flash + JumpStart combination will become the
> preferred way to install; this combination is already a defacto
> standard in large enterprises that already have the necessary Solaris
> expertise.
>
> However, one weak point of this approach remains to be the DHCP and
> PXE. While DHCP installations provide a platform independent booting
> environment on both SPARC and i86pc (via PXE), it is currently very
> painful to implement a DHCP server properly.
>
> I've been working with Solaris for more than ten years now, most of
> which were spent as either a sysadmin or as a system engineer, and I
> feel that DHCP server which supports booting / installation via
> JumpStart is very difficult to properly configure; furthermore, it is
> overly complicated.
>
> May I therefore suggest to the author of the paper, to revisit the
> DHCP problem?
>
I agree that it's overly complicated, the reasons why aren't
particularly relevant to share anymore, and I'm guilty of not having
taken more action to fix it, since it's an area where I have had at
least partial responsibility for a while.
Addressing this is probably a combination of:
- introduce GRUB on SPARC to reduce the reliance on DHCP vendor options
- modify the default DHCP server setup so that the basic things you do
need defined are there to begin with and it's just site-specific work
that's needed
- replace add_install_client and so on with tools that do a complete job
of configuring installation service
But I'm certainly interested in additional ideas.
>
> 2. and I quote:
>
> "Unlike the existing Solaris installer, the user will not be asked to
> select slices and mount points for a more detailed filesystem layout.
> This is because the default installation will use ZFS pools and
> filesystems to construct the basic filesystem layout. Advanced user
> options will allow the continued use of UFS as the installation
> filesystem for those customers who require it, but our direction is
> to de-emphasize this legacy technology. The usage of ZFS as the
> default filesystem simplifies our ability to offer safe patching and
> upgrades with rollback, and will allow for faster provisioning of
> zones."
>
> Exactly this has been my concern throughout the author's essay: while
> I agree that Solaris will benefit from an easier installer, I suggest
> that there are also "Advanced" buttons for system administrators
> which enable one to configure the installation exactly as one sees
> fit, i.e.:
>
> I don't want the installer being "smart" and deciding for me how many
> ZFS pools or which FileSystems to configure on top of ZFS; same goes
> for UFS FileSystems. What I do want and need is very fine grained
> control over that. I feel that this is critical for an advanced
> installation.
There's no intention to prevent you from having that fine-grained
control on the advanced installation path, I'll certainly make that more
clear in the next iteration. As we move into design of that path, we'll
certainly be looking for help in defining what capabilities are required.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
326
From:
DE
Registered:
4/28/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 27, 2006 3:22 PM
in response to: dminer
|
|
Dave Miner <Dave dot Miner at Sun dot COM> writes:
> Addressing this is probably a combination of:
>
> - introduce GRUB on SPARC to reduce the reliance on DHCP vendor options
Please don't: the current GRUB setup (having to edit/modify menu.lst for
each client) is a nightmare compared to the SPARC/pre-NewBoot way of having
vendor options to control settings. While this may be convenient for a
single system, it becomes very tedious when having to maintain large
numbers of systems
> - modify the default DHCP server setup so that the basic things you do
> need defined are there to begin with and it's just site-specific work
> that's needed
> - replace add_install_client and so on with tools that do a complete job
> of configuring installation service
>
> But I'm certainly interested in additional ideas.
As I think I mentioned before, JET has a plugin framework to handle this,
currently with a Sun DHCP module and and an ISC module in the works.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 28, 2006 7:49 AM
in response to: rorth
|
|
Rainer Orth wrote:
> Dave Miner <Dave dot Miner at Sun dot COM> writes:
>
>> Addressing this is probably a combination of:
>>
>> - introduce GRUB on SPARC to reduce the reliance on DHCP vendor options
>
> Please don't: the current GRUB setup (having to edit/modify menu.lst for
> each client) is a nightmare compared to the SPARC/pre-NewBoot way of having
> vendor options to control settings. While this may be convenient for a
> single system, it becomes very tedious when having to maintain large
> numbers of systems
>
The reasons to make the move on SPARC are relatively strong, and what
you're pointing out is a deficiency in x86 that we should be looking to
correct.
>> - modify the default DHCP server setup so that the basic things you do
>> need defined are there to begin with and it's just site-specific work
>> that's needed
>> - replace add_install_client and so on with tools that do a complete job
>> of configuring installation service
>>
>> But I'm certainly interested in additional ideas.
>
> As I think I mentioned before, JET has a plugin framework to handle this,
> currently with a Sun DHCP module and and an ISC module in the works.
>
JET has its good points, and will certainly be considered as a
contributor to tools we might use to replace the existing ones.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
326
From:
DE
Registered:
4/28/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 28, 2006 8:00 AM
in response to: dminer
|
|
Dave Miner writes:
> >> Addressing this is probably a combination of:
> >>
> >> - introduce GRUB on SPARC to reduce the reliance on DHCP vendor options
> >
> > Please don't: the current GRUB setup (having to edit/modify menu.lst for
> > each client) is a nightmare compared to the SPARC/pre-NewBoot way of having
> > vendor options to control settings. While this may be convenient for a
> > single system, it becomes very tedious when having to maintain large
> > numbers of systems
>
> The reasons to make the move on SPARC are relatively strong, and what
> you're pointing out is a deficiency in x86 that we should be looking to
> correct.
re-reading my mail, I see that it can be misunderstood: I don't oppose the
move to GRUB on SPARC, although it has its tedious points and the boot
archives introduce several new failure modes not seen before. If I recall
correctly from Jan Setje-Eilers' NewBoot presentation during the S10
PlatBeta final meeting, the move is motivated both by the need for ZFS boot
on SPARC and a simplification of the kernel <-> OBP interaction.
I'm only strongly opposed to the switch from DHCP vendor options to the
exclusive use of menu.lst, which is hardly a scalable/centrally
maintainable interface. Btw., per-host sysidcfg files have exactly the
same problem ;-( If we can retain (at least as an option) the ability to
use vendor options to configure the boot/installation even with GRUB,
that's fine with me.
Rainer
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Mar 28, 2006 8:08 AM
in response to: rorth
|
|
Rainer Orth wrote:
...
>
> re-reading my mail, I see that it can be misunderstood: I don't oppose the
> move to GRUB on SPARC, although it has its tedious points and the boot
> archives introduce several new failure modes not seen before. If I recall
> correctly from Jan Setje-Eilers' NewBoot presentation during the S10
> PlatBeta final meeting, the move is motivated both by the need for ZFS boot
> on SPARC and a simplification of the kernel <-> OBP interaction.
>
> I'm only strongly opposed to the switch from DHCP vendor options to the
> exclusive use of menu.lst, which is hardly a scalable/centrally
> maintainable interface. Btw., per-host sysidcfg files have exactly the
> same problem ;-( If we can retain (at least as an option) the ability to
> use vendor options to configure the boot/installation even with GRUB,
> that's fine with me.
>
Thanks for clarifying, Rainer, I kind of thought that was what you were
really after. We'll be having some discussions about SPARC in the next
week and I'll make sure we include your issue.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,674
From:
Registered:
7/15/05
|
|
|
|
Re: Solaris installation strategy
Posted:
Mar 29, 2006 11:46 PM
in response to: dminer
|
|
A few more points to bring up, as per discussion with Dave (quick summary):
(this concerns DHCP / JumpStart references in Dave's paper)
a) configuring the DHCP server to supply booting and installation information for a JumpStart(TM) Flash(TM) should be easy and painless
b) the DHCP server should be capable of supplying enough information to have IPMP automatically configured after the flash
c) the tools to manipulate the DHCP server for these tasks should not make it harder to configure the DHCP server to do b) afterwards
d) as an option, the tools provided for a) and b) could be extended to also encompass / make c) easier.
|
|
|
|
|
Posts:
8
From:
Registered:
4/3/06
|
|
|
|
Re: Solaris installation strategy
Posted:
Apr 3, 2006 7:27 AM
in response to: dminer
|
|
Hi, thanks for posting this. I was impressed with the PDF content -
very good work.
The rest of this post is a bunch of semi-random thoughts and ideas,
some trivial and some would be major long-term projects. Please view
this as a collection of ideas that I think might be interesting or
useful, not a list of demands.
*) In general, I really like the idea of the Live DVD, particularly
the "install without reboot" possibility. However, for people who have
already installed Solaris before and know they want to install it
again, particularly those wanting to install OpenSolaris, one request
I have would be to try to eliminate the requirement for burning DVDs
(or CDs). It seems really lame to have to download an ISO image, then
burn it (hoping it went okay) then boot off it.
For most stand-alone computers though, this is hard to avoid. So my
idea is as follows: make use of bootable USB (and Firewire) devices -
particular CompactFlash cards. That is, a simple boot program could be
downloaded and installed onto such cards (something based on GRUB
perhaps). The main install files would be on the hard disc.
Imagine a person who has just bought a new Windows laptop and wants to
install Solaris/OpenSolaris. The process would go something like this:
1) download a single install file and place it in a fixed location (eg
c:\SOLARIS_INSTALL\ or something), (2) download program which creates
bootable Flash card for current OS (Windows). (3) reboot computer (4)
The Flash card's boot program looks at the hard disc(s) for install
binaries and finds some in c:\SOLARIS_INSTALL\, and gives the user the
option to install from it (and also sort out the partitions if
necessary), (5) install begins.
A similar process could be used for users with just Linux installed.
Obviously such a function would require the Flash card boot program to
be able to read various file system types.
As well as removing the need (and time taken and possibility for
errors) to burn a DVD, this also makes it MUCH easier to do custom
installs, and also to include other software packages. ie in the
c:\SOLARIS_INSTALL\ directory could include a file listing
configuration options. That file could then be used instead of an
interactive installer, making the entire install process automatic.
*) As an side note to the above, being able to install and run Solaris
itself from a USB/Firewire Flash card could be fun for the appliance
market. (Some companies offer "Flash drives" that are basically Flash
with a hard disc form factor and ATA/SATA interface) Eg, for server
blades, instead of having a hot little hard disc, you could have a
cool little Flash card to boot off.
When it was announced that Niagara / UltraSPARC T1 was GPL'd, a
start-up announced that it was going to create a 1 core chip for the
embedded market. Imagine a little embedded system with such a chip,
512MB of main memory and a 2-4GB Flash "drive", and one or two 1 Gb
Ethernet ports. Super low-power, super compact and no moving parts. It
won't be long before cheaper 4GB CF cards cost $100. In a few years
they'll be $25.
*) Above I suggest using a pre-created file to automate installation.
In general about automation, I would say that any complex task that
many people will need to do frequently should be automated as much as
makes sense. After all, that is one of the basics of IT - to save
"costs" (time, reduce errors) by automation. For any sort of
installation automation scripts, there should be a "central" (probably
separate for OpenSolaris and Solaris though) repository of up-to-date
examples for common scenarios.
The availability of installation automation options should also be
made clear in the interactive installer - and they should be hard to
miss as well (not buried in some help sub-menu). It should also be
clear from the website to download install files that automation
options are available. The reason I say this is that it would be a
shame to have a nice useful feature and then people don't realise it
exists.
*) A minor observation on interactive installers: Every one I've seen
separately asks for locale specific information several times - eg
what keyboard, what timezone and what language. Most installers simply
default to assuming everyone is from the US and using US specific
components.
It would be nice to see installers try to smartly guess locale
information from the hardware - or at least make use of previous
selected options. Eg, if someone selects a timezone for the UK, they
probably have a UK keyboard and want a "UK english" locale - such
choices shouldn't be hardwired, but the installer to change the
default offering. This minimises the amount of changes users have to
make when going through the install options. Saves time and increases
the chance of the user making the correct/best selections.
Similarly, when forced to select the type of keyboard, it can be
rather hit and miss - most keyboards don't have their type code
printed on them. So it would be nice to have a way to double
check the keyboard type after selecting one from a list.
*) For the graphical user interface to the interactive install, I
would suggest something like this: have a window with a set of
coloured and labeled tabs on the left. The colouring would be based on
whether information is required (coloured red say), whether changes
may be required (coloured orange), and whether they're okay (coloured
green). The bottom left tab would essentially be "start install". Each
tab would be a stage in the install. This would be in addition to
"next" and "previous" buttons in the main window.
The reason for this being that if *all* you get is next and previous
you can't tell how many stages you have to go through to get to the
end. With the buttons, advanced users can also take short cuts through
the installer in a simple way.
*) It should be relatively simple to create secure (reasonably
locked-down) installs, even with the interactive installer. Maybe this
would better be part of post installation and general configuration -
since confirming that an OS is nicely locked down right now and being
able to fix common issues is a reccuring problem, though secure on
install means less of a window of opportunity for attacks. At a
minimum, "legacy" (ie where there are better/more secure options
available) server software should not be active by default - though
maybe installed by default.
*) Now that Sun's C/C++/Fortran compilers are available for free, it
would be nice if the Sun Studio C/C++ command-line tools (at a
minimum) came with the OS as standard.
*) This is more of a high-level package management comment, while I'm
in the area, as it were: for any package, some nice meta information
to include would be details about support (possibly including links).
For example, the Apache HTTPD package that comes with Solaris should
include some meta information say that it is a *supported* package -
and maybe also reference forums where free support may be available.
For software on the "companion CD", the packages would include
information about it not being supported, but could obviously provide
links which may help.
*) How well can Solaris x86 live with MacOS X on x86?
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Apr 3, 2006 10:52 AM
in response to: c.rijk
|
|
Chris Rijk wrote:
> Hi, thanks for posting this. I was impressed with the PDF content -
> very good work.
>
Thanks!
> The rest of this post is a bunch of semi-random thoughts and ideas,
> some trivial and some would be major long-term projects. Please view
> this as a collection of ideas that I think might be interesting or
> useful, not a list of demands.
>
OK.
>
> *) In general, I really like the idea of the Live DVD, particularly
> the "install without reboot" possibility. However, for people who have
> already installed Solaris before and know they want to install it
> again, particularly those wanting to install OpenSolaris, one request
> I have would be to try to eliminate the requirement for burning DVDs
> (or CDs). It seems really lame to have to download an ISO image, then
> burn it (hoping it went okay) then boot off it.
>
No, you won't have to do that, but I didn't make it very clear in the
version that was published. I'm envisioning that Sun or other vendors
of OpenSolaris-based systems would be able to provide a direct
installation service based off of some of the concepts our WAN install
technology uses. Burning ISO's should be a last resort, actually.
> For most stand-alone computers though, this is hard to avoid. So my
> idea is as follows: make use of bootable USB (and Firewire) devices -
> particular CompactFlash cards. That is, a simple boot program could be
> downloaded and installed onto such cards (something based on GRUB
> perhaps). The main install files would be on the hard disc.
>
> Imagine a person who has just bought a new Windows laptop and wants to
> install Solaris/OpenSolaris. The process would go something like this:
> 1) download a single install file and place it in a fixed location (eg
> c:\SOLARIS_INSTALL\ or something), (2) download program which creates
> bootable Flash card for current OS (Windows). (3) reboot computer (4)
> The Flash card's boot program looks at the hard disc(s) for install
> binaries and finds some in c:\SOLARIS_INSTALL\, and gives the user the
> option to install from it (and also sort out the partitions if
> necessary), (5) install begins.
>
> A similar process could be used for users with just Linux installed.
>
> Obviously such a function would require the Flash card boot program to
> be able to read various file system types.
>
> As well as removing the need (and time taken and possibility for
> errors) to burn a DVD, this also makes it MUCH easier to do custom
> installs, and also to include other software packages. ie in the
> c:\SOLARIS_INSTALL\ directory could include a file listing
> configuration options. That file could then be used instead of an
> interactive installer, making the entire install process automatic.
>
Interesting thoughts. We definitely would like to make it possible to
initiate an install strictly from something like a USB memory stick;
with sufficient hacking around with GRUB you should be able to run a
network install from one right now. Pretty soon the capacities will be
such that I think we'll want to publish directly usable images for that
case.
We'd been kicking around some ideas around using virtual machine
technology to run the install under Windows or Linux as it would be
simpler for us architecturally, but that also has the problem of
requiring the user to have an OS and virtualization platform which can
do that. Being able to grab the install image out of a Windows or other
filesystem would be another possibility.
One of my colleagues suggested the other day that perhaps we should just
skip the whole "coexist in FDISK" problem in the belief that virtual
machine technology will prove to make installing multiple OS's that are
separably bootable a quaint practice. He does have a point, but I'm not
sure it's the right answer within the next couple of years.
>
> *) As an side note to the above, being able to install and run Solaris
> itself from a USB/Firewire Flash card could be fun for the appliance
> market. (Some companies offer "Flash drives" that are basically Flash
> with a hard disc form factor and ATA/SATA interface) Eg, for server
> blades, instead of having a hot little hard disc, you could have a
> cool little Flash card to boot off.
>
> When it was announced that Niagara / UltraSPARC T1 was GPL'd, a
> start-up announced that it was going to create a 1 core chip for the
> embedded market. Imagine a little embedded system with such a chip,
> 512MB of main memory and a 2-4GB Flash "drive", and one or two 1 Gb
> Ethernet ports. Super low-power, super compact and no moving parts. It
> won't be long before cheaper 4GB CF cards cost $100. In a few years
> they'll be $25.
One of our main problems there is how to handle the writable portions,
since the duty cycles for flash drives aren't quite up to hard drive
standards. I think we'll have to do a stronger job of separating
software from configuration and logging to make that a reality. In
principle, though, it's not too different from our suggested diskless
direction, wherein we'd just download and run images in memory. So
perhaps we'll have it almost there, anyway.
>
>
> *) Above I suggest using a pre-created file to automate installation.
> In general about automation, I would say that any complex task that
> many people will need to do frequently should be automated as much as
> makes sense. After all, that is one of the basics of IT - to save
> "costs" (time, reduce errors) by automation. For any sort of
> installation automation scripts, there should be a "central" (probably
> separate for OpenSolaris and Solaris though) repository of up-to-date
> examples for common scenarios.
>
> The availability of installation automation options should also be
> made clear in the interactive installer - and they should be hard to
> miss as well (not buried in some help sub-menu). It should also be
> clear from the website to download install files that automation
> options are available. The reason I say this is that it would be a
> shame to have a nice useful feature and then people don't realise it
> exists.
>
As one of the goals is to have the best automation capabilities, these
are good ideas to help achieve that. Keep an eye out as we proceed on
design, we're going to try to address it.
>
>
> *) A minor observation on interactive installers: Every one I've seen
> separately asks for locale specific information several times - eg
> what keyboard, what timezone and what language. Most installers simply
> default to assuming everyone is from the US and using US specific
> components.
>
> It would be nice to see installers try to smartly guess locale
> information from the hardware - or at least make use of previous
> selected options. Eg, if someone selects a timezone for the UK, they
> probably have a UK keyboard and want a "UK english" locale - such
> choices shouldn't be hardwired, but the installer to change the
> default offering. This minimises the amount of changes users have to
> make when going through the install options. Saves time and increases
> the chance of the user making the correct/best selections.
>
We're working on some things to improve this already, but one problem,
as I understand it, is that a lot of the really cheap keyboards don't
give you any usable type codes so we have to go manual far more often
than we'd like. But leveraging one input to handle others is certainly
a good principle to apply.
> Similarly, when forced to select the type of keyboard, it can be
> rather hit and miss - most keyboards don't have their type code
> printed on them. So it would be nice to have a way to double
> check the keyboard type after selecting one from a list.
>
As I recall, Red Hat (or was it SuSE?) used to have some sort of option
for testing that you'd picked the right layout. I'll make a note to
look into that one.
>
> *) For the graphical user interface to the interactive install, I
> would suggest something like this: have a window with a set of
> coloured and labeled tabs on the left. The colouring would be based on
> whether information is required (coloured red say), whether changes
> may be required (coloured orange), and whether they're okay (coloured
> green). The bottom left tab would essentially be "start install". Each
> tab would be a stage in the install. This would be in addition to
> "next" and "previous" buttons in the main window.
>
> The reason for this being that if *all* you get is next and previous
> you can't tell how many stages you have to go through to get to the
> end. With the buttons, advanced users can also take short cuts through
> the installer in a simple way.
>
My UI designer will probably have some interesting reactions to the
specific suggestions ;-), but yes, your main point that wizards which
don't tell you where you are in the process, and don't provide ways to
move around more gracefully than pressing the back button 20 times, are
unfriendly is a good one. We'll try not to make that mistake.
>
> *) It should be relatively simple to create secure (reasonably
> locked-down) installs, even with the interactive installer. Maybe this
> would better be part of post installation and general configuration -
> since confirming that an OS is nicely locked down right now and being
> able to fix common issues is a reccuring problem, though secure on
> install means less of a window of opportunity for attacks. At a
> minimum, "legacy" (ie where there are better/more secure options
> available) server software should not be active by default - though
> maybe installed by default.
>
This one gets into controversial territory. The hard-core minimizers
argue that any bits that they don't need to run should never even be
installed. We've had a lot of discussion on this topic in recent
months, and at some point I'm going to have to put together a reasonable
story to address it. But yes, we completely agree that locking down
shouldn't be purely an install-time decision, and older, deprecated
services shouldn't be on by default in most cases. You'll start seeing
some movement here in Solaris Nevada really soon now.
>
> *) Now that Sun's C/C++/Fortran compilers are available for free, it
> would be nice if the Sun Studio C/C++ command-line tools (at a
> minimum) came with the OS as standard.
>
Yeah, wouldn't it? Not something I can make a decision about, but it's
a constant topic of conversation.
>
> *) This is more of a high-level package management comment, while I'm
> in the area, as it were: for any package, some nice meta information
> to include would be details about support (possibly including links).
> For example, the Apache HTTPD package that comes with Solaris should
> include some meta information say that it is a *supported* package -
> and maybe also reference forums where free support may be available.
> For software on the "companion CD", the packages would include
> information about it not being supported, but could obviously provide
> links which may help.
>
Yes, tying the package database more directly to the documentation and
support would be a very good enhancement. Noted.
>
> *) How well can Solaris x86 live with MacOS X on x86?
>
Seems like Apple's going out of their way to discourage this, but
perhaps they'll see the error of their ways eventually. I imagine we'll
be in the same situation as Linux here, but I haven't been paying too
close attention to this specific issue. Perhaps someone else can pipe
up if they have any thoughts.
Thanks for all the thoughts, Chris!
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
8
From:
Registered:
4/3/06
|
|
|
|
Re: Re: Solaris installation strategy
Posted:
Apr 4, 2006 4:32 AM
in response to: dminer
|
|
> No, you won't have to do that, but I didn't make it very clear in the
> version that was published. I'm envisioning that Sun or other vendors
> of OpenSolaris-based systems would be able to provide a direct
> installation service based off of some of the concepts our WAN install
> technology uses. Burning ISO's should be a last resort, actually.
Sorry for not giving more context in my original post on this. While WAN install is great in a number of ways (particularly if only the bits needed are downloaded which is nice for those wanting a small install), it has a couple of issues: firstly is the complexity of WAN capable network setup (though I'd guess this can overlap a lot with Solaris networking setup anyway). The other point is that if you want a fast *install time* (ie minimum downtime), then network install is going to be noticibly slower than from local media, in most cases. Obviously some will have fast connections though - but most SMBs and "enthusiasts" (or developers wanting something they can use at home) would have relatively slow networking. My connection at home is actually faster than my one at work, but it still takes a long time to download a full Solaris install. However, at least I can do other things at the same time, which I couldn't for WAN install. Long downloads are also more succeptible to intermittant networking problems.
I hope the above gives some context to why I think it would be worth being able to install from local media that isn't DVD. I'm glad you think "Burning ISO's should be a last resort".
Of course, over time, network connections will get increasingly faster - most likely much faster than Solaris itself grows (though I guess then JES will be added as standard or something ^-^). So WAN install will become more usable over time.
> We'd been kicking around some ideas around using virtual machine
> technology to run the install under Windows or Linux as it would be
> simpler for us architecturally, but that also has the problem of
> requiring the user to have an OS and virtualization platform which can
> do that. Being able to grab the install image out of a Windows or other
> filesystem would be another possibility.
One related idea I had but decided not to mention (due to the implementation effort required) would be to do a basic ZFS port for Windows/Linux/etc (would only need to be single-threaded and only being able to handle one disc would be enough for most users). That way, once a "spare" partition has been created, the basic ZFS port could be used to write the install to it from another OS. However, this would require a completely different installer since Solaris itself wouldn't be running - naturally, the OS virtualisation technique you mention above would get around this and other problems.
> One of my colleagues suggested the other day that perhaps we should just
> skip the whole "coexist in FDISK" problem in the belief that virtual
> machine technology will prove to make installing multiple OS's that are
> separably bootable a quaint practice. He does have a point, but I'm not
> sure it's the right answer within the next couple of years.
In about 18 months, probably more than half of all new x86 systems will have hardware virtualisation built-in to the CPU. I'm not sure how much that helps though compared to current software virtualisation technology.
> One of our main problems there is how to handle the writable portions,
> since the duty cycles for flash drives aren't quite up to hard drive
> standards. I think we'll have to do a stronger job of separating
> software from configuration and logging to make that a reality. In
> principle, though, it's not too different from our suggested diskless
> direction, wherein we'd just download and run images in memory. So
> perhaps we'll have it almost there, anyway.
When you say "duty cycles for flash drives aren't quite up to hard drive standards", do you mean the number of re-writes Flash cells can handle without errors? If I recall correctly, Flash cells can generally handle many billion re-writes on average, and also has support for offlining groups of cells in a similar way to how hard discs handle bad sectors. Sounds like you have looked at this more closely than me though. btw, wouldn't ZFS's copy-on-write help a bit by spreading the writes around...?
> As one of the goals is to have the best automation capabilities, these
> are good ideas to help achieve that. Keep an eye out as we proceed on
> design, we're going to try to address it.
Great! From previous comments, didn't sound like automation was that high a priority. Glad you liked the ideas.
> This one gets into controversial territory. The hard-core minimizers
> argue that any bits that they don't need to run should never even be
> installed. We've had a lot of discussion on this topic in recent
> months, and at some point I'm going to have to put together a reasonable
> story to address it. But yes, we completely agree that locking down
> shouldn't be purely an install-time decision, and older, deprecated
> services shouldn't be on by default in most cases. You'll start seeing
> some movement here in Solaris Nevada really soon now.
Certainly is tricky. And there's no "one size fits all" that's for sure. Maybe an early first question in an interactive installer should be "what is your general attitude towards security?" with options like "I want maximum ease of use", "a reasonable balance" and "paranoid" ^-^ (probably need more technical options). Those high level choices would then influence what's installed/activated, and maybe other things.
As a side-note, how much is being made use of Solaris's Process Rights Management? That's certainly one way to help contain any possible damage. This could be applied to GUI applications as well. Maybe for a next-gen package managament, among the options would be to have "open", "restricted" and "paranoid" (or whatever) security options on install which would affect things like what PRMs are given and so on.
Going even further would be to integrate overall package mangament with security settings for them and things like security alerts. Many security alerts aren't very useful in terms of what sys-admin should do. "Wait for a patch and disable program if possible in the meantime" isn't that handy. For example, if a vulnerability depends on a buffer-overflow attack but you have an UltraSPARC chip or an x86 chip with NX-bit support then such attacks *may* be rendered useless - would be nice to get a security alert from Solaris along the lines of "You have XYZ installed but because you have anti-stack cracking support active, you don't have to worry about this vulnerability". In other cases, the following would be interesting too: "The current application suffers from this security vulnerability. There are no known exploits currently available but it is recommended that you disable this program until a patch is available. If this program is needed, then in the meantime, the following list of PRM setting changes can be made to reduce the scope for damage in case of an attack - see this web-page for more information".
> Seems like Apple's going out of their way to discourage this, but
> perhaps they'll see the error of their ways eventually. I imagine we'll
> be in the same situation as Linux here, but I haven't been paying too
> close attention to this specific issue. Perhaps someone else can pipe
> up if they have any thoughts.
Maybe we need a grass-roots internet campain to persaude Apple that "the customer is always right" - that it would be in their own interest to support multi-booting (or at least not get in the way). I think to many people an Apple laptop with MacOS X and Solaris/Linux installed would be a dream come true.
|
|
|
|
|
Posts:
1,264
From:
US
Registered:
8/5/05
|
|
|
|
Re: Re: Re: Solaris installation strategy
Posted:
Apr 4, 2006 5:14 AM
in response to: c.rijk
|
|
On 4/4/06, Chris Rijk <chris at aceshardware dot com> wrote:
>
> Going even further would be to integrate overall package mangament
> with security settings for them and things like security alerts. Many>
> security alerts aren't very useful in terms of what sys-admin should
> do. "Wait for a patch and disable program if possible in the meantime"
> isn't that handy. For example, if a vulnerability depends on a
> buffer-overflow attack but you have an UltraSPARC chip or an x86
> chip with NX-bit support then such attacks *may* be rendered useless -
> would be nice to get a security alert from Solaris along the lines of "You
> have XYZ installed but because you have anti-stack cracking support
> active, you don't have to worry about this vulnerability". In other cases,
> the following would be interesting too: "The current application suffers
> from this security vulnerability. There are no known exploits currently
> available but it is recommended that you disable this program until a
> patch is available. If this program is needed, then in the meantime, the
> following list of PRM setting changes can be made to reduce the scope
> for damage in case of an attack - see this web-page for more information".
This seems to be going the same direction I was going with "Optional Modules"
I proposed as possibly being useful with fault management.
http://www.opensolaris.org/jive/thread.jspa?forumID=49&threadID=3214
This particular type of "fault management" would really be more of
risk management, which seems to be what predictive self-healing is
all about. In this case, it would be just optional self-diagnosis.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Re: Solaris installation strategy
Posted:
Apr 4, 2006 12:57 PM
in response to: mgerdts
|
|
Mike Gerdts wrote:
> On 4/4/06, Chris Rijk <chris at aceshardware dot com> wrote:
>> Going even further would be to integrate overall package mangament
>> with security settings for them and things like security alerts. Many>
>> security alerts aren't very useful in terms of what sys-admin should
>> do. "Wait for a patch and disable program if possible in the meantime"
>> isn't that handy. For example, if a vulnerability depends on a
>> buffer-overflow attack but you have an UltraSPARC chip or an x86
>> chip with NX-bit support then such attacks *may* be rendered useless -
>> would be nice to get a security alert from Solaris along the lines of "You
>> have XYZ installed but because you have anti-stack cracking support
>> active, you don't have to worry about this vulnerability". In other cases,
>> the following would be interesting too: "The current application suffers
>> from this security vulnerability. There are no known exploits currently
>> available but it is recommended that you disable this program until a
>> patch is available. If this program is needed, then in the meantime, the
>> following list of PRM setting changes can be made to reduce the scope
>> for damage in case of an attack - see this web-page for more information".
>
> This seems to be going the same direction I was going with "Optional Modules"
> I proposed as possibly being useful with fault management.
>
> http://www.opensolaris.org/jive/thread.jspa?forumID=49&threadID=3214
>
> This particular type of "fault management" would really be more of
> risk management, which seems to be what predictive self-healing is
> all about. In this case, it would be just optional self-diagnosis.
>
Yes, we do seem to have a lot of pieces (as is often the case). Putting
them together is really where much of our investment needs to focus.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Re: Solaris installation strategy
Posted:
Apr 4, 2006 12:52 PM
in response to: c.rijk
|
|
Chris Rijk wrote:
>> No, you won't have to do that, but I didn't make it very clear in
>> the version that was published. I'm envisioning that Sun or other
>> vendors of OpenSolaris-based systems would be able to provide a
>> direct installation service based off of some of the concepts our
>> WAN install technology uses. Burning ISO's should be a last resort,
>> actually.
>
> Sorry for not giving more context in my original post on this. While
> WAN install is great in a number of ways (particularly if only the
> bits needed are downloaded which is nice for those wanting a small
> install), it has a couple of issues: firstly is the complexity of WAN
> capable network setup (though I'd guess this can overlap a lot with
> Solaris networking setup anyway). The other point is that if you want
> a fast *install time* (ie minimum downtime), then network install is
> going to be noticibly slower than from local media, in most cases.
> Obviously some will have fast connections though - but most SMBs and
> "enthusiasts" (or developers wanting something they can use at home)
> would have relatively slow networking. My connection at home is
> actually faster than my one at work, but it still takes a long time
> to download a full Solaris install. However, at least I can do other
> things at the same time, which I couldn't for WAN install. Long
> downloads are also more succeptible to intermittant networking
> problems.
>
> I hope the above gives some context to why I think it would be worth
> being able to install from local media that isn't DVD. I'm glad you
> think "Burning ISO's should be a last resort".
>
> Of course, over time, network connections will get increasingly
> faster - most likely much faster than Solaris itself grows (though I
> guess then JES will be added as standard or something ^-^). So WAN
> install will become more usable over time.
>
The usability issues with WAN installation are a priority to fix; our
current support for this is way too hard to set up on the server side.
What I see is that there are tradeoffs to be made by each user. In
section 4.1.8 of the paper, I broke down the performance into three
broad categories, synopses of which were:
1. download & burn media
2. start the installer and provide any inputs
3. lay down the bits and get them running
A Sun-provided WAN installation service minimizes #1, while increasing
#3 (and perhaps #2); overall it should be the fastest option for a
single install, and as WAN speed and reliability increase it seems the
advantage will widen. Avoiding burning also minimizes #1 to some
extent. If you're going to do more than a one-off install, you're
better off creating a cache on the local LAN, so that you optimize #3.
>
>> We'd been kicking around some ideas around using virtual machine
>> technology to run the install under Windows or Linux as it would be
>> simpler for us architecturally, but that also has the problem of
>> requiring the user to have an OS and virtualization platform which
>> can do that. Being able to grab the install image out of a Windows
>> or other filesystem would be another possibility.
>
> One related idea I had but decided not to mention (due to the
> implementation effort required) would be to do a basic ZFS port for
> Windows/Linux/etc (would only need to be single-threaded and only
> being able to handle one disc would be enough for most users). That
> way, once a "spare" partition has been created, the basic ZFS port
> could be used to write the install to it from another OS. However,
> this would require a completely different installer since Solaris
> itself wouldn't be running - naturally, the OS virtualisation
> technique you mention above would get around this and other problems.
>
Yeah, I'll be happy to get the installer running on OpenSolaris - other
platforms are out of scope for now.
>
>
>> One of my colleagues suggested the other day that perhaps we should
>> just skip the whole "coexist in FDISK" problem in the belief that
>> virtual machine technology will prove to make installing multiple
>> OS's that are separably bootable a quaint practice. He does have a
>> point, but I'm not sure it's the right answer within the next
>> couple of years.
>
> In about 18 months, probably more than half of all new x86 systems
> will have hardware virtualisation built-in to the CPU. I'm not sure
> how much that helps though compared to current software
> virtualisation technology.
>
It's a trend which will bear watching.
>
>> One of our main problems there is how to handle the writable
>> portions, since the duty cycles for flash drives aren't quite up to
>> hard drive standards. I think we'll have to do a stronger job of
>> separating software from configuration and logging to make that a
>> reality. In principle, though, it's not too different from our
>> suggested diskless direction, wherein we'd just download and run
>> images in memory. So perhaps we'll have it almost there, anyway.
>
> When you say "duty cycles for flash drives aren't quite up to hard
> drive standards", do you mean the number of re-writes Flash cells can
> handle without errors? If I recall correctly, Flash cells can
> generally handle many billion re-writes on average, and also has
> support for offlining groups of cells in a similar way to how hard
> discs handle bad sectors. Sounds like you have looked at this more
> closely than me though. btw, wouldn't ZFS's copy-on-write help a bit
> by spreading the writes around...?
>
I can't say I've looked at it that closely, my info is secondhand. We
certainly have hot spots in the system which would make me skeptical
that it's a good idea right now. ZFS might help, I guess, though I
don't think it was explicitly designed for this purpose so it's more a
side-effect than intentional, and thus seems likely to not be completely
effective.
>
>> As one of the goals is to have the best automation capabilities,
>> these are good ideas to help achieve that. Keep an eye out as we
>> proceed on design, we're going to try to address it.
>
> Great! From previous comments, didn't sound like automation was that
> high a priority. Glad you liked the ideas.
>
>
>> This one gets into controversial territory. The hard-core
>> minimizers argue that any bits that they don't need to run should
>> never even be installed. We've had a lot of discussion on this
>> topic in recent months, and at some point I'm going to have to put
>> together a reasonable story to address it. But yes, we completely
>> agree that locking down shouldn't be purely an install-time
>> decision, and older, deprecated services shouldn't be on by default
>> in most cases. You'll start seeing some movement here in Solaris
>> Nevada really soon now.
>
> Certainly is tricky. And there's no "one size fits all" that's for
> sure. Maybe an early first question in an interactive installer
> should be "what is your general attitude towards security?" with
> options like "I want maximum ease of use", "a reasonable balance" and
> "paranoid" ^-^ (probably need more technical options). Those high
> level choices would then influence what's installed/activated, and
> maybe other things.
>
Mostly, we want to find a way to not ask questions like that, because
they're either too vague and lead to not really achieving the user's
purpose, or too detailed and the ease-of-use just isn't there. But I'm
sure we'll end with some amount of dialog on some path to let users tune
this.
> As a side-note, how much is being made use of Solaris's Process
> Rights Management? That's certainly one way to help contain any
> possible damage. This could be applied to GUI applications as well.
> Maybe for a next-gen package managament, among the options would be
> to have "open", "restricted" and "paranoid" (or whatever) security
> options on install which would affect things like what PRMs are given
> and so on.
>
Privileges are being used pretty extensively, but there are places we
need to leverage them further.
> Going even further would be to integrate overall package mangament
> with security settings for them and things like security alerts. Many
> security alerts aren't very useful in terms of what sys-admin should
> do. "Wait for a patch and disable program if possible in the
> meantime" isn't that handy. For example, if a vulnerability depends
> on a buffer-overflow attack but you have an UltraSPARC chip or an x86
> chip with NX-bit support then such attacks *may* be rendered useless
> - would be nice to get a security alert from Solaris along the lines
> of "You have XYZ installed but because you have anti-stack cracking
> support active, you don't have to worry about this vulnerability". In
> other cases, the following would be interesting too: "The current
> application suffers from this security vulnerability. There are no
> known exploits currently available but it is recommended that you
> disable this program until a patch is available. If this program is
> needed, then in the meantime, the following list of PRM setting
> changes can be made to reduce the scope for damage in case of an
> attack - see this web-page for more information".
>
I agree, integrating security alerts with the software management tools
would be a good thing to do. Our recent acquisition of Aduva seems to
have brought some technology in this area, though I haven't looked at it
in detail yet.
Dave
_______________________________________________
install-discuss mailing list
install-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/install-discuss
|
|
|
|
|
Posts:
8
From:
Registered:
4/3/06
|
|
|
|
Re: Re: Re: Solaris installation strategy
Posted:
Apr 11, 2006 9:21 AM
in response to: dminer
|
|
Late reply time...
dminer wrote:
>The usability issues with WAN installation are a priority to fix; our
>current support for this is way too hard to set up on the server side.
>
>What I see is that there are tradeo | | | |
