Re: [POSTFIX] On est trolldi, j'en ai une bien bonne :

[BERTRAND Joel]

Ph. Gras a écrit :

Hello les gens !

Saviez-vous ce que signifie SMTP ?

Simple Mail Transfert Protocol

MDR -D

Ph. Gras


	Ehoh ! Il y a longtemps qu'on est passé à ESMTP.Et sais-tu ce que 
signifie le E ? ;-)


JKB

Re: Performance RAID instable

[BERTRAND Joel]

Pascal Hambourg a écrit :

Le 05/10/2017 à 13:34, BERTRAND Joël a écrit :

 Je pense (mais je n'ai pas regardé, il y a longtemps que je ne
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus
de 32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.


D'après ce que j'ai compris en lisant

l'activation de PAE modifie la structure des tables de pages (avec
notamment un niveau supplémentaire), quelle que soit la quantité de
mémoire physique à adresser. Je ne pense pas que le fait que la totalité
de la mémoire physique soit adressable avec 32 bits y change quelque chose.


	Personnellement, je ne fais pas d'hypothèse sur la complexité de la 
grouille rajoutée par PAE (j'ai des vieux souvenirs des problèmes de 
gestion de la mémoire sur sparc32 entre le 2.0 et le 2.2...). J'ai vu 
des trucs tellement ma fichus dans les noyaux Linux... D'autant que les 
noyaux i686 avec plus de 4Go de mémoire doivent être aujourd'hui 
marginaux. Je ne suis pas sûr qu'il y ait encore un réel effort là-dessus.


Cordialement,

JKB

Re: Performance RAID instable

[BERTRAND Joel]

Frédéric MASSOT a écrit :

Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :

Seb a écrit :


Bonjour Pascal,



Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
: utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?


Ah oui, c'est une bonne idée.

Si j'appelle sur une machine en Debian 9
apt-cache search linux-image
je ne vois pas de noyau 3.16 .

Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de
solution packagée indiquée; d'un autre côté, elle ne mentionne pas non
plus les backports pour avoir, au contraire, un noyau plus récent.

Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)


Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire
ça, cela s'est soldé par un échec.


À cause du bug (865866) de LibreOffice Writer j'utilise un noyau 3.16
i386 sur une Buster avec systemd et udev sans problème. Il y a aucun
problème à changer de noyau.


Bonjour,

	Ça se fait, mais de là à dire sans problème... J'ai dû faire un 
rétrofit de matériel qui avait été installé avec un 4.x (j'ai oublié le 
numéro mineur). Le noyau 3.16 s'installe, boote, mais se baugeait lors 
de l'appel à udev et systemd. Il y a une dépendance forte entre udev, la 
version de la bouse systemd et celle du noyau. Ça peut se passer bien, 
avec juste une ligne de warning ou rien du tout, ça peut aussi mettre le 
système en vrac. On ne peut plus aujourd'hui garder des versions du 
noyau différentes pour se sortir d'un mauvais pas de manière fiable.


	Lorsque tu prends une Debian avec un 4.11 ou 4.12 et que tu veux 
remettre un 3.16, il convient d'installer toutes les dépendances du 
3.16. Et ça peut faire beaucoup de monde puisque de plus en plus 
d'outils tiers dépendent de la saloperie systemd.


	Dans le sens contraire, tu peux _aussi_ avoir des problèmes. Pas plus 
tard qu'hier, j'ai fait un dist-upgrade sur un serveur de test. 
Changement de noyau et, forcément, changement de udev et systemd. 
Impossible à redémarrer sans passer au bouton ! shutdown -r ne faisait 
rien (sauf bouffer 100% d'un CPU durant plus d'une heure). Le noyau 
initial était un 4.11, le nouveau un 4.12 avec la grouille qui venait 
avec lui. Là, ça allait, j'étais à côté de la machine. Mais je sens que 
je vais me déplacer pour mes machines hébergées qui n'ont pas de bandeau 
de prise commandé à distance.


Cordialement,

JKB

Re: [POSTFIX] On est trolldi, j'en ai une bien bonne :

[Marc Chantreux]

On Fri, Oct 06, 2017 at 07:57:35AM +0200, Ph. Gras wrote:
> Saviez-vous ce que signifie SMTP ?
> Simple Mail Transfert Protocol

"la messagerie c'était pire avant" :)

tu sais ce que signifie HTTP ?

vu les multiples détournements, c'est bien risible aussi et 
encore une fois, si on a pas le contexte et le besoin d'origine.

bon troll
marc

Re : mail et reply

[Yann Serre]

Goûté et approuvé !

Le 05/10/2017 à 21:54, Christophe a écrit :


K9 fait le boulot.

[POSTFIX] On est trolldi, j'en ai une bien bonne :

[Ph. Gras]

Hello les gens !

Saviez-vous ce que signifie SMTP ?

Simple Mail Transfert Protocol

MDR -D

Ph. Gras

Re: Re : mail et reply

[Christophe]

Hello,

Le 05/10/2017 à 16:53, Vincent Lefevre a écrit :

chose impossible maintenant
avec le client e-mail de Samsung, qui refuse de terminer la config
tant qu'il n'a pas réussi à se connecter avec succès à un serveur
POP ou IMAP


Sachant que d'autre part le client mail Samsung casse (jusqu'à S5 à coup 
sur) les entêtes "In-Reply-To" ... tu ne perds pas grand chose à t'en 
séparer ...


K9 fait le boulot.

@+
Christophe.

Re: Héritage numérique

[Thierry Bugier Pineau]

Bonjour

Je crois que la question ne porte pas sur (ou exclusivement sur) les choses de 
valeur.

Étant donné qu'il est question d'accès à des données chiffrées je pense qu'il 
peut s'agir des photos de vacances, la passation des comptes utilisateur de 
divers sites et services en ligne (le fichier keepassx).

Quid des oeuvres téléchargées légalement et protégées par DRM ? Quid des 
comptes de réseaux (a)sociaux ? Quid de tous les services web où traine un bout 
de notre vie ?

Je sais que la question est d'actualité à la CNIL depuis quelques années et 
qu'il y a une législation à l'étude. Peut être que ça a abouti à des lois en 
vigueur d'ailleurs.

Je pense que la question est très pertinente car il s'agit de protéger sa vie 
privée au delà de l'accès à l'au delà. Pourquoi un notaire serait plus fiable 
que les GAFAM finalement ? Un notaire est un humain avant tout. L'humain est 
faillible et une profession n'est pas un vaccin.

Les notaires n'ont probablement pas de datacenter hébergeant un tahoe-lafs. 
Enbpassant, jetez un oeil à ce projet c'est intéressant. 

Le 5 octobre 2017 18:30:57 GMT+02:00, Haricophile  a 
écrit :
>Le Thu, 5 Oct 2017 14:57:00 +0200,
>Wallace  a écrit :
>
>> Du coup je viens à vous demander quelle solution vous envisageriez
>> pour palier au souci de la perte d'une partie de la clef? Ou quelle
>> autre mécanisme serait le plus adapté?
>
>D'habitude on utilise un notaire pour ce qui concerne l'héritage...
>
>-- 
>haricoph...@aranha.fr 

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Héritage numérique

[Wallace]

Le 05/10/2017 à 18:30, Haricophile a écrit :
>
> D'habitude on utilise un notaire pour ce qui concerne l'héritage...
>
Le notaire ne débloquera pas rapidement les informations. Un rdv notaire
se fait bien après les funérailles et parfois quelques semaines après
alors que le délai de déclaration de succession de 6 mois est calé sur
la date de mort.

Encore une fois ce n'est pas pour bypasser le notaire et les lois, c'est
pour transmettre rapidement aux proches et à qui de droits certains
accès vitaux de manière rapide des informations qui changent plusieurs
fois par an.

Aussi le notaire peut garder des papiers, des clefs usb je doute déjà et
quand à le déranger une fois par an pour mettre à jour les données
confiées je pense que ça va vite devenir cher. Et il ne va pas se
soucier si la clef usb est toujours en état de marche, changer de
support si la mode de stockage change...





signature.asc
Description: OpenPGP digital signature

Re: Héritage numérique

[Wallace]

L'idée est pas mal. Même si j'ai de bons serveurs à disposition
j'aimerais une solution offline.

Maintenant le contenu que tu mets à disposition n'est pas chiffré et il
reste les risques piratage, vol / incendie / inondation (cas rasberry pi
ou autre à la maison), si serveur loué risque de défaut de paiement 2
jours après le décé car comptes bloqués et les proches ont pris le temps
de gérer les funérailles et pas les accès à récupérer ...

C'est pas mal mais pas au top à mon sens.

Le 05/10/2017 à 15:42, Yann Serre a écrit :
> Hypothèse :
> - cas d'un décès accidentel
> - j'ai un serveur ou un hébergement fiable.
>
> Je transmets aujourd'hui à mes proches (ou partenaires professionnels
> susceptibles de prendre le relais) une URL + un login + un mot de passe.
>
> C'est une page à ouverture différée.
> Le jour de la première connexion, le proche est informé que le contenu
> se déverrouillera dans 3 jours par défaut (ou 1 semaine après mon
> retour de vacances si je pars dans un désert numérique).
>
> Immédiatement, à chaque connexion et si je suis vivant + joignable, je
> reçois une notification que quelqu'un est (trop ?) curieux. Je peux
> annuler l'ouverture différée avant l'expiration du délai.
>
> J'ai mis en place cette solution pour ne pas mettre mes clients en
> incapacité d'accéder à leurs données.
>
> ---
>
> Maintenant le cas "tout le monde doit être présent pour l'ouverture" :
> Le délai d'ouverture différée ne débute que quand tout le monde a
> entré son login / password. On ajoute donc une liste et des pastilles
> vertes / rouges sur la page...
>
>
> Longue vie !
>
> Yann
>




signature.asc
Description: OpenPGP digital signature

Re: Héritage numérique

[Wallace]

Le 05/10/2017 à 16:12, Eric Bernard a écrit :
> Bonjour,
> quelques idées que je jette comme ça :
> 1°) Quel légitimité de ce procédé : es-ce légal et reconnu par la loi
> => pour éviter toute contestation ?
Pour la partie légale je ne sais pas mais disons que c'est un début
d'information. Le notaire dans tous les cas demande si des instructions
même orales avaient été précisées donc un fichier chiffré par une
personne devrait suffire à authentifié.
> 2°) Comment être sûre que ces données ne seront pas altérées =>
> existe-t-il un support numérique fiable à long terme ?
Disons qu'il me revient l'obligation de maintenir et renouveler ces
copies régulièrement
> 3°) Ces données doivent être accessible facilement car elles seront
> modifiées régulièrement donc certainement pas avec un procédé complexe
> comme expliqué et donc falsifiables.
Pas tant que cela de modifications, ce keepass contiendra les mots de
passes master de mes autres keepass disons quelques modifications par an
grand max.
> 4°) Qui dit que la mort ne sera pas dû à un "événement" qui provoquera
> une onde électromagnétique donc les données numérique... bye, bye.
Là le monde aura mieux à faire que de s'occuper de moi :) mais le
warning est important mais à quoi bon faire passer des mots de passe si
tout le numérique est mort derrière.
> 5°) Dans tout les cas, le système est fait pour que les dettes
> (succession, etc...) soient payées et le reste n'est qu'accessoire.
Tout à fait mais ça serait dommage que de priver ma famille de l'accès à
la gestion de mes outils numériques, aux dernières photos du smartphone
ou des derniers documents travaillés qui sont pas encore mis à
disposition ailleurs. Ou tout simplement reprendre le droit admin sur un
NAS ou un compte où ils avaient que des accès utilisateurs. L'admin du
wifi, du firewall, ... plein de petites choses qui serait pas agréable
de devoir formater et réinstaller parce qu'il manque un accès.
>
> Conclusion, un bon vieux testament papier détaillant les biens avec
> les données qui vont bien chez plusieurs proches...
Pour moi c'est en complément.



signature.asc
Description: OpenPGP digital signature

Re: Héritage numérique

[fred]

Le 05/10/2017 à 16:12, Eric Bernard a écrit :

> 5°) Dans tout les cas, le système est fait pour que les dettes
> (succession, etc...) soient payées et le reste n'est qu'accessoire.
> 
Bonjour,

Je ne suis pas 100% d'accord avec cela. On peut décider de refuser
l'héritage d'un proche car le "paquet" contient plus de dettes qu'autre
chose (j'ai eu à faire ce choix pour ne pas me retrouver moi même en
difficulté financière). Donc pas d'obligation à payer les factures si on
décide de ne pas accepter l'héritage.

Par contre, il reste légitime de pouvoir récupérer un certain nombre de
données qui sont potentiellement sur des espaces protégés par mdp
(document numérisés, photos, vidéos, souvenirs divers). Vous devez par
ailleurs avoir connaissance de la situation exacte du défunt avant de
vous prononcer sur l'acceptation ou non d'un héritage. Si l'ensemble des
relevés bancaires et des factures sont uniquement accessibles sur une
machine avec mdp, on ne peut pas se prononcer en toute connaissance de
cause dans certains cas.

Fred

Re: Héritage numérique

[Haricophile]

Le Thu, 5 Oct 2017 14:57:00 +0200,
Wallace  a écrit :

> Du coup je viens à vous demander quelle solution vous envisageriez
> pour palier au souci de la perte d'une partie de la clef? Ou quelle
> autre mécanisme serait le plus adapté?

D'habitude on utilise un notaire pour ce qui concerne l'héritage...

-- 
haricoph...@aranha.fr 

Re: Héritage numérique

[Gabriel Corona]

> Reste plus qu'à trouver des solutions décorrélées d'infrastructures
> tiers.

Dans Debian, il y a plusiseurs paquets qui implémentent ça :

*  ;

* libgfshare-bin (programme gfsplit) ;

et d'autres paquets qui implémentent ça en tant que lib.

Disclaimer : je n'ai jamais utilisé ni l'un ni l'autre.

-- 
Gabriel

Re: De retour à MUTT

[Vincent Lefevre]

On 2017-10-04 16:07:40 +0200, David Martin wrote:
> >> Je voulais savoir si des "muttant" sont dans la place, et quel soft
> >> pour la gestion d'adresse vous utilisez ;-)
> >
> >Je n'en utilise pas. Les alias de Mutt me suffisent jusqu'à présent.
> 
> Tu peux les classer ?

Je ne sais pas ce que tu entends par classer, mais...

