1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/openpkg/register.pod Tue Jul 31 12:23:42 2012 +0200
1.3 @@ -0,0 +1,358 @@
1.4 +
1.5 +=pod
1.6 +
1.7 +=head1 NAME
1.8 +
1.9 +B<openpkg register> - OpenPKG Registry Command-Line Client
1.10 +
1.11 +=head1 SYNOPSIS
1.12 +
1.13 +B<register> [-u|--user=<user|token>] [-l|--link=<token>] [I<-d|--desc=<text>>]
1.14 + [-m|--mode=fake|post|wipe] [I<-a|--args=<args>>]
1.15 + [I<--plat=<text>>] [I<--orel=<text>>] [I<--uuid=<file>>]
1.16 + [I<--conf=<file>>] [I<--prep=<file>>] [I<--tran=<file>>]
1.17 + [I<--util=<file>>] [--data=<tag>[,<tag>...]]
1.18 + [I<-P|--preparation>] [I<-T|--transaction>]
1.19 + [I<-U|--utilization>] [I<-C|--convenience>]
1.20 + [I<-I|--interaction>]
1.21 + [I<-v|--verbose>] [I<-h|--help>]
1.22 +
1.23 +B<register> -S|--printstatus
1.24 +
1.25 +B<register> -R|--rewriteurls [I<url> ...]
1.26 +
1.27 +=head1 DESCRIPTION
1.28 +
1.29 +B<openpkg register> is the Command-Line Client the OpenPKG Registry. It is
1.30 +used by administrators to register an instance with the OpenPKG Registry for
1.31 +later association.
1.32 +
1.33 +After association, B<openpkg register> can be used for repetitive
1.34 +reregistrations which update the heartbeat of the instance on the Registry
1.35 +server, avoiding premature depature from the database. It is assumed that
1.36 +every instance will be reregistered daily. Dormant
1.37 +instances might be discarded from the Registry, revoking their access to
1.38 +additional resources.
1.39 +
1.40 +=head1 PRIMARY OPERATIONS
1.41 +
1.42 +The following primary operations are available:
1.43 +
1.44 +=over 4
1.45 +
1.46 +=item B<-h>, B<--help>
1.47 +
1.48 +Display brief usage message.
1.49 +
1.50 +=item B<-v>, B<--verbose>
1.51 +
1.52 +Display progress information during data posting.
1.53 +
1.54 +=item B<-P>, B<--preparation>
1.55 +
1.56 +Execute the primary operation "preparation".
1.57 +Creates registry data for one request and dumps it stdout
1.58 +in XML format. That request can be filtered and piped into
1.59 +the transaction phase or it can be copied and pasted into the
1.60 +XMLdump CGI facility manually.
1.61 +A copy of the output of the last run is also saved to the C<${REGISTRY_PREP}> file.
1.62 +
1.63 +=item B<-T>, B<--transaction>
1.64 +
1.65 +Execute the primary operation "transaction".
1.66 +Reads registry data with one request from stdin, executes
1.67 +the transaction and writes registry data with one or more
1.68 +responses to stdout in XML format.
1.69 +Depending on the mode of operation, the transaction might be an actual
1.70 +transport to the XMLdump CGI facility or a fake activity which complements the
1.71 +manual preparation.
1.72 +A copy of the output of the last run is also saved to the C<${REGISTRY_TRAN}> file.
1.73 +
1.74 +=item B<-U>, B<--utilization>
1.75 +
1.76 +Execute the primary operation "utilization".
1.77 +Reads registry data with one response from stdin and updates the local
1.78 +registry information.
1.79 +Depending on the mode of operation, the utilization might be an actual
1.80 +processing of a transaction response or a fake activity which complements the
1.81 +manual transaction.
1.82 +Anyway, this step finalizes the registration process and makes the instance
1.83 +assume it has been properly registered. This status can be printed. URL
1.84 +rewriting is activated.
1.85 +A copy of the output of the last run is also saved to the C<${REGISTRY_UTIL}> file.
1.86 +
1.87 +=item B<-C>, B<--convenience>
1.88 +
1.89 +Execute the primary operation "convenience".
1.90 +This executes the three primary operations "preparation", "transaction" and
1.91 +"utilization" in that order and pipes data through this chain.
1.92 +
1.93 +=item B<-I>, B<--interaction>
1.94 +
1.95 +Execute the primary operation "interaction".
1.96 +Like "convenience" but user is interactively asked for information. This is
1.97 +the easiest way to do registration but it is not meat to be automated.
1.98 +
1.99 +=item B<-S>, B<--printstatus>
1.100 +
1.101 +If the instance has been registered, information about the registration is printed in a
1.102 +format suitable for shell evaluation and return code is true.
1.103 +Otherwise nothing is printed and return code is false.
1.104 +
1.105 +=item B<-R>, B<--rewriteurls> [I<url> ...]
1.106 +
1.107 +If the instance has been registered, the given URLs are rewritten to prepend
1.108 +user:pass information before hostnames below the openpkg.(org|net|com)
1.109 +domains. Note the username is is UUID_REGISTRY and the password is the
1.110 +concatenation of UUID_INSTANCE and UUID_PLATFORM from the
1.111 +PREFIX/etc/openpkg/uuid file. Both informations are not meant to be used for
1.112 +traditional authentication, they are merly statistical information.
1.113 +Otherwise the URLs are returned verbatim.
1.114 +
1.115 +=back
1.116 +
1.117 +=head1 STANDARD OPTIONS
1.118 +
1.119 +Standard options are typically used to automate registration (not
1.120 +association).
1.121 +
1.122 +=over 4
1.123 +
1.124 +=item B<-m>, B<--mode> fake|post|wipe
1.125 +
1.126 +Overrides C<${REGISTRY_MODE}> variable in C<${REGISTRY_CONF}> file.
1.127 +Has no default and is a manadatory setting.
1.128 +
1.129 +In B<post> mode, transactions are carried out using real network connectivity.
1.130 +The "preparation" step creates a XMLdump and writes it into the
1.131 +C<${REGISTRY_PREP}> file. The "transaction" step posts it to the DropXML form
1.132 +using a HTTP request. The response coming back from Registration server is
1.133 +also in XML format and is saved to C<${REGISTRY_TRAN}> file. The
1.134 +"utilization" step processes this response and writes the final results to the
1.135 +C<${REGISTRY_UTIL}> file.
1.136 +
1.137 +In B<fake> mode, no network connectivity takes place.
1.138 +The "prepararation" step creates a XMLdump and writes it into the
1.139 +C<${REGISTRY_PREP}> file. The "transaction" step is a fake only. It assumes a
1.140 +successful response from the Registration server and saves it to
1.141 +C<${REGISTRY_TRAN}> file. The "utilization" step processes this response and
1.142 +writes the final results to the C<${REGISTRY_UTIL}> file.
1.143 +I<Note>: fake mode is meant as a way to register instances which cannot or must
1.144 +not post data directly to the Registration server.
1.145 +
1.146 +In B<wipe> mode, the registration is wiped out locally. The status is reset
1.147 +and URL rewriting is disabled.
1.148 +I<Note>: the registration server is not contacted, the instace must be removed
1.149 +manually using the web interface.
1.150 +I<Note>: wiping registration is highly recommended as a precursor action of
1.151 +cloning activities.
1.152 +
1.153 +=item B<-a>, B<--args> "arg [arg ...]"
1.154 +
1.155 +Overrides C<${REGISTRY_ARGS}> variable in C<${REGISTRY_CONF}> file.
1.156 +Complements the mode and is specific to it.
1.157 +Defaults to "http://registry.openpkg.org/register" which is the official registry of the OpenPKG Project.
1.158 +This default is useful for "post" mode.
1.159 +
1.160 +=item B<-u>, B<--user> I<user|token>
1.161 +
1.162 +Overrides C<${REGISTRY_USER}> variable in C<${REGISTRY_CONF}> file.
1.163 +Indicates the registry user which will find this registration in his arrival queue.
1.164 +The user can also specified as a token which is enabled for use as "user".
1.165 +If the token is also enabled for "assoc" the registered instance is immediately associated
1.166 +to the user with no need for the user to visit the web interface.
1.167 +This information in submitted via the "registry_user" attribute of the XML request.
1.168 +Retrieves default online from http://openpkg.org/go/autoregister and is a manadatory setting.
1.169 +
1.170 +=item B<-l>, B<--link> I<token>
1.171 +
1.172 +Overrides C<${REGISTRY_LINK}> variable in C<${REGISTRY_CONF}> file.
1.173 +Indicates the registry user which will find this registration linked to his token.
1.174 +The link must be specified as a token which is enabled for use as "link".
1.175 +If a user token is used and the link token is also enabled for "assoc" then the registered instance
1.176 +is immediately associated to the user with no need for the user to visit the web interface.
1.177 +This information in submitted via the "registry_link" attribute of the XML request.
1.178 +Has no default and is an optional setting.
1.179 +Be aware that linked users see the same information about an instance as the associated user
1.180 +can find on his "association" page but they cannot alter or delete information.
1.181 +
1.182 +=item B<-d>, B<--desc> I<description>
1.183 +
1.184 +Overrides C<${REGISTRY_DESC}> variable in C<${REGISTRY_CONF}> file.
1.185 +Indicates a human readable description of the instance.
1.186 +This information in submitted via the "registry_desc" attribute of the XML request.
1.187 +It appears in the "description" column on the "association" page of the web form and can be edited on the server side.
1.188 +Defaults to "openpkg://${FQDN}${PREFIX}"
1.189 +
1.190 +=back
1.191 +
1.192 +=head1 ADVANCED OPTIONS
1.193 +
1.194 +Advanced options can be enganged to tailor and fully automate a registration
1.195 +(not association).
1.196 +
1.197 +=over 4
1.198 +
1.199 +=item B<--plat>
1.200 +
1.201 +Overrides C<${REGISTRY_PLAT}> variable in C<${REGISTRY_CONF}> file.
1.202 +Indicates the platform. Concatenated information from CPU architecture (arch) and Operating System (os).
1.203 +This information in submitted via the "registry_plat" attribute of the XML request.
1.204 +Defaults to "%{l_platform -p}", e.g. "ix86-freebsd6.1"
1.205 +
1.206 +=item B<--orel>
1.207 +
1.208 +Overrides C<${REGISTRY_VERS}> variable in C<${REGISTRY_CONF}> file.
1.209 +Indicates the OpenPKG release.
1.210 +This information in submitted via the "registry_orel" attribute of the XML request.
1.211 +Defaults to "%{l_openpkg_release}", e.g. "OpenPKG-CURRENT", "OpenPKG-2-STABLE", "OpenPKG-2.5",
1.212 +
1.213 +=item B<--uuid>
1.214 +
1.215 +Overrides C<${REGISTRY_UUID}> variable in C<${REGISTRY_CONF}> file.
1.216 +Indicates the UUID file of the instance.
1.217 +This information in submitted via the "uuid_registry", "uuid_instance" and "uuid_platform" attributes of the XML request.
1.218 +Defaults to F<${PREFIX}/etc/openpkg/uuid>
1.219 +
1.220 +=item B<--conf>
1.221 +
1.222 +Overrides C<${REGISTRY_CONF}> variable from previous C<${REGISTRY_CONF}> file. Processing
1.223 +of the current configuration file is aborted immediately with all variables
1.224 +read so far kept. THe new configuration file is read in immediately and
1.225 +processing continues there. This works similar to an include but is more
1.226 +primitive as it does not allow nesting, only chaining.
1.227 +Defaults to F<${PREFIX}/etc/openpkg/register.conf>
1.228 +
1.229 +=item B<--prep>
1.230 +
1.231 +Overrides C<${REGISTRY_PREP}> variable in C<${REGISTRY_CONF}> file.
1.232 +File to save a copy of the output from the "preparation" step.
1.233 +Defaults to F<${PREFIX}/etc/openpkg/register.prep>
1.234 +
1.235 +=item B<--tran>
1.236 +
1.237 +Overrides C<${REGISTRY_TRAN}> variable in C<${REGISTRY_CONF}> file.
1.238 +File to save a copy of the output from the "transaction" step.
1.239 +Defaults to F<${PREFIX}/etc/openpkg/register.tran>
1.240 +
1.241 +=item B<--util>
1.242 +
1.243 +Overrides C<${REGISTRY_UTIL}> variable in C<${REGISTRY_CONF}> file.
1.244 +File to save a copy of the output from the "utilization" step.
1.245 +Defaults to F<${PREFIX}/etc/openpkg/register.util>
1.246 +
1.247 +=item B<--data>
1.248 +
1.249 +Overrides C<${REGISTRY_DATA}> variable in C<${REGISTRY_CONF}> file.
1.250 +Comma separated list of tags to prepare. Available tags are "request",
1.251 +"package" and "provides". The "request" refers to the whole thing and
1.252 +is mandatory. The "package" includes name-version-release information
1.253 +for all installed packages and "provides" adds more details required to
1.254 +capture package options. For details see OPENPKG_PREP below.
1.255 +Defaults to "request,package,provides"
1.256 +
1.257 +=back
1.258 +
1.259 +=head1 FILES
1.260 +
1.261 +The following files are used by B<openpkg register>:
1.262 +
1.263 +=over 4
1.264 +
1.265 +=item OPENPKG_UUID=F<${PREFIX}/etc/openpkg/uuid>
1.266 +
1.267 + UUID_REGISTRY="..."
1.268 + UUID_INSTANCE="..."
1.269 + UUID_PLATFORM="..."
1.270 +
1.271 +=item OPENPKG_CONF=F<${PREFIX}/etc/openpkg/register.conf>
1.272 +
1.273 +Format suitable for shell evaluation. Interactive mode appends remarked date
1.274 +and current settings for reuse as new defaults for future runs. Can be preset
1.275 +to customize or automate registration.
1.276 +
1.277 +=item OPENPKG_PREP=F<${PREFIX}/etc/openpkg/register.prep>
1.278 +
1.279 + <?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
1.280 + <!DOCTYPE registry
1.281 + PUBLIC "-//OpenPKG//DTD OpenPKG Registry 0.0.1//EN"
1.282 + "http://registry.openpkg.org/registry.dtd" []>
1.283 + <registry>
1.284 + <request id="..."
1.285 + registry_user="me@example.com"
1.286 + registry_desc="openpkg://rm0.openpkg.net/openpkg-dev"
1.287 + registry_plat="ix86-freebsd6.1"
1.288 + registry_orel="OpenPKG-CURRENT"
1.289 + uuid_registry="..."
1.290 + uuid_instance="..."
1.291 + uuid_platform="..."
1.292 + />
1.293 + <package id="..." name="ssmtp" version="2.61" release="20050608">
1.294 + <provides name="ssmtp::with_ssl" flag="=" version="no"/>
1.295 + <provides name="MTA" flag="" version=""/>
1.296 + <provides name="ssmtp" flag="=" version="2.61-20050608"/>
1.297 + </package>
1.298 + </registry>
1.299 +
1.300 +The XML request starts with <?xml version ...> and <!DOCTYPE registry ...>
1.301 +headers followed by a <registry> container. The request is inside a <request>
1.302 +tag. Successful submission into the XMLdump form requires the headers and
1.303 +exactly one container. It is possible to merge multiple requests into a single
1.304 +container manually or otherwise and submit them all at once.
1.305 +
1.306 +=item OPENPKG_TRAN=F<${PREFIX}/etc/openpkg/register.tran>
1.307 +
1.308 + <?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
1.309 + <!DOCTYPE registry
1.310 + PUBLIC "-//OpenPKG//DTD OpenPKG Registry 0.0.1//EN"
1.311 + "http://registry.openpkg.org/registry.dtd" []>
1.312 + <registry>
1.313 + <response id="..." done="yes">openpkg://rm0.openpkg.net/openpkg-dev</response>
1.314 + </registry>
1.315 +
1.316 +The XML response starts with <?xml version ...> and <!DOCTYPE registry ...>
1.317 +headers followed by a <registry> container. The response is inside a <request>
1.318 +tag. The data carried in the tag comes from the "description" column on the
1.319 +"association" page of the web form and can be edited on the server side.
1.320 +
1.321 +=item OPENPKG_UTIL=F<${PREFIX}/etc/openpkg/register.util>
1.322 +
1.323 + REGISTRY_DBID="..."
1.324 + REGISTRY_DONE="yes"
1.325 + REGISTRY_RESP="openpkg://foo.example.com/my/openpkg/prefix"
1.326 +
1.327 +=back
1.328 +
1.329 +=head1 EXAMPLES
1.330 +
1.331 + # su - openpkg-mop
1.332 + $ openpkg register --printstatus
1.333 + REGISTRY_DBID="..."
1.334 + REGISTRY_DONE="yes"
1.335 + REGISTRY_RESP="openpkg://foo.example.com/my/openpkg/prefix"
1.336 + $ openpkg register --printstatus >/dev/null && echo "Yup"
1.337 + Yup
1.338 + $ eval `openpkg register --printstatus`; echo DONE=$REGISTRY_DONE
1.339 + DONE=yes
1.340 + $ openpkg register --mode=wipe
1.341 + $ openpkg register --printstatus || echo "Nope"
1.342 + Nope
1.343 + $ openpkg register --user=thl@openpkg.net --mode=post
1.344 + REGISTRY_DBID="...."
1.345 + REGISTRY_DONE="yes"
1.346 + REGISTRY_RESP="openpkg://foo.example.com/my/openpkg/prefix"
1.347 + $ openpkg register --printstatus >/dev/null && echo "Yup"
1.348 + Yup
1.349 + $ openpkg register --rewriteurls http://download.openpkg.org/foo/bar
1.350 + ftp://...:...@download.openpkg.org/foo/bar
1.351 +
1.352 +=head1 SEE ALSO
1.353 +
1.354 +bash(1), C<openpkg man uuid>, C<http://registry.openpkg.org/>
1.355 +
1.356 +=head1 AUTHOR
1.357 +
1.358 +Thomas Lotterer E<lt>thl@openpkg.orgE<gt>
1.359 +
1.360 +=cut
1.361 +
