Авторизация в nginx на базе google одноразовых паролей.
По разным причинам пришлось отказаться от авторизации auth_basic и файла с паролями, несекурно и все тут.
Пользователей много с разным уровнем знаний, поэтому авторизация по сертификатам не подходит.
Подсказали решение на базе Nginx (http_auth_request_module) + Apache (google-authenticator-apache-module).
Поковырявшись несколько дней поднял, но не мог понять некоторые моменты как работают. Поковырявшись еще и разобрался.
Недавно мне поставили такую задачу: Есть много коммивояжеров с ноутбуками которые разъезжают по стране и что-то кому-то впаривают продают.
Т.к. им нужны актуальные данные о наличии товара и ценах, время от времени они подключаются к центральному серверу через интернет и сливают себе обновленные данные.
Условия к задаче:
— Частота и периодичность выхода на связь коммивояжеров неизвестна, ровно как и длительность.
— Должно все работать максимально надежно, потому как коммивояжеры они такие «коммивояжеры».
— Решение должно быть на базе Mysql master-slave replication.
Выводы из условия:
— Для надежности, на стороне клиента(slave) минимум настроек, никаких скриптов по крону, все должно быть внутри mysql.
— Т.к. неизвестно когда и с какой периодичностью будут подключаться к master базе коммивояжеры, binlog на мастере нужно хранить так долго пока все slave не скачают его себе.
Решение:
— Информировать мастер, какие slave и сколько уже «скачали». А точнее в какой позиции самый «ленивый» slave.
— Все остальные binlog можно смело удалять.
Внутри одно дата-центра организовать отказоустойчивость легко — есть масса инструментов и техник.
А как быть если надо организовать отказоустойчивость на базе нескольких дата-центров?
Ниже я приведу, на мой взгляд элегантное и очень дешевое решение, не лишенное конечно же недостатков.
Смысл заключается в том чтоб в каждом дата-центре был свой NS сервер который отдает IP своего дата-центра.
Зачастую мне приходится иметь дело с таблицами которые содержат редко или даже никогда ни обновляемые данные. Хорошим примером таких данных являются различные логи. Некоторые таблицы регулярно очищаются от устаревших данных, а в некоторых приходится хранить записи «вечно». Поэтому такие таблицы «пухнут» и работа с ними становится тяжелой операцией для всей системы.
Чтобы уменьшить нагрузку на диск и ФС, придумали partitioning, по простому — секционирование. Файл с данными таблицы разрезается по какому-то условию на несколько не больших файлов — партиций. Для случая с логами разумно партиционировать таблицы по полю, содержащему даты события. Часто бывает разумно резать таблицу на partition по году по месяцу или по дням месяца/недели.
Что-то подсказывает что резать придется по полю timestamp.