On 03/16/11 05:57 AM, Robert Milkowski wrote:
On 03/11/11 10:59 AM, Robert Milkowski wrote:
Hi,
I'm trying to deploy AI for Solaris 11 Express and so far it's been
challenging... I have some questions and I hope someone will be able
to help.
1. disk partitioning on x86
There could be multiple partitions or none - how can I force AI to use
entire disk and put one large Solaris2 partition regardless of how a
disk is currently partitioned? There is such an option for interactive
installs.
2. console on ttya
If post-install scripts are supposed to be delivered via SMF during a
first boot following AI install, how can I put GRUB's menu.lst for the
first boot so I can pass options like console=ttya-...? What if I need
to get information from an external database about how console should
be set-up for a given server? For the AI/install boot it is easy as it
is matter of generating a proper menu.lst for a given server. How can
I do it for the first boot?
Similar issue is with passing specific kernel options on some os/hw
combination due to bugs, etc.
Basically how can I make sure that a customized menu.lst is used
during first boot?
Assuming you are using the same redirection for the console during
installation, that should be carried through correctly to the installed
instance.
User-specified modifications to the menu aren't directly possible right
now.
That would be something although still very limiting...
3. pkg performance
The solaris.zlib downloads at about 100MB/s on a GbE network - good.
However then pkg starts downloading packages and the network
utilizations varies between 0.5MB - 30MBs with an average less than a
couple of MB/s. I guess the sporadic 15-30MB/s occurrences are for
some large files, otherwise the performance is abysmal and it takes
far too long to just transfer packages. Not to mention that entire
process is basically serialized and doesn't make much use of
additional cores on a server. Is there a way for pkg to download
multiple files at the same time? This could probably help a little
bit... It doesn't have to be able to saturate a GbE link but doing
less than 5% is far from being impressive.
4. packages install/uninstall sections
In jumpstart if some packages were marked to be uninstalled there
would never be installed in the first place. Currently AI+pkg installs
all selected packages and then uninstalls packages marked so. Ideally
all packages to be installed and uninstalled should be passed to pkg
at the same time and pkg should come up with the final set of packages
to install.
The uninstall support that's there right now is mostly for dealing with
deficiencies in the way we've been defining group packages. Those are
being resolved and revisiting that to instead provide access to the
recently-
introduced --reject functionality in pkg would be useful.
Good know. Anything that would make it more efficient both in terms of
amount of data transferred over a network and time it takes to install would
be very welcome.
5. tasks
I can see in the install_log entries like "current
task:set_partition_active". Is there a way to add your own tasks?
No.
This is really bad then. As absolute minimum one should be able to decide
which of the provided tasks should run or not and perhaps they should be
customizable as well.
Then to make it even more useful one should be able to run their own tasks.
The tasks that are done in that phase of installation are the things
needed to glue the system together so that it'll boot at all and to
apply the configuration you've expressed in the manifest and
configuration profile. It's constructed and visible in the logs at that
granularity to ease debugging and support of issues easier, but it is
most definitely not suitable in its present incarnation as a hook for
executing customer-supplied customizations.
6. /export/home
How can I prevent it from being created? I don't want to use autofs
for /home directories, nor I want to /export, /export/home,
/export/home/jack to be created. Unconfiguring it during the first
boot via smf is rather silly.
Right now you can't.
Hopefully that would change and rather sooner than later.
More options for specifying ZFS configuration will be available in
future releases. Designs for that have been posted here in the past.
7. root disk mirroring
how can I set-up rpool to be mirrored during installation? Setting it
up post-install during first boot when it will have to resilver
several GBs of data is far from ideal.
Again, right now you cannot.
:(
See above.
8. /etc/system
how can I customize /etc/system before the first boot? This is similar
to #2.
Most direct answer right now would be to republish the kernel package with
your own required /etc/system contents.
That's getting close to tweaking the boot image and making it more flexible
in the first place.
I have the thought that /etc/system entries could be fodder for IPS
actions, but that needs some discussion.
Generally AI needs pre- and post- install scripts additional to first
boot finish scripts via SMF. There seems to be a mechanism for
psot-install sctips already implemented and in use it is just not
exposed to end-users which is a mistake. I don't want some of them to
be running and to have undo their changes during first boot.
We're happy to consider additional functionality in that needs to be
provided
by AI, but generalized user scripting within the installation environment
isn't
up for consideration. You do have the option of building customized boot
images that provide your own post-auto-install services if you wish, but
you
own that image.
What do you mean exactly by that? I mean is there some documentation and
easy way to customize the image (I haven't looked yet) even if I will need
to own it?
It looks like this could be the best and most flexible way after all.
Distribution Constructor, specifically the docs in
http://download.oracle.com/docs/cd/E19963-01/html/820-6564/using.html
Right now I'm evaluating S11 and specifically looking how to integrate it
into the current environment.
To be honest - if it were jumpstart I would have finished setting up a
customized network install long time ago and it would be working for many
years.
Thanks to AI I'm moving from one limitation to another... I'm close to
seriously consider coming up with own scripting which would utilize cpio or
zfs send|recv as it would not only greatly increase the time it takes to
install an OS but also make the entire install as flexible as I want and
much easier to integrate with other OSes and an existing environment. Right
now, apart for very basic *desktop* installations, AI gets more in a way
than it actually solves any real problems. But I'm still trying to be open
minded about AI and want to see how far I can go with it also hoping that it
will improve very soon.
So far from my experience with AI I would very welcome below features in AI
(in no particular order) which would make it actually very usable for me:
1. image based installations
- perhaps one could provide an xml profile with the list of packages
to be installed/uninstalled and some tool would extract all of them from
repo server and store them as one large
signed archive which could be streamed to the system,
even if all pkg actions would have to be executed at the end of it it would
most likely make an installation much faster, right now
it is very slow
Image-based installations are something we have had on the roadmap from
the beginning and intend to provide at some point in the future.
1.1 pkg/pkg.depotd performance - well, this is not really AI but still it
impacts AI performance and for now there is much to be improved here
2. ability to use whole disk by wiping out anything what was on it before
(afaik it's been fixed in later builds, so should be coming soon...?)
3. ability to configure mirrored root disks (again, afaik it's been fixed in
more recent builds...?)
4. ability to set any zpool/dataset properties *before* any data is put into
root pool (again, afaik it's been fixed in more recent builds...?)
- mostly compression, atime
All of the above are in the works.
5. ability to disable/enable AI tasks and perhaps even customize/parametrize
some of them
Having to undo some of their customizations is silly and counter
productive
- ability to customize menu.lst (remove background, change
console=XXX setting, pass additional kernel parameters, etc.)
- ability to customize /etc/system
Noted. If you want to file RFE's, they're welcome.
6. ability to put your own tasks, especially post-install but before first
boot
- the really (not so) funny thing is that since auto_reboot property
could be set to false one can actually execute a post-install script
manually, it is "just" not possible to do it in a fully automated
way, or other option is to remotely (from a script) log-in via ssh
(with livessh=true), monitor when installation finished and again with
auto_reboot=false then execute a post install script
remotely - I'm pretty sure that many people determined enough to
actually deploy S11 in production will end-up doing something along these
lines. IMHO AI team should make it easier for
them and not harder as it won't really accomplish anything good.
The ability to disable automatic reboots is there because some customers
require the ability to verify the installation or make other manual
adjustments prior to booting into the installed instance. Yes, it could
be used to do many other things, including running manual scripts. The
difference is that at this time we are not committing to providing
specifications for a customer-accessible programming environment,
because there are many aspects of the implementation that we are already
changing and considering changing. We may provide such a specification
in the future, but it would be premature right now.
7. disabling/enabling smf services doesn't work entirely, some of them get
re-enabled after lme, looks like this has been fixed in more recent builds
(?)
8. there should be progress displayed on a console, including an option of a
more verbose one (afaik it's planned...?)
Yes, both of these will be addressed in future builds.
9. installadm shouldn't automatically configure and enable tftpd unless ask
to do so, in many environments there are already dedicated tftp servers
The data we have so far is that there are relatively few such
environments, but an RFE will be considered.
10. it should be possible to put /var in a dedicated dataset
/var is a serious hairball whose disposition is being discussed.
11. installadm should use a template name as a suffix to i86pc* directory
name in /tftpboot, same goes for menu.lst.template_name
Changes are being made to how we handle the boot configuration already.
12. backup/mirroring - how one can easily backup and/or replicvat AI
configuration across different servers?
Not easily right now. I expect it would work fine in a cluster, though
I'm guessing that's not your use case. Again, RFE's would be welcome.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
