gem: unable to convert U+00A9 from UTF-8 to US-ASCII

При использовании команды gem install, отображаются сообщения о пропуске установки файлов Ruby из-за ошибки конвертации символов из таблицы UTF-8 в US-ASCII.
Вероятнее всего, в системе не была выставлена подходящая кодировка. В этом случае решить проблему можно, выбрав в качестве используемой кодировки ru_RU.UTF-8, используя команду:

dpkg-reconfigure locales

Exim4 — Не доходит отправляемая почта

В журнале Exim4 /var/log/exim4/mainlog постоянно пополняются записи:

Our system has detected an unusual rate of\n421-4.7.0 unsolicited mail originating from your IP address. To protect our\n421-4.7.0 users from spam, mail sent from your IP address has been temporarily\n421-4.7.0 rate limited.

Сие говорит о том, что сервер-получатель отвергает корреспонденцию из-за подозрения на спам (слишком частые отправления писем). Следует отследить в журнале почтовые адреса, от имени которых отправляются письма. Если почтовые адреса отправителей Вам не известны, то скорее всего вредоносный код генерирует рассылку, от имени несуществующих почтовых адресов, подключенных доменов.
Следует посмотреть объем неотправленных сообщений в директории /var/spool/exim4/input. Если сообщения содержат спам и их объём велик — следует выявить вредоносный код, генерирующий эти письма.
К примеру, если сервер используется для работы сайтов, написанных на PHP, то для обнаружения вредоносного кода следует изучить журнал /var/log/php-mail.log. По количеству генерируемых сообщений, обнаружить вредный сценарий довольно просто.
После устранения источника проблемы, следует остановить почтовый сервер командой killall -9 exim4 (команда service exim4 stop вероятнее всего не прервёт процесс отправки замороженных почтовых сообщений). И затем очистить директорию со скопившейся корреспонденцией, командой find /var/spool/exim4/input -delete. После чего, почтовый сервер можно запустить вновь: service exim4 start.
Для пресечения подобной проблемы в будущем, можно ограничить список адресов, корреспонденция с которых будет отправляться сервером Exim4.

Possible missing firmware

Ошибка при установке пакетов:

W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module r8169

Решением является установка пакета firmware-realtek.

GPG error — NO_PUBKEY

Бывают случаи, когда при выполнении команды apt-get update, выводится ошибка, где упоминается GPG:

W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://www.deb-multimedia.org stable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 5C808C2B65558117

Номер публичного ключа при этом может быть иным.
Решением проблемы является добавление в систему публичного GnuPG-ключа репозитория, из которого осуществляется попытка установить пакет (который, в свою очередь, подписан данным ключом):

gpg --keyserver pgpkeys.mit.edu --recv-key 5C808C2B65558117
gpg -a --export 5C808C2B65558117 | apt-key add -

Disk quota exceeded при наличии свободного места

Порой при работе сайта на арендованном VPS может появиться подобная ошибка:

Warning: mkdir(): Disk quota exceeded
in /var/www/site.ru/logger.php
on line XXX Can’t log exception

Работа сайта может быть нарушена при обращениях к БД. Сама БД при перезагрузке может выдавать ошибку:

mysql open: Disk quota exceeded

Аналогичную ошибку при запуске могут выдавать и все остальные программы.
Если при проверке наличия свободного места (команда df -h) мы видим, что свободного места ещё достаточно, то вероятно дело в ограничении максимального количества дескрипторов, установленных хостером. Следует обратиться в службу технической поддержки, уточнить, подошли ли Вы к пределу количества инод, и если это так, то попросить увеличить лимит. После этого попытаться заново запустить все необходимые службы.

SSHD — POSSIBLE BREAK-IN ATTEMPT!

Запись в журнале /var/log/auth.log вида

sshd[16793]: Address XXX.XXX.XXX.XXX maps to somedomain.com, but this does not map back to the address — POSSIBLE BREAK-IN ATTEMPT!

говорит о том, что при попытке проверить обратное сопоставление домена, полученный IP-адрес отличается от IP-адреса клиента SSH.
Это вполне распространённая ситуация, например: сервер А обслуживает домен somedomain.com и использует его в качестве своего имени, сам сайт somedomain.com физически находится на сервере Б; сервер А пытается подключиться к серверу С; сервер С проводя обратное сопоставление доменного имени клиента видит, что у домена somedomain.com должен быть IP-адрес сервера Б, который отличается от IP-адреса сервера А.
Данная запись может служить поводом для блокировки клиента, например программой fail2ban. Если IP-адрес XXX.XXX.XXX.XXX, указанный в записи журнала, является доверенным, а программа защиты блокирует этот адрес под предлогом спуфинга, то данную проблему можно решить добавив в файл конфигурации /etc/ssh/sshd_config строку (или отредактировав, при её наличии):

