phpStorm 8 – ERROR – nse.impl.GeneralLicenseManager – No valid license found

Vous venez d’installer votre Fedora 22 et vous venez de télécharger l’excellent IDE PHP phpStorm. Mais celui-ci refuse de se lancer. Un message d’insulte s’affiche :

OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=350m; support was removed in 8.0
juin 08, 2015 8:39:20 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
juin 08, 2015 8:39:20 PM java.util.prefs.FileSystemPreferences$6 run
WARNING: Prefs file removed in background /home/greg/.java/.userPrefs/prefs.xml
[   1343]  ERROR - nse.impl.GeneralLicenseManager - No valid license found 
java.lang.Throwable
	at com.intellij.openapi.diagnostic.Logger.error(Logger.java:115)
	at com.intellij.ide.a.g.bb.a(bb.java:107)
	at com.intellij.idea.MainImpl$1.start(MainImpl.java:47)
	at com.intellij.idea.StartupUtil.prepareAndStart(StartupUtil.java:105)
	at com.intellij.idea.MainImpl.start(MainImpl.java:42)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at com.intellij.ide.plugins.PluginManager$2.run(PluginManager.java:91)
	at java.lang.Thread.run(Thread.java:745)
[   1348]  ERROR - nse.impl.GeneralLicenseManager - PhpStorm 8.0.3  Build #PS-139.1348 
[   1348]  ERROR - nse.impl.GeneralLicenseManager - JDK: 1.8.0_45 
[   1348]  ERROR - nse.impl.GeneralLicenseManager - VM: OpenJDK 64-Bit Server VM 
[   1348]  ERROR - nse.impl.GeneralLicenseManager - Vendor: Oracle Corporation 
[   1349]  ERROR - nse.impl.GeneralLicenseManager - OS: Linux 

Aie ! Mais que raconte t’il ? Pourquoi me parle t’il de licence ? Je viens de l’installer je n’ai pas le droit à ma version d’essai ?
Et bien ce n’est pas du tout cela… Le problème vient de la version de Java installée par défaut.

Pour résoudre se problème lancer un terminal, puis en root tapez :

dnf install java-1.8.0-openjdk

Une fois installé vous relancez phpStorm et vous obtiendrez celle belle fenêtre ! 😉

phpstorm_work

Installer NetBeans 8 sur Fedora 21

Alors que vous essayez d’installer la version 8 de NetBeans sur votre Fedora 21 tout fraichement installée un joli message d’insulte vous empêche de continuer :

