fedora fr planet

Add your email:  Fedora Tunisia Group

 

Syndicate content Planet Fedora-Fr
Sélection de blogs autour de Fedora
Updated: 7 hours 38 min ago

Remi Collet : PHP 5.6.0 Release Candidate

Fri, 06/20/2014 - 12:12

La première Release Candidate de PHP 5.6.0 est publiée, voir PHP 5.6.0RC1 is available.

Les RPM sont disponibles dans le dépôt remi-php56 pour Fedora 19 à 20 et pour Enterprise Linux 5 à 7 (RHEL, CentOS)

Attention : il s'agit d'une version destinée aux tests a ne pas utiliser en production.

Changement dans les paquets :

  • Le nouveau paquet php-dbg fournit le debogueur interactif
  • Chaque fichier de configuration (/etc/php.d) est préfixé par un numéro garantissant un order de chargement correct.

Installation :

yum --enablerepo=remi,remi-php56 update php\*

Cette nouvelle version est un des changements attendus pour Fedora 21, voir PHP 5.6

PHP 5.6.0RC1 est aussi déjà disponible dans Fedora rawhide.

Documentation :

Fonctionnant avec la version de développement depuis plus mois, je n'ai pas rencontrer de problème avec les applications que j'utilise ou les suite de tests que je fait tourner lors de la construction de paquets.

La plupart des extensions sont aussi disponibles.

Remi Collet : RHEL-7, EPEL-7, remi-7 et PHP

Tue, 06/10/2014 - 17:56

Red Hat Enterprise Linux 7 est publiée, voir : Red Hat Enterprise Linux 7 now Generally Available

EPEL

Le dépôt EPEL pour RHEL-7 est ouvert (toujours en beta)

Installation :

wget http://dl.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.1.noarch.rpm
yum install epel-release-7-0.1.noarch.rpm

Vous avez donc à votre disposition une pile PHP assez complète (version 5.4.16).

A noter, RHSCL 1.1 fournit aussi php55 (version 5.5.6).

Remi

Pour les adeptes des dernières versions, ou pour les extensions supplémentaires le dépôt remi est aussi ouvert :

Installation :

wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
yum install remi-release-7.rpm

Et vous pouvez disposer au choix de 3 versions

  • PHP 5.4.29 dans le dépôt remi
  • PHP 5.5.13 dans le dépôt remi-php55
  • PHP 5.6.0beta4 dans le dépôt remi-php56

CentOS 7 est en cours de préparation et devrait être disponibles dans quelques jours/semaines.

Remi Collet : PHP 5.4.29 et 5.5.13

Fri, 05/30/2014 - 10:28

Les RPM de PHP version 5.5.13 sont disponibles dans le dépôt remi pour Fedora et dans le dépôt remi-php55 pour Enterprise Linux.

Les RPM de PHP version 5.4.29 sont disponibles dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...).

Annonces des versions :

Installation de PHP 5.5

yum --enablerepo=remi-php55,remi update php\*

Installation de PHP 5.4

yum --enablerepo=remi update php\*

Et bientôt dans les mises à jour officielles:

À noter :

  • la version EL7 est construite avec RHEL-7.0RC
  • la version EL6 est construite avec RHEL-6.5
  • pour php 5.5, l'extension Zip est désormais fournit dans le paquet php-pecl-zip.
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

Informations, lire :

Matthieu Saulnier : Changement de MTA

Wed, 05/28/2014 - 16:35

Sur toutes mes machines les nombreux emails envoyés par le démon Cron doivent être relayés par un Mail Transport Agent (MTA). J'utilise pour cela Postfix que j'ai l'habitude de déployer. Sur une installation minimale de Fedora, il n'y a pas vraiment changement de MTA puisqu'il y en a aucun installé d'office. En revanche, sur une installation standard de Fedora en laissant Anaconda installer GNOME3, il y aura un MTA installé par défaut (Ssmtp). Pas la peine d'essayer de le supprimer à coup de "yum remove", ce n'est pas lui qui va poser problème à Postfix, mais plutôt la configuration système faite avec des liens symboliques. Ai-je bien dit "problème" ? Ah oui c'est vrai, il est énoncé dans le log, le problème.

mai 23 01:16:54 mosquito systemd[1]: Starting Postfix Mail Transport Agent... mai 23 01:16:56 mosquito aliasesdb[997]: newaliases: In sSMTP aliases are read from a plain text file mai 23 01:16:56 mosquito aliasesdb[997]: touch: impossible d'obtenir les attributs de « /etc/aliases.db »: Aucun fichier ou dossier de ce type mai 23 01:16:59 mosquito postfix/postfix-script[1187]: starting the Postfix mail system mai 23 01:16:59 mosquito postfix/master[1189]: daemon started -- version 2.10.3, configuration /etc/postfix mai 23 01:16:59 mosquito systemd[1]: Started Postfix Mail Transport Agent.

Après installation, le démon démarre bien, il en demeure pas moins hors-service, en effet le fichier aliases.db est un fichier vital pour son fonctionnement. Normallement, la commande newaliases est censée créer ce fichier, d'ailleurs cette commande est lancée à la fin de l'installation du paquet postfix. Sauf qu'elle échoue, même si on la lance manuellement, avec toujours le même message d'erreur :

newaliases: In sSMTP aliases are read from a plain text file

