​​Блокировка подключения USB-устройств в Linux

USB-устройства – это удобно, подключил и работай, но это серьезная брешь в безопасности. Поэтому многие администраторы задумываются над тем, как ограничить возможность использовать USB-устройства.

Самое простое решение, что называется «в лоб», заблокировать загрузку драйвера usb-storage, для этого выполните:

echo "install usb-storage /bin/true" > /etc/modprobe.d/usb-storage.conf

После чего потребуется перезагрузить устройство. Данный метод заменяет установку драйвера usb-storage командой /bin/true, которая ничего не делает, а только возвращает код успешного завершения операции.

При этом кроме USB-накопителей у вас также перестанут работать и USB устройства ввода, такие как клавиатуры или мыши.

Данный способ вполне подойдет для серверов, чтобы уменьшить возможности «шаловливых рук» в случае непосредственного физического доступа к устройствам.

Альтернативой указанному выше способу можно использовать:

echo "blacklist uas" > /etc/modprobe.d/blacklist.conf
echo "blacklist usb-storage" > /etc/modprobe.d/blacklist.conf

Список модулей приведен для систем Debian и Ubuntu, после чего также перезагрузите устройство.

Более гуманным будет запрет на автоматическое монтирование USB-накопителей, после чего это можно будет сделать только вручную и только с правами суперпользователя.
Создадим файл /etc/udev/rules.d/99-usb.rules и внесем в него строку:

ENV{ID_USB_DRIVER}=="usb-storage",ENV{UDISKS_IGNORE}="1"

Для применения без перезагрузки применяем:

udevadm control --reload-rules

Чтобы разрешить автоматическое монтирование выбранных устройств сначала нам потребуется узнать их серийный номер:

udevadm info --query=env --name=/dev/sdd | grep ID_SERIAL

В нашем случае мы узнаем серийный номер устройства sdd, затем добавляем в /etc/udev/rules.d/99-usb.rules строку:

ATTRS{serial}=="4079621041319618643",ENV{UDISKS_IGNORE}="0"

Где в кавычках указываем серийный номер нужного устройства. Таких строк можно добавить несколько.

Данные способы простые и в чем-то даже грубые, но они доступны на любой системе без установки стороннего ПО.

Если же требуется более гибкое управление USВ устройствами, то вам потребуется специализированный софт, например, USBGuard, но это уже тема отдельной заметки.

Как инфоцыгане отравили IT

И тут я вспомнил про IT-курсы. Вот кто навёл шороху в нашем IT-мирке. Инфоцыгане почувствовали вкус вовлечённости и быстро оккупировали маркетинговые позиции в IT-школах. А ведь многие из этих школ создавались с энтузиазмом и искренним желанием помогать. Да, да – 8 лет назад действительно все эти сайты онлайн-школ просто содержали обучающие материалы и ничего не обещали.

✅ Читать полностью: https://habr.com/ru/articles/915766/

В целом - достаточно интересная статья, хотя с выводами автор и немного перегнул палку, но в целом так оно и есть.

Куда не плюнь, даже в хорошие курсы - везде тебе расскажут об "успешном успехе" и будут делать упор именно на него, а не на содержимое курсов.

​​Кеширующий прокси или зеркало репозитория?

Уже не первый раз сталкиваемся с тем, что начинающие администраторы путают эти два понятия. Поэтому попробуем внести ясность.

По мере роста количества машин под управлением Linux возникает проблема доступа к репозиториям. Например, при обновлении весь парк машин будет многократно выкачивать один и тот же объем трафика.

Дополнительными негативными факторами могут быть скорость канала или скорость доступа к репозиториям. Все это заставляет задуматься о том, как решить проблему.

Первое что приходит на ум – это локальное зеркало репозитория. Создать его несложно, для этого есть штатная утилита apt-mirror. С ее помощью можно поддерживать на собственных ресурсах полную копию репозиториев системы.

Но тут возникают иные сложности, так, например, размер репозиториев текущей версии Debian для архитектуры amd64 составляет 778 ГБ, сюда как минимум следует добавить all и еще 258 ГБ. Получаем примерно 1 ТБ требуемого дискового пространства.

Если у нас в эксплуатации несколько систем, то зеркала репозиториев нужно будет организовать для каждой из них. При переходе на новую версию – добавить новые репозитории.

В итоге получаем весьма значительное расходование места, причем достаточно бесполезное, поскольку по факту вы будете использовать лишь малую его часть.