Configuring the installer...
Searching for JVM on the system...
Extracting installation data...
Running the installer wizard...
Can`t initialize UI
Running in headless mode

Exception: java.awt.HeadlessException thrown from the UncaughtExceptionHandler in thread « main »

En effet, Fedora 21 est fourni par défaut avec OpenJDK (obligatoire pour utiliser LibreOffice) et tout cela n’a pas l’air compatible avec NetBeans 8 (ou plutôt il lui manque quelque chose qui n’est pas vraiment expliqué lors de l’erreur).

Et bien la solution fonctionnelle et la plus simple est simplement d’installer 1 seul package :

yum install -y java-1.8.0-openjdk-devel

netbeans8-installation

Résoudre un problème de lenteur sous TYPO3 quand on partage le dossier typo3temp en NFS entre plusieurs serveurs

Sous ce titre de billet très long j’ai essayé de résumer le problème que j’ai rencontré dans le cadre de mon travail sur une application tournant sur le cms TYPO3 version 6.1.1.

En environnement de développement tout allait bien, les performances du site était bonne, le backoffice également. Nous passons plus tard en environnement de pré-production.

Serveur ultra puissant (que ce soit les frontaux ou la base de données) et malgré cela j’obtiens un temps de chargement backoffice extrêmement lent ! L’action de changement des droits des pages prend plusieurs minutes à s’effectuer (environ 50 pages) alors que le même nombre sur la version de démo de TYPO3 prend quelques secondes !

Je décide alors de surveiller les requêtes sur la base de données. Au passage j’en profite pour vous parler d’un logiciel vraiment sympa : Jet Profiler for MySQL.
J’obtient un nombre crête de 250 requêtes/secondes ! Autant vous dire que ce n’est rien du tout ! Alors que ce passe t’il ?

Voici l’architecture web mise en place (je vous ai fait un schéma simplifié) :

1 répartiteur de charge + 2 serveurs web frontaux + 1 serveur de partage de ressource + 1 serveur de base de données

1 répartiteur de charge + 2 serveurs web frontaux + 1 serveur de partage de ressource + 1 serveur de base de données

Lorsqu’un internaute visite le site, le répartiteur décide de l’envoyer sur l’un des 2 serveurs web. La requête HTTP arrive sur Apache, il exécute PHP…

Ensuite c’est à ce moment qu’intervient le serveur de ressources. Nous avons décidé de partager les ressources entre les serveurs Web pour ne pas avoir besoin de mettre en place un mécanisme de synchronisation des dossier « typotemp » et « uploads » (nous en avons profité pour le faire aussi pour le dossier « fileadmin »). Ce partage a été mis en place au travers d’un montage NFS. Lors que TYPO3 ou notre extension a besoin d’écrire un fichier dans le dossier typo3temp il ne savent pas qu’ils sont sur finalement sur un serveur distant. Le dossier « typo3temp » est présent en local sur le serveur et c’est tout ce qui compte. C’est la magie des montages de dossier en temps que montage NFS.

Oui mais si vous relisez le titre du billet c’est peut être à ce moment là que vous allez comprendre d’où venait le problème.

En effet, alors que cela ne posait pas de problème particulier d’utiliser le NFS avec les version 4.x de TYPO3, cela en posait depuis la version 6.0. De nouveau fichier de cache ont vus le jour et sont crées dans le dossier « typo3temp » (valeur par défaut, nous en reparlerons après).
Je n’ai pas pu voir ce que cela représentait comme nombre de fichiers (TYPO3 ne laisse pas assez longtemps les fichiers sur le disque) mais un dossier se nommant « Cache » dans « typo3temp » est utilisé pour stockage de différents caches.

Pour expliquer la piste de ce « cache » j’ai cherché dans la documentation de TYPO3. Et c’est la que vous pleurez réellement… Déjà, n’espérez jamais avoir de l’aide via les forum FR, soit on vous répond « Va voir la doc » ou soit on ne vous répond même pas…
Bref, la documentation de TYPO3 sur les caches se trouve ici. Alors oui c’est chouette tout est expliqué dans les moindres détails, quels sont les différents cache, où ils peuvent être enregistrés (fichier, base de données, redis, memcached, etc.. ). Mais ce n’est quand même pas super évident…

Il faut savoir que tous les types de caches de TYPO3 ont une configuration par défaut. Des fois ce sera dans la base de données, des fois ce sera en fichier sur le disque. Si nous regardons dans la configuration « file backend » vous pouvez voir que par défaut le dossier est « typo3temp/cache/« . Nous allons changer ce chemin par défaut pour le placer en dehors du dossier « typo3temp ». Ainsi il ne sera pas sur NFS.

Tout d’abord créez un dossier « typo3cache » (par exemple dans le dossier de TYPO3 (au même niveau que les dossier « typo3temp », « uploads », etc… En effet, la configuration cherche un dossier par rapport au dossier principal de votre site.
N’oubliez pas de donner les droits à votre user « apache » car il aura besoin d’écrire dans ce nouveau dossier.

Ensuite nous allons modifier la configuration de TYPO3.
Editez le fichier « typo3conf/LocalConfiguration.php »

Rendez-vous à la fin du fichier, vous devriez avoir une configuration « SYS », voici un exemple :

'SYS' => array(
	'compat_version' => '6.1',
	'curlUse' => '1',
	'dbClientCompress' => '0',
),

Il faut ajouter la configuration dans « SYS ». Voici ce que j’ai mis :

'SYS' => array(
	'caching' => array(
		'cacheConfigurations' => array(
			'cache_core' => array(
				'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\SimpleFileBackend',
				'frontend' => 'TYPO3\\CMS\\Core\\Cache\\Frontend\\PhpFrontend',
				'options' => array(
						'cacheDirectory' => 'typo3cache/',
				),
			),
			'cache_phpcode' => array(
				'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\SimpleFileBackend',
				'frontend' => 'TYPO3\\CMS\\Core\\Cache\\Frontend\\PhpFrontend',
				'options' => array(
						'cacheDirectory' => 'typo3cache/',
				),
			),
			'fluid_template' => array(
				'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\SimpleFileBackend',
				'frontend' => 'TYPO3\\CMS\\Core\\Cache\\Frontend\\PhpFrontend',
				'options' => array(
						'cacheDirectory' => 'typo3cache/',
				),
			),
			't3lib_l10n' => array(
				'backend' => 'TYPO3\\CMS\\Core\\Cache\\Backend\\SimpleFileBackend',
				'options' => array(
						'cacheDirectory' => 'typo3cache/',
				),
			),
		),
	),
	'compat_version' => '6.1',
	'curlUse' => '1',
	'dbClientCompress' => '0',
),

Bon alors dans ma configuration je n’étais pas obligé de ré-écrire les valeurz « backend » et « frontend » car ce sont déjà les valeurs par défauts (spécifiez simplement les tableau options »).

Videz les caches de configuration de TYPO3 et testez votre site pour voir s’il fonctionne toujours et si le dossier « typ3cache » se rempli.

Suite à cette modification, la valeur de 250 requêtes/secondes passe maintenant à plus de 2500 ! C’est beaucoup mieux !

Il reste encore d’autres possibilités pour faire grimper les performances, mais ça fera l’objet d’un autre billet sur ce blog 😉

 

Avec mots-clefs

MATE : Résoudre l’erreur « mate-screenshot » not found

Après une installation toute fraiche (voir mon article à ce sujet) de MATE sous Fedora 17 j’ai rencontré une erreur étrange :

Il y a eu une erreur lors de l’exécution de mate-screenshot : L’exécution du processus fils « mate-screenshot » a échoué (aucun fichier ou dossier de ce type)

mate-screenshot

Cette erreur se produit lorsque vous appuyez sur la touche « Impr écran » de votre clavier. Pour résoudre ce probleme il vous suffit d’installer le package « mate-utils » qui ne s’installe pas par défaut (??!)

Pour faire cela lancez une fenêtre Terminal, connectez vous en « root », puis tapez cette commande :

yum install mate-utils

Installer l’environnement MATE sous Fedora 17

A cause du retard de la Fedora 18 (prévu pour le 8 janvier 2013) je me suis décidé à installer l’environnement MATE sur ma Fedora 17. En effet, MATE (fork de Gnome2) sera intégré qu’à partir de Fedora 18.

Pour installer MATE sous Fedora 17 faites comme ceci :
– Ouvrez un terminal et passez en « root »
– Installez ce package qui configurera les dépots de MATE
yum install https://dl.dropbox.com/u/49862637/Mate-desktop/fedora_17/mate-desktop-fedora-updates/noarch/mate-desktop-release-17-2.fc17.noarch.rpm
Une fois le dépot installé, exécutez cette commande pour installer l’environnement :
yum groupinstall MATE-Desktop
Sur mon poste, j’ai eu besoin de télécharger 102 packages.

Une fois tout cela installé, déconnecté vous de votre session actuelle (pas besoin de redémarrer le système) et choisissez l’environnement MATE avant de vous reconnecter (une liste doit être disponible à l’écran de connexion)

MATE -1.4

Quand MySQL 5.5 ne veut pas démarrer sous Fedora 16

Après une installation toute fraiche de ma fedora 16 je ré-installe une version binaire de MySQL (parce que comme tout, j’aime bien savoir où je mets les choses :p )

Pas de chance ! Voila que MySQL ne veut pas démarrer ! J’obtiens ce message d’erreur :

mysqld: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory

C’est finalement très simple ! Il manque un package !
Pour installer le package manquant, en root tapez ceci :

yum install libaio

Vous n’avez plus qu’ensuite à relancer votre serveur MySQL et tout ira bien !

Sortie de TYPO3 4.6

L’équipe de développement vient d’annoncer la sortie de la nouvelle version TYPO3, la version 4.6

Les innovations importantes sont :

  • Un nouveau système de gestion des traductions.
  • Une nouvel élément de contenu pour la génération des formulaires (FrontEnd)
  • Une amélioration de la sécurité et des performances.
Vous pouvez retrouver l’annonce la news de l’annonce et la release notes pour plus de détails.
Comme d’habitude, vous pouvez télécharger cette nouvelle version depuis la page de téléchargement.

Sortie de PHP 5.4.0 Beta1

La premiere version beta de PHP 5.4 vient tous juste d’être publiée.

Cette version ne doit pas être encore utilisée sur un serveur de production. La liste des changements étant assez impressionnante, je vous renvois vers le changelog de cette beta1.

Si vous désirez tester cette version vous pouvez vous rendre sur la page de Quality Assurance. Pour vous aider à compiler vous pouvez retrouver quelques articles sur mon blog. A noter que cette nouvelle version de PHP gère maintenant les dernieres version d’autoconf. Ce qui vous évitera bien des soucis si vous ajoutez des extension PECL.

 

 

 

 

 

configure: error: Please reinstall the BZip2 distribution

Si, lors de votre compilation, vous obtenez cette erreur :
configure: error: Please reinstall the BZip2 distribution
Vérifiez que vous avez installé « bzip2 ». Vous pouvez le vérifier en tapant la commande suivante :


which bzip2

S’il est présent, ajoutez simplement le paquet suivant :
libbz2-devel

Sortie d’Apache 2.2.20

Suite à l’exploitation (entendez par là, la création d’un script permettant d’exploiter la faille) d’une faille sur le serveur Apache connue depuis maintenant 4 ans, la fondation Apache vient tous juste de mettre à jour sa dernière version stable.

Au moment où j’écris ces lignes, le site officiel n’annonce pas encore la disponibilité de cette version. Cependant le correctif est annoncé dans le changelog

Vous pouvez néanmoins la télécharger en changeant le numéro de version dans l’url de téléchargement.

Par exemple, depuis les serveurs OVH :  Apache 2.2.20