Najczęstsze problemy i pytania związane architekturą SAS^® 9 Intelligence Platform

I. Serwer Metadanych

1. Jak uruchomić serwer metadanych?
2. Jak sprawdzić, czy serwer metadanych działa?
3. Jak sprawdzić, czy na danym koncie startuje proces SAS?>
4. Jak zaktualizować licencję SASa?
5. Jakie pliki konfiguracyjne są wykorzystywane przy uruchamianiu serwera metadanych?
6. Jakie uprawnienia musi mieć użytkownik w systemie operacyjnym, żeby wystartować proces SAS?
7. Jakie uprawnienia w systemie operacyjnym powinien mieć użytkownik, na którego koncie startuje serwer metadanych?
8. Gdzie znaleźć log serwera metadanych?
9. Jak sprawdzić, na którym porcie działa serwer metadanych?
10. W jaki sposób podaje się identyfikator użytkownika przy logowaniu?
11. Czy można zdefiniować inny sposób autentykacji niż system operacyjny dla serwera metadanych?
12. Jak zmienić hasła użytkownikom standardowym (sasadm, sastrust, sassrv)?

II. Object Spawner

13. Jak uruchomić Object Spawner?
14. Jak sprawdzić, czy object spawner działa?
15. Jakie pliki konfiguracyjne są wykorzystywane przez Object Spawner?
16. Gdzie znaleźć log Object Spawnera?
17. Jakie uprawnienia powinien mieć użytkownik, na którym działa object spawner?
18. Na jakim porcie nasłuchuje object spawner?
19. Jak sprawdzić, które serwery są startowane przez object spawner?

III. Workspace Serwer

20. Jak jest uruchamiany workspace serwer?
21. Na jakim koncie jest uruchamiany workspace serwer?
22. Jakie uprawnienia musi mieć użytkownik, na którym działa workspace serwer?
23. Z jakich plików konfiguracyjnych korzysta workspace serwer?
24. Gdzie znajdują się logi workspace serwera?
25. Jak wykonywana jest autentykacja użytkownika, na którego koncie ma działać workspace serwer?

IV. Stored Process Serwer

26. Jak jest uruchamiany stored process serwer?
27. Na jakim koncie jest uruchamiany stored process serwer?
28. Jakie uprawnienia musi mieć użytkownik, na którego koncie jest uruchamiany stored process serwer?
29. Jakie pliki konfiguracyjne wykorzystuje stored process serwer?
30. Gdzie znajdują się logi stored process serwera?
31. Na jakich portach działa stored process serwer?

V. Pooled Workspace Serwer

32. Jak jest uruchamiany pooled workspace serwer?
33. Na jakim koncie jest uruchamiany pooled workspace serwer?
34. Jakie uprawnienia musi mieć użytkownik, na którego koncie jest uruchamiany pooled workspace serwer?
35. Jakie pliki konfiguracyjne wykorzystuje pooled workspace serwer?
36. Gdzie znajdują się logi pooled workspace serwera?
37. Na jakich portach działa pooled workspace serwer?

VI. OLAP serwer

38. Jak uruchomić OLAP serwer?
39. Jak sprawdzić, czy OLAP serwer działa?
40. Jakie uprawnienia musi mieć użytkownik, na którego koncie działa serwer OLAP?
41. Jakie pliki konfiguracyjne wykorzystuje serwer OLAP?
42. Na jakim porcie działa serwer OLAP?
43. Gdzie znajduje się log serwera OLAP?
44. Jakie uprawnienia musi mieć użytkownik, żeby wyświetlić dane z kostki?
45. Jak autentykuje serwer OLAP?

I. Serwer Metadanych

1. Jak uruchomić serwer metadanych?

UNIX
Sugerowaną metodą jest wykorzystanie skryptu (/Lev1/sas.servers), który służy do uruchamiania i zatrzymywania wszystkich procesów działających w środowisku 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 (/Lev1/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-Lev1] 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 jest dostępny w katalogu serwera metadanych (\Lev1\SASMeta\MetadataServer).

Uruchomienie serwera:

MetadataServer.bat start

Zatrzymanie serwera:

MetadataServer.bat stop

Początek strony

2. Jak sprawdzić, czy serwer metadanych działa?

UNIX
Do sprawdzenia, czy serwer metadanych działa można wykorzystać skrypt startujący i zatrzymujący wszystkie procesy środowiska SAS (/Lev1/sas.servers):

./sas.servers status

