VMware на Ubuntu 8.10: спостереження про зависання

У лютому 2009 року в мене почали зависати віртуальні машини у VMware Server. Проблема не обмежувалася гостьовою системою: разом із нею зависала вся Ubuntu 8.10.

Що я спробував

Довго намагався знайти причину, а потім установив VMware Workstation. У ньому віртуальні машини знову почали запускатися.

Результат у моїй конфігурації

Працювало, щоправда, якось повільно — але все ж працювало. Це було моє враження від роботи системи, а не вимірювання продуктивності VMware Server і Workstation.

Номерів збірок, журналів помилок і точних налаштувань у тій нотатці немає. Тому вона описує перебіг мого збою та заміну інструмента, але не встановлює його технічну причину й не визначає сумісність інших версій VMware або Ubuntu.

Google у кризовому 2009 році: реорганізація інженерних офісів

У лютому 2009 року я звернув увагу на повідомлення про зміни в європейських офісах Google. Тодішня нотатка спиралася на новину itnews.com.ua/46299.html. Первинне повідомлення компанії дозволяє точніше описати, що саме відбувалося.

Що оголосила Google

У заяві від 14 січня 2009 року компанія повідомила про консолідацію інженерних команд в Остіні, Тронгеймі та Лулео. Зміни стосувалися близько 70 інженерних працівників у цих трьох містах разом. Google прагнула зберегти якомога більше з них, запропонувавши роботу в інших офісах, але не гарантувала переведення кожного.

Це уточнює старий переказ: йшлося про конкретні інженерні майданчики, а не про повне припинення діяльності Google у Швеції або Норвегії. Кількість 40 працівників із вторинної новини не слід підміняти загальним масштабом оголошених змін.

Окрема зміна в рекрутингу

Того самого дня Google опублікувала повідомлення про скорочення приблизно 100 посад у рекрутингу на тлі уповільнення найму. Це інший захід, який не варто змішувати з переведенням інженерів.

У початковій нотатці я пов'язував новини з економічною кризою. Сам факт реорганізації не доводить збитковості компанії чи недостовірності її фінансової звітності. Ця публікація зберігає контекст 2009 року й описує тодішні оголошення, а не поточний стан офісів Google.

160 готелів до Євро-2012: що планували в Україні на початку 2009 року

На початку 2009 року підготовка до Євро-2012 поставила питання, де розмістити гостей чемпіонату. У січневому сюжеті програми «Подробиці» йшлося про потребу збудувати 160 готелів за три роки у шести українських містах, які тоді розглядали для проведення матчів. Сюжет від 23 січня 2009 року в архіві Української асоціації футболу.

Які готелі згадували в січневому сюжеті

У сюжеті навели такий розподіл за категоріями:

• 57 п’ятизіркових готелів
• 76 чотиризіркових
• 27 тризіркових

Разом ці числа дають 160. У первинному заголовку цього допису стояло 120. У тексті допису й у телевізійному сюжеті фігурувало число 160. Воно описувало оцінену на початку 2009 року потребу в готелях.

Як змінився перелік міст

У травні 2009 року виконком УЄФА підтвердив Київ для групових матчів і частини плей-оф. Для Донецька, Львова й Харкова залишив час виконати вимоги до стадіонів, транспорту й розміщення. Дніпропетровськ і Одесу до переліку міст проведення не включили. Травневе рішення УЄФА.

У грудні УЄФА затвердила проведення матчів у Києві, Донецьку, Львові й Харкові, а фінал залишила за Києвом. Січневу цифру 160 варто читати в контексті ранньої підготовки, коли розглядали шість міст. Грудневе рішення УЄФА.

Вплив кризи на великі IT-компанії: архівне посилання 2009 року

У цій короткій нотатці 2009 року я зберіг посилання на матеріал про вплив економічної кризи на великі IT-компанії:

http://mobilnik.ua/articles/442.html

У самому дописі немає таблиць, показників чи висновків із того матеріалу. Посилання збережено як частину історії публікації.

ICQ-клієнти в старій Ubuntu: вибір між Pidgin і SIM

Поступово переходячи на Linux, я шукав заміну звичному ICQ-клієнту. LICQ мені не зовсім підійшов: у моїй конфігурації були спотворення під час передавання даних і питання до використаних портів.

Варіанти Pidgin і SIM знайшов у статті за адресою http://ubuntueasy.com/internet/icq-klienty-v-ubuntu-linux-7-10.

Pidgin: уже встановлений клієнт

У моїй тодішній Ubuntu Pidgin уже був установлений: достатньо було відкрити «Програми → Інтернет» і запустити його. Це був мультипротокольний клієнт, який не обмежувався ICQ. Наявність у цій інсталяції не означала, що Pidgin є обов’язковою частиною кожної системи з GNOME.

