TartareFR - Contributions [fr]

Services/Kerberos/Install

2018-01-31T08:50:31Z

Didier : /* Récapitulatif des outils d'utilisation et d'administration */

== Introduction ==

Le protocole Kerberos est issu du projet « Athena » du MIT, mené par Miller et Neuman. La version 5 du protocole Kerberos a été normalisée par l'IETF dans les RFC 1510 (septembre 1993) et 1964 (juin 1996). Le nom « Kerberos » provient provient de la mythologie grecque et correspond au nom du chien (en français « Cerbère ») protégeant l'accès aux portes d’Hadès.

L'objet de Kerberos est la mise en place de serveurs d'authentification ('''AS''' pour '''Authentication Server'''), permettant d'identifier des utilisateurs distants, et des serveurs de délivrement de tickets de service ('''TGS''', pour '''Ticket Granting System'''), permettant de les autoriser à accéder à des services réseau. Les clients peuvent aussi bien être des utilisateurs que des machines. La plupart du temps, les deux types de services sont regroupés sur un même serveur, appelé Centre de Distribution des Clés (ou '''KDC''', pour '''Key Distribution Center''').

== Fonctionnement ==

Le protocole Kerberos repose sur un système de cryptographie à base de clés secrètes (clés symétriques ou clés privées), avec l'algorithme DES. Kerberos partage avec chaque client du réseau une clé secrète faisant office de preuve d'identité.

Le principe de fonctionnement de Kerberos repose sur la notion de « tickets » :

[[Fichier:KerberosSimple.svg|800px]]
# Afin d'obtenir l'autorisation d'accès à un service, un utilisateur distant doit envoyer son identifiant au serveur d'authentification.
# Le serveur d'authentification vérifie que l'identifiant existe et envoie un ticket initial au client distant, chiffré avec la clé associée au client. Le ticket initial contient :
#* un clé de session, faisant office de mot de passe temporaire pour chiffrer les communications suivantes ;
#* un ticket d'accès au service de délivrement de ticket.
# Le client distant déchiffre le ticket initial avec sa clé et obtient ainsi un ticket et une clé de session.
# Grâce à son ticket et sa clé de session, le client distant peut envoyer une requête chiffrée, afin de demander l'accès à un service.

Par ailleurs, Kerberos propose un système d'authentification mutuelle permettant au client et au serveur de s'identifier réciproquement.

L'authentification proposée par le serveur Kerberos a une durée limitée dans le temps, ce qui permet d'éviter à un pirate de continuer d'avoir accès aux ressources : on parle ainsi d'anti re-jeu.

* Les comptes sont appelé '''principal''' pour kerberos. Ce peut être un utilisateur (ex: ''didier@TARTAREFR.EU''), un hôte (ex: ''kerberos.tartarefr.eu@TARTAREFR.EU''), un service (ex: ''http/kerberos.tartarefr.eu@TARTAREFR.EU''), etc...
* Un '''keytab''' (trousseau de clé) est un fichier où est encodé avec plusieurs algorithmes un ou plusieurs mots de passe.

== Pré-requis ==

* Les clients doivent avoir un nom d'hôte pleinement qualifié et resolvable via un serveur DNS ou via le fichier <path>/etc/hosts</path>
* Les heures doivent être synchronisées entre les serveurs (via <app>chronyd</app> ou <app>ntpd</app>)

== Installation du serveur ==

=== Installation ===
<pre>
yum install krb5-server krb5-workstation
</pre>

=== Configuration ===
{{Admon/tip|Rappel des conventions d'écriture|
* le nom de '''domaine''' est en minuscule (''didier.tartarefr.eu'')
* le nom du '''royaume''' est en majuscule (''DIDIER.TARTAREFR.EU'')
}}
Remplacement du domaine example.com par le notre dans les fichiers de configuration.
<pre>
sed -i -e 's/EXAMPLE.COM/DIDIER.TARTAREFR.EU/g' -e 's/example.com/didier.tartarefr.eu/g' /etc/krb5.conf
sed -i -e 's/EXAMPLE.COM/DIDIER.TARTAREFR.EU/g' /var/kerberos/krb5kdc/kdc.conf
sed -i -e 's/EXAMPLE.COM/DIDIER.TARTAREFR.EU/g' /var/kerberos/krb5kdc/kadm5.acl
</pre>

{{Admon/file|<path>/etc/krb5.conf</path>|
<syntaxhighlight lang="ini">
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = DIDIER.TARTAREFR.EU
default_ccache_name = KEYRING:persistent:%{uid}

[realms]
DIDIER.TARTAREFR.EU = {
kdc = kerberos.didier.tartarefr.eu
admin_server = kerberos.didier.tartarefr.eu
}

[domain_realm]
.didier.tartarefr.eu = DIDIER.TARTAREFR.EU
didier.tartarefr.eu = DIDIER.TARTAREFR.EU
</syntaxhighlight>}}

{{Admon/file|<path>/var/kerberos/krb5kdc/kdc.conf</path>|
<syntaxhighlight lang="ini">
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88

[realms]
DIDIER.TARTAREFR.EU = {
master_key_type = aes256-cts
#database_name = /var/kerberos/krb5kdc/principal
acl_file = /var/kerberos/krb5kdc/kadm5.acl
dict_file = /usr/share/dict/words
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
#default_principal_flags = +preauth
}
</syntaxhighlight>}}

{{Admon/file|<path>/var/kerberos/krb5kdc/kadm5.acl</path>|
<syntaxhighlight lang="ini">
*/admin@DIDIER.TARTAREFR.EU *
</syntaxhighlight>}}
Les droits d'administration sont fixés dans le fichier <path>/var/kerberos/krb5kdc/kadm5.acl</path> et sont sous la forme
<pre>principal permissions [target_principal [restrictions] ]</pre>
exemple
<pre>
*/admin@DIDIER.TARTAREFR.EU *
admin *
</pre>
Chaque champs peut avoir un joker ( astérisque *)
* '''principal''': Il spécifie tout ou partie d'un nom du compte kerberos
* '''permissions''': voir le tableau '''Permissions d'administration'''
* '''target_principal''': paramètre optionnel. Il spécifie tout ou partie de domaine Kerberos
* '''restrictions''': paramètre optionnel. C'est une chaine de caractère représentant les options. Les options possibles sont:
** {+|-}flagname: l'option est forcée à la valeur indiquée. Les options admissibles ici sont les mêmes que les permissions préfixés du signe + ou - (voir le tableau ''Permissions d'administration'')
** clearpolicy: la politique est forcé avec un paramètre vide (pas de politique)
** policy ''pol'': la politique est forcé au paramètre ''pol''
** -{expire, pwexpire, maxlife, maxrenewlife} ''time'': l'option est forcée à la valeur indiquée.

{|class="wikitable"
|+ Permissions d'administration
! Permission
! Commentaire
|-
| '''a'''
| [Dis]allows the addition of principals or policies
|-
| '''c'''
| [Dis]allows the changing of passwords for principals
|-
| '''d'''
| [Dis]allows the deletion of principals or policies
|-
| '''i'''
| [Dis]allows inquiries about principals or policies
|-
| '''l'''
| [Dis]allows the listing of principals or policies
|-
| '''m'''
| [Dis]allows the modification of principals or policies
|-
| '''p'''
| [Dis]allows the propagation of the principal database (used in Incremental database propagation)
|-
| '''s'''
| [Dis]allows the explicit setting of the key for a principal
|-
| '''x'''
| Short for admcil. All privileges
|-
| '''*'''
| Same as x.
|}

=== Initialisation ===
On créer la base de données. Cette étape peut être très longue s'il n'y a pas assez d'entropie. Pour s'assurer qu'il y en ai assez, on peut lancer la commande @find / 1>/dev/null 2>&1@ dans un autre shell afin d'en générer. A la fin, la commande demande la futur mot de passe de la base (xk0un7mysx)
<pre>
kdb5_util create -s
</pre>

On ouvre le firewall pour kerberos (port 88)
<pre>
firewall-cmd --permanent --add-service=kerberos
firewall-cmd --reload
</pre>

On démarre les services
<pre>
systemctl start krb5kdc
systemctl start kadmin
systemctl enable kadmin
systemctl enable krb5kdc
</pre>

=== Tests ===
On va lister les principals déjà disponibles
<pre>
kadmin.local
Authenticating as principal root/admin@DIDIER.TARTAREFR.EU with password.
kadmin.local: listprincs
K/M@DIDIER.TARTAREFR.EU
kadmin/admin@DIDIER.TARTAREFR.EU
kadmin/changepw@DIDIER.TARTAREFR.EU
kadmin/kerberos.didier.tartarefr.eu@DIDIER.TARTAREFR.EU
krbtgt/DIDIER.TARTAREFR.EU@DIDIER.TARTAREFR.EU
kadmin.local: exit
</pre>

Puis ajouter un principal pour l'utilisateur didier
<pre>
kadmin.local
kadmin.local: ank didier
WARNING: no policy specified for didier@DIDIER.TARTAREFR.EU; defaulting to no policy
Enter password for principal "didier@DIDIER.TARTAREFR.EU":
Re-enter password for principal "didier@DIDIER.TARTAREFR.EU":
Principal "didier@DIDIER.TARTAREFR.EU" created.
kadmin.local: exit
</pre>

On vérifie que l'utilisateur didier peut acquérir un jeton kerberos. Si la commande ne renvoie rien, c'est que ça s'est bien passé.
<pre>
kinit didier
</pre>

On liste les jetons distribués
<pre>
klist
Ticket cache: KEYRING:persistent:0:0
Default principal: didier@DIDIER.TARTAREFR.EU

Valid starting Expires Service principal
25/02/2015 10:47:09 26/02/2015 10:47:06 krbtgt/DIDIER.TARTAREFR.EU@DIDIER.TARTAREFR.EU
renew until 25/02/2015 10:47:09
</pre>

On vérifie que l'utilisateur didier ne peut que changer son mot de passe (politique par défaut)
<pre>
kadmin -p didier
Authenticating as principal didier with password.
Password for didier@DIDIER.TARTAREFR.EU:
kadmin: listprincs
get_principals: Operation requires ``list'' privilege while retrieving list.
kadmin: cpw didier
Enter password for principal "didier@DIDIER.TARTAREFR.EU":
Re-enter password for principal "didier@DIDIER.TARTAREFR.EU":
Password for "didier@DIDIER.TARTAREFR.EU" changed.
kadmin: exit
</pre>

'''Pour chaque hôte''' devant être géré par Kerberos
* on ajoute un principal avec un mot de passe aléatoire
* on l'exporte dans un keytab local (celui-ci sera copié dans un deuxième temps sur l'hôte concerné)
<pre>
kadmin.local
Authenticating as principal didier/admin@DIDIER.TARTAREFR.EU with password.

kadmin.local: ank -randkey host/test.didier.tartarefr.eu@DIDIER.TARTAREFR.EU
WARNING: no policy specified for host/test.didier.tartarefr.eu@DIDIER.TARTAREFR.EU; defaulting to no policy
Principal "host/test.didier.tartarefr.eu@DIDIER.TARTAREFR.EU" created.

kadmin.local: ktadd -k /tmp/krb5.keytab host/test.didier.tartarefr.eu
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type des3-cbc-sha1 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type arcfour-hmac added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type camellia256-cts-cmac added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type camellia128-cts-cmac added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type des-hmac-sha1 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type des-cbc-md5 added to keytab FILE:/tmp/krb5.keytab.

kadmin.local: exit
</pre>

On copie ensuite ce keytab local sur le client kerberos (serveur SSH, serveur web, etc...)

== Installation sur les clients ==

On installe les outils kerberos
<pre>
yum install krb5-workstation
</pre>

On édite (ou on copie le fichier depuis le serveur) /etc/krb5.conf

On ajoute un utilisateur système didier
<pre>
useradd -s /bin/bash -m didier
passwd didier
</pre>
On vérifie que l'utilisateur didier peut acquérir un jeton kerberos depuis ce client.
<pre>
kinit didier
</pre>

=== Connexion locale (PAM) ===

Installation du <class>PAM</class> (Pluggable Authentication Modules) <class>Kerberos</class> et activation.
<pre>
yum install pam_krb5
authconfig --enablekrb5 --update
</pre>

=== Client SSH ===

