After installing OpenERP (using script from OpenERP forum) I couldn't get any "Apps". The solution was quite simple, but very hard to find.
Yo have to set up (in console) two environment variables: http_proxy and https_proxy and restart server
http_proxy=192.168.1.1:3128 https_proxy=192.168.1.1:3128 /etc/init.d/openerp restart
As You can see my proxy server uses default port 3128 and is on my gateway 191.168.1.1.
Next I've started to create "parts" using my own numbering scheme based on categories founded on credativ Blog because the main purpose was to take control of my electronics parts.
Wcześniej opisałem jak się pozbyć komunikatu
lmtpunix[1000]: IOERROR: fstating sieve script /var/lib/imap/sieve/u/user/defaultbc: No such file or directory
za pomocą RoundCubeMail z odpowiednią wtyczką. Jednak to rozwiązanie jest dla pojedynczych użytkowników. Rozwiązanie globalne jest następujące.
Trzeba przygotować zwykły plik tekstowy z zawartością np.:
/* empty script */
ważne, żeby był poprawnym skryptem Sieve. Niech się nazywa pusty.sieve. Następnie uruchamiamy konsolę, tu z domyślnym użytkownikiem cyrus:
sieveshell -u cyrus -a cyrus localhost
i wydajemy polecenie załadowania skryptu na serwer oraz ustawiamy go aktywnym:
> put pusty.sieve globalny > activate globalny
dla pewności można to sprawdzić:
> list globalny <- active script
teraz można już wyjść z powłoki (poleceniem quit).
Wykonane zmiany widać również w systemie plikowym:
# ls -l /var/lib/imap/sieve/global/ total 8 lrwxrwxrwx 1 cyrus mail 11 Apr 14 2013 defaultbc -> globalny.bc -rw------- 1 cyrus mail 20 Apr 14 2013 globalny.bc -rw------- 1 cyrus mail 18 Apr 14 2013 globalny.script
Oczywiście nic nie stoi na przeszkodzie, żeby globalny plik nie był pusty, tylko wykonywał jakąś akcję.
Trzeba także zapewnić wpis w /etc/cyrus.conf w sekcji SERVICES wyglądający jakoś tak:
sieve cmd="timsieved" listen="sieve" prefork=0
czy działa najłatwiej sprawdzić sprawdzając czy cyrus-master słucha na porcie 4190:
# netstat -ntlp | grep 4190 tcp 0 0 0.0.0.0:4190 0.0.0.0:* LISTEN 1443/cyrus-master
jak widać u mnie słucha.
Po tym jak dorobiłem przycisk spam do Roundcube'a mogłem się łatwo pozbywać niechcianej poczty, ale ona cały czas zalegała w katalogu Junk. Przydało by się, żeby spam był kasowany po pewnym czasie. Do tego służy polecenie cyr_expire i parametr expire.
Najpierw sprawdziłem stan aktualny. Wydałem więc polecenie:
localhost> info user/jaqb/Junk {user/jaqb/Junk}: condstore: false duplicatedeliver: false lastpop: lastupdate: 14-Oct-2013 21:29:32 +0200 partition: default pop3newuidl: true sharedseen: false size: 3451803
teraz ustawiam kasowanie na 60 dni
localhost> mboxcfg user/jaqb/Junk expire 60
jak widać poniżej pojawił się nowy parametr
localhost> info user/jaqb/Junk {user/jaqb/Junk}: condstore: false duplicatedeliver: false expire: 60 lastpop: lastupdate: 14-Oct-2013 21:29:32 +0200 partition: default pop3newuidl: true sharedseen: false size: 3451803
teraz trzeba sprawdzić, czy w pliku /etc/cyrus.conf jest wpis:
delprune cmd="cyr_expire -E 3" at=0400
oczywiście można zmienić godzinę z 4:00 na jakąś inną.
Nowy dzień przywitał mnie oczyszczoną skrzynką.
SQUAT jest to system indeksowania poczty by wyszukiwanie wiadomości trwało szybciej - w sumie fajna sprawa, ale...
Serwer poczty oparty na Cyrus IMAP po zainstalowaniu krzyczał w logu, że:
SQUAT failed to open index file SQUAT failed
naprawienie tego jest dość proste w pliku /etc/cyrus.conf w sekcji EVENTS dopisujemy dwie linijki:
squat cmd="squatter -r *" period=60 squat cmd="squatter -r *@*" period=60
które mówią, żeby serwer co 60 min poleceniem squatter przebudował indeksy.
Przy większych systemach trzeba by pewnie pomyśleć o wydajności i użyć przełączników -s lub/i -i.
Tak jak obiecałem w opisie ustawiania ograniczeń teraz pokażę jak zdjąć limit ze skrzynki.
Kasowanie wygląda podobnie jak zmiana wielkości tyle, że ustawiamy rozmiar kwoty na wartość none:
cyradm -user cyrus localhost localhost> listquota user/jaqb STORAGE 37094/40960 (90.5615234375%) localhost> setquota user/jaqb none remove quota localhost> listquota user/jaqb / localhost> quit
Jak widać ograniczenie zniknęło.
Miałem ciekawy przypadek błędu w repozytorium. Od razu powiem, że bez kopi zapasowej nie udało by mi się go rozwiązać.
Kopia robocza na jednym komputerze - wszystko działa (latami). Po jakimś czasie zachciało mi się (akurat - po prostu musiałem) w nim grzebnąć, ale już na nowym sprzęcie i ... klops. Okazało się, że repozytorium jest uszkodzone, co gorsza, jak się później okazało, już na wersji 2 (błąd dysku ???).
Komunikaty błędu miałem różne. Komenda svn pokazywała:
svn: REPORT of '/svnprv/reponame/!svn/vcc/default': Could not read \ chunk size: connection was closed by server (http://localhost)
w error_log apache'a było:
[error] [client 127.0.0.1] Provider encountered an error while \ streaming a REPORT response. [500, #0] [error] [client 127.0.0.1] A failure occurred while driving \ the update report editor [500, #160004]
a polecenie svnadmin verify reponame zwracało:
svnadmin: Checksum mismatch while reading representation: expected: 10b6f87d95a8283b4dc96607a662c4de actual: 1865015a5837bc21ea73397ee68e1c44
Po przejrzeniu backup'ów (makaronizm, ale "kopia zapasowa" jest taka długa...) znalazłem taki który miał poprawnie zapisaną wersję drugą - z przed 2 lat! W ten sposób posunąłem się o 400% (z wersji 1 do 4 ;-) do pełni szczęścia trochę brakuje...
Niby coś-tam działało, bo WebSVN ładnie pokazywał historie i doszedłem do tego, że mogę ściągać diff'y między różnymi wersjami, np.:
svn di http://localhost/svn/reponame@7 \ http://localhost/svn/reponame@15
W ten sposób dowiedziałem się, że tylko wersja 2 jest uszkodzona. Niestety próby odzyskania reszty danych z bieżącego repozytorium nie dawały pozytywnych rezultatów (testowałem na różnych wersjach):
svnadmin dump -r3 reponame svnadmin: Checksum mismatch while reading representation: expected: 959148e046aafa5f51db215c9ee0796d actual: 98824bfc23034f920d603d42a0810843
Oczywiście działało dla wersji 0 i 1. Kluczem okazał się przełącznik --incremental !
svnadmin dump -r3 --incremental reponame * Dumped revision 3.
Teraz już poszło gładko. Trzeba założyć nowe repozytorium i załadować do niego dane z kopii (była spakowana bzip2):
svnadmin create reponame-new bzcat reponame-2011-09-25.dump.bz2 | svnadmin load reponame-new ... ------- Committed revision 4 >>>
ustalić numer ostatniej wersji, powiedzmy 45 (żeby nie było równo) i wtedy (jak widać wersję 4 już miałem):
for x in `seq 5 45` ; do svnadmin dump --incremental -r $x reponame \ | svnadmin load reponame-new; done
... no trochę to trwało, ale za to pełen sukces.
Teraz wystarczy skasować stare i zmienić nazwę "nowego":
rm -rf reponam mv reponame-new reponame
Ładowane dane były do pustego repozytorium, więc UUID się nie zmienił.
Teraz trzeba poprawić skrypt, żeby po pierwsze wychwytywał błędy przy robieniu zrzutu (dump) i może dodatkowo wykonywał jeszcze zrzut ostatnich np. 10 wersji...
Pewnego pięknego dnia okazało się, że moje konto (założone jak każde inne) też ma nałożone ograniczenia rozmiaru skrzynki (btw. to skandal, żeby nakładać ograniczenia na admina. Co innego użytkownikom, ale dla admina ?)
Nie było innego wyjścia jak zwiększyć (docelowo zdjąć) sobie limit. Uruchomiłem konsolę cyradm. Trzeba to zrobić jako użytkownik cyrus (który jest definiowany w /etc/imapd.conf jako admin), bo nie potrafiłem ustawić quota na własnym koncie. Wcześniej oczywiście ustawiłem mu hasło. Wyglądało to tak:
cyradm -user cyrus localhost
teraz można sobie wypisać konta:
localhost> listmailbox user/%
jak to nie zadziała (konta są zakładane wg innej konwencji) to można spróbować:
listmailbox *
teraz najważniejsze sprawdzenie ustawienia bieżącego, ustawienie nowej wartości i ponowne sprawdzenie:
localhost> listquota user/jaqb STORAGE 18606/20480 (90.849609375%) localhost> setquota user/jaqb 40960 quota:40960 localhost> listquota user/jaqb STORAGE 18606/40960 (45.4248046875%) localhost> quit
jak widać miałem limit 20MB a zwiększyłem do 40. Teraz mam zajęte 45%. Ostatniego polecenia też chyba nie trzeba objaśniać...
Docelowo trzeba by sobie ten limit zdjąć. Wg. Managing IMAP rozdział 9 to nawet wykonalne, ale to w następnym odcinku ;-)
Tak jak pisałem ostatnio instalacja tego rozszerzenia jest prosta. Konfiguracja też. Wystarczy skopiować domyślny plik konfiguracyjny:
cd /usr/share/roundcubemail/plugins/managesieve cp config.inc.php.dist config.inc.php
Zmienić w pliku /usr/share/roundcubemail/plugins/managesieve/config.inc.php port z 2000 na 4190. U mnie wygląda to tak:
$rcmail_config['managesieve_port'] = 4190;
To oczywiście ma związek z plikiem /etc/cyrus.conf w którym mam wpis:
SERVICES { (...) sieve cmd="timsieved" listen="sieve" prefork=0
jeżeli jest wykomentowany to trzeba włączyć.
Wejście w konfigurację filtrów powoduje założenie domyślnego zbioru filtrów o nazwie managesieve oraz link do niego defaultbc i tym samym rozwiązuje problem wpisów w logu typu
lmtpunix[1000]: IOERROR: fstating sieve script /var/lib/imap/sieve/u/user/defaultbc: No such file or directory
ale tylko dla tego konkretnego użytkownika. Jest to łatwiejsze niż posługiwanie się poleceniem interfejsem znakowym sieveshell.
W poprzednim odcinku pisałem jak zainstalować roundcube z paczki. Teraz opiszę instalację rozszerzeń, tzw. plugin'ów.
Zakładam, że czytający ma przynajmniej podstawową wiedzę z zakresu programowania obiektowego, biegłą znajomość SQL z obsługą triggerów w szczególności oraz potrafi policzyć transkonduktancję czwórnika.
No to do dzieła. Otwieramy w ulubionym edytorze (oczywiście vi) plik /etc/roundcubemail/main.inc.php i poprawiamy linię
$rcmail_config['plugins'] = array();
na np. taką:
$rcmail_config['plugins'] = array('managesieve', 'markasjunk');
właśnie włączyliśmy dwie nowe funkcje: zarządzanie skryptami sieve i przenoszenie wiadomości do katalogu Spam jednym przyciskiem.
W standardowej instalacji RoundCubeMail jest dostarczony z następującymi rozszerzeniami:
acl additional_message_headers archive autologon database_attachments debug_logger emoticons enigma example_addressbook filesystem_attachments help hide_blockquote http_authentication jqueryui managesieve markasjunk newmail_notifier new_user_dialog new_user_identity password redundant_attachments show_additional_headers squirrelmail_usercopy subscriptions_option userinfo vcard_attachments virtuser_file virtuser_query
więcej o nich można przeczytać na specjalnej stronie.
W CentOS z EPEL (u mnie epel-release-6-8) instalacja jest prosta:
yum install roundcubemail
i już.
Teraz trzeba przygotować bazę. Tu nie ma filozofii tak jak każe plik INSTALL. Zmieniłem nazwę bazy i użytkownika: rcm, to skrót od RoundCubeMail:
create database rcm character set utf8; create user 'rcmuser'@'localhost' identified by 'tajnehaslo'; grant all privileges on rcm.* to 'rcmuser'@'localhost';
Jak widać hasło jest tajne ;-) Teraz trzeba te same nazwy ustawić w pliku:
/etc/roundcubemail/db.inc.php
w linii
$rcmail_config['db_dsnw'] = 'mysql://rcmuser:tajnehaslo@localhost/rcm';
a następnie zainicjować bazę poleceniem
mysql -u rcmuser -p rcm < /usr/share/doc/roundcubemail-0.8.5/SQL/mysql.initial.sql
wystarczy podać hasło i chwilę poczekać.
Dodatkowo w pliku
/etc/httpd/conf.d/roundcubemail.conf
trzeba dodać uprawnienia dla własnego komputera (jeżeli nie instalujemy lokalnie). W oryginale było:
Alias /roundcubemail /usr/share/roundcubemail <Directory /usr/share/roundcubemail/> <IfModule mod_authz_core.c> # Apache 2.4 Require local </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Deny from all Allow from 127.0.0.1 Allow from ::1 </IfModule> </Directory>
ja zmieniłem na:
Alias /roundcubemail /usr/share/roundcubemail <Directory /usr/share/roundcubemail/> <IfModule mod_authz_core.c> # Apache 2.4 Require local </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Deny from all Allow from 127.0.0.1 Allow from 1.2.3.4 Allow from ::1 </IfModule> </Directory>
gdzie 1.2.3.4 to zewnętrzny adres IP z którego konfigurowałem zdalnie serwer.
Teraz już można się zalogować na serwer (gdy IP jest 4.3.2.1):
http://4.3.2.1/roundcubemail/
i używać podając wszystkie dane konta. W teorii za pomocą tak postawionego serwera można sprawdzać pocztę na dowolnym innym.
W przypadku CentOS 6.4 można zamiast wiadomości dostać komunikat: Service Unavailable Error 500, a w pliku logu
tail /var/log/roundcubemail/errors
miałem:
PHP Error: Could not perform encryption; make sure Mcrypt is installed or lib/des.inc is available in /usr/share/roundcubemail/program/include/rcmail.php on line 1474 (POST /roundcubemail/?_task=login&_action=login)
rozwiązaniem jest zamiana w pliku
/etc/php.d/mcrypt.ini
lini
extension=module.so
na
extension=mcrypt.so
i restart serwera.
Ponieważ RoundCubeMail ma aspiracje bycia aplikacją, więc trzeba podać również nazwę serwera. Tutaj zakładam, że serwer powinien być jeden (co najwyżej kilka do wyboru z listy), bo po co obcy ludzie mają mi zapychać łącze.
Podstawową modyfikacją jest ustawienie wartości $rcmail_config['default_host'] na coś sensownego. Ja mam:
$rcmail_config['default_host']='ssl://localhost:993';
oczywiście przy połączeniu lokalnym można nie używać szyfrowania, ale to następnym razem...
Add comment