За последнее время, наш сайт часто подвергается достаточно мощным DDOS атакам, к слову последняя атака была самой крупной за последнее время, размер ботнета по нашим оценкам — около 10 тысяч машин, мощность — 100 Mbits/s.

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

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

Атака была типа HTTP Flood. Система на которой у нас работает сайт — Apache под Linux. Мы написали несколько скриптов, которые будут приведены в тексте статьи. В принципе аналогичный подход можно применять и для Windows/IIS.

Попытаюсь рассказать, какие основные шаги мы сделали для отражения атаки, и какие проблемы возникали по ходу:

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

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-июнь 2011.

Прочитав много литературы по истории бизнеса и наблюдая рост популярности Интернет-торговли, автору этих строк хотелось реализовать свои знания на практике. Искали подходящую тему для проекта. Необходимыми условиями были:

1) Вложение не более $10 000
2) Прибыль не менее $1 000 в месяц
3) Минимальная рутина

По первым двум пунктам все понятно. А вот по третьему пункту поясню. К тому моменту я уже работал в собственной компании (сфера финансов). Это был 2009 год. Последствия кризиса еще сильно влияли на основной бизнес и работы было непочатый край. Много времени отвлекать на сторонний бизнес автор не мог.
Подходящий случай подвернулся в октябре 2009 года.

Здравствуйте, хабралюди!

Я отношу себя к ленивым фотографам. То есть я не люблю скрупулёзно обрабатывать отснятый материал, но при этом периодически испытываю желание выложить пачечку-другую фотографий в Интернет, желательно быстро.

Для Линукса, которым я пользуюсь практически 100% времени, есть много различных графических инструментов для работы с фото. Но иногда бывает, что нужной функции в используемой программе — нету.
Или она есть, но ты не смог её найти. Что же делать? Конечно же, использовать bash.

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

Всё началось с того, что я наткнулся на видео, которое рассказывало о съёмках одного из моих любимых сериалов, Warehouse 13:
www.aoltv.com/2009/07/10/behind-the-scenes-of-warehouse-13

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

Но, как принято на сайте AOL TV, видео оказалось доступно только жителям US. Зачем накладывать такие ограничения — я не могу взять в толк. Где и какая жаба их душит, непонятно.
Но такая мелочь меня не могла остановить.

Несколько книг по разным темам, которые находятся в открытом доступе.

Основы программирования

• codebetter.com/karlseguin/2008/06/25/foundations-of-programming-ebook
• pine.fm/LearnToProgram
• netlib.bell-labs.com/cm/cs/pearls
• www.faqs.org/docs/artu
• savannah.nongnu.org/projects/pgubook

Несколько недель назад американский телеканал CNBC продемонстрировал фильм из своего документального цикла «Титаны», посвященный главе компании Apple Стиву Джобсу. Эти фильмы рассказывают о жизни выдающихся людей, изменивших мир. И конечно же, этот список был бы неполным, если бы в нем не было создателя Mac, iPod, iPhone, iPad и множества других полезных вещей. Русская озвучка подготовлена сайтом — AppleInsider.ru



Еще 2 части под катом.

Привет, хабралюди! Кто из вас не мечтал создать свою игру? А возможно ли написать браузерную стратегию, не имея при этом опыта и денег? Возможно, если очень этого хотеть.

Под катом моя история создания бесплатной пошаговой стратегии.

Привет хабра-сообществу.

Относительно недавно достаточно давно писал статью про создание очередной казуалки на Flash-платформе с физикой, обещал вторую статью, встречайте.
В этой статье — научу рисовать мир и расскажу о сенсорах. Остальное под катом.

Что можно сделать из этих двух уроков, можно посмотреть тут (музыку отключить нельзя, но можно убрать звук в системе).

Неделю назад координатор известного проекта «РосЯма» объявил об открытии исходников сайта (PHP-скриптов) под BSD-подобной лицензией: «Так как мы не в состоянии отследить все клоны РосЯмы, которые могут возникать, и вообще всё то, что могут придумать наши предприимчивые соотечественники, решили выбрать лицензию посвободнее. Кто угодно может совершенно бесплатно скачать себе исходный код, как угодно его менять, использовать в своих проектах, в том числе коммерческих и закрытых», — сообщил представитель веб-студии Greensight, которая сделала разработку сайта.

Репозиторий на Mercurial находится по адресу hg.rosyama.ru. Клонирование:

hg clone http://hg.rosyama.ru rosyama-local/

Обновление до новой версии — командой hg pull. Поддержка и обновление проекта продолжаются, репозиторий открыт только на pull. Баг-трекер функционирует по адресу trac.rosyama.ru.

Цена разработки «РосЯмы» составляет около 200 000 руб. Учитывая стоимость и общественную важность проекта, переход под Open Source можно только приветствовать, несмотря на все отрицательные моменты.

Abstract: как работает open-iscsi (ISCSI initiator в linux), как его настраивать и чуть-чуть про сам протокол ISCSI.

Лирика: В интернете есть множество статей довольно хорошо объясняющих, как настроить ISCSI target, однако, почему-то, практически нет статей про работу с инициатором. Не смотря на то, что target технически сложнее, административной возни с initiator больше — тут больше запутанных концепций и не очень очевидные принципы работы.

ISCSI

Перед тем, как рассказать про ISCSI — несколько слов о разных типах удалённого доступа к информации в современных сетях.

NAS vs SAN

Существует два метода доступа к данным, находящимся на другом компьютере: файловый (когда у удалённого компьютера запрашивают файл, а какими файловыми системами это сделано — никого не волнует), характерные представители NFS, CIFS (SMB); и блочный — когда у удалённого компьютера запрашивают блоки с дискового носителя (аналогично тому, как их читают с жёсткого диска). В этом случае запрашивающая сторона сама себе делает на блочном устройстве файловую систему, а сервер, отдающий блочное устройство, знать не знает про файловые системы на нём. Первый метод называют NAS (network attached storage), а второй — SAN (storage area network). Названия вообще указывают на другие признаки (SAN подразумевает выделенную сеть до хранилищ), но так сложилось, что NAS — это файлы, а SAN — это блочные устройства по сети. И хотя все (?) понимают, что это неправильные названия, чем дальше, тем больше они закрепляются.

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

В общем — вот оно. Бейте ногами, режьте на части. Встречайте!

С разрешения автора материала представляю вам для ознакомления обзор соглашения о слиянии Google Inc. и Motorola Mobility Holdings, Inc.

Первое впечатление

Отгремели обсуждения о том, как, где, зачем Google купила Motorola и что из этого будет, отшутились острые языки, волна была, волна прошла. Мне в руки попал официальный текст соглашения о Слиянии Google Inc. и Motorola Mobility Holdings, Inc., датированного 15 августа 2011 г. (можете почитать здесь). Должен вам сказать соглашение далеко не маленькое, все 68 страницы отборного юридического сленга. Поэтому знакомство с творчеством американских юристов будет у нас многосерийным. Сейчас эпизод первый — обзорная экскурсия.

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

В этой статье я не буду писать о том, как правильно разрабатывать сайты и как убеждать заказчика, что вы правы. Это опыт + полное документирование проекта на каждом этапе + умение грамотно вести диалог.

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

Думаю, никто не будет спорить, что контент – король. И именно с него обычно и начинается сайт, как информационный носитель.

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

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

Обойдусь без копипастов и даже ссылок о том, что Ruby за зверь такой, ибо написано было уже сполна. В данном посте просто хочу рассказать о пути изучения Ruby (и, впоследствии фреймворка Ruby on Rails) человека далекого от программирования.

1. Любопытство

«Насколько далекого?», спросите вы, а я отвечу — «Чуть менее, чем полностью», так как в десятом классе в школе у меня были уроки программирования, парочка из которых были уделены Паскалю. Признаюсь, впоследствии о html узнал, и даже мог в Dreamweaver-e сверстать страничку или поставить готовый движок, да по инструкции налепить плагинов, но не более.
Хотя компьютеры мне нравились, пошел я учиться на экономиста* — бакалавриат, магистратура по бух. учету и аудиту, аспирантура по финансам, работа в банке, преподавание, страхование. Но не жилось мне спокойно в финансах, — финансовый калькулятор удовлетворял необходимости решения тривиальных задач, но не удовлетворял мой мозг. А ему хотелось посчитать не только будущую и приведенную стоимость актива, но и создать массив данных из исторических стоимостей этого актива за n лет, высчитать среднюю доходность, дисперсию и, в конце-концов построить красивый график!

Предисловие

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

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

Ситуацию усугубляет наблюдаемое ныне противостояние распространенного заблуждения, что в облаке все очень надежно и можно крепко спать: жесткие диски «из титана», сетевой трафик течет «по золотым проводам», а инженеры там крутые парни из Челябинска, рассекающие писсуар пополам — с рекомендациями облачного провайдера на тему «мы предоставляем сервисы достаточной надежности и быстрые каналы между ДЦ, а задача архитектора проекта — комбинировать наши технологии, доводя девяточки справа до нужного количества».

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