Archives par étiquette : testing

Mise à jour de ma documentation Debian

Salut,

(pas la peine de faire des commentaires de troll, je ne validerai pas)

J’ai mis à jour ma doc d’installation + kit de survie + gros sujets « serveur » à l’instant.
Elle est disponible au format Word (oui oui, je sais) et au format PDF (mais certains liens HTML dedans ne marchent pas, si quelqu’un sait pourquoi… généré avec PDFCreator depuis Word 2007)
Elle est destinée à des personnes connaissant un peu Linux et voulant installer un Linux qui a fait ses preuves, plutôt pour un usage serveur.

Le concept de cette n-ième mouture est le suivant :

  • J’abandonne la partie graphique/bureautique => utilisez Ubuntu
  • Premiers chapitres sur les quelques trucs à savoir sur Debian (différentes versions etc)
  • Gros chapitre comparant, écran par écran, l’installation de « Etch mode expert », « Lenny mode expert » et « Etch mode normal ». Afin de montrer les différences avec la prochaine release d’une part, et la comparaison normal/expert d’autre part – pour ceux à qui cela ferait peur.
  • Kit de survie : comment gérer les paquets, gérer son système – quelques spécificités Debian
  • Firewall « shorewall » : tout pour faire rapidement une conf propre
  • Serveur de mail : un exemple bien complet pour monter un serveur, de postfix à spamassassin, rulesemporium, tout ça
  • Un exemple d’installation d’application LAMP classique : gallery2

Voilà. Vous pouvez me faire vos retours, vos impressions, tout ça.

Mixer les releases Debian, sans trop de risque

Salut,

Il arrive qu’on ait besoin d’une application en « testing » sur un serveur en « stable ». Par exemple OCSInventory-NG. Il y a la bonne et la mauvaise méthode pour faire ça.

La mauvaise méthode (rapide, mais naze sur le long terme)

La méthode bourrin consiste à ajouter momentanément les lignes qui vont bien dans /etc/apt/sources.list, faire un apt-get update, l’installer et enlever les dépôts ensuite.
Ca marche mais on ne profite pas des mises à jour qui peuvent être importantes. Je dis ça car ensuite il vaut mieux enlever ces lignes qui risquent de vous faire migrer une partie de vos applis de « stable » à « testing » (si des fois vous êtes aveugles lors de votre « upgrade » régulier).
A ce propos, il ne faut pas oublier d’ajouter les lignes concernant le dépôt de sécurité.
Exemple, j’ajoute les lignes « lenny » pour donner ça :

deb ftp://ftp2.fr.debian.org/debian/ etch main contrib non-free
deb ftp://ftp2.fr.debian.org/debian/ lenny main contrib non-free

deb http://security.debian.org/ etch/updates main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free

La bonne méthode (presque aussi rapide)

La méthode propre consiste à garder tout le temps les lignes concernant les 2 (4) dépôts, mais à indiquer à APT le niveau de release que l’on veut conserver par défaut. Pour ce faire, créer un fichier du genre 00release dans /etc/apt/apt.conf.d/. Exemple :

# cat /etc/apt/apt.conf.d/00Release
APT::Default-Release "stable";

Soyez prudent les 2/3 premières fois où vous mettrez à jour vos dépôts + upgrade. Histoire d’être sûr.

Le bug qui en découle

Souvent, l’effet de bord sera ça à votre prochain « apt-get update » :

Fetched 14.6MB in 50s (292kB/s)
Reading package lists... Error!
E: Dynamic MMap ran out of room
E: Error occurred while processing tkdiff (NewVersion1)
E: Problem with MergeList /var/lib/apt/lists/debian_debian_dists_lenny_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.
E: Couldn't rebuild package cache

La correction sera d’augmenter un buffer quelconque pour APT, en ajoutant/adaptant, généralement dans /etc/apt/apt.conf.d/70debconf la ligne suivante :

APT::Cache-Limit 15728640; // 15 MB

Afin de repousser un peu la limite.

Voilà, c’est tout pour cette petite astuce néanmoins bien pratique.