from:"Slava Astashonok"

Artem Chuprina wrote:

В корне эту проблему решает DISCARD. На кой, спрашивается, говорить
тому концу, что ты не хочешь принимать письмо с вирусом, если ты его все
равно уже получил целиком? Чтобы, если это подломанная винда, она на

А если это человек, а не червь прислал письмо? Ну завирусовыный документ у
него, а он ни сном ни духом. Повторяю: нельзя просто так выкидывать
сообщения - человек должен получить уведомление о судьбе своей почты.

твой бэкапный MX с ним пошла? А online проверка на вирусы (postfix это,
кстати, тоже умеет) - это способ создать себе другую проблему. DoS.

DoS? Ой, ну откуда он возмётся? Или postfix не умеет контролировать LA?
Тогда я правильно сделал, что не выбрал его в качестве MTA ;) И не имеет
значения где почта будет отлёживаться до фактической доставки - в
локальном спуле, или на удалённом сервере, получившем в час пик 450.

Этой - не будет. Будет предыдущей. Мне, от чьего имени червяк себя
рассылает, с этого не легче. Причем вот уж к предыдущей-то системе ну
никаких претензий - она получила отлуп от следующего хопа и честно его
мне передала. В итоге, получив от тебя таких презентов с сотенку, я
подумаю, а не отстреливать ли нафиг всю почту, которую отстрелила твоя
система. Но предварительно, поскольку теперь это и от меня требует
фильтрации контента, я попытаюсь что-нибудь отстрелить тебе.

Не понял. От кого от тебя? Не я шлю безумные DSN'ы, а другой хост, и
если он поверил отправителю и его MAIL FROM, то он и виноват. Виноват так
же и в том, что скорее всего является open relay'ем для своей локальной
сети и не проверяет сообщения на вирусы. Так что претензии не ко мне а к
говнопровайдеру.

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

И вирусы, как я понял, тоже? Пусть получатель проверит - запустит и
посмотрит что получилось? :)

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:

Угу. DISCARD применяется для вирусов. Кои, собственно, тоже не
пропадают, а карантинятся на месяц. RTFM: amavisd.conf. Есть еще
скриптик, который по письму на определенный адрес высылает обратно,
когда и от кого письма на запрашивающего были пойманы за вирус. При

Зашибись. Вот о таких скриптиках я и говорю. В результате сидишь и
думаешь: кому же, чёрт побери, нужно слать уведомление - отправителю,
адрес которого на 99% подделан, или получателю о сотне вирусов уложеных в
карантин.

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

О том кто его шлёт обратно я уже писал - почтовик, который этому спаму и
позволил попасть в Сеть. Так что, повторяю, он и виновник безобразия.

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

Я вредных и не даю.

Это мы ещё разберёмся :)

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:

DB В смысле проверку? Имеется проверка отправителя? Но ведь это тоже не
DB панацея. И потом, увидев в логах достаточно таких проверок, я бы тоже
DB задумался о подрезании всего почтового трафика с проверяющей машины, как
DB спам-базо-тестилки.

Нормальные люди ограничиваются проверкой существования MX или A для
домена. Кто ж им расскажет про существование юзера?

Шутить изволите? А я вот возьму и начну слат от [EMAIL PROTECTED] или
ещё из каго домена - что ваш нормальный человек в этом случае сделает?
Ничего проверка только A или MX не даёт! А exim'овский callout или
milter-sender именно проверяет наличе пользователя, делая вид, что хочет
доставить почту от . А если хост (вот это действительно называется
борцунством) не принимает почту от , то ему прямая дорога в rfc-ignorant.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Andrey Melnikoff wrote:

 Протокол SMTP не гарантирует доставки письма получателю. Нигде и никак. 

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

 И назвать DSN NOTIFY=SUCESS,FAILURE,DELEAY можно только грязным хаком, ибо 
 a) половина систем его не умеет как таковой, 
 b) еще ~25% не поддерживает из за принципов автора.

Это является теперь официальным предлогом молча выбрасывать почту?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: psswd hash

Cryptomix_Volid_ wrote:
 чем можно создать хеши паролей по алгоритмам sha1 ssha1 des md5 blowfish
 желательно одной тулзой?

openssl, slappasswd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:

 Учитывая, что адреса, о которых идет речь, генерируются случайно (читай:
 повторяются редко - несомненно.  Это только за настоящими он будет
 редко ходить.

Подумаешь - лишняя SMTP-крннекция, которая длится секунд 5.

   Идея, как всегда, чем-то красивая, но в целом (ИМХО) бредовая.
  AM Пока цель оправдывает средства - оно имеет право жить.
 
 В данном случае, возможно, не цель оправдывает средства, а овчинка
 выделенки не стоит.

В том-то и дело, что стоит и ещё как. Этот механизм позволяет ощутимо
разгрузить почтовик потому как мы таким образом откинем процентов 70 спама
и вирусов. Вот так. :)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:

 С sendmail - это milter?  Который не позволяет внести в письмо
 информацию о том, на что именно выругался spamassassin?  Фтопку.

Согласен - возмите exim :)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:
Slava Astashonok - debian-russian@lists.debian.org @ Thu, 20 Oct 2005
10:08:34 +0400:

SA Зашибись. Вот о таких скриптиках я и говорю. В результате сидишь и
SA думаешь: кому же, чёрт побери, нужно слать уведомление - отправителю,
SA адрес которого на 99% подделан, или получателю о сотне вирусов уложеных в
SA карантин.

Вы не брезгливы. Но невнимательны. (c)

Хорошо. Кому будет писать скрипт? Конкретно. Ответ на этот вопрос мне
хочется знать потому что это ключевой момент. В случае с drweb'ом можно
было научить его слать уведомления для конкретных типов вируса, т.е.
например, червей игнорировать, а про остальные уведомлять, что в итоге в
некоторой степени приводило к нужному эффекту: человек получал
уведомление, а черви преимущественно дропались без уведомлений.

SA О том кто его шлёт обратно я уже писал - почтовик, который этому спаму и
SA позволил попасть в Сеть. Так что, повторяю, он и виновник безобразия.

Позволить спаму попасть в Сеть - это неизбежно, увы. Потому что спам -
дело индивидуальное и вероятностное. А ты что, на уровне SMTP спам
разворачиваешь?

Разворачиваю? Скорее отбиваю. А что?

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:
Slava Astashonok - debian-russian@lists.debian.org @ Thu, 20 Oct 2005
10:02:52 +0400:

SA А если это человек, а не червь прислал письмо? Ну завирусовыный
SA документ у него, а он ни сном ни духом. Повторяю: нельзя просто так
SA выкидывать сообщения - человек должен получить уведомление о судьбе
SA своей почты.

А кто его выкидывает? Ты? А...

А DISCARD работает как-то иначе? Ну, расскажите, пожалуйста - мы же,
надеюсь, не просто плевками обмениваемся? :)

SA DoS? Ой, ну откуда он возмётся? Или postfix не умеет контролировать LA?
SA Тогда я правильно сделал, что не выбрал его в качестве MTA ;) И не имеет
SA значения где почта будет отлёживаться до фактической доставки - в
SA локальном спуле, или на удалённом сервере, получившем в час пик 450.

... и в следующий раз важное письмо поползет только через полчаса. И
опять наткнется на 450... Это и есть DoS. В post-SMTP схеме оно будет
обработано в порядке очереди, а в твоей - как повезет. _Если_ повезет.

Очередь тоже может вырасти на столько, что очень важное письмо доберётся
до адресата спустя сутки, так что не надо. А на практике я clamav'а в
top'е не наблюдал даже когда сервак работал на каком-то сраном целероне.

SA Не понял. От кого от тебя? Не я шлю безумные DSN'ы, а другой хост, и
SA если он поверил отправителю и его MAIL FROM, то он и виноват. Виноват так
SA же и в том, что скорее всего является open relay'ем для своей локальной
SA сети и не проверяет сообщения на вирусы. Так что претензии не ко мне а к
SA говнопровайдеру.

Для своей локальной сети все являются опен релеями. А кто пытается
ввести проверку, того очень быстро начинают больно пинать. Ибо смысл
понятия локальная сеть для MTA - именно в том, что из нее принимается
любая почта. С проверкой на вирусы, конечно, да. Но проверка на вирусы
- дело ресурсоемкое, не слишком простое и от свежих вирусов спасающее
плохо.

Ну, это у кого как. Но то, что почти у всех это опен релей я хорошо вижу
на куче идиотских DSN'ов. Когда-то это было приемлимо, но не теперь.
Неужели вы принимаете любую почту только на основании того, что она
направляется в ваш домен? А ведь раньше почтовики так и работали - сначала
принимали, а потом убеждались в существовании адресата. но теперь то всё
изменилось и бездумно принимать всю почту из локальной сети глупо. Неужели
вы серьёзно отметаете возможность проникновения червя в локальную сеть?
Это по меньшей мере не серьёзно. Авторизация плюс обязательная проверка
существования ящика отправителя - вот минимальные требования хорошего
граничного почтовика, а желательно ещё и антивирус на нём.

SA И вирусы, как я понял, тоже? Пусть получатель проверит - запустит и
SA посмотрит что получилось? :)

Чини понималку. Пора.

Шутка юмора это была. Возвращаю комлемент назад.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:

SA Хорошо. Кому будет писать скрипт? Конкретно. Ответ на этот вопрос мне
SA хочется знать потому что это ключевой момент. В случае с drweb'ом можно
SA было научить его слать уведомления для конкретных типов вируса, т.е.
SA например, червей игнорировать, а про остальные уведомлять, что в итоге в
SA некоторой степени приводило к нужному эффекту: человек получал
SA уведомление, а черви преимущественно дропались без уведомлений.

Скрипт будет писать тому, кто прислал ему запрос.

Подписался на рассылку что ли? Или как? Повторяю свой начальный вопрос:
как ламероватый пользователь узнает, что его письмо содержало вирус и было
поэтому прибито?

SA Разворачиваю? Скорее отбиваю. А что?

А как ты отличаешь спам от не-спама? А то у меня некоторые письма от
нужных роботов в спам попадают с завидной регулярностью (ну, блин,
роботы такие). Я бы ОЧЕНЬ НЕ ХОТЕЛ, чтобы они до меня не доходили.

С роботами есть проблемы. Причём, они не столько связаны с кривыми
заголовками, на которые очень резко реагирует spamassassin, а в моём
случае - с проверкой адреса отправителя. Ну, что поделаешь - я выбрал своё
меньшее из зол.

Нет, whitelist помогает только после того, как адрес будет отслежен, а
мне и первое письмо ценно. А еще есть получатели, которые читают
письма, похожие на спам, ибо так пишут клиенты. И такие получатели есть
в трех из доброго десятка доменов, на которые я релею почту, и меня о
появлении новых не предупреждают.

Есть такие и у меня. Причём, читают не только похожую, но и спам просят не
фильтровать. Вношу таким юзерам соответсвующие флаги в LDAP. Но тут лежит
одна здоровенная грабля - это несколько RCPT TO в одной сесси, причём
когда в получателях пользователи из разных классов - один хочет спам
получать, а другой нет. Приходится выкручиваться и получателям класса,
отличного от класса первого адресата, говорить 450. Пока так.

Кстати, постой-постой... Ты с каким кодом отбиваешь? 450? Сиречь
отправитель узнает о том, что его письмо не доставлено, дней через пять?

На спам и вирусы говорю 550 и рву соединение.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:

  SA В том-то и дело, что стоит и ещё как. Этот механизм позволяет
  SA ощутимо разгрузить почтовик потому как мы таким образом откинем
  SA процентов 70 спама и вирусов. Вот так. :)
 
 Это уже после 90%-го отсева за неподобающий хендшейк?

Ага - мы ещё в несколько раз снижаем нагрузку на контентодробилки.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:

Скрипт будет писать тому, кто прислал ему запрос.

SA Подписался на рассылку что ли? Или как? Повторяю свой начальный
SA вопрос: как ламероватый пользователь узнает, что его письмо
SA содержало вирус и было поэтому прибито?

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

