Support du traqueur

Les utilisateurs n'aiment ni interrompre leur travail ni regarder le sablier
Phil
Administrateur du site
Messages : 249
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Re: Support du traqueur

Message par Phil » dim. 4 mars 2018 16:57

Le traqueur a été mis à jour pour éviter la faille de sécurité CVE-2018-1058. A noter que, si vous exécutiez le traqueur dans une base de travail dédiée sans aucun privilège public conformément aux recommandations, le risque était de toute façon nul en ce qui concerne cette faille.
Cdlt. Phil - pgphil.ovh

Phil
Administrateur du site
Messages : 249
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Re: Support du traqueur

Message par Phil » dim. 17 juin 2018 13:29

Merci à un DBA pour sa question :

"Les rapports font des full sur les tables du traqueur, il ne manquerait pas des index sur vos tables ?"

Réponse : vous utilisez le traqueur avec une version 9.4 ou inférieure de PostgreSQL. Le traqueur crée des index BRIN introduits en 9.5. Si vous voulez éviter les seq scan, vous pouvez mettre à jour votre version de PostgreSQL ou créer vos propres index B-Tree sur les tables du traqueur.
De manière générale, le traqueur utilise les petites et grandes innovations de PostgreSQL au fur et à mesure de leur mise à disposition :
- fonctionnalités json de PostgreSQL 9.3
- fonction pg_sleep_for de PostgreSQL 9.4
- indexation BRIN de PostgreSQL 9.5
- indexation BLOOM et wait events de PostgreSQL 9.6
- résumé automatique (autosummarize) des index BRIN, partitionnement déclaratif de PostgreSQL 10
- indexation automatique des partitions, procédures avec transactions embarquées de PostgreSQL 11
- ...
Cdlt. Phil - pgphil.ovh

Phil
Administrateur du site
Messages : 249
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Re: Support du traqueur

Message par Phil » sam. 15 sept. 2018 18:57

La version 2.05.03 était la dernière version du traqueur compatible avec PostgreSQL 9.3. Cette version restera en ligne mais elle n'est plus maintenue.
Le traqueur en version 3.00.00 est compatible avec les versions PostgreSQL 9.4 à 12.
Cdlt. Phil - pgphil.ovh

Phil
Administrateur du site
Messages : 249
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Support du traqueur

Message par Phil » ven. 28 sept. 2018 18:42

Merci à un administrateur RHEL pour sa question :

"Je n'ai rien du tout dans les infos mémoire remontées par le tracker, c'est toujours à 0. Bug ? Version de PostgreSQL 10.1, version de RHEL : 7.4 "

Réponse :

J'ai expérimenté un agrégat dans l'affichage des résultats concernant la mémoire, en interactif et dans les rapports produits par -r, donc il peut y avoir bug.
Mais s'il y a 0 partout, c'est plutôt le même problème que celui remonté le 3 novembre 2017.
Vérifiez votre version de psutil depuis un shell :

Code : Tout sélectionner

python
Python 2.7.5 (default, May  3 2017, 07:55:04)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import psutil
>>> psutil.__version__
'2.2.1'
Dans cet exemple, la version de psutil est trop ancienne, il faut au moins une version 4 (5+ recommandée).
Cdlt. Phil - pgphil.ovh

Phil
Administrateur du site
Messages : 249
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Support du traqueur

Message par Phil » lun. 8 oct. 2018 22:01

Merci à un architecte pour sa question :

Depuis la 12.2.0.1, Oracle Database facilite le suivi des performances dans les configurations de type "Active Dataguard" (hot standby pour PostgreSQL) en autorisant l'enregistrement d'informations AWR concernant la standby dans la base primaire. Il est ensuite possible de produire des rapports et cela permet de suivre l'activité de la base de secours bien qu'elle soit en lecture seule. Est-ce possible avec le traqueur et PostgreSQL ?

Réponse :

