[devel] Broken python21

[devel] Broken python21

[Alexander Bokovoy]

Greetings!

Из-за libgdbm.so.2 у нас сломан python21:

Preparing packages for installation...
setup-2.2.0-alt3
Preparing packages for installation...
glibc-core-2.2.6-alt0.6
Preparing packages for installation...
filesystem-2.1.6-alt9
Preparing packages for installation...
alt-gpgkeys-0.1-alt9
altlinux-release-Sisyphus-alt20021129
bzlib-1.0.2-alt6
bzip2-1.0.2-alt6
common-licenses-1.1-alt1
getopt-1.1.2-alt3
glib-1.2.10-alt6
gzip-1.3.3-alt3
info-install-4.3-alt1
libattr-2.0.5-alt0.1cvs
libacl-2.0.5-alt0.1cvs
libbeecrypt-2.2.0-alt2
libdb2-2.4.14-alt2
libdb4-4.0.14-alt8
libe2fs-1.32-alt1
e2fsprogs-1.32-alt1
libpam-0.75-alt17
libpcre-3.9-alt3
libpopt-1.7-alt5
chkconfig-1.2.24-alt3
libreadline-4.3-alt2
libshhopt-1.1.7-alt1
hwclock-2.17-alt1
libtcb-0.9.8.1-alt1
losetup-2.11w-alt2
mktemp-1.4-alt2
net-tools-1.60-alt4
nss_tcb-0.9.8.1-alt1
pam-0.75-alt17
pam_passwdqc-0.7.1-alt1
pam_userpass-0.5.1-alt1
rootfiles-alt-alt8
sh-2.05b-alt3
SysVinit-2.84-alt4
diffutils-2.8.1-alt3
findutils-4.1.7-alt6
gawk-3.1.1-alt4
genromfs-0.5.1-alt3
grep-2.5.1-alt0.2.cvs
logrotate-3.6.2-alt2
pam_tcb-0.9.8.1-alt1
pam-config-1.1.2-alt1
perl-base-5.8.0-alt0.8.1
sed-3.02-alt2
shadow-convert-4.0.0-alt8
tar-1.13.25-alt2
tcb-utils-0.9.8.1-alt1
shadow-utils-4.0.0-alt8
etcskel-2.0.7-alt5
terminfo-5.3.20021012-alt1
libtinfo-5.3.20021012-alt1
bash-2.05b-alt3
coreutils-4.5.3-alt1
bootloader-utils-0.1-alt5
control-0.4-alt1
dev-3.3.1-alt1
libgpm-1.20.1-alt0.6rc1
libncurses-5.3.20021012-alt1
mount-2.11w-alt2
procps-2.0.10-alt2
psmisc-21.2-alt1
vim-minimal-6.1.178-alt12
which-2.14-alt2
zlib-1.1.4-alt2
librpm-4.0.4-alt11
modutils-2.4.21-alt1
mkinitrd-2.8.4-alt2
rpm-4.0.4-alt11
warning: /etc/rpm/macros.db1 created as /etc/rpm/macros.db1.rpmnew
util-linux-2.11w-alt2
initscripts-5.49-ipl45mdk
kernel24-up-2.4.19-alt0.8
couldn't create custom box: python21 due libgdbm.so.2


-- 
/ Alexander Bokovoy
---
Adding features does not necessarily increase functionality -- it just
makes the manuals thicker.

Re: [devel] Broken python21

[aen]

Alexander Bokovoy wrote:

>Greetings!
>
>Из-за libgdbm.so.2 у нас сломан python21:
>  
>
А он нам нужен?

Rgrds, Алексей

Re: [devel] Broken python21

[Dmitry V. Levin]

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

On Mon, Dec 09, 2002 at 07:47:08PM +0200, Alexander Bokovoy wrote:
> Из-за libgdbm.so.2 у нас сломан python21:

1. Он был вчера пересобран.
2. Зачем вы его используете? Скорее всего, тем самым вы совершаете ошибку,
  ибо в файле /etc/apt/pkgpriorities явно указано, что по умолчанию
  следует использовать python22.


--
ldv

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

Re: [devel] Broken python21

[Alexander Bokovoy]

On Mon, Dec 09, 2002 at 09:12:06PM +0300, Dmitry V. Levin wrote:
> On Mon, Dec 09, 2002 at 07:47:08PM +0200, Alexander Bokovoy wrote:
> > Из-за libgdbm.so.2 у нас сломан python21:
> 
> 1. Он был вчера пересобран.
Я не вижу этого на www.altlinux.ru.

> 2. Зачем вы его используете? Скорее всего, тем самым вы совершаете ошибку,
>   ибо в файле /etc/apt/pkgpriorities явно указано, что по умолчанию
>   следует использовать python22.
Я уже пересобрал ethereal с python22, но тем не менее вопрос остается
открытым: почему пытается поставиться python21 при указании в 
BuildRequires: python и при том, что в саму систему _уже_ поставился python22?

Вот протокол сборки:

Building ethereal ...
Preparing packages for installation...
setup-2.2.0-alt3
Preparing packages for installation...
glibc-core-2.2.6-alt0.6
Preparing packages for installation...
filesystem-2.1.6-alt9
Preparing packages for installation...
alt-gpgkeys-0.1-alt9
altlinux-release-Sisyphus-alt20021129
bzlib-1.0.2-alt6
bzip2-1.0.2-alt6
common-licenses-1.1-alt1
getopt-1.1.2-alt3
glib-1.2.10-alt6
gzip-1.3.3-alt3
info-install-4.3-alt1
libattr-2.0.5-alt0.1cvs
libacl-2.0.5-alt0.1cvs
libbeecrypt-2.2.0-alt2
libdb2-2.4.14-alt2
libdb4-4.0.14-alt8
libe2fs-1.32-alt1
e2fsprogs-1.32-alt1
libpam-0.75-alt17
libpcre-3.9-alt3
libpopt-1.7-alt5
chkconfig-1.2.24-alt3
libreadline-4.3-alt2
libshhopt-1.1.7-alt1
hwclock-2.17-alt1
libtcb-0.9.8.1-alt1
losetup-2.11w-alt2
mktemp-1.4-alt2
net-tools-1.60-alt4
nss_tcb-0.9.8.1-alt1
pam-0.75-alt17
pam_passwdqc-0.7.1-alt1
pam_userpass-0.5.1-alt1
rootfiles-alt-alt8
sh-2.05b-alt3
SysVinit-2.84-alt4
diffutils-2.8.1-alt3
findutils-4.1.7-alt6
gawk-3.1.1-alt4
genromfs-0.5.1-alt3
grep-2.5.1-alt0.2.cvs
logrotate-3.6.2-alt2
pam_tcb-0.9.8.1-alt1
pam-config-1.1.2-alt1
perl-base-5.8.0-alt0.8.1
sed-3.02-alt2
shadow-convert-4.0.0-alt8
tar-1.13.25-alt2
tcb-utils-0.9.8.1-alt1
shadow-utils-4.0.0-alt8
etcskel-2.0.7-alt5
terminfo-5.3.20021012-alt1
libtinfo-5.3.20021012-alt1
bash-2.05b-alt3
coreutils-4.5.3-alt1
bootloader-utils-0.1-alt5
control-0.4-alt1
dev-3.3.1-alt1
libgpm-1.20.1-alt0.6rc1
libncurses-5.3.20021012-alt1
mount-2.11w-alt2
procps-2.0.10-alt2
psmisc-21.2-alt1
vim-minimal-6.1.178-alt12
which-2.14-alt2
zlib-1.1.4-alt2
librpm-4.0.4-alt11
modutils-2.4.21-alt1
mkinitrd-2.8.4-alt2
rpm-4.0.4-alt11
warning: /etc/rpm/macros.db1 created as /etc/rpm/macros.db1.rpmnew
util-linux-2.11w-alt2
initscripts-5.49-ipl45mdk
kernel24-up-2.4.19-alt0.8
Can't locate MDK/Common.pm in @INC (@INC contains: /usr/lib/perl5/i386-linux /usr/lib/perl5 /usr/local/lib/perl5/site_perl/5.8.0/i386-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/i386-linux /usr/lib/perl5/vendor_perl /usr/lib/perl5/vendor_perl .) at /usr/sbin/detectloader line 12.
BEGIN failed--compilation aborted at /usr/sbin/detectloader line 12.
Cannot find a boot loader, you may have to see why detectloader has
problems or specify via the command line.
Preparing packages for installation...
autoconf-common-0.1-alt1
automake-common-0.1-alt1
bison-1.35-alt2
cpio-2.5-alt2
ed-0.2-alt2
file-3.39-alt2
gcc-common-1.2.1-alt2
cpp3.2-3.2.1-alt2
glibc-gconv-modules-2.2.6-alt0.6
glibc-locales-2.2.6-alt0.6
glibc-nss-2.2.6-alt0.6
glibc-timezones-2.2.6-alt0.6
glibc-utils-2.2.6-alt0.6
iconv-2.2.6-alt0.6
glibc-2.2.6-alt0.6
kernel-headers-common-1.0-alt2
kernel24-openmosix-headers-2.4.19-alt1
glibc-devel-2.2.6-alt0.6
libbfd-2.13.90.0.4-alt2
binutils-2.13.90.0.4-alt2
libexpat-1.95.5-alt1
libgcc3.2-3.2.1-alt2
libgdbm-1.8.3-alt1
libgmp-4.1-alt1
libintl2-0.11.5-alt9
gettext-0.11.5-alt9
libltdl-1.4.2-alt0.2
libssl-0.9.6g-alt3
libstdc++3.2-3.2.1-alt2
libtool-1.4.2-alt0.2
m4-1.4.1-alt2
autoconf_2.5-2.56-alt1
make-3.79.1-ipl6mdk
gcc3.2-3.2.1-alt2
patch-2.5.4-ipl10mdk
python22-2.2.2-alt1
gettext-tools-0.11.5-alt9
su-0.60-alt14
texinfo-4.3-alt1
automake_1.7-1.7.1-alt1
rpm-build-4.0.4-alt11
rpm-build-topdir-4.0.4-alt11
can't prepare `ethereal': couldn't install required package: python21 due libgdbm.so.2

-- 
/ Alexander Bokovoy
---
I'd just as soon kiss a Wookie.
		-- Princess Leia Organa

Re: [devel] Broken python21

[Aleksandr Blokhin]

On Mon, 9 Dec 2002 21:04:55 +0200
Alexander Bokovoy <a.bokovoy@sam-solutions.net> wrote:

>> 
>> А чем ставите?
AB> APT 0.3, естественно (из-под BTE). Из-за последних провайдерских
AB> "радостей" смена APT
AB> еще не доползла. Да и ее стоило бы проанонсировать погромче (не
AB> только на
AB> apt@packages), с соответствующими комментариями относительно
AB> перемещения
AB> важных файлов конфигурации (чего не было и на apt@packages).
AB> Changelog-и 
AB> в пакетах заменой анонсу не являются.

Кста!
По поводу последнего APT-0.5.
После его установки, при генерации хешей, passphrase приходится 
вводить дважды. В предыдущих версиях такого не наблюдалось. 
Это так и было задумано?

--
Best regards
AB
--
				... In nomine Altli, et Ctrli, et Spititus Deli, Reset!

Re: [devel] Broken python21

[Dmitry V. Levin]

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

On Mon, Dec 09, 2002 at 08:23:27PM +0200, Alexander Bokovoy wrote:
> > > Из-за libgdbm.so.2 у нас сломан python21:
> > 
> > 1. Он был вчера пересобран.
> Я не вижу этого на www.altlinux.ru.

Наверное, его ещё там нет.

> > 2. Зачем вы его используете? Скорее всего, тем самым вы совершаете ошибку,
> >   ибо в файле /etc/apt/pkgpriorities явно указано, что по умолчанию
> >   следует использовать python22.
> Я уже пересобрал ethereal с python22, но тем не менее вопрос остается
> открытым: почему пытается поставиться python21 при указании в 
> BuildRequires: python и при том, что в саму систему _уже_ поставился python22?

А чем ставите?

Между прочим, в contrib'е есть ещё несколько пакетов, которые не
рекомендуется использовать для сборки других пакетов.


--
ldv

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

Re: [devel] Broken python21

[Alexander Bokovoy]

On Mon, Dec 09, 2002 at 09:53:58PM +0300, Dmitry V. Levin wrote:
> > Я уже пересобрал ethereal с python22, но тем не менее вопрос остается
> > открытым: почему пытается поставиться python21 при указании в 
> > BuildRequires: python и при том, что в саму систему _уже_ поставился python22?
> 
> А чем ставите?
APT 0.3, естественно (из-под BTE). Из-за последних провайдерских "радостей" смена APT
еще не доползла. Да и ее стоило бы проанонсировать погромче (не только на
apt@packages), с соответствующими комментариями относительно перемещения
важных файлов конфигурации (чего не было и на apt@packages). Changelog-и 
в пакетах заменой анонсу не являются.

> Между прочим, в contrib'е есть ещё несколько пакетов, которые не
> рекомендуется использовать для сборки других пакетов.
У меня нет "contrib". У меня есть classic. Какой смысл проверять
замкнутость и работоспособность Sisyphus на его подмножестве.

P.S. Дима, с кардинальными сменами надо поаккуратнее.

-- 
/ Alexander Bokovoy
---
Armstrong's Collection Law:
	If the check is truly in the mail,
	it is surely made out to someone else.

Re: [devel] Broken python21

[Dmitry V. Levin]

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

On Mon, Dec 09, 2002 at 09:04:55PM +0200, Alexander Bokovoy wrote:
> > > Я уже пересобрал ethereal с python22, но тем не менее вопрос остается
> > > открытым: почему пытается поставиться python21 при указании в 
> > > BuildRequires: python и при том, что в саму систему _уже_ поставился python22?
> > 
> > А чем ставите?
> APT 0.3, естественно (из-под BTE). Из-за последних провайдерских "радостей" смена APT
> еще не доползла. Да и ее стоило бы проанонсировать погромче (не только на

Не вижу смысла, мы ведь не отдел маркетинга.

> apt@packages), с соответствующими комментариями относительно перемещения
> важных файлов конфигурации (чего не было и на apt@packages). Changelog-и 
> в пакетах заменой анонсу не являются.

Не вижу смысла анонсировать это.

> > Между прочим, в contrib'е есть ещё несколько пакетов, которые не
> > рекомендуется использовать для сборки других пакетов.
> У меня нет "contrib". У меня есть classic. Какой смысл проверять
> замкнутость и работоспособность Sisyphus на его подмножестве.

Прямой: contrib не войдет в Master.

> P.S. Дима, с кардинальными сменами надо поаккуратнее.

Сейчас еще одно будет...


--
ldv

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

Re: [devel] Broken python21

[aen]

Hi!
Dmitry V. Levin wrote:

>On Mon, Dec 09, 2002 at 09:04:55PM +0200, Alexander Bokovoy wrote:
>  
>
>>>>Я уже пересобрал ethereal с python22, но тем не менее вопрос остается
>>>>открытым: почему пытается поставиться python21 при указании в 
>>>>BuildRequires: python и при том, что в саму систему _уже_ поставился python22?
>>>>        
>>>>
>>>А чем ставите?
>>>      
>>>
>>APT 0.3, естественно (из-под BTE). Из-за последних провайдерских "радостей" смена APT
>>еще не доползла. Да и ее стоило бы проанонсировать погромче (не только на
>>    
>>
>
>Не вижу смысла, мы ведь не отдел маркетинга.
>
Дима, отдел маркетинга будет анонсирвоать дял публики, в devel нет
маркетинга.

>
>  
>
>>apt@packages), с соответствующими комментариями относительно перемещения
>>важных файлов конфигурации (чего не было и на apt@packages). Changelog-и 
>>в пакетах заменой анонсу не являются.
>>    
>>
>
>Не вижу смысла анонсировать это.
>
>  
>
>>>Между прочим, в contrib'е есть ещё несколько пакетов, которые не
>>>рекомендуется использовать для сборки других пакетов.
>>>      
>>>
>>У меня нет "contrib". У меня есть classic. Какой смысл проверять
>>замкнутость и работоспособность Sisyphus на его подмножестве.
>>    
>>
>
>Прямой: contrib не войдет в Master.
>
Да, об этом говорилось.

>
>  
>
>>P.S. Дима, с кардинальными сменами надо поаккуратнее.
>>    
>>
>
>Сейчас еще одно будет...
>
Проанонсируйте, пожалуйста.

Rgrds, Алексей

>
>
>--
>ldv
>  
>

Re: [devel] Broken python21

[Dmitry V. Levin]

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

On Mon, Dec 09, 2002 at 08:49:55PM +0200, Aleksandr Blokhin wrote:
> >> А чем ставите?
> AB> APT 0.3, естественно (из-под BTE). Из-за последних провайдерских
> AB> "радостей" смена APT
> AB> еще не доползла. Да и ее стоило бы проанонсировать погромче (не
> AB> только на
> AB> apt@packages), с соответствующими комментариями относительно
> AB> перемещения
> AB> важных файлов конфигурации (чего не было и на apt@packages).
> AB> Changelog-и 
> AB> в пакетах заменой анонсу не являются.
> 
> Кста!
> По поводу последнего APT-0.5.
> После его установки, при генерации хешей, passphrase приходится 
> вводить дважды. В предыдущих версиях такого не наблюдалось. 
> Это так и было задумано?

Теперь по умолчанию хеши создаются и в новом формате (для apt0.5), и в
старом (apt0.3). Разумеется, старые можно отключить (--no-oldhashfile).


--
ldv

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

Re: [devel] Broken python21

[Dmitry V. Levin]

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

On Mon, Dec 09, 2002 at 09:04:55PM +0200, Alexander Bokovoy wrote:
> > > Я уже пересобрал ethereal с python22, но тем не менее вопрос остается
> > > открытым: почему пытается поставиться python21 при указании в 
> > > BuildRequires: python и при том, что в саму систему _уже_ поставился python22?
> > 
> > А чем ставите?
> APT 0.3, естественно (из-под BTE). Из-за последних провайдерских "радостей" смена APT

К сожалению, apt0.3 толком не удаётся научить приоритетам выбора пакетов.
Для apt0.5 как минимум /etc/apt/pkgpriorities работает предсказуемым
образом (спасибо mouse).


--
ldv

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

Re: [devel] Broken python21

[Alexander Bokovoy]

On Mon, Dec 09, 2002 at 11:08:29PM +0300, Dmitry V. Levin wrote:
> On Mon, Dec 09, 2002 at 09:04:55PM +0200, Alexander Bokovoy wrote:
> > > > Я уже пересобрал ethereal с python22, но тем не менее вопрос остается
> > > > открытым: почему пытается поставиться python21 при указании в 
> > > > BuildRequires: python и при том, что в саму систему _уже_ поставился python22?
> > > 
> > > А чем ставите?
> > APT 0.3, естественно (из-под BTE). Из-за последних провайдерских "радостей" смена APT
> К сожалению, apt0.3 толком не удаётся научить приоритетам выбора пакетов.
> Для apt0.5 как минимум /etc/apt/pkgpriorities работает предсказуемым
> образом (спасибо mouse).
Вроде бы ibiblio.org пока оказался отзывчивым в плане rsync и думаю, что
за пару дней BTE сможет перебраться на 0.5 (с учетом необходимости
перевода на 0.5 и всех остальных использующих BTE проектов).

-- 
/ Alexander Bokovoy
---
You will have a long and unpleasant discussion with your supervisor.

Re: [devel] Broken python21

[AntonFarygin]

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

Alexander Bokovoy пишет:

>On Mon, Dec 09, 2002 at 09:53:58PM +0300, Dmitry V. Levin wrote:
>  
>
>>>Я уже пересобрал ethereal с python22, но тем не менее вопрос остается
>>>открытым: почему пытается поставиться python21 при указании в 
>>>BuildRequires: python и при том, что в саму систему _уже_ поставился python22?
>>>      
>>>
>>А чем ставите?
>>    
>>
>APT 0.3, естественно (из-под BTE). Из-за последних провайдерских "радостей" смена APT
>еще не доползла. Да и ее стоило бы проанонсировать погромче (не только на
>apt@packages), с соответствующими комментариями относительно перемещения
>важных файлов конфигурации (чего не было и на apt@packages). Changelog-и 
>в пакетах заменой анонсу не являются.
>
Тогда у вас есть вероятность в BTE собирать не тем компилятором?

Собственно apt-0.5 mouse начал патчить именно после того, когда bte 
(написанная на ruby) начала компилировать по умолчанию gcc 2.95 и 
использовать старый autoconf. Сейчас apt-0.5 вполне корректно 
справляется с выбором лучшего python и всего остального.

Кстати, apt-0.5 был в Sisyphus за несколько дней до того самого с 
провайдерами. Да и rsync никто не закрывал. Сервера работаю, трафик 
бегает (меньше конечно, но все же)

>
>  
>
>>Между прочим, в contrib'е есть ещё несколько пакетов, которые не
>>рекомендуется использовать для сборки других пакетов.
>>    
>>
>У меня нет "contrib". У меня есть classic. Какой смысл проверять
>замкнутость и работоспособность Sisyphus на его подмножестве.
>
Classic - это свалка всех подмножеств. В Contrib могут (а могут ли?) 
попасть пакеты, которые провайдят не то, что надо.

Потому для сборки и лучше использовать Master.

Rgds,
Rider


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

Re: [devel] Broken python21

[Aleksandr Blokhin]

On Mon, 9 Dec 2002 23:02:33 +0300
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

DVL> On Mon, Dec 09, 2002 at 08:49:55PM +0200, Aleksandr Blokhin wrote:
>> >> А чем ставите?
>> AB> APT 0.3, естественно (из-под BTE). Из-за последних провайдерских
>> AB> "радостей" смена APT
>> AB> еще не доползла. Да и ее стоило бы проанонсировать погромче (не
>> AB> только на
>> AB> apt@packages), с соответствующими комментариями относительно
>> AB> перемещения
>> AB> важных файлов конфигурации (чего не было и на apt@packages).
>> AB> Changelog-и 
>> AB> в пакетах заменой анонсу не являются.
>> 
>> Кста!
>> По поводу последнего APT-0.5.
>> После его установки, при генерации хешей, passphrase приходится 
>> вводить дважды. В предыдущих версиях такого не наблюдалось. 
>> Это так и было задумано?

DVL> Теперь по умолчанию хеши создаются и в новом формате (для apt0.5),
DVL> и в
DVL> старом (apt0.3). Разумеется, старые можно отключить
DVL> (--no-oldhashfile).

Спасибо!

--
Best regards
AB
--
				... In nomine Altli, et Ctrli, et Spititus Deli, Reset!

Re: [devel] Broken python21

[Alexander Bokovoy]

On Mon, Dec 09, 2002 at 11:11:57PM +0300, AntonFarygin wrote:
> >apt@packages), с соответствующими комментариями относительно перемещения
> >важных файлов конфигурации (чего не было и на apt@packages). Changelog-и 
> >в пакетах заменой анонсу не являются.
> >
> Тогда у вас есть вероятность в BTE собирать не тем компилятором?
Нет. У нас ее нет, ибо мы используем ccache с правильными настройками.

> Собственно apt-0.5 mouse начал патчить именно после того, когда bte 
> (написанная на ruby) начала компилировать по умолчанию gcc 2.95 и 
> использовать старый autoconf. Сейчас apt-0.5 вполне корректно 
> справляется с выбором лучшего python и всего остального.
> 
> Кстати, apt-0.5 был в Sisyphus за несколько дней до того самого с 
> провайдерами. Да и rsync никто не закрывал. Сервера работаю, трафик 
> бегает (меньше конечно, но все же)
rsync.altlinux.ru за последние дня 4 испытывал изменения почти только в SRPMS, а
все бинарные пакеты не менялись. Например, у меня сейчас в локальном
репозитарии от сегодняшнего утра наблюдается целый gnome-panel-2.1.2-alt1 и
битый симлинк gnome-panel-2.1.3-alt1. Зеркалирование еще утром делалось с
rsync.altlinux.ru. И это не одно такое явление.

> >>Между прочим, в contrib'е есть ещё несколько пакетов, которые не
> >>рекомендуется использовать для сборки других пакетов.
> >У меня нет "contrib". У меня есть classic. Какой смысл проверять
> >замкнутость и работоспособность Sisyphus на его подмножестве.
> >
> Classic - это свалка всех подмножеств. В Contrib могут (а могут ли?) 
> попасть пакеты, которые провайдят не то, что надо.
Нет, не могут. Если такие пакеты есть, то их место в unsupported.

 
> Потому для сборки и лучше использовать Master.
Антон, ты говоришь ерунду. Что это за отношение к Classic как к свалке?
Целостность Сизифа обеспечивается или должна обеспечиваться именно по
Classic, а не по подмножествам. Иное -- путь к развалу зависимостей, что
мы уже и наблюдаем (bootloader-utils, pysol, python21, ряд других) именно
из-за ослабления контроля путем самоутешения в подкомпонентах.

-- 
/ Alexander Bokovoy
---
Be careful when you bite into your hamburger.
		-- Derek Bok

Re: [devel] Broken python21

[AntonFarygin]

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

Alexander Bokovoy пишет:

>On Mon, Dec 09, 2002 at 11:11:57PM +0300, AntonFarygin wrote:
>  
>
>>>apt@packages), с соответствующими комментариями относительно перемещения
>>>важных файлов конфигурации (чего не было и на apt@packages). Changelog-и 
>>>в пакетах заменой анонсу не являются.
>>>
>>>      
>>>
>>Тогда у вас есть вероятность в BTE собирать не тем компилятором?
>>    
>>
>Нет. У нас ее нет, ибо мы используем ccache с правильными настройками.
>
А ccache разваливается в BTE? Или как?

>
>  
>
>>Собственно apt-0.5 mouse начал патчить именно после того, когда bte 
>>(написанная на ruby) начала компилировать по умолчанию gcc 2.95 и 
>>использовать старый autoconf. Сейчас apt-0.5 вполне корректно 
>>справляется с выбором лучшего python и всего остального.
>>
>>Кстати, apt-0.5 был в Sisyphus за несколько дней до того самого с 
>>провайдерами. Да и rsync никто не закрывал. Сервера работаю, трафик 
>>бегает (меньше конечно, но все же)
>>    
>>
>rsync.altlinux.ru за последние дня 4 испытывал изменения почти только в SRPMS, а
>все бинарные пакеты не менялись. Например, у меня сейчас в локальном
>репозитарии от сегодняшнего утра наблюдается целый gnome-panel-2.1.2-alt1 и
>битый симлинк gnome-panel-2.1.3-alt1. Зеркалирование еще утром делалось с
>rsync.altlinux.ru. И это не одно такое явление.
>
Очень странно.  gnome-panel 2.1.3 лежит в Sisyphus со второго декабря (в 
нормальном, а не битом виде). Все нормально и на моей машине, которую я 
вчера зеркалировал с Sisyphus с rsync.altlinux.ru. Никаких проблем не 
возникало с зеркалированием. Да и rsync.altlinux.ru менялся все время 
также нормально (я зеркалирую только бинарные пакеты).

>
>  
>
>>>>Между прочим, в contrib'е есть ещё несколько пакетов, которые не
>>>>рекомендуется использовать для сборки других пакетов.
>>>>        
>>>>
>>>У меня нет "contrib". У меня есть classic. Какой смысл проверять
>>>замкнутость и работоспособность Sisyphus на его подмножестве.
>>>
>>>      
>>>
>>Classic - это свалка всех подмножеств. В Contrib могут (а могут ли?) 
>>попасть пакеты, которые провайдят не то, что надо.
>>    
>>
>Нет, не могут. Если такие пакеты есть, то их место в unsupported.
>
наверное так и есть ;-)

