This media is not supported in your browser
VIEW IN TELEGRAM
Что такое Devops 😂
https://www.youtube.com/watch?v=NXwtcjOdaHw
Work-life balance ставишь 0.
Не понял только одно. Зачем докер контейнер упаковали в zip?
#юмор #devops
https://www.youtube.com/watch?v=NXwtcjOdaHw
Work-life balance ставишь 0.
Не понял только одно. Зачем докер контейнер упаковали в zip?
#юмор #devops
Очередная тема выходного дня. Хочу вернуться к своей старой заметке, написанной более 2,5 лет назад на тему того, как подходить к любому делу. Прежде чем продолжать чтение этой, прочитайте ту. Она не потеряла актуальность, и я не изменил своё мнение, более того, ещё больше убедился в правоте написанного. Говорю об этом, потому что получил подтверждение в том числе на основании опыта последних лет.
Во всех делах, которые я задумал и начал, неизменно продвинулся вперёд. Где-то больше, где-то меньше, но самое главное, что есть движение. Даже очень маленькие регулярные шажки по совершенно незнакомой теме приводят к результату. Главное, загрузить в голову какую-то мысль и снабжать её небольшими (можно и большими) порциями материала.
У меня это выглядит до банальности просто. Когда мне нужно решить какую-то задачу или что-то изучить, я делаю плейлисты из тематических видео в ютубе. И просто смотрю это либо целенаправленно, либо в фоне, когда куда-то еду на машине или в метро. Мозг начинает потихоньку получать и обрабатывать информацию. Потом ты целенаправленно или случайно (а все случайности на самом деле не случайны) получаешь расширение этой информации в виде новой информации или, что значительно лучше, контакты и знакомства по теме. Поэтому я не игнорирую очное посещение различных мероприятий (выстави, семинары, конференции и т.д.).
Я не знаю, как это работает. Разные люди объясняют это про разному. Кто-то говорит, что вселенная подсказывает. Кто-то, что мозг излучает какие-то волны и фиксируется на похожем излучении, когда видит тематическую информацию. Кто-то считает, что это участие бога. Не суть важно. Главное, что это работает. Жизненный опыт подтверждает, а как это на самом деле работает - вторично. Возможно, с нашего уровня развития это вообще нельзя изучить.
Приведу несколько своих примеров. Про этот канал я уже писал 2,5 года назад. Просто 2 публикации в день в течении нескольких лет и этот канал читают тысячи людей. Когда родился первый ребёнок, я не понимал, как вытянуть ещё больше. Но мне хотелось детей. В итоге жду сейчас четвертого. Всё само как-то устраивается потихонечку.
Начал строить дом вообще ничего не понимая и не зная. Косяков было море, крышу переделывал полностью (неправильно рассчитали стропильную систему). Какие только проблемы я не решал: потёкший котёл, постоянная влага в подполе, неправильная вентиляция, замёрзший ввод воды и т.д. Всё и не упомнишь уже. Тем не менее, шаг за шагом всё получилось. Дом достроен, а я параллельно освоил ещё одну профессию. Работал на стройке прорабом и технадзором для 5-ти разных бригад.
С воспитанием детей и семейной жизнью то же самое. Потихоньку изучаешь материалы, общаешься со специалистами, посещаешь тематические мероприятия. И все проблемы решаются, дела налаживаются, результат приходит.
Медицина - такая же история. Я сейчас прохожу новое лечение своей спины. Наконец-то удалось найти причину болей, поставить нормальный диагноз. Просто потихонечку крутил в голове мысли на эту тему, делал тут заметки. Одна из заметок и помогла. Там дали ссылку на канал Епифанова (на самом деле шарлатан), но через него я попал на настоящего врача и дела начали налаживаться. Кто много мается болями в спине, обратите внимание на заболевание миофасциальный синдром. Им много кто страдает, но врачи почему-то очень мало про него знают и почти не ставят такой диагноз.
В общем, так во всём: в работе, личных делах, в обучении и т.д. Просто сгружаешь в голову информацию и потихоньку обдумываешь, делаешь небольшие шажки, но регулярно. В этом сильно мешает различное ютубовское развлекалово. Это пустышка, которой люди забивают своё время, а некоторые вообще всё время. Я бью себя по руками и постоянно ограничиваю просмотр бесполезных вещей. Если надо отдохнуть и расслабиться, провожу время с детьми или гуляю.
Если вам интересно, могу каждый из перечисленных примеров подробно раскрыть отдельной заметкой. Пишите об этом и ставьте реакцию к посту, чтобы я понимал, писать или нет.
#мысли
Во всех делах, которые я задумал и начал, неизменно продвинулся вперёд. Где-то больше, где-то меньше, но самое главное, что есть движение. Даже очень маленькие регулярные шажки по совершенно незнакомой теме приводят к результату. Главное, загрузить в голову какую-то мысль и снабжать её небольшими (можно и большими) порциями материала.
У меня это выглядит до банальности просто. Когда мне нужно решить какую-то задачу или что-то изучить, я делаю плейлисты из тематических видео в ютубе. И просто смотрю это либо целенаправленно, либо в фоне, когда куда-то еду на машине или в метро. Мозг начинает потихоньку получать и обрабатывать информацию. Потом ты целенаправленно или случайно (а все случайности на самом деле не случайны) получаешь расширение этой информации в виде новой информации или, что значительно лучше, контакты и знакомства по теме. Поэтому я не игнорирую очное посещение различных мероприятий (выстави, семинары, конференции и т.д.).
Я не знаю, как это работает. Разные люди объясняют это про разному. Кто-то говорит, что вселенная подсказывает. Кто-то, что мозг излучает какие-то волны и фиксируется на похожем излучении, когда видит тематическую информацию. Кто-то считает, что это участие бога. Не суть важно. Главное, что это работает. Жизненный опыт подтверждает, а как это на самом деле работает - вторично. Возможно, с нашего уровня развития это вообще нельзя изучить.
Приведу несколько своих примеров. Про этот канал я уже писал 2,5 года назад. Просто 2 публикации в день в течении нескольких лет и этот канал читают тысячи людей. Когда родился первый ребёнок, я не понимал, как вытянуть ещё больше. Но мне хотелось детей. В итоге жду сейчас четвертого. Всё само как-то устраивается потихонечку.
Начал строить дом вообще ничего не понимая и не зная. Косяков было море, крышу переделывал полностью (неправильно рассчитали стропильную систему). Какие только проблемы я не решал: потёкший котёл, постоянная влага в подполе, неправильная вентиляция, замёрзший ввод воды и т.д. Всё и не упомнишь уже. Тем не менее, шаг за шагом всё получилось. Дом достроен, а я параллельно освоил ещё одну профессию. Работал на стройке прорабом и технадзором для 5-ти разных бригад.
С воспитанием детей и семейной жизнью то же самое. Потихоньку изучаешь материалы, общаешься со специалистами, посещаешь тематические мероприятия. И все проблемы решаются, дела налаживаются, результат приходит.
Медицина - такая же история. Я сейчас прохожу новое лечение своей спины. Наконец-то удалось найти причину болей, поставить нормальный диагноз. Просто потихонечку крутил в голове мысли на эту тему, делал тут заметки. Одна из заметок и помогла. Там дали ссылку на канал Епифанова (на самом деле шарлатан), но через него я попал на настоящего врача и дела начали налаживаться. Кто много мается болями в спине, обратите внимание на заболевание миофасциальный синдром. Им много кто страдает, но врачи почему-то очень мало про него знают и почти не ставят такой диагноз.
В общем, так во всём: в работе, личных делах, в обучении и т.д. Просто сгружаешь в голову информацию и потихоньку обдумываешь, делаешь небольшие шажки, но регулярно. В этом сильно мешает различное ютубовское развлекалово. Это пустышка, которой люди забивают своё время, а некоторые вообще всё время. Я бью себя по руками и постоянно ограничиваю просмотр бесполезных вещей. Если надо отдохнуть и расслабиться, провожу время с детьми или гуляю.
Если вам интересно, могу каждый из перечисленных примеров подробно раскрыть отдельной заметкой. Пишите об этом и ставьте реакцию к посту, чтобы я понимал, писать или нет.
#мысли
Когда вы настраиваете VPN, встаёт вопрос выбора размера MTU (maximum transmission unit) внутри туннеля. Это размер полезного блока с данными в одном пакете. Как известно, в сетевом пакете часть информации уходит для служебной информации в заголовках. Различные технологии VPN используют разный объём служебных заголовков. А если VPN пущен поверх другого VPN канала, то этот вопрос встаёт особенно остро.
Если ошибиться с размером MTU, то пакеты начнут разбиваться на несколько, чтобы передать полезный блок с данными. Это очень сильно снижает скорость передачи данных. Минимум в 2 раза, но на деле гораздо больше.
Правильно выбрать размер MTU можно с помощью готового калькулятора - Visual packet size calculator. Его автор, кстати, Даниил Батурин, который иногда ведёт бесплатные вебинары Rebrain, которые я периодически рекламирую. Рекомендую послушать, интересно.
К сожалению, в калькуляторе нет OpenVPN. И я как-то сходу не смог найти информацию, сколько места занимают служебные заголовки этого протокола. Покажу пример для WireGuard, если я всё правильно понимаю. Если ошибаюсь, прошу поправить.
Мы устанавливаем туннель WireGuard, чтобы гонять по нему ipv4 трафик. Идём в калькулятор и выстраиваем там цепочку:
IPv4 (20 bytes) ⇨ WireGuard (40 bytes) ⇨ IPv4 (20 bytes)
Имея на родительском интерфейсе MTU 1500, внутри туннеля нам необходимо установить его 1420. Если не ошибаюсь, это как раз значение по умолчанию для WireGuard.
Тема MTU довольно сложная. Если вы не сетевой инженер и специально ей не интересовались, то вникнуть непросто. На практике я сталкивался с подобными проблемами. Решал их в меру своих сил и способностей - просто уменьшал MTU до некоторых значений, когда проблем пропадала. Если вы не разбираетесь детально в этой теме, рекомендую поступать так же. И важно знать, что если у вас PPPoE соединение от провайдера, то оно дополнительно 8 байт занимает на заголовки. Часто дефолтные значения различного софта не учитывают этого нюанса и нужно будет поправить вручную.
#vpn #network
Если ошибиться с размером MTU, то пакеты начнут разбиваться на несколько, чтобы передать полезный блок с данными. Это очень сильно снижает скорость передачи данных. Минимум в 2 раза, но на деле гораздо больше.
Правильно выбрать размер MTU можно с помощью готового калькулятора - Visual packet size calculator. Его автор, кстати, Даниил Батурин, который иногда ведёт бесплатные вебинары Rebrain, которые я периодически рекламирую. Рекомендую послушать, интересно.
К сожалению, в калькуляторе нет OpenVPN. И я как-то сходу не смог найти информацию, сколько места занимают служебные заголовки этого протокола. Покажу пример для WireGuard, если я всё правильно понимаю. Если ошибаюсь, прошу поправить.
Мы устанавливаем туннель WireGuard, чтобы гонять по нему ipv4 трафик. Идём в калькулятор и выстраиваем там цепочку:
IPv4 (20 bytes) ⇨ WireGuard (40 bytes) ⇨ IPv4 (20 bytes)
Имея на родительском интерфейсе MTU 1500, внутри туннеля нам необходимо установить его 1420. Если не ошибаюсь, это как раз значение по умолчанию для WireGuard.
Тема MTU довольно сложная. Если вы не сетевой инженер и специально ей не интересовались, то вникнуть непросто. На практике я сталкивался с подобными проблемами. Решал их в меру своих сил и способностей - просто уменьшал MTU до некоторых значений, когда проблем пропадала. Если вы не разбираетесь детально в этой теме, рекомендую поступать так же. И важно знать, что если у вас PPPoE соединение от провайдера, то оно дополнительно 8 байт занимает на заголовки. Часто дефолтные значения различного софта не учитывают этого нюанса и нужно будет поправить вручную.
#vpn #network
Несколько полезных команд из использования GIT. Накопилось на небольшую заметку, поэтому решил опубликовать. Тут ничего особенного, если это можно сказать про GIT. Реально, это довольно сложная система с кучей всяких параметров, ситуаций, вариантов действия и т.д. Эта система контроля версий, про которую можно книги писать. И, наверное, пишут (я не читал).
Простая команда, про которую я узнал случайно. Она объединяет добавление изменённых файлов и коммит. Удобно и пригодится всем:
Заменяет:
Можно сразу алиас сделать, чтобы ещё упростить команду:
Если регулярно используете git, то можно добавить в алиасы наиболее часто используемые команды. Status так точно можно добавить:
Если чего-то понаделали локально в репозитории, хотите сохранить эти изменения, но не хотите пушить их куда-то, то можно воспользоваться командой stash. Она удалит все изменения в файлах, но сохранит их отдельно, чтобы можно было вернуться к ним, если понадобится.
Файлы вернулись в первоначальный вид, а все изменения сохранены отдельно. Если захотите вернуть их, то выполните:
Все изменения вернулись в файлы. У stash много дополнительных параметров. Если будете пользоваться, то почитайте.
Если посмотреть изменения большого репозитория, то в консоли всё это не очень читаемо, так как много информации. Можно немного упростить:
Так читается намного лучше.
📌 Теперь краткая инструкция, как перенести репозиторий из одного удалённого сервера в другой.
Перенесли полностью репозиторий со всеми коммитами на новое место и настроили на него локальный репозиторий. Последнее можно не делать, если вам это не нужно. Вот подробная инструкция github по теме дубликатов репозиториев.
#git
Простая команда, про которую я узнал случайно. Она объединяет добавление изменённых файлов и коммит. Удобно и пригодится всем:
# git commit -am "changed two files"Заменяет:
# git add .# git commit -m "changed two files"Можно сразу алиас сделать, чтобы ещё упростить команду:
# git config --global alias.cam "commit -am" # git cam "changed two files"Если регулярно используете git, то можно добавить в алиасы наиболее часто используемые команды. Status так точно можно добавить:
# git config --global alias.st status # git stЕсли чего-то понаделали локально в репозитории, хотите сохранить эти изменения, но не хотите пушить их куда-то, то можно воспользоваться командой stash. Она удалит все изменения в файлах, но сохранит их отдельно, чтобы можно было вернуться к ним, если понадобится.
# git stashФайлы вернулись в первоначальный вид, а все изменения сохранены отдельно. Если захотите вернуть их, то выполните:
# git stash popВсе изменения вернулись в файлы. У stash много дополнительных параметров. Если будете пользоваться, то почитайте.
Если посмотреть изменения большого репозитория, то в консоли всё это не очень читаемо, так как много информации. Можно немного упростить:
# git log --onelineТак читается намного лучше.
📌 Теперь краткая инструкция, как перенести репозиторий из одного удалённого сервера в другой.
# git clone --bare git@server01.local:testrepo.git# cd testrepo.git && git fetch origin# git remote add new-origin git@server02.local:testrepo.git# git push --mirror new-origin# git remote rm origin && git remote rename new-origin originПеренесли полностью репозиторий со всеми коммитами на новое место и настроили на него локальный репозиторий. Последнее можно не делать, если вам это не нужно. Вот подробная инструкция github по теме дубликатов репозиториев.
#git
GitHub Docs
Duplicating a repository - GitHub Docs
To maintain a mirror of a repository without forking it, you can run a special clone command, then mirror-push to the new repository.
Недавно была публикация про централизованную установку дистрибутивов по сети с помощью технологии PXE. В комментариях посоветовали интересный проект - LTSP (Linux Terminal Server Project). Это софт из этой же оперы, только с упором на простое создание собственных преднастроенных образов. Проект open source, так что можно бесплатно пользоваться. При этом он старый и известный продукт, который одно время продвигал AltLinux. Много статей нашёл, правда довольно старых. Возможно уже отказались от него.
LTSP поддерживает 2 режима работы: тонкий и толстый клиенты. Тонкий полностью грузит ОС по сети. Вся работа выполняется на терминальном сервере. Толстый клиент устанавливает систему на свой жёсткий диск, а с терминала подключает пользовательские файлы и программы.
В принципе, LTSP ничего особенного не делает и всю его функциональность можно реализовать самостоятельно: поднять tftp сервер, подготовить загрузочный образ, настроить его загрузку через dhcp, положить систему и пользовательские файлы на nfs сервер, подключать их на системе, которая грузится по сети. LTSP всё это упрощает, предоставляя инструменты для управления.
После загрузки системы на тонком клиенте, пользователю необходимо пройти аутентификацию по SSH, ему пробрасываются иксы. Он попадает в своё рабочее окружение. В случае толстого клиента ему подключается его домашний каталог и затем запускается окружение.
Установить и настроить LTSP сервер относительно просто, особенно если есть понимание работы используемых технологий. В качестве DHCP сервера не обязательно должен выступать линуксовый сервер. Подойдёт и Mikrotik. Есть репозитории для Ubuntu и Debian. Вот пример установки на Debian 12:
Дальше необходимо подготовить клиентскую систему. Тут есть три варианта:
1️⃣ Использовать локальную систему как эталон для загрузки клиентам.
2️⃣ Собрать свой raw образ виртуальной машины.
3️⃣ Выбрать отдельную директорию и там собирать необходимую систему, чрутясь туда с помощью chroot.
Мне видится третий вариант наиболее удобным. Я сам его использовал, когда настраивал подобное. Хотел пойти по этому пути и показать его вам, но узнал, что в последней версии LTSP этот вариант признан устаревшим. Разработчики рекомендую использовать первый или второй вариант. Если хочется третий, то вот инструкция.
Полное руководство по настройке не уместить в заметке. Покажу только основные этапы, чтобы было понятно, как LTSP настраивается. Готовим образ для загрузки по сети на основе текущей системы:
В результате работы команды получите образ системы /srv/ltsp/images/x86_64.img и образы для tftp в /srv/tftp/ltsp/x86_64. Добавляем в эти образы iPXE меню:
Настраиваем NFS сервер для экспорта созданных образов:
Эта команда просто добавляет в /etc/exports.d настройки:
Далее вы либо локально, либо на внешнем dhcp сервере настраиваете tftp сервер и путь к загрузке образа. LTSP поддерживает загрузку через UEFI. В зависимости от того, какие клиенты у вас будут, выбираете образ для загрузки.
LTSP хранит все свои настройки в конфигурационном файле, которые используются во время генерации образа. В этих настройках, к примеру, можно указать автологин для каких-то MAC адресов, сетевые настройки, hostname и т.д. После изменения этих настроек, загрузочные образы надо пересобирать.
В общем, LTSP простая и надёжная система для создания и управления загрузочными образами. По своей сути это набор shell и немного python скриптов.
⇨ Сайт / Исходники
#pxe
LTSP поддерживает 2 режима работы: тонкий и толстый клиенты. Тонкий полностью грузит ОС по сети. Вся работа выполняется на терминальном сервере. Толстый клиент устанавливает систему на свой жёсткий диск, а с терминала подключает пользовательские файлы и программы.
В принципе, LTSP ничего особенного не делает и всю его функциональность можно реализовать самостоятельно: поднять tftp сервер, подготовить загрузочный образ, настроить его загрузку через dhcp, положить систему и пользовательские файлы на nfs сервер, подключать их на системе, которая грузится по сети. LTSP всё это упрощает, предоставляя инструменты для управления.
После загрузки системы на тонком клиенте, пользователю необходимо пройти аутентификацию по SSH, ему пробрасываются иксы. Он попадает в своё рабочее окружение. В случае толстого клиента ему подключается его домашний каталог и затем запускается окружение.
Установить и настроить LTSP сервер относительно просто, особенно если есть понимание работы используемых технологий. В качестве DHCP сервера не обязательно должен выступать линуксовый сервер. Подойдёт и Mikrotik. Есть репозитории для Ubuntu и Debian. Вот пример установки на Debian 12:
# wget https://ltsp.org/misc/ltsp-ubuntu-ppa-focal.list -O /etc/apt/sources.list.d/ltsp-ubuntu-ppa-focal.list# wget https://ltsp.org/misc/ltsp_ubuntu_ppa.gpg -O /etc/apt/trusted.gpg.d/ltsp_ubuntu_ppa.gpg# apt update# apt install --install-recommends ltsp ltsp-binaries dnsmasq nfs-kernel-server openssh-server squashfs-tools ethtool net-tools epoptesДальше необходимо подготовить клиентскую систему. Тут есть три варианта:
1️⃣ Использовать локальную систему как эталон для загрузки клиентам.
2️⃣ Собрать свой raw образ виртуальной машины.
3️⃣ Выбрать отдельную директорию и там собирать необходимую систему, чрутясь туда с помощью chroot.
Мне видится третий вариант наиболее удобным. Я сам его использовал, когда настраивал подобное. Хотел пойти по этому пути и показать его вам, но узнал, что в последней версии LTSP этот вариант признан устаревшим. Разработчики рекомендую использовать первый или второй вариант. Если хочется третий, то вот инструкция.
Полное руководство по настройке не уместить в заметке. Покажу только основные этапы, чтобы было понятно, как LTSP настраивается. Готовим образ для загрузки по сети на основе текущей системы:
# ltsp image /# ltsp initrdВ результате работы команды получите образ системы /srv/ltsp/images/x86_64.img и образы для tftp в /srv/tftp/ltsp/x86_64. Добавляем в эти образы iPXE меню:
# ltsp ipxeНастраиваем NFS сервер для экспорта созданных образов:
# ltsp nfsЭта команда просто добавляет в /etc/exports.d настройки:
/srv/ltsp *(ro,async,crossmnt,no_subtree_check,no_root_squash,insecure)/srv/tftp/ltsp *(ro,async,crossmnt,no_subtree_check,no_root_squash,insecure)Далее вы либо локально, либо на внешнем dhcp сервере настраиваете tftp сервер и путь к загрузке образа. LTSP поддерживает загрузку через UEFI. В зависимости от того, какие клиенты у вас будут, выбираете образ для загрузки.
LTSP хранит все свои настройки в конфигурационном файле, которые используются во время генерации образа. В этих настройках, к примеру, можно указать автологин для каких-то MAC адресов, сетевые настройки, hostname и т.д. После изменения этих настроек, загрузочные образы надо пересобирать.
В общем, LTSP простая и надёжная система для создания и управления загрузочными образами. По своей сути это набор shell и немного python скриптов.
⇨ Сайт / Исходники
#pxe
Вчера бился часа 3-4 над одной проблемой. Уже спать пора было ложиться, но не могу уснуть, когда не доделано дело. Не даст спокойно спать, а на следующий день всё равно придётся доделывать. Не могу бросить нерешённые задачи, даже если они не очень важные. Особенно, когда кажется, что ещё чуть-чуть и всё заработает.
Мне нужно было настроить aws-cli для работы со сторонними S3 сервисами. В целом, проблем особых нет. У Yandex.Cloud или Selectel есть для этого инструкции. Важная особенность в том, что эта утилита заточена на использование с сервисами AWS. Для подключения к сторонним сервисам есть консольный ключ
Мне нужно было настроить работу без этого ключа. Для этого нужно правильно настроить
Я пробовал и на локальном WSL под Ubuntu, и на виртуалке под Debian 12. Никак не получалось настроить. Не буду вас утомлять дальнейшем рассказом. Сразу скажу, в чём было дело. Есть параметр для файла credentials:
Но появился он не так давно. Версии aws-cli на обоих системах, что я настраивал, были старее, где этого параметра ещё не было. При этом утилита на него не ругалась. Я такого накрутил в настройках и переменных, что даже когда обновил утилиту до последней версии, не заработало.
Потом всё обнулил, начал с самого начала с новой версией и всё получилось. Поначалу даже мысли не было, что версия слишком старая. Обычно на неподдерживаемые параметры программы ругаются. А тут тишина. Тупо не принимает его, хоть ты что делай. Я уже не знал, что и думать. Всё перепробовал.
Вот описание настроек в документации. Тут и намека нет на версию, начиная с которой это поддерживается. В версии 2.9.19 не работает, в последней 2.13.39 - работает. Появилось это только в июле этого года в версии 2.13.0. А обсуждение этой фичи есть аж с 2015 года.
Обидно потерять столько времени на такой ерунде.
#s3
Мне нужно было настроить aws-cli для работы со сторонними S3 сервисами. В целом, проблем особых нет. У Yandex.Cloud или Selectel есть для этого инструкции. Важная особенность в том, что эта утилита заточена на использование с сервисами AWS. Для подключения к сторонним сервисам есть консольный ключ
--endpoint-url=https://s3.ru-1.storage.selcloud.ru. Это вариант для Selectel. Он работает нормально.Мне нужно было настроить работу без этого ключа. Для этого нужно правильно настроить
~/.aws/config и ~/.aws/credentials. Начал гуглить решение задачи. Наткнулся на множество вопросов, где люди спрашивают, как подобное настроить. Где-то есть инструкции, как это предположительно может работать, как обойти этот вопрос, например добавлением алиаса с уже настроенным эндпоинтом, чтобы его не набирать. Можно использовать переменные окружения типа export AWS_ENDPOINT_URL=https://s3.ru-1.storage.selcloud.ru, но у меня они почему-то никак не работали.Я пробовал и на локальном WSL под Ubuntu, и на виртуалке под Debian 12. Никак не получалось настроить. Не буду вас утомлять дальнейшем рассказом. Сразу скажу, в чём было дело. Есть параметр для файла credentials:
endpoint_url = https://s3.ru-1.storage.selcloud.ruНо появился он не так давно. Версии aws-cli на обоих системах, что я настраивал, были старее, где этого параметра ещё не было. При этом утилита на него не ругалась. Я такого накрутил в настройках и переменных, что даже когда обновил утилиту до последней версии, не заработало.
Потом всё обнулил, начал с самого начала с новой версией и всё получилось. Поначалу даже мысли не было, что версия слишком старая. Обычно на неподдерживаемые параметры программы ругаются. А тут тишина. Тупо не принимает его, хоть ты что делай. Я уже не знал, что и думать. Всё перепробовал.
Вот описание настроек в документации. Тут и намека нет на версию, начиная с которой это поддерживается. В версии 2.9.19 не работает, в последней 2.13.39 - работает. Появилось это только в июле этого года в версии 2.13.0. А обсуждение этой фичи есть аж с 2015 года.
Обидно потерять столько времени на такой ерунде.
#s3
Хочу напомнить про 2 очень полезные утилиты Linux, с помощью которых удобно в скриптах делать проверки наличия подключенных и примонтированных блочных устройств и файловых систем. Речь пойдёт про findmnt и findfs.
Про первую я уже когда-то рассказывал. Findmnt удобна и полезна сама по себе, без привязки к скриптам. Просто запустите её и посмотрите вывод. Она выводит в консоль подробную информацию о всех точках монтирования. А ключ
А если в чём-то ошибётесь, то получите ошибку:
Findfs сама по себе ничего не выводит. Она умеет искать файловые системы по заданными параметрами В качестве аргумента принимает значение LABEL, UUID, PARTLABEL и PARTUUID. Например так:
Нашли файловую систему на /dev/sda2 с заданным UUID. При этом код выхода будет 0:
Если файловая система не будет найдена, код будет 1:
Соответственно, подобную проверку мы может использовать в скриптах перед тем, как выполнять какие-то действия. Это актуально для каких-нибудь бэкапов или синхронизаций на сетевых или внешних дисках. Делаем простую проверку, типа такой:
Вместо echo можно сразу выполнять какое-то действие. Оно будет выполнено, если указанный скрипту UUID подключен. То есть сам скрипт работает так:
И точно так же по аналогии можно сделать проверку точек монтирования с помощью findmnt:
Проверяем:
Внешнее хранилище для бэкапов не смонтировано, ничего не делаем. Очень важно делать такие проверки, когда копируете что-то на примонтированные устройства. Если запустить процесс копирования при отмонтированном устройстве, то вы просто забьёте весь диск локальной системы, так как все файлы польются на неё.
Я и сам с таким сталкивался, и много раз видел вопросы людей на тему того, что не могут понять, что происходит. Обычно это выглядит так. В момент бэкапа сетевой диск не был примонтирован и мы забили весь корень файлами. А потом в какой-то момент этот диск примонтировался и мы больше не видим те файлы, что были скопированы в точку монтирования в тот момент, когда там не было диска. Его надо отмонтировать и удалить локальные файлы. Если это сразу не просечёшь, то можно много времени потратить на поиск того, что занимает всё свободное место на разделе.
Так что назначайте метки внешним дискам, проверяйте их, делайте проверки монтирования сетевых дисков и т.д. Не выполняйте копирования и синхронизации без этих проверок. А то можно сильно удивиться из-за какой-нибудь неожиданной ошибки. Я реально сталкивался сам с этим не раз, пока не начал постоянно добавлять проверки. Вроде думаешь в локалке всё стабильно, сервера и сеть никто не дёргает, всё в одной стойке стоит. А потом оказалось, что после выключения электричества сервера поднялись не равномерно и сервер с бэкапами поднялся позже остальных. В итоге куда-то не примонтировался сетевой диск для бэкапов и они начали литься локально, пока там место не кончится.
#bash #script
Про первую я уже когда-то рассказывал. Findmnt удобна и полезна сама по себе, без привязки к скриптам. Просто запустите её и посмотрите вывод. Она выводит в консоль подробную информацию о всех точках монтирования. А ключ
-x ещё и позволяет проверить отредактированный файл fstab на наличие в нём ошибок. Рекомендую запомнить эту возможность и использовать:# findmnt -xSuccess, no errors or warnings detectedА если в чём-то ошибётесь, то получите ошибку:
# findmnt -x/mnt/backup [E] unreachable on boot required source: UUID=151ea24d-977a-412c-818f-0d374baa5012Findfs сама по себе ничего не выводит. Она умеет искать файловые системы по заданными параметрами В качестве аргумента принимает значение LABEL, UUID, PARTLABEL и PARTUUID. Например так:
# findfs "UUID=151ea24d-977a-412c-818f-0d374baa5013"/dev/sda2Нашли файловую систему на /dev/sda2 с заданным UUID. При этом код выхода будет 0:
# echo $?0Если файловая система не будет найдена, код будет 1:
# findfs "UUID=151ea24d-977a-412c-818f-0d374baa5012"findfs: unable to resolve 'UUID=151ea24d-977a-412c-818f-0d374baa5012'# echo $?1Соответственно, подобную проверку мы может использовать в скриптах перед тем, как выполнять какие-то действия. Это актуально для каких-нибудь бэкапов или синхронизаций на сетевых или внешних дисках. Делаем простую проверку, типа такой:
if findfs "UUID=$1" >/dev/null; then echo "$1 connected."elseecho "$1 not connected."fiВместо echo можно сразу выполнять какое-то действие. Оно будет выполнено, если указанный скрипту UUID подключен. То есть сам скрипт работает так:
# ./check-fs.sh 151ea24d-977a-412c-818f-0d374baa5013151ea24d-977a-412c-818f-0d374baa5013 connected.И точно так же по аналогии можно сделать проверку точек монтирования с помощью findmnt:
if findmnt -rno TARGET "$1" >/dev/null; then echo "$1 mounted."elseecho "$1 not mounted."fiПроверяем:
# ./check-mnt.sh /mnt/extbackup/mnt/extbackup not mounted.Внешнее хранилище для бэкапов не смонтировано, ничего не делаем. Очень важно делать такие проверки, когда копируете что-то на примонтированные устройства. Если запустить процесс копирования при отмонтированном устройстве, то вы просто забьёте весь диск локальной системы, так как все файлы польются на неё.
Я и сам с таким сталкивался, и много раз видел вопросы людей на тему того, что не могут понять, что происходит. Обычно это выглядит так. В момент бэкапа сетевой диск не был примонтирован и мы забили весь корень файлами. А потом в какой-то момент этот диск примонтировался и мы больше не видим те файлы, что были скопированы в точку монтирования в тот момент, когда там не было диска. Его надо отмонтировать и удалить локальные файлы. Если это сразу не просечёшь, то можно много времени потратить на поиск того, что занимает всё свободное место на разделе.
Так что назначайте метки внешним дискам, проверяйте их, делайте проверки монтирования сетевых дисков и т.д. Не выполняйте копирования и синхронизации без этих проверок. А то можно сильно удивиться из-за какой-нибудь неожиданной ошибки. Я реально сталкивался сам с этим не раз, пока не начал постоянно добавлять проверки. Вроде думаешь в локалке всё стабильно, сервера и сеть никто не дёргает, всё в одной стойке стоит. А потом оказалось, что после выключения электричества сервера поднялись не равномерно и сервер с бэкапами поднялся позже остальных. В итоге куда-то не примонтировался сетевой диск для бэкапов и они начали литься локально, пока там место не кончится.
#bash #script
В заметке к системе управления проектам Taiga в комментариях порекомендовали продукт Plane.so. Я посмотрел, он у меня давно уже в todo листе стоит, ещё с лета. Решил развернуть его и попробовать.
Plane — open-source аналог Jira. Бэкенд написан на Python, фронт на JavaScript. Данные хранит в PostgreSQL, файлы в локальном Minio, кэш в Redis, веб сервер использует Nginx. В общем, стандартный современный стек. Всё это упаковано в Docker, так что установка в несколько простых действий:
И можно идти в веб интерфейс. Настройки можно поменять в
Система выглядит очень приятной, шустрой, удобной. Мне понравился интерфейс. Возможности там стандартные для такого рода продуктов. Создаёте проекты и ведёте их. Фиксируете проблемы, отслеживаете исправление, создаёте Kanban доски и т.д. Попробовать можно в бесплатном тарифном плане в облаке.
Монетизируется вся эта штука облачным сервисом и расширенной версией self-hosted установки. Так что это не поделка энтузиастов, а продукт коммерческой компании. Судя по звездам на гитхабе, Plane весьма популярна. Я так сходу в голове всё не припомню, что знаю, но навскидку мне понравилось Plane больше, чем всё, что я видел раньше. Но сразу уточню, что конкретно я никогда не работал с навороченными и большими установками, поэтому мне чем проще и лаконичнее интерфейс, тем лучше. Тот же YouTrack очень навороченный. Его употеешь настраивать, прежде чем запустишь. Он мне нравится, но функциональность там избыточная для небольших команд.
⇨ Сайт / Исходники
#управление_проектами
Plane — open-source аналог Jira. Бэкенд написан на Python, фронт на JavaScript. Данные хранит в PostgreSQL, файлы в локальном Minio, кэш в Redis, веб сервер использует Nginx. В общем, стандартный современный стек. Всё это упаковано в Docker, так что установка в несколько простых действий:
# git clone --depth 1 -b master https://github.com/makeplane/plane.git# cd plane# ./setup.sh# docker compose -f docker-compose-hub.yml upИ можно идти в веб интерфейс. Настройки можно поменять в
.env файлах перед запуском. По умолчанию учётка будет captain@plane.so / password123. Система выглядит очень приятной, шустрой, удобной. Мне понравился интерфейс. Возможности там стандартные для такого рода продуктов. Создаёте проекты и ведёте их. Фиксируете проблемы, отслеживаете исправление, создаёте Kanban доски и т.д. Попробовать можно в бесплатном тарифном плане в облаке.
Монетизируется вся эта штука облачным сервисом и расширенной версией self-hosted установки. Так что это не поделка энтузиастов, а продукт коммерческой компании. Судя по звездам на гитхабе, Plane весьма популярна. Я так сходу в голове всё не припомню, что знаю, но навскидку мне понравилось Plane больше, чем всё, что я видел раньше. Но сразу уточню, что конкретно я никогда не работал с навороченными и большими установками, поэтому мне чем проще и лаконичнее интерфейс, тем лучше. Тот же YouTrack очень навороченный. Его употеешь настраивать, прежде чем запустишь. Он мне нравится, но функциональность там избыточная для небольших команд.
⇨ Сайт / Исходники
#управление_проектами
Мне неизвестны какие-то простые и эффективные способы поиска дубликатов файлов в Linux с использованием стандартного набора системных программ и утилит. Если встаёт такая задача, то приходится искать какие-то сторонние средства. Я предлагаю один из них - Deduplicator.
Deduplicator - небольшая open source программа, написанная на Rust. Написана в основном силами одного человека. Им же и поддерживается. Пока регулярно. Автор, судя по всему, любит свой продукт, поэтому старается обновлять.
Основная особенность Deduplicator - очень быстрая работа. Используется сравнение по размеру и хешам, полученных с помощью растовского алгоритма fxhash (впервые слышу о таком).
Использовать лучше самую свежую версию, потому что там появился вывод результата в json, плюс в одной из недавних версий стали выводиться полные пути дубликатов. До этого выводились обрезанные и было неудобно. Есть проблема с тем, что в репозитории собранная под Linux версия есть только годовой давности. Более свежие предлагается собирать самостоятельно. Не знаю, зачем так сделано, но я в итоге собрал сам, благо сделать это не трудно через растовый пакетный менеджер:
На выходе получаем одиночный бинарник, который можно скопировать на целевой сервер. Сразу скажу про ещё один момент, с которым столкнулся. Deduplicator хочет свежую версию glibc. Не понял точно, какую именно, но на Centos 7 не заработал. Не получилось прогнать на месте. В итоге проверку сделал на бэкап сервере. Там более свежая система - Debian 12, уже успел обновить. На Ubuntu 22 тоже завелась, почистил на своём ноуте дубликаты и домашнем медиасервере. Там дубликатов море было.
Вывод удобно направить сразу в текстовый файл и там уже смотреть:
Он будет в табличном виде. Удобен для ручного просмотра. А если нужна автоматизация, то есть вывод в
Сразу скажу, что на файловых серверах проверил дубликаты чисто для информации. Я не знаю, как системно решать проблемы с дубликатами и надо ли. Можно заменять дубликаты символьными ссылками, но в какой-то момент это может выйти боком.
⇨ Исходники
#fileserver
Deduplicator - небольшая open source программа, написанная на Rust. Написана в основном силами одного человека. Им же и поддерживается. Пока регулярно. Автор, судя по всему, любит свой продукт, поэтому старается обновлять.
Основная особенность Deduplicator - очень быстрая работа. Используется сравнение по размеру и хешам, полученных с помощью растовского алгоритма fxhash (впервые слышу о таком).
Использовать лучше самую свежую версию, потому что там появился вывод результата в json, плюс в одной из недавних версий стали выводиться полные пути дубликатов. До этого выводились обрезанные и было неудобно. Есть проблема с тем, что в репозитории собранная под Linux версия есть только годовой давности. Более свежие предлагается собирать самостоятельно. Не знаю, зачем так сделано, но я в итоге собрал сам, благо сделать это не трудно через растовый пакетный менеджер:
# apt install cargo# cargo install deduplicatorНа выходе получаем одиночный бинарник, который можно скопировать на целевой сервер. Сразу скажу про ещё один момент, с которым столкнулся. Deduplicator хочет свежую версию glibc. Не понял точно, какую именно, но на Centos 7 не заработал. Не получилось прогнать на месте. В итоге проверку сделал на бэкап сервере. Там более свежая система - Debian 12, уже успел обновить. На Ubuntu 22 тоже завелась, почистил на своём ноуте дубликаты и домашнем медиасервере. Там дубликатов море было.
Вывод удобно направить сразу в текстовый файл и там уже смотреть:
# ./deduplicator /mnt/backup/design > deduplicator.txtОн будет в табличном виде. Удобен для ручного просмотра. А если нужна автоматизация, то есть вывод в
--json с помощью соответствующего ключа.Сразу скажу, что на файловых серверах проверил дубликаты чисто для информации. Я не знаю, как системно решать проблемы с дубликатами и надо ли. Можно заменять дубликаты символьными ссылками, но в какой-то момент это может выйти боком.
⇨ Исходники
#fileserver
Вчера вечером проскочила интересная новость на opennet. Я их обычно не комментирую, если они напрямую не касаются меня. В данном случае это не так. Компания Nextcloud GmbH объявила о присоединении почтового клиента Roundcube. Я этот веб клиент использую по умолчанию для всех настроенных почтовых серверов последние лет 10. Может даже больше. До этого пользовался Squirrelmail. Roundcube один из самых популярных, если не самый популярный, автономный веб клиент для почтовых серверов.
Новость на Opennet:
⇨ https://www.opennet.ru/opennews/art.shtml?num=60197
Оригинал:
⇨ https://nextcloud.com/blog/open-source-email-pioneer-roundcube-comes-aboard-nextcloud/
Что по факту будет, пока не понятно. Заявляют, что веб клиент так и будет обособленным, развитие продолжится, команда останется и даже увеличится, слияния кодовых баз не будет. Тогда не понятно, зачем покупали. Надеюсь, что продукт получит новый виток развития, а не заглохнет, как конкурент собственной разработки Nextcloud Mail.
Я ещё почему обратил внимание и подсветил эту новость. В opennet показали недавние проблемы с безопасностью у Roundcube. Там регулярно находят критические уязвимости. Я очень не люблю оставлять веб почту в открытый доступ. Это всегда риск её компрометации. А если начинаешь ограничивать доступ, то сильно падает удобство использования.
Если в условном postfix и dovecot критические уязвимости я вообще не припоминаю, и их можно спокойно оставлять в открытом доступе, то с веб клиентами это не так. C Roundcube всё время приходится следить за обновлениями и своевременно обновлять. Если есть возможность, я закрываю доступ к веб почте либо vpn, либо basic_auth. Пользователям это не нравится. Иногда руководство в приказном порядке настаивает на открытом прямом доступе, принимая риски.
В общем, если у вас веб почта в открытом доступе, уделяйте ей пристальное внимание и по возможности изолируйте от остальных сервисов. Это прям реальная дыра в инфраструктуру. Почтовые сервера чаще всего компрометируют через веб клиенты.
#mailserver
Новость на Opennet:
⇨ https://www.opennet.ru/opennews/art.shtml?num=60197
Оригинал:
⇨ https://nextcloud.com/blog/open-source-email-pioneer-roundcube-comes-aboard-nextcloud/
Что по факту будет, пока не понятно. Заявляют, что веб клиент так и будет обособленным, развитие продолжится, команда останется и даже увеличится, слияния кодовых баз не будет. Тогда не понятно, зачем покупали. Надеюсь, что продукт получит новый виток развития, а не заглохнет, как конкурент собственной разработки Nextcloud Mail.
Я ещё почему обратил внимание и подсветил эту новость. В opennet показали недавние проблемы с безопасностью у Roundcube. Там регулярно находят критические уязвимости. Я очень не люблю оставлять веб почту в открытый доступ. Это всегда риск её компрометации. А если начинаешь ограничивать доступ, то сильно падает удобство использования.
Если в условном postfix и dovecot критические уязвимости я вообще не припоминаю, и их можно спокойно оставлять в открытом доступе, то с веб клиентами это не так. C Roundcube всё время приходится следить за обновлениями и своевременно обновлять. Если есть возможность, я закрываю доступ к веб почте либо vpn, либо basic_auth. Пользователям это не нравится. Иногда руководство в приказном порядке настаивает на открытом прямом доступе, принимая риски.
В общем, если у вас веб почта в открытом доступе, уделяйте ей пристальное внимание и по возможности изолируйте от остальных сервисов. Это прям реальная дыра в инфраструктуру. Почтовые сервера чаще всего компрометируют через веб клиенты.
#mailserver
🔝 Очередной ТОП постов за прошедший месяц. Все самые популярные публикации можно почитать со соответствующему хэштэгу #топ.
Дабы не делать отдельную публикацию, хочу одну мысль донести тут. Чат к заметкам существует для того, чтобы дополнить, дать полезную информацию по теме заметки. Это делается не для того, чтобы поболтать, а чтобы дать дополнительную пользу читателям. Многие заметки из прошлого читают вместе с комментариями. Пустая болтовня в них только зря тратит время читателей.
У меня был отдельный чат для разговоров. Он вырос до нескольких тысяч пользователей, но я понял, что это не мой формат и продал его. Текущий чат к заметкам я не хочу превращать в болталку. Так что прошу использовать его по назначению.
📌 Больше всего просмотров:
◽️Случай на конференции с iftop (11700)
◽️Утилита CFSSL для управления собственным CA (10947)
◽️Прикольный мем про Linux (10776)
📌 Больше всего комментариев:
◽️Новый тип DNS записи - HTTPS (117)
◽️Заметка про замену IE для старых устройств (98)
◽️Бесплатный сервис для хранения 1024 ГБ (97)
📌 Больше всего пересылок:
◽️Ресурс с материалами по Mikrotk (541)
◽️Утилита CFSSL для управления собственным CA (277)
◽️Универсальный ISO образ для установки от netboot.xyz (296)
◽️Статический кэш средствами Nginx (236)
📌 Больше всего реакций:
◽️Заметка про продуктивность с личными примерами (312)
◽️Прикольный мем про Linux (261)
◽️Инфантильность в IT (250)
◽️Ресурс с материалами по Mikrotk (211)
◽️Особенности копирования в Linux с cp (185)
#топ
Дабы не делать отдельную публикацию, хочу одну мысль донести тут. Чат к заметкам существует для того, чтобы дополнить, дать полезную информацию по теме заметки. Это делается не для того, чтобы поболтать, а чтобы дать дополнительную пользу читателям. Многие заметки из прошлого читают вместе с комментариями. Пустая болтовня в них только зря тратит время читателей.
У меня был отдельный чат для разговоров. Он вырос до нескольких тысяч пользователей, но я понял, что это не мой формат и продал его. Текущий чат к заметкам я не хочу превращать в болталку. Так что прошу использовать его по назначению.
📌 Больше всего просмотров:
◽️Случай на конференции с iftop (11700)
◽️Утилита CFSSL для управления собственным CA (10947)
◽️Прикольный мем про Linux (10776)
📌 Больше всего комментариев:
◽️Новый тип DNS записи - HTTPS (117)
◽️Заметка про замену IE для старых устройств (98)
◽️Бесплатный сервис для хранения 1024 ГБ (97)
📌 Больше всего пересылок:
◽️Ресурс с материалами по Mikrotk (541)
◽️Утилита CFSSL для управления собственным CA (277)
◽️Универсальный ISO образ для установки от netboot.xyz (296)
◽️Статический кэш средствами Nginx (236)
📌 Больше всего реакций:
◽️Заметка про продуктивность с личными примерами (312)
◽️Прикольный мем про Linux (261)
◽️Инфантильность в IT (250)
◽️Ресурс с материалами по Mikrotk (211)
◽️Особенности копирования в Linux с cp (185)
#топ
▶️ Недавно вышел необычный сериал по кибербезопасности под названием «Невидимая война». Я и на хабре видел анонс, и тут в комментариях давали ссылку. В нём собраны некоторые истории об угрозах, озвученные довольно известными в индустрии людьми. Да и не только. Там и депутаты, криминалисты, какие-то прочие личности засветились. Больше всего там Кибердеда (Масалович) будет.
Я посмотрел первые две серии. Не могу сказать, что он мне прям понравился. Досматривать не стал. Сделан неплохо, атмосферно. Может для технически несильно подкованной аудитории будет интересно. Но мне показалось повествование каким-то размытым, неконкретным, в основном состоящим из общих слов. В общем, рассказали всё то, что я и так знаю и понимаю. Поэтому интереса особо не было.
Делюсь с вами, может кому-то понравится в выходные посмотреть необычное тематическое видео. Это документальный сериал с художественными вставками. Как я уже сказал, качество исполнения неплохое, так что на любителя.
⇨ Трейлер
⇨ Невидимая война. Серия 1. Что такое кибербезопасность?
⇨ Невидимая война. Серия 2. Кто такие хакеры?
⇨ Невидимая война. Серия 3. Методы работы киберпреступников и киберзащитников.
⇨ Невидимая война. Серия 4. Виды шпионских атак
⇨ Невидимая война. Серия 5. Финансовые киберпреступления и безопасность детей в киберпространстве.
⇨ Невидимая война. Серия 6. Контроль развития нейросетей.
#видео
Я посмотрел первые две серии. Не могу сказать, что он мне прям понравился. Досматривать не стал. Сделан неплохо, атмосферно. Может для технически несильно подкованной аудитории будет интересно. Но мне показалось повествование каким-то размытым, неконкретным, в основном состоящим из общих слов. В общем, рассказали всё то, что я и так знаю и понимаю. Поэтому интереса особо не было.
Делюсь с вами, может кому-то понравится в выходные посмотреть необычное тематическое видео. Это документальный сериал с художественными вставками. Как я уже сказал, качество исполнения неплохое, так что на любителя.
⇨ Трейлер
⇨ Невидимая война. Серия 1. Что такое кибербезопасность?
⇨ Невидимая война. Серия 2. Кто такие хакеры?
⇨ Невидимая война. Серия 3. Методы работы киберпреступников и киберзащитников.
⇨ Невидимая война. Серия 4. Виды шпионских атак
⇨ Невидимая война. Серия 5. Финансовые киберпреступления и безопасность детей в киберпространстве.
⇨ Невидимая война. Серия 6. Контроль развития нейросетей.
#видео
В моём распоряжении временно оказался свежезаказанный сервер с Proxmox VE 8.1 на софтовом рейде mdadm. Пока он не был нагружен рабочей нагрузкой, у меня появилась ограниченная возможность протестировать производительность разных форматов дисков: raw и qcow2. Lvm хранилище не было создано, так что его проверить не получилось. Не стал гонять разные тесты, так как лично меня интересуют только диски и разница между ними.
Конфигурация сервера следующая:
◽CPU: Intel Silver 4314 (16x2.4 ГГц HT)
◽RAM: 64 ГБ — 4 × 16 ГБ DDR4 ECC Reg
◽2 × 960 ГБ SSD Micron_5300_MTFDDAK960TDS
Я так понял, что это бюджетные серверные SSD.
Никогда подробно не изучал методику тестирования жёстких дисков, потому решил повторить комбинированный тест вот из этой статьи на хабре. Взял fio и конфигурацию для гибридного теста на чтение и запись одновременно:
Если будете повторять тест, то не перепутайте имена дисков, потеряете все данные на них. Тест запускал на голом сервере, где кроме гипервизора и одной виртуалки на базе Debian 12 ничего не было, никакой нагрузки. Настройки диска дефолтные:
◽Cache: Default (No cache)
◽Bus/Deviace: SCSI
◽SCSI Controller: VirtIO SCSI single
Сама виртуалка вот такая:
◽CPU: 4 Cores
◽Memory: 8 GiB
Все настройки по умолчанию. То есть взял некий средний вариант виртуалки, который обычно сам использую для разных задач.
Чтобы исключить влияние файловой системы, в виртуалке тесты делал на отдельных виртуальных дисках, один из которых был qcow2, второй raw. Это были вторые диски помимо системного.
Далее здесь в статье была куча результатов тестов, которые я в итоге удалил, потому что они не влезали в заметку, и в них не было большого смысла.
В общем, я провёл несколько тестов, перезагружал гипервизор и проводил снова. На деле я не заметил существенной разницы. Отличия были в пределах погрешностей, как по iops, так и по latency. В связи с этим можно спокойно брать диски qcow2 и не бояться, что они будут медленнее raw. Тестами это не подтверждается. Зато qcow2 экономят место на сервере, так как растут по мере заполнения. Плюс, позволяют делать снепшоты на лету.
Я, честно говоря, думал, что raw будет быстрее процентов на 10% на запись хотя бы из-за того, что у qcow2 должна быть лишняя прослойка за счёт copy-on-write. На деле я этого не заметил. Результат меня заинтересовал, так что попробую при случае ещё раз прогнать где-то эти тесты, только ещё lvm туда добавить. Хотя уже сейчас мне кажется, что там тоже всё это будет в пределах погрешности.
Если кому-то реально интересны цифры, то вот типичный результат теста, который я получал плюс-минус постоянно:
read: IOPS=33.4k, BW=130MiB/s (137MB/s)(50.0GiB/392494msec)
slat (usec): min=2, max=280, avg= 5.23, stdev= 1.27
clat (usec): min=34, max=12271, avg=233.77, stdev=328.07
lat (usec): min=95, max=12276, avg=239.00, stdev=327.98
write: IOPS=71.8k, BW=280MiB/s (294MB/s)(50.0GiB/182675msec); 0 zone resets
slat (usec): min=2, max=159, avg= 4.45, stdev= 1.62
clat (usec): min=36, max=8373, avg=106.48, stdev=56.20
lat (usec): min=44, max=8378, avg=110.93, stdev=56.07
Поясню, что usec это microsecond, то есть latency чтения 233.77 usec = 0,233 ms (миллисекунды). Результаты примерно 30-70к IOPS и 0,1-0,2мс latency при чтении и записи объёма в 50.0GiB. Вроде неплохой результат в общем смысле. Хорошая производительность.
Единственное, что я не понял, почему при одинаковых настройках тестов, результаты записи были неизменно выше, чем чтения. Это воспроизводилось постоянно на всех теста. В графиках на гипервизоре тоже чётко было видно, что во время тестов скорость записи выше, чем чтения.
#proxmox
Конфигурация сервера следующая:
◽CPU: Intel Silver 4314 (16x2.4 ГГц HT)
◽RAM: 64 ГБ — 4 × 16 ГБ DDR4 ECC Reg
◽2 × 960 ГБ SSD Micron_5300_MTFDDAK960TDS
Я так понял, что это бюджетные серверные SSD.
Никогда подробно не изучал методику тестирования жёстких дисков, потому решил повторить комбинированный тест вот из этой статьи на хабре. Взял fio и конфигурацию для гибридного теста на чтение и запись одновременно:
[readtest]blocksize=4kfilename=/dev/sdbrw=randreaddirect=1buffered=0ioengine=libaioiodepth=8[writetest]blocksize=4kfilename=/dev/sdbrw=randwritedirect=1buffered=0ioengine=libaioiodepth=8Если будете повторять тест, то не перепутайте имена дисков, потеряете все данные на них. Тест запускал на голом сервере, где кроме гипервизора и одной виртуалки на базе Debian 12 ничего не было, никакой нагрузки. Настройки диска дефолтные:
◽Cache: Default (No cache)
◽Bus/Deviace: SCSI
◽SCSI Controller: VirtIO SCSI single
Сама виртуалка вот такая:
◽CPU: 4 Cores
◽Memory: 8 GiB
Все настройки по умолчанию. То есть взял некий средний вариант виртуалки, который обычно сам использую для разных задач.
Чтобы исключить влияние файловой системы, в виртуалке тесты делал на отдельных виртуальных дисках, один из которых был qcow2, второй raw. Это были вторые диски помимо системного.
Далее здесь в статье была куча результатов тестов, которые я в итоге удалил, потому что они не влезали в заметку, и в них не было большого смысла.
В общем, я провёл несколько тестов, перезагружал гипервизор и проводил снова. На деле я не заметил существенной разницы. Отличия были в пределах погрешностей, как по iops, так и по latency. В связи с этим можно спокойно брать диски qcow2 и не бояться, что они будут медленнее raw. Тестами это не подтверждается. Зато qcow2 экономят место на сервере, так как растут по мере заполнения. Плюс, позволяют делать снепшоты на лету.
Я, честно говоря, думал, что raw будет быстрее процентов на 10% на запись хотя бы из-за того, что у qcow2 должна быть лишняя прослойка за счёт copy-on-write. На деле я этого не заметил. Результат меня заинтересовал, так что попробую при случае ещё раз прогнать где-то эти тесты, только ещё lvm туда добавить. Хотя уже сейчас мне кажется, что там тоже всё это будет в пределах погрешности.
Если кому-то реально интересны цифры, то вот типичный результат теста, который я получал плюс-минус постоянно:
read: IOPS=33.4k, BW=130MiB/s (137MB/s)(50.0GiB/392494msec)
slat (usec): min=2, max=280, avg= 5.23, stdev= 1.27
clat (usec): min=34, max=12271, avg=233.77, stdev=328.07
lat (usec): min=95, max=12276, avg=239.00, stdev=327.98
write: IOPS=71.8k, BW=280MiB/s (294MB/s)(50.0GiB/182675msec); 0 zone resets
slat (usec): min=2, max=159, avg= 4.45, stdev= 1.62
clat (usec): min=36, max=8373, avg=106.48, stdev=56.20
lat (usec): min=44, max=8378, avg=110.93, stdev=56.07
Поясню, что usec это microsecond, то есть latency чтения 233.77 usec = 0,233 ms (миллисекунды). Результаты примерно 30-70к IOPS и 0,1-0,2мс latency при чтении и записи объёма в 50.0GiB. Вроде неплохой результат в общем смысле. Хорошая производительность.
Единственное, что я не понял, почему при одинаковых настройках тестов, результаты записи были неизменно выше, чем чтения. Это воспроизводилось постоянно на всех теста. В графиках на гипервизоре тоже чётко было видно, что во время тестов скорость записи выше, чем чтения.
#proxmox
В прошлый выходной вы дружно поддержали написание заметок на неайтишную тематику, так что начинаю. Это будет серия заметок на злободневную тему всех тружеников на сидячей работе, страдающих в условиях города гиподинамией. Речь пойдёт про боли в шее, спине, пояснице.
Кто давно читает мой канал, знает, что у меня есть проблемы в этом плане. Я несколько раз делал заметки по этой теме. На текущий момент я существенно продвинулся в изучении и лечении своих болячек, так что решил поделиться. Уверен, это будет полезно огромному количеству читателей, так как тема злободневная и актуальная для многих людей. Сейчас почти не встретишь человека 30+ без проблем с опорно-двигательным аппаратом.
Тема большая, даже не знаю, как лучше начать. У меня где-то с 25 лет начала периодически болеть шея, с 35 - поясница. Сейчас мне 39. Примерно в 30 лет я понял, что у меня проблема, которую нужно начинать решать, иначе будет хуже. Я прошёл по стандартной схеме, по которой ходят плюс-минус все, кто не в теме и пытается поправить здоровье.
Сначала решил попробовать помочь себе самостоятельно. Тут я прошёлся по всем существующим граблям: ходил в тренажёрный зал, плавал, в том числе с тренером, занимался со своим весом на турнике и брусьях. Становилось только хуже. Понял, что надо идти к врачу. Подобными проблемами почему-то занимаются неврологи, хотя с нервами у меня было всё в порядке.
Дальше я попал в жернова современной медицины, которая оказалась полностью бессильна перед моим заболеванием. Тут тоже всё как у всех. Сделал МРТ, там протрузии, грыжи, сколиоз. И началось - уколы, лекарства, ЛФК, мануальщики, остеопаты. Быстро понял, что ничего не помогает, а даёт только временное облегчение. Боли неизменно возвращались и год от года становилось хуже.
Потом мне повезло. Я попал в зал ЛФК, где работал реальный специалист, увлечённый своим делом. Он лет 20 принимает людей лично и ведёт их вместе с помощниками в зале. Здесь впервые посмотрели на меня внимательно, послушали не на уровне конвейера, а вникли в проблемы, выявили проблемные группы мышц и дали упражнения, которые реально начали помогать. Через полгода регулярного (2-3 раза в неделю) посещения этого зала у меня ушли все боли, немного увеличилась амплитуда движения, уменьшился сколиоз, перепад плеч, небольшая скрученность корпуса относительно таза. Ну и в целом я стал чувствовать себя нормально. Успокоился и понял, что так уже можно нормально жить.
Проблема была в том, что зал очень далеко от меня. Я ездил туда 1,5-2 часа в один конец, 2-3 часа тренировки и 1,5 часа обратная дорога. Можете сами представить, сколько времени у меня уходило на эти занятия (в этот момент я перестал писать статьи). Дома или где-то в обычном зале у меня не получалось воспроизвести необходимый объём и правильность тренировок, чтобы получить стабильный эффект.
Примерно 5 лет я занимался и жил в таком режиме. Экспериментировал с рабочими местами, матрасами, подушками и т.д. Со временем стал замечать, что понемногу ситуация ухудшается. Ещё обращал внимание, что не получается растянуться. Я неизменно тянулся все эти года, но результат был околонулевой. Например, я не мог достать руками до пола, хотя в норме здоровый человек даже без специальных тренировок должен это делать. Неделю не тянешься и теряешь все результаты. Понимал, что так быть не должно.
Этой осенью я начал снова погружаться в тему болей в спине. Просто представил себя через 20 лет и понял, что надо действовать уже сейчас. Пробовал сам разные варианты растяжек и упражнений. Доставал своего тренера различными вопросами. Уже тогда начал получать от него информацию в духе, что реально болят не грыжи и операции не избавляют людей от болей и проблем. И вообще ни от чего не избавляют, кроме как от денег и здоровья. Я не был готов принять такую информацию, думал, что это какие-то странности. Зачем тогда людям их делают? Но в голове информация осела, и я начал копать.
Что в итоге накопал, читайте в следующей заметке.
👇👇👇
#разное #здоровье #спина
Кто давно читает мой канал, знает, что у меня есть проблемы в этом плане. Я несколько раз делал заметки по этой теме. На текущий момент я существенно продвинулся в изучении и лечении своих болячек, так что решил поделиться. Уверен, это будет полезно огромному количеству читателей, так как тема злободневная и актуальная для многих людей. Сейчас почти не встретишь человека 30+ без проблем с опорно-двигательным аппаратом.
Тема большая, даже не знаю, как лучше начать. У меня где-то с 25 лет начала периодически болеть шея, с 35 - поясница. Сейчас мне 39. Примерно в 30 лет я понял, что у меня проблема, которую нужно начинать решать, иначе будет хуже. Я прошёл по стандартной схеме, по которой ходят плюс-минус все, кто не в теме и пытается поправить здоровье.
Сначала решил попробовать помочь себе самостоятельно. Тут я прошёлся по всем существующим граблям: ходил в тренажёрный зал, плавал, в том числе с тренером, занимался со своим весом на турнике и брусьях. Становилось только хуже. Понял, что надо идти к врачу. Подобными проблемами почему-то занимаются неврологи, хотя с нервами у меня было всё в порядке.
Дальше я попал в жернова современной медицины, которая оказалась полностью бессильна перед моим заболеванием. Тут тоже всё как у всех. Сделал МРТ, там протрузии, грыжи, сколиоз. И началось - уколы, лекарства, ЛФК, мануальщики, остеопаты. Быстро понял, что ничего не помогает, а даёт только временное облегчение. Боли неизменно возвращались и год от года становилось хуже.
Потом мне повезло. Я попал в зал ЛФК, где работал реальный специалист, увлечённый своим делом. Он лет 20 принимает людей лично и ведёт их вместе с помощниками в зале. Здесь впервые посмотрели на меня внимательно, послушали не на уровне конвейера, а вникли в проблемы, выявили проблемные группы мышц и дали упражнения, которые реально начали помогать. Через полгода регулярного (2-3 раза в неделю) посещения этого зала у меня ушли все боли, немного увеличилась амплитуда движения, уменьшился сколиоз, перепад плеч, небольшая скрученность корпуса относительно таза. Ну и в целом я стал чувствовать себя нормально. Успокоился и понял, что так уже можно нормально жить.
Проблема была в том, что зал очень далеко от меня. Я ездил туда 1,5-2 часа в один конец, 2-3 часа тренировки и 1,5 часа обратная дорога. Можете сами представить, сколько времени у меня уходило на эти занятия (в этот момент я перестал писать статьи). Дома или где-то в обычном зале у меня не получалось воспроизвести необходимый объём и правильность тренировок, чтобы получить стабильный эффект.
Примерно 5 лет я занимался и жил в таком режиме. Экспериментировал с рабочими местами, матрасами, подушками и т.д. Со временем стал замечать, что понемногу ситуация ухудшается. Ещё обращал внимание, что не получается растянуться. Я неизменно тянулся все эти года, но результат был околонулевой. Например, я не мог достать руками до пола, хотя в норме здоровый человек даже без специальных тренировок должен это делать. Неделю не тянешься и теряешь все результаты. Понимал, что так быть не должно.
Этой осенью я начал снова погружаться в тему болей в спине. Просто представил себя через 20 лет и понял, что надо действовать уже сейчас. Пробовал сам разные варианты растяжек и упражнений. Доставал своего тренера различными вопросами. Уже тогда начал получать от него информацию в духе, что реально болят не грыжи и операции не избавляют людей от болей и проблем. И вообще ни от чего не избавляют, кроме как от денег и здоровья. Я не был готов принять такую информацию, думал, что это какие-то странности. Зачем тогда людям их делают? Но в голове информация осела, и я начал копать.
Что в итоге накопал, читайте в следующей заметке.
👇👇👇
#разное #здоровье #спина
В этот момент я уже чётко понимал, что у меня ярко выраженные проблемы с некоторыми мышцами, которые:
▪ Не растягиваются.
▪ Слишком упругие и жёсткие.
▪ Начинают болеть, если их хоть немного перегрузить (практический опыт из ЛФК и других тренировок в обычном зале).
То есть я уже созрел для принятия нужной информации. В это время поздним вечером мне youtubе случайно в рекомендациях показывает видео Эдуарда Конкина - Грыжа поясничного отдела позвоночника. Моя история лечения, которому уже 6 лет. Хотел отложить просмотр, так как был уже час ночи, а ролик очень длинный. Но что-то подсказало, что надо смотреть сейчас. Я посмотрел его полностью.
После просмотра я всё понял. История похожа на мою, только я в нужное время попал к хорошему специалисту и это меня спасло от стремительного развития болезни. Понял, что причина моих болей - миофасциальный болевой синдром или триггерная болезнь мышц, как и большинства людей с болями в спине в разной степени тяжести.
Дальше всё пошло по накатанной. Я начал впитывать информацию, которой оказалось море. Дам общие мазки в виде конкретных ссылок, которые остались в памяти и зафиксировались. Вот истории людей с этим заболеванием:
◽Миофасциальный синдром. История болезни и лечения
◽Краткая история лечения МФС. Грыжа диска. Растяжки при МФС
◽Миофасциальный синдром. История Ирины Мельник
◽Как Ютуб спас мою жизнь или Как вылечить спину
◽ЛЕЧЕНИЕ НАЙДЕНО! ГРЫЖИ ПОЗВОНОЧНИКА, ТРИГГЕРНЫЕ ТОЧКИ(МФС)
Люди были настолько поражены, пройдя все круги ада официальной медицины, что не пожалели своего времени и записали длинные ролики, рассказав про своё выздоровление. А кто-то стал лечить, как мог, таких же страдальцев, потому что больше просто некому.
Каналы профессиональных врачей, которые лечат МФС:
◽Андрей Лукьянов (Кисловодск)
◽Юрий Верхотуров (Москва)
Каналы фактически самоучек (не врачей), которые тоже лечат этот недуг:
◽Алексей Тарасенко (Кисловодск)
◽Алексей Наговицын (Подмосковье)
◽Владимир Яковенко (Краснодар)
◽Александр, Барнаул
◽Dr. Dubuk (Одесса)
Я изучил все представленные каналы. Как мне кажется, разобрался с этой темой. Ещё немного информации:
- MioClinic - "клиника" в Москве, которую открыл Эдуард Конкин, про которого я рассказал в начале.
- Статья в Медицинской газете - Павел ЖАРКОВ, главный научный сотрудник Российского научного центра рентгенорадиологии, профессор.
- Медицинская книга - Трэвелл и Симонс, Миофасциальные боли и дисфункции, 3 тома.
- Медицинская книга - Георгий Иваничев, Мануальная терапия.
Книги издавались давно, в продаже не найти. Все врачи и самоучки, которых я видел, лечат по книге Трэвелл и Симонс.
Кратко соберу информацию по миофасциальному синдрому. Признаками болезни являются:
1️⃣ Сокращение объёма движения мышц, ухудшается растяжка. Причём это не мышечные спазмы, которые вызывают нервные импульсы. Это самоподдерживаемое сжатие мышц. То есть мышцы без внешних сигналов остаются в таком состоянии. И могут в нём находиться годами и десятилетиями. Это я у себя наблюдаю давно.
2️⃣ В мышцах появляются триггерные точки в виде небольших или больших уплотнений. При надавливании на них возникает острая боль, которая может простреливать по всей длине мышцы. Боль очень сильная, её ни с чем не спутать. Я много лет иногда наблюдал эту боль, когда супруга делала небольшой расслабляющий массаж спины. Были места, где очень больно. Я не понимал, что это такое. Думал, почки что ли так болят при надавливании или какие-то другие внутренние органы. Когда узнал про триггерную болезнь, нашёл у себя множество ярко выраженных точек, которые заметны даже при самостоятельной пальпации. Удивительно, но за столько лет ни один врач это не проделал со мной.
3️⃣ Если больные мышцы нагрузить в зале или на физической работе, то будет обострение в виде болей, невозможности разогнуться или выполнить какие-то движения.
4️⃣ Мышцы могут либо постоянно болеть, либо во время обострений.
Далее рассмотрю основные причины заболевания и методику лечения.
👇👇👇
#разное #здоровье #спина
▪ Не растягиваются.
▪ Слишком упругие и жёсткие.
▪ Начинают болеть, если их хоть немного перегрузить (практический опыт из ЛФК и других тренировок в обычном зале).
То есть я уже созрел для принятия нужной информации. В это время поздним вечером мне youtubе случайно в рекомендациях показывает видео Эдуарда Конкина - Грыжа поясничного отдела позвоночника. Моя история лечения, которому уже 6 лет. Хотел отложить просмотр, так как был уже час ночи, а ролик очень длинный. Но что-то подсказало, что надо смотреть сейчас. Я посмотрел его полностью.
После просмотра я всё понял. История похожа на мою, только я в нужное время попал к хорошему специалисту и это меня спасло от стремительного развития болезни. Понял, что причина моих болей - миофасциальный болевой синдром или триггерная болезнь мышц, как и большинства людей с болями в спине в разной степени тяжести.
Дальше всё пошло по накатанной. Я начал впитывать информацию, которой оказалось море. Дам общие мазки в виде конкретных ссылок, которые остались в памяти и зафиксировались. Вот истории людей с этим заболеванием:
◽Миофасциальный синдром. История болезни и лечения
◽Краткая история лечения МФС. Грыжа диска. Растяжки при МФС
◽Миофасциальный синдром. История Ирины Мельник
◽Как Ютуб спас мою жизнь или Как вылечить спину
◽ЛЕЧЕНИЕ НАЙДЕНО! ГРЫЖИ ПОЗВОНОЧНИКА, ТРИГГЕРНЫЕ ТОЧКИ(МФС)
Люди были настолько поражены, пройдя все круги ада официальной медицины, что не пожалели своего времени и записали длинные ролики, рассказав про своё выздоровление. А кто-то стал лечить, как мог, таких же страдальцев, потому что больше просто некому.
Каналы профессиональных врачей, которые лечат МФС:
◽Андрей Лукьянов (Кисловодск)
◽Юрий Верхотуров (Москва)
Каналы фактически самоучек (не врачей), которые тоже лечат этот недуг:
◽Алексей Тарасенко (Кисловодск)
◽Алексей Наговицын (Подмосковье)
◽Владимир Яковенко (Краснодар)
◽Александр, Барнаул
◽Dr. Dubuk (Одесса)
Я изучил все представленные каналы. Как мне кажется, разобрался с этой темой. Ещё немного информации:
- MioClinic - "клиника" в Москве, которую открыл Эдуард Конкин, про которого я рассказал в начале.
- Статья в Медицинской газете - Павел ЖАРКОВ, главный научный сотрудник Российского научного центра рентгенорадиологии, профессор.
- Медицинская книга - Трэвелл и Симонс, Миофасциальные боли и дисфункции, 3 тома.
- Медицинская книга - Георгий Иваничев, Мануальная терапия.
Книги издавались давно, в продаже не найти. Все врачи и самоучки, которых я видел, лечат по книге Трэвелл и Симонс.
Кратко соберу информацию по миофасциальному синдрому. Признаками болезни являются:
1️⃣ Сокращение объёма движения мышц, ухудшается растяжка. Причём это не мышечные спазмы, которые вызывают нервные импульсы. Это самоподдерживаемое сжатие мышц. То есть мышцы без внешних сигналов остаются в таком состоянии. И могут в нём находиться годами и десятилетиями. Это я у себя наблюдаю давно.
2️⃣ В мышцах появляются триггерные точки в виде небольших или больших уплотнений. При надавливании на них возникает острая боль, которая может простреливать по всей длине мышцы. Боль очень сильная, её ни с чем не спутать. Я много лет иногда наблюдал эту боль, когда супруга делала небольшой расслабляющий массаж спины. Были места, где очень больно. Я не понимал, что это такое. Думал, почки что ли так болят при надавливании или какие-то другие внутренние органы. Когда узнал про триггерную болезнь, нашёл у себя множество ярко выраженных точек, которые заметны даже при самостоятельной пальпации. Удивительно, но за столько лет ни один врач это не проделал со мной.
3️⃣ Если больные мышцы нагрузить в зале или на физической работе, то будет обострение в виде болей, невозможности разогнуться или выполнить какие-то движения.
4️⃣ Мышцы могут либо постоянно болеть, либо во время обострений.
Далее рассмотрю основные причины заболевания и методику лечения.
👇👇👇
#разное #здоровье #спина
Скорость развития заболевания или болезненные ощущения при МФС будут у всех сильно разные. Представленные истории людей - это очень тяжёлые случаи, когда люди уже и ходить толком не могли. Конкретно у меня заболевание уже хроническое, но в острой форме оно не проявлялось, так как помогала профилактика. Но профилактика не давала излечения, а переводила болезнь в хроническую стадию.
📌 Основные причины развития МФС:
1️⃣ Травма, в результате которой нарушается симметрия туловища и работа мышц. Скорее всего у меня с этого всё и началось в юности, а далее усугубилось сидячей работой.
2️⃣ Перегрузка мышц, в том числе в результате травмы. Можно что-то поднять очень тяжёлое и надорваться, повредить мышцу. У кого-то само пройдёт, а у кого-то начнёт развиваться триггерная болезнь. Также к перегрузке мышц ведёт длительное статическое положение в неудобной позе. Это как раз наша тема. Долго сидите в неудобной позе, когда, к примеру, голова немного вперёд наклонена. Постоянно вижу таких людей. В итоге перегружаете мышцы шейного отдела. То же самое с поясницей и какими-то другими мышцами.
Длительное статическое напряжение очень вредно. В этом кроется секрет, почему люди, попробовавшие чередовать работу то сидя, то стоя, получают облегчение, что я лично проверил на собственно опыте. Меняя положение тела вы просто даёте отдыхать одним мышцам и напрягаете другие. Это хорошая профилактика заболевания. Важно именно чередовать, а не работать в одном и том же положении.
3️⃣ Сильное переохлаждение.
4️⃣ Нехватка железа, витаминов группы Б, гормональные сбои и нарушение работы щитовидной железы.
📌 Основные способы лечения. Как я уже сказал, они все представлены в книге авторов Трэвелл и Симoнс.
1️⃣ Растяжение больных мышц с помощью технологии ПИР (постизометрическая релаксация). Тянуть можно только так. Если растягивать через силу, как обычно все тянутся, то будет хуже. Больные мышцы так просто не растянуть. Растяжка может помочь только на начальной стадии, в самых простых случаях. Во всех остальных она дополняет другие способы.
2️⃣ Растяжение больных мышц, кратковременно охлаждённых какими-то препаратами. Я не видел, чтобы у нас кто-то практиковал подобное, потому что препаратов таких, как я понял, нет в продаже.
3️⃣ Прокалывание триггерных точек иглой. Сложность в том, что не всегда удаётся точно попасть в нужную точку. Не всем это помогает полностью избавиться от заболевания. Этот способ тоже комбинируют с остальными.
4️⃣ Миопрессура. Это мануальная терапия, но она не похожа на всё то, что предлагают обычные мануальщики (пример, как это выглядит для шеи). Больные мышцы с триггерами разминают с большим усилием. Это очень болезненно. Обычно миопрессуру совмещают с растяжкой и прокалываниями. Тяжелые случаи без миопрессуры не вылечить. А большинство пациентов очень тяжёлые, так как в попытках излечиться другими способами теряют драгоценное время и превращаются в хроников.
Вот примеры, как должно проходить обследование пациента при болях в спине:
◽Юрий Верхотуров. Это простой случай и начальная стадия. Тут же показано, как его предлагают лечить только растяжкой.
◽Эдуард Конкин. В описании к видео вся процедура описана текстом. Помимо просмотра, можете и её прочитать.
Ещё несколько важных моментов:
● 5 самых частых заблуждений о мышцах
● Правда о защемлении нерва
● Межпозвонковая грыжа. Делать или нет операцию?
"Болевых рецепторов нет ни в позвонках, ни в межпозвонковых дисках, ни в костях, ни в суставных хрящах, ни в спинном мозге, ни в корешках спинномозговых нервов, ни в самих нервах, как нет их в ногтях и волосах". "...источником боли могут быть только те анатомические структуры, в которых есть болевые рецепторы".
В заключительной части расскажу, что конкретно делаю я для излечения.
👇👇👇
#разное #здоровье #спина
📌 Основные причины развития МФС:
1️⃣ Травма, в результате которой нарушается симметрия туловища и работа мышц. Скорее всего у меня с этого всё и началось в юности, а далее усугубилось сидячей работой.
2️⃣ Перегрузка мышц, в том числе в результате травмы. Можно что-то поднять очень тяжёлое и надорваться, повредить мышцу. У кого-то само пройдёт, а у кого-то начнёт развиваться триггерная болезнь. Также к перегрузке мышц ведёт длительное статическое положение в неудобной позе. Это как раз наша тема. Долго сидите в неудобной позе, когда, к примеру, голова немного вперёд наклонена. Постоянно вижу таких людей. В итоге перегружаете мышцы шейного отдела. То же самое с поясницей и какими-то другими мышцами.
Длительное статическое напряжение очень вредно. В этом кроется секрет, почему люди, попробовавшие чередовать работу то сидя, то стоя, получают облегчение, что я лично проверил на собственно опыте. Меняя положение тела вы просто даёте отдыхать одним мышцам и напрягаете другие. Это хорошая профилактика заболевания. Важно именно чередовать, а не работать в одном и том же положении.
3️⃣ Сильное переохлаждение.
4️⃣ Нехватка железа, витаминов группы Б, гормональные сбои и нарушение работы щитовидной железы.
📌 Основные способы лечения. Как я уже сказал, они все представлены в книге авторов Трэвелл и Симoнс.
1️⃣ Растяжение больных мышц с помощью технологии ПИР (постизометрическая релаксация). Тянуть можно только так. Если растягивать через силу, как обычно все тянутся, то будет хуже. Больные мышцы так просто не растянуть. Растяжка может помочь только на начальной стадии, в самых простых случаях. Во всех остальных она дополняет другие способы.
2️⃣ Растяжение больных мышц, кратковременно охлаждённых какими-то препаратами. Я не видел, чтобы у нас кто-то практиковал подобное, потому что препаратов таких, как я понял, нет в продаже.
3️⃣ Прокалывание триггерных точек иглой. Сложность в том, что не всегда удаётся точно попасть в нужную точку. Не всем это помогает полностью избавиться от заболевания. Этот способ тоже комбинируют с остальными.
4️⃣ Миопрессура. Это мануальная терапия, но она не похожа на всё то, что предлагают обычные мануальщики (пример, как это выглядит для шеи). Больные мышцы с триггерами разминают с большим усилием. Это очень болезненно. Обычно миопрессуру совмещают с растяжкой и прокалываниями. Тяжелые случаи без миопрессуры не вылечить. А большинство пациентов очень тяжёлые, так как в попытках излечиться другими способами теряют драгоценное время и превращаются в хроников.
Вот примеры, как должно проходить обследование пациента при болях в спине:
◽Юрий Верхотуров. Это простой случай и начальная стадия. Тут же показано, как его предлагают лечить только растяжкой.
◽Эдуард Конкин. В описании к видео вся процедура описана текстом. Помимо просмотра, можете и её прочитать.
Ещё несколько важных моментов:
● 5 самых частых заблуждений о мышцах
● Правда о защемлении нерва
● Межпозвонковая грыжа. Делать или нет операцию?
"Болевых рецепторов нет ни в позвонках, ни в межпозвонковых дисках, ни в костях, ни в суставных хрящах, ни в спинном мозге, ни в корешках спинномозговых нервов, ни в самих нервах, как нет их в ногтях и волосах". "...источником боли могут быть только те анатомические структуры, в которых есть болевые рецепторы".
В заключительной части расскажу, что конкретно делаю я для излечения.
👇👇👇
#разное #здоровье #спина
После того, как я узнал про МФС, связался с Эдуардом Конкиным, так как он тоже живёт в Москве. Приехал к нему на приём. Стоит он символических денег. На тот момент я ещё немного сомневался в том, что у меня именно МФС.
Эдуард очень быстро нашёл несколько триггерных точек. Нажал со средним усилием на больную мышцу, у меня аж глаза на лоб полезли и я закричал. Никогда не испытывал такой боли. Потом так же понажимал на здоровые мышцы, такой боли не было. Я сразу убедился, что вот она, болезнь. Все признаки налицо.
Он узнал у меня про мои проблемные места: поясница и шея. В пояснице немного размял с усилием триггерную точку. Было очень больно. В шее тоже болючую точку проткнул иглой. Немного ещё посмотрел на меня, покрутил, понажимал. Убедился, что у меня кроме МФС ничего нет. Все признаки именно этой болезни. Дал контакт человека, который занимается миопрессурой (тоже бывший больной).
На следующий день у меня на пояснице, где разминали триггер, был синяк, место болело. Но что самое удивительное, пояснице стало легче. Ушла ноющая боль, растяжка улучшилась. То же самое на шее. Появилась лёгкость движений, головная боль ушла. У меня иногда голова могла болеть по нескольку дней. Это очень выматывает. Я уже научился чувствовать приближение боли. После прокола триггера почувствовал, что вероятность боли в голове ушла дальше.
После этого я полностью убедился в своём диагнозе и начал определяться с лечением. Изучил все материалы, что нашёл в ютубе. Понял, что полностью сам излечиться не смогу, поэтому стал ходить на миопрессуру. Сразу стало легче. Убрал все подкладки под поясницу, которые купил в машину. В последний год уже не мог без ноющей боли долго сидеть за рулём. Начал доставать руками до пола. Мог сидеть и работать на любом стуле, а не только на удобном кресле с поддержкой поясницы, которая со временем уже тоже не помогала.
С поясницей улучшения заметил сразу, а вот с шеей нет. Там проблема из юности и мышцы скорее всего уже поражены фиброзом. Это следствие запущенного миофасциального синдрома. Фиброз лечится очень тяжело и долго. Сейчас я нахожусь в стадии планирования долгосрочного лечения. Есть предварительные договорённости с одним специалистом из другого города, который готов меня взять на месячный курс. Если всё сложится, то потом отдельно об этом напишу.
📌 Дома для себя сформировал список регулярных утренних мероприятий на основе рекомендаций доктора Лукьянова (один, два):
1️⃣ Самостоятельная прокатка триггеров спины с помощью пластиковых шариков.
2️⃣ Растяжка по рекомендациям из книги Трэвелл и Симонс. За основу взял примеры вот этой женщины.
3️⃣ Прогревание под горячим душем, потом минут 10 лежу под тёплым одеялом.
Ну и регулярные походы в ЛФК и на миопрессуру. Так как туда не удаётся попасть чаще двух раз в неделю, а этого мало, приходится дома трудиться самому. Делаю этот комплекс через день, так как на следующий день после прокатки спины болят мышцы.
Если у вас болит спина или шея, не терпите боль и не откладывайте. Чем быстрее начать лечение, тем оно легче и дешевле будет. В норме у здорового человека ничего болеть не должно. Постарайтесь найти специалиста, который поможет. Самолечением тут себя не вытащить. Можно только временно облегчить ситуацию. Самому все больные мышцы не обработать. Это физически невозможно, так как желательно расслабляться, а когда сам себе делаешь - напрягаешься.
❗️Я потратил несколько часов на осмысление, сбор материала и написание этого цикла заметок. Не стал растягивать и опубликовал всё за раз. Надеюсь, он кому-то будет полезен и поможет сохранить здоровье. По какой-то неведомой причине, в стандартах врачей в современных больницах напрочь отсутствует это заболевание, хотя оно подробно исследовано и описано в том числе профессиональными врачами. Активность на ютубе и очереди на месяцы к врачам подтверждают, что страдает ею множество людей. Фактически, большая часть болей в спине вызваны именно больными мышцами.
Будьте здоровы и не болейте.
#разное #здоровье #спина
Эдуард очень быстро нашёл несколько триггерных точек. Нажал со средним усилием на больную мышцу, у меня аж глаза на лоб полезли и я закричал. Никогда не испытывал такой боли. Потом так же понажимал на здоровые мышцы, такой боли не было. Я сразу убедился, что вот она, болезнь. Все признаки налицо.
Он узнал у меня про мои проблемные места: поясница и шея. В пояснице немного размял с усилием триггерную точку. Было очень больно. В шее тоже болючую точку проткнул иглой. Немного ещё посмотрел на меня, покрутил, понажимал. Убедился, что у меня кроме МФС ничего нет. Все признаки именно этой болезни. Дал контакт человека, который занимается миопрессурой (тоже бывший больной).
На следующий день у меня на пояснице, где разминали триггер, был синяк, место болело. Но что самое удивительное, пояснице стало легче. Ушла ноющая боль, растяжка улучшилась. То же самое на шее. Появилась лёгкость движений, головная боль ушла. У меня иногда голова могла болеть по нескольку дней. Это очень выматывает. Я уже научился чувствовать приближение боли. После прокола триггера почувствовал, что вероятность боли в голове ушла дальше.
После этого я полностью убедился в своём диагнозе и начал определяться с лечением. Изучил все материалы, что нашёл в ютубе. Понял, что полностью сам излечиться не смогу, поэтому стал ходить на миопрессуру. Сразу стало легче. Убрал все подкладки под поясницу, которые купил в машину. В последний год уже не мог без ноющей боли долго сидеть за рулём. Начал доставать руками до пола. Мог сидеть и работать на любом стуле, а не только на удобном кресле с поддержкой поясницы, которая со временем уже тоже не помогала.
С поясницей улучшения заметил сразу, а вот с шеей нет. Там проблема из юности и мышцы скорее всего уже поражены фиброзом. Это следствие запущенного миофасциального синдрома. Фиброз лечится очень тяжело и долго. Сейчас я нахожусь в стадии планирования долгосрочного лечения. Есть предварительные договорённости с одним специалистом из другого города, который готов меня взять на месячный курс. Если всё сложится, то потом отдельно об этом напишу.
📌 Дома для себя сформировал список регулярных утренних мероприятий на основе рекомендаций доктора Лукьянова (один, два):
1️⃣ Самостоятельная прокатка триггеров спины с помощью пластиковых шариков.
2️⃣ Растяжка по рекомендациям из книги Трэвелл и Симонс. За основу взял примеры вот этой женщины.
3️⃣ Прогревание под горячим душем, потом минут 10 лежу под тёплым одеялом.
Ну и регулярные походы в ЛФК и на миопрессуру. Так как туда не удаётся попасть чаще двух раз в неделю, а этого мало, приходится дома трудиться самому. Делаю этот комплекс через день, так как на следующий день после прокатки спины болят мышцы.
Если у вас болит спина или шея, не терпите боль и не откладывайте. Чем быстрее начать лечение, тем оно легче и дешевле будет. В норме у здорового человека ничего болеть не должно. Постарайтесь найти специалиста, который поможет. Самолечением тут себя не вытащить. Можно только временно облегчить ситуацию. Самому все больные мышцы не обработать. Это физически невозможно, так как желательно расслабляться, а когда сам себе делаешь - напрягаешься.
❗️Я потратил несколько часов на осмысление, сбор материала и написание этого цикла заметок. Не стал растягивать и опубликовал всё за раз. Надеюсь, он кому-то будет полезен и поможет сохранить здоровье. По какой-то неведомой причине, в стандартах врачей в современных больницах напрочь отсутствует это заболевание, хотя оно подробно исследовано и описано в том числе профессиональными врачами. Активность на ютубе и очереди на месяцы к врачам подтверждают, что страдает ею множество людей. Фактически, большая часть болей в спине вызваны именно больными мышцами.
Будьте здоровы и не болейте.
#разное #здоровье #спина
Кажется, я ни разу не упоминал про простой и быстрый способ отладки bash скрипта. Для этого достаточно в самое начало написать:
В этом случай bash начнёт выводить в консоль каждую команду, которую он выполняет. Успешно выполненная команда помечается плюсом в начале строки. Не сказать, что это прям очень сильно помогает отладить, если есть ошибка, но в целом проще и удобнее. Особенно если скрипт большой, с условиями, вычислением переменных и т.д. Вы всё будете видеть на каждом этапе.
Покажу как это работает на простом скрипте по добавлению swap в систему:
Запускаем скрипт:
Благодаря
Когда не знал про
#bash #script
set -xВ этом случай bash начнёт выводить в консоль каждую команду, которую он выполняет. Успешно выполненная команда помечается плюсом в начале строки. Не сказать, что это прям очень сильно помогает отладить, если есть ошибка, но в целом проще и удобнее. Особенно если скрипт большой, с условиями, вычислением переменных и т.д. Вы всё будете видеть на каждом этапе.
Покажу как это работает на простом скрипте по добавлению swap в систему:
#!/bin/bashset -xread -p 'Enter swap size in megabytes: ' size_mbsize_kb=$((1024*${size_mb}))dd if=/dev/zero of=/swap bs=1024 count=${size_kb}chmod 0600 /swapmkswap /swapswapon /swapif [ "$(grep '/swap' /etc/fstab)" ]; then echo "Error: file /etc/fstab already has 'Swap' record"else echo "Add Swap record to /etc/fstab" echo -e '\n/swap swap swap defaults 0 0' >> /etc/fstabfiswapon --showЗапускаем скрипт:
# ./script.sh + read -p 'Enter swap size in megabytes: ' size_mbEnter swap size in megabytes: 512+ size_kb=524288+ dd if=/dev/zero of=/swap bs=1024 count=524288524288+0 records in524288+0 records out536870912 bytes (537 MB, 512 MiB) copied, 1.26859 s, 423 MB/s+ chmod 0600 /swap+ mkswap /swapSetting up swapspace version 1, size = 512 MiB (536866816 bytes)no label, UUID=e873faad-881e-4df0-b25f-23580b952738+ swapon /swap++ grep /swap /etc/fstab+ '[' '' ']'+ echo 'Add Swap record to /etc/fstab'Add Swap record to /etc/fstab+ echo -e '\n/swap swap swap defaults 0 0'+ swapon --showNAME TYPE SIZE USED PRIO/swap file 512M 0B -2Благодаря
set -x мы видим каждое действие, которое выполняет скрипт. Оно начинается с +, а дальше виден стандартный вывод после этого действия. Так разбирать работу скрипта проще, потому что в командах видны все переменные. В этом примере это не очень актуально, а когда они будут неявно указаны, а вычисляемые, то это может сильно помочь. Когда не знал про
set -x, выводил нужные мне переменные в разных местах скрипта с помощью echo во время отладки, чтобы понимать, что там происходит после каждой команды. Но этот путь намного проще.#bash #script
Примерно пол года назад я участвовал во внедрении Rocket.Chat в небольшой организации, где около 50-ти пользователей чата. Делал об этом заметку. Чат прижился, накопился некоторый опыт использования, так что могу поделиться информацией.
В общем и целом с чатом никаких особых проблем не возникло. Я лично занимался только серверной частью. Создавал учётки, подключал пользователей, устанавливал им клиента другой человек, непосредственно работающий там.
С установкой и обслуживанием больших проблем не было. Установил всё стандартно, только прикрепляемые файлы в директорию из базы вынул. Об этом писал в первой заметке. Запустил в Docker. Хватило виртуалки 2 CPU, 4GB RAM. Чат ровно один раз протёк по памяти, пришлось ребутнуть виртуальную машину. Мониторинг почти сразу оповестил, что окно логина недоступно, перезагрузил, пользователи даже не успели заметить.
Мониторинг настроил в Zabbix. Ничего особо не придумывал. Стандартный шаблон для Linux и мониторинг стартовой страницы сервиса. Внутренние метрики не стал мониторить. Нужды в этом не возникло.
Явно не нравится перевод на русский язык. Ни мне, ни пользователям. Пытался через встроенную функциональность в админке перевести самостоятельно некоторые вещи. Не получилось. Не знаю, по какой причине, но мой перевод не отображался. В самой админке по настройкам сильно не лазил. Даже не помню, что менял. Что-то по мелочи. Особо можно не вникать, если не хочется. По умолчанию всё нормально работает.
Ещё один минус - часто выходят обновления. Ну как минус. Это может и плюс с точки зрения развития, но для эксплуатации это минус. Приходится часто по ночам обновлять. Последнее обновление вообще вышло с предупреждением, что через 30 дней все новые клиенты перестанут обслуживаться. А клиенты обновляются автоматически, потому что вручную их хлопотно обновлять. Да и оповещения о новых версиях постоянно выскакивают. Администратор на месте всё же принял решение отключить автообновление и делать его своими силами.
Хорошая новость в том, что обновлять довольно просто, так как это Docker. Вот моя инструкция по обновлению. Писал для себя, чтобы не забыть.
Обновляется обычно контейнер с Rocket.Chat, а всё состояние живёт в базе MongoDB, которая обновляется редко. Так что всё обновление - это удаление старого контейнера с чатом и запуск нового.
Для бэкапа ничего особо не придумывал. Во-первых, бэкаплю саму виртуалку. Во-вторых, рядом с директорией, где прикрепляемые к сообщениям файлы, сделал ещё пару директорий. В одной дамп базы:
Во второй бэкап volume:
Все три директории бэкап сервер забирает к себе. В итоге имею бэкап виртуалки, дамп базы, сырые файлы контейнера, директорию с прикреплёнными файлами.
Всё это занимает не так много места, так что особо придумывать ничего не надо.
Если есть вопросы, задавайте. Мне лично Рокет не очень нравится. Я им почти не пользуюсь. Какой-то он нелепый немного, тормозной. В админке всё тоже как-то намешано, что путаешься постоянно. Но из бесплатных что-то сильно лучше я не знаю. После Telegram трудно пользоваться другими чатами.
#chat
В общем и целом с чатом никаких особых проблем не возникло. Я лично занимался только серверной частью. Создавал учётки, подключал пользователей, устанавливал им клиента другой человек, непосредственно работающий там.
С установкой и обслуживанием больших проблем не было. Установил всё стандартно, только прикрепляемые файлы в директорию из базы вынул. Об этом писал в первой заметке. Запустил в Docker. Хватило виртуалки 2 CPU, 4GB RAM. Чат ровно один раз протёк по памяти, пришлось ребутнуть виртуальную машину. Мониторинг почти сразу оповестил, что окно логина недоступно, перезагрузил, пользователи даже не успели заметить.
Мониторинг настроил в Zabbix. Ничего особо не придумывал. Стандартный шаблон для Linux и мониторинг стартовой страницы сервиса. Внутренние метрики не стал мониторить. Нужды в этом не возникло.
Явно не нравится перевод на русский язык. Ни мне, ни пользователям. Пытался через встроенную функциональность в админке перевести самостоятельно некоторые вещи. Не получилось. Не знаю, по какой причине, но мой перевод не отображался. В самой админке по настройкам сильно не лазил. Даже не помню, что менял. Что-то по мелочи. Особо можно не вникать, если не хочется. По умолчанию всё нормально работает.
Ещё один минус - часто выходят обновления. Ну как минус. Это может и плюс с точки зрения развития, но для эксплуатации это минус. Приходится часто по ночам обновлять. Последнее обновление вообще вышло с предупреждением, что через 30 дней все новые клиенты перестанут обслуживаться. А клиенты обновляются автоматически, потому что вручную их хлопотно обновлять. Да и оповещения о новых версиях постоянно выскакивают. Администратор на месте всё же принял решение отключить автообновление и делать его своими силами.
Хорошая новость в том, что обновлять довольно просто, так как это Docker. Вот моя инструкция по обновлению. Писал для себя, чтобы не забыть.
#infohttps://docs.rocket.chat/deploy/updating-rocket.chat#upgrading-rocket.chat-on-dockerdocker pull registry.rocket.chat/rocketchat/rocket.chat:6.4.8mcedit .env #change versiondocker compose stop rocketchatdocker compose rm rocketchatdocker compose up -d rocketchatОбновляется обычно контейнер с Rocket.Chat, а всё состояние живёт в базе MongoDB, которая обновляется редко. Так что всё обновление - это удаление старого контейнера с чатом и запуск нового.
Для бэкапа ничего особо не придумывал. Во-первых, бэкаплю саму виртуалку. Во-вторых, рядом с директорией, где прикрепляемые к сообщениям файлы, сделал ещё пару директорий. В одной дамп базы:
#!/bin/bash/usr/bin/docker exec rocketchat-mongodb-1 sh -c 'mongodump --archive' > /opt/rocket.chat/backup_db/rocketchat-`date +"%Y-%m-%d_%H-%M"`.dump/usr/bin/gzip /opt/rocket.chat/backup_db/rocketchat-`date +"%Y-%m-%d_%H-%M"`.dump/usr/bin/find /opt/rocket.chat/backup_db/ -type f -mtime +10 -exec rm -rf {} \;/usr/bin/touch /opt/rocket.chat/timestampВо второй бэкап volume:
#!/bin/bash/usr/bin/docker run --rm \ -v rocketchat_mongodb_data:/backup \ -v /opt/rocket.chat/backup_volume:/archive \ --env BACKUP_FILENAME="rocketchat-%Y-%m-%d_%H-%M.tar.gz" \ --env BACKUP_LATEST_SYMLINK="rocketchat-latest.tar.gz" \ --entrypoint backup offen/docker-volume-backup:v2Все три директории бэкап сервер забирает к себе. В итоге имею бэкап виртуалки, дамп базы, сырые файлы контейнера, директорию с прикреплёнными файлами.
Всё это занимает не так много места, так что особо придумывать ничего не надо.
Если есть вопросы, задавайте. Мне лично Рокет не очень нравится. Я им почти не пользуюсь. Какой-то он нелепый немного, тормозной. В админке всё тоже как-то намешано, что путаешься постоянно. Но из бесплатных что-то сильно лучше я не знаю. После Telegram трудно пользоваться другими чатами.
#chat
Только я успел написать и в целом похвалить Rocket.Chat за простоту установки, удобство и бесплатность, как прилетает новость о том, что в версии 6.5 теперь бесплатная версия поддерживает только 25 пользователей. Если надо больше - добро пожаловать в платную подписку - от $4.60 в месяц за пользователя.
Я успел обновиться только до 6.4.8 и меня пока это ограничение не затронуло. Пока есть время подумать, как дальше быть. Какое-то время можно не обновляться, но всё равно долго так не протянуть. Будут баги и дыры, которые нужно будет закрывать.
Новость особо нигде не светилась. Пришлось потрудиться и поискать, когда это изменение появилось. Немного информации есть в описании релиза 6.5. Плюс, обновилась документация: "Your workspace will be automatically provisioned a free Starter plan license when you install or upgrade to Rocket.Chat version 6.5 or higher." А на сайте, соответственно, появилось описание этого плана:
STARTER
Everything small teams need to collaborate securely
✔️ Up to 25 users
✔️ Up to 100 monthly active contacts (Omnichannel)
Только я определился с self-hosted бесплатным чатом, как опять придётся выбирать. Я тестировал и изучал почти все популярные чат-серверы:
◽️ Mattermost
◽️ Zulip
◽️ Revolt
◽️ Matrix + Element
◽️ Delta Chat
◽️ Jami
◽️ SimpleX Chat
◽️ NextCloud + Talk
◽️ TrueConf Server Free (бесплатно до 50 юзеров)
На мой взгляд, наиболее зрелые продукты из полностью бесплатных без ограничений по пользователям, которые можно внедрить в организации - Zulip, Rocket.Chat, Mattermost, Matrix + Element. Rocket.Chat соответственно, исключаем, так как 25 пользователей в бесплатной версии слишком мало. Неплохой продукт - TrueConf Server Free. Там и мессенджер, и видеозвонки. Бесплатно до 50-ти пользователей, что довольно неплохо. И сам чат приятный. Но если покупать, то дороговато выходит.
У кого были успешные внедрения бесплатных self-hosted чатов, поделитесь своим опытом. Не понятно, на чём теперь остановиться.
#chat #подборка
Я успел обновиться только до 6.4.8 и меня пока это ограничение не затронуло. Пока есть время подумать, как дальше быть. Какое-то время можно не обновляться, но всё равно долго так не протянуть. Будут баги и дыры, которые нужно будет закрывать.
Новость особо нигде не светилась. Пришлось потрудиться и поискать, когда это изменение появилось. Немного информации есть в описании релиза 6.5. Плюс, обновилась документация: "Your workspace will be automatically provisioned a free Starter plan license when you install or upgrade to Rocket.Chat version 6.5 or higher." А на сайте, соответственно, появилось описание этого плана:
STARTER
Everything small teams need to collaborate securely
✔️ Up to 25 users
✔️ Up to 100 monthly active contacts (Omnichannel)
Только я определился с self-hosted бесплатным чатом, как опять придётся выбирать. Я тестировал и изучал почти все популярные чат-серверы:
◽️ Mattermost
◽️ Zulip
◽️ Revolt
◽️ Matrix + Element
◽️ Delta Chat
◽️ Jami
◽️ SimpleX Chat
◽️ NextCloud + Talk
◽️ TrueConf Server Free (бесплатно до 50 юзеров)
На мой взгляд, наиболее зрелые продукты из полностью бесплатных без ограничений по пользователям, которые можно внедрить в организации - Zulip, Rocket.Chat, Mattermost, Matrix + Element. Rocket.Chat соответственно, исключаем, так как 25 пользователей в бесплатной версии слишком мало. Неплохой продукт - TrueConf Server Free. Там и мессенджер, и видеозвонки. Бесплатно до 50-ти пользователей, что довольно неплохо. И сам чат приятный. Но если покупать, то дороговато выходит.
У кого были успешные внедрения бесплатных self-hosted чатов, поделитесь своим опытом. Не понятно, на чём теперь остановиться.
#chat #подборка
