Назад | Перейти на главную страницу

Стандартная конфигурация файловой системы веб-серверов

Я пытаюсь упростить управление, резервное копирование и репликацию моего веб-сервера. У меня есть веб-сайты, файлы конфигурации, ssl-сертификаты, хосты, разбросанные повсюду. Кажется логичным, что все они должны быть в одном месте. я думал создать каталог в корне вот так

/data

и внутри этого есть все каталоги для моих данных на этом веб-сервере, например:

/data 
    /websites                    [websites directories]
    /ssl_certs                   [secure certificates for sites]
    /vhosts                      [virtual host files for sites]
    /config                      [Software config files (apache, mod_security etc.)
        /apache2                 [Apache Server Config files]
        /proftpd                 [FTP Server Config files]
    /utilities                   [Misc Bash Scripts]

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

Итак, у меня 3 вопроса:

это хорошая идея или это будет больше хлопот, чем стоит?

Будет ли это иметь какие-либо последствия с точки зрения безопасности?

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

У меня примерно так:

  • /и т.д/
    • apache2 /
      • сайты-доступные /
      • сайты с поддержкой /
    • ssl /
      • * .crt
      • частный/
        • * .key
  • / srv /
    • www /
      • $ site /
        • htdocs /
        • журналы /
        • cgi-bin /

Разные сайты делают разные вещи; Если у вас есть система резервного копирования и план аварийного восстановления, который тщательно задокументирован, а ваши файлы конфигурации настроены правильно, то место их размещения не имеет значения.

«Стандарты» ... их так много, что это дурацкое название. Есть типичный сайты, но даже это зависит от дистрибутива и веб-сервера.

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

Обычно конфигурации находятся в / etc / appname (поэтому сертификаты находятся в / etc / nginx / certs /, пароли - в / etc / nginx / passwords, отдельные конфигурации vhost находятся в / etc / nginx / sites / и т. Д.). Это не считается беспорядком или «повсюду»; все находится в каталоге / etc / nginx / dir.

Содержимое сайтов обычно идет в / var / www / site1, / var / www / site2, но это настраивается для каждого сайта и не обязательно должно соответствовать этому соглашению. (Каждый сайт может находиться в совершенно другом месте, если вы захотите, если httpd имеет доступ.)

Примечание. Обычно я использую nginx, но каталог конфигурации для apache должен быть / etc / apache2 /. То же самое относится.

Примечание. Это еще одно распространенное соглашение об использовании / etc / apache2 / sites-enabled / и sites-available /, но мне лично такой подход не нравится.

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

Проблема, с которой я столкнулся с тем, что вы предлагаете, заключается в том, что вы назвали каталог «данными» - я бы хотел, чтобы вся конфигурация и сертификаты SSL были хорошо отделены от содержимого. И поскольку конфигурация по умолчанию в любом случае будет в основном / etc, это кажется логичным местом, чтобы оставить ее.

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