Знову про резервне копіювання

Раніше я вже писав про резервне копіювання в Лінуксі з допомогою obnam. З того часу розробка цієї програми припинилася, і мені потрібно було знайти альтернативу. Я зупинився на borg-backup. Але спершу:

Навіщо спеціальна програма?

Ви могли подумати — нащо все ускладнювати, я буду просто вручну копіювати файли на флешку. І це цілком прийнятне рішення.

Але якщо ваших файлів трохи більше, ніж 2-3? Копіювати кожного разу все? Чи тільки те, що ви змінили? А якщо ви випадково щось забудете? Чи випадково вилучите щось не те з резервних копій? А що робити з попередніми версіями файлів? Перейменовувати й зберігати? Чи перезаписувати? Якщо зберігати, то скільки минулих копій? І коли їх вилучати?

А якщо ви також хочете стискати дані перед копіюванням для економії місця, і шифрувати, щоб випадкові люди не мали до них доступу?

Програми для резервного копіювання дають вам можливість один раз налаштувати резервне копіювання, і потім лише натискати «одну кнопку» і ні про що не хвилюватися.

Продовжити читання «Знову про резервне копіювання»

Mariadb: швидкодія «з коробки» (Fedora)

Mariadb «з коробки» має досить консервативні налаштування, не орієнтовані на швидкодію. Наприклад, вимкнутий кеш запитів. Також для таблиць InnoDB сервер буде після кожного INSERT/UPDATE-запиту вимагати від ядра записати зміни на диск (вилити їх з кешу файлової системи), що може бути дуууже повільно для більшої кількости запитів. Тому я змінив деякі типові налаштування, щоб пришвидшити роботу (тут не йдеться про якийсь production-сервер, а суто оптимальне середовище для розробки).

Отже вміст файлу /etc/my.cnf.d/performance.cnf:

[server]
# Увімкнути кеш запитів і збільшити до 50M
query_cache_size = 52428800 

# Зливати дисковий кеш кожні 30 с. замість після кожного
# INSERT/UPDATE
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 30

Tor для людей: ssh-доступ до машини за шлюзом

Окрім можливости виходити в мережу на обмежених з’єднаннях і захисту від стеження, Tor має ще одну дуже корисну функцію: можливість створювати публічнодоступну адресу для будь-якої машини, незалежно від того, чи у неї змінна IP і чи вона за шлюзами (NAT-ами). Де б ця машина не була (а якщо це ноутбук, то він може постійно переміщуватися з місця на місце), ця адреса буде незмінною. Вона завжди закінчується доменом .onion, і має вигляд, подібний до: sejnfjrq6szgca7v.onion (якщо відкрити цю адресу в Tor Browser, ви потрапите на Tor-версію сайту debian.org).

Продовжити читання «Tor для людей: ssh-доступ до машини за шлюзом»

Веб-сайти на localhost — автоматичне налаштування virtual hosts і dns (fedora)

TLDR: Правда, було б зручно, якби просто створивши теку в ~/public_html/, ми могли відразу і автоматично бачити її за адресою http://назва-теки.self/ як повноцінний віртуальний сервер апача? Ось один зі способів це зробити (я користуюся Fedora, але, можливо, на инших дистрибутивах процедура буде подібною).
Продовжити читання «Веб-сайти на localhost — автоматичне налаштування virtual hosts і dns (fedora)»

Зручне резервне копіювання даних в Лінуксі з допомогою obnam

Backup Backup Backup - And Test Restores
Сервер, знищений внаслідок пожежі.

Важливі дані треба зберігати щонайменше в двох місцях, на двох окремих носіях інформації. Адже не існує стовідсотково надійних і невразливих носіїв інформації — кожен носій рано чи пізно дає збій, і передбачити це не завжди можливо. Резервне копіювання — це як застрахувати будинок, тільки безкоштовно (окрім хіба що ціни резервного носія інформації). Якщо ви зберігаєте на компуторі якусь свою роботу — від фотографій до дисертації чи історичних романів — вам конче необхідно налаштувати собі резервне копіювання, инакше ви ризикуєте в будь-який момент втратити результати своєї праці.

