Skip to content


Якби Google був українським державним підприємством

Якби Google був українським державним підприємством, то:

  1. Пошукові запити потрібно було б подавати у письмовій формі, на спеціальному бланку, у вівторок та четвер із дев'ятої до одинадцятої години ранку, за місцем прописки. Для цього було б необхідно відстояти чергу.
  2. Бланк із письмовим запитом включав би сам пошуковий запит, а також дату вашого народження, адресу прописки, місце реального проживання, кількість дітей, ідентифікаційний код, паспортні дані. До запиту потрібно приклеїти кольорову фотографію (як на закордонний паспорт), не давнішу ніж три місяці.
  3. Письмовий запит подавати у кількості три оригінальні примірники.
  4. До письмового запиту слід долучити також:
    • довідку про відсутність судимості;
    • довідку про відсутність боргів за комунальні послуги, в тому числі довідку про відсутність боргів за опалення до 2002 року;
    • довідку нарколога та психіатра про дієздатність;
    • приписне свідоцтво або військовий квиток;
    • письмову заяву батьків, подругів та дорослих дітей про те, що вони не проти того, щоб ви подавали заявку на пошук в Інтернеті. Якщо у вас є неповнолітні діти, необхідно дозвільне рішення опікунської ради;
    • висновок експертної комісії при Міністерстві внутрішніх справ про те, що ваш запит не може призвести до розкриття державної таємниці (документи приймаються кожну третю суботу непарного місяця з 16:00 до 16:30);
    • висновок регіонального відділення Національної комісії з питань моралі про те, що ваш запит не містить матюків та порнографії (документи за місцем прописки тимчасово не приймаються в зв"язку з ремонтом);
    • довідку поліклініки про те, що ви пройшли планову вакцинацію і через ваш запит в Інтернет не проникнуть шкідливі віруси;
    • довідку про відсутність інших пошукових запитів, які перебувають у розгляді ДП "Гугль".
  5. Перед поданням запиту слід оплатити:
    • вартість пошуку (чотириста п'ятдесят гривень);
    • страховий внесок (вісім гривень п'ятдесят копійок);
    • обов'язковий добровільний внесок у фонд "Гугль майбутнього" (дев'яносто три гривні одинадцять копійок, БУДЬ ЛАСКА БЕЗ ЗДАЧІ - У НАС НЕМАЄ КОПІЙОК!).
  6. Запит приймається до розгляду лише після підписання Додаткової угоди, згідно з якою ви зобов'язуєтеся не користуватися іншими пошуковими сервісами в Інтернеті протягом трьох років із дня підписання угоди. Угода підписується в присутності державного нотаріуса (вартість послуг нотаріуса - сто п'ятдесят гривень).
  7. За "Витягом з Інтернету" (офіційна назва результатів пошуку) слід з'явитися не раніше, ніж через двадцять робочих днів, вистоявши ще одну чергу. Витяг ви отримаєте в друкованій формі (матричний прінтер). У зв'язку з браком коштів у державному бюджеті графічні матеріали в результатах пошуків не друкуватимуться.
  8. Якщо результатів іще немає, необхідно чекати ще двадцять робочих днів, після чого ви маєте право повторити запит.

У випадку, якщо ви володієте вебсайтом в Інтернеті і надаєте вільний доступ до інформації, згідно з Законом N666-66 від 38 лютого 2010 року, в зв'язку з необхідністю державного регулювання інформаційної політики в Інтернеті, а також для уніфікації пошукових сервісів та для зручності доступу громадян України до інформації в Інтернеті, ви зобов'язані:

  • негайно передати всю інформацію з Вашого веб-сайту Державному підприємству "Український Гугль" на дискетах діаметром 3.5 дюйми (допускаються тільки дискети приватного підприємство "Дискета-Гугль" вартістю 25 гривень за одиницю товару);
  • після отримання підтвердження, видалити усю інформацію з вашого вебсайту протягом 5 календарних днів.

Posted in Fun.


PuTTY: делаем Windows полезным

В данной статье будет описано как строить SSH-туннели с помощью PuTTY.

1. Локальный проброс порта

Рассмотрим следующую ситуацию. Мы находимся внутри корпоративной сети, у нашего компьютера адрес 192.168.0.2, доступ во внешний мир полностью закрыт (то есть никакого NAT-а, proxy и т.п.). Влиять на политику ограничения доступа у нас возможности нет, но зато есть SSH-доступ на один из серверов с маршрутизируемым IP-адресом, который доступен из Интернет. Внутренний адрес этого сервера, пусть будет для примера 192.168.0.3. Структура сети изображена на рисунке:

Схема сети
Предположим, что нам очень нужно подключиться, к примеру, по SSH на некоторый удалённый сервер с IP-адресом 212.212.212.212 где-то далеко в Интернет. Для этого запускаем PuTTY, создаём SSH-подключение к серверу 192.168.0.3 (далее по тексту SSH-сессия 1), идем в пункт Tunnels:
Local port forwarding
и указываем, что локальный порт 2222 нашего компьютера должен быть поставлен в соответствие порту 22 на сервере с IP-адресом 212.212.212.212. Далее жмем кнопку "Open", авторизуемся на сервере 192.168.0.3. Затем создаём ещё одно подключение (далее по тексту SSH-сессия 2), но уже на localhost, порт 2222 и жмём кнопку "Open":Окно создания нового подключения


В результате SSH-сессия 2 будет туннелироваться (т.е. будет установлена внутри ранее установленной SSH-сессии 1). Для удалённого сервера 212.212.212.212 всё будет выглядеть так, как будто к нему подключается 111.111.111.111:
Схема подключения через SSH-туннель

2. Удалённый проброс порта

В этом случае подключение внутри SSH-туннеля устанавливается в другую сторону – от удаленного сервера на наш локальный компьютер. Может быть полезно, если требуется открыть доступ к локальным сервисам нашего компьютера. Рассмотрим ту же сеть, что и в пункте 1, но для простоты предположим, что теперь у нас есть NAT:
Локальная сеть с NAT, remote port forwarding
Здесь уже у нас есть возможность подключаться через SSH напрямую к 212.212.212.212 благодаря наличию NAT-а. А вот 212.212.212.212 подключиться на 192.168.0.2 без специальных ухищрений, понятное дело, не сможет, т.к. 192.168.0.2 не подключен к Интернет непосредственно. Предположим, что пользователю, сидящему под X-ами на 212.212.212.212 нужно через remote desktop попасть на наш компьютер 192.168.0.2. Для этого в SSH-сеансе подключения с 192.168.0.2 на 212.212.212.212 нужно изменить настройки в разделе Tunnels следующим образом:
Remote ssh port forwarding setup
В результате после успешной авторизации на 212.212.212.212 можно увидеть следующее:

#lsof -i -nP | grep 3333
sshd  18598   avz   11u  IPv4 592868957   TCP 127.0.0.1:3333 (LISTEN)

То есть sshd ожидает подключений на TCP-порт 3333, которые затем по SSH-туннелю будут перенаправлены на 192.168.0.2 порт 3389. И юзер сидящий за 212.212.212.212 сможет с помощью rdesktop увидеть наш рабочий стол:

Remote port forwarding via putty

3. Socks-proxy

В этом случае мы можем использовать сервер с SSH-демоном как промежуточный (proxy). Схема сети как в случае #1 (без NAT и штатных прокси):
Схема сети
Чтобы заставить PuTTY испольнять роль socks-прокси, нужно параметры SSH-сессии с 192.168.0.2 на 192.168.0.3 изменить следующим образом:
DynamicВ результате после успешной авторизации со стороны клиента можно будет наблюдать следующее:

C:\>netstat -ano | find "1080"
  TCP    127.0.0.1:1080     0.0.0.0:0      LISTENING       2392
C:\>tasklist | find /i "2392"
putty.exe                2392 Console        0             5420 КБ

То есть putty, выполняющийся с PID-ом 2392, начинает слушать порт 1080, ожидая подключений. Далее берем любое приложение, умеющее работать с SOCKS-прокси, например Firefox, и указываем ему использовать наш прокси:
Firefox proxy configuration dialogТеперь все запросы от броузера будут проходить через сервер 192.168.0.3. В логах веб-сайтов, по которым мы таким образом будем ходить, будет отображаться внешний IP-адрес нашего сервера - 111.111.111.111.

P.S. Из help-файла Putty 0.58:
Question A.10.3: What does ‘PuTTY’ mean?
It's the name of a popular SSH and Telnet client. Any other meaning is in the eye of the beholder. It's been rumoured that ‘PuTTY’ is the antonym of ‘getty’, or that it's the stuff that makes your Windows useful...
:)


