Чем отличается su от sudo?

su «substitute user» — заменить пользователя
sudo «substitute user and do» — подменить пользователя и выполнить

su требует пароль целевой учетной записи, на кого переключаемся.
sudo требует пароль текущего пользователя и запускает от его имени команды, которым требуются права суперюзера.

Например, мы сидим под пользователем user и хотим войти под John:

user@dev:/$ su john

Будет запрошен пароль, нужно ввести пароль именно от учетной записи john, а не от user.

А вот пример с sudo:

user@dev:/$ sudo -u john whoami

А здесь нужно ввести пароль от учетной записи user, а не от John или рута. Но для этого случая сперва необходимо добавить пермишены для пользователя user в файл /etc/sudoers.

user ALL=(ALL:ALL) ALL

Редактировать этот файл можно по средствам команды visudo. А свалидировать конфиг можно командой visudo -c. Редактирование этого файла через visodu хорошо тем, что если вы допустите ошибку, то при сохранении, оно сообщит о ней.

А для чего нужен дефис после su?

Для очистки переменных и чтобы пользоваться чистой оболочкой при переключении на другого пользователя.

Авторизуемся под пользователем user и экспортируем переменную:

ssh user@pc
export a="test"

Теперь у пользователя user есть переменная "a" которая = test.

Переключаемся на пользователя John и смотрим переменную "a"

su john
echo $a

Вывелась строчка test. То есть все что мы задали под user, перекочевало в оболочку john. А теперь добавим дефис:

su - john
echo $a

Переменная $a больше не выводится. Чистая оболочка. Кстати с этим дефисом часто косячат и потом долго не могут понять в чем причина. Переменные вроде были заданы, а потом куда-то пропали.

su (с дефисом) — сначала переключается пользователь, а затем запускается shell, зачищаются все переменные.

su (без дефиса) — переключает пользователя, оставляя переменные окружения старого пользователя.

У sudo есть подобные ключи -s -i

user@pc:/$ sudo -s

Запустится оболочка с правами root

user@pc:/$ sudo -i

Запустится оболочка, но уже с чтением файлов root/.profile/.bashrc и т.п. Можно попробовать добавить экспорт переменной в .profile, сделать sudo -s/-i и увидеть что с ключом -i переменная выведется на экран.

По сути sudo -i = команде sudo su -. Но обычно за sudo su - в приличных местах можно получить по шапке. Это плохая практика! Так как это порождает дополнительный процесс и больше гемора с набором самой команды.

👉 DevOps Portal

👩‍💻 Топ-5 полезных утилит для Docker

Portainer — проект с открытым исходным кодом, представляющий собой образ графического web-интерфейса для управления Docker.

Hadolint — представляет собой утилиту, предназначенную для оценки Dockerfile с точки зрения корректности синтаксиса и безопасности инструкций.

Dozzle — представляет собой веб-интерфейс для отображения логов контейнеров в режиме реального времени.

Dive — утилита, которая визуально отображает подробную информацию о Docker образах и их слоях.

Ctop — утилита для мониторинга метрик в контейнерах, которая напоминает утилиту top в Unix системах.

👉 DevOps Portal | #ресурсы

ZRAM позволяет сжимать оперативную память на лету и таким образом увеличить ее объём.

При включении zram, сжатие переносит часть нагрузки на процессор, но использование zram действительно может улучшить производительность.

Также есть zswap, которая сжимает данные в разделе подкачки. И которая по умолчанию включена почти во всех официальных ядрах.

Проблема zswap заключается в том, что его приоритет выше чем у zram, который остается неиспользуемым. Чтобы решить эту проблему, нужно отключить zswap в ядре.

CONFIG_ZSWAP_DEFAULT_ON=N

Но чтобы применить эту опцию, нужно пересобрать ядро. Пойдем легким путем и выключим zswap через загрузчик grub.

Редактируем файл /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="zswap.enabled=0" loglevel=3 quiet "

Не забываем перегенирировать конфиг grub:

grub-mkconfig -o /boot/grub/grub.cfg

Перезагружаем машину и проверяем отключение zswap:

cat /sys/module/zswap/parameters/enabled

Если вывелась буква N — значит все правильно.

Ну и наконец включаем zram. Для этого пишем bash скрипт и кидаем его в автозагрузку:

#!/bin/bash

modprobe zram
mkdir /sys/block/zram0
echo lz4 > /sys/block/zram0/comp_algorithm
echo 1G > /sys/block/zram0/disksize
echo 2 > /sys/block/zram0/max_comp_streams
mkswap --label zram0 /dev/zram0
swapon --priority 100 /dev/zram0

