[devel] Q: Текущее состояние web policy (идеи для bugzilla)

[devel] Q: Текущее состояние web policy (идеи для bugzilla)

[Aleksey Avdeev]

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

   В связи с очередным подходом к bugzilla (для внутренних проектов, 
с небольшим количеством участников, требуется возможность перевесить 
баг на пользователя из списка -- разумеется, данная фича будет 
отключаемой) интересует текущее состояние web policy (и скриптов 
поддержки).

   На данный момент задумка такая:

1. Ставить bugzilla в /usr/share/bugzilla/x.y.z.

Т. к. БД разных версий между собой несовместимы, а преобразование 
односторонние -- требуется обеспечение одновременной установки 
нескольких версий. Обновление bugzilla конкретного сайта -- планирую 
отдать на откуп его вебмастера.

2. Иметь скрипты для установки (обновления) приложения 
непосредственно на сайт его администратором.

Помню разговор (в контексте web policy) о создании скриптов 
перемещения web приложений на нужное место через копирование файлов 
и/или выставление симлинков по списку. Немогу найти, чем он 
закончился. (Помню что-то про пакет их содержащий... Но немогу его 
найти.)

3. Обеспечение работы приложения под обоими apache.

Сдесь пока вижу загвозтку с конфигурационными фалами (localconfig и 
.htaccess в частности): желательно обеспечить доступ только 
вебсерверу (ro) и администратору сайта (rw). В случаи одного apache 
-- решение видно:

640 <админ>:apache <файл>

Но у нас есть apache и apache2 и нет группы содержащей их обоих... 
Как быть в таком случаи (без создания общей для веб серверов группы) 
-- я незнаю.

4. Обеспечить работоспособность под mod_perl. (В перспективе: пока 
mod_perl для меня -- тёмный лес.)

-- 

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

Re: [devel] Q: Текущее состояние web policy (идеи для bugzilla)

[Ivan Fedorov]

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

Aleksey Avdeev пишет:
> Здравствуйте.

> 3. Обеспечение работы приложения под обоими apache.
> 
> Сдесь пока вижу загвозтку с конфигурационными фалами (localconfig и
> .htaccess в частности): желательно обеспечить доступ только вебсерверу
> (ro) и администратору сайта (rw). В случаи одного apache -- решение видно:
> 
> 640 <админ>:apache <файл>
> 
> Но у нас есть apache и apache2 и нет группы содержащей их обоих... Как
> быть в таком случаи (без создания общей для веб серверов группы) -- я
> незнаю.


Внедрить ACL.


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

Re: [devel] Q: Текущее состояние web policy (идеи для bugzilla)

[Aleksey Avdeev]

Ivan Fedorov пишет:
> Aleksey Avdeev пишет:
> 
>>Здравствуйте.
> 
> 
>>3. Обеспечение работы приложения под обоими apache.
>>
>>Сдесь пока вижу загвозтку с конфигурационными фалами (localconfig и
>>.htaccess в частности): желательно обеспечить доступ только вебсерверу
>>(ro) и администратору сайта (rw). В случаи одного apache -- решение видно:
>>
>>640 <админ>:apache <файл>
>>
>>Но у нас есть apache и apache2 и нет группы содержащей их обоих... Как
>>быть в таком случаи (без создания общей для веб серверов группы) -- я
>>незнаю.
> 
> 
> 
> Внедрить ACL.

   В пакет? Не думаю, что стоит на него завязываться: сдесь общей 
группы достаточно.

-- 

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

[devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Michael Shigorin]

