Mechanizm podglądu logów i alarmów pozwala przeglądać w kliencie graficznym Proliba logi generowane przez procesy batchowe na serwerze bazy danych. Procedury wywoływane na serwerze zapisują swoje logi do bazy danych i można je dzięki temu zobaczyć w kliencie graficznym. Dodatkowo oprócz zwykłych logów w tym samym module prezentowane są także tzw. alarmy. Są to krótkie informacje tekstowe informujące o błędach i niepokojących sytuacjach które zdarzyły się na serwerze bazy danych.

Do procedury podglądu logów mogą wejść tylko operatorzy którym nadano odpowiednie uprawnienia. Początkową konfigurację tego modułu należy rozpocząć od utworzenia testowego wpisu alarmu. Należy zalogować się na serwer z bazą danych a następnie wykonać polecenie:

[maxel@cpd1-PROLIB-db-2019 ~]$ /prolib/maxware/bin/prolib batch dodaj_log.p -param "-ETYKIETAl2,-LOGwersja_info,-ALARM"

Może to wykonać Informatyk w bibliotece lub Inżynier systemowy SygnitySBS.

Po wykonaniu tego polecenia należy zalogować się do Proliba do modułu Administrator i wejść do opcji Uprawnienia/Operatorzy, grupy, procedury i wybrać zakładkę Procedury

Następnie należy wyszukać procedurę pokaz_logi.w i nadać do niej odpowiednie uprawnienia. Sugeruję aby dodać do listy operatorów przynajmniej Bibliotekarza systemowego:

Następnie należy się przelogować i po uruchomieniu Proliba wejść do opcji Aplikacja/Lista logów. Należy kolejno przełączyć się na Alarmy i Logi. Na liście alarmów powinien się pojawić alarm z etykietą L2.

W kolejnym kroku należy skonfigurować uprawnienia szczegółowe. Należy wejść do modułu Administrator do opcji Uprawnienia/Operatorzy, grupy, procedury i wybrać zakładkę Procedury. Następnie należy wyszukać procedur o nazwach zaczynających się od alarm.

Podobnie jak w przypadku procedury pokaz_logi.w należy odpowiednio ustawić uprawnienia dla operatorów (np. Bibliotekarza systemowego):

Po ponownym przelogowaniu się podczas logowania się do Proliba powinno pojawić się okienko informujące o alarmie:

Gdyby takie okienko się nie pojawiło prosimy o kontakt z Inżynierem systemowym SygnitySBS.

Możemy w tym momencie skasować alarm klawiszem Usuń wpis loga. Był on potrzebny tylko do konfiguracji.

Mechanizm prezentacji logów i alarmów został poprawnie skonfigurowany.

Aby dodać kolejnego operatora należy dodać go do listy uprawnień do procedur: pokaz_logi.w, alarm_pokaz, alarm_usun_log i alarm_wylacz.

Parametry konkretnej bazy można podawać jako parametry startowe, bądź umieszczać w pliku konfiguracyjnym nazwa.pf (np. prolib.pf).

Podstawowe parametry pozwalające na konfigurację bazy to:

-db - ścieżka do bazy danych lub nazwa bazy
-H - adres IP badz hostname serwera (można pominąć jeśli klient jest na tym samym serwerze co baza)
-S – numer portu lub nazwa usługi z pliku /etc/services (można pominąć jeśli klient jest na tym samym serwerze co baza)
-N – typ protokołu (można pominąć jeśli klient jest na tym samym serwerze co baza)

Tak. Zostały przygotowane odpowiednie skrypty dające taką możliwość.

Drukarki laserowe w odróżnieniu od drukarek igłowych drukują całą stronę i dlatego najprostsze podejście tzn. wysłanie wydruku poprzedzone wysłaniem do drukarki kodów sterujących oczywiście zadziała ale będziemy mieli 1 rewers na 1 stronie (np. A4). Wiąże się z tym duże marnotrawstwo papieru. Dlatego opracowane zostały skrypty drukowania z kolejkowaniem. W tym trybie wydruki nie są bezpośrednio wysyłane na drukarkę ale chwilowo przenoszone do katalogu kolejki. Osobny proces wysyła wydruki z kolejki scalając zebrane tam rewersy w ten sposób, że na jednej kartce A4 mieści się kilka (4-5) rewersów.

W trybie z kolejkowaniem definicja drukarki w Prolibie może wyglądać następująco:

W crontab'ie użytkownika maxel jest wywoływana procedura batch-rewersy.p:

[root@ProlibDB ~]# crontab -l -u maxel
.....

* * * * * /prolib/maxware/bin/prolib batch batch-rewersy.p >/dev/null  2>&1

.....

Procedura batch-rewersy.p zapisuje rewersy znajdujące się w bazie danych Prolib do plików w katalogu /prolib/tty/rap a następnie wywołuje dla każdego pliku odpowiedni skrypt. Który skrypt drukarkowy zostanie wywołany zależy od konfiguracji zapisanej w Prolibie w module Administrator w opcji Ustawienia/Wydruki rewersów. Odpowiednie wpisy wiążą pary Lokalizacja i Znak miejsca z określoną drukarką i jej skryptem. W przypadku rewersu drukowanego na drukarce rew_filia2 zostanie wywołany skrypt /prolib/druk/rewersy_laser.sh z parametrem filia2 (nazwa kolejki). Skrypt rewersy_laser.sh przenosi plik z rewersem do katalogu kolejki /prolib/wrk/kolejki/filia2/do_druku. W tym miejscu gromadzą się rewersy oczekując na kolejny proces który scali je w jeden wydruk i wyśle na drukarkę.

Ten krok może zostać zrealizowany na dwa sposoby.

W pierwszym operator w magazynie lub wypożyczalni logując się na serwer bazy danych na określonego użytkownika (programem putty.exe) uruchamia skrypt /prolib/druk/menu_rewersy.sh . Skrypt ten pozwala na żądanie wydrukować rewersy z określonej kolejki, ponowić poprzedni wydruk lub zakończyć pracę. Wyświetla także ile jest rewersów w danej kolejce. Można go dostosować do obsługi wielu kolejek.

Druga możliwość to cykliczne wywołanie skryptu crontab_rewersy.sh . W tym rozwiązaniu w crontab'ie użytkownika maxel znajduje się wywołanie skryptu:

[root@ProlibDB ~]# crontab -l -u maxel
.....

0 8-15 * * 1-5 /prolib/druk/crontab_rewersy.sh >/dev/null  2>&1

.....

Przykładowo o każdej pełnej godzinie pomiędzy 8 a 15, od poniedziałku do piątku skrypt crontab_rewersy.sh będzie scalał rewersy z określonych kolejek i jako pojedynczy wydruk wysyłał je na drukarkę laserową.

W obu przypadkach (menu_rewersy.sh i crontab_rewersy.sh) pliki z rewersami są scalane, modyfikowane są niektóre kody sterujące a następnie dodawany jest plik z kodami sterującymi specyficznymi dla drukarki laserowej. Tak przygotowany wydruk wysyłany jest już do drukarki.

W przypadku wydruku bez kolejkowania skrypt drukarkowy wskazywany w definicji drukarki w systemie Prolib (Administrator opcja Ustawienia/Drukarki) obsługuje pojedynczy rewers z katalogu /prolib/tty/rap. Modyfikuje niektóre kody sterujące i dodaje plik z kodami sterującymi dla drukarki laserowej. Tak przygotowany plik z pojedynczym rewersem zostaje od razu wysłany na drukarkę.

W drukarce można wykorzystywać papier formatu A4 jaki i A6 (mamy przygotowane kody sterujące)

