Reprise du message précédent :
si c'est comme sous Ubuntu, c'est un coup de bluez ça

Ah cette commande bien utile que j'oublie toujours. Merci  

Redémarrage assez rapide ce soir mais le freeze juste avant l'apparition de xfce reste plus long que la normale:

Avec le coupable probable:

Bluez n'est pas dans la liste, ce qui me convient vu que je n'utilise pas le blutooth.

Si c'est un prb de network, au hasard, essaye peu etre avec une ip fixe plutôt que dhcp et/ou de changer de serveur de dns si tu a ceux de ton provider par ceux de google, freedns etc...
 
Ca explique pas l'origine du prb mais ca le resoudra peu etre directement

Ce n'est finalement pas un problème de réseau. En boot sans aucune interface réseau il z a toujours cette pause après le login. Rien pourtant ne l'explique dans la liste  

ça ressemble à un timeout votre truc, vous avez regardé les log de votre desktop manager ?
 
Si c'est ligthdm ça doit se trouver vers :

C'est peut-être bien ça, appuyer sur echap après le login améliore en tout grandement la vitesse d'apparition du bureau.  
 
 
Voici mon lightdm.log:
 

Il lancerait 2 sessions?

De ce que je pige c'est que dans un premier temps il plante car il n'arrive pas à ouvrir ta session avec l'utilisateur priareos.
 
On voit d'ailleurs que sur l'auth réussie, il charge la langue US. C'est la langue de ton installation ?

En ligne de commandes tout marche parfaitement. Je vais créer un second compte pour voir si ça marche mieux. Pour la langue US, oui c'est correct.

rm -rvf /home/<user>/.cache/session
sans conviction.
Il arrive parfois que virer ce dossier règle des problèmes.

Merci mais ça ne marche malheureusement pas, pas plus que de créer un nouveau profil.

Lightdm j'ai toujour eu des emmerdes perso. que cela soit en le configurant au petit oignons en epluchant la doc et les tutos ou en le laissant avec une config plus ou moins par défaut, ca a jamais tenu plus de deux semaines sans avoir des problèmes de login ensuite. J'ai eu beau épluché les solutions du net, les logs, vider le cache, verifier les droits, les fichiers etc... j'ai jamais trouver la source du/des prb et depuis je met systématiquement sddm qui me fait pas ça..  
 
Le seul truc qui marchait quelque temps c'etait de tout virer, lightdm, greeter et conf et de tout reinstaller