> (jamais utiliser les alias) tu t'y retrouves ?

En choisissant le bon nom d'alias, oui. Astuce: si on veut regrouper
des alias sous le même thème, choisir un préfixe commun.

[...]
> ### Boîte Perso 
> 
> mailboxes +spool/INBOX
> folder-hook   =spool/INBOX"set record='=sent-mail-`date +%m-%Y`'"
> mbox-hook =spool/INBOX"=mbox-mail-`date +%m-%Y`"
> 
> mailboxes +spool/Debian-List
> 
>  Debian User
> folder-hook =spool/Debian-List "set nopgp_autosign"
> folder-hook =spool/Debian-List "my_hdr From: Marc Naon 
>  "
> mbox-hook   =spool/Debian-List "=mbox-Debian-List-`date +%m-%Y`"
> 
> 
> Quand j'ecris à la liste ça enregistre bien une copie du mail envoyé dans 
> Debian-List et au bon
> endroit mais pas pour un mails depuis ma inbox
> 
> J'ai testé de commenter le bloc  Boite Perso  et de rajouter 
> simplement 
> set record = +sent ou sent ou "+sent" rien ne s'enregistre

Bizarre.

Voir aussi la config de:

3.36. copy

   Type: quadoption
   Default: yes

   This variable controls whether or not copies of your outgoing messages
   will be saved for later references. Also see [1620]$record,
   [1621]$save_name, [1622]$force_name and "[1623]fcc-hook".

et autres variables qui sont liées à $record.

Tu peux aussi essayer de voir avec strace s'il y a une tentative
d'accès à "sent".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Héritage numérique

[Eric Bernard]

Bonjour,
quelques idées que je jette comme ça :
1°) Quel légitimité de ce procédé : es-ce légal et reconnu par la loi => 
pour éviter toute contestation ?
2°) Comment être sûre que ces données ne seront pas altérées => 
existe-t-il un support numérique fiable à long terme ?
3°) Ces données doivent être accessible facilement car elles seront 
modifiées régulièrement donc certainement pas avec un procédé complexe 
comme expliqué et donc falsifiables.
4°) Qui dit que la mort ne sera pas dû à un "événement" qui provoquera 
une onde électromagnétique donc les données numérique... bye, bye.
5°) Dans tout les cas, le système est fait pour que les dettes 
(succession, etc...) soient payées et le reste n'est qu'accessoire.


Conclusion, un bon vieux testament papier détaillant les biens avec les 
données qui vont bien chez plusieurs proches...




Le 05/10/2017 à 15:42, Yann Serre a écrit :

Hypothèse :
- cas d'un décès accidentel
- j'ai un serveur ou un hébergement fiable.

Je transmets aujourd'hui à mes proches (ou partenaires professionnels 
susceptibles de prendre le relais) une URL + un login + un mot de passe.


C'est une page à ouverture différée.
Le jour de la première connexion, le proche est informé que le contenu 
se déverrouillera dans 3 jours par défaut (ou 1 semaine après mon 
retour de vacances si je pars dans un désert numérique).


Immédiatement, à chaque connexion et si je suis vivant + joignable, je 
reçois une notification que quelqu'un est (trop ?) curieux. Je peux 
annuler l'ouverture différée avant l'expiration du délai.


J'ai mis en place cette solution pour ne pas mettre mes clients en 
incapacité d'accéder à leurs données.


---

Maintenant le cas "tout le monde doit être présent pour l'ouverture" :
Le délai d'ouverture différée ne débute que quand tout le monde a 
entré son login / password. On ajoute donc une liste et des pastilles 
vertes / rouges sur la page...



Longue vie !

Yann

Re: Héritage numérique

[Wallace]

Le 05/10/2017 à 15:15, Gabriel Corona a écrit :
>
> Ce que tu cherches, c'est une solution de partage de secret :
>
> https://fr.wikipedia.org/wiki/Secret_r%C3%A9parti
>
> Par exemple, le partage de clé de Shamir :
>
> https://fr.wikipedia.org/wiki/Partage_de_cl%C3%A9_secr%C3%A8te_de_Shamir
>
> En gros, ça "découpe" un secret en N parties (tu en donnes une par
> personne) mais il suffit de réunir M (<= N) parties différentes pour
> obtenir le secret.
>
> Le valeurs de M et N sont au choix de l'utilisateur et permet un
> compromis entre robustesse (faire en sorte qu'on puisse récupérer le
> secret même si une, deux, trois personnes disparaissent et/ou perdent
> leur partie) et résistance à un complot (faire en sorte que deux ou
> trois personnes ne décident pas de te trahir et de récupérer ton
> secret) : il faut qu'au moins M personnes se mettent d'accord pour
> récupérer le secret.
>
Ca me semble pas mal comme solution.
Reste plus qu'à trouver des solutions décorrélées d'infrastructures tiers.



signature.asc
Description: OpenPGP digital signature

Re: Re : mail et reply (was: phishing en UTF8)

[Vincent Lefevre]

Bonjour,

On 2017-10-04 15:50:59 +0200, Thierry Bugier wrote:
> Le mercredi 04 octobre 2017 à 14:39 +0200, Vincent Lefevre a écrit :
> > Au passage, les clients mail pour Android, c'est une vraie
> > catastrophe.
> > Je n'ai pas réussi à en trouver un que l'on puisse configurer sans
> > avoir à définir un serveur POP ou IMAP qui fonctionne (e.g. juste
> > pour pouvoir envoyer du mail).
> 
> J'utilise K9 mail dispo sir F-Droid. JE croisd qu'il est aussi sur le
> play store (que je n'utilise pas malgré que j'ai gmail ;) )

Merci pour l'info. Effectivement, ça fonctionne. On est obligé de
choisir un serveur pour la réception du mail, même si on n'en a pas,
mais il suffit d'ignorer les erreurs (chose impossible maintenant
avec le client e-mail de Samsung, qui refuse de terminer la config
tant qu'il n'a pas réussi à se connecter avec succès à un serveur
POP ou IMAP).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 15:16, Seb a écrit :


Par contre, concernant le choix du noyau 3.16, pourquoi avoir choisi 
celui de wheezy-backports qui était adapté à l'userland de wheezy 
(déjà ancien et sans systemd) et n'est plus maintenu depuis la 
publication de jessie, plutôt que celui de jessie ?


Quand j'ai installé Jessie sur la machine de bureau, en 2015, je n'ai eu 
aucun problème avec le débit des disques.
Quand j'ai installé Jessie sur la machine à la maison, qui est presque 
un clone de la machine de bureau, en janvier 2017, le problème est 
apparu. À la même date, Jessie sur la machine de bureau, sur laquelle je 
fais des 'upgrade' mais jamais de 'dist-upgrade', fonctionnait sans 
problème.
Je fais donc l'hypothèse que le noyau a été mis à jour (sans changement 
du numéro de version) pendant la durée de vie de Jessie.


Je suis dubitatif sur cette hypothèse car un dist-upgrade n'est 
nécessaire pour mettre à jour le noyau qu'en cas de changement d'ABI, 
précisément parce que le nom des paquets du noyau, qui contient la 
version de l'ABI, change. Or d'après ce que je peux voir il n'y a pas eu 
de changement de la version d'ABI (4) du noyau 3.16 inclus dans Jessie 
depuis la publication initiale de Jessie. Donc un simple upgrade était 
suffisant pour installer toutes les mises à jour du noyau jusqu'à ce jour.

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 14:58, Frédéric MASSOT a écrit :


