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

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

Игромеханически это выглядит так:

1. Есть 10 точек: достопримечательности и места ночёвок.
2. На каждой точке добавляется театрально-игровой блок: условно, место подготовлено для мини-представления, актёры что-то вам показывают, вы делаете пару выборов действиями или бездействием.
3. Потом вам достаётся головоломка квестового типа, для решения которой надо побегать, например, пособирать куски плитки по лабиринту пещер или расшифровать координаты и доехать (лучше на лошади) до точки.
4. На выходе вас ждёт второй сюжетный блок, чаще всего — встреча с актёром, который даёт новую информацию, видеопослание или что-то ещё.
5. Плюс «случайные встречи» по дороге, как в классике RPG.

Чтобы превратить целую поездку в спектакль — чуваки сделали очень крутую работу. Особенно офигенные моменты старта следующего переезда, когда звучит что-то вроде: «мы знаем, где они — это пещерный город!» — и вы садитесь в машины, чтобы поехать атаковать чужую базу через 200 километров.

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

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

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

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

Я обожаю программирование – оно творит чудеса. Но о программировании вам известно гораздо больше, чем мне.

Однако чудеса встречаются не только в программировании, но даже в такой затхлой и заскорузлой области, как бухгалтерский учет. Да-да, в ней самой – в бухгалтерии, к которой я испытываю амбивалентные чувства: искреннюю и горячую симпатию (все-таки это моя изначальная профессия) и не менее застарелую и страстную ненависть (я такое про бухгалтерию знаю, что вам и не снилось).

На этот раз сосредоточимся на позитиве. Позвольте мне рассказать об одном чудесном изобретении в области учетной методологии под названием «амортизационный фонд».

Устройство на ATtiny13, управляемое программой из 290 16-разрядных слов, написанной на ассемблере, запоминает коды шести кнопок пульта ДУ и включает/выключает три нагрузки.

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

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

Введение

В данной серии статей я хочу рассмотреть систему сборки дистрибутива buildroot и поделиться опытом её кастомизации. Здесь будет практический опыт создания небольшой ОС с графическим интерфейсом и минимальным функционалом.

Прежде всего, не следует путать систему сборки и дистрибутив. Buildroot может собрать систему из набора пакетов, которые ему предложили. Buildroot построен на make-файлах и поэтому имеет огромные возможности по кастомизации. Заменить пакет на другую версию, добавить свой пакет, поменять правила сборки пакета, кастомизировать файловую систему после установки всех пакетов? Всё это умеет buildroot.

В России buildroot используется, но на мой взгляд мало русскоязычной информации для новичков.

Цель работы — собрать дистрибутив с live-загрузкой, интерфейсом icewm и браузером. Целевая платформа — virtualbox.

Зачем собирать свой дистрибутив? Зачастую нужен ограниченный функционал при ограниченных ресурсах. Ещё чаще в автоматизации нужно создавать прошивки. Приспосабливать дистрибутив общего назначения, вычищая лишние пакеты и превращать его в прошивку путь более трудоёмкий, чем собрать новый дистриб. Использование Gentoo тоже имеет свои ограничения.

Buildroot система очень мощная, но она ничего не сделает за вас. Она может лишь дать возможности и автоматизировать процесс сборки.

Альтернативные системы сборки (yocto, open build system и прочие) не рассматриваются и не сравниваются.

Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?

Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.

В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?

Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?

Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»

Так что изменилось? — Всё изменилось!

Целью данного проекта было:

• Изучение протокола DHCP при работе в сети IPv4
• Изучение Python (немножко более чем с нуля ;) )
• замена серверу DB2DHCP (мой форк), оригинал здесь, который собирать под новую ОС всё труднее и труднее. Да и не нравится, что бинарник, который нет возможности «поменять прям щас»
• получение работоспособного сервера DHCP с возможностью выборки IP адреса абонента по mac абонента или связке mac свича+порт (Option 82)
• написание очередного велосипеда (О! это моё любимое занятие)
• получение люлей про свою косорукость на Хабрахабр (а лучше инвайта) ;)

Результат:  работает ;) Опробовано на ОС FreeBSD и Ubuntu. Теоретически код можно попросить работать под любой ОС, т.к. специфических привязок в коде как будто нет.
Осторожно! Дальше много.

В данной статье пойдёт краткое повествование о том, что нам может рассказать такая привычная с виду вещь как NetBIOS. Какую он может предоставить информацию для потенциального злоумышленника/пентестера.

Если вы когда-нибудь самостоятельно собирали компьютер и покупали лицензию на Windows, вам, вероятно, не захочется покупать ещё одну лицензию для следующего компьютера. Но, используя команду slmgr, можно деактивировать старый ПК и активировать новый.

Деактивируйте старый ПК вместо покупки новой лицензии

Лицензии на Windows стоят дорого. Цена официального ключа от Microsoft, от $100 до $200, может сравниться с ценой терабайтного твердотельного накопителя, 16 Гб RAM или материнской платы. А покупать дешёвые ключи с сомнительных веб-сайтов – это не очень хорошая идея. Поэтому платить за очередную лицензию, когда вы избавляетесь от старого компьютера в пользу нового – не очень интересная идея. Но хорошая новость в том, что можно деактивировать ПК, который вы больше не будете использовать, и перенести лицензию на новый.

Введение

Ещё с юности, когда у нас был старый DeskJet, меня интересовали картриджи струйных принтеров. Эти картриджи казались очень интересными и как только в них заканчивались чернила, я сразу забирал их себе. В то время я не мог сделать с ними ничего, кроме как разобрать и пачкать руки… Хоть я и знал, что там внутри есть какая-то сложная электроника, но при касании контактов батарейкой не происходило ничего интересного, а моих знаний по электронике на большее не хватало.

Чуть позже, когда я стал студентом, мне удалось раздобыть старый струйный принтер. В то время сам я пользовался лазерным принтером, поэтому он мне был не очень интересен, зато было любопытно исследовать картриджи и попытаться выполнить их реверс-инжиниринг. Я в самом деле написал статью об управлении этими картриджами, и хотя они работали достаточно хорошо, были и недостатки: мне так и не удалось выяснить точный порядок сопел, картридж был только монохромным (печатал маджентой), к тому же довольно старым, а потому разрешение оказалось довольно низким.

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

Кратко о ситуации в ВУЗах (личный опыт)

Для начала стоит оговорить, что изложенный материал субъективен, так сказать "взгляд изнутри", но по ощущениям информация актуальна для многих государственных ВУЗов постсоветского пространства.

Ввиду спроса на специалистов ИТ, многие учебные заведение открыли соответствующие направления подготовки. Более того, даже до студентов вовсе не "айтишных" специальностей дошло множество предметов ИТ-ого профиля, зачастую это Python, R, менее везучим многим приходится осваивать "пыльные" учебные языки, вроде Pascal.

Если посмотреть глубже, то все не так просто. Не все преподаватели успевают за "трендами". Лично я, учась на "программистской" специальности столкнулся с тем, что у некоторых преподавателей нет актуальных конспектов лекций. Если говорить точнее, преподаватель скинул старосте на флешку фото конспектов, написанных от руки каким-то студентом. Об актуальности таких материалов как методички по WEB-программированию (2010-ого года) я вовсе молчу. Также остается догадываться, касательно того, что происходит в техникумах и худших из худших учебных заведениях.

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



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

Блоки информации (chunks)

Чтобы свободно пользоваться новыми знаниями, к ним нужно привыкнуть. А привычка, как известно, дело времени. В книге Learning How to Learn (или на замечательном курсе на Coursera) блоки информации называются chunks, и в курсе рассказывается про их формирование. На это уходит время, которое на практике нельзя существенно ускорить.

Сначала мы учим, что такое натуральные числа, потом целые, потом рациональные, потом вещественные. Потом мы изучаем пределы, потом производные, потом интегралы, потом топологию, потом анализ на многообразиях и так далее. Для каждого следующего шага нам необходимо понять предыдущий и воспринимать его как информационную единицу. Когда я говорю «многообразие», для меня — это информационная единица, а для изучающего — это информационный гугол: хаусдорфово топологическое пространство, в котором у каждой точки есть окрестность, гомеоморфная бла бла. Я помню момент, когда впервые смог произнести вслух «тензорное произведение» без внутреннего дискомфорта. Мне потребовалось много времени.

