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..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/ könyvtárába létrehoz egy `en' nevű könyvtárat a program. A frissítés során a lists/ könyvtárakban található .txt és .html állományokat bemásolja a program a lists//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// 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/ átkerül a $prefix/archives/private/.mbox/ helyre, 2) ha a listának csak nyilvános mbox arcívuma van, akkor a $prefix/archives/public/ átkerül a $prefix/archives/private/.mbox/ helyre és egy szimbolikus hivatkozást kell létrehozni, a $prefix/archives/public/.mbox hivatkozásnak a $prefix/archives/private/.mbox/ 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/ helyre mozgatja át és létrehozza a $prefix/archives/public/ 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 . 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//*) minden egyes listánál áthelyezi a $prefix/lists/ 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 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/ - 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: