Discussion :

[qi130]

Bien le bonjour!

Alors voilà, je me suis décidé à explorer les versions 2.5 à 4 de Firebird, à la faveur de longues vacances à venir.

Je nourris l'ambition d'installer sur un PC faisant office de serveur ces versions.

1ère question : les différentes versions peuvent-elles être actives en même temps? Etant entendu que chacune doit disposer de son n° de port spécifique (of course)

2ème question: quelle type d'installation privilégier? (Cf https://firebird.developpez.com/faq/...e-sous-Windows)

3ème question: faut-il installer dans l'ordre croissant des versions ou bien cela n'a-t-il aucune importance?

4ème question: peut-il y avoir un souci avec fbclient.dll ? (genre la V4 écrase la v2.5, y a-t-il rétrocompatibilité?) Ou bien le type d'install (voir Q.3) garantit que chaque serveur dispose de "sa" fbclient?

Coté LAN:
J'ai fait qq tentatives, bien sûr infructueuses. Mes connaissances datent un peu et ne sont plus en phase avec les nouvelles versions d'OS.

Q.1: le PC (futur serveur, W10PRO) ne répond pas aux ping émis par mon PC de dev (W10Famille). J'augure qu'une tentative d'accès "applicative" à ce serveur sera en échec.
=> faut-il créer 1 règle ICMP dans le pare-feu du futur serveur?
Q.2: le ping inverse marche. N'ayant pas souvenir d'avoir modifié le pare-feu, est-il possible que cette règle soit la conséquence de l'activation d'un service Win genre découverte du réseau ?
Q.3: avec l'échec du ping, je me suis aventuré dans le routage de ma box: a priori ça ne sert à rien: vous confirmez? (pas d'accès au serveur depuis internet)
Q.4: par contre il me faudra créer des règles dans le pare-feu du serveur pour autoriser l'entrée sur les ports spécifiés dans chaque fichier ".conf": vous confirmez?
(d'après cette page, le trafic sortant est "open bar")

Sur le serveur:
Q.1:j'envisage des répertoires dédiés selon le format (ODS) de chaque base genre

Code :

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

1
2
3
C:\BD\FB25\ 
...\FB30\
etc

est-ce pertinent?

Merci par avance.

[SergioMaster]

Bonjour, que de questions ! Je vais tâcher d'y répondre

1ʳᵉ question : les différentes versions peuvent-elles être actives en même temps ? Étant entendu que chacune doit disposer de son n° de port spécifique (of course)

Oui

2ᵉ question*: quel type d'installation privilégier ?

Moins facile, car cela va dépendre de la version globalement, pour pas d'ennuis, installer en service avec guardian me semble la meilleure approche, je ne l'ai pas fait pour FB4 sur mon poste, et je dois régulièrement relancer le service quand j'en ai besoin (service en démarrage manuel)

3ᵉ question*: faut-il installer dans l'ordre croissant des versions ou bien cela n'a-t-il aucune importance ?
4ᵉ question*: peut-il y avoir un souci avec fbclient.dll ?

Pas vraiment d'importance sauf en ce qui concerne la copie de fbclient sur windows/system et syswow64 (pour le 32 bits) , AMHA il ne faut mettre que la version la plus aboutie (donc la plus élevée) dans ces répertoires systèmes. Lors de l'installation il y a une case à cocher pour ce qui est de la copie vers windows donc facile de ne pas le faire
D'un point de vue Delphi, le mieux ensuite est de désigner la "bonne" fbclient.dll à utiliser au niveau de la connexion (bien sûr cela va dépendre des composants utilisés)

LAN

Q.1: le PC (futur serveur, W10PRO) ne répond pas aux ping émis par mon PC de dev (W10Famille).
Q.2: le ping inverse marche.

Problèmes de réglage, ces W10 et W11 me cassent régulièrement les pieds !

Q.3 : avec l'échec du ping, je me suis aventuré dans le routage de ma box: a priori ça ne sert à rien: vous confirmez? (pas d'accès au serveur depuis internet)

