- openSUSE Users (Français)

Messages d'erreur suite à mise à jour
by Adel Scott 16 Jan '21

16 Jan '21

Bonjour, Meilleurs vœux à tous. J'ai une machine qui ne supporte pas les mises à jour de Kernel 😕 c'est la quatrième fois qu'elle me fait ce coup là depuis l'installation de ma Leap 15.2. Ça m'oblige à chaque fois à tout réinstaller et je voudrais bien trouver une solution pour résoudre ce problème différemment sans devoir y passer des heures. Voilà les messages que j'ai lors du boot : [ TIME ] Timed out waiting for device dev-disk-by\x2duuid-6263\x2d64D1.device [ DEPEND ] dependency failed for /run/media/jeffr/58d3f788-4263-4d82-8677-2319d99e8a9d. [ DEPEND ] Dependency failed for LOcal File Systems. [ DEPEND ] Dependency failed for Early Kernel Boor Messages. J'arrive à la fin à me connecter en root mais en "Emergency mode" Dans ce même mode j'accède poutant bien à ma partition dans le /home/jeffr Si j'essaye de mettre à jour mon système j'ai le message : La partition UUID=6263-64D1 ne peut être montée mount:/mnt/run/media/jeffr ... can't find UUID=6263-64D1 Si quelqu'un avait une solution à me proposer, de préférence en français, pour que je résolve ce problème avec la 15.2 sans devoir tout refaire à nouveau. Je vous remercie, excellent week-end à vous. Jeff

4 4

[opensuse-fr] petit problème de routage
by Adel.Scott 12 Nov '20

12 Nov '20

Bonjour à tou.te.s, J'ai eut un gros plantage sur ma partition système lors d'une mise à jours il y a 48 heures et je n'ai pas eut d'autres choix que de réinstaller ma Leap 15.2 le système refusait de booter il ne pouvait pas réparer la partition système BtrFS 🙁 Mes partitions /home sont sur un autre disque je n'ai pas perdu de fichier importants. J'ai cependant un problème de réseau. J'ai un petit serveur qui partage sa connexion internet avec plusieurs autres machines. J'utilise network manager pour mes connexions réseau Eth0 pour le réseau interne et Eth1 sortir vers Internet. Lorsque je ping vers mon réseau local en 192.168.58.xxx il passe par 192.168.0.50 et ne trouve pas sa cible bien sur. Si je désactive Eth1 le réseau local rentre dans l'ordre. Lorsque les 2 cartes sont connectées je sors sur internet. abyss:/home/jeffr # ping orichalque PING orichalque.jeff-realisations.home (192.168.58.6) 56(84) bytes of data. From 192.168.0.50 (192.168.0.50) icmp_seq=1 Destination Host Unreachable From 192.168.0.50 (192.168.0.50) icmp_seq=2 Destination Host Unreachable From 192.168.0.50 (192.168.0.50) icmp_seq=3 Destination Host Unreachable From 192.168.0.50 (192.168.0.50) icmp_seq=4 Destination Host Unreachable ^C --- orichalque.jeff-realisations.home ping statistics --- 7 packets transmitted, 0 received, +4 errors, 100% packet loss, time 6044ms pipe 4 abyss:/home/jeffr # ping free.fr PING free.fr (212.27.48.10) 56(84) bytes of data. 64 bytes from www.free.fr (212.27.48.10): icmp_seq=1 ttl=54 time=7.75 ms 64 bytes from www.free.fr (212.27.48.10): icmp_seq=2 ttl=54 time=7.65 ms 64 bytes from www.free.fr (212.27.48.10): icmp_seq=4 ttl=54 time=7.67 ms Il me reste encore quelques cheveux et j'aimerai bien ne pas les perdre 😁 Sébastien "Sogal" m'avait aidé lors d'une précédente configuration j'ai donc suivi les indications qu'il m'avaient données ci-dessous mais sans résultat cette fois. > Le pare-feu utilisé par openSUSE n'est plus SuSEFirewall2, c'est > firewalld qui est utilisé à présent. > > Tu dois tout d'abord activer le forwarding d'IP: > > vim /etc/sysctl.d/ip_forward.conf > > et tu y ajoutes: > > net.ipv4.ip_forward = 1 > > puis > > sysctl -f /etc/sysctl.d/ip_forward.conf > > Tu peux obtenir le même résultat via: > > yast routing ip-forwarding on > > Ensuite, en admettant que ton interface locale (eth0) soit dans la zone > 'internal' et ton interface internet (eth1) dans la zone 'external' du > pare-feu, tu lances: > > firewall-cmd --zone=external --add-masquerade --permanent > > puis > > firewall-cmd --reload > > Tu peux lister la configuration actuelle de firewalld et les > correspondances interface <=> zone via: > > firewall-cmd --list-all-zones > > Pour affecter tes interfaces à des zones: > > firewall-cmd --permanent --zone=internal --change-interface=eth0 > > firewall-cmd --permanent --zone=external --change-interface=eth1 > > firewall-cmd --reload Je vous remercie pour l'aide que vous voudrez bien m'apporter. Bien cordialement, Jeff

