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
- guaranteed the profile file names are unique
- make them distinguishable from other files that might be written in
the directory accidentally (e.g.:vi backup files from hand-editing)
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
