Архів за місяць: Червень 2013

mysqldump, cron та –defaults-extra-file

Linux, Адміністрування, Програмування, , , ,

Для резервного копіювання баз даних MySQL використовується утиліта mysqldump. Щоб не “світити” пароль доступу до бази даних можна використовувати файл .my.cnf такого змісту:

$ cat ~/.my.cnf 
[client]
user=КОРИСТУВАЧ
pass=ПАРОЛЬ

Тепер можна запускати mysqldump без вказування паролю:

$ mysqldump -u КОРИСТУВАЧ БАЗА_ДАННИХ > файл_дампу.sql

Але якщо ви спробуєте додати таку команду у crontab, то вас спіткає невдача:

mysqldump: Got error: 1045: Access denied for user 'КОРИСТУВАЧ'@'localhost'
 (using password: NO) when trying to connect

Справа в тому, що з CRON середовища файл ~/.my.cnf не зчитується. Треба додати спеціальну опцію –defaults-extra-file=’шлях до вашого .my.cnf’

Але і тут все не так просто. Наприклад, наступна команда не буде працювати:

$ mysqldump -u КОРИСТУВАЧ --default-extra-file=/home/КОРИСТУВАЧ/.my.cnf БД > файл_дампу.sql
mysqldump: unknown variable 'default-extra-file=/home/КОРИСТУВАЧ/.my.cnf'

Причина в послідовності аргументів. Першим має бути –default-extra-file:

$ mysqldump --default-extra-file=/home/КОРИСТУВАЧ/.my.cnf -u КОРИСТУВАЧ БД > файл_дампу.sql

Сторінка maintenance за допомогою Nginx

Linux, Адміністрування, Програмування, ,

При оновленні програмного забезпечення на бекенді (back-end) бажано показувати користувачеві пояснювальну інформацію. Наприклад, сторінку на якій написано, що зараз проводяться технічні роботи і сайт буде доступний за мить.

Якщо фронтенд (front-end) у вас Nginx, то це можна зробити за допомогою директиви try_files. Для цього, на час проведення технічних робіт, слід підмінити конфігурацію сайту наступним змістом:

server {
  listen   80;
  server_name ДОМЕНИ;
  location / {
    root /var/www/maintenance;
    try_files $uri /maintenance.html;
  }
}

В порожній директорії /var/www/maintenance повинен бути лише один файл maintenance.html. Саме його і побачить користувач.

Перевагою цього методу є те, що у браузері залишиться поточний URL. Тобто не буде заміни на http://ДОМЕН/maintenance.html

Створення власного SSL сертифікату та застосування його у Nginx

Debian, Linux, Адміністрування, Мережа, Програмування, , , ,

Стисло опишу, як згенерувати SSL сертифікат у Debian.

Встановлюємо пакет ssl-cert:

apt-get install ssl-cert

Створюємо сертифікат для потрібного домену:

make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/ДОМЕН

Ця консольна утиліта запитає назву домену. Ви повинні ввести домен, для якого створюється сертифікат.

Сертифікат матиме вміст:

-----BEGIN RSA PRIVATE KEY-----
 це приватний ключ
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
 це публічний сертифікат
-----END CERTIFICATE-----

Приватний ключ зберігаємо у каталозі /etc/ssl/private. Краще дати йому розширення *.key:

$ cat /etc/ssl/private/ДОМЕН.key
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

Публічну частину – у каталозі /etc/ssl/certs, з розширенням *.pem:

$ cat /etc/ssl/certs/ДОМЕН.pem
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Оригінальній файл можна видалити. Чомусь в мене файл сертифікату був створений зі символічним посиланням на нього. Це посилання – теж видаляємо.

Підключаємо сертифікат до Nginx:

server {

 listen   443;
 server_name ДОМЕН;

 ssl  on;
 ssl_certificate        /etc/ssl/certs/ДОМЕН.pem;
 ssl_certificate_key    /etc/ssl/private/ДОМЕН.key;

 ssl_session_timeout  5m;

 ssl_protocols  SSLv3 TLSv1;
 ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
 ssl_prefer_server_ciphers   on;

 ...
}

Шифрований (https) доступ до wiki (http) за допомогою Nginx

Linux, Адміністрування, Мережа, , , , , , ,

До wiki сайту треба створити зашифрований SSL доступ. Wiki працює всередині віртуальної машини і не має можливості дати йому реального IP. Тому шифрування доступу будемо здійснювати засобами Nginx.

Схема буде такою:

Nginx (https) -> proxy_pass -> Apache (http) with Wiki

Генерація штучного SSL сертифікату доволі тривіальна задача, не будемо зупинятися на цьому.

Налагодження Nginx складається з 3-х частин:

  • переведення всього HTTP трафіку у HTTPs
  • проксування HTTPs з Nginx на Apache з wiki
  • зміна $wgServer у параметрах wiki

1. Перетворюємо HTTP запити у дзеркальні HTTPs

server {
    listen   80;
    server_name ДОМЕН;
    rewrite ^ https://$server_name$request_uri? permanent;
}

2. Проксуємо трафік до wiki

server {
    listen   443;
    server_name ДОМЕН;
    ssl  on;
    ...
    location / {
        proxy_pass       http://ЛОКАЛЬНА_АДРЕСА_WIKI:80;
        proxy_set_header Host      $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_redirect   off;
    }
}

3. Міняємо http на https у змінній $wgServer

Після перших 2-х кроків ми практично зробили шифроване з’єднання, але деякі посилання всередині wiki сторінок містять http протокол.

Треба відредагувати файл LocalSettings.php і замінити:

$wgServer = "http://ДОМЕН";

на

$wgServer = "https://ДОМЕН";