1. Загружаем модуль zram
2. Выбираем алгоритм сжатия lz4 (либо zstd)
3. Объем zram 1гиг физической оперативки
4. 2 это количество потоков сжатия (потоки процессора)
5. Создаем блочное устройство и включаем его

Запускаем скрипт и проверяем включение командой: zramctl. Если на экран что-то вывелось, значит всё хорошо и сжатие начало работать.

Если заморачиваться с bash скриптами не хочется, ставим утилиту которая будет работать через systemd.

apt install systemd-zram-generator

Правим конфиг /etc/systemd/zram-generator.conf

[zram0]
zram-size = ram
compression-algorithm = lz4

Активируем и запускаем:

systemctl daemon-reload
systemctl start /dev/zram0

Всё! Теперь оно само будет запускаться без лишних движений.

👉 DevOps Portal

SecretScanner

Ищет незащищённые креды и пароли в Docker-образах, контейнерах и на ПК.

Сканирует данные, сверяя их с базой из 140 типов секретов.

Входит в состав ThreatMapper — инструмента с открытым кодом для выявления и ранжирования уязвимостей в облачных приложениях.

👉 GitHub

👉 DevOps Portal | #ресурсы

Знали ли вы про такую команду в linux как - «yes»?

Команда yes служит для вывода в стандартный поток (stdout) строки «y» или любой другой строки. Если ее запустить по умолчанию, команда будет бесконечно сыпать строку «y».

Например, есть у вас консольная команда, которая во время своей работы будет запрашивать подтверждение: а вы точно уверены, что удаляете тестовую базу данных? Вот на такие случаи и нужна команда «yes», чтобы не руками вводить подтверждение, а делегировать это действие.

Полезно для пайплайнов. Бывает такое, что у программы нет ключей типа apt -y install, а подтверждать как-то в автоматическом режиме нужно.

Синтаксис проброса стандартный, через систему пайпов:

yes | apt install nginx

В примере выше, когда пакетный менеджер попросит нажать Y, команда «yes» автоматически это сделает и начнется процесс установки.

Не забываем, про передачу аргументов, если внешняя программа например хочет чтобы вы ввели слово: «hello» делаем так:

yes hello | apt install nginx

Но обычно на практике, в 99% случаев команда «yes» запускается без аргументов, так как большинство запрашивает именно Yes.

Если есть команда «yes», значит должна быть и «no». Но увы 😁. Так вот если нужно отменить, передайте в «yes» аргументом строку «no».

Что-то может запросить простого нажатия Enter, например когда в репозиторий добавляется gpg ключ. Как послать Enter? А вот так:

yes "" | <твоя команда>

Это сработает как Enter потому, что команда «yes» выводит в stdout не просто сроку Y, но еще и завершает ее в конце символом Enter. Вот именно поэтому при запуске чистого «yes», строчки на экране будут идти столбиком.

👉 DevOps Portal

kubectx

Это инструмент командной строки, который позволяет пользователям переключаться между контекстами (кластерами) и пространствами имен Kubernetes быстрее и проще, чем с помощью одних только команд kubectl.

# switch to another cluster that's in kubeconfig
$ kubectx minikube
Switched to context «minikube».

# switch back to previous cluster
$ kubectx -
Switched to context «oregon».

# rename context
$ kubectx dublin=gke_ahmetb_europe-west1-b_dublin
Context «gke_ahmetb_europe-west1-b_dublin» renamed to «dublin».

# change the active namespace on kubectl
$ kubens kube-system
Context «test» set.
Active namespace is «kube-system».

# go back to the previous namespace
$ kubens -
Context «test» set.
Active namespace is «default».

Установка

Можно установить с помощью Krew:

kubectl krew install ctx
kubectl krew install ns

После установки инструменты будут доступны в виде kubectl ctx и kubectl ns.

Еще можно установить так:

brew install kubectx

и так:

sudo apt install kubectx

👉 DevOps Portal | #ресурсы

👩‍💻 Безопасность Kubernetes

Держите шпаргалку для защиты Kubernetes-кластеров:

— Защита компонентов
— Сетевая безопасность
— Безопасность pods и объектов
— Управление credentials и данными

👉 DevOps Portal | #ресурсы

Чем отличаются файлы .bashrc .bash_profile .profile и т.п.

