Subscribe: Génération Linux - Mot-clé - Tutoriel
http://www.generation-linux.fr/index.php?feed/tag/Tutoriel/rss2
Added By: Feedage Forager Feedage Grade A rated
Language:
Tags:
avec  dans  des  données  est  fichier  les  linux  mon  par  pas  pour  qui  répertoire  serveur  sur  tout  une  vous 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Génération Linux - Mot-clé - Tutoriel

Génération Linux - Mot-clé - Tutoriel



Ce blog est consacré à GNU/Linux et à tous les logiciels libres. Vous trouverez sur ce blog des news, des tutoriels, des cours, des trucs et astuces, des liens et divers articles concernant le monde du libre.



Published: Thu, 14 Dec 2017 09:43:12 +0100

 



rssLounge, un excellent gestionnaire de flux RSS !

Sat, 02 Jul 2011 14:46:00 +0200

J'utilise Tiny Tiny RSS depuis déjà quelques temps. Quand je cherchais des alternatives à Netvibes (début 2009), Tiny Tiny RSS m'avait semblé être le meilleur outil disponible pour lire ses flux RSS à partir de son serveur (toujours dans mon optique d'auto-hébergement). Après avoir lu l'article de ®om, je me suis rendu compte que pas mal de gens se plaignaient de TTRSS (pour des raisons que j'évoquerai dans cet article) et préféraient rssLounge. Étant également un peu insatisfait de TTRSS (j'en parlerai là aussi plus en détail), j'ai décidé de tester rssLounge. Un excellent logiciel que j'ai adopté et que je vous invite à découvrir : I. Le changement Je vais tout d'abord vous détailler les raisons qui m'ont fait abandonner Tiny Tiny RSS au profit d'une nouvelle solution de gestion de flux RSS :Le temps de chargement : c'est l'inconvénient qui revenait le plus souvent (forcément), je viens de chronométrer, Tiny Tiny RSS met précisément 9 secondes entre le temps où je valide mes identifiants et où l'application est opérationnelle. 9 secondes ça peut paraitre peu, mais pour un temps de chargement de page web, je vous assure que c'est énorme ! Par ailleurs, la navigation au sein des différentes catégories, des flux RSS ou dans la configuration est assez longue également. L'espace pris par la base de données : Mon installation actuelle de TInty Tiny RSS date d'un peu plus de 6 mois et ma base de données fait déjà 60 Mo ! Alors j'ai bien vu qu'il y avait une option de purge. Cependant, comme je l'ai évoqué ici, je n'ai pas réussi à la faire fonctionner (et c'est pas faute d'avoir essayé). J'avais beau mettre une purge pour les articles plus vieux de 3 jours, j'avais encore tous mes articles en base de données... L'installation pénible : J'ai trouvé cela pénible de devoir, lors de l'installation, créer sa base de données et la peupler "à la main" avec un banal fichier .sql. Un installeur est simple à mettre en place, je n'ai pas compris pourquoi il n'y en avait pas. Un système de mise à jour des flux pas très intuitif : J'ai trouvé le système de mise à jour des flux assez "difficile" à comprendre et n'est pas très bien expliqué dans la documentation officielle. Ce sont donc les principales raisons qui m'ont fait abandonner Tiny Tiny RSS. Comme vous pouvez le constater, ce ne sont pas des problèmes bloquants, mais c'est juste que mis les uns à la suite des autres, l'utilisation finale ne devient plus très agréable.J'ai donc décidé de tester rssLounge. II. Fonctionnalités Voici ses principales caractéristiques traduites du site officiel : Un lecteur RSS très complet Permet de définir des priorités pour des flux et n'afficher que certaines priorités (et donc certains flux) Supporte les images et photos, et permet de suivre facilement les photoblogs et les sites du genre deviantart, flickr, tumblr Une belle interface (ajax), très intuitive et facile à utiliser (drag & drop, etc.) Un système de plugins pour définir de nouvelles sources de données, permettant ainsi de suivre des pages ne supportant pas les RSS Possibilité de définir des expressions régulières pour filtrer les messages Supporte les mises à jour ajax et via crontab Import/export OPML Multilingue Voici un screenshot de mon rrsLounge actuel (où on peut voir un photoblog (tumblr) en haut des articles). Cliquez pour agrandir : III. Installation Pour commencer, il faut aller récupérer l'application sur le site officiel puis le mettre en place sur un serveur web. Pensez à donner les droits d'apache sur votre répertoire (chown -R www-data:www-data /var/www/rss). Il n'y a plus qu'à aller sur l'URL en question. Un installeur s'affiche. Ici, j'avais 2 erreurs, j'ai voulu vous les montrer pour que vous sachiez comment faire si vous les rencontriez. La première, mod_rewrite non chargé c'est parce que le fichier .htaccess de votre application n'est pas interprété. Dans le répertoire de rssLounge, il y a un fichier .htaccess indispensable.Chez moi, c'est parce que dans ma confi[...]



Sauvegarder automatiquement ses sites web distants chez soi

Sat, 04 Jun 2011 13:11:00 +0200

Je m'occupe et administre plusieurs sites hébergés ailleurs que chez moi, sur un serveur d'hébergement mutualisé. Autrement dit, je n'ai qu'un accès FTP au répertoire www. Aucune sauvegarde n'est donc faite sur ces machines. de temps en temps, quand j'y pense, je fais un backup "manuel" en me connectant en FTP et en rapatriant les données chez moi, puis je vais sur l'interface phpmyadmin et fait un export de la base. Une solution pas terrible, vous en conviendrez.Depuis que j'ai mon serveur perso chez moi, je me suis dit qu'il serait intéressant d'automatiser cette sauvegarde. Je n'aurai donc plus à me soucier de le faire "manuellement" une fois par mois.Voici les scripts que j'ai utilisé, ma procédure, mon automatisation, bref, un petit tuto pour sauvegarder automatiquement ses sites web hébergés loin de chez soi. I. L'environnement Je m'occupe actuellement de 3 "gros" sites 'propulsés par Joomla' hébergés chez un hébergeur qui me propose un accès FTP sur le répertoire www ainsi qu'une base de données que j'administre via phpmyadmin.Je vais prendre l'exemple du plus gros site que j'administre et que je veux sauvegarder chez moi automatiquement :Un répertoire www de 1,2 Go (1945 répertoires et 20017 fichiers) accessible uniquement en FTP Une base de donnée de plusieurs dizaines de Mo et d'une centaine de tables La base de données n'est pas accessible à distance (je ne peux pas faire un mysqldump de chez moi sur la base) Les modifications sur le www ne sont pas fréquentes, en revanche, les modifications sur la base sont nombreuses et quotidiennes Les backups du www via FTP durent environ 1h30, 2h (très grand nombre de petits fichiers et grosses photos) Je veux une sauvegarde mensuelle pour le répertoire www et une sauvegarde hebdomadaire pour la base de données. Voila pour les données de base. Voici comment je fais pour sauvegarder tout ça.II. La sauvegarde La sauvegarde va se dérouler en 3 étapes : la sauvegarde de la base de données (qui, elle aussi, va se découper en 2 temps), la sauvegarde du répertoire www et enfin, l'automatisation de tout cela.La base de données Comme je vous l'ai dit, je ne peux pas accéder directement à la base depuis chez moi. Si j'avais pu, un simple mysqldump aurait fait l'affaire. Si vous avez un accès distant sur votre base, vous pouvez passer cette étape. Ici, c'est un peu plus compliqué : il faut générer un mysqldump sur la machine distante puis récupérer le dump en FTP.Il faut donc, dans un premier temps, écrire le script de génération de dump. Ce sera un script php que nous appelleront, via curl, dans notre script shell de backup (voir après). $db.sql");#On vire l'ancienne version gzippée du dumpsystem("rm $db.sql.gz");#On gzip la nouvelle versionsystem("gzip $db.sql");?>À ma racine www, j'ai créé un répertoire backup dans lequel j'ai ajouté ce script backup.php. Ainsi, dès qu'on appellera la page http://monsite.fr/backup/backup.php, un dump mydatabase.sql.gz sera généré dans ce répertoire backup. Ensuite, sur mon serveur je créé mon script shell de backup de mysql :#!/bin/bash#Ce script fait un backup de la BDD et la récupère en ftp#FICHIER_DUMP='/www/backup/mydatabase.sql.gz'FICHIER_DEST='/sauvegardes/monsite/mysql/mydatabase.sql.gz'MAIL_CONTACT='mail@me.fr' #On génère le fichier sur le serveur (voir ci-dessus)curl -s http://monsite.fr/backup/backup.phpsleep 10#On vire l'ancienne version sur le serveurrm -f $FICHIER_DEST #On ramène le fichier sauvegardé via ftp sur notre serveurlftp ftp://login:pass@ftp.monsite.fr -e "get $FICHIER_DUMP -o $FICHIER_DEST ; quit"  RET=$? if [ $RET -gt 0 ] then MESSAGE="Erreur de dump de la base $FICHIER_DUMP" echo $MESSAGE | /usr/bin/mail -s "Erreur sur le serveur" $MAIL_CONTACT filftp ftp://login:pass@ftp.monsite.fr -e "rm $FICHIER_DUMP ; quit"Explications :La varia[...]



Supprimer les anciens noyaux : gagner de la place et alléger Grub

Sun, 06 Feb 2011 11:04:00 +0100

J'utilise la version 10.04 LTS d'Ubuntu depuis sa sortie, ça fait donc presque un an. Au fil des mises à jour, des nouveaux noyaux sont installés, rendant obsolètes les anciens. Le problème, c'est qu'à chaque nouveau noyau, ça fait 2 lignes supplémentaires dans la liste du Grub au démarrage de la machine. D'habitude (avec les anciennes version d'Ubuntu, et donc de Grub), je modifiais juste le fichier de conf du Grub (/boot/grub/menu.lst) pour effacer de la liste les anciens noyaux. C'est une mauvaise solution et c'est plus compliqué à faire avec la nouvelle version de Grub. J'ai donc décidé de faire les choses correctement : supprimer les anciens noyaux. Je gagne ainsi de la place sur mon disque dur et dans ma liste de Grub. I. Connaitre les noyaux installés Nous allons commencer par regarder les noyaux qui sont installés sur notre machine. Pour cela, on utilise la commande suivante : sudo dpkg -l | grep linux Cela nous affiche tous les paquets installés sur notre machine contenant le mot "linux". Dans cette liste, ce sont ces entrées qui nous intéressent : ii  linux-headers-2.6.32-25              2.6.32-25.45                                    Header files related to Linux kernel versionii  linux-headers-2.6.32-25-generic      2.6.32-25.45                                    Linux kernel headers for version 2.6.32 on xii  linux-headers-2.6.32-26              2.6.32-26.48                                    Header files related to Linux kernel versionii  linux-headers-2.6.32-26-generic      2.6.32-26.48                                    Linux kernel headers for version 2.6.32 on xii  linux-headers-2.6.32-27              2.6.32-27.49                                    Header files related to Linux kernel versionii  linux-headers-2.6.32-27-generic      2.6.32-27.49                                    Linux kernel headers for version 2.6.32 on xii  linux-headers-2.6.32-28              2.6.32-28.55                                    Header files related to Linux kernel versionii  linux-headers-2.6.32-28-generic      2.6.32-28.55                                    Linux kernel headers for version 2.6.32 on xii  linux-headers-generic        &nb[...]