1 2

[opensuse-fr] openSUSE Conference 2020 - du 15 au 17 octobre 2020
by Guillaume GARDET 16 Oct '20

16 Oct '20

Bonjour à tous, l'openSUSE + LibreOffice Conference se tient (en anglais) en ligne du 15 au 17 octobre 2020. Planning: https://events.opensuse.org/conferences/oSLO/schedule IRC (pour avoir des infos fraiches): #libocon Room1: https://jitsi.documentfoundation.org/conf_room1 Room1: https://jitsi.documentfoundation.org/conf_room2 Workshop: https://jitsi.documentfoundation.org/conf_workshop Meeting room to chat: https://jitsi.documentfoundation.org/conf_chat Guillaume -- To unsubscribe, e-mail: opensuse-fr+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-fr+owner(a)opensuse.org

1 0

[opensuse-fr] Demande d'aide partage de connexion internet Leap 15.2
by Adel.Scott 25 Aug '20

25 Aug '20

Bonjour, J'ai besoin d'un peu d'aide pour le partage de ma connexion internet avec une OpenSuse 15.2. Suite au crash de ma partition racine Btrfs que je n'ai pas pu ou su réparer, j'ai profité de cette panne pour passer d'une Leap 15.1 à une 15.2, mais j'ai perdu toute ma config contrairement à une mise à jour :( J'ai 2 cartes réseau une pour le réseau local (eth0), l'autre pour le net (eth1). Le réseau fonctionne le ping vers différentes machines en local répond, le serveur est bien connecté à internet, mais je n'arrive pas à partager cette connexion internet avec les autres machines. Il y a quelques années avec une opensuse 42.x je crois, on résolvait ça avec YaST dans le menu firewall. Mais là je ne trouve rien et mes recherches sur internet (en français) ne me donnent pas de solutions. Connaissez-vous l'astuce pour partager Internet sur les PC de mon réseau local ? Je vous remercie. Cordialement, Jeff -- To unsubscribe, e-mail: opensuse-fr+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-fr+owner(a)opensuse.org

4 9

[opensuse-fr] [NEWS] Changement d'adresses IP de build.opensuse.org
by sogal 03 Feb '20

03 Feb '20

