Архив рубрики: Без рубрики

barman — backup postgresql

barman утилита позволяющая делать:
* обычный бэкап
* инкрементальный бэкап
* бэкап с standby сервера
* восстановление из бэкапа

Документация: http://docs.pgbarman.org

Schema description
Для такой схемы понадобится 3 сервера:
* Master — основной сервер
* Standby — реплика с master, hot standby
* Backup — сервер на котором будут находится бэкапы

Схема может быть полезной в том случае если и master и standby находятся в одном ДЦ и необходимо сделать независимый бэкап в другой ДЦ.
В случае если standby уже находится в другом ДЦ бэкап может запускаться локально на standby сервере.
Если же репликации совсем нет, можно бэкапить master сервер напрямую в бэкап сервера.

Во всех этих случаях бэкап тоже удобно делать с помощью barman.

Читать далее

optipng — быстрая оптимизация картинок на сайте

Чтобы сайт открывался немного быстрее можно оптимизировать все изображенияна сайте. Удобная утилита для этого — optipng

Пример:

$ optipng image.png 
du -sh image.png*
1.1M    image.png.orig
628K    image.png

До — 1.1 MB, после 628K ~ 500KB — без потери качества.

русификация wordpress

Если так получилось, что wordpress уже стоит английская версия, и надо его русифицировать.
Краткая инструкция есть тут http://codex.wordpress.org/Translating_WordPress#Using_Localizations

1) Идем на wordpress-i18n
ищем нужную нам локализацию, в нашем случае ru_RU

и скачиваем себе на сервер:

svn export http://svn.automattic.com/wordpress-i18n/ru_RU/trunk/

2) редактируем wp-config, добавляем:

define('WPLANG', 'ru_RU');

3) Создаем каталог

mkdir -p wp-content/languages

и копируем содержимое »trunk/messages» в »wp-content/languages»