Далі я додавав обліковий запис, обирав протокол ICQ, вводив потрібні дані й підключався. Спочатку вигляд здавався незвичним, та до нього можна було звикнути; нестандартні звуки теж налаштовувалися.

Кодування cp1251 у тодішньому середовищі

Для обміну зі співрозмовниками на інших системах я тоді звертав увагу на параметр cp1251. Він стосувався сумісності кодування в тому середовищі й не був універсальним налаштуванням для всіх месенджерів.

SIM: знайоміший інтерфейс і додаткові залежності

SIM нагадував звичайний ICQ-клієнт і теж підтримував кілька протоколів. Водночас для його встановлення в моїй Ubuntu доводилося додавати залежності KDE — їхня кількість тоді здалася мені суттєвим мінусом.

У старому репозиторії використовувався такий рядок встановлення:

sudo apt-get install sim

Установлену програму шукали в меню «Програми → Інтернет».

Що я обрав

Зрештою поставив собі Pidgin. Непоганий виявився пейджер: кілька протоколів, робота в Linux і, коли звик, цілком приємний інтерфейс.

Описаний вхід до ICQ стосується 2009 року. Згодом протокол змінився, і розробники Pidgin пояснили в офіційній довідці про протоколи, що самі не підтримують його новий варіант. Старий рядок встановлення SIM також не підтверджує наявності пакета в репозиторії вашої версії Ubuntu.

Оновлення QIP відновило підключення до ICQ

14 лютого 2009 року QIP сам повідомив мені про нову версію та запропонував її завантажити.

Підключення до ICQ знову запрацювало

Я встановив запропоноване оновлення — і ICQ знову запрацював нормально.

QIP та ICQ: повторні проблеми підключення

Знову проблеми з ICQ у QIP… У моїй тодішній версії клієнта підключення періодично не працювало.

Повідомлення про непідтримуваний клієнт

Мені знову надійшло сповіщення, що мій варіант ICQ-клієнта не підтримується. І це при тому, що встановлена версія QIP була однією з новіших на той момент!

Раніше подібні відключення сторонніх клієнтів я пов’язував зі змінами протоколу ICQ. Нове повідомлення нагадало ту ситуацію, але саме по собі воно не пояснювало причини повторного збою. Для точного розбору потрібні версія QIP, текст діагностики та дані про стан сервісу в той час.

VPN-шлюз на Ubuntu 8.10: історія одного налаштування

Коли мій шлюз на Windows почав сильно збоїти, я вирішив перенести його функції на Ubuntu 8.10. Раніше це мені не вдавалося: провайдер надавав інтернет через VPN, а для з’єднання треба було правильно вказати чимало параметрів.

Як допоміг NetworkManager

Цього разу все запрацювало на ура! Допоміг NetworkManager, у якому можна було налаштовувати різні типи з’єднань: дротові, бездротові, DSL і VPN. Саме зручніше керування з’єднанням стало для мене головною відмінністю від попередніх спроб.

Налаштування VPN я тоді розбирав за статтею:

http://openkazan.info/ubuntu-8.10-vpn-pptp

Firestarter і взаємодія з VPN

З Firestarter довелося повозитися окремо, щоб узгодити його роботу з VPN. Для цього використовував такі обговорення й матеріали:

• http://liski.vsi.ru/ubuntu/index.php?page=79
• http://forum.ubuntu.ru/index.php?topic=42746.0

Перебіг цієї спроби та обмеження знайденого обходу описав у попередньому дописі про Firestarter і VPN. Сам факт роботи з’єднання ще не засвідчує правильності правил фільтрації.

Що отримав після переходу

У підсумку в моїй конфігурації вдалося зробити більше, ніж до цього на Windows:

1. Інтернет запрацював стабільно.
2. Установив міжмережевий екран для фільтрації трафіку.
3. Додав спеціальні утиліти контролю з’єднань і трафіку.
4. Отримав можливість використовувати потрібні серверні програми Linux, зокрема для роботи через інтернет.

Це досвід налаштування Ubuntu 8.10 у 2009 році. Точні старі адреси залишив для зв’язку з тією конфігурацією; їхній вміст нині не вдалося перевірити. Опис типів з’єднань тогочасного NetworkManager зберігся в довідці Ubuntu для NetworkManager 0.7.

Firestarter і PPTP VPN: розбір старого обхідного рішення

У старій конфігурації VPN я зіткнувся з проблемою взаємодії Firestarter і з'єднання через ppp0. Guarddog мені не підійшов, тому я повернувся до Firestarter й знайшов обговорення за адресою http://forum.ubuntu.ru/index.php?topic=42746.0.

Інтерфейс ppp0 і перший обхід проблеми

