This is ../info/swbis.info, produced by makeinfo version 4.9 from
swbis.texi.

   This manual is for swbis (version 0.950, 01 Dec 2007), which is a
implementation of the POSIX System Administration - Part 2: Software
Administration conforming to IEEE Std 1387.2-1995 (ISO/IEC 15068-2) and
Open Group CAE C701.  Currently, not all of the standard is
implemented.  There are extensions for package authentication.
Extensions to the standard are indicated as such in this document.

   Copyright (C) 2005, 2006 James H. Lowe, Jr.

     Permission is granted to copy, distribute and/or modify this
     document under the terms of the GNU Free Documentation License,
     Version 1.1 or any later version published by the Free Software
     Foundation; with no Invariant Sections, with the Front-Cover Texts
     being "A GNU Manual," and with the Back-Cover Texts as in (a)
     below.  A copy of the license is included in the section entitled
     "GNU Free Documentation License."

     (a) The FSF's Back-Cover Text is: "You have freedom to copy and
     modify this GNU Manual, like GNU software.  Copies published by
     the Free Software Foundation raise funds for GNU development."

INFO-DIR-SECTION Software development
START-INFO-DIR-ENTRY
* Swbis: (swbis).               POSIX software packaging utilities.
END-INFO-DIR-ENTRY


File: swbis.info,  Node: Host Requirements,  Next: Configuring swbis,  Prev: Other Resources,  Up: Top

Host Requirements
*****************

'swbis' is designed to be as non-intrusive as possible and this applies
to host requirements which are minimal.

   For package creation you need `uuidgen' and if creating signed
distributions you need `gpg'.

   For package installation you need `sh', `bash', `getconf', `dd',
`tar', `hostname', `mkdir', `expr', `echo', `test', `sleep'.

   Installation of packages on remote hosts (i.e. using swinstall with
a remote host target) does not require swbis to be installed there.

   The `swverify' and `swign' commands are shell scripts which may have
additional requirements.

   Here are the technical details about requirements for `swinstall',
the same apply to `swcopy':

   `swinstall' requires a Posix shell accessible by the remote shell
command.  This is the remote command run by ssh (or rsh)  for  all
operations.  This command can be controlled by the -shell-command
option or the swbis_shell_command defaults file  option.   Permitted
values  are "bash"  (/bin/bash  -s) or "sh" (/bin/sh -s) or "posix"
('PATH=`getconf PATH` sh -s').   The default is  "posix".   `swinstall'
requires  the POSIX capability of reading commands on stdin according
to the specification described in IEEE Std  1003.1,  2003  Ed.;  sh
-shell,  Section STDIN.

   This requirement accommodates reading of shell program code and data
on STDIN.  This capability may not  be  present  in  some  /bin/sh
shells.   The  "/bin/sh"  on  FreeBSD-5.1 may be broken in this regard,
hence "-shell-command=bash" should be used for BSD hosts.  The  public
domain Korn shell (pdksh-5.2.14) seems to work OK, that is, it complies
by luck or intent with the POSIX capability of reading  data  and code
on stdin.

   If  the  -no-getconf  option  is set or the
swinstall.swbis_no_getconf defaults option is "true" then the remote
command is '/bin/sh -s'.  Use of the no-getconf option is needed for
communication with user accounts on remote machines whose login shell
is not a Bourne shell  (e.g.  csh) such as root on some default BSD
installations.  Other *nix systems may require use of getconf because
their /bin/sh is  broken  or  not  Posix enough (e.g. Sun platforms).
Still other systems may not have getconf.

   Other utilities required to be in $PATH on the remote host are: dd,
pax (or  tar|star|gtar), hostname, mkdir, expr, echo, test, sleep, read
(if not builtin).


File: swbis.info,  Node: Installing RPM Packages,  Next: Translating RPM Format Packages to a POSIX Distribution,  Prev: Installing POSIX Distributions,  Up: Top

Installing RPM Packages
***********************

Installing RPMs results in the RPM first being translated to a POSIX
archive in tar format, *Note Translating RPM Format Packages to a POSIX
Distribution::, then installation by swinstall proceeds normally.

     swinstall --allow-rpm -s - @ host1:/mnt/test/root1 < your-0.1.arch.rpm

   In this example, a remote host and target path is specified.  No
files will be installed outside of the target path.  The `allow-rpm'
may be turned on in the `swbisdefaults' file or by command line option.


File: swbis.info,  Node: Translating RPM Format Packages to a POSIX Distribution,  Next: Remote Host Operations,  Prev: Installing RPM Packages,  Up: Top

