Antisèches techniques

Tester une configuration SSL de OpenLDAP - Debian

Tue, 18 Mar 2025 12:15:00 +0000

Pour tester si le SSL est activer et consulter le certificat :

 openssl s_client -connect 127.0.0.1:636 -showcerts -state

Si il y a un certificat, voici la commande ldapsearch qui permet de tester la connexion :

 ldapsearch -v -H ldaps://127.0.0.1:636

La commande devrait répondre : SASL/DIGEST-MD5 authentication started avant de demander un mot de passe.

En cas de mauvaise configuration, les messages suivants pourraient être renvoyés :

ldap_sasl_interactive_bind_s: Can't contact LDAP server : ldaps:/// n’est pas activé
additional info: The TLS connection was non-properly terminated : les certificats ne sont pas créés/activés

Enfin, le test pour un login particulier peut se faire avec la commande suivante :

ldapsearch  -x -D uid=admin,ou=People,dc=domain,dc=com -w <MOT_DE_PASSE_ADMIN> -H ldaps://127.0.0.1 -b  dc=domain,dc=com -x  uid=login

En adaptant :

l’identifiant du compte admin (ici uid=admin,ou=People,dc=domain,dc=com)
le mot de passe de ce compte (ici <MOT_DE_PASSE_ADMIN>)
l’annuaire ldap interrogé (ici dc=domain,dc=com)
le login recherché (ici uid=login)

Activer ldaps

Pour activer le SSL, veiller à ce que ldaps:/// est activé via l’option SLAPD_SERVICES de /etc/default/slapd :

 $ grep SLAPD_SERVICES /etc/default/slapd
 SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"

Configurer les certificats

Vérifier que openldap est configuré avec un certificat :

$ sudo ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -s base | grep olcTLS
olcTLSCACertificateFile: /etc/ssl/openldap/certs/cacert.pem
olcTLSCertificateFile: /etc/ssl/openldap/certs/ldapserver-cert.crt
olcTLSCertificateKeyFile: /etc/ssl/openldap/private/ldapserver-key.key

Si ce n’est pas le cas, la commande ldapmodify permettra de le faire via un fichier ldif.

Voici le contenu du ldif (appelé ssl.ldif dans la suite) :

dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/openldap/certs/cacert.pem
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/openldap/certs/ldapserver-cert.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/openldap/private/ldapserver-key.key

Il faut adapter les chemins des certificats/clés en fonction de ceux créés.

Une fois le fichier créé, voici comment l’intégrer dans la configuration :

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif

Augmenter la taille d'une partition lvm

Wed, 22 May 2024 15:45:00 +0000

Trouver la partition à augmenter :

df -h

/dev/mapper/lv-vg-tmp    4,6G    177M  4,1G   5% /tmp
/dev/mapper/lv-vg-tmp-home   121G     96G   20G  83% /home

Augmenter la taille de la partition :

lvresize --resizefs --size +5G /dev/mapper/lv-vg-tmp-home

Source : https://doc.ubuntu-fr.org/lvm#volume_logique2

Conserver la compatibilité des url Big Blue Button

Mon, 05 Jun 2023 15:00:00 +0000

En changeant de version de Greenlight de la version 2 à la version 3 (big blue button 2.4 à 2.6), les url des chambres ont changées.

Les chambres avaient des url de type bbb.example.org/b/id-de-ma-chambre, elles sont maintenant accessibles depuis bbb.example.org/rooms/id-de-ma-chambre

Pour conserver la compatibilité après la migration, il faut ajouter une redirection nginx en créant un fichier /etc/bigbluebutton/nginx/oldurl.nginx avec le contenu :

rewrite ^/b/(.*)$ /rooms/$1 permanent;

IcedTea Error: Cannot grant permissions to unsigned jars

Mon, 02 Jan 2023 15:00:00 +0000

Chez Online, l’accès KVM nécessite parfois l’execution d’un code java via icedtea-web. Pour certains vieux serveurs, un erreur Cannot grant permissions to unsigned jars doit être résolue.

$ javaws viewer.jnlp
netx: Initialization Error: Could not initialize application. (Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.)
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
	at java.desktop/net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:823)
	at java.desktop/net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:531)
	at java.desktop/net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:946)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.
	at java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.getClassLoaderSecurity(JNLPClassLoader.java:2488)
	at java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:384)
	at java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:807)
	at java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:337)
	at java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:420)
	at java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:494)
	at java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:467)
	at java.desktop/net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:815)
	... 2 more

Pour se faire, vous pouvez identifier les jar qui posent problème via la java console :

...
netx: Initialization Error: Could not initialize application. (Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.)
App already has trusted publisher: false
Jar found at /home/user/.cache/icedtea-web/cache/3/https/192.168.1.1/443/software/avctVMLinux64.jarhas been verified as UNSIGNED
Jar found at /home/user/.cache/icedtea-web/cache/2/https/192.168.1.1/443/software/avctKVMIOLinux64.jarhas been verified as UNSIGNED
Jar found at /home/user/.cache/icedtea-web/cache/1/https/192.168.1.1/443/software/avctKVM.jarhas been verified as UNSIGNED

On peut reproduire l’erreur via l’outil jarsigner :

$ jarsigner -verify -certs -verbose /home/user/.cache/icedtea-web/cache/3/https/192.168.1.1/443/software/avctVMLinux64.jar

        196 Fri Jul 25 17:49:26 CEST 2014 META-INF/MANIFEST.MF
        259 Mon Jul 24 09:53:16 CEST 2017 META-INF/DELL.SF
        6669 Mon Jul 24 09:53:16 CEST 2017 META-INF/DELL.RSA
         259 Fri Jul 25 17:49:26 CEST 2014 META-INF/AVOCENT.SF
        1058 Fri Jul 25 17:49:26 CEST 2014 META-INF/AVOCENT.DSA
           0 Tue Nov 05 14:49:36 CET 2013 META-INF/
 m  ? 371353 Tue May 17 15:52:22 CEST 2011 libavmlinux.so

  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  ? = unsigned entry

- Signed by "CN=Avocent, OU=iBMC, O=Avocent Corporation, L=Sunrise, ST=Florida, C=US"
    Digest algorithm: SHA1 (disabled)
    Signature algorithm: SHA1withDSA (disabled), 1024-bit key (weak)
- Signed by "CN=Dell Inc., O=Dell Inc., L=Round Rock, ST=Texas, C=US"
    Digest algorithm: SHA1 (weak)
    Signature algorithm: MD5withRSA (disabled), 2048-bit key
  Timestamped by "CN=Certum EV TSA SHA2, OU=Certum Certification Authority, O=Unizeto Technologies S.A., C=PL" on lun. juil. 24 09:53:17 UTC 2017
    Timestamp digest algorithm: SHA-1 (weak)
    Timestamp signature algorithm: SHA256withRSA, 2048-bit key

WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:

  jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01

Il faut donc intervenir sur l’option jdk.jar.disabledAlgorithms de java pour réactiver les éléments désactivés par défaut. Ici SHA1 (et par incidence SHA1withDSA et MD5withRSA).

Pour le faire, il faut éditer le fichier java.security de la version de votre java.

La version de mon java étant 17.0.5 :

$ java -version
openjdk version "17.0.5" 2022-10-18
OpenJDK Runtime Environment (build 17.0.5+8-Debian-2)
OpenJDK 64-Bit Server VM (build 17.0.5+8-Debian-2, mixed mode, sharing)

il faut modifier la configuration qui se trouve dans /usr/lib/jvm/java-1.17.0-openjdk-amd64/conf/security/java.security :

#jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024

jarsigner indique maintenant que le jar est vérifié :

$ jarsigner -verify -certs -verbose /home/user/.cache/icedtea-web/cache/3/https/192.168.1.1/443/software/avctVMLinux64.jar
...

jar verified.

et icedtea-web ne pose plus de problème :

$ javaws viewer.jnlp

Diviser la partition root en raid en plusieurs partitions

Fri, 06 May 2022 09:30:00 +0000

Pour réaliser cette procédure, on a besoin de modifier la partition root. Il faut donc booter en mode rescue (ou via un live cd).

Identifier le raid de la partition root

Liste les périphérique raid :

$ cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md126 : active (auto-read-only) raid1 sda3[1] sdb3[0]
      975055872 blocks super 1.2 [2/2] [UU]
      	resync=PENDING
      bitmap: 7/8 pages [28KB], 65536KB chunk

md127 : active (auto-read-only) raid1 sda2[1] sdb2[0]
      523264 blocks super 1.2 [2/2] [UU]

Et repérage des détails de chacun d’entre eux :

$ tune2fs -l /dev/md126
tune2fs 1.45.5 (07-Jan-2020)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          3b617f47-b28d-4c8f-9f17-697779d503bc
Block count:              243763968
Reserved block count:     12188198
Overhead blocks:          4108002
Free blocks:              239277665
Free inodes:              60907081
[...]

Le point de montage est bien /, c’est donc notre périphérique.

Réduction de la taille du raid

Vérification du système de fichier :

$ e2fsck -f /dev/md126

Réduction de la taille :

$ resize2fs /dev/md126 40G

Réduction de la taille du raid :

$ mdadm --grow --size 45G /dev/md126
mdadm: component size of /dev/md126 has been set to 52428800K

On prend volontairement des taille plus petite que la taille visée de 50G histoire d’éviter les problèmes de conversion d’unités

Retaille la première partition

Il faut retailler une à une les partitions de chacun des disques.

$ mdadm --manage --set-faulty /dev/md126 /dev/sda3

$ mdadm --manage --remove /dev/md126 /dev/sda3

Désactiver les autres partitions (via mdadm --stop et/ou swapoff) puis retailler le disque pour réduire la partition sda3 à 50G.

$ fdisk /dev/sda

$ partprobe /dev/sda

Une fois réalisé, on peut reconstituer le raid :

$ mdadm --add /dev/md126 /dev/sda3

Il faut ensuite attendre que les données soient recopiées (cat /proc/mdadm).

Copier la taille pour la seconde partitions

Désactiver l’usage de toutes les partitions du 2d disque en commençant par celle faisant partie du raid :

$ mdadm --manage --set-faulty /dev/md126 /dev/sdb3

$ mdadm --manage --remove /dev/md126 /dev/sdb3

Puis copier la table des partition du premier sur le 2d disque :

$ sfdisk -d /dev/sda   | sfdisk /dev/sdb

On prévient le noyau du changement de partitions :

$ partprobe /dev/sdb

On ajoute le 2d disque dans le raid :

$ mdadm --add /dev/md126 /dev/sdb3

Mise d’ecquerre des tailles :

$ mdadm --grow --size 49G /dev/md126

$ resize2fs /dev/md126
resize2fs 1.45.5 (07-Jan-2020)
Filesystem at /dev/md126 is mounted on /root/root; on-line resizing required
old_desc_blocks = 6, new_desc_blocks = 7
The filesystem on /dev/md126 is now 13107200 (4k) blocks long.

Création d'une visualisation de schema SQL

Mon, 04 Apr 2022 09:30:00 +0000

Installation des dépendances

 sudo apt install python3-sadisplay graphviz

Création du fichier graphviz

sadisplay -u "mysql://user:password@host/database" > schema.dot

Création de l’image de visualisation du schéma SQL

dot -Tpng schema.dot > schema.png

Réception de mail exim Mailing to remote domains not supported

Thu, 07 Oct 2021 11:00:00 +0000

Description du problème « Mailing to remote domains not supported »

Un serveur envoi de manière intempestive des mails au sujet « Mail delivery failed: returning message to sender » dont une partie du contenu :

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  mail@example.org
     (generated from actualys@localhost)
     Mailing to remote domains not supported

La suite du message peut contenir des mails administratifs du type compte-rendu de crontab.

Mail frozen

Avec la commande mailq, vérifiez qu’il existe bien des mails dans un état frozen afin de vous assurez que les notifications viennent bien de cette machine :

$ mailq
17h  2.0K 1mYA7M-0002Z6-16 <> *** frozen ***
      mail@example.org

17h  2.0K 1mYACA-0002a6-60 <> *** frozen ***
      mail@example.org

L’envoi de ces mails est donc retenté régulièrement par exim.

Reconfiguration d’exim

Avec la commande dpkg-reconfigure, reconfigurez exim

$ sudo dpkg-reconfigure exim4-config

Veillez au domaine associé à votre configuration exim pour qu’elle ne corresponde pas à une autre machine que la votre.

Purge des mails frozen

Pour nettoyer les mails frozen, executez la commande suivante :

$ sudo mailq | grep frozen | awk '{print $3}' | sudo xargs exim -Mrm

Assurez-vous que la queue de mails reste bien vide quelques minutes plus tard (notamment si des crons s’executent régulièrement).

$ sudo mailq

Copier un document couchdb

Fri, 17 Sep 2021 09:37:00 +0000

Copier un document couchdb

La documentation couchdb de la copie d’un document est décrite ici : https://docs.couchdb.org/en/stable/api/document/common.html#copying-from-a-specific-revision

