Bernez a écrit 1087 commentaires

Tu ne montres pas si tes slapd écoutent en ldap:// ou en ldaps://. JXplorer ne gère pas le STARTTLS. Pour vérifier que ça marche utilise ldapsearch avec l'option -ZZ. Pour ne pas s'encombrer des problèmes de certificats, mettre "TLS_REQCERT allow" dans le fichier .ldaprc.

Debian 7 est sortie il y a un peu plus d'un mois. Debian 6 est donc obsolète et il vaut mieux utiliser la 7.

Il est plus propre d'utiliser le mode dit "STARTTLS" qui passe du texte en clair à SSL à chaud et utilise le port standard du protocole, que le SSL natif sur un autre port (cf. FAQ de OpenLDAP).

Trêve de pinaillage, voici comment ça se configure. Pour être plus tranquille, préconfigurer les options du client LDAP pour le root :
# cat > /root/.ldaprc
URI ldapi:///
SASL_MECH EXTERNAL
#
Ensuite créer un fichier LDIF comme suit :
# cat > init.ldif
dn: cn=config
changetype: modify
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/ca-key.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/ca-cert.pem
# ldapmodify -Q -f init.ldif
Pas besoin d'ajouter "ldaps///" en argument à slapd.

Pour s'assurer que l'annuaire sera inaccessible aux clients sans SSL :
# cat > ssl.ldif
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1
# ldapmodify -Q -f ssl.ldif

J'ai voulu faire un rapport de bug pour le signaler, puis j'ai constaté qu'il faut pour cela un compte Google (que je n'ai pas). Quand même assez dommage pour un logiciel GNU.

Mets l'utilisateur monsiteweb dans le groupe www-data.
Autres remarques tant que j'y suis : utilise SSH (scp) à la place de FTP, et ne rends pas exécutables des fichiers qui n'ont pas à l'être.

Je connais UPS, Fedex, ou DHL, mais pas ColiPoste. c'est peut-être peut-être un leader local quelque part dans un petit bout du globe et à tout les coup pour des petits colis seulement.

Peut-être, mais ils utilisent maintenant le leader des distributions Linux (ou pas).

En effet, on lit très souvent « certificat SSL », mais TLS peut aussi utiliser des certificats OpenPGP, et X.509 est utilisé par d'autres protocoles tels que S/MIME. Ces deux standards ont été définis totalement indépendamment.

Exim est effectivement très flexible, mais sans que cette flexibilité ne gêne la lisibilité de la configuration. La configuration par défaut est également raisonnable. Il ne faut pas se laisser effrayer par la myriade de fichiers sous Debian. Cette façon de configurer Exim est très spécifique à Debian et, je pense, avant tout faite pour ceux qui n'ont que des besoins très standards.

Tous ceux que j'ai vu utiliser Exim le faisaient parce que c'est ce qui est fourni par défaut avec Debian pour des raisons historiques et faute de raison importante pour changer, et n'avaient strictement rien changé à la configuration par défaut.

J'ai fait un certain nombre d'adaptations (en partant du fichier de configuration par défaut livré en upstream) sur diverses machines.

De plus la doc d'Exim est excellente. Donc Exim me paraît être un choix tout à fait pertinent.

Certes la plupart des sous-titres sont fait à l'arrache, mais un bon sous-titre est mis en forme, placé dans l'image au bon endroit (droite, gauche, haut…), et donc décaler la chose va te pourrir l'affichage :(.

Je pense que Kerro parlait de décalage dans le temps, et non dans l'espace.

Ex, sur postfix, pour modifier les entetes, pas possible de le faire juste pour les mails entrants (mais pas envoyés par les clients auth), et que pour certains domaines, on peut tout simplement pas tout faire à la fois.

