Support Sonata 6. Трехкомпонентная сисиема. Развертывание за 5 минут.
Ставим на компьютер пользователю
Ставим на сервер
Ставим на компьпютер админу
Если сотруднику понадобилась инструкция по созданию заявки, значит Вы выбрали не тот Help Desk.
Сидишь за reverse proxy, CDN или балансировщиком - открываешь access-лог, а там один и тот же IP на всех запросах. Обычно 127.0.0.1, адрес ingress-контроллера или внутренний IP прокси.
На этом фоне ломаются rate limiting, fail2ban, аудит и любые расследования: Nginx честно пишет адрес своего непосредственного соседа, а не исходного клиента.
Почему так.
$remote_addr - это адрес узла, который напрямую установил соединение с Nginx. Если перед ним стоит прокси, то для Nginx клиентом является именно прокси.
Настоящий IP пользователя обычно приезжает отдельно:
в X-Real-IP;
в X-Forwarded-For;
в заголовке конкретного CDN;
через PROXY protocol, если перед нами L4-балансировщик.
Но просто взять значение HTTP-заголовка и записать его в лог - плохая идея:
log_format main '$http_x_real_ip - $request';
Любой клиент может сам отправить:
X-Real-IP: 1.1.1.1
и подложить в ваши логи произвольный адрес.
Правильная схема - не доверять заголовку самому по себе, а доверять конкретному прокси, который этот заголовок формирует.
Для этого в Nginx есть штатный ngx_http_realip_module.
Проверяем, собран ли он в текущем бинарнике:
nginx -V 2>&1 | tr ' ' '\n' | grep -- --with-http_realip_module
Если Nginx собираете сами, понадобится флаг:
--with-http_realip_module
В пакетах популярных дистрибутивов модуль обычно уже включён, но проверять лучше конкретный установленный бинарник.
Настраиваем доверенный прокси:
set_real_ip_from 10.42.0.10;
set_real_ip_from 10.42.0.11;
real_ip_header X-Real-IP;
После этого Nginx будет заменять $remote_addr адресом из X-Real-IP, но только если соединение пришло от узла из set_real_ip_from.
Важно: указывайте точные адреса или минимальную подсеть балансировщиков.
Вот так делать нежелательно:
set_real_ip_from 10.0.0.0/8;
Этой настройкой вы разрешаете любому узлу из всей сети 10.0.0.0/8 подменять клиентский IP. Лучше доверять конкретным адресам прокси или выделенному сегменту.
Сам origin при этом желательно закрыть от прямого доступа извне через firewall, security group или network policy. Иначе клиент сможет обойти прокси и прийти непосредственно к Nginx.
На самом прокси X-Real-IP должен перезаписываться, а не слепо передаваться от клиента:
proxy_set_header X-Real-IP $remote_addr;
Не так:
proxy_set_header X-Real-IP $http_x_real_ip;
Во втором случае прокси просто протащит значение, которое прислал пользователь.
В чём ловушка с X-Forwarded-For
Этот заголовок содержит цепочку адресов через запятую:
X-Forwarded-For: client, proxy-1, proxy-2
Если в инфраструктуре несколько доверенных прокси, можно настроить Nginx так:
set_real_ip_from 10.42.0.10;
set_real_ip_from 10.42.0.11;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
Тогда Nginx будет разбирать цепочку справа налево, пропуская доверенные адреса из set_real_ip_from, и выберет последний недоверенный адрес.
Например:
X-Forwarded-For: 1.1.1.1, 203.0.113.25, 10.42.0.10
Если 10.42.0.10 - доверенный внутренний прокси, а 203.0.113.25 - адрес клиента, добавленный доверенным edge-прокси, Nginx выберет 203.0.113.25, а не подставленный пользователем 1.1.1.1.
Но это работает безопасно только тогда, когда вся доверенная цепочка прокси известна и перечислена в set_real_ip_from.
После обработки модулем:
$remote_addr - восстановленный адрес клиента;
$realip_remote_addr - исходный адрес узла, который подключился к Nginx;
$http_x_forwarded_for - заголовок в том виде, в котором он приехал.
Для диагностики удобно логировать всё сразу:
log_format main
'client=$remote_addr '
'peer=$realip_remote_addr '
'xff="$http_x_forwarded_for" '
'request="$request" '
'status=$status';
Так можно понять не только какой IP выбрал Nginx, но и от какого прокси пришло соединение и какую цепочку тот передал.
Rate limiting после этого тоже сможет работать по реальному клиентскому адресу - если ключ зоны построен на $remote_addr или $binary_remote_addr:
limit_req_zone $binary_remote_addr
zone=per_ip:10m
rate=10r/s;
Использовать для лимитов сырой $http_x_forwarded_for не стоит: это строка с цепочкой адресов, которую при неправильной настройке прокси можно подделать или постоянно менять.
С fail2ban та же логика: он увидит реальный адрес только в том случае, если анализирует поле лога, в котором записан обработанный $remote_addr.
Если перед Nginx стоит TCP-балансировщик, HTTP-заголовков может не быть вообще. Тогда обычно используется PROXY protocol:
server {
listen 443 ssl proxy_protocol;
set_real_ip_from 10.42.0.10;
real_ip_header proxy_protocol;
}
PROXY protocol также нельзя принимать от кого угодно: источник соединения должен быть ограничен доверенными балансировщиками.
После изменения конфигурации:
nginx -t && systemctl reload nginx
Проверяем:
tail -f /var/log/nginx/access.log
Смотрим одновременно на client, peer и xff. Проверка только первого поля лога мало что доказывает: важно видеть всю цепочку и понимать, почему Nginx выбрал именно этот адрес.
Очень краткий вывод
Не доверяйте заголовку с IP.
Доверяйте конкретному прокси, который этот заголовок сформировал.
Предположим, что у вас есть система, которая использует GNU Tar для полных и инкрементных резервных копий. Или, может быть, вы используете GNU Tar для этого напрямую. Если у вас есть инкрементный tar-архив, вас могут интересовать один или оба вопроса, которые в некотором смысле зеркально отражают друг друга: какие файлы были удалены между предыдущим инкрементом и этим, или каково состояние дерева каталогов на момент этого инкремента (если он и все предыдущие бэкапы, от которых он зависит, были правильно восстановлены). (Эти вопросы глубоко волнуют людей, которые могли удалить какое-то количество файлов, но не уверены точно, какие именно файлы были удалены.)
Обработка удаленных файлов - одна из проблем инкрементного резервного копирования, и подходы к ней бывают разными. То, как GNU Tar справляется с удаленными файлами, отчасти задокументировано в разделах "Using tar to perform incremental dumps" и "Dumpdir", но документация не объясняет это предметно. Если упростить, то GNU Tar не записывает удаления явно. Вместо этого каждый инкрементный tar-архив содержит полный список дерева каталогов, который включает как объекты, находящиеся в этом инкрементном архиве, так и те, что пришли из предыдущих. Чтобы вычислить удаленные файлы, вам нужно сравнить два списка дерева каталогов. (В рамках этого полного списка инкрементный tar-архив записывает каждый каталог, даже неизмененный.)
Вы можете получить эти полные списки с помощью команды tar --list --incremental --verbose --verbose --file ..., но tar выводит их в неудобном формате. Вы не получаете дерево каталогов в том виде, в каком его выдает обычный tar -t. Вместо этого вы получаете содержимое Dumpdir для каждого каталога, напечатанное отдельно, и вам придется самостоятельно обрабатывать результаты, чтобы собрать дерево каталогов с полными путями и так далее. Люди, вероятно, писали инструменты для этого - либо на основе вывода tar, либо путем прямого чтения формата инкрементного архива GNU Tar.
На мой взгляд, подход GNU Tar вполне разумен и обладает некоторыми полезными свойствами (хотя тут есть свои компромиссы). Что удобно, вы можете восстановить полное дерево каталогов на этот конкретный момент времени из любого отдельного инкрементного архива - вам не нужно проходить через всю цепочку, чтобы собрать общую картину. Это также, вероятно, делает систему несколько более устойчивой, если вы утеряли часть инкрементных архивов где-то в середине: по крайней мере, вы знаете, что там должно быть, пусть у вас и нет копий этих файлов. Поиск момента, когда был удален один конкретный файл, происходит лучше, чем если бы существовали явные записи об удалении, так как вы можете запустить бинарный поиск по инкрементам, чтобы найти первый, где этот файл исчезает. Отсутствие явных отчетов об удалении действительно делает неудобным определение всего, что было удалено между двумя последовательными инкрементами, но с другой стороны, вы можете определить, что было удалено (или добавлено) между любыми двумя tar-архивами, без необходимости просматривать каждый инкремент между ними.
(Можно сказать, что инкрементные архивы GNU Tar содержат снимок состояния дерева каталогов, вместо того чтобы вести журнал изменений этого состояния.)
Иногда вопросы первой линии ТП просто радуют
Видео с камеры в кабинете сисадминов. Это просто была проба работы с видеоредактором, для того чтобы поиграться с размещением видео на Ютубе. Что получилось, судите сами.
Статья готовилась в сборник для школьников, ищущих свой путь, как взгляд изнутри на профессию. Все мысли и наблюдения основаны на опыте автора :)
За время своей жизни мне пришлось сменить несколько работ, в силу ряда причин. Хочу поделиться с читателями своим взглядом на работу системного администратора.
«Курьером хорошо, а сисадмином лучше
В сисадмины я б пошел, пусть меня научат»
Почти Маяковский
Эту специальность называют по-разному: администратор, системный администратор, сисадмин, админ. Для краткости в статье я буду именовать её – сисадмин.
Сисадмином я стал по мере роста технологий. В середине 90-х я установил на крупном заводе сеть Novell и стал ее админом. Правда первая сеть насчитывала в середине 90-х всего 10 компьютеров, но это было начало. Закончил работу на заводе менеджером сисадминов. Сеть разрослась до 1200 компьютеров, многие из которых круглосуточно работали с технологическими приложениями. К тому времени заводская сеть уже была соединена с сетями других заводов компании. Сейчас я работаю в смежной области и администрированием не занимаюсь.
Первое, что должен понять для себя человек, стремящийся стать админом – это ответственность. Она будет нарастать по мере вашего профессионального роста. От фирмы с полусотней компьютеров вы можете пройти путь до человека от действий которого зависит работа десятков миллионов людей. И на каждом этапе последствия каждого неверного шага будут обходиться все дороже для вас и окружающих. Оцените свои возможности. Прежде чем начать путь по этой тропе.
«У самурая нет цели – есть только путь!»
Японская мудрость как нельзя кстати подходит к деятельности сисадмина. Вы НИКОГДА не доведете свою сеть до совершенства. Каждый день вы садовник, который стремится придать палисаднику, скверу или парку надлежащий вид. И даже если в какой-то момент вам удастся, подобно Фаусту вскричать: «Остановись, мгновенье, ты прекрасно!», то в следующее мгновение новые задачи разрушат совершенство. Если вы «процессный тип», то эта работа для вас подходит больше, чем человеку, ориентированному на результат.
Будьте готовы, что будете учиться всю жизнь. «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее» — слова королевы описывают скорость смены знаний в ИТ.
Выбрав работу сисадмина будьте готовы в любой момент включиться в работу. Днем, ночью, в отпуске – сбой не выбирает время.
В мелких организациях ваше участие обязательно всегда. В крупных есть планы аварийного восстановления, где роль каждого специалиста расписана. Без вас, конечно, смогут обойтись, но в таких случаях поднимают «всех, способных держать оружие».
В случае, если задачи сисадмина связаны с непрерывным технологическим циклом, то он на связи 24/7/365 или даже 366 дней в году. В вашем контракте/трудовом договоре может быть записано что угодно, но сбой устранять вам.
И именно в критических ситуациях проверяются знания и навык сисадмина. Восстановление технологической базы непрерывного производства, под бдительным взором начальства дает адреналина не меньше, чем полет на спортивном самолете с элементами высшего пилотажа.
Работа сисадмина в маленькой организации кардинально отличается от работы сисадмина в большой.
В маленькой организации вы будете «царь и бог», отвечающий за все. Платой за свободу ваших действий в выборе того или иного решения будет работа далекая от администрирования. Вы постоянно будете общаться с людьми и решать их текущие вопросы – от сломанной мышки, до застрявшей в принтере бумаги. Это конечно даст вам огромный опыт, но при условии, если вы готовы к такому общению. Условная «Мария Петровна» из бухгалтерии может изрядно потрепать вам нервы.
Для понимания, с чем вам придется столкнуться в работе, попробуйте обучить программе или работе с телефоном своих старших родственников. Если это получится легко и спокойствие вас не покинет, то работа с людьми для вас.
Небольшая организация позволит вам накопить опыт взаимодействия различных систем, опыт решения возникающих при этом проблем. Из минусов могу отметить низкую вероятность прохождения курсов повышения квалификации и затягивающую рутину, далекую от администрирования. Большинство знаний вы будете добывать самостоятельно. Если вы интроверт и общение с людьми для вас тягостно, то лучше начать свой старт с большой организации.
Здесь вы не будете «мудрецом в фарфоровой пагоде изредка спускающимся к смертным для решения их проблем», вы будете частью огромного механизма. Если вы не любите общаться с незнакомыми людьми, то такой старт для вас оптимален. Общение админов происходит чаще всего с ограниченным кругом людей. Даже если есть аутсорсинговое обслуживание систем и серверов, общение будет происходить с одними и теми же лицами организации.
В крупных организациях отлажена система подготовки кадров, вы пройдете внутренние и внешние курсы по вашей специальности. Вас поддержат и направят ваши старшие товарищи. Большинство ваших действий будут делаться по утвержденным алгоритмам и кейсам. Из минусов – вы не получите опыта взаимодействия различных систем и не будет влиять на ИТ решения. И можете стать очень узким специалистом в конкретной области. В этом нет ничего плохого, но этот фактор надо учитывать. До мест, где вы самостоятельно будете принимать решения вам придется добираться долго, и вы уже сможете осознать меру вашей ответственности.
Есть вариант, когда вы работаете сисадмином в небольшом филиале организации, тогда вам удастся совместить преимущества и недостатки большой и малой организации. Обучение и настройка будут происходить под присмотром старших товарищей, а у вас будет некоторое поле для проявления инициативы в работе. Плюсом такого подхода является возможность роста и перехода в головной офис.
Несмотря на то, что ИТ технологии добрались до большинства рабочих мест, многие пользователи до сих пор с ними на «Вы». Иногда пользователи принижают себя, говоря такие фразы: «Вы такой умный, а я вот в этом совсем не разбираюсь (да куда уж мне, мы люди простые etc.)». Для многих людей, чей возраст вдвое превышает ваш, обращение за знаниями к молодому человеку это психологическая проблема. Несомненно, такой подход ласкает ваш слух и повышает ЧСВ, но не попадайтесь в эту ловушку. Превращение в бронзовую статую с нимбом на голове не способствует гибкости ума. Наиболее оптимальная формула выхода: «Марья Петровна, нельзя быть специалистом во всём, вы разбираетесь в бухгалтерии (логистике, снабжении и т.д.), а я в ИТ. Каждый делает свое дело». Поверьте, хорошие отношения с пользователями никогда и никому не вредили.
Заведите себе привычку все документировать. Надеяться на память не нужно. Некоторые действия приходится проделывать раз в год или реже. Поверьте, даже человек с хорошей памятью может забыть некоторые нюансы. Документирование нужно прежде всего вам. Чем дольше вы работаете в одной организации, тем больше вы знаете нюансов, свойственных конкретной сети. Документируйте их.
Один из руководителей говорил: «Важно иметь минимум двух сисадминов, которые не пьют в одной компании, не ездят на одной машине и не летают одним самолетом». Все важные пароли должны быть записаны на бумаге и помещены в сейф, случиться может всякое. Даже вы сами можете забыть важный пароль.
Сисадмин постоянно должен готовиться к сбою в работе оборудования. В крупных организациях разрабатывают и периодически актуализируют планы аварийного восстановления. В мелких вам придётся делать это самостоятельно. Регулярная проверка бэкапа – одна из важнейших функций сисадмина. Позднее это приведет к профдеформации: «Бэкапов много не бывает».
Достоинства работы сисадмина – возможность горизонтального роста. Часто повышение в должности, или вертикальный рост, не дает возможность продолжать работу сисадмина в полной мере и начинает снижать его навык. Но всегда есть возможность, оставаясь на одной должности расти в своих знаниях. На этой работе вы можете найти свой баланс работа-семья-увлечения. В ряде случаев сисадмины покидали более высокооплачиваемую должность и возвращались на свое предыдущее место с привычным балансом жизни.
Кроме роста по управленческой линии сисадминам доступен и рост по профессиональной. Можно попробовать свои силы в смежных областях. Близка к работе админа должность системного архитектора на проектах, когда опыт и знания позволяют создавать новые информационные системы. В дальнейшем такие люди часто становятся руководителями проектов в ИТ областях.
В целом работа сисадмина очень интересная, но необходимо учитывать особенности своего характера, чтобы работа приносила удовлетворение. Берите знания там где можете и сколько можете унести.
Отдельные слова хочу написать для девушек, ищущих себя в этой профессии. Большинство сисадминов — мужчины. И у вас будут сложности, но они вполне преодолимы. Будьте готовы к неприятию со стороны коллег мужского пола. Равенство и равноправие заявлено в рамках закона, но часто сталкивается с традициями общества. Не падайте духом, у меня есть знакомые девушки системные администраторы и они отлично работают. А одна из них уже руководит админами на крупном заводе. Единственный способ борьбы с предрассудками — знания.
Кроме профессиональных могут возникнуть и личные сложности. Не все мужчины поймут вызов на сбой среди ночи. Но с другой это может помочь найти понимающего человека.
В целом работа админа очень интересная. Вам просто необходимо учитывать особенности своего характера, чтобы работа приносила удовлетворение. Берите знания там где можете и сколько можете унести.
“По большой структуре сети
Сервер файлы рассылает.
Между сервером и дверью
Восседает Supervisor
Cyberdaemon’у подобный.
Он крутой upgrade замыслил
От которого, конечно,
Все работать будет хуже…
Но зато узнает каждый
Кто в конторе самый главный …”
Народное творчество 90-х
И если вы выберет стезю сисадмина, то станете “бойцом невидимого фронта”. Кондиционеры и чиллеры будут обдувать вас холодными ветрами в серверных. С красными от бессонницы глазами вы будете искать неисправность среди ночи, чтобы люди могли переслать друг другу котиков и пожелания доброго утра. Под трибунами сотый раз проверять оборудование, чтобы все кольца олимпийской эмблемы раскрылись вовремя. Проходить по лезвию бритвы, меняя прошивку маршрутизатора в далекой сибирской тайге, куда “только самолетом можно долететь”. Но пройдет время и при вашем появлении ошибки программ будут исчезать сами, а сервера получать нужные настройки. История компьютерной техники будет проходить перед вашими глазами. Спустя годы вы сможете сказать: “Я был там, две тысячи лет назад …”.
P.S. Иллюстрации к статье создавал автор при помощи Qwen
Автор: Павел Пырин
Редактор: Сабуров Даниил
Оригинал статьи https://stroikaveka.org/sfery-zhizni/v-sisadminy-ya-b-poshel...
Условия использования: свободное некоммерческое использование при условии указания автора и ссылки на первоисточник.
Для коммерческого использования — обращаться на почту: buildxxvek@gmail.com
Спасибо за поддержку
@Balu829 - человек имеющий свое мнение обо всем на свете
@Mauop.KomoB - человек творческий
@kka2012 - юридические истории, такое не придумаешь
они и я рекомендуем
@MorGott - любители юмора и лора всевозможных вселеных - вам сюда. "Звёздные войны" - отдельное спасибо
@kotofeichkotofej - качественные переводы комиксов с сохранением шутеек
@ZaTaS - авторские рисунки, шаржи и просто отличные образы. Несерьёзно о серьезном
@Erepb.Ky3bMu4 - Кузьмич, что ещё сказать.
@MamaLada - скоровские истории. У неё телеграмм. Заходите в телеграмм.
@volchek1024 - Писатель с разнообразным сильным материалом
@VasilyGrust - писатель , женщины в истории.
Столкнулся с любопытной проблемой. Многим последнее время рекомендовал брать ноутбуки 16"(они реально классные по соотношению полезное место на экране-цена, имхо), но вместе с тем столкнулся, что при общении письмами через Outlook начали чаще случаться казусы с изображениями в почтовике. Как оказалось у них по умолчанию выставлялся масштаб изображения 125%.
Беглый поиск решений по нейросетям или схожим проблемам в Гугле/Яндексе результатов не дал.
А проблема была в том, что изображение, которое я отправляю, у получателя выглядит мельче оригинала, а если он поставит это же изображение (тот же файл) в свою подпись, то мне оно придёт больше исходного размера с шакальным качеством. Отдельно отмечу, что моё изображение из моего письма, вернувшись ко мне будет выглядеть корректно. Фактически, Outlook изменяет размер изображения не взирая на настройки по одному лишь ему известному паттерну.
Условно берём пикачу 100 на 100 пикселей (здесь и далее рекомендую ориентироваться на сопутствующий текст)
Отправляем адресату, а он получает следующее
Так сказать "Пикачу скукожился".
А если человек пишет ответ, то я получаю совсем странное. Мой пикачу нормальный, а у него 49,5
К чему это я? А точно. О проблемах с добавлением изображений в подпись Outlook!
Так вот, вспомнив молодость, я начал перебирать варианты и нашёл причину. Оказывается виновато масштабирование экрана в системе (Win10/11). У моего коллеги установлено масштабирование 125%, но одному лишь Одину известно почему, Outlook чужие изображения уменьшает/не масштабирует, а твоё увеличивает на эту самую разницу между 100% и текущим.
Решение следующее: добавление изображения не из файла, а копированием из полученного сообщения. После этого на картинку не действуют поломные правила и все участвующие в переписке видят одинакового пикачу без уменьшения и увеличивания.
Либо установить 100% масштабирование проблемному пользователю и купить ему микроскоп =)
З.ы. У тандербёрда свои проблемы бывают, добавление изображения через ссылку считаю достойной альтернативой, но в наше время почти все почтовики отсекают все гиперссылки, а значит или лишние изображения в переписке или готовимся получить переписку вида.
