Support de Java sous Oracle Fusion Middleware et/ou Weblogic

Lorsque Java SE est utilisé pour faire fonctionner un produit Oracle, il est considéré comme un composant intégré à ce produit et il se conforme au support de ce dernier (Premier Support life cycle) tout en respectant la politique d'Oracle Lifetime Support.

Voici des exemples provenant du site de support d’Oracle :

• J2SE 1.4.2 End of Life (EOL) was announced for October 2008 and J2SE 5.0 for October 2009. This Java SE End of Life applies to Java SE when used standalone or with 3rd party applications. Many Oracle Fusion Middleware products are installed with or run on these versions of J2SE, (now referred to as Java SE). For Oracle Fusion Middleware products, the Oracle Lifetime Support Policy's Extended Support date takes precedence for a given Oracle Fusion Middleware product.
• Java SE 6  End of Life (EOL) is provided here. This Java SE End of Life applies to Java SE when used standalone or with 3rd party applications. Many Oracle Fusion Middleware products are installed with or run on this version of  Java SE. For Oracle Fusion Middleware products, the Oracle Lifetime Support Policy's Extended Support date takes precedence for a given Oracle Fusion Middleware product.
• For Java SE 7 and newer, the same guidelines will be applicable and as according to the Oracle Fusion Middleware Lifetime Support Policy document.

Pour plus de détails, réfèrez-vous à  la note d’Oracle « Java SE End of Life and Oracle Fusion Middleware Policy [ID 952075.1] »

Un accès SFTP n'a jamais été aussi facile

Voici une simple et complète intégration du support SFTP à Windows Explorer qui s'intitule "Swish".

Swish ajoute un support SFTP à Windows Explorer pour qu'on puisse accéder à nos fichiers sur un autre ordinateur/serveur en toute sécurité via SSH. Swish est facile à utiliser car il s'intègre parfaitement à Windows Explorer pour travailler avec des fichiers distants comme si c'était des disques locaux.

Swish est une belle option pour les utilisateurs de Windows parce qu'il est simple d'utilisation.

Pour plus de détails : http://www.swish-sftp.org/

Impossible de recréer la liste de contrôle d'accès (ACL)

Suite à la suppression de la liste nommée "power_users.xml" qui avait été créée à l'aide du code PL/SQL fournit par Oracle, je n'étais plus en mesure de la recréer. J'obtenais l'erreur "ORA-01403 : NO DATA FOUND" lors de l'exécution des commandes suivantes dans SQL*Plus sous le compte "SYS" sur une base  de données 11gR2 (11.2.0.3) :

SYS@lab11g> exec DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('power_users.xml','test','APEX_040100', TRUE, 'connect');

SYS@lab11g> exec DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('power_users.xml','*');

Après avoir exécuté plusieurs requêtes pour consulter la configuration de l'ACL dans le dictionnaire de la base de données, je fus surpris du résultat de la requête suivante :

SYS@lab11g> select host from net$_acl;
HOST
-----------------------------------------------------
*
192.168.1.109
ftp.oracle.com

La requête m'indiquait que le host "*" était toujours présent dans la base de données malgré la suppression de la liste "power_users.xml". J'ai alors vérifié si ce "host" était assigné à une autre liste dont j'aurais peut-être oublié :

SYS@lab11g> select *
from DBA_NETWORK_ACLS T1, NET$_ACL t2
where t1.aclid=t2.aclid
and t2.host = '*';

no rows selected

Le host "*" n'étant assigné à aucune liste, je l'ai alors supprimé :

SYS@lab11g> delete from NET$_ACL where host = '*';

1 row deleted.

SYS@lab11g> commit;

Commit complete.

Suite à la suppression, je fus en mesure de recréer la liste telle que désirée.

Je ne peux m'empêcher de vous dire qu'il n'est pas recommandé de supprimer des données directement du dictionnaire de la base de données. Mieux vaut contacter le support d'Oracle.

Une limite au maximum

Lors de la création d'une base de données Oracle 11gR2 sous Microsoft Windows Server avec l'utilitaire DBCA, nous avons rencontré l'erreur suivante :

ORA-02249: missing or invalid value for MAXLOGMEMBERS

Nous savions que ceci était directement lié à la création des fichiers de contrôle plus précisément au nombre de membres qui sont autorisés dans chaque groupe de journaux (redo log).

Dans DBCA, nous sommes revenu à l'écran de saisie concernant les paramètres nous permettant de spécifier la valeur de "MAXLOGMEMBERS". La valeur que nous avions inscrite était "6". Rien de très élevé, vous en conviendrez !

Pour comprendre la cause de cette erreur, nous avons effectué quelques recherches pour finalement tomber sur un document d'Oracle indiquant que cela est dû à une restriction codé en dur qui oblige la valeur à être comprise entre 1 et 5. Oracle considère qu'il est peu probable qu'une base de données ait à utiliser plus de 2 ou 3 membres pour chaque groupe de fichiers log. Par conséquent, le maximum de 5 a été mis en place.

La documentation d'Oracle n'est pas clair à ce sujet. Elle indique que la valeur dépend de notre système d'exploitation. Dans le document "Oracle® Database Administrator’s Reference" pour Linux/Unix, il est indiqué que la maximum est 5. Un peu plus de précision dans la documentation ou dans le message d'erreur aurait été apprécié.

