Всем привет!

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

На написание статьи меня подтолкнул комментарий к предыдущей статье. Перефразирую удивление пользователя: «Ну как же так? Cервер не пишет писем о том, что он забэкапился!». Причём, со слов аналитиков, он не один такой, иначе бы не появился тред на форуме. А раз люди пишут — значит, это кому нибудь нужно!

В статье я поясню, почему этой функции в продукте нет. Но на этом мы не остановимся, мы эту функцию добавим! Мы ж программисты, так что напишем письмо и сгенерируем отчёт в виде html страницы.


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

Приготовьтесь: много кода, картинок нет.

Всем привет.

Недавние статьи на Хабре Импортозамещение на практике. Часть 1. Варианты и Не долго музыка играла… или как ОС Эльбрус так и не стала свободной не оставили меня равнодушным. Я решил поизучать этот вопрос в ключе задачи резервного копирования. Тем более, что в этой статье продукты Veeam Software упоминаются, а значит, вопрос может быть актуальным именно в ключе импортозамещения.


первоисточник изображения

Первым делом я решил скачать ОС «Эльбрус», а точнее — только доступный дистрибутив для архитектуры x86_64, посмотреть, как он устроен, и попробовать поставить на него Veeam Agent for Linux. Желающих узнать, что из этого получилось, прошу под кат.

Всем привет!

Ооочень хочется прям сразу приступить к теме, но правильнее будет немного рассказать про мою историю:

Вступление

Я программист с опытом разработки frontend одностраничных приложений, scala/java и nodejs на сервере.

Довольно долго (уже точно пару — тройку лет), я придерживался мнения, что docker это манна небесная и вообще очень крутой инструмент и абсолютно каждый разработчик должен уметь пользоваться им. А отсюда вытекает, что и у каждого разработчика должен стоять docker на локальной машине. Да что там про моё мнение, вы полистайте вакансии, которые размещаются на том же hh. В каждой второй есть упоминание про docker и если вы им владеете — это будет вашим конкурентным преимуществом ;)

На своем пути я встечался с многими людьми, с их разным отношением к docker и к его экосистеме. Одни говорили, что это удобная вещь, гарантирующая кроссплатформенность. Вторые не понимали зачем им запускаться в контейнерах и какой профит от этого, третьим было вообще пофиг и они не парились (просто писали код и уходили домой — завидую, кстати, им :) )

В связи с тем, что близится 2020 год и «час хэ», когда нужно будет отчитаться об исполнении приказа Минсвязи о переходе на отечественное ПО (в рамках импортозамещения), мне прилетела задача о разработке плана, собственно, по исполнению приказа Министерства связи и массовых коммуникаций №334 от 29.06.2017. И начал я разбираться. И первое, на что я наткнулся, была статья о том, что «Вертолеты России» уже все сделали и что надо у них опыт перенимать. А все ли так гладко?.. Давайте смотреть.

Не так давно ИТ-директор холдинга «Вертолеты России» Михаил Носов рассказал о том, как они выполняли приказ Министрерства связи об импортозамещении ПО. Показал презентацию с цифрами и выгодами от перехода на отечественный софт… И все бы ничего, но только есть там куча несоответствий…

Как было написано в одной умной книге — если в вашем IT-отделе нет автоматизированной установки операционной системы, то её создание может быть самой важной задачей, которую вы когда-либо выполняли.

Я начинаю цикл статей, посвященных разбору задач сервиса pentesterlab. К сожалению, у меня нет Про-версии курса, поэтому я ограничен только списком свободных задач. Каждый кейс — система, содержащая уязвимость, которой необходимо воспользоваться для достижения определенной цели.

Привет, Хабр! Не так давно возникла довольно типичная ситуация — руководство дало команду «Выбрать систему защиты данных от утечки». Основной критерий выбора — способность решить задачу не допустить утечек критически важной (по мнению руководства) документации, файлов и тому подобного. Как следовало из устного ЦУ руководителя, журналы и разная аналитическая функциональная оснащённость — вторична. Цитируя шефа, «для отлова злоумышленников мы можем и видеокамеры повесить, решайте задачу так, чтоб не разбираться с утечками, а исключить их». Разумеется, все прекрасно понимают, что 100% исключения риска утечек достичь нереально, поэтому — речь о минимизации риска утечки информации.

Вашему вниманию предлагается перевод прощального письма Миода Валлата, разработчика OpenBSD в течение 15+ лет, покинувшего проект неделю назад. Письмо, изначально адресованное лично некоему Джиму, рассказывает историю о том, куда порой приводят благие намерения, и вызвало резонанс среди пользователей Reddit и HackerNews. Учтите — высказанное мнение субъективно, и, по словам самого автора, "вы имеете право с ним не согласиться".

Сегодняшний мир — это amd64 (по-другому x64, или x86-64), armv7 и, в скором будущем, aarch64 (64-битный ARMv8). Всё остальное мертво, Джим. Никто не вкладывает достаточно денег и мыслительного труда в прочие архитектуры. В действительности, лишь небольшая часть людей в курсе существования остальной части экосистемы (mips, power8, ...), и все равно никому нет до них дела.

Поддержка устаревшей платформы на плаву — это весело, поскольку это напоминает тебе о 90-ых, когда существовал большой выбор «железных» платформ, с приблизительно одинаковым соотношением цены/мощности. В конце концов, дешевые PC убили практически всю конкуренцию, а рынок смартфонов дал ARM нездоровую долю рынка в мире встраиваемых систем.

Затем, спустя некоторое время, веселье подходит к концу, поскольку никто не пишет код, держа в уме твою платформу, — ведь она не считается достаточно мощной, а современные компиляторы больше ее не поддерживают (или они генерируют для нее нерабочий код, что на деле еще хуже). У твоей платформы есть аппаратные границы в несколько сотен MB физической памяти? Тебе не удастся запустить на ней веб-браузер или даже программу для просмотра PDF. Кто-нибудь все еще запускает testsuite из последней версии gcc на твоей платформе? Нет? Прости, чувак, но вот тебе «никель» (5 центов), сходи купи себе уже компьютер получше…

Плагинов для систем мониторинга существует огромное количество. Можно посмотреть и найти нужное в каталогах exchange.nagios и monitoringexchange. При поисках нужного плагина проверять лучше в обоих репозиториях — несмотря на кажущуюся идентичность, их содержимое различается.

Другое дело, что качество и функционал плагинов, даже сходных между собой, сильно разнятся — есть быстро слепленные на коленке хаки, работающие в строго определенных условиях и решающих узкую задачу. После написания автор плагина не стал выбрасывать его в /dev/null, а решил поведать о нём миру. Другие плагины представляют собой добротно сделанные продукты, работающие с целыми семействами устройств и предоставляющих обширную информацию о целевых системах.

Вот о последних и хотелось бы поговорить, тем более, что за время работы с nagios/icinga обнаружилось, что русскоязычной информации по плагинам для систем мониторинга крайне мало.

Данная статья посвящена мониторингу серверов HP Proliant, и автор искренне надеется, что она поможет в работе тем, кто имеет оборудование HP, и хотел бы более полно отслеживать его параметры.

Возможно, это странно, но в первые дни на работе после новогодних каникул, когда все упавшее за праздники уже успешно возвращено к жизни, у многих возникает желание как-то упорядочить информацию в своей голове, дабы привести её к систематизированному виду. Хорошим катализатором для этого процесса является осознание факта, что вроде и обладаешь багажом знаний, но бабушке с улицы или шестилетнему ребёнку в простых словах этот багаж ну никак не получится объяснить. Ибо, как гласит народная мудрость, не смог объяснить ребёнку – значит, сам не знаешь. Да и вообще, дефрагментация информации ещё никому не вредила.
Но у нас не курс прикладной психологии, поэтому сегодня я просто изложу в систематизированном виде набора пикселей максимальное количество полезной информации о функции репликации виртуальных машин в среде гипервизора Hyper-V на примере текущей версии Windows Server 2012 R2.

Итак, на что я хочу потратить примерно час вашего времени:

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