W celu przeniesienia lub wgrania nowej wersji po reinstalacji należy użyć programu do automatycznej instalacji klienta graficznego. Jeżeli nie mamy odpowiedniej wersji autoinstalatora prosimy o kontakt z inżynierem systemowym w celu udostępnienia instalatora.

Jeżeli na danym komputerze nie ma zainstalowanego Proliba i Progressa korzystamy Prolib_AutoInstall_Full_GUI_20xx.x.xx.exe - gdzie xx.x.xx to numer aktualnej wersji

Jeżeli na danym komputerze jest tylko reinstalacja czyli starsza wersja Proliba i Progressa jest już na tym stanowisku korzystamy Prolib_AutoInstall_SP_GUI_20xx.x.xx.exe - gdzie xx.x.xx to numer aktualnej wersji

Wersja 5 dokumentu z wymaganiami systemowymi z dnia 27 maja 2022 r.

Podstawowym wymaganiem jest oprogramowanie Progress OpenEdge 11.7, które wymagane jest przy wersji systemu Prolib 2019.2.01, wcześniej 11.5 oraz 10.2B. Oznacza to, że Klient musi mieć aktualną polisę serwisową na posiadane oprogramowanie Progress Workgroup, Enterprise, Client Networking. OpenEdge  jest dostępny na podstawowych platformach sprzętowych typu: Linux czy Microsoft Windows. Szczegóły w dokumencie pt. OpenEdge 11 Platform and Product Availability Guide na stronach firmy Progress (www.progress.com).

System Prolib może działać na osobnych serwerach fizycznych lub na jednym serwerze fizycznym podzielonym na maszyny wirtualne tak, aby możliwe było uruchomienie serwera bazy danych, serwera OPAC-a WWW (katalogu elektronicznego) oraz serwera aplikacji - jeśli ten ostatni jest wymagany.

Serwery wirtualne na jednym serwerze fizycznym

Serwery fizyczne

Systemy Operacyjne

Stacje robocze

Urządzenia peryferyjne

Parametry łącza internetowego

Jeżeli system prolib wolniej działa lub podczas wyszukiwaniu w Integro widzimy spowolnienie

Na serwerze z katalogiem Integro sprawdzamy czy serwer nie jest atakowany przez boty przeszukujące

Sprawdzenie logów vim /var/www/nginx/nazwa_domenowa_pl/logs/access.log i wyszukujemy /bot

Jeżeli w logu widzimy dużą ilość wpisów zwiazanych z botem pod tą samą nazwą lub pod różnymi

Sprawdzić czy w katalogu Integro jest metoda antybotowa i jak wyglada lista antybotowa 

vim /prolib/integro/index.php i szukamy jak wpisu poniżej 

Jeżeli wpisu nie ma proszę zgłosić uwagę do inżyniera systemowego poprzez zgłoszenie https://sos.prolib.pl/

Jeżeli nie ma danego bota na liście dopisać do listy.

Na serwerze z bazą

Sprawdzić zajętość webserwisów.
/prolib/progress/bin/asbman -q -i prolibws 

Ilość wywołanych usług tomcata 

netstat -an | grep 9050

Zatrzymać nginx na serwerze z Katalogiem
systemctl stop nginx

Zatrzymać tomcat na serwerze z bazą
systemctl stop tomcat

Zrestartować brokery poleceniem:  
/prolib/progress/bin/asbman -i prolibws –stop 

/prolib/progress/bin/asbman -i prolibws –start

Uruchomić usługi tomcat
systemctl start tomcat

Uruchomić usługe nginx
systemctl start nginx

W systemie Prolib na serwerach (bazy danych, Integro, OpacWWW) jest uruchamiane wiele dodatkowych procedur.

