Wsparcie Techniczne

UNIX
Sugerowaną metodą jest wykorzystanie skryptu (<sas_config>/Levx/sas.servers), który służy do uruchamiania i zatrzymywania wszystkich procesów środowiska działających na danej maszynie w odpowiedniej kolejności.
Uruchomienie:   ./sas.servers start
Zatrzymanie:   ./sas.servers stop

Każdy z procesów można również wystartować ręcznie. Dla serwera metadanych skrypt startujący znajduje się w katalogu serwera (/Levx/SASMeta/MetadataServer).

Uruchomienie serwera:   ./MetadataServer.sh start
Zatrzymanie serwera:   ./MetadataServer.sh stop

Windows
Na Windows najczęściej procesy działające w ramach środowiska SAS są zainstalowane jako usługi. Wystarczy więc w oknie Usług uruchomić proces o domyślnej nazwie SAS [nazwa_katalogu-Levx] SASMeta - Metadata Server. Skrót do skryptu startującego serwera metadanych może być również dostępny w menu Start -> Programy -> SAS. Sam skrypt znajduje się w katalogu serwera metadanych (<sasconfig>\Levx\SASMeta\MetadataServer).
Uruchomienie serwera:   MetadataServer.bat start
Zatrzymanie serwera:   MetadataServer.bat stop

UNIX
Do sprawdzenia, czy serwer metadanych działa można wykorzystać skrypt startujący i zatrzymujący wszystkie procesy środowiska SAS (<sasconfig>/Levx/sas.servers):./sas.servers status
Można również wykorzystać skrypt z katalogu serwera metadanych (<sasconfig>/Lev/SASMeta/MetadataServer): ./MetadataServer.sh status

Windows
Jeżeli serwer metadanych działa jako usługa, status serwera wystarczy sprawdzić w oknie Usług. Innym sposobem jest wykorzystanie skryptu z katalogu serwera metadanych (<sasconfig>\Levx\SASMeta\MetadataServer):
MetadataServer.bat status

Na obu platformach można również wykorzystać procedurę METAOPERATE, uruchamiając ją bezpośrednio z SASa (SAS Foundation nie musi być uruchomione na tej samej maszynie co serwer metadanych):

PROC METAOPERATE SERVER="host-name"
PORT= port-number
USERID= "userid"
PASSWORD="password"
ACTION=STATUS;
RUN;<

W celu sprawdzenia, czy SAS startuje na danym koncie, należy zalogować się na konto tego użytkownika i uruchomić SASa z katalogu instalacyjnego <sashome>\SASFoundation\9.4\sas.exe lub <sashome>/SASFoundation/9.4/sas.
UNIX
Do przelogowania na innego użytkownika można wykorzystać polecenie
su nazwa_użytkownika
Windows
SASa można uruchomić w imieniu innego użytkownika za pomocą polecenie runas: runas /user:nazwa_użytkownika <sashome>\SASFoundation\9.4\sas.exe

Po wygaśnięciu licencji SAS przestaje działać. Wszystkie informacje o licencjach, w tym kroki, które należy wykonać przy aktualizacji licencji, znajdują się na stronach License Assistance

Serwer metadanych korzysta z plików konfiguracyjnych, które znajdują się w katalogu serwera metadanych (<sasconfig>/Levx/SASMeta/MetadataServer) oraz z plików konfiguracyjnych znajdujących się w katalogu instalacyjnym SAS Foundation. Pliki konfiguracyjne w katalogu serwera metadanych:

• adminUsers.txt - zawiera informacje o specjalnych użytkownikach w metadanych - administratorach i użytkownikach 'unrestricted'
• logconfig.xml - definiuje mechanizm logowania dla serwera metadanych
• omaconfig.xml - podstawowe opcje do uruchomienia serwera metadanych
• trustedUsers.txt - informacje o użytkownikach specjalnych w metadanych (uwierzytelnionych)
• trustedPeers.xml - informacje o specjalnych połączeniach z serwerem metadanych
• sasv9.cfg - plik konfiguracyjny SAS, ze specjalnymi opcjami dla serwera metadanych
• sasv9_usermods.cfg - plik konfiguracyjny SAS z dodatkowymi opcjami; wszelkie modyfikacje podstawowych ustawień powinny być wprowadzane w tym pliku.

Dodatkowo wykorzystywane są wszystkie pliki konfiguracyjne używane przy starcie sesji SAS (punkt 6).

Użytkownik musi mieć dostęp:

• do odczytu do katalogu, w którym jest zainstalowane SAS Foundation (<sashome>/SASFoundation/9.4) oraz do podkatalogów.
• do uruchamiania komendy startującej SASa (linku sas na UNIX lub polecenia sas.exe w katalogu SAS Foundation). Na platformie UNIX może być zdefiniowany inny link.

UNIX
SAS jest uruchamiany za pomocą skryptu z katalogu <sashome>/SASFoundation/9.4/bin. W katalogu tym może znajdować się kilka skryptów, po jednym dla każdej wersji językowej, która jest zainstalowana. Pliki konfiguracyjne wykorzystywane przy starcie:

• <sashome>/SASFoundation/9.4/sasv9.cfg
• <sashome>/SASFoundation/9.4/nls//sasv9.cfg
• <sashome>/SASFoundation/9.4/sasv9_local
• sasv9.cfg w katalogu domowym użytkownika

W przypadku, gdy ta sama opcja jest ustawiana w kilku plikach, decydująca jest ostatnia napotkana definicja.

Wykorzystywane są również dwa pliki, które zawierają definicje zmiennych środowiskowych:

• <sashome>/SASFoundation/9.4/bin/sasenv
• <sashome>/SASFoundation/9.4/bin/sasenv_local - zawiera zmienne środowiskowe dodane przez administratora; przykładowo tutaj powinny być umieszczane zmienne środowiskowe niezbędne do skonfigurowania modułów SAS/ACCESS

Windows
Dodatkowo wykorzystywany jest plik \SASFoundation\9.4\sasv9.cfg, w którym znajduje się wskazanie na plik konfiguracyjny z katalogu \SASFoundation\9.4\nls\.

Obie platformy
Do działania SASa niezbędne są 3 biblioteki. Ich definicje znajdują się w plikach konfiguracyjnych lub w instrukcji uruchamiającej SAS:

• SASHELP - jest to konkatenacja kilku katalogów (podkatalogów katalogu instalacyjnego SAS), do których użytkownik musi mieć dostęp do odczytu.
• SASUSER - domyślnie wskazuje na katalog domowy użytkownika, choć w przypadku serwerów działających w środowisku SAS, mogą być zdefiniowane inne katalogi; dostęp może być tylko do odczytu
• WORK - biblioteka robocza, dostęp do modyfikacji.

UNIX
Serwer metadanych najczęściej startuje na koncie SAS Installer (domyślnie sas). SAS Deployment Wizard w trakcie instalacji i konfiguracji przypisuje temu użytkownikowi odpowiednie uprawnienia do katalogów i skryptów. Serwer metadanych nie powinien być startowany na koncie root.

Windows
Domyślnie serwer metadanych jest instalowany jako usługa i startuje na koncie SYSTEM, dzięki czemu ma odpowiednie uprawnienia. Jeżeli do uruchomienia serwera metadanych będzie wykorzystany inny użytkownik, należy zdefiniować dla niego odpowiednie uprawnienia do katalogów serwera metadanych. Użytkownik, na którym działa serwer metadanych powinien mieć pełne uprawnienia do następujących katalogów:

• <sasconfig>\Levx
• <sasconfig>\Levx\SASMeta
• <sasconfig>\Levx\SASMeta\MetadataServer
• <sasconfig>\Levx\SASMeta\MetadataServer\MetadataRepositories (a także do wszystkich katalogów, w których zostały zdefiniowane repozytoria, o ile znajdują się w niestandardowych miejscach).
• <sasconfig>\Levx\SASMeta\MetadataServer\rposmgr

Użytkownik musi mieć również prawo do odczytu i zapisu w katalogu, w którym tworzony jest log serwera metadanych (punkt 8).

Dodatkowo użytkownik musi mieć uprawnienia do wystartowania SASa (punkt 6).

Biblioteka SASUSER dla serwera metadanych jest definiowana w configu serwera metadanych jako tylko do odczytu i wskazuje na \Levx\SASMeta\MetadataServer\sasuser.

Uprawnienia, które powinny być zdefiniowane dla katalogu środowiska są opisane w dokumentacji w rozdziałach Recommended Operating System Protections for Windows Machines oraz Default Operating System Protections for UNIX and z/OS Machines.

Położenie logu jest zdefiniowane w pliku konfiguracyjnym <sasconfig>\Levx\SASMeta\MetadataServer\logconfig.xml. Domyślnie jest on tworzony w katalogu <sasconfig>\Levx\SASMeta\MetadataServer\Logs lub <sasconfig>\Levx\Logs.

UNIX
Na systemach UNIX oprócz standardowego logu, tworzony jest również dodatkowo SASMeta_MetadataServer_console.log. Lokalizacja tego pliku definiowana jest w skrypcie startującym serwer metadanych (<sasconfig>/Levx/SASMeta/MetadataServer/MetadataServer.sh)

Numer portu, na którym działa serwer metadanych powinien znajdować się w dokumentacji instalacyjnej. Można go również znaleźć w plikach konfiguracyjnych serwera metadanych (<sasconfig>\Levx\SASMeta\MetadataServer\sasv9.cfg w ramach opcji objectserverparms).
Sprawdzanie, czy port jest zajęty można wykonać za pomocą polecenia netstat.

W celu korzystania z metadanych i pozostałych serwerów dostępnych w środowisku, użytkownik musi zalogować się do serwera metadanych. Serwer metadanych otrzymany identyfikator i hasło użytkownika prześle do autentykacji do odpowiedniego mechanizmu zewnętrznego. W niektórych przypadkach może przeprowadzić autentykację sam. Otrzymany identyfikator użytkownika zostanie też wykorzystany do identyfikacji użytkownika w metadanych.