Il y a plusieurs années avec Lilo sur une machine physique où le mode
PAE ne fonctionnait pas bien, je limitais la mémoire à 3,7 ou 3,6 Go en
passant le paramètre mem= au noyau. La machine avait un problème avec le
PCI Hole.


Ce n'était probablement pas le PAE que ne fonctionnait pas bien mais le 
remapping de la mémoire physique masquée par le PCI hole au delà de la 
barrière de 4 Gio (et qui est donc inaccessible en 32 bits sans PAE).

Re: Héritage numérique

[Yann Serre]

Hypothèse :
- cas d'un décès accidentel
- j'ai un serveur ou un hébergement fiable.

Je transmets aujourd'hui à mes proches (ou partenaires professionnels 
susceptibles de prendre le relais) une URL + un login + un mot de passe.


C'est une page à ouverture différée.
Le jour de la première connexion, le proche est informé que le contenu 
se déverrouillera dans 3 jours par défaut (ou 1 semaine après mon retour 
de vacances si je pars dans un désert numérique).


Immédiatement, à chaque connexion et si je suis vivant + joignable, je 
reçois une notification que quelqu'un est (trop ?) curieux. Je peux 
annuler l'ouverture différée avant l'expiration du délai.


J'ai mis en place cette solution pour ne pas mettre mes clients en 
incapacité d'accéder à leurs données.


---

Maintenant le cas "tout le monde doit être présent pour l'ouverture" :
Le délai d'ouverture différée ne débute que quand tout le monde a entré 
son login / password. On ajoute donc une liste et des pastilles vertes / 
rouges sur la page...



Longue vie !

Yann

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 13:34, BERTRAND Joël a écrit :

Pascal Hambourg a écrit :

Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


 Et en recompilant depuis les sources quitte à recompiler en 32
bits sur un système 64 bits ?


Ou en activant le multi-arch et en installant les bibliothèques 32 bits
nécessaires ?


 Ça coule de source. Mais à force, ledit paquet risque de demander 
des bibliothèques qui ne seront plus sur les versions récentes de debian...


Certes mais si le .deb s'installe sur stretch i386, cela signifie que 
les dépendances nécessaires sont encore disponibles.



 Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau
d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une
complexité accrue.


Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne
désactivera pas PAE. C'est une option en dur dans le noyau. Pour
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre
des fonctionnalités comme le NX/XD bit).


 Je pense (mais je n'ai pas regardé, il y a longtemps que je ne 
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même 
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus de 
32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.


D'après ce que j'ai compris en lisant

l'activation de PAE modifie la structure des tables de pages (avec 
notamment un niveau supplémentaire), quelle que soit la quantité de 
mémoire physique à adresser. Je ne pense pas que le fait que la totalité 
de la mémoire physique soit adressable avec 32 bits y change quelque chose.



Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.


 Ça ne dépend pas des options de compilation et des scripts 
d'édition des liens ? Il me semble qu'il est possible de forcer la 
taille des pointeurs dans ces scripts. Si tu force un adressage 64 bits 
réels, je ne vois pas ce qu'un mécanisme dérivé de PAE pourra bien venir 
faire là-dedans.


Le point commun, c'est l'utilisation de tables de pages avec des entrées 
sur 64 bits.

Re: Performance RAID instable

[Seb]

(Je vois bien la méthode facile et rapide pour descendre à 4 Go: 
enlever l'une des deux barrettes de RAM; comment feriez-vous si vous ne 
pouviez pas toucher au matériel ?)

En passant l'option mem=xxx à la ligne de commande du noyau.


Donc à la main lors du boot. OK.
(Oui bidouiller /etc/default/grub, noté.)

Par contre, concernant le choix du noyau 3.16, pourquoi avoir choisi 
celui de wheezy-backports qui était adapté à l'userland de wheezy (déjà 
ancien et sans systemd) et n'est plus maintenu depuis la publication de 
jessie, plutôt que celui de jessie ?


Quand j'ai installé Jessie sur la machine de bureau, en 2015, je n'ai eu 
aucun problème avec le débit des disques.
Quand j'ai installé Jessie sur la machine à la maison, qui est presque un 
clone de la machine de bureau, en janvier 2017, le problème est apparu. 
À la même date, Jessie sur la machine de bureau, sur laquelle je fais des 
'upgrade' mais jamais de 'dist-upgrade', fonctionnait sans problème.
Je fais donc l'hypothèse que le noyau a été mis à jour (sans changement du 
numéro de version) pendant la durée de vie de Jessie. Je sais que je ne 
veux pas la version du noyau qui était en vigueur dans Jessie juste avant 
la release de Stretch. Je ne sais pas laquelle des deux versions me 
donnerait le paquet linux-image-3.16.0-4-686-pae. Dans le doute, j'ai pris 
la version la plus ancienne que me proposait apt-get: 
linux-image-3.16.0-0.bpo.4-686-pae . Cela dit, s'il ne parle pas à 
systemd, ça va pas booter en Debian 9...



Seb.

Re: Héritage numérique

[Gabriel Corona]

> L'idée serait de mettre à disposition de différents proches
> (familles, amis) un fichier chiffré qui ne pourrait s'ouvrir qu'en
> présence de toutes les personnes en même temps. [...]  Souci avec
> cette méthode, si une personne décède juste avant moi ou avec moi si
> lui même n'a pas remis ces instructions à une autre personne le
> fichier restera à jamais indéchiffrable.

Ce que tu cherches, c'est une solution de partage de secret :

https://fr.wikipedia.org/wiki/Secret_r%C3%A9parti

Par exemple, le partage de clé de Shamir :

https://fr.wikipedia.org/wiki/Partage_de_cl%C3%A9_secr%C3%A8te_de_Shamir

En gros, ça "découpe" un secret en N parties (tu en donnes une par
personne) mais il suffit de réunir M (<= N) parties différentes pour
obtenir le secret.

Le valeurs de M et N sont au choix de l'utilisateur et permet un
compromis entre robustesse (faire en sorte qu'on puisse récupérer le
secret même si une, deux, trois personnes disparaissent et/ou perdent
leur partie) et résistance à un complot (faire en sorte que deux ou
trois personnes ne décident pas de te trahir et de récupérer ton
secret) : il faut qu'au moins M personnes se mettent d'accord pour
récupérer le secret.

-- 
Gabriel

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 14:38, Seb a écrit :


(Je vois bien la méthode facile 
et rapide pour descendre à 4 Go: enlever l'une des deux barrettes de 
RAM; comment feriez-vous si vous ne pouviez pas toucher au matériel ?)


En passant l'option mem=xxx à la ligne de commande du noyau.

Par contre, concernant le choix du noyau 3.16, pourquoi avoir choisi 
celui de wheezy-backports qui était adapté à l'userland de wheezy (déjà 
ancien et sans systemd) et n'est plus maintenu depuis la publication de 
jessie, plutôt que celui de jessie ?

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 14:38, Seb a écrit :
> 
>> * Le problème ne se manifeste pas sur deux autres machines sous
>> Debian 9, qui ont pourtant le noyau 4.9.0-3-686-pae, signe que ce
>> n'est pas toute cette classe de noyaux qui pose problème.
> 
> Pardon, correction: je constate que ces deux machines (qui fonctionnent
> bien, elles) ont 2 Go de RAM. Du coup, l'hypothèse d'une RAM > 4 Go mal
> gérée dans les noyaux récents se trouve confortée.
> 
> Sur ma machine de bureau, je dois hélas régulièrement utiliser InDesign
> dans une VirtualBox: ça rame déjà affreusement, ça m'embêterait de ne
> pas disposer de 8 Go quand j'en ai besoin. Sur la machine à la maison,
> par contre, je pourrai sans problème descendre à 4 Go si le passage au
> noyau 3.16 ne se passe pas comme espéré. (Je vois bien la méthode facile
> et rapide pour descendre à 4 Go: enlever l'une des deux barrettes de
> RAM; comment feriez-vous si vous ne pouviez pas toucher au matériel ?)

Merci de ne pas me mettre en copie des mails je suis abonné à la liste.

Il y a plusieurs années avec Lilo sur une machine physique où le mode
PAE ne fonctionnait pas bien, je limitais la mémoire à 3,7 ou 3,6 Go en
passant le paramètre mem= au noyau. La machine avait un problème avec le
PCI Hole.

Aujourd'hui, tu peux ajouter "mem=3072m" à la ligne
"GRUB_CMDLINE_LINUX_DEFAULT=" du fichier "/etc/default/grub". Il faudra
tester avec plusieurs valeurs du seuil de la mémoire.


-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Héritage numérique

[Wallace]

Bonjour à tous,

Petit sujet pas très glamour mais je me suis sérieusement posé la
question de qu'arrivera t il à mes données / mes ordis si je ne suis
plus là du jour au lendemain. Et la réponse est que beaucoup de données
ou accès seront pratiquement indispensables à mes proches.

Ok y a des super services d'entreprises pour l'héritage numérique mais
j'ai pas confiance, qui me dit que la boite existera dans x années,
faire ouvrir ce tiroir pourrait prendre trop de temps pour les proches :
attente du certificat de décé, reconnaissance d'héritiers, ... trop de
mauvaises raisons.

Aussi j'ai un besoin simple, je chiffre tout, mes disques durs sur mes
OS, mon smartphone, mes NAS, je met des mots de passe complexe aléatoire
sur tout et stocké dans différents keepassx et je n'utilise pas de
stockage dans les GAFAM qui permettent de désigner une personne légataire.

L'idée serait de mettre à disposition de différents proches (familles,
amis) un fichier chiffré qui ne pourrait s'ouvrir qu'en présence de
toutes les personnes en même temps.

Ce fichier contiendra un répertoire avec un README avec petit texte, mes
dernières volontés, là où je stocke différentes données (perso,
entreprise) et un premier keepassx qui contient les premiers mots de
passes utiles pour déverrouiller les suivants et les OS sur lesquels il
se trouve.

J'ai pensé à un chiffrement en coupant la clef en plusieurs parties que
je remet à chaque personne. Ainsi personne ne peut ouvrir le contenu
sans aller voir les autres.

Souci avec cette méthode, si une personne décède juste avant moi ou avec
moi si lui même n'a pas remis ces instructions à une autre personne le
fichier restera à jamais indéchiffrable.

Pareil si je fais des clefs pour chaque personne et que je chiffre
plusieurs fois le fichier, il suffit d'une clef manquante pour tout bloquer.

Par contre j'y vois un avantage certain, les proches seront déjà en
contact rapproché au moment du grand saut et ouvrir le fichier ne sera
l'affaire que de quelques heures pour regrouper physiquement les
personnes autour d'un ordinateur.

Du coup je viens à vous demander quelle solution vous envisageriez pour
palier au souci de la perte d'une partie de la clef? Ou quelle autre
mécanisme serait le plus adapté?

Merci




signature.asc
Description: OpenPGP digital signature

Re: Performance RAID instable

[Seb]

* Le problème ne se manifeste pas sur deux autres machines sous 
Debian 9, qui ont pourtant le noyau 4.9.0-3-686-pae, signe que ce n'est 
pas toute cette classe de noyaux qui pose problème.


Pardon, correction: je constate que ces deux machines (qui fonctionnent 
bien, elles) ont 2 Go de RAM. Du coup, l'hypothèse d'une RAM > 4 Go mal 
gérée dans les noyaux récents se trouve confortée.


Sur ma machine de bureau, je dois hélas régulièrement utiliser InDesign 
dans une VirtualBox: ça rame déjà affreusement, ça m'embêterait de ne pas 
disposer de 8 Go quand j'en ai besoin. Sur la machine à la maison, par 
contre, je pourrai sans problème descendre à 4 Go si le passage au noyau 
3.16 ne se passe pas comme espéré. (Je vois bien la méthode facile et 
rapide pour descendre à 4 Go: enlever l'une des deux barrettes de RAM; 
comment feriez-vous si vous ne pouviez pas toucher au matériel ?)



Seb.

Re: Performance RAID instable

[Seb]

Bonjour,



Tu peux ajouter ces lignes dans le fichier "/etc/apt/sources.list" :
deb ftp://ftp.debian.org/debian/ wheezy-backports main contrib non-free
deb ftp://ftp.fr.debian.org/debian jessie main contrib non-free


Merci ! C'est ce que j'ai fait, Le package que je viens d'installer est
linux-image-3.16.0-0.bpo.4-686-pae
Par contre j'ai fait ça à distance si bien que je ne peux pas sélectionner 
aisément le noyau à utiliser par défaut lors du reboot; je testerai de 
visu ce soir pour valider que le système démarre correctement en 3.16 .



À propos de l'archi:

* Le problème ne se manifeste pas sur deux autres machines sous Debian 9, 
qui ont pourtant le noyau 4.9.0-3-686-pae, signe que ce n'est pas toute 
cette classe de noyaux qui pose problème.