Вот это я и ожидал услышать. Выходит, что нужно сразу слать два письма -
одно с вложением и следом второе - с вопросом ну, что, получил?. Сама
возможность исчезновения письма будет приводить к тому, что пользователи
через минуту после отправки будут начинать интересоваться его судьбой.
Неужели вы не чувствуете, что это попахивает халтурой - какое будет
доверие к такой почтовой системе? Только от того, что почта стала ходить
по сетям, где возможны потери пакетов, она не должна становиться
ненадёжной. Либо письмо доставлено, либо не доставлено и отпраитель
получил об этом уведомление - есть только два варианта. А то в итоге не
почтовая служба получится, а мочало какое-то. Так вот, возвращаясь от
лирики к практике: online-SMTP обработка позволяет уцелеть меж двух огней
- с одной стороны она не дропает ни одного сообщения, а с другой не шлёт
бесполезных DSN'ов.

SA С роботами есть проблемы. Причём, они не столько связаны с кривыми
SA заголовками, на которые очень резко реагирует spamassassin, а в
SA моём случае - с проверкой адреса отправителя. Ну, что поделаешь - я
SA выбрал своё меньшее из зол.

Вот и я тоже. У меня в результате зла нет почти совсем.

Ну, про SMTP-callout я особо спорить и не желаю - вещица на любителя. Есть
и сильные стороны и слабые. Я нахожу, что первых больше.

SA Есть такие и у меня. Причём, читают не только похожую, но и спам
SA просят не фильтровать. Вношу таким юзерам соответсвующие флаги в
SA LDAP. Но тут лежит одна здоровенная грабля - это несколько RCPT TO
SA в одной сесси, причём когда в получателях пользователи из разных
SA классов - один хочет спам получать, а другой нет. Приходится
SA выкручиваться и получателям класса, отличного от класса первого
SA адресата, говорить 450. Пока так.

Схема post-SMTP с этим справляться умеет гораздо более грамотно.

Во-первых, хочу напомнить, что это происходит только при приёме спама. А
во-вторых, это грамотно как именно реализуется? Приняли почту якобы
всем, а доставили только желающим получать спам, а остальным сгенерировали
DSN? Или дропнули без DSN?

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:

SA А DISCARD работает как-то иначе?

Ага. Если пользоваться амависом.

SA Ну, расскажите, пожалуйста - мы же, надеюсь, не просто плевками
SA обмениваемся? :)

Очень просто. Прежде чем сказать 250, он прикопает письмо в карантине.
Откуда, если оно за месяц не потребовалось, его тихо прибьет cron.

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

Я понимаю, что апологетам post-SMTP обработки ничего другого не остаётся,
и я им сочувствую, но полностью одобрить такие методы не могу по
профессионально-этическим принципам.

SA Очередь тоже может вырасти на столько, что очень важное письмо
SA доберётся до адресата спустя сутки, так что не надо.

Тут я его хотя бы смогу в случае острой необходимости вытащить руками.
Потому что оно уже у меня.

Ну, хорошо, хорошо, я в случае крайней необходимости почти ничего не
сделаю. Осталось только посчитать на какую почтовую активность хватит
тысячного целерона и увидеть, что техническое решение этого вопроса
(увеличение вычислительных мощностей) будет копеечным для конторы, которой
этого целерона не хватит.

SA Ну, это у кого как. Но то, что почти у всех это опен релей я хорошо
SA вижу на куче идиотских DSN'ов. Когда-то это было приемлимо, но не
SA теперь. Неужели вы принимаете любую почту только на основании
SA того, что она направляется в ваш домен?

Когда _в_ мой домен - это проще. Адрес получателя обязательно должен
быть валидным, иначе как я письмо доставлю? А адрес отправителя -
только в том случае, если я ему что-то решу доставить. Что совершенно
не факт.

Это был риторический вопрос :) Разумеется адрес получателя должен
существовать и эту проверку _теперь_ все делают в течение SMTP-сессии, а
раньше, как я писал - нет - потому что спама не было. Это я говорил к
вопросу о проверке валидности envelope sender'а в почте, отправляемой
внутренними пользователями вовне: _теперь_ этот, так сказать, жест
вежливости по отношению к другим (мол, мы гарантируем, что адрес
отправителя действительно наш) мне лично не кажется надуманным.

SA А ведь раньше почтовики так и работали - сначала принимали, а потом
SA убеждались в существовании адресата. но теперь то всё изменилось и
SA бездумно принимать всю почту из локальной сети глупо. Неужели вы
SA серьёзно отметаете возможность проникновения червя в локальную
SA сеть? Это по меньшей мере не серьёзно. Авторизация плюс
SA обязательная проверка существования ящика отправителя - вот
SA минимальные требования хорошего граничного почтовика, а желательно
SA ещё и антивирус на нём.

А авторизация от нынешних червяков уже не шибко спасает. Прикопанный на
диске пароль они тоже умеют прочесть. Вернее, просто воспользоваться
той же самой почтовкой для отправки.

Да, но пока к счастью ещё где-то спасает, особенно если почтовый клиент не
оутглюк. Но главное - авторизация позволяет проверить допустимось значения
envelope sender'а, т.е. запретить его спуфинг.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Andrey Melnikoff wrote:

Протокол SMTP не гарантирует доставки письма получателю. Нигде и никак.

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

Покажие документ, где это написанно. Really. RFC/STD/чёнибудь.

RFC 821

If a server-SMTP has accepted the task of relaying the mail and
later finds that the forward-path is incorrect or that the mail
cannot be delivered for whatever reason, then it must construct an
undeliverable mail notification message and send it to the
originator of the undeliverable mail (as indicated by the
reverse-path).

This notification message must be from the server-SMTP at this
host. Of course, server-SMTPs should not send notification
messages about problems with notification messages. One way to
prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a
message is relayed it is permissible to leave the reverse-path
null. A MAIL command with a null reverse-path appears as follows:

MAIL FROM:

RFC 2821

If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null () reverse path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line). However,
if this address is null (), the receiver-SMTP MUST NOT send a
notification.

И назвать DSN NOTIFY=SUCESS,FAILURE,DELEAY можно только грязным хаком, ибо
a) половина систем его не умеет как таковой,
b) еще ~25% не поддерживает из за принципов автора.

Это является теперь официальным предлогом молча выбрасывать почту?

