Perforce Administrative Tips & Tricks
Quick and dirty simplified versioning of files in mass with SaltStack and Perforce.
I have a dedicated Perforce depot used for configuration management.
My basic depot layout:
//sa/... #sa for sysadmin
//sa/cfg/... #Configuration directory for my global template and config files.
//sa/dev/webapp/... #My software under development
//sa/hosts/... #A hosts directory to version files from hosts.
I typically map my hosts out by fqdn.
//sa/hosts/{FQDN}/...
example:
//sa/hosts/flagship.vogon.com/...
//sa/hosts/poetry.vogon.com/...
//sa/hosts/airlock.vogon.com/...
In Perforce the FQDN mapping to a depot path can be achieved by uses of the perforce client.
Client configuration tips configuration management:
- Come up with a naming convention for your perforce clients:
My convention is as follows hostname-{postfix} or appstack-{postfix}
example: p4 -c airlock-cfg
- Map the root of your filesystem to a desired depot path:
I want root "/" on unix host airlock to map //sa/hosts/airlock.vogon.com/...
Lets have a look at the client spec:
p4 client -o airlock-cfg
Client: airlock-cfg
Root: /
View:
//sa/hosts/airlock.vogon.com/... //airlock-cfg/...
- The use of the hostname or the FQDN as the client spec name with a
pre or postfix is very useful, then you want to auto pair the client to
the system you want to version.
Lets run a bunch of simple Perforce versioning commands via Salt cmd.run on a set of hosts
- We need a universal Perforce login ticket that can be used across a set of hosts.
Print a ticket that works on all hosts:
p4 -u cfg-user login -a -p
Enter password:
854B5EA3FB600EF562DFT6Y653C79
- Lets add, edit and submit some files to a class of hosts on the vogon.com domain.
From your salt-master host with already setup salt minions.
We will orchestrate the versioning of files on the salt minions from the salt master.
By running the commands remotely via salt's cmd.run
example:
root@salt-master.vogon.com:# salt 'dns*.vogon.com' cmd.run 'p4 -p poetry.vogon.com:4242 -u cfg-user -P 854...9 -c `hostname`-cfg add /etc/bind/named.conf.options'
This command will mark for add the named.conf.options file on all hosts that's start with the hostname of dns on the vogon.com domain.
As
that we named the Perforce client spec with the systems hostname we can
auto generate the hostname on the fly as we version. note the backtick surrounding the `hostname` command.
This will perform the inline printing of the hostname. This should produce a client spec with a name that matches are naming convention.
Salt cmd.run should run the following Perforce commands correctly on all dns servers.
p4 -p poetry.vogon.com:4242 -u cfg-user -P 854...9 -c dnsmaster-cfg add /etc/bind/named.conf.options
p4 -p poetry.vogon.com:4242 -u cfg-user -P 854...9 -c dnsslave-us-cfg add /etc/bind/named.conf.options
p4 -p poetry.vogon.com:4242 -u cfg-user -P 854...9 -c dnsslave-jp-cfg add /etc/bind/named.conf.options
p4 -p poetry.vogon.com:4242 -u cfg-user -P 854...9 -c dnsslave-eu-cfg add /etc/bind/named.conf.options
Your expected Salt and Perforce output should look like this:
dnsmaster.vogon.com:
//sa/hosts/dnsmaster.vogon.com/etc/bind/named.conf.options#1 - opened for add
dnsslave-us.vogon.com:
//sa/hosts/dnsslave-us.vogon.com/etc/bind/named.conf.options#1 - opened for add
dnsslave-jp.vogon.com:
//sa/hosts/dnsslave-jp.vogon.com/etc/bind/named.conf.options#1 - opened for add
dnsslave-eu.vogon.com:
//sa/hosts/dnsslave-eu.vogon.com/etc/bind/named.conf.options#1 - opened for add
- Lets edit our files in mass from all salt minions.
example:
root@salt-master.vogon.com:# salt 'dns*.vogon.com' cmd.run 'p4 -p poetry.vogon.com:4242 -u cfg-user -P 854...9 -c `hostname`-cfg edit /etc/bind/named.conf.options'
Your expected Salt and Perforce output should look like this:
dnsmaster.vogon.com:
//sa/hosts/dnsmaster.vogon.com/etc/bind/named.conf.options#1 - opened for edit
dnsslave-us.vogon.com:
//sa/hosts/dnsslave-us.vogon.com/etc/bind/named.conf.options#1 - opened for edit
dnsslave-jp.vogon.com:
//sa/hosts/dnsslave-jp.vogon.com/etc/bind/named.conf.options#1 - opened for edit
dnsslave-eu.vogon.com:
//sa/hosts/dnsslave-eu.vogon.com/etc/bind/named.conf.options#1 - opened for edit
- Lets added some comments to our config files.
salt 'dns*.vogon.com' cmd.run 'echo "// This file is versioned" >> /etc/bind/named.conf.options''
- Lets submit our files in mass from all salt minions.
salt 'dns*.vogon.com' cmd.run 'p4 -p poetry.vogon.com:4242 -u cfg-user
-P 854...9 -c `hostname`-cfg submit -d "mass submit of bind9 config files."'
dnsmaster.vogon.com:
Submitting change 239725.
Locking 1 files ...
add //sa/hosts/dnsmaster.vogon.com/etc/bind/named.conf.optionn#1
Change 239725 submitted.
dnsslave-us.vogon.com:
Submitting change 239726.
Locking 1 files ...
add //sa/hosts/dnsslave-us.vogon.com/etc/bind/named.conf.options#1
Change 239726 submitted.
dnsslave-eu.vogon.com:
Submitting change 239727.
Locking 1 files ...
add //sa/hosts/dnsslave-us.vogon.com/etc/bind/named.conf.options#1
Change 239727 submitted.
dnsslave-eu.vogon.com:
Submitting change 239727.
Locking 1 files ...
add //sa/hosts/dnsslave-eu.vogon.com/etc/bind/named.conf.options#1
Change 239727 submitted.
- Lets sync to deploy one of our application stacks for DNS in mass from all salt minions.
example:
root@salt-master.vogon.com:# salt 'dns*.vogon.com' cmd.run 'p4 -p poetry.vogon.com:4242 -u cfg-user -P 854...9 -c dns_webapp-cfg sync //sa/dev/webapp/... '
- Lets logout and invalidate the ticket we used across the set of hosts.
example:
p4 -p poetry.vogon.com:4242 -u cfg-user logout -a
