FYI, I'm making some changes in this area for the zones work.
Firstly, the directory where the profiles are located will be passed in
to auto_install as a paramter:
/usr/bin/auto-install -m manifest -p /profile/dir ...
That directory will be stored as a variable in ApplicationData in the
DOC, and the ApplySysConfig checkpoint will read that. So that path
will no longer be hardcoded in the checkpoint.
Secondly, I'm updating the ApplySysConfig checkpoint to not care what
the names of the files are in the given profile directory. I really
don't see a good reason why it should care. It should just iterate the
given directory and check/treat each file as a profile.
The purpose of allowing abritrary names in the given profile dir is
because we're exposing the "-p /profile/dir" option to zoneadm install.
We're defining the directory to contain one or more profiles of any
name. I don't want to define the interface such that the names of the
files under that directory *must* conform to some naming scheme.
More comments below ....
On 03/25/11 00:41, Karen Tung wrote:
Hi everyone,
Please see my comments inline.
On 03/23/11 06:25 AM, William Schumann wrote:
On 03/23/11 01:22 PM, Darren Kenny wrote:
Hi Ginnie,
On 22/03/2011 16:34, Virginia Wray wrote:
Hi --
Karen and I had a conversation about the ApplySysConfig ICT.
Currently, there is a variable that is set to /var/run/profile and
looks for
files that are profile***.xml. Karen ran into problems when her
file wasn't
located in /var/run/profile and the file didn't fit the naming
standard the ICT was
looking for.
I suppose the main question I would have here is about the name of
the profile -
what does the system configuration SMF service look for?
There can be any number of profile files. SMF expects the files to
appear in the /var/svc/profile/site/ directory on first boot.
Presently, the manifest-locator service (ai_get_manifest.py) is coded
to write any profiles it finds to a work directory, since the new BE
doesn't exist at that point. The work directory is
/system/volatile/profiles/. It generates profile file names to:
- reflect the AI profile name on the AI server for diagnostic purposes
So how is it doing this? By renaming the profiles to profileN.xml as we
get them from the server, we're actually _not_ preserving the names as
they were on the server, right?
- guaranteed the profile file names are unique
This isn't ApplySysConfig's problem, and I don't see why ApplySysConfig
needs to care. The populator of the profile directory needs to
guarantee that. In our given use case here, since manifest-locator is
simply naming the profiles profileN.xml as it gets them, this is already
happening.
- make them distinguishable from other files that might be written in
the directory accidentally (e.g.:vi backup files from hand-editing)
Unlikely a case we have to deal with in the install environment.
thanks,
-ethan
Since the manifest-locator service is not a checkpoint that's run by
the AI application,
it won't have access to the DOC that's used by the ICT checkpoints.
So, the suggestion
to have the names of profiles that the apply_sysconfig_profile ICT
needs to work with
be stored in the DOC won't work.
The apply_sysconfig_profile ICT is coded to pick up only files that
begin with "profile" and end with ".xml" from the work directory, and
write them into /var/svc/profile/site/ in the incipient BE. (This
file naming is only a convention - not documented or externally
exposed.)
Sounds like the manifest-locator service will generate files with
names that's a certain format.
I experimented with changing the name of the profile generated by
the "generate-sc-profile" checkpoint to match the name format
expected by the apply_sysconfig_profile ICT. The installed system is
able
to boot and hostnames and users are configured correctly.
So, I think we are OK to leave the code in apply_sysconfig_profile ICT
that looks
for profiles with the profile*.xml name pattern. However, I think the
filename pattern
should be a constant defined in a common place that all install
components
that generates manifests(eg: manifest-locator, generate-sc-profile
checkpoint)
and the ApplySysConfig() checkpoint should use
so we won't have a name mis-match in the future.
Thanks,
--Karen
Upon first-boot, SMF will take all files in /var/svc/profile/site as
SMF profiles, regardless of the name.
Another detail: if there are no profiles provided by the user, the
current plan is for ICT apply_sysconfig_profile to write a single
profile that will cause SCI tool to be invoked upon first boot.
William
I think we need to be consistent with that the SMF service will
accept on
first-boot, and the ICT should match that behaviour since it's
copying over the
SC profile(s) to the new BE for it to use.
William, can you tell us more about what the SMF service does here?
My suggestion was to have the application add this information to
the DOC
for the ICT to pull and apply. It could be optional, and we could
leave the current
format as a default if nothing is found in the DOC, or the
information in the DOC
could replace the current format.
That's certainly possible, but I feel that if we behave the way that
the SC SMF
service will, we should be alright.
Thanks,
Darren.
Do you guys have any thoughts this?
thanks,
ginnie
-------- Original Message --------
Subject: Re: sys config profile name and the ApplySysConfig()
profile checkpoint
Date: Mon, 21 Mar 2011 10:43:41 -0700
From: Karen Tung<[email protected]>
Reply-To: [email protected]
Organization: Oracle Corporation
To: Virginia Wray<[email protected]>
CC: William Schumann<[email protected]>, Jan Damborsky
<[email protected]>
Hi Ginnie,
Please see my response inline.
On 03/21/11 09:38, Virginia Wray wrote:
Hi -
I incorporated William's changes, so he knows more about the
reason for
using "profile" as a check than I do.
William states that the copy should act only on files that look like
profiles, so
can we define what they look like?
Or could we use the DOC somehow and pull the file(s) (and the
location
from which
to pull it) from there? Could the gen_sc_profile checkpoint put the
name of the profile and
location into the DOC? Then ApplySysConfig could pull the info from
the DOC.
I really like this idea. For the generate-sc-profile checkpoint, I
think the name of
the profile to be generated can be registered into the DOC when we
register that
checkpoint. Will this also work for the cases that you need to
deal with?
Thanks,
--Karen
thanks,
ginnie
On 03/21/11 06:34 AM, William Schumann wrote:
Karen, please find my response at the bottom.
On 03/21/11 09:05 AM, Jan Damborsky wrote:
Hi Karen,
I will let Ginnie clarify that point, as I don't know why.
Pulling also William into the loop, since he is working on enhanced
SC profiles for AI and I assume he will be also using
ApplySysConfig
checkpoint for transferring SC profiles to the target in case of AI
is used
for the installation.
Jan
On 03/19/11 12:46 AM, Karen Tung wrote:
Hi Jan and Ginnie,
I was debugging the problem of not being able to login after
installing and booting the installed system.
Jan helped me figured out that I need to run the ApplySysConfig()
checkpoint which will copy the generated profile to the installed
system.
ApplySysConfig profile looks for the generated profile in the
/var/run/profile directory. However,
the generate-sc-profile checkpoint provided by the SCI tool
project is generating the profile in /tmp. Per Jan's advice,
I changed the generate-sc-profile checkpoint to generate the
profile into the /var/run/profile directory.
When I try my install
again, I found that ApplySysConfig checkpoint still doesn't
copy the generated profile like I expected. After some digging,
I found that's because the ApplySysConfig checkpoint is only
copying profiles of the name "profileNNNN.xml" in
/var/run/profile.
http://indiana-build.us.oracle.com:40000/file/bc731f683a23/usr/src/lib/install_ict/apply_sysconfig.py#l92
The name of the profile generated by the generate-sc-profile
checkpoint
is "sc_manifest.xml". So, there's not a match. Then, I manually
did the copying and everything works!
So, I guess the question is, why does ApplySysConfig checkpoint
only
copy files matching the name 'profileNNNN.xml'?
The idea here is that it will attempt to read only files that look
like profiles. For example, if someone manually modifies a profile
in that directory with vim, vim can create a backup file in the same
directory with a ~ appended to the file name, and we don't want that
backup mistaken for the intended profile. RE: NNNN -
ai_get_manifest.py writes profiles with generated temp filenames
profileNNN.xml to guarantee that the filenames are unique.
So, the pattern I was aiming for was files beginning with 'profile'
and ending with '.xml'.
(If anyone wants, we could drop the "starts with 'profile'"
requirement and just copy '.xml' files.)
Make sense?
William
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
