-
вклад
-
3вопроса
-
389ответов
-
36%решений
Лайки
-
Как добавить заголовок в NGINX только для определенного IP?
edo1h @edo1hЧто-то вроде этого:
map $http_x_forwarded_for $cachefile_header { "8.8.8.8" $cachefile; default ""; } … server { … location "/" { … add_header X-Cache-File $cachefile_header; } }
P. S. неплохая статья про map (там упоминается и про "if is evil") -
Как запретить доступ к сайту из USA но разрешить user-agent Googlebot?
dodo512 @dodo512map "$geoip_country_code,$http_user_agent" $deny { default 0; ~^US.*Googlebot 0; ~^US 1; ~^CN 1; } server { if ($deny) { return 403; } -
Как найти битый *.png файл?
-
Как отобразить GOшный сайт в Firefox?
-
Есть ли разницы в производительности веб-сервера под CentOS 7 и CentOS 8?
-
Какой годный курс, а лучше книгу по docker, docker-compose, ansible?
Все хорошие инструменты - необычайно гибкие в использовании.
Поэтому никакой курс не сможет раскрыть инструмент в различных вариантах, не хватит времени.
Практически в каждом проекте что-то настраивается под себя, так как это удобно или как придумано именно здесь и сейчас.
К документации нужно просто добавлять практику на каком-то хобби проекте, или реальном проекте, чтобы стояла конкретная задача. И все. -
Не срабатывают правила iptables, чяднт?
Может соединения уже в established висят. Они могут на роутере висеть даже. -
Как урезать аппетиты Postfix-a?
Вы можете ограничить колво процессов постфикса:
1й путь - в main.cf указать default_process_limit - по умолчанию 100, попробуйте поставить 50
2й путь - в master.cf можно указать лимит процессов каждого воркера, нас интересует: строка
smtp unix - - - - - smtp
предпоследняя колонка это лимит процессов данного воркера
можно поменять на
smtp unix - - - - 40 smtp
После любых изменений перезапустите постфикс. -
Необходимо ли выносить docker окружение в отдельный репозиторий?
Правильно - хранить код в одном репозитории.
На проде не требуется даже иметь гит или что там у вас в качестве системы контроля версий.
Нужно настраивать CI/CD так, чтобы в контейнер на прод выкатывались только нужные файлы и каталоги, ничего лишнего.
Очень удобно, когда в девелоперском окружении код работает без докера, но сопутствующие вещи вроде БД и прочих сервисов удобно держать в контейнерах и на девелоперской машине. Так проще развёртывать среду разработки и быстрее вводить сотрудников в процесс. Технически нет особых проблем, чтобы настроить удалённую отладку прямо внутри контейнера. так можно приблизить девелоперское окружение к продовой конфигурации.
Вообще очень многое зависит от сложности вашего проекта, от количества и связности ваших модулей, от механизмов, направленных на масштабируемость.
Храните всё, что нужно для CI/CD в том же репозитории где код. Там же у вас лежат тесты (не нужные в продакте), вспомогательные скрипты, артефакты тулинга и прочее.
Поищите, в гитхабе есть много так называемых "КукиКаттеров". Это инструмент, для шаблонизации проектов на разных стеках. Как правило в созданной по такому шаблону заготовке проекта уже есть всё не обходимое для CI/CD. -
Как узнать через консоль какие диски установлены в системе?
С помощью lshw. Для мира RedHat и CentOS она ставится вот так:
yum -y install epel-release yum -y install lshw
дальше краткий список дисков:
lshw -short | grep disk
если подробно:
lshw | less -
Дайте наводку на самый годный мануал для настройки почтового сервера и всего ПО для него?
Столь обширные вопросы методом ковыряния VPSки не "закрываются". Годик-другой поддержки реального почтовика выглядит более перспективно с этой точки зрения - с неспешным сбором граблей, разборками с пользователями и всяким таким.
Отриньте давно устаревшие или неполные гайды и панельки, первый шаг в сторону от которых поставил всё колом. -
Дайте наводку на самый годный мануал для настройки почтового сервера и всего ПО для него?
Dr. Bacon @baconНу и одна статья другой противоречит.
Ну и один мануал другому противоречит. Проблема всего этого, что нет универсального рецепта настройки. Смотри какие есть у DigitalOcean, но и к ним можно без конца придираться.
ЗЫ а нормальный почтовый сервер по мануалу "нормально" практически не собрать, тут нужен именно опыт. -
Как организовать работу с mongodb и докером на локалке и сервере?
Ни в коем случае не пушить туда-сюда.
- В идеальном случае ваш проект должен поддерживать миграции:
- Каждая ревизия кода, которая нарушает совместимость с БД относительно предыдущей, должна содержать скрипт миграции. В этом скрипте создаётся структура, модифицируются старые данные, переименовываются поля и т.д. Иногда такие скрипты делают двунаправленными, чтобы поддерживать обратные миграции.
- В БД нужно хранить версию или номер ревизии, которой соответствует текущее состояние БД.
- При запуске приложения нужно проверять версию и выполнять цепочку миграций, необходимых для приведения версии к требуемому состоянию.
Так вы можете добиться того, чтобы продуктовая БД была отдельно, тестовая отдельно, девелоперская отдельно. Очень плохая идея работать на девелоперской машине с данными из продовой базы. Так происходят утечки перс-данных.
Монга - это schema less БД, которая толерантно относится структуре коллекций и не валится при запросе несуществущих полей. Нужно стараться писать код максимально толерантно к отсутствию наполнения БД.
В любом случае у вас в БД есть обычно:
- структура (в случае монги, как я уже сказал, это не так важно)
- справочники
- пользовательские данные
- производные данные (кэш), которые можно безболезненно удалить, а затем они перегенерятся сами по мере запросов.
Нужно писать код так, чтобы он всю структуру и технические справочники, отсутствующие в предоставленной БД и необходимые для работы, умел инициализировать сам. Или, на худой конец, сделайте команду или скрипт init_db.
Если какие-то тестовые данные нужны для тестов или отладки, то можно сделать скрипт, который заполнит БД ими. Это называется фикстуры.
Никогда не храните код в БД. Всякие хранимые процедуры и прочее в БД - это зло. Код должен быть в системе контроля версий, а БД к этому не приспособлены. Если уж нужны хранимки, то храните их в системе контроля версий и заливайте их в БД при инициализации или миграциями. - В идеальном случае ваш проект должен поддерживать миграции:
-
Доработать скрипт BASH, чтобы отдавал вывод конкретной команды?
Не использовать telnet. Есть вполне себе нормальный api, ну или хотя бы ssh. -
Построение сети в офисе с VPN?
1. Настроить ip forwarding на Linux-сервере
2. Настроить VPN-соединение куда вам там надо. Вы не уточнили как реализован VPN-сервер назначения
3. На клиентах сети настроить шлюзом IP-адрес вашего Linux-сервера -
При подключении по SSH постоянно запрашивается пароль, как исправить?
-
У кого в организации есть утвержденный план действий при отказе оборудования или ЧС в серверной?
Нельзя писать инструкции для стороннего не обученного персонала по ремонту оборудования.
Максимум можно описать схему переключения на резерв, если например требуется ручное включение рубильника или типа того.
Написав инструкцию ты выроешь себе могилу, т.к. в любой ошибке персонала (а она обязательно будет) будешь виноват ты.
Я бы посоветовал видоизменить инструкцию из двух пунктов
1. Обесточить оборудование
2. Поставить в известность непосредственного руководителя.
Если человек обязан вызвать администратора, которого невозможно вызвать, то ты подставишь этого человека.
Руководитель есть? Вот он пусть и руководит процессом ликвидации ЧП, пусть у него болит голова как до тебя дозвониться, это его работа, решать орг вопросы. -
Можно ли 4 + 8 гб?