[-- Attachment #1.1: Type: text/plain, Size: 2536 bytes --]

On Thu, Sep 01, 2005 at 04:02:32PM +0400, Aleksey Avdeev wrote:
> интересует текущее состояние web policy (и скриптов поддержки).

Так и не добрался посмотреть на farmer, но с тех пор подсунули
ещё кой-чего интересного и наведшего на мысли.

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

farmer? (так и не появился ни в Daedalus, ни в Sisyphus AFAICS)

http://lists.altlinux.ru/pipermail/devel/2005-March/018792.html
http://lists.altlinux.ru/pipermail/devel/2005-March/018785.html
http://lists.altlinux.ru/pipermail/devel/2005-March/018673.html


Мне тут местные гентуводы показывали на той неделе, как сделано
у них -- нарисован helper по имени webapp-config, который умеет
различать помеченное как "конфиг" ("индивидуальное") и копировать
(не симлинковать или ещё как, а именно тупо копировать) всё
остальное по виртхостам при обновлении.

http://www.gentoo.org/cgi-bin/viewcvs.cgi/net-www/webapp-config/


В дебиане (спасибо подсказавшим) тоже сдвинулось с мёртвой точки
где-то двухлетней давности:

http://alioth.debian.org/projects/webapps-common/
http://alioth.debian.org/projects/webapppolicy/
http://lists.alioth.debian.org/mailman/listinfo/webapps-common-discuss
http://lists.debian.org/debian-devel/2005/05/msg00075.html

Видимо, заинтересованным (или хотя бы одному из нас) имеет смысл
сходить в гости и натырить идей, коль скоро там они проросли
быстрее.


С другой стороны, у нас есть update_chrooted, который можно
попробовать приспособить для этой задачи.


> 3. Обеспечение работы приложения под обоими apache.
[...]
> 640 <админ>:apache <файл>
> Но у нас есть apache и apache2 и нет группы содержащей их
> обоих...  Как быть в таком случаи (без создания общей для веб
> серверов группы) -- я незнаю.

Создать группу, в которую входят оба апача (видимо, пригласить
apache2 в apache соответствующим FR).

> 4. Обеспечить работоспособность под mod_perl. (В перспективе:
> пока mod_perl для меня -- тёмный лес.)

Буду признателен за помощь, см. тж. README.ALT -- там ссылки 
на баги, их обсуждение и краткое описание выводов.

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

[-- Attachment #1.2: farmer --]
[-- Type: text/plain, Size: 3783 bytes --]

#!/usr/bin/perl

use strict;

my %config = (
		"confFiles"=> ["config/*php.dist","config/conf.xml"]
	);

my $debug = 1;

unless($#ARGV == 1) {
	DEBUG(1,"usage: $0 sourceDir destinationDir");
	exit;
}

unless (-e $ARGV[0] && -e $ARGV[1]) {
	DEBUG(0,"sourceDir $ARGV[0] or destinationDir $ARGV[1] not exist");
	exit(1);
}

unless (&farmer($ARGV[0],$ARGV[1])) {
	DEBUG(0,"Cloning failed");
}


sub farmer {

	my $from = shift;
	my $to = shift;
	my %FROM = ();
	
	unless ( -d $from ) {
		&DEBUG($from." not exist or not directory");
		return undef;
	}
	
	if (! -e $to ) {
		unless ($config{"confFiles"}) {
			symlink $from,$to;
			return "true";
		} else {
			mkdir $to,0755;
		}
	} elsif (! -d $to) {
		DEBUG(0,"$to exist but not directory");
		return undef;
	}

	foreach my $conf (@{$config{confFiles}}) {
		$conf =~ s/\*/[^\/]*/g;
		$conf =~ s/(\.|\?)/\\$1/g;
		$conf =~ s/^\///;
		$conf =~ s/\/$//;
	}

	my $dir = "";
	my %cdir = ();
	my @dirs = ();
	
	do {
		unless ( opendir(DIR,$from."/".$dir) ){
			DEBUG(0, "Can not open dir $from.$dir: $!");
			return undef;
		}
		foreach ( grep {! /\.{1,2}$/ } readdir(DIR)) {
			if ( -f $from."/".$dir."/".$_ ){
				$FROM{$dir."/".$_} = "f". &checkCf($dir."/".$_,\%cdir);
			} elsif ( -d $from."/".$dir."/".$_ ) {
				$FROM{$dir."/".$_} = "d". &checkCf($dir."/".$_,\%cdir);
				push @dirs,$dir."/".$_;
			} else {
				DEBUG(1, "$_ not file or directory. Skip it.");
			}
		}
		close(DIR);
		$dir = shift @dirs;
	} while ($dir);

	my @list = sort keys %FROM;

	foreach my $file (@list) {

		if (exists $cdir{$file} || $FROM{$file} eq "dc"){
			if ( -e $to.$file ) {
				if ( -l $to.$file ) {
					unlink $to.$file;
				} elsif (! -d $to.$file) {
					DEBUG(1,"$file is not a dir. Something wrong. Try to backUp");
					unless (&backUp($to.$file)) {
						return undef;
					};
				}
			}
			my ($mode,$uid,$gid) = (stat($from.$file))[2,4,5];
			mkdir $to.$file, $mode;
			chown $uid,$gid,$to.$file;
		} elsif ($FROM{$file} eq "fc") {
			if ( -l $to.$file ) {
				unlink $to.$file;
			} elsif ( -e $to.$file ) {
				next;
			}
			system("cp","-p",$from.$file,$to.$file);
		} elsif ($FROM{$file} eq "d") {
			if ( -l $to.$file ) {
				unlink $to.$file;
			} elsif ( -d $to.$file ) {
				DEBUG(1, "$file is a dir. Can not link it. Try to backUp");
				next unless (&backUp($to.$file));
			} elsif (-e $to.$file ) {
				DEBUG(1,"$file not dir. Try to backUp");
				unless (&backUp($to.$file)) {
					return undef;
				}
			}
			symlink($from.$file,$to.$file);
			foreach my $empty ( grep { /^$file\/.+/ } @list ){
				$FROM{$empty} = "empty";
			}

		} elsif ($FROM{$file} eq "f") {
			if (-l $to.$file) {
				unlink($from.$to);
			} elsif ( -e $to.$file) {
				next unless (&backUp($to.$file));
			}
			symlink($from.$file,$to.$file);
		}
	}

	return "ok";

}

sub checkCf {
	my $file = shift;
	my $dir = shift;
	my $ret = undef;
	my @tmp = ();
	foreach my $cnf (@{$config{confFiles}}) {
		next unless ($file =~ /^\/$cnf$/ || $file =~ /^\/$cnf\/.+$/ );
		$ret = "c";
		@tmp = split(/\//, $file);
		shift @tmp; pop @tmp;
		foreach (@tmp) {
			next if (exists ${$dir}{"/".$_});
			${$dir}{"/".$_} = "c";
		}
	}
	return $ret;
}

sub DEBUG {
	my $level = shift;
	my $message = shift;

        if ($level == 0) {
		print STDERR $message."\n";
	} elsif ($level <= $debug) {
		print $message."\n";
	}
}

sub backUp {
	my $file = shift;
	my $backup = $file.".farmer-save";
	
	if (-d $backup) {
		system("rm","-rf",$backup);
	} elsif ( -f $backup || -l $backup) {
		unlink $backup;
	} elsif ( -e $backup) {
		return undef;	
	}

	system("mv",$file,$backup);

	return "ok";	
}

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

Re: [devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Vladimir Lettiev]

Michael Shigorin пишет:

>>2. Иметь скрипты для установки (обновления) приложения 
>>непосредственно на сайт его администратором.
>>Помню разговор (в контексте web policy) о создании скриптов
>>перемещения web приложений на нужное место через копирование
>>файлов и/или выставление симлинков по списку. Немогу найти, чем
>>он закончился. (Помню что-то про пакет их содержащий... Но
>>немогу его найти.)
> 
> farmer? (так и не появился ни в Daedalus, ни в Sisyphus AFAICS)
> 
> http://lists.altlinux.ru/pipermail/devel/2005-March/018792.html
> http://lists.altlinux.ru/pipermail/devel/2005-March/018785.html
> http://lists.altlinux.ru/pipermail/devel/2005-March/018673.html

Йолки-палки, прочитал и понял, что забыл тогда сообщить имя пакета: wacs 
- лежит в Daedalus...

http://lists.altlinux.ru/pipermail/sisyphus/2005-March/054733.html
http://lists.altlinux.ru/pipermail/sisyphus/2005-May/058958.html

Дело принципа, надо эту штукенцию доделать, к тому же я её доделал (в 
плане создания жёстких ссылок), только не запакетил и не обновил 
документацию. Ща гляну архивы.

-- 
С уважением, Владимир Леттиев aka crux <crux@gorodmasterov.com>

[devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Michael Shigorin]

On Thu, Sep 01, 2005 at 07:18:33PM +0400, Vladimir Lettiev wrote:
> >farmer? (так и не появился ни в Daedalus, ни в Sisyphus AFAICS)
> >http://lists.altlinux.ru/pipermail/devel/2005-March/018792.html
> >http://lists.altlinux.ru/pipermail/devel/2005-March/018785.html
> >http://lists.altlinux.ru/pipermail/devel/2005-March/018673.html
> Йолки-палки, прочитал и понял, что забыл тогда сообщить имя
> пакета: wacs - лежит в Daedalus...

О как.  Значит, fgrep farmer Sisyphus/i586/base/contents_index
тоже бы не помог. :)

> Дело принципа, надо эту штукенцию доделать, к тому же я её
> доделал (в плане создания жёстких ссылок), только не запакетил
> и не обновил документацию. Ща гляну архивы.

Не, из принципа не надо.  Если дело _нужное_ для текущих задач, 
то разумно.  Иначе пусть подбирают те, кому припекло следующим
:-)

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

Re: [devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Aleksey Avdeev]

Vladimir Lettiev пишет:
> Michael Shigorin пишет:
> 
>>> 2. Иметь скрипты для установки (обновления) приложения 
>>> непосредственно на сайт его администратором.
>>> Помню разговор (в контексте web policy) о создании скриптов
>>> перемещения web приложений на нужное место через копирование
>>> файлов и/или выставление симлинков по списку. Немогу найти, чем
>>> он закончился. (Помню что-то про пакет их содержащий... Но
>>> немогу его найти.)
>>
>>
>> farmer? (так и не появился ни в Daedalus, ни в Sisyphus AFAICS)
>>
>> http://lists.altlinux.ru/pipermail/devel/2005-March/018792.html
>> http://lists.altlinux.ru/pipermail/devel/2005-March/018785.html
>> http://lists.altlinux.ru/pipermail/devel/2005-March/018673.html
> 
> 
> Йолки-палки, прочитал и понял, что забыл тогда сообщить имя пакета: wacs 
> - лежит в Daedalus...

   Спасибо. То что надо (в первом приближении ;-)).

