En fait c’est un noyau préparé par OVH qui contient les derniers patchs de sécurité et qui permet de se passer de modules externes car ils sont embarqués. Problème: quand j’ai voulu upgrader ma distrib de Etch à Lenny, j’ai eu énormément d’ennuis et j’ai dû faire appel à un ami spécialiste pour me dépatouiller.

Le premier problème a été Lilo: il a commencé à me mettre des warnings pendant la mise à jour. Comme je n’étais pas sûr des conséquences que cela aurait au reboot et vu que Lilo commence sérieusement à dater, on a décidé de mettre Grub, et là tout est parti en vrille, ce qui n’aurait pas été le cas si j’avais eu un noyau standard… En effet d’une part Grub se base sur le nom d’un noyau standard pour s’installer, ce qui n’était pas le cas. La config de grub ne n’est donc pas faite correctement. On s’est donc dit que dans ce cas, on allait donner à Grub ce qu’il voulait, c’est à dire un noyau standard. Sauf que la il va aussi falloir gérer les modules à la main. En plus de cela le serveur était en raid1 logiciel, ce qui nécessite une maipulation supplémentaire avec Grub.

On va donc essayer à travers cet article de remettre la distribution droite dès le départ étant donné que le serveur dédié sur lequel je refais cette expérience est neuf.

La première chose à faire est de récupérer toutes les informations nécessaires sur notre hardware, notre architecture, le raid logiciel, etc…

Déjà, grâce au nom du noyau on sait que l’on est sur une architecture 64 bits.

Pour le hardware, on a besoin de savoir quel est le processeur que nous avons, ainsi que la ou les cartes réseaux.  Pour le processeur, on va faire un :

> vi /var/log/dmesg

puis on va faire une recherche sur « Intel ». Déjà je peux noter les infos suivantes:

CPU0: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz stepping 0a

Bon, première info… Le truc à savoir avec l’architecture 64 bits, c’est que quel que soit votre processeur (AMD ou Intel), vous devrez installer un noyau AMD64. On peut le voir à cette adresse: http://www.debian.org/ports/amd64/

Le portage se compose d’un noyau pour tous les processeurs AMD 64 bits avec l’extension AMD64 et pour les processeurs Intel avec l’extension EM64T et d’un espace utilisateur 64 bits commun.

Bref, si je fais un

> apt-cache seach 'linux-image'

je tombre sur ce noyau :  » linux-image-2.6.26-2-amd64 – Linux 2.6.26 image on AMD64″

C’est celui-là qu’il nous faut.

En ce qui concerne la carte réseau, dans un premier temps on a besoin de savoir combien on en a. Pour cela un petit

> ifconfig

M’indique qu’il n’y a que et0 et lo (qui est l’interface locale). Donc je n’ai qu’une carte. Pour m’assurer des modules nécessaires à ma carte réseau, j’ai trouvé en parcourant les forums un truc plutôt pas mal. Tapez la commande:

> lspci -n

Et copiez le contenu du résultat dans le textarea de ce site: http://kmuto.jp/debian/hcl/

Il vous donnera le nom des modules à charger. Dans mon cas c’est donc le module r8169 dont j’ai besoin

Enfin on finit par vérifier si on est en raid ou pas. En tapant :

> cat /proc/mdstat

j’obtiens:

md1 : active raid1 sdb1[1] sda1[0]
5245120 blocks [2/2] [UU]

md2 : active raid1 sdb2[1] sda2[0]
970992576 blocks [2/2] [UU]

Donc je sais que je suis en raid1 sur deux disques serial ATA (sda et sdb).

On a tout ce qu’il faut pour se lancer. C’est parti:

On installe grub en premier (en effet notre noyau standard a besoin de grub pour s’installer sinon on a une erreur).

> apt-get install grub

On crée le répertoire de grub dans le répertoire de boot :

> mkdir /boot/grub

On fait une première install de grub. Je suis pas sûr que cette étape soit nécessaire, je vérifierai cela lors de ma prochaine installation de dédié

> grub-install /dev/md1

On installe notre noyau :

> apt-get install linux-image-2.6.26-2-amd64

On installe grub :

> grub-install /dev/md1

On demande une mise à jour de grub

> update-grub

