# Host Configuration Management

## Overview

This describes how to use an unlicensed p4d private repo (with no p4d process running on a port) to manage configuration of specific files on a given server machine.  The p4d repo is self-contained on the machine, with no automated checkpoints or independent backups. This is backed up when this VM it runs on is backed up.

Essentially, a single workspace with a root directory of '/' is used to selectively and sparsely version individual files of interest on the disk, in place in their normal location. For example, we might version files such as:

* `/etc/grafana/grafana.ini`
* `/etc/grafana/ldap.toml`
* `/etc/hosts`
* `/root/.bashrc`

## Typical Usage Examples

Sample usage:

Login as root, and do

```
cd /etc/grafana
p4 opened                # <-- Make sure nothing was checked out from before.
p4 status grafana.ini    # <-- Make sure this says no files to reconcile.

p4 edit grafana.ini
vi grafana.ini           # <-- Make whatever changes you like.
p4 diff grafana.ini
p4 -s submit -d "Made a cool config change to Grafana." grafana.ini

fp

```

This last command, the `fp` alias, calls a script `/root/HostCM/fix_perms.sh` that uses a data file `/root/HostCM/fix_perms.dat` to adjust permissions after versioning operations.  This is only needed when the files being versioned have certain required ownership, group, and/or permissions settings (ala `chown` and `chmod`).  This script knows the required ownership and permissions and sets them. It is to be used after a `p4 submit` or `p4 sync` command.

For example, the `/etc/grafana/grafana.ini` and `/etc/grafana/ldap.toml` files are sensitive to permissions, and thus are listed in the `fix_perms.dat` file and require `fp` to be run after submitting, syncing, or fetching changes. The latter operation, fetching only applies if extending to central versioning.  Other files, such as `/etc/hosts`, are not particularly sensitive and do not require it (so long as the `umask` is the default, which it should be for root). However, `fp` is safe to run at any time.

## Extending to Central Versioning

This is host-local versioning. If we later decided to use centralized versioning, we can extend this approach to the p4hms server.  In this local repo we create a remote spec named 'origin' to reference the central HMS server.  That remote spec defines the mapping to the central server such that files in //streams/main/... in the local/private repo go to a path like `//HostCM/main/host/p4hms/...` on the central server.

Then we `p4 push` to push and `p4 fetch` to fetch changes to/from that central server.  While both pushing and fetching are possible, for this host-local versioning usage model, it is likely we will only push changes after first making edits on the local machine.

## One Time Setup for Host Configuration Management

### Step 1: Set P4CONFIG

Append these lines to the `~root/.bashrc` file:

```
export PATH="$PATH:/root/HostCM"
export P4CONFIG=.p4config.HostCM
alias o='p4 opened'
alias md='mkdir -p'
alias cls=clear
alias fp=/root/HostCM/fix_perms.sh
```

Then, to load this setting in the current shell, do:

```
source ~/.bashrc

```

We use a fully qualified path in P4CONFIG so it works from any directory.

### Step 2: Initialize the repo

Create the first file to version, as a sample and for documentation.

```
$ mkdir /root/HostCM
$ cd /root/HostCM
$ ln -s /p4/hms/bin/p4_hms p4
$ ln -s /p4/hms/bin/p4d_hms p4d
$ vi ReadMe.md    # <-- This file
```

Then initialize the repo.

```
$ cd /
$ p4 init -C0 -n
$ cd /root/HostCM
$ p4 rec
$ p4 submit -d "Added initial ReadMe.md file and p4/p4d symlinks." ...
```

At this point, we are setup for host-local versioning.

Following is a sample of some commands and actual output per above:

```
[root@p4hms /]# echo $P4CONFIG
.p4config.HostCM

[root@p4hms /]# p4 init -C0 -n
Server root-dvcs-1673882900 saved.

[root@p4hms /]# cd root/HostCM/

[root@p4hms HostCM]# ls
ReadMe.md

[root@p4hms HostCM]# p4 add ReadMe.md 
//streams/main/root/HostCM/ReadMe.md#1 - opened for add

[root@p4hms HostCM]# p4 submit -d "Added initial ReadMe.md file." ReadMe.md
Submitting change 1.
Locking 1 files ...
add //streams/main/root/HostCM/ReadMe.md#1
Change 1 submitted.
```