zimoch/Controls-docs
0
0
Fork 0
forked from Controls/gitea-pages
Code Pull Requests Actions Activity

cleanup

Browse Source
This commit is contained in:
ebner
2023-02-01 13:42:24 +01:00
parent cd03a02433
commit d311b6e246
15 changed files with 7 additions and 3838 deletions
Download Patch File Download Diff File Expand all files Collapse all files
_toc.yml
+1 -1
View File
@@ -22,7 +22,7 @@ parts:
chapters:
- file: infrastructure-guide/infrastructure_systems
sections:
- file: infrastructure-guide/pxeserv01
- file: infrastructure-guide/boot_server
- file: infrastructure-guide/sysdb_server
- file: infrastructure-guide/puppet01
- file: infrastructure-guide/repo00
admin-guide/deployment/_static/legacy_boot.puml
+1 -1
View File
@@ -3,7 +3,7 @@
actor admin
participant "BIOS Node\n(legacy boot)" as bootnode
participant "QIP DHCP" as dhcp
participant "pxeserv01.psi.ch" as pxeserver
participant "boot.psi.ch" as pxeserver
participant "sysdb.psi.ch" as sysdb
participant "repo00.psi.ch" as reposerver
admin-guide/deployment/_static/uefi_boot.puml
+1 -1
View File
@@ -3,7 +3,7 @@
actor admin
participant "UEFI Node" as bootnode
participant "QIP DHCP" as dhcp
participant "pxeserv01.psi.ch" as pxeserver
participant "boot.psi.ch" as pxeserver
participant "sysdb.psi.ch" as sysdb
participant "repo01.psi.ch" as reposerver
admin-guide/legacy/installation.rst
-65
View File
@@ -1,65 +0,0 @@
Installation
============
This section describes the various installation methods, e.g. PXE.
PXE Server
----------
The PXE server is ``pxeserv01.psi.ch``, running SL 5.1.
Directory structure
~~~~~~~~~~~~~~~~~~~
The usual ``/tftpboot/pxelinux.cfg`` setup. The ``pxelinux.cfg``
directory contains the following subdirectories:
- ``Boot``: could be Windows-related
- ``centos``: CentOS 7.0, 7.1, and 7.2
- ``dl``: diskless systems
- ``pxelinux.cfg``: PXELINUX configuration
- ``scientific``: Scientific Linux, 3.01 -> 7.0, partly obsolete
- ``tools``:
PXELINUX
--------
The PXELINUX configuration files are in ``pxeserv01:/tftpboot``.
The ``default`` file currently contains 127 labels.
Scientific Linux 6, 64bit
~~~~~~~~~~~~~~~~~~~~~~~~~
One thing to note is that the
[Kickstart file](http://linux.web.psi.ch/kickstart/configs/sl64-64-desk-stable-ks.cfg)
is modified during installation by the
[``ks_pre.sh``](http://linux.web.psi.ch/dist/scientific/64/kickstart/bin/ks_pre.sh)
script.
Kickstart
---------
The documentation on Kickstart files is currently based on
``sl64-64-desk-stable-ks.cfg``, the default Kickstart file for SL6.
In the ``%pre`` section a distribution-specific script ``ks_pre.sh``
is downloaded and executed. Errors are not handled. The script
*modifies* the Kickstart file. The latter contains markers
``#BEGIN_MAIN`` and ``#END_MAIN`` to mark the region to be modified.
Custom keys
~~~~~~~~~~~
The Kickstart files defines variables ``INIT_KEYS`` and
``APPEND_KEYS`` and exports them for use by ``ks_pre.sh``. The latter
attempts to download an environment file and a script
``custom_pre.sh`` for each key and sources them.
The custom key related files are stored below
``/afs/psi.ch/software/linux/dist/scientific/$OSVERSION/custom/``.
Examples for custom keys are ``DesktopTesting`` and ``DesktopStable``.
admin-guide/legacy/misc/prepareanewslrelease.rst
-162
View File
@@ -1,162 +0,0 @@
Prepare a new release
=====================
Introduction
------------
This document describes the preparation of a new SLP major or minor
release for SL >= 5.4.
Requirements
------------
Before you start you need a clean copy of the original SL repositories
of interest from http://www.scientificlinux.org.
The SL repositories shall be mirrored to our AFS mirror on its own
volume, e.g. `/afs/psi.ch/software/mirror/scientific/54/` is on AFS
volume `sw.mirror.sl54.nb`.
However, the mirror is usually made automatically by the script
`/afs/psi.ch/software/mirror/scripts/mirror.sh` which is run by cron
on pxeserv01. To add a new distribution to the mirror script you have
to edit the file `/afs/psi.ch/software/mirror/scripts/mirror.conf`.
You also need a separate AFS distribution volume, e.g. `sw.dist.sl54`
for `/afs/psi.ch/software/linux/dist/scientific/54`.
Once this is done, you're ready to start with the Procedure section.
Procedure
---------
1. Go to the SL distribution B<top> directory, change to the
subdirectory `scripts` and run the following scripts::
# cd /afs/psi.ch/software/linux/dist/scientific/
# cd scripts/Sl60/
# sh 1-create_the_new_dist-config_file.sh <new_osversion>
# sh 2-copy_the_kernel_and_initrd_for_tftp_boot.sh
# sh 3-copy_the_puppet_environment_for_desktop.sh # If a new one should be used,
# usually only for major release
# changes
# Note: Some of the files might need some manual customization, e.g.
#
# module_gdm (pictures)
# module_splash (pictures)
# module_background_image (pictures)
# module_buildsystem
# sh 4-create_new_dist_directory_structure.sh <new_osversion> <pre_osversion>
### Check and edit the new files if necessary, especially the following ones:
# scripts/dist-config
# scripts/KERNEL_MODULES_TO_BUILD/sl6.i386.kms-to-be-built
# scripts/KERNEL_MODULES_TO_BUILD/sl6.x86_64.kms-to-be-built
# scripts/build-gpfs.sl6x.sh
# scripts/build-openafs.sl6x.i686.sh
# scripts/build-openafs.sl6x.x86_64.sh
# scripts/copy_the_sl_base_repos_from_the_local_mirror.sh
# scripts/rsync_security_updates_to_all_directories.sh
<pre_osversion> is the distribution which serves as a template for
<new_osversion>.
The scripts will prepare most of the stuff automatically based on
the previous version. Some of the new files, however, still have to
be edited manually.
2. Go to the SL distribution directory, change to the subdirectory
`scripts` and run the following scripts::
# cd /afs/psi.ch/software/linux/dist/scientific/60/scripts/
2.1 Copy the SL Base Repos
The script below copies the sl6base repository from the mirror on
AFS to the dist SL6 directory taking into account the
`rsync_exclude.rpmlist`, i.e. not all RPMS will be copied. To keep
the repodata consistent with the RPMS in the Packages directory,
the repodata has to be updated, too, by running the second script
shown here::
# sh copy_the_sl_base_repos_from_the_local_mirror.sh
# sh run_createrepo_on_base_i386.sh #sl64: still to do
# sh run_createrepo_on_base_x86_64.sh #sl64: still to do
2.2 Copy the Security Updates::
# sh rsync_security_updates_to_all_directories.sh
2.3 Build kernel module if minor release
If you prepare a new major release skip this section.
If you prepare a new minor release you already have build systems
where you can build kernel modules.
Thus check whether you have to build at least the openafs and the
gpfs modules. If the kernel versions of this and the previous SL
minor versions do not differ you should already have the modules
copied to e.g. the nonfree and psi repos, then there's nothing to
do here.
2.4 Update The Symbolic Links in RPMS_all::
# sh update_symlinks_in_RPMS_all.sh
3. Create new snaphots, release UNSTABLE and set the initial PSI
version.
# ./create_new_snapshots.sh alldirs > \
# INITIAL_LOG/2011-02-25-create_new_snapshots.log 2>&1
# ./release_unstable.sh
# ./create_new_psi_version.sh
# ./create_file_psiversion-info.sh
6. Write the new kickstart conig files.
Goto the kickstart config directory and use one of the old
kickstart config files as a template::
# cd /afs/psi.ch/software/linux/kickstart/configs/
8. Make the new entries in the tftpd file.
Goto the tftpd directory and edit the file default::
# cd /afs/psi.ch/service/linux/tftpboot/pxelinux.cfg/
# vi default
#<<< sl64: hereiam:
#<<< to do: fix /usr/bin/psi-fix_file_permission, module_localadmin
9. Now perform first installation tests and debug where necessary.
10. If you prepare a new major release, install new build systems.
12. If you prepare a new major release, go to
`/afs/psi.ch/project/linux/dist` and create the directory
structure below for the RPM build environment::
slp6
|-- RPMS/
| |-- i386/
| |-- i486/
| |-- i586/
| |-- i686/
| |-- noarch/
| `-- x86_64/
`-- SRPMS/
14. Build kernel modules.
15. Also get new software versions for non SL repos (psi, others,
etc.).
16. Again create new snapshots and a new PSI version.
17. Now perform the second test installation and debugging suite.
admin-guide/legacy/misc/projectpsi-puppet1.rst
-1070
View File
File diff suppressed because it is too large Load Diff
admin-guide/legacy/misc/psi-puppet2_installation.rst
-609
View File
@@ -1,609 +0,0 @@
Installation `psi-puppet2`
==========================
References
----------
- https://wiki.intranet.psi.ch/AIT/PuppetServer2009
- http://reductivelabs.com/trac/puppet/wiki/PluginsInModules
Introduction
------------
This document describes the Installation of the new puppet server
psi-puppet2, which replaces the puppet server running on pxeserv01.
The psi-puppet2 server is an interim solution for the pxeserv01
replacement for the following reasons:
- The puppet service on pxeserv01 is very unstable.
- The performance on pxeserv01 is very bad, what makes work almost impossible.
- The psi-puppet1 server is not ready for production yet.
The new system will be setup as a 32 bit SL5 server with the latest
puppet server package and dependencies installed.
The puppet server configuration is the same as the one on pxeserv01.
**Note**: Don't confuse psi-puppet2 with psi-puppet1, which not only
is thought as a replacement of the puppet server on pxeserv01 but also
comes with a reimplementation of the whole puppet configuration,
whereas psi-puppet2 takes over the puppet configuration from
pxeserv01.
Description of the Basic Server Setup
-------------------------------------
- Hardware
Dell Power Edge 1750
- Operating System
SL51 32 bit Server
- Network configuration
Static IP for Production Server: 129.129.190.160/24
Hostname: psi-puppet2.psi.ch
- Required RPMS
- puppet-server (http://download.fedora.redhat.com/pub/epel/5/i386/repoview/)
- augeas-libs
- facter
- puppet (http://download.fedora.redhat.com/pub/epel/5/i386/repoview/)
- ruby
- ruby-augeas
- ruby-libs
- ruby-shadow
- ruby-irb (required for reading help)
- ruby-rdoc (required for reading help)
Procedure
---------
Setup The Puppet Server
~~~~~~~~~~~~~~~~~~~~~~~
Install The Puppet Server Software
..................................
Use the yum repositories `/etc/yum.repos.d/epeli386.repo` and
`/etc/yum.repos.d/epelx86_64.repo` to download and install the latest
puppet packages::
[epeli386]
name=epel i386
baseurl=http://download.fedora.redhat.com/pub/epel/5/i386/
enabled=0
Install the puppet-server package. Dependencies will be resolved::
# yum --enablerepo=epeli386 install puppet-server
...
Dependencies Resolved
=============================================================================
Package Arch Version Repository Size
=============================================================================
Installing:
puppet-server noarch 0.24.8-1.el5.1 epel 26 k
Installing for dependencies:
augeas-libs i386 0.5.1-1.el5 epel 196 k
facter noarch 1.5.5-1.el5 epel 54 k
puppet noarch 0.24.8-1.el5.1 epel 542 k
ruby i386 1.8.5-5.el5_2.6 sl5update 279 k
ruby-augeas i386 0.2.0-1.el5 epel 17 k
ruby-libs i386 1.8.5-5.el5_2.6 sl5update 1.6 M
ruby-shadow i386 1.4.1-7.el5 epel 9.5 k
Transaction Summary
=============================================================================
Install 8 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
...
For later use, download the required RPMS and copy them to our yum
repository, see section `Put Puppet Related RPMS To Our Yum
Repository` below.
Configure The Puppet Server
...........................
Use the puppet server configuration of pxeserv01 on psi-puppet2.
The configuration files of the puppet server, directory
`/etc/puppet/`, are located on AFS, see section `Mount AFS Volumes`.
The log is on the local disk in `/var/log/puppet`. To set the logfile
edit the line `PUPPETMASTER_OPTS` in
`/etc/rc.d/init.d/puppetmaster`. For testing also the debug option
`-d` is enabled::
PUPPETMASTER_OPTS="-v -d -l /var/log/puppet/puppetmaster.log"
Enable puppetmaster in runlevels 3, 4 and 5::
# chkconfig --levels 345 puppetmaster on
Mount AFS Volumes on Puppet Server
..................................
The puppet server configuration files as well as the puppet manifests
for clients are located on AFS.
AFS is already mounted as `/afs` in this default SL5 server installation::
# mount
...
AFS on /afs type afs (rw)
Now, we want to remount `/afs/psi.ch/service/linux/puppet/etc/puppet`
on `/etc/puppet`. Therefor the mount option `bind` is used, which
facilitates to remount parts of already mounted filesystems on an
alternative location in the file hierarchy.
As shown below we do the remount in `/etc/rc.local`, which is executed
after all the other init scripts::
#!/bin/sh
touch /var/lock/subsys/local
# Puppet
mount -o bind /afs/psi.ch/service/linux/puppet/etc/puppet /etc/puppet
# Restart Services depending on afs mounts
/etc/init.d/puppetmaster restart
Before the `rc.local` script can be applied the proper AFS permissions
have to be set.
Check the AFS permissions::
# [gasser_m@pc7377 ~]
# fs la /afs/psi.ch/service/linux/
Access list for /afs/psi.ch/service/linux/ is
Normal rights:
svc_linux:tools l
svc_linux:puppet l
svc_linux:readonly rl
svc_linux:pxe l
svc_linux rlidwka
Create a new AFS group for the puppet server::
# pts creategr svc_linux:puppet_hosts -owner svc_linux
group svc_linux:puppet_hosts has id -10851
Add the IP of psi-puppet2 to this group::
# pts adduser 129.129.190.160 svc_linux:puppet_hosts
Set the AFS permissions::
# fs sa /afs/psi.ch/service/linux/ svc_linux:puppet_hosts l
# fs sa /afs/psi.ch/service/linux/puppet/ svc_linux:puppet_hosts rl
# fs sa /afs/psi.ch/service/linux/puppet/etc svc_linux:puppet_hosts rl
# fs sa /afs/psi.ch/service/linux/puppet/var svc_linux:puppet_hosts rl
# fs sa /afs/psi.ch/service/linux/puppet/etc/puppet svc_linux:puppet_hosts rl
Recursively set the same permissions to all subdirectories underneath
`/afs/psi.ch/service/linux/puppet/etc/puppet`::
# cd /afs/psi.ch/service/linux/puppet/etc/puppet
# find -noleaf -type d -exec fs sa {} svc_linux:puppet_hosts rl \;
Then restart the AFS service::
# service afs restart
Finally, run the `rc.local` script or just reboot psi-puppet2 to see
whether everything comes up.
Allow User Login Access To psi-puppet2
......................................
To enable remote login via ssh and execution of root commands via
sudo, the following files have to be edited.
- `/etc/passwd`
- `/etc/shadow`
- `/etc/security/ssh.allow`
- `/etc/group`
- `/etc/hosts.allow`
- `/etc/sudoers`
passwd::
gasser_m:!:2374:840:Gasser Marc:/afs/psi.ch/user/g/gasser_m:/bin/bash
kapeller:!:3804:9102:Rene Kapeller:/afs/psi.ch/user/k/kapeller:/bin/bash
billich:!:3830:840:Heinrich Billich:/afs/psi.ch/user/b/billich:/bin/bash
markushin:!:3883:840:Valeri Markushin:/afs/psi.ch/user/m/markushin:/bin/bash
shadow::
gasser_m:NP:::::::
kapeller:NP:::::::
billich:NP:::::::
markushin:NP:::::::
group::
ait::840
sls::9102
ssh.allow::
kapeller
billich
markushin
gasser_m
hosts.allow::
sshd: ... pc7377 pc7377.psi.ch gfalc05 gfalc05.psi.ch pc4568 pc4568.psi.ch
Configuring Puppet Reporting
............................
There are a number of different report processors available on the
master. The default report, store, simply stores the report file on
the disk.
By default, each client is configured not to report back to the
master. It has to be enabled either by the report option in
`puppet.conf` or using `--report` on the command line.
`/etc/puppet/puppet.conf`::
[puppetd]
report = true
Command line::
# puppetd --report
Store Report Processor
,,,,,,,,,,,,,,,,,,,,,,
Enable the store reports by using the `reports` configuration option
in the puppemasterd section of the `puppet.conf` file on the master.
`/etc/puppet/puppet.conf`::
[puppetmasterd]
reports = store
The default reports directory is $vardir/reports.
Rrdgraph Report Processor
,,,,,,,,,,,,,,,,,,,,,,,,,
To enable the `rrdgraph` reports, `rrdtool` and `rrdtool-ruby`
packages have to be installed.
The packages are available from the the `psi-beta` repository, they
originate from the repository shown below.
`/etc/yum.repos.d/epeli386.repo`::
[epeli386]
name=epel i386
baseurl=http://download.fedora.redhat.com/pub/epel/5/i386/
enabled=0
# yum install rrdtool rrdtool-ruby
Then, configure `puppet.conf` by adding the lines shown below in the
corresponding section. Here store and rrdgraph are enabled.
`/etc/puppet/puppet.conf`::
[puppetmasterd]
reports = store,rrdgraph
rrddir = $vardir/rrd
rrdinterval = $runinterval
rrdgraph = true
Install the Ganglia Monitor Daemon
..................................
Install `ganglia-gmond` and add the configuration file shown below::
# yum install ganglia-gmond
Use the same `/etc/gmond.conf` as on psi-puppet1::
# /etc/init.d/gmond start
For the ganglia server configuration ask Valeri Markushin.
See puppet at [[http://129.129.190.27/ganglia/][http://129.129.190.27/ganglia/]].
Setup The Puppet Client
~~~~~~~~~~~~~~~~~~~~~~~~
Either install or update the puppet package on a client::
# yum --enablerepo=psi-beta install puppet
# yum --enablerepo=psi-beta update puppet
Test The Puppet Clients
~~~~~~~~~~~~~~~~~~~~~~~
To find out which versions of puppet servers and clients are
compatible to each other and in which order they should be updated,
the following tests are performed.
Test the Old Client With The New Server
.......................................
Set the new server `psi-puppet2.psi.ch` in `/etc/puppet/puppet.conf`,
remove the certificate and run puppetd::
# [root@vsl5132de-ut]
# cd /var/puppet/
# rm -rf ssl/
# puppetd --test
Ok.
Test the New Client With The New Server
.......................................
Update the puppet client. Set the new server `psi-puppet2.psi.ch` in
`/etc/puppet/puppet.conf`, remove the certificate and run puppetd::
# [root@vsl5132de-ut]
# yum --enablerepo=psi-beta update puppet
# cd /var/puppet/
# rm -rf ssl/
# puppetd --test
Ok.
Test the New Client With The Old Server
.......................................
Update the puppet client. Then set the old server `pxeserv01.psi.ch`
in `/etc/puppet/puppet.conf`, remove the certificate and run puppetd::
# [root@vsl5132de-ut]
# yum --enablerepo=psi-beta update puppet
...
=============================================================================
Package Arch Version Repository Size
=============================================================================
Updating:
puppet noarch 0.24.8-1.el5.1 psi-beta 542 k
Installing for dependencies:
augeas-libs i386 0.5.1-1.el5 psi-beta 196 k
ruby-augeas i386 0.2.0-1.el5 psi-beta 17 k
ruby-shadow i386 1.4.1-7.el5 psi-beta 9.5 k
Updating for dependencies:
facter noarch 1.5.5-1.el5 psi-beta 54 k
Transaction Summary
=============================================================================
Install 3 Package(s)
Update 2 Package(s)
Remove 0 Package(s)
...
# cd /var/puppet/
# rm -rf ssl/
# puppetd --test
Not ok. A lot of error messages appear. It seems the new client is not
compatible to the old server!
Conclusion
..........
First update the server, then the client.
So, when you have an old client addressing the new server for tests,
and finally you wanna change it back to the old server, this should
work by just modifying `/etc/puppet/puppet.conf` on the client.
However, once you updated the client you can not go back to the old
server, unless you downgrade the client --- with yum this means
removing the new client and reinstalling the old one.
Put Puppet Related RPMS To Our Yum Repository
---------------------------------------------
To have a consistent puppet installation on our hosts we put them to
our repository.
Use yumdowloader, package yum-utils, to download puppet related RPMS::
# root@psi-puppet2
# yum install yum-utils
# yumdownloader --enablerepo=epeli386 puppet-server augeas-libs facter \
# puppet ruby-augeas ruby-shadow
# yumdownloader --enablerepo=epelx86_64 augeas-libs ruby-augeas ruby-shadow
**Note**: There seem to be only i386 and noarch versions of the
required RPMS.
Before they are linked into the latest `testing` and `current`
repositories they should be tested. So copy them to the `psi-beta`
repository first::
# scp *rpm gasser_m@tux50:/afs/psi.ch/software/linux/dist/scientific/51/beta
# gasser_m@tux50
# cd /afs/psi.ch/software/linux/dist/scientific/51/beta
# createrepo .
To test the puppet clients see section `Test The Puppet Clients`.
If the tests passed successfully copy them to the `others` repository
and create symbolic links to `testing` and `current` to make them
available::
# [root@psi-puppet2]
# scp *rpm gasser_m@tux50:/afs/psi.ch/software/linux/dist/scientific/51/others/all
# gasser_m@tux50
# cd /afs/psi.ch/software/linux/dist/scientific/51/others/all
# createrepo .
Update Puppet
-------------
Keep the following order.
- Update the puppet server.
- Update the puppet client.
Update The Puppet Server
~~~~~~~~~~~~~~~~~~~~~~~~
At the time of writing the latest Puppet version 0.25.1 was only
available at http://tmz.fedorapeople.org/repo/puppet/epel/5/i386/.
Download the required packages to SL51 psi-beta repository first::
# wget http://tmz.fedorapeople.org/repo/puppet/epel/5/i386/puppet-server-0.25.1-0.3.el5.noarch.rpm
# wget http://tmz.fedorapeople.org/repo/puppet/epel/5/i386/puppet-0.25.1-0.3.el5.noarch.rpm
Then login to a test server and stop the puppetmaster daemon::
# /etc/init.d/puppetmaster stop
Because the /etc/puppet/ is on AFS, root has no write permissions.
So, first umount the etc/puppet from AFS, then run `yum update` using
the psi-beta repository, and remount etc/puppet::
# umount /etc/puppet
# yum --enablerepo=psi-beta update puppet-server
# mount -o bind /afs/psi.ch/service/linux/puppet/etc/puppet /etc/puppet
Set the following options in /etc/init.d/puppetmaster::
PUPPETMASTER_OPTS="-v -d -l /var/log/puppet/puppetmaster.log"
Finally, restart the service and test it with a client::
# /etc/init.d/puppetmaster start
Login to a client and run puppetd::
# puppetd --test
Update The Puppet Client
~~~~~~~~~~~~~~~~~~~~~~~~
Basically, the 0.24.x clients should be compatible to the 0.25.x
server. Though, there are some changes between the versions, that
might cause troubles. Thus, the puppet clients should be updated, too.
On a SL51 client run::
# yum --enablerepo=psi-beta update puppet
On a SL54 client run::
# yum update puppet
As soon as the client is updated, its `puppet.conf` needs some
modifications, because of the "factsync" option which is deprecated
and replaced by "pluginsync" in the 0.25.x versions.
`/etc/puppet/puppet.conf` on a 0.25.x client: "factsync" is replaced
by "pluginsync", factpath is set (not clear whether the latter is
necessary)::
[main]
vardir = /var/puppet
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
pluginsync = true
factpath = $vardir/lib/facter
environment = DesktopSL5Unstable
[puppetd]
report = true
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
server = psi-puppet1.psi.ch
Further the directory structure on the server for placing facts
changed. The new structure if using modules and environments is
illustrated below taking the environment "DesktopSL5Unstable" as an
example:
The modulepath for DesktopSL5Unstable is::
modulepath = /var/puppet/environments/DesktopSL5Unstable/modules
A stub module called "custom" has to be created in the "$modulepath"
subdirectory to keep the files::
$modulepath/custom/
`-- lib/
|-- facter/
| `-- sysconfig_psi_desktop.rb
`-- puppet/
|-- provider/
`-- type/
This subdirectory tree under custom is implicitly searched by the
puppet server.
**Notes**:
If you have both, the new and the old variant to keep facts, option
"pluginsync" enabled, only the new script location will be considered.
If you run only the old variant to keep facts::
$modulepath/facts/files/somescript.rb
with option "factsync" enabled, they will be loaded giving out a
warning "... use pluginsync instead of factsync ..."
For more information see the
http://reductivelabs.com/trac/puppet/wiki/PluginsInModules.
admin-guide/legacy/misc/puppet-trouble-shooting-in-twiki.rst
-145
View File
@@ -1,145 +0,0 @@
Puppet Trouble-shooting in TWiki
================================
Introduction
------------
This is the location were to post puppet problems and solutions at AIT
and GFA.
Please use the following format according the first entry below:
- HEADING2: Error (HOSTNAME): "BEGIN OF ERROR MESSAGE ..."
*(The HOSTNAME in parentheses is optional, if the problem might affect any host.)*
- HEADING3: Context, a short description in what situation the error appears.
- HEADING3: Solution, if known, provide a possible solution to fix the problem.
Puppet Server Errors
--------------------
Error (pxeserv01): "Starting puppetmaster: Could not prepare for execution ..."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Context
.......
The puppetmaster daemon on pxeserv01 received an unattended SIGTERM
and stopped. Maybe there is a self signed certificate which expired
or something. Anyway, restarting failed showing the following error::
# [root@pxeserv01 puppet]# /etc/init.d/puppetmaster start
Starting puppetmaster: Could not prepare for execution: Retrieved certificate does not \
match private key; please remove certificate from server and regenerate it with the current key
Solution
........
Create a new certificate for the server.
**IMPORTANT NOTE**: Recreating a new certificate for the server showed
that the clients which still have the old certificate of the server
can not connect anymore to it. Thus you need to be sure you have a
way to update the certificate of the server on the clients before
applying this. Eventually, a better solution might be to just sign
the old server certificate with `puppetca`. It was not tested whether
this works, too.
Remove /var/puppet/ssl/ on the server::
# rm -rf /var/puppet/ssl/
Then try to start puppetmaster, what failed again, but recreated the
ssl subdirectory and its content::
# /etc/init.d/puppetmaster start
Eventually, sign the certificate for pxeserv01 itself::
# puppetca --sign pxeserv01.psi.ch
# /etc/init.d/puppetmaster start
Via our management console the certificates on the clients had to be
deleted, in order they can retrieve the new server certificate::
# for i in host1 host2 ...
# do
# ssh -o ConnectTimeout=1 root@$i rm -rf /var/puppet/ssl/
# done
Puppet Client Errors
--------------------
Error: "Could not request certificate: ..."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Context
.......
Running puppetd on any client might fail showing the following error::
# puppetd --test
err: Could not request certificate: Retrieved certificate does not match private key;
please remove certificate from server and regenerate it with the current key
Exiting; failed to retrieve certificate and watiforcert is disabled
Solution
........
The problem is that for what reason ever the client certificate is not
valid, i.e. it does not match its copy stored on the puppet server.
Usually this happens when a host is reinstalled keeping its original
hostname. During the initial puppetd run, the client requests a new
certificate from the server, which denies, because there is already a
certificate on the server for that hostname.
To fix this you have to delete the old certificate on client and
server.
On the server::
# puppetca --clean HOSTNAME.psi.ch
HOSTNAME.psi.ch
notice: Removing file Puppet::SSL::Certificate HOSTNAME.psi.ch at
'/var/puppet/ssl/ca/signed/mpc1273.psi.ch.pem'
If this notice does not appear, the certificate was not deleted.
On the client::
# rm -rf /var/puppet/ssl/
Then, run puppetd again::
# puppetd --test
Error: "notice: Run of Puppet configuration client already in progress; skipping ..."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Context
.......
Running puppetd on any client might fail showing the following error,
even `ps ax | grep puppetd` does not show a running puppet process::
# puppetd --test
notice: Run of Puppet configuration client already in progress; skipping
Solution
........
There is still an old lock file `/var/puppet/state/puppetdlock`.
Remove the lock file and run puppetd again::
# rm /var/puppet/state/puppetdlock
admin-guide/legacy/misc/puppetmasteratpsi.rst
-76
View File
@@ -1,76 +0,0 @@
Puppetmaster At PSI
===================
Procedure
---------
Manual Check Whether Puppetmaster Is Running
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contemporary, the `puppetmasterd` process often crashes and automatic
restart fails. Thus it has to be started manually again. Therefore login
to `pxeserv01`, check whether the process is still running and if not,
restart `puppetmasterd`.
Check whether the `puppetmasterd` is running::
[root@pxeserv01 ~]# ps ax | grep puppet
549 pts/0 S+ 0:00 grep puppet
6641 ? S 7:53 /bin/bash ./test-and-restart-puppetmaster.sh
It's not running.
Check the logfile. The logfile is situated on AFS::
# tail /afs/psi.ch/service/linux/puppet/var/log/puppetmaster.log
...
Mon Jan 26 09:22:27 +0100 2009 Puppet (notice): Compiled configuration for slsnedi1.psi.ch in 0.09 seconds
Mon Jan 26 09:24:55 +0100 2009 Puppet (notice): Caught TERM; shutting down
Mon Jan 26 09:24:55 +0100 2009 Puppet (notice): Shutting down
Mon Jan 26 09:24:55 +0100 2009 Puppet (err): Could not remove PID file /var/run/puppet/puppetmasterd.pid
Mon Jan 26 09:25:01 +0100 2009 Puppet (err): Could not create PID file: /var/run/puppet/puppetmasterd.pid
In this case remove `/var/run/puppet/puppetmasterd.pid` and restart the server::
# rm /var/run/puppet/puppetmasterd.pid
# /etc/init.d/puppetmaster restart
Check again whether the `puppetmasterd` is running::
# [root@pxeserv01 ~]# ps ax | grep puppet
549 pts/0 S+ 0:00 grep puppet
6641 ? S 7:53 /bin/bash ./test-and-restart-puppetmaster.sh
31599 ? Ssl 0:03 /usr/bin/ruby /usr/sbin/puppetmasterd \
--logdest=/afs/psi.ch/service/linux/puppet/var/log/puppetmaster.log
Finally, test it on a client::
# [root@pc7377 ~]# psi-puppet
...
puppetd was running successfully
Automatic Check Whether Puppetmaster Is Running
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On `pxeserv01` the script `/root/test-and-restart-puppetmaster.sh`
continuously observes the `puppetmasterd` and should restart it when
it's hanging.
The script is started in the following way::
# [root@pxeserv01 etc]# nohup /root/test-and-restart-puppetmaster.sh &
The output is written to:
- `$HOME/nohup.out`
The logfile.
- `/dev/shm/puppetwatch.1`
- `/dev/shm/puppetwatch.2`
admin-guide/legacy/misc/updatesl57.rst
-282
View File
@@ -1,282 +0,0 @@
Update SL57 and later i386 and x86_64
=====================================
Introduction
------------
Keep the following order:
- Get the latest security updates from the SL mirror for the
"update.$ARCH" repository.
- Build kernel modules.
- Get updates for the "psi" repository.
- Get updates for the "other" repository.
- Get updates for the "nonfree" repository.
- Create new snapshots.
- Release "unstable" from new snapshots.
- Create a new PSI version.
- Release "testing".
- Release "stable".
Update The Different Repositories
---------------------------------
Get the Latest Security Update RPMS From SL Mirror
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Get the latest security update RPMS from the local SL57 mirror for
both architectures, i386 and x86_64, by invoking
`rsync_security_updates_to_all_directories.sh` on tux50.
They will be copied to the corresponding `.../updates.${ARCH}/all/`
directories. This will take some time::
# cd /afs/psi.ch/software/linux/dist/scientific/57/scripts/
# nohup ./rsync_security_updates_to_all_directories.sh > \
# UPDATE_LOG/$(date +%Y-%m-%d)-rsync_security_updates_to_all_directories.log 2>&1 &
Then, check for errors in the log file::
# grep -i error UPDATE_LOG/20091221-rsync_security_updates_to_all_directories.log
...
Finally, run `update_symlinks_in_rpms_all.sh` to keep all symlinks in
the directory
`/afs/psi.ch/software/linux/dist/scientific/57/RPMS_all/` up to date.
The script removes dead links and creates new links to the new RPMS.
It is basically not necessary for running PSI updates, rather it's
just convenient to have a directory with the list of all RPMS of a
distribution::
# ./update_symlinks_in_RPMS_all.sh
Build Kernel Modules
~~~~~~~~~~~~~~~~~~~~
First install the latest kernel and kernel-devel packages on the
respective build systems.
Then build the RPMS on the corresponding build systems using the
scripts below.
32 bit::
# [gasser_m@tukan50-32]
# cd /afs/psi.ch/software/linux/dist/scientific/57/scripts
# sh build_kernel_modules.sh 2.6.18-194.3.1.el5 > \
# UPDATE_LOG/20100630-build_kernel_modules-2.6.18-194.3.1.el5.i686.log 2>&1
# check-set-of-built-kernel-modules.bash /tmp/rpms_for_2.6.18-194.3.1.el5 \
# KERNEL_MODULES_TO_BUILD/sl5.i386.kms-to-be-built
# sh build-gpfs.sl5x.i386.sh
64 bit::
# [gasser_m@tux50-64]
# cd /afs/psi.ch/software/linux/dist/scientific/57/scripts
# sh build_kernel_modules.sh 2.6.18-194.3.1.el5 > \
# UPDATE_LOG/20100630-build_kernel_modules-2.6.18-194.3.1.el5.x86_64.log 2>&1
# check-set-of-built-kernel-modules.bash /tmp/rpms_for_2.6.18-194.3.1.el5 \
# KERNEL_MODULES_TO_BUILD/sl5.x86_64.kms-to-be-built
# sh build-gpfs.sl5x.x86_64.sh
Finally, from both build systems, copy the built kernel modules to the
psi repository::
# cp -av `cat /tmp/rpms_for_2.6.18-194.3.1.el5` /afs/psi.ch/software/linux/dist/scientific/57/psi/all/
Get Updates For The Psi Repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Get Updates For The Other Repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Get Updates For The Nonfree Repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create New Snapshots
--------------------
The script `create_new_snapshots.sh` will pick out the latest version
of each RPM found in the active repositories.
It will create a subdirectory (snapshot) in each repository and name
it after the current date using the format YYYYMMDD.
Then it will place a symbolic link into this subdirectory for each
latest RPM found in the `all` subdirectory of the currently processed
repository.
To invoke it run the following command::
# nohup ./create_new_snapshots.sh alldirs > UPDATE_LOG/$(date +%Y-%m-%d)-create_new_snapshots.log 2>&1 &
Release Unstable, Create A New PSI Version And Release The Other SLP Snapshots
------------------------------------------------------------------------------
Release Unstable
~~~~~~~~~~~~~~~~
The "unstable" distribution is where active development of SLP occurs.
Generally, this distribution is run by developers and those who like
to live on the edge.
The command `release_unstable.sh` will update the respective symlinks
`.../unstable` to the latest snapshots.
Because `release_unstable.sh` is interactive, you should not redirect
the output to a file, as you won't be able to see the questions asked.
Before `release_unstable.sh`::
# [gasser_m@tux50]
# cd /afs/psi.ch/software/linux/dist/scientific/57/
# ls -l */unstable
# ./release_unstable.sh
After `release_unstable.sh`::
# ls -l */unstable
As soon as an unstable distribution has become testing a new unstable
can be generated which again points to the new latest snapshots.
Create A New PSI Version
~~~~~~~~~~~~~~~~~~~~~~~~
Run::
# cd /afs/psi.ch/software/linux/dist/scientific/57/scripts
# sh create_new_psi_version.sh
As soon as the new PSI version is created, i.e. the symbolic links
which point to the same target snapshots as the latest unstable
snapshots, the psi-version-info.txt file has to be actualized to
activate the PSI auto-update again for the hosts which are set to
unstable::
# ./create_file_psiversion-info.sh
Eventually, test the unstable release.
Release Testing
~~~~~~~~~~~~~~~
The "testing" distribution contains packages that haven't been
accepted into a "stable" release yet, but they are in the queue for
that. The main advantage of using this distribution is that it has
more recent versions of software.
The command `release_testing.sh` will update the respective symlinks
`.../testing` to the latest unstable snapshots.
If the puppet environment DesktopSL5Unstable was modified and the
changes should be made in DesktopSL5Testing, too, run
`rsync_puppet_env_testing_with_unstable.sh` before
`release_testing.sh`.
Because `release_testing.sh` is interactive, you should not redirect
the output to a file, as you won't be able to see the questions asked::
# [gasser_m@tux50]
# cd /afs/psi.ch/software/linux/dist/scientific/57/scripts
# ./rsync_puppet_env_testing_with_unstable.sh
# ./rsync_kickstart_dir_DesktopTesting_with_DesktopUnstable.sh
# ./release_testing.sh
# ./create_file_psiversion-info.sh
Release Stable
~~~~~~~~~~~~~~
To activate the PSI auto-update again for testing hosts the
psi-version-info.txt file has to be actualized.
The "stable" distribution, formerly known as "current", contains the
latest officially released distribution of SLP.
This is the production release of SLP, the one which we primarily
recommend using.
The command `release_stable.sh` will update the respective symlinks
`.../stable` to the latest unstable snapshots.
The procedure is analogous to the procedure described in the "Release
Testing" section::
# ./rsync_puppet_env_stable_with_testing.sh
# ./rsync_kickstart_dir_DesktopStable_with_DesktopTesting.sh
# ./release_stable.sh
# ./create_file_psiversion-info.sh
### begin ./release_stable.sh ###
Sourcing configuration file ./dist-config
TOP_DIR is /afs/psi.ch/software/linux/dist/scientific/57
Running ./release_stable.sh ...
Latest snapshot in psi:
/afs/psi.ch/software/linux/dist/scientific/57/psi/testing -> 20090916
Latest snapshot in others:
/afs/psi.ch/software/linux/dist/scientific/57/others/testing -> 20090916
Latest snapshot in update.i386:
/afs/psi.ch/software/linux/dist/scientific/57/update.i386/testing -> 20090916
Latest snapshot in update.x86_64:
/afs/psi.ch/software/linux/dist/scientific/57/update.x86_64/testing -> 20090916
Latest snapshot in kernel:
/afs/psi.ch/software/linux/dist/scientific/57/kernel/testing -> 2.6.18-128.7.1.el5
Latest snapshot in nonfree:
/afs/psi.ch/software/linux/dist/scientific/57/nonfree/testing -> 20090916
Latest snapshot in cluster:
/afs/psi.ch/software/linux/dist/scientific/57/cluster/testing -> 20090916
Relink stable to the latest snapshots (y/n)?
Before `release_stable.sh`::
# [gasser_m@tux50]
# cd /afs/psi.ch/software/linux/dist/scientific/57/
# ls -l */stable
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:25 cluster/stable -> 20090316
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:23 enhanced/stable -> 20090316
lrwxr-xr-x 1 gasser_m ait 18 Sep 18 11:24 kernel/stable -> 2.6.18-128.1.1.el5
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:24 nonfree/stable -> 20090316
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:22 others/stable -> 20090316
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:21 psi/stable -> 20090821
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:22 update.i386/stable -> 20090820
lrwxr-xr-x 1 gasser_m ait 8 Sep 18 11:21 update.x86_64/stable -> 20090820
After `release_stable.sh`::
# ls -l */stable
admin-guide/legacy/misc/updateslmaindoc.rst
-1275
View File
File diff suppressed because it is too large Load Diff
admin-guide/legacy/monitoring.rst
-34
View File
@@ -1,34 +0,0 @@
Monitoring and Reporting
========================
Cron jobs
---------
Cron jobs send mail on error, usually to `linuxmaster@psi.ch`, a
distribution list.
Nagios/Icinga
-------------
Ganglia
-------
Other
-----
Some systems dump information in
``/afs/psi.ch/service/linux/statistics/rawdata``. Others save it to
``/afs/psi.ch/intranet/Controls/tmp/sysreport/PSI``.
The PXE server `pxeserv01` regularly runs a script,
`/afs/psi.ch/service/linux/tftpboot/tools/script/pxe_script`, which copies
`/var/log/tftp.log` to `/afs/psi.ch/service/linux/tftpboot/tools/log/`,
compresses it, and produces statistics, which are saved as `pxeStatistik-$(date
+%Y%m%d).txt`.
The script is currently run as user `vojisavljevic` and the run is configured in
that user's crontab.
admin-guide/legacy/puppet.rst
-8
View File
@@ -1,8 +0,0 @@
Puppet
======
There have been and still are several instances of Puppet PSI.
- ``pxeserv01`` (obsolete, no puppetmaster running)
- ``psi-puppet3`` (used by Controls-IT)
- ``psi-puppet4``
infrastructure-guide/infrastructure_systems.md
+1 -1
View File
@@ -3,7 +3,7 @@ List of systems and their primary role:
__Core Infrastructure:__
* [boot.psi.ch](pxeserv01) - TFTP server for PXE booting
* [boot.psi.ch](boot_server) - TFTP server for PXE booting
* [sysdb.psi.ch](sysdb_server) - Runs sysdb, providing the dynamic iPXE, Grub and kickstart files
infrastructure-guide/pxeserv01.md
+3 -108
View File
@@ -1,71 +1,10 @@
# pxeserv01
The server is a RHEL 8, installed manually and registered directly with redhat.com . This is so that it's completely independent from anything else at PSI.
For historical reasons, the tftpboot directory is hosted on AFS. But for an unknown reason, the RHEL8 tftpd can not read the files from AFS. (It's not SELinux) So the data is mirrored to the local drive and is served from this copy.
See /etc/crontab
There is a cron job defined in /etc/crontab to sync the content of the `/afs` directory to the local `/tftpboot` directory.
This job runs **every minute** and is defined as follows:
```
* * * * * root rsync -aah --exclude '*rhel-8-poc*' --delete /afs/psi.ch/service/linux/tftpboot/ /tftpboot
```
# boot.psi.ch
This server hosts the tftp service (port 69) used for pxe booting.
Permissions /tftpboot directory:
```bash
[root@pxeserv01 ~]# du -sh /tftpboot/
5.2G /tftpboot/
[root@pxeserv01 ~]# ls -lad /tftpboot/
drwxr-xr-x 13 5122 840 4096 Mar 4 17:26 /tftpboot/
```
Permissions of the /afs tftpboot directory:
```
[root@pxeserv01 tftpboot]# fs listacl
Access list for . is
Normal rights:
psi:nodes rl
svc.linux:administrators rlidwka
svc.linux:pxe rl
svc.linux:readonly rl
svc.linux:tools rl
svc.linux:users l
web:hosts rl
[root@pxeserv01 tftpboot]# pwd
/afs/psi.ch/service/linux/tftpboot
[root@pxeserv01 tftpboot]#
```
Current members of linux.administrators:
```
$ pts membership svc.linux:administrators
Members of svc.linux:administrators (id: -10574) are:
system:administrators
ebner
lutz_h
stadler_h
kapeller
huesser
feichtinger
barabas
sala
gsell
ozerov_d
talamo_i
dorigo_a
nazlikul_m
caubet_m
taylor_j
ext-metzler_d
buchel_k
```
# Important
For any changes in the pxe config settings there might be a delay of 1 minute before the clients see the changes!
For any changes in the pxe config settings there might be a delay of 30 seconds before the clients see the changes!
# pxelinux.cfg directory
@@ -77,48 +16,4 @@ There are several syntax variants, which can be used for specific pxelinux confi
(/afs/psi.ch/service/linux/tftpboot/grub.cfg* /tftpboot/grub.cfg*)
Beside the default `grub.cfg` there can similar to `pxelinux` a host or network specific `grub` configuration files.
For details see the [Grub Manual](https://www.gnu.org/software/grub/manual/grub/grub.html#Network), but note that the MAC address documentation is wrong: smiliar as for `pxelinux` the MAC address must be prepended with `01-` to denote the network hardware type Ethernet.
# Questions
- is there a special tftpd configuration, if yes, where?
- It's not really a config, but the systemd unit file, which is changed from the default
```
/usr/lib/systemd/system/tftp.service
```
- chronyd has a port open on 323, for what is this needed?
- That's nothing special or custom, that's just how chronyd works by default
- Are firewall rules set explicitly? Current firewall rules:
```
[root@pxeserv01 ~]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: ens192
sources:
services: cockpit dhcpv6-client ssh tftp
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
[root@pxeserv01 ~]#
```
- answer:
- tftp is opened up additionally, nothing more
```
firewall-cmd --zone=public --add-service=tftp --permanent
firewall-cmd --zone=public --add-service=tftp
```
- is this service also used for windows systems? (I can see a `uefiwin` directory in the tftpboot directory)
- yes, this is the one and only tftp server for all PSI networks
- The one person I ever talked to about PXE booting and windows was Niklaus Baumann.
- Can you please explain the structure of the /tftpboot directory - which directories are populated by which services/users. Who is managing all this content? Is there additional documentation on this?
- Not really, it's a mess I inherited. On legacy mode, pxelinux.0 is loaded, on uefi, it is the grubx64.efi . These have their configs in pxelinux.cfg and grub.cfg respectively.
For details see the [Grub Manual](https://www.gnu.org/software/grub/manual/grub/grub.html#Network), but note that the MAC address documentation is wrong: smiliar as for `pxelinux` the MAC address must be prepended with `01-` to denote the network hardware type Ethernet.