System Berberis został wykonany w architekturze klient–serwer i tym samym jest w stanie obsługiwać wiele stanowisk pracy. Serwerem bazy danych może być Oracle lub PostgreSQL. Oprogramowanie klienckie może zostać zainstalowane na stanowiskach komputerowych wyposażonych w system Windows XP (Servis Pack 2), Windows Vista lub Windows 7.

• redukcja kosztów oraz eliminacja błędów związanych z ręcznym wprowadzaniem danych

• znaczne obniżenie czasu wprowadzania danych i eliminacja opóźnień z tym związanych

• redukcja kosztów sprzętowych i pomieszczeń przez użycie jego wysoko produktywnego systemu wprowadzania danych

• szybki dostęp do wszelkich informacji

• gwarancja 100% pewności informacji dzięki użyciu automatycznych reguł walidacji

• gwarancja zachowania danych w formacie kompatybilnym z Twoją bazą danych

3. Wymagania systemowe

Uwaga: Poniższe dane mają charakter czysto orientacyjny. Rzeczywiste wymagania systemowe zależą od specyfiki działań prowadzonych przy wykorzystaniu systemu, np. charakteru pracy, ilości przetwarzań w jednostce czasu, ilości i wielkości załączników zapisywanych w bazie danych itp.

Procesor: zgodny z wymaganiami systemu operacyjnego

Pamięć RAM: zgodna z wymaganiami systemu operacyjnego

Twardy dysk: 150MB wolnej przestrzeni dyskowej

Drukarka: laserowa lub atramentowa

System operacyjny: Windows XP Service Pack 2, Windows Vista, Windows 7

Sieć: dostęp do serwera w dowolnej technologii (sieć lokalna, radiowa, internet)

Serwer:

Procesor: 2,6 GHz (zalecany 2x2,6)

Pamięć RAM: 2 GB

Twardy dysk: o pojemności dostosowanej do ilości generowanych dokumentów. Zaleca się zastosowanie systemu RAID celem ochrony przed utratą danych.

System operacyjny: Windows XP Service Pack 2, Windows Vista, Windows 7, Windows SBS 2003, Windows Server 2003 , Windows Server 2008, Linux, Solaris

Zalecany system: Windows Serwer, Linux Debian.

Zdalny dostęp: publiczny i stały zewnętrzny adres IP, router/modem dostępowy do Internetu z opcją serwera VPN lub z opcją przekierowania wybranych portów do środka sieci.

 

4. Konfiguracja

Poniższa lista tematów obejmuje zagadnienia oraz problemy, które najczęściej napotyka się podczas instalowania i konfigurowania poszczególnych elementów Systemu Berberis.

4.1. Instalacja oprogramowania serwerowego Systemu Berberis na serwerach Linux

4.2. Aktualizacja oprogramowania serwerowego Systemu Berberis na serwerach Linux

4.3. Instalacja  oprogramowania klienckiego Systemu Berberis

4.4. Aktualizacja oprogramowania klienckiego Systemu Berberis

4.5. Zwiększenie szybkości pobierania i wysyłania maili przy dużej liczbie operatorów lub skrzynkach z dużą ilością maili

4.6. Wpis w logach serwera PostgreSQL postaci: FATAL:  sorry, too many clients already

4.7. Instalacja dodatkowych słowników do sprawdzania pisowni w zaawansowanych edytorach (poczta, zdarzenia, itp.)

4.8. Instalacja oprogramowania klienckiego w trybie cichym

4.9. Problem z połączeniem klienta Systemu Berberis z serwerem

4.1. Instalacja oprogramowania serwerowego Systemu Berberis na serwerach Linux

1. Rozpakować berberis-linux-<numer wersji>.tgz poleceniem tar xf berberis-linux-<numer wersji>.tgz.
2. Przejść do katalogu berberis-linux-<numer wersji> poleceniem cd berberis-linux-<numer wersji>.
3. Uruchomić ./setup.sh i dalej postępować według instrukcji pojawiających się na ekranie.

