Souci :
La migration a fait que les utilisateurs se connectent avec un autre identifiant (du point de vue de Seafile).
On le constate en regardant dans la table MySQL seahubdb.profile_profile :
use seahubdb;
select * from profile_profile;
+----+------------------------------------------------+-------------+-------+-----------+----------+-------------------------------------+-------------+----------------------+-------------------------------+
| id | user | nickname | intro | lang_code | login_id | contact_email | institution | list_in_address_book | is_manually_set_contact_email |
+----+------------------------------------------------+-------------+-------+-----------+----------+-------------------------------------+-------------+----------------------+-------------------------------+
| 1 | user1@mon.domaineA.fr | | | NULL | NULL | NULL | | 0 | 0 |
| 2 | user2@mon.domaineA.fr | | | NULL | NULL | NULL | | 0 | 0 |
| 3 | user3@mon.domaineA.fr | | | NULL | NULL | NULL | | 0 | 0 |
| 4 | user4@domaineB.fr | | | NULL | NULL | NULL | | 0 | 0 |
| 5 | user5@domaineB.fr | | | NULL | NULL | NULL | | 0 | 0 |
| 6 | user6@domaineB.fr | | | NULL | NULL | NULL | | 0 | 0 |
| 7 | user7@domaineB.fr | | | NULL | NULL | NULL | | 0 | 0 |
| 8 | 2dc612f5xxxxxxxxxxx070130478969d@auth.local | user1 | | NULL | NULL | user1@domaineB.fr | | 0 | 0 |
| 9 | d6b0179xxxxxxx659248ef76e5fa47d2@auth.local | user7 | | NULL | NULL | NULL | | 0 | 0 |
| 10 | 35xxxxxxxxxxxxxxxx996f0c73782141@auth.local | user3 | | NULL | NULL | user3@domaineB.fr | | 0 | 0 |
| 11 | fb1f79924d96466daxxxxxxxxx3d4106@auth.local | user2 | | NULL | NULL | user2@domaineB.fr | | 0 | 0 |
| 12 | 4eexxxxxxxxxxxxxxxxxxc90b3d806ce@auth.local | user4 | | NULL | NULL | user4@domaineB.fr | | 0 | 0 |
+----+------------------------------------------------+------------------+-------+-----------+----------+----------------------------------------------+-------------+----------------------+-------------------------------+
12 rows in set (0.000 sec)

On peut voir 3 types d’utilisateurs :
– user1@mon.domaineA.fr
– user1@domaineB.fr
– 2dc612f5xxxxxxxxxxx070130478969d@auth.local

Les 3 utilisateurs dans ce cas sont les mêmes, mais authentifiés différemment, ce qui perturbe Seafile.

Solution :
Pour récupérer l’accès aux fichiers, il faut mettre à jour les tables RepoOwner, SharedRepo, RepoUserToken, RepoGroup et share_fileshare.
Les requêtes de mise à jour ressemblent à cela.

Il faut, à partir de la table seahubdb.profile_profile déterminer les correspondances entre les 3 identifiants pour ne laisser en BDD que la 3ème version en @auth.local. Et cela pour tous les utilisateurs. Exemple ici pour user1.

use seafile;

UPDATE RepoOwner
SET owner_id='2dc612f5xxxxxxxxxxx070130478969d@auth.local'
WHERE owner_id IN ('user1@domaineB.fr','user1@mon.domaineA.fr');

UPDATE SharedRepo
SET from_email='2dc612f5xxxxxxxxxxx070130478969d@auth.local'
WHERE from_email IN ('user1@domaineB.fr','user1@mon.domaineA.fr');

UPDATE SharedRepo
SET to_email='2dc612f5xxxxxxxxxxx070130478969d@auth.local'
WHERE to_email IN ('user1@domaineB.fr','user1@mon.domaineA.fr');