Soyez votre propre fournisseur OpenID avec SimpleID

Sat, 08 Jan 2011 13:01:00 +0100

J'ai eu du mal à trouver un titre court et précis pour cet article. Voici les points que je sohaite aborder dans cet article : Qu'est ce qu'OpenID ? Qu'est ce qu'être fournisseur OpenID ? Pourquoi l'être ? Comment l'être ? Il est temps de reprendre le contrôle de nos données. Ça, je ne vous l'apprends pas. Mais que pensez-vous de reprendre également le contrôle de votre identité numérique, de vos identifiants, de vos mots de passe. Comment centraliser vos informations personnelles chez vous, sur votre machine ? Je vais essayer de répondre à ces questions dans cet article. I. Qu'est ce qu'OpenID ? OpenID est un système d’authentification décentralisé qui permet l’authentification unique, ainsi que le partage d’attributs. Il permet à un utilisateur de s’authentifier auprès de plusieurs sites (devant prendre en charge cette technologie) sans avoir à retenir un identifiant pour chacun d’eux mais en utilisant à chaque fois un unique identifiant OpenID. Wikipedia Concrètement, en général, quand vous souhaitez vous inscrire sur un site, vous devez : remplir un formulaire avec plus ou moins de données vous concernant (pseudo, nom, prénom, mail, age, etc.) valider votre demande et attendre un mail de confirmation aller sur votre boite mail pour cliquer sur un lien d'activation Ce processus est à répéter sur chaque nouveau site, à chaque nouvelle inscription. Outre le fait que ce soit assez rébarbatif, on fini par ne plus s'y retrouver avec toutes ces identités ("quel pseudo j'ai choisi pour ce site, quel mot de passe, etc."). De plus, problème récurent de ces dernières années, vous confiez vos données, vos mots de passe, vos coordonnées à de nombreux sites, sans savoir ce qu'ils en font, ce qu'ils peuvent en faire ou encore si tout cela est bien sécurisé : combien de sites n'utilisent toujours pas le HTTPS pour les formulaires de connexion (facebook, twitter & co), laissant transiter en clair vos mots de passe sur le réseau. Le mécanisme d'OpenID est le suivant : Vous créez un compte (ou "identité") OpenID sur votre serveur : vous renseignez votre login, mot de passe, adresse mail, nom et quelques autres attributs Vous pouvez désormais aller sur un site supportant l'authentification OpenID : vous cliquez sur "Me connecter avec mon identifiant OpenID" Vous êtes redirigé vers votre serveur Vous vous identifiez sur votre serveur (avec le login et le mot de passe de votre compte OpenID) Vous êtes redirigé et automatiquement authentifié sur le site d'où vous venez. Si par la suite, vous allez sur un autre site qui supporte l'authentification OpenID, vous cliquez sur "Me connecter avec mon identifiant OpenID" Vous êtes redirigé vers votre serveur Et comme vous vous étiez déjà connecté auparavant, vous êtes automatiquement redirigé et authentifié vers ce deuxième site. Je suis assez clair ? C'est le principe du SSO (Single Sign On) : On s'authentifie une fois et on est authentifié sur tous les autres sites avec cette même identité.Ainsi, une seule identité, un seul endroit où sont stockés vos informations, mot de passe, coordonnées, etc. : chez vous ! Note : J'ai été un peu vite en disant "vous créez un compte OpenID sur votre serveur". Vous pouvez, si vous ne souhaitez pas le mettre sur votre serveur, créer un compte chez un fournisseur OpenID "public" (liste des fournisseurs). II. Être son propre fournisseur OpenID ? Cet article a pour but de vous montrer comme être son propre fournisseur OpenID. Les raisons de devenir son fournisseur ont été évoquées ci-dessus (on reste maitre de ses données, de ses mots de passe, de son identité en centralisant tout ça chez soi). Je pense que quitte à centraliser quelque chose, autant que ce soit chez soi ;) Pour faire cela, de nombreuses applications sont disponibles, dans de nombreux langages (voir la liste). Pour ma part, j'ai mis en place SimpleID, une application simple, rapide à mettre en place, sécurisée,[...]