Est-ce que ça supporte le SRS et que pour certains domaines? (maintenant que spf est accepté de partout, il est ptet temps de s'occuper de srs?!)

A priori tout ça est faisable avec Exim.

Un des grands apports d'IPv6 est de simplifier la vie des routeurs, en diminuant la charge nécessaire au traitement des en-têtes (simplification des en-têtes et déport des sommes de contrôle dans la couche de transport) et en diminuant le nombre de routes grâce à la meilleur hiérarchisation de l'adressage.

Le protocole TLS permet une négociation, entre le serveur et le client, des protocoles cryptographiques (ciphers) à utiliser. Dans ton cas ton serveur web et le navigateur d'Android n'ont pas trouvé de terrain d'entente. J'imagine que le vieil Android ne négocie que des protocoles que GnuTLS considère par défaut pas assez sécurisés. La solution la plus simple consiste probablement à faire accepter à GnuTLS des protocoles gérés par Android 2.3. Si ton serveur web est Apache, regarde du côté de la directive GnuTLSPriorities de mod_gnutls.

Dans le même genre :

curl -v -6 http://www.esial.uhp-nancy.fr
* getaddrinfo(3) failed for www.esial.uhp-nancy.fr:80
* Couldn't resolve host 'www.esial.uhp-nancy.fr'
* Closing connection #0
curl: (6) Couldn't resolve host 'www.esial.uhp-nancy.fr'

Par contre, comment s'assurer qu'une extension fonctionne bien? Je vois toujours le correcteur d'orthographe, et rien pour la grammaire…

Il faut installer un des dictionnaires disponibles depuis la même page de téléchargement que celle de grammalecte.

Tes règles sont cohérentes mais inutilement chargées à mon avis. Le « --sport 1024:65535 » n'apporte pas grand chose. Le « -m state --state NEW,ESTABLISHED », quant à lui, correspond pour ainsi dire à tous les paquets. Enlever ces deux choses feraient gagner en lisibilité sans affecter la sécurité.

Pour régler ton problème de droits d'accès, pourquoi n'utilises-tu pas tout simplement un utilisateur spécifique aux permissions restreintes ? MySQL permet des réglages très fins à ce niveau.

Une autre dans le paragraphe sur autosleep : « Cette technique […] est vivement critiqué » => « critiquée ».

Peux-tu préciser ce que tu veux faire exactement ?

Stunnel répondrait-il à ton besoin ?

C'est là la grande force de l'espéranto par rapport à ses concurrents: il reste relativement abordable pour un asiatique ou un hongrois, car si son vocabulaire est principalement indo-européen, sa grammaire ne l'est pas du tout.
Créer une langue à la fois simple et représentant la même difficulté d'apprentissage pour tout le monde est une chimère. Il y a tellement de façons différentes, et incompatibles entre elles, d'exprimer une même idée, que bâtir une grammaire qui mette sur un pied d'égalités Européens, Chinois, Indiens et Polynésiens, ne peut se faire qu'au moyen d'un énorme monstre totalement incohérent. Sinon on avantage forcément quelqu'un. La difficulté d'apprentissage dépend énormément des langues qu'on connait déjà.

La doc d'Exim dit :
When Exim is built, an option called FIXED_NEVER_USERS can be set to a list of users that must not be used for local deliveries. This list is fixed in the binary and cannot be overridden by the configuration file. By default, it contains just the single user name “root”.
Donc pour permettre de délivrer des mails au root, il faudrait reconstruire le paquet Debian. Cela dit, tout comme les développeurs d'Exim et un grand nombre d'informaticiens, je ne vois aucune bonne raison de vouloir délivrer des mails au root.

Le site du SOCIS précise dans sa FAQ qu'il faut choisir une licence de l'Open Source Initiative, dont certaines sont jugées non-libres par la FSF soit dit en passant.

Tu peux obtenir le comportement que tu souhaites très simplement avec mod_dav sous Apache. Ce module est livré de base avec Apache (au moins sous Debian) donc il suffit d'installer Apache. Ensuite tu configures un répertoire avec des permissions adéquates dans la config d'Apache :

<Directory /var/www/devoirs>
    DAV on
    AuthType Basic
    AuthName DepotWebDAV
    AuthUserFile /etc/apache2/passwd.dav
    <Limit PROPFIND PUT>
        Require user etudiant professeur
    </Limit>
    <Limit DELETE GET>
        Require user professeur
    </Limit>
</Directory>

L'utilisateur qui fait tourner Apache (www-data sous Debian) doit avoir les droits en écriture sur le répertoire /var/www/devoirs.

Ensuite tu crées tes utilisateurs avec htpasswd :

httpasswd -c /etc/apache2/passwd.dav professeur
httpasswd /etc/apache2/passwd.dav etudiant

Et si tu n'as pas envie de t'embêter avec un certificat SSL pour protéger les envois de mots de passe, tu peux utiliser une authentification digest à la place de basic (de concert avec la commande htdigest).

Un paquet à installer, un fichier de configuration et des comptes utilisateurs dans un fichier à plat, on ne peut pas faire plus simple.

Pourrais-tu donner des exemples d'articles ainsi créés ?

Nous revenons au début d'Internet, et oui beaucoup d'entre vous l'ont oublié, mais chaque poste était relié au net par une IP publique !
Attention donc aux réglages des paramètres de sécurité (pare-feux...). Pour cette raison en entreprise l'adoption de l'IPv6 ne sera sans doute pas activée avant très longtemps, une IPv6 publique fera sans doute du NAT pour aller vers internet
J'espère bien qu'on ne sera jamais témoins d'une telle aberration ! Pour obtenir le même de niveau de sécurité qu'avec le NAT couramment utilisé de nos jours, 3 lignes de configuration suffisent :
iptables -P FORWARD DROP
iptables -A FORWARD -i interface_internet -o interface_locale -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i interface_locale -o interface_internet -j ACCEPT
Là c'est un exemple avec Netfilter, mais j'imagine que tout pare-feu capable de faire du NAT peut en faire autant.

Je ne l'ai pas testé, mais la commande suivante pourrait faire l'affaire :
iptables -t nat -A PREROUTING -d 123.123.123.123 -p tcp --dport 1234 -j DNAT --to-destination IP_du_serveur:1001-1020 --persistent