PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#3 Re : Sécurité » PgAdmin4 Unable to connect to server:timeout expired » 02/05/2021 11:43:47

Clairement vous avez UFW activé sur votre serveur 2 et il est configuré pour n'accepter des connexions que sur les ports explicitement configuré, mais 5432 n'en fait pas partie.  Il vous faut donc explicitement ajouter le port.  Je ne connais pas du tout UFW, mais à priori un command du style pourrait marcher :

sudo ufw allow 5432

Je vous laisse lire la documentation pour valider cette commande et/ou si vous voulez n'autoriser la connexion que depuis certaines IP ou toute autre chose.

#4 Re : Sécurité » PgAdmin4 Unable to connect to server:timeout expired » 02/05/2021 10:46:18

À priori la configuration est bonne sur le serveur 2: listen_addresses écoute bien sur toutes les interfaces réseaux, et netstat le confirme.  À priori, vous avez-donc un soucis externe à postgres.  Soit un firewall sur le serveur 2 (par exemple que renvoie iptable -L -n sur les 2 serveurs ?) empêche les accès, soit le serveur 2 est sur un réseau différent et vous ne pouvez pas y accéder, soit vous utilisez une mauvaise IP pour vous connecter depuis psql/pgAdmin.

#5 Re : Sécurité » PgAdmin4 Unable to connect to server:timeout expired » 02/05/2021 09:22:35

psql sur le 1 ne se connecte pas au premier serveur.

Vous voulez dire ne se connecte par au 2nd serveur ?  Pour la suite, peut-on dire que le serveur 1 est le serveur sur lequel vous pouvez vous connecter depuis l'extérieur, et le serveur 2 celui où vous ne pouvez-pas.


Quoi qu'il en soit, vous avez une différence de configuration entre vos 2 serveurs, et/ou vous ne pouvez pas joindre du tout le 2nd serveur depuis le premier (vlan ou autre qui sait) et/ou vous avez un firewall sur le 2nd serveur qui bloque le port 5432.


La commande netstat indiquée dans votre premier message était-elle sur le serveur 1 ou 2?

Pouvez-vous nous montrer la configuration postgres sur les 2 serveurs ?  Par exemple:

SELECT name, current_setting(name), source, sourcefile, sourceline FROM pg_settings WHERE source <> 'default' AND name NOT IN ('config_file', 'data_directory', 'hba_file', 'ident_file');

#6 Re : Sécurité » PgAdmin4 Unable to connect to server:timeout expired » 02/05/2021 08:55:44

C'est donc un problème de configuration pour la connexion distante sur votre 2nd serveur.  Essayez de vous connecter avec psql depuis la même machine que celle hébergeant pgAdmin et donnez nous la sortie d'erreur, ainsi que les logs sur le 2nd serveur postgres s'il y en a suite à l'échec de connexion.

#7 Re : Général » Requête pour vérifier un mot de passe » 01/05/2021 10:57:32

Le problème n'est pas de dépasser une limite du nombre de connexions (quoi que, cela peut aussi être le cas), mais surtout le fait qu'il est plus efficace d'effectuer un grand nombre de requêtes en utilisant un nombre plus restreint de connexions.  Tout simplement parce que votre système, passé un certain nombre de processus, va commencer à prendre plus de temps à passer de l'exécution d'un processus à un autre qu'à traiter votre code applicatif.  Et en bonus vous économiserez aussi sur le temps d'établissement des connexions si vous n'avez pas de connexion persistentes.  Et si vous en avez, vous pourrez avoir moins de connexions "réelles", et économiser sur le surcout lié à un grand nombre de connexions, même si elles sont inactives.

#9 Re : Installation » Installation version specifique sur Ubuntu » 30/04/2021 16:38:50

Oui, mais si vous avez déjà un réplicat en 9.5 c'est inutile il suffit de mettre à jour les binaires.

#10 Re : Général » Corrupted visibility map » 30/04/2021 15:33:00

asphator a écrit :

le lien que je fais est que les pg_clog contiennent les historiques de commits/transactions qui permet ensuite à la map de visibilité de savoir quelles sont les lignes à afficher ou non, or, s'il lui manque un fichier clog, il n'est plus capable d'assurer l'intégrité de sa map de visibilité (ou si j'ai mal compris, je veux bien qu'on me corrige svp smile

Effectivement, mais uniquement pour les lignes non "freezées", sinon vous auriez un problème passé quelques milliards de transactions (en plus de devoir conserver un historique de l'intégralité des transactions exécutées, ce qui serait très volumineux).


Donc soit le fichier clog était le bon et il n'était pas accessible (à priori peu plausible), soit le xmin/xmax des lignes en question était corrompu et pointait vers un numéro de transaction invalide, ce qui fait que le fichier clog manquant est tout à fait normal.


Le seul moyen de savoir serait de regarder le numéro de transaction et de le comparer au numéro de transaction courant et du datfrozenxid, pour savoir s'il est valide ou non.


Au passage il est possible que la coupure électrique soit totalement sans rapport avec le problème, outre le fait que cela ait entrainé un redémarrage du serveur et donc la suppression du cache postgres et du cache OS ce qui aurait pu tout simplement révéler une corruption survenue des jours ou des mois plus tôt.  S'il s'agit de lignes utilisées en permanence dans l'application, cela serait très probable.

#11 Re : Installation » Installation version specifique sur Ubuntu » 30/04/2021 14:52:11

capbase a écrit :

Pour une raison toute simple.
Je mets en prod la partie standby d'un cluster dont la partie primaire tourne en 12.5
Je n'ai pas la possibilité de tester l'appli et la valider en 12.6

La version 12.6 est une version mineure de la version majeure 12.  Par défintion, elle est compatible avec la 12.5, même s'il évidemment de rigueur de consulter les notes de mises à jour.

Vous pouvez les consulter à l'adresse https://www.postgresql.org/docs/12/release-12-6.html

Donc à moins que votre appli repose sur un des bugs ou crash corrigé dans la version 12.5, il n'y a aucune bonne raison de ne pas mettre à jour.


Et comme indiqué par ruizsebastien, une réplication 12.5 / 12.6 ne posera pas de problème.  Enfin, à part la possibilité d'exploiter un des bugs de la 12.5 sur le primaire évidemment.

#12 Re : Général » Corrupted visibility map » 30/04/2021 14:46:30

ioguix a écrit :

Concernant les clog, une ligne fait manifestement référence à une transaction plus ancienne que l'actuel horizon connu. Cet horizon bouge entre autre lors des vacuum. Il se peut que l'action d'un vacuum qui aura supprimé le clog en question suite à son travail de freeze ait été perdu. Reste à savoir comment cela est possible. Corruption matériel ? fysnc=off ? perte d'un cache sans BBU au fond d'une baie SAN ?

Ou plus simplement corruption d'un xmin/xmax, soit d'une ligne de la table soit de la table TOAST associée.

#13 Re : Général » Corrupted visibility map » 30/04/2021 12:39:10

asphator a écrit :

6.

vacuum full mytable

=> ERROR sur master, OK sur slave

Je ne suis pas certain de comprendre cette étape.  Avez-vous effectué un VACUUM FULL mytable sur les 2 serveurs (ce qui implique donc une réplication logique), ou uniquement sur le primaire et suite à ça l'erreur lors du SELECT n'apparait plus sur le secondaire mais toujours sur le primaire ?

#14 Re : Installation » Installation version specifique sur Ubuntu » 30/04/2021 12:34:21

Pourquoi voulez-vous installer une version dont vous savez qu'elle contient des bugs ?

#15 Re : Général » Requête pour vérifier un mot de passe » 30/04/2021 08:02:50

J'ai l'impression qu'il y a un gros malentendu sur le vocabulaire.  Une "table locale" ou "côté client" ici veut dire "implémenté avec le reste des objets SQL applicatifs créés sur la base de données", en opposition avec "utilisation de l'infrastructure existante dans postgres".  Donc ici créer une table applicative pour gérer les utilisateurs plutôt qu'utiliser CREATE USER, créer une table applicative pour gérer les autorisation plutôt qu'utiliser GRANT / REVOKE (ou ROW LEVEL SECURITY ou autre) etc etc.

#16 Re : Général » Requête pour vérifier un mot de passe » 29/04/2021 02:15:56

alassanediakite a écrit :

Salut

rjuju a écrit :

La distinction se ferait côté applicatif.  Vous pouvez continuer à recevoir un utilisateur et mot de passe, et comparez ça avec une table locale contenant la liste des utilisateurs avec un secure hash du mot de passe.  Votre applicatif retient alors l'utilisateur et autorise ou refuse les actions en fonction de son profil, également stocké dans des tables locales.

Donc pour lui la table des users en local signifie sur l'application cliente. Ce que je trouve vraiment hyper compliqué à mettre en œuvre (implanter toute la gestion des privilèges coté client!).
@+

Oui, je parlais bien de tables dédiées sur l'instance postgres et d'une gestion externe de l'authentification et des autorisations par l'application.  Cela ne devrait cependant pas être très compliqué à implémenter, et il s'agit de l'approche standard sur toutes les applications.  Cela nécessite effectivement un peu plus d'efforts qu'exécuter des GRANT / REVOKE sur un ensemble de tables, mais si vous souhaitez des autorisations plus fine vous devriez mettre en place du ROW LEVEL SECURITY, et dans ce cas la gestion native n'est pas forcément triviale non plus.

#17 Re : Installation » installation Postgresql sous linux mint le user postgres n'existe pas » 24/04/2021 10:28:27

Error: no initdb program for version 12 found

Il y a vraiment un gros problème dans votre installation hmm  Une réinstallation complète devrait effectivement régler le problème, mais cela ne vous dira pas comment le problème est arrivé ni comment le résoudre sans tout réinstaller si cela se reproduit.


Si vous voulez creuser et résoudre ce problème, n'hésitez pas je vous aiderai avec plaisir.

#18 Re : Installation » installation Postgresql sous linux mint le user postgres n'existe pas » 24/04/2021 06:31:00

Comme vous voulez.  Mais à priori votre problème est que le cluster par défaut a été supprimé, et mettre à jour mint ne changera à priori pas ça.  Si vous le recréez tout le restee devrait fonctionner normalement:

pg_createcluster 12 main

#19 Re : Général » Requête pour vérifier un mot de passe » 23/04/2021 18:15:14

Svear a écrit :

D'accord, j'ai compris. Effectivement je n'ai vraiment pas assez d'expérience. Seul le changement de mot de passe en mode "sql" m'importe peu. Je ne vérifie pas le mot de passe pour l'embêter mais pour éviter qu'un idiot le lui change pendant qu'il va pissser. Si lui il veut le changer via la ligne de commande, ok pour moi.

Je suis entièrement d'accord, c'est une bonne chose de n'autoriser le changement de mot de passe qu'après la vérification du mot de passe actuel.  Mais postgres ne fonctionne pas comme ça, du fait de sa gestion de l'authentification.  Il n'y a aucune garantie qu'un role ait un mot de passe associé, et même s'il en a un il n'y aucune garantie que l'utilisateur ait eu besoin de fournir son mot de passe pour s'authentifier (ex: authentification trust ou certificat), ou qu'il ait fourni le mot de passe dont postgres à un jour eu connaissance (ex authentication pam ou kerberos/AD).


Svear a écrit :

Sinon effectivement tout un tas de possibilités auxquelles je n'ai pas pensé. Euh... il y a moyen de lui interdire de créer des objets via les grant?

Oui évidemment.  Et par défaut un utilisateur n'a le droit que de créer des objets dans le schéma public, c'est donc assez facile à configurer (et c'est d'ailleurs recommandé, cf https://wiki.postgresql.org/wiki/A_Guid … earch_Path ).

Svear a écrit :

Et il peut vraiment désactiver les logs?

C'était un peu exagéré.  Il pourra exécuter différents "SET config = valeur", mais au moins log_min_duration_statements et log_min_messages ne sont pas modifiables par un simple utilisateur.  Il pourra cependant faire un

SET work_mem = '1TB';
SELECT * FROM pg_class c1 CROSS JOIN pg_class c2 CROSS JOIN pg_class c3...

et consommer énormément de mémoire.  Vous pourriez essayer de mettre en place énormément de controles sur votre instance pour empêcher un utilisateur de faire n'importe quoi, mais de manière générale si vous voulez vous assurer de n'autoriser que les requêtes applicatives, il ne faut autoriser que votre applicatif à se connecter.


Svear a écrit :

Merci de vos conseils, ils ont été précieux et considérés avec attention. D'autant plus que le projet en est à ses débuts donc je pose les bases ce qui veut dire que je peux les changer relativement facilement. Accessoirement (pour confirmation) il n'y a donc pas moyen de checker son propre mot de passe.


Postgres ne dispose pas d'une version "en clair" des mots de passe, pour raison de sécurité (cela était techniquement possible il y a quelques années en demandant de stocker explicitement un mot de passe en clair mais heureusement plus maintenant).  Vous pourriez tenter de valider le mot de passe saisi avec le hash stocké en utilisant les même heuristiques que pour l'authentification, en supposant que l'utilisateur ait un mot de passe, mais cela supposerait d'écrire le code correspondant en C et de le packager dans une extension.  Si vous utilisez vraiment une authentification par mot de passe, il est conseillé d'utiliser la méthode scram, et réimplémenter la validation est clairement loin d'être trivial smile

#20 Re : Installation » installation Postgresql sous linux mint le user postgres n'existe pas » 23/04/2021 17:54:28

Je n'ai pas de debian/ubuntu sous la main, mais en regardant http://manpages.ubuntu.com/manpages/xen … per.1.html (comme indiqué dans le message), est-ce que

psql --cluster 12/main

fonctionne ?

Sinon que renvoie

pg_lsclusters

#21 Re : Installation » installation Postgresql sous linux mint le user postgres n'existe pas » 23/04/2021 15:24:16

En posant la question je trouve la log dans /var/log/postgresql

Ce sont les log de postgres, pas d'apt.  Ce n'est pas surprenant que la suppression du package voire le "prune" ne supprime pas ce fichier.  Mais s'il y a eu une installation de postgres par le passé et que l'utilisateur système postgres n'existe pas, j'imagine qu'il y a eu de mauvaises manipulations ayant entrainé la suppression de l'utilisateur système et la détection d'une installation précédente qui fait que l'utilisateur n'est pas recréé.

#22 Re : Installation » installation Postgresql sous linux mint le user postgres n'existe pas » 23/04/2021 14:45:52

Etes-vous sur que l'installation à fonctionné ?  Je vois notamment

supported-versions: WARNING! Unknown distribution: linuxmint
ubuntu found in ID_LIKE, treating as Ubuntu
supported-versions: WARNING: Unknown Ubuntu release: 20.1


Que retourne

dpkg -l | grep postgres

#23 Re : Installation » installation Postgresql sous linux mint le user postgres n'existe pas » 23/04/2021 13:52:21

L'utilisateur système postgres est normalement créé lors de l'installation de postgres.  J'imagine donc que vous avez eu un soucis lors de cette installation, mais impossible d'en dire plus sans avoir la liste des commandes effectuées ainsi que leurs retours.

#24 Re : Général » Requête pour vérifier un mot de passe » 23/04/2021 13:50:20

Svear a écrit :

Débutant en Postgres, j'ai quand-même tenté de faire les trucs bien en créant, dans la bdd elle-même, des roles dits "de groupe" (qui n'ont pas le droit login). Ces roles "de groupe" possèdent le droti "grant connect to". Ensuite les tables qui sont créées ont alors leurs droits insert/update/delete positionnés par rapport à ces roles "de groupe". Et les roles qui sont créés pour les utilisateurs sont ensuite "grantés" sur ces roles particuliers.
[...]

Je suis d'accord que vous avez fait les choses bien, mais malheureusement cette approche pose de nombreux problèmes, et à mon avis vous aurez un retour de baton un jour ou l'autre si vous gardez cette approche.

Svear a écrit :

J'ai parfaitement conscience que cette méthode permettrait à toto de se connecter directement via psql (un petit linux portable qui usurperait l'IP des IP autorisées et hop) mais à quoi ça l'avancerait? Il n'aurait pas plus de droits via psql que ce qu'il en a avec l'appli.

Et bien déjà il aurait le droit de changer son mot de passe sans devoir fournir le mot de passe actuel, ce qui est en contradiction avec ce que vous cherchez à faire.  Il aurait également le droit d'ouvrir autant de connexions qu'il le souhaite, jusqu'à saturation, et donc empêcher tout le monde de se connecter.  Ou exécuter des requêtes de son choix et consommer énormément de ressources, potentiellement jusqu'à saturation ou OOM, ou de créer ses propres objets, insérer en une seule requêtes des milliards de lignes et saturer l'espace disque, désactiver les traces de requêtes etc...


Svear a écrit :

Mais effectivement mon appli n'est pas compatible avec un pooler de connexion (dont je connais la notion mais que je n'ai pas implémentée).
Mais à l'inverse, si l'appli se connectait avec un role dédié (que je présume donc directement créé avec la bdd), je ne pourrais plus gérer la connexion. Comment en effet distinguer "toto" de "titi"?

La distinction se ferait côté applicatif.  Vous pouvez continuer à recevoir un utilisateur et mot de passe, et comparez ça avec une table locale contenant la liste des utilisateurs avec un secure hash du mot de passe.  Votre applicatif retient alors l'utilisateur et autorise ou refuse les actions en fonction de son profil, également stocké dans des tables locales.

#25 Re : Général » Requête pour vérifier un mot de passe » 23/04/2021 08:23:52

Bonjour,


Je pense que votre approche pour l'authentification est problématique.

Votre application à priori se connecte à l'instance postgres avec le role fourni lors de la connexion plutôt qu'un role postgres dédié.  C'est en général une mauvaise idée car cela pose plusieurs problèmes.  Le plus important étant que cela rend votre application incompatible avec un pooler de connexion, ce qui revient à dire que votre application ne fonctionnera pas correctement avec de nombreux utilisateurs, mais cela pose également de potentiel problème de sécurité et/ou de mauvaise utilisation car vos utilisateurs ont techniquement un accès direct à l'instance.  Implémenter à la place un système d'authentification externe résoud à la fois votre problème original ainsi que tous les problèmes qui découlent de l'utilisation d'un role postgres par utilisateur applicatif.

Pied de page des forums

Propulsé par FluxBB