>
> 
>  
>
>>Потому для сборки и лучше использовать Master.
>>    
>>
>Антон, ты говоришь ерунду. Что это за отношение к Classic как к свалке?
>Целостность Сизифа обеспечивается или должна обеспечиваться именно по
>Classic, а не по подмножествам. Иное -- путь к развалу зависимостей, что
>мы уже и наблюдаем (bootloader-utils, pysol, python21, ряд других) именно
>из-за ослабления контроля путем самоутешения в подкомпонентах.
>
Я бы сказал не так: целостоность Sisyphus должна обеспечиваться как в 
отдельных компонентах, так и в Classic.
То, что битые зависимости - несоменно ошибки, о которых также несомненно 
стоит сообщить в BTS.

Использовать Master для сборки лучше конечно по другой причине - если 
пакет падает в компоненту Master, то явно лучше собирать с 
использованием этой компоненты, что бы не нарушить ее целостность.


Rgds,
Rider


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

Re: [devel] Broken python21

[Andrey Orlov]

On 2002 December 09 Monday 21:06, you wrote:

[что-то там про python21]

> А он нам нужен?

Я, наверно, один из тех кому он должен был бы быть нужен (Zope & Co).
Дык вот: погашено много флеймов и опровергнуто много аргументов. На сегодняшний 
день:

--- Zope работает с python2.2.2 (мало того, наш пакет может и не поднятся с 213, а с 221 гавкнется точно), 
     поэтому в дистрибутиве python213 мне не нужен (в смысле в Мастере или что-там-мы-будем-писать
    -на-болванки);

--- Тем не менее я очень благодарен уже (и буду еще более благодарен в последствии) тем 
     людям, которые поддерживают python2.1.3 живым. Желательно чбы в сизифусе он все-таки
     пока остался, даже ценой пропадания части функциональности (например работоспособность
     gdbm меня совершенно не беспокоит, кажется его можно собрать (если нет другого варианта) без
     поддержки оной). Нужен для гашения флеймов (тестирования) - очень приятно бывает выяснить
     что ошибка проявлятся и под ним;

О флеймах и аргументах можно почитать у меня на сайте, но, IMHO не стоит.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- www.neural.ru, cray@neural.ru ---
----------------------------------------

Re: [devel] Broken python21

[Dmitry V. Levin]

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

On Mon, Dec 09, 2002 at 10:32:35PM +0200, Alexander Bokovoy wrote:
> > Кстати, apt-0.5 был в Sisyphus за несколько дней до того самого с 
> > провайдерами. Да и rsync никто не закрывал. Сервера работаю, трафик 
> > бегает (меньше конечно, но все же)
> rsync.altlinux.ru за последние дня 4 испытывал изменения почти только в SRPMS, а
> все бинарные пакеты не менялись. Например, у меня сейчас в локальном

Это не так.

> репозитарии от сегодняшнего утра наблюдается целый gnome-panel-2.1.2-alt1 и
> битый симлинк gnome-panel-2.1.3-alt1. Зеркалирование еще утром делалось с
> rsync.altlinux.ru. И это не одно такое явление.

Звучит неправдоподобно.
Пишите мне, подробнее, и личной почтой.

> > >>Между прочим, в contrib'е есть ещё несколько пакетов, которые не
> > >>рекомендуется использовать для сборки других пакетов.
> > >У меня нет "contrib". У меня есть classic. Какой смысл проверять
> > >замкнутость и работоспособность Sisyphus на его подмножестве.
> > >
> > Classic - это свалка всех подмножеств. В Contrib могут (а могут ли?) 
> > попасть пакеты, которые провайдят не то, что надо.
> Нет, не могут. Если такие пакеты есть, то их место в unsupported.

Нет.
unsupported - это вообще непонятно что такое.
contrib - это в точности то место, куда incominger может себе позволить
положить чей-то новый пакет без review; соответственно, за качество
отвечает только maintainer.

> > Потому для сборки и лучше использовать Master.
> Антон, ты говоришь ерунду. Что это за отношение к Classic как к свалке?
> Целостность Сизифа обеспечивается или должна обеспечиваться именно по
> Classic, а не по подмножествам. Иное -- путь к развалу зависимостей, что
> мы уже и наблюдаем (bootloader-utils, pysol, python21, ряд других) именно
> из-за ослабления контроля путем самоутешения в подкомпонентах.

Саша, ты говоришь не лучше Антона.

В идеале, замкнутость должна быть покомпонентная:
base
base+castle+kernel
base+junior+kernel
base+castle+junior+kernel+master
classic
- каждая группа должна быть замкнута по установке, а группы master и
  classic - ещё и по сборке.


--
ldv

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

Re: [devel] Broken python21

[Alexander Bokovoy]

On Mon, Dec 09, 2002 at 11:50:01PM +0300, AntonFarygin wrote:
> >>Тогда у вас есть вероятность в BTE собирать не тем компилятором?
> >Нет. У нас ее нет, ибо мы используем ccache с правильными настройками.
> А ccache разваливается в BTE? Или как?
Не разваливается. Я же написал: "у нас ее (проблемы) нет".

> >>
> >rsync.altlinux.ru за последние дня 4 испытывал изменения почти только в 
> >SRPMS, а
> >все бинарные пакеты не менялись. Например, у меня сейчас в локальном
> >репозитарии от сегодняшнего утра наблюдается целый gnome-panel-2.1.2-alt1 и
> >битый симлинк gnome-panel-2.1.3-alt1. Зеркалирование еще утром делалось с
> >rsync.altlinux.ru. И это не одно такое явление.
> Очень странно.  gnome-panel 2.1.3 лежит в Sisyphus со второго декабря (в 
> нормальном, а не битом виде). Все нормально и на моей машине, которую я 
> вчера зеркалировал с Sisyphus с rsync.altlinux.ru. Никаких проблем не 
> возникало с зеркалированием. Да и rsync.altlinux.ru менялся все время 
> также нормально (я зеркалирую только бинарные пакеты).
Мы специально вчера вечером провели ручную синхронизацию с
rsync.altlinux.ru и она оказалась стольже неуспешной по результатам --
обновлений бинарных пакетов не произошло. Я не знаю, кого здесь обвинять
-- rsync.altlinux.ru, или луну, светившую на трафик по дороге...

> >>Потому для сборки и лучше использовать Master.
> >Антон, ты говоришь ерунду. Что это за отношение к Classic как к свалке?
> >Целостность Сизифа обеспечивается или должна обеспечиваться именно по
> >Classic, а не по подмножествам. Иное -- путь к развалу зависимостей, что
> >мы уже и наблюдаем (bootloader-utils, pysol, python21, ряд других) именно
> >из-за ослабления контроля путем самоутешения в подкомпонентах.
> >
> Я бы сказал не так: целостоность Sisyphus должна обеспечиваться как в 
> отдельных компонентах, так и в Classic.
В отдельных компонентах нельзя добиться целостности, за исключением
basesystem. Можно добиться целостности в наборах компонент, поскольку
построены они по принципу матрешек. Так вот, для меня сломанность Contrib
означает сломанность Sisyphus, причем она не замечается apt-get unmet,
зато отлично видна в BTE при использовании механизма сборки или тестовой
установки пакетов. Проблемы с pysol (отсутствие зависимости на tkinterp)
вообще отлавливаются только при использовании -- попытке запуска. Я думаю,
что и эту ситуацию мы будем пытаться в будущем подчинять
автоматизированному тестированию (через использование UML).

> То, что битые зависимости - несоменно ошибки, о которых также несомненно 
> стоит сообщить в BTS.
Может стоит поставить PV -- там есть почтовый интерфейс к багам. А то с лазанием
по bugs.altlinux.ru я очень быстро выеду свой 45Мб лимит трафика в неделю 
на проксе :(

> Использовать Master для сборки лучше конечно по другой причине - если 
> пакет падает в компоненту Master, то явно лучше собирать с 
> использованием этой компоненты, что бы не нарушить ее целостность.
Я уже говорил, что это деление эфемерное, и приводил в сентябре примеры.
Собственно, благодаря этому и возникло понятие Classic. Деление на Contrib
и Master -- верный путь к ослаблению контроля качества сборки. Вспомните
Contrib в Mandrake.


-- 
/ Alexander Bokovoy
---
Beware of bugs in the above code; I have only proved it correct, not tried it.
		-- Donald Knuth

Re: [devel] Broken python21

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 12:03:35AM +0300, Dmitry V. Levin wrote:
> > репозитарии от сегодняшнего утра наблюдается целый gnome-panel-2.1.2-alt1 и
> > битый симлинк gnome-panel-2.1.3-alt1. Зеркалирование еще утром делалось с
> > rsync.altlinux.ru. И это не одно такое явление.
> 
> Звучит неправдоподобно.
> Пишите мне, подробнее, и личной почтой.
Дима, как я уже написал, вчера вечером, перед переключением на ibiblio, мы
провели ручную синхронизацию и она оказалась столь же неуспешной, как и
автоматические -- сам процесс rsync отработал без проблем, но ручная
инспекция показала битые ссылки. Логов под рукой не осталось, но с
подобным я уже сталкивался при пересборке ТеХовских компонент -- вспомни
историю с perl-SGMLSpm.

> > > Classic - это свалка всех подмножеств. В Contrib могут (а могут ли?) 
> > > попасть пакеты, которые провайдят не то, что надо.
> > Нет, не могут. Если такие пакеты есть, то их место в unsupported.
> Нет.
> unsupported - это вообще непонятно что такое.
Да.

> contrib - это в точности то место, куда incominger может себе позволить
> положить чей-то новый пакет без review; соответственно, за качество
> отвечает только maintainer.
Я с этим не согласен. Пусть такие пакеты идут в Daedalus. В Sisyphus все
должно подвергаться review. Не хватает мощностей при обработке incoming --
давайте что-то другое придумаем, но не будем уменьшать собственный
контроль качества.

> Саша, ты говоришь не лучше Антона.
> 
> В идеале, замкнутость должна быть покомпонентная:
> base
> base+castle+kernel
> base+junior+kernel
> base+castle+junior+kernel+master
> classic
Это -- не компоненты, это -- группы компонент.

> - каждая группа должна быть замкнута по установке, а группы master и
>   classic - ещё и по сборке.
С этим согласен. Однако выделять _только_ Мастера считаю неверным.

-- 
/ Alexander Bokovoy
---
A lack of leadership is no substitute for inaction.

Re: [devel] Broken python21

[AntonFarygin]

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

Alexander Bokovoy пишет:

>On Mon, Dec 09, 2002 at 11:50:01PM +0300, AntonFarygin wrote:
>  
>
>>>>Тогда у вас есть вероятность в BTE собирать не тем компилятором?
>>>>        
>>>>
>>>Нет. У нас ее нет, ибо мы используем ccache с правильными настройками.
>>>      
>>>
>>А ccache разваливается в BTE? Или как?
>>    
>>
>Не разваливается. Я же написал: "у нас ее (проблемы) нет".
>
Саш, ты меня не понял. Я спрашивал - как используется ссache в BTE?

>
>  
>
>>>rsync.altlinux.ru за последние дня 4 испытывал изменения почти только в 
>>>SRPMS, а
>>>все бинарные пакеты не менялись. Например, у меня сейчас в локальном
>>>репозитарии от сегодняшнего утра наблюдается целый gnome-panel-2.1.2-alt1 и
>>>битый симлинк gnome-panel-2.1.3-alt1. Зеркалирование еще утром делалось с
>>>rsync.altlinux.ru. И это не одно такое явление.
>>>      
>>>
>>Очень странно.  gnome-panel 2.1.3 лежит в Sisyphus со второго декабря (в 
>>нормальном, а не битом виде). Все нормально и на моей машине, которую я 
>>вчера зеркалировал с Sisyphus с rsync.altlinux.ru. Никаких проблем не 
>>возникало с зеркалированием. Да и rsync.altlinux.ru менялся все время 
>>также нормально (я зеркалирую только бинарные пакеты).
>>    
>>
>Мы специально вчера вечером провели ручную синхронизацию с
>rsync.altlinux.ru и она оказалась стольже неуспешной по результатам --
>обновлений бинарных пакетов не произошло. Я не знаю, кого здесь обвинять
>-- rsync.altlinux.ru, или луну, светившую на трафик по дороге...
>
Вчера вечером бинарные пакеты _гарантированно_ были. Я специально 
синхронизировал свой ноутбук с rsync.altlinux.ru - бинарные пакеты есть, 
все зависимости удовлетворены.

Явно проблема или в луне или у вас в rsync.

Пришли мне по личной почте rsync -nva --stats --delete-after

>
>  
>
>>>>Потому для сборки и лучше использовать Master.
>>>>        
>>>>
>>>Антон, ты говоришь ерунду. Что это за отношение к Classic как к свалке?
>>>Целостность Сизифа обеспечивается или должна обеспечиваться именно по
>>>Classic, а не по подмножествам. Иное -- путь к развалу зависимостей, что
>>>мы уже и наблюдаем (bootloader-utils, pysol, python21, ряд других) именно
>>>из-за ослабления контроля путем самоутешения в подкомпонентах.
>>>
>>>      
>>>
>>Я бы сказал не так: целостоность Sisyphus должна обеспечиваться как в 
>>отдельных компонентах, так и в Classic.
>>    
>>
>В отдельных компонентах нельзя добиться целостности, за исключением
>basesystem. Можно добиться целостности в наборах компонент, поскольку
>построены они по принципу матрешек. Так вот, для меня сломанность Contrib
>означает сломанность Sisyphus, причем она не замечается apt-get unmet,
>зато отлично видна в BTE при использовании механизма сборки или тестовой
>установки пакетов. Проблемы с pysol (отсутствие зависимости на tkinterp)
>вообще отлавливаются только при использовании -- попытке запуска. Я думаю,
>что и эту ситуацию мы будем пытаться в будущем подчинять
>автоматизированному тестированию (через использование UML).
>
Да, BTE вылавливает такие ошибки - я с этим столкнулся буквально сегодня ;)

Но у меня все еще тяжелее чем у вас - BTE работает с правами 
пользователя. ;-)