* Avec le noyau initial de la Debian 8 (mais pas avec le noyau qui 
équipait l'ISO en janvier 2017), sur la même machine au bureau je n'avais 
aucun souci (8 Go RAM, noyau -686-pae).



À propos de gqview: oui, théoriquement je pourrais recompiler à partir des 
sources, en gardant des versions figées des bibliothèques, à la manière 
d'un snap. Mais pour l'instant, il suffit que j'accepte la légère pénalité 
de performance d'un noyau -686 par rapport à un noyau -amd pour pouvoir 
utiliser tel quel un ancien .deb; le compromis me va.



Seb.

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :
> Seb a écrit :
>>
>> Bonjour Pascal,
>>
>>
>>> Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
>>> : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
>>
>> Ah oui, c'est une bonne idée.
>>
>> Si j'appelle sur une machine en Debian 9
>>     apt-cache search linux-image
>> je ne vois pas de noyau 3.16 .
>>
>> Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de
>> solution packagée indiquée; d'un autre côté, elle ne mentionne pas non
>> plus les backports pour avoir, au contraire, un noyau plus récent.
>>
>> Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
>> trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
>> page web m'irait amplement.)
> 
> Avec un init systemV, c'est assez trivial. Avec la grouille
> systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire
> ça, cela s'est soldé par un échec.

À cause du bug (865866) de LibreOffice Writer j'utilise un noyau 3.16
i386 sur une Buster avec systemd et udev sans problème. Il y a aucun
problème à changer de noyau.


-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Codec Xvid

[BERTRAND Joël]

Michel a écrit :

Le 05/10/2017 à 11:50, BERTRAND Joël a écrit :

Bonjour à tous,

J'ai un petit problème avec une vidéo encodée avec xvid. Il m'est
impossible de la lire, je ne vois qu'une image me demandant d'installer
le codec xvid. Pas de son, pas d'image.

J'ai pourtant la bibliothèque installée (libxvidcode). J'ai tenté une
conversion par ffmpeg sans succès, je me tape toujours cette image (mais
convertie en mepg4, c'est plus joli).

Je n'ai rien trouvé de probant dans les archives d'internet. Je suppose
qu'ici, certains ont déjà été confrontés au même problème. Comment le
résoudre ?

Bien cordialement,

JKB



Bonjour Joël,

ffmpeg -i te donne quelles infos?


Bonjour,

$ ffmpeg -i mitose.avi
ffmpeg version 3.3.4 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7 (Debian 7.2.0-4)
  configuration: --disable-decoder=amrnb --disable-decoder=libopenjpeg 
--disable-mips32r2 --disable-mips32r6 --disable-mips64r6 
--disable-mipsdsp --disable-mipsdspr2 --disable-mipsfpu --disable-msa 
--disable-libopencv --disable-podpages --disable-stripping 
--enable-avfilter --enable-avresample --enable-gcrypt --enable-gnutls 
--enable-gpl --enable-libass --enable-libbluray --enable-libbs2b 
--enable-libcaca --enable-libcdio --enable-libfdk-aac 
--enable-libfontconfig --enable-libfreetype --enable-libfribidi 
--enable-libgme --enable-libgsm --enable-libilbc --enable-libkvazaar 
--enable-libmp3lame --enable-libopencore-amrnb 
--enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg 
--enable-libopenmpt --enable-libopus --enable-libpulse 
--enable-librubberband --enable-libshine --enable-libsnappy 
--enable-libsoxr --enable-libspeex --enable-libtesseract 
--enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc 
--enable-libvorbis --enable-libvpx --enable-libx265 --enable-libxvid 
--enable-libzvbi --enable-nonfree --enable-opengl --enable-openssl 
--enable-postproc --enable-pthreads --enable-shared --enable-version3 
--enable-libwebp --incdir=/usr/include/x86_64-linux-gnu 
--libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --toolchain=hardened 
--enable-frei0r --enable-chromaprint --enable-libx264 
--enable-libiec61883 --enable-libdc1394 --enable-vaapi --disable-opencl 
--enable-libmfx --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu

  libavutil  55. 58.100 / 55. 58.100
  libavcodec 57. 89.100 / 57. 89.100
  libavformat57. 71.100 / 57. 71.100
  libavdevice57.  6.100 / 57.  6.100
  libavfilter 6. 82.100 /  6. 82.100
  libavresample   3.  5.  0 /  3.  5.  0
  libswscale  4.  6.100 /  4.  6.100
  libswresample   2.  7.100 /  2.  7.100
  libpostproc54.  5.100 / 54.  5.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'mitose.avi':
  Metadata:
major_brand : mp42
minor_version   : 0
compatible_brands: isommp42
creation_time   : 2015-04-27T08:01:01.00Z
artist  :
description :
title   :
  Duration: 01:41:17.50, start: 0.00, bitrate: 1037 kb/s
Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), 
yuv420p(tv), 670x340 [SAR 1:1 DAR 67:34], 27 kb/s, 30 fps, 30 tbr, 30k 
tbn, 60 tbc (default)

Metadata:
  creation_time   : 2015-04-27T08:01:01.00Z
  handler_name: Mainconcept MP4 Video Media Handler
  encoder : AVC Coding
At least one output file must be specified

	Je ne vois rien de bizarre. Le débit me semble correct (même si 
faible), ce n'est pas un film d'action...


Cordialement,

JKB

Re: Codec Xvid

[Michel]

Le 05/10/2017 à 11:50, BERTRAND Joël a écrit :
>   Bonjour à tous,
> 
>   J'ai un petit problème avec une vidéo encodée avec xvid. Il m'est 
> impossible de la lire, je ne vois qu'une image me demandant d'installer 
> le codec xvid. Pas de son, pas d'image.
> 
>   J'ai pourtant la bibliothèque installée (libxvidcode). J'ai tenté une 
> conversion par ffmpeg sans succès, je me tape toujours cette image (mais 
> convertie en mepg4, c'est plus joli).
> 
>   Je n'ai rien trouvé de probant dans les archives d'internet. Je suppose 
> qu'ici, certains ont déjà été confrontés au même problème. Comment le 
> résoudre ?
> 
>   Bien cordialement,
> 
>   JKB
> 

Bonjour Joël,

ffmpeg -i te donne quelles infos?

Re: Performance RAID instable

[BERTRAND Joël]

Pascal Hambourg a écrit :

Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :



Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


 Et en recompilant depuis les sources quitte à recompiler en 32
bits sur un système 64 bits ?


Ou en activant le multi-arch et en installant les bibliothèques 32 bits
nécessaires ?


	Ça coule de source. Mais à force, ledit paquet risque de demander des 
bibliothèques qui ne seront plus sur les versions récentes de debian...



Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement
(VirtualBox).


 Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau
d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une
complexité accrue.


Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne
désactivera pas PAE. C'est une option en dur dans le noyau. Pour
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre
des fonctionnalités comme le NX/XD bit).


	Je pense (mais je n'ai pas regardé, il y a longtemps que je ne 
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même 
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus de 
32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.



Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.


	Ça ne dépend pas des options de compilation et des scripts d'édition 
des liens ? Il me semble qu'il est possible de forcer la taille des 
pointeurs dans ces scripts. Si tu force un adressage 64 bits réels, je 
ne vois pas ce qu'un mécanisme dérivé de PAE pourra bien venir faire 
là-dedans.


Cordialement,

JKB

Re: Codec Xvid

[BERTRAND Joël]

JF Straeten a écrit :


Re,

On Thu, Oct 05, 2017 at 12:55:31PM +0200, BERTRAND Joël wrote:

[...]

Tu as essayé avec plusieurs lecteurs ? mplayer, vlc, xine ?


mplayer KO
mpv KO
vlc KO
gxine KO


Retenter une conversion avec un autre soft ? HandBrake ?

Mais si rien ne sait simplement la lire sur le système, je n'y crois
pas beaucoup...

Regarde peut-être dans la section "Video" de mediainfo  s'il
y a un truc exotique ou qui donnerait une piste ?


Il n'y a rien d'exotique dans la sortie de mediainfo. Je pense que je 
vais trouver une machine Windows pour convertir le fichier (vlc sous 
Windows le lit). J'ai déjà eu ce problème par le passé avec ce codec.


Bien cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :



    Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


 Et en recompilant depuis les sources quitte à recompiler en 32 bits 
sur un système 64 bits ?


Ou en activant le multi-arch et en installant les bibliothèques 32 bits 
nécessaires ?



    Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).


 Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de 
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé 
plus de 4Go de mémoire (périphériques compris) au prix d'une complexité 
accrue.


Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne 
désactivera pas PAE. C'est une option en dur dans le noyau. Pour 
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre 
des fonctionnalités comme le NX/XD bit).
Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un 
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.

