Re: full-upgrade to buster

[fred]

Le 09/07/2019 à 23:01, Jean Bernon a écrit :

- Mail original -


De: "hamster" 
À: debian-user-french@lists.debian.org
Envoyé: Mardi 9 Juillet 2019 22:51:05
Objet: Re: full-upgrade to buster
Le 09/07/2019 à 21:13, fred a écrit :

y a t il ici des persones suceptibles de partager leur expertise
sur
un upgrade depuis debian9 ?

Je me pose la question de l'interet de l'upgrade. C'est long, au
moins
aussi long qu'une installation, ca implique de télécharger a peu près
autant de données que pour une install, ca prend beaucoup de place
dans
la partition racine vu qu'a un moment l'ancienne et la nouvelle
version
sont cote a cote sur le disque et ca peut planter si on a installé
des
logiciels en provenance de dépots tiers comme par exemple libdvdcss2
pour pouvoir lire des DVD.
Du coup je me demande quel interet il y a a faire une upgrade plutot
que
re-installer sans toucher a la partition /home afin de ne pas perdre
sa
configuration.

J'ai fait l'upgrade hier. C'est long en effet (2H dans mon cas), mais ça s'est 
bien passé. Comment fait-on une réinstall sans toucher /home ?



Merci Jean,
tu mets le focus sur le point évident : upgrade sans modifier tout ce 
qui est *caché* dans /home


--
Fred,

Re: full-upgrade to buster

[fred]

le seul intérêt c'est de pas modifier /home, et bien sur tous les 
réglages/configs/etc... non ?


Le 09/07/2019 à 22:51, hamster a écrit :

Le 09/07/2019 à 21:13, fred a écrit :

y a t il ici des persones suceptibles de partager leur expertise sur
un upgrade depuis debian9 ?

Je me pose la question de l'interet de l'upgrade. C'est long, au moins
aussi long qu'une installation, ca implique de télécharger a peu près
autant de données que pour une install, ca prend beaucoup de place dans
la partition racine vu qu'a un moment l'ancienne et la nouvelle version
sont cote a cote sur le disque et ca peut planter si on a installé des
logiciels en provenance de dépots tiers comme par exemple libdvdcss2
pour pouvoir lire des DVD.

Du coup je me demande quel interet il y a a faire une upgrade plutot que
re-installer sans toucher a la partition /home afin de ne pas perdre sa
configuration.




--
Fred,

Re: full-upgrade to buster

[hamster]

Le 09/07/2019 à 23:01, Jean Bernon a écrit :
> J'ai fait l'upgrade hier. C'est long en effet (2H dans mon cas), mais
> ça s'est bien passé. Comment fait-on une réinstall sans toucher /home ?

Il faut bien sur que /home soit sur une partition séparée. Quand on
installe, au moment de formater on refuse les formatages automatiques
proposés et on choisit l'option de formatage manuel. On configure pour
que la partition contenant les données personnelles soit montée sur
/home et qu'elle ne soit pas formatée. Au moment de créer des
utilisateurs, on crée les memes et dans le meme ordre pour qu'ils aient
les mêmes numéros identifiants.

Il faut ensuite refaire aussi les configurations qui sont du coté du
système, dans /etc (unattended-upgrades, fail2ban, lightdm, sudoers,
etc…) mais ca se fait très bien en copiant les fichiers de configuration
depuis la sauvegarde qu'on a pas manqué de faire avant de réinstaller ou
upgrader.

Re: full-upgrade to buster

[fred]

Oh, t'as raison, pardon pour le bruit mes excuses merci de ne pas répondre !

Le 09/07/2019 à 22:36, Jean-Michel OLTRA a écrit :

 Bonjour,


Le mardi 09 juillet 2019, fred a écrit...



y a t il ici des persones suceptibles de partager leur expertise sur un
upgrade depuis debian9 ?

Hmmm ! On va attendre encore un peu…



--
Fred,

Re: full-upgrade to buster

[Jean Bernon]

- Mail original - 

> De: "hamster" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mardi 9 Juillet 2019 22:51:05
> Objet: Re: full-upgrade to buster

> Le 09/07/2019 à 21:13, fred a écrit :
> > y a t il ici des persones suceptibles de partager leur expertise
> > sur
> > un upgrade depuis debian9 ?

> Je me pose la question de l'interet de l'upgrade. C'est long, au
> moins
> aussi long qu'une installation, ca implique de télécharger a peu près
> autant de données que pour une install, ca prend beaucoup de place
> dans
> la partition racine vu qu'a un moment l'ancienne et la nouvelle
> version
> sont cote a cote sur le disque et ca peut planter si on a installé
> des
> logiciels en provenance de dépots tiers comme par exemple libdvdcss2
> pour pouvoir lire des DVD.

> Du coup je me demande quel interet il y a a faire une upgrade plutot
> que
> re-installer sans toucher a la partition /home afin de ne pas perdre
> sa
> configuration.

J'ai fait l'upgrade hier. C'est long en effet (2H dans mon cas), mais ça s'est 
bien passé. Comment fait-on une réinstall sans toucher /home ?

Re: Répertoire source de Linux

[Jean Bernon]

- Mail original - 

> De: "Étienne Mollier" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mardi 9 Juillet 2019 20:18:38
> Objet: Re: Répertoire source de Linux

> Jean Bernon, au 2019-07-09 :
> > Je viens de migrer sans problème de Stretch à Buster. Mais
> > j'utilise un driver wifi/bluetooth spécial (mt7630e) que je
> > dois réinstaller à chaque changement de version Linux. Les
> > scripts d'installation ont fonctionné sans problème depuis 5
> > ans. Avec Buster le script d'installation du wifi a bien
> > fonctionné. En revanche côté bluetooth, le script qui patche
> > btusb.c et génére un btusb.ko modifié, bute sur la création
> > d'un répertoire source de Linux. Il y a un problème inédit de
> > source signé et non signé que je comprends mal. En tout cas le
> > script veut désinstaller linux-image-4.19 et installer à la
> > place une version non signée. Voir ci-dessous.
> >
> > Si je réponds OK, j'obtiens un ferme avertissement de ne pas
> > continuer...
> >
> > Qui aurait une suggestion pour en sortir sans tout casser ?

> Bonsoir,

> Les paquets linux signés et non-signés le sont au sens du « UEFI
> Secure Boot », dont le support est apparu en Debian 10. En
> utilisant un paquet non-signé, le boot UEFI Secure Boot ne sera
> plus possible. Étant donné que vous avez migré depuis Debian
> Stretch, je suppose que vous n'avez pas activé cette option de
> sécurité entre temps.

> À mon sens, il n'y a pas de risque majeur de casse.

> Bien à vous,
> --
> Étienne Mollier 
> 5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D

Merci pour l'explication. Je vais piocher ça un peu plus, avant de relancer le 
script. Le bluetooth n'est pas immédiatement indispensable. Je donnerai un 
retour à ce moment.

Re: full-upgrade to buster

[hamster]

Le 09/07/2019 à 21:13, fred a écrit :
> y a t il ici des persones suceptibles de partager leur expertise sur
> un upgrade depuis debian9 ?

Je me pose la question de l'interet de l'upgrade. C'est long, au moins
aussi long qu'une installation, ca implique de télécharger a peu près
autant de données que pour une install, ca prend beaucoup de place dans
la partition racine vu qu'a un moment l'ancienne et la nouvelle version
sont cote a cote sur le disque et ca peut planter si on a installé des
logiciels en provenance de dépots tiers comme par exemple libdvdcss2
pour pouvoir lire des DVD.

Du coup je me demande quel interet il y a a faire une upgrade plutot que
re-installer sans toucher a la partition /home afin de ne pas perdre sa
configuration.

Re: [autre sujet ][pertinence des préoccupations lumière bleue] : Lumière bleue des moniteurs led ?

[Basile Starynkevitch]

On 7/9/19 3:59 PM, toto wrote:

Rebonjour à tous !.

J'ai bien noté :

F.Lux et Redshift :
https://wiki.visionduweb.fr/index.php?title=Installer_Configurer_Utiliser_des_logiciels_sur_GNU_Linux#F.lux

Je regarde cela desuite !

Pour info : je pose cette question car lorsque je travaille devant mon écran
tft lcd 19 pouces toute la journée je n'ai aucune  irritation aux yeux par
contre devant mon écran led de portable qui a à peu près 4 ans j'ai les yeux
un peu irrités même après seulement deux ou trois heures d'utilisation.



Ca peut être dû à un microtremblement visuuel de chaque pixel. Par 
expérience, ça donne la migraine. Et RedShift n'arrangera rien.



Librement

--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France; 
(mobile phone: cf my web page / voir ma page web...)

Re: full-upgrade to buster

[Jean-Michel OLTRA]

Bonjour,


Le mardi 09 juillet 2019, fred a écrit...


> y a t il ici des persones suceptibles de partager leur expertise sur un
> upgrade depuis debian9 ?

Hmmm ! On va attendre encore un peu…

-- 
jm

Re: full-upgrade to buster

[fred]

Merci à toi JC, j'y cours !!!

Le 09/07/2019 à 21:53, JC.EtiembleG a écrit :

Le 09/07/2019 à 21:13, fred a écrit :
y a t il ici des persones suceptibles de partager leur expertise sur 
un upgrade depuis debian9 ?


Tu vas sur https://debian-facile.org/forum.php, il y a des mises à 
jour effectuées ;)




--
Fred,

Re: [autre sujet ][pertinence des préoccupations lumière bleue] : Lumière bleue des moniteurs led ?

[Pierre L.]

Hello,
peut-etre pas le même emplacement ? (une fenêtre derrière, reflet...)
Ou l'habitude d'utiliser le portable en fin de journée, avec des yeux
déjà un peu fatigués...?
Un écran de portable plus petit, avec une police de caractères plus
petits aussi que la version bureau, donc les yeux travaillent un peu plus ?



Le 09/07/2019 à 15:59, toto a écrit :
> Pour info : je pose cette question car lorsque je travaille devant mon écran
> tft lcd 19 pouces toute la journée je n'ai aucune  irritation aux yeux par
> contre devant mon écran led de portable qui a à peu près 4 ans j'ai les yeux
> un peu irrités même après seulement deux ou trois heures d'utilisation.
> Pourtant je baisse la luminosité mais cela ne change pas grand chose. Il
> faudrait peut être que je fasse mesurer la lumière provenant de cet écran
> led pour savoir s'il n'a pas un problème ???




