Obtenir l'ID pour l'installation de Postgres Server

Question

Nous souhaitons créer un système de licences dans lequel plusieurs utilisateurs connectés à un serveur Postgres partagent la même clé.

Cela signifie que la clé de licence doit en quelque sorte contenir les informations sur le serveur pour lequel elle a été créée, de sorte que la clé ne fonctionnera pas sur un second serveur plus des clients. Je recherche donc un identifiant aussi unique que possible. Jusqu'à présent, sans beaucoup de chance.

SELECT version(); 

Renvoie une chaîne comme ce qui suit:

PostgreSQL 9.3.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54), 64-bit 

Ce qui est probablement un peu différent pour chaque installation Postgres, mais ce n'est pas assez bon (d'autant plus que nous voulons regrouper Postgres avec notre application).

Existe-t-il des informations auxquelles j'accède un peu plus, comme par exemple le temps d'installation, etc.?

Answer 1

Vous pouvez, en tant que notes_horse_with_no_name, utiliser l'identificateur du système de base de données. Cependant:

• Le sysid ne change pas lorsque vous cloner une base de données via pg_basebackup, instantanés SAN, etc. L'incrément ID Timeline peut, mais ne pas toujours, selon la méthode utilisée pour la copie.

• Le sysid modifie si vous videz et rechargez une base de données sur une nouvelle instance, même si le contenu de la base de données est le même.

• De nombreuses instances maître de lecture/écriture PostgreSQL peuvent avoir le même sysid si elles sont toutes clonées à partir d'un postgres préconfiguré commun dans un modèle de conteneur ou similaire.

• Il est trivial de régénérer le sysid, ou de le définir comme vous le souhaitez.

• Le sysid n'est pas conservée par pg_upgrade

donc personnellement, je ne recommande pas d'utiliser sysid. Si je devais effectuer une récupération après sinistre et restaurer une base de données dans une nouvelle base de données et que votre logiciel me bloque, je trouverais un nouveau fournisseur et un avocat.

Il n'est pas utile que ce n'est pas actuellement accessible via SQL, seulement en utilisant pg_controldata.

Définissez et non utilisez la chaîne de version. Ce sera la même chose pour tout ensemble de déploiements provenant du même ensemble de paquets, de binaires distribués, ou autre.

Il n'y a vraiment rien de ce que vous voulez dans PostgreSQL, et je ne suis pas sûr que peut être en raison des choses que les gens font régulièrement. Le clonage, les instantanés et DBs restaurations, la copie d'un DB pour une instance d'assurance qualité/mise en scène, etc., etc.

---

Mon conseil personnel: ne le faites pas.J'ai dû casser des systèmes comme celui-ci dans les situations d'urgence lorsque le système de licence menace la continuité de l'activité. (C'est rarement dur). Je préconise fortement contre les outils avec l'application active des licences lorsque je suis impliqué dans les achats. Les dongles sont encore pire. Prêtez attention au fait que même Microsoft utilise l'application de la licence "soft", où il vous aide à suivre la conformité et vous avertit, mais n'essaie pas de casser le système s'il pense que vous n'êtes pas conforme. C'est à cela que sert le système juridique.

Oh, si vous vraiment pensez que vous devez faire cela, les systèmes Microsoft Windows ont un SID. Mais vos clients vous détesteront s'ils doivent réinstaller le système d'exploitation.

De même, il y a le TPM matériel. Mais ils vous haïront encore plus s'ils restaurent une image de sauvegarde du système d'exploitation sur un nouveau matériel et que la base de données refuse de démarrer.