Artica: Une console Web d'administration d'un serveur Linux pour entreprises

Thu, 04 Nov 2010 13:15:00 +0100

Il existe de nombreuses console web d'administration. La plus connue de tous est "Webmin". Artica est un projet Open Source qui tente d'aller plus loin... Artica en 3 mots :  Artica est un "front-end" d'administration d'un serveur Linux développé en Ajax/PHP et FreePascal. Qui peut être intéressé ? Vous gérez une petite entreprise, vous ne disposez pas des compétences Linux pour aborder les sujets tels que la messagerie, le proxy, le serveur de fichier, le VPN et le VDI mais vous souhaitez vous en équiper à moindre coûts.  Continuez à lire ce billet. Vous êtes expert Linux voir un "geek" et ce depuis plusieurs années.  Pour vous Linux n'a pas de "secrets"...  Fermez cette page, cela ne vous intéressera pas. Les distributions Linux supportées : Artica est développé d'abord sous Debian/Ubuntu et porté pour supporter OpenSuse, Mandriva, CentOS et Fedora. Quels sont les modules et logiciels affectés par Artica ? Artica est en charge de gérer les logiciels suivants :  La messagerie: Le relais: Postfix, SpamAssassin, ClamAv, Amavis, milter-greylist, policyd, alermime, ASSP, milter-dkim, OpenDKIM, dkim-filter, Kaspersky Antispam, Kaspersky Antivirus. Les boîtes aux lettres : RoundCube, cyrus-imap, Zarafa, imapsync Le serveur de fichier :  Samba, Kaspersky For Samba, ScannedOnly, rsync, NFS, DropBox, Xapian (moteur de recherche), BackupPC Le proxy Internet Squid, DansGuardian, AddZap, squidGuard, ufdbGuard, C-ICAP Le VPN avec OpenVPN Le Virtual Desktop Infrastructure  VirtualBox, ThinClient2 La gestion utilisateur :  OpenLDAP et Mysql. Les groupwares  RoundCube, OpenGoo, Drupal, Joomla, SugarCRM Artica quelles sont les différences ? Faire un panel web, pour tout développeur, c'est pas si compliqué que cela...  Une représentation des paramètres par des champs et formulaires: Cela,  toutes les consoles déjà existantes proposent ce principe. Un démon Artica va plus loin en rajoutant démon qui tourne en tâche de fond.  Ce démon à pour but de surveiller et de "réparer" des dysfonctionnements qui pourraient être trouvés en cours de production. En faites, grâce à Internet et fort d'une énorme communauté, l'ensemble des erreurs et leurs solutions sont déjà disponibles. Ce démon est prévu pour rencontrer ces erreurs et y apporter les corrections de façon dynamique. Un fil conducteur. L'ensemble des logiciels malgré qu'ils soient développés chacun de leur côté sont alors rassemblés dans la console afin d'établir un fil conducteur en fonction d'un service donné.L'exemple le plus frappant c'est par exemple la gestion de Roundcube en multi-domaines qui est associée avec la possibilité de créer plusieurs instances postfix.Chaque organisation ajoutée dans la console dispose alors de son propre relais de messagerie et de son propre WebMail.On ne parle pas d'Amavis, Spamassassin,milter-greylist mais on parle d'anti-spam et de gestion de quarantaine, le démon est la pour paramétrer les modules en fonction des besoins.Du Sexy ! Fini les consoles d'administration austères en Times New Roman. La console est entièrement en Ajax. Des illustrations proposent de comprendre d'un premier coup d'oeil la fonctionnalité et son intérêt.Multi-administrateurs La composition des utilisateurs s'effectue de la sorte : On créé des organisations. Chaque organisation dispose de groupes utilisateurs qui hébergent des utilisateurs.Chaque groupe dispose de droits spécifiques.La console web s'adapte à ces droits et n'affiche que les fonctionnalités privilégiées.L'ensemble de ces modules sont régis par une base de données commune : OpenLdap. Tous les modules sont coordonnés autour de la gestion des utilisateurs où via chaque profil, un utilisateur peut avoir accès aux services ou non.L'interface multi-utilisateurs et multi-administrateurs défie les règle[...]