signature.asc
Description: OpenPGP digital signature

Re: full-upgrade to buster

[JC.EtiembleG]

Le 09/07/2019 à 21:13, fred a écrit :
y a t il ici des persones suceptibles de partager leur expertise sur un 
upgrade depuis debian9 ?


Tu vas sur https://debian-facile.org/forum.php, il y a des mises à jour 
effectuées ;)


--
J-C Etiemble

full-upgrade to buster

[fred]

bonjour la liste,
y a t il ici des persones suceptibles de partager leur expertise sur un 
upgrade depuis debian9 ?

merci!

--
fred,

Re: Répertoire source de Linux

[Étienne Mollier]

Jean Bernon, au 2019-07-09 :
> Je viens de migrer sans problème de Stretch à Buster. Mais
> j'utilise un driver wifi/bluetooth spécial (mt7630e) que je
> dois réinstaller à chaque changement de version Linux. Les
> scripts d'installation ont fonctionné sans problème depuis 5
> ans. Avec Buster le script d'installation du wifi a bien
> fonctionné. En revanche côté bluetooth, le script qui patche
> btusb.c et génére un btusb.ko modifié, bute sur la création
> d'un répertoire source de Linux. Il y a un problème inédit de
> source signé et non signé que je comprends mal. En tout cas le
> script veut désinstaller linux-image-4.19 et installer à la
> place une version non signée. Voir ci-dessous.
>
> Si je réponds OK, j'obtiens un ferme avertissement de ne pas
> continuer...
>
> Qui aurait une suggestion pour en sortir sans tout casser ?

Bonsoir,

Les paquets linux signés et non-signés le sont au sens du « UEFI
Secure Boot », dont le support est apparu en Debian 10.  En
utilisant un paquet non-signé, le boot UEFI Secure Boot ne sera
plus possible.  Étant donné que vous avez migré depuis Debian
Stretch, je suppose que vous n'avez pas activé cette option de
sécurité entre temps.

À mon sens, il n'y a pas de risque majeur de casse.

Bien à vous,
-- 
Étienne Mollier 
   5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D




signature.asc
Description: OpenPGP digital signature

Re: Apache2 augmenter le nombre de connexions simultanées

[Daniel Caillibaud]

Le 09/07/19 à 16h07, JUPIN Alain  a écrit :
> Bonjour,
> 
> J'avoue que je me suis posé la question, mais d'après pas mal de forum,
> si PHP lui-même est safe threadé il semble que ce ne soit pas le cas de
> toutes les librairies dont il dépend. Et on m'avait conseillé pour
> l'usage de PHP de conserver "prefork". L'ancien serveur lui était en
> worker et cela ne semble pas poser de problème (fonctionnellement
> parlant) après j'ai pas testé s'il y avait des fuites entre threads.
> 
> Mais je vais de nouveau réexaminer la question suite à ta remarque ;)

Effectivement, regarde un peu la littérature avant, c'est bien possible que
prefork soit conseillé pour mod_php, mais tu n'auras aucun pb en mpm avec
php-fpm.
En gros php n'est plus dans le binaire apache mais a son propre serveur à
qui les threads apache délèguent le boulot si ça le concerne. 

C'est nettement plus efficace.

J'ai basculé de apache prefork + mod_php vers nginx + php-fpm y'a ~10ans
suite à des mesures sur mon contexte de l'époque
- à faible/moyenne charge apache + mod_php était un peu plus rapide
- sur un hardware donné, nginx + php-fpm pouvaient encaisser 3~4 fois plus
  de clients simultanés (mesuré avec tsung, avec de vraie sessions
  utilisateur et plein d'aléatoire pour ne pas mesurer le cache)
- quand on s'approchait de la limite, la solution apache décrochait très
  vite (répondait mal à tout le monde voire plus à personne) quand nginx
  arrivaient à servir la plupart des connectés (avec pas mal de timeout
  pour les nouveaux arrivants)

Aujourd'hui je crois que apache mpm + php-fpm devrait donner des choses
voisines de nginx + php-fpm (question perfs tout se joue ensuite sur les
réglages, qui se font différemment sur les deux solutions, mais une fois
débranché les .htaccess et autres tueurs de perfs activés par défaut
apache tient la comparaison, dixit le peu de littérature que j'ai survolé).

Et php-fpm a plein d'autres avantages sur mod_php (la sécurité, avec des
droits réglés par pool php, des configs php qui dépendent du contexte,
etc., choses pénibles à faire avant avec suexec par ex).

-- 
Daniel

L'idée d'une armée européenne est vraiment intéressante,
mais pourquoi ne pas aller plus loin en créant une armée
mondiale dont le principal intérêt serait qu'elle n'aurait 
pas d'ennemis.
Philippe Geluck, Le chat

Re: Utiliser la sortie hdmi de mon pc portable ?

[toto]

Bonjour.

Je viens de lire le dernier message et je vais faire des tests.

Merci.



--
Sent from: http://debian.2.n7.nabble.com/debian-user-french-f1152225.html

Re: [autre sujet ][pertinence des préoccupations lumière bleue] : Lumière bleue des moniteurs led ?

[toto]

Rebonjour à tous !.

J'ai bien noté :

F.Lux et Redshift : 
https://wiki.visionduweb.fr/index.php?title=Installer_Configurer_Utiliser_des_logiciels_sur_GNU_Linux#F.lux

Je regarde cela desuite !

Pour info : je pose cette question car lorsque je travaille devant mon écran
tft lcd 19 pouces toute la journée je n'ai aucune  irritation aux yeux par
contre devant mon écran led de portable qui a à peu près 4 ans j'ai les yeux
un peu irrités même après seulement deux ou trois heures d'utilisation.
Pourtant je baisse la luminosité mais cela ne change pas grand chose. Il
faudrait peut être que je fasse mesurer la lumière provenant de cet écran
led pour savoir s'il n'a pas un problème ???

Encore merci pour les infos.



--
Sent from: http://debian.2.n7.nabble.com/debian-user-french-f1152225.html

Re: Apache2 augmenter le nombre de connexions simultanées

[JUPIN Alain]

Bonjour,

J'avoue que je me suis posé la question, mais d'après pas mal de forum,
si PHP lui-même est safe threadé il semble que ce ne soit pas le cas de
toutes les librairies dont il dépend. Et on m'avait conseillé pour
l'usage de PHP de conserver "prefork". L'ancien serveur lui était en
worker et cela ne semble pas poser de problème (fonctionnellement
parlant) après j'ai pas testé s'il y avait des fuites entre threads.

Mais je vais de nouveau réexaminer la question suite à ta remarque ;)
Merci à toi.

Alain JUPIN
Lumières d'Ici ... et d'Ailleurs 

Le 09/07/2019 à 15:59, Daniel Caillibaud a écrit :
> Le 09/07/19 à 11h43, JUPIN Alain  a écrit :
>> PS : Apache utilise le MPM prefork mais çà vous l'aurez sans doute
>> compris ;)
> Juste par curiosité (j'utilise plus d'apache depuis ~10ans), pourquoi
> utiliser le mode prefork ?
>
> À moins d'avoir de la RAM en trop, c'est quand même bcp plus efficace en
> mode worker non ?
>
> Y'a des applis qui supportent pas le multi-threading ?
>

Re: Apache2 augmenter le nombre de connexions simultanées

[Daniel Caillibaud]

Le 09/07/19 à 11h43, JUPIN Alain  a écrit :
> PS : Apache utilise le MPM prefork mais çà vous l'aurez sans doute
> compris ;)

Juste par curiosité (j'utilise plus d'apache depuis ~10ans), pourquoi
utiliser le mode prefork ?

À moins d'avoir de la RAM en trop, c'est quand même bcp plus efficace en
mode worker non ?

Y'a des applis qui supportent pas le multi-threading ?

-- 
Daniel

Le génie consiste à voir ce que tout le monde a vu
et à penser ce que personne n'a pensé.

Re: Apache2 augmenter le nombre de connexions simultanées

[JUPIN Alain]

Bonjour

C'est un Apache 2.4.25, dans la config initiale, j'avais bien
MaxRequestWorkers mais comme cela ne fonctionnait pas, j'ai testé
l'ancienne directive MaxClients.
Par contre, en effet, je n'ai pas indiqué de directive ServerLimits.

Je vais tester cela. Merci

Alain JUPIN
Lumières d'Ici ... et d'Ailleurs 
Le 09/07/2019 à 14:44, Yahoo a écrit :
>
> Bonjour, (desole pour les accents, j ai un soucis d encodage)
>
> peux tu nous dire la version de apache que tu utilise, car la
> directive MaxClient n'est normalement plus utilise depuis la version
> 2.3.13 de apache (mais encore supporte)
>
> Pour apache2 en nmp_prefork, il faut jouer avec la directive
> MaxRequestWorker (ancienement MaxClient, mais encore supporte) qui
> permet de gerer le nombre de connexions traitee simultanement. Elle
> est fixe a 256 maximum par defaut. sinon Il ne faut pas oublier de
> modifier aussi la directive ServerLimit?? pour augmenter a plus de 256
> la directive MaxRequestWorker.
>
> |MaxRequestWorker (MaxClients)| = M??moire vive totale d??di??e au
> serveur /web/ / Taille maximale des processus enfants
>
> Loic
>
> Le 09/07/2019 ?? 11:43, JUPIN Alain a ??crit??:
>> Bonjour,
>>
>> J'ai un serveur ISPConfig 3 qui tourne sous Debian 9 et apparemment,
>> le nombre de process apache reste bloqu?? aux alentours de 150 (dixit
>> Munin).
>> J'ai eu beau tenter de modifier??
>> /etc/apache2/mods-enabled/mpm_prefork.conf qui ressemble ?? c??
>> 
>> ?? StartServers?? ?? ?? ??5
>> ?? MinSpareServers?? ?? ?? 5
>> ?? MaxSpareServers?? ?? ??10
>> ?? MaxClients ?? ?? ?? ?? ??  ?? 500
>> ?? MaxRequestsPerChild 0
>> 
>>
>> Actuellement, je reste bloqu?? ?? 150 connexions simultan??es. Une
>> id??e pour passer ?? 500 ?
>>
>> Qu'ai donc foir??, mal compris ?
>>
>> PS : Apache utilise le MPM prefork mais  vous l'aurez sans doute
>> compris ;)
>>
>> Merci ?? vous
>> -- 
>> Alain JUPIN
>> Lumi??res d'Ici ... et d'Ailleurs 

