Чем отличаются файлы .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-инженера в 2023 году
⚖️ 25 курсов, книг и подкастов для развития критического мышления
👀 6 способов привлечь внимание работодателя
🤖📜 Искусственный интеллект: краткая история
📰❌ 10 признаков фейковой вакансии
🔤 Азбука SQL в примерах. Часть 1. Создаем базу данных и первую таблицу
🔤 Азбука SQL в примерах. Часть 2. Ограничения, которые упрощают жизнь

📈 Обзор рынка труда в ИТ: III квартал 2023 года

В этой статье обсудим зарплату программистов в III квартале 2023 года, динамику вакансий, тенденции рынка труда в ИТ и многое другое. Присоединяйтесь!

Читать статью

Очередной #дайджест инструментов и материалов по DevOps

🔅 Менеджер логических томов (LVM) в CentOS Stream 9 — конфигурирование томов на боевой виртуалке с подробными объяснениями

🔅 Kubernetes и Kernel Panics — как Netflix’s Container Platform соединяет Linux Kernel Panics с модулями Kubernetes

🔅 Port Knocking в Mikrotik Firewall Filter — что это и как настроить на tcp портах, какие нюансы есть при использовании icmp протокола и чем может помочь данная настройка в работе сетевого инженера

🔅 Простой и удобный шаблон для bash-скриптов выполняемых по расписанию — шаблон скрипта-обёртки на bash для запуска заданий по cron и systemd timers

🔅 Резервное копирование данных — использование cp и rsync в Linux для задач резервного сохранения и восстановления данных

🌎 ТОП-10: рейтинг лучших зарубежных работодателей в IT

При составлении рейтинга учитывали различные факторы из открытых данных портала Glassdoor, включая отзывы сотрудников, уровень лояльности действующих и бывших сотрудников, зарплата, льготы, бонусы и прочие бенефиты.

1️⃣ Red Hat
2️⃣ Gainsight
3️⃣ Box
4️⃣ MathWorks
5️⃣ ServiceNow
6️⃣ Marvell Technology
7️⃣ CrowdStrike
8️⃣ Fortinet
9️⃣ NetApp
🔟 Genentech

👉 Читать статью

#memes

Сколько раз говорили, что все, пора, но так и не решались уйти в новую сферу?

🏘️ 🌰 Это база: нюансы работы с Redis

Redis — это база данных, которая размещается в памяти и хорошо подходит для следующих целей:

♦️ Кэширование данных: этот сценарий подходит когда есть ключ, по которому вы можете прочитать или записать кэш. Частый случай: использование Redis как кэша перед другой базой-крепышом, вроде MySQL.

♦️ Хранение сессий: этот сценарий подходит при росте проекта, когда мы получаем несколько инстансов приложения на разных машинах за балансировщиком и возникает потребность в хранении пользовательских сессий в хранилище, которое доступно для каждого сервера приложения.

♦️ Pub/Sub: помимо хранилища данных Redis можно использовать как брокер сообщений. В этом случае издатель может опубликовать сообщения в именованном канале для любого числа подписчиков. Когда клиент публикует сообщение в канале, Redis доставляет это сообщение всем клиентам, подписанным на этот канал, что обеспечивает обмен информацией между отдельными компонентами приложения в реальном времени.

Остальная занимательная часть вот тут

#туториал

🐶🐕 KubePug

👉 Загружает сгенерированный файл data.json, содержащий информацию об устаревании API Kubernetes
👉 Проверяет текущий кластер Kubernetes или входные файлы, проверяя, существуют ли объекты в этих устаревших версиях API, позволяя пользователю проверить перед переносом

Особенности

🔹 Может запускаться в кластере Kubernetes, используя kubeconfig или текущий кластер
🔹 Может выполняться с другим набором манифестов/файлов
🔹 Позволяет указать целевую версию Kubernetes, подлежащую проверке
🔹 Предоставляет заменяющий API, который следует использовать
🔹 Сообщает версии, что API устарел или удален, в зависимости от версии целевого кластера

Как использовать

Запустите kubectl krew install deprecations

Как использовать с Helm

Если хотите проверить сгенерированные манифесты с помощью Helm, можно запустить так:

helm template -f values.yaml .0 | kubepug --k8s-version v1.22.0 --input-file=-

Измените аргументы в kubepug (и шаблоне Helm) по своему желанию

🔥🔥 Фаервол веб-приложений для Nginx

Брандмауэр веб-приложений (WAF) — это приложение, которое отслеживает сетевой трафик на прикладном уровне.

OSI (Open Systems Interconnection) — одна из наиболее часто упоминаемых структур сетевого трафика. Когда пакет пересекает уровень 6 (представление) и перемещается на уровень 7 (прикладной), он подвергается операциям расшифровки/декодирования декодирования.

Каждая из этих операций может быть подвержена ошибочному декодированию и интерпретации, которые могут быть использованы для выхода из стандартного контекста приложения. Инъекции — это всего лишь один тип таких уязвимостей, и долгое время они были причиной беспокойства номер один, особенно потому, что традиционные устройства IDS/IPS не могут справиться с этими угрозами.

Продолжение здесь

Очередной #дайджест инструментов для проверки безопасности образов Docker

🔰 Clair — предназначен для интеграции с системами оркестровки контейнеров, такими как Kubernetes.

🔰 Trivy — поддерживает сканирование изображений на наличие уязвимостей в пакетах ОС и зависимостях приложений.

🔰 Anchore — может быть интегрирован в конвейеры CI/CD для обеспечения соблюдения политик безопасности на ранних этапах процесса разработки.

🔰 Dagda — предоставляет как интерфейс командной строки, так и REST API для интеграции в конвейеры CI/CD.

🔰 Snyk — его можно использовать для поиска уязвимостей в образах Docker и отслеживания их на предмет новых проблем.

🔰 Docker Bench Security — сам по себе это не сканер уязвимостей, но он помогает обеспечить безопасную настройку сред Docker.

🧑‍💻 Статьи для IT: как объяснять и распространять значимые идеи

Напоминаем, что у нас есть бесплатный курс для всех, кто хочет научиться интересно писать — о программировании и в целом.

Что: семь модулей, посвященных написанию, редактированию, иллюстрированию и распространению публикаций.

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

👉Материалы регулярно дополняются, обновляются и корректируются. А еще мы отвечаем на все учебные вопросы в комментариях курса.

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

Как скрыть процессы в Linux от других пользователей.

Если запустить pstree, ps, htop можно увидеть процессы не только свои, но также системные и пользовательские. В левой колонке будут имена пользователей.

Чтобы скрыть свои процессы от других пользователей, нужно перемонтировать /proc с опцией hidepid.

Работает только с пользователями, рут будет по-прежнему в курсе запущенных процессов

Параметр hidepid определяет какую информацию о процессах мы ограничим для пользователей, которые не являются владельцами этих процессов.

Параметры которые можно задать:

hidepid=0 - Включена по умолчанию, все видят всё, полный доступ к /proc/PID/.

hidepid=1 - Разрешает обращаться к информации только о своих процессов. Часть файлов в каталоге /proc/PID/ защищена.

hidepid=2 - Это тот же самый hidepid=1 + всё в /proc/PID будет невидимо для других пользователей.

Запускаем от рута:

mount -o remount,rw,nosuid,nodev,noexec,relatime,hidepid=2 /proc

Теперь снова запускаем от обычного пользователя htop и наблюдаем, что выборка процессов пропала, и осталось +- 2, bash и htop.

Естественно после ребута сервера, все это пропадет. Чтобы этого не произошло — монтируем /proc в fstab.

Вставляем в /etc/fstab

proc /proc proc defaults,nosuid, nodev, noexec,relatime,hidepid=2 0 0

Встречаются приложения которые могут отвалиться. Для этого нужно зафиксить маунт с опцией gid=VALUE.

Значением gid параметра может быть имя группы в системе, членам которой доступ к процессам будет разрешён. И затем маунтить /proc таким образом:

proc /proc proc defaults, hidepid=2, gid=bashdays 0 0

Добавляем пользователя от имени которого будет работать приложение/демон в эту группу и проверяем — если всё сделано верно, то приложение заработает как обычно.