Lotharedon

Blog

Derniers articles du blog


  • Lotharedon Sat, 19 Mar 2016 03:20:17 +0100
    Journal d'un apprenti-sorcier en Sciences Informatiques

    • Comment déceler une arnaque sur le web Sat, 19 Mar 2016 03:20:17 +0100
      Aujourd'hui, mon père m'a envoyé une jolie promotion pour obtenir un iPhone 6S à 1€. Comme ça fait longtemps que je n'ai rien écrit ici, je profite de l'occasion pour voir comment déceler facilement une arnaque.

      Histoire d'avoir un peu de matière pour comprendre les explications qui suivent, voici les liens qu'il m'a envoyé :
      Je ne mets ces liens (et les suivant) ici que pour vous permettre de suivre les explications. Je vous déconseille fortement de faire autre chose que de consulter le contenu pour comprendre cette article. Je décline toute responsabilité quant aux autres usages faits avec ces pages, à leurs conséquences, et aux éventuelles pertes d'argent survenant.


      Tout d'abord, regarder la forme du site.

      L'URL

      En apparence le site a l'air sérieux, avec les cours boursiers affichés. Cependant, la forme du début de l'url est bizarre (www.lanouvelles.fr.news-reports.net). Pourquoi le nom de domaine est "news-reports.net" ? Le site n'est pas "La nouvelles" à en croire le logo ? Pourquoi est-ce qu'on dirait 2 noms de domaines (lanouvelles.fr et news-reports.net) qui ont été collés ?


      Le site

      À présent, regardons un peu ce qu'est ce site. Si on clique sur le logo, on atterrit sur la page de la promo (https://www.walter-brand.com/offres/ECCBC87E/?ntw=14&aff=1306=&sub2=1451457694&sub3= ) qui est sur un site différent. Si on essaye d'aller en page d'accueil (www.lanouvelles.fr.news-reports.net), on tombe sur une page vide de contenu, ce qui est assez étrange pour ce qui semble être un site d'actualité.


      Le contenu de la page

      L'explication de la promo

      Là, rien de nouveau : une promo incroyable, un témoignage pour "prouver" le fonctionnement de la promo, en plus le "témoin" a déjà fait les recherches pour nous pour vérifier que c'était pas une arnaque, un contexte farfelu (les PdM d'Apple ont reculé de 35%) et probablement faux, une "conclusion" farfelue elle aussi (tactique courante des grosses entreprises : t'en connais beaucoup qui divise le revenu de leur produit phare par 799 quand elles vont mal ?). Et bien sûr, on en met des tonnes pour "prouver" que ce n'est pas une arnaque.


      Les détails manquant ou figés

      La section des commentaires mérite aussi un petit détour : tu auras beau recharger la page de temps en temps, le temps depuis la publication des commentaires ne changera pas.
      On note aussi l'absence de pied de page contenant les liens vers les mentions légales et les différentes sections du site.


      Le "distributeur"

      Bien que le témoin ait fait le boulot pour nous, on va quand même jeter un coup d'oeil au distributeur et sa page de promo.

      Le site

      Sur la page de promo, on constate qu'il y a très peu de liens, pas même vers la page d'accueil. Sur celle-ci, on notera le décalage complet entre les "services" proposés et sa qualité de distributeur de produits Apple. On notera également l'absence d'informations relative à la promo.


      Une recherche avec Google

      Faisons un tour sur google, pour voir si ils sont connus en tant que distributeur de produits Apple (mots clefs : walter brand apple). Les seuls liens en relation avec cette marque sont des liens parlant justement de la promotion, et rien d'autre. Les suggestions de recherches de google tournent également autour de ce sujet.


      Un peu de logique et de culture

      Le fait que Walter Brand soit présenté comme un des distributeurs européen d'Apple, y compris en France, est également suspect. Apple vend directement ses produits via des Apple Store, qui sont propriétés d'Apple. Même le stand Apple de la Fnac est un stand Apple Store. Les seuls cas où ce n'est pas Apple, ce sont soit de petits revendeurs (et encore, ce n'est pas autorisé par Apple, même sur Amazon seul Apple vend ses produits), de la contrebande, et de la contrefacon.


      Et enfin, un petit coup de technique

      Si on jette un coup d'oeil au whois du site (par exemple sur https://whois.net/), on voit que le nom de domaine (walter-brand.com) a été créé en janvier 2016 au Panama. L'autre nom de domaine, news-reports.net, a été créé en novembre 2015.


      Alors, promo ou arnaque ?
    • SailfishOS : impossible d'installer ou désinsaller un programme malgré de la place restante sur le mobile Sat, 09 Jan 2016 16:12:23 +0100
      SailFishOS est un OS de smartphone jeune et intéressant. Il est basé sur OpenSuse, Wayland, et son système de partitionnement est BTRFS. Cependant, parfois illui arrive d'avoir des bugs incompréhensibles. L'un d'entre se caractérise par l'impossibilité d'utiliser le store et de voir échouer les opérations exécutés par Warehouse avec un message disant "dismiss by user". La cause de tout ceci peut être un bug de BTRFS qui réparti mal les données etfait croire au système qu'il n'y a plus de place. Nous allons voir ici deux façon de le résoudre, et une façon simple de lesurveiller.

      Solution #1 : avec le mode développeur

      La première façon de réparer SailFishOS s'adresse aux gens ayant installé le mode développeur. Si ce n'est pas votre cas, passez à la section suivante ; avec ce bug, vous ne pouvez pas l'installer. Si vous y arrivez, c'est que vous n'êtes pas concerné par le contenu de cet article.
      Grâce au mode dévelopeur, nous pouvons accéder au super utilisateur soit directement dans l'appli Terminal, soit via SSH. Choisissez votre façon de vous y connecter, et une fois cela fait, tapez dans le terminal (en root) :
      btrfs fi show
      . Elle devrait vous afficher quelque chose du type :
      Label: 'sailfish'  uuid: 4b9a7c4f-83c2-49be-b2b7-6fe67cc12eae
              Total devices 1 FS bytes used 9.74GiB
              devid    1 size 13.75GiB used 13.31GiB path /dev/mmcblk0p28
      
      Btrfs v3.16
      Observez le dernier nombre indiqué : si il est proche de 13.75GB, alors vous avez un problème de répartition de données avec BTRFS (bug connu). Ici nous avons "13.31GB", nous sommes donc concerné par ce problème.
      Une autre façon de le vérifier est d'utiliser la commande
      btrfs-balancer allocation
      . Si la valeur retournée est supérieur ou égal à "13153337344" octets, c'est la cause de notre problème.
      Pour le régler, il faut utiliser la commande
      btrfs-balancer balance
      . Cependant il faut le faire en ayant la batterie bien chargé, voir en charge, et être patient, car cette commande peut avoir besoin de plusieurs heures pour s'exécuter.
      Cependant il est aussi possible delancer la même opération via une commande un peu différente qui permet de la segmenter en opérations plus courtes :
      btrfs balance start -dusage=XX /
      . Le paramètre dusage spécifie le pourcentage maximal de block occupées par els données à relocaliser. En gros, plus la valeur est basse, plus les fichiers à relocaliser seront forcéments petits, donc moins il y en aura, et plus rapide de sera à exécuter. Ainsi, on pourra exécuter en plusieurs fois :
      btrfs balance start -dusage=0 /
      btrfs balance start -dusage=5 /
      btrfs balance start -dusage=10 /
      btrfs balance start -dusage=25 /
      btrfs balance start -dusage=40 /
      Avec ces commandes on va commencer par relocaliser les fichiers de très petites tailles, puis utilisant moins de 5 % des blocks, etc, jusqu'à relocaliser les fichiers utilisant jusqu'à 40% des blocks. Cette façon de faire permet également de traiter plus rapidement les grosses partitions formatées en BTRFS.


      Solution #2 : sans le mode développeur.

      Cette solution est basiquement la même que la précédente, mais contourne l'absence du mode développeur. Pour cela, nous allons utiliser le mode Recovery du Jolla.

      1. Éteindre le smartphone
      2. Démarrer leJolla en maintenant enfoncé les touche "Power" et "Volume -"
      3. Connectez le Jolla en USB à l'ordinateur
      4. Préparez votre ordinateur à la connexion :
      • Si vous êtes sous GNU/Linux, activez la nouvelle interface (avec ifconfig)
      • Si vous êtes sous Windows, installez telnet et le pilote de RNDIS
      1. Connectez vous en telnet à l'adresse 10.42.66.66. De la, vous avez accès au recovery
      2. Le recovery vous propose plusieurs choix. Exécutez le shell (choix n°4)

      Nous voilà a présent dans le terminal de récupération du Jolla. Nous allons à présent préparer l'environnement de récupération :
      1. Créez un dossier /mnt/chroot (mkdir /mnt/chroot)
      2. Montez les partitions du Jolla de tel façon à pouvopir y lancer un chroot :
      mount /dev/mmcblk0p28 /mnt/chroot
      mount -o bind /proc /mnt/rootfs/proc
      mount -o bind /dev /mnt/rootfs/dev
      mount -o bind /sys /mnt/rootfs/sys
      1. Rentrez dans le chroot :
        chroot /mnt/chroot
        . Une fois dedans, on peut monter le homedir avec la commande "mount -t btrfs -o subvol=@home /dev/mmcblk0p28 /home".

      À présent, nous sommes dans l'environnement de SailFishOS, nous pouvons traiter notre problème. Tou d'abord, vérifions qu'on soit bien concerné par celui-ci avec les commandes
      btrfs fi show
      et
      btrfs-balancer allocation
      . Si il n'y a pratiquement pas de place disponible ou pour la seconde commande si la valeur retournée est supérieure ou égale à "13153337344" octets, malgré la présence de beaucoup de place libre sur la partition (visible via la commande df -h), alors il faut rééquilibrer la répartition de l'écriture des données via la commande
      btrfs balance start -dusage=XX /
      , comme indiqué dans la section précédente.


      Surveiller ce bug

      Pour éviter de se retrouver à nouveau au dépourvu dans cette situation, une application est disponible dans OpenRepos (accessible via Warehouse). Elle s'appelle "btrfs balance checker". Elle enverra une notification lorsqu'on se rapproche de l'état paralysant le système.
    • FDM : le Feline Display Manager, un fork de TDM Wed, 18 Nov 2015 22:50:06 +0100
      Aujourd'hui, je vais vour présenter rapidement un petit fork que j'ai fait d'un petit pratique pour ceux qui se connecte à leur ordi sous GNU/Linux à partir d'un TTY et non d'un gestionnaire de session. Il s'agit de FDM, le Feline Display Manager, qui est un gestionnaire de session en TTY.

      À quoi cela sert-il ? Et bien tout simplement à choisir la session à lancer lors d'une connexion en TTY. Il permet également de palier aux changements de la commande "xinit" qui ne permet plus, avec l'aide d'un fichier ~/.xinitrc, de facilement choisir la session X à lancer. Avec FDM vous aurez donc la possibilité de lancer à la connexion la session X de votre choix, mais aussi la session Wayland ou n'importe quoi d'autre (tel qu'une session bash, pour rester en TTY).

      Comment cela fonctionne-t-il ? Je vous invite à lire la page de mon Wiki correspondant ou le fichier README joint au projet. Son fonctionnement n'a rien de vraiment compliqué pour quelqu'un qui sait utiliser GNU/Linux via un terminal ;)

      Où est-il disponible ? Il est téléchargeable à partir du dépôt GitHub correspondant au projet. C'est également là-bas qu'il faudra signaler tout problème ou toute demande d'amélioration.

      Puis-je le modifier ? Bien sûr, c'est un logiciel libre sous licence GPLv3. D'ailleurs, tout les patchs sont les bienvenu :)

      Pourquoi avoir fait un tel projet ? Tout d'abord, j'ai pour habitude de démarrer mes GNU/Linux en TTY, et un programme de ce genre est quand même assez pratique. Ensuite, depuis que X ne fonctionnement plus en root mais en userland, le choix d'une session graphique via la commande xinit et un fichier ~/.xinitrc conçu à cet effet ne fonctionne plus. Pour palier à ce changement, j'avais décidé d'utiliser TDM. Cependant n'étant plus maintenu et ayant des limitations n'ayant plus de sens actuellement, j'ai décidé de le forker pour l'améliorer.

      Dépôt de TDM : https://code.google.com/p/t-display-manager
      Github de FDM : https://github.com/Astaoth/Feline-Display-Manager
      Documentation en français de FDM : http://lotharedon.org/wiki/index.php/FDM
    • GNU/Linux : Définir la résolution des tty avec l'option "nomodeset" (sans pilote chargé) Thu, 15 Oct 2015 14:32:12 +0200
      Depuis peu, grâce à l'usage de KMS, le kernel peut utiliser le pilote graphique pour afficher un bel écran de chargement et surtout définir la résolution de l'écran avant le chargement du serveur d'affichage (Xorg ou la famille Wayland) et de l'interface graphique. Cependant lorsqu'on utilise un pilote propriétaire, le pilote ne peut être chargé qu'au lancement du serveur d'affichage. Cela veut donc dire que grub et les tty s'afficheront dans une résolution minimale et standard. Cependant il est possible de spécifié à Grub une résolution différente. Pour cela, il faut modifier le fichier /etc/default/grub (en root) et y insérer :
      # Spécification de la résolution de l'écran attendue
      # Cette résolution doit être supportée par la carte graphique
      GRUB_GFXMODE=<résolution de l'écran>
      
      # Permettre au noyau de garder la même résolution que Grub
      GRUB_GFXPAYLOAD_LINUX=keep
      
      La résolution doit être notée sans guillemets.

      Ensuite il faut mettre à jour Grub via la commande "sudo update-grub", et au prochain démarrage la résolution utilisée devrait être différente.

      Source : http://ubuntuforums.org/showthread.php?t=2087827
    • Note de maintenance : Fin de transposition de Wiki Tue, 05 May 2015 14:14:18 +0200
      En mettant en place ce blog et ce wiki, j'avais pour but de transposer l'ancienne version de ce dernier, tournant sous DokuWiki, vers une nouvelle version plus soignée utilisant MediaWiki (comme Wikipedia). C'est à présent chose faite, le contenu de l'ancienne version est à présent intégralement présent dans la nouvelle version, disponible ici : http://lotharedon.org/wiki. Bonne lecture :)
    • Comparatif : quelle solution de Cloud pour remplacer DropBox ? Thu, 16 Apr 2015 12:45:53 +0200
      DropBox est un logiciel permettant de synchroniser des dossiers entre différents ordinateurs mais aussi avec un serveur extérieur, qui permet d'accéder à ses dossiers via une interface Web. Il se repose sur SVN, ce qui lui permet d'avoir un historique de version. Son modèle est de type client-serveur.

      Actuellement, il existe plusieurs solutions équivalentes à Dropbox que nous pouvons déployer sur notre serveur. Les principales alternatives sont Owncloud (sûrement le plus connu), Pydio (anciennement AjaxPlorer), Seafile, et Sparkleshare (repose sur Git). Seulement, parmi ces solution, laquelle choisir ? Laquelle correspondra le plus à mes usages ? Je vais donc ici comparer ces différentes solutions pour vous permettre de choisir plus facilement.

      Owncloud

      Sûrement le plus connu, son but est de permettre à tous de mettre en place son cloud personnel. Il offre de nombreuses fonctionnalités, dont la première et principale est la gestion de fichiers en ligne. Il peut gérer des fichiers locaux à des emplacements autres que son dossier, mais aussi des fichiers stockés sur des comptes Google Drive, Dropbox, Amazon S3, (S)FTP, OpenStack et WebDav. Il peut exploiter des bases de données MySQL, SQLite et PostgreSQL et fourni également un accès WebDav.
      À côté, il possède un système de greffons permettant d'ajouter de nouvelles applications. Ainsi il peut faire office de client RSS, de client de courriels, avoir des lecteurs audios et vidéos, visualiser des fichiers dans de très nombreux formats, gérer des carnets d'adresses et des calendriers en leur fournissant des accès CalDav et CardDav, et plein d'autres. Cependant après usage, mon sentiment est qu'il fait plein de choses, mais il ne les fait pas forcément correctement. Par exemple le client de courriels reste pauvre en fonctionnalité et de permet d'accéder qu'à un seul compte. Le client de flux RSS ne fonctionnera pas non plus avec tout les flux, et en particuliers ceux qui sont en https avec un certificat auto-signé ou de CACert.
      Au niveau de l'interface, elle est relativement clair et propre. Il faut quelques minutes pour la prendre en main, et ensuite tout sera accessible facilement. Les options sont facilement configurables et compréhensibles. En revanche, j'ai noté que sur un mobile cette interface n'était pas des plus pratique. Il vaudra mieux passer par un client. Je trouve également qu'au fur et à mesure des versions son interface s'alourdit et ralentit malgré les efforts des développeurs pour la rendre plus rapide.
      Il possède également des clients de Synchronisation pour Windows, GNU/Linux et Mac OS. Malgré des débuts difficiles, ces clients semblent fonctionner correctement pour synchoniser les données. Les clients Android et iOS sont également disponibles.
      Cette solution est programmé en php. Pour la déployer, il suffira de l'extraire dans un dossier géré par un serveur web etd'installer les quelques bibliothèques requises.
      En bonus, il est capable de se synchoniser avec d'autres instances d'Owncloud.


      Pydio

      Anciennement AjaxPlorer et propulsé par Red Hat, le but de ce projet est de permettre la gestion et la synchronisation de fichiers en ligne. Tout comme OwnCloud, il possède de nombreux plugins lui permettant d'accéder à des fichiers disponible dans différents type de stockage. Il peut exploiter les bases de données SQLite, MySQL et PostgreSQL. Il fourni également un accès WebDav.
      Son système de greffons lui permettra de gérer différents mécanismes d'authentifications et de nouvelles fonctionnalités en rapport avec la gestion de fichiers. En revanche il n'y aura pas de greffons permettant de gérer des calendriers en ligne ou des carnets d'adresses (par exemple). Du coup, la gestion des fichiers sera très bonne et très complète, avec de très nombreux éditeurs et visionneurs. Il sera également possible de créer des espace de fichiers partageables ou publics, et même de générer des mini-sites publics permettant un accès facile à un ensemble de fichiers.
      L'interface est assez différente de celle de Owncloud. L'ouverture d'un fichier se fera dans un onglet au sein de l'application, ce qui permettra d'éditer plusieurs fichiers en même temps. Sa configuration elle est quelque peut monstrueuse. En effet, de très nombreuses options sont disponible, et encore plus via les greffons. Chacun d'entre eux possède son interface de configuration. Cependant cette quantité d'option de configuration disponible permettra de paramétrer finement cette solution. Par exemple il sera possible de choisir les droits des fichiers nouvellement créés. Les thèmes peuvent proposer des versions mobiles, mais qui nécessiteront d'avoir un smartphone récent et d'avoir un user-agent reconnu par Pydio. Cependant je trouve que même celle-ci restera lourde, tout comme son interface principale.
      Il possède également des clients de synchronisations pour Windws, Mac OS X, GNU/Linux, et aussi Android et iOS.
      Tout comme Owncloud, cette solution est basé sur JavaScrip et PHP. Ainsi pour le déployer, il suffira de le placer dans un dossier géré par le serveur Web.


      Seafile

      Ce projet a pour but de proposer un équivalent de Dropbox facile à déployer, rapide, complet, et à attirer les entreprises via une version payante proposant du support. Ce projet pourra exploiter des bases de données SQLite et MySQL. Outre son accès Web et ses applis, il propose des accès à ses données en WebDav et via Fuse.
      Il ne possède pas de système de greffon officiel permettant d'ajouter des fonctionnalités supplémentaires. Cependant il est déjà très complet avec de nombreux outils de visionnage et un éditeur de texte.
      Son interface Web est légère et s'affiche correctement dans des navigateurs Web anciens sur des smartphones lents. En revanche ses options sont assez pauvres, le gros se faisant directement dans son fichier de configuration.
      Il possède des clients pour Windows, GNU/Linux, Mac OS X, Android et iOS, qui permettront de synchroniser les données ou d'explorer à distances les dossiers sans rien télécharger.
      Comme il repose sur Python, son déployement pourra se faire n'importe où. Cependant par défaut son interface Web est exécuté via un min-serveur Web inclu, il faudra donc lire son WIki pour l'associer à un Apache un Nginx déjà existant. Pour le démarrer, il ne suffit pas d'avoir un serveur Web activé, il faut également lancé ses exécutable. La création d'un démon à la main serait à envisager.


      Sparkleshare

      SparkleShare n'est qu'un client, qui a pour but d'exploiter n'importe quel dépôt Git de la même façon que Dropbox. Il accédera au dépôts distant de la même façon que les interfaces classiques de Git le font. Côté serveur, la seule chose requise est un serveur Git, et ses dépendances. Ainsi, si rien n'est prévu à côté, le seul accès possible aux données se fera via le serveur Git et rien d'autre.
      Ses clients existent pour GNU/Linux, Windows et Mac OS X, mais pas pour smartphones.
      Le principal intérêt de ce client est de pouvoir exploiter n'importe quel serveur Git pour en faire un équivalent de Dropbox. Ainsi, il sera possible d'exploiter des sites web tel que Bitbucket par exemplepour stocker ses documents en ligne et gratuitement.


      Le mot de la fin

      Chacune de ces solutions a des forces et des faiblesses l'associant à des usages différents.
      Si vous êtes un utilisateur lambda qui cherche à remplacer Dropbox facilement et sans devoir gérer un serveur, Sparkleshare est fait pour vous.
      Si vous souhaitez avoir votre cloud personnel, offrant des fonctionnalités variées (mais parfois incomplètes) tout en ne voulant déployer qu'une seule applis et sans trop se prendre la tête (du moins au début), il faudra s'orienter vers Owncloud.
      Si vous ne souhaitez gérer que des documents en ligne, avec plusieurs façon d'y accéder ou avec des clients mobiles, vous aurez le choix entre Pydio et Seafile. Le premier étant un peu plus simple à déployer, le second étant plus accessible.
    • Génération de nouveaux mots de passe en cas de perte des anciens pour des partitions LUKS. Sun, 15 Mar 2015 22:45:56 +0100
      Lors de l'installation d'une distribution GNU/Linux, il est souvent possible de choisir de créer des partitions chiffrées. Celles-ci seront impossible à lire sans posséder un des mots de passe configurés. Le standard utilisé pour le chiffrement est LUKS, et il permet d'avoir jusqu'à 8 mots de passe différent par partition. Seulement, lors de la perte de l'ensemble de ceux-ci, il devient alors impossible de lire les partitions chiffrées. Cependant, si elles sont toujours montées, il est possible de recréer de nouveaux mots de passe.


      Vérification des mots de passe

      Pour réaliser la vérification des mots de passe, il n'est pas utile de démonter les partitions chiffrées.

      Avant de créer de nouveaux mots de passe, il se peut que vous ayez une vague idée de l'un d'entre eux, que vous souhaitez vérifier. Pour cela, nous pouvons utiliser la commande "cryptsetup" :
      cryptsetup luksAddKey <chemin du volume chiffré>
      Le chemin du volume chiffré est celui de la partition physique et ouverte par LUKS, et non celui du périphérique monté par le système. Par exemple, dans le cas d'une partition physique et chiffrée "/dev/sda1", et d'une partition "/dev/dm-0" montée sur "/", dont LUKS a un mappage interne de "sda1" sur "dm-0", il faudra indiquer "/dev/sda1". Lors de l'appel de cette commande, "cryptsetup" va tout d'abord demander un mot de passe valide avant de permettre l'ajout d'un nouveau. Si le mot de passe est invalide, cette commade va nous le signaler.


      Mots de passe définitivement perdus

      Si la vérification s'avère infructueuse, il reste possible de créer un nouveau mot de passe, à condition que la partition soit montée et déchiffrée. Si ce n'est pas le cas, les données peuvent être considérées comme perdues.
      Pour cela, il faut tout d'abord trouver la correspondance entre les aprtitions physiques et les volumes LUKS, avant de pouvoir ajouter de nouveaux mots de passe en exploitant la clef maîtresse.


      Trouver les correspondances entre les partitions physiques et les volumes LUKS

      Lorsqu'on tape la commande "blkid", on peut voir les différentes partitions du système, leur étiquette, leur UUID et leur point de montage. Seulement les informations indiquées ne sont que celles vues par le système d'exploitation. Ainsi, par exemple, dans mon cas j'obtiens :
      /dev/block/8:2: UUID="8XXX6" TYPE="crypto_LUKS" 
      /dev/block/253:0: LABEL="Racine" UUID="1XXXX2" TYPE="xfs" 
      /dev/block/8:1: LABEL="Boot" UUID="9XXXXd" TYPE="ext2" 
      /dev/block/253:1: LABEL="Swap" UUID="6XXXXd" TYPE="swap" 
      /dev/block/8:3: UUID="9XXXX1" TYPE="crypto_LUKS" 
      /dev/sda3: UUID="9XXXX1" TYPE="crypto_LUKS" 
      /dev/sda2: UUID="8XXXX6" TYPE="crypto_LUKS" 
      /dev/dm-0: LABEL="Racine" UUID="1XXXX2" TYPE="xfs" 
      /dev/sda1: LABEL="Boot" UUID="9XXXXd" TYPE="ext2" 
      /dev/dm-1: LABEL="Swap" UUID="6XXXXd" TYPE="swap" 
      Les partitions physiques sont celles du types "/dev/sdaX" et les volumes LUKS sont ceeux du type "/dev/dm-X".

      À côté, parmi les outils fournis par LUKS, nous avont "dmsetup" qui peut fournir des informations sur notre table LUKS. Ainsi, pour avoir l'association entre les partitions physiques et LUKS, nous pouvons utiliser la commande "dmsetup info" :
      Name:              luks-9XXXX1
      State:             ACTIVE
      Read Ahead:        8192
      Tables present:    LIVE
      Open count:        2
      Event number:      0
      Major, minor:      253, 1
      Number of targets: 1
      UUID: CRYPT-LUKS1-9XXXX1-luks-9XXXX1
      
      Name:              luks-8XXXX6
      State:             ACTIVE
      Read Ahead:        8192
      Tables present:    LIVE
      Open count:        1
      Event number:      0
      Major, minor:      253, 0
      Number of targets: 1
      UUID: CRYPT-LUKS1-8XXXX6-luks-8XXXX6
      Ici, les lignes qui nous intéressent sont les lignes "Name", "Major, minor", et éventuellement "UUID". Seulement nous pouvons voir que les lignes "UUID" sont du type "CRYPT-LUKS-<uuid du volume>-<nom du volume disponible à la ligne "Name">". Or ici, la ligne "Name" contient déjà l'uuid du volume, donc la ligne "UUID" n'apporte rien de plus.

      Donc, en ne reprenant que les informations utiles, nous avons ici :
      Name:              luks-9XXXX1
      Major, minor:      253, 1
      
      Name:              luks-8XXXX6
      Major, minor:      253, 0
      
      Ces informations nous permettent déjà de faire le lien entre les partitions physiques et les volumes LUKS grâce aux volumes de "/dev/block". En effet, la ligne "Major, minor" indique un volume block qui n'est qu'un lien symbolique vers un volume chiffré, et l'uuid associé est celui d'une partition physique.
      Dans le cas où ces volumes block ne sont pas présents sur votre système, vous pouvez appeler la commande "dmsetup info" en lui précisant un volume chiffré. Ainsi "dmsetup info /dev/dm-0" nous retournera :
      Name:              luks-8XXXX6
      State:             ACTIVE
      Read Ahead:        8192
      Tables present:    LIVE
      Open count:        1
      Event number:      0
      Major, minor:      253, 0
      Number of targets: 1
      UUID: CRYPT-LUKS1-8XXXX6-luks-8XXXX6
      Nous avons ainsi l'uuid de la partition physique correspondante, qui est donc ici "/dev/sda2".

      Ce dernier raisonnement peut également être appliqué avec la commande "dmsetup table <volume chiffré>". Nous allons obtenir une série de valeur que nous pourrons comparer à la sortie de cette commande sans préciser de volume cette fois, qui affiche les mêmes informations pour l'ensemble des volumes, mais en y ajoutant également les noms qui contiennent les uuid.


      Création des nouveaux mots de passe

      À présent, nous avons donc l'association entre nos partitions physiques et les volumes lus par le système d'exploitation. Nous pouvons donc générer les nouveaux mots de passe à partir de la clef maîtresse.

      Chacun des volumes a une clef maîtresse qui permet de le déverouiller. Pour ceux qui sont lisibles, il est possible de récupérer cette clef grâce à la commande "dmsetup table --showkeys". Elle se trouve dans le cinquième champ au format décimal. Pour l'exploiter il faut la récupérer, mais également la convertir au format binaire. Pour cela, nous allons exploiter awk, mais aussi xxd pour la convertion, qui fait parti de l'installation de Vim. Ainsi la commande pour extraire la clef maîtresse de "dm-1" sera :
      dmsetup table --showkeys /dev/dm-1 | awk '{ print $5 }' | xxd -r -p

      Pour ajouter une nouvelle clef, nous allons utiliser la commande "cryptsetup luksAddKey" avec le paramètre "--master-key-file" qui va nous permettre de donner la clef maîtresse extraite grâce à la commande précédente. Au lieu de la copier-coller, nous allons tout simplement utiliser un pipe. Par exemple, cette commande appliqués à "sda3", qui est la partition correspondant à "dm-1" comme vu précédement, sera :
      cryptsetup luksAddKey /dev/sda3 --master-key-file <(dmsetup table --showkeys /dev/dm-1 | awk '{ print $5 }' | xxd -r -p)
      On y retrouve au début notre partition physique, et entre parenthèses le volume utilisé par le système d'exploitation.

      Une fois cela fait, nous pouvons vérifier la validité des mots de passe avec la méthode vu dans la section précédente.


      Sources

    • Fermeture de l'Ovi-Store Sat, 14 Mar 2015 11:50:39 +0100
      Hier a été un triste jour pour les possesseurs de smartphones Nokia. L'Ovi-Store a définitivement fermé ses portes, supprimant ainsi l'app-store officiels des smatphones Nokia sous Symbian, Maemo, et Meego. Cependant ces smartphoens restent utilisable sans, grâce à des alternatives mises en place par la communauté. À noter par contre que les chargeurs de cartes sont toujours opérationnels.


      Symbian S60

      Avec la fermeture de son market, Nokia a cependant prévu une alternative pour ne pas laisser les utilisateurs le bec dans l'eau. Il s'agit de l'Opera Store, qui propose des applis pour Symbian et J2ME, mais aupour Android, Blackberry, et autres. Cependant, seules figures les applis dont les développeurs ont demandé à faire la migration. Ainsi certaines applis ont été perdues si personne n'a fait de backup.

      Historiquement, Symbian n'a pas de market central, ce qui freina son développement. Nokia avait mis en place l'Ovi-Store pour enfin centraliser la vente d'applications aux pocesseurs de smartphones tournant sous Symbian. Cependant d'autres markets ont continués à se développer, fournissant ainsi de nombreuses alternatives.
      • Le "curated app store", allant de pair avec le "curated game store, qui propose une sélections d'applis propre et fonctionnelle. L'accès direct au téléchargement se fait par ici : http://www.allaboutsymbian.com/downloads/
      • AppListfourni un nouveau store avec une applli à installer, qui fonctionne comme l'ancien Ovi-Store. Cependant, l'appli est mal adapté à l'écran du Nokia E6.
      • Mobile 9 a un immense market assez ancien proposant tout et n'importe quoi, pour Symbian mais aussi Android et autres
      • Smartosworld un market propre mais plus mis à jour depuis mai 2014
      • Sis Mob propose quelques applis, toujours mis à jour
      • Un petit blo proposant quelques jeux spécifiquement adaptés au Nokia E6
      • Symtechsolution propose quelques jeux pour les anciens smartphones Nokia.


      Maemo 5

      Pour lui, la dispartion de l'Ovi-Store n'est pas un réel problème. La plupart de ses applis sont disponible dans des dépôts n'appartenant pas à Nokia, et la communauté a déjà dû faire face à la fin du support officiel du Nokia N900. Il existe donc de nombreuses sauvegardes de l'Ovi-Store pour le N900, et des dépôts de Nokia.


      Meego

      Le cas de Meego est plus délicat. Bien que fonctionnant de la même façon que Maemo 5 avec son système de dépôts, pour lui l'Ovi-Store était également bien intégré. Les dépôts ont donc pu être sécurisés, avec la création de l'OpenRepos qui propose les applis fournis par la communauté faites ces dernières années, mais en revanche il ne contient pas toutes les applis qui étaient dispo sur l'Ovi-Store. À ce jour, je n'ai toujours pas entendu parler d'une alternative ou d'une sauvegarde quelconque de ces applis. Cependant, il faut tout de même garder en tête que le Nokia N9 peut aussi faire tourner les applis développés pour SailFish OS. Il est donc loin de se retrouver démuni.
    • vdirsyncer : le caldav/carddav hors-ligne Tue, 24 Feb 2015 11:45:52 +0100
      Vdirsyncer est un outil défini par son auteur comme étant au Card/Cal/Dav ce qu'est l'imap hors-ligne aux courriels. C'est un client léger et simple qui permet de récupérer localement ses contacts CardDav sous forme de vcards, et ses calendriers au format iCal. Il peut synchroniser n'importe quel répertoire distant et n'importe quel répertoire local, sans contraintes. Il permet donc de facilement partager ses contacts et ses agendas entre différents serveurs Card/Cal/Dav.


      Installation

      Pour l'installer, le plus simple est de le faire avec "pip" (python installer packages). Pour faire ca proprement, on va l'installer dans un environnement virtuel. Comme ca, on pourra facilement le déplacer et le supprimer.
      Pour créer un environnement virtuel avec Python, il faut avoir installé le paquet python-virtualenv (à adapter selon votre distrubution). Ensuite, pour le créer, il suffit d'utiliser la commande "virtualenv <emplacement d'installation>". Par la suite, pour utiliser les programmes dans cet environnement, il suffira d'exécuter les binaires situés dans le dossier bin qu'il contient. Ensuite, en exécutant la commande "pip" contenu nous allons pouvoir installer vdirsyncer et ses dépendances. Parmi ses dépendances, certaines d'entre elles peuvent requérir gcc. Il faudra donc l'avoir installé au préalable. Voici la procédure complète pour installer vdirsyncer dans un environnement virtuel :

      #Création de l'environnement virtuel : 
      virtualenv ~/vdirsyncer_env/
      
      #On se déplace dans le dossier de binaires, pour plus de simplicité à l'appel des commandes : 
      cd ~/vdirsyncer_env/bin/
      
      #Installation de vdirsyncer et ses dépendances : 
      ./pip install vdirsyncer
      ./pip install atomicwrites
      ./pip install requests-toolbelt
      ./pip install icalendar
      
      #Requiert GCC, libxml-dev,  python-devel, libxslt-devel, libxslt-python
      ./pip install lxml
      
      Et voilà ! Il ne reste plus qu'à le configurer


      Configuration

      Le configuration est simple. Elle se passe soit dans "~/.vdirsyncer/config", soit dans "~/.config/vdirsyncer/config", soit dans le fichier indiqué par la variable d'environnement "$VDIRSYNCER_CONFIG".
      La seule partie obligatoire est la première section. Elle doit contenir :
      [general]
      status_path = ~/.config/vdirsyncer/status/
      # ou encore
      status_path = ~/.vdirsyncer/status/
      #ou un autre dossier, à choisir en fonction de votre configuration

      Ensuite, vient la configuration des pairs de dossiers à synchroniser. On y définit deux sources de stockages, locales ou distantes. On peut éventuellement aussi définir une résolution de conflit, et plusieurs collections de données, voir une éventuelle découverte automatique par rapport aux média indiqués. Voici la syntaxe :
      [pair <nom de la paire>]
      a = <premier média de la pair>
      b = <second média de la pair>
      
      #Éventuellement : 
      conflict_resolution = <pouvant être null | a wins | b wins>
      collections = <collections de données>
      
      Pour la résolution de conflit :
      • null : indique qu'un message d'erreur est affiché, mais rien n'est changé
      • a wins (respectivement "b") : indique que les données de "a" (respectivement "b") ont la prévalence sur celles de "b" (respectivement "a")

      Les collections sont soit un nom simple, soit une liste encadré par des crochets et séparée par des virgules des différentes collections disponible à synchroniser. Elles offrent un moyen plus simple de définir plusieurs calendriers ou agenda pour une source donnée sans devoir définir une nouvelle paire à chaque fois. Les noms sont entourrés de guillemets. Par exemple avec "collections = ["from b", "foo", "bar"]" vdirsyncer cherchera à synchroniser toutes les collections de "b", mais aussi "foo" et "bar".

      Et enfin vient la configuration des médias à synchroniser. Il en existe cinq, dont un en lecture seul. Ils permettent de définir un stockage CardDav, un stockage CalDav, un fichier (vcf ou ics en fonction du type) où stocker l'ensemble des données, un dossier dans lequel seront créés un fichier par élément, et un calendrier en ligne en lecture seul à partir d'un lien vers un fichier ics. Au lieu de faire la liste de l'ensemble des possibilités décrites dans la documentation officielle, je vais donner quelques exemples simples. Pour chacun des stockages présentés, d'autres options existent, que je vous invite à découvrir dans le documentation officielle, dont les liens se trouvent à la fin de cet article.

      • Stockage CalDav
      [storage <nom du stockage>]
      type = caldav
      url = <lien CalDav, recommandé en https en particulier si une authentification est requise>
      username = <si une authentification est requise, nom de l'utilisateur>
      password = <si une authentification est requise, mot de passe de l'utilisateur>
      verify = <définit si le certicifat SSL doit être validé, par défaut à "True". Dans le cas d'un certificat auto-signé, peut être le chemin vers celui-ci>
      

      • Stockage CardDav : ce sont basiquement les mêmes options
      [storage <nom du stockage>]
      type = carddav
      url = <lien CardDav, recommandé en https en particulier si une authentification est requise>
      username = <si une authentification est requise, nom de l'utilisateur>
      password = <si une authentification est requise, mot de passe de l'utilisateur>
      verify = <définit si le certicifat SSL doit être validé, par défaut à "True". Dans le cas d'un certificat auto-signé, peut être le chemin vers celui-ci>
      

      • Stockage local dans un dossier (par exemple, stockage des contacts dans des fichiers vcf)
      [storage <nom du stockage>]
      type = filesystem
      path = <chemin absolu vers le dossier qui contiendra les fichiers>
      fileext = <extension des fichiers à créer. Ce paramètre ne modifie pas le format du fichier, juste l'extension>
      
      De cette façon, des vcards sont tout le temps généré pour chacun des contacts, peu importe l'extension donnée.

      • Stockage local dans un seul fichier (par exemple, stockage calendrier dans un fichier ics)
      [storage <nom du stockage>]
      type = singlefile
      path = <chemin absolu vers le fichier qui contiendra les données. Son extension ne modifie pas le format du fichier.>
      De cette façon, un calendrier pourra être stocké au format ics (ou un répertoire au format vcf), peu importe l'extension du fichier indiqué.

      • Calendrier en lecture seul au format ics
      [storage <nom du stockage>]
      type = http
      url = <lien vers le fichier ics, recommandé en https en particulier si une authentification est requise>
      username = <si une authentification est requise, nom de l'utilisateur>
      password = <si une authentification est requise, mot de passe de l'utilisateur>
      verify = <définit si le certicifat SSL doit être validé, par défaut à "True". Dans le cas d'un certificat auto-signé, peut être le chemin vers celui-ci>


      Utilisation

      Son exécution est très simple : il n'y a que 3 commandes possible, avec éventuellement de la verbosité. Ces commandes sont :
      • discover : découvre les collections en fonction des paramètres indiqués dans la configuration des paires ; peut être suivi du nom des paires à traiter
      • sync : synchronise les données ; peut être suivi du nom des paires à traiter
      • repair : répare une collection donnée : doit être suivi du nom de la collection à traiter

      L'unique option possible est l'ajout de verbosité avec son niveau. Cette option est "-v <niveau de verbosité>. Les différents niveaux peut être CRITICAL, ERROR, WARNING, INFO ou DEBUG.


      Sources

    • Mise en place d'un serveur e-mail : installation du "webmail" Tue, 30 Dec 2014 23:51:56 +0100
      Comme vu dans un article précédent, j'ai jeté mon dévolu sur Sogo pour la partie webmail, qui apporte également une très bonne gestion Caldav et Carddav. Pour voir à quoi il ressemble, une démo est disponible ici. Bien qu'un guide d'installation soit disponible, Sogo ne propose pas d'étapes à suivre pour le faire fonctionner. Je vais tâcher de le faire ici, dans l'optique d'une utilisation avec peu d'utilisateurs. Pour une installation plus personnalisée, le guide d'installation indique toutes les options disponibles, leurs valeurs par défaut, et comment les utiliser.


      Installation

      Sogo propose des paquets pour les distributions GNU/Linux les plus populaires pour les serveurs. D'autres distributions peuvent également l'empaqueter.
      Ayant une CentOS 7, Sogo propose un dépôt spécialement pour ma distribution. Pour le faire fonctionner, il lui faudra également une base de données MySQL ou PostgreSQL, un serveur Web, et PHP. pour ma part, j'ai opté pour Apache que je connais bien, et MySQL, plus léger.

      Pour ceux qui ne l'ont pas dans leur gestionnaire de paquet, il reste la solution de la compilation manuelle. C'est plus long, mais au moins vous l'aurez. Il faudra également compiler Sope, qui permet à Sogo d'accéder à sa base de données.


      Compilation de Sope

      Tout d'abord, il vous faudra installer GNUStep, dont Sope dépend. Ensuite, il faut récupérer les sources de la dernière version stable ici.
      Une fois les sources extraites dans un répertoire de travail, commencez par "sourcer" le script "GNUstep.sh" ou GNUstep.csh" (en fonction de votre shell) afin de définir correctement les variables d'environnement requises. Une fois cela fait, pour lancer la compilation, il suffit de lancer ces commandes :
      ./configure --with-gnustep --enable-strip --disable-debug
      make
      sudo make install
      Pour des raisons de sécurité et éviter de risquer d'abîmer le système, il faut toujours compiler avec un utilisateur normal.

      Pour activer le mode de débuggage, la commande configure sera :
      ./configure --with-gnustep --disable-strip --enable-debug

      Et enfin, à partir de là, il faudra installer le mode Apache "mod_ngobjweb" pour lui permettre de faire suivre les requêtes Web vers Sope, et donc Sogo. Pour cela, à partir du dossier des sources, il faut aller dans le répertoire "sope-appserver/mod_ngobjweb" et suivre la procédure indiqué dans le fichier README.


      Compilation de Sogo

      Le procédure est globalement la même. Les sources se trouvent ici, et les commandes sont :
      ./configure --with-gnustep --enable-strip --disable-debug
      make
      sudo make install
      Une fois cela fait, Sogo sera installé dans le répertoire indiqué par la variable d'environnement "GNUSTEP_LOCAL_ROOT". Celle-ci est variable en fonction de votre distribution.

      Pour finir, si les dossiers "UI/WebServerRessources" et "UI/Templates" ne sont pas présents dans "$GNUSTEP_LOCAL_ROOT/Library/SOGo-0.9/", copiez-les dedans.

      À présent Sogo est installé, et vous pouvez supprimer les sources.


      Configuration

      Base de données

      Tout d'abord il faut créer un utilisateur et une base de données pour Sogo :
      create database sogo;
      grant all privileges on sogo.* to 'sogo'@'localhost' identified by '&lt;mot de passe&gt;'

      Dans le cas où vous ne voulez pas vous embêter avec un annuaire LDAP pour identifier vos utilisateurs, vous pouvez en créer dans la base de donnée de Sogo :

      Ensuite, connectez vous à votre base de données, créez la table qui contiendra les utilisateurs, et ajouter ceux que vous désirez :
      mysql -u sogo -D sogo -p
      MariaDB [sogo]> create table sogo_custom_users (
                             -> c_uid varchar(40) primary key, 
                             -> c_name varchar(40) not null, 
                             -> c_password varchar(140) not null, 
                             -> c_cn varchar(128), 
                             -> mail varchar(128));
      
      MariaDB [sogo]> insert into sogo_custom_users values (
                             -> '&lt;identifiat&gt;', 
                             -> '&lt;nom, peut être identique à l'identifiant"&gt;', 
                             -> '&lt;génération du hash à la volé du mot de passe&gt;', 
                             -> '&lt;nom courant&gt;', 
                             -> '&lt;adrese e-mail&gt;');
      
      L'identifiant et le mot de passe sont également exploités pour l'authentification IMAP. Les méthodes de hash et de stockage n'ont pas d'influence sur cet utilisation.
      Pour générer à la voler le hash du mot de passe, MySQL a plusieurs fonctions qui permettent de le calculer directement. Ces fonctions sont MD5('<mot_de_passe>'), SHA('<mot_de_passe>'), et SHA2('<mot de passe>',<algorithme>). Les algorithmes disponibles pour SHA2 sont 224 (SHA-224), 256 (SHA-256), 384 (SHA-384), et 512 (SHA-512).

      Et enfin, récupérez les diverses informations utiles à la configuration de Sogo :
      MariaDB [sogo]> show variables where Variable_name = 'port';
      +-------------------+--------+
      | Variable_name | Value |
      +-------------------+--------+
      | port                  | 3306  |
      +-------------------+--------+
      
      MariaDB [sogo]> select user();
      +--------------------+
      | user()                |
      +--------------------+
      | sogo@localhost |
      +--------------------+
      
      MariaDB [sogo]> select database();
      +--------------+
      | database() |
      +--------------+
      | sogo          |
      +--------------+
      
      À partir de ces informations, nous pouvons récupérer l'url de la base de données. Elle sera de type "mysql://<utilisateur SQL>:<mot de passe SQL>@<hôte>:<port>/<base de données>". Ainsi, dans notre cas et avec les options par défaut, ce sera : "mysql://sogo:<mot de passe>@localhost:3306/sogo". Cette URL nous servira pour la suite.


      Sogo

      La configuration de Sogo est effectuée dans le fichier "/etc/sogo/sogo.conf". Les valeurs par défaut de chacun des paramètres figures dans le guide d'installation. Certains paramètres sont déjà présents, en étant commentés, pour donner des exemples d'utilisation.
      Voici les paramètres indispensables pour concorder avec notre installation :

      • Configuration de la base de données :
      SOGoProfileURL = "&lt;URL de la base de données&gt;/sogo_user_profile"; //URL vers les profils d'utilisateurs
      OCSFolderInfoURL = "&lt;URL de la base de données&gt;/sogo_folder_info"; //URL vers la localisation des dossiers des utilisateurs
      OCSSessionsFolderURL = "&lt;URL de la base de données&gt;/sogo_sessions_folder"; //URL vers le stockage sécurisé des informations de sessions des utilisateurs

      • Configuration du système d'authentification. Cela se passe dans un tableau qui est également commun a l'authentification par LDAP :
      SOGoUserSources = (
        {
          type = sql;  //Peut être de type "ldap" ou "sql"
          id = directory;  //Honnêtement, je n'ai pas compris à quoi il sert. J'ai laissé la valeur par défaut proposé dans l'exemple de configuration
          viewURL = "&lt;URL de la base de données&gt;/sogo_custom_users";  //L'URL vers notre table contenant nos utilisateurs
          canAuthenticate = YES; //Si cette table permet d'authentificer des utilisateurs
          isAddressBook = YES;  //Si cette table peut être utilisé comme un carnet d'adresse partagé en lecture seule
          userPasswordAlgorithm = sha512; //l'algotirhme de hash utilisé
        }
      );
      

      • Le reste. Les différentes valeurs possibles sont indiquées dans le guide d'installation.
      SOGoSuperUsernames = (&ltutilisateur 1&gt;, &ltutilisateur 2&gt;);  //Liste des utilisateur ayant les privilèges administrateur
      SOGoMailDomain &lt;nom de domaine&gt;  //Nom de domaine par défaut, utilisé pour valider les adresses e-mails
      SOGoTimeZone Europe/Paris;  //Fuseau horaire
      SOGoLanguage French;
      

      Les autres paramètres dépendent entièrement de vos préférences ou peuvent être laissés avec leur valeurs par défaut.

      À présent, Sogo est complètement configuré et pourra se lancer. Il ne reste plus qu'à le rendre accessible via le web.


      Apache

      Installez, et vérifiez que les modules suivant soient bien activés dans la configuration de Apache : "proxy", "proxy_http", "headers" et "rewrite".
      Par défaut, la configuration de Sogo dans Apache, situé dans "/etc/<dossier de configuration de Apache>/conf.d/SOGo.conf", ajoute un dossier "/SOGo" pour chacun des sites activés. Pour changez ceci renommez "SOGo.conf" en "SOGo.conf.ori". Surtout ne le supprimez pas, il contient une configuration par défaut correct que nous pouvons reprendre ainsi que des exemples pour diverses options. Ensuite, dans le fichier d'hôte virtuel via lequel vous souhaitez rendre accessible Sogo, ou si vous n'en utilisez pas dans un nouveau fichier du dossier "conf.d", ajoutez ceci (basé sur le fichier "SOGo.conf.ori") :
      #UNIQUEMENT dans le cas d'un nouvel hôte virtuel dédié à Sogo : 
      DocumentRoot /usr/lib/GNUstep/SOGo/WebServerResources/
      
      #Pour tout le monde
      ##Les alias
      Alias /SOGo.woa/WebServerResources "/usr/lib64/GNUstep/SOGo/WebServerResources"
      Alias /SOGo/WebServerResources "/usr/lib64/GNUstep/SOGo/WebServerResources"                            	                                                                                                   
      
      ##Le dossier apache
      <Directory /usr/lib64/GNUstep/SOGo/>
          AllowOverride None
      
          <IfVersion < 2.4>
              Order deny,allow
              Allow from all
          </IfVersion>
          <IfVersion >= 2.4>
              Require all granted
          </IfVersion>
      
      # Explicitly allow caching of static content to avoid browser specific behavior.                                                                                                                       
      # A resource's URL MUST change in order to have the client load the new version.                                                                                                                       
          <IfModule expires_module>
              ExpiresActive On
              ExpiresDefault "access plus 1 year"
           </IfModule>
       </Directory>
      
      ##Le proxy pour accéder à Sogo
      ProxyRequests Off
      SetEnv proxy-nokeepalive 1
      ProxyPreserveHost On
      ProxyPass /SOGo http://127.0.0.1:20000/SOGo retry=0
      
      <Proxy http://127.0.0.1:20000/SOGo>
      ## À ajuster selon la configuration, ici paramétré pour un profile sécurisé couplé à du HTTPS
          RequestHeader set "x-webobjects-server-port" "443"
          RequestHeader set "x-webobjects-server-name" "lotharedon.org"
          RequestHeader set "x-webobjects-server-url" "https://lotharedon.org"
          RequestHeader unset "x-webobjects-remote-user"
          RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
      
          AddDefaultCharset UTF-8
      
          Order allow,deny
          Allow from all
      </Proxy>
      


      Voilà, à présent notre installation de Sogo est complète. Il ne nous reste plus qu'à lancer Sogo, à redémarrer Apache, et à la tester !


      Bonus

      • Adresse IMAP externes :
      Pour autoriser la relève des adresses IMAP externes, ajoutez cette ligne dans la configuration de Sogo :
      SOGoMailAuxiliaryUserAccountsEnabled = YES;

      • Ajout des filtres et de la gestion des absences prolongées :
      Il faut avoir installé Sieve sur le serveur. Une fois cela fait, les options de filtrages sont disponibles dans l'onglet "Courrier" des préférences, et un onglet "Absences prolongées" apparait également. Ce ne sont que des bêtes interfaces aux filtres Sieve.

    Wiki

    Dernières pages créées sur le Wiki


  • Lotharedon - Nouvelles pages [fr] Sat, 30 Jan 2016 14:12:02 GMT
    De Lotharedon

    • Recette: crêpes sucrées simples Sat, 30 Jan 2016 14:12:02 GMT

      Alucard : Page créée avec « == Ingrédients == Pour environ 8 petites crêpes / 1 personne : * 1 œuf * 65 g de farine * 125 ml de lait * environ 50 ml d'huile * 1 cuillère à café de sucre * 1 p... »


      == Ingrédients ==

      Pour environ 8 petites crêpes / 1 personne :
      * 1 œuf
      * 65 g de farine
      * 125 ml de lait
      * environ 50 ml d'huile
      * 1 cuillère à café de sucre
      * 1 pincée de sel

      Pour 4 personnes :
      * 4 œufs
      * 250 g de farine
      * 500 ml de lait
      * environ 100 ml d'huile
      * 2 cuillère à soupe de sucre
      * 1 pincée de sel


      == Préparation ==

      # Verser la farine, le sucre et le sel dans un grand récipient
      # Faire un cratère avec
      # Casser les œufs et les mettre dans ce cratère
      # Verser l'huile
      # Mélanger jusqu'à avoir une grosse pâte
      # Ajouter un peu de lait
      # Mélanger énergiquement pour ne pas avoir de grumeaux
      # Ajouter petit à petit le lait tout en continuant à mélanger
      # Huiler une poêle avec un sopalin imbibé d'huile
      # La mettre à chauffer sur un feu vif
      # Une fois la poêle chaude, verser suffisamment de la préparation de crêpe pour recouvrir tout le fond de la poêle sans que ce soit trop épais
      # Une fois que la crêpe ne semble plus liquide mais suffisamment solide pour pouvoir la soulever par un bord, la retourner
      # Dès qu'elle arrête de frémir, la retirer immédiatement du feu et la verser dans une assiette
      # Recommencer jusqu'à ce qu'il n'y ait plus de préparation de crêpe
    • Recette: émincé de poulet au miel Sat, 30 Jan 2016 13:48:39 GMT

      Alucard : Page créée avec « == Ingrédients == Pour une personne : * 1 escalope de poulet * 1 cuillère à soupe de sauce soja sucrée si possible * 1/2 cuillère à soupe de miel == Préparation =... »


      == Ingrédients ==

      Pour une personne :
      * 1 escalope de poulet
      * 1 cuillère à soupe de sauce soja sucrée si possible
      * 1/2 cuillère à soupe de miel

      == Préparation ==

      # Émincer le poulet
      # Mélanger le miel et la sauce soja
      # Verser de l'huile à cuisson dans une poêle et faire chauffer à vif
      # Mettre l'émincé de poulet dans la poêle
      # Verser le mélange sauce soja et miel dans la poêle
      # Laisser cuire
      # C'est prêt à servir :)
    • FDM Mon, 16 Nov 2015 15:33:50 GMT

      Alucard : /* Configuration globale */ Correction du rendu d'une définition


      Le Feline Display Manager est un fork de [https://code.google.com/p/t-display-manager TDM]. C'est un gestionnaire de session en TTY qui permet donc de choisir son interface à la connexion d'un compte en TTY, qu'elle soit graphique ou non.

      == Installation ==

      === Pré-requis ===

      * Ce logiciel s'appuie sur des commande spécifique au shell bash. Pour pouvoir l'utiliser bash est indispensable. Cependant il n'est pas nécessaire que ce soit le shell par défaut.
      * Pour l'installer, la commande "make" est requise.

      === Installation ===

      Pour récupérer la dernière version, à l'heure actuelle le plus simple est de la récupérer via GitHub ici : https://github.com/Astaoth/Feline-Display-Manager/releases .
      Une fois l'archive récupérée et extraite, modifiez éventuellement le préfixe du dossier d'installation pour choisir un répertoire d'installation a votre convenance. Un bon préfixe est le dossier <code>/usr/local</code>. Ensuite, il suffit de taper les commandes suivantes :
      <nowiki>make
      sudo make install
      make clean</nowiki>
      Et enfin, assurez vous d'avoir dans votre $PATH les commandes contenu dans le dossier <code>$PREFIX/bin/</code>. Si ce n'est pas le cas, vous pouvez soit ajouter directement ce dossier au $PATH, soit créer des liens de ces exécutables vers un dossier du $PATH.

      === Désinstallation ===

      Pour le désinstaller, le plus simple est d'avoir conservé le Makefile utilisé lors de l'installation. Il suffira alors de taper la commande <code>make uninstall</code>, avec le bon préfixe configuré.
      Si vous n'avez plus le Makefile alors deux situations se présentent : soit FDM est installé dans un dossier utilisé par d'autres éléments du système (tel que <code>/usr/local</code>), soit dans un dossier qui lui est propre.
      * Dans le premier cas, voici l'arborescence des fichiers à supprimer :
      $PREFIX/bin/fdm
      $PREFIX/bin/fdmctl
      $PREFIX/bin/fdm_core
      $PREFIX/etc/fdm.cfg
      $PREFIX/share/fdm/
      * Dans le second cas, il suffira de supprimer le dossier contenant FDM.

      == Utilisation et configuration ==

      === Utilisation ===

      Pour pouvoir l'utiliser, il faut ajouter la commande <code>fdm</code> à la fin du fichier de configuration du shell utilisés lors d'une connexion d'un utilisateur.
      * Pour bash : ce fichier est <code>~/.bash_profile</code> pour un utilisateur, ou <code>/etc/profile</code> pour l'ensemble des utilisateurs du système. Il ne faut pas le faire dans le fichier <code>~/.bashrc</code> ou <code>/etc/bash.bashrc</code>, sinon il s'affichera à chaque lancement d'un terminal.
      * Pour zsh : ce fichier est <code>~/.zlogin</code> pour un utilisateur, ou <code>/etc/zsh/zprofile</code> pour l'ensemble des utilisateurs du système (<code>/etc/profile</code> peut également fonctionner).

      Une fois cela fait, il sera lancé à chaque connexion d'un utilisateur à partir d'un tty.

      === Configuration globale ===

      La configuration global est effectuée via le fichier <code>$PREFIX/etc/fdm.cfg</code>. Voici les options disponibles :
      ;PREFIX
      : Le préfixe du dossier d'installation, utilisé lors de l'installation de FDM. Cette variable ne devrait pas être modifiée par l'utilisateur, sauf si il choisit de déplacer FDM dans un autre dossier.
      ;VERSION
      : La version actuelle de FDM
      ;UI
      : L'interface de FDM à utiliser :
      :* "text" : FDM sera lancé en mode texte
      :* "ncurses" : FDM sera lancé en mode ncurses
      ;CONFDIR
      : Le chemin du dossier stockant la configuration utilisateur.
      ;CACHEDIR
      : Le chemin du dossier de cache de l'utilisateur.
      ;X
      : Le chemin du dossier stockant les sessions X de l'utilisateur.
      ;WAYLAND
      : Le chemin du dossier stockant les sessions Wayland de l'utilisateur.
      ;EXTRA
      : Le chemin du dossier stockant les sessions qui ne sont ni X, ni Wayland, de l'utilisateur.
      ;DEFAULT
      : La session par défaut à utiliser.
      ;SAVELAST
      : Si "1", la session par défaut est la dernière session utilisée et qui n'est pas une session stockée dans le dossier EXTRA.
      ;AUTOSTART
      : Lance la session par défaut sans afficher FDM.

      === Configuration par utilisateur ===

      La configuration d'un utilisateur est stockée dans le dossier <code>~/.config/fdm</code>. Dedans, on y trouvera :
      ;<code>fdminit</code>
      : Ce fichier contient l'ensemble des commandes à exécuter lors du lancement de FDM.
      ;<code>fdmexit</code>
      : Ce fichier contient l'ensemble des commandes à exécuter à la fin de l'exécution de FDM, et donc juste avant le lancement de l'interface choisie.
      ;Les dossiers <code>X</code>, <code>Wayland</code> et <code>extra</code>
      : Ces dossiers contiendront les liens vers les interfaces à proposer lors de l'exécution de FDM. La liste des interfaces possible peut être modifiée simplement via la commande <code>fdmctl</code>.
      ;le lien symbolique <code>./default</code>
      : Ce lien pointe vers l'interface par défaut. Cette interface est soit choisie par l'utilisateur, soit correspond à la dernière interface lancé qui ne soit pas de type "Extra". Ce comportement se configure via le fichier <code>$PREFIX/etc/fdm.cfg</code>. L'interface par défaut peut être modifiée via la commande fdmctl.
      ;Le dossier <code>cache</code>
      : Ce dossier contient les sessions désactivées via la commande fdmctl.

      == fdmctl ==

      "fdmctl" est une commande permettant de modifier un certain nombre de paramètres propre à l'utilisateur simplement. Voici les commandes possibles :
      ;fdmctl init
      : initialise le dossier de configuration
      ;fdmctl list
      : liste l'ensemble des sessions disponible
      ;fdmctl cache
      : liste les sessions du dossier "cache"
      ;fdmctl check <session>
      : voir à quoi correspond la session donnée
      ;fdmctl default [session]
      : permet de voir et de définir la session par défaut
      ;fdmctl add <name> <path> [x(default) | w[ayland] | e[xtra]]
      : ajouter une nouvelle session
      ;fdmctl enable/disable <session>
      : activer ou désactiver une session