rien à voir avec l'échec du ping réseau local. Uniquement nécessaire dans le cas d'accès internet ou, vers un NAS comme serveur Firebird (chose que j'ai pu tester mais uniquement avec une version FB, impossible pour moi d'installer plusieurs versions de FB sur mon NAS pourtant ça l'est)

Q.4 : par contre, il me faudra créer des règles dans le pare-feu du serveur pour autoriser l'entrée sur les ports spécifiés dans chaque fichier ".conf": vous confirmez?

cela vaut mieux oui, mais le pare-feu windows est je ne le maitrise pas bien, j'utilise Norton chez moi et ESET sur le serveur d'entreprise


Sur le serveur:

Q.1 : j'envisage des répertoires dédiés selon le format (ODS) de chaque base genre est-ce pertinent?

d'un point de vue "je sais où je range mes bases de données sur mon système" oui. Je recommande surtout de déclarer des alias dans (selon les versions) FB 2.5 Aliases.conf , FB>2.5 databases.conf

[qi130]

Bonjour Serge, et merci pour tes réponses.

A priori, mes réflexions allaient dans le bon sens

Concernant ce point:

D'un point de vue Delphi, le mieux ensuite est de désigner la "bonne" fbclient.dll à utiliser au niveau de la connexion (bien sûr cela va dépendre des composants utilisés)

je n'ai, par contre, pas les idées claires.

Sur le serveur, la version de fbclient compte pour du beurre, non? Sauf bien sûr pour les outils d'admin (sur le serveur), mais je n'ai pas souvenir qu'on ait le choix de la version de cette DLL quand on déclare une base. Et du coup, ce serait la dernière DLL déposée dans le(s) répertoire(s) système qui est utilisée; on suppose que la rétro compatibilité est acquise, y compris pour les sauts/ruptures techniques 3/4/5?

Par contre, coté client, effectivement, il faut être attentif: une DLLv5 pour 1 base en v2 => a priori ok; pas l'inverse!
Du coup, pour les applis Delphi, comment gérer? fichier ini, BdR? afin de prendre la bonne? En cascade, il convient de différencier chaque DLL "fbclient25.dll", "fbclient40.dll', etc. ainsi elles peuvent cohabiter (en fait le nom importe peu, puisqu'on alimente/force ce nom dans les composants).

Qu'en penses-tu?

[SergioMaster]

Je me doutais en écrivant 'côté Delphi' que tu allais tiquer
Quelques suites proposent des connexions (FireDac, Zeos pour celles que je maitrise) avec indications du chemin de la bibliothèque et même si besoin le nom donc tout dépend de l'installation client.
Par copie de la DLL dans les fichiers systèmes windows, je pensais surtout à cette partie. Attention aussi à l'OS (64 ou 32) ça peut faire de gros dégâts si tu mixes

Du coup, pour les applis Delphi, comment gérer? fichier ini, BdR? afin de prendre la bonne? En cascade, il convient de différencier chaque DLL "fbclient25.dll", "fbclient40.dll', etc. ainsi elles peuvent cohabiter (en fait le nom importe peu, puisqu'on alimente/force ce nom dans les composants).

renommer les fblient.dll te forrcera à indiquer le nom de la dll en plus du répertoire, pas forcément une bonne solution.
Sachant que, jusqu'à présent un fbclient.dll v 4 se connecte sur des bases v.3 et v.25 sur le serveur, sauf tu veux vraiment t'embêter à prendre des versions spécifiques ...
Toutefois, s'il s'agit d'utiliser des backups ou nBackups je n'ai pas fait ce test

Du coup, pour les applis Delphi, comment gérer? fichier ini, BdR?

Désormais, je gère ça dans des fichiers ini se trouvant dans %Appdata% (C:\Users\<nom>\AppData\Roaming) pour les préférences utilisateurs et C:\ProgramData\<Application> pour ce qui est connexion Firebird (mots de passe cryptés évidemment) voir C:\ProgramData\<Application>\<program name> pour du spécifique au programme. Je ne mets plus rien en BDR, c'est déjà trop le souk et avec le 64 bits encore plus

[qi130]

Je te remercie pour ces précisions qui confortent mon approche initiale.

renommer les fbclient.dll te forcera à indiquer le nom de la dll en plus du répertoire, pas forcément une bonne solution

+1 puisque effectivement il s'agit juste "d'isoler" chaque dll et donc des répertoires différents suffisent.

Je vais continuer à prototyper l'implantation de tout ça.

[qi130]

Bon, la 2.5 est installée sur le serveur.

Au passage, création des règles FW pour le port renseigné dans le .conf (1 pour TCP, 1 pour UDP).

Grosse galère pour me connecter depuis 1 autre poste ... jusqu'à ce que je partage le répertoire visé (celui de employee.fdb) et là ça marche.
Du coup, mise en œuvre des alias (un jeu d'enfant).

Il faudra sûrement que je revienne sur le FW client: ma galère sus-mentionnée m'a fait ajouter des règles qui ne sont peut-être pas nécessaires, d'autant que certaines pré-existaient, liées aux installations locales de versions FB précédentes (visant le 127.0.0.1 )

Autre point à statuer: le port d'émission des évènements par le serveur (aka RemoteAuxPort). Ce port est, d'après la doc, aléatoire (j'ai au moins 1 appli avec ce genre de chose).

J'essaierai, à l'occasion de mes longues vacances à venir, de rédiger 1 papier

[SergioMaster]

Grosse galère pour me connecter depuis 1 autre poste ... jusqu'à ce que je partage le répertoire visé (celui de employee.fdb) et là ça marche.
Du coup, mise en œuvre des alias (un jeu d'enfant).

Hum cette histoire de partage ce n'est pas normal

Autre point à statuer: le port d'émission des évènements par le serveur (aka RemoteAuxPort). Ce port est, d'après la doc, aléatoire (j'ai au moins 1 appli avec ce genre de chose).

RemoteAux, tu peux le définir dans firebird.conf. A ma souvenance le port est aléatoire côté client mais pas côté serveur

J'essaierai, à l'occasion de mes longues vacances à venir, de rédiger 1 papier

Bravo pour le papier, j'ai l'impression que tes longues vacances sont les mêmes que les miennes qui commencent dans 1 mois

[qi130]

Bravo pour le papier, j'ai l'impression que tes longues vacances sont les mêmes que les miennes qui commencent dans 1 mois

C'est bien ça

Je prends note de ta remarque sur la normalité du partage du répertoire. Je supprimerai ce partage "pour voir". C'est vrai qu'en première intention, ma connexion vers le serveur mettait en oeuvre la triplette IP/port/nom_complet_base, puis fort du succès acquis de haute lutte, j'ai remplacé le nom_complet par l'alias.

[SergioMaster]

L'alias est la meilleure solution, surtout lorsqu'il s'agit de configurer les connexions via un fichier ini ou autres, de plus quand tu veux changer la base d'endroit tu n'a besoin d'intervenir que sur la liste d'alias sur le serveur
Attention aussi aux firebird.conf, surtout pour les versions 3 et plus
cette partie (en bleu ce que j'ai mis pour FB4)

# ----------------------------
# TCP Protocol Settings
#
# The TCP Service name/Port number to be used for client database
# connections.
#
# It is only necessary to change one of the entries, not both. The
# order of precendence is the 'RemoteServiceName' (if an entry is
# found in the 'services.' file) then the 'RemoteServicePort'.
#
# Per-connection configurable.
#
# Type: string, integer
#
#RemoteServiceName = gds_db
#RemoteServicePort = 3050
RemoteServicePort = 3054

#
# The TCP Port Number to be used for server Event Notification
# messages. The value of 0 (Zero) means that the server will choose
# a port number randomly.
#
# Per-connection configurable.
#
# Type: integer
#
#RemoteAuxPort = 0
RemoteAuxPort = 30541

et celle ci

# Per-database configurable.
#
#AuthServer = Srp
AuthServer = Legacy_Auth, Srp, Win_Sspi
#
# Per-connection and per-database configurable.
#
#AuthClient = Srp, Srp256, Legacy_Auth #Non Windows clients
#AuthClient = Srp, Srp256, Win_Sspi, Legacy_Auth #Windows clients
AuthClient = Legacy_Auth, Srp, Srp256, Win_Sspi

et enfin le choix du type de server

# ============================
# Settings for Architecture Configuration
# ============================

#
# Controls the method Firebird engine uses to work with databases and
# related Firebird server startup parameters.
#
# The values are:
# Super / ThreadedDedicated - databases are opened exclusive by single server process,
# attachments share single DB pages cache inside process
# SuperClassic / ThreadedShared - databases are opened by single server process,
# but it does not prevent opening them in other processes (embedded access),
# each attachment has its own DB pages cache
# Classic / MultiProcess - for each attachment to server a separate process is started,
# each database may be opened by multiple processes (including local ones for
# embedded access), each attachment (process) has its own DB pages cache
#
# Type: string
#
#ServerMode = Super
ServerMode = Classic

moi j'ai mis classic car c'est sur mon poste de travail, pas sur un "serveur"

[qi130]

Résolution de "l'histoire" du partage : ça continue de fonctionner ... sans partage

Petite question concernant la DLL client:
J'ai installé la 2.5 64bits. Je trouve 2 dll: 1 dans le \bin du répertoire d'installation (863 Ko) et 1 dans \WOW64 de ce même répertoire (540 Ko)
A quoi correspondent ces 2 DLL manifestement différentes ? (1 en 32bits, l'autre en 64?)

J'ai constaté qu'aucun de ces répertoires ne figure dans le PATH. Du coup, pour l'utilisation d'une appli installée sur le serveur (en local donc), comment savoir/indiquer quelle DLL doit être appelée? Est-ce là qu'intervient le fichier INI? (sinon pour moi, ça tient du miracle )

edit !

Je viens d'installer la V3 en demandant la copie de la dll dans les répertoires système: les dll sont donc accessibles via le PATH.
-> je n'avais pas dû cocher l'option pour la 2.5
-> il faut, au moins dans mon cas, procéder dans l'ordre des versions. Ainsi la DLL v3 écrase la v2, la v4 écrasera la v3, etc. Dans la vraie vie,l'upgrade du SGBD va de paire avec ce principe;et cela lève le doute sur la rétro-compatibilité (du moins j'espère )

[SergioMaster]

Résolution de "l'histoire" du partage : ça continue de fonctionner ... sans partage

Ah, j'en étais sur

J'ai installé la 2.5 64bits. Je trouve 2 dll: 1 dans le \bin du répertoire d'installation (863 Ko) et 1 dans \WOW64 de ce même répertoire (540 Ko)
A quoi correspondent ces 2 DLL manifestement différentes ? (1 en 32bits, l'autre en 64?)

c'est là où Microsoft est logique, la dll 32 bits est dans xxxWOW64
Oui, tu n'avais certainement pas coché la case copie de la dll lors de l'installation de fb 2.5, et, il faut suivre l'ordre des versions si tu coches cette case à chaque fois. La bibliothèque, à partir de la version 4, permet le TimeZone d'une colonne temps (TIME, TIMESTAMP). Dernièrement, lorsque j'ai voulu faire le test sur une base V4 (je rappelle que "par défaut" je travaille sur la V3), je plantais Delphi , la cause : dll v3 utilisée au lieu de la v4

[qi130]

c'est là où Microsoft est logique, la dll 32 bits est dans xxxWOW64

J'ai relevé une autre curiosité suite à l'install de la V3...
Je n'ai eu aucun problème pour me connecter au dit serveur qui écoute sur le port 3030, alors qu'il m'a fallu ouvrir le port 3025 dans le FW pour la v 2.5

J'irai jeter 1 oeil dans le FW (si je retrouve comment y accéder )

Bref, les premiers tests avec les 2 versions de FBServer qui cohabitent sont concluants Ok, je me limite à la connexion et à interroger les données, mais je suis satisfait, d'autant que le client utilise 1 DLL v 2.17 (), les méta-données sont restituées correctement: merci les UIB !

En route pour la v4...

[qi130]

And voila !
Coté serveur


Obtenu de haute lutte
Coté client

Concernant la V3:

• Coté FW et mon étonnement d'un post précédent: validation par mes soins de l'accès "réseau local" au 1er lancement du serveur (popup du FW). J'ai reconfiguré pour le seul port 3030.
• FlameRobin (v0.9.10) est incapable d'ouvrir la base employee (ODS non supporté) - Cependant, la v0.9.3 depuis le poste client y parvient

Concernant la V4:
Il apparait que la complexité technique de cette version est plus élevée, avec nombre d'interventions dans firebird.conf et l'obligation pour mon "architecture" de positionner ce paramètre:

Code :

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

1
2
#WireCrypt = Enabled (for client) / Required (for server)
WireCrypt = Enabled

suite à l'apparition du message

Client attempted to attach unencrypted but wire encryption is required

aussi bien sur le serveur que depuis le client.

Y a plus qu'à mettre ça en forme...

[qi130]

Par rapport à mon post précédent:
Erreur FlameRobin relative à l'ODS : message mal à propos ! En fait, le référencement de la base était KO.

Paramètre WireCrypt de la V4: ça marche aussi avec "Disabled". Il n'y a, a priori, pas de valeur par défaut, et l'indication d'un choix est obligatoire.