Записки IT специалиста

Семейный гибрид, который тратит как скутер! Устали кормить бензоколонки? Японские и корейские гибриды — это 3-4 литра на 100 км и никаких компромиссов! Почему гибрид — это умно: - Экономия топлива — до 60% по сравнению с обычным ДВС - Надёжность — батареи ходят 200-300 тысяч км - Комфорт — плавный ход, тихая работа Топовые гибриды: 🚗 Toyota Prius, Aqua, Harrier Hybrid 🚗 Honda Fit Hybrid, Vezel Hybrid 🚗 Lexus CT, NX, RX Hybrid Что входит в услугу: • Подбор честного гибрида с живой батареей • Проверка истории обслуживания • Финальная цена без скрытых платежей • Доставка до двери с ПТС • Консультации по эксплуатации Работаем с 2008 года, знаем всё о гибридах! Хочешь «живые» расчёты владения? ✅ Подпишись на Telegram — там калькуляторы экономии и реальные отзывы владельцев! Подписаться #реклама О рекламодателе

Новому сайту – быть! Последнее время многие нас спрашивают про сайт, будет ли он продолжать свое развитие или нет. Вопрос не праздный, потому как формат заметок в Телеграм не позволяет глубоко раскрыть многие темы (ограничение в 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-летней историей практически невозможно написать нормальный скрипт конвертации, так как сам движок не раз менял подходы к верстке, а еще были и ручные правки. Нет, быстро переконвертировать можно и забить на огрехи, мол потом поправим, но это не наш метод. Поэтому практически весь материал был проверен вручную. По-быстрому, но тем не менее. Поэтому косяки будут, но не в том масштабе, в котором могли быть. Сегодня с переносом контента мы закончили и теперь осталось отстроить систему сборки и развертывания. Поэтому в ближайшие несколько дней новый сайт будет опубликован, а вместе с ним будем публиковать целую пачку материалов, которая лежала в черновиках и изначально версталась под новый сайт.

Кэшбэк до 10% за путешествия Отдыхать приятнее с кэшбэком. В Т-Путешествиях на карту вернется до 10% за: - Авиабилеты - Отели, глэмпинги, хостелы и апартаменты Планируйте поездки с выгодой в Т-Путешествиях. Узнать больше #реклама tbank.ru О рекламодателе

Режимы запуска 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 будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.

Приказ ФСТЭК России №117 вводит обновленные требования к защите информации для государственных и муниципальных ИС, а также систем с данными ограниченного доступа. Ошибки в интерпретации требований повышают риск штрафов при проверках. Консультанты F6 подготовили чек-лист, который поможет быстро определить: — попадает ли ИС под действие Приказа №117; — документальные, организационные и технические меры защиты; — мероприятия по оценке защищенности; — ориентиры для подготовки к проверкам. Чек-лист будет полезен руководителям ИБ и ИТ, специалистам по защите информации, аудиторам и комплаенсу. Скачайте чек-лист и проверьте свою ИС на соответствие требованиям Приказа №117 #реклама О рекламодателе

Можно ли заплутать в трех соснах при помощи ИИ? Сейчас вокруг ИИ складывается большой ажиотаж, многие считают, что наличие такого помощника обесценивает знания и опыт и позволяет даже начинающим сотрудникам выполнять работу старших товарищей, не напрягаясь и не вникая. Ну да, вкалывают роботы – счастлив человек. Это мы слышали не раз и не два. Но любой, кто серьезно работал с ИИ понимает, что несмотря на весь достигнутый прогресс – это просто помощник: неутомимый, исполнительный, но туповатый, хотя и начитанный. Это как? Да вот так, теория без практики мертва, практика без теории – сборник магических заклинаний, камланий и ритуалов. И только совмещение первого и второго дают устойчивый результат в виде экспертных знаний и навыков. Сегодня мы провели небольшой эксперимент, задали трем сетям один провокационный вопрос, в «забеге» участвовали 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 ГБ.

Работаете психологом, наставником, коучем? Узнайте про Мотивационный профиль Рисса (RMP) - как он поможет с клиентами. Особенно, с теми, кто - "застрял" и топчется на месте - не знает, чего хочет - хочет, но не делает. Расскажем, как выявлять глубинные мотивы клиента и работать с ними, а не с поверхностными проблемами Узнать больше #реклама 16+ reissprofile.ru О рекламодателе

Lazydocker – легкая консольная утилита для управления Docker Управлять инфраструктурой 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, работает быстро, потребляет минимум ресурсов и, главное, поработали – закрыли.

Роден нанял бы себе ИИ-агента 💯 Ещё пару лет назад ценность инженера была в технических навыках. Сейчас — в том, как он выстраивает систему, которая работает за него или даже целую команду. Примерно как Роден 😅 Да, тот самый скульптор XIX века. Он не вырезал каждую скульптуру сам, а строил мастерскую, где идея остаётся за ним, а исполнение масштабируется. С ИИ происходит то же самое. Лучшие команды собирают процессы, где агенты подхватывают задачи, делают работу и возвращают результат — остаётся только проверить. Вот вам простой тест (подсмотрел у Дмитрия Бороздина): — у вас есть документация, где хранится весь контекст? — проводите тесты ИИ-агентов? — работаете с логами и метриками, чтобы отслеживать ошибки? Если хотя бы на один вопрос ответили «нет» — ваша мастерская, скорее всего, работает некорректно. Я периодически читаю Дмитрия — он много пишет об ИИ в ритейле: как влияет на продажи, клиентский опыт и экономику интернет-магазинов. Если тема откликается, вот канал: https://t.me/+e0WMXuHoHOBjZWIy?erid=2W5zFHoXwDb 👈

Установка и настройка сервера лицензирования 1С:Предприятие Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация. Основные проблемы - это оптимизация распределения лицензий и привязка лицензий к параметрам оборудования, что создает трудности в виртуальной среде. Облегчить работу и централизовать управление лицензиями вам поможет выделенный сервер лицензирования, как его установить и настроить мы расскажем в этой статье. https://interface31.ru/tech_it/2024/11/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie.html