Comme SSH utilise PAM par défaut, le paquet <package>pam_krb5</package> doit être [[#Connexion_locale_.28PAM.29|installé et activé]].
{{Admon/tip|Utilisateurs pouvant se connecter au serveur|Seul les utilisateurs ayant un '''principal Kerberos''' et ayant un '''compte utilisateur sur le serveur SSH''' peuvent se connecter en SSH avec la méthode ''gssapi-with-mic''.}}

Il est possible de se [[Windows/Kerberos/Client|connecter en GSSAPI depuis un poste Windows]]

==== Sur le serveur Kerberos ====

On créé un principal qui aura accès à tous les serveurs. Il n'y a pas de nom mieux choisi que '''root'''.
# On créé le principal pour root<pre>kadmin.local -q "addprinc -randkey root"</pre>
# On s'assure que le fichier d'export n'existe pas encore<pre>rm -f /tmp/root.keytab</pre>
# On exporte ce principal<pre>kadmin.local -q "ktadd -k /tmp/root.keytab root"</pre>
# On copie dans <path>/root</path> du '''client''' l'export du principal root.

Pour chaque serveur SSH devant être géré par kerberos
# On créé un principal <nowiki>host/<FQDN></nowiki><pre>kadmin.local -q "addprinc -randkey host/server.tartarefr.eu"</pre>
# On s'assure que le fichier d'export n'existe pas encore<pre>rm -f /tmp/krb5.keytab</pre>
# On exporte ce principal (et uniquement lui pour des raisons de sécurité)<pre>kadmin.local -q "ktadd -k /tmp/krb5.keytab host/server.tartarefr.eu"</pre>
# On copie ce principal sur le '''serveur SSH'''<pre>scp /tmp/krb5.keytab server.tartarefr.eu:/etc/krb5.keytab</pre>
# On copie le fichier de configuration Kerberos sur le serveur SSH<pre>scp /etc/krb5.conf server.tartarefr.eu:/etc/krb5.conf</pre>

==== Sur le serveur SSH ====
* On lui spécifie explicitement le propriétaire/groupe de l'export du principal<pre>chown root:root /etc/krb5.keytab</pre>
* On lui spécifie les droits associés<pre>chmod 600 /etc/krb5.keytab</pre>

==== sur le client SSH ====
* On copie dans <path>/root</path> l'export du principal root.

==== Test de connexion ====

Avant de le fixer dans le fichier /etc/ssh/ssh_config, on teste
# On acquiert un jeton kerberos<pre>kinit -k -t /root/root.keytab root</pre>
# On se connecte par ssh en forçant l'option ''GSSAPIAuthentication''<pre>ssh root@server.tartarefr.eu -o "GSSAPIAuthentication yes" -o "PasswordAuthentication no"</pre>
# Si la connexion est un succès (sans mot de passe), on vérifie que le fichier <path>/etc/ssh/ssh_config</path> contient bien
#* <pre>GSSAPIAuthentication yes</pre>
#* <pre>GSSAPIDelegateCredentials yes</pre>

==== Debug ====

# Vérification de la synchronisation de l'heure<pre>date && hwclock</pre>
# Vérification des paramètres du fichier <path>/etc/ssh/sshd_config</path>
#* <pre>GSSAPIAuthentication yes</pre>
#* <pre>GSSAPIDelegateCredentials yes</pre>
# Vérification DNS
#* S'assurer que la résolution fonctionne correctement dans les deux sens<pre>getent hosts $(hostname) | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'</pre>
#* Vérification du fichier <path>/etc/hosts</path> sur le serveur SSH.<br>'''Il ne doit en aucun cas résoudre sur localhost'''.<br>Le premier nom d'hôte qui suit l'adresse IP (LAN/WAN) doit être le nom d'hôte pleinement qualifié, suivi du nom d'hôte simple.<br>Les alias (CNAME) ainsi que les noms d'hôte virtuels d'Apache peuvent être placé après.
# Vérification des fichiers
#* Vérification du fichier <path>/etc/krb5.conf</path> sur le serveur SSH
#** Le contenu attendu (c.a.d identique à celui du serveur Kerberos)
#** Le bon propriétaire et groupe<pre>chown root:root /etc/krb5.conf</pre>
#** Les bons droits<pre>chmod 644 /etc/krb5.conf</pre>
#* Vérification du fichier <path>/etc/krb5.keytab</path> sur le serveur SSH
#** Le contenu attendu, avec le nom d'hôte pleinement qualifié correspondant (préfixé par ''host/'') et le bon lvno (le numéro d'export qui est incrémenté à chaque fois)<pre>klist -k /etc/krb5.keytab</pre>
#** Le bon propriétaire et groupe<pre>chown root:root /etc/krb5.conf</pre>
#** Les bons droits<pre>chmod 600 /etc/krb5.conf</pre>

=== Authentification Apache ===

* Installation d'apache, du module ssl et du module d'authentification kerberos pour apache<pre>yum install httpd mod_ssl mod_auth_kerb</pre>
* Ajout d'un principal pour apache (mot de passe aléatoire)<pre>kadmin.local -q "addprinc -randkey http/didier.tartarefr.eu</pre>
* Export du principal dans un keytab<pre>kadmin.local -q "ktadd -k /etc/httpd/conf.d/http.keytab http/didier.tartarefr.eu"</pre>
* Modification du propriétaire du keytab car apache doit pouvoir lire ce fichier<pre>chown apache /etc/httpd/conf.d/http.keytab</pre>
* Vérification de la bonne configuration en obtenant un ticket kerberos manuellement<pre>kinit -k -t /etc/httpd/conf.d/http.keytab http/didier.tartarefr.eu</pre>
* Destruction du ticket avant de redémarrer le service <app>httpd</app><pre>kdestroy</pre>

Exemple de configuration apache
<syntaxhighlight lang="apache">
<Directory /var/www/html/kerb>
SSLRequireSSL
AuthType Kerberos
AuthName "Kerberos Authentication"
KrbAuthRealms DIDIER.TARTAREFR.EU
Krb5Keytab /etc/httpd/conf.d/http.keytab
KrbServiceName http/didier.tartarefr.eu
KrbMethodNegotiate Off
KrbSaveCredentials Off
KrbVerifyKDC Off
Require valid-user
</Directory>
</syntaxhighlight>

== Récapitulatif des outils d'utilisation et d'administration ==

* '''kinit''': Acquiert un nouveau jeton kerberos pour l'utilisateur passé en argument.
* '''kdestroy''': Efface le jeton de l'utilisateur actif (le nom passé en argument à kinit)
* '''klist''': Affiche la liste des jetons pour l'utilisateur actif
* '''kadmin''': Commande d'administration de kerberos.

== Sauvegarde / Restauration ==

L'utilitaire <app>kdb5_util</app> est utilisé pour la sauvegarde et la restauration: <path>/usr/sbin/kdb5_util</path>
* Sauvegarde dans le fichier krbsave <pre>kdb5_util dump krbsave</pre>
* Restauration à partir du fichier krbsave <pre>kdb5_util load krbsave</pre>On peut rajouter l'option <code>--update</code> pour mettre à jour uniquement une base existante à partir du la sauvegarde, au lieu de la vider.

== Références ==

* [http://fr.wikipedia.org/wiki/Kerberos_%28protocole%29 Page Wikipedia expliquant le protocole Kerberos]
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/Using_Kerberos.html Documentation RedHat de l'installation du serveur]
* [http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch11_04.htm Configuration du serveur SSH pour utiliser Kerberos]
* [http://unix.stackexchange.com/questions/90383/ssh-authentication-using-gssapi-keyex-or-gssapi-with-mic-publickey-not-permitte Debugging SSH authentication using gssapi-keyex or gssapi-with-mic]

MediaWiki:Sidebar

2017-11-10T15:12:41Z

Didier :

MediaWiki:Sidebar

2017-11-10T15:11:01Z

Didier :

MediaWiki:Sidebar

2017-11-10T15:10:21Z

Didier :

Services

2017-05-06T14:35:21Z

Didier : Page créée avec « {{Admon/button|width=200px|title=Base de données}} {{Admon/button|width=200px|title=DNS}} {{Admon/button|width=200px|title=voIP}} {{Admon/button|width=200px|title=Mail}}... »

{{Admon/button|width=200px|title=Base de données}}
{{Admon/button|width=200px|title=DNS}}
{{Admon/button|width=200px|title=voIP}}
{{Admon/button|width=200px|title=Mail}}
{{Admon/button|width=200px|title=Déploiement}}
{{Admon/button|width=200px|title=Virtualisation}}
{{Admon/button|width=200px|title=Web}}
{{Admon/button|width=200px|title=Cluster}}
{{Admon/button|width=200px|title=Monitoring}}
{{Admon/button|width=200px|title=Sécurité}}

Modèle:Admon/button

2017-05-06T14:28:19Z

Didier :

<span class="effect3d" style="display:inline-block;text-align:center;background-color:#f6f6f6;padding:5px 8px;margin:2px;border:#A7D7F9 2px solid;border-radius:6px;width:{{{width|120px}}};font-weight:bold;font-size:16px;line-height:{{{iconsize|16}}}px;padding:10px;">
<span style="position:relative;top:-2px;">{{#if:{{{icon|}}}|[[Fichier:{{{icon}}}|link=|alt=]]|[[Fichier:IconLinux32.png|link=|alt=]]}}</span>
<span>[[{{{link|Accueil}}}|{{{title|Title}}}]]</span>
</span>

Services/FTP/SFTP

2017-05-06T09:49:06Z

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 obligat... »

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 obligatoire, 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 SELinux, 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

Services/Kerberos/Install

2017-05-06T09:45:19Z

Didier : Page créée avec « == Introduction == Le protocole Kerberos est issu du projet « Athena » du MIT, mené par Miller et Neuman. La version 5 du protocole Kerberos a été normalisée par l'... »

== Introduction ==

Le protocole Kerberos est issu du projet « Athena » du MIT, mené par Miller et Neuman. La version 5 du protocole Kerberos a été normalisée par l'IETF dans les RFC 1510 (septembre 1993) et 1964 (juin 1996). Le nom « Kerberos » provient provient de la mythologie grecque et correspond au nom du chien (en français « Cerbère ») protégeant l'accès aux portes d’Hadès.

L'objet de Kerberos est la mise en place de serveurs d'authentification ('''AS''' pour '''Authentication Server'''), permettant d'identifier des utilisateurs distants, et des serveurs de délivrement de tickets de service ('''TGS''', pour '''Ticket Granting System'''), permettant de les autoriser à accéder à des services réseau. Les clients peuvent aussi bien être des utilisateurs que des machines. La plupart du temps, les deux types de services sont regroupés sur un même serveur, appelé Centre de Distribution des Clés (ou '''KDC''', pour '''Key Distribution Center''').

== Fonctionnement ==

Le protocole Kerberos repose sur un système de cryptographie à base de clés secrètes (clés symétriques ou clés privées), avec l'algorithme DES. Kerberos partage avec chaque client du réseau une clé secrète faisant office de preuve d'identité.

Le principe de fonctionnement de Kerberos repose sur la notion de « tickets » :

[[Fichier:KerberosSimple.svg|800px]]
# Afin d'obtenir l'autorisation d'accès à un service, un utilisateur distant doit envoyer son identifiant au serveur d'authentification.
# Le serveur d'authentification vérifie que l'identifiant existe et envoie un ticket initial au client distant, chiffré avec la clé associée au client. Le ticket initial contient :
#* un clé de session, faisant office de mot de passe temporaire pour chiffrer les communications suivantes ;
#* un ticket d'accès au service de délivrement de ticket.
# Le client distant déchiffre le ticket initial avec sa clé et obtient ainsi un ticket et une clé de session.
# Grâce à son ticket et sa clé de session, le client distant peut envoyer une requête chiffrée, afin de demander l'accès à un service.

Par ailleurs, Kerberos propose un système d'authentification mutuelle permettant au client et au serveur de s'identifier réciproquement.

L'authentification proposée par le serveur Kerberos a une durée limitée dans le temps, ce qui permet d'éviter à un pirate de continuer d'avoir accès aux ressources : on parle ainsi d'anti re-jeu.

* Les comptes sont appelé '''principal''' pour kerberos. Ce peut être un utilisateur (ex: ''didier@TARTAREFR.EU''), un hôte (ex: ''kerberos.tartarefr.eu@TARTAREFR.EU''), un service (ex: ''http/kerberos.tartarefr.eu@TARTAREFR.EU''), etc...
* Un '''keytab''' (trousseau de clé) est un fichier où est encodé avec plusieurs algorithmes un ou plusieurs mots de passe.

== Pré-requis ==

* Les clients doivent avoir un nom d'hôte pleinement qualifié et resolvable via un serveur DNS ou via le fichier <path>/etc/hosts</path>
* Les heures doivent être synchronisées entre les serveurs (via <app>chronyd</app> ou <app>ntpd</app>)

== Installation du serveur ==

=== Installation ===
<pre>
yum install krb5-server krb5-workstation
</pre>

=== Configuration ===
{{Admon/tip|Rappel des conventions d'écriture|
* le nom de '''domaine''' est en minuscule (''didier.tartarefr.eu'')
* le nom du '''royaume''' est en majuscule (''DIDIER.TARTAREFR.EU'')
}}
Remplacement du domaine example.com par le notre dans les fichiers de configuration.
<pre>
sed -i -e 's/EXAMPLE.COM/DIDIER.TARTAREFR.EU/g' -e 's/example.com/didier.tartarefr.eu/g' /etc/krb5.conf
sed -i -e 's/EXAMPLE.COM/DIDIER.TARTAREFR.EU/g' /var/kerberos/krb5kdc/kdc.conf
sed -i -e 's/EXAMPLE.COM/DIDIER.TARTAREFR.EU/g' /var/kerberos/krb5kdc/kadm5.acl
</pre>

{{Admon/file|<path>/etc/krb5.conf</path>|
<syntaxhighlight lang="ini">
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = DIDIER.TARTAREFR.EU
default_ccache_name = KEYRING:persistent:%{uid}

[realms]
DIDIER.TARTAREFR.EU = {
kdc = kerberos.didier.tartarefr.eu
admin_server = kerberos.didier.tartarefr.eu
}

[domain_realm]
.didier.tartarefr.eu = DIDIER.TARTAREFR.EU
didier.tartarefr.eu = DIDIER.TARTAREFR.EU
</syntaxhighlight>}}

{{Admon/file|<path>/var/kerberos/krb5kdc/kdc.conf</path>|
<syntaxhighlight lang="ini">
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88

[realms]
DIDIER.TARTAREFR.EU = {
master_key_type = aes256-cts
#database_name = /var/kerberos/krb5kdc/principal
acl_file = /var/kerberos/krb5kdc/kadm5.acl
dict_file = /usr/share/dict/words
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
#default_principal_flags = +preauth
}
</syntaxhighlight>}}

{{Admon/file|<path>/var/kerberos/krb5kdc/kadm5.acl</path>|
<syntaxhighlight lang="ini">
*/admin@DIDIER.TARTAREFR.EU *
</syntaxhighlight>}}
Les droits d'administration sont fixés dans le fichier <path>/var/kerberos/krb5kdc/kadm5.acl</path> et sont sous la forme
<pre>principal permissions [target_principal [restrictions] ]</pre>
exemple
<pre>
*/admin@DIDIER.TARTAREFR.EU *
admin *
</pre>
Chaque champs peut avoir un joker ( astérisque *)
* '''principal''': Il spécifie tout ou partie d'un nom du compte kerberos
* '''permissions''': voir le tableau '''Permissions d'administration'''
* '''target_principal''': paramètre optionnel. Il spécifie tout ou partie de domaine Kerberos
* '''restrictions''': paramètre optionnel. C'est une chaine de caractère représentant les options. Les options possibles sont:
** {+|-}flagname: l'option est forcée à la valeur indiquée. Les options admissibles ici sont les mêmes que les permissions préfixés du signe + ou - (voir le tableau ''Permissions d'administration'')
** clearpolicy: la politique est forcé avec un paramètre vide (pas de politique)
** policy ''pol'': la politique est forcé au paramètre ''pol''
** -{expire, pwexpire, maxlife, maxrenewlife} ''time'': l'option est forcée à la valeur indiquée.

{|class="wikitable"
|+ Permissions d'administration
! Permission
! Commentaire
|-
| '''a'''
| [Dis]allows the addition of principals or policies
|-
| '''c'''
| [Dis]allows the changing of passwords for principals
|-
| '''d'''
| [Dis]allows the deletion of principals or policies
|-
| '''i'''
| [Dis]allows inquiries about principals or policies
|-
| '''l'''
| [Dis]allows the listing of principals or policies
|-
| '''m'''
| [Dis]allows the modification of principals or policies
|-
| '''p'''
| [Dis]allows the propagation of the principal database (used in Incremental database propagation)
|-
| '''s'''
| [Dis]allows the explicit setting of the key for a principal
|-
| '''x'''
| Short for admcil. All privileges
|-
| '''*'''
| Same as x.
|}

=== Initialisation ===
On créer la base de données. Cette étape peut être très longue s'il n'y a pas assez d'entropie. Pour s'assurer qu'il y en ai assez, on peut lancer la commande @find / 1>/dev/null 2>&1@ dans un autre shell afin d'en générer. A la fin, la commande demande la futur mot de passe de la base (xk0un7mysx)
<pre>
kdb5_util create -s
</pre>

On ouvre le firewall pour kerberos (port 88)
<pre>
firewall-cmd --permanent --add-service=kerberos
firewall-cmd --reload
</pre>

On démarre les services
<pre>
systemctl start krb5kdc
systemctl start kadmin
systemctl enable kadmin
systemctl enable krb5kdc
</pre>

=== Tests ===
On va lister les principals déjà disponibles
<pre>
kadmin.local
Authenticating as principal root/admin@DIDIER.TARTAREFR.EU with password.
kadmin.local: listprincs
K/M@DIDIER.TARTAREFR.EU
kadmin/admin@DIDIER.TARTAREFR.EU
kadmin/changepw@DIDIER.TARTAREFR.EU
kadmin/kerberos.didier.tartarefr.eu@DIDIER.TARTAREFR.EU
krbtgt/DIDIER.TARTAREFR.EU@DIDIER.TARTAREFR.EU
kadmin.local: exit
</pre>

Puis ajouter un principal pour l'utilisateur didier
<pre>
kadmin.local
kadmin.local: ank didier
WARNING: no policy specified for didier@DIDIER.TARTAREFR.EU; defaulting to no policy
Enter password for principal "didier@DIDIER.TARTAREFR.EU":
Re-enter password for principal "didier@DIDIER.TARTAREFR.EU":
Principal "didier@DIDIER.TARTAREFR.EU" created.
kadmin.local: exit
</pre>

On vérifie que l'utilisateur didier peut acquérir un jeton kerberos. Si la commande ne renvoie rien, c'est que ça s'est bien passé.
<pre>
kinit didier
</pre>

On liste les jetons distribués
<pre>
klist
Ticket cache: KEYRING:persistent:0:0
Default principal: didier@DIDIER.TARTAREFR.EU

Valid starting Expires Service principal
25/02/2015 10:47:09 26/02/2015 10:47:06 krbtgt/DIDIER.TARTAREFR.EU@DIDIER.TARTAREFR.EU
renew until 25/02/2015 10:47:09
</pre>

On vérifie que l'utilisateur didier ne peut que changer son mot de passe (politique par défaut)
<pre>
kadmin -p didier
Authenticating as principal didier with password.
Password for didier@DIDIER.TARTAREFR.EU:
kadmin: listprincs
get_principals: Operation requires ``list'' privilege while retrieving list.
kadmin: cpw didier
Enter password for principal "didier@DIDIER.TARTAREFR.EU":
Re-enter password for principal "didier@DIDIER.TARTAREFR.EU":
Password for "didier@DIDIER.TARTAREFR.EU" changed.
kadmin: exit
</pre>

'''Pour chaque hôte''' devant être géré par Kerberos
* on ajoute un principal avec un mot de passe aléatoire
* on l'exporte dans un keytab local (celui-ci sera copié dans un deuxième temps sur l'hôte concerné)
<pre>
kadmin.local
Authenticating as principal didier/admin@DIDIER.TARTAREFR.EU with password.

kadmin.local: ank -randkey host/test.didier.tartarefr.eu@DIDIER.TARTAREFR.EU
WARNING: no policy specified for host/test.didier.tartarefr.eu@DIDIER.TARTAREFR.EU; defaulting to no policy
Principal "host/test.didier.tartarefr.eu@DIDIER.TARTAREFR.EU" created.

kadmin.local: ktadd -k /tmp/krb5.keytab host/test.didier.tartarefr.eu
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type des3-cbc-sha1 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type arcfour-hmac added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type camellia256-cts-cmac added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type camellia128-cts-cmac added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type des-hmac-sha1 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type des-cbc-md5 added to keytab FILE:/tmp/krb5.keytab.

kadmin.local: exit
</pre>

On copie ensuite ce keytab local sur le client kerberos (serveur SSH, serveur web, etc...)

== Installation sur les clients ==

On installe les outils kerberos
<pre>
yum install krb5-workstation
</pre>

On édite (ou on copie le fichier depuis le serveur) /etc/krb5.conf

On ajoute un utilisateur système didier
<pre>
useradd -s /bin/bash -m didier
passwd didier
</pre>
On vérifie que l'utilisateur didier peut acquérir un jeton kerberos depuis ce client.
<pre>
kinit didier
</pre>

=== Connexion locale (PAM) ===

Installation du <class>PAM</class> (Pluggable Authentication Modules) <class>Kerberos</class> et activation.
<pre>
yum install pam_krb5
authconfig --enablekrb5 --update
</pre>

=== Client SSH ===