Привет, Хабр. Под этим пафосным заголовком я бы хотел поговорить о том, что такое «инженерная наука», в чём состоит главная обязанность инженера и что бывает, если он с ней не справляется — мне кажется, в последнее время эта тема становится всё более актуальной, при этом её публичного обсуждения я не вижу.

Сподвигла меня на это разразившаяся (при моём активном участии) в минувшие выходные история с «нейроинтерфейсами» компании Bitronics Lab — детскими учебными наборами для снятия ЭЭГ и мышечной активности, которые при ближайшем рассмотрении оказались попросту небезопасны в использовании из-за несоблюдения их производителем базовых требований к электробезопасности медицинского оборудования.

История это очень показательна в том, что она демонстрирует, как по мере роста сложности система, составленная из кажущихся её авторам безопасными компонентов, становится опасной — причём на примере системы простой, бытовой и интуитивно понятной, а не атомного реактора или реактивного лайнера, которые любят брать в качестве примеров авторы книг вроде моей любимой "Inviting Disaster".

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

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



Казалось бы, что может пойти не так?

[Прим. переводчика. Материал статьи относится к Windows Server 2003/2003R2/2008/2008R2, но большинство из описанного справедливо и для более поздних версий ОС]

Уоррен снова здесь. Эта статья — краткое справочное руководство о том, как правильно вычислить минимальный размер промежуточной папки, необходимый для нормальной работы DFSR. Задание меньших значений может привести к замедлению репликации или вообще к ее остановке. Имейте в виду, что это лишь минимальные значения. Принимая решение о размере промежуточной папки, помните следующее: чем больше будет размер промежуточной папки, тем лучше, вплоть до размера самой реплицируемой папки. За дополнительными сведениями о том, как важно использовать верный размер промежуточной папки, обратитесь к разделу «Как определить, есть ли у вас проблема с промежуточной папкой» и постам из блогов, ссылки на которые размещены в конце этой статьи.

В статье разбираются популярные мифы и сценарии мошенничества с бесконтактными системами оплаты на примере настоящего POS-терминала, карт PayPass/payWave и телефонов с функцией Google Pay/Apple Pay.

Рассматриваемые темы:

• Можно ли НА САМОМ ДЕЛЕ украсть деньги, прислонившись POS-терминалом к карману? — мы попытаемся полностью воспроизвести этот сценарий мошенничества от начала до конца, с использованием настоящего POS-терминала и платежных карт в реальных условиях.
• В чем разница между физическими и виртуальными картами Apple Pay? — как происходит связывание физической карты и токена Apple Pay, и почему Apple Pay во много раз безопаснее обычной карты.
• Используем аппаратный NFC-сниффер (ISO 14443A) — воспользуемся устройством HydraNFC для перехвата данных между POS-терминалом и картой. Рассмотрим, какие конфиденциальные данные можно извлечь из перехваченного трафика.
• Разбираем протокол EMV — какими данными обменивается карта с POS-терминалом, используемый формат запросов, механизмы защиты от мошенничества и replay-атак.
• Исследуем операции без карты (CNP, MO/TO) — в каких случаях на самом деле(!) можно украсть деньги с карты, имея только реквизиты, считанные бесконтактно, а в каких нельзя.

Внимание!

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

Материалы в статье представлены исключительно в ознакомительных целях. Все сцены демонстрации мошенничества инсценированы и выполнены с согласия участвующих в них лиц. Все списанные деньги с карт были возвращены их владельцам. Воровство денег с карт является уголовным преступлением и преследуется по закону.

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

Ещё в мае 2018 я писал статью с рекомендациями как защитить свой Микротик.

Как ни странно, но в сети до сих пор тысячи «открытых» роутеров Mikrotik и армия ботнета пополняется.

Я в свободное от работы и отдыха время искал уязвимые устройства по всей сети и делал настройки в соответствии со своими рекомендациями, то есть добавлял правила фаервола, которые закрывали доступ к роутеру не из локальной сети. В комментариях писал информацию об уязвимости и оставлял адрес телеграм-канала @router_os, где можно было мне задать интересующие вопросы (у нормального админа они должны были появиться).



С мая по сегодняшний день я «вырвал» из лап ботнета более 100 тысяч устройств Mikrotik.

