Mailman - The GNU Mailing List Management System
Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
MEGJEGYZÉS A MODERÁLÁSHOZ
2.0.x verzióról 2.1 verzióra történő frissítéskor ellenőrizzük,
hogy a moderálási és a privát beállítások nem térnek-e el a
korábban beállított értékektől. A moderálási és privát beállítások,
a könnyebb érthetőség és kezelhetőség érdekében, jelentősen
megváltoztak a Mailman újabb verziójában. Hiába azonban az
igyekezet, hogy minél tökéletesebben, problémamentesen kerüljenek
át a régi, összetett beállítások az új rendszerbe, mégis elő-
fordulhat, hogy a beállítások átvétele hibás lesz.
Különösen a (Privát beállítások -> Feladók szűrése)
default_member_moderation, generic_nonmember_action, és
accept_these_nonmembers beállításokat ellenőrizzük le. Ezenfelül
célszerű ellenőriznünk a Listatagok kezelése menüben a fel-
használók egyenkénti moderálási állapotát is.
FRISSÍTÉS KORÁBBI VERZIÓKRÓL
A Mailman frissítése többnyire nem jelent mást, mint egy újabb
verzió telepítését a létező telepített verzióra. Azonban néhány
esetben saját magunknak kell bizonyos változtatásokat elvégeznünk.
Azt hogy egész pontosan mit kell csinálnunk az függ attól, hogy
melyik verzióról melyik verzióra állunk át. Mindegyik esetben
először kapcsoljuk ki az e-mail és web hozzáférést a telepített
Mailmanhez, mivel lényegében egy adatbázis frissítünk és nem
lenne szerencsés ha frissítés közepén az adatbázisunk megváltozik.
A következőket javasoljuk :
- Kapcsoljuk le a bejövő levelekért felelős mail deamont. A legtöbb
smtp kiszolgáló megpróbálja később továbbítani nekünk a leveleket,
ha lezártuk a 25-ös portot.
- Átmenetileg kapcsoljuk ki a web hozzáférést is a telepített
Mailmanhez. Ezt elérhetjük úgy, hogy vagy ideiglenesen leállítjuk
a web kiszolgálót, vagy létrehozunk egy "átmenetileg szünetel"
oldalt a Mailman URL-ökhöz. Bővebb információkért olvassuk el
a web kiszolgálónk dokumentációját.
Működő listák sablonállományait nem frissíti a Mailman. Hogy ilyen
esetben mit kell csinálni, azt Chuq Von Rospach leírásából lehet
megtudni a következő címen:
http://mail.python.org/pipermail/mailman-users/2000-September/006826.html
[Valójában MM2.1a2 verzióra történő váltáskor a program lecseréli
a sablonállományokat, azokat pedig törli amelyek megegyeznek az
eredeti változattal (az összehasonlítást az md5 ellenőrzőösszegek
alapján végzi).]
FRISSÍTÉS 2.0.x VERZIÓRÓL 2.1 VERZIÓRA
A Mailman 2.1-es verziójában drasztikus változtatáson esett át a
qrunner rendszer. A qrunnert többé nem cron-ból kell indítani!
Helyette a bin/mailmanctl program indításával vagy leállításával
lehet kezelni a levelek feldolgozását. A program egyben egy
Unix indító szkript is. Fontos, hogy el ne felejtsük frissíteni
a crontab bejegyzést az új cron/crontab.in állománnyal.
MEGJEGYZÉS: Nagyon fontos, hogy *MIELŐTT* frissítenénk MM2.1alpha2
előtti verzióról MM2.1alpha2-nél újabb verzióra, akkor hagyjuk
hogy a régi qrunner folyamat a qfiles/ könyvtárban található
összes kézbesítésre váró üzenetet feldolgozza, mert a frissítés
után már nem fogja feldolgozni ezeket az üzeneteket az új qrunner.
MEGJEGYZÉS: Mailman 2.1beta1-nél újabb verzióra való átálláskor
újra létre kell hoznunk az aliases állományokat, mivel az újabb
verziókban a wrapper program neve megváltozott mailman-re. A
README.<MTAnk>.hu állományokban részletes leírás található a
Mailman és az adott levelezőszerver összekapcsolásáról.
Az aliases állományt a bin/genaliases programmal könnyen újra
létre lehet hozni.
A 2.1-es Mailman már többféle nyelven is használható, támogatja
az eltérő karakterkészleteket. Régebbi verziókban listánként
mindössze egy nyelv volt használható és az is az angol volt. A
frissítés során minden egyes lista lists/<listanév> könyvtárába
létrehoz egy `en' nevű könyvtárat a program. A frissítés során a
lists/<listanév> könyvtárakban található .txt és .html állományokat
bemásolja a program a lists/<listanév>/en könyvtárba.
Ha módosítottuk a sablonokat, hogy ne (csak) angol szöveget
tartalmazzanak, akkor saját magunknak kell átnevezni az `en'
könyvtárat a használt nyelv kódjának megfelelő nevű könyvtárrá.
A Mailman frissítéseket végző programja automatikusan törli azokat
a sablonokat, amelyek több, azonos példányban is megtalálhatóak,
de nem árt személyesen is átfutnunk a sablonállományok listáját
ellenőrzésképpen.
Ha 2.0.x-es rendszert használunk nem a szokványos javításokkal,
akkor a frissítés során problémákba ütközhetünk. Ilyenek lehetnek:
- Ha a #413752 (mindig sima szövegformátum) javítást telepítettük,
akkor a frissítés nem fog gond nélkül zajlani. A #651406 frissítés
segíthet a probléma megoldásában.
http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=413752
http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=651406
LISTÁK EGYENKÉNTI FRISSÍTÉSE
Ha félünk a 2.1-es verzióra történő teljes átállásból eredő problé-
máktól, akkor megtehetjük hogy a listáinkat egyenkét frissítjük az
újabb verzióra. Ehhez mindössze egy üres könyvtárba kell telepítenünk
a Mailman 2.1-es verzióját, erre a könyvtárra $MM21 -ként fogunk a
későbbiekben hivatkozni. (A 2.0-ás verzió könyvtárára pedig a
továbbiakban $MM20 -ként hivatkozunk.)
Ilyen esetben a Mailman 2.0 és 2.1-es verziója egyszerre fog
működni a rendszerünkön addig, amíg teljes egészében át nem állunk
a 2.1-es verzióra. Az általunk használt MTA és web kiszolgálóktól
függően ez a módszer gond nélkül, simán is működhet, azonban elő-
fordulhatnak komoly problémák is.
Ha az Apache kiszolgálónál a mod_rewrite funkciót tudjuk használni,
akkor beállíthatjuk, hogy mind a 2.0-ás és 2.1-es Mailman ugyanazt
a /mailman és /pipermail címet használhassa; ezzel elérhetjük hogy
a lista adminisztrátorok, a felhasználók zavartalanul tudják
használni a rendszert.
Minden egyes listánál, amelyet a másik verzióba akarunk átvinni
a következőket tegyük.
* Állítsuk le az MTA-t.
Ha a kimenő forgalmunk számottevő, akkor megtehetjük, hogy
úgy állítjuk be az MTA-t, hogy csak a 127.0.0.1 (localhost)
címről érkező kapcsolatokat fogadja, így a 2.0-ás Mailman a
várakozó leveleket kézbesíteni tudja. Hogy ezt a beállítást,
hogyan tudjuk megtenni az függ a használt MTA-tól; Exim esetén
a "local_interfaces = 127.0.0.1" sort kell megadnunk, majd
"kill -HUP" paranccsal újraindítanunk az Exim démont.
* Állítsuk le a webkiszolgálót. Jobb megoldás, ha csak a /mailman/
oldalakhoz érkező kéréseket irányítjuk át egy "átmenetileg
nem elérhető" oldalra, ettől még más oldalakat el fognak
tudni érni a felhasználók.
A megoldás itt is programfüggő; Apache esetén a mod_rewrite
segítségével az alábbi módon oldható meg:
RewriteRule ^/mailman/.* /var/www/unavailable.html [L]
(Természetesen előbb létre kell hoznunk a
/var/www/unavailable.html oldalt.)
* Kényszerítsük a 2.0-ás Mailmant, hogy dolgozza fel a várakozó
leveleket a következő paranccsal:
python -S $MM20/cron/qrunner
(Ezt csak akkor kell megtennünk, ha a $MM20/qfiles könyvtár
nem üres, azonban győződjünk meg ekkor, hogy az MTA képes
fogadni kapcsolatot a 127.0.0.1 címről.)
* Mozgassuk át a listát:
cd $MM20
mv -i lists/foo-list $MM21/lists
mv -i archives/private/foo-list $MM21/archives/private
mv -i archives/private/foo-list.mbox $MM21/archives/private
rm archives/public/foo-list
rm archives/public/foo-list.mbox
cd $MM21
bin/withlist -l -r fix_url mylist
(Az utolsó lépés, a fix_url használata csak akkor szükséges,
ha a 2.0-ás és 2.1-es verziók eltérő URL-t használnak.)
* Módosítsuk a web kiszolgáló beállítását, hogy a listák
oldalai elérhetőek legyenek. Két megoldás lehet; az egyszerűbb
az, hogy egy új címen keresztül érjük el a 2.1-es verziót,
pl. /mailman-21. Ehhez az Apache mod_rewrite modulját kell
használnunk:
RewriteRule /mailman/(.*)/(foo-list.*) /mailman-21/$1/$2 [R=temp]
(A [R=temp] rész azt jelenti, hogy a "/mailman-21/" cím csak
átmeneti és ha már minden listát átmozgattunk a 2.1-es
verzióba, akkor megszűnik és az összes listát a "/mailman/"
címen lehet majd elérni.)
A másik megoldásnál nem szeretnénk egy új címet használni,
hanem mind a 2.0-ás, mind a 2.1-es verzió listáit ugyanazon a
címen keresztül szeretnénk elérni. A megoldás ekkor az
Apache mod_rewrite moduljával a következő lehet:
RewriteRule ^/mailman/(.*)/(foo-list.*) \
$MM21/cgi-bin/$1/$2 \
[T=application/x-httpd-cgi]
Ezen megoldás másik előnye, hogy gyorsabb is, mivel nem történik
átirányítás.
Bármelyik megoldást is alkalmazzuk el ne felejtkezzünk a lista
archívumának az átirányításáról sem:
RewriteRule ^/pipermail/(foo-list.*) $MM21/archives/public/$1
* Indítsuk újra a web kiszolgálót (vagy kapcsoljuk ki az átirányítást,
amely az "átmenetileg szünetel" oldalt hozza be).
* Indítsuk újra az MTA-t (vagy állítsuk be, hogy mostantól már ne
csak a 127.0.0.1 címről fogadjon kapcsolatot).
FRISSÍTÉS 2.0 VERZIÓRÓL 2.0.x VERZIÓRA (AHOL x >= 1)
Nem kell sok mindent tenni, a "make install" -lal a frissítés
is megtörténik.
FRISSÍTÉS 2.0 béta VERZIÓRÓL 2.0 végleges VERZIÓRA
ÚJRA le kell futtatnunk a configure programot; a config.status
újrafuttatása sajnos az autoconf programban történt változások
miatt nem elegendő. A config.status első sorai között meg
találhatjuk, hogy régebben milyen beállításokkal futtattuk le a
configure-t.
A végleges 2.0-ás verzióban a cron feladatok és azok gyakorisága
megváltozott. A `mailman' felhasználónak újra be kell tölteni
a misc/crontab.in fájlból a helyes beállításokat. Bővebben
erről az INSTALL dokumentációban lehet olvasni.
HA KIHAGYJUK EZT A LÉPÉST, AKKOR A MAILMAN NEM FOG MEGFELELŐ
HATÉKONYSÁGGAL MŰKÖDNI.
FRISSÍTÉS 1.x VERZIÓRÓL 2.x VERZIÓRA
Erősen javasolt, hogy győződjünk meg a frissítés előtt, hogy
a Mailman feldolgozási sora üres.
A 1.x verzióban a levelek kézbesítését a run_queue program
végezte. A 2.x verziókban ez a program megszűnt (funkcióját
az MTA vette át), és jelenleg nem ismert, hogy milyen hatást
idéz elő a frissítés ezen a programrészen, de valószínű
hibás működéshez vezetne.
Ha a $prefix/data könyvtár üres, akkor a Mailman feldolgozási
sora biztosan üres. Ha a könyvtár "mm_q." kezdetű fájlokat
tartalmaz, akkor még mindig van kézbesítésre váró levél a
feldolgozási sorban. A $prefix/cron/run_queue program indítá-
sával kényszeríteni lehet ezen levelek kézbesítését. A program
többszöri indítása nem sietteti a feldolgozás idejét, mivel
a program párhuzamos feldolgozások elől zárolja a leveleket.
Fontos megjegyeznünk, hogy a feldolgozási sor kiürítése időbe
kerül és a rendszert erősen terhelheti (ezért is lett átírva a
kézbesítés a 2.x verzióban).
Nem kell használni a "make update" parancsot, ha 1.0 vagy 1.1-ről
2.0-ára frissítünk, mert ezt a parancsot a "make install" automa-
tikusan lefuttatja. Viszont frissítenünk kell a crontab bejegyzéseket,
hogy ezentúl ne a cron/run_queue, hanem a cron/qrunner program
legyen időszakosan elindítva. Ezek után nyugodtan lehet törölni
a $prefix/cron/run_queue fájlt.
Ha egy 1.0 béta előtti verzióról szeretnénk frissíteni, akkor
azt a lejjebb található módon végezzük.
FRISSÍTÉS PRE-1.0 VERZIÓRÓL 2.x VERZIÓRA
Az 1.0 béta előtti verziókról történő frissítéskor legelőször
a Mailman könyvtár rendszerét kell frissíteni, ezt két módon
tehetjük meg.
Első módszernél a forrás könyvtárában miután kiadtuk a "make
install" parancsot, adjuk ki a "make update" parancsot. Ekkor
létrejön egy "update.log" nevű állomány a forrás gyökér-
könyvtárába. Ha a program a Mailman fájlrendszer frissítésekor
olyan problémába ütközik, amelyet nem tud megoldani, akkor ebbe
az "update.log" állományba fogja menteni a hibaüzenetet. Célszerű
ezért ezt a fájlt frissítés után átnéznünk.
A frissítést végrehajthatjuk úgy is, hogy belépünk a telepített
Mailman könyvtárába (pl. $prefix) és futtatjuk a bun/update
programot. Ez a program ugyanazt hajtja végre, mint az előbbi,
de nem hozza létre az update.log fájlt.
Ellenőrizzük a crontab beállításokat. Töröljük a szükségtelen,
elavult programok indítására vonatkozó bejegyezéseket, elsősorban
a cron/upvolumes_yearly, cron/upvolumes_monthly, vagy cron/archive
programokra utaló bejegyzéseket.
A "MAKE UPDATE" MŰKÖDÉSE
A továbbiakban a "make update" működéséről, magyarázatokkal el-
látva olvashatunk. Reméljük, hogy ez segít az esetleges problémák
elhárításában.
Jó tudni, hogy nem jelenthet problémát, ha minden egyes frissítéskor
kiadjuk a "make update" parancsot, azonban az 1.0-nál újabb verziók
esetén nem fog változást hozni!
- 1.0b10 verzióra történő frissítéskor a templates/options.html
fájlt át kell másolni minden egyes listánál a lists/<listanév>/
könyvtárba. Ha módosítottuk az options.html fájlt - mondjuk a
webfelületen keresztül -, akkor a változtatásokat saját magunknak
kell végrehajtani az új fájlokon.
- 1.0b7 verzióra történő frissítéskor a Mailman/smtplib.py{,c}
állományokat törölni kell, a funkcióját a Python 1.5.2 verzióban
található smtplib veszi át.
- Az archívum helye az 1.0b6-os telepítésével megváltozik, mivel
ebben a verzióba a Pipermail már be lett építve. A teendők,
1) ha a listának csak privát mbox archívuma van, akkor a
$prefix/archives/private/<listanév> átkerül a
$prefix/archives/private/<listanév>.mbox/<listanév> helyre,
2) ha a listának csak nyilvános mbox arcívuma van, akkor a
$prefix/archives/public/<listanév> átkerül a
$prefix/archives/private/<listanév>.mbox/<listanév> helyre
és egy szimbolikus hivatkozást kell létrehozni, a
$prefix/archives/public/<listanév>.mbox hivatkozásnak a
$prefix/archives/private/<listanév>.mbox/<listanév> helyre kell mutatnia.
3) ha a listának mindkét típusú archívuma létezik már, akkor
a "make update" a kettő közül attól függően azt választja, hogy
a lista éppen nyilvános vagy privát archívummal rendelkezik.
Ezek után a mások mbox-ot átnevezi mbox.preb6 -á.
4) ha a lista olyan CVS verziót használ, ahol az archívum helye
a $prefix/public_html/archives volt, akkor a program ezeket
a $prefix/archives/private/<listanév> helyre mozgatja át és
létrehozza a $prefix/archives/public/<listanév> szimbolikus
hivatkozást, ha a lista archívuma nyilvános. Ezzel egy
jogosultsági probléma is megoldódik.
A régi listák archívumának létrehozásához lépjünk be `mailman'
felhasználóként és futassuk a következő parancsot:
$prefix/bin/arch <listanév> <mbox-archívum-elérési-útvonala>.
Továbbá a beta6 alapértelmezés szerint az archívumot mind
mbox, mind html formátumban létrehozza. Hogy csak egyik, vagy
mindkettő vagy semelyik módszer szerint se archiváljon az
a megfelelő helyen beállítható. Erről bővebben a
$prefix/Mailman/Defaults.py állományban lehet olvasni.
A fejlesztések során volt egy olyan rövid időszak, amikor az
archiválást végző kód nem csak a saját csomagján belül volt
elhelyezve. Ekkor az archívumba elhelyezendő levelekhez a
HyperArch modulra is szükség volt, amelynek azóta a helye
megváltozott. A problémát a következő paranccsal lehet
megoldani:
ln -s $prefix/Mailman/Archiver/HyperArch.py \
$prefix/Mailman/HyperArch.py
- Ha 1.0b4 -nél régebbi verzióról frissítünk, akkor a "make update"
a lista-specifikus sablonokat ($prefix/templates/<listanév>/*)
minden egyes listánál áthelyezi a $prefix/lists/<listanév> könyvtárba.
Ellenőrizzük, hogy a $prefix/templates könyvtárban maradó általános
sablon fájlok közül bármelyik is meg változott-e. (Elméletileg
csak az options.html változik meg a b5-ről b6 verzióra történő
átálláskor.)
Nagyon régi Mailman verzióknál még <listanév> alkönyvtár sem
található a $prefix/templates könyvtárban! Ez esetben saját
magunknak kell bizonyos fájlokat átmásolni az új könyvtárba.
A következő parancs átmásolja a szükséges fájlokat:
cp templates/{archives,handle_opts,listinfo,roster,subscribe}.html lists/<listanév>
- Törölni kell azokat a modulokat, amelyek a korábbi verziókban
megtalálhatóak voltak, de az újabbakban le lettek cserélve,
vagy új nevet kaptak.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: