Logiciels » Autres logiciels [Réglé] Akonadi / Kalarm : lubuntu 20.04
Reprise du message précédent
Papoteur :
je ne sais pas lequel utilise Lubuntu
Les versions récentes de Lubuntu utilisent LXQT. Pour un vieil ordinateur, il est préférable d'utiliser Debian ou Mageia avec LXDE (GTK2).
Ubuntu utilise Apparmor. Mageia est un MSEC qui peut être désactivé.
bisane :
Je viens juste de voir !
J'ai compris avant de poster mon avant-dernier message, et espère l'avoir "bien" fait, mais je n'ai pas trouvé de balise "code"... donc je tape à la main...
bisane :
Edit jybz : remplacement des balises block par code.
Je viens juste de voir !
J'ai compris avant de poster mon avant-dernier message, et espère l'avoir "bien" fait, mais je n'ai pas trouvé de balise "code"... donc je tape à la main...
Oui, personne ne le vois. C'est le symbole </>
nic80 :
@bisane: que donne la commande "sudo journalctl -b 0 | grep apparmor | grep mysql" ?
Ca :
Code :
bisane@bisane:~$ sudo journalctl -b 0 | grep apparmor | grep mysql
[sudo] Mot de passe de bisane :
nov. 11 17:20:05 bisane audit[725]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="mysqld_akonadi" pid=725 comm="apparmor_parser"
nov. 11 17:20:05 bisane kernel: audit: type=1400 audit(1605111605.812:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="mysqld_akonadi" pid=725 comm="apparmor_parser"
nov. 11 17:20:06 bisane kernel: audit: type=1400 audit(1605111605.928:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/mysqld" pid=729 comm="apparmor_parser"
nov. 11 17:20:05 bisane audit[729]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/mysqld" pid=729 comm="apparmor_parser"
nov. 11 17:21:28 bisane audit[1869]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/home/bisane/" pid=1869 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
nov. 11 17:21:28 bisane kernel: audit: type=1400 audit(1605111688.037:36): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/home/bisane/" pid=1869 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
nov. 11 17:21:28 bisane audit[1870]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/home/bisane/.local/share/akonadi/mysql.conf" pid=1870 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
nov. 11 17:21:28 bisane kernel: audit: type=1400 audit(1605111688.069:37): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/home/bisane/.local/share/akonadi/mysql.conf" pid=1870 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
magnux77 :
Après avoir judicieusement choisi LXDE comme environnement graphique via Lubuntu "pour un vieux notebook qui avait peu de ressources", pourquoi installer les composants KDE Plasma (korganizer, kalarm) propres à étouffer ce bon vieux notebook ? C'est surprenant, je me demande même pourquoi mes collègues ne sont pas surpris ?
Je ne me rappelle pas avoir précisément installé ces composants... ça doit remonter à quelque temps !
Quoi qu'il en soit, j'ai "harmonisé" les environnements sur le notebook et mon PC, et là, je suis sur le PC. C'est sur celui-ci que j'ai Kalarm, pas sur le notebook, que je n'ai pas encore upgradé vers la 20.04.
arte-naki :
Les versions récentes de Lubuntu utilisent LXQT. Pour un vieil ordinateur, il est préférable d'utiliser Debian ou Mageia avec LXDE (GTK2).
Je ne me sens pas vraiment prête à tout recommencer à 0...
Thunderbird ne propose pas du tout les mêmes fonctionnalités que Kalarm, en tout cas pour ce pour quoi je l'utilise...
magnux77 :
Enfin, petite précision, Mageia, contrairement à Ubuntu, ne deale pas avec Microsoft.
Ce qui signifie, en clair ?
![:]](/images/smileys/8.gif ":]")
Je ne comprends pas tout à vos échanges, nic80 et jybz, mais je vais de ce pas regarder du côté des liens indiqués... sachant que je suis une truffe en anglais, pour arranger le tout !
Bonjour,
Dans la partie log, on voit que apparmor bloque l' accès au travers du profile.
Pour test il faudrait désactiver le profile /usr/bin/mysqld avec la commande
apparmor_parser -R /etc/apparmor.d/<profile>
Aprés je ne sais pas ce que contient le répertoire /etc/apparmor.d/ (que donne un "ls -al /etc/apparmor.d/" ? Edité par nic80 Le 11/11/2020 à 18h13
Dans la partie log, on voit que apparmor bloque l' accès au travers du profile.
Citation :
.nov. 11 17:21:28 bisane audit[1870]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/home/bisane/.local/share/akonadi/mysql.conf" pid=1870 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Pour test il faudrait désactiver le profile /usr/bin/mysqld avec la commande
apparmor_parser -R /etc/apparmor.d/<profile>
Aprés je ne sais pas ce que contient le répertoire /etc/apparmor.d/ (que donne un "ls -al /etc/apparmor.d/" ? Edité par nic80 Le 11/11/2020 à 18h13
Bonjour,
Bien évidemment, la désactivation que j' ai indiqué précédément est en principe temporaire (le temps de tester). Si apparmor est là, c' est qu' il y a une raison !
Le ls est là pour savoir ce qu' il y a dans le répertoire (parce que je doute qu' il y ai /usr/bin/mysqld en tant que fichier !) Edité par nic80 Le 11/11/2020 à 18h17
Bien évidemment, la désactivation que j' ai indiqué précédément est en principe temporaire (le temps de tester). Si apparmor est là, c' est qu' il y a une raison !
Le ls est là pour savoir ce qu' il y a dans le répertoire (parce que je doute qu' il y ai /usr/bin/mysqld en tant que fichier !) Edité par nic80 Le 11/11/2020 à 18h17
Tu continues à me parler chinois, nic, mais je continue à faire ce que tu me dis...
Juste, avant, je copie ceci, extrait de ce post :
Ceci :
Si j'essaie sans <profile>, ça donne ça :
Avant d'enlever un profil quelconque, j'aimerais bien savoir s'il est possible de le récupérer et comment !
Juste, avant, je copie ceci, extrait de ce post :
Code BASH :
bisane@bisane:~$ sudo /etc/init.d/apparmor status -l ● apparmor.service - Load AppArmor profiles Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled) Active: active (exited) since Wed 2020-11-11 17:20:06 CET; 1h 21min ago Docs: man:apparmor(7) https://gitlab.com/apparmor/apparmor/wikis/home/ Process: 699 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS) Main PID: 699 (code=exited, status=0/SUCCESS) nov. 11 17:20:04 bisane systemd[1]: Starting Load AppArmor profiles... nov. 11 17:20:05 bisane apparmor.systemd[699]: Restarting AppArmor nov. 11 17:20:05 bisane apparmor.systemd[699]: Reloading AppArmor profiles nov. 11 17:20:05 bisane apparmor.systemd[718]: Skipping profile in /etc/appa…fox nov. 11 17:20:06 bisane apparmor.systemd[734]: Skipping profile in /etc/appa…ogd nov. 11 17:20:06 bisane systemd[1]: Finished Load AppArmor profiles. Hint: Some lines were ellipsized, use -l to show in full.
nic80 :
que donne un "ls -al /etc/apparmor.d/" ?
Ceci :
Code BASH :
bisane@bisane:~$ ls -al /etc/apparmor.d/ total 172 drwxr-xr-x 7 root root 4096 nov. 11 08:55 . drwxr-xr-x 167 root root 12288 nov. 11 10:22 .. drwxr-xr-x 4 root root 12288 oct. 3 10:39 abstractions drwxr-xr-x 2 root root 4096 sept. 2 2019 disable drwxr-xr-x 2 root root 4096 sept. 2 2019 force-complain -rw-r--r-- 1 root root 802 mars 22 2018 lightdm-guest-session drwxr-xr-x 2 root root 4096 nov. 8 19:06 local -rw-r--r-- 1 root root 1313 mai 19 18:59 lsb_release -rw-r--r-- 1 root root 1033 avril 15 2020 mysqld_akonadi -rw-r--r-- 1 root root 1108 mai 19 18:59 nvidia_modprobe -rw-r--r-- 1 root root 3222 mars 11 2020 sbin.dhclient drwxr-xr-x 5 root root 4096 oct. 3 10:04 tunables -rw-r--r-- 1 root root 11082 juil. 7 15:20 usr.bin.evince -rw-r--r-- 1 root root 8493 juin 3 17:08 usr.bin.firefox -rw-r--r-- 1 root root 3202 févr. 25 2020 usr.bin.man -rw-r--r-- 1 root root 1519 août 14 2019 usr.lib.libreoffice.program.oosplash -rw-r--r-- 1 root root 1227 août 25 00:58 usr.lib.libreoffice.program.senddoc -rw-r--r-- 1 root root 10653 août 25 00:58 usr.lib.libreoffice.program.soffice.bin -rw-r--r-- 1 root root 1046 août 25 00:58 usr.lib.libreoffice.program.xpdfimport -rw-r--r-- 1 root root 26307 oct. 8 09:30 usr.lib.snapd.snap-confine.real -rw-r--r-- 1 root root 5797 avril 24 2020 usr.sbin.cupsd -rw-r--r-- 1 root root 563 mars 5 2019 usr.sbin.haveged -rw-r--r-- 1 root root 672 févr. 19 2020 usr.sbin.ippusbxd -rw-r--r-- 1 root root 2006 oct. 22 15:19 usr.sbin.mysqld -rw-r--r-- 1 root root 1575 févr. 11 2020 usr.sbin.rsyslogd -rw-r--r-- 1 root root 1385 déc. 7 2019 usr.sbin.tcpdump
Code BASH :
bisane@bisane:~$ apparmor_parser -R /etc/apparmor.d/<profile> bash: erreur de syntaxe près du symbole inattendu « newline »
Si j'essaie sans <profile>, ça donne ça :
Code BASH :
bisane@bisane:~$ sudo apparmor_parser -R /etc/apparmor.d/ [sudo] Mot de passe de bisane : apparmor_parser : impossible de supprimer << firefox >>. Profil inexistant apparmor_parser : impossible de supprimer << /usr/sbin/rsyslogd >>. Profil inexistant
Avant d'enlever un profil quelconque, j'aimerais bien savoir s'il est possible de le récupérer et comment !
Bonjour,
En fait <profile>, c' est ce qui est indiqué dans la documentation.
Ici pour exclure mysql-akonadi et mysqld, je ferais :
apparmor_parser -R /etc/apparmor.d/mysqld_akonadi
Et
apparmor_parser -R /etc/apparmor.d/mysqld
Et ça pas en root si on veut que ce soit temporaire.
Edit: pour le désactiver completement, il faut creer un lien symbolique (donc en principe pas de raison que le test survive au redémarrage du pc sans ça. Edité par nic80 Le 11/11/2020 à 19h31
En fait <profile>, c' est ce qui est indiqué dans la documentation.
Ici pour exclure mysql-akonadi et mysqld, je ferais :
apparmor_parser -R /etc/apparmor.d/mysqld_akonadi
Et
apparmor_parser -R /etc/apparmor.d/mysqld
Edit: pour le désactiver completement, il faut creer un lien symbolique (donc en principe pas de raison que le test survive au redémarrage du pc sans ça. Edité par nic80 Le 11/11/2020 à 19h31
nic80 :
Bonjour,
En fait <profile>, c' est ce qui est indiqué dans la documentation.
Ici pour exclure mysql-akonadi et mysqld, je ferais :
apparmor_parser -R /etc/apparmor.d/mysqld_akonadi
Et
apparmor_parser -R /etc/apparmor.d/mysqld
Et ça pas en root si on veut que ce soit temporaire.
Edit: pour le désactiver completement, il faut creer un lien symbolique (donc en principe pas de raison que le test survive au redémarrage du pc sans ça.
En fait <profile>, c' est ce qui est indiqué dans la documentation.
Ici pour exclure mysql-akonadi et mysqld, je ferais :
apparmor_parser -R /etc/apparmor.d/mysqld_akonadi
Et
apparmor_parser -R /etc/apparmor.d/mysqld
Edit: pour le désactiver completement, il faut creer un lien symbolique (donc en principe pas de raison que le test survive au redémarrage du pc sans ça.
1) si tu ne le fais pas en root, est-ce que ça sera accepté ?
2) comment ça, ça reste temporaire et ça ne survie pas au redémarrage ? on est dans /etc pas dans /dev ni /proc ou /tmp.
Je viens de comprendre en lisant :
http://www.linuxcertif.com/man/8/apparmor_parser/
et
https://wiki.debian.org/AppArmor/HowToUse
Ok, c'est chargé/déchargé, et on ne vient pas modifier les fichiers dans /etc. Donc tant qu'on utilise apparmor_parser, il n'y a aucune crainte.
http://www.linuxcertif.com/man/8/apparmor_parser/
et
https://wiki.debian.org/AppArmor/HowToUse
Citation :
List all loaded AppArmor profiles for applications and processes and detail their status (enforced, complain, unconfined):
$ sudo aa-status
$ sudo aa-status
Ok, c'est chargé/déchargé, et on ne vient pas modifier les fichiers dans /etc. Donc tant qu'on utilise apparmor_parser, il n'y a aucune crainte.
D'ailleurs :
https://wiki.debian.org/AppArmor/HowToUse#Diagnose_if_a_bug_might_have_been_caused_by_AppArmor
https://wiki.debian.org/AppArmor/HowToUse#Diagnose_if_a_bug_might_have_been_caused_by_AppArmor
Citation :
Diagnose if a bug might have been caused by AppArmor
Look in these logs for:
ALLOWED (logged when a profile in complain mode violates the policy)
DENIED (logged when a profile in enforce mode actually blocks an operation)
The full log message should provide more information on what exact access has been denied. You can use this to edit profiles before turning them on in enforce mode.
Sometimes, it's useful to disable a profile and to test again if the bug persists:
Look in these logs for:
ALLOWED (logged when a profile in complain mode violates the policy)
DENIED (logged when a profile in enforce mode actually blocks an operation)
The full log message should provide more information on what exact access has been denied. You can use this to edit profiles before turning them on in enforce mode.
Sometimes, it's useful to disable a profile and to test again if the bug persists:
Code BASH :
# disable a profile temporarily $ sudo aa-disable /etc/apparmor.d/usr.bin.example # after testing, re-enable it in complain mode $ sudo aa-complain /etc/apparmor.d/usr.bin.example # or in enforce mode $ sudo aa-enforce /etc/apparmor.d/usr.bin.example
Donc, pour tester de retirer un profile :
On suppose que ça marchera après cette commande. Ensuite, il faut savoir ce qu'il faut réparer du profile !
Je suppose que le mode "se plaindre" pourrait nous dire où est le problème :
Oh ! Je viens de lire juste au dessus :
Aha !
J'ai envie de dire... Mets à jour ?
Code BASH :
sudo aa-disable /etc/apparmor.d/mysqld_akonadi
On suppose que ça marchera après cette commande. Ensuite, il faut savoir ce qu'il faut réparer du profile !
Je suppose que le mode "se plaindre" pourrait nous dire où est le problème :
Code BASH :
sudo aa-complain /etc/apparmor.d/mysqld_akonadi
Oh ! Je viens de lire juste au dessus :
Citation :
To set a profile to enforce mode, use aa-enforce instead of aa-complain. Beware though: many profiles are not up-to-date and will break functionality in enforce mode, be ready to debug!
Aha !
J'ai envie de dire... Mets à jour ?
Bonjour,
D' ailleurs je me suis trompé...
Ce serait plus pour mysqld:
apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld
Bien entendu aprés ces commandes, il faudra essayer de redemarrer akonadi (pour voir)
Edit: je pense qu' il faut décharger les 2 (usr.sbin.mysqld et mysqld_akonadi), pas seulement mysqld_akonadi
Edité par nic80 Le 11/11/2020 à 19h54
D' ailleurs je me suis trompé...
Ce serait plus pour mysqld:
apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld
Bien entendu aprés ces commandes, il faudra essayer de redemarrer akonadi (pour voir)
Edit: je pense qu' il faut décharger les 2 (usr.sbin.mysqld et mysqld_akonadi), pas seulement mysqld_akonadi
Edité par nic80 Le 11/11/2020 à 19h54
bisane :
Je ne comprends pas tout à vos échanges, [...] !!!
Ah, désolé, a force d'être dans ce genre de cas, ou se déconnecte de la réalité et je ne comprends plus comment on ne peut pas comprendre ce qu'on dit.
Je ne connais pas AppArmor, mais voici comment je comprends les choses
https://fr.wikipedia.org/wiki/AppArmor
Lorsque "tu" (l'utilisateur 1000 autrement dénommé Bisane) demande à exécuter mysqld, le démon (processus serveur tournant en tâche de fond) du gestionnaire de la base de donnée Mysql, au lieu de l'exécuter bêtement, le système d'exploitation exécute AppArmor qui vient changer l'environnement et contrôler ce qui a le droit de se passer.
Apparmor se base sur des fichiers de profile dans /etc/apparmor.
Lorsque tu as fait une mise à jour, AppArmor a restreint les droits, ou a augmenté en sécurité, mais le profile n'aurait pas été mis à jour. Ainsi, lorsque tu demande à lancer l'application mysqld, il y a AppArmor qui vient se mettre en travers et refuse.
D'après le rapport de bogue trouvé par Nic80, je lis cette phrase :
Serhiy Ivanov :
The auto_installer under debian/ubuntu should be able to adjust apparmor settings for mysqld accordingly to manually chosen folder for configurations.
Si je comprends bien, lorsque Akonadi lance Mysqld (en fait un exécutable /sbin/akonadi-mysqld spécial),
bisane :
org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld-akonadi"
org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/bisane/.local/share/akonadi/mysql.conf", "--datadir=/home/bisane/.local/share/akonadi/db_data/", "--socket=/run/user/1000/akonadi/mysql.socket", "--pid-file=/run/user/1000/akonadi/mysql.pid")
org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/bisane/.local/share/akonadi/mysql.conf", "--datadir=/home/bisane/.local/share/akonadi/db_data/", "--socket=/run/user/1000/akonadi/mysql.socket", "--pid-file=/run/user/1000/akonadi/mysql.pid")
[EDIT] : il n'accepterait pas mysqld_akonadi (qui est /usr/sbin/mysqld_akonadi) et ça devrait être /usr/sbin/mysqld, voire plus loin. [ /EDIT]
Et peut-être que le profile de AppArmor ne le permet pas.
Ce n'est peut-être pas ça le problème, mais c'est une piste.
Je souhaite connaitre le contenu du fichier /etc/apparmor/akonadi-mysqld, alors je cherche sur internet et je tombe dessus :
https://forum.kde.org/viewtopic.php?f=215&t=162053&start=15 (lecture en cours...)
Redirige vers un rapport de bogue de KDE :
https://bugs.kde.org/show_bug.cgi?id=411093 (lecture en cours...)
Rien d'intéressant. Ça dit que ce bogue existe, tu n'es pas la seule.
"LE" rapport de bogue qui te concerne, chez Ubuntu :
https://bugs.launchpad.net/ubuntu/+source/akonadi/+bug/1873087
Apparemment, le problème est la manière dont mysqld est appelé.
En remplaçant (le ou les) mysqld_anonadi par /usr/sbin/mysqld dans le fichier /etc/apparmor.d/mysqld_akonadi règlerait le problème.
D'après le rapport de bogue, tu peux le faire en une seule ligne de commande :
Code BASH :
sudo sed 's|mysqld_akonadi|/usr/sbin/mysqld|' -i /etc/apparmor.d/mysqld_akonadi
Tu peux faire une sauvegarde du fichier avant si ça te rassure, mais je pense que ce n'est pas utile.
Alors... comment dire ???? C'est désespérant !!!!
J'ai donc fait
Puis
Et
Eh bien... J'ai exactement le même résultat !!!
Enfin, je crois ! En tout cas, ça ne marche toujours pas...
Je ne repère pour ma part aucune différence dans le fichier mysqld-akonadi...
Je joins les 2
J'ai donc fait
Code BASH :
sudo sed 's|mysqld_akonadi|/usr/sbin/mysqld|' -i /etc/apparmor.d/mysqld_akonadi
Puis
Code BASH :
sudo systemctl reload apparmorEt
Code BASH :
akonadictl start
Eh bien... J'ai exactement le même résultat !!!
Enfin, je crois ! En tout cas, ça ne marche toujours pas...
Code BASH :
bisane@bisane:~$ akonadictl start Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) bisane@bisane:~$ org.kde.pim.akonadiserver: Starting up the Akonadi Server... mysqld-akonadi: [ERROR] Failed to open required defaults file: /home/bisane/ mysqld-akonadi: [ERROR] Fatal error in defaults handling. Program aborted! org.kde.pim.akonadiserver: database server stopped unexpectedly org.kde.pim.akonadiserver: Database process exited unexpectedly during initial connection! org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld-akonadi" org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/bisane/.local/share/akonadi/mysql.conf", "--datadir=/home/bisane/.local/share/akonadi/db_data/", "--socket=/run/user/1000/akonadi/mysql.socket", "--pid-file=/run/user/1000/akonadi/mysql.pid") org.kde.pim.akonadiserver: stdout: "" org.kde.pim.akonadiserver: stderr: "" org.kde.pim.akonadiserver: exit code: 1 org.kde.pim.akonadiserver: process error: "Unknown error" mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/run/user/1000/akonadi/mysql.socket' (2)' Check that mysqld is running and that the socket: '/run/user/1000/akonadi/mysql.socket' exists! org.kde.pim.akonadiserver: Failed to remove runtime connection config file org.kde.pim.akonadiserver: Shutting down AkonadiServer... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally...
Je ne repère pour ma part aucune différence dans le fichier mysqld-akonadi...
Je joins les 2
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie