Project

General

Profile

TOC PREV NEXT
Fermilab CD logo Complete Guide and Reference Manual for UPS and UPD

Chapter Contents

Chapter 9: Product Installation: Special Cases
   9.1 Installing Products that Require Special Privileges
   9.2 Installing into Local Filesystem Using UPD from AFS-Space
   9.3 Installing Products into AFS Space
     9.3.1 Overview
     9.3.2 Request a Product Volume
     9.3.3 Install your Product
     9.3.4 Post-Installation Steps

  Chapter 9: Product Installation: Special Cases

  This chapter provides product installation information about specific cases. It discusses:

  • how to install products requiring special privileges
  • how to install into a local products area using the installation of UPD in AFS space
  • how to install products into the AFS-space UPS products area

  9.1 Installing Products that Require Special Privileges

  Although no currently supported packages require special configuration, there may be unsupported packages that people still use, such as 'systools' or 'flpr' that have installasroot actions required. If special permissions must be set, then 'installasroot' is the recommended way to get this.

If you are using 'installasroot,' at some point during the installation process users are prompted to login as root and run the command:

% ups installasroot <product> <version> [<options>]

  This command would then proceed to run the privileged installation actions. The INSTALL_NOTE file should provide instructions if this is necessary.

  Since the implementation of Kerberos authentication, the use of a special k5arc account on a distribution host provides a technique for restricting access to the host. The account gets created when ups installasroot k5arc is run at installation time. The account's login shell is restricted to ksu .

  The k5arc script (see section 21.3.1 Scripts Used to Access Distribution Database ) is designed to take you to the k5arc account on a distribution host, then ksu you to the account of your choice, from where you can execute commands. The individual accounts on the distribution host contain .k5users files. These files control which commands each user/principal is allowed to run.

  9.2 Installing into a Local Filesystem Using UPD from AFS-Space

 

  The local database is usually given a standard name in common use at Fermilab:

  /fnal/ups/db -- standard for several product server bootstrap configurations

  /local/ups/ -- standard for Fermi RedHat Linux

  /usr/products/ -- another popular naming convention

  /usr/products/CMSUN1/ -- naming convention for CMS local databases

There are two product areas, one that has UPD and one that doesn't. You can use the UPD in one product area to install into the other one.

%setup -z /path/a upd

%upd install -z /path/b some_package

  The database must point to a local UPD configuration file with appropriate product location definitions.

  If $PRODUCTS lists the local database first, users can run upd install without any database option and the product will go into the local database (assuming the UPD configuration is set accordingly). If $PRODUCTS doesn't list the local database first, include the -z option in the upd install command, e.g.,:

% upd install -z /path/to/local/db %{font-weight: bold;color: #000000}<product> <version>% ...

  9.3 Installing Products into AFS Space

This is specific to the Fermi central AFS UPS product area in /afs/fnal.gov/ups. People use replicated volumes to avoid having to unwind products into the read/write path /afs/.fnal.gov/... and declare them as /afs/fnal.gov... when they want to make another AFS product area with volume replication.

  9.3.1 Overview

  A single AFS volume is intended to contain instances for all flavors of a particular UPS product-version combination. For each product, there is a read/write volume into which the product must be installed:

  /afs/.fnal.gov/ups/<product>/<version>

  (note the dot preceding fnal ). There is a process called releasing a volume which replicates the read/write product volume into read-only clones. Replication avoids any single point of failure for a product and provides more robust service. Multiple frozen read-only copies of the product areas are kept on several AFS server machines. Users should run setup to access these redundant, read-only volumes of products. Otherwise, the benefit of cloning is wasted. A product must therefore be declared to UPS via its read-only pathname (notice the absence of a dot preceding fnal ):

  /afs/fnal.gov/ups/<product>/<version>

  The AFS-space updconfig file is configured to unwind products into the read/write area (via the UNWIND_PROD_DIR definition), and then release them to the read-only volumes, using the upd_volrelease script (via the PREDECLARE action). As the action name suggests, this happens before declaring the product. When ups declare gets called, the PROD_DIR_PREFIX in the AFS-space dbconfig file ensures that the read-only pathname gets declared.

  Installations into AFS space should be made from one of the interactive nodes of the fnalu cluster, preferably a SunOS node. The fnalu nodes have the arcd daemon running and supply the upd_volrelease script, both of which are required for AFS installations. fsui02.fnal.gov is the machine on which it works most consistently. If users need a non-SunOS node, use upd install -H <target_flavor> to set the flavor. The userid products and the groups uas and upsdatabase are allowed to install into AFS space. Other users/groups must create a Service Now ticket requesting permission to release a volume.

  9.3.2 Request a Product Volume

  Only AFS administrators are allowed to create product volumes. To request a product volume, contact the Service Desk. They will forward the message appropriately. Recall that all the instances for the different flavors of a particular product-version pair go into a single AFS volume. The request needs to include:

  • the product name
  • the product version
  • the combined size of the various instances that will go into the volume
  • the AFS user and group(s) who need write access

  An AFS administrator will create a volume writable by the requestor and the requestor's group, and notify the requestor when it's ready. The product instances can be installed in the volume as soon as it is created.

  9.3.3 Install your Product

  Be sure to have a Kerberos ticket and an AFS token first. Users also need upd_volrelease in their path. To verify this, do:

% which upd_volrelease.

If none is in your path, do:

% setup k5arc

Then you can reverify with the which upd_volrelease command.
p<>. Install each instance of the product (all of the same version) using the upd install command (documented in Chapter 6: Installing Products Using UPD ). Specify the read-only path for the database as shown here:

% upd install -z /afs/fnal.gov/ups/db <product> <version> \
 -f <flavor> [-q <qualifierList>] ...

  9.3.4 Post-Installation Steps

  Configure the Product

  Because the product areas as declared in AFS space are read-only, if the product requires configuration, execute the commandd using the read/write path name, e.g.,:

% ups configure -r /afs/.fnal.gov/... <product> <version> \
  -f <flavor>...

  Create Symbolic Links

  If the product needs the ability to write into any areas under its product root directory during normal use, then symbolically link these areas. If the area must be shared, link to the read/write area. If not, link to some area on non-AFS writable disk (e.g., under /tmp or /var ).

  For example, say the product fred in AFS space needs to write into $FRED_DIR/log which is read-only. Go into the read/write $FRED_DIR area, remove the log directory and create a link for the area in which to write (e.g., /var/tmp/fred ) in the read-write area, e.g.,:

% ln -s /var/tmp/fred /afs/.fnal.gov/ups/fred/v1_0/SunOS/log

  The volume needs to be released, as described below. The read-only replicas will contain the link.

  If links are made to a non-AFS writable disk, check the SETUP action in the product's table file; it should ensure that the specified area exists at product setup. E.g., if linking to /var/tmp/fred :

Action = setup
...
Execute( test -d /var/tmp/fred || (mkdir /var/tmp/fred; 
         chmod 777 /var/tmp/fred), NO_UPS_ENV) ( %{font-weight: normal;color: #000000}all on one line in real file% )

  Rerun the Volume Release

  If users have configured the product, or they have added symbolic links, they need to manually rerun the upd_volrelease script to re-release the product volume, e.g.,:

$ upd_volrelease /afs/.fnal.gov/ups/<product>/<version>

  unless the product's actions already take this into account (look for upd_volrelease calls in the table file's CONFIGURE action).

  Note that it doesn't hurt to re-release a product volume several times in a row, so if unsure, just rerun it.

  To save time, configure all the flavors of the product version first, and then run the upd_volrelease command once at the end.

 

 

TOC PREV NEXT

This page last revised in May 2014

TOC PREV NEXT
Fermilab CD logo Complete Guide and Reference Manual for UPS and UPD

Chapter Contents

Chapter 9: Product Installation: Special Cases
   9.1 Installing Products that Require Special Privileges
   9.2 Installing into Local Filesystem Using UPD from AFS-Space
   9.3 Installing Products into AFS Space
     9.3.1 Overview
     9.3.2 Request a Product Volume
     9.3.3 Install your Product
     9.3.4 Post-Installation Steps

  Chapter 9: Product Installation: Special Cases

  This chapter provides product installation information about specific cases. It discusses:

  • how to install products requiring special privileges
  • how to install into a local products area using the installation of UPD in AFS space
  • how to install products into the AFS-space UPS products area

  9.1 Installing Products that Require Special Privileges

  Although no currently supported packages require special configuration, there may be unsupported packages that people still use, such as 'systools' or 'flpr' that have installasroot actions required. If special permissions must be set, then 'installasroot' is the recommended way to get this.

If you are using 'installasroot,' at some point during the installation process users are prompted to login as root and run the command:

% ups installasroot <product> <version> [<options>]

  This command would then proceed to run the privileged installation actions. The INSTALL_NOTE file should provide instructions if this is necessary.

  Since the implementation of Kerberos authentication, the use of a special k5arc account on a distribution host provides a technique for restricting access to the host. The account gets created when ups installasroot k5arc is run at installation time. The account's login shell is restricted to ksu .

  The k5arc script (see section 21.3.1 Scripts Used to Access Distribution Database ) is designed to take you to the k5arc account on a distribution host, then ksu you to the account of your choice, from where you can execute commands. The individual accounts on the distribution host contain .k5users files. These files control which commands each user/principal is allowed to run.

  9.2 Installing into a Local Filesystem Using UPD from AFS-Space

 

  The local database is usually given a standard name in common use at Fermilab:

  /fnal/ups/db -- standard for several product server bootstrap configurations

  /local/ups/ -- standard for Fermi RedHat Linux

  /usr/products/ -- another popular naming convention

  /usr/products/CMSUN1/ -- naming convention for CMS local databases

There are two product areas, one that has UPD and one that doesn't. You can use the UPD in one product area to install into the other one.

%setup -z /path/a upd

%upd install -z /path/b some_package

  The database must point to a local UPD configuration file with appropriate product location definitions.

  If $PRODUCTS lists the local database first, users can run upd install without any database option and the product will go into the local database (assuming the UPD configuration is set accordingly). If $PRODUCTS doesn't list the local database first, include the -z option in the upd install command, e.g.,:

% upd install -z /path/to/local/db %{font-weight: bold;color: #000000}<product> <version>% ...

  9.3 Installing Products into AFS Space

This is specific to the Fermi central AFS UPS product area in /afs/fnal.gov/ups. People use replicated volumes to avoid having to unwind products into the read/write path /afs/.fnal.gov/... and declare them as /afs/fnal.gov... when they want to make another AFS product area with volume replication.

  9.3.1 Overview

  A single AFS volume is intended to contain instances for all flavors of a particular UPS product-version combination. For each product, there is a read/write volume into which the product must be installed:

  /afs/.fnal.gov/ups/<product>/<version>

  (note the dot preceding fnal ). There is a process called releasing a volume which replicates the read/write product volume into read-only clones. Replication avoids any single point of failure for a product and provides more robust service. Multiple frozen read-only copies of the product areas are kept on several AFS server machines. Users should run setup to access these redundant, read-only volumes of products. Otherwise, the benefit of cloning is wasted. A product must therefore be declared to UPS via its read-only pathname (notice the absence of a dot preceding fnal ):

  /afs/fnal.gov/ups/<product>/<version>

  The AFS-space updconfig file is configured to unwind products into the read/write area (via the UNWIND_PROD_DIR definition), and then release them to the read-only volumes, using the upd_volrelease script (via the PREDECLARE action). As the action name suggests, this happens before declaring the product. When ups declare gets called, the PROD_DIR_PREFIX in the AFS-space dbconfig file ensures that the read-only pathname gets declared.

  Installations into AFS space should be made from one of the interactive nodes of the fnalu cluster, preferably a SunOS node. The fnalu nodes have the arcd daemon running and supply the upd_volrelease script, both of which are required for AFS installations. fsui02.fnal.gov is the machine on which it works most consistently. If users need a non-SunOS node, use upd install -H <target_flavor> to set the flavor. The userid products and the groups uas and upsdatabase are allowed to install into AFS space. Other users/groups must create a Service Now ticket requesting permission to release a volume.

  9.3.2 Request a Product Volume

  Only AFS administrators are allowed to create product volumes. To request a product volume, contact the Service Desk. They will forward the message appropriately. Recall that all the instances for the different flavors of a particular product-version pair go into a single AFS volume. The request needs to include:

  • the product name
  • the product version
  • the combined size of the various instances that will go into the volume
  • the AFS user and group(s) who need write access

  An AFS administrator will create a volume writable by the requestor and the requestor's group, and notify the requestor when it's ready. The product instances can be installed in the volume as soon as it is created.

  9.3.3 Install your Product

  Be sure to have a Kerberos ticket and an AFS token first. Users also need upd_volrelease in their path. To verify this, do:

% which upd_volrelease.

If none is in your path, do:

% setup k5arc

Then you can reverify with the which upd_volrelease command.
p<>. Install each instance of the product (all of the same version) using the upd install command (documented in Chapter 6: Installing Products Using UPD ). Specify the read-only path for the database as shown here:

% upd install -z /afs/fnal.gov/ups/db <product> <version> \
 -f <flavor> [-q <qualifierList>] ...

  9.3.4 Post-Installation Steps

  Configure the Product

  Because the product areas as declared in AFS space are read-only, if the product requires configuration, execute the commandd using the read/write path name, e.g.,:

% ups configure -r /afs/.fnal.gov/... <product> <version> \
  -f <flavor>...

  Create Symbolic Links

  If the product needs the ability to write into any areas under its product root directory during normal use, then symbolically link these areas. If the area must be shared, link to the read/write area. If not, link to some area on non-AFS writable disk (e.g., under /tmp or /var ).

  For example, say the product fred in AFS space needs to write into $FRED_DIR/log which is read-only. Go into the read/write $FRED_DIR area, remove the log directory and create a link for the area in which to write (e.g., /var/tmp/fred ) in the read-write area, e.g.,:

% ln -s /var/tmp/fred /afs/.fnal.gov/ups/fred/v1_0/SunOS/log

  The volume needs to be released, as described below. The read-only replicas will contain the link.

  If links are made to a non-AFS writable disk, check the SETUP action in the product's table file; it should ensure that the specified area exists at product setup. E.g., if linking to /var/tmp/fred :

Action = setup
...
Execute( test -d /var/tmp/fred || (mkdir /var/tmp/fred; 
         chmod 777 /var/tmp/fred), NO_UPS_ENV) ( %{font-weight: normal;color: #000000}all on one line in real file% )

  Rerun the Volume Release

  If users have configured the product, or they have added symbolic links, they need to manually rerun the upd_volrelease script to re-release the product volume, e.g.,:

$ upd_volrelease /afs/.fnal.gov/ups/<product>/<version>

  unless the product's actions already take this into account (look for upd_volrelease calls in the table file's CONFIGURE action).

  Note that it doesn't hurt to re-release a product volume several times in a row, so if unsure, just rerun it.

  To save time, configure all the flavors of the product version first, and then run the upd_volrelease command once at the end.

 

 

TOC PREV NEXT

This page last revised in May 2014