Désolé, il est actuellement impossible d'utiliser le traqueur sur une hot standby, que ce soit en mode batch ou en mode interactif.
En mode batch, le traqueur peut enregistrer les informations dans un cluster distinct du cluster à superviser. Cependant, aucune opération INSERT n'est autorisée dans les transactions en lecture seule des hot standby, même si l'insertion concerne une table étrangère située dans un cluster en lecture/écriture. L'erreur obtenue sera "ERREUR: ne peut pas exécuter INSERT dans une transaction en lecture seule"
En mode interactif, le traqueur crée des tables temporaires. Permettre la création de tables temporaires dans les hot standby était discuté sur la liste pgsql-hackers. Ce sera donc peut-être possible à l'avenir mais ce n'est pas encore implémenté, même dans PostgreSQL 12. Je vais réfléchir à une solution permettant de contourner cette limitation mais je ne peux donner de délai concernant la disponibilité.
Cdlt. Phil - pgphil.ovh

Phil
Administrateur du site
Messages : 249
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Support du traqueur

Message par Phil » sam. 27 oct. 2018 21:58

Il est ensuite possible de produire des rapports et cela permet de suivre l'activité de la base de secours bien qu'elle soit en lecture seule. Est-ce possible avec le traqueur et PostgreSQL ?
C'est fait en version 3.2.0. En mode batch (option -b H), le traqueur permet à présent d'historiser pg_stat_activity dans un fichier plat afin d'analyser l'activité des clusters en lecture seule (hot standby) de versions PostgreSQL 11 et supérieures.
Cdlt. Phil - pgphil.ovh

Phil
Administrateur du site
Messages : 249
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Support du traqueur

Message par Phil » ven. 22 mars 2019 15:48

Merci à Patrice pour sa question :

"Nous utilisons PostgreSQL 8.4 avec Debian 6, est-il possible d'utiliser le traqueur avec des anciennes versions ?"

Réponse :

Le support LTS (long term support) de Debian 6 s'est arrêté en 2016. Je vous suggère d'envisager rapidement une mise à jour.
Le traqueur n'a de toute façon jamais fonctionné avec PostgreSQL 8.4. Il fonctionne avec PostgreSQL 9.3 et versions supérieures. Seules les versions 9.4 et supérieures sont encore activement supportées au 22/03/2019.
Il est bien sûr théoriquement possible d'adapter le script. Il faut pour cela se passer des blocs pl/pgsql anonyme et des "IF NOT EXISTS" au niveau DDL, renommer dans le script la colonne "query" de pg_stat_activity en "current_query" etc
Ce n'est cependant pas envisagé. Vous pouvez faire cette adaptation si vous le souhaitez ou sponsoriser un backport.
Cdlt. Phil - pgphil.ovh

Phil
Administrateur du site
Messages : 249
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Re: Support du traqueur

Message par Phil » mer. 18 sept. 2019 17:52

Merci à un RSSI pour sa question :

"Dans la page supplémentaire de la sécurité du traqueur https://pgphil.ovh/traqueur_10_14.php vous suggérez de créer un utilisateur OS "traqueur" distinct de l'utilisateur OS "postgres" pour faire tourner localement le traqueur mais ensuite l'utilisateur "traqueur" doit être SUPERUSER au niveau du cluster.
En quoi est-ce utile puisque de toute façon tout utilisateur SGBD avec l'attribut SUPERUSER a automatiquement les mêmes droits que l'utilisateur OS "postgres" comme il est noté dans le communiqué sur la faille CVE-2019-9193 https://www.postgresql.org/about/news/1935/ ?
By design, there exists no security boundary between a database superuser and the operating system user the server runs under. As such, by design the PostgreSQL server is not allowed to run as an operating system superuser (e.g. "root"). The features for COPY .. PROGRAM added in PostgreSQL 9.3 did not change any of the above, but added a new command within the same security boundaries that already existed.
"


Réponse :

Vous avez tout à fait raison, ce compte OS supplémentaire n'empêcherait aucunement les actions malveillantes s'il était compromis puisque l'utilisateur traqueur "superuser" pourrait agir en tant qu'utilisateur OS "postgres" sur le serveur sans restriction. J'ai supprimé cette partie qui pouvait prêter à confusion.
Ce compte permettrait tout de même de limiter certaines erreurs humaines comme un rm malencontreux ou autre mais il obligerait aussi à modifier les droits sur la socket Unix, ce qui n'est pas souhaitable.
Cdlt. Phil - pgphil.ovh

Répondre