Blog éclectique & sans sujet précis

Entre deux bouquins sur la Seconde Guerre Mondiale ^[1], petit retour sur un cauchemar personnel récurrent : l’installation d’Oracle. Je suis un peu maso, je cherche à l’installer sans qu’on me le demande.

La première partie traitait de la 10g et date un peu. Depuis bien des gigaoctets ont coulé dans les routeurs d’Internet, le Président tout neuf à l’époque a été changé, il y a eu deux réformes des rythmes scolaires, et deux versions majeures d’Oracle. Suite à toute la pub dans la presse archi-spécialisée (Oracle Magazine en tête), je me suis dit que j’allais tester la dernière version, et cette fois sous Linux. J’aime bien avoir un Oracle sur mon poste, ça m’a dépanné (et aussi dépanné des clients) plus d’une fois.

Oracle Linux

En effet, quitte à prendre du Oracle, autant prendre du Oracle Linux (du RedHat rebadgé, mais on reste dans l’esprit du libre, et Oracle participe bien activement au kernel). Il existe des machines virtuelles toutes prêtes sous VirtualBox (Oracle aussi...), donc j'ai installé ça sur mon beau portable professionnel tout neuf.

Je passe sur le clavier français pas reconnu au démarrage. Pas terrible pour taper le mot de passe par défaut. Ça fait plaisir de voir que le temps perdu dans ma jeunesse sur des jeux mal programmés m’a permis de mémoriser le clavier américain. Je corrige dans la config.

Plus grave : pas de réseau, un problème courant avec VirtualBox. Comme si les problèmes de proxy et de pare-feu ne donnaient pas assez d’occasion de se taper la tête contre les murs.

Finalement, ça marche, mais en bridge et pas avec le NAT qui fonctionne pourtant sans problème avec deux autres machines (une Windows, une Ubuntu). Ma machine virtuelle apparaît donc directement sur le réseau commun de l’agence : pas top du point de vue sécurité. Je m’en contente un temps histoire de pouvoir mettre à jour le système d’exploitation (yum update).

Oracle 12c

Dans ce nid douillet tout neuf, déposons l’installateur de la 12c, sous forme de deux gros zip d’un gigaoctet chacun. Rappelons qu’à la différence de pas mal d’éditeurs, Oracle permet à n’importe quel quidam de télécharger beaucoup de ses outils, même ceux archi-propriétaires comme la base, en échange de l’ouverture d’un compte ^[2].

Dézipper tout ça est une plaisanterie pour mon PC, la puissance des machines de bureau actuelle me fascinera toujours ^[3].

Une fois lancé, l’installateur hurle très vite qu’il est incapable de trouver le nom de la machine. J’avais eu le bug il y a six ans avec la 10g : le pauvre est perturbé par l’absence d’un autre nom que localhost dans le fichier hosts. Il suffit de rajouter le nom de la machine dans ledit fichier. Que ce problème si basique perdure des années plus tard, et qu’Oracle soit le seul logiciel que ce genre de chose perturbe, en dit long sur l’ouverture de la boîte. Bref.

Par la suite, l’installateur remplit sa tâche sans aucune originalité (choix/Suivant/choix/Suivant/Suivant...), ce qui est un bon point. Une question me taraude : pourquoi maintenir à grands frais un système d’exploitation propre (même repompé), et ne pas offrir le paquetage (RPM) adéquat pour cet OS pour son propre produit phare ? (Mise à jour 2023 : moins de dix ans après, c’est fait !) Parce que l’installateur est en Java (autre produit maison...) et contient trop de logique interne pour qu’il soit convertible en script ? Parce que les services responsables ne sont pas au même étage à Redwood Shores ? Il est vrai que l’éditeur a toujours eu du mal avec la facilité d’administration et l’intégration à d’autres systèmes : l’installateur Windows n’est pas un .msi, le requêteur SQL Developer n’a pas de programme d’installation au contraire du moindre petit shareware développé par un ado le week-end, et la base de données tient à sa propre hiérarchie séparée dans le système de fichiers. On a vu pire, et ça s’est amélioré depuis que Microsoft a croqué une belle part du marché, mais bon...

Le disque sur la machine virtuelle est trop étroit. En regardant de plus près, je m’aperçois que parmi les quatre disques durs (virtuels) fournis dans l’image d’Oracle Linux, deux ne sont ni utilisé ni formatés ; en tout cas parted ne trouve rien, même pas de table de partitions. Je me demande encore maintenant si je n’ai pas manqué quelque chose d’important. En tout cas j’ai découvert que la machine virtuelle utilisait LVM, et j’ai donc pu appliquer mes connaissances fraîchement acquises ^[4] pour intégrer au pool ces quatre disques après formatage.

L’installateur se plaint ensuite que la place manque dans le swap (corrigé, mais ce ne sera pas immédiat pour un débutant), et que certaines bibliothèques optionnelles manquent. Un coup de yum install suffit mais on se demande pourquoi les paquets ne sont pas installés par l’installateur, et pourquoi d’ailleurs celui-ci demande à ouvrir une fenêtre root pour exécuter un script quand il pourrait le faire lui-même.

