ServerAdmin.ru
Авторская информация о системном администрировании. Информация о рекламе: @srv_admin_reklama_bot Автор: @zeroxzed Второй канал: @srv_admin_live Сайт: serveradmin.ru
نمایش بیشتر26 428
مشترکین
+824 ساعت
+637 روز
+44330 روز
- مشترکین
- پوشش پست
- ER - نسبت تعامل
در حال بارگیری داده...
معدل نمو المشتركين
در حال بارگیری داده...
Ушла эпоха. Сервис icq завершил свою работу.
Вчера видел эту новость. Как-то даже взгрустнулось, хотя аськой активно не пользовался уже лет 10. Когда начинал работать, это был основной инструмент онлайн общения, как со знакомыми, так и по рабочим делам.
Нашёл у себя основной клиент для ICQ, которым больше всего пользовался. Это портабельная версия Miranda. Очень приятный софт был с кучей плагинов. При этом минималистичный, не жрущий ресурсы, и работающий без установки. Запустил его, работает, как и прежде, только подключиться к серверам, само собой, не может. Вся история сохранилась, с ней удобно работать. Посмотрел переписку. В 2017 году последние записи. Довольно долго у меня продержалась. В это время уже параллельно со Skype использовал. А потом полностью на Telegram перешёл.
Меня удивляет, что после Miranda была куча мессенджеров, и все они хуже её. Неужели нельзя было посмотреть и сделать нечто похожее? По удобству работы с историей переписки ничего близко нет и сейчас. Я буквально пару лет назад потушил последний сервер с Jabber, где в качестве клиента использовалась Miranda. Людей она полностью устраивала, хоть возможности как сервера, так и клиента морально устарели. Не хватало статуса прочтения сообщений, гибкой передачи и хранения файлов на сервере. Но меня в качестве админа очень устраивало такое решение, так как почти не тратило время на обслуживание. Просто всегда работало. С современными чат серверами типа Rocket.Chat или Zulip хлопот гораздо больше. А Jabber + Miranda просто работали.
История в Миранде осталась с 2008 года. Почитал немного, как в другую жизнь попал. Самая большая группа с пользователями - Lineage 😎 Ничего уже не помню из того времени. Не знаю, зачем я всё это храню. Привычка, закреплённая в генах - всё хранить. Вдруг пригодится. Я ещё прадеда застал, который всё хранил, и отец мой такой же. Наверное это полезный навык для крестьян, потомком которых я являюсь. Но сейчас это больше мешает. Хотя кто знает, как жизнь повернётся.
А вы до какого года использовали аську? Номер свой помните? У меня обычный девятизнак был. Не было нужды его где-то применять в последние года, но помню до сих пор. В памяти, похоже, на всю жизнь отложился.
#разное
👍 95👎 6
Photo unavailableShow in Telegram
В продолжение утренней темы про удалённые рабочие места. Есть интересный проект n.eko по запуску различных браузеров в Docker контейнере с доступом к нему по протоколу WebRTC.
На практике это может выглядеть так. Вы арендуете где-то VPS, ставите туда Docker и запускаете необходимый вам браузер из готового образа neko. Далее со своего рабочего места в браузере открываете этот браузер. Благодаря возможностям WebRTC всё работает быстро в том числе с передачей звука и видео. Спокойно можно смотреть ютуб или любое другое видео.
В дополнение к такому использованию, вы можете подключать к своему браузеру зрителей с возможностью смотреть, что вы там делаете. В таком режиме можно даже фильмы совместно просматривать. Есть отдельный образ с VLC плеером.
Работает это максимально просто и быстро. Создаём compose.yaml с нужным браузером:
services: neko: image: m1k1o/neko:google-chrome restart: unless-stopped shm_size: 3gb ports: - 8080:8080 - 52000-52100:52000-52100/udp cap_add: - SYS_ADMIN environment: NEKO_SCREEN: 1920x1080@30 NEKO_PASSWORD: neko NEKO_PASSWORD_ADMIN: admin NEKO_EPR: 52000-52100 NEKO_NAT1TO1: 10.20.1.36И запускаем:
# docker compose up -d
В данном примере NEKO_NAT1TO1: 10.20.1.36
- адрес сервера в локальной сети, где я запускаю neko. Если это будет VPS с внешним ip адресом, ничего указывать не надо. Адрес будет определён автоматически.
После того, как загрузится и запустится образ, можно идти по ip адресу сервера на порт 8080 и логиниться в neko.
NEKO_PASSWORD: neko
- пароль для пользователей, которые смогут только смотреть.
NEKO_PASSWORD_ADMIN: admin
- пароль для пользователя admin. То есть заходить админом вам надо будет с учёткой admin / admin.
Когда залогинитесь, снизу будет иконка клавиатуры и ползунок. Иконку надо нажать, ползунок подвинуть, чтобы заработало управление внутри контейнера. Справа вверху будут настройки разрешения экрана и некоторые другие. Рекомендую сразу снизить чувствительность скрола мышки. У меня он по умолчанию был очень чувствительный. Было некомфортно пользоваться, пока не нашёл эту настройку.
Neko можно запустить по HTTPS или через обратный прокси. В документации есть примеры настроек для этого. Для прокси удобно использовать упомянутый ранее Traefik. Для него тоже пример конфигурации представлен.
Вот, в общем-то, и всё. Можно пользоваться. С переключением раскладки проблем нет, русский ввод работает. Список готовых образов с браузерами и не только представлен в документации. Можно и обычную систему запустить с xfce, или собрать собственный образ. Есть образы под arm, отдельно с поддержкой видеокарт.
Образы регулярно автоматически обновляются, так что браузеры там свежих версий. Получается хорошее решение для гарантированной изоляции, если хочется запустить в браузере что-то сомнительное. Или просто использовать отдельный браузер с необходимыми настройками и локацией.
Подключаться к такому браузеру можно с мобильных клиентов. Интерфейс адаптирован под разрешения экранов смартфонов.
Отдельно есть проект по управлению виртуальными комнатами с запущенными браeзерами neko - neko-rooms.
⇨ Сайт / Исходники / Neko-rooms
#vdi👍 67👎 1
Photo unavailableShow in Telegram
Открытый практикум Security by Rebrain: Знакомство с Policy Engines для K8s - OPA Gatekeeper vs Kyverno
Успевайте зарегистрироваться. Количество мест строго ограничено! Запись практикума “DevOps by Rebrain” в подарок за регистрацию!
👉Регистрация
Время проведения:
27 Июня (Четверг) в 20:00 по МСК
Программа практикума:
🔹Познакомимся с Policy Engines
🔹Узнаем, для чего пишутся политики
🔹Сравним возможности OPA Gatekeeper и Kyverno
🔹Проверим работоспособность политик на практике
Кто ведёт?
Николай Панченко - Ведущий специалист по безопасности K8s, Тинькофф. 10+ лет в IT, 8+ лет в безопасности. Спикер конференций DevOpsConf, VK K8s Security, БЕкон(безопасность контейнеров), Tages Meetup.
Бесплатные практикумы по DevOps, Linux, Networks и Golang от REBRAIN каждую неделю. Подключайтесь!
Реклама. ООО "РЕБРЕИН". ИНН 7727409582 erid: 2VtzqvXvYTA
👍 3👎 3
Подписчик поделился информацией об одном любопытном проекте по созданию инфраструктуры рабочих мест на базе Kubernetes, где рабочие места поднимаются в подах. По сути это получается open source аналог Citrix Workspace. Разумеется, с большой натяжкой, так как это всего лишь небольшой бесплатный проект с открытым исходным кодом.
Речь идёт об webmesh-vdi. Основные возможности этой системы:
◽Запуск операционных систем в подах Kubernetes. Соответственно, поддерживается только то, что работает в контейнерах на Linux хосте.
◽Доступ к системам через браузер с поддержкой микрофонов и звуков, передачей файлов.
◽Поддержка MFA через zitadel.
◽Локальная аутентификация пользователей, через LDAP или OpenID.
◽Helm чарт, чтобы всё это быстро развернуть.
Запустить всё это хозяйство можно в существующем кластере Kubernetes через готовый helm chart. Если у вас его нет, а попробовать хочется, то можно запустить на k3s, развёрнутым локально как standalone kubernetes на базе одной ноды. Для этого нужна любая система с установленным docker и пакетом dialog:
# curl https://get.docker.com | bash -
# apt install dialog
# curl -JLO https://raw.githubusercontent.com/kvdi/kvdi/main/deploy/architect/kvdi-architect.sh
# bash kvdi-architect.sh
Можно ничего не настраивать, а оставить по умолчанию. После установки можно сразу скачать шаблоны ОС:
# k3s kubectl apply -f https://raw.githubusercontent.com/kvdi/kvdi/main/deploy/examples/example-desktop-templates.yaml
Установятся 3 шаблона:
▪️ ubuntu-xfce
▪️ ubuntu-kde
▪️ dosbox
На базе этих шаблонов можно создавать рабочие места. Делается это через веб интерфейс, учётка админа была показана в конце установки.
После запуска рабочего места, можно посмотреть, где и как оно запущено. Смотрим список подов кубера:
# kubectl get pod
NAME READY STATUS
prometheus-operator-8545786465-zdt97 1/1 Running
kvdi-manager-57d84fcd49-pbc6l 2/2 Running
kvdi-app-df5c78cc7-kdfrt 2/2 Running
prometheus-kvdi-prometheus-0 3/3 Running
ubuntu-kde-qqjmc 2/2 Running
Все компоненты webmesh-vdi запущены в подах, в том числе и рабочее место на базе ubuntu-kde, которое я создал из шаблона.
Интересный проект. Мне понравился своей относительной простотой и реализацией. Ниже список других упоминаемых мной проектов, на базе которых можно построить инфраструктуру vdi:
- Ravada VDI
- OpenUDS
- PVE-VDIClient
- Termidesk
Если кому любопытно, моё отношение к Kubernetes. А если вы никогда не работали с Кубером, но хотите погонять этот проект, то вот моя статья с базовым описанием команд и в целом по работе с кластером Kubernetes. Этой информации хватит, чтобы хоть немного ориентироваться в том, что там происходит.
#vdi #kuber👍 63👎 2
Файловая система ext4 при создании резервирует 5% всего объёма создаваемого раздела. Иногда это очень сильно выручает, когда система встаёт колом и нет возможности освободить место. А без этого она не может нормально работать (привет zfs и lvm-thin). Тогда можно выполнить простую операцию:
# tune2fs -m 3 /dev/mapper/root
или
# tune2fs -m 3 /dev/sda3
Вместо 5% в резерв оставляем 3%, а высвободившееся место остаётся доступным для использования. На больших разделах 5% может быть существенным объёмом. Очень хочется этот резерв сразу поставить в 0 и использовать весь доступный объём. Сделать это можно так:
# tune2fs -m 0 /dev/sda3
Сам так не делаю никогда и вам не рекомендую. Хотя бы 1% я всегда оставляю. Но чаще всего именно 3%, если уж совсем место поджимает. Меня не раз и не два выручал этот резерв.
Вторым приёмом для защиты от переполнения диска может быть использование файла подкачки в виде обычного файла в файловой системе, а не отдельного раздела. Я уже не раз упоминал, что сам всегда использую подкачку в виде обычного файла в корне, так как это позволяет гибко им управлять, как увеличивая в размере, так и ужимая, когда не хватает места.
Создаём swap размером в гигабайт и подключаем:
# dd if=/dev/zero of=/swap bs=1024 count=1000000
# mkswap /swap
# chmod 0600 /swap
# swapon /swap
Если вдруг решите, что своп вам больше не нужен, отключить его так же просто, как и подключить:
# swapoff -a
# rm /swap
Третьим вариантом страховки в случае отсутствия свободного места на разделе является заранее создание пустого файла большого объёма.
# fallocate -l 10G /big_file
При его удалении, высвобождается место, которое позволит временно вернуть работоспособность системе и выполнить необходимые действия.
Может показаться, что это какие-то умозрительные примеры. Но на деле я много раз сталкивался с тем, что кончается место на сервере по той или иной причине, и службы на нём встают. А надо, чтобы работали. Пока разберёшься, что там случилось, уходит время. Я сначала добавляю свободное место из имеющихся возможностей (swap или резерв ext4), а потом начинаю разбираться. Это даёт возможность сразу вернуть работоспособность упавшим службам, а тебе несколько минут, чтобы разобраться, в чём тут проблема. Обычно это стремительно растущие логи каких-то служб.
#linux👍 143👎 4
Photo unavailableShow in Telegram
Освойте популярные подходы к мониторингу СУБД PostgreSQL в Zabbix!
✨ Приглашаем 27 июня в 20:00 мск на бесплатный вебинар «Мониторинг PostgreSQL в Zabbix»
Вебинар является частью полноценного онлайн-курса "Observability: мониторинг, логирование, трейсинг от Отус".
➡️ Записаться на вебинар
На вебинаре мы разберем:
✅ основные метрики, за которыми нужно наблюдать;
✅ процессы, которые обеспечивают работоспособность кластера PostgreSQL;
✅ каким образом можно мониторить реплики и бэкапы данной СУБД;
✅ ответы на все возникающие вопросы.
🎙 Спикер Иван Федоров — опытный технический директор и капитан команды IBI Solutions.
Записывайтесь сейчас, а мы потом напомним. Участие бесплатно.
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
👍 10👎 7
Photo unavailableShow in Telegram
Часто доступ к веб ресурсам осуществляется не напрямую, а через обратные прокси. Причём чаще доступ именно такой, а не прямой. При возможности, я всегда ставлю обратные прокси перед сайтами даже в небольших проектах. Это и удобнее, и безопаснее, но немного более хлопотно в управлении.
Для проксирования запросов в Docker контейнеры очень удобно использовать Traefik. Удобство это в первую очередь проявляется в тестовых задачах, где часто меняется конфигурация контейнеров с приложениями, их домены, а также возникают задачи по запуску нескольких копий типовых проектов. Для прода это не так актуально, потому что он обычно более статичен в этом плане.
Сразу покажу на практике, в чём заключается удобство Traefik и в каких случаях имеет смысл им воспользоваться. Для примера запущу через Traefik 2 проекта test1 и test2, состоящих из nginx и apache и тестовой страницы, где будет указано имя проекта. В этом примере будет наглядно виден принцип работы Traefik.
Запускаем Traefik через
docker-compose.yaml
:
# mkdir traefik && cd traefik
# mcedit docker-compose.yaml
services: reverse-proxy: image: traefik:v3.0 command: --api.insecure=true --providers.docker ports: - "80:80" - "8080:8080" networks: - traefik_default volumes: - /var/run/docker.sock:/var/run/docker.sock networks: traefik_default: external: true
# docker compose upМожно сходить в веб интерфейс по ip адресу сервера на порт 8080. Пока там пусто, так как нет проектов. Создаём первый тестовый проект. Готовим для него файлы:
# mkdir test1 && cd test1
# mcedit docker-compose.yaml
services: nginx: image: nginx:latest volumes: - ./app/index.html:/app/index.html - ./default.conf:/etc/nginx/conf.d/default.conf labels: - "traefik.enable=true" - "traefik.http.routers.nginx-test1.rule=Host(`test1.server.local`)" - "traefik.http.services.nginx-test1.loadbalancer.server.port=8080" - "traefik.docker.network=traefik_default" networks: - traefik_default - test1 httpd: image: httpd:latest volumes: - ./app/index.html:/usr/local/apache2/htdocs/index.html networks: - test1 networks: traefik_default: external: true test1: internal: true
# mcedit default.conf
server {
listen 8080;
server_name _;
root /app;
index index.php index.html;
location / {
proxy_pass http://httpd:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# mcedit app/index.html
It's Container for project test1Запускаем этот проект:
# docker compose upВ веб интерфейсе Traefik, в разделе HTTP появится запись:
Host(`test1.server.local`) http nginx-test1@docker nginx-test1Он по меткам в docker-compose проекта test1 автоматом подхватил настройки и включил проксирование всех запросов к домену test1.server.local в контейнер nginx-test1. При этом сам проект test1 внутри себя взаимодействует по своей внутренней сети test1, а с Traefik по сети traefik_default, которая является внешней для приёма запросов извне. Теперь можно скопировать проект test1, изменить в нём имя домена и имя внутренней сети на test2 и запустить. Traefik автоматом подцепит этот проект и будет проксировать запросы к test2.server.local в nginx-test2. Работу этой схемы легко проверить, зайдя откуда-то извне браузером на test1.server.local и test2.server.local. Вы получите соответствующую страницу index.html от запрошенного проекта. К Traefik легко добавить автоматическое получение TLS сертификатов от Let's Encrypt. Примеров в сети и документации много, настроить не составляет проблемы. Не стал показывать этот пример, так как не уместил бы его в формат заметки. Мне важно было показать суть - запустив один раз Traefik, можно его больше не трогать. По меткам в контейнерах он будет автоматом настраивать проксирование. В некоторых ситуациях это очень удобно. #webserver #traefik #devops
👍 81👎 4
Для тех, кто пользуется Proxmox Backup Server (PBS) важное предостережение. Я им пользуюсь практически с момента релиза, но только недавно столкнулся с проблемой. Не допускайте исчерпания свободного места на сервере с бэкапами.
Я краем уха слышал, что очистка от старых данных нетривиальная штука и нельзя просто взять, удалить ненужные бэкапы и освободить занятое место. Но сам с этим не сталкивался, так как обычно место планирую с запасом и настраиваю мониторинг. Так что своевременно предпринимаю какие-то действия.
А тут проспал. Точнее, неправильно отреагировал на сложившуюся ситуацию. Были видно, что место заканчивается. Я зашёл, удалил некоторые бэкапы в ожидании увеличения свободного объёма для хранения. Была сделана копия большой виртуалки, которая тоже поехала в архив. Рассчитывал, что благодаря дедупликации, реального места будет занято не так много. Но ошибся.
То ли место не успело освободиться, то ли дедупликация в реальности сработала не так, как я ожидал, но в итоге было занято 100% доступного объёма хранилища и все процессы в нём встали. Он даже сам себя очистить не мог. Процесс Garbage Collect не запускался из-за недостатка свободного места. Я решил вопрос просто - очистил логи systemd:
# journalctl --vacuum-size=256M
Они занимали несколько гигабайт, так что мне хватило для того, чтобы отработал процесс Garbage Collect. Но он не удаляет данные, а только помечает их к удалению. Реально данные будут удалены через 24 часа и 5 минут после того, как сборщик мусора пометит их на удаление. И никакого способа вручную запустить реальную очистку хранилища нет. По крайней мере я не нашёл.
Очень внимательно прочитал несколько тем на официальном форуме по этой проблеме и везде совет один - освобождайте место или расширяйте хранилище, если у вас zfs, запускайте сборщик мусора и ждите сутки. Других вариантов нет, кроме полного удаления Datastore со всеми бэкапами. Тогда место освободится сразу.
Это особенность реализации дедупликации в PBS. Помеченные на удаления chunks реально удаляются через 24 часа. Форсировать этот процесс не получится.
#proxmox #backup👍 149👎 6
Photo unavailableShow in Telegram
🔆 Приглашаем вас на вебинар "Знакомство с MySQL InnoDB Cluster"! 🚀
🧠 Мы разберём все отличия кластерного решения InnoDB Cluster от обычной репликации. Вы узнаете, как настроить и запустить рабочий кластер, получите полное представление о возможностях и ограничениях этого решения.
👍 Наш вебинар станет находкой для системных администраторов Linux, администраторов баз данных (DBA) и всех, кто хочет познакомиться с InnoDB Cluster. Вебинар откроет новые горизонты в администрировании баз данных, позволив понять основные различия архитектуры кластера и традиционной репликации.
🏆 Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.
⏰ Занятие пройдёт 04 июля 2024 года в 19:00 по мск в рамках курса «Инфраструктура высоконагруженных систем». Доступна рассрочка на обучение!
👉 Зарегистрируйтесь для участия https://otus.pw/0vF7/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
👍 8👎 7
Я много раз упоминал в заметках, что надо стараться максимально скрывать сервисы от доступа из интернета. И проверять это, потому что часто они туда попадают случайно из-за того, что что-то забыли или неверно настроили. Решил через shodan глянуть открытые Node Exporter от Prometheus. Они часто болтаются в открытом виде, потому что по умолчанию никаких ограничений доступа в них нет. Заходи, кто хочешь, и смотри, что там есть.
И первым же IP адресом с открытым Node Exporter, на который я зашёл, оказалась чья-то нода Kubernetes. Причём для меня она сразу стала не чей-то, а я конкретно нашёл, кому она принадлежит. Мало того, что сам Node Exporter вываливает просто кучу информации в открытый доступ. Например, по volumes от контейнеров стало понятно, какие сервисы там крутятся. Видны названия lvm томов, точки монтирования, информация о разделах и дисках, биос, материнка, версия ОС, система виртуализации и т.д.
На этом же IP висел Kubernetes API. Доступа к нему не было, он отдавал 401 Unauthorized. Но по сертификату, который доступен, в Alternative Name можно найти кучу доменов и сервисов, которые засветились на этом кластере. Я не знаю, по какому принципу они туда попадают, но я их увидел. Там я нашёл сервисы n8n, vaultwarden, freshrss. Не знаю, должны ли в данном случае их веб интерфейсы быть в открытом доступе или нет, но я в окна аутентификации от этих сервисов попал.
Там же нашёл информацию о блоге судя по всему владельца этого хозяйства. Плодовитый специалист из Бахрейна. Много open source проектов, которые он развивает и поддерживает. Там же резюме его как DevOps, разработчика, SysOps. Нашёл на поддоменах и прошлую версию блога, черновики и кучу каких-то других сервисов. Не стал уже дальше ковыряться.
Ссылки и IP адреса приводить не буду, чтобы не навредить этому человеку. Скорее всего это какие-то его личные проекты, но не факт. В любом случае, вываливать в открытый доступ всю свою подноготную смысла нет. Закрыть файрволом и нет проблем. Конечно, всё это так или иначе можно собрать. История выпущенных сертификатов и dns записей хранится в открытом доступе. Но тем не менее, тут всё вообще в куче лежит прямо на активном сервере.
Для тех, кто не в курсе, поясню, что всю историю выпущенных сертификатов конкретного домена со всеми поддоменами можно посмотреть тут:
⇨ https://crt.sh
Можете себя проверить.
#devops #security
👍 93👎 2
یک طرح متفاوت انتخاب کنید
طرح فعلی شما تنها برای 5 کانال تجزیه و تحلیل را مجاز می کند. برای بیشتر، لطفا یک طرح دیگر انتخاب کنید.