HOAB

Le problème :

Pas vraiment de problème si ce n'est le problème des drivers en 32 ou 64 bits. C'est plus un pense-bête.

EA <-> base Mysql via driver ODBC

La documentation d'installation du driver ODBC : ici

Solution :

1. Installer EA
2. Installer un kit Microsoft Visual C++ 2010. Attention à prendre la même version (32 ou 64 bits) que le driver ODBC
3. Installer un driver Mysql
   • Chez moi j'ai eu un problème :
     • si pas de driver x64, pas reconnu dans ODBC,
     • si pas de driver x32 EA ne se connecte pas (il est en 32 bits).
   • Bref il faut les deux... quelque soit le kit VC++....
4. Créer un utilisateur sur votre base MYSQL, une base, donner les droits à l'utilisateur pour accéder à la base
5. Créer les tables via les scripts EA
6. Créer une source de données ODBC
   1. Panneau de configuration > Source de données (ODBC)
   2. Source de données utilisateurs > Ajouter
   3. Adresse du serveur + login/mdp + base
7. Ouvrir EA
8. Ouvrir le projet à commiter
   1. Vérification de l'intégrité : Tools | Data Management | Project Integrity Check
   2. Transfert :
      • Tools | Data Management | Project Transfert
      • Choisir le type : EAP vers DMBS (fichier vers BDD)
      • Choisir le fichier source
      • Choisir la connexion ODBC et remplir les informations (utiliser la connection ODBC créée précdemment)
      • Cocher :
        • "Return matched rows instead of affected rows"
        • "Allow big result sets"
9. Ouvrir le projet avec EA
   1. File | Open | Connect to server | Connection Wizard
   2. Choisir la connexion ODBC et remplir les informations

Le problème :

La connexion réseau depuis une image CentOS sous VirtualBox vers un réseau entreprise un peu tatillon.

Dans un réseau entreprise, j'ai eu la surprise de voir le lancement de l'image VirtualBox "tuer" les prises réseaux.

Eh oui ! J'avais configuré ma VB en mode "Accès par pont".

Solution :

On commence par un petit pense-bête pour moi :

Par la suite :

• VM = l'image que vous avez lancé sur VirtualBox
• Réseau entreprise = le réseau auquel vous vous connectez avec votre PC
• Réseau VB = réseau VirtualBox. Quand VB s'installe, il peut déployer une carte réseau virtuelle ce qui permet d'avoir un réseau propre à votre machine. Cette carte fait aussi serveur DHCP !

Les modes réseaux (Liste des modes réseaux VirtualBox, sur CCM):

- /!\ IMPORTANT /!\ : Accès par pont : adresse IP entreprise

• la VM demande une autre adresse IP au réseau entreprise. (c'était mon problème : 2 adresses réseaux sur 1 même prise réseau => ZAG !)
• Cela créé une deuxième machine indépendant de votre PC.

- /!\ IMPORTANT /!\ : NAT : adresse réseau local (10.0.x).

• Adresse locale (inacessible depuis votre PC ou le réseau entreprise)
• La redirection de port est intégré dans VirtualBox (sur la carte) c'est pratique
• Donc en réalité un peu accessible via certains ports....

- Réseau NAT : jamais utilisé

• a priori pour ne pas utiliser les adresses locales par défaut (10.0.x).
• Permet de choisir un réseau via l'interface globale Virtualbox (partie réseau NAT)
• Redirection de port à faire via l'interface globale Virtualbox plutôt que sur la configuration de la carte réseau (dans Virtualbox aussi)

- Réseau interne :

• pas de réseau
• seulement entre les VM. (à vérifier, jamais fait)
• Les VM parlent aux VM, ici l'ombre (une sombre histoire à Achille Talon, si quelqu'un me retrouve la bulle... :))

- Réseau privé hôte : adresse IP donnée par la carte virtuelle VB

• demande une adresse IP à la carte VB : on a créé un réseau interne entre le PC et la VM
• Le PC et la VM se connaisse, l'extérieur doit passer par le PC pour avoir accès à la VM
• Redirection de port à faire vous-même si besoin

Translations / Redirections :

Dans tous ces modes, ce qu'il faut bien voir, c'est qu'à partir du moment où :

1. PC1 accède avec PC2
2. PC2 accède à la VM
3. vous êtes maitre de PC2

A priori tout est possible. Que la VM soit en accès par pont, nat, réseau privé hôte, etc...

Un PuTTY bien placé vous permet de faire les translations de port que vous voulez (et dans les 2 sens !).

Donc au choix :

- votre réseau est cool : vous utilisez le mode accès par point, vous avez installé une nouvelle machine sur le réseau, indépendante de l'hôte.