Re: Debian Buster RC2 : Mise en veille systématique ?

[Christian Quentin]

Je viens de refaire une install complète pour voir si le problème est là
dès l'installation ou s'il apparaît après modification. 

Au premier démarrage après installation, pas de GDM. En me connectant en
mode console, les actions d'arrêt fonctionne ainsi : 

* en root, reboot fonctionne
* en root, shutdown now fonctionne
* en root, halt arrête le PC mais ne l'éteint pas

Pour avoir accès au GDM, j'ai installé le paquet firmware-linux. A
l'issue de cette installation, les messages d'arrêt du PC défilent
pendant quelques secondes puis l'écran s'éteint : 

* en root, reboot ne redémarre pas le PC
* en root, shutdown now arrête le PC mais ne l'éteint pas 
* en root, halt arrête le PC mais ne l'éteint pas

Après un redémarrage forcé, le message "resuming from hibernation"
apparaît maintenant dans la séquence de démarrage. 

J'ai aussi essayé de désinstaller le paquet firmware-linux mais je ne
reviens pas à l'état initial (GDM reste présent et l'arrêt du PC reste
problématique) 

Si cela aide à comprendre ce qui se passe...

Christian

Re: Apache2 augmenter le nombre de connexions simultanées

[Yahoo]

  
  
Bonjour, (desole pour les accents, j ai un soucis d encodage)

peux tu nous dire la version de apache que tu utilise, car la
  directive MaxClient n'est normalement plus utilise depuis la
  version 2.3.13 de apache (mais encore supporte)
  
Pour apache2 en nmp_prefork, il faut jouer avec la directive
  MaxRequestWorker (ancienement MaxClient, mais encore supporte) qui
  permet de gerer le nombre de connexions traitee simultanement.
  Elle est fixe a 256 maximum par defaut. sinon Il ne faut pas
  oublier de modifier aussi la directive ServerLimit?? pour augmenter
  a plus de 256 la directive MaxRequestWorker.
MaxRequestWorker (MaxClients) =
  M??moire vive totale d??di??e au serveur web
  / Taille maximale des processus enfants
Loic

Le 09/07/2019 ?? 11:43, JUPIN Alain a
  ??crit??:


  
  Bonjour,
  
  J'ai un serveur ISPConfig 3 qui tourne sous Debian 9 et
  apparemment, le nombre de process apache reste bloqu?? aux
  alentours de 150 (dixit Munin).
  J'ai eu beau tenter de modifier??
  /etc/apache2/mods-enabled/mpm_prefork.conf qui ressemble ?? c??
  
  ?? StartServers?? ?? ?? ??5
  ?? MinSpareServers?? ?? ?? 5
  ?? MaxSpareServers?? ?? ??10
  ?? MaxClients ?? ?? ?? ?? ??  ?? 500
  ?? MaxRequestsPerChild 0
  
  
  Actuellement, je reste bloqu?? ?? 150 connexions simultan??es. Une
  id??e pour passer ?? 500 ? 
  
  Qu'ai donc foir??, mal compris ?
  
  PS : Apache utilise le MPM prefork mais  vous l'aurez sans doute
  compris ;)
  
  Merci ?? vous
  -- 
Alain JUPIN
Lumi??res
  d'Ici ... et d'Ailleurs

  

Re: Debian Buster RC2 : Mise en veille systématique

[Eric Degenetais]

Le mar. 9 juil. 2019 à 10:46, Christian Quentin
 a écrit :
>
> Le 2019-07-08 13:07, Eric Degenetais a écrit :
>
> Le ven. 5 juil. 2019 10:42, Christian Quentin 
>  a écrit :
>>
>> Le 2019-07-05 06:50, Jean-Michel OLTRA a écrit :
>>
>>
>> Bonjour,
>
> Bonjour
>>
>>
>> Le jeudi 04 juillet 2019, Christian Quentin a écrit...
>>
>>
>> Que je clique sur le bouton Eteindre/Redémarrer ou que je tape halt dans
>> un terminal (ou shutdown now), le résultat est le même : le PC met très
>> longtemps à s'éteindre et finalement se met en veille. J'ai un petit
>> voyant lumineux qui confirme que le PC (un portable HP 15_bw0xx) reste
>> sous tension.
>>
>>
>> Et avec `systemctl poweroff`, ça fait pareil ?
>>
>> Oui. Je viens de faire l'essai. Même comportement.
>
> En fin de compte, ça ressemble à un plantage au shutdown plutôt qu'à une mise 
> en veille systématique, non ?
>
> Cordialement
>
> Éric Dégenètais
>
>
> ... sauf l'indication "resuming from hibernation" au redémarrage mais 
> peut-être ce message est-il trompeur...

