On peut soit passer par leur service, limité à 25 Mo par utilisateur (mais gratuit) soit installer soi-même son propre serveur. Etant un peu de nature paranoïaque, j’ai donc choisi la seconde solution après avoir testé la façon dont fonctionne leur service.
Certains blocs expliquent que la procédure d’installation fonctionne mal, voire pas du tout, même après plusieurs essais.
J’ai donc décidé de vérifier ces allégations en testant la procédure officielle du site de Mozilla sur un nouveau conteneur sur mon NAS.
Je réplique donc les commandes citées apt-get install python-dev mercurial sqlite3 python-virtualenv libssl-dev hg clone https://hg.mozilla.org/services/server-full cd server-full make build
Là, j’obtiens une erreur liée à une résolution qui ne peut pas s’effectuer. Je ne cherche pas bien longtemps, je tente de relancer le make build, qui cette fois se déroule sans problème.
Une fois l’installation terminée, je passe à l’étape de configuration.
Je le lance, puis je vais sur son URL:5000 et obtiens une 404. Fonctionnement étrange, mais soit.
Cela semble fonctionner à peu près … sauf si le certificat SSL de son reverse proxy n’est pas ajouté en exception, visiblement :–)
]]>Il ne m’a pas fallu longtemps pour me dire que je gaspillais de l’électricité et du temps d’attente à laisser ces machines séparées.
Rapidement cependant, je me suis rendu compte que l’actuel serveur était jonché de tests divers et variés, avec des services pas réellement utilisés qui étaient lancés, des bouts de configuration par-ci par-là … bref, une plate-forme de test.
Je voulais faire quelque chose de plus propre à cette occasion, et la virtualisation m’a permis de répondre à cette problématique.
La virtualisation, on en parle beaucoup : c’est vrai que c’est très pratique, on peut lancer plusieurs systèmes sur sa machine de bureau par exemple, en même temps. Sur un serveur, c’est globalement le même principe : on lance plusieurs machines distinctes les unes des autres.
Nous avons, au choix, dans la virtualisation, deux types de technologies : la virtualisation complète, ou bien la para-virtualisation par conteneurs.
Dans le premier cas, le système virtualisé (invité) a conscience qu’il est virtualisé : ses composants portent bien souvent la marque du distributeur (de la solution de virtualisation), et les pilotes sont spécifiques. Charge à l’hyperviseur de transformer tout ça vers le système hôte par la suite.
Si cette option est indispensable pour faire tourner des systèmes différents (Linux / Windows, Windows / Unix, Linux / Unix, etc.) elle a l’inconvénient qu’on perd un peu en performances dans la “conversion”.
N’ayant que peu le besoin d’avoir d’autres systèmes que ma Debian préférée, je pouvais passer via une solution type OpenVZ, qui utilise des conteneurs afin de virtualiser (on partage le noyau avec la machine et on lance ses processus dans son coin). J’ai quand même décidé de me laisser une porte de sortie vers KVM, et me suis tourné vers Proxmox, qui propose assez simplement une interface web pour gérer ses machines.
Ainsi, j’ai donc la possibilité de créer de nouveaux conteneurs ou bien de nouvelles machines virtuelles.
La question suivante, c’était que mon NAS tournait sous Debian, et que je n’avais pas envie de le réinstaller. Fort heureusement, Proxmox est basée sur Debian également, et l’installation de quelques packages et d’un noyau personnalisé suffisent à transformer une Debian en une Proxmox !
J’ai cependant rencontré quelques soucis de dépendances, j’ai du bidouiller un peu pour que cela se fasse bien (jouer entre apt-get et aptitude, par exemple !).
Au bout de quelques minutes (ou heures, je ne sais plus :) ) ma Proxmox était opérationnelle ! J’ai donc commencé à créer un conteneur par service : – Owncloud (permet de remplacer Google Drive et Dropbox) – SabNZBd (outil en Python pour Usenet) – Sickbeard (outil en Python pour suivre ses séries) – Couchpotato (outil en Python également, mais pour les films) – ZNC (bouncer IRC pour rester connecté aux salons que je fréquente même mon PC fixe éteint) – Jabber (serveur XMPP) – Transmission, en version web (client Torrent) – Headphones (outil en Python permettant la gestion de librairie musicale) – un serveur DNS (pour usage futur, donc éteint pour le moment)
Chaque machine est indépendante des autres, et utilise la mémoire et les ressources CPU dont ses applications a besoin. J’ai une vue directe sur le réseau, le CPU , la RAM utilisée … par chaque machine. Je peux ainsi couper l’une ou l’autre en fonction des besoins.
Il reste sur l’hôte la gestion du serveur NFS, ainsi que du RAID logiciel. Huit machines lancées, plus l’hôte, consomment à peine 1 Gio de RAM, sur les 8 que propose mon NAS.
Je suis entièrement satisfait de cette migration : elle ne change rien à la gestion de mes fichiers, elle me permet de séparer les services que j’utilise, je gère le NAT sur ma freebox de façon simplifiée (j’ai une IP interne par service, qui tourne sur un port plus “classique”), le tout en consommant moins …
Et pour ce qui est de l’accessibilité de l’extérieur, j’ai toujours un reverse proxy sur mon Raspberry Pi qui me permet d’accéder, par noms, aux différentes machines.
]]>Vous partez, une, deux voires plusieurs semaines à l’étranger, donc.
Bien évidemment, votre compagnon téléphonique sera du voyage, pour être joignable à tout moment … au cas où. Et c’est compréhensible.
Principalement, il est nécessaire de s’occuper de deux choses avant de partir
Il faut s’assurer que l’option “Voyages”, si elle existe, est activée sur votre forfait. Généralement, votre espace client vous l’indiquera, et un coup de fil à votre services clients vous permettra le cas échéant de demander plus d’informations sur cette option qui permettra d’activer le roaming. Derrière ce mot étrange se cache tout simplement le fait d’être en itinérance sur un réseau mobile qui n’est pas le sien. Vu que l’on est dans un pays étranger, c’est donc normal.
Si votre opérateur ne vous propose pas cette option, changez vite de forfait avant de partir ;–)
Autre point que j’avais oublié (Merci Julian) : Les bandes de fréquences ne sont pas toujours les mêmes qu’en France. Pour l’Europe, aucun problème, mais les fréquences aux USA ou dans certains pays d’Asie par exemple sont différentes. Le plus simple est de demander confirmation à votre opérateur que votre téléphone français fonctionnera là-bas :–)
Si vous désirez pouvoir joindre vos proches depuis le pays étranger, il est nécessaire de faire une petite modification dans votre répertoire.
En effet, habituellement, nous rentrons les numéros sous leur forme géographique française, telle que 0Y.XX.XX.XX.XX, où Y prend une valeur entre 1 et 9 en fonction du numéro.
Si cette méthode fonctionne tout à fait bien lorsque nous nous trouvons en France, il ne faut pas oublier que nous allons sur le réseau mobile d’un opérateur étranger, pour qui le 06 que nous appelons peut tout à fait être un numéro appartenant à son réseau national …
Il risque donc de mal acheminer l’appel.
La manipulation est simple : elle consiste à remplacer le premier 0 du numéro par +33. Ainsi, un 06.00.00.00.00 sera transformé en +336.00.00.00.00
Rassurez-vous, cette numérotation fonctionne parfaitement de la France vers la France !
L’habitude est donc bonne à prendre à chaque fois que vous rajoutez un numéro dans votre répertoire :–)
Ici, la question est très délicate, car certaines coyances populaires veulent complexifier la chose, semble-t-il.
Je vais établir quatre scénarios différents, afin que vous compreniez bien tous les tenants et les aboutissants.
Dans tous les cas, pour connaître les tarifs appliqués, il faudra voir avec votre opérateur …
Votre soeur, Alice, a un mobile français. Elle veut vous joindre lorsque vous partez pour savoir si votre séjour se passe bien. Combien paiera-t-elle ?
La réponse est simple : un appel normal, comme si vous vous trouviez en France.
Attention par contre, vous paierez à la réception de l’appel.
Votre frère, Marc, habite en Allemagne, et il a un numéro Allemand. Son numéro commence donc par +49 (49 étant l’indicatif téléphonique de l’Allemagne).
Lorsque vous l’appelez, vous payez le prix d’une communication internationale. Lui ne paie rien.
C’est ce qui se produira, par exemple, si vous prenez une carte SIM locale pendant votre voyage, avec un forfait prépayé par exemple.
Vous payez un montant un peu plus élevé que si on vous avait appelé, votre correspondant ne paie rien.
Ici, c’est jackpot (mais pas pour vous) : vous payez le tarif d’une communication vers le pays d’origine de la ligne de votre correspondant, et celui-ci paye les frais d’itinérance puisqu’il n’est pas dans son pays.
Les SMS utilisent le même fonctionnement que les appels.
En conclusion de ces différents points : – Lorsque vous appelez un numéro français depuis la France, vous ne paierez toujours que le prix normal, que celui-ci soit à 2m de vous ou bien à l’autre bout du monde – Lorsque vous recevez un appel à l’étranger, vous payez (Note : la réception de SMS est gratuite) – Lorsque vous appelez la France depuis l’étranger, vous payez encore plus cher (Note : votre forfait SMS illimité ne s’applique pas, vous paierez les SMS envoyés depuis l’étranger)
J’espère que cet article vous aura permis de mieux comprendre, si ce n’était pas déjà le cas, le bazar que peut être la gestion de l’itinérance au niveau du mobile.
Si toutefois vous aviez encore un doute, ou une question, n’hésitez pas : Vous pouvez écrire à l’adresse
Il existe une solution assez simple pour contourner ce problème, du moins si l’on possède une machine à l’extérieur de son réseau (par exemple, un serveur virtuel, ou bien un petit Kimsufi chez OVH (enfin, s’ils acceptent un jour à nouveau les clients :–) )
Cet article parlera donc de SSH, de SOCKS et de tunnel.
Je vais vous expliquer, rapidement, ces différents termes.
SSH, qui signifie Secure SHell, est un protocole de communication chiffré (attention, celui qui utilise le verbe crypter, je l’enferme dedans (la crypte) !)
On peut faire tout un tas de choses avec … globalement, c’est simplement un protocole qui permet à deux machines de communiquer de façon sécurisée.
On le connaît bien souvent dans le domaine de l’administration système, via la prise de contrôle à distance d’un shell (ligne de commande).
Mais il est également possible, grâce à une option du client OpenSSH, de créer un véritable proxy SOCKS sur sa machine.
Pas question de parler de chaussettes ici, je vais plutôt résumer très rapidement l’article Wikipédia (anglais, car l’article français est nul).
SOCKS est donc un protocole qui route des paquets entre un client et un serveur au travers d’un proxy (un proxy qui s’appelle SOCKS, pour le coup).
Je ne vais pas partir dans une explication de ce qu’est un proxy, sinon on ne va pas s’en sortir.
Ici, le mot est très transparent, et a une correspondance dans la vie réelle : un tunnel, c’est tout simplement un grand tube avec deux extrémités :–)
J’y viens, ne soyez pas trop impatients !
Nous partons donc du principe que vous disposez de deux machines distinctes et géographiquement distantes. Typiquement, votre ordinateur de bureau chez vous, sur une connexion ADSL, et une machine ailleurs, sur une connexion de datacenter (100M, ou même Gigabit).
Ce que l’on va faire, c’est utiliser la connexion de notre serveur afin d’accéder à Youtube (ou autres, ça marche pour tous les sites web).
Et cela … grâce simplement à une seule commande. Nous allons utiliser l’option -D du client SSH, qui nous permettra de mettre immédiatement en écoute un proxy SOCKS sur le port de notre choix (rappel, les 1024 premiers sont réservés et seul root peut les utiliser)
La commande à utiliser est donc la suivante :
ssh -D 8080 utilisateur@hôte
Petite explication pour ce qui est dans la commande :
+ 8080 indique le port local sur lequel SSH va écouter les connexions entrantes
+ utilisateur désigne l’utilisateur avec lequel on se connecte au serveur distant (et on évitera root, parce qu’on a conscience des risques de sécurité d’avoir un compte root ouvert)
+ hôte désigne l’adresse ou le nom du serveur distant. Par exemple, monserveur.mondomaine.com, ou bien son adresse IP, directement.
SSH nous connecte donc effectivement au serveur, tout en mettant en écoute un port local. Nous avons presque fini.
La dernière étape est d’aller dans les paramètres de son navigateur, et de renseigner dans la partie Proxy les informations suivantes :
Proxy SOCKS (attention, on ne remplit pas HTTP ni les autres champs) : localhost : 8080 (si on a mis un autre port dans la commande, on le modifie, bien évidemment)
Et … c’est tout ! :)
On peut maintenant regarder des vidéos de châtons en 1080p ! :–)
Une fois cet article terminé, je me suis rendu compte qu’il manquait une petite explication au pourquoi du comment, à ce qu’on a fait, et les implications.
Globalement, chaque fournisseur d’accès à Internet a des accords avec des fournisseurs de transit, afin d’interconnecter les différents réseaux mondieux.
Certaines routes, fréquemment utilisées (on prendra comme analogie le périphérique parisien) saturent souvent quand trop de monde veulent les emprunter.
Ce que nous faisons, c’est que nous sortons prendre une autoroute que moins de monde utilise pour aller là où on veut … et même si le chemin est plus long, vu qu’on va beaucoup plus vite, ce n’est pas très grave. Bien évidemment, cette autoroute a un petit péage en fonction des services que l’on a à notre disposition.
Techniquement, notre navigateur envoie toutes ses requêtes à notre proxy SOCKS, qui lui ne fait que transférer cela à la machine distante, qui se charge elle d’effectuer réellement les requêtes et de les renvoyer dans le tunnel pour qu’on les recoive. C’est presque “simple” comme fonctionnement.
]]>C’était clairement un problème jusqu’à ce soir. J’avais mis en place une solution de contournement utilisant un web-proxy … qui était malheureusement assez peu pratique.
En visitant le blog de Victor Héry, je suis tombé sur cet article qui indiquait comment monter un reverse proxy avec Apache. D’ailleurs, son explication de l’utilité du bazar est assez claire, n’hésitez pas à aller le lire.
Du coup, j’ai entrepris de faire la même chose avec Nginx sur mon Raspberry Pi (parce que Apache, c’est trop facile :–) )
Edit 10 mars 2014 : Coquille trouvée par un lecteur concernant l’emplacement du fichier contenant la configuration : il n’était pas situé dans /etc/nginx mais dans /etc/nginx/sites-available/
Il faut également vérifier que le fichier nginx.conf va bien chercher les fichiers dans sites-enabled et faire le lien symbolique qui va bien :)
Pour expliquer rapidement, Nginx (A prononcer Engine X, j’ai appris ça récemment) est un serveur web, qui a des fonctionnalités de proxy, de reverse proxy, et load balancer, etc.
Il a un gros intérêt, c’est sa très faible consommation en ressources.
Un proxy, globalement, c’est une machine qui va servir d’intermédiaire entre le client (votre ordinateur, par exemple) et un serveur (par exemple, un serveur web)
Généralement, un proxy est utilisé en entreprise en guise de “porte de sortie” vers le web. Quand on ne renseigne pas l’adresse du proxy dans le navigateur, il n’est pas possible d’accéder à Internet.
Le reverse proxy, il fait l’inverse : depuis Internet, accéder à plusieurs (machines|services|sites|…) qui sont dans un réseau local, sans passer par de la translation d’adresse / de ports, qui, bien que pratique, est rapidement limitée quand on a qu’une adresse IP, par exemple.
Pour schématiser rapidement, pour accéder aux différents services que j’ai chez moi, je veux une adresse en trucbidule.mondomaine.fr ou machinchose.mondomaine.fr et pas mondomaine.fr:1337 ou mondomaine.fr:42
J’ai un domaine qui pointe vers l’adresse IP de chez moi, qui sera, à des fins de confidentialité, modifié dans ce billet. Je prendrai http://chezmoi.exemple.fr comme … exemple.
Je déclare donc dans mes DNS de nouveaux enregistrements : + service1.chezmoi.exemple.fr + service2.chezmoi.exemple.fr
Je les fais pointer en CNAME vers chezmoi.
Jusque là, rien de très compliqué.
Là encore, rien de très compliqué sous Debian …
apt-get install nginx
Devant de plus en plus parano, je désirais forcer l’utilisation de SSL à ce niveau-là, afin d’éviter toute interception éventuelle de mes mots de passe sur des réseaux non sécurisés …
J’ai du suivre ce tutoriel très bien fait, et donc en gros, avec 3 commandes j’étais prêt à activer le SSL sur mes domaines
openssl genrsa -out nginx.key 2048
openssl req -new -key nginx.key -out nginx.csr
openssl x509 -req -days 3650 -in nginx.csr -signkey nginx.key -out nginx.crt
Et voilà, un certificat SSL signé par moi-même, accompagné de sa clé.
Ici, les concepts qui entrent en jeu sont un peu plus coriaces …
Pour faire simple, on fait correspondre une configuration à un nom de domaine (service1.chezmoi.exemple.fr par exemple)
On dit à notre nginx que quand le client appelle service1.chezmoi.exemple.fr, il agit de telle manière.
Note : La directive Host est implémentée dans la version 1.1 du protocole HTTP, un client en version 1.0 ne pourra pas accéder à vos hôtes … mais globalement, vous ne devriez pas avoir à vous en soucier, HTTP1.0 n’est plus utilisé depuis un bout de temps.
Je créée donc un fichier /etc/nginx/sites-available/reverse, où je place toutes mes configurations. Les voici, en brut, commentés avec les # :
# On commence par dire où se situent nos certificats SSL
# On aurait pu les mettre séparément dans chaque "server" en ayant besoin.
ssl_certificate /etc/nginx/nginx.crt;
ssl_certificate_key /etc/nginx/nginx.key;
server {
# Redirection vers HTTPS
# Ici, je spécifie que toute requête vers le port 80 (HTTP) sera renvoyée vers le même hôte, en HTTPS.
listen 80;
return 301 https://$host$request_uri;
}
server {
# Service 1
listen 443;
# J'active SSL
ssl on;
server_name service1.chezmoi.exemple.fr; # Ici, c'est le nom de domaine qui sera appelé dans le navigateur
location / { # pour le dossier racine (/), on active le mode proxy vers l'adresse spécifiée, sur le port spécifié
proxy_pass http://premieremachine:1081/;
}
}
server {
# Service 2
listen 443;
ssl on;
# On peut spécifier 2 noms de domaine différents qui auront le même comportement
server_name service2.chezmoi.exemple.fr;
server_name chezmoi.exemple.fr;
location / {
proxy_pass https://secondemachine:443/;
}
}
On relance le service … et ça roule !
On teste dans son navigateur en HTTP, on est bien redirigé vers la même adresse en HTTPS …
On a un avertissement qui dit que le certificat est signé par une autorité non-reconnue (moi :) ), c’est normal, on “accepte les risques” et c’est parti.
Notre serveur nginx fait donc bien son travail de proxy … nous ne savons pas, en tant que client, quelle machine travaille derrière : on sait juste que sur l’URL appelée, le service nous est retourné.
Je n’ai eu aucun souci pour proxyfier du HTTPS, pour répondre à Victor :–)
Pour schématiser rapidement : |client|<==SSL==>|proxy|<==SSL==>|serveur|
Tout d’abord, il semble nécessaire de parler de cette école : 42, qu’est-ce que c’est ? Pourquoi 42 ?
Mes lecteurs “geeks” auront reconnu l’allusion à la réponse universelle, de l’écrivain Douglas Adams, dans son livre Le guide du voyageur galactique (The Hitchhiker’s Guide to the Galaxy).
(D’ailleurs, je n’ai pas lu le livre, j’en ai presque honte, mais si quelqu’un veut bien me le prêter …)
Le nom de l’école provient donc d’une référence connotée “geek”. C’est plutôt un bon départ, pour une école d’informatique, non ?
Fondée par Nicolas Sadirac (ancien directeur général d’Epitech), ainsi que deux de ses cadres dirigeants, Kwame Yamgnane et Florian Bucher, et financée intégralement pour les dix premières années de fonctionnement par Xavier Niel (fondateur d’Iliad, la maison-mère de Free, notamment) : ensuite, Xavier Niel espère que d’autres entreprises prendront le relais pour financer une formation innovante et permettant à de jeunes talents d’être formés gratuitement à l’informatique.
Généralement, quand Xavier Niel annonce une nouveauté, cela provoque un grand bruit (Cf le lancement de Free mobile). Cela n’a pas manqué avec le lancement de 42, à tel point que près de 50000 personnes ont débuté les tests de recrutement. Sur ces 50000, dont je faisais partie, beaucoup se sont arrêtés, soit en cours de route, soit à la fin des tests, pour la simple raison que la candidature était uniquement “pour voir comment c’était” : le fait est que les tests sont amusants, principalement des tests de logique et de persévérance …
Lorsque j’ai vu les résultats que pourraient donner cette école, et l’offre immédiate d’Ametix d’offrir un poste payé 45000€ annuels pour la première promotion sortante, je dois avouer que j’ai été emballé : enfin, une formation de pointe dans l’informatique était proposée en France, et cela gratuitement !
En regardant le programme, je dois avouer que c’est très complet. Surtout en trois ans … nous verrons bien ce que ça donnera dans la pratique, après tout.
Dans mon école, où je suis en cinquième et dernière année d’études (une école privée dont je ne vanterai pas les mérites), j’ai des amis, dont un qui est en première année. Il m’a avoué pendant cette année s’ennuyer pendant les cours, il trouvait que cela n’allait pas assez vite, qu’il n’apprenait pas grand chose. Je lui ai donc naturellement répondu que je comprenais ce qu’il ressentait … et puis, finalement, je lui ai conseillé de passer les tests d’admission de 42. Surpris au départ, puis curieux, il a finalement passé ces tests. Puis, étant admissible, il s’est posé la question de savoir si ça valait vraiment le coup. Là encore, je lui ai conseillé de poursuivre le processus en se rendant à Paris pour le “check-in”, autrement dit une présentation de ce que serait l’école pendant le premier mois d’été, puis pendant les trois ans qui suivent.
Finalement, il est allé à ce “check-in”. Puis il en est revenu, un peu effrayé. Je me rappelle ses paroles “Ils parlent de 60 à 70 heures de travail par semaine, je tiendrai jamais le coup.”
Effectivement, le rythme, surtout pendant la piscine, est éprouvant. Pour les débutants complets, c’est facilement douze heures de travail par jour, pendant tous les jours de la semaine. Pas de vacances pour trois ans, pas de week-ends (sauf si l’étudiant le décide … et accepte les conséquences ;–) ) : il faut être paré.
Aujourd’hui, il fait partie de la seconde “piscine”, période ultime de sélection, où environ 750 étudiants travaillent, pendant un mois complet, et se plongent, d’abord dans le Shell, puis rapidement et pour le reste du mois dans l’apprentissage du langage C. Les premiers abandonnent dès le premier jour, beaucoup suivent … pendant tous le mois. De la piscine de juillet, il est resté 500 étudiants sur les 800 du départ : on peut juger que beaucoup ne pouvaient pas tenir le rythme, où n’étaient simplement pas fait pour travailler dans l’informatique … ce qui est totalement compréhensible (on retrouve, globalement, des chiffres assez proches dans les premières années des autres écoles).
De ses mots, il commence réellement à apprécier la piscine. Je le comprends totalement. C’est un challenge permanent, sans rythme imposé, sans cours imposés (les cours sont sous forme de vidéos sur l’intranet, et chacun les visionne (ou pas) à son rythme afin de rendre les exercices (ou pas, là encore ;–) ).
Ce qui fait que cette piscine est passionnante, et que j’aurais sûrement adoré ? Le challenge, tout d’abord, la découverte de nouvelles choses, la nouveauté …
Les inconvénients sont de respecter la Norme de 42 … ma foi assez stricte, mais je pense, très formatrice.
A quoi ça sert de sortir des gens qui font du code illisible ? :–)
Si je lui ai conseillé 42, c’était parce que je savais qu’il était un peu comme moi, qu’il a en lui le “gêne” de l’informatique.
Quel est ce “gêne” de l’informatique ? Selon moi, cela se matérialise par une curiosité exacerbée, et un besoin de comprendre “comment ça marche”.
Depuis des années, je suis passionné et très curieux des machines que je découvre, j’ai envie de savoir comment elles fonctionnent, et je veux en savoir toujours plus.
De l’informatique sans challenge, sans renouveau, pour moi ce n’est pas de l’informatique, et je suis certain qu’il pense -ou pensera, dans quelques années- comme cela.
La suite, c’est que je suis persuadé qu’il terminera brillamment cette piscine, et je suis persuadé qu’il sera admissible dans cette école, parmi les mille étudiants sélectionnés.
Et je suis persuadé qu’il réussira ses trois années de formation haut la main, j’oserai presque parier qu’il sera assez haut dans le classement … mais pour ne pas lui mettre trop de pression, je ne vais pas le dire :–)
Dans tous les cas, je lui souhaite bien du courage, et il est certain que je serai ravi de le conseiller en tant que recrue dès que possible, pour des stages ou un premier emploi, parce que je sais qu’il sera un excellent informaticien.
Je n’ai pas conseillé cette école à beaucoup de mes connaissances. Pour dire vrai, je ne l’ai conseillée qu’à deux personnes, que je considérais apte à réussir. Une seule d’entre elle a relevé le défi, je lui souhaite tout le courage qu’il faut pour mener à bien ces trois années et en ressortir excellent.
Quoi de mieux qu’une petite machine pas chère pour gérer un petit serveur de mails ? :-)
Ayant déjà touché un peu à Postfix pour la gestion des mails, je me suis dit qu’il serait parfait pour mon usage, je suis donc parti sur cette solution.
Il me fallait également un serveur IMAP, et pour lui, je me suis orienté vers Dovecot, que j’avais également approché rapidement par le passé
Et enfin, la dernière étape : le webmail. Mon choix s’est orienté vers Roundcube. Un peu par défaut, n’ayant pas eu d’apparition divine m’indiquant qu’un autre webmail était “mieux”.
A ma grande surprise, la configuration s’est passé … des plus simplement. J’ai installé Postfix, ma distribution m’a demandé l’usage que je souhaitais en faire, j’ai répondu “site Internet”, et la configuration s’est faite seule.
Idem pour Dovecot et Roundcube … Tout au plus, j’ai dû empêcher le lancement d’Apache (lié à RoundCube par les dépendances), et utiliser le nginx précédemment configuré pour faire pointer tout cela vers la bonne adresse … Mais c’est bien tout !
J’ai également généré des certificats SSL pour RoundCube … principalement pour utiliser l’application Android du même nom sans risquer du spoofing … sait-on jamais :)
La machine derrière est donc composée d’un processeur Atom N2800, 2 Go de RAM, un disque dur de 500 Go, et une connectivité de 100Mbps.
Les plus geeks d’entre vous imagineront immédiatement plein d’usages sympas pour seulement 3€ (Hors Taxes, certes) par mois.
Maintenant que j’ai cette machine à disposition, qu’est-ce que je compte en faire ?
La question mérite de se poser. Pour l’instant, j’ai quelques pistes, que j’explorerai au fur et à mesure du temps.
Parmi les idées que j’ai, on peut lister :
Vous connaissez probablement Wordpress, système de gestion de blog utilisé par près de la moitié des blogs au niveau mondial …
Eh bien, désolé, mais vous n’êtes pas sur un blog propulsé par Wordpress.
Désireux de connaître d’autres systèmes, j’ai demandé à twitter ce qu’on pouvait me conseiller : on m’a répondu Octopress.
Après quelques recherches rapides, je tombe donc sur le site officiel.
Après légère réflexion, je me suis dit qu’il serait plus utile d’avoir un système générant des pages statiques, plutôt qu’un système comme Wordpress qui est dynamique (et donc régénère les pages à chaque visite). Ça tombe bien, Octopress est un système comme cela.
Pour faire simple, j’écris mes articles et mes pages dans des fichiers texte tout simples, avec les balises HTML que je souhaite, et puis je lance la génération des fichiers statiques.
Pour le moment, cela ne prend que quelques secondes, mais je suppose que sur des fichiers fréquemment modifiés, et en grand nombre, le temps doive s’allonger … ce n’est pas très important, vu le but et la popularité attendue du blog ;-) )
Je retire plusieurs avantages à ce système :