cedricAbonnel/abonnel-siteweb
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Initialisation

Browse Source
This commit is contained in:
Cédric Abonnel
2024-01-07 10:02:35 +01:00
commit b7291133a3
4418 changed files with 169147 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

179
data/pages/informatique/serveur/castopod/docker-compose.txt Normal file
View File

@@ -0,0 +1,179 @@
====== docker-compose.yml ======
{{ :dummy.png?75x75|Castopod > docker compose}}
Cette configuration définit un ensemble de services Docker qui sont utilisés pour déployer l'application Castopod, une plateforme de gestion de podcasts.
<code yaml>
version: "3.7"
services:
app:
image: castopod/app:latest
container_name: "castopod-app"
volumes:
- castopod-media:/opt/castopod/public/media
environment:
MYSQL_DATABASE: castopod
MYSQL_USER: castopod
MYSQL_PASSWORD: changeme
CP_BASEURL: "https://lesconteslinux.mindcast.fr"
CP_ANALYTICS_SALT: changeme
CP_CACHE_HANDLER: redis
CP_REDIS_HOST: redis
networks:
- castopod-app
restart: unless-stopped
redis:
image: redis:7.0-alpine
container_name: "castopod-redis"
volumes:
- castopod-cache:/data
networks:
- castopod-app
# this container is optional
# add this if you want to use the videoclips feature
video-clipper:
image: castopod/video-clipper:latest
container_name: "castopod-video-clipper"
volumes:
- castopod-media:/opt/castopod/public/media
environment:
MYSQL_DATABASE: castopod
MYSQL_USER: castopod
MYSQL_PASSWORD: changeme
restart: unless-stopped
volumes:
castopod-media:
castopod-cache:
networks:
castopod-app:
</code>
Les services déclarés sont les suivants :
1. Le service **"app"** :
* Utilise l'image Docker **"castopod/app:latest"** pour exécuter l'application Castopod.
* Le nom du conteneur est défini comme **"castopod-app"**.
* Montre un volume nommé **"castopod-media"** dans le répertoire **"/opt/castopod/public/media"** du conteneur, qui est utilisé pour stocker les fichiers médias des podcasts.
* Définit plusieurs variables d'environnement liées à la base de données MySQL utilisée par Castopod, y compris le nom de la base de données, l'utilisateur et le mot de passe.
* Définit également d'autres variables d'environnement, telles que l'URL de base de Castopod, le sel pour les analyses, le gestionnaire de cache utilisé (Redis), et l'hôte Redis.
* Appartient au réseau **"castopod-app"**.
* Le redémarrage du conteneur est défini sur **"unless-stopped"**, ce qui signifie qu'il sera redémarré automatiquement sauf s'il est arrêté explicitement.
2. Le service **"redis"** :
* Utilise l'image Docker **"redis:7.0-alpine"** pour exécuter une instance Redis, qui est utilisée par Castopod comme gestionnaire de cache.
* Le nom du conteneur est défini comme **"castopod-redis"**.
* Montre un volume nommé **"castopod-cache"** dans le répertoire **"/data"** du conteneur, qui est utilisé pour stocker les données de cache de Redis.
* Appartient également au réseau **"castopod-app"**.
3. Le service **"video-clipper"** (optionnel) :
* Utilise l'image Docker **"castopod/video-clipper:latest"** pour exécuter un conteneur dédié à la fonctionnalité de découpage vidéo de Castopod.
* Le nom du conteneur est défini comme **"castopod-video-clipper"**.
* Montre le même volume **"castopod-media"** que le service **"app"**, ce qui permet au conteneur d'accéder aux fichiers médias des podcasts.
* Définit les mêmes variables d'environnement pour la base de données MySQL que le service **"app"**.
* Le redémarrage du conteneur est également défini sur **"unless-stopped"**.
En outre, la configuration définit deux volumes Docker nommés **"castopod-media"** et **"castopod-cache"**, qui sont utilisés pour stocker respectivement les fichiers médias des podcasts et les données de cache de Redis. De plus, un réseau nommé **"castopod-app"** est créé pour permettre la communication entre les services.
Cette configuration permet donc de déployer l'application Castopod avec une base de données MySQL et une instance Redis pour la gestion du cache.
===== Concernant les variables à modifier =====
Voici les variables modifiables présentes dans la section ''environment'' de chaque service :
Pour le service "**app**" :
* ''MYSQL_DATABASE'' : Nom de la base de données MySQL utilisée par Castopod.
* ''MYSQL_USER'' : Nom d'utilisateur MySQL pour Castopod.
* ''MYSQL_PASSWORD'' : Mot de passe MySQL pour Castopod.
* ''CP_BASEURL'' : URL de base pour Castopod.
* ''CP_ANALYTICS_SALT'' : Sel utilisé pour les analyses.
Pour le service "**video-clipper**" (optionnel) :
* ''MYSQL_DATABASE'' : Nom de la base de données MySQL utilisée par Castopod.
* ''MYSQL_USER'' : Nom d'utilisateur MySQL pour Castopod.
* ''MYSQL_PASSWORD'' : Mot de passe MySQL pour Castopod.
Vous pouvez modifier ces variables en fonction de vos besoins spécifiques en leur attribuant les valeurs souhaitées. Par exemple, vous pouvez changer le nom de la base de données, l'utilisateur et le mot de passe MySQL, ainsi que l'URL de base pour Castopod, le sel pour les analyses. Assurez-vous de respecter les contraintes et les configurations requises par l'application Castopod lors de la modification de ces variables.
===== Concernant les volumes =====
Pour définir les volumes dans la configuration Docker Compose, vous utilisez la section ''volumes'' du fichier YAML. Voici comment faire :
<code yaml>
version: "**3.7"
services:
app:
image: castopod/app:latest
container_name: "**castopod-app"
volumes:
- castopod-media:/opt/castopod/public/media
# ...
redis:
image: redis:7.0-alpine
container_name: "**castopod-redis"
volumes:
- castopod-cache:/data
# ...
volumes:
castopod-media:
castopod-cache:
</code>
Dans cet exemple, nous avons ajouté la section ''volumes'' à la fin du fichier YAML. À l'intérieur de cette section, vous déclarez vos volumes en utilisant un nom de volume suivi des deux-points '':''. Les noms de volume ici sont "**castopod-media**" et "**castopod-cache**".
Ensuite, vous pouvez référencer ces volumes dans la section ''volumes'' des services concernés en utilisant la syntaxe ''<nom du volume>:<chemin du montage dans le conteneur>''. Dans l'exemple ci-dessus, le volume "**castopod-media**" est monté dans le répertoire ''/opt/castopod/public/media'' du conteneur du service "**app**", et le volume "**castopod-cache**" est monté dans le répertoire ''/data'' du conteneur du service "**redis**".
En définissant les volumes de cette manière, Docker va créer les volumes persistants nécessaires pour les conteneurs et les associer à leurs répertoires respectifs à chaque exécution.
N'oubliez pas que si vous avez plusieurs services utilisant les mêmes volumes, ils auront accès aux mêmes données persistantes, ce qui peut être utile pour le partage de données entre les conteneurs.
Voici un exemple de configurations que vous pouvez utiliser pour les volumes "**castopod-media**" et "**castopod-cache**" dans votre fichier Docker Compose :
1. Utilisation d'un chemin local sur la machine hôte :
<code yaml>
volumes:
castopod-media:
driver: local
driver_opts:
type: none
o: bind
device: /chemin/vers/le/dossier/media
castopod-cache:
driver: local
driver_opts:
type: none
o: bind
device: /chemin/vers/le/dossier/cache
</code>
Dans cet exemple, nous utilisons des volumes de type "**local**" pour lier des dossiers locaux sur la machine hôte aux conteneurs. Vous devez remplacer "**/chemin/vers/le/dossier/media**" et "**/chemin/vers/le/dossier/cache**" par les chemins réels vers les dossiers que vous souhaitez utiliser pour stocker les données du volume.
2. Utilisation de volumes nommés :
<code yaml>
volumes:
castopod-media:
castopod-cache:
</code>
Dans cet exemple, nous déclarons simplement les volumes "**castopod-media**" et "**castopod-cache**" sans spécifier de configuration supplémentaire. Dans ce cas, Docker va créer et gérer les volumes automatiquement dans un emplacement par défaut sur le système de fichiers du système d'hébergement Docker.
===== Concernant l'option restart =====
Dans le contexte de la configuration Docker Compose, la ligne ''restart: unless-stopped'' est spécifiée pour les services "**app**" et "**video-clipper**".
Lorsque vous utilisez ''restart: unless-stopped'', cela signifie que Docker va automatiquement redémarrer le conteneur en cas d'arrêt, sauf si vous arrêtez explicitement le conteneur manuellement en utilisant une commande Docker, par exemple ''docker stop castopod-app''.
Cela garantit que le conteneur est toujours en cours d'exécution, sauf si vous décidez de l'arrêter de manière explicite. Cela peut être utile pour s'assurer que les services sont toujours disponibles et fonctionnent de manière continue, même après un redémarrage du système ou un arrêt inattendu.
Cette option de redémarrage automatique peut être configurée avec d'autres valeurs, telles que ''always'', ''on-failure'', ''unless-stopped''.

77
data/pages/informatique/serveur/dovecot.txt Normal file
View File

@@ -0,0 +1,77 @@
====== Dovecot - fournisseur IMAP ======
{{ :dummy.png?75x75}}
**Dovecot** est un serveur de messagerie populaire, open source basé sur le protocole **IMAP** (Internet Message Access Protocol).
**
Dovecot** permet aux utilisateurs de recevoir et gérer leurs emails en utilisant le protocole IMAP. IMAP est un protocole de messagerie qui permet de synchroniser les emails entre plusieurs appareils, de sorte que vous pouvez accéder à vos emails n'importe où et n'importe quand. **Dovecot** est une implémentation populaire et fiable de ce protocole, utilisée par de nombreux fournisseurs de messagerie pour leur service de messagerie.
L'un des avantages de l'utilisation du protocole **IMAP** est que vous n'avez pas besoin de télécharger vos emails sur chaque appareil que vous utilisez pour les consulter. Au lieu de cela, vous pouvez accéder à vos emails en temps réel sur tous vos appareils, et les actions que vous effectuez sur un appareil (comme lire un email, le marquer comme lu, ou le déplacer dans un dossier) seront automatiquement synchronisées avec les autres appareils. Cela signifie que vous avez toujours une vue à jour de vos emails, peu importe où vous vous trouvez.
===== Certificat IMAP =====
L'utilisation d'un certificat pour IMAP est importante pour garantir la sécurité des communications entre le client et le serveur.
Les certificats pour IMAP sont généralement stockés dans le répertoire de configuration de votre serveur de messagerie, qui dépend de votre implémentation spécifique d'IMAP. Sur un système **Debian** avec **Dovecot**, vous pouvez trouver les certificats dans le répertoire ''/etc/dovecot/private/''. Ce répertoire peut inclure des fichiers tels que le certificat SSL, la clé privée et d'autres informations de sécurité nécessaires à la configuration de Dovecot. Il est important de s'assurer que les fichiers de certificat sont protégés et accessibles uniquement aux utilisateurs autorisés pour garantir la sécurité du système.
Voir l'article : [[:journal_geek:2023:20230209-verifier-la-date-d-un-certificat]]
--
Vous pouvez utiliser la commande OpenSSL pour afficher les informations d'une clé privée. La syntaxe de base pour afficher les informations d'une clé privée est la suivante :
openssl x509 -noout -text -in /etc/dovecot/private/dovecot.pem
Pour afficher uniquement les dates associées à la clé, vous pouvez utiliser la commande suivante:
openssl x509 -noout -in /etc/dovecot/private/dovecot.pem -enddate -startdate
===== Redémarrage de Dovecot =====
Il est généralement conseillé de redémarrer Dovecot pour prendre en compte les mises à jour de la configuration ou pour résoudre les problèmes de fonctionnement. Cependant, il est important de faire attention à la fréquence à laquelle vous redémarrez le service, car un redémarrage excessif peut entraîner une interruption temporaire du service et affecter les utilisateurs connectés.
Il est donc conseillé de programmer un redémarrage de Dovecot uniquement lorsque cela est absolument nécessaire, par exemple lorsque vous apportez des modifications importantes à la configuration ou lorsque vous effectuez des mises à jour du logiciel Dovecot. Il est également important de planifier le redémarrage de Dovecot en dehors des heures de pointe pour minimiser l'impact sur les utilisateurs.
sudo systemctl restart dovecot
--
Voici un exemple de script **bash** pour tester la date d'expiration de ''mx.exemple.fr:993'' et pour redémarrer le service Dovecot s'il est à moins de 10 jours de l'expiration, et pour envoyer un e-mail à ''toto@example.fr'' si le redémarrage n'a pas résolu le problème :
<code BASH [enable_line_numbers="true", start_line_numbers_at="1"]>
#!/bin/bash
delay_expiration=10
# Tester la date d'expiration de mx.exemple.fr:993
expiration_date=$(echo | openssl s_client -connect mx.exemple.fr:993 -servername mx.exemple.fr 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
# Convertir la date d'expiration en timestamp
expiration_timestamp=$(date -d "$expiration_date" +%s)
# Calculer le nombre de jours restants jusqu'à l'expiration
today_timestamp=$(date +%s)
diff=$(( (expiration_timestamp - today_timestamp) / 86400 ))
# Si le nombre de jours restants est inférieur à 10, redémarrer Dovecot
if [ $diff -lt $delay_expiration ]; then
sudo systemctl restart dovecot
# Tester à nouveau la date d'expiration de mx.exemple.fr:993
new_expiration_date=$(echo | openssl s_client -connect mx.exemple.fr:993 -servername mx.exemple.fr 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
new_expiration_timestamp=$(date -d "$new_expiration_date" +%s)
new_diff=$(( (new_expiration_timestamp - today_timestamp) / 86400 ))
# Si la date d'expiration n'a pas été résolue, envoyer un e-mail à toto@exemple.fr
if [ $new_diff -lt $delay_expiration ]; then
echo "Le certificat de mx.exemple.fr:993 est proche de son expiration." | mail -s "[ALERTE] Expiration SSL mx.exemple.fr:993 - $new_diff jours restants" toto@exemple.fr
fi
fi
</code>
Vous pouvez planifier ce script en utilisant crontab pour le faire exécuter à intervalles réguliers. Par exemple, vous pouvez le faire exécuter tous les jours à 4 heures du matin en ajoutant la ligne suivante à votre **crontab** :
<code>
0 4 * * * /chemin/vers/le/script.sh
</code>
--- //[[user:cedricabonnel]]//

66
data/pages/informatique/serveur/dovecot/creer-un-script-de-hook-let-s-encrypt-pour-dovecot.txt Normal file
View File

@@ -0,0 +1,66 @@
====== Créer un script de Hook Let's Encrypt pour Dovecot ======
Pour mettre en place un hook qui redémarre **Dovecot** après chaque renouvellement de certificat avec **Let's Encrypt** (généralement géré par **Certbot**), vous devez ajouter un script de hook dans le répertoire approprié ou spécifier le hook directement dans la commande de renouvellement de **Certbot**. Voici comment vous pouvez procéder :
===== 1. Création d'un Script de Hook =====
Vous pouvez créer un script qui redémarre **Dovecot**. Par exemple:
<code BASH>
#!/bin/bash
# reload-dovecot.sh
# Redémarrer Dovecot
echo "Reloading Dovecot..."
systemctl restart dovecot
</code>
Enregistrez ce script quelque part sur votre système, par exemple, ''/etc/letsencrypt/renewal-hooks/post/reload-dovecot.sh''.
**Assurez-vous de rendre le script exécutable :**
<code BASH>
chmod +x /etc/letsencrypt/renewal-hooks/post/reload-dovecot.sh
</code>
===== 2. Utiliser Certbot avec le Hook =====
Lorsque vous exécutez **Certbot** pour renouveler vos certificats, vous pouvez spécifier des hooks à exécuter avant ou après le renouvellement.
**Ajouter le Hook de Renouvellement Automatique :** Si vous avez configuré Certbot pour renouveler automatiquement vos certificats (ce qui est la configuration recommandée), vous pouvez ajouter votre script de hook directement dans la configuration de renouvellement de Certbot.
Pour chaque certificat dans ''/etc/letsencrypt/renewal/'', il y a un fichier de configuration correspondant. Vous pouvez ajouter les lignes suivantes au fichier de configuration de votre domaine (par exemple, ''/etc/letsencrypt/renewal/smtp.serveur.fr.conf''):
<code BASH>
[renewalparams]
post_hook = /etc/letsencrypt/renewal-hooks/post/reload-dovecot.sh
</code>
===== 3. Utiliser des Hooks Directoires =====
**Certbot** vérifie également automatiquement trois répertoires pour les scripts à exécuter comme hooks :
* ''/etc/letsencrypt/renewal-hooks/pre/'' : Avant le renouvellement.
* ''/etc/letsencrypt/renewal-hooks/deploy/'' : Après le renouvellement réussi d'un certificat.
* ''/etc/letsencrypt/renewal-hooks/post/'' : Après la tentative de renouvellement (qu'elle soit réussie ou non).
Placer votre script dans ''/etc/letsencrypt/renewal-hooks/post/'' assurera qu'il s'exécute après chaque tentative de renouvellement, ce qui est idéal pour des actions comme redémarrer Dovecot.
===== 4. Testez votre Configuration =====
Après avoir mis en place le hook, vous devriez tester le processus pour vous assurer que tout fonctionne comme prévu. Vous pouvez simuler un renouvellement avec Certbot en utilisant une option de test (cela ne remplacera pas vos certificats actuels) :
<code BASH>
certbot renew --dry-run
</code>
Si tout est correctement configuré, **Certbot** renouvellera le certificat en mode test et exécutera votre script pour redémarrer **Dovecot**. Assurez-vous que **Dovecot** fonctionne correctement après l'exécution du script.
===== Notes Importantes : =====
* **Sécurité :** Vérifiez que seuls les utilisateurs appropriés ont des permissions d'écriture sur le script et les fichiers de configuration pour éviter des modifications non autorisées.
* **Logs :** Surveillez vos logs pour vous assurer que les renouvellements et les redémarrages de **Dovecot** se passent comme prévu. **Certbot** et **Dovecot** écrivent tous deux des logs qui peuvent être utiles en cas de problème.
* **Compatibilité :** Vérifiez que les versions de **Certbot** et **Dovecot** que vous utilisez supportent les configurations et méthodes décrites ici, car les logiciels peuvent changer avec le temps.
En ayant un hook bien configuré, vous vous assurez que **Dovecot** utilise toujours un certificat à jour, maintenant ainsi la sécurité de votre service de messagerie.

32
data/pages/informatique/serveur/index.txt Normal file
View File

@@ -0,0 +1,32 @@
====== Serveur ======
{{ :informatique.jpg?nolink&300x|Informatique et Technologie}}
===== Table des matières =====
<WRAP clear/>
<WRAP group>
<WRAP half column>
==== Les pages ====
<nav stacked="true" fade="true">
<nspages . -h1 -nbCol=1 -textNS=" " -textPages=" " -simpleList -exclude:cookie: -exclude:user: -exclude:playground: -exclude:[sidebar index start rightsidebar navbar topheader header help pageheader pagefooter legal-notices footer 404]>
</nav>
</WRAP>
<WRAP half column>
==== Les sous-catégories ====
<nav stacked="true" fade="true">
<nspages . -h1 -nbCol=1 -noPages -subns -textNS=" " -textPages=" " -simpleList -exclude:cookie: -exclude:user: -exclude:playground: -exclude:[sidebar index start rightsidebar navbar topheader header help pageheader pagefooter legal-notices footer 404]>
</nav>
</WRAP>
</WRAP>
~~NOTOC~~
~~NOCACHE~~

33
data/pages/informatique/serveur/ngnix.txt Normal file
View File

@@ -0,0 +1,33 @@
====== Nginx ======
L'histoire de Nginx (prononcé "Engine X") est une histoire de succès dans le domaine des serveurs web et de la technologie open source. Nginx est connu pour sa performance élevée, sa gestion efficace des connexions et sa capacité à gérer un grand nombre de requêtes simultanées. Voici un aperçu de l'histoire de Nginx :
1. **Création de Nginx** :
* Nginx a été créé par Igor Sysoev, un ingénieur russe, en 2002. À l'origine, il a développé Nginx pour résoudre des problèmes de performance et de montée en charge rencontrés lors de la gestion de sites web à fort trafic. Il a conçu Nginx pour être un serveur web léger et rapide, principalement destiné à être utilisé comme serveur proxy inverse.
2. **Version 0.1** :
* La première version publique de Nginx, la version 0.1, a été publiée en octobre 2004. À ce stade, Nginx était principalement utilisé en Russie, mais il a rapidement gagné en popularité dans le monde entier grâce à ses performances exceptionnelles.
3. **Focus sur la performance** :
* Nginx a été conçu dès le départ pour être extrêmement performant et efficace en termes de ressources. Il était capable de gérer un grand nombre de connexions simultanées avec une empreinte mémoire minimale, ce qui en faisait un choix attrayant pour les sites web à fort trafic.
4. **Utilisation comme serveur proxy inverse** :
* L'une des premières utilisations courantes de Nginx était en tant que serveur proxy inverse, qui permet de distribuer le trafic vers plusieurs serveurs d'application en aval. Cette fonctionnalité était particulièrement précieuse pour l'équilibrage de charge et la répartition de la charge sur des clusters de serveurs.
5. **Adoption croissante** :
* Au fil des années, Nginx est devenu de plus en plus populaire, en particulier parmi les sites web à fort trafic et les entreprises qui cherchaient à améliorer les performances de leurs infrastructures en ligne.
6. **Nginx, Inc.** :
* En 2011, Igor Sysoev a cofondé Nginx, Inc., une entreprise qui a été créée pour fournir des services de support, de formation et des solutions commerciales autour de Nginx. Cela a contribué à renforcer la position de Nginx dans le secteur des technologies web.
7. **Nginx Open Source** :
* Bien que Nginx, Inc. propose des produits commerciaux basés sur Nginx, le serveur web lui-même reste open source et est disponible gratuitement sous une licence open source.
8. **Élargissement des fonctionnalités** :
* Au fil du temps, Nginx a élargi ses fonctionnalités pour inclure des capacités telles que le chargement dynamique de modules, la prise en charge du protocole HTTP/2, la gestion de contenu statique, la réécriture d'URL, et bien plus encore. Ces fonctionnalités ont renforcé sa position en tant que serveur web polyvalent.
9. **Acquisition par F5 Networks** :
* En 2019, F5 Networks, une entreprise spécialisée dans les solutions de gestion de la circulation et de sécurité des applications, a acquis Nginx, Inc. pour 670 millions de dollars. Cette acquisition a renforcé la présence de Nginx dans le domaine des applications d'entreprise et de la sécurité.
Aujourd'hui, Nginx est largement utilisé dans le monde entier pour servir des sites web, équilibrer la charge du trafic web, accélérer les performances des applications et offrir des solutions de sécurité. Il reste un pilier de l'infrastructure web moderne et continue de jouer un rôle clé dans l'optimisation des performances et la mise à l'échelle des services en ligne.

370
data/pages/informatique/serveur/postfix.txt Normal file
View File

@@ -0,0 +1,370 @@
====== PostFix : serveur de messagerie sous Linux ======
{{ :informatique:linux:pasted:20210116-063335.png?75x75|et toutes les astuces à connaître concernant les mails.}}
Cet article est destiné aux débutants qui veulent configurer un **serveur de messagerie électronique** de base. Il est préférable d'avoir une connaissance élémentaire en administration système, ainsi que la capacité d'installer des logiciels et de modifier des fichiers de configuration. L'article a été rédigé en se basant sur Debian 11, mais les instructions devraient également convenir aux autres versions. Veuillez noter que des différences peuvent exister dans les autres versions.
Postfix est un logiciel de serveur de messagerie open source largement adopté. En tant que "MTA" (Agent de Transfert de Message), il joue un rôle central dans le traitement, la transmission et la distribution des courriels. Doté de fonctionnalités avancées en matière de sécurité, de filtrage et de personnalisation, Postfix est un choix prisé pour la gestion des systèmes de messagerie.
<nav stacked="true" fade="true">
<nspages .:postfix -h1 -hideNoSubns -subns -nbCol=1 -textNS=" " -textPages=" " -simpleList -exclude:cookie: -exclude:user: -exclude:playground: -exclude:[sidebar index start rightsidebar navbar topheader header help pageheader pagefooter legal-notices footer 404] -pagesInNs -sortId -reverse >
</nav>
===== - Introduction =====
L'objectif fondamental de cette procédure est de permettre à n'importe quelle machine ou serveur d'envoyer des courriels vers une adresse spécifique. Pour y parvenir, il est nécessaire de préparer le courrier électronique à l'aide d'un programme externe, puis de le transmettre efficacement au serveur de messagerie de destination en utilisant le protocole SMTP (Simple Mail Transfer Protocol).
Le processus de l'envoi de courriel via SMTP s'articule comme suit, prenons un exemple concret avec un courriel destiné à l'adresse alice@example.com :
1. L'utilisateur ou un programme externe crée le courrier électronique, en spécifiant les informations du destinataire (alice@example.com), en rédigeant le contenu du message et en incluant d'autres détails nécessaires.
2. Le courriel est ensuite remis au serveur SMTP local, qui se trouve sur la machine ou le serveur à partir duquel l'envoi est effectué.
3. Le serveur SMTP analyse le domaine du destinataire (dans ce cas, "example.com") pour déterminer comment atteindre le serveur de messagerie de destination.
4. Le serveur SMTP établit un contact avec le serveur de messagerie de destination (le serveur SMTP de "example.com" dans cet exemple) en utilisant le protocole SMTP.
5. Le serveur de messagerie de destination accepte le courriel, le stocke temporairement, puis le transfère éventuellement dans la boîte aux lettres de l'utilisateur Alice, située sur son propre serveur de messagerie.
6. Si tout se déroule sans problème, le courriel est ainsi livré avec succès à Alice, qui peut alors le consulter dans sa boîte de réception.
Ce processus est la façon dont le protocole SMTP assure la transmission de courriels, encheminant ces derniers de l'expéditeur au destinataire, en utilisant les serveurs de messagerie appropriés à travers Internet.
==== - Axe de travail ====
Il existe de nombreuses configurations et combinaisons différentes possibles lors de la mise en place d'un serveur de messagerie électronique, bien trop nombreuses pour être toutes couvertes ici. Par conséquent, cet article effectue certaines choix fondamentaux pour vous, tels que les logiciels que nous allons utiliser (Postfix et Dovecot). D'autres options nécessiteront des modifications de la part de l'utilisateur, comme les adresses réseau et les noms de domaine. Les paramètres plus avancés, comme la gestion de domaines virtuels et des utilisateurs, ne sont pas abordés dans cet article et ne seront pas traités ici.
Dans ce contexte, nous utilisons **Postfix** comme agent de transfert de messagerie (MTA). **Dovecot** est utilisé pour permettre aux utilisateurs d'accéder à leur courrier électronique via les protocoles **IMAP** ou **POP**. Nous partons du principe que le nom de domaine utilisé est **example.com**, mais cela devrait être adapté par le lecteur. Vous pouvez utiliser un véritable nom de domaine pour un serveur de messagerie pleinement qualifié ou un faux nom de domaine si vous souhaitez uniquement créer un serveur de messagerie interne.
Notre exemple suppose que le serveur de messagerie physique (hôte) porte le nom **mail.example.com** et est situé à l'adresse IP privée **192.168.0.1** (veuillez personnaliser ces informations en fonction de vos besoins). Le serveur de messagerie fournira des comptes de messagerie basés sur les comptes système d'utilisateurs standards, et les utilisateurs accéderont à leur courrier en utilisant leur nom d'utilisateur et leur mot de passe de compte système. Nous illustrons cela avec un utilisateur nommé **John Smith**, qui dispose d'un compte système avec le nom d'utilisateur **john**.
==== - Serveurs SMTP ====
Sous Linux Debian, il existe plusieurs programmes d'envoi de courriels, chacun avec ses propres fonctionnalités et avantages. Voici quelques-uns des programmes les plus couramment utilisés pour envoyer des courriels sous Debian :
1. **ssmtp**: Simple SMTP est un programme léger qui permet d'envoyer des courriels via SMTP. Il est particulièrement adapté aux tâches d'envoi de courriels automatisées et ne prend pas en charge la réception de courriels.
2. **msmtp**: MSMTP est un autre client SMTP léger qui facilite l'envoi de courriels depuis la ligne de commande ou depuis des scripts. Il peut être configuré pour transmettre des courriels à travers un serveur SMTP externe.
3. **Postfix**: Bien que Postfix soit principalement un serveur de messagerie, il peut également être utilisé pour envoyer des courriels depuis une machine Debian. Il offre une grande flexibilité en matière de configuration, mais sa configuration peut être plus complexe que celle des clients SMTP plus simples.
4. **sendmail**: Sendmail est un programme de messagerie historique sous Unix/Linux, bien qu'il soit maintenant souvent remplacé par des alternatives plus modernes. Cependant, il est toujours disponible sur Debian et peut être utilisé pour envoyer des courriels.
5. **Exim**: Exim est un autre serveur de messagerie qui peut être configuré pour envoyer des courriels. Il est également capable de gérer la réception de courriels, ce qui en fait une option plus complète.
Le choix du programme d'envoi de courriels dépendra de vos besoins spécifiques, de votre niveau de confort avec la configuration et de la complexité de votre infrastructure de messagerie. Pour des tâches simples d'envoi de courriels depuis la ligne de commande ou depuis des scripts, **ssmtp** ou **msmtp** sont souvent des choix pratiques. Pour des besoins plus avancés, **Postfix** ou **Exim** peuvent être mieux adaptés.
===== - Installer Postfix =====
Pour installer Postfix sur Debian, vous devez utiliser le gestionnaire de paquets APT (Advanced Package Tool). Voici comment vous pouvez procéder :
<code bash>
sudo apt update
sudo apt install postfix
</code>
La première commande ''apt update'' met à jour la liste des paquets disponibles dans les dépôts Debian, et la deuxième commande "apt install" installe Postfix ainsi que ces dépendances.
{{:informatique:linux:pasted:20210116-054542.png}}
Choisir ''Site Internet''
{{:informatique:linux:pasted:20210116-054903.png}}
Entrer la valeur FQDN de votre adresse de serveur
{{:informatique:linux:pasted:20210116-054839.png}}
si vous devez relancer la configuration de Postfix
sudo dpkg-reconfigure postfix
Pour supprimer **Sendmail**, vous pouvez utiliser la commande suivante :
<code bash>
sudo apt-get remove sendmail
</code>
Cette commande supprime le programme **Sendmail** de votre système Debian.
Après avoir installé **Postfix**, vous devrez configurer ces logiciels pour les adapter à vos besoins spécifiques.
===== - Configurer Postfix =====
Les fichiers de configuration de postfix sont stockés dans /etc/postfix. Les deux principaux fichiers de configuration de postfix sont master.cf et main.cf, bien que nous ne traiterons que de main.cf ici. Tout d'abord, nous allons ajouter ou modifier certaines lignes dans le fichier de configuration main.cf. Les lignes suivantes doivent être ajoutées, modifiées ou décommentées :
<code>
myhostname = mail.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mynetworks = 192.168.0.0/24, 127.0.0.0/8
relay_domains =
home_mailbox = Maildir/
</code>
===== - Tests =====
Faire un essai d'envoi de mail
echo "Le contenu du mail" | mail -s "ceci est le sujet" mail@domaine.tld
Le programme **mail** est une composante du package **mailutils**. Donc, si le programme n'est pas installer sur la machine, utilisez ''sudo apt install mailutils''
--
Pour modifier un paramètre dans **Postfix**, il faut éditer le fichier de configuration
sudo nano /etc/postfix/main.cf
Redémarrer le service
sudo systemctl restart postfix
===== Gestion des Alias =====
Ajouter dans le fichier de configuration de **Postfix**, ''/etc/postfix/main.cf''
virtual_alias_maps = hash:/etc/postfix/virtual
Puis ajouter dans le fichier ''/etc/postfix/virtual'' les **alias désirés** tel que le modèle suivant :
<code>
@monserveur.tld mail@domain.tld
</code>
Enfin, exécuter le bloc suivant. Il sera nécessaire de l’exécuter à chaque modifications effectuées du fichier ''/etc/postfix/virtual''.
sudo postmap /etc/postfix/virtual
sudo systemctl restart postfix
===== Mails en attente =====
Pour connaître les mails en attente
sudo postqueue -p
--
Pour traiter tous les mails en attente
sudo postqueue -f
--
Pour supprimer tous les mails en attente
sudo postsuper -d ALL
===== Reprise de la configuration de Postfix =====
Le fichier de configuration de **Postfix** est ''/etc/postfix/main.cf''. Il est éditable par **nano** ou **vim**. On va le reprendre pour configurer **Postfix**.
---
myhostname = myserver.example.com
Il est important que l'option ''myhostname'' corresponde au FQDN (fully qualified domain name) du serveur. La valeur à renseigner et celle qui renvoyée par la commande :
nslookup 91.134.243.56
| {{:informatique:linux:pasted:20210117-214414.png}} |
Dans l'exemple précédent, le serveur est noté dans le ''name =''
Cette information est gérée par le serveur DNS
Cette option se trouve les paramètres ''Gérer les paramètres IPs'', chez **kimsufi.com**
| {{:informatique:linux:pasted:20210117-214634.png}} |
Cette option, **reverse DNS**, se trouve dans les options du **serveur VPS** de vos **serveurs dédiés**, chez **ovh.com**
| {{:informatique:linux:pasted:20210117-215132.png}} |
| {{:informatique:linux:pasted:20210117-231208.png}} |
---
Configurer le **nom du serveur SMTP**, domaine à afficher dans le courrier sortant
myorigin = example.com
Configuer le **nom du serveur SMTP**
mydomain = example.com
Configure to which SMTP domains to relay messages to, for example:
relay_domains = example.com
---
Configuration minimaliste du SMTP Greeting Banner:
smtpd_banner = $myhostname
---
Limiter les attaques par déni de services :
<code>
default_process_limit = 100
smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 30
queue_minfree = 20971520
header_size_limit = 51200
message_size_limit = 10485760
smtpd_recipient_limit = 100
</code>
===== Consulter le fichier log =====
Le fichier log standard de **postfix** est ''/var/log/mail.info''
Vous pouvez garder un oeuil sur les logs
sudo tail -f /var/log/mail.info&
===== Envoyer un mail =====
Il y a deux possibilités :
* envoie depuis un client : **mail**
* connexion en **Telnet** sur le serveur SMTP
L'utilitaire **mail** fait parti de la suite **mailutils**
sudo apt install mailutils
---
Utilisation de l'utilitaire **mail** depuis un poste client.
Pour envoyer un mail à ''mail@example.com'' de la part de ''sender@example.com''
echo "This is the message body" | mail -s "This is the subject" mail@example.com -aFrom:sender@example.com
Pour envoyer un mail à ''username''
echo "This is the message body" | mail -s "Hello World" username
---
Utilisation de **telnet** pour se connecter sur le serveur SMTP ''mail.mymailserver.com''
telnet mail.mymailserver.com 25
Puis saisir les commandes SMTP
EHLO checkeremail.com
MAIL FROM:<sender@mailserver.fr>
RCPT TO:<dest@mymailserver.com>
DATA
Subject: Sending an email using telnet
Hello,
Here is my body? Do you like it?
Cédric
.
QUIT
===== Vider tous les mails =====
Vider tous les mails présents dans la boite d'un utilisateur. On considère que la boite mail (mbox) de l'utilisateur ''www-data'' se trouve dans le fichier ''/var/mail/www-data''
sudo sh -c "> /var/mail/www-data"
===== Gestion des certificats =====
Pour configurer **Postfix** et **Certbot** pour utiliser les certificats SSL/TLS de "smtp.monserveur.fr" avec **Let's Encrypt**, suivez ces étapes générales. Assurez-vous d'avoir les droits nécessaires sur le serveur et que vous êtes à l'aise avec l'édition de fichiers de configuration en ligne de commande.
==== Configurer Postfix pour utiliser SSL/TLS ====
1. **Accédez à la configuration de Postfix**:
* Connectez-vous à votre serveur en tant que sudouser.
* Ouvrez le fichier de configuration principal de Postfix avec un éditeur de texte, tel que ''nano'' ou ''vim''. Le fichier est généralement situé à ''/etc/postfix/main.cf''.
2. **Définissez les chemins des certificats**:
* Localisez ou ajoutez les lignes suivantes dans ''main.cf'' pour spécifier l'emplacement des fichiers de certificat et de clé privée (remplacez les chemins par les vôtres si nécessaire) :
<code>
smtpd_tls_cert_file = /etc/letsencrypt/live/smtp.monserveur.fr/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/smtp.monserveur.fr/privkey.pem
</code>
* Activez l'utilisation de TLS en ajoutant ou en s'assurant que la ligne suivante est présente :
<code>
smtpd_use_tls = yes
</code>
3. **Redémarrez Postfix**:
* Sauvegardez vos modifications et fermez le fichier.
* Exécutez la commande ''sudo systemctl restart postfix'' pour appliquer les modifications.
==== Configurer Dovecot pour SSL/TLS ====
Si vous utilisez Dovecot comme serveur IMAP/POP3 :
1. Les fichiers de configuration de **Dovecot** se trouvent généralement dans ''/etc/dovecot/''. Le fichier principal de configuration est souvent nommé ''dovecot.conf'', et il peut inclure d'autres fichiers de configuration situés dans ''/etc/dovecot/conf.d/''.
2. Dans les fichiers de configuration de **Dovecot**, vous devrez trouver et modifier les lignes qui définissent le chemin du certificat SSL et de la clé privée. Recherchez quelque chose comme ceci :
<code>
ssl_cert = </etc/letsencrypt/live/smtp.serveur.fr/fullchain.pem
ssl_key = </etc/letsencrypt/live/smtp.serveur.fr/privkey.pem
</code>
Pensez à désactiver la configuration présente dans ''/etc/dovecot/conf.d/10-ssl.conf''.
3. **Redémarrez Dovecot** avec ''sudo systemctl restart dovecot''.
4. Après le redémarrage, assurez-vous que tout fonctionne comme prévu. Vous pouvez vérifier que **Dovecot** écoute avec le nouveau certificat en vous connectant avec un client de messagerie ou en utilisant OpenSSL :
<code>
openssl s_client -connect smtp.serveur.fr:993
</code>
==== Configurer Let's Encrypt pour le renouvellement automatique ====
1. **Certbot** gère généralement les renouvellements automatiquement. Cependant, vous pouvez personnaliser ou ajouter des scripts de renouvellement dans le dossier de hooks de renouvellement.
2. **Scripts de renewal-hooks**:
* Placez les scripts personnalisés dans ''/etc/letsencrypt/renewal-hooks/''. Vous pouvez avoir des scripts ''pre'', ''deploy'', et ''post'' pour s'exécuter avant, pendant, et après le renouvellement.
* Un script typique dans ''post'' pourrait redémarrer Postfix et Dovecot pour appliquer les nouveaux certificats.
Voir les pages :
* [[informatique:serveur:postfix:Créer un script de hook Let's Encrypt pour Postfix]]
* [[informatique:serveur:dovecot:Créer un script de hook Let's Encrypt pour Dovecot]]
Si vous avez deux scripts distincts, ''reload-dovecot.sh'' et ''reload-postfix.sh,'' et vous souhaitez exécuter les deux après le renouvellement de certificat **Let's Encrypt** par **Certbot**, vous pouvez configurer les hooks dans le fichier de configuration de renouvellement de **Certbot** ou les placer dans les répertoires de hook appropriés.
Vous devriez ajouter des lignes pour post_hook dans la section ''[renewalparams]''. Votre fichier pourrait ressembler à ceci :
<code>
[renewalparams]
post_hook = /etc/letsencrypt/renewal-hooks/post/reload-dovecot.sh && /etc/letsencrypt/renewal-hooks/post/reload-postfix.sh
</code>
3. **Tester le renouvellement**:
* Exécutez ''sudo certbot renew --dry-run'' pour tester le processus de renouvellement et s'assurer que tout fonctionne comme prévu.
==== Vérification et maintenance ====
* **Vérifiez les logs** de **Postfix** et **Dovecot** pour les erreurs liées aux certificats SSL/TLS.
* Assurez-vous que les certificats se renouvellent correctement en vérifiant les dates d'expiration et en observant le comportement du système lors des renouvellements planifiés.
==== Remarques ====
* Faites toujours une copie de sauvegarde des fichiers de configuration avant de les modifier.
* Les chemins exacts et les commandes peuvent varier légèrement en fonction de votre distribution Linux et de la version de vos logiciels.
* Assurez-vous que les ports nécessaires sont ouverts sur votre pare-feu pour permettre les connexions TLS/SSL.
En suivant ces étapes, vous devriez être capable de configurer **Postfix** et **Dovecot** pour utiliser les certificats SSL/TLS avec **Let's Encrypt**, améliorant ainsi la sécurité de votre serveur de messagerie. Assurez-vous de tester votre configuration pour vérifier que tout fonctionne correctement avant de la mettre en production.
===== Biblio =====
* https://www.tecmint.com/install-postfix-mail-server-with-webmail-in-debian/
* https://wiki.centos.org/HowTos(2f)postfix.html

98
data/pages/informatique/serveur/postfix/configuration-de-postfix-avec-un-relais-smtp-externe-utilisant-l-authentification-login-ou-plain.txt Normal file
View File

@@ -0,0 +1,98 @@
====== Configuration de Postfix avec un relais SMTP externe utilisant l'authentification LOGIN ou PLAIN ======
{{ :dummy.png?75x75|Linux Postifx hostrelay}}
Par défaut, Postfix est configuré pour envoyer des e-mails directement au serveur de messagerie du destinataire. Cependant, il est parfois nécessaire de configurer Postfix pour utiliser un relais SMTP externe avec authentification LOGIN ou PLAIN.
===== Éditer le fichier de configuration principal =====
Le fichier de configuration principal de Postfix est généralement situé dans le répertoire ''/etc/postfix/main.cf''. Ouvrez ce fichier à l'aide d'un éditeur de texte et recherchez les directives suivantes :
<code>
relayhost =
smtp_sasl_auth_enable = no
</code>
===== Configurer le relais SMTP externe =====
Modifiez la directive ''relayhost'' pour spécifier l'adresse du relais SMTP externe que vous souhaitez utiliser. Par exemple, si le relais SMTP externe est ''smtp.example.com'' et il écoute sur le port ''587'', la directive devrait ressembler à ceci :
<code>
relayhost = [smtp.example.com]:587
</code>
===== Activer l'authentification PLAIN =====
Décommentez la directive ''smtp_sasl_auth_enable'' en supprimant le # au début de la ligne, puis modifiez sa valeur à ''yes'' :
<code>
smtp_sasl_auth_enable = yes
</code>
===== Configurer les informations d'authentification =====
Ajoutez les informations d'authentification pour le relais SMTP externe en ajoutant les directives suivantes dans le fichier de configuration :
<code>
smtp_sasl_auth_enable = yes
smtpd_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtp_sasl_mechanism_filter = login, plain
</code>
Voici ce que font ces options :
1. ''smtp_sasl_auth_enable = yes'' : Cette option active l'authentification SASL (Simple Authentication and Security Layer) pour les connexions SMTP sortantes. Cela permet à Postfix de s'authentifier auprès du relais SMTP externe en utilisant les informations d'identification fournies.
2. ''smtpd_sasl_auth_enable = yes'' : Cette option active l'authentification SASL pour les connexions SMTP entrantes. Elle permet à Postfix d'accepter les connexions SMTP entrantes et d'authentifier les clients qui se connectent.
3. ''smtp_sasl_security_options = noanonymous'' : Cette option spécifie que Postfix n'accepte pas les connexions anonymes lors de l'authentification SASL. Cela garantit que toutes les connexions SMTP doivent fournir des informations d'identification valides.
4. ''smtp_sasl_tls_security_options = noanonymous'' : Cette option spécifie que lors de l'utilisation de TLS (Transport Layer Security) pour sécuriser les connexions SMTP, les connexions anonymes ne sont pas autorisées.
5. ''smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'' : Cette option indique à Postfix où trouver le fichier de hachage contenant les informations d'identification (nom d'utilisateur et mot de passe) pour l'authentification SASL auprès du relais SMTP externe. Dans cet exemple, le fichier ''/etc/postfix/sasl_passwd'' est utilisé et doit être converti en un fichier de hachage à l'aide de la commande ''postmap''.
6. ''smtp_use_tls = yes'' : Cette option active l'utilisation de TLS pour chiffrer les connexions SMTP sortantes. Elle assure que les communications avec le relais SMTP externe sont sécurisées.
7. ''smtp_tls_note_starttls_offer = yes'' : Cette option indique à Postfix d'émettre une offre STARTTLS lors de l'établissement d'une connexion SMTP sortante. Cela permet d'initier une négociation TLS avec le relais SMTP externe si celui-ci prend en charge TLS.
8. ''smtp_sasl_mechanism_filter = login, plain'' : Cette option spécifie les mécanismes d'authentification SASL autorisés pour les connexions SMTP sortantes. Dans cet exemple, seuls les mécanismes "login" et "plain" sont autorisés.
Ces options combinées permettent à Postfix de configurer un relais SMTP externe avec authentification PLAIN et d'établir des connexions sécurisées à l'aide de TLS. Cela garantit que les e-mails sont envoyés de manière fiable et en toute sécurité via le relais externe.
===== Créer le fichier de mots de passe SASL =====
Créez un fichier ''/etc/postfix/sasl_passwd'' et ajoutez les informations d'authentification suivantes :
<code>
[smtp.example.com]:587 username:password
</code>
Remplacez ''smtp.example.com'' par l'adresse du relais SMTP externe, ''587'' par le port utilisé, ''username'' par votre nom d'utilisateur de messagerie pour le relais SMTP, et ''password'' par votre mot de passe associé.
===== Générer le fichier de hachage des mots de passe SASL =====
Exécutez la commande suivante pour générer le fichier de hachage des mots de passe SASL à partir du fichier ''sasl_passwd'' :
<code>
sudo postmap /etc/postfix/sasl_passwd
</code>
Cette commande va créer un fichier ''/etc/postfix/sasl_passwd.db'' contenant le hachage des mots de passe.
===== Redémarrer POSTFIX =====

63
data/pages/informatique/serveur/postfix/creer-un-script-de-hook-let-s-encrypt-pour-postfix.txt Normal file
View File

@@ -0,0 +1,63 @@
Pour adapter l'article afin de créer un script de hook Let's Encrypt pour Postfix, voici une version modifiée du texte :
====== Configurer un Script de Hook Let's Encrypt pour Postfix ======
Assurer la continuité et la sécurité de votre serveur de messagerie Postfix est crucial, surtout lorsqu'il s'agit de la gestion automatique des certificats SSL/TLS via Let's Encrypt. La mise en place d'un script de hook qui redémarre Postfix à chaque renouvellement de certificat est une étape essentielle. Voici les étapes pour configurer cela avec Certbot :
===== 1. Élaboration d'un Script de Hook =====
Créez un script qui initiera le redémarrage de Postfix une fois le certificat renouvelé. Voici un exemple de script que vous pourriez utiliser :
<code BASH>
#!/bin/bash
# reload-postfix.sh
# Redémarrer Postfix
echo "Reloading Postfix..."
systemctl restart postfix
</code>
Sauvegardez ce script dans un endroit sûr, tel que ''/etc/letsencrypt/renewal-hooks/post/reload-postfix.sh''.
**Rendez le script exécutable :**
<code BASH>
chmod +x /etc/letsencrypt/renewal-hooks/post/reload-postfix.sh
</code>
===== 2. Intégration avec Certbot =====
Lorsque vous exécutez Certbot pour le renouvellement des certificats, indiquez ce script comme un hook post-renouvellement. Si Certbot est configuré pour renouveler automatiquement vos certificats, ajoutez votre script dans la configuration de renouvellement de Certbot en modifiant le fichier de configuration du domaine concerné, par exemple, ''/etc/letsencrypt/renewal/yourdomain.conf'':
<code BASH>
[renewalparams]
post_hook = /etc/letsencrypt/renewal-hooks/post/reload-postfix.sh
</code>
===== 3. Exploitation des Directoires de Hooks =====
Certbot recherche dans trois répertoires spécifiques des scripts à exécuter en tant que hooks :
* ''/etc/letsencrypt/renewal-hooks/pre/'' : Avant le renouvellement.
* ''/etc/letsencrypt/renewal-hooks/deploy/'' : Après un renouvellement réussi.
* ''/etc/letsencrypt/renewal-hooks/post/'' : Après toute tentative de renouvellement.
Placer votre script dans ''/etc/letsencrypt/renewal-hooks/post/'' s'assure qu'il sera exécuté après chaque renouvellement, garantissant ainsi que Postfix redémarre avec le nouveau certificat.
===== 4. Validation de la Configuration =====
Effectuez un test de renouvellement pour vous assurer que tout fonctionne correctement :
<code BASH>
certbot renew --dry-run
</code>
Si tout est bien configuré, Certbot renouvellera le certificat en mode test et exécutera votre script pour redémarrer Postfix. Vérifiez que Postfix fonctionne correctement après le redémarrage.
===== Remarques Importantes : =====
* **Sécurité :** Assurez-vous que seuls les utilisateurs appropriés ont des permissions d'écriture sur le script et les fichiers de configuration.
* **Logs :** Surveillez les logs de Certbot et Postfix pour tout problème éventuel lors des renouvellements et redémarrages.
* **Compatibilité :** Vérifiez que les versions de Certbot et Postfix en usage sont compatibles avec les méthodes décrites ici.
En mettant en place un hook bien configuré, vous vous assurez que Postfix fonctionne toujours avec un certificat valide, maintenant ainsi la sécurité et la fiabilité de votre serveur de messagerie.

74
data/pages/informatique/serveur/postfix/reecrire-return-path-et-l-adresse-d-expediteur.txt Normal file
View File

@@ -0,0 +1,74 @@
====== Réécriture des adresses e-mail sortantes dans Postfix ======
{{ :dummy.png?75x75|Linux Postfix generic}}
Le Return-Path, également connu sous le nom d'adresse d'enveloppe, est une adresse e-mail utilisée pour les notifications de non-distribution (bounces) et pour les erreurs de livraison des e-mails. Il est généralement différent de l'adresse affichée dans l'en-tête "**From**" du message.
Lorsque vous utilisez le fichier ''/etc/postfix/generic'' pour réécrire les adresses e-mail dans Postfix, la réécriture s'applique par défaut uniquement aux en-têtes "**From**", "**Sender**" et "**Return-Path**".
Voici comment réécrire les en-têtes "**From**", "**Sender**" et "**Return-Path**" en utilisant le fichier ''/etc/postfix/generic'' :
===== Ouvrez le fichier ''/etc/postfix/generic'' =====
Utilisez votre éditeur de texte préféré pour ouvrir le fichier ''/etc/postfix/generic'' :
<code>
sudo nano /etc/postfix/generic
</code>
===== Configurer les règles de réécriture =====
Dans ce fichier, vous pouvez ajouter des règles de réécriture sous la forme suivante :
<code>
@server.ntdl adresse_modifiee@example.com
@server adresse_modifiee@example.com
@localhost adresse_modifiee@example.com
</code>
Remplacez
* ''adresse_modifiee@example.com'' par l'adresse e-mail modifiée que vous souhaitez afficher pour les destinataires
* ''server.ntdl'' par le nom de votre serveur FQDN
* ''server'' par le nom de votre serveur non FQDN
Vous pouvez ajouter autant de règles que nécessaire, chacune sur une nouvelle ligne.
===== Enregistrer et fermer le fichier =====
Une fois que vous avez configuré toutes les règles de réécriture souhaitées, enregistrez et fermez le fichier ''/etc/postfix/generic''.
===== Générer le fichier de hachage =====
Le fichier ''/etc/postfix/generic'' doit être converti en un fichier de hachage pour que Postfix puisse l'utiliser efficacement. Pour générer le fichier de hachage, exécutez la commande suivante :
<code>
sudo postmap /etc/postfix/generic
</code>
Cela va créer un fichier ''/etc/postfix/generic.db'', qui contient le hachage des adresses e-mail réécrites.
===== Configurer Postfix pour utiliser ''/etc/postfix/generic'' =====
Ouvrez le fichier de configuration principal de Postfix ''/etc/postfix/main.cf'' et recherchez la directive ''smtp_generic_maps''. Si elle n'existe pas, ajoutez la ligne suivante :
<code>
sender_canonical_maps = hash:/etc/postfix/generic
</code>
Cette directive indique à Postfix d'utiliser le fichier ''/etc/postfix/generic'' pour la réécriture des adresses e-mail sortantes.
===== Redémarrez Postfix pour appliquer les modifications =====
<code>
sudo service postfix restart
</code>
Avec cette configuration, les réécritures spécifiées dans ''/etc/postfix/generic'' s'appliqueront également au Return-Path des messages sortants, en plus des en-têtes "**From**", "**Sender**" et "**Return-Path**". Cela vous permet de personnaliser entièrement les adresses d'enveloppe utilisées pour les erreurs de livraison des e-mails.
Si vous souhaitez réécrire d'autres en-têtes des messages sortants comme "**Reply-To**", vous devrez utiliser d'autres directives et configurations spécifiques de Postfix.

56
data/pages/informatique/serveur/web-linux-apache/accelerer-le-traitement-php.txt Normal file
View File

@@ -0,0 +1,56 @@
====== Accélérer l’exécution des pages avec memcached ======
===== Installer memcached =====
Installer **memcached** pour PHP 7.4 :
<code BASH>
sudo apt install php7.4-memcached memcached
</code>
Installer **memcached** pour PHP 8.0 :
<code BASH>
sudo apt install php8.0-memcached memcached
</code>
===== Vérifier le fonctionne de memcached dans le system =====
ps ax | grep memcached
Résultat
<code>
14085 ? Ssl 0:00 /usr/bin/memcached -m 64 -p 11211 -u memcache -l 127.0.0.1 -P /var/run/memcached/memcached.pid
</code>
===== Paramétrer memcached dans php =====
Il faut ajouter des paramètres dans la configuration de PHP. J'ai dédié un fichier de paramétrage ''sudo nano /etc/php/7.4/fpm/conf.d/20-apcu.ini''
<code>
extension=apcu.so
apc.enabled=1
apc.shm_size=256M
apc.ttl=7200
apc.enable_cli=1
apc.gc_ttl=3600
apc.entries_hint=4096
apc.slam_defense=1
apc.serializer=php
</code>
===== Vérifier le fonctionne de memcached par php =====
Pour vérifier la prise en compte, il suffit de demande à phpinfo().
<code PHP>
<?php
phpinfo();
?>
</code>
{{ informatique:serveur:web-linux-apache:pasted:20201230-155201.png }}

111
data/pages/informatique/serveur/web-linux-apache/comment_demenager_un_hebergement_web_sans_trop_de_perturbations.txt Normal file
View File

@@ -0,0 +1,111 @@
====== Comment déménager un hébergement web sans trop de perturbations ? ======
{{ :journal_geek:demenager_1.png?direct&400|}}
Je veux changer d’hébergement un site Internet. Le site Internet est sur un vieux Debian et je veux le migrer sur un nouveau Debian. Le souci est que le changement d'adresse IP oblige une propagation DNS qui peut prendre 24 heures. Cela implique pendant cette transition de figer les écritures dans les fichiers du site. Ce qui n'est pas pensable.
Apache propose une fonctionnalité qui s'appelle "reverse proxy". Il permet d'être le destinataire d'un appel à un site et transmettre cette requête à un autre serveur Apache.
===== De la résolution du nom de domaine à la réponse du serveur Web =====
<WRAP center round tip>
Les noms de domaines et adresses IP utilisés dans cette page ne sont que fictions.
</WRAP>
D'abord, comprenons comment l'accès à un site fonctionne. Lorsque que j’appelle le site ''perdu.com'', le système DNS se met en œuvre pour fournir une adresse IP à votre ordinateur. C'est le principe d'un nom de domaine : associé une adresse IP à un nom. Donc, au moment de la création du nom de domaine, l'adresse IP a été renseignée.
{{ :journal_geek:resolution_dns_1.png?direct |}}
Cette adresse IP a été définie au moment de la création de l’hébergement du site Internet. C'est l'adresse du serveur Web Apache.
{{ :journal_geek:chemin_vers_serveurweb_01.png?direct |}}
Avec un serveur Web, il peut y avoir plusieurs sites hébergés. Le serveur Web Apache peut gérer plusieurs sites Internet. De ce fait, une adresse IP peut correspondre à plusieurs sites Internet, donc plusieurs noms de domaine.
Dans notre exemple, nous avons le site ''perdu.com'' et le site ''trouve.com'' qui correspondent tous les deux à l'adresse 208.97.177.124, donc au même serveur Web.
On peut utiliser le site [[https://ipinfo.io/91.134.242.127|ipinfo.io]] pour vérifier le nombre de sites hébergés par un serveur.
{{ :journal_geek:multisites_1.png?direct |}}
Lorsque le serveur Web Apache va recevoir la demande provenant de la demande d'accès, il recevra le nom de domaine dans le paramètre ''Host''. C'est le protocole HTTP.
{{ :journal_geek:entete_http_demande_1.png?direct |}}
Et grâce à la configuration des sites Web, Apache sera capable de récupérer les fichiers associés au bon nom de domaine.
Voici un exemple de configuration du serveur :
<code>
# Apache doit écouter sur le port 80
Listen 80
# Toutes les adresses IP doivent répondre aux requêtes sur les
# serveurs virtuels
NameVirtualHost *:80
<VirtualHost *:80>
DocumentRoot /var/www/trouve.com
ServerName trouve.com
# Autres directives ici
</VirtualHost>
<VirtualHost *:80>
DocumentRoot /var/www/perdu.com
ServerName perdu.com
# Autres directives ici
</VirtualHost>
</code>
Pour résumer, votre serveur ne dispose que d'une seule adresse IP, et de nombreux alias (CNAMES) peuvent pointer vers cette adresse dans le DNS.
D'autres exemples sont disponibles sur le site [[https://httpd.apache.org/docs/2.4/fr/vhosts/examples.html|Apache 2.4]]
===== Transfert des fichiers =====
En attendant, je vais transférer les fichiers du site actuel vers le nouveau serveur Web (103.224.182.253).
Le transfert va s'effectuer en deux passes. La première passe permet de transférer le plus gros du site. Il faut prendre en considération tous les gros fichiers qui peuvent prendre du temps à copier, ou tous les petits fichiers qui sont nombreux et peuvent prendre également du temps à transférer.
<code>
rsync -avz /var/www/perdu.com -e "ssh -p 11822" chloe@103.224.182.253:"/var/www/"
</code>
''rsync'' doit être installé sur le serveur distant.
Une fois cette opération terminer, il faudra effectuer une seconde passe pour synchroniser les fichiers fraichement modifiés. Durant cette phase, il faudra veiller à ce que le site soit inaccessible.
===== Reverse Proxy =====
Je vais employer une directive de proxy dans Apache pour transférer le nom de domaine vers le nouveau serveur web (103.224.182.253).
{{ :journal_geek:reverse_proxy_1.png?direct |}}
Sur l'ancien serveur Web, je vais activer le mode Proxy :
<code>
sudo a2enmod proxy_http
</code>
Je vais utiliser les directives ''proxyPass'' et ''proxyPassReverse'' pour indiquer l'adresse IP du nouveau serveur :
<code>
<VirtualHost *:80>
ProxyPreserveHost On
ProxyPass "/" "http://103.224.182.253/"
ProxyPassReverse "/" "http://103.224.182.253/"
ServerName perdu.com
</VirtualHost>
</code>
A partir de maintenant, le site peut de nouveau être opérationnel :
<code>
sudo service apache2 restart
</code>
On peut désormais s'occuper des DNS pour modifier l'adresse IP associée au nom de domaine.
--- //[[user:cedricabonnel]] 2019/08/02 18:09//

42
data/pages/informatique/serveur/web-linux-apache/configurer-apache2-pour-php-fpm.txt Normal file
View File

@@ -0,0 +1,42 @@
====== Configurer Apache 2 pour PHP FPM ======
A noter que la **configuration de FPM pour Apache 2** s'effectue directement dans le fichier de configuration ''/etc/php/7.4/fpm/pool.d/www.conf''. Nous n'interviendrons pas dans ce fichier.
**Activer le module proxy** FCGI pour Apache2 en exécutant le code suivant.
<code BASH>
sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php7.4-fpm
</code>
**Modifier l'ordre de traitement des pages index** dans le fichier ''/etc/apache2/mods-available/dir.conf''
<code INI>
DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm
</code>
**Ajouter l'appel à PHP** dans le fichier de configuration associé au **ServerName** ''/etc/apache2/sites-available/100-exemple.conf''
Suivant la version d'Apache, l'instruction **SetHandler** ne sera pas la même. Pour connaitre, la version d'Apache, executer ''sudo apachectl -V''.
<code>
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/html
<Directory /var/www/html>
Options -Indexes +FollowSymLinks +MultiViews
AllowOverride All
Require all granted
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
</code>
**Redémarrer** les services Apache2 et PHP FPM:
<code BASH>
$ sudo systemctl restart php7.4-fpm apache2
</code>

124
data/pages/informatique/serveur/web-linux-apache/configurer-autodiscover.txt Normal file
View File

@@ -0,0 +1,124 @@
====== Configurer Autodiscover et Autoconfig ======
{{ :dummy.png?75x75|Nom de la section}}
===== DNS =====
_autodiscover._tcp.yourdomain.com. 3600 IN SRV 10 10 443 mail.yourmx.com.
===== Autodiscover pour Outlook =====
<code PHP autodiscover.php>
<?php
$postData = file_get_contents('php://input'); //Autodiscover requests are HTTP posts with XML content
$xml = simplexml_load_string($postData);
$user = $xml->Request->EMailAddress; //copy the email address from the request into a variable
//set Content-Type
header("Content-Type: application/xml");
?>
<?php echo '<?xml version="1.0" encoding="utf-8" ?>'; ?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>POP3</Type>
<Server>mail.yourmx.com</Server>
<Port>995</Port>
<LoginName><?php echo $user; ?></LoginName>
<DomainRequired>off</DomainRequired>
<SPA>off</SPA>
<SSL>on</SSL>
<AuthRequired>on</AuthRequired>
<DomainRequired>on</DomainRequired>
</Protocol>
<Protocol>
<Type>IMAP</Type>
<Server>mail.yourmx.com</Server>
<Port>993</Port>
<DomainRequired>on</DomainRequired>
<LoginName><?php echo $user; ?></LoginName>
<SPA>off</SPA>
<SSL>on</SSL>
<Encryption>Auto</Encryption>
<AuthRequired>on</AuthRequired>
</Protocol>
<Protocol>
<Type>SMTP</Type>
<Server>mail.yourmx.com</Server>
<Port>587</Port>
<DomainRequired>on</DomainRequired>
<LoginName><?php echo $user; ?></LoginName>
<SPA>off</SPA>
<Encryption>Auto</Encryption> <!-- if your server requires encrypotion other than SSL -->
<AuthRequired>on</AuthRequired>
<UsePOPAuth>on</UsePOPAuth>
<SMTPLast>off</SMTPLast>
</Protocol>
</Account>
</Response>
</Autodiscover>
</code>
===== Directives Apache =====
<code>
ServerAlias autoconfig.*
RewriteEngine On
RewriteCond %{HTTPS} !on [OR]
RewriteCond %{HTTP_HOST} !^discover\.my-service\.com$
RewriteRule ^(.*)$ https://discover.my-service.com$1 [R=301]
</code>
===== Certificat SSL =====
Remember to get a SIGNED SSL Cert.
===== Autoconfig pour Thunderbird =====
<code XML config-v1.1.xml>
<?xml version="1.0" encoding="UTF-8"?>
<clientConfig version="1.1">
<emailProvider id="domain.tld">
<domain>domain.tld</domain>
<displayName>Mail</displayName>
<displayShortName>Mail</displayShortName>
<incomingServer type="pop3">
<hostname>mailserver.domain.tld</hostname>
<port>995</port>
<socketType>SSL</socketType>
<authentication>password-cleartext</authentication>
<username>%EMAILADDRESS%</username>
<pop3>
<leaveMessagesOnServer>true</leaveMessagesOnServer>
<downloadOnBiff>true</downloadOnBiff>
<daysToLeaveMessagesOnServer>10</daysToLeaveMessagesOnServer>
</pop3>
</incomingServer>
<incomingServer type="imap">
<hostname>mailserver.domain.tld</hostname>
<port>993</port>
<socketType>SSL</socketType>
<authentication>password-cleartext</authentication>
<username>%EMAILADDRESS%</username>
</incomingServer>
<outgoingServer type="smtp">
<hostname>mailserver.domain.tld</hostname>
<port>587</port>
<socketType>STARTTLS</socketType>
<authentication>password-cleartext</authentication>
<username>%EMAILADDRESS%</username>
</outgoingServer>
</emailProvider>
</clientConfig>
</code>

67
data/pages/informatique/serveur/web-linux-apache/configurer-ipv6-sur-son-site.txt Normal file
View File

@@ -0,0 +1,67 @@
====== Configurer ipv6 sur son site ======
{{ :dummy.png?75x75|Nom de la section}}
^ Terme ^ Description | Exemple |
| YOUR_IPV6 | Il s'agit de l’adresse IPv6 assignée à votre service | 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:yyyy |
| IPv6_PREFIX | Il s'agit du préfixe (ou netmask) de votre bloc IPv6, généralement de 64 | 2001:xxxx:xxxx:xxxx::/64\\ ou 64 |
| IPv6_GATEWAY | Il s'agit de la passerelle de votre bloc IPv6 | 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:zzzz |
| INT_NET | Il s'agit de l'interface réseau utilisée pour communiquer avec Internet | eth0\\ enp1s0 |
**YOUR_IPV6** est fourni par le prestataire associée à votre hébergement. Il doit être disponible dans votre espace client.
Quelques exemples :
| {{informatique:serveur:web-linux-apache:pasted:20210220-084138.png}} |
| {{informatique:serveur:web-linux-apache:pasted:20210220-084202.png}} |
De manière générale, l'adresse **IPv6_GATEWAY** se calcule depuis l'adresse **YOUR_IPV6**. Il faut prendre les 28 premiers bits et ajouter **00:0:0:0:1**. Par exemple **2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:yyyy** devient **2001:xxxx:xxxx::xx00:0:0:0:1**
----
Pour **Debian**, il est nécessaire de créer un nouveau fichier **interfaces** pour une prise en compte permanente.
Éditer le fichier ''/etc/network/interfaces.d/51-cloud-init-ipv6.cfg'' ou équivalent avec les valeurs suivantes.
Remplacer les éléments génériques (c’est-à-dire YOUR_IPV6, IPV6_PREFIX et IPV6_GATEWAY) ainsi que l’interface réseau (INT_NET) par vos valeurs personnalisées.
<code>
auto INT_NET
iface INT_NET inet6 static
mtu 1500
address YOUR_IPV6
netmask IPV6_PREFIX
post-up /sbin/ip -6 route add IPV6_GATEWAY dev INT_NET
post-up /sbin/ip -6 route add default via IPV6_GATEWAY dev INT_NET
pre-down /sbin/ip -6 route del default via IPV6_GATEWAY dev INT_NET
pre-down /sbin/ip -6 route del IPV6_GATEWAY dev INT_NET
</code>
exemple concret
<code>
auto enp1s0
iface enp1s0 inet6 static
mtu 1500
address 2001:41d1:1:8241::1
netmask 64
post-up /sbin/ip -6 route add 2001:41d1:1:8200:0:0:0:1 dev enp1s0
post-up /sbin/ip -6 route add default via 2001:41d1:1:8200:0:0:0:1 dev enp1s0
pre-down /sbin/ip -6 route del default via 2001:41d1:1:8200:0:0:0:1 dev enp1s0
pre-down /sbin/ip -6 route del 2001:41d1:1:8200:0:0:0:1 dev enp1s0
</code>
Il suffit de redémarrer l'interface réseau :
systemctl restart networking
Pour tester, utiliser un **ping** en ipv6 :
ping abonnel.fr -6
----
Déclarer l'adresse IPv6 dans la zone DNS du site concerné, dans un enregistrement **AAAA**.
{{informatique:serveur:web-linux-apache:pasted:20210220-085027.png}}

13
data/pages/informatique/serveur/web-linux-apache/configurer-php-fpm.txt Normal file
View File

@@ -0,0 +1,13 @@
====== Configurer PHP FPM ======
{{ :dummy.png?75x75|Nom de la section}}
La configuration de PHP FPM s'effectue dans le fichier ''/etc/php/7.4/fpm/php.ini''
===== timezone =====
date.timezone = "Europe/Paris"
===== Prise en compte des modifications =====
systemctl restart apache2 php7.4-fpm

12
data/pages/informatique/serveur/web-linux-apache/configurer-plusieurs-versions-de-php-avec-apache-2-4.txt Normal file
View File

@@ -0,0 +1,12 @@
====== Configurer plusieurs versions de PHP avec Apache 2.4 ======
{{ :dummy.png?75x75|Configurer plusieurs versions de PHP avec Apache 2.4}}
Ce tutoriel va vous aider à configurer plusieurs versions de PHP avec Apache avec une distribution Linux Debian 10.6.
Ce tutoriel décrit l'installation et la configuration de deux //VirtualHost// dans Apache avec un chacun une version de PHP différente. La première configuration fonctionnera avec PHP5.6 et l'autre avec PHP 7.4. vous pouvez utiliser autant de version PHP avec Apache sans pré requis supplémentaire, il suffit d'appliquer le principe enseigné dans ce tutoriel.
Ce tutoriel a été testé sur **Debian 10.6 pour ARM (Raspbian / Raspberry OS)** le **12/10/2020**.
{{page>informatique:serveur-web-linux-apache:php#installer-une-seconde-version-de-php}}

60
data/pages/informatique/serveur/web-linux-apache/configurer_un_site_web_apache_2/creer_un_groupe_d_utilisateurs_pour_un_site_web.txt Normal file
View File

@@ -0,0 +1,60 @@
====== Créer un groupe d'utilisateurs pour un site Web ======
<note tip>Cet article fait partie de la collection [[informatique:applications:configurer_un_site_web_apache_2:index]]</note>
{{page>informatique:linux:applications:configurer_un_site_web_apache_2:configuration_utilisee}}
{{page>informatique:serveur-web-linux-apache:definitions_et_contexte}}
Avant de créer un site dans la configuration Apache 2, vous devez déterminer un groupe d'utilisateurs (administrateurs, développeurs, opérateurs...) qui devront accéder aux fichiers du site.
Le bonne pratique est de créer un groupe d'utilisateur qui sera en charge du maintient du site web. Même pour un seul utilisateur cette méthode est valable et __évolutive__. Il est vivement conseillé de créer __un groupe par site Internet__.
===== Créer un groupe =====
<code>
sudo groupadd www-perdu.com
</code>
===== Associer l'utilisateur au groupe =====
<code>
sudo usermod -a -G www-perdu.com chloe
</code>
Si vous êtes logué avec le compte ''chloe'', il faut se déconnecter et connecter pour que ''usermod'' soit pris en compte.
===== Créer les dossiers du site =====
Je vais créer le dossier du site dans ''/var/www''. Les droits seront automatiquement donnés à ''root'' afin d'empêcher n'importe qui d'aller modifier le contenu.
<code>
sudo mkdir -p /var/www/perdu.com/www
sudo chown -R root /var/www/perdu.com
</code>
===== Modifier le groupe des dossiers du site =====
L'objectif est de données les droits au groupe ''www-perdu.com'' et de restreindre l'accès en lecture seule aux autres groupes d'utilisateurs.
<code>
sudo chgrp -R www-perdu.com /var/www/perdu.com
sudo chmod -R 775 /var/www/perdu.com
</code>
Lorsque qu'un fichier est créé, afin de garder la priorité au groupe de développeurs, j'attribue l'option ''s''
<code>
sudo chmod -R g+s /var/www/perdu.com
</code>
S'il est nécessaire d'autoriser Apache à modifier le contenu d'un dossier, par exemple ''uploads'', je modifierai les droits en attribuant le groupe à ''www-data'' (groupe d'utilisation d'Apache 2).
<code>
sudo chown -R www-data /var/www/perdu.com/www/uploads
</code>
--- //[[user:cedricabonnel]] 2019/07/26 18:18//

62
data/pages/informatique/serveur/web-linux-apache/configurer_un_site_web_apache_2/site_apache_24_sous_domaine_autre.txt Normal file
View File

@@ -0,0 +1,62 @@
===== Configuration du site avec sous-domaine autre que www avec Apache 2.4 =====
{{tag>"serveur web"}}
La configuration du site Internet s'effectue dans un fichier de configuration.
* Il accepte une connexion sur le port http (80) pour rediriger les visiteurs vers le https (443).
* Il permet une connexion de certbot / let's encrypt pour obtenir ou renouveler un certificat SSL sur le port 80.
* Il permet d'avoir des logs dans des dossiers séparés
Voici les paramètres qu'il faut veiller à modifier :
^ fichier de configuration du site | /etc/apache2/sites-available/100-com.perdu-podcast.divers.conf |
^ fichier log accès | ${APACHE_LOG_DIR}/divers.perdu-podcast.com-access.log |
^ fichier log erreurs | ${APACHE_LOG_DIR}/divers.perdu-podcast.com-error.log |
^ dossier racine du site | /home/www-master/perdu-podcast.com/divers |
^ dossier certificats SSL | /etc/letsencrypt/live/divers.perdu-podcast.com/ |
^ Fichier de configuration SSL | /etc/letsencrypt/options-ssl-apache.conf\\ /etc/apache2/redirect_80_2_443.conf |
<code>
<VirtualHost *:80>
ServerName divers.perdu-podcast.com
# Redirection des URL vers https
Include /etc/apache2/redirect_80_2_443.conf
</VirtualHost>
<VirtualHost *:443>
ServerName divers.perdu-podcast.com
DocumentRoot /home/www-master/perdu-podcast.com/divers
<Directory /home/www-master/perdu-podcast.com/divers>
Options -Indexes
AllowOverride all
Order allow,deny
allow from all
</Directory>
<Location />
Require all granted
</Location>
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/divers.perdu-podcast.com-error.log
CustomLog ${APACHE_LOG_DIR}/divers.perdu-podcast.com-access.log combined
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/divers.perdu-podcast.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/divers.perdu-podcast.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</code>

12
data/pages/informatique/serveur/web-linux-apache/definitions_et_contexte.txt Normal file
View File

@@ -0,0 +1,12 @@
====== Définitions et contexte ======
Vous trouverez des informations personnelles qu'il faudra adapter suivant votre contexte.
^ dossier racine du site Web | ''/var/www/perdu.com'' |
^ dossiers modifiables par Apache2 | ''/var/www/perdu.com/www/uploads'' |
^ les fichiers de configuration du site | ''/etc/apache2/sites-available/100.com.perdu.conf'' |
^ hostname et alias | ''perdu.com'' et ''www.perdu.com'' |
^ personnes gestionnaire du site | ''chloe'' |
^ groupe de développeurs | ''www-perdu.com'' |
^ fichier log accès | ''/var/www/perdu.com/logs/http-info-access.log'' |
^ fichier log erreurs | ''/var/www/perdu-com/logs/http-info-error.log'' |

26
data/pages/informatique/serveur/web-linux-apache/directives-apache2-serveur-configuration-repertoire.txt Normal file
View File

@@ -0,0 +1,26 @@
====== Directives Apache 2 ======
{{ :dummy.png?75x75|Options possibles pour la configuration d'un site}}
===== MultiViews =====
Les vues multiples ("**multiviews**") à contenu négocié permet une recherche de correspondance de modèle de nom de fichier implicite, et fait son choix parmi les résultats.
> <code>https://a5l.fr/login => https://a5l.fr/login.php</code>
Cette option est ignorée si elle est définie en tout autre endroit qu'une section **<Directory>**.
La directive [[https://httpd.apache.org/docs/current/content-negotiation.html#page-header|Multiviews]] à les effets suivants : Si le serveur reçoit une requête pour **/un/répertoire/foo**, et si **/un/répertoire/foo** n'existe pas, le serveur parcourt le répertoire à la recherche de tous les fichiers de nom **foo.***, et simule véritablement une correspondance de type qui nomme tous ces fichiers en leur assignant les mêmes type de média et codage de contenu qu'ils auraient eus si le client avait requis l'un d'entre eux avec son nom complet. Il choisit ensuite le fichier qui correspond le mieux au profile du client, puis renvoie le document.
Exemple de paramétrage dans la configuration Apache :
<code INI>
<Directory /var/www/html>
Options -Indexes +FollowSymLinks +MultiViews
AddType application/x-httpd-php .php
AllowOverride All
Require all granted
</Directory>
</code>
--

93
data/pages/informatique/serveur/web-linux-apache/dolibarr.txt Normal file
View File

@@ -0,0 +1,93 @@
====== dolibarr ======
{{ :dummy.png?75x75|dolibarr}}
====== Sauvegarde ======
<code>
mysqldump -u user -pyourpass --result-file=mysqldump_databasename_version_date.sql databasename| bzip2 > mysqldump_databasename_version_date.bz2
</code>
avec
* ''databasename'' le nom de la base de données utilisée par Dolibarr
* ''user'' le nom de l'utilisateur de la base de données ''databasename''
* ''yourpass'' le mot de passe associé au ''user''
* ''mysqldump_databasename_version_date'' le nom du fichier de sauvegarde
Certaines informations sont disponibles dans le fichier ''dolibarrdir/htdocs/conf/conf.php''
le nom du fichier de sauvegarde ''mysqldump_databasename_version_date'' peut se décomposer
* ''databasename'' le nom de la base de données utilisée par Dolibarr
* ''version'' la version de Dolibarr
* ''date'' la date de la sauvegarde au format YYYYMMDD
Exemple de script CRON :
<code>
30 1 * * * mysqldump databasename -h host -u user -pyourpass -l --single-transaction -K --add-drop-table=TRUE --tables -c -e --hex-blob --default-character-set=utf8 | bzip2 > mysqldump_databasename_3.6_`date +%Y%m%d`.sql.bz2
</code>
====== Mise à jour ======
Depuis un très ancienne version, une 3.6.2. Il y a des problèmes qui empêchent d'accéder à certaines fonctions de la version 12 (créer un nouveau **Tiers**...). J'avais le message 404 : //File not found//. J'ai dû effectuer une installation neuve, en figeant l'ancienne version.
====== Déploiement ======
Pour une **mise à jour** ou une **installation**, la procédure est identique.
Liste des versions disponibles sur [[https://sourceforge.net/projects/dolibarr/files/Dolibarr%20ERP-CRM/]]
<code>
cd /var/www
unzip dolibarr-11.0.4.zip
cp -r dolibarr-11.0.4/* dolibarr
rm -fr dolibarr-11.0.4
sudo apt install php-curl php-intl php-zip
sudo systemctl restart php-fpm apache2
</code>
Vérifier le paramétrage d'Apache dans un fichier ''/etc/apache2/sites-available/100-dolibarr.conf'' :
<code 100-dolibarr.conf>
Alias /dolibarr /var/www/dolibarr/htdocs
<Directory /var/www/dolibarr/htdocs>
# Options Indexes FollowSymLinks
DirectoryIndex index.php
# <IfModule mod_php5.c>
# AddType application/x-httpd-php .php
# php_flag magic_quotes_gpc Off
# php_flag track_vars On
# php_flag register_globals Off
# php_value include_path .
# </IfModule>
</Directory>
</code>
Pour une mise à jour, il faut effacer le fichier suivant :
<code>
sudo rm dolibarr/documents/install.lock
</code>
Puis se rendre sur la page http://serveur/dolibarr/install
====== Erreurs durant la mise à jour ======
<code>
Erreur DB_ERROR_1118: ALTER TABLE llx_cronjob ADD COLUMN entity integer DEFAULT 0;
Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
</code>
Il faut relancer la précédente étape de mise à jour.

7
data/pages/informatique/serveur/web-linux-apache/forcer-la-reinitialisation-d-un-mot-de-passe-nextcloud.txt Normal file
View File

@@ -0,0 +1,7 @@
====== Forcer la réinitialisation d'un mot de passe utilisateur NextCloud ======
{{ :dummy.png?75x75|Forcer la réinitialisation d'un mot de passe utilisateur NextCloud}}
Pour réinitialiser le mot d'un utilisateur, il est possible de le faire en ligne de commande. Par exemple, pour réinitialiser le mot de passe du compte admin :
<code>
sudo -u www-data php /var/www/nextcloud/occ user:resetpassword admin
</code>

68
data/pages/informatique/serveur/web-linux-apache/http_apache2.txt Normal file
View File

@@ -0,0 +1,68 @@
====== Configurer un site en http pour un sous-domaine spécifique ======
{{ :dummy.png?75x75|Nom de la section}}
Voici mes prises de notes pour configurer un site Internet **http**. Le configuration est destinée pour un site Internet dont le sous-domaine est **srv195**.
<code>
Configurer Apache 2 pour un site Internet
http://srv195.acego.fr
</code>
===== Pré requis =====
La configuration du site Internet s'effectue dans un fichier de configuration.
* Il accepte une connexion sur le port http 80.
* Il accepte les connexions vers le ''srv195.acego.fr''.
* Il permet d'avoir des logs dans des dossiers séparés
{{page>informatique:serveur-web-linux-apache:definitions_et_contexte}}
===== Configuration Apache 2 =====
On configure un site web à partir d'un fichier ''conf'' qui contient des directives. Dans notre exemple de fichier ''conf'', il sera configuré le site Internet ''srv195.acego.fr''.
Le fichier à créer est ''/etc/apache2/sites-available/100-fr.acego.srv195.conf'' :
<code>
<VirtualHost *:80>
ServerName srv195.acego.fr
Protocols h2 http/1.1
DocumentRoot /var/www/acego.fr/srv195
<Directory /var/www/acego.fr/srv195>
Options -Indexes
AllowOverride all
Order allow,deny
allow from all
</Directory>
<Location />
Require all granted
</Location>
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/srv195.acego.fr-error.log
CustomLog ${APACHE_LOG_DIR}/srv195.acego.fr-access.log combined
</VirtualHost>
</code>
===== Activer la configuration du site =====
On active la configuration du site en utilisant le binaire ''a2ensite''
<code>
sudo a2ensite 100-fr.acego.srv195
</code>
Et si tout se passe bien, on recharge la configuration d'Apache 2 sans avoir besoin de redémarre le service :
<code>
sudo service apache2 reload
</code>
--- //[[user:cedricabonnel]] 2020/05/03 16:59//

66
data/pages/informatique/serveur/web-linux-apache/http_proxy_apache2.txt Normal file
View File

@@ -0,0 +1,66 @@
====== Apache 2 : reverse-proxy : configurer un site http avec sous-domaine en www ======
Voici mes prises de notes pour configurer un reverse-proxy avec Apache 2.
<code>
Configurer Apache 2
http://www.abonnel.fr <==[reverse proxy ]==> 51.23.41.1
</code>
===== Pré requis =====
La configuration du site Internet s'effectue dans un fichier de configuration.
* Il accepte une connexion sur le port http 80.
* Il redirige vers un hébergement par http avec adresse IP
{{page>informatique:linux:solutions_linux:configurer_un_site_web_apache_2:definitions_et_contexte_proxy}}
===== Configuration Apache 2 =====
On configure un site web à partir d'un fichier ''conf'' qui contient des directives. Dans notre exemple de fichier ''conf'' configure le site Internet ''extra.perdu.com''.
Le fichier à créer est ''/etc/apache2/sites-available/100.com.perdu.extra.conf'' :
<code>
<VirtualHost *:80>
ServerName extra.perdu.com
ProxyPass /.well-known/acme-challenge !
Alias /.well-known/acme-challenge /var/www/html/.well-known/acme-challenge
<Directory "/var/www/html/.well-known/acme-challenge">
Options None
AllowOverride None
Require all granted
AddDefaultCharset off
</Directory>
ProxyPreserveHost On
ProxyPass "/" "http://103.224.182.253/"
ProxyPassReverse "/" "http://103.224.182.253/"
</VirtualHost>
</code>
Afin de prévenir notre paramétrage futur en https, la directive ''RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge/.*'' permet de ne pas rediriger les appels pour Let's Encrypt (http/301). En effet, Let's encrypt n'accepte que des status http/200 lorsque nous mettrons en œuvre l'ajout d'un certificat SSL.
Cette directive peut-être laissée active, même si vous ne prévoyez pas d'ajouter une certificat SSL avec Let's Encrypt.
===== Activer la configuration du site =====
On active la configuration du site en utilisant le binaire ''a2ensite''
<code>
sudo a2ensite 100-com.perdu.extra.conf
</code>
Et si tout se passe bien, on recharge la configuration d'Apache 2 sans avoir besoin de redémarre le service :
<code>
sudo service apache2 reload
</code>
--- //[[user:cedricabonnel]] 2019/07/26 18:54//

79
data/pages/informatique/serveur/web-linux-apache/http_www_apache2.txt Normal file
View File

@@ -0,0 +1,79 @@
====== Configurer un site www en http ======
Voici mes prises de notes pour configurer un site Internet **http**. Le configuration est destinée pour un site Internet commençant par **www**.
<code>
Configurer Apache 2 pour un site Internet
http://www.abonnel.fr
</code>
===== Pré requis et objectifs =====
La configuration du site Internet s'effectue dans un fichier de configuration.
* Il accepte une connexion sur le port http 80.
* Il permet des connexions sans le ''www'' pour être redirigé vers le ''www''.
* Il permet d'avoir des logs dans des fichiers séparés
===== Configuration Apache 2 =====
On configure un site web à partir d'un fichier ''conf'' qui contient des directives. Dans notre exemple de fichier ''conf'', il sera configuré le site Internet ''abonnel.fr'' et son alias ''www.abonnel.fr''.
Le fichier à créer est ''/etc/apache2/sites-available/100-fr.abonnel.conf''.
A noter qu'afin de prévenir notre paramétrage futur en **https**, la directive ''RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge/.*'' permet de ne pas rediriger les appels pour Let's Encrypt (http/301). En effet, Let's encrypt n'accepte que des status http/200 lorsque nous mettrons en œuvre l'ajout d'un certificat SSL.
Cette directive peut-être laissée active, même si vous ne prévoyez pas d'ajouter une certificat SSL avec Let's Encrypt.
<code>
<VirtualHost *:80>
ServerName abonnel.fr
ServerAlias www.abonnel.fr
Protocols h2 http/1.1
DocumentRoot /var/www/abonnel.fr/www
<Directory /var/www/abonnel.fr/www>
Options -Indexes +MultiViews
AllowOverride all
Order allow,deny
allow from all
</Directory>
<Location />
Require all granted
</Location>
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/abonnel.fr-error.log
CustomLog ${APACHE_LOG_DIR}/abonnel.fr-access.log combined
# Redirection des URL sans www
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge/.*
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>
</code>
===== Activer la configuration du site =====
On active la configuration du site en utilisant le binaire ''a2ensite''
<code>
sudo a2ensite 100-fr.abonnel.conf
</code>
Et si tout se passe bien, on recharge la configuration d'Apache 2 sans avoir besoin de redémarre le service :
<code>
sudo service apache2 reload
</code>

146
data/pages/informatique/serveur/web-linux-apache/https_proxy_apache2.txt Normal file
View File

@@ -0,0 +1,146 @@
====== Apache 2 : proxy-reverse : configurer un site en https pour un sous-domaine ======
Voici mes prises de notes pour configurer un site Internet **http**. Le configuration est destinée pour un site Internet commençant par **www**.
<code>
Configurer Apache 2
http://www.abonnel.fr ==> https://www.abonnel.fr <==[reverse-proxy]==> 54.1.23.4
</code>
===== Pré requis =====
Je viens de demander un [[ssl-let-s_encrypt-certbot-auto|certificat SSL]] pour le site Internet. Il faut configurer Apache 2 pour que :
* les demandes en https utilisent le certificat SSL
* toutes les visites en http soit redirigé en https
====== Configurer ======
Je complète le fichier de configuration ''/etc/apache2/sites-available/100-com.perdu.extra.conf''. J'ajoute un bloc de redirection vers ''https'' :
<code>
RewriteEngine On
RewriteCond %{SERVER_NAME} =extra.perdu.com
RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge/.*
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</code>
Puis, j'ajoute un bloc pour la configuration SSL / https. Il s'agit d'un copier/coller de la configuration http.
J'effectue quelques modifications :
* [[linux:solutions_linux:configurer_un_site_web_apache_2:ErrorLog]] et [[linux:solutions_linux:configurer_un_site_web_apache_2:CustomLog]] pour l’écriture des fichiers logs
* [[linux:solutions_linux:configurer_un_site_web_apache_2:RewriteRule]] pour la redirection des URL sans www
* Ajout des options SSL
* Ajout de la gestion des certificats
<code>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName extra.perdu.com
ProxyPreserveHost On
ProxyPass "/" "http://103.224.182.253/"
ProxyPassReverse "/" "http://103.224.182.253/"
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/extra.perdu.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/extra.perdu.com/privkey.pem
</VirtualHost>
</IfModule>
</code>
Les options SSL sont à créer une seule fois sur le serveur. Ces options sont communes à tous les sites Internet que je configure.
Les options dans ''/etc/letsencrypt/options-ssl-apache.conf'' sont les suivantes :
<code>
SSLEngine on
# intermediate configuration, tweak to your needs
SSLProtocol -ALL +TLSv1.2
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:!RC4:HIGH:!MD5:!aNULL:!EDH
SSLHonorCipherOrder on
SSLCompression on
#SSLSessionTickets off
# -- Securité supplémentaire
SSLOptions +StrictRequire
# HSTS (mod_headers is required) (15768000 seconds = 6 months)
Header always set Strict-Transport-Security "max-age=15768000"
# Always ensure Cookies have "Secure" set (JAH 2012/1)
Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4"
</code>
----
Ce qui donne une configuration globale suivante :
<code>
<VirtualHost *:80>
ServerName extra.perdu.com
# ProxyPass devient obsolète avec RewriteRule
ProxyPass /.well-known/acme-challenge !
Alias /.well-known/acme-challenge /var/www/html/.well-known/acme-challenge
<Directory "/var/www/html/.well-known/acme-challenge">
Options None
AllowOverride None
Require all granted
AddDefaultCharset off
</Directory>
# Proxy* deviennent obsolète avec Rewrite*
ProxyPreserveHost On
ProxyPass "/" "http://103.224.182.253/"
ProxyPassReverse "/" "http://103.224.182.253/"
RewriteEngine On
RewriteCond %{SERVER_NAME} =info.mindcast.fr
RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge/.*
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName extra.perdu.com
ProxyPreserveHost On
ProxyPass "/" "http://103.224.182.253/"
ProxyPassReverse "/" "http://103.224.182.253/"
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/extra.perdu.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/extra.perdu.com/privkey.pem
</VirtualHost>
</IfModule>
</code>
====== Recharger ======
Après ces modifications, je recharge la configuration de Apache 2 :
<code>
sudo service apache2 reload
</code>
====== Liens ======
https://stackoverflow.com/questions/20406845/proxy-error-502-the-proxy-server-received-an-invalid-response-from-an-upstream

194
data/pages/informatique/serveur/web-linux-apache/https_www_apache2.txt Normal file
View File

@@ -0,0 +1,194 @@
====== Configurer un site en https ======
{{ informatique:serveur:web-linux-apache:pasted:20210121-012842.png?300}}
Votre certificat a été généré grâce à **Certbot**. Il faut désormais configurer **Apache** pour utiliser de manière systématique ce certificat.
Voici mes prises de notes pour passer un site Internet **http** en **https**. Le configuration est destinée pour un site Internet dont le sous-domaine est **www**. Il est très facilement adaptable pour un site avec un sous-domaine différent.
<code>
Configurer Apache 2
http://www.perdu.com ==> https://www.perdu.com
</code>
Je viens de demander un certificat SSL pour le site Internet ''perdu.com''. Il faut configurer Apache 2 pour que :
* les demandes en https utilisent le certificat SSL
* toutes les visites en http soit redirigées en https
====== Configurer ======
Je complète le fichier de configuration ''/etc/apache2/sites-available/100-com.perdu.conf''. J'ajoute un bloc de redirection vers ''https'' :
<code>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge/.*
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</code>
Puis, j'ajoute un bloc pour la configuration SSL / https. Il s'agit d'un copier/coller de la configuration http.
J'effectue quelques modifications :
* [[linux:solutions_linux:configurer_un_site_web_apache_2:ErrorLog]] et [[linux:solutions_linux:configurer_un_site_web_apache_2:CustomLog]] pour l’écriture des fichiers logs
* [[linux:solutions_linux:configurer_un_site_web_apache_2:RewriteRule]] pour la redirection des URL sans www
* Ajout des options SSL
* Ajout de la gestion des certificats
<code>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName perdu.com
ServerAlias www.perdu.com
Protocols h2 http/1.1
DocumentRoot /var/www/perdu.com/www
<Directory /var/www/perdu.com/www>
Options -Indexes +MultiViews
AllowOverride all
Order allow,deny
allow from all
</Directory>
<Location />
Require all granted
</Location>
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/www.perdu.com-https-error.log
CustomLog ${APACHE_LOG_DIR}/www.perdu.com-https-access.log combined
SSLCertificateFile /etc/letsencrypt/live/www.perdu.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.perdu.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.perdu.com/chain.pem
</VirtualHost>
</IfModule>
</code>
Les options SSL sont à créer une seule fois sur le serveur. Ces options sont communes à tous les sites Internet que je configure.
Les options dans ''/etc/apache2/mods-enabled/ssl.conf'' sont les suivantes :
<code>
# Intermediate configuration
SSLProtocol -ALL +TLSv1.2
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:!RC4:HIGH:!MD5:!aNULL:!EDH
SSLHonorCipherOrder on
#SSLSessionTickets off
SSLOptions +StrictRequire
SSLCompression off
# HSTS (mod_headers is required) (15768000 seconds = 6 months)
Header always set Strict-Transport-Security "max-age=15768000"
# Always ensure Cookies have "Secure" set (JAH 2012/1)
Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4"
</code>
Il convient de désactiver ces options dans le fichier ''/etc/letsencrypt/options-ssl-apache.conf''
----
Ce qui donne une configuration globale suivante :
<code>
<VirtualHost *:80>
ServerName perdu.com
ServerAlias www.perdu.com
Protocols h2 http/1.1
DocumentRoot /var/www/perdu.com/www
<Directory /var/www/perdu.com/www>
Options -Indexes +MultiViews
AllowOverride all
Order allow,deny
allow from all
</Directory>
<Location />
Require all granted
</Location>
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/www.perdu.com-http-error.log
CustomLog ${APACHE_LOG_DIR}/www.perdu.com-http-access.log combined
# Redirection des URL vers https
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge/.*
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName perdu.com
ServerAlias www.perdu.com
Protocols h2 http/1.1
DocumentRoot /var/www/perdu.com/www
<Directory /var/www/perdu.com/www>
Options -Indexes
AllowOverride all
Order allow,deny
allow from all
</Directory>
<Location />
Require all granted
</Location>
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/www.perdu.com-https-error.log
CustomLog ${APACHE_LOG_DIR}/www.perdu.com-https-access.log combined
SSLCertificateFile /etc/letsencrypt/live/www.perdu.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.perdu.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.perdu.com/chain.pem
</VirtualHost>
</IfModule>
</code>
====== Recharger ======
Après ces modifications, je recharge la configuration de Apache 2 :
<code>
sudo service apache2 reload
</code>
====== Zone DNS ======
Il est possible d'ajouter une option dans la zone DNS pour sécuriser l'authenticité de l'organisme de certification.
Il s'agit du //DNS Certification Authority Authorization (CAA)// à activer grâce à un enregistrement **CAA** de la zone DNS :
www IN CAA 128 issue "letsencrypt.org"
perdu.com. IN CAA 128 issue "letsencrypt.org"
====== Tester ======
Vous pouvez tester votre site grâce à l'outil https://www.ssllabs.com/ssltest/analyze.html

73
data/pages/informatique/serveur/web-linux-apache/index.txt Normal file
View File

@@ -0,0 +1,73 @@
====== Serveur Web Linux Apache ======
{{ informatique:serveur:web-linux-apache:pasted:20201225-185814.png?75x75|Serveur Web Linux Apache}}
Je vous invite à savoir comment faire pour installer et configurer un serveur **Web Liuux Apache**. Ceci inclus la configuration des fichiers et démarrer, arrêter et activer votre serveur httpd / Apache 2 Linux.
L'association des mots **Linux**, **Apache**, **MariaDB** et **PHP** donne l'acronyme **LAMP**. **Linux** est le __système d'exploitation__, ou OS, qui permet de faire cohabiter plusieurs programmes et produire un résultat. **Apache** est un programme qui fonctionne de manière continue afin de __fournir des pages Internet__ aux visiteurs. Sans **PHP** associé, les pages seraient statiques, c'est-à-dire que les pages fournies ressembleraient à du texte, sans que le texte puisse s'adapter. **PHP** permet de __rendre plus intelligent__ le site. Et enfin, **MariaDB** est __une base de données__. C'est un programme qui rassemble des données par thème et peuvent être triées, extraites et modifiées via des algorithmes précis.
Je vous propose une installation de ces applications, ainsi qu'un paramétrage qui vous permettra d'avoir une solution qui tient la route. C'est un premier pas afin d'avoir une solution clé en main avec les bons paramètres.
Les prérequis qui ne seront pas abordés, sont les suivants :
* **Debian 10** est installé sur un serveur VPS, serveur virtuel ...
* un accès **ssh** au serveur
* quelques notions de **BASH**
===== Table des matières =====
* [[.:|Introduction]]
* [[.:preparer-le-serveur-linux|]]
**Serveur LAMP à installer**
* Apache
* [[.:installer-apache-2-4|]]
* PHP
* [[.:installer-php-fpm|]]
* [[.:configurer-php-fpm|]]
* [[.:modifier-la-page-index-apache|]]
* [[.:configurer-apache2-pour-php-fpm|]]
* Apache, optimisations
* [[.:http_www_apache2]]
* [[.:http_apache2]]
* [[.:directives-apache2-serveur-configuration-repertoire]]
* [[.:www-data-droits]]
* [[.:accelerer-le-traitement-php|]]
* PHP, options
* [[.:php-installer-un-second-moteur|]]
* SGBD : MariaDB
* [[informatique:linux:applications:sgbd:mariadb:installer-mariadb-server]]
* [[informatique:serveur:web-linux-apache:reinitialiser-le-mot-de-passe-root-mysql]]
* [[informatique:serveur:web-linux-apache:installer-phpmyadmin]]
* Apache, https
* [[informatique:serveur:web-linux-apache:ssl-let-s-encrypt-certbot]]
* [[.:https_www_apache2|]]
* Réseau
* [[informatique:serveur:web-linux-apache:configurer-ipv6-sur-son-site]]
**maintenance**
* [[informatique:serveur:web-linux-apache:comment_demenager_un_hebergement_web_sans_trop_de_perturbations]]
**applications web**
* [[informatique:serveur:web-linux-apache:wordpress]]
* [[informatique:serveur:web-linux-apache:nextcloud]]
**articles obsolètes**
* [[.:lamp|]]
* [[informatique:serveur:web-linux-apache:ssl-let-s_encrypt-certbot-auto]]
* [[informatique:serveur:web-linux-apache:configurer-plusieurs-versions-de-php-avec-apache-2-4]]
* [[informatique:serveur:web-linux-apache:https_proxy_apache2]]

129
data/pages/informatique/serveur/web-linux-apache/install-lutim.txt Normal file
View File

@@ -0,0 +1,129 @@
====== Installer Lutim ======
Lutim est codé en Perl, pour le faire fonctionner il est nécessaire d’installer Carton, un gestionnaire de modules Perl.
<code>
sudo cpan Carton
</code>
Pour créer les aperçus des images après upload, il est nécessaire d’installer le logiciel ImageMagick et le module Perl qui correspond.
<code>
sudo apt-get install perlmagick
</code>
Créez un compte utilisateur ''lutim'' ainsi que le dossier ''/var/www/lutim'' ou ''/home/lutim/www'' dans lequel seront copiés les fichiers avec les droits d’accès correspondants.
<code>
useradd lutim
groupadd lutim
mkdir -p /home/lutim/www
chown -R lutim:lutim /home/lutim
</code>
Téléchargez les fichiers de la dernière version sur le dépôt officiel (« Download zip » en bas à droite ou bien en ligne de commande avec git), copiez son contenu dans le dossier /var/www/lutim et attribuez les droits des fichiers à l’utilisateur lutim
<code>
sudo apt-get install git
cd /home/lutim/www
sudo git clone https://git.framasoft.org/luc/lutim.git
chown lutim:lutim -R /home/lutim/www
</code>
Connectez-vous avec l’utilisateur lutim : ''su lutim -s /bin/bash'' et lancez la commande d’installation des dépendances depuis le dossier ''/home/lutim/www''
<code>
cd /home/lutim/www
su lutim -s /bin/bash
carton install
</code>
Maintenant que tout est prêt, modifiez le fichier de configuration de Lutim lutim.conf avec votre éditeur de texte préféré sur le modèle du fichier lutim.conf.template.
Par défaut le logiciel est configuré pour écouter sur le port 8080 de l’adresse 127.0.0.1 (localhost) et avec l’utilisateur www-data qu’il faut donc ici remplacer par lutim
cp lutim.conf.template lutim.conf
vim lutim.conf
L’ensemble des paramètres sont facultatifs à l’exception du paramètre contact (pensez bien à le configurer et à le décommenter) mais il peut être utile de chiffrer systématiquement les images : always_encrypt => 1
Lutim en tant que service
À présent, le serveur tournera lorsque qu’on lancera en tant que root cette commande :
carton exec hypnotoad script/lutim
Pour éviter de devoir relancer le serveur à la main à chaque redémarrage du serveur, on va donc lancer Lutim sous forme de service. Il faut pour ça copier le script utilities/lutim.init dans le fichier /etc/init.d/lutim, le rendre exécutable puis copier le fichier utilities/lutim.default dans /etc/default/lutim.
cp utilities/lutim.init /etc/init.d/lutim
cp utilities/lutim.default /etc/default/lutim
Il faut maintenant modifier /etc/default/lutim pour y mettre le chemin d’installation de notre Lutim (/var/www/lutim si vous n’avez pas changé le chemin préconisé par ce tutoriel)
vim /etc/default/lutim
chmod +x /etc/init.d/lutim
chown root:root /etc/init.d/lutim /etc/default/lutim
4 – Pailler
À ce stade, si tout s’est bien passé, lorsque vous exécutez la commande service lutim start, Lutim est pleinement fonctionnel. Vous n’avez qu’à vous rendre sur l’URL http://127.0.0.1:8080 pour pouvoir l’utiliser.
Nous allons maintenant configurer Lutim pour le rendre accessible depuis un nom de domaine avec Nginx (vous pouvez également utiliser Apache ou Varnish puisque seule la fonctionnalité de proxy inverse nous intéresse).
Nginx
Installez le paquet :
apt-get install nginx
Créez le fichier de configuration de votre domaine /etc/nginx/sites-available/votre-nom-de-domaine pour y mettre ceci (en remplaçant « votre-nom-de-domaine ») et le port 8080 si vous l’avez changé dans la configuration de Lutim :
server {
listen 80 ;
server_name votre-nom-de-domaine ;
root /var/www/lutim/public ;
# Important pour la confidentialité des utilisateurs
access_log off ;
error_log /var/log/nginx/lutim.error.log ;
# Paramètre important ! À adapter en fonction de la configuration de Lutim
client_max_body_size 40M ;
location ~* ^/(img|css|font|js)/ {
try_files $uri @lutim ;
add_header Expires "Thu, 31 Dec 2037 23:55:55 GMT" ;
add_header Cache-Control "public, max-age=315360000" ;
}
location / {
try_files $uri @lutim ;
}
location @lutim {
proxy_pass http://127.0.0.1:8080 ;
proxy_set_header Host $host ;
proxy_set_header X-Real-IP $remote_addr ;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ;
proxy_set_header X-Remote-Port $remote_port ;
proxy_redirect off ;
}
}
Activez votre fichier :
ln -s /etc/nginx/sites-available/votre-nom-de-domaine /etc/nginx/sites-enabled/votre-nom-de-domaine
Enfin, relancez nginx : service restart nginx
5 – Tailler et désherber
La personnalisation de votre instance de Lutim passe par l’édition à la main des fichiers css, images et javascript qui se trouvent dans le dossier public et des fichiers du dossier templates ou public pour les fichiers statiques..
Les fichiers de langues se trouvent dans le dossier lib/Lutim/I18N.
Pour pouvoir personnaliser et observer vos modifications en direct, il vous faudra stopper temporairement le service service lutim stop et le démarrer avec la commande :
carton exec morbo script/lutim
Le serveur écoutera alors sur http://127.0.0.1:3000 mais vous pouvez le faire écouter sur le même port qu’avec hypnotoad pour continuer à passer par Nginx pendant votre développement :
carton exec morbo script/lutim --listen=http://127.0.0.1:8080

62
data/pages/informatique/serveur/web-linux-apache/installer-apache-2-4.txt Normal file
View File

@@ -0,0 +1,62 @@
====== Installer Apache 2.4 ======
{{ informatique:applications:pasted:20201012-221943.png?75x75|Installer Apache 2.4}}
===== Installer Apache 2.4 =====
Pour avoir votre site Internet ou fournir des pages Web ou autres joyeusetés dans votre Intranet, il faut installer le service Apache 2.. On l'appelle également le **service Web** ou encore **httpd**. Il permet de recevoir des requêtes et répondre en envoyant des ressources (pages HTML, contenu XML, fichiers divers…). Les protocoles de communication en standard sont http (80/tcp) et https (443/tcp).
Les **paquets d’installation** d'Apache sont disponibles dans les dépôts officiels et standard. Il suffit d'ouvrir un **Terminal** et d’exécuter les commandes suivantes pour déployer la dernière version du serveur Web Apache.
<code>
sudo apt update
sudo apt install apache2 libapache2-mod-fcgid
</code>
Des **paquets supplémentaires** vous seront proposés, je vous invite à les accepter car ils vous seront utiles.
C'est l'heure de la vérification. Une fois l'installation terminée vous pouvez ouvrir un navigateur et saisir votre nom de serveur dans la barre d'URL. Par exemple, tapez l'URL ''http://localhost/'', le résultat doit apparaître.
{{informatique:applications:pasted:20201012-221943.png}}
===== Activer des modules complémentaires =====
Il existe des **__modules__** qui permettent d'agrémenter les possibilités offertes par Apache 2. Il n'est pas nécessaire de les activer si vous n'en avez pas besoin. N'activez des modules que si vous êtes sûre de les utiliser.
^ nom ^ description ^ activer ^ désactiver ^
^ UserDir | utilisé dans le configuration multi utilisateurs |''sudo a2enmod userdir'' | ''sudo a2dismod userdir'' |
^ rewrite | permet d'utiliser les directives de redirections | ''sudo a2enmod rewrite'' | ''sudo a2dismod rewrite'' |
^ headers | utilisé dans le configuration SSL | ''sudo a2enmod headers'' | ''sudo a2dismod headers'' |
^ ssl | permet d'utiliser le https | ''sudo a2enmod ssl'' | ''sudo a2dismod ssl'' |
^ remoteip | utiliser l'adresse IP du client derrière un proxy | ''sudo a2enmod remoteip'' | ''sudo a2dismod remoteip'' |
L'activation d'un ou plusieurs modules nécessite le redémarrage d'Apache 2 :
<code>
sudo service apache2 restart
</code>
===== Activer http/2 =====
Avec Debian 10, Apache 2.4 est déjà compilé avec l'option http/2. Il suffit de l'activer avec la commande suivante :
<code>
sudo a2enmod http2
</code>
Il faudra privilégier le **PHP FPM**, tel que nous l'abordons dans un prochain chapitre/
Côté exécution Apache 2.4, **mpm_prefork** est incompatible avec **http/2**, il faut lui préférer **mpm_event**
<code>
sudo a2dismod mpm_prefork
sudo systemctl restart apache2
sudo a2enmod mpm_event
sudo systemctl restart apache2
</code>
Afin, dans les **VirtualHost**, il sera nécessaire d'indiquer le protocole http/2
Protocols h2 http/1.1

38
data/pages/informatique/serveur/web-linux-apache/installer-php-fpm.txt Normal file
View File

@@ -0,0 +1,38 @@
====== Installer une version de PHP FPM ======
Voici comment installer l'interpréteur //PHP//. Il peut être appelé en ligne de commande. Avec //Apache 2//, nous utiliserons la version PHP-FPM.
PHP-FPM (FastCGI Process Manager) est une alternative à PHP. C'est une mise en œuvre avec quelques fonctionnalités supplémentaires utiles pour les sites de toute taille, en particulier les sites les plus fréquentés.
Pour **l'installation de PHP**, j'utilise le dépôt de //Ondřej Surý//, dans lequel il y a les dernières versions pour //Debian//. Les processeurs pris en charge sont : ** ARM64**, **ARMhf**, **amd64** et **i386**.
<code BASH>
sudo apt install gnupg
# add key
wget -q http://packages.sury.org/php/apt.gpg -O- | sudo apt-key add -
</code>
<code BASH>
# add into sources.list
sudo echo "deb http://packages.sury.org/php/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/php.list
</code>
La commande suivante installe la dernière version disponible en date pour **php-fpm**.
<code BASH>
sudo apt update
sudo apt install php php-fpm
</code>
Mais nous préférerons installer une version bien précise de **php-fpm**. Ceci afin d'éviter une mise à jour majeure qui bloquerait des scripts.
<code BASH>
sudo apt update
sudo apt install php7.4 php7.4-fpm
</code>
La version actuelle est la version 7.4, ce qui nous permettra de vérifier le fonctionnement de **fpm** :
<code BASH>
sudo systemctl status php7.4-fpm
</code>

104
data/pages/informatique/serveur/web-linux-apache/installer-phpmyadmin.txt Normal file
View File

@@ -0,0 +1,104 @@
====== Installer phpMyAdmin ======
Prérequis :
* PHP 7.4
* Apache 2.4
* MariaDB / MySQL 5.5 et plus
Les modules PHP **mysql**, **zip**, **gd** et **mbstring** sont nécessaires pour une utilisation optimale de l'application.
<code BASH>
sudo apt install php7.4-mysql php7.4-mbstring php-zip php-gd
</code>
Télécharger l'archive présent sur le site ''phpmyadmin.net'' permet d'avoir la dernière version stable en date. A l'heure où j'écris ces lignes, il s'agit de la version 5.0.2.
cd /var/www
wget https://files.phpmyadmin.net/phpMyAdmin/5.0.2/phpMyAdmin-5.0.2-all-languages.tar.gz
sudo tar -xzvf phpMyAdmin-5.0.2-all-languages.tar.gz
sudo rm phpMyAdmin-5.0.2-all-languages.tar.gz
cd phpMyAdmin-5.0.2-all-languages
sudo chgrp -R www-data .
sudo chmod -R g+s .
---
Configuration simple avec le fichier présent dans ``/var/html/phpMyAdmin-5.0.2-all-languages/config.inc.php``
<code PHP>
<?php
// use here a value of your choice at least 32 chars long
$cfg['blowfish_secret'] = '1{dd0`<Q),5XP_:R9UK%%8\"EEcyH#{o';
$i=0;
$i++;
$cfg['Servers'][$i]['auth_type'] = 'cookie';
// if you insist on "root" having no password:
// $cfg['Servers'][$i]['AllowNoPassword'] = true;
</code>
---
configuration site avaible
sudo nano /etc/apache2/sites-available/100-phpmyadmin.conf
<code>
Alias /phpmyadmin /var/www/phpMyAdmin-5.0.2-all-languages
<Directory /var/www/phpMyAdmin-5.0.2-all-languages>
Options Indexes FollowSymLinks
DirectoryIndex index.php
<IfModule mod_php5.c>
AddType application/x-httpd-php .php
php_flag magic_quotes_gpc Off
php_flag track_vars On
php_flag register_globals Off
php_value include_path .
</IfModule>
</Directory>
# Authorize for setup
<Directory /var/www/phpMyAdmin-5.0.2-all-languages/setup>
<IfModule mod_authn_file.c>
AuthType Basic
AuthName "phpMyAdmin Setup"
AuthUserFile /etc/phpmyadmin/htpasswd.setup
</IfModule>
Require valid-user
</Directory>
# Disallow web access to directories that don't need it
<Directory /var/www/phpMyAdmin-5.0.2-all-languages/libraries>
Order Deny,Allow
Deny from All
</Directory>
<Directory /var/www/phpMyAdmin-5.0.2-all-languages/setup/lib>
Order Deny,Allow
Deny from All
</Directory>
</code>
----
Activer la configuration du site
sudo a2ensite 100-phpmyadmin
sudo systemctl reload apache2
---
Code intégral et interactif en cours de rédaction sur [[https://github.com/cedricAbonnel/server-web/scripts/install-phpmyadmin]]

11
data/pages/informatique/serveur/web-linux-apache/installer_piwik.txt Normal file
View File

@@ -0,0 +1,11 @@
====== Installer Piwik ======
Télécharger l'archive dans un dossier temporaire :
<code>
cd /tmp
wget http://builds.piwik.org/piwik.zip
unzip piwik.zip
</code>

74
data/pages/informatique/serveur/web-linux-apache/lamp.txt Normal file
View File

@@ -0,0 +1,74 @@
====== [OBSOLÈTE] Linux Apache MySQL PHP sous Fedora Core 24 ======
<note important>Article OBSOLÈTE\\
Je vous conseille d'installer une solution Web sur un serveur **Debian**. [[informatique:serveur:web-linux-apache:]]</note>
Je vous présente (rapidement) comment installer un serveur Linux Apache MySQL PHP sous **Linux Fedora 24 Desktop**.\\
Toutes les commandes sont a exécuter dans une fenêtre **terminal**.
===== - Installer sous Linux =====
==== - Linux Fedora ====
On commence à par installer **Apache httpd**.
<code bash>
dnf install httpd
</code>
Ajouter des règles dans le firewall:
<code bash>
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo systemctl reload firewalld
</code>
Activer Apache automatiquement :
<code bash>
sudo systemctl enable httpd.service
</code>
Démarrer le service apache :
<code bash>
sudo service httpd start
</code>
On continue avec l'installation du SGBD **MariaDB**.
<code bash>
sudo dnf install mariadb-server
</code>
Démarrage de MariaDB
<code bash>
sudo service mariadb start
</code>
Activer MariaDB automatiquement :
<code bash>
sudo systemctl enable mariadb
</code>
Sécuriser l'installation de MariaDB :
<code bash>
mysql_secure_installation
</code>
Et enfin, on installe l'interpréteur **PHP**
<code bash>
sudo dnf install php-mysql php-gd php-cli php-mbstring php-cli php-fpm
</code>
Activer PHP FPM automatiquement :
<code bash>
sudo systemctl enable php-fpm
</code>
Démarrer le service php-fpm et apache :
<code bash>
sudo service php-fpm start
</code>

24
data/pages/informatique/serveur/web-linux-apache/modifier-la-page-index-apache.txt Normal file
View File

@@ -0,0 +1,24 @@
====== Modifier la page d'accueil standard d'Apache ======
Je propose une **page d'accueil standard du serveur Apache 2** en **PHP** qui permet d'afficher un ensemble d'informations avant de rediriger le visiteur.
<code XML>
<!DOCTYPE html>
<html>
<head>
<title>site non configuré pour <?PHP echo $_SERVER['HTTP_HOST'];?></title>
<meta charset="UTF-8" />
<meta http-equiv="refresh" content="10; url=https://www.abonnel.fr/" />
</head>
<body>
<h1>Serveur trouvé</h1>
<p>Les paramètres ne sont pas configurés pour le site <strong><?PHP echo $_SERVER['HTTP_HOST'];?></strong></p>
<p>Je vous redirige dans 10 secondes vers <a href="https://www.abonnel.fr/">ici</a>.</p>
</body>
</html>
</code>
Je remplace la page ''/var/www/html/index.html'' par ''/var/www/html/index.php''.

477
data/pages/informatique/serveur/web-linux-apache/nextcloud.txt Normal file
View File

@@ -0,0 +1,477 @@
====== NextCloud ======
===== - Installer NextCloud =====
==== - Pré requis ====
Environnement utilisé lors de la rédaction de ce document
* OS : Linux Debian 10
* HTTP : Serveur Apache 2.4
* SGBD : MariaDB
* Langage : PHP 7.4 exécuté en FPM avec Apache
==== - Modules PHP installés ====
<code>
sudo apt install php7.4-fpm php7.4-common
sudo apt install php7.4-gd php7.4-mysql php7.4-curl php7.4-mbstring php7.4-intl
sudo apt install php7.4-gmp php7.4-bcmath php7.4-imagick php7.4-xml php7.4-zip
sudo apt install imagemagick
</code>
==== - Configuration PHP ====
__Mémoire limite__
Dans la configuration par défaut, la valeur **memory_limit** n'est pas indiquée. Ajouter dans le fichier de configuration PHP FPM ''/etc/php/7.4/fpm/conf.d/25-memory.ini''.
<code>
memory_limit = 1G
</code>
==== - Base de données ====
Il faut créer un utilisateur et une base de données.
Dans cette section on définie :
* password_nextcloud : le mot de passe MariaDb ssociée
**Se connecter à mariaDb** :
<code>
mysql -uroot -p
</code>
<code SQL>
USE mysql;
</code>
**Créer la base de données **:
<code SQL>
CREATE DATABASE nextcloud DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
</code>
**Créer le compte de connexion ** et associer les droits sur la base de données :
<code SQL>
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,CREATE TEMPORARY TABLES,DROP,INDEX,ALTER ON nextcloud.* TO 'user_nextcloud'@'localhost' IDENTIFIED BY '${password_nextcloud}';
quit;
</code>
===== - Configurer Apache 2.4 =====
Nous allons ajouter un dossier à notre configuration Web actuelle. L'accès se fera par http://www.abonnel.fr/cloud
Éditer le fichier de configuration Apache ''/etc/apache2/sites-available/100-fr.abonnel.www-cloud.conf''
<code>
Alias /cloud "/var/www/abonnel.fr/cloud/"
<Directory /var/www/abonnel.fr/cloud/>
Require all granted
AllowOverride All
Options +FollowSymLinks +MultiViews
MultiviewsMatch Any
<IfModule mod_dav.c>
Dav off
</IfModule>
</Directory>
</code>
>> Prendre en considération la configuration
<code>
a2ensite 100-fr.abonnel.www-cloud.conf
</code>
>> Activer les modules Apache 2 suivants
<code>
sudo a2enmod rewrite
sudo a2enmod headers
sudo a2enmod env
sudo a2enmod dir
sudo a2enmod mime
</code>
>> Activer la gestion du SSL
<code>
sudo a2enmod ssl
sudo a2ensite default-ssl
</code>
>> Modifier les droits d'accès sur le dossier data
<code>
sudo chown -R www-data:www-data /var/www/abonnel.fr/cloud/
</code>
>> Télécharger le script
Le script est disponible à l'adresse https://nextcloud.com/install/#instructions-server
{{ informatique:applications:nextcloud_download.png |}}
<code>
wget https://download.nextcloud.com/server/releases/nextcloud-18.0.3.tar.bz2
</code>
>> Déployer le script
<code>
sudo tar -xjf nextcloud-18.0.1.tar.bz2 -C /var/www/abonnel.fr/
sudo mv /var/www/abonnel.fr/cloud/nextcloud /var/www/abonnel.fr/cloud
</code>
>> Mettre les bons droits sur le dossiers
<code>
sudo chown -R www-data:www-data /var/www/abonnel.fr/cloud
</code>
>> Redémarrage du service Apache
<code>
service apache2 restart
</code>
>> Se connecter à NextCloud pour terminer le paramétrage
Utiliser l'URL qui permet d'accéder à NextCloud. Par exemple https://abonnel.fr/cloud
Lors du premier appel, le panneau de configuration initiale s'affiche.
==== - Configuration l'antivirus ====
apt-get install clamav clamav-daemon
==== - Configuration Redis et APCu ====
<code>
sudo apt install redis php7.4-redis php7.4-apcu
sudo apt install redis php8.1-redis php8.1-apcu
sudo apt install redis php8.3-redis php8.3-apcu
</code>
Il faut éditer le fichier de configuration NextCloud ''/var/www/abonnel.fr/cloud/config/config.php'' :
<code>
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'memcache.local' => '\OC\Memcache\APCu',
'redis' => array(
'host' => 'localhost',
'port' => 6379,
),
</code>
Il faut associer le groupe ''redis'' au compte ''www-data''
sudo usermod -a -G redis www-data
Puis redémarrer Apache2
sudo systemctl restart apache2
=== Activation de memcache ===
<code>
apt install php7.4-memcache
</code>
Assurez-vous également que le module Memcache est activé dans votre fichier de configuration PHP. Vous devrez peut-être ajouter ou décommenter la ligne suivante dans les fichiers de configuration :
<code>
/etc/php/7.4/mods-available/memcache.ini:extension=memcache.so
/etc/php/8.3/mods-available/memcache.ini:extension=memcache.so
/etc/php/8.1/mods-available/memcache.ini:extension=memcache.so
</code>
<code>
/etc/php/7.4/cli/php.ini:apc.enable_cli=1
/etc/php/7.4/fpm/php.ini:apc.enable_cli=1
/etc/php/8.1/mods-available/apcu.ini:apc.enable_cli=1
/etc/php/8.3/mods-available/apcu.ini:apc.enable_cli=1
</code>
Après avoir apporté des modifications, redémarrez le service PHP-FPM pour prendre en compte les modifications :
<code>
sudo service php7.4-fpm restart
sudo service php8.1-fpm restart
sudo service php8.3-fpm restart
</code>
==== - Les options nextCloud ====
Pour modifier les options il faut éditer le fichier de configuration NextCloud ''/var/www/abonnel.fr/cloud/config/config.php''.
Une fois les modification effectuées, il faut exécuter le script suivant :
<code>
sudo -u www-data php /var/www/abonnel.fr/cloud/occ maintenance:update:htaccess
</code>
> Forcer les connexions en https
<code>
'forcessl' => true,
'forceSSLforSubdomains' => true,
</code>
> Mettre par défaut l'interface en Français et le code pays
<code>
'default_phone_region' => 'FR',
'default_language' => 'fr',
'default_locale' => 'fr_FR',
</code>
> Faire disparaître le index.php de l'URL
<code>
'overwrite.cli.url' => 'https://www.abonnel.fr/cloud',
'htaccess.RewriteBase' => '/cloud',
</code>
> Mise à jour en ligne de commande
<code>
sudo -u www-data php7.4 /var/www/abonnel.fr/cloud/occ upgrade
</code>
> Désactiver le mode maintenance
<code>
sudo -u www-data php7.4 /var/www/abonnel.fr/cloud/occ maintenance:mode --off
</code>
> Mettre à jour toutes les applications
<code>
sudo -u www-data php7.4 /var/www/abonnel.fr/cloud/occ app:update --all
</code>
==== - ajouter une tâche cron pour NextCloud ====
>> Éditer la configuration cron pour www-data
<code>
sudo crontab -u www-data -e
</code>
Dans la configuration, ajouter :
<code>
*/5 * * * * php -f /var/www/abonnel.fr/cloud/cron.php
</code>
==== - configurer fail2ban ====
Créer le fichier ''/etc/fail2banb/filter.d/nextcloud.conf'' qui définie les règles de détection d'erreur d'authentification.
<code>
[Definition]
_groupsre = (?:(?:,?\s*"\w+":(?:"[^"]+"|\w+))*)
failregex = ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Login failed:
^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Trusted domain error.
datepattern = ,?\s*"time"\s*:\s*"%%Y-%%m-%%d[T ]%%H:%%M:%%S(%%z)?"
</code>
Le fichier ''/etc/fail2ban/jail.d/nextcloud.local'' permet de renseigner l'environnement Nextcloud.
<code>
[nextcloud]
backend = auto
enabled = true
port = 80,443
protocol = tcp
filter = nextcloud
maxretry = 3
bantime = 86400
findtime = 43200
logpath = /var/www/abonnel.fr/cloud/data/nextcloud.log
</code>
Redémarrer, vérifier :
<code>
sudo systemctl restart fail2ban
sudo systemctl status fail2ban
sudo fail2ban-client status nextcloud
</code>
==== - configurer mysql ====
Dans le fichier ''/etc/mysql/conf.d/mysql.cnf''
<code>
innodb_buffer_pool_size=1G
innodb_io_capacity=4000
</code>
==== - configurer php ====
Dans un fichier de configuration PHP-FPM, par exemple ''/etc/php/8.0/fpm/conf.d/25-nextcloud.ini''
<code>
memory_limit = 1G
pm = dynamic
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18
opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
</code>
==== - Mettre à jour automatiquement NextCloud ====
>> Éditer la configuration cron pour www-data
<code>
sudo crontab -u www-data -e
</code>
Dans la configuration, ajouter :
<code>
0 3 * * * php /var/www/abonnel.fr/updater/updater.phar --no-interaction
</code>
==== - Mettre à jour automatiquement les applications NextCloud ====
>> Éditer la configuration cron pour www-data
<code>
sudo crontab -u www-data -e
</code>
Dans la configuration, ajouter :
<code>
* 10 */1 * * php -f /var/www/abonnel.fr/cloud/occ app:update --all
</code>
===== - Maintenance suite aux mises à jour =====
==== - Index manquants ====
La base de données a quelques index manquants. L'ajout d'index dans de grandes tables peut prendre un certain temps. Elles ne sont donc pas ajoutées automatiquement. En exécutant ''occ db:add-missing-indices'', ces index manquants pourront être ajoutés manuellement pendant que l'instance continue de tourner. Une fois les index ajoutés, les requêtes sur ces tables sont généralement beaucoup plus rapides.
<code>
sudo -u www-data php7.4 /var/www/abonnel.fr/cloud/occ db:add-missing-indices
</code>
==== - Clés primaires manquantes ====
Il manque des clés primaires dans la base de données. En raison du fait que l’ajout de clés primaires sur les grandes tables peut prendre un certain temps, elles n’ont pas été ajoutées automatiquement. En exécutant ''occ db:add-missing-primary-keys'', ces clés primaires manquantes peuvent être ajoutées manuellement pendant que l’instance continue de fonctionner.
<code>
sudo -u www-data php7.4 /var/www/abonnel.fr/cloud/occ db:add-missing-primary-keys
</code>
==== - Clés primaires manquantes ====
Certaines colonnes facultatives sont manquantes dans la base de données. Étant donné qu'ajouter des colonnes sur des grandes tables peut prendre du temps, elles n'ont pas été ajoutées automatiquement lorsqu'elles sont facultatives. En exécutant ''occ db:add-missing-columns'' ces colonnes manquantes peuvent être ajoutées manuellement alors que l'instance continue de fonctionner. Une fois que les colonnes sont ajoutées, la performance ou l'utilisabilité de certaines fonctionnalités pourraient être améliorées.
<code>
sudo -u www-data php7.4 /var/www/abonnel.fr/cloud/occ db:add-missing-columns
</code>
==== - Clés primaires manquantes ====
Certaines colonnes de la base de données n'ont pas été converties en **big int**. Changer le type de colonne dans de grandes tables peu prendre beaucoup de temps, elles n'ont donc pas été converties automatiquement. En exécutant ''occ db:convert-filecache-bigint'' ces changements en suspens peuvent être déclenchés manuellement. Cette opération doit être exécutée pendant que l'instance est hors ligne.
<code>
sudo -u www-data php7.4 /var/www/abonnel.fr/cloud/occ maintenance:mode --on
sudo -u www-data php7.4 /var/www/abonnel.fr/cloud/occ db:convert-filecache-bigint
sudo -u www-data php7.4 /var/www/abonnel.fr/cloud/occ maintenance:mode --off
</code>
===== - Quelques trucs et astuces =====
==== - Utilisateur désactivé ====
Activer un utilisateur qui a été désactivé :
sudo -u www-data php occ user:enable [username]
==== - Import d'un VCard en erreur ====
Convertir un fichier **vcard 2.1** en **vcard 3.0** pour l'importer dans NextCloud :
https://github.com/jowave/vcard2to3
<code>
git clone https://github.com/jowave/vcard2to3.git
cd vcard2to3
./vcard2to3.py your_file.vcf
</code>
==== - Contacts / CardDAV ====
**Nextcloud** propose un backend **CardDAV** pour que les utilisateurs puissent stocker et partager leurs carnets d'adresses et leurs contacts.
=== Carnet d'adresses système ===
**Modifié dans la version 27 : Le carnet d'adresses système est désormais accessible à tous les utilisateurs de Nextcloud.**
Nextcloud maintient un carnet d'adresses en lecture seule contenant les informations de contact de tous les utilisateurs de l'instance.
Les utilisateurs désactivés sont supprimés de ce carnet d'adresses.
Vous pouvez désactiver l'accès au carnet d'adresses système en utilisant la valeur de configuration de l'application ''system_addressbook_expose''.
Exécutez la commande ''occ config:app:set dav system_addressbook_exposed --value="no"'' pour désactiver l'accès au carnet d'adresses système pour tous les utilisateurs. Veuillez noter que cela n'influence pas le partage fédéré.
=== Avertissement ===
Si des clients se sont déjà connectés au point de terminaison CalDAV, les clients peuvent rencontrer des problèmes de synchronisation après la désactivation de l'accès au carnet d'adresses système. Cela peut souvent être résolu en choisissant un carnet d'adresses par défaut différent sur le client et en forçant une nouvelle synchronisation.
=== Confidentialité et étendue des propriétés de l'utilisateur ===
Les informations de contact dans le carnet d'adresses système sont extraites des informations de profil des utilisateurs. Les propriétés de profil ne sont écrites dans le carnet de contacts système que si l'étendue est définie sur "Local" ou plus élevé.
Les utilisateurs qui définissent toutes leurs étendues de propriétés sur "Privé" sont supprimés du carnet d'adresses système et ne sont donc pas visibles par les autres utilisateurs.
Les paramètres de partage de fichiers contrôlent l'énumération des autres utilisateurs.
- Si l'autocomplétion du nom d'utilisateur n'est pas autorisée, le carnet d'adresses système ne montrera que le contact système de l'utilisateur mais pas d'autres contacts.
- Si l'autocomplétion du nom d'utilisateur est autorisée, les utilisateurs verront les cartes de contact de tous les autres utilisateurs.
- Si l'autocomplétion est limitée aux utilisateurs au sein des mêmes groupes, les utilisateurs verront les cartes de contact d'autres utilisateurs dans les groupes partagés.
- Si l'autocomplétion est limitée aux numéros de téléphone correspondants, le carnet d'adresses système ne montrera que le contact système de l'utilisateur mais pas d'autres contacts.
- Si l'autocomplétion est limitée aux utilisateurs au sein des mêmes groupes et aux numéros de téléphone correspondants, les utilisateurs verront les cartes de contact d'autres utilisateurs dans les groupes partagés.
=== Synchronisation du carnet d'adresses ===
Le carnet d'adresses est mis à jour automatiquement à chaque ajout, modification, désactivation ou suppression d'utilisateur. Les administrateurs peuvent également déclencher une réécriture complète du carnet d'adresses avec ''occ''.

14
data/pages/informatique/serveur/web-linux-apache/php-installer-un-second-moteur.txt Normal file
View File

@@ -0,0 +1,14 @@
====== Installer une seconde version de PHP ======
Cet article décrit comment installer une autre version de PHP sur votre système.
<code BASH>
sudo apt update
sudo apt install php5.6 php5.6-fpm
</code>
Nous vérifions le fonctionnement de **fpm** :
<code BASH>
sudo systemctl status php5.6-fpm
</code>

19
data/pages/informatique/serveur/web-linux-apache/preparer-le-serveur-linux.txt Normal file
View File

@@ -0,0 +1,19 @@
====== Préparer son serveur Web ======
{{ informatique:applications:server-311338_1280.png?400|}}
Je vous propose une solution pour préparer votre serveur fonctionnant sour Debian 10. Je vous donne quelques conseils pour le sécuriser.
{{page>informatique:linux:commandes:adduser#creer-un-utilisateur}}
{{page>informatique:linux:commandes:sudo#ajouter-le-groupe-sudo-a-un-utilisateur}}
{{page>informatique:linux:changer-le-nom-de-machine}}
{{page>informatique:linux:commandes:ssh#copier-votre-cle-publique-sur-un-poste-distant}}
{{page>informatique:bash:creer_aliases}}
{{page>informatique:divers:apt-get_upgrade}}
{{page>informatique:logiciels:fail2ban}}

1
data/pages/informatique/serveur/web-linux-apache/reinitialiser-le-mot-de-passe-root-mysql.txt Normal file
View File

@@ -0,0 +1 @@
{{page>informatique:logiciels:mariadb:maintenance:reinitialiser-le-mot-de-passe-root}}

5
data/pages/informatique/serveur/web-linux-apache/sidebar.txt Normal file
View File

@@ -0,0 +1,5 @@
{{ informatique:serveur:web-linux-apache:pasted:20201225-185814.png|Serveur Web Linux Apache}}
<WRAP clear/>
{{page>..:web-linux-apache:index#table-des-matieres}}
~~NOCACHE~~

155
data/pages/informatique/serveur/web-linux-apache/ssl-let-s-encrypt-certbot.txt Normal file
View File

@@ -0,0 +1,155 @@
====== certbot pour Let's Encrypt ======
{{ informatique:applications:pasted:20200507-002818.png?75x75|cerbot pour let's encrypt}}
**Certbot** est un binaire qui permet de mettre en œuvre un certificat SSL pour un domaine d'un site Internet.
Voici les actions a effectuer sur **Linux** **Debian 10**.
Depuis 2020, **certbot** est installé depuis **snapcraft**.
===== - Installer snap =====
Si vous n'avez pas encore installé **snap**, il faut executer les commandes suivantes dans un **terminal**. Les commandes doivent avoir une élevation des droits.
sudo apt update
sudo apt install snapd
sudo snap install core
Si **snap** est déjà installé, assurez-vous d'être à jour :
sudo snap refresh core
===== - Installer certbot =====
Exécutez la commande suivante oour installer **cerbot** sur votre machine. Ceci est a exéctuer dans un terminal.
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
===== - Générer un certificat - gestion manuelle =====
Si vous suivez ce guide, je vous conseille une gestion manuelle de vos certificats.
Il y a deux variables :
^ dirWeb | Dossier des données du site. Pour habitude, c'est quelque chose du genre ''/var/www/html/'' |
^ siteName | Nom du site Internet. Par exemple ''abonnel.fr'' |
<code BASH>
read -p "Quel est votre nom de domaine ? " siteName
read -p "Dossier Web du site ? " dirWeb
sudo certbot certonly --webroot -w $dirWeb -d $siteName --register-unsafely-without-email
</code>
L'avantage de ce script :
* pas d'arrêt d'Apache 2
* pas de mail à saisir
* autonomie sur la configuration Apache 2
Quelques **chemins** à retenir :
^ fichier de configuration | /etc/letsencrypt/renewal/$siteName.conf |
^ dossier archive | /etc/letsencrypt/archive/$siteName |
^ fichier cert | /etc/letsencrypt/live/$siteName/cert.pem |
^ fichier privkey | /etc/letsencrypt/live/$siteName/privkey.pem |
^ fichier chain | /etc/letsencrypt/live/$siteName/chain.pem |
^ fichier fullchain | /etc/letsencrypt/live/$siteName/fullchain.pem |
Pour enregistrer un domaine principal avec et sans les **www**, il faut utiliser le script suivant :
<code BASH>
echo "Quel nom de domaine (avec www) ?"
read siteNameWww
echo "Quel nom de domaine (sans les www) ?"
read siteName
sudo certbot certonly --webroot -w /var/www/html/ -d $siteName -d $siteNameWww --register-unsafely-without-email
</code>
===== - Générer un certificat - gestion automatique =====
Si vous avez effectué le paragraphe précédent [[#generer-un-certificat-gestion-manuelle]], il est inutile de suivre les recommandations de ce chapitre.
Exécutez le commande suivant pour générer un certificat et édité votre configuration Apache de manière automatique. Le protocole **https** s'active de manière automatique, en une seule étape.
sudo certbot --apache
===== - Renouveler les certificats automatiquement =====
Éditer la tâche des tâches Linux du compte ''root'', //crontab// :
<code>
sudo crontab -e
</code>
La tâche doit exécutée le programme ''certbot'' avec l'option de renouvellement, ''renew''. L'option ''post-hook'' permet d'indiquer la commande à exécuter après le traitement de ''certbot''. Dans notre cas, on demande à ''systemctl'' de recharger la configuration ''Apache 2''.
<code>
0 23 1-7 */2 4 python -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/bin/certbot renew --post-hook "systemctl reload apache2" >> /var/log/letsencrypt/renew.log
</code>
Explications :
<html><pre>
Tous les deux mois ( 0 23 1-7 <strong>*/2</strong> 4 )
à 23 heures ( <strong>0 23</strong> 1-7 */2 4 ),
le premier jeudi ( 0 0 <strong>1-7</strong> */2 <strong>4</strong> ),
lancement d'un script Python, qui retarde 1 heure au maximum (random.random() * 3600),
l’exécution de la mise à jour de certbot.
</pre></html>
Vous pouvez trouver d'autres informations sur la page [[https://crontab.guru/#0_23_1-7_*/2_4]]
===== - Afficher les dates du certificats =====
Pour afficher les dates de génération et d'expiration d'un certificat en local sur un serveur :
<code>
sudo ls /etc/letsencrypt/live/
read -p "Quel est votre nom de domaine ?" siteName
sudo openssl x509 -noout -dates -in /etc/letsencrypt/live/$siteName/fullchain.pem
</code>
---
Pour afficher les dates de génération et d'expiration d'un certificat d'un site distant :
<code>
openssl s_client -connect www.w3.org:443| openssl x509 -noout -dates
</code>
Exemple de résultat :
{{informatique:serveur:web-linux-apache:pasted:20210117-213056.png|Exemple de résultat pour les dates du certificat de www.w3.org}}
===== - Réinitialiser la configuration Let's Encrypt =====
Façon documentée :
<code BASH>
echo Affichage des noms possibles :
sudo ls /etc/letsencrypt/live
echo .
echo "Quel nom de domaine ?"
read siteName
certbot delete --cert-name $siteName
</code>
Façon brutale :
<code BASH letsencrypt_erase>
#!/bin/bash
# réinitialiser let's encrypt pour un domaine precis
echo Affichage des noms possibles :
sudo ls /etc/letsencrypt/live
echo .
echo "Quel nom de domaine ?"
read siteName
sudo rm -fr /etc/letsencrypt/live/$siteName/
sudo rm /etc/letsencrypt/renewal/$siteName.conf
sudo rm -fr /etc/letsencrypt/archive/$siteName/
</code>

137
data/pages/informatique/serveur/web-linux-apache/ssl-let-s_encrypt-certbot-auto.txt Normal file
View File

@@ -0,0 +1,137 @@
====== [OBSOLÈTE] certbot auto pour Let's Encrypt ======
{{ informatique:applications:pasted:20200507-002818.png?75x75|cerbot pour let's encrypt}}
<WRAP center round important 60%>
Depuis 2020, l'installation s'effectue depuis **certbot** avec **snap**
Suivez le guide dans l'article [[informatique:serveur:web-linux-apache:ssl-let-s-encrypt-certbot]]
</WRAP>
**Certbot** est un binaire qui permet de mettre en œuvre un certificat SSL pour un domaine d'un site Internet. **Certbot-auto** est une solution complète qui permet d’exécuter //Certbot// de manière optimale.
===== - Télécharger CERTBOT =====
En terminal, j’exécute ''wget''
<code>
wget https://dl.eff.org/certbot-auto
</code>
===== - Déployer CERTBOT =====
<code>
sudo mv certbot-auto /usr/local/bin/certbot-auto
sudo chown root /usr/local/bin/certbot-auto
sudo chmod 0755 /usr/local/bin/certbot-auto
/usr/local/bin/certbot-auto --install-only
</code>
===== - Application CERTBOT pour un domaine =====
Exécution de l'utilitaire pour configurer un site avec les options suivantes :
<code>
read -p "Quel est votre nom de domaine ? " siteName
read -p "Dossier Web du site ? " dirWeb
sudo certbot-auto certonly --webroot -w $dirWeb -d $siteName --register-unsafely-without-email
</code>
L'avantage de ce script :
* pas d'arrêt d'Apache 2
* pas de mail à saisir
* autonomie sur la configuration Apache 2
Quelques **chemins** à retenir :
^ fichier de configuration | /etc/letsencrypt/renewal/$siteName.conf |
^ dossier archive | /etc/letsencrypt/archive/$siteName |
^ fichier cert | /etc/letsencrypt/live/$siteName/cert.pem |
^ fichier privkey | /etc/letsencrypt/live/$siteName/privkey.pem |
^ fichier chain | /etc/letsencrypt/live/$siteName/chain.pem |
^ fichier fullchain | /etc/letsencrypt/live/$siteName/fullchain.pem |
===== - Application CERTBOT pour un domaine principal =====
Exécution de l'utilitaire pour configurer un domaine principal. Un domaine principal est accessible avec les //www// et sans :
<code>
echo "Quel nom de domaine (avec www) ?"
read siteNameWww
echo "Quel nom de domaine (sans les www) ?"
read siteName
certbot-auto certonly --webroot -w /var/www/html/ -d $siteNameWww -d $siteName --register-unsafely-without-email
</code>
L'avantage de ce script :
* pas d'arrêt d'Apache 2
* pas de mail à saisir
* autonomie sur la configuration Apache 2
Quelques **chemins** à retenir :
^ fichier de configuration | /etc/letsencrypt/renewal/$siteNameWww.conf |
^ dossier archive | /etc/letsencrypt/archive/$siteNameWww |
^ fichier cert | /etc/letsencrypt/live/$siteNameWww/cert.pem |
^ fichier privkey | /etc/letsencrypt/live/$siteNameWww/privkey.pem |
^ fichier chain | /etc/letsencrypt/live/$siteNameWww/chain.pem |
^ fichier fullchain | /etc/letsencrypt/live/$siteNameWww/fullchain.pem |
===== - Renouveler les certificats =====
Il suffit d’exécuter la commande :
<code>
$ sudo certbot-auto renew
</code>
Les paramètres ''cerbot'' sont automatiquement traités et une mise à jour des certificats sont opérés.
Il faudra redémarrer le service Web (par exemple ''systemctl reload apache2'').
===== - Renouveler les certificats automatiquement =====
Éditer la tâche des tâches Linux du compte ''root'', //crontab// :
<code>
sudo crontab -e
</code>
La tâche doit exécutée le programme ''certbot-auto'' avec l'option de renouvellement, ''renew''. L'option ''post-hook'' permet d'indiquer la commande à exécuter après le traitement de ''certbot-auto''. Dans notre cas, on demande à ''systemctl'' de recharger la configuration ''Apache 2''.
<code>
0 23 1-7 */2 4 python -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/certbot-auto renew --post-hook "systemctl reload apache2" >> /var/log/letsencrypt/renew.log
</code>
Explications :
<html><pre>
Tous les deux mois ( 0 23 1-7 <strong>*/2</strong> 4 )
à 23 heures ( <strong>0 23</strong> 1-7 */2 4 ),
le premier jeudi ( 0 0 <strong>1-7</strong> */2 <strong>4</strong> ),
lancement d'un script Python, qui retarde 1 heure au maximum (random.random() * 3600),
l’exécution de la mise à jour de certbot.
</pre></html>
===== - Afficher les dates du certificats =====
<code>
sudo ls /etc/letsencrypt/live/
read -p "Quel est votre nom de domaine ?" siteName
sudo openssl x509 -noout -dates -in /etc/letsencrypt/live/$siteName/fullchain.pem
</code>
===== - Réinitialiser la configuration Let's Encrypt =====
<code BASH letsencrypt_erase>
#!/bin/bash
# réinitialiser let's encrypt pour un domaine precis
echo Affichage des noms possibles :
sudo ls /etc/letsencrypt/live
echo .
echo "Quel nom de domaine ?"
read siteName
sudo rm -fr /etc/letsencrypt/live/$siteName/
sudo rm /etc/letsencrypt/renewal/$siteName.conf
sudo rm -fr /etc/letsencrypt/archive/$siteName/
</code>

27
data/pages/informatique/serveur/web-linux-apache/wordpress.txt Normal file
View File

@@ -0,0 +1,27 @@
====== WordPress ======
===== - Installer =====
Dans un premier temps, il faut suivre le guide pas à pas pour [[informatique:applications:configurer_un_site_web_apache_2:index|installer Apache2 avec PHP et MySQL]].
Ensuite, vient le téléchargement de l'application depuis le site **Wordpress**. J'utilise la commande ''wget'' pour télécharger l'archive directement sur le serveur Web.
<code BASH>
$ wget https://fr.wordpress.org/latest-fr_FR.tar.gz
</code>
Le programme est contenu dans une archive compressée **tar.gz**. Donc, il faut décompresser l’archive .
<code BASH>
$ tar -xzvf latest-fr_FR.tar.gz
$ rm latest-fr_FR.tar.gz
$ mv wordpress/* .
$ rmdir wordpress
</code>
Voici quelques ressources qui peuvent aider :
* https://serverfault.com/questions/357108/what-permissions-should-my-website-files-folders-have-on-a-linux-webserver
* https://codex.wordpress.org/Installing_WordPress#Detailed_Instructions
* https://doc.ubuntu-fr.org/installer_un_serveur_debian
* http://olange.developpez.com/articles/debian/installation-serveur-dedie/?page=page_2

45
data/pages/informatique/serveur/web-linux-apache/www-data-droits.txt Normal file
View File

@@ -0,0 +1,45 @@
====== Configurer les droits des fichiers ======
{{ :dummy.png?75x75|Configurer les droits des fichiers}}
Je vous propose un suite de commandes afin de rendre votre utilisateur actif, symbolisé par **${USER}**, utilisateur avec pouvoir du dossier **/var/www/html**.
Le dossier **/var/www/html** est le dossier par défaut sous **Debian** de votre service **Apache**.
Le groupe **www-data** est le groupe par défaut utilisé par **Apache** pour accéder aux ressources et exécuter ses services.
--
**Ajouter le groupe** **www-data** à l'**utilisateur courant**
sudo usermod -a -G www-data ${USER}
Vous pourrez vérifier l'affectation en saisissant la commande ''id ${USER}''
--
**Définir l'utilisateur** en tant que propriétaire du dossier **/var/www/html**
sudo chown -R ${USER}:www-data /var/www/html
--
**Autoriser les accès** uniquement à l'utilisateur et au groupe **www-data**
sudo chmod 770 -R /var/www/html
find /var/www/html -type f -exec sudo chmod gu-x {} +
--
**Reprendre le groupe** à la création des nouveaux objets
find /var/www/html -type d -exec sudo chmod g+s {} +
--
**Bloquer les autorisations** pour **other** et forcer **rw** pour le groupe **www-data**
La commande suivante peut nécessiter le déploiement du programme **acl** : ''sudo apt install acl''.
setfacl -m d:g:www-data:rw,d:o::- /var/www/html