Основное различие этих конфигурационных файлов заключается в том, что некоторые из них читаются только оболочками входа (login). Например, при входе в систему с другого хоста или при входе в текстовую консоль локальной unix-машины. Используются файлы .login .profile .zlogin. Зависит от того какая у вас оболочка.

Далее идут конфигурационные файлы, которые читаются «интерактивными» оболочками. То есть подключенными к терминалу или псевдотерминалу. Это файлы с именами .bashrc, .tcshrc, .zshrc и т.д.

Файл .bashrc читается только интерактивной и non-login оболочкой, поэтому большинство людей в конечном итоге инклудят в файле .bash_profile чтение файла .bashrc, например:

[[ -r ~/.bashrc ]] && . ~/.bashrc

Другие оболочки ведут себя по-другому. Например, в zsh, файл .zshrc всегда читается для интерактивной оболочки, независимо от того, является ли она login или нет.

А файл .profile, это просто сценарий входа в систему. И изначально использовался в /bin/sh. Оболочка Bash, будучи обратно совместимым с sh, будет читать .profile, если он конечно же существует.

Пример файла .profile

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc
  fi
fi

Как видим, при login’е заинклудится файл .bashrc.

В дистрибутивах семейства Debian сначала выполняется .profile, а потом уже .bash_profile. А вот в дистрибах производных от RHEL, сначала выполняется .bash_profile, а уже потом .profile. Ну вот прям каша! 

В документации bash хорошо объясняется, при каких обстоятельствах читается каждый файл. И поведение на разных машинах в целом одинаково.

Выжимка из man bash:

/bin/bash - The bash executable
/etc/profile - The systemwide initialization file, executed for login shells
/etc/bash.bashrc - The systemwide per-interactive-shell startup file
/etc/bash.bash.logout - The systemwide login shell cleanup file, executed when a login shell exits
~/.bash_profile - The personal initialization file, executed for login shells
~/.bashrc - The individual per-interactive-shell startup file
~/.bash_logout - The individual login shell cleanup file, executed when a login shell exits
~/.inputrc - Individual readline initialization file

👉 DevOps Portal

Awesome Linux Software

Ооооочень объёмный перечень приложений, ПО, инструментов и других материалов для разных дистрибутивов Linux.

👉 https://github.com/luong-komorebi/Awesome-Linux-Software

👉 DevOps Portal

Поговорим о команде enable. Она включает или отключает встроенные команды оболочки.

Отключение встроенных команды позволяет выполнить дисковую команду, имеющую то же имя, что и встроенная команда оболочки, без указания полного пути, даже если оболочка ищет встроенные команды перед дисковыми командами.

Запускаем:

bash 
type test

И видим: test is a shell builtin. То есть используется команда test встроенная в оболочку. А не та что лежит на пути в test: /usr/bin/test. Воспользуемся дисковой версией этой утилиты:

enable -n test
type test

И получим такое: test is /usr/bin/test. Получается мы сделали некое переключение. И по факту используем разные версии test.

Чтобы включить обратно встроенную команду test в оболочке, выполняем:

enable test

Можно подгрузить расширения поставляемые с оболочкой. Некие плагины, экстеншены. Для этого эти экстеншены нужно установить:

apt/yum install bash-builtins

Оно установится в папку /usr/lib/bash/. В ней будут всякие mkdir, rm, sleep и т.п. По сути это те же дисковые команды, только экстеншены для оболочки.

Для начала узнаем дисковую версию команды mkdir:

mkdir --version

mkdir (GNU coreutils) 8.32

Теперь загружаем экстеншен в оболочку:

enable -f /usr/lib/bash/mkdir mkdir
mkdir --version

Получаем такое: -bash: mkdir: --: invalid option

Теперь запускаем:

type mkdir

Видим: mkdir is a shell builtin, то есть теперь mkdir используется не системный (дисковый), а тот что подгружен в оболочку bash.

Например, мы снесли все системные бинарники и остался только bash. Через подгрузку экстеншенов можно без проблем обслуживать свою операционную систему, даже если в системе пропал mkdir и т.п.

Чтобы посмотреть что вообще подгружено в оболочку, воспользуемся командой:

lsof +fg -p $$

Получим отчет по текущему процессу, что подгружено в данный момент в оболочку и используется.

С версии 4.4 в bash появилась переменная BASH_LOADABLES_PATH, с помощью нее можно задать путь для поиска экстеншенов. Тогда при подгрузке этих модулей, не нужно будет использовать полные пути.

BASH_LOADABLES_PATH=/usr/lib/bash/
enable -f sleep sleep