Dans la requète http il faut utiliser la méthode COPY et l’entête Destination: new_document_id pour indiquer le nouvel id de document :

curl -X COPY http://localhost:5984/database_name/document_id -H 'Destination: new_document_id'

Autologin avec metabase

Mon, 13 Sep 2021 01:07:00 +0000

Autologin avec metabase

S’authentifier avec l’api de metabase

Il est possible de s’authentifier à metabase via son api, en incluant par exemple ce code javascript dans une page du même domaine :

var metabase_webpath = '/metabase';
var username = 'username';
var password = 'password';

var xhttp = new XMLHttpRequest();
xhttp.open("POST", metabase_webpath + "/api/session", false);
xhttp.setRequestHeader("Content-type", "application/json");
xhttp.send('{"password":"' + password + '","username":"' + username + '","remember":'+ remember +'}');

Une réponse avec le code http 200 indique une authentification réussi.

Vérifier si l’utilisateur est authentifié sur metabase

var metabase_webpath = '/metabase';
var xhttp = new XMLHttpRequest();
xhttp.open("GET", metabase_webpath + "/api/user/current", true);
xhttp.send();
xhttp.onload = function() {
	if(xhttp.status != 401) {
		// Utilisateur déjà authentifié sur metabase
        return;
	}
    
    // Utilisateur non authentifié
}

Insérer du code javascript dans métabase avec Apache

Si metabase est distribué par apache, comme par exemple avec cette configuration :

<Location "/metabase/">
        ProxyPass http://localhost:3213/
        ProxyPassReverse http://localhost:3213/
        SSLRequireSSL
</Location>

Il est possible d’insérer du code html dans la réponse http avec les modules apache substitute et filter. Filter est généralement activé de base, il est par contre nécessaire d’activer substitute :

sudo a2enmod substitute

Voici la configuration apache pour insérer l’appel à un fichier javascript nommé /js/metabase_autologin.js dans toute les pages html de métabase :

<Location "/metabase/">
        Header unset Content-Security-Policy
        RequestHeader unset Accept-Encoding
        AddOutputFilterByType SUBSTITUTE text/html
        Substitute "s#</body>#<script type=\"text/javascript\" src=\"/js/metabase_autologin.js\"></script></body>#ni"
</Location>

Problème decriture du lock solr avec tomcat 9

Tue, 31 Aug 2021 21:00:00 +0000

Problème d’écriture du fichier de lock SOLR avec tomcat 9

Suite à une migration de tomcat8 à tomcat9 sous Debian, Solr n’arrive plus à écrire en la base lucenne.

Les exceptions suivantes sont renvoyés (dans le fichier /var/log/tomcat9/catalina.out :

java.lang.RuntimeException: Failed to acquire random test lock; please verify filesystem for lock directory './solr/data/index' supports locking

ou :

org.apache.lucene.store.LockReleaseFailedException: Cannot forcefully unlock a NativeFSLock which is held by another indexer component: ./solr/data/index/lucene-xxxxxxxxxxxxxxxxxxxxxxxxx-lucene-xxxx-test.lock

Le problème vient d’un problème d’autorisation en écriture de tomcat9 dans la base lucence.

Vérifier la paternité et les droits du répertoire data et de ses sous-répertoire

Le service Tomcat9 sous debian ne tourne plus sous l’utilisateur tomcat8 mais tomcat. Il faut donc s’assurer que ce démon a les droits pour écrire dans la base hébergée dans le sous répertoire data du répertoire de travail solr.

Pour s’en assurer, il faut changer les droits :

chown -R tomcat.tomcat solr/data

chmod -R u+wX solr/data

Autoriser les écritures dans la sandbox java

Avec tomcat9, un système de sandboxing a été introduit. Il limite les accès en écriture sur quasi tous les répertoires (Pour plus d’info, voir ce README Debian).

A moins que le répertoire data soit un sous répertoire de /var/lib/tomcat9/webapps, il faut l’ajouter comme répertoire autorisé dans service.d.

Pour se faire, il suffit d’ajouter un fichier .conf dans le répertoire /etc/systemd/system/tomcat9.service.d/ (nous avons choisi override.conf) contenant les informations suivantes :

  [Service]
  ReadWritePaths=/chemin/absolu/vers/solr/data

(il faut evidemment adapter /chemin/absolu/vers/solr/data à votre configuration)

Cette résolution a été trouvée grace à ce fil serverfault.