TartareFR - Contributions [fr]

Datasheet

2016-09-17T08:14:26Z

Didier : /* Applications */

== Services ==
* [[Datasheet/LVM|LVM]]
* [[Datasheet/MySQL|MySQL]]
* [[Datasheet/XtraBackup|XtraBackup]]
* [[Datasheet/RHCluster|RedHat Cluster]]
* [[Datasheet/MAJ/Postgresql|Mise à jour de postgresql]]
* [[Datasheet/MAJ/Gitlab|Mise à jour de Gitlab]]
* [[Datasheet/FileSystem/XFS|Erreur de réparation après un crash sur XFS]]
* [[Datasheet/Screen|Screen]]

== Applications ==
* [[Datasheet/Thunderbird/UseDefaultTemplate|Utilisation d'un modèle par défaut dans Thunderbird]]
* [[Datasheet/Firefox/AcceptCertificate|Accepter un certificat auto-signé dans Firefox]]
* [[Datasheet/OpenSSL/CryptFile|Chiffrer/Déchiffrer un fichier]]

== Virtualisation ==
* [[Datasheet/Docker|Docker]]
* [[Datasheet/Virsh|Virsh]]
* [[Datasheet/Libguestfs|Libguestfs]]

== Systemd ==
* [[Datasheet/Systemd|Systemd]]
* [[Datasheet/Journalctl|Journalctl]]
* [[Datasheet/Hostnamectl|Hostnamectl]]
* [[Datasheet/Localectl|Localectl]]
* [[Datasheet/Timedatectl|Timedatectl]]
* [[Datasheet/Firewalld|Firewalld]]

== Gestion des RPM ==
* [[Datasheet/yum|Yum]]
* [[Datasheet/Repoquery|Repoquery]]
* [[Datasheet/PackageCleanup|Package-cleanup]]
* [[Datasheet/Fedpkg|Fedpkg]]

Datasheet/OpenSSL/CryptFile

2016-09-17T08:14:08Z

Didier : /* Déchiffrement */

{{Datasheet}}
= Chiffrement/Déchiffrement de fichier =

== Lister les cyphers disponibles ==

<pre>
openssl list-cipher-commands
aes-128-cbc
aes-128-ecb
aes-192-cbc
aes-192-ecb
aes-256-cbc
aes-256-ecb
base64
bf
bf-cbc
bf-cfb
bf-ecb
bf-ofb
camellia-128-cbc
camellia-128-ecb
camellia-192-cbc
camellia-192-ecb
camellia-256-cbc
camellia-256-ecb
cast
cast-cbc
cast5-cbc
cast5-cfb
cast5-ecb
cast5-ofb
des
des-cbc
des-cfb
des-ecb
des-ede
des-ede-cbc
des-ede-cfb
des-ede-ofb
des-ede3
des-ede3-cbc
des-ede3-cfb
des-ede3-ofb
des-ofb
des3
desx
idea
idea-cbc
idea-cfb
idea-ecb
idea-ofb
rc2
rc2-40-cbc
rc2-64-cbc
rc2-cbc
rc2-cfb
rc2-ecb
rc2-ofb
rc4
rc4-40
rc5
rc5-cbc
rc5-cfb
rc5-ecb
rc5-ofb
seed
seed-cbc
seed-cfb
seed-ecb
seed-ofb
zlib
</pre>

== Chiffrement ==

<pre>openssl enc -e -aes-256-cbc -in <FILE> -out <FILE>.asc</pre>
* '''enc''': on précise qu’on va utiliser un algorithme de chiffrement
* '''-e''': on chiffre un fichier
* '''-aes-256-cbc''': le cypher utilisé, ici AES-256-CBC
* '''-in <FILE>''': le fichier à chiffrer
* '''-out <FILE>.asc''': le fichier chiffré (avec l'ajout de l'extension .asc')

== Déchiffrement ==

<pre>openssl enc -d -aes-256-cbc -in <FILE>.asc -out <FILE></pre>
* '''enc''': on précise qu’on va utiliser un algorithme de chiffrement
* '''-d''': on déchiffre un fichier
* '''-aes-256-cbc''': le cypher utilisé, ici AES-256-CBC (doit être identique à celui de la commande de chiffrement)
* '''-in <FILE>.asc''': le fichier à chiffrer
* '''-out <FILE>''': le fichier chiffré (avec la suppression de l'extension .asc')

== Utilisation avec des scripts ==

On peut passer le mot de passe à la commande de chiffrement/déchiffrement.
<pre>openssl enc -d -aes-256-cbc -in <FILE>.asc -out <FILE> -pass pass:MonSuperMotDePasse</pre>
{{Admon/warning|Mot de passe dans la commande|Bien que cette méthode met à mal la sécurité, il peut arriver qu'elle est son utilité}}

Datasheet/OpenSSL/CryptFile

2016-09-17T08:09:41Z

Didier : Page créée avec « {{Datasheet}} = Chiffrement/Déchiffrement de fichier = == Lister les cyphers disponibles == <pre> openssl list-cipher-commands aes-128-cbc aes-128-ecb aes-192-cbc aes-1... »

IDS/Fail2Ban

2016-09-17T07:47:07Z

Didier : /* Bloquer les erreurs apache */

== Qu'est-ce que Fail2ban? ==
Fail2ban lit des fichiers de log comme /var/log/pwdfail ou /var/log/apache/error_log et bannit les adresses IP qui ont obtenu un trop grand nombre d'échecs lors de l'authentification. Il met à jour les règles du pare-feu pour rejeter cette adresse IP. Ces règles peuvent êtres défines par l'utilisateur. Fail2ban peut lire plusieurs fichiers de log comme ceux de sshd ou du serveur Apache.

== Installation ==

yum install fail2ban

Par défaut, le port 22 (ssh) est surveillé, vous pouvez vérifier que les règles ipatbles ont bien prises en compte fail2ban:

iptables -S | grep fail2ban
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A fail2ban-ssh -j RETURN

== Configuration ==

Deux fichiers:

=== fail2ban.conf ===

Rien à faire dans ce fichier, vous pouvez laisser les options par défaut:

/etc/fail2ban/fail2ban.conf

loglevel = 3
logtarget = /var/log/fail2ban.log
socket = /var/run/fail2ban/fail2ban.sock

=== jail.conf ===

Ce fichier est beaucoup plus intéressant, il contient tous les services à monitorer, et vous allez le découvrir, fail2ban ne se limite pas à SSH...

/etc/fail2ban/jail.conf

Vérifiez l'adresse d'envoi des mails d'avertissement:

[DEFAULT]
destemail = root@localhost

'''Erreur commune pour l'envoi des mail d'alertes'''

N'oubliez pas de modifier la variable action = %(action_)s
Et de la placer soit sur:

action = %(action_mw)s

Soit sur

action = %(action_mwl)s

Pour activer la surveillance d'un service, il suffit de placer la variable "enabled" à "true"

Par défaut la protection du service SSH est activée, pas les autres:
Si votre ssh n'écoute pas sur le port 22, pensez à le changer... (port = N° de port)

[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6

D'autres services, à activer en fonction de vos besoins:

[xinetd-fail]
enabled = true
filter = xinetd-fail
port = all
banaction = iptables-multiport-log
logpath = /var/log/daemon.log
maxretry = 2

[pam-generic]
enabled = true
filter = pam-generic
port = all
banaction = iptables-allports
port = anyport
logpath = /var/log/auth.log
maxretry = 6

[ssh-ddos]
enabled = true
port = ssh
filter = sshd-ddos
logpath = /var/log/auth.log
maxretry = 6

[apache]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

[apache-multiport]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

[apache-noscript]
enabled = true
port = http,https
filter = apache-noscript
logpath = /var/log/apache*/*error.log
maxretry = 6

[apache-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = /var/log/apache*/*error.log
maxretry = 2

[postfix]
enabled = true
port = smtp,ssmtp
filter = postfix
logpath = /var/log/mail.log

[sasl]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = sasl
logpath = /var/log/mail.log

n'oubliez pas de redémarrer fail2ban :

# service fail2ban restart

=== jail.local ===

Le fichier jail.local vous permet de mettre vos règles personnelles. Voici quelques exemples:

<pre>
[pure-ftpd]
enabled = true
port = ftp,ftp-data,ftps,ftps-data
filter = pure-ftpd
logpath = /var/log/messages
maxretry = 3

[dovecot-pop3imap]
enabled = true
filter = dovecot-pop3imap
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,pop3s,imap,imaps", protocol=tcp]
logpath = /var/log/mail.log
maxretry = 5

[webmin-auth]
enabled = true
port = https,10000
filter = webmin-auth
logpath = /var/log/auth.log
maxretry = 3

# Plugin ''roundcube-fail2ban-plugin'' à installer
#
[roundcube]
enabled = true
port = http,https
filter = roundcube
action = iptables-multiport[name=roundcube, port="http,https"]
sendmail-whois[name=roundcube, dest=root@localhost, sender=fail2ban@localhost]
logpath = /var/www/path/logs/userlogins

# Plugin ''squirrel_logger'' à ajouter à squirrelmail
[squirrelmail]
enabled = true
port = http,https
filter = squirrelmail
logpath = /var/www/path/squirrelmail_access_log
bantime = 6000
maxretry = 4

# Règle anti-Kevin...
[apache-admin]
enabled = true
port = http
filter = apache-admin
logpath = /var/log/apache*/error*.log
maxretry = 6

# Règle anti-boulets...
[apache-404]
enabled = true
port = http
filter = apache-404
logpath = /var/log/ispconfig/httpd/*/error*
maxretry = 10
</pre>

Les fichiers de conf qui vont bien:

'''pure-ftpd.conf''' déjà inclu dans la configuration de base

'''dovecot-pop3imap.conf''' déjà inclu dans la configuration de base

'''webmin-auth.conf'''
<pre>
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
# Rule by : Delvit Guillaume
#
# $Revision: 728 $
#

[Definition]

# patern : webmin[15673]: Non-existent login as toto from 86.0.6.217
# webmin[29544]: Invalid login as root from 86.0.6.217
#
# Option: failregex
# Notes.: regex to match the password failure messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
failregex = webmin.* Non-existent login as .+ from <HOST>$
webmin.* Invalid login as .+ from <HOST>$

# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
</pre>

'''roundcube.conf'''
<pre>
[Definition]
failregex = FAILED login for .*. from <HOST>
ignoreregex =
</pre>

'''squirrelmail.conf'''
<pre>
# Fail2Ban configuration file
#
# Author: Bill Landry ((email_protected))
#
# $Revision: 510 $

[Definition]

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P\S+)
# Values: TEXT

failregex = \[LOGIN_ERROR\].*from <HOST>: Utilisateur inconnu ou mot de passe incorrect

# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT

ignoreregex =
</pre>

'''apache-admin.conf'''
<pre>
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision: 471 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failure messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching.
# Values: TEXT
# [client x.x.x.x] File does not exist: /home/www/admin/admin,
failregex = [[]client <HOST>[]] File does not exist: .*admin|PMA|mysql

#
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
</pre>

'''apache-404.conf'''
<pre>
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision: 471 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failure messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching.
# Values: TEXT
# [client x.x.x.x] File does not exist: /home/www/admin/admin,
failregex = [[]client <HOST>[]] File does not exist: .*
#
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
</pre>

'''Option très intéressante pour les logs multiples'''

Vous avez la possibilité (si vos logs sont "dispersés") de mettre des chemins "relatifs" - Vous pouvez utiliser les * (étoiles)

Par exemple, vos logs pour chaque site sont dispersés dans des répertoires différents...
Vous utiliserez alors le chemin suivant (tous les sous-répertoires dans /var/log/ispconfig/httpd/ seront alors pris en compte)

logpath /var/log/ispconfig/httpd/*/error*

==== Plugins squirrelmail et rouncube ====

[http://mattrude.com/projects/roundcube-fail2ban-plugin/ Plugin roundcube-fail2ban-plugin]

[http://www.howtoforge.com/configuring-fail2ban-with-squirrelmail-on-debian-lenny-ispconfig-3 Plugin squirrel_logger]

==== Fail2ban avec mod-evasive ====

Si vous utilisez mod-evasive, le module de protection contre les attaques Ddos de apache2, vous aurez peut-etre envie d'ajouter un filtre à fail2ban:

# $EDITOR /etc/fail2ban/filter.d/apache-dosevasive.conf
<pre>
# Fail2Ban configuration file
#
# Author: Xela
#
# $Revision: 728 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the Forbidden log entrys in apache error.log
# maybe (but not only) provided by mod_evasive
#
# Values: TEXT
#
#failregex = ^\[[^\]]*\]\s+\[error\]\s+\[client \] client denied by server configuration:\s
failregex = ^\[[^\]]*\]\s+\[error\]\s+\[client <HOST>\] client denied by server configuration:\s

# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
</pre>

Ajoutez ensuite ce bloc à /etc/fail2ban/jail.local (adaptez l'emplacement du fichier log à surveiller en fonction de votre configuration)
<pre>
[apache-dosevasive]

enabled = true
filter = apache-dosevasive
action = iptables-allports[name=apache-dosevasive]
logpath = /var/log/ispconfig/httpd/*/error*
#logpath = /var/log/apache*/*error.log
bantime = 600
maxretry = 10
</pre>

=== Cas particulier de mysql ===

Si vous souhaitez protéger un serveur mysql dont la base est ouverte sur Internet (ce qui n'est pas conseillé et pas très prudent...), voici comment faire:

[[https://www.debian-fr.org/securite-anti-brute-force-t39497.html Discussion sur le Forum]]

==== Activez les logs de mysql ====

Dans le fichier /etc/mysql/my.cnf

general_log_file = /var/log/mysql/mysql.log
general_log = 1

==== Patchez le fichier de support de date de fail2ban ====

Une sauvegarde:
cp /usr/share/fail2ban/server/datedetector.py /usr/share/fail2ban/server/datedetector.py.sos

Dans le fichier /usr/share/fail2ban/server/datedetector.py ajoutez ceci (ligne 144)

''Attention, les espaces sont des tabulations''
<pre>
# AAMMJJ HH:MM:SS
template = DateStrptime()
template.setName("YearMonthDay Hour:Minute:Second")
template.setRegex("\d{2}\d{2}\d{2} \d{2}:\d{2}:\d{2}")
template.setPattern("%y%m%d %H:%M:%S")
self.__templates.append(template)
</pre>

Vous devriez obtenir ceci:

<pre>
...
# <09/16/08@05:03:30>
template = DateStrptime()
template.setName("<Month/Day/Year@Hour:Minute:Second>")
template.setRegex("^<\d{2}/\d{2}/\d{2}@\d{2}:\d{2}:\d{2}>")
template.setPattern("<%m/%d/%y@%H:%M:%S>")
self.__templates.append(template)
# AAMMJJ HH:MM:SS
template = DateStrptime()
template.setName("YearMonthDay Hour:Minute:Second")
template.setRegex("\d{2}\d{2}\d{2} \d{2}:\d{2}:\d{2}")
template.setPattern("%y%m%d %H:%M:%S")
self.__templates.append(template)
finally:
self.__lock.release()
...
</pre>

==== Configurez fail2ban ====

$editor /etc/fail2ban/jail.conf
<pre>
[mysql]
enabled = true
port = 3306
filter = mysqld
logpath = /var/log/mysql/mysql.log
maxretry = 3
</pre>

$editor /etc/fail2ban/filter.d/mysqld.conf
<pre>
# Fail2Ban configuration file
#
# Author: JOUBERT Pierre-Benoît
#

[Definition]
failregex = Access denied for user '.*'@'<HOST>'
</pre>

=== Bloquer les erreurs 403 apache ===

Modification du fichier /etc/fail2ban/jail.local
<pre>
[apache-forbidden]
enabled = true
port = http,https
logpath = %(apache_access_log)s
# %(apache_error_log)s
bantime = 172800
maxretry = 6
</pre>

Fichier /etc/fail2ban/filter.d/apache-forbidden.conf
<pre>
[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# apache-common.local
before = apache-common.conf

[Definition]
failregex = <HOST>\ \-\ \-\ .*HTTP\/[0-9]+(\.[0-9]+)?\" 403
\[client\ <HOST>:[0-9]+\]\ client\ denied
ignoreregex =
</pre>

Un redémarrage du service plus tard, notre prison est maintenant opérationnelle et celui qui fait plus de 6 tentatives pour accéder à une ressource protégé par mot de passe, est banni pour 1 semaine.

== Test ==

=== Testez les règles ===

L'erreur commune est de se tromper de fichier log... Vérifiez et revérifiez que le fichier donné en "logpath" est le bon.
Ensuite testez vos règles avec la commande /usr/bin/fail2ban-regex

# /usr/bin/fail2ban-regex /var/www/path/logs/userlogins /etc/fail2ban/filter.d/roundcube.conf

Exemple de sortie:
<pre>
Running tests
=============

Use regex file : /etc/fail2ban/filter.d/roundcube.conf
Use log file : /var/www/path/logs/userlogins

Results
=======

Failregex
|- Regular expressions:
| [1] FAILED login for .*. from <HOST>
|
`- Number of matches:
[1] 1 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
41.xxx.xxx.xxx (Wed Dec 28 15:51:14 2011)

Date template hits:
0 hit(s): MONTH Day Hour:Minute:Second
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second
0 hit(s): Year/Month/Day Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/MONTH/Year:Hour:Minute:Second
0 hit(s): Month/Day/Year:Hour:Minute:Second
0 hit(s): Year-Month-Day Hour:Minute:Second
2 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond]
0 hit(s): Day-Month-Year Hour:Minute:Second
0 hit(s): TAI64N
0 hit(s): Epoch
0 hit(s): ISO 8601
0 hit(s): Hour:Minute:Second
0 hit(s): <Month/Day/Year@Hour:Minute:Second>

Success, the total number of match is 1

However, look at the above section 'Running tests' which could contain important
information.
</pre>

=== Testez l'état des jails ===

Avec la commande /usr/bin/fail2ban-client vous pouvez vérifier l'état de vos "jails":

Exemples de sortie:

# /usr/bin/fail2ban-client status
<pre>
Status
|- Number of jail: 18
`- Jail list: dovecot-pop3imap, pure-ftpd, roundcube, apache, ssh, dovecot, apache-overflows, apache-noscript, squirrelmail, apache-dosevasive, apache-admin, pam-generic, postfix, ssh-ddos, webmin-auth, apache-404, sasl, named-refused-tcp
</pre>

# /usr/bin/fail2ban-client status apache-404
<pre>
Status for the jail: apache-404
|- filter
| |- File list: /var/log/path/error.log /var/log/path2/error.log /var/log/path2/error.log Etc...
| |- Currently failed: 5
| `- Total failed: 32
`- action
|- Currently banned: 2
| `- IP list: 41.xxx.xxx.xxx 84.xxx.xxx.xxx
`- Total banned: 2
</pre>

=== Testez en violant une règle ===

Créez par exemple un répertoire dans votre serveur apache, rendez obligatoire l'identification, puis entrez plusieurs fois de suite un mot de passe erroné.
Vous devriez avoir dans vols logs ceci:

tail -f /var/log/fail2ban.log

2011-08-08 12:27:18,730 fail2ban.actions: WARNING [apache] Ban 10.9.11.150

Effectivement, iptables à bloqué votre ip:

iptables -L

Chain fail2ban-apache (1 references)
target prot opt source destination
DROP all -- 10.9.11.150 anywhere
RETURN all -- anywhere anywhere

Au bout de 10 minutes (en fonction de ce que vous aurez précisé dans le configuration), l'IP sera de nouveau "libérée":

2011-08-08 12:37:19,585 fail2ban.actions: WARNING [apache] Unban 10.9.11.150

== Erreur au démarrage de fail2ban ==

Si vous surveillez plusieurs services, il existe un bug gênant sur fail2ban ([http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554162 fail2ban: fails to load iptable rules with multiple jails]) - Il existe une solution :

Lorsque vous démarrerez fail2ban, surveillez ses logs, vous devriez avoir ceci:

2011-08-08 16:44:40,564 fail2ban.jail : INFO Jail 'apache-noscript' started
2011-08-08 16:44:40,810 fail2ban.jail : INFO Jail 'pam-generic' started
2011-08-08 16:44:41,051 fail2ban.jail : INFO Jail 'xinetd-fail' started
2011-08-08 16:44:41,269 fail2ban.jail : INFO Jail 'ssh-ddos' started
2011-08-08 16:44:41,506 fail2ban.jail : INFO Jail 'apache-multiport' started
2011-08-08 16:44:41,739 fail2ban.jail : INFO Jail 'apache-overflows' started
2011-08-08 16:44:41,976 fail2ban.jail : INFO Jail 'ssh' started
2011-08-08 16:44:42,206 fail2ban.jail : INFO Jail 'postfix' started
2011-08-08 16:44:42,448 fail2ban.jail : INFO Jail 'sasl' started
2011-08-08 16:44:42,667 fail2ban.jail : INFO Jail 'apache' started

Si vous avez ce genre de message d'erreur:

2011-08-08 12:22:52,286 fail2ban.actions.action: ERROR iptables -N fail2ban-pam-generic
iptables -A fail2ban-pam-generic -j RETURN
iptables -I INPUT -p tcp -j fail2ban-pam-generic returned 400
2011-08-08 15:06:04,467 fail2ban.actions.action: ERROR iptables -D INPUT -p tcp -m multiport --dports 10122 -j fail2ban-ssh-ddos
iptables -F fail2ban-ssh-ddos
iptables -X fail2ban-ssh-ddos returned 100
2011-08-08 15:06:10,027 fail2ban.actions.action: ERROR iptables -N fail2ban-apache-overflows
iptables -A fail2ban-apache-overflows -j RETURN
iptables -I INPUT -p tcp -m multiport --dports http,https -j fail2ban-apache-overflows returned 200
2011-08-08 15:06:10,224 fail2ban.actions.action: ERROR iptables -N fail2ban-postfix
iptables -A fail2ban-postfix -j RETURN
iptables -I INPUT -p tcp -m multiport --dports smtp,ssmtp -j fail2ban-postfix returned 400
2011-08-08 15:06:10,283 fail2ban.actions.action: ERROR iptables -N fail2ban-sasl
iptables -A fail2ban-sasl -j RETURN
iptables -I INPUT -p tcp -m multiport --dports smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s -j fail2ban-sasl returned 200
2011-08-08 15:14:26,002 fail2ban.actions.action: ERROR iptables -D INPUT -p tcp -m multiport --dports http,https -j fail2ban-apache-overflows
iptables -F fail2ban-apache-overflows
iptables -X fail2ban-apache-overflows returned 100
2011-08-08 15:14:28,374 fail2ban.actions.action: ERROR iptables -D INPUT -p tcp -m multiport --dports smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s -j fail2ban-sasl
iptables -F fail2ban-sasl
iptables -X fail2ban-sasl returned 100
2011-08-08 15:14:45,382 fail2ban.actions.action: ERROR iptables -N fail2ban-apache-noscript
iptables -A fail2ban-apache-noscript -j RETURN
iptables -I INPUT -p tcp -m multiport --dports http,https -j fail2ban-apache-noscript returned 400

Il existe deux solutions:

1) Modifier le fichier /usr/bin/fail2ban-client

'''Faite une sauvegarde de auparavant...'''

Editez le fichier /usr/bin/fail2ban-client et ajoutez une temporisation (time.sleep(0.1)) à cet endroit:

def __processCmd(self, cmd, showRet = True):
beautifier = Beautifier()
for c in cmd:
time.sleep(0.1)
beautifier.setInputCmd(c)

Si la temporisation à 0.1 ne suffit pas, mettez 0.2. et redémarrez fail2ban.

2) Installer une version supérieure (Fixed in version fail2ban/0.8.5-2)

Installer la version testing (8.6-3 0) ou celle des backports (8.6-3~bpo60+1)

== Fail2ban et ipv6 (EXPERIMENTAL) ==

Vous le savez, l'ipv6 se généralise, lancement officiel le 6 juin 2012
Quid de fail2ban ? Malheureusement, fail2ban ne supporte pas encore l'ipv6.
Heureusement, il existe un patch qui permet d'avoir fail2ban activé sur votre ipv6...

Mode d'emploi:

Téléchargez le patch:
<pre>
wget http://thanatos.trollprod.org/sousites/fail2banv6/fail2ban-ipv6.tar.bz2
--2012-04-14 09:30:31-- http://thanatos.trollprod.org/sousites/fail2banv6/fail2ban-ipv6.tar.bz2
Résolution de thanatos.trollprod.org (thanatos.trollprod.org)... 94.23.14.97, 2001:41d0:2:f61::fed1:fe54
Connexion vers thanatos.trollprod.org (thanatos.trollprod.org)|94.23.14.97|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 2293 (2,2K) [application/x-bzip]
Sauvegarde en : «fail2ban-ipv6.tar.bz2»

100%[=============================================================================================>] 2 293 --.-K/s ds 0,001s

2012-04-14 09:30:31 (2,98 MB/s) - «fail2ban-ipv6.tar.bz2» sauvegardé [2293/2293]
</pre>

mkdir fail2ban-ipv6
tar xvjf fail2ban-ipv6.tar.bz2 -C fail2ban-ipv6

cp /usr/share/fail2ban/server/filter.py /usr/share/fail2ban/server/filter.py.sos
cp /usr/share/fail2ban/server/failregex.py /usr/share/fail2ban/server/failregex.py.sos

Testez les patch:

cd /usr/share/fail2ban/server/

root@nas:/usr/share/fail2ban/server# patch -p0 --dry-run < /root/fail2ban-ipv6/patchfilter.patch
patching file filter.py
Hunk #1 succeeded at 525 (offset 14 lines).
Hunk #2 succeeded at 549 (offset 14 lines).
Hunk #3 succeeded at 580 (offset 14 lines).

root@nas:/usr/share/fail2ban/server# patch -p0 --dry-run < /root/fail2ban-ipv6/regex.patch
patching file failregex.py
Hunk #1 succeeded at 47 (offset 3 lines).

Si le résultat est positif (pas d'erreur) lancez les patchs

root@nas:/usr/share/fail2ban/server# patch -p0 < /root/fail2ban-ipv6/patchfilter.patch
patching file filter.py
Hunk #1 succeeded at 525 (offset 14 lines).
Hunk #2 succeeded at 549 (offset 14 lines).
Hunk #3 succeeded at 580 (offset 14 lines).
root@nas:/usr/share/fail2ban/server# patch -p0 < /root/fail2ban-ipv6/regex.patch
patching file failregex.py
Hunk #1 succeeded at 47 (offset 3 lines).

Copiez les fichiers nécessaires:

root@nas:/usr/share/fail2ban/server# cp /root/fail2ban-ipv6/ip64tables.sh /usr/bin/
root@nas:/usr/share/fail2ban/server# chmod 755 /usr/bin/ip64tables.sh
root@nas:/usr/share/fail2ban/server# cp /root/fail2ban-ipv6/iptables46-multiport.conf /etc/fail2ban/action.d/
root@nas:/usr/share/fail2ban/server# chmod 644 /etc/fail2ban/action.d/iptables46-multiport.conf

Créez le bloc de configuration:

nano /etc/fail2ban/jail.conf

...
[ssh-ip6tables]
enabled = true
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
action = iptables46-multiport[name=SSH, port=22, protocol=tcp]
sendmail-whois[name=SSH, dest=root, sender=fail2ban@mail.com]
...

Redémarrez fail2ban et vérifiez qu'il est actif:

service fail2ban restart
Restarting authentication failure monitor: fail2ban.
ip6tables -S
...
-N fail2ban-SSH
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-SSH
-A fail2ban-SSH -j RETURN

Avertissement:
# N'a pas encore été testé
# Ne pas activer la résolution de nom dans les logs

== Liens externes ==

Je vous encourage à lire:

* La page de man de fail2ban
* [http://www.fail2ban.org/wiki/index.php/Main_Page Le Wiki de fail2ban - Très complet]

[[Catégorie:Sécurité]]

IDS/Fail2Ban

2016-09-17T07:41:16Z

Didier : /* Cas particulier de mysql */

== Qu'est-ce que Fail2ban? ==
Fail2ban lit des fichiers de log comme /var/log/pwdfail ou /var/log/apache/error_log et bannit les adresses IP qui ont obtenu un trop grand nombre d'échecs lors de l'authentification. Il met à jour les règles du pare-feu pour rejeter cette adresse IP. Ces règles peuvent êtres défines par l'utilisateur. Fail2ban peut lire plusieurs fichiers de log comme ceux de sshd ou du serveur Apache.

== Installation ==

yum install fail2ban

Par défaut, le port 22 (ssh) est surveillé, vous pouvez vérifier que les règles ipatbles ont bien prises en compte fail2ban:

iptables -S | grep fail2ban
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A fail2ban-ssh -j RETURN

== Configuration ==

Deux fichiers:

=== fail2ban.conf ===

Rien à faire dans ce fichier, vous pouvez laisser les options par défaut:

/etc/fail2ban/fail2ban.conf

loglevel = 3
logtarget = /var/log/fail2ban.log
socket = /var/run/fail2ban/fail2ban.sock

=== jail.conf ===

Ce fichier est beaucoup plus intéressant, il contient tous les services à monitorer, et vous allez le découvrir, fail2ban ne se limite pas à SSH...

/etc/fail2ban/jail.conf

Vérifiez l'adresse d'envoi des mails d'avertissement:

[DEFAULT]
destemail = root@localhost

'''Erreur commune pour l'envoi des mail d'alertes'''

N'oubliez pas de modifier la variable action = %(action_)s
Et de la placer soit sur:

action = %(action_mw)s

Soit sur

action = %(action_mwl)s

Pour activer la surveillance d'un service, il suffit de placer la variable "enabled" à "true"

Par défaut la protection du service SSH est activée, pas les autres:
Si votre ssh n'écoute pas sur le port 22, pensez à le changer... (port = N° de port)

[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6

D'autres services, à activer en fonction de vos besoins:

[xinetd-fail]
enabled = true
filter = xinetd-fail
port = all
banaction = iptables-multiport-log
logpath = /var/log/daemon.log
maxretry = 2

[pam-generic]
enabled = true
filter = pam-generic
port = all
banaction = iptables-allports
port = anyport
logpath = /var/log/auth.log
maxretry = 6

[ssh-ddos]
enabled = true
port = ssh
filter = sshd-ddos
logpath = /var/log/auth.log
maxretry = 6

[apache]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

[apache-multiport]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

[apache-noscript]
enabled = true
port = http,https
filter = apache-noscript
logpath = /var/log/apache*/*error.log
maxretry = 6

[apache-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = /var/log/apache*/*error.log
maxretry = 2

[postfix]
enabled = true
port = smtp,ssmtp
filter = postfix
logpath = /var/log/mail.log

[sasl]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = sasl
logpath = /var/log/mail.log

n'oubliez pas de redémarrer fail2ban :

# service fail2ban restart

=== jail.local ===

Le fichier jail.local vous permet de mettre vos règles personnelles. Voici quelques exemples:

<pre>
[pure-ftpd]
enabled = true
port = ftp,ftp-data,ftps,ftps-data
filter = pure-ftpd
logpath = /var/log/messages
maxretry = 3

[dovecot-pop3imap]
enabled = true
filter = dovecot-pop3imap
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,pop3s,imap,imaps", protocol=tcp]
logpath = /var/log/mail.log
maxretry = 5

[webmin-auth]
enabled = true
port = https,10000
filter = webmin-auth
logpath = /var/log/auth.log
maxretry = 3

# Plugin ''roundcube-fail2ban-plugin'' à installer
#
[roundcube]
enabled = true
port = http,https
filter = roundcube
action = iptables-multiport[name=roundcube, port="http,https"]
sendmail-whois[name=roundcube, dest=root@localhost, sender=fail2ban@localhost]
logpath = /var/www/path/logs/userlogins

# Plugin ''squirrel_logger'' à ajouter à squirrelmail
[squirrelmail]
enabled = true
port = http,https
filter = squirrelmail
logpath = /var/www/path/squirrelmail_access_log
bantime = 6000
maxretry = 4

# Règle anti-Kevin...
[apache-admin]
enabled = true
port = http
filter = apache-admin
logpath = /var/log/apache*/error*.log
maxretry = 6

# Règle anti-boulets...
[apache-404]
enabled = true
port = http
filter = apache-404
logpath = /var/log/ispconfig/httpd/*/error*
maxretry = 10
</pre>

Les fichiers de conf qui vont bien:

'''pure-ftpd.conf''' déjà inclu dans la configuration de base

'''dovecot-pop3imap.conf''' déjà inclu dans la configuration de base

'''webmin-auth.conf'''
<pre>
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
# Rule by : Delvit Guillaume
#
# $Revision: 728 $
#

[Definition]

# patern : webmin[15673]: Non-existent login as toto from 86.0.6.217
# webmin[29544]: Invalid login as root from 86.0.6.217
#
# Option: failregex
# Notes.: regex to match the password failure messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
failregex = webmin.* Non-existent login as .+ from <HOST>$
webmin.* Invalid login as .+ from <HOST>$

# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
</pre>

'''roundcube.conf'''
<pre>
[Definition]
failregex = FAILED login for .*. from <HOST>
ignoreregex =
</pre>

'''squirrelmail.conf'''
<pre>
# Fail2Ban configuration file
#
# Author: Bill Landry ((email_protected))
#
# $Revision: 510 $

[Definition]

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P\S+)
# Values: TEXT

failregex = \[LOGIN_ERROR\].*from <HOST>: Utilisateur inconnu ou mot de passe incorrect

# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT

ignoreregex =
</pre>

'''apache-admin.conf'''
<pre>
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision: 471 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failure messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching.
# Values: TEXT
# [client x.x.x.x] File does not exist: /home/www/admin/admin,
failregex = [[]client <HOST>[]] File does not exist: .*admin|PMA|mysql

#
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
</pre>

'''apache-404.conf'''
<pre>
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision: 471 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failure messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching.
# Values: TEXT
# [client x.x.x.x] File does not exist: /home/www/admin/admin,
failregex = [[]client <HOST>[]] File does not exist: .*
#
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
</pre>

'''Option très intéressante pour les logs multiples'''

Vous avez la possibilité (si vos logs sont "dispersés") de mettre des chemins "relatifs" - Vous pouvez utiliser les * (étoiles)

Par exemple, vos logs pour chaque site sont dispersés dans des répertoires différents...
Vous utiliserez alors le chemin suivant (tous les sous-répertoires dans /var/log/ispconfig/httpd/ seront alors pris en compte)

logpath /var/log/ispconfig/httpd/*/error*

==== Plugins squirrelmail et rouncube ====

[http://mattrude.com/projects/roundcube-fail2ban-plugin/ Plugin roundcube-fail2ban-plugin]

[http://www.howtoforge.com/configuring-fail2ban-with-squirrelmail-on-debian-lenny-ispconfig-3 Plugin squirrel_logger]

==== Fail2ban avec mod-evasive ====

Si vous utilisez mod-evasive, le module de protection contre les attaques Ddos de apache2, vous aurez peut-etre envie d'ajouter un filtre à fail2ban:

# $EDITOR /etc/fail2ban/filter.d/apache-dosevasive.conf
<pre>
# Fail2Ban configuration file
#
# Author: Xela
#
# $Revision: 728 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the Forbidden log entrys in apache error.log
# maybe (but not only) provided by mod_evasive
#
# Values: TEXT
#
#failregex = ^\[[^\]]*\]\s+\[error\]\s+\[client \] client denied by server configuration:\s
failregex = ^\[[^\]]*\]\s+\[error\]\s+\[client <HOST>\] client denied by server configuration:\s

# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
</pre>

Ajoutez ensuite ce bloc à /etc/fail2ban/jail.local (adaptez l'emplacement du fichier log à surveiller en fonction de votre configuration)
<pre>
[apache-dosevasive]

enabled = true
filter = apache-dosevasive
action = iptables-allports[name=apache-dosevasive]
logpath = /var/log/ispconfig/httpd/*/error*
#logpath = /var/log/apache*/*error.log
bantime = 600
maxretry = 10
</pre>

=== Cas particulier de mysql ===

Si vous souhaitez protéger un serveur mysql dont la base est ouverte sur Internet (ce qui n'est pas conseillé et pas très prudent...), voici comment faire:

[[https://www.debian-fr.org/securite-anti-brute-force-t39497.html Discussion sur le Forum]]

==== Activez les logs de mysql ====

Dans le fichier /etc/mysql/my.cnf

general_log_file = /var/log/mysql/mysql.log
general_log = 1

==== Patchez le fichier de support de date de fail2ban ====

Une sauvegarde:
cp /usr/share/fail2ban/server/datedetector.py /usr/share/fail2ban/server/datedetector.py.sos

Dans le fichier /usr/share/fail2ban/server/datedetector.py ajoutez ceci (ligne 144)

''Attention, les espaces sont des tabulations''
<pre>
# AAMMJJ HH:MM:SS
template = DateStrptime()
template.setName("YearMonthDay Hour:Minute:Second")
template.setRegex("\d{2}\d{2}\d{2} \d{2}:\d{2}:\d{2}")
template.setPattern("%y%m%d %H:%M:%S")
self.__templates.append(template)
</pre>

Vous devriez obtenir ceci:

<pre>
...
# <09/16/08@05:03:30>
template = DateStrptime()
template.setName("<Month/Day/Year@Hour:Minute:Second>")
template.setRegex("^<\d{2}/\d{2}/\d{2}@\d{2}:\d{2}:\d{2}>")
template.setPattern("<%m/%d/%y@%H:%M:%S>")
self.__templates.append(template)
# AAMMJJ HH:MM:SS
template = DateStrptime()
template.setName("YearMonthDay Hour:Minute:Second")
template.setRegex("\d{2}\d{2}\d{2} \d{2}:\d{2}:\d{2}")
template.setPattern("%y%m%d %H:%M:%S")
self.__templates.append(template)
finally:
self.__lock.release()
...
</pre>

==== Configurez fail2ban ====

$editor /etc/fail2ban/jail.conf
<pre>
[mysql]
enabled = true
port = 3306
filter = mysqld
logpath = /var/log/mysql/mysql.log
maxretry = 3
</pre>

$editor /etc/fail2ban/filter.d/mysqld.conf
<pre>
# Fail2Ban configuration file
#
# Author: JOUBERT Pierre-Benoît
#

[Definition]
failregex = Access denied for user '.*'@'<HOST>'
</pre>

=== Bloquer les erreurs apache ===

== Test ==

=== Testez les règles ===

L'erreur commune est de se tromper de fichier log... Vérifiez et revérifiez que le fichier donné en "logpath" est le bon.
Ensuite testez vos règles avec la commande /usr/bin/fail2ban-regex

# /usr/bin/fail2ban-regex /var/www/path/logs/userlogins /etc/fail2ban/filter.d/roundcube.conf

Exemple de sortie:
<pre>
Running tests
=============

Use regex file : /etc/fail2ban/filter.d/roundcube.conf
Use log file : /var/www/path/logs/userlogins

Results
=======

Failregex
|- Regular expressions:
| [1] FAILED login for .*. from <HOST>
|
`- Number of matches:
[1] 1 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
41.xxx.xxx.xxx (Wed Dec 28 15:51:14 2011)

Date template hits:
0 hit(s): MONTH Day Hour:Minute:Second
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second
0 hit(s): Year/Month/Day Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/MONTH/Year:Hour:Minute:Second
0 hit(s): Month/Day/Year:Hour:Minute:Second
0 hit(s): Year-Month-Day Hour:Minute:Second
2 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond]
0 hit(s): Day-Month-Year Hour:Minute:Second
0 hit(s): TAI64N
0 hit(s): Epoch
0 hit(s): ISO 8601
0 hit(s): Hour:Minute:Second
0 hit(s): <Month/Day/Year@Hour:Minute:Second>

Success, the total number of match is 1

However, look at the above section 'Running tests' which could contain important
information.
</pre>

=== Testez l'état des jails ===

Avec la commande /usr/bin/fail2ban-client vous pouvez vérifier l'état de vos "jails":

Exemples de sortie:

# /usr/bin/fail2ban-client status
<pre>
Status
|- Number of jail: 18
`- Jail list: dovecot-pop3imap, pure-ftpd, roundcube, apache, ssh, dovecot, apache-overflows, apache-noscript, squirrelmail, apache-dosevasive, apache-admin, pam-generic, postfix, ssh-ddos, webmin-auth, apache-404, sasl, named-refused-tcp
</pre>

# /usr/bin/fail2ban-client status apache-404
<pre>
Status for the jail: apache-404
|- filter
| |- File list: /var/log/path/error.log /var/log/path2/error.log /var/log/path2/error.log Etc...
| |- Currently failed: 5
| `- Total failed: 32
`- action
|- Currently banned: 2
| `- IP list: 41.xxx.xxx.xxx 84.xxx.xxx.xxx
`- Total banned: 2
</pre>

=== Testez en violant une règle ===

Créez par exemple un répertoire dans votre serveur apache, rendez obligatoire l'identification, puis entrez plusieurs fois de suite un mot de passe erroné.
Vous devriez avoir dans vols logs ceci:

tail -f /var/log/fail2ban.log

2011-08-08 12:27:18,730 fail2ban.actions: WARNING [apache] Ban 10.9.11.150

Effectivement, iptables à bloqué votre ip:

iptables -L

Chain fail2ban-apache (1 references)
target prot opt source destination
DROP all -- 10.9.11.150 anywhere
RETURN all -- anywhere anywhere

Au bout de 10 minutes (en fonction de ce que vous aurez précisé dans le configuration), l'IP sera de nouveau "libérée":

2011-08-08 12:37:19,585 fail2ban.actions: WARNING [apache] Unban 10.9.11.150

== Erreur au démarrage de fail2ban ==

Si vous surveillez plusieurs services, il existe un bug gênant sur fail2ban ([http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554162 fail2ban: fails to load iptable rules with multiple jails]) - Il existe une solution :

Lorsque vous démarrerez fail2ban, surveillez ses logs, vous devriez avoir ceci:

2011-08-08 16:44:40,564 fail2ban.jail : INFO Jail 'apache-noscript' started
2011-08-08 16:44:40,810 fail2ban.jail : INFO Jail 'pam-generic' started
2011-08-08 16:44:41,051 fail2ban.jail : INFO Jail 'xinetd-fail' started
2011-08-08 16:44:41,269 fail2ban.jail : INFO Jail 'ssh-ddos' started
2011-08-08 16:44:41,506 fail2ban.jail : INFO Jail 'apache-multiport' started
2011-08-08 16:44:41,739 fail2ban.jail : INFO Jail 'apache-overflows' started
2011-08-08 16:44:41,976 fail2ban.jail : INFO Jail 'ssh' started
2011-08-08 16:44:42,206 fail2ban.jail : INFO Jail 'postfix' started
2011-08-08 16:44:42,448 fail2ban.jail : INFO Jail 'sasl' started
2011-08-08 16:44:42,667 fail2ban.jail : INFO Jail 'apache' started

Si vous avez ce genre de message d'erreur:

2011-08-08 12:22:52,286 fail2ban.actions.action: ERROR iptables -N fail2ban-pam-generic
iptables -A fail2ban-pam-generic -j RETURN
iptables -I INPUT -p tcp -j fail2ban-pam-generic returned 400
2011-08-08 15:06:04,467 fail2ban.actions.action: ERROR iptables -D INPUT -p tcp -m multiport --dports 10122 -j fail2ban-ssh-ddos
iptables -F fail2ban-ssh-ddos
iptables -X fail2ban-ssh-ddos returned 100
2011-08-08 15:06:10,027 fail2ban.actions.action: ERROR iptables -N fail2ban-apache-overflows
iptables -A fail2ban-apache-overflows -j RETURN
iptables -I INPUT -p tcp -m multiport --dports http,https -j fail2ban-apache-overflows returned 200
2011-08-08 15:06:10,224 fail2ban.actions.action: ERROR iptables -N fail2ban-postfix
iptables -A fail2ban-postfix -j RETURN
iptables -I INPUT -p tcp -m multiport --dports smtp,ssmtp -j fail2ban-postfix returned 400
2011-08-08 15:06:10,283 fail2ban.actions.action: ERROR iptables -N fail2ban-sasl
iptables -A fail2ban-sasl -j RETURN
iptables -I INPUT -p tcp -m multiport --dports smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s -j fail2ban-sasl returned 200
2011-08-08 15:14:26,002 fail2ban.actions.action: ERROR iptables -D INPUT -p tcp -m multiport --dports http,https -j fail2ban-apache-overflows
iptables -F fail2ban-apache-overflows
iptables -X fail2ban-apache-overflows returned 100
2011-08-08 15:14:28,374 fail2ban.actions.action: ERROR iptables -D INPUT -p tcp -m multiport --dports smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s -j fail2ban-sasl
iptables -F fail2ban-sasl
iptables -X fail2ban-sasl returned 100
2011-08-08 15:14:45,382 fail2ban.actions.action: ERROR iptables -N fail2ban-apache-noscript
iptables -A fail2ban-apache-noscript -j RETURN
iptables -I INPUT -p tcp -m multiport --dports http,https -j fail2ban-apache-noscript returned 400

Il existe deux solutions:

1) Modifier le fichier /usr/bin/fail2ban-client

'''Faite une sauvegarde de auparavant...'''

Editez le fichier /usr/bin/fail2ban-client et ajoutez une temporisation (time.sleep(0.1)) à cet endroit:

def __processCmd(self, cmd, showRet = True):
beautifier = Beautifier()
for c in cmd:
time.sleep(0.1)
beautifier.setInputCmd(c)

Si la temporisation à 0.1 ne suffit pas, mettez 0.2. et redémarrez fail2ban.

2) Installer une version supérieure (Fixed in version fail2ban/0.8.5-2)

Installer la version testing (8.6-3 0) ou celle des backports (8.6-3~bpo60+1)

== Fail2ban et ipv6 (EXPERIMENTAL) ==

Vous le savez, l'ipv6 se généralise, lancement officiel le 6 juin 2012
Quid de fail2ban ? Malheureusement, fail2ban ne supporte pas encore l'ipv6.
Heureusement, il existe un patch qui permet d'avoir fail2ban activé sur votre ipv6...

Mode d'emploi:

Téléchargez le patch:
<pre>
wget http://thanatos.trollprod.org/sousites/fail2banv6/fail2ban-ipv6.tar.bz2
--2012-04-14 09:30:31-- http://thanatos.trollprod.org/sousites/fail2banv6/fail2ban-ipv6.tar.bz2
Résolution de thanatos.trollprod.org (thanatos.trollprod.org)... 94.23.14.97, 2001:41d0:2:f61::fed1:fe54
Connexion vers thanatos.trollprod.org (thanatos.trollprod.org)|94.23.14.97|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 2293 (2,2K) [application/x-bzip]
Sauvegarde en : «fail2ban-ipv6.tar.bz2»

100%[=============================================================================================>] 2 293 --.-K/s ds 0,001s

2012-04-14 09:30:31 (2,98 MB/s) - «fail2ban-ipv6.tar.bz2» sauvegardé [2293/2293]
</pre>

mkdir fail2ban-ipv6
tar xvjf fail2ban-ipv6.tar.bz2 -C fail2ban-ipv6

cp /usr/share/fail2ban/server/filter.py /usr/share/fail2ban/server/filter.py.sos
cp /usr/share/fail2ban/server/failregex.py /usr/share/fail2ban/server/failregex.py.sos

Testez les patch:

cd /usr/share/fail2ban/server/

root@nas:/usr/share/fail2ban/server# patch -p0 --dry-run < /root/fail2ban-ipv6/patchfilter.patch
patching file filter.py
Hunk #1 succeeded at 525 (offset 14 lines).
Hunk #2 succeeded at 549 (offset 14 lines).
Hunk #3 succeeded at 580 (offset 14 lines).

root@nas:/usr/share/fail2ban/server# patch -p0 --dry-run < /root/fail2ban-ipv6/regex.patch
patching file failregex.py
Hunk #1 succeeded at 47 (offset 3 lines).

Si le résultat est positif (pas d'erreur) lancez les patchs

root@nas:/usr/share/fail2ban/server# patch -p0 < /root/fail2ban-ipv6/patchfilter.patch
patching file filter.py
Hunk #1 succeeded at 525 (offset 14 lines).
Hunk #2 succeeded at 549 (offset 14 lines).
Hunk #3 succeeded at 580 (offset 14 lines).
root@nas:/usr/share/fail2ban/server# patch -p0 < /root/fail2ban-ipv6/regex.patch
patching file failregex.py
Hunk #1 succeeded at 47 (offset 3 lines).

Copiez les fichiers nécessaires:

root@nas:/usr/share/fail2ban/server# cp /root/fail2ban-ipv6/ip64tables.sh /usr/bin/
root@nas:/usr/share/fail2ban/server# chmod 755 /usr/bin/ip64tables.sh
root@nas:/usr/share/fail2ban/server# cp /root/fail2ban-ipv6/iptables46-multiport.conf /etc/fail2ban/action.d/
root@nas:/usr/share/fail2ban/server# chmod 644 /etc/fail2ban/action.d/iptables46-multiport.conf

Créez le bloc de configuration:

nano /etc/fail2ban/jail.conf

...
[ssh-ip6tables]
enabled = true
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
action = iptables46-multiport[name=SSH, port=22, protocol=tcp]
sendmail-whois[name=SSH, dest=root, sender=fail2ban@mail.com]
...

Redémarrez fail2ban et vérifiez qu'il est actif:

service fail2ban restart
Restarting authentication failure monitor: fail2ban.
ip6tables -S
...
-N fail2ban-SSH
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-SSH
-A fail2ban-SSH -j RETURN

Avertissement:
# N'a pas encore été testé
# Ne pas activer la résolution de nom dans les logs

== Liens externes ==

Je vous encourage à lire:

* La page de man de fail2ban
* [http://www.fail2ban.org/wiki/index.php/Main_Page Le Wiki de fail2ban - Très complet]

[[Catégorie:Sécurité]]

Datasheet/Firewalld

2016-09-17T07:38:44Z

Didier : /* Commandes de modification */

{{Datasheet}}
= Firewalld =

Gestion du firewall

== Introduction ==

Firewalld est une surcouche aux outils netfilter traditionnels: iptables, ip6tables et ebtables qui permet une gestion dynamique des règles, c'est à dire que les règles sont appliquées sans le redémarrage complet du parefeu. Les règles existantes restent donc en place, et les modules noyaux complémentaires utilisés ne sont pas déchargés.

Avec iptables en direct, il fallait soit ré-appliquer l'ensemble des règles, soit appliqué la modification au runtime (non triviale car les règles sont forcément empilées par le dessus), puis aux fichiers pour le prochain redémarrage.

Avec firewalld, il n'y a plus de période (très courte) sans protection, ni de rupture dans le suivi des connexions (related established)
{{Admon/warning|Utilisation des outils traditionnels netfiter|L'utilisation de FirewallD implique que les commandes <app>iptables</app>, <app>ip6tables</app> et <app>ebtables</app> ne soient plus utilisées directement. 
De plus les fichiers <path>/etc/sysconfig/iptables</path>, <path>/etc/sysconfig/ip6tables</path> et <path>/etc/sysconfig/ebtables<chain></path> ne sont plus utilisés.}}

Les fichiers de configurations:
* configuration par défaut dans des fichiers au format XML dans le répertoire <path>/usr/lib/firewalld</path>. Ils sont susceptibles d'être modifiés par une mise à jour.
* configuration effectuée par l'administrateur ou les utilisateurs dans le répertoire <path>/etc/firewalld</path>.

== Les zones ==

FirewallD intègre une notion de zones de réseaux.

* A chaque zone de réseau est associé un ensemble de services réseaux accessibles de l'extérieur, suivant la confiance que l'on accorde à cet "extérieur".
* Les interfaces réseaux (ifaces) peuvent être affectées à une zone de réseau.
{{Admon/important|Par défaut, le trafic sortant est toujours autorisé ainsi que les connexions déja établies|Seules les caractéristiques du trafic entrant seront à préciser.}}

Détails des zones:
* '''trusted''' (non modifiable): un vLAN dédié considéré comme totalement fiable (Réseau dédié pour du RAID sur IP, etc...).
* '''home''': un LAN considéré comme partielement fiable
* '''work''': un autre LAN considéré comme partielement fiable
* '''internal''': un autre LAN considéré comme partielement fiable
* '''dmz''': une DMZ très peu fiable (sans DHCP)
* '''public''': un réseau non fiable
* '''external''': un réseau non fiable (sans DHCP)
* '''block''' (non modifiable): l'intégralité du traffic est bloqué (reject)
* '''drop''' (non modifiable): l'intégralité du traffic est ignoré (drop)

== Les commandes ==

Certaines commandes n'ont pas de sortie, il faut donc analyser le code de retour.

=== Commandes de statut ===
* Statut du firewall<pre>firewall-cmd --state</pre>
* Obtenir la zone par défaut<pre>firewall-cmd --get-default-zone</pre>
* Obtenir la zone courante<pre>firewall-cmd --get-active-zone</pre>
* Obtenir la zone associé à l'interfcae réseau eth0<pre>firewall-cmd --get-zone-of-interface=eth0</pre>
* Lister les services autorisés pour la zone ''public''<pre>firewall-cmd --zone=public --list-services</pre>

=== Commandes de modification ===
Les commandes persistantes doivent être suivi d'un rechargement du service (reload)
* Reload du firewall (sans perte d'information sur le suivi de connexion)<pre>firewall-cmd --reload</pre>
* Ouvrir le firewall (runtime only) pour les connexions http<pre>firewall-cmd --add-service=smtp</pre>
* Ouvrir le firewall (runtime et persistant) pour les connexions http<pre>firewall-cmd --persistant --add-service=smtp</pre>
* Fermer le firewall (runtime et persistant) pour les connexions http<pre>firewall-cmd --persistant --remove-service=smtp</pre>
* Ouvrir le firewall (runtime et persistant) pour les connexions sur le port TCP 8080<pre>firewall-cmd --persistant --add-port=8080/tcp</pre>
* Bloquer une adresse en particulier (runtime et persistant)<pre>firewall-cmd --persistant --add-rich-rule="rule family=ipv4 source address=115.0.0.0/8 drop"</pre>

== Liens ==
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html Documentation Redhat]

Fichier:DockerContainer.svg

2016-04-19T14:34:56Z

Didier : Exemple de Conteneurs Docker

Exemple de Conteneurs Docker

Fichier:Virtualisation-Container.svg

2016-04-19T14:34:34Z

Didier : Virtualisation par conteneur

Virtualisation par conteneur

Fichier:Virtualisation-Hyperviser.svg

2016-04-19T14:34:17Z

Didier : Virtualisation par hyperviseur

Virtualisation par hyperviseur

Virt/Docker

2016-04-19T14:32:55Z

Didier : Page créée avec « Logo Docker == Théorie == [https://www.docker.com/ Docker] est donc une plateforme de virtualisation par conteneur qui, contrairement... »

[[Fichier:LogoDocker.png|centré|Logo Docker]]

== Théorie ==

[https://www.docker.com/ Docker] est donc une plateforme de virtualisation par conteneur qui, contrairement à la virtualisation sur hyperviseur où de nouvelles machines complètes doivent être créée, va permettre de créer des conteneurs qui vont uniquement contenir une ou plusieurs applications. Empaquetées sous forme de conteneurs, ces applications pourront ainsi être facilement déployées sur tout hôte exécutant Docker, chaque conteneur restant parfaitement indépendant !

Le nom et le vocabulaire de cette technologie n’ont pas été choisis au hasard : tout comme les conteneurs en métal, toujours fabriqués selon les mêmes standards, peuvent être pris en charge par n’importe quel transporteur (et peu importe ce qu’il y a dedans), une application « Dockerisée » doit pouvoir être exécutée sur n’importe quel hôte faisant tourner Docker, peu importe son contenu !

=== La virtualisation par hyperviseur ===

[[Fichier:Virtualisation-Hyperviser.svg|Virtualisation par hyperviseur|600px]]

Avec la virtualisation par [https://fr.wikipedia.org/wiki/Hyperviseur hyperviseur] de type 2 (VMware Workstation, VirtualBox…), chaque hôte invité virtualise un environnement complet, ce qui permet notamment de pouvoir exécuter un système virtualisé différent du système hôte (typiquement du Windows sur un GNU/Linux par exemple).

=== La virtualisation par conteneur ===

[[Fichier:Virtualisation-Container.svg|Virtualisation par containeur|600px]]

Dans ce cas, conteneur virtualisé et système hôte sont fortement liés et c’est pour cela que cette technologie, qui existe pourtant depuis longtemps (OpenVZ a déjà presque 10 ans !), était peu répandue jusqu’à maintenant. Certains appellent d’ailleurs ce type de virtualisation la paravirtualisation...

=== Principe d'utilisation ===

Docker simplifie l’utilisation d’outils existants, et c’est sa principale force. S’il est possible d’isoler des conteneurs : processus, interfaces réseau, points de montage, c’est grâce à l’utilisation des '''namespaces''' Linux. Un processus qui s’exécute dans un espace de nom correspondant à un conteneur ne sera visible que par ce conteneur et le système hôte exécutant ce conteneur. En comparant les deux précédents schémas, on remarque que la virtualisation par conteneur est plus rapide que la virtualisation par hyperviseur car les conteneurs ont directement accès aux ressources matérielles de l’hôte. La consommation de ces ressources pouvant être gérées par l’hôte en question grâce aux '''[https://fr.wikipedia.org/wiki/Cgroups control groups]''' (cgroups) du noyau Linux.

Tout ceci fait donc de Docker un '''chroot dopé aux stéroïdes'''.

À ses débuts Docker était une couche d’abstraction à LXC car il permettait de s’affranchir de la complexité de ce dernier en gérant pour nous un certain nombre d’opérations. Aujourd’hui Docker va beaucoup plus loin que LXC puisqu’il dispose de sa propre plate-forme : [http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/ Libcontainer] (bien que LXC soit toujours proposé sous forme de plugin).

Et ce qui démarque Docker des autres, c’est la rapidité de la mise en place des flux de travail : tout est fait pour réduire le temps entre le développement, les tests, le déploiement et l’utilisation de votre application en production. Et pour cela, on trouve les images.

Une image est le composant de base de Docker. C’est un instantané d’un système d’exploitation (par exemple Debian). Ces images sont disponibles sur un dépôt public, géré par Docker, appelé le registre.

==== Les images ====

[[Fichier:DockerContainer.svg|Conteneur Docker|600px]]

L’exemple ci-dessus se compose de deux conteneurs, parfaitement isolés (d’où les couleurs différentes). On trouve à la base les composants nécessaires à Docker, et qui sont fournis par le noyau Linux de l’hôte. On trouve ensuite deux images : Debian et [https://fr.wikipedia.org/wiki/BusyBox BusyBox].

Une image ne peut être modifiée directement, elle reste toujours en lecture seule.

Remarquez qu’un environnement d’exécution peut nécessiter l’empilement de plusieurs images (ici mariadb, puis apache), rendu possible par les fonctionnalités de '''[https://fr.wikipedia.org/wiki/Copy-On-Write copy-on-write]''' des modules de stockages utilisés par Docker ([https://fr.wikipedia.org/wiki/Aufs AuFS], [https://fr.wikipedia.org/wiki/Btrfs Btrfs]).

Enfin, on trouve la couche supérieure, accessible en écriture, qui contiendra toutes les modifications apportées à l’application.
{{Admon/tip||Au lancement d'un conteneur exécutant une application à partir d’une image, Docker va monter le système de fichier de l’image souhaitée en lecture seule, et ajouter une couche accessible en écriture par dessus, via UnionFS.}}
On fait donc de sacrées économies de consommation puisque plusieurs conteneurs utilisant la même image de base utiliseront le même système de fichiers !

==== Le Hub ====

Le [https://hub.docker.com/ Hub Docker] est un GitHub pour les images Docker.

Pour conserver les modifications apportées à l'application, Il faut enregistrer celles-ci dans une nouvelle image qui sera uniquement composée des différences apportées. Cette image sera identifiée par Docker grâce à un numéro unique, et pourra être pousser (push) vers le dépôt public Docker.

Le Docker Hub est aux images ce que git est au code. Les commandes sont les mêmes.

== Installation ==

=== Installation du paquet RPM ===
Docker est supporté sur CentOS 6 et 7, avec de légères différences durant l'installation. Il est vivement recommandé de partir d'un hôte ayant les dernières mises à jour: <code>yum update</code>
* '''CentOS 6''': paquet présent dans le dépôt '''EPEL'''<pre>yum install docker-io</pre>
* '''CentOS 7''': paquet présent dans le dépôt '''EPEL'''<pre>yum install docker</pre>
{{Admon/warning|Version du noyau CentOS 6|Pour utiliser Docker sur CentOS6, il faut, au minimum, un noyau de version '''2.6.32-431''' car celui-ci contient des adaptations pour exécuter Docker.}}

=== Exécuter Docker sans les droits root ===

La documentation nous indique que le daemon Docker tourne toujours avec l’utilisateur root, et qu’il se connecte à une [https://fr.wikipedia.org/wiki/Berkeley_sockets#Types_de_sockets socket Unix] en lieu et place d’un socket TCP. L’utilisateur root est par défaut propriétaire de ce socket Unix, et ne peut donc être accessible qu’avec la commande sudo.

Pour éviter d’utiliser sudo à tort et à travers, nous allons pouvoir créer un groupe Unix nommé '''docker''' pour nous y ajouter. Ainsi, les propriétés du daemon docker seront modifiées pour que celui-ci soit accessible en lecture / écriture pour les membres du groupe docker. Certes le daemon doit toujours fonctionner en tant que root, mais si nous utilisons le client docker en tant que membre du groupe docker, alors nous n’aurons plus besoin d’utiliser sudo.

<syntaxhighlight lang="bash">
# On ajoute le groupe docker s'il n'existe pas déjà.
groupadd docker

# On ajoute l'utilisateur courant (nous) "${USER}" au groupe.
# On peut y mettre n'importe quel utilisateur
# Il faudra se reconnecter pour que les modifications prennent effet.
gpasswd -a ${USER} docker

# On redémarre le daemon.
service docker restart
</syntaxhighlight>

C’est du bonus hein… Cela permet aussi de gérer la [https://docs.docker.com/articles/security/#dockersecurity-daemon surface d’attaque] de Docker, mais vous pouvez très bien sauter cette étape et continuer à utiliser Docker avec sudo.

=== Tests ===

<pre>docker version</pre>
<pre>
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d/1.7.1
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d/1.7.1
OS/Arch (server): linux/amd64
</pre>

<pre>docker info</pre>
<pre>
Images: 7
Storage Driver: devicemapper
Pool Name: docker-253:0-1183660-pool
Pool Blocksize: 65.54 kB
Backing Filesystem: extfs
Data file: /dev/loop0
Metadata file: /dev/loop1
Data Space Used: 957.5 MB
Data Space Total: 107.4 GB
Data Space Available: 24.65 GB
Metadata Space Used: 1.507 MB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.146 GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Data loop file: /var/lib/docker/devicemapper/devicemapper/data
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
Library Version: 1.02.95-RHEL6 (2015-09-08)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 2.6.32-573.22.1.el6.x86_64
Operating System: <unknown>
CPUs: 8
Total Memory: 7.685 GiB
Name: webdev-test.b2pweb.com
ID: TZXP:Z74H:7XCC:JMST:ZAKF:R5Y5:DSOR:JHGO:Z4GC:T3SZ:662F:3NR2
</pre>

== Les conteneurs ==

Pour récupérer une image, on va interroger le [https://hub.docker.com/ docker hub] pour lister toutes les images du registre:
<pre>docker search centos</pre>
<pre>
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
centos The official build of CentOS. 2147 [OK]
jdeathe/centos-ssh CentOS-6 6.7 x86_64 / CentOS-7 7.2.1511 x8... 20 [OK]
jdeathe/centos-ssh-apache-php CentOS-6 6.7 x86_64 / Apache / PHP / PHP M... 16 [OK]
nimmis/java-centos This is docker images of CentOS 7 with dif... 8 [OK]
torusware/speedus-centos Always updated official CentOS docker imag... 7 [OK]
nickistre/centos-lamp LAMP on centos setup 3 [OK]
centos/mariadb55-centos7 3 [OK]
[...]
</pre>
Un grand nombre de résultats sont proposés. On observe que le premier résultat indique une image CentOS officielle, ce qui nous assure qu’elle a été validée par l’équipe de Docker. Les images gérées par l’équipe de Docker se remarquent par le format de leur nom, qui est de la forme nom-image alors que les '''non-officielles''' sont plutôt de la forme '''utilisateur/nom-image'''.

On récupère l'image officielle CentOS 7 (latest)
<pre>docker pull centos</pre>
<pre>
latest: Pulling from centos
47d44cb6f252: Pull complete
8aa7f4a1dd13: Pull complete
e0f5867add13: Pull complete
eeb3a076a0be: Pull complete
Digest: sha256:1b9adf413b3ab95ce430c2039954bb0db0c8e2672c48182f2c5b3d30373d5b71
Status: Downloaded newer image for centos:latest
</pre>
ainsi quer la version 6
<pre>docker pull centos:6</pre>
<pre>
6: Pulling from centos
9868edceea88: Pull complete
e0eab6e60b7e: Pull complete
61bf77ab8841: Pull complete
47d44cb6f252: Already exists
Digest: sha256:57f0027b92985edbd0eb87818b73d5dd771dd5955e6b794d624c8a79a4bd4795
Status: Downloaded newer image for centos:6
</pre>
On liste les images déjà téléchargées. La sortie de la commande suivante indique que nous avons récupéré les image portant l’ID 61bf77ab8841 et eeb3a076a0be dans le dépôt intitulé « centos ». Un ID permet d’identifier de manière unique la version d’une image. Ensuite, comme un ID n’est pas forcément explicite pour désigner une version, on lui affecte un ou plusieurs tags, ici « latest » et « 6 ». Plusieurs tags peuvent effectivement désigner la même image, mais chaque version d’image ne possède qu’un ID.
<pre>docker images</pre>
<pre>
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
centos 6 61bf77ab8841 2 weeks ago 228.9 MB
centos latest eeb3a076a0be 2 weeks ago 196.7 MB
</pre>
L'empilement peut être affiché avec l'option '''--all'''
<pre>docker images --all</pre>
<pre>
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
centos 6 61bf77ab8841 2 weeks ago 228.9 MB
<none> <none> e0eab6e60b7e 2 weeks ago 228.9 MB
<none> <none> 9868edceea88 2 weeks ago 228.9 MB
centos latest eeb3a076a0be 2 weeks ago 196.7 MB
<none> <none> e0f5867add13 2 weeks ago 196.7 MB
<none> <none> 8aa7f4a1dd13 2 weeks ago 196.7 MB
<none> <none> 47d44cb6f252 7 months ago 0 B
</pre>
Les images intermédiaires correspondent aux différentes commandes qui ont été utilisées pour générer l’image finale. Ces commandes peuvent être affichées avec la commande history.
<pre>docker history centos:6</pre>
<pre>
IMAGE CREATED CREATED BY SIZE COMMENT
61bf77ab8841 2 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B
e0eab6e60b7e 2 weeks ago /bin/sh -c #(nop) LABEL name=CentOS Base Imag 0 B
9868edceea88 2 weeks ago /bin/sh -c #(nop) ADD file:ae8f506cbd1f016c67 228.9 MB
47d44cb6f252 7 months ago /bin/sh -c #(nop) MAINTAINER The CentOS Proje 0 B
</pre>

=== Premiers lancements ===

On lance notre premier conteneur. Évidemment l'intérêt est purement éducatif, car celui-ci ne fera qu'afficher <code>Hello World!</code> et se terminera.
{{Admon/important|Durée de vie des conteneurs|La durée de vie d’un conteneur dépend directement du temps de vie des processus qui y sont exécutés.}}
<pre>docker run centos:latest /bin/echo 'Hello World!'</pre>
<pre>
Hello World!
</pre>

On lance maintenant l'interpréteur Bash à l'intérieur de notre conteneur. L'option '''i''' laisse l'entrée standard ouverte et l'option '''t''' alloue un pseudo-terminal à la commande.
<pre>docker run -t -i centos:6 /bin/bash</pre>
<pre>
[root@a3bcca2ae195 /]# hostname
a3bcca2ae195
[root@a3bcca2ae195 /]# exit
exit
</pre>

On liste nos conteneurs (l'option -a permet d'afficher tous les conteneurs car seul les actifs sont affiché par défaut).
<pre>docker ps -a</pre>
<pre>
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a3bcca2ae195 centos:6 "/bin/bash" 35 seconds ago Exited (0) 12 seconds ago angry_goodall
f947fb083eaa centos:6 "/bin/echo 'Hello Wo About a minute ago Exited (0) About a minute ago ecstatic_kirch
b6710cdfbcb1 centos:latest "/bin/echo 'Hello Wo About a minute ago Exited (0) About a minute ago lonely_feynman
</pre>

On peut visualiser tous les détails d'une image
<pre>docker inspect centos:6</pre>
<syntaxhighlight lang="json">
[
{
"Id": "61bf77ab884102c059826f37af32b766aec3a0145af35dbc296bc33754e74757",
"Parent": "e0eab6e60b7ea4336660dfcbc7ce837621f191d7d6ea587cdf225eecd2001dc6",
"Comment": "",
"Created": "2016-04-01T21:29:01.147650406Z",
"Container": "01a4934c6001e17bfa875876616d915ee5c7a2fdd094f63c4ff84c70a9da3c43",
"ContainerConfig": {
"Hostname": "4d7e41fcce2c",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"PortSpecs": null,
"ExposedPorts": null,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": null,
"Cmd": [
"/bin/sh",
"-c",
"#(nop) CMD [\"/bin/bash\"]"
],
"Image": "e0eab6e60b7ea4336660dfcbc7ce837621f191d7d6ea587cdf225eecd2001dc6",
"Volumes": null,
"VolumeDriver": "",
"WorkingDir": "",
"Entrypoint": null,
"NetworkDisabled": false,
"MacAddress": "",
"OnBuild": null,
"Labels": {
"build-date": "2016-03-31",
"license": "GPLv2",
"name": "CentOS Base Image",
"vendor": "CentOS"
}
},
"DockerVersion": "1.9.1",
"Author": "The CentOS Project \u003ccloud-ops@centos.org\u003e",
"Config": {
"Hostname": "4d7e41fcce2c",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"PortSpecs": null,
"ExposedPorts": null,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": null,
"Cmd": [
"/bin/bash"
],
"Image": "e0eab6e60b7ea4336660dfcbc7ce837621f191d7d6ea587cdf225eecd2001dc6",
"Volumes": null,
"VolumeDriver": "",
"WorkingDir": "",
"Entrypoint": null,
"NetworkDisabled": false,
"MacAddress": "",
"OnBuild": null,
"Labels": {
"build-date": "2016-03-31",
"license": "GPLv2",
"name": "CentOS Base Image",
"vendor": "CentOS"
}
},
"Architecture": "amd64",
"Os": "linux",
"Size": 0,
"VirtualSize": 228912764
}
]
</syntaxhighlight>

=== Démonisation ===

On va daemoniser notre conteneur avec l'option '''d'''. Cette fois la sortie est l'ID du conteneur.
<pre>docker run -t -i -d centos:6 /bin/bash</pre>
<pre>713ed98359e25eebd6316831d192c9094d5ec7b5bb8f1907ad444db8eabbb298</pre>

Afin de se simplifier la vie, on va obtenir son petit nom
<pre>docker ps</pre>
<pre>
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
713ed98359e2 centos:6 "/bin/bash" 2 minutes ago Up 2 minutes gloomy_jones
</pre>

* Pour visualiser la sortie standard de notre conteneur daemonisé, on lance la commande
** avec l'ID<pre>docker logs 713ed98359e25eebd6316831d192c9094d5ec7b5bb8f1907ad444db8eabbb298</pre>
** avec son nom<pre>docker logs gloomy_jones</pre>
* On peut s'attacher à ce conteneur<pre>docker attach gloomy_jones</pre>
* Le mettre en pause<pre>docker pause gloomy_jones</pre>
* Le sortir de sa léthargie imposée<pre>docker unpause gloomy_jones</pre>
* L'arrêter<pre>docker stop gloomy_jones</pre>
* Le renommer<pre>docker rename gloomy_jones centos6</pre>
* Le supprimer<pre>docker rm centos6</pre>

== Les commits ==
== Les liaisons ==
== Les volumes ==

Fichier:Virtualisation-Container.png

2016-04-19T08:07:29Z

Didier : Pile de la virtualisation par containeur

Pile de la virtualisation par containeur

Fichier:Virtualisation-Hyperviser.png

2016-04-19T08:07:16Z

Didier : Pile de la virtualisation par hyperviseur

Pile de la virtualisation par hyperviseur

Fichier:LogoDocker.png

2016-04-19T08:06:43Z

Didier : Logo Docker

Logo Docker

RPM

2016-02-26T09:44:51Z

Didier : /* Commande rpm */

{{Admon/tip|<big><big>Fedora Packaging</big></big>|
* [https://admin.fedoraproject.org FAS Account]
* [http://fedoraproject.org/wiki/Packaging:Guidelines Guidelines]
* [http://fedoraproject.org/wiki/Changes/FormatSecurity Format Security]
* [http://fedoraproject.org/wiki/Package_SCM_admin_requests SCM Requests]
* [https://fedoraproject.org/wiki/Using_Fedora_GIT Using git and fedpkg]
* [https://fedoraproject.org/wiki/Using_the_Koji_build_system Using the Koji build system]
* [https://admin.fedoraproject.org/pkgdb Package Database]: manage contact, package admins (bodhi), etc...
* [http://fedoraproject.org/wiki/New_package_process_for_existing_contributors Package process for existing contributors]
* [http://fedoraproject.org/wiki/Package_Review_Process Package Review Process]
* [https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Join the package collection maintainers]
* [https://fedoraproject.org/wiki/Package_update_HOWTO Updating Package HowTo]
}}

== Commande rpm ==
* [[RPM/Using|Utiliser la commande <app>rpm</app>]]
* [[RPM/UsingYum|Utiliser la commande <app>yum</app>]]
* [[RPM/DNF/FAQ| F.A.Q. concernant <app>dnf</app>]]
* [[RPM/DNFvYUM|Comparatif de <app>dnf</app> et de <app>yum</app>]]
* [[RPM/Troubleshooting|Gérer les problèmes liés aux RPMs]]

== Spec file ==
* [[RPM/Spec|Fichiers Spec]]

== Building environment ==
* [[RPM/Environnement|Building Environment]]

== Packaging Guideline ==
* [[RPM/Guidelines|Packaging Guidelines]], which contains '''MUST''' and '''SHOULD''' check list

== Rpmlint ==
* [[RPM/rpmlinterror|Common errors with rpmlint]]

== Mock ==
*Configuration example about [[RPM/Mock|Mock]]

== Makefile ==
* Fichier commun [[RPM/CommonMakefile|Makefile]]

== Sign RPM ==
* [[RPM/Sign|Sign RPM]]

== Koji ==
{{:Koji}}

RPM/Troubleshooting

2016-02-26T09:44:38Z

Didier : Page créée avec « == Problèmes de dépendances == Pour visualiser les dépendances d'un paquet <pre>yum deplist <PACKAGE></pre> ou <pre>rpm -q --required <PACKAGE></pre> == Problèmes su... »

== Problèmes de dépendances ==

Pour visualiser les dépendances d'un paquet
<pre>yum deplist <PACKAGE></pre>
ou
<pre>rpm -q --required <PACKAGE></pre>

== Problèmes suite à une mise à jour ==

On essaie de remettre une version plus ancienne
<pre>yum downgrade <PACKAGE></pre>
ou
<pre>rpm -Uvh --oldpackage [--force] <PACKAGE></pre>

On peut maintenant visualiser les mises à jour disponibles
<pre>yum list updates <PACKAGE></pre>

Si le problème est résolu, on peut bloquer la version pour ce paquet.
# On installe le plugin yum/dnf
#* Yum <pre>yum install yum-plugin-versionlock</pre>
#* Dnf <pre>dnf install 'dnf-command(versionlock)'</pre>
# On bloque la version<pre>yum versionlock add <PACKAGE></pre>

Commandes utiles pour gérer les verrous
* Lister les verrous<pre>yum versionlock list</pre>
* Débloquer le verrou d'un paquet<pre>yum versionlock del <PACKAGE></pre>
* Débloquer tous les verrous<pre>yum versionlock clear</pre>

== Problèmes de Bases de données RPM corrompues ==

# On supprime les blocage: fermeture (normale puis forcée si besoin) des programmes utilisant les bases<pre>lsof | grep /var/lib/rpm</pre>
# On supprime les index<pre>rm -f /var/lib/rpm/__db.00*</pre>
# On vérifie l'intégrité des bases de données<pre>/usr/lib/rpm/rpmdb_verify /var/lib/rpm/*</pre>
# Si une base est corrompue, on peut importer une base à partir d'un export de celle qui est corrompue<pre>mv /var/lib/rpm/Packages /var/lib/rpm/packages.bad</pre><pre>/usr/lib/rpm/rpmdb_dump /var/lib/rpm/Packages.bad | /usr/lib/rpm/rpmdb_load /var/lib/rpm/Packages</pre>
# On reconstruit les index<pre>rpm -v --rebuilddb</pre>

== Vérification des paquets installés et résolution des différences ==

Pour vérifier que les fichiers d'un paquet RPM soient d'origine, on lance la commande suivante et elle ne doit pas donner de sortie si les fichiers ne sont modifiés.
L'option -v affichera tous les fichiers (y compris ceux qui ne sont pas modifiés)
<pre>rpm -V <PACKAGE></pre>
De même on peut vérifier tout le système
<pre>rpm -Va </pre>

On peut aller plus loin avec yum en installant un plugin
<pre>
yum install yum-plugin-verify
</pre>
et ainsi vérifier le paquet avec l'argument
* '''verify''': vérifier l'absence de doublon dans les versions et la non-modificcation de fichier (sauf les fichiers de configuration) pour ce paquet
* '''verify-rpm''': chercher toutes les modifications par rapport au paquet:
** '''S''': taille (file Size differs)
** '''M''': permissions (Mode differs,includes permissions and file type)
** '''5''': somme de contrôle (en général MD5) (5 digest (formerly MD5 sum) differs)
** '''D''': Numéro majeure et mineure pour les fichiers de périphérique de <path>/dev</path> (Device major/minor number mismatch)
** '''L''': cible d'un lien symbolique (readlink path mismatch)
** '''U''': propriétaire (User ownership differs)
** '''G''': groupe (Group ownership differs)
** '''T''': date de dernière modification (mTime differs)
** '''P''': capacités (caPabilities differ): exemple le paquet <package>apache</package> a comme capacité supplémentaire webserver
* '''all''': lance les deux vérifications précédentes

exemple
<pre>
rpm -Vv b2pweb-release
......... c /etc/pki/rpm-gpg/RPM-GPG-KEY-B2PWEB-7
S.5....T. c /etc/yum.repos.d/b2pweb.repo
</pre>
On peut voir que le fichier <path>/etc/pki/rpm-gpg/RPM-GPG-KEY-B2PWEB-7</path> est d'origine, alors que le fichier <path>/etc/yum.repos.d/b2pweb.repo</path> a été modifié: Taille (S), checksum (5) et mtime (T) différents.

et maintenant avec yum
<pre>
yum verify b2pweb-release
Modules complémentaires chargés : fastestmirror, verify
verify done
</pre>
Pas de doublon pour ce paquet (multilib, etc...) et les fichiers ne sont pas modifiés (hormis les fichiers de configuration, ce qui est le cas pour <path>/etc/yum.repos.d/b2pweb.repo</path>)
<pre>
yum verify-rpm b2pweb-release
Modules complémentaires chargés : fastestmirror, verify
==================== Installed Packages ====================
b2pweb-release.noarch : B2PWeb repository
File: /etc/yum.repos.d/b2pweb.repo
Tags: configuration
Problem: checksum does not match
Current: sha256:376f90323acef154dc7f57e087d71522f85f4ce0422a482fcc8f067ef254f94b
Original: sha256:196f897a18f425ed006f1fba965ff7e769e413f42eeea6a4aafe82d0e4c2ba21
--------
Problem: size does not match
Current: 452
Original: 402
--------
Problem: mtime does not match
Current: Fri Jan 29 11:40:03 2016 (279 days, 22:56:31 later)
Original: Fri Apr 24 12:43:32 2015
verify-rpm done
</pre>
Là on voit mieux ce qui a été modifié

On peut simplement remettre les permissions d'origine avec la commande
<pre>rpm --setperms <PACKAGE></pre>
et les bon propriétaires/groupes
<pre>rpm --setugids <PACKAGE></pre>

ou avec yum, on ré-installe le tout, mais il faudra gérer les fichiers avec l'extension ''rpmnew'' et ''rpmsave''.
<pre>yum reinstall <PACKAGE></pre>

IDS/Tripwire

2016-01-20T10:11:23Z

Didier : /* Décrypter un rapport */

== Installation ==

L'installation est triviale car le paquet est présent dans les dépôts de base Fedora et dans les dépôts '''[[Distributions#D.C3.A9p.C3.B4ts_Additionnels_2|EPEL]]''' pour CentOS.
yum install tripwire

== Initialisation de l'application ==

L'installation via RPM installe un fichier de configuration et un fichier définissant la politique par défaut dans le dossier <path>/etc/tripwire</path>. Ces fichiers ne peuvent être utilisés directement par tripwire, car celui-ci travaille avec des fichiers cryptés.

La documentation (la page man de tripwire contient toutes les informations nécessaires) nous apprend qu'il va nous falloir 2 clés:
* '''site.key''': Une clé servant à encrypter le fichier de définition de la politique sur un ou plusieurs systèmes
* '''hostname-local.key''': Une autre clé servant uniquement à crypter les fichiers utilisés localement (il est donc unique sur chaque système)
Suivant l'opération à effectuer, une ou deux clés seront requises.

=== Méthode manuelle ===

Génération de deux clés
<pre>
twadmin -m G -v -S /etc/tripwire/site.key -Q passphrase
twadmin -m G -v -L /etc/tripwire/hostname-local.key -P passphrase
</pre>

Une fois les clés générées, on va pouvoir encrypter le fichier de configuration et le fichier définissant la politique. C'est une protection contre la modification des fichiers par un éventuelle attaquant.
<pre>
twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twcfg.txt
twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twpol.txt
</pre>

=== Avec un Script ===

<pre>tripwire-setup-keyfiles</pre>
<pre>

----------------------------------------------
The Tripwire site and local passphrases are used to sign a variety of
files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain both
letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file:
/etc/tripwire/twcfg.txt
has been preserved for your inspection. It is recommended that you
move this file to a secure location and/or encrypt it in place (using a
tool such as GPG, for example) after you have examined it.

----------------------------------------------
Signing policy file...
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file:
/etc/tripwire/twpol.txt
has been preserved for your inspection. This implements a minimal
policy, intended only to test essential Tripwire functionality. You
should edit the policy file to describe your system, and then use
twadmin to generate a new signed copy of the Tripwire policy.

Once you have a satisfactory Tripwire policy file, you should move the
clear-text version to a secure location and/or encrypt it in place
(using a tool such as GPG, for example).

Now run "tripwire --init" to enter Database Initialization Mode. This
reads the policy file, generates a database based on its contents, and
then cryptographically signs the resulting database. Options can be
entered on the command line to specify which policy, configuration, and
key files are used to create the database. The filename for the
database can be specified as well. If no options are specified, the
default values from the current configuration file are used.
</pre>

== Utilisation ==

=== Premier lancement ===

On va lancer la génération de la base avec la politique par défaut, l'affinage se fera dans un second temps, après la première vérification.
tripwire --init

Le premier rapport de tripwire va contenir beaucoup de faux-positif, car la politique par défaut est généraliste.
<pre>
### Warning: File system error.
### Filename: /usr/sbin/fixrmtab
### Aucun fichier ou dossier de ce type
### Continuing...
</pre>
On va donc lister tous les fichiers inexistant en générant un rapport de vérification
tripwire --check | grep '### Filename' | tee twtest.txt
et commenter les fichiers inexistants dans le fichier de définition de la politique <path>/etc/tripwire/twpol.txt</path>

=== Modification de la politique ===

Une fois le fichier de définition de la politique modifié, il faut l'encrypter et ré-initialiser la base de données
<pre>
twadmin --update-policy /etc/tripwire/twpol.txt
tripwire --init
</pre>

=== Modification sur le système ===

Une fois le système modifié, suite à une mise à jour par exemple, il faut mettre à jour la base de données de tripwire en acceptant les modifications d'un rapport (en général le dernier rapport créé) servant de référence.

Tripwire ne va mettre à jour que les éléments rapportés dans ce rapport (ajout/suppression/modification), ce qui rend l'opération très rapide.
tripwire --update -a --twrfile /var/lib/tripwire/report/localhost-lastest.twr

=== Décrypter un rapport ===

Les rapports tripwire (localisés dans <path>/var/lib/tripwire/report/</path>) étant cryptés, la lecture doit se faire à l'aide d'un utilitaire fournit par le paquet tripwire
twprint --print-report --twrfile /var/lib/tripwire/report/localhost-lastest.twr

=== Génération manuelle de signature ===

Le paquet tripwire fournit un utilitaire calculant les sommes de contrôle d'un fichier
<pre>
siggen /root/.bashrc
--------------------------------------------------------------------------------
Signatures for file: /root/.bashrc

CRC32 BHT0Cs
MD5 CwY+CrtjstBa28sj0FsHBr
SHA ACvBSZWywMS6n4W44NqHgCigQGz
HAVAL AocbY3K9hcyO229F8iRtCk
--------------------------------------------------------------------------------
</pre>

== Durcissement de la sécurité ==

* Tripwire ne peut que constater la modification des fichiers et doit donc être installé/configuré en même temps que la distribution.
* Tripwire n'utilise que la version cryptée des fichier de configuration et de définition de la politique. C'est pourquoi il est recommandé de supprimé les fichiers ''en clair''<pre>rm /etc/tripwire/twpol.txt /etc/tripwire/twcfg.txt</pre>Les fichiers peuvent être générés à partir de leur version cryptée.<pre>twadmin -m p > /etc/tripwire/twpol.txt</pre><pre>twadmin -m f > /etc/tripwire/twcfg.txt</pre>

IDS/Tripwire

2016-01-20T10:09:55Z

Didier :

== Installation ==

L'installation est triviale car le paquet est présent dans les dépôts de base Fedora et dans les dépôts '''[[Distributions#D.C3.A9p.C3.B4ts_Additionnels_2|EPEL]]''' pour CentOS.
yum install tripwire

== Initialisation de l'application ==

L'installation via RPM installe un fichier de configuration et un fichier définissant la politique par défaut dans le dossier <path>/etc/tripwire</path>. Ces fichiers ne peuvent être utilisés directement par tripwire, car celui-ci travaille avec des fichiers cryptés.

La documentation (la page man de tripwire contient toutes les informations nécessaires) nous apprend qu'il va nous falloir 2 clés:
* '''site.key''': Une clé servant à encrypter le fichier de définition de la politique sur un ou plusieurs systèmes
* '''hostname-local.key''': Une autre clé servant uniquement à crypter les fichiers utilisés localement (il est donc unique sur chaque système)
Suivant l'opération à effectuer, une ou deux clés seront requises.

=== Méthode manuelle ===

Génération de deux clés
<pre>
twadmin -m G -v -S /etc/tripwire/site.key -Q passphrase
twadmin -m G -v -L /etc/tripwire/hostname-local.key -P passphrase
</pre>

Une fois les clés générées, on va pouvoir encrypter le fichier de configuration et le fichier définissant la politique. C'est une protection contre la modification des fichiers par un éventuelle attaquant.
<pre>
twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twcfg.txt
twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twpol.txt
</pre>

=== Avec un Script ===

<pre>tripwire-setup-keyfiles</pre>
<pre>

----------------------------------------------
The Tripwire site and local passphrases are used to sign a variety of
files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain both
letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file:
/etc/tripwire/twcfg.txt
has been preserved for your inspection. It is recommended that you
move this file to a secure location and/or encrypt it in place (using a
tool such as GPG, for example) after you have examined it.

----------------------------------------------
Signing policy file...
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file:
/etc/tripwire/twpol.txt
has been preserved for your inspection. This implements a minimal
policy, intended only to test essential Tripwire functionality. You
should edit the policy file to describe your system, and then use
twadmin to generate a new signed copy of the Tripwire policy.

Once you have a satisfactory Tripwire policy file, you should move the
clear-text version to a secure location and/or encrypt it in place
(using a tool such as GPG, for example).

Now run "tripwire --init" to enter Database Initialization Mode. This
reads the policy file, generates a database based on its contents, and
then cryptographically signs the resulting database. Options can be
entered on the command line to specify which policy, configuration, and
key files are used to create the database. The filename for the
database can be specified as well. If no options are specified, the
default values from the current configuration file are used.
</pre>

== Utilisation ==

=== Premier lancement ===

On va lancer la génération de la base avec la politique par défaut, l'affinage se fera dans un second temps, après la première vérification.
tripwire --init

Le premier rapport de tripwire va contenir beaucoup de faux-positif, car la politique par défaut est généraliste.
<pre>
### Warning: File system error.
### Filename: /usr/sbin/fixrmtab
### Aucun fichier ou dossier de ce type
### Continuing...
</pre>
On va donc lister tous les fichiers inexistant en générant un rapport de vérification
tripwire --check | grep '### Filename' | tee twtest.txt
et commenter les fichiers inexistants dans le fichier de définition de la politique <path>/etc/tripwire/twpol.txt</path>

=== Modification de la politique ===

Une fois le fichier de définition de la politique modifié, il faut l'encrypter et ré-initialiser la base de données
<pre>
twadmin --update-policy /etc/tripwire/twpol.txt
tripwire --init
</pre>

=== Modification sur le système ===

Une fois le système modifié, suite à une mise à jour par exemple, il faut mettre à jour la base de données de tripwire en acceptant les modifications d'un rapport (en général le dernier rapport créé) servant de référence.

Tripwire ne va mettre à jour que les éléments rapportés dans ce rapport (ajout/suppression/modification), ce qui rend l'opération très rapide.
tripwire --update -a --twrfile /var/lib/tripwire/report/localhost-lastest.twr

=== Décrypter un rapport ===

Les rapports tripwire (localisé dans <path>/var/lib/tripwire/report/</path>) étant cryptés, la lecture doit se faire à l'aide d'un utilitaire
twprint --print-report --twrfile /var/lib/tripwire/report/localhost-lastest.twr

=== Génération manuelle de signature ===

Le paquet tripwire fournit un utilitaire calculant les sommes de contrôle d'un fichier
<pre>
siggen /root/.bashrc
--------------------------------------------------------------------------------
Signatures for file: /root/.bashrc

CRC32 BHT0Cs
MD5 CwY+CrtjstBa28sj0FsHBr
SHA ACvBSZWywMS6n4W44NqHgCigQGz
HAVAL AocbY3K9hcyO229F8iRtCk
--------------------------------------------------------------------------------
</pre>

== Durcissement de la sécurité ==

* Tripwire ne peut que constater la modification des fichiers et doit donc être installé/configuré en même temps que la distribution.
* Tripwire n'utilise que la version cryptée des fichier de configuration et de définition de la politique. C'est pourquoi il est recommandé de supprimé les fichiers ''en clair''<pre>rm /etc/tripwire/twpol.txt /etc/tripwire/twcfg.txt</pre>Les fichiers peuvent être générés à partir de leur version cryptée.<pre>twadmin -m p > /etc/tripwire/twpol.txt</pre><pre>twadmin -m f > /etc/tripwire/twcfg.txt</pre>

IDS/Tripwire

2016-01-20T10:09:19Z

Didier : /* Modification sur le système */

== Installation ==

L'installation est triviale car le paquet est présent dans les dépôts de base Fedora et dans les dépôts '''[[Distributions#D.C3.A9p.C3.B4ts_Additionnels_2|EPEL]]''' pour CentOS.
yum install tripwire

== Initialisation de l'application ==

L'installation via RPM installe un fichier de configuration et un fichier définissant la politique par défaut dans le dossier <path>/etc/tripwire</path>. Ces fichiers ne peuvent être utilisés directement par tripwire, car celui-ci travaille avec des fichiers cryptés.

La documentation (la page man de tripwire contient toutes les informations nécessaires) nous apprend qu'il va nous falloir 2 clés:
* '''site.key''': Une clé servant à encrypter le fichier de définition de la politique sur un ou plusieurs systèmes
* '''hostname-local.key''': Une autre clé servant uniquement à crypter les fichiers utilisés localement (il est donc unique sur chaque système)
Suivant l'opération à effectuer, une ou deux clés seront requises.

=== Méthode manuelle ===

Génération de deux clés
<pre>
twadmin -m G -v -S /etc/tripwire/site.key -Q passphrase
twadmin -m G -v -L /etc/tripwire/hostname-local.key -P passphrase
</pre>

Une fois les clés générées, on va pouvoir encrypter le fichier de configuration et le fichier définissant la politique. C'est une protection contre la modification des fichiers par un éventuelle attaquant.
<pre>
twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twcfg.txt
twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twpol.txt
</pre>

=== Avec un Script ===

<pre>tripwire-setup-keyfiles</pre>
<pre>

----------------------------------------------
The Tripwire site and local passphrases are used to sign a variety of
files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain both
letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file:
/etc/tripwire/twcfg.txt
has been preserved for your inspection. It is recommended that you
move this file to a secure location and/or encrypt it in place (using a
tool such as GPG, for example) after you have examined it.

----------------------------------------------
Signing policy file...
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file:
/etc/tripwire/twpol.txt
has been preserved for your inspection. This implements a minimal
policy, intended only to test essential Tripwire functionality. You
should edit the policy file to describe your system, and then use
twadmin to generate a new signed copy of the Tripwire policy.

Once you have a satisfactory Tripwire policy file, you should move the
clear-text version to a secure location and/or encrypt it in place
(using a tool such as GPG, for example).

Now run "tripwire --init" to enter Database Initialization Mode. This
reads the policy file, generates a database based on its contents, and
then cryptographically signs the resulting database. Options can be
entered on the command line to specify which policy, configuration, and
key files are used to create the database. The filename for the
database can be specified as well. If no options are specified, the
default values from the current configuration file are used.
</pre>

== Utilisation ==

=== Premier lancement ===

On va lancer la génération de la base avec la politique par défaut, l'affinage se fera dans un second temps, après la première vérification.
tripwire --init

Le premier rapport de tripwire va contenir beaucoup de faux-positif, car la politique par défaut est généraliste.
<pre>
### Warning: File system error.
### Filename: /usr/sbin/fixrmtab
### Aucun fichier ou dossier de ce type
### Continuing...
</pre>
On va donc lister tous les fichiers inexistant en générant un rapport de vérification
tripwire --check | grep '### Filename' | tee twtest.txt
et commenter les fichiers inexistants dans le fichier de définition de la politique <path>/etc/tripwire/twpol.txt</path>

=== Modification de la politique ===

Une fois le fichier de définition de la politique modifié, il faut l'encrypter et ré-initialiser la base de données
<pre>
twadmin --update-policy /etc/tripwire/twpol.txt
tripwire --init
</pre>

=== Modification sur le système ===

Une fois le système modifié, suite à une mise à jour par exemple, il faut mettre à jour la base de données de tripwire en acceptant les modifications d'un rapport (en général le dernier rapport créé) servant de référence.

Tripwire ne va mettre à jour que les éléments rapportés dans ce rapport (ajout/suppression/modification), ce qui rend l'opération très rapide.
tripwire --update -a --twrfile /var/lib/tripwire/report/localhost-lastest.twr

=== Décrypter un rapport ===

Les rapports tripwire (localisé dans <path>/var/lib/tripwire/report/</path>) étant cryptés, la lecture doit se faire à l'aide d'un utilitaire
twprint --print-report --twrfile /var/lib/tripwire/report/localhost-lastest.twr

=== Génération manuelle de signature ===

Le paquet tripwire fournit un utilitaire calculant les sommes de contrôle d'un fichier
<pre>
siggen /root/.bashrc
--------------------------------------------------------------------------------
Signatures for file: /root/.bashrc

CRC32 BHT0Cs
MD5 CwY+CrtjstBa28sj0FsHBr
SHA ACvBSZWywMS6n4W44NqHgCigQGz
HAVAL AocbY3K9hcyO229F8iRtCk
--------------------------------------------------------------------------------
</pre>

== Durcissement de la sécurité ==

* Tripwire ne peut que constater la modification des fichiers et doit donc être installé/configuré en même temps que la distribution.
* Tripwire n'utilise que la version cryptée des fichier de configuration et de définition de la politique. C'est pourquoi il est recommandé de supprimé les fichiers ''en clair''<pre>rm /etc/tripwire/twpol.txt /etc/tripwire/twcfg.txt</pre>Les fichiers peuvent être générés à partir de leur version cryptée.<pre>twadmin -m p > /etc/tripwire/twpol.txt</pre><pre>twadmin -m f > /etc/tripwire/twcfg.txt</pre>

Datasheet/Firefox/AcceptCertificate

2016-01-06T09:01:47Z

Didier : Page créée avec « {{Datasheet}} = Accepter un certificat auto-signé avec Firefox = # On clique sur '''Je comprends les risques''' pour afficher le bouton permettant d'accepter le certific... »

{{Datasheet}}
= Accepter un certificat auto-signé avec Firefox =

# On clique sur '''Je comprends les risques''' pour afficher le bouton permettant d'accepter le certificat [[Fichier:FirefoxAcceptSelfsignedCertificate1.png]]
# On clique sur le bouton {{Button|Ajouter une exception ...}} tout en bas [[Fichier:FirefoxAcceptSelfsignedCertificate2.png]]
# On clique sur le bouton {{Button|Confirmer l'exception de sécurité}} en bas à gauche de la nouvelle fenêtre qui vient de s'ouvrir [[Fichier:FirefoxAcceptSelfsignedCertificate3.png]]

Fichier:FirefoxAcceptSelfsignedCertificate3.png

2016-01-06T09:00:38Z

Didier :

Fichier:FirefoxAcceptSelfsignedCertificate2.png

2016-01-06T09:00:09Z

Didier :

Fichier:FirefoxAcceptSelfsignedCertificate1.png

2016-01-06T08:59:49Z

Didier :

Datasheet

2016-01-06T08:53:48Z

Didier : /* Applications */

== Services ==
* [[Datasheet/LVM|LVM]]
* [[Datasheet/MySQL|MySQL]]
* [[Datasheet/XtraBackup|XtraBackup]]
* [[Datasheet/RHCluster|RedHat Cluster]]
* [[Datasheet/MAJ/Postgresql|Mise à jour de postgresql]]
* [[Datasheet/MAJ/Gitlab|Mise à jour de Gitlab]]
* [[Datasheet/FileSystem/XFS|Erreur de réparation après un crash sur XFS]]
* [[Datasheet/Screen|Screen]]

== Applications ==
* [[Datasheet/Thunderbird/UseDefaultTemplate|Utilisation d'un modèle par défaut dans Thunderbird]]
* [[Datasheet/Firefox/AcceptCertificate|Accepter un certificat auto-signé dans Firefox]]

== Virtualisation ==
* [[Datasheet/Docker|Docker]]
* [[Datasheet/Virsh|Virsh]]
* [[Datasheet/Libguestfs|Libguestfs]]

== Systemd ==
* [[Datasheet/Systemd|Systemd]]
* [[Datasheet/Journalctl|Journalctl]]
* [[Datasheet/Hostnamectl|Hostnamectl]]
* [[Datasheet/Localectl|Localectl]]
* [[Datasheet/Timedatectl|Timedatectl]]
* [[Datasheet/Firewalld|Firewalld]]

== Gestion des RPM ==
* [[Datasheet/yum|Yum]]
* [[Datasheet/Repoquery|Repoquery]]
* [[Datasheet/PackageCleanup|Package-cleanup]]
* [[Datasheet/Fedpkg|Fedpkg]]

CPP/CrossCompilation

2016-01-05T09:48:02Z

Didier :

Pour générer un exécutable windows depuis linux, il faut recourir à ce qu’on appelle la cross-compilation: compiler sur un système pour un autre système.
On va partir d’un simple “Hello world”. A ce propos, j’ai découvert une [https://github.com/leachim6/hello-world collection d’hello world sur Github].

== Compilation d'un fichier unique ==

=== Sources ===

Le fichier source en C

{{Admon/file|main.c|<syntaxhighlight lang="c">
#include<stdio.h>
int main()
{
printf("Hello World !\n");
return 0;
}
</syntaxhighlight>}}

Le fichier source en C++
{{Admon/file|main.cpp|<syntaxhighlight lang="cpp">
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World !" << endl;
return 0;
}
</syntaxhighlight>}}

=== Compilation manuelle ===
==== GNU/Linux ====

Pour GNU/Linux, le fichier C serait compilé avec la commande
<syntaxhighlight lang="bash">
gcc -O0 -Wall -g -o helloc main.c
</syntaxhighlight>
et le fichier C++
<syntaxhighlight lang="bash">
g++ -O0 -Wall -g -o hellocpp main.cpp
</syntaxhighlight>

==== Wind@uze ====

On va se servir des compilateurs mingw (32 et/ou 64 bits)

===== Version 32 bits =====

On installe les compilateurs C et C++ <class>mingw</class> 32 bits ainsi que la collection d'utilitaires
<syntaxhighlight lang="bash">
dnf install mingw32-gcc mingw32-gcc-c++ mingw32-binutils
</syntaxhighlight>
le fichier C sera compilé avec la commande
<syntaxhighlight lang="bash">
i686-w64-mingw32-gcc -O0 -Wall -g -o helloc32.exe main.c
</syntaxhighlight>
et le fichier C++
<syntaxhighlight lang="bash">
i686-w64-mingw32-g++ -O0 -Wall -g -o hellocpp32.exe main.cpp
</syntaxhighlight>
En testant le binaire généré à partir du C++ avec <app>wine</app>, on se rend compte qu’il ne fonctionne pas (absence de DLLs).

{{color|red|err:module:import_dll Library libstdc++-6.dll (which is needed by L"V:\\hello32.exe") not found}}

Pour résoudre ce problème, il va falloir copié quelques DLLs dans le même répertoire que l’exécutable
<syntaxhighlight lang="bash">
cp /usr/i686-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll .
cp /usr/i686-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll .
cp /usr/i686-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll .
</syntaxhighlight>
{{Admon/tip|Test des exécutables avec wine|Wine affiche énormément de trace de debug (FIXME) dans la console et le message provenant de nos exécutables risque d'être noyé au milieu des traces de wine. Il est préférable de désactiver certaines traces:
<syntaxhighlight lang="bash">export WINEDEBUG=fixme-all</syntaxhighlight>
On peut maintenant tester un exécutable
<syntaxhighlight lang="bash">wine win32/cpp-helloworld.exe</syntaxhighlight>}}

===== Version 64 bits =====

On installe les compilateurs C et C++ <class>mingw</class> 64 bits ainsi que la collection d'utilitaires
<syntaxhighlight lang="bash">
dnf install mingw64-gcc mingw64-gcc-c++ mingw64-binutils
</syntaxhighlight>
le fichier C sera compilé avec la commande
<syntaxhighlight lang="bash">
x86_64-w64-mingw32-gcc -O0 -Wall -g -o helloc64.exe main.c
</syntaxhighlight>

et le fichier C++
<syntaxhighlight lang="bash">
x86_64-w64-mingw32-g++ -O0 -Wall -g -o hellocpp64.exe main.cpp
</syntaxhighlight>

Pour résoudre le même problème que la version 32 bits, il va falloir copié quelques DLLs dans le même répertoire que l’exécutable.
<syntaxhighlight lang="bash">
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll .
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_seh-1.dll .
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll .
</syntaxhighlight>

=== Compilation avec Makefile ===
Chaque architecture aura son propre répertoire d'accueil afin d'éviter le chevauchement de DLLs (même nom mais architecture différente) et fabriquera deux binaires: un avec un fichier source en '''C''' et l'autre avec un fichier source en '''C++'''.

On va définir plusieurs cibles principales:
* '''linux''': ce sera la cible par défaut et elle construira les binaires ELF dans le répertoire <path>linux</path>
* '''win32''': elle construira les binaires Windows 32 bits dans le répertoire <path>win32</path>
* '''win64''': elle construira les binaires Windows 64 bits dans le répertoire <path>win64</path>
* '''win''': elle lancera les cibles win32 et win64
* '''all''': elle lancera les cibles linux, win32 et win64
* '''clean''': elle nettoiera le projet
D'autres cibles secondaires seront définies:
* '''tree''': Créera si besoin le répertoire d'accueil des binaires
* '''copy-dll32''': copiera si besoin les DLLs 32 bits dans le répertoire d'accueil des binaires Windows 32 bits
* '''copy-dll64''': copiera si besoin les DLLs 64 bits dans le répertoire d'accueil des binaires Windows 64 bits
{{Admon/tip|@ dans les commandes|Certaines commandes du fichier <path>Makefile</path> sont précédées d'un '''@''' afin de ne pas écrire la commande en cours sur la sortie standard.}}

{{Admon/file|Makefile|<syntaxhighlight lang="make">
CFLAGS=-O0 -Wall -g
CXXFLAGS=-O0 -Wall -g
LDFLAGS=
WINFLAGS=
CTARGET=c-helloworld
CXXTARGET=cpp-helloworld

DLL32_PATH := /usr/i686-w64-mingw32/sys-root/mingw/bin
DLL64_PATH := /usr/x86_64-w64-mingw32/sys-root/mingw/bin

linux: tree c-linux cpp-linux

win: win32 win64

win32: tree c-win32.exe cpp-win32.exe copy-dll32

win64: tree c-win64.exe cpp-win64.exe copy-dll64

all: linux win

tree:
@[ -d linux ] || mkdir linux
@[ -d win32 ] || mkdir win32
@[ -d win64 ] || mkdir win64

cpp-linux:
@g++ $(CXXFLAGS) -o linux/$(CXXTARGET) main.cpp

c-linux:
@gcc $(CFLAGS) -o linux/$(CTARGET) main.c

c-win32.exe:
@i686-w64-mingw32-gcc $(CFLAGS) -o win32/$(CTARGET).exe main.c

cpp-win32.exe:
@i686-w64-mingw32-g++ $(CXXFLAGS) -o win32/$(CXXTARGET).exe main.cpp

c-win64.exe:
@x86_64-w64-mingw32-gcc $(CFLAGS) -o win64/$(CTARGET).exe main.c

cpp-win64.exe:
@x86_64-w64-mingw32-g++ $(CXXFLAGS) -o win64/$(CXXTARGET).exe main.cpp

copy-dll32:
@[ -f libwinpthread-1.dll ] || cp $(DLL32_PATH)/libwinpthread-1.dll win32/
@[ -f libstdc++-6.dll ] || cp $(DLL32_PATH)/libstdc++-6.dll win32/
@[ -f libgcc_s_sjlj-1.dll ] || cp $(DLL32_PATH)/libgcc_s_sjlj-1.dll win32/

copy-dll64:
@[ -f libwinpthread-1.dll ] || cp $(DLL64_PATH)/libwinpthread-1.dll win64/
@[ -f libstdc++-6.dll ] || cp $(DLL64_PATH)/libstdc++-6.dll win64/
@[ -f libgcc_s_seh-1.dll ] || cp $(DLL64_PATH)/libgcc_s_seh-1.dll win64/

clean:
@rm -rf linux win32 win64

</syntaxhighlight>}}

== Compilation de plusieurs fichiers sources ==

=== Sources ===

Afin de simplifier les explications, on va se concentrer sur le <class>C++</class> et utiliser un fichier Makefile. Cette fois les sources seront un fichier principal (<path>main.cpp</path>) ainsi qu'un fichier de définition (<path>data.h</path>) et d'implémentation (<path>data.cpp</path>) d'une classe.

{{Admon/file|main.cpp|<syntaxhighlight lang="cpp">
#include <iostream>
#include "data.hpp"

using namespace std;

int main()
{
Data data;
data.set( 99 );
cout << "data: " << data.get() << endl;
return 0;
}
</syntaxhighlight>}}
{{Admon/file|data.h|<syntaxhighlight lang="cpp">
#ifndef _DATA_HPP_
#define _DATA_HPP_

#include <iostream>

class Data
{
public:
Data();
~Data();
void set( int number );
int get() const;

protected:
int _number;
};

int get();

#endif //_DATA_HPP_
</syntaxhighlight>}}
{{Admon/file|data.cpp|<syntaxhighlight lang="cpp">
#include "data.h"

Data::Data() :
_number( 0 )
{
}

Data::~Data()
{
}

void Data::set( int number )
{
_number = number;
}

int Data::get() const
{
return _number;
}
</syntaxhighlight>}}

=== Fichier Makefile ===

Cette fois on va définir un modèle générique afin de compiler chaque fichier source cpp en fichier objet et lier ces fichiers objet entre eux pour obtenir un exécutable.
{{Admon/note|Fichiers temporaires|Les fichiers temporaires ne sont pas isolés dans leur répertoire d'accueil respectif, mais cela ne pose pas de problème de conflit entre les architectures.}}
{{Admon/file|Makefile|<syntaxhighlight lang="make">
CXXFLAGS=-O0 -Wall -g
LDFLAGS=
CXXTARGET=data

DLL32_PATH := /usr/i686-w64-mingw32/sys-root/mingw/bin
DLL64_PATH := /usr/x86_64-w64-mingw32/sys-root/mingw/bin

linux: tree linux.exe

win: win32 win64

win32: tree win32.exe copy-dll32

win64: tree win64.exe copy-dll64

all: linux win

tree:
@[ -d linux ] || mkdir linux
@[ -d win32 ] || mkdir win32
@[ -d win64 ] || mkdir win64

%.o: %.cpp $(CXXDEPS)
@g++ -c -o $@ $< $(CXXFLAGS)

%.obj32: %.cpp $(CXXDEPS)
@i686-w64-mingw32-g++ -c -o $@ $< $(CXXFLAGS)

%.obj64: %.cpp $(CXXDEPS)
@x86_64-w64-mingw32-g++ -c -o $@ $< $(CXXFLAGS)

linux.exe: main.o data.o
@g++ $(CXXFLAGS) -o linux/$(CXXTARGET) main.o data.o

win32.exe: main.obj32 data.obj32
@i686-w64-mingw32-g++ $(CXXFLAGS) -o win32/$(CXXTARGET).exe main.obj32 data.obj32

win64.exe: main.obj64 data.obj64
@x86_64-w64-mingw32-g++ $(CXXFLAGS) -o win64/$(CXXTARGET).exe main.obj64 data.obj64

copy-dll32:
@[ -f libwinpthread-1.dll ] || cp $(DLL32_PATH)/libwinpthread-1.dll win32/
@[ -f libstdc++-6.dll ] || cp $(DLL32_PATH)/libstdc++-6.dll win32/
@[ -f libgcc_s_sjlj-1.dll ] || cp $(DLL32_PATH)/libgcc_s_sjlj-1.dll win32/

copy-dll64:
@[ -f libwinpthread-1.dll ] || cp $(DLL64_PATH)/libwinpthread-1.dll win64/
@[ -f libstdc++-6.dll ] || cp $(DLL64_PATH)/libstdc++-6.dll win64/
@[ -f libgcc_s_seh-1.dll ] || cp $(DLL64_PATH)/libgcc_s_seh-1.dll win64/

clean:
@rm -rf linux win32 win64 *.o *.obj32 *.obj64
</syntaxhighlight>}}

C C++

2016-01-05T09:46:35Z

Didier : /* Cross-compilation */

== Tests Unitaires ==
* [[CPP/CMake/UnitTests|Intégrer les tests unitaires avec CMake]]
* [[CPP/UnitTests/CppTest| Tests unitaires avec CppTest]]

== Cross-compilation ==
* [[CPP/CrossCompilation|Cross-Compilation simple]]
* [[CPP/CMake/CrossCompilation|Cross-Compilation avec cmake]]

C C++

2016-01-04T14:32:24Z

Didier :

== Tests Unitaires ==
* [[CPP/CMake/UnitTests|Intégrer les tests unitaires avec CMake]]
* [[CPP/UnitTests/CppTest| Tests unitaires avec CppTest]]

== Cross-compilation ==
* [[CPP/CrossCompilation|Cross-Compilation simple sans Makefile]]
* [[CPP/CMake/CrossCompilation|Cross-Compilation avec cmake]]

CPP/CrossCompilation

2016-01-04T14:31:35Z

Didier : Page créée avec « Pour générer un exécutable windows depuis linux, il faut recourir à ce qu’on appelle la cross-compilation: compiler sur un système pour un autre système. On va par... »

Pour générer un exécutable windows depuis linux, il faut recourir à ce qu’on appelle la cross-compilation: compiler sur un système pour un autre système.
On va partir d’un simple “Hello world”. A ce propos, j’ai découvert une collection d’hello world sur Github.

== Sources ==

Le fichier source en C

{{Admon/file|main.c|<syntaxhighlight lang="c">
#include<stdio.h>
int main()
{
printf("Hello World !\n");
return 0;
}
</syntaxhighlight>}}

Le fichier source en C++
{{Admon/file|main.cpp|<syntaxhighlight lang="cpp">
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World !" << endl;
return 0;
}
</syntaxhighlight>}}

== Compilation ==
=== GNU/Linux ===

Pour GNU/Linux, le fichier C serait compilé avec la commande
<syntaxhighlight lang="bash">
gcc -O0 -Wall -g -o helloc main.c
</syntaxhighlight>
et le fichier C++
<syntaxhighlight lang="bash">
g++ -O0 -Wall -g -o hellocpp main.cpp
</syntaxhighlight>

=== Wind@uze ===

On va se servir des compilateurs mingw
<syntaxhighlight lang="bash">
dnf install mingw32-gcc mingw32-gcc-c++ mingw32-binutils mingw64-gcc mingw64-gcc-c++ mingw64-binutils
</syntaxhighlight>

==== Version 32 bits ====

le fichier C sera compilé avec la commande
<syntaxhighlight lang="bash">
i686-w64-mingw32-gcc -O0 -Wall -g -o helloc32.exe main.c
</syntaxhighlight>
et le fichier C++
<syntaxhighlight lang="bash">
i686-w64-mingw32-g++ -O0 -Wall -g -o hellocpp32.exe main.cpp
</syntaxhighlight>
En testant le binaire généré à partir du C++ avec wine, on se rend compte qu’il ne fonctionne pas (absence de DLLs).

{{color|red|err:module:import_dll Library libstdc++-6.dll (which is needed by L"V:\\hello32.exe") not found}}

Pour résoudre ce problème, il va falloir copié quelques DLLs dans le même répertoire que l’exécutable
<syntaxhighlight lang="bash">
cp /usr/i686-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll .
cp /usr/i686-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll .
cp /usr/i686-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll .
</syntaxhighlight>

==== Version 64 bits ====

le fichier C sera compilé avec la commande
<syntaxhighlight lang="bash">
x86_64-w64-mingw32-gcc -O0 -Wall -g -o helloc64.exe main.c
</syntaxhighlight>

et le fichier C++
<syntaxhighlight lang="bash">
x86_64-w64-mingw32-g++ -O0 -Wall -g -o hellocpp64.exe main.cpp
</syntaxhighlight>

Pour résoudre le même problème que la version 32 bits, il va falloir copié quelques DLLs dans le même répertoire que l’exécutable.
<syntaxhighlight lang="bash">
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll .
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_seh-1.dll .
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll .
</syntaxhighlight>

CPP/CMake/CrossCompilation

2016-01-04T14:24:18Z

Didier : Page créée avec « == Sources == On va cette fois se servir de deux fichiers sources, d’un fichier en-tête et d’un fichier cmake pour construire notre binaire '''cppdata''': * Le fichi... »

== Sources ==

On va cette fois se servir de deux fichiers sources, d’un fichier en-tête et d’un fichier cmake pour construire notre binaire '''cppdata''':
* Le fichier main.cpp
* Le fichier data.cpp, qui est l’implémentation de la class Data
* Le fichier en-tête data.hpp qui déclare notre class Data

{{Admon/file|main.cpp|<syntaxhighlight lang="cpp">
#include <iostream>
#include "data.hpp"

using namespace std;

int main()
{
Data data;
data.set( 99 );
cout << "data: " << data.get() << endl;
return 0;
}
</syntaxhighlight>}}

{{Admon/file|data.hpp|<syntaxhighlight lang="cpp">
#ifndef _DATA_HPP_
#define _DATA_HPP_

#include

class Data
{
public:
Data();
~Data();
void set( int number );
int get() const;

protected:
int _number;
};

int get();

#endif //_DATA_HPP_
</syntaxhighlight>}}

{{Admon/file|data.cpp|<syntaxhighlight lang="cpp">

#include "data.hpp"
Data::Data() :
_number( 0 )
{
}
Data::~Data()
{
}

void Data::set( int number )
{
_number = number;
}

int Data::get() const
{
return _number;
}
</syntaxhighlight>}}

{{Admon/file|CMakeLists.txt|<syntaxhighlight lang="cmake">

cmake_minimum_required(VERSION 2.6)
project(testdata)
add_executable(cppdata main.cpp data.cpp)
</syntaxhighlight>}}

== La chaine de construction ==

Afin de se simplifier la tâche, on va écrire un fichier buildchain pour chaque architecture. Ces fichiers, utilisables uniquement par cmake, nous permettront de nous affranchir de longues ligne de définition cmake.
* Le buildchain windows 32 bits: win32.cmake
* Le buildchain windows 64 bits: win64.cmake

{{Admon/file|win32.cmake|<syntaxhighlight lang="cmake">
set(CMAKE_SYSTEM_NAME Windows)

set( WIN_BUILD_ARCH "i686" )
set( WIN_ARCH_BITS "32" )
set( WIN_ARCH "x86" )
set(COMPILER_PREFIX "${WIN_BUILD_ARCH}-w64-mingw32")

# Which compilers to use for C and C++
set(CMAKE_C_COMPILER ${COMPILER_PREFIX}-gcc)
set(CMAKE_CXX_COMPILER ${COMPILER_PREFIX}-g++)
set(CMAKE_RC_COMPILER ${COMPILER_PREFIX}-windres)

# Here is the target environment located
set(CMAKE_FIND_ROOT_PATH /usr/${COMPILER_PREFIX} /usr/${COMPILER_PREFIX}/sys-root/mingw)

# Adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
</syntaxhighlight>}}

{{Admon/file|win64.cmake|<syntaxhighlight lang="cmake">

set(CMAKE_SYSTEM_NAME Windows)

set( WIN_BUILD_ARCH "x86_64" )
set( WIN_ARCH_BITS "64" )
set( WIN_ARCH "x64" )
set(COMPILER_PREFIX "${WIN_BUILD_ARCH}-w64-mingw32")

# Which compilers to use for C and C++
set(CMAKE_C_COMPILER ${COMPILER_PREFIX}-gcc)
set(CMAKE_CXX_COMPILER ${COMPILER_PREFIX}-g++)
set(CMAKE_RC_COMPILER ${COMPILER_PREFIX}-windres)

# Here is the target environment located
set(CMAKE_FIND_ROOT_PATH /usr/${COMPILER_PREFIX} /usr/${COMPILER_PREFIX}/sys-root/mingw)

# Adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
</syntaxhighlight>}}

== Construction ==

Comme habituellement avec cmake, on créé un répertoire dédié à la construction.
=== Linux ===
<syntaxhighlight lang="bash">
mkdir linux
cd linux
cmake ..
make
</syntaxhighlight>
=== Wind@uze ===
==== Version 32 bits ====
<syntaxhighlight lang="bash">
mkdir win32
cmake -D CMAKE_TOOLCHAIN_FILE=../win32.cmake ..
make
</syntaxhighlight>
==== Version 64 bits ====
<syntaxhighlight lang="bash">
mkdir win64
cmake -D CMAKE_TOOLCHAIN_FILE=../win64.cmake ..
make
</syntaxhighlight>

IDS/Tripwire

2015-12-18T09:16:25Z

Didier : /* Modification sur le système */

== Installation ==

L'installation est triviale car le paquet est présent dans les dépôts de base Fedora et dans les dépôts '''[[Distributions#D.C3.A9p.C3.B4ts_Additionnels_2|EPEL]]''' pour CentOS.
yum install tripwire

== Initialisation de l'application ==

L'installation via RPM installe un fichier de configuration et un fichier définissant la politique par défaut dans le dossier <path>/etc/tripwire</path>. Ces fichiers ne peuvent être utilisés directement par tripwire, car celui-ci travaille avec des fichiers cryptés.

La documentation (la page man de tripwire contient toutes les informations nécessaires) nous apprend qu'il va nous falloir 2 clés:
* '''site.key''': Une clé servant à encrypter le fichier de définition de la politique sur un ou plusieurs systèmes
* '''hostname-local.key''': Une autre clé servant uniquement à crypter les fichiers utilisés localement (il est donc unique sur chaque système)
Suivant l'opération à effectuer, une ou deux clés seront requises.

=== Méthode manuelle ===

Génération de deux clés
<pre>
twadmin -m G -v -S /etc/tripwire/site.key -Q passphrase
twadmin -m G -v -L /etc/tripwire/hostname-local.key -P passphrase
</pre>

Une fois les clés générées, on va pouvoir encrypter le fichier de configuration et le fichier définissant la politique. C'est une protection contre la modification des fichiers par un éventuelle attaquant.
<pre>
twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twcfg.txt
twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twpol.txt
</pre>

=== Avec un Script ===

<pre>tripwire-setup-keyfiles</pre>
<pre>

----------------------------------------------
The Tripwire site and local passphrases are used to sign a variety of
files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain both
letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file:
/etc/tripwire/twcfg.txt
has been preserved for your inspection. It is recommended that you
move this file to a secure location and/or encrypt it in place (using a
tool such as GPG, for example) after you have examined it.

----------------------------------------------
Signing policy file...
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file:
/etc/tripwire/twpol.txt
has been preserved for your inspection. This implements a minimal
policy, intended only to test essential Tripwire functionality. You
should edit the policy file to describe your system, and then use
twadmin to generate a new signed copy of the Tripwire policy.

Once you have a satisfactory Tripwire policy file, you should move the
clear-text version to a secure location and/or encrypt it in place
(using a tool such as GPG, for example).

Now run "tripwire --init" to enter Database Initialization Mode. This
reads the policy file, generates a database based on its contents, and
then cryptographically signs the resulting database. Options can be
entered on the command line to specify which policy, configuration, and
key files are used to create the database. The filename for the
database can be specified as well. If no options are specified, the
default values from the current configuration file are used.
</pre>

== Utilisation ==

=== Premier lancement ===

On va lancer la génération de la base avec la politique par défaut, l'affinage se fera dans un second temps, après la première vérification.
tripwire --init

Le premier rapport de tripwire va contenir beaucoup de faux-positif, car la politique par défaut est généraliste.
<pre>
### Warning: File system error.
### Filename: /usr/sbin/fixrmtab
### Aucun fichier ou dossier de ce type
### Continuing...
</pre>
On va donc lister tous les fichiers inexistant en générant un rapport de vérification
tripwire --check | grep '### Filename' | tee twtest.txt
et commenter les fichiers inexistants dans le fichier de définition de la politique <path>/etc/tripwire/twpol.txt</path>

=== Modification de la politique ===

Une fois le fichier de définition de la politique modifié, il faut l'encrypter et ré-initialiser la base de données
<pre>
twadmin --update-policy /etc/tripwire/twpol.txt
tripwire --init
</pre>

=== Modification sur le système ===

Une fois le système modifié, suite à une mise à jour par exemple, il faut mettre à jour le base de données de tripwire
tripwire --update

== Durcissement de la sécurité ==

* Tripwire ne peut que constater la modification des fichiers et doit donc être installé/configuré en même temps que la distribution.
* Tripwire n'utilise que la version cryptée des fichier de configuration et de définition de la politique. C'est pourquoi il est recommandé de supprimé les fichiers ''en clair''<pre>rm /etc/tripwire/twpol.txt /etc/tripwire/twcfg.txt</pre>Les fichiers peuvent être générés à partir de leur version cryptée.<pre>twadmin -m p > /etc/tripwire/twpol.txt</pre><pre>twadmin -m f > /etc/tripwire/twcfg.txt</pre>

IDS/Tripwire

2015-12-18T08:57:33Z

Didier : /* Initialisation de l'application */

IDS/Tripwire

2015-12-18T08:53:10Z

Didier : /* Installation */

== Installation ==

L'installation est triviale car le paquet est présent dans les dépôts de base Fedora et dans les dépôts '''[[Distributions#D.C3.A9p.C3.B4ts_Additionnels_2|EPEL]]''' pour CentOS.
yum install tripwire

== Initialisation de l'application ==

L'installation via RPM installe un fichier de configuration et un fichier définissant la politique par défaut dans le dossier <path>/etc/tripwire</path>. Ces fichiers ne peuvent être utilisés directement par tripwire, car celui-ci travaille avec des fichiers cryptés.

La documentation (la page man de tripwire contient toutes les informations nécessaires) nous apprend qu'il va nous falloir 2 clés:
* '''site.key''': Une clé servant à encrypter le fichier de définition de la politique sur un ou plusieurs systèmes
* '''hostname-local.key'': Une autre clé servant uniquement à crypter les fichiers utilisés localement (il est donc unique sur chaque système)
Suivant l'opération à effectuer, une ou les deux clés seront requises.

=== Méthode manuelle ===

Génération de deux clés
<pre>
twadmin -m G -v -S /etc/tripwire/site.key -Q passphrase
twadmin -m G -v -L /etc/tripwire/hostname-local.key -P passphrase
</pre>

Une fois les clés générées, on va pouvoir encrypter le fichier de configuration et le fichier définissant la politique. C'est une protection contre la modification des fichiers par un éventuelle attaquant.
<pre>
twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twcfg.txt
twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twpol.txt
</pre>

=== Avec un Script ===

<pre>tripwire-setup-keyfiles</pre>
<pre>

----------------------------------------------
The Tripwire site and local passphrases are used to sign a variety of
files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain both
letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file:
/etc/tripwire/twcfg.txt
has been preserved for your inspection. It is recommended that you
move this file to a secure location and/or encrypt it in place (using a
tool such as GPG, for example) after you have examined it.

----------------------------------------------
Signing policy file...
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file:
/etc/tripwire/twpol.txt
has been preserved for your inspection. This implements a minimal
policy, intended only to test essential Tripwire functionality. You
should edit the policy file to describe your system, and then use
twadmin to generate a new signed copy of the Tripwire policy.

Once you have a satisfactory Tripwire policy file, you should move the
clear-text version to a secure location and/or encrypt it in place
(using a tool such as GPG, for example).

Now run "tripwire --init" to enter Database Initialization Mode. This
reads the policy file, generates a database based on its contents, and
then cryptographically signs the resulting database. Options can be
entered on the command line to specify which policy, configuration, and
key files are used to create the database. The filename for the
database can be specified as well. If no options are specified, the
default values from the current configuration file are used.
</pre>

== Utilisation ==

=== Premier lancement ===

On va lancer la génération de la base avec la politique par défaut, l'affinage se fera dans un second temps, après la première vérification.
tripwire --init

Le premier rapport de tripwire va contenir beaucoup de faux-positif, car la politique par défaut est généraliste.
<pre>
### Warning: File system error.
### Filename: /usr/sbin/fixrmtab
### Aucun fichier ou dossier de ce type
### Continuing...
</pre>
On va donc lister tous les fichiers inexistant en générant un rapport de vérification
tripwire --check | grep '### Filename' | tee twtest.txt
et commenter les fichiers inexistants dans le fichier de définition de la politique <path>/etc/tripwire/twpol.txt</path>

=== Modification de la politique ===

Une fois le fichier de définition de la politique modifié, il faut l'encrypter et ré-initialiser la base de données
<pre>
twadmin --update-policy /etc/tripwire/twpol.txt
tripwire --init
</pre>

=== Modification sur le système ===

Une fois le système modifié, suite à une mise à jour par exemple, il faut mettre à jour le base de données de tripwire
tripwire --update

IDS/Tripwire

2015-12-18T08:51:32Z

Didier : /* Premier lancement */

== Installation ==

L'installation est triviale car le paquet est présent dans les dépôts de base Fedora et dans les dépôts [[Distributions#D.C3.A9p.C3.B4ts_Additionnels_2|EPEL]] pour CentOS.
yum install tripwire

== Initialisation de l'application ==

L'installation via RPM installe un fichier de configuration et un fichier définissant la politique par défaut dans le dossier <path>/etc/tripwire</path>. Ces fichiers ne peuvent être utilisés directement par tripwire, car celui-ci travaille avec des fichiers cryptés.

La documentation (la page man de tripwire contient toutes les informations nécessaires) nous apprend qu'il va nous falloir 2 clés:
* '''site.key''': Une clé servant à encrypter le fichier de définition de la politique sur un ou plusieurs systèmes
* '''hostname-local.key'': Une autre clé servant uniquement à crypter les fichiers utilisés localement (il est donc unique sur chaque système)
Suivant l'opération à effectuer, une ou les deux clés seront requises.

=== Méthode manuelle ===

Génération de deux clés
<pre>
twadmin -m G -v -S /etc/tripwire/site.key -Q passphrase
twadmin -m G -v -L /etc/tripwire/hostname-local.key -P passphrase
</pre>

Une fois les clés générées, on va pouvoir encrypter le fichier de configuration et le fichier définissant la politique. C'est une protection contre la modification des fichiers par un éventuelle attaquant.
<pre>
twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twcfg.txt
twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twpol.txt
</pre>

=== Avec un Script ===

<pre>tripwire-setup-keyfiles</pre>
<pre>

----------------------------------------------
The Tripwire site and local passphrases are used to sign a variety of
files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain both
letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file:
/etc/tripwire/twcfg.txt
has been preserved for your inspection. It is recommended that you
move this file to a secure location and/or encrypt it in place (using a
tool such as GPG, for example) after you have examined it.

----------------------------------------------
Signing policy file...
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file:
/etc/tripwire/twpol.txt
has been preserved for your inspection. This implements a minimal
policy, intended only to test essential Tripwire functionality. You
should edit the policy file to describe your system, and then use
twadmin to generate a new signed copy of the Tripwire policy.

Once you have a satisfactory Tripwire policy file, you should move the
clear-text version to a secure location and/or encrypt it in place
(using a tool such as GPG, for example).

Now run "tripwire --init" to enter Database Initialization Mode. This
reads the policy file, generates a database based on its contents, and
then cryptographically signs the resulting database. Options can be
entered on the command line to specify which policy, configuration, and
key files are used to create the database. The filename for the
database can be specified as well. If no options are specified, the
default values from the current configuration file are used.
</pre>

== Utilisation ==

=== Premier lancement ===

On va lancer la génération de la base avec la politique par défaut, l'affinage se fera dans un second temps, après la première vérification.
tripwire --init

Le premier rapport de tripwire va contenir beaucoup de faux-positif, car la politique par défaut est généraliste.
<pre>
### Warning: File system error.
### Filename: /usr/sbin/fixrmtab
### Aucun fichier ou dossier de ce type
### Continuing...
</pre>
On va donc lister tous les fichiers inexistant en générant un rapport de vérification
tripwire --check | grep '### Filename' | tee twtest.txt
et commenter les fichiers inexistants dans le fichier de définition de la politique <path>/etc/tripwire/twpol.txt</path>

=== Modification de la politique ===

Une fois le fichier de définition de la politique modifié, il faut l'encrypter et ré-initialiser la base de données
<pre>
twadmin --update-policy /etc/tripwire/twpol.txt
tripwire --init
</pre>

=== Modification sur le système ===

Une fois le système modifié, suite à une mise à jour par exemple, il faut mettre à jour le base de données de tripwire
tripwire --update

IDS/Tripwire

2015-12-18T08:27:27Z

Didier : /* Utilisation */

== Installation ==

L'installation est triviale car le paquet est présent dans les dépôts de base Fedora et dans les dépôts [[Distributions#D.C3.A9p.C3.B4ts_Additionnels_2|EPEL]] pour CentOS.
yum install tripwire

== Initialisation de l'application ==

L'installation via RPM installe un fichier de configuration et un fichier définissant la politique par défaut dans le dossier <path>/etc/tripwire</path>. Ces fichiers ne peuvent être utilisés directement par tripwire, car celui-ci travaille avec des fichiers cryptés.

La documentation (la page man de tripwire contient toutes les informations nécessaires) nous apprend qu'il va nous falloir 2 clés:
* '''site.key''': Une clé servant à encrypter le fichier de définition de la politique sur un ou plusieurs systèmes
* '''hostname-local.key'': Une autre clé servant uniquement à crypter les fichiers utilisés localement (il est donc unique sur chaque système)
Suivant l'opération à effectuer, une ou les deux clés seront requises.

=== Méthode manuelle ===

Génération de deux clés
<pre>
twadmin -m G -v -S /etc/tripwire/site.key -Q passphrase
twadmin -m G -v -L /etc/tripwire/hostname-local.key -P passphrase
</pre>

Une fois les clés générées, on va pouvoir encrypter le fichier de configuration et le fichier définissant la politique. C'est une protection contre la modification des fichiers par un éventuelle attaquant.
<pre>
twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twcfg.txt
twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twpol.txt
</pre>

=== Avec un Script ===

<pre>tripwire-setup-keyfiles</pre>
<pre>

----------------------------------------------
The Tripwire site and local passphrases are used to sign a variety of
files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain both
letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file:
/etc/tripwire/twcfg.txt
has been preserved for your inspection. It is recommended that you
move this file to a secure location and/or encrypt it in place (using a
tool such as GPG, for example) after you have examined it.

----------------------------------------------
Signing policy file...
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file:
/etc/tripwire/twpol.txt
has been preserved for your inspection. This implements a minimal
policy, intended only to test essential Tripwire functionality. You
should edit the policy file to describe your system, and then use
twadmin to generate a new signed copy of the Tripwire policy.

Once you have a satisfactory Tripwire policy file, you should move the
clear-text version to a secure location and/or encrypt it in place
(using a tool such as GPG, for example).

Now run "tripwire --init" to enter Database Initialization Mode. This
reads the policy file, generates a database based on its contents, and
then cryptographically signs the resulting database. Options can be
entered on the command line to specify which policy, configuration, and
key files are used to create the database. The filename for the
database can be specified as well. If no options are specified, the
default values from the current configuration file are used.
</pre>

== Utilisation ==

=== Premier lancement ===

On va lancer la génération de la base avec la politique par défaut, l'affinage se fera dans un second temps
tripwire --init

Le premier rapport de tripwire va contenir beaucoup de faux-positif, car la politique par défaut est généraliste.
<pre>
### Warning: File system error.
### Filename: /usr/sbin/fixrmtab
### Aucun fichier ou dossier de ce type
### Continuing...
</pre>
On va donc lister tous les fichiers inexistant
tripwire --check | grep '### Filename' >> twtest.txt
et les commenter dans le fichier de définition de la politique <path>/etc/tripwire/twpol.txt</path>

=== Modification de la politique ===

Une fois le fichier de définition de la politique modifié, il faut l'encrypter et ré-initialiser la base de données
<pre>
twadmin --update-policy /etc/tripwire/twpol.txt
tripwire --init
</pre>

=== Modification sur le système ===

Une fois le système modifié, suite à une mise à jour par exemple, il faut mettre à jour le base de données de tripwire
tripwire --update

IDS/Tripwire

2015-12-17T15:12:43Z

Didier :

== Installation ==

L'installation est triviale car le paquet est présent dans les dépôts de base Fedora et dans les dépôts [[Distributions#D.C3.A9p.C3.B4ts_Additionnels_2|EPEL]] pour CentOS.
yum install tripwire

== Initialisation de l'application ==

L'installation via RPM installe un fichier de configuration et un fichier définissant la politique par défaut dans le dossier <path>/etc/tripwire</path>. Ces fichiers ne peuvent être utilisés directement par tripwire, car celui-ci travaille avec des fichiers cryptés.

La documentation (la page man de tripwire contient toutes les informations nécessaires) nous apprend qu'il va nous falloir 2 clés:
* '''site.key''': Une clé servant à encrypter le fichier de définition de la politique sur un ou plusieurs systèmes
* '''hostname-local.key'': Une autre clé servant uniquement à crypter les fichiers utilisés localement (il est donc unique sur chaque système)
Suivant l'opération à effectuer, une ou les deux clés seront requises.

=== Méthode manuelle ===

Génération de deux clés
<pre>
twadmin -m G -v -S /etc/tripwire/site.key -Q passphrase
twadmin -m G -v -L /etc/tripwire/hostname-local.key -P passphrase
</pre>

Une fois les clés générées, on va pouvoir encrypter le fichier de configuration et le fichier définissant la politique. C'est une protection contre la modification des fichiers par un éventuelle attaquant.
<pre>
twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twcfg.txt
twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key -Q passphrase /etc/tripwire/twpol.txt
</pre>

=== Avec un Script ===

<pre>tripwire-setup-keyfiles</pre>
<pre>

----------------------------------------------
The Tripwire site and local passphrases are used to sign a variety of
files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain both
letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file:
/etc/tripwire/twcfg.txt
has been preserved for your inspection. It is recommended that you
move this file to a secure location and/or encrypt it in place (using a
tool such as GPG, for example) after you have examined it.

----------------------------------------------
Signing policy file...
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file:
/etc/tripwire/twpol.txt
has been preserved for your inspection. This implements a minimal
policy, intended only to test essential Tripwire functionality. You
should edit the policy file to describe your system, and then use
twadmin to generate a new signed copy of the Tripwire policy.

Once you have a satisfactory Tripwire policy file, you should move the
clear-text version to a secure location and/or encrypt it in place
(using a tool such as GPG, for example).

Now run "tripwire --init" to enter Database Initialization Mode. This
reads the policy file, generates a database based on its contents, and
then cryptographically signs the resulting database. Options can be
entered on the command line to specify which policy, configuration, and
key files are used to create the database. The filename for the
database can be specified as well. If no options are specified, the
default values from the current configuration file are used.
</pre>

== Utilisation ==

=== Initialisation de la base de données ===

tripwire -m i

=== Modification de la configuration ===

Le premier rapport de tripwire va contenir beaucoup de faux-positif
<pre>
### Warning: File system error.
### Filename: /usr/sbin/fixrmtab
### Aucun fichier ou dossier de ce type
### Continuing...
</pre>
On va donc lister tous les fichiers inexistant
/usr/sbin/tripwire -m c | grep '### Filename' >> twtest.txt
et les commenter dans le fichier de définition de la politique <path>/etc/tripwire/twpol.txt</path>

Mail/MTA/Postfix/GmailRelay

2015-10-10T13:16:06Z

Didier : Page créée avec « == Modify postfix configuration == Edit /etc/postfix/main.cf <pre> # sets gmail as relay relayhost = [smtp.gmail.com]:587 # use tls smtp_use_tls=yes # use sasl when au... »

== Modify postfix configuration ==

Edit /etc/postfix/main.cf
<pre>
# sets gmail as relay
relayhost = [smtp.gmail.com]:587

# use tls
smtp_use_tls=yes

# use sasl when authenticating to foreign SMTP servers
smtp_sasl_auth_enable = yes

# path to password map file
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

# list of CAs to trust when verifying server certificate
smtp_tls_CAfile = /etc/ssl/certs/ca-bundle.trust.crt

# eliminates default security options which are imcompatible with gmail
smtp_sasl_security_options =
</pre>

If you need further debugging you can add these:

<pre>
debug_peer_list=smtp.gmail.com
debug_peer_level=3
</pre>

== Set Gmail credentials ==

Add Gmail credentials to /etc/postfix/sasl_passwd
<pre>
[smtp.gmail.com]:587 username:password
</pre>
and create database
<pre>postmap /etc/postfix/sasl_passwd</pre>

== Reload postfix service ==

<pre>systemctl reload postfix</pre>

Services

2015-09-09T16:05:23Z

Didier : /* Processus noyau */

== Services B2PWeb ==

{{:B2PWeb/Services}}

== Database management system ==

=== MySQL ===

* [[DBMS/MySQL/Brief|Brève présentation]]
* [[DBMS/MySQL/ReasonsReplicationLag|Causes courantes du lag de réplication]]
* [[DBMS/MySQL/InnoDB/DataOrganization|Organisation des données innodb]]
* [[DBMS/MySQL/ResetSlave|Réinitialiser la réplication]]
* [[DBMS/MySQL/Tips|Astuces]]

==== Sauvegarde et restauration ====
* [[DBMS/MySQL/XtraBackup|XtraBackup]]
* [[DBMS/MySQL/backup_scripts|Scripts Utiles]]

==== Réplication du datadir ====
* [[DBMS/MySQL/DRBD|Datadir sur partition DRBD]]

==== Optimisation ====
* [[DBMS/MySQL/Optimizing| Optimiser le fichier <path>/etc/my.cnf</path>]] pour innoDB

==== Informations ====
* [[DBMS/MySQL/Informations| Obtenir des informations sur un serveur MySQL]]
* [[DBMS/MySQL/Show_Grants| Afficher les GRANTS MySQL]]

==== XtraDB Cluster ====
* [[DBMS/MySQL/XtraDBCluster/Install| Installation d'un cluster Percona XtraDB]]
* [[DBMS/MySQL/XtraDBCluster/Manage| Gestion d'un cluster Percona XtraDB]]

=== Oracle ===
* [[DBMS/Oracle/Brief|Présentation d'Oracle]]

=== PostgreSQL ===
* [[DBMS/PostgreSQL/Brief|Brève présentation]]

== Versionning control system ==

* [[VCS/GitLab/Install|Installation de gitlab]], un clone de github avec une interface web.

=== Git ===
* [[VCS/GitOverSvn|Git over Svn]] repository
* [[VCS/Git|Git]]
* [[VCS/Git/ImportSVN| Importer un dépôt SVN]]
* [[VCS/Git/CreateRemoteRepository|Initialiser un dépôt distant]]
* [[VCS/Git/ResolvingMerge|Résoudre les conflits de merge]]
* [[VCS/Git/SyncFork|Synchroniser un Fork]] (utile pour les forks github)

== Domain Name Server ==
* [[Services/DNS/Install|Installation de bind]]
* Check DNS Zone with [[DNS/Zonecheck|Zonecheck]]

== Voice over IP ==
* Serveur de VoIP [[VoIP/Asterisk|Asterisk]]
* Analyse de la base de données CDR [[VoIP/Elastix/Database/Cdr|base de données CDR sur Elastix]]
* [[VoIP/Skype|Skype]]
* [[VoIP/AsteriskOnFedora|Un serveur VoIP Asterisk sur Fedora]]

== Mail ==
* [[Mail/MTA/Sendmail|Sendmail]]
* [[Mail/MTA/Zimbra|Zimbra]]
* [[Mail/MTA/Synchro/ImapSync|ImapSync]]

== Sauvegarde ==
* Serveur de sauvegarde [[Save/Amanda|Amanda]]
* Sauvegarde des bases de données [[DBMS/MySQL/Brief|MySQL]] avec [[Save/Amanda/ZRM|MySQL-zrm]]

== Communication ==
* Envoi de message sur la messagerie instantanée Jabber en ligne de commande avec [[Com/Jabber/Sendxmpp|sendxmpp]]

== File System ==
=== Logical Volume Manager ===
* [[Filesystem/LVM|LVM]]
=== Linux File System ===
* [[Filesystem/Ext3|EXT3]]
* [[Filesystem/Ext4|EXT4]]

=== Raid sur IP ===
* [[Filesystem/RaidOverIP/GlusterFS|GlusterFS]]
* [[Filesystem/RaidOverIP/DRBD|DRBD]]

=== Partage ===
* [[Filesystem/Network/NFS| NFS]]
* [[Filesystem/Network/Samba| Samba]]

=== Monitoring ===
* [[Filesystem/Monitoring/Smart| Smart]]

== Installation et déploiement automatique ==
* [[Installation/Cobbler|Cobbler]]
* [[Deploy/Puppet|Puppet]]
* [[Deploy/SpaceWalk|SpaceWalk]]
** [[Deploy/SpaceWalk/Install|Install SpaceWalk]]
** [[Deploy/SpaceWalk/Upload|Uploading Content]]
** Registrer [[Deploy/SpaceWalk/Client|client]] on Spacewalk.
** [[Deploy/SpaceWalk/Backup|Backup]]
** [[Deploy/SpaceWalk/Howto| Tutorial]]
* [[Deploy/Ansible|Ansible]]

== Virtualisation ==
* Pseudo-virtualisation avec un environnement [[Virt/Chroot|Chroot]]
* [[Virt/LibVirt|LibVirt]]
* [[Virt/RawDisk|Accéder à des données sur un disque virtuel]]
* [[Virt/LinuxGuest|Ajouter un disque sans reboot]]

=== Containers ===
* [[Virt/LXC|LXC]]
* [[Virt/Docker|Docker]]

=== Virtualisation complète et para-virtuelle ===
* [[Virt/Xen|Xen]]
* [[Virt/Xen4|Xen4]]
* [[Virt/VirtualBox|VirtualBox]]
* [[Virt/KVM|Qemu/KVM]]

== Services Web ==
* [[Webserver/Apache|Apache]]
** [[Webserver/Apache/StatusPage|Page de status d'Apache]]
** [[Webserver/Apache/FineTuningSSL|Configuration fine du module SSL]]
** [[Webserver/Apache/Tips|Trucs et astuces]]
** [[Webserver/Apache/Migration_2.2_2.4|Migration d'Apache version 2.2 en 2.4]]
** Les modules d'Apache
*** [[Webserver/Apache/Modules/GeoIP|mod_geoip]]
*** [[Webserver/Apache/Modules/Evasive|mod_evasive]]
*** [[Webserver/Apache/Modules/Security|mod_security]]
* [[Services/Web/Stikked|Stikked]]

== PKI ==
* [[Services/OCSP| répondeur OCSP (Online Certificate Status Protocol)]]

== Clustering ==
* [[Services/Cluster/Pacemaker|Pacemaker]]
* [[Services/Cluster/RHCluster|RedHat Cluster]]
* [[Services/Cluster/RHCluster/Admin|Administration d'un cluster RedHat]]

== Monitoring ==

=== Nagios ===
* [[Services/Monitoring/Nagios| Nagios]]

=== Pnp4Nagios ===
* [[Services/Monitoring/Pnp4Nagios| Pnp4Nagios]]

=== Shinken ===
* [[Services/Monitoring/Shinken| Shinken]]

=== SNMP ===
* [[Services/Monitoring/SNMP| SNMP]]

== Serveur de clés ==
* [[Services/Kerberos/Install|Installation d'un serveur Kerberos]]
* [[Services/Kerberos+LDAP/Install|Installation d'un serveur Kerberos couplé avec LDAP ]]

== Virtual Private Network ==
* [[Services/VPN/Openvpn|Openvpn]]

== Accès à distance ==
* [[Services/Remote/VNC/TigerVNC|TigerVNC]]

== Processus noyau ==
* [[Services/Kernel/CGroup|Control Group]]

== File Transfer Protocol ==
* [[Services/FTP/SFTP|Secure FTP (SFTP)]]

Services/FTP/SFTP

2015-09-09T16:05:11Z

Didier : Page créée avec « Pour donner un accès en téléversement à un tiers, la solution la plus logique serait d'utiliser ssh et de limiter ce tiers au serveur sFTP. Bien que ce ne soit oblilga... »

Pour donner un accès en téléversement à un tiers, la solution la plus logique serait d'utiliser ssh et de limiter ce tiers au serveur sFTP. Bien que ce ne soit oblilgatoire, celui-ci serait emprisonné dans son répertoire utilisateur (chroot)

== Création du groupe et des utilisateurs ==

Création du groupe ''sftponly'' qui limiterait les utilisateurs à l'utilisation de sFTP (accès SSH interdit)
groupadd sftponly
Création d'un utilisateur dont l'accès serait uniquement via sFTP (pas d'ouverture de session possible, en local ou distant) et affectation d'un mot de passe.
useradd -m -s /bin/false -c 'sFTP User Only' sftptest
usermod -aG sftponly sftptest
passwd sftptest

== Modification de la configuration du démon SSH ==

Dans le fichier <path>/etc/ssh/sshd_config</path>
Modifier le programme gérant le sFTP afin d'utiliser le wrapper interne à ssh pour lancer le programme sFTP. En effet le binaire ne sera pas accessible depuis le chroot.
Subsystem sftp internal-sftp

Ajouter à la fin du fichier, la configuration des utilisateurs ayant pour groupe ''sftponly'' afin de les emprisonner dans leur répertoire personnel et de leur permettre l'accès uniquement au service sFTP.

Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no

Le démon SSH (sshd) doit être rafraichi
service sshd reload

== Ajuster les droits des répertoires utilisateurs créés ==

Le répertoire personnel des utilisateurs sFTP doit avoir pour propriétaire et groupe '''root''' et pour permission '''755''' (root:root rwxr-xr-x). Afin de pouvoir téléverser, il faut créer un répertoire ayant pour propriétaire l'utilisateur (sftptest ici). en effet l'utilisateur ne pourra pas téléverser à sa racine (son répertoire utilisateur).

chown root:sftponly /home/sftptest
chmod 755 /home/sftptest
mkdir /home/sftptest/upload
chown sftptest: sftponly /home/sftptest/upload
chmod 755 /home/sftptest/upload

== SELinux ==

Par défaut, pour SELinix, le chroot sFTP est en lecture seule. Afin d'autoriser le téléversement, il faut qu'il soit en lecture/écriture. SELInux dispose d'un booléen pour ça.

setsebool -P ssh_chroot_rw_homedirs on

== Test ==

Afin de ne pas perturber le démon SSH en cours d'utilisation, on peut lancer une seconde instance (sur un port différent) en mode debug
/usr/sbin/sshd -p 2222 -d

Depuis un autre poste, on test la connexion ssh (qui ne doit pas fonctionner) et le téléversement d'un fichier à la racine (qui doit rapporter une erreur) et dans le répertoire upload (seul ce dernier doit fonctionner).
ssh -p 2222 sftptest@monserver
sftptest@monserver's password:
This service allows sftp connections only.
Connection to monserver closed.

sftp -p 2222 sftptest@monserver
sftptest@monserver's password:
Connected to monserver.
sftp> ls
upload
sftp> put test.txt
Uploading test.txt to /test.txt
remote open("/test.txt"): Permission denied
sftp> cd upload
sftp> put test.txt
Uploading test.txt to /upload/test.txt
test.txt 100% 5 0.0KB/s 00:00
sftp> exit

Datasheet

2015-06-05T13:26:05Z

Didier : /* Services */

== Services ==
* [[Datasheet/LVM|LVM]]
* [[Datasheet/MySQL|MySQL]]
* [[Datasheet/XtraBackup|XtraBackup]]
* [[Datasheet/RHCluster|RedHat Cluster]]
* [[Datasheet/MAJ/Postgresql|Mise à jour de postgresql]]
* [[Datasheet/MAJ/Gitlab|Mise à jour de Gitlab]]
* [[Datasheet/FileSystem/XFS|Erreur de réparation après un crash sur XFS]]
* [[Datasheet/Screen|Screen]]

== Applications ==
* [[Datasheet/Thunderbird/UseDefaultTemplate|Utilisation d'un template par défaut]]

== Virtualisation ==
* [[Datasheet/Docker|Docker]]
* [[Datasheet/Virsh|Virsh]]
* [[Datasheet/Libguestfs|Libguestfs]]

== Systemd ==
* [[Datasheet/Systemd|Systemd]]
* [[Datasheet/Journalctl|Journalctl]]
* [[Datasheet/Hostnamectl|Hostnamectl]]
* [[Datasheet/Localectl|Localectl]]
* [[Datasheet/Timedatectl|Timedatectl]]
* [[Datasheet/Firewalld|Firewalld]]

== Gestion des RPM ==
* [[Datasheet/yum|Yum]]
* [[Datasheet/Repoquery|Repoquery]]
* [[Datasheet/PackageCleanup|Package-cleanup]]
* [[Datasheet/Fedpkg|Fedpkg]]

Datasheet/Screen

2015-06-05T13:25:08Z

Didier : Page créée avec « {{Datasheet}} = Screen = == Présentation == Screen [http://fr.wikipedia.org/wiki/GNU_Screen GNU Screen] est un multiplexeur de terminaux permettant d'ouvrir plusieurs t... »

{{Datasheet}}
= Screen =

== Présentation ==

Screen [http://fr.wikipedia.org/wiki/GNU_Screen GNU Screen] est un multiplexeur de terminaux permettant d'ouvrir plusieurs terminaux dans une même console, de passer de l'un à l'autre et de les récupérer plus tard.

Toutes les commandes à destination de screen sont toutes précédées de {{Button|CTRL}} <nowiki>+</nowiki> {{Button|a}} suivi de la {{Button|touche de commande}}

== Utilisation basique ==

* Ouvrir une session screen<pre>screen</pre>Par défaut, le nom de la session sera <tty utilisé>.<nom d'hôte simple>
* Ouvrir une session screen en la nommant<pre>screen -S nom_de_la_session</pre>
* Détacher une session screen: {{Button|CTRL}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|d}}
* Se rattacher à une session nommée<pre>screen -r nom_de_la_session</pre>
* Se rattacher à une session<pre>screen -r</pre>Si plusieurs sessions sont disponibles, screen affichera une liste de celles-ci.<pre> 21906.pts-3.didier (Detached)</pre> Il faudra alors spécifier soit son identifiant (21906), soit son nom (pts-3.didier)
* Lister les sessions screen existantes<pre>screen -ls</pre>
* Fermer une session screen: {{Button|CTRL}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|\}} ( {{Button|AltGr}} + {{Button|8}} ) ou <pre>exit</pre>
* S'attacher à un screen déjà attaché (partage de session)<pre>screen -x nom_de_la_session</pre>

== Raccourcis clavier ==

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|n}}: Aller au terminal suivant (next)

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|p}}: Aller au terminal précédent (previous).

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|0}}..{{Button|9}}: aller au terminal n.

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|'}}: saisir dans le prompt le numéro du terminal.

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|"}}: lister des différents terminaux, avec la possibilité d'en choisir un.

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|w}}: lister les terminaux actuels avec leur nom.

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|a}}: retourner au terminal d'où l'on vient.

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|A}}: nommer les terminaux et s'y rendre par la suite plus aisément.

'''Séparation de la console''' :

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|<nowiki>|</nowiki>}} ( {{Button|AltGr}} + {{Button|6}} ): Sépare la console courante en deux consoles verticalement (la console courante devient celle de gauche).

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|S}}: Sépare la console courante en deux consoles horizontalement (la console courante devient celle du dessus).

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|TAB}}: Une fois la console séparée, ce raccourci permet de se positionner sur la console suivante.
{{Admon/tip|Seconde console|Pour la seconde console, il faut soit:

créer un nouveau screen {{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|AltGr}} <nowiki>+</nowiki> {{Button|c}}

démarrer un nouveau terminal{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|c}}
}}

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|Q}}: Supprime toutes les consoles, sauf la console courante.

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|K}}: Supprime la console courante.
{{Admon/tip|Suppression de région|La suppression d'une ou plusieurs régions ne supprime pas les consoles qui s'y trouvaient.}}

'''Divers''' :

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|F}}: Redimensionnement de la fenêtre à la taille de son terminal. Utile lorsque l'on est plusieurs sur une même console et que l'on n'a pas tous un écran 16/9e.

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|H}}: Permet de logguer tout ce qui passe à l'écran dans un fichier $HOME/screenlog.XX (XX : no de la console)

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|?}}: Affiche une petite aide

'''Déplacement et copie''' :

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|ESC}}: Entre en mode copie/scrollback. On peut se déplacer dans le screen avec les flèches directionnelles et la touche {{Button|ENTER}} Permet de commencer une sélection. Un second appui sur la touche {{Button|ENTER}} termine la sélection.

{{Button|Ctrl}} <nowiki>+</nowiki> {{Button|a}} suivi de {{Button|]}} ( {{Button|AltGr}} + {{Button|)}} ): Colle le contenu sélectionné précédemment.

Modèle:Button

2015-06-05T13:23:59Z

Didier : Page créée avec « {{{1|Button}}} »

{{{1|Button}}}

Koji/Installation

2015-04-23T11:38:15Z

Didier : /* Configuration */

'''Mettre en place un système de construction de RPM Koji'''

== Présentation ==
{{class|Koji}} est une suite logicielle de construction de RPM. Il utilise [[RPM/Mock|mock]] pour créer des environnements
chrootés et y effectuer les builds.

[[Fichier:KojiArch.svg|441px|vignette|centré|Architecture du koji]]

* '''Koji-Hub''' C'est le centre nerveux de toutes les opérations Koji. Il s'agit d'un serveur XML-RPC fonctionnant sous mod_python pour Apache. {{class|koji-hub}} est passif : il ne reçoit que les appels XML-RPC et s'appuie sur les autres outils de la suite pour la construction. {{class|koji-hub}} est le seul composant qui a un accès direct à la base de données et est l'un des deux composants qui ont un accès en écriture au système de fichiers.
* '''Kojid''' ou '''Koji-builder''' C'est le démon de compilation qui s'exécute sur chacune des machines de construction. Sa principale responsabilité est de scruter les demandes de construction entrantes et de les exécuter. Pour cela, {{class|kojid}} interroge {{class|koji-hub}}. {{class|Kojid}} est également responsable d'autres tâches que la construction : la création d'images d'installation par exemple. kojid utilise Mock pour la construction. Il crée également un buildroot vierge pour chaque génération. kojid est écrit en Python et communique avec koji-hub par l'intermédiaire de XML-RPC.
* '''Koji-Web''' C'est un ensemble de scripts qui s'exécutent avec mod_python et utilise le moteur de templates Cheetah pour fournir une interface web à {{class|Koji}}. Il agit comme un client à {{class|koji-hub}} en offrant une interface d'aministration limitée. {{class|koji-Web}} expose un grand nombre d'informations et fournit également un moyen pour certaines opérations, telles que l'annulation de builds.
* '''Koji-client''' C'est une interface en ligne de commande ( CLI = Command Line Interface ) écrit en Python qui fournit de nombreux hooks à {{class|Koji}}. Il permet à l'utilisateur d'interroger la plupart des données ainsi que d'effectuer des actions telles que l'ajout d'utilisateurs et de lancer la construction des demandes.
* '''Kojira''' C'est un démon qui garde la racine de construction repodata à jour. Il est responsable de l'enlèvement des racines redondantes et du nettoyage après une demande de construction est terminée.

Les composants de {{class|Koji}} peuvent être installés sur des serveurs différents. La seule obligation est d'autoriser la communication entre les différents composants de la suite.

{{class|Koji}} supporte nativement l'authentification par serveur Kerberos et par certificat SSL. Seul {{class|koji-client}} supporte l'authentification par mot de passe. De ce fait, l'authentification par mot de passe ne sera même pas abordée.

La méthode d'authentification doit être choisie dès le début de l'installation. Dans la suite de ce document, nous mettrons en place la méthode SSL.

{{class|Koji}} utilise beaucoup d'espace disque dans son répertoire primaire <path>/mnt/koji</path>. De plus Mock en utilisera beaucoup aussi sur les répertoires <path>/var/lib/mock</path> et <path>/var/cache/mock</path>. Il vaut mieux prévoir des partitions dédiées à ces répertoires ( les répertoires de Mock doivent appartenir au groupe mock et avoir les permissions 02755 ).

Pour un aperçu rapide des outils utilisés : [[RPM/Yum|yum]], [[RPM/Mock|mock]], {{class|Koji}} (et tous ses composants), [[RPM/Mash|mash]], et comment ils fonctionnent ensemble, il existe une excellente présentation <ref>Présentation des outils de création/gestion des RPM [http://indico.cern.ch/event/55091 | Version online ] Version offline: [[Fichier:MockKojiMash.pdf]] ( non mise à jour )</ref> créée par Steve Traylen du CERN.

Le dépôt git de RussianFedora avec les fichiers de configuration de {{class|Koji}} <ref>https://github.com/RussianFedora/koji-setup</ref>

=== Connaissances requises ===
* Connaissances basiques de l'authentification par certificat SSL.
* Connaissances basiques de création de base de données PostgreSQL and d'importation de structure de base
* Connaissances basiques de l'outil psql
* Connaissances basiques de configuration d'Apache
* Connaissances basiques des outils yum/createrepo/mock
* Connaissances basiques de la ligne de commandes
* Connaissances basiques sur la construction de RPM

=== Dépendances ===

Sur le serveur ({{class|koji-hub}} / {{class|kojiweb}} )
* httpd
* mod_ssl
* postgresql-server
* mod_wsgi
* MySQL-python

Sur les constructeurs ( {{class|kojid}} )
* mock
* setarch
* rpm-build
* createrepo

Si le mode d'authentification choisie est Kerberos, il faudra aussi que le réseau local ait un serveur DNS et une dépendance supplémentaire est à installer sur le serveur et les constructeurs.
* mod_auth_kerb

=== Espace disque ===

comme <class>Koji</class> utilise [[RPM/Mock|Mock]], les répertoires <path>/var/lib/mock</path> et <path>/var/cache/mock</path> grossiront mais une purge de ces répertoires est mise en place par Koji.

Les répertoires qui vont grossir au fur et à mesure de l'utilisation sont ceux de:
* Mock:
* La base de données: <path>/var/lib/psql</path>
* Le répertoire principal de Koji: <path>/mnt/koji</path>
* Le répertoire des dépôts: <path>/mnt/repo</path>
Il sera donc judicieux de leur attribuer une partition spécifique avec une taille dynamique (lvm)

== Génération des certificats SSL ==

Ces certificats serviront à l'authentification des éléments de Koji sur le {{class|koji-hub}}.

Création du répertoire des certificats

<syntaxhighlight lang="bash">
mkdir /etc/pki/koji && cd /etc/pki/koji
</syntaxhighlight>
Création du fichier de configuration de nos futurs certificats
{{Admon/file|<path>/etc/pki/koji/ssl.cnf</path>|
<pre>
HOME = .
RANDFILE = .rand

[ca]
default_ca = ca_default

[ca_default]
dir = .
certs = $dir/certs
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/%s_ca_cert.pem
private_key = $dir/private/%s_ca_key.pem
serial = $dir/serial
crl = $dir/crl.pem
x509_extensions = usr_cert
name_opt = ca_default
cert_opt = ca_default
default_days = 3650
default_crl_days = 30
default_md = sha256
preserve = no
policy = policy_match

[policy_match]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[req]
default_bits = 4096
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = MASK:0x2002

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = FR
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Languedoc Roussilon
localityName = Locality Name (eg, city)
localityName_default = Beaucaire
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Home
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (eg, your name or your server\'s hostname)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64

[req_attributes]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name

[usr_cert]
basicConstraints = CA:FALSE
nsComment = "OpenSSL Generated Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always

[v3_ca]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true
</pre>}}
{{Admon/note|Modification du fichier ssl.cnf|Bien que cela ne soit pas obligatoire, il est recommandé d'éditer les champs suffixés par '''_default''' dans la section '''[req_distinguished_name]''', afin de coller aux informations du serveur en cours d'installation Cela vous permettra d'accepter directement les valeurs proposées par défaut à la génération des certificats. Les autres sections n'ont pas besoin d'être éditées.}}

=== Génération de l'autorité de certification ===

Toujours depuis le répertoire /etc/pki/koji, on initialise notre générateur et on génère l’autorité de certification. Celle-ci se compose d'une paire clé/certificat qui servira à signer tous les autres certificats.

Ici, le CN sera obligatoirement le nom d'hôte du serveur (FQDN), les autres renseignements ne sont pas bloquants pour la suite.
<syntaxhighlight lang="bash">
cd /etc/pki/koji/
mkdir {certs,private,confs}
touch index.txt
echo 01 > serial
openssl genrsa -out private/koji_ca_cert.key 4096
openssl req -config ssl.cnf -new -x509 -days 3650 -key private/koji_ca_cert.key \
-out koji_ca_cert.crt -extensions v3_ca
</syntaxhighlight>

=== Générer les certificats des composants de Koji et le certificat de l'administrateur===

Chaque composant de Koji a besoin d'un certificat.
Kojihub et kojiweb ont besoin d'avoir le nome d'hôte pleinement qualifié (FQDN) en CN, on se servira de OU pour distinguer les certificats. Pour les autres certificats, le CN doit être le nom du composant ( kojira ), le login du compte administrateur ou le nom du builder qui sera définit avec koji-client.
Par simplicité, on va se servir de ces scripts pour générer les certificats des composants et les certificats web.

Script de génération des certificats
{{Admon/file|<path>/etc/pki/koji/generate-certificate.sh</path>|
<syntaxhighlight lang="bash">
#!/bin/bash
#if you change your certificate authority name to something else you will need to change the caname value to reflect the change.
caname=koji

# user is equal to parameter one or the first argument when you actually run the script
user=$1

if [[ "$user" == "" ]]
then
echo "Usage: $(basename $0) USER"
exit
fi

echo "Generate certificates for \"${user}\""

openssl genrsa -out certs/${user}.key 4096

cat ssl.cnf | sed 's/insert_hostname/'${user}'/'> ssl2.cnf

openssl req -config ssl2.cnf -new -nodes -out certs/${user}.csr -key certs/${user}.key

openssl ca -config ssl2.cnf -keyfile private/${caname}_ca_cert.key -cert ${caname}_ca_cert.crt \
-out certs/${user}.crt -outdir certs -infiles certs/${user}.csr

cat certs/${user}.crt certs/${user}.key > ${user}.pem

mv ssl2.cnf confs/${user}-ssl.cnf

</syntaxhighlight>}}

Script de génération des certificats pour les navigateurs Web
{{Admon/file|<path>/etc/pki/koji/generate-web-certificate.sh</path>|
<syntaxhighlight lang="bash">
#!/bin/bash
#if you change your certificate authority name to something else you will need to change the caname value to reflect the change.
caname=koji

# user is equal to parameter one or the first argument when you actually run the script
user=$1

if [[ "$user" == "" ]]
then
echo "Usage: $(basename $0) USER"
exit
fi

echo "Generate web certificates for \"${user}\""

openssl pkcs12 -export -inkey certs/${user}.key -in certs/${user}.crt -CAfile ${caname}_ca_cert.crt \
-out certs/${user}_browser_cert.p12
</syntaxhighlight>}}

On génère les certificats comme cela pour tous les composants et users du tableau récapitulatif:
<syntaxhighlight lang="bash">
cd /etc/pki/koji/
./generate-certificate.sh kojiweb
</syntaxhighlight>
Le user choisi pour être le koji admin est le user didier.

De plus pour les utilisateurs (réels) de {{class|koji}}, on générera les certificats web comme ceci:
<syntaxhighlight lang="bash">
./generate-web-certificate.sh didier
</syntaxhighlight>

{| class="wikitable"
! Nom du certificat
! CN (commonName)
! OU (organizationalUnitName)
|-
| kojihub
| koji.didier-linux.eu (FQDN)
| kojihub
|-
| kojiweb
| koji.didier-linux.eu (FQDN)
| kojiweb
|-
| kojira
| kojira
| Admin
|-
| didier ( utilisateur koji admin )
| didier ( ici c'est le user et non le nom d'hôte de la machine )
| Admin
|-
| kojibuilder.didier-linux.eu
| kojibuilder.didier-linux.eu
| builder
|}

=== Copier les certificats dans le home de utilisateur admin ===

On copie le certificat correspondant à l'administrateur du {{class|Koji}}, et l'autorité de certification dans son home.

<syntaxhighlight lang="bash">
mkdir ~/.koji
cp /etc/pki/koji/didier.pem ~/.koji/client.crt
cp /etc/pki/koji/koji_ca_cert.crt ~/.koji/clientca.crt
cp /etc/pki/koji/koji_ca_cert.crt ~/.koji/serverca.crt
</syntaxhighlight>
{{Admon/note|Modification des paramètres par défaut|Pour modifier des paramètre d'un client sans modifier la configuration générale, il faut copier le fichier <path>/etc/koji.conf</path> dans le home de l'utilisateur <path>~/.koji/config</path> et y effectuer les modifications dans celui-ci.}}

==Mise en place des principals Kerberos==

Le serveur Kerberos doit pouvoir être trouvé grâce au DNS. Le point final indique que l'hôte est pleinement qualifié (FQDN).
<pre>_kerberos._udp IN SRV 10 100 88 kerberos.didier-linux.eu.</pre>

{| class="wikitable"
! Principal
! Utilisation
|-
| host/kojihub@DIDIER-LINUX.EU
| Utiliser par koji-hub pour communiquer avec le client koji
|-
| HTTP/kojiweb@DIDIER-LINUX.EU
| Utiliser par koji-web pour négotier une authentifiaction avec le navigateur web. C'est le principal pour l'authentification Apache <package>mod_auth_kerb</package>.
|-
| koji/kojiweb@DIDIER-LINUX.EU
| Utiliser par koji-web pour communiquer avec koji-hub. C'est le principal qui va authentifier koji-web sur Kerberos comme "koji/kojiweb@EXAMPLE.COM". Koji-web relayera aussi le nom d'utilisateur (authentification Apache) vers koji-hub (koji-hub config option '''''ProxyPrincipals''''').
|-
| koji/kojira@DIDIER-LINUX.EU
| Utiliser par kojira pour communiquer avec koji-hub
|-
| compile/builder1@DIDIER-LINUX.EU
| Utiliser par le constructeur koji pour communiquer avec koji-hub
|}

==Ajout des utilisateurs Koji aux alias du serveur de mail local==

Bien évidemment, un serveur [[Mail/MTA/Sendmail|sendmail]] en local est déjà configuré et opérationnel.

Appairer les utilisateurs Koji aux véritables adresses mail.
{{Admon/file|<path>/etc/aliases</path>|
<pre>
# Person who should get root's mail
root: didier@didier-linux.eu
didier: didier@didier-linux.eu
</pre>}}

Puis lancer la régénération des alias
# newaliases

== Serveur PostgreSQL ==
Une fois l'autentification mise en place, nous avons besoin d'installer un serveur [[DBMS/PostgreSQL/Brief|PostgreSQL]], de le configurer et de mettre en place la structure de la base de données pour {{class|Koji}}.
'''Fichiers de Configuration :'''

* /var/lib/pgsql/data/pg_hba.conf
* /var/lib/pgsql/data/postgresql.conf

===Installation du serveur PostgreSQL===
<pre>
yum install postgresql-server
</pre>

===Initialisation de la base de données PostgreSQL===

Les commandes suivantes initialise le serveur [[DBMS/PostgreSQL/Brief|PostgreSQL]] et le démarre.
Le script d'init a été converti à systemd sur les distributions Fedora 16 et supérieures et la cible '''initdb''' du script d'init a été supprimée. On initialise directement avec les commandes du SGBD.
<syntaxhighlight lang="bash">
su - postgres -c "PGDATA=/var/lib/pgsql/data initdb"
systemctl start postgresql.service
</syntaxhighlight>
{{admon/tip|Initialisation du SGBD sur les distributions sysVinit|<pre>service postgresql initdb && service postgresql start</pre>}}

=== Compte utilisateur ===

Mise en place du compte '''koji''' sur le système (utilisateur unix) et mise en place d'un mot de passe.
<syntaxhighlight lang="bash">
useradd koji
passwd koji
</syntaxhighlight>

=== Setup de PostgreSQL et import de la structure de la base ===

Création de l'utilisateur PostgreSQL '''koji''' et création de sa base de données, puis import de la structure.
{{Admon/bug|Import de la structure|Il est important laisser le joker (*) afin de ne pas se restreindre à une version particulière de Koji. Durant des test, il a été découvert que la restriction à une version spécifique de Koji ne créé pas correctement toutes les tables.}}
<syntaxhighlight lang="bash">
su - postgres
createuser koji
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
createdb -O koji koji
logout
</syntaxhighlight>
<syntaxhighlight lang="bash">
su - koji
psql koji koji < /usr/share/doc/koji*/docs/schema.sql
exit
</syntaxhighlight>

=== Autorisation de Koji-web et Koji-hub aux resources===
''Dans cet exemple, Koji-web et Koji-hub sont démarrés sur localhost.''

Ces paramètres doivent être ajouter avant les autres.
Fichier <path>/var/lib/pgsql/data/pg_hba.conf</path>
{{Admon/file|<path>/var/lib/pgsql/data/pg_hba.conf</path>|
<pre>
host koji koji 127.0.0.1/32 trust
host koji koji ::1/128 trust
</pre>}}
On peut aussi utiliser les sockets UNIX. La variable '''''DBHost''''' variable ne doit pas être renseigné avec cette méthode.
{{Admon/file|<path>/var/lib/pgsql/data/pg_hba.conf</path>|
<pre>
local koji apache trust
local koji apache 127.0.0.1/32 trust
local koji apache ::1/128 trust
local koji koji trust
</pre>}}

=== Application des changements à chaud ===

Informer postgreSQL que les fichiers de configuration doivent être relus.
<syntaxhighlight lang="bash">
root@localhost$ su - postgres
postgres@localhost$ pg_ctl reload
postgres@localhost$ exit
</syntaxhighlight>

=== Ajout du premier administrateur du Koji à la base PostgreSQL ===

Le premier administrateur du <class>Koji</class> doit être ajouter à la main avec des commandes SQL. Une fois ajouté avec les droits administarteur, Il pourra gérer les autres utilisateurs de <class>Koji</class> avec l'outil d'administration en ligne de commande.

Pour l'authentifiaction SSL ou Kerberos, il n'y a pas besoin de mettre un mot de passe.
<syntaxhighlight lang="bash">
root@localhost$ su - koji
koji@localhost$ psql
koji=> insert into users (name, status, usertype) values ('admin-user-name', 0, 0);
</syntaxhighlight>

=== Se donner les droits admin ===

Commande permettant de se donner les droits administrateur. Pour la lancer, on doit connaitre l'ID de l'utilisateur.
<pre>
koji=> insert into user_perms (user_id, perm_id, creator_id) values (<ID of user inserted above>, 1, <ID of user inserted above>);
</pre>
{{Admon/tip|Connaitre l'ID des utilisateurs|Pour connaitre les IDs des utilisateurs du <class>Koji</class>, on doit lancer une commande SQL.
<pre>
koji=> select * from users;
</pre>}}

A ce stade, aucune action ne peut être démarrée tant que le kojihub n'est pas configuré et le serveur web démarré.

== Koji Hub ==

koji-hub est le centre nerveux de toutes les opérations Koji. Il s'agit d'un serveur XML-RPC fonctionnant sous mod_python pour Apache. koji-hub est passif : il ne reçoit que les appels XML-RPC et s'appuie sur les autres outils de la suite pour la construction. koji-hub est le seul composant qui a un accès direct à la base de données et est l'un des deux composants qui ont un accès en écriture au système de fichiers.

'''Fichiers de Configuration'''

* /etc/httpd/conf/httpd.conf
* /etc/httpd/conf.d/kojihub.conf
* /etc/httpd/conf.d/ssl.conf (when using ssl auth)
* /etc/koji-hub/hub.conf
* /etc/koji.conf

Le répertoire de travail sera <path>/mnt/koji</path>.
{{Admon/bug|Répertoire de travail de Koji|Si le répertoire de travail de Koji n'est pas <path>/mnt/koji</path>, il est impératif de créer un lien symbolique du répertoire de travail de Koji dans <path>/mnt</path>:
<pre>ln -s /path/to/koji/datadir /mnt/koji</pre>}}

===Installation de {{class|koji-hub}}===
<pre>
yum install koji-hub httpd mod_ssl
</pre>

=== Configuration ===

On bride tout d'abord le nombre maximum de requête sur le serveur [[Webserver/Apache|apache]] à une valeur plus raisonnable afin de prévenir une saturation et/ou un crash du serveur web.
{{Admon/file|<path>/etc/httpd/conf/httpd.conf</path>|
<syntaxhighlight lang="apache">
<IfModule prefork.c>
...
MaxRequestsPerChild 100
</IfModule>
<IfModule worker.c>
...
MaxRequestsPerChild 100
</IfModule>
</syntaxhighlight>}}

Le répertoire <path>/mnt/koji/packages</path> doit être accessible par HTTP. On ajoute donc un alias.

{{Admon/file|<path>/etc/httpd/conf.d/kojipackages.conf</path>|
<syntaxhighlight lang="apache">
Alias /packages "/mnt/koji/packages"
<Directory "/mnt/koji/packages">
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</syntaxhighlight>}}

{{Admon/file|<path>/etc/httpd/conf.d/ssl.conf</path>|
<syntaxhighlight lang="apache">
LoadModule ssl_module modules/mod_ssl.so

Listen 443

SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300

SSLMutex default

SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin

SSLCryptoDevice builtin

<VirtualHost _default_:443>
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite RC4-SHA:AES128-SHA:ALL:!ADH:!EXP:!LOW:!MD5:!SSLV2:!NULL

SSLCertificateFile /etc/pki/koji/certs/kojihub.crt
SSLCertificateKeyFile /etc/pki/koji/certs/kojihub.key
SSLCertificateChainFile /etc/pki/koji/koji_ca_cert.crt
SSLCACertificateFile /etc/pki/koji/koji_ca_cert.crt
SSLVerifyClient require
SSLVerifyDepth 10

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
</syntaxhighlight>}}

{{Admon/file|<path>/etc/httpd/conf.d/kojihub.conf</path>|
<syntaxhighlight lang="apache">
Alias /kojihub /usr/share/koji-hub/kojixmlrpc.py

<Directory "/usr/share/koji-hub">
Options ExecCGI
SetHandler wsgi-script
Order allow,deny
Allow from all
</Directory>

Alias /kojifiles "/mnt/koji/"

<Directory "/mnt/koji">
Options Indexes SymLinksIfOwnerMatch
AllowOverride None
Order allow,deny
Allow from all
</Directory>

<Location /kojihub/ssllogin>
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +StdEnvVars
</Location>

<Location /kojihub>
SSLOptions +StdEnvVars
</Location>
</syntaxhighlight>}}

{{Admon/file|<path>/etc/koji-hub/hub.conf</path>|
<syntaxhighlight lang="ini">
[hub]
DBName = koji
DBUser = koji
DBHost = localhost
KojiDir = /mnt/koji

DNUsernameComponent = CN
ProxyDNs = C=FR,ST=Languedoc Roussillon,L=Beaucaire,O=Home,OU=kojiweb,CN=koji.didier-linux.eu,emailAddress=root@didier-linux.eu

LoginCreatesUser = On
KojiWebURL = http://koji.didier-linux.eu/koji
EmailDomain = didier-linux.eu
NotifyOnSuccess = True
</syntaxhighlight>}}

{{Admon/file|<path>/etc/koji.conf</path>|
<syntaxhighlight lang="ini">
[koji]
server = http://koji.didier-linux.eu/kojihub
weburl = http://koji.didier-linux.eu/koji
topurl = http://koji.didier-linux.eu/kojifiles
topdir = /mnt/koji
cert = ~/.koji/client.crt
ca = ~/.koji/clientca.crt
serverca = ~/.koji/serverca.crt
</syntaxhighlight>}}

=== Configuration de [[Security/SELinux|SELinux]] ===
Si le mode enforcing est utilisé, on doit autoriser [[Webserver/Apache|apache]] à acceder au serveur [[SGBD/PostgreSQL]]. Même si le mode est permissive, il est recommandé de lancer la commande suivante afin de se prémunir d'un changement de mode de [[Security/SELinux|SELinux]].

<pre>
setsebool -P httpd_can_network_connect_db 1
</pre>

=== Squelette des fichiers Koji ===

Avant que les autres composants de Koji puissent fonctionner correctement, On doit créer la structure et modifié les droits de celui-ci.

<syntaxhighlight lang="bash">
cd /mnt
mkdir koji
cd koji
mkdir {packages,repos,work,scratch}
chown apache.apache *
</syntaxhighlight>

Ici, [[Webserver/Apache|apache]] peut être redémarré et on peut effectuer des opérations minimales sur notre serveur Koji via le client en ligne de commande: gestion des utilisateurs et des constructeurs.

Il faut s'assurer que le client est configuré par défaut ( fichier <path>/etc/koji.conf</path> et que les certificats sont en place dans le home de l'administrateur.

{{Admon/note|Fichier de configuration alternatif|Si un fichier de configuration personnel autre que <path>~/.koji/config</path> est utilisé, il faut utilisé la commande koji avec l'option '''-c'''.}}
La commande suivante teste le login administrateur sur le serveur Koji.
koji call getLoggedInUser

{{Admon/important|Droit des daemons|Kojira a besoin du privilège '''repo''' avant le lancement du daemon. C'est pourquoi il est vivement recommandé de créer cet utilisateur maintenant et de lui ajouter le privilège

<pre>
koji add-user kojira
koji grant-permission repo kojira
</pre>

Pour des raisons similaires, les hôtes de constructions doivent être ajoutés avant le démarrage du daemon kojid.

<pre>
koji add-host kojibuilder1 x86_64 i386
koji add-host kojibuilder2 ppc ppc64
koji add-host kojibuilder3 ia64
</pre>}}

== Koji Web - Interface for the Masses ==

Koji-web est un jeu de scripts qui tournent avec mod_wsgi et qui utilise le moteur de modèle Cheetah pour fournir une interface web à Koji. Koji-web affiche beaucoup d'informations et propose même quelques opérations comme l'abandon de tâche.

'''Fichiers de Configuration:'''
* /etc/kojiweb/web.conf
* /etc/httpd/conf.d/kojiweb.conf
* /etc/httpd/conf.d/ssl.conf

'''Installation de Koji-Web:'''
<pre>
yum install koji-web mod_ssl
</pre>

==== Configuration obligatoire ====

La configuration doit fournir à Koji-web les URLs d'accès à Koji-hub, aux paquets koji (builds) et à sa propre interface. Il est judicieux de modifier aussi le secret (directive ''PythonOption Secret''.

Avec l'authentification SSL, elle doit aussi fournir le nom des certificats à utiliser et la directive ''PythonOption WebCert'' doit contenir '''la clé publique ET la clé privée'''.
{{Admon/file|<path>/etc/kojiweb/web.conf</path>|
<pre>
[web]
SiteName = koji
KojiTheme = didier

KojiHubURL http://koji.didier-linux.eu/kojihub
KojiFilesURL http://www.didier-linux.eu/kojifiles

WebCert /etc/pki/koji/kojiweb.pem
ClientCA /etc/pki/koji/koji_ca_cert.crt
KojiHubCA /etc/pki/koji/koji_ca_cert.crt

LoginTimeout 72
Secret CHANGE_ME

LibPath = /usr/share/koji-web/lib
</pre>}}

==== Configuration Optionnelle ====

Il faut éditer le fichier <path>/etc/httpd/conf.d/kojiweb.conf</path> pour configurer l'authentification choisie.

{{Admon/file|<path>/etc/httpd/conf.d/kojiweb.conf</path>|
<pre>
<Location /koji/login>
SSLOptions +StdEnvVars
</Location>
</pre>}}

{{Admon/file|<path>/etc/httpd/conf.d/ssl.conf</path>|
<pre>
SSLVerifyClient require
SSLVerifyDepth 10
</pre>}}

==== Interface Web opérationnelle ====

L'interface Web du koji est maintenant accessible et la plupart des opérations de lecture doivent fonctionner et chaque utilisateur doit pouvoir se connecter.

== Koji Daemon - Builder ==

Kojid est le daemon de construction qui tourne sur chaque constructeur. son rôle principale est de traiter les requêtes de construction. Koji ne se limite cependant pas aux tâches de construction puisqu'il peut aussi construire des images ISO, des disques virtuels (appliances). Kojid utilise mock pour créer des environnements de construction minimaliste et en créé pour chaque construction. Ceci permet le compartimentage des constructions et les constructions ne peuvent pas se gêner les unes les autres. Kojid est écrit en python et communique avec le hub via XML-RPC.

'''fichiers de Configuration'''
* Configuration du daemon Kojira: /etc/kojid/kojid.conf
* Variables de lancement du daemon: /etc/sysconfig/kojid

'''Installation de kojid:'''
<pre>
yum install koji-builder
</pre>

==== Configuration générale ====

Le fichier de configuration de chaque constructeur doit être édité afin que la directive ''server'' pointe sur l'hôte supportant le Koji-hub. La directive ''user'' doit contenir le nom d'hôte du constructeur.
{{Admon/file|<path>/etc/kojid/kojid.conf</path>|
<pre>
; The URL for the xmlrpc server
server=http://hub.example.com/kojihub

; the username has to be the same as what you used with add-host
; in this example follow as below
user = kojibuilder1.example.com
</pre>}}

La directive ''workdir'' peut être différente entre les constructeurs mais elle ne doit pas être le répertoire de travail du Koji (<path>/mnt/koji</path>)
{{Admon/file|<path>/etc/kojid/kojid.conf</path>|
<pre>
; The directory root for temporary storage
workdir=/tmp/koji
</pre>}}

==== Configuration des certificats SSL ====

Ces entrées doivent être éditées pour pointer sur les bons certificats générés précédemment.
{{Admon/file|<path>/etc/kojid/kojid.conf</path>|
<pre>
;client certificate
; This should reference the builder certificate we created above, for
; kojibuilder1.example.com
cert = /etc/kojid/kojid.pem

;certificate of the CA that issued the client certificate
ca = /etc/kojid/koji_ca_cert.crt

;certificate of the CA that issued the HTTP server certificate
serverca = /etc/kojid/koji_ca_cert.crt
</pre>}}
{{Admon/important|Copie des certificats sur l'hôte|Les certificats SSL doivent être copiés depuis l'hôte abritant le Koji-hub sur les constructeurs dans le répertoire <path>/etc/kojid</path> pour que les constructeurs puissent s'authentifier.}}

==== Ajout d'un hôte à la base de données des constructeurs ====

Il faut maintenant ajouter l'hôte à la base de données des constructeurs afin qu'il puisse être utilisé par Koji-hub.
{{Admon/important|L'ajout doit être fait avant le premier démarrage du daemon de construction|Sinon, il faudra purger les entrées à la main dans les tables ''sessions'' et ''users
'' avant de pouvoir démarrer avec succès le daemon.}}
<pre>
koji add-host kojibuilder1.didier-linux.eu i386 x86_64
</pre>
Le premier argument après la commande est le nom d'hôte du constructeur. Le second argument spécifie l'(les) architecture(s) utilisées par l'hôtes.

==== Ajout de l'hôte au canal de création ====

Les canaux sont un moyen de contrôler quel constructeur fait quoi. Par défaut les hôtes sont ajouté au canal ''default''. Il faut qu'au moins quelques uns (1 au minimum) soient ajoutés au canal ''createrepo'' pour pouvoir lancer les travaux kojira sur les dépôts.
<pre>
koji add-host-to-channel kojibuilder1.didier.eu createrepo
</pre>

==== Capacité ====

La capacité d'un hôte par défaut est de 2, ce qui veut dire que le daemond econstruction n'acceptera pas de travail supplémentaire si le load average est supérieur à 2. Ce paramètre est différent de celui du nombre maximal de travaux (fichier de configuration). Avant que ledaemon de construction n'accepte un nouveau travail, il s'assure que le load average est inférieur à la capacité et que le nombre de travaux est inférieur au nombre maximal. Toutefois, à l'ère des CPU multi-coeurs, un load average de 2 est insuffisant pour consommer 100% des ressources du système. Il n'y a pas d'option pour définir la capacité en ligne de commande, cela doit être fait en base (psql).

<pre>
koji@localhost$ psql koji
koji=# select (id, name, capacity) from host;
row
--------------------------------
(1,kojibuilder1.didier-linux.eu,2)
(2,kojibuilder2.didier-linux.eu,2)
(2 rows)

koji=# update host set capacity = 16 where id = 1;
UPDATE 1
koji=#
</pre>

==== Démarrage du daemon Kojid ====

Une fois le constructeur ajouté à la base de données, on peut démarrer son daemon de construction.
<pre>
systemctl start kojid
</pre>
On vérifie dans le fichier <path>/var/log/kojid.log</path> qur le daemon a bien démarré. Si aucune erreur n'est rapportée, c'est que le daemon doit être correctement configuré et démarré. On peut le vérifier sur l'interface Koji-web dans l'onglet ''hôtes''. Cette page affiche le liste des constructeurs et leur status.

== Kojira - Création et maintenance du dépôt ==
'''Fichiers de Configuration:'''
* Configuration du daemon Kojira: <path>/etc/kojira/kojira.conf</path>
* Variables de lancement du daemon: <path>/etc/sysconfig/kojira</path>

'''Installation de kojira'''
yum install koji-utils

==== Configuration générale ====
La directive ''server'' a besoin de pointer sur le koji-hub.
{{Admon/file|<path>/etc/kojira/kojira.conf</path>|
<pre>
; The URL for the xmlrpc server
server=http://koji.didier-linux.eu/kojihub
</pre>}}
{{Admon/important|Note importante|
* Kojira a besoin d'un accès en lecture/écriture sur <path>/mnt/koji</path>.
* Il ne devrait exister qu'une seule instance de {{class|kojira}} à la fois.
* Il n'est pas recommandé de lancer kojira sur les constructeurs, car ceux-ci n'ont besoin que d'un accès en lecture seule sur le répertoire <path>/mnt/koji</path>.}}

==== Configuration de l'authentification SSL ====

{{Admon/file|<path>/etc/kojira/kojira.conf</path>|
<pre>
;client certificate
; This should reference the kojira certificate we created above
cert = /etc/pki/koji/kojira.pem

;certificate of the CA that issued the client certificate
ca = /etc/pki/koji/koji_ca_cert.crt

;certificate of the CA that issued the HTTP server certificate
serverca = /etc/pki/koji/koji_ca_cert.crt
</pre>}}

''The local user kojira runs as needs to be able to read and write to /mnt/koji/repos/.
If the volume that directory resides on is root-squashed or otherwise unmodifiable
by root, you can set '''RUNAS=''' to a user that has the required privileges.''

{{Admon/file|<path>/etc/sysconfig/kojira</path>|
<pre>
FORCE_LOCK=Y
KOJIRA_DEBUG=N
KOJIRA_VERBOSE=Y
RUNAS=root
</pre>}}

==== Ajout de l'utilisateur kojira à Koji ====
Si cela n'a pas été déjà fait, création de l'utilisateur kojira et ajout du droit '''repo''' à celui-ci. Cela doit être fait avec le compte de l'administrateur de Koji.
<pre>
koji add-user kojira
koji grant-permission repo kojira
</pre>

=== Démarrage du deamon Kojira ===
<pre>
systemctl start kojira.service
</pre>
On vérifie dans le fichier <path>/var/log/kojira/kojira.log</path> que {{class|kojira}} a bien démarré.

== SELinux ==
<pre>
semanage fcontext -a -t httpd_sys_rw_content_t '/mnt/koji(/.*)?'
restorecon -Rv /mnt/koji
</pre>

==Notes==
<references />

[[Catégorie:RPM|Install Koji]]
[[Catégorie:Koji|Install]]
[[Catégorie:Server|Install Koji]]

Koji/Installation

2015-04-23T11:34:59Z

Didier : /* Se donner les droits admin */

'''Mettre en place un système de construction de RPM Koji'''

== Présentation ==
{{class|Koji}} est une suite logicielle de construction de RPM. Il utilise [[RPM/Mock|mock]] pour créer des environnements
chrootés et y effectuer les builds.

[[Fichier:KojiArch.svg|441px|vignette|centré|Architecture du koji]]

* '''Koji-Hub''' C'est le centre nerveux de toutes les opérations Koji. Il s'agit d'un serveur XML-RPC fonctionnant sous mod_python pour Apache. {{class|koji-hub}} est passif : il ne reçoit que les appels XML-RPC et s'appuie sur les autres outils de la suite pour la construction. {{class|koji-hub}} est le seul composant qui a un accès direct à la base de données et est l'un des deux composants qui ont un accès en écriture au système de fichiers.
* '''Kojid''' ou '''Koji-builder''' C'est le démon de compilation qui s'exécute sur chacune des machines de construction. Sa principale responsabilité est de scruter les demandes de construction entrantes et de les exécuter. Pour cela, {{class|kojid}} interroge {{class|koji-hub}}. {{class|Kojid}} est également responsable d'autres tâches que la construction : la création d'images d'installation par exemple. kojid utilise Mock pour la construction. Il crée également un buildroot vierge pour chaque génération. kojid est écrit en Python et communique avec koji-hub par l'intermédiaire de XML-RPC.
* '''Koji-Web''' C'est un ensemble de scripts qui s'exécutent avec mod_python et utilise le moteur de templates Cheetah pour fournir une interface web à {{class|Koji}}. Il agit comme un client à {{class|koji-hub}} en offrant une interface d'aministration limitée. {{class|koji-Web}} expose un grand nombre d'informations et fournit également un moyen pour certaines opérations, telles que l'annulation de builds.
* '''Koji-client''' C'est une interface en ligne de commande ( CLI = Command Line Interface ) écrit en Python qui fournit de nombreux hooks à {{class|Koji}}. Il permet à l'utilisateur d'interroger la plupart des données ainsi que d'effectuer des actions telles que l'ajout d'utilisateurs et de lancer la construction des demandes.
* '''Kojira''' C'est un démon qui garde la racine de construction repodata à jour. Il est responsable de l'enlèvement des racines redondantes et du nettoyage après une demande de construction est terminée.

Les composants de {{class|Koji}} peuvent être installés sur des serveurs différents. La seule obligation est d'autoriser la communication entre les différents composants de la suite.

{{class|Koji}} supporte nativement l'authentification par serveur Kerberos et par certificat SSL. Seul {{class|koji-client}} supporte l'authentification par mot de passe. De ce fait, l'authentification par mot de passe ne sera même pas abordée.

La méthode d'authentification doit être choisie dès le début de l'installation. Dans la suite de ce document, nous mettrons en place la méthode SSL.

{{class|Koji}} utilise beaucoup d'espace disque dans son répertoire primaire <path>/mnt/koji</path>. De plus Mock en utilisera beaucoup aussi sur les répertoires <path>/var/lib/mock</path> et <path>/var/cache/mock</path>. Il vaut mieux prévoir des partitions dédiées à ces répertoires ( les répertoires de Mock doivent appartenir au groupe mock et avoir les permissions 02755 ).

Pour un aperçu rapide des outils utilisés : [[RPM/Yum|yum]], [[RPM/Mock|mock]], {{class|Koji}} (et tous ses composants), [[RPM/Mash|mash]], et comment ils fonctionnent ensemble, il existe une excellente présentation <ref>Présentation des outils de création/gestion des RPM [http://indico.cern.ch/event/55091 | Version online ] Version offline: [[Fichier:MockKojiMash.pdf]] ( non mise à jour )</ref> créée par Steve Traylen du CERN.

Le dépôt git de RussianFedora avec les fichiers de configuration de {{class|Koji}} <ref>https://github.com/RussianFedora/koji-setup</ref>

=== Connaissances requises ===
* Connaissances basiques de l'authentification par certificat SSL.
* Connaissances basiques de création de base de données PostgreSQL and d'importation de structure de base
* Connaissances basiques de l'outil psql
* Connaissances basiques de configuration d'Apache
* Connaissances basiques des outils yum/createrepo/mock
* Connaissances basiques de la ligne de commandes
* Connaissances basiques sur la construction de RPM

=== Dépendances ===

Sur le serveur ({{class|koji-hub}} / {{class|kojiweb}} )
* httpd
* mod_ssl
* postgresql-server
* mod_wsgi
* MySQL-python

Sur les constructeurs ( {{class|kojid}} )
* mock
* setarch
* rpm-build
* createrepo

Si le mode d'authentification choisie est Kerberos, il faudra aussi que le réseau local ait un serveur DNS et une dépendance supplémentaire est à installer sur le serveur et les constructeurs.
* mod_auth_kerb

=== Espace disque ===

comme <class>Koji</class> utilise [[RPM/Mock|Mock]], les répertoires <path>/var/lib/mock</path> et <path>/var/cache/mock</path> grossiront mais une purge de ces répertoires est mise en place par Koji.

Les répertoires qui vont grossir au fur et à mesure de l'utilisation sont ceux de:
* Mock:
* La base de données: <path>/var/lib/psql</path>
* Le répertoire principal de Koji: <path>/mnt/koji</path>
* Le répertoire des dépôts: <path>/mnt/repo</path>
Il sera donc judicieux de leur attribuer une partition spécifique avec une taille dynamique (lvm)

== Génération des certificats SSL ==

Ces certificats serviront à l'authentification des éléments de Koji sur le {{class|koji-hub}}.

Création du répertoire des certificats

<syntaxhighlight lang="bash">
mkdir /etc/pki/koji && cd /etc/pki/koji
</syntaxhighlight>
Création du fichier de configuration de nos futurs certificats
{{Admon/file|<path>/etc/pki/koji/ssl.cnf</path>|
<pre>
HOME = .
RANDFILE = .rand

[ca]
default_ca = ca_default

[ca_default]
dir = .
certs = $dir/certs
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/%s_ca_cert.pem
private_key = $dir/private/%s_ca_key.pem
serial = $dir/serial
crl = $dir/crl.pem
x509_extensions = usr_cert
name_opt = ca_default
cert_opt = ca_default
default_days = 3650
default_crl_days = 30
default_md = sha256
preserve = no
policy = policy_match

[policy_match]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[req]
default_bits = 4096
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = MASK:0x2002

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = FR
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Languedoc Roussilon
localityName = Locality Name (eg, city)
localityName_default = Beaucaire
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Home
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (eg, your name or your server\'s hostname)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64

[req_attributes]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name

[usr_cert]
basicConstraints = CA:FALSE
nsComment = "OpenSSL Generated Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always

[v3_ca]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true
</pre>}}
{{Admon/note|Modification du fichier ssl.cnf|Bien que cela ne soit pas obligatoire, il est recommandé d'éditer les champs suffixés par '''_default''' dans la section '''[req_distinguished_name]''', afin de coller aux informations du serveur en cours d'installation Cela vous permettra d'accepter directement les valeurs proposées par défaut à la génération des certificats. Les autres sections n'ont pas besoin d'être éditées.}}

=== Génération de l'autorité de certification ===

Toujours depuis le répertoire /etc/pki/koji, on initialise notre générateur et on génère l’autorité de certification. Celle-ci se compose d'une paire clé/certificat qui servira à signer tous les autres certificats.

Ici, le CN sera obligatoirement le nom d'hôte du serveur (FQDN), les autres renseignements ne sont pas bloquants pour la suite.
<syntaxhighlight lang="bash">
cd /etc/pki/koji/
mkdir {certs,private,confs}
touch index.txt
echo 01 > serial
openssl genrsa -out private/koji_ca_cert.key 4096
openssl req -config ssl.cnf -new -x509 -days 3650 -key private/koji_ca_cert.key \
-out koji_ca_cert.crt -extensions v3_ca
</syntaxhighlight>

=== Générer les certificats des composants de Koji et le certificat de l'administrateur===

Chaque composant de Koji a besoin d'un certificat.
Kojihub et kojiweb ont besoin d'avoir le nome d'hôte pleinement qualifié (FQDN) en CN, on se servira de OU pour distinguer les certificats. Pour les autres certificats, le CN doit être le nom du composant ( kojira ), le login du compte administrateur ou le nom du builder qui sera définit avec koji-client.
Par simplicité, on va se servir de ces scripts pour générer les certificats des composants et les certificats web.

Script de génération des certificats
{{Admon/file|<path>/etc/pki/koji/generate-certificate.sh</path>|
<syntaxhighlight lang="bash">
#!/bin/bash
#if you change your certificate authority name to something else you will need to change the caname value to reflect the change.
caname=koji

# user is equal to parameter one or the first argument when you actually run the script
user=$1

if [[ "$user" == "" ]]
then
echo "Usage: $(basename $0) USER"
exit
fi

echo "Generate certificates for \"${user}\""

openssl genrsa -out certs/${user}.key 4096

cat ssl.cnf | sed 's/insert_hostname/'${user}'/'> ssl2.cnf

openssl req -config ssl2.cnf -new -nodes -out certs/${user}.csr -key certs/${user}.key

openssl ca -config ssl2.cnf -keyfile private/${caname}_ca_cert.key -cert ${caname}_ca_cert.crt \
-out certs/${user}.crt -outdir certs -infiles certs/${user}.csr

cat certs/${user}.crt certs/${user}.key > ${user}.pem

mv ssl2.cnf confs/${user}-ssl.cnf

</syntaxhighlight>}}

Script de génération des certificats pour les navigateurs Web
{{Admon/file|<path>/etc/pki/koji/generate-web-certificate.sh</path>|
<syntaxhighlight lang="bash">
#!/bin/bash
#if you change your certificate authority name to something else you will need to change the caname value to reflect the change.
caname=koji

# user is equal to parameter one or the first argument when you actually run the script
user=$1

if [[ "$user" == "" ]]
then
echo "Usage: $(basename $0) USER"
exit
fi

echo "Generate web certificates for \"${user}\""

openssl pkcs12 -export -inkey certs/${user}.key -in certs/${user}.crt -CAfile ${caname}_ca_cert.crt \
-out certs/${user}_browser_cert.p12
</syntaxhighlight>}}

On génère les certificats comme cela pour tous les composants et users du tableau récapitulatif:
<syntaxhighlight lang="bash">
cd /etc/pki/koji/
./generate-certificate.sh kojiweb
</syntaxhighlight>
Le user choisi pour être le koji admin est le user didier.

De plus pour les utilisateurs (réels) de {{class|koji}}, on générera les certificats web comme ceci:
<syntaxhighlight lang="bash">
./generate-web-certificate.sh didier
</syntaxhighlight>

{| class="wikitable"
! Nom du certificat
! CN (commonName)
! OU (organizationalUnitName)
|-
| kojihub
| koji.didier-linux.eu (FQDN)
| kojihub
|-
| kojiweb
| koji.didier-linux.eu (FQDN)
| kojiweb
|-
| kojira
| kojira
| Admin
|-
| didier ( utilisateur koji admin )
| didier ( ici c'est le user et non le nom d'hôte de la machine )
| Admin
|-
| kojibuilder.didier-linux.eu
| kojibuilder.didier-linux.eu
| builder
|}

=== Copier les certificats dans le home de utilisateur admin ===

On copie le certificat correspondant à l'administrateur du {{class|Koji}}, et l'autorité de certification dans son home.

<syntaxhighlight lang="bash">
mkdir ~/.koji
cp /etc/pki/koji/didier.pem ~/.koji/client.crt
cp /etc/pki/koji/koji_ca_cert.crt ~/.koji/clientca.crt
cp /etc/pki/koji/koji_ca_cert.crt ~/.koji/serverca.crt
</syntaxhighlight>
{{Admon/note|Modification des paramètres par défaut|Pour modifier des paramètre d'un client sans modifier la configuration générale, il faut copier le fichier <path>/etc/koji.conf</path> dans le home de l'utilisateur <path>~/.koji/config</path> et y effectuer les modifications dans celui-ci.}}

==Mise en place des principals Kerberos==

Le serveur Kerberos doit pouvoir être trouvé grâce au DNS. Le point final indique que l'hôte est pleinement qualifié (FQDN).
<pre>_kerberos._udp IN SRV 10 100 88 kerberos.didier-linux.eu.</pre>

{| class="wikitable"
! Principal
! Utilisation
|-
| host/kojihub@DIDIER-LINUX.EU
| Utiliser par koji-hub pour communiquer avec le client koji
|-
| HTTP/kojiweb@DIDIER-LINUX.EU
| Utiliser par koji-web pour négotier une authentifiaction avec le navigateur web. C'est le principal pour l'authentification Apache <package>mod_auth_kerb</package>.
|-
| koji/kojiweb@DIDIER-LINUX.EU
| Utiliser par koji-web pour communiquer avec koji-hub. C'est le principal qui va authentifier koji-web sur Kerberos comme "koji/kojiweb@EXAMPLE.COM". Koji-web relayera aussi le nom d'utilisateur (authentification Apache) vers koji-hub (koji-hub config option '''''ProxyPrincipals''''').
|-
| koji/kojira@DIDIER-LINUX.EU
| Utiliser par kojira pour communiquer avec koji-hub
|-
| compile/builder1@DIDIER-LINUX.EU
| Utiliser par le constructeur koji pour communiquer avec koji-hub
|}

==Ajout des utilisateurs Koji aux alias du serveur de mail local==

Bien évidemment, un serveur [[Mail/MTA/Sendmail|sendmail]] en local est déjà configuré et opérationnel.

Appairer les utilisateurs Koji aux véritables adresses mail.
{{Admon/file|<path>/etc/aliases</path>|
<pre>
# Person who should get root's mail
root: didier@didier-linux.eu
didier: didier@didier-linux.eu
</pre>}}

Puis lancer la régénération des alias
# newaliases

== Serveur PostgreSQL ==
Une fois l'autentification mise en place, nous avons besoin d'installer un serveur [[DBMS/PostgreSQL/Brief|PostgreSQL]], de le configurer et de mettre en place la structure de la base de données pour {{class|Koji}}.
'''Fichiers de Configuration :'''

* /var/lib/pgsql/data/pg_hba.conf
* /var/lib/pgsql/data/postgresql.conf

===Installation du serveur PostgreSQL===
<pre>
yum install postgresql-server
</pre>

===Initialisation de la base de données PostgreSQL===

Les commandes suivantes initialise le serveur [[DBMS/PostgreSQL/Brief|PostgreSQL]] et le démarre.
Le script d'init a été converti à systemd sur les distributions Fedora 16 et supérieures et la cible '''initdb''' du script d'init a été supprimée. On initialise directement avec les commandes du SGBD.
<syntaxhighlight lang="bash">
su - postgres -c "PGDATA=/var/lib/pgsql/data initdb"
systemctl start postgresql.service
</syntaxhighlight>
{{admon/tip|Initialisation du SGBD sur les distributions sysVinit|<pre>service postgresql initdb && service postgresql start</pre>}}

=== Compte utilisateur ===

Mise en place du compte '''koji''' sur le système (utilisateur unix) et mise en place d'un mot de passe.
<syntaxhighlight lang="bash">
useradd koji
passwd koji
</syntaxhighlight>

=== Setup de PostgreSQL et import de la structure de la base ===

Création de l'utilisateur PostgreSQL '''koji''' et création de sa base de données, puis import de la structure.
{{Admon/bug|Import de la structure|Il est important laisser le joker (*) afin de ne pas se restreindre à une version particulière de Koji. Durant des test, il a été découvert que la restriction à une version spécifique de Koji ne créé pas correctement toutes les tables.}}
<syntaxhighlight lang="bash">
su - postgres
createuser koji
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
createdb -O koji koji
logout
</syntaxhighlight>
<syntaxhighlight lang="bash">
su - koji
psql koji koji < /usr/share/doc/koji*/docs/schema.sql
exit
</syntaxhighlight>

=== Autorisation de Koji-web et Koji-hub aux resources===
''Dans cet exemple, Koji-web et Koji-hub sont démarrés sur localhost.''

Ces paramètres doivent être ajouter avant les autres.
Fichier <path>/var/lib/pgsql/data/pg_hba.conf</path>
{{Admon/file|<path>/var/lib/pgsql/data/pg_hba.conf</path>|
<pre>
host koji koji 127.0.0.1/32 trust
host koji koji ::1/128 trust
</pre>}}
On peut aussi utiliser les sockets UNIX. La variable '''''DBHost''''' variable ne doit pas être renseigné avec cette méthode.
{{Admon/file|<path>/var/lib/pgsql/data/pg_hba.conf</path>|
<pre>
local koji apache trust
local koji apache 127.0.0.1/32 trust
local koji apache ::1/128 trust
local koji koji trust
</pre>}}

=== Application des changements à chaud ===

Informer postgreSQL que les fichiers de configuration doivent être relus.
<syntaxhighlight lang="bash">
root@localhost$ su - postgres
postgres@localhost$ pg_ctl reload
postgres@localhost$ exit
</syntaxhighlight>

=== Ajout du premier administrateur du Koji à la base PostgreSQL ===

Le premier administrateur du <class>Koji</class> doit être ajouter à la main avec des commandes SQL. Une fois ajouté avec les droits administarteur, Il pourra gérer les autres utilisateurs de <class>Koji</class> avec l'outil d'administration en ligne de commande.

Pour l'authentifiaction SSL ou Kerberos, il n'y a pas besoin de mettre un mot de passe.
<syntaxhighlight lang="bash">
root@localhost$ su - koji
koji@localhost$ psql
koji=> insert into users (name, status, usertype) values ('admin-user-name', 0, 0);
</syntaxhighlight>

=== Se donner les droits admin ===

Commande permettant de se donner les droits administrateur. Pour la lancer, on doit connaitre l'ID de l'utilisateur.
<pre>
koji=> insert into user_perms (user_id, perm_id, creator_id) values (<ID of user inserted above>, 1, <ID of user inserted above>);
</pre>
{{Admon/tip|Connaitre l'ID des utilisateurs|Pour connaitre les IDs des utilisateurs du <class>Koji</class>, on doit lancer une commande SQL.
<pre>
koji=> select * from users;
</pre>}}

A ce stade, aucune action ne peut être démarrée tant que le kojihub n'est pas configuré et le serveur web démarré.

== Koji Hub ==

koji-hub est le centre nerveux de toutes les opérations Koji. Il s'agit d'un serveur XML-RPC fonctionnant sous mod_python pour Apache. koji-hub est passif : il ne reçoit que les appels XML-RPC et s'appuie sur les autres outils de la suite pour la construction. koji-hub est le seul composant qui a un accès direct à la base de données et est l'un des deux composants qui ont un accès en écriture au système de fichiers.

'''Fichiers de Configuration'''

* /etc/httpd/conf/httpd.conf
* /etc/httpd/conf.d/kojihub.conf
* /etc/httpd/conf.d/ssl.conf (when using ssl auth)
* /etc/koji-hub/hub.conf
* /etc/koji.conf

Le répertoire de travail sera <path>/mnt/koji</path>.
{{Admon/bug|Répertoire de travail de Koji|Si le répertoire de travail de Koji n'est pas <path>/mnt/koji</path>, il est impératif de créer un lien symbolique du répertoire de travail de Koji dans <path>/mnt</path>:
<pre>ln -s /path/to/koji/datadir /mnt/koji</pre>}}

===Installation de {{class|koji-hub}}===
<pre>
yum install koji-hub httpd mod_ssl
</pre>

=== Configuration ===

On bride tout d'abord le nombre maximum de requête sur le serveur [[Webserver/Apache|apache]] à une valeur plus raisonnable afin de prévenir une saturation et/ou un crash du serveur web.
{{Admon/file|<path>/etc/httpd/conf/httpd.conf</path>|
<syntaxhighlight lang="apache">
<IfModule prefork.c>
...
MaxRequestsPerChild 100
</IfModule>
<IfModule worker.c>
...
MaxRequestsPerChild 100
</IfModule>
</syntaxhighlight>}}

Le répertoire <path>/mnt/koji/packages</path> doit être accessible par HTTP. On ajoute donc un alias.

{{Admon/file|<path>/etc/httpd/conf.d/kojipackages.conf</path>|
<syntaxhighlight lang="apache">
Alias /packages "/mnt/koji/packages"
<Directory "/mnt/koji/packages">
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</syntaxhighlight>}}

{{Admon/file|<path>/etc/httpd/conf.d/ssl.conf</path>|
<syntaxhighlight lang="apache">
LoadModule ssl_module modules/mod_ssl.so

Listen 443

SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300

SSLMutex default

SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin

SSLCryptoDevice builtin

<VirtualHost _default_:443>
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite RC4-SHA:AES128-SHA:ALL:!ADH:!EXP:!LOW:!MD5:!SSLV2:!NULL

SSLCertificateFile /etc/pki/koji/certs/kojihub.crt
SSLCertificateKeyFile /etc/pki/koji/certs/kojihub.key
SSLCertificateChainFile /etc/pki/koji/koji_ca_cert.crt
SSLCACertificateFile /etc/pki/koji/koji_ca_cert.crt
SSLVerifyClient require
SSLVerifyDepth 10

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
</syntaxhighlight>}}

{{Admon/file|<path>/etc/httpd/conf.d/kojihub.conf</path>|
<syntaxhighlight lang="apache">
Alias /kojihub /usr/share/koji-hub/kojixmlrpc.py

<Directory "/usr/share/koji-hub">
Options ExecCGI
SetHandler wsgi-script
Order allow,deny
Allow from all
</Directory>

Alias /kojifiles "/mnt/koji/"

<Directory "/mnt/koji">
Options Indexes SymLinksIfOwnerMatch
AllowOverride None
Order allow,deny
Allow from all
</Directory>

<Location /kojihub/ssllogin>
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +StdEnvVars
</Location>

<Location /kojihub>
SSLOptions +StdEnvVars
</Location>
</syntaxhighlight>}}

{{Admon/file|<path>/etc/koji-hub/hub.conf</path>|
<syntaxhighlight lang="ini">
[hub]
DBName = koji
DBUser = koji
DBHost = localhost
KojiDir = /mnt/koji

DNUsernameComponent = CN
ProxyDNs = /C=FR/ST=Languedoc Roussillon/O=Home/OU=kojiweb/CN=koji.didier-linux.eu/emailAddress=root@didier-linux.eu|/C=FR/ST=Languedoc Roussillon/O=Home/OU=Admin/CN=didier/emailAddress=didier@didier-linux.eu

LoginCreatesUser = On
KojiWebURL = http://koji.didier-linux.eu/koji
EmailDomain = didier-linux.eu
NotifyOnSuccess = True
</syntaxhighlight>}}

{{Admon/file|<path>/etc/koji.conf</path>|
<syntaxhighlight lang="ini">
[koji]
server = http://koji.didier-linux.eu/kojihub
weburl = http://koji.didier-linux.eu/koji
topurl = http://koji.didier-linux.eu/kojifiles
topdir = /mnt/koji
cert = ~/.koji/client.crt
ca = ~/.koji/clientca.crt
serverca = ~/.koji/serverca.crt
</syntaxhighlight>}}

=== Configuration de [[Security/SELinux|SELinux]] ===
Si le mode enforcing est utilisé, on doit autoriser [[Webserver/Apache|apache]] à acceder au serveur [[SGBD/PostgreSQL]]. Même si le mode est permissive, il est recommandé de lancer la commande suivante afin de se prémunir d'un changement de mode de [[Security/SELinux|SELinux]].

<pre>
setsebool -P httpd_can_network_connect_db 1
</pre>

=== Squelette des fichiers Koji ===

Avant que les autres composants de Koji puissent fonctionner correctement, On doit créer la structure et modifié les droits de celui-ci.

<syntaxhighlight lang="bash">
cd /mnt
mkdir koji
cd koji
mkdir {packages,repos,work,scratch}
chown apache.apache *
</syntaxhighlight>

Ici, [[Webserver/Apache|apache]] peut être redémarré et on peut effectuer des opérations minimales sur notre serveur Koji via le client en ligne de commande: gestion des utilisateurs et des constructeurs.

Il faut s'assurer que le client est configuré par défaut ( fichier <path>/etc/koji.conf</path> et que les certificats sont en place dans le home de l'administrateur.

{{Admon/note|Fichier de configuration alternatif|Si un fichier de configuration personnel autre que <path>~/.koji/config</path> est utilisé, il faut utilisé la commande koji avec l'option '''-c'''.}}
La commande suivante teste le login administrateur sur le serveur Koji.
koji call getLoggedInUser

{{Admon/important|Droit des daemons|Kojira a besoin du privilège '''repo''' avant le lancement du daemon. C'est pourquoi il est vivement recommandé de créer cet utilisateur maintenant et de lui ajouter le privilège

<pre>
koji add-user kojira
koji grant-permission repo kojira
</pre>

Pour des raisons similaires, les hôtes de constructions doivent être ajoutés avant le démarrage du daemon kojid.

<pre>
koji add-host kojibuilder1 x86_64 i386
koji add-host kojibuilder2 ppc ppc64
koji add-host kojibuilder3 ia64
</pre>}}

== Koji Web - Interface for the Masses ==

Koji-web est un jeu de scripts qui tournent avec mod_wsgi et qui utilise le moteur de modèle Cheetah pour fournir une interface web à Koji. Koji-web affiche beaucoup d'informations et propose même quelques opérations comme l'abandon de tâche.

'''Fichiers de Configuration:'''
* /etc/kojiweb/web.conf
* /etc/httpd/conf.d/kojiweb.conf
* /etc/httpd/conf.d/ssl.conf

'''Installation de Koji-Web:'''
<pre>
yum install koji-web mod_ssl
</pre>

==== Configuration obligatoire ====

La configuration doit fournir à Koji-web les URLs d'accès à Koji-hub, aux paquets koji (builds) et à sa propre interface. Il est judicieux de modifier aussi le secret (directive ''PythonOption Secret''.

Avec l'authentification SSL, elle doit aussi fournir le nom des certificats à utiliser et la directive ''PythonOption WebCert'' doit contenir '''la clé publique ET la clé privée'''.
{{Admon/file|<path>/etc/kojiweb/web.conf</path>|
<pre>
[web]
SiteName = koji
KojiTheme = didier

KojiHubURL http://koji.didier-linux.eu/kojihub
KojiFilesURL http://www.didier-linux.eu/kojifiles

WebCert /etc/pki/koji/kojiweb.pem
ClientCA /etc/pki/koji/koji_ca_cert.crt
KojiHubCA /etc/pki/koji/koji_ca_cert.crt

LoginTimeout 72
Secret CHANGE_ME

LibPath = /usr/share/koji-web/lib
</pre>}}

==== Configuration Optionnelle ====

Il faut éditer le fichier <path>/etc/httpd/conf.d/kojiweb.conf</path> pour configurer l'authentification choisie.

{{Admon/file|<path>/etc/httpd/conf.d/kojiweb.conf</path>|
<pre>
<Location /koji/login>
SSLOptions +StdEnvVars
</Location>
</pre>}}

{{Admon/file|<path>/etc/httpd/conf.d/ssl.conf</path>|
<pre>
SSLVerifyClient require
SSLVerifyDepth 10
</pre>}}

==== Interface Web opérationnelle ====

L'interface Web du koji est maintenant accessible et la plupart des opérations de lecture doivent fonctionner et chaque utilisateur doit pouvoir se connecter.

== Koji Daemon - Builder ==

Kojid est le daemon de construction qui tourne sur chaque constructeur. son rôle principale est de traiter les requêtes de construction. Koji ne se limite cependant pas aux tâches de construction puisqu'il peut aussi construire des images ISO, des disques virtuels (appliances). Kojid utilise mock pour créer des environnements de construction minimaliste et en créé pour chaque construction. Ceci permet le compartimentage des constructions et les constructions ne peuvent pas se gêner les unes les autres. Kojid est écrit en python et communique avec le hub via XML-RPC.

'''fichiers de Configuration'''
* Configuration du daemon Kojira: /etc/kojid/kojid.conf
* Variables de lancement du daemon: /etc/sysconfig/kojid

'''Installation de kojid:'''
<pre>
yum install koji-builder
</pre>

==== Configuration générale ====

Le fichier de configuration de chaque constructeur doit être édité afin que la directive ''server'' pointe sur l'hôte supportant le Koji-hub. La directive ''user'' doit contenir le nom d'hôte du constructeur.
{{Admon/file|<path>/etc/kojid/kojid.conf</path>|
<pre>
; The URL for the xmlrpc server
server=http://hub.example.com/kojihub

; the username has to be the same as what you used with add-host
; in this example follow as below
user = kojibuilder1.example.com
</pre>}}

La directive ''workdir'' peut être différente entre les constructeurs mais elle ne doit pas être le répertoire de travail du Koji (<path>/mnt/koji</path>)
{{Admon/file|<path>/etc/kojid/kojid.conf</path>|
<pre>
; The directory root for temporary storage
workdir=/tmp/koji
</pre>}}

==== Configuration des certificats SSL ====

Ces entrées doivent être éditées pour pointer sur les bons certificats générés précédemment.
{{Admon/file|<path>/etc/kojid/kojid.conf</path>|
<pre>
;client certificate
; This should reference the builder certificate we created above, for
; kojibuilder1.example.com
cert = /etc/kojid/kojid.pem

;certificate of the CA that issued the client certificate
ca = /etc/kojid/koji_ca_cert.crt

;certificate of the CA that issued the HTTP server certificate
serverca = /etc/kojid/koji_ca_cert.crt
</pre>}}
{{Admon/important|Copie des certificats sur l'hôte|Les certificats SSL doivent être copiés depuis l'hôte abritant le Koji-hub sur les constructeurs dans le répertoire <path>/etc/kojid</path> pour que les constructeurs puissent s'authentifier.}}

==== Ajout d'un hôte à la base de données des constructeurs ====

Il faut maintenant ajouter l'hôte à la base de données des constructeurs afin qu'il puisse être utilisé par Koji-hub.
{{Admon/important|L'ajout doit être fait avant le premier démarrage du daemon de construction|Sinon, il faudra purger les entrées à la main dans les tables ''sessions'' et ''users
'' avant de pouvoir démarrer avec succès le daemon.}}
<pre>
koji add-host kojibuilder1.didier-linux.eu i386 x86_64
</pre>
Le premier argument après la commande est le nom d'hôte du constructeur. Le second argument spécifie l'(les) architecture(s) utilisées par l'hôtes.

==== Ajout de l'hôte au canal de création ====

Les canaux sont un moyen de contrôler quel constructeur fait quoi. Par défaut les hôtes sont ajouté au canal ''default''. Il faut qu'au moins quelques uns (1 au minimum) soient ajoutés au canal ''createrepo'' pour pouvoir lancer les travaux kojira sur les dépôts.
<pre>
koji add-host-to-channel kojibuilder1.didier.eu createrepo
</pre>

==== Capacité ====

La capacité d'un hôte par défaut est de 2, ce qui veut dire que le daemond econstruction n'acceptera pas de travail supplémentaire si le load average est supérieur à 2. Ce paramètre est différent de celui du nombre maximal de travaux (fichier de configuration). Avant que ledaemon de construction n'accepte un nouveau travail, il s'assure que le load average est inférieur à la capacité et que le nombre de travaux est inférieur au nombre maximal. Toutefois, à l'ère des CPU multi-coeurs, un load average de 2 est insuffisant pour consommer 100% des ressources du système. Il n'y a pas d'option pour définir la capacité en ligne de commande, cela doit être fait en base (psql).

<pre>
koji@localhost$ psql koji
koji=# select (id, name, capacity) from host;
row
--------------------------------
(1,kojibuilder1.didier-linux.eu,2)
(2,kojibuilder2.didier-linux.eu,2)
(2 rows)

koji=# update host set capacity = 16 where id = 1;
UPDATE 1
koji=#
</pre>

==== Démarrage du daemon Kojid ====

Une fois le constructeur ajouté à la base de données, on peut démarrer son daemon de construction.
<pre>
systemctl start kojid
</pre>
On vérifie dans le fichier <path>/var/log/kojid.log</path> qur le daemon a bien démarré. Si aucune erreur n'est rapportée, c'est que le daemon doit être correctement configuré et démarré. On peut le vérifier sur l'interface Koji-web dans l'onglet ''hôtes''. Cette page affiche le liste des constructeurs et leur status.

== Kojira - Création et maintenance du dépôt ==
'''Fichiers de Configuration:'''
* Configuration du daemon Kojira: <path>/etc/kojira/kojira.conf</path>
* Variables de lancement du daemon: <path>/etc/sysconfig/kojira</path>

'''Installation de kojira'''
yum install koji-utils

==== Configuration générale ====
La directive ''server'' a besoin de pointer sur le koji-hub.
{{Admon/file|<path>/etc/kojira/kojira.conf</path>|
<pre>
; The URL for the xmlrpc server
server=http://koji.didier-linux.eu/kojihub
</pre>}}
{{Admon/important|Note importante|
* Kojira a besoin d'un accès en lecture/écriture sur <path>/mnt/koji</path>.
* Il ne devrait exister qu'une seule instance de {{class|kojira}} à la fois.
* Il n'est pas recommandé de lancer kojira sur les constructeurs, car ceux-ci n'ont besoin que d'un accès en lecture seule sur le répertoire <path>/mnt/koji</path>.}}

==== Configuration de l'authentification SSL ====

{{Admon/file|<path>/etc/kojira/kojira.conf</path>|
<pre>
;client certificate
; This should reference the kojira certificate we created above
cert = /etc/pki/koji/kojira.pem

;certificate of the CA that issued the client certificate
ca = /etc/pki/koji/koji_ca_cert.crt

;certificate of the CA that issued the HTTP server certificate
serverca = /etc/pki/koji/koji_ca_cert.crt
</pre>}}

''The local user kojira runs as needs to be able to read and write to /mnt/koji/repos/.
If the volume that directory resides on is root-squashed or otherwise unmodifiable
by root, you can set '''RUNAS=''' to a user that has the required privileges.''

{{Admon/file|<path>/etc/sysconfig/kojira</path>|
<pre>
FORCE_LOCK=Y
KOJIRA_DEBUG=N
KOJIRA_VERBOSE=Y
RUNAS=root
</pre>}}

==== Ajout de l'utilisateur kojira à Koji ====
Si cela n'a pas été déjà fait, création de l'utilisateur kojira et ajout du droit '''repo''' à celui-ci. Cela doit être fait avec le compte de l'administrateur de Koji.
<pre>
koji add-user kojira
koji grant-permission repo kojira
</pre>

=== Démarrage du deamon Kojira ===
<pre>
systemctl start kojira.service
</pre>
On vérifie dans le fichier <path>/var/log/kojira/kojira.log</path> que {{class|kojira}} a bien démarré.

== SELinux ==
<pre>
semanage fcontext -a -t httpd_sys_rw_content_t '/mnt/koji(/.*)?'
restorecon -Rv /mnt/koji
</pre>

==Notes==
<references />

[[Catégorie:RPM|Install Koji]]
[[Catégorie:Koji|Install]]
[[Catégorie:Server|Install Koji]]

Koji/SigulUsing

2015-04-23T08:53:42Z

Didier : /* FAQ */

== Sigul ==

après une [[Koji/SigulInstall|installation de Sigul]], on peut l'utiliser.
{{Admon/note|Commandes disponible|<pre>$ sigul --help-commands
delete-key Delete a key
modify-key-user Modify user's key access
list-users List users
grant-key-access Grant key access to a user
sign-text Output a cleartext signature of a text
import-key Import a key
new-user Add a user
sign-rpm Sign a RPM
list-keys List keys
sign-data Create a detached signature
revoke-key-access Revoke key acess from a user
user-info Show information about a user
change-passphrase Change key passphrase
list-key-users List users that can access a key
new-key Add a key
modify-user Modify a user
sign-rpms Sign one or more RPMs
modify-key Modify a key
delete-user Delete a user
key-user-info Show information about user's key access
get-public-key Output public part of the key
</pre>
}}

=== Créer une nouvelle clé ===

Une fois le client Sigul capable d'envoyer des commandes à <class>Sigul</class>, on peut créer une nouvelle clé nommée '''centos-5-key'''.
sigul new-key --name-real='CentOS-5-B2PWeb' --name-comment='CentOS 5 B2PWeb Signing Key' --name-email='srs@b2pweb.com' --key-admin root centos-5-key
{{Admon/note|Générer beaucoup d'entropie durant le génération de la clé|La génération de la clé nécessite beaucoup d'entropie sur le serveur Sigul. On peut donc occuper le serveur et paradoxalement accélerer la génération de la clé.

La commande suivant génère assez d'entropie pour 2 minutes:
<pre>find / > /dev/null 2>&1</pre>}}<pre>
$ sigul new-key --help
usage: client.py new-key [options] key

Add a key

options:
-h, --help show this help message and exit
--key-admin=USER Initial key administrator
--name-real=NAME_REAL
Real name of key subject
--name-comment=NAME_COMMENT
A comment about of key subject
--name-email=NAME_EMAIL
E-mail of key subject
--expire-date=YYYY-MM-DD
Key expiration date
</pre>

=== Import d'une clé existante ===
sigul import-key 'CentOS-5-B2PWeb' ~/.gnupg/secring.gpg

=== Changer le nom de la clé ===
Changer le nom de la clé '''centos5''' en '''centos-5-key'''<pre>sigul modify-key --new-name centos-5-key centos5</pre>

=== Ajout d'un utilisateur ===

* Ajout d'un utilisateur administrateur<pre>sigul new-user --admin --with-password didier</pre>

=== Autoriser l'utilisation d'une clé existante à un utilisateur ===
<pre>sigul grant-key-access centos-5-key didier</pre>
<pre>
sigul grant-key-access --help
usage: client.py grant-key-access key user

Grant key access to a user

options:
-h, --help show this help message and exit
</pre>

=== Modifier la phrase de passe ===
sigul change-passphrase centos-5-key
<pre>
sigul change-passphrase --help
usage: client.py change-passphrase key

Change key passphrase

options:
-h, --help show this help message and exit
</pre>

=== FAQ ===

{{Admon/faq|ERROR: I/O error: Unexpected EOF in NSPR|
* S'assurer que le répertoire des clés existe. Ce chemin est déclaré dans le fichier <path>/etc/sigul/server.conf</path><pre>gnupg-home: /var/lib/sigul/server/gnupg</pre>
** Propriétaire: '''sigul'''
** Groupe: '''sigul'''
** Droits: 0700 '''rwx------'''
** Lien symbolique '''/var/lib/sigul/gnupg''' pointant sur <path>/var/lib/sigul/server/gnupg</path>
* S'assurer qu'il y a suffisamment d'espace disque ( en gros deux fois la taille du plus gros paquet RPM )
* S'assurer que les daemons sigul_bridge et sigul_server sont démarrés<pre>service sigul_server status && service sigul_bridge status</pre>
* S'assurer que le pont peut se connecter au serveur ( [[Koji/SigulInstall#Firewall| Configure firewall]] )}}

{{Admon/faq|Error: Unknown error|
Vérifier les journaux du serveur, l'erreur est surement plus explicite
* <pre>/usr/bin/rpmsign: No such file or directory</pre>Il suffit d'installer le paquet <package>rpm-sign</package> qui n'est pas installé par défaut sur centos 7. Un simple <code>yum provides /usr/bin/rpmsign</code> donne le paquet à installer.}}

{{Admon/faq|Unknown error on creating key process|
* Installer le paquet <package>gnupg1</package> depuis [ http://people.redhat.com/mitr/rpmsigner/rhel6 ] ou de [ http://infrastructure.stg.fedoraproject.org/repo/builder-rpms/6Server/SRPMS/ ]
* S'assurer que Sigul est configurer pour utiliser <package>gnupg1</package><pre>sed -i -e '/gnupg_bin/s,^.*$,gnupg_bin = "/usr/bin/gpg1",' /usr/share/sigul/settings.py</pre>
* S'assurer que le paquet <package>python-sqlalchemy</package> soit installé}}

{{Admon/faq|Certificats client expirés|
Une fois le certificat client expiré, il faut le désactiver localement<pre>certutil -d ~/.sigul -D -n sigul-client-cert</pre> et refaire une génération de certificat client.}}

== Interfacer Sigul et koji ==

=== configuration ===

<class>Sigul</class> peut être utiliser pour signer un ou de multiples RPMs dans une instance <class>Koji</class>. Une fois le client Sigul correctement configuré, il suffit juste de configurer l'utilisateur Proxy pour Koji. Quand un client <class>Sigul</class> émet une requête de signature pour <class>Koji</class>, le pont <class>Sigul</class> se connecte à <class>Koji</class> en tant qu'utilisateur '''kojiweb'''. Il faut juste s'assurer que l'utilisateur demandeur a les droits administrateur sur le <class>Koji</class> et <class>Sigul</class> s'occupe du reste.

La configuration pour <class>Koji</class> peut être situer n'importe où, du moment que l'utilisateur sigul a droit de lecture. Les certificats pour '''kojiweb''' doivent être copiés dans le même chemin que la configuration <class>Koji</class>

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash">su - sigul</syntaxhighlight>
* Création du répertoire de configuration de <class>Koji</class><syntaxhighlight lang="bash">mkdir -p ~/.koji</syntaxhighlight>
* Copie de la configuration par défaut du client <class>Koji</class><syntaxhighlight lang="bash">cp /etc/koji.conf ~/.koji/config</syntaxhighlight>
* Copie des certificats {{class|Kojiweb}} dans celui-ci<syntaxhighlight lang="bash">cp /etc/pki/koji/pem/kojiweb.pem .koji/client.pem</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/clientca.crt</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/serverca.crt</syntaxhighlight>

Après avoir redémarrer le pont <class>Sigul</class>, le client doit être capable d'obtenir un RPM depuis Koji et de le signer.

=== Test ===

Pour tester l'interfaçage, on va obtenir un RPM depuis <class>Koji</class>, le signer et le sauvegarder dans le répertoire de travail actuel. c'est juste pour tester la connxion et l'authentification sur <class>Koji</class> et <class>Sigul</class>.
<syntaxhighlight lang="bash">sigul sign-rpm -o signed.rpm key_name unsigned.rpm</syntaxhighlight>

Si la commande précédente fonctionne, un RPM signé est présent dans le répertoire de travail actuel.

On vérifie sa signature
<syntaxhighlight lang="bash">rpm --checksig signed.rpm</syntaxhighlight>

== Script sigulsign_unsigned.py ==

Le script est à récupérer depuis un depôt releng de Fedora via git (git://git.fedorahosted.org/git/releng) ou directement depuis https://git.fedorahosted.org/cgit/releng/tree/scripts/sigulsign_unsigned.py

Avant de pouvoir utiliser ce script magique qui va signer tous les RPM non-signés (derniers m-v-r) construit dans le Koji, il est nécessaire de modifier quelques variables:
* Changer l'URL du HUB Koji (2 fois): KOJIHUB
* Spécifier nos propres fichiers de certificats: SERVERCA, CLIENTCA, CLIENTCERT
* Ajout de nos clés de signature: KEYS
{{Admon/warning|Casse de l'ID dans le script sigulsign_unsigned.py|GPG rapporte un ID écrit en majuscule mais dans le script, celui-ci doit être renseigné en minuscule pour que le processus fonctionne.}}

Pour obtenir l'ID de nos clés:
* exporter de la clé<pre>sigul get-public-key centos-5-key > centos-5-key.asc</pre>
* importer dans GPG<pre>gpg --import centos-5-key.asc</pre>
* Lister nos clé GPG<pre>gpg --list-keys</pre>
<pre>
/root/.gnupg/pubring.gpg
------------------------
pub 1024D/773DF357 2013-08-20
uid CentOS-5-B2PWeb (CentOS 5 B2PWeb Signing Key) <srs@b2pweb.com>
sub 2048g/EBC96FF2 2013-08-20
</pre>
L'ID de notre clé '''centos-5-key''' est 773DF357
<syntaxhighlight lang="diff">
Change koji hostname, certificate files and add B2PWeb signing keys
diff -u a/sigulsign_unsigned.py b/sigulsign_unsigned.py
--- a/sigulsign_unsigned.py 2013-08-21 10:05:57.418032284 +0200
+++ b/sigulsign_unsigned.py 2013-08-21 10:13:11.683976970 +0200
@@ -38,11 +38,11 @@ rpmdict = {}
unsigned = []
loglevel = ''
passphrase = ''
-KOJIHUB = 'https://koji.fedoraproject.org/kojihub'
+KOJIHUB = 'http://koji.b2pweb.com/kojihub'
# Should probably set these from a koji config file
-SERVERCA = os.path.expanduser('~/.fedora-server-ca.cert')
-CLIENTCA = os.path.expanduser('~/.fedora-upload-ca.cert')
-CLIENTCERT = os.path.expanduser('~/.fedora.cert')
+SERVERCA = os.path.expanduser('~/.koji/serverca.crt')
+CLIENTCA = os.path.expanduser('~/.koji/clientca.crt')
+CLIENTCERT = os.path.expanduser('~/.koji/client.pem')
# Setup a dict of our key names as sigul knows them to the actual key ID
# that koji would use. We should get this from sigul somehow.
KEYS = {'fedora-12-sparc': {'id': 'b3eb779b', 'v3': True},
@@ -67,7 +67,9 @@ KEYS = {'fedora-12-sparc': {'id': 'b3eb7
'fedora-10': {'id': '4ebfc273', 'v3': False},
'fedora-10-testing': {'id': '0b86274e', 'v3': False},
'epel-6': {'id': '0608b895', 'v3': True},
- 'epel-5': {'id': '217521f6', 'v3': False}}
+ 'epel-5': {'id': '217521f6', 'v3': False},
+ 'centos-5-key' : {'id': '773df357', 'v3': True},
+ 'centos-6-key' : {'id': 'd3f3c56a', 'v3': True}}

def exit(status):
"""End the program using status, report any errors"""
@@ -213,7 +215,7 @@ if not (opts.just_list or opts.just_writ

# Reset the KOJIHUB if the target is a secondary arch
if opts.arch:
- KOJIHUB = 'http://%s.koji.fedoraproject.org/kojihub' % opts.arch
+ KOJIHUB = 'http://%s.koji.b2pweb.com/kojihub' % opts.arch
# setup the koji session
logging.info('Setting up koji session')
kojisession = koji.ClientSession(KOJIHUB)
</syntaxhighlight>

=== Signature d'un ou plusieurs paquets ===

C'est utile afin de signer des paquets qui ne sont pas les derniers construits (dernier N-V-R)
<syntaxhighlight lang="bash">
sigulsign_unsigned.py -v --password="motdepasse" --inherit centos-6-key <N-V-R>
</syntaxhighlight>

exemple:

<syntaxhighlight lang="bash">
sigulsign_unsigned.py -v --password="$(cat /root/.sigul/centos-6-key)" --inherit centos-6-key appliance-tools-007.0-1.el6
</syntaxhighlight>

Koji/Installation

2015-04-22T10:14:01Z

Didier : /* Koji Web - Interface for the Masses */

'''Mettre en place un système de construction de RPM Koji'''

== Présentation ==
{{class|Koji}} est une suite logicielle de construction de RPM. Il utilise [[RPM/Mock|mock]] pour créer des environnements
chrootés et y effectuer les builds.

[[Fichier:KojiArch.svg|441px|vignette|centré|Architecture du koji]]

* '''Koji-Hub''' C'est le centre nerveux de toutes les opérations Koji. Il s'agit d'un serveur XML-RPC fonctionnant sous mod_python pour Apache. {{class|koji-hub}} est passif : il ne reçoit que les appels XML-RPC et s'appuie sur les autres outils de la suite pour la construction. {{class|koji-hub}} est le seul composant qui a un accès direct à la base de données et est l'un des deux composants qui ont un accès en écriture au système de fichiers.
* '''Kojid''' ou '''Koji-builder''' C'est le démon de compilation qui s'exécute sur chacune des machines de construction. Sa principale responsabilité est de scruter les demandes de construction entrantes et de les exécuter. Pour cela, {{class|kojid}} interroge {{class|koji-hub}}. {{class|Kojid}} est également responsable d'autres tâches que la construction : la création d'images d'installation par exemple. kojid utilise Mock pour la construction. Il crée également un buildroot vierge pour chaque génération. kojid est écrit en Python et communique avec koji-hub par l'intermédiaire de XML-RPC.
* '''Koji-Web''' C'est un ensemble de scripts qui s'exécutent avec mod_python et utilise le moteur de templates Cheetah pour fournir une interface web à {{class|Koji}}. Il agit comme un client à {{class|koji-hub}} en offrant une interface d'aministration limitée. {{class|koji-Web}} expose un grand nombre d'informations et fournit également un moyen pour certaines opérations, telles que l'annulation de builds.
* '''Koji-client''' C'est une interface en ligne de commande ( CLI = Command Line Interface ) écrit en Python qui fournit de nombreux hooks à {{class|Koji}}. Il permet à l'utilisateur d'interroger la plupart des données ainsi que d'effectuer des actions telles que l'ajout d'utilisateurs et de lancer la construction des demandes.
* '''Kojira''' C'est un démon qui garde la racine de construction repodata à jour. Il est responsable de l'enlèvement des racines redondantes et du nettoyage après une demande de construction est terminée.

Les composants de {{class|Koji}} peuvent être installés sur des serveurs différents. La seule obligation est d'autoriser la communication entre les différents composants de la suite.

{{class|Koji}} supporte nativement l'authentification par serveur Kerberos et par certificat SSL. Seul {{class|koji-client}} supporte l'authentification par mot de passe. De ce fait, l'authentification par mot de passe ne sera même pas abordée.

La méthode d'authentification doit être choisie dès le début de l'installation. Dans la suite de ce document, nous mettrons en place la méthode SSL.

{{class|Koji}} utilise beaucoup d'espace disque dans son répertoire primaire <path>/mnt/koji</path>. De plus Mock en utilisera beaucoup aussi sur les répertoires <path>/var/lib/mock</path> et <path>/var/cache/mock</path>. Il vaut mieux prévoir des partitions dédiées à ces répertoires ( les répertoires de Mock doivent appartenir au groupe mock et avoir les permissions 02755 ).

Pour un aperçu rapide des outils utilisés : [[RPM/Yum|yum]], [[RPM/Mock|mock]], {{class|Koji}} (et tous ses composants), [[RPM/Mash|mash]], et comment ils fonctionnent ensemble, il existe une excellente présentation <ref>Présentation des outils de création/gestion des RPM [http://indico.cern.ch/event/55091 | Version online ] Version offline: [[Fichier:MockKojiMash.pdf]] ( non mise à jour )</ref> créée par Steve Traylen du CERN.

Le dépôt git de RussianFedora avec les fichiers de configuration de {{class|Koji}} <ref>https://github.com/RussianFedora/koji-setup</ref>

=== Connaissances requises ===
* Connaissances basiques de l'authentification par certificat SSL.
* Connaissances basiques de création de base de données PostgreSQL and d'importation de structure de base
* Connaissances basiques de l'outil psql
* Connaissances basiques de configuration d'Apache
* Connaissances basiques des outils yum/createrepo/mock
* Connaissances basiques de la ligne de commandes
* Connaissances basiques sur la construction de RPM

=== Dépendances ===

Sur le serveur ({{class|koji-hub}} / {{class|kojiweb}} )
* httpd
* mod_ssl
* postgresql-server
* mod_wsgi
* MySQL-python

Sur les constructeurs ( {{class|kojid}} )
* mock
* setarch
* rpm-build
* createrepo

Si le mode d'authentification choisie est Kerberos, il faudra aussi que le réseau local ait un serveur DNS et une dépendance supplémentaire est à installer sur le serveur et les constructeurs.
* mod_auth_kerb

=== Espace disque ===

comme <class>Koji</class> utilise [[RPM/Mock|Mock]], les répertoires <path>/var/lib/mock</path> et <path>/var/cache/mock</path> grossiront mais une purge de ces répertoires est mise en place par Koji.

Les répertoires qui vont grossir au fur et à mesure de l'utilisation sont ceux de:
* Mock:
* La base de données: <path>/var/lib/psql</path>
* Le répertoire principal de Koji: <path>/mnt/koji</path>
* Le répertoire des dépôts: <path>/mnt/repo</path>
Il sera donc judicieux de leur attribuer une partition spécifique avec une taille dynamique (lvm)

== Génération des certificats SSL ==

Ces certificats serviront à l'authentification des éléments de Koji sur le {{class|koji-hub}}.

Création du répertoire des certificats

<syntaxhighlight lang="bash">
mkdir /etc/pki/koji && cd /etc/pki/koji
</syntaxhighlight>
Création du fichier de configuration de nos futurs certificats
{{Admon/file|<path>/etc/pki/koji/ssl.cnf</path>|
<pre>
HOME = .
RANDFILE = .rand

[ca]
default_ca = ca_default

[ca_default]
dir = .
certs = $dir/certs
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/%s_ca_cert.pem
private_key = $dir/private/%s_ca_key.pem
serial = $dir/serial
crl = $dir/crl.pem
x509_extensions = usr_cert
name_opt = ca_default
cert_opt = ca_default
default_days = 3650
default_crl_days = 30
default_md = sha256
preserve = no
policy = policy_match

[policy_match]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[req]
default_bits = 4096
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = MASK:0x2002

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = FR
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Languedoc Roussilon
localityName = Locality Name (eg, city)
localityName_default = Beaucaire
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Home
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (eg, your name or your server\'s hostname)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64

[req_attributes]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name

[usr_cert]
basicConstraints = CA:FALSE
nsComment = "OpenSSL Generated Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always

[v3_ca]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true
</pre>}}
{{Admon/note|Modification du fichier ssl.cnf|Bien que cela ne soit pas obligatoire, il est recommandé d'éditer les champs suffixés par '''_default''' dans la section '''[req_distinguished_name]''', afin de coller aux informations du serveur en cours d'installation Cela vous permettra d'accepter directement les valeurs proposées par défaut à la génération des certificats. Les autres sections n'ont pas besoin d'être éditées.}}

=== Génération de l'autorité de certification ===

Toujours depuis le répertoire /etc/pki/koji, on initialise notre générateur et on génère l’autorité de certification. Celle-ci se compose d'une paire clé/certificat qui servira à signer tous les autres certificats.

Ici, le CN sera obligatoirement le nom d'hôte du serveur (FQDN), les autres renseignements ne sont pas bloquants pour la suite.
<syntaxhighlight lang="bash">
cd /etc/pki/koji/
mkdir {certs,private,confs}
touch index.txt
echo 01 > serial
openssl genrsa -out private/koji_ca_cert.key 4096
openssl req -config ssl.cnf -new -x509 -days 3650 -key private/koji_ca_cert.key \
-out koji_ca_cert.crt -extensions v3_ca
</syntaxhighlight>

=== Générer les certificats des composants de Koji et le certificat de l'administrateur===

Chaque composant de Koji a besoin d'un certificat.
Kojihub et kojiweb ont besoin d'avoir le nome d'hôte pleinement qualifié (FQDN) en CN, on se servira de OU pour distinguer les certificats. Pour les autres certificats, le CN doit être le nom du composant ( kojira ), le login du compte administrateur ou le nom du builder qui sera définit avec koji-client.
Par simplicité, on va se servir de ces scripts pour générer les certificats des composants et les certificats web.

Script de génération des certificats
{{Admon/file|<path>/etc/pki/koji/generate-certificate.sh</path>|
<syntaxhighlight lang="bash">
#!/bin/bash
#if you change your certificate authority name to something else you will need to change the caname value to reflect the change.
caname=koji

# user is equal to parameter one or the first argument when you actually run the script
user=$1

if [[ "$user" == "" ]]
then
echo "Usage: $(basename $0) USER"
exit
fi

echo "Generate certificates for \"${user}\""

openssl genrsa -out certs/${user}.key 4096

cat ssl.cnf | sed 's/insert_hostname/'${user}'/'> ssl2.cnf

openssl req -config ssl2.cnf -new -nodes -out certs/${user}.csr -key certs/${user}.key

openssl ca -config ssl2.cnf -keyfile private/${caname}_ca_cert.key -cert ${caname}_ca_cert.crt \
-out certs/${user}.crt -outdir certs -infiles certs/${user}.csr

cat certs/${user}.crt certs/${user}.key > ${user}.pem

mv ssl2.cnf confs/${user}-ssl.cnf

</syntaxhighlight>}}

Script de génération des certificats pour les navigateurs Web
{{Admon/file|<path>/etc/pki/koji/generate-web-certificate.sh</path>|
<syntaxhighlight lang="bash">
#!/bin/bash
#if you change your certificate authority name to something else you will need to change the caname value to reflect the change.
caname=koji

# user is equal to parameter one or the first argument when you actually run the script
user=$1

if [[ "$user" == "" ]]
then
echo "Usage: $(basename $0) USER"
exit
fi

echo "Generate web certificates for \"${user}\""

openssl pkcs12 -export -inkey certs/${user}.key -in certs/${user}.crt -CAfile ${caname}_ca_cert.crt \
-out certs/${user}_browser_cert.p12
</syntaxhighlight>}}

On génère les certificats comme cela pour tous les composants et users du tableau récapitulatif:
<syntaxhighlight lang="bash">
cd /etc/pki/koji/
./generate-certificate.sh kojiweb
</syntaxhighlight>
Le user choisi pour être le koji admin est le user didier.

De plus pour les utilisateurs (réels) de {{class|koji}}, on générera les certificats web comme ceci:
<syntaxhighlight lang="bash">
./generate-web-certificate.sh didier
</syntaxhighlight>

{| class="wikitable"
! Nom du certificat
! CN (commonName)
! OU (organizationalUnitName)
|-
| kojihub
| koji.didier-linux.eu (FQDN)
| kojihub
|-
| kojiweb
| koji.didier-linux.eu (FQDN)
| kojiweb
|-
| kojira
| kojira
| Admin
|-
| didier ( utilisateur koji admin )
| didier ( ici c'est le user et non le nom d'hôte de la machine )
| Admin
|-
| kojibuilder.didier-linux.eu
| kojibuilder.didier-linux.eu
| builder
|}

=== Copier les certificats dans le home de utilisateur admin ===

On copie le certificat correspondant à l'administrateur du {{class|Koji}}, et l'autorité de certification dans son home.

<syntaxhighlight lang="bash">
mkdir ~/.koji
cp /etc/pki/koji/didier.pem ~/.koji/client.crt
cp /etc/pki/koji/koji_ca_cert.crt ~/.koji/clientca.crt
cp /etc/pki/koji/koji_ca_cert.crt ~/.koji/serverca.crt
</syntaxhighlight>
{{Admon/note|Modification des paramètres par défaut|Pour modifier des paramètre d'un client sans modifier la configuration générale, il faut copier le fichier <path>/etc/koji.conf</path> dans le home de l'utilisateur <path>~/.koji/config</path> et y effectuer les modifications dans celui-ci.}}

==Mise en place des principals Kerberos==

Le serveur Kerberos doit pouvoir être trouvé grâce au DNS. Le point final indique que l'hôte est pleinement qualifié (FQDN).
<pre>_kerberos._udp IN SRV 10 100 88 kerberos.didier-linux.eu.</pre>

{| class="wikitable"
! Principal
! Utilisation
|-
| host/kojihub@DIDIER-LINUX.EU
| Utiliser par koji-hub pour communiquer avec le client koji
|-
| HTTP/kojiweb@DIDIER-LINUX.EU
| Utiliser par koji-web pour négotier une authentifiaction avec le navigateur web. C'est le principal pour l'authentification Apache <package>mod_auth_kerb</package>.
|-
| koji/kojiweb@DIDIER-LINUX.EU
| Utiliser par koji-web pour communiquer avec koji-hub. C'est le principal qui va authentifier koji-web sur Kerberos comme "koji/kojiweb@EXAMPLE.COM". Koji-web relayera aussi le nom d'utilisateur (authentification Apache) vers koji-hub (koji-hub config option '''''ProxyPrincipals''''').
|-
| koji/kojira@DIDIER-LINUX.EU
| Utiliser par kojira pour communiquer avec koji-hub
|-
| compile/builder1@DIDIER-LINUX.EU
| Utiliser par le constructeur koji pour communiquer avec koji-hub
|}

==Ajout des utilisateurs Koji aux alias du serveur de mail local==

Bien évidemment, un serveur [[Mail/MTA/Sendmail|sendmail]] en local est déjà configuré et opérationnel.

Appairer les utilisateurs Koji aux véritables adresses mail.
{{Admon/file|<path>/etc/aliases</path>|
<pre>
# Person who should get root's mail
root: didier@didier-linux.eu
didier: didier@didier-linux.eu
</pre>}}

Puis lancer la régénération des alias
# newaliases

== Serveur PostgreSQL ==
Une fois l'autentification mise en place, nous avons besoin d'installer un serveur [[DBMS/PostgreSQL/Brief|PostgreSQL]], de le configurer et de mettre en place la structure de la base de données pour {{class|Koji}}.
'''Fichiers de Configuration :'''

* /var/lib/pgsql/data/pg_hba.conf
* /var/lib/pgsql/data/postgresql.conf

===Installation du serveur PostgreSQL===
<pre>
yum install postgresql-server
</pre>

===Initialisation de la base de données PostgreSQL===

Les commandes suivantes initialise le serveur [[DBMS/PostgreSQL/Brief|PostgreSQL]] et le démarre.
Le script d'init a été converti à systemd sur les distributions Fedora 16 et supérieures et la cible '''initdb''' du script d'init a été supprimée. On initialise directement avec les commandes du SGBD.
<syntaxhighlight lang="bash">
su - postgres -c "PGDATA=/var/lib/pgsql/data initdb"
systemctl start postgresql.service
</syntaxhighlight>
{{admon/tip|Initialisation du SGBD sur les distributions sysVinit|<pre>service postgresql initdb && service postgresql start</pre>}}

=== Compte utilisateur ===

Mise en place du compte '''koji''' sur le système (utilisateur unix) et mise en place d'un mot de passe.
<syntaxhighlight lang="bash">
useradd koji
passwd koji
</syntaxhighlight>

=== Setup de PostgreSQL et import de la structure de la base ===

Création de l'utilisateur PostgreSQL '''koji''' et création de sa base de données, puis import de la structure.
{{Admon/bug|Import de la structure|Il est important laisser le joker (*) afin de ne pas se restreindre à une version particulière de Koji. Durant des test, il a été découvert que la restriction à une version spécifique de Koji ne créé pas correctement toutes les tables.}}
<syntaxhighlight lang="bash">
su - postgres
createuser koji
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
createdb -O koji koji
logout
</syntaxhighlight>
<syntaxhighlight lang="bash">
su - koji
psql koji koji < /usr/share/doc/koji*/docs/schema.sql
exit
</syntaxhighlight>

=== Autorisation de Koji-web et Koji-hub aux resources===
''Dans cet exemple, Koji-web et Koji-hub sont démarrés sur localhost.''

Ces paramètres doivent être ajouter avant les autres.
Fichier <path>/var/lib/pgsql/data/pg_hba.conf</path>
{{Admon/file|<path>/var/lib/pgsql/data/pg_hba.conf</path>|
<pre>
host koji koji 127.0.0.1/32 trust
host koji koji ::1/128 trust
</pre>}}
On peut aussi utiliser les sockets UNIX. La variable '''''DBHost''''' variable ne doit pas être renseigné avec cette méthode.
{{Admon/file|<path>/var/lib/pgsql/data/pg_hba.conf</path>|
<pre>
local koji apache trust
local koji apache 127.0.0.1/32 trust
local koji apache ::1/128 trust
local koji koji trust
</pre>}}

=== Application des changements à chaud ===

Informer postgreSQL que les fichiers de configuration doivent être relus.
<syntaxhighlight lang="bash">
root@localhost$ su - postgres
postgres@localhost$ pg_ctl reload
postgres@localhost$ exit
</syntaxhighlight>

=== Ajout du premier administrateur du Koji à la base PostgreSQL ===

Le premier administrateur du <class>Koji</class> doit être ajouter à la main avec des commandes SQL. Une fois ajouté avec les droits administarteur, Il pourra gérer les autres utilisateurs de <class>Koji</class> avec l'outil d'administration en ligne de commande.

Pour l'authentifiaction SSL ou Kerberos, il n'y a pas besoin de mettre un mot de passe.
<syntaxhighlight lang="bash">
root@localhost$ su - koji
koji@localhost$ psql
koji=> insert into users (name, status, usertype) values ('admin-user-name', 0, 0);
</syntaxhighlight>

=== Se donner les droits admin ===

Commande permettant de se donner les droits administrateur. Pour la lancer, on doit connaitre l'ID de l'utilisateur.
<pre>
koji=> insert into user_perms (user_id, perm_id, creator_id) values (<id of user inserted above>, 1, <id of user inserted above>);
</pre>
{{Admon/tip|Connaitre l'ID des utilisateurs|Pour connaitre les IDs des utilisateurs du <class>Koji</class>, on doit lancer une commande SQL.
<pre>
koji=> select * from users;
</pre>}}

A ce stade, aucune action ne peut être démarrée tant que le kojihub n'est pas configuré et le serveur web démarré.

== Koji Hub ==

koji-hub est le centre nerveux de toutes les opérations Koji. Il s'agit d'un serveur XML-RPC fonctionnant sous mod_python pour Apache. koji-hub est passif : il ne reçoit que les appels XML-RPC et s'appuie sur les autres outils de la suite pour la construction. koji-hub est le seul composant qui a un accès direct à la base de données et est l'un des deux composants qui ont un accès en écriture au système de fichiers.

'''Fichiers de Configuration'''

* /etc/httpd/conf/httpd.conf
* /etc/httpd/conf.d/kojihub.conf
* /etc/httpd/conf.d/ssl.conf (when using ssl auth)
* /etc/koji-hub/hub.conf
* /etc/koji.conf

Le répertoire de travail sera <path>/mnt/koji</path>.
{{Admon/bug|Répertoire de travail de Koji|Si le répertoire de travail de Koji n'est pas <path>/mnt/koji</path>, il est impératif de créer un lien symbolique du répertoire de travail de Koji dans <path>/mnt</path>:
<pre>ln -s /path/to/koji/datadir /mnt/koji</pre>}}

===Installation de {{class|koji-hub}}===
<pre>
yum install koji-hub httpd mod_ssl
</pre>

=== Configuration ===

On bride tout d'abord le nombre maximum de requête sur le serveur [[Webserver/Apache|apache]] à une valeur plus raisonnable afin de prévenir une saturation et/ou un crash du serveur web.
{{Admon/file|<path>/etc/httpd/conf/httpd.conf</path>|
<syntaxhighlight lang="apache">
<IfModule prefork.c>
...
MaxRequestsPerChild 100
</IfModule>
<IfModule worker.c>
...
MaxRequestsPerChild 100
</IfModule>
</syntaxhighlight>}}

Le répertoire <path>/mnt/koji/packages</path> doit être accessible par HTTP. On ajoute donc un alias.

{{Admon/file|<path>/etc/httpd/conf.d/kojipackages.conf</path>|
<syntaxhighlight lang="apache">
Alias /packages "/mnt/koji/packages"
<Directory "/mnt/koji/packages">
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</syntaxhighlight>}}

{{Admon/file|<path>/etc/httpd/conf.d/ssl.conf</path>|
<syntaxhighlight lang="apache">
LoadModule ssl_module modules/mod_ssl.so

Listen 443

SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300

SSLMutex default

SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin

SSLCryptoDevice builtin

<VirtualHost _default_:443>
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite RC4-SHA:AES128-SHA:ALL:!ADH:!EXP:!LOW:!MD5:!SSLV2:!NULL

SSLCertificateFile /etc/pki/koji/certs/kojihub.crt
SSLCertificateKeyFile /etc/pki/koji/certs/kojihub.key
SSLCertificateChainFile /etc/pki/koji/koji_ca_cert.crt
SSLCACertificateFile /etc/pki/koji/koji_ca_cert.crt
SSLVerifyClient require
SSLVerifyDepth 10

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
</syntaxhighlight>}}

{{Admon/file|<path>/etc/httpd/conf.d/kojihub.conf</path>|
<syntaxhighlight lang="apache">
Alias /kojihub /usr/share/koji-hub/kojixmlrpc.py

<Directory "/usr/share/koji-hub">
Options ExecCGI
SetHandler wsgi-script
Order allow,deny
Allow from all
</Directory>

Alias /kojifiles "/mnt/koji/"

<Directory "/mnt/koji">
Options Indexes SymLinksIfOwnerMatch
AllowOverride None
Order allow,deny
Allow from all
</Directory>

<Location /kojihub/ssllogin>
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +StdEnvVars
</Location>

<Location /kojihub>
SSLOptions +StdEnvVars
</Location>
</syntaxhighlight>}}

{{Admon/file|<path>/etc/koji-hub/hub.conf</path>|
<syntaxhighlight lang="ini">
[hub]
DBName = koji
DBUser = koji
DBHost = localhost
KojiDir = /mnt/koji

DNUsernameComponent = CN
ProxyDNs = /C=FR/ST=Languedoc Roussillon/O=Home/OU=kojiweb/CN=koji.didier-linux.eu/emailAddress=root@didier-linux.eu|/C=FR/ST=Languedoc Roussillon/O=Home/OU=Admin/CN=didier/emailAddress=didier@didier-linux.eu

LoginCreatesUser = On
KojiWebURL = http://koji.didier-linux.eu/koji
EmailDomain = didier-linux.eu
NotifyOnSuccess = True
</syntaxhighlight>}}

{{Admon/file|<path>/etc/koji.conf</path>|
<syntaxhighlight lang="ini">
[koji]
server = http://koji.didier-linux.eu/kojihub
weburl = http://koji.didier-linux.eu/koji
topurl = http://koji.didier-linux.eu/kojifiles
topdir = /mnt/koji
cert = ~/.koji/client.crt
ca = ~/.koji/clientca.crt
serverca = ~/.koji/serverca.crt
</syntaxhighlight>}}

=== Configuration de [[Security/SELinux|SELinux]] ===
Si le mode enforcing est utilisé, on doit autoriser [[Webserver/Apache|apache]] à acceder au serveur [[SGBD/PostgreSQL]]. Même si le mode est permissive, il est recommandé de lancer la commande suivante afin de se prémunir d'un changement de mode de [[Security/SELinux|SELinux]].

<pre>
setsebool -P httpd_can_network_connect_db 1
</pre>

=== Squelette des fichiers Koji ===

Avant que les autres composants de Koji puissent fonctionner correctement, On doit créer la structure et modifié les droits de celui-ci.

<syntaxhighlight lang="bash">
cd /mnt
mkdir koji
cd koji
mkdir {packages,repos,work,scratch}
chown apache.apache *
</syntaxhighlight>

Ici, [[Webserver/Apache|apache]] peut être redémarré et on peut effectuer des opérations minimales sur notre serveur Koji via le client en ligne de commande: gestion des utilisateurs et des constructeurs.

Il faut s'assurer que le client est configuré par défaut ( fichier <path>/etc/koji.conf</path> et que les certificats sont en place dans le home de l'administrateur.

{{Admon/note|Fichier de configuration alternatif|Si un fichier de configuration personnel autre que <path>~/.koji/config</path> est utilisé, il faut utilisé la commande koji avec l'option '''-c'''.}}
La commande suivante teste le login administrateur sur le serveur Koji.
koji call getLoggedInUser

{{Admon/important|Droit des daemons|Kojira a besoin du privilège '''repo''' avant le lancement du daemon. C'est pourquoi il est vivement recommandé de créer cet utilisateur maintenant et de lui ajouter le privilège

<pre>
koji add-user kojira
koji grant-permission repo kojira
</pre>

Pour des raisons similaires, les hôtes de constructions doivent être ajoutés avant le démarrage du daemon kojid.

<pre>
koji add-host kojibuilder1 x86_64 i386
koji add-host kojibuilder2 ppc ppc64
koji add-host kojibuilder3 ia64
</pre>}}

== Koji Web - Interface for the Masses ==

Koji-web est un jeu de scripts qui tournent avec mod_wsgi et qui utilise le moteur de modèle Cheetah pour fournir une interface web à Koji. Koji-web affiche beaucoup d'informations et propose même quelques opérations comme l'abandon de tâche.

'''Fichiers de Configuration:'''
* /etc/kojiweb/web.conf
* /etc/httpd/conf.d/kojiweb.conf
* /etc/httpd/conf.d/ssl.conf

'''Installation de Koji-Web:'''
<pre>
yum install koji-web mod_ssl
</pre>

==== Configuration obligatoire ====

La configuration doit fournir à Koji-web les URLs d'accès à Koji-hub, aux paquets koji (builds) et à sa propre interface. Il est judicieux de modifier aussi le secret (directive ''PythonOption Secret''.

Avec l'authentification SSL, elle doit aussi fournir le nom des certificats à utiliser et la directive ''PythonOption WebCert'' doit contenir '''la clé publique ET la clé privée'''.
{{Admon/file|<path>/etc/kojiweb/web.conf</path>|
<pre>
[web]
SiteName = koji
KojiTheme = didier

KojiHubURL http://koji.didier-linux.eu/kojihub
KojiFilesURL http://www.didier-linux.eu/kojifiles

WebCert /etc/pki/koji/kojiweb.pem
ClientCA /etc/pki/koji/koji_ca_cert.crt
KojiHubCA /etc/pki/koji/koji_ca_cert.crt

LoginTimeout 72
Secret CHANGE_ME

LibPath = /usr/share/koji-web/lib
</pre>}}

==== Configuration Optionnelle ====

Il faut éditer le fichier <path>/etc/httpd/conf.d/kojiweb.conf</path> pour configurer l'authentification choisie.

{{Admon/file|<path>/etc/httpd/conf.d/kojiweb.conf</path>|
<pre>
<Location /koji/login>
SSLOptions +StdEnvVars
</Location>
</pre>}}

{{Admon/file|<path>/etc/httpd/conf.d/ssl.conf</path>|
<pre>
SSLVerifyClient require
SSLVerifyDepth 10
</pre>}}

==== Interface Web opérationnelle ====

L'interface Web du koji est maintenant accessible et la plupart des opérations de lecture doivent fonctionner et chaque utilisateur doit pouvoir se connecter.

== Koji Daemon - Builder ==

Kojid est le daemon de construction qui tourne sur chaque constructeur. son rôle principale est de traiter les requêtes de construction. Koji ne se limite cependant pas aux tâches de construction puisqu'il peut aussi construire des images ISO, des disques virtuels (appliances). Kojid utilise mock pour créer des environnements de construction minimaliste et en créé pour chaque construction. Ceci permet le compartimentage des constructions et les constructions ne peuvent pas se gêner les unes les autres. Kojid est écrit en python et communique avec le hub via XML-RPC.

'''fichiers de Configuration'''
* Configuration du daemon Kojira: /etc/kojid/kojid.conf
* Variables de lancement du daemon: /etc/sysconfig/kojid

'''Installation de kojid:'''
<pre>
yum install koji-builder
</pre>

==== Configuration générale ====

Le fichier de configuration de chaque constructeur doit être édité afin que la directive ''server'' pointe sur l'hôte supportant le Koji-hub. La directive ''user'' doit contenir le nom d'hôte du constructeur.
{{Admon/file|<path>/etc/kojid/kojid.conf</path>|
<pre>
; The URL for the xmlrpc server
server=http://hub.example.com/kojihub

; the username has to be the same as what you used with add-host
; in this example follow as below
user = kojibuilder1.example.com
</pre>}}

La directive ''workdir'' peut être différente entre les constructeurs mais elle ne doit pas être le répertoire de travail du Koji (<path>/mnt/koji</path>)
{{Admon/file|<path>/etc/kojid/kojid.conf</path>|
<pre>
; The directory root for temporary storage
workdir=/tmp/koji
</pre>}}

==== Configuration des certificats SSL ====

Ces entrées doivent être éditées pour pointer sur les bons certificats générés précédemment.
{{Admon/file|<path>/etc/kojid/kojid.conf</path>|
<pre>
;client certificate
; This should reference the builder certificate we created above, for
; kojibuilder1.example.com
cert = /etc/kojid/kojid.pem

;certificate of the CA that issued the client certificate
ca = /etc/kojid/koji_ca_cert.crt

;certificate of the CA that issued the HTTP server certificate
serverca = /etc/kojid/koji_ca_cert.crt
</pre>}}
{{Admon/important|Copie des certificats sur l'hôte|Les certificats SSL doivent être copiés depuis l'hôte abritant le Koji-hub sur les constructeurs dans le répertoire <path>/etc/kojid</path> pour que les constructeurs puissent s'authentifier.}}

==== Ajout d'un hôte à la base de données des constructeurs ====

Il faut maintenant ajouter l'hôte à la base de données des constructeurs afin qu'il puisse être utilisé par Koji-hub.
{{Admon/important|L'ajout doit être fait avant le premier démarrage du daemon de construction|Sinon, il faudra purger les entrées à la main dans les tables ''sessions'' et ''users
'' avant de pouvoir démarrer avec succès le daemon.}}
<pre>
koji add-host kojibuilder1.didier-linux.eu i386 x86_64
</pre>
Le premier argument après la commande est le nom d'hôte du constructeur. Le second argument spécifie l'(les) architecture(s) utilisées par l'hôtes.

==== Ajout de l'hôte au canal de création ====

Les canaux sont un moyen de contrôler quel constructeur fait quoi. Par défaut les hôtes sont ajouté au canal ''default''. Il faut qu'au moins quelques uns (1 au minimum) soient ajoutés au canal ''createrepo'' pour pouvoir lancer les travaux kojira sur les dépôts.
<pre>
koji add-host-to-channel kojibuilder1.didier.eu createrepo
</pre>

==== Capacité ====

La capacité d'un hôte par défaut est de 2, ce qui veut dire que le daemond econstruction n'acceptera pas de travail supplémentaire si le load average est supérieur à 2. Ce paramètre est différent de celui du nombre maximal de travaux (fichier de configuration). Avant que ledaemon de construction n'accepte un nouveau travail, il s'assure que le load average est inférieur à la capacité et que le nombre de travaux est inférieur au nombre maximal. Toutefois, à l'ère des CPU multi-coeurs, un load average de 2 est insuffisant pour consommer 100% des ressources du système. Il n'y a pas d'option pour définir la capacité en ligne de commande, cela doit être fait en base (psql).

<pre>
koji@localhost$ psql koji
koji=# select (id, name, capacity) from host;
row
--------------------------------
(1,kojibuilder1.didier-linux.eu,2)
(2,kojibuilder2.didier-linux.eu,2)
(2 rows)

koji=# update host set capacity = 16 where id = 1;
UPDATE 1
koji=#
</pre>

==== Démarrage du daemon Kojid ====

Une fois le constructeur ajouté à la base de données, on peut démarrer son daemon de construction.
<pre>
systemctl start kojid
</pre>
On vérifie dans le fichier <path>/var/log/kojid.log</path> qur le daemon a bien démarré. Si aucune erreur n'est rapportée, c'est que le daemon doit être correctement configuré et démarré. On peut le vérifier sur l'interface Koji-web dans l'onglet ''hôtes''. Cette page affiche le liste des constructeurs et leur status.

== Kojira - Création et maintenance du dépôt ==
'''Fichiers de Configuration:'''
* Configuration du daemon Kojira: <path>/etc/kojira/kojira.conf</path>
* Variables de lancement du daemon: <path>/etc/sysconfig/kojira</path>

'''Installation de kojira'''
yum install koji-utils

==== Configuration générale ====
La directive ''server'' a besoin de pointer sur le koji-hub.
{{Admon/file|<path>/etc/kojira/kojira.conf</path>|
<pre>
; The URL for the xmlrpc server
server=http://koji.didier-linux.eu/kojihub
</pre>}}
{{Admon/important|Note importante|
* Kojira a besoin d'un accès en lecture/écriture sur <path>/mnt/koji</path>.
* Il ne devrait exister qu'une seule instance de {{class|kojira}} à la fois.
* Il n'est pas recommandé de lancer kojira sur les constructeurs, car ceux-ci n'ont besoin que d'un accès en lecture seule sur le répertoire <path>/mnt/koji</path>.}}

==== Configuration de l'authentification SSL ====

{{Admon/file|<path>/etc/kojira/kojira.conf</path>|
<pre>
;client certificate
; This should reference the kojira certificate we created above
cert = /etc/pki/koji/kojira.pem

;certificate of the CA that issued the client certificate
ca = /etc/pki/koji/koji_ca_cert.crt

;certificate of the CA that issued the HTTP server certificate
serverca = /etc/pki/koji/koji_ca_cert.crt
</pre>}}

''The local user kojira runs as needs to be able to read and write to /mnt/koji/repos/.
If the volume that directory resides on is root-squashed or otherwise unmodifiable
by root, you can set '''RUNAS=''' to a user that has the required privileges.''

{{Admon/file|<path>/etc/sysconfig/kojira</path>|
<pre>
FORCE_LOCK=Y
KOJIRA_DEBUG=N
KOJIRA_VERBOSE=Y
RUNAS=root
</pre>}}

==== Ajout de l'utilisateur kojira à Koji ====
Si cela n'a pas été déjà fait, création de l'utilisateur kojira et ajout du droit '''repo''' à celui-ci. Cela doit être fait avec le compte de l'administrateur de Koji.
<pre>
koji add-user kojira
koji grant-permission repo kojira
</pre>

=== Démarrage du deamon Kojira ===
<pre>
systemctl start kojira.service
</pre>
On vérifie dans le fichier <path>/var/log/kojira/kojira.log</path> que {{class|kojira}} a bien démarré.

== SELinux ==
<pre>
semanage fcontext -a -t httpd_sys_rw_content_t '/mnt/koji(/.*)?'
restorecon -Rv /mnt/koji
</pre>

==Notes==
<references />

[[Catégorie:RPM|Install Koji]]
[[Catégorie:Koji|Install]]
[[Catégorie:Server|Install Koji]]

Koji/SigulUsing

2015-04-22T07:48:04Z

Didier : /* FAQ */

== Sigul ==

après une [[Koji/SigulInstall|installation de Sigul]], on peut l'utiliser.
{{Admon/note|Commandes disponible|<pre>$ sigul --help-commands
delete-key Delete a key
modify-key-user Modify user's key access
list-users List users
grant-key-access Grant key access to a user
sign-text Output a cleartext signature of a text
import-key Import a key
new-user Add a user
sign-rpm Sign a RPM
list-keys List keys
sign-data Create a detached signature
revoke-key-access Revoke key acess from a user
user-info Show information about a user
change-passphrase Change key passphrase
list-key-users List users that can access a key
new-key Add a key
modify-user Modify a user
sign-rpms Sign one or more RPMs
modify-key Modify a key
delete-user Delete a user
key-user-info Show information about user's key access
get-public-key Output public part of the key
</pre>
}}

=== Créer une nouvelle clé ===

Une fois le client Sigul capable d'envoyer des commandes à <class>Sigul</class>, on peut créer une nouvelle clé nommée '''centos-5-key'''.
sigul new-key --name-real='CentOS-5-B2PWeb' --name-comment='CentOS 5 B2PWeb Signing Key' --name-email='srs@b2pweb.com' --key-admin root centos-5-key
{{Admon/note|Générer beaucoup d'entropie durant le génération de la clé|La génération de la clé nécessite beaucoup d'entropie sur le serveur Sigul. On peut donc occuper le serveur et paradoxalement accélerer la génération de la clé.

La commande suivant génère assez d'entropie pour 2 minutes:
<pre>find / > /dev/null 2>&1</pre>}}<pre>
$ sigul new-key --help
usage: client.py new-key [options] key

Add a key

options:
-h, --help show this help message and exit
--key-admin=USER Initial key administrator
--name-real=NAME_REAL
Real name of key subject
--name-comment=NAME_COMMENT
A comment about of key subject
--name-email=NAME_EMAIL
E-mail of key subject
--expire-date=YYYY-MM-DD
Key expiration date
</pre>

=== Import d'une clé existante ===
sigul import-key 'CentOS-5-B2PWeb' ~/.gnupg/secring.gpg

=== Changer le nom de la clé ===
Changer le nom de la clé '''centos5''' en '''centos-5-key'''<pre>sigul modify-key --new-name centos-5-key centos5</pre>

=== Ajout d'un utilisateur ===

* Ajout d'un utilisateur administrateur<pre>sigul new-user --admin --with-password didier</pre>

=== Autoriser l'utilisation d'une clé existante à un utilisateur ===
<pre>sigul grant-key-access centos-5-key didier</pre>
<pre>
sigul grant-key-access --help
usage: client.py grant-key-access key user

Grant key access to a user

options:
-h, --help show this help message and exit
</pre>

=== Modifier la phrase de passe ===
sigul change-passphrase centos-5-key
<pre>
sigul change-passphrase --help
usage: client.py change-passphrase key

Change key passphrase

options:
-h, --help show this help message and exit
</pre>

=== FAQ ===

{{Admon/faq|ERROR: I/O error: Unexpected EOF in NSPR|
* S'assurer que le répertoire des clés existe. Ce chemin est déclaré dans le fichier <path>/etc/sigul/server.conf</path><pre>gnupg-home: /var/lib/sigul/server/gnupg</pre>
** Propriétaire: '''sigul'''
** Groupe: '''sigul'''
** Droits: 0700 '''rwx------'''
** Lien symbolique '''/var/lib/sigul/gnupg''' pointant sur <path>/var/lib/sigul/server/gnupg</path>
* S'assurer qu'il y a suffisamment d'espace disque ( en gros deux fois la taille du plus gros paquet RPM )
* S'assurer que les daemons sigul_bridge et sigul_server sont démarrés<pre>service sigul_server status && service sigul_bridge status</pre>
* S'assurer que le pont peut se connecter au serveur ( [[Koji/SigulInstall#Firewall| Configure firewall]] )}}

{{Admon/faq|Unknown error on creating key process|
* Installer le paquet <package>gnupg1</package> depuis [ http://people.redhat.com/mitr/rpmsigner/rhel6 ] ou de [ http://infrastructure.stg.fedoraproject.org/repo/builder-rpms/6Server/SRPMS/ ]
* S'assurer que Sigul est configurer pour utiliser <package>gnupg1</package><pre>sed -i -e '/gnupg_bin/s,^.*$,gnupg_bin = "/usr/bin/gpg1",' /usr/share/sigul/settings.py</pre>
* S'assurer que le paquet <package>python-sqlalchemy</package> soit installé}}

{{Admon/faq|Certificats client expirés|
Une fois le certificat client expiré, il faut le désactiver localement<pre>certutil -d ~/.sigul -D -n sigul-client-cert</pre> et refaire une génération de certificat client.}}

== Interfacer Sigul et koji ==

=== configuration ===

<class>Sigul</class> peut être utiliser pour signer un ou de multiples RPMs dans une instance <class>Koji</class>. Une fois le client Sigul correctement configuré, il suffit juste de configurer l'utilisateur Proxy pour Koji. Quand un client <class>Sigul</class> émet une requête de signature pour <class>Koji</class>, le pont <class>Sigul</class> se connecte à <class>Koji</class> en tant qu'utilisateur '''kojiweb'''. Il faut juste s'assurer que l'utilisateur demandeur a les droits administrateur sur le <class>Koji</class> et <class>Sigul</class> s'occupe du reste.

La configuration pour <class>Koji</class> peut être situer n'importe où, du moment que l'utilisateur sigul a droit de lecture. Les certificats pour '''kojiweb''' doivent être copiés dans le même chemin que la configuration <class>Koji</class>

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash">su - sigul</syntaxhighlight>
* Création du répertoire de configuration de <class>Koji</class><syntaxhighlight lang="bash">mkdir -p ~/.koji</syntaxhighlight>
* Copie de la configuration par défaut du client <class>Koji</class><syntaxhighlight lang="bash">cp /etc/koji.conf ~/.koji/config</syntaxhighlight>
* Copie des certificats {{class|Kojiweb}} dans celui-ci<syntaxhighlight lang="bash">cp /etc/pki/koji/pem/kojiweb.pem .koji/client.pem</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/clientca.crt</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/serverca.crt</syntaxhighlight>

Après avoir redémarrer le pont <class>Sigul</class>, le client doit être capable d'obtenir un RPM depuis Koji et de le signer.

=== Test ===

Pour tester l'interfaçage, on va obtenir un RPM depuis <class>Koji</class>, le signer et le sauvegarder dans le répertoire de travail actuel. c'est juste pour tester la connxion et l'authentification sur <class>Koji</class> et <class>Sigul</class>.
<syntaxhighlight lang="bash">sigul sign-rpm -o signed.rpm key_name unsigned.rpm</syntaxhighlight>

Si la commande précédente fonctionne, un RPM signé est présent dans le répertoire de travail actuel.

On vérifie sa signature
<syntaxhighlight lang="bash">rpm --checksig signed.rpm</syntaxhighlight>

== Script sigulsign_unsigned.py ==

Le script est à récupérer depuis un depôt releng de Fedora via git (git://git.fedorahosted.org/git/releng) ou directement depuis https://git.fedorahosted.org/cgit/releng/tree/scripts/sigulsign_unsigned.py

Avant de pouvoir utiliser ce script magique qui va signer tous les RPM non-signés (derniers m-v-r) construit dans le Koji, il est nécessaire de modifier quelques variables:
* Changer l'URL du HUB Koji (2 fois): KOJIHUB
* Spécifier nos propres fichiers de certificats: SERVERCA, CLIENTCA, CLIENTCERT
* Ajout de nos clés de signature: KEYS
{{Admon/warning|Casse de l'ID dans le script sigulsign_unsigned.py|GPG rapporte un ID écrit en majuscule mais dans le script, celui-ci doit être renseigné en minuscule pour que le processus fonctionne.}}

Pour obtenir l'ID de nos clés:
* exporter de la clé<pre>sigul get-public-key centos-5-key > centos-5-key.asc</pre>
* importer dans GPG<pre>gpg --import centos-5-key.asc</pre>
* Lister nos clé GPG<pre>gpg --list-keys</pre>
<pre>
/root/.gnupg/pubring.gpg
------------------------
pub 1024D/773DF357 2013-08-20
uid CentOS-5-B2PWeb (CentOS 5 B2PWeb Signing Key) <srs@b2pweb.com>
sub 2048g/EBC96FF2 2013-08-20
</pre>
L'ID de notre clé '''centos-5-key''' est 773DF357
<syntaxhighlight lang="diff">
Change koji hostname, certificate files and add B2PWeb signing keys
diff -u a/sigulsign_unsigned.py b/sigulsign_unsigned.py
--- a/sigulsign_unsigned.py 2013-08-21 10:05:57.418032284 +0200
+++ b/sigulsign_unsigned.py 2013-08-21 10:13:11.683976970 +0200
@@ -38,11 +38,11 @@ rpmdict = {}
unsigned = []
loglevel = ''
passphrase = ''
-KOJIHUB = 'https://koji.fedoraproject.org/kojihub'
+KOJIHUB = 'http://koji.b2pweb.com/kojihub'
# Should probably set these from a koji config file
-SERVERCA = os.path.expanduser('~/.fedora-server-ca.cert')
-CLIENTCA = os.path.expanduser('~/.fedora-upload-ca.cert')
-CLIENTCERT = os.path.expanduser('~/.fedora.cert')
+SERVERCA = os.path.expanduser('~/.koji/serverca.crt')
+CLIENTCA = os.path.expanduser('~/.koji/clientca.crt')
+CLIENTCERT = os.path.expanduser('~/.koji/client.pem')
# Setup a dict of our key names as sigul knows them to the actual key ID
# that koji would use. We should get this from sigul somehow.
KEYS = {'fedora-12-sparc': {'id': 'b3eb779b', 'v3': True},
@@ -67,7 +67,9 @@ KEYS = {'fedora-12-sparc': {'id': 'b3eb7
'fedora-10': {'id': '4ebfc273', 'v3': False},
'fedora-10-testing': {'id': '0b86274e', 'v3': False},
'epel-6': {'id': '0608b895', 'v3': True},
- 'epel-5': {'id': '217521f6', 'v3': False}}
+ 'epel-5': {'id': '217521f6', 'v3': False},
+ 'centos-5-key' : {'id': '773df357', 'v3': True},
+ 'centos-6-key' : {'id': 'd3f3c56a', 'v3': True}}

def exit(status):
"""End the program using status, report any errors"""
@@ -213,7 +215,7 @@ if not (opts.just_list or opts.just_writ

# Reset the KOJIHUB if the target is a secondary arch
if opts.arch:
- KOJIHUB = 'http://%s.koji.fedoraproject.org/kojihub' % opts.arch
+ KOJIHUB = 'http://%s.koji.b2pweb.com/kojihub' % opts.arch
# setup the koji session
logging.info('Setting up koji session')
kojisession = koji.ClientSession(KOJIHUB)
</syntaxhighlight>

=== Signature d'un ou plusieurs paquets ===

C'est utile afin de signer des paquets qui ne sont pas les derniers construits (dernier N-V-R)
<syntaxhighlight lang="bash">
sigulsign_unsigned.py -v --password="motdepasse" --inherit centos-6-key <N-V-R>
</syntaxhighlight>

exemple:

<syntaxhighlight lang="bash">
sigulsign_unsigned.py -v --password="$(cat /root/.sigul/centos-6-key)" --inherit centos-6-key appliance-tools-007.0-1.el6
</syntaxhighlight>

Koji/SigulUsing

2015-04-22T07:42:20Z

Didier : /* Script sigulsign_unsigned.py */

== Sigul ==

après une [[Koji/SigulInstall|installation de Sigul]], on peut l'utiliser.
{{Admon/note|Commandes disponible|<pre>$ sigul --help-commands
delete-key Delete a key
modify-key-user Modify user's key access
list-users List users
grant-key-access Grant key access to a user
sign-text Output a cleartext signature of a text
import-key Import a key
new-user Add a user
sign-rpm Sign a RPM
list-keys List keys
sign-data Create a detached signature
revoke-key-access Revoke key acess from a user
user-info Show information about a user
change-passphrase Change key passphrase
list-key-users List users that can access a key
new-key Add a key
modify-user Modify a user
sign-rpms Sign one or more RPMs
modify-key Modify a key
delete-user Delete a user
key-user-info Show information about user's key access
get-public-key Output public part of the key
</pre>
}}

=== Créer une nouvelle clé ===

Une fois le client Sigul capable d'envoyer des commandes à <class>Sigul</class>, on peut créer une nouvelle clé nommée '''centos-5-key'''.
sigul new-key --name-real='CentOS-5-B2PWeb' --name-comment='CentOS 5 B2PWeb Signing Key' --name-email='srs@b2pweb.com' --key-admin root centos-5-key
{{Admon/note|Générer beaucoup d'entropie durant le génération de la clé|La génération de la clé nécessite beaucoup d'entropie sur le serveur Sigul. On peut donc occuper le serveur et paradoxalement accélerer la génération de la clé.

La commande suivant génère assez d'entropie pour 2 minutes:
<pre>find / > /dev/null 2>&1</pre>}}<pre>
$ sigul new-key --help
usage: client.py new-key [options] key

Add a key

options:
-h, --help show this help message and exit
--key-admin=USER Initial key administrator
--name-real=NAME_REAL
Real name of key subject
--name-comment=NAME_COMMENT
A comment about of key subject
--name-email=NAME_EMAIL
E-mail of key subject
--expire-date=YYYY-MM-DD
Key expiration date
</pre>

=== Import d'une clé existante ===
sigul import-key 'CentOS-5-B2PWeb' ~/.gnupg/secring.gpg

=== Changer le nom de la clé ===
Changer le nom de la clé '''centos5''' en '''centos-5-key'''<pre>sigul modify-key --new-name centos-5-key centos5</pre>

=== Ajout d'un utilisateur ===

* Ajout d'un utilisateur administrateur<pre>sigul new-user --admin --with-password didier</pre>

=== Autoriser l'utilisation d'une clé existante à un utilisateur ===
<pre>sigul grant-key-access centos-5-key didier</pre>
<pre>
sigul grant-key-access --help
usage: client.py grant-key-access key user

Grant key access to a user

options:
-h, --help show this help message and exit
</pre>

=== Modifier la phrase de passe ===
sigul change-passphrase centos-5-key
<pre>
sigul change-passphrase --help
usage: client.py change-passphrase key

Change key passphrase

options:
-h, --help show this help message and exit
</pre>

=== FAQ ===

{{Admon/faq|ERROR: I/O error: Unexpected EOF in NSPR|
* S'assurer que le répertoire des clés existe et a les bons propriétaires et droits ( owner et group: '''sigul''' ) Ce chemin est déclaré dans le fichier <path>/etc/sigul/server.conf</path><pre>gnupg-home: /var/lib/sigul/server/gnupg</pre>
* S'assurer qu'il y a suffisamment d'espace disque ( en gros deux fois la taille du plus gros paquet RPM )
* S'assurer que les daemons sigul_bridge et sigul_server sont démarrés<pre>service sigul_server status && service sigul_bridge status</pre>
* S'assurer que le pont peut se connecter au serveur ( [[Koji/SigulInstall#Firewall| Configure firewall]] )}}

{{Admon/faq|Unknown error on creating key process|
* Installer le paquet <package>gnupg1</package> depuis [ http://people.redhat.com/mitr/rpmsigner/rhel6 ] ou de [ http://infrastructure.stg.fedoraproject.org/repo/builder-rpms/6Server/SRPMS/ ]
* S'assurer que Sigul est configurer pour utiliser <package>gnupg1</package><pre>sed -i -e '/gnupg_bin/s,^.*$,gnupg_bin = "/usr/bin/gpg1",' /usr/share/sigul/settings.py</pre>
* S'assurer que le paquet <package>python-sqlalchemy</package> soit installé}}

{{Admon/faq|Certificats client expirés|
Une fois le certificat client expiré, il faut le désactiver localement<pre>certutil -d ~/.sigul -D -n sigul-client-cert</pre> et refaire une génération de certificat client.}}

== Interfacer Sigul et koji ==

=== configuration ===

<class>Sigul</class> peut être utiliser pour signer un ou de multiples RPMs dans une instance <class>Koji</class>. Une fois le client Sigul correctement configuré, il suffit juste de configurer l'utilisateur Proxy pour Koji. Quand un client <class>Sigul</class> émet une requête de signature pour <class>Koji</class>, le pont <class>Sigul</class> se connecte à <class>Koji</class> en tant qu'utilisateur '''kojiweb'''. Il faut juste s'assurer que l'utilisateur demandeur a les droits administrateur sur le <class>Koji</class> et <class>Sigul</class> s'occupe du reste.

La configuration pour <class>Koji</class> peut être situer n'importe où, du moment que l'utilisateur sigul a droit de lecture. Les certificats pour '''kojiweb''' doivent être copiés dans le même chemin que la configuration <class>Koji</class>

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash">su - sigul</syntaxhighlight>
* Création du répertoire de configuration de <class>Koji</class><syntaxhighlight lang="bash">mkdir -p ~/.koji</syntaxhighlight>
* Copie de la configuration par défaut du client <class>Koji</class><syntaxhighlight lang="bash">cp /etc/koji.conf ~/.koji/config</syntaxhighlight>
* Copie des certificats {{class|Kojiweb}} dans celui-ci<syntaxhighlight lang="bash">cp /etc/pki/koji/pem/kojiweb.pem .koji/client.pem</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/clientca.crt</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/serverca.crt</syntaxhighlight>

Après avoir redémarrer le pont <class>Sigul</class>, le client doit être capable d'obtenir un RPM depuis Koji et de le signer.

=== Test ===

Pour tester l'interfaçage, on va obtenir un RPM depuis <class>Koji</class>, le signer et le sauvegarder dans le répertoire de travail actuel. c'est juste pour tester la connxion et l'authentification sur <class>Koji</class> et <class>Sigul</class>.
<syntaxhighlight lang="bash">sigul sign-rpm -o signed.rpm key_name unsigned.rpm</syntaxhighlight>

Si la commande précédente fonctionne, un RPM signé est présent dans le répertoire de travail actuel.

On vérifie sa signature
<syntaxhighlight lang="bash">rpm --checksig signed.rpm</syntaxhighlight>

== Script sigulsign_unsigned.py ==

Le script est à récupérer depuis un depôt releng de Fedora via git (git://git.fedorahosted.org/git/releng) ou directement depuis https://git.fedorahosted.org/cgit/releng/tree/scripts/sigulsign_unsigned.py

Avant de pouvoir utiliser ce script magique qui va signer tous les RPM non-signés (derniers m-v-r) construit dans le Koji, il est nécessaire de modifier quelques variables:
* Changer l'URL du HUB Koji (2 fois): KOJIHUB
* Spécifier nos propres fichiers de certificats: SERVERCA, CLIENTCA, CLIENTCERT
* Ajout de nos clés de signature: KEYS
{{Admon/warning|Casse de l'ID dans le script sigulsign_unsigned.py|GPG rapporte un ID écrit en majuscule mais dans le script, celui-ci doit être renseigné en minuscule pour que le processus fonctionne.}}

Pour obtenir l'ID de nos clés:
* exporter de la clé<pre>sigul get-public-key centos-5-key > centos-5-key.asc</pre>
* importer dans GPG<pre>gpg --import centos-5-key.asc</pre>
* Lister nos clé GPG<pre>gpg --list-keys</pre>
<pre>
/root/.gnupg/pubring.gpg
------------------------
pub 1024D/773DF357 2013-08-20
uid CentOS-5-B2PWeb (CentOS 5 B2PWeb Signing Key) <srs@b2pweb.com>
sub 2048g/EBC96FF2 2013-08-20
</pre>
L'ID de notre clé '''centos-5-key''' est 773DF357
<syntaxhighlight lang="diff">
Change koji hostname, certificate files and add B2PWeb signing keys
diff -u a/sigulsign_unsigned.py b/sigulsign_unsigned.py
--- a/sigulsign_unsigned.py 2013-08-21 10:05:57.418032284 +0200
+++ b/sigulsign_unsigned.py 2013-08-21 10:13:11.683976970 +0200
@@ -38,11 +38,11 @@ rpmdict = {}
unsigned = []
loglevel = ''
passphrase = ''
-KOJIHUB = 'https://koji.fedoraproject.org/kojihub'
+KOJIHUB = 'http://koji.b2pweb.com/kojihub'
# Should probably set these from a koji config file
-SERVERCA = os.path.expanduser('~/.fedora-server-ca.cert')
-CLIENTCA = os.path.expanduser('~/.fedora-upload-ca.cert')
-CLIENTCERT = os.path.expanduser('~/.fedora.cert')
+SERVERCA = os.path.expanduser('~/.koji/serverca.crt')
+CLIENTCA = os.path.expanduser('~/.koji/clientca.crt')
+CLIENTCERT = os.path.expanduser('~/.koji/client.pem')
# Setup a dict of our key names as sigul knows them to the actual key ID
# that koji would use. We should get this from sigul somehow.
KEYS = {'fedora-12-sparc': {'id': 'b3eb779b', 'v3': True},
@@ -67,7 +67,9 @@ KEYS = {'fedora-12-sparc': {'id': 'b3eb7
'fedora-10': {'id': '4ebfc273', 'v3': False},
'fedora-10-testing': {'id': '0b86274e', 'v3': False},
'epel-6': {'id': '0608b895', 'v3': True},
- 'epel-5': {'id': '217521f6', 'v3': False}}
+ 'epel-5': {'id': '217521f6', 'v3': False},
+ 'centos-5-key' : {'id': '773df357', 'v3': True},
+ 'centos-6-key' : {'id': 'd3f3c56a', 'v3': True}}

def exit(status):
"""End the program using status, report any errors"""
@@ -213,7 +215,7 @@ if not (opts.just_list or opts.just_writ

# Reset the KOJIHUB if the target is a secondary arch
if opts.arch:
- KOJIHUB = 'http://%s.koji.fedoraproject.org/kojihub' % opts.arch
+ KOJIHUB = 'http://%s.koji.b2pweb.com/kojihub' % opts.arch
# setup the koji session
logging.info('Setting up koji session')
kojisession = koji.ClientSession(KOJIHUB)
</syntaxhighlight>

=== Signature d'un ou plusieurs paquets ===

C'est utile afin de signer des paquets qui ne sont pas les derniers construits (dernier N-V-R)
<syntaxhighlight lang="bash">
sigulsign_unsigned.py -v --password="motdepasse" --inherit centos-6-key <N-V-R>
</syntaxhighlight>

exemple:

<syntaxhighlight lang="bash">
sigulsign_unsigned.py -v --password="$(cat /root/.sigul/centos-6-key)" --inherit centos-6-key appliance-tools-007.0-1.el6
</syntaxhighlight>

Koji/SigulInstall

2015-04-22T07:41:28Z

Didier : /* Interfacer Sigul et koji */

== Vue d'ensemble ==

<class>Sigul</class> est une suite logicielle pour un serveur de signature, qui peut signer les RPMs ou de simple ou multiples fichiers. Toutes les clés [[Security/OpenGPG|GPG]] sont stockés uniquement sur le serveur <class>Sigul</class> (Sigul server), et donc aucun utilisateur n'a accès à aucune clé publique ou privée. Toutes les communications avec le serveur passent par le pont <class>Sigul</class> (Sigul bridge) qui agit comme une passerelle entre le client et le serveur. Cela isole le serveur et interdit tout accès extérieur autre que depuis le pont. Le client <class>Sigul</class>, une fois configuré, autorise les utilisateurs à signer les RPMs avec les clés créées (ou importées) sur le serveur <class>Sigul</class>, en envoyant des commandes au pont, qui lui se chargera de transmettre au serveur.
[[Fichier:SigulArch.svg|441px|centré|vignette|Architecture de Sigul]]
{{Admon/bug|<class>Sigul</class> sur les systèmes el6|<class>Sigul</class> a un bug récurrent<ref>https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=894019</ref> sur les systèmes el6 et a besoin de travailler avec le paquet <package>gnupg1</package> au lieu du paquet par défaut <package>gnupg2</package>.

Il faut modifier le fichier <path>/usr/share/sigul/settings.py</path>
<pre>gnupg_bin = "/usr/bin/gpg1"</pre>

Le paquet <package>sigul</package> du dépôt B2PWeb intègre déjà les modifications pour travailler avec <package>gnupg1</package>.}}

== Installation ==

Rien de plus simple, on installe via [[RPM/UsingYum|yum]], puis on créé l'arborescence nécessaire aux composants de <class>Sigul</class> {{Admon/smiley|:)}}

La création de l'arborescence est rendue nécessaire par le fait d'installer le pont et le serveur sur le même système (chose qui n'est pas recommandée pour des raisons de sécurité)
<syntaxhighlight lang="bash">
yum install sigul
su - sigul -s /bin/bash -c 'mkdir /var/lib/sigul/{bridge,server}'
</syntaxhighlight>
{{Admon/tip|Modification permanente pour l'utilisateur sigul|Il peut être pratique de fixer le shell pour l'utilisateur sigul afin de simplifier les commandes d'administrations
<syntaxhighlight lang="bash"># usermod -s /bin/bash sigul</syntaxhighlight>
De même, on peut fixer définitivement les variables utilisées dans l'installation en ajoutant au fichier <path>~/.bash_profile</path> de l'utilisateur sigul
<pre>
bridge_dir=/var/lib/sigul/bridge
server_dir=/var/lib/sigul/server
export bridge_dir
export server_dir

gpgagent=$(ps aux | grep gpg | grep sigul | grep -v grep | wc -l)
[ ${gpgagent} -eq 0 ] && gpg-agent --homedir=/var/lib/sigul/server --daemon --use-standard-socket 1>/dev/null 2>&1
</pre>
}}
{{Admon/note|FAS|FAS est le système de compte de Fedora, nous n'avons pas besoin de FAS pour un système <class>Sigul</class> personnel.}}
{{Admon/warning|Mot de passe NSS| Il faut impérativement se rappeler tous les mots de passes utilisés ici.}}

== Firewall ==

* Le pont <class>Sigul</class> doit pouvoir communiquer avec le serveur <class>Sigul</class> ( default: TCP port 44333 )
* Tous les clients <class>Sigul</class> doivent pouvoir communiquer avec le pont <class>Sigul</class> ( default: TCP port 44334 )

Naturellement, Le pont peut avoir des accès plus restrictifs ( autorisation de quelques adresses IP )
* Pour le pont<syntaxhighlight lang="bash">iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 44334 -j ACCEPT</syntaxhighlight>
* Pour le serveur (une seule adresse autorisée)<syntaxhighlight lang="bash">iptables -A INPUT -s 192.168.0.148/32 -p tcp -m state --state NEW -m tcp --dport 44333 -j ACCEPT</syntaxhighlight>

== Mise en place du pont ==

Le pont agit en tant que passerelle centrale su système <class>Sigul</class>. C'est le seul composant qui dialogue avec le serveur, c'est à dire que les commandes clientes pour le serveur vont être envoyées au pont, qui les relayera au serveur, recevra la réponse et la redistribuera au client. Le pont agit en tant que passerelle pour [[Koji]] pour la signature des paquets, le pont dialogue avec le [[Koji/Installation#Pr.C3.A9sentation|Hub Koji]] avec l’authentification d'un utilisateur Proxy, comme Kojiweb. La partie sur la liaison entre <class>Sigul</class> et <class>Koji</class> est [[Koji/SigulInstall#Configuration_de_Sigul_pour_koji|ici]].

Pour démarrer la mise en place, on doit générer les certificats qui seront utilisés pour authentifier les différent composants du système <class>Sigul</class> entre eux. Le pont sera utilisé comme Autorité de Certification pour les communications internes du système <class>Sigul</class>.

=== Opérations avec le compte sigul ===

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash"># su - sigul</syntaxhighlight>
* Définition du répertoire de destination<syntaxhighlight lang="bash">bridge_dir=/var/lib/sigul/bridge</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$bridge_dir''<syntaxhighlight lang="bash">certutil -d $bridge_dir -N</syntaxhighlight>
* Génération de l'autorité de certification (CA: Certificate Authority) qui sera utilisée par tous les composants <class>Sigul</class><syntaxhighlight lang="bash">certutil -d $bridge_dir -S -n sigul-ca -s 'CN=Sigul CA' -t CT,, -x -v 120</syntaxhighlight>
* Génération d'un certificat pour le pont Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le pont est hebergé<syntaxhighlight lang="bash">certutil -d $bridge_dir -S -n sigul-bridge-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120</syntaxhighlight>

=== Opérations avec le compte root ===

Il est temps de configurer le pont en éditant le fichier <path>/etc/sigul/bridge.conf</path>

<pre>
[bridge]
bridge-cert-nickname: sigul-bridge-cert
client-listen-port: 44334
server-listen-port: 44333
max-rpms-payload-size: 10737418240

[koji]
koji-config: ~/.koji/config

[daemon]
unix-user: sigul
unix-group: sigul

[nss]
nss-dir: /var/lib/sigul/bridge
nss-password: bridgensspasswd
</pre>

=== Test ===

Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_bridge.log</path>
<syntaxhighlight lang="bash">sigul_bridge -v -v</syntaxhighlight>

Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.
{{Admon/note|Le premier message du fichier <path>/var/log/sigul_bridge.log</path> doit être
<pre>2011-11-24 16:41:42,214 DEBUG: Waiting for the client to connect</pre>}}

Arrêt du pont sigul CRTL-C

=== Démarrage ===

On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.

'''systemd'''
<syntaxhighlight lang="bash">
systemctl start sigul_bridge.service
systemctl enable sigul_bridge.service
</syntaxhighlight>
'''sysVinit'''
<syntaxhighlight lang="bash">
service sigul_bridge start
chkconfig sigul_bridge on
</syntaxhighlight>

== Mise en place du serveur ==

Le serveur est complètement isolé du reste du monde. Toutes les communications depuis l'extérieur doivent être interdites, exception faite des communications avec le pont. De même, les communications sortantes doivent être restreintes au pont pour un maximum de sécurité. Il faut s'assurer qu'aucun accès exterieur est possible (même web). Il détient toutes les clés pour signer les RPMs, et donc aucun utilisateur ne doit avoir accès directement aux clés, le serveur est le seul système qui connait les clés.

=== Opérations préalables sur le pont avec l'utilisateur sigul ===
* Export de l'autorité de certification dans le fichier <path>sigulca.p12</path><syntaxhighlight lang="bash">pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca</syntaxhighlight>
* Copie du fichier <path>sigulca.p12</path> sur le serveur <class>Sigul</class>
* Destruction de l'export<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>

=== Opérations avec l'utilisateur sigul ===

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash"># su - sigul</syntaxhighlight>
* Définition du répertoire de destination<syntaxhighlight lang="bash">server_dir=/var/lib/sigul/server</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$server_dir''<syntaxhighlight lang="bash">certutil -d $server_dir -N</syntaxhighlight>
* Import de l'autorité de certification (CA: Certificate Authority)<syntaxhighlight lang="bash">pk12util -d $server_dir -i sigulca.p12</syntaxhighlight><syntaxhighlight lang="bash">certutil -d $server_dir -M -n sigul-ca -t CT,,</syntaxhighlight>
* Génération d'un certificat pour le serveur Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le serveur est hebergé<syntaxhighlight lang="bash">certutil -d $server_dir -S -n sigul-server-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120</syntaxhighlight>
* Suppression de l'export de l'autorité de certification<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>
{{Admon/bug|Répertoire racine de gnupg|Bien que la configuration de sigul puisse être éditée,
<pre>_default_storage_path = '/var/lib/sigul/server'
default_gnupg_home = os.path.join(_default_storage_path, 'gnupg')
</pre>
il faut quand même rajouter un lien symbolique à la racine du répertoire personnel de sigul.
<pre>
cd /var/lib/sigul
ln -s /var/lib/sigul/server/gnupg gnupg
</pre>}}

=== Opérations avec l'utilisateur root ===

Il est temps de configurer le serveur en éditant le fichier <path>/etc/sigul/server.conf</path>.
<pre>
[server]
bridge-hostname: koji.didier-linux.eu
bridge-port: 44333
max-file-payload-size: 1073741824
max-memory-payload-size: 1048576
max-rpms-payload-size: 10737418240
server-cert-nickname: sigul-server-cert
signing-timeout: 60

[database]
database-path: /var/lib/sigul/server/server.sqlite

[gnupg]
gnupg-home: /var/lib/sigul/server/gnupg
gnupg-key-type: DSA
gnupg-key-length: 1024
gnupg-subkey-type: ELG-E
gnupg-subkey-length: 2048
gnupg-key-usage: sign
passphrase-length: 64

[daemon]
unix-user: sigul
unix-group: sigul

[nss]
nss-dir: /var/lib/sigul/server
nss-password: **********
</pre>

On va maintenant créer la base de données pour que le serveur y stocke les informations à propos des utilisateurs et des clés
<syntaxhighlight lang="bash">sigul_server_create_db</syntaxhighlight>

On va ajouter l'administrateur initial. Celui-ci doit déjà exister localement sur le système.
<syntaxhighlight lang="bash">sigul_server_add_admin</syntaxhighlight>

=== Test ===

Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_server.log</path>
<syntaxhighlight lang="bash">sigul_server -v -v</syntaxhighlight>

Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.
{{Admon/note|You should see the first log message in <path>/var/log/sigul_server.log:</path>
<pre>2011-11-24 16:36:42,154 DEBUG: Waiting for a request</pre>}}

Arrêt du pont sigul CRTL-C

=== Démarrage ===

On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.

'''systemd'''
<syntaxhighlight lang="bash">
systemctl start sigul_server.service
systemctl enable sigul_server.service
</syntaxhighlight>
'''sysVinit'''
<syntaxhighlight lang="bash">
service sigul_server start
chkconfig sigul_server on
</syntaxhighlight>

== Mise en place du Client ==

Le client doit pouvoir s'authentifier sur le pont avec des certificats pour pouvoir envoyer des commandes à celui-ci.

=== Opérations préalables sur le pont avec l'utilisateur sigul ===

* Export de l'autorité de certification dans le fichier <path>sigulca.p12</path><syntaxhighlight lang="bash">pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca</syntaxhighlight>
* Copie du fichier <path>sigulca.p12</path> sur le client <class>Sigul</class> et modification du propriétaire sur celui-ci
* Destruction de l'export<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>

=== Opérations sur le client avec l'utilisateur root ===

Edition du fichier <path>/etc/sigul/client.conf</path>
<pre>
[client]
bridge-hostname: koji.didier-linux.eu
bridge-port: 44334
client-cert-nickname: sigul-client-cert
server-hostname: koji.didier-linux.eu

[koji]
koji-config: ~/.koji/config

[nss]
nss-dir: ~/.sigul
</pre>

=== Opérations sur le client avec l'utilisateur qui utilisera Sigul ===

* Définition du répertoire de destination<syntaxhighlight lang="bash">client_dir=~/.sigul</syntaxhighlight>
* Création de celui-ci<syntaxhighlight lang="bash">mkdir $client_dir</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$client_dir''<syntaxhighlight lang="bash">certutil -d $client_dir -N</syntaxhighlight>
* Import de l'autorité de certification (CA: Certificate Authority)<syntaxhighlight lang="bash">pk12util -d $client_dir -i sigulca.p12</syntaxhighlight><syntaxhighlight lang="bash">certutil -d $client_dir -M -n sigul-ca -t CT,,</syntaxhighlight>
* Génération d'un certificat pour le serveur Le champs CN doit être le login de l'utilisateur pour le système <class>Sigul</class><syntaxhighlight lang="bash">certutil -d $client_dir -S -n sigul-client-cert -s 'CN=root' -c sigul-ca -t u,, -v 120</syntaxhighlight>
* Suppression de l'export de l'autorité de certification<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>
* Copie du fichier de configuration générale des clients <path>/etc/sigul/client.conf</path> dans son répertoire personnel <path>~/.sigul/client.conf</path><syntaxhighlight lang="bash">cp /etc/sigul/client.conf ~/.sigul/client.conf</syntaxhighlight>
* Édition du fichier <path>~/.sigul/client.conf</path> pour insérer le mot de passe de l'utilisateur dans la section [nss].<syntaxhighlight lang="bash">nss-password: Your NSS PASS</syntaxhighlight>

=== Test ===
Test avec une commande sigul pour valider le bon fonctionnement de toute la chaine
sigul list-users

On peut maintenant utiliser pleinement <class>Sigul</class>.

==Sigul Client Config Script==

Ce script peut être utilisé pour mettre en place rapidement l’authentification pour un client <class>Sigul</class> quand l’authentification FAS n'est pas utilisée.
{{Admon/important|L'utilisateur doit déjà être créé sur le serveur|Ce script ne fait que la mise en place des certificats.}}
<syntaxhighlight lang="bash">
#!/bin/bash
#Variables### And initial setup#######
mkdir ~/.sigul
client_dir=~/.sigul
user=$(whoami)
####################
echo
############################Begin Certificate imports
echo "======================="
echo "Setting up NSS Database"
echo "======================="
certutil -d $client_dir -N
echo
echo "==================="
echo "Downloading CA Cert"
echo "==================="
wget http://someurl.com/sigul/sigulca.p12 <-- Substitute with a path or url of your exported .p12
echo
echo "=================="
echo "Importing CA certs"
echo "=================="
pk12util -d $client_dir -i sigulca.p12
certutil -d $client_dir -M -n sigul-ca -t CT,,
echo
echo "======================"
echo "Generating Client cert"
echo "======================"
certutil -d $client_dir -S -n sigul-client-cert -s "CN=$user" -c sigul-ca -t u,, -v 120
echo
echo "======================"
#########End certificate imports########
########################################
#########NSS password Saver#############
read -p "Would you like to save your nss pass to ~/.sigul/client.conf [y/n]: " nsspasssel
#########User Input conditional#########
if [ $nsspasssel == "y" -o $nsspasssel == "Y" ]; then
echo "Enter your NSS password One more time: "
read -s nsspass
echo "[nss]" > ~/.sigul/client.conf
echo "nss-password: $nsspass" >> ~/.sigul/client.conf
echo
echo "==========="
echo "Cleaning up"
echo "==========="
rm sigulca.p12
else
echo
echo "==========="
echo "Cleaning up"
echo "==========="
rm sigulca.p12
fi
#########################################\
</syntaxhighlight>

== Utilisation ==
Utilisation de son [[Koji/SigulUsing|Sigul signing server]]

== Références ==
<references/>

Koji/SigulInstall

2015-04-22T07:39:39Z

Didier : /* Opérations sur le client avec l'utilisateur qui utilisera Sigul */

== Vue d'ensemble ==

<class>Sigul</class> est une suite logicielle pour un serveur de signature, qui peut signer les RPMs ou de simple ou multiples fichiers. Toutes les clés [[Security/OpenGPG|GPG]] sont stockés uniquement sur le serveur <class>Sigul</class> (Sigul server), et donc aucun utilisateur n'a accès à aucune clé publique ou privée. Toutes les communications avec le serveur passent par le pont <class>Sigul</class> (Sigul bridge) qui agit comme une passerelle entre le client et le serveur. Cela isole le serveur et interdit tout accès extérieur autre que depuis le pont. Le client <class>Sigul</class>, une fois configuré, autorise les utilisateurs à signer les RPMs avec les clés créées (ou importées) sur le serveur <class>Sigul</class>, en envoyant des commandes au pont, qui lui se chargera de transmettre au serveur.
[[Fichier:SigulArch.svg|441px|centré|vignette|Architecture de Sigul]]
{{Admon/bug|<class>Sigul</class> sur les systèmes el6|<class>Sigul</class> a un bug récurrent<ref>https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=894019</ref> sur les systèmes el6 et a besoin de travailler avec le paquet <package>gnupg1</package> au lieu du paquet par défaut <package>gnupg2</package>.

Il faut modifier le fichier <path>/usr/share/sigul/settings.py</path>
<pre>gnupg_bin = "/usr/bin/gpg1"</pre>

Le paquet <package>sigul</package> du dépôt B2PWeb intègre déjà les modifications pour travailler avec <package>gnupg1</package>.}}

== Installation ==

Rien de plus simple, on installe via [[RPM/UsingYum|yum]], puis on créé l'arborescence nécessaire aux composants de <class>Sigul</class> {{Admon/smiley|:)}}

La création de l'arborescence est rendue nécessaire par le fait d'installer le pont et le serveur sur le même système (chose qui n'est pas recommandée pour des raisons de sécurité)
<syntaxhighlight lang="bash">
yum install sigul
su - sigul -s /bin/bash -c 'mkdir /var/lib/sigul/{bridge,server}'
</syntaxhighlight>
{{Admon/tip|Modification permanente pour l'utilisateur sigul|Il peut être pratique de fixer le shell pour l'utilisateur sigul afin de simplifier les commandes d'administrations
<syntaxhighlight lang="bash"># usermod -s /bin/bash sigul</syntaxhighlight>
De même, on peut fixer définitivement les variables utilisées dans l'installation en ajoutant au fichier <path>~/.bash_profile</path> de l'utilisateur sigul
<pre>
bridge_dir=/var/lib/sigul/bridge
server_dir=/var/lib/sigul/server
export bridge_dir
export server_dir

gpgagent=$(ps aux | grep gpg | grep sigul | grep -v grep | wc -l)
[ ${gpgagent} -eq 0 ] && gpg-agent --homedir=/var/lib/sigul/server --daemon --use-standard-socket 1>/dev/null 2>&1
</pre>
}}
{{Admon/note|FAS|FAS est le système de compte de Fedora, nous n'avons pas besoin de FAS pour un système <class>Sigul</class> personnel.}}
{{Admon/warning|Mot de passe NSS| Il faut impérativement se rappeler tous les mots de passes utilisés ici.}}

== Firewall ==

* Le pont <class>Sigul</class> doit pouvoir communiquer avec le serveur <class>Sigul</class> ( default: TCP port 44333 )
* Tous les clients <class>Sigul</class> doivent pouvoir communiquer avec le pont <class>Sigul</class> ( default: TCP port 44334 )

Naturellement, Le pont peut avoir des accès plus restrictifs ( autorisation de quelques adresses IP )
* Pour le pont<syntaxhighlight lang="bash">iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 44334 -j ACCEPT</syntaxhighlight>
* Pour le serveur (une seule adresse autorisée)<syntaxhighlight lang="bash">iptables -A INPUT -s 192.168.0.148/32 -p tcp -m state --state NEW -m tcp --dport 44333 -j ACCEPT</syntaxhighlight>

== Mise en place du pont ==

Le pont agit en tant que passerelle centrale su système <class>Sigul</class>. C'est le seul composant qui dialogue avec le serveur, c'est à dire que les commandes clientes pour le serveur vont être envoyées au pont, qui les relayera au serveur, recevra la réponse et la redistribuera au client. Le pont agit en tant que passerelle pour [[Koji]] pour la signature des paquets, le pont dialogue avec le [[Koji/Installation#Pr.C3.A9sentation|Hub Koji]] avec l’authentification d'un utilisateur Proxy, comme Kojiweb. La partie sur la liaison entre <class>Sigul</class> et <class>Koji</class> est [[Koji/SigulInstall#Configuration_de_Sigul_pour_koji|ici]].

Pour démarrer la mise en place, on doit générer les certificats qui seront utilisés pour authentifier les différent composants du système <class>Sigul</class> entre eux. Le pont sera utilisé comme Autorité de Certification pour les communications internes du système <class>Sigul</class>.

=== Opérations avec le compte sigul ===

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash"># su - sigul</syntaxhighlight>
* Définition du répertoire de destination<syntaxhighlight lang="bash">bridge_dir=/var/lib/sigul/bridge</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$bridge_dir''<syntaxhighlight lang="bash">certutil -d $bridge_dir -N</syntaxhighlight>
* Génération de l'autorité de certification (CA: Certificate Authority) qui sera utilisée par tous les composants <class>Sigul</class><syntaxhighlight lang="bash">certutil -d $bridge_dir -S -n sigul-ca -s 'CN=Sigul CA' -t CT,, -x -v 120</syntaxhighlight>
* Génération d'un certificat pour le pont Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le pont est hebergé<syntaxhighlight lang="bash">certutil -d $bridge_dir -S -n sigul-bridge-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120</syntaxhighlight>

=== Opérations avec le compte root ===

Il est temps de configurer le pont en éditant le fichier <path>/etc/sigul/bridge.conf</path>

<pre>
[bridge]
bridge-cert-nickname: sigul-bridge-cert
client-listen-port: 44334
server-listen-port: 44333
max-rpms-payload-size: 10737418240

[koji]
koji-config: ~/.koji/config

[daemon]
unix-user: sigul
unix-group: sigul

[nss]
nss-dir: /var/lib/sigul/bridge
nss-password: bridgensspasswd
</pre>

=== Test ===

Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_bridge.log</path>
<syntaxhighlight lang="bash">sigul_bridge -v -v</syntaxhighlight>

Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.
{{Admon/note|Le premier message du fichier <path>/var/log/sigul_bridge.log</path> doit être
<pre>2011-11-24 16:41:42,214 DEBUG: Waiting for the client to connect</pre>}}

Arrêt du pont sigul CRTL-C

=== Démarrage ===

On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.

'''systemd'''
<syntaxhighlight lang="bash">
systemctl start sigul_bridge.service
systemctl enable sigul_bridge.service
</syntaxhighlight>
'''sysVinit'''
<syntaxhighlight lang="bash">
service sigul_bridge start
chkconfig sigul_bridge on
</syntaxhighlight>

== Mise en place du serveur ==

Le serveur est complètement isolé du reste du monde. Toutes les communications depuis l'extérieur doivent être interdites, exception faite des communications avec le pont. De même, les communications sortantes doivent être restreintes au pont pour un maximum de sécurité. Il faut s'assurer qu'aucun accès exterieur est possible (même web). Il détient toutes les clés pour signer les RPMs, et donc aucun utilisateur ne doit avoir accès directement aux clés, le serveur est le seul système qui connait les clés.

=== Opérations préalables sur le pont avec l'utilisateur sigul ===
* Export de l'autorité de certification dans le fichier <path>sigulca.p12</path><syntaxhighlight lang="bash">pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca</syntaxhighlight>
* Copie du fichier <path>sigulca.p12</path> sur le serveur <class>Sigul</class>
* Destruction de l'export<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>

=== Opérations avec l'utilisateur sigul ===

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash"># su - sigul</syntaxhighlight>
* Définition du répertoire de destination<syntaxhighlight lang="bash">server_dir=/var/lib/sigul/server</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$server_dir''<syntaxhighlight lang="bash">certutil -d $server_dir -N</syntaxhighlight>
* Import de l'autorité de certification (CA: Certificate Authority)<syntaxhighlight lang="bash">pk12util -d $server_dir -i sigulca.p12</syntaxhighlight><syntaxhighlight lang="bash">certutil -d $server_dir -M -n sigul-ca -t CT,,</syntaxhighlight>
* Génération d'un certificat pour le serveur Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le serveur est hebergé<syntaxhighlight lang="bash">certutil -d $server_dir -S -n sigul-server-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120</syntaxhighlight>
* Suppression de l'export de l'autorité de certification<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>
{{Admon/bug|Répertoire racine de gnupg|Bien que la configuration de sigul puisse être éditée,
<pre>_default_storage_path = '/var/lib/sigul/server'
default_gnupg_home = os.path.join(_default_storage_path, 'gnupg')
</pre>
il faut quand même rajouter un lien symbolique à la racine du répertoire personnel de sigul.
<pre>
cd /var/lib/sigul
ln -s /var/lib/sigul/server/gnupg gnupg
</pre>}}

=== Opérations avec l'utilisateur root ===

Il est temps de configurer le serveur en éditant le fichier <path>/etc/sigul/server.conf</path>.
<pre>
[server]
bridge-hostname: koji.didier-linux.eu
bridge-port: 44333
max-file-payload-size: 1073741824
max-memory-payload-size: 1048576
max-rpms-payload-size: 10737418240
server-cert-nickname: sigul-server-cert
signing-timeout: 60

[database]
database-path: /var/lib/sigul/server/server.sqlite

[gnupg]
gnupg-home: /var/lib/sigul/server/gnupg
gnupg-key-type: DSA
gnupg-key-length: 1024
gnupg-subkey-type: ELG-E
gnupg-subkey-length: 2048
gnupg-key-usage: sign
passphrase-length: 64

[daemon]
unix-user: sigul
unix-group: sigul

[nss]
nss-dir: /var/lib/sigul/server
nss-password: **********
</pre>

On va maintenant créer la base de données pour que le serveur y stocke les informations à propos des utilisateurs et des clés
<syntaxhighlight lang="bash">sigul_server_create_db</syntaxhighlight>

On va ajouter l'administrateur initial. Celui-ci doit déjà exister localement sur le système.
<syntaxhighlight lang="bash">sigul_server_add_admin</syntaxhighlight>

=== Test ===

Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_server.log</path>
<syntaxhighlight lang="bash">sigul_server -v -v</syntaxhighlight>

Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.
{{Admon/note|You should see the first log message in <path>/var/log/sigul_server.log:</path>
<pre>2011-11-24 16:36:42,154 DEBUG: Waiting for a request</pre>}}

Arrêt du pont sigul CRTL-C

=== Démarrage ===

On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.

'''systemd'''
<syntaxhighlight lang="bash">
systemctl start sigul_server.service
systemctl enable sigul_server.service
</syntaxhighlight>
'''sysVinit'''
<syntaxhighlight lang="bash">
service sigul_server start
chkconfig sigul_server on
</syntaxhighlight>

== Mise en place du Client ==

Le client doit pouvoir s'authentifier sur le pont avec des certificats pour pouvoir envoyer des commandes à celui-ci.

=== Opérations préalables sur le pont avec l'utilisateur sigul ===

* Export de l'autorité de certification dans le fichier <path>sigulca.p12</path><syntaxhighlight lang="bash">pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca</syntaxhighlight>
* Copie du fichier <path>sigulca.p12</path> sur le client <class>Sigul</class> et modification du propriétaire sur celui-ci
* Destruction de l'export<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>

=== Opérations sur le client avec l'utilisateur root ===

Edition du fichier <path>/etc/sigul/client.conf</path>
<pre>
[client]
bridge-hostname: koji.didier-linux.eu
bridge-port: 44334
client-cert-nickname: sigul-client-cert
server-hostname: koji.didier-linux.eu

[koji]
koji-config: ~/.koji/config

[nss]
nss-dir: ~/.sigul
</pre>

=== Opérations sur le client avec l'utilisateur qui utilisera Sigul ===

* Définition du répertoire de destination<syntaxhighlight lang="bash">client_dir=~/.sigul</syntaxhighlight>
* Création de celui-ci<syntaxhighlight lang="bash">mkdir $client_dir</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$client_dir''<syntaxhighlight lang="bash">certutil -d $client_dir -N</syntaxhighlight>
* Import de l'autorité de certification (CA: Certificate Authority)<syntaxhighlight lang="bash">pk12util -d $client_dir -i sigulca.p12</syntaxhighlight><syntaxhighlight lang="bash">certutil -d $client_dir -M -n sigul-ca -t CT,,</syntaxhighlight>
* Génération d'un certificat pour le serveur Le champs CN doit être le login de l'utilisateur pour le système <class>Sigul</class><syntaxhighlight lang="bash">certutil -d $client_dir -S -n sigul-client-cert -s 'CN=root' -c sigul-ca -t u,, -v 120</syntaxhighlight>
* Suppression de l'export de l'autorité de certification<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>
* Copie du fichier de configuration générale des clients <path>/etc/sigul/client.conf</path> dans son répertoire personnel <path>~/.sigul/client.conf</path><syntaxhighlight lang="bash">cp /etc/sigul/client.conf ~/.sigul/client.conf</syntaxhighlight>
* Édition du fichier <path>~/.sigul/client.conf</path> pour insérer le mot de passe de l'utilisateur dans la section [nss].<syntaxhighlight lang="bash">nss-password: Your NSS PASS</syntaxhighlight>

=== Test ===
Test avec une commande sigul pour valider le bon fonctionnement de toute la chaine
sigul list-users

On peut maintenant utiliser pleinement <class>Sigul</class>.

== Interfacer Sigul et koji ==

=== configuration ===

<class>Sigul</class> peut être utiliser pour signer un ou de multiples RPMs dans une instance <class>Koji</class>. Une fois le client Sigul correctement configuré, il suffit juste de configurer l'utilisateur Proxy pour Koji. Quand un client <class>Sigul</class> émet une requête de signature pour <class>Koji</class>, le pont <class>Sigul</class> se connecte à <class>Koji</class> en tant qu'utilisateur '''kojiweb'''. Il faut juste s'assurer que l'utilisateur demandeur a les droits administrateur sur le <class>Koji</class> et <class>Sigul</class> s'occupe du reste.

La configuration pour <class>Koji</class> peut être situer n'importe où, du moment que l'utilisateur sigul a droit de lecture. Les certificats pour '''kojiweb''' doivent être copiés dans le même chemin que la configuration <class>Koji</class>

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash">su - sigul</syntaxhighlight>
* Création du répertoire de configuration de <class>Koji</class><syntaxhighlight lang="bash">mkdir -p ~/.koji</syntaxhighlight>
* Copie de la configuration par défaut du client <class>Koji</class><syntaxhighlight lang="bash">cp /etc/koji.conf ~/.koji/config</syntaxhighlight>
* Copie des certificats {{class|Kojiweb}} dans celui-ci<syntaxhighlight lang="bash">cp /etc/pki/koji/pem/kojiweb.pem .koji/client.pem</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/clientca.crt</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/serverca.crt</syntaxhighlight>

Après avoir redémarrer le pont <class>Sigul</class>, le client doit être capable d'obtenir un RPM depuis Koji et de le signer.

=== Test ===

Pour tester l'interfaçage, on va obtenir un RPM depuis <class>Koji</class>, le signer et le sauvegarder dans le répertoire de travail actuel. c'est juste pour tester la connxion et l'authentification sur <class>Koji</class> et <class>Sigul</class>.
<syntaxhighlight lang="bash">sigul sign-rpm -o signed.rpm key_name unsigned.rpm</syntaxhighlight>

Si la commande précédente fonctionne, un RPM signé est présent dans le répertoire de travail actuel.

On vérifie sa signature
<syntaxhighlight lang="bash">rpm --checksig signed.rpm</syntaxhighlight>

==Sigul Client Config Script==

Ce script peut être utilisé pour mettre en place rapidement l’authentification pour un client <class>Sigul</class> quand l’authentification FAS n'est pas utilisée.
{{Admon/important|L'utilisateur doit déjà être créé sur le serveur|Ce script ne fait que la mise en place des certificats.}}
<syntaxhighlight lang="bash">
#!/bin/bash
#Variables### And initial setup#######
mkdir ~/.sigul
client_dir=~/.sigul
user=$(whoami)
####################
echo
############################Begin Certificate imports
echo "======================="
echo "Setting up NSS Database"
echo "======================="
certutil -d $client_dir -N
echo
echo "==================="
echo "Downloading CA Cert"
echo "==================="
wget http://someurl.com/sigul/sigulca.p12 <-- Substitute with a path or url of your exported .p12
echo
echo "=================="
echo "Importing CA certs"
echo "=================="
pk12util -d $client_dir -i sigulca.p12
certutil -d $client_dir -M -n sigul-ca -t CT,,
echo
echo "======================"
echo "Generating Client cert"
echo "======================"
certutil -d $client_dir -S -n sigul-client-cert -s "CN=$user" -c sigul-ca -t u,, -v 120
echo
echo "======================"
#########End certificate imports########
########################################
#########NSS password Saver#############
read -p "Would you like to save your nss pass to ~/.sigul/client.conf [y/n]: " nsspasssel
#########User Input conditional#########
if [ $nsspasssel == "y" -o $nsspasssel == "Y" ]; then
echo "Enter your NSS password One more time: "
read -s nsspass
echo "[nss]" > ~/.sigul/client.conf
echo "nss-password: $nsspass" >> ~/.sigul/client.conf
echo
echo "==========="
echo "Cleaning up"
echo "==========="
rm sigulca.p12
else
echo
echo "==========="
echo "Cleaning up"
echo "==========="
rm sigulca.p12
fi
#########################################\
</syntaxhighlight>

== Utilisation ==
Utilisation de son [[Koji/SigulUsing|Sigul signing server]]

== Références ==
<references/>

Koji/SigulInstall

2015-04-22T07:37:50Z

Didier : /* Opérations sur le client avec l'utilisateur root */

== Vue d'ensemble ==

<class>Sigul</class> est une suite logicielle pour un serveur de signature, qui peut signer les RPMs ou de simple ou multiples fichiers. Toutes les clés [[Security/OpenGPG|GPG]] sont stockés uniquement sur le serveur <class>Sigul</class> (Sigul server), et donc aucun utilisateur n'a accès à aucune clé publique ou privée. Toutes les communications avec le serveur passent par le pont <class>Sigul</class> (Sigul bridge) qui agit comme une passerelle entre le client et le serveur. Cela isole le serveur et interdit tout accès extérieur autre que depuis le pont. Le client <class>Sigul</class>, une fois configuré, autorise les utilisateurs à signer les RPMs avec les clés créées (ou importées) sur le serveur <class>Sigul</class>, en envoyant des commandes au pont, qui lui se chargera de transmettre au serveur.
[[Fichier:SigulArch.svg|441px|centré|vignette|Architecture de Sigul]]
{{Admon/bug|<class>Sigul</class> sur les systèmes el6|<class>Sigul</class> a un bug récurrent<ref>https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=894019</ref> sur les systèmes el6 et a besoin de travailler avec le paquet <package>gnupg1</package> au lieu du paquet par défaut <package>gnupg2</package>.

Il faut modifier le fichier <path>/usr/share/sigul/settings.py</path>
<pre>gnupg_bin = "/usr/bin/gpg1"</pre>

Le paquet <package>sigul</package> du dépôt B2PWeb intègre déjà les modifications pour travailler avec <package>gnupg1</package>.}}

== Installation ==

Rien de plus simple, on installe via [[RPM/UsingYum|yum]], puis on créé l'arborescence nécessaire aux composants de <class>Sigul</class> {{Admon/smiley|:)}}

La création de l'arborescence est rendue nécessaire par le fait d'installer le pont et le serveur sur le même système (chose qui n'est pas recommandée pour des raisons de sécurité)
<syntaxhighlight lang="bash">
yum install sigul
su - sigul -s /bin/bash -c 'mkdir /var/lib/sigul/{bridge,server}'
</syntaxhighlight>
{{Admon/tip|Modification permanente pour l'utilisateur sigul|Il peut être pratique de fixer le shell pour l'utilisateur sigul afin de simplifier les commandes d'administrations
<syntaxhighlight lang="bash"># usermod -s /bin/bash sigul</syntaxhighlight>
De même, on peut fixer définitivement les variables utilisées dans l'installation en ajoutant au fichier <path>~/.bash_profile</path> de l'utilisateur sigul
<pre>
bridge_dir=/var/lib/sigul/bridge
server_dir=/var/lib/sigul/server
export bridge_dir
export server_dir

gpgagent=$(ps aux | grep gpg | grep sigul | grep -v grep | wc -l)
[ ${gpgagent} -eq 0 ] && gpg-agent --homedir=/var/lib/sigul/server --daemon --use-standard-socket 1>/dev/null 2>&1
</pre>
}}
{{Admon/note|FAS|FAS est le système de compte de Fedora, nous n'avons pas besoin de FAS pour un système <class>Sigul</class> personnel.}}
{{Admon/warning|Mot de passe NSS| Il faut impérativement se rappeler tous les mots de passes utilisés ici.}}

== Firewall ==

* Le pont <class>Sigul</class> doit pouvoir communiquer avec le serveur <class>Sigul</class> ( default: TCP port 44333 )
* Tous les clients <class>Sigul</class> doivent pouvoir communiquer avec le pont <class>Sigul</class> ( default: TCP port 44334 )

Naturellement, Le pont peut avoir des accès plus restrictifs ( autorisation de quelques adresses IP )
* Pour le pont<syntaxhighlight lang="bash">iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 44334 -j ACCEPT</syntaxhighlight>
* Pour le serveur (une seule adresse autorisée)<syntaxhighlight lang="bash">iptables -A INPUT -s 192.168.0.148/32 -p tcp -m state --state NEW -m tcp --dport 44333 -j ACCEPT</syntaxhighlight>

== Mise en place du pont ==

Le pont agit en tant que passerelle centrale su système <class>Sigul</class>. C'est le seul composant qui dialogue avec le serveur, c'est à dire que les commandes clientes pour le serveur vont être envoyées au pont, qui les relayera au serveur, recevra la réponse et la redistribuera au client. Le pont agit en tant que passerelle pour [[Koji]] pour la signature des paquets, le pont dialogue avec le [[Koji/Installation#Pr.C3.A9sentation|Hub Koji]] avec l’authentification d'un utilisateur Proxy, comme Kojiweb. La partie sur la liaison entre <class>Sigul</class> et <class>Koji</class> est [[Koji/SigulInstall#Configuration_de_Sigul_pour_koji|ici]].

Pour démarrer la mise en place, on doit générer les certificats qui seront utilisés pour authentifier les différent composants du système <class>Sigul</class> entre eux. Le pont sera utilisé comme Autorité de Certification pour les communications internes du système <class>Sigul</class>.

=== Opérations avec le compte sigul ===

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash"># su - sigul</syntaxhighlight>
* Définition du répertoire de destination<syntaxhighlight lang="bash">bridge_dir=/var/lib/sigul/bridge</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$bridge_dir''<syntaxhighlight lang="bash">certutil -d $bridge_dir -N</syntaxhighlight>
* Génération de l'autorité de certification (CA: Certificate Authority) qui sera utilisée par tous les composants <class>Sigul</class><syntaxhighlight lang="bash">certutil -d $bridge_dir -S -n sigul-ca -s 'CN=Sigul CA' -t CT,, -x -v 120</syntaxhighlight>
* Génération d'un certificat pour le pont Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le pont est hebergé<syntaxhighlight lang="bash">certutil -d $bridge_dir -S -n sigul-bridge-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120</syntaxhighlight>

=== Opérations avec le compte root ===

Il est temps de configurer le pont en éditant le fichier <path>/etc/sigul/bridge.conf</path>

<pre>
[bridge]
bridge-cert-nickname: sigul-bridge-cert
client-listen-port: 44334
server-listen-port: 44333
max-rpms-payload-size: 10737418240

[koji]
koji-config: ~/.koji/config

[daemon]
unix-user: sigul
unix-group: sigul

[nss]
nss-dir: /var/lib/sigul/bridge
nss-password: bridgensspasswd
</pre>

=== Test ===

Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_bridge.log</path>
<syntaxhighlight lang="bash">sigul_bridge -v -v</syntaxhighlight>

Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.
{{Admon/note|Le premier message du fichier <path>/var/log/sigul_bridge.log</path> doit être
<pre>2011-11-24 16:41:42,214 DEBUG: Waiting for the client to connect</pre>}}

Arrêt du pont sigul CRTL-C

=== Démarrage ===

On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.

'''systemd'''
<syntaxhighlight lang="bash">
systemctl start sigul_bridge.service
systemctl enable sigul_bridge.service
</syntaxhighlight>
'''sysVinit'''
<syntaxhighlight lang="bash">
service sigul_bridge start
chkconfig sigul_bridge on
</syntaxhighlight>

== Mise en place du serveur ==

Le serveur est complètement isolé du reste du monde. Toutes les communications depuis l'extérieur doivent être interdites, exception faite des communications avec le pont. De même, les communications sortantes doivent être restreintes au pont pour un maximum de sécurité. Il faut s'assurer qu'aucun accès exterieur est possible (même web). Il détient toutes les clés pour signer les RPMs, et donc aucun utilisateur ne doit avoir accès directement aux clés, le serveur est le seul système qui connait les clés.

=== Opérations préalables sur le pont avec l'utilisateur sigul ===
* Export de l'autorité de certification dans le fichier <path>sigulca.p12</path><syntaxhighlight lang="bash">pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca</syntaxhighlight>
* Copie du fichier <path>sigulca.p12</path> sur le serveur <class>Sigul</class>
* Destruction de l'export<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>

=== Opérations avec l'utilisateur sigul ===

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash"># su - sigul</syntaxhighlight>
* Définition du répertoire de destination<syntaxhighlight lang="bash">server_dir=/var/lib/sigul/server</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$server_dir''<syntaxhighlight lang="bash">certutil -d $server_dir -N</syntaxhighlight>
* Import de l'autorité de certification (CA: Certificate Authority)<syntaxhighlight lang="bash">pk12util -d $server_dir -i sigulca.p12</syntaxhighlight><syntaxhighlight lang="bash">certutil -d $server_dir -M -n sigul-ca -t CT,,</syntaxhighlight>
* Génération d'un certificat pour le serveur Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le serveur est hebergé<syntaxhighlight lang="bash">certutil -d $server_dir -S -n sigul-server-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120</syntaxhighlight>
* Suppression de l'export de l'autorité de certification<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>
{{Admon/bug|Répertoire racine de gnupg|Bien que la configuration de sigul puisse être éditée,
<pre>_default_storage_path = '/var/lib/sigul/server'
default_gnupg_home = os.path.join(_default_storage_path, 'gnupg')
</pre>
il faut quand même rajouter un lien symbolique à la racine du répertoire personnel de sigul.
<pre>
cd /var/lib/sigul
ln -s /var/lib/sigul/server/gnupg gnupg
</pre>}}

=== Opérations avec l'utilisateur root ===

Il est temps de configurer le serveur en éditant le fichier <path>/etc/sigul/server.conf</path>.
<pre>
[server]
bridge-hostname: koji.didier-linux.eu
bridge-port: 44333
max-file-payload-size: 1073741824
max-memory-payload-size: 1048576
max-rpms-payload-size: 10737418240
server-cert-nickname: sigul-server-cert
signing-timeout: 60

[database]
database-path: /var/lib/sigul/server/server.sqlite

[gnupg]
gnupg-home: /var/lib/sigul/server/gnupg
gnupg-key-type: DSA
gnupg-key-length: 1024
gnupg-subkey-type: ELG-E
gnupg-subkey-length: 2048
gnupg-key-usage: sign
passphrase-length: 64

[daemon]
unix-user: sigul
unix-group: sigul

[nss]
nss-dir: /var/lib/sigul/server
nss-password: **********
</pre>

On va maintenant créer la base de données pour que le serveur y stocke les informations à propos des utilisateurs et des clés
<syntaxhighlight lang="bash">sigul_server_create_db</syntaxhighlight>

On va ajouter l'administrateur initial. Celui-ci doit déjà exister localement sur le système.
<syntaxhighlight lang="bash">sigul_server_add_admin</syntaxhighlight>

=== Test ===

Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_server.log</path>
<syntaxhighlight lang="bash">sigul_server -v -v</syntaxhighlight>

Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.
{{Admon/note|You should see the first log message in <path>/var/log/sigul_server.log:</path>
<pre>2011-11-24 16:36:42,154 DEBUG: Waiting for a request</pre>}}

Arrêt du pont sigul CRTL-C

=== Démarrage ===

On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.

'''systemd'''
<syntaxhighlight lang="bash">
systemctl start sigul_server.service
systemctl enable sigul_server.service
</syntaxhighlight>
'''sysVinit'''
<syntaxhighlight lang="bash">
service sigul_server start
chkconfig sigul_server on
</syntaxhighlight>

== Mise en place du Client ==

Le client doit pouvoir s'authentifier sur le pont avec des certificats pour pouvoir envoyer des commandes à celui-ci.

=== Opérations préalables sur le pont avec l'utilisateur sigul ===

* Export de l'autorité de certification dans le fichier <path>sigulca.p12</path><syntaxhighlight lang="bash">pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca</syntaxhighlight>
* Copie du fichier <path>sigulca.p12</path> sur le client <class>Sigul</class> et modification du propriétaire sur celui-ci
* Destruction de l'export<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>

=== Opérations sur le client avec l'utilisateur root ===

Edition du fichier <path>/etc/sigul/client.conf</path>
<pre>
[client]
bridge-hostname: koji.didier-linux.eu
bridge-port: 44334
client-cert-nickname: sigul-client-cert
server-hostname: koji.didier-linux.eu

[koji]
koji-config: ~/.koji/config

[nss]
nss-dir: ~/.sigul
</pre>

=== Opérations sur le client avec l'utilisateur qui utilisera Sigul ===

* Définition du répertoire de destination<syntaxhighlight lang="bash">client_dir=~/.sigul</syntaxhighlight>
* Création de celui-ci<syntaxhighlight lang="bash">mkdir $client_dir</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$client_dir''<syntaxhighlight lang="bash">certutil -d $client_dir -N</syntaxhighlight>
* Import de l'autorité de certification (CA: Certificate Authority)<syntaxhighlight lang="bash">pk12util -d $client_dir -i sigulca.p12</syntaxhighlight><syntaxhighlight lang="bash">certutil -d $client_dir -M -n sigul-ca -t CT,,</syntaxhighlight>
* Génération d'un certificat pour le serveur Le champs CN doit être le login de l'utilisateur pour le système <class>Sigul</class><syntaxhighlight lang="bash">certutil -d $client_dir -S -n sigul-client-cert -s 'CN=didier' -c sigul-ca -t u,, -v 120</syntaxhighlight>
* Suppression de l'export de l'autorité de certification<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>
* Copie du fichier de configuration générale des clients <path>/etc/sigul/client.conf</path> dans son répertoire personnel <path>~/.sigul/client.conf</path><syntaxhighlight lang="bash">cp /etc/sigul/client.conf ~/.sigul/client.conf</syntaxhighlight>
* Édition du fichier <path>~/.sigul/client.conf</path> pour insérer le mot de passe de l'utilisateur dans la section [nss].<syntaxhighlight lang="bash">nss-password: Your NSS PASS</syntaxhighlight>

=== Test ===
Test avec une commande sigul pour valider le bon fonctionnement de toute la chaine
sigul list-users

On peut maintenant utiliser pleinement <class>Sigul</class>.

== Interfacer Sigul et koji ==

=== configuration ===

<class>Sigul</class> peut être utiliser pour signer un ou de multiples RPMs dans une instance <class>Koji</class>. Une fois le client Sigul correctement configuré, il suffit juste de configurer l'utilisateur Proxy pour Koji. Quand un client <class>Sigul</class> émet une requête de signature pour <class>Koji</class>, le pont <class>Sigul</class> se connecte à <class>Koji</class> en tant qu'utilisateur '''kojiweb'''. Il faut juste s'assurer que l'utilisateur demandeur a les droits administrateur sur le <class>Koji</class> et <class>Sigul</class> s'occupe du reste.

La configuration pour <class>Koji</class> peut être situer n'importe où, du moment que l'utilisateur sigul a droit de lecture. Les certificats pour '''kojiweb''' doivent être copiés dans le même chemin que la configuration <class>Koji</class>

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash">su - sigul</syntaxhighlight>
* Création du répertoire de configuration de <class>Koji</class><syntaxhighlight lang="bash">mkdir -p ~/.koji</syntaxhighlight>
* Copie de la configuration par défaut du client <class>Koji</class><syntaxhighlight lang="bash">cp /etc/koji.conf ~/.koji/config</syntaxhighlight>
* Copie des certificats {{class|Kojiweb}} dans celui-ci<syntaxhighlight lang="bash">cp /etc/pki/koji/pem/kojiweb.pem .koji/client.pem</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/clientca.crt</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/serverca.crt</syntaxhighlight>

Après avoir redémarrer le pont <class>Sigul</class>, le client doit être capable d'obtenir un RPM depuis Koji et de le signer.

=== Test ===

Pour tester l'interfaçage, on va obtenir un RPM depuis <class>Koji</class>, le signer et le sauvegarder dans le répertoire de travail actuel. c'est juste pour tester la connxion et l'authentification sur <class>Koji</class> et <class>Sigul</class>.
<syntaxhighlight lang="bash">sigul sign-rpm -o signed.rpm key_name unsigned.rpm</syntaxhighlight>

Si la commande précédente fonctionne, un RPM signé est présent dans le répertoire de travail actuel.

On vérifie sa signature
<syntaxhighlight lang="bash">rpm --checksig signed.rpm</syntaxhighlight>

==Sigul Client Config Script==

Ce script peut être utilisé pour mettre en place rapidement l’authentification pour un client <class>Sigul</class> quand l’authentification FAS n'est pas utilisée.
{{Admon/important|L'utilisateur doit déjà être créé sur le serveur|Ce script ne fait que la mise en place des certificats.}}
<syntaxhighlight lang="bash">
#!/bin/bash
#Variables### And initial setup#######
mkdir ~/.sigul
client_dir=~/.sigul
user=$(whoami)
####################
echo
############################Begin Certificate imports
echo "======================="
echo "Setting up NSS Database"
echo "======================="
certutil -d $client_dir -N
echo
echo "==================="
echo "Downloading CA Cert"
echo "==================="
wget http://someurl.com/sigul/sigulca.p12 <-- Substitute with a path or url of your exported .p12
echo
echo "=================="
echo "Importing CA certs"
echo "=================="
pk12util -d $client_dir -i sigulca.p12
certutil -d $client_dir -M -n sigul-ca -t CT,,
echo
echo "======================"
echo "Generating Client cert"
echo "======================"
certutil -d $client_dir -S -n sigul-client-cert -s "CN=$user" -c sigul-ca -t u,, -v 120
echo
echo "======================"
#########End certificate imports########
########################################
#########NSS password Saver#############
read -p "Would you like to save your nss pass to ~/.sigul/client.conf [y/n]: " nsspasssel
#########User Input conditional#########
if [ $nsspasssel == "y" -o $nsspasssel == "Y" ]; then
echo "Enter your NSS password One more time: "
read -s nsspass
echo "[nss]" > ~/.sigul/client.conf
echo "nss-password: $nsspass" >> ~/.sigul/client.conf
echo
echo "==========="
echo "Cleaning up"
echo "==========="
rm sigulca.p12
else
echo
echo "==========="
echo "Cleaning up"
echo "==========="
rm sigulca.p12
fi
#########################################\
</syntaxhighlight>

== Utilisation ==
Utilisation de son [[Koji/SigulUsing|Sigul signing server]]

== Références ==
<references/>

Koji/SigulInstall

2015-04-22T07:37:11Z

Didier : /* Opérations avec l'utilisateur root */

== Vue d'ensemble ==

<class>Sigul</class> est une suite logicielle pour un serveur de signature, qui peut signer les RPMs ou de simple ou multiples fichiers. Toutes les clés [[Security/OpenGPG|GPG]] sont stockés uniquement sur le serveur <class>Sigul</class> (Sigul server), et donc aucun utilisateur n'a accès à aucune clé publique ou privée. Toutes les communications avec le serveur passent par le pont <class>Sigul</class> (Sigul bridge) qui agit comme une passerelle entre le client et le serveur. Cela isole le serveur et interdit tout accès extérieur autre que depuis le pont. Le client <class>Sigul</class>, une fois configuré, autorise les utilisateurs à signer les RPMs avec les clés créées (ou importées) sur le serveur <class>Sigul</class>, en envoyant des commandes au pont, qui lui se chargera de transmettre au serveur.
[[Fichier:SigulArch.svg|441px|centré|vignette|Architecture de Sigul]]
{{Admon/bug|<class>Sigul</class> sur les systèmes el6|<class>Sigul</class> a un bug récurrent<ref>https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=894019</ref> sur les systèmes el6 et a besoin de travailler avec le paquet <package>gnupg1</package> au lieu du paquet par défaut <package>gnupg2</package>.

Il faut modifier le fichier <path>/usr/share/sigul/settings.py</path>
<pre>gnupg_bin = "/usr/bin/gpg1"</pre>

Le paquet <package>sigul</package> du dépôt B2PWeb intègre déjà les modifications pour travailler avec <package>gnupg1</package>.}}

== Installation ==

Rien de plus simple, on installe via [[RPM/UsingYum|yum]], puis on créé l'arborescence nécessaire aux composants de <class>Sigul</class> {{Admon/smiley|:)}}

La création de l'arborescence est rendue nécessaire par le fait d'installer le pont et le serveur sur le même système (chose qui n'est pas recommandée pour des raisons de sécurité)
<syntaxhighlight lang="bash">
yum install sigul
su - sigul -s /bin/bash -c 'mkdir /var/lib/sigul/{bridge,server}'
</syntaxhighlight>
{{Admon/tip|Modification permanente pour l'utilisateur sigul|Il peut être pratique de fixer le shell pour l'utilisateur sigul afin de simplifier les commandes d'administrations
<syntaxhighlight lang="bash"># usermod -s /bin/bash sigul</syntaxhighlight>
De même, on peut fixer définitivement les variables utilisées dans l'installation en ajoutant au fichier <path>~/.bash_profile</path> de l'utilisateur sigul
<pre>
bridge_dir=/var/lib/sigul/bridge
server_dir=/var/lib/sigul/server
export bridge_dir
export server_dir

gpgagent=$(ps aux | grep gpg | grep sigul | grep -v grep | wc -l)
[ ${gpgagent} -eq 0 ] && gpg-agent --homedir=/var/lib/sigul/server --daemon --use-standard-socket 1>/dev/null 2>&1
</pre>
}}
{{Admon/note|FAS|FAS est le système de compte de Fedora, nous n'avons pas besoin de FAS pour un système <class>Sigul</class> personnel.}}
{{Admon/warning|Mot de passe NSS| Il faut impérativement se rappeler tous les mots de passes utilisés ici.}}

== Firewall ==

* Le pont <class>Sigul</class> doit pouvoir communiquer avec le serveur <class>Sigul</class> ( default: TCP port 44333 )
* Tous les clients <class>Sigul</class> doivent pouvoir communiquer avec le pont <class>Sigul</class> ( default: TCP port 44334 )

Naturellement, Le pont peut avoir des accès plus restrictifs ( autorisation de quelques adresses IP )
* Pour le pont<syntaxhighlight lang="bash">iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 44334 -j ACCEPT</syntaxhighlight>
* Pour le serveur (une seule adresse autorisée)<syntaxhighlight lang="bash">iptables -A INPUT -s 192.168.0.148/32 -p tcp -m state --state NEW -m tcp --dport 44333 -j ACCEPT</syntaxhighlight>

== Mise en place du pont ==

Le pont agit en tant que passerelle centrale su système <class>Sigul</class>. C'est le seul composant qui dialogue avec le serveur, c'est à dire que les commandes clientes pour le serveur vont être envoyées au pont, qui les relayera au serveur, recevra la réponse et la redistribuera au client. Le pont agit en tant que passerelle pour [[Koji]] pour la signature des paquets, le pont dialogue avec le [[Koji/Installation#Pr.C3.A9sentation|Hub Koji]] avec l’authentification d'un utilisateur Proxy, comme Kojiweb. La partie sur la liaison entre <class>Sigul</class> et <class>Koji</class> est [[Koji/SigulInstall#Configuration_de_Sigul_pour_koji|ici]].

Pour démarrer la mise en place, on doit générer les certificats qui seront utilisés pour authentifier les différent composants du système <class>Sigul</class> entre eux. Le pont sera utilisé comme Autorité de Certification pour les communications internes du système <class>Sigul</class>.

=== Opérations avec le compte sigul ===

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash"># su - sigul</syntaxhighlight>
* Définition du répertoire de destination<syntaxhighlight lang="bash">bridge_dir=/var/lib/sigul/bridge</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$bridge_dir''<syntaxhighlight lang="bash">certutil -d $bridge_dir -N</syntaxhighlight>
* Génération de l'autorité de certification (CA: Certificate Authority) qui sera utilisée par tous les composants <class>Sigul</class><syntaxhighlight lang="bash">certutil -d $bridge_dir -S -n sigul-ca -s 'CN=Sigul CA' -t CT,, -x -v 120</syntaxhighlight>
* Génération d'un certificat pour le pont Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le pont est hebergé<syntaxhighlight lang="bash">certutil -d $bridge_dir -S -n sigul-bridge-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120</syntaxhighlight>

=== Opérations avec le compte root ===

Il est temps de configurer le pont en éditant le fichier <path>/etc/sigul/bridge.conf</path>

<pre>
[bridge]
bridge-cert-nickname: sigul-bridge-cert
client-listen-port: 44334
server-listen-port: 44333
max-rpms-payload-size: 10737418240

[koji]
koji-config: ~/.koji/config

[daemon]
unix-user: sigul
unix-group: sigul

[nss]
nss-dir: /var/lib/sigul/bridge
nss-password: bridgensspasswd
</pre>

=== Test ===

Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_bridge.log</path>
<syntaxhighlight lang="bash">sigul_bridge -v -v</syntaxhighlight>

Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.
{{Admon/note|Le premier message du fichier <path>/var/log/sigul_bridge.log</path> doit être
<pre>2011-11-24 16:41:42,214 DEBUG: Waiting for the client to connect</pre>}}

Arrêt du pont sigul CRTL-C

=== Démarrage ===

On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.

'''systemd'''
<syntaxhighlight lang="bash">
systemctl start sigul_bridge.service
systemctl enable sigul_bridge.service
</syntaxhighlight>
'''sysVinit'''
<syntaxhighlight lang="bash">
service sigul_bridge start
chkconfig sigul_bridge on
</syntaxhighlight>

== Mise en place du serveur ==

Le serveur est complètement isolé du reste du monde. Toutes les communications depuis l'extérieur doivent être interdites, exception faite des communications avec le pont. De même, les communications sortantes doivent être restreintes au pont pour un maximum de sécurité. Il faut s'assurer qu'aucun accès exterieur est possible (même web). Il détient toutes les clés pour signer les RPMs, et donc aucun utilisateur ne doit avoir accès directement aux clés, le serveur est le seul système qui connait les clés.

=== Opérations préalables sur le pont avec l'utilisateur sigul ===
* Export de l'autorité de certification dans le fichier <path>sigulca.p12</path><syntaxhighlight lang="bash">pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca</syntaxhighlight>
* Copie du fichier <path>sigulca.p12</path> sur le serveur <class>Sigul</class>
* Destruction de l'export<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>

=== Opérations avec l'utilisateur sigul ===

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash"># su - sigul</syntaxhighlight>
* Définition du répertoire de destination<syntaxhighlight lang="bash">server_dir=/var/lib/sigul/server</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$server_dir''<syntaxhighlight lang="bash">certutil -d $server_dir -N</syntaxhighlight>
* Import de l'autorité de certification (CA: Certificate Authority)<syntaxhighlight lang="bash">pk12util -d $server_dir -i sigulca.p12</syntaxhighlight><syntaxhighlight lang="bash">certutil -d $server_dir -M -n sigul-ca -t CT,,</syntaxhighlight>
* Génération d'un certificat pour le serveur Le champs CN doit être le nom complet de l'hôte (fqdn) sur lequel le serveur est hebergé<syntaxhighlight lang="bash">certutil -d $server_dir -S -n sigul-server-cert -s 'CN=koji.b2pweb.com' -c sigul-ca -t u,, -v 120</syntaxhighlight>
* Suppression de l'export de l'autorité de certification<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>
{{Admon/bug|Répertoire racine de gnupg|Bien que la configuration de sigul puisse être éditée,
<pre>_default_storage_path = '/var/lib/sigul/server'
default_gnupg_home = os.path.join(_default_storage_path, 'gnupg')
</pre>
il faut quand même rajouter un lien symbolique à la racine du répertoire personnel de sigul.
<pre>
cd /var/lib/sigul
ln -s /var/lib/sigul/server/gnupg gnupg
</pre>}}

=== Opérations avec l'utilisateur root ===

Il est temps de configurer le serveur en éditant le fichier <path>/etc/sigul/server.conf</path>.
<pre>
[server]
bridge-hostname: koji.didier-linux.eu
bridge-port: 44333
max-file-payload-size: 1073741824
max-memory-payload-size: 1048576
max-rpms-payload-size: 10737418240
server-cert-nickname: sigul-server-cert
signing-timeout: 60

[database]
database-path: /var/lib/sigul/server/server.sqlite

[gnupg]
gnupg-home: /var/lib/sigul/server/gnupg
gnupg-key-type: DSA
gnupg-key-length: 1024
gnupg-subkey-type: ELG-E
gnupg-subkey-length: 2048
gnupg-key-usage: sign
passphrase-length: 64

[daemon]
unix-user: sigul
unix-group: sigul

[nss]
nss-dir: /var/lib/sigul/server
nss-password: **********
</pre>

On va maintenant créer la base de données pour que le serveur y stocke les informations à propos des utilisateurs et des clés
<syntaxhighlight lang="bash">sigul_server_create_db</syntaxhighlight>

On va ajouter l'administrateur initial. Celui-ci doit déjà exister localement sur le système.
<syntaxhighlight lang="bash">sigul_server_add_admin</syntaxhighlight>

=== Test ===

Lancement en mode debug, les logs se trouvant dans le fichier <path>/var/log/sigul_server.log</path>
<syntaxhighlight lang="bash">sigul_server -v -v</syntaxhighlight>

Vérification du fichier journal et s'il n'y a pas d'erreur, on peut continuer.
{{Admon/note|You should see the first log message in <path>/var/log/sigul_server.log:</path>
<pre>2011-11-24 16:36:42,154 DEBUG: Waiting for a request</pre>}}

Arrêt du pont sigul CRTL-C

=== Démarrage ===

On peut maintenant lancer le deamon et activer son démarrage automatique au démarrage.

'''systemd'''
<syntaxhighlight lang="bash">
systemctl start sigul_server.service
systemctl enable sigul_server.service
</syntaxhighlight>
'''sysVinit'''
<syntaxhighlight lang="bash">
service sigul_server start
chkconfig sigul_server on
</syntaxhighlight>

== Mise en place du Client ==

Le client doit pouvoir s'authentifier sur le pont avec des certificats pour pouvoir envoyer des commandes à celui-ci.

=== Opérations préalables sur le pont avec l'utilisateur sigul ===

* Export de l'autorité de certification dans le fichier <path>sigulca.p12</path><syntaxhighlight lang="bash">pk12util -d $bridge_dir -o sigulca.p12 -n sigul-ca</syntaxhighlight>
* Copie du fichier <path>sigulca.p12</path> sur le client <class>Sigul</class> et modification du propriétaire sur celui-ci
* Destruction de l'export<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>

=== Opérations sur le client avec l'utilisateur root ===

Edition du fichier <path>/etc/sigul/client.conf</path>
<pre>
[client]
bridge-hostname: koji.b2pweb.com
bridge-port: 44334
client-cert-nickname: sigul-client-cert
server-hostname: koji.b2pweb.com

[koji]
koji-config: ~/.koji/config

[nss]
nss-dir: ~/.sigul
</pre>

=== Opérations sur le client avec l'utilisateur qui utilisera Sigul ===

* Définition du répertoire de destination<syntaxhighlight lang="bash">client_dir=~/.sigul</syntaxhighlight>
* Création de celui-ci<syntaxhighlight lang="bash">mkdir $client_dir</syntaxhighlight>
* Création de la base de données NSS, pour garder les informations des certificats, dans le répertoire de destination définit par la variable ''$client_dir''<syntaxhighlight lang="bash">certutil -d $client_dir -N</syntaxhighlight>
* Import de l'autorité de certification (CA: Certificate Authority)<syntaxhighlight lang="bash">pk12util -d $client_dir -i sigulca.p12</syntaxhighlight><syntaxhighlight lang="bash">certutil -d $client_dir -M -n sigul-ca -t CT,,</syntaxhighlight>
* Génération d'un certificat pour le serveur Le champs CN doit être le login de l'utilisateur pour le système <class>Sigul</class><syntaxhighlight lang="bash">certutil -d $client_dir -S -n sigul-client-cert -s 'CN=didier' -c sigul-ca -t u,, -v 120</syntaxhighlight>
* Suppression de l'export de l'autorité de certification<syntaxhighlight lang="bash">rm -f sigulca.p12</syntaxhighlight>
* Copie du fichier de configuration générale des clients <path>/etc/sigul/client.conf</path> dans son répertoire personnel <path>~/.sigul/client.conf</path><syntaxhighlight lang="bash">cp /etc/sigul/client.conf ~/.sigul/client.conf</syntaxhighlight>
* Édition du fichier <path>~/.sigul/client.conf</path> pour insérer le mot de passe de l'utilisateur dans la section [nss].<syntaxhighlight lang="bash">nss-password: Your NSS PASS</syntaxhighlight>

=== Test ===
Test avec une commande sigul pour valider le bon fonctionnement de toute la chaine
sigul list-users

On peut maintenant utiliser pleinement <class>Sigul</class>.

== Interfacer Sigul et koji ==

=== configuration ===

<class>Sigul</class> peut être utiliser pour signer un ou de multiples RPMs dans une instance <class>Koji</class>. Une fois le client Sigul correctement configuré, il suffit juste de configurer l'utilisateur Proxy pour Koji. Quand un client <class>Sigul</class> émet une requête de signature pour <class>Koji</class>, le pont <class>Sigul</class> se connecte à <class>Koji</class> en tant qu'utilisateur '''kojiweb'''. Il faut juste s'assurer que l'utilisateur demandeur a les droits administrateur sur le <class>Koji</class> et <class>Sigul</class> s'occupe du reste.

La configuration pour <class>Koji</class> peut être situer n'importe où, du moment que l'utilisateur sigul a droit de lecture. Les certificats pour '''kojiweb''' doivent être copiés dans le même chemin que la configuration <class>Koji</class>

* Comme toutes '''les commandes de cette partie doivent être lancées par l'utilisateur sigul''', on va donc devenir cet utilisateur<syntaxhighlight lang="bash">su - sigul</syntaxhighlight>
* Création du répertoire de configuration de <class>Koji</class><syntaxhighlight lang="bash">mkdir -p ~/.koji</syntaxhighlight>
* Copie de la configuration par défaut du client <class>Koji</class><syntaxhighlight lang="bash">cp /etc/koji.conf ~/.koji/config</syntaxhighlight>
* Copie des certificats {{class|Kojiweb}} dans celui-ci<syntaxhighlight lang="bash">cp /etc/pki/koji/pem/kojiweb.pem .koji/client.pem</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/clientca.crt</syntaxhighlight><syntaxhighlight lang="bash">cp /etc/pki/koji/kojica.crt .koji/serverca.crt</syntaxhighlight>

Après avoir redémarrer le pont <class>Sigul</class>, le client doit être capable d'obtenir un RPM depuis Koji et de le signer.

=== Test ===

Pour tester l'interfaçage, on va obtenir un RPM depuis <class>Koji</class>, le signer et le sauvegarder dans le répertoire de travail actuel. c'est juste pour tester la connxion et l'authentification sur <class>Koji</class> et <class>Sigul</class>.
<syntaxhighlight lang="bash">sigul sign-rpm -o signed.rpm key_name unsigned.rpm</syntaxhighlight>

Si la commande précédente fonctionne, un RPM signé est présent dans le répertoire de travail actuel.

On vérifie sa signature
<syntaxhighlight lang="bash">rpm --checksig signed.rpm</syntaxhighlight>

==Sigul Client Config Script==

Ce script peut être utilisé pour mettre en place rapidement l’authentification pour un client <class>Sigul</class> quand l’authentification FAS n'est pas utilisée.
{{Admon/important|L'utilisateur doit déjà être créé sur le serveur|Ce script ne fait que la mise en place des certificats.}}
<syntaxhighlight lang="bash">
#!/bin/bash
#Variables### And initial setup#######
mkdir ~/.sigul
client_dir=~/.sigul
user=$(whoami)
####################
echo
############################Begin Certificate imports
echo "======================="
echo "Setting up NSS Database"
echo "======================="
certutil -d $client_dir -N
echo
echo "==================="
echo "Downloading CA Cert"
echo "==================="
wget http://someurl.com/sigul/sigulca.p12 <-- Substitute with a path or url of your exported .p12
echo
echo "=================="
echo "Importing CA certs"
echo "=================="
pk12util -d $client_dir -i sigulca.p12
certutil -d $client_dir -M -n sigul-ca -t CT,,
echo
echo "======================"
echo "Generating Client cert"
echo "======================"
certutil -d $client_dir -S -n sigul-client-cert -s "CN=$user" -c sigul-ca -t u,, -v 120
echo
echo "======================"
#########End certificate imports########
########################################
#########NSS password Saver#############
read -p "Would you like to save your nss pass to ~/.sigul/client.conf [y/n]: " nsspasssel
#########User Input conditional#########
if [ $nsspasssel == "y" -o $nsspasssel == "Y" ]; then
echo "Enter your NSS password One more time: "
read -s nsspass
echo "[nss]" > ~/.sigul/client.conf
echo "nss-password: $nsspass" >> ~/.sigul/client.conf
echo
echo "==========="
echo "Cleaning up"
echo "==========="
rm sigulca.p12
else
echo
echo "==========="
echo "Cleaning up"
echo "==========="
rm sigulca.p12
fi
#########################################\
</syntaxhighlight>

== Utilisation ==
Utilisation de son [[Koji/SigulUsing|Sigul signing server]]

== Références ==
<references/>