Blog de Guillaume

Tout n'est qu'une question de point de vue.

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

Ubuntu Server Karmic Koala et Dedibox

Certains d’entre vous l’on peut être remarqué, le serveur, et donc par conséquent le blog, était indisponible depuis très tôt ce matin (depuis environ 01h00) jusqu’à très tard ce matin (jusqu’à environ 11h45). La cause, j’ai tenté de migrer la Dedibox, qui était sous Ubuntu 9.04, vers Ubuntu 9.10. Malheureusement, j’ai pensé que la migration allait se passer comme toutes les autres fois. Mais ça n’a pas été le cas comme vous avez pu vous en douter. Donc pour la mémoire (et m’obliger à prendre plus d’informations auparavant) et pour ceux qui tomberaient dans le piège également, voilà comment procéder pour garder son serveur fonctionnel.

On a correctement mis à jour votre installation de Ubuntu Server via les commandes suivantes :
~$ sudo aptitude update
~$ sudo aptitude full-upgrade
~$ sudo aptitude install update-manager-core
~$ sudo do-release-upgrade


Là tout est à jour, mais on a le malheur (qui a été le mien) de redémarrer après avoir remplacé dans le fichier menu.lst de GRUB les :

root=UUID=4564577843545963533

par des :

root=/dev/sda2

Manque de chance, le serveur ne veut pas booter quand même. Et ceci est dû au kernel utilisé par la Dedibox. Pour remédier à cela, il faut installer le kernel proposé dans les dépôts de Ubuntu. Immédiatement, on démarre le système de secours. Pour accéder à ce mode, on passe par l’interface d’administration, puis Système de secours et on clique Passer votre serveur en mode de secours. La machine est ainsi électriquement redémarrée et les identifiant / mot de passe du compte SSH nous sont donnés.

Préparons le terrain

Une fois connecté en SSH, on arrive sur un terminal sans privilèges d’administration. On va donc se les donner en utilisant le mot de passe qui nous a été fournis.
~$ sudo su -

Maintenant, on va monter les partitions pour déterminer vraiment d’où vient le souci et dans notre cas installer le kernel qui va bien. Pour cela, on utilise les commandes mount et chroot.
~# mkdir server

~# mount /dev/sda2 server
~# mount /dev/sda1 server/boot

~# mount --bind /proc server/proc
~# mount --bind /sys server/sys
~# mount --bind /dev server/dev

~# chroot server


À ce stade, on est sur notre serveur. On peut donc y effectuer les opérations nécessaires.

Réparons

Comme je l’ai dit plus haut, pour réparer les dégâts, il faut utiliser le kernel générique à la place du kernel Dedibox. On installe alors le paquet linux-server.
root@serveur sudo aptitude update
root@serveur sudo aptitude full-upgrade
root@serveur sudo aptitude install linux-server


On oublie surtout pas de remplacer le root=UUID=… par root=/dev/sda2 dans le fichier menu.lst de GRUB et voilà, la réparation est faite.

Chouette, ça marche !

La réparation est terminé, on peut revenir sur une utilisation normale du serveur. Cependant, il faut prendre soit de terminer tous les processus que l’on a lancé en chroot et de démonter toutes les partitions.
root@serveur exit

~# umount server/proc
~# umount server/sys
~# umount server/dev

~# umount server/boot
~# umount server

~# exit
~$ exit


Pour finir, on retourne dans la console d’administration Dedibox et on clique sur Cliquer ici pour repasser en mode normal. Et là, le boot devrait se faire sans aucun souci. Conclusion, il ne faut pas se précipiter et se dire que tout réinstaller est la seule solution. Ici, on a réparé le tout sans perte de données mais par contre il y a eu un downtime (et un long pour moi, je tiens à m’en excuser d’ailleurs). C’est après avoir été dans ce genre de situations, que l’on se dit que GNU/Linux c’est quand même vachement bien. Mais ce n’est pas une raison pour faire n’importe quoi !

Sources

Artisan Numérique
Forum Dedibox News

Ubuntu, nouveau look

On l’attendait depuis un moment, Ubuntu va changer de look c’est officiel. Nouveau thème pour le système, nouveau style pour le logo et la marque. Personnellement, j’aime le nouveau style sobre et surtout au revoir le marron que l’on a pu connaître (même si je l’aimais bien). Pour voir tout ça, rendez-vous ici et . Voilà enfin un petit coup de jeune pour notre mon système d’exploitation préféré. Il ne reste plus qu’à savoir si ce nouveau look va plaire à la communauté.

Au niveau des thèmes du système, il y en deux. Un relativement sombre et l’autre qui est plus clair. En revanche, sur les deux thèmes, les boutons de gestion d’une fenêtre (fermer, réduire, agrandir) sont maintenant placés sur la gauche (toujours en haut bien entendu) de la fenêtre. On constate que le tableau de bord de GNOME a droit à de nouvelles icônes.

   

Le thème du boot est également modifié pour quelque chose plus en accord avec les thèmes systèmes et le nouveau look.

Toujours dans la continuité les logos ont changé avec une nouvelle police, entre autre, que je trouve très réussite.

blackubuntulogo.png

Enfin pour terminer, les divers sites web, CDs et pochettes, les habits et accessoires vont être mis à la nouvelle mode.

Les icônes dans GNOME, un vrai souci ?

On l’a tous remarqué (du moins les utilisateurs de GNOME, version >= 2.28). Les icônes se sont barrées. C’est un bug ? Non. Enfin si, mais un bug de l’esprit de ceux qui ont décidé ça. Avant la version 2.28, GNOME utilisait les icônes dans les menus et sur les boutons. Mes barres d’outils, quant à elles, possédaient des icônes avec un texte en dessous. Depuis la version 2.28, les icônes précédemment utilisées sont parties et les barres d’outils possèdent des icônes avec un texte sur la droite (mais pas toujours). Pour les barres d’outils, le style est complètement foireux et étrange, pour les icônes c’est peut-être pas terrible tant que l’on peut les réactiver. Tout ça, c’était possible avec GNOME 2.28. On pouvait utiliser les icônes (sans modifier directement les valeurs GConf) et modifier le style des barres d’outils. Avec GNOME 2.29, certaines personnes ont eu l’idée d’enlever l’onglet Interface disponible jusqu’à présent via Système > Préférences > Apparence. Et ça, malgré les protestations qu’il y a eu. De plus, les décideurs responsables de cette modification répondent de manière relativement agressive aux protestations. Sympa pour un tel projet. Sympa aussi pour les dyslexiques.



Bref, qu’est-ce qui se passe en ce moment ? L’interface par défaut ne doit plus être modifiable facilement ? Doit-on vraiment coder un outil spécial pour tweaker notre interface ? Quelle est la prochaine étape ? Ne plus nous permettre de changer de thème ? Aidez-moi à comprendre car là je n’arrive plus à suivre les décideurs… Bref, si vous développez des applications pour le bureau GNOME, forcez l’affichage des icônes et proposez la modification du style des barres d’outils, ça aidera peut-être les auteurs du crime à se rendre compte de la débilité d’avoir proposé un patch qui a permis d’enlever l’onglet Interface.

Ubuntu et les PPAs, force ou faiblesse ?

Depuis que Launchpad existe et qu’il propose des PPAs, on a vu le nombre de ses dépôts de paquets non-officiels augmenter de manière assez impressionnante. D’ailleurs, même moi je les utilise aussi bien pour obtenir certains paquets que pour en distribuer d’autres (comme java-gnome et GNOME Split). Le fait que de plus en plus d’utilisateurs ont recours à ce genre de dépôts m’a fait me poser une question. Est-il vraiment raisonnable, pour des questions de sécurité et stabilité du système, d’utiliser un nombre relativement élevé de PPAs ?

Revenons au début de la réflexion. Pourquoi utiliser un PPA ? Dans un premier cas, c’est pour obtenir des mises à jour de paquets, soit pour des corrections de bugs, soit pour obtenir la dernière version d’une bibliothèque ou d’un logiciel. Dans un deuxième cas, c’est pour obtenir des paquets encore non disponibles dans les dépôts officiels (pour de jeunes programmes notamment). Avec Karmic Koala, l’ajout d’un PPA peut se faire de manière très simple via la ligne de commande (add-apt-repository) ou via la logithèque. Grâce à ça, les utilisateurs, même novices, peuvent très facilement avoir accès à toutes sortes de dépôts personnels. Est-ce bien ou est-ce mal ? De mon point de vue, je dirais que c’est un peu des deux, le PPA a ses avantages (logiciels nouveaux ou à jour) mais ses défauts (stabilité ? sécurité ?). Malheureusement, ses défauts ne viennent pas tant du principe mais plutôt des gens qui vont packager les applications (n’étant pas un expert dans le domaine je ne peux pas vraiment critiquer ça). Lorsqu’un paquet entre dans Debian et donc dans Ubuntu lors de la synchronisation, il est considéré comme stable et sans risque pour le système. De plus, des personnes, des professionnels du packaging l’auront contrôlé et corrigé. Ceci n’est pas vrai avec un PPA. Le packageur, connaisseur ou non, va packager son application (en faire un paquet source) et l’envoyer sur Launchpad, la ferme de serveurs se chargera d’en faire un ou des paquets binaires. C’est quelque chose de très pratique et appréciable pour le développeur, ça peut l’être nettement moins pour l’utilisateur si son système plante à cause d’un paquet de mauvaise qualité.


Bref, il n’y a pas vraiment une vérité absolue. Un ou des PPAs ont une force et une faiblesse. Pour la faiblesse, l’utilisateur en est averti en général, et heureusement ! Cependant, il est facile de céder à la tentation pour utiliser la dernière version d’un logiciel car il a telle ou telle fonctionnalité en plus. Les PPAs sont sympas mais il ne faut pas en abuser. Si c’est le cas, je pense qu’une remise en cause de la part de l’utilisateur se doit d’être faite. Peut-être que Ubuntu n’est pas la distribution qui lui correspond le mieux. Peut-être que l’utilisateur appréciera davantage une distribution comme Arch Linux (et d’autres) qui ont des paquets toujours mis à jour. Vous aussi, vous avez un avis sur le sujet ? Partagez-le avec nous.

Lancer un programme en anglais sans changer la langue

Il peut être intéressant, pour une raison ou une autre, de vouloir utiliser un programme en anglais sur un système configuré dans une autre langue. Dans mon cas, je voudrais pouvoir réaliser simplement quelques captures d'écran de GNOME Split en anglais.

Dans un tel cas, il serait forcément assez lourd de changer la langue de tout le système pour lancer un logiciel. C'est là qu'intervient la variable d'environnement LANG. C'est avec cette variable que nous allons jouer. Pour commencer, on peut entrer la commande suivante dans un terminal.
~$ echo $LANG

Si votre système est en français comme le mien, vous devriez probablement avoir comme résultat la chaîne de caractères suivante : fr_FR.UTF-8.

Pour lancer un logiciel en anglais, on va modifier cette variable seulement dans le "terminal" où l'on va lancer le programme. Pour cela, on crée un script qui va donner à la variable LANG la valeur C puis exécuter la ligne de commande passée en argument du script (ligne de commande identique à celle que l'on utiliserait pour lancer le logiciel normalement).

Pour faire le script, on crée puis édite un fichier nommé (comme on veut en fait) english.sh et on y met le code suivant :

#!/bin/bash
LANG=C "$@"


Ensuite, on enregistre puis on rend le script exécutable.
~$ chmod +x english.sh

Finalement, on lance le script et on passe en paramètre la ligne de commande à exécuter.
~$ ./english.sh transmission

En voilà ce que ça donne (un peu de pub ça fait pas de mal non roh).

Clavier EeePC 1000 HE et Ubuntu 9.10 Karmic Koala

Je me suis récemment rendu compte d'un problème relativement embêtant. Ce dernier est lié à la reconnaissance du clavier de mon Asus EeePC 1000 HE. En effet, il m'était impossible (du moins avec la combinaison de touches normale Alt Gr + 8) d'utiliser le \ (backslash) dans un éditeur de texte. Chose assez embêtante pour un programmeur quand il a besoin d'utiliser le fameux \n (ou encore \r ou \t) dans ses printf() par exemple.

Une solution existe, heureusement, et elle est simple. Pour cela, on va dans Système > Préférences > Clavier. On se rend ensuite dans l'onglet Agencement puis on change le modèle du clavier pour utiliser Portable Asus.


Voilà, simple et efficace.

GNOME Split sort en version 0.3

Je n'avais pas signalé la sortie de la version 0.2, et bien je vais me rattraper avec celle de la version 0.3. GNOME Split, le logiciel de découpage et assemblage de fichiers, évolue petit à petit. La version 0.1 était une première version plutôt avancée, par conséquent la version 0.2 n'a vu arriver que des corrections de bugs (dont un critique pour les utilisateurs de la version 2.22.3 de glib). Alors qu'est-ce qu'il y a dans cette version ?

  • Découpage et assemblage au format GNOME Split,
  • Découpage et assemblage au format Xtremsplit,
  • Découpage et assemblage sans format spécifique (semblable à la commande "split", assemblage par "cat" possible),
  • Réorganisation de la boîte de dialogue de préférences,
  • Optimisation du code de l'interface graphique,
  • Ajout d'info bulle sur les boutons de la barre d'outils,
  • Correction de bugs divers.

Le code source peut être récupéré soit via cette archive, soit via le dépôt Bazaar. Pour les utilisateurs de Ubuntu 9.10 Karmic Koala, un dépôt PPA (dépôt non officiel donc attention hein) est à disposition. Une fois ce dernier ajouté, il ne suffira alors qu'à utiliser la commande :
~$ sudo aptitude install gnome-split

Sortie de java-gnome 4.0.14

Une nouvelle version de java-gnome est disponible depuis hier. Il s'agit de la version 4.0.14 de l'API. Elle apporte notamment une intégration de la correction orthographique via l'API Enchant, une amélioration de la gestion des pointeurs (de souris) grâce à GDK. On voit apparaître de même une meilleure gestion du rendu de texte. Une autre nouveauté est l'apparition du widget LinkButton qui offre la possibilité d'ouvrir une URL grâce à un bouton (travail effectué par Serkan Kaba et moi-même).


Il est désormais possible de créer ses propres tailles de papier afin de pouvoir utiliser le format PDF via Cairo même si la taille n'est pas standard. On a également droit à un lot de corrections principalement typographiques. Comme certains le savent ou l'ont remarqué, avec GNOME 2.28, les icônes dans les menus peuvent être masquées ou non selon la configuration (elles le sont par défaut). Il est toutefois possible d'en forcer l'affichage maintenant grâce à de nouvelles méthodes dans l'API ou bien de continuer à utiliser les paramètres globaux. Au niveau de la compilation de la bibliothèque, l'utilisation de Xvfb permet aux packageurs de lancer tout de même la suite de tests et de générer la javadoc. Enfin, un bug critique a été corrigé contourné. Ce dernier faisait crasher l'application directement si l'utilisateur utilisait la version 2.22.3 de glib.

La news complète de la sortie de java-gnome 4.0.14 est ici, le téléchargement des sources lui est par . À noter que GNOME Split 0.1 utilise la version 4.0.13 et que GNOME Split 0.2 utilisera la version 4.0.14. La dernière release de java-gnome est déjà disponible sur Gentoo, Arch Linux, bientôt pour Debian, pour Ubuntu ça sera pour Lucid Lynx (mais je vais demander un backport dans Karmic Koala).

À vos codes.

- page 1 de 22