Le système utilise des liens symboliques pour définir les commandes par défaut à utiliser dans certaines situations, dont la façon de délivrer du courrier, ce type de configuration permet de se passer du libre arbitre de l'administrateur quand le système doit choisir quel programme est à utiliser, indispensable lorsqu'il y a plusieurs MTA installés sur le système. Tant que le MTA à utiliser par défaut ne sera pas /usr/sbin/sendmail.postfix, la commande newaliases restera en erreur. Il existe donc pour l'administrateur souhaitant changer les commandes par défaut un programme qui s'occupe de tout :

man alternatives

Et dans notre cas de figure, on va lancer la commande pour sélectionner Postfix :

mosquito:~# alternatives --config mta Il existe 2 programmes qui fournissent « mta ». Sélection Commande ----------------------------------------------- * 1 /usr/sbin/sendmail.ssmtp + 2 /usr/sbin/sendmail.postfix Entrez pour garder la sélection courante [+] ou saisissez le numéro de type de sélection :2

Une fois validé, newaliases devrait correctement créer le fichier aliases.db. Avant de redémarrer le service Postfix, veillez à restaurer les contextes SELinux sur ce fichier, dans le cas contraire Postfix ne redémarrera pas :

mai 28 15:58:31 mosquito systemd[1]: Starting Postfix Mail Transport Agent... mai 28 15:58:31 mosquito aliasesdb[7044]: postalias: fatal: open /etc/aliases.db: Permission denied mai 28 15:58:31 mosquito postfix/postalias[7046]: fatal: open /etc/aliases.db: Permission denied mai 28 15:58:34 mosquito postfix/postfix-script[7128]: starting the Postfix mail system mai 28 15:58:34 mosquito postfix/master[7130]: daemon started -- version 2.10.3, configuration /etc/postfix mai 28 15:58:34 mosquito systemd[1]: Started Postfix Mail Transport Agent.

Un simple restorecon -v /etc/aliases.db fera l'affaire.

Johan Cwiklinski : Mort de Chiliproject et migration vers Redmine

Wed, 05/14/2014 - 07:34

Depuis un certain temps (voire même un temps certain), j'utilise Chiliproject pour gérer les demandes de Galette - entre autres.

J'avais tout d'abord opté pour Redmine, avant de switcher vers Chiliproject dès la création du projet. Seulement voilà, aujourd'hui, Chiliproject semble inactif. Pas de commits depuis près d'un an, plus d'activité apparente des développeurs principaux sur les forums et autres, ... Étant moi même en charge d'un projet Open Source, je ne peux pas leur jeter la pierre, je comprends parfaitement que l'on puisse avoir d'autres centres d'intérêts et priorités. On peut avoir une vie en somme :-)" class="smiley

Le fait est que je ne souhaite pas conserver trop longtemps un projet qui n'est plus maintenu, et qui n'évoluera visiblement plus à l'avenir. La migration vers un autre projet (à condition d'en trouver un qui soit dores et déjà utilisable) ne saurait se faire sans perdre les données existantes ; et les nombreux tickets (résolus ou non) créés ces dernières années.

La solution la moins pire semble de simplement revenir à Redmine (c'est encore le projet qui s'approche le plus de Chiliproject, évidemment). Ce ne serait pas aussi rigolo si ça pouvait fonctionner sans encombres, la base de données n'est pas tout à fait compatible et requiert des modifications.

Une première documentation sur la migration de Chiliproject vers Redmine est disponible, ainsi qu'un programme Java qui se charge d'une partie de la conversion (il reste quelques requêtes à jouer à la main). Cette méthode n'a pas fonctionné pour moi, le programme tombe sur une chaîne alors qu'il attend un entier... Et c'est la fin des haricots !

En continuant mes recherches, j'ai trouvé une seconde documentation sur la migration de Chiliproject vers Redmine, qui référence la première trouvée, en ajoutant quelques remarques, et surtout un script - Ruby cette fois - de migration de la base ; ce dernier est celui qui a fonctionné pour moi.

J'ai installé mon instance de Redmine sur une CentOS6 ; qui a le « gros défaut » de fournir une version 1.8.7 de Ruby, incompatible avec le script de migration :-/" class="smiley Fort heureusement, les Software Collections existent, et sont très facilement utilisables. Récupérez le dépôt adéquat (wget http://people.redhat.com/bkabrda/scl_ruby193.repo), installez la version adéquate de Ruby (yum install ruby193 ruby19-ruby-devel).

Beaucoup de dépendances requises par Redmine ne sont pas disponibles dans les dépôts, il faut « obligatoirement » en passer par l'installation de gems locaux (ce qui n'est pas très propre, mais je n'ai pas trouvé mieux...) ; et c'est pour cela que j'ai dédié une machine virtuelle aux installations de Redmine/Chiliproject.

Je suppose que l'installation des seuls gems requis par le script de migration suffisent, mais pour le test, j'ai installé les dépendances de Redmine. J'ai rencontré quelques erreurs, j'ai brodé. La procédure pour la mise à jour au final est la suivante (l'instance de Redmine étant préalablement installée et fonctionnelle) :

cd /var/www/redmine scl enable ruby193 "gem install bundle" scl enable ruby193 "bundle install --without postgresql sqlite test development" wget https://gist.githubusercontent.com/pallan/6663018/raw/b6823dd7b4286c328e249a17f4cfb0bd9ef59373/chiliproject_to_redmine.rb scl enable ruby193 "ruby chiliproject_to_redmine.rb"

Il suffit alors de relancer Redmine pour tester si tout s'est correctement déroulé, après avoir allumé un (ou plusieurs !) cierges ;-)" class="smiley