Проблема с локалью на Debian после установки какого-то пакета

Работать в шелле невозможно. Половина текста вот такой трэш:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = "en_GB.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Возможные варианты решения (у всех своя причина и потому свой путь):

dpkg-reconfigure locales
dpkg-reconfigure console-setup
update-locale

Ошибка ODBC-подключения

Проверяем ODBC настройки:

[root@localhost etc]# isql -v default
[MYODBCUtilReadDataSource.c][233][ERROR] Unknown attribute (Servername).
[MYODBCUtilReadDataSource.c][233][ERROR] Unknown attribute (Username).
[ISQL]ERROR: Could not SQLConnect

такие вещи бывают, если неправильно указать поля в ODBC, например Servername вместо Server или Username вместо User.

Проблема не в том, что Вы опечатались. Проблема в том, что в интернете половина примеров выложены именно с неправильными именами. Причина - отсутствие единого стандарта :( Тут ничего не поделать. Примеры для CentOS совсем не подходят для SLES и наоборот, хотя эти системы очень похожи.

PPTP с авторизацией в LDAP через RADIUS

Жизнь штука интересная. Всегда преподносит сюрпризы. К сожалению, прекрасный VPN продукт, лучший в мире из софтверных, - OpenVPN, оказался плох тем, что не поддерживается на нативном уровне ни одной популярной операционной системой. А ставить клиента, сертификаты и конфиги оказалось непосильной задачей для особо "интеллектуальных" людей (и это при простейшем мануале в три клика).
"Искаропки" и Windows и Ubuntu и MacOS и Symbian и Android поддерживают только PPTP.

Итак приступим. Схема будет такая:
клиент соединяется по PPTP с PPTP-сервером. Организуется тоннель. Внутри этого тоннеля соединяются PPP-клиент и PPP-сервер и первый запрашивает у второго логин с паролем в форме MS-CHAPv2 (почему именно его - опишу ниже). PPP-сервер берет эти данные и просит RADIUS-сервер провести аутентификацию. Так как наши пользователи хранятся в LDAP-каталоге, то RADIUS обращается к этому каталогу, биндится от имени администратора, берет из него хэши пользователя и сравнивает с теми, что ему дал PPP-сервер. После чего дает ответ PPP-серверу пускать клиента или не пускать.


Теперь маленькая ремарка о том, почему единственно возможный вариант передачи пароля - MS-CHAPv2 (v2 - вторая версия). Есть четыре основных варианта: PAP (без шифрования), CHAP (с шифрованием), MS-CHAPv1/v2 (с шифрованием, совместимым с NT/LM) и EAP.
PAP для нас не подходит потому, что по умолчанию при создании PPTP-подключения Windows требует шифрования. Можно это изменить в свойствах настройки, но это требует целых два клика мышью, что опять таки делает задачу невыполнимой для многих.
CHAP для нас не подходит потому, что по умолчанию в LDAP хранятся только NT/LM хэши паролей, а CHAP-хешей там нет. Провести аутентификацию RADIUS не сможет. Можно было позаботиться об этом при разворачивании LDAP-сервера, чтобы были и CHAP-пароли, но теперь уже поздно. Если добавить это поле, что нужно заставлять клиентов сменить пароль, чтобы это поле заполнилось.
EAP, если я не путаю, не будет работать с LDAP по каким-то другим причинам, описанным в конфиге его модуля. Могу ошибаться. Не суть важно.
Остается настраивать MS-CHAPv2.

Свершилось: вышел CentOS 6

Скачать можно здесь. Но внимание на заметку тестировщиков:

Mirrors are picking up the release. The mirrors will remain "bit-flipped" (read: locked from public access) until it's decided that the release has made it to a sufficient number of mirrors for release. Watch the CentOS-Announce mailing list and/or #centos IRC channel for more info on the release. Anything you download from mirrors before the announcement may not be the final packages, and you may put your system into a funky state -- use at your own risk.

Думаю, будет уместно дать ссылку на детальный обзор улучшений в RHEL 6.

Установка Nagios на Debian с авторизацией в LDAP

Для начала устанавливаем вэб-сервер, через который мы будем работать с Nagios, а также включаем аутентификационные и авторизационные модули:

aptitude install apache2
a2enmod auth_basic authn_file authnz_ldap authz_default authz_groupfile authz_host authz_user

Далее ставим сам Nagios, документацию к нему, которая будет доступна из вэб-интерфейса, плагин, при помощи которого Nagios будет обращаться за данными к другим машинам, а также утилиты для построения графиков:

aptitude install nagios3 nagios3-doc nagios-nrpe-plugin nagiosgrapher

При установке aptitude поставит все необходимые зависимости.

По умолчанию доступ к панели Nagios осуществляется как-то по-деревенски:
http://IP.ADD.RE.SS/nagios3, а мы сделаем красиво: http://nagios.nodesquad.com
Для этого создадим конфиг виртхоста:

Организация сервера сбора логов со всех серверов на единый syslog-сервер

На syslog-сервере.

Открываем настройки rsyslog и раскомментируем модуль и порт (желательно TCP):

vim /etc/rsyslog.conf

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

После изменений перегружаем демон:

invoke-rc.d rsyslog restart

На стороне каждого из логируемых серверов.

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

vim /etc/rsyslog.conf

# transfer logs to common Syslog-server
*.*   @@syslog.nodesquad.com:514

После изменений перегружаем демон:

invoke-rc.d rsyslog restart

А еще есть возможность собирать dmesg со всех серверов!

Ну все, теперь можно парсить логи всякими logrotate'ами или чем душе угодно. Все укромно, все в одном месте. Очень рекомендую еще поставить LogAnalyzer с приятной вэб-мордочкой и удобным управлением и фильтрами. В репо Debian его нету, так что можно поставить deb-пакет отсюда.

Ну и в качестве наводки, вот еще более продвинутая система: Graylog2.