Нет - это такой момент, когда ты получаешь DSN с надписью Relayed to
non-aware DSN mailer, как ты узнаешь что онный non-aware мыллер не угробил
сообщение?

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:

SA Вот это я и ожидал услышать. Выходит, что нужно сразу слать два
SA письма - одно с вложением и следом второе - с вопросом ну, что,
SA получил?. Сама возможность исчезновения письма будет приводить к
SA тому, что пользователи через минуту после отправки будут начинать
SA интересоваться его судьбой. Неужели вы не чувствуете, что это
SA попахивает халтурой - какое будет доверие к такой почтовой системе?

Давай ты не будешь спорить о вкусе устриц с теми, кто их ел?

SA Только от того, что почта стала ходить по сетям, где возможны
SA потери пакетов, она не должна становиться ненадёжной. Либо письмо
SA доставлено, либо не доставлено и отпраитель получил об этом
SA уведомление - есть только два варианта. А то в итоге не почтовая
SA служба получится, а мочало какое-то. Так вот, возвращаясь от лирики
SA к практике: online-SMTP обработка позволяет уцелеть меж двух огней
SA - с одной стороны она не дропает ни одного сообщения, а с другой не
SA шлёт бесполезных DSN'ов.

Если речь идет о сферическом MTA в вакууме - да.

Это как раз схема не сферического MTA, а MTA, функционирующего в
_современном_ интернете. Это qmail и прочее красивое на бумаге наследие
прошлого (я конкретно о post-SMTP обработке почты) хорошо работает в
вакууме, но когда начинает переть спам и вирусы - либо дропает сообщения,
либо, что чаще, засыпает невинных пользователей DSN'ами.

SA Во-первых, хочу напомнить, что это происходит только при приёме
SA спама. А во-вторых, это грамотно как именно реализуется? Приняли
SA почту якобы всем, а доставили только желающим получать спам, а
SA остальным сгенерировали DSN? Или дропнули без DSN?

Можно так, можно эдак. Как скажешь. Только если среди получателей есть
не только любители спама, письмо на этот предмет проверяться будет, а
если только - то и проверяться не будет.

На всякий случай (я смотрю не все знают об этом факте): почтовые стандарты
_требуют_ или доставить письмо или отправить DSN. Возмите на заметку.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:
  Протокол SMTP не гарантирует доставки письма получателю. Нигде и никак. 
  
  SMTP гарантирует как минимум, что отправитель узнает о том, что письмо не
  было доставлено.
   
   Покажие документ, где это написанно. Really. RFC/STD/чёнибудь.
 
  SA RFC 821
 А оно delivered, кстати.  А что в /dev/null - ну вот политика тут такая.

  SA По приведённым RFC не бывает на столько non-aware, что б совсем молча
  SA дропали. А конфинурации бывают, вот только стандарт они нарушают.
 
 RFC 821 - это только SMTP.  А мы про доставку почты вообще.  Разница
 понятна?  Так покажите стандарт на доставку...

Демогогия. По делу есть что сказать?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

Artem Chuprina wrote:

SA Ну, хорошо, хорошо, я в случае крайней необходимости почти ничего
SA не сделаю. Осталось только посчитать на какую почтовую активность
SA хватит тысячного целерона и увидеть, что техническое решение этого
SA вопроса (увеличение вычислительных мощностей) будет копеечным для
SA конторы, которой этого целерона не хватит.

У меня есть свой собственный сервер. Не конторский. 300-й целерон и
128 мег памяти. Если ты мне подаришь ему замену, я даже специально ради
тебя сделаю там in-SMTP проверку.

А у меня дома на P166 и что? Речь не о том как реализовать MTA на помойном
железе, а как этот MTA должен вести себя в совремнном интернете.

SA Это был риторический вопрос :) Разумеется адрес получателя должен
SA существовать и эту проверку _теперь_ все делают в течение SMTP-сессии, а
SA раньше, как я писал - нет - потому что спама не было. Это я говорил к
SA вопросу о проверке валидности envelope sender'а в почте, отправляемой
SA внутренними пользователями вовне: _теперь_ этот, так сказать, жест
SA вежливости по отношению к другим (мол, мы гарантируем, что адрес
SA отправителя действительно наш) мне лично не кажется надуманным.

А я не гарантирую, что он мой. Когда я отправляю письмо через MTA фирмы
со своего домашнего адреса, он ничего про мой домашний адрес
гарантировать не может. И когда я отправляю со своего сервера письмо,
полученное по UUCP с ноутбука, этот сервер про этот ноутбук тоже ничего
гарантировать не может. Кроме того, что почту на произвольный адрес в
домене wizzle.ran.pp.ru (и еще в нескольких доменах) он положит в спул
тому же UUCP.

Ну, не гарантируете и не надо - червей то у вас внутри быть не может.

Которые умеют гонять почту исключительно по SMTP - им этого всего не
понять. И того, что почта может быть отправлена локально и SMTP-сессии
там вообще не было как класса (и это не повод не проверять его на
вирусы) - тоже...

Это вообще к чему?

SA Да, но пока к счастью ещё где-то спасает, особенно если почтовый
SA клиент не оутглюк. Но главное - авторизация позволяет проверить
SA допустимось значения envelope sender'а, т.е. запретить его спуфинг.

Ага, и потом долго настраивать - тому два дополнительных адреса
прописать, этому три, uucp вообще домены целиком разрешать (а твой exim
это переживет?)... А у меня (surprise!) ни одного лдапа на всю контору,
не считая криво поставленного Active Directory, у которого и в прямой
постановке прибабахов хватает... И функции админа у меня не основные.

В огороде бузина, а в Киеве дядька.

У меня такое ощущение, что ничего нового мы в этом треде уже не услышим.
Стороны высказались.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: spamassassin + exim

2005-10-18 Пенетрантность Slava Astashonok

Artem Chuprina wrote:

PA sa-exim отвергает письмо прямо во время smtp-сессии.
PA amavis же его сначала засасывает, проверяет и потом назад суёт в очередь,
PA так что
PA * одно и тоже письмо проходит через МТА два раза
PA * жрёт в два раза больше ресурсов,

Гонево.