>
>  
>
>>То, что битые зависимости - несоменно ошибки, о которых также несомненно 
>>стоит сообщить в BTS.
>>    
>>
>Может стоит поставить PV -- там есть почтовый интерфейс к багам. А то с лазанием
>по bugs.altlinux.ru я очень быстро выеду свой 45Мб лимит трафика в неделю 
>на проксе :(
>
Может быть. Но лучше что-то тогда интегрированное с BTE и Sisyphus.

>
>  
>
>>Использовать Master для сборки лучше конечно по другой причине - если 
>>пакет падает в компоненту Master, то явно лучше собирать с 
>>использованием этой компоненты, что бы не нарушить ее целостность.
>>    
>>
>Я уже говорил, что это деление эфемерное, и приводил в сентябре примеры.
>Собственно, благодаря этому и возникло понятие Classic. Деление на Contrib
>и Master -- верный путь к ослаблению контроля качества сборки. Вспомните
>Contrib в Mandrake.
>
Для этого и создавался. Промышленный запуск BTE для всего devel@ , в 
теории, должен повысить качество пакетов, попадаемых в Sisyphus.

Я очень надеюсь, что это будет совсем скоро.

Rgds,
Rider


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

Re: [devel] Broken python21

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 01:02:12PM +0300, AntonFarygin wrote:
> >Не разваливается. Я же написал: "у нас ее (проблемы) нет".
> Саш, ты меня не понял. Я спрашивал - как используется ссache в BTE?
"Соответствующим образом" :) Посмотри в /usr/lib/rpm/macros и в пакет
ccache-bte.

> >В отдельных компонентах нельзя добиться целостности, за исключением
> >basesystem. Можно добиться целостности в наборах компонент, поскольку
> >построены они по принципу матрешек. Так вот, для меня сломанность Contrib
> >означает сломанность Sisyphus, причем она не замечается apt-get unmet,
> >зато отлично видна в BTE при использовании механизма сборки или тестовой
> >установки пакетов. Проблемы с pysol (отсутствие зависимости на tkinterp)
> >вообще отлавливаются только при использовании -- попытке запуска. Я думаю,
> >что и эту ситуацию мы будем пытаться в будущем подчинять
> >автоматизированному тестированию (через использование UML).
> >
> Да, BTE вылавливает такие ошибки - я с этим столкнулся буквально сегодня ;)
> 
> Но у меня все еще тяжелее чем у вас - BTE работает с правами 
> пользователя. ;-)
У нас тоже с правами пользователя (еще с весны). Так что к чему этот довод
-- не понял.

> >Может стоит поставить PV -- там есть почтовый интерфейс к багам. А то с 
> >лазанием
> >по bugs.altlinux.ru я очень быстро выеду свой 45Мб лимит трафика в неделю 
> >на проксе :(
> >
> Может быть. Но лучше что-то тогда интегрированное с BTE и Sisyphus.
PV здесь (в SaM Solutions) с BTE интегрирован. Вплоть до возможности
менять статус ошибок по коммитам спек-файлов.

> >Я уже говорил, что это деление эфемерное, и приводил в сентябре примеры.
> >Собственно, благодаря этому и возникло понятие Classic. Деление на Contrib
> >и Master -- верный путь к ослаблению контроля качества сборки. Вспомните
> >Contrib в Mandrake.
> Для этого и создавался. Промышленный запуск BTE для всего devel@ , в 
> теории, должен повысить качество пакетов, попадаемых в Sisyphus.
> 
> Я очень надеюсь, что это будет совсем скоро.
Это можно было сделать еще в конце лета.


-- 
/ Alexander Bokovoy
---
This will be a memorable month -- no matter how hard you try to forget it.

Re: [devel] BTE

[Dmitry V. Levin]

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

On Tue, Dec 10, 2002 at 12:28:08PM +0200, Alexander Bokovoy wrote:
> > Но у меня все еще тяжелее чем у вас - BTE работает с правами 
> > пользователя. ;-)
> У нас тоже с правами пользователя (еще с весны). Так что к чему этот довод
> -- не понял.

Ваша версия BTE устанавливает пакеты с правами root'а, что есть insecure.


--
ldv

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

Re: [devel] Dependencies

[Dmitry V. Levin]

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

On Tue, Dec 10, 2002 at 11:57:23AM +0200, Alexander Bokovoy wrote:
> > > репозитарии от сегодняшнего утра наблюдается целый gnome-panel-2.1.2-alt1 и
> > > битый симлинк gnome-panel-2.1.3-alt1. Зеркалирование еще утром делалось с
> > > rsync.altlinux.ru. И это не одно такое явление.
> > 
> > Звучит неправдоподобно.
> > Пишите мне, подробнее, и личной почтой.
> Дима, как я уже написал, вчера вечером, перед переключением на ibiblio, мы
> провели ручную синхронизацию и она оказалась столь же неуспешной, как и
> автоматические -- сам процесс rsync отработал без проблем, но ручная
> инспекция показала битые ссылки. Логов под рукой не осталось, но с
> подобным я уже сталкивался при пересборке ТеХовских компонент -- вспомни
> историю с perl-SGMLSpm.

Чудес не бывает.
Я же сказал, логи - личной почтой.

> > contrib - это в точности то место, куда incominger может себе позволить
> > положить чей-то новый пакет без review; соответственно, за качество
> > отвечает только maintainer.
> Я с этим не согласен. Пусть такие пакеты идут в Daedalus. В Sisyphus все
> должно подвергаться review. Не хватает мощностей при обработке incoming --
> давайте что-то другое придумаем, но не будем уменьшать собственный
> контроль качества.

Давай придумаем. Пока что мы имеем то, что имеем.

> > В идеале, замкнутость должна быть покомпонентная:
> > base
> > base+castle+kernel
> > base+junior+kernel
> > base+castle+junior+kernel+master
> > classic
> Это -- не компоненты, это -- группы компонент.
> 
> > - каждая группа должна быть замкнута по установке, а группы master и
> >   classic - ещё и по сборке.
> С этим согласен. Однако выделять _только_ Мастера считаю неверным.

Почему "только", я же перечислил 5 групп компонент.


--
ldv

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

Re: [devel] BTE

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 01:40:36PM +0300, Dmitry V. Levin wrote:
> On Tue, Dec 10, 2002 at 12:28:08PM +0200, Alexander Bokovoy wrote:
> > > Но у меня все еще тяжелее чем у вас - BTE работает с правами 
> > > пользователя. ;-)
> > У нас тоже с правами пользователя (еще с весны). Так что к чему этот довод
> > -- не понял.
> Ваша версия BTE устанавливает пакеты с правами root'а, что есть insecure.
Есть идеи как использовать команду chroot без соответствующих привилегий?

Сейчас эта установка "зажата" в sudo:
sandman 127.0.0.1=NOPASSWD:/usr/sbin/chroot /var/cache/sandman/*

Аналогично и остальные вызовы (apt-get, mount --bind, umount) -- все
зажато только на необходимые и четко определенные ресурсы.

Пользователь sandman -- системный (id = 107).

-- 
/ Alexander Bokovoy
---
I read the newspaper avidly.  It is my one form of continuous fiction.
		-- Aneurin Bevan

Re: [devel] Broken python21

[AntonFarygin]

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

Alexander Bokovoy пишет:

>On Tue, Dec 10, 2002 at 01:02:12PM +0300, AntonFarygin wrote:
>  
>
>>>Не разваливается. Я же написал: "у нас ее (проблемы) нет".
>>>      
>>>
>>Саш, ты меня не понял. Я спрашивал - как используется ссache в BTE?
>>    
>>
>"Соответствующим образом" :) Посмотри в /usr/lib/rpm/macros и в пакет
>ccache-bte.
>
Ага, спасибо. ;-)

>
>  
>
>>>В отдельных компонентах нельзя добиться целостности, за исключением
>>>basesystem. Можно добиться целостности в наборах компонент, поскольку
>>>построены они по принципу матрешек. Так вот, для меня сломанность Contrib
>>>означает сломанность Sisyphus, причем она не замечается apt-get unmet,
>>>зато отлично видна в BTE при использовании механизма сборки или тестовой
>>>установки пакетов. Проблемы с pysol (отсутствие зависимости на tkinterp)
>>>вообще отлавливаются только при использовании -- попытке запуска. Я думаю,
>>>что и эту ситуацию мы будем пытаться в будущем подчинять
>>>автоматизированному тестированию (через использование UML).
>>>
>>>      
>>>
>>Да, BTE вылавливает такие ошибки - я с этим столкнулся буквально сегодня ;)
>>
>>Но у меня все еще тяжелее чем у вас - BTE работает с правами 
>>пользователя. ;-)
>>    
>>
>У нас тоже с правами пользователя (еще с весны). Так что к чему этот довод
>-- не понял.
>
Chroot формируется с правами пользователя. chrootuid - для перехода в 
chroot.

>
>  
>
>>>Может стоит поставить PV -- там есть почтовый интерфейс к багам. А то с 
>>>лазанием
>>>по bugs.altlinux.ru я очень быстро выеду свой 45Мб лимит трафика в неделю 
>>>на проксе :(
>>>
>>>      
>>>
>>Может быть. Но лучше что-то тогда интегрированное с BTE и Sisyphus.
>>    
>>
>PV здесь (в SaM Solutions) с BTE интегрирован. Вплоть до возможности
>менять статус ошибок по коммитам спек-файлов.
>
>  
>
>>>Я уже говорил, что это деление эфемерное, и приводил в сентябре примеры.
>>>Собственно, благодаря этому и возникло понятие Classic. Деление на Contrib
>>>и Master -- верный путь к ослаблению контроля качества сборки. Вспомните
>>>Contrib в Mandrake.
>>>      
>>>
>>Для этого и создавался. Промышленный запуск BTE для всего devel@ , в 
>>теории, должен повысить качество пакетов, попадаемых в Sisyphus.
>>
>>Я очень надеюсь, что это будет совсем скоро.
>>    
>>
>Это можно было сделать еще в конце лета.
>
Насколько я знаю - нельзя. На то были соответствующие причины.

Rgds,
Rider


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

Re: [devel] BTE

[Dmitry V. Levin]

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

On Tue, Dec 10, 2002 at 12:51:24PM +0200, Alexander Bokovoy wrote:
> > > > Но у меня все еще тяжелее чем у вас - BTE работает с правами 
> > > > пользователя. ;-)
> > > У нас тоже с правами пользователя (еще с весны). Так что к чему этот довод
> > > -- не понял.
> > Ваша версия BTE устанавливает пакеты с правами root'а, что есть insecure.
> Есть идеи как использовать команду chroot без соответствующих привилегий?

Есть идея использовать chrootuid.


--
ldv

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

Re: [devel] BTE

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 12:51:24PM +0200, Alexander Bokovoy wrote:
> Пользователь sandman -- системный (id = 107).
На той машине, естественно. (107 сейчас в Сизифе -- rsyncd). Понятно, что
речь идет не о конкретном UID, а о 0 < UID < 500.
-- 
/ Alexander Bokovoy
---
The superior man understands what is right; the inferior man understands
what will sell.
		-- Confucius

Re: [devel] BTE

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 02:02:30PM +0300, Dmitry V. Levin wrote:
> On Tue, Dec 10, 2002 at 12:51:24PM +0200, Alexander Bokovoy wrote:
> > > > > Но у меня все еще тяжелее чем у вас - BTE работает с правами 
> > > > > пользователя. ;-)
> > > > У нас тоже с правами пользователя (еще с весны). Так что к чему этот довод
> > > > -- не понял.
> > > Ваша версия BTE устанавливает пакеты с правами root'а, что есть insecure.
> > Есть идеи как использовать команду chroot без соответствующих привилегий?
> Есть идея использовать chrootuid.
И как это поможет установить пакеты в chroot без запуска apt-get с
привилегиями root в этом chroot?

Дело ведь в том, что при установке пакетов надо соответствующие права
расставлять, владельцев менять и так далее. 

К тому же, непонятно чем поможет эта утилита в деле замены sudo --
BTE ведь и так работает не под root, она только процессы формирования
chroot запускает с повышением привилегий. А chrootuid имеет права 755, то
есть все равно не сможет выполнить chroot(2), будучи запущена из-под
непривилегированного пользователя sandman.

-- 
/ Alexander Bokovoy
---
To understand the heart and mind of a person, look not at what
he has already achieved, but at what he aspires to do.

Re: [devel] Broken python21

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 02:02:01PM +0300, AntonFarygin wrote:
> Chroot формируется с правами пользователя. chrootuid - для перехода в 
> chroot.
Для выполнения команды chrootuid все равно требуются права root, я не вижу
в этой схеме (глядя на исходный код chrootuid) серьезных преимуществ этой
команды. Раскажи мне подробнее о том, как формировать chroot без прав
root, не используя механизмы подмены библиотек как в Debian.

-- 
/ Alexander Bokovoy
---
What we Are is God's gift to us.
What we Become is our gift to God.

Re: [devel] BTE

[Dmitry V. Levin]

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

On Tue, Dec 10, 2002 at 01:15:15PM +0200, Alexander Bokovoy wrote:
> > > > > > Но у меня все еще тяжелее чем у вас - BTE работает с правами 
> > > > > > пользователя. ;-)
> > > > > У нас тоже с правами пользователя (еще с весны). Так что к чему этот довод
> > > > > -- не понял.
> > > > Ваша версия BTE устанавливает пакеты с правами root'а, что есть insecure.
> > > Есть идеи как использовать команду chroot без соответствующих привилегий?
> > Есть идея использовать chrootuid.
> И как это поможет установить пакеты в chroot без запуска apt-get с
> привилегиями root в этом chroot?

Это уже детали, о которых, надеюсь, расскажет Alexander Nikolaev.


--
ldv

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

Re: [devel] BTE

[Dmitry V. Levin]

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

On Tue, Dec 10, 2002 at 01:19:06PM +0200, Alexander Bokovoy wrote:
> > Chroot формируется с правами пользователя. chrootuid - для перехода в 
> > chroot.
> Для выполнения команды chrootuid все равно требуются права root, я не вижу

Зато есть возможность избежать необходимости запускать с правами root
параметризованных программ.

> в этой схеме (глядя на исходный код chrootuid) серьезных преимуществ этой
> команды. Раскажи мне подробнее о том, как формировать chroot без прав
> root, не используя механизмы подмены библиотек как в Debian.

Почему же не использовать эти самые механизмы?


--
ldv

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

Re: [devel] BTE

[Alexander V. Nikolaev]

On Tue, Dec 10, 2002 at 02:33:07PM +0300, Dmitry V. Levin wrote:
> On Tue, Dec 10, 2002 at 01:15:15PM +0200, Alexander Bokovoy wrote:
> > > > > > > Но у меня все еще тяжелее чем у вас - BTE работает с правами 
> > > > > > > пользователя. ;-)
> > > > > > У нас тоже с правами пользователя (еще с весны). Так что к чему этот довод
> > > > > > -- не понял.
> > > > > Ваша версия BTE устанавливает пакеты с правами root'а, что есть insecure.
> > > > Есть идеи как использовать команду chroot без соответствующих привилегий?
> > > Есть идея использовать chrootuid.
> > И как это поможет установить пакеты в chroot без запуска apt-get с
> > привилегиями root в этом chroot?
> 
> Это уже детали, о которых, надеюсь, расскажет Alexander Nikolaev.

Реально для ухода в chroot и создании девайсов используется связка 
sudo + chrootuid. 
В принципе Дима Левин говорил что можно сделать версию chroot работающую 
от пользователя и использующую capabilities

Re: [devel] Broken python21

[Alexander V. Nikolaev]

On Tue, Dec 10, 2002 at 01:19:06PM +0200, Alexander Bokovoy wrote:
> On Tue, Dec 10, 2002 at 02:02:01PM +0300, AntonFarygin wrote:
> > Chroot формируется с правами пользователя. chrootuid - для перехода в 
> > chroot.
> Для выполнения команды chrootuid все равно требуются права root, я не вижу
> в этой схеме (глядя на исходный код chrootuid) серьезных преимуществ этой
chrootuid избавляет от необходимости ставит пакет su в chroot

> команды. Раскажи мне подробнее о том, как формировать chroot без прав
> root, не используя механизмы подмены библиотек как в Debian.
> 

А что плохого в том чтобы выполнять postinst скрипты под fakeroot?

Re: [devel] BTE

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 02:52:18PM +0300, Alexander V. Nikolaev wrote:
> > > И как это поможет установить пакеты в chroot без запуска apt-get с
> > > привилегиями root в этом chroot?
> > Это уже детали, о которых, надеюсь, расскажет Alexander Nikolaev.
> Реально для ухода в chroot и создании девайсов используется связка 
> sudo + chrootuid. 
Это понятно, но это только для mknod(2).

> В принципе Дима Левин говорил что можно сделать версию chroot работающую 
> от пользователя и использующую capabilities
Это не ответ на вопрос, заданный выше.

Мне пока (по bte-0.2 с altair) непонятно, как происходит установка пакетов в chroot,
если id -un для процесса не root.
-- 
/ Alexander Bokovoy
---
Most people have a mind that's open by appointment only.

Re: [devel] Broken python21

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 02:54:39PM +0300, Alexander V. Nikolaev wrote:
> On Tue, Dec 10, 2002 at 01:19:06PM +0200, Alexander Bokovoy wrote:
> > On Tue, Dec 10, 2002 at 02:02:01PM +0300, AntonFarygin wrote:
> > > Chroot формируется с правами пользователя. chrootuid - для перехода в 
> > > chroot.
> > Для выполнения команды chrootuid все равно требуются права root, я не вижу
> > в этой схеме (глядя на исходный код chrootuid) серьезных преимуществ этой
> chrootuid избавляет от необходимости ставит пакет su в chroot
С этим согласен, это хорошее средство.

> > команды. Раскажи мне подробнее о том, как формировать chroot без прав
> > root, не используя механизмы подмены библиотек как в Debian.
> А что плохого в том чтобы выполнять postinst скрипты под fakeroot?
Зачем? Нет, я понимаю, что "все средства хороши", но это уж точно dirty
hack.

-- 
/ Alexander Bokovoy
---
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.

Re: [devel] BTE

[AntonFarygin]

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

Alexander Bokovoy пишет:

>On Tue, Dec 10, 2002 at 02:52:18PM +0300, Alexander V. Nikolaev wrote:
>  
>
>>>>И как это поможет установить пакеты в chroot без запуска apt-get с
>>>>привилегиями root в этом chroot?
>>>>        
>>>>
>>>Это уже детали, о которых, надеюсь, расскажет Alexander Nikolaev.
>>>      
>>>
>>Реально для ухода в chroot и создании девайсов используется связка 
>>sudo + chrootuid. 
>>    
>>
>Это понятно, но это только для mknod(2).
>
И для ухода в chroot для выполнения заданий в чруте (и для сборки в том 
числе).

>
>  
>
>>В принципе Дима Левин говорил что можно сделать версию chroot работающую 
>>от пользователя и использующую capabilities
>>    
>>
>Это не ответ на вопрос, заданный выше.
>
>Мне пока (по bte-0.2 с altair) непонятно, как происходит установка пакетов в chroot,
>если id -un для процесса не root.
>  
>
А rpm и apt-get install работают из под обычного пользователя, если им 
хватает прав на изменения необходимых им файлов.

Rgds,
Rider


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

Re: [devel] BTE

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 03:29:26PM +0300, AntonFarygin wrote:
> >Это понятно, но это только для mknod(2).
> И для ухода в chroot для выполнения заданий в чруте (и для сборки в том 
> числе).
Я по коду это уже увидел. Принципиально это ничем не отличается от того,
что есть в Tcl-версии, только делает меньше.

> >>В принципе Дима Левин говорил что можно сделать версию chroot работающую 
> >>от пользователя и использующую capabilities
> >Это не ответ на вопрос, заданный выше.
> >
> >Мне пока (по bte-0.2 с altair) непонятно, как происходит установка
> >пакетов в chroot, если id -un для процесса не root.
> А rpm и apt-get install работают из под обычного пользователя, если им 
> хватает прав на изменения необходимых им файлов.
В результате мы получаем среду, не идентичную реальной. И вот это уже
критично. Подумай сам -- такая система не может восприниматься как
доверительная с точки зрения сборщика -- в ней присутствуют существенные
различия с реальной средой. В результате получается, что основная задача
-- генерация эталонных пакетов -- не достигается. Ибо эти пакеты не
соответствуют тому, что происходит при сборке в "сферическом коне в
вакууме", которым является среда, полученная так, как ставятся пакеты в
реальности.


-- 
/ Alexander Bokovoy
---
Your/our computer(s) had suffered a memory leak, and we are waiting for them to be topped up.

Re: [devel] Broken python21

[Alexander V. Nikolaev]

On Tue, Dec 10, 2002 at 02:16:44PM +0200, Alexander Bokovoy wrote:

> > > команды. Раскажи мне подробнее о том, как формировать chroot без прав
> > > root, не используя механизмы подмены библиотек как в Debian.
> > А что плохого в том чтобы выполнять postinst скрипты под fakeroot?
> Зачем? Нет, я понимаю, что "все средства хороши", но это уж точно dirty
> hack.
> 
Единственным чистым и секьюрным решением будет Usermode Linux - всо 
остальное будет компромиссом или по "правильности сборки" или по 
безопасности

Re: [devel] Broken python21

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 04:01:21PM +0300, Alexander V. Nikolaev wrote:
> On Tue, Dec 10, 2002 at 02:16:44PM +0200, Alexander Bokovoy wrote:
> 
> > > > команды. Раскажи мне подробнее о том, как формировать chroot без прав
> > > > root, не используя механизмы подмены библиотек как в Debian.
> > > А что плохого в том чтобы выполнять postinst скрипты под fakeroot?
> > Зачем? Нет, я понимаю, что "все средства хороши", но это уж точно dirty
> > hack.
> > 
> Единственным чистым и секьюрным решением будет Usermode Linux - всо 
> остальное будет компромиссом или по "правильности сборки" или по 
> безопасности
На этом мы с тобой сходимся. Но это сильная архитектурная привязка. :)
-- 
/ Alexander Bokovoy
---
"The way of the world is to praise dead saints and prosecute live ones."
 -- Nathaniel Howe

Re: [devel] BTE

[Dmitry V. Levin]

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

On Tue, Dec 10, 2002 at 02:53:24PM +0200, Alexander Bokovoy wrote:
> > >Мне пока (по bte-0.2 с altair) непонятно, как происходит установка
> > >пакетов в chroot, если id -un для процесса не root.
> > А rpm и apt-get install работают из под обычного пользователя, если им 
> > хватает прав на изменения необходимых им файлов.
> В результате мы получаем среду, не идентичную реальной. И вот это уже
> критично. Подумай сам -- такая система не может восприниматься как
> доверительная с точки зрения сборщика -- в ней присутствуют существенные
> различия с реальной средой. В результате получается, что основная задача
> -- генерация эталонных пакетов -- не достигается. Ибо эти пакеты не
> соответствуют тому, что происходит при сборке в "сферическом коне в
> вакууме", которым является среда, полученная так, как ставятся пакеты в
> реальности.

Дело в том, что реальности бывают разные.
Именно поэтому бывают ситуации, когда некоторые говорят, что у них "не
работает".

Я не вижу причин считать эту реальность хуже других.


--
ldv

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

[devel] Re: Broken python21

[Andrey Khavryuchenko]

Alexander,

"AVN" == Alexander V Nikolaev wrote:

 AVN> Единственным чистым и секьюрным решением будет Usermode Linux - всо 
 AVN> остальное будет компромиссом или по "правильности сборки" или по 
 AVN> безопасности

BTW, существует ли в публичном доступе какой-либо .spec на него?  Я до сих
пор не собрал этот пакет для Сизифа исключительно потому, что нет времени
писать его с нуля.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/edu/

[devel] Re: Broken python21

[Andrey Khavryuchenko]

Alexander,

"AB" == Alexander Bokovoy wrote:

 AB> On Tue, Dec 10, 2002 at 04:01:21PM +0300, Alexander V. Nikolaev wrote:
 >> On Tue, Dec 10, 2002 at 02:16:44PM +0200, Alexander Bokovoy wrote:
 >> Единственным чистым и секьюрным решением будет Usermode Linux - всо 
 >> остальное будет компромиссом или по "правильности сборки" или по 
 >> безопасности
 AB> На этом мы с тобой сходимся. Но это сильная архитектурная привязка. :)

??? К чему привязка?

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/edu/

Re: [devel] Re: Broken python21

[Alexander V. Nikolaev]

On Tue, Dec 10, 2002 at 03:32:18PM +0200, Andrey Khavryuchenko wrote:
>  AVN> Единственным чистым и секьюрным решением будет Usermode Linux - всо 
>  AVN> остальное будет компромиссом или по "правильности сборки" или по 
>  AVN> безопасности
> 
> BTW, существует ли в публичном доступе какой-либо .spec на него?  Я до сих
> пор не собрал этот пакет для Сизифа исключительно потому, что нет времени
> писать его с нуля.
Мне неизвестно...
И как найти компромисс по конфигурации ;)
Или all in modules?


По крайней мере я хотел бы видеть конфигурацию где не будет доступа к 
host файловой системе и сеть будет в виде tun/tap.

Re: [devel] BTE

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 04:19:33PM +0300, Dmitry V. Levin wrote:
> > В результате мы получаем среду, не идентичную реальной. И вот это уже
> > критично. Подумай сам -- такая система не может восприниматься как
> > доверительная с точки зрения сборщика -- в ней присутствуют существенные
> > различия с реальной средой. В результате получается, что основная задача
> > -- генерация эталонных пакетов -- не достигается. Ибо эти пакеты не
> > соответствуют тому, что происходит при сборке в "сферическом коне в
> > вакууме", которым является среда, полученная так, как ставятся пакеты в
> > реальности.
> 
> Дело в том, что реальности бывают разные.
> Именно поэтому бывают ситуации, когда некоторые говорят, что у них "не
> работает".
> 
> Я не вижу причин считать эту реальность хуже других.
Давай для начала определимся с задачами. Мы хотим достигнуть следующих
целей, по крайней мере, я формулирую себе их так:

1. Непротиворечивая и качественно собранная пакетная база дистрибутива.
2. Высокий уровень безопасности используемых для достижения (1) средств.
3. По возможности единообразные алгоритмы для выполнения одинаковых задач
   в разных процессах.
4. Единая система сборки всех категорий результирующих продуктов -- от
   отдельных пакетов и репозитариев до ISO-образов, содержащих
   конкретные решение ("устанавливаемые дистрибутивы", "системы для
   запуска прямо с CD" и так далее).
5. Единая система контроля качества всех категорий результирующих продуктов.

Исходя из указанных задач, можно делать выводы о приспособленности тех или
иных средств для их решения.

В частности, очевидно, что процессы 1) подготовки сборочной среды для
сборки пакетов, 2) установки пакетов дистрибутива, 3) подготовки
тестирующей среды и 4) подготовки сборочной среды для собирания
ISO-образов, содержат одинаковые подпроцессы установки пакетов (базовой
системы, дополнений, etc), выполнение которых должно происходить
идентично, насколько это возможно.

Та реальность, которую ты предлагаешь считать "не хуже других", не
позволяет обеспечить идентичную реализацию одинаковых подпроцессов. Более
того, исходя из развернутого разговора с AVN, данная реальность не
предполагает одинакового поведения при сборке всех пакетов, что неумолимо
ведет к рождению исключений. Я считаю это серьезной ошибкой в
проектировании.

-- 
/ Alexander Bokovoy
---
To invent, you need a good imagination and a pile of junk.
		-- Thomas Edison

[devel] Re: Broken python21

[Andrey Khavryuchenko]

Alexander,

"AVN" == Alexander V Nikolaev wrote:

 AVN> On Tue, Dec 10, 2002 at 03:32:18PM +0200, Andrey Khavryuchenko wrote:
 AVN> Единственным чистым и секьюрным решением будет Usermode Linux - всо 
 AVN> остальное будет компромиссом или по "правильности сборки" или по 
 AVN> безопасности
 >> 
 >> BTW, существует ли в публичном доступе какой-либо .spec на него?  Я до сих
 >> пор не собрал этот пакет для Сизифа исключительно потому, что нет времени
 >> писать его с нуля.
 AVN> Мне неизвестно...

Жаль.  Потому как в uml-ном списке меня послали.  На kernel.org :(

 AVN> И как найти компромисс по конфигурации ;)
 AVN> Или all in modules?

Его бы хоть как-то собрать.

 AVN> По крайней мере я хотел бы видеть конфигурацию где не будет доступа к 
 AVN> host файловой системе и сеть будет в виде tun/tap.

Будем посмотреть.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/edu/

Re: [devel] Re: Broken python21

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 03:37:56PM +0200, Andrey Khavryuchenko wrote:
> Alexander,
> 
> "AB" == Alexander Bokovoy wrote:
> 
>  AB> On Tue, Dec 10, 2002 at 04:01:21PM +0300, Alexander V. Nikolaev wrote:
>  >> On Tue, Dec 10, 2002 at 02:16:44PM +0200, Alexander Bokovoy wrote:
>  >> Единственным чистым и секьюрным решением будет Usermode Linux - всо 
>  >> остальное будет компромиссом или по "правильности сборки" или по 
>  >> безопасности
>  AB> На этом мы с тобой сходимся. Но это сильная архитектурная привязка. :)
> ??? К чему привязка?
К конкретному ядру (типу ядер).
-- 
/ Alexander Bokovoy
---
Not SENSUOUS ... only "FROLICSOME" ... and in need of DENTAL WORK ... in PAIN!!!

Re: [devel] Re: Broken python21

[aen]

Andrey Khavryuchenko wrote:

>Alexander,
>
>"AVN" == Alexander V Nikolaev wrote:
>
> AVN> On Tue, Dec 10, 2002 at 03:32:18PM +0200, Andrey Khavryuchenko wrote:
> AVN> Единственным чистым и секьюрным решением будет Usermode Linux - всо 
> AVN> остальное будет компромиссом или по "правильности сборки" или по 
> AVN> безопасности
> >> 
> >> BTW, существует ли в публичном доступе какой-либо .spec на него?  Я до сих
> >> пор не собрал этот пакет для Сизифа исключительно потому, что нет времени
> >> писать его с нуля.
> AVN> Мне неизвестно...
>
>Жаль.  Потому как в uml-ном списке меня послали.  На kernel.org :(
>
>  
>
Я собирал пакет umlinux для Spring.

Rgrds, Алексей

[devel] Re: Broken python21

[Andrey Khavryuchenko]

Aleksey,

"a" == aen  wrote:

 a> Andrey Khavryuchenko wrote:
 >> Жаль.  Потому как в uml-ном списке меня послали.  На kernel.org :(
 a> Я собирал пакет umlinux для Spring.

Спек или .src.rpm личным мылом можно?

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/edu/

Re: [devel] BTE

[AntonFarygin]

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

Alexander Bokovoy пишет:

>On Tue, Dec 10, 2002 at 04:19:33PM +0300, Dmitry V. Levin wrote:
>  
>
>>>В результате мы получаем среду, не идентичную реальной. И вот это уже
>>>критично. Подумай сам -- такая система не может восприниматься как
>>>доверительная с точки зрения сборщика -- в ней присутствуют существенные
>>>различия с реальной средой. В результате получается, что основная задача
>>>-- генерация эталонных пакетов -- не достигается. Ибо эти пакеты не
>>>соответствуют тому, что происходит при сборке в "сферическом коне в
>>>вакууме", которым является среда, полученная так, как ставятся пакеты в
>>>реальности.
>>>      
>>>
>>Дело в том, что реальности бывают разные.
>>Именно поэтому бывают ситуации, когда некоторые говорят, что у них "не
>>работает".
>>
>>Я не вижу причин считать эту реальность хуже других.
>>    
>>
>Давай для начала определимся с задачами. Мы хотим достигнуть следующих
>целей, по крайней мере, я формулирую себе их так:
>
>1. Непротиворечивая и качественно собранная пакетная база дистрибутива.
>2. Высокий уровень безопасности используемых для достижения (1) средств.
>3. По возможности единообразные алгоритмы для выполнения одинаковых задач
>   в разных процессах.
>4. Единая система сборки всех категорий результирующих продуктов -- от
>   отдельных пакетов и репозитариев до ISO-образов, содержащих
>   конкретные решение ("устанавливаемые дистрибутивы", "системы для
>   запуска прямо с CD" и так далее).
>5. Единая система контроля качества всех категорий результирующих продуктов.
>
Пункт 5 - единый с чем именно? Не понимаю...

>
>Исходя из указанных задач, можно делать выводы о приспособленности тех или
>иных средств для их решения.
>
>В частности, очевидно, что процессы 1) подготовки сборочной среды для
>сборки пакетов, 2) установки пакетов дистрибутива, 3) подготовки
>тестирующей среды и 4) подготовки сборочной среды для собирания
>ISO-образов, содержат одинаковые подпроцессы установки пакетов (базовой
>системы, дополнений, etc), выполнение которых должно происходить
>идентично, насколько это возможно.
>
Согласен со всем, кроме пункта 1. Ибо, на мой взгляд, в сборочной среде 
не должно присутствовать:
a) по возможности установленных сервисных программ
б) по возможности _запущенных_ сервисных программ. Например - на данный 
момент процесс N 1 обламывается на этапе установки пакета apache на 
скрипте добавления chkconfig --add httpd (что естественно). Да и не 
совсем понятно - почему для apache-devel необходим пакет apache ??? 
Разве нельзя пакеты собирать, не имея реальных сервисов в системе, а 
имея только библиотеки?

Все остальные среды, несомненно, должны эмулировать реальную систему.

Причина, побудившая выполнять создание сборочной среды под обычным 
пользователем - в первую очередь безопасность. Не стоит забывать, что  у 
нас сейчас будет открываться доступ к сборочным серверам через почтовый 
интерфейс. И, честно говоря, давать возможность создавать рутовые чруты 
по письму (пусть даже авторизованному) - страшно.

А все остальные перечисленные операции, стандартно выполняются в более 
доверенной среде.

Кстати, модифицировать тот код, добавив возможность работать через sudo 
на рута не составит больших проблем.

>
>Та реальность, которую ты предлагаешь считать "не хуже других", не
>позволяет обеспечить идентичную реализацию одинаковых подпроцессов. Более
>того, исходя из развернутого разговора с AVN, данная реальность не
>предполагает одинакового поведения при сборке всех пакетов, что неумолимо
>ведет к рождению исключений. Я считаю это серьезной ошибкой в
>проектировании.
>
Можно поподробнее про неодинаковое поведение?
Поведение сборочной среды диктуется исключительно зависимостями пакета и 
возможностью указывать другой apt репозиторий.

Rdgs,
Rider


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

Re: [devel] BTE

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 07:00:20PM +0300, AntonFarygin wrote:
> >2. Высокий уровень безопасности используемых для достижения (1) средств.
> >3. По возможности единообразные алгоритмы для выполнения одинаковых задач
> >  в разных процессах.
> >4. Единая система сборки всех категорий результирующих продуктов -- от
> >  отдельных пакетов и репозитариев до ISO-образов, содержащих
> >  конкретные решение ("устанавливаемые дистрибутивы", "системы для
> >  запуска прямо с CD" и так далее).
> >5. Единая система контроля качества всех категорий результирующих 
> >продуктов.
> >
> Пункт 5 - единый с чем именно? Не понимаю...
Единая со всей остальной системой (BTS, project management, сборочной
средой). Потому что контроль качества -- это не только проверка на
устанавливаемость пакетов, это и feedback, и соответствующие блокировки
выполнения задач в проекте.

> >системы, дополнений, etc), выполнение которых должно происходить
> >идентично, насколько это возможно.
> >
> Согласен со всем, кроме пункта 1. Ибо, на мой взгляд, в сборочной среде 
> не должно присутствовать:
> a) по возможности установленных сервисных программ
Ты имеешь в виду тех, что ставят себя в init.d?

> б) по возможности _запущенных_ сервисных программ. Например - на данный 
> момент процесс N 1 обламывается на этапе установки пакета apache на 
> скрипте добавления chkconfig --add httpd (что естественно). Да и не 
Неестественно.

> совсем понятно - почему для apache-devel необходим пакет apache ??? 
> Разве нельзя пакеты собирать, не имея реальных сервисов в системе, а 
> имея только библиотеки?
В случае apache надо рассматривать подробнее (я не помню прямо сейчас).
Однако я не понимаю, почему chkconfig --add httpd должен что-то ломать --
ведь при выполнении этой команды ничего реально не запускается, только
делается symlink.

> Все остальные среды, несомненно, должны эмулировать реальную систему.
> 
> Причина, побудившая выполнять создание сборочной среды под обычным 
> пользователем - в первую очередь безопасность. Не стоит забывать, что  у 
> нас сейчас будет открываться доступ к сборочным серверам через почтовый 
> интерфейс. И, честно говоря, давать возможность создавать рутовые чруты 
> по письму (пусть даже авторизованному) - страшно.
Страшно -- помести "исполнителя" в UML. Это вопрос deployment
соответствующей службы, а не ее реализации. Вот cvs и shell не
предоставляют достаточных средств для защиты, а devel.altlinux.ru тем не
менее серьезно защищен.

> >Та реальность, которую ты предлагаешь считать "не хуже других", не
> >позволяет обеспечить идентичную реализацию одинаковых подпроцессов. Более
> >того, исходя из развернутого разговора с AVN, данная реальность не
> >предполагает одинакового поведения при сборке всех пакетов, что неумолимо
> >ведет к рождению исключений. Я считаю это серьезной ошибкой в
> >проектировании.
> >
> Можно поподробнее про неодинаковое поведение?
> Поведение сборочной среды диктуется исключительно зависимостями пакета и 
> возможностью указывать другой apt репозиторий.
Этот вопрос я переадресую AVN, поскольку он и вел речь про неодинаковое
поведение.


-- 
/ Alexander Bokovoy
---
When does summertime come to Minnesota, you ask?  Well, last year, I
think it was a Tuesday.

Re: [devel] BTE

[AntonFarygin]

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

Alexander Bokovoy пишет:

>On Tue, Dec 10, 2002 at 07:00:20PM +0300, AntonFarygin wrote:
>  
>
>>>2. Высокий уровень безопасности используемых для достижения (1) средств.
>>>3. По возможности единообразные алгоритмы для выполнения одинаковых задач
>>> в разных процессах.
>>>4. Единая система сборки всех категорий результирующих продуктов -- от
>>> отдельных пакетов и репозитариев до ISO-образов, содержащих
>>> конкретные решение ("устанавливаемые дистрибутивы", "системы для
>>> запуска прямо с CD" и так далее).
>>>5. Единая система контроля качества всех категорий результирующих 
>>>продуктов.
>>>
>>>      
>>>
>>Пункт 5 - единый с чем именно? Не понимаю...
>>    
>>
>Единая со всей остальной системой (BTS, project management, сборочной
>средой). Потому что контроль качества -- это не только проверка на
>устанавливаемость пакетов, это и feedback, и соответствующие блокировки
>выполнения задач в проекте.
>
>  
>
>>>системы, дополнений, etc), выполнение которых должно происходить
>>>идентично, насколько это возможно.
>>>
>>>      
>>>
>>Согласен со всем, кроме пункта 1. Ибо, на мой взгляд, в сборочной среде 
>>не должно присутствовать:
>>a) по возможности установленных сервисных программ
>>    
>>
>Ты имеешь в виду тех, что ставят себя в init.d?
>
Да.

>
>  
>
>>б) по возможности _запущенных_ сервисных программ. Например - на данный 
>>момент процесс N 1 обламывается на этапе установки пакета apache на 
>>скрипте добавления chkconfig --add httpd (что естественно). Да и не 
>>    
>>
>Неестественно.
>
Кстати, действительно. Обламывается с сообщением о том, что на операцию 
нет прав. Если надо - вышлю логи сборки mod_ruby

>
>  
>
>>совсем понятно - почему для apache-devel необходим пакет apache ??? 
>>Разве нельзя пакеты собирать, не имея реальных сервисов в системе, а 
>>имея только библиотеки?
>>    
>>
>В случае apache надо рассматривать подробнее (я не помню прямо сейчас).
>Однако я не понимаю, почему chkconfig --add httpd должен что-то ломать --
>ведь при выполнении этой команды ничего реально не запускается, только
>делается symlink.
>
Да, он действительно не ломает. Так это же еще один плюс в эту систему.

>
>  
>
>>Все остальные среды, несомненно, должны эмулировать реальную систему.
>>
>>Причина, побудившая выполнять создание сборочной среды под обычным 
>>пользователем - в первую очередь безопасность. Не стоит забывать, что  у 
>>нас сейчас будет открываться доступ к сборочным серверам через почтовый 
>>интерфейс. И, честно говоря, давать возможность создавать рутовые чруты 
>>по письму (пусть даже авторизованному) - страшно.
>>    
>>
>Страшно -- помести "исполнителя" в UML. Это вопрос deployment
>соответствующей службы, а не ее реализации. Вот cvs и shell не
>предоставляют достаточных средств для защиты, а devel.altlinux.ru тем не
>менее серьезно защищен.
>
Так мы чем и занимаемся. Реализация очень тесно связана с дальнейшей 
эксплуатацией.

>
>  
>
>>>Та реальность, которую ты предлагаешь считать "не хуже других", не
>>>позволяет обеспечить идентичную реализацию одинаковых подпроцессов. Более
>>>того, исходя из развернутого разговора с AVN, данная реальность не
>>>предполагает одинакового поведения при сборке всех пакетов, что неумолимо
>>>ведет к рождению исключений. Я считаю это серьезной ошибкой в
>>>проектировании.
>>>
>>>      
>>>
>>Можно поподробнее про неодинаковое поведение?
>>Поведение сборочной среды диктуется исключительно зависимостями пакета и 
>>возможностью указывать другой apt репозиторий.
>>    
>>
>Этот вопрос я переадресую AVN, поскольку он и вел речь про неодинаковое
>поведение.
>
Я у него уже уточнил. Как сказал мне AVN, под неодинаковым поведением он 
имел в виду отсутствие системных сервисов, поднимаемых в чруте.

Вы с ним явно друг друга не поняли ;-)

Для всех без исключения пакетов установка проходит единообразно, за 
исключением, пожалуй, сборочных зависимостей. То, что некоторые POST 
скрипты не могут выполняться с правами, отличными от root - недостаток 
этих POST скриптов, а не как не системы сборки.
Т.е. - реальное тестирование _установки_ выходит на качественно более 
высокий уровень, позволяюще выявлять абсолютно не нужные,мало того - 
запрещенные в реальной системе действия. Как то старт сервиса, открытие 
соединений наружу и т.д. и т.п.

Правда остается еще одна проблема - возможность изменения системных 
библиотек из пост-скриптов. Может быть стоит делать полностью весь 
chroot read-only ?


Rgds,
Rider


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

Re: [devel] BTE

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 08:04:07PM +0300, AntonFarygin wrote:
> >>б) по возможности _запущенных_ сервисных программ. Например - на данный 
> >>момент процесс N 1 обламывается на этапе установки пакета apache на 
> >>скрипте добавления chkconfig --add httpd (что естественно). Да и не 
> >Неестественно.
> Кстати, действительно. Обламывается с сообщением о том, что на операцию 
> нет прав. Если надо - вышлю логи сборки mod_ruby
Так на какую операцию нет прав? (Высылай).

> >В случае apache надо рассматривать подробнее (я не помню прямо сейчас).
> >Однако я не понимаю, почему chkconfig --add httpd должен что-то ломать --
> >ведь при выполнении этой команды ничего реально не запускается, только
> >делается symlink.
> Да, он действительно не ломает. Так это же еще один плюс в эту систему.
Это еще один показатель, что проблема с несобирающимся mod_ruby лежит в
другом месте. :)

> >Страшно -- помести "исполнителя" в UML. Это вопрос deployment
> >соответствующей службы, а не ее реализации. Вот cvs и shell не
> >предоставляют достаточных средств для защиты, а devel.altlinux.ru тем не
> >менее серьезно защищен.
> Так мы чем и занимаемся. Реализация очень тесно связана с дальнейшей 
> эксплуатацией.
Вот это -- совершенно неправильно. BTE, как она проектировалась и
реализовывалась нами, позволяет существование независимых сборочных сред
на разных машинах. В том числе и автономно. Если новая версия будет тесно
завязана на конкретную эксплуатацию, то особого смысла в ней не будет --
это будет очередной закрытый проект, увы.

> >Этот вопрос я переадресую AVN, поскольку он и вел речь про неодинаковое
> >поведение.
> Я у него уже уточнил. Как сказал мне AVN, под неодинаковым поведением он 
> имел в виду отсутствие системных сервисов, поднимаемых в чруте.
Как я уже сказал, сервисы в chroot и так не поднимаются (и никогда не
поднимались). Так что я не понимаю, откуда может взяться такое видение
ситуации и требование, чтобы они не поднимались.

> Для всех без исключения пакетов установка проходит единообразно, за 
> исключением, пожалуй, сборочных зависимостей. То, что некоторые POST 
> скрипты не могут выполняться с правами, отличными от root - недостаток 
> этих POST скриптов, а не как не системы сборки.
Антон, тебя начинает заносить. На то она и установка с правами 
администратора по жизни. В противном случае ты получаешь несоответствие
LSB в сгенерированной файловой системе.

> Правда остается еще одна проблема - возможность изменения системных 
> библиотек из пост-скриптов. Может быть стоит делать полностью весь 
> chroot read-only ?
Не стоит.

-- 
/ Alexander Bokovoy
---
The only difference between a rut and a grave is their dimensions.

Re: [devel] BTE

[Dmitry V. Levin]

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

On Tue, Dec 10, 2002 at 07:28:47PM +0200, Alexander Bokovoy wrote:
> > Я у него уже уточнил. Как сказал мне AVN, под неодинаковым поведением он 
> > имел в виду отсутствие системных сервисов, поднимаемых в чруте.
> Как я уже сказал, сервисы в chroot и так не поднимаются (и никогда не
> поднимались). Так что я не понимаю, откуда может взяться такое видение
> ситуации и требование, чтобы они не поднимались.

Это немного другой вопрос, но все же:
если %post (%pre или ещё кто-то) настолько крив, что запускает таки
сервер, то что делать в таком случае?

> > Правда остается еще одна проблема - возможность изменения системных 
> > библиотек из пост-скриптов. Может быть стоит делать полностью весь 
> > chroot read-only ?
> Не стоит.

Согласно fhs, /tmp и /var/tmp должны быть доступны по записи.
Это, конечно, не значит, что нормально написанные программы будут туда
писать, но все же.


--
ldv

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

Re: [devel] BTE

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 09:41:08PM +0300, Dmitry V. Levin wrote:
> On Tue, Dec 10, 2002 at 07:28:47PM +0200, Alexander Bokovoy wrote:
> > > Я у него уже уточнил. Как сказал мне AVN, под неодинаковым поведением он 
> > > имел в виду отсутствие системных сервисов, поднимаемых в чруте.
> > Как я уже сказал, сервисы в chroot и так не поднимаются (и никогда не
> > поднимались). Так что я не понимаю, откуда может взяться такое видение
> > ситуации и требование, чтобы они не поднимались.
> 
> Это немного другой вопрос, но все же:
> если %post (%pre или ещё кто-то) настолько крив, что запускает таки
> сервер, то что делать в таком случае?
Править spec-файл, очевидно. Вообще, здесь надо разделить две проблемы:
1. Проблема с уже имеющимися в репозитарии версиями пакетов. Очевидно, 
   что при вводе системы в строй придется провести аудит всех пакетов на 
   эту тему и исправить их.
2. Проблема с новыми версиями пакетов, приходящими в систему через incoming.
   В этом случае привходящий пакет подвергается обязательной проверке
   путем установки в UML и сверкой состояний до/после установки.

-- 
/ Alexander Bokovoy
---
Bombeck's Rule of Medicine:
	Never go to a doctor whose office plants have died.

[devel] Re: BTE

[Michael Shigorin]

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

On Tue, Dec 10, 2002 at 07:00:20PM +0300, AntonFarygin wrote:
> Не стоит забывать, что  у нас сейчас будет открываться доступ к
> сборочным серверам через почтовый интерфейс. И, честно говоря,
> давать возможность создавать рутовые чруты по письму (пусть
> даже авторизованному) - страшно.

Это понятно.  Мне, правда, почему-то казалось, что сборка в BTE
наружу не выставляется, а является (прерогативой|удобством) ОТК.

Т.е. доступ _уже_ ограничен, можно сказать -- и с целью
обеспечения этого самого К.

> Можно поподробнее про неодинаковое поведение?
> Поведение сборочной среды диктуется исключительно зависимостями
> пакета и возможностью указывать другой apt репозиторий.

Возможно ли поручиться за поведение кода _пакетов_?

PS: можно игнорировать, наверное.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] BTE

[Dmitry V. Levin]

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

On Tue, Dec 10, 2002 at 08:48:46PM +0200, Alexander Bokovoy wrote:
> > Это немного другой вопрос, но все же:
> > если %post (%pre или ещё кто-то) настолько крив, что запускает таки
> > сервер, то что делать в таком случае?
> Править spec-файл, очевидно. Вообще, здесь надо разделить две проблемы:
> 1. Проблема с уже имеющимися в репозитарии версиями пакетов. Очевидно, 
>    что при вводе системы в строй придется провести аудит всех пакетов на 
>    эту тему и исправить их.

Это уже довольно большая задача.

> 2. Проблема с новыми версиями пакетов, приходящими в систему через incoming.
>    В этом случае привходящий пакет подвергается обязательной проверке
>    путем установки в UML и сверкой состояний до/после установки.

Это уже тянет на "светлое будущее".


--
ldv

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

Re: [devel] BTE

[Alexander Bokovoy]

On Tue, Dec 10, 2002 at 10:59:09PM +0300, Dmitry V. Levin wrote:
> On Tue, Dec 10, 2002 at 08:48:46PM +0200, Alexander Bokovoy wrote:
> > > Это немного другой вопрос, но все же:
> > > если %post (%pre или ещё кто-то) настолько крив, что запускает таки
> > > сервер, то что делать в таком случае?
> > Править spec-файл, очевидно. Вообще, здесь надо разделить две проблемы:
> > 1. Проблема с уже имеющимися в репозитарии версиями пакетов. Очевидно, 
> >    что при вводе системы в строй придется провести аудит всех пакетов на 
> >    эту тему и исправить их.
> Это уже довольно большая задача.
Ввод BTE в эксплуатацию -- сама по себе довольно большая задача.
Опыт сборки для Сизифа в BTE показывает, что хотя ситуация в Сизифе далека
от идеала, указанных проблем в нем не встречалось. Исследование AVN и
Mouse показало только один подобный сервис.

> 
> > 2. Проблема с новыми версиями пакетов, приходящими в систему через incoming.
> >    В этом случае привходящий пакет подвергается обязательной проверке
> >    путем установки в UML и сверкой состояний до/после установки.
> Это уже тянет на "светлое будущее".
Ничего сложного, кстати. Мы проводили эксперимент год назад. Все
замечательно скриптуется.

-- 
/ Alexander Bokovoy
---
Byte your tongue.

Re: [devel] BTE

[AntonFarygin]

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

Alexander Bokovoy пишет:

>On Tue, Dec 10, 2002 at 09:41:08PM +0300, Dmitry V. Levin wrote:
>  
>
>>On Tue, Dec 10, 2002 at 07:28:47PM +0200, Alexander Bokovoy wrote:
>>    
>>
>>>>Я у него уже уточнил. Как сказал мне AVN, под неодинаковым поведением он 
>>>>имел в виду отсутствие системных сервисов, поднимаемых в чруте.
>>>>        
>>>>
>>>Как я уже сказал, сервисы в chroot и так не поднимаются (и никогда не
>>>поднимались). Так что я не понимаю, откуда может взяться такое видение
>>>ситуации и требование, чтобы они не поднимались.
>>>      
>>>
>>Это немного другой вопрос, но все же:
>>если %post (%pre или ещё кто-то) настолько крив, что запускает таки
>>сервер, то что делать в таком случае?
>>    
>>
>Править spec-файл, очевидно. Вообще, здесь надо разделить две проблемы:
>1. Проблема с уже имеющимися в репозитарии версиями пакетов. Очевидно, 
>   что при вводе системы в строй придется провести аудит всех пакетов на 
>   эту тему и исправить их.
>
Да нет. В нашем случае само провериться ;-)

>2. Проблема с новыми версиями пакетов, приходящими в систему через incoming.
>   В этом случае привходящий пакет подвергается обязательной проверке
>   путем установки в UML и сверкой состояний до/после установки.
>
>  
>
Аналогично...

Rgds,
Rider


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

Re: [devel] Re: BTE

[AntonFarygin]

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

Michael Shigorin пишет:

>On Tue, Dec 10, 2002 at 07:00:20PM +0300, AntonFarygin wrote:
>  
>
>>Не стоит забывать, что  у нас сейчас будет открываться доступ к
>>сборочным серверам через почтовый интерфейс. И, честно говоря,
>>давать возможность создавать рутовые чруты по письму (пусть
>>даже авторизованному) - страшно.
>>    
>>
>
>Это понятно.  Мне, правда, почему-то казалось, что сборка в BTE
>наружу не выставляется, а является (прерогативой|удобством) ОТК.
>
Нет. Это раньше так было. Сейчас мы работаем над тем, что бы полностью 
автоматизировать процесс:
мантейнер->пакет->бинарный пакет->Sisyphus

>
>Т.е. доступ _уже_ ограничен, можно сказать -- и с целью
>обеспечения этого самого К.
>
Он ограничен по другим причинам: система еще не созрела для нормальной 
эксплуатации.

>
>  
>
>>Можно поподробнее про неодинаковое поведение?
>>Поведение сборочной среды диктуется исключительно зависимостями
>>пакета и возможностью указывать другой apt репозиторий.
>>    
>>
>
>Возможно ли поручиться за поведение кода _пакетов_?
>
Нет, естественно нет.

Rgds,
Rider


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

Re: [devel] BTE

[AntonFarygin]

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

Alexander Bokovoy пишет:

>On Tue, Dec 10, 2002 at 10:59:09PM +0300, Dmitry V. Levin wrote:
>  
>
>>On Tue, Dec 10, 2002 at 08:48:46PM +0200, Alexander Bokovoy wrote:
>>    
>>
>>>>Это немного другой вопрос, но все же:
>>>>если %post (%pre или ещё кто-то) настолько крив, что запускает таки
>>>>сервер, то что делать в таком случае?
>>>>        
>>>>
>>>Править spec-файл, очевидно. Вообще, здесь надо разделить две проблемы:
>>>1. Проблема с уже имеющимися в репозитарии версиями пакетов. Очевидно, 
>>>   что при вводе системы в строй придется провести аудит всех пакетов на 
>>>   эту тему и исправить их.
>>>      
>>>
>>Это уже довольно большая задача.
>>    
>>
>Ввод BTE в эксплуатацию -- сама по себе довольно большая задача.
>Опыт сборки для Сизифа в BTE показывает, что хотя ситуация в Сизифе далека
>от идеала, указанных проблем в нем не встречалось. Исследование AVN и
>Mouse показало только один подобный сервис.
>
А они не проводили такого исследования.

На данный момент все выглядит так (что бы было понятно):

Mouse заканчивает почтовый интерфейс к BTE, AVN - решает проблемы со 
сборкой, я - тестирую.

Так что обычно на грабли наступаю я сам. Еще была проблема с prein 
скриптами в lubutempter. Но, я уверен  -мы это решим ;-)

>
>  
>
>>>2. Проблема с новыми версиями пакетов, приходящими в систему через incoming.
>>>   В этом случае привходящий пакет подвергается обязательной проверке
>>>   путем установки в UML и сверкой состояний до/после установки.
>>>      
>>>
>>Это уже тянет на "светлое будущее".
>>    
>>
>Ничего сложного, кстати. Мы проводили эксперимент год назад. Все
>замечательно скриптуется.
>
Да, AVN уверяет, что при текущей модели формирования chroot можно будет 
использовать без проблем umlinux.

Rgds,
Rider


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

Re: [devel] BTE

[Alexander Bokovoy]

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

On Tue, Dec 10, 2002 at 02:02:30PM +0300, Dmitry V. Levin wrote:
> > > > > Но у меня все еще тяжелее чем у вас - BTE работает с правами 
> > > > > пользователя. ;-)
> > > > У нас тоже с правами пользователя (еще с весны). Так что к чему этот довод
> > > > -- не понял.
> > > Ваша версия BTE устанавливает пакеты с правами root'а, что есть insecure.
> > Есть идеи как использовать команду chroot без соответствующих привилегий?
> 
> Есть идея использовать chrootuid.
Есть идея этот chrootuid посмотреть повнимательнее. Такой профанации я еще
не встречал. Патч, лечащий профанацию, прилагается. Пакеты
(chrootuid-1.3-alt2) уже отправлены в devel:/incoming/Sisyphus/BTE.

Немного о том, почему здесь не надо использовать syslog. Поскольку
chroot(1) и su(1) пишут ошибки на stderr, то я не вижу необходимости и
утилите, комбинирующей их, писать не на stderr. Более того, очевидно,
именно запись в syslog вместо stderr и привела к пропуску второго ляпсуса,
названного мною выше "профанацией". Хотя, впрочем, как назвать
кардинально неправильное поведение "secure" программы?

-- 
/ Alexander Bokovoy
---
Nobody knows what goes between his cold toes and his warm ears.
		-- Roy Harper

[-- Attachment #2: chrootuid-1.3-alt.patch --]
[-- Type: text/plain, Size: 2628 bytes --]

--- chrootuid-1.3/chrootuid.c.orig	2002-12-11 15:28:44 +0200
+++ chrootuid-1.3/chrootuid.c	2002-12-11 15:42:57 +0200
@@ -50,9 +50,11 @@
 
 #include <unistd.h>
 #include <stdlib.h>
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
 #include <pwd.h>
 #include <grp.h>
-#include <syslog.h>
 
 int     main(argc, argv)
 int     argc;
@@ -65,12 +67,6 @@
      * require only two arguments.
      */
 
-#ifdef LOG_DAEMON
-    (void) openlog(argv[0], LOG_PID | LOG_NDELAY, LOG_DAEMON);
-#else
-    (void) openlog(argv[0], LOG_PID);
-#endif
-
     /*
      * Require proper amount of arguments. In all cases of error, exit with
      * zero status because we have already reported the problem via syslogd.
@@ -78,44 +74,44 @@
      */
 
     if (argc < 4) {
-	syslog(LOG_ERR, "usage: %s path user command", argv[0]);
-	return (0);
+	fprintf(stderr,"usage: %s path user command\n", argv[0]);
+	return (1);
     }
     /* Must step into the new subtree. */
 
     if (chdir(argv[1])) {
-	syslog(LOG_ERR, "chdir(%s): %m", argv[1]);
-	return (0);
+	fprintf(stderr, "chdir(%s): %s\n", argv[1], strerror(errno));
+	return (1);
     }
     /* The user must be known in the *unrestricted* universe... */
 
     if ((pwd = getpwnam(argv[2])) == 0) {
-	syslog(LOG_ERR, "%s: user unknown", argv[2]);
-	return (0);
+	fprintf(stderr, "%s: user unknown\n", argv[2]);
+	return (1);
     }
     /* initgroups() accesses the group file in the unrestricted universe... */
 
     if (initgroups(pwd->pw_name, pwd->pw_gid) < 0) {
-	syslog(LOG_ERR, "initgroups: %m");
-	return (0);
+	fprintf(stderr, "initgroups: %s\n", strerror(errno));
+	return (1);
     }
     endgrent();
 
     /* Do the chroot() before giving away root privileges. */
 
     if (chroot(argv[1])) {
-	syslog(LOG_ERR, "chroot(%s): %m", argv[1]);
-	return (0);
+	fprintf(stderr, "chroot(%s): %s\n", argv[1], strerror(errno));
+	return (1);
     }
     /* Switch group id then user id. */
 
     if (setgid(pwd->pw_gid)) {
-	syslog(LOG_ERR, "setgid(%d): %m", pwd->pw_gid);
-	return (0);
+	fprintf(stderr, "setgid(%d): %s\n", pwd->pw_gid, strerror(errno));
+	return (1);
     }
     if (setuid(pwd->pw_uid)) {
-	syslog(LOG_ERR, "setuid(%d): %m", pwd->pw_uid);
-	return (0);
+	fprintf(stderr, "setuid(%d): %s\n", pwd->pw_uid, strerror(errno));
+	return (1);
     }
     /* In case we still have the /etc/passwd file still open. */
 
