[STBR/security] sendmail

Jarosław Kamper jack w jack.eu.org
Nie, 30 Mar 2003, 20:49:08 CEST


Dnia Sunday 30 of March 2003 20:01, Jakub Bogusz napisał:
> On Sun, Mar 30, 2003 at 01:17:34AM +0100, Jarosław Kamper wrote:
> > Dnia Saturday 29 of March 2003 22:43, Jakub Bogusz napisał:
> > > On Sat, Mar 29, 2003 at 09:24:06PM +0100, Jarosław Kamper wrote:
> > > > @@ -163,7 +163,7 @@
> > > >  %build
> > > >   echo "define(\`confCC', \`%{__cc}')" >> config.m4
> > > >   echo "define(\`confOPTIMIZE', \`%{rpmcflags}
> > > > -DUSE_VENDOR_CF_PATH=1 -DNETINET6')" >> config.m4 -echo
> > > > "define(\`confLIBSEARCH', \`db')" >> config.m4
> > > >   +echo "define(\`confLIBSEARCH', \`db resolv')" >> config.m4
> > > >
> > > > Co to niby robi? Na HEAD niby ma poprawiac budowalnosc z -without
> > > > ldap, ale juz buduje sie i bez tego ;/
> > >
> > > Przecież już jest to resolv w specu?
> > > Zobaczę, czy nadal go używa.
> >
> > W HEAD, nie w RA-branch (odwrotnego diffa wkleiłem)
>
> Już się pogubiłem co na co chcesz zmieniać...

echo "define(\`confLIBSEARCH', \`db')" >> config.m4

na

echo "define(\`confLIBSEARCH', \`db resolv')" >> config.m4

Czyli tak, jak jest na HEAD.

> W każdym razie to resolv tutaj jest potrzebne.
> Nawet jeśli z ldap się buduje bez (biblioteki ldap są zlinkowane
> z -lresolv), to nie można go pominąć, bo gdyby ldap kiedyś przestało
> być zlinkowane z -lresolv, to sendmail przestanie działać.

No właśnie chodziło mi o --without ldap - zawsze tak buduję sendmaila i 
kiedyś z tym bcondem przestał się budować, później djurban dodał to co 
wyżej (resolv), co niby miało sprawić, że znowu zacznie się budować. Ale 
W 8.12.9 przestało to rzutować (buduje się z i bez). Co nie zmienia 
faktu, że z tego co piszesz to powinno być również w RA-branch...
Dodać?

> > > > Swoją drogą, durnym pomysłem wydaje mi się zamieszczanie
> > > > sendmail.cf - ten powinien być generowany z sendmail.mc, np w
> > > > %post jakieś: mv /etc/mail/sendmail.cf
> > > > /etc/mail/sendmail.cf.rpmold
> > > > m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
> > >
> > > Nie. Nie wszystko da się osiągnąć w samym .mc - "ciekawe" jakby
> > > ktoś zareagował na podmienienie mu pliku .cf z ręcznie dopisanymi
> > > regułami...
> >
> > Podobno wszytko da się z tego wygenerować i podobno .cf nie powinno
> > się edytować ;)
>
> Nie, nie wszystko można uzyskać modyfikując .mc.
> Trzeba by jeszcze poprawiać szablony - znajdujące się
> w /usr/lib/sendmail-cf, a one są read-only.

A co potrzeba? Zawsze można dodać do sendmail.mc i zakomentować.

> No i łatwiej/szybciej zrobić małą poprawkę w sendmail.cf, niż
> dopisywać obsługę dodatkowych parametrów do szablonów.

A gdy wystarczy daną "obsługę" tylko odkomentować, lub zmienić jej 
wartość? ;)

> > [jack w pldmachine jack]$ head -25 /etc/mail/sendmail.cf|tail -1
> > #####   DO NOT EDIT THIS FILE!  Only edit the source .mc file.
> >
> > Pytania? ;>
>
> E tam, jakieś bzdury ;P
> Po co wsadzali komentarze do .cf ;>

hehe

> > > > lub
> > > > m4 /etc/mail/sendmail.mc.rpmnew > /etc/mail/sendmail.cf.rpmnew
> > >
> > > przecież tak już praktycznie jest? (z tą różnicą, że ten drugi plik
> > > też instaluje rpm)
> >
> > Nie jest. A wnioskuję z tego, że sendmail.mc mi się nowy nie pojawił,
> > a sendmail.cf.rpmnew tak. Czary? ;) Diff pomiędzy moim sendmail.cf i
> > sendmail.cf.rpmnew był nawet paroekranowy.
>
> Różni się co najmniej wersja sendmaila i wersje szablonów.
> Mogły być też poprawki w szablonach (np. była co najmniej jedna między
> 8.12.8 a 8.12.9).

Tak, ale ten sendmail.cf.rpmnew jest z kosmosu, a przynajmniej nie z mojej 
maszyny. A IMHO powinen.

> > Diff pomiędzy sendmail.cf
> > wygenerowanym z mojego sendmail.mc a sendmail.cf.rpmnew był
> > jednolinijkowy ;)
>
> Jak tylko generujesz, to sobie przegeneruj.

No oczywiście porównuję zmiany w .mc jak się jakieś nowe pliki .mc 
pojawiają...

> Ja robię vim -d /etc/mail/sendmail.cf{,.rpmnew} i dalej jak w przypadku
> innych plików konfiguracyjnych.

IMHO to bez sensu rzeźbienie, skoro robią to automaty ;)
-- 
Jarosław Kamper <jack w jack.eu.org> http://jack.eu.org/



Więcej informacji o liście dyskusyjnej pld-devel-pl