Pour relayer en français, l'annonce parue ce jour [0]: Au cours de la [fenêtre de maintenance](https://en.opensuse.org/openSUSE:Downtime) de ce jeudi (2020-02-06), nous déplacerons les adresses IPv4 et IPv6 de [build.opensuse.org](https://build.opensuse.org). Les nouvelles adresses sont: 195.135.221.162 2001:67c:2178:8::162 Les personnes utilisant cette instance de l'[Open Build Service](https://build.opensuse.org/) ne devraient normalement pas le remarquer, mais si vous êtes assez fou pour avoir ajouté les anciennes adresses IP à certaines règles de pare-feu ou autres fichiers de configuration, assurez-vous de mettre à jour votre configuration en conséquence. Veuillez noter que cela affecte également les entrées CNAME (alias) suivantes: - https://api.opensuse.org - https://obs-analyze.opensuse.org - https://obs-grafana.opensuse.org - https://obs-measure.opensuse.org - https://rabbit.opensuse.org - https://registry.opensuse.org [0] https://news.opensuse.org/2020/02/03/new-ip-addresses-for-build-opensuse-or… -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher -- To unsubscribe, e-mail: opensuse-fr+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-fr+owner(a)opensuse.org

1 0

[opensuse-fr] Tumbleweed: nouvelles de la semaine 03/2020
by sogal 16 Jan '20

16 Jan '20

Veuillez trouver ci-après les nouvelles d'openSUSE tumbleweed pour cette semaine: Plusieurs paquets ont été mis à jour cette semaine dans openSUSE Tumbleweed comme prévu après la saison des vacances. Cinq instantanés de cette version évolutive ont été livrés cette dernière semaine après avoir passé les tests rigoureux appliqués par openQA. Ces versions sont incroyablement stables avec des notes enregistrées au-dessus 95, selon le Tumbleweed snapshot reviewer. L'instantané le plus récent, 20200112, a mis à jour Xfce avec une mise à jour pour xfce4-session 4.14.1 et xfce4-settings 4.14.2. Divers changements visibles pour les développeurs ont été apportés dans l'instantané 20200101 dont re2 de Google une bibliothèque pour expressions régulières . frogr, l'application GNOME pour la gestion des images avec un compte Flickr, a été mis à jour en 1.6 et a supprimé l'usage obsolète de GTimeVal. La plate-forme open source pour le scale-out du stockage cloud public et privé, glusterfs 7.1, a corrigé le rééquilibrage du stockage provoqué par une erreur d'entrée et une fuite de mémoire dans glusterfsd. La version 7.0.9.14 de ImageMagick a optimisé les performances des effets spéciaux de Fx et de virglrenderer 0.8.1, qui est un projet visant à étudier la possibilité de créer un GPU 3D virtuel pour une utilisation à l'intérieur des machines virtuelles qemu afin accélérer le rendu 3D. L'instantané a continué de mettre à jour les paquets pour KDE Applications 19.12.1 qui avaient été intégré dans l'instantané 20200111 . Des améliorations ont été apportées à la vitesse de la molette de défilement pour Dolphin de KDE et le logiciel de montage vidéo Kdenlive avait plusieurs correctifs et un ajustement pour un rendu plus rapide, du code obsolète a aussi été supprimé du paquet de diagramme des applications parapluie. La plupart des paquets Applications KDE ont également mis à jour l'année du copyright à 2020. En plus des paquets KDE Applications 19.12.1 qui ont commencés à arriver dans l'instantané 20200111, Plasma 5.17.5 de KDE est également arrivé dans l'instantané. Cette mise à jour de Plasma a corrigé une régression intervenue dans la transition l'applet de pageur hors de QtWidgets et a corrigé le glisser-déposer de fichiers depuis Dolphin vers un widget de bureau virtuel. Le Plasma NetworkManager avait également un correctif pour un crash lors du changement de configuration IPv4. Le correctif très attendu de la vulnérabilité de sécurité dans Firefox a été effectué avec la mise à jour de Mozilla vers Firefox 72.0.1; il y avait huit Common Vulnerabilities and Exposures (CVE) traitées dans la mise à jour de la version précédente 71 incluse dans Tumbleweed, mais la version 72.0.1 a corrigé le bogue que des pirates pouvaient utiliser pour accéder à un ordinateur de toute personne utilisant le navigateur en raison d'informations d'alias incorrectes dans le compilateur JIT IonMonkey. LibreOffice 6.4.0.1 a ajouté un correctif pour corriger un bouton qui permettait le mauvais ordre d'une interface Qt et curl 7.68.0 comportait un grand nombre de correctifs et de modifications pour inclure l'ajout d'une implémentation de BearSSL vtls pour la Transport Layer Security (TLS). La version 0.8.8 de snapper a bénéficié d'une réécriture d'un sous-paquet de Python vers C ++ et plusieurs paquets YaST ont été mis à jour, ce qui comprenait la correction d'une erreur lors d'une mise à niveau si /var/lib/YaST2 manquait lors de l'utilisation de Btrfs. L'outil de dépannage sysdig a été mis à jour dans l'instantané 20200110 ; il a corrigé une fuite de mémoire et mis à jour l'utilisation des API Kubernetespour prendre en charge la version 1.16. De nombreux paquets GNOME ont été mis à jour vers la version 3.34.3 et le paquet fwupd 1.3.6, pour la mise à jour de firmware, a ajouté un nouveau plugin pour travailler avec les cartes MultiMediaCard intégrées (eMMC). Une mise à jour de rpm-build a permis l'abandon d'une dépendance à python3-setuptools grâce à la mise à jour de rpm en version 4.15.1 et le compilateur d'exécution optimisé pour la boucle intérieure (orc) 0.4.31 corrigé divers problèmes sur PowerPC. Les instantanés 20200109 et 20200108 contenaient une quantité minimale de mises à jour de paquets, mais le Noyau Linux a été mis à jour vers la version 5.4.7 dans l'instantané 20200108, et fournissait une grande quantité de mises à jour par rapport au noyau 5.3.12 précédent. Les mises à jour pour Btrfs dans le noyau étaient nombreuses et il y avait une poignée de correctifs dans le noyau pour IBM s390 et pour le système de fichiers ext4. Source: https://blog.alionet.org/fr/2020-01-15-libreoffice-firefox-curl-mise-a-jour… -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher -- To unsubscribe, e-mail: opensuse-fr+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-fr+owner(a)opensuse.org

2 1

[opensuse-fr] Traduction: information sur le vote pour le changement de nom du projet
by Sébastien 'sogal' Poher 22 Oct '19

22 Oct '19

Bonjour à tous, Comme vous le savez sûrement un vote pour évaluer la pertinence d'un changement de nom du projet openSUSE est en cours. À la demande d'une partie de la communauté, le Conseil et le comité des élections ont rédigé un résumé [0] du contexte et implications du vote. Il a été traduit en français [1], en voici le contenu: ---------------------- # Vote sur le changement de nom du projet openSUSE ## Contexte Une discussion sur le changement de nom de notre projet a eu lieu sur la liste de diffusion du projet suite à une autre discussion concernant la transformation du projet en fondation. Cette dernière proposition a été annoncée par le Conseil du projet lors de la conférence annuelle. Par la suite, il a été proposé que, si le nom du projet devait être modifié, la transformation du projet en fondation était une bonne occasion de le faire. Les avantages et les conséquences du changement de nom du projet ont été discutés sur la liste de diffusion du projet pendant plusieurs semaines. Stasiek Michalski (LCP) a posé la question et Richard Brown a fourni des perspectives juridiques après avoir discuté avec des collègues de l'équipe juridique SUSE. Après avoir consulté un avocat spécialisé, le Conseil a souligné que les deux entités juridiques indépendantes (openSUSE et SUSE) pourraient conserver leurs marques respectives de façon concurrente, de sorte que l'existence des deux marques déposées ne constitue pas un obstacle. Les discussions sur le changement ou la conservation du nom du projet peuvent être résumées comme suit: ### Pourquoi devrions-nous conserver le nom du projet actuel? * Nous perdrions la réputation de la marque openSUSE, durement acquise au fil des ans. * De nombreux membres et autres contributeurs sont fortement attachés au nom actuel. * Changer le nom peut donner l’impression que la relation entre SUSE et openSUSE est tendue. * Il faudra beaucoup de travail pour renommer les domaines, les projets OBS et leurs métadonnées, l’espace de noms GitHub, les marques de paquets, etc. * Le changement de marque nécessite une campagne de communication active (et donc de l'argent) au fil des ans pour ancrer le nouveau nom du projet dans les esprits. * SUSE peut transférer ou céder sous licence la marque déposée à la (future) fondation openSUSE. * La relation avec SUSE fait partie de notre stratégie marketing, par exemple lorsque nous mettons en avant la base de code partagée entre Leap et SLE. * Changer le nom du projet rendra obsolètes les goodies openSUSE actuels (T-shirts, mugs, autocollants, etc.). ### Pourquoi devrions-nous changer le nom du projet? * openSUSE est souvent mal écrit et/ou mal prononcé (par exemple, OpenSUSE, OpenSuSE, etc.). Regardez comment dites-vous SUSE? * La Free Software Foundation (FSF) ne recommande pas l'usage du terme "ouvert", très flou. * La distinction entre openSUSE et SUSE peut être source de confusion pour les personnes novices dans l'une ou l'autre de ces marques. De nombreuses personnes raccourcissent ainsi openSUSE en SUSE. * Si la communauté pense que le projet tirera bénéficie d’un nouveau nom, c'est maintenant qu'il convient de le modifier, c'est-à-dire avant l'enregistrement d'une nouvelle structure juridique (telle qu'une fondation). *Les arguments ci-dessus ne reflètent en aucun cas les positions du conseil ou du comité des élections.* ## Vote La communauté reste divisée sur le sujet et en de telles circonstances, il n’est pas simple d’envisager un consensus en se basant uniquement sur les discussions des listes de diffusion. Le Conseil a donc demandé au comité des élections de mettre en place un vote afin d'obtenir la décision de la communauté d'une manière plus claire et mesurable. Le comité des élections a annoncé que le vote aurait lieu du 10 octobre au 7 novembre 2019. Le comité des élections peut être contacté à l’adresse [mailto: election-officials(a)opensuse.org election-officials(a)opensuse.org] pour toute question relative à ce vote. Processus de vote Le vote électronique a lieu sur elections.opensuse.org, la même plate-forme utilisée lors des élections au Conseil. Les membres ont reçu leur lien de vote électronique et leurs identifiants d'accès à leur alias de courrier électronique @opensuse.org. Ils peuvent ensuite se connecter et voter. Ils peuvent également modifier leur vote à tout moment avant 23h59 UTC le 7 novembre 2019, seul le dernier vote étant enregistré. ## Question mise au vote Changeons-nous le nom du projet? [] Oui [] Non La question reste simple afin d’éviter toute ambiguïté ou risque de parti pris de la part du Conseil ou du comité des élections. Les questions plus détaillées auraient été (pour des raisons techniques, cela n'a pas été possible car le vote était déjà en cours): [] Je suis favorable à la modification du nom de notre projet "openSUSE" et au remplacement des utilisations du nom "openSUSE" par un nouveau nom. Je souhaite que le Conseil du projet openSUSE et SUSE travaillent ensemble pour atteindre cet objectif. (Les prochaines étapes comprendront la détermination de propositions concrètes et un vote sur le choix effectif.) (Ceci correspond au vote Oui.) [] Je suis favorable au maintien du nom "openSUSE" pour notre projet et aimerait voir le Conseil et SUSE travailler ensemble pour faire tout ce qui est nécessaire (en termes de marques et d’autres accords) pour permettre cela. (Ceci correspond au vote Non.) Résultat Le résultat du vote sera annoncé le 8 novembre 2019. Les membres recevront le résultat par courrier électronique. Le résultat sera également publié sur news.opensuse.org et annoncé sur la liste de diffusion du projet. [0] https://en.opensuse.org/openSUSE:Project_name_change_vote [1] https://fr.opensuse.org/openSUSE:Vote_pour_le_changement_de_nom_du_projet -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher

2 1

[opensuse-fr] KDE et openSUSE: Plasma 5.17, Qt 5.14 plus encore
by Sébastien 'sogal' Poher 13 Oct '19

13 Oct '19

Voici les dernières nouvelles du développement d'openSUSE Tumbleweed ------------------------ Plasma 5.17 Beta La version bêta de Plasma 5.17 a été publiée avec de nombreuses nouvelles fonctionnalités et améliorations telles que la mise à l’échelle fractionnelle par écran sur Wayland, une nouvelle interface utilisateur pour la configuration des autorisations des périphériques Thunderbolt et des statistiques réseau dans KSysGuard. Ce dernier nécessite plus de privilèges que d’habitude pour une application utilisateur. C’est pourquoi l’équipe de sécurité SUSE est en train de vérifier ces autorisations. openQA a déjà trouvé quelques bogues, comme GIMP plus “en couleurs” que d’habitude et certaines applications telles que Kirigami et Qt Widgets qui casse certains raccourcis clavier. Les deux ont été corrigés dans l’intervalle et seront corrigés dans la version finale de 5.17. Si vous n’avez pas encore testé Plasma 5.17 Beta, il reste encore un peu de temps! Si vous rencontrez un problème dans le logiciel, veuillez vous rendre sur KDE bug tracker. Si au lieu de cela vous trouvez un problème spécifique à openSUSE, rendez vous sur l’openSUSE bugzilla. Pour obtenir Plasma 5.17 sur votre installation Leap ou Tumbleweed, vous pouvez lire https://fr.opensuse.org/SDB:KDE_repositories. Si vous rencontrez des problèmes graves, l’instantané automatique du système de fichiers racine pris à l’aide de [btrfs] (https://en.wikipedia.org/wiki/Btrfs) vous aide à revenir à l’état de fonctionnement en démarrant dans un instantané plus ancien et en faisant une restauration. Argon, un support live installable comprenant Leap 15.1 avec la version bêta et ne nécessitant aucun ajout de dépôt manuel, est également disponible. openSUSE Leap 15.2 Comme ce fut le cas pour Leap 42.2, 15.2 inclura également des mises à jour majeures de nombreux composants. A côté d’une nouvelle version du noyau Linux, il est prévu de la livrer avec Qt 5.12 LTS, Plasma 5.18 (bien sûr également LTS) et les dernières versions de KDE Frameworks et Applications, que nous pourrons faire entrer suffisamment tôt pour que les tests appropriés garantissent la meilleure expérience utilisateur possible! Cela signifie que la session “Full Wayland” qui a atterri dans Tumbleweed il y a quelques semaines sera également disponible dans Leap 15.2 de même que la prise en charge de la mise à l’échelle fractionnelle par écran. Comme les versions cibles d’Applications, Frameworks et Plasma ne sont pas encore connues, nous intégrons actuellement Qt 5.12 LTS aux derniers packages de Factory. Qt 5.14 Les utilisateurs de Tumbleweed et de Leap sont habitués à bénéficier des versions les plus récentes des logiciels KDE incluant les fonctionnalités et corrections de bogues disponibles, ce qui n’est possible qu’en suivant le développement de Qt et en agissant de manière proactive. Ainsi, bien que la branche 5.1 de Qt soit encore jeune, nous sommes déjà en train de l’intégrer dans nos versions. Lors de la construction initiale de la version 5.14 Alpha, certains bogues (QTBUG-78867, QTBUG-78881, QTBUG-78911, QTBUG-78948) avaient déjà été identifiés et corrigés pour la plupart, de sorte que le projet KDE:Qt:5.14 est construit et utilisable dès maintenant. Pour développer avec Qt 5.14 et tester vos applications, vous n’avez plus qu’à ajouter le dépôt. Jusqu’ici, nous en sommes toujours à la phase d’intégration et nous préparons tout ce qui doit l’être, mais nous soumettrons bientôt Qt 5.14 en zone de transit de Factory afin de voir comment il s’y intègre. L’une des caractéristiques les plus visibles pour l’utilisateur est que la mise en œuvre de la mise à l’échelle (pour les écrans HiDPI) a été principalement réécrite. Parmi les autres changements notables, citons l’ajout de divers systèmes d’accélération de Qt Quick utilisant une nouvelle couche d’abstraction (opt-in), qui peut désormais tirer parti de Vulkan ainsi que l’introduction d’un nouveau module “qtquicktimeline”, qui permet de faciliter intégration d’animations basées sur la chronologie dans Qt Quick. source: https://news.opensuse.org/2019/10/10/kde-and-opensuse-plasma-5-17-qt-5-14-a… -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher

1 0

[opensuse-fr] Lumière sur le développement de YaST - Sprint86
by Sébastien 'sogal' Poher 11 Oct '19

11 Oct '19

*Voici une traduction des annonces de l'équipe de développement de YaST* Maintenant que vous avez eu l'occasion de consulter [notre message sur les options de chiffrement avancées](https://lizards.opensuse.org/2019/10/09/advanced-encryption-yast/) (en particulier si vous êtes un utilisateur de s390), il est temps de vérifier ce qui s’est passé lors du dernier sprint de développement YaST, qui s’est achevé lundi dernier. Comme d'habitude, nous avons travaillé sur un large éventail de sujets, notamment: - Amélioration de la prise en charge des systèmes de fichiers multi-périphériques dans le partitionneur expert. - Résolution des problèmes de réseau, de démarrage sécurisé et de kdump dans AutoYaST. - Plus d'attente de `chrony` lors du démarrage initial lorsque cela n'a pas de sens. - Préparation de la prise en charge de la scission des fichiers de configuration entre `/usr/etc` et` /etc`. - Utilisation de `/etc/sysctl.d` pour écrire les paramètres liés à YaST au lieu du fichier principal `/etc/sysctl.conf`. ### Expert Partitioner et systèmes de fichiers multi-périphériques Jusqu'à présent, le partitionnement en mode expert partait du principe que Btrfs était le seul système de fichiers construit sur plusieurs périphériques. Mais ce n'est pas tout à fait vrai, car certains systèmes de fichiers peuvent utiliser un journal externe pour améliorer les performances. Par exemple, *Ext3/4* et *XFS* peuvent être configurés pour utiliser des périphériques distincts pour les données et la journalisation. Nous avons reçu un [rapport de bogue](https://bugzilla.suse.com/show_bug.cgi?id=1145841) causé par ce malentendu sur les systèmes de fichiers multi-périphériques. Le partitionneur expert désignait comme "faisant partie de Btrfs" un périphérique utilisé comme journal externe d'un système de fichiers *Ext4*. Nous avons donc amélioré cette fonctionnalité lors du dernier sprint et les périphériques de journal externes sont maintenant correctement indiqués dans la colonne *Type* du Partitionneur expert, comme illustré dans la capture d'écran ci-dessous. ![Type de journal externe](http://lizards.opensuse.org/wp-content/uploads/2019/10/yast2-stora… De plus, les informations sur le système de fichiers indiquent maintenant quel périphérique est utilisé pour le journal externe. ![Détails du périphérique de journal externe](http://lizards.opensuse.org/wp-content/uploads/2019/10/yast2-stora… Enfin, nous avons également limité l’utilisation des périphériques appartenant à un système Btrfs multi-périphériques. À présent, vous recevrez un message d'erreur si vous essayez de modifier l'un de ces périphériques. À l'avenir, nous étendrons cette fonctionnalité pour permettre de modifier les systèmes de fichiers utilisant un journal externe via le Partitionneur expert. ### AutoYaST a fait l'objet de notre attention Au cours de ce sprint, nous avons accordé à AutoYaST une attention particulière dans différents domaines: réseaux, chargeur de démarrage et kdump. À propos de la zone réseau, nous avons terminé la prise en charge de s390 dans la nouvelle couche réseau, en corrigeant certaines anciennes limitations en matière d’activation de périphériques et de gestion d’UDev. En dehors de cela, nous avons corrigé plusieurs bugs et amélioré beaucoup la documentation, car nous la trouvions plutôt incomplète. Un autre changement important a été l'ajout de la possibilité de désactiver le démarrage sécurisé pour UEFI via AutoYaST. Bien sûr, nous avons également mis à jour la documentation et, au cours du processus, nous avons ajouté des éléments manquants et supprimé d'autres éléments inutiles. Enfin, nous avons corrigé un problème délicat lorsque nous essayons de faire fonctionner kdump sur un système minimal. Après débogage, nous avons découvert qu’AutoYaST ajoutait trop tard `kdump` à la liste des paquets à installer. Ce problème a été résolu et il devrait maintenant fonctionner comme un charme. Comme vous l'avez peut-être vu, à part l'écriture de code, nous essayons de contribuer à la documentation afin que nos utilisateurs disposent d'une bonne source d'informations. Si vous êtes curieux, en plus des documents pour les versions [SUSE](https://suse.com/documentation) et [openSUSE](https://doc.opensuse.org/) publiées, vous pouvez consulter les [dernières versions](https://susedoc.github.io/) (y compris le [manuel AutoYaST](https://susedoc.github.io/doc-sle/master/SLES-autoyast/html)). Félicitations à notre équipe de documentation pour cet extraordinaire travail ! ### Éviter le temps mort `chrony-wait` Récemment, certains utilisateurs d’openSUSE ont signalé un problème très gênant dans Tumbleweed. Lorsque la synchronisation de l'heure est activée via YaST, le système peut rester bloqué pendant le processus de démarrage si aucune connexion réseau n'est disponible. Le problème est que, mis à part le service `chrony`, YaST activait également le service` chrony-wait`. Ce service est utilisé pour garantir que l'heure est correctement définie avant de continuer avec d'autres services pouvant être affectés par un décalage temporel. Mais sans connexion réseau, `chrony-wait` attendra environ 10 minutes. Inacceptable. La discussion sur le correctif de ce bogue est toujours ouverte, mais pour le moment, nous avons appliqué une solution de contournement dans YaST afin d'activer `chrony-wait` uniquement pour les produits nécessitant une heure précise, comme openSUSE Kubic. Dans le reste des cas, les systèmes démarreront plus rapidement, même sans réseau, bien que certains services puissent être affectés par un décalage temporel. ### Fractionnement des fichiers de configuration entre `/etc` et `/usr/etc` En tant qu'utilisateurs Linux, nous sommes tous habitués à vérifier les paramètres du système dans `/etc`, qui contient un mélange de valeurs de configuration propres au fournisseur et à l'hôte. Cette approche a plutôt bien fonctionné dans le passé, non sans quelques ratés, mais lorsque des choses comme [les mises à jour transactionnelles](https://en.opensuse.org/openSUSE:Packaging_for_transacti… entrent en jeu, la situation devient compliquée. Afin de résoudre ces problèmes, il est prévu de scinder les fichiers de configuration entre `/etc` et `/usr/etc`. Le premier contiendrait les paramètres du fournisseur, tandis que le second définirait des valeurs spécifiques à l'hôte. Bien sûr, une telle démarche a de nombreuses implications. Au cours de ce sprint, nous avons donc essayé d'identifier les problèmes potentiels pour YaST et de proposer des solutions pour les résoudre à l'avenir. Si vous êtes intéressé par les détails techniques, vous pouvez lire [nos conclusions](https://github.com/yast/yast-yast2/blob/2975c70ab17f1bc790c0ca…. ### Écrire les modifications de Sysctl dans `/etc/sysctl.d` Pour pouvoir gérer la séparation de `/etc` et `/usr/etc`, YaST doit arrêter d’écrire dans des fichiers tels que `/etc/sysctl.conf` et utiliser un fichier spécifique dans les répertoires `.d` (comme `/etc/sysctl.d`). Ainsi, dans le cadre de la recherche susmentionnée, nous avons adapté plusieurs modules (`yast2-network`,` yast2-tune`, `yast2-security` et` yast2-vpn`) afin qu'ils se comportent de cette manière concernant `/etc/sysctl.conf`. À partir de maintenant, les paramètres spécifiques à YaST seront écrits dans `/etc/sysctl.d/30-yast.conf` au lieu de `/etc/sysctl.conf`. De plus, si YaST trouve l'un de ces paramètres dans le fichier `.conf` général, il les déplacera au nouvel emplacement. ### Et après? Sprint 87 est déjà en cours. Outre la correction de certains bugs introduits lors de la refactorisation du réseau, nous prévoyons de travailler sur d'autres tâches liées au stockage, telles que le support du redimensionnement pour LUKS2 ou certains problèmes liés a snapper. Nous vous donnerons plus de détails dans notre prochain rapport de sprint. Restez à l'écoute! -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher -- To unsubscribe, e-mail: opensuse-fr+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-fr+owner(a)opensuse.org

1 0

[opensuse-fr] Annonce de fin de vie pour openSUSE Leap 15.0
by Sébastien 'sogal' Poher 11 Oct '19

11 Oct '19

Dans un message publié sur les listes de diffusion du projet openSUSE, Marcus Meissner, de l'équipe de maintenance SUSE et openSUSE, a annoncé la fin de support d'openSUSE Leap 15.0. En voici une traduction: Le 30 novembre 2019, openSUSE Leap 15.0 atteindra la fin de sa période de support après une durée de vie d'un an et demi (cette version est parue en mai 2018). En conséquence, openSUSE Leap 15.0 ne bénéficiera plus de mises à jour de maintenance ou de sécurité après cette date. Il est donc fortement recommandé aux utilisateurs de procéder à la mise à jour vers la version actuelle, à savoir openSUSE Leap 15.1. La prochaine publication de la distribution, openSUSE Leap 15.2, est prévue pour mai 2020. -- 'When there is no more room at school, the dumb will walk the Earth.' Sébastien 'sogal' Poher -- To unsubscribe, e-mail: opensuse-fr+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-fr+owner(a)opensuse.org

1 0