Только начал работать с небольшой группой интерфейсных веб-разработчиков, которые все входят на выделенный производственный сервер WHM / Apache с правами root для изменения клиентских веб-сайтов. Они утверждают, что не хотят входить в каждую из учетных записей отдельных сайтов, потому что их очень много.
Я не опытный системный администратор, но знаю, что это неправильно.
Как лучше всего создать логины для этих разработчиков и назначить разрешения на получение полных прав rwx для всех клиентских ресурсов в каталогах / home /?
Дополнительная информация: * Когда я говорю «разработчики», я имею в виду дизайнеров интерфейса CSS / HTML. Наши разработчики используют git как CVS и не работают на сервере, пока мы не выпустим новые версии CMS.
Я не опытный системный администратор, но знаю, что это неправильно.
На самом деле, что действительно неправильно, так это то, что на ваших производственных машинах есть разработчики. : - / (Ваша жизнь станет лучше, если у вас будет другая машина, на которой они смогут протестировать свои изменения, и сценарий для внесения этих изменений в производственную установку. Ваша жизнь изменится. действительно становится лучше, когда они проверяют свой код в центральном репозитории исходного кода (svn и т. д.) и развертывают его в промежуточной среде для тестирования и только потом в производственной среде.)
К сожалению, я не уверен, что смогу дать много конструктивных советов, не зная более подробной информации о вашей ситуации, но вот несколько вещей, которые могут помочь:
Создайте группу разработчиков и включите все файлы в эту группу. Затем присвойте всем файлам g = rwx.
Кроме того, когда разработчики редактируют сайты, я думаю, это признак плохой работы. Я рекомендую простое управление выпусками:
Проверяйте веб-сайты в репозитории кода, используя что-то вроде subversion. Затем попросите их создать теги с инструкциями по развертыванию. Затем администратор может выполнить развертывание с использованием этих тегов и инструкций по развертыванию и, в идеале, автоматизировать этот процесс. Кроме того, администратор может убедиться, что существует стратегия возврата.
С точки зрения безопасности, я бы порекомендовал полностью поместить отдельные сайты в другую структуру каталогов и связывать их через vhosts. Т.е. / var / www / client1, / var / www / client2. Оттуда создайте новую группу с именем webdev (или что-то еще) и дайте этой группе права на запись в деревья / var / www / client *.
При этом я бы также рекомендовал создать тестовую среду и / или среду Q / A для внесения изменений, а затем, после проверки, развернуть их на производственном сервере. В идеале веб-разработчики не имели доступа к производственной системе, и отдельный веб-администратор или веб-мастер должен был бы развернуть новые страницы. Другой вопрос, может ли ваша культура поддерживать такое разделение обязанностей.
Лично я считаю, что разработчик не должен иметь никаких прав на производственную коробку, но это потому, что я пришел из очень жесткой среды, где мы использовали Rational Unified Process как закон. Dev были их права делать то, что они хотели, Acceptance у них были ограниченные права, но изменения прошли через меня (системный администратор) и Production, на которые у них не было прав, и любые / все изменения прошли через меня в запланированный день, если изменение не было экстренным. На самом деле все сводится к тому, какова ваша политика управления по данному вопросу. Если это всего лишь небольшой магазин, то, очевидно, то, что я только что описал, является огромным избытком, но все же хорошей практикой, о которой стоит подумать. Лучше всего действовать с минимальными привилегиями и давать им только то, что им нужно. Все остальное терпит неудачу, просто убедитесь, что вы получаете хорошие резервные копии для отката любых изменений, которые могут испортить ситуацию (fyi снимки с виртуальными машинами - находка для такого рода изменений, просто не позволяйте снимкам жить более 48 часов, иначе они раздуваются).
Из-за того, что cPanel должен иметь определенные разрешения для определенных папок / файлов, некоторые из вышеперечисленных не будут работать (в других областях - да, с cPanel / WHM - нет).
Я бы сделал одно или оба из следующих действий:
1) Создайте посредника в WHM, у которого есть доступ к учетным записям, чтобы разработчики могли входить в WHM по мере необходимости, но вы можете настроить привилегии, которые есть у посредника с точки зрения модификации сервера. Таким образом, разработчики могут делать вещи, связанные с cPanel, для клиентов, но не портят сервер в целом.
2) Используйте ключи ssh, чтобы позволить им войти КАК ПОЛЬЗОВАТЕЛЬ, которому принадлежат файлы. Поскольку вы используете cPanel, ключи ssh войдут в /home/username/.ssh/authorized_keys Вы можете сохранить «главный» файл authorized_keys и распространять его по мере необходимости в каталогах / home / username.
С помощью этого метода, если разработчик уходит, вы можете просто вытащить его ключ из "главного" файла authorized_keys и выделить новый без старого ключа.
Я также согласен с ответом Люка выше.
mkdir /var/www
chown root:www-data /var/www
chmod 2775 /var/www
Поместите пользователей в группу www-data.