UseDNS no

Альтернативным способом отключения блокировок является правка фильтров программы защиты, например всё той же fail2ban, то есть исключение вышеуказанной фразы о взломе из регулярных выражений фильтров.

Open file limits

Часто при использовании какой-либо программы, при открытии большого количества файлов она сваливается, т.к. упирается в ограничение (по умолчанию 1024 открытых файла), выводя ошибку: failed (24: Too many open files). Текущее использование открытых файлов программой можно узнать так:

lsof -u процесс | wc -l

Многие программы умеют изменять ограничения самостоятельно, поэтому задать ограничение на количество открытых файлов можно в конфигурационном файле. Например, используя параметр open_files_limit в конфигурационном файле my.cnf сервера MySQL, или параметр worker_rlimit_nofile для Nginx.
Однако, заданные значения в конфигурационных файлах этих программ могут не применяться при перезапуске. В этом случае ограничение накладывается системой.
Можно узнать ограничение системы для текущего пользователя с помощью команды:

ulimit -a

А для всей системы в целом:

sysctl fs.file-max

Установить же новое значение для ограничения по файлам для текущего пользователя можно так:

ulimit -n значение

Если новые ограничения устанавливаются пользователем root и им же перезапускается Ваша программа, то, несмотря на то, что программа работает от имени другого пользователя, у неё должны вступить в силу новые настройки. Перезапустив программу, можно проверить, применились ли новые значения. Например, выполнить в MySQL команду:

show variables like ‘open_files_limit';

Однако, новые значения ограничений, устанавливаемые утилитой ulimit действуют в рамках одной сессии. Это означает, что при следующем подключении, настройки ограничений системы вернуться к исходным. Чтобы не использовать каждый раз данную утилиту, можно задать параметры ограничений в файле /etc/security/limits.conf. Например, для снятия ограничения на количество одновременно открытых файлов (до 65к, чего хватает в большинстве случаев) для всех пользователей, добавить в конец файла строки:

* soft nofile 65536
* hard nofile 65536

Также следует знать, что файл limits.conf является конфигурационным файлом PAM. А далеко не все программы при запуске используют PAM. Если Ваша программа из числа тех, что не используют PAM, то перед правкой файла limits.conf следует проверить директорию /etc/default/ на наличие конфигурационных файлов Вашей программы. И, если таковые имеются, добавить в конец её конфигурационного файла команду «ulimit -n 65536». Если же в /etc/default/ конфигурационных файлов Вашей программы нет, то можно принудить использовать настройки limits.conf для всех, добавив в конец файлов /etc/pam.d/common-session и /etc/pam.d/common-session-noninteractive (при наличии оного) строку:

session required pam_limits.so

После чего перезагрузить систему.

Завершение зависшего процесса

В настольной версии Ubuntu, если зависло какое то окно, его можно убить следующим образом: нажимаем Alt+F2, пишем в строку поиска «xkill», выбираем найденную утилиту, после чего тыкаем в зависшую программу изменившимся курсором мыши.

VMware — W110: Failed to build vmnet. Failed to execute the build command.

Если после установки VMware не запускается и пишет в /tmp/vmware-root/vmware-modconfig-XXXX.log ошибку:
W110: Failed to build vmnet. Failed to execute the build command.
Можно попробовать следующее:
1. создаём файл vmnet313.patch в домашней директории и пишем в него:

205a206
> #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 13, 0)
206a208,210
> #else
> VNetFilterHookFn(const struct nf_hook_ops *ops,        // IN:
> #endif
255c259,263
<    transmit = (hooknum == VMW_NF_INET_POST_ROUTING);
---
>    #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 13, 0)
>       transmit = (hooknum == VMW_NF_INET_POST_ROUTING);
>    #else
>       transmit = (ops->hooknum == VMW_NF_INET_POST_ROUTING);
>    #endif

2. открываем терминал и переходим с директорию модулей VWware

cd /usr/lib/vmware/modules/source

3. извлекаем модули vmnet

tar -xvf vmnet.tar

4. патчим ранее созданным файлом

patch vmnet-only/filter.c < ~/vmnet313.patch

5. кладем модуль обратно в тарбол

tar -uvf vmnet.tar vmnet-only

6. удаляем более ненужную директорию

rm -r vmnet-only

7. запускаем vmware-modconfig

/usr/lib/vmware/bin/vmware-modconfig —console —install-all