[sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[Aleksey Avdeev]

Здравствуйте.

  Перевожу сервер с M2.4 на С3.0. В процессе перевода возникли проблемы
с subversion (репозитарии недоступны). Оказалось, что даже svnadmin
работает криво:

$ svnadmin help
svnadmin: Bad database version: got 4.2.52, should be at least 4.3.28

(В error_log -- dav ругается на тоже самое.)

Установлено:

$ rpm -qa|fgrep subversion
subversion-python-1.2.3-alt2
subversion-1.2.3-alt2
subversion-server-common-1.2.3-alt2
subversion-server-dav-1.2.3-alt2
subversion-doc-1.2.3-alt2
libsubversion-1.2.3-alt2
subversion-tools-1.2.3-alt2

$ rpm -qa|fgrep db4
libdb4.3_cxx-4.3.28-alt1
libdb4.3-devel-4.3.28-alt1
libdb4.3_java-4.3.28-alt1
libdb4.3-4.3.28-alt1
libdb4.2-4.2.52-alt4.1
^^^^^^^^^^^^^^^^^^^^^^
db4.3-utils-4.3.28-alt1

  Смущает выделенное. При попытки снести, получаю:

]$ sudo -H apt-get remove libdb4.2
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Следующие пакеты будут УДАЛЕНЫ:
  apache2 apache2-manual apache2-mod_ssl apache2-mod_webauth
apache2-mod_webauthldap
  apache2-mod_webauthldap-tests apache2-suexec libaprutil libdb4.2
libsubversion subversion subversion-python
  subversion-server-common subversion-server-dav subversion-tools webauth

  Как разрулить ситуацию? (Желательно без пересборки. :-))

PS: Багу вешать?

-- 

С уважением. Алексей.

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]

On Sat, Jan 21, 2006 at 11:24:33PM +0300, Aleksey Avdeev wrote:
>   Перевожу сервер с M2.4 на С3.0. В процессе перевода возникли проблемы
> с subversion (репозитарии недоступны).

В любом случае при использовании формата bdb нужно сначала сделать
_старой_ версией svnadmin dump, потом после обновления восстановить
репозитории в новом формате с помощью svnadmin load.  С форматом fsfs
подобных граблей нет.

> Оказалось, что даже svnadmin работает криво:
> 
> $ svnadmin help
> svnadmin: Bad database version: got 4.2.52, should be at least 4.3.28
> 
> (В error_log -- dav ругается на тоже самое.)
> 
> Установлено:
> 
> $ rpm -qa|fgrep subversion
> subversion-python-1.2.3-alt2
> subversion-1.2.3-alt2
> subversion-server-common-1.2.3-alt2
> subversion-server-dav-1.2.3-alt2
> subversion-doc-1.2.3-alt2
> libsubversion-1.2.3-alt2
> subversion-tools-1.2.3-alt2
> 
> $ rpm -qa|fgrep db4
> libdb4.3_cxx-4.3.28-alt1
> libdb4.3-devel-4.3.28-alt1
> libdb4.3_java-4.3.28-alt1
> libdb4.3-4.3.28-alt1
> libdb4.2-4.2.52-alt4.1
> ^^^^^^^^^^^^^^^^^^^^^^
> db4.3-utils-4.3.28-alt1

А libapr и libaprutil?

>   Смущает выделенное. При попытки снести, получаю:
> 
> ]$ sudo -H apt-get remove libdb4.2
> Чтение списков пакетов... Завершено
> Построение дерева зависимостей... Завершено
> Следующие пакеты будут УДАЛЕНЫ:
>   apache2 apache2-manual apache2-mod_ssl apache2-mod_webauth
> apache2-mod_webauthldap
>   apache2-mod_webauthldap-tests apache2-suexec libaprutil libdb4.2
> libsubversion subversion subversion-python
>   subversion-server-common subversion-server-dav subversion-tools webauth
> 
>   Как разрулить ситуацию? (Желательно без пересборки. :-))

Непосредственная зависимость на libdb-*.so есть только в пакете
libaprutil - остальные компоненты subversion, похоже, получают libdb
косвенным образом.  Возможно, в системе каким-то образом завалялясь
старая версия libaprutil, собранная ещё с libdb4.2 - в этом случае
следует обновить именно её.

libsubversion требует libapr >= 1:0.9.5-alt0.4, и не указывает явно
требуемую версию libaprutil; возможно, в пакет следует добавить
зависимость на libaprutil версии не ниже, чем использованная при
сборке пакета.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[Sviataslau Svirydau]

