swask - Ask for user responses"
No additional rationale is required under this heading.
The purpose of this utility is to provide support for interactive requirements for software. By being able to execute these interactive scripts independently of swinstall and swconfig, it allows those utilities to still be scheduled for non-interactive execution.The request scripts can be used to ask the administrator questions, or requests, where responses are needed by the software before installation or configuration.
The utility may be used to perform the following task:
- Answer the requests of software that has interactive customization needs.
The swask utility and request scripts are for software specific questions only. It does not provide any mechanism for implementation specific questions, although an implementation can choose to support implementation, site, or system-specific enhancements as normal implementation extensions.
No additional rationale is required under this heading.
No additional rationale is required under this heading.
No additional rationale is required under this heading.
No additional rationale is required under this heading.
This Software Administration specification has not included a naming convention or structure for storing per client response information. If a request script requires per client information, then it needs to store that information for all clients in the response file, and then locate the appropriate information during configuration.This Software Administration specification provides a means for the request script to determine which clients are being requested, and for the configure script to determine that client. See
Control Script Execution and Environment .For example, a request script that requests per client keys is as follows:
- set - $targets echo 'keys="' > response for i in $targets do echo enter key for $i read j echo $i $j >> response done echo '"' >> response
and the corresponding configure script that looks up the correct key from the response file:
- set - $keys while [ -n $1 ] do if [ "$1" = "$targets" ] then echo key is $2 break fi shift; shift; done
An implementation needs to ensure that any response files that already exist in the source or the catalog are copied to the SW_CONTROL_DIRECTORY before the request script is executed. The order of checks for response files allows for the following precedence:
- User input (if ask=true)
- Pre-existing response file
- Pre-existing client configuration
- Model response file (from source)
There are numerous ways to implement where the request scripts are executed and what SW_CONTROL_DIRECTORY is set to, for the command:
- swask -s source -c catalog Foo.Bar
Example implementation A:
- mkdir catalog/Foo/Bar copy request script for Foo.Bar to catalog/Foo/Bar copy any necessary response file to catalog/Foo/Bar if catalog/Foo/Bar/response exists, no action else if source/catalog/Foo/Bar/response exists, copy it set SW_CONTROL_DIRECTORY=catalog/Foo/Bar execute catalog/Foo/Bar/request (remove catalog/Foo/Bar/request)
Example implementation B:
- mkdir catalog/Foo/Bar /usr/tmp/aaaa43542/Foo/Bar copy request script for Foo.Bar to /usr/tmp/aaaa43542/Foo/Bar copy any necessary response file to catalog/Foo/Bar if catalog/Foo/Bar/response exists, no action else if source/catalog/Foo/Bar/response exists, copy it set SW_CONTROL_DIRECTORY=catalog/Foo/Bar execute /usr/tmp/aaaa43542/Foo/Bar/request (remove /usr/tmp/aaaa43542/Foo/Bar)
Example implementation C:
- mkdir /usr/tmp/aaaa43542 copy any necessary response file to /usr/tmp/aaaa43542 catalog/Foo/Bar/response exists, copy it else if source/catalog/Foo/Bar/response exists, copy it set SW_CONTROL_DIRECTORY=/usr/tmp/aaaa43542 execute source/catalog/Foo/Bar/request mkdir catalog/Foo/Bar cp /usr/tmp/aaaa43542/response catalog/Foo/Bar (remove /usr/tmp/aaaa43542)
No additional rationale is required under this heading.
No additional rationale is required under this heading.
Contents | Next section | Index |