Instrukcja obsługi systemu dLibra 5.0 oraz dMuseion 1.0

Skip to end of metadata
Go to start of metadata

Instalacja serwera bazy danych Oracle i serwera systemu dLibra na tym samym komputerze


Podczas instalacji serwera bazy danych Oracle w domyślnej konfiguracji, w wersji 9.0, instalowana jest wirtualna maszyna Javy w wersji 1.3.1. Katalog bin tej instalacji Javy jest dodawany do zmiennej systemowej PATH. Z tego powodu próba uruchomienia serwera systemu dLibra kończy się niepowodzeniem - serwer powinien być uruchamiany w środowisku zgodnym z Java 1.5. Aby zapobiec takiej sytuacji, należy po instalacji serwera Oracle i maszyny wirtualne Javy w wersji zgodnej z 1.5, sprawdzić czy zmienna systemowa PATH wskazuje na katalog bin właściwej wersji Javy.

Podczas instalacji serwera bazy danych Oracle domyślnie instalowana jest również XML-owa baza danych (XDB). Domyślnie dostęp do niej odbywa się poprzez port 8080. Port ten jest również domyślnym portem dla wielu kontenerów serwletów - w tym proponowanego do wykorzystania w systemie dLibra kontenera Tomcat. Z tego powodu nie jest możliwe równoczesne działanie bazy XDB i kontenera Tomcat na jednym komputerze, jeżeli wykorzystywane są ich domyślne konfiguracje. Aby zmienić tą sytuację można zmodyfikować konfigurację Tomcata lub XDB.

Aby zmodyfikować port, którego używa Tomcat należy zmienić wartości 8080 występujące w pliku server.xml w podkatalogu conf katalogu, w którym zainstalowano Tomcata. Można je zmienić na przykład na wartość 80.

Natomiast aby zmodyfikować port używany przez XDB należy podłączyć się do bazy danych jako użytkownik SYSDBA i wydać następujące zapytania:

SQL>call dbms_xdb.cfg_update(updateXML(dbms_xdb.cfg_get(),
'/xdbconfig/sysconfig/protocolconfig/httpconfig/http-port/text()',8081))
/
SQL>commit;
SQL>exec dbms_xdb.cfg_refresh;

Niewłaściwe porównywanie znaków diakrytycznych w bazie MySQL


W przypadku instalacji systemu dLibra na bazie danych MySQL pojawia się problem dotyczący dodawania nowych wartości do opisu obiektów cyfrowych i poprawiania wartości już w opisie istniejących. Problem ten pojawia się, gdy próbujemy zmienić wartość bez znaków diakrytycznych na wartość takie znaki posiadającą np. "skora" na "skóra" lub gdy próbujemy dodać nową wartość, która różni się od innej wartości istniejącej już w systemie tylko znakami diakrytycznymi. Wyświetlany jest wówczas komunikat o błędzie, iż dodawana/zmieniona wartość już istnieje. Problem ten może dotyczyć również sytuacji, w której różnica sprowadza się tylko do wielkości liter (np. Koło i koło).

Błąd ten związany jest ze sposobem porównywania znaków przez bazę danych MySQL. Dla kodowania UTF-8, w którym znaki powinny być przechowywane w bazie danych, domyślnym sposobem porównywania znaków jest utf8_general_ci, który znaki diakrytyczne jak np. ä, ó traktuje tak samo jak odpowiednio a, o. Dlatego podczas sprawdzania, czy w bazie danych istnieje nowa wartość "skóra" zostaje znaleziona wartość "skora".

Rozwiązaniem tego problemu jest zmiana domyślnego sposobu porównywania znaków na binarny o nazwie utf8_bin. Można tego dokonać na poziomie całej bazy danych, tabeli czy nawet pojedynczej kolumny. Szczegółowe informacje na ten temat znajdują się na stronie Specifying Character Sets and Collations instrukcji bazy danych MySQL.

W przypadku opisanego powyżej problemu podstawowym rozwiązaniem jest zmiana sposobu porównywania znaków dla tabeli MET_ATTRIBUTE_VALUES. Polecenie zmiany sposobu porównywania powinno wyglądać następująco:

ALTER TABLE nazwa_tabeli CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;

Uwaga!

Icon

W przypadku przeprowadzania opisanej powyżej operacji na bazie danych już po instalacji, zaleca się wcześniejsze wykonanie backup-u bazy danych.

Problemy z połączeniem się Aplikacją Redaktora do serwera dLibra działającego w konfiguracji sieciowej z NAT

Konfiguracja sieciowa z NAT (lub np. z połączeniami tunelowymi SSH) to sytuacja, w której serwer dLibra nasłuchuje na swoich portach (standardowo 10051 i 10052) na adresie prywatnym w sieci wewnętrznej, a klient korzystający z Aplikacji Redaktora do podłączania się używa adresu publicznego (ogólnodostępnego adresu internetowego). Taka konfiguracja serwera wymaga odpowiedniego skonfigurowania profilu logowania w Aplikacji Redaktora (patrz: 02. Instalacja, uruchamianie i logowanie).

Jeżeli w takiej sytuacji występują problemy z podłączeniem się Aplikacji Redaktora do serwera dLibra, zalecane jest wykonanie następujących czynności w celu ułatwienia zdiagnozowania przyczyny problemu:

1) Weryfikacja poprawności konfiguracji NAT - jeżeli mechanizm NAT na serwerze jest skonfigurowany poprawnie, to połączenie na port 10051 i 10052 na adresie publicznym powinno być w praktyce połączeniem na te porty na adres prywatny. Aby sprawdzić czy to działa należy upewnić się, czy po wykonaniu na maszynie klienta polecenia

telnet <adres publiczny> 10051
telnet <adres publiczny> 10052

(lub podobnego, w zależności od systemu operacyjnego) połączenia udają się jeżeli serwer dLibry jest włączony i nasłuchuje na tych samych portach na adresie prywatnym oraz połączenia nie udają się, jeżeli serwer dLibry jest wyłączony.

Jeżeli ten test się nie powiedzie, to problem najprawdopodobniej leży w konfiguracji NAT na serwerze (na poziomie konfiguracji w systemie operacyjnym itp.) i nie ma to związku z systemem dLibra. Inna prawdopodobna przyczyna to blokowanie połączeń na systemach typu firewall.

2) *Weryfikacja poprawności konfiguracji profilu logowania Aplikacji Redaktora" - jeżeli powyższy test się powiedzie, to należy w konfiguracji profilu logowania w Aplikacji Redaktora (rys. 2 od góry na stronie 02. Instalacja, uruchamianie i logowanie) w polu host podać adres publiczny, zaznaczyć "Używaj konfiguracji NAT" i wpisać również adres publiczny w pole "Domyślny serwer".

Jeżeli przy takiej konfiguracji logowanie nadal nie powiedzie się, prosimy o przesłanie na adres pomocy technicznej zrzutu ekranu z konfiguracją niedziałajacego profilu logowania w Aplikacji Redaktora oraz zrzutu ekranu z objawami zachowania się Aplikacji Redaktora przy próbie logowania.

  • No labels