Bonjour à tous,

didierg wrote:Bonjour,

Je viens de découvrir (peut-être que je ne l'avais pas vu avant) qu'en bas de chaque page de résultats de recherche Google figure le nom de la ville où je réside.

Selon les explications fournies:

"Google détecte automatiquement la position de votre ordinateur à partir de son adresse IP, de l'historique des positions (s'il est activé) et des lieux que vous avez recherchés récemment."

J'aimerai savoir si il y a moyen de restreindre la curiosité de Google à ce niveau ?

Oui, il y a une adresse qui permet de ne pas géolocaliser selon l'adresse IP à X mètres de chez toi.

L'adresse est :

https://www.google.com/webhp?sclient=psy&hl=fr&safe=off&newwindow=1

Par contre, Google peut toujours garder ta géolocalisation précise à quelques mètres près dans ses serveurs.

Pour firefox, il y a l'option "geo.enabled=false" pour éviter une géolocalisation par rapport au navigateur, mais il ne faut pas oublier que google peut toujours géolocaliser par rapport à wifi (c'est indiqué dans leurs conditions d'utilisations pour les téléphones android), je ne sais pas ce que cela vaut pour les ordinateurs sans compte Google donc sur un PC, préférer l'utilisation d'un cable avec un connecteur RJ45, et désactiver le wifi.

Si cela peut-être utile.

Bonjour à tous,

merci à VINDICATORs et à madko.

Pour ma part, c'est résolu en grande partie.

VINDICATORs wrote:Pour info virt-manager c'est une interface graphique qui se base sur libvirt (incluant QEMU, KVM, ...)

Libvirt c'est ce qui gère la virtualisation derrière :
https://fr.wikipedia.org/wiki/Libvirt

Il ne faut pas confondre 😉 .

Merci du renseignement, je me suis mal exprimé, en effet, je pensais au fait quand j'utilisais virt-manager pour configurer le réseau, et dont le réseau hôte était "désactivé" et que l'IPV6 ne fonctionnait pas, d'où l'impossibilité d'installer une distribution sans désactiver l'ipv6 avant l'installation.
Par contre les machines qemu-kvm créées en ligne de commandes ne sont pas reconnues par libvirt.

madko wrote: Ok donc il s'agit d'un bridge natif (comparé à d'autres solutions de bridge comme OpenVswitch par ex)

Quels sont les droits sur /dev/net/tun ?

ll /dev/net/tun

La seule fois où j'ai eu cette erreur je passais par libvirt, qui est quand même bien plus simple (définition de la VM en XML pour éviter les 8 lignes de commandes qemu etc). Donc je sais pas si ça te concerne mais ça pourrait être une piste. Dans le fichier /etc/libvirt/qemu.conf il y a un bloc:

#cgroup_device_acl = [
#    "/dev/null", "/dev/full", "/dev/zero",
#    "/dev/random", "/dev/urandom",
#    "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
#    "/dev/rtc","/dev/hpet", "/dev/sev"
#]

Qui est commenté mais nous indique les valeurs par défaut. Je devais décommenter ça, et ajouter /dev/net/tun dans la liste. Puis relancer le service libvirt. Comment ça se concrêtise pour ton cas ?? Il faudrait trouver le moyen de voir les ACL des cgroup

Cela ne donnait rien, sachant que les machines créées à la main ne sont pas gérées par libvirt.

Et j'avais lu que le mode tap n'était pas possible à cause d'histoire de sécurité, donc j'ai essayé de tester macvtap, mais... ca semble être utilisé pour de grand domaines, et la documentation est ... n'y a t'il pas de centralisation de documentation à jour ? C'est un véritable problème concernant les distributions GNU\Linux.

Je suis reparti sur tap, sachant que j'ai constaté une anomalie.

En effet, en tapant:

sudo ip tuntap add dev tap0 mode tap user 1000

Je n'ai plus le message d'erreur suivant:

qemu-system-x86_64: could not open /dev/net/tun: Permission denied

et je peux lancer un invité via qemu-kvm avec tap situé dans /dev/tapX sans message d'erreur, et sans être root.

qemu-system-x86_64 [...] -M q35 [...] -cpu host -bios OVMF-pure-efi.fd  [...] -drive file=debian_stretch.qcow2,cache=none,if=virtio,media=disk,index=0 -boot order=cd,once=d,menu=on,strict=on [...] -enable-kvm -netdev tap,ifname=/dev/tap5,id=debiannetwork,script=no,downscript=no -device virtio-net-pci,netdev=debiannetwork

Par contre, pas de connexion dans l'invité.

De plus, lors d'une manipulation (création d'un bridge situé dans le même réseau que celui de l'hôte (même plage d'adresses IP avec le même masque), pour constater si cela fonctionnait (car même "domaine" réseau, j'avais constaté que l'invité fonctionnait et pouvait communiquer avec l'hôte, avec un inconvénient, le réseau hôte ne fonctionnait pas, et "ca casse" NetworkManager (il faut redémarrer), sachant que l'interface enp2s0 était activée dans l'hôte et donc causait le problème).

Donc création d' un script en créant un fichier ifconfig-br0, afin de créer un bridge br0 dans:

/etc/sysconfig/network-scripts/ifcfg-br0

en ajoutant ceci:

DEVICE=br0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge

Puis en modifiant le script concernant le réseau filaire en fonctionnement:

nano /etc/sysconfig/network-scripts/ifcfg-enp2s0

j'ai fait les modifications suivantes:

HWADDR=XX:XX:XX:XX:XX:XX
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
#je désactive la ligne ci-dessous car je ne veux pas que cette connexion se lance au démarrage, juste le bridge br0, sinon tout est cassé.
#BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp2s0
UUID=da0c1734-d1ea-49b6-850e-a8337b3ff6d3
ONBOOT=yes
MACADDR=00:00:00:00:00:01
#J'ajoute la ligne ci-dessous pour lier l'interface réseau actuelle au bridge ci-dessous br0
BRIDGE=br0

On ajoute dans le fichier /etc/sysctl.conf

net.ipv4.ip_forward = 1
net.ipv4.conf.default.arp_filter = 1

et on valide les changements par:

 sysctl -p /etc/sysctl.conf

Ci-dessous, je ne sais pas si cela est utile, parce que je ne sais pas si c'est lié à libvirtd et que cela joue sur les machines créées par qemu-kvm en ligne de commandes (il me semble que oui, mais la flemme de vérifier) je rajoute:

 allow br0

dans le fichier /etc/qemu/bridge.conf

On redémarre,

Et en ligne de commande:

qemu-system-x86_64 [...] -M q35 [...] -cpu host -bios OVMF-pure-efi.fd  [...] -drive file=debian_stretch.qcow2,cache=none,if=virtio,media=disk,index=0 -boot order=cd,once=d,menu=on,strict=on [...] -enable-kvm -netdev bridge,br=br0,id=debiannetwork -device virtio-net-pci,netdev=debiannetwork
 [...] && remote-viewer spice+unix:///tmp/spice.sock

ne pas oublier d'installer spice-vdagent pour profiter de la paravirtualisation, et quemu-guest-agent pour ...? les ports séries?

Lors du lancement de l'invité, une interface tap est créée et une adresse IP est assignée dans l'invité, j'ai bien accès à l'interface "enp2s0",et la machine invitée peut communiquer avec l'hôte (on peut pinger etc.)

Compatible avec virtualbox.

edit: On peut faire tourner plusieurs machines invitées derrière le même bridge.
Par contre, pour ne pas avoir des machines avec la même adresse IP, le même masque réseau et la même adresse MAC, il faut attribuer une adresse MAC différente pour différencier le réseau de chaque machine, il faut donc ajouter une adresse MAC personnalisée pour chaque machine via qemu:

-netdev bridge,br=br0,id=fedora29network -device virtio-net-pci,netdev=fedora29network,mac=00:32:02:50:13:5e

Je vous remercie de vos réponses.
Cordialement

Merci de vos réponses, à nouvo09 et didierg,

Comme j'ai réinstallé fedora, le problème ne se présente plus (la mise à jour n'a rien donné).

J'avais écumé les forums de VirtualBox, et d'autres pages, sans que la raison soit claire, et il fallait faire une remontée à VirtualBox, en suivant la procédure suivante.

Le "VirtualBox Extension Pack" était installé , et les invités aussi, et je faisais bien parti du groupe vboxusers.

J'avais constaté que les bus USB étaient occupés.

J'avais lu aussi que Wireshark posait problème, et je n'ai jamais compris pourquoi.

Ainsi, je me rappelle maintenant que j'avais "activé" le mode debug concernant les périphériques USB pour pouvoir monitorer le trafic USB d'un disque dur, en suivant la procédure suivante:

La modification des ACL via setfacl en doit-être la cause, en effet, même sous qemu-kvm, j'avais un problème similaire, je ne pouvais seulement brancher qu'un seul USB, je n'avais plus de channel de disponible.

En testant une machine Fedora 29 sous qemu-kvm, avec fedora réinstallée, le problème n'apparaît plus.
Je pense que le problème provient du changement d'ACL dans /dev/usbmon*.

Je vais tester aujourd'hui ou demain, je pense que ce problème provient de la modification des ACL.

Je vous remercie à vous deux de m'avoir rafraîchie la mémoire, je vais tester sur une machine via qemu-kvm.

Edit: En testant sous qemu-kvm, sous fedora 29, je n'ai pas rencontré ce problème, même avec la modification des ACL de /dev/usbmon*.
J'avais constaté aussi que seul un périphérique USB pouvait être branché sous qemu-kvm, ce que je n'ai pas constaté lors d'une réinstallation de Fedora 28.
En regardant ce problème arrive sans qu'on ne le sache pourquoi de temps à autre, sans savoir d'où provient le problème, même en suivant le guide de "résolution" du site de VirtualBox.

Bonjour,

Méthode d'installation :
Via gnome-software.

Problèmes majeurs :
Présent sous Fedora 28, et reproduit sous Fedora 29, VirtualBox ne reconnaît en aucun cas les périphériques USB, et difficile de trouver la raison.

problèmes mineurs :
Auncun.

Points positifs :
Heureux de tester la dernière version de qemu et de kvm.

Points négatifs :
Rien qui ne vient en tête. Je note que le manque d'émulateurs de jeux, ou le problème de fonctionnement des émulateurs de jeux est un vrai problème, par exemple snes9x. Cependant en utilisant une autre méthode pour installer les pilotes Nvidia, avec un ordinateur équipé de la technologie d'optimus, le problème ne se présente plus (sous fedora 28),
edit: ou encore la qualité du son de PCSX2 est un gros problème. il faut installer alsa-plugins-pulseaudio.i686


Mais dû au problème de la non-reconnaissance des périphériques USB via VirtualBox, j'ai réinstallé Fedora via une image ISO.


Méthode d'installation :
Via une image ISO. Les partitions /home et /data (partition qui contient des données n'ont pas été formatées (celle de mon disque dur classique ).

Problèmes majeurs :

• Écran qui se fige peu de temps après l'ouverture de la session, que ce soit dans une session Wayland ou une session Xorg. Seul le mode rescue permet de ralentir un écran bloqué.
• Openvpn ne fonctionne pas, il semble qu'il manque un service.
• Énormément d'alertes de ABTR. Néanmoins, elles ne sont pas répertoriées, donc impossible de le signaler.
• Rétroéclairage du clavier qui ne fonctionne pas.
• Ventilateur qui souffle comme un diable.
• Un logiciel comme Rufus serait bienvenue. Cela aiderait énormément à alléger certaines tâches (comme le fait de ne pas lancer Windows dans une machine virtuelle,)

problèmes mineurs :
RAS.

Points négatifs :

• Impossible d'utiliser fedora 29. Malheureusement, j'ai réinstallé fedora 28, en attendant que la version 29 soit beaucoup plus stable.
• Comme dans Fedora 28, l'indicateur "triangle" de la touche "Majuscule" qui ne s'affiche pas est un problème. Ayant un ordinateur n'ayant pas les LEDs pour vérifier si la touche MAJ est activée, cela est problématique pour taper les mots de passe.

Finalement, j'ai été étonné par la différence entre une mise à jour via Gnome-Software (qui supprime automatiquement les dépendances non-désirées) et une réinstallation complète. Je n'ai pas compris la cause qui a provoqué cela, alors que fedora 28 tourne comme une horloge. Un début de réponse est que nouveau prend mal en charge la carte graphique utilisée, car, en réinstallant Fedora 28, il y a un gros problème avec des signalements lié à Xorg dans une session de Wayland, l'installation de bumblebee règle le souci.

edit: Après une mise à jour le 24 novembre 2018 via gnome-software pas de souci à reporter. De plus, Fedora 29 semble plus réactive que fedora 28, impressionnant!

Bonjour à tous et à toutes,

Configuration:
CPU: i7-8550U
RAM : 16 Go DDR4
GPU : Nvidia Gforce 1050 4G +(carte graphique intel intégrée dans le processeur)
DD : 256 Go SSD + 1 To disque dur mécanique 5400 trs\min.
Environnement de bureau: Gnome 3 (wayland et quelquefois X pour les tests de optimus)

Méthode d'installation:
Étant passé de Debian à Fedora 27 fin avril 2018, puis testé une mise à jour vers fedora 28, je n'ai pas rencontré de problèmes particuliers. Puis réinstallation de 0 à partir d'un liveUSB de Fedora 28, l'installation s'est bien passé (le partitionnement manuel pour un SSD+ disque dur mécanique a été difficile à comprendre la première fois).

- Problèmes majeurs :
Rien de particulier.

- Soucis mineurs :

Je remarque, pour le moment, que certains logiciels sont mal configurés par défaut.
1) minidlna (serveur UpNp n'est pas configuré convenablement, en tout cas pas à son optimum), mais problème résolu.

2)Difficulté de configurer optimus et prime avec les pilotes propriétaires sous fedora 27 pour prime et optirun, mais résolu et "correction du bug" indiqué dans ce post quand on désinstalle prime.
Sous Fedora 28, optimus marche à peu près bien avec les paramètres par défaut (il faut ajouter un paquet pour prendre en charge les programmes 32 bits). Prime n'a pas encore été testé.

3) Détection de la carte utilisée via les extensions de gnome-software ne fonctionnent pas, pour le cas des ordinateurs équipés de optimus, (moyen de contournerment trouvé).

4)PCSX2 est bugué concernant la configuration de la manette, le programme se ferme automatiquement, plus son qui "craque" (moyens de contournements trouvé) .

5)Il semble que XEN n'est plus maintenu par Fedora, mais je n'ai pas encore cherché à résoudre le problème.


- Points positifs :
1) Fedora est visuellement une très belle distribution.
2)J'aime l'utilisation de paquets récents, surtout qu'en ce moment, j'étudie la virtualisation\paravirtualisation sous qemu\kvm\virt-manager (bien que ce soit très vaste), les paquets récents sont un plus.
3)J'aime le support des pilotes récents.
4) j'aime le shell coloré par défaut.
5) Ce que j'aime par dessus tout, c'est d'utiliser une distribution qui respecte l'utilisateur et le respect des choix de vie privée (concernant les rapports de bugs à envoyer ou non).


- Points négatifs :
1) J'aimerai obtenir la recette de compilation de gros programmes pour pouvoir déterminer l'origine d'un bug (cas pour PCSX2), mais ce n'est pas spécifique à Fedora.

Cordialement