Better Fedora
Версия: 0.04
За този документ
Преди около две години за сайта „Linux за българи“ написах статия, в която събрах купчина дребни съвети за това как да направим по-лъскав и удобен за работа актуалния тогава Red Hat 8. Оттогава досега много хора ми писаха, че използват статията при конфигуриране на системите си. Аз лично също често се връщам към нея за да си припомня някой детайл като правя нова машина.
За първи път се сблъсках с Linux (Slackware) през 1996-1997, но тогава завършвах университета, очакваше ме казарма и чопленето в тази посока определено не бе с висок приоритет. През 1998 започнах частен бизнес и реших да опитам друга дистрибуция в офиса, а именно Red Hat. И така още тогава (от версия 5.0) Red Hat Linux се превърна в моят десктоп и досега е така. Вярно – от скоро се нарича Fedora. Вероятно на много хора това и сега звучи кощунствено. Представете си как звучеше тогава. Linux за десктоп е тема, която е предизвикала не една ожесточена дискусия – дори сред привърженици на софтуера с отворен код. Моят избор беше продиктуван от идеята, че не искам да използвам собственически софтуер, когато мога да използвам свободен. Дори и ако втория не е достатъчно читав или стабилен. Изборът ми бе чисто морален… И – признавам си – съдържаше не малка доза инат.
Налагаше се много неща да преоткривам сам, понякога с помощта на половинчати сламки, намерени из Интернет. Споделях направеното на http://linux.gyuvet.ch. Сега вече няма смисъл от такъв сайт – далеч по-лесно е да намериш всичко в Интернет. Дистрибуциите се развиха грандиозно. И все пак, дори и днес, някои неща като например поддръжка на mp3, DVD или компоненти, които не са свободен софтуер като Flash няма как да се разпространяват с дистрибуциите и човек трябва да си ги добави сам.
Често попадам на материали като този, които подобно на моята статия за Red Hat 8 се опитват да подсказват идеи за това или онова. Вдъхновен и от новата Fedora Core 2, която наистина е една превъзходна колекция, реших да започна една статия, която ще дописвам непрекъснато съобразно темповете на развитие на Fedora Core, която ще съдържа събрани на едно място и проверени допълнения към стандартната колекция пакети, която екипа на Fedora прави.
Изборът ми на Fedora мисля, че е ясен. Седемгодишния ми опит с дистрибуциите на Red Hat ми дава основанието да си мисля, че ги познавам изключително добре. Каквото и да сте чули или прочели за Red Hat моето мнение е, че те правят чудесни, стабилни и много премислени дистрибуции, с които е удоволствие да работя. А и припознавам Fedora като моят тип дистрибуция. Без да искам да кажа нищо лошо за останалите, които също с удоволствие ползвам и разглеждам отвреме на време. Просто Fedora е моят избор. Така, че това е документ за Fedora Core. Вероятно всичко тук е валидно на 100% и за Red Hat Desktop и Red Hat Enterprise, а може би и за други rpm-базирани дистрибуции, но дотолкова доколкото това не е проверено не мога да го твърдя със сигурност.
В този материал няма да застъпвам едно или друго направление на Linux – според основната идея на този материал – тук ще има както полезни идеи за десктоп употреба така и за сървърна администрация.
Важна дреболия
Щом четете такъв материал вероятно вие сте човека, който и администрира системата си. В същото време навярно вече знаете, че идеята да работите като root потребител е не само проява на лош вкус, но и не особено безопасно намерение. Този потребител се използва само за администрация, но пък понякога наистина е досадно непрекъснато да превключвате потребителите или да имате една или две обикновени конзоли и още една или две като потребител root – особено когато ни трябва административен достъп за една команда, каквато е например инсталацията на пакет.
Едно елегантно решение е командата sudo, която интересно защо често ненужно стои обвита в забвение. Всичко което е нужно да направите е да добавите в /etc/sudoers един ред за вашия потребител, който отвреме на време ще трябва да изпълнява админстративни задачи. Например за потребителя yovko така:
# User privilege specification<br></br>
root ALL=(ALL) ALL<br></br>
yovko ALL=(ALL) ALL```
Друг вариант е да добавите потребителя yovko в групата wheel и да разрешите тези права за цялата група wheel така:
` %wheel ALL=(ALL) ALL`
Сега вече когато ми е нужно да инсталирам пакет не е нужно да ставам root, а просто трябва да напиша sudo пред командата, която искам да изпълня с административни права:
`sudo rpm -Uvh packagename.rpm`
Ще бъда попитан за паролата си – при това забележете – моята парола – а не тази на root, след което командата се изпълнява с административни права.
Забележете, че файлът /etc/sudoers е с разрешения само за четене дори и за потребител root. За да го редактирате трябва временно да си дадете на root права за писане, като не забравите да ги махнете след това. По-лесно е да използвате и нарочната команда за редактиране на този файл visudo.
> Бърз курс за yum
Отдавна отминаха времената, когато Linux-системите се инсталираха с дискети и CD-та. При положение, че все повече живеем в Интернет отколкото навън и при възможността да ползваме широколентова свързаност, която пък ни дава бърз начин да разполагаме с всички току-що появили се или обновени пакети софтуер, естествено е да разполагаме и с инструменти, които да ни помагат да го правим.
Като инструмент за управление на пакетите yum се появи за първи път във Fedora Core 1. Името му идва от акронима на Yellowdog Updater Modified и както не е трудно да се досети човек е компонент от дистрибуцията за Mac и PowerPC [Yellow Dog Linux](http://www.yellowdoglinux.com/). До този момент Red Hat предоставяха единствено инструмента up2date, който бе обвързан с услугата им Red Hat Network. Междувременно се появи вариант на apt инструмента на Debian за Red Hat и покрай него започнаха да се роят и apt-хранилища на rpm-пакети за Fedora и Red Hat Linux. Всъщност от Fedora Core 1 насам инструмента up2date във Fedora е различен от up2date за Red Hat и е само интерфейс към yum и apt и няма нищо общо с Red Hat Network, която остана само платена услуга за Enterprise фамилията на Red Hat Inc.
Имам своите съображения да предпочитам yum пред apt, въпреки че apt е наистина много усъвършенстван инструмент, а в комбинация с графични frontend-и като synaptic се превръща в луксозен кадилак. Считам yum за по-native инструмент за rpm-управление, допада ми семплия му стил и вид, идеята за header-ите и автоматизацията за проверката на подписите на пакетите. И понеже за него като че ли няма много известно и достъпно кратко четиво ето моят преразказ на действителността.
Конфигурацията на yum се намира във файла /etc/yum.conf и по подразбиране във Fedora съдържа официалните хранилища на fedora.redhat.com. Този файл условно можем да разделим на две части – началната съдържа общи параметри, а втората списък от хранилища с пакети. И понеже този материал освен като crash course в yum трябва и да разказва и за някакви нововъведения, които можем да добавим към една стандартна Fedora система нека да разгледаме моят yum.conf файл, който използвам към днешна дата:
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=1
exactarch=1
exclude=kernel*
retries=20
gpgcheck=1```
Това са глобалните параметри, които са в сила за yum и за инсталиране на пакет от хранилищата описани след тях. Секцията започва задължително с [main] и задава директорията, където ще се съхраняват свалените пакети, файла за водене на журнал, политиката за инсталация – в случая – винаги най-новите пакети, дали непременно да се инсталират само пакети, компилирани за конкретната архитектура, дали да се проверява gpg подписа на пакетите и други подобни. Самите параметри говорят достатъчно за себе си.
Стойностите им често са 1 (да) или 0 (не). Забележете параметъра exclude=kernel* – при мен е коментиран, което означава, че не се взима под внимание, но ако го активираме това за yum ще означава, че не трябва да се грижи за пакети, които започват с това име – в случая да не се занимава с ядрото, защото може би искаме да го обновяваме на ръка. За стандартни машини, които нямат някакви специално компилирани ядра е добре да оставите yum да се грижи за всичко – ядрата, които идват от отбора разработчици на Fedora са достатъчно универсални и оптимизирани.
Да разгледаме по-интересната част – втората – списъка с хранилища.
[base]<br></br>
name=Fedora Core $releasever - $basearch - Base<br></br>
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/os/```
[updates-released]
name=Fedora Core $releasever - $basearch - Released Updates
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/$basearch/```
#[updates-testing]<br></br>
#name=Fedora Core $releasever - $basearch - Unreleased Updates<br></br>
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/$releasever/$basearch/```
[development]
name=Fedora Core $releasever - Development Tree
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/```
Забележете, че всяко хранилище започва с някакъв идентификатор като [base], след който следват поне два параметъра. Първият е името на хранилището, както ни е приятно да го разпознаваме – само по себе си то е безинтересно за yum. И вторият, който съдържа адреса на хранилището. Забележете, че често се срещат две променливи, които можете да ползвате не само в името, но и като част от URL-а на хранилището. $releasever съдържа номера на версията на дистрибуцията (за Fedora Core 2 това ще бъде числото 2), а $basearch архитектурата на системата ви – например i386. Можем да зададем адрес на хранилище както с променливи така и без тях. Например долните два реда за Fedora Core 2 върху Intel PC ще са напълно идентични:
baseurl=http://mirror.somewhere.net/fedora/$releasever/$basearch/os/<br></br>
baseurl=http://mirror.somewhere.net/fedora/2/i386/os/```
Ако ги зададете с променливи обаче няма да се налага да преглеждате и поправяте номера на версията, когато излезе Fedora Core 3. Горния файл, който цитирам на части всъщност ползвам още от Fedora Core 1. Той както виждате съдържа четирите стандартни хранилища на Fedora. Базовото е самата дистрибуция във вида в който е видяла бял свят, а updates-released са обновените пакети излезли след появата на дистрибуцията. Слагат се и двете за да можете да си добавяте пакети след инсталацията без да са ви нужни дистрибутивните CD-та. Третото и четвъртото хранилище са коментирани, защото аз не ги използвам – те съдържат testing и development колекциите. Когато например излезе test1 на Core 3 не е нужно да сваляте и печете CD-та, просто откоментирайте трите реда за testing хранилището и направете yum update, а ако искате да живеете на ръба можете да опитате и суровото месо от development хранилището.
Хайде сега да добавим още няколко интересни неофициални хранилища. Погледнете файла [yum.conf](src/yum.conf), който използвам в момента и го разгледайте. Хранилището на [Dag Wieers](http://dag.wieers.com/packages/) е най-голямото и превъзходното, което съм срещал. Струва си да го разгледате внимателно и ако някога ви потрябва някакъв пакет със сигурност тук е първото място, което трябва да навестите. Почти задължително е да добавите и хранилищата на fedora.us – там понякога има интересни и различни пакети. Изберете си най-близкия или бърз огледален сървър. Аз съм предпочел един германски. [Livna.org](http://livna.org) също имат интересни попадения – ориентирани съм към мултимедия – предлагат mp3 поддръжка, която Fedora заради лицензни съображения не иска да разпространява, пакетиран mplayer, както и интересния навярно за мнозина техен собствен NVidia driver на rpm.
Хранилището на Университета в Небраска съдържа пакети като RealPlayer, а нищо не ви пречи да добавите и хранилище само за един пакет, както съм направил за flash-player пакета на Warren Togami в края на файла. По времето, когато пиша това [freshrpms.net](http://freshrpms.net) още не съдържа пакети за Core 2, но това също е хранилище, което е просто задължително. Ако имате собствени локални хранилища също можете да ги дефинирате, както аз съм добавил примерни редове за хранилища по NFS. Можете да си добавите и всякакви други интересни източници, които оцените като полезни. Забележете, че към някои от хранилищата съм добавил и други параметри като gpgcheck – това се прави, когато за някое хранилище искате да дефинирате различна политика от тази зададена глобално в началото на файла.
И сега след като имаме най-чудната колекция от хранилища на света какво правим? Ами простичката команда yum update или sudo yum update:
[yovko@eos yovko]$ sudo yum update
Password:
Gathering header information file(s) from server(s)
Server: Fedora Core 2 - i386 - Base
Server: Dag Wieers RPM Repository for Fedora Core 2
Server: Fedora Core 2 -- Fedora Esslingen (Germany) mirror
Server: Livna.org Fedora Compatible Packages (stable)
Server: Macromedia Flash RPM repository by Warren Togami
Server: University of Nebraska-Lincoln stable repository
Server: Fedora Core 2 - i386 - Released Updates
Finding updated packages
Downloading needed headers
Resolving dependencies
Dependencies resolved```
Първото стартиране ще свали header-ите на всички пакети в хранилищата и в зависимост от връзката ви към Интернет може да продължи доста време. След като процедурата приключи в момента, в който пожелаете да инсталирате някакъв пакет просто пишете:
[root@eos root]# yum install openmotif21<br></br>
Gathering header information file(s) from server(s)<br></br>
Server: Fedora Core 2 - i386 - Base<br></br>
Server: Dag Wieers RPM Repository for Fedora Core 2<br></br>
Server: Fedora Core 2 -- Fedora Esslingen (Germany) mirror<br></br>
Server: Livna.org Fedora Compatible Packages (stable)<br></br>
Server: Macromedia Flash RPM repository by Warren Togami<br></br>
Server: University of Nebraska-Lincoln stable repository<br></br>
Server: Fedora Core 2 - i386 - Released Updates<br></br>
Finding updated packages<br></br>
Downloading needed headers<br></br>
Resolving dependencies<br></br>
Dependencies resolved<br></br>
I will do the following:<br></br>
[install: openmotif21 2.1.30-9.i386]<br></br>
Is this ok [y/N]: y<br></br>
Downloading Packages<br></br>
Getting openmotif21-2.1.30-9.i386.rpm<br></br>
openmotif21-2.1.30-9.i386 100% |=========================| 923 kB 00:05<br></br>
Running test transaction:<br></br>
Test transaction complete, Success!<br></br>
openmotif21 100 % done 1/1<br></br>
Installed: openmotif21 2.1.30-9.i386<br></br>
Transaction(s) Complete```
А ако искаме да потърсим пакет :
[root@eos root]# yum search mplayer
Gathering header information file(s) from server(s)
Server: Fedora Core 2 - i386 - Base
Server: Dag Wieers RPM Repository for Fedora Core 2
Server: Fedora Core 2 -- Fedora Esslingen (Germany) mirror
Server: Livna.org Fedora Compatible Packages (stable)
Server: Macromedia Flash RPM repository by Warren Togami
Server: University of Nebraska-Lincoln stable repository
Server: Fedora Core 2 - i386 - Released Updates
Finding updated packages
Downloading needed headers
Looking in available packages for a providing package
Available package: mplayer-fonts.noarch 0:1.1-2.1.fc2.dag from dag matches with
Font files for MPlayer, the Movie Player for Linux
Available package: mplayer-fonts.noarch 0:1.1-2.1.fc2.dag from dag matches with
mplayer-fonts
Available package: mplayerplug-in.i386 0:2.60-2.1.fc2.dag from dag matches with
Browser plugin for mplayer
Available package: mplayerplug-in.i386 0:2.60-2.1.fc2.dag from dag matches with
mplayerplug-in
4 results returned
Looking in installed packages for a providing package
No packages found```
Виждаме, че в хранилището на Dag има четири пакета, които ни интересуват. А ако само искаме да получим информация за някой пакет? Нямаме проблем – можем да попитаме така:
[root@eos root]# yum info j2re<br></br>
Gathering header information file(s) from server(s)<br></br>
Server: Fedora Core 2 - i386 - Base<br></br>
Server: Dag Wieers RPM Repository for Fedora Core 2<br></br>
Server: Fedora Core 2 -- Fedora Esslingen (Germany) mirror<br></br>
Server: Livna.org Fedora Compatible Packages (stable)<br></br>
Server: Macromedia Flash RPM repository by Warren Togami<br></br>
Server: University of Nebraska-Lincoln stable repository<br></br>
Server: Fedora Core 2 - i386 - Released Updates<br></br>
Finding updated packages<br></br>
Downloading needed headers<br></br>
Looking in Available Packages:<br></br>
Name : j2re<br></br>
Arch : i586<br></br>
Version: 1.4.2<br></br>
Release: 5.1.fc2.dag<br></br>
Size : 56.99 MB<br></br>
Group : Development/Languages<br></br>
Repo : Dag Wieers RPM Repository for Fedora Core 2<br></br>
Summary: Sun Java(tm) 2 Runtime Environment<br></br>
Description: This packages provides the environment to run java 2 aplications with JRE.```
Обърнете внимание, че за да може да проверявате дали пакетите са подписани с ключовете на авторите им, трябва да импортирате въпросните публични ключове. Ето например как можем да постъпим с ключа на livna.org:
`[root@eos root]# rpm --import http://rpm.livna.org/RPM-LIVNA-GPG-KEY`
> Българско огледало на Fedora Core
От края на 2003 в Софийския университет благодарение на Веселин Колев и Георги Данчев работи локално огледало на Fedora и Debian. На 2 юни 2004 [Весо Колев лично обяви](http://linux-bg.org/cgi-bin/y/index.pl?page=news&key=362056600) официално огледалото за публично достъпно за цялото българско Интернет пространство. Огледалния сървър предлага и пакетите от FreshRPMS, както и тези от хранилището на Dag Wieers. Вече не е нужно да правите международен трафик за да обновявате системите си. Просто променете yum.conf файла си така, че да можете да ползвате българското огледало:
[base]
name=Fedora Core $releasever - $basearch - Base
baseurl=ftp://ftp2.lcpe.uni-sofia.bg/fedora/linux/core/$releasever/$basearch/os```
[updates-released]<br></br>
name=Fedora Core $releasever - $basearch - Released Updates<br></br>
baseurl=ftp://ftp2.lcpe.uni-sofia.bg/fedora/linux/core/updates/$releasever/$basearch```
[freshrpms]
name=Fedora Core $releasever - $basearch - Freshrpms
baseurl=ftp://ftp2.lcpe.uni-sofia.bg/freshrpms/pub/freshrpms/ayo/fedora/linux/$releasever/$basearch/freshrpms```
[dag]<br></br>
name=Fedora Core $releasever - $basearch - Dag<br></br>
baseurl=ftp://ftp2.lcpe.uni-sofia.bg/freshrpms/pub/dag/fedora/$releasever/en/$basearch/dag```
> Други огледални сървъри
В зависимост от това каква е свързаността ви към Интернет и кое огледало ви е по-бързо е добре вместо стандартните сървъри да си намерите огледало, което ви идва най-близо (бързо) до вас. Например аз работя в София, но свързаността ми към Интернет е директно през Австрия – в този ред на мисли – австрийските и немските огледала са ми най-близо, а не българските. Можете да си изберете огледало от [http://fedora.redhat.com/download/mirrors.html](http://fedora.redhat.com/download/mirrors.html).
И да си пренапишете yum.conf така:
[base]
name=Fedora Core $releasever - $basearch - Base
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/os/```
#Use Austrian mirror<br></br>
[base]<br></br>
name=Fedora Core $releasever - $basearch - Base<br></br>
baseurl=http://ftp.univie.ac.at/systems/linux/fedora/$releasever/$basearch/os/```
> Няколко думи за up2date
Все пак нека накратко да изясним каква е точно промяната в up2date на Fedora Core. Казано с две думи във файла /etc/sysconfig/rhn/sources вече можете да задавате както apt, така и yum хранилища едновременно. Например:
apt macromedia http://ruslug.rutgers.edu macromedia/apt/fedora/2 macromedia
yum livna-stable http://rpm.livna.org/fedora/2/i386/yum/stable/
yum-mirror fedora-core-2 http://fedora.redhat.com/download/up2date-mirrors/fedora-core-2
```
Разликата между yum и apt хранилище е малка. Ключовата разлика e наличието на хедъри. За yum хранилище се счита всяка директория с rpm пакети, достъпна през web, NFS или по друг валиден начин, която съдържа поддиректория headers, съдържаща хедъри на пакетите в хранилището и файла header.info (и/или header.src.info), който ги описва.
Как да си направим локално хранилище за създаване на RPM пакети
Дори и да не сте разработчик понякога може да се ви се наложи да правите свои RPM-пакети. Всъщност това нито е сложно нито особено трудоемко. В общия случай дори не е нужно да разбирате от програмиране.
По правило във всяка RPM-базирана система имате една директорийна йерархия, която съдържа няколко поддиректории – BUILD, RPMS, SOURCES, SPECS, SRPMS, които от своя страна могат да съдържат други поддиректории. Във Fedora и RedHat тази йерархия се намира в /usr/src/redhat. За да я използвате обаче задължително трябва да сте root-потребител, което принципно не само, че не е нужно, но доста често не е желателно. В тази статия ще разгледаме как можем да си създадем собствено потребителско хранилище за създаване на rpm-пакети например в личната си потребителска директория.
Всичко, което ни е нужно е да си създадем (или откопираме от /usr/src/redhat) въпросната структура от директории. На практика са ни нужни само основните пет. Другите така или иначе ще се появят в последствие. Обърнете внимание на главните букви.
$ cd ~<br></br>
$ mkdir rpmbuild<br></br>
$ cd rpmbuild<br></br>
$ mkdir BUILD RPMS SOURCES SPECS SRPMS```
Аз си създавам една поддиректория в моята home-директория, която наричам rpmbuild, но тя може да се казва както ви харесва. Именно в нея създаваме петте поддиректории. Вярвате или не, но вече свършихме половината от работата. Сега остава да създадем само един скрит файл .rpmmacros в домашната си потребителска директория.
`$ touch ~/.rpmmacros`
Отворете го с любимия си текстов редактор и вътре напишете следното:
%_topdir %(echo $HOME)/rpmbuild %debug_package %{nil} %PACKAGER Yovko Lambrev www.yovko.net
На практика файлът съдържа набор от променливи, които указват различни неща при самия процес на създаване на пакета. Всъщност необходимия минимум от съдържание е само първият ред, съдържащ променливата %_topdir. Тя трябва да задава името на локалната ни фабрика за пакети. В случая е описана поддиректорията rpmbuild в home-директорията на потребителя. Ако сте предпочели друго име или място трябва да промените този ред. Втората променлива не е задължителна и указва да не се създава пакет с debug-информация, която ако не сте разработчик няма особен смисъл за вас. В същия файл можете да задавате и други незадължителни параметри, които обикновено се задават в spec-файловете на съответните пакети, но зададени тук се възприемат като стойности по подразбиране, в случай че spec-файла не ги дефинира. В случая тук с третия ред е зададено името (навярно вашето) на човека, създал пакета така както искате то да изглежда в хедърите на rpm-пакета. Запишете файла. Това е всичко. В следващата секция ще разгледаме как можем да създаваме пакети с командата rpmbuild.
> Създаване на RPM-пакет от изходен код с rpmbuild
На практика това е нормалния начин за създаване на rpm-пакет. След като обаче имаме изходния код това означава, че преди да сглобим пакета е нужно да компилираме до изпълним код, който да пакетираме в RPM. За щастие разполагаме с великолепния инструмент rpmbuild, с помощта на който можем да правим почти чудеса. rpmbuild се обособи като отделен инструмент от версия 4.1 на RPM. Така че имайте наум версията на пакетния си мениджър и че няма как да го намерите ако ползвате по-стара. В по-предишните версии някои от функционалностите на rpmbuild се правеха с командата rpm.
За да създадем какъвто и да е rpm-пакет трябва да имаме или да си напишем един spec-файл, който указва детайлите, свързани с пакета, който искаме да получим – например колко файла, съдържащи изходния код на проекта трябва да ползва rpmbuild за да го компилира, кои точно са те, от кои други пакети ще е зависим нашия, кой го е създал, с какви опции да се компилира и много, много, много други неща. Нямам амбицията да разглеждам rpmbuild в детайли, нито теорията на rpm-пакетите. Всеки, който се интересува може да намери достатъчно подробна информация в документацията. Аз ще опитам да разясня бегло само основните неща от процеса.
Нека за целта си харесаме един проект, който искаме да направим на rpm-пакети. Един удобен такъв е socks сървъра dante. Ако отворите архива с изходния му код ще видите, че той съдържа SPECS поддиректория в основната си директория, която пък съдържа dante.spec файл, което ще ни спести писането на такъв, а и се предполага, че след като този е написан от авторите му те най-добре знаят защо именно така изглежда файла. Често вместо SPECS поддиректория архивите с изходен код съдържат само spec-файл, което също е напълно достатъчно.
Свалете изходния код на dante от ftp://ftp.inet.no/pub/socks/ – той представлява един tar.bz2 архив – и го поставете във вашата ~/rpmbuild/SOURCES поддиректория. В интерес на истината не е задължително да го сложите там, но нали искаме нещата си подредени.
Тъй като имаме tar-архив със spec-файл в него трябва просто да изпълним командата:
`$ rpmbuild -ta dante-1.1.14.tar.gz`
Първото, което ще се случи е че архивът ще се разпакетира във вашата ~/rpmbuild/BUILD директория като ще си създаде поддиректория там. След което ще се стартират нормалните обичайни процеси на конфигуриране и компилиране. Най-накрая ще се сглобят и пакетите. След като процесът приключи ще намерите компилираните (в случая три) rpm-пакети в ~/rpmbuild/RPMS/i386 – забележете, че се е създала поддиректория за архитектурата i386. В ~/rpmbuild/SRPMS директорията ще намерите src.rpm-пакетa.
Какво обаче правим ако нямаме готов spec-файл. Принципно трябва да си напишем такъв – най-лесно това става с пренаписване на готов такъв или след консултация с документацията за шаблоните при създаване на пакети за Fedora – проекта предоставя такива. Всички файлове, включително документация и изходен код в разпакетиран вид трябва да се поставят в поддиректория на BUILD. Въпросният spec-файл трябва да се постави в ~/rpmbuild/SPECS и да се изпълни команда rpmbuild -ba (или -bb ако искаме само изпълними инсталационни rpm-пакети). Всеки spec-файл съдържа %define, %prep, %build, %install, %clean и други секции и макроси, които ако някога сте компилирали софтуер от изходен код веднага ще се досетите за какво служат. След успешно приключване на процеса ще намерите пакетите отново в ~/rpmbuild/RPMS/{arch} и ~/rpmbuild/SRPMS.
> Как да отваряме .CAB архиви или self-extract .EXE архиви под Linux
Всичко, което ви е нужно се нарича cabextract и се инсталира с командата:
`$ yum install cabextract`
> Инсталиране на безплатните шрифтове на MS
Можете да си направите rpm-пакет съдържащ тези щрифтове. Нужно е да имате инсталиран cabextract и wget, защото шрифтовете, които MS предоставя са в .cab и .exe файлове. Wget ви е нужен за да свалите въпросните файлове по време на процеса на създаване на пакета.
Трябва да си свалите само един spec-файл от [тук](http://sourceforge.net/project/showfiles.php?group_id=34153&package_id=26315). Поставете файла в вашата SPECS поддиректория на локалното си rpmbuild хранилище и понеже нямаме изходен код в случая и можем да направим само бинарен пакет изпълнете командата:
`$ rpmbuild -bb msttcorefonts-1.3-4.spec`
След сваляне на всичко нужно от Интернет, извличане на шрифтовете от архивите и пакетирането им в rpm-пакет, ще намерите въпросния в RPMS/noarch поддиректорията.
Инсталирайте го и презаредете щрифтовия си сървър:
rpm -Uvh msttcorefonts-1.3-4.noarch.rpm
service xfs reload```
Как да монтираме NTFS дялове?
Ядрото на Fedora още от времената на RedHat не включва по подразбиране поддръжка на NTFS файлови системи. За целта е нужно да прекомпилирате ядрото и да включите нужния модул, което обаче е далеч по времеемко ако просто инсталирате готов модул от rpm-пакет. От Linux NTFS project можете да си свалите rpm за конкретното ви ядро. Важно е да уцелите модула за вашето ядро, разбира се 😉
Инсталирайте го с:
rpm -ivh kernel-ntfs-2.6.6-1.435.i686.rpm
Системата ви повече няма да ви казва, че не разпознава ntfs-дяловете по диска ви.
Поддръжка на mp3
Версията на XMMS, която се разпространява с Fedora е безполезна за прослушване на mp3-файлове, защото заради лицензни обстоятелства тази поддръжка беше изхвърлена от дистрибуцията, още когато се казваше Red Hat Linux. Ако все още обаче не сте си прехвърлили музиката в чудесния и отворен формат ogg можете да си добавите поддръжка на mp3 в XMMS така:
yum install xmms-mp3
Не лоша идея е да си инсталирате и mp3 encoder-а lame – а lame-devel ще ви е нужен за mplayer евентуално 😉
yum install lame lame-devel
Macromedia Flash/Shockwave plug-in
След като имаме зададено хранилище за flash-player пишем просто:
[root@eos root]# yum install flash-plugin
Откъде знам, че се казва така ли? Ами ако не знам мога да потърся, например така:
[root@eos root]# yum search flash*
А ако пък държите да го инсталирате на ръка: http://ruslug.rutgers.edu/macromedia/
Как да си инсталираме RealPlayer?
Ами ако сте си добавили хранилището на Университета в Небраска, за което говорехме в началото на статията просто трябва да направите следното:
yum install RealPlayer9
Това е всичко! Плейърът се стартира с командата realplay.
Java plug-in за Mozilla
Много е простичко и лесно… Разбира се ако сте си добавили в yum.conf хранилището на Dag. След като инсталирате java-та трябва да рестартирате mozilla.
yum install mozilla-j2re
*
Следва продължение…*
ChangeLog:
6 Юли 2004 – ver. 0.04
– Добавен съвет за избор на най-близко огледало за yum.conf1 Юли 2004 – ver. 0.03
– Добавена забележка за visudo
– Добавена инсталация за поддръжка на mp3
– Добавени секции за инсталация на RealPlayer, Java-plugin за Mozilla и NTFS модул към ядрото3 Юни 2004 – ver. 0.02
– Добавен текст за българското огледало на Fedora
– Добавена секция за създаване на локално хранилище за build-ване на RPM-пакети
– Добавена секция за инсталиране на безплатните шрифтове на MS
– Добавен ChangeLog
– Разрешени коментари към статиятаМай 2004 – ver. 0.01
– Първоначална чернова на документа
Коментари ()