Do ich uruchamiania wykorzystywany jest mechanizm crontab (dla Linux'a) lub Harmonogram zadań (dla Windows).

Na serwerze bazy danych wywołania są umieszczone w crontab'ie użytkowników: maxel i root.

Po zalogowaniu się na użytkownika root i wydając polecenie

[root@ProlibDB ~]# crontab -l -u maxel

zobaczymy listę wywoływanych skryptów dla użytkownika maxel

Pierwsze 5 kolumn oznacza:

czas uruchomienia (minuty)

czas uruchomienia (godzina)

dzień miesiąca

miesiąc

dzień tygodnia

Kolejna kolumna to polecenie do uruchomienia.

W naszym przykładzie pierwszy wpis oznacza:

Codziennie o godzinie 0:03 uruchom /prolib/maxware/bin/prolib crontab

Większość wpisów wywołuje skrypt /prolib/maxware/bin/prolib który jest głównym skryptem systemu Prolib i który wykonuje różne operacje na serwerze bazy danych zależnie od pierwszego parametru.

Opcje skryptu /prolib/maxware/bin/prolib wykorzystywane do uruchamiania różnych procedur wywoływanych cyklicznie:

crontab

Wywołanie procedur które mają być wykonane raz dziennie:

- rotowane są logi (https://help.prolib.pl/faqs/co-jest-i-jak-dzia%C5%82a-rotacja-log%C3%B3w

- instalowane są poprawki do systemu Prolib (poprawki dla serwera bazy danych)

- restartowani są klienci dla Integro/OpacWWW (AppServer lub WebSpeed)

- uruchamiane są procedury:

snd_zwr.p - wysłanie maili o upływającym terminie zwrotu książki

czytkarmail.p - wysłanie maili o rozpoczęciu naliczania kary

rejopsrv.p rejopsrv-usuzam.p - obsługa mechanizmu Zdalnej Rejestracji Czytelników (maile, blokady, usuwanie)

datawazczyt.p - obsługa daty ważności konta

init_wypbatch.p - inicjalizacja Wypożyczalni

wid_init.p - obsługa modułu Wymiana i Dary

wo2_opacbp.p - czyszczenie tablic tymczasowych OpacWWW

statystyka-batch.p - statystyki (głównie Wypożyczalni)

news-cleaner.p - usuwanie starych nowości

batchraporty.p - generowanie raportów w trybie batchowym

zamowienia-control-batch.p - obsługa zamówień ksero, skanów

recipient-control-batch.p - kontrola poprawności numeru telefonu (dla SMSów)

aktualnosci-remove-batch.p - usuwanie przeterminowanych aktualności biblioteki

rankings-analyzer-batch.p - analiza danych dla potrzeb rankingu

kolekcja-control-batch.p - obsługa Kolekcji

powiadomienia-batch.p - obsługa modułu Powiadomienia

batch-email-kasacja-kolejki.p - usuwanie starych emaili z bazy danych

rating-update-batch.p - aktualizacja ocen czytelnika (na podstawie danych Indeksu Centralnego)

cron20

Wywołanie procedur które mają być wykonane w nocy. Obecnie wywoływane są dwie procedury porządkujące dane:

buduj5xxbatch.p - procedura odbudowuje linki w polach 5xx

batch-rec-refresher.p - batchowa odbudowa rekordów (np. po scalaniu słowników)

cron5

Wywołanie procedur związanych z aktualizacją danych z CKHW

akt_lkhw.p - aktualizacja haseł CKHW

akt_rek_bibl.p - aktualizacja rekordów bibliograficznych importowanych z NUKATu

ex-locks-control

W opcji tej uruchamiana jest procedura ex-locks-control.p, która usuwa blokady na rekordach czytelników założone w module Wypożyczalnia

digitalizacja_control

W opcji tej uruchamiana jest procedura digitalizacja_control.p, która usuwa blokady związane z obsługą materiałów zdigitalizowanych

check_sys

Sprawdzenie stanu serwera i różnych elementów systemu Prolib dla potrzeb alarmów

solr-update

Obsługa synchronizacji danych pomiędzy bazą Prolib a Integro (baza SOLR). Procedura jest uruchamiana tylko gdy w bibliotece jest Integro

 batch batch-rewersy.p

Uruchomienie procedury wydruku rewersów.

blokuj_za_nocne

Blokada czytelników związana z mechanizmem wypożyczeń nocnych

W każdej bibliotece występuje także wpis:

/prolib/emailmax/skrypty/unix/wyslij.sh

Jest to wywołanie mailera.

W niektórych bibliotekach mogą być jeszcze wywoływane inne procedury zależne od konfiguracji. Skrypty zazwyczaj umieszczane są w katalogu /prolib/maxware/bin

W przypadku użytkownika root, procedur związanych z systemem Prolib jest trochę mniej. Mogą to być:

/prolib/maxware/bin/kopia

Wykonanie kopii bezpieczeństwa bazy i aplikacji

/prolib/maxware/bin/czysc_logi_tomcata.sh

Uruchomienie procedury usuwającej stare logi z katalogu /prolib/opac-integro/tomcat/logs. Procedura działa gdy jest Integro

/prolib/maxware/bin/straznik.sh

Uruchomienie procedury kontrolującej drukarki do rewersów (strażnik drukarek)

W pierwszej kolejności należy sprawdzić czy do serwera po przez rdp nie może dostać się jedna osoba czy więcej 

Jeżeli jedna osoba :
- Sprawdzić czy konto danej osoby nie jest zablokowane na serwerze rdp
- Sprawdzić czy konto danej osoby nie wygasło na serwerze rdp

- Sprawdzić czy konto jest w grupie użytkowników pulpitu zdalanego

- Sprawdzić punkty z poniższe

Jeżeli wszyscy nie mogą się zalogować :

- Czy system Windows nie był aktualizowany i ma problem z restartem serwera i nie wszystkie powłoki systemowe zostały wyłączone (potrzebny restart)

- Sprawdzić punkty z poniższe

Jeżeli częściowo osoby nie mogą się zalogować :
- Sprawdzić czy są przypisywane do tego samego serwera rdp (czy Load balance nie wpuszcza na jeden serwer a drugi jest nie dostępny)
- Sprawdzić czy nie ma problemów z kartą sieciową (czy nie zmieniła się adresacja serwera) na serwerze rdp
- Sprawdzić czy nie ma problemów z dyskami (podmontowaną macierzą) na serwerze rdp
- Przy wirtualiazcji maszyn sprawdzić czy nie było jakiejś aktualizacji wirtualizatora i nie potrzebny jest restart maszyn wirtualnych.
- Sprawdzić limity sesji na serwerze rdp (Limity sesji należy ustawić albo poprzez limit sesji RDP w polityce ról dla domeny, lub też indywidualnie dla każdego operatora wchodząc w edycję

- Jeżeli serwer rdp został zrestartowany i nie można zalogować się do systemu Prolib sprawdzić czy nie zostały jakieś zawieszone sesje przy bazie danych Progress

Proszę sprawdzić czy operator połączenia internetowego nie zmienił adresu IP z którego się łączymy, jeżeli tak to poinformować inżyniera systemowego o zmianie adresu.

W systemie Prolib działa wiele procedur uruchamianych cyklicznie. Prawie wszystkie z nich generują pliki logów, które zawierają informacje o działaniu procedury i ewentualnych błędach. Większość logów tworzona jest w katalogu /prolib/tty/rap.

Każdorazowe uruchomienie procedury powoduje DOPISYWANIE nowej informacji do logu związanego z daną procedurą. Jak łatwo zauważyć już po kilku tygodniach log staje się na tyle duży, że trudno jest go przeglądać. Zajmuje także coraz więcej miejsca na dysku. Jednocześnie wpisy w logu pochodzące np. z przed 3-4 lat nie mają już za bardzo znaczenia.

Aby rozwiązać problem dużych logów od wielu lat w skryptach obsługujących system Prolib (głównie /prolib/maxware/bin/prolib) stosowany jest mechanizm rotacji logów.

Polega on na tym, że raz w tygodniu (w nocy z soboty na niedzielę) zmieniane są nazwy logów w taki sposób, że główny log danej procedury staje się logiem archiwalnym a procedura zaczyna zapisywać dane do nowego logu. Przykładowo procedura snd_zwr.p zapisuje informacje do logu /prolib/tty/rap/snd_zwr.log.

W momencie rotacji nazwa pliku /prolib/tty/rap/snd_zwr.log zmieniana jest na snd_zwr.log.0

Podobnie zmieniane są nazwy logów wcześniejszych (z poprzednich tygodni). Zmiana nazw jest robiona w kolejności od najstarszego do najmłodszego. Najstarszy log (.6) jest usuwany. W katalogu może się znajdować do 7 logów archiwalnych (tj.   .0   .1   ...  .6) oraz log aktualny.

W skrypcie /prolib/maxware/bin/prolib za tą operację odpowiada następująca funkcja:

function rotuj_logi ()
{
  while [ "$1" != "" ]
  do
    # rotacja logu wskazanego parametrem $1
    rm -f $1.6
    mv $1.5 $1.6 >/dev/null 2>&1
    mv $1.4 $1.5 >/dev/null 2>&1
    mv $1.3 $1.4 >/dev/null 2>&1
    mv $1.2 $1.3 >/dev/null 2>&1
    mv $1.1 $1.2 >/dev/null 2>&1
    mv $1.0 $1.1 >/dev/null 2>&1
    mv $1 $1.0 >/dev/null 2>&1

    shift
  done
}

Wywołanie może wyglądać tak:

         # rotacja logow z innych mechanizmow
          LLOGOW="batch-rewersy.log blokuj_za_nocne-batch.log emaildemon.log przekaz.log ex-locks-control.log solr-update-index.log"
          rotuj_logi ${LLOGOW}

Dla potrzeb mailera stworzony został skrypt /prolib/emailmax/skrypty/unix/emailrot.sh

Jest on wywoływany ze skryptu /prolib/maxware/bin/prolib z w nocy z soboty na niedzielę. Dodatkowo oprócz rotowania logu /prolib/emailmax/email.log rotuje on katalogi pocztowe: err, out oraz dodatkowy log /prolib/emailmax/kolejki.log a także czyści katalog kosza /prolib/emailmax/kosz. W przypadku mailera przechowywane jest 5 logów (katalogów) archiwalnych (.1 ... .5) oraz log (katalog) aktualny.

Niektóre moduły (np. serwer SIP-2, serwer P2SO) rotują logi we własnym zakresie. Logi te znajdują się także w katalogu /prolib/tty/rap.

Przykład listy logów serwera SIP-2:

Przykład listy logów serwera P2SO:

W końcówce 2020 roku Red Hat ogłosił ogromną zmianę w systemach CentOS Linux zmieniając zasady dotychczasowego działania. Po otrzymaniu wielu krytycznych głosów Red Hat, zmienił politykę dostępu do licencji w programie Red Hat Developer Program. Dzięki ogromnej społeczności, Red Hat wprowadził zapis, który daje możliwość uruchomienia 16 systemów operacyjnych Red Hat w celach produkcyjnych.

Aby otrzymać darmowe licencje należy założyć bezpłatne konto w Red Hat. Następnie przejść na stronę do pobierania obrazów ISO - Download.

Oryginalne źródła informacji:

• New Year, new Red Hat Enterprise Linux programs: Easier ways to access RHEL
• No-cost RHEL for small production workloads
• Individual Developer subscription
• Individual Developer subscription for RHEL

Configuring basic authentication

Po instalacji systemu należy zarejestrować system na naszym koncie.

Przed rejestracją należy uzupełnić konfigurację, zmieniając plik dowolnym edytorem tekstowym: /etc/insights-client/insights-client.conf

auto_config=FALSE
authmethod=BASIC
username=<your customer portal username>
password=<your customer portal password>

Następnie wydać polecenie w konsoli: 

# insights-client --register

Tak. Powstał zestaw skryptów umożliwiający wysyłanie rewersów przy pomocy maili. Dostępne są dwa tryby pracy.

W pierwszym rewers jest wysyłany prawie natychmiast. Proces "wydruku" jest wywoływany co kilka (1-5) minut na serwerze bazy danych. Odpowiada za to następujący wpis w tablicy crontab użytkownika maxel:

[root@ProlibDB ~]# crontab -l -u maxel

......

* * * * * /prolib/maxware/bin/prolib batch batch-rewersy.p >/dev/null  2>&1

......

Procedura batch-rewersy.p odczytuje rewersy znajdujące się w bazie danych i zapisuje każdy z nich do pliku. Pliki znajdują się w katalogu /prolib/tty/rap:

[root@ProlibDB ~]# cd /prolib/tty/rap
[root@ProlibDB rap]# ll *.rap
-rw-r--r-- 1 maxel prolib 346 May  3 12:32 0305221232020711.rap
-rw-r--r-- 1 maxel prolib 345 May  3 12:32 0305221232021232.rap
-rw-r--r-- 1 maxel prolib 346 May  3 12:32 0305221232022681.rap
-rw-r--r-- 1 maxel prolib 340 May  3 12:32 0305221232023004.rap
-rw-r--r-- 1 maxel prolib 346 May  3 12:32 0305221232025164.rap
-rw-r--r-- 1 maxel prolib 342 May  3 12:32 0305221232026760.rap

.....

Nazwy plików zawierają datę i godzinę wysłania rewersu.

Np.  0305221232026760.rap   to rewers wysłany 3.05.2022 o godz. 12:32

Końcowa część nazwy jest pseudolosowa.

Po zapisaniu rewersu do pliku procedura batch-rewersy.p wywołuje dla każdego z rewersów odpowiedni skrypt obsługujący daną drukarkę. Dany rewers jest wiązany z określoną drukarką poprzez parę Znak Miejsca i Lokalizacja. To powiązania możemy skonfigurować w module Administrator  w opcji Ustawienia/Wydruki rewersów.

Samą drukarkę definiujemy w module Administrator w opcji Ustawienia/Drukarki i może ona wyglądać następująco:

Skrypt /prolib/druk/rew2mail przygotowuje Inżynier systemowy w oparciu o skrypt wzorcowy w którym modyfikuje początek:

Skrypt /prolib/druk/rew2mail zapisuje plik rewersu z katalogu /prolib/tty/rap/ jako plik z mailem w katalogu /prolib/emailmax/in. Mail ten zawiera treść rewersu (wersja TXT i HTML). Nazwa tego maila zaczyna się od prefiksu emr

Istnieje wersja skryptu która wysyła dodatkowo plik rewersu jako załącznik. Po zapisaniu pliku z mailem następuje jego wysłania przez proces obsługujący mailera.

Drugi tryb wykorzystuje kolejkowanie. W tym trybie mamy skrypt /prolib/druk/r2m który jest odpowiednikiem rew2mail. Przykładowa definicja drukarki w systemie Prolib:

W tym przykładzie mamy zdefiniowaną kolejkę o nazwie filia1 i utworzone odpowiednie drzewo katalogów związanych z tą kolejką w /prolib/wrk/kolejki/filia1. Są tam katalogi do_druku, drukowane i wydrukowane. Proces wydruku rewersów (batch-rewersy.p) wywołuje skrypt /prolib/druk/r2m przekazując mu nazwę kolejki (filia1) i nazwę pliku z rewersem. Skrypt /prolib/druk/r2m przenosi plik z rewersem do katalogu kolejki /prolib/wrk/kolejki/filia1/do_druku gdzie rewers ten oczekuje na kolejny proces uruchamiany w mechanizmie crontab:

[root@cpd1-PROLIB-db-2019 prolib]# crontab -l -u maxel
......
0 8,12,16 * * *  /prolib/druk/wyslij_rewersy_mailem.sh filia1 >/dev/null 2>&1
....

W tym przykładzie codziennie w godzinach 8,12 i 16 jest uruchamiany skrypt wyslij_rewersy_mailem.sh który scala w jeden plik wszystkie pliki, które znajdzie w katalogu /prolib/wrk/kolejki/filia1/do_druku, przekształca go do postaci pliku z mailem i zapisuje do katalogu /prolib/emailmax/in. Z tego miejsca mail ten zostanie wysłany przez mailera.

Jak widać kolejkowanie pozwala na wysyłanie maili o określonych godzinach i w postaci jednego maila zawierającego wiele rewersów. Ten tryb sprawdzi się w przypadku gdy rewersów nie jest zbyt wiele.

W obu trybach możliwe jest zdefiniowanie wielu skryptów i kolejek i wysyłanie rewersów mailem np. dla wielu filii. Każda z filii może mieć osobną skrzynkę mailową.

Skrypty są przygotowywane przez inżynierów systemowych Sygnity.

Wydruki rewersów w systemie Prolib realizowane są najczęściej przy wykorzystaniu mechanizmu wydruków w systemie Linux. System ten nazywa się CUPS.

Mechanizm potrafi obsłużyć wiele drukarek, w różnych standardach. W przypadku chwilowego wyłączenia drukarki (np.na noc) CUPS przechowuje wydruki w kolejce. Zostaną one wznowione po ponownym włączeniu drukarki.

System CUPS niestety nie jest w stanie sobie poradzić gdy czasy wyłączenia drukarki są diametralnie różne. O ile wyłączenie na noc nie jest problemem to już długi weekend może spowodować trwałe zablokowanie drukarki.

Jeżeli po dłuższej przerwie drukarka nie chce wznowić drukowania należy sprawdzić jej stan.

W tym celu należy się zalogować na serwer z bazą danych jako root i wykonać następujące polecenie:

[root@cpd1-PROLIB-db-2019 ~]# lpstat -t
scheduler is running
no system default destination
device for rewers: lpd://10.57.6.134/rewers
rewers accepting requests since Wed 25 May 2022 12:54:59 PM CEST
printer rewers is idle.  enabled since Wed 25 May 2022 12:54:59 PM CEST
[root@cpd1-PROLIB-db-2019 ~]#

Powyższy przykład pokazuje poprawnie działającą drukarkę.

A tak wygląda drukarka która została zablokowana:

[root@cpd1-PROLIB-db-2019 ~]# lpstat -t
scheduler is running
no system default destination
device for rewers: lpd://10.57.6.134/rewers
rewers accepting requests since Fri 03 Jun 2022 11:40:32 AM CEST
printer rewers disabled since Fri 03 Jun 2022 11:40:32 AM CEST -
        Paused
[root@cpd1-PROLIB-db-2019 ~]#

Powodem zablokowania może być zbyt długi czas wyłączenia drukarki.

Aby ją odblokować należy wydać polecenie:

[root@cpd1-PROLIB-db-2019 ~]# cupsenable rewers
[root@cpd1-PROLIB-db-2019 ~]# lpstat -t
scheduler is running
no system default destination
device for rewers: lpd://10.57.6.134/rewers
rewers accepting requests since Fri 03 Jun 2022 11:43:52 AM CEST
printer rewers is idle.  enabled since Fri 03 Jun 2022 11:43:52 AM CEST
[root@cpd1-PROLIB-db-2019 ~]#

Ręczne odblokowywanie drukarki może być trochę uciążliwe. Dlatego w 2011 powstał skrypt który automatycznie pilnuje stanu drukarek i steruje ich blokadą i odblokowaniem. Skrypt nosi nazwę Strażnika drukarek i jest instalowany na życzenie Biblioteki przez Inżyniera systemowego SygnitySBS.

W skrócie działa on w następujący sposób. Jest wywoływany cyklicznie, zazwyczaj co 15 minut i sprawdza stan drukarek wg. zadanej listy. Dla każdej drukarki porównuje jej stan pokazywany przez lpstat -t ze stanem faktycznym tzn. czy drukarka jest widoczna na sieci. Wykorzystuje do tego celu polecenie ping. Jeżeli stan się zmienił tzn. drukarka została włączona lub wyłączona to wykorzystując polecenia cupsdisable lub cupsenable steruje jej kolejką. Zablokowanie kolejki powoduje, że wydruki nadal będą trafiały do kolejki ale gdy drukarka jest wyłączona to będą tam cierpliwie czekały na jej włączenie. Ponieważ skrypt jest wywoływany co jakiś czas (np. 15 minut) to po włączeniu drukarki należy odczekać jakiś czas (maksymalnie 15 minut) i drukarka powinna zacząć ponownie drukować.

Ponieważ skrypt wykorzystuje do sprawdzenia stanu drukarki polecenie ping to należy pamiętać, że tak naprawdę sprawdzany jest stan wyłączony/włączony PRINT SERWERA a nie drukarki!. Aby zapobiec  problemom należy zawsze razem z drukarką wyłączać Print serwer. Najlepiej jest gdy oba urządzenia są zasilane ze wspólnej listwy zasilającej (Accar). Oczywiście gdy print serwer jest wbudowany w drukarkę ten problem nie występuje.

W Prolibie od wersji 2016.1.00 pojawił się mechanizm prezentacji logów i alarmów. Umożliwia on podgląd logów tworzonych przez procedury działające na serwerze bazy danych. Oprócz zwykłych logów mogą się tam pojawić tzw. alarmy.

Alarm jest krótką informacją wpisywaną do bazy danych informującą o jakimś zdarzeniu, które sygnalizuje nieprawidłowości w działaniu serwera bazy danych. Alarmy są wyświetlane wybranym operatorom w systemie Prolib podczas logowania.

Do okienka podglądu logów i alarmów możemy wejść wybierając w menu głównym Proliba opcję Operator/Lista logów.

Jeżeli opcja jest nieaktywna to należy skonfigurować ten mechanizm: https://help.prolib.pl/faqs/jak-skonfigurowa%C4%87-mechanizm-podgl%C4%85du-log%C3%B3w-i-alarm%C3%B3w

W procedurze wyświetlającej logi możemy:

- wybrać typ wyświetlanych wpisów (wszystkie, tylko logi zwykłe albo tylko alarmy)

- zawęzić listę logów według początku etykiety

- wskazać jeden z wybranych logów i wyświetlić jego treść

- usunąć log, skasować znacznik alarmu lub zapisać log do pliku

W dolnej części okienka wyświetlana jest treść logu.

Gdy podczas logowania pojawi się to okienko należy odczytać czego dotyczy alarm lub alarmy. Należy w tym celu wyświetlić treść alarmów. Po ich odczytaniu prosimy zgłosić uwagę do SOS lub telefonicznie skontaktować się z Inżynierem systemowym SygnitySBS, który dokładnie sprawdzi przyczynę.

Alarmy mogą być sygnalizowane z wielu powodów:

Błąd kopii bazy danych (blad_kopii_bazy)

Bardzo ważny alarm. Świadczy o tym że nie udało się wykonać poprawnie kopii bazy danych. Prosimy absolutnie go nie ignorować tylko jak najszybciej zgłosić uwagę do SOS

Zabicie zawieszonego procesu akt_lkhw (akt_lkhw_kill)

Alarm sygnalizuje, że poprzednie wywołanie procedury aktualizacji CKHW zawiesiło się i proces został skasowany aby nowy proces mógł dokończyć aktualizację.

Zabicie zawieszonego procesu akt_rek_bibl (akt_rek_kill)

Alarm podobny do poprzedniego (dotyczy innej procedury) ale wymaga przeanalizowania czy skasowany proces nie wymaga powtórzenia.

Przekroczenie granicznych rozmiarów dla plików bazy danych (alarm extendy)

Wymagana będzie interwencja Inżyniera systemowego SygnitySBS i przeładowania bazy danych do większych plików. Innym powodem może być zbyt duży plik z transakcjami który należy skrócić.

Przepełnienie dysku (dysk)

Jeden z dysków logicznych (filesystem) jest zapełniony więcej jak 90%. Należy skasować niepotrzebne pliki, skrócić logi itp.

Ten alarm jest często powiązany z alarmem dotyczącym kopii bezpieczeństwa.

Problemy z mailerem (mailer)

Alarm sygnalizowany gdy danego dnia nie udało się wysłać żadnego maila - wszystkie trafiły do katalogu z błędami. Może to świadczyć o tym że coś zmieniło się w konfiguracji serwera pocztowego (adres, protokół, hasło) albo serwer pocztowy uległ awarii.

Proces mailera nie był uruchamiany od ponad 6 godzin (mailer_hb)

Problem dotyczy lokalnego mechanizmu wysyłania maili albo w kolejce jest bardzo dużo maili i ich wysyłka trwa już wiele godzin.

Błędne adresy emailowe (bledy_email)

To zdarzenie nie jest traktowane jako alarm ale zwykły log. W treści pojawią się imiona, nazwiska, identyfikatory oraz adresy mailowe czytelników do których nie udało się wysłać maila. Częstym powodem jest literówka w adresie email, którą wystarczy poprawić. Niestety niewysłane maile nie są automatycznie powtarzane.

Zbyt długie działanie procesu aktualizacji SOLR (solr_hb)

Ten alarm może się pojawić w bibliotece która ma Integro. Świadczy o tym, że kolejka ze zmianami, które są przesyłane do bazy danych SOLR (Integro) jest bardzo długa. Może się to zdarzyć po dużych zmianach w bazie. Należy zgłosić problem w SOS a wtedy Inżynier systemowy SygnitySBS sprawdzi stan kolejki. Często wystarczy cierpliwie poczekać aż kolejka sama się rozładuje. Niemniej ten alarm może też świadczyć o problemach które będą wymagały interwencji.

W kolejce procesu solr-update są zaległe pliki (solr_kolejka)

Alarm także dotyczący procesu synchronizacji Prolib->Integro. Wymaga sprawdzenia kolejki ponieważ zostały w niej znalezione zgubione pliki.

Błąd w konfiguracji wydruku rewersów (batch-rewersy)

Zdecydowanie najczęściej zgłaszany alarm. Nie jest groźny. Sygnalizuje problem w konfiguracji wydruku rewersów (brakuje w niej obsługi jakiejś kombinacji Lokalizacja/Znak miejsca) lub dotyczy konkretnej książki (zazwyczaj źle określono jej przeznaczenie do wypożyczenia/do udostępniania). Dokładną przyczynę można określić na podstawie konkretnego rewersu lub rewersów które spowodowały ten alarm

Należy sprawdzić, czy w systemie są jakieś zawieszone sesje. Należy to zrobić za pomocą narzędzia Open Edge Monitor: /prolib/maxware/bin/prolib monitor. W tym narzędziu należy wybrać opcję 8 - Shut Down Database.

Ta opcja nie oznacza natychmiastowego wyłączenia bazy danych. Pojawi się lista, na której należy sprawdzić daty nawiązanych sesji. Jeśli data wskazuje, że sesja jest zawieszona (np. działa 3 miesiące) wybrać 1 - disconnect user.

Kliknij aby pobrać instrukcję.

W przypadku wystąpienia problemów z podłączeniem się do bazy danych należy sprawdzić czy jest ona PRAWIDŁOWO uruchomiona. Baza danych powinna być uruchamiana wraz z uruchomieniem serwera bazy ale czasami zdarza się, że z powodu różnych błędów baza nie zostanie poprawnie uruchomiona. Aby sprawdzić stan bazy należy zalogować się na serwer bazy danych jako użytkownik root i wejść do katalogu /prolib/db

W gdy baza danych działa powinien tam być plik prolib.lk:

[root@prolib2 db]# ll *.lk
-r--r--r-- 1 root root 265 04-25 15:55 prolib.lk

Samo istnienie pliku jeszcze nie daje gwarancji poprawnego działania bazy bo mogło dojść do sytuacji (dosyć częstej), że serwer został gwałtownie wyłączony i baza danych nie została poprawnie zamknięta. Wtedy mimo że plik prolib.lk istnieje to baza nie działa. Taką sytuację wykryjemy gdy będziemy próbowali uruchomić program monitora bazy Progress:

[root@prolib2 db]# /prolib/maxware/bin/prolib monitor

Gdy baza działa poprawnie to ukaże nam się główny ekran programu monitor (/prolib/progress/bin/promon):

Po sprawdzeniu że baza działa, wychodzimy z programu monitor wykorzystując opcję Q

Awaria zasilania serwera z bazą danych, a po włączeniu serwera i włączeniu klienta graficznego otrzymujemy komunikat
"Nie można połączyć się z serwerem bazy prolib, błąd 0.(1432)"

Logujemy się na serwer z bazą danych i wykonujemy poniższe punkty

1. Sprawdzić czy na serwerze nasłuchuje port 2001 (netstat -an | grep 2001) jeżeli nie

2. Sprawdzić czy w katalogach /prolib/db/ znajduje się plik prolib.lk jeżeli tak

3. Usunąć plik prolib.lk (rm prolib.lk)

4. Uruchomić proliba ponownie (systemctl start prolib)

Brak możliwości zalogowania się do systemu PROLIB 

1. Sprawdzamy czy jest możliwość zalogowania się na innych stacjach roboczych do systemu Prolib 
1a Tak można się zalogować do na innych stacjach roboczych do systemu Prolib
    Na stacji gdzie nie działa sprawdzamy plik c:/prolib/conf/prolibm21.pf w pliku tym sprawdzamy czy parametry podłączeniowe są zgodne z serwerem
    
    -db prolib (nazwa bazy danych)
    -H 172.168.10.5 (adres ip serwera na którym postawiona jest baza danych proliba)
    -S 2001 (port na którym baza danych działa)
    
2 Gdy problem wystepuje na wszystkich stacjach roboczych logujemy się na serwer z bazą danych i sprawdzamy ilość wolnego miejsca na dyskach 
    df -h

    Katalog głowny / lub katalog /prolib musza posiadać wolne miejsce 
    
3. Sprawdzić czy na serwerze nasłuchuje port 2001 (netstat -an | grep 2001) jeżeli nie 
3a. Sprawdzić czy w katalogach /prolib/db/ znajduje sie plik prolib.lk jeżeli tak 
3b. Usunąć plik prolib.lk (rm prolib.lk)
3c. Uruchomić Proliba ponownie (systemctl start prolib)

4. Sprawdzić czy na serwerze nasłuchuje port 2001 (netstat -an | grep 2001) jeżeli tak 
4a. Sprawdzić czy w katalogach /prolib/db/ znajduje sie plik prolib.lk jeżeli tak
4b. Sprawdzamy czy ostatni plik prolib.b* (b1, b2 itd) nie przekroczył wartości 2GB
4c. Tak samo sprawdzamy czy ostatni plik prolib_131.d* (d1, d2,itd ) nie przekroczyły wartości 2GB
4d. Jeżeli któreś z powyższych plików b* lub d* przekroczyły wartość 2GB proszę zgłosić uwagę systemie sos.prolib.pl w celu zwiększenia ilości extendów.
 

Kopię bezpieczeństwa bazy danych oraz wybranych katalogów aplikacji Prolib wykonuje skrypt /prolib/maxware/bin/kopia

W niektórych instalacjach skrypt ten może mieć inną nazwę (backup, kopia.sh)

Skrypt ten jest wykonywany cyklicznie, zazwyczaj wieczorem. Wywoływany jest w mechanizmie crontab dla użytkownika root.

Aby sprawdzić o której jest wywoływany należy zalogować się na serwer bazy danych jako root i wywołać:

[root@cpd1-PROLIB-db-2019 kopia]# crontab -l
00 22 * * 1,2,3,4,5 /prolib/maxware/bin/kopia >/dev/null 2>&1
1 0 * * 0 /prolib/maxware/bin/czysc_logi_tomcata.sh >/dev/null 2>&1
[root@cpd1-PROLIB-db-2019 kopia]#

W tym przykładzie kopia wykonywana jest o godzinie 22:00 od poniedziałku do piątku (pole 1,2,3,4,5)

Zazwyczaj kopia wykonywana jest do katalogu /prolib/kopia. W niektórych instalacjach może to być inny katalog. Sprawdzić to można w samym skrypcie:

#!/bin/bash
# Kopia bezpieczenstwa baz i aplikacji PROLIB

KOPIE=/prolib/kopia ; export KOPIE
LOG=$KOPIE/kopia.log ; export LOG

echo ================================================================ >$LOG
date >>$LOG

cd $KOPIE
[root@cpd1-PROLIB-db-2019 kopia]#

Na początku skryptu ustawiany jest katalog oraz plik logu. Dalej wykonywana jest kopia bazy danych oraz kopie poszczególnych katalogów aplikacji. Przykładowo:

# kopie baz
/prolib/maxware/bin/prolib zbackup >>$LOG 2>&1

# kopia aplikacji
cd /prolib
echo tty---------------------- >>$LOG
tar -czpf kopia/tty.tgz prolib2* tty 2>>$LOG
tar -tzpf kopia/tty.tgz >/dev/null 2>>$LOG

echo maxware------------------ >>$LOG
tar -czpf kopia/maxware.tgz maxware 2>>$LOG
tar -tzpf kopia/maxware.tgz >/dev/null 2>>$LOG

Przedstawiony fragment skryptu wykonuje kopię bazy danych (z kompresją przy pomocy gzip) także kopie katalogów /prolib/prolib2* /prolib/tty oraz /prolib/maxware.  Wykonywane są także kopie innych katalogów (/prolib/emailmax itp.). W niektórych instalacjach (zazwyczaj tam gdzie jest OpacWWW) kopiowany jest jeszcze plik z kopią okładek (z serwera OpacWWW przy pomocy wget).

W dalszej części skryptu pliki mogą być następnie kopiowane na zewnętrzny dysk (np. dysk sieciowy).

Skrypt /prolib/maxware/bin/kopia można uruchomić w każdej chwili (pamiętając że NADPISZE on poprzednią kopię). Należy go uruchamiać będąc zalogowanym jako użytkownik root. W niektórych instalacjach gdy jest dużo wolnego miejsca na dysku przechowywane są kopie bazy danych z kilku dni (zazwyczaj z ostatniego tygodnia). Katalog /prolib/kopia wygląda wtedy tak:

[maxel@prolib ~]$ ll /prolib/kopia/
razem 8759412
-rw-r--r--. 1 root root    4757380 05-19 21:12 emailmax.tgz
-rw-r--r--  1 root root   11423188 05-19 21:12 etc.tgz
-rw-r--r--. 1 root root    2225500 05-19 21:12 kopia.log
-rw-r--r--. 1 root root     199307 05-19 21:12 maxware.tgz
-rw-r--r--  1 root root 1217652191 05-15 21:03 prolib0.bkup.gz
-rw-r--r--  1 root root 1221018727 05-16 21:03 prolib1.bkup.gz
-rw-r--r--  1 root root 1218032448 05-17 21:03 prolib2.bkup.gz
-rw-r--r--  1 root root 1220962148 05-18 21:03 prolib3.bkup.gz
-rw-r--r--  1 root root 1220889078 05-19 21:04 prolib4.bkup.gz
-rw-r--r--  1 root root 1217405168 05-13 21:03 prolib5.bkup.gz
-rw-r--r--  1 root root 1216185468 05-14 21:03 prolib6.bkup.gz
-rw-r--r--. 1 root root  418818944 05-19 21:12 tty.tgz
[maxel@prolib ~]$

Najstarszą kopię bazy danych mamy z dnia 13.05 (prolib5.bkup.gz) a najnowszą z 19.05 (prolib4.bkup.gz).

W katalogu /prolib/kopia możemy znaleźć także plik logu, zazwyczaj o nazwie kopia.log

Należy go co jakiś czas przeglądać czy nie są sygnalizowane jakieś błędy.

Wiele problemów z kopią bezpieczeństwa jest sygnalizowanych jako alarm w systemie Prolib.

Kopia bezpieczeństwa bazy danych wykonywana jest przy pomocy skryptu /prolib/maxware/bin/prolib z opcją backup lub zbackup (kopia zostanie dodatkowo skompresowana przy pomocy gzip'a). Skrypt ten jest wywoływany w skrypcie wykonującym kopię /prolib/maxware/bin/kopia

W opcjach backup/zbackup oprócz zrobienia backupu wykonywana jest także weryfikacja.

Sprawdzenie poprawności należy rozpocząć od logu /prolib/kopia/kopia.log

Należy znaleźć wpis dotyczący backupu z określonego dnia i przejrzeć fragment dotyczący robienia backupu i jego weryfikacji:

czw, 19 maj 2022, 21:00:01 CEST
------------------------------------------------------------------------
| SygnityBS  S.A.                                                      |
| obsluga baz i aplikacji: Prolib, Promax, CKHW, LKHW, OpacWWW, ProWEB |
------------------------------------------------------------------------

1657979 aktywnych bloków z 2213853 bloków ³±cznie w /prolib/db/prolib zostanie zrzuconych. (6686)
98304 bloków BI zostanie zrzuconych. (6688)
Szacuje siê, ¿e kopia archiwalna zajmie 6.7 GBytes no¶nika. (9285)
Odtworzenie wymaga³oby prawdopodobnie 1759866 bloków db, u¿ywaj±c 6.7 GBytes pamiêci no¶nika. (9286)
Backed up 222457 db blocks in 00:00:10
Backed up 412885 db blocks in 00:00:20
Backed up 480882 db blocks in 00:00:30

....

Backed up 1604948 db blocks in 00:04:10
Backed up 1653639 db blocks in 00:04:20
Backed up 1690747 db blocks in 00:04:22
Zapisano ³±cznie 32813 bloków zapasowych, u¿ywaj±c 4.3 GBytes pamiêci no¶nika. (13625)

Wykonanie kopii archiwalnej zakoñczone. (3740)

To jest full kawa³ek kopii z serii /prolib/db/prolib.db kawa³ków. (6759)
Data wykonania kopii: Thu May 19 21:00:01 2022. (6760)
Rozmiar bloku wynosi 4096. (6994)
Ten kawa³ek kopii przeszed³ pomy¶lnie czê¶ciow± weryfikacjê. (6765)
Rozpoczê³a siê faza weryfikacji kopii. (3751)
Verified 0 db blocks in 00:00:00
Verified 679157 db blocks in 00:00:10
Verified 1384654 db blocks in 00:00:20
Verified 1690747 db blocks in 00:00:23
Kopia /prolib/db/prolib.db przesz³a pomy¶lnie przez weryfikacjê. (6758)

--gzip-----------------
--gunzip-t-------------

Po zakończeniu weryfikacji wykonywana jest kompresja i weryfikacja kompresji (przy pomocy gzip'a)

Aby dodatkowo sprawdzić czy kopia bazy jest poprawna (np. po skopiowaniu jej) możemy wykorzystać narzędzie Progress'a.

W pierwszym kroku gdy kopia bazy jest skompresowana musimy ją rozpakować (UWAGA na ilość wolnego miejsca na dysku!):

[maxel@prolib kopia]$ cd /prolib/kopia
[maxel@prolib kopia]$ gunzip prolib.bkup.gz

Po rozpakowaniu należy dodać do ścieżki PATH katalog z narzędziami Progress'a:

[maxel@prolib kopia]$ PATH=/prolib/progress/bin:$PATH

i uruchomić weryfikację kopii bezpieczeństwa:

[maxel@prolib kopia]$ prorest /dev/null prolib.bkup -vp -verbose

Kopię bazy danych możemy wykonać w dowolnym momencie, zarówno przy włączonej jaki i wyłączonej bazie danych. Po pierwsze musimy sprawdzić czy mamy wystarczającą ilość wolnego miejsca na dysku (lub na określonym filesystemie).

Następnie dodajemy do ścieżki PATH katalog z narzędziami Progress'a:

[maxel@prolib kopia]$ PATH=/prolib/progress/bin:$PATH

Gdy baza danych jest włączona używamy dodatkowo parametru online w poleceniu probkup:

[root@cpd1-PROLIB-db-2019 tmp]# probkup online  /prolib/db/prolib /prolib/tmp/prolib.bkup

Gdy baza jest wyłączona pomijamy ten parametr:

[root@cpd1-PROLIB-db-2019 tmp]# probkup /prolib/db/prolib /prolib/tmp/prolib.bkup

W obu przypadkach utworzymy kopię bazy danych /prolib/db/prolib w pliku /prolib/tmp/prolib.bkup

Możemy także wykonać kopię bazy danych korzystając ze skryptu /prolib/maxware/bin/prolib

Jednak w tym przypadku kopia będzie zawsze wykonywana w katalogu /prolib/kopia

Wywołanie skryptu:

[root@cpd1-PROLIB-db-2019 tmp]# /prolib/maxware/bin/prolib backup

lub

[root@cpd1-PROLIB-db-2019 tmp]# /prolib/maxware/bin/prolib zbackup

gdy chcemy zrobić kopię z kompresją gzip.

Skrypt /prolib/maxware/bin/prolib automatycznie rozpoznaje czy baza jest włączona czy wyłączona.

Serwery pocztowe Google, z definicji są silnie zabezpieczone przed nieautoryzowanymi próbami logowania się do serwerów, poprzez niezaufane urządzenia. Dlatego też, bez włączenia możliwości logowania się aplikacji firm trzecich z którymi google nie współpracuje, próby autoryzacji będą kończyły się niepowodzeniem. Istnieją jednak dwie możliwości udostępnienia skrzynki pocztowej dla powiadomień wysyłanych do czytelników w systemie Prolib. Pełna instrukcja konfiguracji konta Google znajduje się pod tym linkiem.

Służą do tego polecenia w Centos 7 lub Oracle Linux :

systemctrl stop biblioteka

systemctrl stop biblioteka

Służą do tego polecenia w Centos 6: 

/etc/init.d/prolib stop
/etc/init.d/prolib start

lub

/prolib/maxware/bin/prolib stop
/prolib/maxware/bin/prolib start

Pliki bazy danych znajdują się na serwerze bazy danych, zazwyczaj w katalogu /prolib/db. Znajduje się tam kilka lub kilkanaście  plików zawierających dane, pliki logów oraz pliki pomocnicze. Przykładowa zawartość tego katalogu może wyglądać następująco:

Pliki prolib_131.d... zawierają dane, plik prolib.b1 to plik z transakcjami, plik prolib.d1 zawiera informacje o strukturze bazy (jakie są tabele i indeksy), pliki prolib.db i prolib.ds to pliki systemowe bazy Progress. Pliki prolib.lg i prolib.lic to pliki logów, pierwszy to log główny bazy danych a drugi zawiera informacje związane z wykorzystaniem licencji. Plik prolib.st zawiera informacje o strukturze fizycznej bazy (tzw. extendy). Plik prolib.lk to plik znacznikowy sygnalizujący stan bazy danych. Widoczne w katalogu pliki delta.df oraz idx.log to pliki pomocnicze utworzone podczas reinstalacji.

Z wymienionych plików czytelną zawartość ma przede wszystkim plik logu (prolib.lg). Jest to plik tekstowy który można przeglądać narzędziami typu vi, more itp.

Zawiera on wpisy dotyczące zdarzeń na bazie danych: uruchomienie, zatrzymanie, logowanie się operatora, podłączenie klienta lokalnego, przeindeksowanie bazy oraz błędy i ostrzeżenia.

Na serwerze z katalogiem Integro  by zatrzymać katalog służą do tego polecenia : 

systemctl stop nginx

systemctl start nginx

Jeżeli po włączeniu strony Integro dostajemy informacje o Braku dostępu do ogólnego serwisu obsługi opaca

  systemctl status tomcat

Zrestartować brokery poleceniem:  

  systemctl stop tomcat

  systemctl start tomcat

Jeżeli po włączeniu strony Integro dostajemy informacje SoapFault

  /prolib/wrk/ prolibws.broker.000001.log

Zrestartować brokery poleceniem:  

/prolib/progress/bin/asbman -i prolibws –stop

/prolib/progress/bin/asbman -i prolibws –start

Jeżeli podczas wyszukiwania w Integro dostajemy informacje kod błędu 500

  systemctl status solr

Zrestartować usługi SOLR poleceniem:  

  systemctl stop solr

  systemctl start solr

Usuniecie plik log w /prolib/db/prolib.lg jeżeli jest bardzo duży

1. Wchodzimy w katalog /prolib/db/

2. Wywołujemy polecenie /prolib/progress/bin/prolog -online prolib w tym momencie log jest skracany przy uruchomionej bazie  i zapisywany od nowa 

Wydruki rewersów (zamówień czytelników) mogą być drukowane na wiele różnych sposobów. Oprócz wielu typów drukarek jak drukarki igłowe czy laserowe mogą być także wysyłane w postaci maili. W przypadku wydruków na drukarkach należy w pierwszej kolejności sprawdzić czy nie została zablokowana kolejka wydruków w systemie Linux.

Należy w tym celu zalogować się na serwer bazy danych i wywołać:

[root@ProlibDB ~]# lpstat -t
scheduler is running
no system default destination
device for magazyn: lpd://172.16.68.94/lpd
magazyn accepting requests since Wed 25 May 2022 11:20:02 AM CEST
printer magazyn is idle.  enabled since Wed 25 May 2022 11:20:02 AM CEST

W podanym przykładzie w systemie Linux jest zdefiniowana jedna drukarka o nazwie magazyn. Mechanizm wydruku CUPS działa (scheduler is running). Jeżeli drukarek jest więcej należy określić tę którą chcemy sprawdzić i wywołać polecenie filtrując dane poleceniem grep z nazwą drukarki (magazyn):

[root@ProlibDB ~]# lpstat -t | grep magazyn
device for magazyn: lpd://192.168.1.6/lpd
magazyn accepting requests since Wed 25 May 2022 11:20:02 AM CEST
printer magazyn is idle.  enabled since Wed 25 May 2022 11:20:02 AM CEST
[root@ProlibDB ~]#

Uzyskamy wtedy informacje o konkretnej drukarce. Najważniejsza jest informacja o tym czy drukarka działa czy została zablokowana. Podaje ją linia rozpoczynająca się słowem printer. Poniżej jest przykład drukarki działającej i zablokowanej.

printer oki1 is idle.  enabled since sob, 19 lut 2022, 08:45:33
printer oki2 disabled since sob, 28 kwi 2012, 11:18:48 -
        Printer not responding!

W przypadku drukarki zablokowanej możemy ją odblokować poleceniem cupsenable. Jednak najpierw powinniśmy się upewnić że drukarka jest włączona i widoczna z serwera.

Wtedy należy wywołać polecenie:

[root@ProlibDB ~]# cupsenable oki2

Jeżeli w kolejce czekają wydruki to rozpocznie się ich wysyłanie do drukarki.

Może się zdarzyć, że kolejka zostanie zablokowana jakimś wydrukiem który w niej utknął. Po wydaniu polecenia:

[root@ProlibDB ~]# lpstat -t

za informacjami o kolejkach i drukarkach zobaczymy listę wydruków które znajdują się w kolejce.

Każda pozycja ma swój identyfikator składający się z nazwy kolejki i kolejnego numeru wydruku.

[root@cpd1-PROLIB-db-2019 ~]# lpstat -t
scheduler is running
no system default destination
device for rewers: lpd://10.57.6.134/rewers
rewers accepting requests since Wed 25 May 2022 12:50:27 PM CEST
printer rewers now printing rewers-1.  enabled since Wed 25 May 2022 12:50:27 PM CEST
        The printer is in use.
rewers-1                root              1024   Wed 25 May 2022 12:50:27 PM CEST

W podanym przykładzie w kolejce znajduje się jeden wydruk o identyfikatorze rewers-1. Wydruk został wykonany 25 maja 2022. Aby go usunąć należy wydać polecenie:

[root@cpd1-PROLIB-db-2019 ~]# cancel rewers-1

Aby usunąć wszystkie wydruki z danej kolejki należy wywołać polecenie:

[root@cpd1-PROLIB-db-2019 ~]# cancel -a rewers

Jeżeli blokada drukarki będzie się powtarzać proponujemy zainstalowanie skryptu strażnika drukarek https://help.prolib.pl/faqs/jak-dzia%C5%82a-stra%C5%BCnik-drukarek

Mailer współpracujący z systemem Prolib ma możliwość ponownego wysłania maili znajdujących się w jednym z katalogów /prolib/emailmax/err*

Częstym powodem dla którego wiele maili trafiło do katalogów err* jest awaria serwera SMTP, zmiana jego konfiguracji lub hasła do autoryzacji.

Aby wysłać ponownie maile (ale tylko takie które NIE zostały wysłane) należy zalogować się na serwer z bazą danych jako użytkownik root, przelogować się na użytkownika maxel (UWAGA - ważne!) a następnie wywołać skrypt ponow_maile.sh:

[root@DB ~]# su - maxel
Last login: Wed May 25 15:21:24 CEST 2022 on pts/4
[maxel@DB ~]$ /prolib/emailmax/skrypty/unix/ponow_maile.sh

Ukaże się pytanie o datę początkową, następnie o datę końcową przedziału czasowego z którego chcemy wysłać maile oraz informacja ile znaleziono maili do ponownego wysłania:

==========================================================
Skrypt do ponownego wysylania maili

Podaj date poczatkowa dla maili (RRRR MM DD GG mm):>
  (0 - wyjscie z programu)
2022 5 23 5 0

Podaj date koncowa dla maili (RRRR MM DD GG mm):>
  (0 - wyjscie z programu)
2022 5 24 0 0
Znalazlem 5 maili
Czy wyslac je ponownie (t/n)?

Po wybraniu t maile z katalogów err* spełniające warunek wyszukiwania zostaną przeniesione do katalogu /prolib/emailmax/in. Przy najbliższym wywołaniu skryptu  /prolib/emailmax/skrypty/unix/wyslij.sh (z crontab'a) zostaną one wysłane.

UWAGA: gdy liczba maili do wysłania jest duża (setki czy tysiące) wysyłanie tych maili może trochę potrwać.

W podanym przykładzie wybraliśmy czas od 23.05.2022 5:00 do 24.05.2022 0:00. Program znalazł 5 maili.