PA * усложняет подсчёт статистики,
PA * и вообще опасно: если ты примешь письмо, пропустишь его в amavis, а
PA потом система скрешится (или MTA остановится), то письмо будет потеряно
PA (в amavis нету своей очереди)

И не должно быть. Очередь есть у exim. К нему что, амавис только через
задницу можно прикрутить? Если да, то правильно я не стал его
рассматривать как MTA...

Напрасно. Но вопроc в другом - по поводу amavis и прочих аналогичных
решений, отрабатывающих _после_ приёма письма: что предлагаете делать с
отвергнутым письмом? Это серьёзнейший вопрос - я уже как-то тут или в Fido
писал, что уведомлений о недошедшем спаме с якобы моего адреса и прочих
DSN'ов получаю раз в 30 больше чем собственно самого спама (последний
успешно фильтруется). К этому приводит _устаревшая_ технология post-SMTP
обработки почты. В то время как online-SMTP обработка решает эту проблему
в корне (и exim, кстати, это умеет, как и sendmail+milter).

Кто-то скажет, что раз письмо определено как спам или вирус его можно
молча дропнуть, и будет не прав! Почтовая система расписалась в принятии
почты, сказав 250 на DATA, и взяла на себя _ответственность_ за дальнейшую
доставку, и прежде чем просто так взять и выкинуть писмо из очереди она
должна быть абсолютно уверена, что это письмо было отправлено не
человеком, а червём или спам-программой. В случае с червями ещё
более-менее ясно: там можно по названию вируса определить, а как быть с
остальными срабатываниями (я уже не говорю о ложных)? При online же
проверке даже можно не очень бояться ложных срабатываний - письмо не будет
_молча_ выброшено. И бессмысленных DSN'ов отправлено тоже не будет (во
всяком случае этой почтовой системой). В результате экономится время
пользователя - в первом случае не нужно искать куда же бесследно делось
письмо, а во втором - не нужно удалять мусор из почтового ящика.

PS
Про amavis-milter я уже в курсе, но речь-то шла не о sendmail, как я
понимаю :)

PPS
Да что говорить об спаме и вирусах - народ элементарную проверку
существования получателя в течение SMTP-сессии не делает. Кашмар. Скоро на
борьбу с такими горе-постмастерами будет уходить времени больше, чем на
возню со спамом. :(

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

samba уже подзадолбала

2005-08-15 Пенетрантность Slava Astashonok

Тут уже описывали похожую ситуацию. Моя заключается в том, что временами
(сегодня вообще сразу на четырёх серверах почти одновременно) зависают
процессы smbd. Со стороны это выглядит это так, что samba перестаёт отвечать
на запросы в результате чего клиенты мучительно тормозят и отваливаются по
тайм-ауту. Зависшие smbd реагируют только на SIGKILL. Вот характерной завис:

#0  0x2d446052 in select () from /lib/libc.so.6
#1  0x2d232734 in ?? () from /usr/lib/libldap_r.so.2
#2  0x083fb5b0 in ?? ()
#3  0x083fb6b0 in ?? ()
#4  0x2d21dbf9 in ldap_int_select () from /usr/lib/libldap_r.so.2
#5  0x2d209cef in ldap_result () from /usr/lib/libldap_r.so.2
#6  0x2d20c786 in ldap_search_st () from /usr/lib/libldap_r.so.2
#7  0x2d9473e9 in ?? () from /lib/libnss_ldap.so.2
#8  0x083fb400 in ?? ()
#9  0x2d953c38 in ?? () from /lib/libnss_ldap.so.2
#10 0x0002 in ?? ()
#11 0x5d36730c in ?? ()
#12 0x2d954b9c in ?? () from /lib/libnss_ldap.so.2
#13 0x in ?? ()
#14 0x in ?? ()
#15 0x5d367b78 in ?? ()
#16 0x0001 in ?? ()
#17 0x in ?? ()
#18 0x5d3672b4 in ?? ()
#19 0x2d953888 in ?? () from /lib/libnss_ldap.so.2
#20 0x0001 in ?? ()
#21 0x2d953888 in ?? () from /lib/libnss_ldap.so.2
#22 0x5d3672c4 in ?? ()

На всех серверах sarge с последними апдейтами: libc 2.3.2.ds1-22, samba
3.0.14a-3, libldap2 2.1.30-8, libnss-ldap 238-1. Никакой закономерности
установить не удалось. Упоминаний в Сети тоже не нашёл. Ещё примечательный
факт заключается в том, что баг наблюдается пока только на uni-процессорных
машинах. Никто с похожим не сталкивался?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: samba уже подзадолбал а

2005-08-15 Пенетрантность Slava Astashonok

Konstantin Matyukhin wrote:

...
   соответствующие системные id. Я закоментировал nobody в passwd и
   изменил sambaSID в ldap для nobody на S-x-501. Закоментировал
   map to guest = Bad User
   и убрал  guest из passdb backend.
 
   В результате 5 часов работы - полет нормальный процессы, использующие
   IPC$ не зависают. (правда я еще длбавил в ldap запись для root c
   objectClass только top и sambaSamAccount и
   sambaSID=S-xxx-1000).

Не, тут у меня всё аккуратно: и nobody одинаковые и root'ы и sid'ы у них
правильные. Я считаю, что лично мой случай не связан с некорректностью данных
в ldap'е. Похоже, что в каком-то месте коктейля из nss, ldap и samba вылазит
race condition. Буду искать.

 Сам попробовать не могу, т.к. после безуспешных попыток заставить работать
 sambу из sarge, пришлось откатиться на версию из woody.   

Понятно. Мне отступать некуда.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: 2 internet connections

2005-07-14 Пенетрантность Slava Astashonok


Sergey Lutay wrote:

проблема в том, что хочеться отвечать на соединения с обоих интерфейсов. 
то есть пришел пакет на eth0 - днатим внутрь сети, а ответ посылаем 
обратно через eth0. И также чтоб на eth1.   Адреса естественно на этих 
интерфейсах разные то есть если обращались к.А.А.А.А , то ответ не 
пришел от Б.Б.Б.Б


man iptables /--ctorigdst

Например, адреса на внешних интерфейсах 100.0.1.1 и 100.0.2.1 соотвественно, 
тогда вот такими правилами можно пометить пакеты-ответы


PREROUTING -t mangle -m conntrack --ctorigdst 100.0.1.1 -j MARK --set-mark 1
PREROUTING -t mangle -m conntrack --ctorigdst 100.0.2.1 -j MARK --set-mark 2

и разогнать их по правильным направлениям:

ip ro add default via 100.0.1.254 table 1
ip ru add fwmark 1 lookup 1

ip ro add default via 100.0.2.254 table 2
ip ru add fwmark 2 lookup 2

где 100.0.1.254 и 100.0.2.254 - шлюзы соответсвующих каналов


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Где nologin?

2005-07-14 Пенетрантность Slava Astashonok


Anatoly Pugachev wrote:


--
#!/bin/bash
echo This account currently not available
logout
--

это пишем в /bin/nologin (без --) и ставим права на исполнение
(chmod +x /bin/nologin)



только наверное в данный скрипт вначале, перед echo, все-таки было бы неплохо 
добавить

trap  INT
trap  HUP
trap  QUIT
trap  KILL
trap  TSTP

а то представляем себе ситуацию, когда пользователь логинится и нажимает
ctrl-c .


И что по-вашему он в результате прервёт? Скрипт? А шелл останется? :-D
Нет - будет остановлен _шелл_, выполняющий скрипт, и злоумышленник тут же 
разлогиниться.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Где nologin?

2005-07-14 Пенетрантность Slava Astashonok


Alexander wrote:
Чудеса да и только! С удивлением обнаружил отсутствие в Debian утилиты 
nologin. А что заменяет ее в Deb?


Веселее всего в качестве шелл сделать fortune с BOFH'овскими отмазками ;)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Как переехать с samba 2.2 на samba 3.0 не п ереподключая компью теры - члены домена

2005-07-08 Пенетрантность Slava Astashonok


[EMAIL PROTECTED] wrote:


Спасибо, помогло. Однако есть интересная особенность - в выдаваемых
списках пользователей нет пользователей, только группы. Хотя вход в
домен происходит нормально.


Да, на 3.0.14 у меня аналогичный глюк. Но я точно помню, что на каких-то 
других 3.0.x я его не наблюдал. И что ещё забавнее, тут недавно одно 
подразделение переводили на 3.0.14, так, ребята утверждают, что список 
пользователей исчез в процессе, т.е. был и исчез. Мистика какая-то ;) В любом 
случае это не критично: пользователя если очень нужно можно ввести руками.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Как переехать с samba 2.2 на samba 3.0 не п ереподключая компью теры - члены домена


