Установка и настройка языка в Ubuntu
Показано, как установить пакеты локализации на примере русского языка, настроить языковые предпочтения, добавить раскладки клавиатуры и установить их параметры.
Грабельки deployment при наличии opcode кэша
Привет, PHP разработчик, администратор или релиз-менеджер! Наткнулся на интересное, спешу поделиться.
Дано:
Проект на PHP, одновременно работающий в режиме разработки («DEV», из SVN), а также боевом режиме («LIVE»), в который переводится ветка DEV после отлова багов. Сервер примечателен только тем, что PHP запускается через php-fpm и там включено opcode кэширование. У меня нижеследующее проявилось и при XCache и при APC.
Надо:
Перевести отлаженный проект из режима разработки в режим работы.
Решаем:
Итак, имеем примерно такую структуру проекта (ненужное вырезано):
.../dev/
/app/
/index.php : <?php require dirname(__FILE__).'/../conf.php'; print $me;
conf.php : <?php $me = 'dev';
.../live/
/app/
/index.php : <?php require dirname(__FILE__).'/../conf.php'; print $me;
conf.php : <?php $me = 'live';
Два виртуальных хоста в web сервере берут данные из …/dev/ и …/live/, где лежит соответствующий код. Всё работает, opcode кэш ускорят работу, все счастливы. Запрос на …/dev/app/index.php возвращает «dev», на …/live/app/index.php — «live».
Но вот пришла пора выложить код из DEV в LIVE как можно более быстро и без глюков. Понятно, что вариантов море, один из пришедших в голову был таков: для deployment использовать 2 команды переименования каталогов. Это на самом деле весьма «дешево»: операционная система сделает очень мало работы в очень короткое время, сбои крайне маловероятны:
mv .../live/app .../bak && mv .../dev/app .../live
И вот в очень короткое время мы переместили код. Всё хорошо? Нет! Запрос на …/live/app/index.php возвращает «dev», сайт работает с тестовыми данными разработчика! 
Расследование:
Собственно, поиск причины был не сильно долгим. Мы переместили ветку файловой системы, идентификаторы файлов («inode») внутри ветки не поменялись и op-кэш наивно думает, что ничего не поменялось, т.к. он идентифицирует код по идентификатору файла. Ну и в итоге в окружении LIVE лежит файл, который запускается интерпретатором PHP со включенным файлом конфигурации на момент попадания в кэш — это был файл из DEV ветки. Вот так.
Итого мораль — при переносе дерева файлов PHP в рамках обработчика PHP с включенным opcode кэшированием вы продолжаете использовать старый закэшированный код, даже если включенные из перенесенных файлы поменялись.
Что делать?
Один из вариантов, и как мне кажется правильный — это запустить два экземпляра php-fpm обработчика. Отдельно для DEV и LIVE окружений. Или полностью исключить некоторые файлы из кэширования.
Репликация MySQL на одном сервере
Привет, администраторы!
Попалась любопытная задача, сделать репликацию одной базы в другую на том же самом сервере. Решение нашлось. Забавное. Привожу дополнено и по-русски:
Дано:
MySQL сервер (у меня он на Ubuntu, но тут, пожалуй не важно) — одна штука, база данных base1.
Надо:
Сделать репликацию базы на том же самом сервере, не запуская дополнительных процессов, в базу base2.
Решение:
Копируем base1 в base2, каким угодно способом, это ваше начальное состояние, после этого base1 не должна меняться.
Настраиваем [mysql] секцию в /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;
Типа всё. Согласен получить комментарии по теме!
Админская сага
По просторам Эни Кеев
Пальчики летали.
От админского захода
Пассворд подбирали.
Да админ малой не промах:
Что пароль — аршин по сорок.
А в портах-то красота,
Не торчат абы куда!
И в системе чёткий план
Всем сервайсам по правам.
На просторах Эки Кеев
Пальчики устали.
Шифт с пробелом поломали,
Доступ не достали…
Что-то заинтересовало?