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

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

Говорят, что современные аппаратные технологии поддержки виртуализации (VT-d у Intel, IOMMU у AMD) позволяют отдавать физическое устройство на шине PCI в непосредственное управление виртуальной машине. В том числе видеокарту.
Воображение рисует такую конфигурацию: настольный сервер с гипервизором, на нем запускается гостевая пользовательская операционная система, имеющая доступ к необходимым устройствам ввода-вывода, один-два неприхотливых сервера по мере надобности, ну и сколько надо виртуалок для бесчеловечных экспериментов. Управляем гипервизором через консоль в гостевой ОС либо удаленно, с ноутбука, скажем.
Вдохновленный этой картиной, я решил попробовать, но оказалось, что проброс (passthrough) видеоадаптера — задача не совсем тривиальная. Только месяца через три боданий с железом и чтения форумов удалось получить положительный результат. В качестве гипервизора пробовал VMware и Xen. Получилось только с Xen.

Водитель директору: «Я знаю 15 способов обмануть навигацию».
Директор водителю: «А я знаю 27 способов понизить тебе зарплату».

О повсеместном внедрении ГЛОНАСС можно сказать много хорошего и плохого. В целом, затея отличная: мир достаточно давно использует спутниковые технологии в логистических целях и для снижения постоянных издержек на содержание транспорта. В России все перевернуто с ног на голову: подключение автопарка к системам GPS/ГЛОНАСС мониторинга инициировано сверху и насаждается порой там, где от него особого толка быть не может.

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

Резервное копирование базы данных — это такая штука, которую вечно приходится настраивать для уже работающих проектов прямо на «живых» production-серверах.
Подобная ситуация легко объяснима. В самом начале любой проект еще пуст и там просто нечего копировать. В фазе бурного развития головы немногочисленных разработчиков заняты исключительно прикручиванием фишек и рюшек, а также фиксом критических багов с дедлайном «позавчера». И только когда проект «взлетит», приходит осознание, что главная ценность системы — это накопленная база данных, и её сбой станет катастрофой.
Эта обзорная статья — для тех, чьи проекты уже достигли этой точки, но жареный петух ещё не клюнул.

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

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

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

Но статья, на самом деле, не об этом. Я хочу рассказать про две замечательные команды git, которые я недавно для себя открыл. Это git blame и git bisect

Возможность Berkeley Internet Name Daemon (BIND) хранить зоны DNS в базе mysql не шибко известна и крайне плохо документирована. Документация заморожена на моменте включения отдельного патча DLZ в основную ветку BIND, а это BIND 9.4.* и 2005-2006 годы. Я постараюсь хотя бы частично восполнить этот пробел, выложив под хабракатом рабочие на данный момент инструкции с примерами. Мое описание совершенно не претендует на полноту, но простейшую зону прописать позволит.
Отдельно хочу заметить, что DLZ поддерживает не только mysql, список поддерживаемых хранилищ также под хабракатом.

Подключение PayPal Standard Checkout

В данном руководстве последовательно описан мой опыт внедрения PayPal Standard Checkout с использованием языка Java на платформе Google App Engine. Данная статья рассчитана на людей уже имеющих опыт работы с облачной платформой GAE.

Задача

Потребовалось мне интегрировать платёжную систему PayPal на сайт собственного проекта который будет предоставлять сервис по подписке. Начав работу с PayPal Express Checkout API через некоторое время пришло осознание того что система приёма платежа становится слишком громоздкой, в то время как у готовых кнопок Standard Checkout отсутствует необходимая гибкость, которая требуется в случае интеграции сайта с другими платёжными системами.
Выход был найден в использовании инструментов Standard Checkout которые предоставляет PayPal разработчикам сторонних “корзин” для сайта.

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

Как обнаружить, что база данных повреждена

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

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xfdff74c9; actual: 0xfdff74cb). It occurred during a read of page (1:69965) in database ID 13 at offset 0x0000002229a000 in file 'D:\Develop\Databases\Broken1.mdf'.

Attempt to fetch logical page 1:69965 in database 13 failed. It belongs to allocation unit 72057594049069056 not to 281474980642816.

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

Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.

Как-то давно я уже писал об этом, но немного скудно и сумбурно. После я решил расширить список инструментов в обзоре, добавить статье структуры, учесть критику (большое спасибо Lefty за советы) и отправил ее на конкурс на СекЛаб (и опубликовал ссылку, но по всем понятным причинам ее никто не увидел). Конкурс закончен, результаты объявили и я с чистой совестью могу ее (статью) опубликовать на Хабре.

Бесплатные инструменты пентестера веб-приложений

В данной статье я расскажу о наиболее популярных инструментах для пентестинга (тестов на проникновение) веб-приложений по стратегии «черного ящика».
Для этого мы рассмотрим утилиты, которые помогут в данном виде тестирования. Рассмотрим следующие категории продуктов:

1. Сетевые сканеры
2. Сканеры брешей в веб-скриптах
3. Эксплойтинг
4. Автомазация инъекций
5. Дебаггеры (снифферы, локальные прокси и т.п.)

Компания Google опубликовала ряд рекомендаций, как уменьшить задержку (latency) для TCP-соединений между веб-сервером и браузером. В этих рекомендациях обобщаются исследования, которые компания вела в течение нескольких лет.

1. Увеличьте первоначальный размер congestion window до 10 (IW10). Сейчас в начале TCP-соединения отправляется три пакета данных в три раунда (RTT) для передачи небольшой информации (15 КБ). Наши эксперименты показывают, что IW10 уменьшает сетевую задержку для веб-соединений более чем на 10%.

2. Уменьшите первоначальный таймаут с 3 секунд до 1 секунды. RTT в 3 секунды был приемлем пару десятилетий назад, но в современном интернете нужен гораздо меньший таймаут. Наше обоснование для этого хорошо задокументировано здесь.

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

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

