Re: openvpn unrevoke сертиф иката
On 2009.08.28 at 16:18:36 +0400, Andrey N. Prokofiev wrote: День добрый! Возможно ли каким-либо образом сделать unrevoke сертификата пользователя? У openssl ca в ключике -crl_reason есть возможное значение removeFromCRL -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Правильные демоны - не демоны?
Hello! On Saturday 29 August 2009 05:19:24 Artem Chuprina wrote: AP Лучшие тестеры - сами пользователи. Вот насчет лучшие - это ты загнул. Сотня пользователей не заменяет одного профессионального тестировщика. Обратное, впрочем, тоже верно. Профессиональный тестировщик проверяет на соответствие ТЗ, а пользователь пытается употребить ПО для решения своих задач, и зачастую разными изощренными способами. Так что тестирование пользователями позволяет и ТЗ привести в соответствие с реальными потребностями, а не идеями менеджеров. Получается, без тестировщика трудно понять, сделано ли то, что должно быть сделано, а без пользователей - применимо ли сделанное для решения требуемых задач. P.S. Иногда встречаются пользователи, которые лучше любого тестировщика проверяют - то ли им так не везет и все грабли на них срабатывают, то ли это талант :-) Best regards, Alexey Pechnikov. http://pechnikov.tel/
Безопасность chroot
Hello! Предлагаю в противовес применению виртуалок обсудить возможности полных chroot-окружений (т.е. с целой системой, созданной, к примеру, debootstrap или скопированной с работающей машины). Чрут с бинарем и парой библиотек имхо особого интереса не представляет, т.к. или работает без проброшенных ФС, или сводится к полному варианту. Интересны вопросы использования примонтированного /proc, /dev/pts, etc. Как пример: каким образом запретить отрабатывание init 0 в чруте c монтированным /proc? Разумеется, интересует не банальное удаление бинаря, а ограничение возможности посылать сообщения внешним процессам. Есть и идеологические вопросы: является ли прикладное ПО, требующее /proc для работы, правильно спроектированным? Например, постгрес требует /proc, но его работа с гигабайтами shared memory мне кажется дурной практикой, сохранившейся со времен мэйнфреймов. Огромная просьба ко всем - не нужно упирать на программные ошибки, которые временами обнаруживаются и позволяют выходить из чрут. Технология chroot давняя и достаточно стабильная, чтобы использоваться в продакшене, чего не скажешь о многих виртуалках. А вот как ею пользоваться грамотно, и хотелось бы узнать подробнее. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Безопасность chroot
On Sat, Aug 29, 2009 at 01:02:33PM +0400, Alexey Pechnikov wrote: Предлагаю в противовес применению виртуалок обсудить возможности полных chroot-окружений (т.е. с целой системой, созданной, к примеру, debootstrap или скопированной с работающей машины). Чрут с бинарем и парой библиотек имхо особого интереса не представляет, т.к. или работает без проброшенных ФС, или сводится к полному варианту. Интересны вопросы использования примонтированного /proc, /dev/pts, etc. Как пример: каким образом запретить отрабатывание init 0 в чруте c монтированным /proc? Если тебя это волнует, то очевидно ты в чруте собираешься запускать процессы от рута. На этом можно смело закрыть тему. -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Безопасность chroot
Hello! On Saturday 29 August 2009 13:39:59 Stanislav Maslovski wrote: Как пример: каким образом запретить отрабатывание init 0 в чруте c монтированным /proc? Если тебя это волнует, то очевидно ты в чруте собираешься запускать процессы от рута. На этом можно смело закрыть тему. Умеете init запускать не от рута? Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Безопасность chroot
On Sat, Aug 29, 2009 at 01:59:13PM +0400, Alexey Pechnikov wrote: Hello! On Saturday 29 August 2009 13:39:59 Stanislav Maslovski wrote: Как пример: каким образом запретить отрабатывание init 0 в чруте c монтированным /proc? Если тебя это волнует, то очевидно ты в чруте собираешься запускать процессы от рута. На этом можно смело закрыть тему. Умеете init запускать не от рута? Еще одно подтверждение того, что ты действительно собираешься запускать процессы от рута в чруте. Еще раз повторю, что про обозначенную в сабже тему в таком случае можно смело забыть. -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Безопасность chroot
On Sat, Aug 29, 2009 at 02:33:34PM +0400, Alexey Pechnikov wrote: Hello! On Saturday 29 August 2009 14:21:35 Stanislav Maslovski wrote: Еще одно подтверждение того, что ты действительно собираешься запускать процессы от рута в чруте. Еще раз повторю, что про обозначенную в сабже тему в таком случае можно смело забыть. Ровно так, как можно забыть о безопасности сервера, подключенного к интернет. У тебя весьма оригинальные взгляды на безопасность в целом и на сетевую безопасность в частности. Возвращаясь к топику, я бы рекомендовал тебе для начала прочесть что-нибудь общего плана о том, что же такое чрут. Начни со статьи на википедии: http://en.wikipedia.org/wiki/Chroot -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Безопасность chroot
On Sat, Aug 29, 2009 at 02:33:34PM +0400, Alexey Pechnikov wrote: Hello! On Saturday 29 August 2009 14:21:35 Stanislav Maslovski wrote: Еще одно подтверждение того, что ты действительно собираешься запускать процессы от рута в чруте. Еще раз повторю, что про обозначенную в сабже тему в таком случае можно смело забыть. Ровно так, как можно забыть о безопасности сервера, подключенного к интернет. Просто подумай о том, что никакой chroot не отменяет вызовы ядра, которыми можно сделать все. В отличии от виртуалки. Поэтому chroot в котором работают под root и не имеет смысла. И chroot в котором достаточно полная система, чтобы обеспечить эскалацию привилегий тоже смысла не имеет. Для целей безопасности, разумеется. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Безопасность chroot
Hello! On Saturday 29 August 2009 14:21:35 Stanislav Maslovski wrote: Еще одно подтверждение того, что ты действительно собираешься запускать процессы от рута в чруте. Еще раз повторю, что про обозначенную в сабже тему в таком случае можно смело забыть. Ровно так, как можно забыть о безопасности сервера, подключенного к интернет. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Безопасность chroot
Hello! On Saturday 29 August 2009 14:43:46 Stanislav Maslovski wrote: On Sat, Aug 29, 2009 at 02:33:34PM +0400, Alexey Pechnikov wrote: Hello! On Saturday 29 August 2009 14:21:35 Stanislav Maslovski wrote: Еще одно подтверждение того, что ты действительно собираешься запускать процессы от рута в чруте. Еще раз повторю, что про обозначенную в сабже тему в таком случае можно смело забыть. Ровно так, как можно забыть о безопасности сервера, подключенного к интернет. У тебя весьма оригинальные взгляды на безопасность в целом и на сетевую безопасность в частности. Возвращаясь к топику, я бы рекомендовал тебе для начала прочесть что-нибудь общего плана о том, что же такое чрут. Начни со статьи на википедии: http://en.wikipedia.org/wiki/Chroot Больше вам нечего сказать? Если вы хотите загаживать основную систему результатами разных экспериментов, ваше дело. Если вы хотите опробовать новую систему инициализации на основном сервере, рискуя навсегда потерять к нему доступ после перезагруки, это ваши проблемы. Но это не значит, что все должны так же на авось действовать. А раз уж у меня есть разные chroot для разных задач, то мне интересно разобраться в этой технологии подробнее. Вам не интересно - так ведь никто не заставляет. При отмонтированном /proc и у рута в чруте возможности сильно ограничены. И уж тем более сбой программы в чруте не повлияет на основную систему, даже если эта программа изначальна запущена инит-процессом с рутовыми привелегиями. Посему постарайтесь по существу говорить. Или подождем Артема, который в соседнем топике обещал на эту тему кое-что рассказать, если будет задан вопрос. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Безопасность chroot
On Sat, Aug 29, 2009 at 03:11:31PM +0400, Alexey Pechnikov wrote: Hello! On Saturday 29 August 2009 14:43:46 Stanislav Maslovski wrote: On Sat, Aug 29, 2009 at 02:33:34PM +0400, Alexey Pechnikov wrote: Hello! On Saturday 29 August 2009 14:21:35 Stanislav Maslovski wrote: Еще одно подтверждение того, что ты действительно собираешься запускать процессы от рута в чруте. Еще раз повторю, что про обозначенную в сабже тему в таком случае можно смело забыть. Ровно так, как можно забыть о безопасности сервера, подключенного к интернет. У тебя весьма оригинальные взгляды на безопасность в целом и на сетевую безопасность в частности. Возвращаясь к топику, я бы рекомендовал тебе для начала прочесть что-нибудь общего плана о том, что же такое чрут. Начни со статьи на википедии: http://en.wikipedia.org/wiki/Chroot Больше вам нечего сказать? Если вы хотите загаживать основную систему результатами разных экспериментов, ваше дело. Если вы хотите опробовать новую систему инициализации на основном сервере, рискуя навсегда потерять к нему доступ после перезагруки, это ваши проблемы. Но это не значит, что все должны так же на авось действовать. А раз уж у меня есть разные chroot для разных задач, то мне интересно разобраться в этой технологии подробнее. Так а я о чем - разбирайся. Меньше будет пустого шума в debian-russian. Вам не интересно - так ведь никто не заставляет. При отмонтированном /proc и у рута в чруте возможности сильно ограничены. Что помешает руту подмонтировать /proc обратно? И уж тем более сбой программы в чруте не повлияет на основную систему, даже если эта программа изначальна запущена инит-процессом с рутовыми привелегиями. Сколько не говори сладко, во рту слаще не станет. Посему постарайтесь по существу говорить. Чем я и занимаюсь, указывая на твои грубые ошибки (связанные с недостатком знаний/понимания). Если тебя это раздражает - настрой procmail. -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Безопасность chroot
Hello! On Saturday 29 August 2009 15:06:56 Иван Лох wrote: Просто подумай о том, что никакой chroot не отменяет вызовы ядра, которыми можно сделать все. В отличии от виртуалки. Поэтому chroot в котором работают под root и не имеет смысла. И chroot в котором достаточно полная система, чтобы обеспечить эскалацию привилегий тоже смысла не имеет. Для целей безопасности, разумеется. 1) selinux и подобные решения могут запретить сделать все. Это конкретно к вопросу о запуске init 0 в чруте - даже если пользователю удалось повысить свои привелегии, что может произойти и на основной системе. Однако в чруте, вероятно, можно и какие-то другие техники применить, вот и вопрос - какие? 2) Запуск от рута одного init-процесса в чруте еще не дает возможности пользователям и приложениям получить права рута. И работать от рута абсолютно не то же самое, что иметь запущенные в системе процессы от рута (которые, кстати, есть во всех линуксах, но это не отменяет возможность и необходимость защиты системы). 3) Обеспечить эскалацию привелегий - это не проблема чрута как технологии, хотя бы потому, что многие гипервизоры это тоже позволяют. Так что виртуалка на практике не надежнее чрута, а скорее, наоборот, т.к. добавляется много лишнего кода, работающего с высшими привелегиями. В чруте, например, можно не монтировать /proc, что, насколько я понимаю, сделает невозможным вызов init 0. На виртуалке же вы и такой возможности не имеете. А вот что нужно отрезать в чруте, чтобы блокировать означенную угрозу, как раз и представляет интерес. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Безопасность chroot
Hello! On Saturday 29 August 2009 15:23:25 Stanislav Maslovski wrote: Вам не интересно - так ведь никто не заставляет. При отмонтированном /proc и у рута в чруте возможности сильно ограничены. Что помешает руту подмонтировать /proc обратно? Пусть есть запущенный от рута процесс init. Как от юзера www-data подмонтировать /proc, воспользовавшись привелегиями процесса init? Вы серьезно считаете, что системный init или runit такие дырявые? Может, я чего-то не знаю, но мне это кажется очень маловероятным. Если есть такая проблема, то придется selinux и проч. использовать, как я уже упоминал в другом сообщении. Но я полагаю, что это не так. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Безопасность chroot
В сообщении от Saturday 29 of August 2009 16:02:33 Alexey Pechnikov написал(а): Hello! Предлагаю в противовес применению виртуалок обсудить возможности рассуждать о безопастности чего-то в чем-то можно долго. так же как рассуждать о просто безопастности. но лучше всего рассуждать о чем-то где-то и непонятно для чего. -- Чтоб ты жил на одну рекламу.
Re: Безопасность chroot
Hello! Уточняю - пользователь в чруте рута не имеет! Но есть процессы, запущенные от рута, и потенциальная возможность повышения привелегий. Последнее сильно связано и с безопасностью основной системы, но различные зонные политики безопасности, возможно, позволят ограничить запуск лишних процессов от рута именно в чруте. Если есть еще какие-то варианты предотвратить повышение привилегий в чруте, хотелось бы узнать. И еще - отсутствие в чруте процессов с рутовыми привилегиями может ли _гарантировать_ безопасность от повышения привилегий? Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Безопасность chroot
29 августа 2009 г. 14:43 пользователь Alexey Pechnikov (pechni...@mobigroup.ru) написал: Hello! On Saturday 29 August 2009 15:06:56 Иван Лох wrote: Просто подумай о том, что никакой chroot не отменяет вызовы ядра, которыми можно сделать все. В отличии от виртуалки. Поэтому chroot в котором работают под root и не имеет смысла. И chroot в котором достаточно полная система, чтобы обеспечить эскалацию привилегий тоже смысла не имеет. Для целей безопасности, разумеется. 1) selinux и подобные решения могут запретить сделать все. Это конкретно к вопросу о запуске init 0 в чруте - даже если пользователю удалось повысить свои привелегии, что может произойти и на основной системе. Однако в чруте, вероятно, можно и какие-то другие техники применить, вот и вопрос - какие? Никаких других техник нет. Чрут только позволяет сменить корневой каталог. Всё. Приложение запущенно в чрут от _root_, может сделать всё то, что и без чрута. В том числе и получить доступ к файлам вне чрута. И это нормально. Чрут предназначен не для этого. И кстати запустить init в чруте не выйдет. В системе уже есть процесс с pid 0 2) Запуск от рута одного init-процесса в чруте еще не дает возможности пользователям и приложениям получить права рута. И работать от рута абсолютно не то же самое, что иметь запущенные в системе процессы от рута (которые, кстати, есть во всех линуксах, но это не отменяет возможность и необходимость защиты системы). 3) Обеспечить эскалацию привелегий - это не проблема чрута как технологии, хотя бы потому, что многие гипервизоры это тоже позволяют. Так что виртуалка на практике не надежнее чрута, а скорее, наоборот, т.к. добавляется много лишнего кода, работающего с высшими привелегиями. В чруте, например, можно не монтировать /proc, что, насколько я понимаю, сделает невозможным вызов init 0. На виртуалке же вы и такой возможности не имеете. А вот что нужно отрезать в чруте, чтобы блокировать означенную угрозу, как раз и представляет интерес. Чрут и виртуалка решают РАЗНЫЕ проблемы. Конкретно в вашем случае чрут бесполезен. Как вы будете тестировать новый init не перезагружаясь в чруте ? Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Безопасность chroot
On Sat, Aug 29, 2009 at 03:58:00PM +0400, Alexey Pechnikov wrote: Hello! On Saturday 29 August 2009 15:23:25 Stanislav Maslovski wrote: Вам не интересно - так ведь никто не заставляет. При отмонтированном /proc и у рута в чруте возможности сильно ограничены. Что помешает руту подмонтировать /proc обратно? Пусть есть запущенный от рута процесс init. Ты очень любишь менять коней на ходу. Изначально тебя интересовало несколько иное: а именно, отсылка сигнала процессу init (строго говоря, там не сигнал отсылается, а /dev/initctl используется, но это не суть важно) и как ее запретить. Т.е., предполагалось, что в системе есть некий untrusted процесс, который может этот сигнал послать. Он с необходимостью должен быть запущен от рута, иначе проблемы нет вообще. Как от юзера www-data подмонтировать /proc, воспользовавшись привелегиями процесса init? Вы серьезно считаете, что системный init или runit такие дырявые? Может, я чего-то не знаю, но мне это кажется очень маловероятным. А еще ты очень любишь додумывать за собеседника. Если есть такая проблема, то придется selinux и проч. использовать, как я уже упоминал в другом сообщении. Но я полагаю, что это не так. Selinux -- вообще отдельный (на мой взгляд, не очень удачный) механизм, к чруту прямого отношения не имеющий. Есть еще механизм capabilities (man capabilities), который позволяет распределить привилегии более тонко, но чтобы его использовать, потребуются некие усилия. -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Безопасность chroot
29 августа 2009 г. 15:14 пользователь Alexey Pechnikov (pechni...@mobigroup.ru) написал: Hello! Уточняю - пользователь в чруте рута не имеет! Но есть процессы, запущенные от рута, и потенциальная возможность повышения привелегий. Последнее сильно связано и с безопасностью основной системы, но различные зонные политики безопасности, возможно, позволят ограничить запуск лишних процессов от рута именно в чруте. Если есть еще какие-то варианты предотвратить повышение привилегий в чруте, хотелось бы узнать. И еще - отсутствие в чруте процессов с рутовыми привилегиями может ли _гарантировать_ безопасность от повышения привилегий? Не может. Есть ещё експлойты для ядра. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Безопасность chroot
On Sat, Aug 29, 2009 at 07:10:15PM +0700, ivan demakov wrote: В сообщении от Saturday 29 of August 2009 16:02:33 Alexey Pechnikov написал(а): Hello! Предлагаю в противовес применению виртуалок обсудить возможности рассуждать о безопастности чего-то в чем-то можно долго. так же как рассуждать о просто безопастности. но лучше всего рассуждать о чем-то где-то и непонятно для чего. А если еще и не понятно с кем, то мы получаем двач. Вот к чему привел технический прогресс =) -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: 1Cv8 + PostgreSQL на Len ny. Кто в теме?
,-[Wed, Aug 26, 2009 at 11:26 +0600, Nikolay Shestakov:] | есть положительный опыт юзания 4х баз примерно 60ю пользователями с дикими | подключениями из одной 1с автоматом сразу в 1-2 базы... размеры баз 3-4 гига | 3 шутки и еще одна на 1 гиг... всё это крутиться на терминалке с 8 ядами, 8 | гигами под 2008 сервером и бед не знает... | |Есть положительный опыт при подобных параметрах запускать все это под |wine-etersoft :) есть положительный опыт запуска под простым вайном, но в гетерогенной среде - неприменимо. ) базы клиентом желаюцца читацца и писацца в разных кодировках. -- __ mpd status: [playing] Machine Head - Violate ** * jabber: devil_ins...@jabber.ru * * Registered linux user #450844* ** -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Безопасность chroot
Hello! On Saturday 29 August 2009 16:14:20 Nick wrote: Конкретно в вашем случае чрут бесполезен. Как вы будете тестировать новый init не перезагружаясь в чруте ? Не обязательно его как процесс номер 1 запускать. У меня сейчас в чруте работает два процесса runit, причем второй - от непривелигированного пользователя. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Читалки
,-[Wed, Aug 26, 2009 at 17:18 +0600, Viatcheslav Trotsak:] | Если не интересует форматирование - перегонять в plain text и читать | чем угодно (по крайней мере в ленни было несколько читалок, в этч не | знаю). | Если интересует форматирование - то перегонять в fb2 или html (лучше | первое). | | -- | Best regards, | Alexander GQ Gerasiov | |Благодарю всех участников за содержательные ответы. | |Lenny уже в пути. | |Как я понял из ответов - fbreader рулит. | |В pdf я перегонял doc через OO, но качество не понравилось. | ooo-fbtools весьма адекватна. в последнее время забросил fb-designer и шлепаю себе книжки в ней. pdf можно рассматривать как вариант для техлитературы, но всеж, мне кажется, ее не так много, той, которая никак нигде, кроме графического исполнения. http://lib.rus.ec/b/163202 -- __ mpd status: [playing] Machine Head - Violate ** * jabber: devil_ins...@jabber.ru * * Registered linux user #450844* ** -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Безопасность chroot
Hello! On Saturday 29 August 2009 16:18:40 Nick wrote: И еще - отсутствие в чруте процессов с рутовыми привилегиями может ли _гарантировать_ безопасность от повышения привилегий? Не может. Есть ещё експлойты для ядра. Их еще нужно скомпилировать или загрузить откуда-то. Первое можно запретить, со вторым посложнее. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Безопасность chroot
29 августа 2009 г. 16:18 пользователь Alexey Pechnikov (pechni...@mobigroup.ru) написал: Hello! On Saturday 29 August 2009 16:18:40 Nick wrote: И еще - отсутствие в чруте процессов с рутовыми привилегиями может ли _гарантировать_ безопасность от повышения привилегий? Не может. Есть ещё експлойты для ядра. Их еще нужно скомпилировать или загрузить откуда-то. Первое можно запретить, со вторым посложнее. Если приложение запущенно в чруте, не общается с внешним миром, и не использует каких либо файлов извне (этакое сферическое приложение в вакуме), то безопасно. В противном случае есть возможность запустить уже скомпилированный эксплойт, возможно с уже заданными действиями. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Правильные демоны - не демоны?
Alexey Pechnikov - debian-russian@lists.debian.org @ Sat, 29 Aug 2009 12:49:34 +0400: AP Лучшие тестеры - сами пользователи. Вот насчет лучшие - это ты загнул. Сотня пользователей не заменяет одного профессионального тестировщика. Обратное, впрочем, тоже верно. AP Профессиональный тестировщик проверяет на соответствие ТЗ, Если ты так полагаешь, то ты мало того что сам не профессиональный тестировщик, так еще и ни разу в жизни с профессиональным не общался. Проверка на соответствие ТЗ проводится вообще-то сертифицирующими органами (и что там написано - это отдельная песня), в отдельных очень редких случаях - менеджером, а тестировщик в норме ТЗ вообще в глаза не видит. AP P.S. Иногда встречаются пользователи, которые лучше любого AP тестировщика проверяют - то ли им так не везет и все грабли на них AP срабатывают, то ли это талант :-) Это просто неверный выбор профессии :-) -- Все дуры - бабы фольклор -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Правильные демоны - не демоны?
В сообщении от Суббота 29 августа 2009 18:58:33 автор Artem Chuprina написал: Alexey Pechnikov - debian-russian@lists.debian.org @ Sat, 29 Aug 2009 12:49:34 +0400: AP Лучшие тестеры - сами пользователи. Вот насчет лучшие - это ты загнул. Сотня пользователей не заменяет одного профессионального тестировщика. Обратное, впрочем, тоже верно. AP Профессиональный тестировщик проверяет на соответствие ТЗ, Если ты так полагаешь, то ты мало того что сам не профессиональный тестировщик, так еще и ни разу в жизни с профессиональным не общался. Проверка на соответствие ТЗ проводится вообще-то сертифицирующими органами (и что там написано - это отдельная песня), в отдельных очень редких случаях - менеджером, а тестировщик в норме ТЗ вообще в глаза не видит. Может вы ещё верите в набор тестировщиков по правилу умеет ломать всякое? AP P.S. Иногда встречаются пользователи, которые лучше любого AP тестировщика проверяют - то ли им так не везет и все грабли на них AP срабатывают, то ли это талант :-) Это просто неверный выбор профессии :-) signature.asc Description: This is a digitally signed message part.
Re: Правильные демоны - не демоны?
Hello! On Saturday 29 August 2009 18:58:33 Artem Chuprina wrote: AP Профессиональный тестировщик проверяет на соответствие ТЗ, Если ты так полагаешь, то ты мало того что сам не профессиональный тестировщик, так еще и ни разу в жизни с профессиональным не общался. Проверка на соответствие ТЗ проводится вообще-то сертифицирующими органами (и что там написано - это отдельная песня), в отдельных очень редких случаях - менеджером, а тестировщик в норме ТЗ вообще в глаза не видит. Понимаю, почему вам так хочется временами всех разогнать... Серьезно, сочувствую. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Правильные демоны - не демоны?
Andrew N Golovkov - debian-russian@lists.debian.org @ Sat, 29 Aug 2009 19:20:10 +0400: AP Лучшие тестеры - сами пользователи. Вот насчет лучшие - это ты загнул. Сотня пользователей не заменяет одного профессионального тестировщика. Обратное, впрочем, тоже верно. AP Профессиональный тестировщик проверяет на соответствие ТЗ, Если ты так полагаешь, то ты мало того что сам не профессиональный тестировщик, так еще и ни разу в жизни с профессиональным не общался. Проверка на соответствие ТЗ проводится вообще-то сертифицирующими органами (и что там написано - это отдельная песня), в отдельных очень редких случаях - менеджером, а тестировщик в норме ТЗ вообще в глаза не видит. ANG Может вы ещё верите в набор тестировщиков по правилу умеет ломать ANG всякое? Отнюдь. Просто на соответствие ТЗ я обычно могу проверить и без тестировщика. И даже лучше тестировщика. И дешевле. Но это отвечает на вопрос правильно ли программа выполняет такие-то действия, а не хорошо ли программа работает. А я, знаете ли, программу пишу не для галочки. Для галочки я пишу специально обученный документ под названием текст программы. -- Вам правду резать или кусочком? Кнышев -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: 1Cv8 + PostgreSQL на Lenny. К то в теме?
On Sat, 29 Aug 2009 17:12:10 +0400 Evgeniy M. Solodookhin devil_ins...@gas.starlink.ru wrote: ,-[Wed, Aug 26, 2009 at 11:26 +0600, Nikolay Shestakov:] | есть положительный опыт юзания 4х баз примерно 60ю пользователями с дикими | подключениями из одной 1с автоматом сразу в 1-2 базы... размеры баз 3-4 гига | 3 шутки и еще одна на 1 гиг... всё это крутиться на терминалке с 8 ядами, 8 | гигами под 2008 сервером и бед не знает... | |Есть положительный опыт при подобных параметрах запускать все это под |wine-etersoft :) есть положительный опыт запуска под простым вайном, но в гетерогенной среде - неприменимо. ) базы клиентом желаюцца читацца и писацца в разных кодировках. как так? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Подключить debian-multimedi a без автоустановки
Mikhail Ramendik wrote: Всем привет! Вопрос - как подключить debian-multimedia так, чтобы пакеты оттуда ставились только при прямом на то указании? Понятно, что надо ставить Pin в /etc/apt/preferences, но как именно? Гм. man apt_preferences читали? -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Maintainer signature.asc Description: OpenPGP digital signature
Re: Подключить debian- multimedia без автоустановки
On Sun, Aug 30, 2009 at 12:26:59AM +0100, Mikhail Ramendik wrote: Всем привет! Вопрос - как подключить debian-multimedia так, чтобы пакеты оттуда ставились только при прямом на то указании? Понятно, что надо ставить Pin в /etc/apt/preferences, но как именно? Добавить нечто подобное в /etc/apt/preferences: Package: * Pin: release a=testing,o=Unofficial Multimedia Packages Pin-Priority: 100 Приоритет подправить в соответствии с желаемым поведением (man apt_preferences) -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Подключить debian-multimedi a без автоустановки
Eugene V. Lyubimkin пишет: Понятно, что надо ставить Pin в /etc/apt/preferences, но как именно? Гм. man apt_preferences читали? А по какому параметру можно идентифицировать однозначную принадлежность именно к debian-multimedia? Там, к сожалению, не везде maril...@debian.org мейнтейнер... -- Dmitri Samsonov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Мониторинг opensource-проектов
Необходимо мониторить пару десятков проектов на наличие обновлений/релизов. Попробывал было воспользоваться для этого дела сервисами freshmeat.net и/или sourceforge.net, но у первого странная какая-то выборка, kvm, к примеру отсутствует, а у второго с последним редизаном мониторинг вообще отключили. Как бы решить задачу? p.s. прошу прощения за оффтоп.
[OT] gmail нынче банит при слишком частом опросе почты по POP3?
Перешел по некоторым причинам назад на POP3 при работе с гмылом. Заметил нечто, чего раньше не было: fetchmail периодически ругается: fetchmail authentication failed При заходе через вебинтерфейс гмыл просит ввести некий код верификации. После выполнения этой процедуры fetchmail работает снова. Никто не сталкивался с подобным? Интервал между опросами в fetchmail у меня 300 сек. Есть, правда, один момент. Я опрашиваю гмыл не только по POP3, но еще проверяю содержимое папки Sent Mail по IMAP, т.е. как-то так: poll pop.googlemail.com proto pop3 user ... pass ... ssl poll imap.googlemail.com proto imap user ... pass ... ssl folder [Google Mail]/Sent Mail fetchall Может ему два запроса подряд не нравятся? -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Мониторинг opensource-пр оектов
On Sun, 30 Aug 2009 06:59:06 +0600 Murat D. Kadirov bander...@gmail.com wrote: Необходимо мониторить пару десятков проектов на наличие обновлений/релизов. Попробывал было воспользоваться для этого дела сервисами freshmeat.net и/или sourceforge.net, но у первого странная какая-то выборка, kvm, к примеру отсутствует, а у второго с последним редизаном мониторинг вообще отключили. Как бы решить задачу? Подписаться на RSS (его сейчас любой проектный хостинг предоставляет) и читать любым удобным способом. -- Alexander Galanin http://galanin.nnov.ru pgpn9kV8FNlfQ.pgp Description: PGP signature
Re: Мониторинг opensource-проектов
On Sunday 30 August 2009 07:04:21 Alexander Galanin wrote: On Sun, 30 Aug 2009 06:59:06 +0600 Murat D. Kadirov bander...@gmail.com wrote: Необходимо мониторить пару десятков проектов на наличие обновлений/релизов. Попробывал было воспользоваться для этого дела сервисами freshmeat.net и/или sourceforge.net, но у первого странная какая-то выборка, kvm, к примеру отсутствует, а у второго с последним редизаном мониторинг вообще отключили. Как бы решить задачу? Подписаться на RSS (его сейчас любой проектный хостинг предоставляет) и читать любым удобным способом. Эх, вот думал писать о том, что RSS не предлагать или нет.. стоило было написать :-) ...мда пока писал объяснение, чем для меня так не удобен RSS нашёл решение, как эту засаду обойти. Спасибо. p.s. Хотя в идеале, хотелось бы, чтобы письмо просто падало в почтовый ящик..
Re: Мониторинг opensource-пр оектов
On Sun, 30 Aug 2009 07:29:10 +0600 Murat D. Kadirov bander...@gmail.com wrote: Подписаться на RSS (его сейчас любой проектный хостинг предоставляет) и читать любым удобным способом. Эх, вот думал писать о том, что RSS не предлагать или нет.. стоило было написать :-) ...мда пока писал объяснение, чем для меня так не удобен RSS нашёл решение, как эту засаду обойти. Спасибо. p.s. Хотя в идеале, хотелось бы, чтобы письмо просто падало в почтовый ящик.. Package: rss2email Priority: optional Section: mail Installed-Size: 136 Maintainer: David Watson dwat...@debian.org Architecture: all Version: 1:2.65-1 Depends: python, python-support (= 0.90.0), python-feedparser Filename: pool/main/r/rss2email/rss2email_2.65-1_all.deb Size: 23440 MD5sum: 4b45346a963fd299c822ca7a68ee6e52 SHA1: a26ff139338eeb1ab23bbddc2e43a868364c5d63 SHA256: c9450f4d46d0155ade001e30f97891e71daf0917ce8aa61af0a861febdca9148 Description: receive RSS feeds by email rss2email is a simple program which you can run in your crontab. It watches RSS (or Atom) feeds and sends you a nicely formatted email message for each new item. Homepage: http://rss2email.infogami.com/ -- Alexander Galanin http://galanin.nnov.ru pgp94E8gsRApb.pgp Description: PGP signature
Re: Мониторинг opensource-проектов
On Sunday 30 August 2009 07:34:54 Alexander Galanin wrote: On Sun, 30 Aug 2009 07:29:10 +0600 Murat D. Kadirov bander...@gmail.com wrote: Подписаться на RSS (его сейчас любой проектный хостинг предоставляет) и читать любым удобным способом. Эх, вот думал писать о том, что RSS не предлагать или нет.. стоило было написать :-) ...мда пока писал объяснение, чем для меня так не удобен RSS нашёл решение, как эту засаду обойти. Спасибо. p.s. Хотя в идеале, хотелось бы, чтобы письмо просто падало в почтовый ящик.. Package: rss2email Priority: optional Section: mail Installed-Size: 136 Maintainer: David Watson dwat...@debian.org Architecture: all Version: 1:2.65-1 Depends: python, python-support (= 0.90.0), python-feedparser Filename: pool/main/r/rss2email/rss2email_2.65-1_all.deb Size: 23440 MD5sum: 4b45346a963fd299c822ca7a68ee6e52 SHA1: a26ff139338eeb1ab23bbddc2e43a868364c5d63 SHA256: c9450f4d46d0155ade001e30f97891e71daf0917ce8aa61af0a861febdca9148 Description: receive RSS feeds by email rss2email is a simple program which you can run in your crontab. It watches RSS (or Atom) feeds and sends you a nicely formatted email message for each new item. Homepage: http://rss2email.infogami.com/ Вот, как-раз то, что нужно. Как-то и не думалось о наличии подобного рода софта. Спасибо.
[RFR] po-debconf://gwhois/ru.po
Здравствуйте. Пакет: gwhois Версия: 20090717.1 Количество: 3 переведенных сообщения. Отправка: 08 Сентябрь 2009# translation of gwhois_20090717.1_ru.po to Russian # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # # Yuri Kozlov yu...@komyakino.ru, 2009. msgid msgstr Project-Id-Version: gwhois 20090717.1\n Report-Msgid-Bugs-To: debian-gwh...@michael.holzt.de\n POT-Creation-Date: 2006-09-28 18:34+0200\n PO-Revision-Date: 2009-08-29 10:00+0400\n Last-Translator: Yuri Kozlov yu...@komyakino.ru\n Language-Team: Russian debian-l10n-russian@lists.debian.org\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n X-Generator: KBabel 1.11.4\n Plural-Forms: nplurals=3; plural=(n%10==1 n%100!=11 ? 0 : n%10=2 n%10=4 (n%10010 || n%100=20) ? 1 : 2);\n #. Type: boolean #. Description #: ../templates:1001 msgid Install gwhois as a whois proxy server? msgstr Установить gwhois в качестве прокси-сервера whois? #. Type: boolean #. Description #: ../templates:1001 msgid If gwhois is installed as a whois proxy server (using inetd) it will listen on the standard whois port (43) allowing normal whois clients to query it. msgstr Если установить gwhois как прокси-сервер whois (используется inetd), то он будет прослушивать стандартный порт whois (43), позволяя делать запросы обычными клиентами whois. #. Type: boolean #. Description #: ../templates:1001 msgid This can be interesting for example if you want to setup a generic whois server for your company or coworkers which can then use their standard whois- client (e.g. a windows client) and still make use of the intelligent features of gwhois. msgstr Это может быть полезно, например, если вы хотите настроить обычный сервер whois для вашей компании или сотрудников, чтобы они могли использовать свои стандартные клиенты whois (например, windows-клиенты), а у вас оставалась возможность использовать дополнительные свойства gwhois.
[RFR] po-debconf://durep/ru.po
Здравствуйте. Пакет: durep Версия: 0.9-1 Количество: 5 переведенных сообщений. Отправка: 08 Сентябрь 2009# translation of durep_0.9-1_ru.po to Russian # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # # Yuri Kozlov yu...@komyakino.ru, 2009. msgid msgstr Project-Id-Version: durep 0.9-1\n Report-Msgid-Bugs-To: \n POT-Creation-Date: 2007-09-09 04:31+0200\n PO-Revision-Date: 2009-08-29 11:14+0400\n Last-Translator: Yuri Kozlov yu...@komyakino.ru\n Language-Team: Russian debian-l10n-russian@lists.debian.org\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n X-Generator: KBabel 1.11.4\n Plural-Forms: nplurals=3; plural=(n%10==1 n%100!=11 ? 0 : n%10=2 n%10=4 (n%10010 || n%100=20) ? 1 : 2);\n #. Type: boolean #. Description #: ../templates:1001 msgid Do you want to enable daily report generation? msgstr Включить ежедневное создание отчёта? #. Type: boolean #. Description #: ../templates:1001 msgid If you wish, a daily script will create disk usage statistics of chosen filesystems. They will be kept for seven days. msgstr Если хотите, сценарий ежедневно будет создавать отчёт об использовании диска в заданных файловых системах. Она будет храниться семь дней. #. Type: boolean #. Description #: ../templates:1001 msgid WARNING: with the default configuration, the statistics are stored in the public httpd directory, /var/www/durep. This may breach the privacy of the users. msgstr ПРЕДУПРЕЖДЕНИЕ: по умолчанию, отчёты сохраняются в общедоступном через httpd каталоге /var/www/durep. Это может нарушать конфиденциальность пользовательской информации. #. Type: string #. Description #: ../templates:2001 msgid List of filesystems for durep reports msgstr Список файловых систем для отчёта durep: #. Type: string #. Description #: ../templates:2001 msgid To specify single filesystems to report on, enter their mount points separated by spaces (eg. \/data /var\). A single dot (\.\) means scanning of the whole UNIX filesystem tree. msgstr Чтобы указать для отчёта определённые файловые системы, введите их точки монтирования через пробелы (например, \/data /var\). Одна точка (\.\) означает сканирование всего дерева файловых систем UNIX.
[RFR] po-debconf://mythtv-status/ru.po
Здравствуйте. Пакет: mythtv-status Версия: 0.9.0-5 Количество: 9 переведенных сообщений. Отправка: 08 Сентябрь 2009# translation of mythtv-status_0.9.0-5_ru.po to Russian # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # # Yuri Kozlov yu...@komyakino.ru, 2009. msgid msgstr Project-Id-Version: mythtv-status 0.9.0-5\n Report-Msgid-Bugs-To: and...@etc.gen.nz\n POT-Creation-Date: 2007-12-25 13:20+1300\n PO-Revision-Date: 2009-08-29 11:32+0400\n Last-Translator: Yuri Kozlov yu...@komyakino.ru\n Language-Team: Russian debian-l10n-russian@lists.debian.org\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n X-Generator: KBabel 1.11.4\n Plural-Forms: nplurals=3; plural=(n%10==1 n%100!=11 ? 0 : n%10=2 n%10=4 (n%10010 || n%100=20) ? 1 : 2);\n #. Type: string #. Description #: ../templates:1001 msgid MythTV backend to check: msgstr Проверяемая серверная часть MythTV: #. Type: string #. Description #: ../templates:1001 msgid The MythTV backend to check, you only need to change this if you want to check a different host. msgstr Здесь указывается проверяемая серверная часть (backend) MythTV; требует изменения только в случае, если вы хотите проверять другой компьютер. #. Type: boolean #. Description #: ../templates:2001 msgid Update the system MOTD? msgstr Обновлять системный MOTD? #. Type: boolean #. Description #: ../templates:2001 msgid Whether the Message of the Day should be updated on system boot and on a regular basis. msgstr Здесь можно указать, нужно ли обновлять Сообщение Для регулярно и при загрузке системы. #. Type: boolean #. Description #: ../templates:2001 msgid To adjust how often the MOTD is updated, edit /etc/cron.d/mythtv-status. msgstr Для настройки частоты обновления MOTD, отредактируйте /etc/cron.d/mythtv-status. #. Type: string #. Description #: ../templates:3001 msgid Send email status to: msgstr Отправка данных о состоянии на эл. почту: #. Type: string #. Description #: ../templates:3001 msgid Status emails can be sent on a daily basis. msgstr Состояние можно отправлять ежедневно по электронной почте. #. Type: string #. Description #: ../templates:3001 msgid By default an email is only sent if there are alerts. You must have the MythTV Perl API installed for conflict alerts to be generated. msgstr По умолчанию письма отправляются только при возникновении проблем. Для предупреждений о конфликтах вам требуется установить MythTV Perl API. #. Type: string #. Description #: ../templates:3001 msgid To disable set the email address to \none\. To specify multiple email addresses, seperate them with a comma. msgstr Для выключения вместо адреса укажите \none\. Несколько адресов эл. почты можно задавать через запятую.