Bonjour, y a-t-il des gens ici qui utilisent debian (sid tant qu'à faire) sous btrfs ? Ça fonctionne bien ?

 
J'ai testé avec ssdm mais ça ne venait pas de là non plus. Aujourd'hui la mise à jour a remis les choses dans l'ordre. Comme quoi il faut se méfier des mises à jour sous Debian également.

C'est quand même assez rare.
 
Généralement un simple dpkg-reconfigure permet de régler le problème.

et sur un autre port usb?

et une autre souris?

Concernant les problèmes de bureau et gestionnaire de bureau, j'ai remarqué que la cohabitation n'était pas terrible entre mate/gnome/gdm3/lightdm.
 

Un truc à tester pour les utilisateurs de Mate et gdm3:
Dans /etc/gdm3/daemon.conf, il y a une ligne #WaylandEnable=false pour désactiver la session Wayland de gdm3 ...
 
Je pense que Gnome 3 est ce qui est arrivé de pire au projet GNU de toute son histoire

 Encore faut-il trouvé le bon package. J'en ai réinstallé une bonne quantité mais pas suffisamment peut-être.

Pas sur, avec systemd et pulse il y a de la concurrence, et de quoi relancer quelques beaux débats houleux
 

ha... effectivement ça devient compliqué ton histoire  

 
J'ai eu la chance que la mise à jour suivante résolve le problème. J'ai bien l'impression que j'aurais pu chercher longtemps si ça n'avait pas été le cas.

Pour systemd, je serais moins catégorique, dans le sens où les dépendances sont un vrai plus. Le côté usine à gaz qui fait le café est un vrai problème.
Pour pulse, il aurait peut-être été mieux de bosser sur jackd ...
 

pulseaudio et systemd ne font pas partie de GNU
 
jack est pas vraiment fait pour de l'usage « courant » (et on peut objecter qu'il aurait fallut bosser sur esd ou aRts à la place de créer un nouveau truc à l'époque).

Même s'ils ne font pas partie du projet GNU, ils sont installés par défaut sur la plupart des distributions GNU/Linux, et en sont des composants essentiels ...
 
Je pense que jack aurait fait une meilleure base pour un serveur de sons généraliste
 

Oui j'ai pris un mega raccourci là  

Des gens qui utilisent knockd pour sécuriser un poil mieux le SSH ?

Siwi en terme de taille de log ça donne quoi ? C'est pour un Raspi qui me sert de SSH (et de pihole ), du coup carte SD donc pas top en cas d'écriture intensive.

Boarf, tu changes le port et auth avec une clé only et rulz
 
XaT

 
Tout dépend de la sécurité que tu souhaites. Ça rend les attaques par brute force totalement inefficaces.

 
Bouarf. Changer de port c'est comme changer le numéro de rue sur son adresse postale. Si tu connais le facteur il sait où t'habites.

 
Je l'ai eu fait sur des dedi mais c'etait un peu too much
 
Comme dit en dessus change de port, c'est pas une reel protection en soit mais ca eliminera deja 90% les bots et scan de base.  
met un clé ssh/password fort, autorise seulement les users nécessaires a ce logger et basta
Tu peu aussi autoriser seulement certaines ip via la conf si ta pas besoin d'accéder a ssh avec 50 ip différentes ou dynamique.
 
Rien qu'avec une config correct de ton ssh ya personne qui va aller s'amuser a bruteforce ca, encore moins pour un rpi

Changer le port je suis désolé mais ça reste le trucs plus oldies et inutile que je connaisse .
 
N'importe quel pseudo hacker sera capable de faire un scran de port.
 
Par contre l'auth par clé uniquement est un bon truc !  
 
Et le port knocking me parait une très bon complément à l'auth par clé

faut voir la criticité de la machine mais bon dans 99% des cas, auth par clé + système tenu à jour c'est déjà suffisant, avec fail2ban en plus éventuellement.

Pour le changement de port je suis du même avis que Robin-k. Enfin ce n'est même pas un avis mais un fait. Comme lui j'ai diminué les scans à presque rien depuis que j'ai changé de port.  
OK, si on veut m'attaquer moi personnellement on finira par trouver mon port ssh mais contre les attaques à la cantonade c'est radical.
 
J'ai lu que fail2ban pesait beaucoup sur les ressources. Il faudra que je teste.

C'est léger f2b, je l'ai sur un pov' RPi1 et ça tire peanuts.

de mémoire il me semble que fail2ban ça se contente de lire les logs toutes les X minutes et d'ajouter une règle iptable si besoin (et de l'enlever au bout d'un certain temps), donc pas de raison que ça consomme tellement de ressources.

Ca réduit une grosse partie des bots qui scan le net a la truelle sur les ranges de ports les plus "vulnérables" utilisés par défaut pour essayer d'y lancer la fail 0day a la mode et/ou de finir indexé sur shodan & co
Un hacker il va pas aller s'amuser a faire 3 mois de bruteforce sur le ssh d'un rpi.
 
Un script kiddies, il va par exemple scanner uniquement les bannière du port 22 a la recherche des rpi et essayer d'ouvrir le compte root par defaut pi///raspberry.  
vu que c'est une recherche assez ciblé, ça va très vite, tu peu scanner plusieurs milliers d'ip à la secondes rien qu'avec 100ko d'upload plutôt que t'emmerder a scanner 65K ports.
C'est comme ça que tu te retrouve avec des articles de gars qui on constituer leur botnet de plusieurs millier d'iot en quelques jours juste en exploitant une bête faille / un identifiant par défaut / hardcodé dans du vieux matériel abandonné ou fraîchement commercialisé  
Donc sur le fond changer certains port par défaut, c'est sur, c'est très con, mais ça reste efficace et d'actualité contre les scans à la truelle et au pire ça t’allégera quelques centaines de lignes dans les logs de connexions échouées.  
 
Dans le même genre a la con, les partages smb, tu serait surpris de voir le nombre de To (encore) accessibles en openbar sur le net (pourtant c'est oldies, faut ressortir les tuto de l'an 2000 )

ici : clé ssh uniquement pour être sur et un fail2ban assez agressif pour être parano  
 
Sinon, pour moi la confidentialité n'est pas de la sécurité  

Qu'est- ce que je déteste leur foutu système de "Multiarch" mis en place depuis Wheezy.  
 
Maintenant c'est le bordel pour compiler une application 32bits sur un système 64bits car certaines librairies de développement ne peuvent pas coexister sur un système. Exemple, les librairies de développement de LLVM ne peuvent pas être installés ensemble en 64bits et 32bits sur un système 64bits...
 
Je regrette le temps de la Squeeze avec ses librairies en lib32-XXX comme sur Arch ...