<br><br><div class="gmail_quote">5 мая 2009 г. 15:31 пользователь Victor B. Wagner <span dir="ltr"><<a href="mailto:vitus@altlinux.org">vitus@altlinux.org</a>></span> написал:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 2009.05.05 at 14:46:26 +0400, Evgeny Sinelnikov wrote:<br>
<br>
> 4 мая 2009 г. 19:00 пользователь Victor B. Wagner <[1]<a href="mailto:vitus@altlinux.org">vitus@altlinux.org</a>><br>
> написал:<br>
> [...]<br>
<div class="im">> В Alt зачем-то openssldir указывает в /var. При этом конфигурационный<br>
> файл, как и положено, лежит в /etc, engines посредством более менее<br>
> глубокого хака в исходниках перетащены в /usr/lib, каталог<br>
> сертификатов пустой, даже при установленном пакете ca-certificates,<br>
> а вот скрипты - остались. Исполняемые файлы радостно инсталлируются в<br>
> /var. Зачем?<br>
><br>
> Видимо, для следования FHS. Настройки кладутся в /etc, данные - в /var.<br>
<br>
</div>По-моему, FHS ни разу не одобряет исполняемых файлов в /var.<br>
Опять же, пакет ca-certificates ставит свои данные в /usr/share.<br>
<div class="im"><br>
<br>
> lrwxrwxrwx 1 root root 48 Мар 30 12:56 cert.pem -><br>
> ../../../usr/share/ca-certificates/ca-bundle.crt<br>
> drwxr-xr-x 2 root root 4096 Мар 30 12:56 certs<br>
> drwxr-xr-x 2 root root 4096 Мар 30 12:56 misc<br>
<br>
</div>Вот это самое misc, оно на самом деле такое bin. И в var ему не место.<br>
Хотя по хорошему счету ему место в /usr/share/doc/<something>/examples<br>
<div class="im"><br>
> lrwxrwxrwx 1 root root 32 Мар 30 12:56 openssl.cnf -><br>
> ../../../etc/openssl/openssl.cnf<br>
> drwx------ 2 root root 4096 Мар 27 20:35 private<br>
><br>
> Но, в целом, идея проста - в /var/lib/ssl/ обычная свалка, как везде... А,<br>
<br>
</div>Похоже, что наиболее правильным с точки зрения FHS будет держать<br>
openssldir в /etc Раз уж engines оттуда совсем оторвали.<br>
<br>
Каталоги private и сerts сделать линками в /var/lib/ssl, а openssl.cnf<br>
пусть прямо там лежит.<br>
<div class="im"></div></blockquote><div><br>Ну, да... если оно везде в /etc есть в таком варианте резон....<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> Кстати, здесь же стоит отметить, что файл настроек<br>
> /etc/openssl/openssl.cnf<br>
><br>
> Упакован, опять-таки по старому legacy (ибо я не придумал, как должно и<br>
> сделал как было), в два пакета libssl7 и libssl6, а ранее и в третьем<br>
> libssl4... По счастливому набору обстоятельств файлы идентичны и проблемы<br>
> вроде как не видно... Но тут, тоже стоит что-нибудь решить.<br>
<br>
</div>А вот теперь начнется. Потому что в файл openssl.cnf прописываются<br>
подключенные engines. У старого openssl gost engine нету, а у нового -<br>
есть.<br>
<br>
Кстати, да. Каталог хешированных сертификатов между openssl 0.9.x и<br>
openssl 1.0 несовместим. Они там алгоритм хэширования поменяли.<br>
Так что, видимо, openssldir для 0.9.8 и 1.0 придется разносить.<br>
<div class="im"></div></blockquote><div><br><br>Ну, вот и кто будет в /etc главным? не лучше ли тогда разнести в /var/lib/ssl-0.9.8 и /var/lib/ssl-1.0.0 ?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Смена soname у них прошла ещё в январе:<br>
> * Thu Jan 15 2009 Tomas Mraz <[2]<a href="mailto:tmraz@redhat.com">tmraz@redhat.com</a>> 0.9.8j-1<br>
<div class="im">> - new upstream version with necessary soname bump (#455753)<br>
<br>
</div>Ну, наверное в описании бага #455753 про причины написано.</blockquote><div><br>Ну, я не нашёл... Может быть не внимательно смотрел... С другой стороны я сверку делал на предмет ABI и API самостоятельно...<br><br><a href="https://bugzilla.redhat.com/show_bug.cgi?id=455753">https://bugzilla.redhat.com/show_bug.cgi?id=455753</a><br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> Я тогда не увидел особых изменений в ABI, но, видимо, они<br>
> перестраховались, а может я что-то пропустил...<br>
<br>
</div>><br>Честно сказать не в курсе. После 0.9.8f от перехода на которую мы<br>
отказались с в связи с большим объемом работы и сосредоточили все усилия<br>
на 1.0 (тогда 0.9.9) я за веткой 0.9.8 не особенно следил.<br>
<div class="im"></div></blockquote><div><br>Ну, тут речь идёт об API/ABI между 0.9.8g и 0.9.8j, и далее... То есть минорные изменения вроде бы...<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> Да, кстати, стоит подумать какой soname будет у openssl-1.0.0 ...<br>
<br>
</div>Предлагаю 10. Тогда и заодно и сразу будет видно, что это 1.0.<br>
Может, конечно, мы и промахнемся и когда fedora решит переходить на 1.0<br>
они туда поставят 9. Но очевидно, что уже не 8.<br>
<br>
Или можно оставить как в upstream - 1.0.0<br>
</blockquote><div><br>Последний вариант можно оставить до момента пока не начнём пересборку на нём... Пока можно не отдавать libssl-devel именно 1.0.0-beta, предоставляя желающим libssl1.0-devel.<br></div></div><br>-- <br>
Sin (Sinelnikov Evgeny)<br>