J'ai lu récemment des échanges dans le bug tracker Debian (bug
#928736, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928736 )
sur le fait que ce message est en carton. De fait, sur mon desktop qui
n'a aucun problème le message est systématiquement affiché même lors
d'un démarrage à froid normal. En gros c'est un log avec un message
approximatif qui est émis au moment de chercher une image. Le code qui
émet le message ne sait en fait pas si on est en cours de boot normal
ou de sortie d'hibernation.

Cordialement
__
Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org

Re: Apache2 augmenter le nombre de connexions simultanées

[JUPIN Alain]

Désolé pour le doublons il m’avait semblé avoir fait qu'un seul envoi !

Alain JUPIN
Lumières d'Ici ... et d'Ailleurs 
Le 09/07/2019 à 11:43, JUPIN Alain a écrit :
> Bonjour,
>
> J'ai un serveur ISPConfig 3 qui tourne sous Debian 9 et apparemment,
> le nombre de process apache reste bloqué aux alentours de 150 (dixit
> Munin).
> J'ai eu beau tenter de modifier 
> /etc/apache2/mods-enabled/mpm_prefork.conf qui ressemble à cà
> 
>     StartServers             5
>     MinSpareServers          5
>     MaxSpareServers         10
>     MaxClients                500
>     MaxRequestsPerChild   0
> 
>
> Actuellement, je reste bloqué à 150 connexions simultanées. Une idée
> pour passer à 500 ?
>
> Qu'ai donc foiré, mal compris ?
>
> PS : Apache utilise le MPM prefork mais çà vous l'aurez sans doute
> compris ;)
>
> Merci à vous
> -- 
> Alain JUPIN
> Lumières d'Ici ... et d'Ailleurs 

Apache2 augmenter le nombre de connexions simultanées

[JUPIN Alain]

Bonjour,

J'ai un serveur ISPConfig 3 qui tourne sous Debian 9 et apparemment, le
nombre de process apache reste bloqué aux alentours de 150 (dixit Munin).
J'ai eu beau tenter de modifier 
/etc/apache2/mods-enabled/mpm_prefork.conf qui ressemble à cà

    StartServers             5
    MinSpareServers          5
    MaxSpareServers         10
    MaxClients                500
    MaxRequestsPerChild   0


Actuellement, je reste bloqué à 150 connexions simultanées. Une idée
pour passer à 500 ?

Qu'ai donc foiré, mal compris ?

PS : Apache utilise le MPM prefork mais çà vous l'aurez sans doute
compris ;)

Merci à vous
-- 
Alain JUPIN
Lumières d'Ici ... et d'Ailleurs 

Répertoire source de Linux

[Jean Bernon]

Bonjour, 


Je viens de migrer sans problème de Stretch à Buster. Mais j'utilise un driver 
wifi/bluetooth spécial (mt7630e) que je dois réinstaller à chaque changement de 
version Linux. Les scripts d'installation ont fonctionné sans problème depuis 5 
ans. Avec Buster le script d'installation du wifi a bien fonctionné. En 
revanche côté bluetooth, le script qui patche btusb.c et génére un btusb.ko 
modifié, bute sur la création d'un répertoire source de Linux. Il y a un 
problème inédit de source signé et non signé que je comprends mal. En tout cas 
le script veut désinstaller linux-image-4.19 et installer à la place une 
version non signée. Voir ci-dessous. 
Si je réponds OK, j'obtiens un ferme avertissement de ne pas continuer... 
Qui aurait une suggestion pour en sortir sans tout casser ? 
Merci 
Jean 



*** Downloading kernel source... Lecture des listes de paquets... Fait 
Choix de « linux-signed-amd64 » comme paquet source à la place de « 
linux-image-4.19.0-5-amd64 » 
Selected version '4.19.37+5' (stable) for linux-signed-amd64 
Note : la maintenance du paquet de « linux-signed-amd64 » est réalisée dans le 
système de suivi de versions « Git » à l'adresse : 
https://salsa.debian.org/kernel-team/linux.git 
Veuillez utiliser la commande : 
git clone https://salsa.debian.org/kernel-team/linux.git 
pour récupérer les dernières mises à jour (éventuellement non encore publiées) 
du paquet. 
Nécessité de prendre 2 424 ko dans les sources. 
Réception de :1 http://ftp.fr.debian.org/debian stable/main linux-signed-amd64 
4.19.37+5 (dsc) [7 809 B] 
Réception de :2 http://ftp.fr.debian.org/debian stable/main linux-signed-amd64 
4.19.37+5 (tar) [2 416 kB] 
2 424 ko réceptionnés en 6s (401 ko/s) 
dpkg-source: info: extraction de linux-signed-amd64 dans 
linux-signed-amd64-4.19.37+5 
dpkg-source: info: extraction de linux-signed-amd64_4.19.37+5.tar.xz 
W: Le téléchargement est effectué en dehors du bac à sable en tant que « root » 
car le fichier « linux-signed-amd64_4.19.37+5.dsc » n'est pas accessible par 
l'utilisateur « _apt ». - pkgAcquire::Run (13: Permission non accordée) 
*** Building kernel dependencies... (may be facultative) 
Lecture des listes de paquets... Fait 
Choix de « linux-signed-amd64 » comme paquet source à la place de « 
linux-image-4.19.0-5-amd64 » 
Lecture des listes de paquets... Fait 
Construction de l'arbre des dépendances 
Lecture des informations d'état... Fait 
Les paquets suivants seront ENLEVÉS : 
linux-image-4.19.0-5-amd64 
Les NOUVEAUX paquets suivants seront installés : 
linux-image-4.19.0-5-amd64-unsigned linux-image-4.19.0-5-cloud-amd64-unsigned 
linux-image-4.19.0-5-rt-amd64-unsigned linux-support-4.19.0-5 
sbsigntool 
0 mis à jour, 5 nouvellement installés, 1 à enlever et 0 non mis à jour. 
Il est nécessaire de prendre 0 o/109 Mo dans les archives. 
Après cette opération, 335 Mo d'espace disque supplémentaires seront utilisés. 
Souhaitez-vous continuer ? [O/n]