Translating RPM Format Packages
*******************************

Translation of RPMs is done in memory. No temporary files are created.
Large RPMs or RPMs with many small files may take many seconds or
several minutes to translate.

   Translation is performed by the swbis library executable `lxpsf' and
`swpackage'.

     /usr/lib/swbis/lxpsf --psf-form2 -H ustar |
     swpackage -Wsource=- -s@PSF

   The `lxpsf' is the only swbis program with RPM library dependencies,
and this is the program that does the actual meta-data translation.

   Depending on compilation options, it is possible to disable RPM
translation ability (this is the default), or specify that the built-in
library is to be used.  The built-in library is base on RedHat rpm
release 3.0.5.  If the built-in compile option, `with-self-rpm' is used
there are no dependencies on other packages.

   The easiest way to invoke translation is with the `--unrpm' of
`swpackage' and `swcopy'.

       swcopy --unrpm -s - @- <your-0.1.arch.rpm | tar tvf -
           -or-
       swpackage --unrpm @- <your-0.1.arch.rpm | tar tvf -

   To verbosely preview the translated RPM:

       swcopy --unrpm -s - @- | swinstall -p -x verbose=5


File: swbis.info,  Node: Remote Host Operations,  Next: GNU Toolset Orthogonality,  Prev: Translating RPM Format Packages to a POSIX Distribution,  Up: Top



swbis is network transparent from the ground up.  It uses ssh (or rsh)
to establish remote connections.  Communication then takes place on
standard input, output and error as established by the remote shell
client on the local host.  Operations which are entirely local are
symmetric with remote operations in that swbis communicates via Unix
pipes and makes no distinction based on the locality of the
communication endpoints.

   swbis uses the ssh client program 'ssh' as found by the PATH
variable.  swbis adds the '-T' option to disable pseudo-tty allocation.

   swbis supports an extension to the POSIX target syntax to support
multiple host hops.  Use of password authentication for multi-hop
targets requires use of the SSH_ASKPASS program and redirection of X11
connections over the secure ssh channel.  See the 'ForwardX11' option
in the ssh client configuration.  Use of public key authentication is
more reliable since the authentication agent is forwarded by use of the
'-A' ssh option.

   Important Note:  When making a multi-hop connection using either
authentication method, the authentication credentials appear on the
intermediate hosts and are subject to hijack, hence, the intermediate
hosts' trust requirement should be no less than the terminal host's.


File: swbis.info,  Node: GNU Toolset Orthogonality,  Next: Package Layout and Interchange Format Mimicry,  Prev: Remote Host Operations,  Up: Top



One overriding design goal of swbis is zero re-invention.  To that end,
swbis uses '/usr/bin/gpg' for signing and authentication.  It uses
'rsh' and 'ssh' for remote connections.  It uses 'bash' (as a POSIX
shell) for command processing.  It uses 'pax' or 'tar' for archive
installation.  It uses a file system directory structure as the
database for installed software.


File: swbis.info,  Node: Package Layout and Interchange Format Mimicry,  Next: (swbis_swpackage)SWPACKAGE OUTPUT FORMAT,  Prev: GNU Toolset Orthogonality,  Up: Top



swbis is non-intrusive relative to current practice for data
interchange and storage using tar archives.

   swbis supports a 'minimal package layout' (*Note (swbis_sw)Minimal
Package Layout::.)  This layout follows the POSIX spec but has nil
control directories (Note: nil control directories are not attested to
in the POSIX specification).

   By specifying control directories as empty strings and specifying a
non-empty leading directory for the archive, a swbis POSIX package may
be used inter-changeably with free software tar archive source packages
which commonly have a leading package directory.

   Binary (run-time) packages follow the same pattern except the leading
directory is specified as an empty string as well.  The result is a
run-time package directly installable by `tar'.

   The non-inventive nature of swbis extends into the format level as
well.  swbis has its own archive writing utility, `swpackage', and it is
self contained, however, it writes tar archives which are identical to
archives produced by GNU tar.

   This data format mimicry has several advantages.  It forms the basis
for a very brittle regression test, namely bit-for-bit sameness with
GNU tar.  This also preserves symmetry between a package archive and
package directory in that swbis archives installed with tar can be
repackaged with GNU tar with no bit-wise change relative to the
original.

   Together, these layers of mimicry are put to practical application
in the `swign' program (*Note (swbis_swign)::) which creates GPG signed
POSIX packages without any data copying except by GNU tar.


File: swbis.info,  Node: Index,  Prev: (swbis_sw)EXAMPLE PACKAGE,  Up: Top

Index
*****