Sergey Vlasov wrote:
> ...
>
> libsubversion требует libapr >= 1:0.9.5-alt0.4, и не указывает явно
> требуемую версию libaprutil; возможно, в пакет следует добавить
> зависимость на libaprutil версии не ниже, чем использованная при
> сборке пакета.
>   
В принципе, может, конечно, прокатить... за счет того, что в бэкпортс 
кладется всегда версия меньше, чем в сизифе... так и сделать?

-- 
Best regards,
Sviatoslav Sviridov
--
Real Users know your home telephone number.

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[Aleksey Avdeev]

Sergey Vlasov пишет:
> On Sat, Jan 21, 2006 at 11:24:33PM +0300, Aleksey Avdeev wrote:
> 
>>  Перевожу сервер с M2.4 на С3.0. В процессе перевода возникли проблемы
>>с subversion (репозитарии недоступны).
> 
> 
> В любом случае при использовании формата bdb нужно сначала сделать
> _старой_ версией svnadmin dump, потом после обновления восстановить
> репозитории в новом формате с помощью svnadmin load.  С форматом fsfs
> подобных граблей нет.

  В данном случаи, я ССЗБ (на авось, понадеялся). В прочем, в данном
случаи мне это и не помогло бы: ошибка всплывает, в том числе и _до_
обращения к базам...

> 
> 
>>Оказалось, что даже svnadmin работает криво:
>>
>>$ svnadmin help
>>svnadmin: Bad database version: got 4.2.52, should be at least 4.3.28
>>
>>(В error_log -- dav ругается на тоже самое.)
>>
>>Установлено:
>>
>>$ rpm -qa|fgrep subversion
>>subversion-python-1.2.3-alt2
>>subversion-1.2.3-alt2
>>subversion-server-common-1.2.3-alt2
>>subversion-server-dav-1.2.3-alt2
>>subversion-doc-1.2.3-alt2
>>libsubversion-1.2.3-alt2
>>subversion-tools-1.2.3-alt2
>>
>>$ rpm -qa|fgrep db4
>>libdb4.3_cxx-4.3.28-alt1
>>libdb4.3-devel-4.3.28-alt1
>>libdb4.3_java-4.3.28-alt1
>>libdb4.3-4.3.28-alt1
>>libdb4.2-4.2.52-alt4.1
>>^^^^^^^^^^^^^^^^^^^^^^
>>db4.3-utils-4.3.28-alt1
> 
> 
> А libapr и libaprutil?

$ rpm -qa|fgrep libapr
libapr-0.9.7-alt0.M24.1
libaprutil-0.9.7-alt0.M24.1

> 
> 
>>  Смущает выделенное. При попытки снести, получаю:
>>
>>]$ sudo -H apt-get remove libdb4.2
>>Чтение списков пакетов... Завершено
>>Построение дерева зависимостей... Завершено
>>Следующие пакеты будут УДАЛЕНЫ:
>>  apache2 apache2-manual apache2-mod_ssl apache2-mod_webauth
>>apache2-mod_webauthldap
>>  apache2-mod_webauthldap-tests apache2-suexec libaprutil libdb4.2
>>libsubversion subversion subversion-python
>>  subversion-server-common subversion-server-dav subversion-tools webauth
>>
>>  Как разрулить ситуацию? (Желательно без пересборки. :-))
> 
> 
> Непосредственная зависимость на libdb-*.so есть только в пакете
> libaprutil - остальные компоненты subversion, похоже, получают libdb
> косвенным образом.  Возможно, в системе каким-то образом завалялясь
> старая версия libaprutil, собранная ещё с libdb4.2 - в этом случае
> следует обновить именно её.

  OK. но облом:

$ sudo -H apt-get install libapr libaprutil
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Последняя версия libapr уже установлена.
Последняя версия libaprutil уже установлена.
0 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 1 не
будет обновлено.

  У нас в Backports 2.4 (у меня было M2.4+Backports2.4) libapr более
новый чем в C3.0 (0.9.7-alt0.M24.1 и 0.9.6-alt1, соответственно)...

  Бэкпартировать 0.9.7 для Backports3.0? Для себя -- сделать смогу
(наверное) готового, для C3.0 -- у меня нет.

> 
> libsubversion требует libapr >= 1:0.9.5-alt0.4, и не указывает явно
> требуемую версию libaprutil; возможно, в пакет следует добавить
> зависимость на libaprutil версии не ниже, чем использованная при
> сборке пакета.

PS: Пошлю описание ситуации в Backports: думаю, что обновление D(n)+B(n)
до D(n+1) -- должно проходить гладко. По факту -- мы этого не имеем
(оказалось, что libapr -- не один пакет, dist-upgrade переживший).

-- 

С уважением. Алексей.

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[Sviataslau Svirydau]

Aleksey Avdeev wrote:
>   У нас в Backports 2.4 (у меня было M2.4+Backports2.4) libapr более
> новый чем в C3.0 (0.9.7-alt0.M24.1 и 0.9.6-alt1, соответственно)...
> ...
>   
>> libsubversion требует libapr >= 1:0.9.5-alt0.4, и не указывает явно
>> требуемую версию libaprutil; возможно, в пакет следует добавить
>> зависимость на libaprutil версии не ниже, чем использованная при
>> сборке пакета.
>>     
Плучается, что даже это не спасет...

> PS: Пошлю описание ситуации в Backports: думаю, что обновление D(n)+B(n)
> до D(n+1) -- должно проходить гладко. По факту -- мы этого не имеем
> (оказалось, что libapr -- не один пакет, dist-upgrade переживший).
>   
Вот это как раз вряд ли можно гарантировать. В Backports все же попадают
пакеты из сизифа в основном, т.е. с версией не меньше, чем в любом
вышедшем дистрибутиве. Поэтому для обновления D(n)+B(n) до D(n+1) надо
использовать как минимум D(n+1)+B(n+1), и то это еще ничего не
гарантирует...

-- 
Best regards,
Sviatoslav Sviridov
--
You will have a long and unpleasant discussion with your supervisor.

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[Aleksey Avdeev]

Sviataslau Svirydau пишет:
> 
>> PS: Пошлю описание ситуации в Backports: думаю, что обновление D(n)+B(n)
>> до D(n+1) -- должно проходить гладко. По факту -- мы этого не имеем
>> (оказалось, что libapr -- не один пакет, dist-upgrade переживший).
>>   
> 
> Вот это как раз вряд ли можно гарантировать. В Backports все же попадают
> пакеты из сизифа в основном, т.е. с версией не меньше, чем в любом
> вышедшем дистрибутиве. Поэтому для обновления D(n)+B(n) до D(n+1) надо
> использовать как минимум D(n+1)+B(n+1), и то это еще ничего не
> гарантирует...

  Да.

  Похоже, что придётся поддерживать синхронность Backports, в конечном
итоге. Чтобы до D(n+1)+B(n+1) можно было обновляться простым образом...

-- 

С уважением. Алексей.

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[Aleksey Avdeev]

Sergey Vlasov пишет:
> On Sat, Jan 21, 2006 at 11:24:33PM +0300, Aleksey Avdeev wrote:
> 
>>  Перевожу сервер с M2.4 на С3.0. В процессе перевода возникли проблемы
>>с subversion (репозитарии недоступны).
> 
> 
> В любом случае при использовании формата bdb нужно сначала сделать
> _старой_ версией svnadmin dump, потом после обновления восстановить
> репозитории в новом формате с помощью svnadmin load.  С форматом fsfs
> подобных граблей нет.

  После восстановления функциональности svnadmin (перестановкой
libaprutil, см. другие письма треда) восстановил репозитарии следующим
образом (см. <http://subversion.tigris.org/faq.html#bdb43-upgrade>):

1. svnadmin list-unused-dblogs ...

2. svnadmin recover ...

3. проверка прав на <репозитарий>/db/*

  После этого -- репозитарии работают. Покрасней мере -- доступ на
чтение через http, svnadmin dump (запись -- не проверял)

PS: Проблема с https доступом ещё не решена. Но там явно надо apache2
трясти... (Что именно -- пока не понял.)

-- 

С уважением. Алексей.

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[Aleksey Avdeev]

Aleksey Avdeev пишет:
> Sergey Vlasov пишет:
> 
>>On Sat, Jan 21, 2006 at 11:24:33PM +0300, Aleksey Avdeev wrote:
>>
>>
>>> Перевожу сервер с M2.4 на С3.0. В процессе перевода возникли проблемы
>>>с subversion (репозитарии недоступны).
>>
>>
>>В любом случае при использовании формата bdb нужно сначала сделать
>>_старой_ версией svnadmin dump, потом после обновления восстановить
>>репозитории в новом формате с помощью svnadmin load.  С форматом fsfs
>>подобных граблей нет.
> 
> 
>   После восстановления функциональности svnadmin (перестановкой
> libaprutil, см. другие письма треда) восстановил репозитарии следующим
> образом (см. <http://subversion.tigris.org/faq.html#bdb43-upgrade>):

  В предыдущем письме -- слегка ошибся,

0. svnadmin recover ...

> 
> 1. svnadmin list-unused-dblogs ...
> 
> 2. svnadmin recover ...
> 
> 3. проверка прав на <репозитарий>/db/*
> 
>   После этого -- репозитарии работают. Покрасней мере -- доступ на
> чтение через http, svnadmin dump (запись -- не проверял)
> 
> PS: Проблема с https доступом ещё не решена. Но там явно надо apache2
> трясти... (Что именно -- пока не понял.)
> 


-- 

С уважением. Алексей.

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[Sviataslau Svirydau]

Aleksey Avdeev wrote:
> Здравствуйте.
>
>   Перевожу сервер с M2.4 на С3.0. В процессе перевода возникли проблемы
> с subversion (репозитарии недоступны). Оказалось, что даже svnadmin
> работает криво:
>
> $ svnadmin help
> svnadmin: Bad database version: got 4.2.52, should be at least 4.3.28
>   
В M2.4 subversion (вернее, используемый им libaprutil) собирается с 
libdb4.2, в C3 - с libdb4.3.
Рекомендуется сделать дамп репозитория до обновления (пока в системе 
libdb4.2), а после обновления воссоздать репозитории из дампа (можно 
даже переключиться на использование fsfs вместо bdb :) )
> (В error_log -- dav ругается на тоже самое.)
>
> Установлено:
>
> $ rpm -qa|fgrep subversion
> subversion-python-1.2.3-alt2
> subversion-1.2.3-alt2
> subversion-server-common-1.2.3-alt2
> subversion-server-dav-1.2.3-alt2
> subversion-doc-1.2.3-alt2
> libsubversion-1.2.3-alt2
> subversion-tools-1.2.3-alt2
>
> $ rpm -qa|fgrep db4
> libdb4.3_cxx-4.3.28-alt1
> libdb4.3-devel-4.3.28-alt1
> libdb4.3_java-4.3.28-alt1
> libdb4.3-4.3.28-alt1
> libdb4.2-4.2.52-alt4.1
> ^^^^^^^^^^^^^^^^^^^^^^
> db4.3-utils-4.3.28-alt1
>
>   Смущает выделенное. При попытки снести, получаю:
>
> ]$ sudo -H apt-get remove libdb4.2
> Чтение списков пакетов... Завершено
> Построение дерева зависимостей... Завершено
> Следующие пакеты будут УДАЛЕНЫ:
>   apache2 apache2-manual apache2-mod_ssl apache2-mod_webauth
> apache2-mod_webauthldap
>   apache2-mod_webauthldap-tests apache2-suexec libaprutil libdb4.2
> libsubversion subversion subversion-python
>   subversion-server-common subversion-server-dav subversion-tools webauth
>
>   Как разрулить ситуацию? (Желательно без пересборки. :-))
>   
libaprutil у Вас остался из  M2.4 все еще? Если так - надо его обновить. 
Если уже новый - тогда что еще хочет libdb4.2?
rpmquery --whatrequires libdb-4.2.so?

> PS: Багу вешать?
>   
Давайте разберемся в чем же дело, а то пока не понятно куда вешать-то :) 
...хотя если у Вас libaprutil еще старый, то причина понятна, но как 
можно разрулить возможность таких траблов пока не представляю.

-- 
Best regards,
Sviatoslav Sviridov
--
Remember: the biggest mistake to do is to overdesign. The road to hell is
paved with good intentions.

	- Linus on linux-kernel

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с subversion: Bad database version

[Aleksey Avdeev]

Sviataslau Svirydau пишет:
>
> libaprutil у Вас остался из  M2.4 все еще? Если так - надо его обновить.

  Да, остался старый (из Backports). Обновлять пришлось через
снёс-поставил (утащило за собой subversion и apache2).

  После установки новой версии (и повторной установки subversion и
apache2) консольные утилиты заработали, но поплохело apache2:

$ sudo -H service httpd2 start
Starting httpd2 service: Syntax error on line 282 of
/etc/httpd2/conf/httpd2.conf:
Cannot load /usr/lib/apache2/modules/mod_cgi.so into server:
/usr/lib/apache2/modules/mod_cgi.so: undefined symbol:
apr_procattr_addrspace_set

  Если этот /usr/lib/apache2/modules/mod_cgi.so закоментировать (в
/etc/httpd2/conf/httpd2.conf) -- httpd2 долго делает вид что стартует
(процесс initlog отрабатывает около 5 минут) но не работает. (В логах --
криминала не видно.)

> Если уже новый - тогда что еще хочет libdb4.2?
> rpmquery --whatrequires libdb-4.2.so?
> 
>> PS: Багу вешать?
>>   
> 
> Давайте разберемся в чем же дело, а то пока не понятно куда вешать-то :)
> ...хотя если у Вас libaprutil еще старый, то причина понятна, но как
> можно разрулить возможность таких траблов пока не представляю.
> 


-- 

С уважением. Алексей.

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с mod_ssl: пропал /dev/random

[Aleksey Avdeev]

Aleksey Avdeev пишет:
> Sviataslau Svirydau пишет:
> 
>>libaprutil у Вас остался из  M2.4 все еще? Если так - надо его обновить.
> 
> 
>   Да, остался старый (из Backports). Обновлять пришлось через
> снёс-поставил (утащило за собой subversion и apache2).
> 
>   После установки новой версии (и повторной установки subversion и
> apache2) консольные утилиты заработали, но поплохело apache2:
> 
> $ sudo -H service httpd2 start
> Starting httpd2 service: Syntax error on line 282 of
> /etc/httpd2/conf/httpd2.conf:
> Cannot load /usr/lib/apache2/modules/mod_cgi.so into server:
> /usr/lib/apache2/modules/mod_cgi.so: undefined symbol:
> apr_procattr_addrspace_set
> 
>   Если этот /usr/lib/apache2/modules/mod_cgi.so закоментировать (в
> /etc/httpd2/conf/httpd2.conf) -- httpd2 долго делает вид что стартует
> (процесс initlog отрабатывает около 5 минут) но не работает. (В логах --
> криминала не видно.)

  Со стартом httpd2 разобрался: У меня /dev/random пропал, оказывается,
а mod_ssl -- был настроен на его использование. (И куда делся
/dev/random -- непонятно абсолютно.) :-(

  В данный момент не работает:

SSLRandomSeed startup file:/dev/random  512
SSLRandomSeed connect file:/dev/random 512

  Но работают:

SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

  или

SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect file:/dev/urandom 512

-- 

С уважением. Алексей.

[sisyphus] Re: QU: M2.4 -> С3.0 проблемы с mod_ssl: пропал /dev/random

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

Hi Aleksey!

Tuesday 24, at 08:28:53 PM you wrote:

<skip>
>   Со стартом httpd2 разобрался: У меня /dev/random пропал, оказывается,
> а mod_ssl -- был настроен на его использование. (И куда делся
> /dev/random -- непонятно абсолютно.) :-(
у вас просто энтропия не набралась. поставьте rngd :)

-- 
WBR, Konstantin	      chat with ==>ICQ: 109916175
     Lepikhov,	      speak  to ==>JID: lakostis@jabber.org
aka L.A. Kostis       write  to ==>mailto:lakostis@pisem.net.nospam

...The information is like the bank... 			  (c) EC8OR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: QU: M2.4 -> С3.0 проблемы с mod_ssl: пропал /dev/random

[Aleksey Avdeev]

Konstantin A. Lepikhov пишет:
> Hi Aleksey!
> 
> Tuesday 24, at 08:28:53 PM you wrote:
> 
> <skip>
> 
>>  Со стартом httpd2 разобрался: У меня /dev/random пропал, оказывается,
>>а mod_ssl -- был настроен на его использование. (И куда делся
>>/dev/random -- непонятно абсолютно.) :-(
> 
> у вас просто энтропия не набралась. поставьте rngd :)

  Нда... А ларчик просто открывался. :-)

  Где взять rngd (apt-cache search rngd -- молчит как партизан)? А то
энтропия у меня более полутро суток набиралась... :-(

-- 

С уважением. Алексей.

Re: [sisyphus] Re: QU: M2.4 -> С3.0 проблемы с mod_ssl: пропал /dev/random

[Dmitry Lebkov]

Aleksey Avdeev wrote:
> Konstantin A. Lepikhov пишет:
> 
>>Hi Aleksey!
>>
>>Tuesday 24, at 08:28:53 PM you wrote:
>>
>><skip>
>>
>>> Со стартом httpd2 разобрался: У меня /dev/random пропал, оказывается,
>>>а mod_ssl -- был настроен на его использование. (И куда делся
>>>/dev/random -- непонятно абсолютно.) :-(
>>
>>у вас просто энтропия не набралась. поставьте rngd :)
> 
> 
>   Нда... А ларчик просто открывался. :-)
> 
>   Где взять rngd (apt-cache search rngd -- молчит как партизан)? А то
> энтропия у меня более полутро суток набиралась... :-(

А /dev/urandom вместо /dev/random - не оно?

-- 
WBR, Dmitry Lebkov

Re: [sisyphus] Re: QU: M2.4 -> С3.0 проблемы с mod_ssl: пропал /dev/random

[Aleksey Avdeev]

Dmitry Lebkov пишет:
> Aleksey Avdeev wrote:
> 
>> Konstantin A. Lepikhov пишет:
>>
>>> Hi Aleksey!
>>>
>>> Tuesday 24, at 08:28:53 PM you wrote:
>>>
>>> <skip>
>>>
>>>> Со стартом httpd2 разобрался: У меня /dev/random пропал, оказывается,
>>>> а mod_ssl -- был настроен на его использование. (И куда делся
>>>> /dev/random -- непонятно абсолютно.) :-(
>>>
>>>
>>> у вас просто энтропия не набралась. поставьте rngd :)
>>
>>
>>
>>   Нда... А ларчик просто открывался. :-)
>>
>>   Где взять rngd (apt-cache search rngd -- молчит как партизан)? А то
>> энтропия у меня более полутро суток набиралась... :-(
> 
> 
> А /dev/urandom вместо /dev/random - не оно?
> 

  Менее строгое. Не знаю правда, на сколько это для ssl существенно.

  В принципе, о таком поведении /dev/random (возможности длительного
отсутствии при перезагрузке) надо знать заранее. И быть к нему
готовым... Я же -- не знал. Отсюда и проблемы. :-/

-- 

С уважением. Алексей.

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с mod_ssl: пропал /dev/random

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

* Aleksey Avdeev <solo@> [060124 20:35]:
>   Со стартом httpd2 разобрался: У меня /dev/random пропал, оказывается,
> а mod_ssl -- был настроен на его использование. (И куда делся
> /dev/random -- непонятно абсолютно.) :-(
https://bugzilla.altlinux.org/show_bug.cgi?id=6903 - не оно?

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с mod_ssl: пропал /dev/random

[Aleksey Avdeev]

Alexey I. Froloff пишет:
> * Aleksey Avdeev <solo@> [060124 20:35]:
> 
>>  Со стартом httpd2 разобрался: У меня /dev/random пропал, оказывается,
>>а mod_ssl -- был настроен на его использование. (И куда делся
>>/dev/random -- непонятно абсолютно.) :-(
> 
> https://bugzilla.altlinux.org/show_bug.cgi?id=6903 - не оно?

  Оно самое. Спасибо, буду знать.

-- 

С уважением. Алексей.

Re: [sisyphus] QU: M2.4 -> С3.0 проблемы с mod_ssl: пропал /dev/random

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

On Wednesday 25 January 2006 11:16, Alexey I. Froloff wrote:

[...]
> https://bugzilla.altlinux.org/show_bug.cgi?id=6903 - не оно?
в libgcrypt-1.2.2-alt1 я тоже так сделал, а то даже make test не 
проходил из-за timeout :-(

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [sisyphus] QU: M2.4 -> я3.0 ОПНАКЕЛШ Я mod_ssl: ОПНОЮК /dev/random

[Aleksey Avdeev]

Sergey V Turchin пишет:
> On Wednesday 25 January 2006 11:16, Alexey I. Froloff wrote:
> 
> [...]
> 
>>https://bugzilla.altlinux.org/show_bug.cgi?id=6903 - не оно?
> 
> в libgcrypt-1.2.2-alt1 я тоже так сделал, а то даже make test не 
> проходил из-за timeout :-(

  Вопрос в следующем: нормальное ли это поведение (столь длительный
набор энтропии)? Раньше же он был на порядок быстрее...

-- 

С уважением. Алексей.