replace puppet00 with puppet01

This commit is contained in:
2022-02-11 16:31:24 +01:00
parent 19c3ed1ceb
commit 4f843b71a0
12 changed files with 34 additions and 34 deletions
+1 -1
View File
@@ -28,7 +28,7 @@ use the internal one.
======= ======================= ====================== ============= ====================
Source Destination (internal) Destination (external) Ports Purpose
------- ----------------------- ---------------------- ------------- --------------------
any puppet00 puppet00 8080, 8140 Puppet
any puppet01 puppet01 8080, 8140 Puppet
any repo00 repo00 80, 443 Software Packages
======= ======================= ====================== ============= ====================
+1 -1
View File
@@ -19,7 +19,7 @@ other for production, with the following hostnames:
+====================+================+=================+
| sysdb server | boot00-test | boot00 |
+--------------------+----------------+-----------------+
| puppet server | puppet00-test | puppet00 |
| puppet server | puppet00-test | puppet01 |
+--------------------+----------------+-----------------+
| repository server | repo00-test | repo00 |
+--------------------+----------------+-----------------+
+9 -9
View File
@@ -12,7 +12,7 @@ Deploying a new environment requires the following:
- Environment format: ``data-<environment_name>``
- And change permissions accordingly
3. Configuring the environment in Puppet (``puppet00.psi.ch``)
3. Configuring the environment in Puppet (``puppet01.psi.ch``)
Configuring the environment in sysdb
------------------------------------
@@ -75,7 +75,7 @@ The steps to create and configure a new **GIT** project are:
2. Configure *project* permissions as follows:
- ``[data-<environment_name]->[Settings]->[Repository]``, or directly: https://git.psi.ch/linux-infra/data-(environment_name)/settings/repository
- ``[Deploy Keys]`` -> select ``root@puppet00.psi.ch'`` -> click on ``'Enable'``
- ``[Deploy Keys]`` -> select ``root@puppet01.psi.ch'`` -> click on ``'Enable'``
- ``[data-<environment_name]->[Settings]->[Members]``, or directly: https://git.psi.ch/linux-infra/data-(environment_name)/project_members
- Setup specific permissions for specific users or groups. In example:
- Set project ``Master``:
@@ -84,7 +84,7 @@ The steps to create and configure a new **GIT** project are:
- ``[Select members to invite]`` (``ozerov_d``) + ``[Choose a role permission]`` (``Developer``) + ``[Add to project]``
- ``[data-<environment_name]->[Settings]->[Integrations]``, or directly: https://git.psi.ch/linux-infra/data-(environment_name)/settings/integrations
- Add WebHook as follows:
- ``[URL]``: http://puppet00.psi.ch/events/dataupdate
- ``[URL]``: http://puppet01.psi.ch/events/dataupdate
- (Checked) ``[Push events]``. Uncheck the rest.
- ``[SSL verification]`` -> (uncheck) ``[Enable SSL verification]``
- Confirm information from above, and click on ``[Add webhook]`` to add the new WebHook.
@@ -106,8 +106,8 @@ In example::
Configuring the environment in Puppet
-------------------------------------
Current *test* **Puppet** server is ``puppet00-test.psi.ch``. Current *production* **Puppet** server is ``puppet00.psi.ch``. This documentation will take as an example an environment
deployed in the *production* server ``puppet00.psi.ch``.
Current *test* **Puppet** server is ``puppet00-test.psi.ch``. Current *production* **Puppet** server is ``puppet01.psi.ch``. This documentation will take as an example an environment
deployed in the *production* server ``puppet01.psi.ch``.
You must have ``root`` access to the Puppet server in order to be able to configure it.
@@ -115,7 +115,7 @@ Steps are:
1. Login in to the Puppet server::
ssh root@puppet00.psi.ch
ssh root@puppet01.psi.ch
2. Clone the already created **GIT** project to the ``/srv/puppet/data`` path, which contains all the different projects (Bob environments)::
@@ -148,9 +148,9 @@ Add a new file <environment_name>.yaml in to the project::
git commit -a -m "Added first empty file"
git push
After a few seconds (needs time to trigger the change), check in ``puppet00.psi.ch:/srv/puppet/data/<environment_name>`` that file was successfully triggered (copied) to the puppet server from **GIT**::
After a few seconds (needs time to trigger the change), check in ``puppet01.psi.ch:/srv/puppet/data/<environment_name>`` that file was successfully triggered (copied) to the puppet server from **GIT**::
ssh root@puppet00.psi.ch ls /srv/puppet/data/<environment_name>/<environment_name>.yaml
ssh root@puppet01.psi.ch ls /srv/puppet/data/<environment_name>/<environment_name>.yaml
Full real example::
@@ -161,5 +161,5 @@ Full real example::
git commit -a -m "Added first empty file"
git push
sleep 5
ssh root@puppet00.psi.ch ls /srv/puppet/data/meg/meg.yaml
ssh root@puppet01.psi.ch ls /srv/puppet/data/meg/meg.yaml
+3 -3
View File
@@ -7,12 +7,12 @@ Naming convention for servers
Server names have the form ``purpose[0-9][0-9]{,-test}.psi.ch``, where
``purpose`` is the purpose of the server or the service provided by it. Examples are:
- ``puppet00.psi.ch`` is the **productive** puppetmaster
- ``puppet01.psi.ch`` is the **productive** puppetmaster
- ``repo00-test.psi.ch`` is the **test** Yum repository server
When putting system names into configuration files, we always use lower case and
the fully qualified domain name. Good: ``puppet00.psi.ch``. Bad: ``puppet00`` or
``PUPPET00.PSI.CH``.
the fully qualified domain name. Good: ``puppet01.psi.ch``. Bad: ``puppet01`` or
``PUPPET01.PSI.CH``.
Names for programs
+2 -2
View File
@@ -16,7 +16,7 @@ These can be supplied to ``curl(1)`` using the ``--key``, ``--cert``, and
curl --cacert /etc/puppetlabs/puppet/ssl/certs/ca.pem \
--key /etc/puppetlabs/puppet/ssl/private_keys/$(hostname -f).pem \
--cert /etc/puppetlabs/puppet/ssl/certs/$(hostname -f).pem \
https://puppet00.psi.ch:8080/pdb/query/v4/nodes
https://puppet01.psi.ch:8080/pdb/query/v4/nodes
Queries
@@ -38,7 +38,7 @@ First, let's define a function to simplify the queries::
--key /etc/puppetlabs/puppet/ssl/private_keys/$(hostname -f).pem \
--cert /etc/puppetlabs/puppet/ssl/certs/$(hostname -f).pem \
-H content-type:application/json --data "{ \"query\": \"$pql\" }" \
https://puppet00.psi.ch:8080/pdb/query/v4 | json_reformat
https://puppet01.psi.ch:8080/pdb/query/v4 | json_reformat
}
+1 -1
View File
@@ -1,7 +1,7 @@
Network
-------
The production infrastructure systems, eg. ``puppet00.psi.ch``, are not
The production infrastructure systems, eg. ``puppet01.psi.ch``, are not
reachable from all networks. One example would be the DMZ.
To allow the deployment and configuration in such networks, firewall changes are
+2 -2
View File
@@ -11,7 +11,7 @@ workstations via sshfs.
The typical workflow would be:
#. user mounts the environment area (``puppet00:/envs`` on the puppet master) via sshfs on ``~/puppetenv``;
#. user mounts the environment area (``puppet01:/envs`` on the puppet master) via sshfs on ``~/puppetenv``;
#. user create a directory for the new environent (``mkdir ~/puppetenv/issue_x``);
#. after a few seconds ``issue_x`` will be populated with a copy of the content of the the ``preprod`` environment with a proper git branch named ``issue_x``;
#. user edits files in that directory;
@@ -47,6 +47,6 @@ The file should be in the form of::
And should then be passed in the command like::
sshfs -o idmap=file,uidfile=/Users/talamoig/uidmap,nomap=ignore talamo_i@puppet00:/ ~/puppetenvs
sshfs -o idmap=file,uidfile=/Users/talamoig/uidmap,nomap=ignore talamo_i@puppet01:/ ~/puppetenvs
+2 -2
View File
@@ -164,9 +164,9 @@ Create locally a *keys* directory::
#> mkdir -p ~/eyaml/keys
Copy *puppet00:/etc/puppetlabs/keys/eyaml/public_key.pkcs7.pem* to the above folder. Alternatively, you can copy the above public key, which should be the same::
Copy *puppet01:/etc/puppetlabs/keys/eyaml/public_key.pkcs7.pem* to the above folder. Alternatively, you can copy the above public key, which should be the same::
#> scp root@puppet00:/etc/puppetlabs/keys/eyaml/public_key.pkcs7.pem ~/eyaml/keys
#> scp root@puppet01:/etc/puppetlabs/keys/eyaml/public_key.pkcs7.pem ~/eyaml/keys
Go to the *eyaml* directory::
+1 -1
View File
@@ -24,7 +24,7 @@ directly, so not all PSI hosts known to the Satellite belong to the central
Linux environment. In particular the network team has a number of systems there.
Normally only certain infrastructure systems are registered with the Satellite,
at this point the Puppet server (``puppet00.psi.ch``), the repository server
at this point the Puppet server (``puppet01.psi.ch``), the repository server
(``repo00.psi.ch``), and the boot server (``boot00.psi.ch``).
About once a year we report the total number of systems to ETHZ, so they can
+3 -3
View File
@@ -5,7 +5,7 @@ List of systems and their primary role:
* [boot00](boot00) - 129.129.160.210 - Runs sysdb, providing the dynamic iPXE, Grub and kickstart files
* [puppet00](puppet00) - 129.129.160.211 - Runs the puppet server for the RHEL7 infra
* [puppet01](puppet01) - 129.129.160.118 - Runs the puppet server for the RHEL7 infra
* [repo00](repo00) - 129.129.160.212 - RPM/Yum repository server for RHEL7
@@ -38,7 +38,7 @@ Access to the redhat.com knowledge base:
Passwort: Kb4cc3ss
## Metrics
* [Overview Infrastructure](https://metrics.psi.ch/d/1SL13Nxmz/gfa-linux-tabular?orgId=1&from=now-6h&to=now&refresh=30s&var-env=telegraf_pli&var-host=boot00.psi.ch&var-host=influx00.psi.ch&var-host=lxweb00.psi.ch&var-host=metrics00.psi.ch&var-host=puppet00.psi.ch&var-host=pxeserv01.psi.ch&var-host=repo00.psi.ch&var-host=reposync.psi.ch)
* [Overview Infrastructure](https://metrics.psi.ch/d/1SL13Nxmz/gfa-linux-tabular?orgId=1&from=now-6h&to=now&refresh=30s&var-env=telegraf_pli&var-host=boot00.psi.ch&var-host=influx00.psi.ch&var-host=lxweb00.psi.ch&var-host=metrics00.psi.ch&var-host=puppet01.psi.ch&var-host=pxeserv01.psi.ch&var-host=repo00.psi.ch&var-host=reposync.psi.ch)
# Procedures
@@ -63,4 +63,4 @@ The signing is done like this:
ssh-keygen -s user-ca -I <username> -n <username> -V +55w id_ed25519.pub
```
More details on how this works can be found in this article: https://engineering.fb.com/2016/09/12/security/scalable-and-secure-access-with-ssh/
More details on how this works can be found in this article: https://engineering.fb.com/2016/09/12/security/scalable-and-secure-access-with-ssh/
+2 -2
View File
@@ -10,6 +10,6 @@ Generally speaking, a reinstall can be done without doing anything other than do
- somewhat unrelated to the other points, but a similar case is the ssh server keys, which are stored on the puppet server and are put in place by puppet agent, so they remain unchanged under all reinstall scenarios
It's already documented (https://git.psi.ch/linux-infra/docs/wikis/puppet00) how puppet server certs can be deleted at https://puppet00.psi.ch/ and on that page, the command to delete the client cert is specified.
It's already documented (https://git.psi.ch/linux-infra/docs/wikis/puppet00) how puppet server certs can be deleted at https://puppet01.psi.ch/ and on that page, the command to delete the client cert is specified.
To access https://puppet00.psi.ch one needs to authenticate with your username/password. The server uses a invalid https certificate that is not accepted by modern safari/chrome any more. Use Firefox as a workaround.
To access https://puppet01.psi.ch one needs to authenticate with your username/password. The server uses a invalid https certificate that is not accepted by modern safari/chrome any more. Use Firefox as a workaround.
@@ -9,11 +9,11 @@ Other optional environments can be arbitrarily created and immediately used unde
* /srv/puppet/code/dev/envs/
At https://puppet00.psi.ch/ , a small web app to delete server side certificates is made available. The authentication uses LDAP against the AD, but access rights are granted from the /etc/httpd/conf.d/ssl.conf
At https://puppet01.psi.ch/ , a small web app to delete server side certificates is made available. The authentication uses LDAP against the AD, but access rights are granted from the /etc/httpd/conf.d/ssl.conf
# Branches
You can create a branch to develop new code from the master branch of the puppet repository. To test the code, a directory with the same name as the branch can be created at puppet00:/srv/puppet/code/dev/envs/ . Upon creating the directory, preprod gets rsynced in here. If the branch alrady exists and if it's to be pulled, that can be done via the command:
You can create a branch to develop new code from the master branch of the puppet repository. To test the code, a directory with the same name as the branch can be created at puppet01:/srv/puppet/code/dev/envs/ . Upon creating the directory, preprod gets rsynced in here. If the branch alrady exists and if it's to be pulled, that can be done via the command:
```
git pull origin xyz
@@ -38,15 +38,15 @@ The correct way to pull the modules is with the use of librarian. However, at th
The solution is to always run librarian with the lock file removed:
```
[root@puppet00 prod]# cd /srv/puppet/code/base/prod
[root@puppet00 prod]# rm -f Puppetfile.lock
[root@puppet00 prod]# /opt/puppetlabs/puppet/bin/librarian-puppet install --path=code/modules
[root@puppet01 prod]# cd /srv/puppet/code/base/prod
[root@puppet01 prod]# rm -f Puppetfile.lock
[root@puppet01 prod]# /opt/puppetlabs/puppet/bin/librarian-puppet install --path=code/modules
```
This way the latest commit will be pulled for all incorrectly defined modules.
# Hiera / data-xxx
The data-xxx repositories have a webhook configured that points to http://puppet00.psi.ch/events/dataupdate
The triggered webhook code can be found on puppet00 at /var/www/webhook/app/webhook.py
The data-xxx repositories have a webhook configured that points to http://puppet01.psi.ch/events/dataupdate
The triggered webhook code can be found on puppet01 at /var/www/webhook/app/webhook.py
This webhook checks out the data repositories in /srv/puppet/data