Расширение стандарта иерархии файловой системы (FHS) для размещения корпоративного программного обеспечения

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

Группа приложений / промежуточное программное обеспечение отправляет запрос о том, что им нужна следующая версия корпоративного программного обеспечения для установки на том или ином сервере приложений. Чем ты занимаешься?

• Поставщик не предоставляет вам RPM
• Даже если они это сделают, RPM - огромный беспорядок
  • Например, один RPM мы в основном установили tarball в / tmp, и в качестве пост-установки распаковали его, а затем удалили файл tarball. Если вы его еще не видите, это означает, что удалить его будет невозможно, поскольку установлен только 1 файл.
• Где они предоставляют сценарии установки, опять же ...
  • Вы не можете видеть, куда будут установлены файлы, кроме как доверять документам.

Короче говоря, у каждого поставщика есть свои «правила» и «настройки по умолчанию», и, что хуже всего, у некоторых их нет.

Единственный способ, который я нашел для борьбы с этим, - это изучить установку на машине разработчика и создать для него свой собственный RPM - это затем подняло тему этой статьи - выработать стандарт того, где все должно быть.

В Unix FHS решает многие проблемы, но поскольку это не его работа, он также пропускает те, которые характерны для стороннего программного обеспечения.

Расширение FHS, стандартов и правил для установки продуктов поставщика

Мы с моим коллегой работаем над расширением этого стандарта на программное обеспечение поставщиков (базы данных Oracle, серверы приложений Oracle, Teamsite, Informatica и т. Д. И т. Д.).

Я задокументировал это Вот, и мы действительно очень довольны этим ...

• Это никоим образом не нарушает родительский FHS.
• Он достаточно гибкий, чтобы обойти жесткие установки корпоративного программного обеспечения.

Если кто-то заинтересован в этом вопросе (т. Е. Высоко ценит соблюдение стандартов и их установку там, где это необходимо, и заботится о поддержании чистой системы, в которой новичок может (почти) интуитивно подобрать и начать ходить) - я хотел бы знаю ....

• Как вам удалось решить проблему?
• Если эта модель вам подойдет, а если нет - почему бы и нет?

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

Ноты

Что касается страницы docson ...

• Это незавершенная работа, поэтому, если что-то неясное, прошу прощения (и исправлю)
• Обозначение /opt поскольку выбор третьей стороны не является должен - вместо этого вы можете использовать /usr/local если вы действительно этого хотите, при условии, что это последовательно. Мы просто предпочитаем /opt.
• Прежде чем вы спросите, такие вещи, как /etc/opt/<vendor>/<product> и аналогичные пути делать имеют основания для этого и напрямую унаследованы от FHS.

Вопрос

1. Подойдет ли вам эта модель?
2. Что-нибудь здесь, что, по вашему мнению, не было рассмотрено?

Конечно, предполагается, что у вас достаточно серверов, чтобы начать использовать этот стандарт.