- votre réseau est un peu serré : NAT + redirection de port : c'est votre PC qui expose des ports qui seront redirigées vers la VM (mais alors attention aux configuration antivirus et firewall du PC du coup).

Le reste, c'est plus pour des configurations particulières :

- Réseau privé hôte : si votre accès par point est refusé et que vous voulez accéder "pour de vrai" à une autre VM 

- Réseau NAT : votre plage réseau local est déjà occupée.

Retour au problème :

Je suis passé d'un réseau "cool" à "un peu serré" avec protection des prises, le temps de trouver le paramétrage qui va bien, j'avais bloqué toutes les prises réseaux de la salle de réunion.

+

La question : "est-ce que la redirection du port en mode NAT se fait à chaud ?" (et la réponse est OUI).

+

J'utilise CentOS qui désactive la carte eth0 : le temps de tester les différentes options sous virtualbox...

Ca m'a pris un peu de temps (raisonnable... :)), mais ça a marché.

Le problème :

Avec les vieilles versions d'Oracle Forms (10g2 - 10.1.2.0.2), un système existait pour remplacer le Java web start (JWS).. le Jinitiator (*fear !*).

Sauf que ce vieux système n'est plus maintenu. Donc rien ne se lance. Comme toujours une recherche donne des indices dont :

- réduire la version de Java

- Modifier Oracle Forms pour ne pas utiliser Jinitiator, c'est possible avec la 10g2 je crois

Mais comme par hasard, tout ça ne marche pas chez moi.

Solution :

Ce n'est pas simple... (testée avec la JVM 32bits 1.7.0_55-b13)

0) Activer la console Java pour tous les lancements, vérifier que vous avez l'erreur

ClassNotFoundException : oracle.forms.engine.Main

1) repérer où l'application Java est téléchargée... (Panneau de configuration -> Java -> Général -> PAramètres des fichiers temporaires -> Empalcement, exemple :

C:\Users\<user>\AppData\LocalLow\Sun\Java\Deployment\cache

2) Recherche l'archive de lancement dans les sous répertoires - un fichier de  1,151 Mo). C'est le fichier frmall_jinit.jar indiqué dans la source de la page de l'applet.

3) Surprise c'est un jar dans un jar ! Voilà pourquoi mon java ne pouvais pas lancer l'appli, une astuce Jinit...

3) Extraire le jar : forms.jar

4) Remplacer le fichier du cache par le fichier extrait forms.jar => Dans mon cas j'ai du remplacer ce fichier (conserver le nom du cache évidemment) :

C:\Users\<user>\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\0\2d74c040-2640a8d0

5) Actualiser la page et hop ! ça affiche quelque chose, mais ça plante encore... Eh oui, il y a une vérification de la version de Java dans la classe HTTPConnexion

oracle.forms.net.HTTPConnexion

6) décompilation, suppression du test, mise à jour du HTTPConnexion.class dans l'archive, recopie dans le cache, relance... easy ou presque.

A noter que cette astuce ne devrait pas servir souvent  :

1. soit vous êtes admin et dans ce cas, modifiez votre configuration Oracle Forms pour utiliser JWS
2. soit vous êtes un utilisateur courant et vous faites remonter le problème à votre admin
3. sinon, comme moi, vous êtes utilisateur ponctuel et vous n'avez pas envie de réinstaller une VM XP Java 2 juste pour ça...

Cependant ça peut servir pour toutes les applets Java hein, un truc vous embête, modification, remplacement du cache et hop ça roule. C'est déjà utilisé couramment pour modifier les scores des jeux ^^ (java, flash ou autre)...

Personne ne trouve bizarre qu'un mec finisse un niveau en 0.1 seconde ou qu'un score grimpe à 999 999 999 ?!! :)

Le problème :

Cisco Anyconnect se connecte correctement puis après un arrêt/relance de votre VM/machine, ça ne marche plus : timeout

Solution :

C'est tout bête là encore :

1. allez voir dans : Configuration internet, connexions, paramètre réseau.
2. si Anyconnect s'est mal terminé, le script de configuration automatique est toujours coché....

Donc corrigez la valeur si vous utilisez un script de connexion, sinon décochez la case.

AnyConnect est censé remettre la configuration à sa forme d'origine à la fermeture, mais quand il est tué, il fait ce qu'il peut le pauvre... (et il ne peut pas grand chose....)

Le problème :

OpenVPN se connecte correctement, mais on ne peut accéder aux machines distantes via le VPN.

Lorsqu'on regarde le "Show Status", on a l'erreur suivante : "route addition failed using CreateIpForwardEntry: Accès refusé. "

Solution :

C'est tout bête, il faut exécuter le programme (ou le raccourci dans mon cas) en tant qu'administrateur.

Il est possible de modifier le raccourci pour que ce soit le cas.