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

Как ранее сообщалось на GeekTimes, EFF при поддержке Mozilla, Cisco, Akamai, IdenTrust и исследователей из Мичиганского университета (University of Michigan) создали новый некоммерческий центр сертификации (Certificate Authority) Let's Encrypt [1]. Целью проекта является ускорение перехода всемирной паутины от HTTP к HTTPS.

Думаю что нет *nix-админа, который не пользуется утилитой logrotate. Часто мы пользуемся ею, даже не подозревая что она установлена в системе. Однако, когда мне понадобилось пропарсить проротейченный log-файл, я был крайне удивлен.

Небольшое резюме: статья про успешное внедрение Zabbix с автоматизацией большинства процессов, не претендует на tutorial, но если нужны будут подробности, то могу предоставить.

Помни: сила рыцаря-джедая — это сила Вселенной.
Но помни: гнев, страх — это всё ведет на темную сторону Силы.
Как только ты сделаешь первый шаг по темному пути,
ты уже не сможешь с него свернуть…

Добрый день, уважаемый галактический сенат! На связи снова Денис Мельский, и сегодня на повестке дня — определение теоретического минимума познания *nix систем для юного падавана web-мастерства.

Хотелось бы начать с того, что все мы прекрасно знаем: на 67.4 % наши любимые интернеты крутятся на *nix-based-серверах, а в жизни среднестатистического web-разработчика в вакууме — так и на все 90 %.



Для любителей пруфов — welcome.

Т. ч. в нашем ремесле без знания *nix-систем никак. Давайте проведем экскурс в мир *nix и поймем, какими знаниями должен обладать юный падаван.

Предлагаю рассмотреть три юниорских степени познания дзена управлением шайтан-машиной ака *nix-сервак на примере всеми любимой ubuntu.

В предыдущей моей публикации про сканер уязвимостей rkhunter в комментариях хабрапользователем Indexator был упомянут сканер chrootkit. При схожем функционале c rkhunter, есть ряд отличий, который будет интересно рассмотреть в этой статье. Интересно также то, что совсем недавно была выпущена новая версия сканера, разработка которого казалась замороженной c 2009 года.

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

Сегодня я решил опубликовать свои шпаргалки, на самые часто встречающиеся ошибки при работе с MySQL.

На хабре не раз было упомянуто приложение под названием rkhunter. Хотелось бы остановиться на нем по подробней.

Rkhunter — это сканер различных видов локальных (потенциальных) уязвимостей (бэкдоров, эксплоитов и руткитов) со своей регулярно обновляемой базой.
Он написан на bash и perl, поэтому будет работать под любой серверной ОС на базе unix без каких-либо проблем.

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

Инструменты, традиционно используемые для прослушивания трафика (tshark, о котором мы уже писали, а также ngrep и tcpdump) для этой цели подходят плохо: функциональность для работы с протоколом HTTP у них ограничена.

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

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

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?

Вводная информация

14 октября 2014 года в протоколе шифрования SSL версии 3 была выявлена уязвимость. Эта уязвимость, названная POODLE (Padding Oracle On Downgraded Legacy Encryption), позволяет злоумышленнику читать информацию, зашифрованную этой версией протокола, используя атаку man-in-the-middle.
Также SSLv3 является очень старой версией протокола, но тем не менее многие приложения поддерживают его и используют SSLv3 в случаях, когда недоступны другие более новые и лучшие варианты шифрования. Что важно, злоумышленник может нарочно требовать использования только SSLv3 на обоих сторонах соединения.
Уязвимости POODLE подвержены любые сервисы или клиенты, которые могут соединяться, используя SSLv3.
Более подробная информация по этой уязвимости опубликована здесь CVE-2014-3566.

Вслед за уязвимостью в XML-RPC, недавно компанией Sektion Eins была найдена уязвимость, которой подвержены все версии 7 ветки. Она позволяет выполнить произвольный SQL-запрос в БД друпала не имея никаких прав в системе. Опасность определена как наивысшая. 15 октября вышло обновление ядра до версии 7.32, которое устраняет эту уязвимость. Разработчики настоятельно советуют обновить ядро немедленно. Обновление не займёт много времени, необходимо обновить только файл /includes/database/database.inc. Спасти сайты до обновления может только блокировка сайта, maintenance mode не поможет.

Все было готово к запуску нового проекта, осталась одна проблема – письма подтверждения регистрации Gmail отправлял в спам. Ознакомившись со справкой сервиса Gmail, я понял, что основной проблемой является отсутствие реализации DKIM на сервере. В моем случае, отправкой писем занимался Exim. Необходимо было реализовать связку Exim+DKIM. Увы, из-за смены утилиты реализации DKIM на FreeBSD все инструкции устарели. Мне пришлось вслепую настраивать Exim+DKIM несколько дней. В этой статье я опишу все этапы реализации Exim+DKIM.

