C’est après une version bêta et une version candidate que Red Hat a annoncé ce 10 juin la disponibilité publique de Red Hat Enterprise Linux (RHEL) 7, distribution commerciale destinée aux professionnels et aux entreprises. Il s’agit d’une version majeure, apportant un lot conséquent de nouveautés. Red Hat Enterprise Linux 7 est disponible pour les architectures AMD64/Intel64 et IBM (POWER7, POWER8 et System Z). Les versions bêta et Release Candidate ont été rendues publiques les 11 décembre et 15 avril derniers. Le nom de code de cette version est Maipo.
Sommaire
- Versions logicielles
- Nouveautés importantes
- Installation
- Matériel
- Stockage et systèmes de fichiers
- Virtualisation
- Haute disponibilité et grappes de calcul
- Réseau
- Développement
- Authentification
- Sécurité
- Durée de vie
Versions logicielles
Dans les grandes lignes, RHEL 7 c’est :
- noyau Linux 3.10 ;
- Glibc 2.17 ;
- GNOME 3.8 ;
- KDE 4.10 ;
- Python 2.7.5 ;
- Firefox 24.4 ;
- LibreOffice 4.1 ;
- Bash 4.2 ;
- OpenSSH 6.4p1 ;
- Apache HTTPD 2.4.6 ;
- PHP 5.4.16 ;
- Bind 9.9 ;
- DHCP 4.2 ;
- PostgreSQL 9.2 ;
- Postfix 2.10 ;
- Sendmail 8.14.7 ;
- MariaDB 5.5.35 ;
- Perl 5.16.3 ;
- GCC 4.8.2 ;
- GDB 7.6.1 ;
- SystemTap 2.4 ;
- Samba 4.1.1 ;
- systemd 208 ;
- Xorg-server 1.15.0.
Globalement, en termes de versions logicielles, RHEL 7 se rapproche de Fedora 19.
Nouveautés importantes
- MariaDB remplace MySQL ;
- systemd remplace Upstart comme système d’init ;
- inclusion de Docker et de LXC, montrant l’ambition de Red Hat à faire de RHEL la plate-forme d’informatique en nuages de référence ;
- XFS comme système de fichiers par défaut, en remplacement d’ext4.
Cette dépêche est fortement inspirée de la technical overview officielle et des notes de version.
systemd
systemd est utilisé comme init (système d’initialisation, démarrage) par défaut. Il s’occupe donc de gérer les services, le système (watch dogs, ACPI…) et aussi partiellement les machines virtuelles et les conteneurs (en coopération avec libvirtd). En effet, la version présente est la 208, qui inclut notamment les changements introduits dans la version 205 : la « prise de possession de l’arbre des cgroups ». systemd est le seul responsable de l’arborescence des cgroups et se charge donc d’y placer tous les processus. Cette nouvelle interface est décrite sur le wiki de systemd. La différence ici sera donc marquée, même par rapport à un système avec un systemd ancien (Debian, par exemple) : le cas pour libvirt.
Installation
C'est sans doute la première chose qui va sauter aux yeux lorsque vous installerez RHEL 7 : Anaconda. Si vous n'avez pas utilisé une Fedora depuis la version 18, la surprise sera totale et vous aurez du mal à reconnaître l'interface d'installation, dont les menus sont accessibles en deux étapes principales. Parmi les nouveautés d'Anaconda, on trouvera :
- une meilleure internationalisation ;
- une gestion de cette internationalisation en fonction de la géolocalisation : la langue et l'heure de la machine peuvent être automatiquement définies grâce à cette donnée ;
- la possibilité de configurer un système de fichier tmpfs ;
- une configuration réseau plus complète, avec par exemple l’agrégation de cartes réseau.
Autre nouveauté non négligeable, la mise à jour : il devient possible de mettre à jour une RHEL 6.5 (ou ultérieure dans la branche 6) vers RHEL 7 ! C'est une avancée majeure pour Red Hat, qui prend en charge officiellement cette possibilité.
Une autre chose importante à noter : l'installeur n'est plus accessible pour les machines x86 à processeur 32 bits. Si pour certains cela peut être décevant, il convient de rappeler que depuis plusieurs années, les principaux fabricants de serveurs x86 ne proposent que des machines x86_64, les seules machines 32 bits récentes étant dotées de processeurs de faible puissance et de faible consommation (comme par exemple la gamme Soekris net6501), qui ne sont clairement pas la cible commerciale de Red Hat. Malgré tout, de nombreux paquets compilés pour i686 sont disponibles, ce qui laisse encore du temps si vous avez des développements spécifiques à cette architecture.
Matériel
Pilotes et périphériques
Le retrait de l'architecture 32 bits x86 des plateformes prises en charge permet à Red Hat de faire le ménage. Un certain nombre de pilotes et de modules quittent RHEL, dont par exemple b43-fwcutter, b43-openfwwf, forcedeth, ipw2100, ipw2200 et via-rhine. La liste complète des modules non reconduits dans RHEL 7 est disponible dans la section 4.4.1 du guide de migration.
Préconisations matérielles
Pour faire fonctionner RHEL 7, Red Hat recommande de disposer d'au moins 1 Go de mémoire vive (c'était déjà le cas avec RHEL 6). Dans les faits, il est possible de démarrer avec seulement 256 Mo de mémoire vive, mais il vaudra mieux en avoir 512 Mo pour ouvrir une session graphique (et il ne faudra pas être pressé). Du côté de l'installeur, celui-ci refusera de démarrer en dessous de 512 Mo de mémoire.
Pour ce qui est de la limite haute, Red Hat a augmenté le nombre de processeurs logiques que peut utiliser RHEL. Là où RHEL 6 en est actuellement à 4096 coeurs (en x86_64), la 7 monte jusqu'à 5120 ! Pour la mémoire vive, le maximum annoncé est de 64 To.
Gestion des performances
Performance Co-Pilot
Performance Co-Pilot est un outil de mesure, de surveillance et d’analyse des performances d’un système qui s’intègre avec les outils classiques (syslog…). Des détails sont disponibles aux liens suivants :
- http://developerblog.redhat.com/2013/11/19/exploratory-performance-pcp/ ;
- http://developerblog.redhat.com/2013/11/26/performance-regression-pcp/ ;
- http://blahg.josefsipek.net/?tag=pcp ;
- http://oss.sgi.com/projects/pcp/.
Tuned et profils Tuned
Tuned est un démon qui change la configuration du système (principalement le noyau) pour s'adapter à l'utilisation du système. Il permet de facilement configurer un système pour l'orienter performance ou économie d'énergie. Des profils par défaut sont fournis pour chaque variante de RHEL.
Affinité NUMA
La version du noyau incluse dans RHEL 7 améliore les performances pour les systèmes de type NUMA. Sur ces systèmes, les temps d'accès à la mémoire ne sont pas uniformes et dépendent de la proximité physique des barrettes de RAM. Il faut donc gérer la répartition de la mémoire judicieusement en fonction des cœurs sur lesquels les processus s'exécutent. C'est le noyau qui est chargé de cette optimisation pour réduire les communications inter-nœuds.
Mécanisme de remontée des événements matériels (HERM)
Diverses améliorations dans le noyau et un démon en espace utilisateur (rasdaemon) permettent d'obtenir des informations plus cohérentes sur les rapports d'événement matériel.
Stockage et systèmes de fichiers
XFS
Le système de fichiers utilisé par défaut lors de l’installation est maintenant XFS, qui succède à ext4. Btrfs est disponible lors de l’installation, mais n’est pas recommandé par défaut (aperçu technologique, non pris en charge pour la production).
Tant XFS que BtrFS (quand il sera pleinement pris en charge) voient leurs capacités prises en charge poussées 500 Tio par système de fichiers.
/tmp en tmpfs par défaut
Avec systemd vient le passage du répertoire /tmp au système de fichiers intégralement en mémoire tmpfs par défaut. Cela ne semble affecter que les machines physiques (les machines virtuelles ont un /tmp sur disque par défaut apparemment puisqu'il semble que systemd détecte qu'il n'est pas sur une machine physique). Cette fonction peut se désactiver très facilement (appliqué au prochain redémarrage) :
$ systemctl mask tmp.mount
ext4
Le système de fichiers ext4 prend désormais en charge des fichiers de 50 Tio contre 16 Tio auparavant.
Cache de périphérique blocs sur disque SSD
Un autre aperçu technologique de RHEL 7 est la possibilité d'utiliser un disque SSD PCIe comme cache intermédiaire pour des disques mécaniques plus lents, via lvm(8).
Virtualisation
Conteneurs Linux (LXC) et Docker
Les conteneurs permettent d'isoler des processus ou des environnements plus facilement et de façon moins lourde que les machines virtuelles sur un système. Ils sont particulièrement utiles lorsque l'on veut lancer plusieurs instances d'une application et qu'elles partagent des ressources (les binaires, les bibliothèques…). Les conteneurs sur RHEL 7 utiliseront quatre technologies introduites en partie dans les noyaux récents :
- les espaces de noms (namespace), qui sont de plusieurs types, et permettent principalement de mieux isoler les processus entre eux ;
- les Cgroups, qui facilitent la gestion dynamique et contrôlent l'accès aux ressources ;
- SELinux, chargé de la sécurité, de l'isolation et du contrôle d'accès pour les conteneurs ; il faut noter que le contrôle d'accès SELinux vise principalement à isoler les conteneurs entre eux et vis-à-vis du système, sans ajout de contrôle supplémentaire à l'intérieur du conteneur, lequel ayant d'ailleurs l'impression que SELinux est désactivé ;
- libvirt, qui permet d'administrer les conteneurs.
Pour pouvoir dupliquer rapidement des conteneurs, Docker utilisait le système de fichiers AUFS qui permet de faire des copies liées de systèmes de fichiers de façon très peu coûteuse en temps. Malheureusement, le système de fichiers AUFS n'est inclus ni dans le noyau upstream ni dans les noyaux des distributions autres qu'Ubuntu. Depuis la version 0.7, Docker peut utiliser d'autres méthodes de stockage (fichiers et dossier simples ou Device Mapper et LVM). C'était la raison principale qui retardait l'apparition de Docker dans RHEL, Fedora et les autres distributions. Attention cependant, Docker n'est pas disponible dans l'image ISO de base ou dans le canal de base, il faudra activer les dépôts "extras" et "optional", comme indiqué dans la documentation.
VMware
La machine virtuelle RHEL 7 dispose d'une meilleure intégration avec l'hyperviseur VMware vSphere, grâce notamment à l'ajout des Open VM Tools, fruit de l'ouverture partielle du code source des VMware Tools. La société VMware garde cependant certaines parties de ces outils en licence propriétaire. À noter aussi la prise en charge de l'accélération 3D matérielle dans les machines virtuelles (rendu OpenGL et X11), ainsi qu'un mécanisme de communication plus rapide entre celles-ci et le système hôte VMware ESX. Ces ajouts permettent l'exécution encore plus performante d'une machine virtuelle Red Hat Enterprise Linux fonctionnant sous VMware. Pour plus d'informations, VMware dispose d'une page dédiée à RHEL 7 sur son site.
Xen
Sans plus de détails, Red Hat indique que RHEL 7 fonctionne en tant que domU HVM sous Xen.
Hyper-V
RHEL 7 est utilisable comme machine virtuelle de génération 2 avec un hôte Microsoft Hyper-V Server 2012 R2. Cette deuxième génération permet entre autres d'avoir accès à Secure Boot, un UEFI ou de démarrer depuis un disque virtuel SCSI.
KVM
La solution privilégiée par Red Hat pour la virtualisation n'est pas en reste avec cette nouvelle version majeure de RHEL : il est possible de migrer une machine virtuelle d'un hyperviseur RHEL 6.5 vers un hypverviseur RHEL 7.0 en direct, sans arrêt. De plus, un nouveau périphérique, virtio-rng, pourra être accessible aux machines virtuelles pour qu'elles disposent de plus d'entropie, en provenance de l'hôte. Par défaut, l'hôte utilisera /dev/random, mais un générateur matériel de nombres aléatoires pourra être utilisé.
Côté invités, Red Hat annonce la possibilité d'utiliser les derniers systèmes de Microsoft, Windows 8 et Windows Server 2012.
Haute disponibilité et grappes de calcul
Dans ce domaine, le changement est flagrant : au revoir rgmanager, bonjour Pacemaker ! Du coup, le système de configuration, nommé pcs, remplace ccs, ricci et luci. Pacemaker apporte beaucoup, comme une synchronisation automatique de la configuration des ressources, des options de configuration de ressources basées sur l'heure, le fait d'avoir un outil de configuration en ligne de commande. Cela se fait malheureusement au prix de l’interopérabilité entre des nœuds RHEL 6 et 7 dans un cluster. Il sera sans doute préférable de créer un nouveau cluster RHEL 7 plutôt que de migrer progressivement un cluster existant sous RHEL 6.
Réseau
Dans les précédentes RHEL, pour agréger plusieurs cartes réseau, on utilisait le bonding. Red Hat a inclus dans RHEL 7 le teaming et recommande son utilisation. Si vous avez haï NetworkManager dans RHEL 6 au point de le désactiver dès que possible, du fait de son inadéquation à l'utilisation sur un serveur, sachez que vous avez peut-être été entendu. Non, NetworkManager n'a pas été sorti de RHEL, mais il a été amélioré sur ce point et vous disposez maintenant d'un outil nommé nmcli. Comme NetworkManager ne passe plus son temps à surveiller des modifications dans la configuration réseau, vous pouvez éditer celle-ci manuellement (ou déployer un nouveau fichier avec par exemple Puppet, Salt, Chef ou Satellite) et faire prendre en compte les modifications avec la commande nmcli connection reload.
Une autre nouveauté qui risque de surprendre se situe dans le pare-feu de RHEL, avec l'inclusion du pare-feu dynamique : firewalld. Celui-ci se base sur le concept de zones pour associer un niveau de confiance à un réseau. Son comportement peut s'adapter avec une configuration permanente et une temporaire. Il prend bien entendu en charge IPv4, IPv6, mais aussi les ponts Ethernet !
Développement
La nouvelle version de GCC (4.8) présente dans RHEL 7 ainsi que la nouvelle glibc permettent maintenant d'utiliser C++11, OpenMP v3.1, de nouvelles fonctionnalités pour Fortran et apportent de meilleurs avertissements et diagnostics. Bien entendu, une version plus récente de GDB accompagne tout cela, mais dispose en plus d'un nouveau paquet : gdb-doc. Comme son nom l'indique, il s'agit de la documentation, disponible dans les formats info, HTML et PDF.
Java est aussi de la partie, avec OpenJDK7 comme environnement par défaut. Vous pouvez toutefois installer les machines virtuelles d'IBM et d'Oracle en parallèle, comme pour les différentes versions du noyau Linux.
Dans les autres environnements notables, Python est maintenant disponible en version 2.7.5 (une version 3 sera accessible via les Software Collections) et Ruby arrive en version 2.0.0.
Authentification
Relations d’approbations entre domaines Identity Management et Active Directory
Un utilisateur possédant un compte sur un domaine Active Directory (Microsoft AD) pourra accéder aux ressources mises à disposition sur des serveurs RHEL sans avoir à effectuer une nouvelle authentification. Cela généralise le "single sign on" même s'il existe deux royaumes distincts pour Windows et Linux. C'est le serveur Red Hat Identity Management (projet FreeIPA, à base de Kerberos & LDAP) sous Linux qui établira une relation d'approbation avec le domaine AD. Il n'est pas nécessaire de synchroniser les bases d'utilisateurs.
Realmd
Pour faciliter la configuration pour le point précédent, le démon realmd se chargera de la découverte des royaumes Kerberos Linux et des domaines AD.
Sécurité
Les grands changements sont résumés dans la présentation de Dan Walsh au Red Hat Summit de cette année.
OpenSSH
La principale nouveauté vient avec la nouvelle version d'OpenSSH, qui apporte l'option ChrootDirectory. Cette option permet d'emprisonner l'utilisateur au niveau d'OpenSSH en plus de la possibilité déjà existante au niveau de SELinux.
Autre nouveauté en provenance d'OpenSSH, l'authentification multiple obligatoire. Il est déjà possible d'utiliser une authentification à deux facteurs, mais on peut augmenter la sécurité de son système en imposant celle-ci : cette possibilité se paramètre au niveau de l'option AuthenticationMethods.
Fonctionnalités liées à systemd
journald
RHEL 7 utilise toujours un démon de type syslog par défaut pour stocker les logs du système dans divers fichiers. En revanche, les logs sont d'abord collectés par journald qui les retransmet ensuite au démon syslog.
Il était auparavant difficile de vérifier qu'un message de log avait bien été émis par le démon indiqué dans les logs car syslog ne gardait que très peu d'informations liées à l'identité du processus émetteur de logs. Par exemple, si le démon ntpd venait à être compromis par un attaquant, celui-ci pouvait émettre des logs ressemblant à ceux produit par sshd et ainsi influencer le comportements d'outils tels que fail2ban se basant sur les logs de sshd.
Ce comportement est toujours possible, mais il est désormais très facile de le détecter car journald conserve des informations supplémentaires :
...
SYSLOG_IDENTIFIER=sshd
SYSLOG_PID=2302
MESSAGE=Faux message provenant de sshd...
_PID=2302
_UID=0
_GID=0
_COMM=ntpd
_EXE=/usr/sbin/ntpd
_CMDLINE=/usr/sbin/ntpd -n -u ntp:ntp -g
_SYSTEMD_CGROUP=/system/ntpd.service
_SYSTEMD_UNIT=ntpd.service
_SELINUX_CONTEXT=system_u:system_r:ntpd_t:s0
_SOURCE_REALTIME_TIMESTAMP=1330527027590337
_BOOT_ID=4c3d0faf6b774fb7930972c1a4a5f870
_MACHINE_ID=432d8198a8fc421caf2dca48ccde1cf2\
_HOSTNAME=www.example.com
...
Plus de détails sur le blog de Red Hat lié à la sécurité.
Démarrage des démons avec systemd
L'ensemble des démons est maintenant démarré et géré par systemd. Les administrateurs ne doivent ainsi plus se charger de redémarrer les démons directement, c'est systemd qui s'en charge. Il peut ainsi :
- s'assurer que l'environnement est bien contrôlé (entre autres que les variables d'environnement n'ont pas été modifiées) ;
- s'assurer que le démon a accès au dossier courant lors de son exécution ;
- rediriger les entrées/sorties du terminal vers journald, par exemple pour récupérer tous les logs d'erreurs qui auraient été perdus autrement ;
- ouvrir des sockets auxquelles le démon n'aura pas nécessairement accès, si il est exécuté avec moins de privilèges ;
- changer la gestion des signaux par défaut ;
- …
Enfin, cela simplifie les règles de changement de contexte SELinux et améliore ainsi la sécurité.
Plus de détails sur le blog de Red Hat lié à la sécurité.
Répertoire /tmp privé
Le répertoire /tmp était couramment utilisé par les démons d'un système pour stocker des fichiers temporaires, sockets ou des FIFO. Or ce dossier est accessible à tous les utilisateurs ce qui a causé de nombreux problèmes de sécurité (par exemple CVE-2011-2722) lorsque la manipulation des fichiers n'était pas faite de façon très précautionneuse par rapport à la sécurité.
La plupart des démons utilisent maintenant des sous-dossiers de /run avec des permissions restreintes pour stocker leurs données temporaires. Mais certains projets sont récalcitrants et certains programmes ne peuvent aussi pas être changés (logiciels propriétaires, notamment). Pour ceux-ci, l'option PrivateTmp des fichiers d'unit systemd permet de créer un dossier à accès restreint, dont l'usage sera transparent pour l'application.
Ainsi, avant de démarrer un service, systemd :
- crée un dossier tmp avec un nom imprédictible en utilisant la fonction
mkdtemp; - crée un nouvel espace de nom de système de fichiers (file system namespace) pour que les changements n'impactent pas tout le système, mais uniquement le démon et ses fils ;
- monte avec l'option
bindle dossier créé par-dessus le dossier/tmp; - démarre le service.
Plus de détails sur le blog de Red Hat lié à la sécurité.
SELinux
Association d’étiquette SELinux automatique en fonction du nom de fichier
Le contrôle d'accès effectué par SELinux est basé sur des labels que l'on va attacher aux divers éléments d'un système (fichiers, sockets, processus…). Pour qu'un système fonctionne correctement, il faut que ces labels correspondent aux règles définies dans la politique SELinux. Un problème fréquent se produisait lorsqu'un administrateur ou un utilisateur créait des dossiers ou fichiers et que les labels utilisés par défaut ne correspondaient pas à ce qui était attendu dans la politique SELinux.
Les deux exemples récurrents sont :
- la création du dossier
.sshdans le répertoire/root: le dossier recevait alors le labeladmin_home_tpar défaut alors que la politique est conçue pour que ce dossier soit labelliséssh_home_t, Le démon sshd (utilisant le labelsshd_t) ne pouvait alors pas accéder au contenu de/root/.sshet refusait les connexions à l'aide de clé publique par exemple ; - la création du dossier
public_htmldans le répertoire personnel d'un utilisateur : le dossier recevait alors le labeluser_home_tmais la politique par défaut utilise le labelhttp_user_content_t, L'accès à ces dossiers était donc refusé à Apache (avec le labelhttpd_t).
Dans les deux cas, l'utilisateur devait corriger manuellement le label de ces dossiers et fichiers avec la commande :
$ restorecon -Rv /home/user/public_html
Une première amélioration avait été apportée par l'ajout dans la politique de règles de changement automatique de labels pour les fichiers (file transition rule). Ces règles permettaient d'indiquer par exemple que les fichiers créés par les processus labellisés NetworkManager_t dans le dossier labellisé etc_t (/etc) seraient automatiquement de type net_conf_t. Exemple :
filetrans_pattern(NetworkManager_t, etc_t, file, net_conf_t)
Cette règle n'est cependant pas optimale car elle autorise NetworkManager à créer n'importe quel fichier qui n'existerai pas déjà dans un dossier labellisé etc_t (/etc/) et à lui donner le contexte net_conf_t. Elle ne permets pas non plus de contrôler le label du dossier .ssh lors de sa création par un utilisateur. Une règle du type :
filetrans_pattern(unconfined_t, user_home_t, file, ssh_home_t)
forcerait tous les fichiers du répertoire d'un utilisateur a être labellisé ssh_home_t, ce qui n'est pas vraiment le but recherché.
Eric Paris a ainsi travaillé sur la gestion (dans la politique et dans le noyau) d'un quatrième argument pour cette règle : le nom du fichier créé (sans le chemin d'accès). Cette règle permet d'exprimer ainsi facilement les deux cas de figure cités au-dessus :
- si un processus
unconfined_tcrée un dossier.sshdans un dossieradmin_home_t, alors il sera créé avec le labelssh_home_t:
filetrans_pattern(unconfined_t, admin_home_t, directory, ssh_home_t)
- si un administrateur (
staff_t) crée un dossierpublic_htmldans un dossier labelliséuser_home_t, il sera labelliséhttp_user_content_t:
filetrans_pattern(staff_t, user_home_t, directory, http_user_content_t)
D'autres règles ont aussi été ajoutées pour s'assurer que les fichiers créés dans /dev soient automatiquement labellisés avec les bons contextes sans avoir à attendre qu'udev fixe le contexte.
Cette règle permet aussi de restreindre NetworkManager à la création du seul fichier resolv.conf dans un dossier etc_t.
Plus de détails sur le blog de Red Hat lié à la sécurité.
Aide à la rédaction de politiques
Un nouveau document d'introduction à l'écriture de politiques SELinux a été rédigé entre autres par Dan Walsh. Il est disponible à cette adresse sur le blog orienté développeur Red Hat de Dan Walsh.
Il détaille le processus de création de politique en utilisant les outils sepolicy generate et audit2allow. L'outil sepolicy generate :
- génère la base d'une politique à partir des réponses à des questions de type « Mon programme est-il un démon ? » ;
- prépare un fichier
.specpour construire un paquet RPM pour distribuer facilement la politique sur un ensemble de machines ; - crée une page de man expliquant la politique venant d'être écrite.
Chiffrement
Les récentes versions de RHEL 6 avaient apporté la prise en charge des courbes elliptiques dans le chiffrement pour un certain nombre de paquets. Dans RHEL 7, nss a été mis à jour et apporte de nouvelles suites de chiffrement et fait disparaître MD2, MD4 et MD5 dans le cas des CRL.
Durée de vie
Enfin, et pour conclure sur cette nouvelle version, il convient de rappeler que RHEL 7 disposera d'une durée de vie de 10 ans (13 avec le support étendu, tout comme RHEL 5 et 6).
Aller plus loin
- Red Hat (642 clics)
- DLFP : Red Hat Enterprise Linux 6.5 (798 clics)
- DLFP : Red Hat Enterprise Linux 5.10 (108 clics)
- Annonce de RHEL 7 (248 clics)
- Red Hat Developer Blog : Red Hat Announces RHEL 7 Beta! (61 clics)
- Acheter RHEL (199 clics)
- Annonce de la Release Candidate (33 clics)
- Presentations du Red Hat Summit 2014 (36 clics)
- Annonce de la version bêta (23 clics)
- Annonce de la Release Candidate (17 clics)
- Notes de version (la version anglaise est plus récente) (150 clics)
- Notes de version (97 clics)
- Documentation RHEL 7 (279 clics)
- Documentation RHEL 7 (en cours de traduction) (842 clics)
# Systemd
Posté par Prosper . Évalué à 10.
Enfin une distribution d'envergure qui utilise systemd :)
Ca a l'air sympathique au premier abord, quelques commandes a réapprendre mais c'est pas la mort , tout le reste ca n'est que du plus.
[^] # Re: Systemd
Posté par GeneralZod . Évalué à 3.
Je connais une distro d'envergure qui l'utilise depuis 3 ans et qui sert d'upstream à RHEL: Fedora !
Un billet de Robyn Bergeron, Fedora Project Leader récemment retiré sur la contribution de Fedora à RHEL7: http://robyn.io/2014/06/10/rhel-is-beefy/
PS: par contre, c'est la première distro entreprise à utiliser systemd ;)
[^] # Systemd : bientôt sur SUSE Linux Enterprise
Posté par Sylvain Blandel . Évalué à 2.
Oui, et d'après cette page, la prochaine version majeure de SUSE Linux Enterprise (la version 12) utilisera elle aussi systemd. On trouve également des références à systemd dans les notes de publication de la (future) version 12 de SUSE Linux Enterprise Server.
Cette évolution n'est guère étonnante : openSUSE utilise systemd depuis novembre 2011.
Que va-t-il rester comme distributions n'utilisant pas systemd par défaut ?
[^] # Re: Systemd : bientôt sur SUSE Linux Enterprise
Posté par Zenitram (site web personnel) . Évalué à 2.
Pas foule, et de moins en moins au fur et à mesure que personne ne se tapera les configurations des autres systèmes d'init.
systemd a réussi le pari de les réunir (quasi-)tous. Bravo à lui, dans le monde libre c'est un exploit que d'avoir presque tout le monde d'accord sur une chose! C'est rare (le noyau Linux est la référence des noyaux dans le monde libre, et quoi d'autre qui a réussi l'exploit de réunir tout le monde? Je ne sais pas trop si on peut mettre Firefox car il y a quand même WebKit et Chronium)
il y a juste quelques grincheux, qui n'aiment pas apprendre de nouveaux outils car ils connaissent un truc qui marche même si ça fait moins bien son boulot, qui vont hurler pendant quelque années que c'est de la merde et plus tard tairont leur passé à ce sujet. je suis d'ailleurs étonné qu'ils ne se soient pas encore manifestés sur cette dépèche.
[^] # Re: Systemd : bientôt sur SUSE Linux Enterprise
Posté par patrick_g (site web personnel) . Évalué à 9.
Glibc ? Xorg ?
Tu vas les voir sortir de leur trou à trolls quand la news systemd sera publiée demain ;-)
# systemday
Posté par Anonyme . Évalué à 2.
Mais encore ?
[^] # Re: systemday
Posté par Maz (site web personnel) . Évalué à 2.
J'avoue que c'est assez confus dans la dépêche.
J'ai l'impression qu'il y a amalgame de 2 informations :
1) Tous les daemons sont gérés par systemd dans la version 7.
2) systemd a une option, Restart, qui permet de relancer les daemons qui se sont arrếtés, à la daemon-tools, qui n'existe pas avec upstart.
Sur le second point, je ne suis pas sûr que les daemons soient configurés pour redémarrer automatiquement. Je vérifierai avec la CentOS quand elle sortira.
[^] # Re: systemday
Posté par Misc (site web personnel) . Évalué à 3.
A vue de nez, la plupart ne le sont pas. j'ia 157 services sur mon serveur, et un grep me dit ça:
Il y a sshd qui est relancé en cas de plantage et surtout des services comme systemd ou les ttys.
[^] # Re: systemday
Posté par Bigon . Évalué à 7.
La commande "systemctl (re)start foo" envoie maintenant une requête au PID1 qui va se charger de (re)démarrer le daemon.
Ça peut avoir de l'importance par exemple pour les variables d’environnement et SELinux. Pour le moment si un utilisateur appelle directement l'initscript, des variables d’environnement peuvent se propager dans l’environnement du daemon, avec systemd ce n'est plus possible. Pour SELinux le daemon est toujours démarré depuis le contexte du init ça évite donc les risque que le domaine du daemon soit incorrect.
[^] # Re: systemday
Posté par barmic . Évalué à 3.
Ouai mais c'est pas un argument terrible ça, d'une part les scripts peuvent le faire d'autre par le standard c'est d'utiliser la commande service. Ce qui ne respectent pas le standard c'est un peu à eux de se gérer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemday
Posté par gnumdk (site web personnel) . Évalué à 0.
Non, avec systemd, la commande c'est pas service mais systemctl
[^] # Re: systemday
Posté par barmic . Évalué à 9.
systemd ou pas, le standard LSB c'est service.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemday
Posté par Bigon . Évalué à 5. Dernière modification le 11 juin 2014 à 16:02.
La commande service devrait rediriger vers systemctl (en tout cas sur Debian c'est le cas)
Pour le nettoyage de l’environnement oui les init scripts peuvent faire ça. Pour SElinux, les script ne savent pas le faire et peu de personnes utilisent la commande run_init.
[^] # Re: systemday
Posté par barmic . Évalué à 3.
Ce que je dis c'est qu'avec initsysv elle était capable d'avoir un environnement propre.
Pour SElinux, je sais pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Blogs ou bonnes sources sur RHEL ?
Posté par fraaargh . Évalué à 4.
Bonjour à tous,
je profite de ce billet pour vous demander si vous connaissez de bonnes sources de documentation sur RHEL. Des blogs, des wiki ou des recueils d'astuces, etc… En fait je demande ça car je suis un habitué de Ubuntu, je sais rajouter des PPA pour avoir des logiciels plus à jours par exemple mais je vais bientôt devoir passer à RHEL professionnellement et je n'ai aucune idée de par ou commencer, ni comment me tenir informé de l'actu, des astuces, sur ce système. Par exemple, quand mon admin m'aura installé RHEL, comment je fait pour installer KDE ? Et idéalement une version up to date :)
J'ai eu beau cherché un peu sous Google, j'ai l'impression qu'il n'y a rien pour ce que je cherche (ou du moins pas aussi visible que pour Ubuntu, ou alors je cherche mal).
Voila, amateurs de RHEL, c'est l'heure de partager vos liens avec moi !
[^] # Re: Blogs ou bonnes sources sur RHEL ?
Posté par romu . Évalué à 2.
Salut,
Pour RHEL je ne sais pas, mais je suis passé de Ubuntu à Fedora avec bonheur. C'est quasiment pareil, tu as accès au mot clé "sudo" pour exécuter en mode admin, tu as la notions de dépôt (sauf que les paquets sont en rpm et pas en deb)…bref, quelques heures pour s'y faire au début, mais franchement, c'est pas la mort, on retrouve vite ses marques.
J'imagine que le site Fedora-FR te sera une bonne source d'info, même pour RHEL.
[^] # Re: Blogs ou bonnes sources sur RHEL ?
Posté par chdorb . Évalué à 3.
Tu peux te tourner vers la communauté Fedora, c'est la « base » de RHEL, ou encore CentOS, la RHEL « déredhatisée ».
[^] # Re: Blogs ou bonnes sources sur RHEL ?
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 5.
Salut,
D'abord, l'admin peut installer KDE durant l'installation, c'est inclus dans la distribution ;) ensuite, comme indiqué dans la dépêche, c'est la version 4.10, cela devrait donc être suffisant.
Concernant les dépôts, chez Red Hat, tu vas être intéressé par :
- le canal de base, indispensable ;
- le canal "optional", dont le nom est assez explicite je pense ;
- le canal "supplementary" qui contient essentiellement des logiciels non-libres (Adobe Reader et Flash Player par exemple) ;
- le canal "Oracle Java" qui, comme son nom l'indique, contient différentes machines virtuelles Java éditée par Oracle, ce qui t'évite d'aller la chercher manuellement sur le site de l'éditeur ;
- "Red Hat Software Collections", sorti en version stable depuis la dépêche publiée précédemment.
Ensuite, il y a d'autres dépôts, externes à Red Hat (donc aucun support de la part de Red Hat), assez bien listés par cette page du wiki CentOS. Attention, tous ne sont pas encore prêts pour EL7. Je rajouterais à cette liste le dépôt de Nginx, qui te fournira une version encore plus récente que celle disponible dans EPEL ou dans Software Collections.
[^] # Re: Blogs ou bonnes sources sur RHEL ?
Posté par Maz (site web personnel) . Évalué à 7.
Tout d'abord, RHEL est une distribution très tournée entreprise et support à long terme. Il y a donc beaucoup moins, à ma connaissance aucun, dépôts avec les dernières mises à jour, comme les PPA d'Ubuntu.
Cela dit :
Documentation officielle de RHEL 7
Wiki de CentOS
Documentation officielle de Fedora
Dépôt EPEL
Dépôt RPMFusion
Pour avoir des paquets à jour, tu peux peut-être essayé 0install ou Nix. Personnellement, j'utilise plutôt Archlinux pour avoir un système à jour, donc je ne sais pas ce que donne ces solutions.
[^] # Re: Blogs ou bonnes sources sur RHEL ?
Posté par bubar🦥 (site web personnel) . Évalué à 9. Dernière modification le 13 juin 2014 à 19:15.
yum install
Pas possible, on prends la version livrée par Redhat et on s'en tiens aux préconisations de l'éditeur. Il n'y a pas de notions de "multiples ppa" dans la nature (Il y a EPEL) Donc le KDE sera figé en version.
Ou bien tu te lances dans le bricolage (point de vue éditeur) et alors se pose la question de la pertinence du choix de la distrib. Pourquoi pas plutôt Fedora si tu souhaites avoir un système à la fois stable et totalement à jour ?
Un autre exemple : EXT4. Dans RHEL 6 nous avions une limitation à 16T (exemple : tu poses un LVM directement sur une lun non partitionnée, impossible de faire un LV au delà de 15.5T en ext4). Il ne s'agit pas d'une limitation d'ext4 en soi, mais d'une version de e2fsprog d'une part (partie visible) et -surtout- des backports fait par redhat pour ext4 d'autre part. C'est similaire à ta question, car là aussi il est possible de sortir du cadre des recommendations de l'éditeur (en faisant une mise à jour du noyau en vanille, et en recompilant une x.42.3 de e2fsprog) OK OK c'est possible. Mais une redhat c'est pas fait pour bricoler. Et bricoler c'est faire ce qui est dehors des docs de limites et des docs de recommendations.
Ma réponse est certainement pas celle que tu attendais (et elle ne porte en aucune manière d'autre affirmation que mon opinion) mais c'est comme ça, à mon sens : Redhat on installe et on utilise. On ne sort pas des clous qui ont donnés tant de mal à être plantés.
[^] # Re: Blogs ou bonnes sources sur RHEL ?
Posté par vieuxshell (site web personnel) . Évalué à 1.
On ne sort pas des clous, en regle générale oui.
Mais avec les Software Collections ca bouge pas mal (au moins du point de vue applicatifs)
[^] # Re: Blogs ou bonnes sources sur RHEL ?
Posté par Michel Nicolas (site web personnel) . Évalué à 6.
Je suis étonné que personne ne mentionne l'excellente documentation RedHat (s'applique à Centos aussi!):
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/
[^] # Re: Blogs ou bonnes sources sur RHEL ?
Posté par Maz (site web personnel) . Évalué à 5.
Genre le lien que j'ai posté il y a 2h ?
:p
[^] # Re: Blogs ou bonnes sources sur RHEL ?
Posté par bubar🦥 (site web personnel) . Évalué à 2. Dernière modification le 11 juin 2014 à 18:43.
Dans le même esprit que la doc redhat, les petites vidéos. Claires, sans bullshit, faites par des techos, et qui ne cachent rien. Exemple, pour tuned, une petite vidéo parlante et montrant les élements de confs impactés : https://access.redhat.com/site/videos/898563
[^] # Re: Blogs ou bonnes sources sur RHEL ?
Posté par Zorro (site web personnel) . Évalué à 6.
Si tu es habitué d'Ubuntu, et que par conséquent tu aimes bricoler et rajouter des sources pour avoir des logiciels récents, alors tu vas t'ennuyer… RH s'adresse aux entreprises, c'est une distro ultra-conservatrice, peut-être la plus conservatrice de toutes.
Là, ça va encore bien, elle vient de sortir. Mais tu verras dans 3 ans, quand elle aura encore 3 ou 5 ans et que auras toujours les mêmes versions des logiciels qu'en ce moment, tu vas découvrir que l'ennui est le meilleur ami du sysadmin consciencieux… :)
Imagine-toi bien que CentOS 6.5 (qui correspond donc à RHEL 6, mais en version "gratuite"), c'est encore un noyau 2.6, un Gnome 2, qu'on peut pas y mettre Google Chrome sans utiliser un script et des rpm bricolés par un particulier. Et que dire des dépôts faméliques, quand tu es obligé de te compiler toi-même ton Tint2 (une barre pour Openbox), ou une version anté-diluvienne de Liferea pour suivre tes RSS dans Gnome parce que les versions récentes utilisent des bibliothèques pas dispo pour CentOS 6.5 et qu'aucun dépôt ne le propose…
En revanche, l'intégration avec les logiciels proprio et professionnel, là, c'est que du bonheur. Pouvoir installer VMware Workstation 8 en mode graphique rien qu'en cliquant, et voir les modules se compiler tout seul, en mode graphique aussi, je dois dire que ça fait assez léché.
Enfin, bref, tu vas vite comprendre que l'univers RH/CentOS, c'est performant et stable, mais qu'on n'est pas là pour s'amuser.
Vivement des ArchLinux en prod', tiens !!!
# Alors...
Posté par xcomcmdr . Évalué à 9.
Il peut faire ça SysV ? ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Gnome 3
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
Oui RedHat 7 est livrée avec Gnome 3.8 (et donc gnome-shell) pour l’environnement de bureau, mais…
l'extension "classique" (qui reproduit donc l’expérience de GNOME 2 avec les technologies de GNOME 3) est activée par défaut !
conclusion: on peut prendre les utilisateurs du bac à sable Fedora pour des cons, mais pas les clients qui payent quand même
[^] # Re: Gnome 3
Posté par Prosper . Évalué à 1.
La volonté est peut être de pas trop brusquer les choses visuellement. Enfin bon, d'un autre coté le système d'init lui, change complètement…
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . Évalué à 10.
Ce qui est amusant avec les gens qui rale sur un réglage par défaut, c'est que quand RHEL et Fedora font la même chose, c'est la main mise de RH sur Fedora qui est en cause.
Quand c'est le contraire, c'est la main mise de RH qui fait en sorte que les gens qui payent se retrouve avec un réglage par défaut différent.
Si la mauvaise foi était un carburant, on serait déjà sur alpha du centaure depuis 20 ans…
[^] # Re: Gnome 3
Posté par Pierre Tramo (site web personnel) . Évalué à 9.
Je pense que tu n'as pas saisis mon point de vue qui est :
l'expérience utilisateur gnome 3 est un échec total.
Les utilisateurs qui paient (entre autre les salaires des devs/designers redhat qui pondent cette horreur) n'en veulent pas. Livrer gnome 3 avec l'extension classique activée c'est un rétro pédalage dans les règles de l'art.
la mauvaise foi serait de nier ce fait
[^] # Re: Gnome 3
Posté par MTux . Évalué à 9. Dernière modification le 11 juin 2014 à 15:57.
Quelques points :
1. Sur Fedora on peut avoir Gnome-classic (pas activé par défaut certes, mais facilement)
2. Il fallait bien le faire tester par quelqu'un pour décider si oui ou non il sera bien accepté dans la version entreprise… or fedora sert à ça.
3. Redhat paie quand meme pour une super distro (fedora) gratuite pour tous, on peut donc pas vraiment dire qu'ils prennent les utilisateurs pour des cons.
[^] # Re: Gnome 3
Posté par Atem18 (site web personnel) . Évalué à 5.
Ah oui, ça marche aussi. :D
[^] # Re: Gnome 3
Posté par romu . Évalué à 4.
Des sources, des références pour affirmer que Gnome 3 est un échec total ?
Des gens ont râlé au début, oui, comme pour KDE4 d'ailleurs, et puis les temps faisant son oeuvre, force est de constater que les râleurs se calment, voire reviennent vers Gnome (Linus par exemple). Alors de quelques cas, on ne va pas faire une généralité non plus, mais je crois que de telles assertions sont à modérer…ou à argumenter.
Et moi, j'utilise Gnome 3 avec bonheur chez moi et à mon boulot, mais je suis surement un cas particulier.
[^] # Re: Gnome 3
Posté par barmic . Évalué à 3.
Je crois qu'il est sous KDE (il a fait KDE3.5 -> Gnome2 -> XFCE -> KDE4 si je ne m'abuse).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gnome 3
Posté par david.g . Évalué à 1.
D'après Phoronix il serait sous GNOME 3.
Pour moi le fait que RHEL 7 utilise la version "classique" de GNOME 3, ça prouve déjà qu'il est possible d'avoir plusieurs expériences utilisateur avec GNOME 3. De plus il existe un grand nombre d'extension pour le personnaliser et atténuer ses supposés défauts.
J'ai un peu trainé les pieds avant de passer à GNOME 3, mais depuis que je m'y suis mis et que je reviens sous un GNOME 2 et bien je ne le trouve plus aussi sympatique.
C'est visiblement très à la mode de faire du Gtk/GNOME bashing, mais il ne faut pas confondre ses désires et la réalité.
[^] # Re: Gnome 3
Posté par Ichigo-Roku . Évalué à 2.
Je ne pense pas que ce soit vraiment du Gtk/GNOME bashing. C'est surtout du bashing de tout ce qui est nouveau. Ça ne fait pas très longtemps que je suis dans le monde GNU/Linux, environ 7 ans, mais à chaque changement ça bash.
Les exemples que j'ai en tête : lors du passage à KDE4, lors du passage à GNOME3, sur Arch Linux lors du passage à systemd (je me doute bien que les réactions fussent les mêmes ailleurs que sur Arch Linux), et pour finir sur Ubuntu avec Unity.
Même si je suis utilisateur de DWM, je trouve dommage que ça bash autant pour rien sur KDE/GNOME, pour ne citer qu'eux. Je ne comprends pas pourquoi autant de gens sont contre le moindre changement.
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . Évalué à 10.
Je ne pense pas que ces gens soient contre le changement d'une manière absolu. Mais j'imagine que ces gens se disent "c'est du libre donc je fait ce que je veux" et retombe de haut quand ils découvrent que leur liberté dépend surtout de tout les autres gens qui font le travail.
C'est l'exemple de KDE4, de Gnome3, de systemd. Tout des choix qui ont apportés des changements visibles, sur des sujets familiers, à un rythme décidé par quelqu'un d'autre.
Et c'est la réalisation que l'indépendance qu'on leur a donné comme allant de paire avec le libre a un prix parfois exorbitant qu'ils n'avaient pas vu qui fait un choc. Que le libre n'est pas une démocratie, que les dirigeants sont totalement sourds à leur demande, et qu'au final, ils ne sont rien dans une hiérarchie qui soudain se dessine. Et donc, que râler et partir sont les seuls choses qu'ils peuvent faire dans leur majorité.
Partir, ça arrive toujours. Râler de façon récurrente et longue, par contre, je trouve que ça fascinant. Par exemple, sur slashdot, y a un mec qui poste dans toute les dépêches en lien avec RHEL pour dire qu'il a déployé pacemaker en 6.3 et qu'il a été retiré ensuite, donc que RH l'a trahi. Et y a toujours 3 personnes qui vont lui dire "c'était marqué comme technology preview, c’était donc possible et non couvert par un support longue durée". Malgré ça, le mec reste sur sa position, car il n'arrive pas à se remettre en cause.
[^] # Re: Gnome 3
Posté par Okki (site web personnel, Mastodon) . Évalué à 3.
Aucune idée s'il a encore changé entre temps, mais l'an passé, il semblait être revenu sous GNOME ;)
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . Évalué à 5.
en effet. En parti parce qu'il se base sur pas grand chose, et en partie parce que même si j'avais pu lire dans tes pensées, ça ne reste qu'un point de vue.
Je connais des gens satisfait, et en proportion, pas mal de gens parmi les utilisateurs de gnome 2 autour de moi. Les KDEistes sont restés sous KDE, etc. Ensuite, je vais pas dire que je connais que des gens satisfaits, mais la présence d'alternative à Gnome 2, à KDE et à d'autres depuis longtemps montrent bien qu'il y a des gens qui veulent autre chose, même avec ce gnome 2 si génial qu'on nous en parle à chaque fois.
Passer de ça à "un echec total", j'ai des doutes (je ne dirait pas "mauvaise foi", car j'ai le sentiment que ça te vexerais comme un pou ). Je m'en sert tout les jours et j'ai pas eu envie de m'arracher les yeux, on me force pas à l'utiliser ni rien.
Livrer mate serait un rétro pédalage. Ou ne pas supporter le mode non classique serait un rétro pédalage. La, c'est une transition en douceur pour les utilisateurs du desktop RHEL, qui ne sont pas les mêmes utilisateurs que Fedora. Fedora vise les gens qui veulent expérimenter et découvrir les derniers trucs du libres. RHEL vise les gens qui veulent la continuité, et tout comme l'intégration de docker et des scl, tout comme le support des scripts d'init, RHEL vise la migration au rythme des gens.
Mais je suis pas la pour faire la pub de la distro. Je constate juste que dans la mesure ou l'extension classique ne modifie pas les applications, alors on peut aussi dire que pour un truc que tu qualifie de retro pédalage dans les règles de l'art, ça manque de profondeur. L'expérience utilisateur reste quand même profondément changé par les applications. Donc si ton propos est que les changements entre Fedora et RHEL sont un retro pédalage, alors il est simple de déduire que tout ce qui n'a pas changé est une validation pur et simple de tout le travail des designers gnomes, donc de la grande partie de l'expérience utilsiateur, qui va au dela du bureau.
Mais je pense que tu es juste allergique aux changements de gnome-shell pour divers raisons, et que tu cherches à te rassurer sur ton opinion en ralant ici ou sur irc à longueur de temps.
[^] # Re: Gnome 3
Posté par Zorro (site web personnel) . Évalué à 1.
Gnome 3 est un plaisir de tous les instants à utiliser.
Je pense même, sans rire, que c'est la meilleure chose qui soit arrivée à l'informatique personnelle depuis la généralisation de la mémoire Flash et le Wi-Fi.
Les designers de Gnome 3 ont peut-être fait des paris un peu fou (tout axer sur l'interface tactile, alors que visiblement tout le monde s'en fout : les PC de bureaux à écran tactile sont une micro-niche et Gnome sur tablette, heu…) mais ils ont le mérite d'avoir repensé les choses.
Maintenant les conservateurs qui réclameront, encore dans 30 ans, leurs bons vieux paradigmes à la Windows 95, ont bien sûr droit à la parole, mais qu'ils ne viennent pas clamer ça comme une vérité, ça serait la moindre des choses.
[^] # Re: Gnome 3
Posté par Anonyme . Évalué à 4.
Mais pourquoi tout le monde semble dire que Gnome 3 est axé sur le tactile ? Qu'est ce qu'il y a d'axé sur le tactile dans Gnome 3 ?
[^] # Re: Gnome 3
Posté par ckyl . Évalué à 4.
Je suis d'accord avec toi, SAUF POUR CE FOUTU SLIDER DU SCREEN LOCKER. Sérieusement quoi…
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . Évalué à 2.
Il se retire aussi avec esc ou quand tu commence à taper le mot de passe. Et le fait de ne pas se retirer quand tu touches la souris, c'est pour pouvoir mettre un widget (genre dans mon souvenir, tu peux couper la musique directement sur le screensaver).
Je pense qu'il y a aussi des idées pour un déverrouillage par pin code (https://wiki.gnome.org/Design/OS/ScreenLock/PinAuthentication) mais pour le moment, personne ne bosse dessus (ou il y a des soucis compliqués à résoudre). L'idée serait je pense un jour d'avoir un truc pour tablette ou écran tactile. Mais c'est pas encore ça.
[^] # Re: Gnome 3
Posté par gnumdk (site web personnel) . Évalué à 2.
Ça tombe bien, les devs de GNOME passent leur temps à dire que GNOME3 n'est pas pensé pour le tactile!
Et perso, je veux bien que ce soit un succès GNOME Shell mais pour l'instant, je ne l'ai pas vu souvent tourner chez les gens… (par rapport à l'époque de GNOME2… Mais il faut dure que Unity y est pour beaucoup… Je vois pas plus KDE…)
[^] # Re: Gnome 3
Posté par Zorro (site web personnel) . Évalué à 2.
Se tourner vers le tactile était pourtant bien dans les orientations du menu Applications (grosses icônes, pages d'icônes qu'on fait défiler d'un glisser de doigt, comme sous Android), et dans la simplification (peut-être un peu excessive, j'admets) de Nautilus/Fichiers : plus d'onglets, plus de vue en arborescence, mais une préférence pour les raccourcis. Même la simplification du menu système, en haut à droite, qui ne nécessite plus de devoir viser l'une ou l'autre icône (on clique sur n'importe laquelle et l'ensemble des commandes apparaît).
Et j'ai souvenir d'avoir lu ça dans une interview, à l'époque de la sortie de Gnome 3, avec l'un des dev, mais alors je sais plus du tout où (peut-être sur WorldOfGnome ?)
Mais c'est sûr que maintenant que le tactile n'a pas vraiment décollé (en tout cas, pas avec Gnome 3), ils se sont un peu calmés.
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . Évalué à 3.
Les grosses icones, c'est aussi pour les souris (car les gens qui n'ont pas l'habitude d'une souris ont parfois du mal, et j'invite les gens à filer une souris à quelqu'un qui n'a jamais touché le mulot pour voir), et pour avoir des choses visuellement plus jolis.
Et il y a aussi le fait d'avoir une interface qui se rapproche des tablettes car c'est par la qu'on estime que les gens vont commencer leur apprentissage de l'informatique de nos jours. Donc en ayant un paradigme pas trop éloigné, on estime que la courbe d'apprentissage sera moins abrupte.
Pour faire vraiment du tactile, il faudrait plus de choses à tout les niveaux, comme un clavier tactile (notamment pour déverrouiller). Il faut des applications adaptées et les drivers d'écrans tactiles, sans doute une applet de calibration.
Et bon, on peut dire ce qu'on veut, je doute qu'un mode de recherche au clavier (comme l'overview de gnome shell) soit très tablette friendly, donc je pense qu'il faudrait changer ça aussi. Et sans doute agrandir le menu et la barre du haut, à vue de nez. j'imagine qu'un vrai test sur une tablette donnerais plein de trucs à corriger.
[^] # Re: Gnome 3
Posté par KiKouN . Évalué à 2.
Et je vous raconte pas quand le gars à une souris de gamer avec des paramètres de ouf qui permet de faire un n-tuple axel à devenir l'objet de désirs de Philippe Candeloro.
[^] # Re: Gnome 3
Posté par ariasuni . Évalué à 3.
D’après ce que j’ai compris, ils voulaient faire en sorte que GNOME Shell fonctionne bien en tactile pour les ordinateurs portables à écran tactile, ce qui n’est pas une mauvaise idée.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Gnome 3
Posté par zebra3 . Évalué à 3.
Et pourtant, c'est sur tous les OS pour tablette ou smartphone.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Gnome 3
Posté par Misc (site web personnel) . Évalué à 3.
Certes, pour les contacts ( je pense que tu parles de ça ), mais ça ne parait pas être le paradigme premier d'usage.
En tout cas, pas sur mon vieux android ou mon nokia.
[^] # Re: Gnome 3
Posté par zebra3 . Évalué à 3.
Ah non je parle de tout :-)
Il y a même un bouton physique pour chercher sur quelques Android 2.x que j'ai vus. Et bien souvent il y a par défaut un widget de recherche.
Côté Nokia j'avoue que je me suis arrêté à Symbian. Mon vieux 5800 marche encore très bien et s'il n'est pas très sexy je n'ai pas encore trouvé de téléphone aussi robuste tant matériel que logiciel.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Gnome 3
Posté par Pseudo007 . Évalué à 1.
J'utilise Gnome 3, tout n'est pas parfait, je trouve même qu'il reste pas mal de boulot, mais clairement c'est la bonne direction.
Il y en a qui vont (encore) rentrer en résistance (comme pour systemd, les modules du noyau (oui oui, il y en a qui n'en voulait pas !), Pulseaudio, etc), mais in fine, Gnome 2 (ou Gnome 3 + extension Gnome 2) ne sera plus utilisé. Gnome 3 est la bonne direction.
J'utilise GNU/Linux depuis genre 20 ans, Gnome depuis 15 ans, Gnome 3 est clairement mieux. Je dis mieux, pas plus. Il y en a qui croit que plus de gadgets ou d'options c'est mieux. Comme la majorité des gens, je n'en fais pas parti.
[^] # Re: Gnome 3
Posté par Pseudo007 . Évalué à 1.
Quelle conclusion à la con…
RHEL n'a pas la même cible que Fedora !
Fedora c'est pour découvrir ce qui est "hot" dans le logiciel libre. Classique, c'est pas "hot". Les entreprises ne veulent pas payer leurs employés pour ça.
Puis les utilisateurs de Fedora savent faire "yum install gnome-classic-session".
Je l'ai pas fait, j'ai pas essayé. Je tourne la page de Gnome 2.
C'est impressionnant les résistances qu'il y a à presque tout……………
[^] # Re: Gnome 3
Posté par ariasuni . Évalué à 5.
«Reproduire» me parait un bien grand mot. C’est le même thème que GNOME Shell (thème que je trouve moche, lorsqu’on ouvre un menu il se mélange au fond blanc de l’application, et je ne peux même pas le changer), on ne peut ni ni créer/supprimer, ni déplacer, ni personnaliser les panneaux. Bref, c’est l’apparence de GNOME et encore, ça fonctionne un peu pareil et ça s’arrête là. On dirait limite une démo de GNOME 2 sur laquelle seules les principales fonctionnalités ont été implémentées.
On devrait plutôt appeler ça «l’expérience GNOME 2 castré».
Écrit en Bépo selon l’orthographe de 1990
# OpenSSH et ChrootDirectory
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
Je suis un peu surpris pour cette histoire de ChrootDirectory.
Je l'utilise sur une Centos 6 et il semble que la fonction existe depuis OpenSSH 4.9 sortir en 2008 !
Sinon, je trouve que ça fait beaucoup de module supprimé. Ya plein de vieux périphériques qui vont être jeté pour rien j'ai l'impression :(
[^] # Re: OpenSSH et ChrootDirectory
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 4.
Concernant OpenSSH, c'est effectivement un loupé. Extrait du chapitre 14 des release notes :
Ce qui change donc, c'est le fait de pouvoir utiliser des utilisateurs confinés via SELinux grâce à la variable selinuxuser_usessh_chroot_.
Concernant les modules, oui ça fait beaucoup, mais lors de la beta, j'avais cru voir des disparitions de pilotes réseau Realtek que je n'ai pas revu dans les notes de la 7.0. Au pire, je suppose qu'il est possible de packager ce qui manque.
[^] # Re: OpenSSH et ChrootDirectory
Posté par Misc (site web personnel) . Évalué à 6.
Non, tu va continuer à utiliser RHEL 6 dessus et voila.
# Xen
Posté par MTux . Évalué à 4.
Quid du Dom0 ?
[^] # Re: Xen
Posté par Misc (site web personnel) . Évalué à 2.
Non supporté, sauf erreur de ma part.
Mais le projet Centos a un sous groupe visant à intégrer xen dans Centos, donc à terme, ça serait une solution.
[^] # Re: Xen
Posté par MTux . Évalué à 2.
Merci, c'est vrai je me rappelle de Xen4CentOS maintenant.
Mais pourquoi ma question a-t-elle était moinsonnée ??
# Ce que l'on n'a pas eu le temps de mettre dans la dépêche
Posté par Siosm (site web personnel) . Évalué à 3.
Il manque quelques points que je n'ai pas eu le temps de traduire pour la dépêche. Ils sont détaillés (avec ceux que l'on a traduit) dans ce document qui référence une grande partie des nouveautés.
[^] # Re: Ce que l'on n'a pas eu le temps de mettre dans la dépêche
Posté par Siosm (site web personnel) . Évalué à 3.
Ceux qui veulent aussi des logiciels plus à jour peuvent se tourner vers les Software Collections, qui sont supportées sur RHEL 7 :
# xfs ?
Posté par zurvan . Évalué à 7.
Est-ce qu'il y a une raison pour utiliser XFS ? J'avais l'impression que c'était un vieux fs (datant du défunt irix) et pensait que ça n'était plus développé…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: xfs ?
Posté par Siosm (site web personnel) . Évalué à 0.
Pour Dave Chinner, le mainteneur actuel de XFS, c'est le système de fichier le plus abouti à l'heure actuelle :
Si je ne me trompe pas, il supporte mieux les systèmes de fichiers de très grande taille que Ext4.
[^] # Re: xfs ?
Posté par Zenitram (site web personnel) . Évalué à 4.
Moi aussi, tout ce que je fais, c'est le meilleur et les autres sont plus nuls. Quelle référence.
Après, oser dire qu'un FS qui n'a pas de compression native, pas de déduplication native, pas de gestion de RAID native (c'est quand même du bonheur de voir son RAID se reconstruire en 10 minutes plutôt que des heures lorsqu'on casse son RAID avec 1% d'espace occupé sur le disque car on vient de l'installer), bon on peut accepter l'absence de chiffrement si on accepte le chiffrement par la couche du dessous, faut quand même le faire… Oui, la demande de fonctionnalités pour un FS a changé, on n'a plus au 20ème siècle…
Oui, mais Ext4 c'est un peu l'évolution facile du passé en attedannt le vrai changement…
OK, les FS en licences compatibles GPL sont en retard, mais quand même, on peut regarder le libre pas GPL ou le non libre pour se dire qu'on n'est plus forcément le FS le plus abouti… Le sauveur sera peut-être Btrfs (mais non jugé assez stable pour le moment et pas encore de RAID je crois :( ).
On n'est pas obligé de sortir que x pense que son truc est le meilleur sans poser un doute sur ce qu'il dit.
[^] # Re: xfs ?
Posté par Siosm (site web personnel) . Évalué à 1.
J'ai clairement mentionné que c'était l'opinion du mainteneur de XFS et donc que c'était probablement biaisé. J'aurais dû dire « stable » plutôt que « abouti ».
Comme toujours, c'est uniquement le système de fichiers choisi par défaut, il est tout à fait possible d'utiliser Ext4 ou Btrfs à l'installation.
[^] # Re: xfs ?
Posté par woopla . Évalué à 3.
Si si btrfs gère très bien le RAID. J'ai 5 disques en RAID6 qui sont en btrfs, 0 soucis pour l'instant, que du bonheur. Il le gère nativement, à la ZFS.
[^] # Re: xfs ?
Posté par Prosper . Évalué à 2.
Sauf qu'il manque plein de fonctions[1], c'est quand même une feature expérimentale au sein d'un fs qui n'est pas encore considéré comme stable:/
Par contre les performances semblent alléchantes[2]
[1] http://marc.merlins.org/perso/btrfs/post_2014-03-23_Btrfs-Raid5-Status.html
[2] http://lwn.net/Articles/536038/
[^] # Re: xfs ?
Posté par xcomcmdr . Évalué à 8. Dernière modification le 12 juin 2014 à 08:26.
Ah ouais…
Pas de compression (NTFS l'a depuis 1993. ZFS le fait aussi)
Pas de chiffrement (NTFS l'a depuis 2000. ZFS le fait aussi)
Pas de dé-duplication des données (NTFS l'a depuis 2012. ZFS le fait aussi)
On ne peut pas réduire une partition XFS.
Semble être moins performant que ext4
…
C'est sûr, c'est le système de fichiers le plus abouti à l'heure actuelle.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: xfs ?
Posté par Loïc Blot (site web personnel) . Évalué à 1.
XFS étant plus adapté aux fichiers volumineux et la volonté de Redhat étant de faire du cloud, je présume que XFS se devait de remplacer EXT. La limite de capacité des volumes en fait également partie.
Veepee & UNIX-Experience
[^] # Re: xfs ?
Posté par Misc (site web personnel) . Évalué à 3.
Surtout si tu vises les volumes de données que tu va avoir dans 10 ans avec le code d'aujourd'hui, au vue de la durée de vie de la distribution.
[^] # Re: xfs ?
Posté par KiKouN . Évalué à 4.
Si on ne peut pas réduire la taille du système de fichier, je pense qu'il n'est absolument pas adapter au cloud. Il est exclue que j'utilise un système de fichier que l'on ne peut pas réduire.
C'est déjà galère de réduire un FS qu'en le démontant.
[^] # Re: xfs ?
Posté par Misc (site web personnel) . Évalué à 2.
J'aurais pensé que l'usage du cloud ( enfin tu veux dire IaaS ), c'est de crasher ta VM car elle est éphémère ?
# Pilotes retirés
Posté par FreeB5D . Évalué à 1.
Ce n'est pas le retrait de x86_32 qui permet à RH d'enlever ces pilotes, mais eux-mêmes: je possède une carte mère avec un proc amd64 et un chipset réseau piloté par forcedeth, comme quoi cette seule explication ne tient pas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.