По данным ssh.com и Wikipedia, первая версия и реализация протокола SSH увидела свет в 1995 году. Задачей автора было разработать безопасную альтернативу использовавшимся тогда для удалённого администрирования rlogin, telnet и rsh. Любопытно, что появлению протокола SSH поспособствовал инцидент информационной безопасности, в результате которого злоумышленник собрал внушительную базу логинов/паролей от серверов, просто прослушивая университетскую сеть и выделяя пакеты аутентификации (пары логин/пароль в них передавались в незашифрованном виде).

Протокол быстро завоевал популярность и после длительного периода доработок и улучшений был стандартизован IETF в 2006 году. С тех пор он успел стать де-факто стандартом для удалённого управления системами с текстовой консолью. Помимо собственно текстовой консоли в протоколе предусмотрена масса других полезных функций, таких как передача файлов и переадресация портов. Именно о переадресации портов (port forwarding) и её не слишком очевидном применении пойдёт речь в этой статье.

Иллюстрированная проекция модели сетевого взаимодействия OSI на универсальную последовательную шину.

Три «замечательных» уровня стека USB

Меня не устроил вид стека USB, который можно встретить чаще всего на просторах сети:


Уровень шины, логический, функциональный… Это, конечно, замечательные абстракции, но они скорее для тех, кто собирается делать драйвер или прикладной софт для хоста. На стороне же микроконтроллера я ожидаю шаблонный конечный автомат, в узлы которого мы обычно встраиваем свой полезный код, и он сперва будет по всем законам жанра глючить. Или же глючить будет софт на хосте. Или драйвер. В любом случае кто-то будет глючить. В библиотеках МК тоже с наскока не разобраться. И вот я смотрю на трафик по шине USB анализатором, где происходящие события на незнакомом языке с тремя замечательными уровнями вообще не вяжутся. Интересно, это у меня от гриппозной лихорадки в голове такой диссонанс?

Если у читателя бывали сходные ощущения, предлагаю альтернативное, явившееся мне неожиданно ясно в перегретом мозгу видение стека USB, по мотивам любимой 7-уровневой модели OSI. Я ограничился пятью уровнями:



Я не хочу сказать, что весь софт и библиотеки уже сделаны или должны проектироваться, исходя из этой модели. Из инженерных соображений код c уровнями будет сильно перемешан. Но я хочу помочь тем, кто начинает своё знакомство с шиной USB, кто хочет понять протоколы обмена устройств и терминологию предметной области, подобраться поближе к готовым примерам, библиотекам и лучше ориентироваться в них. Эта модель не для загрузки в МК, но в ваши блестящие умы, дорогие друзья. А ваши золотые руки потом всё сами сделают, я не сомневаюсь:)

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

Всем доброго времени суток!

Уже на следующей неделе у нас стартует очередная группа «Администратор Linux», в связи с чем мы провели ряд мероприятий. Одно из них — открытый урок на тему «SSH/NC/Socat: tips & tricks». На нём мы вспомнили, что такое ssh, его историю и предназначение. Рассмотрели различные варианты его использования: remote, local port forwarding, secure copy, socks proxy, reverse proxy. Попробовали на деле в виртуальной лаборатории утилиты nc и socat.

Вебинар провёл опытный системный администратор Владимир Дроздецкий — разработчик инфраструктуры letundra.com, exposcan.ru, crispmessenger.com.

Предлагаем вашему вниманию подробное описание прошедшего мероприятия.

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

0. Вместо введения

Что это за статья?
Эта статья представляет собой компиляцию информации из различных источников, вольный перевод некоторых частей документации, а также мои собственные комментарии, дополнения и описания возникших проблем.

Для кого эта статья?
В первую очередь, для новичков, каковым являюсь и я. На форумах по embedded Linux очень часто можно встретить вопрос: «А как на этой плате работать с SPI?». Именно на него я и попытаюсь дать ответ. В качестве примера, я приведу код написанный для работы с моим тестовым SPI устройством.

© Яндекс.Картинки

Перечень изменений.

Все специалисты по информационной безопасности рано или поздно сталкиваются с вопросами законодательного регулирования своей деятельности. Первой проблемой при этом обычно является поиск документов, где прописаны те или иные требования. Данный справочник призван помочь в этой беде и содержит подборку ссылок на основные законодательные и нормативно-правовые акты, регламентирующие применение информационных технологий и обеспечение информационной безопасности в Российской Федерации.