Архів рубрики: Адміністрування

Зміна hostname у Debian

Командний рядок терміналу (такого як Xterm), як правило, показує запрошення у вигляді:

user@hostname:dir$ _

Це доволі зручно, тому що працюючи одночасно з декількома консолями ви завжди розумієте по значенню @hostname з яким сервером маєте справу. Якщо ім’я серверу записане у форматі домену – www.example.com, то користувач побачить hostname не повністю, а лише його ліву частину до першої крапки:

user@www:dir$ _

У віртуальних серверів (VPS), особливо у орендованих, це ім’я не завжди містить корисну інформацію. Скоріше за все, там буде суміш літер та цифр, або якийсь номер для внутрішнього використання.

Отже як змінити hostname у Debian. Одразу попереджую, що використання команди hostname дає лише тимчасовий ефект, після перезапуску сервера повернеться попереднє ім’я.

Самий простий спосіб – змінити ім’я у файлі /etc/hostname (навіть якщо цей файл порожній) та перезавантажити комп’ютер.

Якщо можливості перезавантажити серер не має, можна спробувати зробити це “на ходу”. Більш детально читайте про це тут: https://wiki.debian.org/HowTo/ChangeHostname

Наведена тут інформація не підходить до контейнерів Debian всередині OpenVZ. Всередині контейнера, навіть якщо ви поміняєте вміст файлу /etc/hostname, після перезапуску hostname повернеться до первісного значення, яке вказане у конфігурації контейнера. Тому для OpenVZ використовуйте команду:

# vzctl set ID_КОНТЕЙНЕРА --hostname НОВИЙ_HOSTNAME --save

Порядок псевдонімів server_name у конфігу Nginx

Веб-сервер Nginx дозволяє доволі гнучко керувати псевдонімами вашого сайту. Можна використовувати декілька директив server_name:

server_name example.com www.example.com alias.com;
server_name www.alias.com;

Мені подобається схема у 2 імені, коли перше іде без www, а друге з www:

server_name example.com www.example.com;
server_name alias.com www.alias.com;

Але перше ім’я домену має найвищій пріоритет і саме воно буде використане за умовчанням при обробці правил rewrite з опціями redirect та permanent.

Простий приклад. Маємо правило:

rewrite ^/user/(.*) /newlook/$1 permanent;

За таким правилом користувача завжди буде перенаправлено до домену example.com:

example.com/user/index.php -> example.com/newlook/index.php
www.example.com/user/index.php -> example.com/newlook/index.php
alias.com/user/index.php -> example.com/newlook/index.php
www.alias.com/user/index.php -> example.com/newlook/index.php

Налаштування 3G інтернету від 3mob (Utel) в Gnome 3 (Linux)

Лінукс, як і всі Unix-оподібні операційні системи, традиційно сильна у налаштуванні мережі. Так було у епоху Ethernet, але з появою бездротових мереж та мобільного інтернету 2G (GPRS/EDGE) та 3G (UMTS/HSPA) підключення до мережі це лише сервіс. Тепер на перший план виходить зручність підключення.

У менеджері вікон Gnome 3 ці налаштування відбуваються майже автоматично, але є я зміг підключитися до 3G від 3mob (Utel) лише першого разу, коли спрацював “візард” налаштування. Потім коли я вставляв USB 3G-модем (HUAWEI) і клацав на перемикачі “Мобільна радіомережа” – з’являлось повідомлення, що “ви підключені до мережі Utel” і потім “з’єднання розірване”. Вам сюди – якщо у Вас проблеми на рівні драйверу USB 3G-модему.

Треба вручну прибрати за “візардом”. Для цього з командного рядка запускаємо:

$ nm-connection-editor

На вкладці “Мобільні широкосмугові” знаходимо підключення Utel та клацаємо кнопку “Змінити…”.

На наступному екрані також обираємо вкладку “Мобільні широкосмугові”. У себе я включив перемикач “Підключати автоматично” – це головне. А також змінив тип на “Віддавати перевагу 3G (UMTS/HSPA)”, та вимкнув “Вмикати роумінг, якщо недоступна домашня мережа”. Закриваємо діалог клацнувши на кнопку “Зберегти…”.

Все. Тепер щоб підключитися до інтернету я вставляю 3G модем, трохи чекаю поки його ідентифікує система та клацаю на кнопці включення “Мобільної радіомережі”.

Заміна одного рядка на два у вбудованому текстовому редакторі Midnight Commander

Не знаю як вам, а мені подобається вбудований текстовий редактор mc. Чогось я так і не зміг оволодіти vim, тому на новому сервері в мене перша команда:

# apt-get install mc

Потім включаю у конфігурації вбудований текстовий редактор для редагування:

F9 / Options / Configurations… / Use internal edit / OK

Тепер клавіша F4 закріплена саме за вбудованим редактором.

Нещодавно, мені довелось вручну правити файл конфігурації сервера імен BIND. Там було доволі багато зон для яких треба було замінити рядок:

type master;

на 2 рядка:

type slave;
masters {192.168.0.1;};

Пошук та заміна у вбудованому редакторі є (F4 Replace), проте незрозуміло як замінити рядок на два рядки. Клавіша Enter працює як OK.

Після декількох спроб я знайшов вихід. Треба перемкнути пошук у режим Regular expression та ввести символ нового рядка як n. Таким самим чином можна додавати символи табуляції – t.

Wifi для Debian Wheezy (iwlwifi)

Ноутбук з Windows 8 для мене наче пристрій з майбутнього. Без сенсорного екрану та миші я не зміг оцінити переваг нового інтерфейсу. Навіть перезавантажити його, щоб зайти у BIOS, виявилось не так просто.

Встановити Лінукс (Debian Wheezy) я зміг майже без проблем, але під час виявлення мережевого обладнання побачив на екрані повідомлення, що для роботи драйвера wifi мені потрібні якісь firmware:

iwlwifi-2030-6.ucode та iwlwifi-2030-5.ucode

Звичайно, ні на якому змінному носії в мене їх не було, хоча в комплекті до ноутбука йшла низка компакт-дисків (DVD чи CD не знаю), але вставити їх все рівно не було куди. Тому під час встановлення я пропустив пункт налагодження wifi і підключився через звичайне дротове з’єднання з мережею (добре, що у комплекті був перехідник usb-ethernet).

Але без wifi працювати не прикольно. Тому я поліз у гугл та знайшов wiki по налаштуванню Intel WiFi пристроїв у Debian: http://wiki.debian.org/iwlwifi

Треба віддати належне документації Debian – вона може трохи заплутана, але дуже достовірна. Все зробив як там було написано:

  1. Додав non-free пакунки у файлі /etc/apt/sources.list
    deb http://mirror.mirohost.net/debian/ wheezy main non-free
  2. Оновив перелік пакунків та встановив firmware-iwlwifi
    # apt-get update
    # apt-get install firmware-iwlwifi
  3. Перезапустив модуль ядра для роботи з wifi:
    # modprobe -r iwlwif
    # modprobe iwlwif

Все, wifi мережі одразу з’явились на панелі:

 

Встановлення Debian Etch “старого” зразка

Програмне забезпечення, що написано декілька років тому, може виявитись не сумісним з сучасними операційними системами Linux. То версія бібліотеки не та, то виклик системної функції спочатку був deprecated, а потім взагалі зник і таке інше.

Причин багато, але іноді краще встановити стару операційну систему ніж переробляти невідомо ким написаний програмний код.

Debian 4.0 Etch the first install screenНаприклад, достовірно відомо, що програма працює у Debian 4.0 Etch. Зараз я розповім, як встановити цей “застарілий” дистрибутив.

На сторінці http://cdimage.debian.org/cdimage/archive/ ви знайдете образи для встановлення Debian починаючи з випуску 3.0 Woody проте їх немає де оновити. Тобто ви зможете встановити мінімальну систему, але підключення до дзеркала пакунків закінчиться невдачею, адже ці системи зараз не підтримуються.

Але є вихід. Існує спеціальний ресурс snapshot.debian.org, який містить копії основного репозиторію пакунків Debian на певну дату.

Я скачав з каталогу etch/main/installer-amd64/20070308etch7/images/netboot/ образ mini.iso для встановлення системи через мережу. Інсталяція йшла добре до моменту вибору дзеркала пакунків. На цьому етапі слід вибрати налаштування вручну і вказати адресу дзеркала сайту snapshot.debian.org.

Отже на першому кроці діалогу обираємо http протокол. Далі домене ім’я snapshot.debian.org. Потім шлях до пакунків. Він має такий вигляд:

/archive/debian/20090802T004153Z/

Якщо система успішно підключилася до дзеркала, то ви побачите на екрані меню для вибору гілки. Я обрав -  Etch (oldstable). Все, далі система встановлюється звичайним чином.

Зміст файлу /etc/apt/sources.list:

deb http://snapshot.debian.org/archive/debian/20090802T004153Z/ etch main
deb-src http://snapshot.debian.org/archive/debian/20090802T004153Z/ etch main

mysqldump, cron та –defaults-extra-file

Для резервного копіювання баз даних 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

При оновленні програмного забезпечення на бекенді (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

Стисло опишу, як згенерувати 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

До 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://ДОМЕН";