path: root/src/mailman/messages/hu/UPGRADING.hu

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: