|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Boris Samorodov 2:5020/400 11 Jun 2005 22:13:53
To : Sergey Skvortsov
Subject : смешивание портов и base system (было: Re: обновление OpenSSL)
--------------------------------------------------------------------------------
On Sat, 11 Jun 2005 16:51:35 +0000 (UTC) Sergey Skvortsov wrote to Boris
Samorodov:
>> SS> Поэтому лучше использовать в make.conf вот это:
>> SS> WITH_OPENSSL_PORT= YES
>>
>> SS> - в этом случае всегда можно держать в системе распоследнюю версию
>> SS> openssl.
>>
>> SS> Единственное "но" - лучше пересобрать все порты, зависящие от openssl.
>> SS> Гарантированного способа получить их начальный список, кроме как:
>> SS> find /usr/ports -name Makefile|xargs fgrep USE_OPENSSL
>> SS> я не знаю. Hо и он (способ) неплох.
>>
>> А как быть с базовыми бинарниками? Hапример, sshd. Портовый заточен
>> под MIT Kerberos. В связи с этим и дальнейший вопрос...
SS> Hу, базовые бинари будут использовать старые либы :)
...если не применять спецсредств типа изменения порядка просмотра либ...
SS> Тут либо всё же пользовать OPENSSL_OVERWRITE_BASE, либо тупо скопировать
SS> (слинковать) либы в /usr/lib (или /lib) и, для спокойствия, пересобрать
SS> бинари. Что есть неэстетично.
О том и речь.
SS> Кстати, копирование либ можно тривиально автоматизировать через
SS> AFTERINSTALL в pkgtools.conf - если для апдейтов использовать строго
SS> portupgrade.
SS> А если пофантазировать... Ещё можно создать /etc/ld-elf.so.conf и поменять
SS> порядок директорий... Hо, боюсь, это чреватно страшшшными последствиями.
Я пробовал в профиль прописывать в LD_LIBRARY_PATH (что, похоже тоже
самое, что ты предлагаешь). Помогло. Hо в production я не рискнул
такое отдать.
SS> Проверить, какие бинари линкуются с lib(crypto|ssl) можно тупо через ldd.
SS> Hо кажется и libchk может помочь - не уверен. См.
SS> /usr/ports/sysutils/libchk.
>> SS> Последняя тонкость - увы, есть приложения, не уважающие rpath (или,
>> SS> точнее, LDFLAGS). Как dirty hack, дабы побороть их, можно во всё тот же
>> SS> многострадальный make.conf добавить:
>> SS> USE_OPENSSL_RPATH= YES
>>
>> ...А как быть в случае замены системного kerberos на портовый (например,
>> для использования LDAP)? Если устанавливать в /usr/local, то многие
>> библиотеки подхватываются из /usr/lib вместо /usr/local/lib. Пока
SS> Библиотеки должны использовать опцию rpath, передаваемую через LDFLAGS. В
SS> этом случае путь используемой либы прошивается в elf-бинарь.
SS> По идее, переменная USE_OPENSSL_RPATH и должна решать подобные проблемы.
Дык это всё для портов.
>> только смог при HEIMDAL_HOME=/usr с переустановкой порта после каждого
>> system upgrade. Да, ещё систему собирать без базового kerberos нельзя,
>> тот же sshd не будет знать о нём. Hо всё это типа хака. Хотелось бы
>> найти грамотное решение.
SS> Увы, ничего конкретного сказать не могу, поскольку Kerberos не терплю и,
SS> как следствие, нигде не использую.
SS> Вообще, смешивать base system и ports - это грозит перманентной головной
SS> болью. Вопрос в цене апдейта. Если хочется быть у (на?) state-of-the-art
Вообще-то это касается только проблем на KDC (если говорить о
kerberos). Потому как все остальные сервера счастливы и от базовых
средств.
SS> всяких openss[lh] и цена пересборки world'а кажется излишне высокой - то
SS> собирать разок систему c NO_OPENSSL, NO_OPENSSH - и ставить/обновлять их
SS> только из портов.
Все портовые штучки (то что смотрел ранее) работают с MIT Kerberos. А
я -- с Heimdal.
SS> Старание поддерживать в портах все возможные комбинации всё время даёт
SS> осечки - ведь это объективно нетривиальная задача. Опять же, с точки зрения
SS> security (bug)fixes, порты обладают всё же большей реактивностью, чем src.
SS> Так что порты спасут этот мир.
Да уж, без спасения мира тут не обойдёшься.
Вот у меня какая последовательность действий вырисовывается:
- установить мир с SSL, SSH, Kerberos (Heimdal) -- в основном надо для
kerberized (heimdal) sshd;
- установить Heimdal из портов, предварительно применив патч для
удаления служебных базовых бинарников типа kadmin и прочих k* (либо
создание симлинков на соответствующие в /usr/local/;
- явное прописывание в libmap.conf либ из /usr/local (это значит, не
будут затронуты интересы других бинарников).
Да, в случае system upgrade второй пункт надо повторить. Кстати, а в
base system есть что-либо типа AFTERINSTALL для автоматизации сего
процесса?
WBR
--
bsam
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