Уменьшить размер локальных репозиториев в целом можно, например, скачав только самые нужные или оставив только последние версии пакетов, но все это не устраняет общей проблемы – значительный перерасход места.

Альтернатива локальному репозиторию – кеширующий прокси-сервер. Он работает по схожему, но несколько иному принципу.

Как и любой прокси-сервер он становится посредником между системой и репозиторием и один раз скачав любой пакет помещает его в локальный кеш. При последующих запросах пакет будет уже отдаваться из кеша, без повторного скачивания.

Локальная структура также организуется по принципу репозиториев, с учетом версии системы, архитектуры, источника пакетов и т.д.

Поэтому один кеширующий прокси может без проблем обслуживать любое количество систем и их версий. Никаких настроек при этом делать не надо. Новая система первый раз скачает необходимые файлы из интернета, а остальные получат их уже из локального хранилища.

Потребовался новый пакет или обновление? Аналогично, один раз качаем, остальное получаем локально.

При этом размер кеша будет равен размеру реально используемых пакетов и их версий. И разница с локальным репозиторием получается где-то на порядок.

Поэтому для большинства сценариев оптимальным будет использование именно кеширующего прокси.

Локальные репозитории в свою очередь следует использовать для закрытого контура или крупных систем с узким внешним каналом.

Настроить кеширующий прокси Apt-Cacher NG можно по нашей статье: Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu

​​Как показала практика, не все знают, что такое пакетные менеджеры и с чем их едят. А также путают форматы пакетов, низкоуровневые инструменты по управлению ими и высокоуровневые менеджеры.

Если коротко, то на самом нижем уровне притаились низкоуровневые инструменты вроде dpkg или rpm, которые умеют работать только с локальными пакетами и не умеют ничего кроме их установки и удаления. Разрешать зависимости тоже не их задача.

Выше уровнем стоят пакетные менеджеры, которые предоставляют пользователю удобный интерфейс для работы с низкоуровневыми инструментами и ряд дополнительных функций, основная из которых - это разрешение зависимостей, также их задача - это работа с репозиториями.

Пример таких менеджеров - APT, YUM/DNF, Zypper и т.д.

Они не умеют устанавливать и удалять пакеты, и по большому счету им вообще все равно с чем работать. Их задача - найти нужные пакеты, все зависимости к ним, скачать и передать это все на уровень ниже. Либо "доходчиво" пояснить низкоуровневому инструменту чего именно хочет пользователь, скажем удалить или переустановить пакет.

Таким образом у нас имеется два уровня абстракции: низкоуровневый инструмент, который непосредственно работает с пакетами и высокоуровневый менеджер, который предоставляет пользователю удобный инструмент для управления пакетами и ряд дополнительных сервисных функций.

Поэтому не следует удивляться таким проектам, как APT-RPM используемый в ALT Linux, который представляет собой пакетный менеджер APT наученный работать с низкоуровневым rpm, вместо dpkg.

Более подробно почитать на эту тему применительно к Debian/Ubuntu можно в нашей статье: https://interface31.ru/tech_it/2019/09/linux-nachinayushhim-chast-5-upravlenie-paketami.html

​​Форматируем раздел как ReFS в Windows 10/11

Файловая система ReFS была представлена в 2012 году и имеет ряд существенных преимуществ над своей предшественницей – NTFS. Также она имеет ряд особенностей и ограничений.

Например, на ReFS не может быть расположен загрузочный том, поэтому установить систему на эту ФС не удастся.

Подробнее обо всем этом можно почитать в первоисточнике: https://learn.microsoft.com/ru-ru/windows-server/storage/refs/refs-overview

Первоначально ReFS была доступна без ограничений как в клиентских, так и серверных выпусках ОС Windows, но это продолжалось недолго.

Начиная с выпуска 1709 в Windows 10 убрали поддержку ReFS для всех редакций кроме Professional for Workstation и Enterprise.

Но убрали ее по-хитрому: просто отключили возможность форматировать разделы в ReFS, сама же поддержка этой файловой системы была сохранена в полноценном виде.

Это, кстати, вполне объяснимо: ломать совместимость для пользователей уже успевших отформатировать диски в ReFS никто не рискнул.

Да и толку от этой затеи немного, поддержка файловых систем реализована на уровне ядра и выпилить ее полностью – задача непростая. А все остальное достаточно легко обходится различными твиками.

В общем Microsoft поступили в своем репертуаре, сначала дали попробовать, потом спрятали.

Но они бы не были собой, если бы с последними обновлениями Windows 11 не случилось второго пришествия ReFS под видом «дисков для разработки», о чем мы писали в дневной заметке.

Однако, если вам нужна ReFS не следует бежать за Windows 11 и срочно обновлять ее. Можно поступить проще.

Энтузиастом создана утилита mkrefs, которая позволяет быстро и просто отформатировать любой том в ReFS в любых выпусках Windows 10 и 11.

Скачать ее можно с репозитория разработчика на Github: https://github.com/0xbadfca11/mkrefs

Чтобы использовать утилиту вам потребуется создать том и присвоить ему букву, можно без форматирования, либо переформатировать уже существующий.

Чтобы получить справку просто запустите утилиту без ключей. В самом простом виде, с параметрами по умолчанию, можем отформатировать том под ReFS так:

mkrefs E: /X

Ключ /X используется для форсирования форматирования, полезно если вы переформатируете уже существующую файловую систему, на которой могут быть открытые файловые дескрипторы.

Также доступны ключи:

▫️ /V:label – метка тома, задаем произвольно, при наличии пробелом заключаем в кавычки

▫️ /A:{4096 | 64K} – размер блока файловой системы, по умолчанию 4К

▫️ /I:{enable | disable} – включение проверки целостности файловой системы, по умолчанию выключено

Например:

mkrefs E: /X /V:”My ReFS Vol” /A:64K /I:enabled

После чего в вашей системе появится диск с файловой системой ReFS который вы сможете полноценно использовать.

Также существует альтернативный способ с правкой реестра, но мы не рекомендуем его использовать, так как после такой правки у некоторых пользователей наблюдались проблемы с пробросом

​​Потоки целостности ReFS – плюсы, минусы и подводные камни

Потоки целостности ReFS – это дополнительная функция файловой системы, которая позволяет осуществлять контроль целостности данных путем использования контрольных сумм. При этом ReFS всегда использует контрольные суммы для метаданных.

Потоки целостности можно включить для файла, директории или тома. По умолчанию они выключены. Потоки целостности наследуются от родительского каталога или корня тома, т.е. включив потоки целостности для каталога вы включите их для всех находящихся в нем файлов и папок.

Как работают потоки целостности? При создании или любом изменении файла для него вычисляется контрольная сумма и записывается в метаданные. При чтении вначале вычисляется контрольная сумма запрошенных данных, затем она сравнивается с сохраненной и, если они совпадают, содержимое отдается запросившему его процессу.

При повреждении данных возможны два варианта действия.

1️⃣ Если ReFS используется на одиночном томе или на Дисковых пространствах без отказоустойчивости, то поврежденный файл блокируется и приложению сообщается об ошибке чтения.

2️⃣ Если используется зеркало или пространства четкости, то ReFS попробует восстановить файл, при успехе приложению будет отдан восстановленный файл, при неудаче – сообщение об ошибке чтения.

Также ReFS имеет собственный скраббер, который позволяет регулярно проводить проверки целостности редко используемых данных.

Проверить состояние потоков целостности для файлов можно командой:

Get-FileIntegrity -FileName H:\Docs\TextDocument.txt

Для всех файлов в каталоге:

Get-Item -Path 'C:\Docs\*' | Get-FileIntegrity

Включить потоки целостности можно для файла, каталога или тома:

Set-FileIntegrity H:\Docs\TextDocument.txt -Enable $True
Set-FileIntegrity H:\Docs -Enable $True
Set-FileIntegrity H:\ -Enable $True

Вроде бы пока все хорошо и интересно, но есть один неочевидный момент.

Если мы посмотрим в вывод команды Get-FileIntegrity то увидим:

FileName Enabled Enforced

 --------               ------- --------

 H:\Docs\TextDocument.txt False   True

Ну с колонкой Enabled – понятно, а вот что такое Enforced?

Выше мы говорили, что в случае неудачного восстановления доступ к файлу будет заблокирован. Параметр Enforced как раз отвечает за блокировку файла.

🆘 Применительно к ReFS блокировка означает фактическое удаление, так как нет никаких способов разблокировать такой файл.

Это может быть опасно, скажем из-за одной байтовой ошибки у вас может оказаться удален виртуальный диск на десятки и сотни гигабайт. Который можно было спокойно подключить и считать с него данные.

Такое поведение можно выключить, для этого используйте

Set-FileIntegrity H:\Docs\TextDocument.txt -Enforce $False

Но помните, что по умолчанию оно включено для всех объектов тома.

Отключить потоки целостности тоже легко:

Set-FileIntegrity H:\Docs\TextDocument.txt -Enable $False

Данная технология относится к числу тех, которые не следует применять бездумно, так как это может быть чревато потерей данных.

С другой она же позволит обеспечить лучшую целостность при наличии отказоустойчивости, либо поможет проще справиться с повреждениями диска.

👆В общем – применяйте с умом.

​​Трансформация цифровых продуктов

На заре формирования рынка программного обеспечения приобретаемая вами программа рассматривалась как еще одна вещь, такая же как ботинки, штаны или бутылка пива.

Действительно, в ту пору передать экземпляр ПО можно было в основном только физическим способом, на некотором физическом носителе, после чего вы становились его владельцем и никакого простого способа лишить вас права владения им не было.

Но в отличие от штанов ПО, как и любой другой цифровой контент, обладало одной интересной особенностью – его можно скопировать.

Купив штаны, вы, конечно, можете одолжить их другу, но тогда у вас самих штанов уже не будет. Поэтому на вечеринку в модных штанах пойдет кто-то один, либо каждому придется раскошелиться на собственный экземпляр штанов.

Клонировать программу мы можем бесчисленное количество раз, причем без всякого ухудшения ее качества. Что и послужило причиной появления такого явления как компьютерное пиратство.

И не нужно лукавить, что несанкционированное копирование – это не тоже самое, что кража штанов из магазина. Ведь ни у продавца, ни у производителя ничего не убавилось…

На самом деле это не так, как производство штанов, так и производство программного обеспечения имеет расходы, как прямые, так и косвенные.

Покупая штаны, вы оплачиваете не только ткань, но и расходы на их производство (амортизация оборудования, зарплаты персонала и т.д. и т.п.) , однако благодаря объему эти затраты размазаны на всю партию тонким слоем и не обременительны для покупателя.

То же самое и с цифровыми продуктами, нельзя говорить, что цифровой экземпляр ничего не стоит, ну или имеет цену носителя, на который записан. Его разработка и поддержка стоит денег, а привлекательная цена основана на предположении что будет продан определенный тираж.

Каждая несанкционированная копия – это фактический убыток. Так как затраты вы уже понесли, а прибыли до сих пор не получили.

Но контролировать физические копии практически невозможно, особенно если владелец «честно» ею поделился, вместе с ключом для установки.

Поэтому, как только интернет перестал быть роскошью, а стал повседневной обыденностью производители ПО перешли к различным онлайн-способам проверки легальности владения экземпляром программы.

Первой ласточкой стал механизм активации, который предусматривал блокировку основных возможностей программы если она не прошла онлайн-проверку законности владения.

По мере развития сетевых возможностей и расширения каналов передачи данных появилась возможность онлайн-доставки контента, что позволило не передавать покупателю лицензии физический экземпляр программы, а устанавливать его онлайн.

Это уже сужало возможные злоупотребления, но все еще давало в руки пользователя автономную копию продукта, которую он, при желании и умении, мог перенести на другой ПК без приобретения нового экземпляра.

Следующий шаг – это подписная модель, когда ПО не продается, а сдается в аренду на основе небольших ежемесячных платежей.

Из плюсов – доступность, если раньше какой-то профессиональный пакет был вам просто финансово недоступен, то теперь вы можете использовать его всего лишь за небольшую месячную оплату.

Минусы также очевидны – вы не владеете даже локальной копией продукта и полностью завязаны на внешние сервисы. Со всеми вытекающими. Если производителю что-то не понравится, то он может просто отключить вас от своих серверов и вы останетесь у разбитого корыта.

Еще хуже, если там хранятся ваши данные, и локальная копия так же контролируется приложением.

Облака, не так давно это было модно. Вам не нужны собственные мощности, вам не нужны собственные сотрудники, просто оплати тариф…

Сегодня идет обратная волна, отказа от облаков в пользу self-hosted, но это не про деньги и затраты, а про право владения.
Производителей ПО можно понять, но сегодня ситуация сильно перекошена в их сторону, когда пользователь покупает некое эфемерное право и ничем не защищен.

