Reference Information › CA AppLogic Support Knowledge Base › Overview of Support Knowledge Base › Backbone Fabric Controller Home › Brownbag Session - 2012-02-23 - Backbone Fabric Controller 3.1: Install, BFC Users, and Scripting

Brownbag Session - 2012-02-23 - Backbone Fabric Controller 3.1: Install, BFC Users, and Scripting

Brownbag Session - 2012-02-23 - Backbone Fabric Controller 3.1: Install, BFC Users, and Scripting

Module Objectives

After completing this module, you will be able to:

• Understand BFC Installation, Recovery and Upgrade
• Understand the users the BFC creates
• Understand BFC scripting

Why you need to know:

• These topics provide a knowledge base for Support that will help in resolving customer issues with the BFC

Agenda

1. BFC-generated users
2. BFC installation, upgrade and recovery
3. BFC scripting

1. BFC-generated Users

The BFC installer creates two users that the BFC uses in performing its operations

bfcadmin

• Webserver runs as bfcadmin user, as the webserver should not run as root due to security issues
• Firewall prevents any other kind of access

  bfcutil
  

• This user allows scp of inventory and deployer results back to the BFC from a server running the utility image

Think of the BFC as an appliance from the standpoint of these two users. UIDs, home directories, ssh keys all should not be modified.

The BFC installer also creates a bfc group

bfc group

• Created so that the BFC can have group owenership of some of our files instead of world ownership

2. BFC Installation, Upgrade and Recovery

The BFC installer inspects and updates CentOS and then installs the BFC

CentOS 5.5 installation prerequisites

• YUM configuration validated (used to install packages required by BFC)
• easy to configure a yum repo backed by installation media
• SELinux must be disabled (bad interactions with LDAP)
• 32 bit systems only (no testing on 64 bit)
• Adequate disk space
• 25GB in install location (assumes at least one version will be imported)
• 1GB in /
• 1GB in /var
• Configured interfaces on both the backbone and external networks

BFC Distribution Contents

• bfcext.iso: contains GPL software components used by the BFC implementation
• bfcinstall.iso: contains the BFC implementation
  • also includes some open source software with agreeable licensing terms
• fcinstall.sh
  • Setup/configuration program
• bfc rpm
  • Erlang release

    R14B distro: kernel, stdlib, etc.

    CA-developed applications: components, services, grid, etc. A combination of erlang and python code

  • WebUI

    GWT

  • Setup

    Python code invoked by fcinstall.sh to configure the BFC

• bfc-lang-pack rpm
  • Localizations
• bfc-docs rpm
  • Documentation for use at sites without external network connectivity

bfcext.iso

• bfc-utilityimage rpm
  • Bootable Linux image used in discovery/inventory/node-provisioning
• Python26 rpms
  • CentOS includes python 2.4 (there seems to be a hard dependency on 2.4)
  • BFC uses 2.6 for its install/configuration system and for its component drivers that are written in python.
• dhc-ldap rpm
  • CentOS 5.5 does not contain a version of dhcp that takes its configuration info from LDAP

The BFC installation flow

Previous installation is uninstalled

• Uninstall aborts if there are any grids defined
• "-f" flag on fcinstall.sh disables the grid check

  Useful if the BFC is not running

bfcext.iso is mounted (on a temporary directory)

Package dependencies are installed via yum

BFC packages are installed via rpm (bfc-utilityimage, bfc, bfc-lang-pack, bfc-doc)

• RPM pre/post scripts do the following:

  Validate file system space availability

  Create users/group (bfcadmin and bfcutil users, bfc group)

  Set up erlang distro

  Set up BFC web UI (webmachine configuration)

Python setup program is invoked

• Input data (replication, passphrase, admin password, network info)
• Configure iptables firewall (using supplied network info)
• Set up system services

  tftp

  ldap

  dhcp

  nfs

• Set up utility image

  PXE boot setup

  Generate and set up ssh keys

• Set up BFC

  Create service (/etc/init.d/bfc)

  SSL certificate for web server (self-signed)

The BFC can be recovered from a replica database

Recovery from an existing replica

• Replica directory must be populated; files must be owned by bfcadmin:bfc

Machine being installed must have the same "identity" as the original from which the replica was made:

• Network addresses (external and backbone)
• uname -n
• hostname -s
• Installation target directory ("-t" flag to fcinstall.sh)
• BFC version

Replica directory and passphrase must be specified

• Passphrase must match original
• No inputs for app password or network interfaces - obtained from replica

Setup and configuration identical to initial install (package install via yum, rpm install, service configuration, utility image setup, etc.)

Download directory must be populated

• All known versions/hotfixes must be present
• In 3.1 only imported versions are required

If an upgrade fails, replica directory can be used to re-install previous BFC version

Prior to the upgrade, make sure replication is on. If replication is not on, turn it on (even if it is replicating to a local directory)

If the upgrade fails, and the BFC is not properly recovered (upgrade should attempt to recover back to the previous version on failure, but if it doesn't...)

• Uninstall the BFC
• Run the installer for the pre-upgrade version, and answer "yes" to the recovery question
• This will recover the BFC back to its pre-upgrade state

If the mnesia db is corrupt such that the BFC will not start, a last-resort option is the db_restore script

db_restore script

• Restores the mnesia db
• Restores from the latest backup in /opt/bfc/Mnesia.bfc/backup
• Currently does not ask for confirmation, or from which backup you'd like to restore, so be careful before running. Should check the dates on the backup files in the /opt/bfc/Mnesia.bfc/backup directory before running

BFC Upgrade from 3.0 to 3.1 is supported (and will be supported from 3.0/3.1 to 3.5)

BFC Upgrade:

• Can be run with no affect on running grids, regardless of their AppLogic version
• Checks for ongoing grid operations (grid updates, creates, etc.)
• Shuts down any SLA processing (any grids looking for servers)
• Shuts down the BFC
• Verifies OS packages and updates as necessary
• Does the upgrade of the BFC code/db
• Starts the BFC against a replicated db, then shuts down the BFC
• Restarts the BFC and SLA processing

3. BFC Scripting

BFC Scripts

Both shell script and "escripts" are located in/opt/bfc/bin

• Shell scripts like "uninstall" are run just like any other shell script
  • Uninstall
  • Db_restore
  • Add_ssh_keys
• "escripts" access the erlang infrastructure
  • "" to run an escript (bfcadmin user has its path set up to run the escript command)
  • Unlock_user
  • Stop_replication
  • gridcnt

  BFC escripts are only generated by the development team

  In cases where the development team has created scripts to "unstick" an object, these are escipts

  • Escripts require a great deal of knowledge of the BFC component model
  • Really need to be a BFC developer to be able to write escripts
  • Easy way to corrupt a BFC if done improperly

  In 3.5 BFC API will be available

  • Webservices interface
  • Can write python, curl commands, java, etc. to create scripts
  • First version mainly concentrates on grid creation, update
  • Lots of administration tasks (like everything in the checklist) will need to be done via the UI in the first version

Summary

This module showed you:

• An explanation of the users the BFC creates
• An explanation of BFC installation, upgrade and recovery
• An explanation of BFC scripting for future releasess