Dokumentáció/SL9.3/Telepítés/A rendszer frissítése és csomagkezelés
A SUSE LINUX frissítése
A szoftverek jellemzően minden egyes verziójukban egyre nagyobbra »nőnek«. Éppen ezért frissítés előtt érdemes szemügyre venni a rendelkezésre álló területet a df paranccsal. Ha úgy gyanítja, hogy kifut a merevlemez-területből, akkor mentse el az adatokat a rendszer frissítése és újraparticionálása előtt. Nincs általános ökölszabály arra nézve, hogy mekkorának kell lenniük az egyes partícióknak. A területkövetelmények függenek az egyedi particionálási profiltól, a kiválasztott szoftverektől és a SUSE LINUX verziójától.
Előkészületek
Frissítés előtt másolja át a régi konfigurációs fájlokat egy másik adathordozóra, például szalagra, cserélhető merevlemezre, ZIP-meghajtóra vagy USB-lemezre. Ez elsősorban az /etc könyvtár fájljaira vonatkozik, valamint a /var és /opt könyvtár egyes könyvtárjaira és fájljaira. Célszerű lementeni a /home könyvtárban található felhasználói adatokat (a HOME, azaz saját könyvtárakat) is. Ezeket az adatokat root felhasználóként mentse el. Csak a root jogosult az összes helyi fájl olvasására.
A frissítés megkezdése előtt jegyezze fel a gyökérpartíciót. A df / parancs kiírja a gyöképartíció eszköznevét. A Listázás a df -h paranccsal esetében a leírandó gyökérpartíció a /dev/hda2 (ez a fájlrendszer / része).
Példa: Listázás a df -h paranccsal
Filesystem Size Used Avail Use% Mounted on /dev/hda1 1.9G 189M 1.7G 10% /dos /dev/hda2 8.9G 7.1G 1.4G 84% / /dev/hda5 9.5G 8.3G 829M 92% /home
Lehetséges problémák
A passwd és group fájlok ellenőrzése az /etc könyvtárban
A rendszer frissítése előtt győződjön meg róla, hogy az /etc/passwd és az /etc/group fájlok nem tartalmaznak szintaktikai hibákat. E célból indítsa el a pwck és grpck ellenőrző segédprogramot root felhasználóként, és ha hibát észlel, javítsa azokat.PostgreSQL
A PostgreSQL (postgres) frissítése előtt mentse le az adatbázisokat. Tekintse meg a pg_dump kézikönyvoldalát (man). Erre csak akkor van szükség, ha a PostgreSQL-t ténylegesen használta is a frissítés előtt.
Frissítés a YaST segítségével
Az Előkészületek előkészületi eljárásait követve most már frissíthető a rendszer:- Indítsa el a rendszert ugyanúgy, mint az új telepítés esetében (A rendszer elindítása a telepítéshez). A YaST-ban válasszon ki egy nyelvet és válassza ki a Meglévő rendszer frissítése menüpontot. Ne válassza az Új telepítés menüpontot.
- A YaST megállapítja, hogy van-e egynél több gyökérpartíció. Ha csak egy van, folytatja a következő lépéssel. Ha több van, akkor válassza ki a megfelelőt és erősítse ezt meg a Tovább gombbal (Előkészületek ahol a példában a /dev/hda2 került kiválasztásra). A YaST beolvassa a partíció régi fstab fájlját és annak alapján elemzi, majd felcsatolja a felsorolt fájlrendszereket.
- Ezután lehetőség nyílik a rendszerfájlok elmentésére a frissítés közben. Ez a beállítás lelassítja a frissítési folyamatot. Csak akkor használja ezt a beállítást, ha nincs friss mentése a rendszerről.
- A következő párbeszédablakban vagy válassza azt a lehetőséget, hogy csak a már telepített szoftvereket frissíti, vagy azt, hogy új szoftverkomponenseket is fel akar venni a rendszerbe (frissítési mód). Célszerű elfogadni a felajánlott lehetőséget, például az Alapértelmezett rendszert. Módosításokra később bármikor van lehetőség a YaST-tal.
Egyedi csomagok frissítése
Függetlenül a teljes környezet frissítési állapotától, az egyes csomagok mindig frissíthetők. Igaz, innentől kezdve az Ön felelőssége, hogy a rendszer konzisztens marad-e. A frissítéssel kapcsolatos tanácsok: http://www.novell.com/linux/download/updates/.
Válassza ki a kívánt komponenseket a YaST csomagválasztó listájáról az igényeknek megfelelően. Ha egy olyan csomagot választ ki, amely a rendszer összműködését befolyásolja, a YaST figyelmeztet. Az ilyen csomagokat célszerű csak a frissítési módban frissíteni. Például igen sok csomag használ megosztott könyvtárakat. Ha frissíti ezeket a programokat és az alkalmazásokat a futó rendszerben, akkor problémák léphetnek fel.
Frissítés kézzel
Az alaprendszer frissítése
Mivel alapvető rendszer-komponenseket, mint például függvénytárakat, le kell cserélni az alaprendszer frissítése során, a frissítés nem futtatható az éppen futó Linux rendszeren. Először be kell állítani a frissítő-környezetet. Ezt meg lehet tenni CD-vel, DVD-vel, vagy egy szokásos indítólemezzel. Ha kézi módosításokat eszközöl a frissítés során, vagy a frissítést a YaST szöveges módjában végrehajtani, akkor kövesse az itt leírt lépéseket.
- Miután a kernel elindult az indítólemezről, elindul a linuxrc.
- A linuxrc-ben válassza ki a nyelvet és állítsa be a billentyűzetet a Settings menüben, majd kattintson az OK-ra, hogy megerősítse a változtatásokat.
- Szükséges lehet a hardver- és szoftver meghajtókat betölteni a Kernel Modules menüben.
- A forrásmédia kiválasztásához menjen a Start Installation or System menü Start Installation or Update pontjába.
- A telepítő-környezet betöltődik a linuxrc-ben, majd elinud a YaST.
A nyelvválasztás és a YaST általi hardver-detektálás után válassza az Update exisiting system menüpontot a YaST nyitóképernyőjén. Ezután a YaST megpróbálja megtalálni a gyökérpartíciót, és megjeleníti az eredményt kiválasztás vagy elfogadás céljából. Válassza ki a gyökérpartíciót a listából (pl. /dev/hda2). Ezen a módon a YaST azonnal beolvassa a régi fstab fájlt erről a partícióról. A YaST megvizsgálja és felcsatolja az itt talált fájl-rendszereket.
Ezután lehetsége van biztonsági másolatot készuíteni a rendszerfájlokról. A következő párbeszéd-ablakban leetősége van választani a már telepített szoftverek frissítése valamint a fontos új komponensek telepítése (upgrade mode) között. Tanácsos elfogadni az ajánlott beállítást. Módosításokat lehet végezni később a YaST segítségével.
A figyelmeztető ablakban válassza a "Yes"-t az új szoftver telepítéséhez. Először az RPM-adatbázis vizsgálata történik, aztán a fő rendszer-komponensek frissítődnek. A YaST automatikusan mentést készít az utolsó telepítés óta változott fájlokról. Ezen kívül a konfigurációs fájlokról is mentés készül .rpmorig és .rpmsave kiterjesztéssel. A telepítési vagy frissítési folyamatról napló készül /var/log/YaST2/y2log*-ban és később bármikor megtekinthető.
A rendszer többi részének frissítése
Az alaprendszer frissítése után a YaST átkapcsol frissítő módba. Ez a mód lehetővé teszi, hogy igényeihez szabja a rendszer többi részének frissítését. Végezze el az eljárást egy új telepítéshez hasonlóan. Egyéb dolgok mellett választhat új kernelt. A YaST bemutatja a lehetséges opciókat.
Lehetséges problémák
Ha a frissítés után bizonyos környezeti változók nem úgy viselkednek, ahogy elvárható, ellenőrízze a saját könyvtárában a ponttal kezdődő fájlokat, hogy kompatibilisek-e a rendszerrel. Ha nem, használja az /etc/skel-ben lévő aktuális változatokat. Pl. cp /etc/skel/.profile ~/.profile.
A szoftver változásai az egyes verziók között
Az egyes verziók közötti lényeges különbségeket az alábbiakban soroljuk fel. Az összefoglaló jelzi például, ha az alapbeállítások teljesen át lettek konfigurálva, ha a konfigurációs fájlok át lettek helyezve máshová, vagy ha a szokásos alkalmazások lényegesen megváltoztak. Itt említjük meg azokat a lényeges módosításokat, amelyek befolyásolják a rendszer mindennapos használatát, akár felhasználói, akár rendszergazdai szinten.
Az egyes verziók problémái és speciális kérdései online jelennek meg, ahogy azonosítjuk őket. Tekintse meg az alábbi hivatkozásokat. Az egyes csomagok fontos frissítései a http://www.novell.com/products/linuxprofessional/downloads/ címen érhetők el, a YaST online frissítés (YOU) segítségével — lásd: YaST online frissítés.
8.1-ről 8.2-re
Problémák és speciális kérdések: http://portal.suse.com/sdb/en/2003/04/bugs82.html
- 3D-támogatás nVidia alapú videokártyákhoz (változások): Az NVIDIA_GLX/NVIDIA_kernel RPM (beleértve a switch2nvidia_glx fájlt is) ki lett hagyva. Töltse le az nVidia Linux IA32-telepítőjét az nVidia webhelyéről (http://www.nvidia.com), telepítse ezzel a telepítővel az illesztőprogramját, majd használja az SaX2 programot vagy a YaST-ot a 3D-támogatás bekapcsolásához.
- Egy új telepítés során az inetd helyett a xinetd kerül telepítésre, és biztonságos értékekkel beállításra. Tekintse meg az /etc/xinetd.d könyvtárat. Rendszerfrissítés során azonban megmarad az inetd.
- A PostgreSQL verziója most 7.3. A 7.2.x verzióról frissítés esetén hajtson végre egy dump/restore (kiírás/visszaállítás) műveletet a pg_dump paranccsal. Ha az alkalmazás lekérdezi a rendszerkatalógusokat, akkor további igazításokra lehet szükség, mivel a sémák a 7.3-as változatban kerültek bevezetésre. További információ: http://www.ca.postgresql.org/docs/momjian/upgrade_tips_7.3.
- Az stunnel 4. verziója már nem támogatja a parancssori paraméterek használatát. A mellékelt /usr/sbin/stunnel3_wrapper parancsfájl azonban képes a parancssori paraméterek egy stunnel konfigurációs fájllá átalakítására amely használható a program indításakor (cserélje ki az alábbi sorban a PARAMÉTEREK szót a saját paraméterekre):
/usr/sbin/stunnel3_wrapper stunnel PARAMÉTEREK
- Az így előállított konfigurációs fájl kiíródik az alapértelmezett kimenetre, amelyből készíthető egy állandó konfigurációs fájl.
- Az openjade (openjade) a jelenleg használt DSSSL-alrendszer a jade (jade_dsl) helyett, ha a db2x.sh (docbook-toys) fut. Kompatibilitási okokból az egyes programok elérhetők az o előtag nélkül is.
- Ha a saját alkalmazások a jade_dsl-től és a korábban ott telepített fájloktól függenek, akkor igazítsa őket az új /usr/share/sgml/openjade könyvtárhoz, vagy hozzon létre egy láncot root felhasználóként:
cd /usr/share/sgml
- Az rzsz-vel való ütközés elkerülése érdekében az sx parancssori eszköz neve továbbra is s2x, sgml2xml vagy osx.
8.2-ről 9.0-ra
Problémák és speciális kérdések: http://portal.suse.com/sdb/en/2003/07/bugs90.html
- Most már használható az RPM csomagkezelő 4-es változata. A csomagok készítése most már a különálló rpmbuild program feladata. A telepítésre, frissítésre, illetve az adatbázisok lekérdezésére továbbra is az rpm szolgál. Lásd: RPM — a csomagkezelő.
- Most már használható nyomtatáshoz a foomatic-filters csomag. Ennek a tartalma le lett választva a cups-drivers csomagból, mivel akkor is használhatók nyomtatásra, ha a CUPS nincs telepítve. Ilyen módon tehát a YaST támogat a nyomtatási rendszertől (CUPS, LPRng) független konfigurációkat is. A csomag konfigurációs fájlja a /etc/foomatic/filter.conf.
- A foomatic-filters és cups-drivers csomagok egyaránt szükségesek az LPRng és az lpdfilter használatához.
- A mellékelt szoftvercsomagok XML-erőforrásai elérhetők az /etc/xml/suse-catalog.xml bejegyzésein keresztül. Ezt a fájlt nem szabad szerkeszteni az xmlcatalog-gal, mivel ennek hatására törlődhetnek a helyes frissítéshez szükséges strukturális megjegyezések. Az /etc/xml/suse-catalog.xml fájl elérése az /etc/xml/catalognextCatalog utasításával történik, így az xmllint-hez vagy az xsltproc-hoz hasonló XML-eszközök automatikusan meg tudják találni a helyi erőforrásokat.
9.0-ról 9.1-re SLES8-ról SLES9-re
Forduljon a http://portal.suse.com címen található SUSE támogatási adatbázis »A SUSE LINUX 9.1 ismert problémái és speciális funkciói« cikkéhez (a speciális funkciók kulcsszó alatt). Ezek a cikkek minden egyes SUSE LINUX verzióhoz elkészülnek.
Frissítés 2.6-os kernelre
A SUSE LINUX most már teljes egészében a 2.6-os kernelre épül. Az előző, 2.4-es kernel nem használható már, mert a disztribúcióban található alkalmazások nem működnek együtt vele.Ügyeljen az alábbi részletekre:*A modulok betöltését az /etc/modprobe.conf fájl szabályozza. Az /etc/modules.conf fájl használata elavult. A YaST megpróbálja átkonvertálni a fájlt (lásd még az /sbin/generate-modprobe.conf parancsfájlnál).
- A modulok neve .ko utótaggal végződik.
- Az ide-scsi modulra már nincs szükség CD-k írásához.
- Az snd_ előtag törlésre került az ALSA hangmodul opciói közül.
- A sysfs most már a /proc fájlrendszert egészíti ki.
- Sokat javult az energiagazdálkodás (különösen az ACPI) és most már egy YaST-modul segítségével is beállítható.
VFAT-partíciók felcsatolása
VFAT-partíciók felcsatolásakor a code paramétert át kell írni codepage-re. Ha nem sikerül a VFAT-partíció felcsatolása, akkor ellenőrizze, hogy az /etc/fstab fájl nem a régi paraméter értékét tartalmazza-e.
Készenlét és felfüggesztés ACPI használata esetén
A 2.6-os kernel támogatja az ACPI készenléti és felfüggesztési műveleteit. Ez a funkció még kísérleti stádiumban van és lehet, hogy egyes hardverelemek nem támogatják. A funkció használatához a powersave csomagra van szükség. A csomagról információ az /usr/share/doc/packages/powersave helyen található. Grafikus előtétprogram is létezik hozzá a kpowersave csomagban.
Beviteli eszközök
A beviteli eszközökkel kapcsolatos változásokat illetően forduljon a http://portal.suse.com címen található SUSE támogatási adatbázis »A SUSE LINUX 9.1 ismert problémái és speciális funkciói« cikkéhez (a speciális funkciók kulcsszó alatt).
Natív POSIX-szálkönvytár és a glibc 2.3.x
Az NGPT (Next Generation POSIX Threading) előírásainak megfelelően összeszerkesztett alkalmazások nem működnek együtt a glibc 2.3.x verziójával. Az olyan érintett alkalmazást, amely nem a SUSE LINUX csomag része, újra kell fordítani a linuxthreads vagy az NPTL (Native POSIX Thread Library) használatával. A preferált megoldás az NPTL, lévén ez a jövőre tervezett szabvány.Ha az NPTL használata problémákat okoz, akkor a régebbi linuxthreads-megvalósítás is használható, az alábbi környezeti változó beállítása mellett (a kernelverzió helyére a megfelelő kernel verziószámát írja):
LD_ASSUME_KERNEL=kernelverzió
Az alábbi verziószámok használhatók:
- 2.2.5 (i386, i586)
-
- linuxthreads lebegőpontos vermek nélkül
- 2.4.1 (AMD64, IPF, s390x, i586, i686)
- linuxthreads lebegőpontos vermekkel. Megjegyzések a kernellel, illetve a lebegőpontos vermeket használó linuxthreadsszel kapcsolatban: Az errno, h_errno és _res must funkciókat használó alkalmazásnak be kell ágyaznia a fejlécfájlokat (errno.h, netdb.h és resolv.h) egy #include paranccsal. Az olyan többszálú támogatással rendelkező C++ programokhoz, amelyek használják a száltörlést (thread cancellation), az LD_ASSUME_KERNEL=2.4.1 változót kell alkalmazni ahhoz, hogy használni tudják a linuxthreads könyvtárat.
A Native POSIX Thread Library (natív POSIX szálkönyvtár) adaptációi
Az NPTL része a SUSE LINUX 9.1-nek, mint szálkezelő csomag. Az NPTL binárisan kompatibilis a régebbi linuxthreads könyvtárral. Azon területeken azonban, ahol a linuxthreads megsérti a POSIX szabványt, alkalmazkodni kell az NPTL-hez. Ide tartozik: a szignálok kezelése, a getpid, amelyik ugyanazt az értéket adja vissza mindegyik szálban, valamint az, hogy a pthread_atforkkal bejegyzett szálazonosítók nem működnek a vfork használata esetén.
Hálózati csatolók beállítása
Megváltozott a hálózati csatolók beállítása. Korábban a hardver inicializálásra került egy nem létező eszköz beállítása után. Most a rendszer megkeresi az új hardvert és azonnal inicializálja, így az új hálózati csatoló máris beállítható.
Új nevek jelentek meg a konfigurációs fájlokban. Mivel a hálózati csatolók neve dinamikusan kerül előállításra, és egyre szélesebb körben terjednek az üzem közben cserélhető (hotplug-) eszközök, az eth0, eth1 és társai egyre kevésbé alkalmasak a beállításokhoz. Éppen ezért az egyedi azonosítók, például a MAC-cím és a PCI-kártyahely szolgál a csatolók elnevezésére. A csatolónevek azonnal használhatók, ahogy megjelennek. Az ifup eth0 vagy ifdown eth0 parancsok azért még használhatók.
Az eszközkonfigurációk az /etc/sysconfig/hardware könyvtárban találhatók. Az eszközök által biztosított csatolók általában az /etc/sysconfig/network alatt találhatók (különböző nevekkel). A részletes leírás a /usr/share/doc/packages/sysconfig/README fájlban található.
A hangrendszer beállítása
Frissítés után a hangkártyákat is újra kell konfigurálni. Ez elvégezhető a YaST sound moduljával. A root felhasználó nevében írja be, hogy yast2 sound.
A .local felső szintű tartomány, mint link-local tartomány
A névfeloldó könyvtár a .local felső szintű tartományt »link-local« típusú tartománynak tekinti és a multicast DNS-lekérdezéseket a 224.0.0.251 multicast-címre, az 5353-as portra küldi a normál DNS-lekérdezések helyett. Ez egy inkompatibilitást eredményező módosítás. Ha a .local tartomány már szerepel a névkiszolgáló konfigurációjában, akkor használjon egy másik tartománynevet. További információ a multicast DNS-ről: http://www.multicastdns.org.Az egész rendszerre kiterjedő UTF-8 kódolás
A rendszer alapértelmezett kódolása az UTF-8. Vagyis egy normál telepítés során telepítésre kerül egy területi beállítás UTF-8 kódolással, mint például az en_US.UTF-8. További információ a ihttp://www.suse.de/~mfabian/suse-cjk/locales.html weboldalon olvasható.Fájlnevek UTF-8 kódolásúra alakítása
A korábbi fájlrendszerek nem használtak UTF-8 kódolású fájlneveket (legfeljebb speciális esetekben). Ha ezek a fáljnevek nem-ASCII karaktereket tartalmaznak, összekavarodnak. Ennek kijavítására használja a convmv parancsfájlt, amely átalakítja a fájlnevek kódolását UTF-8-ra.
A 2001-es POSIX szabvánnyal kompatibilis parancsértelmező eszközök
Az alapértelmezett beállítások mellett a coreutils csomag (tail, chown, head, sort stb.) már nem az 1992-es, hanem a 2001-es POSIX szabványnak felelnek meg (Single UNIX Specification, version 3 == IEEE Std 1003.1-2001 == ISO/IEC 9945:2002). A régi viselkedés is kikényszeríthető egy környezeti változóval:_POSIX2_VERSION=199209
A _POSIX2_VERSION változó új alapértéke most már a 200112. A SUS szabvány megtekinthető (ingyenesen, de a regisztráció kötelező) a http://www.unix.org címen.
| POSIX 1992 | POSIX 2001 |
|---|---|
| chown tux.users | chown tux:users |
| tail +3 | tail -n 3 |
| head -1 | head -n 1 |
| sort +3 | sort -k 4 |
| nice -10 | nice -n 10 |
| split -10 | split -l 10 |
/etc/gshadow elavult
Az /etc/gshadow kikerült a disztribúcióból, mivel erre a fájlra több okból sincs már szükség:- Nem támogatja a glibc.
- Nincs hivatalos felület a fájlhoz. Még a shadow csomag sem tartalmaz ilyen felületet.
- A legtöbb eszköz, amely ellenőrzi a csoportos jelszót, nem támogatja a fájlt és figyelmen kívül hagyja a fenti okok miatt.
OpenLDAP
Mivel megváltozott az adatbázis formátuma, az adatbázisokat újra kell generálni. A frissítés során a rendszer megpróbálja ezt automatikusan elvégezni. Bizonyos esetekben azonban az általakítás sikertelen.
A sémaellenőrzés lényegesen javult. Éppen ezért egy sor, a szabványnak nem megfelelő, ám korábban elvégezhető művelet most már nem hajtható végre.
A konfigurációs fájl szintaxisa részben megváltozott, egy ACL-nézettel. A telepítés után a frissítésre vonatkozó információ az /usr/share/doc/packages/openldap2/README.update fájlban olvasható.
Apache 2 az Apache 1.3 helyett
Az 1.3 verziójú Apache webkiszolgálót felváltotta az Apache 2. A 2.0 változat részletes dokumentációja a http://httpd.apache.org/docs-2.0/en/ weboldalon olvasható. Telepített HTTP kiszolgálót tartalmazó rendszereken a frissítés eltávolítja az Apache csomagot és az Apache 2-t telepíti. Ennek megfelelően a rendszert a YaST segítségével vagy kézzel utána kell igazítani. Az /etc/httpd könyvtár konfigurációs fájljai most az /etc/apache2 könyvtárban találhatók meg.
Szálak és folyamatok is kiválaszthatók több egyidejű kérés kiszolgálására. A folyamatkezelés egy önálló modulba került, a többfeladatosságért felelős modulba (multiprocessing module, MPM). Ennek megfelelően az Apache 2 működéséhez vagy az apache2-prefork csomagra (a stabilitás érdekében ezt javasoljuk) vagy az apache2-worker csomagra szükség van. Az MPM-től függően az Apache 2 eltérő módon reagál a kérésekre. Ez befolyásolja a teljesítményt, valamint a modulok használatát is. E jellemzők részletes leírása: Szálak.
Az Apache 2 most már támogatja a következő generációs Internet Protocolt, az IPv6-ot.
Készült egy mechanizmus, amellyel a modulok programozói megadhatják a modulok kívánt betöltési sorrendjét, így nem kell a felhasználóknak törődniük ezzel. Gyakran fontos, hogy milyen sorrendben kerülnek betöltésre a modulok és korábban ezt a betöltési sorrend határozta meg. Egy olyan modult például, amelyik csak hitelesített felhasználóknak ad hozzáférést bizonyos erőforrásokhoz, előbb kell betölteni, hogy a megfelelő jogosultság nélküli felhasználók nehogy véletlenül láthassák ezeket az oldalakat.
Az Apache felé irányuló kérések és a rájuk adott válaszok szűrhetők.
Samba 2.x-ről Samba 3.x-re
A Samba 2.x-ről Samba 3.x-re frissítés után a winbind hitelesítés nem elérhető. A többi hitelesítési módszer továbbra is használható. Emiatt a következő programok eltávolításra kerültek:
/usr/sbin/wb_auth /usr/sbin/wb_ntlmauth /usr/sbin/wb_info_group.pl
Lásd még: http://www.squid-cache.org/Doc/FAQ/FAQ-23.html#ss23.5.
OpenSSH-frissítés (v3.8p1)
A gssapi támogatást felváltotta a gssapi-with-mic a potenciális MITM-támadások elkerülése érdekében. Ez a két verzió nem kompatibilis. Ez azt jelenti, hogy a régebbi disztribúciók Kerberos-jegyeivel nem lehetséges a hitelesítés, mivel azok még régebbi hitelesítési módszereket használnak.
SSH és terminálalkalmazások
Távoli gépről kezdeményezett (különösen SSH, telnet és RSH) kapcsolat esetén a (SLES, SLES 8 vagy SUSE LINUX 9.0 és korábbi verziók között, amelyekben az UTF-8 kódolás még nincs telepítve és aktiválva alapértelmezés szerint, vagy nem támogatott), lehetséges, hogy a terminálalkalmazások helytelen karaktereket jelenítenek meg.
Ez azért van, mert az OpenSSH nem továbbítja a helyi beállításokat. Éppen ezért az alapértelmezett rendszerbeállítások lehet, hogy nem egyeznek meg a távoli termináléval. Ez befolyásolja a szöveges módban használt YaST-ot is, illetve a távoli gépről normál (nem root) felhasználóként végrehajtott alkalmazásokat is. A root által elindított alkalmazások csak akkor érintettek, ha a felhasználó megváltoztatta a root normál területi beállításait (alapértelmezésben csak az LC_CTYPE kerül beállításra).
libiodbc kimaradt
A FreeRADIUS-felhasználóknak most már a unixODBC-hez kell csatlakozniuk, mert a libiodbc többé nem része a csomagnak.
Az FHS (lásd Szabványok és specifikációk) most azt igényli, hogy az XML-erőforrások (DTD-k, stíluslapok stb.) az /usr/share/xml könyvtárba legyenek telepítve. Éppen ezért néhány könyvtár már nem található meg az /usr/share/sgml helyen. Ha problémákba ütközik, módosítsa a parancsfájlokat és make-fájlokat, vagy használja a hivatalos katalógusokat (különösen az/etc/xml/catalog vagy /etc/sgml/catalog fájlokat).
Cserélhető adathordozók és a subfs
A cserélhető adathordozók most már integrálva vannak a subfs segédprogrammal. Az adathordozókat már nem kell kézzel felcsatolni a mount utasítással. Az adathordozó felcsatolásához egyszerűen csak váltson át a /media könyvtár megfelelő eszközkönyvtárára. Az adathordozók nem dobathatók ki addig, amíg valamilyen program használja őket.Nyomtatókonfiguráció
A nyomtatási rendszer változásairól további információ: A nyomtatási rendszer frissítése, felújítása és átállítása.
9.1-ről 9.2-reSLES9-ről SLES10-re (1. rész)
Forduljon a http://portal.suse.com címen található SUSE támogatási adatbázis »A SUSE LINUX 9.2 ismert problémái és speciális funkciói« cikkéhez (a speciális funkciók kulcsszó alatt).
A tűzfal aktiválása az ezt felajánló párbeszédablakban telepítés közben
A nagyobb biztonság érdekében a mellékelt SuSEFirewall2 tűzfal aktiválásra kerül a telepítés végén az ezt felajánló párbeszédablakban. Ez azt jelenti, hogy kezdetben minden port le lesz zárva és itt, a párbeszédablakban nyitható meg, amennyiben szükséges. Alapértelmezésben más, távoli rendszerekből nem lehet bejelentkezni. Szintén megakadályozza a tűzfal a hálózat szabad tallózását, valamint a multicast-alkalmazásokat, mint például az SLP, a Samba (»Hálózatok«) és egyes játékok működését. A tűzfalbeállítások finomhangolására a YaST használható.
Ha hálózati hozzáférésre van szükség telepítés közben egy szolgáltatás telepítéséhez vagy beállításához, a megfelelő YaST-modul megnyitja a szükséges TCP- és UDP-portokat az összes belső és külső csatolón. Ha ez nem kívánatos, a felhasználó lezárhatja a portokat a YaST-modulban, vagy megadhat más, részletesebb tűzfalbeállításokat.
| Szolgáltatás | Port |
|---|---|
| HTTP-kiszolgáló | A tűzfal a »list« utasításoknak megfelelően kerül beállításra (csak TCP) |
| Mail (postfix) | smtp 25/TCP |
| Samba-kiszolgáló | netbios-ns 137/TCP; netbios-dgm 138/TCP; netbios-ssn 139/TCP; microsoft-ds 445/TCP |
| DHCP-kiszolgáló | bootpc 68/TCP |
| DNS-kiszolgáló | domain 53/TCP; domain 53/UDP |
| DNS-kiszolgáló | További speciális támogatás a portleképezőhöz a SuSEFirewall2-ben |
| Portleképező | sunrpc 111/TCP; sunrpc 111/UDP |
| NFS-kiszolgáló | nfs 2049/TCP |
| NFS-kiszolgáló | Plusz portleképező |
| NIS-kiszolgáló | Aktiválja a portleképezőt |
| TFTP | tftp 69/TCP |
| CUPS (IPP) | ipp 631/TCP; ipp 631/UDP |
KDE- és IPv6-támogatás
Alapértelmezésben az IPv6-támogatás nincs bekapcsolva a KDE-hez. Engedélyezni a YaST /etc/sysconfig szerkesztőjével lehet. Az ok, amiért a funkció le van tiltva, hogy nem minden internet-szolgáltató támogatja még tökéletesen az IPv6-címeket és ez hibaüzeneteket, illetve késve megjelenített oldalakat eredményezhet webböngészés közben.
YaST online frissítés és "delta csomagok"
A YaST online frissítés most már támogat egy speciális fajta RPM-csomagot, amely egy alapcsomaghoz képest csak a bináris eltéréseket tatalmazza. Ez a módszer lényegesen lecsökkenti a csomagok méretét és a letöltésükhöz szükséges időt; igaz, a végső csomag összeállítása nagyobb terhet ró a CPU-ra. Az /etc/sysconfig/onlineupdate fájlban állítható be, hogy a YOU használja-e ezeket a "delta-csomagokat." A műszaki részletek itt olvashatók: file:///usr/share/doc/packages/deltarpm/README.
A nyomtatási rendszer beállításai
A telepítés végén (az ezt felajánló párbeszédablakban) a nyomtatási rendszerhez szükséges portokat ki kell nyitni a tűzfalon. A CUPS használatához a 631-es TCP és a 631-es UDP portra van szükség, és normál működés közben nem szabad őket lezárni. A régi LPD-protokollhoz tartozó 515-ös TCP-portot és a Samba által használt portokat szintén ki kell nyitni LPD, illetve SMB protokollon keresztüli nyomtatáshoz.
Váltás az X.Org rendszerre
Az XFree86 helyett immár az X.Org alkalmazását kompatibilitási láncok segítik, amelyek lehetővé teszik a fontos fájlok és parancsok elérését a régebbi neveken is.
| XFree86 | X.Org |
|---|---|
| XFree86 | Xorg |
| Xf86config | xorgconfig |
| Xf86cfg | xorgcfg |
| XFree86 | X.Org |
|---|---|
| XFree86.0.log | Xorg.0.log |
| XFree86.0.log.old | Xorg.0.log.old |
Az X.Org rendszerre átállás során a csomagok neve XFree86* helyett xorg-x11* lett.
X11-terminálemulátorok
Töröltünk egy sor terminálemulátort, mert már vagy nem támogatják, vagy nem működnek az alapértelmezett környezetben, elsősorban mert nem kezelik az UTF-8 kódolást. A SUSE LINUX tartalmaz szabványos terminálokat, mint például az xterm, a KDE- és GNOME-terminálok, valamint az mlterm (Multilingual Terminal Emulator for X), amelyek használhatók az aterm és az eterm helyett.
A powersave csomag módosításai
Az /etc/sysconfig/powersave könyvtár konfigurációs fájljai megváltoztak:
| Régi | Így lett szétvágva |
|---|---|
| /etc/sysconfig/powersave/common | common |
| cpufreq | |
| events | |
| battery | |
| sleep | |
| thermal |
Az /etc/powersave.conf fájl elavult. A meglévő változók átkerültek a fent (Több részre vágott konfigurációs fájlok az /etc/sysconfig/powersave könyvtárban) bemutatott fájlokba. Ha megváltoztatta az »event« (esemény-) változókat az /etc/powersave.conf fájlban, akkor ezeket most át kell vezetni az /etc/sysconfig/powersave/events fájlba is.
Az alvási állapotok neve megváltozott a következőkről:
- felfüggesztés (ACPI S4, APM suspend)
- készenlét (ACPI S3, APM standby)
Az alábbiakra:
- felfüggesztés lemezre (ACPI S4, APM suspend)
- felfüggesztés memóriába (ACPI S3, APM suspend)
- készenlét (ACPI S1, APM standby)
OpenOffice.org (OOo)
- Könyvtárak
-
- Az OOo most már az /usr/lib/ooo-1.1 könyvtárba kerül telepítésre, nem az /opt/OpenOffice.org könyvtárba. A felhasználói beállítások alapértelmezett könyvtára most a már a ~/.ooo-1.1, nem pedig a ~/OpenOffice.org1.1.
- KDE- és GNOME-támogatás
-
- A KDE- és GNOME-bővítések az OpenOffice_org-kde és OpenOffice_org-gnome csomagokban érhetők el.
- Burkoló
-
- Van néhány új burkoló az OOo komponensek indításához. Az új nevek: Burkoló.
| Régi | Új |
|---|---|
| /usr/X11R6/bin/OOo-calc | /usr/bin/oocalc |
| /usr/X11R6/bin/OOo-draw | /usr/bin/oodraw |
| /usr/X11R6/bin/OOo-impress | /usr/bin/ooimpress |
| /usr/X11R6/bin/OOo-math | /usr/bin/oomath |
| /usr/X11R6/bin/OOo-padmin | /usr/sbin/oopadmin |
| /usr/X11R6/bin/OOo-setup | – |
| /usr/X11R6/bin/OOo-template | /usr/bin/oofromtemplate |
| /usr/X11R6/bin/OOo-web | /usr/bin/ooweb |
| /usr/X11R6/bin/OOo-writer | /usr/bin/oowriter |
| /usr/X11R6/bin/OOo | /usr/bin/ooffice |
| /usr/X11R6/bin/OOo-wrapper | /usr/bin/ooo-wrapper |
- A burkoló most már támogatja az --icons-set paraméter használatát is a KDE- és GNOME-ikonok közötti váltáshoz. Az alábbi paraméterek viszont már nem támogatottak: --default-configuration, --gui, --java-path, --skip-check, --lang (a nyelvet most már a területi beállítások határozzák meg), --messages-in-window és --quiet.
A kmix hangkeverő
Alapértelmezésben a kmix a beállított hangkeverő. Felsőkategóriás hardverhez más keverők is létezhetnek, mint a QAMix/KAMix, az envy24control (csak az ICE1712), vagy a hdspmixer (csak az RME Hammerfall).DVD-írás
A múltban a cdrecord csomagban található cdrecord bináris állományhoz mellékeltünk egy javítást a DVD-k írásának támogatásához. Most már egy új, cdrecord-dvd nevű bináris állomány kerül telepítésre, amelyik tartalmazza ezt a javítást.
A dvd+rw-tools csomagban található growisofs program most már mindenfajta DVD-adathordozót (DVD+R, DVD-R, DVD+RW, DVD-RW, DVD+RL) képes írni. Javasoljuk, hogy a foltozott cdrecord-dvd helyett ezt használja.
Többféle kernel
Lehetséges egymás mellé többféle kernelt telepíteni. Ez a funkció arra szolgál, hogy a rendszergazdák frissíthessenek az egyik kernelről a másikra egy új telepítésével, ellenőrizhessék, hogy az új kernel rendben működik-e, és utána törölhessék a régit. Bár a YaST még nem támogatja ezt a funkciót, a kernelek egyszerűen telepíthetők és távolíthatók el a parancssorból az rpm -i csomag.rpm parancs használatával. A csomagok parancssori kezeléséről további információ: RPM — a csomagkezelő.
Az alapértelmezett rendszertöltő menük csak egy kernelbejegyzést tartalmaznak. Több kernel telepítése előtt célszerű felvenni a bejegyzéseket az újakhoz, hogy könnyebb legyen kiválasztani őket. Az új kernel telepítése előtti példány vmlinuz.previous és initrd.previous néven érhető el. Ha készít egy, az alapértelmezetthez hasonló rendszertöltő-bejegyzést, amelyik a vmlinuz.previous és initrd.previous fájlokra mutat (a vmlinuz és initrd helyett), akkor az előzőleg aktív kernel is elérhető. Ennek alternatívájaként a GRUB és a LILO támogatja helyettesítő karakterekkel megadott rendszertöltő-bejegyzések használatát is. Ennek részleteiről a GRUB info oldalain (info grub) és a lilo.conf (5) kézikönyvoldalon (man) talál további információt.
9.2-ről 9.3-ra SLES9-ről SLES10-re (2. rész)
Forduljon a http://portal.suse.com címen található SUSE támogatási adatbázis »A SUSE LINUX 9.3 ismert problémái és speciális funkciói« cikkéhez (a speciális funkciók kulcsszó alatt).
Kézi telepítés indítása a kernel paranccsorban
A Kézi telepítés mód eltűnt a rendszertöltő képernyőjéről. Továbbra is lehet kézi módba kapcsolni a linuxrc-t a manual=1 paraméter megadásával. Általában erre nincsen szükség, mivel a kernel parancssorban kényelmesen meg lehet adni a telepítési paramétereket (például textmode=1), vagy egy URL-t telepítési forrásként.Kerberos a hálózati hitelesítéshez
A hálózati hitelesítés alapértelmezett rendszere a Kerberos és nem a heimdal. A meglévő heimdal-konfigurációk automatikus átalakítása nem lehetséges. A rendszerfrissítés során másolatok készülnek a konfigurációs fájlokról, amint azt a Elmentett fájlok mutatja.
| Régi fájl | Elmentett fájl |
|---|---|
| /etc/krb5.conf | /etc/krb5.conf.heimdal |
| /etc/krb5.keytab | /etc/krb5.keytab.heimdal |
Az (/etc/krb5.conf) klienskonfiguráció nagyon hasonlít a heimdal esetére. Ha nincs semmi extra beállítva, elegendő kicserélni a kpasswd_server paramétert arra, hogy admin_server
Nem lehetséges viszont átvenni a kiszolgálóval (kdc/kadmind) kapcsolatos adatokat. A rendszer frissítése után a régi heimdal-adatbázis még mindig elérhető a /var/heimdal könyvtárban; az MIT kerberos adatbázisának a könyvtára a /var/lib/kerberos/krb5kdc.
X.Org konfigurációs fájl
Az SaX2 konfigurációs eszköz az X.Org beállításait az /etc/X11/xorg.conf fájlba írja. A nulláról telepítés során nem születnek kompatibilitási láncok az XF86Config fájlról az xorg.conf fájlra.PAM-konfiguráció
- common-auth
- alapértelmezett PAM-konfiguráció az auth szakaszhoz
- common-account
- alapértelmezett PAM-konfiguráció az account szakaszhoz
- common-password
- alapértelmezett PAM-konfiguráció a jelszóváltáshoz
- common-session
- alapértelmezett PAM-konfiguráció a munkamenetek felügyeletéhezEzeket az alapértelmezett konfigurációs fájlokat be kell ágyazni az alkalmazásspecifikus konfigurációs fájlba, mivel egyszerűbb egy konfigurációs fájlt kezelni és karbantartani, mint a rendszeren meglévő kb. negyvenet. Ha később telepít egy új alkalmazást, az megörökli a már beállított módosításokat és a rendszergazdának nem kell emlékeznie a konfiguráció beállítására.
A változások egyszerűek: Ha az alábbi konfigurációs fájllal rendelkezik (alapértelmezésként a legtöbb alkalmazás számára):
#%PAM-1.0 auth required pam_unix2.so account required pam_unix2.so password required pam_pwcheck.so password required pam_unix2.so use_first_pass use_authtok #password required pam_make.so /var/yp session required pam_unix2.so
akkor az átírható így:
#%PAM-1.0 auth include common-auth account include common-account password include common-password session include common-session
RPM — a csomagkezelő
A SUSE LINUX rendszerben az RPM (Red Hat Package Manager) szolgál a szoftvercsomagok kezelésére. A legfontosabb programjai az rpm és az rpmbuild. A sokoldalú RPM-adatbázist lekérdezve részletes információt kaphatnak a felhasználók, a rendszergazdák és a csomagkészítők a telepített szoftverekről.Alapvetően az rpm-nek ötféle működési módja van: szoftvercsomagok telepítése, eltávolítása vagy frissítése; az RPM-adatbázis újraépítése; RPM-bázisok vagy egyedi RPM-archívumok lekérdezése; a csomagok integritásának ellenőrzése; valamint a csomagok aláírása. Az rpmbuild parancs használható a tiszta forrásból származó csomagok előállítására.A telepíthető RPM-archívumok egy speciális bináris formátumot használnak. Az archívumok a telepítendő programfájlokból, valamint bizonyos, az rpm által a telepítés során használt, vagy dokumentációs célokból az RPM-adatbázisban tárolt metaadatokból állnak. Az RPM-archívumok szokásos kiterjesztése a .rpm.
Az rpm használható LSB-kompatibilis csomagok kezelésére is. Az LSB-ről információ az Szabványok és specifikációk helyen található.
A csomagok hitelességének ellenőrzése
A SUSE LINUX RPM csomagok GnuPG-aláírással rendelkeznek. Az ujjlenyomatban használt kulcs:1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build@suse.de> Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA
Az rpm --checksig apache-1.3.12.rpm parancs használható egy RPM-csomag aláírásának ellenőrzésére; arra, hogy valóban a SUSE-től vagy más, megbízható forrásból származik-e. Ez különösen ajánlott az internetről származó frissítőcsomagok esetében. A SUSE nyilvános csomagaláírási kulcsa általában a /root/.gnupg/ könyvtárban található. A kulcs ezenfelül megtalálható az /usr/lib/rpm/gnupg/ könyvtárban is, hogy a normál felhasználók is ellenőrizhessék az RPM-csomagok aláírását.
Csomagok kezelése: Telepítés, frissítés és eltávolítás
Általában egy RPM-archívum telepítése igen egyszerű: rpm -i csomag_neve.rpm. Ez a parancs telepíti a csomagot, de csak akkor, ha a függőségek teljesülnek és nincs ütközés más csomagokkal. Egy hibaüzenet keretében az rpm kéri, hogy a telepíteni kívánt csomagok teljesítsék a függőségi követelményeket. A háttérben az RPM-adatbázis garantálja, hogy ne lépjen fel semmilyen ütközés – egy adott fájl csak egy csomaghoz tartozhat. Különféle paraméterekkel az rpm kényszeríthető ezen alapértelmezések figyelmen kívül hagyására, de ezt csak szakértőknek ajánljuk. Egyébként a rendszer integritását veszélyezteti, illetve előfordulhat, hogy nem lesz képes frissíteni a rendszert.A -U vagy --upgrade, illeve a -F vagy --freshen opciók használhatók a csomagok frissítésére, például: rpm -F csomag.rpm. Ez a parancs törli a régi változat fájljait és azonnal telepíti az új fájlokat. A kétféle lehetőség közötti különbség az, hogy a -U telepít olyan csomagokat, amelyek korábban nem léteztek a rendszerben, a -F csupán a meglévő csomagokat frissíti. Frissítéskor az rpm a konfigurációs fájlokat is frissíti óvatosan, az alábbi stratégia alkalmazásával:- Ha a rendszergazda nem módosította a konfigurációs fájlt, akkor az rpm telepíti a megfelelő fájl új verzióját. A rendszergazda beavatkozására nincsen szükség.
- Ha a rendszergazda módosította a konfigurációs fájlt a frissítés előtt, akkor az rpm elmenti a fájlt .rpmorig vagy .rpmsave (tartalék fájl) kiterjesztéssel, és telepíti az új csomagban található változatot; de csak akkor, ha az eredetileg telepített fálj és az új változat eltérő. Ebben az esetben hasonlítsa össze az elmentett fájlt (.rpmorig vagy .rpmsave) az újonnan telepített fájllal és ha szükséges, végezze el az új fájlban a szükséges módosításokat. Ezután feltétlenül törölje az .rpmorig és .rpmsave fájlokat a jövőbeni frissítések problémáinak elkerülése érdekében.
- Az .rpmnew fájlok akkor jelennek meg, ha a konfigurációs fájl már létezik és ha a noreplace címke lett megadva a .spec fájlban.
Frissítés után az .rpmsave és .rpmnew fájlokat törölni kell az összehasonlítás után, hogy ne zavarják a későbbi frissítéseket. Az .rpmorig kiterjesztést akkor használja a program, ha a fájl korábban nem volt ismert az RPM-adatbázisban.
Minden más esetben az .rpmsave név kerül alkalmazásra. Más szavakkal, az .rpmorig egy idegen formátumról RPM-re frissítés eredménye. Az .rpmsave egy régebbi RPM-ről egy újabb RPM-re frissítés eredménye. Az .rpmnew fájlokból nem derül ki, hogy a rendszergazda módosította-e a konfigurációs fájlt. Az ilyen fájlok listája a /var/adm/rpmconfigcheck helyen található. Egyes konfigurációs fájlok (például az /etc/httpd/httpd.conf) nem kerülnek felülírásra a folyamatos működés fenntartása érdekében.
A -U kapcsoló nem egyenértékű a -e paraméterrel történő eltávolítással és a -i paraméterrel történő telepítéssel. Ahol csak lehet, inkább a -U paramétert használja.
Egy csomag törléséhez írja be, hogy rpm -e csomag_neve. Az rpm csak akkor törli a csomagot, ha nincsenek feloldatlan függőségek. Elvileg lehetetlen például törölni a Tcl/Tk-t addig, amíg egy másik alkalmazás használja. Még ebben az esetben is, az RPM az adatbázistól kér segítséget. Ha az ilyen törlés – bármilyen okból és akár szokatlan körülmények között is – lehetlennek bizonyul, még akkor is, ha semmilyen további függőség nincs, akkor célszerű lehet újraépíteni az RPM-adatbázist a --rebuilddb paraméter használatával.
Az RPM és a javítások
A rendszer működési biztonságának garantálásához időről időre frissítőcsomagokat kell telepíteni a rendszeren. Korábban egy csomag egy hibáját csak a teljes csomag cseréjével lehett megoldani. A kis fájlokban hibákat tartalmazó nagy csomagok javításai feleslegesen nagy adatmennyiséget eredményeztek. A SUSE RPM azonban lehetővé teszi az egyes csomagok foltozását.A legfontosabb szempontokat a pine példáján keresztül mutatjuk be:
- A javító RPM megfelelő-e a rendszerhez?
- Ennek ellenőrzéséhez először le kell kérdezni a csomag telepített verzióját. A pine esetében erre a következő parancs szolgál:
rpm -q pine pine-4.44-188
- Ezután ellenőrizni kell, hogy a javító RPM megfelelő-e a pine adott verziójához:
rpm -qp --basedon pine-4.44-224.i586.patch.rpm pine = 4.44-188 pine = 4.44-195 pine = 4.44-207
- Ez a javítás a pine háromféle verziójához jó. Mivel a telepített verzió is megtalálható a listában, a javítás telepíthető.
- Milyen fájlokat cserél le a javítás?
- A javítás által érintett fájlok egyszerűen megtekinthetők a javító RPM-ben. Az rpm-P paraméterével speciális javítási funkciók választhatók ki. A fájlok az alábbi paranccsal listázhatók:
rpm -qpPl pine-4.44-224.i586.patch.rpm /etc/pine.conf /etc/pine.conf.fixed /usr/bin/pine
- vagy ha a javítás már telepítve van, akkor az alábbival:
rpm -qPl pine /etc/pine.conf /etc/pine.conf.fixed /usr/bin/pine
- Hogyan történik a javító RPM telepítése a rendszerben?
- A javító RPM-ek ugyanúgy használhatók, mint a szokásos RPM-ek. Az egyetlen különbség, hogy a javítandó RPM-nek már telepítve kell lennie.
- Milyen javítások vannak telepítve a rendszeren és mely csomagokhoz?
- A rendszeren telepített összes javítást az rpm <tt>-qPa</tt> parancs listázza ki. Ha csak egyetlen javítás van telepítve egy új rendszeren (mint a fenti példában), akkor a lista így néz ki:
rpm -qPa pine-4.44-224
- Ha később kíváncsi arra, hogy mely csomagverziók mikor lettek telepítve, ez is lekérdezhető az RPM-adatbázisból. A pine esetében ezt az információt a következő paranccsal lehet kiíratni:
rpm -q --basedon pine pine = 4.44-188
További információ, így például az RPM javítási funkciójáról az rpm és az rpmbuild parancsok kézikönyvoldalain (man) olvashatók.
Delta RPM-csomagok
A »delta RPM« csomagok egy RPM-csomag régebbi és új változata közötti különbséget (»deltát«) tartalmazzák. Egy delta RPM alkalmazása egy régi RPM-en egy teljesen új RPM-et fog eredményezni. Ha nincs meg a régi RPM-példány, a delta RPM a telepített RPM-mel is képes együttműködni. A deltarpm csomagok még a javító RPM-eknél is kisebbek. Ez hasznos, ha a frissítőcsomagokat az interneten keresztül kell elküldeni. A hátránya, hogy a delta RPM-ekkel végzett frissítési műveletek lényegesen jobban megterhelik a CPU-t, mint a sima és javító RPM-ek használata. Ahhoz, hogy a YaST delta RPM-csomagokat használjon a YOU-munkamenetekben, állítsa az /etc/sysconfig/onlineupdate fájlban található YOU_USE_DELTAS változót a »yes« értékre.A prepdeltarpm, writedeltarpm és applydeltarpm bináris fájlok a deltarpm csomag részei. Ezek segítenek a delta RPM-csomagok elkészítésében és alkalmazásában. Az alábbi parancsokkal készíthető egy new.delta.rpm nevű delta RPM (feltéve, hogy az old.rpm és a new.rpm rendelkezésre áll):
prepdeltarpm -s seq -i info old.rpm > old.cpio prepdeltarpm -f new.rpm > new.cpio xdelta delta -0 old.cpio new.cpio delta writedeltarpm new.rpm delta info new.delta.rpm rm old.cpio new.cpio delta
Az applydeltarpm használatával előállítható az új RPM, akár a fájlrendszerből is, ha a régi csomag már telepítve van:
applydeltarpm new.delta.rpm new.rpm
Vagy pedig a -r paraméter használatával származtatható a régi RPM-ből, a fájlrendszer elérése nélkül:
applydeltarpm -r old.rpm new.delta.rpm new.rpm
A műszaki részletek a file:///usr/share/doc/packages/deltarpm/README helyen találhatók.
RPM-lekérdezések
A -q paraméter megadása esetén az rpm lekérdezéseket indít. Megvizsgálható egy adott RPM-archívum (a -p paraméterrel) és lekérdezhető a telepített csomagok RPM-adatbázisa. Többféle kapcsoló is használható a kívánt adatok típusának megadására (lásd: A legfontosabb RPM-lekérdezési paraméterek).
| -i | Csomaginformáció |
| -l | Fájllista |
| -f FÁJL | A FÁJL fájlt tartalmazó csomag lekérdezése (a FÁJL-t teljes elérési úttal kell megadni) |
| -s | Fájllista állapotinformációval (magával vonja a -l alkalmazását) |
| -d | Csak a dokumentációs fájlok listázása (magával vonja a -l alkalmazását) |
| -c | Csak a konfigurációs fájlok listázása (magával vonja a -l alkalmazását) |
| --dump | Részletes fájllista (a -l, -c és -d paraméterekkel együttes használathoz) |
| --provides | Azon csomagok funkcióinak listázása, amelyeket egy másik csomag kérhet a --requires paraméterrel |
| --requires, -R | A csomag által igényelt képességek |
| --scripts | Telepítési parancsfájlok (telepítés előtti, utáni és eltávolító) |
Például az rpm -q -i wget parancs hatására a rpm -q -i wget által mutatott eredményt kapjuk.
Example: rpm -q -i wget
Név : wget
Áthelyezés : (nem áthelyezhető)
Verzió : 1.9.1
Gyártó : SUSE LINUX AG, Nuernberg, Germany
Kiadás : 50
Készítési dátum : Sat 02 Oct 2004 03:49:13 AM CEST
Telepítési dátum: Mon 11 Oct 2004 10:24:56 AM CEST
Készítő gép : f53.suse.de
Csoport : Productivity/Networking/Web/Utilities
Forrás RPM : wget-1.9.1-50.src.rpm
Méret : 1637514
Licenc : GPL
Aláírás : DSA/SHA1, Sat 02 Oct 2004 03:59:56 AM CEST, Key ID a84edae89c800aca
Packager : http://www.suse.de/feedback
URL : http://wget.sunsite.dk/
Összefoglalás : Eszköz FTP- és HTTP-kiszolgálók tükrözéséhez
Leírás : A Wget segítségével lekérhetők WWW-dokumentumok vagy FTP-fájlok egy
kiszolgálóról. Működhet parancsfájlokban, de a konzolon önálóan is.
[...]
A -f csak akkor működik, ha a teljes fájlnevet adja meg, elérési úttal együtt. Annyi fáljnevet adhat meg, amenyi csak jólesik. Például az alábbi parancs:
rpm -q -f /bin/rpm /usr/bin/wget
eredménye a következő:
rpm-4.1.1-191 wget-1.9.1-50
Ha csak a fájlnév egy része ismert, használjon egy parancsfájlt (Parancsfájl csomagok kereséséhez). A részleges fájlnevet adja át paraméterként a parancsfájlnak.
Example: Parancsfájl csomagok kereséséhez
#! /bin/sh
for i in $(rpm -q -a -l | grep $1); do
echo "\"$i\" is in package:"
rpm -q -f $i
echo ""
done
Az rpm -q --changelog rpm parancs egy csomag részletes adatait (frissítések, konfiguráció, módosítások stb.) írja ki. Az alábbi példa az rpm csomagról ír ki információt. Ténylegesen csak az RPM-adatbázis legutolsó öt bejegyzése íródik ki. A többi bejegyzés (két évre visszamenőleg) a csomagban magában található. Ez a lekérdezés csak akkor működik, ha az 1. számú CD a /media/cdrom pontra van felcsatolva:
rpm -qp --changelog /media/cdrom/suse/i586/rpm-4*.rpm
A telepített RPM-adatbázis segítségével ellenőrzések is végezhetők. Ezek a -V, -y vagy --verify paraméterrel indíthatók. E paraméter használatakor az rpm megjeleníti egy csomagnak a telepítés óta módosult fájljait. Az rpm nyolc karakterszimbólum segítségével jelzi az alábbi módosításokat:
| 5 | MD5-ellenőrzőösszeg |
| S | Fájlméret |
| L | Szimbolikus lánc |
| T | Módosítás ideje |
| D | Fő- és aleszközszámok |
| U | Tulajdonos |
| G | Csoport |
| M | Mód (jogosultságok és fájltípus) |
Konfigurációs fájlok esetében a c betű kerül kiírásra. Például az /etc/wgetrc (wget) módosításainak kiírása:
rpm -V wget S.5....T c /etc/wgetrc
Az RPM-adatbázis fájljai a /var/lib/rpm könyvtárban találhatók. Ha az /usr partíció mérete 1 GB, akkor ez az adatbázis közel 30 MB-ot foglal, különösen teljes frissítés után. Ha az adatbázis sokkal nagyobb a vártnál, akkor célszerű újraépíteni az adatbázist a --rebuilddb opcióval. Előtte azonban mentse el a régi adatbázist. A cron.dailycron-parancsfájl napi másolatokat készít az adatbázisról (gzip-pel tömörítve) és a /var/adm/backup/rpmdb könyvtárba menti őket. A másolatok számát az /etc/sysconfig/backup fájl MAX_RPMDB_BACKUPS változója szabályozza (alapértelmezés: 5). Egy mentés mérete mintegy 3 MB az /usr minden 1 GB-jára.
Forráscsomagok telepítése és lefordítása
A SUSE LINUX forrásfájlokat tartalmazó csomagjai .src.rpm (source RPM, forrás RPM) kiterjesztéssel rendelkeznek.
Az alábbi könyvtáraknak az rpm és az rpmbuild rendelkezésére kell állniuk az /usr/src/packages könyvtárban (hacsak nincsenek megadva egyedi beállítások például az /etc/rpmrc fájlban):
- SOURCES
- az eredeti forrásokhoz (.tar.bz2 or .tar.gz files, etc.) és a disztribúcióspecifikus módosításokhoz (általában .diff vagy .patch fájlok)
- SPECS
- a .spec fájlokhoz. Ezek az összeállítási (build) folyamatot vezérlő meta Makefile fájlokhoz hasonlók
- BUILD
- az összes forrás kicsomagolva, foltozva és lefordítva található meg ebben a könyvtárban
- RPMS
- ahol a kész bináris csomagok találhatók
- SRPMS
- itt találhatók a forrás RPM-ekEgy forráscsomag YaST-tal telepítése közben az összes szükséges összetevő telepítésre kerül az /usr/src/packages könyvtárban: a forrás és a módosítások a SOURCES, a vonatkozó .spec fájl pedig a SPECS könyvtárban.
Az alábbi példa a wget.src.rpm csomagot mutatja be. Telepítve a csomagot a YaST-tal, az alábbi listához hasonló fájlok kell, hogy megjelenjenek:
/usr/src/packages/SOURCES/nops_doc.diff /usr/src/packages/SOURCES/toplev_destdir.diff /usr/src/packages/SOURCES/wget-1.9.1+ipvmisc.patch /usr/src/packages/SOURCES/wget-1.9.1-brokentime.patch /usr/src/packages/SOURCES/wget-1.9.1-passive_ftp.diff /usr/src/packages/SOURCES/wget-LFS-20040909.tar.bz2 /usr/src/packages/SOURCES/wget-wrong_charset.patch /usr/src/packages/SPECS/wget.spec
Az rpmbuild -b X /usr/src/packages/SPECS/wget.spec parancs indítja el a fordítást. Az X helyére az összeállítási folyamat különböző szakaszai kerülnek (a részletek a --help paraméterrel elindított program kimenetén, vagy az RPM-dokumentációban olvashatók). Alább csak egy egészen rövid magyarázat következik:
- -bp
- A források előkészítése az /usr/src/packages/BUILD könyvtárban: kicsomagolás és foltozás.
- -bc
- Ugyanaz, mint a -bp, de fordítással.
- -bi
- Ugyanaz, mint a -bp, de az összeállított szoftver telepítésével. Vigyázat: ha a csomag nem támogatja a BuildRoot funkciót, akkor előfordulhat, hogy felülíródnak egyes konfigurációs fájlok.
- -bb
- Ugyanaz, mint a -bi, de a bináris csomag létrehozásával. Ha a fordítás sikeres, a bináris fájl az /usr/src/packages/RPMS könyvtárban kell, hogy legyen.
- -ba
- Ugyanaz, mint a -bi, de a forrás RPM létrehozásával. Ha a fordítás sikeres, a bináris fájl az /usr/src/packages/SRPMS könyvtárban kell, hogy legyen.
- --short-circuit
- Egyes lépések kihagyása.A létrehozott bináris RPM most már telepíthető az rpm <tt>-i</tt>, vagy még inkább az rpm <tt>-U</tt> paranccsal. Az rpm-mel telepítve a csomag megjelenik az RPM-adatbázisban.
RPM-csomagok lefordítása a build segítségével
Sok csomag esetében az a veszély, hogy nemkívánatos csomagok is bekerülnek a futó rendszerbe az összeállítási folyamat közben. Ennek megakadályozására használható a build parancs, amelyik létrehoz egy jóldefiniált környezetet, amelyben a csomag összeállítása zajlik. E chroot-környezet létrehozásához a build parancsfájlnak meg kell adni a teljes csomagfát. Ez a fa biztosítható a merevlemezről, NFS-en keresztül, vagy DVD-ről. A megfelelő pozíciót a build --rpms könyvtár parancs adja meg. Szemben az rpm paranccsal, a build parancs a forráskönyvtár SPEC fájlját keresi meg. A wget vadonatúj (a fenti példához hasonló) összeállításához, amennyiben a DVD fel van csatolva a rendszerbe a /media/dvd ponton, adja ki a következő parancsot, mint root felhasználó:
cd /usr/src/packages/SOURCES/ mv ../SPECS/wget.spec . build --rpms /media/dvd/suse/ wget.spec
Létrejön egy minimális környezet a /var/tmp/build-root könyvtár alatt. A csomag ebben a környezetben készül el. Befejezés után az eredményül kapott csomagok a /var/tmp/build-root/usr/src/packages/RPMS könyvtárban találhatók.
A build parancsfájl többféle kiegészítő paraméter használatát is lehetővé teszi. A parancsfájl például előnyben részesíthet saját RPM-eket, kihagyhatja az összeállítási környezet inicializálását, vagy a fenti fázisok közül egyre korlátozhatja az rpm parancs használatát. További információ a build <tt>--help</tt> paranccsal, vagy a build kézikönyvoldalán (man) érhető el.
Eszközök az RPM-archívumokhoz és az RPM-adatbázishoz
A Midnight Commander (mc) képes megjeleníteni az RPM-archívumok tartalmát és kimásolni egy részüket. Az archívumokat virtuális fájlrendszerekként jeleníti meg, amelyekben a Midnight Commander szinte minden szokásos parancsa használható. A HEADER például az F3 billentyűvel tekinthető meg. Az archívumstruktúra bejárható a kurzorbillentyűk és az Enter segítségével. Az archívum egyes elemei kimásolhatók az F5 billentyűvel.A KDE a kpackage eszközt biztosítja az rpm grafikus előtétprogramjaként. YaST-modulként egy teljes funkciókörű csomagkezelő is elérhető (lásd: Szoftver telepítése és eltávolítása).