> 
> http://lists.altlinux.ru/pipermail/sisyphus/2005-March/054733.html
> http://lists.altlinux.ru/pipermail/sisyphus/2005-May/058958.html

   Видел, я эти письма. Только не смог найти, когда оно потребовалось...

> 
> Дело принципа, надо эту штукенцию доделать, к тому же я её доделал (в 
> плане создания жёстких ссылок), только не запакетил и не обновил 
> документацию. Ща гляну архивы.
> 

   Есть несколько вопросов по скрипту:

1. Можно ли поставить в один виртуальный сервер одно приложение 
несколько раз, в каталоги с разными именами? Параметры --vhost и 
--webAppRoot вселяют надежду, но смущает "Includes 
conf/wacs/%vhost-%name.conf" упоминаемый в документации.

2. Осуществляется ли копирование файла, при невозможности создать 
жёсткую ссылку?

   Несколько идей, для дальнейшего развития данного проекта (из 
того, что для меня актуально :-)):

1. Возможность для wacs "забыть" про установленное приложение при 
обновлениях rpm пакета его содержащего. Существенно для приложений 
требующих большой ручной доточки после инсталляции: их желательно 
обновлять только по явному пинку администратора.

2. Возможность поставить несколько идентичных приложений "рядом" -- 
в общий DocumentRoot, но с разным webAppRoot (отличными от 
умолчальных). Существенно для тестирования приложений при их ручной 
доточке.

3. Возможность указать, для каких файлов использовать симлинки 
вместо жёстких ссылок/копий. Это для тех приложений -- которые их 
переживают. (Точнее для их мантейнеров. :-)) Если приложение 
поставлено с запретом на автообновления (п. 1) то симлинки 
заменяются на жёсткие ссылки/копии.

PS: Пока не пойму на сколько применима (удобна) идея изложеная 
webapp-common (приложения в каталогах соответствующих языку 
реализации)... А нужно ли оно вообще?

-- 

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

[devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Michael Shigorin]

On Fri, Sep 02, 2005 at 02:29:30PM +0400, Aleksey Avdeev wrote:
> 1. Возможность для wacs "забыть" про установленное приложение
> при обновлениях rpm пакета его содержащего. Существенно для
> приложений требующих большой ручной доточки после инсталляции:
> их желательно обновлять только по явному пинку администратора.

Есть обдуманное мнение, что такие паковать бессмысленно.

> 3. Возможность указать, для каких файлов использовать симлинки
> вместо жёстких ссылок/копий. Это для тех приложений -- которые
> их переживают. (Точнее для их мантейнеров. :-)) Если приложение
> поставлено с запретом на автообновления (п. 1) то симлинки
> заменяются на жёсткие ссылки/копии.

Копии.

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

Re: [devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Aleksey Avdeev]

Michael Shigorin пишет:
> On Fri, Sep 02, 2005 at 02:29:30PM +0400, Aleksey Avdeev wrote:
> 
>>1. Возможность для wacs "забыть" про установленное приложение
>>при обновлениях rpm пакета его содержащего. Существенно для
>>приложений требующих большой ручной доточки после инсталляции:
>>их желательно обновлять только по явному пинку администратора.
> 
> 
> Есть обдуманное мнение, что такие паковать бессмысленно.

   Думаю, что смысл всётаки есть:

1. "Стандартное" состояние пакета будет зафиксированным (в том виде 
-- как его видит мантейнер) и повторяемым. Кого-то оно может и 
устроит. :-) У остальных -- появится отправная точка к которой можно 
привязывать улучшения, если стандартный вариант не устраивает.

2. В той-же bugzilla изменить можно многое: от замены картинок, до 
корректировки кода/шаблонов. Оформлять всё это как конфиги? Недумаю, 
что нужно. Но лазейку для тех, кто полезет всё менять -- оставить 
стоит... Но прикрытее собственной задницы при этом будет нелишним. :-)

> 
> 
>>3. Возможность указать, для каких файлов использовать симлинки
>>вместо жёстких ссылок/копий. Это для тех приложений -- которые
>>их переживают. (Точнее для их мантейнеров. :-)) Если приложение
>>поставлено с запретом на автообновления (п. 1) то симлинки
>>заменяются на жёсткие ссылки/копии.
> 
> 
> Копии.
> 

   Скорее да.

-- 

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

[devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Michael Shigorin]

On Fri, Sep 02, 2005 at 04:47:06PM +0400, Aleksey Avdeev wrote:
> >Есть обдуманное мнение, что такие паковать бессмысленно.
> Думаю, что смысл всётаки есть:

Мнение было обдумано с учётом исторической параллели --
линуксовый софт бессмысленно было как угодно паковать с целью 
в т.ч. контроля целостности, пока установка подразумевала
прилежное вождение напильником по коду.

Соответственно софт, который в таком же детском состоянии сейчас,
точно так же бессмысленно паковать.

С другой стороны, уже немало софта подобным образом упаковано 
в том же Gentoo (см. требующих webapp-common) и будет -- в Debian,
поэтому ареал софта, где хаки по месту -- не норма жизни, должен
потихоньку расти.

> 1. "Стандартное" состояние пакета будет зафиксированным (в том
> виде -- как его видит мантейнер) и повторяемым. Кого-то оно
> может и устроит. :-) У остальных -- появится отправная точка к
> которой можно привязывать улучшения, если стандартный вариант
> не устраивает.

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

Думал было для freshmeat написать editorial на эту тему,
но в процессе совсем стало грустно от того, что положительных
героев нашлось действительно аж два.  Это которые вообще не
требуют копирования основной части кода, позволяя обойтись 
одним симлинком.

> 2. В той-же bugzilla изменить можно многое: от замены картинок,
> до корректировки кода/шаблонов. Оформлять всё это как конфиги?

Да, конечно.

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

Re: [devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Денис Смирнов]

On Fri, Sep 02, 2005 at 05:43:47PM +0300, Michael Shigorin wrote:

MS> Думал было для freshmeat написать editorial на эту тему,
MS> но в процессе совсем стало грустно от того, что положительных
MS> героев нашлось действительно аж два.  Это которые вообще не
MS> требуют копирования основной части кода, позволяя обойтись 
MS> одним симлинком.

Кто второй?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> А что там [в категории insecure] будет? [...]
Потенциально небезопасный софт за которым внимательно следить security
team не будет.
		-- mrkooll in devel@

[devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Michael Shigorin]

On Sat, Sep 03, 2005 at 02:18:27AM +0400, Денис Смирнов wrote:
> MS> Думал было для freshmeat написать editorial на эту тему,
> MS> но в процессе совсем стало грустно от того, что положительных
> MS> героев нашлось действительно аж два.  Это которые вообще не
> MS> требуют копирования основной части кода, позволяя обойтись 
> MS> одним симлинком.
> Кто второй?

drupal

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

Re: [devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Igor Zubkov]

В сообщении от Суббота, 03-Сен-2005 12:25 Michael Shigorin написал(a):
> On Sat, Sep 03, 2005 at 02:18:27AM +0400, Денис Смирнов wrote:
> > MS> Думал было для freshmeat написать editorial на эту тему,
> > MS> но в процессе совсем стало грустно от того, что положительных
> > MS> героев нашлось действительно аж два.  Это которые вообще не
> > MS> требуют копирования основной части кода, позволяя обойтись
> > MS> одним симлинком.
> > Кто второй?
>
> drupal

Первый, это Typo3?

-- 
Now playing: АРИЯ - Ворон

[devel] [JT] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Michael Shigorin]

On Wed, Sep 07, 2005 at 03:27:32PM +0300, Igor Zubkov wrote:
> > > Кто второй?
> > drupal
> Первый, это Typo3?

Угу.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
 ----       visit our conference (Oct 1):
--          http://conference.osdn.org.ua

Re: [devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Денис Смирнов]

On Fri, Sep 02, 2005 at 03:09:05PM +0300, Michael Shigorin wrote:
>> 1. Возможность для wacs "забыть" про установленное приложение
>> при обновлениях rpm пакета его содержащего. Существенно для
>> приложений требующих большой ручной доточки после инсталляции:
>> их желательно обновлять только по явному пинку администратора.
MS> Есть обдуманное мнение, что такие паковать бессмысленно.

У typo3 полная обратная совместимость, кстати?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> nspr развивается в рамках мозиллы. В ее CVS лежит более свежая версия
> и она постоянно обновляется.
Там самый большой объем обновлений -- copyright в каждом файле. :)
		-- at in devel@

[devel] Re: Q: Текущее состояние web policy (идеи для bugzilla)

[Michael Shigorin]

On Fri, Sep 02, 2005 at 05:35:43PM +0400, Денис Смирнов wrote:
> >> 1. Возможность для wacs "забыть" про установленное приложение
> >> при обновлениях rpm пакета его содержащего. Существенно для
> >> приложений требующих большой ручной доточки после инсталляции:
> >> их желательно обновлять только по явному пинку администратора.
> MS> Есть обдуманное мнение, что такие паковать бессмысленно.
> У typo3 полная обратная совместимость, кстати?

Не знаю.  По крайней мере скриптик-обновлялку базы пнуть после
этого самого обновления кода -- a must, т.е. автоматического
процесса совсем бесплатно не получается.

Возможно, такие действия и получится автоматизировать при помощи
php-cgi, но что с виртхостами и прочим HTTP-окружением?

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

Re: [devel] Q: Текущее состояние web policy (идеи для bugzilla)

[Alexey Borovskoy]

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

* Пятница 02 Сентябрь 2005 01:02 Aleksey Avdeev

> Здравствуйте.
>
>    В связи с очередным подходом к bugzilla (для внутренних
> проектов, с небольшим количеством участников, требуется
> возможность перевесить баг на пользователя из списка --
> разумеется, данная фича будет отключаемой) интересует текущее
> состояние web policy (и скриптов поддержки).
>
>    На данный момент задумка такая:
>
> 1. Ставить bugzilla в /usr/share/bugzilla/x.y.z.

webapp-common в backports. Там минимальный набор каталогов.

-- 
Алексей.
GPG key fingerprint
DBB3 1832 13C6 5C96 4A58  4AFF 78F7 159F 66AD 8D7E

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