Discussion :

[m4k-Hurrican]

Bonjour,

Voilà, depuis un moment nous avons des accès internes en php à notre base de données, et celà fonctionne bien. Les scripts PHP se connectent à la base locale, effectuent requêtes et mises à jour, bref çà marche.
Aujourd'hui nos sites web sont hébergés à l'extérieur, et nous souhaitons qu'ils puissent écrire et lire directement dans certains fichiers d'interface de la base. Hélas je n'arrive pas à faire fonctionner la connexion à distance. J'ai bien suivi la syntaxe d'accès à une base DB2 non cataloguée, mais rien n'y fait.
Quelqu'un a t'il déjà traité ce problème ?
Ou a une idée à me soumettre ?

Exemple de chaîne utilisée pour une connexion externe mais testée depuis un serveur dans le réseau local :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$database='DBSample';
$hostname='192.168.0.10';
$user='WWWDBUSR';
$pwd='PWDSAMPLE';
$dsn = "DATABASE=$database;HOSTNAME=$hostname;PROTOCOL=TCPIP;UID=$user;PWD=$pwd";
$conn = db2_connect ($dsn,"", "");

[Luc1an0]

Salut,

Diverses pistes :

- Est ce que ta base de donnée (= le process d'écoute, sur le serveur distant) écoute bien sur toutes les interfaces ? (boucle locale + au moins 1 IP)
- Si oui : Le forward des ports utiles est il bien mis en place ?
- Si oui à 1, voir 2 : le firewall ?

[m4k-Hurrican]

A priori je n'ai pas de problème d'écoute, puisque les requêtes depuis les programmes écrits en VB passent. Mais j'ai peut être une lacune à ce niveau, pour moi l'écoute BD est la même, mais je me trompe peut être.
Pour éviter les problèmes de parefeu, dans les tests j'ai fait mes requêtes depuis un serveur placé dans le réseau local. Quand tout fonctionnera, on déportera çà sur le site réel en externe.

Edit :
J'ai bien l'impression après de longues recherches à 2 sur la toile, que l'accès natif à distance ne fonctionne pas en dehors des connexions catalogues (de serveur DB2 à serveur DB2)... Tout le monde bascule sur une solution via le pilote ODBC.

[m4k-Hurrican]

Bon, pour info :
On a pas pu passer par un accès natif, à priori, comme supposé, çà ne marche pas en accès distant.
On s'est donc rabattu sur un accès ODBC, moins performant, plus pénalisant, mais au moins... fonctionnel.

Pour accéder via ODBC en externe on a téléchargé le package disponible chez IBM pour les machines sous Linux.
Mais... Il ne suffit pas d'ouvrir le port 446 sur le pare-feu et de faire une NAT. On a aussi eu besoin d'ouvrir et de mapper les ports 8470 à 8476 qui correspondent à des serveurs divers de Client/iSeries Access (8470=Central server, 8471=Database server ou 8476=Signon par exemple). Depuis, notre liaison directe entre les serveurs web et l'iSeries est fonctionnelle, l'utilisateur Web défini, peut écrire et lire les données directement dans une bibliothèque d'échange à laquelle il est restreint.