Windows
Najczęściej na Windows zdefiniowana jest autentykacja domenowa. Wówczas przy logowaniu do serwera metadanych należy wpisać domena\identyfikator. Taki też identyfikator powinien być wpisany jako Login w definicji użytkownika. Jeżeli wykorzystywana jest autentykacja przez system operacyjny przy logowaniu wystarczy podać identyfikator użytkownika, natomiast w loginie identyfikator musi być poprzedzony nazwą serwera (np. server\sasdemo). Autentykacja zewnętrzna, niezależna od autentykacji domenowej zdefiniowanej dla systemu Windows, opisana jest w punkcie (punkt 11).

UNIX
Jeżeli wykorzystywana jest autentykacja poprzez system operacyjny, wówczas przy logowaniu użytkownik podaje swój identyfikator. W loginie również umieszcza się identyfikator użytkownika. Autentykacja zewnętrzna opisana jest w punkcie (punkt 11).

Na obu platformach można wykorzystywać konta wewnętrzne dla użytkowników, którzy wykonują wyłącznie zadania w obrębie serwera metadanych (nie uruchamiają żadnych procesów). Identyfikator takiego użytkownika to nazwa_użytkownika@saspw.

Inną możliwością jest skorzystanie z mechanizmu IWA - Integrated Windows Authentication. Dla serwera metadanych na Windows mechanizm ten jest domyślnie skonfigurowany. W przypadku UNIXa mechanizm wymaga zainstalowania i skonfigurowania dodatkowego narzędzia Quest Authentication Services. W takim przypadku identyfikator użytkownika jest odczytywany z systemu operacyjnego.

Większość aplikacji wykorzystuje profile, które przechowywane są na lokalnych komputerach. Zawierają one informacje, jak połączyć się z serwerem metadanych. Mogą mieć zapisany identyfikator i hasło użytkownika (hasło zakodowane). W przypadku problemów z zalogowaniem się dobrze jest sprawdzić profil, czy zawiera poprawny identyfikator i aktualne hasło.

Domyślnie serwer metadanych autentykuje w oparciu o system operacyjny. Jeżeli do autentykacji ma być wykorzystane AD lub LDAP sugerowanym rozwiązaniem jest skonfigurowanie systemu operacyjnego tak, aby to on autentykował przez AD lub LDAP. Wtedy z tego sposobu autentykacji SAS będzie korzystał domyœlnie i żadne modyfikacje w środowisku SAS nie są konieczne. Można jednak skonfigurować dla serwera metadanych autentykację przez AD lub LDAP niezależnie od ustawień w systemie operacyjnym. W tym celu w pliku konfiguracyjnym serwera metadanych (<sasconfig>\Levx\SASMeta\MetadataServer\sasv9_usermods.cfg) należy dopisać opcję:

-authproviderdomain provider:authdomain | (provider-1:domain-1)

gdzie provider może przyjmować następujące wartości:

• ADIR autentykacja będzie przeprowadzana w oparciu o Active Directory
• HOSTUSER autentykacja będzie wykonywana w oparciu o system operacyjny; w tej opcji można podać domenę Windows
• LDAP autentykacja będzie wykonywana przez serwer LDAP

a authdomain to dowolna nazwa, która będzie używana przy logowaniu do wyboru rodzaju autentykacji. W takim przypadku przy logowaniu użytkownik powinien podać swój identyfikator w postaci identyfikator@authdomain chyba, że dodatkowo zostanie w pliku konfiguracyjnym zdefiniowana opcja

-PRIMARYPROVIDERDOMAIN

która pozwala zdefiniować jaki rodzaj autentykacji będzie domyślny. Wtedy podawanie domeny przy logowaniu do domyślnej domeny nie jest konieczne, natomiast przy logowaniu użytkowników hostowych należy logować się poprzez identyfikator@host.

Dodatkowo w celu wykorzystania tego sposobu autentykacji w systemie operacyjnym muszą być zdefiniowane zmienne środowiskowe, które pozwolą na połączenie się z AD lub LDAP. Szczegóły można znaleźć w SAS^® 9.4 Intelligence Platform: Security Administration Guide.

Użytkownicy techniczni to użytkownicy zdefiniowani w trakcie konfiguracji systemu, wykorzystywani do wykonywania pewnych standardowych funkcji w środowisku metadanych. Hasła dla nich mogą być zapisane w metadanych, mogą być również zapisane w plikach konfiguracyjnych. Do zmiany haseł dla tych użytkowników służy SAS Deployment Manager (<sashome>\SASDeploymentManager\9.4\sasdm.exe lub <sashome>/SASDeploymentManager/9.4/sasdm.sh). Za jego pomocą hasła zostaną zmienione zarówno w metadanych, jak i w odpowiednich plikach konfiguracyjnych.

Object spawner zaraz po starcie łączy się z serwerem metadanych i odczytuje stamtąd informacje niezbędne do działania. Dlatego ważne jest, aby został uruchomiony po starcie serwera metadanych.

UNIX
Sugerowaną metodą uruchomienia object spawnera jest wykorzystanie skryptu <sasconfig>/Levx/sas.servers. Skrypt ten startuje wszystkie procesy środowiska działające na danej maszynie w odpowiedniej kolejności. Możliwe jest również wystartowanie samego object spawnera za pomocą skryptu dostępnego w katalogu object spawnera:

<sasconfig>/Levx/ObjectSpawner/ObjectSpawner.sh start

Windows
Najczęściej object spawner jest zdefiniowany jako usługa (domyślna nazwa: 'SAS [nazwa_katalogu - Levx] Object Spawner'), więc uruchomienie go polega na uruchomieniu odpowiedniej usługi. Innym sposobem jest skorzystanie ze skrótu dostępnego w Start -> Programy-> SAS (o ile został dodany) lub ze skryptu znajdującego się w katalogu object spawnera:

<sasconfig>\Levx\ObjectSpawner\ObjectSpawner.bat start

UNIX
Do sprawdzenia statusu object spawnera można wykorzystać skrypt z katalogu <sasconfig>/Levx:

./sas.servers status

Pokaże on status wszystkich procesów środowiska SAS działającyh na danej maszynie. Można również wykorzystać skrypt dostępny w katalogu object spawnera (<sasconfig>/Levx/ObjectSpawner):

./ObjectSpawner.sh status

Windows
Jeżeli object spawner działa jako usługa, wystarczy sprawdzić status usługi. Można również wykorzystać skrypt znajdujący się w katalogu object spawnera <sasconfig>\Levx\ObjectSpawner:

ObjectSpawner.bat status

Object spawner korzysta z 2 plików konfiguracyjnych:

• metadataConfig.xml - plik zawiera parametry niezbędne do połączenia się z serwerem metadanych - nazwa/IP serwera, numer portu, identyfikator i hasło użytkownika, za pomocą którego object spawner będzie łączył się z serwerem metadanych; hasło w pliku jest zaszyfrowane. W celu sprawdzenia, czy hasło jest poprawne, można wykorzystać proc PWENCODE, która szyfruje hasła:

  proc pwencode in="hasło";
  run;

• logconfig.xml - informacje o inicjalnym logowaniu ustawionym dla object spawnera.

Domyślnie object spawner tworzy codziennie nowy log. Wszystkie są umieszczane w katalogu <sasconfig>/Levx/ObjectSpawner/logs lub <sasconfig>/Levx/logs. Lokalizacja definiowana jest w pliku konfiguracyjnym logconfig.xml.

UNIX
Object spawner domyślnie tworzy dodatkowy log ObjectSpawner_console.log. Ten log jest ustawiany w skrypcie startującym object spawner (<sasconfig>/Levx/ObjectSpawner/ObjectSpawner.sh).

UNIX
Domyślnie object spawner działa na koncie użytkownika SAS Installer. SAS Deployment Manager przy instalacji i konfiguracji środowiska przypisuje temu użytkownikowi odpowiednie uprawnienia. W przypadku wykorzystania innego konta trzeba zagwarantować, że użytkownik będzie miał dostęp do odczytu i zapisu do katalogu object spawnera (<sasconfig>/Levx/ObjectSpawner) oraz do katalogu, w którym będzie zapisywany log object spawnera (punkt 5).

Dodatkowo powinien mieć uprawnienia do uruchamiania <sasconfig>/Levx/ObjectSpawner/ObjectSpawner.sh i <sashome>/SASFoundation/9.4/utilities/bin/objspawn.

Windows
Domyślnie object spawner działa jako usługa uruchamiana na koncie SYSTEM. W takim przypadku żadne dodatkowe ustawienia nie są konieczne. Jeżeli będzie działać na innym koncie, wówczas należy zagwarantować, że wykorzystywany użytkownik będzie miał pełny dostęp do katalogu object spawnera (<sasconfig>\Levx\ObjectSpawner) oraz katalogu, w którym tworzony jest log object spawnera (punkt 5). Musi mieć również dostęp do katalogu <sashome>\SASFoundation\9.4.

Dodatkowo w systemie operacyjnym użytkownik powinien być członkiem grupy administratorów oraz mieć ustawione następujące uprawnienia:

• Dostosuj przydziały pamięci dla procesów (Adjust memory quotas for a process)
• Zamień żeton na poziomie procesu (replace a process level token)

W przypadku, kiedy workspace serwer został skonfigurowany tak, żeby wykorzystywał Integrated Windows Authentication (IWA) i ma dostawać się do serwisów sieciowych (np. bazy danych SQL Server lub do systemu plików z wykorzystaniem ścieżki UNC) korzystając z identyfikatora Windows to konto, na którym działa object spawner, potrzebuje jeszcze uprawnienia Trusted for Delegation.

Obie platformy
Oprócz użytkownika, na którego koncie działa object spawner, wykorzystywany jest również użytkownik do połączenia z metadanymi. Jest on potrzebny do odczytania definicji serwerów, które object spawner ma uruchamiać i loginów, które będą wykorzystywane do uruchamiania niektórych procesów. Może to być użytkownik wewnętrzny (domyślnie jest to SAS Trusted User). Wykorzystywany użytkownik jest zapisany w pliku konfiguracyjnym <sasconfig>/Levx/ObjectSpawner/metadataConfig.xml. Użytkownik ten musi mieć dostęp do definicji wszystkich serwerów uruchamianych przez dany object spawner w metadanych. Domyślnie SAS Trusted User należy do grupy SAS System Services, która ma dostęp do definicji wszystkich serwerów. Użytkownik musi również mieć dostęp do loginu (ów), na którym będą startowane stored process serwer, pooled workspace serwer i workspace serwer o ile został skonfigurowany do autentykacji tokenowej. Domyślnie SAS Trusted User należy do grupy SAS General Servers, do której został przypisany login, na którym działają stored process serwer i pooled workspace serwer.
Użytkownik, na którym działa object spawner nie powinien być użytkownikiem "unrestricted".

Porty, na których nasłuchuje object spawner, są zapisane w metadanych. Object spawner wykorzystuje port operatora, który jest dla niego zdefiniowany oraz dodatkowo wszystkie porty typu Bridge zdefiniowane dla serwerów, które dany object spawner ma uruchamiać. Dla różnych serwerów numer portu typu Bridge może się powtarzać, gdyż aplikacja żądając uruchomienia serwera, przekazuje informację, jaki serwer ma być uruchomiony.
Porty typu PortBank są wykorzystywane przez sesje pooled workspace serwera.
Sprawdzenie, czy porty nie są zajęte można wykonać za pomocą polecenia netstat.

Po starcie object spawner sprawdza, pod jakimi nazwami serwer jest widoczny w sieci. Informacje te umieszcza w logu. Nazwa ta musi się zgadzać z nazwą serwera podaną dla object spawnera w metadanych (we właściwościach object spawnera na zakładce 'Options').

Serwery, które mają być startowane przez dany object spawner, są przypisane w metadanych. Ich listę można obejrzeć i zmodyfikować wyświetlając właściwości object spawnera na zakładce 'Servers'.

Workspace serwer jest uruchamiany przez object spawner na życzenie użytkownika. Komenda startująca jest zapisana w metadanych, we właściwościach workspace serwera, skąd jest odczytywana przez object spawner przy starcie. Domyślnie jest to uruchomienie skryptu WorkspaceServer.bat/WorkspaceServer.sh z katalogu workspace serwera (<sasconfig>/Levx/SASApp/WorkspaceServer).

Workspace serwer jest przypisany do object spawnera w metadanych, we właściwościach object spawner (zakładka 'Servers').

Do uruchomienia standardowego workspace serwera może być użyte konto, na które użytkownik zalogował się do serwera metadanych lub konto odczytane z metadanych. W przypadku, kiedy podany przy logowaniu identyfikator nie może zostać wykorzystany, a w metadanych nie ma dostępnego odpowiedniego loginu (w domenie autentykacji workspace serwera), niektóre aplikacje mogą zapytać o identyfikator i hasło. Login w metadanych może być zdefiniowany bezpośrednio dla użytkownika lub dla grupy, do której należy.

Istnieje możliwoœć zdefiniowania dla workspace serwera autentykacji w oparciu o mechanizm Integrated Windows Authentication (IWA). W takim przypadku workspace serwer będzie startował na koncie użytkownika aktualnie zalogowanego do Windows.

Dla workspace serwera jest również możliwe zdefiniowanie autentykacji tokenowej. Wtedy wszystkie sesje są uruchamiane na tym samym, wskazanym w metadanych, koncie. Dostęp do tego loginu musi mieć użytkownik, za pomocą którego object spawner łączy się z serwerem metadanych (Object Spawner punkt 6).

Niezależnie od tego, jak zostały podane identyfikator i hasło, musi to być konto, które system operacyjny, na którym działa workspace serwer, może zautentykować.

Użytkownik, na którego koncie będzie startował workspace serwer, musi mieć uprawnienia do odczytu katalogu <sasconfig>/Levx/SASApp i uruchamiania skryptów sas.sh|bat oraz appservercontext_env.sh|bat z tego katalogu, a także do katalogu <sasconfig>/Levx/SASApp/WorkspaceServer i do uruchamiania skryptów WorkspaceServer.sh|bat i WorkspaceServer_usermods.sh|bat. Musi także mieć uprawnienia potrzebne do uruchomienia procesu sas (Serwer Metadanych punkt 6).

Jeżeli workspace serwer został skonfigurowany tak, że będzie tworzył log, użytkownik, na którego koncie jest uruchamiany workspace serwer musi mieć uprawnienia do zapisu w katalogu, w którym będzie tworzony log workspace serwera (Workspace Serwer punkt 4).

Windows
Użytkownik, na którym będzie startowany proces, musi mieć uprawnienie 'Logowanie w trybie wsadowym' (Log on as a batch job). Nie jest ono potrzebne w przypadku, gdy będzie wykorzystywany mechanizm IWA.

Workspace serwer korzysta z następujących plików konfiguracyjnych zdefiniowanych w środowisku:

• w katalogu <sasconfig>\Levx\SASApp\WorkspaceServer: sasv9.cfg, sasv9_usermods.cfg, autoexec.sas oraz autoexec_usermods.sas
• w katalogu <sasconfig>\Levx\SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas oraz appserver_autoexec_usermods.sas.
• <sasconfig>\Levx\metadataConfig.xml, zawierającym informacje, jak połaczyć się z serwerem metadanych

