Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Comment ne pas laisser de traces dans un shell…

Sébastien Natroll Pour une raison ou une autre, il peut être intéressant de ne pas faire figurer certaines commandes dans l’historique d’un shell. Plutôt que de favoriser la manière forte (en vidant .bash_history par exemple), je vous propose la méthode méticuleuse. Ouvrez une console et voyez plutôt… Les touches fléchées Haut et Bas de votre clavier vous La suite >

Novembre 2011

Premier Samedi Date : samedi 5 novembre 2011 Horaires : de 14h00 à 18h00 Lieu : Carrefour Numérique, Cité des Sciences et de lIndustrie, Paris Pour une nouvelle installation ou pour des ajustements de votre distribution GNU/Linux Fedora, Mandriva, Mageia ou Ubuntu, venez nous retouver le samedi 5 novembre 2011 au Carrefour Numérique de la Cité des [...]

Rencontres Fedora 16 à Paris

Association Borsalinux-Fr

L'association Borsalinux-Fr vous donne rendez-vous le samedi 3 décembre 2011 à Universciences à Paris pour les Rencontres Fedora 16. Cet événement est en marge du Premier Samedi du Libre, qui sera centré autour de la distribution Fedora.

Informations générales

  • Le 3 décembre 2011 de 14h à 18h (discussions, conférences, ateliers et installations)
  • Au Carrefour Numérique d'Universciences, Paris, France
  • Le site communautaire francophone est disponible à l'adresse fedora-fr.org

Programme des festivités

Pour cette nouvelle version de Fedora, pleine de nouveautés, ces Rencontres sont l'occasion de découvrir Fedora, sa communauté, d'échanger sur le monde Libre, mais aussi de participer à des ateliers et conférences sur des domaines spécifiques.

Lors de cette journée, vous pourrez demander une démonstration et une installation de Fedora 16 mais aussi parler de tout ce qui concerne le logiciel libre ! Au programme :

  • Dans l'Agora
    • 15 h - 15 h 30, présentation de Spice par Christophe Fergeau ;
    • 16 h - 17 h 30, découverte d'OpenStack (atelier) par Bertrand Juglas ;
    • 18 h - 18 h 45, discussions autour de la traduction francophone, par Kévin Raymond.
  • Dans la Classe numérique
    • 14 h - 18 h, discussions, démonstrations, installations.

[Le planning est susceptible d'évoluer légèrement, venez vérifier quelques jours avant !]

Si vous souhaitez contribuer, c'est tout à fait possible, contactez-nous ! Vous pourriez très bien prendre trente minutes pour présenter les nouveautés de Fedora 16.

Après l'événement

Après l'événement, des photos et un compte rendu seront disponibles ici.

Borsalino est mort vive Stetson (et merci Ikoula) !

Guillaume Kulakowski

Après 5 années de bons et loyaux services, Borsalino, le serveur hébergeant les sites de Fedora-Fr va prendre sa retraite. Mais pas de panique pour la continuité du service cela fait déjà 2 semaines que nos équipes travaillent dare dare pour déménager nos services sur le nouveau serveur, Stetson, lui aussi mis à disposition par notre partenaire Ikoula.

536 jours d'uptime

Au programme, exit la vieille Fedora Core 5 mise à jour en FC6, bonjour la belle Red Hat Enterprise Linux 6.1, installée via KVM par notre ami Remi.

Parmi les nouveautés mises en place grâce au surplus de mémoire (8Go) :

Voila, du coup la partie FC6 du dépôt llaumgui tire sa révérence.

Téléchargement : quand les ayants droit se trompent de cible.

Sébastien Natroll Dernièrement, j’ai posé les yeux par hasard sur un DVD acheté bien gentiment dans le commerce. Je me suis souvenu que ça a toujours été ainsi avec les VHS, les DVD, et certainement les Blu-Ray. Avec les VHS, on avait droit avant le début de chaque film à plusieurs minutes de publicités en tout genre La suite >

Sur Twitter, les Japonais ont l’avantage.

Sébastien Natroll Twitter, c’est avant tout un réseau social de choix pour balancer des messages de 140 caractères maximum. Quand vous êtes français (ou anglais, italien, espagnol, javanais), il en résulte une lutte de l’esprit pour optimiser au mieux le nombre de caractères utilisés et le contenu de votre message. S’il y a bien un endroit où La suite >

mysql-5.5.17

Remi Collet

Les RPM de MySQL Community Server 5.5.17 GA sont disponibles dans le dépôt remi pour fedora et pour Enterprise Linux (RHEL, CentOS, ...).

A lire : Introduction to MySQL 5.5 Changes in MySQL 5.5.17 MySQL 5.5 Reference Manual Cette construction utilise un fichier spec proche de celui de Rawhide. ATTENTION : avant la mise à jour, une sauvegarde de vos bases de données est très vivement conseillée (un vidage avec mysqldump par exemple).    L'installation la plus simple... Lire mysql-5.5.17

Borsalinux-Fr fait peau neuve !

Association Borsalinux-Fr

Bonjour Stetson !

À la suite du changement de nom de l'association, nous avons souscrit à un nouveau serveur, (nom de code Stetson) qui passe en RHEL6.1 et qui remplace notre bon vieux Borsalino (FC6 bien patché pour suivre le mouvement).

Il y aura donc moins de congestions sur fedora-fr.org. Ce serveur héberge listes de diffusion, wiki, forums, gestion de ticket, un git…

Ce qu'on y gagne, clairement ? Je cite Remi :

Ancien serveur :

Nom : borsalino
Processeur : AMD Sempron(tm) 2600+
Mémoire : 1Gio
Disque : 2x80Gio en Raid
Système : Fedora Core release 6 (Zod) (patché à mort pour disposer des dernières versions et des correctifs de sécurité)
Dépôts : extras, llaumgui et remi

Nouveau serveur :

Nom : stetson
Processeur : Intel(R) Core(TM) i3-2100T CPU @ 2.50GHz
Mémoire : 8Gio
Disque : 2x500Gio en Raid
Système : Red Hat Enterprise Linux Server release 6.1 (Santiago) (avec une souscription officielle évidement)
Dépôts : optional, epel, llaumgui et remi

Ce nouveau serveur, comme l'ancien, est gracieusement mis à notre disposition par Ikoula. Nous avons profité de l'arrivée de ce serveur pour mettre en place ce blog.

Bonjour borsalinux-fr.org !

Nous n'utiliserons plus de wiki pour l'association (nous avons toujours celui du Projet Fedora à disposition). Ce blog nous permettra de relayer les informations importantes sur la vie de l'association.

Les détails sur la migration sont sur le forum. Un grand merci à Guillaume et Remi pour ce travail !

Quand MySQL WorkBench cherche ses tables ...

Alexandre Frandemiche

MySQL WorkBenchDepuis hier, je me suis rendu compte que MySQL Workbench n'arrivait plus à lister les tables de mes schémas MySQL.

Dès que je voulais afficher les tables, "Fetching" apparaissait de manière interminable et systématique ... Serait-ce parce que le paquet fourni par Fedora est corrompu ???

# yum reinstall mysql-workbench ne change rien ...

Je passe alors par le dépôt de Remi, mais rien n'y fait ... Cela doit alors provenir de mes données ... seulement voilà, avec un bon vieux MySQL Query, cela fonctionne ... Il m'aura fallu chercher 2 secondes pour tomber sur cet incident ouvert chez MySQL, lire quelques réponses et tester ce qui suit :

$ mysql-upgrade -u myuser -pmypassword -P myport -h myhost

Je relance MySQL WorkBench et ... tadaaa ! Voilà mes tables !!!

Je pensais que partager cette astuce pourrait servir ou me servir à nouveau ;) !

