Установка и настройка Debian Linux в качестве хостинга

Установка и настройка Debian Linux в качестве хостинга

Устанавливаем Debian Linux (amd64) с параметрами по умолчанию — по обыкновению протыкиваем всё всквозную.

1. При выборе языка — выбираем по умолчанию и ищем своё расположение при выборе страны размещения сервера.

2. При настройке пользователя: а) root дозволено логиниться б) пароль root (потом смените) в) нормальных пользователей НЕ добавляем (пока не надо) г) по умолчанию локаль ввода en_US.UTF-8 плюс ваша родная локаль, как дополнительная.

3. При разметке диска указываете Manual Внутри: Если диск чистый (нет строки FREE SPACE, выбираем корневую запись нашего жёсткого диска ⇒ Yes ⇒ msdos Если диск не пустой — желательно зачистить его таким же способом, дабы избежать побочных телодвижений по дозачистке от того, чем не пользуетесь, и место кончилось. Далее, первым ставим swap-раздел равный размеру оперативной памяти+256мб. Если у Вас 2 гига памяти на машине — swap = 2048+256 = вводите «2304 mb» ; На виртуалках swap размещается в конце диска, чтобы не мешал. На физических машинах желательно в центр диска. Потом ставим корневую партицию с файловой системой ext4. Если у Вас высокие или аггресивные нагрузки на файловую систему, то выделяете отдельную партицию /home с файловой системой xfs

4. Конфигурирование Package Manager Use a Network Mirrir: Yes Use non-free software: Yes Выберите все сервиса для использования, когда спросит (надо довыбрать backports)

5. Select and Install Software Должно быть выбрано SSH Server + standard system utilities

УСТАНОВКА СОФТА И НАСТРОЙКА

Если это виртуалка то ставим open-vm-tools apt-get install open-vm-tools Это позволит Хосту виртуализации видеть нашу гостевую машину (обычно актуально для vSphere / Workstation / Xen Server )

Обязательный набор софта для комфортной жизни: (для боевого хоста 99% не нужно, так как его функция отнюдь не удобства предоставлять)

запускаем mc и по желанию настраиваем как нужно.

для удобства правим файл .profile добавляя в конце mc

НАСТРОЙКА ПОЛЬЗОВАТЕЛЕЙ

. ИЗ ПОД ROOT'А НИЧЕГО НЕ КРУТИМ И НЕ ВЕРТИМ НА СЕРВЕРЕ ! НИКОГДА !

Обязательно выходим из mc (F10)

исполняем (passphrase оставляем пустым — прокликиваем ENTER'ом):

ЭТУ ЖЕ САМУЮ ОПЕРАЦИЮ НЕОБХОДИМО ВЫПОЛНИТЬ ИЗ ПОД КАЖДОГО НОВОГО ПОЛЬЗОВАТЕЛЯ — СГЕНЕРИТЬ КЛЮЧИ ДОСТУПА К МАШИНЕ ИЗВНЕ (ЕСЛИ ТРЕБУЕТСЯ). ДОСТУПА ПО ПАРОЛЮ НЕ БУДЕТ ! ЗАБУДЬТЕ ! пароли воруют. Особенно при передаче скайпом в кафе на бесплатном вайфай :-).

Настраиваем putty для входа и входим. Если удачно, то идём /etc/ssh/sshd_config и отключаем парольный доступ PasswordAuthentication no

УСТАНОВКА ВЕБ СЕРВЕРА, СЕРВЕРОВ БД И PHP5

(php7 в дебиан 8 пока нет) # NGINX

У нас не будет апача — к чёрту его. У нас будет Nginx+PHP5-FPM

COMPOSER

Согласно инструкции https://getcomposer.org/download/

СОЗДАНИЕ ПОЛЬЗОВАТЕЛЯ ДЛЯ ПРОЕКТА НА LARAVEL

пароль укажите тоже lara для удобства, потом смените.

В папке /home появится папка lara — домашняя директория пользователя

НАСТРАИВАЕМ ВЕБ СЕРВЕР, БД, РНР ДЛЯ ПОЛЬЗОВАТЕЛЯ lara

Повышаем безопасность CGI согласно статье https://habrahabr.ru/post/100961/

ищем ;cgi.fix_pathinfo=1 меняем на cgi.fix_pathinfo=0

/etc/php5/fpm/pool удаляем всё создаём файл lara.conf ( USERNAME.conf )

В итоге: — все файлы php создаёт от пользователя lara и группы www-data, что позволит владельцу владеть файлами, а вебсерверу их крутить и вертеть, как тому надо. — собственная папка tmp для временных файлов — собственные логи web-сервера и php (донастроете если надо будет) — отправка почты через php mail()

НАСТРОЙКА NGINX

сразу конфиги выложу, а то статья уже резиновая

SSL сами настроете, там не сложно, но долго его генерить, а лучше его получать у https://www.startssl.com/

если ругнётся, то читайте логи. в отдельных ситуациях ему надо видеть все директории, куда указывает document_root (у нас ещё нет lara.com/public в /home/lara/www)

ПОЛЬЗОВАТЕЛЬ И ВСЁ ИЗ ПОД НЕГО

выходим из mc (F10) если запущен

настраиваем ключи для доступа по ключу, как настраивали для root'а забираем ключи и логинимся через putty этим пользователем.

COMPOSER И LARAVEL

затем добавляем в файл

после чего мы можем крафтить приложение laravel куда угодно в рамках директории пользователя.

вот и всё. технически вам останется настроить сервера БД и кастомизировать архитектуру системы как нужно проекту.

ЗАПОМНИТЕ! НИЧЕГО! НИКОГДА! НЕ ИСПОЛНЯЙТЕ ОТ РУТА, ЕСЛИ ТОГО НЕ ТРЕБУЕТ СИСТЕМА. САМОВОЛЬНЫЕ ПОПЫТКИ ЗАПУСТИТЬ ВЕБСЕРВЕР ИЛИ РНР ОТ РУТА ВЕДУТ К САМЫМ ЖЕСТОКИМ ПОСЛЕДСТВИЯМ !

Ваш кронтаб ещё не существует. Из под рута создайте файл /var/spool/cron/crontabs/lara

запуск задач от лары

Как вы считаете, полезен ли этот материал? Да Нет

Комментарии (18)

  1. ЗАПОМНИТЕ!
  2. НИЧЕГО!
  3. НИКОГДА!

Слушай, оформи статью — я всё понимаю, время, деньги, но пожалей читателей. Ещё капсом тут не писали.

Есть же Markdown.

форму создания статей улучши :) а то ни подсказок о маркдауне ни элементов редактора. в идеале банальный бб-редактор сделай, чтобы было красиво.

  1. а то ни подсказок о маркдауне ни элементов редактора.

