Et quand je vois ça : http://www.nofrag.com/2008/nov/17/30079/, j’ai peur pour son avenir… de gamer. Je me dis qu’il n’aura plus moyen de se gratter les couill… en jouant aux FPS sans se faire péter une grenade sur les pieds ? Tu décapsules ta binouse en pleine LAN-à-la-webcam et boum, une ‘nade sur les pieds, équipe décimée. Tu farfouilles dans le tas de Haribo, hop, “defuse” ta bombe enclenchée par erreur. Tu te grattes le menton ? boum auto head-shot. Tu te grattes la jambe en pleine course ? dérapage au frein à main. Tu veux soigner ton coéquipier ? plante lui une seringue dans le bid’

Ca promet l’avenir technologique…
fiouuu, je suis fatigué moi

JFK avait raison, il aura fallu 40 ans.
Pourvu qu’il ne se fasse pas buter.

Et bon courage à lui.

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)

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 :

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.

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.

Et voilà le travail

Bon, va falloir que je remette à jour ma doc, moi…

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 :

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.

Je ne sais pas comment j’ai fait pour tenir si longtemps avec cette horreur.

(et avec modconf, vous pourrez virer une bonne fois le module pcspkr (”PC Speaker”), section kernerls/drivers/input/misc - yarglaaaaa)

Et comme à chaque fois, il faut :
- un clic toutes les 5 minutes tellement ça rame
- s’apercevoir que sous Firefox c’est un peu moisi ; donc recommencer la procédure sous IE
- valider 10 étapes pour dire “oui je sais c’est sensible, c’est privé, non je ne piraterai pas, oui lâchez-moi”
- enfin voir son nouveau contrat apparaitre (ouf)
- cliquer sur le bouton pour voir les numéros de licences
- revenir le lendemain et recommencer car il y a 24 heures de délai entre l’ajout et l’affichage des infos du contrat
- se dire qu’en attendant, autant lancer le téléchargement des CD, ce sera toujours ça de pris
- et une fois qu’on approche de ce Saint Graal, on obtient à chaque fois, sans mentir, ceci :

Bon, finalement, je retenterai demain… faut pas être pressé…

=> 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 :

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.

En résumé pour être plus libre et créatif dans ses services (et mieux dominer le monde ? les 2 fondateurs ont quand même parfois des idées étranges (si je ne me suis pas trompé de référence, je ne sais plus))

D’autant que vu les abonnés aux différents services Google (gmail etc), ils n’auront aucun mal à le faire répandre, contrairement à Firefox où il faut quand même chercher un peu pour l’installer (je parle des utilisateurs lambda proche du 0 en manipulation de souris - ils sont nombreux).
Là, n’importe quel utilisateur du moindre service Google pourra sûrement installer “Chrome” en un clic qui sera inmanquable sur l’interface dudit service… vous ne croyez pas ?

Bon, moi ce qui me taraude, c’est pas le navigateur, c’est l’OS. C’est pour quand ?
Qu’ils écrivent un OS depuis rien, j’en doute. C’est quand même couillu, surtout pour arriver à maturité (si la maturité d’un OS existe :). Par contre, partir d’un Linux et construire une distrib innovante, ils en ont les moyens, j’en suis sûr.
Je vois le plan d’ici : à l’install, première étape, tu donnes (ou crées) ton ID gmail et de là, ça récupère tout ton environnement OS lié à ta personne : tes applis, tes paramétrages, ton fond d’écran. Bref, tout ce que Google pourrait stocker comme ils aiment le faire.
Ca me parait réaliste :
- prendre un linux
- un système de package simple et et transparent (à la Ubuntu “ajout/suppression”) avec des applis bien senties (c’est beau d’avoir beaucoup de choix mais déroutant pour le commun des mortels à qui IE/media player suffisent puisqu’ils sont fournis)
- un look joli sans trop en faire
- évidemment un clic direct vers les services Google
Avec ça tu couvres beaucoup d’utilisateurs standards (type web/mail/mp3/msn).

Alors, votre avis ? l’OS, il viendra ? sous quelle forme ?

Deux/trois tests plus tard, je vois le plan : ok pour les ports standards de bureautik-man à la plage (lire ses mails, naviguer sur Internet) mais le reste….. zob.
En gros, j’ai pu voir vite fait que ça passait pour les ports 80, 443, 465, 993 et 1194. Le reste j’ai pas cherché. A tous les coups, le 25, 143, 110 doivent passer aussi. Sans compter la miriade de saloperies de ports réseaux d’un Exchange / Active Dir. Ca doit marcher aussi, sinon comment faire pour vite vite reprendre sa propale depuis son transat ?