[EMAIL PROTECTED] wrote:
[...]

Создал пользователя и машину в ldap, установив
для них соответствующие старые sidы.

Результат - машина с XP не может пройти аутентификацию в домене по
причине отсутствия записи о машине.

Скажите кто-нибудь пробовал решать такую задачу? Это возможно или нет?
А если да, то как?


Членство машины в домене определяется соответсвующими SID'ами, но его ещё 
нужно и подтвердить. Ключами для этого служат LM и NT пароли машин - их тоже 
нужно скопировать.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Посоветуйте готов ую систему учёта сете вого трафика


Mikhail Gusarov wrote:


AAL Вроде как syslog умеет на другую машину логи пересылать - этим можно
AAL воспользоваться или нет?

Оно по UDP шлет - для подсчета трафика лучше не использовать.


И что? У вас на eth такие большие потери? Протокол NetFlow (де-факто стандарт 
для учёта и мониторинга трафика) в качестве транспорта использует UDP.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Посоветуйте готов ую систему учёта сете вого трафика


Andrey A Lubimets wrote:

сам ulog-acctd мне понравился, только вот чем обрабатывать 1.5 гига 
логов в gzip?


Кашмар.


Т.е. он просто в текстовый файл всё пишет?
1,5 гига это за какой период/трафик, а то у меня /var всего 1 гиг :-/

Вроде как syslog умеет на другую машину логи пересылать - этим можно 
воспользоваться или нет?




попробовал тупо загрузить часть данных в postgres - как и ожидалось 
тормоз ещё тот (замена на mysql явно не решит проблему), надо как-то 
группировать данные за прошлые периоды -  нет времени заняться этим.



а ulogd (ulogd-mysql, ulogd-pgsql) -  никто не пробовал?


Присоединяюсь к совету воспользоваться fprobe-ulog + flow-tools


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Посоветуйте готов ую систему учёта сете вого трафика


[EMAIL PROTECTED] wrote:

Я вот что-то не могу понять ? Вам для учета или мониторинга?

учет насколько я понимаю - это подсчет.
Я использую netacct-mysql - никаких проблем не возникает с ним, есть
веб-интерфейс


Если для мониторинга , то тут конечно netflow и думать придумывать особо
нечего больше


Подсчёт - это частный случай мониторинга. И нередко по результатам подсчёта 
требуется провести разбор полётов. Поэтому хочется (ну, скажем, лично мне) 
иметь более детализированные данные нежели просто счётчики. И NetFlow тут 
очень удобен, потому как позволяет выбрать приемлимое соотношение между 
объёмом и детализацией данных путём изменения параметров агрегации.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Посоветуйте готов ую систему учёта сете вого трафика

Andrey A Lubimets wrote:

Вообще (видимо рискую разжечь флейм) хотелось бы услышать более-менее
компетентное мнение на тему iptables(ulog) vs libpcap.

Ну или кто подскажет что почитать на эту тему.

Читать придётся в основном флейм :-D Практически весь он будет посвящён тому,
что pcap теряет пакеты. Но на самом деле это urban legend. Точнее, скажем так,
теряет pcap не больше ulog'а - и там и там могут быть потери если не
предпринять некоторых мер. Так что на этом уровне они равны. Далее: pcap
портабелен, что очевидный плюс, также очень привлекательно выглядят его гибкие
фильтры и pcap слышит всё, тогда как ulog только ip. Однако, получаемая
через pcap информация о пакете не содержит ни какой информации о маршруте.
Т.е. определить вошёл данный пакет или выходит и через какой интерфейс на
основании _только_ полученной из pcap информации невозможно. Последний
недостаток pcap, на мой взгляд, перевешивает все его плюсы (в рамках
обсуждаемой темы учёта и мониторинга трафика, конечно).

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Cisco Aironet 340

