Работаю я админом сетевой и серверной инфраструктуры в немецкой конторе околофинансового сектора. Количество сотрудников — меньше 100, из которых ИТ отдел занимает довольно малый процент, а разработчиков можно пересчитать по пальцам одной руки.

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

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

Так вот, руководству этого показалось мало, и захотелось внедрить еще что-нибудь эдакое, модное. По каковой причине зимой нам прямо в офисе организовали тренинг по Kanban.

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

В основном проблем не возникло, но одна из наших сотрудниц с месяц назад, когда все выглядело еще не так страшно, поехала в отпуск к родне в Египет и благополучно застряла там из-за закрытия границ. Ну, сама-то здорова, рабочий ноут с ней — сидит себе на карантине и работает через VPN. Неделю работает, две… На третью неделю VPN перестал подключаться. Саппорт первой линии проверил банальности навроде перезагрузки — не помогло. Вторая линия стала диагностировать: соединение уходит в вечный таймаут на стадии TLS Handshake. Отключили локальный фаерволл — не помогло. Попробовали другую машину — не работает. Другого провайдера — не работает. На этом моменте саппорты сдались и радостно спихнули проблему на меня по старому доброму принципу «во всем виноват сетевик».

Всем привет.

Чуть более года назад мне пришлось столкнуться с такой неприятной штукой, как подозрение на заражение бешенством. Прочитанная вчера статья о прививках для путешественников напомнила мне о том случае — в особенности отсутствием в ней упоминаний бешенства, хотя это крайне широко распространенный (особенно в России, Азии, Африке и Америке) и очень коварный вирус. К сожалению, связанным с ним рискам далеко не всегда придается должное значение.

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

Что среднестатистический житель России может навскидку сказать о бешенстве? Ну, есть такая болезнь. В связи с ней чаще всего вспоминают бешеных собак. Старшее поколение скорее всего еще обязательно добавит, что в случае укуса такой собаки придется делать 40 уколов в живот и на несколько месяцев забыть об алкоголе. Вот, пожалуй, и всё.

Давайте разберемся, почему такое отношение к этому заболеванию крайне опасно.

Всем привет.

Я наконец-то изыскал время и написал вторую часть своей истории об IT-эмиграции. Первую часть можно прочитать тут — История переезда системного администратора в Германию. Часть первая: поиск работы и виза. В этой части я опишу подробно, как мы с сестрой обустраивались на новом месте, какие ошибки при этом допускали и сколько нам эти ошибки стоили.

Итак, поехали.

У нас было два загранпаспорта, национальная виза, контракт на работу, договор на учебу и целое множество вещей всех сортов и расцветок, а также лысый кот, длинный список дел, норовящая развалиться машина и несколько тысяч евро. Не то чтобы всё это было так уж необходимо для переезда в Германию, но если уж начал эмигрировать из России, то становится трудно остановиться. Единственное, что вызывало у меня опасение — это жилье. Ничто в мире не бывает более беспомощным, безответственным и порочным, чем поиск квартиры во Франкфурте. Я знал, что рано или поздно мы столкнемся и с этим.

Всем привет!

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

Интернет в Германии — вещь в себе. Никакого Ethernet, и уж тем более PON, в квартиры здесь в 99% случаев не проводится. Оптика хотя бы до подвала — тоже редко встречающаяся роскошь. Рынок тут поделен между провайдерами, предлагающими интернет по разным xDSL технологиям, и операторами кабельного ТВ, раздающим интернет через DOCSIS. Линии, как правило, содержатся в хорошем состоянии, и скорость можно получить вполне сравнимую с «традиционными» способами подключения.

Все это хорошо и вполне достаточно для большинства домашних пользователей, но как только вы хотите подключить свой собственный маршрутизатор — начинаются проблемы. Если вы при этом еще и используете IP-телефонию, VPN и тому подобные вещи, все становится совсем грустно. Что под DSL, что под DOCSIS выбор роутеров здесь крайне ограничен, а при подключении провайдеры выдают самые ширпотребные «мыльницы», многие из которых просто не умеют работать в режиме моста. То есть придется либо дополнительно покупать недешевый модем, либо ставить свой маршрутизатор за NAT, либо вообще отказаться от этой идеи. Промучившись некоторое время в попытках «подружить» свой Juniper SRX100 и провайдерский Fritz!Box 7590, я произвел некоторые изыскания и по очень удачной цене купил на eBay Juniper SRX220H, а к нему MPIM — модуль VDSL2 модема, SRX-MP-1VDSL2-A.


А вот дальше начинаются хитрости.

Всем привет.

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

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

Введение