Как это нет подсказок? Внимательнее смотри:

Кнпоок для форматирования нет, но на GitHub их тоже нет и никто не жалуется. Для статей они бесполезны, ибо надо мышкой возить. Препросмотр есть.

  1. в идеале банальный бб-редактор сделай, чтобы было красиво.

Оформлять BB-кодами статьи это прошлый век.

Я знаю, что у них на сайте именно так, но интересно, почему не curl и rm? У PHP могут быть отключены fopen_wrappers, да и писать же длинно.

/\. , ибо кроме .ht* есть не менее интересные файлы и папки .git, .svn и т.д.

я думаю либо дело вкуса либо подразумевается отсутствие модуля курл

Я про нативный curl. Во многих ли системах присутствует PHP, но отсутствует curl? Или если удалили curl ради каких-то целей, то зачем оставлять PHP, через который можно сделать то же самое (или с модулем curl, или через fopen_wrappers)? ИМХО, curl без php это понятно, но php без curl, когда последний идёт штатно — совершенно не понятно, зачем.

Многие проекты диктуют требования — максимальная производительность и/или безопасность и/или обеспечение hi-load. Админам приходится удалять неиспользуемые модули php, иногда требуется пересобрать php не через загружаемый бинарник получаемый пакажом от операционки, а путём компиляции, да ещё и с интеграцией необходимых модулей в компилируемую сборку таким образом, чтобы в следствии отключать подгружаемые модули, как функцию, которая высвобождает большие ресурсы при большом кол-ве уникальных посетителей (hi-load). По теме курла. В системе debian 8.5 (сейчас, текущая) по умолчанию НЕТ курла. Его надо доустанавливать руками. Только что проверил на виртуалке, установленной с нуля (из пакетов только standard utils).

Коротко говоря: Боевой сервер должен обеспечивать hi-load и безопасность. И наличие там «удобств» ведёт в вероятным потерям производительности и невероятным финансовым потерям от взлома. Сервер для разработки в принципе может нести что и как угодно на себе и в себе, главное чтобы доступ к нему был затруднён любым способом тем, кто не входит в круг разработчиков. Это может быть мудрёное имя домена/хоста, вход по ключу, а не по паролю, да что угодно.

  1. В системе debian 8.5 (сейчас, текущая) по умолчанию НЕТ курла.

Понятно. Я обычно работаю с CentOS и Ubuntu, там попадаются супер-минималистичные сборки без curl и cron, но редко. Всё равно тот же curl почти всегда нужен для обычных задач типа загрузки ключей для gpg и apt, сборки из исходников и так далее.

Я с трудом могу представить гипотетический сценарий, когда отсутствие curl спасает от взлома, ИМХО слишком много векторов для атаки, если уже есть доступ к shell.

в дебиане апт в состоянии загрузить ключ и сам. Да и не надо привязываться только к курлу, смотри шире на всю систему в целом, а то за отсутствием курла не увидишь PermitEmptyPasswords yes в конфигурации sshd

По операционкам и всяким там билдам и веткам отдельных линуксов хочу заметить, что из линуксов знаю следующие сертифицированы в качестве промышленных Red Hat, SUSE, Debian, Ubuntu. Возможно (не интересовался) в этом списке Centos так как на нём строили и vmware esx(i) и XenServer. Сейчас vmware esx(i) живёт на базе Red Hat, а XenServer не скажу (не знаю текущего положения дел).

Старайтесь использовать проверенные, стабильные и медленно развивающиеся дистрибутивы линукса, такие как debian, centos, redhat ибо они и есть стандартизированные для промышленного использования, где скорость развития дистрибутива и есть яркий показатель жёсткой стандартизации/сертификации (процесс долгий и трудоёмкий — проверить всё и вся перед выпуском нового билда). Не путайте со слабыми командами, которые медленно развивают свой дистрибутив ввиду малой численности.

Подскажи в каком месте должен лежать фаил

в профиле пользователя

Ты имеешь ввиду в домашней директории пользователя создать фаил .profile ? у меня Debian 7.

Все разобрался )) /etc/profile

ты не прав, — у файлов даже название разное. "

/" означает домашний каталог пользователя выполни "cd " и где бы ты ни был — перейдёшь в домашний каталог пользователя. кстати правильно говорить «директория» , ни «папка» ни «каталог» .

Вот теперь дошло, опять таки через ls файла не видно, но через: nano .profile набирается. Из гайда обывателю сразу не понять.

а где вы видели обывателя разворачивающего хостинг? :)

Действительно, это основы Linux.

это домашняя папка (/root, /home/user), а .file — скрытая папка/файл, показывается не через sh ls , а через sh ls -a ( «all» ).

📎📎📎📎📎📎📎📎📎📎