Note to self
Je n’oublierais plus d’installer mysql-dev avant d’essayer d’installer le binding ruby-mysql
Il faut que je me marque ça sur un marbre, accroché en pendentif !
Ca doit faire au moins 3 fois que je me fais avoir. Bon ce soir, j’ai juste mis 10 minutes avant de m’en rendre compte. Donc histoire de ne plus oublier, je note ici la procédure. Elle se déroule sur macosX mais elle s’adapte à tout à peut de chose prêt.
Pour l’installation de mysql:
pouype@pomme:pouype$ fink install mysql
pour la futur installation de ruby-mysql
pouype@pomme:pouype$ fink install mysql-dev
Et après on peut sereinement executé:
pouype@pomme:pouype$ gem install mysql
RubyGem c’est bien, c’est pratique. Il faudrait que j’en parle…
Dernière minutes
Bon en fait j’avais pas vu, mais ça n’as pas marché, un problème pour trouver les librairies mysql on dirait. Bref, Gem c’est bien, mais on bonne installation de librairies à l’ancienne, avec un setup.rb, install.rb ça marche mieux ;-)
ssh avec clefs
Accéder à un serveur, avant ça se faisait par telnet. Maintenant Telnet est utilisé pour tester les connexions d’un serveur HTTP ou SMTP (ou autres) mais surement pas pour faire de l’administration de machine, car telnet est simple, basique et transmet en clair toute les instruction tapé, y compris les mots de passe.
Pour un accès plus sécurisé, l’administration de serveur (ou la simple connexion) s’effectue par le biais d’SSH. SSH est un protocole de communication, OpenSSH (voir aussi le site officiel OpenSSH.org) est un ensemble d’outil libre permettant l’utilisation de ce protocole.
Bon on arrête là les liens vers wikipedia :p Le but c’est donc de ce connecté de manière sécurisé à une machine distante. Pour cela, la machine distante doit avoir un “serveur” (ou démon) ssh qui écoute sur un port (par défaut: le 22). La commande en question:
ssh login@machine
et oui, tout simplement aller voir la man page ssh(1) pour en savoir plus.
Ensuite il faut saisir un mot de passe. Quand c’est une fois de temps à autre, ça peut aller. Quand cela vous arrive souvent taper tout le temps des mot de passe peut devenir pénible. On peut y remédier simplement. Tout d’abord, il faut se créer une clé. La commande ssh-keygen(1) nous permet de créé une clé privée et une clé publique chiffré en utilisant soit un type RSA soit DSA (arf, encore des lien wikipédia :-p ). Prenons DSA qui apparement est plus sécurisé (je ne suis pas un expert en sécurité, si quelqu’un peut me confirmé ça ?)
yafra@yeti:~$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/yafra/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/yafra/.ssh/id_dsa. Your public key has been saved in /home/yafra/.ssh/id_dsa.pub. The key fingerprint is: 90:56:9d:14:00:96:a1:73:dc:d1:ca:ef:09:fd:28:e6 yafra@yeti yafra@yeti:~$
En plus de préciser l’endroit où l’on souhaite placer les clefs, on peut préciser une phrase qui servira de confirmation de clef. Cette commande va donc créer une clé publique et une privée dans le répertoire .ssh (dans mon cas). On retrouve un fichier id_dsa pour la clé privée et un id_dsa.pub pour la clé publique.
Bien, maintenant on va ajouter la clé publique sur les serveur que l’on veux pouvoir contacter sans saisir de mot de passe. On vas utiliser la commande scp(1) pour ça.
scp .ssh/id_dsa.pub monlogin@monserveur:.ssh/
On place notre clé publique dans le repertoire .ssh de notre utilisateur sur le serveur cible. Ensuite il faut se placer sur le serveur en question pour effectuer l’ajout de la clé dans la liste des cléfs autorisés:
ssh monlogin@monserveur cat .ssh/id_dsa.pub >> .ssh/authorized_keys
Et voilà, le tour est joué. On peut maintenant se connecter en ssh sur cette machine en tapant simplement:
ssh monlogin@monserveur
Et sans avoir à taper de mot de passe. La seul condition est d’avoir la clé privé correspondante placé dans le repertoire .ssh (ou autre en fonction de la configuration du client ssh, mais c’est une autres histoire).
Ca faisait longtemps que j’avais pas posté. Faut dire qu’en se moment jesuis pas mal pris… tiens je vais d’ailleurs faire un petit top un de ces jours, dès que j’ai retouché quelque photos pour mettre avec :).
Pour ce qui est de ce billet, c’est pas bien compliqué, c’est des infos qu’on peut trouver sur pas mal de site, mais je pense que ça ne tueras personne que l’info soit disponible un peu plus :) et puis ça me fait plaisir de parler d’OpenSSH et de SSH en général, je m’en sert quotidiennement. Désolé pour ceux qui eventuellement ne comprendrais rien à tout ça (hein Terckan ;-) ).
OpenBSD hostname.change
Pan, oui je me tape sur les doigts. Déjà parce que ça fait un moment que j’ai pas blogué mais surtout parce que j’ai oublié comment on effectuais un changement de nom de machine sur un serveur OpenBSD. Pour essayer de retenir cette procédure, et surtout la noter quelque part, en voici la teneur:
Pour commencer, il faut modifier le fichier
/etc/myname
(fichier lu au démarrage pour connaitre le nom de la machine). Ensuite pour que les modifications soit prisent en compte (en la modification :p ) on “redémarre” le démons en charge du réseau:
$ sh /etc/netstart foo0
sh est nécessaire pour l’execution de la comment netstart. Certaines commande (enfin, au moins celle là) ne sont pas executable telle quelle. Bien sur il faut remplacer le foo0 par votre interface réseau (si vous en avez plusieurs) sinon ce paramètre n’est pas nécessaire.
C’est pas grand chose, certain peuvent même rire tellement c’est bête comme manoeuvre mais j’arrive jamais à m’en souvenir :p. Il faudrais aussi aborder les démons unix qui sont bien plus propre et complet que les “taches” windows (le nom en dit long de toute façon :p ). Mais là maintenant le plus important c’est de trouver un appartement à Montpellier !!
Vim exploration de fichiers 3
Oui oui, entre Vim et SciTE mon coeur balance. L'un est d'une puissance exceptionnel et disponible par défaut (enfin en version VI simple) sur toutes les machines de type Unix, l'autre est simple, jolie et tout de même efficace. Mais aujourd'hui je vais parler d'un plugin de Vim que je trouve excellent: un l'explorateur de fichier
Ce qui est bien avec Vim (et les logiciels libre en général) c'est qu'il y a toujours une plusieurs personnes qui, pour notre plus grand plaisir, développent de tas de petites choses qui nous facilite la vie. Un explorateur de fichier dans Vim... Je ne pensais même pas que ça pouvait exister. Mais en fouillant dans les tips de Vim j'ai découvert ce superbe plugins.
C'est tout simple, il suffit de télécharger le tarball. Je vous conseil de prendre celui qui est disponible sur le site de Vim, y'a un suivi des versions. Cependant pour les gens pressé, j'ai mis à dispo une copie de la version que j'ai testé dans la zone (vtreeexplorer-1.24.tar.gz). Ensuite on décompresse le tout dans le répertoire .vim:
$ cd ~/.vim $ wget http://zone.typouype.org/vtreeexplorer-1.24.tar.gz $ tar -xvzf vtreeexplorer-1.24.tar.gz
Et voilà. Maintenant en ouvrant Vim, vous avez accès à la commande :Explore qui ouvrira dans la page courante la liste des fichiers contenu dans le répertoire courant. D'autres commande sont disponible, comme :Vexplore qui exécuteras la même chose mais en effectuant un vsplit auparavant. Les fans de la souris pourront naviguer avec elle, mais quelque raccourci clavier vous permettra d'aller plus vite :)
Faut que je dépiote la doc maintenant, y'a pas mal de chose interessante... Puis me viens une idée aussi ou plutôt une question: des plugins Vim en ruby c'est faisable ? :D
OpenBSD 3.9 : gestion utilisateurs environnements
Dans le cadre d'un serveur, distant ou non, il est bon de prendre certaines précaution, et de s'aménager un environnements agréable. On vas essayer de faire ça.
Pour commencer simple et efficace, il est recommandé un peu partout, par un peu tout le monde de ne pas se connecter avec l'utilisateur "administrateur": root en terme nixien (de la planête *nix/*bsd, aucun rapport avec nixon ou qui que se soit :p). C'est dangereux pour les données et le systèmes. Un tel utilisateur a plein pouvoir sur l'ensemble et peu par faut d'attention tout mettre en l'air. Comme tout le monde le sait: l'erreur et humaine et en général les problèmes viennent de l'humain :p. En gros (et en gras) pas de connexion avec l'utilisateur root.
En général, sur un serveur on se connect e en utilisant le protocole ssh, dont 'implémentation la plus répendu est OpenSSH. Cette implémentation réalisé par les soins de l'équipe d'OpenBSD est evidemment incluse dans leur système, ainsi que dans beaucoup d'autres (plus ou moins officiellement). Le démon (serveur) OpenSSH est également le seul à être lancé dans une installation par défaut dans OpenBSD. Ce démon dispose d'un fichier de configuration qui vas nous permettre de limiter l'accès à notre serveur.
C'est assez simple, une fois connecté avec son utilisateur habituel sur le serveur, il faut passer en root pour pouvoir modifier le fichier (j'ai dit connexion en root, pas utilisation de root :p). Pour passer en root, utilisez la commande su(1) nous permet de devenir root le temps de la manipulation (on peut aussi utiliser sudo(8) mais comme je n'en ai pas encore parlé, on vas faire sans). Ensuite une édition du fichier /etc/ssh/sshd_config nous permettras de modifier la seul ligne qui pour le moment nous interesse : #PermitRootLogin yes. En fait la plupart des options en commentaire (je n'ai pas vérifié pour toute) sont affiché avec leur valeurs par défaut. Il nous suffit juste d'enlever le commentaire et de modifier le yes en no pour obtenir ceci :PermitRootLogin no. Facile non ? Et ça évite bien des problèmes. Fini les erreurs de manip alors que l'on c'est connecté avec root (vécu inside), et surtout la personne voulant attaquer le serveur devras commencer par trouver un login...
Et blablabla et blablabla. Normalement je voulais aussi parler du fichier .profile et de sudo, mais j'ai trop blablaté sur ssh là, j'ai pas envie de faire un post trop long avec plein de truc dedans. Là y'a que PermitRootLogin no, au moins c'est simple :p. Je tacherais de faire plus concis la prochaine fois quand même :)
OpenBSD 3.9 gestion utilisateur
Voilà donc le système d’exploitation OpenBSD 3.9 installé sur une dédibox. Après avoir envoyé le resultat de la commande dmesg
à l’adresse dmesg_AT_openbsd.org, on vas maintenant mettre en place certaines petites bricole bien pratique (voir indispensable :p )
La première chose à faire c’est de lancer la commande afterboot.
Celle ci nous informe de plusieurs manipulation conseillé pour le bon fonctionnement du système. On y retrouve notamment l’adresse de la page d’errata listant les correctifs à appliquer pour suivre la branche stable-current. Aujourd’hui, 11 correctifs sont disposition. Dont un à propos du serveur X dont on à pas besoin (sur un serveur).
Pour commencer, hors de question d’utiliser l’utilisateur root , créons un nouvel utilisateur.
adduser est la commande qu’il nous faut :). Sous OpenBSD et sans paramètres, celle ci permet d’ajouter un utilisateur de façon assité, vraiment très pratique et très clair. Quelque conseil apparaissent tout de même sur la fin de la page man:
- pour le username(nom d’utilisateur / Login)
- Utilisez plutôt des minuscules
- Utilisez des caractères alphabétique (pas de ponctuation)
- Pas plus de 31 caractères
- Le fullname (nom complet)
- sans le caractère :
Pour le reste, les sélections par défaut sont très bien (enfin moi c’est ce que j’ai utilisé :p). Juste pour l’utilisateur qui seras en charge de l’administration du système, il faut penser à le mettre dans le groupe wheel on verra plus tard que ça vas nous servir pour le sudo. Voici ce que ça donne en image:

Pour la suite on explorera le fichier sudoer pour le paramétrage de la commande sudo.
Installation OpenBSD sur dédibox 5
Je vous le disais il y a quelque jour: “j’ai commandé une dédibox (samedi 16/09/2006)”/articles/2006/09/16/jai-craqu%C3%A9. Et bien je l’ai reçu hier !! Rapide non ? je pensais pas l’avoir avant le week-end prochain :)
Du coup hier je me suis empressé d’installer ma nouvelle machine distante. Via la console d’administration de dédibox, j’ai lancé très facilement une installation de debian. Sans trop me soucier du détail car c’etais juste pour faire une première installation rapide, histoire de définir l’adresse ip de ma dédibox, et de pouvoir m’y connecter en SSH.
Très rapidement (moins de 10 minutes), je suis tout fiero de me connecter dessus :). Bon étape suivante, openBSD. Direction les liens que j’avais déjà parcouru plusieurs fois: bsdedibox.net et le lien fourni dans le wiki: open.bsdedibox.net. Sur ce dernier on trouve un petit formulaire qui reprend les grandes parties de l’installation d’OpenBSD que j’ai déjà peut voir plusieurs fois:


Après avoir rempli les champs, la validation crée assez vite (moins de 3 minutes) une image à télécharger. Un texte explique aussi la marche à suivre pour la suite. C’est assez simple, il faut redémarrer la dédibox en mode rescue (mono user) ce connecter (toujours avec SSH) dessus avec le compte root (le seul activé en mode rescue), puis faire un wget du fichier gardé en session sur le site de open.dedibox.net, avec une série de paramètre qui vas bien (et surtout qui doit placer l’image au bon endroit).
Ensuite, il suffit, via la console, de “sortir” du mode rescue ce qui a pour effeet de redémarrer la dédibox. Le redémarrage est un peu plus long que d’habitude, en fait l’installation d’OpenBSD est en train de s’effectuer.
Au retour du ping (un bon système d’alerte par mail est disponible pour le suivi de la dédibox) on peut se loggué à nouveau, mais cette fois sur OpenBSD :)
Simplissime non ? Je vous parlerais de ce que j’ai fait après (notamement les elements listés dans la page man du AFTERBOOT
OpenBSD: un système complet (installation)
Je vais essayer de retranscrire ici mes expériences avec OpenBSD. J’ai fait une première tentative qui a échoué, pour mieux retenter une autre fois, puis recraqué pour recommencer puis encore fait un bilan final pour finalement faire le retour du retour du retour du retour. Je crois que j’aime trop ce système et surtout ça philosophie… Mais je ne vais pas exposer mes aller retour. Je vais plutôt partager ce que j’en apprend, et comment je m’y prend ;-) (d’ailleurs vous pourrez peut-être m’aider ?)
Acquérir OpenBSD
Pour commencer il faut acquerir OpenBSD. Personnellement j’ai commandé les cd de la 3.9 (la version 4.0 devrais sortir en novembre). Ca permet d’aider un peu le projet, et de bénéficier de jolis CD avec une belle pochette :)
Sérieusement, les CDs contiennent tous ce qu’il faut pour une installation de base pour la plupart des architectures disponibles, et les sources (qui permettent de ne faire qu’une synchronisation CVS si on souhaite utiliser les ports, mais on en parlera plus tard). De plus, la pochette contient toutes les instructions pour installer le système, des recommandations, des dessins sympa, bref autant quand pour découvrir linux j’avais acheter la boite RedHat et regretté, autant là, je suis très heureux de l’avoir acheté.
aller voir sur le site pour plus d’info
Si vous préféré télécharger une image d’OpenBSD, il faut savoir qu’il n’existe pas d’image complète du système (pour pousser à l’achat des cds ? ). Cependant on peut trouver une image minimale permettant l’installation via le réseau d’un système complet: par exemple dans ce repertoire on trouve une un CD39.iso pour powerpc qui correspond au démarrage de l’installation et on peut trouver ici toute les architectures pour lesquelles un cd d’installation minimale peut être trouvé
L’installation
On vas pas faire dans la dentelle, pas de dual boot, on utilise tout le disque. Pour le dual boot ça dépends surement due l’environnement, étant sous powerpc je ne pense pas couvrir la plupart des bessoin (puis j’aime pas les dual boot :-p ).
D’ailleurs je ne vais pas rentrer dans un détail de questions/réponses, juste aborder les points que je pense spécifique à OpenBSD (peut-être à tout les BSD ? ). Dans un premier temps: la partition: on en a déjà entendu parler vaguement, les BSD n’utilise pas le système de partition tel qu’on le connais. Il utilise une partition certes, mais une seul. Après on peut toujours monter d’autres partition, mais le système doit être installé completement sur une seul. Par contre les BSD utilise des slice ou tranche pour compartimenter le système. Rien de bien effrayant. L’utilitaire DISKLABEL devrais se lancer automatiquement quand ça seras nécessaire. Personnellement j’ai du utiliser la commande me permettant de redéfinir la taille de prise en charge du disque, pour qu’il prenne tout (peut-être du à mon système osX qui traine encore par là).
Voici ce que disklabel propose comme commande:

En gros je me suit servi donc de b pour modifier la taille à prendre en compte (set OpenBSD disk boundaries)
d pour effacer les eventuelles tranche mal faites et de a pour en ajouter d’autres.
Il y a quelque informations importantes par rapport à ce disklabel. Tout d’abord, le disklabel c correspond à la tranche de base, c’est l’image de la partition sur laquelle on s’installe. Il ne faut pas le supprimer (par contre la commande b permet de l’agrandir si elle ne prend pas toute la partition :) ). Ensuite j’ai une particularité sous mac (uniquement ?) c’est une une tranche i. Ca correspond à mon MBR, un bout de disque qui vas servir pour le démarrage. Donc pas touche non plus (je crois que c’est spécifique powerpc). La tranche b est automatiquement placé en swap. C’est comme ça et pas autrement. Ensuite les conseils/bonne lecture propose d’utiliser:
- a : /
- d : /tmp
- e : /var
- g : /usr
- h : /home
(comment ça on a sauté une lettre ? ben oui c’est bizarre… enfin c’est pas très grave :) ).
Pour ce qui est des tailles, à part pour le swap conseillé avec un minimum de 32m, le reste est à la disposition de chacun. Petite précision, on peut saisir les tailles en précisant l’unité: 10k, 10m , 10g … ). Voici ma table de disklabel (à titre d’exemple)