При достаточно большой и распределенной инфраструктуре, использующей DFS в качестве единой точки доступа к данным и DFSR для репликации данных между ЦОД и серверами филиалов, возникает вопрос мониторинга состояния этой репликации.
Так совпало, что почти сразу после начала использования DFSR, мы начали внедрение Zabbix с целью заменить существующий зоопарк различных инструментов и привести мониторинг инфраструктуры к более информативному, полному и логичному виду. Об использовании Zabbix для наблюдения за репликацией DFS и пойдет речь.

Первым делом, нам нужно определиться, какие данные о репликации DFS нужно получать для контроля за ее состоянием. Наиболее актуальный индикатор — backlog. В него попадают файлы, которые не были синхронизированы с другими членами группы репликации. Посмотреть его размер можно утилитой dfsrdiag, устанавливающейся вместе с ролью DFSR. В нормальном состоянии репликации, размер backlog должен стремиться к нулю. Соответственно, большие значения количества файлов в backlog свидетельствуют о проблемах с репликацией.

Теперь о практической стороне вопроса.

Занимаясь поиском информации на предмет мониторинга упомянутой полки средствами Zabbix, я совершенно случайно наткнулся на интересный пост, датированный 2010 годом. Как там утверждается, в этой полке есть скрытая учетка admin с дефолтным паролем «!admin», которая имеет полные права, аналогичные учетке manage. Я ввел эти учетные данные на странице авторизации веб-интерфейса одной из наших полок, имеющей актуальные обновления прошивки, и успешно зашел с правами manage.

Я фрилансер, и основная моя специализация — решения IP телефонии на основе Asterisk.

На днях ко мне обратился один из моих довольно давних клиентов, у которого в прошлом году я внедрял телефонию для call-центра интернет-магазина. Там я ставил и настраивал только и исключительно Asterisk с сопутствующими пакетами, установкой же собственно сервера и ОС (Ubuntu), как и поддержкой системы после внедрения, занимался местный сисадмин, а ко мне изредка обращались с разовыми нетривиальными задачами, требующими квалификации большей, чем простая правка контекстов в диалплане. В этот раз им потребовалось изменить логику работы CDR в части статистики принятых вызовов по очередям.

Договорившись о стоимости и сроках, я приступил к работе. Каково же было мое удивление, когда после включения логирования незавершенных звонков в CDR пошел поток записей а-ля «UNKNOWN UNKNOWN» со статусом «FAILED»! Причем попытки дозвона были направлены на несколько литовских номеров в коде +370.

Поскольку мысль о подключении извне к самому asterisk была после проверки отброшена сразу (все рекомендации по безопасности были выполнены еще на этапе внедрения, стоял fail2ban, а sip-аккаунты имели жесткое ограничение по ip), и при этом AMI был отключен, то оставался один вариант — call-файлы. Так и оказалось. Уточнил у клиента: они не использовали эту технологию и тем более не звонили в Литву. Мораль? Правильно, банальный взлом.

Для подключения удаленных офисов к корпоративной сети и телефонии при отсутствии проводных провайдеров мы используем LTE от Yota и all-in-one маршрутизаторы DrayTek Vigor 2920VN.

На днях приехал мне на настройку очередной комплект DrayTek 2920 + Yota LU150. Этот модем сам по себе является мини-роутером, и по умолчанию выдает подключенному к нему по USB хосту IP адрес из подсети 10.0.0.0/24, которая в моем случае пересекалась с локальной сетью. В настройках модема по адресу %modemip%/network можно изменить диапазон – на выбор доступны 192.168.0.0/24 и 172.16.0.0/24.

Изменив диапазон на 172.16.0.0/24, я настроил маршрутизатор по стандартной, уже опробованной схеме. И тут – облом: интернет работает, а VPN туннель до центрального офиса не поднимается. К слову, в это время на таком же маршрутизаторе с таким же модемом в одном из удаленных офисов все работает. Чертовщина? Нет, инженеры в чертей не верят!

Я хотел бы рассказать о небольшой доработке системы мониторинга Mikrotik The Dude. Эта система ранее уже упоминалась хабраюзерами gsandul и cedr. Доработку, о которой пойдет речь, я когда-то описывал в своем блоге, но здесь ее сможет увидеть и оценить большее количество народа.

Итак, вкратце: The Dude — довольно мощная и гибкая система мониторинга сетевых устройств, поддерживающая различные типы проверок доступности сервисов и умеющая опрашивать устройства по SNMP. Она поддерживает два типа отправки сообщений о событиях во внешний мир: это e-mail и syslog.

Для оповещения админа по SMS о каких-либо алертах можно пойти традиционным способом — то есть через email-sms шлюз, но в этом случае есть вероятность, что при падении аплинка система до шлюза не достучится и сообщение отправлено не будет. У меня же в наличии были приблудившийся откуда-то 3G модем Huawei E220 от красно-белого оператора, корпоративная симка с условно-безлимитными SMS и собственно сама машина, на которой стояла The Dude — работала она через wine под Ubuntu.