👉 DevOps Portal

Руководство по командам Linux

Включает команды, сгруппированные по разделам: управление файлами, пользователями, процессами, оборудованием, сетью, сжатием данных, SSH, установкой пакетов и системной информацией.

Также содержит сочетания клавиш для работы в терминале.

Полезно 👍

👉 DevOps Portal

Как определить состояние контейнера Docker?


1️⃣Проверить статус всех контейнеров:

docker ps -a

Эта команда выводит список всех контейнеров, их идентификаторы, имена, статус и время работы. В колонке "STATUS" можно увидеть текущее состояние контейнера, например:
- Up X hours — контейнер работает.
- Exited (code) — контейнер завершил работу с определённым кодом выхода.

2️⃣ Проверить состояние конкретного контейнера:

Используйте команду docker inspect, чтобы получить подробную информацию о состоянии контейнера:

docker inspect <container_id>

Эта команда выводит всю информацию о контейнере, включая статус, ошибки, время работы и другие параметры. Для удобства можно использовать фильтрацию JSON-вывода, например:

docker inspect -f '{{.State.Status}}' <container_id>

Возможные статусы:
- running — контейнер запущен.
- exited — контейнер завершил работу.
- paused — контейнер приостановлен.
- restarting — контейнер перезапускается.

3️⃣ Проверить логи контейнера:

Чтобы увидеть последние действия контейнера, можно просмотреть его логи:

docker logs <container_id>

Это поможет понять, что происходило с контейнером, особенно если он неожиданно завершил работу.

👉 DevOps Portal

Kubetools — это тщательно подобранный список популярных инструментов для Kubernetes.

Хочу поделиться несколькими тулами, которые точно заслуживают внимания:

🔹 kubie - лично пользуюсь, удобно. Kubie - это kubectx + kubens в одной туле, в конфиге достаточно указать где искать kubeconfigs.

🔹 k9s - UI в терминале с кучей хоткеев, я раньше как-то недооценивал, то потом мне его продал Макс Витковский (кубер-шайтан из моей команды). В общем, теперь это primary cli тула в работе.

🔹 Lens - это красивая, но прожорливая приложуха. Отлично выглядит, но не более 😅 Удобно для девов, или начинающих крутить кубер. Плохо работает на большом скейле - безбожно тупит.

По ссылке ниже - ещё 100500 тулов для менеджмента, работы, аудита и анализа кубер кластера 👇
https://collabnix.github.io/kubetools/

👉 DevOps Portal

1000+ Bash скриптов для DevOps

Не всегда скрипты на Bash вообще нужны в DevOps, но иногда всё же возникает ситуация, когда нужно что-то автоматизировать, а готовых решений нет или они не подходят.
И именно в таких ситуациях может быть удобно быстро написать решение на Bash.

Так что держите эту большую подборку — это скрипты, связанные с настройкой и управлением AWS, GCP, Kubernetes, Docker, PostgreSQL, MySQL, Hive, Impala, Kafka, Hadoop, Jenkins, GitHub, GitLab, BitBucket, Azure TeamCity, Spotify, LDAP, Python и это далеко не полный список

Есть здесь даже скрипты для конфигурирования .bashrc, .vimrc, .gitconfig, .screenrc, tmux

⛓ Ссылка: тык

👉 DevOps Portal | #ресурсы

Упражнения для DevOps специалистов на GitHub

Репозиторий содержит в себе разные упражнения по:

- Linux
- DNS
- АРМ
- Go

И мноооого всего другого

⛓ Ссылка: тык

👉 DevOps Portal | #ресурсы

tailspin

Утилита, которая позволяет просматривать логи с подсветкой. Это удобно, красиво и сокращает много времени на анализ.

Но есть один минус - если привыкните, то читать логи без этой тулзы будет очень сложно 🤓

🔛 https://github.com/bensadeh/tailspin

👉 DevOps Portal | #ресурсы

Команды systemd для управления Docker

Для запуска Docker многие дистрибутивы Linux используют systemd. Для запуска сервисов используется команда systemctl. Если ее нет, следует использовать команду service.

$ sudo systemctl start docker
$ sudo service docker start

Чтобы добавить сервис в автозагрузку, либо убрать его:

$ sudo systemctl enable docker
$ sudo systemctl disable docker

Для проверки параметров запуска сервиса и их изменения:

$ sudo systemctl edit docker

Просмотра связанных с сервисом журналов:

$ journalctl -u docker

👉 DevOps Portal