UWAGA: Skrypt instalacyjny jest testowany dla systemów: Debian, Ubuntu, Fedora, OpenSuse.

4.2. Aktualizacja oprogramowania serwerowego Systemu Berberis na serwerach Linux

1. Wykonać kopie zapasową baz danych.
2. Rozpakować berberis-linux-<numer wersji>.tgz poleceniem tar xf berberis-linux-<numer wersji>.tgz.
3. Katalogi berberis-linux-<numer wersji>/berberis_client oraz berberis-linux-<numer wersji>/berberis_server/berberis_db przegrać na system Windows.
4. Na systemie Windows z katalogu berberis_db uruchomić program berberisdb.exe.
5. Wybrać opcje uaktualnienie.
5. Podać hasło dla użytkownika berberis, adres serwera oraz port na jakim pracuje serwer PostgreSQL.
6. Nacisnąć Dalej, zaznaczyć jakie bazy maja być uaktualnione i rozpocząć uaktualnienie.
UWAGA: Resztę poleceń wykonać tylko po pomyślnej aktualizacji bazy danych!
7. W systemie Linux przejść do katalogu berberis-server-<numer wersji> poleceniem cd berberis-server-<numer wersji>.
8. Uruchomić ./setup.sh i dalej postępować według instrukcji pojawiających się na ekranie.
 

4.3. Instalacja  oprogramowania klienckiego Systemu Berberis

1. W systemie Windows uruchomić instalację programem setup.exe z katalogu berberis-linux-<numer wersji>\berberis_client.
2. Podczas instalacji należy podać nazwę bazy na serwerze PostgreSQL, hasło użytkownika berberis oraz adres ip serwera.

4.4. Aktualizacja oprogramowania klienckiego Systemu Berberis

1. W systemie Windows uruchomić instalację programem setup.exe z katalogu berberis_client.
2. Podczas instalacji należy podać nazwę bazy na serwerze PostgreSQL, hasło użytkownika berberis oraz adres ip serwera.
Uwaga: Instalacje klientów należy dokonać równocześnie na wszystkich stanowiskach.
 

4.5. Zwiększenie szybkości pobierania i wysyłania maili przy dużej liczbie operatorów lub skrzynkach z dużą ilością maili

1) Konfiguracja domyślna.

Domyślnie istnieje jeden proces (Mailchecker) który odpowiada za odbiór  i wysyłkę maili ze wszystkich aktywnych kont pocztowych zdefiniowanych dla operatorów.

Jest to wynikiem tego, iż domyślnie dla każdego definiowanego konta pocztowego na danej bazie, wartość w worker_email.mailchecker_id jest równa 0  i w pliku conf.xml (domyślnie C:\Program Files\BMS Creative\berberis_server\conf\services) wartość parametru mailchecker_id = 0 (patrz poniżej na pogrubiony tekst w konfiguracja Mailcheckera dla bazy maxima):

<Service DisplayName="schedule_test_v_6000" WorkingDir="C:\Program Files\BMS Creative\berberis_server" PriorityClass="Normal" NoWindow="1">

            <ExeFile>C:\Program Files\Java\jre6\bin\java.exe</ExeFile>

            <Parameters>-jar &quot;C:\Program Files\BMS Creative\berberis_server\berberis_service\bin\schedule.jar&quot; &quot;C:\Program Files\BMS Creative\berberis_server\conf\services\conf.xml&quot; schedule_test_v_6000</Parameters>

</Service>

<MailChecker Name="maxima">

        <url>jdbc:postgresql:// localhost:5436/maxima 4</url>

        <!-- url zawierajacy adres, port, i nazwa bazy danych z ktora ma sie laczyc daemon -->

        <login>berberis</login>

        <password />

        <logfile>log/mailchecker_maxima.log</logfile>

        <!-- sciezka do pliu z logiem -->

        <loglevel>6</loglevel>

        <!-- poziom logowania od 1 do 6-->

        <maxlogfilesize>5</maxlogfilesize>

        <!-- maksymalny rozmiar pliku logow w MegaBajtach-->

        <interval>5</interval>

        <!-- czas miedzy kolejnymi pobraniami maili w minutach-->

        <send_interval>60</send_interval>

        <!-- czas miedzy kolejnymi wyslaniami maili w sekundach-->

        <err_send_interval>15</err_send_interval>

        <!--czas miedzy wysylaniem wiadomosci ktora maja bledy wyslania w minutach-->

        <send_period>2</send_period>

        <!-- czas (w dniach) przez jaki maja byc podejmowane proby wysylania maila-->

        <mailchecker_id>0</mailchecker_id>

        <!-- identyfikator mailcheckera -->

    </MailChecker>

Inaczej mówiąc, Mailchecker skonfigurowany jak powyżej obsługuję wszystkie konta pocztowe dla których

worker_email.mailchecker_id=0 

2)   Utworzenie kilku Mailchecker’ów dla różnych grup kont pocztowych

Można zdefiniowane konta pocztowe podzielić na grupy i dla każdej z nich zdefiniować Mailchecker’a obsługującego jedynie konta należące do danej grupy.

Konto pocztowe należy grupować  poprzez ustawienia dla nich jednej, tej samej wartości w worker_email.mailchecker_id

Następnie trzeba w pliku conf.xml dopisać pełne sekcje

<Service …>

[…]

</Service>

oraz

<MailChecker …>

[…]

</MailChecker>

 i w <mailchecker_id>0</mailchecker_id> podać zamiast 0, wartość którą przypisaliśmy w worker_email.mailchecker_id

Przykład takiej konfiguracji dla bazy maxima:

- zatrzymuję usługę Berberis Service

- dla 3 kont, w tabeli worker_email, w kolumnie mailchecker_id ustawiam wartość równą 1

- do pliku conf.xml dopisuję nowe sekcje odpowiedzialne za uruchamianie dodatkowego Mailcheckera obsługującego konta z worker_email.mailchecker_id=1:

<Service DisplayName="maxima_mailchecker_id_1" WorkingDir="C:\Program Files\BMS Creative\berberis_server" PriorityClass="Normal" NoWindow="1">

            <ExeFile>C:\Program Files\Java\jre6\bin\java.exe</ExeFile>

            <Parameters>-jar &quot;C:\Program Files\BMS Creative\berberis_server\berberis_service\bin\schedule.jar&quot; &quot;C:\Program Files\BMS Creative\berberis_server\conf\services\conf.xml&quot; maxima_mailchecker_id_1</Parameters>

        </Service>

<MailChecker Name=" maxima_mailchecker_id_1">

        <url>jdbc:postgresql:// localhost:5436/maxima 4</url>

        <!-- url zawierajacy adres, port, i nazwa bazy danych z ktora ma sie laczyc daemon -->

        <login>berberis</login>

        <password />

        <logfile>log/mailchecker_maxima_id_1.log</logfile>

        <!-- sciezka do pliu z logiem -->

        <loglevel>6</loglevel>

        <!-- poziom logowania od 1 do 6-->

        <maxlogfilesize>5</maxlogfilesize>

        <!-- maksymalny rozmiar pliku logow w MegaBajtach-->

        <interval>5</interval>

        <!-- czas miedzy kolejnymi pobraniami maili w minutach-->

        <send_interval>60</send_interval>

        <!-- czas miedzy kolejnymi wyslaniami maili w sekundach-->

        <err_send_interval>15</err_send_interval>

        <!--czas miedzy wysylaniem wiadomosci ktora maja bledy wyslania w minutach-->

        <send_period>2</send_period>

        <!-- czas (w dniach) przez jaki maja byc podejmowane proby wysylania maila-->

        <mailchecker_id>1</mailchecker_id>

        <!-- identyfikator mailcheckera -->

    </MailChecker>

-          uruchamiam usługę Berberis Service

-          w katalogu log (domyślnie C:\Program Files\BMS Creative\berberis_server\log) sprawdzam czy pojawił się plik logów o nazwie mailchecker_maxima_id_1.log i czy nie ma w nim niepokojących wpisów