Re: Codec Xvid

[JF Straeten]

Re,

On Thu, Oct 05, 2017 at 12:55:31PM +0200, BERTRAND Joël wrote:

[...]
> > Tu as essayé avec plusieurs lecteurs ? mplayer, vlc, xine ?
> 
> mplayer KO
> mpv KO
> vlc KO
> gxine KO

Retenter une conversion avec un autre soft ? HandBrake ?

Mais si rien ne sait simplement la lire sur le système, je n'y crois
pas beaucoup...

Regarde peut-être dans la section "Video" de mediainfo  s'il
y a un truc exotique ou qui donnerait une piste ?

Hih,

-- 

JFS.

Re: Codec Xvid

[BERTRAND Joël]

JF Straeten a écrit :


Hello,

On Thu, Oct 05, 2017 at 11:48:00AM +0200, BERTRAND Joël wrote:

[...]

J'ai un petit problème avec une vidéo encodée avec xvid. Il m'est
impossible de la lire, je ne vois qu'une image me demandant d'installer le
codec xvid. Pas de son, pas d'image.


Tu as essayé avec plusieurs lecteurs ? mplayer, vlc, xine ?


mplayer KO
mpv KO
vlc KO
gxine KO




J'ai pourtant la bibliothèque installée (libxvidcode). J'ai tenté une


Tu es sûr de la lib ? J'ai libxvidcore4 ici sous Strecth...


Je ne suis sûr de rien, moi ;-)

Faute de frappe :
# dpkg-query -l | grep libxvid
ii  libxvidcore4:amd643:1.3.4-dmo1

Cordialement,

JKB

Re: Performance RAID instable

[BERTRAND Joël]

Seb a écrit :


Bonjour,



Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


	Et en recompilant depuis les sources quitte à recompiler en 32 bits sur 
un système 64 bits ?



Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).


	Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de 
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé 
plus de 4Go de mémoire (périphériques compris) au prix d'une complexité 
accrue.



et le chipset (ou le contrôleur disque). C'est un point à ne pas
négliger d'autant que je vois pae dans le nom du noyau.


Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer
quelle serait la bonne commande ?


lspci par exemple.


  Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule.


J'aurais préféré rester en systemV, mais l'option n'est pas proposée
lors de l'installation de Debian et je ne sais pas dans quelle mesure on
peut espérer que Devuan et Debian resteront synchrones.


La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.


Aïe...


Bien cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :

Seb a écrit :


Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)


 Avec un init systemV, c'est assez trivial. Avec la grouille 
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire 
ça, cela s'est soldé par un échec.


Je l'avais fait quand Debian 9 stretch était encore en testing, peu 
avant sa publication en stable. Pas de problème particulier, sauf avec 
le GPU Radeon : en l'absence du firmware pourtant optionnel avec ce 
modèle de GPU, l'initialisation du module radeon semblait ne pas aller à 
son terme (il manquait des messages dans les logs du noyau) et 
l'affichage se coupait. Pourtant le même noyau 3.16 initialisait 
correctement le GPU même sans firmware avec le userland de Debian 8 
jessie. Le dernier message du module radeon dans les logs du noyau 
parlant de "user helper", il se peut fort bien que ce soit effectivement 
une incompatibilité avec la version de systemd/udev de stretch. Aucun 
problème en revanche si le firmware était présent, ni avec le noyau 4.9 
de stretch avec ou sans firmware.

Re: Codec Xvid

[JF Straeten]

Hello,

On Thu, Oct 05, 2017 at 11:48:00AM +0200, BERTRAND Joël wrote:

[...]
>   J'ai un petit problème avec une vidéo encodée avec xvid. Il m'est
> impossible de la lire, je ne vois qu'une image me demandant d'installer le
> codec xvid. Pas de son, pas d'image.

Tu as essayé avec plusieurs lecteurs ? mplayer, vlc, xine ? 


>   J'ai pourtant la bibliothèque installée (libxvidcode). J'ai tenté une

Tu es sûr de la lib ? J'ai libxvidcore4 ici sous Strecth...

Hih,


-- 

JFS.

Codec Xvid

[BERTRAND Joël]

Bonjour à tous,

	J'ai un petit problème avec une vidéo encodée avec xvid. Il m'est 
impossible de la lire, je ne vois qu'une image me demandant d'installer 
le codec xvid. Pas de son, pas d'image.


	J'ai pourtant la bibliothèque installée (libxvidcode). J'ai tenté une 
conversion par ffmpeg sans succès, je me tape toujours cette image (mais 
convertie en mepg4, c'est plus joli).


	Je n'ai rien trouvé de probant dans les archives d'internet. Je suppose 
qu'ici, certains ont déjà été confrontés au même problème. Comment le 
résoudre ?


Bien cordialement,

JKB

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 11:27, Seb a écrit :
> 
> Bonjour,
> 
> 
>> Une remarque en passant : je n'ai pas observé ce genre de chose en
>> amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
> 
> J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
> visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
> effacer des images si je laisse la touche Delete appuyée, ce qui
> m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
> un .deb mais il ne s'installe pas sur un système en 64 bits.)
> 
>> Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
>> installée
> 
> 8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
> 
>> et le chipset (ou le contrôleur disque). C'est un point à ne pas
>> négliger d'autant que je vois pae dans le nom du noyau.
> 
> Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer
> quelle serait la bonne commande ?

Tu peux utiliser lspci ou lshw.



-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[Seb]

Bonjour,


	Une remarque en passant : je n'ai pas observé ce genre de chose en 
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le 
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien 
effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive 
souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb 
mais il ne s'installe pas sur un système en 64 bits.)


	Je ne sais pas si tu as indiqué plus haut la taille de la mémoire 
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).

et le chipset (ou le contrôleur disque). C'est un point à ne pas 
négliger d'autant que je vois pae dans le nom du noyau.


Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer 
quelle serait la bonne commande ?



  Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule.


J'aurais préféré rester en systemV, mais l'option n'est pas proposée lors 
de l'installation de Debian et je ne sais pas dans quelle mesure on peut 
espérer que Devuan et Debian resteront synchrones.



La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.


Aïe...


Seb.

Re: Performance RAID instable

[BERTRAND Joël]

Seb a écrit :


Bonjour Pascal,



Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
: utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?


Ah oui, c'est une bonne idée.

Si j'appelle sur une machine en Debian 9
apt-cache search linux-image
je ne vois pas de noyau 3.16 .

Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de
solution packagée indiquée; d'un autre côté, elle ne mentionne pas non
plus les backports pour avoir, au contraire, un noyau plus récent.

Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)


	Avec un init systemV, c'est assez trivial. Avec la grouille 
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire 
ça, cela s'est soldé par un échec.


JKB

Re: Performance RAID instable

[BERTRAND Joël]

Seb a écrit :


Bonjour,



Pour finir, je sais obtenir un retour a des performances normales en
vidant le cache :
sync ; echo 2 > /proc/sys/vm/drop_caches
et comme toi, j'ai une nouvelle dégradation violente au bout d'un
certain temps.


Il y a quelques jours, j'ai passé la machine à la maison (Debian 9
stable) sur le noyau 4.12.0-0.bpo.1-686-pae (backports). J'ai continué à
mesurer la performance des disques avec cette nouvelle situation. Voici
le résultat:
https://framapic.org/bFa8E3Zz3aJA/3vFMDsmo5LhF.png