UPDATE RepoUserToken
SET email='2dc612f5xxxxxxxxxxx070130478969d@auth.local'
WHERE email IN ('user1@domaineB.fr','user1@mon.domaineA.fr');

UPDATE RepoGroup
SET user_name='2dc612f5xxxxxxxxxxx070130478969d@auth.local'
WHERE user_name IN ('user1@domaineB.fr','user1@mon.domaineA.fr');

UPDATE share_fileshare
SET username='2dc612f5xxxxxxxxxxx070130478969d@auth.local'
WHERE username IN ('user1@domaineB.fr','user1@mon.domaineA.fr');

Pas besoin de nettoyer la table seahubdb.profile_profile, même si à mon avis les entrées obsolètes ne serviront plus.

A priori la modification est prise à chaud, pas besoin de redémarrage.

En complément, et je doute que cela ait aidé, mais j’ai modifié le fichier de conf seafile :
/var/www/seafile/conf/seahub_settings.py
#LDAP_ADMIN_DN = ''
#LDAP_ADMIN_PASSWORD = ''
LDAP_USER_ATTR_EMAIL = 'mail'

Un redémarrage des services seafile semble nécessaire après modification :
systemctl restart seafile.service seahub.service

The post Seafile sur Yunohost et fichiers disparus first appeared on Gagzen.

Une fois installée, il ne semble pas possible de s’authentifier comme il faut sur Mobilizon.
Une fois le formulaire remplis, on atterrie sur une page vide (avec les Header et Footer de Mobilizon).

Il faut passer les commandes suivantes pour corriger :

sudo yunohost app setting mobilizon protect_against_basic_auth_spoofing -v false
sudo yunohost app ssowatconf
sudo systemctl restart mobilizon

Supprimer le cookie Mobilizon, puis éventuellement redémarrer le navigateur si cela ne suffit pas.

Source :
https://forum.yunohost.org/t/mobilizon-souci-pour-se-connecter/37315

The post Mobilizon sur Yunohost – Souci de login first appeared on Gagzen.

Le souci semble lié à la gestion LateX de Kali. Solution au 09/06/2025 :

apt-get install texlive-latex-extra --no-install-recommends
apt-get install texlive-fonts-recommended

Puis restart openvas

systemctl restart gvmd.service

—
Source
https://github.com/greenbone/gsa/issues/1146
Qui rebondit ici :
https://github.com/greenbone/gvmd/blob/main/INSTALL.md#prerequisites-for-optional-features

The post OpenVAS sous Kali – Rapport PDF vide first appeared on Gagzen.

Par défaut, Hesk 3.5.3 au 04/05/2025, autorise les pièces jointes telles que :

'max_number' => 2,
'max_size' => 2097152,
'allowed_types' => array('.gif','.jpg','.png','.zip','.rar','.csv','.doc','.docx','.xls','.xlsx','.txt','.pdf')

Il est donc possible de modifier tel que par exemple :

'max_number' => 20,
'max_size' => 20971520,
'allowed_types' => array('.gif','.jpg','.png','.zip','.rar','.csv','.doc','.docx','.xls','.xlsx','.txt','.pdf','.ods','.odt','.jpeg')

fichier hesk_settings.inc.php, à la racine du site.

The post Hesk modification paramètre pièces jointes first appeared on Gagzen.

Pour ce faire :

En supposant que sda est le disque sain et sdb le disque remplacé :

sfdisk -d /dev/sda > part_table_$(date +"%Y-%m-%d")
grep -v ^label-id part_table_$(date +"%Y-%m-%d") | sed -e 's/, *uuid=[0-9A-F-]*//' | sfdisk /dev/sdb