@@ -124,6 +120,6 @@
     /* Run the command and hope for the best. */
 
     (void) execv(argv[3], argv + 3);
-    syslog(LOG_ERR, "%s: %m", argv[3]);
-    return (0);
+    fprintf(stderr, "%s: %s", argv[3], strerror(errno));
+    return (1);
 }

Re: [devel] BTE

[AntonFarygin]

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

Alexander Bokovoy пишет:

>On Tue, Dec 10, 2002 at 02:02:30PM +0300, Dmitry V. Levin wrote:
>  
>
>>>>>>Но у меня все еще тяжелее чем у вас - BTE работает с правами 
>>>>>>пользователя. ;-)
>>>>>>            
>>>>>>
>>>>>У нас тоже с правами пользователя (еще с весны). Так что к чему этот довод
>>>>>-- не понял.
>>>>>          
>>>>>
>>>>Ваша версия BTE устанавливает пакеты с правами root'а, что есть insecure.
>>>>        
>>>>
>>>Есть идеи как использовать команду chroot без соответствующих привилегий?
>>>      
>>>
>>Есть идея использовать chrootuid.
>>    
>>
>Есть идея этот chrootuid посмотреть повнимательнее. Такой профанации я еще
>не встречал. Патч, лечащий профанацию, прилагается. Пакеты
>(chrootuid-1.3-alt2) уже отправлены в devel:/incoming/Sisyphus/BTE.
>
>Немного о том, почему здесь не надо использовать syslog. Поскольку
>chroot(1) и su(1) пишут ошибки на stderr, то я не вижу необходимости и
>утилите, комбинирующей их, писать не на stderr. Более того, очевидно,
>именно запись в syslog вместо stderr и привела к пропуску второго ляпсуса,
>названного мною выше "профанацией". Хотя, впрочем, как назвать
>кардинально неправильное поведение "secure" программы?
>
Позволю не согласиться с этим мнением. Коды возврата - да, патчить надо. 
Явно не стоит писать в syslog usage - тоже согласен. А вот другая 
информация в syslog не помешает. (su, кстати, умеет писать в syslog, 
если его собрать с этой фичей). А man chroot - мочить. Более 
информирующего man я еще не встречал. Разве что man yes :-)

Rdgs,
Rider


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

Re: [devel] BTE

[Alexander Bokovoy]

On Wed, Dec 11, 2002 at 05:21:46PM +0300, AntonFarygin wrote:
> >Есть идея этот chrootuid посмотреть повнимательнее. Такой профанации я еще
> >не встречал. Патч, лечащий профанацию, прилагается. Пакеты
> >(chrootuid-1.3-alt2) уже отправлены в devel:/incoming/Sisyphus/BTE.
> >
> >Немного о том, почему здесь не надо использовать syslog. Поскольку
> >chroot(1) и su(1) пишут ошибки на stderr, то я не вижу необходимости и
> >утилите, комбинирующей их, писать не на stderr. Более того, очевидно,
> >именно запись в syslog вместо stderr и привела к пропуску второго ляпсуса,
> >названного мною выше "профанацией". Хотя, впрочем, как назвать
> >кардинально неправильное поведение "secure" программы?
> >
> Позволю не согласиться с этим мнением. Коды возврата - да, патчить надо. 
> Явно не стоит писать в syslog usage - тоже согласен. А вот другая 
> информация в syslog не помешает. (su, кстати, умеет писать в syslog, 
> если его собрать с этой фичей). А man chroot - мочить. Более 
> информирующего man я еще не встречал. Разве что man yes :-)
В состоянии 1.3-alt1 этот пакет просто неработоспособен, если
работоспособность мерить по заявленному в его man.

Что касается syslog -- это мое личное мнение. chroot не может писать в syslog,
как и все утилиты из coreutils, за исключением su. su у нас пишет в syslog
_и_ на stderr, как все в coreutils. По-хорошему, этот механизм надо делать
подобным же.

-- 
/ Alexander Bokovoy
---
All of the packets are empty.

Re: [devel] BTE

[Dmitry V. Levin]

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

On Wed, Dec 11, 2002 at 04:07:36PM +0200, Alexander Bokovoy wrote:
> > Есть идея использовать chrootuid.
> Есть идея этот chrootuid посмотреть повнимательнее. Такой профанации я еще
> не встречал. Патч, лечащий профанацию, прилагается. Пакеты
> (chrootuid-1.3-alt2) уже отправлены в devel:/incoming/Sisyphus/BTE.
> 
> Немного о том, почему здесь не надо использовать syslog. Поскольку
> chroot(1) и su(1) пишут ошибки на stderr, то я не вижу необходимости и

su(1), равно как и другие пользователи pam(8), используют syslog(3).

При этом su пишет и в stderr (не то, что в syslog).

> утилите, комбинирующей их, писать не на stderr. Более того, очевидно,
> именно запись в syslog вместо stderr и привела к пропуску второго ляпсуса,
> названного мною выше "профанацией". Хотя, впрочем, как назвать
> кардинально неправильное поведение "secure" программы?

Полегче с выражениями.
Я чуть было не подумал, что там серьезные ошибки.


--
ldv

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

Re: [devel] BTE

[Alexander Bokovoy]

On Wed, Dec 11, 2002 at 06:34:36PM +0300, Dmitry V. Levin wrote:
> > утилите, комбинирующей их, писать не на stderr. Более того, очевидно,
> > именно запись в syslog вместо stderr и привела к пропуску второго ляпсуса,
> > названного мною выше "профанацией". Хотя, впрочем, как назвать
> > кардинально неправильное поведение "secure" программы?
> 
> Полегче с выражениями.
> Я чуть было не подумал, что там серьезные ошибки.
Для меня эта ошибка -- серьезная, поскольку не дает возможности правильно
реагировать в скриптах на поведение запущенных под chrootuid программами.
Особенно, когда они не найдены из-за того, что chrootuid не смотрит в
отличие от chroot в PATH/default path при запуске.

-- 
/ Alexander Bokovoy
---
Q:	What happens when four WASPs find themselves in the same room?
A:	A dinner party.

Re: [devel] BTE

[Dmitry V. Levin]

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

On Wed, Dec 11, 2002 at 05:42:03PM +0200, Alexander Bokovoy wrote:
> > > утилите, комбинирующей их, писать не на stderr. Более того, очевидно,
> > > именно запись в syslog вместо stderr и привела к пропуску второго ляпсуса,
> > > названного мною выше "профанацией". Хотя, впрочем, как назвать
> > > кардинально неправильное поведение "secure" программы?
> > 
> > Полегче с выражениями.
> > Я чуть было не подумал, что там серьезные ошибки.
> Для меня эта ошибка -- серьезная, поскольку не дает возможности правильно
> реагировать в скриптах на поведение запущенных под chrootuid программами.
> Особенно, когда они не найдены из-за того, что chrootuid не смотрит в
> отличие от chroot в PATH/default path при запуске.

Не все сразу. :)


--
ldv

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

Re: [devel] BTE

[Alexander Bokovoy]

On Wed, Dec 11, 2002 at 07:05:26PM +0300, Dmitry V. Levin wrote:
> > Для меня эта ошибка -- серьезная, поскольку не дает возможности правильно
> > реагировать в скриптах на поведение запущенных под chrootuid программами.
> > Особенно, когда они не найдены из-за того, что chrootuid не смотрит в
> > отличие от chroot в PATH/default path при запуске.
> 
> Не все сразу. :)
:) Программа существует с 1993 года.
-- 
/ Alexander Bokovoy
---
It's not against any religion to want to dispose of a pigeon.
		-- Tom Lehrer, "Poisoning Pigeons in the Park"

Re: [devel] BTE

[Dmitry V. Levin]

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

On Wed, Dec 11, 2002 at 06:26:21PM +0200, Alexander Bokovoy wrote:
> > > Для меня эта ошибка -- серьезная, поскольку не дает возможности правильно
> > > реагировать в скриптах на поведение запущенных под chrootuid программами.
> > > Особенно, когда они не найдены из-за того, что chrootuid не смотрит в
> > > отличие от chroot в PATH/default path при запуске.
> > 
> > Не все сразу. :)
> :) Программа существует с 1993 года.

Скажи это автору. В Сизифе она меньше месяца.


--
ldv

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

Re: [devel] BTE

[Alexander Bokovoy]

On Wed, Dec 11, 2002 at 07:48:42PM +0300, Dmitry V. Levin wrote:
> On Wed, Dec 11, 2002 at 06:26:21PM +0200, Alexander Bokovoy wrote:
> > > > Для меня эта ошибка -- серьезная, поскольку не дает возможности правильно
> > > > реагировать в скриптах на поведение запущенных под chrootuid программами.
> > > > Особенно, когда они не найдены из-за того, что chrootuid не смотрит в
> > > > отличие от chroot в PATH/default path при запуске.
> > > 
> > > Не все сразу. :)
> > :) Программа существует с 1993 года.
> Скажи это автору. В Сизифе она меньше месяца.
Дык я скорее про автора и возмущаюсь. А претензии к сборщику только в
пропуске кодов возврата в случае ошибок. :)

-- 
/ Alexander Bokovoy
---
I have a very strange feeling about this...
		-- Luke Skywalker