Analogicznie jak w podanym przykładzie robię dla kolejnych grup kont pocztowych wykorzystując np. wartości mailchecker_id = 2 ,3 , ….

Wszystkie konta dla których worker_email.mailchecker_id pozostało równe 0, będą obsługiwane tak, jak do tej pory przez główny proces Mailcheckera, posiadającego w swojej konfiguracji wpis <mailchecker_id>0</mailchecker_id>

3)   Utworzenie osobnych Mailchecker’ów do odbioru i wysyłki maili dla różnych grup kont pocztowych

Mailchecker zdefiniowany jak w punkcie 2) obsługuje konta pocztowe z danej grupy, ale zajmuje się odbiorem i wysyłką maila jednocześnie. Jeżeli skrzynki pocztowe obsługiwane przez dany Mailchecker są bardzo duże (posiadają po kilka tysięcy maili), to etap sprawdzania tych skrzynek pocztowych pod kątem nowych maili, może zajmować wiele czasu, co może przełożyć się na wydłużenie czasu oczekiwania na wysłanie maili z Berberisa dla tych kont pocztowych.

Dlatego można dla danej grupy kont pocztowych skonfigurować dwa Mailchecker’y: jeden odpowiada za odbieranie maili, a drugi za wysyłanie. Oba pracują niezależnie od siebie.

Jak utworzyć taka konfigurację?

Na pewno będzie potrzebna jedna skrzynka pocztowa, z której nikt nie korzysta w rzeczywistości, nikt nie wysyła na nią maili. Będę tą skrzynkę nazywał skrzynką WIDMO. Będzie ona użyta w konfiguracji w celu eliminacji nieprawdziwych  informacji o błędach w logach Mailchecker’ów – wyjaśnienie będzie zawarte później.

Przykładowe dane tego konta to:

Adres e-mail: widmo@example.pl

Serwer POP3: pop3.example.pl

Serwer SMTP: smtp.example.pl

Nazwa użytkownika:  widmo@example.pl

Załóżmy, że chcę aby dane konto pocztowe zdefiniowane dla operatora miało osobnego Mailchecker’a do pobierania maili i osobnego do wysyłania.

Dane tego konta to:

Adres e-mail: mail@example.pl

Serwer POP3: pop3.example.pl

Serwer SMTP: smtp.example.pl

Nazwa użytkownika:  mail@example.pl

Mimo, że konto jest jedno, to w kartotece operatora w Berberisie muszę zdefiniować je dwa razy: jako konto do odbioru poczty (IN) oraz jako konto do wysyłki poczty (OUT).

Nazwy IN i OUT zostały użyte jedynie na potrzeby wyjaśnienia mechanizmu konfiguracji opisanego w tym punkcie.

Rysunek przedstawia konfigurację konta mail@example.pl jako konta maili przychodzących (IN):

Komentarz:

- opcja „Tylko przychodzące” musi być zaznaczona; powoduje ona, że Mailchecker obsługujący to konto będzie zajmował się sprawdzaniem maili przychodzących w oparciu o dane wpisane w „Konto przychodzące”

Rysunek przedstawia konfigurację konta mail@example.pl jako konta maili wychodzących (OUT):

Komentarz:

- opcja „Domyślne” oznacza, że podczas pisania nowego maila - w przypadku gdy dany operator posiada kilka skrzynek pocztowych - to konto zostanie podpowiedziane jako domyślna skrzynka z której pisany mail zostanie wysłany

- w części „Konto przychodzące” podaliśmy dane konta WIDMO, ponieważ Mailchecker odpowiedzialny za obsługę tego konta do wysyłki (OUT) będzie również sprawdzał czy na skrzynce WIDMO nie ma nowych maili. Jeżeli – tak jak pisałem wyżej - konto WIDMO będzie zawsze puste, sprawdzenie takiego konta potrwa ułamek sekundy i nie opóźni wysłania maili