Comme ce n’est pas une isntallation serveur, il n’y a pas d’élement exotique au niveau du réseau par exemple, je précise DHCP, le système me trouve tout ça tout seul, tranquillement. Les options par défaut sont bien souvent les bonne. On crée juste un compte root (en fait juste le mot de passe).
Ah si, il faut choisir les paquets de base à installer. Effectivement les BSDs (?) on leur serveur X “embarqué”. Pour openBSD les raisons sont la sécurité. Du coup le serveur X sur openBSD est passé au crible, revue et corrigé par l’équipe. L’inconvénient c’est que du coup les mises à jour sont moins fréquentes, le serveur X est un peu “vieux”.
Donc on choisi ces paquets, la liste n’est pas longue:
Select sets by entering a set name, a file name pattern or 'all'. De-select
sets by prepending a '-' to the set name, file name pattern or 'all'. Selected
sets are labeled '[x]'.
[X] bsd
[X] bsd.rd
[ ] bsd.mp
[X] base39.tgz
[X] etc39.tgz
[X] misc39.tgz
[X] comp39.tgz
[X] man39.tgz
[X] game39.tgz
[ ] xbase39.tgz
[ ] xetc39.tgz
[ ] xshare39.tgz
[ ] xfont39.tgz
[ ] xserv39.tgz
Set name? (or 'done') [bsd.mp] all
[X] bsd
[X] bsd.rd
[X] bsd.mp
[X] base39.tgz
[X] etc39.tgz
[X] misc39.tgz
[X] comp39.tgz
[X] man39.tgz
[X] game39.tgz
[X] xbase39.tgz
[X] xetc39.tgz
[X] xshare39.tgz
[X] xfont39.tgz
[X] xserv39.tgzTout les paquets commençant par X sont les paquets graphique. Pour une installation “de bureau” forcement, on prend. Je ne pourrais pas vous expliquer l’utilité de chacun, mais pour un système comme celui que l’on veut, on prend tout. Je pense que pour un serveur ça peut être interessant de ce pencher sur la question (game39 par exemple ne doit pas vraiment servir :) ).
Post installation
Et voilà, une fois fait, le système est fonctionnel. Un EJECT du cdrom s’impose, et un petit reboot ne fait pas de mal.
Nous voilà avec un prompt qui ne pourras marcher qu’avec le user Root (le seul existant pour le moment). La première chose à faire une fois connecté c’est envoyer le résultat d’un DMESG à l’équipe OpenBSD:
$ dmesg | mail your-account@yourmail.dom and then forward that message to dmesg@openbsd.org
Cela leur permet de recueillir des informations sur les systèmes installé.
Voilà, j’aborderais la suite plus tard, ça fait déjà un billet bien long. J’allais oublier: le site officiel OpenBSD sur lequel il y a beaucoup de docs, d’infos. Notamment les pages man qui sont accessible (voir aussi les liens sur les commande DISKLABEL, EJECT, DMESG dans le billet) et un très bon guide d’installation. Oui oui, finalement je n’ai fait qu’un commentaire de texte :) la prochaine fois ça seras peut-être plus personnelle
Le coùt d'un serveur dédié vs un serveur maison 2
Bon, puisque c'est le principal frein pour moi j'ai décidé d'essayer de comparer avec le cout d'un serveur maison... Histoire de me convaincre. C'est une étude faites maison, mais si ça peut aider certaines personne à prendre leur décision (moi le premier) c'est déjà ça.
Je considère que j'ai déjà une machine, ma machine de bureau. Je vais ramener les tarifs à l'année.
Coùt Financier
Dédibox:
C'est le plus simple. De quoi on a besoin ?
- Une connexion internet. Aujourd'hui elle tourne pour la plupart autour de 30 euro/mois (free, neuf, alice). Donc 30*12=~360 euro/an
- La dédibox. 29.99 euro ht/mois. soit:(29.99*1.196)*12=430.5 euro /an
Coùt total /an: 800 euro
Le serveur maison
J'ai fait une rapide config à peut prêt équivalente à la machine dédibox sur ldlc.fr: il faut compter environ 450 euros la machine. Pas de carte graphique (pas besoin c'est un serveur), pas d'écran, pas de clavier/souris.
La connexion internet. C'est le même tarif 30 euros/mois soit en gros, 360 euros/an.
Pour l'obtention d'une IP fixe, je crois que le plus simple c'est de passer par les services comme DynDNS ou no-ip.com. Ce sont des services gratuits (à ce que j'ai pu voir) donc aucun coùt financier.
Pour ce qui est de l'électricité, j'ai trouvé sur le site d'ernergystar.org un calculateur de consomation d'énergie. J'ai été assez surpris de voir que ça me reviendrais à seulement 126 euros/an... Bon je me suis peut-être trompé quelque part (attention sur la somme final il prend en compte l'achat ou la location de la machine...)
Coùt total / an = 900 euros la première année puis 500 euros
j'ai arrondi au supérieur, on vas dire une marge de sécurité sur mes estimations.
Coùt Temps
A l'installation, j'estime que je mettrais autant de temps. Pour la dédibox, je compte installer OpenBSD et à la maison aussi. Ca devrais me prendre le même temps. Même pour la maintenance, je passerais autant de temps. Même OS, dans les deux cas je serais en SSH dans une console (je pense) donc vraiment je vois pas la différence... Les kilomêtres ? Pour de la lignes de commandes je suis pas sur que ça soit si flagrant que ça.Au niveau des différence sur le temps, c'est le temps passer avec le hardware qui peut être compté. Combien de temps pour monter une machine ? combien de temps pour changer un disque dur ? combien de temps pour mettre de la ram en plus ? combien de temps pour remettre en place une carte réseau ? une alimentation ?
On vas dire que ça vas de 5 minutes à 4 heures. Soyons large :)
Conclusion Personnel
Effectivement, même si la première année coûte moins cher avec une dédibox, ça deviens plus interessant d'héberger un serveur à la maison. Cependant pour une différence de 300 euros par an ça reste une somme.Mais il manque les éléments qui a priori ne coute pas plus de temps ou d'argent mais qui peuvent être génant quand on héberge.
Le bruit déjà. Pour le moment je n'ai pas la place pour mettre une machine qui tourne en permanence chez moi. Trop bruyant. Mais c'est un critère assez personnel, je pense que certaine personnes peuvent s'en accomoder.
La disponibilitée. C'est sur ça fait classe d'afficher un UpTime de 2 ans :-D. Mais le truc c'est qu'il ne faut pas avoir de coupure de courant/connexion entre temps. Ne pas se prendre les pieds dans le fil, que le chat ne mange pas la prise. Et surtout laissé tourner la machine pendant qu'on est en vacances... Je fais parti des gens qui coupe toute l'électricité et l'eau quand ils partent en vacances. Encore une fois c'est un critères très personnel.
La bande passante. Je ne pense pas avoir des "tétra chier" (j'adore cette expression) de visiteurs, mais c'est toujours désagréable de mettre du temps pour accéder à un site, et puis ça jouerais aussi sur mon utilisation quotidienne... Alors les zones dégroupés avec gros débits c'est bien, mais c'est pas partout ;-). Encore un critère personnel.
Finalement j'en arrive à une conclusion que j'ai en tête depuis un moment: je vais prendre une dédibox. Suis-je pret à payer 70 euros /mois (au lieu de 30 euros aujourd'hui) ?
Je crois que mon compte en banque le l'autorise, il me reste plus qu'a franchir le cap, la barrière psychologique, de dépenser de l'argent pour avoir une machine supplémentaire en location et distante, car finalemetn c'est ça la dédibox: Une machine de location distante ;-)
Conclusion Général
D'un point de vue plus général je crois que la différence est assez faible.Il y a le point financier, mais il faudrais prendre en compte l'étude sur plusieurs année (ce qui est délicat en informatique) car je pense que le serveur d'hébergement à besoin d'évoluer parfois, ne serait-ce qu'en matériel. Et c'est un coup zéro pour un hébergement distant (on change d'ofrfe, voir elle évolue) alors qu'a la maison faut aller racheter des pièces.
Donc en gros, si c'est une question de moyen financier, autant essayer d'héberger sur une petite machine maison, avec du bricolage maison. C'est valable aussi pour ceux qui veulents justement s'amuser avec une machine à la maison, la bichoner, avec un gros uptime, ou tout simplement apprendre à le faire.
Pour ceux sans problème financier (disons pas à 100 euros pret de retirer à la fin du mois), qui n'ont pas envie de passer du temps à bichoner une machine, je conseillerais une dédibox, ou tout autre solution d'hébergement type serveur dédié ou virtuel.
la voie de la passion: Aller courage... prend ta carte bleu
la voie de la raison: Nons attend réfléchi un peu, est-tu sur d'en avoir besoin ? attend unpeu, y'a surement d'autres option
la voie de la passion: La carte ! c'est facile c'est rapide tu sentiras rien ... aller !!!
Serveur dédié: Dédibox ? Autres ? 6
Ca fait quelque mois que je me pose la question. Est-ce que je doit prendre un serveur dédié ?
Juste pour mon blog c'est clair que c'est pas la peine, mais j'aimerais mettre certaine bricole à disposition, et en gérer un peu l'historique par le biais d'un SubVersioN ou d'un CVS (hmm tiens encore un choix qu'il faudras faire :) ). J'aimerais aussi tester certaine bricole en Ruby, pourquoi ma developper certain service, bref, des activité qui nécessite d'avoir un accès plus poussé qu'un simple FTP.
Le problème majeur c'est le tarif ! c'est tout de suite autres chose, disons que c'est le tarif du mutualisé mais par mois au lieu de par an :-/
En mettant de coté l'aspect financié, il y a plusieurs options interessante. La dédibox semble interessante, un accès root, la possibilité d'installer un OpenBSD (bon c'est pas dans les installation par défaut, mais c'est faisable ;-) ). D'autres Serveur Dédié Virtuel chez 1and1 semble interessant, mais plus cher que la dédibox pour un service un peu en dessous.
Une autre option prise par certain est d'avoir un serveur à la maison... même si je pense que ça me plairait à mettre en place, ça me saoulera très vite de l'administrer... Et puis la bande passante... c'est une option que j'ai rejeté.
Et comme pour beaucoup de chose, la possibilité d'abstinence. Bon pour un serveur online, c'est faisable contrairement à d'autres truc ;-).
Bref, je suis dans le flou depuis 3 mois, je ne n'arrive pas à me décider. C'est horrible ! A force de voir des gens mettre en place des dédibox (prendreuncafé,un groupement d'éponge activiste y'a un moment...) , je vais craquer :)
Edit: J'oubliais l'option hebergement chez un ami à titre gracieux :) mais je me demande si ça ne peut pas créer des conflits. "Quoi tu déconne ton chat à débranché le serveur et il est resté down pendant toute ta semaine de vacances !!! "

