Наткнулся на статью "SSH-туннели — пробрасываем порт" и захотелось ее дополнить.

Итак, какие еще способы тунеллирования есть:

1. Динамический доступ через SSH

Допустим мы имеем SSH доступ в сеть, и хотим получить доступ к другим хостам/портам в этой сети. Способ уже описанный в вышеупомянутой статье предполагает знание хоста: порта куда мы хотим получить доступ. Но что если мы не знаем этого?

Тут может пригодиться динамический доступ через SSH. Для его конфигурации используется опция ssh -D.

ssh -D 127:0.0.1:2222 user@remotehost

После подключения вы получите динамический socks4 прокси-сервер, слушающий на своей машине на порту 2222 и предоставляющий доступ к удаленной сети.

Как воспользоваться этим доступом? Один из вариантов — использовать proxychains.

• Устанавливаем Proxychains:
  
  

  apt-get proxychains
  

  
  
• Конфигурируем proxychains для использования порта 2222 (на нем слушает наш прокси). Для этого редактируем файл /etc/proxychains.conf и меняем текущую конфигурацию в разделе [ProxyList] с socks4 127.0.0.1 9050 на socks4 127.0.0.1 2222
  
• Теперь мы можем использовать proxychains с (почти) любой утилитой. Например, можно запустить сканирование всей удаленной сети при помощи nmap:
  
  

  proxychains nmap -sT -sV -v -P0 адрес_подсети маска_подсети
  

  
  

Раньше, когда надо было распределить нагрузку на несколько серверов, мы прописывали несколько A-записей с одним именем в DNS-зоне, и все работало. Запросы клиентов распределялись примерно поровну. Особенно актуален такой способ балансировки был для раздачи статитического контента.

Недавно наш клиент обратился к нам с проблемой:
В ЧНН начинались проблемы с загрузкой различных флешек — файлы загружались по несколько минут.

Что обычно делает python-программист, когда его отправляют воевать с ошибкой?
Сначала он лезет в sentry. Здесь можно найти время, сервер, подробности сообщения об ошибке, traceback и, может быть, какой-нибудь полезный контекст. Затем, если этих данных недостаточно, программист идет c бутылкой к админам. Те залезают на сервер, ищут это сообщение в файловых логах, и, может быть, находят его и некоторые предшествующие ошибке записи, которые в редких случаях могут помочь в расследовании.
А что делать, если в логах только loglevel=ERROR, а ошибка настолько крута, что ее локализация требует сопоставления логики поведения нескольких различных демонов, которые запущены на десятке серверов?

Решение — централизованное хранилище логов. В самом простом случае — syslog (за 5 лет, что был развернут в rutube, не использовался ни разу), для более сложных целей — ELK. Скажу честно, "ластик" — крут, и позволяет быстро крутить разнообразную аналитику, но вы интерфейс Kibana видели? Этой штуке так же далеко до консольных less/grep, как винде до линукса. Поэтому мы решили сделать свой велосипед, без Java и Node.js, зато с sphinxsearch и Python.

Многие я думаю читали о применении Elasticsearch, Logstash и Kibana для сбора и анализа логов, но часто статьи начинаются с длинного мануала как поднять сервисы ELK и заставить работать их совместно.
Здесь я хочу рассказать о быстром старте с помощью Docker.

Записывая для VPSVille три ролика по Graylog понял, что на хабре по нему только одна обзорная статья, а мануалы на любом языке запутаны из-за различной работы компонентов в разных версиях ПО. Потратив сутки на переваривание всей этой красоты пишу мануал: как настроить сервер Graylog для сбора событий из Windows и Linux.

Кто очень хочет понимать Linux, но не поймет с чего начинать — прошу ко мне на канал.