W efekcie jedna skrzynka pocztowa email@example.pl rozbita na kwa konta IN i OUT wygląda jak poniżej:

Teraz czas na konfigurację worker_email.mailchecker_id  dla kont IN i OUT.

Wszystkie konta OUT przeznaczone na wysyłkę grupujemy razem wpisując unikalną wartości worker_email.mailchecker_id. Pozostałe konta IN możemy zostawić na domyślnym Mailchecker o id = 0 (czyli worker_email.mailchecker_id=0) lub rozbić na odrębne Mailchecker’y jeśli odbiór jest za wolny. (Korzystając z instrukcji zawartych w punkcie 2 tej instrukcji).

Dla omawianego wyżej przykładu:

Dla konta „IN mail@example.pl„ ustawiamy worker_email.mailchecker_id= 0

A dla konta „OUT mail@example.pl„ ustawiamy worker_email.mailchecker_id=99

Dla innych kont typu IN należących do tej samej grupy kont co „IN mail@example.pl” również ustawiamy worker_email.mailchecker_id=0

Dla innych kont typu OUT należących do tej samej grupy kont co „OUT mail@example.pl” również ustawiamy worker_email.mailchecker_id=99

Teraz zatrzymujemy usługę Berberis service.

Następnie definiujemy Mailcheckera odpowiedzialnego za wysyłanie maili z kont o worker_email.mailchecker_id=99 (proszę zwrócić uwagę na parametr interval i send_interval)

<Service DisplayName="maxima_mailchecker_OUT_id_99" WorkingDir="C:\Program Files\BMS Creative\berberis_server" PriorityClass="Normal" NoWindow="1">

            <ExeFile>C:\Program Files\Java\jre6\bin\java.exe</ExeFile>

            <Parameters>-jar &quot;C:\Program Files\BMS Creative\berberis_server\berberis_service\bin\schedule.jar&quot; &quot;C:\Program Files\BMS Creative\berberis_server\conf\services\conf.xml&quot; maxima_mailchecker_OUT_id_99</Parameters>

        </Service>

<MailChecker Name=" maxima_mailchecker_OUT_id_99">

        <url>jdbc:postgresql:// localhost:5436/maxima</url>

        <!-- url zawierajacy adres, port, i nazwa bazy danych z ktora ma sie laczyc daemon -->

        <login>berberis</login>

        <password />

        <logfile>log/mailchecker_maxima_OUT_id_99.log</logfile>

        <!-- sciezka do pliu z logiem -->

        <loglevel>6</loglevel>

        <!-- poziom logowania od 1 do 6-->

        <maxlogfilesize>5</maxlogfilesize>

        <!-- maksymalny rozmiar pliku logow w MegaBajtach-->

        <interval>60</interval>

        <!-- czas miedzy kolejnymi pobraniami maili w minutach-->

        <send_interval>5</send_interval>

        <!-- czas miedzy kolejnymi wyslaniami maili w sekundach-->

        <err_send_interval>15</err_send_interval>

        <!--czas miedzy wysylaniem wiadomosci ktora maja bledy wyslania w minutach-->

        <send_period>2</send_period>

        <!-- czas (w dniach) przez jaki maja byc podejmowane proby wysylania maila-->

        <mailchecker_id>99</mailchecker_id>

        <!-- identyfikator mailcheckera -->

    </MailChecker>

Uruchamiamy usługę Berberis Service i sprawdzamy logi nowych Mailchecke’rów.

4.6. Wpis w logach serwera PostgreSQL postaci: FATAL:  sorry, too many clients already

Przyczyna: Liczba połączeń do bazy danych przekracza domyślny limit 100 połączeń.

Rozwiązanie (tylko dla Serwera Berberis pracującego w środowisku Windows): Należy zwiększyć limit połączeń.

Wszyscy operatorzy pracujący w Berberisie winni się wylogować. Na serwerze należy zatrzymać usługę Berberis Postgresql 8.4. Na serwerze należy wykonać kopię zapasową pliku

