Polecenie "migrate"

Pozwala na migrację konfiguracji lokalnych serwisów. Migracja oznacza wyznaczenie dla każdego serwisu szablonu konfiguracyjnego oraz detekcję różnic między bieżącą konfiguracją a szablonem konfiguracyjnym.

Dostępne są migracje konfiguracji:

• sowas - migracja konfiguracji dostępnych serwisów (przejęcie kontroli nad konfiguracją sowas.cfg)
• sowa2 - migracja konfiguracji zainstalowanych serwisów typu SOWA2 (przejęcie kontroli nad plikiem .inf, katalog.ini oraz index.py)
• sowasql - migracja konfiguracji zainstalowanych serwisów typu SOWASQL (przejęcie kontroli nad całym katalogiem etc/)

Składnia

sowizor migrate sowas [check|start] [--force]
sowizor migrate sowa2|sowasql
sowizor migrate <sid> [--force] [--nodelete] [--ignore-params|--generate-params] [--generate-services] [--use=schema=<hid>] [--override-records]

Migracja konfiguracji sowas

W systemach Linux instalowany jest moduł o nazwie "sowas". Konfiguracja katalogów SOWY przechowywana jest w pliku sowas.cfg. Podczas migracji sowizor przejmuje kontrolę nad tym plikiem - od momentu migracji jest on automatycznie generowany podczas wszelkich operacji na serwisach dokonywanych przy pomocy sowizora.

Migracja konfiguracji sowas jest obligatoryjna i należy ją przeprowadzić zaraz po instalacji sowizora.

Wywołanie polecenia z parametrem sowas lub sowas check - weryfikuje możliwość migracji ustawień (zwykle nie ma z tym problemu).

Wywołanie polecenia z parametrem sowas start - przeprowadza migrację konfiguracji. Od tego momentu serwisy są już pod kontrolą sowizora (nie ma potrzeby uruchamiania polecenia "scan").

Operację tę należy wykonać tylko raz. Jeśli z jakiegoś powodu zaistnieje konieczność jej powtórzenia, konieczne będzie podanie opcjonalnego atrybutu --force. Wymusi to ponowną migrację konfiguracji z pliku sowas.cfg.

Migracja konfiguracji serwisów SOWA2 i SOWASQL

Wydając polecenie z parametrem sowa2 lub sowasql można wyświetlić listę serwisów, potencjalnie nadających się do migracji.

Podając jako parametr identyfikator <sid> uruchamia się migrację serwisu (o ile jest to serwis SOWA2 lub SOWASQL).

Jest to zaawansowany, skomplikowany proces, który wymaga szczegółowej wiedzy na temat architektury systemu i sposobu jego konfiguracji. Z tego powodu wskazane jest przeprowadzanie tej operacji pod nadzorem pracowników firmy SOKRATES-software.

Proces ten dzieli się na fazę check (detekcja ustawień) i start (wykonanie migracji).

Etapy w fazie check

• detekcja schematu (schemat określa przeznaczenie serwisu, układ katalogu, dostępne rekordy i bazy aplikacji)
• detekcja używanych typów rekordów
• wykrycie różnic w konfiguracji pól logicznych rekordów SOWY2
• sprawdzenie poprawności parametrów systemu
• wykrycie używanych usług katalogu SOWY2 (detekcja m.in. formatów, zestawień, programów, indeksów, kryteriów itd.)
• sprawdzenie dostępności i poprawności struktur plików DBF (nie dotyczy wersji SQL)

Po zakończeniu fazy check, program dla każdego migrowanego serwisu wyświetli podsumowanie i możliwe dalsze kroki migracji. Możliwe są następujące statusy:

• Migracja już wykonana - oznacza to, że serwis został już wcześniej zmigrowany i nie ma potrzeby robić tego ponownie. Można to jednak wymusić podając opcjonalny argument --force.
• Migracja możliwa: katalog gotowy do automatycznej migracji
• Migracja możliwa: zalecana weryfikacja przez specjalistę - ten status wystąpi w przypadku stwierdzenia istotnych różnic np. w konfiguracji struktur pól logicznych rekordów SOWA2. Wymagana jest świadoma decyzja o aktualizacji tych struktur do wykrytego (lub zadeklarowanego) schematu konfiguracyjnego.
• Migracja niemożliwe: wymagana aktualizacja ręczna - ten status wystąpi w przypadku, gdy proces automatycznej detekcji ustawień napotkał na problemy wymagające ręcznej ingerencji. Jeśli operator programu nie wykona odpowiednich modyfikacji, wówczas migracja automatyczna nie będzie możliwa.
• Konieczność kontaktu z firmą SOKRATES-software - ten status oznacza, że napotkano serwis o konfiguracji wyjątkowo niestandardowej (której nie opisuje żaden dostępny szablon konfiguracyjny)