Domotique/Multimedia - Samsung Galaxy Tab 7" sous Android 2.3. fournie par Samsung

Alexandre Frandemiche

Bonjour à tous !

Comme je l'avais déjà expliqué lors de ce billet : Samsung Galaxy Tab et Heimdall, ma Samsung Galaxy Tab a reçu CyanogenMod, il y a un moment en version beta, depuis, voici la version 2.3.3 où visiblement tout est fonctionnel ! Je repasse donc à une version fournie par Samsung, il paraitrait que cette dernière venue est prometteuse ... à tester donc ! Tester, certes, mais toujours depuis ma Fedora et non via Odin sous Windows ...

Pour rappel, il vous suffit de décompresser le fichier disponible à l'adresse suivante : http://file.mixturecloud.com/download=PMWw2Q.

Une fois fait, vous n'avez plus qu'à respecter ce qui figure sur l'image suivante (rappel : $ heimdall-frontend ) :

Heimdall

Une fois terminé, la tablette doit redémarrer toute seule, si ce n'est pas le cas, au bout de quelques minutes, faites-le manuellement en appuyant longuement sur le bouton "power".

Il faut redémarrer en mode recovery ("power" + "volume up"), faire un wipe (restore default) puis il faut redémarrer la tablette à nouveau depuis le menu du recovery (bouton "home" = OK).

Et voilà, vous avez une tablette toute neuve, sans surcouche opérateur, mais fournie par Samsung ! Ainsi vous pouvez profiter pleinement de votre tablette et des applications made by Samsung ;) !

Enjoy !

GLPI version 0.80

Remi Collet

GLPI (Gestionnaire Libre de Parc Informatique) version 0.80.4 est sorti. Lire les annonces : 0.80, 0.80.1, 0.80.2, 0.80.3 et 0.80.4. Les RPM sont disponibles dans le dépôt remi.

Il s'agit d'une version majeure très orientée ITIL (implémentation des SLA, notamment)

La documentation est disponible au format PDF : glpidoc-0.80.1.pdf La version 0.78.x n'est plus maintenue et la version 0.80.x est désormais stable, et les principales extensions sont disponibles.Actuellement, dans le dépôt : glpi-0.80.4-1 glpi-appliances-1.7.0-1 glpi-data-injection-2.1.0-1 glpi-fusioninventory-2.4.0-1... Lire GLPI version 0.80

PHP et les extensions PECL pour ZTS

Remi Collet

PHP est disponible pour apache en mode prefork et worker. Fedora ne fournit aucune extension (ce qui le rend inutilisable).

Depuis la version 5.3.1 les extensions pour ZTS (mode worker) sont disponibles dans mon dépôt. Désormais les extensions PECL pour ZTS le sont également.

Attention : les extensions, ou les bibliothèques liées, ne sont pas toutes sécurisées pour ce mode (thread-safe) ce qui peut provoquer des plantages. Depuis la version 5.3.8-5, j'ai modifié le contenu du paquet php-devel afin de fournir les éléments nécessaires à la construction des extensions PECL pour le mode ZTS : /usr/bin/php-zts/php-config... Lire PHP et les extensions PECL pour ZTS

fail2ban : punir les récidivistes

Fabien Nicoleau

Fail2ban permet de bannir des adresses IP tentant de s'attaquer à votre système. Elles sont repérées grâce aux fichiers de log des différents services. Fail2ban les consulte et agit en fonction des expressions régulières qui lui sont données, et d'une tolérance d'erreurs donnée.

Les "bans" ont une durée, mais parfois on se rend compte qu'aussitôt son ban terminé, une adresse tente de nouveau de s'attaquer au système. Une solution simple peut être de mettre une rêgle permanante avec iptables, ce qui règlera définitivement le problème. Cependant cette solution ne me convient pas totalement car je n'aime pas le fait d'ajouter des règles à iptables qui ne seront peut être pas toujours utiles (l'attaquant peut s'arrêter, ou son adresse peut changer). De plus, j'aime assez l'idée qu'un serveur puisse être un minimum autonome. Si je ne consulte pas les logs de mon serveur pendant 1 mois et que je ne me rend pas compte qu'une adresse m'attaque à longueur de journée, mon serveur risque d'être en danger.

Pour régler ce problème, il suffit de créer un jail dans fail2ban qui scrutera son propre log. Ainsi il sera possible de bannir pour une très longue durée une IP qui déjà été bannie plusieurs fois. Cette technique est expliquée dans un article en anglais, je propose ici une explication en  français.

La première chose à faire est de créer un filtre, qu'on placera dans /etc/fail2ban/filter.d/fail2ban-recidivist.conf . En voici le contenu :

[Definition]
failregex = fail2ban.actions: WARNING \[(.*)\] Ban <HOST>
ignoreregex = fail2ban.actions: WARNING \[fail2ban-recidivist\] Ban <HOST>

La ligne du failregex indique la regex qui permettra de repérer les lignes de ban dans le fichier de log de fail2ban. La dernière ligne permet d'ignorer les bans ajoutés par notre nouvelle règle. Cela évitera de les comptabiliser et donc de fausser le nombre de bans à prendre en compte pour une IP. Notez ici que nous ignorons les bans pour le jail fail2ban-recidivist. Si vous changez le nom du jail, pensez aussi à modifier le filtre pour que l'ignoreregex soit correcte.

Il faut ensuite ajouter un jail dans le fichier /etc/fail2ban/jail.conf, dont voici la définition :

[fail2ban-recidivist]
enabled  = true
filter   = fail2ban-recidivist
action   = iptables-allports[name=recidivist]
logpath  = /var/log/messages
maxretry = 5
# 1 semaine
findtime = 604800
# 1 semaine
bantime  = 604800

Comme pour les autres jails, on indique ici le nom du filtre utilisé (et dont nous avons donné la définition précédemment), l'action à effectuer (je choisis ici de bannir sur tous les ports l'attaquant, et de passer le nom "recidivist" à iptables pour la règle. Il serait aussi possible, voir même judicieux, d'envoyer un e-mail pour vous prévenir de ce ban particulier grâce à l'action sendmail-whois), le fichier de log à scruter, qui est pour ce jail celui de fail2ban (qui utilise SYSLOG dans mon cas), le nombre de tentatives infructueuses, la plage de temps sur laquelle on fait le décompte, et enfin le temps de banissement.

Pour ce cas précis, je bannis pendant une semaine une personne qui a déja été bannie 5 fois durant la dernière semaine par d'autres règles. Sachant que chaque règle a elle aussi un nombre de tentatives d'essais (3 par défaut), cela donne tout de même une bonne tolérance.

Il faut noter que si vous utilisez une action qui ne prend pas en compte de nom (ici recidivist), et qui enregistre simplement l'adresse IP, ce système ne fonctionnera pas. En effet, si une personne est bannie parce qu'elle a essayé de s'authentifier sans succès plusieurs fois, pour une durée d'un jour, et qu'ensuite ce jail bannit l'IP pour une semaine, au bout d'une journée, le premier ban sera retiré, l'IP donc retirée, et le ban d'une semaine annulé. Ce problème n'apparait pas avec iptables car il prend en compte le nom de l'action, et ne confond donc pas les bans. En revanche, cela semble pouvoir se produire avec ipfw, hostsdeny et shorewall.

Voilà grâce à cette règle un serveur un peu plus autonome, qui sévira de façon plus dure s'il est attaqué trop souvent par la même personne.


Fabien (eponyme)

fail2ban : punir les récidivistes

Fabien Nicoleau

Fail2ban permet de bannir des adresses IP tentant de s'attaquer à votre système. Elles sont repérées grâce aux fichiers de log des différents services. Fail2ban les consulte et agit en fonction des expressions régulières qui lui sont données, et d'une tolérance d'erreurs donnée.

Les "bans" ont une durée, mais parfois on se rend compte qu'aussitôt son ban terminé, une adresse tente de nouveau de s'attaquer au système. Une solution simple peut être de mettre une rêgle permanante avec iptables, ce qui règlera définitivement le problème. Cependant cette solution ne me convient pas totalement car je n'aime pas le fait d'ajouter des règles à iptables qui ne seront peut être pas toujours utiles (l'attaquant peut s'arrêter, ou son adresse peut changer). De plus, j'aime assez l'idée qu'un serveur puisse être un minimum autonome. Si je ne consulte pas les logs de mon serveur pendant 1 mois et que je ne me rend pas compte qu'une adresse m'attaque à longueur de journée, mon serveur risque d'être en danger.

Pour régler ce problème, il suffit de créer un jail dans fail2ban qui scrutera son propre log. Ainsi il sera possible de bannir pour une très longue durée une IP qui déjà été bannie plusieurs fois. Cette technique est expliquée dans un article en anglais, je propose ici une explication en  français.

La première chose à faire est de créer un filtre, qu'on placera dans /etc/fail2ban/filter.d/fail2ban-recidivist.conf . En voici le contenu :

[Definition]
failregex = fail2ban.actions: WARNING \[(.*)\] Ban <HOST>
ignoreregex = fail2ban.actions: WARNING \[fail2ban-recidivist\] Ban <HOST>

La ligne du failregex indique la regex qui permettra de repérer les lignes de ban dans le fichier de log de fail2ban. La dernière ligne permet d'ignorer les bans ajoutés par notre nouvelle règle. Cela évitera de les comptabiliser et donc de fausser le nombre de bans à prendre en compte pour une IP. Notez ici que nous ignorons les bans pour le jail fail2ban-recidivist. Si vous changez le nom du jail, pensez aussi à modifier le filtre pour que l'ignoreregex soit correcte.

Il faut ensuite ajouter un jail dans le fichier /etc/fail2ban/jail.conf, dont voici la définition :

[fail2ban-recidivist]
enabled  = true
filter   = fail2ban-recidivist
action   = iptables-allports[name=recidivist]
logpath  = /var/log/messages
maxretry = 5
# 1 semaine
findtime = 604800
# 1 semaine
bantime  = 604800

Comme pour les autres jails, on indique ici le nom du filtre utilisé (et dont nous avons donné la définition précédemment), l'action à effectuer (je choisis ici de bannir sur tous les ports l'attaquant, et de passer le nom "recidivist" à iptables pour la règle. Il serait aussi possible, voir même judicieux, d'envoyer un e-mail pour vous prévenir de ce ban particulier grâce à l'action sendmail-whois), le fichier de log à scruter, qui est pour ce jail celui de fail2ban (qui utilise SYSLOG dans mon cas), le nombre de tentatives infructueuses, la plage de temps sur laquelle on fait le décompte, et enfin le temps de banissement.

Pour ce cas précis, je bannis pendant une semaine une personne qui a déja été bannie 5 fois durant la dernière semaine par d'autres règles. Sachant que chaque règle a elle aussi un nombre de tentatives d'essais (3 par défaut), cela donne tout de même une bonne tolérance.

Il faut noter que si vous utilisez une action qui ne prend pas en compte de nom (ici recidivist), et qui enregistre simplement l'adresse IP, ce système ne fonctionnera pas. En effet, si une personne est bannie parce qu'elle a essayé de s'authentifier sans succès plusieurs fois, pour une durée d'un jour, et qu'ensuite ce jail bannit l'IP pour une semaine, au bout d'une journée, le premier ban sera retiré, l'IP donc retirée, et le ban d'une semaine annulé. Ce problème n'apparait pas avec iptables car il prend en compte le nom de l'action, et ne confond donc pas les bans. En revanche, cela semble pouvoir se produire avec ipfw, hostsdeny et shorewall.

