Я искал на этом сайте хороший ответ на свой вопрос, лучшее, что я смог найти, было этот. (Я бы предположил поместить свою конфигурацию в /etc
, приложение в /usr/local/bin
и данные в любом /home/firda/.tunnel
или где-то в /var
или /srv
или /usr
.)
Предисловие:
Пишу серверное приложение на C ++. Он должен стоять между другими серверами, мобильными приложениями и устройствами (небольшими устройствами, например, в автомобиле). Обычно он прослушивает TCP-порт (для обработки клиентов = мобильных приложений и серверов) и UDP-порт (где данные будут поступать из / в ipsec / racoon и / или открытый порт - связь с устройствами, настраиваемый протокол). Ему не нужны привилегии root (порт> 1000, например, 11235), поэтому я решил установить бит SUID и назначить владение своей учетной записью (чтобы она работала под моей учетной записью, даже если я запустил ее как root). Вот как я его сейчас развертываю (от MAKEFILE)
deploy := /usr/local/bin
user := firda
name := tunnel
watchdog := tunnel-watchdog
names := $(name) $(watchdog)
deploy:
cp $(names) $(deploy)/
chown $(user):$(user) $(patsubst %,$(deploy)/%,$(names))
chmod a-rwx,u+xs $(patsubst %,$(deploy)/%,$(names))
$(deploy)/$(watchdog)
и добавил /usr/local/bin/tunnel-watchdog
к /etc/rc.local
(туннель-сторожевой таймер просто разветвляется для запуска туннеля и перезапускает его, если он умирает). Когда я хочу его развернуть, я копирую исходники в свой домашний каталог (/home/firda/tunnel
), тип make test
для сборки и самопроверки (под учетной записью без полномочий root), затем kill
эти два запущенных процесса (после ps -fu firda
чтобы узнать PID) и введите make deploy
скопировать новые исполняемые файлы в /usr/local/bin
и запустите его снова (под учетной записью root).
Вопросы:
/etc/tunnel/config
now - указывает номера портов, но теперь он также содержит учетные данные / настройки пользователя / устройства)/etc/tunnel/config.tmp
создается по истечении некоторого времени ожидания, например, когда пользователь добавлен, /etc/tunnel/config
-> /etc/tunnel/config.bak
и /etc/tunnel/config.tmp
-> /etc/tunnel/config
)/home/firda/whatever
? /srv/something
?)Я знаю, что могу разместить все файлы в своем домашнем каталоге (это мой собственный сервер, который, вероятно, не будет передан кому-либо еще, ... кто знает), но хотел бы знать лучшая практика совет, как это делать правильно (не перекрещивать администраторские привычки, такие как разбиение диска на разделы и квоты - хотелось бы знать, как это обычно делается, как это можно сделать, какие папки подходят для какой-то системы резервного копирования). Спасибо.
P.S .: Это не веб-сервер (пока), но я предполагаю, что ответы могут быть похожими. Этот вопрос может показаться дублирующим тому, на который я ссылался, но я не был удовлетворен ответом, поэтому я скорее указал мое собственное приложение и потребности (особенно вопрос о разделении, квотах и резервных копиях).
ОБРАТНАЯ СВЯЗЬ:
Стандарт иерархии файловой системы разделяет каталоги по двум критериям: только для чтения (/usr
, /etc
, /opt
и /boot
) - все это для исполняемых файлов и стабильной конфигурации, а не для данных. Второй критерий - это совместный (независимый от платформы) и не подлежащий совместному использованию (зависит от платформы). Данные должны войти /var
дерево с одним добавленным исключением: /srv
может использоваться как для данных только для чтения, так и для данных для чтения и записи (что идеально подходит для служб, которым нужны файлы обоих типов в одном каталоге).
Сейчас я, вероятно, буду использовать /etc
для базовой конфигурации (включая параметры для изменения используемых каталогов), /usr/local/bin
для приложения и /var/local
для моих данных. (С помощью /srv
может быть вторым вариантом.)
Есть комментарии, прежде чем мы сможем закрыть этот вопрос?
Единственный документ, который пытается понять все это, - это Стандарт иерархии файловой системы; a.k.a. FHS.
Однако он не дает однозначного ответа на ваш вопрос. Вроде бы есть 3 варианта:
/opt/tunnel
и хранить все файлы, относящиеся к приложению, есть./usr/local
и связанные /*/local
каталоги. Прочтите FHSВариант 1 наиболее распространен для проприетарного и корпоративного программного обеспечения, но он не очень соответствует духу остальной системы. Вариант 2 определенно лучший с точки зрения наличия хорошей системы, но это большой объем работы, если вы не привыкли упаковывать программное обеспечение. Вариант 3 является традиционным и исторически наиболее распространенным методом, и FHS окажет вам здесь наибольшую помощь, но вы также, вероятно, захотите изучить, как другие люди и программное обеспечение (которое вы уважаете) решили ту же проблему.