Есть штатная дока про включение и виды MFA
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html
Но - там ни слова про включение MFA как требование для всех. Впрочем, легко гуглится заметка их блога
Включить эту информацию, хотя бы ссылкой, они как всегда не осилили.
Если машина - часть ASG и min-max-desired настроены (1-2-1 например, важно что max=min+1, desired=min) то оно само пересоздаст инстансы. Если нужно именно этот же инстанс обновлять, без его пересоздания - надо в сторону ansible смотреть.
Также, есть секция, которая запускается при каждом старте, что-то типа bootcmd, надо доки уточнить. И есть cloud_final_modules
https://aws.amazon.com/ru/premiumsupport/knowledge-center/execute-user-data-ec2/
вот тут про bootcmd есть
https://stackoverflow.com/questions/6475374/how-do-i-make-cloud-init-startup-scripts-run-every-time-my-ec2-instance-boots
В плане, в эти блоки можно поставить ansible. Потому что userdata работает только при создании инстанса.
Если /tmp является частью раздела /, это может быть проблемой. В том числе - можно поймать майнера, как через redis, docker, так и php
https://www.sourceclear.com/vulnerability-database/security/remote-code-execution-rce/php/sid-4487
https://github.com/docker-library/redis/issues/217
В общем, читаем https://stackoverflow.com/questions/60151640/kdevtmpfsi-using-the-entire-cpu
И непосредственно по модификациям
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=816800k,mode=777,uid=0,gid=0 0 0' >> /etc/fstab
# rename or clean /tmp, create empty, then
mount /tmp
chmod go-rwx /var/tmp
chmod 1777 /tmp
Может быть актуально и для centos, и для debian
Хоть винда это не совсем в этот блог, но там есть WSL, в котором работает линух. И там - если посмотреть в /mnt то будут виндовые диски, с правами 777 на всё. Благо, есть решение - чуть покопав, узнаём что там drvfs, и можно перемонтировать нужные диски так:
sudo umont /mnt/d
sudo mount -t drvfs D: /mnt/d -o metadata,uid=1000,gid=1000,umask=22,fmask=111
это даёт 755 на папки, 644 на файлы, возможность менять атрибуты (опция metadata), и юзер - под которым мы входим (можно завести ещё юзеров и выставить нужного)
взято тут
https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/
Можно отдельные диски настраивать через fstab, правда пока не очень понятно как.
Также, тут
https://devblogs.microsoft.com/commandline/automatically-configuring-wsl/ (читать оба, про options - первый линк)
читать про otions, чтобы применить опции при старте (сразу для всех дисков).
Минимальный конфиг /etc/wsl.conf:
[automount]
options = "metadata"
Чуть посложнее
[automount]
enabled = true
root = /mnt/
options = "metadata,umask=22,fmask=11"
mountFsTab = false
Первым делом нужно в личном кабинете включить v6.
Далее, нужно проверить DUID, который должен совпасть с маком Lan1. "Особенность"==корявость v6 - тут применяют DUID - ид устройства. А оно привязано на мак 1 лана.
Теперь смотрим https://zametkit.blogspot.com/2014/04/ipv6-mikrotik-dhcp-client.html
Есть ещё такое
https://wiki.rtzra.ru/software/mikrotik/mikrotik-ipv6
PS Несколько доставляет, что запись на board.sknt.ru появилась в сентябре 2016, "и до сентября тест". И уже 4 года оно "тест".
https://habr.com/ru/company/ruvds/blog/523872/
Сама статья средней интересности, но вот комментарии - то, ради чего эта заметка и сделана.
embden
18 октября 2020 в 17:22
+9
SELinux — это позорное пятно в безопасности Linux. Стоит хотя бы упомянуть, что реализация большинства инструментов в SELinux — это хромые поделия, в которых даже сами мантейнеры SELinux с трудом разбираются (зайдите, к примеру, на их github и посмотрите код mcstransd). Кроме этого, в SELinux есть два параллельных языка для написания политик безопасности, при этом в некоторых местах у них конфликтуют даже ключевые слова (то, что в одном называется typeattribute в другом записывается typeattributeset или как-то так). Систему категорий, кстати, практически забросили и пользуются ей только для разграничения виртуальных машин, хотя потенциал был (и есть) гигантский. Добавьте к этому, что в пользовательских дистрибутивах пользователи толком не могут защититься с помощью SELinux (адекватного UI и адекватной политики до сих пор нет, большая часть бинарников имеет одинаковый контекст безопасности), то Linux уже и не кажется правильным решениям для защищенного пользовательского десктопа.
Продолжение к
https://dragonflybsd.blogspot.com/2019/02/nginx.html
https://dragonflybsd.blogspot.com/2019/03/nginx-prometheus-dashboard-grafana.html
Сам vts так и заброшен, при этом на данный момент есть 332 форка, так что проект нужен людям.
https://github.com/vozlt/nginx-module-vts/network/members
Лучше подобрать живую замену и переключиться.
Итак. Диагностика.
Запрашиваем
curl http://localhost/status/format/json
Если ответ 501 Not Implemented - или модуль не подключен, или не активирован в настройках.
То есть убеждаемся, что:
1) модуль собран и подключен
2) настройки примерно как в доке https://github.com/vozlt/nginx-module-vts#synopsis (в частности, может быть закомментирован vhost_traffic_status_zone)
Также, при наличии прометея и nginx-vts-exporter, можно запросить статистику
# curl 127.0.0.1:9913/metrics
Если вывод только такой
# HELP nginx_vts_exporter_build_info A metric with a constant '1' value labeled by version, revision, branch, and goversion from which nginx_vts_exporter was built.
# TYPE nginx_vts_exporter_build_info gauge
nginx_vts_exporter_build_info{branch="HEAD",goversion="go1.10",revision="8aa2881c7050d9b28f2312d7ce99d93458611d04",version="0.10.3"} 1
то опять же, статистика не отдаётся, при этом в его логах будет fetchHTTP failed HTTP status 501
"SMR позволяет производителям предлагать более высокую емкость без необходимости кардинального изменения базовой технологии записи."
https://habr.com/ru/post/500214/
Но - оно совершенно не дружит с рейдами, особенно zfs.
А теперь по производителям.
WD. Выделился тем, что даже в NAS сериях молча сделал SMR, от чего против него подан групповой иск. От этого wd дал задний ход и разделил NAS серию на несколько (1). Так же, у них есть Purple серия, но одна проблема - это всё 3.5", а задача - диски в сервер с 2.5" отсеками. Также стали известны заменой скорости вращения на "индекс скорости", делая диски 7200+SMR вместо 5400+CMR.
Seagate. Заявляли что их серии для NAS честные (серия IronWolf), смотрим что данная серия не существует в виде HDD для 2.5". Оно есть, но уже SSD. Далее, открываем сайт
https://www.seagate.com/ru/ru/internal-hard-drives/cmr-smr-list/
и видим что 2.5" - только SMR.
Toshiba. Сделала небольшую доку
https://toshiba.semicon-storage.com/ap-en/company/news/news-topics/2020/04/storage-20200428-1.html
И ещё полезная табличка
Как итог: если нужны диски в NAS или сервер - лучше взять SSD, ну или смотреть seagate EXOS (учитывая что оно SAS). Так будет и быстрее, и без ущербной в данном случае технологии.
https://stackoverflow.com/questions/60924254/mongodb-replicaset-is-broken-in-kubernetes
https://dba.stackexchange.com/questions/236758/mongodb-replicaset-instance-re-join-after-kubernetes-pod-restart
Хотя там и идёт как "вопросы с ошибками", их можно взять за основу.
Но остаётся ещё вопрос. Что в случае кубера, что cfn - у нас после деплоя на выходе есть N обезличенных серверов и нет механизмов, что есть mongo1 а что есть mongoN и что автоматически сборку надо запустить ровно на одной из машин, причём все ноды уже должны быть установлены (резолвиться в днс как минимум). И если запуск сборки ещё можно решить на внешних скриптах, то с именами - всё печально.
Добавляем, что при обновлении можно обновлять за раз менее половины машин, иначе кластер встанет в RO с нехваткой живых голосов, и продолжить обновление можно только после того, как все предыдушие не просто подключились в кластер, а полностью выполнили синхронизацию.
Delete existing replicaSet record in Server C using the command
shell> mongo
mongo> use local
mongo>db.system.replset.remove({});
mongo>exit
Изучаем замену для cfn - cdk (AWS Cloud Development Kit)
"это платформа разработки программного обеспечения ... используя привычные языки программирования"
И вот для быстрого старта: https://youtu.be/bz4jTx4v-l8
И пример кода
Если нам нужно выкатывать набор инстансов, то там можно указать DependsOn и сборка будет ждать готовности инстанса. Но в случае с ASG всё не так просто.
Во-первых, DependsOn на ASG - продолжит развёртывание по готовности самого ASG, но не его машин.
Во-вторых, повесить DependsOn на отдельный инстанс группы или их набор - невозможно напрямую.
В третьих, есть механизмы CreationPolicy и UpdatePolicy (которые так же нужно вешать на инстанс, чтобы стек ждал готовности ноды) и через /opt/aws/bin/cfn-signal на ASG выставлять что нода готова.
Можно сделать внешний счётчик через WaitCondition + WaitConditionHandle.
У него есть нюанс. Если в случае *Policy используется формат --resource (ASGName), то в случае WaitCondition - такой формат не работает! Мы должны применять форму cfn-signal -e 0 !Ref OurWaitCondition, ну или использовать curl. У меня ушло много времени, чтобы найти этот "особый" формат. И да, если мы используем runcmd с блоком Sub - то вместо !Ref надо использовать формат ${OurWaitCondition}.
Второй нюанс: Anytime you add a WaitCondition resource during a stack update or update a resource with a wait condition, you must associate the wait condition with a new WaitConditionHandle resource. Do not reuse an old wait condition handle that has already been defined in the template. If you reuse a wait condition handle, the wait condition might evaluate old signals from a previous create or update stack command.
И напоследок: Updates are not supported for this resource.
И ещё линки
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html
https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430
In June of 2020 we will stop allowing new domains to validate via ACMEv1.
In June of 2021 we will entirely disable ACMEv1 as a viable way to get a Let’s Encrypt certificate.
Проблема будет со старыми системами, например debian 7 - старая версия больше не работает на создание, а через год не будет работать на продление, а обновление возможно не всегда.
При этом быа ещё такая утилита dehydrated, тоже продали.
Как я понимаю, в отличие от штатного убогого, тут сразу получаем автогенерацию шаблона. В общем, можно поиграться и посмотреть. Но советую использовать такие приложения или для быстрого прототипирования, или для самообразования. Тот случай, когда разобраться в итоговом шаблоне - обязательно.
Одно но: оно платное, хотя есть Developer версия, 1 seat, 1 linked AWS account, 6 active stacks
https://harrisonmilbradt.com/blog/fixing-update_rollback_failed-in-serverless/
Actions > Continue Update Rollback и там есть пропуск сломанных шагов. Также есть консольная версия
aws cloudformation continue-update-rollback --stack-name my-stack --resources-to-skip failed-resource1 failed-resource2
Есть у амазона сервис авторизации Cognito, позволяет настроить авторизацию гугла, oauth и подобным.
Сам по себе сервис достаточно прост: сначала в User pools создаём пул юзеров, причём на старте достаточно "review defaults", потом создаем базу для вошедших юзеров - Identity.
Теперь в самом простом случае - заводим локальных пользователей, создаём группу (по доке выше) - и вот уже сервис можно использовать.
Замечание для kibana: после включения Cognito в настройках, авторизацию запрашивать не будет, нужно нажать в ES - Modify access policy и в Principal заменить * на хитрую строку, подробнее всё в той же доке выше.
Starting with rpm-4.13, RPM is able to process boolean expressions in all dependencies (Requires, Recommends, Suggests, Supplements, Enhances, Conflicts). Boolean Expressions are always enclosed with parenthesis. They are build out of “normal” dependencies: either name only or name, comparison and version description.
https://rpm.org/user_doc/boolean_dependencies.html
То есть теперь можно написать такие вещи как
Requires: (pkgA or (pkgB and pkgC))
Supplements: (foo and (lang-support-cz or lang-support-all))
и так далее. НО - это всё есть только в centos8, в 7 и ниже версии старые, в 7 например 4.11.
Если нужно поставить AD FS для AWS AD - полноценно это не сделать, потому что AWS AD не даёт юзеров с правами domain administrator.
In a default AD FS installation, AD FS uses two containers that require special AD permissions that your AWS Microsoft AD administrative account does not have. To address this, you will create two nested containers in your OU for AD FS to use. When you install AD FS, you tell AD FS where to find the containers through a Windows PowerShell parameter.
Поэтому создавать нужно через PowerShell, заглядывая в https://aws.amazon.com/jp/blogs/security/how-to-enable-your-users-to-access-office-365-with-aws-microsoft-active-directory-credentials/, выкидывая часть про azure и office, но "тело" там вполне универсально.
Для этого нужен Windows instance, введённый в домен.
backend = systemd
apt-get install rsyslog/etc/rsyslog.d/sshd.conf:
authpriv.* /var/log/auth.log
sudo softwareupdate --reset-ignored
catchError step, or manually set a build status using currentBuild.result. See the help for the catchError step for examples.# Turn off IPv6 # net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 net.ipv6.conf.eth0.disable_ipv6 = 1И перечитываем конфиг
deb http://archive.debian.org/debian wheezy main
deb http://archive.debian.org/debian-security wheezy/updates main