Один в поле – ИТ-директор!

Время от времени меня приглашают в небольшие компании чтобы «разобраться» с их единственным системным администратором. Список претензий к работе их штатного специалиста всегда примерно одинаков: медленно выполняет поставленные задачи, часто «ничего не работает», а даже был вот такой случай…
При этом зачастую уровень претензий к работе системного администратора никак не коррелирует с его уровнем технической компетенции, а, в основном, связан с отсутствием у системных администраторов минимальных управленческих компетенций, столь необходимых для работы в компании, в которой ты единственный понимающий в ИТ человек.

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

В статье будет рассказано о возможном применении xdebug системными администраторами web-серверов. Может показаться, что администратор не должен заниматься диагностикой и отладкой кода, поскольку это – работа программиста. Это так. Но, как, в случае возникновения проблемы, убедить программиста в том, что его код неоптимален (если это действительно так) и нуждается в переработке, если программист все время заявлет: «У нас все хорошо – чините сервер»? Представим, что это программист, с которым нежелательно спорить. Например, наш очень дорогой и возмущенный клиент.

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

Мне поступила задача организовать отказоустойчивость веб-приложения из двух серверов. Веб-приложение включает в себя статические файлы и данные в СУБД MySQL.
Основное требование заказчика — веб-приложение должно быть всегда доступно и в случае сбоя в течении 5 минут сбой должен быть восстановлен.
2 сервера, территориально разнесенные в разных ЦОДах, должны удовлетворить данное требование.

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

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

Увидев в очередной раз презренный посыл в Google в ответ на вопрос о том, как развернуть собственную LAMP'у, решил написать данный пост. Чтобы хоть как-то разбавить тонны радостных отчётов об успешной установке из блогов, суть которых сводится к одной команде aptitude install blah-blah.

Нет, ну конечно понятно, PHP самый надёжный язык, а все движки сайтов, на нём написанные, являются живым воплощением непробиваемой защиты от взлома. Тогда да — aptitude install apache2 — и будет вам счастье. Не забудьте оставить phpmyadmin по дефолтному адресу, да поставьте какое-нибудь дырявое FTP решето.

Вообще, как оказалось, многие даже не в курсе, что взломав сайт и получив возможность исполнять свой PHP код, злоумышленник на системе с дефотными настройками сможет как минимум прочитать в вашей системе почти что угодно. Оно и понятно — работая с Linux привыкаешь как-то, что по дефолту безопасность находится на вполне достаточном уровне. А тут такая дыра…

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

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

И нет, это не ещё одна статья с описанием установки Linux и выполнением aptitude install apache2. Скорее наоборот: в этой статье я хотел показать фатальную недостаточность данных манипуляций и мягко говоря некомпетентность тех, кто их тиражирует в интернете.

История

Однажды к нам пришли (ну, не сами...) серверы с 14 хардами по 2Тб. Избавившись от аппаратного рейда (зачем — вопрос отдельный), мы задумались о том, что неплохо бы сделать для них загрузку по сети, дабы избавиться от возни с разделами. Диски предполагалось экспортировать по iSCSI, и не хотелось выделять какие-то диски на Особенные Системные Диски, а какие-то на всё остальное. Таким образом возникла задача сделать загрузку по сети с размещением корневого каталога в оперативной памяти.

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

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

CMake — кроcсплатформенная утилита для автоматической сборки программы из исходного кода. При этом сама CMake непосредственно сборкой не занимается, а представляет из себя front-end. В качестве back-end`a могут выступать различные версии make и Ninja. Так же CMake позволяет создавать проекты для CodeBlocks, Eclipse, KDevelop3, MS VC++ и Xcode. Стоит отметить, что большинство проектов создаются не нативных, а всё с теми же back-end`ами.

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

Я постоянно дёргал их, снова и снова расспрашивал о всяких мелочах, а потом эти мелочи благополучно забывал. В конце концов, я задал им вопрос — а нет ли какого-нибудь обзорного документа, уткнувшись в который я бы избавил ребят от своего назойливого внимания? Не получив утвердительного ответа я решил написать эту статью, которая по завершению была вычитана Эдэмом Джексоном и Дэвидом Эйрли. Они оба работают над этим стеком.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

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

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

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

Итак, вуаля!


За источник информации была взята статья из вики. В блок-схеме «UTF-16 → CP 866» означает, что исходная кодировка была «UTF-16», а распозналась она как «CP 866».

Как всегда — кликабельно. Исходник в .docx: здесь.

Автор: Кирилл Корняков, лидер команды разработчиков в Itseez.

Привет, Хабр!



Этой записью мы открываем блог компании Itseez (от англ. it sees — «оно видит!»). Компания основана адептами компьютерного зрения, проработавшими в этой области более 13 лет, среди которых есть участники проекта OpenCV с первого дня его существования. Наша стратегия связана с разработкой технологий и продуктов в области компьютерного зрения под девизом ”Vision that works!”. Наши клиенты — Willow Garage, NVidia, Intel, Microsoft, несколько менее известных компаний и стартапов. На сегодняшний день коллектив Itseez — это команда из 40 инженеров и исследователей, многие сотрудники активно участвуют в образовательной деятельности: преподают в университете, публикуются в журналах и выступают на конференциях, а также проводят школы по компьютерному зрению.

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

Поскольку это первая запись в нашем блоге, хотелось бы поделиться чем-то интересным, поэтому мы расскажем о ключевом проекте компании — о разработке библиотеки алгоритмов компьютерного зрения OpenCV (о своем вкладе в ROS (Robot Operating System) и PCL (Point Cloud Library) мы пока умолчим). Подготовленный читатель, вероятно, удивится, задавшись вопросом: “Но ведь OpenCV разрабатывается Intel / Willow Garage!”, и будет прав, но лишь отчасти. Действительно, далеко не все знают, что большинство ведущих разработчиков OpenCV живут и трудятся в России, в городе Нижний Новгород, и являются сотрудниками компании Itseez. Поэтому, чтобы устранить недоразумения, первый пост мы решили посвятить краткому изложению истории OpenCV. Также, пользуясь случаем, в заключении мы поделимся некоторой инсайдерской информацией о будущем проекта.

Привет, уважаемый хабраюзер!

Все разработчики программ рано или поздно сталкиваются с проблемой падения программы у пользователя. Но далеко не все при этом могут получить доступ к конкретному компу, на котором что-то идёт не так, запустить там gdb и повторить падение. И даже получить информацию от пользователя бывает крайне сложно: в багтрекер (или техподдержку) приходит сообщение а-ля «программа падает, что делать?», а вот технической информации, так важной для разработчика, пользователь не прилагает к своему сообщению. Да ещё и не каждый напишет об этом! Просто перестанет пользоваться программой — и всё.

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

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

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

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

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

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

Сформулируем задачу: получить параметры, полностью характеризующие контур фигуры, изображенной на картинке.

Некоторое время назад меня попросили настроить в удаленном филиале простейшую балансировку трафика. Работают они, бедолаги, через ADSL, и отправка электронных писем большого объема (сканы документов) забивает им весь обратный канал, что приводит к проблемам в работе с офисными онлайн-программами через VPN.
В качестве шлюза у них используется Linux (Fedora). До этого я пару раз видел, как подобная балансировка настраивается через ipfw на FreeBSD, а так как знаю механизм iptables достаточно хорошо, не ожидал особых проблем. Но поискав в Интернете, я был неприятно удивлен тем, что iptables мне тут совсем не помощник. И знания о порядке прохождения пакетов через его таблицы и правила мне почти не пригодятся. Нужно изучать tc из пакета iproute2.

Неожиданно для себя, я потратил два дня, для того чтобы более-менее разобраться в балансировке трафика средствами iproute2. Сначала попалась не самая лучшая для новичка статья про HTB(здесь). Различные примеры из Интернет тоже порой вводили в ступор, так как в них часто не было описания конкретных опций или смысла их применения. Поэтому я и попытался собрать полученные мною знания в одну статью, а главное описать все на доступном для новичков уровне.

Уже более полугода я пользуюсь текстовым процессором Lyx. Встроенных шаблонов с лихвой хватало, чтобы писать конспекты лекций, готовиться к семинарам и делать несложные отчеты к лабораторным работам. Но в прошлом семестре пришлось делать два курсовых проекта в соответствии с требования ЕСКД. Я начал работу в Lyx, но без специальных шаблонов документов, мои отчеты в редакторе выглядели так: