Передовая практика в отношении прекращенного производства программного обеспечения (OpenDS)?

8

Насколько плохо использовать OpenDS , который активно не поддерживается и имеет последний патч в 2010 году, и требовать JDK6 (который также устарел) в производственной среде (хотя на бэкэнде и не предоставляется напрямую конечным пользователям) ).

Если он уже есть, стоит ли вообще времени и денег, необходимых для поиска замены, проведения интеграционных тестов и тому подобного? Каковы общие критерии для такого шага в отношении устаревшего программного обеспечения в производстве в целом?

ldap java opends Хенрик Кьюс Алстад
источник
4
Хорошей практикой является правильная оценка рисков в вашей конкретной ситуации.
HBruijn
3
В этом конкретном случае, возможно ли было бы перейти на OpenDJ, который является форком OpenDS и, возможно, на него легко перейти?
Птман
1
Прикомандирования. У ForgeRock также есть небольшая дорожная карта для OpenDJ.
Йоло Пердием

Ответы:

13

Я предлагаю вам оценить это с точки зрения бизнес / операционного риска.

Использование старого неподдерживаемого программного обеспечения часто приводит к возникновению этих потенциальных рисков.

  • Нет поддержки поставщиков
  • Нет обновлений ошибок
  • Нет патчей безопасности
  • Обновления ОС могут быть несовместимы
  • Возможности аварийного восстановления могут быть ограничены.
  • Проблемы с лицензированием могут вызвать проблемы с восстановлением / эксплуатацией.
  • Невозможность масштабировать / расширять операции на основе этого сервиса.

Последние два часто пропускаются.

Несколько лет назад у меня был случай, когда клиент использовал устаревшее, проприетарное программное обеспечение MTA. Они заключили новый крупный контракт на маркетинг по электронной почте и должны были быстро нарастить свою ферму почтовых серверов.

Они не смогли получить лицензию для своего MTA. У MTA были определенные функции и специальный API, который глубоко интегрировался в их платформу электронного маркетинга.

Нам пришлось вручную клонировать диски и размещать их на новых, более мощных серверах, чтобы масштабировать систему. Ускорение нового сервера имело бы больше смысла, но не было работоспособным решением из-за устаревшего программного обеспечения.

Поэтому, если вы не планируете обновление в ближайшее время, вам может потребоваться оценить риски и, по крайней мере, иметь предварительные планы по устранению проблем, если они возникнут.

Люди часто упоминают безопасность. Однако старое программное обеспечение, если оно не имеет известных активных эксплойтов, по своей природе не более безопасно, чем современная замена.

Риск безопасности заключается не в том, что программное обеспечение может быть использовано, а в том, что у вас нет легкого обращения за помощью в случае выявления проблем безопасности.

Лично я предпочел бы модернизировать некоторые ключевые компоненты операций, а не пытаться срочно разработать новое решение.

jeffatrackaid
источник