Ubuntu - обновленные библиотеки libicu с последними изменениями временных зон

Октябрьское обновление таймзон уже успело неплохо попить крови системных администраторов. Ведь во многих случаях недостаточно простого обновления tzdata, т.к. некоторые пакеты и библиотеки используют свою базу временных зон.

Наши разработчики используют Symfony2, и кое-где версия фреймворка ниже 2.6, а значит Symfony forms использует icu, и обновлять последний как-то мало кто торопится.
Поводом для написсания данного поста стал пост об этой же проблеме на хабре, но там рассматривалось решение проблемы для CentOS.

Мы используем преимущественно ubuntu, поэтому я сделал PPA с обновленными библиотеками (для 12.04 и 14.04).

Возьмем тестовый скрипт из той статьи на хабре и проверим на Ubuntu с «родным» icu:

<?php
$dateIn = '27.10.2014';
$tz = 'Europe/Moscow';
date_default_timezone_set($tz);
$intlDateFormatter = new \IntlDateFormatter('ru_RU', 2, -1, $tz, 1, 'dd.MM.yyyy');
$timestamp = $intlDateFormatter->parse($dateIn);

var_dump($intlDateFormatter->format($timestamp));
var_dump(date('d.m.Y', $timestamp));

И выполним его:

php ./icutz.php 
string(10) "27.10.2014"
string(10) "26.10.2014"

Всё плохо. Теперь подключим ppa и обновим библиотеку из него:

sudo add-apt-repository -y ppa:rzz/icu && sudo aptitude update

Обновляем libicu
Для Ubuntu 12.04: sudo aptitude safe-upgrade libicu48
Для Ubuntu 14.04: sudo aptitude safe-upgrade libicu52

Снова запускаем наш скрипт:

php ./icutz.php 
string(10) "27.10.2014"
string(10) "27.10.2014"

Готово! Но вообще, конечно, я рекомендую помимо всего прочего обновить версию Symfony, чтобы отвязаться от icu насовсем.

UPD, 12 Ноября 2014: в связи с поступившими просьбами сделать обновленный пакет icu 5.2 для 12.04, icu 4.8 переехал в отдельный PPA: ppa:rzz/icu48

Mikrotik - автоматический бэкап на FTP или E-mail

Микротик - отличная штука, чего и говорить. Многие мои знакомые по моей рекомендации купили себе эти роутеры. Настройку их, конечно же, поручали мне, т.к. самое сложное, что они максимум видели до этого - это прошивка для роутеров ASUS "от энтузиастов" (к слову, тоже очень милая вещь, но сейчас не об этом), ну а по сравнению с ней процедура настройки микротика выглядит для таких людей каким-то диким колдунством. Некоторые из вышеуказанных знакомых так и пользуются роутером в том виде, в котором я им его настроил (либо просят внести какие-либо изменения меня, что я делаю удаленно), иные же пытаются вносить изменения в настройки и экспериментировать самостоятельно. Последнее весьма похвально, но иногда приводит к неприятным последствиям. Впрочем, даже если пользователь ничего не правит в настройках роутера, никто не защищен от ситуаций, из-за которых роутер может прийти в негодность (примеров можно придумать массу). Для минимизации возможных неприятных последствий я написал скрипт, который каждый день создает бэкап и заливает его на мой FTP-сервер.

Исходник скрипта на github



Первые четыре строки задают переменные, касающиеся того, что именно и как бэкапить:
saveUserDB - бэкапить ли базу User Manager'a
saveSysBackup - сохранять ли системный бэкап (аналогично тому, который создается по команде /system backup save в консоли)
encryptSysBackup - шифровать ли системный бэкап (поддерживается начиная с RouterOS 6.13)
saveRawExport - сохранять ли бэкап всей конфигурации в "читабельном" виде (.rsc-скрипт)

Следующие четыре строки описывают настройки для подключения к FTP и вряд ли нуждаются в комментировании.

По дополнительным просьбам сделал аналогичный скрипт, отсылающий бэкап на e-mail вместо заливки по FTP. Правда, ввиду ограничений RouterOS, каждый файл из бэкапа отправляется только отдельным письмом (т.е. получается до трех писем за один раз).

Исходник на github



Настройки аналогичны первому скрипту, разве что нужно задать в переменной mailTo адрес, на который будут отправляться бэкапы.
Если вы планируете использовать скрипт, отправляющий резервные копии на почту, обязательно сначала задайте настройки отправки почты (подробно можно почитать в Mikrotik Wiki)

После добавления скрипта (допустим, мы его назвали "backup-script"), необходимо добавить задание в планировщик:

/system scheduler add interval=1d name="Run backup" on-event=backup-script \
policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=jan/01/1970 start-time=01:00:00

О кавычках в VARCHAR и о том, как не надо делать в целом

На днях звонят мне наши веб-разработчики и говорят, мол MySQL тормозит адово, сил нет никаких терпеть, а при нескольких одновременных запросах и вовсе транзакции валятся по таймауту.

Привычный осмотр processlist'a показал вполне ожидаемую картину. В таблице чуть более 11 миллионов строк, и уже где-то полминуты висит простенький запрос типа UPDATE some_table SET act_status = 1 WHERE grp_id = 10885882802223, останавливаться он при этом не собирается, а в State красуется "Queried about 5120000 rows".

«Опять индекс не поставили!», - подумал Штирлиц и отправил разработчиков расставлять индексы, попросив попутно не отвлекать более подобными пустяками.

Однако, индекс был. Но всё равно фуллскан. Как так? А очень просто, как оказалось в итоге. В вышеуказанном запросе поле grp_id, если положиться на здравый смысл, должно иметь какой-нибудь целочисленный тип. Но здравый смысл - это для кого-то другого. Тот, кто делал эту прекрасную таблицу, решил что лучше будет, если это поле сделать VARCHAR.

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

Этот самый недо-ORM строил запросы следующим образом: если запрашиваемое значение включало только цифры, то кавычек в запросе не было. Ну а если цифры и буквы, то кавычки заботливо подставлялись.

В результате мы имели то, что имели (проблему с фуллсканом и адовые тормоза).

Смотрим внимательно. Что получалось и как быть не должно, если уж мы имеем дело с VARCHAR:

EXPLAIN select * from some_table where grp_id = 10885882802223 LIMIT 1;
+------+-------------+------------+------+---------------+------+---------+------+---------+-------------+
| id   | select_type | table      | type | possible_keys | key  | key_len | ref  | rows    | Extra       |
+------+-------------+------------+------+---------------+------+---------+------+---------+-------------+
|    1 | SIMPLE      | some_table | ALL  | grp           | NULL | NULL    | NULL | 7747809 | Using where |
+------+-------------+------------+------+---------------+------+---------+------+---------+-------------+

А вот как надо было:

EXPLAIN select * from some_table where grp_id = '10885882802223' LIMIT 1;
+------+-------------+------------+------+---------------+-------+---------+-------+------+-------------+
| id   | select_type | table      | type | possible_keys | key   | key_len | ref   | rows | Extra       |
+------+-------------+------------+------+---------------+-------+---------+-------+------+-------------+
|    1 | SIMPLE      | some_table | ref  | grp           | grp   | 99      | const |    1 | Using where |
+------+-------------+------------+------+---------------+-------+---------+-------+------+-------------+

Ситуация на самом деле идиотская донельзя и руки бы отрывать за такие изыски. Какие-нибудь еще выводы оставляю право читателю сделать самостоятельно.