Dodatkowo wykorzystywane są wszystkie standardowe pliki konfiguracyjne używane przy starcie sesji SAS (Serwer Metadanych punkt 6).

Do skonfigurowania logowania jest wykorzystywany plik \Levx\SASApp\WorkspaceServer\logconfig.xml.

Standardowo workspace serwer nie tworzy logów. Jeżeli zmienione zostały ustawienia domyślne, wówczas lokalizacja logów jest zapisana w pliku <sasconfig>\Levx\SASApp\WorkspaceServer\logconfig.xml. Logi workspace serwera powinny być zdefiniowane w taki sposób, żeby każdy proces tworzył swój plik z logiem. Każdy użytkownik, na którego startuje workspace serwer musi mieć dostęp do zapisu do katalogu, w którym będą tworzone logi.

Workspace serwer jest uruchamiany przez object spawner, który musi wiedzieć, na jakim koncie proces ma być wystartowany. Informacje te dostaje od aplikacji albo odczytuje z metadanych. Przed wystartowaniem procesu musi nastąpić autentykacja użytkownika. Jest ona wykonywana zawsze w oparciu o system operacyjny. W przypadku Windows najczęściej system operacyjny prześle identyfikator i hasło do AD, gdyż na ogół zdefiniowana jest autentykacja domenowa. W przypadku UNIXa, jeżeli autentykacja ma się odbywać w oparciu o AD/LDAP, niezbędne jest skonfigurowanie mechanizmu PAM.

Stored process serwer jest uruchamiany przez object spawner. Komenda startująca jest zapisana w metadanych, we właściwościach stored process serwera, skąd jest odczytywana przez object spawner przy starcie. Domyślnie jest to uruchomienie skryptu StoredProcessServer.bat/StoredProcessServer.sh z katalogu stored process serwera (<sasconfig>/Levx/SASApp/StoredProcessServer).

Stored process serwer jest przypisany do object spawnera w metadanych, we właściwościach object spawner (zakładka 'Servers').

Konto, na którym działa stored process serwer jest zapisane w metadanych we właściwościach stored process serwera. Jest ono odczytywane przez object spawner przy starcie. Jeżeli stored process serwer działa na platformie Windows i do uruchamiania serwera jest używany użytkownik lokalny, jego identyfikator w metadanych musi być poprzedzony nazwą maszyny.

Dostęp do wykorzystywanego loginu musi mieć użytkownik, za pomocą którego object spawner łączy się z serwerem metadanych (domyślnie SAS Trusted User). Domyślnie login ten jest zdefiniowany dla grupy SAS General Servers, do której należy SAS Trusted User.

Użytkownik, na którego koncie działa stored proces serwer, jest autentykowany przez system operacyjny.

Użytkownik, na którym jest uruchamiany stored process serwer musi mieć uprawnienia do odczytu do katalogu <sasconfig>\Levx\SASApp i <sasconfig>\Levx\SASApp\StoredProcessServer. Musi mieć prawo uruchamiać skrypty z katalogu <sasconfig>\Levx\SASApp\StoredProcessServer: StoredProcessServer.sh|bat oraz StoredProcessServer_usermods.sh|bat, a także skryptów <sasconfig>\Levx\SASApp\sas.sh|bat i <sasconfig>/Levx/SASApp/appservercontext_env.sh|bat. Musi mieć wszystkie uprawnienia, które są potrzebne, żeby uruchomić proces sas (Serwer metadanych punkt 6).

Biblioteka SASUSER dla stored proces serwera jest zdefiniowana w configu serwera jako tylko do odczytu i wskazuje na <sasconfig>\Levx\SASApp\StoredProcessServer\sasuser.

Dodatkowo użytkownik musi mieć uprawnienia do katalogu, w którym zapisywany jest log (punkt 5) oraz do katalogów, w których przechowywane są kody procesów gotowych.

Windows
Użytkownik musi mieć uprawnienie 'Logowanie w trybie wsadowym' (Log on as a Batch job).

Stored process serwer wykorzystuje następujące pliki konfiguracyjne z katalogów środowiska:

• Z katalogu <sasconfig>\Levx\SASApp\StoredProcessServer: sasv9.cfg, sasvg_usermods.cfg, autoexec.sas oraz autoexec_usermods.sas
• Z katalogu <sasconfig>\Levx\SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas, appserver_autoexec_usermods.sas.
• <sasconfig>\Levx\metadataConfig.xml, zawierającym informacje, jak połaczyć się z serwerem metadanych

Dodatkowo korzysta z wszystkich plików konfiguracyjnych potrzebnych do uruchomienia procesu sas (Serwer metadanych punkt 6).

Do skonfigurowania logowania jest wykorzystywany plik <sasconfig>\Levx\SASApp\StoredProcessServer\logconfig.xml.

Ścieżka do katalogu z logami jest zdefiniowana w pliku konfiguracyjnym <sasconfig>\Levx\SASApp\StoredProcessServer\logconfig.xml. Domyślnie logi są tworzone w katalogu <sasconfig>\Levx\Logs lub <sasconfig>\Levx\SASApp\StoredProcessServer\logs.

Porty, na których działa stored process serwer, są zdefiniowane w metadanych. Są to porty typu MultiBridge. Zajętość portów można sprawdzić komendą netstat.

Pooled workspace serwer jest uruchamiany przez object spawner. Komenda startująca jest zapisana w metadanych, we właściwościach pooled workspace serwera, skąd jest odczytywana przez object spawner przy starcie. Domyślnie jest to uruchomienie skryptu PooledWorkspaceServer.bat/PooledWorkspaceServer.sh z katalogu stored process serwera (<sasconfig>/Levx/SASApp/PooledWorkspaceServer).

Pooled workspace serwer jest przypisany do object spawnera w metadanych, we właściwościach object spawnera (zakładka 'Servers').

Konto, na którym działa pooled workspace serwer, jest zapisane w metadanych we właściwościach pooled workspace serwera. Jest ono odczytywane przez object spawner przy starcie. Jeżeli pooled workspace serwer działa na platformie Windows i do uruchamiania serwera jest używany użytkownik lokalny, jego identyfikator w metadanych musi być poprzedzony nazwą maszyny.

Dostęp do wykorzystywanego loginu musi mieć użytkownik, za pomocą którego object spawner łączy się z serwerem metadanych (domyślnie SAS Trusted User). Domyślnie login ten jest zdefiniowany dla grupy SAS General Servers, do której należy SAS Trusted User.

Użytkownik wykorzystywany do uruchomienia pooled workspace serwera jest autentykowany przez system operacyjny.

Użytkownik, na którym jest uruchamiany pooled workspace serwer musi mieć uprawnienia do odczytu do katalogu <sasconfig>\Levx\SASApp> oraz <sasconfig>\Levx\SASApp\PooledWorkspaceServer. Musi mieć prawo uruchamiać skrypty z katalogu <sasconfig>\Levx\SASApp\PooledWorkspaceServer: PooledWorkspaceServer.sh|bat i PooledWorkspaceServer_usermods.sh|bat, oraz skrypty <sasconfig>/Levx/SASApp/sas.sh|bat i <sasconfig>/Levx/SASApp/appservercontext_env.sh|bat. Musi mieć wszystkie uprawnienia, które są potrzebne, żeby uruchomić proces sas (Serwer metadanych punkt 6).
Dodatkowo musi mieć uprawnienia do katalogu, w którym zapisywany jest log (punkt 5).

Biblioteka SASUSER dla pooled workspace serwera jest zdefiniowana w configu serwera jako tylko do odczytu i wskazuje na <sasconfig>\Levx\SASApp\PooledWorkspaceServer\sasuser.

Windows
Użytkownik musi mieć uprawnienie 'Logowanie w trybie wsadowym' (Log on as a Batch job).

Pooled workspace serwer wykorzystuje następujące pliki konfiguracyjne z katalogów środowiska:

• Z katalogu <sasconfig>\Levx\SASApp\PooledWorkspaceServer: sasv9.cfg, sasvg_usermods.cfg, autoexec.sas i autoexec_usermods.sas
• Z katalogu <sasconfig>\Levx\SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas, appserver_autoexec_usermods.sas.
• <sasconfig>\Levx\metadataConfig.xml, zawierającym informacje, jak połaczyć się z serwerem metadanych

Dodatkowo korzysta z wszystkich plików konfiguracyjnych potrzebnych do uruchomienia procesu sas (Serwer metadanych punkt 6).

Do skonfigurowania logowania jest wykorzystywany plik <sasconfig>\Levx\SASApp\PooledWorkspaceServer\logconfig.xml.

Ścieżka do katalogu z logami jest zdefiniowana w pliku konfiguracyjnym <sasconfig>\Levx\SASApp\PooledWorkspaceServer\logconfig.xml. Domyślnie logi są tworzone w katalogu <sasconfig>\Levx\Logs lub <sasconfig>\Levx\SASApp\PooledeWorkspaceServer\logs.

Porty, na których działa pooled workspace serwer, są to porty typu PortBank zdefiniowane w metadanych dla object spawnera. Porty te są wykorzystywane tylko w czasie połączenia klienta z wybranym procesem pooled workspace serwera. Po rozłączeniu się klienta (wykonaniu kodu), proces dalej działa, a wykorzystany port jest zwracany do puli portów object spawnera. Przy połączeniu kolejnego klienta object spawner przydzieli procesowi wolny port z puli dostępnych portów.

Sugerowaną metodą startowania serwera jest wykorzystanie skryptu /Levx/sas.servers, który służy do uruchamiania i zatrzymywania wszystkich procesów środowiska działających na danej maszynie:

./sas.servers start

Dostępny jest również skrypt służący tylko do startowania i zatrzymywania serwera OLAP. Znajduje się on w katalogu serwera: <sasconfig>/Levx/SASApp/OLAPServer:

./OLAPServer start

Windows
Najczęściej OLAP serwer jest zdefiniowany jako usługa, wystarczy więc uruchomić ją. Skrót do wystartowania serwera może być również umieszczony w Start -> Programy -> SAS. Dostępny jest również skrypt w katalogu OLAP serwera: <sasconfig>\Levx\SASApp\OLAPServer:

OLAPServer.bat start