cp trunk/messages/* wp-content/languages/

После этого wordpress должен быть русифицирован.

etckeeper — отслеживание изменений конфигурационных файлов

etckeeper — программа(скрипт) которая позволяет держать /etc (или любой другой каталог) в системе контроля версий(на текущий момент поддерживается git, mercurial, bazaar или darcs). Есть в репозиториях CentOS и Debian. В принципе, никто не мешает нам организовать в /etc git репозиторий и получить почти тоже самое. Но etckeeper позволяет автоматизировать ряд случаев:

  • При установке программ — все конфигурационные файлы автоматически добавляют в репозиторий
  • По крону (/etc/cron.daily/etckeeper) каждую ночь комитятся все изменения которые не были добавлены в ручную.

Если с помощью etckeeper вы захотите отслеживать изменения в любом другом каталоге( -d ключ) то cron скрипт лучше дублировать дописав везде где надо ключ -d.

Учитывая, что теперь /etc представляет собой репозиторий мы можем использовать hook’и (скрипты).
Можно как положить нужные скрипты в /etc/.git/hooks так и в /etc/etckeeper/*.d. Таким образом можно настроить уведомление на почту, например списка измененных файлов и сами изменения, это будет удобно если сервером управляют несколько системных администраторов.

Типовой пример работы с etkeeper.

  • etckeeper init — инициализирует репозиторий в /etc/ — скорее всего не надо будет делать этого, тк инициализация будет произведена в процессе установки etckeeper.
  • etckeeper commit -m «Комментарий» — записать изменения в репозиторий

Так же доступны все комманды выбранной VCS(Системы контроля версий). На примере git:

  • git status
  • git log

Настройка уведомлений на почту на примере git:

    1. Скопируем дефолтный email хук:
# cp /usr/share/git-core/contrib/hooks/post-receive-email /etc/.git/hooks/post-commit
# chmod +x  /etc/.git/hooks/post-commit
  1. Применим к нему patch:
    --- post-commit.orig    2014-04-23 19:18:31.226172671 +0400
    +++ post-commit 2014-04-23 19:03:42.096839354 +0400
    @@ -742,9 +742,10 @@
            # themselves
            prep_for_email $2 $3 $1 && PAGER= generate_email
     else
    -       while read oldrev newrev refname
    -       do
    -               prep_for_email $oldrev $newrev $refname || continue
    -               generate_email $maxlines | send_mail
    -       done
    +        oldrev=$(git log -2 --format=%H| tail -1)
    +        newrev=$(git log -1 --format=%H)
    +        if [ "$oldrev" = "$newrev" ]; then oldrev="00000"; fi
    +        refname="refs/heads/master"
    +        prep_for_email $oldrev $newrev $refname || continue
    +       generate_email $maxlines | send_mail
     fi
    
  2. Впишем в /etc/.git/config конфигурацию для hook’а
    [hooks]
            showrev = "git show -C %s; echo"
            emailprefix = "[git-projectname] "
            mailinglist = "john@example.com,anybody@example.com"
            envelopesender = noreply@yourdomain.com
    

Все, теперь при выполнении команды etckeeper commit и ночью по крону на почту будут падать изменения в каталоге /etc/.

net.ipv4.ip_nonlocal_bind

Полезная настройка sysctl:

net.ipv4.ip_nonlocal_bind = 1

Позволяет сервису забиндится и слушать трафик на ip которого нет. Бывает полезно в связке с keepalived, когда между серверами плавает ip. Альтернативный вариант запускать сервисы из скриптов keepalived — но вариант с sysctl более простой и надежный.

smartmoontools обновление бд устройств

Иногда проверяя S.M.A.R.T. данные диска можно увидеть такой вывод:

170 Unknown_Attribute 0x0033 100 100 010 Pre-fail Always - 0
171 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0
172 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0
174 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0

Unknown_Attribute — значит, что параметр не описан в БД.

Обычно она лежит тут:

/usr/share/smartmontools/drivedb.h

Есть замечательная утилита которая сама делает обновление — update-smart-drivedb (часть пакета smartmontools).

Иногда (Debian Wheezy, CentOS 6.5) она ведет себя так:

update-smart-drivedb
/usr/share/smartmontools/drivedb.h.error: rejected by /usr/sbin/smartctl, probably no longer compatible

Если мы заглянем в /usr/share/smartmontools/drivedb.h.error то увидим следующее:

 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://sourceforge.net/p/smartmontools/code/">here</a>.</p>
<hr>
<address>Apache/2.2.3 (CentOS) Server at smartmontools.svn.sourceforge.net Port 50043</address>
</body></html>

БД переехала по другому URL.

Пропатчим руками update-smart-drivedb:

sed -i -e "s#^SRCEXPR=.*#SRCEXPR='https://sourceforge.net/p/smartmontools/code/HEAD/tree/\$location/smartmontools/drivedb.h?format=raw'#" /usr/sbin/update-smart-drivedb

Обновляем:

# update-smart-drivedb
/usr/share/smartmontools/drivedb.h updated from branches/RELEASE_5_41_DRIVEDB

Смотрим S.M.A.R.T

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours_and_Msec 0x0032   100   100   000    Old_age   Always       -       167h+54m+02.150s
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       2
170 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
174 Unexpect_Power_Loss_Ct  0x0032   100   100   000    Old_age   Always       -       0
183 SATA_Downshift_Count    0x0032   100   100   000    Old_age   Always       -       15
184 End-to-End_Error        0x0033   100   100   090    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0

Все на месте.

p.s.
Проблема с неправильным URL решена в Debian Jessie

Мониторинг здоровья ssd диска

По нашему мнению, нет смысла делать raid1 на ssd дисках, увеличения скорости по чтению не будет сколько нибудь существенным, а надежность мы таким образом не получаем, т.к. важнейшим критерием определяющим долголетие ssd диска является количество операций записи, а оно при raid уровня 1 (mirror) будет одинаковым у обоих дисков.

Таким образом, наиболее эффективным  видится создание регулярных бэкапов и мониторинг здоровья ssd диска.

Есть два важных S.M.A.R.T. параметра по этому поводу:

Available_Reservd_Space — значение в процентах, сколько свободных блоков для замещения битых осталось. чем ближе это значение к 0 тем хуже.

Media_Wearout_Indicator —  индикатор износа изменяется так же от 100 до 1. При 1 необходимо уделить внимание носителю.