11.03.08
Posted in Debian, Ubuntu, planet-libre.org at 5:58 pm by michauko
Moi qui croyait n’être embetté que sous Windows par ces histoires de limitations de taille de fichiers, de disques, de partitions etc, je viens de m’en prendre une en pleine tête : formatter une grappe RAID5 de 6*500 Go (SATA), volume utile 2.5 To.
Je n’avais pas trop fait attention à l’installation de la Debian, mais j’ai loupé une question cruciale par méconnaissance : le type de table de partition.
Tout cela est expliqué et difficile à suivre sur wikipedia. Moi j’en retiendrai juste le résultat pratique.
Eviter le problème à l’installation…
Au tout premier accès au disque “virtuel” ainsi créé, je me souviens que le programme d’installation m’a demandé ça :
Ca n’arrive que sur des disques jamais initialisés (comme des grappes RAID) ou des disques virtuels. Peut-être aussi des disques sortis d’usine sans aucun pré-traitement, je ne sais pas.
Par défaut, c’était GPT. J’ai pas trop réfléchi, j’ai mis msdos car j’avais déjà eu ce cas (sur un disque virtuel de petite taille, type machine VirtualBox pour faire joujou). En fait, la proposition par défaut doit être la bonne. Car impossible de formatter au delà de 300 Go ensuite (pourquoi 300 ?)
Si comme moi, vous avez râté cette étape, voici ci-dessous comment corriger.
…ou le corriger après coup
FDISK ne dit trop rien à la création des partitions, masi il crée une partition de moindre taille.
CFDISK est à peine plus bavard. En l’utilisant en console (et non pas à distance), j’ai vu passer des messages d’erreur, notamment :
Very big device. Trying to use READ CAPACITY(16)
De là, Google m’a expliqué le problème et il a fallu le rectifier en changeant ce type de table de partitions. Vous pourrez alors adresser tout l’espace physique de votre disque et le formatter.
Corrigez en utilisant l’outil PARTED :
[root@toto: ~]$ parted /dev/sdb
GNU Parted 1.7.1
Using /dev/sdb
Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) mklabel gpt
(parted) mkpart
Partition name? []? MON_GROS_HD
File system type? [ext2]? ext3
Start? 0
End? -1
(parted) p
Disk /dev/sdb: 2500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 2500GB 2500GB MON_GROS_HD
(parted) quit
[root@toto: ~]$ fdisk -l /dev/sdb
Disk /dev/sdb: 2499.9 GB, 2499946741760 bytes
255 heads, 63 sectors/track, 303934 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 267350 2147483647+ ee EFI GPT
[root@toto: ~]$ mkfs.ext3 /dev/sdb1
mke2fs 1.40-WIP (14-Nov-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
305184768 inodes, 610338551 blocks
30516927 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
18627 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 35 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Et voilà le travail.
Au fait : ext3 semble être limité à 8 To. S’il y a quelques années 8 To paraissaient être une limite lointaine, actuellement, c’est moins évident. Il faudra alors passer en XFS ou ReiserFS (OK, j’évite les blagues de mauvais goût)
Permalink
10.14.08
Posted in Debian, Ubuntu, planet-libre.org at 3:30 pm by michauko
Raaah, je me trainais ce truc là depuis longtemps ; pourtant je sais parfaitement que le FTP est un de ces protocoles un peu pourris vis-à-vis des firewalls (et proxies), mais j’avais jamais rien fait pour m’arranger la situation.
Bref, l’occasion de faire un rappel - je passe la théorie car je donnerais dans l’à peu près, mais j’explique l’aspect pratique pour régler le problème titre de cet article.
Lorsque vous avez des problèmes de mode passif, actif etc en FTP, pensez à ceci.
Si quelqu’un veut poster en commentaire la théorie expliquant le problème, n’hésitez pas. Il me semble me rappeler des histoires de trames FTP contenant les IP émettrices et donc nécessité d’avoir des modules de masquerading particulier pour bien gérer le FTP… un vague résidu de cours de réseau 
La configuration
J’ai un serveur avec :
un FTP - restreints à certaines IP, rappelez-vous que FTP n’est pas du tout sûr (mot de passe en clair) et qu’il vaut mieux privilégier SFTP (du FTP par dessus SSH),
un shorewall ouvrant les ports 20 et 21
Bref que du bonheur en apparence.
Le problème
Malgré ça, je galère toujours d’un client FTP à l’autre. Le dernier en date : ncftp pour des échanges depuis un LAN vers ce serveur public. Ca se traduit par un cafouilli général dans les modes passifs etc.
Et un message d’erreur que pour une fois, j’ai relu lentement et me suis rappelé le coup du NAT spécifique FTP :
Falling back to PORT instead of PASV mode
En soit, je me foutais de savoir comment le client FTP établissait sa connexion, car dans tous les cas ça marchait, ça restait sécurisé dans la limite de ce que je demandais, mais c’était surtout que la complétion de nom, style cd rep TAB-TAB-TAB mettait 20 secondes à répondre le temps de passer en mode “PORT” justement. Soit environ 19,8 secondes de trop.
Comment on le règle ?
On pense à activer le NAT spécifique au protocole FTP, dans netfilter. Pour ce faire, par exemple via l’outil modconf (ou sudo modconf chez Ubuntu) afin d’activer ces 2 modules :
./kernel/net/netfilter/nf_conntrack_ftp.ko
./kernel/net/ipv4/netfilter/nf_nat_ftp.ko
Point besoin de rebooter, rien.
Voilà, un protocole FTP mieux géré par firewall netfilter sur votre serveur.
Excusez-moi pour l”à peu près technique concernant cet article. FTP ça me gave, c’est un sac d’ennuis ce truc. Mais c’est pratique.
Permalink
10.09.08
Posted in Coup de coeur, Debian, planet-libre.org at 5:09 pm by michauko
Wordpress est un outil de blog (un CMS diront certains) que je trouve assez sympa. Son premier but est de pouvoir publier facilement un blog, c’est-à-dire publier du contenu. Il n’est cependant pas trop prévu pour publier du contenu à accès restreint.
Dans les dernières versions, on voit des options pour protéger par mot de passe un article (ou une page). Mais ça s’arrête là, mais ça peut suffire dans bien des cas.
J’avais besoin de monter un site rapidement avec quelques pages statiques et des news, facilement éditables. Wordpress convenait donc, mais dans un contexte entreprise, il fallait priver l’intégralité de l’accès.
En cherchant un peu, on trouve donc 2 plug-ins parfaits pour ça.
Voici ce retour d’expérience : installer Wordpress avec authentification LDAP et contenu complètement privé (members-only).
Installation
Je suis parti sur une version SVN (la 2.6.2) car elle permet d’utiliser des plug-ins récents, qui ne fonctionnent pas pour ma version “stable” Debian (2.0.x). J’ai donc tout fait à la main, je vous résume ceci.
Préparation de la base MySQL
En console mysql, vous taperez par exemple :
CREATE DATABASE wordpress;
CREATE USER ‘wpadmin’@’localhost’ IDENTIFIED BY ‘mon_passwd’;
GRANT ALL ON wordpress.* TO ‘wpadmin’@’localhost’;
Ceci vous crée la base vide et un utilisateur d’administration.
Installation et configuration de l’application
Je schématise, côté OS et téléchargement de l’application :
mkdir /srv/www/wordpress
cd /srv/www/wordpress
svn co http://svn.automattic.com/wordpress/trunk/
Vous éditerez alors votre fichier /srv/www/wordpress/trunk/wp-config.php pour y renseigner au moins les champs suivants :
define(’DB_NAME’, ‘wordpress’);
define(’DB_USER’, ‘wpadmin’);
define(’DB_PASSWORD’, ‘mon_passwd’);
define(’DB_HOST’, ‘localhost’);
Vous ajouterez la conf Apache qui va bien (VirtualHost ou non), avec au moins ceci :
< Directory> # sans l’espace
Options FollowSymLinks
AllowOverride Limit Options FileInfo
DirectoryIndex index.php
< /Directory> # sans l’espace
Du classique, je ne détaille pas trop, je me concentre sur Wordpress, pas Apache2.
Lancement de l’installeur
Ensuite, vous irez sur http://votre_site/votre_blog/wp-admin/install.php pour lancer l’installation en 2/3 clics.
Vous voilà avec un wordpress tout vide et opérationnel.
Je passe sur le tour du propriétaire, j’enchaîne directement sur le choix et l’installation des plug-ins qui vont bien.
Les plug-in LDAP
Il y en a plusieurs, plus ou moins suivi, plus ou moins compatibles avec votre version de Wordpress. J’ai trouvé sur le site notamment celui-ci (wpDirAuth) compatible avec plein de LDAP, notamment OpenLDAP.
Après 2 heures de galère, on apprend que la version officielle sur ce site (1.2) n’est pas compatible avec Wordpress 2.6+.
Vous utiliserez donc la version 1.3 disponible ici.
L’installation est classique, en gros :
cd /srv/www/wordpress/trunk/wp-content/plugins
wget http://www.royal.wednet.edu/~ayearout/wpDirAuth-1.3.zip
unzip wpDirAuth-1.3.zip
Puis activation du plugin dans l’interface d’administration de WordPress. Classique. Son paramétrage ressemble à ceci, très complet :
Plug-in “members-only”
Enfin, ce plug-in permet de faire en sorte qu’il faille être connecté pour accéder au moindre contenu. Par défaut, vous êtes donc redirigé vers la page d’authentification.
![plug-in \"members-only\" pour Wordpress](http://michauko.org/blog/wp-content/uploads/2008/10/20081009_165503-300x296.png "plug-in \\"members-only\\" pour Wordpress")
Et voilà le travail
Permalink
Posted in Debian at 9:18 am by michauko
Tiens, on dirait que ça accélère… mes mails ce matin :
Bon, va falloir que je remette à jour ma doc, moi…
Permalink
10.03.08
Posted in Debian, planet-libre.org at 4:45 pm by michauko
Salut,
J’ai eu à déplacer l’outil sympa - très bien pour gérer des mailings-lists avec modération - d’un serveur à un autre.
L’outil était sur le backend de mail, avec la conf apache de sympa, la base de données de sympa et évidemment les binaires (le package sympa).
Le but était de déplacer la partie binaire, apache et base de données ; en conservant les boîtes mails et alias sur le backend de départ.
Je vous livre un petit retour d’expérience car c’est un poil plus compliqué que de déplacer une application LAMP classique.
Je partais d’une version Debian/stable, donc package sympa 5.2.3-1.2+etch1 et la cible était la même.
Je considère que vous avez déjà un Apache2 et MySQL sur la machine cible - et une machine cible capable de relayer des mails (recevoir et envoyer) sur postfix
La migration classique
La base reste la même :
1) Sur la machine cible, installez l’application - même version évidemment, packagée.
2) Reprenez (à la main ou en écrasant) la conf /etc/apache2/conf.d/sympa d’un serveur à l’autre
3) Reprenez ou adaptez /etc/sympa
4) Exportez/importez la base de données “sympa”, comme une brute, par exemple :
machine_depart:$> mysqldump -u votre_user_qui_va_bien -p -B sympa > migr_sympa.sql
puis
machine_cible:$> mysql -u user -p < migr_sympa.sql
5) Assurez-vous d’avoir les bons identifiants de login de l’application sympa dans les tables “mysql” de Mysql (= les tables du schéma mysql. Pigé ? il doit y avoir notamment une ligne dans la table mysql.user concernant le User sympa) :
use mysql ; SELECT * from user where User = ’sympa’;
La partie spécifique “sympa”
Ce qui est ci-dessus est ce que vous auriez à faire avec une appli LAMP typique qui stocke tout en base.
Manque de chance, sympa - au moins dans la version 5.2 (actuellement 5.4 dispo, pas essayé) - stocke tout un tas d’informations dans /var/lib/sympa, /usr/lib/sympa etc. Sans compter les alias mails qui permettent de transmettre les mails aux processus de gestion de sympa.
Donc il vous reste à faire :
La redirection des alias mail
Normalement, sur votre serveur de départ, vous devriez avoir tout un tas d’alias de mail dans /etc/aliases, genre :
sympa: “| /usr/lib/sympa/bin/queue sympa”
listmaster: “| /usr/lib/sympa/bin/queue listmaster”
sympa-request: postmaster
sympa-owner: postmaster
maliste1: “| /usr/lib/sympa/bin/queue maliste1″
maliste1-request: “| /usr/lib/sympa/bin/queue maliste1-request”
maliste1-owner: “| /usr/lib/sympa/bin/bouncequeue maliste1″
maliste2…..
Il faut reprendre cette configuration telle quelle sur la machine cible et s’assurer sur la première - qui reste la machine de backend de mail (mon MX en gros), donc celle qui reçoit le mail - qu’elle sache faire suivre tout ça à la machine cible qui est devenue celle qui gère sympa.
Donc dans la machine de départ, vous trafiquerez tout de la sorte :
sympa: “sympa@machinecible.com”
listmaster: “listmaster@machinecible.com”
sympa-request: postmaster (j’ai laissé tel quel, c’est un choix)
sympa-owner: postmaster (j’ai laissé tel quel, c’est un choix)
maliste1: “maliste1@machinecible.com”
maliste1-request: “maliste1-request@machinecible.com”
maliste1-owner: “maliste1-owner@machinecible.com”
maliste2…..
A la recherche du bordel éparpillé partout
Ensuite, je m’étais arrêté là - ahahah, erreur.
Sur l’interface web (la nouvelle), je ne voyais plus mes listes. La raison est que “sympa” stocke les listes, les archives etc hors de la base, dans des répertoires comme /usr/lib/sympa et /var/lib/sympa.
Donc, il faut reprendre tout ça sur la machine cible (des bêtes “tar” avec conservation des permissions suffisent).
Finalement, j’ai opté pour un joli :
dpkg -L sympa | less
De là, je suis passé dans tous les répertoires nommés (sauf les doc, le “man” etc - faut pas pousser) et je me suis assuré qu’il n’y ait pas de différence - attention à certains droits en setuid/setgid au nom de “sympa:sympa”.
Ensuite, vous envoyez la purée auprès de vos utilisateurs pour leur indiquer que le système est à nouveau dispo, sur une liste modérée tant qu’à faire, afin de bien faire tous les tests.
Si rien n’arrive, c’est pas grave, vous avez raté un truc.
Si vous recevez la demande de modération, c’est que ça semble bien parti
Le nettoyage
Lorsque vous ferez le DROP DATABASE sympa sur l’ancienne machine et le aptitude purge sympa, ça vous confirmera ce que je vous racontais sur le stockage des archives, des listes etc :
Permalink
09.23.08
Posted in Debian, planet-libre.org at 5:10 pm by michauko
Salut,
Il arrive qu’on ait besoin d’une application en “testing” sur un serveur en “stable”. Par exemple OCSInventory-NG. Il y a la bonne et la mauvaise méthode pour faire ça.
La mauvaise méthode (rapide, mais naze sur le long terme)
La méthode bourrin consiste à ajouter momentanément les lignes qui vont bien dans /etc/apt/sources.list, faire un apt-get update, l’installer et enlever les dépôts ensuite.
Ca marche mais on ne profite pas des mises à jour qui peuvent être importantes. Je dis ça car ensuite il vaut mieux enlever ces lignes qui risquent de vous faire migrer une partie de vos applis de “stable” à “testing” (si des fois vous êtes aveugles lors de votre “upgrade” régulier).
A ce propos, il ne faut pas oublier d’ajouter les lignes concernant le dépôt de sécurité.
Exemple, j’ajoute les lignes “lenny” pour donner ça :
deb ftp://ftp2.fr.debian.org/debian/ etch main contrib non-free
deb ftp://ftp2.fr.debian.org/debian/ lenny main contrib non-free
deb http://security.debian.org/ etch/updates main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free
La bonne méthode (presque aussi rapide)
La méthode propre consiste à garder tout le temps les lignes concernant les 2 (4) dépôts, mais à indiquer à APT le niveau de release que l’on veut conserver par défaut. Pour ce faire, créer un fichier du genre 00release dans /etc/apt/apt.conf.d/. Exemple :
# cat /etc/apt/apt.conf.d/00Release
APT::Default-Release “stable”;
Soyez prudent les 2/3 premières fois où vous mettrez à jour vos dépôts + upgrade. Histoire d’être sûr.
Le bug qui en découle
Souvent, l’effet de bord sera ça à votre prochain “apt-get update” :
Fetched 14.6MB in 50s (292kB/s)
Reading package lists… Error!
E: Dynamic MMap ran out of room
E: Error occurred while processing tkdiff (NewVersion1)
E: Problem with MergeList /var/lib/apt/lists/debian_debian_dists_lenny_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.
E: Couldn’t rebuild package cache
La correction sera d’augmenter un buffer quelconque pour APT, en ajoutant/adaptant, généralement dans /etc/apt/apt.conf.d/70debconf la ligne suivante :
APT::Cache-Limit 15728640; // 15 MB
Afin de repousser un peu la limite.
Voilà, c’est tout pour cette petite astuce néanmoins bien pratique.
Permalink
09.17.08
Posted in Debian, Ubuntu, planet-libre.org at 6:11 pm by michauko
Sympa Hamachi, j’en parlais dans un précédent billet pour l’aspect “je joue en réseau avec mes potes”.
=> Aujourd’hui, j’en parle pour bloquer cette saloperie 
d’outil qui peut apporter de gros ennuis au boulot
Pour rappel, c’est un VPN “zero-conf” qui permet à l’utilisateur nullissime en informatique (c’est-à-dire que vous n’avez rien besoin de connaître en info pour installer/utiliser ce truc) d’installer un VPN pour atteindre ses copains au boulot ou son PC chez lui. Au-delà de ça, ça peut rapidement se transformer en une passerelle entre un réseau bien sale (celui de l’utilisateur lambda chez lui, nul en informatique je le rappelle) et votre entreprise. D’où problèmes. D’où envie de donner des baffes.
Voici comment le bloquer (du moins maintenant il ne passe plus à mon boulot et pourtant il essaye - donc je dois avoir fait le tour de la question), tant au niveau shorewall - si l’accès Internet est direct - qu’au niveau squid si vos utilisateurs *doivent* passer par le proxy pour atteindre Internet.
Analyse à 2 balles du comportement de hamachi pour mieux le bloquer
Au départ, installez hamachi pour tester. Ca devrait se connecter sans problème. Je pense qu’il va chercher la conf proxy dans les paramètres de IE.
C’est typiquement le genre d’outils qui a prévu tout un tas de modes de connexions genre :
- essayer tout un tas de ports standards
- avoir plein de noms de machines pour atteindre le serveur par plusieurs chemins
MAIS, comme c’est un outil avec un point central (le serveur chez eux pour s’authentifier - puisque ça a une vocation commerciale, payante, tout ça), on peut à un moment donné repérer tous les serveurs centraux et les bloquer. C’est pas comme pour des protocoles décentralisés type peer-to-peer.
Bon après, s’ils changent leurs noms ou IP tout le temps, ça peut devenir pénible.
Une fois connecté, allez voir vos logs squid, vous devriez voir tout un tas de requêtes du style :
1221661590.889 350758 votre.ip.sur.lan TCP_MISS/200 3734 CONNECT ssl-24.hamachi.cc:443 - DIRECT/74.201.74.26 -
De là, avec quelques commandes hosts, genre :
for i in `seq -f ‘%02g’ 1 40`
do
host ssl-$i.hamachi.cc
done
Ainsi que :
for i in `seq 1 255`
do
host 74.201.74.$i
done
Ce qui donne :
…
103.74.201.74.in-addr.arpa domain name pointer ns3.3amlabs.com.
104.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
105.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
106.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
…
Vous verrez qu’en gros, la plage IP 74.201.74.0/24 est à eux et qu’avec 4/5 noms de domaines génériques, vous pourrez tout bloquer.
Blocage niveau shorewall
En considérant que votre shorewall fonctionne bien, vous pouvez soit blacklister dans le fichier /etc/shorewall/blacklist (si vous avez bien activé l’option “blacklist” dans le fichier /etc/shorewall/interfaces), soit faire une règle dans /etc/shorewall/rules.
Dans “blacklist”, ajoutez la ligne :
74.201.74.0/24
Ou, dans “rules”, ajoutez :
DROP lan net:74.201.74.0/24 all
Relancez shorewall via /etc/init.d/shorewall reload
Blocage niveau Squid
Allez dans le fichier /etc/squid/squid.conf et à l’endroit où sont définies des “ACL”, ajoutez celles-ci - c’est un exemple à adapter.
acl tout_mon_lan src 172.16.0.0/255.255.0.0
acl vilain_hamachi dstdomain .hamachi.cc .logmeinhamachi.com .logmein.com .3amlabs.com logmeinrescue.com logmeinrescue-enterprise.com
http_access deny tout_mon_lan vilain_hamachi
(le tout sur 3 lignes uniquement)
Ici je me base sur les noms de domaines, pas les IP. C’est un choix motivé par le fait que le client hamachi semble tenter des noms de machines, pas des IP. A voir si l’éditeur fait évoluer ça dans le temps.
Et pensez à recharger squid : /etc/init.d/squid reload
Validez que ça ne marche plus
Retestez la connexion à Hamachi. Vous devriez le voir s’exciter dans les logs squid sur quelques ssl-xx.hamachi.cc pris au hasard puis plus rien :
1221666080.309 0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-14.hamachi.cc:443 - NONE/- text/html
1221666199.615 0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-15.hamachi.cc:443 - NONE/- text/html
1221666283.816 5 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-13.hamachi.cc:443 - NONE/- text/html
En images, ça reste sur ça :
Permalink
09.10.08
Posted in Bugs, Debian, planet-libre.org at 4:01 pm by michauko
En Debian Lenny, wordpress est passé en 2.5.1 (2.5.1-6 précisemment). Il y avait un warning à l’upgrade (l’occasion de rappeler l’existence du paquet “apt-listbugs” qui vous indique les bugs en cours sur un paquet que vous tentez d’installer/upgrader) qui annonçait que tout était pété en 2.5.1 sur “Sid” (unstable).
Etant en “Lenny” (testing), j’y suis allé confiant, résultat, je tombe sur ce bug et un blog inutilisable, en gros.
Manque de bol, j’ai regardé trop vite la version dispo en Sid. Aussi une 2.5.1, mais la -7, j’avais pas vu. Elle corrige le truc. Donc si vous êtes dans le même cas, ajoutez les sources “sid” dans votre “apt” et faites un “aptitude install wordpress”. Supprimez les listes “sid/unstable” ensuite.
Et pour rebondir sur le post précédent de Cedynamix, incitant à passer en 2.6.2 au plus vite pour raison de sécurité, vous êtes marron si vous en restez au packaging Debian, toutes versions confondues.
Permalink
07.18.08
Posted in Debian, Ubuntu, planet-libre.org at 4:51 pm by michauko
P’tite intro
J’utilise Squirrelmail comme client webmail pour les comptes en IMAP. C’est parfaitement fonctionnel, mais aussi très moche.
On peut certes changer le look si on adore le CSS, ou en trouver d’autres sur le web (mais ça se cantonne à changer la palette de couleur), ou enfin, pour 100/150 € on peut en payer un super-jouli avec des fleurs bleues dans les coins, au look de MS-LookOut.
Il y aussi Horde/IMP, très utilisé et complet. Et Roundcube, qui monte : très très joli (en AJAX-qui-tâche) mais pas encore 100% fonctionnel (bal IMAP partagées KO par exemple).
Sinon il y a aussi IlohaMail. C’est moins moche (sans être beau) et aussi simple à installer.
Par contre, le développement semble bien arrêté (depuis 2006). Sur une debian testing, on est en 0.8.6-rc3sid là où la .0.8.6 est officiellement sortie et la 0.9 en beta depuis 2 ans. Pas un message depuis 2 ans sur le blog.
Si vous êtes toujours en train de lire, c’est que cette vieillerie ne vous fait pas peur ; ça tombe bien vu que l’IMAP a pas du évoluer des masses depuis longtemps.
Comme Squirrelmail, les “thèmes” sont en options, voire rares, voire moches, voire payants….
Bon je critique, mais pour le prix, j’en suis content.
Allez, mise en place de la chose (au besoin, la mise en place de squirrelmail est décrite dans ma doc Debian qu’il-faut-que-je-mette-à-jour-un-de-ces-quatre).
Pré-requis
Idéalement, un serveur IMAP pour accéder à vos boîtes aux lettres, le PHP, un Apache2 et optionnellement une base de données (ex: MySQL). Regardez ma doc si vous n’avez rien de tout ça, sauf une grosse envie de monter une Debian.
Installation
Ca commence sur un air connu :
root@linux:~# sudo aptitude install ilohamail
Lecture des listes de paquets… Fait
Construction de l’arbre des dépendances
Lecture des informations d’état… Fait
Lecture de l’information d’état étendu
Initialisation de l’état des paquets… Fait
Lecture des descriptions de tâches… Fait
Les NOUVEAUX paquets suivants vont être installés :
aspell{a} aspell-en{a} dictionaries-common{a} ilohamail libaspell15{a}
0 paquets mis à jour, 5 nouvellement installés, 0 à enlever et 4 non mis à jour.
Il est nécessaire de télécharger 1550ko/1799ko d’archives. Après dépaquetage, 8889ko seront utilisés.
Voulez-vous continuer ? [Y/n/?]
Ensuite, vous aurez 2 questions :
Si votre installation Apache2 n’est pas trop en ruine, alors ça fera ce qu’il faut tout seul.
La deuxième question - je n’ai pas gardé la photo - vous demande quel alias utiliser pour accéder à l’application, par défaut “/IlohaMail”. Ca se change plus tard.
Utilisation
Normalement, moyennant un rechargement Apache, vous devriez avoir l’application qui fonctionne en allant sur votre http://votre.serveur/IlohaMail/ :
A la première connexion, il y a un paramétrage des préférences. On peut choisir quel est le répertoire d’envoi et de poubelle, ça peut être bien :
Paramétrage un peu plus avancé
Dans /etc/apache2/conf.d/ilohamail, vous pourrez corriger l’alias si mal choisi, exemple :
Alias /mail /usr/share/IlohaMail/source
Options +FollowSymLinks
DirectoryIndex index.php
AllowOverride None
order allow,deny
allow from all
Dans /etc/IlohaMail, il y a plusieurs fichiers sympa. Tous les fichiers sont commentés, pratique pour comprendre les paramètres.
/etc/IlohaMail/conf.php
$backend="DB" au lieu de “FS” si vous voulez stocker les données en base de données plutôt qu’en fichiers. Dans ce cas, il faudra aller dans le fichier db_conf.php pour finir la conf base de données (je ne l’ai pas fait).
Notez ceux là :
$AUTH_MODE["imap"] pour les méthodes d’authentification
$SMTP_SERVER défaut à localhost
$MAX_SESSION_TIME
$DISABLE_CALENDAR
$DISABLE_BOOKMARKS
/etc/IlohaMail/login.php
$default_host = "localhost" par exemple, ça évitera de demander à l’utilisateur un nom de machine
Comprenez aussi par là que IlohaMail, comme beaucoup de “webmail” configurables, peut aller lire vos messages IMAP d’un autre serveur. Si votre webmail IMAP au boulot ne vous plaît pas, par exemple.
Vous pouvez aussi masquer la zone de saisie du serveur et ainsi éviter qu’on puisse utiliser ce webmail pour lire les messages d’un autre serveur.
$hide_host = 1;
$hide_protocol = 1;
$hide_rootdir = 1;
$hide_lang = 0;
$default_lang = "fr/" au lieu de "eng/"
$SSL_ENABLED = true; si vous en avez besoin
/etc/IlohaMail/login_title.inc
Là, vous pourrez changer le message d’accueil du webmail en bidouillant un code HTML ultra-basique.
The End
Et voilà, c’est bon.
Notez que les modifs des fichiers PHP ne nécessitent pas de rechargement d’Apache puisque ces fichiers sont lus à chaque utilisation.
Bon mail
Permalink
07.11.08
Posted in Coup de coeur, Debian, planet-libre.org at 2:32 pm by michauko
Hop,
Oh le beau NAS !
J’ai couplé une PS3 à un NAS QNAP TS-209. Ce NAS tourne sous un Linux minimaliste (architecture ARM) hébergeant plein de services (lisez la fiche ça ira plus vite), notamment TwonkyMedia pour mettre à disposition en DLNA les contenus multimédias de ce NAS. Il y a évidemment un serveur SSH, FTP etc. Bref, tout ce qu’il faut pour bien gérer son contenu à distance et dans n’importe quelle condition.
Mais ça manque de commandes intégrées
Il ne manquait que certains outils qu’on a potentiellement l’habitude d’utiliser sur un Linux (donc depuis le NAS). Me concernant c’était LFTP afin que mon NAS puisse aller chercher tout seul certaines ressources en FTP sur un serveur (bon bref, je vous passe les détails). En effet, quitte à ce qu’il soit tout le temps allumé, autant qu’il sache downloader. Notez que de base, il intègre un wget, un client bittorrent administrable par le web etc….
Heureusement le fabricant est actif
Récemment, il y a eu un update de firmware permettant d’installer QPKG et donnant accès à un dépôt de paquets pour cette architecture, le tout grâce à la commande “ipkg” dont la syntaxe ressemble à du “apt-get”.
On peut donc maintenant installer les commandes screen et ncftp. Par exemple. LFTP ne passe pas pour des problèmes de versions de libc. Plutôt qu’une énorme prise de tête et un NAS potentiellement HS, j’ai opté pour NCFTP au lieu de LFTP. Libre à vous de galérer si vous voulez.
Notez que le paquet QPKG s’installe sur la partition de données principale (exemple chez moi : /share/MD0_DATA/optware/), pas sur les partoches systèmes standard. Donc vous pouvez imaginer installer plein de paquets, il y aura de la place, tant que vous en avez sur votre partition principale.
Installation et utilisation de QPKG
Malheureusement, il ne suffit pas de mettre le nouveau firmware pour obtenir “ipkg”, il faut mettre le nouveau firmware puis installer un paquet “optware” supplémentaire.
Voici donc comment installer QPKG (optware et ipkg) afin de pouvoir taper des commandes magiques comme :
ipkg install screen
ipkg install ncftp
J’ai presque l’impression d’être sous Debian, ouaiiiiiiiis
Mise à jour du firmware
Rapidement, vu que c’est archi-classique, débrouillez-vous. Le firmware est sur le site officiel.
Installez QPKG
Depuis l’interface d’admin de votre NAS (http://votre.ip:8080/) :
La première fois, vous ne trouverez pas le module QPKG, il faut cliquer sur le bouton “Get QPKG”, vous suivez le lien, vous downloadez le paquet sur votre PC puis le chargez dans l’interface. A la fin, vous l’activez, ça ressemble donc à ça :
Ensuite, balancez la purée avec ipkg
Voici ce que donne l’installation de screen et lftp :
[/share/MD0_DATA/optware/opt/bin] # ./ipkg install screen
Installing screen (4.0.3-2) to root…
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/screen_4.0.3-2_arm.ipk
Installing termcap (1.3.1-2) to root…
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/termcap_1.3.1-2_arm.ipk
Configuring screen
chown: unknown group name: root
Configuring termcap
Successfully terminated.
[/share/MD0_DATA/optware/opt/bin] # ./ipkg install lftp
Installing lftp (3.7.3-1) to root…
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/lftp_3.7.3-1_arm.ipk
Installing ncurses (5.6-3) to root…
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/ncurses_5.6-3_arm.ipk
Installing expat (2.0.1-1) to root…
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/expat_2.0.1-1_arm.ipk
Installing libstdc++ (6.0.3-6) to root…
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/libstdc++_6.0.3-6_arm.ipk
Configuring expat
Configuring lftp
Configuring libstdc++
Configuring ncurses
//opt/lib/ipkg/info/ncurses.postinst: line 2: update-alternatives: command not found
postinst script returned status 127
ERROR: ncurses.postinst returned 127
Successfully terminated.
[/share/MD0_DATA/optware/opt/bin] #
La fin ne sent pas très bon. Ca se passe mieux avec NCFTP. J’ai pas cherché plus loin.
Ah oui, j’oubliais, il me semble que ipkg n’est pas le PATH au début. Comme je devais le rebooter, je l’ai fait. Depuis je peux taper ipkg depuis n’importe où. C’était peut-être simplement mon shell ouvert qui datait d’avant l’installation de QPKG, donc PATH KO. Enfin ref, relogguez-vous ou rebootez, au choix.
Amusez-vous bien.
Le mot de la fin
Si vous hésitiez entre tel ou tel NAS, franchement celui-là, il est cool. Si vous avez des questions sur son fonctionnement, demandez toujours.
A+
Permalink
« Previous entries
![plug-in \"members-only\" pour Wordpress](http://michauko.org/blog/wp-content/uploads/2008/10/20081009_165503.png "plug-in \\"members-only\\" pour Wordpress")