(trouvé ici : https://unix.stackexchange.com/questions/12986/how-to-copy-the-partition-layout-of-a-whole-disk-using-standard-tools )

Puis on répare les volume RAID1.
On les liste :

# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md7 : active raid1 sda7[1]
      7498270720 blocks super 1.2 [2/1] [_U]
      bitmap: 26/56 pages [104KB], 65536KB chunk

md6 : active raid1 sda6[0]
      52395008 blocks super 1.2 [2/1] [U_]
      
md2 : active raid1 sda2[0]
      104791040 blocks super 1.2 [2/1] [U_]
      
md4 : active raid1 sda4[0]
      104791040 blocks super 1.2 [2/1] [U_]
      
md5 : active raid1 sda5[0]
      52395008 blocks super 1.2 [2/1] [U_]
      
unused devices: <none>

Et on répare :

# mdadm /dev/md2 --add /dev/sdb2
# mdadm /dev/md4 --add /dev/sdb4
# mdadm /dev/md7 --add /dev/sdb7
# mdadm /dev/md5 --add /dev/sdb5

J’en profite pour cloner la partition EFI :

# dd if=/dev/sda1 of=/dev/sdb1 bs=1024

The post Réparation d’un RAID1 logiciel avec mdadm suite panne first appeared on Gagzen.

dpkg: error processing package yunohost (–configure):
installed yunohost package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
yunohost

 

Trace complète :

 root@toto:~# apt upgrade
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Calculating upgrade… Done
The following package was automatically installed and is no longer required:
equivs
Use ‘apt autoremove’ to remove it.
The following NEW packages will be installed:
libraqm0 linux-image-5.10.0-31-amd64
The following packages will be upgraded:
base-files distro-info-data dns-root-data ffmpeg galera-4 krb5-locales libavcodec58 libavdevice58 libavfilter7 libavformat58
libavresample4 libavutil56 libcurl3-gnutls libgd3 libgdk-pixbuf-2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libglib2.0-0
libglib2.0-data libgnutls30 libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0 libnss-systemd libpam-systemd libpostproc55
libswresample3 libswscale5 libsystemd0 libudev1 libvpx6 linux-image-amd64 linux-libc-dev nano php8.1-imagick php8.2 php8.2-cli
php8.2-common php8.2-fpm php8.2-gd php8.2-mbstring php8.2-opcache php8.2-readline php8.2-xml python3-idna python3-reportbug
reportbug systemd systemd-sysv udev yunohost-admin
52 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 0 B/94.1 MB of archives.
After this operation, 318 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs… Done
Extracting templates from packages: 100%
Setting up yunohost (11.2.22) …
Regenerating configuration, this might take a while…
Traceback (most recent call last):
File « /usr/lib/python3.9/logging/config.py », line 389, in resolve
found = getattr(found, frag)
AttributeError: module ‘moulinette.interfaces’ has no attribute ‘api’

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File « /usr/lib/python3.9/logging/config.py », line 564, in configure
handler = self.configure_handler(handlers[name])
File « /usr/lib/python3.9/logging/config.py », line 722, in configure_handler
klass = self.resolve(cname)
File « /usr/lib/python3.9/logging/config.py », line 391, in resolve
self.importer(used)
File « /usr/lib/python3/dist-packages/moulinette/interfaces/api.py », line 12, in <module>
from gevent import sleep
File « /usr/lib/python3/dist-packages/gevent/__init__.py », line 86, in <module>
from gevent._hub_local import get_hub
File « /usr/lib/python3/dist-packages/gevent/_hub_local.py », line 101, in <module>
import_c_accel(globals(), ‘gevent.__hub_local’)
File « /usr/lib/python3/dist-packages/gevent/_util.py », line 148, in import_c_accel
mod = importlib.import_module(cname)
File « /usr/lib/python3.9/importlib/__init__.py », line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File « src/gevent/_hub_local.py », line 1, in init gevent._gevent_c_hub_local
ValueError: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 152 from C header, got 40 from PyObject

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File « /usr/bin/yunohost », line 77, in <module>
yunohost.cli(
File « /usr/lib/python3/dist-packages/yunohost/__init__.py », line 35, in cli
init_logging(interface= »cli », debug=debug, quiet=quiet)
File « /usr/lib/python3/dist-packages/yunohost/__init__.py », line 168, in init_logging
configure_logging(logging_configuration)
File « /usr/lib/python3/dist-packages/moulinette/utils/log.py », line 67, in configure_logging
dictConfig(logging_config)
File « /usr/lib/python3.9/logging/config.py », line 809, in dictConfig
dictConfigClass(config).configure()
File « /usr/lib/python3.9/logging/config.py », line 571, in configure
raise ValueError(‘Unable to configure handler ‘
ValueError: Unable to configure handler ‘api’
dpkg: error processing package yunohost (–configure):
installed yunohost package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
yunohost
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@toto:~#

L’info importante est ici :

ValueError: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 152 from C header, got 40 from PyObject

En comparant pip et dpkg, il y a une différence de version :

root@toto:/var/log/apt# pip3 list | grep greenlet
greenlet               3.0.3
root@toto:/var/log/apt# dpkg –list | grep greenlet
ii  python3-greenlet                      0.4.17-1+b1                                        amd64        Lightweight in-process concurrent programming (python3)

Solution : Désinstaller la version pip :

root@toto:~# pip uninstall greenlet
Found existing installation: greenlet 3.0.3
Uninstalling greenlet-3.0.3:
Would remove:
/usr/local/include/python3.9/greenlet/greenlet.h
/usr/local/lib/python3.9/dist-packages/greenlet-3.0.3.dist-info/*
/usr/local/lib/python3.9/dist-packages/greenlet/*
Proceed (y/n)? y
Successfully uninstalled greenlet-3.0.3
root@toto:~#

La mise à jour passe sans souci ensuite.

source :
https://forum.yunohost.org/t/python-error-on-all-yunohost-commands-and-webadmin/28506

The post Yunohost mise à jour impossible first appeared on Gagzen.

Quelques commandes que je cherche à chaque fois que j’en ai besoin.

Voir le contenu d’un mail dans la queue :
postcat -q 74B394009B

Supprimer un message spécifique :
postsuper -d 74B394009B

Forcer l’envoi des messages :
postqueue -f

Supprimer les messages en deferred :
postsuper -d ALL deferred

Lister les message deferred :
postqueue -p

sources :

Gestion des messages sortants de Postfix (queues)

https://blog.valouille.fr/2014/04/commandes-utiles-pour-postfix/

The post Quelques commandes Postfix first appeared on Gagzen.

Enfin restart du serveur web ou du fpm, selon le cas.

The post SignaturePDF : Augmenter le nombre de pages max first appeared on Gagzen.

cp -p /var/lib/pgsql/data/pg_hba.conf /root/

dnf install postgresql-server postgresql-upgrade

systemctl stop postgresql.service

dnf module disable postgresql:10

dnf module enable postgresql:12

yum update

mv /var/lib/pgsql/data/pg_hba.conf /var/lib/pgsql/data/pg_hba.conf_new

postgresql-setup –upgrade

cp -p /root/pg_hba.conf /var/lib/pgsql/data

systemctl start postgresql.service

cd /opt/netbox/

git checkout master

git pull origin master

export NETBOX_DELETE_LEGACY_DATA=1

./upgrade.sh

systemctl restart netbox netbox-rq

The post Mise à jour Netbox depuis git avec montée de version Postgresql sur CentOS 8 first appeared on Gagzen.

Lors de la préparation de plusieurs ordinateurs d’une salle de cours, j’ai eu besoin de préparer des sessions invités sur des ordinateurs en LMDE5.

Depuis quelques temps, les distributions ne semblent plus proposer l’option de session invité, ou session éphémère, pour la quelle tout des données disparaissent une fois la session fermée.

Voici donc les commandes permettant la mise en place d’une telle session :

La dernière commande pourra être adaptée en fonction des erreurs dans la syslog.

Source : forums, mais je ne retrouve plus lesquels…

The post Session Invité pour Debian(-like) first appeared on Gagzen.