Rozwiązywanie problemów

W trakcie detekcji ustawień program może napotkać problemy wymagające podjęcia dodatkowych kroków lub decyzji przez operatora. Zwykle w tym momencie proces analizy jest przerywany i wyświetlana jest sugestia na temat możliwych sposobów rozwiązania problemów. Rozwiązać je można albo poprzez poprawienie bieżącej konfiguracji (i w ten sposób wyeliminowanie problemu) lub użycie sugerowanych opcji dodatkowych wywołania polecenia.

• Napotkano niepoprawne (nieznane) parametry w plikach parametry.inc oraz katalog.ini.
  Wszystkie dopuszczalne parametry są elementem pakietu z szablonami konfiguracyjnymi (serwer-sowa2-cfg). Zdarzają się sytuacje w których w migrowanym serwisie pojawi się parametr, którego definicji nie ma w szablonie. Zwykle jest to wynik błędu użytkownika (użycie niepoprawnej składni polecenia administracyjnego), niekiedy zaś jest to lokalny parametr stosowany tylko i wyłącznie w danej instalacji. W zależności od tego jakiego rodzaju jest ów nieznany parametr, należy użyć jednej z dostępnych opcji:
  --ignore-params - ignoruje nieznane parametry i kontynuuje migrację. Parametry te zostaną usunięte z konfiguracji serwisu.
  --generate-params - generuje lokalne definicje parametrów, a ich bieżącą wartość ustawia jako domyślną. Parametry te zostaną zachowane w konfiguracji serwisu.
• Napotkano niepoprawne (nieznane) serwisy/usługi w pliku .inf
  Wszystkie dopuszczalne w standardowych instalacjach serwisy/usługi są elementem pakietu z szablonami konfiguracyjnymi (serwer-sowa2-cfg). Dość częstym przypadkiem jest jednak definiowanie lokalnych serwisów (np. nietypowe zestawienia, programy, czy formaty wyświetlania lub indeksy). W większości przypadków właściwym rozwiązaniem tego problemu jest użycie opcji --generate-services. Dzięki temu wygenerowane zostaną lokalne definicje nietypowych serwisów i zostaną one zachowane w konfiguracji.
• Nie udało się określić schematu konfiguracyjnego dla cełego serwisu.
  Jest to rzadki przypadek, w którym nie udało się określić schematu dla migrowanego serwisu. W takiej sytuacji można wymusić użycie schematu o podanej nazwie, np.:
  --use-schema=marc21-akc - powoduje użycie schematu dla serwisu katalogu bibliotecznego w formacie MARC21 z akcesją dokumentów zwartych.
• Napotkano konflikt oznaczeń indeksów dla rekordów
  W takim przypadku zwykle konieczna jest fachowa ingerencja pracownika SOKRATES-software. Jednym z możliwych rozwiązań jest użycie opcji --override-records, która spowoduje zignorowanie konfliktu i zastosowanie oznaczeń zdefiniowanych w szablonach konfiguracyjnych. Należy używać tej opcji z dużą ostrożnością.

Etapy w fazie start

Serwis, który przejdzie przez etap check można ostatecznie zmigrować wywołując polecenie z parametrem start.

Migracja wykona następujące czynności:

• w razie konieczności zainstaluje i skonfiguruje moduł SMAILER
• wygeneruje i obejmie nadzorem plik katalog.ini (zlikwiduje to wszystkie dotychczasowe pliku .inc w katalogu bazy danych)
• wygeneruje i obejmie nadzorem plik index.py (stosowany do reindeksacji bazy danych w trybie offline)
• jeśli jest to wymagane - przeprowadzi migrację struktur plików DBF
• jeśli jest to wymagane - wykona reindeksację nowo utworzonych lub zmienionych plików DBF
• przeniesie konfigurację wysyłki poczty do modułu SMAILER
• wygeneruje lokalny wariant schematu służący do automatycznego generowania konfiguracji
• wygeneruje i obejmie nadzorem nowy plik konfiguracyjny .inf

Proces ten archiwizuje dotychczasowe ustawienia, dzięki czemu można w razie potrzeby odzyskać starą konfigurację. Domyślnie jest ona archiwizowana i usuwana. Można to zmienić dzięki opcji --nodelete - podanie jej spowoduje, że dotychczasowa konfiguracja nie zostanie usunięta, lecz tylko zostaną przemianowane pliki na rozszerzenie .old.