echo 'logie';

Serveur Dédié: Envoyer des emails

Neck — Sun, 16 Mar 2008 22:45:00 +0100

Avec la configuration actuelle, notre serveur effectue quotidiennement un certain nombre d'actions de maintenance. Le problème est que leurs résultats sont stockés sur le serveur lui-même, rendant la récupération fastidieuse.

Une solution consiste à les envoyer par email. Pour ce faire nous avons deux possibilités, soit un véritable serveur d'envoi (SMTP), soit un programme qui relaie les demandes.

Mon choix s'est porté, du moins pour le moment, sur la deuxième solution. En effet, installer et configurer un serveur SMTP complet semble être relativement complexe, et mal le faire c'est risquer de voir son serveur transformé en usine à spam. J'y repenserai peut-être une fois les choses plus urgentes finies.

Installation

Le programme qui va se charger de faire suivre les emails est msmtp, il est aussi possible de se tourner vers esmtp ou numailer (non testés). Je conseil d'installer également les certificats qui permettrons d'utiliser une connexion sécurisée.

# apt-get install msmtp ca-certificates

Configuration

Étant donné que msmtp ne fait que transmettre plus loin, il nécessite un serveur d'envoi comme destination finale. J'ai pour ma part utilisé l'une des cinq adresses que Gandi offre par domaine, cependant n'importe quel service permettant un accès SMTP peut convenir.

On créer le fichier de configuration:

# nano /etc/msmtprc

# Configuration par défaut.
account default

# Adresse de provenance pour le serveur smtp.
# Cette dernière n'appairait pas dans l'email final mais l'envoi sera normalement refusé si elle est erronée.
from <votre adresse>@<votre domaine>

# Serveur smtp à utiliser.
# Hôte, par exemple mail.gandi.net.
host <serveur smtp>
# Port à utiliser.
# 25 par défaut (587 pour Gandi en mode sécurisé).
port <port>
# Le domaine du serveur, par exemple eikylon.net.
domain <votre domaine>

# Authentification activée
auth on
# Nom d'utilisateur à utiliser pour la connexion.
# Généralement <votre adresse>@<votre domaine>.
user <utilisateur>
password <mot de passe>

# Pour utiliser une connexion sécurisée sinon remplacer par "off".
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt

# Utiliser /var/log/msmtp.log plutôt que les log systèmes.
logfile /var/log/msmtp.log
syslog off

Ensuite on créer le fichier de log et on permet aux gens d'y écrire.

# touch /var/log/msmtp.log
# chmod o+w /var/log/msmtp.log

À propos des mesures anti-spam

Si vous envoyez un email minimal maintenant il est probable que vous ne le receviez jamais.
Car si la configuration est bonne, le message lui ne contiendrait pas assez d'informations. Du coup il aurait de très fortes chances de ne pas passer à travers les mesures anti-spam (que ce soit lors de l'envoi ou de la réception).

D'après mon expérience, afin que tout se passe correctement, il faut au moins renseigner les entêtes "From" et "To". Ces derniers sont ajoutés au début du message sous la forme Nom: Valeur. Ils sont séparé entre eux par un retour à la ligne, pour noter le début du message on double ce retour.

Tester l'installation

Voici une commande qui vous permet de faire un test en tenant compte des considérations du point précédent:

// L'adresse d'envoi est celle renseignée dans la configuration, l'adresse de destination est libre.
// Noter l'option "-t" qui demande à msmtp de lire l'entête "To" pour trouver le destinataire.
$ echo -e 'From: <adresse d'envoi>\r\nTo: <adresse de réception>\r\nSubject: Test\r\n\r\n Ceci est un message de test' | msmtp -t

Utilisation

Si le test est concluant, on peut modifier les commandes dans le cron afin qu'elles déclenchent l'envoie d'un mail.

// Effectuer cette commande en tant qu'administrateur,
// sans quoi le cron n'aura pas les droits nécessaires.
# crontab -e

