Исправляем ошибки запуска клиента 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

​​Система автономного обновления Linux

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

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

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

Впервые проблема с обновлениями была сформулирована разработчиками Fedora еще в 2009 году. Тогда основной претензией было то, что обновления поставляются хаотично, не тестируются в комплексе и непонятны пользователям.

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

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

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

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

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

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

Теперь пакетный менеджер только скачивает обновления и уведомляет systemd об их наличии.

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

Также на пользователя не вываливается вся куча обновлений, а разбивается на метапакеты: обновление системы (23 пакета), обновление KDE (15 пакетов), обновление Firefox, LibreOffice и т.д., что делает процесс более понятным для пользователя.

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

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

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

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

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

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

С технической стороны это делает систему более надежной и практически на 100% гарантирует ее загрузку в графическом режиме (за исключением действительно серьезных проблем).

​​Специальные символы-операторы командной строки Linux

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

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

command &

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

apt update -y & apt full-upgrade -y

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

Для объединения команд используется оператор && - логическое И. Несмотря на всю схожесть с прошлым оператором ее смысл совсем иной. В конструкции:

command _1 && command _2

Вторая команда выполниться только при успешном выполнении первой, т.е. если она вернула код выхода 0.

Поэтому правильная команда для обновления системы будет выглядеть так:

apt update -y && apt full-upgrade -y && apt autoremove -y

Также все знают оператор | - пайп или труба. Он позволяет передать поток вывода одной команды в поток входа другой.

А вот если мы поставим подряд две трубы - || - то получим оператор логическое ИЛИ, в конструкции:

command _1 || command _2

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

В более сложных конструкциях можно использовать И – ИЛИ:

command _1 && command _2 || command _3

Если первая команда завершилась успешно, то будет выполнена команда 2, иначе – команда 3.

​​PortQry v 2.0 – консольный сканер портов для Windows

Инструментов для диагностики сети хватает, но лишних среди них не бывает, поэтому сегодня хотим рассказать о консольном сетевом сканере от Microsoft - PortQry v 2.0, получить его можно на официальной странице: https://www.microsoft.com/en-us/download/details.aspx?id=17148

Использовать ее довольно просто, нам потребуется указать несколько параметров:

-n – точка назначения – имя или адрес сетевого узла
-p – протокол, доступны значения: tcp, udp, both, по умолчанию tcp.
-e – порт назначения
-o – перечень портов через запятую
-r - диапазон портов через двоеточие

Например:

PortQry.exe -n 192.168.100.125 -p udp -e 1194

или

PortQry.exe -n 192.168.100.125 -o 80, 443

В зависимости от результата вы получите одно из значений:

Listening – если порт открыт и ответ от него получен

Not Listening – если на целевом узле не запущен процесс обслуживающий порт и система сообщает ICMP «Destination Unreachable - Port Unreachable» или получен TCP-пакет с флагом Reset.

Filtered – если система не направила никакого ответа или запрос был отфильтрован брандмауэром.

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

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

Таким образом, чтобы определить, действительно ли порт открыт или фильтруется PortQry использует расширенные проверки для ряда протоколов, в их число входят: LDAP, RPC, SMTP/POP3/IMAP4, SNMP, FTP/TFTP, NetBIOS, MS SQL, L2TP и ряд других.

На картинке внизу показан запрос к порту MS SQL, утилита первоначально проверила порт и выдала предварительную оценку: LISTENING or FILTERED.

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

В некоторых случаях может потребоваться использовать определенный порт источника, в этом случае используйте следующий ключ (указанный порт не должен использоваться другими процессами):

PortQry.exe -n 192.168.100.125 -sp 25 -e 25

Кроме того, у утилиты существует локальный режим, в котором она работает с сетевыми процессами хоста, в этом варианте интересными могут быть ключи:

-local – показывает информацию обо всех активных портах и соединениях локального узла
-wport – мониторит сетевую активность указанного порта
- wpid – мониторит сетевую активность процесса с указанным PID

Данные возможность удобно использовать с записью в лог файл:

PortQry.exe -wport 3389 -wt 5 -l rdplog.txt

Где ключ -wt задает частоту опроса в секундах, доступные значение 1-1200, по умолчанию 60 сек, а ключ -l указывает файл журнала, при указании относительного пути журнал создается в директории с утилитой.

Размер заметки не позволяет перечислить все возможности, поэтому дадим ссылку на страничку официальной документации: https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/networking/portqry-command-line-port-scanner-v2

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

Denwer. Кто помнит — уже не джун
Напомнили сегодня про Denwer — тот самый джентльменский набор разработчика. Кто ставил — поймёт. Кто не ставил… ну вы просто молоды)) забавно было вспоминать про инструменты, которые выдают в тебе возвраст разработчика, и объяснять это тем, кто в IT недавно)

🔥 Кто помнит — ставим огоньки)

© TheITDirector - авторский канал ИТ директора про опыт и системность.

#webdev #php #алдытут
Реклама. Бархударян Э.Э. ИНН 771575954801. erid: 2W5zFK1Bi2t