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...

Ten kto umie pisze kod, ten kto nie umie pisze książki..., albo blog.

Pon Wt Śr Czw Pt So N
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            
eZ Publish™ copyright © 1999-2024 eZ Systems AS