Спочатку я вибрав ppp0 як інтерфейс, що дивиться в інтернет, і відредагував /etc/firestarter/user-pre. Наведений варіант із політиками ACCEPT міг істотно послабити фільтрацію — саме тому його не варто переносити як готове безпечне налаштування:

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Це встановлює політику ACCEPT для відповідних вбудованих ланцюжків. Така політика дозволяє пакети, для яких не спрацювало інше завершальне правило; вона не видаляє наявні правила, але може істотно послабити фільтрацію. Відновлення VPN таким способом не підтверджує безпечного налаштування.

Окремі правила для PPTP і неперевірена ідея з FORWARD

На інших форумах я також зустрічав такі правила:

$IPT -A INPUT -p TCP --dport 1723 -j ACCEPT
$IPT -A INPUT -p 47 -j ACCEPT
$IPT -A OUTPUT -p TCP --dport 1723 -j ACCEPT
$IPT -A OUTPUT -p 47 -j ACCEPT

У моїй тодішній конфігурації з цим варіантом з’єднання через певний час усе одно переривалося. Я припускав, що слід додати ще два рядки, але їх не перевіряв:

$IPT -A FORWARD -p TCP --dport 1723 -j ACCEPT
$IPT -A FORWARD -p 47 -j ACCEPT

Тут $IPT — змінна зі старого оточення, значення якої в нотатці не задано. Число 47 позначає IP-протокол GRE, а не порт; TCP 1723 використовується для керувального з'єднання PPTP. Самі ці фрагменти не визначають повного набору правил для маршрутизації, станів з'єднань і конкретної топології.

Перезапуск Firestarter після редагування

Після зміни файла в тодішній системі я перезапускав Firestarter:

sudo /etc/init.d/firestarter restart

Що перевіряти під час діагностики

Для діагностики слід перевіряти фактичні правила, журнали та потрібні напрямки трафіку, з можливістю повернення попередньої конфігурації. Технічний опис дії правил і протоколу: Netfilter: iptables та RFC 2637: PPTP. Цей історичний розбір не є рекомендацією обирати PPTP для нового VPN.

Міжмережевий екран Linux: Netfilter, Firestarter і Guarddog

Графічні оболонки, на які я звернув увагу

У 2009 році для редагування правил iptables я розглядав графічні оболонки Firestarter і Guarddog. Firestarter здавався простішим, але в моїй конфігурації переривалися VPN-з’єднання; Guarddog був складнішим у налаштуванні. Це особисте спостереження, без версій і журналів збою.

Netfilter і керування правилами

Ядро Linux містить підсистему Netfilter, а правила налаштовують відповідними інструментами. Не всі конфігурації зводяться до редагування одного текстового файла й не кожна система автоматично має потрібні правила.

Де перевірити спосіб налаштування своєї системи

У сучасному контексті також є nftables і засоби керування на кшталт ufw. Конкретний інструмент і спосіб збереження правил залежать від дистрибутива та його версії. Для Ubuntu це пояснює документація щодо міжмережевих екранів.

Антивірусні засоби й діагностика мережі в Linux

На час цієї нотатки 2009 року я працював із Unix-подібними системами вже близько п’яти років, якщо не більше, і особисто не стикався з Linux-вірусами. Проте цей досвід не дає підстав стверджувати, що Linux не буває заражений або не потребує засобів захисту.

Перевірка файлів і пошук руткітів

Перевірка файлів корисна, зокрема, коли до спільних каталогів або розділів мають доступ комп’ютери з Windows: файл, який не виконується в Linux, може потрапити до іншої системи. У моїй добірці були:

• ClamAV — антивірусний набір інструментів; може бути корисним, зокрема, для перевірки пошти та файлів, які передаються між різними системами.
• chkrootkit — перевірки ознак відомих руткітів.
• rkhunter — інструмент пошуку підозрілих змін та ознак руткітів; результат вимагає перевірки.
• AVG — був одним із варіантів для Linux у моїй тодішній добірці. Згодом підтримку домашньої Linux-версії припинили — це підтверджує відповідь підтримки AVG.

Добирайте засоби під завдання

Засоби мають різні завдання, тому їх не слід вважати взаємозамінними чи гарантією виявлення всіх загроз. Кількість установлених сканерів сама по собі не визначає рівень захисту, а вплив на швидкодію залежить від режиму їхньої роботи.

Спостереження за мережевими з’єднаннями

Для спостереження за мережею я також звертав увагу на EtherApe та IPTraf. EtherApe графічно показує мережеву активність і протоколи, а IPTraf подає мережеву статистику в консолі. Це засоби діагностики трафіку, а не антивірусні сканери.

Див. офіційну документацію ClamAV: вона описує можливості сканера та прямо відрізняє його від повного комплексу захисту кінцевого пристрою.