L’installation se clôt avec succès en créant une première base d’exemple. Je reboote la machine sur le champ et j'attends une minute.

Premier reboot, et rien.

Aucune base active. Aucune processus oracle dans un top après le reboot.

Ça aussi je l'ai déjà vu : sur Unix, Oracle ne daigne pas s’installer au boot. Dans la version Windows, tous les services (bases, listener, console web...) démarrent avec l’OS. Sous Unix, rien, le script d’install est à écrire ou trouver soi-même, et à lier aux endroits adéquats de /etc/init.d/rcX.d pour un démarrage spontané. Je suppose que quelque part chez Sun-Oracle un administrateur Solaris influent menace de tuer quelqu’un si le programme d’installation prend la moindre initiative, et aucun script proposé ne le satisfera.

Bref, Google m’envoie sur une doc Oracle officielle contenant le fameux script de démarrage. À froid il n’est pas compliqué, mais il y a des pièges :

• il est exécuté en tant que root au boot, et cherche donc à se relancer en tant qu’utilisateur oracle pour être propre ; mais rsh n’est pas spontanément installé sur le système (ce que l’installateur n’a pas vu) et par défaut il semble totalement verrouillé, même de localhost à localhost : il est toujours marrant de voir root se faire jeter par son propre firewall ; je me suis rabattu sur le bon vieux su ;
• il manque le listener (lsnrctl) qui s’occupe de gérer le port réseau.

Je me suis donc inspiré d’un script non officiel mais mieux pensé. (J’adore le commentaire sur dbstart et dbshut officiellement dépréciés depuis longtemps, remplacés par Oracle Restart, une usine à gaz impliquant sans doute l’utilisation de Grid Infrastructure, lequel Oracle Restart est lui-même déprécié.) Le bon côté de l’influence de l’administrateur barbu et agressif ci-dessus évoqué, c’est la haute compatibilité ascendante des anciens scripts, dont l’essentiel n’a pas changé depuis la 9i si je lis bien.

À quelques errements près qui auraient stoppé un débutant, tout marche bien, et la base se lance bien au boot. (Du moins la base container, on verra pour les bases gigognes, la grosse nouveauté, plus tard.)

Console flashie et un peu conne

Je le fais parfois, mais administrer une base de données uniquement à base d’ordres SQL gaspille un temps précieux, un outil graphique convient mieux pour le non-répétitif. En 9i on avait un outil (OEM) passable ; en 10g et 11g la console web énervait par sa lenteur et son ergonomie pourrie ; en 12c on s’enfonce encore plus avec EM Express. Tous les développeurs de chez Oracle n’utilisent plus depuis longtemps que le module DBA de SQL Developer, et ils ont laissé le projet de la console web au premier non informaticien qui passait par là : ça expliquerait qu’elle soit à base de flash.

Oui, du flash, pour un produit de 2013 ! Première conséquence : la console ne marche pas d’entrée sur le Firefox inclus dans Oracle Linux. Deuxième conséquence : l’interface est beeaauuuuccooooppp plus lente que l’ancienne console web en HTML, bien qu’affichant dix fois moins d’informations et d’options. Troisième conséquence : le copier-coller n’est plus possible (ça servait parfois). Je passe sur le fait que la console ne répond qu’avec l’IP dans mon contexte, pas avec son nom. Je peux vivre avec.

Non, je ne regrette pas l’ancienne console, cette bouse d’emctl, son ergonomie pourrie, et sa propension à cesser de fonctionner au bout d’un certain temps pour des raisons obscures. Soit le look Fish-Price doit attirer de jeunes débutants ayant confondu MySQL (produit Oracle) avec Oracle (très grand O), assez courageux pour arriver à la fin de l’installation ; soit elle doit pousser l’utilisateur exigeant — et friqué — à migrer vers Grid Infrastructure (mais 2,5 Go à télécharger pour manager mon cluster de 1 machine virtuelle, ça fait un peu lourd) ; soit les équipes préfèrent bosser sur SQL Developer.

Conclusion énervée

Ces grosses boîtes sont fascinantes : d’un coté des produits parfois très bien pensés et puissants dans leur niche, des équipes regorgeant de gens brillants, et de l’autre des lacunes monstrueuses dans des domaines basiques comme l’installation ou l’administration de base. Même s’il ne s’agit pas de produits pour le péquin moyen, on s'attend au XXIè siècle à un minimum de facilité d’installation quand le système d’exploitation et l’outil proviennent du même éditeur.

Et je me demandais pourquoi mes collègues avaient tendance à ne plus installer que du Windows, même pour les outils non Microsoft... (Soyons honnête : l’installation du Management Studio de SQL Server 2012 dégaze tout autant, et il y a beaucoup plus à lire.)

Si quelqu’un est arrivé ici et se demande s’il y a un intérêt au bout de ce chemin de croix, il sera éclairé dans le prochain billet.