P.P.S. Другой способ туннелирования трафика описан в заметке Разворачивание трафика на основе policy routing. Весьма рекомендую к прочтению.

Posted in *nix, Windows.

Tagged with , , , .


Программный RAID в Linux

RAID will also not help you preserve your data if the server holding the RAID itself is lost in one way or the other (theft, flooding, earthquake, Martian invasion etc.)
(из Software-RAID-HOWTO)

Есть программный RAID-массив уровня 1. Однажды сервер прислал письмо, что с RAID-ом проблемы:

Date: Mon, 14 Jun 2010 11:18:44 +0300
From: mdadm monitoring <[email protected]>
To: [email protected]
Subject: DegradedArray event on /dev/md1:some.server.org

This is an automatically generated mail message from mdadm running on some.server.org
A DegradedArray event had been detected on md device /dev/md1.
Faithfully yours, etc.
P.S. The /proc/mdstat file currently contains the following:
Personalities : [raid1] [raid6] [raid5] [raid4] [raid0]
md1 : active raid1 sdb1[0]
156288256 blocks [2/1] [U_]
md0 : active raid1 sdc3[1] sda3[0]
4192896 blocks [2/2] [UU]
unused devices: <none>

Здесь видно, что у массива md1 отвалился один из двух компонентов (знак подчеркивания вместо буквы U в /proc/mdstat). Через fdisk -l вычисляем имя второго компонента массива и видим, что на устройстве /dev/sdd вообще отсутствуют разделы:

[root@~]# fdisk -l /dev/sdd
Диск /dev/sdd: 160.0 ГБ, 160041885696 байт
255 heads, 63 sectors/track, 19457 cylinders
Единицы = цилиндры по 16065 * 512 = 8225280 байт
На диске /dev/sdd отсутствует верная таблица разделов

Для сравнения смотрим на второй диск массива:

[root@~]# fdisk -l /dev/sdb
Диск /dev/sdb: 160.0 ГБ, 160041885696 байт
255 heads, 63 sectors/track, 19457 cylinders
Единицы = цилиндры по 16065 * 512 = 8225280 байт
Устр-во Загр   Начало    Конец      Блоки  Id  Система
/dev/sdb1  *        1    19457  156288321  fd  Автоопределение Linux raid

Следовательно, нужно содать на sdd раздел типа "fd" (linux raid autodetect) и добавить этот раздел в массив.

[root@~]# fdisk /dev/sdd
Команда (m для справки): n
Действие команды
   e   расширенный
   p   основной раздел (1-4)
p
Номер раздела (1-4): 1
Первый цилиндр (1-19457, по умолчанию 1):
Используется значение по умолчанию 1
Последний цилиндр или +size или +sizeM или +sizeK (по умолчанию 19457):
Используется значение по умолчанию 19457
Команда (m для справки): t
Выбранный раздел 1
Шестнадцатеричный код (введите L для получения списка кодов): fd
Системный тип раздела 1 изменен на fd (Автоопределение Linux raid)
Команда (m для справки): w
Таблица разделов была изменена!
Вызывается ioctl() для перечитывания таблицы разделов.
Синхронизируются диски.
 
[root@ ~]# fdisk -l /dev/sdd
Диск /dev/sdd: 160.0 ГБ, 160041885696 байт
255 heads, 63 sectors/track, 19457 cylinders
Единицы = цилиндры по 16065 * 512 = 8225280 байт
Устр-во Загр   Начало    Конец      Блоки  Id  Система
/dev/sdd1           1    19457  156288321  fd  Автоопределение Linux raid
 
[root@~]# mdadm --manage /dev/md1 --add /dev/sdd1
mdadm: re-added /dev/sdd1

Далее смотрим в /proc/mdstat и видим, что массив начал синхронизацию:

Personalities : [raid1] [raid6] [raid5] [raid4] [raid0]
md1 : active raid1 sdd1[2] sdb1[0]
  1562882 blocks [2/1] [U_]
  [===========>...] recovery = 76% (1194268/1562882) finish=4.3min speed=42M/sec

А если один из компонентов массива переходит в статус "Failed", то обычно помогает его ручное удаление из массива, а затем – добавление заново. Например:

[root@~]# grep md1 /proc/mdstat -A 1
md1 : active raid1 sdb1[1] sdd1[2](F)
      14659200 blocks [2/1] [_U]
 
[root@~]# mdadm --manage /dev/md1 --remove /dev/sdd1
[root@~]# mdadm --manage /dev/md1 --add /dev/sdd1

Чтобы управлять скоростью синхронизации, есть в ядре 2 параметра:

$ cat /proc/sys/dev/raid/speed_limit_min
1000
$ cat /proc/sys/dev/raid/speed_limit_max
200000

Это значения по умолчанию (в Кбайт/сек). Если нужно ускорить процесс, то делаем примерно так:

echo 200000 > /proc/sys/dev/raid/speed_limit_min

Posted in *nix, Howto.

Tagged with , .


Ограничение количества получателей в exim

Поскольку спамеры заинтересованы в отправке почты максимальному количеству получателей, они часто в одной SMTP-сессии передают множество команд "RCPT TO". Так как нормальный юзер такое будет делать очень редко (если вообще будет), то очень полезно ограничить количество получателей для одного письма для минимизации распространения спама через почтовый сервер. Для этого в exim предусмотерна опция recipients_max, числовое значение которой и устанавливает максимально допустимое число получателей одного письма. Если exim работает чисто как relay и не принимает почту для локальных доменов, то просто установки в exim.conf

recipients_max = 10

должно быть достаточно (число 10 взято для примера). В противном же случае, когда exim помимо relay-инга еще и является primary mx для некоторых доменов, использование recipients_max может вызвать проблемы, поскольку количество получателей для входящей почты также будет лимитироваться. Представим ситуацию, когда на сервере пару тысяч пользователей (обычное дело для провайдеров и freemail-сервисов) и 12 из них подписалось на одну и ту же полезную рассылку. При приведённой выше конфигурации почтовый сервер рассылки сможет доставить письмо только 10-ти из этих пользователей, а оставшиеся 2 пойдут пинать админа со словами "почему у меня не работает почта". И вот чтобы всё было по фен-шую, нужно лимитировать количество получателей только для исходящих писем (когда сервер используется как relay). Для этого в блок списков контроля доступа, который соответствует acl_smtp_rcpt, нужно добавить следующее (так, чтобы новые правила были примерно 4-ым и 5-ым сверху если считать для exim.conf, который идет по-умолчанию):

defer condition = RELAY_RCPT_LIMIT_ENABLE
  message = Too many recipients
  condition = ${if >={$recipients_count}{RELAY_RCPT_LIMIT_NUM} {yes}{no}}
  hosts = +relay_from_hosts
  !authenticated = *
 
defer condition = RELAY_RCPT_LIMIT_ENABLE
  message = Too many recipients
  condition = ${if >={$recipients_count}{RELAY_RCPT_LIMIT_NUM} {yes}{no}}
  !hosts = +relay_from_hosts
  authenticated = *

Ну и перед блоком "begin acl" определить две опции:

# Флаг, включающий или выключающий ограничения числа получателей
RELAY_RCPT_LIMIT_ENABLE = yes
# Максимально допустимое число получателей в одном письме
RELAY_RCPT_LIMIT_NUM = 10

Первое условие будет срабатывать для хостов, которым разрешёно использовать почтовый сервер как relay, но которые не прошли аутентификацию. А второе – для хостов, которые прошли аутентификацию, но которым запрещен relay-инг без неё. А вот хосты, которые не могут использовать сервер как relay и которые НЕ прошли аутентификацию проверять не надо, поскольку они доставляют входящую почту на домены, для которых наш exim является primary MX. Четвёртый вариант (хосты, прошедшие аутентификацию и которым разрешён relay) также ограничивать смысла нет, так как обычно эти два множества не пересекаются.

Posted in *nix, Howto.