Alors bon, le VPN passe, donc c’est bon me direz-vous. Justement pas. S’il s’agit de dépanner le VPN ou si vous avez mis des restrictions sur le VPN (histoire que le VPN ne soit pas nécessairement une énorme porte ouverte dans l’entreprise), ça vous fait une belle jambe que le VPN fonctionne.

Conclusions :
1) Obligé de se taper des SSH sur port 443, des tunnels à gogo lorsque le VPN est trop restrictif…
2) Tu parles d’un accès web, tu peux même pas faire ce que tu veux. Pourtant, dès lors que le port 25 est ouvert, si la motivation principale est comme d’hab d’endiguer le spam des zombies etc, franchement, le mal est fait. Ca sert à rien de bloquer le reste.
3) Ou alors j’ai raté une conf quelque part pour ouvrir le port 22 ? je doute

C’est mes yeux ou c’est vraiment de l’accès restreint ce genre de connexion ?

Enfin, bientôt en vacances, c’est déjà ça…

Cet article donne simplement la procédure à suivre depuis un poste Linux pour créer un XUbuntu “persistant” sur USB. Si le mot “persistant” ne vous dit rien, il s’agit d’avoir un Live OS sur USB qui se souvient des modifications (fichiers créés/modifiés), des applications installées etc. Bref, un OS vivant et… persistant.
Le principe ? une partition qui est l’image du CD Live OS, l’autre qui est un “espace de stockage” des modifications, une sorte de “/” qui va grossir avec le temps (et vos modifications).

Ce qui m’a donné envie d’en remettre une couche est le fait que sur mon PC principal, la Ubuntu 7.10 donnait un affichage pourri sous X et sur quelques portables, X ne se chargeait pas du tout.
Pour mon PC principal, Ubuntu 8 a réglé le problème. Pour les portables, je verrai plus tard.
Enfin, tenter un upgrade de Ubuntu 7 à 8 ne me paraît pas être une bonne idée : en effet, dans le cadre d’un OS persistant, il y a certes la partie variable, mais aussi toute ce qui est immuable, tout ce qui concerne le boot. J’ai pas osé “upgrader” la distrib. Surtout que c’est plus une solution de dépannage, pas vraiment pour embarquer un réel OS peaufiné aux petits soins, sinon bonjour les problèmes de drivers graphiques par exemple…..

Assez parlé, voici la manip, brutale :

1) Prenez une clef USB d’au moins 1 Go, plutôt une rapide

2) Créez 2 partitions, l’une de 600 Mo (suffisant pour un XUbuntu dont l’ISO fait 540 Mo), type FAT16 (code 6 sous fdisk), l’autre du reste de la clef, type Linux (que vous formatterez en “ext2″, n’allez pas me mettre de la journalisation sur une clef USB ! O_o). La deuxième partition doit impérativement s’appeler “casper-rw” - c’est comme ça que la partition persistante sera identifiée.
Ne pas oublier : rendez bootable la première partition !

3) Formattez les comme suit :

mkfs.vfat -F 16 -n ubuntu841 /dev/sdX1

(remplacez X) et :

mkfs.ext2 -b 4096 -L casper-rw /dev/sdX2

(remplacez X aussi).

Si vous n’avez pas l’application “mkfs.vfat”, installez le paquet “dosfstools”.

4) Copier ensuite le contenu de l’ISO de la mouture d’Ubuntu qui vous convient (XUbuntu, Ubuntu etc) à la racine de la première partition. Je recommande XUbuntu afin d’être “léger” sur tout type de PC.

5) Recopier le contenu de /isolinux à la racine de la clef.

6) Recopier /casper/vmlinuz à la racine de la clef.

7) Remplacez /casper/initrd.gz par celui fourni ici.

8 ) Copiez le fichier syslinux.cfg trouvé ici à la racine de votre clef.

9) Utilisez un “syslinux” récent (ici, version 3.71) si celui de votre distrib date un peu (qui a dit Debian Etch ?) pour rendre bootable la clef :

syslinux -sf /dev/sdX1

(remplacez X)

Démontez votre clef bien proprement, évidemment, et tentez votre chance. Ca devrait booter
Par défaut, vous bootez en mode persistant en tapant “persist”.

Amusez-vous bien.

La doc d’origine, en anglais et qui n’explique absolument rien est là. Certes j’ai été assez rapide aussi, mais mon précédent article devrait vous fournir des explications complémentaires sur le concept de clefs persistantes si vous n’avez rien compris.

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