Но потребитель голосует кошельком, поэтому поживем – увидим. Рынок – это всегда баланс и компромисс.

​​Ценообразование на ПО и подписки

Постоянно, как только речь заходит о ценах на ПО, в комментариях появляются мнения, что экземпляр ПО ничего не стоит и его пиратство не может нанести разработчику материального ущерба.

На самом деле это не так, ПО как любой материальный предмет или нематериальная работа или услуга стоит денег. Как минимум тех, которые были потрачены на его разработку. И даже если разработчик занимается этим один, то ему все равно нужно питаться, одеваться, содержать семью, оплачивать счета.

И неважно чем он занимается, пишет ПО или печет пирожки. Все эти затраты так или иначе относятся на себестоимость, вне зависимости от материальности результата труда.

А дальше считаем. Допустим затраты на разработку составили 3 млн. руб., примерная аудитория оценивается нами как 1000 человек. Отсюда выводим себестоимость экземпляра программы в 3 000 руб., но мы же должны еще что-то заработать, а также поддерживать и развивать программу.

Оцениваем свою прибыль в 1 млн. руб. и затраты на дальнейшую поддержку и развитие как 2 млн. руб. Итого цена одной лицензии составит 6 000 руб. Продали больше – хорошо, а вот меньше – уже не очень. Потому что придется или затягивать пояс самим разработчикам, или экономить на поддержке и развитии.

Ну да ладно, будем считать, что план мы выполнили и будущее видится светлым и безоблачным. Но на самом деле проблемы только начинаются. Классический подход с оплатой за лицензию без дополнительных платежей сегодня не работает.

Почему? Давайте разбираться. Классическая бизнес-модель предусматривала продажу лицензий на некий продукт с достаточно коротким жизненным сроком. До 5 лет. И без какого-либо развития.

Вы оплачиваете лицензию и получаете некоторый законченный продукт, а также несколько пакетов исправлений к нему в течении жизненного цикла, причем такие пакеты могут выходить раз в полгода-год и это считалось нормальным.

Никакого развития и новых функций в продукте также не предусматривалось, так как все это предназначалось для новой версии продукта, которую надо приобретать заново, пусть и со скидкой для пользователей старой версии.
Такие новые релизы выходили раз в два-три года и ставили пользователя перед непростым выбором: нужны ли ему новые функции настолько, что нужно покупать новую версию или можно еще посидеть на старой.

Сегодня эта модель давно канула в лету, потому что исправления нужные еще вчера, а новые функции должны добавляться постоянно. И выход новой мажорной версии сегодня это чаще некоторое маркетинговое действие, нежели переход на что-то принципиально новое.

Бывает вообще очень тяжело понять, чем именно версия 2.0 отличается от 1.9, поэтому очень многие разработчики перешли на нумерацию по датам, скажем, 25.4 – релиз от апреля 25 года. Все просто и понятно. А также сразу видна актуальность ПО, потому что программу, последний релиз которой был в прошлом году многие будут рассматривать как устаревшую.

И вот тут появляется проблема – за чей счет весь этот банкет? В нашем примере разработчикам хватит средств только на первый год поддержки и сопровождения. А дальше что? Продавать новый мажорный релиз? А кто его купит? Особенно если отличий от текущего там кот наплакал?

Приберечь изменения для релиза? Так конкуренты обойдут, у которых все это уже будет. Как быть?

А выход тут только один – обеспечить постоянный приток денежных средств. Способ для этого есть только один – подписка. Берем ту же самую сумму и делим ее на регулярные платежи, 6000 руб. в год – это 500 руб./мес. Сумма крайне небольшая и необременительная.

При этом меняем бизнес-модель таким образом, чтобы на подписку были завязаны некоторые важные, но не основные функции, чтобы пользователь мог использовать ПО и без подписки. Чем сразу расширяем клиентскую базу и уменьшаем уровень пиратства, особенно если подписные функции завязать на онлайн.

В результате приходим к современной модели – базовые возможности бесплатно, обновления бесплатно, расширенные функции по подписке. И полный переход на нее – дело времени.

​​Нативная реклама, ожидания и реальность

Реклама бывает разная, но как бы к ней не относились – именно реклама является двигателем торговли. Сам не раз и не два находил в рекламе что-то интересное и покупал если не эту позицию, то что-то аналогичное.

Нативная реклама – отдельный вид рекламы, когда реклама выходит в качестве персонализированного отзыва или рекомендации от некого конкретного лица, пользующегося определенным доверием у аудитории.

