ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Правильно добавить версию в пути поиска /usr/lib/ruby/site_ruby/2.3.0/x86_64-linux | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Gleb Kulikov <glebus> | ||||
| Component: | ruby | Assignee: | majioa <majioa> | ||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | boyarsh, cas, imz, ldv, led, majioa, mike, nbr, pav, rider, stalker, vitty, viy, vseleznv | ||||
| Version: | unstable | ||||||
| Hardware: | all | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
Эти скрипты работают только с настроенным ALT-доменом (http://altlinux.org/Домен). Неясно, какой LDAP-сервер вы используете. (В ответ на комментарий №1) > Эти скрипты работают только с настроенным ALT-доменом да, конечно, домен давно настроен. С авторизацией и проч., проблем НЕТ. В любом случае, см. относительно ldap-getent > (http://altlinux.org/Домен). Неясно, какой LDAP-сервер вы используете. openLDAP. Работает: ldap-user-tools-0.9.2-alt1 ruby-ldap-0.9.11-alt2.3 НЕ РАБОТАЕТ: ldap-user-tools-0.9.3-alt1.noarch ruby-ldap-0.9.17-alt1.x86_64 alterator-cmdline /net-domain action read domain:xxxx.tsu.ru domain_type:altdomain resolver:OK access:OK ldap:OK kdc:OK smb:OK (XXXX) dhcpd:Error: domain name xxxx.tsu.ru is not provided to clients [нормально, работает dnsmasq и через него-же отдаются srv-host=_ldap._tcp... kerberos и т.д. ] master:#t ad_dns:127.0.0.1 ad_service:НЕ ГОТОВА (служба остановлена) ad_domain:-- ad_realm:-- ad_dc_name:-- ad_ldap_server:-- ad_kdc_server:-- altdomain_is_available:#t ad_is_available:#f (В ответ на комментарий №1)
> (http://altlinux.org/Домен). Неясно, какой LDAP-сервер вы используете.
openldap-servers-2.4.42-alt4.x86_64
> Работает:
> ldap-user-tools-0.9.2-alt1
>
> НЕ РАБОТАЕТ:
> ldap-user-tools-0.9.3-alt1.noarch
Изменения в ldap-user-tools определённо не могут привести к такому эффекту.
(В ответ на комментарий №4) > > Работает: > > ldap-user-tools-0.9.2-alt1 > > > > НЕ РАБОТАЕТ: > > ldap-user-tools-0.9.3-alt1.noarch > Изменения в ldap-user-tools определённо не могут привести к такому эффекту. воспроизводится на двух системах. корень зла --- в ldap_parse_reply group "$@" я в руби ни бум бум, далее проследить не получается На ruby-ldap. # ll /usr/lib/ruby/site_ruby/x86_64-linux/curses.so
-rw-r--r-- 1 root root 47904 окт 25 14:44 /usr/lib/ruby/site_ruby/x86_64-linux/curses.so
# ruby
require "curses"
/usr/lib/ruby/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- curses.so (LoadError)
from /usr/lib/ruby/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/site_ruby/curses.rb:1:in `<top (required)>'
from /usr/lib/ruby/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/rubygems/core_ext/kernel_require.rb:55:in `require'
from -:1:in `<main>'
Тест: ruby -e 'puts $:' | xargs ls >/dev/null Не должно возвращать ничего. На p8: # ruby -e 'puts $:' | xargs ls >/dev/null # На Sisyphus # ruby -e 'puts $:' | xargs ls >/dev/null ls: невозможно получить доступ к /usr/lib/ruby/site_ruby/2.3.0: Нет такого файла или каталога ls: невозможно получить доступ к /usr/lib/ruby/site_ruby/2.3.0/x86_64-linux: Нет такого файла или каталога ls: невозможно получить доступ к /usr/lib/ruby/vendor_ruby/2.3.0: Нет такого файла или каталога ls: невозможно получить доступ к /usr/lib/ruby/vendor_ruby/2.3.0/x86_64-linux: Нет такого файла или каталога # Created attachment 6996 [details] отдельный бинарник, заменяющий ldap-parse_reply для проверки повторяемости "зависаний" скриптов ldap-... > ls: невозможно получить доступ к /usr/lib/ruby/vendor_ruby/2.3.0: Нет такого Действительно, после создания /usr/lib/ruby/site_ruby/2.3.0 и размещении в нём симлинков на * ruby'ивские *.so из /usr/lib/ruby/site_ruby/, работа восстанавливается. Но вот что странно, при массовых операциях (манипуляции пользователями из отдельного скрипта), замечены "зависания" на ruby . Понять причину подвисаний не получается. Для проверки, сделал простую программу на замену ruby-скрипта "ldap_parse_reply". Для чистоты эксперимента, "голый" бинарник, без питона и прочих излишеств. Действительно, "зависания" при вызове ldap-getent прекратились, но понятно, что проблему это не решает. PS: есть надежда на решение неприятностей с руби? ...ну и разумеется, в копию не попал собственно nbr@ -- надо ACL поправить. Забираю. Делаю правильный ruby. Прошу тестировать задание #179259. Возможно с ним надо будет перекомпилировать некоторые ruby модули, имеющие .so части, так что их можно добавлять в это задание - оно расшарено. (В ответ на комментарий №12) > Прошу тестировать задание #179259. > Возможно с ним надо будет перекомпилировать некоторые ruby модули, имеющие .so > части, так что их можно добавлять в это задание - оно расшарено. Не некоторые, а все компилируемые. Сделал таск #179408 и добавил туда все нужные модули. Возникла проблема с ruby-ffi-yajl, но это решим. (В ответ на комментарий №13) > Не некоторые, а все компилируемые. Сделал таск #179408 и добавил туда все > нужные модули. Возникла проблема с ruby-ffi-yajl, но это решим. rpm-build-ruby тоже надо поправить. Модули ищут ruby(ffi_c), а собранный пакет провайдит ruby(2.3.1/x86_64-linux/ffi_c), ruby(2.3.1/x86_64-linux/ffi_c.so) Если второй к месту, то первый содержит избыточные пути. Иван, что скажешь? (В ответ на комментарий №14) > (В ответ на комментарий №13) > > Не некоторые, а все компилируемые. Сделал таск #179408 и добавил туда все > > нужные модули. Возникла проблема с ruby-ffi-yajl, но это решим. > rpm-build-ruby тоже надо поправить. Модули ищут ruby(ffi_c), а собранный пакет > провайдит ruby(2.3.1/x86_64-linux/ffi_c), ruby(2.3.1/x86_64-linux/ffi_c.so) > Если второй к месту, то первый содержит избыточные пути. > > Иван, что скажешь? Я подозреваю, что в ruby.prov вставить s,^(site|vendor)_ruby/,, >>>>>>>>>>>s,^2\.3\.1/,, s,^$RPM_RUBY_ARCH/,, То всё сработает. Но некрасиво версию вставлять явно. Попробую через [0-9.]\+ А нужно ли отрывать версию abi из путей устанвоки модулей? Они же ставятся в директорию == версии ABI. Вот например путь в debian /usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.1.0/mysql/mysql_api.so Или мы опять делаем свой велосипед ни с кем не совместимый для любителей в случае чего ломать голову? (В ответ на комментарий №16) > А нужно ли отрывать версию abi из путей устанвоки модулей? > > Они же ставятся в директорию == версии ABI. > > Вот например путь в debian > > /usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.1.0/mysql/mysql_api.so > > Или мы опять делаем свой велосипед ни с кем не совместимый для любителей в > случае чего ломать голову? Как раз в новой сборке Ruby .so-шки ставятся не в site_ruby/x86_64-linux/, а в site_ruby/2.3.1/x86_64-linux/ Сами архитектурно-независимые .rb - в site-ruby без версии. (В ответ на комментарий №16) > Вот например путь в debian > Или мы опять делаем свой велосипед Как раз Debian и есть самый большой велосипед из костылей и подпорок, раз существует в единственном экземпляре. Один приведённый путь чего стоит! А.. rvm на девел хосте в юзерской установке ./rubies/ruby-2.2.2/lib/ruby/2.2.0/x86_64-linux/socket.so ./rubies/ruby-2.2.2/lib/ruby/2.2.0/x86_64-linux/openssl.so ./rubies/ruby-2.2.2/lib/ruby/2.2.0/x86_64-linux/stringio.so Я видимо не правильно понял описание бага.Исходя из темы складывается ощущение что отрывается вовсе версия..то есть вместо -/usr/lib/ruby/site_ruby/2.3.0/x86_64-linux +/usr/lib/ruby/site_ruby/x86_64-linux (В ответ на комментарий №19) > Я видимо не правильно понял описание бага.Исходя из темы складывается ощущение > что отрывается вовсе версия..то есть вместо Как раз раньше было без версии. Сейчас она появилась. Денис, последняя проблема, оставшаяся в Ruby: старый вариант: $ ruby -e 'print RbConfig::CONFIG["sitearchdir"]' /usr/lib/ruby/site_ruby/x86_64-linux новый вариант: $ ruby -e 'print RbConfig::CONFIG["sitearchdir"]' /usr/lib/ruby/2.3.1/x86_64-linux должно быть: /usr/lib/ruby/site_ruby/2.3.1/x86_64-linux Из-за этого 7 пакетов не собираются. В спеке Ruby: + --with-sitearchdir=%libdir/%version/%ruby_arch \ Но пакеты туда не ставят. (In reply to comment #22) > В спеке Ruby: > + --with-sitearchdir=%libdir/%version/%ruby_arch \ > > Но пакеты туда не ставят. Да. Сейчас пересоберу с --with-sitearchdir=%libdir/site_ruby/%version/%ruby_arch (In reply to comment #23) > (In reply to comment #22) > > В спеке Ruby: > > + --with-sitearchdir=%libdir/%version/%ruby_arch \ > > > > Но пакеты туда не ставят. > Да. Сейчас пересоберу с > --with-sitearchdir=%libdir/site_ruby/%version/%ruby_arch прошу обновить из задания сейчас --with-sitearchdir=%libdir/site_ruby/%version/%ruby_arch \ --with-vendorarchdir=%libdir/vendor_ruby/%version/%ruby_arch \ (В ответ на комментарий №24) > (In reply to comment #23) > > (In reply to comment #22) > > > В спеке Ruby: > > > + --with-sitearchdir=%libdir/%version/%ruby_arch \ > > > > > > Но пакеты туда не ставят. > > Да. Сейчас пересоберу с > > --with-sitearchdir=%libdir/site_ruby/%version/%ruby_arch > прошу обновить из задания > сейчас > --with-sitearchdir=%libdir/site_ruby/%version/%ruby_arch \ > --with-vendorarchdir=%libdir/vendor_ruby/%version/%ruby_arch \ Пересобираю. Всё равно пофиксил штук 6 пакетов, которые не учитывали ruby_sitearchdir. Сейчас остаются 7 пакетов с анметами по зависимостям. После их починки задание может собраться. Исправлено в ruby-2.3.1-alt2 |
при попытке добавить пользователя через ldap-useradd, получаем ошибку ldap_add: Invalid syntax (21) additional info: gidNumber: value #0 invalid per syntax при просмотре генерируемого ldif оказывается, что поле gidNumber: пустое. дальнейшее разбирательство приводит к скрипту ldap-getent group, не возвращающему список групп. строка 51 в функции ldap_serach_groups() ldap_parse_reply group "$@" выдаёт ошибку /usr/lib/ruby/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- ldap (LoadError) from /usr/lib/ruby/rubygems/core_ext/kernel_require.rb:55:in `require' from -e:2:in `<main>'