Вместо введения: Graylog это open source программное обеспечение, предназначенное для сбора логов в гигантских сетях их огромного количества источников различными способами. В нем можно удобно организовать сбор событий, фильтрацию, поиск, автоматизацию (всякие алерты) и т.д. Аналогичных средств множество, но Graylog предлагает нереальную производительность с использованием современных компонентов, удобную аналитику и красивый интерфейс.
Для работы ему нужна Java, конфигурацию он будет хранить в MongoDB, для поиска и хранения логов — использовать ElasticSearch. Про сбор информации из WIndows будет ниже, но спойлер — агенту больше не нужна Java.

Мы в «Латере» занимаемся созданием биллинга для операторов связи и рассказываем на Хабре о разработке своего продукта, а также публикуем интересные технические переводные материалы. И сегодня мы представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.

Ранее в блоге на Хабре мы рассказывали о развитии нашего продукта — биллинга для операторов связи «Гидра», а также рассматривали вопросы работы с инфраструктурой и использования новых технологий. К примеру, мы рассмотрели плюсы Clojure, ситуации, когда стоит и не стоит использовать MongoDB и ограничения в PostgreSQL.

Сегодня речь пойдет о масштабировании. Разработчики open-source почтового приложения Nylas опубликовали в своем блоге материал о том, как им удалось масштабировать систему в 20 раз за три недели с помощью инструмента ProxySQL. Для этого им пришлось переехать с Amazon RDS на MySQL на EC2. Мы представляем вашему вниманию основные моменты этой интересной заметки.

Disclaimer: оригинальная статья, перевод которой здесь представлен, служит цели объявить о выходе новых старших версий продукта, рассказать в целом о политике версионирования и успехах за прошедший год. Если вас интересуют сухие технические подробности, то рекомендую смотреть полный лог изменений, либо его выжимку с кратким пояснением в конце статьи.

Мы рады представить NGINX 1.10 и 1.11. Эти номера версий обозначают стабильную (stable) и основную (mainline) ветки бесплатных открытых выпусков, над которыми мы сфокусируем наши усилия на протяжении следующих 12 месяцев.

NGINX версии 1.10.0 уже вышел, а будущий выпуск основной ветки будет под номером 1.11.0.

Deb пакеты очень удобный инструмент, особенно если знаешь как его использовать. Попробую поделиться собственным опытом в данном вопросе.

Добрый день, коллеги.

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

Исходные данные у нас такие: начинается разработка проекта, в которой планируется «тонкий бэкенд». Т.е. бэк у нас состоит из закешированных страниц (рендерятся любым шаблонизатором), объёмных моделей с сопутствующей логикой (ORM) и REST API, выполняющего роль контроллера. Фактически, View в такой системе редуцировано и вынесено в JS, благо есть разные реакты, ангуляры и прочие вещи, которые позволяют фронтендщикам считать себя «белыми людьми».

В чем отличие маршрута пакета от его пути?
Стандартный механизм маршрутизации пакетов в интернете — per hop behavior — то есть каждый узел в сети принимает решение куда ему отправить пакет на основе информации, полученной от протоколов динамической маршрутизации и статически указанных администраторами маршрутов.

Маршрут — это интерфейс, в который нам надо послать пакет для достижения какого то узла назначения и адрес следующего маршрутизатора (next-hop):

R1#sh ip rou | i 40.  
	 40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O        40.0.0.0/31 [110/3] via 20.0.0.0, 00:01:54, FastEthernet0/0
O        40.1.1.1/32 [110/4] via 20.0.0.0, 00:00:05, FastEthernet0/0

Что такое путь? Путь — это список узлов, через которые прошел (пройдет) пакет:

 1  10.0.0.1  16.616 ms  16.270 ms  15.929 ms
 2  20.0.0.0  15.678 ms  15.157 ms  15.071 ms
 3  30.0.0.1  26.423 ms  26.081 ms  26.744 ms
 4  40.0.0.0  48.979 ms  48.674 ms  48.384 ms
 5  100.0.0.2  58.707 ms  58.773 ms  58.536 ms

Путь пакета можно посмотреть с помощью утилит tracert в OC Windows и traceroute в GNU/Linux и Unix-подобных системах. (другие команды, типа tracepath мы не рассматриваем).
Многие считают что этих утилит один и тот же принцип работы, но это не так. Давайте разберемся.

• Почему в трейсроуте после узла X идут звездочки?
• Сервис не работает, а трейсроут обрывается на узле X — значит проблема в узле X?
• Почему одинаковые трейсроуты с Windows и Unix показывают разные результаты?
• Почему трейсроут показывает большие задержки на определенном узле?
• Почему трейсроут показывает «серые» адреса при трассировке через интернет?
• Почему маршрутизатор отвечает на трейсроут не тем адресом, каким я хочу?
• Почему трейсроут показывает какие-то «не такие» доменные имена?
• Почему вообще вывод трейсроута отличается от интуитивно ожидаемого чаще, чем хотелось бы?

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

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

Работать в пятницу после обеда первого апреля не хочется — вдруг ещё техника выкинет какую-нибудь шутку. Потому решил о чем-либо написать.
Не так давно на просторах хабра в одной статье огульно охаяли сразу Unix-сокеты, mysql, php и redis. Говорить обо всём в одной статье не будем, остановимся на сокетах и немного на redis.
Итак вопрос: что быстрее Unix- или TCP-сокеты?
Вопрос, который не стоит и выеденного яйца, однако, постоянно муссируемый и писать не стал бы если б не опрос в той самой статье, согласно которому едва-ли не половина респондентов считает, что лучше/надёжнее/стабильнее использовать TCP-сокеты.
Тем, кто и так выбирает AF_UNIX, можно дальше не читать.

Введение

В Badoo несколько десятков «самописных» демонов. Большинство из них написаны на Си, остался один на С++ и пять или шесть на Go. Они работают примерно на сотне серверов в четырех дата-центрах.

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

Однако у нас до недавнего времени не было очень важной части — сбора и анализа логов, которые каждый демон пишет локально в файлы на сервере. Зачастую именно эта информация помогает на самом раннем этапе поймать проблему или постфактум понять причины отказа.

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

Elasticsearch — поисковый движок с json rest api, использующий Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте. Далее по тексту будем называть Elasticsearch как ES.

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

В этой статье я расскажу про основы ES на примере индексации постов блога. Покажу как фильтровать, сортировать и искать документы.

От переводчика.

Привет! В последнее время было обнаружено довольно много уязвимостей, связанных с SSL, поэтому мне захотелось сделать перевод статьи, в которой собран список инструментов для тестирования SSL, TLS и различных уязвимостей. В статье довольно много терминов, поэтому хочу извиниться, если что-то перевела не совсем корректно. Если вы можете предложить лучший вариант перевода, пожалуйста, напишите в личные сообщения.

Привет, Хабр! В этом цикле статей я планирую рассказать о том, как можно организовать сбор и передачу данных с помощью одного из инструментов Hadoop — Apache Flume.

"The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code — not in reams of trivial code that bores the reader to death."
Guido van Rossum

Python — язык программирования, на котором приятно писать и который приятно читать. Мы предлагаем тринадцать лекций осеннего курса CS центра, чтобы посмотреть вглубь языка и попробовать понять, как пользоваться всеми его возможностями. Лекции читает Сергей Лебедев, разработчик в компании JetBrains и преподаватель в Computer Science Center.

Мало освоить синтаксис, чтобы узнать язык программирования: нужно осознать идиомы языка и научиться их применять. В течение курса Сергей знакомит слушателей с идиомами и возможностями языка Python.

_{Фотография сделана осенью 2014 года в Страсбурге, за две недели до начала первого прочтения этого курса.}

Abstract: описание того, как обновляется файл /etc/resolv.conf в условиях работающего dhcp-клиента, специфика различных ОС и варианты реализации.