Нативная реклама эффективна, но и недешева. Мы тоже иногда размещаем такую рекламу, но всегда сами перед этим тестируем рекламируемый продукт и пишем отзывы честно. Устраивает это не всех, плюс долго и дорого. Но по-другому тут быть и не может, так как на кону стоят не только деньги, но и репутация.

Последнее время все чаще стала попадаться реклама БАД MindBooster, звезд с неба не обещали, но делали упор на концентрацию, работоспособность, внимание и прочие плюшки для умственной деятельности в режиме хронических переработок, стресса и т.д. и т.п.

БАДы – штука такая, сложная, во многом индивидуальная, много и пустых обещаний, благо всегда можно сослаться на индивидуальные особенности и отсутствие прямых обещаний.

MindBooster – штука дорогая, мне упаковка на 40 капсул обошлась в 2 230 руб. или 112 руб. за один прием, так как глотать надо сразу по две капсулы. Упаковки хватает на три недели, я честно пропил две.

И? Эффекта ровно ноль, вообще никакого! Ни бодрости, ни концентрации, ни мотивации. Ничего из того, о чем распинались рекламирующие товарищи и что написано на упаковке.

Ну так это же БАДы, скажет кто-то, чего ты хотел. Ну чего-то хотел. Я давно покупаю другой БАД, который справа на рисунке. Который Женьшень-Таурин, 396 рублей за 60 капсул, или 7 рублей за прием.

Состав там прост и незамысловат, примерно тоже самое можно прочитать на банке энергетика. Эффект быстрый и аналогичный, но довольно мягкий, без скачков пульса и давления.

Хорошо бодрит с утра, примерно, как чашка кофе или банка энергетика. Эффект держится часа четыре. Что полностью соответствует ТТХ действующих веществ. Начинает клонить в сон после обеда – можно еще капсулу закинуть. В дороге тоже полезно, чтобы не спать за рулем.

В общем данный БАД работает и цену свою отбивает полностью.

А тут? Может пропил его мало, надо подольше? Но давайте почитаем состав. Кроме непонятных DMAE и Бакопа Монье все остальное вещества привычные и понятные, с коротким сроком действия.

Для большинства из них срок полувыведения – это часы, а полный вывод из организма – сутки или чуть больше. При этом ни одно их этих веществ не накапливается, а излишки выводятся с мочой. Т.е. никакого эффекта накопления тут нет и быть не может.

Ну так кому-то же помогает? Возможно. Во-первых, никто не отменял эффект плацебо, особенно после того, как вы заплатили более 2 тыс. руб. за баночку и полностью в ожидании чуда.

Во-вторых, вам действительно могло не хватать некоторых витаминов и тут вы просто «угадали» состав. Другое дело, что сделать это можно проще и дешевле. Достаточно купить мультивитаминный комплекс в ближайшей аптеке.

Но, опять-таки повторюсь, в некоторых сценариях, когда у человека есть явный недостаток витаминов или какие-то сопутствующие проблемы психосоматического характера, то пропить даже такой БАД будет полезно и будет определенный эффект.

Если же мы говорим о человеке, который сбалансированно питается и не испытывает психосоматических расстройств, то попытка как-то повысить производительность или обмануть природу в рамках соблюдения баланса труда и отдыха путем приема внутрь данного БАД (и не только данного) ожидаемого успеха не принесет.

Да и откуда ему тут взяться, это не психоактивное вещество, а безрецептурная добавка к пище. Просто травки и витаминки. В заведомо безопасных дозах.

Поэтому, как бы не хотелось, чудес не бывает. А хотите эффекта – берите БАДы попроще, с более понятным составом и понятным эффектом.

Как тот же Женьшень-Таурин, хотя и тут надо понимать, что это не про здоровый образ жизни, а про еще один пинок организму.

Исправляем ошибки запуска клиента 1С:Предприятие в современных выпусках Linux

Отношения клиентского приложения 1С:Предприятие и Linux безоблачными не назовешь, хотя нативный клиент для Linux существует уже довольно давно.

Но постоянно следует учитывать массу тонкостей и уметь преодолевать сложности, особенно если вы хотите использовать клиент 1С на свежих выпусках дистрибутивов Linux.

Сегодня мы разберем основные типовые проблемы запуска и пути их решения. А также немного прольем свет на причины всего происходящего.