А если вам просто понравилась девушка с картинки, то здесь хайрез :)

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

Огромнейшая проблема XenServer, как и Xen Cloud Platform, в очень ограниченном количестве документации. Точнее сказать — в полном её отсутствии для нестандартных ситуаций. В частности нигде в официальных источниках мне не удалось найти инструкции по пробросу блочного устройства непосредственно в виртуальную машину.

Для начала зачем это может понадобиться. Простейший пример — у вас есть сервер без надёжного аппаратного RAID контроллера. Но вы хотите рейд. Без проблем — Linux (и XenServer) содержит великолепнейшую штуку — mdadm. А нужен вам этот RAID для файлопомойки, причём файлопомойка займёт всё доступное место. Смысла городить RAID, а поверх него ещё делать XenServer StorageRepository (SR) с type=lvm, в котором создавать один-единственный диск на весь объём нет. Гораздо лучше создать RAID, и пробросить его блочное устройство непосредственно в виртуальную машину. Так и надёжней — в случае чего вы всегда сможете достать жёсткие диски из сервера и воткнуть их в любую Linux машину, которая тут же увидит все ваши данные.

В качестве стандартного syslog-сервиса в Debian используется rsyslog. Дальше рассказывается, как отправлять копии журналов на сервер, сохранять их в SQL-базе и просматривать через удобный Веб-интерфейс.

Тематику cisco на хабре нельзя назвать популярной, зачастую интересные статьи остаются почти незамеченными. Но нас приятно удивил ажиотаж вокруг нашей предыдущей публикации. Больше тысячи человек добавили её в избранное, и это определённо говорит о том, что продолжение необходимо.
Кроме того, много людей, имеющих опыт реального планирования и строительства сетей, делали очень правильные замечания по резервированию. Дело в том, что предложенная в прошлый раз схема сети — это макет, лаборатория, на который мы будем отрабатывать и понимать технологии, поэтому такими вещами мы не озадачивались. В реальной же жизни, особенно, если вы оператор связи/провайдер, необходимы различные схемы резервирования: VRRP, STP, Link Aggregation, протоколы динамической маршрутизации.
Все замечания мы постараемся учесть и в конце цикла, вероятно, рассмотрим то, как сеть должна строиться, чтобы через полгода после запуска инженеру не было мучительно больно.

Сегодня же мы обратимся к части немного скучной, но важной для начинающих: как подключиться, поставить или сбросить пароль, войти по telnet. Также рассмотрим существующие программы — эмуляторы ciscо и интерфейс оборудования.
Как и обещали, в этот раз всё по-взрослому: с видео.

Под катом то же в текстовой и чуть более подробной форме.
Итак, вот они приехали — заветные коробки с надписью Cisco на борту.

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN'ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Введение

Эта статья – скорее из разряда «для самых маленьких», чем «для умудренных опытом», но она призвана повышать профессиональную культуру системных администраторов.
В силу специфики работы мне «по наследству» достается самый разнообразный облачный ад, который приходится разгребать, оптимизировать, приводить в чувство и делать прозрачным и красивым. Эти заметки, пожалуй, иллюстрация к тем моментам, которые вообще недопустимы в системном администрировании.
В причинах, которыми порождаются эти анти-паттерны, можно разбираться очень долго: дедлайны, законы и темпы бизнеса, да и просто идиотизм, наконец. Но цель статьи другая. Мне бы хотелось породить конструктивную дискуссию. А вот уже её результаты и являются основной целью статьи.

Введение

Недавно я описывал созданную мной систему мониторинга транзитного VoIP методом прогнозирования. Самым сильным плюсом данного метода в задаче мониторинга транзитного VoIP является то, что нет необходимости выставлять критерии того, что считать нормальной работой величин, находящихся под мониторингом, а что – потенциальным сбоем.
Ядром системы является rrdtool, в котором реализованы прогнозирование методом Хольта-Винтерса и механизм выявления аберраций.
Мониторинг методом прогнозирования можно использовать не только для VoIP, но и для любого другого типа трафика, а так же, для величин, которые изменяются во времени с некой прогнозируемой цикличностью. В отличие от стандартных методов, при мониторинге с помощью прогнозирования не осуществляет мониторинг состояния величин, находящихся под мониторингом, зато осуществляется мониторинг динамики изменения их состояний во времени.
Если вам интересна математика прогнозирования рекомендую прочесть. Чтобы быть хоть немного в курсе темы, прочтите главу “Метод прогнозирования реализованный в rrdtool” моего предыдущего поста.

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

Вводная: веб-сайт, у которого не экранируется один из параметров в простом SELECT запросе. При этом все ошибки перехватываются, обрабатываются и выводится скромное «Нет данных» или «Произошла ошибка».

Казалось бы: не велика беда. Обновление или изменение данных в него втереть, данные наружу не открываются, все сводится к «Извините, нет данных» — черный ящик.

Но, что на самом деле можно сделать в данной ситуации?

В первой своей статье «измерение расстояния до объекта и его скорости» я рассмотрел захват изображений с веб-камер через Video4Linux2 и через DirectX. В следующей статье «захват видео с сетевых камер, часть 1» я рассмотрел как работать с сетевыми Motion-JPEG камерами. Сейчас я поведаю Вам о захвате изображений с сетевых RTSP камер, в частности поток Motion-JPEG по RTSP.

Задача эта более сложная нежели Motion-JPEG по HTTP, так как необходимо больше действий, больше подключений, но взамен мы получаем большую гибкость, скорость, функциональность и даже некую универсальность. Честно говоря, RTSP для простых задач избыточен, но я не сомневаюсь, что найдутся ситуации, где он будет необходим.