On 08/ 9/10 09:56 PM, Dave Miner wrote:
General issue 3: This really needs use cases walking through the various tasks
administrators will be performing.
First draft of use cases involving setup and maintenance of SC profiles.
One change from the proposal - subcommand to specify criteria-based SC profiles
is 'set-sc' instead of 'add-sc'.
Use case 1:
- sysadmin has several departments with different system configuration needs
- sysadmin periodically wants to use AI to install systems from different
departments
Solution: criteria-based SC profiles
Procedure:
-- sysadmin identifies criteria that distinguishes target systems
-- sysadmin creates an SC profile with configuration information common to all
departments
-- sysadmin creates different SC profiles for each department that contain configuration properties unique to that department and
also XInclude the common SC profile (just above)
-- sysadmin issues 'installadm create-service' to make the image available for
all departments
-- sysadmin issues 'installadm add-sc' for each department specifying the
distinguishing criteria
Example:
-- dept1 is in subnet 10.0.0.0, dept2 is in subnet 11.0.0.0
-- common_profile.xml - SC properties common to both
-- dept1_profile.xml, dept2_profile.xml - SC properties for specific department
-- os131 is the name of the AI service
installadm create_service -s os131 ... -p common_profile.xml // profile common
to all users of service os131
installadm set_sc -s os131 -o network=10.0.0.0 -p dept1_profile.xml // profile
for department 1
installadm set_sc -s os131 -o network=11.0.0.0 -p dept2_profile.xml // profile
for department 2
Benefits:
-- sysadmin changes only one manifest to effect subsequent installs for entire
department, no matter how the manifest is used
Use case 2:
- site just got 10 new computers
- boxes are inventoried and MAC addresses are learned
- sysadmin wants secret passwords to be automatically installed for each system
Solution: XInclude with custom clients
- sysadmin puts a table of MAC addresses and passwords into an XIncluded file
- sysadmin uses create-client for the MAC addresses and uses the master
XInclude file which:
-- uses the XInclude xpointer attribute to index by MAC address into the table
to fetch the passwords
-- for the rest of the SC manifest, the sysadmin uses an identical SC manifest
create-client -e 0:23:12:59:d6:33 -n <svcname> --profile MAC00231259d633.xml
MAC00231259d633.xml:
<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="profile" name="name" >
<service name="ai_properties" version="1" type="service">
<instance name="default" enabled="true" >
<property_group name="ai" type="application" >
<!--
perform table lookup based on MAC address, provide default if no
password specified for MAC
Note: lookup value must be valid XML name, which requires a
leading alpha, and no ':' permitted
so unfortunately, the MAC as used on the installadm command line
must be converted
-->
<xi:include href="psw.xml" xpointer="element(MAC00231259d633/1)">
<!-- provide a default password if none appears in the table -->
<xi:fallback>
<propval name="rootpass" type="astring"
value="$5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/>
</xi:fallback>
</xi:include>
</instance>
</service>
</service_bundle>
psw.xml: - contains a password entry for each MAC address
<itemlist>
<!-- each item represents a password entry for a particular MAC address -->
<item xml:id="MAC00231259d633">
<propval name="rootpass" type="astring"
value="5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/>
</item>
<item xml:id="some other MAC">
...
</itemlist>
Benefits:
- only one password file is necessary for all install clients
- only sysadmin knows passwords
Disadvantages:
- MAC address as used on installadm command line cannot be used to index with
XPointer
- separate top-level .xml file for each MAC address must be created
Alternative solution to use case 2: leverage template scripting with XInclude
As in the proposal, all criteria will be available in the environment the user-defined script runs in. A very simple Python script
can leverage the Python template module to perform criteria substitutions directly from environment variables:
Python script to leverage templating:
from string import Template
import os
f = open("mytemplate.xml")
x = f.readlines()
for line in x:
print Template(line).safe_substitute(os.environ)
f.close()
mytemplate.xml: assuming that the exported environment variable for CID is
"AI_CID" (note xpointer use on line 7):
<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="profile" name="name" >
<service name="ai_properties" version="1" type="service">
<instance name="default" enabled="true" >
<property_group name="ai" type="application" >
<xi:include href="macpsw.xml" xpointer="element(CID*${AI_CID}*/1)">
<xi:fallback>
<propval name="rootpass" type="astring"
value="$5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/>
</xi:fallback> </xi:include>
<propval name="timezone" type="astring" value="US/Pacific"/>
</property_group>
</instance>
</service>
</service_bundle>
Process:
- sysadmin issues installadm, specifying the custom Python script to generate
the SC profile:
--- installadm create-client -e <MAC> -n <servicename> --command "python
my_template_script.py"
- during execution of installadm, the script:
--- generates a top-level temporary .xml with the custom client's CID
substituted
--- the indexing is done via XInclude and the corresponding password comes from
the table
--- the result is stored in a static SC profile for the client
Advantages:
- only one top-level template will work for all CIDs
Use case 3:
- 10 new computers - same as above, except sysadmin knows how to use Cheetah
and doesn't like clumsy XInclude syntax
Solution: Document template engine - Cheetah
Procedure:
- sysadmin makes spreadsheet - 1 line for each computer - each line is <MAC> <root password>
<user name> <user password> <etc...>
- sysadmin makes an SC manifest template where root password, user name, and
user password are represented as template variables
- sysadmin associates Cheetah SC manifest-generating script with custom client
- installadm create-client calls Cheetah engine, with MAC address as parameter
- Cheetah engine, indexes the spreadsheet by MAC and substitutes in any desired
SC manifest properties
Benefits:
- upon AI, systems have known unique passwords (and any other SC manifest
properties)
- sysadmin only edits the spreadsheet for new systems
- single copy of AI manifest template
- messy, fragile XML syntax of SC manifest avoided
Drawbacks:
- sysadmin must learn Cheetah document engine principles and basics
Use case 4:
- same as for (b), except that the sysadmin is confident with scripting abilities and wants to configure everything, then wait until
the computers arrive and the MAC addresses are known before composing the spreadsheet
Solution: dynamic SC manifest generation with document template engine
Procedure:
- in lieu of custom clients, the custom script uses the MAC address from the environment that generates an SC manifest with specific
passwords for specific systems:
--- installadm create-service --dynamic-command "myscript.py" ...
- when computers arrive, sysadmin updates table with MAC addresses and
distributes computers to installing users
- user runs AI and corresponding SC manifest is generated and used
Benefits:
- sysadmin can configure spreadsheet at the last minute and doesn't need to
re-run installadm
Use case 5:
- sysadmin wants to install OpenSolaris on N virtual boxes using a range of
static IP addresses
- sysadmin wants to dynamically generate passwords that only the sysadmin knows
Solution: install-time user-defined script
Procedure:
- sysadmin composes a standard SC manifest template with a replacement tag for
IP address and root password
- sysadmin writes a script that automatically generates an SC manifest when OpenSolaris is installed. When AI requests the SC
manifest, the script follows this algorithm:
--- finds the last IP address allocated and increments it for the new system
--- generates a password
--- encrypts the password
--- supplies the current IP address and encrypted password as input to Cheetah, which replaces the IP address and encrypted password
according to a SC manifest template
--- writes a private copy of the generated password and IP address to a database
--- outputs the SC manifest with the IP address and encrypted password
Benefits:
- as a result, sysadmin has computers with known passwords and IP addresses
- sysadmin doesn't have to compose IP addresses or passwords or prepare any
tables or configure DHCP
- passwords are securely filed
Drawbacks:
- relies on users' ability to script
- bugs, deficiencies in user script
- failed AI can foil algorithm
Use case 6:
- SC profiles are taken from a package that is specified in the AI manifest
Procedure:
- sysadmin determines the paths that the SC profiles will have during first boot
- sysadmin creates SC profile XInclude-ing those paths
- sysadmin issues installadm command using option for deferring inclusions
until first boot:
--- installadm create-service --first-boot my_includes.xml ...
my_includes.xml: for each path, will contain a line of this format:
<xi:include href="<pathN>" xmlms:xi="http://www.w3.org/2001/XInclude/";>
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
