Если вдруг вам хочется чего-нибудь странного, то могу вам кое-что предложить. Например, запустить контейнеры Docker в LXC контейнере Proxmox. Я изначально думал, что это так просто не сработает. Всегда запускаю контейнеры в виртуалках. Тут решил попробовать в LXC, сразу заработало.
Создаёте обычный LXC контейнер с нужными ресурсами. В параметрах через веб интерфейс необходимо установить nesting=1. Далее запускаете его и устанавливаете Docker:
Всё работает. Никаких дополнительных настроек делать не пришлось. Проверял на Proxmox VE 8.2.2. В принципе, удобно. Получается можно спокойно в LXC изолировать контейнеры и запускать их. Мне казалось, что раньше это так не работало.
#proxmox #docker
Создаёте обычный LXC контейнер с нужными ресурсами. В параметрах через веб интерфейс необходимо установить nesting=1. Далее запускаете его и устанавливаете Docker:
# apt install curl# curl https://get.docker.com | bash -# docker run --rm hello-worldHello from Docker!This message shows that your installation appears to be working correctly.Всё работает. Никаких дополнительных настроек делать не пришлось. Проверял на Proxmox VE 8.2.2. В принципе, удобно. Получается можно спокойно в LXC изолировать контейнеры и запускать их. Мне казалось, что раньше это так не работало.
#proxmox #docker
Недавно один из подписчиков, видя мои посты про прокси по ssh, посоветовал расширение для браузера SwitchyOmega. Я когда-то давно искал подобное, но ничего не нашёл, что устроило бы меня. В итоге просто использовал разные браузеры под разные прокси.
Попробовал это расширение. Оно реально удобное. Позволяет по доменам раскидывать настройки. На одни домены ходим без прокси, на другие по одним настройкам, на другие по другим. Сделано просто и удобно. Особенно понравилось, что расширение может на сайте показать, какие ресурсы не были загружены и предложить добавить их в список ресурсов, доступных через прокси. На каких-то сайтах с множеством доменов под cdn это сильно упрощает задачу для формирования списка доменов.
Я уже мельком рассказывал, как использую прокси сам. Расскажу ещё раз поподробнее. У меня есть несколько VPS, к которым я могу подключаться по SSH с пробросом портов на локальную машину. Если нужен HTTP прокси, то пробрасываю порт установленной локально на VPS privoxy, если сойдёт и SOCKS, то напрямую подключаюсь через SSH с ключом -D.
На этих VPS открыт только SSH порт с доступом откуда угодно. Сами прокси в интернет не смотрят, поэтому там нет аутентификации, не надо отдельно следить за безопасностью этих прокси. На своей рабочей машине под Windows открываю WSL, там подключаюсь по SSH примерно так:
или так:
где 1.2.3.4 и 4.3.2.1 - IP VDS, а 192.168.99.2 - IP адрес внутри WSL. В браузере в качестве прокси указываю 192.168.99.2, порт 3128. В зависимости от подключенной VPS, работает та или иная локация для доступа в интернет.
Для сёрфинга или загрузки чего-либо мне такая схема кажется наиболее простой, безопасной и удобной в качестве обслуживания. Наружу торчат только SSH порты, что безопасно. Не привлекают к себе лишнего внимания, в отличие от открытых портов прокси. При этом я имею возможность подключаться к ним откуда угодно. И не нужно использовать VPN, которые иногда могут не работать.
В SwitchyOmega можно создавать разные профили настроек, переключаться между ними вручную или автоматически.
#ssh #proxy
Попробовал это расширение. Оно реально удобное. Позволяет по доменам раскидывать настройки. На одни домены ходим без прокси, на другие по одним настройкам, на другие по другим. Сделано просто и удобно. Особенно понравилось, что расширение может на сайте показать, какие ресурсы не были загружены и предложить добавить их в список ресурсов, доступных через прокси. На каких-то сайтах с множеством доменов под cdn это сильно упрощает задачу для формирования списка доменов.
Я уже мельком рассказывал, как использую прокси сам. Расскажу ещё раз поподробнее. У меня есть несколько VPS, к которым я могу подключаться по SSH с пробросом портов на локальную машину. Если нужен HTTP прокси, то пробрасываю порт установленной локально на VPS privoxy, если сойдёт и SOCKS, то напрямую подключаюсь через SSH с ключом -D.
На этих VPS открыт только SSH порт с доступом откуда угодно. Сами прокси в интернет не смотрят, поэтому там нет аутентификации, не надо отдельно следить за безопасностью этих прокси. На своей рабочей машине под Windows открываю WSL, там подключаюсь по SSH примерно так:
# ssh -L 192.168.99.2:3128:localhost:8118 root@1.2.3.4или так:
# ssh -D 192.168.99.2:3128 root@4.3.2.1где 1.2.3.4 и 4.3.2.1 - IP VDS, а 192.168.99.2 - IP адрес внутри WSL. В браузере в качестве прокси указываю 192.168.99.2, порт 3128. В зависимости от подключенной VPS, работает та или иная локация для доступа в интернет.
Для сёрфинга или загрузки чего-либо мне такая схема кажется наиболее простой, безопасной и удобной в качестве обслуживания. Наружу торчат только SSH порты, что безопасно. Не привлекают к себе лишнего внимания, в отличие от открытых портов прокси. При этом я имею возможность подключаться к ним откуда угодно. И не нужно использовать VPN, которые иногда могут не работать.
В SwitchyOmega можно создавать разные профили настроек, переключаться между ними вручную или автоматически.
#ssh #proxy
Для нагрузочного тестирования сайтов существует популярное и удобное решение от Grafana - k6. Я уже когда-то давно рассказывал про него, но тогда не сделал акцент на том, что он удобен в том числе благодаря интеграции с Grafana через хранение метрик в Influxdb. Покажу, как это выглядит на практике.
K6 много чего умеет. Он вообще очень развитый и продвинутый инструмент, где тесты можно писать в том числе на JavaScript. Продукт позиционирует себя как Tests as code. Его легко поднять и начать тестирование, используя готовые примеры. Показываю на практике.
Поднимаем связку Grafana + Influxdb:
Там готовый docker-compose.yml. В принципе, можно ничего не менять, конфиг простой, без необходимости указания переменных. Запускаем связку:
Можно сходить, проверить графану по стандартному урлу и порту: http://server-ip:3000/login. Учётка стандартная - admin / admin. В графане уже должен быть настроен в Data sources myinfluxdb с урлом из соседнего контейнера.
Теперь нужно выбрать Dashboard. Их очень много разных для k6, выбирайте любой. Наиболее функциональный и удобный вот этот, за счёт того, что там есть группировка по тэгам, группам, урлам. Идём в Dashboards ⇨ Import ⇨ ID 13719.
Всё готово для запуска тестов. В репозитории, в директории examples очень много примеров. Эта директория мапится в контейнер с k6 в docker-compose. Тест можно запустить вот так:
Данные сразу потекут в Influxdb, так что их сразу можно наблюдать в Grafana. Тест не обязательно запускать на этой же машине. Можно из любого другого места, а передать данные через отдельный параметр. Примерно так:
Вот пример простого конфига для теста в 10 потоков в течении 30 секунд:
Соответственно, конфиг легко расширяется дополнительными урлами, тестами, выполняемыми действиями. У продукта хорошая документация и много готовых примеров. Знать JavaScript не обязательно.
⇨ Сайт / Исходники
#нагрузочное_тестирование
K6 много чего умеет. Он вообще очень развитый и продвинутый инструмент, где тесты можно писать в том числе на JavaScript. Продукт позиционирует себя как Tests as code. Его легко поднять и начать тестирование, используя готовые примеры. Показываю на практике.
Поднимаем связку Grafana + Influxdb:
# git clone https://github.com/grafana/k6 && cd k6Там готовый docker-compose.yml. В принципе, можно ничего не менять, конфиг простой, без необходимости указания переменных. Запускаем связку:
# docker compose up -d influxdb grafanaМожно сходить, проверить графану по стандартному урлу и порту: http://server-ip:3000/login. Учётка стандартная - admin / admin. В графане уже должен быть настроен в Data sources myinfluxdb с урлом из соседнего контейнера.
Теперь нужно выбрать Dashboard. Их очень много разных для k6, выбирайте любой. Наиболее функциональный и удобный вот этот, за счёт того, что там есть группировка по тэгам, группам, урлам. Идём в Dashboards ⇨ Import ⇨ ID 13719.
Всё готово для запуска тестов. В репозитории, в директории examples очень много примеров. Эта директория мапится в контейнер с k6 в docker-compose. Тест можно запустить вот так:
# docker compose run k6 run /scripts/stages.jsДанные сразу потекут в Influxdb, так что их сразу можно наблюдать в Grafana. Тест не обязательно запускать на этой же машине. Можно из любого другого места, а передать данные через отдельный параметр. Примерно так:
# k6 run --out influxdb=http://1.2.3.4:8086 stages.jsВот пример простого конфига для теста в 10 потоков в течении 30 секунд:
import http from 'k6/http';import { sleep } from 'k6';export let options = { vus: 10, duration: '30s',};export default function () { http.get('https://test.k6.io'); sleep(1);}Соответственно, конфиг легко расширяется дополнительными урлами, тестами, выполняемыми действиями. У продукта хорошая документация и много готовых примеров. Знать JavaScript не обязательно.
⇨ Сайт / Исходники
#нагрузочное_тестирование
Давно ничего не писал на отстранённые темы. Но сегодня хочу немного поделиться своими мыслями. К тому же повод соответствующий появился. Про День Победы сказать особо нечего. Поздравлять кого-то, кроме ветеранов, тех, кто вывез эту войну и принёс победу на своих плечах, не имеет смысла. Нам остаётся только чтить их память.
Я хочу напомнить, что основа всех войн - ненависть, вражда, раздор. Убери их, и войны не будет. Это фундамент. Сейчас наглядно видно, как работает технология по разжиганию вражды. Не по книгам, каким-то историям и воспоминаниям, а в реальном времени можно наблюдать, как применяют технологию. Изучать и исследовать её.
Разжигая вражду с обоих сторон, подливают масла в огонь и не дают заглохнуть любому конфликту. Стоит людям отбросить это наваждение, как выстраивается диалог. Я недавно из первых уст слышал историю от непосредственного участника, когда две враждующие стороны договариваются и предупреждают друг друга об обстрелах, либо сознательно бьют мимо цели, чтобы не убить, понимая бессмысленность этих действий. Такое возможно только, когда между людьми нет взаимной вражды и ненависти.
Сейчас трудно быть хладнокровным и не поддаваться этому мороку ненависти, которую раздувают. Причём ненависть всех против всех: против чиновников, мигрантов, иноверцев, украинцев, европейцев, американцев. С той стороны то же самое. К каждому находят ключик, чтобы максимально расширить охват. Технология стара, как мир, но, тем не менее, работает: "Разжигай, стравливай и властвуй".
Не теряйте голову, не поддавайтесь вражде, не поддерживайте фундамент текущих и будущих конфликтов. Обычным людям, особенно соседям или тем, кто живёт вместе на одной территории, нужно не враждовать, а дружить и взаимодействовать для взаимной выгоды. Вражда на руку только тем, кто наблюдает со стороны и наживается на этом.
В завершение своих слов хочу привести стихотворение про доброту, человечность и единство народов одного из своих любимых современных исполнителей и поэтов Игоря Растеряева - Дед Агван. Стих написан на основе реальной истории реального ветерана ВОВ:
▶️ Игорь Растеряев. Дед Агван.(стих)
⇨ Описание реальной истории и человека из стихотворения
📜 Текст
.......
Его уж нет, а я большой.
И вдруг я докумекал:
В тот день был самый главный бой
За звание человека.
#разное #мысли
Я хочу напомнить, что основа всех войн - ненависть, вражда, раздор. Убери их, и войны не будет. Это фундамент. Сейчас наглядно видно, как работает технология по разжиганию вражды. Не по книгам, каким-то историям и воспоминаниям, а в реальном времени можно наблюдать, как применяют технологию. Изучать и исследовать её.
Разжигая вражду с обоих сторон, подливают масла в огонь и не дают заглохнуть любому конфликту. Стоит людям отбросить это наваждение, как выстраивается диалог. Я недавно из первых уст слышал историю от непосредственного участника, когда две враждующие стороны договариваются и предупреждают друг друга об обстрелах, либо сознательно бьют мимо цели, чтобы не убить, понимая бессмысленность этих действий. Такое возможно только, когда между людьми нет взаимной вражды и ненависти.
Сейчас трудно быть хладнокровным и не поддаваться этому мороку ненависти, которую раздувают. Причём ненависть всех против всех: против чиновников, мигрантов, иноверцев, украинцев, европейцев, американцев. С той стороны то же самое. К каждому находят ключик, чтобы максимально расширить охват. Технология стара, как мир, но, тем не менее, работает: "Разжигай, стравливай и властвуй".
Не теряйте голову, не поддавайтесь вражде, не поддерживайте фундамент текущих и будущих конфликтов. Обычным людям, особенно соседям или тем, кто живёт вместе на одной территории, нужно не враждовать, а дружить и взаимодействовать для взаимной выгоды. Вражда на руку только тем, кто наблюдает со стороны и наживается на этом.
В завершение своих слов хочу привести стихотворение про доброту, человечность и единство народов одного из своих любимых современных исполнителей и поэтов Игоря Растеряева - Дед Агван. Стих написан на основе реальной истории реального ветерана ВОВ:
▶️ Игорь Растеряев. Дед Агван.(стих)
⇨ Описание реальной истории и человека из стихотворения
📜 Текст
.......
Его уж нет, а я большой.
И вдруг я докумекал:
В тот день был самый главный бой
За звание человека.
#разное #мысли
YouTube
Игорь Растеряев. Дед Агван.(стих)
Игорь Растеряев. Дед Агван.(стих) Автор текста — Игорь Растеряев. Видео оператор — Леха Ляхов. Поздравляем всех с 70-летием Великой Победы!
После праздников надо потихоньку вкатываться в трудовые будни. Чтобы это было проще сделать, можно подключить AI, коих сейчас развелось много на любой вкус. Самый популярный - ChatGPT от OpenAI. Чтобы им пользоваться, нужен VPN и иностранный номер телефона для регистрации и получения токена. Либо какой-то местный сервис, который перепродаёт доступ к OpenAI и другим платным нейросетям.
Есть возможность развернуть открытую нейросеть Ollama с какой-то популярной моделью на своём железе. Решил попробовать эту тему, так как вообще никогда с этим не сталкивался. Было интересно посмотреть, как это работает.
Моделей для нейросетей существует много. Мне было интересно попробовать помощника по консольным командам Linux. Чтобы понять, какая модель лучше для этого подойдёт, посмотрел описание проекта ShellGPT. Он изначально заточен под работу с OpenAI, но как альтернативу даёт возможность использовать локальную Ollama с моделью Mistral. По их мнению она лучше всего подходит для консольных задач.
Разворачиваю Ollama c Mistral на Linux:
Далее вы можете работать с ollama напрямую через консоль, задавая там вопросы:
либо через API:
А можно сразу настроить shell-gpt. Устанавливаем его:
Задаём первый вопрос:
Изначально shell-gpt заточен на работу с OpenAI, поэтому попросит ввести токен. Можно ввести любую строку, главное не оставлять её пустой. Получите ошибку. После этого открываете конфиг
Остальное можно не трогать. Для комфортной работы с нейросетью требуется современная видеокарта. У меня такой нет, поэтому я тестировал работу на CPU. Для этого выделил отдельный старый компьютер на базе четырёхядерного Intel Core i5-2500K 3.30GHz. Сетка работает крайне медленно.
На вопрос:
Она отвечала минут 40-50 и выдала такой ответ:
В таком режиме её использовать невозможно. Решил попробовать на другом компе, где есть хоть и старая, но видюха NVIDIA GeForce GTX 560 Ti с 2G ОЗУ. Но толку от неё не было, так как слишком старая, нет нужных инструкций. Тем не менее, там было больше оперативы, дела пошли пошустрее. Сетка на вопрос:
start nginx docker container
Ответила подробно и осмысленно минут за 15. Ответ не привожу, он очень длинный.
Решил пойти дальше и попробовать её на свободном стареньком серваке с двумя XEON E5 2643 V4. Дал виртуалке все 24 потока и 24G ОЗУ. Дело ещё бодрее пошло. Уже можно нормально пользоваться, практически в режиме реального времени стал отвечать. Время ответа напрямую зависит от длины текста запроса.
Вообще, раньше не думал, что со своими нейронками можно побаловаться на обычном железе. Причём она в целом нормально отвечала. На все мои простые вопросы по консольным командам ответила адекватно. Результаты были рабочими, хоть и не всегда оптимальными. Пример вопроса:
Если не хочется вспоминать команды и ходить в google, вполне рабочая альтернатива. Оставил на серваке Ollama, буду тестировать дальше.
#AI #chatgpt
Есть возможность развернуть открытую нейросеть Ollama с какой-то популярной моделью на своём железе. Решил попробовать эту тему, так как вообще никогда с этим не сталкивался. Было интересно посмотреть, как это работает.
Моделей для нейросетей существует много. Мне было интересно попробовать помощника по консольным командам Linux. Чтобы понять, какая модель лучше для этого подойдёт, посмотрел описание проекта ShellGPT. Он изначально заточен под работу с OpenAI, но как альтернативу даёт возможность использовать локальную Ollama с моделью Mistral. По их мнению она лучше всего подходит для консольных задач.
Разворачиваю Ollama c Mistral на Linux:
# curl https://ollama.ai/install.sh | sh# ollama pull mistral:7b-instructДалее вы можете работать с ollama напрямую через консоль, задавая там вопросы:
# ollama run mistralлибо через API:
# curl -X POST http://localhost:11434/api/generate -d '{ "model": "mistral", "prompt":"Here is a story about llamas eating grass" }'А можно сразу настроить shell-gpt. Устанавливаем его:
# apt install python3-pip# pip3 install shell-gpt[litellm]Задаём первый вопрос:
# sgpt --model ollama/mistral:7b-instruct "Who are you?"Изначально shell-gpt заточен на работу с OpenAI, поэтому попросит ввести токен. Можно ввести любую строку, главное не оставлять её пустой. Получите ошибку. После этого открываете конфиг
~/.config/shell_gpt/.sgptrc и меняете некоторые параметры:DEFAULT_MODEL=ollama/mistral:7b-instructOPENAI_USE_FUNCTIONS=falseUSE_LITELLM=trueОстальное можно не трогать. Для комфортной работы с нейросетью требуется современная видеокарта. У меня такой нет, поэтому я тестировал работу на CPU. Для этого выделил отдельный старый компьютер на базе четырёхядерного Intel Core i5-2500K 3.30GHz. Сетка работает крайне медленно.
На вопрос:
# sgpt --model ollama/mistral:7b-instruct "Who are you?"Она отвечала минут 40-50 и выдала такой ответ:
I'm ShellGPT, your Linux/Debian GNU/Linux 12 (Bookworm) programming and system administration assistant using a Bash shell. I'm here to help answer questions, provide guidance on commands, and assist with various tasks related to managing your Debian system. Let me know how I can be of service!В таком режиме её использовать невозможно. Решил попробовать на другом компе, где есть хоть и старая, но видюха NVIDIA GeForce GTX 560 Ti с 2G ОЗУ. Но толку от неё не было, так как слишком старая, нет нужных инструкций. Тем не менее, там было больше оперативы, дела пошли пошустрее. Сетка на вопрос:
start nginx docker container
Ответила подробно и осмысленно минут за 15. Ответ не привожу, он очень длинный.
Решил пойти дальше и попробовать её на свободном стареньком серваке с двумя XEON E5 2643 V4. Дал виртуалке все 24 потока и 24G ОЗУ. Дело ещё бодрее пошло. Уже можно нормально пользоваться, практически в режиме реального времени стал отвечать. Время ответа напрямую зависит от длины текста запроса.
Вообще, раньше не думал, что со своими нейронками можно побаловаться на обычном железе. Причём она в целом нормально отвечала. На все мои простые вопросы по консольным командам ответила адекватно. Результаты были рабочими, хоть и не всегда оптимальными. Пример вопроса:
# sgpt -s "start nginx web server in docker"```bashsudo systemctl start dockersudo docker pull nginx:latestsudo docker run -d --name mynginx -p 80:80 nginx:latest```Если не хочется вспоминать команды и ходить в google, вполне рабочая альтернатива. Оставил на серваке Ollama, буду тестировать дальше.
#AI #chatgpt
Я практически с самого появления проекта WSL (Windows Subsystem for Linux) на Windows стал им пользоваться. Настроек у него особо никаких нет. Просто ставишь из магазина и всё сразу работает. Используется виртуальный сетевой интерфейс, виртуальный роутер и dhcp сервер. Настроек у всего этого хозяйства нет. IP адреса системы в WSL получают постоянно динамические.
У меня это особо не вызывало проблем, потому что как сервер WSL не использую, и с основной системы обращаться туда нет необходимости. Но в какой-то момент всё равно надоело это и захотелось получить статический IP. На деле это оказалось не так просто. Каких-то инструментов или настроек для этого не существует. По крайней мере я сходу не нашёл. Правда и не сильно искал.
Решил вопрос в лоб и давно уже его использую. Добавил дополнительный IP адрес к виртуальному сетевому интерфейсу в основную систему и в систему WSL. Выглядит это следующим образом для основной системы:
и для WSL (Ubuntu):
Причём вторую команду не обязательно запускать в WSL. Можно выполнить и с хоста:
В итоге, достаточно сделать простенький bat файл, добавить его в стандартный планировщик Windows и запускать при старте системы или при логоне вашего пользователя.
Я сделал такой батник. Добавил небольшую задержу при запуске, потому что без неё иногда команды не отрабатывали. Судя по всему ещё не успевают подняться какие-то службы, необходимые для изменения настроек.
Если кто-то знает, как эту задачу решить более красиво и грамотно, поделитесь информацией. Я сделал как обычно в лоб. Решение заработало, поэтому на нём и остался. Основная машина и система в WSL видят друг друга по соответствующим адресам: 192.168.99.1 и 192.168.99.2.
#windows #wsl
У меня это особо не вызывало проблем, потому что как сервер WSL не использую, и с основной системы обращаться туда нет необходимости. Но в какой-то момент всё равно надоело это и захотелось получить статический IP. На деле это оказалось не так просто. Каких-то инструментов или настроек для этого не существует. По крайней мере я сходу не нашёл. Правда и не сильно искал.
Решил вопрос в лоб и давно уже его использую. Добавил дополнительный IP адрес к виртуальному сетевому интерфейсу в основную систему и в систему WSL. Выглядит это следующим образом для основной системы:
> netsh interface ip add address "vEthernet (WSL)" 192.168.99.1 255.255.255.0и для WSL (Ubuntu):
# ip addr add 192.168.99.2/24 broadcast 192.168.99.255 dev eth0 label eth0:1Причём вторую команду не обязательно запускать в WSL. Можно выполнить и с хоста:
> wsl.exe -u root ip addr add 192.168.99.2/24 broadcast 192.168.99.255 dev eth0 label eth0:1;В итоге, достаточно сделать простенький bat файл, добавить его в стандартный планировщик Windows и запускать при старте системы или при логоне вашего пользователя.
Я сделал такой батник. Добавил небольшую задержу при запуске, потому что без неё иногда команды не отрабатывали. Судя по всему ещё не успевают подняться какие-то службы, необходимые для изменения настроек.
@echo onTIMEOUT /T 5wsl.exe -u root ip addr add 192.168.99.2/24 broadcast 192.168.99.255 dev eth0 label eth0:1;netsh interface ip add address "vEthernet (WSL)" 192.168.99.1 255.255.255.0Если кто-то знает, как эту задачу решить более красиво и грамотно, поделитесь информацией. Я сделал как обычно в лоб. Решение заработало, поэтому на нём и остался. Основная машина и система в WSL видят друг друга по соответствующим адресам: 192.168.99.1 и 192.168.99.2.
#windows #wsl
Для управления Linux сервером через браузер существуют два наиболее популярных решения:
▪️ webmin
▪️ cockpit
Webmin очень старый продукт, написанный на Perl. Он же наиболее функциональный. Развивается до сих пор. Удивительный долгожитель. Сколько работаю с Linux, столько его знаю. Под него существует большое количество плагинов. Вся базовая функциональность сервера им покрывается: файрвол, samba, postfix и dovecot, dns и dhcp, логи, обновления и т.д. Я знал админов, которые успешно управлялись с сервером только через вебмин, не умея и не работая в консоли вообще. Удивился, когда не нашёл на своём канале отдельной заметки про эту панель. Неплохо её знаю, доводилось работать, хотя на свои сервера не устанавливал.
Cockpit более молодой проект, который принадлежит Red Hat. Ими же и развивается. Он более компактный и целостный, возможностей поменьше, чем у Webmin, но лично я бы для базовых задач отдал ему предпочтение. Но только если вам хватает его возможностей. В cockpit удобный просмотр логов, установка обновлений, выполнение базовых настроек системы — переименовать, настроить сеть, посмотреть автозагрузку, остановить или запустить какую-то службу, посмотреть таймеры systemd, отредактировать пользователя и т.д. Можно поставить и отдать сервер в управление кому-то далёкому от консоли человеку. Он сможет решать какие-то простые задачи, типа установки обновлений и настройки пользователей.
Сегодня хочу немного расширить эту тему и познакомить вас с ещё одной панелью управления сервером - Ajenti. Сразу скажу, что это проект намного меньше и проще описанных выше, но у него есть некоторые свои полезные особенности. Базовые возможности там примерно такие же, как у Cockpit без модулей. Функциональность расширяется плагинами, которые устанавливаются через веб интерфейс.
Я развернул на тестовом сервере Ajenti и внимательно посмотрел на неё. Отметил следующие полезные возможности:
◽двухфакторная аутентификация через TOTP;
◽аутентификация по сертификатам;
🔥настраиваемые дашборды с табами и виджетами, куда можно добавить запуск служб или выполнение каких-то скриптов;
◽удобный файловый менеджер;
◽есть русский язык;
◽адаптивный интерфейс, работает и на смартфонах.
Устанавливается панель просто. Есть инструкция, где описан автоматический и ручной способ установки. Панель написана на Python, так что установка через pip. Есть простой скрипт, который автоматизирует её в зависимости от используемого дистрибутива:
Скрипт определяет дистрибутив, устанавливает необходимые пакеты и панель через pip, создаёт systemd службу.
Далее можно идти по IP адресу сервера на порт 8000 и логиниться под root в панель. Сразу имеет смысл сгенерировать самоподписанный TLS сертификат, включить принудительную работу по HTTPS. Всё это в админке делается.
#linux
▪️ webmin
▪️ cockpit
Webmin очень старый продукт, написанный на Perl. Он же наиболее функциональный. Развивается до сих пор. Удивительный долгожитель. Сколько работаю с Linux, столько его знаю. Под него существует большое количество плагинов. Вся базовая функциональность сервера им покрывается: файрвол, samba, postfix и dovecot, dns и dhcp, логи, обновления и т.д. Я знал админов, которые успешно управлялись с сервером только через вебмин, не умея и не работая в консоли вообще. Удивился, когда не нашёл на своём канале отдельной заметки про эту панель. Неплохо её знаю, доводилось работать, хотя на свои сервера не устанавливал.
Cockpit более молодой проект, который принадлежит Red Hat. Ими же и развивается. Он более компактный и целостный, возможностей поменьше, чем у Webmin, но лично я бы для базовых задач отдал ему предпочтение. Но только если вам хватает его возможностей. В cockpit удобный просмотр логов, установка обновлений, выполнение базовых настроек системы — переименовать, настроить сеть, посмотреть автозагрузку, остановить или запустить какую-то службу, посмотреть таймеры systemd, отредактировать пользователя и т.д. Можно поставить и отдать сервер в управление кому-то далёкому от консоли человеку. Он сможет решать какие-то простые задачи, типа установки обновлений и настройки пользователей.
Сегодня хочу немного расширить эту тему и познакомить вас с ещё одной панелью управления сервером - Ajenti. Сразу скажу, что это проект намного меньше и проще описанных выше, но у него есть некоторые свои полезные особенности. Базовые возможности там примерно такие же, как у Cockpit без модулей. Функциональность расширяется плагинами, которые устанавливаются через веб интерфейс.
Я развернул на тестовом сервере Ajenti и внимательно посмотрел на неё. Отметил следующие полезные возможности:
◽двухфакторная аутентификация через TOTP;
◽аутентификация по сертификатам;
🔥настраиваемые дашборды с табами и виджетами, куда можно добавить запуск служб или выполнение каких-то скриптов;
◽удобный файловый менеджер;
◽есть русский язык;
◽адаптивный интерфейс, работает и на смартфонах.
Устанавливается панель просто. Есть инструкция, где описан автоматический и ручной способ установки. Панель написана на Python, так что установка через pip. Есть простой скрипт, который автоматизирует её в зависимости от используемого дистрибутива:
# curl https://raw.githubusercontent.com/ajenti/ajenti/master/scripts/install-venv.sh | bash -s -Скрипт определяет дистрибутив, устанавливает необходимые пакеты и панель через pip, создаёт systemd службу.
Далее можно идти по IP адресу сервера на порт 8000 и логиниться под root в панель. Сразу имеет смысл сгенерировать самоподписанный TLS сертификат, включить принудительную работу по HTTPS. Всё это в админке делается.
#linux
Предлагаю попробовать и забрать в закладки сервис по проверке DNS записей:
⇨ https://zonemaster.net
Я даже и не знал, что существует столько параметров, по которым можно проверить домен. Сервис полностью бесплатен, исходный код открыт. Можно развернуть у себя и делать проверки через JSON-RPC API.
Для полноценной работы нужно будет поднять Zonemaster-CLI (есть собранный Docker контейнер), Zonemaster-Backend (отвечает за API), Zonemaster-GUI (веб интерфейс). Инструкции все здесь.
Домен проверяется по 50-ти проверкам. Для теста прогнал свой домен serveradmin.ru. Набралось приличное количество ошибок и замечаний. Все они прокомментированы, так что в целом понятно, о чём там речь. Особо критичного ничего нет, а некоторые замечания относятся к DNS хостингу, на который я повлиять не могу. В качестве DNS серверов для домена у меня указаны сервера Selectel и Yandex.
Пример замечаний:
◽NS сервера Selectel не имеют PTR записей. Дублирующие их сервера Яндекса имеют. Странно, что в Selectel на это забили.
◽Разные номера SOA записей у DNS серверов. Так как я использую двух разных провайдеров, это нормально. Они должны совпадать в рамках одного провайдера.
🔥Здесь реальная ошибка нашлась. В какой-то момент NS сервера Selectel изменили свои доменные имена. И я забыл их обновить в записях Yandex. В итоге зона в Yandex имела NS сервера ns1.selectel.org и ns2.selectel.org вместо актуальных ns1.selectel.ru и ns2.selectel.ru.
◽Ещё одна небольшая ошибка была. Различались TTL у MX записей у разных провайдеров. Поправил. Параметры должны везде быть идентичными для одних и тех же записей.
В общем, сервис полезный. Рекомендую взять на вооружение и проверять свои домены. Особенно если зоны держат разные серверы и провайдеры, а записей много.
⇨ Сайт / Исходники
#dns #сервис
⇨ https://zonemaster.net
Я даже и не знал, что существует столько параметров, по которым можно проверить домен. Сервис полностью бесплатен, исходный код открыт. Можно развернуть у себя и делать проверки через JSON-RPC API.
Для полноценной работы нужно будет поднять Zonemaster-CLI (есть собранный Docker контейнер), Zonemaster-Backend (отвечает за API), Zonemaster-GUI (веб интерфейс). Инструкции все здесь.
Домен проверяется по 50-ти проверкам. Для теста прогнал свой домен serveradmin.ru. Набралось приличное количество ошибок и замечаний. Все они прокомментированы, так что в целом понятно, о чём там речь. Особо критичного ничего нет, а некоторые замечания относятся к DNS хостингу, на который я повлиять не могу. В качестве DNS серверов для домена у меня указаны сервера Selectel и Yandex.
Пример замечаний:
◽NS сервера Selectel не имеют PTR записей. Дублирующие их сервера Яндекса имеют. Странно, что в Selectel на это забили.
◽Разные номера SOA записей у DNS серверов. Так как я использую двух разных провайдеров, это нормально. Они должны совпадать в рамках одного провайдера.
🔥Здесь реальная ошибка нашлась. В какой-то момент NS сервера Selectel изменили свои доменные имена. И я забыл их обновить в записях Yandex. В итоге зона в Yandex имела NS сервера ns1.selectel.org и ns2.selectel.org вместо актуальных ns1.selectel.ru и ns2.selectel.ru.
◽Ещё одна небольшая ошибка была. Различались TTL у MX записей у разных провайдеров. Поправил. Параметры должны везде быть идентичными для одних и тех же записей.
В общем, сервис полезный. Рекомендую взять на вооружение и проверять свои домены. Особенно если зоны держат разные серверы и провайдеры, а записей много.
⇨ Сайт / Исходники
#dns #сервис
Ранее я делал шпаргалку по mtime, ctime, atime и crtime. Кто иногда путается в этих характеристиках, как я, рекомендую почитать и сохранить. Я там постарался кратко рассказать о них, чтобы не ошибаться на практике. Хотя путаться всё равно не перестал. Расскажу недавнюю историю.
Надо было периодически чистить корзину от Samba. Сама шара регулярно бэкапится, так что большого смысла в корзине нет. Сделал её больше для себя, чтобы если что, можно было быстро локально восстановить случайно удалённые файлы, а не тянуть с бэкапа. Засунул в крон простую команду по очистке:
Тип - каталог, указал, потому что если удалять только файлы, остаются пустые каталоги. Решил удалять сразу их. Плюс, там есть ещё такой момент с файлами, что они прилетают в корзину с исходным mtime, с которым они лежали на шаре. То есть файл может быть удалён сегодня, но mtime у него будет годовалой давности. Так тоже не подходит. С каталогами более подходящий вариант. Там скорее лишнее будет оставаться слишком долго, нежели свежее будет удаляться.
В какой-то момент был удалён сам каталог .trash/. Я, не вникая в суть проблемы, на автомате решил, что достаточно в корне этого каталога раз в сутки обновлять какой-нибудь файл, чтобы mtime каталога обновлялся, и скрипт его не удалял. Добавил перед удалением обновление одного и того же файла через touch:
Через некоторое время каталог .trash/ опять был удалён. Тут уже решил разобраться. Оказалось, обновление mtime файла внутри каталога недостаточно, чтобы обновился mtime самого каталога. Нужно, чтобы был удалён или добавлен какой-то файл. То есть надо файл timestamp удалить и добавить снова. Тогда mtime каталога обновится. В итоге сделал так:
Надеюсь теперь всё будет работать так, как задумано.
Такой вот небольшой нюанс, о котором я ранее не знал. Изменения mtime файла внутри каталога недостаточно для изменения mtime каталога, в котором находится этот файл. Необходимо добавить, удалить или переименовать файл или каталог внутри родительского каталога.
Если я правильно понимаю, то так происходит, потому что каталог это по сути набор информации о всех директориях и файлах внутри. Информация эта состоит из имени и номера inode. Когда я через touch дёргаю файл, его номер inode не меняется. Поэтому и родительский каталог остаётся неизменным. А если файл удалить и создать снова, даже точно такой же, то его номер inode поменяется, поэтому и mtime каталога изменяется.
Век живи - век учись. С такими вещами пока не столкнёшься, не познакомишься. Просто так со всем этим разбираться вряд ли захочется. Я вроде всю теорию по файлам, директориям и айнодам когда-то изучал, но уже всё забыл. Теория без практики мертва.
#linux
Надо было периодически чистить корзину от Samba. Сама шара регулярно бэкапится, так что большого смысла в корзине нет. Сделал её больше для себя, чтобы если что, можно было быстро локально восстановить случайно удалённые файлы, а не тянуть с бэкапа. Засунул в крон простую команду по очистке:
/usr/bin/find /mnt/shara/.trash/ -type d -mtime +7 -exec rm -rf {} \;Тип - каталог, указал, потому что если удалять только файлы, остаются пустые каталоги. Решил удалять сразу их. Плюс, там есть ещё такой момент с файлами, что они прилетают в корзину с исходным mtime, с которым они лежали на шаре. То есть файл может быть удалён сегодня, но mtime у него будет годовалой давности. Так тоже не подходит. С каталогами более подходящий вариант. Там скорее лишнее будет оставаться слишком долго, нежели свежее будет удаляться.
В какой-то момент был удалён сам каталог .trash/. Я, не вникая в суть проблемы, на автомате решил, что достаточно в корне этого каталога раз в сутки обновлять какой-нибудь файл, чтобы mtime каталога обновлялся, и скрипт его не удалял. Добавил перед удалением обновление одного и того же файла через touch:
/usr/bin/touch /mnt/shara/.trash/timestampЧерез некоторое время каталог .trash/ опять был удалён. Тут уже решил разобраться. Оказалось, обновление mtime файла внутри каталога недостаточно, чтобы обновился mtime самого каталога. Нужно, чтобы был удалён или добавлен какой-то файл. То есть надо файл timestamp удалить и добавить снова. Тогда mtime каталога обновится. В итоге сделал так:
/usr/bin/rm /mnt/shara/.trash/timestamp/usr/bin/touch /mnt/shara/.trash/timestamp/usr/bin/find /mnt/shara/.trash/ -type d -mtime +7 -exec rm -rf {} \;Надеюсь теперь всё будет работать так, как задумано.
Такой вот небольшой нюанс, о котором я ранее не знал. Изменения mtime файла внутри каталога недостаточно для изменения mtime каталога, в котором находится этот файл. Необходимо добавить, удалить или переименовать файл или каталог внутри родительского каталога.
Если я правильно понимаю, то так происходит, потому что каталог это по сути набор информации о всех директориях и файлах внутри. Информация эта состоит из имени и номера inode. Когда я через touch дёргаю файл, его номер inode не меняется. Поэтому и родительский каталог остаётся неизменным. А если файл удалить и создать снова, даже точно такой же, то его номер inode поменяется, поэтому и mtime каталога изменяется.
Век живи - век учись. С такими вещами пока не столкнёшься, не познакомишься. Просто так со всем этим разбираться вряд ли захочется. Я вроде всю теорию по файлам, директориям и айнодам когда-то изучал, но уже всё забыл. Теория без практики мертва.
#linux
Прошлая заметка про комбинацию в терминале Alt+Shift+3 получила какой-то невероятный отклик в виде лайков, хотя не делает чего-то особенного. Не ожидал такой реакции. Раз это так востребовано, расскажу ещё про одну комбинацию клавиш в bash, про которую наверняка многие не знают, но она куда более полезная на практике по сравнению с упомянутой выше.
Для тех, кто часто работает в bash, наверняка будет знакома история, когда вы что-то запустили в терминале и постоянно появляются новые строки. Вы хотите прочитать что-то, что уже ушло вверх с экрана, но из-за того, что постоянно появляются новые строки, терминал неизменно проматывается в самый низ. Бесячая ситуация, когда несколько раз пытаешься промотать вверх и не получается.
Такое возникает, например, когда ты смотришь логи в режиме реального времени:
C tail ситуация вымышленная, просто для демонстрации того, о чём идёт речь. Нет никакой проблемы прервать tail, прекратить появление новых строк, чтобы можно было спокойно промотать терминал.
Более реальная ситуация, когда ты запустил Docker контейнер не в режиме демона, он сыпет своими логами в терминал, где-то проскочила ошибка, ты хочешь к ней вернуться, скролишь, но ничего не получается, потому что появляются новые строки. А прервать выполнение ты не можешь, контейнер прекратит свою работу, если его остановить.
И тут тебе поможет комбинация Ctrl + s. Она поставит вывод в терминал на паузу. Новые строки не будут появляться, а ты спокойно сможешь проскролить экран до ошибки и прочитать её. Когда закончишь, нажмёшь Ctrl + q, и терминал продолжит работу в обычном режиме.
То же самое происходит, когда в терминале собирает Dockerfile, запускается большой docker-compose и т.д. Невозможно проскролить терминал наверх, пока процесс не завершится. Но если сделать Ctrl + s, то всё получится.
Это прям реальная тема. Я, когда узнал, очень обрадовался знанию. Сразу как-то проникся, потому что закрыл реальную проблему, которая раздражала время от времени.
#bash
Для тех, кто часто работает в bash, наверняка будет знакома история, когда вы что-то запустили в терминале и постоянно появляются новые строки. Вы хотите прочитать что-то, что уже ушло вверх с экрана, но из-за того, что постоянно появляются новые строки, терминал неизменно проматывается в самый низ. Бесячая ситуация, когда несколько раз пытаешься промотать вверх и не получается.
Такое возникает, например, когда ты смотришь логи в режиме реального времени:
# tail -f /var/log/nginx/access.logC tail ситуация вымышленная, просто для демонстрации того, о чём идёт речь. Нет никакой проблемы прервать tail, прекратить появление новых строк, чтобы можно было спокойно промотать терминал.
Более реальная ситуация, когда ты запустил Docker контейнер не в режиме демона, он сыпет своими логами в терминал, где-то проскочила ошибка, ты хочешь к ней вернуться, скролишь, но ничего не получается, потому что появляются новые строки. А прервать выполнение ты не можешь, контейнер прекратит свою работу, если его остановить.
И тут тебе поможет комбинация Ctrl + s. Она поставит вывод в терминал на паузу. Новые строки не будут появляться, а ты спокойно сможешь проскролить экран до ошибки и прочитать её. Когда закончишь, нажмёшь Ctrl + q, и терминал продолжит работу в обычном режиме.
То же самое происходит, когда в терминале собирает Dockerfile, запускается большой docker-compose и т.д. Невозможно проскролить терминал наверх, пока процесс не завершится. Но если сделать Ctrl + s, то всё получится.
Это прям реальная тема. Я, когда узнал, очень обрадовался знанию. Сразу как-то проникся, потому что закрыл реальную проблему, которая раздражала время от времени.
#bash
Максимально простой и быстрый способ перенести без остановки ОС Linux на другое железо или виртуальную машину. Не понадобится ничего, кроме встроенных средств. Проверял лично и не раз. Перед написанием этой заметки тоже проверил.
Допустим, у вас система виртуальной машины установлена на /dev/sda. Там, соответственно, будет три раздела: boot, корень и swap. Нам надо эту систему перенести куда-то в другое место. Желательно на однотипное железо, чтобы не возникло проблем. Если железо будет другое, то тоже реально, но нужно будет немного заморочиться и выполнить дополнительные действия. Заранее их все не опишешь, так как это сильно зависит от конкретной ситуации. Скорее всего придётся внутри системы что-то править (сеть, точки монтирования) и пересобрать initrd.
Создаём где-то новую виртуальную машину с таким же диском. Загружаемся с любого загрузочного диска. Например, с SystemRescue. Настраиваем в этой системе сеть, чтобы виртуальная машина, которую переносим, могла сюда подключиться. Запускаем сервер SSH. Не забываем открыть порты в файрволе. В SystemRescue он по умолчанию включен и всё закрыто на вход.
Идём на виртуалку, которую будем переносить. И делаем там простой трюк:
Мы с помощью dd читаем устройство
Процесс будет длительный, так как передача получается посекторная. Нужно понимать, что если машина большая и нагруженная, то в момент передачи целостность данных нарушается. Какую-нибудь СУБД так не перенести. Я лично не пробовал, но подозреваю, что с большой долей вероятности база будет битая. А вот обычный не сильно нагруженный сервер вполне.
После переноса он скорее всего ругнётся на ошибки файловой системы при загрузке, но сам себя починит с очень большой долей вероятности. Я как-то раз пытался так перенести виртуалку на несколько сотен гигабайт. Вот это не получилось. Содержимое судя по всему сильно билось по дороге, так как виртуалка не останавливалась. Не удалось её запустить. А что-то небольшое на 20-30 Гб вполне нормально переносится. Можно так виртуалку от какого-то хостера себе локально перенести. Главное сетевую связность между ними организовать.
Если по сети нет возможности передать образ, то можно сохранить его в файл, если есть доступный носитель:
Потом копируем образ и восстанавливаем из него систему:
Делаем всё это с какого-то загрузочного диска.
Напомню, что перенос системы можно выполнить и с помощью специально предназначенного для этого софта:
▪️ ReaR
▪️ Veeam Agent for Linux FREE
▪️ Clonezilla
#linux #backup
Допустим, у вас система виртуальной машины установлена на /dev/sda. Там, соответственно, будет три раздела: boot, корень и swap. Нам надо эту систему перенести куда-то в другое место. Желательно на однотипное железо, чтобы не возникло проблем. Если железо будет другое, то тоже реально, но нужно будет немного заморочиться и выполнить дополнительные действия. Заранее их все не опишешь, так как это сильно зависит от конкретной ситуации. Скорее всего придётся внутри системы что-то править (сеть, точки монтирования) и пересобрать initrd.
Создаём где-то новую виртуальную машину с таким же диском. Загружаемся с любого загрузочного диска. Например, с SystemRescue. Настраиваем в этой системе сеть, чтобы виртуальная машина, которую переносим, могла сюда подключиться. Запускаем сервер SSH. Не забываем открыть порты в файрволе. В SystemRescue он по умолчанию включен и всё закрыто на вход.
Идём на виртуалку, которую будем переносить. И делаем там простой трюк:
# dd if=/dev/sda | ssh root@10.20.1.28 "dd of=/dev/sda"Мы с помощью dd читаем устройство
/dev/sda и передаём его содержимое по ssh на другую машину такой же утилите dd, которая пишет информацию в устройство /dev/sda уже на другой машине. Удобство такого переноса в том, что не нужен промежуточный носитель для хранения образа. Всё передаётся налету. Процесс будет длительный, так как передача получается посекторная. Нужно понимать, что если машина большая и нагруженная, то в момент передачи целостность данных нарушается. Какую-нибудь СУБД так не перенести. Я лично не пробовал, но подозреваю, что с большой долей вероятности база будет битая. А вот обычный не сильно нагруженный сервер вполне.
После переноса он скорее всего ругнётся на ошибки файловой системы при загрузке, но сам себя починит с очень большой долей вероятности. Я как-то раз пытался так перенести виртуалку на несколько сотен гигабайт. Вот это не получилось. Содержимое судя по всему сильно билось по дороге, так как виртуалка не останавливалась. Не удалось её запустить. А что-то небольшое на 20-30 Гб вполне нормально переносится. Можно так виртуалку от какого-то хостера себе локально перенести. Главное сетевую связность между ними организовать.
Если по сети нет возможности передать образ, то можно сохранить его в файл, если есть доступный носитель:
# dd if=/dev/sda of=/mnt/backup/sda.imgПотом копируем образ и восстанавливаем из него систему:
# dd if=/mnt/backup/sda.img of=/dev/sdaДелаем всё это с какого-то загрузочного диска.
Напомню, что перенос системы можно выполнить и с помощью специально предназначенного для этого софта:
▪️ ReaR
▪️ Veeam Agent for Linux FREE
▪️ Clonezilla
#linux #backup
Для тех, кто не любит читать многостраничные man, существует его упрощённая версия, поддерживаемая сообществом — tldr. Аббревиатура как бы говорит сама за себя — Too long; didn't read. Это урезанный вариант man, где кратко представлены примеры использования консольных программ в Linux с минимальным описанием.
Для просмотра информации из tldr можно использовать консольный клиент, либо просто пользоваться веб версией. Описание каждой программы умещается в одну страницу. Авторы, судя по всему, последователи чеховского принципа: "Краткость — сестра таланта".
Вот пример выдачи для lsof:
lsof — Lists open files and the corresponding processes. Note: Root privileges (or sudo) is required to list files opened by others. More information: https://manned.org/lsof.
● Find the processes that have a given file open:
● Find the process that opened a local internet port:
● Only output the process ID (PID):
● List files opened by the given user:
● List files opened by the given command or process:
● List files opened by a specific process, given its PID:
● List open files in a directory:
● Find the process that is listening on a local IPv6 TCP port and don't convert network or port numbers:
В принципе, всё основное охватили. Кому интересно, может посмотреть мою подборку с примерами использования lsof. Я тоже люблю такие краткие выжимки с примерами. Надо будет собрать их все в одну публикацию. На канале уже много набралось по многим популярным утилитам.
Проект интересный и полезный. В закладки можно забрать и иногда пользоваться по нужде. Он похож на некоторые другие, про которые я уже писал ранее:
▪️ cheat.sh — он удобнее организован, можно информацию получать через curl сразу в консоль, без установки клиента
▪️ explainshell.com — тут немного другой принцип, на основе man выдаёт описание длинных команд с разными ключами
Отдельно упомяну сервис, который немного про другое, но тоже очень полезный. Регулярно им пользуюсь:
🔥 shellcheck.net — проверка синтаксиса shell скриптов
#linux #terminal
Для просмотра информации из tldr можно использовать консольный клиент, либо просто пользоваться веб версией. Описание каждой программы умещается в одну страницу. Авторы, судя по всему, последователи чеховского принципа: "Краткость — сестра таланта".
Вот пример выдачи для lsof:
lsof — Lists open files and the corresponding processes. Note: Root privileges (or sudo) is required to list files opened by others. More information: https://manned.org/lsof.
● Find the processes that have a given file open:
lsof path/to/file● Find the process that opened a local internet port:
lsof -i :port● Only output the process ID (PID):
lsof -t path/to/file● List files opened by the given user:
lsof -u username● List files opened by the given command or process:
lsof -c process_or_command_name● List files opened by a specific process, given its PID:
lsof -p PID● List open files in a directory:
lsof +D path/to/directory● Find the process that is listening on a local IPv6 TCP port and don't convert network or port numbers:
lsof -i6TCP:port -sTCP:LISTEN -n -PВ принципе, всё основное охватили. Кому интересно, может посмотреть мою подборку с примерами использования lsof. Я тоже люблю такие краткие выжимки с примерами. Надо будет собрать их все в одну публикацию. На канале уже много набралось по многим популярным утилитам.
Проект интересный и полезный. В закладки можно забрать и иногда пользоваться по нужде. Он похож на некоторые другие, про которые я уже писал ранее:
▪️ cheat.sh — он удобнее организован, можно информацию получать через curl сразу в консоль, без установки клиента
▪️ explainshell.com — тут немного другой принцип, на основе man выдаёт описание длинных команд с разными ключами
Отдельно упомяну сервис, который немного про другое, но тоже очень полезный. Регулярно им пользуюсь:
🔥 shellcheck.net — проверка синтаксиса shell скриптов
#linux #terminal
Существует много консольных инструментов для настройки бэкапов. Наиболее популярные и функциональные restic и borg. Сегодня я расскажу про ещё один, который я недавно внедрил на один веб сервер, так что в конце приведу полные конфиги для полноценного использования.
Речь пойдёт про старый и относительно известный инструмент nxs-backup от компании Nixys. Я знаю его давно. Если не ошибаюсь, то сначала это был просто bash скрипт, потом его упаковали в пакеты. А где-то год назад его полностью переписали и теперь это бинарник на Go.
📌 Основные возможности nxs-backup:
🔹Полные и инкрементные бэкапы на уровне файлов.
🔹Бэкапы СУБД MySQL/PostgreSQL как дампом, так и бинарные.
🔹Бэкапы MongoDB и Redis.
🔹В качестве бэкенда для передачи и хранения может использоваться: S3, SSH (SFTP), FTP, CIFS (SMB), NFS, WebDAV.
🔹Уведомления по email, Telegram, Slack или любой webhook.
Теперь отдельно расскажу, что хорошего и полезного есть конкретно в этой программе, так как список возможностей типичный для подобных программ.
➕Простые конфиги в формате yaml для заданий + одиночный бинарник. Удобно масштабировать и использовать одни и те же настройки на различных проектах. Работает одинаково без зависимостей и пересборки практически на всех Linux.
➕Из предыдущего пункта вытекает удобство использования в контейнерах. В конфиги можно передавать переменные, что упрощает настройку и позволяет не хранить секреты в конфигах. Бонусом будет очень маленький образ с самим nxs-backup, если он будет запускаться отдельно.
➕Возможность гибкой настройки логов и уведомлений. Я сделал хранение полного лога в текстовом файле локально, который легко анализировать и куда-то в общее хранилище передавать. А оповещения об ошибках и предупреждениях отдельно отправляю в Telegram.
➕Бэкап на уровне файлов делается простым tar. На базе его же возможностей организованы инкрементные бэкапы. То есть файлы хранятся в исходном виде, а восстановление возможно самостоятельно без использования nxs-backup. Кому-то это покажется минусом, но лично я больше люблю хранение в таком виде. Да, нет дедупликации, но меньше шансов получить поврежденные данные в случае каких-то проблем.
➕В едином формате конфигов описываются задания для бэкапа файлов и баз. Закрываются базовые потребности одной программой. Не надо дампить или делать бинарные бэкапы каким-то отдельным инструментом.
➕Удобно настроить одновременно локальное хранение бэкапов и отправку в S3. Я обычно это сам костылю скриптами.
➕Есть Helm чарт для использования в Kubernetes.
☝ Сразу отмечу явные минусы:
➖Нет встроенного шифрования.
➖Не очень удобно мониторить. По сути есть только логи и уведомления.
➖Документация так себе. Пришлось поковыряться, хоть в итоге всё и получилось, как задумал.
В целом, получилось неплохо. Я потратил время и создал для себя универсальные конфиги, которые буду использовать. Для интегратора или аутсорсера, кто занимается поддержкой серверов, это удобное решение. Собственно, оно для этих целей и писалось, чтобы закрыть внутренние потребности.
Установка:
Подготовка основного конфига в
⇨ nxs-backup.conf
Конфиг с заданием для бэкапа файлов
⇨ site01-files.conf
Конфиг с заданием для бэкапа БД
⇨ site01-mysql.conf
Проверяем конфигурацию:
Если есть ошибки, увидите их. Если нет, то запускаем бэкап:
У меня успешно создаётся локальный бэкап и одновременно с ним отправляется в S3 Селектела. Соответственно, политика хранения бэкапов указана. Nxs-backup будет автоматически складывать по указанной структуре бэкапы и удалять старые.
Продукт интересный. Кто занимается подобными вещами, рекомендую обратить внимание.
⇨ Сайт / Исходники
#backup
Речь пойдёт про старый и относительно известный инструмент nxs-backup от компании Nixys. Я знаю его давно. Если не ошибаюсь, то сначала это был просто bash скрипт, потом его упаковали в пакеты. А где-то год назад его полностью переписали и теперь это бинарник на Go.
📌 Основные возможности nxs-backup:
🔹Полные и инкрементные бэкапы на уровне файлов.
🔹Бэкапы СУБД MySQL/PostgreSQL как дампом, так и бинарные.
🔹Бэкапы MongoDB и Redis.
🔹В качестве бэкенда для передачи и хранения может использоваться: S3, SSH (SFTP), FTP, CIFS (SMB), NFS, WebDAV.
🔹Уведомления по email, Telegram, Slack или любой webhook.
Теперь отдельно расскажу, что хорошего и полезного есть конкретно в этой программе, так как список возможностей типичный для подобных программ.
➕Простые конфиги в формате yaml для заданий + одиночный бинарник. Удобно масштабировать и использовать одни и те же настройки на различных проектах. Работает одинаково без зависимостей и пересборки практически на всех Linux.
➕Из предыдущего пункта вытекает удобство использования в контейнерах. В конфиги можно передавать переменные, что упрощает настройку и позволяет не хранить секреты в конфигах. Бонусом будет очень маленький образ с самим nxs-backup, если он будет запускаться отдельно.
➕Возможность гибкой настройки логов и уведомлений. Я сделал хранение полного лога в текстовом файле локально, который легко анализировать и куда-то в общее хранилище передавать. А оповещения об ошибках и предупреждениях отдельно отправляю в Telegram.
➕Бэкап на уровне файлов делается простым tar. На базе его же возможностей организованы инкрементные бэкапы. То есть файлы хранятся в исходном виде, а восстановление возможно самостоятельно без использования nxs-backup. Кому-то это покажется минусом, но лично я больше люблю хранение в таком виде. Да, нет дедупликации, но меньше шансов получить поврежденные данные в случае каких-то проблем.
➕В едином формате конфигов описываются задания для бэкапа файлов и баз. Закрываются базовые потребности одной программой. Не надо дампить или делать бинарные бэкапы каким-то отдельным инструментом.
➕Удобно настроить одновременно локальное хранение бэкапов и отправку в S3. Я обычно это сам костылю скриптами.
➕Есть Helm чарт для использования в Kubernetes.
☝ Сразу отмечу явные минусы:
➖Нет встроенного шифрования.
➖Не очень удобно мониторить. По сути есть только логи и уведомления.
➖Документация так себе. Пришлось поковыряться, хоть в итоге всё и получилось, как задумал.
В целом, получилось неплохо. Я потратил время и создал для себя универсальные конфиги, которые буду использовать. Для интегратора или аутсорсера, кто занимается поддержкой серверов, это удобное решение. Собственно, оно для этих целей и писалось, чтобы закрыть внутренние потребности.
Установка:
# curl -L https://github.com/nixys/nxs-backup/releases/latest/download/nxs-backup-amd64.tar.gz -o /tmp/nxs-backup.tar.gz# tar xf /tmp/nxs-backup.tar.gz -C /tmp# mv /tmp/nxs-backup /usr/sbin/nxs-backupПодготовка основного конфига в
/etc/nxs-backup/nxs-backup.conf:⇨ nxs-backup.conf
Конфиг с заданием для бэкапа файлов
/etc/nxs-backup/conf.d/site01-files.conf:⇨ site01-files.conf
Конфиг с заданием для бэкапа БД
/etc/nxs-backup/conf.d/site01-mysql.conf:⇨ site01-mysql.conf
Проверяем конфигурацию:
# nxs-backup -tЕсли есть ошибки, увидите их. Если нет, то запускаем бэкап:
# nxs-backup start allУ меня успешно создаётся локальный бэкап и одновременно с ним отправляется в S3 Селектела. Соответственно, политика хранения бэкапов указана. Nxs-backup будет автоматически складывать по указанной структуре бэкапы и удалять старые.
Продукт интересный. Кто занимается подобными вещами, рекомендую обратить внимание.
⇨ Сайт / Исходники
#backup
▶️ Всем хороших тёплых весенних выходных. Как обычно, ниже те видео из моих подписок за последнее время, что мне показались интересными. Сегодня прям большой список получился.
⇨ HTTP в Wireshark | Компьютерные сети 2024 - 13
Очередной урок с курса по сетям от Созыкина Андрея.
⇨ 2FAuth: автономная веб-альтернатива генераторам одноразовых паролей (OTP) и установка на Synology
Интересная тема. Я раньше не слышал и не видел self-hosted решений для 2FAuth с помощью OTP. Автор разворачивает его на своём Synology.
⇨ Решаем "Тред Ариадны" | TINKOFF CTF 2024 | EASY
Очередной разбор задания от Mekan Bairyev на взлом с низкой сложностью, поэтому ролик относительно прошлых - очень короткий. Как обычно интересная тема и хорошая подача.
⇨ ВЗЛАМЫВАЕМ "Гипнолуч" | TINKOFF CTF 2024 | EASY WEB
Ещё одно относительно простое задание и ролик на 13 минут по нему. Он немного сложнее предыдущего.
⇨ Why pay for Adobe? You don't need it!
Пример установки и настройки self-hosted сервиса для работы через браузер с pdf документами Stirling-PDF. Объединение, разъединение, сжатие, вырезание страниц и вот это вот всё.
⇨ Top 5 Mini PCs for Home Server in early 2024
Обзор современных MiniPC для домашних лабораторий и не только. Некоторые из них вполне продаются в РФ. Например, вот сайт bee-link с minipc. Мне лично нравится такой формат компов для дома и офиса, если вам не нужна мощность.
⇨ Traefik 3 and FREE Wildcard Certificates with Docker
Очень подробный обзор HTTP прокси-сервера и балансировщик нагрузки Traefik. Разобраны все его особенности и удобства. Также показана настройка и реальная эксплуатация. Акцент на получении сертификатов и автоматическую настройку проксирования докер контейнеров.
⇨ Don’t run Proxmox without these settings!
Автор рассказывает о настройках Proxmox, которые он обязательно делает после установки гипервизора: обновления, уведомления, TLS сертификаты, сторейджи, бэкапы и т.д. В целом, ничего особенного. Стандартный чек-лист.
⇨ Proxmox. Templates для VM и LXC. Linked vs Full templates.
Небольшая теория и практика на тему шаблонов в Proxmox. Интересно будет тем, кто не знаком с темой.
⇨ Установка NUT в Proxmox
Пример настройки ИБП с Proxmox через NUT. Рассмотрена установка серверной части, которая корректно выключает сервер при пропадании питания и клиента к ней с веб интерфейсом. Я лично для этих целей предпочитаю apcupsd.
⇨ Настраиваем свой сервер пуш уведомлений Gotify вместе с Proxmox и Crowdsec
Установка и настройка своего сервера Gotify для отправки пуш уведомлений. Известный бесплатный self-hosted сервис с бесплатным мобильным приложением.
⇨ Diun - это вам не watchtower
Обзор программы Diun - маленькое консольное приложение, которое следит за актуальностью локальных docker images и уведомляет, когда вышло обновление. Про него будет скоро отдельная заметка.
⇨ Что такое CI/CD? // Зачем и как работает
Простыми словами о том, что такое CI/CD. Интересно будет тем, кто не знает или до конца не понимает, что это такое, как работает, как архитектурно устроено.
⇨ Экспресс обзор версии Truenas Scale 24 04 Dragonfish
Обзор очередного обновления известного файлового сервера Truenas Scale. По видео можно немного посмотреть на этот продукт изнутри для тех, кто про него не знает. Продукт функциональный с большой историей. Если не ошибаюсь, то Truenas я ставил в офис под файловый сервер с интеграцией в AD ещё лет 15 назад, когда он был на Freebsd.
#видео
⇨ HTTP в Wireshark | Компьютерные сети 2024 - 13
Очередной урок с курса по сетям от Созыкина Андрея.
⇨ 2FAuth: автономная веб-альтернатива генераторам одноразовых паролей (OTP) и установка на Synology
Интересная тема. Я раньше не слышал и не видел self-hosted решений для 2FAuth с помощью OTP. Автор разворачивает его на своём Synology.
⇨ Решаем "Тред Ариадны" | TINKOFF CTF 2024 | EASY
Очередной разбор задания от Mekan Bairyev на взлом с низкой сложностью, поэтому ролик относительно прошлых - очень короткий. Как обычно интересная тема и хорошая подача.
⇨ ВЗЛАМЫВАЕМ "Гипнолуч" | TINKOFF CTF 2024 | EASY WEB
Ещё одно относительно простое задание и ролик на 13 минут по нему. Он немного сложнее предыдущего.
⇨ Why pay for Adobe? You don't need it!
Пример установки и настройки self-hosted сервиса для работы через браузер с pdf документами Stirling-PDF. Объединение, разъединение, сжатие, вырезание страниц и вот это вот всё.
⇨ Top 5 Mini PCs for Home Server in early 2024
Обзор современных MiniPC для домашних лабораторий и не только. Некоторые из них вполне продаются в РФ. Например, вот сайт bee-link с minipc. Мне лично нравится такой формат компов для дома и офиса, если вам не нужна мощность.
⇨ Traefik 3 and FREE Wildcard Certificates with Docker
Очень подробный обзор HTTP прокси-сервера и балансировщик нагрузки Traefik. Разобраны все его особенности и удобства. Также показана настройка и реальная эксплуатация. Акцент на получении сертификатов и автоматическую настройку проксирования докер контейнеров.
⇨ Don’t run Proxmox without these settings!
Автор рассказывает о настройках Proxmox, которые он обязательно делает после установки гипервизора: обновления, уведомления, TLS сертификаты, сторейджи, бэкапы и т.д. В целом, ничего особенного. Стандартный чек-лист.
⇨ Proxmox. Templates для VM и LXC. Linked vs Full templates.
Небольшая теория и практика на тему шаблонов в Proxmox. Интересно будет тем, кто не знаком с темой.
⇨ Установка NUT в Proxmox
Пример настройки ИБП с Proxmox через NUT. Рассмотрена установка серверной части, которая корректно выключает сервер при пропадании питания и клиента к ней с веб интерфейсом. Я лично для этих целей предпочитаю apcupsd.
⇨ Настраиваем свой сервер пуш уведомлений Gotify вместе с Proxmox и Crowdsec
Установка и настройка своего сервера Gotify для отправки пуш уведомлений. Известный бесплатный self-hosted сервис с бесплатным мобильным приложением.
⇨ Diun - это вам не watchtower
Обзор программы Diun - маленькое консольное приложение, которое следит за актуальностью локальных docker images и уведомляет, когда вышло обновление. Про него будет скоро отдельная заметка.
⇨ Что такое CI/CD? // Зачем и как работает
Простыми словами о том, что такое CI/CD. Интересно будет тем, кто не знает или до конца не понимает, что это такое, как работает, как архитектурно устроено.
⇨ Экспресс обзор версии Truenas Scale 24 04 Dragonfish
Обзор очередного обновления известного файлового сервера Truenas Scale. По видео можно немного посмотреть на этот продукт изнутри для тех, кто про него не знает. Продукт функциональный с большой историей. Если не ошибаюсь, то Truenas я ставил в офис под файловый сервер с интеграцией в AD ещё лет 15 назад, когда он был на Freebsd.
#видео
YouTube
HTTP в Wireshark | Компьютерные сети 2024 - 13
Практика с разбором пакетов HTTP в Wireshark
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Текстовая версия видео - https://habr.com/ru/articles/813395/
Сайт курса…
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Текстовая версия видео - https://habr.com/ru/articles/813395/
Сайт курса…
Вакансия инженера по серверным системам и СХД в компании Work System
Всем привет. Ищем к себе в команду серверного ассасина. Ждем реального опыта взаимодействия с американскими, китайскими, российскими линейками серверов и СХД от и до. Например, знаете у кого из Минпромторга тдп указан выше фактического или что у Dell DD6400 в датащите 4 порта fc, а по факту 2.
Нужно прорабатывать решения без компромиссов. Мы не знаем про ограничения по заказным системам, так как у нас есть офисы в Китае, России и СНГ. Например, размещаем квоты на СТО оборудование на заводах HPE, Lenovo и прочих в Китае.
Среди наших клиентов Ростех, Rutube, МКБ, ВТБ и другие компании, реализованными проектами которых мы гордимся. Здесь можно ознакомиться с некоторыми проектами и отзывами.
🤖 Давай познакомимся. Заполни анкету по ссылке
Всем привет. Ищем к себе в команду серверного ассасина. Ждем реального опыта взаимодействия с американскими, китайскими, российскими линейками серверов и СХД от и до. Например, знаете у кого из Минпромторга тдп указан выше фактического или что у Dell DD6400 в датащите 4 порта fc, а по факту 2.
Нужно прорабатывать решения без компромиссов. Мы не знаем про ограничения по заказным системам, так как у нас есть офисы в Китае, России и СНГ. Например, размещаем квоты на СТО оборудование на заводах HPE, Lenovo и прочих в Китае.
Среди наших клиентов Ростех, Rutube, МКБ, ВТБ и другие компании, реализованными проектами которых мы гордимся. Здесь можно ознакомиться с некоторыми проектами и отзывами.
🤖 Давай познакомимся. Заполни анкету по ссылке
Дам несколько советов по организации структуры бэкапов на основе своего опыта. На всякий случай напомню, что у меня не обучающий канал. Я не ставлю себе цели выверить информацию, дать максимально подробно и правильно, чтобы вы смогли повторить за мной. Я делюсь своими знаниями, какие они есть. Специально к публикациям не готовлюсь, в основном пишу экспромтом.
Существуют два принципиально разных подхода к созданию бэкапов:
1️⃣ На целевые сервера с данными устанавливаются какие-то агенты единой системы или самостоятельный софт для подготовки и передачи бэкапов в какое-то хранилище. У этого подхода есть несколько плюсов.
➕ Основной - можно локально задавать политики хранения и ротации бэкапов. Не нужен какой-то единый центр управления для этого, а в качестве бэкенда хранения достаточно будет любого сетевого хранилища, куда можно просто складывать данные. Например, хранилище на базе протокола S3. Сейчас это очень распространённые хранилища.
➕ Второе преимущество - достаточно настроить только доступ к хранилищу бэкапов. К самим серверам со стороны хранения доступ настраивать не обязательно. Это актуально в сильно распределённой системе.
➖ Основной минус такого подхода - если скомпрометируют сервер, то злоумышленники могут с него уничтожить и бэкапы. Вероятность такого развития событий не такая уж и маленькая. Некоторые злоумышленники этим промышляют. Сначала каким-то образом в автоматическом режиме получают доступы к серверам, а потом уже руками туда заходят и начинают разбираться, как там всё устроено. Если получают доступ к бэкапам, то шифруют их тоже. Я знаю такие истории.
В таком режиме можно настроить бэкапы с помощью nxs-backup, restic, borg и многих других консольных программ из мира Linux. Получается максимально дёшево и эффективно.
2️⃣ Другой подход - это когда вы имеете сервер для бэкапов, который сам ходит по целевым машинам и забирает с них данные.
➖ Сразу скажу очевидный минус. Сервер бэкапов должен иметь прямой доступ к серверам с данными. Иногда это бывает хлопотно организовать. Иметь где-то во внешней площадке сервер с бэкапами, куда есть доступ у всех целевых серверов проще, чем сделать с внешней площадки доступ ко всем серверам с данными, особенно если они разрозненно находятся.
➖ Второй момент. Для такой схемы недостаточно просто купить какое-то хранилище с доступом по S3, SMB, NFS и т.д. Это должен быть полноценный сервер.
➕ Плюс тут тоже очевиден - это более безопасный способ хранения бэкапов, так как с целевых серверов нет доступа к архивам. При этом сам сервер с бэкапами на целевые сервера может иметь доступ только на чтение. Даже если он будет скомпрометирован, уничтожить исходные данные не получится. Проще всего такое хранение организовать с помощью rsync и доступа по ssh. Создаём на сервере бэкапов ключ, на серверы с данными добавляем учётку с аутентификацией по этому ключу и забираем данные по ssh. Подойдёт любой софт, который умеет забирать данные по ssh. Как я уже сказал rsync, unison, Butterfly Backup, rsnapshot, ElkarBackup, BackupPC, Burp и т.д.
Только первую схему лично я никогда не использую. Идеально их совмещать, либо использовать только вторую.
Для первой схемы есть возможность себя обезопасить. Например, можно использовать в качестве хранилища S3. В правах доступа к бакету запретить возможность удаления данных. А чтобы обеспечить ротацию архивов, настроить политику удаления старых данных средствами хранилища S3. Я активно применяю такую схему. Делаю 3 бакета: day, week, month. В первом данные хранятся 7 дней, во втором 4 недели, в третьем вечно. Получается дёшево и безопасно.
Более масштабные системы типа Veeam, PBS, Vinchin и т.д. используют оба метода - там и центральный сервер с политиками хранения, и агенты на хостах. Компрометация хостов с агентами не ведёт к потере резервных копий. Разумеется, если в самой серверной части нет уязвимостей. А они иногда бывают. В этом плане вторая схема со скрытием от посторонних глаз сервера с бэкапами наиболее безопасная.
#backup
Существуют два принципиально разных подхода к созданию бэкапов:
1️⃣ На целевые сервера с данными устанавливаются какие-то агенты единой системы или самостоятельный софт для подготовки и передачи бэкапов в какое-то хранилище. У этого подхода есть несколько плюсов.
➕ Основной - можно локально задавать политики хранения и ротации бэкапов. Не нужен какой-то единый центр управления для этого, а в качестве бэкенда хранения достаточно будет любого сетевого хранилища, куда можно просто складывать данные. Например, хранилище на базе протокола S3. Сейчас это очень распространённые хранилища.
➕ Второе преимущество - достаточно настроить только доступ к хранилищу бэкапов. К самим серверам со стороны хранения доступ настраивать не обязательно. Это актуально в сильно распределённой системе.
➖ Основной минус такого подхода - если скомпрометируют сервер, то злоумышленники могут с него уничтожить и бэкапы. Вероятность такого развития событий не такая уж и маленькая. Некоторые злоумышленники этим промышляют. Сначала каким-то образом в автоматическом режиме получают доступы к серверам, а потом уже руками туда заходят и начинают разбираться, как там всё устроено. Если получают доступ к бэкапам, то шифруют их тоже. Я знаю такие истории.
В таком режиме можно настроить бэкапы с помощью nxs-backup, restic, borg и многих других консольных программ из мира Linux. Получается максимально дёшево и эффективно.
2️⃣ Другой подход - это когда вы имеете сервер для бэкапов, который сам ходит по целевым машинам и забирает с них данные.
➖ Сразу скажу очевидный минус. Сервер бэкапов должен иметь прямой доступ к серверам с данными. Иногда это бывает хлопотно организовать. Иметь где-то во внешней площадке сервер с бэкапами, куда есть доступ у всех целевых серверов проще, чем сделать с внешней площадки доступ ко всем серверам с данными, особенно если они разрозненно находятся.
➖ Второй момент. Для такой схемы недостаточно просто купить какое-то хранилище с доступом по S3, SMB, NFS и т.д. Это должен быть полноценный сервер.
➕ Плюс тут тоже очевиден - это более безопасный способ хранения бэкапов, так как с целевых серверов нет доступа к архивам. При этом сам сервер с бэкапами на целевые сервера может иметь доступ только на чтение. Даже если он будет скомпрометирован, уничтожить исходные данные не получится. Проще всего такое хранение организовать с помощью rsync и доступа по ssh. Создаём на сервере бэкапов ключ, на серверы с данными добавляем учётку с аутентификацией по этому ключу и забираем данные по ssh. Подойдёт любой софт, который умеет забирать данные по ssh. Как я уже сказал rsync, unison, Butterfly Backup, rsnapshot, ElkarBackup, BackupPC, Burp и т.д.
Только первую схему лично я никогда не использую. Идеально их совмещать, либо использовать только вторую.
Для первой схемы есть возможность себя обезопасить. Например, можно использовать в качестве хранилища S3. В правах доступа к бакету запретить возможность удаления данных. А чтобы обеспечить ротацию архивов, настроить политику удаления старых данных средствами хранилища S3. Я активно применяю такую схему. Делаю 3 бакета: day, week, month. В первом данные хранятся 7 дней, во втором 4 недели, в третьем вечно. Получается дёшево и безопасно.
Более масштабные системы типа Veeam, PBS, Vinchin и т.д. используют оба метода - там и центральный сервер с политиками хранения, и агенты на хостах. Компрометация хостов с агентами не ведёт к потере резервных копий. Разумеется, если в самой серверной части нет уязвимостей. А они иногда бывают. В этом плане вторая схема со скрытием от посторонних глаз сервера с бэкапами наиболее безопасная.
#backup
Продолжу тему про бэкапы. Бэкап может считаться полноценным, когда он не только сделан и сохранён в нескольких местах, но и успешно восстановлен. Помимо технических моментов, важно учесть и юридические. Сразу остановлюсь на этом моменте.
1️⃣ Нельзя все бэкапы хранить у одного хостера или юридического лица, даже если они географически разнесены. Кажется, что вероятность проблем по этой части не очень велика. На деле я сталкивался с подобным не раз. То собственники делят или захватывают бизнес и вырубают вообще всю инфраструктуру, то по ошибке блокируют учётную запись и невозможно продлить услугу, то ещё что-нибудь. Это важный момент. На него надо обращать внимание.
2️⃣ Большая тема про восстановление. Я на практике знаю, что мало кто реально восстанавливается на постоянной основе из бэкапов и проверяет их. Может в большом бизнесе так где-то и делают, но в малом и среднем почти никогда. Надо понимать, что это стоит денег в виде рабочих часов специалистов и железа под это дело, зачастую в том же объёме, что и рабочий прод. Если оно арендное, то расходы ещё более заметны.
В этом плане мне очень нравится софт от Veeam. Из-за него я долго пользовался HyperV и очень жду, когда он заработает под KVM. Veeam, помимо непосредственно бэкапов, предлагает готовые инструменты для их проверок. База, которую я старался делать всегда - автоматическое ежедневное разворачивание образов виртуалок на запасных серверах. Только когда это реализовано, я могу спать спокойно и быть уверенным, что всё в порядке. И обязательно каждый день отчёт на почту с информацией о бэкапах и восстановлении. Читаю их глазами и проверяю, если что-то не так.
Этот подход даёт много плюсов. Во-первых, бэкапы реально восстанавливаются. Во-вторых, у вас всегда под рукой копия вашего прода не в виде сырых данных, а работающих систем, в том числе связанных между собой сетью. Там есть отдельное решение для работы сети без изменений в системах и доступа к ним. Я иногда их использую, чтобы просто что-то проверить на копии системы. Под это дело обычно использую старые сервера, с которых уехал прод на новые. В случае проблем можно оперативно переключиться на запасной сервер.
Если нет Veeam, то восстановление и проверка реализуются скриптами и костылями по месту в зависимости от обстоятельств. У меня были и статьи, и заметки по этим темам, но всё уже устарело и не обновлялось, поэтому не привожу.
3️⃣ Отдельно отмечу момент со скоростью восстановления. Если не делать восстановление, то невозможно наверняка знать, сколько этот процесс будет длиться. Бэкапы на удалённой площадке могут восстанавливаться и неделю, и две. Они идут по ночам инкрементами и скорости хватает. А полное восстановление может длиться сутками. Это может оказаться неприемлемым.
У меня была такая площадка с большим объёмом данных. Был согласованный план - если что случается, едет водитель и забирает сервер, куда все бэкапы восстанавливаются каждый день. Это были полные бэкапы систем, чтобы можно было взять, привезти сервер и запустить. Важно это проработать.
Когда дело доходит до бэкапов, ситуация хреновая. Это стресс. Если только данные под рукой, то нужно оперативно решать кучу моментов с восстановлением и настройкой систем. Я этим тоже занимался и могу сказать, что лучше не заниматься. Стараюсь, чтобы системы были. Не всегда получается организовать полностью бэкап виртуалок. Тогда делаю системные диски небольшими, бэкаплю их. А сырые данные отдельно.
Знакомый рассказывал историю, когда держал большой объём данных на каком-то очень дешёвом хранилище AWS. А когда нужно было восстановить оттуда данные, оказалось, что быстро это сделать невозможно. И денег стоит совсем других, не как хранение.
4️⃣ Не давайте никому без особой надобности доступ к бэкапам. Особенно каким-то подрядчикам или новым сотрудникам. У меня иногда просят, но тут я непреклонен. Никому не даю, только если руководитель или собственник распорядится. Но ни разу никто после моих доводов не давал таких распоряжений.
#backup
1️⃣ Нельзя все бэкапы хранить у одного хостера или юридического лица, даже если они географически разнесены. Кажется, что вероятность проблем по этой части не очень велика. На деле я сталкивался с подобным не раз. То собственники делят или захватывают бизнес и вырубают вообще всю инфраструктуру, то по ошибке блокируют учётную запись и невозможно продлить услугу, то ещё что-нибудь. Это важный момент. На него надо обращать внимание.
2️⃣ Большая тема про восстановление. Я на практике знаю, что мало кто реально восстанавливается на постоянной основе из бэкапов и проверяет их. Может в большом бизнесе так где-то и делают, но в малом и среднем почти никогда. Надо понимать, что это стоит денег в виде рабочих часов специалистов и железа под это дело, зачастую в том же объёме, что и рабочий прод. Если оно арендное, то расходы ещё более заметны.
В этом плане мне очень нравится софт от Veeam. Из-за него я долго пользовался HyperV и очень жду, когда он заработает под KVM. Veeam, помимо непосредственно бэкапов, предлагает готовые инструменты для их проверок. База, которую я старался делать всегда - автоматическое ежедневное разворачивание образов виртуалок на запасных серверах. Только когда это реализовано, я могу спать спокойно и быть уверенным, что всё в порядке. И обязательно каждый день отчёт на почту с информацией о бэкапах и восстановлении. Читаю их глазами и проверяю, если что-то не так.
Этот подход даёт много плюсов. Во-первых, бэкапы реально восстанавливаются. Во-вторых, у вас всегда под рукой копия вашего прода не в виде сырых данных, а работающих систем, в том числе связанных между собой сетью. Там есть отдельное решение для работы сети без изменений в системах и доступа к ним. Я иногда их использую, чтобы просто что-то проверить на копии системы. Под это дело обычно использую старые сервера, с которых уехал прод на новые. В случае проблем можно оперативно переключиться на запасной сервер.
Если нет Veeam, то восстановление и проверка реализуются скриптами и костылями по месту в зависимости от обстоятельств. У меня были и статьи, и заметки по этим темам, но всё уже устарело и не обновлялось, поэтому не привожу.
3️⃣ Отдельно отмечу момент со скоростью восстановления. Если не делать восстановление, то невозможно наверняка знать, сколько этот процесс будет длиться. Бэкапы на удалённой площадке могут восстанавливаться и неделю, и две. Они идут по ночам инкрементами и скорости хватает. А полное восстановление может длиться сутками. Это может оказаться неприемлемым.
У меня была такая площадка с большим объёмом данных. Был согласованный план - если что случается, едет водитель и забирает сервер, куда все бэкапы восстанавливаются каждый день. Это были полные бэкапы систем, чтобы можно было взять, привезти сервер и запустить. Важно это проработать.
Когда дело доходит до бэкапов, ситуация хреновая. Это стресс. Если только данные под рукой, то нужно оперативно решать кучу моментов с восстановлением и настройкой систем. Я этим тоже занимался и могу сказать, что лучше не заниматься. Стараюсь, чтобы системы были. Не всегда получается организовать полностью бэкап виртуалок. Тогда делаю системные диски небольшими, бэкаплю их. А сырые данные отдельно.
Знакомый рассказывал историю, когда держал большой объём данных на каком-то очень дешёвом хранилище AWS. А когда нужно было восстановить оттуда данные, оказалось, что быстро это сделать невозможно. И денег стоит совсем других, не как хранение.
4️⃣ Не давайте никому без особой надобности доступ к бэкапам. Особенно каким-то подрядчикам или новым сотрудникам. У меня иногда просят, но тут я непреклонен. Никому не даю, только если руководитель или собственник распорядится. Но ни разу никто после моих доводов не давал таких распоряжений.
#backup
Недавно посмотрел видео про Diun (Docker Image Update Notifier). Это маленькая консольная утилита, которая делает одно простое действие - проверяет наличие обновлений для образов запущенных контейнеров на хосте. Если обновление есть, уведомляет через email, telegram, gotify, slack и другие каналы. Больше ничего не делает, не качает обновление, не применяет, не перезапускает образ.
Diun состоит из одного бинарника. Запустить можно как на хосте, создав службу systemd, так и в контейнере, прокинув туда docker.sock. Процесс описан в документации:
Конфигурацию можно передать либо через переменные, либо через конфигурационный файл. Примеры обоих способов тоже есть в документации.
Diun умеет следить за актуальностью образов запущенных Docker контейнеров, образов подов в Kubernetes, Swarm, Nomad. Также можно настроить наблюдение за образами, используемыми в определённых Dockerfiles или конфигурационных файлах yaml, где указаны образы.
Простая, маленькая, удобная утилита. Описание установки, настройки, работы:
▶️ Diun - это вам не watchtower
⇨ Сайт / Исходники
#docker #devops
Diun состоит из одного бинарника. Запустить можно как на хосте, создав службу systemd, так и в контейнере, прокинув туда docker.sock. Процесс описан в документации:
# docker run -d --name diun \ -e "TZ=Europe/Moscow" \ -e "DIUN_WATCH_WORKERS=20" \ -e "DIUN_WATCH_SCHEDULE=0 */6 * * *" \ -e "DIUN_WATCH_JITTER=30s" \ -e "DIUN_PROVIDERS_DOCKER=true" \ -e "DIUN_NOTIF_TELEGRAM_TOKEN=1493678911:AAHtETAKqxUH8ZpyC28R-wxKfvH8WR6-vdNw" \ -e "DIUN_NOTIF_TELEGRAM_CHATIDS=211805263" \ -v "$PWD/data:/data" \ -v "/var/run/docker.sock:/var/run/docker.sock" \ -l "diun.enable=true" \ crazymax/diun:latestКонфигурацию можно передать либо через переменные, либо через конфигурационный файл. Примеры обоих способов тоже есть в документации.
Diun умеет следить за актуальностью образов запущенных Docker контейнеров, образов подов в Kubernetes, Swarm, Nomad. Также можно настроить наблюдение за образами, используемыми в определённых Dockerfiles или конфигурационных файлах yaml, где указаны образы.
Простая, маленькая, удобная утилита. Описание установки, настройки, работы:
▶️ Diun - это вам не watchtower
⇨ Сайт / Исходники
#docker #devops
Для управления веб сервером есть множество готовых веб панелей. Основная проблема их использования - дополнительный вектор атаки сервера через эту веб панель. Причём, случается это довольно часто. В идеале, доступ к веб панели управления хостингом должен быть ограничен. Второй момент - часто веб панели раскидывают конфиги в нестандартные места, переписывают их после перезапуска службы управления. Это часто делает невозможным изменение конфигов вне веб панели, а иногда хочется, так как их возможности ограничены.
Есть промежуточные варианты автоматизации и упрощения управления веб хостингом. Набор консольных инструментов для управления. Наглядным примером подобного продукта является Bitrixenv. Это инструмент для автоматической настройки и управления веб хостингом для размещения сайтов на движке Битрикс.
Для сайтов на Wordpress есть похожий продукт - WordOps. Он позволяет автоматически разворачивать готовое окружение для сайтов на базе Wordpress, а так же любых других статических или php сайтов.
Установить WordOps можно автоматически прямо на сервер:
Скрипт установки выполняет несколько простых шагов:
◽устанавливает необходимые системные пакеты
◽создаёт директории
◽устанавливает WordOps через pip
◽устанавливает acme.sh и WP-CLI
Всё это можно проделать и вручную. После установки становятся доступны консольные команды для управления хостингом. Создадим сайт Wordpress на php81 с сертификатом от Let's Encrypt:
Эта команда выполнит следующие действия:
▪️ добавит репозитории Nginx, Php, MySQL в систему
▪️ установит все необходимые пакеты
▪️ создаст конфигурации Nginx и Php-fpm
▪️ получит tls сертификаты для домена
▪️ установит последнюю версию wordpress
▪️ создаст и настроит подключение к базе данных
В консоли вы получите адрес созданного сайта и учётную запись админа. При этом в директории
Помимо Wordpress сайтов, можно создать обычный html или php:
Из минусов сразу отмечу, то все сайты одной версии php создаются общим пулом php-fpm. Лучше было бы их разделять между собой.
Помимо управления сайтами, у WordOps есть и другие команды, с помощью которых, к примеру, можно:
● обновить системные пакеты
● настроить некоторые параметры ssh
● установить phpMyAdmin, Adminer, Dashboard, Netdata, MySQLTuner, eXtplorer Filemanager, Fail2ban, proftpd и некоторые другие программы
● посмотреть логи служб
Пример того, как может выглядеть настроенный Dashboard вашего сервера.
Про WordOps узнал случайно. Увидел упоминание в комментариях. Сам никогда не пользовался, но мне понравилось, как всё сделано - просто и удобно. Меняются системные конфигурации, при этом всё остаётся на своих местах. Можно руками что-то подправить и это ничего не сломает. Панель просто помогает выполнить настройку.
Подобный инструмент существенно упрощает и ускоряет настройку веб сервера. Желательно им пользоваться, если вы уже умеете настраивать всё это вручную сами. Либо вы далеки от темы настройки веб серверов, а вам его нужно поднять. Для веб разработчиков это отличный инструмент, чтобы поставить на какой-нибудь свой тестовый сервер для разработки.
В документации с примерами показано, как всем этим управлять. Например, добавляем FTP пользователя или используем удалённый mysql сервер.
⇨ Сайт / Исходники
#webserver
Есть промежуточные варианты автоматизации и упрощения управления веб хостингом. Набор консольных инструментов для управления. Наглядным примером подобного продукта является Bitrixenv. Это инструмент для автоматической настройки и управления веб хостингом для размещения сайтов на движке Битрикс.
Для сайтов на Wordpress есть похожий продукт - WordOps. Он позволяет автоматически разворачивать готовое окружение для сайтов на базе Wordpress, а так же любых других статических или php сайтов.
Установить WordOps можно автоматически прямо на сервер:
# wget -qO wo wops.cc && bash woСкрипт установки выполняет несколько простых шагов:
◽устанавливает необходимые системные пакеты
◽создаёт директории
◽устанавливает WordOps через pip
◽устанавливает acme.sh и WP-CLI
Всё это можно проделать и вручную. После установки становятся доступны консольные команды для управления хостингом. Создадим сайт Wordpress на php81 с сертификатом от Let's Encrypt:
# wo site create 330693.simplecloud.ru --wp --php81 -le Эта команда выполнит следующие действия:
▪️ добавит репозитории Nginx, Php, MySQL в систему
▪️ установит все необходимые пакеты
▪️ создаст конфигурации Nginx и Php-fpm
▪️ получит tls сертификаты для домена
▪️ установит последнюю версию wordpress
▪️ создаст и настроит подключение к базе данных
В консоли вы получите адрес созданного сайта и учётную запись админа. При этом в директории
/etc/nginx/sites-enabled будет создана конфигурация для сайта. Причём довольно навороченная. Там сразу будут лимиты на wp-cron.php и wp-login.php, ограничение доступа белым списком к xmlrpc.php, блокировка доступа к некоторым другим внутренностям Wordpress. В директории /var/www/330693.simplecloud.ru будут лежать исходники сайта, логи и некоторые настройки. В рутовском кроне /var/spool/cron/crontabs будут добавлены задания на обновление сертификатов и некоторые другие действия. Все конфигурации в стандартном формате и на своих местах. Искать ничего не надо. Помимо Wordpress сайтов, можно создать обычный html или php:
# wo site create site.tld --html# wo site create site.tld --mysql --php81Из минусов сразу отмечу, то все сайты одной версии php создаются общим пулом php-fpm. Лучше было бы их разделять между собой.
Помимо управления сайтами, у WordOps есть и другие команды, с помощью которых, к примеру, можно:
● обновить системные пакеты
● настроить некоторые параметры ssh
● установить phpMyAdmin, Adminer, Dashboard, Netdata, MySQLTuner, eXtplorer Filemanager, Fail2ban, proftpd и некоторые другие программы
● посмотреть логи служб
Пример того, как может выглядеть настроенный Dashboard вашего сервера.
Про WordOps узнал случайно. Увидел упоминание в комментариях. Сам никогда не пользовался, но мне понравилось, как всё сделано - просто и удобно. Меняются системные конфигурации, при этом всё остаётся на своих местах. Можно руками что-то подправить и это ничего не сломает. Панель просто помогает выполнить настройку.
Подобный инструмент существенно упрощает и ускоряет настройку веб сервера. Желательно им пользоваться, если вы уже умеете настраивать всё это вручную сами. Либо вы далеки от темы настройки веб серверов, а вам его нужно поднять. Для веб разработчиков это отличный инструмент, чтобы поставить на какой-нибудь свой тестовый сервер для разработки.
В документации с примерами показано, как всем этим управлять. Например, добавляем FTP пользователя или используем удалённый mysql сервер.
⇨ Сайт / Исходники
#webserver
Для запуска системы Android на обычных компьютерах или виртуалках долгое время был наиболее популярен проект android-x86.org. К сожалению, он не обновляется уже несколько лет. Наиболее популярным и рабочим вариантом на текущий день является проект Bliss-OS.
Bliss-OS - операционная система на базе Android, которую можно установить на компьютер или ноутбук, а также в виртуальную машину. На железо я ставить не пробовал, хотя в сети видел много отзывов о том, как люди ставят эту систему на старое железо и пользуются. Подойдёт какой-нибудь старый ноут с 4 Гб памяти. При этом Bliss-OS будет со свежей версией Android 13. То есть это будет современная система, которую можно успешно использовать для работы в интернете.
Я установил Bliss-OS в виртуальную машину Proxmox. Продолбался я с ней очень долго, пока не нашёл вот эту инструкцию:
▶️ Installing Android On Proxmox As A Virtual Machine Using BlissOS
Если делать строго по ней, то всё получится. Для виртуальной машины нужно выставить следующие настройки:
◽Bios: OVMF (UEFI)
◽Display: VirGL GPU
Чтобы он заработал, на хост надо установить пару пакетов:
◽Machine: q35
◽VirtIO SCSI single
◽Hard Disk: SATA, галку Discard поставить
◽EFI Disk: тип qcow2, pre-enroll keys отключить
◽Сеть: бридж VirtIO в локалку или куда-то ещё, где есть dhcp
Я устанавливал с ISO образа Bliss-v16.9.4-x86_64-OFFICIAL-gapps-20240220.iso. То есть взял свежую 16-ю версию с Android 13. Во время локальной установки нужно обязательно:
▪️ выбрать разметку gpt
▪️ при разбивке диска сделать первый раздел 1024М, тип EFI System
▪️ второй раздел весь остальной объём, тип Linux Filesystem
▪️ первый раздел форматируем в fat32
▪️ систему ставим на второй раздел, форматируем в ext4
▪️ в качестве загрузчика выбираем rEFInd Boot Manager
Если сделать, как описано, всё получится. Я долго мучался, пока не повторил в точности, как здесь. Система загрузилась, всё заработало. Даже видео с ютуба нормально показывает.
❗️Важное предупреждение. Не используйте в таких системах свои актуальные учётные записи. Подобные системы часто используют для накруток и прочей запрещёнки, так что можно с большой долей вероятности получить бан учётной записи. Используйте отдельные.
Я не проработал один важный момент, который мне был бы очень полезен. Если кто-то знает и пробовал хорошее рабочее решение, дайте совет. Нужна возможность подключаться к этой системе удалённо, желательно не только с PC, но и с другого смартфона под Android.
⇨ Сайт
#android
Bliss-OS - операционная система на базе Android, которую можно установить на компьютер или ноутбук, а также в виртуальную машину. На железо я ставить не пробовал, хотя в сети видел много отзывов о том, как люди ставят эту систему на старое железо и пользуются. Подойдёт какой-нибудь старый ноут с 4 Гб памяти. При этом Bliss-OS будет со свежей версией Android 13. То есть это будет современная система, которую можно успешно использовать для работы в интернете.
Я установил Bliss-OS в виртуальную машину Proxmox. Продолбался я с ней очень долго, пока не нашёл вот эту инструкцию:
▶️ Installing Android On Proxmox As A Virtual Machine Using BlissOS
Если делать строго по ней, то всё получится. Для виртуальной машины нужно выставить следующие настройки:
◽Bios: OVMF (UEFI)
◽Display: VirGL GPU
Чтобы он заработал, на хост надо установить пару пакетов:
# apt install libgl1 libegl1◽Machine: q35
◽VirtIO SCSI single
◽Hard Disk: SATA, галку Discard поставить
◽EFI Disk: тип qcow2, pre-enroll keys отключить
◽Сеть: бридж VirtIO в локалку или куда-то ещё, где есть dhcp
Я устанавливал с ISO образа Bliss-v16.9.4-x86_64-OFFICIAL-gapps-20240220.iso. То есть взял свежую 16-ю версию с Android 13. Во время локальной установки нужно обязательно:
▪️ выбрать разметку gpt
▪️ при разбивке диска сделать первый раздел 1024М, тип EFI System
▪️ второй раздел весь остальной объём, тип Linux Filesystem
▪️ первый раздел форматируем в fat32
▪️ систему ставим на второй раздел, форматируем в ext4
▪️ в качестве загрузчика выбираем rEFInd Boot Manager
Если сделать, как описано, всё получится. Я долго мучался, пока не повторил в точности, как здесь. Система загрузилась, всё заработало. Даже видео с ютуба нормально показывает.
❗️Важное предупреждение. Не используйте в таких системах свои актуальные учётные записи. Подобные системы часто используют для накруток и прочей запрещёнки, так что можно с большой долей вероятности получить бан учётной записи. Используйте отдельные.
Я не проработал один важный момент, который мне был бы очень полезен. Если кто-то знает и пробовал хорошее рабочее решение, дайте совет. Нужна возможность подключаться к этой системе удалённо, желательно не только с PC, но и с другого смартфона под Android.
⇨ Сайт
#android
