Имеет смысл выбросить устаревшее барахло типа SSLv3/TLSv1/TLSv1.1 и использовать разумный набор ciphersuites. Есть хорошие рекомендации и генератор конфигов под популярный софт от Мозилла.
Например, intermediate (TLSv1.2+TLSv1.3, ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384) -- это поддержка Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, and Safari 9, куда уж древнее лезть.
TLSv1 -- это Firefox 1, Android 2.3, Chrome 1, Edge 12, IE8 on Windows XP, Java 6, OpenSSL 0.9.8, Opera 5, and Safari 1..
Если про сервера с k8s -- давно containerd+runc (или crun и другие CRI engines), докер последнее время под капотом его сам использует. Из k8s dockershim (который позволял запускать pod'ы через docker) уже выкинули 3 версии как (в 1.24, начало 2022), а deprecated он был с 1.19 (~2.5 лет назад).
Если для локальной машины/CI -- docker или podman/buildah (под капотом containerd+crun).
Пока да, но они стремились всех перевести на cloud версию (не только Jira, но и OpsGenie) и народ влетел на полторы недели недоступности, если правильно помню без какой-либо разумной обратной связи кроме "мы работаем над этим" и без озвучивания сроков восстановления. И они в какой-то момент заявляли о том что планируют избавиться от on-prem варианта совсем..
может легко разломать систему: во-первых лишний пробел перед ro, во-вторых лейбл может оказаться не /boot (или отсутствовать вообще). Лучше уж использовать человеческий UUID
Особенно хорошо когда этот трекер -- это JIRA в Atlassian Cloud, как сейчас модно xD На те же грабли можно влететь с sms-gateway'ями, сервисами типа PagerDuty..
Про конфиг postfix'а: из того что бросилось в глаза smtp_use_tls = yes при выставленном smtp_tls_security_level не нужен.
Зачем вы ставите certbot через snap (которому, по хорошему не место на сервере) вместо пакета из репозитория или venv+pip -- не понятно. Избегание стандартного пакета из репозитория может быть понятно, если уже нарывались как некоторые доп репозитории типа powertools умеют разваливать certbot.
Никогда так не делайте, тем более на сервере. Для такого способа установки сначала скрипт сохраняется в файл, внимательно просматривается и только потом запускается. Это, кстати, известный вектор для атаки, т. к. скачивание и отправка в pipe легко различимы со стороны сервера и в curl ... | bash -s может быть выполнен совсем другой код.
chmod -R go+r /etc/gitlab/ssl/
И вы пошарили приватные ключи со всеми пользователями системы. Не надо так.
setenforce 0
Может лучше выполнить первым пунктом RTFM, а вторым проставить/восстановить нужные контексты?
Не стоит создавать access key для root аккаунта (aws об этом пишет много где). Создайте отдельного юзера в IAM, настройте разумную политику для него и используйте ключи от его имени.
Ну а о самой "статье" сказать толком нечего, 100500ый туториал как создать какой-нибудь объект в aws и как создать репо на github с недотуториалом про actions.
Да это понятно, что dev иметь представление о сети полезно, но большая часть того чем занимается сетевой инженер -- совсем не его песочница. Здесь же статья была уровня недотуториал по шарку..
Что же до ceph, если senior dev с ней взаимодействует (даже просто читает/пишет с/на смонтированный iscsi), то знать ограничения крайне желательно. Иначе будут fsync'ать после каждого байта (или 512) или выжрут все iops'ы когда в этом не было необходимости. Также как представлять что у разных хранилищ бывает сильно разный размер блока, знать характерные задержки для того io с которыми взаимодействует (и когда это знание станет важным). Как, в общем, с любой смежной областью с которой он имеет дело. Иначе разве это senior, если он живёт в парадигме monkey see -- monkey do?
На мой взгляд базовое уменение пользоваться wireshark/tcpdump необходимо как senior dev, так и линуксовому ops'y общего профиля. Мне в роли разработчика далеко не раз приходилось втыкаться wireshark'ом чтобы отловить проблемы с кодировками, компрессией, несброшенными буфферами, некорректным проксированием и т. п.
Иногда бывает полезно воткнуться удаленно, но это уже обычно не для dev'а: wireshark -k -i <(ssh $REMOTE "tcpdump -s 0 -U -n -w - -i $INTERFACE [filters..]")
Главное чтобы в процессе не получался драконий покер против команды разработки xD
Ну и слово grooming в отоншении людей и их взаимодействия для более-менее знакомых с общечеловеческим употреблением английского обычно имеет сильно негативную коннотацию..
Прям дрожь пробовала пока не перечитал и не предположил что имелся ввиду csv, а не cvs..
А так такого на perl'е было написано предостаточно
Это начало касаться и простых пользователей облачных платформ. Тот же Hetzner начал хотеть денег за публичный IPv4
Имеет смысл выбросить устаревшее барахло типа SSLv3/TLSv1/TLSv1.1 и использовать разумный набор ciphersuites. Есть хорошие рекомендации и генератор конфигов под популярный софт от Мозилла.
Например, intermediate (TLSv1.2+TLSv1.3,
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384) -- это поддержка Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, and Safari 9, куда уж древнее лезть.TLSv1 -- это Firefox 1, Android 2.3, Chrome 1, Edge 12, IE8 on Windows XP, Java 6, OpenSSL 0.9.8, Opera 5, and Safari 1..
Если про сервера с k8s -- давно containerd+runc (или crun и другие CRI engines), докер последнее время под капотом его сам использует. Из k8s dockershim (который позволял запускать pod'ы через docker) уже выкинули 3 версии как (в 1.24, начало 2022), а deprecated он был с 1.19 (~2.5 лет назад).
Если для локальной машины/CI -- docker или podman/buildah (под капотом containerd+crun).
Почему для однонодового k8s был выбран metallb?
А что с flannel не так? Не считая отсутствия сетевых политик
Ну и с record'ами людям периодически нужны
@With/@Builder. Плюс, иногда нужны полноценные древние java beans, там либо руками, либо@Data// removed
Пока да, но они стремились всех перевести на cloud версию (не только Jira, но и OpsGenie) и народ влетел на полторы недели недоступности, если правильно помню без какой-либо разумной обратной связи кроме "мы работаем над этим" и без озвучивания сроков восстановления. И они в какой-то момент заявляли о том что планируют избавиться от on-prem варианта совсем..
Более того, использование
может легко разломать систему: во-первых лишний пробел перед
ro, во-вторых лейбл может оказаться не/boot(или отсутствовать вообще). Лучше уж использовать человеческий UUIDсложна и тяжела эта русска языка, но есть в ней слово "публикация"
Особенно хорошо когда этот трекер -- это JIRA в Atlassian Cloud, как сейчас модно xD
На те же грабли можно влететь с sms-gateway'ями, сервисами типа PagerDuty..
Про конфиг postfix'а: из того что бросилось в глаза
smtp_use_tls = yesпри выставленномsmtp_tls_security_levelне нужен.Зачем вы ставите certbot через snap (которому, по хорошему не место на сервере) вместо пакета из репозитория или venv+pip -- не понятно. Избегание стандартного пакета из репозитория может быть понятно, если уже нарывались как некоторые доп репозитории типа powertools умеют разваливать certbot.
Никогда так не делайте, тем более на сервере. Для такого способа установки сначала скрипт сохраняется в файл, внимательно просматривается и только потом запускается. Это, кстати, известный вектор для атаки, т. к. скачивание и отправка в pipe легко различимы со стороны сервера и в
curl ... | bash -sможет быть выполнен совсем другой код.И вы пошарили приватные ключи со всеми пользователями системы. Не надо так.
Может лучше выполнить первым пунктом RTFM, а вторым проставить/восстановить нужные контексты?
Спасибо, посмеялся. Вы так будете по одному адресу руками банить сотню-тысячу адресов в месяц? Не проще настроить fail2ban?
Напомнило:
How much watch?
No so much..
MGIMO finished?
Ask!
Посмотрев на первые же листинги немного удивился.
разве автоконфигурация из
spring-boot-starter-amqpне создаетConnectionFactory/AmqpAdmin/RabbitTemplate?почему
@EnableRabbitна компоненте (а не на конфигурации)?если хотите health endpoints -- используйте челевоческий
spring-boot-starter-actuatorСначала фраза смутила, потом уже глянул на код. Хорошее название
Formatterдля того что на самом деле являетсяCodec'ом xDНе стоит создавать access key для root аккаунта (aws об этом пишет много где). Создайте отдельного юзера в IAM, настройте разумную политику для него и используйте ключи от его имени.
Ну а о самой "статье" сказать толком нечего, 100500ый туториал как создать какой-нибудь объект в aws и как создать репо на github с недотуториалом про actions.
Да это понятно, что dev иметь представление о сети полезно, но большая часть того чем занимается сетевой инженер -- совсем не его песочница. Здесь же статья была уровня недотуториал по шарку..
Что же до ceph, если senior dev с ней взаимодействует (даже просто читает/пишет с/на смонтированный iscsi), то знать ограничения крайне желательно. Иначе будут fsync'ать после каждого байта (или 512) или выжрут все iops'ы когда в этом не было необходимости. Также как представлять что у разных хранилищ бывает сильно разный размер блока, знать характерные задержки для того io с которыми взаимодействует (и когда это знание станет важным). Как, в общем, с любой смежной областью с которой он имеет дело. Иначе разве это senior, если он живёт в парадигме monkey see -- monkey do?
На мой взгляд базовое уменение пользоваться wireshark/tcpdump необходимо как senior dev, так и линуксовому ops'y общего профиля. Мне в роли разработчика далеко не раз приходилось втыкаться wireshark'ом чтобы отловить проблемы с кодировками, компрессией, несброшенными буфферами, некорректным проксированием и т. п.
Иногда бывает полезно воткнуться удаленно, но это уже обычно не для dev'а:
wireshark -k -i <(ssh $REMOTE "tcpdump -s 0 -U -n -w - -i $INTERFACE [filters..]")Главное чтобы в процессе не получался драконий покер против команды разработки xD
Ну и слово grooming в отоншении людей и их взаимодействия для более-менее знакомых с общечеловеческим употреблением английского обычно имеет сильно негативную коннотацию..