Ρύθμιση της Web Cache στο port 80 για Linux

Οι οδηγίες που ακολουθούν περιγράφουν τη ρύθμιση 11g Web Cache, τμήμα του Oracle Fusion Middleware Web Tier, ώστε να απαντά σε κλήσεις στο port 80. Εξ ορισμού αυτό το port χρειάζεται root access, οπότε μετά την εγκατάσταση θα χρειαστεί να κάνουμε μια μικρή ρύθμιση.

Αρχικά, ορίζουμε ως listening port το 80 και έπειτα επικυρώνουμε τις αλλαγές (apply changes) και σταματάμε την WebCache.

Τώρα από command-line ανατρέχουμε στο directory <WEB_TIER_HOME>/webcache/bin και ως root τρέχουμε το script:

./webcache_setuser.sh setroot <webtier_installation_user>

Με αυτόν τον τρόπο, αλλάζει ο owner του executable webcached και τίθεται το SUID ώστε ο installation user να μπορεί να εκτελέσει την webcache με δικαιώματα υπερχρήστη και να καταλάβει τελικά το port 80. Ξεκινάμε τη webcache ώστε να δούμε τις αλλαγές.

Αποτρέποντας χρήστες μας από το να συνδεθούν σε εφαρμογές του Oracle Application Server

Δυστυχώς ο Oracle Application Server (OAS) δεν διαθέτει τη δυνατότητα να ξεκινήσουμε τις εφαρμογές μας σε Administration mode (όπως κάνει ο Weblogic) ώστε να μην μπορούν να συνδεθούν οι χρήστες μας, αλλά παράλληλα ως διαχειριστές να κάνουμε διάφορες δουλειές. Το μόνο που μπορούμε να κάνουμε είναι να σταματήσουμε την εξυπηρέτηση για συγκεκριμένες εφαρμογές εξ ολοκλήρου, με την εξής σύνταξη:

opmnctl stopproc application=app1 application=app2

Έτσι, παρόλο που το OC4J group μας είναι active, οι χρήστες δεν μπορούν να συνδεθούν στις εφαρμογές app1, app2. Αντίστοιχα, για να ξεκινήσουμε τις εφαρμογές τις οποίες διακόψαμε:

opmnctl startproc application=app1 application=app2

Σε περίπτωση που δουλεύουμε σε cluster, θα χρησιμοποιήσουμε την κατάλληλη σύνταξη:

opmnctl @cluster stopproc application=app1 application=app2

Ενεργοποιώντας τα man pages του Oracle Application Server στο Linux

Έπειτα από την εγκατάσταση του Oracle Application Server, διάφορα συστατικά στοιχεία εγκαθιστούν τα δικά του κείμενα βοήθειας σε μορφή man pages. Ένα ενδεικτικό παράδειγμα από μια 10.1.3 εγκατάσταση περιλαμβάνει διάφορους καταλόγους, όπως του Apache, της Perl, κλπ.

Προκειμένου να έχουμε πρόσβαση και σε αυτά τα κείμενα, τροποποιούμε το αρχείο /etc/bash.bashrc.local που εκτελείται με το login του κάθε χρήστη, ώστε η μεταβλητή περιβάλλοντος του συστήματος manual, να συμπεριλαμβάνει τους καταλόγους που μας ενδιαφέρουν:

export MANPATH=$MANPATH:/opt/oracle/product/10.1.3.1/OracleAS_5/Apache/Apache/man

Κατά αυτόν τον τρόπο, μπορούμε να τα αναζητήσουμε με την εντολή man, τις σελίδες βοήθειας του Apache.

Αντικαθιστώντας τον Oracle XML Parser με τον Xerces ή τον Xalan στον Oracle Application Server

Ένα από τα πιο ενδιαφέροντα έργα στα οποία έχω συμμετάσχει, είναι αυτό της ψηφιακής υπογραφής εγγράφων με τη βοήθεια των καρτών του ΣΥΖΕΥΞΙΣ (http://www.syzefxis.gov.gr) Με τη βοήθεια ενός κατάλληλου API διασύνδεσης με τις συσκευές και την υλοποίηση του προτύπου XML Signatures από το open source project του Apache (http://santuario.apache.org) είναι εφικτή η πιστοποιημένη ανταλλαγή εγγράφων. Η βιβλιοθήκη του Apache XML Security στηρίζεται στις βιβλιοθήκες του Xerces και του Xalan, γεγονός που οδήγησε σε παράξενες συμπεριφορές όταν η εφαρμογή γινόταν deploy στον Oracle Application Server, καθώς ο default XML parser είναι αυτός της Oracle. Πιο συγκεκριμένα, η επιβεβαίωση της υπογραφής αποτύγχανε πάντοτε στο περιβάλλον του OAS, ενώ το standalone testing μου επιβεβαίωνε την ορθότητα.

Προκειμένου να ξεπεραστεί αυτό το πρόβλημα, υπάρχει ένα άρθρο (http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/how-to-swapxmlparser/doc/readme.html) που προτείνει την αλλαγή των βιβλιοθηκών σε μια εφαρμογή που βρίσκεται στον OAS. Ένας πιο σύντομος τρόπος, ειδικά αν πρόκειται να χρησιμοποιήσουμε και τον Oracle XML parser αργότερα σε κάποια σημεία της εφαρμογής μας, είναι προτού να ξεκινήσουμε την εργασία μας με Xalan και Xerces να ορίσουμε προγραμματιστικά τις μεταβλητές συστήματος κατάλληλα, ως εξής:

System.setProperty("javax.xml.parsers.DocumentBuilderFactory", "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");
System.setProperty("javax.xml.parsers.SAXParserFactory", "org.apache.xerces.jaxp.SAXParserFactoryImpl");
System.setProperty("javax.xml.transform.TransformerFactory", "org.apache.xalan.processor.TransformerFactoryImpl");

Αφότου εκτελέσουμε το τμήμα του κώδικα που μας ενδιαφέρει, μπορούμε να επαναφέρουμε τις τιμές των system properties στην αρχική τους τιμή.

Μερικές συμβουλές ασφάλειας (security advices) μετά την εγκατάσταση του Oracle Application Server

Έπειτα από την εγκατάσταση ενός Oracle Application Server, ιδιαίτερα για ένα public site, είναι απαραίτητο να προβούμε σε κάποιες ενέργειες που θα προστατεύσουν το σύστημά μας. Κάποιες από αυτές περιλαμβάνονται στα Security Guides της Oracle (http://download.oracle.com/docs/cd/B14099_19/core.1012/b13999/toc.htm)

• Αλλάξτε πάντα το index page του Apache γιατί δίδει πληροφορίες για το σύστημά σας (με πιο σημαντική την έκδοση). Για παράδειγμα από το index page του login.oracle.com:

• Παρομοίως, αλλάξτε την σελίδα που επιστρέφεται ως page not found. Επίσης δηλώνει την έκδοση των servers σας. Τροποποιείστε αυτή τη συμπεριφορά με την ErrorDocument ντιρεκτίβα του Apache
• Εκμεταλλευτείτε το mod_security του Apache (http://www.modsecurity.org/) που περιλαμβάνεται στις διανομές 10.1.2 και 10.1.3 του OAS ώστε να αποφύγετε XSS και SQL injections
  
• Περιορίστε την πρόσβαση σε URLs που έχουν ευαίσθητες πληροφορίες, μόνο σε χρήστες του εσωτερικού κόσμου ενός site. Τέτοιου είδους URLs είναι το /pls/orasso.home, /oiddas (εφόσον δεν προσφέρουμε self-service διαχείριση χρηστών), /em (για τους Application Servers βασισμένους στο 10.1.3), κλπ. Για να περιορίσουμε την πρόσβαση σε αυτές τις διευθύνσεις, αρκεί να μεταβάλλουμε τα κατάλληλα αρχεία όπως το mod_oc4j.conf ή το plsql.conf, με δηλώσεις του τύπου, που ορίζουν συγκεκριμένους clients που έχουν πρόσβαση στο URL.
  

<Location /oiddas >
Order deny,allow
Deny from all
Allow from localhost adminhost
</Location >

Εργαλεία load balancing για Application Servers

Μια μεγάλη, υψηλής διαθεσιμότητας αρχιτεκτονική, έχει ανάγκη για διαμοιρασμό φόρτου σε πολλαπλά επίπεδα, όπως HTTP, HTTP/s, LDAP κ.ο.κ. Στις περισσότερες περιπτώσεις προτείνεται η αγορά ενός hardware load balancer, που συνήθως διαθέτει και δυνατότητες SSL. Για τις ανάγκες όμως των πειραματισμών μας, μπορούμε να χρησιμοποιήσουμε και ειδικά προγράμματα που αναλαμβάνουν αυτό το έργο. Δυο από αυτά που έχω χρησιμοποιήσει είναι το distributor (http://distributor.sourceforge.net) και το balance (http://www.inlab.de/balance.html) για διαμοιρασμό φόρτου HTTP, HTTP/s, LDAP, LDAP/s στον Oracle Application Server.

To μεν distributor είναι πρόγραμμα ανοικτού κώδικα, γραμμένο σε Java και εκτελείται ως ένα απλό Java πρόγραμμα που διαβάζει τις ρυθμίσεις του από ένα αρχείο. Υποστηρίζει αλγόριθμους round-robin, hash και HTTP cookie-based για την τήρηση του session affinity. Ενδεικτικά ένα configuration file του distributor δείχνει ως εξής:

<distributor
bindaddr="0.0.0.0"
port="2001"
terminate_on_disable="no"
half_close="yes"
connection_timeout="2000"
connection_failure_limit="5"
control_port="2501"
service_type="http">


<algorithms>
<algorithm name="hash" hash_timeout="1800000"/>
<algorithm name="roundrobin"/>
</algorithms>


<target_group>
<target hostname="host1" port="2001"/>
<target hostname="host2" port="2001"/>
</target_group>

Η εμπειρία μου το distributor με άφησε ικανοποιημένο, υπήρξαν όμως και περιπτώσεις που η CPU φαινόταν απασχολείται σε εξαιρετικά υψηλό βαθμό όταν είχε να κάνει με διαμοιρασμό φόρτου σε SSL. Εκεί επιστράτευσα το balance που είναι εξαιρετικά απλό στην χρήση του και εκκινείται από command-line, για παράδειγμα ως εξής:

balance -f 8888 host1:8888 host2:8888

που διαμοιράζει το φόρτο στο host1 και στο host2 και λειτουργεί ως foreground job. Αξίζει να σημειωθεί πως και το balance μπορεί να χρησιμοποιήσει τον αλγόριθμο hash για λόγους session affinity.

Διαβάζοντας την ταυτότητα του χρήστη (user identity) στο JAX-RPC

Η έκδοση 10.1.3 του JDeveloper παρέχει πολλές διευκολύνσεις για την ανάπτυξη Java web services, βασισμένων στο πρότυπο JAX-RPC. Μια από τις πιο σημαντικές, που διασυνδέεται πολύ καλά με τον Oracle Application Server είναι η συμμόρφωση της δικτυακής υπηρεσίας σύμφωνα με τις επιταγές ασφάλειας WS-Security (http://www.oasis-open.org/committees/wss/) προσφέροντας δυνατότητες αυθεντικοποίησης με χρήση ζεύγους κωδικού και συνθηματικού, ψηφιακής υπογραφής ή SAML token.

Πέρα όμως από αυτήν την υπηρεσία, συχνά είναι απαραίτητο να μάθουμε την ταυτότητα του χρήστη που έχει συνδεθεί, ενδεχομένως για να διαμορφώσουμε μηχανισμούς εξουσιοδότησης (authorization) ή να αλλάξουμε εν γένει τη συμπεριφορά του web service. Στο JAX-RPC υποστηρίζεται η δήλωση ειδικών κλάσεων που η εκτέλεσή τους είτε θα προηγείται είτε θα ακολουθεί την εκτέλεση του καθαυτού web service (interceptors). Αυτές οι ειδικές κλάσεις ονομάζονται JAX-RPC handlers και απλά πρέπει να υλοποιούν το interface javax.xml.rpc.handler.Handler.

Υλοποιώντας το προαναφερόμενο interface, η μέθοδος που εκτελείται κάθε φορά που καλείται η υπηρεσία μας είναι η handleRequest() και στην οποία μπορούμε να ορίσουμε τον παρακάτω κώδικα προκειμένου να διαβάσουμε τα στοιχεία του χρήστη που έχει συνδεθεί.

/**
* Intervene request.
* @param messageContext is the SOAP context.
* @return an indication of whether to proceed or not.
*/
public boolean handleRequest(MessageContext messageContext) {
boolean exit = true;

String AUTH_PROPERTY = "oracle.security.wss.authuser";
Object authProperty = messageContext.getProperty(AUTH_PROPERTY);
JAZNUserAdaptor loggedUser = (JAZNUserAdaptor)messageContext.getProperty(AUTH_PROPERTY);

logger.debug("User logged on:" + loggedUser.getName());
//Do something with the user identity.
// ...
return exit;
}

Έτσι τρέχοντας ένα οποιοδήποτε web service, επαληθεύουμε πως διαβάσαμε τα κατάλληλα στοιχεία.

Εγκατάσταση 10.1.3.3.0 στο SuSE Enterprise Desktop

Μόλις έγινε διαθέσιμο το πολυαναμενόμενο patchset 10.1.3.3.0 (patch number: 6148874) του Oracle Application Server, που επιλύει αρκετά θέματα σταθερότητας ειδικά ως προς το SOA Suite. Έχω ήδη αναφερθεί σε προηγούμενο άρθρο στην εγκατάσταση του SOA Suite σε SuSE Enterprise Desktop, οπότε με μεγάλη ευχαρίστηση, διαπίστωσα πως τα βήματα που είχα τότε εφαρμόσει ήταν αρκετά για μια ομαλή εγκατάσταση και του patchset. Πραγματικά, δεν παρουσιάστηκε κανένα πρόβλημα, ούτε χρειάστηκε η παραμικρή διόρθωση.

Εγκατάσταση Oracle Application Server (10.1.3) SOA Suite σε SUSE Linux Enterprise Desktop 10

Σύμφωνα με την πιστοποίηση της Oracle, η έκδοση 3 του Oracle Application Server (10.1.3) είναι προς το παρόν διαθέσιμη για τα λειτουργικά συστήματα Linux RedHat 3.0, 4.0 και SUSE 9. Παραπομπή στο: http://www.oracle.com/technology/software/products/ias/files/oracle_soa_certification_101310.pdf

Σε αυτό το άρθρο θα περιγραφούν τα βήματα που ακολουθήθηκαν για μια επιτυχημένη εγκατάσταση του Oracle Application Server 10.1.3.1.0 (installation type: J2EE Server, Web Server, SOA Suite) στο Novell SuSE Linux Enterprise Desktop 10, ένα πολύ φιλικό και παραγωγικό περιβάλλον εργασίας.

Εκ προοιμίου, ακολουθούμε όλες τις οδηγίες του Installation Guide που αναφέρονται στο SuSE 9 ως βήματα πριν την εγκατάσταση, αναφορικά με oracle χρήστες, file limits, environment variables, IRCA repositories κ.ο.κ. Προκειμένου να ξεγελάσουμε τον installer για την έκδοση του Linux, τροποποιούμε το αρχείο /etc/SuSE-release ως εξής:

SUSE Linux Enterprise Desktop 10 (i586)
VERSION = 10

σε:

SUSE LINUX Enterprise Server 9 (i586)
VERSION = 9

Επίσης, προτού ξεκινήσουμε, ας βεβαιωθούμε πως έχουμε εγκαταστήσει τα πακέτα sysstat, pdksh, openmotif21, glibc-2.2.2-53 (ftp://195.220.108.108/linux/SuSE-Linux/i386/supplementary/commercial/Oracle/glibc-7.2-jdk1.3.1/glibc-2.2.2-53.i386.rpm) που δεν εγκαθίστανται εξ ορισμού στο SuSE 10. Όλα τα παραπάνω πακέτα είναι διαθέσιμα από το http://rpmfind.net/ και ως έκδοση rpm προτίμησα την SuSE 9.3. Ειδικά για τις βιβλιοθήκες glibc, φροντίζουμε να αντιγράψουμε τα αρχεία libdb.a, libdb.so.2, libdb.so στον κατάλογο /usr/lib.

Μια τελευταία επισήμανση για το IRCA, που δημιουργεί τα repositories του BPEL και του Service Bus, είναι πως το πρόγραμμα irca.sh περιμένει να δώσουμε το SERVICE_NAME της Βάσης, αντί του πιο κοινού SID. Παράξενο, αλλά αξιοσημείωτο.

Η εγκατάσταση φυσιολογικά δεν θα παρουσιάσει κανένα πρόβλημα, πέρα από τον έλεγχο των πακέτων, οπότε ο installer θα διαμαρτυρηθεί για τα πακέτα gnome-libs και gnome-libs-devel. Η προηγούμενη ενέργεια μας σχετικά με το glibc μας προφυλάσσει από αυτά τα προβλήματα, οπότε μπορούμε να δηλώσουμε "user verified" τον έλεγχο και να συνεχίσουμε.
Το επόμενο πρόβλημα που αντιμετώπισα ήταν στην εκκίνηση του opmn για τη ρύθμιση του oc4j_soa. Το μήνυμα ήταν το ακόλουθο:

deploy.checkServer: [echo] Checking server status...
[echo] Server is UP.deploy.waitForServer:
[echo] Waiting for server initialization...oc4j.query.opmn:
[echo] Querying OPMN for its request host and port...
[echo] Using linux-spk:6004.
[stopwatch] [oc4j.query.opmn.time: 0.215 sec]oc4j.checkOPMN:
[echo] Checking OPMN managed OC4J URI...
[echo] deployer:oc4j:opmn://linux-spk:6004/oc4j_soa
[stopwatch] [oc4j.checkOPMN.time: 0.643 sec]oc4j.checkCluster:
[echo] Checking OPMN managed clustered OC4J URI...
[echo] deployer:cluster:opmn://linux-spk:6004/oc4j_soa
[stopwatch] [oc4j.checkCluster.time: 0.607 sec]oc4j.checkRMI:
[echo] Checking stand-alone OC4J URI...
[echo] deployer:oc4j:linux-spk.toshiba.gr:6004
BUILD FAILED
/opt/oracle/product/10.1.3.1/OracleAS_5/owsm/scripts/install.xml:1996: The following error occurred while executing this line:
/opt/oracle/product/10.1.3.1/OracleAS_5/owsm/scripts/deploy.xml:395: The following error occurred while executing this line:
/opt/oracle/product/10.1.3.1/OracleAS_5/owsm/scripts/oc[4j.xml:24: Unable to locate a valid OC4J URI. The server is probably down.Total time: 44 secondsstopwatch] [oc4j.checkRMI.time: 0.887 sec]Error 1

Το μόνο που χρειάστηκε, ήταν να συνδεθώ στην οθόνη του Enterprise Manager και να ξεκινήσω το oc4j_soa. Μετά, ξανατρέχοντας το wizard, όλα λειτούργησαν κανονικά.


Τέλος, αξίζει να σημειωθεί πως η συνεργασία του JDeveloper 10.1.3.1 με αυτή την έκδοση του Application Server είναι υποδειγματική και πράγματι προσφέρει one-click deployment.

Database profiling στις συνδέσεις του Application Server

Είναι αναντίρρητο πως τα όποια προβλήματα απόδοσης σε μια εφαρμογή σχετίζονται σχεδόν πάντα με τον χειρισμό των δομών της Βάσης Δεδομένων, της λειτουργίας της, ή με τον τρόπο πρόσβασης σε αυτήν. Στους περισσότερους που ασχολούνται με την μέτρηση των στατιστικών της Oracle, είναι γνωστή η διαδικασία της ενεργοποίησης του "sql trace". Κατά αυτόν τον τρόπο αποτυπώνονται σε dump files στατιστικά σχετικά με το κόστος των SQL εντολών που εκτελούνται. Αργότερα τα αρχεία αναλύονται από το εργαλείο "tkprof" ώστε να εξαχθούν λεπτομερείς πληροφορίες σχετικά με τις πιο απαιτητικές SQL εντολές που εκτελέστηκαν. Έτσι, είναι δυνατή η διάγνωση προβλημάτων, όπως η έλλειψη ενός index, η απλοποίηση ενός query και ούτω το καθεξής.

Η λειτουργία sql trace ενεργοποιείται είτε σε επίπεδο συστήματος (καταγράφοντας όλες τις SQL εντολές του Oracle instance) είτε σε επίπεδο συνόδου (session) με την εντολή "alter session set sql_trace=true". Η πρώτη επιλογή μπορεί να είναι ανέφικτη σε ένα παραγωγικό σύστημα γιατί θα επιβάλλει μεγάλο φόρτο, ενώ η δεύτερη, αναγκαστικά θα χρειάζεται μια προγραμματιστική προσθήκη προκειμένου να μπορέσουμε να επέμβουμε στην αρχικοποίηση του connection pooling της εφαρμογής, αν μάλιστα αυτό επιτρέπεται από το persistence framework που χρησιμοποιούμε (πράγμα που είναι δυνατόν παρεμπιπτόντως για τα ADF Business Components)

Μια απλή λύση για αυτές τις περιπτώσεις είναι η χρήση του πακέτου της βάσης δεδομένων dbms_support (βρίσκεται στο $ORACLE_HOME/rdbms/admin/dbmssupp.sql που παρέχει την ευκολία της παρακολούθησης sql_trace σε δοσμένες συνδέσεις με την εντολή:

DBMS_SUPPORT.START_TRACE_IN_SESSION( SID , SERIAL# );

ενώ η διακοπή της λειτουργίας επιτυγχάνεται με:

DBMS_SUPPORT.STOP_TRACE_IN_SESSION( SID , NULL );

Επομένως, σε συνεργασία με τον DBA είναι δυνατόν να εντοπιστούν οι συνδέσεις που ανοίγει μια εφαρμογή (από το dynamic view v$session), και κατόπιν επαναληπτικά να εφαρμοστεί η παρακολούθηση των SQL εντολών σε αυτές.