C:\Program Files\BMSCreative\berberis_server\postgreSQL\8.4\data\postgresql.conf. (ścieżka podana dla Windows 32bit)

Następnie proszę w tym pliku odnaleźć wpis

max_connections = 100

zmienić jego wartość na 300, czyli

max_connections = 300

i zapisać zmiany.

Następnie proszę uruchomić usługę Berberis Postgresql 8.4 i zalogować się do Berberisa. Jeżeli po zwiększeniu limitu połączeń do 300, usługa Berberis Postgresql 8.4 nie będzie chciała się uruchomić, proszę zmniejszać ten limit o 10 i próbować uruchamiać usługę Berberis Postgresql 8.4 aż do skutku.

4.7. Instalacja dodatkowych słowników do sprawdzania pisowni w zaawansowanych edytorach (poczta, zdarzenia, itp.)

Słowniki można znaleźć na stronie http://wiki.services.openoffice.org/wiki/Dictionaries

Celem zainstalowania należy:

1. Pobrać plik słownika.

2. Rozpakować pobrany plik zip lub oxt (np. za pomocą darmowej aplikacji 7-zip)

3. Przegrać do katalogu z słownikami pliki *.dic oraz *.aff. Standardowo jest to c:\program files\BMS Creative\Berberis\dictionaries

4. Opcjonalnie można zmienić nazwę plików z słownikiem na bardziej przyjazną. Nazwa pliku ze słownikiem widziana jest podczas wybierania języka, który ma być sprawdzany w edytorze.

 

4.8. Instalacja oprogramowania klienckiego w trybie cichym

Można uruchomić instalator z przełącznikami lub rozpakować go 7-zipem i uruchomić bezpośrednio znajdujący się w nim setup.exe z przełącznikami. W pierwszym przypadku operator widzi rozpakowywanie archiwum, a w drugim nie.

1) najprostsze użycie jest następujące:

SetupBerberisClient-6.5.0.6.exe /S

Uaktualnia klienta bez komunikatów potwierdzeń itp. Natomiast jeśli na stanowisku nie było wcześniej naszego klienta instalator wychodzi z trybu cichego na konfiguratorze połączenia - trzeba podać dane do bazy zapisać i instaluje się dalej.

2) można w pełni zautomatyzować instalację wraz z linkowaniem do bazy

Przykładowe użycie:

SetupBerberisClient-6.5.0.6.exe /S /profile=maxima /host=192.168.1.1 /port=5436 /base=maxima /password_encrypted="213 231 223 231 21 323 23 321" /user_xml=False

Przełączniki kolejno:

/S -> uruchamia tryb cichy

/profile -> nazwa profilu widocznego w konfiguratorze

/host /port /base -> namiary na bazę danych

/password lub /password_encrypted -> hasło w postacie jawnej już przeszyfrowane przez konfigurator

(przeszyfrowane hasło można pobrać z pliku %appdata%/BMS CREATIVE/berberis/berberis.xml ze stanowiska, gdzie Berberis już działa)

/user_xml przyjmuje tylko True lub False - aktywuje lub deaktywuje przechowywanie informacji o profilach w katalogu użytkownika

Jeśli dokonujemy instalacji na innym koncie niż operatora, który będzie pracował w Berberisie, najlepiej będzie ustawić False. Wówczas konfiguracja połączenia przechowywana jest w pliku berberis.xml znajdującym się w folderze z programem i każdy operator Windows z niego korzysta. Trzeba tylko zapewnić prawa dostępu do odczytu i zapisu w tym pliku.

4.9 Problem z połączeniem klienta Systemu Berberis z serwerem

Należy otworzyć port 5436 na serwerze i ew. firewallach, miedzy serwerem a klientem. Otwartość portu można sprawdzić np. za pomocą polecenia telnet. W przypadku adresacji sieci lokalnej innej niż: 192.0.0.0/8, 10.0.0.0/8, 172.16.0.0/16 należy dopisać odpowiednią adresację w pliku ...\BMS Creative\berberis_server\postgreSQL\8.4\data\pg_hba.conf