При работе с WEB-сервером Apache часто приходится сталкиваться с командами, начинающимися с apache2ctl (или apachectl). В этой статье кратко рассмотрим, что это за зверь, откуда у него ноги растут и какой список команд может принимать и обрабатывать apachectl. Первая встреча с ним описана в → этой статье. Ниже копнём немного глубже и посмотрим на то, что же всё-таки из себя представляет apache2ctl.

При написании скриптов на Bash для автоматизации создания нового пользователя Linux так, как например описано в → этой статье (с помощью команды useradd) не достаточно просто передать пароль в эту команду. Передаваемый пароль должен быть зашифрован. Иначе, при создании нового пользователя, значение его пароля будет сохранено «как есть», а при попытке входа этого пользователя в систему, пароль будет кодироваться. И пользователь не сможет залогиниться так как обычно закодированный вариант пароля и его вводимое значения не совпадают. В этой статье подробно рассмотрим, как передавать в систему закодированную версию пароля пользователя.

При создании нового пользователя в Debian (или другой linux-системе) можно задать ему разные системные оболочки, которые будут обслуживать его при правильном вводе логина и пароля в системе. Для этого нужно её указать в шаблоне создания пользователя или ввести явно при создании нового пользователя командой useradd -s (см. подробнее по первой ссылке в этой статье). Всё это хорошо, но некоторые системные оболочки не прописаны в системе и для того, чтобы ими можно было пользоваться, для начала их нужно занести в систему.

В предыдущей статье был рассмотрен случай того, как быстро создать пользователя linux. Это удобно, когда пользователь сидит рядом и готов диктовать свои данные и вводить дважды пароль к своему аккаунту. Однако, при автоматическом создании пользователя данный случай вряд ли подходит. Хотелось бы, чтобы все данные могли быть сразу введены в систему из переменных. И такое возможно! Для этого есть масса опций команды useradd, позволяющих передать системе все данные без диалога напрямую.

У каждого пользователя в Unix есть своя домашняя папка, предназначенная для хранения данных пользователя в месте, доступном только для него. О том, как узнать домашнюю директорию любого пользователя можно прочитать по → этой ссылке. О том, где и как создаются записи о домашнем каталоге пользователя написано в → этой статье. О том, как поменять домашнюю папку пользователя по умолчанию в Linux → по этой ссылке. Все перечисленные сведения полезны и могут помочь ручками поправить путь до домашнего каталога пользователя, однако для его смены есть удобная команда linux — usermod. То, как с её помощью быстро поменять домашнюю директорию для пользователя и рассмотрим ниже.

Как упоминалось и не раз, например, в → этой статье про права на файл, что в linux всё является файлом, а у файла есть владелец и группа. При работе с файлами и папками может потребоваться сменить владельца и/или группу. Например, при смене пользователя или его домашнего каталога. Или для того, чтобы заблокировать доступ пользователю к папке и файлам, лежащим в ней. Или наоборот, когда нужно дать права пользователю или группе пользователей в определённое место на диске.

В *nix-системах так всё устроено, что всё является файлом. Это утверждение является парадигмой данного семейства операционных систем. У каждого файла есть владелец, есть группа и есть права на использование данного файла. Данные права определяются для владельца, для группы и для всех остальных. Так всё устроено. В этой статье подробно рассмотрим вопрос прав на файла (и папки), а также команду chmod, которая позволяет менять эти права.

Для понимания структуры доступа в файловой системе часто требуется знать, каким пользователям и группам пользователей какие права доступа назначены к папкам и файлам. Одним из способов быстро узнать эту информацию является команда ls с опцией -l. О том, какие подводные камни могут быть при работе с этой командой и как всё-таки посмотреть информацию о распределении доступа к файлам и директориям на диске, подробно рассмотрим на примерах ниже.

После того, как NGiNX и Apache разведены на разные порты: NGiNX по умолчанию встаёт на 80-й порт, а вот для Apache порт нужно поменять на 8080. Итак, после этого нужно прописать в конфиге /etc/nginx/nginx.conf соответствующие настройки для того, чтобы NGiNX обрабатывал свои запросы на 80-м порту, а то, что предназначено для Apache, отправлял ему на обработку. Также нужно сразу настроить работу с виртуальными хостами, если планируется, что на сервере будет размещаться более одного сайта. Ну и другие настройки типа сжатия, кэширования на стороне браузера и т.п.. В той статье я приведу готовый листинг получающегося конфига nginx.conf. Какие опции за что отвечают, возможно опишу позже.