Un portefeuille pour la base de données

Afin de permettre à la base de données d’accéder au contenu d’un site sécurisé par le protocole SSL, celui-ci doit avoir un portefeuille (wallet) dans lequel on retrouve les certificats.

1. Obtention des certificats

Cette section décrit comment procéder à l’exportation des certificats associés au domaine (site) dont nous voulons que la base de données puisse accéder.

Note : Les étapes de cette section dépendent du fureteur utilisé. Dans le cas actuel, le fureteur Firefox de Mozilla est utilisé.

• Accéder au site via son adresse sécurisée à l’aide d’un fureteur Internet
• Accéder au détail du certificat du site en cliquant à la gauche de l’adresse URL puis, sur le bouton « More Information… »
• Cliquez sur le bouton « View Certificate » pour faire afficher la fenêtre des propriétés
• Ensuite, déplacez-vous vers l’onglet « Details ». À ce moment, il est important de remarquer dans la partie du haut que la hiérarchie est constituée de plusieurs niveaux. Cela indique que vous devez exporter plusieurs certificats (1 par niveau).
• Pour débuter, sélectionnez le premier niveau puis appuyez sur le bouton « Export » au bas de la fenêtre
• Choisissez le format « X.509 Certificate (PEM) » puis enregistrez le certificat sous un emplacement de votre choix.
• Répéter les deux étapes précédentes pour chacun des niveaux

2. Création du portefeuille

• Accéder au serveur de base de données via un outil tel que « Putty »
• Établir une connexion avec le compte propriétaire (ex. oracle)
• Créer une nouvelle entrée dans le portefeuille

Note : Veuillez spécifier un emplacement et un mot de passe pour le protéger.

(oracle) $ orapki wallet create –wallet [répertoire/du/wallet] -pwd [mot_de_passe] -auto_login

3. Importer les certificats dans le portefeuille

• Transférer les certificats précédemment exportés sur le serveur de base de données
• Accéder au serveur de base de données via un outil tel que « Putty »
• Établir une connexion avec le compte propriétaite (ex. oracle)
• Importer tous les trois certificats en exécutant cette commande pour chacun  :

Note : Assurez-vous de préciser le nom exact du fichier correspondant au certificat.

(oracle) $ orapki wallet add -wallet  [répertoire/du/wallet]  -trusted_cert -cert [Nom_fichier_crt] -pwd [mot_de_passe]

4. Afficher le contenu du portefeuille

Vous pouvez exécuter la commande suivant pour vérifier le contenu du portefeuille. La commande affiche les certificats qu’il contient.

(oracle) $ orapki wallet display -wallet [répertoire/du/wallet]

5. Vérifier le fonctionnement

• Démarrer l’outil SQL*Plus
• Établir une connexion à la base de données avec un compte administrateur (DBA)
• Exécuter la requête SQL suivante :

Note : avant d’exécuter la requête, veuillez spécifier l’emplacement (répertoire) où se trouve le fichier (portefeuille) ainsi que le mot de passe de ce dernier

SELECT utl_http.request('https://[Adresse_URL]','',
       'file:[Nom_fichier_Wallet_incluant_Repertoire]', '[Mot de passe]')
  FROM dual;

Si la requête retourne une série de balise « HTML », cela confirme que c’est fonctionnel.

Et pour terminer, n'oubliez pas de jeter un oeil à la liste de contrôle ACL pour que votre schéma (utilisateur) soit autorisé à accéder au site web.

Quels sont les correctifs (patches) installés sur la base de données ?

Si vous désirez connaître les correctifs (patches) d'Oracle qui ont été installés/appliqués sur la base de données, vous pouvez exécuter la commande suivante :

opatch lsinventory

et consulter le contenu des objets ci-dessous du dictionnaire :

select * from DBA_REGISTRY_HISTORY
select * from registry$history;
select * from dba_registry;

Incapable d'émettre un droit malgré la clause "With Grant Option"

Après avoir octroyer le droit d'exécution sur le package UTL_HTTP à un schéma particulier avec la clause "With Grant Option", ce dernier n'a pas été en mesure d'émettre à son tour, ce même droit à un autre schéma malgré la présence de la clause. Lors de l'émission du privilège, l'erreur "ORA-01031 INSUFFICIENT PRIVILEGES" est soulevé. Ce qui ne fait aucun sens.

Après quelques recherches, j'ai alors remarqué que ce comportement est un bug répertorié chez Oracle et il a été observé sur la version 11.2.0.3 de la base de données. (Bug 13036331 : ORA-01031 INSUFFICIENT PRIVILEGES WHEN GRANTING EXECUTE ON DBMS PACKAGES)

Étrangement, mais heureusement, il y a une solution de contournement. Dans mon cas, il a suffit d'effectuer un "Alter system flush shared_pool;" puis d'émettre à nouveau le privilège initial qui comportait la clause "With Grant Option" et ensuite, d'octroyer de nouveau le privilège à l'autre schéma dont il était impossible de faire. Cette fois-ci, ça l'a réussi.