Веселая иллюминация на Mikrotik
Сегодня коллега из одного филиала прислал эту фотографию с вопросом: а нормально ли это, что роутер сияет всеми цветами как новогодняя елка?
Начнем с пятого порта, это нормально, на этой модели данный порт имеет функцию PoE-out и в данной конфигурации включена подача питания на порт.
А вот почему светится желтым четвертый порт? Документация не содержит четкого описания цветов и режимов для каждой модели, но найденная в сети информация сбила коллегу с толку, намекая на то, что порт работает в нестандартном режиме (например, 10 Мбит/с).
Но изучение режимов работы порта не выявило никаких отклонений от своих соседей. Почему же тогда он желтый?
Для правильного ответа на этот вопрос я предложил ему временно выключить светодиод на пятом порте. После чего все сразу вернулось на круги своя.
Дело в том, что в данной модели Mikrotik индикаторы распаяны прямо на плате, а рассеиватель физически устроен так, что более яркий красный может спокойно «слепить» соседние зеленые.
В результате мы на месте индикатора четвертого порта и видим желтый цвет, также обратите внимание на средний (третий) индикатор – он немного более желтого оттенка, чем первые два.
Эту особенность хорошо знают те, кто много работает с Mikrotik и подвержены ей все модели в аналогичных корпусах. Если вас все же терзают сомнения, то попробуйте выключить соседние светодиоды в System – LEDs и проверить реальный цвет «подозрительного индикатора».
Сегодня коллега из одного филиала прислал эту фотографию с вопросом: а нормально ли это, что роутер сияет всеми цветами как новогодняя елка?
Начнем с пятого порта, это нормально, на этой модели данный порт имеет функцию PoE-out и в данной конфигурации включена подача питания на порт.
А вот почему светится желтым четвертый порт? Документация не содержит четкого описания цветов и режимов для каждой модели, но найденная в сети информация сбила коллегу с толку, намекая на то, что порт работает в нестандартном режиме (например, 10 Мбит/с).
Но изучение режимов работы порта не выявило никаких отклонений от своих соседей. Почему же тогда он желтый?
Для правильного ответа на этот вопрос я предложил ему временно выключить светодиод на пятом порте. После чего все сразу вернулось на круги своя.
Дело в том, что в данной модели Mikrotik индикаторы распаяны прямо на плате, а рассеиватель физически устроен так, что более яркий красный может спокойно «слепить» соседние зеленые.
В результате мы на месте индикатора четвертого порта и видим желтый цвет, также обратите внимание на средний (третий) индикатор – он немного более желтого оттенка, чем первые два.
Эту особенность хорошо знают те, кто много работает с Mikrotik и подвержены ей все модели в аналогичных корпусах. Если вас все же терзают сомнения, то попробуйте выключить соседние светодиоды в System – LEDs и проверить реальный цвет «подозрительного индикатора».
👍37😁21❤4
Как получить список подключенных USB-устройств в Windows
Возникла необходимость просмотреть список подключенных устройств на удаленном ПК с Windows. Задача не самая простая, ну не бегать же глазами по диспетчеру устройств. В Linux для этого есть команда
Для этой цели будем использовать командлет
Кроме идентификатора мы можем использовать в отборе класс, но в этом случае в вывод не попадут такие устройства как камеры или смарт-карты (токены), но может попасть совсем не USB-устройство, например, контроллер USB на PCIe шине:
При желании можем оба отбора скомбинировать и получить только устройства класса USB подключенные именно как USB:
Как видим, PowerShell дает не меньше возможностей и позволяет легко выполнять отборы по требуемым параметрам.
Возникла необходимость просмотреть список подключенных устройств на удаленном ПК с Windows. Задача не самая простая, ну не бегать же глазами по диспетчеру устройств. В Linux для этого есть команда
lsusb, посмотрим, что может нам предложить PowerShell.Для этой цели будем использовать командлет
Get-PnpDevice, для начала отберем устройства по идентификатору в котором присутствует USB, опция Status OK покажет только активные устройства:Get-PnpDevice -InstanceId 'USB*' -Status OK
Кроме идентификатора мы можем использовать в отборе класс, но в этом случае в вывод не попадут такие устройства как камеры или смарт-карты (токены), но может попасть совсем не USB-устройство, например, контроллер USB на PCIe шине:
Get-PnpDevice -Class 'USB' -Status OK
При желании можем оба отбора скомбинировать и получить только устройства класса USB подключенные именно как USB:
Get-PnpDevice -InstanceId 'USB*' -Class USB -Status OK
Как видим, PowerShell дает не меньше возможностей и позволяет легко выполнять отборы по требуемым параметрам.
👍24🤝5❤3⚡2
Установка и настройка сервера лицензирования 1С:Предприятие
Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация.
Основные проблемы - это оптимизация распределения лицензий и привязка лицензий к параметрам оборудования, что создает трудности в виртуальной среде.
Облегчить работу и централизовать управление лицензиями вам поможет выделенный сервер лицензирования, как его установить и настроить мы расскажем в этой статье.
https://interface31.ru/tech_it/2024/11/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie.html
Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация.
Основные проблемы - это оптимизация распределения лицензий и привязка лицензий к параметрам оборудования, что создает трудности в виртуальной среде.
Облегчить работу и централизовать управление лицензиями вам поможет выделенный сервер лицензирования, как его установить и настроить мы расскажем в этой статье.
https://interface31.ru/tech_it/2024/11/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie.html
👍19❤2
Lazydocker – легкая консольная утилита для управления Docker
Управлять инфраструктурой Docker в голом терминале не очень удобно и каждый раз, когда речь заходит об этом, на ум приходят Portainer и его аналоги.
Но если у вас пяток-десяток контейнеров на недорогом VPS, то тянуть туда еще один тяжелый контейнер для управления – это перебор.
В этом случае может пригодиться Lazydocker – интерактивная консольная утилита, закрывающая все основные потребности по управлению и контролю Docker инфраструктуры.
Для ее установки можно воспользоваться инструкцией из официального репозитория, которая скачивает и запускает скрипт, но в этом случае утилита будет размещена в $HOME/.local/bin, что не очень удобно, поэтому сразу определим место установки.
Если мы хотим, чтобы утилита была доступна всем пользователям сервера по стандартному пути, то установим ее в
Теперь можно запускать сам скрипт:
А дальше просто:
Навигация осуществляется стрелками, цифрами и фигурными скобками (по горизонтали).
Основных разделов шесть: проекты и сервисы – это то, что вы запускаете при помощи Docker Compose, затем идут отдельные контейнеры, образы, тома и сети.
В каждом разделе вы можете посмотреть доступную информацию: настройки, логи, статистику или выполнить набор команд, который доступен в меню по кнопке x, кнопкой b можно вызвать массовые команды для групповых действий.
Все быстро, просто, удобно. Если вы обладаете базовыми знаниями Docker и понимаете, что и для чего, то освоение утилиты займет пару минут.
Утилита написана на Go, работает быстро, потребляет минимум ресурсов и, главное, поработали – закрыли.
Управлять инфраструктурой Docker в голом терминале не очень удобно и каждый раз, когда речь заходит об этом, на ум приходят Portainer и его аналоги.
Но если у вас пяток-десяток контейнеров на недорогом VPS, то тянуть туда еще один тяжелый контейнер для управления – это перебор.
В этом случае может пригодиться Lazydocker – интерактивная консольная утилита, закрывающая все основные потребности по управлению и контролю Docker инфраструктуры.
Для ее установки можно воспользоваться инструкцией из официального репозитория, которая скачивает и запускает скрипт, но в этом случае утилита будет размещена в $HOME/.local/bin, что не очень удобно, поэтому сразу определим место установки.
Если мы хотим, чтобы утилита была доступна всем пользователям сервера по стандартному пути, то установим ее в
/usr/local/bin, для чего перед запуском скрипта определим переменную окружения: export DIR=/usr/local/bin
Теперь можно запускать сам скрипт:
curl https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh | bash
А дальше просто:
lazydocker
Навигация осуществляется стрелками, цифрами и фигурными скобками (по горизонтали).
Основных разделов шесть: проекты и сервисы – это то, что вы запускаете при помощи Docker Compose, затем идут отдельные контейнеры, образы, тома и сети.
В каждом разделе вы можете посмотреть доступную информацию: настройки, логи, статистику или выполнить набор команд, который доступен в меню по кнопке x, кнопкой b можно вызвать массовые команды для групповых действий.
Все быстро, просто, удобно. Если вы обладаете базовыми знаниями Docker и понимаете, что и для чего, то освоение утилиты займет пару минут.
Утилита написана на Go, работает быстро, потребляет минимум ресурсов и, главное, поработали – закрыли.
👍28🔥4❤2🤝1
Можно ли заплутать в трех соснах при помощи ИИ?
Сейчас вокруг ИИ складывается большой ажиотаж, многие считают, что наличие такого помощника обесценивает знания и опыт и позволяет даже начинающим сотрудникам выполнять работу старших товарищей, не напрягаясь и не вникая.
Ну да, вкалывают роботы – счастлив человек. Это мы слышали не раз и не два. Но любой, кто серьезно работал с ИИ понимает, что несмотря на весь достигнутый прогресс – это просто помощник: неутомимый, исполнительный, но туповатый, хотя и начитанный.
Это как? Да вот так, теория без практики мертва, практика без теории – сборник магических заклинаний, камланий и ритуалов. И только совмещение первого и второго дают устойчивый результат в виде экспертных знаний и навыков.
Сегодня мы провели небольшой эксперимент, задали трем сетям один провокационный вопрос, в «забеге» участвовали ChatGPT, Gemini и Qwen. А вопрос был простой:
Почему Joplin при размере контейнера в 554 МБ развернулся в 4,46 ГБ?
Сетки начинают активно думать и строить предположения, в целом ход их мысли правильный и грамотный, что может усыпить бдительность вопрошающего. Они совершенно правильно предлагают выполнить внутри контейнера определенные команды, чтобы понять, кто занял все это место.
Но вывод делают абсолютно неправильный, только увидев, что это папка
В общем сразу нагнали жути, а дальше пошли ценные указания как подключить к контейнеру том и на горячую перенести в него данные, чтобы они бесследно не пропали при перезапуске.
Хорошо, демонстративно делаю:
И снова показываю размер образа, и поясняю, что все мои данные на месте. После чего ИИ выдвигает новую гипотезу, что это могут быть временные файлы, логи, кеши и сессии. А дальше идут новые рекомендации как это все оптимизировать, вынести, разнести и т.д. и т.п.
При этом все три сетки продолжают нагнетать жути:
Ладно, предлагаю им ознакомиться с образцом Compose-файла от самих разработчиков, где никаких томов к контейнеру Joplin не монтируется, но в ответ снова идут размышления, что там просто пример, а на практике может быть всякое.
Скажем честно, если бы мы заранее не знали правильный ответ, но возможно бы и повелись, больно все хорошо обосновано было.
Но в итоге мы при помощи тех же самых команд, что советовала сетка показали ей что на самом деле занимает место.
И что? А ничего, ИИ моментально переобулся на ходу (это он умеет):
На самом деле все просто, Joplin Server написан на Node.js, который отлично жмется, а в развернутом виде и составляет те самые 4,5 ГБ.
Сейчас вокруг ИИ складывается большой ажиотаж, многие считают, что наличие такого помощника обесценивает знания и опыт и позволяет даже начинающим сотрудникам выполнять работу старших товарищей, не напрягаясь и не вникая.
Ну да, вкалывают роботы – счастлив человек. Это мы слышали не раз и не два. Но любой, кто серьезно работал с ИИ понимает, что несмотря на весь достигнутый прогресс – это просто помощник: неутомимый, исполнительный, но туповатый, хотя и начитанный.
Это как? Да вот так, теория без практики мертва, практика без теории – сборник магических заклинаний, камланий и ритуалов. И только совмещение первого и второго дают устойчивый результат в виде экспертных знаний и навыков.
Сегодня мы провели небольшой эксперимент, задали трем сетям один провокационный вопрос, в «забеге» участвовали ChatGPT, Gemini и Qwen. А вопрос был простой:
IMAGE ID DISK USAGE CONTENT SIZE EXTRA
joplin/server:latest 5d9e7f9d31b4 4.46GB 554MB U
Почему Joplin при размере контейнера в 554 МБ развернулся в 4,46 ГБ?
Сетки начинают активно думать и строить предположения, в целом ход их мысли правильный и грамотный, что может усыпить бдительность вопрошающего. Они совершенно правильно предлагают выполнить внутри контейнера определенные команды, чтобы понять, кто занял все это место.
Но вывод делают абсолютно неправильный, только увидев, что это папка
/home/joplin сразу возникает гипотеза: Вот и виновник: 3.4 ГБ в папке /home.
В образе Joplin Server по умолчанию рабочая директория и данные пользователя находятся именно в /home/joplin. Поскольку база данных у тебя вынесена в отдельный контейнер Postgres, эти 3.4 ГБ — это не заметки, а скорее всего хранилище ресурсов (Resources/Attachments): картинки, PDF-файлы и другие вложения, которые ты синхронизировал.
Почему это плохо в текущем виде?
Риск потери данных: Если ты сделаешь docker compose down и удалишь контейнер (а не просто остановишь), всё, что не в базе и не в Volume, исчезнет навсегда.
В общем сразу нагнали жути, а дальше пошли ценные указания как подключить к контейнеру том и на горячую перенести в него данные, чтобы они бесследно не пропали при перезапуске.
Хорошо, демонстративно делаю:
docker compose down
docker compose up -d
И снова показываю размер образа, и поясняю, что все мои данные на месте. После чего ИИ выдвигает новую гипотезу, что это могут быть временные файлы, логи, кеши и сессии. А дальше идут новые рекомендации как это все оптимизировать, вынести, разнести и т.д. и т.п.
При этом все три сетки продолжают нагнетать жути:
Для Joplin на Postgres это обычно не критично (всё в БД), но если ты используешь FileSystem как хранилище для ресурсов (Storage Driver), то обязательно выноси эту папку на хост.
Вердикт: Если docker system prune не скинет эти 4ГБ, значит, Joplin хранит вложения или логи внутри себя. Для «чистого» сервера это ненормально, и лучше поправить маппинг папок в конфиге сейчас, пока ты не залил туда всю свою базу заметок.
Ладно, предлагаю им ознакомиться с образцом Compose-файла от самих разработчиков, где никаких томов к контейнеру Joplin не монтируется, но в ответ снова идут размышления, что там просто пример, а на практике может быть всякое.
Скажем честно, если бы мы заранее не знали правильный ответ, но возможно бы и повелись, больно все хорошо обосновано было.
Но в итоге мы при помощи тех же самых команд, что советовала сетка показали ей что на самом деле занимает место.
И что? А ничего, ИИ моментально переобулся на ходу (это он умеет):
Вот мы и нашли "жирок". Эти 3.4 ГБ — это исходный код и зависимости самого приложения Joplin.
Что происходит?
В образе Joplin Server разработчики упаковали всё дерево в /home/joplin/packages.
Это нормально: Это не мусор, а рабочие модули (парсеры, рендерер, сам сервер), без которых приложение не заведется.
На самом деле все просто, Joplin Server написан на Node.js, который отлично жмется, а в развернутом виде и составляет те самые 4,5 ГБ.
👍26😁3❤1
Режимы запуска bash
Скрипты и команды bash – это то, с чем ежедневно сталкивается системный администратора, поэтому важно знать режимы запуска командной оболочки и контекст выполнения команд bash в каждом конкретном случае.
1️⃣ Начнем с режима входа в систему, в этом случае bash является оболочкой входа и при завершении процесса сеанс прекратится. Такой режим используется при интерактивном входе в систему или при подключении через SSH.
При запуске в качестве оболочки входа bash создает новую базовую среду и считывает файлы инициализации
Кроме того,
Таким образом в режиме входа в систему bash создает базовую среду на основе как системных настроек, так и персональных для выполнившего вход пользователя.
2️⃣ Следующий режим – интерактивный, он запускается, когда стандартные потоки ввода-вывода подключены к эмулятору терминала. Например, если вы запустили терминал в графической среде. Или явно запустили bash внутри оболочки входа (а это может быть не обязательно bash).
В этом случае новая базовая среда не создается, а наследуется контекст окружения текущей оболочки, в дополнение к этому считываются персональные настройки из
Если сравнивать интерактивный режим и режим оболочки входа, то основной разницей является то, что интерактивный режим наследует текущее окружение и только лишь дополняет его персональными настройками.
3️⃣ Третий режим – неинтерактивный. Он используется при запуске
Этот режим существенно отличается как от режима оболочки входа, так и интерактивного. Основное его отличие в том, что при запуске создается новая минимальная базовая среда, но при этом не считываются никакие файлы инициализации, кроме файла указанного в переменной
Таким образом большинство привычных настроек, включая пути исполнения, в неинтерактивном режиме окажутся недоступны. И если скрипт у вас прекрасно работал интерактивно, то в неинтерактивном режиме вас может поджидать неприятная неожиданность.
Как избежать данной проблемы? Не запускать скрипты интерактивно. Т.е. вместо
В чем разница? В первом случае скрипт будет исполнен интерактивно, в режиме оболочки входа или интерактивной оболочки. Во втором bash будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.
Скрипты и команды bash – это то, с чем ежедневно сталкивается системный администратора, поэтому важно знать режимы запуска командной оболочки и контекст выполнения команд bash в каждом конкретном случае.
1️⃣ Начнем с режима входа в систему, в этом случае bash является оболочкой входа и при завершении процесса сеанс прекратится. Такой режим используется при интерактивном входе в систему или при подключении через SSH.
При запуске в качестве оболочки входа bash создает новую базовую среду и считывает файлы инициализации
/etc/profile и один из файлов: ~/.bash_profile, ~/.bash_login или ~/.profile который будет найден первым при поиске в указанном порядке.Кроме того,
/etc/profile считывает файлы /etc/profile.d/*.sh и /etc/bash.bashrc, а ~/.bash_profile содержит указание на исполнение файла ~/.bashrc.Таким образом в режиме входа в систему bash создает базовую среду на основе как системных настроек, так и персональных для выполнившего вход пользователя.
2️⃣ Следующий режим – интерактивный, он запускается, когда стандартные потоки ввода-вывода подключены к эмулятору терминала. Например, если вы запустили терминал в графической среде. Или явно запустили bash внутри оболочки входа (а это может быть не обязательно bash).
В этом случае новая базовая среда не создается, а наследуется контекст окружения текущей оболочки, в дополнение к этому считываются персональные настройки из
~/.bash_profile и общие из /etc/bash.bashrc. Если сравнивать интерактивный режим и режим оболочки входа, то основной разницей является то, что интерактивный режим наследует текущее окружение и только лишь дополняет его персональными настройками.
3️⃣ Третий режим – неинтерактивный. Он используется при запуске
bash -с или bash имя_скрипта, а также при вызове команд и скриптов системными процессами, тем же cron.Этот режим существенно отличается как от режима оболочки входа, так и интерактивного. Основное его отличие в том, что при запуске создается новая минимальная базовая среда, но при этом не считываются никакие файлы инициализации, кроме файла указанного в переменной
BASH_ENV среды окружения (если задан).Таким образом большинство привычных настроек, включая пути исполнения, в неинтерактивном режиме окажутся недоступны. И если скрипт у вас прекрасно работал интерактивно, то в неинтерактивном режиме вас может поджидать неприятная неожиданность.
Как избежать данной проблемы? Не запускать скрипты интерактивно. Т.е. вместо
./my_script.sh используйте bash my_script.sh.В чем разница? В первом случае скрипт будет исполнен интерактивно, в режиме оболочки входа или интерактивной оболочки. Во втором bash будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.
👍14👌1
Новому сайту – быть!
Последнее время многие нас спрашивают про сайт, будет ли он продолжать свое развитие или нет. Вопрос не праздный, потому как формат заметок в Телеграм не позволяет глубоко раскрыть многие темы (ограничение в 4000 символов).
Дополним это тем, что заметка в Телеграм, по сути, одноразовая. Поиск тут так себе, а ленту сильно вверх никто не листает. Поэтому публикация развернутых инструкций и подробных статей возможна только на сайте.
Старый сайт был создан на движке Movable Type 6.2, это довольно интересная CMS, которая генерировала статическое содержимое и наш сайт с самого его основания фактически являлся статическим.
Но сам движок все равно присутствовал на сайте и брал на себя ряд служебных функций: поиск, обработку тегов, пагинацию.
Сам движок тоже пошел сложным путем, сначала разработчики убрали Community-версию, потом и вовсе продали проект японцам, и поддержка продукта стала очень затруднительной.
В текущем виде Movable Type 6.2 – дырявое решето, которое не сломает только ленивый, поэтому большая часть сайта была переведена в режим read-only, потому что иных возможностей сократить поверхность атаки не существовало.
Какое-то время мы хотели все-таки сохранить Movable Type, но практика показала, что ничего хорошего из этого не получится. По актуальным версиям нет не то, что русскоязычной, но и даже англоязычной информации. Сетки тоже не в курсе.
В итоге осенью прошлого года мы затеяли большой переезд, радикально изменив структуру проекта. Теперь за сайт будет отвечать генератор статических страниц HUGO, а сам сайт будет полностью укладываться в парадигму «сайт как код».
Как исходники, так и готовый результат будет храниться в Git и автоматически разворачиваться на хостинг. А ломать там будет принципиально нечего.
Технически структура развернута в Docker на базе Angie и Traefik, а это все тоже набор текстовых файлов, которые легко хранить и можно быстро развернуть где угодно.
Технически новый сайт будет поддерживать все современные технологии: HTTP/3, форматы изображений AVIF и WebP, сжатие zstd и brotli.
По дизайну мы постарались сохранить преемственность, но в тоже время сделать его современным, быстрым и адаптивным. Для любителей будет даже темная тема, но полноценно ей мы заниматься не будем, разве что когда-нибудь потом.
Поэтому она поставляется как есть, те же картинки за всю историю переделать не так просто, чтобы убрать белый фон и добавить прозрачность.
Тут и так могут спросить: а что вы там все эти полгода делали? А делали мы полуручной перенос контента.
Для сайта с 16-летней историей практически невозможно написать нормальный скрипт конвертации, так как сам движок не раз менял подходы к верстке, а еще были и ручные правки.
Нет, быстро переконвертировать можно и забить на огрехи, мол потом поправим, но это не наш метод. Поэтому практически весь материал был проверен вручную. По-быстрому, но тем не менее.
Поэтому косяки будут, но не в том масштабе, в котором могли быть. Сегодня с переносом контента мы закончили и теперь осталось отстроить систему сборки и развертывания.
Поэтому в ближайшие несколько дней новый сайт будет опубликован, а вместе с ним будем публиковать целую пачку материалов, которая лежала в черновиках и изначально версталась под новый сайт.
Последнее время многие нас спрашивают про сайт, будет ли он продолжать свое развитие или нет. Вопрос не праздный, потому как формат заметок в Телеграм не позволяет глубоко раскрыть многие темы (ограничение в 4000 символов).
Дополним это тем, что заметка в Телеграм, по сути, одноразовая. Поиск тут так себе, а ленту сильно вверх никто не листает. Поэтому публикация развернутых инструкций и подробных статей возможна только на сайте.
Старый сайт был создан на движке Movable Type 6.2, это довольно интересная CMS, которая генерировала статическое содержимое и наш сайт с самого его основания фактически являлся статическим.
Но сам движок все равно присутствовал на сайте и брал на себя ряд служебных функций: поиск, обработку тегов, пагинацию.
Сам движок тоже пошел сложным путем, сначала разработчики убрали Community-версию, потом и вовсе продали проект японцам, и поддержка продукта стала очень затруднительной.
В текущем виде Movable Type 6.2 – дырявое решето, которое не сломает только ленивый, поэтому большая часть сайта была переведена в режим read-only, потому что иных возможностей сократить поверхность атаки не существовало.
Какое-то время мы хотели все-таки сохранить Movable Type, но практика показала, что ничего хорошего из этого не получится. По актуальным версиям нет не то, что русскоязычной, но и даже англоязычной информации. Сетки тоже не в курсе.
В итоге осенью прошлого года мы затеяли большой переезд, радикально изменив структуру проекта. Теперь за сайт будет отвечать генератор статических страниц HUGO, а сам сайт будет полностью укладываться в парадигму «сайт как код».
Как исходники, так и готовый результат будет храниться в Git и автоматически разворачиваться на хостинг. А ломать там будет принципиально нечего.
Технически структура развернута в Docker на базе Angie и Traefik, а это все тоже набор текстовых файлов, которые легко хранить и можно быстро развернуть где угодно.
Технически новый сайт будет поддерживать все современные технологии: HTTP/3, форматы изображений AVIF и WebP, сжатие zstd и brotli.
По дизайну мы постарались сохранить преемственность, но в тоже время сделать его современным, быстрым и адаптивным. Для любителей будет даже темная тема, но полноценно ей мы заниматься не будем, разве что когда-нибудь потом.
Поэтому она поставляется как есть, те же картинки за всю историю переделать не так просто, чтобы убрать белый фон и добавить прозрачность.
Тут и так могут спросить: а что вы там все эти полгода делали? А делали мы полуручной перенос контента.
Для сайта с 16-летней историей практически невозможно написать нормальный скрипт конвертации, так как сам движок не раз менял подходы к верстке, а еще были и ручные правки.
Нет, быстро переконвертировать можно и забить на огрехи, мол потом поправим, но это не наш метод. Поэтому практически весь материал был проверен вручную. По-быстрому, но тем не менее.
Поэтому косяки будут, но не в том масштабе, в котором могли быть. Сегодня с переносом контента мы закончили и теперь осталось отстроить систему сборки и развертывания.
Поэтому в ближайшие несколько дней новый сайт будет опубликован, а вместе с ним будем публиковать целую пачку материалов, которая лежала в черновиках и изначально версталась под новый сайт.
🔥84👍31❤10🙏4⚡1
Особенности ротации логов приложений в Docker
В комментариях задали вопрос: как настроить ротацию логов приложения в Docker, в частности вопрос касался веб-сервера Angie.
При этом следует понимать, что речь идет не о логах самого Docker, а именно о логах приложения, работающего в контейнере. И несмотря на то, что в данной заметке речь идет об Angie/NGINX данный подход применим к любым приложениям пишущим собственные логи.
Если мы посмотрим в типовую конфигурацию виртуального хоста Angie/NGINX, то увидим там примерно следующее:
Если ничего больше не делать, то логи будут неконтролируемо расти внутри контейнера, но при его перезапуске окажутся утеряны. И то и другое является нежелательным, поэтому будем исправлять ситуацию.
Прежде всего вынесем логи на хост, поэтому смонтируем дополнительный Volume, для этого в compose-файл добавьте:
Теперь, после перезапуска все логи будут в
Для их ротации воспользуемся системной службой logrotate, для этого в
Где angie-mysite в команде docker exec – имя контейнера, убедитесь, что в вашем compose-файле есть опция:
А в остальном это стандартная конфигурация logrotate, мы делаем ротацию каждый день, храним 14 архивов, все архивы, кроме предпоследнего сжимаем.
После выполнения ротации мы дополнительно посылаем серверу Angie команду reopen на переоткрытие файлов лога.
Проверить работу конфигурации можно командой:
Которая ничего не делает, но только имитирует команду ротации, таким образом вы проверите конфигурационный файл на предмет ошибок и убедитесь, что все указано верно.
В комментариях задали вопрос: как настроить ротацию логов приложения в Docker, в частности вопрос касался веб-сервера Angie.
При этом следует понимать, что речь идет не о логах самого Docker, а именно о логах приложения, работающего в контейнере. И несмотря на то, что в данной заметке речь идет об Angie/NGINX данный подход применим к любым приложениям пишущим собственные логи.
Если мы посмотрим в типовую конфигурацию виртуального хоста Angie/NGINX, то увидим там примерно следующее:
access_log /var/log/angie/my_site.access.log;
error_log /var/log/angie/my_site.error.log;
Если ничего больше не делать, то логи будут неконтролируемо расти внутри контейнера, но при его перезапуске окажутся утеряны. И то и другое является нежелательным, поэтому будем исправлять ситуацию.
Прежде всего вынесем логи на хост, поэтому смонтируем дополнительный Volume, для этого в compose-файл добавьте:
volumes:
- /opt/my_site /logs:/var/log/angie
Теперь, после перезапуска все логи будут в
/opt/my_site /logs и при перезапуске контейнера не будут потеряны. Для их ротации воспользуемся системной службой logrotate, для этого в
/etc/logrotate.d/ создадим дополнительный файл настроек для нашей службы, например angie-mysite и внесем в него следующий текст:/opt/my_site/logs/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 0644 root root
sharedscripts
postrotate
docker exec angie-mysite angie -s reopen
endscript
}Где angie-mysite в команде docker exec – имя контейнера, убедитесь, что в вашем compose-файле есть опция:
container_name: angie-mysite
А в остальном это стандартная конфигурация logrotate, мы делаем ротацию каждый день, храним 14 архивов, все архивы, кроме предпоследнего сжимаем.
После выполнения ротации мы дополнительно посылаем серверу Angie команду reopen на переоткрытие файлов лога.
Проверить работу конфигурации можно командой:
logrotate -d /etc/logrotate.d/angie-mysite
Которая ничего не делает, но только имитирует команду ротации, таким образом вы проверите конфигурационный файл на предмет ошибок и убедитесь, что все указано верно.
👍16🤝3🤷♂1❤1
💈Релиз нового сайта! 💈
Сегодня, в пятницу 17 апреля 2026 года мы наконец то выпустили релиз нового сайта. Заходим, смотрим, обживаемся.
Весь контент перенесен, тема адаптирована к уже привычной, цвета и стили по возможности сохранены.
Со стилями еще придется поработать, особенно в области читабельности врезок с кодом и т.д.
Есть темная тема, но она – как есть, специально ей заниматься времени и особого желания нет, так как нужно обрезать белый фон с кучи картинок в заголовках статей.
Материал весь вычитан руками, но вычитан «по диагонали», на предмет цепляющих глаз косяков, поэтому косяки помельче обязательно будут, будем вылавливать и исправлять.
Таксономия будет серьезно переработана, ибо в нынешнем виде она неудобна и некоторые категории сильно перегружены.
Добавлена новая таксономия серии – для более удобного объединения материалов в группы, пока полноценно сделана серия по iptables, можете посмотреть.
Теги – как были, так и останутся, к ним особых вопросов нет.
Все старые ссылки перелинкованы, так что ничего не потеряется если вы будете переходить из внешних источников или закладок.
Все тяжелые файлы вынесены на CDN, нечего им на самом сайте делать, ссылки на скачивание перелинкованы.
Форум убран за ненадобностью, нет и не будет. Такой формат сегодня популярностью не пользуется.
Система комментариев тоже собственная, пока пустая, но будет импортирован весь архив с Disqus, так что ничего не потеряется.
Вход возможен через Яндекс, Google и GitHub, через телегу не войдете, так как заблокированы сервера API.
В целом на этом все, ждем обратной связи.
✅ https://interface31.ru
Сегодня, в пятницу 17 апреля 2026 года мы наконец то выпустили релиз нового сайта. Заходим, смотрим, обживаемся.
Весь контент перенесен, тема адаптирована к уже привычной, цвета и стили по возможности сохранены.
Со стилями еще придется поработать, особенно в области читабельности врезок с кодом и т.д.
Есть темная тема, но она – как есть, специально ей заниматься времени и особого желания нет, так как нужно обрезать белый фон с кучи картинок в заголовках статей.
Материал весь вычитан руками, но вычитан «по диагонали», на предмет цепляющих глаз косяков, поэтому косяки помельче обязательно будут, будем вылавливать и исправлять.
Таксономия будет серьезно переработана, ибо в нынешнем виде она неудобна и некоторые категории сильно перегружены.
Добавлена новая таксономия серии – для более удобного объединения материалов в группы, пока полноценно сделана серия по iptables, можете посмотреть.
Теги – как были, так и останутся, к ним особых вопросов нет.
Все старые ссылки перелинкованы, так что ничего не потеряется если вы будете переходить из внешних источников или закладок.
Все тяжелые файлы вынесены на CDN, нечего им на самом сайте делать, ссылки на скачивание перелинкованы.
Форум убран за ненадобностью, нет и не будет. Такой формат сегодня популярностью не пользуется.
Система комментариев тоже собственная, пока пустая, но будет импортирован весь архив с Disqus, так что ничего не потеряется.
Вход возможен через Яндекс, Google и GitHub, через телегу не войдете, так как заблокированы сервера API.
В целом на этом все, ждем обратной связи.
✅ https://interface31.ru
🔥52👍33⚡6❤6🤮1
Microsoft переделывает «Пуск» с нуля
Такая вот новость появилась вчера в зарубежных, а теперь уже и наших источниках, немного процитирую:
Ничего не напоминает? Прошлый раз столь же большая переработка пользовательского интерфейса в Windows 10 неожиданно вылилась в новую ОС Windows 11, теперь же, по слухам, нас ждет скорый выпуск Windows 12.
И данная новость косвенно на это указывает, новый дизайн пользовательского интерфейса – новая ОС.
Главное, чтобы Microsoft учла собственные ошибки и сделала их них правильные выводы. Интерфейс Windows 11 местами не так уж и плох, многое сделано правильно и хорошо, но все это было перечеркнуто новым, неудачным, меню Пуск.
Да, его немного привели в чувство в более новых релизах, но оно как было деревянным, так и осталось.
Судя по всему, кардинальные изменения нам не грозят:
Но как раз этого и не нужно, потому что ни к чему хорошему это не приводит, лучше последовательно развивать что есть, взяв лучшие стороны из разных решений. Но, как говорится, поживем – увидим.
А пока можно окунуться в прошлое и познакомиться с историей меню Пуск от его возникновения до наших дней:
✅ История кнопки и меню "Пуск"
✅ История кнопки и меню "Пуск". Продолжение
Такая вот новость появилась вчера в зарубежных, а теперь уже и наших источниках, немного процитирую:
Microsoft работает над крупным обновлением меню «Пуск» в Windows 11, которое призвано предоставить пользователям больше контроля над его внешним видом. По словам осведомлённых источников, эти улучшения разрабатываются в рамках нового дизайна пользовательского интерфейса WinUI 3, разработку которого компания уже подтвердила.
Ничего не напоминает? Прошлый раз столь же большая переработка пользовательского интерфейса в Windows 10 неожиданно вылилась в новую ОС Windows 11, теперь же, по слухам, нас ждет скорый выпуск Windows 12.
И данная новость косвенно на это указывает, новый дизайн пользовательского интерфейса – новая ОС.
Главное, чтобы Microsoft учла собственные ошибки и сделала их них правильные выводы. Интерфейс Windows 11 местами не так уж и плох, многое сделано правильно и хорошо, но все это было перечеркнуто новым, неудачным, меню Пуск.
Да, его немного привели в чувство в более новых релизах, но оно как было деревянным, так и осталось.
Судя по всему, кардинальные изменения нам не грозят:
По имеющимся данным, новое меню «Пуск» будет похоже на существующее, но получит более продвинутые возможности настройки, которые можно будет изменить в приложении «Параметры Windows». Добавятся параметры включения или отключения определённых разделов, а также возможность вручную выбирать между маленьким и большим макетом меню «Пуск».
Но как раз этого и не нужно, потому что ни к чему хорошему это не приводит, лучше последовательно развивать что есть, взяв лучшие стороны из разных решений. Но, как говорится, поживем – увидим.
А пока можно окунуться в прошлое и познакомиться с историей меню Пуск от его возникновения до наших дней:
✅ История кнопки и меню "Пуск"
✅ История кнопки и меню "Пуск". Продолжение
🤮8👍3🤔2🤡2❤1
VitruvianOS – гибрид Haiku на ядре Linux
В конце марта этого года состоялся первый публичный релиз VitruvianOS – операционной системы на базе Debian, которая предоставляет API и компоненты пользовательского пространства для запуска приложений для Haiku и BeOS.
В системе реализованы: app_server - графический сервер и графический тулкит Interface Kit из Haiku. Вместо systemd используется система инициализации janus_daemon, аналог родного launch_daemon.
Как видим, это не просто реализация графической оболочки а-ля Haiku поверх ядра Linux, а именно отдельная подсистема, позволяющая запускать на Linux нативные приложения Haiku и BeOS.
Сразу возникает вопрос: а зачем это надо? Ведь есть оригинальная Haiku. Есть, только весь вопрос в том, сколько человек ее использует и сколько занимается разработкой. Круг их весьма узок и все, чем они занимаются происходит в тесном сообществе, изолированном от остального мира открытого ПО.
Переход на платформу Linux позволяет, во-первых, привлечь большее количество пользователей и решить ряд проблем за счет использования готовой базы, а самим сосредоточиться на сильных сторонах BeOS, которые есть желание продолжать использовать.
От этого выиграют все: и поклонники Haiku, и пользователи Linux, так как наработки обоих проектов можно будет использовать совместно. А работать в большой команде всегда лучше, чем вариться с собственном мирке.
Да, в конечном итоге это скорее всего приведет к появлению очередного окружения рабочего стола, скажем, HaikuDE, который будет работать с привычным Linux окружением. Но такой вариант кажется мне наиболее оптимальным.
Потому что сильные стороны Haiku/BeOS – это идеи и реализации, заложенные в первоначальную систему, а не конкретное воплощение в коде.
Яркий пример тому – macOS, которая спокойно сменила платформу сначала на BSD, а теперь и просто перешла на архитектуру ARM. Причем абсолютно прозрачно для пользователя. Потому что ему не интересно, что там под капотом, ему важен пользовательский опыт, как он взаимодействует с системой и что она может ему дать.
Поэтому пожелаем новому проекту удачи, потому что BeOS – это действительно самобытная и интересная система, которая наконец сможет найти своего пользователя.
В конце марта этого года состоялся первый публичный релиз VitruvianOS – операционной системы на базе Debian, которая предоставляет API и компоненты пользовательского пространства для запуска приложений для Haiku и BeOS.
В системе реализованы: app_server - графический сервер и графический тулкит Interface Kit из Haiku. Вместо systemd используется система инициализации janus_daemon, аналог родного launch_daemon.
Как видим, это не просто реализация графической оболочки а-ля Haiku поверх ядра Linux, а именно отдельная подсистема, позволяющая запускать на Linux нативные приложения Haiku и BeOS.
Сразу возникает вопрос: а зачем это надо? Ведь есть оригинальная Haiku. Есть, только весь вопрос в том, сколько человек ее использует и сколько занимается разработкой. Круг их весьма узок и все, чем они занимаются происходит в тесном сообществе, изолированном от остального мира открытого ПО.
Переход на платформу Linux позволяет, во-первых, привлечь большее количество пользователей и решить ряд проблем за счет использования готовой базы, а самим сосредоточиться на сильных сторонах BeOS, которые есть желание продолжать использовать.
От этого выиграют все: и поклонники Haiku, и пользователи Linux, так как наработки обоих проектов можно будет использовать совместно. А работать в большой команде всегда лучше, чем вариться с собственном мирке.
Да, в конечном итоге это скорее всего приведет к появлению очередного окружения рабочего стола, скажем, HaikuDE, который будет работать с привычным Linux окружением. Но такой вариант кажется мне наиболее оптимальным.
Потому что сильные стороны Haiku/BeOS – это идеи и реализации, заложенные в первоначальную систему, а не конкретное воплощение в коде.
Яркий пример тому – macOS, которая спокойно сменила платформу сначала на BSD, а теперь и просто перешла на архитектуру ARM. Причем абсолютно прозрачно для пользователя. Потому что ему не интересно, что там под капотом, ему важен пользовательский опыт, как он взаимодействует с системой и что она может ему дать.
Поэтому пожелаем новому проекту удачи, потому что BeOS – это действительно самобытная и интересная система, которая наконец сможет найти своего пользователя.
👍12❤2🤡1
Копируй, вставляй и молись
Не так давно в классическом труде UNIX® and Linux® System Administration Handbook в очередной раз наткнулся на описание данного метода, который авторы метко назвали «копируй, вставляй и молись».
В переводе данный абзац будет выглядеть так:
Но, к сожалению, данный метод использовался, используется и будет продолжать использоваться со всеми вытекающими отсюда последствиями.
И это относится не только к написанию скриптов, но и к файлам конфигурации, когда администраторы копируют чужие примеры даже не задумываясь.
Спрашиваешь: «а зачем тут это?»
В ответ пожимают плечами и путано поясняют что так было написано в одной умной инструкции.
К этой же порочной методике можно отнести и бездумное копирование инструкций, а также любимый многими «вид спорта» - настройка чего-либо с помощью чужих готовых скриптов.
Последний вариант вообще вне конкуренции по возможным деструктивным последствиям, потому как в статье автор хотя бы комментирует свои действия, и вы можете понять надо ли это в вашем случае или не надо, то скрипт может просто сделать все молча и по-своему.
Неоднократно сталкивались с товарищами, которые приходят за помощью с жалобой, мол поставил продукт А, но ничего не работает. А на уточняющие вопросы поясняют, что ничего не знают и дают ссылку на скрипт.
Бездумное следование инструкциям ничуть не лучше, по сути, это выходит тот же самый скрипт, но в более простом варианте, когда команды вбивает оператор. Его роль тут сводится просто к скопировал-вставил и его спокойно можно заменить дрессированной обезьяной. 🐵
Поэтому не стоит уподобляться братьям нашим меньшим. Делаем по инструкции – стараемся понять каждое действие, назначение всех используемых опций, значений настроек и всегда сопоставляем их с нашими текущими реалиями.
Надо нам это? Не надо? А почему здесь такое число? На что оно влияет.
Да, вы потратите больше времени, но это время не будет потрачено даром. Вы начнете хотя бы на базовом уровне разбираться в конфигурации и принципе работы продукта, а также сразу наметите возможные проблемы и места, которые за эти участки отвечают.
Что касается чужих скриптов, то их использовать, конечно можно, но крайне нежелательно до тех пор, пока вы не сможете читать их с листа и понимать, что они делают и зачем. И не важно, насколько популярен этот скрипт, сколько у него звезд на гитхабе и т.д. и т.п.
Почему? Да потому что всегда может что-то пойти не так и если скрипт для вас черный ящик, то вы даже не поймете, где проблема и в чем. После чего все равно придется либо изучать его, либо идти просить помощи.
И это мы еще не говорим о том, что автор может иметь собственные представления «о прекрасном» и использовать нестандартные пути, приемы, допускать ошибки, прибиваться гвоздями к версиям и т.д. и т.п.
При определенных условиях работа скрипта может вообще оказаться деструктивной, но не со злого умысла автора, а просто потому, что он пропустил некоторые проверки или вообще не предусмотрел вашего сценария.
При этом мы понимаем, что, даже прочитав данную заметку многие пожмут плечами и пойдут работать методом «копируй, вставляй и молись» дальше. Потому что он в целом работает, а что касается дальнейшей эксплуатации: упремся – разберемся.
Но только вот профессиональному росту специалиста он никак не содействует и об этом нужно помнить если не хотите чтобы вас потом заменила дрессированная обезьяна в виде столь популярного ныне искусственного интеллекта.
Не так давно в классическом труде UNIX® and Linux® System Administration Handbook в очередной раз наткнулся на описание данного метода, который авторы метко назвали «копируй, вставляй и молись».
В переводе данный абзац будет выглядеть так:
Не стесняйтесь адаптировать код существующих скриптов для своих нужд. Но не занимайтесь программированием по принципу «копируй, вставляй и молись», когда вы не понимаете код. Найдите время, чтобы разобраться в этом. Это время никогда не тратится зря.
Но, к сожалению, данный метод использовался, используется и будет продолжать использоваться со всеми вытекающими отсюда последствиями.
И это относится не только к написанию скриптов, но и к файлам конфигурации, когда администраторы копируют чужие примеры даже не задумываясь.
Спрашиваешь: «а зачем тут это?»
В ответ пожимают плечами и путано поясняют что так было написано в одной умной инструкции.
К этой же порочной методике можно отнести и бездумное копирование инструкций, а также любимый многими «вид спорта» - настройка чего-либо с помощью чужих готовых скриптов.
Последний вариант вообще вне конкуренции по возможным деструктивным последствиям, потому как в статье автор хотя бы комментирует свои действия, и вы можете понять надо ли это в вашем случае или не надо, то скрипт может просто сделать все молча и по-своему.
Неоднократно сталкивались с товарищами, которые приходят за помощью с жалобой, мол поставил продукт А, но ничего не работает. А на уточняющие вопросы поясняют, что ничего не знают и дают ссылку на скрипт.
Бездумное следование инструкциям ничуть не лучше, по сути, это выходит тот же самый скрипт, но в более простом варианте, когда команды вбивает оператор. Его роль тут сводится просто к скопировал-вставил и его спокойно можно заменить дрессированной обезьяной. 🐵
Поэтому не стоит уподобляться братьям нашим меньшим. Делаем по инструкции – стараемся понять каждое действие, назначение всех используемых опций, значений настроек и всегда сопоставляем их с нашими текущими реалиями.
Надо нам это? Не надо? А почему здесь такое число? На что оно влияет.
Да, вы потратите больше времени, но это время не будет потрачено даром. Вы начнете хотя бы на базовом уровне разбираться в конфигурации и принципе работы продукта, а также сразу наметите возможные проблемы и места, которые за эти участки отвечают.
Что касается чужих скриптов, то их использовать, конечно можно, но крайне нежелательно до тех пор, пока вы не сможете читать их с листа и понимать, что они делают и зачем. И не важно, насколько популярен этот скрипт, сколько у него звезд на гитхабе и т.д. и т.п.
Почему? Да потому что всегда может что-то пойти не так и если скрипт для вас черный ящик, то вы даже не поймете, где проблема и в чем. После чего все равно придется либо изучать его, либо идти просить помощи.
И это мы еще не говорим о том, что автор может иметь собственные представления «о прекрасном» и использовать нестандартные пути, приемы, допускать ошибки, прибиваться гвоздями к версиям и т.д. и т.п.
При определенных условиях работа скрипта может вообще оказаться деструктивной, но не со злого умысла автора, а просто потому, что он пропустил некоторые проверки или вообще не предусмотрел вашего сценария.
При этом мы понимаем, что, даже прочитав данную заметку многие пожмут плечами и пойдут работать методом «копируй, вставляй и молись» дальше. Потому что он в целом работает, а что касается дальнейшей эксплуатации: упремся – разберемся.
Но только вот профессиональному росту специалиста он никак не содействует и об этом нужно помнить если не хотите чтобы вас потом заменила дрессированная обезьяна в виде столь популярного ныне искусственного интеллекта.
👍6❤1👎1🤮1🥱1