Існує безліч програм для резервного копіювання і безліч способів налаштування. Цей допис — для користувачів Gnu/Linux, але якщо Ви працюєте у Windows, для вас теж є безліч програм для резервного копіювання. Я розповім про програму, якою користуюся сам.

Продовжити читання «Зручне резервне копіювання даних в Лінуксі з допомогою obnam»

Дві слові про паролі

KeePassX-uk
Менеджер паролів KeePassX

Не можу не поділитися однією простою й дуже розумною думкою одного дослідника компуторної безпеки:

Запам’ятовувати усі паролі — дурна ідея. Вони обов’язково будуть слабкими і легкими до зламування. Хіба не легше використовувати менеджер паролів, і мати при тому супер-міцні паролі, які не треба тримати в голові?
Продовжити читання «Дві слові про паролі»

10 прикладів використання командного рядка Gnu/Linux та инших

До командного рядка часто ставляться як до якоїсь таємничої «шаманської магії». Насправді ж це дуже практична річ, яка кожному може стати в пригоді, особливо коли треба виконати якусь однакову дію над великою кількістю файлів. Багато моїх близьких і друзів перейшли на Gnu/Linux, але не всі з них знають про можливості, «заховані» в командному рядку на цих системах.

Продовжити читання «10 прикладів використання командного рядка Gnu/Linux та инших»

Gmail, IMAP та «мітки» кирилицею

Gmail дає змогу чіпляти до листа різні мітки, які з точки зору протоколів витягування пошти (POP3 та IMAP4) є скриньками. В принципі, інтерфейс Gmail також їх показує як скриньки з листами.

Іноді у різних рецептах (згодувати spamassassin’у теку «Спам» із гуглопошти, наприклад) окремим пунктом програми передбачено витягування вмісту такої скриньки (за допомогою fetchmail, скажімо).

Рішення просте:

poll imap.gmail.com protocol IMAP 
   user "nouser@gmail.com" is localuser here
   password 'superpassword',
   folder "[Gmail]/Spam",
   # folder 'from Smith',
   # fetchlimit 1, keep,
   ssl

Але проблема виникає тоді, коли мітки українською (не латинкою, взагалі кажучи). І ніде, чомусь, я рішення не знайшов, саме тому це й пишу.

Справа в тому, що кодування назв скриньок має бути у «модифікованому UTF-7»; це зазначено у RFC 3501 (5.1.3. Mailbox International Naming Convention).

При цьому «службові» скриньки зазначаються як «[Gmail]/Скринька»:

poll imap.gmail.com protocol IMAP 
   user "nouser@gmail.com" is localuser here
   password 'superpassword',
   folder "[Gmail]/&BCEEPwQwBDw-",         # «Спам» — обов’язково "[Gmail]/"
   # folder '&BDIEVgQ0- &BCEEMARIBDoEMA-', # «від Сашка» —  *без* "[Gmail]/"
   # fetchlimit 1, keep,
   ssl

Письменництво з Git

Протягом певного часу я застосовую т.зв. керування версіями до текстів. Це дає мені можливість:

  1. бачити зміни, які я зробив відносно останньої «зафіксованої» версії файлу;
  2. порівнювати між собою будь-які з раніших версій файлу;
  3. паралельно працювати над кількома варіянтами того ж файлу, які відрізняються у певних місцях, але мають значну частину спільного тексту; тобто спробувати, наприклад, переробити певний розділ і подивитись «що із того вийде», залишивши стару версію цього розділу доступною до повернення в документ навіть після будь-якого редагування инших розділів;
  4. синхронізувати версію одного файлу із версією другого (наприклад, текст із ілюстрацією);
  5. відіслати комусь документ для редагування й переглянути усі корекції при отриманні; обирати, яку корекцію прийняти, а яку ні.

Це далеко не вичерпний перелік. Як це працює? У вас є тека з файлами, а всередині цієї теки є під-тека .git, де зберігаються попередні версії файлів та інформація про послідовність та зв’язок між змінами. Єдина вимога — навчити вашу систему керування версіями порівнювати різні версії файлів того формату, в якому ви пишете ваш текст.

Продовжити читання «Письменництво з Git»