Re: qmail or not qmail?
Hello! Специально для вас разыскал этот диалог между дебиан-девелоперами: On Fri, 21 Dec 2007, John H. Robinson, IV wrote: On Fri, 21 Dec 2007, Don Armstrong wrote: On Fri, 21 Dec 2007, John H. Robinson, IV wrote: On Fri, 21 Dec 2007, Don Armstrong wrote: On Fri, 21 Dec 2007, John H. Robinson, IV wrote: On Fri, 21 Dec 2007, Don Armstrong wrote: On Fri, 21 Dec 2007, John H. Robinson, IV wrote: On Fri, 21 Dec 2007, Don Armstrong wrote: On Fri, 21 Dec 2007, John H. Robinson, IV wrote: On Fri, 21 Dec 2007, Don Armstrong wrote: On Fri, 21 Dec 2007, John H. Robinson, IV wrote: On Fri, 21 Dec 2007, Don Armstrong wrote: On Fri, 21 Dec 2007, John H. Robinson, IV wrote: Joerg Jaspert wrote: There are *way* better MTAs [than qmail] out there that dont need tons of patches applied just to fulfill basic requirements for a MTA. No, there are not. Yes, there are. No, there are not. Yes, there are. No, there are not. Yes, there are. No, there are not. Yes, there are. No, there are not. Yes, there are. No, there are not. Yes, there are. No, there are not. Yes, there are. Next? ;-) On Thursday 28 January 2010 07:08:04 Stanislav Vlasov wrote: Больше 2Гб на _процесс_ открывает дырку. По-мелкому, но обманываете - там unsigned int - 4 Гб. Разница не сильно большая на самом деле. Ну будет открыто не через год, а через три. Схоластикой занимаетесь, по сути. Поскольку обработать заголовок большего размера нельзя, т.к. предел это для беззнакового целого. А использование long long нарушит переносимость. Так что полагаю, что эта же проблема есть во всех портабельных MTA. Раз уж вы до сих пор не сподобились посмотреть, почему этот баг не закрыт, опять приходится здесь объяснять. Ну через пять. Один фиг - оригинальный кумыл точно дыряв, а за патченый djb не отвечает. Хм, есть рассылка, где можете получить поддержку, есть дебиан-мантейнеры, с кем можно проконсультироваться и так далее. На необитаемый остров вовсе не похоже. Что касается именно использования множества патчей - тут я вас вполне понимаю. Именно потому, собственно, я сам и выбрал qmail, чтобы можно было нужную функциональность добавлять внешними утилитами. Ваш любимый отбой несуществующих адресатов может быть организован аналогично rblsmtpd, и если мне оно понадобится, то я воспользуюсь именно вспомогательной утилитой, вместо ковыряния исходников. Но возгласы вида там есть патчи, усе пропало!, мне отнюдь не кажутся осмысленными, т.к. лишь чтук пять патчей закрывают дыры, а остальные это просто расширение функциональности, например, поддержка ldap (в дебиановском qmail ее как патч впихнули, хотя можно найти сборку именно qmail-ldap). и про попадании не меньше чем в N - либо отопнуть, либо добавить хидер с указанием. Насчет не меньше чем в N я не в курсе, обычно N==1. И что вы будете делать, если ночью по местному какой-то из rbl накроется и будет на всех говорить это спамер, а утром должно придти письмо из другого часового пояса? Или уважаемый клиент попал в один из rbl потому что этот rbl заносит в спамеры целыми сетями? А зачем мне в _свой_ лист что попало включать? Думать надо на этапе составления своего списка, а не удесятерять миллионы обращений. Эдак вы, экономя трафик на отбое писем, взамен еще больше нагенерите на обращениях к черным спискам. В общем-то несложно поправить rblsmtpd на обращение хоть к миллиону внешних хостов, но это была бы совершенно бредовая затея, - используйте свой лист. Или патча, который позволит проверить helo/from/to/ip внешними средствами и получить решение о приёме до посылки ответа на DATA. Например, выбираете пункт 5.12. Отклонение недействительных получателей во время SMTP-сессии в оглавлении, узнаете, что список соответствующих патчей доступен здесь: http://netdevice.com/qmail/rcptck/ и также вам предлагается ссылка на рекомендуемый патч. Это нормальное поведение бОльшей части MTA. Вы просили _патч_, я вам на него дважды ссылку дал. Что ж вы теперь-то от него отмежеваться решили? Впрочем, выше я и альтернативный вариант привел, коль вы ссылки не смотрите... Так что причины - в бюрократии, увы. Чтож... Пусть будет бюрократия. Хотя другие пакеты появляются хотя бы в non-free. Так и qmail есть в non-free. Речь идет о замене существующего пакета более функциональным. Ой как всё запущено... То есть допустить, что юзер с uid 64010 в системе может уже быть вы не в состоянии? Опять вы в чем-то непотребном мантейнера подозреваете :-) Позвольте мне все же отослать вас к preinst скрипту, вместо того, чтобы его целиком здесь приводить. Есть там
Re: очень хочется squirrelsh
Alexandr Sagadeev writes: Автоматическую вставлялку не использую. Разница в том, что закрывающуюся операторную скобку можно поставить не глядя, а для ТАБа надо помнить сколько раз его нажать и не путать с пробелом.Для последнего приходится отвлекаться от печати. Какой ужас. Вы nano код пишете? -- With Best Regards, Maxim Tyurin JID:mrko...@jabber.pibhe.com
Re: qmail or not qmail?
Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 28 Jan 2010 01:27:13 +0300: и про попадании не меньше чем в N - либо отопнуть, либо добавить хидер с указанием. AP Насчет не меньше чем в N я не в курсе, обычно N==1. От N==1 нормальные постмастера давно уже отучились. Очень уж чревато боком. Впрочем, боюсь, я это тебе рассказываю зря... AP Что мешает держать _свой_ лист, а в него добавлять по вхождению в N AP публичных или по любому нужному критерию? Или вы на каждое входящее AP письмо предпочитаете делать тучу запросов к удаленным хостам, да AP еще с вероятными повторами? Уважающие себя проверялки умеют кэшировать. А тучу запросов и так, и так придется делать, если ты свой список формируешь на основе других. Причем если ты его именно формируешь на основе других, то туча будет куда больше. По причине, которую ты мог бы заметить и сам. Впрочем, эта ошибка у тебя систематическая. -- Лень оправдывает средства -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Подошва сапога
Lex2d aka Lex - debian-russian@lists.debian.org @ Wed, 27 Jan 2010 22:27:31 +0200: V Обратное, так же должно быть верно - люди должны снабжать тебя всем V нужным для жизни, потому что ты даешь им то, что надо им. Между твоим потому что ты даешь им то, что надо им и его потому, что она им нужна - пропасть. LaL хм... имхо господа коммунисты-теоретики, при вопросах снабжения, LaL всегда забывают маленькую деталь - что в реальности множество LaL ресурсов дефицитно и их надо как-то распределять(когда они LaL придумываю способы распределения, по привычке изобретают аналог LaL денег). Посему все коммунические уклады - не более чем следствие LaL устранения дефицита в конкретных областях. По большому счету, по первым двум уровням пирамиды Маслоу дефицит уже стал искусственным (наших возможностей хватает для его устранения), а по остальным он искусственный по определению. -- Не любят они на самом деле не Гринпис, а позицию Как бы чего не вышло, справедливо считая, что при такой позиции ничего и не выйдет. -- http://vitus-wagner.livejournal.com/397851.html?thread=14561307#t14561307 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: очень хочется squirrelsh
Serhiy Storchaka writes: В персональные компьютеры 80-х следовало прошивать форт, а не бейсик. Компактнее, мощнее, быстрее. Только форт в 80-х и остался :( Или уже есть нормальные 32 и 64 бита? -- With Best Regards, Maxim Tyurin JID:mrko...@jabber.pibhe.com
Re: очень хочется squirrelsh
Maxim Tyurin пишет: Alexandr Sagadeev writes: Автоматическую вставлялку не использую. Разница в том, что закрывающуюся операторную скобку можно поставить не глядя, а для ТАБа надо помнить сколько раз его нажать и не путать с пробелом.Для последнего приходится отвлекаться от печати. Какой ужас. Вы nano код пишете? Опаньки. А есть редактор, в котором можно писать код на питоне искаропки? -- Head office Igor Chumak System Administrator OJSC “UIC Generali Garant” 15/2 Chervonoarmiyska str., 01004, Kyiv, Ukraine Phone: +38(044)206 8820 E-Mail: i.chu...@generali.garant.ua www.generali.garant.ua -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: qmail or not qmail?
On Wed, Jan 27, 2010 at 01:19:21PM +0200, Oleg Tsymaenko wrote: Вот основные идеи манифеста коммунистической партии: Хорошенькое начало! Теперь по существу: qmail можно использовать как почтовый сервер. А продолжение еще лучше! Я плакалъ. -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: qmail or not qmail?
28 января 2010 г. 13:46 пользователь Alexey Pechnikov pechni...@mobigroup.ru написал: Специально для вас разыскал этот диалог между дебиан-девелоперами: [...] Yes, there are. No, there are not. Yes, there are. Next? ;-) Красиво, душевно :-) Больше 2Гб на _процесс_ открывает дырку. По-мелкому, но обманываете - там unsigned int - 4 Гб. Разница не сильно большая на самом деле. Ну будет открыто не через год, а через три. Схоластикой занимаетесь, по сути. Поскольку обработать заголовок большего размера нельзя, т.к. предел это для беззнакового целого. А использование long long нарушит переносимость. Так что полагаю, что эта же проблема есть во всех портабельных MTA. Раз уж вы до сих пор не сподобились посмотреть, почему этот баг не закрыт, опять приходится здесь объяснять. Кто-то говорил, что надо обрабатывать заголовок такого размера? Достаточно, если при попадании такого письма МТА не будет падать или открывать дыру. Ну через пять. Один фиг - оригинальный кумыл точно дыряв, а за патченый djb не отвечает. Хм, есть рассылка, где можете получить поддержку, есть дебиан-мантейнеры, с кем можно проконсультироваться и так далее. На необитаемый остров вовсе не похоже. Угу... Похоже на деревню... Что касается именно использования множества патчей - тут я вас вполне понимаю. Именно потому, собственно, я сам и выбрал qmail, чтобы можно было нужную функциональность добавлять внешними утилитами. Ваш любимый отбой несуществующих адресатов может быть организован аналогично rblsmtpd, и если мне оно понадобится, то я воспользуюсь именно вспомогательной утилитой, вместо ковыряния исходников. Но возгласы вида там есть патчи, усе пропало!, мне отнюдь не кажутся осмысленными, т.к. лишь чтук пять патчей закрывают дыры, а остальные это просто расширение функциональности, например, поддержка ldap (в дебиановском qmail ее как патч впихнули, хотя можно найти сборку именно qmail-ldap). Возгласы относятся не к существованию патчей, а к их количеству на каждый чих и к тому, что про то, какие патчи с какими сочетаются нормально, а какие - нет. и про попадании не меньше чем в N - либо отопнуть, либо добавить хидер с указанием. Насчет не меньше чем в N я не в курсе, обычно N==1. И что вы будете делать, если ночью по местному какой-то из rbl накроется и будет на всех говорить это спамер, а утром должно придти письмо из другого часового пояса? Или уважаемый клиент попал в один из rbl потому что этот rbl заносит в спамеры целыми сетями? А зачем мне в _свой_ лист что попало включать? Думать надо на этапе составления своего списка, а не удесятерять миллионы обращений. Эдак вы, экономя трафик на отбое писем, взамен еще больше нагенерите на обращениях к черным спискам. В общем-то несложно поправить rblsmtpd на обращение хоть к миллиону внешних хостов, но это была бы совершенно бредовая затея, - используйте свой лист. Мне проще сделать белый список откуда принимать обязательно и проверять остальных внешними листами, чем принимать в два раза больше почты только потому, что образовался очередной ботнет, не попавший в мой рбл. Или патча, который позволит проверить helo/from/to/ip внешними средствами и получить решение о приёме до посылки ответа на DATA. Например, выбираете пункт 5.12. Отклонение недействительных получателей во время SMTP-сессии в оглавлении, узнаете, что список соответствующих патчей доступен здесь: http://netdevice.com/qmail/rcptck/ и также вам предлагается ссылка на рекомендуемый патч. Это нормальное поведение бОльшей части MTA. Вы просили _патч_, я вам на него дважды ссылку дал. Что ж вы теперь-то от него отмежеваться решили? Впрочем, выше я и альтернативный вариант привел, коль вы ссылки не смотрите... Ссылки я смотрю. Главная засада в приведенных вами патчах - они каждый делает какой-то кусочек проверки. А надо - комплекс. Вторая засада - нет уверенности, что даже если каждый патч безопасен, будет безопасно их сочетание. Так что причины - в бюрократии, увы. Чтож... Пусть будет бюрократия. Хотя другие пакеты появляются хотя бы в non-free. Так и qmail есть в non-free. Речь идет о замене существующего пакета более функциональным. И даже сделать пакет netqmail тоже не вышло бы? Ой как всё запущено... То есть допустить, что юзер с uid 64010 в системе может уже быть вы не в состоянии? Опять вы в чем-то непотребном мантейнера подозреваете :-) Позвольте мне все же отослать вас к preinst скрипту, вместо того, чтобы его целиком здесь приводить. Есть там такая проверка, не волнуйтесь. Наличие проверки в данном случае означает всего-лишь невозможность поставить кумыл при наличии юзера. При отсутствии дебиана и, особенно, компьютера, тоже могут возникнуть некоторые технические проблемы. У меня юзеры из LDAP начинаются с uid 1. При этом, с uid 64000 - технические юзеры типа бекапилки или нагиоса. Привязку программы к какому-либо uid/gid кроме 0 я бы назвал технической проблемой разработчика. -- Stanislav
Re: очень хочется squirrelsh
Игорь Чумак writes: Опаньки. А есть редактор, в котором можно писать код на питоне искаропки? Я пишу в emacs. Не жалуюсь. Знакомые используют vim и тоже не жалуются. Использующие eclipse жалуются на его прожорливость, а на редактор тоже не жалуются. Еще используют eric, WingIde и встроенный в Visual Studio. Ни от кого не слышал про подсчет пробелов. Tab и BS всем хватает. -- With Best Regards, Maxim Tyurin JID:mrko...@jabber.pibhe.com
Re: очень хочется squirrelsh
Игорь Чумак - debian-russian@lists.debian.org @ Thu, 28 Jan 2010 12:37:53 +0200: Автоматическую вставлялку не использую. Разница в том, что закрывающуюся операторную скобку можно поставить не глядя, а для ТАБа надо помнить сколько раз его нажать и не путать с пробелом.Для последнего приходится отвлекаться от печати. Какой ужас. Вы nano код пишете? ИЧ Опаньки. ИЧ А есть редактор, в котором можно писать код на питоне искаропки? Как обычно, _оба_ текстовых редактора. -- Will write code that writes code that writes code that writes code for money. -- on comp.lang.lisp -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: очень хочет ся squirrelsh
On Wed, Jan 27, 2010 at 04:23:54PM +0300, Artem Chuprina wrote: А кстати. Где можно _хорошо_ почитать про Форт? А то в своем образовании я его упустил, а вероятно, зря... Интересует, понятно, в первую очередь изложение концепций. Thinking Forth by Leo Brodie http://thinking-forth.sourceforge.net/ -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: очень хочется squirrelsh
Maxim Tyurin - debian-russian@lists.debian.org @ Thu, 28 Jan 2010 12:17:26 +0200: В персональные компьютеры 80-х следовало прошивать форт, а не бейсик. Компактнее, мощнее, быстрее. MT Только форт в 80-х и остался :( MT Или уже есть нормальные 32 и 64 бита? Если б тогда прошивали - точно б были. В 80-х и в бейсике не было 32 и 64 бит - и ничего, по сю пору, блин, живее всех живых... -- Если ты не боишься синего экрана, то почему боишься черного? -- Д.Белявский -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: очень хочется squirrelsh
Maxim Tyurin wrote: Serhiy Storchaka writes: В персональные компьютеры 80-х следовало прошивать форт, а не бейсик. Компактнее, мощнее, быстрее. Только форт в 80-х и остался :( Да и пусть бы. Лучше бы 80-е прошли под знаком форта, чем бейсика и ассемблера. Да и не остался бы, если бы использовался повсеместно. Развился бы и дотянул до сегодня. Если не сам, то на другие языки большое влияние оказал бы. И на архитектуру процессоров. Или уже есть нормальные 32 и 64 бита? Вроде бы утверждённый ANSI стандарт не зависит от размера слова. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: qmail or not qmail?
Hello! On Thursday 28 January 2010 14:17:18 Stanislav Vlasov wrote: 28 января 2010 г. 13:46 пользователь Alexey Pechnikov pechni...@mobigroup.ru написал: Специально для вас разыскал этот диалог между дебиан-девелоперами: [...] Yes, there are. No, there are not. Yes, there are. Next? ;-) Красиво, душевно :-) Дискуссия была очень похожа на нашу - одни с успехом используют, другие нет, взаимопонимания по непонятным причинам не наблюдается. Кто-то говорил, что надо обрабатывать заголовок такого размера? Достаточно, если при попадании такого письма МТА не будет падать или открывать дыру. В этом смысле все предпочитают ограничивать размер письма. Собственно, поправить-то несложно, просто видимо никому не надо было (хотя можно и патч поискать, например, посмотреть в том же netqmail, я в него давно не заглядывал). Мне проще сделать белый список откуда принимать обязательно и проверять остальных внешними листами, чем принимать в два раза больше почты только потому, что образовался очередной ботнет, не попавший в мой рбл. Поищите, вроде где-то я видел доработанный вариант под это дело. Мне он не был интересен, так что ссылку не сохранил. Опять же, это внешняя утилита, которая на безопасность qmail не влияет. Ссылки я смотрю. Главная засада в приведенных вами патчах - они каждый делает какой-то кусочек проверки. А надо - комплекс. Вторая засада - нет уверенности, что даже если каждый патч безопасен, будет безопасно их сочетание. Они к разным утилитам относятся, так что не конфликтуют. Опять же, сборка http://dbn.smarden.org/sid/ выделяет и отдельную утилиту для отбоя, чтобы не менять оригинальный код ради нового функционала (и DJB это же советует). Так и qmail есть в non-free. Речь идет о замене существующего пакета более функциональным. И даже сделать пакет netqmail тоже не вышло бы? И такой пакет есть, лежит в репозитории Gerrit Pape (если не ошибаюсь, для всех релизов дебиана, начиная с potato). В 2007-м году, когда qmail был передан в public domain, Gerrit пакеты зааплодил на ftp-master - и вот, ждем... У меня юзеры из LDAP начинаются с uid 1. При этом, с uid 64000 - технические юзеры типа бекапилки или нагиоса. Привязку программы к какому-либо uid/gid кроме 0 я бы назвал технической проблемой разработчика. Во-первых, см. дебиан полиси, где это отнюдь не запрещается. Во-вторых, запускать весь софт от рута - это вы через край хватили. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: qmail or not qmail?
Hello! On Thursday 28 January 2010 14:08:56 Stanislav Maslovski wrote: On Wed, Jan 27, 2010 at 01:19:21PM +0200, Oleg Tsymaenko wrote: Вот основные идеи манифеста коммунистической партии: Хорошенькое начало! Теперь по существу: qmail можно использовать как почтовый сервер. А продолжение еще лучше! Я плакалъ. А я-то до этого и не дочитал, спасибо, показали :-D Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: очень хочется squirrelsh
On 2010.01.27 22:58, Aleksey Cheusov wrote: А кстати. Где можно _хорошо_ почитать про Форт? А то в своем образовании я его упустил, а вероятно, зря... Из того, что я видел мне больше всего понравилась IIRC, С.Н.Баранов Язык Форт и его реализации Good one! http://www.forth.org.ru/~cactus/library.htm Почуствовать Форт за 10 минут поможет пример buzzard.2: http://www.de.ioccc.org/years.html#1992 Читаем http://www.de.ioccc.org/1992/buzzard.2.hint - как запустить и http://www.de.ioccc.org/1992/buzzard.2.design - как это все работает. buzzard.2.c - иходник интерпретатора на с (790 байт), из него получают циклы и рекурсию. -- С уважением, Александр Гавенко. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: очень хочется squirrelsh
Serhiy Storchaka пишет: ivan demakov wrote: tcl -- по похожести на шелл. Питон на это и не претендует. А как у языка у тикля проблемы со структурой. Большие программы неподдерживаемы, работа со сложными структурами данных неудобна. В чём-то он похож на фортран. У Tcl нет проблем со структурой, только у лиспа более ясная структура программы, то есть такая структура, которую легко разобрать при помощи стандартных средств самого языка и может быт однозначно прочитана программистом. По поводу неподдерживаемости больших программ - их надо писать, более, чем одну, только тогда можно с уверенностью выдвигать такой тезис. Средства необходимые для написания больших программ в языка есть. Удобства работы со структурами данных - вещь относительная, можно создавать _любые_ структуры данных, как с помощью средств языка, так и с помощью FFI/C, а вот скорость, например, вставки элементов не в конец списка меня не устраивает, но это частность. А по поводу похожести на фортран - напомните, какие в фортране есть средства для метапрограммирования? Последнее утверждение - бред сивой кобылы, прошу прощения за резкость. P.S. Я не фанат тикля, я просто им пользуюсь. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: уже совсем не хочет ся squirrelsh
On Wed, 27 Jan 2010 22:12:21 +0200 Alexey Boyko ale...@boyko.km.ua wrote: startup не обязан вызывать именно main. И даже если это расходится с требованиями стандарта на стартап, программой на Си оно быть не перестаёт. Текст без main это набор функций на Си (библиотека, например), а не программа, так как непонятна точка запуска. Кому непонятна? Всем кроме автора. startup не обязан вызывать именно main. -- Best Regards, Yuri Kozlov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: qmail or not qmail?
28 января 2010 г. 18:36 пользователь Alexey Pechnikov pechni...@mobigroup.ru написал: Специально для вас разыскал этот диалог между дебиан-девелоперами: No, there are not. Yes, there are. Next? ;-) Красиво, душевно :-) Дискуссия была очень похожа на нашу - одни с успехом используют, другие нет, взаимопонимания по непонятным причинам не наблюдается. В нашей дискуссии как раз понятно. Вы предпочитаете самостоятельно суперклеем склеивать велосипед из деталей очень разного происхождения, я - взять работающее решение, соединённое болтами, которые иногда надо подтягивать (в последний раз требовалось месяца два назад - поставил дрвеб, ибо у начальника инфобезопасности профессиональная паранойя и кламаву он недостаточно доверяет, в предпоследний - в сентябре, когда топам захотелось попосылать файлы в 100Мб). Кто-то говорил, что надо обрабатывать заголовок такого размера? Достаточно, если при попадании такого письма МТА не будет падать или открывать дыру. В этом смысле все предпочитают ограничивать размер письма. Собственно, поправить-то несложно, просто видимо никому не надо было (хотя можно и патч поискать, например, посмотреть в том же netqmail, я в него давно не заглядывал). Я в это верю. Просто когда на это указали djb и какое нынче число? Сколько лет прошло? Мне проще сделать белый список откуда принимать обязательно и проверять остальных внешними листами, чем принимать в два раза больше почты только потому, что образовался очередной ботнет, не попавший в мой рбл. Поищите, вроде где-то я видел доработанный вариант под это дело. Мне он не был интересен, так что ссылку не сохранил. Опять же, это внешняя утилита, которая на безопасность qmail не влияет. Дешевле взять проверенное в N местах решение, чем клеить велосипед. Ссылки я смотрю. Главная засада в приведенных вами патчах - они каждый делает какой-то кусочек проверки. А надо - комплекс. Вторая засада - нет уверенности, что даже если каждый патч безопасен, будет безопасно их сочетание. Они к разным утилитам относятся, так что не конфликтуют. Опять же, сборка Не всегда. Часть того, что мне могло бы потребоваться - патчила smtpd. Сильно не разбирался, но не факт, что они патчили не один и тот же файл. http://dbn.smarden.org/sid/ выделяет и отдельную утилиту для отбоя, чтобы не менять оригинальный код ради нового функционала (и DJB это же советует). Не возражаю, но тогда не вижу смысла именно в кумыле, если все дырки прикрываются снаружи. Так и qmail есть в non-free. Речь идет о замене существующего пакета более функциональным. И даже сделать пакет netqmail тоже не вышло бы? И такой пакет есть, лежит в репозитории Gerrit Pape (если не ошибаюсь, для всех релизов дебиана, начиная с potato). В 2007-м году, когда qmail был передан в public domain, Gerrit пакеты зааплодил на ftp-master - и вот, ждем... Подозреваю - из-за отсутствия такой уж большой необходимости в кумыле именно в дистрибутиве. У меня юзеры из LDAP начинаются с uid 1. При этом, с uid 64000 - технические юзеры типа бекапилки или нагиоса. Привязку программы к какому-либо uid/gid кроме 0 я бы назвал технической проблемой разработчика. Во-первых, см. дебиан полиси, где это отнюдь не запрещается. Во-вторых, запускать весь софт от рута - это вы через край хватили. Э... Запуск и привязка - разные вещи. Скажем, uid для daemon в дебиане равен 1, а в RH - уже 2. Если какая-либо софтина посчитает, что для запуска под daemon ей необходимо и достаточно сменить uid на 1, то её автор просчитался. Здесь - аналогично. -- Stanislav
Re: Шейпер и два pppoe соединения.
On Tue, Jan 26, 2010 at 10:33:30AM +0200, Nick wrote: Имеется такая схема: dsl modem - router. На нём устанавливается два pppoe соединения. Нужно нарезать канал так, чтоб они не мешали друг другу. И что же это значит - не мешали друг другу? Во-первых, они и так друг другу мешать не будут, пока пропускной способности канала достаточно. А когда канала уже не хватает - возможны разные стратегии. Пока я думаю, что нужно поднять виртуальный интерфейс на выход в сторону модема, и настроить шейпер там. Или может есть способы как шейпить сам pppoe трафик ? Смущает то, что этот pppoe не tcp/ip. Если у тебя ppp интерфейсы на роутере поднимаются, то и TCP/IP трафик, который ты в эти интерфейсы роутишь, там тоже должен быть. -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Qemu работает крайне медлен но.
Имей в виду, что в современном qemu (0.12) kqemu зарэзали. Потому что у него есть общеизвестные плюхи (включая возможные проблемы с безопасностью) и ограничения (мешающие развитию qemu), и никого, желающего и способного им заниматся, не нашлось. Благодарю за информацию. Обязательно буду учитывать про покупке следущего ноута :) -- Best regards, Andrey Rubik
Re: Qemu работает крайне м едленно.
On Wed, Jan 27, 2010 at 17:50, Victor Wagner wrote: С другой стороны, возможно к тому времени как 0.12 окажется в debian, процессоров не умеющих виртуализации не останется ;-) [в sid - 0.11] Вот еще! Я не собираюсь ближайшие пять лет купленный год назад ASUS X80L выкидывать. Вот-вот. Лично я уже много лет использую дома буджетный HP nx9020 и отказываться от него не собираюсь до тех пор, пока не помрёт собственной смертью. Разумеется, на такой древней машине о виртуализации и речи быть не может... ;-) -- Igor Goryachev E-Mail/Jabber: i...@goryachev.org
Re: qmail or not qmail?
Hello! On Thursday 28 January 2010 19:55:14 Stanislav Vlasov wrote: В нашей дискуссии как раз понятно. Вы предпочитаете самостоятельно суперклеем склеивать велосипед из деталей очень разного происхождения, я - взять работающее решение, соединённое болтами, которые иногда надо подтягивать (в последний раз требовалось месяца два назад - поставил дрвеб, ибо у начальника инфобезопасности профессиональная паранойя и кламаву он недостаточно доверяет, в предпоследний - в сентябре, когда топам захотелось попосылать файлы в 100Мб). У меня почта интегрирована в документооборот и qmail идеально вписался в эту картину - великолепно интегрируется с любой системой. Рекомендую посмотреть статью об интеграции qmail с оракловской базой (это в проекте OpenACS, который на AOL Server, делали) - имхо просто и функционально. У меня основная СУБД постгрес, и сделано по-другому, а можно было бы и еще несколькими способами реализовать, что доказывает гибкость qmail. Супервизором у меня трудится runit (читай daemontools), tcpserver тоже вкалывает на нескольких фронтах, так что для qmail инфраструктура самая подходящая. Они к разным утилитам относятся, так что не конфликтуют. Опять же, сборка Не всегда. Часть того, что мне могло бы потребоваться - патчила smtpd. Сильно не разбирался, но не факт, что они патчили не один и тот же файл. http://dbn.smarden.org/sid/ выделяет и отдельную утилиту для отбоя, чтобы не менять оригинальный код ради нового функционала (и DJB это же советует). Не возражаю, но тогда не вижу смысла именно в кумыле, если все дырки прикрываются снаружи. Не смешивайте мух с котлетами - багфиксы с расширением функциональности. Я тоже могу заявить, что без десятка расширений и нескольких дополнительных патчей SQLite в дебиане неюзабельный. Причем, учитывая то, что от него в очередной раз отломали поддержку юникода, так оно и есть. А прилепленные мантейнером патчи - кривые, и я специально получил подтверждение этому у апстрима и послал мантейнеру - ноль реакции. Так что на мантейнеров надейся, а сам не плошай. И такой пакет есть, лежит в репозитории Gerrit Pape (если не ошибаюсь, для всех релизов дебиана, начиная с potato). В 2007-м году, когда qmail был передан в public domain, Gerrit пакеты зааплодил на ftp-master - и вот, ждем... Подозреваю - из-за отсутствия такой уж большой необходимости в кумыле именно в дистрибутиве. Там многие пакеты подолгу маринуются, так что наш случай - совсем не исключение. У меня юзеры из LDAP начинаются с uid 1. При этом, с uid 64000 - технические юзеры типа бекапилки или нагиоса. Привязку программы к какому-либо uid/gid кроме 0 я бы назвал технической проблемой разработчика. Во-первых, см. дебиан полиси, где это отнюдь не запрещается. Во-вторых, запускать весь софт от рута - это вы через край хватили. Э... Запуск и привязка - разные вещи. Скажем, uid для daemon в дебиане равен 1, а в RH - уже 2. Если какая-либо софтина посчитает, что для запуска под daemon ей необходимо и достаточно сменить uid на 1, то её автор просчитался. Здесь - аналогично. Дебиан полиси позволяет использовать этот диапазон идентификаторов для _фиксированных_ id, так что не вижу никаких противоречий. Есть _другой_ диапазон, для назначаемых динамически - но это совсем другая история. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: qmail or not qmail?
29 января 2010 г. 0:55 пользователь Alexey Pechnikov pechni...@mobigroup.ru написал: В нашей дискуссии как раз понятно. Вы предпочитаете самостоятельно суперклеем склеивать велосипед из деталей очень разного происхождения, я - взять работающее решение, соединённое болтами, которые иногда надо подтягивать (в последний раз требовалось месяца два назад - поставил [...] У меня почта интегрирована в документооборот и qmail идеально вписался в эту картину - великолепно интегрируется с любой системой. Рекомендую [...] Угу. И клеем служат патчи, которые необходимо отбирать и прикладывать и потом собирать кумыл на той же машине, где он будет работать. Про что я и говорил. Они к разным утилитам относятся, так что не конфликтуют. Опять же, сборка Не всегда. Часть того, что мне могло бы потребоваться - патчила smtpd. Сильно не разбирался, но не факт, что они патчили не один и тот же файл. http://dbn.smarden.org/sid/ выделяет и отдельную утилиту для отбоя, чтобы не менять оригинальный код ради нового функционала (и DJB это же советует). Не возражаю, но тогда не вижу смысла именно в кумыле, если все дырки прикрываются снаружи. Не смешивайте мух с котлетами - багфиксы с расширением функциональности. Я В данном случае под дыркой имелось ввиду штатное поведение кумыла - приём чего попало. тоже могу заявить, что без десятка расширений и нескольких дополнительных патчей SQLite в дебиане неюзабельный. Причем, учитывая то, что от него в очередной раз отломали поддержку юникода, так оно и есть. А прилепленные мантейнером патчи - кривые, и я специально получил подтверждение этому у апстрима и послал мантейнеру - ноль реакции. Так что на мантейнеров надейся, а сам не плошай. Не возражаю, но почему тогда для того же постфикса есть практически всё нужное и при этом довольно давно, в отличе от кумыла? Скажем, uid для daemon в дебиане равен 1, а в RH - уже 2. Если какая-либо софтина посчитает, что для запуска под daemon ей необходимо и достаточно сменить uid на 1, то её автор просчитался. Здесь - аналогично. Дебиан полиси позволяет использовать этот диапазон идентификаторов для _фиксированных_ id, так что не вижу никаких противоречий. Есть _другой_ диапазон, для назначаемых динамически - но это совсем другая история. У меня дебиан - на паре-тройке хостов. И эти хосты вполне могут использовать другие дистрибутивы, ибо почта и вебсервер - всего-навсего вспомогательная вещь, которая может быть заменена. Потому дебиан полиси не является определяющим документом для используемого софта. -- Stanislav