Охват: Debian, Ubuntu, Centos/Fedora/RHEL; dhclient с resolvconf и без. NetworkManager не учитывается.

Лирика: Я только что потратил несколько дней (подробности на английском [1], [2]) разбираясь как правильно сохранять 'options rotate' в /etc/resolv.conf в разных дистрибутивах при работающим DHCP. Оказалось, внятной документации по этому вопросу нет, и информацию пришлось собирать из разных источников, исходных текстов и экспериментальных данных. Дальше будет сухо и по делу.

О чём речь?

У компьютера сетевой интерфейс принципиально может быть сконфигурирован тремя видами: вручную/специализированным софтом, статически заданными настройками и через DHCP-клиент. (Есть ещё сколько-то экзотики, но эти три — основные методы). Первый метод нам не интересен, со статической конфигурацией всё просто — как написано, так и будет. DHCP интересен тем, что компьютер запрашивает настройки по сети «у кого-то». Протокол DCHP имеет множество опций (настроек), которые могут изменять совершенно неожиданные настройки компьютера — часовой пояс, адрес сервера с точным временем, таблицу маршрутизации, имя или домен сервера, и т.д. Из всего этого нас интересует возможность задавать настройки DNS.

Традиционно, настройки DNS-ресолвера хранятся в файле /etc/resolv.conf, и после обновления dhcp-аренды этот файл обновляется. В этой статье объясняется, как именно "-ся" этот файл.

Устройство DHCP client

Существует несколько реализаций dhcp-клиента, нас интересует ISC DHCP, как наиболее распространённая.
Сам клиент называется /sbin/dhclient, однако, стандартно, для обновления настроек, вызывается не он, а /sbin/dhclient-script. dhclient-script вызывает dhclient и использует его ответ для изменения разных частей системы. В самом dhclient-script есть функция make_resolv_conf, которая, собственно, и создаёт файл resolv.conf.

Инфраструктура системы пакетов для Python долго подвергалась критике как от разработчиков, так и от системных администраторов. Долгое время даже само комьюнити не могло прийти к соглашению, какие именно инструменты использовать в каждом конкретном случае. Уже существуют distutils, setuptools, distribute, distutils2 в качестве базовых механизмов распространения и virtualenv, buildout, easy_install и pip в качестве высокоуровневых инструментов управления всем этим беспорядком.

До setuptools основным форматом распространения были исходные файлы или некоторые бинарные MSI-дистрибутивы для Windows. Под Linux были изначально сломанный bdist_dumb и bdist_rpm, который работал только на системах, основанных на Red Hat. Но даже bdist_rpm работал недостаточно хорошо для того, чтобы люди начали его использовать.

Несколько лет назад PJE попытался исправить эту проблему, предоставив смесь из setuptools и pkg_resources для улучшения distutils и добавления метаданных в Python-пакеты. В дополнение к этому он написал утилиту easy_install для их установки. По причине отсутствия формата распространения, поддерживающего метаданные, был предоставлен формат 'яиц' [egg].

Python eggs – обычные zip-архивы, содержащие python-пакет и необходимые метаданные. Хотя многие люди, вероятно, никогда намеренно не собирали egg'и, их формат метаданных до сих пор жив-здоров. И все разворачивают свои проекты с использованием setuptools.

К сожалению, некоторое время спустя сообщество разделилось, и часть его провозгласила смерть бинарных форматов и 'яиц' в частности. После этого pip, замена easy_install, перестал принимать egg-формат.

Потом прошло еще немного времени, и отказ от бинарных пакетов стал доставлять неудобства. Люди всё больше и больше стали деплоить на облачные сервера, а необходимость перекомпиляции C-шных библиотек на каждой машине не слишком радует. Так как 'яйца' на тот момент были малопонятны (я так полагаю), их переделали в новых PEP-ах, и назвали 'колёсами' [wheels].