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

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


Выбор пал на https://account.nt-vps.ru/register/ из-за низких цен и неплохой стабильности за эти деньги(правда 2 дня были серьезные проблемы с сетью). Был взят VPS за 5 рублей в сутки(или за 150р в месяц) с небольшими конфигурациями ОЗУ 128mb и 10Гб на диске.

В автоматическом режиме был установлен Debian 7.0 x86-64 Wheezy и VPS была готова к работе.
64 битная сиcтема была выбрана лишь для моих личных нужд, а вам же советую, на этом VPS, ставить x86.

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

Рассмотрим подробно, как защищены современные валюты, как происходит проверка подлинности (валидация) и что за аппаратура для этого применяется.

В народе есть замечательная крылатая фраза «Сапожник без сапог». Она в полной мере описывает ситуацию, в которой оказываются ИТ-отделы организаций и обслуживающие компании. Люди, которые помогают другим пользователям решать проблемы с техникой, исправлять ошибки в программах, восстанавливать работоспособность программ и оборудования, пытаются навести порядок и привить культуру работы с оборудованием и программным обеспечением, сами не могут навести порядок у себя! О чем пойдет речь? О наболевшем… Учет оборудования и все, что с этим связано. Думаю Вам будет интересно услышать о том, как мы сделали систему учета предназначенную для ИТ-отделов, все таки хабр одно из крупнейших в России IT-сообществ.

Вопрос SMS уведомлений в zabbix уже освещался на Хабре и проблема решалась с использованием СМС-шлюзов. Также упоминали про Отправку SMS c помощью Delphi. Я же хочу рассказать, как настроить SMS уведомления используя USB модем.
Итак, что имеем:

1) довольно обширная ИТ-инфраструктура

2) система мониторинга Zabbix 2.0.3 (актуальная версия на момент написания статьи) функционирующая под Fedora 14 x64

3) 3G USB модем ZTE MF100 от национального украинского оператора Киевстар.



4) Prepaid симка, которая шла в комплекте с модемом.

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

И снова здравствуйте! После перерыва в месяц продолжаем экскурсию по форматам изображений и алгоритмам сжатия. Где мы остановились? Ах, да, восьмидесятые годы.

Очередной пост для блога, посвященного работе над игрушечной ОС. В прошлый раз я писал про необходимость в простеньком драйвере AHCI (SATA). Прежде чем начать двигаться в этом направлении, я решил набросать инфраструктуру драйверов: общий интерфейс драйвера + уточнённый интерфейс драйвера устройства хранения. Формулирование этих интерфейсов выявило проблему, на которую я ранее не обращал внимания — проблему портируемости.

Не зависящий от платформы код (например, большая часть планировщика, вспомогательный код типа kprintf, ...) у меня перемешивается с кодом, заточенным только под x86_64 (системные таблицы дескрипторов, APIC, прерывания, ...). Хотя ничего не мешало мне сформулировать интерфейс драйвера, жёстко привязанного к x86_64 (в частности, свободно оперировать PCI-адресами), мне стало ясно, что без чёткого отделения кода, специфичного для конкретной платформы, от общего портируемого кода я буду лишь усугублять ситуацию. Итак, я принял решение перебрать всё написанное, отделив общий код (в корне src/) от кода, специфичного для платформы (в src/x86_64/). Этим я и занимался последние две недели.

Термин «игровая механика» имеет много значений, но сегодня я буду говорить об игровой механике как об абстракции, определяющей состояние игры. Очень упрощённо это выглядит вот так:



Есть только два фактора, которые определяют любое текущее состояние игры: механика (правила) и игроки своими действиями.

Уровень ядра

Такт 1: определение состояния
Всегда есть некое текущее состояние системы (например, начало хода). Оно определяется на первом такте инициализирующей последовательностью, когда игроки «загружают» игру, раскладывая поле, выбирая фишки, распределяя начальные ресурсы и так далее. Затем оно меняется в зависимости от происходящего в игре.

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

Немного предыстории

В студенческие годы я подрабатывал внештатным переводчиком в одном из бюро переводов Москвы. Занимался я в основном переводами по тематике своего образования, то есть переводил всё, что было связано с отраслью связи и телекоммуникациями. Платили по рыночным меркам мало, но как студента меня это тогда вполне устраивало.
Вся работа бюро переводов сводилась к тому, чтобы набрать заказов как можно больше, а затем распределить это между несколькими переводчиками. По сути некий вид краудсорсинга получался. Основным объектом лингвистических издевательств становилась документация на программное обеспечение или оборудование. Самыми яркими примерами в моей памяти остались перевод документации на SDH/PDH оборудование Huawei и перевод документации на платформу Comverse. Сотрудников компаний-заказчиков мне искренне жалко, и сейчас я расскажу, почему.

Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

Эта статья по сути будет подборкой «Best practiсe» для системных администраторов Samba. Основой статьи является глава Troubleshooting Techniques из книги Sam’s Teach Yourself Samba in 24 Hours. Мы постараемся рассмотреть наиболее распространенные ошибки при настройке Samba.

Согласитесь, ужасно поменять двигатель в машине, а потом выяснить, что не ехала она из-за отсутствия бензина! Может, это и не лучшая метафора, но многие системные администраторы тратят время зря, не проверив в первую очередь самые очевидные вещи. Посмотрите, как примерно должен выстраиваться процесс поиска и решения проблем с Samba:

Большинство статей в наш блог пишут разработчики. Мы решили исправить эту несправедливость и добавить немного DevOps. Сегодня поговорим о важном ― о бэкапах.
Так как Badoo активно развивается и количество сотрудников постоянно увеличивается, мы пришли к выводу, что централизованное резервное копирование гораздо удобнее, чем частичное копирование и хранение информации в различных местах.
В статье мы рассмотрим, как различными способами «забэкапить» довольно большое количество рабочих станций с помощью одного хранилища, не прибегая к серьёзным вложениям и избегая громоздкой реализации.
Заранее оговоримся, что бэкап не охватывает 100% сотрудников, так как не все хранят свои данные на локальных машинах, поэтому у нас не было цели сделать бэкап обязательно-принудительным.
Одной из основных сложностей централизованного бэкапа стало то, что сотрудники используют разные операционные системы.

Как же мы смогли собрать всех на одном сервере?

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

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

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

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

На прошлой неделе Яндекс.Диску исполнился год, и за этот год сервисом успели воспользоваться уже больше 8 000 000 пользователей.

А сейчас мы продолжаем рассказывать о том, сколько усилий понадобилось, чтобы всё это стало возможным. Недавно мы писали о том, как и почему команда Яндекс.Диска выбрала WebDAV для синхронизации десктоп-клиентов с сервером и начала работу над прототипом клиента Яндекс.Диска. Сегодня, как и обещали, — о том, как всё работает с серверной стороны.



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

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

Итак, три самые ненавистные вещи для пользователей: изменения, неожиданности, разрыв контекста.

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

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

Изменения

Компьютеры позволяют менять интерфейс (напоминаю, речь про интерфейс для решения задачи) очень быстро и легко. Появление новых функций ставит программиста/разработчика интерфейса/etc перед проблемой логического переупорядочивания элементов. Например, было три функции в top level, теперь их стало семь, давайте разделим их на две логические группы (3 и 4) — всё ок, никакого хаоса.
С точки зрения пользователя: раньше было три логические функции, теперь они куда-то исчезли, на их месте появились два меню, причём одно действие в первом меню, а оставшиеся два во втором. Ад, ужас, погибель, проклятье программисту.

Пользователи LinguaLeo начинают изучать английский язык в Джунглях — хранилище тысяч материалов разного уровня сложности, формата и тематик; шаг за шагом учатся слышать и понимать речь носителей языка и расширять словарный запас. Кому нужна грамматика — идут в Курсы. Словарный запас пополняется не только из Джунглей, при добавлении незнакомых слов в Личный словарь, но и с помощью подготовленных Наборов слов, доступных для индивидуального изучения. В разделе Общение можно вести Диалоги на английском, чтобы практиковать язык с другими пользователями LinguaLeo в режиме real-time, выбирая темы для общения. Общение только на английском!

Для создания Диалогов на английском мы использовали Node.js, DynamoDB (все на AWS). Сейчас поделимся нашим опытом.

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

1. Взаимосвязь процедур обновлений продуктивной системы и процесса ее резервного копирования
2. Тестирование восстановления из резервных копий
3. Взаимодействие бэкап-процесса с элементами сетевой инфраструктуры продуктивной сети
4. Документирование процедуры восстановления после сбоев

Мне, как и многим из вас, работать с bash и стандартными утилитами Linux гораздо удобнее и приятнее, чем с cmd.exe. Однако, к сожалению, порой обстоятельства складываются так, что операционную систему выбирать не приходится. Например, в моём случае корпоративным стандартом является Windows 7. К счастью есть способ сделать жизнь линуксоида в командной строке Windows комфортнее, о нём и пойдет речь ниже.

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

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

Снова прошу прощения за отсутствие перевода словосочетания “computer science”.

Кратко

• Боритесь за закон Парето, следите за тем, чтобы 20% вашего труда давало вам 80% результата;
• Расставляйте приоритеты, ведь минимализм нужен для того, чтобы делать то, что нужно, а не распыляться по мелочам;
• Лучшее — враг хорошего: сначала просто сделайте, потом сделайте правильно, потом сделайте лучше;
• Убивайте в зародыше, не бойтесь начать всё сначала. Чем быстрее ошибётесь, тем быстрее научитесь;
• Повышайте свою ценность. Постоянно думайте о том, чем можно помочь команде, — и развивайтесь в этом направлении;
• Сперва основы. Мыслите последовательно, ориентируясь на лучшие практики мира Computer Science;
• Посмотрите с разных сторон. Простое получается тяжелее, чем сложное, поэтому включайте воображение;
• Синтаксис — основа взаимодействия. Мы пишем код для людей, а не для машин;
• Не запутывайте. Старайтесь проектировать слоями, по мере возможности не зависящими друг от друга;
• Вычищайте оставленное-на-всякий-случай. Минимализм борется с отвлекающим от основного.

Как мы и обещали в анонс-посте, мы открываем цикл статей по виртуализации рабочего пространства.

Тема “модная” на западе, и ее развивают достаточно давно, как технологически (программно), так и с точки зрения аппаратной части. Если вы слышали о таких словах, как “тонкие клиенты”, “виртуализация”, “bring your own device”, “удаленный доступ к данным”, то, скорее всего, вы слышали о какой-либо из частей этого необъятного моря виртуализации рабочих мест.

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

Итак, виртуализация рабочего места. Что она из себя представляет? Прежде чем ответить на данный вопрос, предлагаем вам задуматься вообще о самом термине «рабочее пространство» и такой фразе, как «виртуализация рабочего места».