Re: Debian Buster RC2 : Mise en veille systématique

[Christian Quentin]

Le 2019-07-08 13:07, Eric Degenetais a écrit :

> Le ven. 5 juil. 2019 10:42, Christian Quentin 
>  a écrit : 
> 
> Le 2019-07-05 06:50, Jean-Michel OLTRA a écrit : 
> 
> Bonjour,

Bonjour  

> Le jeudi 04 juillet 2019, Christian Quentin a écrit...
> 
> Que je clique sur le bouton Eteindre/Redémarrer ou que je tape halt dans
> un terminal (ou shutdown now), le résultat est le même : le PC met très
> longtemps à s'éteindre et finalement se met en veille. J'ai un petit
> voyant lumineux qui confirme que le PC (un portable HP 15_bw0xx) reste
> sous tension. 
> Et avec `systemctl poweroff`, ça fait pareil ?

Oui. Je viens de faire l'essai. Même comportement. 
En fin de compte, ça ressemble à un plantage au shutdown plutôt qu'à une
mise en veille systématique, non ?  

Cordialement  

Éric Dégenètais 

... sauf l'indication "resuming from hibernation" au redémarrage mais
peut-être ce message est-il trompeur...

Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

[Daniel Caillibaud]

Le 08/07/19 à 19h22, G2PC  a écrit :
> SSHFS : Une alerte est manquante sur l'état des droits de clé privée
> 
> Avis aux développeurs de paquets, pour corriger le bogue suivant, ouvert
> sur le Github officiel du paquet SSHFS.
> 
> Je suis probablement mauvais, mais je crée mes clés privées sur le
> serveur, après une première connexion avec un simple mot de passe.
> Une fois cela fait, je copie le contenu de mes clés sur la machine locale.

Pourquoi ne pas les générer directement sur la machine locale ?
C'est bcp plus simple, et les fichiers auront directement les bons droits.

En console, sous le user qui veut générer une paire de clés c'est la
commande `ssh-keygen`


> Pour cela, je suis en mode graphique et je crée deux fichiers sur ma
> machine: id_rsa_private et id_rsa.pub qui ont, par défaut, les droits 664.

C'est de là que vient le pb, la clé privée doit être en 600 (la publique
peut rester en 644)

> Je remarque le message d'alerte suivant, avec SSH, lorsque je souhaite
> me connecter avec mon utilisateur local simple, à l'aide de la clé privée:
> 
> ssh USER@SERVEUR -i /home/USERLOCAL/.ssh/SERVEUR/id_rsa_private
> 
> @
> WARNING: UNPROTECTED PRIVATE KEY FILE!
> @
> Permissions 0664 for '/home/USERLOCAL/.ssh/SERVEUR/id_rsa_private' are
> too open.
> It is required that your private key files are NOT accessible by others.
> This private key will be ignored.
> 
> On note ici la traduction de l'anglais vers le français : This private
> key will be ignored. -> La clé privée est ignorée !
> 
> Avec ça, je comprends mieux!
> J'ai identifié ce qui ressemble à un bogue, ou plutôt à un manque de
> précision, sur SSHFS, mais, cela me semble important.

C'est pas un bug mais une fonctionnalité, une clé privée que tout le monde
peut lire n'est pas privée et ne sert à rien, elle est donc logiquement
ignorée par ssh.

> sshfs -o allow_other,
> IdentityFile=/home/$USERLOCAL/.ssh/$SERVEUR/id_rsa_private
> $USERSERVEUR@$SERVEUR:/home/$USERSERVEUR/$FOLDER /home/$USERLOCAL/$FOLDER

> Si l'utilisateur qui se connecte est l'utilisateur root de la machine
> locale, la phrase secrète est requise lors du montage de dossiers
> partagés.

Tu es sûr que c'est la phrase secrète de la clé privée qui est demandée, et
qu'elle est ensuite utilisée ? Ça m'étonne, ça voudrait dire que ssh
tolèrerait une clé privée en 644 si c'est root qui l'utilise, ça ce serait
un bug (de ssh), j'en doute un peu, je pense qu'il demande aussi le pass
de $USERSERVEUR@$SERVEUR si c'est root qui lance la commande (et que la
clé privée est en 644, et que $SERVEUR accepte les connexions par mot de
passe, ce qui est par ailleurs une mauvaise idée).

