Хмельной Девопс. Страница 4

Друзья, всем предлагаю зайти на свои сайты и проверить не добавит ли их chrome 17 Апреля в блеклист. В developer tools, console можно увидеть предупреждение, в случае, если google планирует добавить его в недоверенные:

The SSL certificate used to load resources from https://scdn.cxense.com will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.

Больше информации по ссылке выше. Небольшая цитата из статьи:

On January 19, 2017, a public posting to the mozilla.dev.security.policy newsgroup drew attention to a series of questionable website authentication certificates issued by Symantec Corporation’s PKI. Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements.

Вывод: используйте letsencrypt 🙂

На выходных я написал про то, как нейросети повлияют на рекламу будущего. Но даже без нейросетей рекламные кабинеты сегодня могут очень многое.

У фейсбука с 2010 года есть возможность для любого скачать архив своей страницы. И он может вас напугать.

— Там есть информация о всех ваших действиях с момента регистрации.
— Геолокация всех фотографий
— Геолокация всех мест, откуда вы когда-то заходили в фейсбук
— Ваш усредненный портрет, сделанный из всех фото с вами

Узнать, что еще фейсбук знает про вас и как скачать этот архив, вы можете из статьи.

https://hackernoon.com/your-facebook-data-is-creepy-as-hell-319ae47117e6

У многих очень часто возникают проблемы с настройкой firewall. А все потому что никто и никогда не пытается рисовать упрощенную схемку сети. Я для себя используют примерно такой алгоритм при настройке firewall:

1. Нарисовать схемку со всеми заинтересованными сторонами - локальная сеть, сервера, клиенты и тд и тп
2. Показать на этой схемке движение пакетов/сегментов/whatever
3. Описать словами или символами какие потоки должны быть разрешены, какие запрещены, какие перекинуты.
4. Переписать пункт 3 на языке фаервола (в нашем случае iptables).

Ниже будет приведена очень простая схема с локальной сетью и двумя серверами внутри.

Первый кейс - разрешить клиенту А доступ к firewall по ssh:

1.a Входящий трафик на интерфейсе eth0 от клиента с ip 1.1.1.1 на порт 22 разрешить
1.b iptables -I INPUT -i eth0 -s 1.1.1.1/32 -p tcp -m tcp --dport 22 -j ACCEPT

Второй кейс - нам надо пробрасывать все запросы, идущие к нам на порт 80, на зеленый сервер на порт 80:

2.a Весь входящий трафик на интерфейс eth0 на порт 80 проксировать на зеленый сервер на порт 80
2.b iptables -t nat -I PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination green_ip:80

Третий кейс - нам надо запретить красному серверу выходить в интернет:

3.a Весь входящий трафик на eth1 идующий от красного сервера в интернет запретить
3.b iptables -I INPUT -i eth1 -s red_ip/32 ! -d 172.16.0.0/24 -j DROP

Как вы можете заметить - весь локальный трафик, обращенный к firewall'у от красного сервера будет разрешен, что соответствует условию задачи.

И последний, четвертый кейс - маскировать исходящий адрес от всех клиентов локальной сети:

4.a Во всем трафике от пользователей локальной сети, идущим в интернет, маскировать исходящий адрес
4.b iptables -t nat -I POSTROUTING -o eth0 -s 172.16.0.0/24 -j MASQUERADE

Ну и вишинка на торте - блокируем весь остальной входящий трафик. Вообще есть два подхода к настройке firewall - blacklisting или whitelisting. При первом мы разрешаем все, что не запрещено. При втором наоборот - запрещаем все, что не разрешено. Я придерживаюсь подходе whitelisting и обычно меняю политику входящего (и исходящего) трафика на DROP. Так образом все что не разрешено явно будет запрещено:

iptables -P INPUT DROP

Кстати, про исходящие правила. Тут все точно так же как и с входящими, просто меняется вектор движения трафика. По этому поводу циско рекомендует придерживаться следующий правил:

1. Входящий трафик должен блокироваться как можно ближе к получателю
2. Исходящий трафик должен блокироваться как можно ближе к отправителю

Читал доклад Игоря Сысоева по nginx. Там была забавная шутка про sendmail и его конфигурацию. Прямо ностальгия нахлынула. Нашел ссылочку, вот делюсь - http://www.lib.ru/SENDMAIL/sendmail_cf.txt. Именно по причине конфигурации я в свое время ушел с sendmail'а. Потом был qmail, слава богу не долго. Потом postfix и наконец-то я добрался до exim'а, который использую везде и по сей день.
К слову сказать, большинство вещей я изучал по сайту lissyara.su и форуму sysadmin.ru. Ох и было время. 4 дня на комиляцию kde из портов, опен релей доступный для всех на постфиксе, свой сервер на балконе, чтобы не шумел в комнате.
Ах да, статья про exim тут - https://www.lissyara.su/articles/freebsd/mail/exim+dovecot+postfixadmin/

В последнее время очень часто на глаза попадаются дискуссии по поводу того стоит ли использовать swap на серверах или нет. Давайте разбираться. На данный момент оперативная память не является огромной проблемой для серверов. В хецнере меньше чем за 50 евро вы из коробки получаете 64Gb памяти. Прочитав кучу обсуждений я вынес для себя два сценария поведения:

1. Если вы хотите чтобы ваш сервис медленно деградировал - используйте swap. Вообще ситуация маловероятная, если оперативной памяти достаточно. Linux будет сбрасывать в кеш только действительно редкоиспользуемые страницы памяти, освобождая место для активных процессов и дискогового кеша. Проблемы начинаются тогда, когда у вас начинает активно свопиться редис или, к примеру, постгрес. Тогда сервис вроде бы работает, но как-то медленно. Что касается веб фронтов с healthchecks тут навряд ли будет какое-либо переключение, потому что ноды-то доступны.

2. Если вы хотите применять тактику fast fail - не используйте swap. Да, действительно, система начнет убивать процессы, которые используют много памяти. И это приведет к достаточно быстрому переключению на работающую ноду. Если у вас есть резерв конечно. Ну и в общем случае делать мониторинги на доступность намного проще, чем на время отклика, к примеру.

Итого, как любят говорить мои заокеанские коллеги - it depends. Делаем все по ситуации, главное не забываем про мониторинг каждого компонента. Тогда наступит счастье.

Наконец-то хорошее и детальное описание metldown/spectre. Изначально было понятно, что тем кто хостится сам у себя или на выделенных серверах особенно переживать не надо. Я думаю больше всех зацепила формулировка а) что проблема в железе б) что в железе выпускаемом уже 10 лет.
Я вас прошу - не поддавайтесь хайпам, а реально смотрите на ситуацию.

https://geektimes.ru/post/297029/ - metldown
https://geektimes.ru/post/297031/ - spectre

Дружно благодарим Олега Артамонова за прекрасное описание.

Телеграм представил свою криптовалюту и сеть TON (Telegram Open Network).

Кроме собственно криптовалюты, обещают (все имена с приставкой TON):
- сеть типа i2p (можно обходить цензуру(!) Proxy);
- распределенное хранилище типа торрентов (Storage);
- некую сеть для децентрализованных приложений и сматр-контрактов (Services);
- аналог сервиса DNS, чтобы не запоминать длинные адреса (DNS);
- платежную систему (Payments).

Насколько я понимаю, во всех случаях, речь идет не о классической полностью децентрализованной системе (такие ещё не научились делать достаточно быстрыми и удобными), но о неком балансе между удобством (в том числе скоростью) и децентрализацией.

Это означает, что телеграм будет иметь власть над этой валютой и этим платформами. Готовы ли будут люди сторговать часть власти на удобство — интересный вопрос. Как власти будут прессовать телеграм применять эту власть, если система «взлетит» — вообще попкорна не напасешься.

Обход сетевых блокировок, быстрые, удобные и дешевые микроплатежы — всё это звучит очень круто. Учитывая, что делают те люди, что запустили vk и tg — думаю, что не облажаются.

Редакция уже предлагают запрограммировать Медузу для этой сети 😂 (а почему бы и нет).

Вот краткое описание TON в картинках (23 страницы) и статья в научном стиле (132 страницы A4).

nginx-log-exporter

Про мониторинг nginx.
Помимо стандартных url чек и /status страниц можно собирать еще кучу дополнительных параметров. Я использую связку prometheus + nginx + несколько экспортеров. Немного подробнее о них:

1. https://github.com/vozlt/nginx-module-vts - vts модуль, которые выдает расширенную статистку по запросам/ответам прямо из недр nginx. Единственный минус данного модуля - нет разделения на коды ответов (только 2xx,3xx,4xx,5xx,...) и нет данных по времени ответа.
К этому модулю идет экспортер: https://github.com/hnlq715/nginx-vts-exporter, получаются вполне хорошие графики, по которым можно смотреть всплески 4-ых и 5-ых ошибок.

2. https://github.com/martin-helmich/prometheus-nginxlog-exporter - парсит лог файлы nginx'а, агрегирует все данные и потом отдает prometheus'у на хранение. Работает в режиме tail -f, то есть как демон. Позволяет выдавать интересную статистику по 90,99th percentile времени ответов и кодам ошибок. На скриншоте ниже данные с nginx-log-exporter с одной ноды. Главное не забыть добавить в лог файлы nginx время ответа клиенту и время ответа upstream, чтобы эти данные появились:


log_format time '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'$upstream_response_time $request_time';

Вы еще не используете curl? Тогда мы идем к вам!
Потрясающая утилита, которая позволяет вам очень быстро протестировать любой http сервис. Посмотреть хедеры, протестировать api, проверить ssl и многое многое другое. Возможно если бы я разрабатывал API целыми днями, то поставил бы себе какой-нибудь gui клиент и работал бы в нем. Но по долгу службы чаще всего приходится быстро сделать запрос и проверить ответ. И в этом curl'у нет равных.
Чаще всего я использую curl в таком виде:

curl -D - -s -o /dev/null -H 'Host: domain.com' -k https://app1.domain.com/

Немного об опциях:
1. -D - - дампить хедеры в -, что означает stdout.
2. -s - silent mode - не показывать скорость загрузки и не выводить ошибки
3. -o /dev/null - все что отдаст нам вебсервер выкинуть в /dev/null
4. -H 'Host: domain.com - добавить к запросу хедер Host: domain.com
5. -k - игнорировать валидность ssl сертификата - мы же обращаемся на конкретную ноду (app1.domain.com) и сертификат явно не совпадет с domain.com. Хотя возможно вы используете wildcard сертификаты и тогда в данном случае можно не заморачиваться.

Вот таким нехитрым способом можно быстро протестировать любой endpoint. Еще из полезных опций можно отметить:
1. -u user:password - указываем логин/пароль для basic auth
2. -d '{data}' - передать данные в POST запросе
3. -d @/path/to/file - передать в POST запросе данные из файла

А еще очень удобно смотреть json, передавай вывод curl на вход jq:

curl -s -o - http://google.com/json_response | jq .

Из интересного можно посмотреть еще на http://http-prompt.com, но у меня он не прижился - не любою интерактивные утилиты.

Отличный модуль для nginx для проверки жизнеспособности upstreams - https://github.com/yaoweibin/nginx_upstream_check_module. Нативный функционал доступен в платной версии nginx, поэтому данный модуль придется скомпилировать отдельно. После сборки и деплоя можно дописывать такие проверки в конфиг.

TCP Check:

check interval=3000 fall=2 rise=1 timeout=1000 default_down=false type=tcp;

HTTP Check:

check interval=3000 rise=2 fall=2 timeout=1000 type=http;
check_http_send "GET / HTTP/1.1\r\nHost: domain.com\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;

Если алерт в мониторинге горит красным больше недели-двух - удаляйте его.

Если горит 1 день и его заметили - чините.

Наверняка все слышали, а многие даже используют в своей повседневной работе pagerduty. (www.pagerduty.com). Недавно ребята обновили роуты до России и теперь вместо звонков из Америки (+1) звонки идут с +7 953. Самое неприятное в этом то, что теперь pagerduty звонит три раза подряд без остановки. Если раньше можно было просто сбросить звонок и начать разбираться с проблемой, то теперь это надо сделать три раза. Особенно неприятно, когда инцидент плавающий и он то появляется то исчезает - пойди-ка разберись с проблемой, когда тебе постоянно звонят.

Кстати, если вы прячитесь от коллекторов и боитесь брать трубку с незивестных номеров - добавьте pagerduty vcard со всеми исходящими телефонными номерами, которые использует pagerduty - https://support.pagerduty.com/v1/docs/notification-phone-numbers.