Boas práticas em relação ao software descontinuado em produção (OpenDS)?

Quão ruim é usar o OpenDS , que não é mantido ativamente e teve o último patch em 2010, e requer o JDK6 (que também é obsoleto) em um ambiente de produção? (Embora no back-end e não diretamente exposto aos usuários finais )

Se já estiver lá, geralmente vale o tempo e o dinheiro necessários para encontrar uma substituição, executar testes de integração e outros? Quais são os critérios comuns para executar esta etapa em relação a software obsoleto na produção em geral?

ldap java opends

— Henrik Kjus Alstad
fonte

A boa prática é fazer uma avaliação de risco adequada à sua situação individual.

— HBruijn

Nesse caso específico, não seria possível migrar para o OpenDJ, que é uma bifurcação do OpenDS e provavelmente fácil de migrar?

— ptman

Destacamento. O ForgeRock também tem um bom roteiro para o OpenDJ.

— Yolo Perdiem

Sugiro que você avalie isso em termos de risco comercial / operacional.

O uso de software antigo e não suportado geralmente acarreta esses riscos em potencial.

Nenhum suporte de fornecedor
Nenhuma atualização para bugs
Sem patches de segurança
As atualizações do sistema operacional podem ser incompatíveis
As opções de recuperação de desastres podem ser limitadas.
Problemas de licenciamento podem causar problemas operacionais / de recuperação.
Incapacidade de escalar / expandir operações com base neste serviço.

Os dois últimos são frequentemente esquecidos.

Anos atrás, tive um caso em que um cliente estava usando um software legado e proprietário do MTA. Eles garantiram um novo contrato importante de marketing por e-mail e precisavam aumentar rapidamente seu farm de servidores de correio.

Eles não conseguiram garantir uma licença para o seu MTA. O MTA tinha certos recursos e uma API especial que se integrou profundamente à sua plataforma de marketing por email.

Tivemos que clonar manualmente os discos e colocá-los em novos servidores mais poderosos para expandir o sistema. A ativação de um novo servidor teria feito mais sentido, mas não era uma solução viável devido ao software legado.

Portanto, se você não planeja atualizar em breve, pode ser necessário avaliar os riscos e, pelo menos, ter planos preliminares de como mitigar os problemas, caso surjam.

As pessoas costumam mencionar segurança. No entanto, o software antigo, desde que não exista, explorações ativas conhecidas não é inerentemente mais seguro do que uma substituição moderna.

O risco de segurança não é que o software possa ser explorado, mas você não pode recorrer facilmente se um problema de segurança for identificado.

Pessoalmente, prefiro atualizar alguns componentes principais das operações de maneira planejada do que tentar projetar urgentemente uma nova solução.

— jeffatrackaid
fonte