Bonnes pratiques concernant les logiciels abandonnés en production (OpenDS)?

À quel point est-il mauvais d'utiliser OpenDS , qui n'est pas activement maintenu, et qui avait le dernier correctif en 2010, et qui nécessite JDK6 (qui est également obsolète) dans un environnement de production? ).

S'il est déjà là, vaut-il généralement le temps et l'argent nécessaires pour trouver un remplaçant, exécuter des tests d'intégration, etc.? Quels sont les critères communs pour franchir cette étape, concernant les logiciels obsolètes en production en général?

Je vous suggère d'évaluer cela en termes de risque commercial / opérationnel.

L'utilisation de vieux logiciels non pris en charge comporte souvent ces risques potentiels.

• Pas de support fournisseur
• Aucune mise à jour des bugs
• Aucun correctif de sécurité
• Les mises à jour du système d'exploitation peuvent être incompatibles
• Les options de récupération après sinistre peuvent être limitées.
• Les problèmes de licence peuvent entraîner des problèmes de récupération / d'exploitation.
• Incapacité à étendre / étendre les opérations sur la base de ce service.

Les deux derniers sont souvent négligés.

Il y a des années, j'ai eu un cas où un client utilisait un ancien logiciel MTA propriétaire. Ils ont obtenu un nouveau contrat majeur de marketing par e-mail et ont dû rapidement accélérer leur batterie de serveurs de messagerie.

Ils n'ont pas pu obtenir de licence pour leur MTA. Le MTA avait certaines fonctionnalités et une API spéciale qui s'intégraient profondément dans leur plate-forme de marketing par e-mail.

Nous avons dû cloner manuellement des disques et les placer dans de nouveaux serveurs plus puissants pour étendre le système. Faire tourner un nouveau serveur aurait été plus logique mais n'était pas une solution viable en raison du logiciel hérité.

Donc, si vous ne prévoyez pas de mettre à niveau prochainement, vous devrez peut-être évaluer les risques et au moins avoir des plans provisoires sur la façon d'atténuer les problèmes s'ils surviennent.

Les gens mentionnent souvent la sécurité. Cependant, les anciens logiciels, à condition qu'ils n'aient pas d'exploits actifs connus, ne sont intrinsèquement pas plus sûrs qu'un remplacement moderne.

Le risque de sécurité n'est pas que le logiciel puisse être exploité mais que vous n'ayez aucun recours facile si un problème de sécurité est identifié.

Personnellement, je préfère mettre à niveau certains composants clés des opérations de manière planifiée que d'essayer de concevoir de toute urgence une nouvelle solution.