tyPouypOblOg

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 ;-)

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 ;-) ).

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 !!

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

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