Créer une ferme de wikis avec Dokuwiki

Wed, 23 Dec 2009 17:44:00 +0100

Ce titre n'est peut-être pas très explicite, qu'est-ce que "dokuwiki", qu'est-ce qu'une "ferme", qu'est-ce que "créer" ? Cet article va vous présenter ce qu'est dokuwiki, pourquoi je pense que c'est le meilleur moteur de wiki libre, ce qu'est une ferme de wikis et comment faire une ferme de dokuwikis. I. Pourquoi Dokuwiki ? DokuWiki est un moteur de wiki libre distribué sous licence GNU GPL créé par Andreas Gohr en juin 2004. Contrairement à la plupart des autres moteurs de wiki, Dokuwiki stocke ses données dans des fichiers textes sur la machine, aucune base de données n'est donc nécessaire (ce qui est, pour moi, un atout non négligeable et très appréciable) ! La dernière version de dokuwiki est disponible sur le site officiel. Un autre gros avantage de Dokuwiki est sa grande communauté de contributeurs. En effet, dokuwiki est tellement souple que beaucoup de monde à décidé de développer dessus. Par exemple, si vous allez voir sur la page officielle des plugins, vous pourrez vous rendre compte qu'il y en a énormément (570 à l'heure où j'écris ces lignes), pour tous les goûts, du plus utile au plus futile :)L'installation d'un plugin est également très pratique : tout est contenu dans un répertoire, donc pour supprimer un plugin, il vous suffit de supprimer ce répertoire. Rien ne reste, pas de configuration orpheline, pas de fichiers temporaires, pas d'inclusion dans d'autres fichiers, etc. De plus, tout est faisable via l'interface web d'administration de Dokuwiki. Un autre avantage qui à été décisif pour l'adoption de Dokuwiki dans mon travail : ses très nombreux modes d'authentification. En effet, comme je vous l'ai dit, ce logiciel est tellement souple que la communauté à créé un grand nombre de modules d'authentification. Au programme, en plus des comptes locaux, vous pouvez vous identifier sur Dokuwiki via MySQL, LDAP, pgSQL, punbb, CAS, drupal, htaccess, radius, pam, shibboleth, imap, xmpp, etc. Vous pouvez coupler toutes ces authentifications, les utiliser séparément, et tout un tas d'autres méthodes. Pour la petite histoire, dans mon travail (DSI de l'Université Nancy 2), j'ai mis en place une authentification qui peut-être différente en fonction des fermes parmi CAS, comptes locaux, shibboleth, le tout couplés ou séparément. Bref, je pourrais m'étendre encore longtemps sur les vertus de ce moteur de wiki mais pour résumer, je peux dire qu'il s'agit d'une vraie mine d'or :) II. Qu'est-ce qu'une ferme de wikis ? Voici en l'arborescence simplifiée d'un répertoire Dokuwiki : |_conf (répertoire de configuration du wiki)|_data (contient les données du wiki comme les pages, les images, les documents joints, etc.)|_lib (contient les plugins, les templates du wiki)|_inc (contient les fichiers de langue, les modules d'authentification, etc.) Admettons que vous souhaitez héberger plusieurs wikis sur une machine (par exemple 24 wikis). Avec un système de wiki "classique", il faudrait 24 répertoires avec 24 répertoires conf, data, lib, inc, etc., il faudrait installer 24 fois les mêmes plugins, 24 fois les mêmes modules d'authentification et faire 24 mises à jour si besoin est.Bref, un vrai calvaire (surtout quand on dépasse les 50 wikis) ! Le principe des fermes est le suivant : Il y a un répertoire maître qui contient tous les modules, tous les plugins, tous les templates et après, pour chaque nouveau wiki, il y a un répertoire contenant un sous-répertoire conf (qui contiendra la configuration de chaque wiki) et un sous répertoire data (qui contiendra les données de chaque wiki). C'est tout. Chaque wiki (appelé aussi animal) ira chercher des modules, ses templates, ses librairies dans le répertoire maître. Au final, nous obtiendrons donc une arborescence de ce type : |_master  |_lib  |_inc|_wiki1  |_conf   |_data|_wiki2   |_conf   |_data|_wiki3   |_conf   |_data Plusieurs g[...]



PAL : Un agenda en ligne de commande toujours là pour vous

Mon, 21 Dec 2009 12:55:00 +0100

Pour tout ceux qui souhaitent avoir un agenda toujours à porté de main, voici un outil bien pratique qui fonctionne en ligne de commande. Vous aurez accès à un calendrier en moins de deux, avec vos événements de surplus ! Voyons tout cela de plus près ... Rédigé par Plonstic (que j'ai contacté suite à son commentaire, merci à lui !) Avant propos : Cet article contient quelques lignes de code. En tant qu'auteur j'ai pris soin de les vérifier sur mon système. Cependant, dans votre cas, il se peut que certains résultats ne soient pas ceux escomptés. De manière générale, il faut TOUJOURS vérifier les lignes de code que l'on vous fait exécuter (c'est la première faille des OS ;D). Les risques restent toutefois limités, car rien n'est fait en root ici. Toutes les actions peuvent être effectuées graphiquement (décompression d'archive, édition de fichiers, etc.). Pour des raisons "d'universalité" j'ai préféré présenter les lignes de commandes (de toute façon c'est un calendrier en ligne de commandes !) Bonne lecture... Présentation pal est un calendrier en ligne de commande qui affiche des événements à la manière de la commande cal des distributions UNIX, de gcal de GNU ou de calendar des distributions BSD. Les avantages : Un calendrier avec mise en évidence des jours auxquels sont associés un/des événements Organisation des événements par type et couleurs Recherche d'événements par expressions régulières Prise en charge des événements officiels (vacances, saints, journées historiques, etc.) Les événements peuvent être ponctuels ou répétitifs (quotidiens, hebdomadaire, mensuels, annuels) avec date de début et date de fin Ajout des événements en ligne (option -m ) ou en externe (éditions de fichiers) Exportation en HTML ou LATeX. Les inconvénients : Ne peut pas récupérer les événements sur internet N'est pas compatible vcal En ligne de commande (hum mais c'est l'intérêt ça, non ?!) Mais ça peut se faire avec des scripts (ce n'est pas expliqué ici). 1. Installation Pour les distributions Debian ou Ubuntu, on installera le paquet pal : sudo aptitude install pal Pour les autres, vous trouverez les sources ici. 2. Utilisation 2.1. Lancement pal se lance simplement avec pal 2.2. Édition Pour éditer les événements en ligne, on ajoutera l'option -m : pal -m Les flèches du clavier permettent de changer de jour. [a] pour ajouter un événement [e] pour entrer un descriptif [Suppr] pour supprimer un événement [q] pour quitter [h] pour l'aide sur les autres options d'édition 2.3. Recherche Pour rechercher un événement particulier on utilisera les option -s et -r : pal -s formule -r nbrjours où formule est une chaîne de caractères (ou une expression régulière) comprise dans la description de l'événement recherché dans les nbrjours prochains jours Example : Recherche le prochain jour le Pâques (en anglais ou en français) pal -r 365 -s "\(p.ques\)\|\(easter\)" Ou, plus simplement, si vous avez vos événements en français : pal -r 365 -s "pâques" 2.4. Exportation Pour exporter en HTML, on utilisera l'option --html cat >> mon_calendrier.html << EOF Mon calendrier généré depuis pal $(pal --html -c 12) EOF Note : l'option -c permet de spécifier le nombre de "lignes" (exemple) Pour exporter en LATeX, on utilisera l'option --latex pal --latex -c 12 > mon_cal.tex sed -i '5i\\\usepackage[latin1]{inputenc}' mon_cal.tex sed -i '5i\\\usepackage[francais]{babel}' mon_cal.tex sed -i 's/Monday/lundi/g' mon_cal.tex sed -i 's/Tuesday/mardi/g' mon_cal.tex sed -i 's/Wedne[...]



Dépôt Mercurial sur CentOs, Part 2 : Mercurial

Thu, 03 Dec 2009 07:24:00 +0100

Maintenant que nous avons un serveur sécurisé avec SSL (voir Dépôt Mercurial sur CentOs, Part 1), nous allons mettre en place le dépôt mercurial. La structure qui sera mise en place permettra la gestion de multiprojets. Installation de mercurial : Ici rien de plus simple étant donné que celui-ci est déjà packagé : yum install mercurial Pour afficher le numéro de version de Mercurial mais aussi vérifier que celui-ci fonctionne bien avant de continuer quoi que ce soit il vous faut taper: hg --version Il faut maintenant créer un dossier où les dépôt seront stockés : mkdir -p /srv/hg/cgi-bin Note: Libre à vous de le changer si celui-ci ne vous convient pas. Dans le répertoire cgi-bin nous allons y copier le cgi de mercurial : cp /usr/share/doc/mercurial-1.2/hgwebdir.cgi /srv/hg/cgi-bin/Note: Il existe deux cgi un pour la gestion de projet unique (hgweb) et un pour la gestions de plusieurs projets (hgwebdir). C'e sont ces scripts qui vont se charger de tout ! Il faut maintenant créer le fichier de configuration hgweb.config dans /srv/hg/cgi-bin/ et y ajouter ces deux lignes : [collections] /srv/hg = /srv/hg Voilà c'est à peu près tout pour la mise en place de Mercurial, reste la configuration d'Httpd. Configuration d'Httpd Il faut rajouter les éléments permettant d'indiquer l'emplacement du cgi de mercurial  dans /etc/httpd/conf.d/ssl.conf  Alias /hg /srv/hg/cgi-bin DirectoryIndex hgwebdir.cgi SetHandler cgi-scriptAllowOverride All Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all ErrorLog /var/log/httpd/hg.log Création d'un projet  Nous allons créer notre premier dépot dans /srv/hg/MonProjet et donner les droits d'écriture dans le dépôt à apache: sudo -u apache hg init /srv/hg/MonProjet Rendez-vous sur https://serveur/hg/hgwebdir.cgi où vous retrouverez votre projet ! Permettre le push  Avoir accès au dépôt ce n'est pas tout, il faut aussi pouvoir y écrire ! Pour celà il faut créer le fichier /srv/hg/MonProjet/.hg/hgrc et y mettre: [web]allow_push = * L'étoile donne accès à n'importe qui, il faudra changer celle-ci par les noms d'utilisateurs devant avoir accès au dépôt. Il serait malencontreux que tout le monde puisse envoyer des données sur le dépôt. Sécuriser le dépôt Il est intéressant et même indispensable de protéger son répertoire pour éviter d'avoir des ennuis. il faut tout d'abord commencer par créer un fichier qui contiendra les logins et password des personnes autorisées : htpasswd -c /etc/mercurial/htpasswd remi Note: Il est important de mettre le htpasswd en dehors des répertoires accessibles par les internautes. Note: le '-c' n'est à mettre que si le fichier n'existe pas (afin de le créer).  Pour rajouter un autre utilsateur à la liste il suffira de faire : htpasswd /etc/mercurial/htpasswd remi Il faut maintenant placer un fichier .htaccess dans /srv/hg/cgi-bin  : AuthUserFile /etc/mercurial/htpasswd AuthGroupFile /dev/nullAuthName "Identification"AuthType BasicRequire valid-user Désormais lors d'un push, un nom d'utilisateur et un mot de passe seront demandés ! Importation du dépot sur une machine de travail Maintenant que notre repository est opérationnel, il faut l'importer sur les machines de travail ! Cela se fait très simplement au travers de la commande : hg clone AdresseWebDuRepo RepertoireDeDestination Conclusion Et voilà, à vous les joies de Mercurial ! Améliorations Un point intéressant serait de modifier le chemin d'accès actuel (https://serveur/hg/hgwebdir.cgi/MonProjet) par quelques chose de plus propre comme : https://hg.serveur/MonProjet. N'ayant pas de certifs wildcard pour le moment pour mon domaine je ne l'ai pas encore fait. Cet article sera modi[...]



Création d'une webradio sous Ubuntu avec Amarok et Darkice

Fri, 31 Jul 2009 15:14:00 +0200

Pour le compte de mon activité en informatique libre INFORMALIBRE (http://www.informalibre.fr), j'ai travaillé sur la mise en place d'une solution de streaming depuis un PC sous Ubuntu.Ainsi vous pouvez écouter http://www.meltinpot.fr grâce à un PC sous Ubuntu 9.04. Voici comment j'ai fait : SOMMAIRE : Avertissement !Les pré-requisPrésentation de la solution de streamingInstallation et compilation de darkiceInstallation d'AMAROK 1.4Automatiser le lancement de darkice + faire des testsLe gestionnaire de tâche planifiéInstaller ICECAST2 Avertissement ! Les manipulations qui suivent nécessitent des manipulations à effectuer avec des droits superutilisateurs (root) dont le mauvais usage peut engendrer des effets néfastes pour votre système. Je ne suis donc pas responsable de vos erreurs. (j'ai repris ce texte d'avertissement très explicite sur le site de http://blog.profnoel.com/ )Les pré-requis Vous devez avoir ubuntu-restricted-extra et lame , pour ce faire cliquez sur ce lien : apt://ubuntu-restricted-extras,lamePrésentation de la solution de streaming La solution présenté ici a été retenu pour plusieurs raisons :AMAROK 1.14- Fiabilité lors d'une lecture de musique en continue alors que d'autres logiciels boguent au bout de quelques temps (par exemple exaile)- Meilleur qualité d'utilisation lors de l'ajout de musique dans des playlists par rapport à mpd et son frontend sonata par exemple. DARKICE- Programme qui envoi le son "streamé" (dans mon cas, depuis alsa)  vers un serveur shoutcast hébergé par streamakaci©- Possibilité d'envoyer le son vers un serveur icecast2 en simultané (pour un futur streaming en ogg vorbis).- Plus grande fiabilité que edcast-jackInstallation et compilation de Darkice Nous devons installer Darkice et Amarok 1.4, nous allons commencer par darkice !DARKICEPour des raisons liés au copyright sur le support du mp3, Darkice n'est pas compilé avec le format mp3 en standard.Nous devons donc le compiler nous même, mais comme il est dans les dépôts source nous pouvons faire ça très simplement en suivant ce tuto : http://doc.ubuntu-fr.org/projets/paquets/recompiler_un_logiciel_des_depots C'est parti pour la compilation de Darkice:Tout d'abord, il faut installer build-essential, dpkg-dev et fakeroot, un clic sur le lien suivant permet d'installer les paquets très facilement: apt://build-essential,dpkg-dev,fakeroot (d'autres méthodes existent : http://doc.ubuntu-fr.org/tutoriel/comment_installer_un_paquet). Bien attendre que tout soit installé et ne pas faire autre chose tant que vous n'avez pas cliqué sur OK (le système vous dit que tout à bien été installé, appuyer sur "Afficher le bureau", en bas à gauche pour voir si des fenêtres ne sont pas cachées).Ensuite lancez un terminal : Applications->Accessoires->Terminaltapez : apt-get source darkice (ce qui va installer les sources de darkice)Ensuite rendez-vous dans le répertoire de darkice puis dans le répertoire debiancd darkice-0.19 puis entrer, puis cd debian puis entrerUtilisez ensuite la commande suivante :gksudo gedit rules gksudo plutôt que sudo car nous lançons un logiciel gtk)Recherchez la ligne : dh_auto_configure -- --prefix=/usr --sysconfdir=/usr/share/doc/darkice/examples Et ajouter y ceci : --with-lameCela vous donnera cette ligne :dh_auto_configure -- --prefix=/usr --sysconfdir=/usr/share/doc/darkice/examples --with-lameEnregistrez rules et quittez gedit (vous devriez revenir au terminal)Ensuite dans votre console tapez : sudo apt-get build-dep darkice   (ainsi nous allons télécharger toutes les dépendances sources de darkice)Il devrait s'afficher ceci : Les NOUVEAUX paquets suivants seront installés : debhelper dpatch gettext html2text intltool-debian libasound2-dev libfaac-dev libjack-dev libjack0.100.0-dev  libmail-sendma[...]



Installer le greffon Separate+ pour Gimp en 64 bits

Wed, 24 Jun 2009 08:25:00 +0200

Bonjour, un rapide billet pour expliquer comment installer le greffon Separate+ pour Gimp 2.x sur un système 64 bits (la procédure est aussi valable pour un système 32 bits)

(image)

Hum, là j'entends des voix qui me disent : "C'est quoi ce truc ?"

Le greffon Separate+ permet la gestion de la quadrichromie dans Gimp avec l'espace de couleur CMJN utilisé par tous les imprimeurs. En attendant Gimp 3.0 qui supportera CMJN en natif, Separate+ nous sauve la vie à nous pauvres "graphistes" libristes "professionnels".

Le .deb fournit par le lien de la doc Ubuntu est en 32 bits, donc pas compatible avec ma Xubuntu 64 bits. Il reste donc la compile à la mano ^^ Comme une andouille j'ai cherché partout des infos sur la compile en 64 bits.... En faite, c'est automatique car ça compile par rapport au système. Logique, mais pas évident en état de stress (le CMJN est un besoin professionnel urgent !).

(image)

Separate+ rajoute une entrée dans le menu image. En bas, le menu Separate propose 4 options : Duetone (je ne l'ai pas utilisé et connais pas sont utiilité), separate qui permet d'obtenir une image en CMJN niveau de gris. Une fois cette image obtenu, l'option Proof permet d'avoir un aperçue du résultat imprimé avec simulation des encres imprimeur et l'option Save permet d'enregistrer l'image CMJN au format TIFF avec export d'un profil d'impression CMJN.

Notez que rien ne remplace le travail en CMJN dès le départ. Separate+ convertit en CMJN depuis du RVB, donc la qualité final sera forcément moins bonne que du CMJN natif.
Dans les logiciels Libre qui supporte le CMJN en natif nous avons Krita et Scribus par exemple.

Procédure :

  1. Téléchargement : téléchargez sur cette page la dernière version de Separate+ : http://cue.yellowmagic.info/softwares/separate.html
  2. Dé-zippage, puis avec un terminal placer vous dans le dossier dé-zippé.
  3. Installation des librairies utiles, pour moi ça a été : sudo apt-get install liblcms1-dev libtiff4-dev libgimp2.0-dev pkg-config build-essential fakeroot checkinstall
  4. Compilation : make
  5. Installation : sudo checkinstall (génération d'un .deb puis installation de celui-ci)
  6. Enjoy !

Sources :