Można również wykorzystać skrypt z katalogu serwera metadanych (/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 (\Lev1\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;

Początek strony

3. Jak sprawdzić, czy na danym koncie startuje proces SAS?>

W celu sprawdzenia, czy SAS startuje na danym koncie, należy zalogować się na konto tego użytkownika i uruchomić SASa z katalogu instalacyjnego \SASFoundation\9.2\sas.exe lub /SASFoundation/9.2/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 \SASFoundation\9.2\sas.exe

Początek strony

4. Jak zaktualizować licencję SASa?

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

Początek strony

5. Jakie pliki konfiguracyjne są wykorzystywane przy uruchamianiu serwera metadanych?

Serwer metadanych korzysta z plików konfiguracyjnych, które znajdują się w katalogu serwera metadanych (/Lev1/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).

Początek strony

6. Jakie uprawnienia musi mieć użytkownik w systemie operacyjnym, żeby wystartować proces SAS?

Użytkownik musi mieć dostęp:
• do odczytu do katalogu, w którym jest zainstalowane SAS Foundation (/SASFoundation/9.2) 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 /SASFoundation/9.2/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:

• /SASFoundation/9.2/sasv9.cfg
• /SASFoundation/9.2/nls//sasv9.cfg
• /SASFoundation/9.2/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:

• /SASFoundation/9.2/bin/sasenv
• /SASFoundation/9.2/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.2\sasv9.cfg, w którym znajduje się wskazanie na plik konfiguracyjny z katalogu \SASFoundation\9.2\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.

Początek strony

7. Jakie uprawnienia w systemie operacyjnym powinien mieć użytkownik, na którego koncie startuje serwer metadanych?

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:

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

Użytkownik musi mieć również prawo do odczytu i zapisu w katalogu, w którym zapisywany 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 \Lev1\SASMeta\MetadataServer\sasuser.

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

Początek strony

8. Gdzie znaleźć log serwera metadanych?

Położenie logu jest zdefiniowane w pliku konfiguracyjnym \MetadataServer\logconfig.xml. Domyślnie jest on tworzony w katalogu \Lev1\SASMeta\MetadataServer\Logs lub \Lev1\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 (/MetadataServer/MetadataServer.sh)

Początek strony

9. Jak sprawdzić, na którym porcie działa serwer metadanych?

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 (\Lev1\SASMeta\MetadataServer\sasv9.cfg w ramach opcji objectserverparms).
Sprawdzanie, czy port jest zajęty można wykonać za pomocą polecenia netstat.

Początek strony

10. W jaki sposób podaje się identyfikator użytkownika przy logowaniu?

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.

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.

Początek strony

11. Czy można zdefiniować inny sposób autentykacji niż system operacyjny dla serwera metadanych?

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 mogą korzystać wszystkie serwery SAS 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 (\Lev1\SASMeta\MetadataServer\sasv9.cfg) należy dopisać opcję:

-authproviderdomain provider:authdomain | (provider-1:domain-1<, . . .provider-n:domain-n>)

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 SASR 9.2 Intelligence Platform: Security Administration Guide.

Początek strony

12. Jak zmienić hasła użytkownikom standardowym (sasadm, sastrust, sassrv)?

Użytkownicy standardowi 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 (\SASDeploymentManager\9.2\config.exe lub /SASDeploymentManager/9.2/config.sh). Za jego pomocą hasła zostaną zmienione zarówno w metadanych, jak i w odpowiednich plikach konfiguracyjnych.

Początek strony

II. Object Spawner

13. Jak uruchomić Object Spawner?

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 /Lev1/sas.servers. Skrypt ten startuje wszystkie procesy działające w środowisku w odpowiedniej kolejności. Możliwe jest również wystartowanie samego object spawnera za pomocą skryptu dostępnego w katalogu object spawnera:

/Lev1/ObjectSpawner/ObjectSpawner.sh start

Windows
Najczęściej object spawner jest zdefiniowany jako usługa (domyślna nazwa: 'SAS [nazwa_katalogu - Lev1] 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:

\Lev1\ObjectSpawner\ObjectSpawner.bat start

Początek strony

14. Jak sprawdzić, czy object spawner działa?

UNIX
Do sprawdzenia statusu object spawnera można wykorzystać skrypt z katalogu /Lev1:

./sas.servers status

Pokaże on status wszystkich procesów działających w środowisku. Można również wykorzystać skrypt dostępny w katalogu object spawnera (/Lev1/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 \Lev1\ObjectSpawner:

ObjectSpawner.bat status

Początek strony

15. Jakie pliki konfiguracyjne są wykorzystywane przez Object Spawner?

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.

Początek strony

16. Gdzie znaleźć log Object Spawnera?

Domyślnie object spawner tworzy codziennie nowy log. Wszystkie są umieszczane w katalogu /Lev1/ObjectSpawner/logs lub /Lev1/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 (/Lev1/ObjectSpawner/ObjectSpawner.sh).

Początek strony

17. Jakie uprawnienia powinien mieć użytkownik, na którym działa object spawner?

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 (/Lev1/ObjectSpawner) oraz do katalogu, w którym będzie zapisywany log object spawnera (punkt 16).

Dodatkowo powinien mieć uprawnienia do uruchamiania /Lev1/ObjectSpawner/ObjectSpawner.sh i /SASFoundation/9.2/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 (\Lev1\ObjectSpawner) oraz katalogu, w którym tworzony jest log object spawnera (punkt 16). Musi mieć również dostęp do katalogu \SASFoundation\9.2.

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 /Lev1/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".

Początek strony

18. Na jakim porcie nasłuchuje object spawner?

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 do uruchamiania 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').

Początek strony

19. Jak sprawdzić, które serwery są startowane przez object spawner?

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'.

Początek strony

III. Workspace Serwer

Workspace serwer jest startowany przez object spawner, dlatego każda zmiana w definicji workspace serwera w metadanych wymaga ponownego zaczytania definicji przez object spawner. Można to zrobić restartując object spawner lub podłączając się do niego w konsoli metadanych i wykonując polecenie z pomocniczego menu 'Refresh spawner'.

20. Jak jest uruchamiany workspace serwer?

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 (/Lev1/SASApp/WorkspaceServer).
Workspace serwer jest przypisany do object spawnera w metadanych, we właściwościach object spawner (zakładka 'Servers').

Początek strony

21. Na jakim koncie jest uruchamiany workspace serwer?

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

W przypadku, gdy serwery SAS działają na Windows, można dla workspace serwera zdefiniować, że ma być wykorzystywany 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 koncie, które zostało wskazane w metadanych. Dostęp do tego loginu musi mieć użytkownik, za pomocą którego object spawner łączy się z serwerem metadanych (punkt 18).

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ć.

Początek strony

22. Jakie uprawnienia musi mieć użytkownik, na którym działa workspace serwer?

Użytkownik, na którego koncie będzie startował workspace serwer musi mieć uprawnienia do odczytu katalogu /Lev1/SASApp i uruchamiania skryptu sas.sh|bat oraz appservercontext_env.sh|bat z tego katalogu a także do katalogu /Lev1/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 (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 (punkt 24).

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.

Początek strony

23. Z jakich plików konfiguracyjnych korzysta workspace serwer?

Workspace serwer korzysta z następujących plików konfiguracyjnych zdefiniowanych w środowisku:
• w katalogu \Lev1\SASApp\WorkspaceServer: sasv9.cfg, sasv9_usermods.cfg, autoexec.sas oraz autoexec_usermods.sas
• w katalogu \Lev1\SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas oraz appserver_autoexec_usermods.sas.

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

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

Początek strony

24. Gdzie znajdują się logi workspace serwera?

Standardowo workspace serwer nie tworzy logów. Jeżeli zmienione zostały ustawienia domyślne, wówczas lokalizacja logów jest zapisana w pliku \Lev1\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.

Początek strony

25. Jak wykonywana jest autentykacja użytkownika, na którego koncie ma działać workspace serwer?

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.

Początek strony

IV. Stored Process Serwer

Stored Process serwer jest startowany przez object spawner, dlatego każda zmiana w definicji serwera w metadanych wymaga ponownego zaczytania definicji przez object spawner. Można to zrobić restartując object spawner lub podłączając się do niego w konsoli metadanych i wykonując polecenie z pomocniczego menu 'Refresh spawner'.

26. Jak jest uruchamiany stored process serwer?

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 (/Lev1/SASApp/StoredProcessServer).
Stored process serwer jest przypisany do object spawnera w metadanych, we właściwościach object spawner (zakładka 'Servers').

Początek strony

27. Na jakim koncie jest uruchamiany stored process serwer?

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.

Początek strony

28. Jakie uprawnienia musi mieć użytkownik, na którego koncie jest uruchamiany stored process serwer?

Użytkownik, na którym jest uruchamiany stored process serwer musi mieć uprawnienia do odczytu do katalogu \Lev1\SASApp i \Lev1\SASApp\StoredProcessServer. Musi mieć prawo uruchamiać skrypty z katalogu \Lev1\SASApp\StoredProcessServer: StoredProcessServer.sh|bat oraz StoredProcessServer_usermods.sh|bat, a także skryptów \Lev1\SASApp\sas.sh|bat i /Lev1/SASApp/appservercontext_env.sh|bat. Musi mieć wszystkie uprawnienia, które są potrzebne, żeby uruchomić proces sas (punkt 6).
Biblioteka SASUSER dla stored proces serwera jest zdefiniowana w configu serwera jako tylko do odczytu i wskazuje na \Lev1\SASApp\StoredProcessServer\sasuser.
Dodatkowo użytkownik musi mieć uprawnienia do katalogu, w którym zapisywany jest log (punkt 30) 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).

Początek strony

29. Jakie pliki konfiguracyjne wykorzystuje stored process serwer?

Stored process serwer wykorzystuje następujące pliki konfiguracyjne z katalogów środowiska:
• Z katalogu \Lev1\SASApp\StoredProcessServer: sasv9.cfg, sasvg_usermods.cfg, autoexec.sas oraz autoexec_usermods.sas
• Z katalogu \Lev1\SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas, appserver_autoexec_usermods.sas.

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

Do skonfigurowania logowania jest wykorzystywany plik \Lev1\SASApp\StoredProcessServer\logconfig.xml.

Początek strony

30. Gdzie znajdują się logi stored process serwera?

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

Początek strony

31. Na jakich portach działa stored process serwer?

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.

Początek strony

V. Pooled Workspace Serwer

Pooled workspace serwer jest startowany przez object spawner, dlatego każda zmiana w definicji serwera w metadanych wymaga ponownego zaczytania definicji przez object spawner. Można to zrobić restartując object spawner lub podłączając się do niego w konsoli metadanych i wykonując polecenie z pomocniczego menu 'Refresh spawner'.

32. Jak jest uruchamiany pooled workspace serwer?

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 (/Lev1/SASApp/PooledWorkspaceServer).
Pooled workspace serwer jest przypisany do object spawnera w metadanych, we właściwościach object spawnera (zakładka 'Servers').

Początek strony

33. Na jakim koncie jest uruchamiany pooled workspace serwer?

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.

Początek strony

34. Jakie uprawnienia musi mieć użytkownik, na którego koncie jest uruchamiany pooled workspace serwer?

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

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

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

Początek strony

35. Jakie pliki konfiguracyjne wykorzystuje pooled workspace serwer?

Pooled workspace serwer wykorzystuje następujące pliki konfiguracyjne z katalogów środowiska:
• Z katalogu \Lev1\SASApp\PooledWorkspaceServer: sasv9.cfg, sasvg_usermods.cfg, autoexec.sas i autoexec_usermods.sas
• Z katalogu \Lev1\SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas, appserver_autoexec_usermods.sas.

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

Do skonfigurowania logowania jest wykorzystywany plik \Lev1\SASApp\PooledWorkspaceServer\logconfig.xml.

Początek strony

36. Gdzie znajdują się logi pooled workspace serwera?

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

Początek strony

37. Na jakich portach działa pooled workspace serwer?

Porty, na których działa pooled workspace serwer, są zdefiniowane w metadanych dla object spawnera. Są to porty typu PortBank. Zajętość portów można sprawdzić komendą netstat.

Początek strony

VI. OLAP Serwer

38. Jak uruchomić OLAP serwer?

UNIX
Sugerowaną metodą startowania serwera jest wykorzystanie skryptu /Lev1/sas.servers, który służy do uruchamiania i zatrzymywania wszystkich procesów działających w środowisku SAS:

./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: /Lev1/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: \Lev1\SASApp\OLAPServer:

OLAPServer.bat start

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

Początek strony

39. Jak sprawdzić, czy OLAP serwer działa?

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

sas.server status

Inną metodą jest wykorzystanie skryptu znajdującego się w katalogu serwera (/Lev1/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 (\Lev1\SASApp\OLAPServer):

OLAPServer.bat status

Początek strony

40. Jakie uprawnienia musi mieć użytkownik, na którego koncie działa serwer OLAP?

Użytkownik, na którym startuje serwer OLAP musi mieć uprawnienia do odczytu katalogu serwera OLAP (/Lev1/SASApp/OLAPServer), do uruchamiania skryptu startującego serwer OLAP (OLAPServer.sh z katalogu serwera) oraz skryptu /Lev1/SASApp/appservercontext_env.sh|bat. Musi mieć uprawnienia do zapisu do katalogu, w którym będzie tworzony log serwera (punkt 43), jak również uprawnienia niezbędne do uruchomienia procesu SAS (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 \Lev1\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 /Lev1/sasv9_meta.cfg.

Początek strony

41. Jakie pliki konfiguracyjne wykorzystuje serwer OLAP?

OLAP serwer wykorzystuje następujące pliki konfiguracyjne:
• z katalogu /Lev1/SASApp/OLAPServer: sasv9.cfg, sasv9_usermods.cfg, , autoexec.sas, autoexec_usermods.sas, logconfig.xml
• z katalogu /Lev1/SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas, appserver_autoexec_usermods.sas
• z katalogu /Lev1: 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 (punkt 6).

Początek strony

42. Na jakim porcie działa serwer OLAP?

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.

Początek strony

43. Gdzie znajduje się log serwera OLAP?

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

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

Początek strony

44. Jakie uprawnienia musi mieć użytkownik, żeby wyświetlić dane z kostki?

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.

Początek strony

45. Jak autentykuje 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 sposobu autentykacji tak, jak serwer metadanych (punkt 11).

Początek strony

Data ostatniej aktualizacji dokumentu: 07.04.2011