Obie platformy
Po starcie OLAP serwer łączy się z serwerem metadanych, dlatego musi być uruchomiony po starcie serwera metadanych.

UNIX
Status serwera OLAP można sprawdzić za pomocą skryptu sas.servers, znajdującego się w katalogu <sasconfig>/Levx:

sas.server status

Inną metodą jest wykorzystanie skryptu znajdującego się w katalogu serwera (<sasconfig>/Levx/SASApp/OLAPServer):

OLAPServer.sh status

Windows
Jeżeli OLAP serwer działa jako usługa, wystarczy sprawdzić status usługi. Można również wykorzystać skrypt znajdujący się w katalogu serwera (<sasconfig>\Levx\SASApp\OLAPServer):

OLAPServer.bat status

Użytkownik, na którym startuje serwer OLAP musi mieć uprawnienia do odczytu katalogu serwera OLAP (<sasconfig>/Levx/SASApp/OLAPServer), do uruchamiania skryptu startującego serwer OLAP (OLAPServer.sh z katalogu serwera) oraz skryptu <sasconfig>/Levx/SASApp/appservercontext_env.sh|bat. Musi mieć uprawnienia do zapisu do katalogu, w którym będzie tworzony log serwera (punkt 6), jak również uprawnienia niezbędne do uruchomienia procesu SAS (Serwer Metadanych punkt 6). Ponieważ w systemie operacyjnym serwer OLAP to jeden proces, działający w imieniu konkretnego użytkownika, to ten użytkownik musi mieć uprawnienia do odczytu do wszystkich katalogów, w których są przechowywane fizyczne pliki kostek.
Jeżeli w SASie została zdefiniowana opcja UTILLOC lub SPDEUTILLOC, wówczas użytkownik musi mieć dostęp do zapisu do ścieżek podanych w ramach tych opcji.
Serwer OLAP nie powinien być startowany na koncie Root.

Biblioteka SASUSER dla OLAP serwera jest zdefiniowana w configu serwera jako tylko do odczytu i wskazuje na <sasconfig>\Levx\SASApp\OLAPServer\sasuser.

OLAP serwer po starcie, a także w ciągu całej swojej pracy kontaktuje się z serwerem metadanych. Połączenie to odbywa się za pomocą specjalnego użytkownika, który musi być zdefiniowany jako "trusted user" (domyślnie jest to SAS Trusted User). Wszystkie parametry potrzebne do połączenia z serwerem metadanych (w tym użytkownik) są zapisane w pliku <sasconfig>/Levx/sasv9_meta.cfg.

OLAP serwer wykorzystuje następujące pliki konfiguracyjne:

• z katalogu <sasconfig>/Levx/SASApp/OLAPServer: sasv9.cfg, sasv9_usermods.cfg, , autoexec.sas, autoexec_usermods.sas, logconfig.xml
• z katalogu <sasconfig>/Levx/SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas, appserver_autoexec_usermods.sas
• <sasconfig>/Levx/metadataConfig.xml i <sasconfig>/Levx/sasv9_meta.cfg - tutaj są podane parametry połączeniowe do serwera metadanych.

Dodatkowo serwer OLAP wykorzystuje wszystkie pliki konfiguracyjne używane przy uruchomieniu procesu SAS (Serwer Metadanych punkt 6).

Numer portu, na którym działa OLAP serwer, jest zapisany w metadanych w obiekcie Connection zdefiniowanym dla serwera. Zajętość portu można sprawdzić komendą NETSTAT.

Mechanizm logowania dla serwera OLAP jest zdefiniowany w pliku konfiguracyjnym serwera logconfig.xml. Domyślnie log jest zapisywany w katalogu <sasconfig>\Levx\SASApp\OLAPServer\logs lub <sasconfig>\Levx\Logs.

Dodatkowo na UNIXie jest tworzony log SASApp_OLAPServer_console.log, który jest zdefiniowany w skrypcie startującym OLAP serwer (<sasconfig>/Levx/SASApp/OLAPServer/OLAPServer.sh).

Użytkownik, który chce odczytać dane z kostki musi mieć zdefiniowane dla kostki uprawnienia Read i ReadMetadata. Mogą być one nałożone bezpośrednio na kostkę lub na folder, w którym znajduje się kostka (bezpośrednio lub pośrednio), ew. w domyślnym schemacie zdefiniowanym dla repozytorium.
W systemie operacyjnym dostęp do fizycznych plików musi mieć użytkownik, na którym działa serwer OLAP.

Jeżeli użytkownik łączy się najpierw z serwerem metadanych, a potem z serwerem OLAP, to serwer OLAP wykorzystuje autentykacje tokenową, tzn. serwer metadanych generuje specjalny token, który jest przez aplikację kliencką przekazywany do serwera OLAP, który z kolei zwraca token do weryfikacji do serwera metadanych.
W niektórych przypadkach użytkownicy mogą łączyć się z serwerem OLAP bezpośrednio. Wówczas serwer OLAP jest odpowiedzialny za dokonanie autentykacji. Domyślnie korzysta z autentykacji poprzez system operacyjny, ale może mieć zdefiniowane alternatywne sposoby autentykacji tak, jak serwer metadanych (Serwer Metadanych punkt 11).