Add oldiers translations from obsd4a
HUC Stéphane
parent
6623954a78
commit
9c0a93fc3f
GPG Key ID:
C4ED64222D9B037F
|
|
@ -0,0 +1,303 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2020-08-25T13:40:59+02:00
|
||||
description: "Traduction EN → FR de l'article 'How to build a name server with DNS over TLS (DoT)' de l'auteur Bruno Flückiger."
|
||||
draft: false
|
||||
include_toc: true
|
||||
show_comments: false
|
||||
tags: ['Traduction','OpenBSD','DNS','DoT']
|
||||
title: "Comment créer un serveur de noms avec DNS-over-TLS (DoT)"
|
||||
translationKey: ''
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Retrouvez ci-dessous la traduction EN → FR de l'article "**[How to build a name server with DNS over TLS (DoT)][1]**",
|
||||
écrit par Bruno Flückiger.
|
||||
|
||||
---
|
||||
|
||||
Date : 2020-08-25
|
||||
|
||||
## Introduction
|
||||
|
||||
Cet article est en rapport avec la configuration de [nsd(8)](https://man.openbsd.org/nsd)
|
||||
en tant que serveur de noms public pour votre propre domaine, fournissant
|
||||
DNS-over-TLS (DOT). Tout ce qui faut pour cette tâche est inclus dans
|
||||
l'installation de base d'OpenBSD. Vous n'avez besoin d'installer aucun
|
||||
paquet additionnel pour cela.
|
||||
|
||||
## Certificats
|
||||
|
||||
Tout fournisseur de certificats qui supporte le protocole [ACME](https://tools.ietf.org/html/rfc8555)
|
||||
peut être utilisé. Personnellement, j'utilise le plus populaire
|
||||
actuellement : [Let's Encrypt](https://letsencrypt.org/).
|
||||
|
||||
Les challenges reçus du fournisseur de certificats seront utilisés par
|
||||
[httpd(8)](https://man.openbsd.org/httpd) en configurant `/etc/httpd.conf`,
|
||||
similaire à ceci :
|
||||
|
||||
```cfg
|
||||
server "ns1.example.net" {
|
||||
listen on egress port http
|
||||
root "/"
|
||||
location "/.well-known/acme-challenge/*" {
|
||||
request strip 2
|
||||
root "/acme"
|
||||
}
|
||||
}
|
||||
|
||||
types {
|
||||
include "/usr/share/misc/mime.types"
|
||||
}
|
||||
```
|
||||
|
||||
Testez votre configuration, puis activez et démarrez httpd(8) :
|
||||
|
||||
```sh
|
||||
$ doas httpd -n
|
||||
$ doas rcctl enable httpd
|
||||
$ doas rcctl start httpd
|
||||
```
|
||||
|
||||
L'étape suivante est de configurer acme-client(1). Je vous suggère
|
||||
d'utiliser `/etc/examples/acme-client.conf` en tant que source à
|
||||
sauvegarder puis à modifier conséquemment. Le fichier `acme-client.conf`
|
||||
résultant devrait être sauvegardé dans `/etc` et ressemblait à :
|
||||
|
||||
```cfg
|
||||
authority letsencrypt {
|
||||
api url "https://acme-v02.api.letsencrypt.org/directory"
|
||||
account key "/etc/acme/letsencrypt-privkey.pem"
|
||||
}
|
||||
|
||||
authority letsencrypt-staging {
|
||||
api url "https://acme-staging.api.letsencrypt.org/directory"
|
||||
account key "/etc/acme/letsencrypt-staging-privkey.pem"
|
||||
}
|
||||
|
||||
domain ns1.bsdhowto.ch {
|
||||
domain key "/etc/ssl/acme/private/ns1.bsdhowto.ch.key"
|
||||
domain certificate "/etc/ssl/acme/ns1.bsdhowto.ch.crt"
|
||||
domain full chain certificate "/etc/ssl/acme/ns1.bsdhowto.ch.fullchain.pem"
|
||||
sign with letsencrypt
|
||||
}
|
||||
```
|
||||
|
||||
Avant d'avoir votre certificat, vous devriez vous assurer que
|
||||
[pf(4)](https://man.openbsd.org/pf) laisse passer les requêtes vers
|
||||
[httpd(8)](https://man.openbsd.org/pf.conf). Ajoutez une règle similaire
|
||||
à la suivante dans votre fichier pf.conf(5) :
|
||||
|
||||
`pass in on egress proto tcp from any to egress port http`
|
||||
|
||||
Vérifiez la configuration dans `/etc/pf.conf` puis chargez-la dans pf(4)
|
||||
en utilisant les commandes suivantes :
|
||||
|
||||
```sh
|
||||
$ doas pfctl -nf /etc/pf.conf
|
||||
$ doas pfctl -f /etc/pf.conf
|
||||
```
|
||||
|
||||
Maintenant vous êtes prêt à récupérer le certificat pour nsd(8).
|
||||
N'oubliez pas de créer le fichier OCSP aussi :
|
||||
|
||||
```sh
|
||||
$ dest=/etc/ssl/ns1.example.net
|
||||
$ doas acme-client ns1.example.net
|
||||
$ doas ocspcheck -No ${dest}.ocsp ${dest}.fullchain.pem
|
||||
```
|
||||
|
||||
Vous devez vous assurer que le certificat soit valide, de même pour la
|
||||
réponse OCSP, et qu'ils soient renouvelés avant leurs expirations. Je
|
||||
vous suggère d'ajouter quelque chose comme ceci dans `/etc/daily.local` :
|
||||
|
||||
```sh
|
||||
#!/bin/sh
|
||||
|
||||
dest=/etc/ssl/ns1.example.net
|
||||
|
||||
acme-client ns1.example.net
|
||||
if [ $? -eq 0 ] ; then
|
||||
ocspcheck -No ${dest}.ocsp ${dest}.fullchain.pem
|
||||
rcctl restart nsd
|
||||
fi
|
||||
|
||||
oscpcheck -i ${dest}.ocsp ${dest}.fullchain.pem
|
||||
if [ $? -eq 1 ] ; then
|
||||
ocspcheck -No ${dest}.ocsp ${dest}.fullchain.pem
|
||||
rcctl restart nsd
|
||||
fi
|
||||
```
|
||||
|
||||
Le script vérifie en premier le certificat. S'il a été renouvelé , il
|
||||
récupère la réponse OCSP pour le nouveau certificat et redémarre nsd(8)
|
||||
afin de charger les nouveaux fichiers. À la seconde étape, le script
|
||||
vérifie si la réponse OCSP a expirée. Si c'est le cas, il récupère une
|
||||
nouvelle réponse OCSP et redémarre nsd(8) afin de charger la nouvelle
|
||||
réponse OCSP.
|
||||
|
||||
## Configuration de nsd(8)
|
||||
|
||||
La configuration correcte de nsd(8) dépend du rôle de votre serveur :
|
||||
primaire ou secondaire. La plupart des fournisseurs de domaines
|
||||
requièrent que vous exécutiez au moins deux serveurs de noms, de
|
||||
préférence dans deux différents sous-réseaux. Je vous montre la
|
||||
configuration des deux.
|
||||
|
||||
Voici la première pour le primaire :
|
||||
|
||||
```cfg
|
||||
server:
|
||||
hide-identity: yes
|
||||
hide-version: yes
|
||||
ip-address: 192.0.2.11
|
||||
ip-address: 192.0.2.11@853
|
||||
ip-address: 2001:db8:1::c000:020b
|
||||
ip-address: 2001:db8:1::c000:020b@853
|
||||
server-count: 1
|
||||
statistics: 86400
|
||||
tls-service-key: "/etc/ssl/ns1.example.net.key"
|
||||
tls-service-pem: "/etc/ssl/ns1.example.net.fullchain.pem"
|
||||
tls-service-ocsp: "/etc/ssl/ns1.example.net.ocsp"
|
||||
|
||||
remote-control:
|
||||
control-enable: yes
|
||||
|
||||
key:
|
||||
name: nskey.example.net
|
||||
algorithm: sha256
|
||||
secret: "IAmASecretKeyForDomainTransfers"
|
||||
|
||||
zone:
|
||||
name: "example.net"
|
||||
zonefile: "/var/nsd/zones/master/%s.dns"
|
||||
notify: 198.51.100.12 nskey.example.net
|
||||
notify: 2001:db8:2::c633:640c nskey.example.net
|
||||
provide-xfr: 198.51.100.12 nskey.example.net
|
||||
provide-xfr: 2001:db8:2::c633:640c nskey.example.net
|
||||
outgoing-interface: 192.0.2.11
|
||||
outgoing-interface: 2001:db8:1::c000:020b
|
||||
```
|
||||
|
||||
Assurez vous que le serveur primaire et le secondaire utilise la même
|
||||
clé secrète pour le transfert de domaines, autrement cela ne fonctionnera
|
||||
pas. Vous pouvez générer le secret pour la clé de transfert de domaine
|
||||
en utilisant la commande suivante :
|
||||
|
||||
```sh
|
||||
$ for i in $(jot -r -s " " 32 0 255) ; do
|
||||
> echo ${i} | awk '{ printf "%c", $1 }'
|
||||
> done | sha256 -b
|
||||
```
|
||||
|
||||
La prochaine étape est de s'assurer que le fichier de votre zone contient
|
||||
certaines données valides. Soit vous avez déjà un fichier de zone valide,
|
||||
soit vous pouvez utiliser celui qui suit en tant que point de départ :
|
||||
|
||||
```cfg
|
||||
$ORIGIN .
|
||||
$TTL 3600 ; 1 hour
|
||||
example.net IN SOA ns1.example.net. hostmaster.example.net. (
|
||||
1 ; serial
|
||||
10800 ; refresh (3 hours)
|
||||
600 ; retry (10 minutes)
|
||||
241900 ; expire (4 weeks)
|
||||
3600 ; minimum (1 hour)
|
||||
)
|
||||
NS ns1.example.net.
|
||||
NS ns2.example.net.
|
||||
$ORIGIN example.net.
|
||||
ns1 A 192.0.2.11
|
||||
AAAA 2001:db8:1::c000:020b
|
||||
ns2 A 198.51.100.12
|
||||
AAAA 2001:db8:2::c633:640c
|
||||
```
|
||||
|
||||
La configuration du second serveur a besoin d'autres options légèrement
|
||||
différentes pour en faire un serveur secondaire, mais elle ressemble à
|
||||
celle du serveur primaire :
|
||||
|
||||
```cfg
|
||||
server:
|
||||
hide-identity: yes
|
||||
hide-version: yes
|
||||
ip-address: 198.51.100.12
|
||||
ip-address: 198.51.100.12@853
|
||||
ip-address: 2001:db8:2::c633:640c
|
||||
ip-address: 2001:db8:2::c633:640c@853
|
||||
server-count: 1
|
||||
statistics: 86400
|
||||
tls-service-key: "/etc/ssl/ns2.example.net.key"
|
||||
tls-service-pem: "/etc/ssl/ns2.example.net.fullchain.pem"
|
||||
tls-service-ocsp: "/etc/ssl/ns2.example.net.ocsp"
|
||||
|
||||
remote-control:
|
||||
control-enable: yes
|
||||
|
||||
key:
|
||||
name: nskey.example.net
|
||||
algorithm: sha256
|
||||
secret: "IAmASecretKeyForDomainTransfers"
|
||||
|
||||
zone:
|
||||
name: "example.net"
|
||||
zonefile: "/var/nsd/zones/slave/%s.dns"
|
||||
allow-notify: 192.0.2.11 nskey.example.net
|
||||
allow-notify: 2001:db8:1::c000:020b nskey.example.net
|
||||
request-xfr: 192.0.2.11 nskey.example.net
|
||||
request-xfr: 2001:db8:1::c000:020b nskey.example.net
|
||||
outgoing-interface: 198.51.100.12
|
||||
outgoing-interface: 2001:db8:2::c633:640c
|
||||
```
|
||||
|
||||
Sur les deux serveurs, vous devez exécuter la commande suivant pour
|
||||
prendre le contrôle à distance pour que l'utilisation de nsd-control(8)
|
||||
fonctionne :
|
||||
`$ doas nsd-control-setup`
|
||||
|
||||
Maintenant, il faut vérifier votre configuration. Exécutez la commande
|
||||
suivante sur chacun des serveurs afin de trouver des erreurs de
|
||||
typographie :
|
||||
`$ doas nsd-checkconf /var/nsd/etc/nsd.conf`
|
||||
|
||||
Si tout semble bon, vous êtes prêt pour activer et démarrer nsd(8) sur
|
||||
les deux serveurs :
|
||||
```sh
|
||||
$ doas rcctl enable nsd
|
||||
$ doas rcctl start nsd
|
||||
```
|
||||
|
||||
La dernière pièce du puzzle sont les règles pour pf(4) afin d'autoriser
|
||||
l'accès externe à nsd(8). Ajoutez ces deux lignes à `/etc/pf.conf` :
|
||||
|
||||
```cfg
|
||||
pass in on egress proto { tcp udp } from any to egress port domain
|
||||
pass in on egress proto { tcp udp } from any to egress port domain-s
|
||||
```
|
||||
|
||||
Vérifiez puis chargez la configuration changée :
|
||||
|
||||
```sh
|
||||
$ doas pfctl -nf /etc/pf.conf
|
||||
$ doas pfctl -f /etc/pf.conf
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Remerciements
|
||||
|
||||
Avec l'aimable autorisation de Bruno Flückiger !
|
||||
|
||||
*Cette page est la traduction de la page **[How to build a name server with DNS over TLS (DoT)][1]** du site **BSDHowto.ch**.*
|
||||
|
||||
---
|
||||
|
||||
## Historique
|
||||
|
||||
J'ai écrit historiquement cette traduction sur le wiki de la communauté
|
||||
"OpenBSD Pour Tous".
|
||||
|
||||
---
|
||||
|
||||
[1]: https://www.bsdhowto.ch/externaldns.html
|
||||
|
|
@ -0,0 +1,186 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2020-08-29T15:04:08+02:00
|
||||
description: "Traduction EN → FR de l'article 'How to build a malware scan server' de l'auteur Bruno Flückiger."
|
||||
draft: false
|
||||
include_toc: true
|
||||
show_comments: false
|
||||
tags: ['Traduction','OpenBSD','malware']
|
||||
title: "Comment construire un serveur de scan de malware"
|
||||
translationKey: ''
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Retrouvez ci-dessous la traduction EN → FR de l'article "**[How to build a malware scan server][1]**",
|
||||
écrit par Bruno Flückiger.
|
||||
|
||||
---
|
||||
|
||||
Date : 2020-05-16
|
||||
|
||||
## Introduction
|
||||
|
||||
Récemment, j'ai eu la tâche de construire, au travail, un serveur de
|
||||
scan de malware supportant [ICAP](https://tools.ietf.org/html/rfc3507).
|
||||
Actuellement, nous utilisons RedHat Enterprise Linux. Mais
|
||||
[c-icap](http://c-icap.sourceforge.net/) n'est pas disponible en tant
|
||||
que paquet dans un des dépôts de confiance, alors j'ai décidé d'utiliser
|
||||
[OpenBSD](https://www.openbsd.org/) pour cette tâche.
|
||||
|
||||
Le serveur de scan de malware utilise [ClamAV](https://www.clamav.net/)
|
||||
en tant que scanner de malware et c-icap en tant que serveur ICAP,
|
||||
fournissant une interface pour chaque produit qui supporte ICAP tel
|
||||
[Squid](http://www.squid-cache.org/).
|
||||
|
||||
## Installation des paquets
|
||||
|
||||
C'est une tâche très simple, un seul paquet s'occupe de tout :
|
||||
`$ doas pkg_add -i c-icap-clamav`
|
||||
|
||||
Ce paquet contient le module c-icap pour ClamAV qui installe c-icap et
|
||||
clamav en dépendances.
|
||||
|
||||
## Configuration de ClamAV
|
||||
|
||||
Deux des trois démons installés par ClamAv sont d'intérêt : freshclam et
|
||||
clamd. En premier, configurez freshclam afin de vous assurer que la base
|
||||
de données des malware de ClamAV reste à jour.
|
||||
|
||||
Le fichier `/etc/freshclam.conf` contient les paramètres suivants :
|
||||
|
||||
```cfg
|
||||
LogTime yes
|
||||
LogSyslog yes
|
||||
LogFacility LOG_DAEMON
|
||||
DatabaseMirror db.ch.clamav.net
|
||||
DatabaseMirror database.clamav.net
|
||||
NotifyClamd /etc/clamd.conf
|
||||
```
|
||||
|
||||
Maintenant, activez et démarrez freshclam afin qu'il mette à jour la
|
||||
signature de la base de donnée de ClamAV :
|
||||
|
||||
```sh
|
||||
$ doas rcctl enable freshclam
|
||||
$ doas rcctl start freshclam
|
||||
```
|
||||
|
||||
Ensuite, configurez clamd. Dans le fichier `/etc/clamd.conf`, les lignes
|
||||
suivantes sont paramétrées :
|
||||
|
||||
```cfg
|
||||
LogTime yes
|
||||
LogSyslog yes
|
||||
LogFacility LOG_DAEMON
|
||||
TemporaryDirectory /tmp
|
||||
LocalSocket /var/clamav/clamd.sock
|
||||
TCPSocket 3310
|
||||
TCPAddr 127.0.0.1
|
||||
User _clamav
|
||||
DetectPUA yes
|
||||
AlertEncrypted yes
|
||||
AlertEncryptedArchive yes
|
||||
AlertEncryptedDoc yes
|
||||
AlertOLE2Macros yes
|
||||
AlertPhishingSSLMismatch yes
|
||||
AlertPhishingCloak yes
|
||||
MaxRecursion 12
|
||||
```
|
||||
|
||||
La dernière partie de configuration est à-propos de c-icap. Deux fichiers
|
||||
de configurations ont besoin de modifications avant de permettre à c-icap
|
||||
d'utiliser ClamAV en tant que scanner de malware.
|
||||
|
||||
Le premier est `/etc/c-icap/c-icap.conf`. Ajoutez les lignes suivantes :
|
||||
```cfg
|
||||
Include /etc/c-icap/clamd_mod.conf
|
||||
Include /etc/c-icap/virus_scan.conf
|
||||
```
|
||||
|
||||
Vous devriez changer les valeurs suivantes dans ce fichier de manière
|
||||
significative et différente :
|
||||
```cfg
|
||||
ServerAdmin admin@example.org
|
||||
ServerName scanner.example.org
|
||||
TmpDir /tmp
|
||||
```
|
||||
|
||||
Il y a un défaut dans le fichier de configuration à-propos de la
|
||||
journalisation. L'option `Logger` est paramétrée vers `sys_logger`.
|
||||
Mais le module `sys_logger` requis est chargé seulement plus tard dans
|
||||
le fichier de configuration. Si vous voulez utiliser `sys_logger`, vous
|
||||
devez charger le module avant de paramétrer l'option `Logger`. Cela
|
||||
empêchera c-icap de démarrer, bien que [rcctl(8)](https://man.openbsd.org/rcctl)
|
||||
retournera ok. Soit vous changez l'option `Logger` vers `file_logger`
|
||||
soit vous déplacez les blocs dans le fichier de configuration pour
|
||||
utiliser `sys_logger`.
|
||||
|
||||
Dans le fichier `/etc/c-icap/clamd_scan.conf`, faites les paramétrages
|
||||
suivants :
|
||||
```cfg
|
||||
clamd_mod.ClamdHost 127.0.0.1
|
||||
clamd_mod.ClamdPort 3310
|
||||
```
|
||||
|
||||
## Démarrer les services
|
||||
|
||||
Puisque toute la configuration est faite, c'est maintenant le moment
|
||||
d'activer et de démarrer les services :
|
||||
```sh
|
||||
$ for s in clamd c_icap ; do
|
||||
> rcctl enable $s
|
||||
> rcctl start $s
|
||||
> done
|
||||
```
|
||||
|
||||
Soyez patient avec clamd. Il prend du temps à démarrer parce qu'il
|
||||
vérifie la base de données des signatures.
|
||||
|
||||
## Tester le serveur ICAP
|
||||
|
||||
Tester votre démarrage est facile parce que c-icap est fourni avec un
|
||||
client ICAP pour cette tâche : c-icap-client. Appellez-le sans arguments
|
||||
effectuera un simple appel d'OPTIONS pour vérifier si le server fonctionne :
|
||||
```sh
|
||||
$ c-icap-client
|
||||
ICAP server:localhost, ip:127.0.0.1, port:1344
|
||||
|
||||
OPTIONS:
|
||||
Allow 204: Yes
|
||||
Preview: 1024
|
||||
Keep alive: Yes
|
||||
|
||||
ICAP HEADERS:
|
||||
ICAP/1.0 200 OK
|
||||
Methods: RESPMOD, REQMOD
|
||||
Service: C-ICAP/0.5.6 server - Echo demo service
|
||||
ISTag: CI0001-XXXXXXXXX
|
||||
Transfer-Preview: *
|
||||
Options-TTL: 3600
|
||||
Date: Sat, 16 May 2020 10:02:03 GMT
|
||||
Preview: 1024
|
||||
Allow: 204
|
||||
X-Include: X-Authenticated-User, X-Authenticated-Groups
|
||||
Encapsulated: null-body=0
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Remerciements
|
||||
|
||||
Avec l'aimable autorisation de Bruno Flückiger !
|
||||
|
||||
*Cette page est la traduction de la page
|
||||
**[How to build a malware scan server][1]** du site **BSDHowto.ch**.*
|
||||
|
||||
---
|
||||
|
||||
## Historique
|
||||
|
||||
J'ai écrit historiquement cette traduction sur le wiki de la communauté
|
||||
"OpenBSD Pour Tous".
|
||||
|
||||
---
|
||||
|
||||
[1]: https://www.bsdhowto.ch/malware.html
|
||||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2019-05-20T11:00:01+01:00
|
||||
description: "Relecture du chapitre 6 - Dive into Python pour la communauté DVP"
|
||||
draft: false
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2019-05-16T20:27:01+01:00
|
||||
description: "Relecture du chapitre 8 - Dive into Python pour la communauté DVP"
|
||||
draft: false
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2019-05-16T21:31:01+01:00
|
||||
description: "Relecture du chapitre 2 - Python 3 Module of the Week pour la communauté DVP"
|
||||
draft: false
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2020-09-16T21:19:47+02:00
|
||||
description: "Traduction EN→FR : Que se passe-t-il quand vous écrivez dans la barre d'adresse du navigateur web ?!"
|
||||
draft: false
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2020-11-21T10:52:01+01:00
|
||||
description: "Carnet de revues concernant les différentes traductions EN → FR que j'ai faites et autres relectures auquelles j'ai participées"
|
||||
draft: false
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2020-12-22T23:31:21+01:00
|
||||
description: "Traduction du Tutoriel EN → FR 'Host your Cryptpad web office suite with OpenBSD' décrivant l'installation, la configuration de la suite web office Cryptpad pour l'utiliser sous OpenBSD"
|
||||
draft: false
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2021-05-07T15:08:51+02:00
|
||||
description: "Traduction du Tutoriel EN → FR 'Full list of services offered by a default OpenBSD installation' - article de Solène Rapenne - expliquant les différents services par défaut sous OpenBSD"
|
||||
draft: false
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2021-02-20T16:18:45+01:00
|
||||
description: "Traduction du Tutoriel EN → FR 'What security does a default OpenBSD installation offer?' expliquant ce qu'il faut attendre de la sécurité par défaut sous OpenBSD, selon Solène Rapenne"
|
||||
draft: false
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2021-05-05T14:21:10+02:00
|
||||
description: "Traduction du Tutoriel EN → FR 'OpenBSD: getting started' expliquant ce qu'il savoir pour bien commencer sous OpenBSD, selon Solène Rapenne"
|
||||
draft: false
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
---
|
||||
categories: ['Traduction']
|
||||
date: 2020-11-23T12:00:01+01:00
|
||||
description: "Traduction du 'Guide du Routeur OpenBSD' du site unixsheikh.com"
|
||||
draft: false
|
||||
|
|
|
|||
Loading…
Reference in New Issue