Vous n'êtes pas identifié(e).
Pages : 1
Bonjour la communauté,
je voudrais savoir s'il y a une différence algorithmique majeure entre ces 2 requêtes :
select table1.* from table1 left join table2 using (id) where table2.id is nullet
select * from table1 where id not in (select id from table2)Je demande ça car d'après moi le résultat de ces 2 requêtes devraient être identiques mais apparemment je me trompe. Je fais ce type de requête pour tester la présence d'uuid entre 2 tables et alors que la première me renvoie le résultat attendu, la deuxième renvoie 0 lignes. Quelque chose doit m'échapper ...
Bon, j'ai un peu honte mais j'ai trouvé la cause de tous mes souci. Ce qui m'a mis la puce à l'oreille est que les connexions distantes ne fonctionnaient que depuis des serveurs ovh. Et là je me suis rappelé !!!! quand j'avais installé mon vps je m'était dis que le Edge Network Firewall était une bonne idée et comme à l'époque je ne voulais pas qu'on puisse se connecter de l'extérieur je n'avais bien sur pas ouvert l'accès au port 5432. Ce pare-feu ne s'appliquant qu'aux portes d'OVH, ceci explique cela 
La sécurité c'est bien aussi faut-il bien tout consigner !!! 
L'étau se resserre un petit peu : un telnet sur le port 5432 permet la connexion depuis d'autre vps mais pas depuis chez moi (ni depuis windows, ni depuis linux, que ce soit en passant par la box ou par la 4g). Avec nmap je détecte bien les port 80 et 22 mais le 5432 reste invisible et inaccessible. Bon je crois que l'on sort de l'objet de ce forum là, postgresql n'est plus en cause je pense. Je vais continué à investiguer... Merci pour votre aide.
Merci pour les pistes. En effet le pb ne vient pas de postgres : j'ai testé la connexion via psql depuis d'autres serveurs (psql -h ip_de_l'hôte -p 5432 -d ma_base -U user -W) et la connexion se fait très bien. C'est vrai j'aurais du commencer par là... mais j'étais focalisé sur les outils. Par contre toujours impossible de connecter un pgAdmin ou un dbeawer, la seule erreur que j'obtient est un timeout expired et rien dans le log de postgres.
Je pensais avoir trouvé la solution en constatant mon erreur dans la config hba (inversion base / utilisateur), il fallait mettre :
host ma_base all 0.0.0.0/0 scram-sha-256
Mais non, le problème est toujours là 
. En attendant j'ai mis all / all pour être sûr)
Bonjour,
merci de votre réponse ! Alors sous psql la commande "SHOW listen_addresses;" me renvoie bien *
et "netstat -nlt | grep 5432" me donne bien :
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN
tcp6 0 0 :::5432 :::* LISTEN
Donc de ce coté, pas de soucis.
Bonjour,
voici ma config : pg 15.8 sur debian 12
Jusqu'à présent toutes les connexions se faisaient en local soit par les appli installées sur le serveur soit via un tunnel SSH. Mes connexions sur dbeawer se font parfaitement avec le tunnel.
J'ai besoin maintenant d'ouvrir une base de donnée à des connexions distantes. J'ai donc effectué les modifs suivantes :
- dans postgresql.conf : listen_addresses = '*'
- dans pg_hba.conf :
host all ma_base 0.0.0.0/0 scram-sha-256
D'ailleurs voici le fichier complet :
local all postgres peer
local all all peer
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256
host all ma_base 0.0.0.0/0 scram-sha-256
local replication all peer
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256
- J'ai ouvert le port dans iptables (iptables -A INPUT -p tcp --dport 5432 -j ACCEPT)
résultat:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5432
- J'ai vérifié qu'il n'y ait pas d'autre pare-feu actif
- J'ai bien sûr redémarrer le service postgresql (systemctl restart postgresql)
J'essaye de me connecter via différents outils en direct à l'ip de mon serveur (port 5432) sur ma_base mais sans succès. La même connexion en localhost via le tunnel ssh se fait sans problème. C'est donc bien ma connexion tcp qui bloque quelque part.
Je veux bien des pistes pour identifier le souci Merci d'avance
Pages : 1