Настраиваем сервер для LiveStreet. Часть II. Vim, файловая система, hostname.
Предыдущие части:
Итак, мы успешно зашли в консоль сервера. Первое что нужно сделать — перезагрузить его командой:
Замечание: Я буду стараться каждую отдельную команду оборачивать с блок как вот тут. Т.е. в этих инструкция — одна команад = один блок. Любая команда запускается на выполнение, набиранием оной в консоли и нажимаем клавиши ENTER после этого. Можно скопировать в буфер, сбросить в консоль правой кнопкой мыши и, опять же, ENTER.
Зачем перезагружать? — Нужно убедиться что сервер без проблем рестартует. Я лично сталкивался с проблемой (у очень именитого немецкого хостера, кстати), когда из-за изначально неправильно настроенного загрузчика, сервер самостоятельно к жизни не возвращался. Такие проблемы никому и за даром не нужны, поэтому это стоит проверить и если что-то не так, решать с помощью поддержки хостера, до начала установки.
После выполнения вышеупомянутой команды, связь с сервером, естественно, прервется. Перезагрузка не должна занимать больше нескольких минут.
Устанавливаем текстовый редактор vim (если он уже был установлен, а многие хостеры включают его в минимальную конфигурацию, то ничего страшного не произойдет):
Замечание: Я знаю что матёрые администраторы обольют меня презрением, но всю первичную установку я буду описывать так, как будто она происходит от имени root. По моему мнению, во время первичной установки sudo это некому не нужные дополнительные препоны. Но в какой-то из последующих частей, ближе к концу, коснемся и этого.
vim штука очень мощная, и для замшелого пользователя Windows, весьма не привычная. С его помощью мы будем редактировать файлы в консоли. К счастью, из всей его необъятной мощи нам хватит трёх команд:
OК. Редактор у нас есть, теперь настраиваем файловую систему.
Сначала смотрим что у нас есть командой:
Выдаст что-то в таком духе:
Нас интересует первая строка «on /» которая олицетворяет собой корневую файловую систему. Если там ext3, а не ext4 — не повезло. Рекомендовать менять это самостоятельно, и описывать процесс, не стану. Это не очень сложно, но всё же я не могу отнести эту тему к доступной для новичка. Однако, это стоит того и для уверенных в себе несколько советов:
Чем ext4 лучше ext3? — много чем, но для нас главным образом интересно то, что она быстрее.
Итак, вносим некоторые изменения.
Для начала создадим раздел для временных файлов nginx:
Открываем vim-ом конфигурацию файловой системы:
В конце файла добавляем три следующих строки (за эти три строки огромная благодарность уходит господину Orhideous ):
Последняя — это мы монтируем тот самый раздел который мы позже будем использовать для временных файлов nginx. Потому что память работает очень быстро :). В примере выше, я выделил под это дело 128Mb. Сколько выделять… В принципе, больше 128M не надо даже для весьма загруженных сайтов ( даже если у вас черте знает сколько доступных Gb, много выделять под это большого смысла не имеет). Для не больших сайтов на VPS, полагаю, хватит и 32-64M.
Обращаю внимание на uid=33,gid=33 в последней строке. Это id юзера www-data и группы www-data. Под управлением этого юзера будут работать все наши сервисы связанные в сайтом, и nginx в том числе. Этот юзер и эта группа, присутствуют в OS изначально, и по идее всегда имеют такие id. Но, не лишне, убедится в этом командами:
Последние что нам нужно сделать в /etc/fstab — это выставить опцию noatime нашей корневой файловой системе. Для этого ищем строку её описывающую. Она не обязательно будет первой. Это что-то что в качестве «mount point» имеет просто символ /. Cписок изначальных опций в ней может выглядеть по разному. Что-то такое:
Замечание: конечно это надо не столько с корневым разделом, сколько с разделом где будут лежать файлы нашего сайта и базы данных. Но, как правило, это корень. Если у вас это не так, или допустим, у вас несколько разделов из-за больших жестких дисков — проставить noatime на все из них, тоже не грех.
Замечание для VPS: существует рекомендация о том, что при использовании ext4 c VPS стоит увеличить timeout. Хотя я лично не могу ни подтвердить ни опровергнуть нужность этого, совет кажется мне разумным. Делается просто — меняется значение по умолчанию (которое 30) в файле /sys/block/sda/device/timeout на 120.
Замечание для храбрых: в случае использования ext4, есть еще одна хорошая опция, помимо noatime, положительно влияющая на производительность: data=writeback. Однако, во-первых с ней связаны, некие теоретические риски. Во-вторых просто прикрутить это в /etc/fstab может привести к печальным последствиям (система после перезагрузки свалится в readonly mode), нужно делать командой tune2fs. В общем, информацию я дал, дальше google и на свой страх и риск.
И ещё полезная заметка по теме от господина ewden : livestreet.ru/blog/14223.html
Внеся все изменения, убеждаемся что нигде ничего плечом не задели, и выходим с сохранением оных.
Теперь настраиваем hostname. По умолчанию хостер может дать серверу оригинальное имя. Наш, например, назывался мило: Debian-60-squeeze-64-minimal. Нам это не очень безразлично, потому что имя хоста используется кое-какими сервисами, например почтой. Лучше чтоб он назывался так же как наш домен без www.
Поправить это крайне просто, идём в файл /etc/hostname:
После всех этих изменений, рестартуем систему (можно и без рестарта было бы обойтись, но так проще, а заодно и проверим ):
После успешного рестарта вызываем опять команду:
И это, к слову, был последний рестарт, который мы будем делать.
Продолжение в следующей части:
Часть III. Некоторые настройки ядра, репозитории и базовые утилиты.
Итак, мы успешно зашли в консоль сервера. Первое что нужно сделать — перезагрузить его командой:
reboot
Замечание: Я буду стараться каждую отдельную команду оборачивать с блок как вот тут. Т.е. в этих инструкция — одна команад = один блок. Любая команда запускается на выполнение, набиранием оной в консоли и нажимаем клавиши ENTER после этого. Можно скопировать в буфер, сбросить в консоль правой кнопкой мыши и, опять же, ENTER.
Зачем перезагружать? — Нужно убедиться что сервер без проблем рестартует. Я лично сталкивался с проблемой (у очень именитого немецкого хостера, кстати), когда из-за изначально неправильно настроенного загрузчика, сервер самостоятельно к жизни не возвращался. Такие проблемы никому и за даром не нужны, поэтому это стоит проверить и если что-то не так, решать с помощью поддержки хостера, до начала установки.
После выполнения вышеупомянутой команды, связь с сервером, естественно, прервется. Перезагрузка не должна занимать больше нескольких минут.
Устанавливаем текстовый редактор vim (если он уже был установлен, а многие хостеры включают его в минимальную конфигурацию, то ничего страшного не произойдет):
apt-get -y install vim
Замечание: Я знаю что матёрые администраторы обольют меня презрением, но всю первичную установку я буду описывать так, как будто она происходит от имени root. По моему мнению, во время первичной установки sudo это некому не нужные дополнительные препоны. Но в какой-то из последующих частей, ближе к концу, коснемся и этого.
vim штука очень мощная, и для замшелого пользователя Windows, весьма не привычная. С его помощью мы будем редактировать файлы в консоли. К счастью, из всей его необъятной мощи нам хватит трёх команд:
- выйти из редактора не сохраняя изменения: ESC :q! ENTER
- выйти из редактора сохранив все изменения: ESC :qw ENTER
- находясь в редакторе включить режим редактирования: i (при этом в нижнем левом углу консоли появится надпись "-- INSERT --" )
OК. Редактор у нас есть, теперь настраиваем файловую систему.
Сначала смотрим что у нас есть командой:
mount
Выдаст что-то в таком духе:
/dev/sda1 on / type ext4 (rw)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
Нас интересует первая строка «on /» которая олицетворяет собой корневую файловую систему. Если там ext3, а не ext4 — не повезло. Рекомендовать менять это самостоятельно, и описывать процесс, не стану. Это не очень сложно, но всё же я не могу отнести эту тему к доступной для новичка. Однако, это стоит того и для уверенных в себе несколько советов:
- www.debian-administration.org/article/643/Migrating_a_live_system_from_ext3_to_ext4_filesystem
- www.linuxquestions.org/questions/linux-general-1/remount-root-filesystem-read-only-547908/
- Важный хинт по второму линку, о том какие сервисы нужно убить, чтобы переключить корневую систему в режим readonly fuser -v -m /
- Убивать сервисы надёжно можно командой killall
Чем ext4 лучше ext3? — много чем, но для нас главным образом интересно то, что она быстрее.
Итак, вносим некоторые изменения.
Для начала создадим раздел для временных файлов nginx:
mkdir /var/spool/nginx
Открываем vim-ом конфигурацию файловой системы:
vim /etc/fstab
В конце файла добавляем три следующих строки (за эти три строки огромная благодарность уходит господину Orhideous ):
tmpfs /dev/shm tmpfs size=32M,rw,nosuid,nodev,noatime 0 0tmpfs — это выделение оперативной памяти под файловую систему. RAM-disk, по-простому. Первые две строки это просто ограничение доступного места в паре не нужным нам системных разделов, которые присутствуют в Debian. tmpfs — умная штука, оно захватывает память по необходимости. То, что мы тут указали это верхняя граница просто. Так что не думайте, что этими тремя строками мы сразу отъели у системы 192Mb.
tmpfs /lib/init/rw tmpfs size=32M,rw,nosuid,nodev,noatime 0 0
tmpfs /var/spool/nginx tmpfs size=128M,mode=01777,uid=33,gid=33,noatime 0 0
Последняя — это мы монтируем тот самый раздел который мы позже будем использовать для временных файлов nginx. Потому что память работает очень быстро :). В примере выше, я выделил под это дело 128Mb. Сколько выделять… В принципе, больше 128M не надо даже для весьма загруженных сайтов ( даже если у вас черте знает сколько доступных Gb, много выделять под это большого смысла не имеет). Для не больших сайтов на VPS, полагаю, хватит и 32-64M.
Обращаю внимание на uid=33,gid=33 в последней строке. Это id юзера www-data и группы www-data. Под управлением этого юзера будут работать все наши сервисы связанные в сайтом, и nginx в том числе. Этот юзер и эта группа, присутствуют в OS изначально, и по идее всегда имеют такие id. Но, не лишне, убедится в этом командами:
id -u www-data
id -g www-data
Последние что нам нужно сделать в /etc/fstab — это выставить опцию noatime нашей корневой файловой системе. Для этого ищем строку её описывающую. Она не обязательно будет первой. Это что-то что в качестве «mount point» имеет просто символ /. Cписок изначальных опций в ней может выглядеть по разному. Что-то такое:
defaultsили такое:
rwИли, даже, список чего-нибудь. Просто в конце списка опций ставим запятую и пишем noatime, больше там ничего не меняя. У нас на сервере, например, в итоге корневая строка выглядит так:
/dev/md/2 / ext4 defaults,noatime 0 0Для чего? — Linux, по умолчанию, пишет в файловую систему дату последнего обращения к файлу. Т.е. каждый раз, когда вы читаете файл, что-то дополнительно пишется. Учитывая объемы операций чтения файлов, которые демонстрирует любой сайт — это не малая работа. Для нас эта особенность — просто напрасная трата ресурсов, и опция её выключает.
Замечание: конечно это надо не столько с корневым разделом, сколько с разделом где будут лежать файлы нашего сайта и базы данных. Но, как правило, это корень. Если у вас это не так, или допустим, у вас несколько разделов из-за больших жестких дисков — проставить noatime на все из них, тоже не грех.
Замечание для VPS: существует рекомендация о том, что при использовании ext4 c VPS стоит увеличить timeout. Хотя я лично не могу ни подтвердить ни опровергнуть нужность этого, совет кажется мне разумным. Делается просто — меняется значение по умолчанию (которое 30) в файле /sys/block/sda/device/timeout на 120.
Замечание для храбрых: в случае использования ext4, есть еще одна хорошая опция, помимо noatime, положительно влияющая на производительность: data=writeback. Однако, во-первых с ней связаны, некие теоретические риски. Во-вторых просто прикрутить это в /etc/fstab может привести к печальным последствиям (система после перезагрузки свалится в readonly mode), нужно делать командой tune2fs. В общем, информацию я дал, дальше google и на свой страх и риск.
И ещё полезная заметка по теме от господина ewden : livestreet.ru/blog/14223.html
Внеся все изменения, убеждаемся что нигде ничего плечом не задели, и выходим с сохранением оных.
Теперь настраиваем hostname. По умолчанию хостер может дать серверу оригинальное имя. Наш, например, назывался мило: Debian-60-squeeze-64-minimal. Нам это не очень безразлично, потому что имя хоста используется кое-какими сервисами, например почтой. Лучше чтоб он назывался так же как наш домен без www.
Поправить это крайне просто, идём в файл /etc/hostname:
vim /etc/hostnameи правим имя на нужное нам. Потом, аналогично, идём в файл /etc/hosts
vim /etc/hostsи там везде где есть старое имя — меняем на новое.
После всех этих изменений, рестартуем систему (можно и без рестарта было бы обойтись, но так проще, а заодно и проверим ):
reboot
После успешного рестарта вызываем опять команду:
mountчтобы убедится что наши изменения файловой системы вступили в силу и команду
hostname -vчтобы убедится, что и имя изменилось.
И это, к слову, был последний рестарт, который мы будем делать.
Продолжение в следующей части:
Часть III. Некоторые настройки ядра, репозитории и базовые утилиты.
49 комментариев
Я лишь выразил свое мнение. А вы, уж коль желаете, можете при каждом коннекте по ssh ребутать сервер.
Да и кстати статья с дебиан-администратора тоже.
После ребута фс всегда переходила в readonly и соотвественно не в консоли не рассмотреть что случилось и что не так, не в журналах (логах) В readonly же всё.
Теоретически можно опробовать system rescue cd, он он предпологает, что возможна хотя-бы эмитация физ. доступа к серверу.
Сервер в инете и без фаерфола == беспорядочный секс с каждым встречным не предохраняясь.))А еще менять нужно порт SSH обязательно, поэтому 22 поменяйте на свой.
ewden, надеюсь Вы с Gmurga забабахаете совместную статью все таки по этой теме. Потому что толку, что Вы тут распинаетесь в конечном итоге не будет для того, кто будет строго следовать мануалам…
По вашему скрипту, на первый взгляд, могут быть два совета кстати.
После «случайного» iptables -F придётся либо ехать в цод, либо писать хостинг-провайдеру, пусть сделают iptables -P INPUT ACCEPT.
Два, sh как-бы сюда писать не надо. Более правильным будет в /etc/network/interfaces написать:
Вешать ssh на другой порт, всё-же не думаю нужным.
Сделать авторизацию по ключам, и фиг пролезут. Дабы не доставали, можно ещё поставить fail2ban.
Все правила просто вписать в конфиг вместо sh? Да, верно, это будет лучшим решением.
Кстати чтобы избежать курьезов, лучше убрать iptables из автозагрузки, пока не станет ясно, что все впорядке. Ну по крайней мере у меня машину можно из панельки хостера отправить в жесткий ребут или потушить.
Без fail2ban никуда, но ssh Я все равно меняю… Тем более, что владелец только Я один, поэтому мне не трудно указать порт при подключении. Тут уже от паранойи каждого зависит)
Понимаю, но надеюсь скоро она все-таки появиться ;)
Например
Если вас реально хотят взломать, то никакой другой порт не поможет.
И «нормальный» параноик бы делал port knocking, и уж точно не на базе одного iptables. Благо есть выбор инструментов различных для этого.
Насчёт автозагрузки, вы правы. Но можно сделать и круче. Для работы ресурса отдельный апплинк, а для обслуживания сервера вами отдельный, который будет в строжайшем секрете. ;)
Потеряли основной апплинк — есть резервный. Через него и работаем.
29374 открывает, 28374 закрывает.
Если будете использовать пример с правилами для IPTABLES исправьте строки с 22 портом на следующие:
Перед параметрами syn dport и т.п. должно быть два тире, а не один дефис. Видимо, когда копипастил — запортачил, сорри.
Вообще если кому-то есть что добавить по делу — я это крайне приветствую. В любой форме. Можете в комментариях оставить, можете в личке списаться со мной, можете собственную заметку написать — включим оную в общее оглавление.
Господин ewden , например уже активно сотрудничает, за что ему большущее спасибо, и следующая часть будет состоять наполовину из его рекомендаций.
Присоединяйтесь. :)
Как исходя из этого узнать тип файловой системы?
Файл /sys/block/sda/device/timeout у меня не нашелся.
Вообще не понял. В конфигурации /etc/fstab у меня изначально имеется
Где ставить запятую? :)
В общем жесть :(
А вообще, не OpenVZ ли у вас?
1. Что это означает? Необходимо последовательно нажать эти клавиши на клавиатуре или что?
2. У меня просто появляется чёрный экран, как понять что у меня открылся нужный мне файл?
2. Пустой чёрный экран означает что файла не было и vim просто открывает «пустой» файл с тем чтоб вы могли могли создать новый. Но файла /etc/fstab не быть не может… проверьте его наличие например с помощью mc
WTF???
А в /etc/fstab у меня только это