Для лично-рабочих нужд я активно использую task-tracking system под названием Redmine. Redmine практически всем хорош из открытых трекеров, но очень любит память. Традиционно он запускается через rails server (WEBRick) или rails-specific сервер thin. Во второй конфигурации у меня он жрал 300Мб оперативной памяти, а среднее время генерации страницы было близко к секунде, что совершенно неприемлимо. По этой причине я решил использовать uwsgi - совершенно прекрасный appserver, который я активно использую для своего творчества на python. Uwsgi работает очень быстро (действительно - очень!), достаточно экономно относится к памяти, обладает широчайшими возможностями конфигурирования - просто-таки мечта, а не сервер. До недавнего времени он умел работать только с python (под который интерфейс uWSGI, строго говоря, и создавался), но теперь умеет обрабатывать ruby и даже PHP. Минусом uwsgid является, во-первых, тот факт, что он находится на переднем крае разработок, а значит - может работать ой как своеобразно. Не менее своеобразно он настраивается, и документации по нему очень мало.
Неоднократно замечал, что многие мои коллеги (или просто знакомые) часто путают разные варианты модного сейчас набора концепций под собирательным названием “вычислительные облака”. Я решил набросать очень-очень краткий путеводитель по облакам, с примерами и анализом сильных и слабых сторон.
Катастрофическое отсуствие времени в сочетании с любовью к Django и перфекционизмом привело к тому, что я решил отказаться от написания самостоятельного движка блога и перейти на Marcus от Ивана Сагалаева и Михаила Андреева. Движок, конечно, не 100% идеал (а есть ли вообще 100% идеал? Логика подсказывает, что такой невозможен), но близок к прекрасному. В ближайшее время вытащу сюда свои старые статьи и добавлю новых.
В данной статье рассматривается такой инструмент мониторинга, как Munin. Этот инструмент существует под xNIX (Linux, xBSD, Solaris) и Windows и позволяет централизовано отслеживать и наглядно отображать состояние подшефных систем. Изначально используется для отрисовки графиков, но также его можно использовать как чистое средство для наблюдения. Большой плюс Munin - гибкость (все графики рисуются плагинами, активными на целевых системах, и никто не запрещает использовать только те плагины, которые нужны) и возможность с одного сервера собирать информацию о множестве других. Соответственно, нагрузка на наблюдаемом сервере минимальна. Интересно? Добро пожаловать под кат
В свете выхода нового стабильного релиза любимого мною дистрибутива Debian (Squeeze, 6.0) - краткая инструкция по обновлению дистрибутива до нового релиза.
Monit - самостоятельный демон, работающий от пользователя root. Демон работает на Linux, Free/Net/OpenBSD, SUN Solaris и некоторых других UNIX-системах. Это OpenSource проект, у которого есть “старший брат” - коммерческий проект MMonit. Последний обладает более широким функционалом в вопросе массового мониторинга, межсетевого взаимодействия и составления отчетов. Идея авторов проста - для одиночного сервера используем Monit, для большой сетевой фермы - MMonit.
Linux в целом - достаточно защищенная система. При условии сложных паролей и своевременных обновлений (а также - нормального firewall-а) сломать его с целью получения данных достаточно трудно. Однако в случае физического доступа к машине достаточно просто загрузится с другого диска (например, с диска Slax) – и с файловой системой можно делать все, что угодно. Дабы противостоять такой атаке – придумана шифрованая файлсистема. В данной статье пошагово описано создание шифрованой файлсистемы (шифр - AES128) на отдельном разделе диска, авторизация по паролю (keyword). Статья писалась под Xubuntu linux (Debian), хотя в принципе для других версий Linux принципиальных различий не будет.
И снова доброго утречка. В данной статье я рассажу о своем опыте эмуляции Juniper M-серии в домашних условиях и о тех трудностях, которые ждут экспериментаторов. Замечу, что данная статья является творческой компиляцией из этого, этого и вот этого, щедро сдобреного собственным опытом и несколько лишенным воды. Если этой статьи вам мало - добро пожаловать в первоисточники :)
OpenSSHd имеет очень немалое количество механизмов аутентификации, которые в принципе базируются на двух парадигмах - симметричного ключа (пароль) и несимметричного (сертификат). Разница в этих парадигмах довольно незамысловата: в случае использования симметричного ключа копию этого ключа надо хранить на сервере, чтобы при авторизации сравнить хранимое значение со значением, отправленным пользователем. В случае, если значения одинаковы - пароль считается верным и пользователя авторизуют, если значения разные - то нет. Минус пароля в том, что его можно перехватить, после чего пользоваться им без ограничений. Идея сертификата (несимметричного ключа) - более свежая. Она создавалась позже системы на базе пароля и учитывает вышеуказанную уязвимость. Работает эта система на базе двух связанных между собой ключей - открытого и закрытого. Используя открытый ключ, можно зашифровать сообщение, но расшифровать его - нельзя. Расшифровать сообщение можно только закрытым ключом. При этом имея закрытый ключ - можно создать открытый, однако имея открытый - нельзя восстановить закрытый. Кроме того, закрытым ключом можно не только зашифровать, но подписать сообщение - добавить к нему некоторое значение, которое однозначно идентифицирует сообщение. Подписаное сообщение нельзя изменить, при изменении подпись нарушается. При этом, имея открытый ключ можно совершенно однозначно идентифицировать, что подписано сообщение было совершенно определенным закрытым ключом. Но восстановить закрытый ключ или подписать открытым ключом сообщение - снова нельзя. Надеюсь, я не слишком сильно усложнил статью этим кратким экскурсом в практическую криптографию :) Итак, поехали, только практика и ничего кроме практики