Русский в консоли Ubuntu Server

В Ubuntu в очередной раз поломали отображение национальных шрифтов в консоли (именно в консоли, а не в эмуляторе терминала). Я, помнится, около 2008 года уже помог починить, но «технологии шагнули далеко вперед» 🙂

Что случилось и как починить — читайте в статье: http://help.ubuntu.ru/wiki/russian_font_in_console.

Приводить полностью не буду, если кратко, то надо добавить FRAMEBUFFER=Y в /etc/initramfs-tools/initramfs.conf и после перенастройки консоль будет оставаться правильно настроенной при перезагрузке.

 

Это реклама Русскоязычной пользовательской документации Ubuntu, в составлении которой можно и нужно поучаствовать, если вы владеете информацией и хотите поделиться с людьми.

комментария 2 »08.02.2012 08:42:58 | Ubuntu | ,

Репликация MySQL на одном сервере

Привет, администраторы!

Попалась любопытная задача, сделать репликацию одной базы в другую на том же самом сервере. Решение нашлось.  Забавное. Привожу дополнено и по-русски:

Дано:

MySQL сервер (у меня он на Ubuntu, но тут, пожалуй не важно) — одна штука, база данных base1.

Надо:

Сделать репликацию базы на том же самом сервере, не запуская дополнительных процессов, в базу base2.

Решение:

Копируем base1 в base2, каким угодно способом, это ваше начальное состояние, после этого base1 не должна меняться.

Настраиваем [mysqld] секцию в /etc/mysql/my.cnf, добавив:

...
server-id=1
report-host=master-is-slave-host
log-bin=myserver-binlog
relay-log=myserver-relaylog
replicate-same-server-id=1
binlog-do-db=base1
replicate-rewrite-db=base1->base2
replicate-do-db=base2
...

После этого следует перезапустить сервер и можно увидеть, что binlog начал писаться:

# service mysql restart
...
# ls /var/lib/mysql/myserver*
myserver-binlog.000001

Выдыхаем, запускаем работу вашего приложения с base1, теперь можно.

Осталось запустить репликацию, выполняем админом в базе:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'localhost' IDENTIFIED BY 'CoolPassW0rd';
FLUSH PRIVILEGES;
CHANGE MASTER TO MASTER_HOST='localhost', MASTER_USER='repl',
    MASTER_PASSWORD='CoolPassW0rd', MASTER_LOG_FILE='myserver-binlog.000001';
START SLAVE;

И для контроля, что всё ок, посмотрите, что выдают:

SHOW MASTER STATUS;
SHOW SLAVE STATUS;

Типа всё. Согласен получить комментарии по теме!

комментария 4 »07.02.2012 17:58:30 | Ubuntu, Делаю | , ,

Админская сага

По просторам Эни Кеев

Пальчики летали.

От админского захода

Пассворд подбирали.

Да админ малой не промах:

Что пароль — аршин по сорок.

А в портах-то красота,

Не торчат абы куда!

И в системе чёткий план

Всем сервайсам по правам.

На просторах Эки Кеев

Пальчики устали.

Шифт с пробелом поломали,

Доступ не достали…

Комментариев нет »18.03.2011 01:09:04 | Делаю | , ,

Исправить «too many open files» в nginx

У вас настолько выросла посещаемость сайта, что nginx отписывает ошибки «too many open files» с ужасающей скоростью?

Причина в лимитах. По умолчанию на процесс выдается возможность открыть 1024 файла (по крайней мере в Debian и Ubuntu). Как узнать действующие лимиты? Просто. Выполняем от суперпользователя:

for pid in `pidof nginx`; do echo "$(< /proc/$pid/cmdline)"; egrep 'files|Limit' /proc/$pid/limits; echo "Currently open files: $(ls -1 /proc/$pid/fd | wc -l)"; echo; done

Получаем отчётик:

nginx: worker process
Limit                     Soft Limit           Hard Limit           Units
Max open files            1024                 1048576              files
Currently open files: 945

nginx: master process /usr/sbin/nginx
Limit                     Soft Limit           Hard Limit           Units
Max open files            1024                 1048576              files
Currently open files: 24

Ситуация ясна, процесс nginx на грани фола: ещё чуть-чуть и злополучная ошибка «разорвёт» все логи…

Решение проблемы пришлось искать недолго. Во многих блогах и обсуждениях в форумах и списках рассылки предлагается способ с применением утилиты ulimit и редактированием /etc/sysctl.conf и /etc/security/limits.conf.

Пробуем. Не работает. Ищем тщательнее…

Правильный ответ для запускаемого от суперпользователя головного процесса nginx таков: надо отредактировать nginx.conf, добавив в начало директиву (число выбирайте по вкусу):

worker_rlimit_nofile 16384;

После этого пошлите «master process»-у сигнал HUP (пере-конфигурация) и, вуаля:

nginx: worker process
Limit                     Soft Limit           Hard Limit           Units
Max open files            16384                16384                files
Currently open files: 1058

nginx: master process /usr/sbin/nginx
Limit                     Soft Limit           Hard Limit           Units
Max open files            1024                 1048576              files
Currently open files: 24

Ну, а теперь поздравляю, высокая посещаемость при пустых логах ошибок — что может быть более приятно админу?

комментария 3 »21.07.2010 03:02:42 | Делаю |

Следующие записи »