С давних пор для второго шага аутентификации мы использовали одноразовые пароли отправляемые через СМС. Такой функционал появился в Redmine в 2013, когда мы разработали плагин redmine_sms_auth. Об этом мы писали в давней статье.

Но время не стоит на месте. Мы активно внедряем Telegram в бизнес-процессы компании (раз, два, три).

В связи с этим решили сделать аутентификацию через Telegram в Redmine. Заодно с этим переписать старый плагин про СМС и добавить поддержку Google Authenticator.

Далее мы расскажем о том как установить, настроить и использовать этот плагин.

Однажды появилась такая необходимость обновить версии темплейтов OpenVZ загруженных в кэш Proxmox'а.

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

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

Итак, есть желание и пора приступать к его осуществлению. Для начала решим, что же конкретно должен делать наш скрипт.

Бывает, сайты падают из-за отказа площадки хостера, каналов и так далее. Я 7 лет работаю в хостинге, и часто вижу такие проблемы.

Пару лет назад я понял, что услуга резервной площадки (без доработки их сайта или сервиса) очень важна клиентам. Теоретически тут всё просто:
1. Иметь копию всех данных в другом дата-центре.
2. При сбое переключать работу на резервный ДЦ.

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

Про fail2ban написано уже много, в том числе и на хабре. Эта статья немного о другом — как сделать защиту им еще надежнее и о еще пока неизвестных в широких кругах новых функциях fail2ban. Добавлю сразу — речь пойдет пока про development branch, хотя уже долго проверенный в бою.

Краткое вступление

В большинстве своем fail2ban устанавливается из дистрибутива (как правило это какая-нибудь стабильная старая версия) и настраивается по манам из интернета за несколько минут. Затем годами работает, без вмешательства админа. Нередко даже логи, за которыми вроде как следит fail2ban, не просматриваются.
Так вот, сподвигнуть на написание этого поста меня заставил случай, произошедший с одним сервером моего хорошего знакомого. Классика жанра — пришла абуза, за ней вторая и пошло поехало. Хорошо еще злоумышленник попался ленивый — логи не потер, да и повезло еще крупно, что logrotate был настроен, чтобы хранить логи месяцами.

Введение

Как настроить nginx в качестве frontend к apache и зачем это нужно — написано неоднократно, в том числе и на Хабре. Мой случай немного отличается от классического. Начиналось все как обычно, проект на apache, увеличение количества посетителей и, связанная с ним, недостаточность ресурсов сервера. Но проект использовал SSL для защиты обмена данными с клиентами. С чем я столкнулся и как решил проблемы я расскажу под катом.

^{Карта Участники OpenStreetMap}
 
Существует множество способов определения местоположения, такие как спутниковая навигация (GPS), местоположение по беспроводным сетям WiFi и по сетям сотовой связи.
 
В данном посте мы попытались проверить, насколько хорошо работает технология определения местоположения по вышкам сотовой связи в городе Минске (при условии использования только открытых баз данных координат передатчиков GSM).
 
Принцип действия заключается в том, что сотовый телефон (или модуль сотовой связи) знает, каким приемопередатчиком базовой станции он обслуживается и имея базу данных координат передатчиков базовой станции можно приблизительно определить своё местоположение.

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

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

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

В этой статье я опишу интересное решение на базе Nginx для случая, когда дисковая система становится узким местом при раздаче контента (например, видео).

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

Проявляется это приблизительно так: иногда 3Kb картинка грузится так, как будто бы она весит 3Mb, на ровном месте начинают «залипать» (отдаваться очень медленно) css-ы и JavaScript-ы. Вы нажимаете ctrl + reload — и уже, вроде, проблемы нет, потом спустя всего несколько минут все повторяется опять.

Не всегда истинная причина «тормозов» очевидна и мы косо поглядываем то на nginx, то на хостера, то на «забитый» канал, то на «тормозной» или «глючный» браузер :)

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

В этой статье я предложу Вам свое решение этой проблемы, основанное на практическом опыте использования SSD дисков совместно с web-сервером nginx.

Предисловие от переводчика

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

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

Статья будет полезна как для видавших виды «поваров», так и для новичков.

Вот надумал написать обзор библиотек с помощью которых легко и удобно писать приложения под Android.
Список вырисовывается такой:

• Android Annotations
• Groundy
• Retrofit
• AnnotatedSQL
• Android db-commons

Если заинтересованны прошу под кат.

Привет, Хабраюзеры! На улице противная погода, ангина не дает покоя моему воспаленному горлу, почему бы не написать статью? Это моя первая проба пера на Хабре, поэтому не судите строго. Название ее навеяно огромным количеством книг, имеющих схожее название. В этой статье я постараюсь описать путь воина-автоматизатора для юных падованов, коим в некоторой мере являюсь сам. Речь пойдет о подходе, который при определенном старании, поможет в краткие сроки познакомиться с таким инструментом кроссплатформенной автоматизации, как CHEF. А также, при сильном старании – овладеть ним в достаточной мере для первых серьезных опытов. Эта статья – некий “guiding way” для людей, мало знакомых с процессом автоматизации.

Если вы являетесь rails-разработчиком, то вы наверняка слышали про Unicorn, http-сервер, способный одновременно обрабатывать множество запросов.

Для обеспечения параллельности Unicorn использует создание множества процессов. Т.к. созданные (форкнутые) процессы являются копиями друг друга, это значит, что rails-приложение должно быть потокобезопасным.

Это здорово, т.к. нам тяжело быть уверенными, что наш код является потокобезопасным. Если мы не можем быть уверены в этом, то ни о параллельных веб-серверах, таких как Puma, ни даже об альтернативных реализациях Ruby, реализующих параллелизм, таких как JRuby и Rubinius, не может быть и речи.

Поэтому Unicorn предоставляет нашим rails-приложениям параллельность даже если они не потокобезопасны. Однако, это требует определенной платы. Rails-приложения, запускаемые на Unicorn’е требуют гораздо больше памяти. Не обращая никакого внимания на потребление памяти вашим приложением, вы можете в итоге обнаружить, что ваш облачный сервер перегружен.

В этой статье мы рассмотрим несколько способов использования параллельности Unicorn'а, при этом контролируя количество потребляемой памяти.

Очень короткая статья, про то как можно использовать HAProxy в качестве балансировщика для multi-master серверов MySQL, таких как Percona или Galera.

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

Для тех кто не знаком с HAProxy, цитата о предназначении продукта:

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

От слов к делу, установка и настройка очень просты:

Привет уважаемому сообществу!

В какой-то момент времени встала потребность перенести базу приложения на django с mysql на postgresql. Первые два захода на эту проблему были неудачными, но позволили разобраться с целостностью данных, искоренить проблемы для manage.py syncdb и manage.py migrate.

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

Мы в РИКе немного ретрограды — до сих пор читаем книжки и советуем это делать нашим студентам. Пусть буржуи говорят про клиповое мышление, но мы верим, что Россия как была самой читающей страной в мире, так ею и останется :)

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

PostgreSQL предлагает несколько вариантов резервирования данных. Обо всех них уже рассказано не раз, в том числе и на хабре. Но в основном рассказывается про технические особенности методов. Я же хочу постараться рассказать про общую стратегию резервного копирования, объединив все методы в эффективную систему, которая поможет вам сохранить все данные и уменьшить число погибших нервных клеток в критических ситуациях.
Вводные данные: сервер PostgreSQL 9.2, База размером >100Gb.

Статья является пошаговым руководством по построению масштабируемого отказоустойчивого файлового хранилища, доступ к которому будет осуществлен по протоколам Samba, NFS. В качестве файловой системы, которая будет непосредственно отвечать за сохранение и масштабирование файловой шары будем использовать GlusterFS, о котором было уже достаточно написано хабрасообществом. Так как GlusterFS — часть Red Hat Storage, туториал написан для RH — like систем.

Есть несколько идентичных серверов (4 ноды) на Amazon EC2 с Ubuntu. Каждый генерирует и хранит у себя на диске кэш, который хотелось бы синхронизировать. Но простой rsync тут не подойдет — файлов несколько миллиардов, nfs — слишком медлителен, и т. д. Полный список рассмотренных вариантов с пояснениями ниже.

К тому же, время от времени нужно удалять устаревшие файлы сразу на всех серверах, что пока делается вручную и занимает несколько суток. Вопрос наиболее быстрой для такого Use Case файловой системы планирую описать позже. Оговорюсь только, что по нескольким причинам была выбрана XFS.

После теста нескольких кластерных технологий и файловых систем, по совету старшего товарища, решили использовать тот же rsync, но в связке с inotify. Немного поискав в интернете готовое такое решение, дабы не изобретать велосипед, наткнулся на csyncd, inosync и lsyncd. На хабре уже была статья о csyncd, но он тут не подходит, т.к. хранит список файлов в базе SQLite, которая вряд-ли сможет сносно работать даже с миллионом записей. Да и лишнее звено при таких объемах ни к чему. А вот lsyncd оказался именно тем, что нам и было нужно.

UPD: Как показала практика, необходимо ощутимое измение и дополние в тексте. Я решил внести лишь незначительные правки в основную часть, а новыми выводами поделиться в конце статьи.