Comme SSH utilise PAM par défaut, le paquet <package>pam_krb5</package> doit être [[#Connexion_locale_.28PAM.29|installé et activé]].
{{Admon/tip|Utilisateurs pouvant se connecter au serveur|Seul les utilisateurs ayant un '''principal Kerberos''' et ayant un '''compte utilisateur sur le serveur SSH''' peuvent se connecter en SSH avec la méthode ''gssapi-with-mic''.}}

Il est possible de se [[Windows/Kerberos/Client|connecter en GSSAPI depuis un poste Windows]]

==== Sur le serveur Kerberos ====

On créé un principal qui aura accès à tous les serveurs. Il n'y a pas de nom mieux choisi que '''root'''.
# On créé le principal pour root<pre>kadmin.local -q "addprinc -randkey root"</pre>
# On s'assure que le fichier d'export n'existe pas encore<pre>rm -f /tmp/root.keytab</pre>
# On exporte ce principal<pre>kadmin.local -q "ktadd -k /tmp/root.keytab root"</pre>
# On copie dans <path>/root</path> du '''client''' l'export du principal root.

Pour chaque serveur SSH devant être géré par kerberos
# On créé un principal <nowiki>host/<FQDN></nowiki><pre>kadmin.local -q "addprinc -randkey host/server.tartarefr.eu"</pre>
# On s'assure que le fichier d'export n'existe pas encore<pre>rm -f /tmp/krb5.keytab</pre>
# On exporte ce principal (et uniquement lui pour des raisons de sécurité)<pre>kadmin.local -q "ktadd -k /tmp/krb5.keytab host/server.tartarefr.eu"</pre>
# On copie ce principal sur le '''serveur SSH'''<pre>scp /tmp/krb5.keytab server.tartarefr.eu:/etc/krb5.keytab</pre>
# On copie le fichier de configuration Kerberos sur le serveur SSH<pre>scp /etc/krb5.conf server.tartarefr.eu:/etc/krb5.conf</pre>

==== Sur le serveur SSH ====
* On lui spécifie explicitement le propriétaire/groupe de l'export du principal<pre>chown root:root /etc/krb5.keytab</pre>
* On lui spécifie les droits associés<pre>chmod 600 /etc/krb5.keytab</pre>

==== sur le client SSH ====
* On copie dans <path>/root</path> l'export du principal root.

==== Test de connexion ====

Avant de le fixer dans le fichier /etc/ssh/ssh_config, on teste
# On acquiert un jeton kerberos<pre>kinit -k -t /root/root.keytab root</pre>
# On se connecte par ssh en forçant l'option ''GSSAPIAuthentication''<pre>ssh root@server.tartarefr.eu -o "GSSAPIAuthentication yes" -o "PasswordAuthentication no"</pre>
# Si la connexion est un succès (sans mot de passe), on vérifie que le fichier <path>/etc/ssh/ssh_config</path> contient bien
#* <pre>GSSAPIAuthentication yes</pre>
#* <pre>GSSAPIDelegateCredentials yes</pre>

==== Debug ====

# Vérification de la synchronisation de l'heure<pre>date && hwclock</pre>
# Vérification des paramètres du fichier <path>/etc/ssh/sshd_config</path>
#* <pre>GSSAPIAuthentication yes</pre>
#* <pre>GSSAPIDelegateCredentials yes</pre>
# Vérification DNS
#* S'assurer que la résolution fonctionne correctement dans les deux sens<pre>getent hosts $(hostname) | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'</pre>
#* Vérification du fichier <path>/etc/hosts</path> sur le serveur SSH.<br>'''Il ne doit en aucun cas résoudre sur localhost'''.<br>Le premier nom d'hôte qui suit l'adresse IP (LAN/WAN) doit être le nom d'hôte pleinement qualifié, suivi du nom d'hôte simple.<br>Les alias (CNAME) ainsi que les noms d'hôte virtuels d'Apache peuvent être placé après.
# Vérification des fichiers
#* Vérification du fichier <path>/etc/krb5.conf</path> sur le serveur SSH
#** Le contenu attendu (c.a.d identique à celui du serveur Kerberos)
#** Le bon propriétaire et groupe<pre>chown root:root /etc/krb5.conf</pre>
#** Les bons droits<pre>chmod 644 /etc/krb5.conf</pre>
#* Vérification du fichier <path>/etc/krb5.keytab</path> sur le serveur SSH
#** Le contenu attendu, avec le nom d'hôte pleinement qualifié correspondant (préfixé par ''host/'') et le bon lvno (le numéro d'export qui est incrémenté à chaque fois)<pre>klist -k /etc/krb5.keytab</pre>
#** Le bon propriétaire et groupe<pre>chown root:root /etc/krb5.conf</pre>
#** Les bons droits<pre>chmod 600 /etc/krb5.conf</pre>

=== Authentification Apache ===

* Installation d'apache, du module ssl et du module d'authentification kerberos pour apache<pre>yum install httpd mod_ssl mod_auth_kerb</pre>
* Ajout d'un principal pour apache (mot de passe aléatoire)<pre>kadmin.local -q "addprinc -randkey http/didier.tartarefr.eu</pre>
* Export du principal dans un keytab<pre>kadmin.local -q "ktadd -k /etc/httpd/conf.d/http.keytab http/didier.tartarefr.eu"</pre>
* Modification du propriétaire du keytab car apache doit pouvoir lire ce fichier<pre>chown apache /etc/httpd/conf.d/http.keytab</pre>
* Vérification de la bonne configuration en obtenant un ticket kerberos manuellement<pre>kinit -k -t /etc/httpd/conf.d/http.keytab http/didier.tartarefr.eu</pre>
* Destruction du ticket avant de redémarrer le service <app>httpd</app><pre>kdestroy</pre>

Exemple de configuration apache
<syntaxhighlight lang="apache">
<Directory /var/www/html/kerb>
SSLRequireSSL
AuthType Kerberos
AuthName "Kerberos Authentication"
KrbAuthRealms DIDIER.TARTAREFR.EU
Krb5Keytab /etc/httpd/conf.d/http.keytab
KrbServiceName http/didier.tartarefr.eu
KrbMethodNegotiate Off
KrbSaveCredentials Off
KrbVerifyKDC Off
Require valid-user
</Directory>
</syntaxhighlight>

== Récapitulatif des outils d'utilisation et d'administration ==

* '''kinit''': Acquiert un nouveau jeton kerberos pour l'utilisateur passé en argument.
* '''kdestroy''': Efface le jeton de l'utilisateur actif (le nom passé en argument à kinit)
* '''klist''': Affiche la liste des jetons pour l'utilisateur actif
* '''kadmin''': Commande d'administration de kerberos.

== Références ==

* [http://fr.wikipedia.org/wiki/Kerberos_%28protocole%29 Page Wikipedia expliquant le protocole Kerberos]
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/Using_Kerberos.html Documentation RedHat de l'installation du serveur]
* [http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch11_04.htm Configuration du serveur SSH pour utiliser Kerberos]
* [http://unix.stackexchange.com/questions/90383/ssh-authentication-using-gssapi-keyex-or-gssapi-with-mic-publickey-not-permitte Debugging SSH authentication using gssapi-keyex or gssapi-with-mic]

Fichier:KerberosSimple.svg

2017-05-06T09:44:39Z

Didier : Workflow du protocole Kerberos

Workflow du protocole Kerberos

Koji/SigulUsing

2017-04-21T07:07:11Z

Didier : Page créée avec « == Sigul == après une installation de Sigul, on peut l'utiliser. {{Admon/note|Commandes disponible|<pre>$ sigul --help-commands delete-key... »

== 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='didier@tartarefr.eu' --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) <didier@tartarefr.eu>
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.tartarefr.eu/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.tartarefr.eu/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

2017-04-21T07:03:36Z

Didier : /* Mise en place du pont */

== 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>}}

== 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 10.0.0.10/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 [[RPM#Infrastructure_de_construction_de_RPM:_Koji|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<br>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.tartarefr.eu' -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<br>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.tartarefr.eu' -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<br>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

2017-04-21T07:02:11Z

Didier : /* Mise en place du pont */

== 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>}}

== 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 10.0.0.10/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 [[/RPM#Infrastructure_de_construction_de_RPM:_Koji|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<br>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.tartarefr.eu' -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<br>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.tartarefr.eu' -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<br>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/>

RPM

2017-04-21T07:00:34Z

Didier : /* Koji */

{{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]]

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

== Environnement de construction ==
* [[RPM/Environnement|Building Environment]]

== Infrastructure de construction de RPM: Koji ==

=== Installation d'un serveur Koji personnel ===
* [[Koji/Installation|Installation d'un serveur Koji]] pas à pas avec l’authentification SSL.
* Installation d'un repository avec [[RPM/Mash|Mash]]

=== Bootstrap de son serveur Koji ===
* [[Koji/Bootstrap|Bootstrap de Koji]]

=== Utilisation de son serveur Koji ===
* [[Koji/Utilisation|Utilisation de Koji]]
* [[Koji/CLI|Utilisation du client Koji en ligne de commande]]

== Serveur de signature: sigul ==
* [[Koji/SigulInstall|Installation d'un Serveur de Signature Sigul]]
* [[Koji/SigulUsing|Utilisation du Serveur de Signature Sigul]]

Fichier:SigulArch.svg

2017-04-21T06:59:14Z

Didier : Architecture d'un serveur Sigul

Architecture d'un serveur Sigul

Koji/SigulInstall

2017-04-21T06:54:14Z

Didier : Page créée avec « == 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 c... »

== 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>}}

== 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 10.0.0.10/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<br>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.tartarefr.eu' -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<br>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.tartarefr.eu' -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<br>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/CLI

2017-04-20T10:34:33Z

Didier : Page créée avec « == Commandes générales == <pre> koji help Available commands: build Build a package from source buildinfo Print basic... »

== Commandes générales ==
<pre>
koji help
Available commands:
build Build a package from source
buildinfo Print basic information about a build
cancel Cancel tasks and/or builds
chain-build Build one or more packages from source
download-build Download a built package
help List available commands
import-comps Import group/package information from a comps file
latest-by-tag Print the latest packages for each tag
latest-pkg Print the latest packages for a tag
list-api Print the list of XML-RPC APIs
list-buildroot List the rpms used in or built in a buildroot
list-external-repos List external repos
list-groups Print the group listings
list-history Display historical data
list-hosts Print the host listing
list-pkgs Print the package listing for tag or for owner
list-tag-history Print a history of tag operations
list-tag-inheritance Print the inheritance information for a tag
list-tagged List the builds or rpms in a tag
list-tags Print the list of tags
list-targets List the build targets
list-tasks Print the list of tasks
list-untagged List untagged builds
list-volumes List storage volumes
maven-build Build a Maven package from source
mock-config Create a mock config
moshimoshi Introduce yourself
move-pkg 'Move' one or more packages between tags
resubmit Retry a canceled or failed task, using the same parameter as the original task.
rpminfo Print basic information about an RPM
search Search the system
show-groups Show groups data for a tag
tag-pkg Apply a tag to one or more packages
taginfo Print basic information about a tag
taskinfo Show information about a task
untag-pkg Remove a tag from one or more packages
wait-repo Wait for a repo to be regenerated
watch-logs Watch logs in realtime
watch-task Track progress of particular tasks
win-build Build a Windows package from source
wrapper-rpm Build wrapper rpms for any archives associated with a build.
(Type "koji --help" for help about global options
or "koji <command> --help" for help about a particular command's options
or "koji help --admin" for help about privileged administrative commands.)
</pre>

== Commandes d'administration ==
<pre>
koji help --admin
Available commands:
add-external-repo Create an external repo and/or add one to a tag
add-group Add a group to a tag
add-group-pkg Add a package to a group's package listing
add-group-req Add a group to a group's required list
add-host Add a host
add-host-to-channel Add a host to a channel
add-pkg Add a package to the listing for tag
add-tag Add a new tag to the database
add-tag-inheritance Add to a tag's inheritance
add-target Create a new build target
add-user Add a user
add-volume Add a new storage volume
block-group-pkg Block a package from a group's package listing
block-group-req Block a group's requirement listing
block-pkg Block a package in the listing for tag
build Build a package from source
buildinfo Print basic information about a build
call Execute an arbitrary XML-RPC call
cancel Cancel tasks and/or builds
chain-build Build one or more packages from source
clone-tag Duplicate the contents of one tag onto another tag
disable-host Mark one or more hosts as disabled
disable-user Disable logins by a user
download-build Download a built package
edit-external-repo Edit data for an external repo
edit-host Edit a host
edit-tag Alter tag information
edit-tag-inheritance Edit tag inheritance
edit-target Set the name, build_tag, and/or dest_tag of an existing build target to new values
enable-host Mark one or more hosts as enabled
enable-user Enable logins by a user
free-task Free a task
grant-permission Grant a permission to a user
help List available commands
import Import externally built RPMs into the database
import-archive Import an archive file and associate it with a build
import-comps Import group/package information from a comps file
import-in-place Import RPMs that are already in place
import-sig Import signatures into the database
latest-by-tag Print the latest packages for each tag
latest-pkg Print the latest packages for a tag
list-api Print the list of XML-RPC APIs
list-buildroot List the rpms used in or built in a buildroot
list-external-repos List external repos
list-groups Print the group listings
list-history Display historical data
list-hosts Print the host listing
list-permissions List user permissions
list-pkgs Print the package listing for tag or for owner
list-signed List signed copies of rpms
list-tag-history Print a history of tag operations
list-tag-inheritance Print the inheritance information for a tag
list-tagged List the builds or rpms in a tag
list-tags Print the list of tags
list-targets List the build targets
list-tasks Print the list of tasks
list-untagged List untagged builds
list-volumes List storage volumes
lock-tag Lock a tag
make-task Create an arbitrary task
maven-build Build a Maven package from source
mock-config Create a mock config
moshimoshi Introduce yourself
move-pkg 'Move' one or more packages between tags
prune-signed-copies Prune signed copies
regen-repo Force a repo to be regenerated
remove-channel Remove a channel entirely
remove-external-repo Remove an external repo from a tag or tags, or remove entirely
remove-host-from-channel Remove a host from a channel
remove-tag Remove a tag
remove-tag-inheritance Remove a tag inheritance link
remove-target Remove a build target
rename-channel Rename a channel
restart-hosts Restart enabled hosts
resubmit Retry a canceled or failed task, using the same parameter as the original task.
revoke-permission Revoke a permission from a user
rpminfo Print basic information about an RPM
search Search the system
set-build-volume Move a build to a different volume
set-pkg-arches Set the list of extra arches for a package
set-pkg-owner Set the owner for a package
set-pkg-owner-global Set the owner for a package globally
set-task-priority Set task priority
show-groups Show groups data for a tag
spin-appliance Create an appliance given a kickstart file
spin-livecd Create a live CD image given a kickstart file
tag-pkg Apply a tag to one or more packages
taginfo Print basic information about a tag
taskinfo Show information about a task
unblock-group-pkg Unblock a package from a group's package listing
unblock-group-req Unblock a group's requirement listing
unblock-pkg Unblock a package in the listing for tag
unlock-tag Unlock a tag
untag-pkg Remove a tag from one or more packages
wait-repo Wait for a repo to be regenerated
watch-logs Watch logs in realtime
watch-task Track progress of particular tasks
win-build Build a Windows package from source
wrapper-rpm Build wrapper rpms for any archives associated with a build.
write-signed-rpm Write signed RPMs to disk
(Type "koji --help" for help about global options
or "koji <command> --help" for help about a particular command's options
or "koji help --admin" for help about privileged administrative commands.)
</pre>

Fichier:KojiwebScreenshot.png

2017-04-20T10:32:39Z

Didier : Photo d'écran de kojiweb (https://koji.fedoraproject.org/koji/)

Photo d'écran de kojiweb (https://koji.fedoraproject.org/koji/)

Fichier:LogoKoji.svg

2017-04-20T10:23:29Z

Didier : Logo Koji

Logo Koji

Koji/Utilisation

2017-04-20T10:20:01Z

Didier : Page créée avec « droite == Généralités == === Ajout d'un paquet au repository === Un admin du koji ajoute le paquet et le place sous la responsabil... »

[[Fichier:LogoKoji.svg|sans_cadre|droite]]

== Généralités ==

=== Ajout d'un paquet au repository ===
Un admin du koji ajoute le paquet et le place sous la responsabilité d'un utilisateur Koji
koji add-pkg --owner didier centos-5 didier-release
{{Admon/tip|Construction d'un paquet scratch|
Koji permet de construire des paquets sans qu'il soit nécessaire de les ajouter au repository: c'est le '''scratch build'''

La commande de construction devient donc
<pre>koji build --scratch centos-5 didier-release-1.0.0-1.fc17.src.rpm</pre>
Toutefois cette méthode n'est pas recommandé si on cherche à construire un paquet pour notre dépôt (hors test).}}

=== Construction d'un paquet ===

==== Depuis un paquet source ====
koji build centos-5 didier-release-1.0.0-1.fc17.src.rpm

==== Depuis un système de contrôle de version ====

Il faut tout d'abord autoriser le serveur et le dépôt sur '''tous les constructeurs''' koji ( kojid ).

Ici on déclare deux dépôts de sources:
* dépôt '''GIT''': ''git://didier.tartarefr.eu/rpm''
* dépôt '''SVN''': ''<nowiki>http://didier.tartarefr.eu/svn/rpm</nowiki>''<br>Celui-ci étant composé d'un arbre SVN standard, on déclare le répertoire ''trunk''.
''
Extrait du fichier <path>/etc/kojid/kojid.conf</path>
; A space-separated list of hostname:repository[:use_common] tuples that kojid is authorized to checkout from (no quotes).
; Wildcards (as supported by fnmatch) are allowed.
; If use_common is specified and is one of "false", "no", "off", or "0" (without quotes), then kojid will not attempt to checkout
; a common/ dir when checking out sources from the source control system. Otherwise, it will attempt to checkout a common/
; dir, and will raise an exception if it cannot.
allowed_scms=didier.tartarefr.eu:/rpm:no didier.tartarefr.eu:/svn/rpm/trunk:yes
{{Admon/warning|Paramètre ''use_common''|Il semble y avoir un bug avec le paramètre ''use_common'' et l'utilisation d'un dépôt git.

En effet quelque soit la valeur de ce paramètre, un dépôt ''common'' sera téléchargé.

'''Work-Around''': Créer un dépôt ''common'' vide sur le serveur git.}}

Le système doit fournir un Makefile qui contient une cible sources, dont la tâche est de fournir les sources via une commande de téléchargement. Si celles-ci sont incluses dans le SCM, la cible doit être vide.

<syntaxhighlight lang="make">
# Common Makefile
sources:
</syntaxhighlight>

Il ne reste plus qu'à lancer la construction depuis <app>koji</app>

avec SVN
koji build centos-5 <nowiki>svn+http://didier.tartarefr.eu/svn/rpm/trunk?didier-release#head</nowiki>

avec git
koji build centos-5 git://didier.tartarefr.eu/rpm?didier-release#5153396fc3bf204b74e745759eee33ed5dad0ffe
{{Admon/important|Différence entre les SCM|* Avec svn, le '''répertoire''' ''common'' sera téléchargé en plus de celui du paquet en cours
* Avec git c'est un '''dépôt''' ''common'' qui sera ajouté et l'intégralité du dépôt rpm sera téléchargé.}}

== Interface Web ==
[[Fichier:KojiwebScreenshot.png||800px]]

== Dépôt B2PWeb ==

=== Importer des paquets sources et binaires ===
{{Admon/warning|Import|Il est impératif d'importer les paquets RPM pour chaque architecture gérée (intel 32/64 bits, etc ...). De plus le paquet SRPM (RPM source) devra être importer en premier.
Il y a donc au minimum import de deux paquets RPM.}}

<package>Koji</package> '''n'accepte pas facilement l'import de paquet RPM binaire sans paquet RPM source correspondant.'''

==== Import standard ====

Comme nous n'avons que deux architectures définies :
* i386 ou i686 ( suivant la version de la distribution )
* x86_64

Afin de maintenir une certaine homogénéité dans le dépôt, il faudra importer les paquets RPM binaires pour les deux architectures.

Le SRPM est obligatoirement importé en premier.

# Import du paquet RPM source<pre>koji add-pkg centos-5 foo.src.rpm</pre>
# Import des paquets RPM binaires
#* Paquet 32 bits<pre>koji add-pkg centos-5 foo.i386.rpm</pre>
#* Paquet 64 bits<pre>koji add-pkg centos-5 foo.x86_64.rpm</pre>

==== Import sans SRPM ====

Exemple en intégrant les paquets pour une base Oracle.
# Téléchargement des RPM depuis le site Oracle dans le dossier <path>/mnt/koji/externals</path>
#* oracle-instantclient12.1-basic-12.1.0.1.0-1.i386.rpm
#* oracle-instantclient12.1-devel-12.1.0.1.0-1.i386.rpm
#* oracle-instantclient12.1-sqlplus-12.1.0.1.0-1.i386.rpm
#* oracle-instantclient12.1-basic-12.1.0.1.0-1.x86_64.rpm
#* oracle-instantclient12.1-devel-12.1.0.1.0-1.x86_64.rpm
#* oracle-instantclient12.1-sqlplus-12.1.0.1.0-1.x86_64.rpm
# Ajout des paquets au {{package|Koji}}
#* <pre>koji add-pkg centos-6 --owner didier oracle-instantclient12.1-basic</pre>
#* <pre>koji add-pkg centos-6 --owner didier oracle-instantclient12.1-devel</pre>
#* <pre>koji add-pkg centos-6 --owner didier oracle-instantclient12.1-sqlplus</pre>
# Import des paquets dans le {{package|Koji}}<pre>koji import --create-build /mnt/koji/externals/oracle*.rpm</pre>
# Comme les paquets sont juste importés, il est nécessaire de les taggués. On commmence par visualiser les paquets non taggués<pre>koji list-untagged</pre>Comme on s'y attend, trois paquets ne sont pas taggués
#* oracle-instantclient12.1-basic-12.1.0.1.0-1
#* oracle-instantclient12.1-devel-12.1.0.1.0-1
#* oracle-instantclient12.1-sqlplus-12.1.0.1.0-1
# Tag des paquets précédemment importés en centos-6-build
#* <pre>koji tag-pkg centos-6 oracle-instantclient12.1-basic-12.1.0.1.0-1</pre>
#* <pre>koji tag-pkg centos-6 oracle-instantclient12.1-devel-12.1.0.1.0-1</pre>
#* <pre>koji tag-pkg centos-6 oracle-instantclient12.1-sqlplus-12.1.0.1.0-1</pre>
# Régénération du dépôt<pre>koji regen-repo centos-6-build</pre>

=== Ajout de paquets sources ===
Il faut tout d'abord avoir une copie de travail du dépôt des sources, accessible en lecture/écriture.

Pour cela il faut disposer d'un compte associé à une paire de clés ( publique et privée ) <app>ssh</app>.
# Génération de la paire de clé
#* Sous GNU/Linux, il suffit de lancer la commande<pre> ssh-keygen -t rsa</pre>
#* Sous Windows il faut utiliser le programme <app>puttygen.exe</app> pour générer la paire de clé. La clé publique porte l'extension '''pub''' et la clé privé '''ppk'''.<br>Il faut ensuite utiliser un agent ( ex: <app>pageant.exe</app> )
#Puis il faut insérer le contenu de la clé publique ( à la suite des autres ) dans le fichier <path>/var/lib/git/.ssh/authorized_keys</path> sur le serveur.<br>Afin de tester avant le checkout, on doit pouvoir se connecter au serveur sans mot de passe<pre> ssh git@didier.tartarefr.eu</pre>
# Si le login est possible, on peut alors obtenir une copie du dépôt<pre>git clone git@didier.tartarefr.eu/rpm</pre>

=== Ajout d'un paquet ===
{{Admon/todo}}
=== Mise à jour d'un paquet ===
{{Admon/todo}}

== Mise à jour du koji ==

La mise à jour du koji est sensible. En effet, les versions doivent correspondre entre le hub, le web, et même les builders.

Si les composants sont sur des machines virtuelles, il est préférable de sauvegarder la vm (a minima de faire un snapshot, ou bien un export) avant de lancer la mise à jour.

== F.A.Q. ==

=== Comment supprimer un paquet sans aucun build associé ===
Pour un problème de nom incorrect de paquet ou pour d'autre raisons, il est nécessaire de modifier directement la base de données, car aucune commande existe.

Si aucun build n'est associé à ce paquet, il n'est référencé que dans deux tables:
* package
* tag_packages

On se place sur le serveur <package>Koji</package> et on se loggue avec l'utilisateur koji

# su - koji
$ psql -U koji koji

Remplacer commit par rollback si quelque chose ne se passe pas bien, afin d'annuler la transaction.
<syntaxhighlight lang="sql">
begin;
delete from tag_packages where package_id = (select id from package where name = 'SOME-TYPO');
delete from package where name = 'SOME-TYPO';
commit;
</syntaxhighlight>

=== BuildrootError: could not init mock buildroot, mock exited with status 30 ===

Et dans le fichier <path>root.log</path> associé au build, on retrouve l'erreur: ''Package does not match intended download''

Il faut lancer manuellement la régénération du dépôt
koji regen-repo centos-6-build

=== Construction du SRPM en erreur ===

* Il faut regarder que le répertoire ne contient pas de fichier nommé <path>sources</path>, car koji télécharge les sources en faisant <pre>make sources</pre>et la cible du Makefile est donc à jour.
* Le paquet n'est pas inclus au dépôt. Il faut l'inclure comme ceci<pre>koji add-pkg centos-6 --owner didier <MON PAQUET></pre>

== Utilisation du repository ==

Il suffit de renseigné <package>yum</package> pour qu'il pointe sur le repository
<nowiki>http://koji.tartarefr.eu/kojifiles/repos/centos-6-build/latest/$basearch</nowiki>

== Skins ==
Modification à partir du thème osg<ref>https://github.com/djw8605/osg-koji-theme</ref>

== Références ==
<references/>

Fichier:IconTodo48.png

2017-04-20T10:17:05Z

Didier : Icone Todo 48 pixels

Icone Todo 48 pixels

Modèle:Admon/todo

2017-04-20T10:15:31Z

Didier :

<noinclude>{{high-risk template|pagecount=all pages}}</noinclude>
{{message|{{color|red|{{#if:{{{1|}}}| {{{1}}}|'''TODO'''
* étape #1
* étape #2
}}}}|image=IconTodo48.png|bgcolor=#cccccc|bdcolor=#c5d7e0}}
<noinclude>{{tempdoc}}[[Category:Admonition templates]]</noinclude>

Modèle:Admon/todo

2017-04-20T10:11:10Z

Didier :

<noinclude>{{high-risk template|pagecount=all pages}}</noinclude>
{{message|{{color|red|{{#if:{{{1|}}}| '''{{{1}}}'''|'''TODO'''}}}}|image=IconTodo48.png|bgcolor=#cccccc|bdcolor=#c5d7e0}}
<noinclude>{{tempdoc}}[[Category:Admonition templates]]</noinclude>

Tuto/Edit

2017-04-20T10:09:19Z

Didier : /* Ajouter une note d'auteur ( simple, importante, avertissement, astuce, auteur original ) */

= Syntaxe =
* Aide générale sur la syntaxe: http://fr.wikipedia.org/wiki/Aide:Syntaxe
* Mot clés de Mediawiki: http://www.mediawiki.org/wiki/Help:Magic_words

= Règle de base =
La recherche dans les pages du wiki ainsi et que la maintenance de celui-ci est grandement facilité par l'ajout de catégorie sur chaque page.

= Modification générale de MediaWiki =
Tous les changements de cette section doivent être édité avec le compte administrateur.
* '''Menu latéral''': [[MediaWiki:Sidebar]]
* '''Ajout de CSS à tous les styles''': [[MediaWiki:Common.css]]
* '''Ajout de CSS pour l'impression''': [[MediaWiki:Print.css]]

= Modules intégrés =
==Upload de fichier==

Page d'aide sur la configuration de l'upload de fichiers <ref>http://www.mediawiki.org/wiki/Manual:Configuring_file_uploads</ref>

==Tableau==
Page d'aide sur les tableaux <ref>http://www.mediawiki.org/wiki/Help:Tables/fr</ref>

Exemple d'utilisation
<pre>
{| class="wikitable"
|+Titre du tableau
!Titre de colonne1
!Titre de colonne2
|-
|Cellule 1 sur la ligne 1
|Cellule 2 sur la ligne 1
|-
|Cellule 1 sur la ligne 2
|Cellule 2 sur la ligne 2
|}
</pre>
{| class="wikitable"
|+Titre du tableau<br>
!Titre de colonne1
!Titre de colonne2
|-
|Cellule 1 sur la ligne 1
|Cellule 2 sur la ligne 1
|-
|Cellule 1 sur la ligne 2
|Cellule 2 sur la ligne 2
|}

= Modules supplémentaires =

* '''CategoryTree''': Afficher une vue en arbre des catégories<ref>http://www.mediawiki.org/wiki/Extension:CategoryTree/fr</ref>
* '''Cite''': Créer des notes de bas de page, collection de références, etc...<ref>http://www.mediawiki.org/wiki/Extension:Cite/Cite.php</ref>
* '''ParserFunctions''': Fonctions avancées pour les extensions<ref>http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions/fr</ref>
* '''Mpdf''': Export de page en PDF<ref>http://www.mediawiki.org/wiki/Extension:Mpdf</ref>
* '''SyntaxHighlight_GeSHi''': Coloration syntaxique de code source<ref>http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi</ref>
* '''RandomImage''': Ajout d'une image aléatoire<ref>http://www.mediawiki.org/wiki/Extension:RandomImage</ref>
* '''SSL_authentification''': Authentification via un certificat<ref>http://www.mediawiki.org/wiki/Extension:SSL_authentication</ref>
* '''CustomTag''': Permet l'usage des tags suivants dans le code wiki ( en ligne )
** '''<nowiki><path></nowiki>''' Affichage du path ex: <path>/home/user</path>
** '''<nowiki><package></nowiki>''' Affichage du nom du paquet ex: <package>perl-ExtUtils-MakeMaker</package>
** '''<nowiki><app></nowiki>''' Affichage du nom de l'application ex: <app>vim</app>
** '''<nowiki><class></nowiki>''' Affichage du nom de la class ex: <class>KVirtualView</class>

= Macros définies permettant un affichage spécial =

== Mettre en valeur un mot ==
* '''class''' pour mettre en valeur un nom de class ( en ligne ) {{class|KVirtual}}
<nowiki>{{class|KVirtual}}</nowiki>
* '''path''' pour mettre en valeur un chemin ( en ligne ), ex: {{path|/home/user}}
<nowiki>{{path|/home/user}}</nowiki>
* '''filename''' pour mettre en valeur un nom de fichier ( en ligne ), ex: {{filename|/etc/mail/aliases}}
<nowiki>{{filename|/etc/mail/aliases}}</nowiki>
* '''package''' pour mettre en valeur un nom de paquet ( en ligne ), ex: {{package|perl-ExtUtils-MakeMaker}}
<nowiki>{{package|perl-ExtUtils-MakeMaker}}</nowiki>
* '''app''' pour mettre en valeur un nom d'application ( en ligne ), ex: {{app|vim}}
<nowiki>{{app|vim}}</nowiki>
* '''code''' pour mettre en valeur un morceau de code ( en ligne ), ex: {{code|find /etc -type f -name '*.conf'}}
<nowiki>{{code|find /etc -type f -name '*.conf'}}</nowiki>
* '''command''' pour mettre en valeur une commande ( en ligne ), ex: {{command|find /etc -type f -name '*.conf'}}
<nowiki>{{command|find /etc -type f -name '*.conf'}}</nowiki>
* '''color''' pour mettre en couleur un mot ( en ligne ), ex: {{color|red|mots en couleur}}
<nowiki>{{color|red|mots en couleur}}</nowiki>

== Ajouter une note d'auteur ( simple, importante, avertissement, astuce, auteur original ) ==
* '''Admon/note''' pour écrire une note d'information
<nowiki>{{Admon/note|Titre|texte optionnel de la note}}</nowiki>
{{Admon/note|Titre|texte optionnel de la note}}
* '''Admon/warning''' pour écrire un avertissement bien visible
<nowiki>{{Admon/warning|Titre|Texte optionnel du warning}}</nowiki>
{{Admon/warning|Titre|Texte optionnel du warning}}
* '''Admon/important''' pour écrire une note très importante
<nowiki>{{Admon/important|Titre|Texte optionnel de la note importante}}</nowiki>
{{Admon/important|Titre|Texte optionnel de la note importante}}
* '''Admon/tip''' pour écrire une astuce bien visible
<nowiki>{{Admon/tip|Titre|Texte optionnel de l'astuce}}</nowiki>
{{Admon/tip|Titre|Texte optionnel de l'astuce}}
* '''Admon/bug''' pour signaler un bug
<nowiki>{{Admon/bug|Titre|Texte optionnel du bug}}</nowiki>
{{Admon/bug|Titre|Texte optionnel du bug}}
* '''Admon/faq''' pour écrire une question réponse
{{Admon/faq|Question|Answer}}
<nowiki>{{Admon/faq|Question|Answer}}</nowiki>
* '''author''' pour afficher les auteurs et les participants éventuels lorsqu'il s'agit d'une page recopié d'un autre wiki.
<nowiki>{{author|author=Auteur original|othersauthors=Liste des participants éventuels (paramètre optionnel)|url=Lien vers l'URL d'origine (paramètre optionnel)}}</nowiki>
{{author|author=Auteur original|othersauthors=Liste des participants éventuels (paramètre optionnel)|url=Lien vers l'URL d'origine (paramètre optionnel)}}
* '''Admon/todo''' pour écrire une liste de chose à faire (TODO)
<nowiki>{{Admon/todo|TODO Liste
* étape 1
* étape 2}}</nowiki>
{{Admon/todo|TODO Liste
* étape 1
* étape 2}}
* '''Admon/file''' pour afficher un ficher texte
<nowiki>{{Admon/file|Chemin du fichier|
<pre>
ligne 1
ligne2
</pre>}}</nowiki>
{{Admon/file|Chemin du fichier|
<pre>
ligne 1
ligne 2
</pre>}}

== Smileys ==
* '''Admon/smiley'''
Good Job {{Admon/smiley|:)}}
<nowiki>{{Admon/smiley|:)}}</nowiki>
{{:Modèle:Admon/smiley/example}}

Consultez le [http://meta.wikimedia.org/wiki/Aide:Contenu Guide de l’utilisateur] pour plus d’informations sur l’utilisation de ce logiciel.

= Langages supportés par l'extension de coloration syntaxique =
<nowiki><syntaxhighlight lang="CODE">
</syntaxhighlight></nowiki>

{| class="wikitable" style="float:left;margin-right:20px;"
!Code||Language
|-
|<code>abap</code>||ABAP
|-
|<code>actionscript</code>||ActionScript
|-
|<code>ada</code>||Ada
|-
|<code>apache</code>||Apache Configuration
|-
|<code>applescript</code>||AppleScript
|-
|<code>asm</code>||Assembly
|-
|<code>asp</code>||Active Server Pages (ASP)
|-
|<code>autoit</code>||AutoIt
|-
|<code>bash</code>||Bash
|-
|<code>basic4gl</code>||Basic4GL
|-
|<code>bf</code>||Brainfuck
|-
|<code>blitzbasic</code>||Blitz BASIC
|-
|<code>bnf</code>||Backus-Naur Form
|-
|<code>c</code>||C
|-
|<code>c_mac</code>||C (Mac)
|-
|<code>caddcl</code>||AutoCAD DCL
|-
|<code>cadlisp</code>||AutoLISP
|-
|<code>cfdg</code>||CFDG
|-
|<code>cfm</code>||ColdFusion Markup Language
|-
|<code>cil</code>||Common Intermediate Language (CIL)
|-
|<code>cobol</code>||COBOL
|-
|<code>cpp-qt</code>||C++ (Qt toolkit)
|-
|<code>cpp</code>||C++
|-
|<code>csharp</code>||C#
|-
|<code>css</code>||Cascading Style Sheets (CSS)
|-
|<code>d</code>||D
|-
|<code>delphi</code>||Delphi
|-
|<code>diff</code>||Diff
|-
|<code>div</code>||DIV
|-
|<code>dos</code>||DOS batch file
|-
|<code>dot</code>||DOT
|-
|<code>eiffel</code>||Eiffel
|-
|<code>fortran</code>||Fortran
|-
|<code>freebasic</code>||FreeBASIC
|-
|<code>genero</code>||Genero
|-
|<code>gettext</code>||GNU internationalization (i18n) library
|-
|<code>glsl</code>||OpenGL Shading Language (GLSL)
|-
|<code>gml</code>||Game Maker Language (GML)
|-
|<code>gnuplot</code>||gnuplot
|-
|<code>groovy</code>||Groovy
|-
|<code>haskell</code>||Haskell
|-
|<code>hq9plus</code>||HQ9+
|-
|<code>html4strict</code>||HTML
|-
|<code>idl</code>||Uno IDL
|-
|<code>ini</code>||INI
|-
|<code>inno</code>||Inno
|-
|<code>intercal</code>||INTERCAL
|-
|<code>io</code>||Io
|-
|<code>java</code>||Java
|-
|<code>java5</code>||Java(TM) 2 Platform Standard Edition 5.0
|-
|<code>javascript</code>||JavaScript
|-
|<code>kixtart</code>||KiXtart
|-
|<code>klonec</code>||Klone C
|-
|<code>klonecpp</code>||Klone C++
|-
|<code>latex</code>||LaTeX
|-
|<code>lisp</code>||Lisp
|-
|<code>lolcode</code>||LOLCODE
|-
|<code>lotusscript</code>||LotusScript
|-
|<code>lua</code>||Lua
|}
{| class="wikitable" style="float:left"
!Code||Language
|-
|<code>m68k</code>||Motorola 68000 Assembler
|-
|<code>make</code>||make
|-
|<code>matlab</code>||MATLAB M
|-
|<code>mirc</code>||mIRC scripting language
|-
|<code>mxml</code>||MXML
|-
|<code>mpasm</code>||Microchip Assembler
|-
|<code>mysql</code>||MySQL
|-
|<code>nsis</code>||Nullsoft Scriptable Install System (NSIS)
|-
|<code>objc</code>||Objective-C
|-
|<code>ocaml-brief</code>||OCaml
|-
|<code>ocaml</code>||OCaml
|-
|<code>oobas</code>||OpenOffice.org Basic
|-
|<code>oracle8</code>||Oracle 8 SQL
|-
|<code>oracle11</code>||Oracle 11 SQL
|-
|<code>pascal</code>||Pascal
|-
|<code>per</code>||per
|-
|<code>perl</code>||Perl
|-
|<code>php-brief</code>||PHP
|-
|<code>php</code>||PHP
|-
|<code>pixelbender</code>||Pixel Bender
|-
|<code>plsql</code>||PL/SQL
|-
|<code>povray</code>||Persistence of Vision Raytracer
|-
|<code>powershell</code>||Windows PowerShell
|-
|<code>progress</code>||OpenEdge Advanced Business Language
|-
|<code>prolog</code>||Prolog
|-
|<code>providex</code>||ProvideX
|-
|<code>python</code>||Python
|-
|<code>qbasic</code>||QBasic/QuickBASIC
|-
|<code>rails</code>||Rails
|-
|<code>reg</code>||Windows Registry
|-
|<code>robots</code>||robots.txt
|-
|<code>ruby</code>||Ruby
|-
|<code>sas</code>||SAS
|-
|<code>scala</code>||Scala
|-
|<code>scheme</code>||Scheme
|-
|<code>scilab</code>||Scilab
|-
|<code>sdlbasic</code>||SdlBasic
|-
|<code>smalltalk</code>||Smalltalk
|-
|<code>smarty</code>||Smarty
|-
|<code>sql</code>||SQL
|-
|<code>tcl</code>||Tcl
|-
|<code>teraterm</code>||Tera Term
|-
|<code>text</code>||Plain text
|-
|<code>thinbasic</code>||thinBasic
|-
|<code>tsql</code>||Transact-SQL
|-
|<code>typoscript</code>||TypoScript
|-
|<code>vb</code>||Visual Basic
|-
|<code>vbnet</code>||Visual Basic .NET
|-
|<code>verilog</code>||Verilog
|-
|<code>vhdl</code>||VHDL
|-
|<code>vim</code>||Vimscript
|-
|<code>visualfoxpro</code>||Visual FoxPro
|-
|<code>visualprolog</code>||Visual Prolog
|-
|<code>whitespace</code>||Whitespace
|-
|<code>winbatch</code>||Winbatch
|-
|<code>xml</code>||XML
|-
|<code>xorg_conf</code>||Xorg.conf
|-
|<code>xpp</code>||X++
|-
|<code>z80</code>||ZiLOG Z80 Assembler
|}
<div style="clear:both;"></div>

= Notes =
<references/>

Modèle:Admon/todo

2017-04-20T09:59:25Z

Didier : Page créée avec « <noinclude>{{high-risk template|pagecount=all pages}}</noinclude> {{message|{{color|red|{{#if:{{{1|}}}| '''{{{1}}}'''|'''TODO'''}}}}|image=Todo.png|bgcolor=#cccccc|bdcolor... »

<noinclude>{{high-risk template|pagecount=all pages}}</noinclude>
{{message|{{color|red|{{#if:{{{1|}}}| '''{{{1}}}'''|'''TODO'''}}}}|image=Todo.png|bgcolor=#cccccc|bdcolor=#c5d7e0}}
<noinclude>{{tempdoc}}[[Category:Admonition templates]]</noinclude>

Koji/Bootstrap

2017-04-20T09:46:31Z

Didier : Page créée avec « = Commandes utiles = Il est nécessaire de régénerer le dépôt régulièrement car <package>Koji</package> ne prend pas automatiquement en compte la mise à jour des d... »

= Commandes utiles =

Il est nécessaire de régénerer le dépôt régulièrement car <package>Koji</package> ne prend pas automatiquement en compte la mise à jour des dépôts externes.
koji regen-repo centos-6-build

Il peut être intéressant d'en faire une tâche cron.

= Bootstrap =

== CentOS 5 ==

=== Ajout des tags ===
koji add-tag centos-5
koji add-tag --parent "centos-5" --arches 'i386 x86_64' centos-5-build

=== Ajout des groupes ===
koji add-group centos-5-build build
koji add-group centos-5-build srpm-build

=== Ajout des cibles ===
koji add-target centos-5 centos-5-build

=== Ajout des repositories externes ===

koji add-external-repo -t centos-5-build -p 10 centos-5-external-core <nowiki>http://mirrors.ircam.fr/pub/CentOS/5/os/\$arch</nowiki>
koji add-external-repo -t centos-5-build -p 5 centos-5-external-update <nowiki>http://mirrors.ircam.fr/pub/CentOS/5/updates/\$arch</nowiki>
koji add-external-repo -t centos-5-build -p 15 centos-5-external-builsys <nowiki>http://buildsys.fedoraproject.org/buildgroups/rhel5/\$arch</nowiki>
koji add-external-repo -t centos-5-build -p 20 centos-5-external-rpmforge <nowiki>http://apt.sw.be/redhat/el5/en/\$arch/rpmforge</nowiki>
koji add-external-repo -t centos-5-build -p 25 centos-5-external-epel <nowiki>http://mirrors.ircam.fr/pub/fedora/epel/5/\$arch</nowiki>

=== Ajout de la liste des paquets ===
Cette liste définie les paquets pour une installation la plus minimaliste possible

koji add-group-pkg centos-5-build build bash bzip2 coreutils cpio diffutils \
findutils gawk gcc grep sed gcc-c++ gzip info patch redhat-rpm-config \
rpm-build shadow-utils tar unzip util-linux-ng which make buildsys-macros \
redhat-release curl

koji add-group-pkg centos-5-build srpm-build bash buildsys-macros curl \
redhat-release make redhat-rpm-config rpm-build shadow-utils

=== Ajout éventuelle de paquets externes ===
koji add-pkg centos-5 centos/5/RPMS/SRPMS/*.rpm
koji add-pkg centos-5 centos/5/RPMS/*.rpm

== CentOS 6 ==

=== Ajout des tags ===
koji add-tag centos-6
koji add-tag --parent "centos-6" --arches 'i686 x86_64' centos-6-build

=== Ajout des groupes ===
koji add-group centos-6-build build
koji add-group centos-6-build srpm-build

=== Ajout des cibles ===
koji add-target centos-6 centos-6-build

=== Ajout des repositories externes ===
koji add-external-repo -t centos-6-build -p 10 centos-6-external-core <nowiki>http://mirrors.ircam.fr/pub/CentOS/6/os/\$arch</nowiki>
koji add-external-repo -t centos-6-build -p 5 centos-6-external-update <nowiki>http://mirrors.ircam.fr/pub/CentOS/6/updates/\$arch</nowiki>
koji add-external-repo -t centos-6-build -p 15 centos-6-external-rpmforge <nowiki>http://apt.sw.be/redhat/el6/en/\$arch/rpmforge</nowiki>
koji add-external-repo -t centos-6-build -p 20 centos-6-external-epel <nowiki>http://mirrors.ircam.fr/pub/fedora/epel/6/\$arch</nowiki>

=== Ajout de la liste des paquets ===
koji add-group-pkg centos-6-build build bash bzip2 coreutils cpio diffutils \
findutils gawk gcc grep sed gcc-c++ gzip info patch redhat-rpm-config \
rpm-build shadow-utils tar unzip util-linux-ng which make buildsys-macros \
redhat-release centos-release curl

koji add-group-pkg centos-6-build srpm-build bash buildsys-macros curl \
redhat-release centos-release make redhat-rpm-config rpm-build shadow-utils

== Fedora 17 ==

=== Ajout des tags ===
koji add-tag fedora-17
koji add-tag --parent 'fedora-17' --arches 'i686 x86_64' fedora-17-build

=== Ajout des groupes ===
koji add-group fedora-17-build build
koji add-group fedora-17-build srpm-build

=== Ajout des cibles ===
koji add-target fedora-17 fedora-17-build

=== Ajout des repositories externes ===
koji add-external-repo -t fedora-17-build -p 10 fedora-17-external-core <nowiki>http://fedora.mirrors.ovh.net/linux/releases/17/Everything/\$arch/os</nowiki>
koji add-external-repo -t fedora-17-build -p 5 fedora-17-external-update <nowiki>http://mir01.syntis.net/fedora/linux/updates/17/\$arch</nowiki>
koji add-external-repo -t fedora-17-build -p 15 fedora-17-external-rpmfusion-free-core <nowiki>http://download1.rpmfusion.org/free/fedora/releases/17/Everything\$arch/os</nowiki>
koji add-external-repo -t fedora-17-build -p 11 fedora-17-external-rpmfusion-free-update <nowiki>http://download1.rpmfusion.org/free/fedora/updates/17/\$arch</nowiki>

=== Ajout de la liste des paquets ===
koji add-group-pkg fedora-17-build build bash bzip2 coreutils cpio diffutils \
findutils gawk gcc grep sed gcc-c++ gzip info patch redhat-rpm-config \
rpm-build shadow-utils tar unzip util-linux-ng which make buildsys-macros-6 \
fedora-release curl

koji add-group-pkg fedora-17-build srpm-build bash buildsys-macros-6 curl \
fedora-release make redhat-rpm-config rpm-build shadow-utils

[[Catégorie:RPM|Bootstrap Koji]]
[[Catégorie:Koji|Bootstrap]]
[[Catégorie:Server|Bootstrap Koji]]

RPM/Mash

2017-04-20T09:44:49Z

Didier : /* Présentation */

'''Mash'''

== Présentation ==
<app>Mash</app> est un outil qui interroge [[Koji/Utilisation|Koji]] afin d'obtenir les RPMs pour un tag donné et qui créer un dépôt directement utilisable avec ceux-ci.

== Installation ==
yum install mash

== Configuration ==

=== Configuration générale de mash ===

Fichier <path>/etc/mash/mash.conf</path>
<syntaxhighlight lang="ini">

[defaults]
configdir = /etc/mash
buildhost = http://koji.tartarefr.eu/kojihub
repodir = file:///mnt/koji
use_sqlite = True
use_repoview = True

</syntaxhighlight>

=== Configuration du dépôt pour CentOS 5 ===

Par défaut, {{package|mash}} créé une somme de vérification avec l'algorythme sha256, ce qui est incompatible avec CentOS 5. On doit donc lui préciser d'utiliser l'algorythme sha1 en lieu et place.

Fichier <path>/etc/mash/centos5.mash</path>
<syntaxhighlight lang="ini">
# mash config file

[5]
rpm_path = os/RPMS/%(arch)s/
repodata_path = os/RPMS/%(arch)s/
source_path = os/SRPMS
debuginfo = True
debuginfo_path = debug/%(arch)s/
multilib = True
multilib_method = devel
tag = centos-5
inherit = True
strict_keys = True
keys = 22B3B81A, 1ACA3465, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9, 773DF357
repoviewurl = http://koji.tartarefr.eu/repositories/
repoviewtitle = "CentOS 5 repository - %(arch)s"
arches = i386 x86_64
delta = True
# Change distro_tags as fedora-release version gets bumped
#distro_tags = cpe:/o:fedoraproject:fedora:17 rawhide
distro_tags = cpe:/o:centos:centos:5 centos-5
hash_packages = True
#make_ancient = True
hash = sha1
outputdir = /mnt/repos/centos
# This forces to also create older version of same package
latest = False

</syntaxhighlight>

=== Configuration du dépôt pour CentOS 6 ===

Fichier <path>/etc/mash/centos6.mash</path>
<syntaxhighlight lang="ini">
# mash config file

[6]
rpm_path = os/RPMS/%(arch)s/
repodata_path = os/RPMS/%(arch)s/
source_path = os/SRPMS
debuginfo = True
debuginfo_path = debug/%(arch)s/
multilib = True
multilib_method = devel
tag = centos-6
inherit = True
strict_keys = True
keys = 22B3B81A, 1ACA3465, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9, D3F3C56A
repoviewurl = http://koji.tartarefr.eu/repositories/
repoviewtitle = "CentOS 6 repository - %(arch)s"
arches = i386 x86_64
delta = True
# Change distro_tags as fedora-release version gets bumped
distro_tags = cpe:/o:centos:centos:6 centos-6
hash_packages = True
outputdir = /mnt/repos/centos
# This forces to also create older version of same package
latest = False

</syntaxhighlight>

=== Configuration du dépôt pour fedora 20 ===

Le fichier existe déjà (installé en même temps que <app>mash</app>). Seul la version de fedora s'incrémente au fur et à mesure des sorties de la distribution.

Fichier <path>/etc/mash/branched.mash</path>
<syntaxhighlight lang="ini">
# mash config file

[20]
rpm_path = os/RPMS/%(arch)s/
repodata_path = os/RPMS/%(arch)s/
source_path = os/SRPMS
debuginfo = True
debuginfo_path = debug/%(arch)s/
multilib = True
multilib_method = devel
tag = fedora-20
inherit = True
strict_keys = True
keys = 246110C1
repoviewurl = http://koji.tartarefr.eu/repositories/
repoviewtitle = "Fedora 20 repository - %(arch)s"
arches = i386 x86_64
delta = True
max_delta_rpm_size = 800000000
# Change distro_tags as fedora-release version gets bumped
distro_tags = cpe:/o:fedoraproject:fedora:20 Null
hash_packages = True
outputdir = /mnt/repositories/fedora

</syntaxhighlight>

=== Mise en place d'un alias ===

Le répertoire <path>/mnt/repositories</path> doit être accessible par HTTP. On ajoute donc un alias.

Fichier <path>/etc/httpd/conf.d/mash.conf</path>
<syntaxhighlight lang="apache">
Alias /repositories "/mnt/repositories"
<Directory "/mnt/repositories">
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
Options +Indexes
AllowOverride None
<IfModule mod_authz_core.c>
# Apache 2.4
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
# Apache 2.2
Order allow,deny
Allow from all
</IfModule>
</Directory>
</syntaxhighlight>

== Lancement de l'outil ==

=== Setup initial ===
On va simplement créé l'arborescence nécessaire
<syntaxhighlight lang="bash">mkdir /mnt/repos/{fedora,centos}</syntaxhighlight>

=== Création des dépôts ===
Création du dépôt pour CentOS 5
<syntaxhighlight lang="bash">mash 5</syntaxhighlight>
Création du dépôt pour CentOS 6
<syntaxhighlight lang="bash">mash 6</syntaxhighlight>
Création du dépôt pour Fedora 20
<syntaxhighlight lang="bash">mash 20</syntaxhighlight>

== F.A.Q. ==
{{Admon/faq|Erreur yum.Errors.RpmDBError: Package tuple could not be found in rpmdb|Cette erreur se rencontre après avoir mis à jour <package>yum</package>

Ce bug est répertorié chez RedHat<ref>https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=920758</ref>

La correction est triviale, Il faut appliquer le patch suivant au fichier <path>/usr/lib/python2.6/site-packages/yum/depsolve.py</path>( _checkFileRequires() caches the file requires of installed or to-be installed packages. Update it when removing packages in TS_INSTALL_STATES from transaction).<ref>http://lists.baseurl.org/pipermail/yum-devel/2013-March/010022.html</ref>
<syntaxhighlight lang="diff">
diff -up a/depsolve.py b/depsolve.py
--- a/depsolve.py 2014-01-14 14:51:27.288392585 +0100
+++ b/depsolve.py.new 2014-01-14 14:51:17.683392467 +0100
@@ -808,6 +808,8 @@ class Depsolve(object):
# Have to deal with loops!
continue
self.tsInfo.remove(otxmbr.pkgtup)
+ ifr = self.installedFileRequires or {}
+ ifr.pop(otxmbr.pkgtup, None)
# We need to remove an obsoleted entry that
# was maybe used to resolve something ... ?
CheckDeps = True
</syntaxhighlight>
}}

== Références ==
<references/>

[[Catégorie:RPM]]
[[Catégorie:Koji]]
[[Catégorie:Server]]

RPM/Mash

2017-04-20T09:42:52Z

Didier : /* Configuration générale de mash */

'''Mash'''

== Présentation ==
<app>Mash</app> est un outil qui interroge [[Koji|Koji]] afin d'obtenir les RPMs pour un tag donné et qui créer un dépôt directement utilisable avec ceux-ci.

== Installation ==
yum install mash

== Configuration ==

=== Configuration générale de mash ===

Fichier <path>/etc/mash/mash.conf</path>
<syntaxhighlight lang="ini">

[defaults]
configdir = /etc/mash
buildhost = http://koji.tartarefr.eu/kojihub
repodir = file:///mnt/koji
use_sqlite = True
use_repoview = True

</syntaxhighlight>

=== Configuration du dépôt pour CentOS 5 ===

Par défaut, {{package|mash}} créé une somme de vérification avec l'algorythme sha256, ce qui est incompatible avec CentOS 5. On doit donc lui préciser d'utiliser l'algorythme sha1 en lieu et place.

Fichier <path>/etc/mash/centos5.mash</path>
<syntaxhighlight lang="ini">
# mash config file

[5]
rpm_path = os/RPMS/%(arch)s/
repodata_path = os/RPMS/%(arch)s/
source_path = os/SRPMS
debuginfo = True
debuginfo_path = debug/%(arch)s/
multilib = True
multilib_method = devel
tag = centos-5
inherit = True
strict_keys = True
keys = 22B3B81A, 1ACA3465, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9, 773DF357
repoviewurl = http://koji.tartarefr.eu/repositories/
repoviewtitle = "CentOS 5 repository - %(arch)s"
arches = i386 x86_64
delta = True
# Change distro_tags as fedora-release version gets bumped
#distro_tags = cpe:/o:fedoraproject:fedora:17 rawhide
distro_tags = cpe:/o:centos:centos:5 centos-5
hash_packages = True
#make_ancient = True
hash = sha1
outputdir = /mnt/repos/centos
# This forces to also create older version of same package
latest = False

</syntaxhighlight>

=== Configuration du dépôt pour CentOS 6 ===

Fichier <path>/etc/mash/centos6.mash</path>
<syntaxhighlight lang="ini">
# mash config file

[6]
rpm_path = os/RPMS/%(arch)s/
repodata_path = os/RPMS/%(arch)s/
source_path = os/SRPMS
debuginfo = True
debuginfo_path = debug/%(arch)s/
multilib = True
multilib_method = devel
tag = centos-6
inherit = True
strict_keys = True
keys = 22B3B81A, 1ACA3465, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9, D3F3C56A
repoviewurl = http://koji.tartarefr.eu/repositories/
repoviewtitle = "CentOS 6 repository - %(arch)s"
arches = i386 x86_64
delta = True
# Change distro_tags as fedora-release version gets bumped
distro_tags = cpe:/o:centos:centos:6 centos-6
hash_packages = True
outputdir = /mnt/repos/centos
# This forces to also create older version of same package
latest = False

</syntaxhighlight>

=== Configuration du dépôt pour fedora 20 ===

Le fichier existe déjà (installé en même temps que <app>mash</app>). Seul la version de fedora s'incrémente au fur et à mesure des sorties de la distribution.

Fichier <path>/etc/mash/branched.mash</path>
<syntaxhighlight lang="ini">
# mash config file

[20]
rpm_path = os/RPMS/%(arch)s/
repodata_path = os/RPMS/%(arch)s/
source_path = os/SRPMS
debuginfo = True
debuginfo_path = debug/%(arch)s/
multilib = True
multilib_method = devel
tag = fedora-20
inherit = True
strict_keys = True
keys = 246110C1
repoviewurl = http://koji.tartarefr.eu/repositories/
repoviewtitle = "Fedora 20 repository - %(arch)s"
arches = i386 x86_64
delta = True
max_delta_rpm_size = 800000000
# Change distro_tags as fedora-release version gets bumped
distro_tags = cpe:/o:fedoraproject:fedora:20 Null
hash_packages = True
outputdir = /mnt/repositories/fedora

</syntaxhighlight>

=== Mise en place d'un alias ===

Le répertoire <path>/mnt/repositories</path> doit être accessible par HTTP. On ajoute donc un alias.

Fichier <path>/etc/httpd/conf.d/mash.conf</path>
<syntaxhighlight lang="apache">
Alias /repositories "/mnt/repositories"
<Directory "/mnt/repositories">
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
Options +Indexes
AllowOverride None
<IfModule mod_authz_core.c>
# Apache 2.4
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
# Apache 2.2
Order allow,deny
Allow from all
</IfModule>
</Directory>
</syntaxhighlight>

== Lancement de l'outil ==

=== Setup initial ===
On va simplement créé l'arborescence nécessaire
<syntaxhighlight lang="bash">mkdir /mnt/repos/{fedora,centos}</syntaxhighlight>

=== Création des dépôts ===
Création du dépôt pour CentOS 5
<syntaxhighlight lang="bash">mash 5</syntaxhighlight>
Création du dépôt pour CentOS 6
<syntaxhighlight lang="bash">mash 6</syntaxhighlight>
Création du dépôt pour Fedora 20
<syntaxhighlight lang="bash">mash 20</syntaxhighlight>

== F.A.Q. ==
{{Admon/faq|Erreur yum.Errors.RpmDBError: Package tuple could not be found in rpmdb|Cette erreur se rencontre après avoir mis à jour <package>yum</package>

Ce bug est répertorié chez RedHat<ref>https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=920758</ref>

La correction est triviale, Il faut appliquer le patch suivant au fichier <path>/usr/lib/python2.6/site-packages/yum/depsolve.py</path>( _checkFileRequires() caches the file requires of installed or to-be installed packages. Update it when removing packages in TS_INSTALL_STATES from transaction).<ref>http://lists.baseurl.org/pipermail/yum-devel/2013-March/010022.html</ref>
<syntaxhighlight lang="diff">
diff -up a/depsolve.py b/depsolve.py
--- a/depsolve.py 2014-01-14 14:51:27.288392585 +0100
+++ b/depsolve.py.new 2014-01-14 14:51:17.683392467 +0100
@@ -808,6 +808,8 @@ class Depsolve(object):
# Have to deal with loops!
continue
self.tsInfo.remove(otxmbr.pkgtup)
+ ifr = self.installedFileRequires or {}
+ ifr.pop(otxmbr.pkgtup, None)
# We need to remove an obsoleted entry that
# was maybe used to resolve something ... ?
CheckDeps = True
</syntaxhighlight>
}}

== Références ==
<references/>

[[Catégorie:RPM]]
[[Catégorie:Koji]]
[[Catégorie:Server]]

RPM/Mash

2017-04-20T09:42:12Z

Didier : Page créée avec « '''Mash''' == Présentation == <app>Mash</app> est un outil qui interroge Koji afin d'obtenir les RPMs pour un tag donné et qui créer un dépôt directement ut... »

'''Mash'''

== Présentation ==
<app>Mash</app> est un outil qui interroge [[Koji|Koji]] afin d'obtenir les RPMs pour un tag donné et qui créer un dépôt directement utilisable avec ceux-ci.

== Installation ==
yum install mash

== Configuration ==

=== Configuration générale de mash ===

Fichier <path>/etc/mash/mash.conf</path>
<syntaxhighlight lang="ini">

[defaults]
configdir = /etc/mash
buildhost = http://koji.b2pweb.com/kojihub
repodir = file:///mnt/koji
use_sqlite = True
use_repoview = True

</syntaxhighlight>

=== Configuration du dépôt pour CentOS 5 ===

Par défaut, {{package|mash}} créé une somme de vérification avec l'algorythme sha256, ce qui est incompatible avec CentOS 5. On doit donc lui préciser d'utiliser l'algorythme sha1 en lieu et place.

Fichier <path>/etc/mash/centos5.mash</path>
<syntaxhighlight lang="ini">
# mash config file

[5]
rpm_path = os/RPMS/%(arch)s/
repodata_path = os/RPMS/%(arch)s/
source_path = os/SRPMS
debuginfo = True
debuginfo_path = debug/%(arch)s/
multilib = True
multilib_method = devel
tag = centos-5
inherit = True
strict_keys = True
keys = 22B3B81A, 1ACA3465, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9, 773DF357
repoviewurl = http://koji.tartarefr.eu/repositories/
repoviewtitle = "CentOS 5 repository - %(arch)s"
arches = i386 x86_64
delta = True
# Change distro_tags as fedora-release version gets bumped
#distro_tags = cpe:/o:fedoraproject:fedora:17 rawhide
distro_tags = cpe:/o:centos:centos:5 centos-5
hash_packages = True
#make_ancient = True
hash = sha1
outputdir = /mnt/repos/centos
# This forces to also create older version of same package
latest = False

</syntaxhighlight>

=== Configuration du dépôt pour CentOS 6 ===

Fichier <path>/etc/mash/centos6.mash</path>
<syntaxhighlight lang="ini">
# mash config file

[6]
rpm_path = os/RPMS/%(arch)s/
repodata_path = os/RPMS/%(arch)s/
source_path = os/SRPMS
debuginfo = True
debuginfo_path = debug/%(arch)s/
multilib = True
multilib_method = devel
tag = centos-6
inherit = True
strict_keys = True
keys = 22B3B81A, 1ACA3465, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9, D3F3C56A
repoviewurl = http://koji.tartarefr.eu/repositories/
repoviewtitle = "CentOS 6 repository - %(arch)s"
arches = i386 x86_64
delta = True
# Change distro_tags as fedora-release version gets bumped
distro_tags = cpe:/o:centos:centos:6 centos-6
hash_packages = True
outputdir = /mnt/repos/centos
# This forces to also create older version of same package
latest = False

</syntaxhighlight>

=== Configuration du dépôt pour fedora 20 ===

Le fichier existe déjà (installé en même temps que <app>mash</app>). Seul la version de fedora s'incrémente au fur et à mesure des sorties de la distribution.

Fichier <path>/etc/mash/branched.mash</path>
<syntaxhighlight lang="ini">
# mash config file

[20]
rpm_path = os/RPMS/%(arch)s/
repodata_path = os/RPMS/%(arch)s/
source_path = os/SRPMS
debuginfo = True
debuginfo_path = debug/%(arch)s/
multilib = True
multilib_method = devel
tag = fedora-20
inherit = True
strict_keys = True
keys = 246110C1
repoviewurl = http://koji.tartarefr.eu/repositories/
repoviewtitle = "Fedora 20 repository - %(arch)s"
arches = i386 x86_64
delta = True
max_delta_rpm_size = 800000000
# Change distro_tags as fedora-release version gets bumped
distro_tags = cpe:/o:fedoraproject:fedora:20 Null
hash_packages = True
outputdir = /mnt/repositories/fedora

</syntaxhighlight>

=== Mise en place d'un alias ===

Le répertoire <path>/mnt/repositories</path> doit être accessible par HTTP. On ajoute donc un alias.

Fichier <path>/etc/httpd/conf.d/mash.conf</path>
<syntaxhighlight lang="apache">
Alias /repositories "/mnt/repositories"
<Directory "/mnt/repositories">
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
Options +Indexes
AllowOverride None
<IfModule mod_authz_core.c>
# Apache 2.4
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
# Apache 2.2
Order allow,deny
Allow from all
</IfModule>
</Directory>
</syntaxhighlight>

== Lancement de l'outil ==

=== Setup initial ===
On va simplement créé l'arborescence nécessaire
<syntaxhighlight lang="bash">mkdir /mnt/repos/{fedora,centos}</syntaxhighlight>

=== Création des dépôts ===
Création du dépôt pour CentOS 5
<syntaxhighlight lang="bash">mash 5</syntaxhighlight>
Création du dépôt pour CentOS 6
<syntaxhighlight lang="bash">mash 6</syntaxhighlight>
Création du dépôt pour Fedora 20
<syntaxhighlight lang="bash">mash 20</syntaxhighlight>

== F.A.Q. ==
{{Admon/faq|Erreur yum.Errors.RpmDBError: Package tuple could not be found in rpmdb|Cette erreur se rencontre après avoir mis à jour <package>yum</package>

Ce bug est répertorié chez RedHat<ref>https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=920758</ref>

La correction est triviale, Il faut appliquer le patch suivant au fichier <path>/usr/lib/python2.6/site-packages/yum/depsolve.py</path>( _checkFileRequires() caches the file requires of installed or to-be installed packages. Update it when removing packages in TS_INSTALL_STATES from transaction).<ref>http://lists.baseurl.org/pipermail/yum-devel/2013-March/010022.html</ref>
<syntaxhighlight lang="diff">
diff -up a/depsolve.py b/depsolve.py
--- a/depsolve.py 2014-01-14 14:51:27.288392585 +0100
+++ b/depsolve.py.new 2014-01-14 14:51:17.683392467 +0100
@@ -808,6 +808,8 @@ class Depsolve(object):
# Have to deal with loops!
continue
self.tsInfo.remove(otxmbr.pkgtup)
+ ifr = self.installedFileRequires or {}
+ ifr.pop(otxmbr.pkgtup, None)
# We need to remove an obsoleted entry that
# was maybe used to resolve something ... ?
CheckDeps = True
</syntaxhighlight>
}}

== Références ==
<references/>

[[Catégorie:RPM]]
[[Catégorie:Koji]]
[[Catégorie:Server]]

Koji/Installation

2017-04-20T09:37:41Z

Didier : Page créée avec « '''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|mo... »

'''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'''<br>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'''<br>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'''<br>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'''<br>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'''<br>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 ]<br>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<br>Cela vous permettra d'accepter directement les valeurs proposées par défaut à la génération des certificats.<br>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]]

Fichier:MockKojiMash.pdf

2017-04-20T09:35:42Z

Didier : RPM Building with Mock, Koji and Mash by Steve Tralen (CERN)

RPM Building with Mock, Koji and Mash by Steve Tralen (CERN)

Fichier:KojiArch.svg

2017-04-20T09:31:58Z

Didier : Koji simplified architecture

Koji simplified architecture

Fichier:IconTextFile16.png

2017-04-20T09:29:20Z

Didier : Icon Plain text 16 pixels

Icon Plain text 16 pixels

Modèle:Admon/file

2017-04-20T09:27:56Z

Didier : Page créée avec « <noinclude>{{high-risk template|pagecount=all pages}}</noinclude><includeonly><div> <div style="background-color: {{{bgcolor|#C1FFE9}}}; border: 1px solid {{{bdcolor|#c4c2... »

<noinclude>{{high-risk template|pagecount=all pages}}</noinclude><includeonly><div>
<div style="background-color: {{{bgcolor|#C1FFE9}}}; border: 1px solid {{{bdcolor|#c4c295}}}; border-radius-top-left: 4px; border-radius-top-right: 4px; color: {{{fgcolor|black}}}; padding: 5px; margin: 1ex 0 -2ex 0;">[[File:IconTextFile16.png]] {{{1}}}</div>
{{{2}}}
</div></includeonly><noinclude>
{{Admon/file|<path>/tmp/path/to/my/file</path>|<pre>
line 1
line 2</pre>
}}
{{tempdoc}}[[Category:Admonition templates]]
</noinclude>

RPM

2017-04-20T09:24:55Z

Didier : /* Environnement de construction */

{{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]]

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

== Environnement de construction ==
* [[RPM/Environnement|Building Environment]]

== Koji ==

=== Installation d'un serveur Koji personnel ===
* [[Koji/Installation|Installation d'un serveur Koji]] pas à pas avec l’authentification SSL.
* Installation d'un repository avec [[RPM/Mash|Mash]]

=== Bootstrap de son serveur Koji ===
* [[Koji/Bootstrap|Bootstrap de Koji]]

=== Utilisation de son serveur Koji ===
* [[Koji/Utilisation|Utilisation de Koji]]
* [[Koji/CLI|Utilisation du client Koji en ligne de commande]]

RPM

2017-04-20T09:23:14Z

Didier : Page créée avec « {{Admon/tip|<big><big>Fedora Packaging</big></big>| * [https://admin.fedoraproject.org FAS Account] * [http://fedoraproject.org/wiki/Packaging:Guidelines Guidelines] * [ht... »

Accueil

2017-04-20T09:15:37Z

Didier :

__NOTITLE__

{| style="margin-top:10px; background:none;"
| style="width:67%; border:1px solid #a7d7f9; vertical-align:top; color:#000; padding: 0px 10px 10px 0px; border-radius:6px;" |
{| cellpadding="2" cellspacing="5" style="width:98%; vertical-align:top; background:transparent;"
| <div id="accueil_titre">{{Accueil/Titre}}
{{Accueil/Fastlink}}
</div>
|-

| {{Accueil/Cadre
|titre = Lumière sur
|id = accueil-lumieresur
|image = IconBookmark32.png
|contenu = <div id="mf-lumieresur" title="Lumière sur">
Le tutorial qui va bien pour écrire des articles sur ce wiki.
</div>
|lien = [[Tuto/Edit|Tutorial]] • [[Tuto/Edit|Tutorial]]
}}

| {{Accueil/Cadre
|titre = Actualités et événements
|id = accueil-actualite
|image = IconCalendar32.png
|contenu = <div id="mf-actualite" title="Actualités et évènements">{{Accueil/news}}</div>
|lien = [[Modèle:Accueil/news|Gérer les actualités]]
}}

| {{Accueil/Cadre
|titre = Le saviez-vous ?
|image = IconQuestion32.png
|contenu = <div id="mf-SaviezVous" title="Le saviez-vous ?">{{Accueil/DoYouKnow}}</div>
|lien = [[Modèle:Accueil/DoYouKnow|Gérer les astuces]]
|id = SaviezVous
}}

|}
| style="border:4px solid transparent;" |

| style="width:33%; border:1px solid #a7d7f9; background:#f5faff; vertical-align:top; padding: 0px 10px 10px 0px; border-radius:6px;"|
{| id="mp-right" cellpadding="2" cellspacing="5" style="width:98%; vertical-align:top; background:#f5faff; background:transparent; text-align: left;"

| {{Accueil/Cadre2
|titre = Image du jour
|image = IconImage32.png
|contenu = <randomimage size="300" float="left" choices="PovrayCityArctic.png | PovrayCityDefault.png | PovrayCityScap.png | PovrayCityWaterlin.png | PovrayGalaxyBigNebula.png | PovrayGalaxyOuterSpace.png | PovrayObjectStarwarsAWing.png | PovrayObjectStarwarsBWing.png | PovrayObjectStarwarsCCRV.png | PovrayObjectStarwarsCloudCity.png | PovrayObjectStarwarsEWing.png | PovrayObjectStarwarsFalcon.png | PovrayObjectStarwarsSTDEST.png | PovrayObjectStarwarsShuttle.png | PovrayObjectStarwarsTieD.png | PovrayObjectStarwarsTieDef.png | PovrayObjectStarwarsTieFighter.png | PovrayObjectStarwarsTieInterceptor.png | PovrayObjectStarwarsXWing.png | PovrayObjectStarwarsYWing.png | PovrayTutoRealisticWater01.png | PovrayTutoRealisticWater02.png | PovrayTutoRealisticWater03.png | PovrayTutoRealisticWater04.png | PovrayTutoRealisticWater05.png | PovrayTutoRealisticWater06.png | PovrayTutoRealisticWater07.png | PovrayTutoRealisticWater08.png | PovrayTutoRealisticWater09.png"></randomimage>
|id = ImageDuJour
}}

| {{Accueil/Cadre2
| image = IconPresentation32.png
| titre = Présentation
| contenu = {{Accueil/Présentation}}
}}

| {{Accueil/Cadre2
| image = IconEdit32.png
| titre = Participation
| contenu = {{Accueil/Participation}}
}}

| {{Accueil/Cadre2
| image = IconCommunity32.png
| titre = Communauté
| contenu = {{Accueil/Communauté}}
}}
|}
|}

{{Accueil/Contact}}
__NOTOC____NOEDITSECTION__

Tuto/Edit

2017-04-20T09:13:12Z

Didier : /* Ajouter une note d'auteur ( simple, importante, avertissement, astuce, auteur original ) */

= Syntaxe =
* Aide générale sur la syntaxe: http://fr.wikipedia.org/wiki/Aide:Syntaxe
* Mot clés de Mediawiki: http://www.mediawiki.org/wiki/Help:Magic_words

= Règle de base =
La recherche dans les pages du wiki ainsi et que la maintenance de celui-ci est grandement facilité par l'ajout de catégorie sur chaque page.

= Modification générale de MediaWiki =
Tous les changements de cette section doivent être édité avec le compte administrateur.
* '''Menu latéral''': [[MediaWiki:Sidebar]]
* '''Ajout de CSS à tous les styles''': [[MediaWiki:Common.css]]
* '''Ajout de CSS pour l'impression''': [[MediaWiki:Print.css]]

= Modules intégrés =
==Upload de fichier==

Page d'aide sur la configuration de l'upload de fichiers <ref>http://www.mediawiki.org/wiki/Manual:Configuring_file_uploads</ref>

==Tableau==
Page d'aide sur les tableaux <ref>http://www.mediawiki.org/wiki/Help:Tables/fr</ref>

Exemple d'utilisation
<pre>
{| class="wikitable"
|+Titre du tableau
!Titre de colonne1
!Titre de colonne2
|-
|Cellule 1 sur la ligne 1
|Cellule 2 sur la ligne 1
|-
|Cellule 1 sur la ligne 2
|Cellule 2 sur la ligne 2
|}
</pre>
{| class="wikitable"
|+Titre du tableau<br>
!Titre de colonne1
!Titre de colonne2
|-
|Cellule 1 sur la ligne 1
|Cellule 2 sur la ligne 1
|-
|Cellule 1 sur la ligne 2
|Cellule 2 sur la ligne 2
|}

= Modules supplémentaires =

* '''CategoryTree''': Afficher une vue en arbre des catégories<ref>http://www.mediawiki.org/wiki/Extension:CategoryTree/fr</ref>
* '''Cite''': Créer des notes de bas de page, collection de références, etc...<ref>http://www.mediawiki.org/wiki/Extension:Cite/Cite.php</ref>
* '''ParserFunctions''': Fonctions avancées pour les extensions<ref>http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions/fr</ref>
* '''Mpdf''': Export de page en PDF<ref>http://www.mediawiki.org/wiki/Extension:Mpdf</ref>
* '''SyntaxHighlight_GeSHi''': Coloration syntaxique de code source<ref>http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi</ref>
* '''RandomImage''': Ajout d'une image aléatoire<ref>http://www.mediawiki.org/wiki/Extension:RandomImage</ref>
* '''SSL_authentification''': Authentification via un certificat<ref>http://www.mediawiki.org/wiki/Extension:SSL_authentication</ref>
* '''CustomTag''': Permet l'usage des tags suivants dans le code wiki ( en ligne )
** '''<nowiki><path></nowiki>''' Affichage du path ex: <path>/home/user</path>
** '''<nowiki><package></nowiki>''' Affichage du nom du paquet ex: <package>perl-ExtUtils-MakeMaker</package>
** '''<nowiki><app></nowiki>''' Affichage du nom de l'application ex: <app>vim</app>
** '''<nowiki><class></nowiki>''' Affichage du nom de la class ex: <class>KVirtualView</class>

= Macros définies permettant un affichage spécial =

== Mettre en valeur un mot ==
* '''class''' pour mettre en valeur un nom de class ( en ligne ) {{class|KVirtual}}
<nowiki>{{class|KVirtual}}</nowiki>
* '''path''' pour mettre en valeur un chemin ( en ligne ), ex: {{path|/home/user}}
<nowiki>{{path|/home/user}}</nowiki>
* '''filename''' pour mettre en valeur un nom de fichier ( en ligne ), ex: {{filename|/etc/mail/aliases}}
<nowiki>{{filename|/etc/mail/aliases}}</nowiki>
* '''package''' pour mettre en valeur un nom de paquet ( en ligne ), ex: {{package|perl-ExtUtils-MakeMaker}}
<nowiki>{{package|perl-ExtUtils-MakeMaker}}</nowiki>
* '''app''' pour mettre en valeur un nom d'application ( en ligne ), ex: {{app|vim}}
<nowiki>{{app|vim}}</nowiki>
* '''code''' pour mettre en valeur un morceau de code ( en ligne ), ex: {{code|find /etc -type f -name '*.conf'}}
<nowiki>{{code|find /etc -type f -name '*.conf'}}</nowiki>
* '''command''' pour mettre en valeur une commande ( en ligne ), ex: {{command|find /etc -type f -name '*.conf'}}
<nowiki>{{command|find /etc -type f -name '*.conf'}}</nowiki>
* '''color''' pour mettre en couleur un mot ( en ligne ), ex: {{color|red|mots en couleur}}
<nowiki>{{color|red|mots en couleur}}</nowiki>

== Ajouter une note d'auteur ( simple, importante, avertissement, astuce, auteur original ) ==
* '''Admon/note''' pour écrire une note d'information
<nowiki>{{Admon/note|Titre|texte optionnel de la note}}</nowiki>
{{Admon/note|Titre|texte optionnel de la note}}
* '''Admon/warning''' pour écrire un avertissement bien visible
<nowiki>{{Admon/warning|Titre|Texte optionnel du warning}}</nowiki>
{{Admon/warning|Titre|Texte optionnel du warning}}
* '''Admon/important''' pour écrire une note très importante
<nowiki>{{Admon/important|Titre|Texte optionnel de la note importante}}</nowiki>
{{Admon/important|Titre|Texte optionnel de la note importante}}
* '''Admon/tip''' pour écrire une astuce bien visible
<nowiki>{{Admon/tip|Titre|Texte optionnel de l'astuce}}</nowiki>
{{Admon/tip|Titre|Texte optionnel de l'astuce}}
* '''Admon/bug''' pour signaler un bug
<nowiki>{{Admon/bug|Titre|Texte optionnel du bug}}</nowiki>
{{Admon/bug|Titre|Texte optionnel du bug}}
* '''Admon/faq''' pour écrire une question réponse
{{Admon/faq|Question|Answer}}
<nowiki>{{Admon/faq|Question|Answer}}</nowiki>
* '''author''' pour afficher les auteurs et les participants éventuels lorsqu'il s'agit d'une page recopié d'un autre wiki.
<nowiki>{{author|author=Auteur original|othersauthors=Liste des participants éventuels (paramètre optionnel)|url=Lien vers l'URL d'origine (paramètre optionnel)}}</nowiki>
{{author|author=Auteur original|othersauthors=Liste des participants éventuels (paramètre optionnel)|url=Lien vers l'URL d'origine (paramètre optionnel)}}

== Smileys ==
* '''Admon/smiley'''
Good Job {{Admon/smiley|:)}}
<nowiki>{{Admon/smiley|:)}}</nowiki>
{{:Modèle:Admon/smiley/example}}

Consultez le [http://meta.wikimedia.org/wiki/Aide:Contenu Guide de l’utilisateur] pour plus d’informations sur l’utilisation de ce logiciel.

= Langages supportés par l'extension de coloration syntaxique =
<nowiki><syntaxhighlight lang="CODE">
</syntaxhighlight></nowiki>

{| class="wikitable" style="float:left;margin-right:20px;"
!Code||Language
|-
|<code>abap</code>||ABAP
|-
|<code>actionscript</code>||ActionScript
|-
|<code>ada</code>||Ada
|-
|<code>apache</code>||Apache Configuration
|-
|<code>applescript</code>||AppleScript
|-
|<code>asm</code>||Assembly
|-
|<code>asp</code>||Active Server Pages (ASP)
|-
|<code>autoit</code>||AutoIt
|-
|<code>bash</code>||Bash
|-
|<code>basic4gl</code>||Basic4GL
|-
|<code>bf</code>||Brainfuck
|-
|<code>blitzbasic</code>||Blitz BASIC
|-
|<code>bnf</code>||Backus-Naur Form
|-
|<code>c</code>||C
|-
|<code>c_mac</code>||C (Mac)
|-
|<code>caddcl</code>||AutoCAD DCL
|-
|<code>cadlisp</code>||AutoLISP
|-
|<code>cfdg</code>||CFDG
|-
|<code>cfm</code>||ColdFusion Markup Language
|-
|<code>cil</code>||Common Intermediate Language (CIL)
|-
|<code>cobol</code>||COBOL
|-
|<code>cpp-qt</code>||C++ (Qt toolkit)
|-
|<code>cpp</code>||C++
|-
|<code>csharp</code>||C#
|-
|<code>css</code>||Cascading Style Sheets (CSS)
|-
|<code>d</code>||D
|-
|<code>delphi</code>||Delphi
|-
|<code>diff</code>||Diff
|-
|<code>div</code>||DIV
|-
|<code>dos</code>||DOS batch file
|-
|<code>dot</code>||DOT
|-
|<code>eiffel</code>||Eiffel
|-
|<code>fortran</code>||Fortran
|-
|<code>freebasic</code>||FreeBASIC
|-
|<code>genero</code>||Genero
|-
|<code>gettext</code>||GNU internationalization (i18n) library
|-
|<code>glsl</code>||OpenGL Shading Language (GLSL)
|-
|<code>gml</code>||Game Maker Language (GML)
|-
|<code>gnuplot</code>||gnuplot
|-
|<code>groovy</code>||Groovy
|-
|<code>haskell</code>||Haskell
|-
|<code>hq9plus</code>||HQ9+
|-
|<code>html4strict</code>||HTML
|-
|<code>idl</code>||Uno IDL
|-
|<code>ini</code>||INI
|-
|<code>inno</code>||Inno
|-
|<code>intercal</code>||INTERCAL
|-
|<code>io</code>||Io
|-
|<code>java</code>||Java
|-
|<code>java5</code>||Java(TM) 2 Platform Standard Edition 5.0
|-
|<code>javascript</code>||JavaScript
|-
|<code>kixtart</code>||KiXtart
|-
|<code>klonec</code>||Klone C
|-
|<code>klonecpp</code>||Klone C++
|-
|<code>latex</code>||LaTeX
|-
|<code>lisp</code>||Lisp
|-
|<code>lolcode</code>||LOLCODE
|-
|<code>lotusscript</code>||LotusScript
|-
|<code>lua</code>||Lua
|}
{| class="wikitable" style="float:left"
!Code||Language
|-
|<code>m68k</code>||Motorola 68000 Assembler
|-
|<code>make</code>||make
|-
|<code>matlab</code>||MATLAB M
|-
|<code>mirc</code>||mIRC scripting language
|-
|<code>mxml</code>||MXML
|-
|<code>mpasm</code>||Microchip Assembler
|-
|<code>mysql</code>||MySQL
|-
|<code>nsis</code>||Nullsoft Scriptable Install System (NSIS)
|-
|<code>objc</code>||Objective-C
|-
|<code>ocaml-brief</code>||OCaml
|-
|<code>ocaml</code>||OCaml
|-
|<code>oobas</code>||OpenOffice.org Basic
|-
|<code>oracle8</code>||Oracle 8 SQL
|-
|<code>oracle11</code>||Oracle 11 SQL
|-
|<code>pascal</code>||Pascal
|-
|<code>per</code>||per
|-
|<code>perl</code>||Perl
|-
|<code>php-brief</code>||PHP
|-
|<code>php</code>||PHP
|-
|<code>pixelbender</code>||Pixel Bender
|-
|<code>plsql</code>||PL/SQL
|-
|<code>povray</code>||Persistence of Vision Raytracer
|-
|<code>powershell</code>||Windows PowerShell
|-
|<code>progress</code>||OpenEdge Advanced Business Language
|-
|<code>prolog</code>||Prolog
|-
|<code>providex</code>||ProvideX
|-
|<code>python</code>||Python
|-
|<code>qbasic</code>||QBasic/QuickBASIC
|-
|<code>rails</code>||Rails
|-
|<code>reg</code>||Windows Registry
|-
|<code>robots</code>||robots.txt
|-
|<code>ruby</code>||Ruby
|-
|<code>sas</code>||SAS
|-
|<code>scala</code>||Scala
|-
|<code>scheme</code>||Scheme
|-
|<code>scilab</code>||Scilab
|-
|<code>sdlbasic</code>||SdlBasic
|-
|<code>smalltalk</code>||Smalltalk
|-
|<code>smarty</code>||Smarty
|-
|<code>sql</code>||SQL
|-
|<code>tcl</code>||Tcl
|-
|<code>teraterm</code>||Tera Term
|-
|<code>text</code>||Plain text
|-
|<code>thinbasic</code>||thinBasic
|-
|<code>tsql</code>||Transact-SQL
|-
|<code>typoscript</code>||TypoScript
|-
|<code>vb</code>||Visual Basic
|-
|<code>vbnet</code>||Visual Basic .NET
|-
|<code>verilog</code>||Verilog
|-
|<code>vhdl</code>||VHDL
|-
|<code>vim</code>||Vimscript
|-
|<code>visualfoxpro</code>||Visual FoxPro
|-
|<code>visualprolog</code>||Visual Prolog
|-
|<code>whitespace</code>||Whitespace
|-
|<code>winbatch</code>||Winbatch
|-
|<code>xml</code>||XML
|-
|<code>xorg_conf</code>||Xorg.conf
|-
|<code>xpp</code>||X++
|-
|<code>z80</code>||ZiLOG Z80 Assembler
|}
<div style="clear:both;"></div>

= Notes =
<references/>

MediaWiki:Print.css

2017-04-20T09:07:32Z

Didier : Page créée avec « /* Le CSS placé ici affectera les impressions */ .printfooter {display: none;} #footer {display: none;} »

/* Le CSS placé ici affectera les impressions */
.printfooter {display: none;}
#footer {display: none;}

MediaWiki:Common.css

2017-04-20T09:07:04Z

Didier :

/* Le CSS placé ici sera appliqué à tous les habillages. */

MediaWiki:Common.css

2017-04-20T09:06:00Z

Didier : Page créée avec « /* Le CSS placé ici sera appliqué à tous les habillages. */ .bluerounded { display:block; background-image:url("https://didier.dnsdynamic.net/wiki/images/b/be/Blue... »

/* Le CSS placé ici sera appliqué à tous les habillages. */

.bluerounded {
display:block;
background-image:url("https://didier.dnsdynamic.net/wiki/images/b/be/BlueBgRounded.png");
background-repeat:no-repeat;
background-position:0 0;
}

.effect3d {
display:block;
background-image:url("https://didier.dnsdynamic.net/wiki/images/1/1a/ItemBg.png");
background-repeat:repeat-x;
background-position:0 50%;
}

Povray/Tutorials/RealisticWater

2017-04-20T06:59:24Z

Didier :

{{author|author=Friedrich A. Lohmüller|url=http://www.f-lohmueller.de/}}

== Une surface de l'eau simple, opaque, plate et réfléchissante ==
{{Povray/tuto|Le plus souvent la surface de l'eau paraît comme un miroir opaque. Pour simuler cette surface il suffit d'ajouter une texture comme 'Polished_Chrome'. L'eau même est transparente, légèrement grisée très clair (L'eau claire n'a pas de couleur !!!).
La couleur d'une surface de l'eau est surtout défini par les objets que se réfléchissent dans la surface. ( Bleu est la couleur de la mer seulement les jours ensoleillés avec un ciel bleu ! L'eau a l'air différente avec des ciels différents ! ).
<syntaxhighlight lang="povray">
plane{<0,1,0>, 0
texture{pigment{rgb <.2,.2,.2>}
finish {ambient 0.15
diffuse 0.55
brilliance 6.0
phong 0.8
phong_size 120
reflection 0.6}
}// end of texture
}// end of plane
</syntaxhighlight>
Si nous avons inséré les définitions des textures, nous pouvons écrire cela plus court :
<syntaxhighlight lang="povray">
#include "textures.inc"
plane{<0,1,0>, 0
texture{ Polished_Chrome }
}// end of plane
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater01.png|300px|vignette|Surface simple, opaque, plate et réfléchissante<br>[[Media:PovrayTutoRealisticWater01.pov|Fichier POVRay correspondant]]]]
}}

== L'eau peu agitée avec reflections des nuages ==
{{Povray/tuto|Des ondes modérées font une surface de l'eau plus réaliste. Nous ajoutons à la texture la commande suivante :
<syntaxhighlight lang="povray">
normal{ bumps 0.03
scale <1,0.25,0.25>*1
turbulence 0.6
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater02.png|300px|vignette|Surface peu agitée avec réflexion<br>[[Media:PovrayTutoRealisticWater02.pov|Fichier POVRay correspondant]]]]
}}

== La mer agitée, la surface de l'eau plus agitée ==

{{Povray/tuto|Nous obtenons cela par ajouter à la texture la commande suivante :
<syntaxhighlight lang="povray">
normal{ bumps 0.3
scale 0.05
turbulence 0.6
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater03.png|300px|vignette|Surface agitée avec bumps<br>[[Media:PovrayTutoRealisticWater03.pov|Fichier POVRay correspondant]]]]
}}
{{Povray/tuto|Aussi un effet très realiste on peut voir par ex. comme cela :
<syntaxhighlight lang="povray">
normal{ crackle 0.15
scale 0.75
turbulence 0.3
translate<-1,0,5>
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater04.png|300px|vignette|Surface agitée avec crackle<br>[[Media:PovrayTutoRealisticWater04.pov|Fichier POVRay correspondant]]]]
}}

== Une surface de l'eau ridée par le vent ==

{{Povray/tuto|Nous obtenons cela avec le motif 'crackle' ou 'bozo' et par ajouter des échelles différentes en direction x et y et aussi une rotation dans la direction transversale au vent :
<syntaxhighlight lang="povray">
normal{ bozo 1.75
scale <2.0,1,0.3>*0.20
rotate<0,10,0>
turbulence 0.9
translate<0,0,-2>
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater05.png|300px|vignette|Surface de l'eau ridée avec bozo<br>[[Media:PovrayTutoRealisticWater05.pov|Fichier POVRay correspondant]]]]
}}

{{Povray/tuto|L'effet ressemblent avec 'crackle':
<syntaxhighlight lang="povray">
normal{ pigment_pattern{
crackle
colour_map { [0, rgb 0]
[1, rgb 1] }
turbulence 1.7
translate <0,0,1>}
0.5}
scale <2.0,1,0.3>*2
rotate<0,10,0>
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater06.png|300px|vignette|Surface de l'eau ridée avec crackle<br>[[Media:PovrayTutoRealisticWater06.pov|Fichier POVRay correspondant]]]]
}}

Remarque : Tout cela sont seulement des simulations des surfaces ondulées! Géométriquement, ils sont toujours parfaitement plat. Pour obtenir des des surfaces tridimensionnelles ondulées, il faut beaucoup plus ! Voir ici et ici !

== Une surface de l'eau partiellement transparente et réfléchissante ==

{{Povray/tuto|Si l'eau paraît partiellement transparente et réfléchissante, nous pouvons simuler en utilisant la texture 'Glass3' (l'eau clair) ou 'Green_Glass' (l'eau verdie par des plantes aquatiques !). Dans ce cas le fond sous-marin doit être bien défini. Le fond a une grande influence sur l'apparence de la surface de l'eau!

<syntaxhighlight lang="povray">
plane{<0,1,0>, 0 translate<0,-3,0>
texture{pigment{color LightWood}
normal {bumps 0.25
scale 0.05}
finish {ambient 0.45
diffuse 0.55}
}// end of texture
}// end of plane 1

plane{<0,1,0>, 0
texture{ Green_Glass
normal{ripples 0.3
scale 0.25
turbulence 0.75
translate< 1,0,2>}
finish{ambient 0.45
diffuse 0.55
reflection 0.3}
}// end of texture
interior{I_Glass}
}// end of plane 2
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater07.png|300px|vignette|Surface de l'eau partiellement transparente et réfléchissante<br>[[Media:PovrayTutoRealisticWater07.pov|Fichier POVRay correspondant]]]]
}}

== Ondes concentriques autour d'un poteau ==

{{Povray/tuto|<syntaxhighlight lang="povray">
plane{<0,1,0>, 0
texture{ Green_Glass
normal{ripples 0.3
scale 0.25
turbulence 0.5
translate< 1,0,2>}
finish{ambient 0.45
diffuse 0.55
reflection 0.3}
}// end of texture
interior{I_Glass}
}// end of plane 2
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater08.png|300px|vignette|Ondes concentriques<br>[[Media:PovrayTutoRealisticWater08.pov|Fichier POVRay correspondant]]]]
}}
== Un trou dans l'eau - un tourbillon ==

{{Povray/tuto|
Cela peut être fait avec quelques fonctions simples de CSG. À la fin nous devons appliquer une texture avec un composant 'normal' approprié sur le plan pour simuler le tourbillon de l'eau.
Pour plus de clarté un quart du plan a été retiré.
# Nous prenons un plan xz ( plane{<0,1,0>,0} ) et un cylindre un peu plus haut. pour éviter des surfaces coïncidentes dans une 'difference'.<br>[[Fichier:PovrayTutoWaterHole01.jpg]]
# Nous soustrayons ce cylindre du notre plan. Nous obtenons un trou avec un arête vive.<br>[[Fichier:PovrayTutoWaterHole02.jpg]]
# Pour arrondir cet arête vive nous prenons un autre cylindere avec le rayon agrandi du rayon du bords ronds.<br>[[Fichier:PovrayTutoWaterHole03.jpg]]
# Encore une fois nous soustrayons ce deuxième cylindre ! <br>[[Fichier:PovrayTutoWaterHole04.jpg]]
# Puis nous ajoutons un tore (un anneau) avec le rayon majeur <nowiki>=</nowiki> rayon de notre deuxième cylindre et le rayon mineur <nowiki>=</nowiki> rayon du bords ronds.<br>[[Fichier:PovrayTutoWaterHole05.jpg]]
# La construction est fini!<br>[[Fichier:PovrayTutoWaterHole06.jpg]]
À la fin nous ajoutons à la texture de l'eau, une normale come cela :
<syntaxhighlight lang="povray">
normal {spiral1 20 0.25
sine_wave
turbulence 0.1
rotate<90,0,0>
scale 0.5
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater09.png|300px|vignette|Un tourbillon<br>[[Media:PovrayTutoRealisticWater09.pov|Fichier POVRay correspondant]]]]
}}

Modèle:Author

2017-04-20T06:56:50Z

Didier :

<noinclude>{{high-risk template|pagecount=all pages}}</noinclude>
{{message|{{#if:{{{author|}}}|Auteur initial '''{{{author}}}'''<br>}}{{#if:{{{othersauthors|}}}|Avec la participation de '''{{{othersauthors}}}'''<br>}}{{#if:{{{url|}}}|Source: {{{url}}}}}|image=IconUser48.png|bgcolor=#def3fe|bdcolor=#c5d7e0}}
<noinclude>{{tempdoc}}[[Category:Admonition templates]]</noinclude>

Modèle:Author

2017-04-20T06:53:30Z

Didier :

<noinclude>{{high-risk template|pagecount=all pages}}</noinclude>
{{message|{{#if:{{{author|}}}|Auteur initial '''{{{author}}}'''<br>}}{{#if:{{{othersauthors|}}}|Avec la participation de '''{{{othersauthors}}}'''}}{{#if:{{{url|}}}|<br>Source: {{{url}}}}}|image=IconUser48.png|bgcolor=#def3fe|bdcolor=#c5d7e0}}
<noinclude>{{tempdoc}}[[Category:Admonition templates]]</noinclude>

Povray/Tutorials/RealisticWater

2017-04-20T06:50:22Z

Didier :

{{author|author=Friedrich A. Lohmüller|url=http://www.f-lohmueller.de/pov_tut/backgrnd/p_wat1.htm}}

== Une surface de l'eau simple, opaque, plate et réfléchissante ==
{{Povray/tuto|Le plus souvent la surface de l'eau paraît comme un miroir opaque. Pour simuler cette surface il suffit d'ajouter une texture comme 'Polished_Chrome'. L'eau même est transparente, légèrement grisée très clair (L'eau claire n'a pas de couleur !!!).
La couleur d'une surface de l'eau est surtout défini par les objets que se réfléchissent dans la surface. ( Bleu est la couleur de la mer seulement les jours ensoleillés avec un ciel bleu ! L'eau a l'air différente avec des ciels différents ! ).
<syntaxhighlight lang="povray">
plane{<0,1,0>, 0
texture{pigment{rgb <.2,.2,.2>}
finish {ambient 0.15
diffuse 0.55
brilliance 6.0
phong 0.8
phong_size 120
reflection 0.6}
}// end of texture
}// end of plane
</syntaxhighlight>
Si nous avons inséré les définitions des textures, nous pouvons écrire cela plus court :
<syntaxhighlight lang="povray">
#include "textures.inc"
plane{<0,1,0>, 0
texture{ Polished_Chrome }
}// end of plane
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater01.png|300px|vignette|Surface simple, opaque, plate et réfléchissante<br>[[Media:PovrayTutoRealisticWater01.pov|Fichier POVRay correspondant]]]]
}}

== L'eau peu agitée avec reflections des nuages ==
{{Povray/tuto|Des ondes modérées font une surface de l'eau plus réaliste. Nous ajoutons à la texture la commande suivante :
<syntaxhighlight lang="povray">
normal{ bumps 0.03
scale <1,0.25,0.25>*1
turbulence 0.6
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater02.png|300px|vignette|Surface peu agitée avec réflexion<br>[[Media:PovrayTutoRealisticWater02.pov|Fichier POVRay correspondant]]]]
}}

== La mer agitée, la surface de l'eau plus agitée ==

{{Povray/tuto|Nous obtenons cela par ajouter à la texture la commande suivante :
<syntaxhighlight lang="povray">
normal{ bumps 0.3
scale 0.05
turbulence 0.6
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater03.png|300px|vignette|Surface agitée avec bumps<br>[[Media:PovrayTutoRealisticWater03.pov|Fichier POVRay correspondant]]]]
}}
{{Povray/tuto|Aussi un effet très realiste on peut voir par ex. comme cela :
<syntaxhighlight lang="povray">
normal{ crackle 0.15
scale 0.75
turbulence 0.3
translate<-1,0,5>
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater04.png|300px|vignette|Surface agitée avec crackle<br>[[Media:PovrayTutoRealisticWater04.pov|Fichier POVRay correspondant]]]]
}}

== Une surface de l'eau ridée par le vent ==

{{Povray/tuto|Nous obtenons cela avec le motif 'crackle' ou 'bozo' et par ajouter des échelles différentes en direction x et y et aussi une rotation dans la direction transversale au vent :
<syntaxhighlight lang="povray">
normal{ bozo 1.75
scale <2.0,1,0.3>*0.20
rotate<0,10,0>
turbulence 0.9
translate<0,0,-2>
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater05.png|300px|vignette|Surface de l'eau ridée avec bozo<br>[[Media:PovrayTutoRealisticWater05.pov|Fichier POVRay correspondant]]]]
}}

{{Povray/tuto|L'effet ressemblent avec 'crackle':
<syntaxhighlight lang="povray">
normal{ pigment_pattern{
crackle
colour_map { [0, rgb 0]
[1, rgb 1] }
turbulence 1.7
translate <0,0,1>}
0.5}
scale <2.0,1,0.3>*2
rotate<0,10,0>
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater06.png|300px|vignette|Surface de l'eau ridée avec crackle<br>[[Media:PovrayTutoRealisticWater06.pov|Fichier POVRay correspondant]]]]
}}

Remarque : Tout cela sont seulement des simulations des surfaces ondulées! Géométriquement, ils sont toujours parfaitement plat. Pour obtenir des des surfaces tridimensionnelles ondulées, il faut beaucoup plus ! Voir ici et ici !

== Une surface de l'eau partiellement transparente et réfléchissante ==

{{Povray/tuto|Si l'eau paraît partiellement transparente et réfléchissante, nous pouvons simuler en utilisant la texture 'Glass3' (l'eau clair) ou 'Green_Glass' (l'eau verdie par des plantes aquatiques !). Dans ce cas le fond sous-marin doit être bien défini. Le fond a une grande influence sur l'apparence de la surface de l'eau!

<syntaxhighlight lang="povray">
plane{<0,1,0>, 0 translate<0,-3,0>
texture{pigment{color LightWood}
normal {bumps 0.25
scale 0.05}
finish {ambient 0.45
diffuse 0.55}
}// end of texture
}// end of plane 1

plane{<0,1,0>, 0
texture{ Green_Glass
normal{ripples 0.3
scale 0.25
turbulence 0.75
translate< 1,0,2>}
finish{ambient 0.45
diffuse 0.55
reflection 0.3}
}// end of texture
interior{I_Glass}
}// end of plane 2
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater07.png|300px|vignette|Surface de l'eau partiellement transparente et réfléchissante<br>[[Media:PovrayTutoRealisticWater07.pov|Fichier POVRay correspondant]]]]
}}

== Ondes concentriques autour d'un poteau ==

{{Povray/tuto|<syntaxhighlight lang="povray">
plane{<0,1,0>, 0
texture{ Green_Glass
normal{ripples 0.3
scale 0.25
turbulence 0.5
translate< 1,0,2>}
finish{ambient 0.45
diffuse 0.55
reflection 0.3}
}// end of texture
interior{I_Glass}
}// end of plane 2
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater08.png|300px|vignette|Ondes concentriques<br>[[Media:PovrayTutoRealisticWater08.pov|Fichier POVRay correspondant]]]]
}}
== Un trou dans l'eau - un tourbillon ==

{{Povray/tuto|
Cela peut être fait avec quelques fonctions simples de CSG. À la fin nous devons appliquer une texture avec un composant 'normal' approprié sur le plan pour simuler le tourbillon de l'eau.
Pour plus de clarté un quart du plan a été retiré.
# Nous prenons un plan xz ( plane{<0,1,0>,0} ) et un cylindre un peu plus haut. pour éviter des surfaces coïncidentes dans une 'difference'.<br>[[Fichier:PovrayTutoWaterHole01.jpg]]
# Nous soustrayons ce cylindre du notre plan. Nous obtenons un trou avec un arête vive.<br>[[Fichier:PovrayTutoWaterHole02.jpg]]
# Pour arrondir cet arête vive nous prenons un autre cylindere avec le rayon agrandi du rayon du bords ronds.<br>[[Fichier:PovrayTutoWaterHole03.jpg]]
# Encore une fois nous soustrayons ce deuxième cylindre ! <br>[[Fichier:PovrayTutoWaterHole04.jpg]]
# Puis nous ajoutons un tore (un anneau) avec le rayon majeur <nowiki>=</nowiki> rayon de notre deuxième cylindre et le rayon mineur <nowiki>=</nowiki> rayon du bords ronds.<br>[[Fichier:PovrayTutoWaterHole05.jpg]]
# La construction est fini!<br>[[Fichier:PovrayTutoWaterHole06.jpg]]
À la fin nous ajoutons à la texture de l'eau, une normale come cela :
<syntaxhighlight lang="povray">
normal {spiral1 20 0.25
sine_wave
turbulence 0.1
rotate<90,0,0>
scale 0.5
}
</syntaxhighlight>
| [[Fichier:PovrayTutoRealisticWater09.png|300px|vignette|Un tourbillon<br>[[Media:PovrayTutoRealisticWater09.pov|Fichier POVRay correspondant]]]]
}}

Fichier:PovrayLensEffectWater.png

2017-04-19T16:13:04Z

Didier : Lens Effect on Water

Lens Effect on Water

Fichier:PovrayLensEffectCandles.png

2017-04-19T16:12:23Z

Didier : Lens effect with candles

Lens effect with candles

Fichier:PovrayGalaxyOuterSpace.png

2017-04-19T16:12:00Z

Didier : Outer space

Outer space

Fichier:PovrayGalaxyBigNebula.png

2017-04-19T16:11:32Z

Didier : Big Nebula

Big Nebula

Fichier:PovrayCityWaterlin.png

2017-04-19T16:11:05Z

Didier : City and Water line

City and Water line

Fichier:PovrayCityScap.png

2017-04-19T16:07:29Z

Didier : City Scap

City Scap