Вебсервер под Linux: ошибка при логине после обновления на релиз 8.3.25+
День добрый!
Возникла следующая проблема при обновлении платформы на linux-сервере.
Конфигурация:
Fedora server 40, апач 2.4, платформа 8.3.24.1761, СЛК 3.0.37.11710, файловые базы (бух и зуп).
После обновления платформы до любой версии 8.3.25 или 8.3.26 при запуске клиента (windows 10) выдает ошибку:
При попытке открыть в браузере:
После возврата на платформу 8.3.24 (изменение пути к wsap24.so в конфиге и перезапуск апача) - все работает как и работало годами раньше.
В системных логах каких-либо ошибок доступа не наблюдается (в access.log апача только та же запись, что и в первой цитате).
Естественно, все права на файлы и каталоги у разных дистрибутивов платформы идентичные. Отключение SELinux эффекта также никакого не дало.
Саппорт, сославшись на то, что под Федорой они платформу не тестировали, умыл руки.
Кто-нибудь сталкивался с подобным? В какую сторону копать?
Возникла следующая проблема при обновлении платформы на linux-сервере.
Конфигурация:
Fedora server 40, апач 2.4, платформа 8.3.24.1761, СЛК 3.0.37.11710, файловые базы (бух и зуп).
После обновления платформы до любой версии 8.3.25 или 8.3.26 при запуске клиента (windows 10) выдает ошибку:
HTTP: Internal server error
Ошибка при работе с ресурсом /e1cib/login?vl=ru_RU&version=8.3.25.1445&clnPid=3152&dppw=0&nm=3328668772090033223&ld=jblw4QoT9S
Ошибка при работе с ресурсом /e1cib/login?vl=ru_RU&version=8.3.25.1445&clnPid=3152&dppw=0&nm=3328668772090033223&ld=jblw4QoT9S
При попытке открыть в браузере:
1C:Enterprise 8 application error: backbas: 2(0x00000002): No such file or directory
После возврата на платформу 8.3.24 (изменение пути к wsap24.so в конфиге и перезапуск апача) - все работает как и работало годами раньше.
В системных логах каких-либо ошибок доступа не наблюдается (в access.log апача только та же запись, что и в первой цитате).
Естественно, все права на файлы и каталоги у разных дистрибутивов платформы идентичные. Отключение SELinux эффекта также никакого не дало.
Саппорт, сославшись на то, что под Федорой они платформу не тестировали, умыл руки.
Кто-нибудь сталкивался с подобным? В какую сторону копать?
Найденные решения
В общем, разобрался с причиной ошибки на Fedora Server.
Дело оказалось в настройке сервиса апача MemoryDenyWriteExecute.
По умолчанию, она включена.
Чтобы ее деактивировать, нужно отредактровать (либо создать, если ранее другие настройки апача не менялись) файл /etc/systemd/system/httpd.service.d/override.conf, добавив в секцию [Service] соответствующую строку:
После необходимо обновить конфигурацию systemd, выполнив команду:
И (пере)запустить апач.
Проверил на релизах 8.3.26.1540 и последнем 8.3.27.1508 - полет нормальный.
Дело оказалось в настройке сервиса апача MemoryDenyWriteExecute.
По умолчанию, она включена.
Чтобы ее деактивировать, нужно отредактровать (либо создать, если ранее другие настройки апача не менялись) файл /etc/systemd/system/httpd.service.d/override.conf, добавив в секцию [Service] соответствующую строку:
[Service]
MemoryDenyWriteExecute=noПосле необходимо обновить конфигурацию systemd, выполнив команду:
# systemctl daemon-reloadИ (пере)запустить апач.
Проверил на релизах 8.3.26.1540 и последнем 8.3.27.1508 - полет нормальный.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Нет, пароли нигде не указываются и до них дело не доходит - ошибка возникает до появления окна выбора пользователя.
Все пути также указаны с учетом регистра везде.
Я все же склоняюсь к тому, что проблема в правах доступа и/или каких-то специфических путях к файлам/каталогам, но локализовать это точнее не выходит. Пробовал менять расположение временных файлов в default.vrd, но также безрезультатно. Куда еще эта зараза пытается ломиться и что ей в этом мешает - непонятно.
Все пути также указаны с учетом регистра везде.
Я все же склоняюсь к тому, что проблема в правах доступа и/или каких-то специфических путях к файлам/каталогам, но локализовать это точнее не выходит. Пробовал менять расположение временных файлов в default.vrd, но также безрезультатно. Куда еще эта зараза пытается ломиться и что ей в этом мешает - непонятно.
(3) Скажите проблему не победили? Сейчас на Ред ОС 8 смаркетанил так же веб сервер и установил платформу 8.3.26.1521 сситуация аналогичная:
HTTP: Internal server error
Ошибка при работе с ресурсом /e1cib/login?clnPid=18939&clnId=8bd465bb-f880-46a2-8eb8-b8c87283ea4c&vl=ru_RU&ni=-772019788&screenwidthcharunits=1755&ld=jblw4QoT9SPskLuQZUhLr
Ошибка при работе с ресурсом /e1cib/login?clnPid=18939&clnId=8bd465bb-f880-46a2-8eb8-b8c87283ea4c&vl=ru_RU&ni=-772019788&screenwidthcharunits=1755&ld=jblw4QoT9SPskLuQZUhLr
(4) Увы, нет.
Но у меня пока не было слишком много времени, чтобы вплотную ей заниматься.
Проверил только по списку зависимостей - все установлены, вряд ли дело в них.
Осталось разве что на голой ОС пробовать завести, чтобы исключить какие-нибудь внесенные на этапе конфигурирования настройки.
В общении с техподдержкой тоже особых идей новых не появилось ни у меня, ни у них.
Хотя в саппорте мне написали, что попробовали воспроизвести баг на РедОС и не обнаружили его:
Но у меня пока не было слишком много времени, чтобы вплотную ей заниматься.
Проверил только по списку зависимостей - все установлены, вряд ли дело в них.
Осталось разве что на голой ОС пробовать завести, чтобы исключить какие-нибудь внесенные на этапе конфигурирования настройки.
В общении с техподдержкой тоже особых идей новых не появилось ни у меня, ни у них.
Хотя в саппорте мне написали, что попробовали воспроизвести баг на РедОС и не обнаружили его:
Получилось перепроверить на ОС РедОС и Ubuntu 22 - на платформе 8.3.25.1501 такой проблемы нет.
(6) Да, но как уже писал выше, там мне ничем конкретным помочь не смогли, сославшись на то, что т.к. официально эту ОС не поддерживают, то не занимались тестированием работы платформы под Федорой.
А по описанию ошибок (которые не дают достаточной информации), без тестов, не могут подсказать, в чем именно может быть причина такого поведения.
А по описанию ошибок (которые не дают достаточной информации), без тестов, не могут подсказать, в чем именно может быть причина такого поведения.
Столкнулся с подобной ошибкой при попытке веб-доступа к БД на АльмаЛинукс, но правда права нигде не редактил особо.
Но где и как их выставлять правильно - тоже нигде не пишут, всё общими фразами...
Пока что грешу на права, тк 1С запускается из под клиента на винде
Но где и как их выставлять правильно - тоже нигде не пишут, всё общими фразами...
Пока что грешу на права, тк 1С запускается из под клиента на винде
(8) Тоже склоняюсь к тому, что проблема с правами где-то в не очевидном для меня месте.
После очередной попытки обновиться до платформы v8.3.26.1540, ошибка, при попытке подключиться к базе через браузер, изменилась на чуть более подробную (но все равно недостаточно подробную для локализации проблемы):
Посмотрим, что ответят в 1С.
После очередной попытки обновиться до платформы v8.3.26.1540, ошибка, при попытке подключиться к базе через браузер, изменилась на чуть более подробную (но все равно недостаточно подробную для локализации проблемы):
1C:Enterprise 8 application error:
Ошибка загрузки компоненты backbas: 2(0x00000002): /opt/1cv8/x86_64/8.3.26.1540/backbas.so: cannot make segment writable for relocation: Permission denied
Ошибка загрузки компоненты backbas: 2(0x00000002): /opt/1cv8/x86_64/8.3.26.1540/backbas.so: cannot make segment writable for relocation: Permission denied
Посмотрим, что ответят в 1С.
(9)
У себя нашёл причину!!!
Нужно в папке дистра, например /opt/1cv8/x86_64/8.3.25.1374/ поменять права на файл wsap24.so - по дефолту там root:root и права 644, а нужно изменить права на 777 или изменить пользователя и группу этого файла, чтоб у апача (httpd) было право на выполнение этого файла.
И всё заработало!
cannot make segment writable for relocation: Permission denied
У себя нашёл причину!!!
Нужно в папке дистра, например /opt/1cv8/x86_64/8.3.25.1374/ поменять права на файл wsap24.so - по дефолту там root:root и права 644, а нужно изменить права на 777 или изменить пользователя и группу этого файла, чтоб у апача (httpd) было право на выполнение этого файла.
И всё заработало!
(14) Права 777 я привёл для примера - это эффективный способ понять, поможет или нет.
Естественно, если это поможет, то нужно выставить соответствующие права, например 654, добавив юзера apache в группу 1с, кстати и наоборот тоже нужно сделать - юзера 1С в группу апача (видел статьи, в которых это описывалось)
По дефолту на файле права 644, то есть без возможности запуска - в этом случае не заработает без смены прав как ни крути
Естественно, если это поможет, то нужно выставить соответствующие права, например 654, добавив юзера apache в группу 1с, кстати и наоборот тоже нужно сделать - юзера 1С в группу апача (видел статьи, в которых это описывалось)
По дефолту на файле права 644, то есть без возможности запуска - в этом случае не заработает без смены прав как ни крути
(12) К сожалению, чуда не случилось.
Ни повышение прав, ни смена владельца как отдельно на модуль веб-сервера, так и на всю директорию платформы с ее содержимым, не дали никакого результата в моем случае.
Да и версии вплоть до 8.3.24 тоже прекрасно обходятся стандартными правами.
Ни повышение прав, ни смена владельца как отдельно на модуль веб-сервера, так и на всю директорию платформы с ее содержимым, не дали никакого результата в моем случае.
Да и версии вплоть до 8.3.24 тоже прекрасно обходятся стандартными правами.
(20) Я в эти выходные тестировал в виртуалках, в том числе и на других, поддерживаемых дистрах (после того как техподдержка в очередной раз послала, сославшись на отсутствие поддержки Федоры). На RedOS 8 тоже сначала не завелось, но после выставления httpd_execmem=1 в флагах SELinux, заработало. Ни с правами, ни с чем-то еще играть не пришлось. Попробуйте, если еще не.
Жаль, что на Fedora проблема не в этом.
Последнее, что удалось выжать из саппорта:
Но что-то я в этом сильно сомневаюсь. Появились мысли, что возможно надо поискать в настройках сервиса апача в systemd, может он какие-то ограничения накладывает на доступ, но это уже в следующие выходные.
Жаль, что на Fedora проблема не в этом.
Последнее, что удалось выжать из саппорта:
>> Сервер Fedora Linux x64,
>> На сервере ядро 6.11.8.
>> cannot make segment writable for relocation: Permission denied
Такое сообщение об ошибке может быть возвращено операционной системой при загрузке библиотеки, если операционная система не поддерживает "Generate position-independent code (PIC)".
Если информация об операционной системе осталась актуальной, то убедитесь, пожалуйста, в вашем дистрибутиве есть поддержка PIC и системные библиотеки собираются с его поддержкой.
>> На сервере ядро 6.11.8.
>> cannot make segment writable for relocation: Permission denied
Такое сообщение об ошибке может быть возвращено операционной системой при загрузке библиотеки, если операционная система не поддерживает "Generate position-independent code (PIC)".
Если информация об операционной системе осталась актуальной, то убедитесь, пожалуйста, в вашем дистрибутиве есть поддержка PIC и системные библиотеки собираются с его поддержкой.
На текущий момент есть факт: при загрузке библиотеки операционная система возвращает ошибку "cannot make segment writable for relocation: Permission denied".
Возможно, какая-то из системных библиотек была собрана без поддержки PIC.
Возможно, какая-то из системных библиотек была собрана без поддержки PIC.
Но что-то я в этом сильно сомневаюсь. Появились мысли, что возможно надо поискать в настройках сервиса апача в systemd, может он какие-то ограничения накладывает на доступ, но это уже в следующие выходные.
(22) Список всех флагов SELinux выводится по команде "getsebool -a" (можно погрепать: "getsebool -a | grep httpd", чтобы посмотреть только относящиеся к апачу).
Соответственно, установить (или снять) любой из них можно командой "setsebool <имя_флага> 1/0/on/off".
В данном случае, нужна команда "setsebool httpd_execmem 1" (будет работать до перезагрузки), либо "setsebool -P httpd_execmem 1" (будет работать постоянно).
Соответственно, установить (или снять) любой из них можно командой "setsebool <имя_флага> 1/0/on/off".
В данном случае, нужна команда "setsebool httpd_execmem 1" (будет работать до перезагрузки), либо "setsebool -P httpd_execmem 1" (будет работать постоянно).
(23) Спасибо!
После изменения флага пошла другая ошибка
Теперь понятно что с доступом беда.
apache сделал права доступа на базу + 1Cv8Temp в рекурсивно.
1С так рекомендует.
После изменения флага пошла другая ошибка
Ошибка загрузки компонент работы с файловым вариантом информационной базы
по причине:
Ошибка загрузки компоненты 'help'
по причине:
Не удалось получить имя временного файла. Проверьте права доступа к директории временных файлов.
[AccessViolation]
по причине:
Ошибка загрузки компоненты 'help'
по причине:
Не удалось получить имя временного файла. Проверьте права доступа к директории временных файлов.
[AccessViolation]
Теперь понятно что с доступом беда.
apache сделал права доступа на базу + 1Cv8Temp в рекурсивно.
1С так рекомендует.
[root@redsr raid1]# cd /mnt/raid1/demo/
[root@redsr demo]# ls -l
итого 2328404
-rwxrwxrwx. 1 apache apache 2384134144 мар 5 07:02 1Cv8.1CD
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8.1CD.cfl
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8.1CL.cfl
-rwxrwxrwx. 1 apache apache 0 фев 21 20:48 1Cv8.cgr
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8.cgr.cfl
drwxrwsrwx. 3 apache apache 4096 фев 21 20:01 1Cv8FTxt
drwxrwsrwx. 2 apache apache 4096 фев 21 20:05 1Cv8JobScheduler
drwxrwsrwx. 2 apache apache 4096 мар 5 07:01 1Cv8Log
-rwxrwxrwx. 1 apache apache 114688 мар 1 07:54 1Cv8snc.1CD
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8snc.1CD.cfl
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8snc.1CL.cfl
drwxrwsrwx. 2 apache apache 4096 фев 26 06:52 1Cv8Temp
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8tmp.1CD.cfl
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8tmp.1CL.cfl
Показать[root@redsr demo]# ls -l
итого 2328404
-rwxrwxrwx. 1 apache apache 2384134144 мар 5 07:02 1Cv8.1CD
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8.1CD.cfl
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8.1CL.cfl
-rwxrwxrwx. 1 apache apache 0 фев 21 20:48 1Cv8.cgr
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8.cgr.cfl
drwxrwsrwx. 3 apache apache 4096 фев 21 20:01 1Cv8FTxt
drwxrwsrwx. 2 apache apache 4096 фев 21 20:05 1Cv8JobScheduler
drwxrwsrwx. 2 apache apache 4096 мар 5 07:01 1Cv8Log
-rwxrwxrwx. 1 apache apache 114688 мар 1 07:54 1Cv8snc.1CD
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8snc.1CD.cfl
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8snc.1CL.cfl
drwxrwsrwx. 2 apache apache 4096 фев 26 06:52 1Cv8Temp
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8tmp.1CD.cfl
-rwxrwxrwx. 1 apache apache 0 дек 31 07:57 1Cv8tmp.1CL.cfl
(25)
Я у себя в рабочем варианте делал temp="/tmp/1C".
Если для апача в файле сервиса systemd включено PrivateTmp, то он кладет временные файлы в каталог вида /tmp/systemd-private-...-httpd.service-.../tmp/1C.
Если PrivateTmp выключено, то сразу в /tmp/1C.
И в первом и во втором случае проблем с доступом к временным файлам у 1С больше не возникало.
Единственно, если баз крутится несколько, то надо назначить для них отдельные каталоги, например, /tmp/1C/Base1 и т.д., чтобы не было конфликта при совпадении имен файлов.
Я у себя в рабочем варианте делал temp="/tmp/1C".
Если для апача в файле сервиса systemd включено PrivateTmp, то он кладет временные файлы в каталог вида /tmp/systemd-private-...-httpd.service-.../tmp/1C.
Если PrivateTmp выключено, то сразу в /tmp/1C.
И в первом и во втором случае проблем с доступом к временным файлам у 1С больше не возникало.
Единственно, если баз крутится несколько, то надо назначить для них отдельные каталоги, например, /tmp/1C/Base1 и т.д., чтобы не было конфликта при совпадении имен файлов.
(25)
Еще как возможная причина - у этой директории нет контекста SELinux httpd_tmp_t, в отличие от стандартного временного каталога апача в /tmp.
Ну и каталогу с базами тоже желательно дать контекст httpd_sys_rw_content_t или, если планируется еще расшаривать доступ и для самбы, public_content_rw_t и разрешить апачу писать туда, включив флаг SELinux httpd_anon_write.
дал на эту папку права apache. Не завелось ))).
Еще как возможная причина - у этой директории нет контекста SELinux httpd_tmp_t, в отличие от стандартного временного каталога апача в /tmp.
Ну и каталогу с базами тоже желательно дать контекст httpd_sys_rw_content_t или, если планируется еще расшаривать доступ и для самбы, public_content_rw_t и разрешить апачу писать туда, включив флаг SELinux httpd_anon_write.
В общем, разобрался с причиной ошибки на Fedora Server.
Дело оказалось в настройке сервиса апача MemoryDenyWriteExecute.
По умолчанию, она включена.
Чтобы ее деактивировать, нужно отредактровать (либо создать, если ранее другие настройки апача не менялись) файл /etc/systemd/system/httpd.service.d/override.conf, добавив в секцию [Service] соответствующую строку:
После необходимо обновить конфигурацию systemd, выполнив команду:
И (пере)запустить апач.
Проверил на релизах 8.3.26.1540 и последнем 8.3.27.1508 - полет нормальный.
Дело оказалось в настройке сервиса апача MemoryDenyWriteExecute.
По умолчанию, она включена.
Чтобы ее деактивировать, нужно отредактровать (либо создать, если ранее другие настройки апача не менялись) файл /etc/systemd/system/httpd.service.d/override.conf, добавив в секцию [Service] соответствующую строку:
[Service]
MemoryDenyWriteExecute=noПосле необходимо обновить конфигурацию systemd, выполнив команду:
# systemctl daemon-reloadИ (пере)запустить апач.
Проверил на релизах 8.3.26.1540 и последнем 8.3.27.1508 - полет нормальный.
(29)
MemoryDenyWriteExecute
Какой-то странный и вредный совет. Фактически, этот параметр запрещает выполнение кода в сегментах данных, по крайней мере запрещает писать в сегменты кода. На кой хрен 1С пытается там что-то изменить? Я не знаю. А может быть у чела на компе майнер завелся или еще чего. Вы это там осторожнее с настройками.
(30)
Дополнительно посмотрел, как обстоят дела на RedOS в виртуалке: по умолчанию такой опции там у апача нет, поэтому все работает при прочих равных. При ее активации, ошибка также начинает воспроизводиться, как и на федоре.
На кой хрен 1С пытается там что-то выполнить?
Кто ж ее знает. Даже саппорту неведомо, чего они там такого нахеровертили после 8.3.24.
Дополнительно посмотрел, как обстоят дела на RedOS в виртуалке: по умолчанию такой опции там у апача нет, поэтому все работает при прочих равных. При ее активации, ошибка также начинает воспроизводиться, как и на федоре.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот