Blaise Braye, IT Edition

Aller au contenu | Aller au menu | Aller à la recherche

mardi, 13 novembre 2007

Configurer SMTP SendMail chez télé2

Et oui, je fais partie des malheureux qui doivent vivre avec le service misérable qu'offre télé2. Je viens de passer plusieurs jours assez difficiles à configurer mon serveur de tests. La configuration du serveur de mail étant l'une qui m'a pris le plus de temps; sans doute pour le simple fait que je ne savais pas trop ce que j'avais à faire. Aujourd'hui, je suis enfin parvenu à une configuration qui me suffit, sans aucune sécurité mais qui me permette d'envoyer des e-mails via apache ou autre.

Sur linuxquestions.org se trouvent la documentation dont je me suis servis.

Je me suis assuré premièrement que sendmail et sendmail-cf étaient installés. Le premier est donc le serveur de mail et le second nous permettra de "compiler" les fichiers de configuration de sendmail avec l'outil m4.

[Bash]
sudo yum install sendmail sendmail-cf

Sur ma configuration actuelle sont donc installés les packages suivants:

  • sendmail - 8.14.1-4.2.fc7.i386
  • sendmail-cf - 8.14.1-4.2.fc7.i386

La seconde étape est de configurer le fichier contenant les informations de connexion à télé2. J'ai donc du me munir d'un nom d'utilisateur "xxxxx@versatel.be" et de votre mot de passe (il a donc bien fallut retrouver ces fichus papier qui ne dataient pas d'hier). Tout est fait en tant que root ici, ce fichier aura une restriction maximum, ce qu'on peux comprendre vu que le mot de passe y apparaitra en clair.

[Bash]
#mkdir /etc/mail/auth
#chmod 600 /etc/mail/auth
#cd /etc/mail/auth
#touch client-info

Ensuite, j'édite, avec des droits de super utilisateur toujours le fichier /etc/mail/auth/client-info

[Bash]
AuthInfo:smtp.tele2.be:587 "U:smmsp" "I:USERID@versatel.be" "P:8PASSWORD" "M:LOGIN"
AuthInfo: "U:USERID@versatel.be" "P:PASSWORD" "M:LOGIN"

A la place de USERID et PASSWORD se trouvent donc mon login et mon mot de passe associé de chez télé2.

En ce qui concerne ce fichier, il ne me restait plus qu'à générer un fichier .db

[Bash]
#makemap -r hash client-info.db < client-info

Il ne restait plus qu'à configurer sendmail en éditer /etc/mail/sendmail.mc toujours en tant que root

[Bash]
dnl define(`SMART_HOST', `smtp.your.provider')dnl

devient

[Bash]
define(`SMART_HOST', `[smtp.tele2.be]')dnl

et au dessus de

[Bash]
FEATURE(`no_default_msa', `dnl')dnl

J'ai ajouté la référence au fichier que j'ai généré un peu plus haut pour les informations d'authentification.

[Bash]
FEATURE(`authinfo',`hash -o /etc/mail/auth/client-info.db')dnl%%%

Avant de lancer le serveur, une dernière étape, générer /etc/mail/sendmail.cf

[Bash]
#cd /etc/mail
#m4 sendmail.mc > sendmail.cf

Et enfin lancer le serveur.

[Bash]
sudo service sendmail start

A présent, tout client de la machine pourra envoyer des email via sendmail; la configuration télé2 n'étant rien de plus qu'un relai, et nécessaire. J'ai remarqué qu'il était possible d'envoyer des e-mail à certaines personnes sans faire ces manipulations mais il semble que tous les serveurs ne l'acceptent pas.

jeudi, 8 novembre 2007

XAMPP un kit serveur tout en un

En matière de kits de déploiements de serveurs, gratuits, rapides à mettre en place et utilisables en quelque étapes, je connaissais jusqu'à ce jour deux outils:

Vient dorénavant s'ajouter à ma panoplie un kit que je qualifierai de bien meilleure qualité: XAMPP

La philosophie sous-jacente à XAMPP est de construire un kit facile à installer afin d'inciter les développeurs à entrer dans le monde d'Apache. Pour plus de commodité, toutes les fonctionnalités sont activés par défaut dans XAMPP.

La configuration par défaut ne convient pas au point de vue sécurité et n'est pas assez sécuritaire dans un environnement de production -- veuillez ne pas utiliser XAMPP dans un tel environnement.

Depuis LAMPP 0.9.5 vous pouvez sécuriser votre installation de XAMPP en utilisant "/opt/lampp/lampp security".


Conclusions

J'ai été un féru utilisateur des deux outils précités mais celui-ci dépasse tout ce que je pouvais attendre en matière de fiabilité, de facilité et d'organisation cohérente des fichiers. Un site web accueillant, une interface prévue pour une panoplie intéressantes de plateformes, le tout fonctionnant du premier coup avec les dernières technologies associées intégrées de base.

A première vue, je ne peux que trop le conseiller.

mercredi, 7 novembre 2007

NTFS-3G Régler les droits d'écriture

Alors que je manquais de place sur mes partitions linux, j'ai voulu commencer à me servir des partitions ntfs pour travailler. Je me suis alors rendu compte que l'accès en écriture était limité à root, ce était seul propriétaire des partitions montées.

J'avais suivi le tutoriel sur le wiki de fedora pour les installer etçà donnait ces quelques lignes supplémentaires dons mon /etc/fstab :

/dev/sda1		/windows/System		ntfs-3g	silent,umask=0022,utf8=true
/dev/sda5		/windows/Programs	ntfs-3g	silent,umask=0022,utf8=true
/dev/sda6		/windows/Datas		ntfs-3g	silent,umask=0022,utf8=true

Dans cet état des choses, les partitions sont montées avec root en propriétaire des partitions montées. Je suis vite tombé sur un très bon tutoriel qui explique à merveille comment s'en sortir avec mount.

Après lecture entre les lignes, j'ai vite compris qu'il me fallait connaître le uid et le gid de mon compte utilisateur,

[Bash]
[Blaisouille@Bujeman ~]$ cat /etc/passwd | grep Blaisouille
Blaisouille:x:500:500:Braye Blaise:/home/Blaisouille:/bin/bash

Il ne me restait plus qu'à modifier mon fstab en conséquence:

/dev/sda1		/windows/System		ntfs-3g	silent,uid=500,gid=500,umask=0002,utf8=true
/dev/sda5		/windows/Programs	ntfs-3g	silent,uid=500,gid=500,umask=0002,utf8=true
/dev/sda6		/windows/Datas		ntfs-3g	silent,uid=500,gid=500,umask=0002,utf8=true

Attention, il faut remarquer le umask qui a changé aussi. en effet, le umask proposé par défaut fixe un chmod 755, ce qui empêche l'écriture à tout autre utilisateur que root. alors que le second umask fixera un chmod 775.

man umask | chmod

yum : Cannot retrieve repository metadata (repomd.xml)

Aujourd'hui, en voulant installer un logiciel supplémentaire via le gestionnaire; cela me fut refusé par un crash de l'application; vive la stabilité!! il semble que l'erreur se propageait à la suite d'un time out.

Pour avoir le cœur net sur la situation, je suis passé en console:

[Bash]
# yum update
http://linuxdownload.adobe.com/linux/i386/repodata/repomd.xml: [Errno 4] IOError: <urlopen error (-2, 'Nom ou service inconnu')>
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: adobe-linux-i386. Please verify its path and try again

Le message est déjà plus clair par ici, yum me demande d'essayer d'autres miroirs, il semble incapable de faire le travail comme un grand... Soit, faisons le travail pour lui, que puis-je voir d'autre comme info dans ce message?

Cannot retrieve repository metadata (repomd.xml) for repository: adobe-linux-i386

On se rapproche, en console je vais voir la liste des dépôts de yum:

[Bash]
[Blaisouille@Bujeman ~]$ cat /etc/yum.conf
# This is the fedorafaq.org yum.conf for Fedora Core 5.
#
# Note that you also need the rest of the configuration
# as described at http://www.fedorafaq.org/#yumconf
[main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=1
exactarch=1
obsoletes=1
# Don't check keys for localinstall
gpgcheck=0
plugins=1
metadata_expire=1800
# Changed this because some mirrors go down and then
# re-trying takes forever.
timeout=7


# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

Apparemment, ce n'est pas là que çà se passe... pas si sur!!

Regardons de plus près les deux dernières lignes, il doit certainement y avoir des fichiers de dépôts dans /etc/yum.repos.d/

[Bash]
[Blaisouille@Bujeman ~]$ ls /etc/yum.repos.d/
adobe-linux-i386.repo    fedora-updates.repo          livna.repo
fedora-development.repo  fedora-updates-testing.repo  livna-testing.repo
fedora.repo              livna-devel.repo

tiens tiens... le premier fichier me rappelle quelque chose :
Cannot retrieve repository metadata (repomd.xml) for repository: adobe-linux-i386

Si adobe ne sait pas me fournir un service fiable, et bien qu'ils aillent voir ailleurs si j'y suis: byebye adobe!!

[Bash]
[Blaisouille@Bujeman ~]$ sudo rm adobe-linux-i386.repo 

je teste un yum update, tout va bien; et du côté du gestionnaire graphique? comme un charme!

un problème réglé vite fait bien fait... la question reste: à quant un yum capable de gérer ce genre de problèmes? problèmes qui d'après moi peuvent arriver en permanence à tout dépôts quel qu'il soit, pourquoi continuer à faire croire à yum que Internet est scalable? il est certes plus fiable qu'il y a 20 ans mais nul n'est à l'abri d'un serveur saturé, de réseaux overflowdés, de routeurs congestionnés,... à quand un super dépôt p2p?

Une question que je me posais il y a déjà quelques années, époque où j'ai vite abandonner l'idée que linux serait mon ami d'ailleurs.

Aujourd'hui bien des choses ont changé mais ce défaut semble être resté, dommage. Est-ce moi qui m'en sert mal? Il faudra que je me penche là dessus, c'est évident.

mardi, 6 novembre 2007

Mise à jour du kernel

Dans un post précédent, je me retrouvais bien embêté avec le dernier noyau que je venais de mettre à jour... ce matin après ma surprise du kernel panic, j'ai droit à une seconde surprise; une mise à jour qui fixe des bugs du kernel 2.6.23.1-10.fc7-i686 (celui qui posait des soucis donc)...

je installe cette mise à jour (il s'agit de la version 2.6.23.1-21.fc7-i686 du kernel) et aujourd'hui il se porte comme un charme..

EDIT Fausse joie, le problème a juste été reporté... au lieu d'attendre une à deux minutes, je dois en attendre une dizaine avant un plantage des irq comme précédemment... décidément ils m'aiment pas les derniers kernels...

- page 2 de 3 -