Oracle Application Server 10g (OAS) e' un infrastruttura completa che permette il deploy e la gestione di applicazioni Web realizzate con strumenti Oracle e di terze parti. Dal punto di vista funzionale OAS e' uno degli ambienti per applicazioni web piu' completi disponibili sul mercato e la sua integrazione presenta vantaggi per un utilizzo a livello di Enterprise.

Poiche' l'ambiente e' veramente completo e complesso qualche suggerimento e qualche trucco possono essere utili!
Questo documento riporta percio' i comandi piu' utilizzati e qualche semplice indicazione per progettare, installare, configurare e gestire al meglio la piattaforma OAS. La lettura presuppone una certa conoscenza dell'ambiente OAS... meglio leggere prima Oracle Application Server 10g - Introduzione! Se invece volete proseguire... gli argomenti sono organizzati in semplici paragrafi: La cassetta degli attrezzi Architettura OAS Amministrazione Link alle pagine di amministrazione Logging Small Footprint Versioni Portal VPP SSO Networking OHS/Apache Security Sistema Operativo Configurazioni particolari Configurazione SSL

Ogni buon sistemista ha una serie di tool che utilizza per risolvere problemi o anche solo per semplificare qualche attivita'. Anche per lavorare con OAS e' opportuno farsi una "cassetta degli attrezzi" adatta!

Il primo consiglio e' quello di installare OAS su un sistema operativo serio. Intendo un sistema operativo che fornisca strumenti di analisi, che non cambi in modo impredicibile, che sia configurabile e stabile, che sia completamente documentato, che implementi in modo accettabile lo stack TCP-IP, ... Per quello che mi riguarda, gli unici OS che soddisfano a tali condizioni, almeno tra quelli che conosco a sufficenza, sono ambienti Unix.

I comandi piu' utili sono (alcuni sono riportati in Comandi Unix poco noti): ps che riporta i processi attivi, netstat per evidenziare lo stato delle connessioni di rete, fuser e, soprattutto, lsof che riportano i file aperti per ogni processo, trace che consente di seguire le chiamate a sistema e fare un debug dei casi piu' complessi (strace, truss, tusc, trace sono i nomi con cui viene chiamata questa utility su Linux/GNU, Solaris, HP-UX, AIX, ...), gdb per determinare le funzioni richiamate, snoop o tcpdump per tracciare lo scambio di pacchetti in rete, sar vmstat iostat... per raccogliere e mantenere le statistiche di utilizzo del sistema, ...

Altri strumenti necessari sono (alcuni vengono riportati con maggior dettaglio in Software libero): un browser per navigare le pagine (sembra banale perche' e' presente IE nel sistema operativo di ogni PC... ma non basta! Utilizzate anche un altro browser: ad esempio l'ottimo Firefox), un LDAP browser per controllare il contenuto dell'OID (eg. Jxplorer), un Tool di amministrazione DB per monitorare sessioni e statement SQL (eg. TOra), un editor serio per i file di configurazione ed i sorgenti (eg. VIM), eventualmente qualche editor per le pagine HTML (eg. NVU, FCKeditor), uno sniffer per controllare lo scambio dei pacchetti in rete (eg. Ethereal), un Java disassember per verificare il contenuto delle classi Java (eg. FrontEnd), uno strumento per la raccolta dei log di accesso e la reportistica (eg. Analog), un tool di generazione di carico ed analisi delle prestazioni (eg. Grinder), qualche utility di gestione (eg. wget, tidy, Putty, VNC, TightVNC ), se il numero di sistemi ed ambienti da monitorare e' elevato risulta utile un controllo automatico (eg. Nagios), ...

Un bagaglio sempre importante per un sistemista sono gli script di amministrazione come: pagina Link OAS, report SQL sulla configurazione, script raccolta password, script di reload procedure Java, rewire di Portal, registrazione di una company, ... che troveremo piu' avanti nei vari capitoli.

Per ultimo, ma non da ultimo, la documentazione, sui prodotti ed in linea, e' fondamentate. Da questo punto di vista quanto Oracle fornisce e' veramente completo, la difficolta' maggiore e' quella di orientarsi! Oltre alla documentazione ufficiale a volte sono anche utili le direttive di Apache, le note sul protocollo HTTP, le tabelle MAC, ...

Chi legge questo documento dovrebbe gia' avere una discreta visione di quella che e' l'architettura di OAS...
In ogni caso il consiglio e' quello di schematizzare e documentare con attenzione istanze, porte, applicazioni, configurazioni... Servono sempre!

Le architetture di servizi che e' possibile creare con OAS sono molteplici e possono soddisfare tutti i requisiti di sicurezza e di alta affidabilita' di siti ed applicazioni Enterprise. Se l'installazione di una piattaforma OAS su un singolo sistema (eg. per un ambiente di sviluppo) e' piuttosto semplice, al contrario le installazioni e configurazioni di produzione con DMZ, DNS, proxy server, load balancer, cluster (a livello di OS, tra Java container, tra web cache, ...), RAC, SSL, Firewall, ... vanno progettate e pianificate con attenzione.

L'Enterprise Manager (EM) consente di configurare ogni singolo elemento che compone l'architettura OAS.
Sara' perche' sono un nostalgico, sara' perche' e' piu' veloce... ma preferisco editare i file di configurazioni piu' complessi con il caro, vecchio vi (eg. per aggiungere un virtual su $ORACLE_HOME/Apache/Apache/conf/httpd.conf).
Quando si effettua una modifica della configurazione di un qualsiasi componente di OAS e' necessario ricordare di segnalare la modifica al DCM perche' aggiorni il Metadata Repository:

$ vi httpd.conf					# Effettuare le modifiche sulla configurazione
$ dcmctl updateConfig -ct ohs			# Registrare le modifiche sul DCM
$ opmnctl status				# Riavviare il server
$ opmnctl stopproc process-type=HTTP_Server
$ opmnctl status
$ opmnctl startproc process-type=HTTP_Server
$ opmnctl status

Alcune configurazione sono effettivamente piu' semplici operando con un editor del sistema operativo. In particolare se le modifiche sono pesanti oppure debbono essere replicate tra piu' server. Per le altre configurazioni EM va benissimo.

E' assolutamente importante documentare ogni configurazione effettuata. Puo' essere utile questo script SQL che raccoglie alcuni elementi della configurazione (naturalmente sono molto piu' completi il PDA (Portal Diagnostic Agent) e gli script descritti in ML.244112.1).

L'accesso a molti servizi si effettua via web. Sembra semplice ma... i link e le possibilita' sono cosi' abbondanti che ci si perde!
Puo' essere molto utile costruire una semplice pagina web che contenga i link ai principali componenti come in questo esempio che ovviamente va personalizzato a seconda della configurazione utilizzata. Non tutti gli accessi sono disponibili, alcuni sono abilitati sono per un accesso locale (dal sistema stesso), altri sono protetti da password, ... ma con un elenco completo e' possibile controllare facilmente se i diversi componenti operano correttamente.

Il numero di log disponibili in OAS e' particolarmente elevato. In pratica ogni componente ha una sua directory di log (a volte /log altre volte /logs) e qualche file di log, error, trace.
Capire in quale file di log andare a cercare informazioni in caso d'errore non e' semplice... spesso si fa prima a cercare gli ultimi file modificati! Per avere l'elenco di tutti i log presenti, ordinati per data di modifica:

cd $ORACLE_HOME
find -name '*.log' | xargs ls -ltr

I log di Apache sono tra i piu' importanti da controllare. Tipicamente sono centinaia perche' utilizzano il rotate; per fare un po' di pulizia tra i log di Apache:

cd $ORACLE_HOME/Apache/Apache/logs
find -name '*log*' -mtime +120 -exec rm -f {} \;

Anche le JVM hanno un log! Per disporre di informazioni sul garbage collector (ed in particolare verificare che non venga richiamato il Full Garbage Collector che e' sospensivo) le JVM vanno attivate con il parametro -verbose:gc. Con il parametro impostato vengono visualizzati tutti i GC con l'indicazione del tempo (msec dall'avvio della JVM), il tipo di GC, la quantita' di memoria prima e dopo esecuzione del GC ed il tempo impiegato. Il log seguente riporta una situazione normale per i primi tre casi e di crisi (con blocco dell'applicazione per diversi secondi) per gli ultimi tre messaggi di log:

3934.364: [GC 302899K->248198K(466048K), 0.0434190 secs]
3973.417: [GC 306437K->253184K(466048K), 0.0511950 secs]
3997.997: [GC 311424K->281647K(466048K), 0.0783690 secs]
...
13958.076: [Full GC 381647K->365175K(466048K), 1.8070920 secs]
13960.156: [Full GC 404740K->379740K(466048K), 1.8893880 secs]
13962.789: [Full GC 405976K->340862K(466048K), 1.5325050 secs]

Parlare di Small Footprint con OAS, ovvero configurare in modo "leggero" gli ambienti ed i servizi, e' un ossimoro.
Pero' qualcosa si puo' fare... Naturalmente il numero di utenti, connessioni, complessita' di programmi, ... supportati saranno inferiori. Tuttavia e' possibile utilizzare tali configurazioni ridotte per ambienti non critici utilizzati per lo sviluppo di applicazioni, POC, demo, ...
Innanzi tutto escludere i componenti non necessari. Le prime cose piu' semplici si fanno con l'EM:

• Disabilitare componenti non necessari (eg. wireless): EM->Farm->Application Server: midtier.company.com -> Home -> Enable/Disable Components
• Ridurre il numero di richieste gestibili dai server HTTP: EM -> Farm-> Application Server: midtier.company.com -> Home -> HTTP_Server -> Administration -> Server Properties -> Client Request Handling -> Maximum Requests Processed Simultaneously Portando il parametro dal valore di default (150) ad un valore piu' basso (eg. 50).
• Ridurre il numero di processi per i server HTTP: EM -> Farm-> Application Server: midtier.company.com -> Home -> HTTP_Server -> Administration -> Advanced Server Properties -> httpd.conf -> Modificare i parametri:

  MinSpareServers 5
  MaxSpareServers 20
  StartServers 5
  

  con valori inferiori, per esempio:

  MinSpareServers 2
  MaxSpareServers 10
  StartServers 2
  

• Ridurre la quantita' di memoria massima assegnata ai Java Container: EM -> Farm -> Application Server: infra.company.com -> OC4J: OC4J_SE -> Administration -> Server Properties -> Command Line Options -> Java Options E modificare il parametro -Xmx128m (set maximum Java heap size)
• Ridurre la quantita' di memoria massima assegnata alla Web Cache: EM -> Farm -> Application Server: infra.company.com -> Web Cache -> -> Administration -> Properties -> Web Cache -> Resource Limits and Timeouts Portare i parametri da :

  Maximum Incoming Connections	700
  Cache Memory Limit(MB)		500
  

  a:

  Maximum Incoming Connections	100
  Cache Memory Limit(MB)		100
  

• Escludere l'avvio degli Enterprise Manager (attivandoli solo quando necessario per attivita' di amministrazione).
  Per disattivare gli EM il comando e' emctl stop iasconsole per le istanze IAS e emctl stop dbconsole per l'istanza RDBMS (la dbconsole e' uno strumento standard per l'amministrazione di Oracle 10g).
• Apache ha un'ampia serie di moduli disponibili. Alcuni di questi hanno un peso considerevole. Se un Apache non viene utilizzato per accedere ad Oracle in modo diretto conviene escludere il modulo mod_plsql, il risparmio in termini di memoria e' notevole.

E' molto importante ricordare di riattivare ogni componente prima di una nuova installazione, di un upgrade o di una patch. Le procedure di installazione infatti controllano le porte socket gia' aperte per non assegnarle ai nuovi servizi; mentre le procedure di upgrade potrebbero non aggiornare i componenti non attivi... Al termine dell'attivita' potranno essere nuovamente disabilitati.
Cosi' come possono essere ridotti i parametri indicati possono essere anche aumentati! Sebbene i valori di default siano largamente adatti per la maggioranza delle installazioni, dopo una necessaria attivita' di controllo e tuning, e' possibile che per configurazioni di maggiori dimensioni sia opportuno incrementarli (eg. -Xmx1024M -Xms1024M).

Sul tuning di OAS e' molto completo questo documento.

Il discorso sulle versioni di OAS e' lungo e complesso... ma questa tabella riassuntiva riporta le principali:

Release	Versione	Note
OAS	1.0, 2.0, 2.1, 3.0, 3.1, ...	Web Server proprietario
iAS 8i	1.0	Apache, OSE (Oracle Servlet Engine), JVM nel DB
9i AS	1.0.2.2
9i AS R2	9.0.2	JDK 1.2, 1.3, 1.4 EJB 1.1, OC4J, alcune features EJB 2.0
	9.0.3	EJB 2.0
OAS 10g	9.0.4	Motore + robusto ed efficiente, Web Cache ottimizzata, OPatch (9.0.4.1)
OAS 10g R2	10.1.2	Discoverer, installazione piu' semplice, topologia della farm, JDK 1.5
	10.1.3	OC4J only: full J2EE 1.4, EJB 3.0, ADF Struts 1.2, SOAP 1.1 e 1.2
	10.1.4	Portal only: Molteplici nuove funzionalita' su Portal, WSRP consumer
OAS R11	11.0	Vedremo!

Anche per Portal vi sono state piu' versioni disponibili nel tempo...

Qui riportiamo qualche comando per capire quali versioni stiamo utilizzando!

$ ls -d $ORACLE_HOME/inventory/Components*/*/*

SQL> SELECT * FROM IAS_VERSIONS

$ $ORACLE_HOME/bin/oidldapd -version

$ ORACLE_HOME/bin/ldapsearch -h oid_host -p oid_port -D "cn=orcladmin" -w orcladmin_password \
	-b "cn=base,cn=oracleschemaversion" -s base "objectclass=*" orclproductversion

$ ORACLE_HOME/bin/ldapsearch -h oid_host -p oid_port -D "cn=orcladmin" -w orcladmin_password \
	-b "cn=oraclecontext" -s base "objectclass=*" orclversion

Come lanciare i comandi e' ovvio... spero!

Un portale permette agli utenti di accedere informazioni provenienti da differenti sorgenti di dati attraverso un singolo punto di ingresso. Un portale inoltre permette a ciascun utente di creare una propria vista privata dei dati definendone le sorgenti e personalizzandone i contenuti. Oracle Application Server Portal 10g (OAS Portal) e’ un ambiente completo ricco di funzionalita’ ma anche complesso sia nell’architettura che nella configurazione dei vari componenti necessari al suo corretto e completo funzionamento.

Le applicazioni gestite da Oracle Portal sono chiamate Portlet e dialogano con il PPE con un protocollo SOAP (proprietario). E' quindi necessario utilizzare l'Oracle PDK (Portal Development Kit) per realizzare applicazioni Portlet con Java, oppure realizzare Portlet in PL/SQL con le relative API.

Il passaggio delle applicazioni tra ambienti viene effettuato con i Transport Set. E' opportuno utilizzare l'utente portal e non l'utente orcladmin per effettuarli.
E' anche opportuno utilizzare lo script sv_rept.sql (Schema Validation Utility) per controllare l'eventuale presenza di oggetti non congruenti sul DB prima di effettuare export/import di Transport Set.

Dalla versione 10.1.4 sono state introdotte nuove possibilita' per lo sviluppo di Portlet in osservanza degli standard introdotti da organismi internazionali. Quindi ora Oracle Portal puo' ospitare:

• Applicazioni Java realizzate utilizzando il PDK Oracle
• Applicazioni PL/SQL realizzate con le API SQL di Oracle Portal
• Applicazione Java realizzate utilizzando le API standard JSR-168
• Applicazioni che rispondono al protocollo WSRP (eg. un WSRP Producer realizzato in .NET con C#)

In qualche condizione puo' essere necessario ricaricare le java stored procedures (eg. a fronte di un'installazione di una patch). Per effettuare la ricompilazione utilizzare questo script.

Alcune attivita' di riconfigurazione di portal vengono eseguite con comandi specifici: ptlasst (o ptlconfig in 10g R2), ptllang, ... Ad esempio per il cambiamento di un virtual host e' necessario effettuare il rewire di portal con questo script (nb la sintassi dipende dalle versioni: nelle piu' recenti il comando ptlasst e' stato sostituito con ptlconfig).

Come si passa in modalita' di editing di una pagina? Basta aggiungere ?_mode=16 all'URL della pagina stessa!
La verifica delle prestazioni e' un aspetto molto importante con Portal. A parte l'utilizzo fortemente consigliato della Web Cache (vi sono due ordini di grandezza di differenza) e' utile il parametro ?_debug=0 per controllare i tempi di risposta di ogni singolo portlet.

Per sviluppare pagine in PL/SQL con un utente differente da portal (cosa fortemente consigliata) e' necessario definire grant e sinonimi con lo script SQL provsyns.sql. Le API PL/SQL sono cosi' disponibili, tuttavia per effettuare prove da linea di comando e' necessario impostare l'ambiente come nel seguente esempio:

SQL> BEGIN
  2   portal.wwctx_api.set_context('username','password');
  3  IF (PORTAL.wwsec_api.is_user_in_group(PORTAL.wwctx_api.get_user_id, 2))
  4  THEN
  5    DBMS_OUTPUT.PUT_LINE('IN GROUP');
  6  ELSE
  7    DBMS_OUTPUT.PUT_LINE('NOT EXISTS');
  8  END IF;
  9  END;
 10  /

Con Oracle Portal vi sono spesso problematiche sulle performances. Le possibilita' di sviluppo di Portali sono molteplici ma vanno analizzati fin da subito gli impatti delle scelte dell'architettura applicativa utilizzata (Portlet PL/SQL o Java, complessita' delle pagine/tipi di Item utilizzati, utilizzo dell'Istant Portal, modalita' di SSO, utilizzo dell'HTTPS, ...). Generalmente la componente che risulta piu' sfruttata e' la CPU del DB Server.
L'utilizzo del Caching a livello di pagina e' fondamentale e quindi la cache non va mai disabilitata (le differenze sono di almeno un'ordine di grandezza nei tempi di risposta). Per abilitare in modo massivo l'utilizzo della cache (MN 251763.1) si puo utilizzare il comando: update wwpob_page$ set cache_mode=1, cache_expires=0 where siteid=33; E quindi quindi ripulire le varie cache e riavviare.

Con l'utilizzo del Virtual Private Portal (VPP) su una stessa Farm si possono ospitare portali diversi e tra loro separati anche dal punto di vista di amministrazione. Ogni portale corrisponde ad un differente subscriber che ha utenti, abilitazioni, page group, pagine, ... completamente seprati dagli altri subscriber.
Dal punto di vista tecnico il VPP utilizza le seguenti tecniche:

• RDBMS: viene utilizzato il Virtual Private Database (VPD) per le tabelle di Portale con visibilita' specifica per subscriber.
• LDAP: al momento della creazione di un subscriber viene creato un nuovo ramo sull'LDAP che contiene tutti i dati (utenti, gruppi, ...) del subscriber.

Per abilitare il VPP il comando e':

cd $ORACLE_HOME/portal/admin/plsql/wwhost
enblhstg.csh -pc infra.company.com:1521:iasdb -ps portal -pw KLK9801L \
    -sc infra.company.com:1521:iasdb -ss orasso -sw AgD31jRj -h infra.company.com \
    -p 3060 -d "cn=orcladmin" -w ias_admin_pass -mode both > vpp.log 2>&1

cd $ORACLE_HOME/portal/admin/plsql/wwhost
addsub.csh -name subs_name -id 3000 -type all -pc infra.company.com:1521:iasdb -pp sys -ps portal -pw KLK9801L \
    -sc infra.company.com:1521:iasdb -sp sys -ss orasso -sw AsD31jRj -h infra.company.com -p 3060 -d "cn=orcladmin" \
    -w ias_admin_pass -a portal.050208.1210 -mode both > sub.log 2>&1

cd $ORACLE_HOME/portal/admin/plsql/wwhost
addburl.csh -name subs_name -pc infra.company.com:1521:iasdb -pu http://subs_name.company.com:7777/pls/portal \
    -ps portal -pw KLK9801L -su https://sso-infra.company.com/pls/orasso -sc infra.company.com:1521:iasdb \
    -ss orasso -sw AsD31jRj > subs_url.log 2>&1

Per operare in PL-SQL nel contesto di un subscriber si puo' utilizzare questo settaggio:

DECLARE
  p_user_name VARCHAR2(60) := 'user';
  p_password VARCHAR2(60) := 'pass';
  p_company VARCHAR2(60) := 'XYZ';
BEGIN
  wwctx_api.set_context(p_user_name,p_password,p_company);
EXCEPTION
   WHEN OTHERS THEN
      dbms_output.put_line(SubStr('Error '||TO_CHAR(SQLCODE)||': '||SQLERRM, 1, 255));
      RAISE;
END;

Con il Single Sign-On (SSO) si proteggono porzioni di siti ed applicazioni. La tecnica utilizzata da OAS e' molto sofisticata e consente di proteggere in modo sicuro (scegliendo tra diversi tipi di autenticazione compresa la modalita' di strong autentication) applicazioni interne (dette Partner Application) o di altra provenienza (dette External Application). La registrazione delle applicazione puo' avvenire in diversi modi: da interfaccia grafica, agendo su alcune tabelle dell'utente ORASSO, ... Utile e' anche questo script che effettua la registrazione.

Quando un utente accede ad una risorsa protetta dall'SSO il web server controlla i diritti dell'utente richiamando il mod_osso, se l'utente non ha ancora effettuato il login il browser viene ridiretto sulla pagina di login. Quando il login viene effettuato con successo viene rilasciato un cookie. Sucessivi accessi alle risorse OAS avvengono controllando il contenuto del cookie e quindi un singolo login e' sufficiente per accedere a tutte le applicazioni. La figura seguente riporta il flusso seguito (nei casi piu' semplici):

Qualche ulteriore dettaglio: L'SSO utilizza cookie di sessione quindi non salvati su disco. La ridirezione verso l'SSO avviene con un messaggio HTTP 302 Found restituito dal web server, e' quindi il browser ad autenticarsi in modo diretto con il server che ospita l'SSO. In realta' i cookie rilasciati sono due: uno da parte dell'SSO ed uno da parte del mod_osso (il primo serve per richiedere piu' login allo stesso utente, il secondo per non "disturbare" inutilmente l'SSO per un utente che si e' gia' autenticato sull'applicazione protetta). Portal utilizza una ulteriore cache ed ha un'implementazione "parallela" dell'SSO per rendere piu' efficenti gli accessi (alcune tabelle dell'utente portal risultano quindi analoghe a quelle dell'utente ORASSO). Tipicamente l'SSO viene protetto con l'SSL, la configurazione non e' banale... nell'ultimo paragrafo di questo documento e' riportato un esempio completo. Ogni applicazione ha un Token assegnato che e' registrato nella tabella PAP di ORASSO e che viene passato come parametro Site2pstoreToken nelle richieste di autenticazione. Le applicazioni protette dall'SSO vengono riconosciute per il loro URL, quindi la configurazione di Virtual Host, le regole di rewrite, il modulo mod_osso, ... in Apache sono fondamentali!
Questa semplice architettura viene resa un poco piu' complessa nel caso di Portal che utilizza proprie tabelle e caching (cfr documentazione Portal).

Il tipo di autenticazione utilizzato dall'SSO e' configurabile nel file $ORACLE_HOME/sso/conf/policy.properties. Oltre alle modalita' fornite da Oracle e' anche possibile utilizzare software di autenticazione forniti da terze parti.
Per implementare tale integrazione e' necessario creare un plug-in di autenticazione. Si tratta di realizzare una classe java che implementi l'interfaccia SSOServerAuthInterface fornita da Oracle e quindi configurare il file policy.properties in modo da richiamarla. Analogamente avviene per la gestione di custom cookie.
Le ultime versioni della documentazione Oracle sono assai complete e contengono esempi esaustivi... certo non e' immediato.

Un utilizzo in produzione di OAS rivolto verso Internet non puo' prescindere dall'utilizzo di Firewall, Load Balancer, Proxy, ... oggetti che introducono non banali problematiche di networking. Sono strumenti necessari per la sicurezza e vantaggiosi per le prestazioni, ma e' necessaria un'attenta configurazione in modo da avere un sistema perfettamente funzionante (eg. Perche' non funziona l'EM con un load balancer?).

La figura seguente indica le connessioni che e' necessario abilitare su Firewall (per una semplice configurazione OAS di default):

La prima interfaccia con gli utenti e' sempre il web server. OAS utilizza, da parecchie versioni, Apache 1.3 come web server ed anche se lo chiama OHS (Oracle HTTP Server) le differenze rispetto alla versione pubblica di Apache sono poche e riguardano principalmente la parte SSL (eg. wallet, mod_osso) e moduli aggiuntivi (eg. mod_plsql). Apache e' veramente molto potente ed offre parecchie possibilita'...
La configurazione di Apache avviene specificando le sue direttive che possono essere poste a livello globale, per virtual host, per directory, per location, per singolo file, ... Le possibilita' sono molte ed e' impossibile citarle tutte: virtual host, regole di rewrite, gestione SSL, modalita' di logging, ...

Qualche indicazione di base? I file di configurazione sono posti nella directory Apache/conf (il file piu' importante e' httpd.conf che contiene la configurazione di base e l'include degli altri file di configurazione), i log nella directory Apache/logs (i file piu' importanti sono access* ed error* che riportano rispettivamente l'elenco di tutti gli accessi (con IP del chiamante e pagina richiamata) e gli errori occorsi). Per controllare lo stato di Apche e' generalmente definito l'URI /server-status (in genere e' protetto quindi va acceduto da local host per esempio con wget localhost:7777/server-status).
Una delle poche direttive specifiche per Oracle e' UseWebCacheIp che indica di utilizzare l'indirizzo del client e non della web cache nel logging e nei controlli di accesso. Parametro utile quando si vuole impostare una sicurezza basata sugli IP dei client. Oracle inoltre ha introdotto alcuni suoi moduli specifici (eg. mod_plsql, mod_osso), per la gestione dei certificati utilizza i wallet, la struttura delle directory e dei file di configurazione e' un poco differente rispetto a quella di default ed infine il lancio dei programmi va fatto con OPMN e non direttamente...

Su ambienti di produzione e' spesso utilizzata la porta 80 poiche' e' quella di default per il protocollo HTTP. In questo caso e' necessario configurare sia Apache che la WebCache (e quest'ultima deve essere configurata per essere lanciata come root utilizzando lo script $ORACLE_HOME/webcache/bin/webcache_setuser.sh come in Note:291579.1). ...

Per approfondire tali argomenti, oltre alla documentazione Oracle (eg. per l'SSL leggere su Metalink la nota N. 351339.1, per le versioni la nota N. 260449.1), vi e' un'ampia documentazione su Apache 1.3 e sucessive. Qualche esempio utile e' riportato nel paragrafo sulle configurazioni particolari come quello sui reverse Proxy o sull'authentication.

Avete dimenticato le password?
OAS genera password quasi impossibili da ricordare per alcuni utenti (e' giusto, altrimenti sarebbe troppo facilmente attaccabile). Per ricavarle nuovamente si puo' utilizzare lo script: get_pwd.sh Lo script legge le password dall'LDAP.

Dalla versione 9.0.4 sono state introdotte policy di sicurezza piu' restrittive... Tra le altre cose puo' succedere che venga bloccato l'utente orcladmin (attenzione vi sono piu' utenti orclamdin: cn=orcladmin e cn=orcladmin,cn=Users,dc=company... che riferiscono a diversi livelli dell'albero LDAP).
Nel primo caso e' utile il comando: oidpasswd connect=DB_NAME unlock_su_acct=true negli altri casi si puo' agire facilmente da interfaccia grafica (oidadmin).

Se invece sono le password dell'Enterprise Manager ad essere state dimenticate...

$emctl set password newPassword
$emctl authenticate newPassword

OAS e' una ambiente molto completo che comprende diversi componenti. L'impatto sul sistema operativo e' analogo a quello degli altri ambienti che utilizzano le stesse tecnologie (per non far nomi: Bea, Websphere, Tomcat/JBoss, IIS per la parte application e MySQL, SQLServer, DB2 per la parte DB).
La manualistica Oracle riporta in modo preciso i requisiti dell'installazione e la procedura d'installazione li verifica con attenzione. Sono adatti alla maggioranza delle configurazioni.
Naturalmente voi non avrete mai problemi... ma poiche' io sono parecchio sfortunato controllo sempre:

• La memoria perche' il grande numero di processi ne richiede parecchia.
• Le connessioni di rete perche' in diverse condizioni queste restano aperte e possono raggiungere il limite bloccando tutto.
• Il DB perche' spesso e' il collo di bottiglia di applicazioni non ancora ottimizzate.

La piattaforma OAS e' molto sofisticata e flessibile, le configurazioni utilizzabili possono quindi essere molte ma anche complesse. Nel seguito sono riportati elementi su alcune configurazioni particolari:

• Utilizzo porte di sistema (eg. utilizzare le porte 80 per l'HTTP e 443 per l'HTTPS)
• Configurazione con Reverse Proxy e comandi utili Apache
• Configurazione in Load Balancing
• Configurazione del linguaggio Italiano su Portal
• Upload file

La Configurazione HTTPS/SSL/Certificati e' un argomento cosi' simpatico che, anziche' scriverne solo qualche nota in un file di testo, l'ho tenuto come ultimo capitolo!

E' buona norma utilizzare l'SSL (Secure Socket Layer) per la server authentication su ambienti di produzione. Questo consente di avere la certezza di collegarsi con il server corretto e tutto lo scambio di messaggi per la fase di login avviene in modo criptato. La parte di client authentication consente di avere la certezza sull'identita' degli utenti ed e' spesso utilizzata ma con minor frequenza. Infine puo' essere utilizzato l'SSL anche per proteggere altre parti dei siti o delle applicazioni web.
OAS supporta in modo molto completo gli standard relativi e la sua configurazione e' piuttosto lineare. Ma non molto semplice... ecco perche' l'ho tenuto come ultimo argomento!

Poiche' il taglio di questo documento e' pratico vi risparmio la descrizione dei protocolli HTTPS, SSL, la teoria dei certificati, l'X509... insomma dovete gia' sapere tutto! Le particolarita' di OAS rispetto ad altri ambienti sono:

• Per la gestione dei certificati OAS utilizza un wallet manager. I certificati debbono essere quindi richiesti e registrati con owm (Oracle Wallet Manager). Una volta inseriti nel wallet i certificati questi sono disponibili al web server e la configurazione e' molto semplice.
• L'architettura di OAS utilizza diversi web server: per l'infrastruttura, per i mid tier sia per le istanze dedicate a Portal che a quelle che ospitano servizi Java... Deve essere ben chiaro dove si deve agire e cosa si vuole ottenere! E' anche molto importante, e questo vale per ogni configurazione con servizi web e non solo per OAS, verificare i numeri di porte utilizzate.
• Per l'avvio dei diversi componenti (eg. Apache) OAS utilizza l'opmn. Quindi i parametri di alcuni programmi (eg. l'utilizzo dell'SSL da parte di Apache) va configurato nel file di definizione dell'opmn (opmn.xml).
• Se si modificano manualmente i file di configurazione (come faccio sempre nell'esempio che segue), bisogna ricordarsi di aggiornare il Metadata repository con dcmctl .... Per vedere i risultati delle modifiche effettuate ovviamente bisogna anche riavviare i servizi di cui e' stata variata la configurazione (sara' ovvio... ma l'ho scritto perche' l'ho dimenticato spesso).

1. Verifiche e controlli
   
2. Creazione wallet
   
3. Configurazione Apache
   
4. Configurare SSO e OIDDAS in SSL Mode
   
5. Configurare la client authentication (opzionale)
   
6. Proteggere siti ed applicazioni (opzionale)
   

1. Verifiche e controlli
   Funziona tutto? E' una domanda importante. Prima di cercare di configurare qualcosa di nuovo e' necessario controllare il corretto funzionamento di ogni componente (eg. login, SSO, OIDDAS, ...). La stessa cosa va fatta ad ogni passo... se c'e' qualcosa che non va bisogna fermarsi e metterlo a posto prima di proseguire. Se avete creato un file di link come quello d'esempio e' il momento di usarlo!
2. Creazione wallet
   Vanno create le richieste dei server certificate, inviate alla CA, caricate sul wallet, salvato il wallet in modalita' AutoLogin, ... alla fine nella directory scelta (eg. wallet1) saranno presenti i due file cwallet.sso ewallet.p12. Il comando e' owm & e non lo descrivo perche' e' un programma X!
3. Configurazione Apache
   
   1. La configurazione dei parametri del web server per l'SSL si effettua nel file $ORACLE_HOME/Apache/Apache/conf/ssl.conf Molto importanti sono ServerName, Listen e Port, generalmente i valori presenti per default sono corretti ma non e' sempre cosi'. Naturalmente i valori di Listen/Port debbono essere univoci e non assegnati ad altri servizi.
   2. Per utilizzare il Server Certificate importato nel passo precedente va sempre modificato il file $ORACLE_HOME/Apache/Apache/conf/ssl.conf in modo da puntare al nuovo wallet, e' anche opportuno verificare/modificare le porte utilizzare per l'SSL. inserendo/modificando le direttive nel virtual corretto (la seconda non serve se si e' impostato AutoLogin nel wallet):

          SSLWallet file:/home/infra/Apache/Apache/conf/ssl.wlt/wallet1 
          # SSLWalletPassword welcome1
      

   3. Se si vogliono utilizzare porte di sistema (<1024) per l'HTTPS e' necessario abilitare Apache a girare come root. E' una configurazione comune poiche' la porta di default per il protocollo HTTPS e' la 443.

      # chown root $ORACLE_HOME/Apache/Apache/bin/.apachectl
      # chmod 6750 $ORACLE_HOME/Apache/Apache/bin/.apachectl
      

   4. Per attivare Apache con SSL abilitato vanno modificati i parametri di avvio. Ovviamente con OAS va fatto su $ORACLE_HOME/opmn/conf/opmn.xml cambiando l'impostazione ssl-disabled in ssl-enabled per il servizio HTTP_Server:

               <ias-component id="HTTP_Server">
                  <process-type id="HTTP_Server" module-id="OHS">
                     <module-data>
                        <category id="start-parameters">
                           <data id="start-mode" value="ssl-enabled"/>
                        </category>
                     </module-data>
                     <process-set id="HTTP_Server" numprocs="1"/>
                  </process-type>
               </ias-component>
      

   5. Per provare? Aggiornare le modifiche ed effettuare il restart di Apache con:

      dcmctl updateconfig
      opmnctl stopproc process-type=HTTP_Server 
      opmnctl startproc process-type=HTTP_Server 
      

      Quindi con un browser accedere via https e provare tutti i link...
4. Configurare SSO e OIDDAS in SSL Mode
   Sono necessari diversi passi, alcuni dei quali opzionali:
   1. Scommentare le seguenti opzioni dell' $ORACLE_HOME/Apache/Apache/conf/ssl.conf

          RewriteEngine on
          RewriteOptions inherit
      

   2. Per rendere obbligatorio l'utilizzo dell'SSL per l'SSO vanno inserite le seguenti direttive al termine del file $ORACLE_HOME/sso/conf/sso_apache.conf (attenzione, a seconda delle versioni i file utilizzati possono essere diversi, in realta' non vi e' alcuna differenza: si tratta di semplici include dell'httpd.conf). Generalmente sono gia' presenti per default e se e' attivo l'SSL "proteggono" l'SSO, puo' essere anche utile commentarle per prova:

      <IfDefine SSL>
          <location "/sso/auth">
              SSLRequireSSL
          <location>
          <location "/sso/ChangePwdServlet">
              SSLRequireSSL
          <location>
      <IfDefine>
      

   3. Configurare al fondo di $ORACLE_HOME/Apache/modplsql/conf/dads.conf (anche questa configurazione generalmente e' gia' presente):

      <IfDefine SSL>
          #Login URL for single sign-on server and external applications 
          <Location "/pls/orasso/*[Ll][Oo][Gg][Ii][Nn]"> 
              SSLRequireSSL 
          </Location> 
          #Change password page 
          <Location "/pls/orasso/*[Pp][Aa][Ss][Ss][Ww][Oo][Rr][Dd]"> 
              SSLRequireSSL 
          </Location>
          #External application login URL 
          <Location "/pls/orasso/*[Ff][Aa][Pp][Pp][Uu][Ss][Ee][Rr]"> 
              SSLRequireSSL 
          </Location>
      </IfDefine>
      

   4. Eseguire la registrazione del nuovo indirizzo del Single Sign-On
      Sull'istanza di infrastruttura, dopo aver salvato la configurazione ed il file osso.conf:

      cd $ORACLE_HOME/sso/bin
      ./ssocfg.sh https sso.company.com 4443
      
      $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/sso/lib/ossoreg.jar \
          -oracle_home_path $ORACLE_HOME \
          -host infra.company.com \
          -port 1521 \
          -sid DBNAME \
          -site_name sso.company.com \
          -config_mod_osso TRUE \
          -mod_osso_url https://sso.company.com:4443 \
          -config_file /home/infra/Apache/Apache/conf/osso/osso.conf \
          -u root
      

      Sull'istanza midtier, dopo aver salvato la configurazione ed il file osso.conf:

      $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/sso/lib/ossoreg.jar \
          -oracle_home_path $ORACLE_HOME \
          -host infra.company.com \
          -port 1521 \
          -sid DBNAME \
          -site_name sso.company.com \
          -config_mod_osso TRUE \
          -mod_osso_url https://sso.company.com:4443 \
          -config_file /home/mid/Apache/Apache/conf/osso/osso.conf \
          -u root
      
      $ORACLE_HOME/portal/conf/ptlconfig -dad portal -sso
      

      Se il lancio degli script non ha riportato errori debbono essere registrate le modifiche e riavviati OHS ed OC4J_SECURITY.

      Se ci sono problemi... Il comando ptlconfig puo' anche essere richiamato con i parametri -host e -port (utile per i virtuali). Vanno controllate le tabelle di ORASSO PAP ed ENABLER e la PAP di PORTAL. I riferimenti sugli URL del DAS sono mantenuti sull'OID in orcldasurlbase cn=OperationURLs,cn=DAS,cn=Products,cn=OracleContext e Portal utilizza una cache OID (che puo' essere rinfrescata) ... Vanno verificati i Site ID Token: l'URL di richiamo li contiene nella variabile Site2pstoreToken dopo l'indicazione della versione del cookie (ogni valore e' separato con un ~). Il valore presente nell'URL e' quello contenuto nell'osso.conf e deve corrispondere ad un entry della PAP.

      Se la configurazione e' piu' complessa (eg. load balancing, cluster, reverse proxy, ...)... ci vuole il doppio di tempo poiche' vi sono piu' ambienti da configurare e bisogna fare il doppio attenzione: quindi si impiega quattro volte tanto! A parte gli scherzi e' importante verificare che tutti gli ambienti e componenti siano attivi (compreso il dcm-daemon) e che vengano allineati in modo sincronizzato.

5. Configurare la client authentication (opzionale)
   Per rendere obbligatoria la SSL Client Authentication (che non e' necessaria per il dialogo in HTTPS ma e' utile se si vuole essere certi dell'identita' del client) vi sono diversi passi:
   1. Configurare la client autentication sul Java Container
      Per richiedere la client authentication su un Java Container nel file $ORACLE_HOME/sso/conf/sso_apache.conf. va posta la direttiva:

         SSLVerifyClient require 
      

   2. Configurare l'SSO per i Digital Certificate
      In $ORACLE_HOME/sso/conf/sso_apache.conf

      <IfModule mod_ossl.c> 
          Oc4jExtractSSL on 
          <Location /sso> 
              SSLOptions +ExportCertData +StdEnvVars 
          <Location> 
      <IfModule>
      

      In $ORACLE_HOME/j2ee/OC4J_SECURITY/application-deployments/sso/web/orion-web.xml

      <jazn-web-app runas-mode="true" />
      

      In $ORACLE_HOME/sso/conf/policy.properties vanno inseriti i parametri seguenti (l'ultimo parametro, commentato, serve se si vuole permettere l'utilizzo di login+password in caso fallisca la client autentication con certificato):

      DefaultAuthLevel = MediumHighSecurity 
      ...
      MediumHighSecurity_AuthPlugin = oracle.security.sso.server.auth.SSOX509CertAuth
      # CertificateAuthFallback=true
      

   3. Riconoscere i certificati utente
      I certificati utente debbono essere riconosciuti validi dal web server. Se si utilizza l'OCA (Oracle Certification Authority) questa viene registrata ma se i certificati hanno sono emesse da altre CA i root certificate debbono essere inseriti nel wallet. L'inserimento avviene generalmente con l'interfaccia grafica, ma e' anche possibile utilizzare un comando:

      orapki wallet add -wallet /home/infra/Apache/Apache/conf/ssl.wlt/wallet1 -trusted_cert -cert Cert.crt -pwd welcome1
      

      La client autentication, per funzionare con il plug-in fornito da Oracle, richiede che il certificato dell'utente sia memorizzato sull'OID. Questo avviene in automatico se si utilizza l'OCA per l'emissione dei certificati. Se viene utilizzata un'altra CA il certificato utente deve essere inserito manualmente (o con qualche programma). Per inserire un certificato nell'OID puo' essere utile il comando:

      setenv NLS_LANG AMERICAN_AMERICA.UTF8 
      ORACLE_HOME/bin/ldapmodify -h <directory_host> -p <directory_ssl_port> -D "cn=orcladmin" -w <password> -f <file_name.ldif>
      

      Dove il file contiene:

      dn: cn=meob,cn=users,dc=xenialab,dc=it 
      changetype: modify 
      replace: usercertificate 
      usercertificate::MIIC3TCCAkYCAgP3MA0GCSqGSIb3DQEBBAUAMIG8MQswCQ 
       NYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEXMBUGA1UEBxMOUmVkd29vZCBTaG9yZXMxGzAZBg 
      ...
       jnw4w6KVau2hcBgC9m4kzUGhHJ9b65v/zx7dIUKyJr4RF+lJhJg4/oYXxLrYHp5NAkHP4htT0gqCXiI=
      

6. Proteggere siti ed applicazioni (opzionale)
   La flessibilita' di Apache per proteggere siti ed applicazioni e' notevole e sono quindi molte le possibilita' con il solo web server (oltre al riferimenti gia' citati utile e' la documentazione Apache-SSL).
   Utilizzando le direttive SSLVerifyClient SSLRequireSSL Allow Deny Require vengono richieste le relative autorizzazioni (nota: se si utilizza la WebCache e' necessaria la direttiva UseWebCacheIp On per far utilizzare gli IP dei client dall'httpd come tipicamente richiesto dalle direttive Allow e Deny). Con regole di RewriteRule e ProxyPass e' possibile reindirizzare le richieste HTTP.
   A questo si aggiunge la possibilita' di proteggere con il Single Sign-On applicazioni Partner o External (dal punto di vista del web server l'SSO e' un modulo e la sua configurazione si effettua con una direttiva). L'SSO e' molto piu' sofisticato e completo degli altri metodi poiche' permette all'utente un login unico per piu' applicazioni. Oltre alle consuete configurazioni e' possibile agire sul file $ORACLE_HOME/Apache/Apache/conf/mod_osso.conf inserendo una direttiva come la seguente:

     <Location /Appl_path>
       Require valid-user
       AuthType Basic
     </Location>
   

   Come gia' visto in qualche esempio le direttive possono essere definite a livello globale ma puo' anche essere utilizzata una direttiva per limitarne l'utilizzo ad un vitual host, directory, location o file (con le direttive Apache <virtual>, <directory>, <location>, <file>)

   Il file interessati sono tipicamente $ORACLE_HOME/Apache/Apache/conf/httpd.conf, $ORACLE_HOME/Apache/Apache/conf/ssl.conf ma vi sono anche eccezioni come $ORACLE_HOME/sso/conf/sso_apache.conf se si vuole effettuare una configurazione per l'SSO.

Testo: Oracle Application Server Tips and Tricks
Data: 1 Maggio 2005
Versione: 1.0.21 - 25 Dicembre 2006
Autore: mail@meo.bogliolo.name