Веб сервер. Каталог для размещения данных сайтов.

xbsd · 25 июня 2013, 23:43:17

Всем привет!
Столкнулся с вопросом поднятия web сервера. И чтобы "грамотно" разбить хард (и не только по этой причине), не могу определиться, где надо держать каталоги сайтов. Какие есть рекомендации Best Practices в этом плане?
В гугл ходил. Выяснил несколько вариантов:
a) создать в домашней директории пользователя каталог www. В каталоге /var/www держать ссылки на каталоги из /home/$user/www.
b) создать в домашней директории пользователя каталог www. Каталог /var/www сделать ссылкой на /home/$user/www.
c) создать каталог /srv/www. Переопределить переменную RootDirectory с /var/www на /srv/www.
d) оставить все как есть. Для удобства добавить пользователя в группу www-data.
e) ?

Для производственного сервера какой вариант использовать, чтобы потом не было мучительно больно ?
Благодарю!

p.s. При создании темы доступна опция "Иконка". Зачем она нужна?

seisros · 26 июня 2013, 13:49:20

Цитата: xbsd от 25 июня 2013, 23:43:17
Всем привет!
Столкнулся с вопросом поднятия web сервера. И чтобы "грамотно" разбить хард (и не только по этой причине), не могу определиться, где надо держать каталоги сайтов. Какие есть рекомендации Best Practices в этом плане?
Для производственного сервера какой вариант использовать, чтобы потом не было мучительно больно ?
Благодарю!
p.s. При создании темы доступна опция "Иконка". Зачем она нужна?

Иконки нужны чтобы выражать эмоции или как-то по особому выделить тему.
Какой сервер? Я так понимаю обычный ПК для одного сайта, с одним жёстким диском. Если так то разбивай как хочеш особой скорости ты не получиш. Я могу сказать как оптимизировать, но зачем стараться писать? Лучше подумай как ты его в сеть пустиш локально или всемирно? Если всемирно, то сначало подключи удачно домен через DDNS или что там у тебя, заплати за электро энергию на пол года вперёд. Тогда я расскажу как использовать 4 жёстких жиска без массива RAID. А так же могу шепнуть по секрету как использовать ещё один ПК в качестве хранилища в добавок к серверу.

xbsd · 26 июня 2013, 15:24:34

Цитата: seisros от 26 июня 2013, 13:49:20Какой сервер? Я так понимаю обычный ПК для одного сайта, с одним жёстким диском.

ну как-то так. Виртуалочка на скромненьком кластере из 8 esx хостов. В качестве аппаратной платформы используются 2x процессорные модификации HP ProLiant DL380p Gen8 c 65 гигабайтами памяти на борту. Хранилище для образов виртуальных машин представляет собой два дешевеньких дисковых массива HP P2000 с дисками sas и одна старенькая HP EVA P6000 Storage c оптическими дисками.Катастрофоустойчивость обеспечена разнесением есх хостов и дисковых полок по разным серверным помещениям. Думаю что не стоит писать про основное и резервное охлаждение, систему пожаротушения и 2 линии электропитания.
С программной частью пока неопределенность, т.к. не знаю какие конкретно проекты переедут на данную машину. Будет ли там нужен Apache или достаточно php + fpm...

seisros, спасибо Вам за проявленный интерес и за то, что пытаетесь помочь, но я немного не о том спросил.

seisros · 26 июня 2013, 18:24:42

Исключаеш использование крупных raid, ипользуй кусками по 600 гигабайт на том. Монтируеш их в домашнюю директорию по 600 на пользователя и работаеш по принципу b). Отключаеш биты и квоты на монтирование файловых систем. Под систему выдели 7.5 гигов, каталоги /var /tmp отдельно. Они не столь важны, постоянно пишутся и при сбоях в восстановлении ситем не участвуют. И всегда используй UUID. И чтобы процессор не парить лишний раз, дисплей менеджер удали. На входе тебе демон NetworkManager и без входа в систему тебе связь установит. По крайней мере у меня так. Монитор можно потом просто снять. Включил кнопку, строки побежали запросит в консоли логин и ждёт. Всё! Сервер работает ни каких авторизаций не надо, там демоны по сети сами шарят. Кнопку нажал Debian сам завершает работу, точно как и freebsd. Тоже ни какой авторизации не надо. Чтобы использовать хранилища или компы с терабайтами через шнур RJ сначало расшариваеш их с сетью потом так же монтируеш в домашнюю директорию, по протоколу nfs, webdav или даже ftp смотря что поставиш. Советую использовать компы с большими жёсткими чем эти хранилища. Хранилища вопервых тупые, во вторых работают не так быстро. Вот если сетевухи с гиг, 80 МБ сек я думаю хватит для хранилищ.

ihammers · 27 июня 2013, 08:43:14

Цитата: seisros от 26 июня 2013, 18:24:42
И чтобы процессор не парить лишний раз, дисплей менеджер удали. На входе тебе демон NetworkManager и без входа в систему тебе связь установит. По крайней мере у меня так. Монитор можно потом просто снять. Включил кнопку, строки побежали запросит в консоли логин и ждёт. Всё! Сервер работает ни каких авторизаций не надо, там демоны по сети сами шарят. Кнопку нажал Debian сам завершает работу, точно как и freebsd. Тоже ни какой авторизации не надо.

Использовать NetworkManager на сервере и вход без авторизации... ну вы даёте. Для чего устанавливать лишние пакеты, лучше установиться с netinst, без графики. И там не будет NetworkManager, всё равно статику прописывать либо в dhcpd или в конфигах интерфейса. Выше автор поста указал, что это будет виртаулка, так что монитор там не нужен.)

Цитата: xbsd от 25 июня 2013, 23:43:17
Столкнулся с вопросом поднятия web сервера. И чтобы "грамотно" разбить хард (и не только по этой причине), не могу определиться, где надо держать каталоги сайтов. Какие есть рекомендации Best Practices в этом плане?
В гугл ходил. Выяснил несколько вариантов:
a) создать в домашней директории пользователя каталог www. В каталоге /var/www держать ссылки на каталоги из /home/$user/www.
b) создать в домашней директории пользователя каталог www. Каталог /var/www сделать ссылкой на /home/$user/www.
c) создать каталог /srv/www. Переопределить переменную RootDirectory с /var/www на /srv/www.
d) оставить все как есть. Для удобства добавить пользователя в группу www-data.
e) ?

Для производственного сервера какой вариант использовать, чтобы потом не было мучительно больно ?

Всё зависит от того как у вас заведено, например у нас используется несколько вариантов, так исторически сложилось. Варианты a и c не так уж сильно и отличаются.
У нас например есть такой способ использования, /home/web/$user/wwwroot в которой находятся: docs, logs, tmp, cgi-bin и нет никаких ссылок в /var/www/, так как используем suexec с fcgid.

Определитесь с тем:

сколько будет пользователей хоста
какие будут и них права (например будут ли просматривать ли они логи)
где будут храниться временные файлы, будет ли они изолированы друг от друга

Например можно сделать по варианту как у нас совмещённым с вариантом a. То есть, домашние директории пользователей находятся где обычно, в этой директории находится www (или wwwroot). Внутри находиться директория docs, которая уже ссылается на /var/www/$user/. Директория logs, ссылается на /var/logs/apache2/$user/.

Из этого следует, что раздел /home должен быть большим, и также большим (смотря насколько часто будут писаться логи) /var

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

Несколько советов из личного опыта, полученного при создании хоста:

если будете предоставлять доступ другим организациям, то храните логи apache2 более 3-х лет, лучше 5-ть, но мало вероятно, что будет такая потребность;
настройте автоматическую ротацию логов через /etc/logrotate.d/apache2_$user;
не используйте для заливки информации незащищенные протоколы (FTP), лучше используйте SFTP поверх SSH;
выдавайте для начала по минимуму памяти для apache2 и php, потом можно будет увеличить. Бывают случаи когда может закончиться память, если php (сайт) скажем так написан по кривому;
определитесь как часто нужно производить резервное копирование базы и данных пользователя, например можно использовать automysqlbackup и backup-manager (раз в сутки, ночью);
...

xbsd · 28 июня 2013, 09:51:27

Цитата: ihammers от 27 июня 2013, 08:43:14Всё зависит от того как у вас заведено, например у нас используется несколько вариантов, так исторически сложилось. Варианты a и c не так уж сильно и отличаются.
У нас например есть такой способ использования, /home/web/$user/wwwroot в которой находятся: docs, logs, tmp, cgi-bin и нет никаких ссылок в /var/www/, так как используем suexec с fcgid.

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

seisros · 28 июня 2013, 10:47:36

Главное не положение файлов конфигурации, А положение носителей квот. Без RAID, при отказе диска просто замениш том. А вот если весь RAID с данными накроется из-за одного диска, это хреново.

xbsd · 28 июня 2013, 11:37:08

Вы то ли не понимаете о чем я спрашиваю, то ли не хотите понимать. С дисками у меня все хорошо.

agentgoblin · 01 июля 2013, 01:03:19

Цитата: xbsd от 25 июня 2013, 23:43:17a) создать в домашней директории пользователя каталог www. В каталоге /var/www держать ссылки на каталоги из /home/$user/www.
b) создать в домашней директории пользователя каталог www. Каталог /var/www сделать ссылкой на /home/$user/www.
c) создать каталог /srv/www. Переопределить переменную RootDirectory с /var/www на /srv/www.
d) оставить все как есть. Для удобства добавить пользователя в группу www-data.

Принципиальной разницы между этими вариантами нет. Выбирай, что тебе удобнее.

xbsd · 01 июля 2013, 20:16:48

да я понимаю. Спросил, на всякий случай.

Тем не менее, спасибо всем откликнувшимся.

ihammers · 02 июля 2013, 08:53:25

Цитата: xbsd от 28 июня 2013, 09:51:27
Да в том и дело, что никак у нас не заведено в этом плане. Я сразу не указал, возможно это прояснит несколько ситуацию, сервер будет сугубо для внутрисетевых пользователей. Администрировать его будут я и возможно 2ое моих коллег. Все.

Тогда вам придётся это сделать:) А так смотрите как выше было описано, может что и пригодиться.
Думаю что в вашем случае лучшим вариантом будет использование /var/www/. Пользователей, если что добавите в группу (общую).