Archiwum miesiąca: wrzesień 2008

Firebird i Reiserfs

bazy danych, linux, , , , , ,

Głównymi bohaterami są Firebird 1.5 oraz system plików reiserfs 3.6 .

Baza danych jest pojedynczym (jak to zwykle przy firebirdzie bywa ;) ) plikiem o wielkości od 1 GB do ~5 GB. Podaje taki przedział ponieważ obserwacji dokonywałem na wielu serwerach dla baz o różnej wielkości. Partycja jest zwykle o wielkości ~15-20 GB czyli jest znacznie większa od wielkości pliku.

Sposób pracy na bazie jest klasyczny, czyli dane są dokładane i to w dosyć sporej ilości.

W efekcie już po kilku tygodniach takiej pracy, plik bazodanowej jest bardzo mocno sfragmentowany. Filefrag zgłasza od kilkudziesięciu do nawet 200-300 tysięcy „extentsów”.

W ramach testów przeszedłem na XFS, efekt? Po kilku tygodniach pracy fragmentacja dla pliku ~2GB wynosi: 3 extents. Różnica jest olbrzymia.

Planuję obserwować jak będzie to zachowywać się na EXT3 w ramach alternatywy dla XFSa. I należałoby dać chyba jeszcze szansę reiserowi i zamontować go z opcją „notail”, być może to będzie miało pozytywny wpływ.

Epilog:

Po 3 tygodniach obserwacji, baza na XFS nadal jest w 3 częściach.

Baza umieszczona na Reiserfs zamontowanego z opcją notail, po kilku dniach zwiększyła ilość swoich kawałków z ponad dwóch tysięcy do ponad czterech tysięcy.

Exim i aliasy z bazy postgresowej

konfiguracja usług, linux, , ,

Aliasy trzymam w bardzo prostej tabelce:

CREATE TABLE aliasy
(
id serial NOT NULL,
alias text NOT NULL DEFAULT ”::text,
destination text NOT NULL DEFAULT ”::text,
CONSTRAINT aliasy_pkey PRIMARY KEY (id)
);

CREATE UNIQUE INDEX ind_alias
ON aliasy
USING btree
(alias);

CREATE TRIGGER cleanup_aliases
BEFORE INSERT OR UPDATE
ON aliasy
FOR EACH ROW
EXECUTE PROCEDURE cleanup_aliases();

CREATE OR REPLACE FUNCTION cleanup_aliases()
RETURNS „trigger” AS
$BODY$
DECLARE
BEGIN
NEW.alias := trim(both FROM lower(NEW.alias));
NEW.destination := trim(both FROM lower(NEW.destination));
RETURN NEW;
END;
$BODY$
LANGUAGE 'plpgsql’ VOLATILE;

Do tego jest trigger mający na celu zapisać w bazie dane małymi literami z obciętymi spacjami na początku oraz końcu. Ten trigger jest zapożyczony z blogu depesza.

Sam ruter w eximie wygląda następująco:

aliasy_postgres:
driver = redirect
allow_fail
allow_defer
data = ${lookup pgsql{ SELECT destination FROM aliasy where alias = (’${quote_pgsql:$local_part}@${quote_pgsql:$domain}’) }}

Exim + postgresql

konfiguracja usług, , , , ,

Nadeszła chwila, kiedy to unixowe konta nie wystarczają do obsługi poczty. Witajcie wirtualni userzy.

Dlaczego postgres? Ponieważ bardzo nie lubię mysqla.

Podczas migracji korzystałem z różnych opisów dostępnych w sieci, wiele informacji (oraz trigerów :)  ) zaczerpnąłem ze strony depesza oraz ze strony Baseciqa . Okazało się jednak, że w powyższych opisach,  oraz w wielu innych jakie google podsuwały, brakowało kilku kluczowych elementów aby exim działał tak jak powinien działać serwer pocztowy. Tym „drobiazgiem” była przede wszystkim nieomówiona autoryzacja użytkowników wysyłających pocztę. Silnie podpierając się stroną ( http://devel.reinikainen.net/attachments/Exim/configure ) uruchomiłem możliwość wysyłania poczty wirtualnym użytkownikom.

Uff, następuje pierwsza próba wysłania maila. I zonk. Okazuje się, że exim dokleja swój primary hostname do adresu mailowego nadawcy. Czyli miałem nadawce takiego:

„user@wirtualna.domena.tld@moj.komputer.tld”

Tutaj wszystko zamykało się w jednej linijce:

control       = submission/sender_retain

Kolejna próba.. I? Pełny sukces! Zadziałało!

Kolejnym etapem będzie uruchomienie aliasów.