Welcome to OCS Inventory NG community support, where you can ask questions and receive answers from other members of the community.

Please ask questions only in English or French.

Release 2.12.3 available

The official documentation can be found on https://wiki.ocsinventory-ng.org. Read it before asking your question.

Categories

Migration d'un serveur OCS vers un nouveau serveur

Bonjour,
J'ai effectué un export de la BDD afin de pouvoir la basculé vers un nouveau serveur différent sous Debian. (ancien : Debian 6.0.10 ; nouveau: Debian 11)

J'aurais aimé savoir si les anciens postes pourrait toujours contactés le serveur maître (en partant du principe ou je garde la même Ip que l'ancien) ? Et est ce que le soft client se met à jour tout seul ?

Merci pour votre aide,
in OCS Inventory NG server for Unix by (350 points)
Share on
share on gp share on fb share on tw share on li

7 Answers

0 votes
Il y a pas mal de réponses sur le forum (en cherchant 'migration') ...
by (20.1k points)
0 votes
Concernant les migrations j'ai fais un environnement de test et tout fonctionne.

Ma question serait est ce que l'ancien soft pourrait communiquer avec le nouveau ?
by (350 points)
0 votes

Il y a de nombreux fils sur la 'migration' plus ou moins récent avec de multiples réponses à quasi tous les sujets. (j'y ai moi-même participé puisque j'en ai réalisé une pour un 'petit' parc ~8k).

Un agent communique avec un serveur défini par la ligne 'Server=' du fichier de conf.
(Il est à recommander d'utiliser un nom dns et non une adresse ip !)
En option, on peut utiliser un certificat sur le serveur, qui sera vérifié avec Ssl=1 (ou non avec Ssl=0).
(Bien sûr, un certificat comporte un CN qui doit correspondre au fqdn du serveur.)
NB : il y a des fils sur les certificats avec de bons liens
by (20.1k points)
0 votes
Comment peut-on vérifier la bonne mise en place du ssl ? J'ai bien l'alerte quand je vais sur la console (à cause du certificat auto-signé), j'ai bien evidemment decommenter les bonnes lignes.

   PerlSetEnv OCS_DB_SL_SSL_ENABLED 1

   PerlSetEnv OCS_DB_SL_SSL_CLIENT_KEY /etc/ssl/private/glpi-test.key

   PerlSetEnv OCS_DB_SL_SSL_CLIENT_CERT /etc/ssl/certs/glpi-test.crt
by (350 points)
0 votes
Pour le certificat (du serveur web), il faut un peu de réflexion ...

Point 1 : l'agent peut avoir Ssl=1 ou Ssl=0 : avec 1, l'agent doit vérifier le certificat du serveur et celui stocké localement (cacert.pem).

Point 2 : un certificat a une date de fin de validité (en fait 2 dates). A l'expiration, il faut re-générer un nouveau certificat ... et le déployer sur tous les agents ! (Non seulement, il n'y a pas de moyen simple de déployer un certificat, mais il faut le créer, le déployer sur les agents AVANT de l'activer sur le serveur ...)

Point 3 : Si quelqu'un veut pourrir votre serveur OCS, il est TRES facile d'extraire du serveur le certificat : le mécanisme a été conçu il y a trop longtemps ...

Pour moi, à mon avis, le certificat pose plus de problèmes qu'il n'apporte de sécurité ...

NB : ce que vous indiquez est le certificat pour MySQL en mode TLS, pas le certificat du serveur web ! Prenez plus de temps pour réfléchir ...
by (20.1k points)
edited by
0 votes
Mais dans le cadre de la mise en place de la fonctionnalité du télé déploiement j'aurais besoin d'un certificat donc d'activer le ssl.
by (350 points)
0 votes
Non, encore non.

Celui qui me suivait pour la migration que j'ai mené, m'a dit : ne dis plus 'je pense', (= vérifie avant de parler)

Il est nécessaire d'avoir http et https au niveau du serveur (pour faire du download), mais Ssl=0 fonctionne très bien. (C'est d'ailleurs la config que j'ai utilisé, et les nouveaux agents étaient installés SANS certificat.)
by (20.1k points)
edited by
 
Powered by Question2Answer
...