Иногда настраиваемый сервер имеет FQDN имя, которое им обрабатываться не должно, но именоваться он должен именно так. В тривиальной настройке exim будет трактовать почту на этот домен локальной и складывать в /var/mail или подобную директорию для локальной почты. Чтобы домен и соответствующая почта не считалась локальной можно это явно прописать в /etc/exim4/hubbed_hosts, например
example.com: mx.example.com
На некоторых компьютерах у меня есть Windows 7 и достало постоянное желание Майкрософт обновить ОС до 10 версии. Отключается коротко и быстро:
wusa.exe /uninstall /kb:3035583
При обновлении MySQL от версии 5.6 его показатели не читаются мунином. В логах появляется ошибка:
Unknown section: INDIVIDUAL BUFFER POOL INFO at /etc/munin/plugins/mysql_innodb_rows line 1098.
Ошибка возникает в результате того, что мунин не распознает новую секцию (INDIVIDUAL BUFFER POOL INFO) в ответе СУБД. Наикратчайший (однако, не лучший) путь вылечить — отключить эту секцию. Для этого в скрипте, который парсит параметры БД /usr/share/munin/plugins/mysql_, находим немного перед 1098 строчкой определение секции
my %section_map = (
и добавляем в самом начале этой секции
'INDIVIDUAL BUFFER POOL INFO' => \&skip,
Проверить корректность запуска можно munin-run на любом из собирающих скриптов. Например:
cd /etc/munin/plugins munin-run mysql_innodb_rows
Иногда Linux отказывается перезагружаться стандартными коммандами. Тогда бывает полезным следующий низкоуровневый способ с помощью механизма SysRq. Для ребута комманда такая:
echo b >/proc/sysrq-trigger
Если команда не проходит сразу, то возможность использования Magic SysRq надо включить
echo 1 > /proc/sys/kernel/sysrq
Также есть полезные для размонтирования ФС (u) и синхронизации дисков (s), которые можно сделать до ребута.
В минимальной установке дебиана конфигурация пакетов после установки происходит с помощью текстового интерфейса, что не всегда удобно. Перевод в "менюподобный" интерфейс (с использованием libncurses) происходит доустановкой пакета dialog:
apt-get install dialog
Есть ряд ПО под java, которое лучше работает на оригинальной оракловской жаве. Дебиан содержит открытый пакет openjdk, однако его недостаточно. А оригинальные оракловские бинарники Java отсутствуют в дебиановских репозитариях вследствие строгой лицензионной политики. Поставим вручную.
Корректный (через репозитарий) способ состоит в использовании установщика из репозитария. Но можно короче и чище сделать это вручную. Для этого качается нужный дистрибутив JDK (или Server JRE), поскольку оракл требует принятия их лицензии, то напрямую без куков скачать не получится. Поэтому качаем локально, заливаем на сервер. Устанавливать будем в
mkdir /opt/jdk tar -zxf jdk-8u5-linux-x64.tar.gz -C /opt/jdk
Проверяем, что все распаковалось, а далее делаем симлинк на исполняемые файлы
update-alternatives --install /usr/bin/java java /opt/jdk/jdk1.8.0_66/bin/java 100 update-alternatives --install /usr/bin/javaс javaс /opt/jdk/jdk1.8.0_66/bin/javaс 100
Проверяем, что все поставилось корректно
update-alternatives --display java update-alternatives --display javaс
Или альтернативный способ
java -version javac -version
Done!
Из быстрых и чистых способов поставить жаву, это скорее всего самый короткий.
Отлично, теперь dovecot поддерживает xz-сжатие. Включается все тривиально:
# Enable zlib plugin globally for reading/writing:
mail_plugins = $mail_plugins zlib
# Enable these only if you want compression while saving:
plugin {
zlib_save_level = 6 # 1..9; default is 6
zlib_save = gz # or bz2, xz or lz4
}
После обновления линуксового ядра с очень старого дистрибутива Debian на 3.16.xxxx в jessie иногда вылазит следующая ошибка
No irq handler for vector (irq -1)
Решается использованием опций pci=nomsi,noaer при загрузке ядра. Чтобы опции использовались постоянно целесообразно их прописать в /etc/default/grub:
GRUB_CMDLINE_LINUX="pci=nomsi,noaer"
Без правки системы загрузки также помогает остановка демона irqbalance
/etc/init.d/irqbalance stop
С учётом, что сервер относится к категории Legacy и на нём старый софт, а перезагрузки его в лучшем случае происходят раз в год, второй способ в этом случае предпочтителен.
Возникает в Dovecot/Thunderbird.
Решается отключением OCSP:
Preferences -> Advanced -> Certificates -> Validation -> Uncheck "Use the Online Certificate Status Protocol (OCSP) to confirm the current validity of certificates"
Часто нужно посмотреть "активные" строчки в конфиге, т.е. исключить из него комментарии и пустые. Это просто делается грепом
grep -v '^$\|^\s*\#' some-config.conf
Или более коротко, не учитывая комментариев, начинающихся не с начала строки:
grep -v '^$\|^#' some-config.conf
Оказывается, в разработке и поддержке серьезных открытых проектов тоже встречаются мудаки.
Кто обновляет nagios-nrpe-server из wheezy в jessie и использует в конфигах опцию dont_blame_nrpe — опция работать не будет. Чтобы она работала нужно пересобрать пакет.
Производительность — один из наиболее заметных параметров системы. Именно на её недостаток чаще всего жалуются пользователи. Ниже приведены некоторые элементарные способы по анализу производительности системы.
Часто ошибочно считает, что поднять скорость системы можно хорошо "оптимизировав" конфиги. Это редко бывает так. Оригинальные стоковые конфиги репозиторного софта подходят для решения многих задач. Их можно (и нужно) менять для достижения задач конкретного проекта. Естественно, все изменения следует сопровождать тестами производительности, а для этого должны быть соответствующие методики и инструменты.
Прежде чем что-то пытаться менять в конфигурации необходимо найти проблемные (узкие) места в системе. В общем случае методика исследования следующая:
munin, Zabbix. В более продвинутом случае — свои плагины к этим системам мониторинга или собственные скрипты. Если пару дней назад всё работало отлично, а сейчас какие-то "тормоза" — мониторинг поможет установить их источник. Кроме этого, мониторинг позволяет обнаружить еще не проявившиеся проблемы, когда используемые ресурсы системы исчерпываются.Load average легко собираются любым мониторингом круглосуточно и его необходимо анализировать. Максимальное значение LA (в часы наибольшей нагрузки) не должно превосходить возможностей системы, т.е. количества её ядер CPU. В противном случае неизбежно замедление работы приложений, причем с увеличением LA выше возможностей системы будут возрастать потери на переключении контекста.
Когда LA достаточно высок имеет смысл посмотреть на что именно расходуются ресурсы процессора. Простейший способ это сделать — посмотреть процессы с наибольшим процессорным временем (TIME) в выводе утилит top, htop или ps aux. Далее уже пытаться снизить нагрузку именно на этом звене.
Часто считается, что процессорная мощность это основной показатель, влияющий на общую производительность системы. Это действительно так лишь в некоторых узких применениях, например в численных расчетах. Во многих других прикладных задачах это не так.
В тех же top и htop следует обратить внимание на процессы в состоянии D, которое обычно соответствует ожиданию ввода-вывода процесса, а также на заполнение свопа. Но об этом ниже.
Коротко (для скриптов мониторинга) значение LA можно взять из параметров системы:
cat /proc/loadavg
Вручную — легче в top и htop.
Характеристики использования процессорного времени отображается также командой vmstat:
$ vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 7596 329216 13260 14506756 0 0 4625 26 42 145 4 1 81 13 0
vmstat принимает 2 аргумента: время в секундах, в течение которого необходимо наблюдать за системой, и количество генерируемых отчетов. Эту утилиту полезно запускать для наблюдения, например для формирования 10 отчетов по 1 минуте каждый:
vmstat 60 10
Колонки us (user) и sy (system) означают соответсвенно процессорное время затраченное на пользовательские процессы (демоны и прикладного ПО) и системное. Для большинства систем нормально, если время распределяется между ними поровну.
in (interrupts) и cs (context switches) это количества прерываний и переключений контекста, и оба эти параметра — накладные расходы системы и их не должно быть много.
Разбивку использования CPU по ядрам можно получить с помощью mpstat, например по всем ядрам
$ mpstat -P ALL Linux 3.2.0-4-amd64 (sys01) 01/05/15 _x86_64_ (16 CPU) 16:09:51 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 16:09:51 all 3.55 18.39 9.83 1.24 0.00 0.50 0.00 0.00 66.49 16:09:51 0 5.85 43.47 11.04 1.62 0.00 6.79 0.00 0.00 31.23 16:09:51 1 4.23 29.35 10.81 1.34 0.00 0.11 0.00 0.00 54.17 16:09:51 2 3.86 24.70 10.17 1.26 0.00 0.11 0.00 0.00 59.90 16:09:51 3 3.66 22.73 9.64 1.10 0.00 0.13 0.00 0.00 62.74 16:09:51 4 6.01 15.49 8.84 4.94 0.00 0.26 0.00 0.00 64.47 16:09:51 5 3.15 12.93 8.29 1.43 0.00 0.08 0.00 0.00 74.13 16:09:51 6 2.93 12.90 8.11 1.08 0.00 0.08 0.00 0.00 74.90 16:09:51 7 2.79 14.15 8.43 0.87 0.00 0.07 0.00 0.00 73.69 16:09:51 8 4.01 24.11 8.93 0.93 0.00 0.04 0.00 0.00 61.98 16:09:51 9 2.89 15.37 10.24 0.84 0.00 0.07 0.00 0.00 70.60 16:09:51 10 2.91 15.56 10.64 0.85 0.00 0.07 0.00 0.00 69.98 16:09:51 11 2.78 15.35 10.61 0.81 0.00 0.09 0.00 0.00 70.36 16:09:51 12 2.89 11.69 8.56 0.84 0.00 0.04 0.00 0.00 75.98 16:09:51 13 3.58 12.81 12.09 0.66 0.00 0.03 0.00 0.00 70.83 16:09:51 14 2.95 12.32 11.24 0.66 0.00 0.03 0.00 0.00 72.80 16:09:51 15 2.36 11.60 9.59 0.59 0.00 0.04 0.00 0.00 75.82
Выводимые параметры утилиты понимающему человеку там очевидны.
Использование оперативной памяти "на ходу" анализируется с помощью утилит htop, vmstat, free. Лучше — смотреть в динамике в мониторинге, том же мунине. Прежде всего необходимо обратить внимание на использование свопа, который в хорошей должен быть почти свободным и не увеличиваться/уменьшаться в определённое время суток.
В выводе
$ free -h
total used free shared buffers cached
Mem: 47G 44G 2.3G 0B 559M 26G
-/+ buffers/cache: 18G 29G
Swap: 15G 3.6G 12G
если окажется мало free-памяти, но много cached — это нормально. Память может быть занята страничным кэшем (cached), который многократно увеличивает скорость дисковых операций. Когда "свободной" (free) памяти действительно много это даже плохо и означает, что она не полностью используется. То же самое относится к выводу vmstat.
Статистику по ввода-выводу системы лучше собирать пакетами мониторинга. Параметр системы, на который в первую очередь необходимо обратить внимание — iowait, т.е. ожидание ввода-вывода. Его подробные значения можно получить, например, с помощью mpstat:
mpstat -P ALL
Сводные значения есть также в top, vmstat.
Часто признаком наличия проблем с вводом-выводом является большое количество процессов в состоянии D (uninterruptible sleep), в которое процесс переходит при ожидании ввода-вывода. Это не обязательно означает, что дело именно в I/O, но такая ситуация в любом случае должна быть исследована.
Счетчики чтения-записи с дисковых устройств получаются по
$ vmstat -d
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
sda 90878564 7454833 2829423640 647949492 205895042 265140200 14858972810 2510368504 0 448274
sdb 455801809 14612605 57375867578 2021813576 434699644 365377967 109699014136 4291627964 0 2081456
sdd 94938371 343221533 57971885640 3782143884 34980046 34425685 8816083324 1994769084 0 449787
sdf 83996804 354254620 57971510608 1338153836 35203200 34649634 8822861163 2201253492 0 462982
sde 83274303 354838922 57968955195 1266856936 34793484 34477071 8818425628 2217294360 0 461751
sdc 112569402 325806501 57972989224 4284077532 35217039 34782607 8820518859 2068813212 0 446935
sr0 0 0 0 0 0 0 0 0 0 0
loop0 0 0 0 0 0 0 0 0 0 0
loop1 0 0 0 0 0 0 0 0 0 0
loop2 0 0 0 0 0 0 0 0 0 0
loop3 0 0 0 0 0 0 0 0 0 0
loop4 0 0 0 0 0 0 0 0 0 0
loop5 0 0 0 0 0 0 0 0 0 0
loop6 0 0 0 0 0 0 0 0 0 0
loop7 0 0 0 0 0 0 0 0 0 0
md0 289404098 0 44556083939 0 123718867 0 17627362527 0 0 0
Еще более удобная утилита для этого — iostat. Как и vmstat, она принимает 2 параметра (время наблюдения и количество отчетов). Полезно снять несколько расширенных отчетов за некоторый промежуток времени, например, минуту:
$ iostat -x 60 5
avg-cpu: %user %nice %system %iowait %steal %idle
7.83 47.27 21.99 1.52 0.00 21.39
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.50 42.87 7.70 40.28 37.27 1732.40 73.76 5.40 112.63 13.26 131.62 2.05 9.83
sdb 9.52 56.27 85.38 60.47 1459.00 5955.80 101.68 14.10 96.69 13.17 214.63 2.46 35.85
sdd 0.08 0.27 0.08 1.47 11.27 40.27 66.49 0.01 5.59 24.80 4.50 4.90 0.76
sdf 0.22 0.50 0.15 2.35 30.27 53.75 67.21 0.02 6.43 31.11 4.85 4.83 1.21
sde 0.17 0.45 0.15 2.28 24.47 44.45 56.64 0.01 4.77 11.11 4.35 3.12 0.76
sdc 0.17 0.32 0.73 1.53 25.47 49.57 66.21 0.02 8.44 12.91 6.30 4.68 1.06
md0 0.00 0.00 1.75 3.25 91.47 93.52 73.99 0.00 0.00 0.00 0.00 0.00 0.00
и по результатам сделать выводы, на какие устройства идет запись или чтение, и как перераспределить содержимое файловой системы для более эффективного использования. Там же есть статистика по iowait.
В первую очередь при определении характеристик сетевых интерфейсов необходимо посмотреть количество ошибок на них, что элементарно делается древней командой ifconfig. Если интерфейс показывает существенное количество ошибок, следует удостовериться в корректности работы сетевой карты и физической сети до маршрутизатора.
Обязательно необходимо убедиться, что настройки скорости и дуплексного режима верны для сетевой карты. Это можно сделать (и изменить) с помощью утилит ethtool и mii-tool:
ethtool eth0
Обычно сетевые карты автоматически узнают сеть, её скорость и дуплексность, но это не всегда так. Иногда встречаются системы, работающие медленно лишь потому, что сетевая карта работает в полудуплексном режиме, что очень сильно снижает производительность и задержку даже ненагруженных систем. В случае полудуплекса или низкой автоопределённой скорости интерфейса, её имеет смысл повысить
ethtool -s eth0 autoneg off speed 100 duplex full
Полезно посмотреть и другие параметры интерфейсов, грепнув их вывода ядра:
dmesg | grep -i eth
Пиковую загрузку сети лучше (как и многое остальное) мониторить постоянно и автоматически, например, тем же munin. Ориентироваться лучше на пиковую нагрузку — по ней должен быть определённый запас и в её время не должно быть больших значений iowait.
Хорошую статистику по сети и разбивку по типам траффика можно получать с помощью ntop.
Многие убеждены, что производительность можно многократно поднять ("оптимизировать") чисто софтовыми способами, т.е. изменением настроек операционной системы и прикладного софта. На деле это не всегда так.
Ядра современных дистрибутивов Linux уже хорошо настроены в плане производительности. Если задача типовая и "железо" устраивает — менять ничего не нужно. Изменение каких-либо параметров через sysctl на большинстве серверных задач не повысит скорость работы, а при плохом подгоне даже понизит. Тем более, следует скептически относиться ко всем интернет-советам по оптимизации (в том числе, описанным на этом сайте).
Какие-то параметры работы можно оптимизировать: настройками прикладного софта, перераспределением файловой системы. Но большинстве случаев наилучший способ повысить производительности системы — "железный", т.е. изменением аппаратных характеристик сервера или распределением и балансировкой нагрузки по разным серверам. При высокой нагрузке на I/O поможет использование RAID, программных (mdadm) или аппаратных.
На масштабирование "железа" и стоит в перспективе ориентироваться и не строить иллюзий по поводу софтовых оптимизаций.
Есть такая древняя утилита для печати двумерного штрих-кода на платежках BiPrint. К сожалению, утилита очень редко обновляется и, что ещё хуже, — всё ещё используется некоторыми российскими банками.
Проблема возникает при попытке установке BiPrint на новые операционные системы. В частности, на Windows 8.1 x64. Кто пытался поставить BiPrint, знает, что последний требует файл ep200.gpd из драйверов старого Epson-принтера. Этот файл легко найти и скачать, однако, он не подписан Microsoft и нормальным образом не добавляется в систему.
Тем не менее, существует вполне рабочее альтернативное решение. Если коротко, то решается проблема следующим образом:
Оказывается, существует консольная Linux утилита для восстановления забытых паролей биос. И даже есть в дебиановских репозитариях. Будем иметь ввиду.
В процессе настройки серверов нередко требуется проверить качество работы и скорость каналов связи. Для этого существует ряд удобных утилит. Ниже описывается работа с двумя полезными утилитами: iperf, mtr.
Другая наиболее важная характеристика сети — скорость канала. Замерить скорость на прием и на передачу можно с помощью утилиты iperf. Для замера требуется запустить утилиту на одном из хостов в режиме сервера, а на другом — в режиме клиента. Запустим её в режиме сервера:
iperf -s
Если требуется проверять скорость до хоста постоянно, то iperf может быть запущен и в режиме демона с опцией -D.
На другой машине в режиме клиента с необходимыми параметрами. Например, запустим тестирование ширины канала в 6 параллельных потоков с отдельными замерами скорости на передачу и на приём:
iperf -c example.com -r -P 6
Аналогично можно запустить тестирование на одновременную передачу и приём:
iperf -c example.com -r -P 6
По умолчанию один тест длится 10 секунд. Время теста может быть изменено ключем -t, что бывает полезно для повышения репрезентативности результата. По умолчанию утилита тестирует канал по TCP-соединению. Тип соединения на UDP может быть изменен соответствующим ключом (-u), при запуске клиентской и серверной частей. iperf имеет много других полезных параметров (которые я редко использую) — они все естественным образом приведены в мануале.
Утилита mtr является аналогом другой широко известной утилиты сетевой диагности traceroute. Наиболее простой способ её применить — запустить с параметром другого хоста:
mtr example.com
В результате получим список промежуточных хостов, долю потерявшихся пакетов и задержки до каждого из хостов. Кроме работы с утилитой в интерактивном режиме, в ней можно получить отчет посредством ключей -–report, -–report-wide.
Иногда сеть ведет себя по разному для больших и маленьких сетевых пакетов. В таком случае можно указать вторым параметром желаемый размер пакета. При этом размер пакета можно сделать случайным, тогда размер указывается отрицательным числом, а модуль этого числа — максимальный размер пакета.
mtr example.com -1000
Для вордпресса есть удобный плагин подсветки исходного кода SyntaxHighlighter MT. По умолчанию он отображает так называемый toolbar: маленький зеленый квадратик-ссылка с вопросом в крайнем верхнем углу текста. В документации на сайте разработчика описывается, как его можно отключить. Однако, канонического конфигурационного файла (как и конфигурации в самом WordPress) в плагине не наблюдается. Приходится идти обходным путём, а именно отключать toolbar в самом исходном коде. Сделать это можно, например, в файле brushTypes.js, определяющим типы подсветки для разных языков добавлением
SyntaxHighlighter.defaults['toolbar'] = false;
перед строчкой
SyntaxHighlighter.all();
После этой правки ничего лишнего с исходным кодом не отображается.
Существует несколько способов управления пользовательскими кронтабами.
Наиболее простой из них — редактирование файла с помощью crontab:
crontab -u USER -e
Также возможно выполнение от учетной записи пользователя
crontab -e
что существенно снижает риск по ошибке записать крон от другого пользователя.
Другой способ, обычно применяемый при переносе конфигураций серверов — копирование пользовательских кронтабов, находящихся в директории /var/spool/cron. При синтаксически корректных исходных конфигах способ работает безотказно. Единственное, что необходимо для его работы: "тронуть" (touch) конфиги после выкладки или перезапустить крон. Иначе, они не будут выполняться.
Метод реализуется командой
crontab -u USER /tmp/old-crontab
которая включает в систему уже существующий конфиг крона. При переносе конфигурации сервера, это вероятно самый безопасный вариант.
Реализуется с помощью различных систем централизованного управления конфигурацией вроде Puppet. Работает очень хорошо, но применять его целесообразно только на достаточно большом количестве масштабируемых серверов.
Фундаментальным и очень полезным качеством всех линуксов-юниксов является их модульность и возможность сборки из "кирпичиков" нужных инструментов. Это прекрасно иллюстрируется следующим примером из мануала утилиты netcat. Эта утилита передачи и приема произвольных данных по протоколам tcp/udp позволяет сделать элементарный и полностью рабочий шелл для работы с удалённым хостом. И это только используя эту утилиту и стандартные средства Linux вроде pipe и перенаправления данных.
На удалённой машине создаем трубу
$ rm -f /tmp/f; mkfifo /tmp/f
берем из неё данные, исполняем и результат толкаем в netcat, а его ответ обратно в трубу:
$ cat /tmp/f | /bin/sh -i 2>&1 | nc -l 127.0.0.1 1234 > /tmp/f
В результате получаем упрощённую нешифрованную версию ssh.
Системное администрирование серверов в большой степени основано на регулярно исполняемых скриптах. Естественно, результат исполнения скриптов нужно проверять и иногда — логировать. Наиболее простой способ это сделать — использовать перенаправления ввода-вывода 2>&1 совместно с &>>. Однако, есть альтернативный (и в чём-то более удобный) способ это сделать, напрямую в syslog, с помощью команды logger. Тогда логирование сводится к командам вроде
some_script.sh 2>&1 | logger -i
По умолчанию, в стоковой установке WordPress формирует постоянные ссылки (permalinks) для постов неотличимые по внешнему виду от статических страниц. Если WP используется как CMS это может быть нежелательно. В случае CMS часто бывает логичней выкладывать статические страницы с пермалинками начиная с корня /, а посты — начиная с некоторого слова, подсказывающего, что пост относится к блогу, например /blog. Это возможно сделать стандартными средствами вордпресса.
Для того, чтобы настроить WP, чтобы он добавлял префикс /blog в начале пермалинков делаем следующее:
Settings -> Reading есть возможность настроить статические страницы по умолчанию (front pages) для основного сайта и для блога. Для сайта в случае использования WP как CMS она обычно настроена. Если не настроена, то создаём такую или выбираем из существующих. Для блога — создаем новую пустую и ставим к ней пермалинк /blog.Settings -> Permalinks меняем формат пермалинков для постов на /blog/%postname%. Предлагаемые по умолчанию настройки RewriteRules в .htaccess подходят и для нашего случая, их не трогаем.blog/category и blog/tags.После этого всё работает.
В интернетах находятся и другие how-to по данному вопросу. То, что выше — короткая выжимка из этого.