Учитывая то, что я не могу выступить на MUM 2018 в Москве, то свой доклад я решил опубликовать на habr.com

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

Я проработал в индустрии IT более десяти лет и скажу вам, это была сумасшедшая гонка, наполненная множеством взлетов и падений. Больше вниз, чем вверх, если я буду действительно честен с вами.

Вы, наконец, сдались на милость контейнеров и обнаружили, что они решают массу проблем и имеет массу преимуществ:

1. Контейнеры незыблемы: ОС, библиотеки, папки и приложения – поскольку все это хранится прямо в контейнере, вы на 100 % уверены, что в продакшн всегда пойдет именно тот образ, который тестировался в QA. И работать он при этом будет абсолютно аналогично.
2. Контейнеры легковесны: Контейнер не ест память впустую. Вместо сотен мегабайт и гигабайт контейнеру нужна память лишь под основной процесс.
3. Контейнеры быстрые: Контейнер запускается так же быстро, как и обычный Linux-процесс. Не минуты, а буквально считанные секунд.

Однако, многие до сих пор считают, что контейнеры – это виртуальные машины, и забывают про важнейшее их свойство…

На DevOps есть по крайней мере два устоявшихся взгляда — со стороны системных администраторов и со стороны разработчиков. Первые обычно хвастаются тем, что используют Chef/Puppet/Ansible/Docker c 200X года, вторые считают, что DevOps либо изжил себя и ведет к NoOps, либо что «я завернул всё в контейнер, а дальше как пойдёт».

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

Эта статья — про DevOps как систему. Как он помогает бизнесу, какие компетенции со стороны инженеров должны появиться для DevOps, какие бизнес-задачи можно решать DevOps-методом производства программного обеспечения, а также какие ошибки возможны на пути к DevOps-производству и как их избежать или купировать. Как, в конце концов, инженеру стать Человеком и быть в этом мире творцом, как для этого построить карьерный путь и как начать смотреть на технологии по-человечески.

В основе материала — расшифровка доклада Александра osminog Титова с нашей октябрьской конференции DevOops 2017.

Много копий сломано вокруг управления сетевыми принтерами на пользовательских компьютерах. В основном администраторы разбились на два лагеря: подключение логон-скриптами (bat/vbs) и управление через GPP. У обоих подходов есть свои плюсы: скрипты быстрее обрабатываются, а GPP гибче и применяется чаще, чем пользователи перезагружают компьютеры. Но когда принтеров больше сотни и разбросаны они в нескольких десятках офисов и городов, сложности будут в обоих случаях.

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

В общем, мы с коллегами для себя выбрали GPP, в первую очередь для того, чтобы кто-то кроме ведущих администраторов мог разобраться в действующем конфиге, просто посмотрев отчет GPMC. Однако, кто скажет, что его штатный интерфейс удобен для управления 100+ устройствами — пусть первый бросит в меня камень. Кроме того, при вводе в эксплуатацию очередной партии нужно проделать много рутины по настройке сетевого сканирования и добавлению на сервер печати.

А всё, что делается больше одного раза, можно автоматизировать!

Что мы сегодня будем делать?

• вести учет всех сетевых принтеров;
• автоматизировать добавление принтеров в GPP (PS/XML);
• автоматизировать добавление принтеров на принт-сервер, причем на кластерный (BAT/VBS)!

Итак, начнем.

Однажды вы задумаетесь, как превратить скрипт или приложение в Windows-службу. Скорее всего, задача окажется не такой уж тривиальной – приложению как минимум потребуется специальный интерфейс для получения команд от системы. А раз есть требования и ограничения, то есть и скрипты, и милые сердцу костылики для преодоления.

Статья будет полезна тем, кто, как и я — «программист не настоящий».

Волею судеб есть на моём попечении почтовый сервер. Маленький, ~20 пользователей. Работает стабильно, менять ПО нежелательно. И не нужно бы, но однажды логи бэкапа недвусмысленно намекнули – если продолжать в том же духе, на полный бэкап будет уходить вся ночь. И дело – в объёмах почтовых ящиков пользователей.