# Mises à jour, à la place de:
# 30 5 * * * (apt-get update -qq && apt-get upgrade -y -q) > /var/log/update.log
30 5 * * * (echo -e 'From: <adresse d'envoi>\r\nTo: <adresse de réception>\r\nSubject: Mises à jour\r\n\r\n'; (apt-get update -qq && apt-get upgrade -y -q)) | /usr/bin/msmtp -t
# Chkrootkit, à la place de:
# 35 5 * * * chkrootkit > /var/log/rootkit.log
35 5 * * *  (echo -e 'From: <adresse d'envoi>\r\nTo: <adresse de réception>\r\nSubject: Chkrootkit\r\n\r\n'; chkrootkit) | /usr/bin/msmtp -t

Références

MarcArea.com: Envoyer des emails avec Gmail via PHP et msmtp (msmtp).

Groupes Gandi: Installation serveur SMTP sur hébergement (serveur SMTP complet).
Documentation Ubuntu Francophone: serveur mail (serveur SMTP complet).

Site officiel de msmtp.

Sommaire | Dernière modification le 16 mars 2008

Alsacréations: tutorial et question dans la FAQ

Neck — Sat, 08 Mar 2008 14:38:00 +0100

En retard (qui a dit comme d'hab...), deux publications chez Alsacréations:

Négociation de contenu, explication du mécanisme de la négociation et exemple pratique en php.
Ma page/mon code source commence par ï»¿ de quoi s'agit-il ?, le problème du BOM en utf-8.

Serveur Dédié: Sécurité

Neck — Sun, 02 Mar 2008 13:06:00 +0100

La distribution en place, il est temps de s'assurer que des indésirables ne puissent pas y mettre leur grain de sable.

Connexion SSH

On se connecte à son serveur avec SSH, il vaut mieux modifier la configuration par défaut:

# nano /etc/ssh/sshd_config

Remplacer le port par défaut part un autre, préférer un nombre au dessus de 10000 pour éviter d'interférer avec d'autres services.

Port 22 -> Port <port>

Interdire l'authentification directe de l'administrateur. Cela devrait déjà être le cas sur la distribution de Gandi mais la mise à jour peut avoir altéré le fichier.

PermitRootLogin Yes -> PermitRootLogin No

Autoriser uniquement notre utilisateur. Cette directive n'existe pas, ajoutez-la en fin de fichier. Le nom est celui utilisé lors de la connexion ssh.

AllowUsers <nom>

Limiter le nombre de connexion simultanées. Décommenter et modifier la ligne:

MaxStartups 3:30:10

Le comportement est le suivant: au delà de 3 connexions non authentifiées, il y a 30% d'échec; ce taux augmente jusqu'à atteindre 100% pour 10 connexions.

Tout ceci enregistré il reste à redémarrer SSH.

# /etc/init.d/ssh restart

Facultatif

Quelques options supplémentaire qui peuvent être ajoutées.

Désactiver la possibilité d'utiliser X11 (mode graphique). C'est inutile pour un serveur donc autant l'enlever.

X11Forwarding Yes -> X11Forwarding No

Mettre un message de bienvenue amical et chaleureux, décommenter la ligne:

Banner /etc/issue.net

Ensuite il faut écrire ledit message.

# nano /etc/issue.net

Voici un exemple tiré de la documentation Ubuntu Anglophone.

***************************************************************************
                            NOTICE TO USERS


This computer system is the private property of its owner, whether
individual, corporate or government.  It is for authorized use only.
Users (authorized or unauthorized) have no explicit or implicit
expectation of privacy.

Any or all uses of this system and all files on this system may be
intercepted, monitored, recorded, copied, audited, inspected, and
disclosed to your employer, to authorized site, government, and law
enforcement personnel, as well as authorized officials of government
agencies, both domestic and foreign.

By using this system, the user consents to such interception, monitoring,
recording, copying, auditing, inspection, and disclosure at the
discretion of such personnel or officials.  Unauthorized or improper use
of this system may result in civil and criminal penalties and
administrative or disciplinary action, as appropriate. By continuing to
use this system you indicate your awareness of and consent to these terms
and conditions of use. LOG OFF IMMEDIATELY if you do not agree to the
conditions stated in this warning.

****************************************************************************

Chez le Client

Pour utiliser un port différent lors de la connexion on utilise "-p":

$ ssh <nom>@<ip du serveur> -p <port>

Il est aussi possible de l'enregistrer dans la configuration locale:

$ nano ~/.ssh/config

Ajouter:

# Mon serveur dédié
Host <ip du serveur>
Port <port>

Iptables

Les noyaux Linux actuels possèdent un module appelé Netfilter qui agit, en autre, comme un pare-feu. La configuration se fait avec Iptables. Tout d'abord l'installer:

# apt-get install iptables

Précaution

Manipuler le pare-feu implique de restreindre les accès extérieurs, or la connexion ssh qui permet l'administration en fait partie. Je vous laisse imaginer qu'une mauvaise manipulation peut avoir de fâcheuses conséquences. Par précaution, il est possible de ménager une issue de secours, elle consiste en une tâche cron qui va supprimer toutes les règles d'Iptables après un certain temps:

// Effectuer cette commande en tant qu'administrateur,
// sans quoi le cron n'aura pas les droits nécessaires.
# crontab -e

Ajouter deux commandes qui nettoieront la configuration d'iptables à <heure>:<minute>. Utiliser date pour obtenir l'heure courante du serveur et y ajouter 10 minutes par exemple.

# m h  dom mon dow   command
<minute> <heure> * * * /sbin/iptables -F; /sbin/iptables -P INPUT ACCEPT

En cas d'erreur la configuration sera remise à zéro, évitant de se retrouver coincé dehors.

Configuration

La logique est la suivante: interdire puis autoriser au compte-goutte.

// Faire le ménage par le vide
# iptables -F
# iptables -X

// accepter le trafic d'une connexion ouverte
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

// accepter le trafic local
# iptables -A INPUT -i lo -j ACCEPT
# iptables -A INPUT -s <ip du serveur> -j ACCEPT

// accepter le trafic du web (http)
# iptables -A INPUT -i eth0 -d <ip du serveur> -p tcp --dport 80 -j ACCEPT

// accepter le trafic ssh, utiliser le port choisi ci-dessus
# iptables -A INPUT -i eth0 -d <ip du serveur> -p tcp --dport <port ssh> -j ACCEPT

// refuser et log tout le reste
# iptables -A INPUT -j LOG --log-prefix 'Iptables denied: '
# iptables -P INPUT DROP
# iptables -P FORWARD DROP

Sauver tout ça

Le problème est que la configuration d'Iptables est remise à zéro à chaque redémarrage. Nous allons pallier à ceci avec l'aide d'un petit script maison.

# nano /etc/init.d/iptables

Le fichier ne doit pas exister, sinon choisir un autre nom. Ce dernier ouvert, y écrire:

#! /bin/sh
# Restaurer et sauver la configuration d'Iptables
case "$1" in
        # sauver
        "save" )
                echo "Sauvegarde de la configuration d'Iptables."
                iptables-save > /etc/iptables
        ;;
        # restaurer
        "start" | * )
                echo "Restauration de la configuration d'Iptables."
                iptables-restore < /etc/iptables
        ;;
esac
exit 0

Ensuite utiliser le script pour régler notre problème.

// Donner les droits d'exécution.
# chmod +x /etc/init.d/iptables
// Enregistrer la configuration actuelle d'iptables
# /etc/init.d/iptables save
// Demander l'exécution du script au démarrage
# update-rc.d iptables defaults

C'est fini, votre configuration sera restaurée automatiquement au démarrage. Au cas ou vous la modifiez, n'oubliez pas d'exécuter:

# /etc/init.d/iptables save

Ne pas oublier...

Avec une telle configuration le serveur ne répondra plus aux ping, c'est normal. Si vous souhaitez qu'il le fasse ajoutez:

# iptables -I INPUT 6 -i eth0 -d <ip du serveur> -p icmp --icmp-type 8 -s 0/0 -j ACCEPT

De plus les ports sont bloqués par défaut, il faut penser à les ouvrir en cas de besoin avec:

# iptables -I INPUT 4 -i eth0 -d <ip du serveur> -p tcp --dport <port> -j ACCEPT

Bloquer les attaques par force brute

Si vous laissez la configuration ssh telle quelle (à plus forte raison sur le port par défaut), vous ne tarderez probablement pas à enregistrer des milliers de tentatives de connexion. Il s'agit d'attaques par force brute, voici deux moyens de les bloquer, à vous de choisir.

Fail2Ban

Fail2Ban est un service qui analyse les logs et modifie la configuration d'iptables pour rejeter les curieux provoquant trop d'erreurs. Tout d'abord on l'installe.

# apt-get install fail2ban
// Désactiver le service pendant que l'on configure.
# /etc/init.d/fail2ban stop

Ensuite, on créer un fichier activant la surveillance de la connexion ssh.

# nano /etc/fail2ban/jail.local

# Configuration de fail2ban pour la connexion SSH.
[ssh]

# Activer le filtre.
enabled = true

# Utiliser notre version des interactions avec iptables
banaction = iptables-optimized

# Insérez ici le port que vous avez choisi pour ssh.
port =  <port>

# Politique appliquée:
# 3 essais en 10 minutes (600s) pour un ban de 20 min (1200s).
maxretry = 3
fintime = 600
bantime = 1200

Il reste une chose à faire, si vous regardez attentivement le fichier vous remarquerez qu'il est question de "notre version des interactions avec iptables". En effet les commandes utilisées par défaut peuvent être optimisées, nous créons donc un fichier avec les nouvelles.

# nano /etc/fail2ban/action.d/iptables-optimized.conf

Ne remplacez aucune valeur entre < et > dans le fichier ci-dessous, fail2ban s'en chargera à la volée.

# Réécriture optimisée des interactions avec iptables.
[Definition]
actionstart = iptables -N fail2ban-<name>
              iptables -I INPUT -p <protocol> --dport <port> -j fail2ban-<name>

actionstop = iptables -D INPUT -p <protocol> --dport <port> -j fail2ban-<name>
             iptables -F fail2ban-<name>
             iptables -X fail2ban-<name>

actioncheck = iptables -n -L INPUT | grep -q fail2ban-<name>

# Règles de bannissement créant une entrée dans les log d'iptables.
# Si ce ne'st pas souhaité, les commenter et les remplacer par celles en dessous.
actionban = iptables -A fail2ban-<name> -s <ip> -j LOG --log-prefix "Iptables denied (Fail2Ban): " --log-ip-options --log-tcp-sequence --log-tcp-options
            iptables -A fail2ban-<name> -s <ip> -j DROP

actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP
              iptables -D fail2ban-<name> -s <ip> -j LOG --log-prefix "Iptables denied (Fail2Ban): " --log-ip-options --log-tcp-sequence --log-tcp-options

# Version sans log.
# actionban = iptables -A fail2ban-<name> -s <ip> -j DROP
# actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP

[Init]
name = default
port = ssh
protocol = tcp

Une fois ceci en place fail2ban est prêt à monter la garde.

# /etc/init.d/fail2ban start
// Vérifier que tout marche.
# /etc/init.d/fail2ban status

Iptables

Iptables est également capable de bloquer ce genre d'attaque. Il suffit d'ajouter quelques règles à notre par-feu.

// <pos. ssh> est la position de la règle existante concernant ssh en partant du haut.
// Si vous avez utilisé la configuration proposée plus haut c'est 5.

// Lorsqu'une nouvelle connexion ssh est détectée, ajouter une entrée dans la liste "SSH".
# iptables -I INPUT <pos. ssh> -i eth0 -d <ip du serveur> -p tcp --dport <port ssh> -m recent --set --name SSH

// Si il existe déjà 4 entrées dans "SSH" par la même ip datant de moins de 1 minute refuser l'accès.
# iptables -I INPUT <pos. ssh> -i eth0 -d <ip du serveur> -p tcp --dport <port ssh> -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP

L'effet de ces règles est: s'il y a plus de 4 (hitcount) connexions en 1 minute (seconds) alors on refuse l'accès.
N'oubliez pas de les sauver.

# /etc/init.d/iptables save

Comparaison

Fail2Ban est légèrement plus compliqué à mettre en place et représente un service supplémentaire sur la machine. De plus il souffre d'un court temps de réaction dû au fait qu'il doit lire et analyser les log, ainsi il peut y avoir plus de requêtes qu'autorisées qui passent avant que le bannissement ne soit effectif. Cependant il permet une configuration très fine et ne se limite pas aux connexions ssh.
Iptables est simple et rapide à mettre en place, mais il traite indifféremment une tentative de connexion réussie et une ratée. Donc quatre connexions réussies en une minute (avec notre configuration) provoqueraient tout de même un rejet. Il faut également souligner que la configuration est basique et ne permet pas une gestion indépendante du temps de ban et du temps de détection.

Configurer IPv4

Nous allons modifier quelques options IPv4 qui pourraient être problématiques:

// Passer en mode root pour les commandes suivantes
$ sudo -s

// Activer les SYN cookies
# echo "1" > /proc/sys/net/ipv4/tcp_syncookies
// Activer la vérification de route
# echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
// Refuser les redirections
# echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
# echo "0" > /proc/sys/net/ipv4/conf/all/secure_redirects
// Loguer les "martiens"
# echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

// Retourner en mode utilisateur normal
# exit

Chkrootkit

Les rootkits sont des sortes de virus, ils n'ont donc rien à faire sur votre serveur. Chkrootkit est un petit utilitaire qui traque leur présence, l'installation et l'utilisation sont des plus simples:

// installer
# apt-get install chkrootkit
// utiliser
# chkrootkit

Automatisation

Vous l'aurez deviné il faut effectuer la chose régulièrement. Ajoutons donc une entrée au cron.

// Effectuer cette commande en tant qu'administrateur,
// sans quoi le cron n'aura pas les droits nécessaires.
# crontab -e

Ajouter à la fin du fichier.

# Vérifier la présence de rootkits tous les matins à 5h55.
55 5 * * * chkrootkit > /var/log/rootkit.log

Note: Il serait bien plus intéressant d'envoyer le résultat par mail, nous verrons comment procéder lors de l'installation d'un smtp.

Références

Prendre un Café: Sécuriser son Ubuntu Server (chkrootkit, fail2ban, ssh).
Fourre-tout.com: Installation Ubuntu Server - Chapitre 1 (IPv4, fail2ban, chkrootkit, ssh).
JujuSeb, Fail2Ban contre l'attaque par brute force.
Billyboylindien: Log ssh et bruteforce, iptables, interdire root.
Christian CALECA: Iptables.

MySecureShell: Sécurité (ssh).
Groupes Gandi: Changement du port SSH, Attention aux mots de passe! (ssh).
Documentation Ubuntu Francophone: ssh, Cron, Iptables, Shell.

The Art of Web: System: fail2ban and iptables.
MDLog:/sysadmin: Using fail2ban to Block Brute Force Attacks
nixCraft: Linux Iptables allow or block ICMP ping request.

Documentation Ubuntu Anglophone: Iptables, AdvancedOpenSSH.
Site officiel de Fail2Ban.

Apache Security, RISTIC Ivan, Ed. O'Reilly, 2005 USA, 380p (Anglais).

Sommaire | Dernière modification le 8 mars 2008

Serveur dédié: Ubuntu

Neck — Fri, 08 Feb 2008 21:13:00 +0100

Première connexion

L'administration du serveur se fait en mode console au travers d'une connexion ssh que l'on ouvre ainsi:

$ ssh <nom>@<ip du serveur>

Une fois le mot de passe entré vous serez connecté à votre serveur en tant qu'utilisateur <nom>.

Note: pour une sécurité optimale choisissez un mot de passe suffisamment compliqué (pour en changer utilisez la commande passwd) et fermez la connexion avec exit une fois que vous avez terminé.

Installer Nano

Il va falloir éditer pas mal de fichiers textes, dans le cas de la distribution de Gandi le seul éditeur à disposition par défaut semble être vim. Puissant mais loin d'être intuitif, je propose d'installer nano qui possède bien moins de fonctionnalités mais est nettement plus simple à utiliser.

$ su
// installer nano
# apt-get install nano
// le choisir comme éditeur par défaut
# export EDITOR=/bin/nano
# exit

Activer Sudo

Chose assez surprenante, la distribution fournie par Gandi ne propose pas le comportement habituel d'Ubuntu pour effectuer une action en tant qu'administrateur (sudo <commande>), au lieu de ça il faut utiliser su pour devenir root puis effectuer ce que l'on veut.
Je préfère sudo notamment parce qu'il me protège contre ma propre stupidité... voici comment l'activer:

// Devenir root.
$ su

// Ajouter votre utilisateur à un groupe de votre choix qui aura les privilèges administrateur.
# adduser <utilisateur> <groupe>

// Éditer la configuration de sudo (ne pas toucher directement le fichier).
# visudo

Dans le fichier à présent ouvert, ajouter ceci à la fin:

%<groupe>  ALL=(ALL) ALL

Enregistrer et quitter.

// Revenir à l'utilisateur de base.
# exit

// Tester sudo, ça devrait marcher.
// Sinon essayer de se déconnecter/reconnecter.
$ sudo <commande>

// Si le test est concluant verrouiller le compte root.
$ sudo passwd -l root

À présent il faut précéder toutes les commandes à exécuter en tant qu'administrateur de sudo.

Configurer et effectuer les mises à jour

Pour des raisons évidentes il vaut mieux garder le serveur à jour, Ubuntu fonctionnant sur le même principe que Debian, il faut d'abord configurer les dépots. Ils sont listés dans /etc/apt/sources.list, voici à quoi ressemble mon fichier après édition:

# nano /etc/apt/sources.list

# Miroirs par défauts proposés par Gandi
deb http://ubuntu.mirror.gandi.net/mirror/ubuntu/ubuntu gutsy main universe multiverse
deb http://ubuntu.mirror.gandi.net/mirror/ubuntu/ubuntu gutsy-security main universe multiverse
deb http://ubuntu.mirror.gandi.net/mirror/ubuntu/ubuntu gutsy-updates main

# Sources (ça peut toujours servir)
deb-src http://ubuntu.mirror.gandi.net/mirror/ubuntu/ubuntu gutsy main universe multiverse
deb-src http://ubuntu.mirror.gandi.net/mirror/ubuntu/ubuntu gutsy-security main universe multiverse
deb-src http://ubuntu.mirror.gandi.net/mirror/ubuntu/ubuntu gutsy-updates main

# Paquets DotDeb (dernières versions Apache, PHP, etc)
deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Le fichier modifié et enregistré, on met à jour le système:

// Mettre à jour les dépots
# apt-get update
// Mettre à jour les programmes installés
# apt-get upgrade

Automatisation

Vérifier les mises à jour doit être fait de manière régulière pour être utile. C'est pourquoi nous allons créer une tâche cron qui va le faire pour nous quotidiennement. Attention à bien lancer l'éditeur en tant qu'administrateur, il existe aussi un cron utilisateur mais il ne possède pas assez de droits pour cette utilisation.

# crontab -e

Ajouter à la fin du fichier.

# Mettre à jour le serveur tous les matins à 5h30.
30 5 * * * (apt-get update -qq && apt-get upgrade -y -q) > /var/log/update.log

Votre serveur est dorénavant tenu à jour automatiquement.

Note: En l'occurrence il pourrait être intéressant d'envoyer le résultat par mail afin de s'assurer que tout s'est bien déroulé, nous verrons comment faire ultérieurement.

Nettoyer les services

Les services sont des petits programmes qui tournent en permanence pour effectuer diverses tâches. Si certains sont bien utiles d'autre ne servent à rien, à part manger des ressources.
Il existe un petit utilitaire en ligne de commande qui permet leur gestion sysv-rc-conf:

// Installer sysv-rc-conf
# apt-get install sysv-rc-conf
// Exécuter sysv-rc-conf
# sysv-rc-conf

En l'occurrence je n'ai pas remarqué quoi que ce soit d'inutile, donc rien à modifier.

Se mettre à l'heure

Beaucoup de chose dépendent de l'heure, dès lors il est préférable que le serveur soit synchronisé avec un serveur d'horodatage. Une synchronisation prend la forme suivante:

# ntpdate pool.ntp.org

Cependant cela aura pour effet d'ajuster l'horloge une fois, il serait préférable d'en vérifier l'exactitude de temps à autre. Heureusement il existe un service pour ça:

# apt-get install ntp

L'installation va créer le fichier /etc/ntp.conf, ouvrez-le et cherchez la ligne Server ntp.ubuntu.com, nous allons la supprimer et la remplacer par les suivantes :

Server 0.fr.pool.ntp.org
Server 1.fr.pool.ntp.org
Server 2.fr.pool.ntp.org
Server 3.fr.pool.ntp.org

Pour finir on relance le service:

# /etc/init.d/ntp restart

Note: choisissez de préférence des serveurs géographiquement proches, voir liste de serveurs publiques.

Références

Fourre-tout.com: Installation Ubuntu Server - Chapitre 1 (mises à jour, synchronisation, services).

Groupes Gandi: Sudo ne marche pas.
Wiki Gandi: Se connecter à Gandi Expert (ssh), Installation de Apache 2.2, PHP 5.2 et MySQL 5.0 (dépots).
Documentation Ubuntu Francophone: Sudo, Cron, Services.

Sommaire | Dernière modification le 2 mars 2008

Serveur dédié: Introduction

Neck — Thu, 07 Feb 2008 17:53:00 +0100

Je vais exposer, à travers une série d'article, la mise en place d'un Serveur dédié. Ceux-ci sont en effet devenu beaucoup plus accessible au niveau du prix et les possibilités offertes sont sans comparaison avec celle d'un hébergement mutualisé.

L'offre

J'ai opté pour l'offre de Gandi, question de prix intéressants, d'accord avec leur philosophie et de flexibilité (bien que dans un premier temps je ne penses pas avoir besoin de ce dernier point).
Cependant c'est loin d'être la seule possibilité, on citera notamment OVH, Kimsufi, Dédibox, Lost-Oasis, Slicehost et j'en oublie des milliers. Un conseil: lisez attentivement la description des offres, elles sont souvent difficilement comparables. Ainsi certains hébergeurs proposent une bande passante de 100Mbs mais limitent le trafique par mois, d'autres exigent un préavis de 3 mois avant résiliation, etc.

Au niveau de la distribution, celle retenue est Ubuntu Gusty (version serveur), à cause d'une certaine expérience avec ce système principalement.

Conventions

Quelques truc pour comprendre les exemples donnés aux travers de ces articles:

Les commandes sont précédées d'un dièse ou d'un dollar. Il s'agit des droits requis pour les exécuter; $ pour utilisateur et # pour administrateur (root).
Les lignes précédées de // dans les listes de commandes et celles précédées de # dans les fichiers sont des commentaires.
Les valeur entre < et > sont à remplacer par celles adaptées à votre situation.

Sommaire

Références Générales

Documentation Ubuntu Francophone
Wiki Gandi: Utiliser Linux

Documentation Ubuntu Anglophone

Dernière modification le 17 mars 2008

En ligne \o/

Neck — Tue, 05 Feb 2008 21:53:00 +0100

Finalement, après moult retards, je me décide à activer ce blog.

Pour plus de détails concernant mes motivations, ma tronche et ce genre de choses je vous invite à lire la présentation. Au menu on pourra trouver des sujets en rapport avec mes centres d'intérêts, à savoir: science, informatique, lectures, etc...

On commence directement les hostilités avec une série d'articles à propos de la mise en place d'un serveur dédié. Expérience nouvelle pour moi que je tenais à consigner quelque part histoire de ne pas tout oublier, en somme un bon motif pour enfin débuter ce blog.

Désolé d'ouvrir avec un sujet aussi "violent", promis je ferai aussi des choses moins spécialisées/geek.

NB: les quelques articles déjà publiés sont antidatés afin de correspondre à l'évènement présenté.
NB2: le design n'est pas de moi, j'en ferai un... un jour.

Quiz sur Alsacréations

Neck — Tue, 06 Nov 2007 20:16:00 +0100

Publication aujourd'hui d'un quiz php sur Alsacréations. Le niveau est supposé difficile, à vous de juger.

Article dans la FAQ d'Alsacréations

Neck — Thu, 11 Oct 2007 12:00:00 +0200

Publication aujourd'hui d'un article dans la FAQ d'Aslsacréations à propos du choix de l'encodage d'un document.