Как часто бывает, зацепив одну, на первый взгляд, маленькую тему, с желанием быстро все узнать и все настроить, приходится закапываться в дремучие дебри и читать не одну статью и/или мануал. Так и получилось у меня в этот раз. Изначально было желание просто узнать, как обновлять порты (или исходные тексты портов) чтоб при желании, устанавливать не устаревшее ПО, но пришлось закопаться немного по глубже.
Эта статья предназначена только для новичков во FreeBSD, опытные профи тут вообще ни чего нового, думаю, для себя не найдут. По этому, если вы на «ты» с этой системой, можете смело пропускать дальнейший текст.
Информации на эту тему хватает, но из 6-10 заметок и статей я взял, так скажем, лучшие наработки и опыт, и записал их в одну, с ссылками на более полные статьи, так что при желании можно получить более подробную информацию по каждому пункту.
Содержание статьи:
1) Выбор ПО для обновления исходных текстов.
2) Процесс обновления исходных текстов системы и портов.
3) Обновление системы(ядро и мир).
4) Обновление портов при помощи pkg_*, portupgrade, portdowngrade.
5) Заключение
6) Дополнительная литература.

Поиск оптимального маршрута юнита к цели на неизвестной карте — одна из самых сложных задач при разработке игры. К счастью, существует некоторое количество алгоритмов, которые решают эту задачу. Есть и отличная библиотека PathFinding.js с поддержкой 11 таких алгоритмов.

Приветствую Вас, жители Хабра.

Недавно на работе возникла ситуация: необходимо было поднять новый почтовый сервер и перенести на него все текущие учетные записи и структуру их почтовых папок со старого сервера. Эта необходимость возникла по нескольким причинам:

1. Количество учетных записей было ограничено 250 аккаунтами;
2. В последнее время сервер почты стал постоянно зависать так, что помогал только хард-ресет (в свое время подметил, что перед этим довольно-таки упорно используется HDD);

Вот что было на тот момент (на платформе SuperMicro):

• PC: CPU Intel® Xeon® X3440 2.53GHz 2.53GHz, RAM 4GB, HDD 1TB
• OS: Windows Server 2008 Enterprise Service Pack 2
• MTA: Alt-N MDaemon (SMTP(S)/POP(S)/IMAP(S) server, SpamD, WorldClient)

Использовалось около 240 учетных записей и папка Users (здесь вся почта) весила около 200 GB.

Что получилось (платформа Dell PowerEdge 2850)

• PC: CPUx2 Intel® Xeon® E5430 2.66GHz 2.67GHz, RAM 4GB, HDD 408GB (RAID: 0)
• OS: FreeBSD 9.0
• MTA: Exim+DoveCot+SpamAssassin

Ну а теперь все по порядку.

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

1. Серые списки (Greylisting)
2. DNSBL
3. Чёрные списки
4. Spamassassin
5. DKIM

Как использовать все эти средства для наиболее эффективного решения проблемы нежелательной корреспонденции?

Что такое DKIM и как оно работает

DKIM (расшифровывается как DomainKeys Identified Mail) — метод идентификации письма по доменным ключам.
DKIM настраивается на почтовом сервере для того, чтобы подписывать исходящие письма цифровой подписью. Наличие такой подписи в заголовке отправленного письма сообщает серверу-получателю, что оно действительно было отправлено с указанного домена.
Известно, что в СПАМ-письмах часто в поле From: ставят е-mail, не имеющий совершенно никакого отношения к отправителю. В этом случае DKIM поможет распознать реальное письмо от спама. В отличие от других методов цифровой подписи письма, DKIM совместим с существующими форматами и протоколами и может быть плавно интегрирован в имеющиеся системы доставки и получения почты.

Подпись письма происходит на SMTP-сервере с помощью секретного ключа (Private key), а расшифровка подписи происходит на сервере-получателе или клиентской программе с помощью публичного ключа (Public key). Что интересно, публичный ключ хранится в DNS, что позволяет убить сразу двух зайцев. Во-первых, нет необходимости прикладывать Public key с каждым письмом для его расшифровки. А во-вторых, в таком случае DKIM позволяет сообщать серверам-получателям что делать с письмом, которое не имеет цифровой подписи, но якобы отправлено от вас. Эта технология называется ADSP (Author Domain Signing Practices). ADSP также хранится в DNS SMTP-сервера и доступен всем и отовсюду.

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

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

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

Мы, наконец, это сделали! Долгое время позорное наследие CP1251 раздражало разработчиков, наводило на мысли о том, что, как же так? Эпоха Unicode уже давно наступила, а мы все еще используем однобайтовую кодировку и расставляем в разных местах костыли для совместимости с внешними системами. Но причина тому была достаточно рациональная: перевести на Unicode большой проект, в который развился Мой Мир, очень трудоемко. Мы оценивали это в полгода и не были готовы тратить столько ресурсов на фичу, которая не принесет русскоязычной аудитории существенной пользы.

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

Разумеется, первое, что было необходимо для интернационализации проекта, это начать принимать, передавать, обрабатывать и хранить данные в UTF-8. Процедура эта для большого проекта непростая и длительная, по пути нам пришлось решить несколько достаточно интересных задач, про которые мы постараемся рассказать.