Voilà grâce à cette règle un serveur un peu plus autonome, qui sévira de façon plus dure s'il est attaqué trop souvent par la même personne.


Fabien (eponyme)

Dennis Ritchie : mort du père de l’informatique d’aujourd’hui.

Sébastien Natroll On en a fait des tas avec Steve Jobs. Génie, visionnaire, véritable père pour certains, aujourd’hui je voudrais rendre hommage à un homme de l’ombre, un homme dont l’œuvre est immense tant elle a influencé l’informatique telle qu’elle existe aujourd’hui. Cet homme est Dennis Ritchie. Pour les étudiants en informatique, ce nom rappelle vaguement quelque La suite >

Dennis Ritchie : mort du père de l'informatique d'aujourd'hui.

Sébastien Natroll On en a fait des tas avec Steve Jobs. Génie, visionnaire, véritable père pour certains, aujourd’hui je voudrais rendre hommage à un homme de l’ombre, un homme dont l’œuvre est immense tant elle a influencé l’informatique telle qu’elle existe aujourd’hui. Cet homme est Dennis Ritchie. Pour les étudiants en informatique, ce nom rappelle vaguement quelque La suite >

fail2ban : classement des IP les plus bannies

Fabien Nicoleau

J'utilise depuis très longtemps fail2ban, qui permet de bannir des IP générant trop d'erreurs (le plus souvent des échecs d'authentification). Il se base sur les logs des différents services et des expressions régulières pour retrouver les tentatives et les bannir.

Je m'y suis un peu plus intéressé ces derniers temps car j'ai été attaqué par des scripts vraiment insistants (ce sera l'objet d'un prochain billet). Dans un premier temps, j'ai voulu obtenir une liste des adresses bannies, avec le nombre de fois, afin de déceler des "récidivistes". Voici la commande utilisée (fail2ban log avec SYSLOG sur mon serveur) :

cat /var/log/messages|grep Ban|awk '{print $7" "$9}'|sort|uniq -c|sort -r

Voici l'explication de la commande :

  • cat : affichage du fichier de log
  • grep Ban : on ne conserve que les lignes concernant un bannissement
  • awk : on extrait simplement les 7ème et 9ème parties, c'est à dire le "jail" utilisé pour le ban, et l'IP bannie
  • un premier sort pour faire en sorte que les IP identiques soient listées les unes en dessous des autres
  • uniq -q : réunies les lignes communes et affiche devant le nombre de fois qu'elles apparaissent
  • un dernier sort (avec l'option reverse) pour faire un tri inverse

On se retrouve ainsi avec une liste indiquant le nombre de fois qu'a été bannie une IP, le jail utilisé et l'IP bannie, le tout dans l'ordre décroisant. Voici un exemple :

      8 [ssh-iptables] 188.138.98.75
      2 [apache-dfind] 93.174.2.202
      2 [apache-dfind] 81.196.179.210
      2 [apache-dfind] 217.70.51.154
      1 [ssh-iptables] 96.8.121.185
      1 [ssh-iptables] 87.106.132.104
      1 [ssh-iptables] 58.211.5.130
      1 [ssh-iptables] 221.207.229.6
      1 [ssh-iptables] 201.140.103.17

Le défaut de cette commande est que l'odre est faire sur du texte, et donc si une IP est bannie plus de 9 fois, elle apparaitra en bas, au lieu d'être en haut.

Cela permet cependant de repérer rapidement une IP trop "agressive" pour la bannir définitivement par exemple.


Fabien (eponyme)

fail2ban : classement des IP les plus bannies

Fabien Nicoleau

J'utilise depuis très longtemps fail2ban, qui permet de bannir des IP générant trop d'erreurs (le plus souvent des échecs d'authentification). Il se base sur les logs des différents services et des expressions régulières pour retrouver les tentatives et les bannir.

Je m'y suis un peu plus intéressé ces derniers temps car j'ai été attaqué par des scripts vraiment insistants (ce sera l'objet d'un prochain billet). Dans un premier temps, j'ai voulu obtenir une liste des adresses bannies, avec le nombre de fois, afin de déceler des "récidivistes". Voici la commande utilisée (fail2ban log avec SYSLOG sur mon serveur) :

cat /var/log/messages|grep Ban|awk '{print $7" "$9}'|sort|uniq -c|sort -r

Voici l'explication de la commande :

  • cat : affichage du fichier de log
  • grep Ban : on ne conserve que les lignes concernant un bannissement
  • awk : on extrait simplement les 7ème et 9ème parties, c'est à dire le "jail" utilisé pour le ban, et l'IP bannie
  • un premier sort pour faire en sorte que les IP identiques soient listées les unes en dessous des autres
  • uniq -q : réunies les lignes communes et affiche devant le nombre de fois qu'elles apparaissent
  • un dernier sort (avec l'option reverse) pour faire un tri inverse

On se retrouve ainsi avec une liste indiquant le nombre de fois qu'a été bannie une IP, le jail utilisé et l'IP bannie, le tout dans l'ordre décroisant. Voici un exemple :

      8 [ssh-iptables] 188.138.98.75
      2 [apache-dfind] 93.174.2.202
      2 [apache-dfind] 81.196.179.210
      2 [apache-dfind] 217.70.51.154
      1 [ssh-iptables] 96.8.121.185
      1 [ssh-iptables] 87.106.132.104
      1 [ssh-iptables] 58.211.5.130
      1 [ssh-iptables] 221.207.229.6
      1 [ssh-iptables] 201.140.103.17

Le défaut de cette commande est que l'odre est faire sur du texte, et donc si une IP est bannie plus de 9 fois, elle apparaitra en bas, au lieu d'être en haut.

Cela permet cependant de repérer rapidement une IP trop "agressive" pour la bannir définitivement par exemple.


Fabien (eponyme)

Mise à jour de quvi pour rawhide : éclatement des paquets

Fabien Nicoleau

Je paquage le logiciel "quvi" pour Fedora. Ce logiciel fournit une bibliothèque (libquvi) permettant de parser les vidéos des sites tels que youtube ou dailymotion (et beaucoup d'autres) ainsi qu'un outil (quvi) utilisant libquvi pour parser les vidéos. La dernière version, la 0.4.0, est maintenant divisée en 3 sources : libquvi (la bibliothèque), libquvi-scripts (les scripts lua utilisés par libquvi permettant de parser les sites) et quvi, l'utilitaire.

J'ai donc aujourd'hui fait les demandes de revue pour les paquets libquvi et libquvi-scripts. Je mettrai à jour quvi quand les deux dépendances auront été importées dans les dépôts:

Ces changements sont importants et ne seront donc effectués que dans rawhide.


Fabien (eponyme)

Mise à jour de quvi pour rawhide : éclatement des paquets

Fabien Nicoleau

Je paquage le logiciel "quvi" pour Fedora. Ce logiciel fournit une bibliothèque (libquvi) permettant de parser les vidéos des sites tels que youtube ou dailymotion (et beaucoup d'autres) ainsi qu'un outil (quvi) utilisant libquvi pour parser les vidéos. La dernière version, la 0.4.0, est maintenant divisée en 3 sources : libquvi (la bibliothèque), libquvi-scripts (les scripts lua utilisés par libquvi permettant de parser les sites) et quvi, l'utilitaire.

J'ai donc aujourd'hui fait les demandes de revue pour les paquets libquvi et libquvi-scripts. Je mettrai à jour quvi quand les deux dépendances auront été importées dans les dépôts:

Ces changements sont importants et ne seront donc effectués que dans rawhide.


Fabien (eponyme)

Page générée le 28 fév 2015 à 21:39