https://interface31.ru/tech_it/2024/08/ispravlyaem-oshibki-zapuska-klienta-1spredpriyatie-v-sovremennyh-vypuskah-linux.html

​​Лог включен, но мало помогает

Именно такой ответ мы получили на предложение одному из наших читателей включить лог, чтобы он помог разобраться в проблеме.

И, к сожалению, подобные отзывы не единичны. Многие считают, что лог должен… А вот что он должен?

А лог не должен никому и ничего, это записи состояний и событий системы, которые могут оказаться вам полезны, а могут быть полностью бесполезными.

Почему так? Начнем с самого лога. Чтобы лог приносил пользу – он должен содержать записи об интересующих нас событиях. А для этого нужно правильно настроить подробность лога.

Многие системы по умолчанию записывают в лог только ошибки и предупреждения, отладочной информации в них нет. Поэтому, если нам не хватает информации – увеличиваем подробность лога.

Другая ошибка – излишние подробности, в этом случае вы просто тонете в малозначительных записях и можете пропустить действительно важное событие или не сможете провести причинно-следственные связи между несколькими событиями. В этом случае нужно наоборот уменьшить подробность логирования.

Еще одна классическая ошибка – смотрим не туда. Чаще всего это связано с тем, что «ошибка» в понимании пользователя не является ошибкой для сервиса и соответственно вы не увидите никакой записи об ошибке в таком случае.

Характерный пример – это состояния HTTP, многие из которых воспринимаются клиентом именно как ошибки. Но для самой системы это вполне допустимые и документированные состояния, которые являются частью штатного рабочего процесса.

В результате получается, что мы ищем то, чего нет. Поэтому не следует ограничивать себя каким-то фильтром или иным отбором по некоторым условиям, которые могут не совсем соответствовать или совсем не соответствовать реальной ситуации.

Поэтому, если в логе тишина, то это не значит, что лог плохой или сервис работает неправильно, а значит, что вы, скорее всего, не туда смотрите.

А смотреть надо в корень – на событие, которое должно вызвать реакцию сервиса. И начинать плясать от печки, т.е. от той системы – которое это событие инициализировала, а не от той, которая должна обработать.

Это позволяет быстро и эффективно выявить ситуации, когда мы обращаемся не туда или не так. Например, как это часто бывает, ваши запросы блокируются брандмауэром, а вы пытаетесь безрезультатно терзать веб-сервер.

Поэтому всегда нужно двигаться от источника события к результату, от локальной системы к удаленной, но не наоборот.

А еще – логи нужно уметь читать. Мы сейчас не будем брать во внимание крайний случай, когда квалификации явно недостаточно и все написанное в логе является «китайской грамотой».

Очень часто при анализе логов коллеги зацикливаются именно на самом событии и пытаются искать именно его описание, часто безрезультатно, но совершенно не обращают внимание на контекст, а ведь именно контекст определяет смысл происходящих событий.

Иногда достаточно промотать десяток строк вверх или вниз от события, чтобы понять, что именно на самом деле происходило в системе. И именно для этого бывает нужно увеличить подробности лога.

Но даже если в логе нет прямых указаний, то всегда следует обращать внимание на повторяющиеся события. Если у вас перед ошибкой раз за разом происходят еще некоторые действия – то именно они могут служить причиной ошибки и заслуживают самого пристального внимания, даже если на первый взгляд с ошибкой никак не связаны.

И помните, сам себя лог не прочитает и его отсутствие или наличие никак на работу системы не влияет. Лог нужен именно вам и нужен для того, чтобы вдумчиво его читать и анализировать. Также вы должны хотя бы в общих чертах понимать, что там написано и как вообще вся эта система работает.

Да, сегодня у нас есть неплохой помощник в виде ИИ, но без самостоятельного понимания он может направить вас на неверный путь, особенно если вы «скормите» ему не ту часть лога или начнете задавать не те вопросы.

Поэтому просто включить лог – это мало, нужно понимать что именно вы хотите в нем увидеть и почему именно в нем.

​​Используем спецсимвол ! в командной строке Linux

Сегодня один из читателей задал вопрос про восклицательный знак в составе команды запуска. Он ошибочно посчитал его признаком повышения прав и признался, что так и не смог найти подробного описания использования этого спецсимвола.

Поэтому попробуем заполнить этот пробел. Восклицательный знак используется для повторения команд и аргументов команд. В самом простейшем виде наберите:

!!

И оболочка повторит последнюю набранную команду. Это удобно, если команда требует повышения прав, тогда вместо перепечатывания команды заново достаточно написать:

sudo !!

Немного сложнее, если команду надо было выполнить от другого пользователя, например, postgres:

su -c “!!” postgres

Также с помощью восклицательного знака легко повторить команду из истории, выполните

 history

Посмотрите номер нужной команды и введите:

 !38

Что заново выполнит команду из истории под номером 38.

Также мы можем повторить выполнение команды со всеми аргументами, допустим мы выполнили:

cat /home/andrey/123.txt /home/ivan/321.txt

Для ее повторения достаточно выполнить:

 !cat

или вообще

 !с

Достаточно ввести одну или несколько букв, которые однозначно могут определить команду в текущей сессии.

Мы можем не только повторить, но и добавить аргументы, например:

!cat /home/andrey/456.txt

Что будет эквивалентно

cat /home/andrey/123.txt /home/ivan/321.txt /home/andrey/456.txt

Также можно использовать восклицательный знак для передачи аргументов предыдущей команды.

Для первого и последнего используйте !^ и !$

Так после выполнения последней команды мы можем указать:

 cat !^ !$

Что приведет к выполнению:

 cat /home/andrey/123.txt /home/andrey/456.txt

Либо можем указать аргументы явно, для последней команды можем использовать !:2 – второй аргумент, или указать команду явно, тогда будет использован указанный аргумент последнего запуска команды:

cat !cat:2

Будет аналогичен:

cat /home/andrey/456.txt

Обратите внимание, что к аргументам также относятся и ключи, поэтому если после запуска

cat -n /home/andrey/456.txt

Вы введете:

cat -n !^

То будет выполнен:

cat -n -n

без аргументов.

​​Полезная для начинающих утилита с неприличным именем

Работая в консоли Linux, начинающие делают ошибки, это нормально. Гораздо хуже, когда ее не удается быстро исправить или поиск информации затруднен.

В этом случае может пригодиться одна полезная утилита с неприличным именем - The Fuck, которое исправляет ошибки в введенных ранее консольных командах.

Утилита разработана на Python и для ее установки выполните:

sudo apt install python3-dev python3-pip python3-setuptools
pip install thefuck -–user

Обратите внимание, что саму утилиту, в отличие от зависимостей, следует устанавливать с правами того пользователя, который будет ей пользоваться, а ключ -–user предписывает установить утилиту только для текущего пользователя.

После чего в файл .bashrc внести строку:

eval $(thefuck --alias fuck)

Которая добавит для команды алиас fuck, если вам ближе родная речь, то можете написать:

eval $(thefuck --alias blya)

Затем перечитайте значения из файла или перезапустите сеанс:

source .bashrc

Теперь можно попробовать утилиту в деле. Вводим команду с ошибкой, после чего вызываем

fuck

Утилита тут же предлагает нам исправление, достаточно нажать Enter, но теперь снова ошибка, мы запустили команду с недостаточным набором прав. Снова вызываем утилиту, и она нас снова поправляет.

Чтобы избежать постоянного вызова утилиты можно запустить ее в режиме повторения:

fuck -r

Теперь она будет последовательно обрабатывать все полученные ошибки до получения результата, либо пока вы не прервете ее действия.

Если вы хотите применять исправления автоматически, то вызовите утилиту с ключом:

fuck -y

Но полностью полагаться на искусственный интеллект неразумно и небезопасно, поэтому разработчики отключили автоматическое подтверждение в режиме повторения.

Больше об утилите можно узнать на официальной странице Git: https://github.com/nvbn/thefuck

​​Настраиваем Visual Studio Code для удаленной работы через SSH

Сегодня все чаще и чаще для конфигурационных файлов используются продвинутые текстовые форматы, такие как JSON или XML, имеющие строгий синтаксис и структуру.

Их применение облегчает программную обработку данных, но при этом они все еще остаются легко читаемыми человеком.

Однако работа с ними в привычных консольных редакторах имеет ряд неудобств, в частности связанных с соблюдением синтаксиса и формата разметки.

Поэтому гораздо удобнее использовать для этого специальные среды разработки, например, VS Code, тем более что он прекрасно умеет работать через SSH.

https://interface31.ru/tech_it/2024/05/nastraivaem-visual-studio-code-dlya-udalennoy-raboty-cherez-ssh.html