Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 Re : GNOME 3 » [RESOLU] Affichage accueil gdm3 sur deuxième écran » 11-02-2020 23:21:23

Épilogue suite à la mise à jour de stretch vers buster.

Échaudé par le comportement de l’écran de session de gdm3 et en prévision de l’arrivée par défaut de wayland sur gnome dont la documentation utilisateur me laisse pantois, j’ai installé lightdm qui utilise le bon vieux Xorg.

La mise à jour terminée je me suis retrouvé avec un écran noir (serveur X planté). Seules les console tty étaient accessibles.

J’ai pu travailler en root.
Après moult manipulations pour comprendre l’origine du défaut en consultant les logs, les fichiers de configurations et mon forum préféré avec w3m, j’ai bricolé sans succès le fichier /etc/X11/xorg.conf.d/xorg.conf. Enfin par dépit j’ai supprimé ce fichier de configuration et… miracle lightdm a bien voulu démarrer correctement.

L’accès à ma session utilisateur se déroule sans souci. Mais problème pour les autres utilisateurs, leurs sessions s’affichent sur l’écran du moniteur du portable (qui n’existe plus).

Avec un peu de recherche j’ai fini par trouver les deux fichiers de configurations existants sur ma session que j’ai copié dans les autres répertoires utilisateurs :

cat ~/.config/monitors.xml



<monitors version="1">
  <configuration>
    <clone>no</clone>
    <output name="eDP-1">
      <vendor>CMN</vendor>
      <product>0x1731</product>
      <serial>0x00000000</serial>
      <width>1600</width>
      <height>900</height>
      <rate>40.001335144042969</rate>
      <x>0</x>
      <y>0</y>
      <rotation>normal</rotation>
      <reflect_x>no</reflect_x>
      <reflect_y>no</reflect_y>
      <primary>yes</primary>
      <presentation>no</presentation>
      <underscanning>no</underscanning>
    </output>
  </configuration>
  <configuration>
    <clone>no</clone>
    <output name="HDMI-1">
      <vendor>HPN</vendor>
      <product>HP 22f</product>
      <serial>3CM8160LVS   </serial>
      <width>1920</width>
      <height>1080</height>
      <rate>59.940200805664062</rate>
      <x>0</x>
      <y>0</y>
      <rotation>normal</rotation>
      <reflect_x>no</reflect_x>
      <reflect_y>no</reflect_y>
      <primary>yes</primary>
      <presentation>no</presentation>
      <underscanning>no</underscanning>
    </output>
    <output name="eDP-1">
      <vendor>CMN</vendor>
      <product>0x1731</product>
      <serial>0x00000000</serial>
    </output>
  </configuration>
</monitors>
 



cat .config/xfce4/xfconf/xfce-perchannel-xml/displays.xml



<?xml version="1.0" encoding="UTF-8"?>

<channel name="displays" version="1.0">
  <property name="Default" type="empty">
    <property name="HDMI-1" type="string" value="1. HPN 23&quot;">
      <property name="Active" type="bool" value="true"/>
      <property name="Resolution" type="string" value="1920x1080"/>
      <property name="RefreshRate" type="double" value="60.000000"/>
      <property name="Rotation" type="int" value="0"/>
      <property name="Reflection" type="string" value="0"/>
      <property name="Primary" type="bool" value="false"/>
      <property name="Position" type="empty">
        <property name="X" type="int" value="0"/>
        <property name="Y" type="int" value="0"/>
      </property>
    </property>
  </property>
</channel>
 



Depuis tout fonctionne.

#2 Re : GNOME 3 » Agenda la Mère Zaclys et Evolution » 11-02-2020 19:39:19

Plus de problème chez moi également.

@nam1962 OVH n’a rien à voir avec le problème. L’erreur 500 est généré par le serveur qui appartient à zaclys.

#3 Re : GNOME 3 » Agenda la Mère Zaclys et Evolution » 10-02-2020 22:19:36

Je viens de mettre à jour en debian 10.3
Pareil.

Le problème semble provenir du serveur zaclys.

#4 Re : GNOME 3 » Agenda la Mère Zaclys et Evolution » 10-02-2020 21:51:34

J’ai le même souci avec debian 10.2 (aucun problème auparavant sous stretch).
Aucun souci avec ma tablette android.
Error 500 est un bug du serveur zaclys.
Problème étrange…

PS : j’ai copié sur le forum zaclys.

#5 Re : Installation de Debian » [RÉSOLU] Écran noir session lightdm suite mise á jour » 02-02-2020 23:03:40

Bon j’ai a priori résolu le problème.
Après moult manip infructueuses à essayer de modifier la configuration du fichier /etc/X11/xorg.conf.d/xorg.conf, une idée de génie m’a traversé la tête zen.gif, j’ai tout simplement supprimé le fichier et depuis cela fonctionne.

J’en conclurais presque le besoin de ce fichier sous stretch avec ma configuration matérielle particulière était dû à un bug corrigé depuis sous buster…

Je passe en résolu.

#6 Re : Installation de Debian » [RÉSOLU] Écran noir session lightdm suite mise á jour » 02-02-2020 20:56:01

Réponse de

xfdesktop


échec de l'analyse des arguments : Impossible d'ouvrir l'affichage



Sinon j'ai basculé sur gdm3, même problème.

#7 Installation de Debian » [RÉSOLU] Écran noir session lightdm suite mise á jour » 02-02-2020 19:00:42

Philou92
Réponses : 3
Hello,
Tout est dans le titre. Cela fait suite á la mise á jour de debian 9 vers 10.
J'ai accès á la console tty1
J'ai essayé de réinstaller lightdm sans succès.
Je me demande si mon problème serait peut-être dû à mon post https://debian-facile.org/viewtopic.php?id=22542
Bref je sèche.

#9 Re : Débuter avec la ligne de commande » mise à jour de routine avec "apt", quelles commandes recommandées? » 01-02-2020 22:51:16

En mode intéractif (commande effectuée manuellement) apt et apt-get sont interchangeables, avec une préférence pour apt sous buster car les informations retournées sont plus riches qu’avec apt-get.
Par contre dans un script il faut exclusivement utiliser apt-get.

Pour la fréquence de mise à jour de sécurité, il faut le faire aussi souvent que possible dès qu’un paquet installé est concerné.
Personnellement je suis abonné aux annonces de sécurité debian pour être régulièrement informé. https://www.debian.org/security/#DSAS

#10 Re : Installation de Debian » [RÉSOLU] Utilité de 70-persistent-net.rules ? » 01-02-2020 22:40:06

Merci Beta-Pictoris smile

Dois-je comprendre que ce fichier ne servait uniquement a renommer les interfaces réseaux à l’ancienne mode et que maintenant il est obsolète ?

#11 Installation de Debian » [RÉSOLU] Utilité de 70-persistent-net.rules ? » 01-02-2020 22:18:19

Philou92
Réponses : 5
Hello,

Je vais bientôt procéder à la migration de ma machine de debian 9 vers debian 10.
Aussi j’applique les recommandations de la note de publication avant le grand saut.
Ma debian 9 étant elle-même déjà issue d’une précédente migration de debian 8, la machine avait conservé les anciens nom d’interface réseau (ETH0 et WLAN0)
J’ai exécuté avec succès les étapes proposées dans la note https://www.debian.org/releases/stable/ … face-names, tout fonctionne à merveille, les deux noms d’interface se sont transformés en enp3s0f1 et wlp2s0.

Et…

Et bien j’ai deux questions subliminales…
Notamment j’ai renommé le fichier /etc/udev/rules.d/70-persistent-net.rules en /etc/udev/rules.d/70-persistent-net.rules.bak.
J’ai pensé naïvement que le fichier /etc/udev/rules.d/70-persistent-net.rules allait être régénéré au démarrage. Que nenni !

D’où mes questions : est-il important de créer à nouveau ce fichier ? Si oui, comment le rédiger ?

cat /etc/udev/rules.d/70-persistent-net.rules


# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# Note j’ai volontairement masqué les adresses MAC

# PCI device 0x10ee:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="80:aa:aa:aa:aa:aa", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x08ee (iwlwifi)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="80:bb:bb:bb:bb:bb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

#12 Re : Autres » boite dialogue gmail » 24-01-2020 22:48:01

rodrigue7973 a écrit :

bonsoir

quelqu'un a enlève boite du dialogue gmail


Hello rodrigue7973
Que faut-il comprendre ?
J’interprète ta phrase de deux façon différente :
1) tu n’as plus la boite de dialogue qui s’affiche et tu ne peux plus accéder à ton compte gmail
2) tu as cette nouvelle boite de dialogue qui s’affiche et tu ne sais pas pourquoi et comment faire pour accéder à ton compte gmail.

#13 Re : Système » Freshclam actif... mais mise à jour disponibles ? » 21-01-2020 23:03:54

A priori c’est le même souci que j’ai cité plus haut, le mirroir db.local.clamav.net n’est pas accessible et provoque des messages d’erreur.
Ouvre le fichier /etc/clamav/freshclam.conf avec un éditeur avec les droits root.
Ajoute un caractère "#" devant l’avant dernière ligne pour la "commenter" de cette façon :

#DatabaseMirror db.local.clamav.net


Puis enregistre le.

#14 Re : Système » Freshclam actif... mais mise à jour disponibles ? » 21-01-2020 22:20:23

Peux-tu retourner le contenu du fichier :

cat /etc/clamav/freshclam.conf



J’ai rencontré un problème similaire ici : https://debian-facile.org/viewtopic.php?id=23989

#15 Re : Réseau » [QUESTION BÊTE]Connexion SSH vraiment moins sécurisé par mot de passe? » 20-01-2020 00:11:49

infothema a écrit :


1) Oui ton mot de passe de connexion est en clair dans les scripts qui se servent de SSH si tu n'as pas de clés !


Je n’utilise pas de script pour me connecter à SSH.
Utiliser des scripts avec des mots de passe en clair ce n’est pas sérieux. Autant coller un post-it avec le mot de passe dessus sur l’écran du PC.

infothema a écrit :


2) Avec un mot de passe "lechiendelavoisine@15estVERT", Il est plus facile de brute forcer ton serveur SSH surtout si il est visible sur le web


C’est plus facile que "lechiendelavoisine@15estVERT?" et moins facile que "lechiendelavoisine15estVERT". Pas très solide comme argument.

infothema a écrit :


4) Ton hébergeur pro te conseillera toujours l'usage des clés en SSH sur ton serveur


J’espère que tu as un accès physique chez ton hébergeur PRO, parce-que si ta clef est corrompue sur le serveur, ou si celle du serveur change , alors tu ne pourras plus y accéder.

infothema a écrit :


Pour résumer, la sécurité se résume à l'usage du protocole SSH avec des clés hautement sécurisées (génération)


Je peux aussi utiliser un mot de passe super long et complexe.

infothema a écrit :


Si tu n'es toujours pas convaincu, je t'invite à visiter ces liens :

https://www.supinfo.com/articles/single … orce-ligne de l'école Supinfo

https://www.securiteinfo.com/attaques/h … ydra.shtml



Pas convaincu.
Ces outils cassent des mots de passe. Ils ne cassent pas SSH.
SSH est un protocole de connexion visant à sécuriser les échanges sur un réseau. Évidemment il est important de protéger le client et le serveur. Ce dernier nécessite à minima une bonne configuration du pare-feu (connexion SSH réservée à des IP/domaine clients connus et l’usage de l’application fail2ban rendent très difficile l’attaque par force brute) et une surveillance des alerte de tentative de connexion.

#16 Re : Réseau » [QUESTION BÊTE]Connexion SSH vraiment moins sécurisé par mot de passe? » 13-01-2020 20:48:41

infothema a écrit :



Que le mot de passe en clair fasse 52 éléments avec des .+-"@7-~ ne change à l'affaire : il est en clair !  smile



En clair ?? Tu dois confondre avec telnet, le mot de passe d'hautentification est chiffré avec ssh.

#17 Re : Réseau » [QUESTION BÊTE]Connexion SSH vraiment moins sécurisé par mot de passe? » 11-01-2020 19:19:41

otyugh a écrit :


D'où vient cette affirmation ?



Du bon sens. Comme tu l’as précisé les deux méthodes nécessitent l’usage d’un mot de passe.

otyugh a écrit :


Mais vu que tu me contredis.


Il n’y a pas de contradiction. Ce n’est qu’une affaire de choix. Le meilleur étant celui que l’on maîtrise le mieux en fonction du contexte d’utilisation.

La connexion par clef est pratique pour l’administrateur qui doit joindre plusieurs serveurs (seul le mot de passe de sa clef privée est nécessaire). Il doit tout de même s’assurer que la machine cliente ne présente pas de faille, malware, keylogger etc… Ce qui à mon avis devient compliqué s’il doit se connecter depuis plusieurs machines clientes différentes. Que dire de la connexion par clef depuis son « abrutiphone », du PC ouinedauze de la voisine etc…
Avec la méthode par mot de passe, on risque la compromission d’un serveur (en admettant que tous les mots de passe des users de tous les serveurs sont différents), avec l’échange de clef on risque de tous les compromettre.

Le principal danger à mon avis serait de se croire plus en sécurité avec une méthode plutôt qu’avec une autre.

otyugh a écrit :


je suis curieux de confirmer la validité de mon erreur).



Je ne vois pas d’erreur dans ce que tu as écris. smile

#18 Re : Réseau » [QUESTION BÊTE]Connexion SSH vraiment moins sécurisé par mot de passe? » 11-01-2020 00:34:46

L’utilisation d’une connexion SSH par mot de passe ou par échange de clef est équivalente en terme de sécurité.
L’échange de clef du client vers le serveur est juste une question de confort d’utilisation, notamment dans le cas où le client souhaite se connecter en SSH à plusieurs machines différentes avec le même mot de passe (celui de sa clef privée). L’inconvénient est que si le mot de passe de la clef privée est compromise, toutes les machines le deviennent  également.
Je pense que dans le cas exposé par @Jahkyn au post #1, connexion en SSH à la même machine par mot de passe depuis des clients différents est la plus sûre, puisque moins complexe à gérer dans ce contexte. Fail2ban est efficace contre les attaques par force brute. j’ajouterai la surveillance régulière des logs de connexion voire l’envoi d’un mail pour chaque bannissement effectué par fail2ban.

#19 Re : Suivi du Wiki et des Projets Git » Wiki - commande TAR » 23-12-2019 19:20:11

Les certitudes peuvent se révéler dangereuses avec la commande tar.
La consultation du manuel complet est nécessaire pour bien la comprendre. Le manuel de gnu tar fait 250 pages https://www.gnu.org/software/tar/manual/tar.pdf

La section 3.3 met en garde sur la position des options en fonction des différents styles d’écritures :

There are three styles for writing operations and options to the command
line invoking tar. The different styles were developed at different times
during the history of tar. These styles will be presented below, from the
most recent to the oldest.
Some options must take an argument 1 . Where you place the arguments
generally depends on which style of options you choose. We will detail spe-
cific information relevant to each option style in the sections on the different
option styles, below. The differences are subtle, yet can often be very im-
portant; incorrect option placement can cause you to overwrite a number
of important files. We urge you to note these differences
, and only use the
option style(s) which makes the most sense to you until you feel comfortable
with the others.
Some options may take an argument. Such options may have at most
long and short forms, they do not have old style equivalent. The rules for
specifying an argument for such options are stricter than those for specifying
mandatory arguments. Please, pay special attention to them



Voir la section 6.3 Reading Names from a File page 112 pour trouver l’explication de la commande que je t’ai fourni.

#20 Re : Système » Obligé de rentrer ma passphrase enigmail à chaque redémarrage. » 23-12-2019 13:56:27

Juste comme ça, ne serait-ce un bête truc qui coince avec le daemon gpg-agent ?

#21 Re : Suivi du Wiki et des Projets Git » Wiki - commande TAR » 23-12-2019 13:38:06

L'ordre des options est important avec la commande tar.

As-tu noté une amélioration de performance avec la commande que j'ai écrite ci-dessus ?

#22 Re : Le bar » .org et bloqueur de pub » 22-12-2019 14:41:40

Je propose que l'on supprime la pub pour voir si ta théorie tient la route.

Pour moi la pub ne finance rien, elle coûte.
Sa seule fonction est de faire grossir les dividendes qui est un centre de coût cela en suscitant des besoins de consommations inutiles.

Pour ce qui est de ce site, il est financé par ses adhérents, maintenu par un collectif de bénévoles et animé par tout ses membres.

#23 Re : Scripts et automatisations de tâches » [Résolu] mon script s'arrête » 22-12-2019 10:31:23

otyugh a écrit :

Avec bash, je crois que tu peux faire quelque chose comme :

commande &
#remplace commande par ton rsync
disown $!



Astucieux.  Tu devrais pouvoir attacher ton processus avec un logiciel comme rptyr à condition d'avoir noté son pid.

Néanmoins, l'avantage pratique de tmux est que si ton processus génère des messages ils seront affichés dans la sortie standard de ton terminal tmux.

#24 Re : Scripts et automatisations de tâches » [Résolu] mon script s'arrête » 21-12-2019 21:19:14

En fait on appelle ça un terminal virtuel. J'ai écris persistant car tu peux te détacher du terminal.
Perso quand je me connecte en ssh, j'ouvre un terminal tmux avant de faire quoique ce soit. En cas de déconnexion intempestive mon tmux est toujours en vie et je pourrai m'y attacher dès la prochaine connexion

https://debian-facile.org/doc:systeme:tmux

Si tu utilises crontab effectivement tu n'auras plus de problème.

#25 Re : Scripts et automatisations de tâches » [Résolu] mon script s'arrête » 21-12-2019 21:01:31

J'oserai dire que pour faire ce genre de manip il te faut utliser un terminal persistant sur pcb, comme screen ou tmux (avec une préférence pour ce dernier).

Pied de page des forums

Propulsé par FluxBB