[http, php, rpm] tworzneie paczek
Lukas
przebudowałem paczke i zainstalowałem. Po przeinstlowaniu mysqla okazalo
się że się nie da nawiązać połączenia przez php z baza. Więc zassałem
php nowe. Ale po wykonaniu configure --with-mysql --prefix=/usr a potem
checkinstall i zainstalowaniu paczki oraz restarcie apacha nie śmiga :/
Więc zabarałem się za apchache. configure --prefix=usr potem
checkinstall i dupa nie robi paczki, kompiluje sie ladnie ale paczki nie
robi. W sumie męczyłem się cały dzień i do niczego nie doszedłem.
Co chce osiągnąć:
Chce żebym mógł przez php kożystać z mysqla
Konkretne pytania:
Jak poprawnie skompilować i zaintalować apacha 2.0.55 z obsługą php?
jak zarządzacie kodem źródłowym/wynikowym aplikacji, pakietami w
fedorce? Rozumiem ze używacie RPM. Ale czym w takim razie robicie
paczki? checkinstall? ręcznie? Jak?
Czy ktoś ma jakieś uwagi co do instalowania i tworzenia paczek?
Powiem szczerze, że nawet nie mam pojęcia jak radzić sobei z błędami
podczas tworzenia paczki przez checkinstall, kiedy to nie chce utworzyc
paczki i wyrzuca błąd. Np dla apacha 2.0.55 jak zrobie make to jest cacy
ale jak zapodam pozniej checkinstall to juz nie robi paczki :/
macie moze jakieś doświadczenie w tym jak sobe z tym radzic albo jak
szukać rozwiązania lub gdzie znaleść jakieś infomracje?
Przyznam się szczerze ze nie wiem jak nawet mam ugryść ten temat paczek
i jak szukać odpowiedzi na google.
Pozdrawiam.
Marcin mzKoder Załęczny
> chciałem coś któregoś dnia zrobić i zaintlowałem sobie mysql5.
> przebudowałem paczke i zainstalowałem. Po przeinstlowaniu mysqla okazalo
> się że się nie da nawiązać połączenia przez php z baza. Więc zassałem
> php nowe. Ale po wykonaniu configure --with-mysql --prefix=/usr a potem
> checkinstall i zainstalowaniu paczki oraz restarcie apacha nie śmiga :/
> Więc zabarałem się za apchache. configure --prefix=usr potem
> checkinstall i dupa nie robi paczki, kompiluje sie ladnie ale paczki nie
> robi. W sumie męczyłem się cały dzień i do niczego nie doszedłem.
>
> Co chce osiągnąć:
> Chce żebym mógł przez php kożystać z mysqla
>
> Konkretne pytania:
> Jak poprawnie skompilować i zaintalować apacha 2.0.55 z obsługą php?
> jak zarządzacie kodem źródłowym/wynikowym aplikacji, pakietami w
> fedorce? Rozumiem ze używacie RPM. Ale czym w takim razie robicie
> paczki? checkinstall? ręcznie? Jak?
> Czy ktoś ma jakieś uwagi co do instalowania i tworzenia paczek?
> Powiem szczerze, że nawet nie mam pojęcia jak radzić sobei z błędami
> podczas tworzenia paczki przez checkinstall, kiedy to nie chce utworzyc
> paczki i wyrzuca błąd. Np dla apacha 2.0.55 jak zrobie make to jest cacy
> ale jak zapodam pozniej checkinstall to juz nie robi paczki :/
>
> macie moze jakieś doświadczenie w tym jak sobe z tym radzic albo jak
> szukać rozwiązania lub gdzie znaleść jakieś infomracje?
> Przyznam się szczerze ze nie wiem jak nawet mam ugryść ten temat paczek
> i jak szukać odpowiedzi na google.
>
> Pozdrawiam.
Do niedawna używałem fedory i red-hata 7.3 na swoich serwerkach w ten
sposób, że wykopywałem dystrybucyjne pakiety łącznie z jądrem i kompi-
lowałem i instalowałem w ich miejsce najnowsze wersje. Chciałem być
twardy ;) Jeśli Cię to interesuje, to poniżej zamieszczam opis insta-
lacji kompletu: mysql+apache+php ze źródeł. Taką zabawę polecam jednak
wyłącznie w celach edukacyjnych. Fedora posiada doskonałe narzędzie
do zarządzania pakietami - yum. Umożliwia ono bezstresowe zarządzanie
i aktualizowanie systemu, gdyż o aktualizacjach jesteś powiadamiany
a nie jak w przypadku źródeł - sam musisz śledzić ich najnowsze wersje.
Zaczynamy więc od mysql:
rpm -e mysql --nodeps
rpm -e mysql-devel --nodeps
Przechodzimy do katalogu z rozpakowanymi źródłami mysql-a
./configure --prefix=/usr/local/share/mysql
make
make install
export PATH=$PATH:/usr/local/share/mysql/bin
Dodajemy do pliku /etc/profile linijkę:
pathmunge /usr/local/share/mysql/bin after
mysql_install_db
chown mysql -R /usr/local/share/mysql/var
kopiujemy plik /usr/local/share/mysql/share/mysql/mysql.server do
/etc/rc.d/init.d i nadajemy mu nazwę mysqld
Uruchamiamy mysqld: /etc/rc.d/init.d/mysqld start
teraz zabezpieczenie serwera (poprzez nadanie rootowi hasła):
/usr/local/share/mysql/bin/mysql
i polecenia w konsolce która się odpali:
use mysql
delete from user where user='';
update user set password=Password('haslo_roota') where user='root';
FLUSH PRIVILEGES;
Przed apachem musimy zainstalować Expata:
* Expat
rpm -e expat --nodeps
rpm -e expat-devel --nodeps
./configure --prefix=/usr/local/share/expat
make
make install
Przekopiowujemy pliki z katalogów w /usr/local/share/expat do
odpowiednich katalogów w /usr/local.
ldconfig
Następnie apache:
rpm -e httpd --nodeps
./configure --prefix=/usr/local/share/apache --enable-shared=max
--enable-module=most
make
make install
Kopiujemy plik /usr/local/share/apache/bin/apachectl do
/etc/rc.d/init.d.
I na koniec PHP. Ale zanim go instalowałem wymieniałem następujące
biblioteki:
* Zlib
rpm -e zlib --nodeps
rpm -e zlib-devel --nodeps
./configure --prefix=/usr/local/share/zlib --shared
make
make install
Przekopiowujemy pliki z katalogów w /usr/local/share/zlib do
odpowiednich katalogów w /usr/local.
ldconfig
* GD
rpm -e libgd --nodeps
./configure --prefix=/usr/local/share/gd
make
make install
Przekopiowujemy pliki z katalogów w /usr/local/share/gd do
odpowiednich katalogów w /usr/local.
ldconfig
* Jpeg-6b (libjpeg)
rpm -e libjpeg --nodeps
./configure --prefix=/usr/local/share/jpeg-6b --enable-shared
make
Przed wywołaniem "make install" tworzymy katalogi:
/usr/local/share/jpeg-6b oraz jego podkatalogi
bin man man/man1 include lib
gdyż make install tego nie zrobi (tylko wywali błędy)
make install
Przekopiowujemy pliki z katalogów w /usr/local/share/jpeg-6b do
odpowiednich katalogów w /usr/local.
ldconfig
* LibPNG
rpm -e libpng --nodeps
./configure --prefix=/usr/local/share/libpng
make
make install
Przekopiowujemy pliki z katalogów w /usr/local/share/libpng do
odpowiednich katalogów w /usr/local.
ldconfig
* Freetype
rpm -e freetype --nodeps
./configure --prefix=/usr/local/share/freetype
make
make install
Przekopiowujemy pliki z katalogów w /usr/local/share/freetype do
odpowiednich katalogów w /usr/local.
ldconfig
* FontConfig
rpm -e fontconfig --nodeps
./configure --prefix=/usr/local/share/fontconfig
--sysconfdir=/usr/local/etc --disable-docs
make
make install
Przekopiowujemy pliki z katalogów w /usr/local/share/fontconfig do
odpowiednich katalogów w /usr/local.
ldconfig
No i nareszcie PHP :)
PHP
# UWAGA!!!
# Poniżej należy ustawić scieżkę do katalogu, w którym zainstalowany
# jest MySQL, ponieważ w wersjach PHP do 4.3.11 domyślny klient libmysql
# jest za stary i nie obsługuje systemu autentykacji w najnowszych
# serwerach mysql (od 4.1)
./configure --with-apxs2=/usr/local/share/apache/bin/apxs
--with-mysql=/usr/local/share/mysql --with-zlib-dir=/usr/local/lib
--with-gd=/usr/local --enable-gd-native-ttf
--with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/local/lib
--with-ttf --with-freetype-dir=/usr/local/lib --enable-exif
--enable-mbstring=all --enable-mbregex
make
make install
Jeśli chcesz jeszcze obsługę SQlite, to dodatkowo:
* SQLite-Php
pear install sqlite
Następnie kopiujemy plik sqlite.so do katalogu przeznaczonego na
dodatkowe moduły (/usr/local/lib/php/extensions) i edytujemy plik
php.ini. Dopisujemy w nim linijkę
extensions=sqlite.so
pod sekcja innych extensions oraz ustawiamy odpowiednio
zmienna extensions_dir (na /usr/local/lib/php/extensions).
A tutaj daję adresy do pobrania poszczególnych źródeł:
* MySQL (http://dev.mysql.com/downloads/)
* Expat
(http://www.linuxfromscratch.org/blfs/view/stable/general/expat.html)
* Apache (http://httpd.apache.org/)
* Zlib (http://www.gzip.org/zlib/)
* GD (http://www.boutell.com/gd/)
* Jpeg-6b (http://www.ijg.org/files/)
* LibPNG (http://www.libpng.org/pub/png/libpng.html)
* Freetype (http://www.freetype.org/
http://sourceforge.net/project/showfiles.php?group_id=3157)
* Fontconfig
(http://www.linuxfromscratch.org/blfs/view/stable/general/fontconfig.html)
* PHP (http://www.php.net/downloads.php)
Uff - no to chyba wszystko.
Pozdrawiam,
Marcin Załęczny
Dominik 'Rathann' Mierzejewski
From: Lukas
> chciałem coś któregoś dnia zrobić i zaintlowałem sobie mysql5.
> przebudowałem paczke i zainstalowałem. Po przeinstlowaniu mysqla
> okazalo się że się nie da nawiązać połączenia przez php z baza. Więc
> zassałem php nowe. Ale po wykonaniu configure --with-mysql --prefix=/usr
> a potem checkinstall i zainstalowaniu paczki oraz restarcie apacha nie
> śmiga :/ Więc zabarałem się za apchache. configure --prefix=usr potem
> checkinstall i dupa nie robi paczki, kompiluje sie ladnie ale paczki nie
> robi. W sumie męczyłem się cały dzień i do niczego nie doszedłem.
Nie rozumiem, dlaczego próbowałeś instalować ze źródeł, skoro wszystko
jest w dystrybucji.
> Co chce osiągnąć:
> Chce żebym mógł przez php kożystać z mysqla
yum install php-mysql
> Konkretne pytania:
> Jak poprawnie skompilować i zaintalować apacha 2.0.55 z obsługą php?
yum install httpd php
> jak zarządzacie kodem źródłowym/wynikowym aplikacji, pakietami w
> fedorce? Rozumiem ze używacie RPM. Ale czym w takim razie robicie
> paczki? checkinstall? ręcznie? Jak?
http://fedoraproject.org/wiki/fedora-rpmdevtools
http://fedoraproject.org/wiki/PackagingGuidelines
Pozdrawiam,
R.
--
RPM repository for Fedora Core http://rpm.greysector.net/
mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
Lukas
[ciach]
> Uff - no to chyba wszystko.
>
> Pozdrawiam,
> Marcin Załęczny
W życiu nie dostałem lepszej odpowiedzi :)
Jestem ogromnie wdzięczny! Mimo moich Błentuf :P
Ale dzięki serdeczne za tak obszerne rozpisanie.
Ja to poprostu próbuje zapoanować nad tym systemem i paczkami, chciałbym
coś sam robić, a nie tylko być lajcik i korzystac z yum. Korzystam z
yum, bo i dzięki niemu sobei przywróciłem system do działania. Jednak
chciałbym troche w celach jakiś reanimacyjnych, czy krytycznych
sytuacjiach umieć zrobić sobie coś ze źródeł oraz wszytko mieć
pozapinane na ostani guzik.
Narazie gubie się w tych wszytkich źródłach i instlowaniu tego. Coprawda
wiele paczek tak instaluje i to wszytko działa. Do momentu kiedy trzeba
zainstalować jakieś kluczowe rzeczy jak apache, wtedy wszytko się
krzaczy, tj nie potrafie poprawnie zrobić paczki rpm. Generalnie wszytko
co moge to rekompiluje na i686. A przyjemnie to się robi przy pomocy
checkinstall.
Także wiem, że istnieje yum, jak i apt którego też próbowałem uzywać
kiedyś na fedorce i całkiem nieźle się sprawowoało.
Jeszcze raz dzięki za odpowiedź tak rozwlekłą. To jest pierwsza tak w
miare dokładna odpowiedź jaką dostałem kiedykolwiek na grupach :)
Pozdro
dawid gajownik
> przebudowałem paczke i zainstalowałem.
Skąd miałeś pakiet src.rpm?
> Po przeinstlowaniu mysqla okazalo się że się nie da nawiązać połączenia
> przez php z baza.
Przekompilowałeś potem php? Jeśli nie, to się nie dziw dlaczego nie
działa.
W FC-4:
[y4kk0@X ~]$ rpm -q php-mysql
php-mysql-5.0.5-2.1
[y4kk0@X ~]$ rpm -qR php-mysql | grep mysql
config(php-mysql) = 5.0.5-2.1
libmysqlclient.so.14
dla pakietu z Rawhide'a skompilowanego z mysql-5.0.18
[y4kk0@X ~]$ rpm -qpR php-mysql-5.1.2-3.i386.rpm | grep mysql
config(php-mysql) = 5.1.2-3
libmysqlclient.so.15
[y4kk0@X ~]$
Jak można wywnioskować, nowsza biblioteka z MySQL ma inne SONAME. Można
się o tym upewnić wydając polecenie:
objdump -p /usr/lib/mysql/libmysqlclient.so.NUMEREK | grep SONAME
Tak więc bez rekompilacji PHP się nie obejdzie. Nasuwa się jednak pytanie:
w jaki sposób przeinstalowałeś paczki z mysqlem? W przypadku poprawnego
użytkowania RPM, yum, itp. zostałbyś natychmiastowo poinformowany o
niespełnionych zależnościach. Przypuszczam, że użyłeś opcji `--nodeps'
albo `--force' co jest bardzo złym pomysłem.
> potem checkinstall i dupa nie robi paczki, kompiluje sie ladnie ale
> paczki nie robi. W sumie męczyłem się cały dzień i do niczego nie
> doszedłem.
Lepiej nauczyć się samemu robić pakiety. Te robione checkinstallem są
miernej jakość: brak skryptów przed/poinstalacyjnych, uzurpują
sobie przynależność standardowych katalogów jak /usr, /usr/local do
stworzonego pakietu, w złym miejscu instalują dokumentację, itd.
Wystarczy odpalić na nich rpmlint, by się o wszystkim przekonać.
> Jak poprawnie skompilować i zaintalować apacha 2.0.55 z obsługą php?
Jeśli potrzebujesz nowszej wersji (pogoń za numerkami?), to
ściągnij pakiety z Rawhide'a i je przekompiluj. Robiłem tak kiedyś z
ciekawości z httpd, mysqlem i php na FC-3 i działało.
> jak zarządzacie kodem źródłowym/wynikowym aplikacji, pakietami w fedorce?
Kodem źródłowym zarządzam przy pomocy edytora tekstu, a pakietami przy
użyciu rpm/yum ;)
> Rozumiem ze używacie RPM.
Tak.
> Ale czym w takim razie robicie paczki? checkinstall?
Nie.
> ręcznie?
Tak.
> Czy ktoś ma jakieś uwagi co do instalowania i tworzenia paczek?
Nie jest to łatwe, bo trzeba trochę wiedzieć na ten temat ;-) Czytając
recenzje pakietów na liście fedora-extras-list można się sporo dowiedzieć.
> jak zapodam pozniej checkinstall to juz nie robi paczki :/
Ułomne narzędzie i tyle :>
> jak szukać rozwiązania lub gdzie znaleść jakieś infomracje?
W googlach. Jak już nigdzie nie ma informacji na temat danego błędu, to
pytam się na jakiejś fedora-*-list.
> nie wiem jak nawet mam ugryść ten temat paczek
Dominik podał już Ci najważniejsze linki. Ja dodam jeszcze:
http://rpm.org/max-rpm-snapshot/ <- główne źródło informacji na temat
budowania pakietów.
http://dobremiasto.net/~hoppke/too_much_to_learn/rpm/index.html <- tu
należy wziąć poprawkę na to, że część rozwiązań może nie być zgodna z
zaleceniami budowania paczek w Fedorze.
Jak samemu robię jakieś pakiety, to zwykle przeglądam spece z innych
dystrybucji (www.rpmseek.com lub serwery CVS, np.
http://cvs.pld-linux.org/cgi-bin/cvsweb/ )
Patche zwykle kradnę z pakietów Debiania lub PLD ;>
> i jak szukać odpowiedzi na google.
Jeśli problem dotyczy Fedory, to w googlach dorzucam zwykle frazę
"site:redhat.com" i szybko znajduję odpowiedź.
--
http://faq.fedora.pl | http://forum.fedora.pl
http://wiki.fedora.pl/Hardware/BinarneSterowniki
http://openwengo.com/ - i Ty możesz pomóc zniszczyć niewolnego Skype'a ;)
dawid gajownik
> Umożliwia ono bezstresowe zarządzanie
> i aktualizowanie systemu, gdyż o aktualizacjach jesteś powiadamiany
> a nie jak w przypadku źródeł - sam musisz śledzić ich najnowsze wersje.
Warto tylko dodać, że czasami najnowsze wersje programów nie zawsze są
załatane. Już wiele razy widziałem, jak łata na jakiegoś babola była
dostępna w CVS-ie projektu, a zadaniem "Security Team" danej dystrybucji
było zbackportowanie tego do dostarczanych pakietów.
Jeśli ktoś nie ma czasu na czytanie list mailingowych związanych
z bezpieczeństwem i wykrytymi lukami, to lepiej niech nie zabiera się
nawet za kompilowanie własnych wersji tak ważnych programów.
W przeciwnym przypadku będzie tylko psuł statystyki GNU/Linuksa co do
ilości włamań.
> Przechodzimy do katalogu z rozpakowanymi źródłami mysql-a ./configure
Wypadałoby jeszcze ustawić zmienne CFLAGS i CXXFLAGS na takie, by
kompilować przynajmniej z `-Wp,-D_FORTIFY_SOURCE=2'
> Przed apachem musimy zainstalować Expata:
Po co, skoro jest w systemie? (to pytanie dotyczy też innych bibliotek)
> ./configure --prefix=/usr/local/share/apache --enable-shared=max
> --enable-module=most
Wersję 2.0.x trzeba jeszcze łatać, by była skompilowana jako Position
Independent Executable
http://cvs.fedora.redhat.com/viewcvs/rpms/httpd/FC-4/httpd-2.0.47-pie.patch
W przypadku 2.2.x wystarczy dodać opcję `--enable-pie'
Bez tego program będzie bardziej podatny na włamania.
> Ale zanim go instalowałem wymieniałem następujące biblioteki:
...czyli sto i jeden sposobów jak rozwalić system w drobny mak...
> * Zlib
> rpm -e zlib --nodeps
> rpm -e zlib-devel --nodeps
Używanie opcji `--nodeps' jest bardzo złym pomysłem. Przy próbie
aktualizacji programu przy użyciu yum, up2date, smartpm, itp.
wymagającego tak usuwanego RPM-a, wywalony pakiet zostanie na nowo
zainstalowany w systemie. Ze względu na kolejność standardowych ścieżek
szukania programów/bibliotek, własnoręcznie skompilowane programy mogą
przestać być widziane.
Co więcej, ręcznie skompilowana biblioteka może mieć inne SONAME, przez co
programy z dystrybucyjnych RPM-ów przestaną działać...
> ./configure --with-apxs2=/usr/local/share/apache/bin/apxs
> --with-mysql=/usr/local/share/mysql --with-zlib-dir=/usr/local/lib
> --with-gd=/usr/local --enable-gd-native-ttf
> --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/local/lib
> --with-ttf --with-freetype-dir=/usr/local/lib --enable-exif
> --enable-mbstring=all --enable-mbregex
A gdzie `--with-pic'? Bez tego otrzymana biblioteka będzie miała relokacje
w segmencie programu. Segment ten nie będzie mógł być oznaczony jako
"tylko do odczytu", więc będzie do niego można zapisywać. Ułatwia to
znacznie zhackowanie takiej aplikacji. Poza tym powoduje to też większe
zużycie RAM-u, bo dana biblioteka nie może być używana przez kilka
programów na raz (każdy proces musi załadować nową kopię).
http://thread.gmane.org/gmane.linux.gentoo.devel/33992
Ja bym jeszcze dodał `--disable-rpath'. Wymaga chyba jeszcze dodatkowego
patchowania
http://cvs.fedora.redhat.com/viewcvs/rpms/php/devel/php-5.0.4-norpath.patch
dawid gajownik
> Jednak chciałbym troche w celach jakiś reanimacyjnych, czy krytycznych
> sytuacjiach umieć zrobić sobie coś ze źródeł oraz wszytko mieć
> pozapinane na ostani guzik.
Chyba raczej rekreacyjnych :P W krytycznych sytuacjach wszystko się
instaluje z paczek. Jak coś nie działa to "downgrade'ujesz" do starszej
wersji. Jak Ci się nudzi, to zainstaluj Rawhide'a -- będzie więcej pożytku
i dla Ciebie i dla dystrybucji (o ile będziesz zgłaszał błedy).
Prawdopodobieństwo rozwalenia systemu jest znaczne większe i często coś
nie działa przez co można się wiele nauczyć.
> Narazie gubie się w tych wszytkich źródłach i instlowaniu tego.
Skoro masz problemy z takimi złożonymi programami, to zaczynaj najpierw od
czegoś prostego. Poczytaj też sobie książkę o GNU Autotools ->
http://sourceware.org/autobook/ -- pomoże Ci zrozumieć działanie
magii skryptu configure, skąd to się wszystko bierze i takie tam
(wystarczy nawet pierwsze kilkadziesiąt stron).
Marcin mzKoder Załęczny
> On Mon, 16 Jan 2006 10:47:16 +0100, Marcin mzKoder Załęczny wrote:
>
>
>
>>Umożliwia ono bezstresowe zarządzanie
>>i aktualizowanie systemu, gdyż o aktualizacjach jesteś powiadamiany
>>a nie jak w przypadku źródeł - sam musisz śledzić ich najnowsze wersje.
>
>
> Warto tylko dodać, że czasami najnowsze wersje programów nie zawsze są
> załatane. Już wiele razy widziałem, jak łata na jakiegoś babola była
> dostępna w CVS-ie projektu, a zadaniem "Security Team" danej dystrybucji
> było zbackportowanie tego do dostarczanych pakietów.
>
> Jeśli ktoś nie ma czasu na czytanie list mailingowych związanych
> z bezpieczeństwem i wykrytymi lukami, to lepiej niech nie zabiera się
> nawet za kompilowanie własnych wersji tak ważnych programów.
> W przeciwnym przypadku będzie tylko psuł statystyki GNU/Linuksa co do
> ilości włamań.
Z tym się zgadzam. Przeszedłem na tryb pakietowy właśnie z powodu braku
czasu i chęci na ciągłe śledzenie zmian i łatek we wszystkich programach
i bibliotekach, które powymieniałem. Choć muszę powiedzieć, że tak
skonstruowanego systemu używałem przez ok. 1,5 roku i nie miałem (na
szęście) żadnego włamania. Oto lista pakietów, które zastąpiłem swoimi:
* Kernel (http://www.kernel.org)
* Iptables (http://www.netfilter.org/)
* Zlib (http://www.gzip.org/zlib/)
* Expat
(http://www.linuxfromscratch.org/blfs/view/stable/general/expat.html)
* PCRE (http://sourceforge.net/projects/pcre/)
* Bind (http://www.isc.org/index.pl?/sw/bind/)
* MySQL (http://dev.mysql.com/downloads/)
* Apache (http://httpd.apache.org/) (Zaleznosci: Expat)
* SQLite3 (http://www.hwaci.com/sw/sqlite/)
* Freetype (http://www.freetype.org/
http://sourceforge.net/project/showfiles.php?group_id=3157)
* Fontconfig
(http://www.linuxfromscratch.org/blfs/view/stable/general/fontconfig.html)
* LibPNG (http://www.libpng.org/pub/png/libpng.html)
* Jpeg-6b (http://www.ijg.org/files/)
* GD (http://www.boutell.com/gd/)
* PHP (http://www.php.net/downloads.php)
* Sqlite-Php (http://sf.net/projects/sqlite-php/)
* ZendOptimizer(http://www.zend.com/store/products/zend-optimizer.php)
* Gateway (http://www.kannel.org/)
* Squid (http://www.squid-cache.org/)
* vsftp (http://vsftpd.beasts.org/)
* Cyrus SASL (ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/)
* Postfix (http://www.postfix.org/)
* Msmtp (http://msmtp.sourceforge.net/)
* Netcat (http://netcat.sourceforge.net/)
* OSSP libmm (http://www.ossp.org/pkg/lib/mm/)
* ttcp
* LCMS
(http://sourceforge.net/project/showfiles.php?group_id=26279&package_id=17828)
Potrzebny dla ImageMagicka
* ImageMagick (http://sourceforge.net/project/showfiles.php?group_id=24099)
* AWStats (http://awstats.sourceforge.net/#DOWNLOAD)
* Python (http://www.python.org/)
>
>>Przechodzimy do katalogu z rozpakowanymi źródłami mysql-a ./configure
>
>
> Wypadałoby jeszcze ustawić zmienne CFLAGS i CXXFLAGS na takie, by
> kompilować przynajmniej z `-Wp,-D_FORTIFY_SOURCE=2'
Wiem, że wiesz co piszesz i przy następnej kompilacji zapewne użyłbym
tych ustawień. Jednak odpowiedź, że coś wypadałoby zrobić (szczególnie
w kwestiach technicznych) mnie nie satysfakcjonuje.
>
>
>>Przed apachem musimy zainstalować Expata:
>
>
> Po co, skoro jest w systemie? (to pytanie dotyczy też innych bibliotek)
Otóż nie. Wcześniej część z nich wywaliłem (rpm -e --nodeps) a części
nie było (instalowałem wersję minimalną).
>
>
>>./configure --prefix=/usr/local/share/apache --enable-shared=max
>>--enable-module=most
>
>
> Wersję 2.0.x trzeba jeszcze łatać, by była skompilowana jako Position
> Independent Executable
> http://cvs.fedora.redhat.com/viewcvs/rpms/httpd/FC-4/httpd-2.0.47-pie.patch
> W przypadku 2.2.x wystarczy dodać opcję `--enable-pie'
>
> Bez tego program będzie bardziej podatny na włamania.
Dzięki za info uaktualniam swoje opisy :)
>
>
>>Ale zanim go instalowałem wymieniałem następujące biblioteki:
>
>
> ...czyli sto i jeden sposobów jak rozwalić system w drobny mak...
Zapewne. Ale mnie przetrwał przez 1,5 roku. Wymieniłem go jednak
właśnie z chęci uzyskania bezpieczniejszego systemu.
>
>
>>* Zlib
>>rpm -e zlib --nodeps
>>rpm -e zlib-devel --nodeps
Tu uwaga z zlibem jest taki problem, że jak go wywalimy, to rpm
przestaje działać. Więc jak z jakiegoś powodu nie uda nam się
go skompilować (w ekstremalnym przypadku - brak gcc ;D) i zainsta-
lować, to później trzeba bootować z płyty i go przywrócić. Następnie
zainstalować to co potrzebne i znowu spróbować go zastąpić.
>
>
> Używanie opcji `--nodeps' jest bardzo złym pomysłem. Przy próbie
> aktualizacji programu przy użyciu yum, up2date, smartpm, itp.
> wymagającego tak usuwanego RPM-a, wywalony pakiet zostanie na nowo
> zainstalowany w systemie. Ze względu na kolejność standardowych ścieżek
> szukania programów/bibliotek, własnoręcznie skompilowane programy mogą
> przestać być widziane.
Wszystko się zgadza. Ale wtedy jeszcze nie używałem yum-a ani up2date.
>
> Co więcej, ręcznie skompilowana biblioteka może mieć inne SONAME, przez co
> programy z dystrybucyjnych RPM-ów przestaną działać...
Dla tych programów i bibliotek, które były mi potrzebne nie miałem
żadnych problemów.
>
>
>>./configure --with-apxs2=/usr/local/share/apache/bin/apxs
>> --with-mysql=/usr/local/share/mysql --with-zlib-dir=/usr/local/lib
>> --with-gd=/usr/local --enable-gd-native-ttf
>> --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/local/lib
>> --with-ttf --with-freetype-dir=/usr/local/lib --enable-exif
>> --enable-mbstring=all --enable-mbregex
>
>
> A gdzie `--with-pic'? Bez tego otrzymana biblioteka będzie miała relokacje
> w segmencie programu. Segment ten nie będzie mógł być oznaczony jako
> "tylko do odczytu", więc będzie do niego można zapisywać. Ułatwia to
> znacznie zhackowanie takiej aplikacji. Poza tym powoduje to też większe
> zużycie RAM-u, bo dana biblioteka nie może być używana przez kilka
> programów na raz (każdy proces musi załadować nową kopię).
>
> http://thread.gmane.org/gmane.linux.gentoo.devel/33992
Już uaktualniam opisy. Wiem czym i dlaczego :)
>
> Ja bym jeszcze dodał `--disable-rpath'. Wymaga chyba jeszcze dodatkowego
> patchowania
> http://cvs.fedora.redhat.com/viewcvs/rpms/php/devel/php-5.0.4-norpath.patch
>
Rozumiem oczywiście, że te wszystkie dodatkowe opcje służą podniesieniu
bezpieczeństwa tworzonych binarek. Ale po przeczytaniu tego tekstu oraz
kilku początkowych postów z podanego adresu wciąż nie wiem co mi daje:
-Wp
-D_FORTIFY_SOURCE=2
--disable-rpath
Nie siedzę w tym temacie, więc nie jest to dla mnie oczywiste. Swoje
programy kompiluję własnymi makefilami, które zawierają polecenia
w stylu:
gcc/g++ -c fname.cpp -o fname
z ewentualnym dodaniem scieżek inkludowych, librarowych i samych
bibliotek. I wszystko mi działa, tak jak chcę. Ale od dzisiaj będę
tworzył bezpieczniejsze binarki :)
Pozdrawiam,
Marcin Załęczny
dawid gajownik
>> Wypadałoby jeszcze ustawić zmienne CFLAGS i CXXFLAGS na takie, by
>> kompilować przynajmniej z `-Wp,-D_FORTIFY_SOURCE=2'
>
> Wiem, że wiesz co piszesz i przy następnej kompilacji zapewne użyłbym
> tych ustawień. Jednak odpowiedź, że coś wypadałoby zrobić (szczególnie
> w kwestiach technicznych) mnie nie satysfakcjonuje.
export CFLAGS="nasze flagi"
Podobnie dla CXXFLAGS. Najlepiej wszystko wrzucić do jakiegoś pliku w
etc/profile.d (np. moje_ustawienia.sh). Standardowo skompilowany program
bez zmienionych flag kompilotara będzie wolniejszy od tych z pakietów.
rpm --eval %{optflags}
W FC-5 na platformie i386 ustawiane są one na '-O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4
-fasynchronous-unwind-tables'
> Otóż nie. Wcześniej część z nich wywaliłem (rpm -e --nodeps) a części
> nie było (instalowałem wersję minimalną).
Niepotrzebne dodawanie sobie roboty ;) Wszystkie pakiety są na płytkach. A
za używanie `--nodeps' powinni palce obcinać ]:->
>> ...czyli sto i jeden sposobów jak rozwalić system w drobny mak...
>
> Zapewne. Ale mnie przetrwał przez 1,5 roku. Wymieniłem go jednak
> właśnie z chęci uzyskania bezpieczniejszego systemu.
Hmm... Aktualizowałeś resztę programów, czy tylko te wymienione na
początku?
> Tu uwaga z zlibem jest taki problem, że jak go wywalimy, to rpm
> przestaje działać.
:)
> Już uaktualniam opisy. Wiem czym i dlaczego :)
Proponuję jeszcze przejrzeć pliki spec z php, mysql-a i httpd. Jest tam
wiele ciekawych opcji, a changelogi też stanowią pewną dozę informacji.
> Rozumiem oczywiście, że te wszystkie dodatkowe opcje służą podniesieniu
> bezpieczeństwa tworzonych binarek.
Tak.
> -Wp
Dodanie opcji do preprocesora:
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Preprocessor-Options.html
> -D_FORTIFY_SOURCE=2
http://www.redhat.com/magazine/009jul05/features/execshield/#checks
> --disable-rpath
http://people.debian.org/~che/personal/rpath-considered-harmful
> Swoje programy kompiluję własnymi makefilami, które zawierają polecenia w
> stylu:
> gcc/g++ -c fname.cpp -o fname
Trochę mało ;-) Ja bym tam dorzucił najlepiej $CFLAGS lub $CXXFLAGS w
zależności czy to jest kompilowane przez gcc czy g++. Poza tym `-Wall' to
minimum, by móc pisać programy z małą ilością błędów.
Marcin mzKoder Załęczny
> On Wed, 18 Jan 2006 00:02:55 +0100, Marcin mzKoder Załęczny wrote:
>
>
>
>>>Wypadałoby jeszcze ustawić zmienne CFLAGS i CXXFLAGS na takie, by
>>>kompilować przynajmniej z `-Wp,-D_FORTIFY_SOURCE=2'
>>
>>Wiem, że wiesz co piszesz i przy następnej kompilacji zapewne użyłbym
>>tych ustawień. Jednak odpowiedź, że coś wypadałoby zrobić (szczególnie
>>w kwestiach technicznych) mnie nie satysfakcjonuje.
>
>
> export CFLAGS="nasze flagi"
>
> Podobnie dla CXXFLAGS. Najlepiej wszystko wrzucić do jakiegoś pliku w
> etc/profile.d (np. moje_ustawienia.sh). Standardowo skompilowany program
> bez zmienionych flag kompilotara będzie wolniejszy od tych z pakietów.
>
> rpm --eval %{optflags}
>
> W FC-5 na platformie i386 ustawiane są one na '-O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4
> -fasynchronous-unwind-tables'
>
zastanawiałem się jak w prosty sposób wyświetlić wartość jakiejś
zmiennej rpm-a. Opcji --eval ani w manualu ani w dokumencie HOWTO
na http://www.rpm.org/ nie znalazłem. Przed chwilą jednak rzuciłem
okiem po sieci i znalazłem na
http://fedora.redhat.com/docs/drafts/rpm-guide-en/ch-command-reference.html
:) (ale teraz wiedziałem czego szukać).
>
>>Otóż nie. Wcześniej część z nich wywaliłem (rpm -e --nodeps) a części
>>nie było (instalowałem wersję minimalną).
>
>
> Niepotrzebne dodawanie sobie roboty ;) Wszystkie pakiety są na płytkach. A
> za używanie `--nodeps' powinni palce obcinać ]:->
Zgadza się :). Ale przy tej okazji chciałbym o jeszcze jedną rzecz
zapytać. Jakiś czas temu wpadłem na genialny pomysł postawienia sobie
mniejszej fedory niż ta w wersji minimalnej. Wystartowałem w trybie
rescue, sformatowałem partycje, podmontowałem odpowiednio cdrom,
chrootowałem się na / przyszłego systemu i zacząłem przy pomocy
rpm-a instalację kolejnych paczuszek zaczynając oczywiście od tych
podstawowych. I tu pojawiły się problemy, bo po kilku może kilkunastu
pakietach okazało się, że powstały rekursywne zależności, tzn. musiałem
zainstalować pakiet a.rpm. Żeby to jednak zrobić rpm krzyczał o pakiet
b.rpm. Gdy zaś chciałem zainstalować b.rpm, to żądał wcześniejszej
instalacji pakietu a.rpm. W takiej sytuacji więc chyba nie da się nie
użyć opcji --nodeps lub --force. Ale może jest jakieś inne rozwiązanie
(przy użyciu tylko i wyłącznie rpm-a), instalacji takich pakietów.
>
>>>...czyli sto i jeden sposobów jak rozwalić system w drobny mak...
>>
>>Zapewne. Ale mnie przetrwał przez 1,5 roku. Wymieniłem go jednak
>>właśnie z chęci uzyskania bezpieczniejszego systemu.
>
>
> Hmm... Aktualizowałeś resztę programów, czy tylko te wymienione na
> początku?
>
>
Tylko te, które wymieniłem. Ale na serwerze był dostęp tylko do
http, ftp, dns, więc problemów nie miałem. Zdaję sobie sprawę, że
gdybym dał dostęp do shella, to od razu ktoś by mi rozniósł system ;)
>>Tu uwaga z zlibem jest taki problem, że jak go wywalimy, to rpm
>>przestaje działać.
>
>
> :)
>
>
>>Już uaktualniam opisy. Wiem czym i dlaczego :)
>
>
> Proponuję jeszcze przejrzeć pliki spec z php, mysql-a i httpd. Jest tam
> wiele ciekawych opcji, a changelogi też stanowią pewną dozę informacji.
>
Na pewno to zrobię. Swoją drogą powoli przymierzam się do tematu
tworzenia paczuszek, ale na razie wciąż jeszcze poznaję ten system
(Fedorę oczywiście :). Na linuksa prawie całkowicie przerzuciłem się
od ok. miesiąca (wcześniej trochę nim administrowałem). To w nim
głównie teraz pracuję i na pozostałych domowych desktopach również
zagościł jako wyłączny system. Działa wszystko co potrzeba: kadu, skype,
filmy, mp3/ogg, drukowanie (ze skanowaniem mam jeszcze problemy ale
pewnie wkrótce znikną). Czego chcieć więcej :) ?
Nie bez znaczenia dla mnie jest też fakt pojawienia się mono i możliwo-
ści łatwiejszego tworzenia wieloplatformowych aplikacji.
>
>>Rozumiem oczywiście, że te wszystkie dodatkowe opcje służą podniesieniu
>>bezpieczeństwa tworzonych binarek.
>
>
> Tak.
>
>
>>-Wp
>
>
> Dodanie opcji do preprocesora:
> http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Preprocessor-Options.html
>
>
>>-D_FORTIFY_SOURCE=2
>
>
> http://www.redhat.com/magazine/009jul05/features/execshield/#checks
>
>
>>--disable-rpath
>
>
> http://people.debian.org/~che/personal/rpath-considered-harmful
>
>
Dzięki za linki w najbliższym czasie bliżej się im przyjrzę.
>>Swoje programy kompiluję własnymi makefilami, które zawierają polecenia w
>>stylu:
>>gcc/g++ -c fname.cpp -o fname
>
>
> Trochę mało ;-) Ja bym tam dorzucił najlepiej $CFLAGS lub $CXXFLAGS w
> zależności czy to jest kompilowane przez gcc czy g++. Poza tym `-Wall' to
> minimum, by móc pisać programy z małą ilością błędów.
>
Tak też zrobię - wykorzystam sposób, który podałeś wyżej i same makefile
mi się nie zmienią :) Są to rzeczy, które kompiluję na własne potrzeby
(ewentualnie najbliższych znajomych) i tworzenie jakichś super działają-
cych skryptów configure nie jest mi potrzebne.
Pozdrawiam,
Marcin Załęczny
dawid gajownik
> Jakiś czas temu wpadłem na genialny pomysł postawienia sobie mniejszej
> fedory niż ta w wersji minimalnej. Wystartowałem w trybie rescue,
> sformatowałem partycje, podmontowałem odpowiednio cdrom, chrootowałem
> się na / przyszłego systemu i zacząłem przy pomocy rpm-a instalację
> kolejnych paczuszek zaczynając oczywiście od tych podstawowych.
Ja instalowałem minimalny system przy pomocy yuma ->
http://fedoraproject.org/wiki/FedoraXenQuickstart#head-d8c5e7b0f9f95e248fbcb12e26f2e9c3b33f3dbc
Trochę ten opis pozmieniałem:
- nie instalowałem w obrazie partycji tylko od razu na do katalogu z
podmontowaną partycją
- w yum.conf zmieniłem ścieżki, by wskazywały na Rawhide'a
- podmontowałem tymczasowo /dev w katalogu docelowym
- IIRC nie montowałem tam /proc, bo za dużo skryptów poinstalacyjnych się
wysypywało.
Był tylko mały problem -- część skryptów poinstalacyjnych i tak sie
nie uruchamiała. Trzeba je było potem odpalać ręcznie (można je zobaczyć
komendą: rpm -q --scripts nawza_pakiety) albo na nowo przeinstalować dane
RPM-y.
Zamiast "groupinstall Base" możesz dać "groupinstall Core" (powinno
zainstalować mniej programów).
Zawsze też można robić w druga stronę - zainstalować wersję "minimalną", a
potem usuwać niepotrzebne programy. Można je wyświetlić poleceniem:
package-cleanup --leaves --all
(program z pakietu yum-utils)
Problem wielkości minimalnej instalacji wraca co jakiś czas na
fedora-devel-list jak bumerang :) Zwykle pada mnie więcej taka odpowiedź
->
http://www.redhat.com/archives/rhl-devel-list/2005-January/msg00478.html
Brakuje osób, które chciałyby zająć się tym problemem :/
> I tu pojawiły się problemy, bo po kilku może kilkunastu pakietach
> okazało się, że powstały rekursywne zależności, tzn. musiałem
> zainstalować pakiet a.rpm. Żeby to jednak zrobić rpm krzyczał o pakiet
> b.rpm. Gdy zaś chciałem zainstalować b.rpm, to żądał wcześniejszej
> instalacji pakietu a.rpm. W takiej sytuacji więc chyba nie da się nie
> użyć opcji --nodeps lub --force.
Instalować oba pakiety naraz? ;)
Opcje `--nodeps' czy `--force' oczywiście mają jakieś zastosowanie.
Przykładowo jak sprawdzałem zależności programu gajim, to chciałem się
upewnić czy naprawdę wymaga on pygtk2-libglade. Bez opcji `--nodeps'
musiałbym wywalić za dużo programów z systemu. Potem wszystko i
tak naprawiłem. Oczywiście przedtem sprawdziłem przy użyciu `rpm -e
--test' co wymaga tego programu i czy przypadkiem nie rozwalę systemu.
Wywalenie przez przypadek popt, glibc czy zlib może się źle skończyć ;]
Problem w tymi opcjami jest taki, że w 99.9% przypadków
używane są one w zły sposób i dlatego zawsze będę odradzał ich używania.
>> Hmm... Aktualizowałeś resztę programów, czy tylko te wymienione na
>> początku?
>>
>>
> Tylko te, które wymieniłem.
Hehe, więc dlatego nic się nie posypało :)
> Ale na serwerze był dostęp tylko do http, ftp, dns, więc problemów nie
> miałem.
Ja bym jeszcze przynajmniej zadbał o openssl. Tutaj jednak trzeba uważać,
bo deweloperzy tej biblioteki w ogóle nie dbają o stabilne ABI i z nowszą
wersją muszą ciągle zmieniać SONAME. Jedynym rozwiązaniem zostaje
backportowanie patchy, bo w przeciwnym wypadku trzeba by rekompilować
połowę systemu.
> Czego chcieć więcej :) ?
Przeportowanych sterowników nVidii z BeOS-a ;)
https://bugs.freedesktop.org/show_bug.cgi?id=5190
>> Trochę mało ;-) Ja bym tam dorzucił najlepiej $CFLAGS lub $CXXFLAGS w
Ech, tak to jest jak się pisze w nocy... Chciałem napisać $(CFLAGS) i
$(CXXFLAGS).
> Tak też zrobię - wykorzystam sposób, który podałeś wyżej i same makefile
> mi się nie zmienią :)
Właściwie to możesz to wszystko jeszcze bardziej zautomatyzować. Zamiast
podawać nazwy plików wystarczy podać coś takiego:
%.o: %.c
$(CC) $(CFLAGS) -c $<
http://www.eikke.com/articles/writing-makefiles-autotools.html
Marcin mzKoder Załęczny
Dzięki za dobre info :) Na prawdę interesujący artykuł. Jak tylko będę
miał trochę czasu, to poeksperymentuję. Wcześniej zapomniałem napisać,
że przy swojej minimalnej instalacji ostatecznie wymiękłem przy tych
zależnościach i ostatecznie zainstalowałem system Anacondą (nie znałem
wtedy jeszcze yum-a).
>
>>I tu pojawiły się problemy, bo po kilku może kilkunastu pakietach
>>okazało się, że powstały rekursywne zależności, tzn. musiałem
>>zainstalować pakiet a.rpm. Żeby to jednak zrobić rpm krzyczał o pakiet
>>b.rpm. Gdy zaś chciałem zainstalować b.rpm, to żądał wcześniejszej
>>instalacji pakietu a.rpm. W takiej sytuacji więc chyba nie da się nie
>>użyć opcji --nodeps lub --force.
>
>
> Instalować oba pakiety naraz? ;)
Wtedy nie wpadłem na to że jest taka możliwość. Czasem człowiek się
czymś głupim zasugeruje i ma klapki na oczach ;)
>>>Hmm... Aktualizowałeś resztę programów, czy tylko te wymienione na
>>>początku?
>>>
>>>
>>
>>Tylko te, które wymieniłem.
>
>
> Hehe, więc dlatego nic się nie posypało :)
:)
>
>>Ale na serwerze był dostęp tylko do http, ftp, dns, więc problemów nie
>>miałem.
>
>
> Ja bym jeszcze przynajmniej zadbał o openssl. Tutaj jednak trzeba uważać,
> bo deweloperzy tej biblioteki w ogóle nie dbają o stabilne ABI i z nowszą
> wersją muszą ciągle zmieniać SONAME. Jedynym rozwiązaniem zostaje
> backportowanie patchy, bo w przeciwnym wypadku trzeba by rekompilować
> połowę systemu.
Próbowałem... Ale po podmianie OpenSSL-a na swojego przestało działać mi
kopiowanie plików przez scp. Dlatego wróciłem do oryginalnego z dystry-
bucji.
>
>>>Trochę mało ;-) Ja bym tam dorzucił najlepiej $CFLAGS lub $CXXFLAGS w
>
>
> Ech, tak to jest jak się pisze w nocy... Chciałem napisać $(CFLAGS) i
> $(CXXFLAGS).
>
Masz rację. Myślałem, że zmienne środowiskowe $CFLAGS i $CXXFLAGS są
automatycznie dodawane do opcji kompilacji w makefile'u. Ale przed
chwilą sprawdziłem i tak nie jest. Trzeba jawnie je podawać jako
$(CFLAGS) i $(CXXFLAGS).
>
>>Tak też zrobię - wykorzystam sposób, który podałeś wyżej i same makefile
>>mi się nie zmienią :)
>
Uwzględniając powyższe doświadczenie, to jednak mie się one zmienią:
muszę dodawać $(CFLAGS) i $(CXXFLAGS) do kompilacji.
>
> Właściwie to możesz to wszystko jeszcze bardziej zautomatyzować. Zamiast
> podawać nazwy plików wystarczy podać coś takiego:
>
> %.o: %.c
> $(CC) $(CFLAGS) -c $<
>
> http://www.eikke.com/articles/writing-makefiles-autotools.html
>
Zgadza się, ale to nie zadziała w każdym przypadku, bo niektóre pliki
*.o zależą od kilku innych plików *.o oraz *.h.
Pozdrawiam,
Marcin Załęczny