Bon...

	Une remarque en passant : je n'ai pas observé ce genre de chose en 
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


	Je ne sais pas si tu as indiqué plus haut la taille de la mémoire 
installée et le chipset (ou le contrôleur disque). C'est un point à ne 
pas négliger d'autant que je vois pae dans le nom du noyau.


Cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 10:40, Pascal Hambourg a écrit :


Sinon, faire comme avec les backports : ajouter les dépôts jessie dans 
sources.list et forcer l'installation du paquet de jessie avec apt-get 
-t jessie...


En fait même pas besoin de forcer puisque le paquet n'existe pas dans 
stretch.

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 10:24, Seb a écrit :
> 
> Bonjour Pascal,
> 
> 
>> Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
>> : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
> 
> Ah oui, c'est une bonne idée.
> 
> Si j'appelle sur une machine en Debian 9
> apt-cache search linux-image
> je ne vois pas de noyau 3.16 .

Les versions 3.16 sont dans les wheezy-backports et chez jessie :

https://packages.debian.org/search?suite=all§ion=all&arch=any&searchon=names&keywords=linux-image-3.16

Tu peux ajouter ces lignes dans le fichier "/etc/apt/sources.list" :

deb ftp://ftp.debian.org/debian/ wheezy-backports main contrib non-free
deb ftp://ftp.fr.debian.org/debian jessie main contrib non-free


Tu peux aussi ajouter l'ensemble des dépôts Wheezy et Jessie :

deb http://ftp.fr.debian.org/debian/ wheezy main contrib non-free
deb http://ftp.fr.debian.org/debian/ wheezy-updates main contrib non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb http://ftp.debian.org/debian/ wheezy-backports main contrib non-free

deb http://ftp.fr.debian.org/debian jessie main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free
deb http://ftp.fr.debian.org/debian jessie-updates main contrib non-free
deb http://ftp.fr.debian.org/debian/ jessie-backports main contrib non-free



-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 10:24, Seb a écrit :


Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait 
: utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?

(...)
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans 
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne 
page web m'irait amplement.)


J'essaierais de récupérer directement le .deb du noyau 3.16 de Jessie 
depuis  
(je suppose que l'architecture est amd64) ou depuis une machine sous 
Jessie avec apt-get download et de l'installer avec dpkg -i sur Stretch. 
Les dépendances devraient être satisfaites.


Sinon, faire comme avec les backports : ajouter les dépôts jessie dans 
sources.list et forcer l'installation du paquet de jessie avec apt-get 
-t jessie...

problème avec opendmarc après reboot

[bernard . schoenacker]

bonjour,

lorsque je redémarre mon serveur opendmarc ne se relance pas ...

comment faire pour pour redémarrer automatiquement ?

apt-cache policy opendmarc
opendmarc:
  Installé : 1.3.2-2
  Candidat : 1.3.2-2
 Table de version :
 *** 1.3.2-2 500
500 http://httpredir.debian.org/debian sid/main amd64 Packages
500 http://httpredir.debian.org/debian buster/main amd64 Packages
500 http://httpredir.debian.org/debian stretch/main amd64 Packages


slt
bernard

Re : Performance RAID instable

[Seb]

Bonjour Thierry,


Idée de troisième solution à faire en parallèle d'un contournement: se 
rapprocher des développeurs du kernel pour signaler qu'il y a 
probablement un bug. Je pense qu'il n'y pas plus vraiment de doute 
l'existence d'un bug. Peut être que eux, justement, pourront proposer un 
contournement fiable en attendant la release du correctif.


C'est faisable. Tu me conseilles de contacter debian-kernel ou lkml ?


Seb.

Re: Performance RAID instable

[Seb]

Bonjour Pascal,


Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : 
utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?


Ah oui, c'est une bonne idée.

Si j'appelle sur une machine en Debian 9
apt-cache search linux-image
je ne vois pas de noyau 3.16 .

Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de 
solution packagée indiquée; d'un autre côté, elle ne mentionne pas non 
plus les backports pour avoir, au contraire, un noyau plus récent.


Y a-t-il une méthode standard Debian qui me permettrait d'installer sans 
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne 
page web m'irait amplement.)


Il y a bien longtemps de cela, dans les années 1990, je compilais mes 
noyaux à la main; ensuite il y a eu trop d'options dans le noyau pour que 
cela reste raisonnable (et puis il fallait aussi s'occuper d'initramfs, 
puis grub a supplanté lilo), bref par commodité je n'ai plus utilisé que 
le noyau pré-packagé depuis une quinzaine d'années. Faute d'expérience 
récente, j'aimerais bien éviter de replonger les mains trop profondément 
dans le système, sans outils Debian dédiés il est presque sûr que 
j'obtiendrais au mieux une machine qui ne boote plus.



Seb.

Re: connectivité DNS secondaire et transfert de zones impossible

[Pascal Hambourg]

Le 05/10/2017 à 06:37, Etilem a écrit :


bonjour,

après avoir fait, il y a un mois environ, une migration de jessie vers
stretch sur deux serveurs DNS,

 - un primaire (dns.etilem.net) et
 - un secondaire (ns1.etilem.net),

je rencontre un problème de connectivité du service DNS secondaire.


Vu d'ici, depuis deux machines connectées à l'internet par deux FAI 
différents, l'adresse IPv6 de ns1.etilem.net est injoignable par ping6, 
traceroute6, requête DNS en UDP et TCP.

Re: Performance RAID instable

[Pascal Hambourg]

Le 04/10/2017 à 21:13, Seb a écrit :


Il me reste donc deux options:

* Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce 
problème.


* Appeler en crontab chaque heure le contournement ponctuel de 
Jean-Bernard.


La deuxième solution est crado, mais je ne connais pas ses vrais 
inconvénients (risques de plantage ?). Les connaissez-vous ?


L'inconvénient, c'est l'effet pour lequel elle a été conçue : le vidage 
du cache des méta-données des systèmes de fichiers, obligeant le noyau à 
relire ces méta-données depuis les disques en cas de besoin. Avec des 
SSD, l'impact négatif doit être moins sensible.



Et entre les deux, que me conseillez-vous ?


Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : 
utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?

Re : Performance RAID instable

[Thierry Bugier]

Bonjour

Le mercredi 04 octobre 2017 à 21:13 +0200, Seb a écrit :
> 
> Il me reste donc deux options:
> 
> * Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas
> ce 
> problème.
> 
> * Appeler en crontab chaque heure le contournement ponctuel de 
> Jean-Bernard.
> 
> La deuxième solution est crado, mais je ne connais pas ses vrais 
> inconvénients (risques de plantage ?). Les connaissez-vous ?
> 
> Et entre les deux, que me conseillez-vous ?
> 
> Une idée pour une troisième option ? (À part bug-fixer le noyau :-)
> 

Idée de troisième solution à faire en parallèle d'un contournement: se
rapprocher des développeurs du kernel pour signaler qu'il y a
probablement un bug. Je pense qu'il n'y pas plus vraiment de doute
l'existence d'un bug. Peut être que eux, justement, pourront proposer
un contournement fiable en attendant la release du correctif.

> 
> Seb.