benevoles:technique:yunohost_mutu
Table des matières
Sans-nuage.fr
ARN propose à ses membres un compte sur une instance YunoHost mutualisée sans-nuage.fr (anciennement hub.netlib.re ) .
Sur cette même instance se trouve la carte wifi-with-me dédié à la collecte des données géographique des personnes intéressées par le projet ( wifi.arn-fai.net )
Aujourd'hui, les services sans-nuage.fr, sont décomposés en 2 serveurs, pour éviter les conflits entre app et diminuer l'impact d'une panne:
- les services en accès libres sur public.sans-nuage.fr
- les services réservés aux membres sur sans-nuage.fr
Provisionnement d'un compte sans-nuage.fr
Voici comment un
Base de données de MDP (keepassXC ou firefox avec mdp fort)
Ordi sous linux
Expliquer l'architecture de l'infra https://wiki.arn-fai.net/benevoles:technique
- Le serveur sans-nuage qui est une VM YunoHost sur le cluster
- La VM qui héberge le site web COIN (interface utilisateur et administrateur)
Créer un compte sur le wiki avec des droits user https://wiki.arn-fai.net/benevoles:technique:yunohost_mutu
Donner des droits superutilisateur sur COIN https://adherents.arn-fai.net/admin/
Pour la procédure, il faut :
- Administrateur / Modérateur de COIN
- Gestion d'utilisateur au minima sur NextCloud
Provisionnement de compte - Découverte de COIN
- Toute demande de service réalisée depuis l'espace adhérent de COIN (https://adherents.arn-fai.net)) est catégorisé dans la section "Services>Demandes" dans l'administration de COIN (https://adherents.arn-fai.net/admin))
- Une notification est envoyée sur le Forum "Nouvelle demande de *** pour un compte sans-nuage" avec un lien de la requête dans l'administration de COIN.
- BUG : **Le lien de la requête n'est pas cliquable" sur le forum car retour à la ligne.
- Cliquer sur "Accepter"
- BUG : quand on valide un sous-compte Asso, par défaut le compte prends le nom du groupe
- FEATURE REQUEST : "Accepter \& Provisionner" n'est pas encore fonctionnel car il faut d'abord vérifier que le pseudo est correct. Feature 1) : demander ET VERIFIER (règle des comptes yunohost) le pseudo du compte sans-nuage dans le formulaire de création du service. Dans le cas des abonnements asso supplémentaires, pour l'instant c'est le nom de l'asso nom_asso qui est ajouté. Dans le cas d'un abonnement asso principal, c'est nom_asso_admin. Feature 2) : demander le Nom Complet (Prénom Nom) du compte supplémentaire pour qu'il soit correctement renseigné dans le compte YunoHost.
- Quand la demande est acceptée, cela créé un abonnement, et démarre donc une facturation (généralement 0€/an, sauf pour le compte asso principal et compte famille supplémentaire).
- Un abonnement créé, créé une configuration de service "Compte externe" = Compte sans-nuage.fr
- Aller dans la section "Configurations>Comptes Externes"
- Cliquer sur le service lié à l'abonnement qu'on vient de créer.
- Vérifier les données, surtout que le pseudo ne comporte que des "lettres", des "chiffres" et éventuellement un "_" (voir les règles des comptes YunoHost) puis cliquer sur "Provisionner"
- Cela prend un peu de temps en raison d'un timeout qui attend la bonne exécution du script de création d'user dans le serveur sans-nuage.fr (YunoHost)
- BUG : Une erreur 504 peut survenir, le lien de redirection ne pointe pas vers le nouveau service provisionné mais vers une URL invalide. Peut-être parce-que le service n'est pas provisionné avant le timout.
- Retourner dans la fiche du service ("Configurations>Comptes Externes") : Au bout de 5 minutes le service doit apparaître comme running (vert)
- BUG : le quota nextcloud n'est pas correctement configuré, il faut se rendre sur nextcloud pour le configurer. Voir prochaine section.
- Pour corriger, il faut modifier la commande occ dans le script (post-install) de provisionnement de compte externe sur la VM de COIN (ext)
- FEATURE REQUEST : définir le quota automatiquement en fonction du type d'abonnement souscrit
- Prévenir sur le forum que le compte a été créé !
Modification du quota Nextcloud - Administration Nextcloud
- Aller sur l'interface admin>users https://sans-nuage.fr/file/settings/users
- Cliquer sur le stylo pour modifier
- Le quota par défaut est 1M. Vérifier le quota
- 3GB pour un compte individuel (quota mail + quota nextcloud = 5GB)
- 25GB pour un compte asso
- ne pas oublier de valider avec la coche à droite
- FEATURE REQUEST : Modifier le quota nextcloud par défaut à 50M et supprimer l'arborescence par défaut pour les nouveaux comptes pour enlever les docs par défaut (20M perdus). Mettre plutôt un README.txt vers de la doc' nextcloud sans-nuage.fr/file
Modification de compte YunoHost et nom sur Nextcloud - Pistes de debug du provisionnement sans-nuage.fr
- BUG : Si les utilisateurs modifient leur "Nom Complet" dans "Editer mon Profil" sur https://sans-nuage.fr/yunohost/sso/edit.html , celui-ci n'est pas répercuté sur Nextcloud
- CONTOURNEMENT : Si un Admin modifie le compte YunoHost directement, comme ci-dessous, le nom est bien répercuté sur Nextcloud (grâce à une tâche Cron).
- se connecter au serveur sans-nuage.fr (interface administrateur YunoHost) https://sans-nuage.fr/yunohost/admin/
- vérifier si l'utilisateur est bien créé -> https://sans-nuage.fr/yunohost/admin/#/users
- d'ici on peut modifier le quota email, adresse email principale, alias, redirection, nom complet (Prénom, Nom),
- FEATURE REQUEST : Feature 2) : demander le Nom Complet (Prénom Nom) du compte supplémentaire Asso pour qu'il soit correctement renseigné dans le compte YunoHost dès la création.
Modification de mot-de-passe par un administrateur
- FEATURE REQUEST (YunoHost) : Le MDP sans-nuage (compte user YunoHost) ne peut être récupéré en autonomie,
CONTOURNEMENT : seul un admin peut le modifier et le transmettre de manière sécurisée en suivant cette procédure
La modification se passe sur https://sans-nuage.fr/yunohost/admin/#/users/
- Et l'envoi de MDP sécurisé c'est 1) uploader le fichier sur smalldrop.sans-nuage.fr en cochant "expiration après le premier téléchargement" 2) copier le lien dans le champ commentaire de l'abonnement adherents.arn-fai.net/admin/external_account 3) prévenir la personne par mail où elle peut récupérer son MDP et préciser qu'il faut IMPERATIVEMENT qu'elle le change par un suffisamment sécurisé qu'elle seule connait. Par exemple >12 caractères avec majuscules, minuscules, chiffres, et caractères spéciaux
Pour séparer/rattacher un compte d'un groupe/asso
- Dans la fiche abonnement sur COIN changer nom de membre et l'offre
- Dans Yunohost détacher le compte du groupe
- Dans Nextcloud changer le quota si nécessaire
Suppression
- Bien s'assurer que la personne est OK car suppression totale des données personnelles
- Sur la fiche du membre dans Yunohost : delete en cochant bien la case pour purger les données personnelles
- Dans COIN : supprimer l'abonnement après avoir renseigné la date de résiliation et enregistrer/valider
Lufi
Retirer un contenu illégal de lufi
- S'assurer que la demande est légitime du point de vue de la lois. Consulter le CA pour valider le retrait (sauf si le délais légal ne le permet pas si ça s'appuie sur le retrait en 1h décidé par l'UE)
- Se connecter sur sans-nuage.fr
- Déplacer la clé du fichier dans /root/legal . Exemple avec un lien https://drop.sans-nuage.fr/r/UBERwJ5g9e
mv /var/www/lufi__3/files/UBERwJ5g9e /root/legal/lufi__3/
- Se connecter à postgresql et indiquer le contenu comme illégal
sudo -u postgres psql \c lufi__3 UPDATE files SET abuse=1 files WHERE short='UBERwJ5g9e';
- Demander au CA si il faut mettre à jour la liste des requêtes de demandes de retrait
Nextcloud
Faire le ménage dans les comptes nextcloud
Quand on supprime un compte sur YunoHost, le compte Nextcloud reste présent (bien qu'il ne soit plus utilisable). Pour faire le ménage:
sudo -u nextcloud /usr/bin/php7.3 --define apc.enable_cli=1 /var/www/nextcloud/occ ldap:show-remnants
Là il faut faire le tris et vérifier celleux qu'il faut supprimer
sudo -u nextcloud /usr/bin/php7.3 --define apc.enable_cli=1 /var/www/nextcloud/occ user:delete ljf2
Bug synchro Nom LDAP / Nom Nextcloud
Si le nom d'affichage est changé dans YunoHost, celui-ci n'est pas répercuté dans Nextcloud, c'est un problème de synchro LDAP. https://github.com/YunoHost-Apps/nextcloud_ynh/issues/49
J'ai ajouté un petit script qui se lance chaque jour pour contrer ce problème, de cette façon les utilisateurices peuvent modifier leur nom dans le SSO YunoHost. /usr/local/bin/sync_nextcloud_ldap
#!/bin/bash
for username in $(yunohost user list --fields username | grep " username:" | sed "s/ username: //g") ; do
fullname="$(yunohost user info $username | grep fullname | sed "s/fullname: //")"
fullname2="$(sudo -u nextcloud /usr/bin/php7.3 --define apc.enable_cli=1 /var/www/nextcloud/occ user:setting $username settings display_name)"
if [[ "$fullname" != "$fullname2" ]] ; then
sudo -u nextcloud /usr/bin/php7.3 --define apc.enable_cli=1 /var/www/nextcloud/occ user:setting $username settings display_name "$fullname"
fi
done
Il faut ajouter les droits sur le script
chmod u+x /usr/local/bin/sync_nextcloud_ldap
Et mettre un cron (ici tous les jours à 7h12)
/etc/cron.d/sync_nextcloud_ldap
12 7 * * * root /usr/local/bin/sync_nextcloud_ldap
Etherpad
Diminuer la taille de la base de donnée
Si vous avez un problème de taille de base de données etherpad: https://github.com/YunoHost-Apps/etherpad_mypads_ynh/issues/188
Matrix
Problème de mot de passe dans Element
Une fois connecté sur Element, certaines opérations nécessitent de re-rentrer son mdp. Il semble que cette demande de mdp ne soit pas implémenté en CAS. Du coup le mdp échoue.
Contournement :
- se connecter à synapse-admin, section User https://synadmin.sans-nuage.fr/#/users
- Sélectionner l'utilisateur > authentification unique
- Noter le pseudo, Supprimer CAS
- Dans "Adresse électronique" Ajouter adresse mail pseudo@sans-nuage.fr
- Demander à l'utilisateur de reset son mdp
- Mets toi en navigation privée sur firefox
- va sur chat.sans-nuage.fr
- cliques sur "mot de passe oublié ?"
- via le mail reçu sur ta boite mail @sans-nuage.fr, définis le même mdp que ton compte sans-nuage.fr
- Et là dans l'idéal tu remets le même MDP que ton MDP sans-nuage
- Remettre CAS avec le pseudo
Nettoyer la base de données
Niveau 1 - via l'interface web Synapse Admin
- Donner des droits administrateur à votre compte matrix sans-nuage.fr permet de vous connecter à https://synadmin.sans-nuage.fr/ pour faire des actions d'administration basiques. Ca passe directement par une requête dans la BDD postgresql matrix_synapse :
su --command="psql matrix_synapse" postgres <<< "UPDATE users SET admin = 1 WHERE name = '@user:sans-nuage.fr'" - Vous pouvez par exemple supprimer les comptes invité plus vieux qu'une semaine
- Afficher 50 lignes par pages
- Sélectionner tout
- "effacer les données de l'utilisateur"
Niveau 2 utilisation de l'API d'administration synadm
- Se connecter en tant que admin_ghentz pour avoir accès à l'API synadm ou configurer son propre path comme suit
- Ensuite aller dans votre client Element pour récupérer un jeton pour l'API synapse
- Tout en bas des paramètres, section
Aide et A propos>Advanced>jeton d'accès
- Ajouter les variables suivantes à votre path :
export SYNAPSE_HS=matrix.sans-nuage.fr export SYNAPSE_TOKEN=le_jeton_recupere
Opérations de nettoyage \c matrix_synapse copy (select room_id, count(*) as cnt from events group by room_id order by cnt desc) to '/tmp/rooms_to_clean' csv; SELECT room_id, stream_ordering, COUNT(event_id) AS c FROM events GROUP BY room_id, stream_ordering ORDER BY c DESC;
SELECT nspname || '.' || relname AS "relation",
pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN ('pg_catalog', 'information_schema')
AND C.relkind <> 'i' AND nspname !~ '^pg_toast'
ORDER BY pg_total_relation_size(C.oid) DESC LIMIT 20;
jq -r '.rooms | map(select(.creator == "@signalbot:sans-nuage.fr")) | .[].room_id' < rooms.json | xargs -ti $SHELL -ic 'synadm POST '"'"'v1/purge_history/{}'"'"' -d '"'"'{"purge_up_to_ts":'"$(date -d-365days +%s000)"'}'"'"
jq -r '.rooms | map(select(.creator == "@whatsappbot:sans-nuage.fr")) | .[].room_id' < rooms.json | xargs -ti $SHELL -ic 'synadm POST '"'"'v1/purge_history/{}'"'"' -d '"'"'{"purge_up_to_ts":'"$(date -d-365days +%s000)"'}'"'"
SELECT FROM state_groups_state LIMIT 5; SELECT COUNT() as nb FROM state_groups_state LIMIT 5; SELECT COUNT(*) as nb FROM state_groups_state;
REINDEX DATABASE CONCURRENTLY matrix_synapse; ou REINDEX DATABASE matrix_synapse;
VACUUM ou VACUUM FULL; semblent avoir le même résultat \q
Autres commandes utiles :
su -c /usr/bin/psql postgres synadm GET 'v2/users?name=bot' | jq postgres=# SELECT pg_size_pretty( pg_database_size( 'matrix_synapse' ) );
full log
122 synadm POST "v1/purge_media_cache?before_ts=$(date -d-60days +%s000)"
123 synadm POST "v1/purge_media_cache?before_ts=$(date -d-30days +%s000)"
124 df -h
125 synadm POST "v1/media/delete?before_ts=$(date -d-900days +%s000)"
126 df -h
127 synadm POST "v1/media/delete?before_ts=$(date -d-899days +%s000)"
128 df -h
129 synadm POST "v1/media/delete?before_ts=$(date -d-800days +%s000)"
130 df -h
131 synadm POST "v1/media/delete?before_ts=$(date -d-700days +%s000)"
132 df -h
133 synadm POST "v1/media/delete?before_ts=$(date -d-600days +%s000)"
134 df -h
135 synadm POST "v1/media/delete?before_ts=$(date -d-500days +%s000)"
136 df -h
137 synadm POST "v1/media/delete?before_ts=$(date -d-500days +%s000)"
138 df -h
139 synadm POST "v1/media/delete?before_ts=$(date -d-400days +%s000)"
140 synadm POST "v1/media/delete?before_ts=$(date -d-450days +%s000)"
141 synadm POST "v1/media/delete?before_ts=$(date -d-400days +%s000)"
142 df -h
143 synadm POST "v1/media/delete?before_ts=$(date -d-365days +%s000)"
144 df -h
145 synadm GET 'v1/rooms?limit=999999' > rooms.json
146 jq '.rooms | map(select(.joined_local_members == 0))' < rooms.json
147 nano rooms.json
148 jq '.rooms | map(select(.joined_local_members == 0)) | map(.state_events) | add' < rooms.json
149 df -h
150 synadm GET 'v1/rooms?limit=500' > rooms.json
151 jq '.rooms | map(select(.joined_local_members == 0))' < rooms.json
152 synadm GET 'v1/rooms?limit=5000' > rooms.json
153 jq '.rooms | map(select(.joined_local_members == 0))' < rooms.json
154 synadm GET 'v1/rooms?limit=1000' > rooms.json
155 synadm GET 'v1/rooms?limit=2000' > rooms.json
156 synadm GET 'v1/rooms?limit=1000' > rooms.json
157 jq '.rooms | map(select(.joined_local_members == 0))' < rooms.json
158 nano rooms.json
159 jq -r '.rooms | map(select(.joined_local_members == 0)) | .[].room_id' < rooms.json | xargs -ti synadm DELETE '
v1/rooms/{}' -d '{"purge": true}'
160 synadm POST "v1/purge_media_cache?before_ts=$(date -d-30days +%s000)"
161 nano rooms.json
162 sudo su
163 exit
164 tmux a
165 sudo su
166 df -h
167 lsblk
168 fdisk -l
169 sudo fdisk -l
170 dfc -Taisob
185 synadm GET 'v1/rooms?limit=999999' > rooms.json
186 jq '.rooms | map(select(.joined_local_members == 0)
187 nano rooms.json
188 sudo su
189 synadm -o json room list -s joined_local_members -r -l 500 | jq -r '.rooms[] | select(.joined_local_members ==
0) | .room_id'
190 synadm POST "v1/purge_media_cache?before_ts=$(date -d-30days +%s000)"
191 history | grep synadm
192 synadm GET v2/users/@gauthier67:sans-nuage.fr | jq
193 synadm GET 'v1/rooms?limit=500' > rooms.json
194 nano rooms.json
195 exit
196 tmux a
197 tmux
198 exit
199 sudo su
200 exit
201 sudo su
202 jq -r '.rooms | map(select(.joined_local_members == 0)) | .[].room_id' < rooms.json | xargs -ti synadm DELETE '
v1/rooms/{}' -d '{"purge": true}'
203 source .bashrc
204 jq -r '.rooms | map(select(.joined_local_members == 0)) | .[].room_id' < rooms.json | xargs -ti synadm DELETE '
v1/rooms/{}' -d '{"purge": true}'
205 nano .bashrc
206 source .bashrc
207 synadm GET v2/users/@gauthier67:sans-nuage.fr | jq
208 jq -r '.rooms | map(select(.joined_local_members == 0)) | .[].room_id' < rooms.json | xargs -ti synadm [0/1972]
v1/rooms/{}' -d '{"purge": true}'
209 nano rooms.json
210 history | grep synadm
211 synadm POST "v1/media/delete?before_ts=$(date -d-365days +%s000)"
212 synadm POST "v1/media/delete?before_ts=$(date -d-465days +%s000)"
213 synadm POST "v1/media/delete?before_ts=$(date -d-365days +%s000)"
214 synadm POST "v1/media/delete?before_ts=$(date -d-400days +%s000)"
215 synadm POST "v1/media/delete?before_ts=$(date -d-430days +%s000)"
216 synadm POST "v1/media/delete?before_ts=$(date -d-400days +%s000)"
217 synadm POST "v1/media/delete?before_ts=$(date -d-365days +%s000)"
218 synadm POST "v1/purge_media_cache?before_ts=$(date -d-300days +%s000)"
219 synadm POST "v1/purge_media_cache?before_ts=$(date -d-200days +%s000)"
220 synadm POST "v1/purge_media_cache?before_ts=$(date -d-100days +%s000)"
221 synadm POST "v1/purge_media_cache?before_ts=$(date -d-150days +%s000)"
222 synadm POST "v1/purge_media_cache?before_ts=$(date -d-100days +%s000)"
223 synadm POST "v1/purge_media_cache?before_ts=$(date -d-70days +%s000)"
224 synadm POST "v1/purge_media_cache?before_ts=$(date -d-30days +%s000)"
225 synadm GET 'v1/rooms?limit=999999' > rooms.json
226 jq '.rooms | map(select(.joined_local_members == 0))' < rooms.json
227 jq '.rooms | map(select(.joined_local_members == 0)) | map(.state_events) | add' < rooms.json
228 jq -r '.rooms | map(select(.joined_local_members == 0)) | .[].room_id' < rooms.json | xargs -ti synadm DELETE '
v1/rooms/{}' -d '{"purge": true}'
229 xargs --help
230 jq -r '.rooms | map(select(.joined_local_members == 0)) | .[].room_id' < rooms.json | xargs -ti synadm DELETE '
v1/rooms/{}' -d '{"purge": true}'
231 history | grep psql
232 psql
233 synadm GET 'v1/rooms?limit=999999' > rooms.json
234 nano rooms.json
235 jq -r '.rooms | map(select(.joined_local_members == 0)) | .[].room_id' < rooms.json | xargs -ti $SHELL -ic "syn
adm DELETE 'v1/rooms/{}' -d '{\"purge\": true}'"
236 nano /tmp/rooms_to_clean
237 head -n 20 /tmp/rooms_to_clean | cut -d, -f1 | xargs -ti $SHELL -ic 'synadm POST \'v1/purge_history/{}\' -d "{\
"purge_up_to_ts\":$(date -d-365days +%s000)}"'
\q
238 head -n 20 /tmp/rooms_to_clean | cut -d, -f1 | xargs -ti $SHELL -ic 'synadm POST '"'"'v1/purge_history/{}'"'"'
-d '"'"'{"purge_up_to_ts":'"$(date -d-30days +%s000)"'}'"'"
239 nano /tmp/rooms_to_clean
240 jq -r '.rooms | map(select(.creator == \"@whatsappbot:sans-nuage.fr\")) | .[].room_id' < rooms.json
241 jq -r '.rooms | map(select(.creator == "@whatsappbot:sans-nuage.fr")) | .[].room_id' < rooms.json
242 jq -r '.rooms | map(select(.creator == "@whatsappbot:sans-nuage.f")) | .[].room_id' < rooms.json
243 jq -r '.rooms | map(select(.creator == "@signalbot:sans-nuage.fr")) | .[].room_id' < rooms.json
244 jq -r '.rooms | map(select(.creator == "@whatsappbot:sans-nuage.fr")) | .[].room_id' < rooms.json | xargs -ti $
SHELL -ic 'synadm POST \'v1/purge_history/{}\' -d "{\"purge_up_to_ts\":$(date -d-365days +%s000)}"'
245 jq -r '.rooms | map(select(.creator == "@whatsappbot:sans-nuage.fr")) | .[].room_id' < rooms.json | xargs -ti $
SHELL -ic "synadm POST 'v1/purge_history/{}' -d '{"'"'"purge_up_to_ts"'"'":"'"'"$(date -d-365days +%s000)"'"'"}'"
246 jq -r '.rooms | map(select(.creator == "@whatsappbot:sans-nuage.fr")) | .[].room_id' < rooms.json | xargs -ti $
SHELL -ic 'synadm POST '"'"'v1/purge_history/{}'"'"' -d '"'"'{"purge_up_to_ts":'"$(date -d-365days +%s000)"'}'"'"
247 jq -r '.rooms | map(select(.creator == "@signalbot:sans-nuage.fr")) | .[].room_id' < rooms.json | xargs -ti $SH
ELL -ic 'synadm POST '"'"'v1/purge_history/{}'"'"' -d '"'"'{"purge_up_to_ts":'"$(date -d-365days +%s000)"'}'"'"
Conflit APT entre mobilizon et onlyoffice
OBSOLETE (mobilizon_ynh utilise maintenant des versions précompilées)
En deux mot : rabbitmq-server dépends de pleins de trucs en erlang (des dépôts debian vanilla) … et Mobilizon dépends de erlang, mais d'une version d'un dépot tier. Le tout résulte en un tas de conflit relou.
Une explication / solution possible est de bricoler le fichier control du .deb de esl-erlang (voulu par Mobilizon) pour donner des versions explicites aux paquets dans “Provides”
cd /root/ mkdir hack_esl_erlang_for_compat_with_rabbitmq apt download esl-erlang cp esl-erlang_1%3a23.1-1_amd64.deb esl-erlang_1%3a23.1-1_amd64.deb.original ar x esl-erlang_1%3a23.1-1_amd64.deb tar -xvf control.tar.xz vim ./control
Dans le fichier, on ajoute “+arnhack” à la version du paquet, et la liste des Provides devient (N.B. : si nécessaire dans le futur, adapter les numéros de version of course…) :
Provides: erlang-abi-17.0 (= 1:23.1-1), erlang-base-hipe (= 1:23.1-1), erlang-dev (= 1:23.1-1), erlang-appmon (= 1:23.1-1), erlang-asn1 (= 1:23.1-1), erlang-common-test (= 1:23.1-1), erlang-corba (= 1:23.1-1), erlang-crypto (= 1:23.1-1), erlang-debugger (= 1:23.1-1), erlang-dialyzer (= 1:23.1-1), erlang-docbuilder (= 1:23.1-1), erlang-edoc (= 1:23.1-1), erlang-eldap (= 1:23.1-1), erlang-erl-docgen (= 1:23.1-1), erlang-et (= 1:23.1-1), erlang-eunit (= 1:23.1-1), erlang-gs (= 1:23.1-1), erlang-ic (= 1:23.1-1), erlang-inets (= 1:23.1-1), erlang-inviso (= 1:23.1-1), erlang-megaco (= 1:23.1-1), erlang-mnesia (= 1:23.1-1), erlang-observer (= 1:23.1-1), erlang-odbc (= 1:23.1-1), erlang-os-mon (= 1:23.1-1), erlang-parsetools (= 1:23.1-1), erlang-percept (= 1:23.1-1), erlang-pman (= 1:23.1-1), erlang-public-key (= 1:23.1-1), erlang-reltool (= 1:23.1-1), erlang-runtime-tools (= 1:23.1-1), erlang-snmp (= 1:23.1-1), erlang-ssh (= 1:23.1-1), erlang-ssl (= 1:23.1-1), erlang-syntax-tools (= 1:23.1-1), erlang-test-server (= 1:23.1-1), erlang-toolbar (= 1:23.1-1), erlang-tools (= 1:23.1-1), erlang-tv (= 1:23.1-1), erlang-typer (= 1:23.1-1), erlang-webtool (= 1:23.1-1), erlang-wx (= 1:23.1-1), erlang-xmerl (= 1:23.1-1)
puis mettre à jour le .deb avec le nouveau fichier:
rm -f control.tar control.tar.xz tar -cvf control.tar control xz control.tar ar r esl-erlang_1%3a23.1-1_amd64.deb control.tar.xz
Et on peut ensuite faire :
dpkg -i esl-erlang_1%3a23.1-1_amd64.deb
benevoles/technique/yunohost_mutu.txt · Dernière modification : 2024/04/16 10:39 de scapharnaum