Le problème maintenant c’est qu’on est sur du raid logiciel. Notre disque /dev/md1 n’est donc pas physique mais virtuel. Et le souci c’est que notre grub-install ne va pas s’inscrire sur le secteur de boot de sda et sdb. Il faut donc faire cette manipulation manuellement :

> grub
grub> root (hd0,0)
grub> setup (hd0)
grub> setup (hd1)
grub> quit

Il ne faut pas oublier de le faire sur les deux disques dur, ainsi si un des disques crash, le deuxième sera bootable.

Avant de rebooter, ne pas oublier les modules de la carte réseau ! Dans /etc/modules rajouter:

loop
r8169

et sauvegardez..

En demandant conseil à mon pote pour réaliser toutes ces manipulations en sécurité, il m’a dit qu’on avait eu un problème au niveau du package « mdadm » qui est le package gérant le raid. En effet, lors de notre expérience malheureuse, il s’est rendu compte que ce paquet n’était pas installé, le noyau d’OVH embarquant ce dont il a besoin pour le faire fonctionner. En ce qui me concerne sur ce nouveau serveur, le package est bien présent mais n’hésitez pas à vérifier et à l’installer le cas échéant sinon vous aurez une surprise au reboot !

Vous pouvez y aller maintenant.

> reboot

et croisez les doigts…

N’hésitez pas à me faire part de vos expériences sur le sujet, mes connaissances sur le sujet étant modestes, il se peut qu’il y ait des erreurs ou des choses à améliorer.

http://blog.fabroce.info/post/2006/11/19/Installer-un-depot-subversion-sur-une-Debian
http://blog.utopiaz.org/2008/04/mise-en-place-svn-et-virtual-hosts-apache/

Son but est de mettre en place un serveur subversion sur une Debian permettant la gestion de plusieurs dépôts avec une gestion des droits différente selon les dépôts.

Installation des packages:

> apt-get install subversion subversion-tools libapache2-svn

Création du répertoire subversion:

> mkdir /home/svn
> chmod 770 /home/svn

Création des différents dépôts (gestion multi-projets)

> svnadmin create /home/svn/projet_1
> svnadmin create /home/svn/projet_2

On crée un fichier qui contient les utilisateurs / mots de passe qui auront accès au dépôt.

> touch /home/svn/.passwd

Ce fichier fonctionne pour la sécurisation d’un répertoire par htaccess. Par exemple:

toto:$1$uH5.fe0.$4aTxZL9kZTHrjyemyJCBL1
hubert:$1$6I5.VG5.$rOl1m.o6bcZLhkKUZStWf/

On crée un fichier qui va contenir tous les droits d’accès des utilisateurs aux différents projets

> vi /home/svn/.authz

La syntaxe de ce fichier n’est pas extrêment compliquée. Elle va ressembler à cela:

[nom_du_depot:/répertoire/dans/depot]
nom_utilisateur = droits_accès

Soyons bien clairs sur la syntaxe entre crochet: le nom du dépôt correspond au nom du répertoire créé grâce à svnadmin create. Donc pour nous ce sera soit projet_1, soit projet_2. Le répertoire qui suit les deux points est le répertoire relatif au dépôt. Voici quelques exemples expliquant ce point:

# correspond au répertoire /home/svn/projet_1/
[projet_1:/]

#correspond au répertoire /home/svn/projet_1/images/
[projet_1:/images]

Prenons un exemple avec ce que nous avons fait plus haut:

[projet_1:/]
toto = rw
hubert = r

Dans cet exemple, l’utilisateur toto peut lire et écrire dans le dépôt projet_1. Par contre hubert ne peut que lire ce dépôt. Voici d’autres exemples:

[projet_1:/]
toto = rw
hubert = r

[projet_1:/readonly]
toto = r

[projet_2:/]
toto = r
hubert =

Dans cet exemple, on a rajouté des paramètres importants:

• toto peut lire et écrire dans le dépôt projet_1 mais ne peut que lire le répertoire readonly du projet_1
• hubert ne peut que lire le projet_1
• toto peut seulement lire le projet_2
• hubert n’a pas accès au projet_2

Il est possible d’aller plus loin et de traiter les droits d’accès pour plusieurs utilisateurs en même temps:

[/]
* = r

Donne droit de lecture à tous les utilisateurs sur tous les dépôts. On peut également créer des groupes d’utilisateurs:

[groups]
mon-groupe-1 = toto, hubert
mon-groupe-2 = pierre, paul, jacques

[projet_1:/home/svn/projet_1]
@mon-groupe-1 = r
@mon-groupe-2 =

On voir que l’on fait appel à un groupe et non à un utilisateur à l’aide du @ devant le nom du groupe. Il est également possible de faire appel aux groupes à l’intérieur de la définition des groupes:

[groups]
mon-groupe-1 = toto, hubert
mon-groupe-2 = pierre, paul, jacques
tous-les-groupes = @mon-groupe-1, @mon-groupe-2

Enfin, à titre informatif, on peut également utiliser des références à des utilisateurs LDAP ou des certificats SSL et utiliser des alias. Personnellement je n’en ai pas eu besoin, donc je vais me contenter de copier bêtement les exemples que j’ai vu ici: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html. Si vous avez des infos complémentaires à ajouter, n’hésitez pas.

[aliases]
harry = CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com
sally = CN=Sally Swatterbug,OU=Engineers,DC=red-bean,DC=com
joe = CN=Gerald I. Joseph,OU=Engineers,DC=red-bean,DC=com

[groups]
calc-developers = &harry, &sally, &joe
paint-developers = &frank, &sally, &jane
everyone = @calc-developers, @paint-developers

On crée un répertoire pour les logs

> mkdir /home/svn/logs

On donne ensuite les droits à Apache

> chown -R www-data:www-data /home/svn

Configuration d’Apache

La solution classique consiste à configurer le fichier /etc/apache2/mods-available/dav_svn.conf. Par défaut tout est commenté dans ce fichier. Il va falloir décommenter, et configurer pour activer l’accès au dépôt SVN. Voici une configuration standard qui permet d’accéder au dépôt configuré plus haut:

<Location /svn>
    DAV svn
    SVNParentPath /home/svn
    AuthType Basic
    AuthName "Subversion Repository"
    AuthUserFile /home/svn/.passwd
    AuthzSVNAccessFile /home/svn/.authz
    Require valid-user
</Location>

Sauvegarder et relancer Apache.

Pour vérifier que tout fonctionne bien, il suffit d’aller avec votre navigateur à l’adresse:

http://IP_serveur/svn/projet_1

Si tout se passe bien, une identification vous est demandée, puis vous devriez voir une page avec marqué « Revision 0″.

Cette méthode fonctionne parfaitement, mais on peut faire mieux. Si vous gérez des noms de domaine sur votre serveur, vous pouvez tout à fait utiliser les VirtualHost pour gérer les adresses d’accès aux dépôts:

<VirtualHost *>
  ServerName svn.mondomaine.com

  <Location />
    DAV svn
    SVNParentPath /home/svn
    AuthType Basic
    AuthName "Subversion Repository"
    AuthUserFile /home/svn/.passwd
    AuthzSVNAccessFile /home/svn/.authz
    Require valid-user
  </Location>

  CustomLog /home/svn/logs/access.log combined
  ErrorLog /home/svn/logs/error.log
</VirtualHost>

Cette méthode présente plusieurs avantages:

• Utilisation d’un sous-domaine, ce qui simplifie l’url
• Possibilité d’utiliser plusieurs noms de domaine pour le même dépôt
• Customisation des logs
• Possibilité de créer un VirtualHost sécurisé par SSL

Installation du paquet:

> apt-get install screen

les commandes screen à partir de la console:

> screen			// Lance un screen
> screen -r			// Reprends un screen détaché
> screen -d			// Force le détachement d'un screen en cas de plantage pour en reprendre le contrôle
> screen -ls			// Affiche la liste des screen mère

commandes à partir d’une console screen:

• CTRL+A puis C = créer une nouvelle console screen
• CTRL+A puis N = passer à la console screen suivante
• CTRL+A puis P = passer à la console screen précédente
• CTRL+A puis D = Détacher le screen et revenir sur la console classique
• CTRL+D = fermer une console screen. Lorsqu’il n’y a plus qu’une seule console, ça quitte screen.

Pour commencer nous allons définir que:

• la machine locale sera la machine cliente, c’est-à-dire celle qui se connectera
• la machine distante sera la machine serveur qui recevra la connexion

Générer les clés:

Pour ce faire, commencer par taper la commande ssh-keygen sur la machine locale:

> ssh-keygen -t dsa

l’option -t dsa indique que l’on utilise un cryptage dsa de la clé, utilisé par SSH2. La génération des clés commence:

Generating public/private dsa key pair.
Enter file in which to save the key (/usr/home/toto/.ssh/id_dsa):

Appuyer sur Enter pour accepter la localisation de la clef (il est plus simple d’accepter la localisation proposée). ssh-keygen demande ensuite une « passphrase » (équivalent d’un mot de passe, mais sous forme de phrase). Cette phrase sert à fortifier la clef pour la rendre plus difficilement cassable.

À partir de là, deux solutions :

• Si on tape une phrase, la connexion sera plus sûre, mais il faudra utiliser ssh-agent pour ne pas avoir à la retaper à chaque fois
• On ne tape pas de phrase (on appuie seulement sur Enter), la connexion sera moins sûre.

la fin de la procédure affiche quelque chose comme:

Your identification has been saved in /usr/home/toto/.ssh/id_dsa.
Your public key has been saved in /usr/home/toto/.ssh/id_dsa.pub.
The key fingerprint is:
1a:2a:3e:4a:1a:65:1c:89:10:92:9c:5c:1f:75:cc:de
toto@machineloc

Le générateur va créer 2 clés: id_dsa (la clé privée) et id_dsa.pub (la clé publique).

Utiliser les clés

• Editer la clé publique et copier son contenu.
• Se rendre sur la machine distante et éditer le fichier .ssh/authorized_keys (le créer s’il le faut)
• Y copier le contenu de la clé publique sur une seule ligne
• Sauvegarder

Procéder ainsi pour toutes les machines distantes sur lesquelles on veut se connecter

Tester la connexion

Une fois que les clés sont placées sur les serveurs local et distant, il faut tester la connexion ssh:

> ssh host "ls -a"

Normalement, le système va détecter la présence des clés et vous demander de confirmer l’utilisation de ces clés. Il faut donc taper « yes » et valider. Cette opération ne se fait qu’une seule fois.

The authenticity of host '213.186.158.139 (213.186.158.139)' can't be established.
RSA key fingerprint is 02:11:f2:db:ad:42:86:de:f3:10:9a:fa:41:2d:09:77.
Are you sure you want to continue connecting (yes/no)?

Installation du paquet bind9 :

apt-get install bind9

modification du fichier
/etc/bind/named.conf.options

Dans la partie « forwarders »:

forwarders {
	80.10.246.2;
        80.10.246.129;
};

Exemple donné pour relai des DNS d’Orange

alias ls='ls -ap --color'

Pour activer la commande ll:

alias ll='ls $LS_OPTIONS -la'

Si après vous être déloggué puis relogué cela ne fonctionne pas, testez la commande suivante:

source ~/.bashrc

Si maintenant vos alias fonctionnent, dans ce cas il faut éditer le fichier .bash_profile et décommenter les lignes suivantes:

if [ -f ~/.bashrc ]; then
    source ~/.bashrc
fi

Les alias seront pris en compte automatiquement à chaque identification.

- sous putty, dans la section [Terminal -> Features], il faut cocher la case Disable application keypad mode
- sous ssh (natif linux), créer un alias

vtvim="TERM=vt220 vim"

> export EDITOR=vim

C’est tout !

> apt-get install ntpdate

Si utilisation d’un firewall, ouvrir le port 123 en UDP. Exemple de règle pour Netfilter (iptables):

iptables -A OUTPUT -o ppp0 -p udp --dport 123 -m state --state ! INVALID -j ACCEPT
iptables -A INPUT  -i ppp0 -p udp --sport 123 -m state --state RELATED,ESTABLISHED -j ACCEPT

Pour se synchroniser utiliser la commande ntpdate:

> ntpdate serveur_de_temps

liste des serveurs de temps français: http://www.cru.fr/services/ntp/serveurs_francais

On peut ensuite utiliser cron pour une synchro toutes les nuits.

>df -h

-h : affichage « humain » – Permet un affichage automatique en Ko, Mo, Go selon les tailles

Connaître l’espace occupé par un répertoire

>du -sh <nom du répertoire>

-s : sans cette option, la commande liste le contenu de chaque fichier du répertoire avec la taille. Avec on n’affiche que la taille du répertoire.