1. Module Description - What the module does and why it is useful
2. Setup - The basics of getting started with backuppc
   • What backuppc affects
   • Setup requirements
   • Beginning with backuppc
3. Usage - Configuration options and additional functionality
4. Limitations - OS compatibility, etc.
5. Development - Guide for contributing to the module
6. Acceptance Tests

This is a SIMP module

This module is a component of the System Integrity Management Platform, a compliance-management framework built on Puppet.

If you find any issues, they can be submitted to our JIRA.

Please read our Contribution Guide and visit our developer wiki.

Module Description

BackupPC is a utility for archiving and restoring data from a central, networked, location. The backuppc module allows for general use and setup, but the default configuration is designed to securely pass data using rsync over SSH.

Setup

What backuppc affects

BackupPC installs the BackupPC Package, manages the service and will set a non-authoritave configuration, that can be changed within the BackuPC GUI.

Setup Requirements

A node should be selected as the BackupPC server before clients are configured with BackupPC

Beginning with backuppc

To get the basic BackupPC setup working in your environment, you should follow either the File Based Authentication or LDAP Authentication below.

Look at the code comments or the developer section under 'simp doc' for additional information on extended usage.

Usage

Server Configuration with File Based Authentication

This method allows for a basic setup and will provide you with a working environment using Apache's file based basic authentication.

  # Repeat this for every user you want on the system.
  backuppc::server::user { 'username':
    password => 'output of ruby -r sha1 -r base64 -e 'puts "{SHA}"+Base64.encode64(Digest::SHA1.digest("password"))''
  }

include 'backuppc'

An example of .yaml:

---
backuppc::is_server: true
backuppc::backup_hosts:
  - backupserver.example.domain
backuppc::server::cgi_admin_users:
  - user1
  - user2
apache::conf::user: 'backuppc'
apache::conf::group: 'apache'
# Only set this if your clients have personal certificates.
apache::ssl::sslverifyclient: 'none'

Server Configuration with LDAP Authentication

include 'backuppc'

An example .yaml config:

---
backuppc::backup_hosts:
  - 'backupserver.example.domain'
backuppc::server::cgi_admin_users:
  - 'user1'
  - 'user2'
backuppc::server::httpd_file_auth: false
backuppc::server::httpd_ldap_auth: true
apache::conf::user: 'backuppc'
apache::conf::group: 'apache'
apache::ssl::sslverifyclient: 'none'

At this point, you should be able to access BackupPC by accessing https://<your_servername>/BackupPC.

Configuring the Client

The client is much simpler to set up.

  include 'backuppc'

With the following in Hiera:

---
backuppc::backup_hosts:
  - 'backupserver.example.domain'

---

NOTES

• After the first run, puppet is no longer authoritative for the BackupPC configuration by default. If you want puppet to be authoritative, you'll need to set $authoritative_conf to 'true' when calling backuppc::server::conf

• This module automatically creates an SSH user key for BackupPC that is used by the bpc_user. This will not be created until a call to backuppc::conf has been made.

• You can use both httpd_file_auth and httpd_ldap_auth simultaneously if you so choose.

The BackupPC web page: http://backuppc.sourceforge.net/

---

Limitations

SIMP Puppet modules are generally intended to be used on a Red Hat Enterprise Linux-compatible distribution.

Development

Please read our Contribution Guide and visit our Developer Wiki

If you find any issues, they can be submitted to our JIRA.

SIMP Contribution Guidelines

System Integrity Management Platform

Acceptance tests

To run the system tests, you need Vagrant installed.

You can then run the following to execute the acceptance tests:

   bundle exec rake beaker:suites

Some environment variables may be useful:

   BEAKER_debug=true
   BEAKER_provision=no
   BEAKER_destroy=no
   BEAKER_use_fixtures_dir_for_modules=yes

• BEAKER_debug: show the commands being run on the STU and their output.
• BEAKER_destroy=no: prevent the machine destruction after the tests finish so you can inspect the state.
• BEAKER_provision=no: prevent the machine from being recreated. This can save a lot of time while you're writing the tests.
• BEAKER_use_fixtures_dir_for_modules=yes: cause all module dependencies to be loaded from the spec/fixtures/modules directory, based on the contents of .fixtures.yml. The contents of this directory are usually populated by bundle exec rake spec_prep. This can be used to run acceptance tests to run on isolated networks. ~