Через відвідуваність мого старого блогу http://nerusoft.blogspot.com/ я вирішив дублювати там повідомлення з нового блогу.
Додатковим мотивом було збереження матеріалів: під час попереднього збою сервера безповоротно втрачено чимало дописів. У початковій нотатці подію віднесено до попереднього року без докладної дати.
Дублювання публікацій тоді здавалося корисним додатковим способом збереження, але воно не замінює повної резервної копії та перевірки відновлення.
Через відвідуваність мого старого блогу http://nerusoft.blogspot.com/ я вирішив дублювати там повідомлення з нового блогу.
Додатковим мотивом було збереження матеріалів: під час попереднього збою сервера безповоротно втрачено чимало дописів. У початковій нотатці подію віднесено до попереднього року без докладної дати.
Дублювання публікацій тоді здавалося корисним додатковим способом збереження, але воно не замінює повної резервної копії та перевірки відновлення.
У різні періоди для проєктів і публікацій ми створювали кілька сайтів. У цій нотатці збережено їхній тодішній перелік:
http://corp2.net — сайт системи «Корпорація 2».http://nerusoft.com — старий корпоративний сайт.http://rudjuk.kiev.ua — персональна сторінка Сергія Рудюка, один із найстаріших наших сайтів.http://i1.kiev.ua — добірка сайтів.http://users.iptelecom.net.ua/~3r/ — давній сайт на майданчику Iptelecom.http://nerusoft.blogspot.com/ — блог розробника.http://rsa.ms — сайт торгової марки RS.Це історія вебресурсів, а не підтвердження поточної належності, доступності або вмісту кожної адреси. Для звернень щодо K2: WhatsApp +380679016322.
У лютому 2009 року я опублікував перелік параметрів, які тоді обговорювали в контексті пошукової оптимізації. Він добре відображає тогочасний підхід: багато уваги приділяли підрахунку ключових слів, обсягу сторінок і формальним ознакам оформлення.
Нижче збережено зміст цього переліку, згрупований за темами. Це історичні припущення про роботу пошуку, а не підтверджена формула ранжування всіх пошукових систем.
Варто розділяти доступність для сканування, індексування та показ у результатах. Google описує ці етапи в офіційній довідці про роботу пошуку. Технічна ознака сторінки не обов'язково є окремим сигналом ранжування.
У посібнику Google Search Central прямо зазначено: meta keywords не використовується, а надмірне повторення ключових слів порушує правила щодо спаму. Підрахунок слів і кількість сторінок самі собою не утворюють рецепта високих позицій.
Практичний початок роботи — корисний зміст, зрозуміла структура, доступні сторінки, змістовні заголовки, посилання та описи зображень. Старий перелік допомагає побачити еволюцію SEO, але для поточних рішень потрібна документація конкретної пошукової системи.
У первісній нотатці був такий перелік поштових серверів Google:
ASPMX.L.GOOGLE.COM.
ALT2.ASPMX.L.GOOGLE.COM.
ALT1.ASPMX.L.GOOGLE.COM.
ASPMX4.GOOGLEMAIL.COM.
ASPMX5.GOOGLEMAIL.COM.
ASPMX2.GOOGLEMAIL.COM.
ASPMX3.GOOGLEMAIL.COM.Числових пріоритетів у джерелі немає, тому порядок рядків не можна вважати готовою конфігурацією DNS. Перелік залишено для історії.
Поточна офіційна інструкція Google Workspace наводить значення smtp.google.com із пріоритетом 1; для доменів зі старими налаштуваннями можуть використовуватися інші записи. Перед зміною перевірте інструкцію саме для вашого сценарію та чинні записи домену.
Для доменів зі старими MX-записами типу aspmx Google прямо зазначає: якщо пошта працює, змінювати ці записи не потрібно.
У старій нотатці я порівнював доступні моєму домену 1500 облікових записів Google-пошти з лімітом 50 для нових доменів, який тоді спостерігав. Наводилася квота 7,2 ГБ на скриньку.
Арифметично це давало 1500 × 7,2 = 10 800 ГБ, або 10,8 ТБ у десятковому поданні, і 50 × 7,2 = 360 ГБ. Проте сума індивідуальних квот не означає автоматично спільний простір, який можна довільно розподіляти між користувачами.
Різниця здавалася мені великою, хоча я вважав, що й меншого ліміту здебільшого мало вистачати. Це була особиста оцінка, а не результат дослідження потреб користувачів.
Ці числа збережено як опис умов того часу зі слів автора. Точну редакцію сервісу й правила для домену не зафіксовано, а твердження про достатність «у 99,9% випадків» не було підкріплено даними. Нотатка не описує поточних квот або тарифів Google Workspace: їх потрібно звіряти для конкретної підписки.
У старій нотатці я порівнював доступні моєму домену 1500 облікових записів Google-пошти з лімітом 50 для нових доменів, який тоді спостерігав. Наводилася квота 7,2 ГБ на скриньку.
Арифметично це давало 1500 × 7,2 = 10 800 ГБ, або 10,8 ТБ у десятковому поданні, і 50 × 7,2 = 360 ГБ. Проте сума індивідуальних квот не означає автоматично спільний простір, який можна довільно розподіляти між користувачами.
Різниця здавалася мені великою, хоча я вважав, що й меншого ліміту здебільшого мало вистачати. Це була особиста оцінка, а не результат дослідження потреб користувачів.
Ці числа збережено як опис умов того часу зі слів автора. Точну редакцію сервісу й правила для домену не зафіксовано, а твердження про достатність «у 99,9% випадків» не було підкріплено даними. Нотатка не описує поточних квот або тарифів Google Workspace: їх потрібно звіряти для конкретної підписки.
Ця архівна публікація анонсувала підготовку версії 1.0.3.0 програми «Розрахунок і проєктування шаф» як проміжного етапу переходу до «Корпорація 2».
Після переходу на «Корпорація 2» передбачалися:
Перелік описує тодішній план, а не перевірені функції випущеної версії чи сучасну сумісність. Поточні питання щодо K2: WhatsApp +380679016322.
На момент цієї публікації ми планували нові версії програм «Розрахунок і проєктування шаф», «Екзамен», «Реплікатор» та AutoFill і подальшу підтримку цих продуктів.
Довгостроковим задумом була інтеграція в «Корпорація 2», де окремі продукти мали працювати як плагіни.
Протягом наступного місяця планувався випуск нової версії «Корпорація» з адаптацією до актуальних тоді операційних систем і врахуванням змін меблевого виробництва після 2003 року.
Це повідомлення про наміри того часу, а не підтвердження строку релізу, поточної підтримки чи складу сучасних продуктів. K2 ERP — інформаційна система, K2 Platform — платформа розробки. Звернення щодо K2: WhatsApp +380679016322.
На нашому сервері закінчилося дискове місце, після чого почалися збої MySQL. Перевірка показала проблему в резервуванні: під час архівування до вхідних даних знову потрапляли результати попереднього копіювання.
Через це обсяг продовжував зростати, і доступного запасу близько 150 ГБ не вистачило. У початковому тексті це описувалося як заповнення «до нескінченності»; точніше говорити про повторне включення архівів, обмежене місткістю носія.
Практичний висновок із цього випадку — відокремлювати каталог резервних копій від джерел або явно виключати його, контролювати вільне місце, завершення завдання та правила зберігання. Після збою бази причину й стан даних потрібно перевіряти окремо; сама поява вільного місця ще не підтверджує їхню цілісність.
Ця нотатка зберігає стару процедуру створення власного центру сертифікації та сертифіката сервера через допоміжний скрипт OpenSSL CA.sh. Вона не є готовою конфігурацією для сучасної Ubuntu або Apache.
Цю процедуру опублікував Олександр Єлісеєнко на OpenNET 11 травня 2004 року. У своїй нотатці я зберіг такі команди:
cd /usr/local/ssl/misc
# Створення власного центру сертифікації
./CA.sh -newca
# Створення запиту сервера
./CA.sh -newreq
# Підписання запиту власним центром
./CA.sh -sign
# Команди копіювання з оригіналу — див. уточнення нижче
cp newreq.pem /usr/local/etc/apache/sslkey/server.key
cp newcert.pem /usr/local/etc/apache/ssl.crt/server.crtУ джерелі також зазначалося розповсюдження сертифіката центру ./demoCA/cacert.pem на клієнтські комп'ютери. Довіра до власного центру має встановлюватися свідомо й контрольовано: такий центр не стає загальнодовіреним лише через створення сертифіката.
Не можна автоматично вважати newreq.pem приватним ключем. Наприклад, у документованому CA.pl -newreq приватний ключ записується в newkey.pem, а запит — у newreq.pem. Поведінку конкретного старого CA.sh потрібно перевіряти за його версією та вмістом файлів перед налаштуванням Apache.
Для сучасного розгортання окремо перевіряють відповідність ключа сертифікату, імена хостів, строк дії, ланцюжок довіри й права на приватний ключ. Саме виконання архівних команд не підтверджує коректної конфігурації HTTPS.
Первісні адреси: http://www.opennet.ru/tips/info/681.shtml та http://www.opennet.ru/base/net/apache_mod_ssl.txt.html. Довідка для зіставлення: OpenSSL CA.pl.
Матеріал «Найпоширеніші схеми шахрайства» перенесено до тематичного блогу.
У початковому повідомленні зазначено адресу: pravdak.blogspot.com. Цей допис збережено як повідомлення про перенесення; самого тексту статті тут немає.
У лютому 2009 року мене зацікавила добірка у Вікіпедії про впровадження Ubuntu в державних установах, освіті та великих технологічних організаціях. Я й сам користувався Ubuntu та поступово переводив на неї свої комп'ютери.
У 2007 році Національні збори Франції вирішили використовувати Ubuntu на своїх робочих станціях. У січні 2008 року жандармерія оголосила поетапний перехід; у тодішніх планах ішлося про десятки тисяч комп'ютерів. Архівний кейс європейського порталу показує, що це був процес, який спирався на попереднє впровадження відкритих програм, а не одночасна заміна всіх систем.
У листопаді 2007 року Canonical повідомила про план понад 180 тисяч учнівських робочих місць з Edubuntu в тодішній Республіці Македонія. Йшлося про поєднання звичайних ПК та віртуальних терміналів, а не про 180 тисяч окремих системних блоків.
Первинна добірка згадувала також Грузію й Іспанію. Такі повідомлення потрібно читати в контексті окремих програм і дат, а не як твердження про всі школи країни. Для Іспанії пізніший кейс Canonical за березень 2010 року описує 220 тисяч робочих місць на основі Ubuntu в Андалусії. Це інший датований показник, ніж 400 тисяч із тодішньої загальної добірки.
Google справді використовувала внутрішній дистрибутив Goobuntu на основі Ubuntu LTS для корпоративних Linux-пристроїв. Це не означало, що всі системи Google працювали на ньому. У розповіді команди Google пояснено, що у 2018 році було завершено перехід на модель rolling release на основі Debian.
Згадка про сервери Вікіпедії також має історичне підґрунтя: кейс Canonical, опублікований у 2010 році, описує вибір Ubuntu для уніфікації серверного середовища Wikimedia. Це свідчення того етапу розвитку інфраструктури, а не її поточний опис.
Для мене ці приклади були аргументом уважніше випробовувати Ubuntu у власній роботі. Практичний перехід усе одно починається з перевірки потрібних програм, обладнання та процесів.
Уже втретє за короткий час я зіткнувся з проблемами роботи сторонніх ICQ-клієнтів. Тоді я пов’язував ці відключення зі змінами протоколу ICQ. Треба визнати: такі повторення вже починали набридати.
Версій клієнтів, журналів помилок та офіційного пояснення я не зберіг. Тому точно описати масштаб збою або підтвердити відключення всіх сторонніх програм за цим записом неможливо. Це моє спостереження за повторюваною проблемою в тодішньому робочому середовищі.
Зберіг собі посилання на добірку корисних прикладів Ajax і JavaScript на WebPHP.
http://webphp.ru/60-professionalnyx-ajax-i-javascript-reshenij/Це була коротка закладка: власного переліку бібліотек, версій чи прикладів коду я до неї не додавав. Перш ніж переносити рішення з цієї добірки у власний проєкт, потрібно перевірити його код, залежності та сумісність із потрібними браузерами.
Під час роботи з TortoiseSVN через SSH мене турбували повторні запити імені користувача та пароля. У старій нотатці пропонувалося відкрити TortoiseSVN → Settings → Network і вписати пароль безпосередньо в команду SSH-клієнта.
Це небажаний спосіб збереження секрету. Архівний рядок із заповнювачами виглядав так:
C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe -l ПользовательВSSH -pw ПарольДляПользователяВSSHТут немає справжнього пароля, але в реальному налаштуванні параметр -pw зберігав би секрет у відкритому вигляді в командному рядку. Також шлях із пробілами має бути взятий у лапки:
"C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe"Якщо TortoisePlink.exe встановлено в іншому каталозі, у полі SSH client потрібно вказати його фактичний повний шлях, а не копіювати наведений каталог.
Для уникнення повторного введення розгляньте автентифікацію SSH-ключем з агентом Pageant відповідно до політики доступу. Офіційна довідка TortoiseSVN описує поле SSH client, лапки в шляхах і використання Pageant.
У старих браузерних конфігураціях для взаємодії з вбудованими Flash-об'єктами іноді був потрібен попередній клік активації. У первісній нотатці я шукав спосіб зручнішого вбудовування через SWFObject.
Цю поведінку IE не слід подавати як незмінну: у бюлетені Microsoft 2008 року вже повідомлялося про її заплановане усунення. Початкове пояснення через патент не відтворюється як перевірений юридичний висновок.
Для прозорого фону та вимкнення меню Flash у моєму тодішньому проєкті використовувався такий фрагмент:
<div id="flashcontent">
Этот текст будет заменен флэшкой.</div>
<script type="text/javascript">
var flashvars = false;
var params = {
wmode: "transparent",
menu: "false"
};
var attributes = {
id: "myDynamicContent",
name: "myDynamicContent"
};
swfobject.embedSWF("/bitrix/templates/ashato/images/guitar.swf", "flashcontent", "130", "133", "8.0.0",
"expressInstall.swf", flashvars, params, attributes);
</script>Код показано як текст, тому він не запускає скрипт чи Flash у статті. Збережені назви SWF-файлів, розміри, параметри й ідентифікатори належать до старого проєкту.
http://noregret.org/tutor/swfobject/http://www.flasher.ru/forum/showthread.php?p=794865http://code.google.com/p/swfobject/http://designformasters.info/posts/flash-embed-with-swfobject-2/Adobe припинила підтримку Flash Player 31 грудня 2020 року та заблокувала виконання Flash-контенту з 12 січня 2021 року. Тому цей приклад є історичним; для нової реалізації потрібні сучасні вебтехнології. Джерело: Adobe Flash Player EOL.
Ця пам'ятка описує внутрішні домовленості історичної версії «Корпорація 2 CMS». Файл corp_runner.php містив основні класи завантаження вебчастини. Правила нижче не є специфікацією сучасних K2 ERP чи K2 Platform.
У програмній частині тоді використовували Windows-1251, називаючи її «ANSI», а в базі даних — UTF-8. Документацію зберігали в UTF-8; файли перекладів — переважно у Windows-1251, за потреби в UTF-8.
Таке рішення автор пов'язував із проблемами сесій, невидимими символами після include/require та виведенням тексту в зображення. Проте з цього не випливає, що PHP загалом краще працює з «ANSI» або не підтримує UTF-8. PHP не задає єдиного кодування рядків; важлива узгодженість даних і функцій. Передчасний вивід також може порушити надсилання заголовків сесії — його слід діагностувати окремо.
Замість прямого виведення пропонувалося користуватися обгорткою; це не було обов'язковою вимогою:
$c->myecho('Текст');Для доступу до бази застосовували функції системи. Перетворення кодування в цій пам'ятці описано так:
$c->dc('Текст'); // з UTF-8 у поточне кодування
$c->ec('Текст'); // з поточного кодування в UTF-8Це контракт, наведений для тієї версії; фактичну реалізацію потрібно звіряти з її кодом. Коротке ім'я $c використовували замість $corp. Первинні ключі отримували через:
$c->myid();Словник передавали у вигляді асоціативного масиву:
$this->s(array(
"Идентификатор перевода 1" => "Перевод 1",
"Идентификатор перевода 2" => "Перевод 2",
"Идентификатор перевода 3" => "Перевод 3"
));Ідентифікатор перекладу виводили таким викликом:
$c->tr('Идентификатор перевода');У каталогах використовували файл desc для пояснення функціональності, а в компонентах — також каталоги документації. Потрібно було описувати роботу компонента, призначення функцій і змінних.
SQL виконували через обгортки системи:
$c->q('SQL-запрос'); // виконання запиту
$c->fetch($dataset); // отримання наступних даних із джерелаТочний результат і обробка помилок залежать від реалізації. Наявність обгортки сама по собі не підтверджує безпечного формування SQL.
Джерела технічних уточнень: рядки PHP, mbstring, headers_sent. Контакт щодо K2: WhatsApp +380679016322.
У розробці «Корпорація 2» програмісти могли змінювати основне ядро. Зміни вносили через систему контролю версій Subversion (SVN).
Для роботи з репозиторієм був потрібен клієнт SVN. Тим, хто працював у Windows, я пропонував TortoiseSVN.
У повідомленні була вказана така адреса репозиторію:
svn+ssh://corp2.net/d2/svn/corp2Для підключення я просив співробітників надіслати заявку на rs@rsa.ms і після цього мав видати ім’я користувача та пароль. Зазвичай ці реквізити збігалися з обліковими даними для SSH. Це опис порядку роботи команди на час публікації; поточну доступність цього репозиторію тут не підтверджено.
Схема svn+ssh використовує автентифікацію SSH і передає протокол Subversion через зашифроване SSH-з’єднання. Механізм описано у Version Control with Subversion.
Для звернень щодо K2: WhatsApp +380679016322.
У лютому 2009 року я звернув увагу на перехід від двозначних номерів екстрених служб до тризначних: 01 → 101, 02 → 102, 03 → 103, 04 → 104.
Початковий текст попереджав про майбутню зміну «через два тижні». Це стосувалося часу тієї публікації, а не нового переходу сьогодні.
Офіційна інформація МВС про Службу 112 пояснює можливість звернення за одним номером для координації потрібних служб. Перелік 101, 102, 103, 104 та 112 також наведено на офіційній сторінці контактів ДСНС. Довідку перевірено 2 листопада 2026 року.
Ще цікавішою для мене виявилася статистика відвідувань нашого сайту за грудень 2008 року: у ній знайшлися і Macintosh, і різні дистрибутиви Linux, і мобільні операційні системи.
Це дані конкретного ресурсу й тодішнього засобу розпізнавання ОС. Відсотки в таблиці описують цю вибірку відвідувань.
| Операційна система / категорія | Кількість | У межах групи, % | Загальна частка, % |
|---|---|---|---|
| Microsoft Windows | 11793 | 100 | 98,38 |
| Microsoft Windows XP | 10452 | 88,63 | 87,19 |
| Microsoft Windows Vista | 1062 | 9,01 | 8,86 |
| Microsoft Windows Server 2003 | 118 | 1,00 | 0,98 |
| Microsoft Windows 2000 | 113 | 0,96 | 0,94 |
| Microsoft Windows 98 | 37 | 0,31 | 0,31 |
| Microsoft Windows CE | 6 | 0,05 | 0,05 |
| Microsoft Windows 95 | 3 | 0,03 | 0,03 |
| Microsoft Windows NT 4.0 | 1 | 0,01 | 0,01 |
| Microsoft Windows ME | 1 | 0,01 | 0,01 |
| Linux | 136 | 100 | 1,13 |
| Linux Ubuntu | 53 | 38,97 | 0,44 |
| Linux - невідома версія | 45 | 33,09 | 0,38 |
| Linux Mandriva | 13 | 9,56 | 0,11 |
| Linux Debian | 11 | 8,09 | 0,09 |
| Linux SUSE | 10 | 7,35 | 0,08 |
| Linux SeaMonkey | 2 | 1,47 | 0,02 |
| Linux Fedora | 2 | 1,47 | 0,02 |
| Macintosh | 39 | 100 | 0,33 |
| Macintosh | 39 | 100,00 | 0,33 |
| ОС мобільних пристроїв | 11 | 100 | 0,09 |
| Невідома ОС мобільного пристрою | 11 | 100,00 | 0,09 |
| xBSD | 5 | 100 | 0,04 |
| FreeBSD | 5 | 100,00 | 0,04 |
| Інші ОС | 3 | 100 | 0,03 |
| Symbian OS | 2 | 66,67 | 0,02 |
| Sun OS | 1 | 33,33 | 0,01 |
У звіті спочатку наведено підсумок групи, потім її складові; підсумок і підрядки не слід додавати вдруге. Показник кількості не дає підстав ототожнювати його з числом унікальних людей.
Отже, лічильник усе-таки враховував Macintosh: у грудневій таблиці його частка становила 0,33%. Це допомогло мені уточнити питання, що виникло під час перегляду іншої вибірки статистики ОС, де Macintosh не було видно.
Linux мав 1,13%, а Windows — 98,38%. Серед усіх зафіксованих відвідувань Windows XP становила 87,19%, Windows Vista — 8,86%.
Тоді я припускав: якщо Microsoft наполегливо просуватиме Vista замість звичної користувачам XP, частина людей може перейти на системи поза сімейством Windows. Такий розвиток подій здавався мені можливим, але сама таблиця показує лише розподіл відвідувань за грудень 2008 року.
«Linux SeaMonkey» — назва категорії у старому звіті. Сам SeaMonkey є пакетом інтернет-застосунків із браузером та поштовим клієнтом, а не окремим дистрибутивом Linux. Цей рядок варто читати з урахуванням того, як лічильник розпізнавав відвідування.
У лютому 2009 року я переглянув статистику відвідувань нашого сайту за операційними системами. Хотілося зрозуміти, чим користуються наші відвідувачі та чи приходить хтось із Linux і FreeBSD.
Точного інтервалу збору цих даних я не записав. Таблиця описує відвідування конкретного сайту; її відсотки не є частками світового ринку.
| Операційна система / категорія | Кількість | У межах групи, % | Загальна частка, % |
|---|---|---|---|
| Microsoft Windows | 441 | 100 | 98,22 |
| Microsoft Windows XP | 396 | 89,80 | 88,20 |
| Microsoft Windows Vista | 35 | 7,94 | 7,80 |
| Microsoft Windows 2000 | 5 | 1,13 | 1,11 |
| Microsoft Windows Server 2003 | 3 | 0,68 | 0,67 |
| Microsoft Windows 98 | 2 | 0,45 | 0,45 |
| Linux | 6 | 100 | 1,34 |
| Linux Ubuntu | 4 | 66,67 | 0,89 |
| Linux SUSE | 1 | 16,67 | 0,22 |
| Linux Mandriva | 1 | 16,67 | 0,22 |
| xBSD | 2 | 100 | 0,45 |
| FreeBSD | 2 | 100,00 | 0,45 |
У звіті спочатку наведено підсумок групи, потім її складові; підсумок і підрядки не слід додавати вдруге. Показник кількості не дає підстав ототожнювати його з числом унікальних людей.
Windows XP залишалася беззаперечним лідером, хоча Microsoft уже просувала Windows Vista. Водночас відвідування з Linux і FreeBSD були — нехай їхня частка й залишалася невеликою.
Macintosh у таблиці не відображався. Я тоді й сам припускав, що причина могла бути в роботі лічильника, тому робити з цього висновок про всіх користувачів Mac не варто.
Мені хотілося, щоб люди активніше освоювали Linux. Його частка в цій вибірці становила 1,34%, і я очікував її зростання: під час економічної кризи люди шукали способи заощадити. Безплатне програмне забезпечення та недорогі компактні комп’ютери, зокрема нетбуки, здавалися мені одним із таких шляхів.
У старому проєкті я зіткнувся з тим, що значення параметра форми, очікуване як save, надходило з додатковими символами ¬_. Проблему помітили під час роботи з IE6, Safari та Opera. У початковій нотатці підозрювалося також передавання через POST, але окремої перевірки цього припущення не наведено.
Ілюстрація отриманого значення та порівняння з оригіналу:
$_GET['op']='save¬_'
if ($_GET['op']=='save'){'программный код'}Фрагмент вище показує задум перевірки й не є готовим виконуваним прикладом: рядок у фігурних дужках — заповнювач. Через відмінність у значенні порівняння з save не давало очікуваного результату.
У «Корпорація 2» тоді використовувалася власна функція очищення:
$GLOBALS["c"]->clrget('Поле');У тексті також був наведений такий виклик:
echo 'op= '.$GLOBALS["c"]->clrget($_GET["op"])Очікуваний результат у тому випадку — op=save. Ці записи по-різному описують аргумент: спершу назву поля, потім його значення. Без реалізації методу clrget не можна вважати їх взаємозамінним або документованим API.
Пізніше я пов’язав помилку з формою, де action містив параметри URL, а методом було обрано POST. Однак саме поєднання цих елементів не доводить причини додавання символів і не є загальною властивістю браузерів. Для діагностики потрібно перевіряти HTML форми, кодування, фактичний запит і обробник параметрів; універсальне відрізання двох символів може пошкодити правильні значення.
Механізм надсилання форм описано в стандарті HTML. Наведена нотатка стосується конкретної історичної реалізації.
У 2009 році я звернув увагу на інструменти Яндекс.Вебмайстра для власників сайтів. Додавання свого ресурсу та підтвердження прав давали доступ до відомостей про його обхід пошуковим роботом.
Мене зацікавила можливість бачити помилки обходу, час відвідування сайту роботом і пояснення проблем із присутністю в пошуку. Початкова адреса консолі була http://webmaster.yandex.ru/wmconsole/.
Сучасна документація сервісу про статистику обходу розрізняє дату відвідування, адресу сторінки та HTTP-код відповіді. Успішний обхід сторінки не тотожний гарантії її появи в пошуковій видачі.
У лютому 2009 року я зберіг уривки матеріалу про PageRank з woweb.ru/publ/31-1-0-714. Частина формул у старій публікації втратилася, а деякі поради змішували математичну модель із практикою пошукової оптимізації. Нижче — впорядковане пояснення з уточненнями.
Уявімо користувача, який переходить між вебсторінками: іноді за посиланням, іноді починає перегляд із випадково вибраної сторінки. PageRank описує стаціонарний розподіл імовірностей перебування на сторінках у такій моделі. Повторні відвідування можливі; умова «ніколи не потрапляти на ту саму сторінку двічі» зі старого переказу була неточною.
Для нормованої спрощеної моделі, де кожна сторінка має вихідні посилання, формулу можна записати так:
PR(p) = (1 - d) / N + d * sum(PR(q) / L(q))
q -> pТут N — кількість сторінок, L(q) — кількість вихідних посилань зі сторінки q, а сума охоплює сторінки, які посилаються на p. У цьому записі d — імовірність переходу за посиланням, 1 − d — випадкового переходу. У літературі позначення можуть відрізнятися, тому важливо читати визначення коефіцієнта. Приклад такого запису є в навчальному матеріалі Stanford.
Для сторінок без вихідних посилань потрібне окреме правило розподілу їхньої ваги. У матричній формі використовують матрицю переходів і повторні ітерації над вектором оцінок. Вага переходу за посиланням визначається кількістю вихідних посилань, а не просто початковим значенням 1/N. За стандартних умов моделі з додатною ймовірністю випадкового переходу отримують єдиний стаціонарний розподіл.
Google підтверджує, що PageRank розвинувся від початкової реалізації та залишається частиною основних систем ранжування. Практичні дії з посиланнями варто звіряти з правилами щодо посилального спаму. Корисні матеріали та зрозумілі переходи важливіші за спробу механічно «накрутити» одну оцінку.
У лютому 2009 року я зберіг нотатку про формування зрозумілих URL для динамічних сторінок Apache/PHP. Джерелом був матеріал woweb.ru/publ/36-1-0-336. У ньому розглядали чотири підходи: обробник помилки 404, MultiViews, ForceType і mod_rewrite.
Нижче збережено початкові фрагменти коду як історичні приклади. Вони залежать від конфігурації Apache та способу підключення PHP; некоректні конструкції окремо пояснено.
ErrorDocument 404 script.phpСтарий підхід пропонував обробляти вигаданий URL у скрипті, викликаному замість відсутньої сторінки. Наведений рядок не є готовим маршрутизатором: значення ErrorDocument має відповідати синтаксису Apache. Для наявної сторінки та справді відсутнього ресурсу потрібні різні результати обробки й HTTP-статуси.
Options MultiviewsУ нотатці припускали, що шлях на кшталт /one/two/three буде зіставлено з файлом one.php, а залишок обробить скрипт. Насправді MultiViews належить до узгодження вмісту: добір варіанта залежить від розширень і налаштувань. Це пояснює документація Apache. Такий механізм не є універсальною заміною маршрутизації.
<filesmatch index="">
ForceType application/x-httpd-php
</filesmatch>Цей блок у збереженому HTML мав некоректний запис секції FilesMatch, тому його не можна копіювати як чинну конфігурацію. ForceType задає тип вмісту; використання спеціального MIME-типу для запуску PHP залежало від історичної поведінки модулів. Apache рекомендує уникати такого покладання на «магічні» типи та налаштовувати обробник явно. Для PHP-FPM потрібна конфігурація відповідного способу підключення.
RewriteEngine On
Options +FollowSymlinks
RewriteBase /
RewriteRule ^index/(.*)$ /index.php/$1Модуль переписує шлях index/... у /index.php/.... Це не обов'язково зовнішнє перенаправлення браузера: переписування може бути внутрішнім. Контекст правила й прапорці визначають результат; дивіться mod_rewrite. Директива RewriteEngine сама собою не обмежує правила лише поточним каталогом.
У джерелі було й комбіноване налаштування:
RewriteEngine On
RewriteBase /
RewriteRule ^index/(.*)$ /index.php/$1
<filesmatch index.php="">
ForceType application/x-httpd-php
</filesmatch>Воно містить таку саму проблему запису FilesMatch. Приклад із сайтом webshops.ru пояснював задум: запит /index/webshops обробляє index.php, який визначає потрібну сторінку за URI. Це ілюстрація маршруту з давнього матеріалу, а не перевірена конфігурація цього сайту сьогодні. Замість старої змінної $REQUEST_URI у сучасному PHP зазвичай використовують $_SERVER['REQUEST_URI'].
Початковий матеріал пропонував такі рядки:
Header("HTTP/1.0 200 OK"); //строка нужна только для п. 1
Header("Last-Modified: ".gmdate("D, M d Y H:i:s",filemtime("index.php"))." GMT"); //строка пригодится в любом случаеheader() потрібно викликати до фактичного виведення вмісту. Не варто безумовно повертати 200 для будь-якого невідомого URL: відсутній ресурс має залишатися помилкою, інакше можливий soft 404.
Час зміни файла index.php не обов'язково відповідає часу зміни даних усіх сторінок, які він формує. Крім того, у форматі дати старого фрагмента переплутано порядок дня та місяця. Для HTTP-дати потрібен порядок на кшталт D, d M Y H:i:s у GMT; значення Last-Modified має описувати саме відповідне представлення ресурсу — дивіться RFC 9110.
У віртуальних каталогах старий матеріал пропонував абсолютні адреси або елемент base у секції head:
<base href="http://ваш_сайт.ru/"></base>Домен у цьому рядку — заповнювач. За стандартом HTML елемент base не має закривального тега; він впливає на всі відносні URL документа. Після зміни маршрутизації перевірте зображення, стилі, скрипти, форми та звичайні посилання.
Зрозумілі URL корисні для навігації, але динамічний сайт не потрібно «маскувати» під статичний заради самого пошуку. Для поточних рішень орієнтуйтеся на рекомендації Google щодо структури URL та конфігурацію свого сервера.
У нотатці про конфігурування файлового менеджера старого FCKeditor я зберігав таке довідкове посилання:
http://www.sergiusd.ru/scripts/fckfsys2#exampleТочна версія редактора й самі параметри в публікації не наведені. Адресу залишено для історії; її доступність і відповідність сучасним редакторам не підтверджені. Під час налаштування файлових операцій важливо окремо перевіряти дозволені каталоги, типи завантажень і права доступу.
Свого часу знайшов непогану збірку PHP-скриптів на WoWeb. Залишаю початкову адресу:
http://www.woweb.ruНа WoWeb.ru доступний каталог скриптів із розділом PHP. Серед категорій є гостьові книги, форуми, банери, каталоги посилань, чати й пошук. Це зручний спосіб зорієнтуватися в добірці за потрібним завданням.
Сам сайт пояснює, що скрипти збиралися в різний час і чимало серверних прикладів застаріли. Тому конкретний скрипт слід розглядати окремо: перевірити код, вимоги до PHP, ліцензію та придатність до свого проєкту. Наявність у каталозі сама по собі не підтверджує сумісності чи безпеки.
Для роботи із ZIP я зберіг посилання на http://blog.webmasterschool.ru/php/48/ та клас Create ZIP File з http://www.phpclasses.org. Нижче — приклади роботи зі старим стороннім класом і процедурним ZIP API.
Клас createZip не є вбудованим класом PHP. Його реалізації у статті немає; приклад залежить від окремого файла createZip.inc.php:
// Подключаем класс для работы с zip-архивами
include_once("createZip.inc.php");
$createZip = new createZip;
// Добавляем директорию
$createZip -> addDirectory("dir/");
// Добавляем файл
$fileContents = file_get_contents("img.jpg");
$createZip -> addFile($fileContents, "dir/img.jpg");
// Создаем архив
$fileName = "archive.zip";
$fd = fopen ($fileName, "wb");
$out = fwrite ($fd, $createZip -> getZippedfile());
fclose ($fd);
// Отдаем архив браузеру
$createZip -> forceDownload($fileName);
@unlink($fileName);
?>У прикладі $dir задає каталог призначення, $file — шлях до архіву, а $log вмикає діагностичний вивід. Функція проходить елементи архіву, створює каталоги та записує вміст файлів:
/**
* Распаковывает zip-архив в указанный каталог.
* $dir - полный путь к каталогу.
* $file - полный путь к zip-архиву.
* $log - флаг вывода диагностики.
*/
function unpackZip($dir, $file, $log=0) {
if ($log) echo "Start unpack [$file] into [$dir] directory...
";
if ($zip = zip_open($file)) {
if ($zip) {
// создать каталог, если он не существует
if (! file_exists($dir)) mkdir($dir);
while ($zip_entry = zip_read($zip)) {
$name = zip_entry_name($zip_entry);
if ($log) echo " <b>unpack </b>: $name
";
// последний символ имени
$last = substr($name, strlen($name)-1);
// если это каталог
if ($last == "/" || $last == "\\") {
$subdir = $dir."/".$name;
// создать каталог, если он не существует
if (! file_exists($subdir)) mkdir ($subdir);
} else {
// распаковать файл
if (zip_entry_open($zip, $zip_entry, "r")) {
$buf = zip_entry_read($zip_entry, zip_entry_filesize($zip_entry));
$fp = fopen($dir."/".zip_entry_name($zip_entry), "w");
fwrite($fp, $buf);
zip_entry_close($zip_entry);
} else {
return false;
}
}
}
zip_close($zip);
}
} else {
return false;
}
return true;
}
?>Ці фрагменти не є готовим рішенням для обробки недовірених архівів. У функції шлях запису складається безпосередньо з імені елемента ZIP: немає перевірки виходу за межі каталогу, обмежень обсягу розпакування чи надійного контролю помилок. Дескриптор записуваного файла явно не закривається; вкладені каталоги також обробляються неповно.
Крім того, zip_open() може повертати числовий код помилки, тому проста перевірка істинності не гарантує успішного відкриття. Цю функцію позначено застарілою з PHP 8.0 на користь об'єктного API ZipArchive.
Для нового коду звертайтеся до документації ZipArchive та перевіряйте шляхи, ліміти ресурсів і всі результати операцій. Довідка щодо старого виклику: zip_open. Історичний код збережено для розбору; не запускайте його без адаптації на довільних завантаженнях.
Після перезавантаження Linux у моїй тодішній конфігурації VMware почав скаржитися на зайняті ресурси: процесор, пам’ять, CD-ROM та інші пристрої. Гостьові машини в результаті не запускалися.
Я вирішив перевстановити VMware. Видалення пройшло успішно, але під час нового встановлення інсталятор повідомив про KVM і відмовився продовжувати, поки той запущений.
Активного KVM я тоді не бачив. Спробував видалити пакети, які могли бути з ним пов’язані, але це не допомогло.
Тоді я встановив KVM і відразу його видалив. І, о диво, після цього VMware нормально встановився, а віртуальні машини знову запустилися!
Проблема час від часу поверталася, і повторне встановлення та видалення KVM тимчасово її усувало. Я припускав, що справа в командах, які виконувалися під час видалення пакета. Утім, перевірки журналів або стану модулів для підтвердження цієї причини в мене не було.
Описаний результат показує послідовність дій у моїй старій системі, але не точний механізм конфлікту. Для його розбору потрібні версії VMware, KVM і ядра, повний текст помилки та журнали. Видалення пакетів навмання може зачепити потрібні компоненти, тому переносити цей обхід на іншу конфігурацію без діагностики не варто.
Сподобалася бібліотека pChart для побудови графіків у PHP. Залишаю початкову адресу зі своєї добірки:
http://pchart.sourceforge.netНа сайті pChart на SourceForge зберігся опис гілки 1.x. Бібліотека працює з даними, підготовленими вручну, з CSV або результатів SQL-запитів. Для побудови зображень потрібна підтримка GD у PHP.
У документації pChart є описи класів pChart, pData і pCache, структура даних та приклади лінійних, стовпчикових і кругових діаграм. Для розуміння коду зручно почати з підготовки набору даних, потім перейти до області побудови, підписів і легенди.
Ці приклади належать до старої гілки бібліотеки. Якщо переносите такий проєкт на іншу версію PHP чи pChart, окремо перевірте сумісність викликів і вимоги GD. Умови ліцензії беріть із тієї версії бібліотеки, яку використовуєте.
VNC, або Virtual Network Computing, — підхід до віддаленого доступу до графічного робочого столу. Сервер передає зображення екрана, а клієнт надсилає події клавіатури та миші. Для цього використовується протокол RFB — Remote Framebuffer.
Клієнт і сервер можуть працювати в різних операційних системах, якщо відповідні реалізації сумісні. Це зручно для технічної підтримки й доступу до власного робочого середовища. Можливість одночасного підключення кількох клієнтів та конкретні функції залежать від сервера і його налаштувань.
VNC створили в Olivetti & Oracle Research Lab (ORL) у Кембриджі. У 1999 році AT&T придбала лабораторію, і розробка продовжилася в AT&T Laboratories Cambridge — цю послідовність наведено в історії RealVNC. Старі згадки Java та J2ME відображають тодішні реалізації, а не гарантію підтримки цих платформ зараз. Відкриті реалізації та похідні VNC поширюються, зокрема, за GNU GPL; прикладом є код LibVNCServer із позначенням GNU GPL та авторства первісного Xvnc. Водночас умови ліцензування потрібно перевіряти для конкретного продукту: назва VNC не означає, що кожна реалізація поширюється за GPL.
Механізм RFB описано в RFC 6143. Обираючи засіб доступу, окремо перевіряйте автентифікацію, захист з'єднання та дозволи користувачів.
http://ru.wikipedia.org/wiki/Virtual_Network_Computinghttp://ask.slashdot.org/article.pl?sid=04/10/20/0132236&tid=185&tid=201&tid=4Кого криза зачіпає найболючіше? У лютому 2009 року, розмірковуючи над цим питанням, я насамперед думав про тих, кому вже бракувало грошей і ресурсів. Коли витрати перевищують можливості, запасу для несподіваного удару залишається небагато.
Але пояснити вразливість компанії лише дефіцитом бюджету було б надто просто. Значення мають і зобов'язання, і доступ до коштів, і залежність від постачальників, енергії та зовнішніх рішень. Навіть прибуткове підприємство може зіткнутися з перервою в роботі.
Великий прибуток у звіті ще не означає, що в потрібний день є чим виконати всі платежі. Прибуток і рух коштів — різні показники: IAS 7 про звіт про рух грошових коштів окремо розглядає надходження й виплати та пояснює коригування прибутку при непрямому методі.
У своєму дописі 2009 року я наводив можливі сценарії: обмеження доступу до грошей або припинення постачання газу на завод. Суть цих прикладів — у зовнішній залежності. Компанія може добре виконувати свою роботу, але втратити можливість продовжувати її через подію поза власним контролем.
Моя головна думка тоді була проста: не варто розраховувати, що криза омине саме нас або що хтось обов'язково врятує бізнес. Підготовку до перебоїв потрібно продумувати заздалегідь.
Практично це починається з кількох запитань:
Такий підхід описано в рекомендаціях Канадського центру кібербезпеки щодо безперервності бізнесу: визначити загрози й наслідки, підготувати порядок дій, розподілити відповідальність і перевіряти план на практиці.
Передбачити кожну подію неможливо. А от знати власні слабкі місця й мати погоджений порядок дій — цілком реальна робота. Саме вона допомагає не опинитися «за бортом», коли звичні умови раптом змінюються.
У лютому 2009 року я звернув увагу на повідомлення про збитки й реструктуризацію Sony. Початкова нотатка посилалася на itnews.com.ua/46310.html і поєднувала фінансову цифру зі скороченням працівників та виробничих майданчиків. Для точного розуміння ці події потрібно розділити.
У повідомленні від 9 грудня 2008 року Sony оголосила план скоротити кількість виробничих майданчиків приблизно на 10% із тодішніх 57 до 31 березня 2010 року. Звідси походить оцінка близько п'яти-шести підприємств.
В електронному бізнесі планували скорочення приблизно 8 тисяч штатних працівників, а також зменшення сезонної та тимчасової робочої сили. Стару загальну цифру «16 тисяч» не варто подавати як число вже звільнених штатних співробітників: це змішує категорії та оголошений план із результатом його виконання.
У звітності Sony від 29 січня 2009 року за квартал жовтень–грудень 2008 року наведено операційний збиток 18 млрд єн, або 197 млн доларів у перерахунку компанії. Водночас чистий прибуток цього кварталу становив 10,4 млрд єн.
У тій самій звітності прогноз операційного збитку на фінансовий рік до 31 березня 2009 року становив 260 млрд єн, приблизно 2,9 млрд доларів за наведеним курсом. Саме прогноз річного операційного результату, квартальний операційний збиток і чистий прибуток не можна називати однією цифрою «втрат».
Для мене криза тоді була перевіркою компаній на міцність: навіть великий масштаб сам по собі не захищає бізнес від боргового навантаження та втрати позицій на ринку. Так я пояснював свій інтерес до цих новин у лютому 2009 року; це авторський висновок, а не твердження про неплатоспроможність Sony.
Тодішня ситуація показувала, як падіння попиту, валютні зміни та витрати впливають на велику технологічну компанію. Ця публікація описує стан і плани на межі 2008–2009 років, а не сучасний фінансовий стан Sony.
У лютому 2009 року в мене почали зависати віртуальні машини у VMware Server. Проблема не обмежувалася гостьовою системою: разом із нею зависала вся Ubuntu 8.10.
Довго намагався знайти причину, а потім установив VMware Workstation. У ньому віртуальні машини знову почали запускатися.
Працювало, щоправда, якось повільно — але все ж працювало. Це було моє враження від роботи системи, а не вимірювання продуктивності VMware Server і Workstation.
Номерів збірок, журналів помилок і точних налаштувань у тій нотатці немає. Тому вона описує перебіг мого збою та заміну інструмента, але не встановлює його технічну причину й не визначає сумісність інших версій VMware або Ubuntu.
У лютому 2009 року я звернув увагу на повідомлення про зміни в європейських офісах Google. Тодішня нотатка спиралася на новину itnews.com.ua/46299.html. Первинне повідомлення компанії дозволяє точніше описати, що саме відбувалося.
У заяві від 14 січня 2009 року компанія повідомила про консолідацію інженерних команд в Остіні, Тронгеймі та Лулео. Зміни стосувалися близько 70 інженерних працівників у цих трьох містах разом. Google прагнула зберегти якомога більше з них, запропонувавши роботу в інших офісах, але не гарантувала переведення кожного.
Це уточнює старий переказ: йшлося про конкретні інженерні майданчики, а не про повне припинення діяльності Google у Швеції або Норвегії. Кількість 40 працівників із вторинної новини не слід підміняти загальним масштабом оголошених змін.
Того самого дня Google опублікувала повідомлення про скорочення приблизно 100 посад у рекрутингу на тлі уповільнення найму. Це інший захід, який не варто змішувати з переведенням інженерів.
У початковій нотатці я пов'язував новини з економічною кризою. Сам факт реорганізації не доводить збитковості компанії чи недостовірності її фінансової звітності. Ця публікація зберігає контекст 2009 року й описує тодішні оголошення, а не поточний стан офісів Google.
У цій короткій нотатці 2009 року я зберіг посилання на матеріал про вплив економічної кризи на великі IT-компанії:
http://mobilnik.ua/articles/442.html
У самому дописі немає таблиць, показників чи висновків із того матеріалу. Посилання збережено як частину історії публікації.
Поступово переходячи на Linux, я шукав заміну звичному ICQ-клієнту. LICQ мені не зовсім підійшов: у моїй конфігурації були спотворення під час передавання даних і питання до використаних портів.
Варіанти Pidgin і SIM знайшов у статті за адресою http://ubuntueasy.com/internet/icq-klienty-v-ubuntu-linux-7-10.
У моїй тодішній Ubuntu Pidgin уже був установлений: достатньо було відкрити «Програми → Інтернет» і запустити його. Це був мультипротокольний клієнт, який не обмежувався ICQ. Наявність у цій інсталяції не означала, що Pidgin є обов’язковою частиною кожної системи з GNOME.
Далі я додавав обліковий запис, обирав протокол ICQ, вводив потрібні дані й підключався. Спочатку вигляд здавався незвичним, та до нього можна було звикнути; нестандартні звуки теж налаштовувалися.
Для обміну зі співрозмовниками на інших системах я тоді звертав увагу на параметр cp1251. Він стосувався сумісності кодування в тому середовищі й не був універсальним налаштуванням для всіх месенджерів.
SIM нагадував звичайний ICQ-клієнт і теж підтримував кілька протоколів. Водночас для його встановлення в моїй Ubuntu доводилося додавати залежності KDE — їхня кількість тоді здалася мені суттєвим мінусом.
У старому репозиторії використовувався такий рядок встановлення:
sudo apt-get install simУстановлену програму шукали в меню «Програми → Інтернет».
Зрештою поставив собі Pidgin. Непоганий виявився пейджер: кілька протоколів, робота в Linux і, коли звик, цілком приємний інтерфейс.
Описаний вхід до ICQ стосується 2009 року. Згодом протокол змінився, і розробники Pidgin пояснили в офіційній довідці про протоколи, що самі не підтримують його новий варіант. Старий рядок встановлення SIM також не підтверджує наявності пакета в репозиторії вашої версії Ubuntu.
14 лютого 2009 року QIP сам повідомив мені про нову версію та запропонував її завантажити.
Я встановив запропоноване оновлення — і ICQ знову запрацював нормально.
Знову проблеми з ICQ у QIP… У моїй тодішній версії клієнта підключення періодично не працювало.
Мені знову надійшло сповіщення, що мій варіант ICQ-клієнта не підтримується. І це при тому, що встановлена версія QIP була однією з новіших на той момент!
Раніше подібні відключення сторонніх клієнтів я пов’язував зі змінами протоколу ICQ. Нове повідомлення нагадало ту ситуацію, але саме по собі воно не пояснювало причини повторного збою. Для точного розбору потрібні версія QIP, текст діагностики та дані про стан сервісу в той час.
Коли мій шлюз на Windows почав сильно збоїти, я вирішив перенести його функції на Ubuntu 8.10. Раніше це мені не вдавалося: провайдер надавав інтернет через VPN, а для з’єднання треба було правильно вказати чимало параметрів.
Цього разу все запрацювало на ура! Допоміг NetworkManager, у якому можна було налаштовувати різні типи з’єднань: дротові, бездротові, DSL і VPN. Саме зручніше керування з’єднанням стало для мене головною відмінністю від попередніх спроб.
Налаштування VPN я тоді розбирав за статтею:
http://openkazan.info/ubuntu-8.10-vpn-pptp
З Firestarter довелося повозитися окремо, щоб узгодити його роботу з VPN. Для цього використовував такі обговорення й матеріали:
http://liski.vsi.ru/ubuntu/index.php?page=79http://forum.ubuntu.ru/index.php?topic=42746.0Перебіг цієї спроби та обмеження знайденого обходу описав у попередньому дописі про Firestarter і VPN. Сам факт роботи з’єднання ще не засвідчує правильності правил фільтрації.
У підсумку в моїй конфігурації вдалося зробити більше, ніж до цього на Windows:
Це досвід налаштування Ubuntu 8.10 у 2009 році. Точні старі адреси залишив для зв’язку з тією конфігурацією; їхній вміст нині не вдалося перевірити. Опис типів з’єднань тогочасного NetworkManager зберігся в довідці Ubuntu для NetworkManager 0.7.
У старій конфігурації VPN я зіткнувся з проблемою взаємодії Firestarter і з'єднання через ppp0. Guarddog мені не підійшов, тому я повернувся до Firestarter й знайшов обговорення за адресою http://forum.ubuntu.ru/index.php?topic=42746.0.
Спочатку я вибрав ppp0 як інтерфейс, що дивиться в інтернет, і відредагував /etc/firestarter/user-pre. Наведений варіант із політиками ACCEPT міг істотно послабити фільтрацію — саме тому його не варто переносити як готове безпечне налаштування:
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPTЦе встановлює політику ACCEPT для відповідних вбудованих ланцюжків. Така політика дозволяє пакети, для яких не спрацювало інше завершальне правило; вона не видаляє наявні правила, але може істотно послабити фільтрацію. Відновлення VPN таким способом не підтверджує безпечного налаштування.
На інших форумах я також зустрічав такі правила:
$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:
sudo /etc/init.d/firestarter restartДля діагностики слід перевіряти фактичні правила, журнали та потрібні напрямки трафіку, з можливістю повернення попередньої конфігурації. Технічний опис дії правил і протоколу: Netfilter: iptables та RFC 2637: PPTP. Цей історичний розбір не є рекомендацією обирати PPTP для нового VPN.
У 2009 році для редагування правил iptables я розглядав графічні оболонки Firestarter і Guarddog. Firestarter здавався простішим, але в моїй конфігурації переривалися VPN-з’єднання; Guarddog був складнішим у налаштуванні. Це особисте спостереження, без версій і журналів збою.
Ядро Linux містить підсистему Netfilter, а правила налаштовують відповідними інструментами. Не всі конфігурації зводяться до редагування одного текстового файла й не кожна система автоматично має потрібні правила.
У сучасному контексті також є nftables і засоби керування на кшталт ufw. Конкретний інструмент і спосіб збереження правил залежать від дистрибутива та його версії. Для Ubuntu це пояснює документація щодо міжмережевих екранів.
На час цієї нотатки 2009 року я працював із Unix-подібними системами вже близько п’яти років, якщо не більше, і особисто не стикався з Linux-вірусами. Проте цей досвід не дає підстав стверджувати, що Linux не буває заражений або не потребує засобів захисту.
Перевірка файлів корисна, зокрема, коли до спільних каталогів або розділів мають доступ комп’ютери з Windows: файл, який не виконується в Linux, може потрапити до іншої системи. У моїй добірці були:
Засоби мають різні завдання, тому їх не слід вважати взаємозамінними чи гарантією виявлення всіх загроз. Кількість установлених сканерів сама по собі не визначає рівень захисту, а вплив на швидкодію залежить від режиму їхньої роботи.
Для спостереження за мережею я також звертав увагу на EtherApe та IPTraf. EtherApe графічно показує мережеву активність і протоколи, а IPTraf подає мережеву статистику в консолі. Це засоби діагностики трафіку, а не антивірусні сканери.
Див. офіційну документацію ClamAV: вона описує можливості сканера та прямо відрізняє його від повного комплексу захисту кінцевого пристрою.
Перший день у новій ERP часто починається з пошуку потрібної кнопки. Наступний виклик складніший: зрозуміти, що зміниться після натискання. ...
