NDLR: article mis à jour en juillet 2015 et en janvier 2020 pour noter certains problèmes comme étant choses du passé.
Vous vous souviendrez peut-être de la première tentative un peu infructueuse, suivie de mon désenchantement envers Ubuntu/Canonical m’ayant amené à sérieusement réévaluer Fedora 15 comme plateforme de choix pour être à la pointe des avancées de GNOME et de Linux en général.
Le présent billet a pour but de partager, à la demande populaire et pour mes amis curieux, mes notes/observations sur ma migration d’Ubuntu à Fedora. Évidemment, je ne peux pas couvrir de manière exhaustive tous les cas d’utilisation, seulement les choses les plus saillantes qui m’ont embêtées. Somme toute, une fois ces soucis résolus, je me plais à utiliser Fedora.
Quelques différences par rapport à Ubuntu/Debian
Comment arrêter gdm: “service prefdm stop” (pas de service nommé “gdm”)- Mise à jour en 2015: “
service gdm stop” fonctionne depuis quelques versions de Fedora/systemd (comme alternative à l’usage direct de la commandesystemctl)
- Mise à jour en 2015: “
- Nano et Wget ne sont pas installés par défaut, et nano n’est pas utilisé comme éditeur de texte par défaut même s’il est installé. Il faut mettre un export EDITOR=nano dans son ~/.bashrc. Ugh.
- La commande rename a une syntaxe différente (elle n’utilise pas des regex comme sous Debian): au lieu de rename “s/2011_/blah/” *.pdf, on utilise: rename “2011_” “blah” *.pdf
- Mise à jour en 2016: Nautilus (le gestionnaire de fichiers) a maintenant la fonctionnalité pour renommer les fichiers en vrac beaucoup plus facilement qu’en ligne de commande, utilisez ça plutôt.
- Pour les développeurs/testeurs: les paquets de dépendances de compilation sont suffixés de “-devel”, pas “-dev”
- Pour les développeurs/testeurs: installer les paquets de débug pour un logiciel donné: cela se fait plutôt avec “
sudo debuginfo-install nom_du_logiciel” (note: les paquets de deboguage sont suffixés de “*-debuginfo” au lieu de “*-dbg”, mais ils ne sont pas immédiatement visibles car les dépôts debuginfo sont désactivés par défaut. Vous pouvez activer ces dépôts en éditant les fichiers dans/etc/yum.repos.d– cela reste vrai avec DNF – mais la commandedebuginfo-installreste plus conviviale car elle active temporairement ces dépôts pour vous, à la volée) - Yum met sa liste de dépôts à jour automatiquement lorsque vous tentez d’installer ou mettre à jour des paquets. C’est bien du fait qu’on n’a pas besoin de réfléchir et que c’est automatique, mais ça finit par énerver du fait que ça n’utilise pas de diff binaire
et que ça prend donc un temps fou à chaque fois.- Mise à jour en 2015: le problème de l’attente intempestive semble réglé depuis Fedora 22, où DNF met à jour sa liste de dépôts régulièrement en arrière-plan
- Les noms des paquets, dans Yum ou PackageKit, sont sensibles à la casse. Par exemple, tenter d’installer “virtualbox-ose” ne fonctionnera pas, il faut “Virtualbox-OSE”. WTF, seriously. Je sais pas qui a bien pu se dire un jour que ça serait une bonne idée.
Les dépôts supplémentaires
- RPM Fusion free (équivalent de “universe”)
- RPM Fusion nonfree (équivalent de “multiverse”)
- Dépôt Adobe officiel: 32 bits et 64 bits (mise à jour: mais qui veut encore Flash en 2015?)
- Pour ceux qui veulent Chromium (version open-source de Google Chrome):
- Au moment de la rédaction de cet article il fallait le dépôt Chromium non-officiel de Tom Callaway: voir les explications/instructions
- Mise à jour en 2015: Tom a abandonné la maintenance de ces paquets (probablement à cause de la non-coopération de Google après toutes ces années). Vous pouvez maintenant obtenir Chromium à partir des dépôts de Russian Fedora (si ça vous fiche autant la trouille que moi, considérez Firefox)
- Mise à jour en 2016: Chromium est maintenant intégré par défaut aux dépôts officiels, pas besoin de rajouter des dépôts.
- Mise à jour en 2018+: franchement, Firefox, c’est bien, utilisez Firefox. Depuis Firefox Quantum, y’a plus vraiment d’avantage de performances avec Chrome/Chromium.
- Au moment de la rédaction de cet article il fallait le dépôt Chromium non-officiel de Tom Callaway: voir les explications/instructions
Quelques optimisations potentielles
- Désactiver presto si vous avez plus de bande passante que de puissance de traitement (pratique sur les netbooks ou ordinateurs plus âgés): éditez le fichier
/etc/yum/pluginconf.d/presto.conf/etc/dnf/dnf.confen mettantdeltarpm=0(voir la doc).- Mise à jour: en pratique, en 2015 cette optimisation n’est que rarement nécessaire, DNF détermine automatiquement le “juste milieu” concernant l’usage des deltas de paquets et les ordinateurs personnels sont ridiculement puissants.
Pour les aventureux qui trouvent yum trop lent, essayez zif (un outil fait maison par Richard Hughes, auteur de packagekit et de tout ce qui a “kit” dans le nom, sauf les Kit-Kat): yum install zif PackageKit-zifInstaller gnome-shell-extensions-* (du moins, toutes celles qui vous intéressent; lisez les descriptions).Mise à jour: passez directement par extensions.gnome.org
Abaisser la sécurité (si le coeur vous en dit)
Je sens qu’on va me flamer pour recommander de telles hérésies, mais SELinux et le pare-feu sont franchement excessifs pour une utilisation de bureau typique.
Le pare-feu me gêne constamment. Par exemple, par défaut il bloquera avahi (aka zeroconf), SSH (et donc le SFTP), etc. Comme je suis derrière un routeur qui remplit déjà ce rôle, je le désactive parfois entièrement (ou même supprime d’un coup le paquet “firewalld”).
Il en va de même pour selinux qui est une source infinie d’emmerdements (je roule pas les serveurs de la NSA, j’ai pas à être si paranoïaque que ça)… En fait, il y a une blague qui dit que si, sous Windows, la réponse typique est «Avez-vous redémarré votre ordinateur?», l’équivalent Fedora est «Avez-vous désactivé SELinux?».
- Pour désactiver temporairement: echo 0 > /selinux/enforce
- Pour désactiver de manière permanente, éditer /etc/selinux/config et changer la ligne SELINUX=enforcing à SELINUX=permissive
- Notons que faire un “disable” (au lieu de permissive) aurait, semble-t-il, d’autres conséquences (mais je n’ai jamais eu de problèmes avec ça… au contraire). Voir le bas de cette page.
Désactiver le login root du serveur SSH
Sous Fedora, le root login à travers SSH est permis par défaut (c’est un peu débile à mon avis), donc il faut le désactiver dans /etc/ssh/sshd_config
Les paquets de modules de kernel automatiques
Si on veut faire fonctionner une de ces infâmes cartes sans fil Broadcom, il faut installer akmod-wl, pas kmod-wl (de rpmfusion). Du moins si on veut s’éviter des modules qui cassent lors de mises à jour de kernel, ou des problèmes de dépendances quand on est dans une version de test de Fedora. Il en va de même avec les modules nvidia, par exemple. Source: fedoraforum.
Comments
13 responses to “Fedora pour un habitué d'Ubuntu, prise deux6 min read”
Dit donc, c’est pas méga-positif tout ça 😉
De mon côté, je m’essaie à OpenSuse et si il y a de super bonnes idée (Zypper, Tumbleweed), mon plus gros problème est que la moitié des logiciels ne sont pas dans les repositories et que, après 5 jours, je n’ai toujours pas compris comment fonctionnait l’équivalent des PPA et que je me contente de chercher des RPM sur Google.
Mais les RPM sont vraiment très lent, Yast se mange sans arrêt la tronche avec PackageKit, tout ça est fort ennuyeux. Est-ce que Fedora privilégie PackageKit ou est-ce qu’elle mélange aussi avec son système maison ?
Ben, c’est un comparatif de “choses auxquelles il faut s’adapter en venant d’Ubuntu”, c’est forcément que des “problèmes” et donc du négatif… tout le reste pour moi c’est du positif (qu’on peut un peu retrouver dans le billet où je décide de quitter Ubuntu), et ça c’est pas le but du billet, sinon il ferait 20 km de long.
Tiens, je dois dire par exemple que Presto c’est cool quand on a un ordinateur assez puissant, et que ne pas avoir à mettre à jour sa liste de dépôts manuellement c’est cool aussi quand on a une connexion rapide 🙂
Les PPA sous Fedora… je ne sais pas s’il y a un équivalent en termes de “build farm automatisé comme launchpad”, visiblement people.fedoraproject.org contient plusieurs dépôts (mais c’est en désordre)… Par contre, on a typiquement moins besoin de PPAs puisque Fedora n’a pas la politique “on ne fournit pas d’updates sauf sécurité” de Ubuntu).
En tout cas, jusqu’à présent, grâce à rpmfusion je n’ai jamais eu à “chercher des rpm sur google”.
Comme interface graphique de gestionnaire de paquets, sous Fedora c’est purement gnome-packagekit. Pour avoir discuté en personne avec Richard Hugues, le plan à long terme est de le remplacer par le software center d’Ubuntu (y’a aussi opensuse et mageia qui sont intéressés), le problème est qu’il faut soit que Canonical lâche leur Contributor License Agreement, ou bien qu’ils forkent le software center… Mais ouais, la lenteur de gnome-packagekit me fait parfois hurler. Utiliser yum (ou zif?) en ligne de commande est généralement beaucoup plus fiable et rapide.
donc en gros ce qui te gêne (hormis SELinux) c’est de la syntaxe? je ne tiens pas compte des akmod/kmod c’est dans la doc.
Hummm… Sudo avec Fedora. Rhalala.
Un vrai Fedorien utilise su –
😉
Passer de Ubuntu a Fedora a été le meilleur changement que j’ai fait juste après l’achat de mon ssd. 😉
@mrk: somme toute, les problèmes sont relativement mineurs oui…
@Ricard: héhé, old hobbits die hard!
> Comment arrêter gdm: “service prefdm stop” (pas de service nommé “gdm”)
On préférera la commande suivante à partir de Fedora 15, puisqu’on est passé à systemd :
# systemctl stop prefdm.service
> Nano et Wget ne sont pas installés par défaut
Tu veux dire que **Vim** et wget ne sont pas installés par défaut ? (eh, vendredi est déjà bien entamé ici ! :P)
> Installer les paquets de débug pour un logiciel donné: sudo debuginfo-install nom_du_logiciel (il n’y a pas de paquets “*-dbg” visibles directement dans les dépôts)
C’est parce qu’ils s’appellent *-debuginfo 🙂
Mais debuginfo-install est de toutes façons une meilleure idée puisqu’elle installe non seulement les debuginfos du paquet souhaité, mais aussi de toutes ses dépendances (histoire d’avoir une stacktrace complète).
> Yum met sa liste de dépôts à jour automatiquement lorsque vous tentez d’installer ou mettre à jour des paquets.
Uniquement si le cache est jugé “vieux”. Ça se configure dans /etc/yum.conf (paramêtre metadata_expire).
Alternativement, tu peux aussi utiliser “yum -C” pour spécifier que tu ne veux pas mettre à jour le cache (donc te faire un alias bash), et “yum makecache” pour manuellement mettre à jour celui-ci.
Maintenant, pourquoi est-ce que yum a ce comportement par défaut ?
Ça vient tout simplement de la politique de mise à jour de Fedora. Je ne connais pas celle d’Ubuntu, mais globalement : Fedora pousse des mises à jour très régulierement (au moins une fois par jour), et Debian pousse très peu de mises à jour (aucun jugement moral de ma part, ça vient tout simplement de leurs objectifs diamétralement opposés).
De plus, Fedora ne garde dans ses dépôts que la version la plus récente de chaque paquet (je ne sais pas pour Debian/Ubuntu).
Dans ces conditions, avoir un cache obsolète sur une Fedora ne peut que causer des ennuis (dépendances manquantes, impression que les dépôts sont “cassés”,…), et le cache est donc mis à jour fréquemment (par défaut il est mis à jour s’il est vieux de plus de 90 minutes).
Il ne faut donc pas voir ça comme un défaut de yum (puisqu’il permet d’obtenir le même comportement qu’apt-get), mais comme une conséquence des objectifs de Fedora : aller vite.
> Les noms des paquets, dans Yum ou PackageKit, sont sensibles à la casse.
C’est vrai pour les commandes “install”, “update”, “list” et “remove” (et peut-être d’autres), mais heureusement, “search” est case-insensitive.
Ceci dit :
# yum install gconf2-devel
[… snip …]
No package gconf2-devel available.
* Maybe you meant: GConf2-devel
Je suis cependant incapable de te dire pourquoi c’est comme ça, sans doute une design decision des early days de RPM qui a survécu. 😉
> Le pare-feu me gêne constamment. […] D’ailleurs, par défaut il empêche avahi (aka zeroconf) de fonctionner correctement, qui casse […]
… les imprimantes réseau, et plein d’autres choses.
C’est un problème connu, mais difficile à résoudre correctement (choisir entre pas de sécurité et pas de features n’est pas une résolution acceptable).
Heureusement, il y a de l’espoir :
http://fedoraproject.org/wiki/Features/DynamicFirewall
> Pour désactiver temporairement: echo 0 > /selinux/enforce
Ou plutôt :
# setenforce 0
(/selinux a été migré vers /sys/fs dans les kernels récents, donc la commande setenforce est plus pérenne)
> Notons que faire un “disable” (au lieu de permissive) aurait, semble-t-il, d’autres conséquences
En fait, permissive est inutile, voire indésirable dans la plupart des cas.
Pour rappel :
– enabled: SELinux est actif, bloque les accès qu’il juge opportun de bloquer et remonte les erreurs
– disabled: SELinux est inactif, c’est la fête
– permissive: SELinux est actif, ne bloque rien, mais continue de monitorer et de remonter les blocages
Du coup, permissive n’est utile que dans deux seul cas :
1. tu es développeur de la politique de sécurité SELinux de ta distribution
2. tu es admin, SELinux bloque un de tes services, et tu veux pouvoir le débloquer tout en continuant d’avoir les infos pour changer la politique de sécurité locale ou corriger le service si c’est un réel bug dans son code
Si tu veux simplement ne pas avoir SELinux sur ta machine, désactive le complètement, ça t’évitera l’overhead (conso mémoire, accès disque pour les logs, …)
> Sous Fedora, le root login à travers SSH est permis par défaut (c’est un peu débile à mon avis)
Chicken and egg?
L’idée c’est que par défaut, tu dois pouvoir te connecter à une machine que tu viens d’installer. Et quand tu installes une machine via un kickstart, de façon automatisée, il est fort possible que :
1. la machine n’ait pas d’autre compte utilisateur que root
2. la machine soit installée sans accès physique à celle-ci
Du coup, tu ne peux pas te connecter autrement la première fois, le temps de désactiver le compte root, créer tes utilisateurs, faire l’authentification par clés, etc…
Si tu as une meilleure idée pour obtenir le owsultat désiré tout en désactivant le login root via SSH par défaut, je suis persuadé que les mainteneurs d’OpenSSH dans Fedora acceptent les suggestions sous forme de bug reports. 🙂
—–
@Ricard:
> Hummm… Sudo avec Fedora. Rhalala.
> Un vrai Fedorien utilise su –
> 😉
Pourquoi ?
sudo est un mécanisme genial dont il serait stupide de se priver sous prétexte que “sous une autre distrib c’est le mecanisme par défaut mais pas chez nous”.
La politique de Fedora est de ne pas avoir un sudo activé par défaut pour que ce soit un choix conscient d el’utilisateur, mais on ne décourage absolument pas son utilisation.
D’ailleurs, les admins de l’infra Fedora utilisent énormement sudo sur les serveurs il me semble.
—–
La transition d’un système vers un autre est toujours un passage frustrant, j’espère avoir pu t’aider. (même si du coup j’ai pondu un pavé ^_^)
Petite précision, pour désactiver SELinux c’est “disabled” et pas disable. Sinon ça ne marchera pas, enfin de toutes façons les 3 états possibles sont écrits dans le fichier quand on va le modifier.
A chaque install de Fedora je commence toujours pas supprimer SE Linux car je juge ça inutile sur un poste client, et même sur un serveur (qui n’a que 1 rôle). Ça ajoute tellement en complexité que perso je préfère avoir moins de sécurité mais une meilleure maîtrise sur ma machine.
Pour le parefeu il y a un outil graphique assez bien foutu qui permet de tout gérer, et même de faire du NAT ou de la redirection de port… encore une fois c’est super pratique.
Pour les pilotes c’est un peu différent de Ubuntu il faut ajouter les dépots rpmfusion puis ensuite aller piocher les kmod-* ou akmod-* mais au final ça marche bien aussi.
J’ai tourné sur Fedora de la version 12 à la 15, en migrant sur KDE4 pour la dernière. Au début je trouvais que c’était une super distro à jour et robuste, mais les dernières m’ont fait changer d’avis au travers de divers plantages ou manques (mais ça vient peut-être de KDE4). Et Yum m’a pas mal énervé avec sa tendance à se resynchroniser à chaque utilisation, surtout la période où ma connexion ADSL ne marchait plus très bien et que pour installer un paquet de 1Mo je devais me taper une synchronisation de 30Mo qui prenait un quart d’heure.
Intéressant tout ça !
Je rajoute juste que je préfère largement la sortie très claire de yum au bordel illisible de apt-get, et que je ne trouve pas l’équivalent de “yum search” bien pratique pour apt-get 🙂
@bochecha:
Pourtant, si je cherche debuginfo dans gpk-application, je ne vois que quatre paquets/résultats de recherche…
Bien vu, merci des éclaircissements. Il est vrai que je n’ai pas cherché à vérifier si on peut “éviter le rafraîchissement des dépôts”… je suppose que c’était juste une légère irritation de ma part face aux rafraîchissements à presque toutes les utilisations de yum.
Concernant la commande “setenforce 0” de selinux, en regardant le manpage il semble que ça le mette en mode permissif, pas un disable complet… est-ce vrai? Alors est-ce différent de ma commande echo suggérée dans ce billet?
Concernant le root login SSH et “j’ai pas d’autre moyen d’accéder à la machine”: aah, je n’avais pas pris en compte les installations à distance… ce n’est pas tellement un scénario du commun des mortels. Normalement j’ai toujours un accès physique aux ordinateurs sur lesquels j’installe Fedora!
Merci, c’était un commentaire très instructif, qui sera certainement utile aux autres lecteurs également!
@goloc:
Tout à fait d’accord là-dessus!
> Concernant la commande “setenforce 0″ de selinux, en regardant le manpage il semble que ça le mette en mode permissif, pas un disable complet… est-ce vrai? Alors est-ce différent de ma commande echo suggérée dans ce billet?
setenforce c’est **exactement** la même chose que ce que tu suggérait dans le billet…
… sauf qu’à partir de Fedora 16, le fs virtuel de SELinux est passé dans /sys/fs/selinux plutôt que dans /selinux, donc le echo ne fonctionnera plus, alors que le setenforce lui fonctionne toujours.
Mais effectivement, pour le désactiver complètement, il faut :
1. passer le paramêtre selinux=0 au kernel sur la ligne Grub
2. modifier le paramêtre qui va bien dans /etc/sysconfig/selinux
(l’un ou l’autre, pas nécessaire de faire les deux)
C’était surement pas très clair dans mon commentaire, mais c’était deux trucs orthogonaux.
@goloc :
l’équivalent de yum search est “apt-cache search”
Pour trouver à quel paquet appartient un fichier, tu peux même installer “apt-file”, faire un “apt-file update”, puis un “apt-file search CePinaiseDeFichierQuiVientDeChai-pas-où”
Au fait, je pense que bzr-gtk est abandonné. Tu peux utiliser bzr qdiff et bzr qlog, c’est ce que je fais.