2005-07-04 Пенетрантность Slava Astashonok


Pavel Shurubura wrote:


  Не получается сконфигурировать PCI карточку Cisco Aironet 340
series. Ядро 2.4.27 из пакета
kernel-image-2.4.27-2-686_2.4.27-8_i386.deb

  Скачал драйвера с cisco.com, скомпилировал модуль.


[...]

К чему такие сложности? Заявляется, что стандартный ядерный модуль airo 
поддерживает 34x. Дальнейшая настройка wifi осуществляется через iwconfig из 
комплекта wireless-tools. Я имел дело с 350, проблем вроде не было.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: SSH и безпарольный логин

2005-07-04 Пенетрантность Slava Astashonok


Pavel Shurubura wrote:
 Max Dmitrichenko [EMAIL PROTECTED] wrote:

[...]


 Но насколько я понял, там (на серваке) в конфиге нужно
 сопоставить этому ключу имя машины, с которой делается
 попытка логина, и имя пользователя на этой машине. А теперь
 вопрос: у dial-up соединений dns-имя машины и ip не
 постоянны, можно ли как-нибудь это обойти?


  По-моему, любой у кого есть закрытый ключ может залогиниться
на сервер с любого хоста. 


Если об этом явно в authorized_keys не попросить:
from=10.11.0.222 ssh-dss B3NzaC1kc3MAAAC...


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: hdparm не может выста вить DMA

2005-06-21 Пенетрантность Slava Astashonok


Dmitry-T wrote:


То есть, как понял, драйвер для NFORCE2 слишком 
поздно загружается... У
меня Sarge, ядро 2.6.8-2-k7 (дистрибутивное). Google 
советует
вкомпилировать нужный модуль в ядро, то 
есть пересобирать... А есть
другие варианты?


Забавно то, что в 2.4 модуль соответствующего IDE можно грузить и после 
ide-detect - UDMA включается и в этом случае. В 2.6 ситуация изменилась. Нужно 
изменять порядок загрузки модулей в initrd.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Ключи mencoder

2005-06-14 Пенетрантность Slava Astashonok


Andrey Vorobets wrote:
mplayer/mencoder 
wmv  mpg1  mpg2 (  ).


   .   
:-(


.  
 .
   encoding-tips.txt, - 
 bpp  videobitrate.3- .

Re: vlan

2005-04-20 Пенетрантность Slava Astashonok

Sergey Matashuk wrote:
   Debian   vlan? 
   2 : 
 3- ? ;-)
1.  /etc/init.d/networking 
2.  /etc/init.d/vlan  networking. 
3. /etc/network/interfaces c pre-up vconfig add ...
3- - __ ,   .
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Sarge

2005-02-02 Пенетрантность Slava Astashonok

Sergey Matashuk wrote:
Hi, All
  :  Sarge?
 (pool/main/a/???/???.deb)
, . 
 Packages.gz, grep   ,   wget.
,?, , 
, ,, 
, Packages.
,   : http://0n.ru/pub/debian-pool.sh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: modprobe не загружает м одули

2005-01-21 Пенетрантность Slava Astashonok


Timur Elzhov wrote:

Доброе время суток.

Для проигрывания звука мне нужно загрузить два модуля, ac97_codec.o и
i810_audio.o.
  insmod /lib/modules/2.4.26/kernel/drivers/sound/ac97_codec.o

прекрасно работает. Но если вместо этого сазать modprobe ac97_codec,
то он не напишет ничего и модуль не загрузится.



Да, что-то сломали. После последнего dist-upgrade в sarge наблюдаю такую же 
каритину: insmod работает, depmod зависимости строит, modprobe молча ничего не 
делает. modutils 2.4.26-1.2. Разбираться пока времени не было.

Re: kill -9

2004-12-26 Пенетрантность Slava Astashonok


Artem Chuprina wrote:


 SA Дистабилизируется тут только пользователь, который испытывает законное
 SA раздражение от того, что не может послушать музыку ;-)

Вообще говоря, не факт.  Глючный драйвер может вырубить всех соседей по
контроллеру, а то и вообще всю подсистему.


Мы придаём одному слову разную смысловую окраску. Аналогичным образом соседей 
по котроллеру может вырубить просто излешне высокая нагрузка на один из 
носистелей, но всё вернётся в исходное состояние как только спадёт нагрузка 
или перестанут запрашивать чтение сбойного сектора. А дистабилизация системы - 
это, например, возможные последствия oops'а: чёрт его знает в какой позе 
сейчас ядро, может толкни - и завалится, а может и без посторонней помощи 
через час лапти склеит. Фраза больной стабилен - из этой же оперы.

Re: kmail жены

2004-12-25 Пенетрантность Slava Astashonok


Artem Zolochewski wrote:

hi all,

Подскажите плиз, как бы мне под моей сессией kde запустить kmail жены, чтоб 
принять ее почту.
Ну и в принципе, как запускать X приложение от имени другого пользователя под 
своей сессией?


Хм. su случайно не для этого? ;)

Re: kill -9

2004-12-25 Пенетрантность Slava Astashonok


Gossen Alexey wrote:


теперь филосовский вопрос. программы которого делают системные вызовы от
пользователя, приводящие к дестабилизации системы, это нехорошая фича, я
прав?


Дистабилизируется тут только пользователь, который испытывает законное 
раздражение от того, что не может послушать музыку ;-)

Re: kmail жены

2004-12-25 Пенетрантность Slava Astashonok


Alexander GQ Gerasiov wrote:


SA Хм. su случайно не для этого? ;)
Ну если с su то еще колдовать придется чтобы иксы позволили.


Колдовать - слишком сильно сказано.

Re: exim4 relay control

2004-12-24 Пенетрантность Slava Astashonok


Dmitry Fedoseev wrote:

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

Имеется exim4, через который почта из внутренней сети ходит наружу. Т.е
relay разрешен для всех хостов внутренней сети. Полученная почта
складывается тут же и читается посредством POP3. Все традиционно. 


Хочется ввести дополнительное ограничение - часть пользователей, имеющих
учетные записи на этой машинке не должна иметь доступа наружу - ни
получать, ни отправлять, только между собой переписываться. Нормальные
пользователи - как и прежде. 


Помогите acl написать. И как правильнее группу задвинутых оформить?


У меня ldap. Делаю приблизительно так:

  require
message = Authentication required
authenticated = *
  accept
condition = ISlocalDomain
  accept
condition = ${lookup ldapm{LDAPAUTH \
  ldap:///LDAPBASE\
  ?uid?sub\
  ?((confValue=active)(confValue=mailRelay)(uid=$authenticated_id))}\
  {yes}{no}}
  deny message = Relaying denied

Т.е. в локальные домены можно слать кому угодно, а наружу - только тем у кого 
имеется атрибут confValue=mailRelay, в противном случае - Relaying denied.

Re: lvm

2004-12-17 Пенетрантность Slava Astashonok


Artem Chuprina wrote:


Таки если я правильно ошибаюсь, initrd при инсталляции пакета делается,
а не при компиляции...


Если использовать персональный initrd для каждого из хостов, то так оно и 
должно быть. А если один на все случаи жизни - то при компиляции.

Re: lvm




Угу, доку скачал, буду читать.  А инсталлятор про него еще не знает?  А
ядро, с которым он грузится?  На предмет загрузки с root=...?


Про root= придётся забыть. Нужно делать более продвинутый initrd. Могу 
поделиться примером.

Re: lvm


Alexander Kogan wrote:


Это почему это забыть? initrd этому не мешает
А зачем примеры initrd? Дебиан его автоматически вполне нормальный делает


Потому, что не root=/dev/mapper/vg00-root ядро не поймёт, а кода активации 
lvm-томов я в debian'овском initrd не видел.

Re: lvm


Alexander Kogan wrote:


Это почему это забыть? initrd этому не мешает
А зачем примеры initrd? Дебиан его автоматически вполне нормальный делает


Блин, опечатался.
Потому, что root=/dev/mapper/vg00-root ядро не поймёт, а кода активации
lvm-томов я в debian'овском initrd не видел.

Re: lvm



если прописать ROOT=/dev/evms/root_volume в /etc/mkinitrd/mkinitrd.conf, то 
postinst скрипт kernel-image-...'a сделает initrd для evms, в который 
включится evms_activate (естественно, при установленных пакетах evms*). Либо 
сказать mkinitrd -r /dev/evms/root ... .


Когда я писал про root= имел в виду, что в случае lvm уже не ядро его 
обрабатывает, а initrd скрипт: получаем 0 в /proc/sys/kernel/real-root-dev. 
Т.е. нужен код в initrd чтобы обработать root= (по сути, сэмулировать его) и 
активировать lvm. Для evms код действительно, как я убедился, есть, но для 
стандартного lvm'а-то нету.

Re: lvm




и активировать lvm. Для evms код действительно, как я убедился, есть, но
для стандартного lvm'а-то нету.



Смотрим и удивляемся.
[EMAIL PROTECTED]:~% uname -a
Linux forward 2.4.27-1-686-smp #1 SMP Fri Sep 3 06:34:36 UTC 2004 i686 
GNU/Linux

[EMAIL PROTECTED]:~% sudo mkinitrd -o initrd -r /dev/forward_vg/home_lv
[EMAIL PROTECTED]:~% sudo mount -o loop initrd mnt
[EMAIL PROTECTED]:~% cat mnt/script
ROOT=/dev/forward_vg/home_lv
[ -c /dev/lvm ] || mknod /dev/lvm c 109 0
mount_tmpfs /etc
vgscan
vgchange -a y
umount -n /etc
[EMAIL PROTECTED]:~%


А каково происхождение этого скрипта? Откуда он взялся?

Re: lvm

А это уже в качестве самостоятельной работы. Продолжительность работы - 1.5 
минуты. ;-))


HINT: vi /usr/sbin/mkinitrd


Вот я об этом и говорю - всё равно руки нужно приложить.
А про плагиновость mkinitrd я не знал.

Re: lvm



Блин! Некуда их прикладывать! HINT был написан для того, чтобы посмотреть на 
этот файл, и понять, что там все уже сделано!


Действительно сделано, но как: чтобы загрузиться с lvm-root нужно сделать 
initrd, загрузившись с lvm-root. Что-то это мне напоминает. ;-)
Я сразу предпочёл сделать единый initrd для всех серверов, в независимости от 
того есть ли на них lvm/md (aka soft raid) или их комбинация и на каком железе 
они работают.

Re: lvm


Alexander N. Kogan wrote:

Неправильно. Этим управляет параметр ROOT=... в /etc/mkinitrd/mkinitrd.conf 
или ключик -r ... для mkinitrd. Если Вы заметили, в моем примере я 
указывал /dev/forward_vg/home_lv, что есть отнюдь не /, а /home. Ему для 
дого, чтобы понять какие операции производить в initrd, нужно только _имя_ 
устройства, по которому он и определяет, что запихивать в initrd.


Да, на примерах более доступно получается: на сервере / находится на 
/dev/vg00/root, а на моём десктопе, на котором я делаю initrd, никаким vg00 не 
пахнет, поэтому когда я запускаю mkinitrd -r /dev/vg00/root -o initrd.img, то 
получаю device /dev/vg00/root is not a block device. Выходит, что я initrd 
выдужден делать на _целевой_ машине, на той самой для которой я его делаю. В 
этом я и вижу порочный замкнутый круг.

Re: lvm

Э. А dpkg -i kernel-image-2.4.xxx-server_xxx_i386.deb Вы тоже на 
десктопе делаете?


Практически имеенно так. Мне нравится debian'овский ядерный патч, но это лишь 
часть того, что мне требуется от ядра - оно у меня всё равно самосборное, так 
что общепринятая технолигия мне не очень годится. Тем не менее, я должен 
признать, что для большинства она действительно вполне подходящая и моё 
изначальное утверждение об отсутсвии поддержки lvm основывалось на неполных 
знаниях о makeinitrd, однако, я остаюсь при своём мнении.

Спасибо за позновательную беседу.

Re: lvm