> Si l'utilisateur qui se connecte est un simple utilisateur de la machine
> locale, le mot de passe de l'utilisateur sur le SERVEUR est demandé lors
> du montage des dossiers partagés.

Ça peut se comprendre, la clé privée est ignorée donc sshfs fait comme si
tu n'en avais pas précisé.

> Attention ! Ce n'est pas le comportement normal! Si la clé privée qui
> est copiée localement a les droits, 600, c'est la phrase secrète qui
> sera demandée. C'est ce que nous voulons !
> 
> 
> Donc, ici, SSHFS ne nous informe pas de la présence de la clé, qui
> possède de mauvais droits, tout comme le fait SSH, lors d’une connexion
> en tant que simple utilisateur local.
> Pourtant, le comportement semble identique ! SSHFS va ignorer la clé
> privée ! OUTCH :/
> 
> Je pense vraiment que SSHFS devrait être capable de mettre en garde sur
> le problème des droits appliqués à la clé privée, de la même manière que
> le fait déjà SSH.
> 
> https://github.com/libfuse/sshfs/issues/180

Je comprends ton point de vue, à partir du moment où tu lui précises une clé
à utiliser il devrait le faire ou s'arrêter avec le bon message d'erreur,
mais c'est visiblement pas l'option choisie par les développeurs de sshfs
(je sais pas si c'est un choix délibéré ou un oubli, tu as bien fait de
poser la question).

-- 
Daniel

Au reste, si l'éducation de la jeunesse est négligée, ne nous en 
prenons qu'à nous-mêmes et au peu de considération que nous 
témoignons à ceux qui s'en chargent.
d'Alembert

[autre sujet ][pertinence des préoccupations lumière bleue] : Lumière bleue des moniteurs led ?

[Eric Degenetais]

Bonjour,
j'avais bien compris l'explication avancée, merci. Elle ne me convainc pas.
Encore une fois les intensités lumineuses en jeu sont très différentes.
Quand les habitants des pays nordiques souffrent de dépression liée au
manque de ce signal lumineux on leur prescrit de s'exposer à des lampes de
forte puissance, pas à des écrans à LED. En ce qui concerne l'effet d'une
utilisation nocturne d'écran, l'explication par le fait que l'intérêt de
l'activité en cours fait oublier l'envie de dormir et dépasser la phase
d'endormissement naturelle est plus simple, et de ce fait plus plausible à
mes yeux jusqu'à preuve (scientifique, et indépendante des fabriquants de
filtres) du contraire.

Cordialement

Éric Dégenètais


Le lun. 8 juil. 2019 21:09, Yann Serre  a
écrit :

> Le 08/07/2019 à 18:40, Eric Degenetais a écrit :
> > Personnellement, j'aimerais bien une démonstration autre que le
> > matériel publicitaire des opticiens ATOLL pour leurs lunettes
> > anti-bleu que l'intensité de la lumière bleue en question est
> > suffisante pour tromper le système nerveux. L'intensité lumineuse d'un
> > cran LED est quand même sacrément inférieure à celle du soleil.
> >
> > Cordialement
> > __
> > Éric Dégenètais
>
> Il me semble que lunettes en question filtrent surtout les UV.
> En photo/vidéo ces mêmes filtres UV sont utilisés depuis très longtemps.
> P'tet qu'en plus des UV les lunettes Atol pour écrans mangent un peu sur
> la longueur d'onde du bleu...
> Mais je pense aussi que médicalement parlant, avoir les rétines exposées
> directement à une source d'UV va poser des problèmes sur le long
> terme... Les UV du soleil, on ne les reçoit que par réflexion, pas
> directement sur les rétines. Et je parie que plus les ondes lumineuses
> sont courtes, moins elle sont énergétiques après réflexion sur une
> surface absorbante (cad pas un miroir, la neige, la surface de l'eau,...).
>
> Sinon pour ce qui est du soleil, le bleu, les UV sont diffractés par
> l'atmosphère (la vapeur d'eau entre autres).
> A midi GMT la partie bleue du spectre pénètre et éclaire directement le
> sol. Plus le soir tombe, plus la lumière traverse l'atmosphère de biais,
> plus l'extrémité bleue du spectre va "rebondir" sur l'atmosphère et se
> perdre dans l'espace (...space ...pace ...ace ...ce ...e ...).
> Bref, la partie du soleil qui arrive au niveau du sol est de plus en
> plus dans l'extrémité rouge du spectre. Et depuis nos ancêtres (les
> petits mammifères qui ont survécu aux dinosaures) cette lumière
> rougeoyante réveille des hormones qui préparent au sommeil.
>
> Au dessus de mon bureau, le soir, l'éclairage d'ambiance est généré
> uniquement par 30W de LEDS rouges et une petite ampoule LED très jaune
> (7W @ 2200°K). Cette lumière d'ambiance rouge se mélange à celle des
> écrans. Un peu comme l'ambiance de nuit des navires militaires. Je ne
> sais pas si c'est vraiment efficace de diluer le bleu dans beaucoup de
> rouge, mais c'est ce que j'expérimente depuis quelques années, sans trop
> de fatigue visuelle ni de problèmes d'endormissement ensuite.
>
> Bon avec tout ça, on n'est pas trolldi.
>
> Bonne semaine à tous.
>
> Yann
>
>