Re: Rescue OVH et Debian SID - Mes services sont coupés

2018-11-30 Par sujet Jean-Michel OLTRA


Bonjour,


Le samedi 01 décembre 2018, G2PC a écrit...


> Je tente aussi de redémarrer MariaDB, qui refuse de démarrer.
> Enter current password for root (enter for none):
> ERROR 2002 (HY000): Can't connect to local MySQL server through socket
> '/var/run/mysqld/mysqld.sock' (111 "Connection refused")

Comment as tu fait pour redémarrer MariaDB ?

> Quels sont les services qui auraient pu s'éteindre, et, qui ne seraient
> pas rechargés automatiquement ?

Aucun, je pense.

> Je constate que si je met l'ip du serveur, il y a bien une redirection
> qui se fait vers le nom de domaine par défaut.
> C'est donc que les VHosts sont bien lus, mais, le site ne s'affiche pas.

Essaie la commande dig :
dig www.ton-site.com
Tu verras alors si tu as une résolution de nom.

-- 
jm



Rescue OVH et Debian SID - Mes services sont coupés

2018-11-30 Par sujet G2PC
Bonsoir / Bonjour

Après avoir du passé par le mode rescue de OVH, j'ai réussi a récupérer
la main sur le serveur.
J'ai redémarré Apache2 mais, les sites ne sont pas consultables.

Je note que depuis le panel OVH, dns n'est pas au vert.
On m'a proposé de redémarrer Bind9 sur le salon de discussions de
Développez, mais, la commande ne fonctionne pas.
Je ne suis même pas certain d'avoir Bind, car, je ne l'ai pas installé.

Je tente aussi de redémarrer MariaDB, qui refuse de démarrer.
Enter current password for root (enter for none):
ERROR 2002 (HY000): Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (111 "Connection refused")

Finalement, est ce que j'ai loupé une étape importante, suite à mon
utilisation du mode rescue ?
Quels sont les services qui auraient pu s'éteindre, et, qui ne seraient
pas rechargés automatiquement ?

Je constate que si je met l'ip du serveur, il y a bien une redirection
qui se fait vers le nom de domaine par défaut.
C'est donc que les VHosts sont bien lus, mais, le site ne s'affiche pas.



Nettoyage du spam : novembre 2018

2018-11-30 Par sujet Jean-Pierre Giraud
Bonjour,
Comme nous sommes en décembre, il est désormais possible de
traiter les archives du mois de novembre 2018 des listes francophones.

N'oubliez bien sûr pas d'ajouter votre nom à la liste des relecteurs
pour que nous sachions où nous en sommes.

Détails du processus de nettoyage du spam sur :

https://wiki.debian.org/I18n/FrenchSpamClean



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet hamster
Le 30/11/2018 à 23:45, Pascal Hambourg a écrit :
>> Mais je persiste a trouver un avantage a sync : ca permet de savoir
>> quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce
>> que meme si le cache concerné n'est pas celui sur lequel agit sync,
>> cette commande ne rend pas le prompt tant que l'écriture n'est pas
>> finie, contrairement a dd. A moins que la encore je me trompe ?
>
> Il faut croire. Test effectué à l'instant : la clé continue à
> clignoter pendant plusieurs secondes après que sync a rendu la main.
> Chronométrée avec time, l'exécution de sync dure environ 0,1 s.
>
> Est-ce que tu as au moins fait l'essai ?

Je connaissais meme pas l'existence de la commande time… J'avais trouvé
(a l'oeil hein) que le moment ou la clef arrete de clignoter etait plus
ou moins synchro avec le moment ou sync rend le prompt. Une différence
de quelques secondes d'accord, mais j'ai jamais vu de différences de
plusieurs minutes comme on peut le voir avec dd. Si on écrit un gros
machin et que ca prend longtemps, par exemple une demi-heure, on peut
très bien avoir dd qui se termine au bout d'un quart d'heure puis sync
qui dure encore un quart d'heure avant de rendre la main.

Mais alors j'ai une autre question : comment on sait quand on peut
débrancher la clef si elle n'a pas de petite lumière qui clignotte ?



KDE et agrégation de liens

2018-11-30 Par sujet kaliderus
Bonsoir,
J'ai lu un peu de doc/tutoriels sur comment agréger 2 interfaces, et
je pense avoir pigé le principe de la configuration à la main (sans
avoir testé) dans /etc/network/interfaces , chose que j'ai toujours
préféré aux interfaces graphiques.
Sauf que là...je suis sous stretch et KDE et je ne pige pas la logique
dans l'applet "gestionnaire de connexions".
Comment créer une interface de "bounding" et y coller les 2 connexions
déjà existantes, à savoir de l'ethernet et du wifi.
Glouglou et compagnie ne m'aident pas trop, que ce soit en anglais ou
en français :-/.
Si quelqu'un l'a déjà fait et peut m'expliquer je suis preneur.
Merci par avance.



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet Pascal Hambourg

Le 30/11/2018 à 22:28, hamster a écrit :

Le 30/11/2018 à 22:03, Pascal Hambourg a écrit :

En effet, la destination n'est pas un système de fichiers. Par contre la
destination est dans un système de fichiers :


Tu n'as pas l'impression de te contredire dans la même phrase ?


Heu non. Fais donc touch toto, tu obtiendra un fichier qui s'appelle
toto. Applique ma phrase a ce fichier, tu verra qu'elle est valide et ne
contiens pas de contradiction.


Ne pas confondre un fichier spécial de périphérique avec le périphérique 
lui-même ou avec un fichier normal. Quand on crée ou écrit dans un 
fichier normal comme ton toto, on écrit dans le système de fichiers qui 
le contient. Quand on écrit dans un périphérique, on n'écrit pas dans le 
système de fichiers qui contient le fichier spécial de périphérique.



Sous unix tout est fichier.


Tout ou presque (pas les interfaces réseau) est traité comme un fichier, 
mais tout n'est pas fichier.



Ma phrase
s'applique aussi bien a ce fichier "toto" qu'au fichier /dev/sdc.


Je ne vois pas le rapport avec le fait qu'un périphérique bloc n'est pas 
dans un système de fichiers.



OK. Et alors, qu'est-ce que ca change ? Le périphérique n'est pas un
système de fichiers, mais il est bien dans un système de fichiers.


Non, c'est le fichier spécial qui est dans le système de fichiers. Pas 
le périphérique. Un périphérique bloc est défini par ses nombres majeur 
et mineur. Un fichier spécial de périphérique est juste un descripteur 
qui contient ces deux numéros, visibles avec ls -l :


$ ls -l /dev/sdb
brw-rw 1 root disk 8, 16 nov.  30 23:36 /dev/sdb

majeur=8, mineur=16

Si je crée un autre fichier spécial de périphérique bloc contenant les 
mêmes nombres avec mknod, c'est un fichier différent (inodes différents, 
rien à voir les liens durs qui pointent vers un même inode) mais le même 
périphérique.



On peut s'amuser a faire rien que la commande dd. Ca travaille un
moment, puis ca rend le prompt. A ce moment la, on fait a la main la
commande sync, et on voit que de nouveau ca travaille un moment. C'est
le signe qu'il restait des choses a écrire sur la clef dans le cache.


Effectivement ce serait le signe si ça se passait ainsi, mais
justement je ne l'ai jamais constaté avec mes clés USB qui ont toutes
un voyant d'activité. Quand ça s'est arrêté de clignoter et j'exécute
sync, ça ne clignote pas plus.

Par contre l'écriture n'est pas forcément finie lorsque dd rend la
main. On le voit bien avec le clignotement qui continue. Il y a donc
un cache quelque part, mais distinct de celui sur lequel sync agit.


OK, tu connais mieux que moi les subtilités du fonctionnement d'unix.


Pas besoin de connaître les subtilités. Il me suffit d'observer mon 
système et ce que je constate ne colle pas avec ce que tu écris.



Mais je persiste a trouver un avantage a sync : ca permet de savoir
quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce
que meme si le cache concerné n'est pas celui sur lequel agit sync,
cette commande ne rend pas le prompt tant que l'écriture n'est pas
finie, contrairement a dd. A moins que la encore je me trompe ?


Il faut croire. Test effectué à l'instant : la clé continue à clignoter 
pendant plusieurs secondes après que sync a rendu la main. Chronométrée 
avec time, l'exécution de sync dure environ 0,1 s.


Est-ce que tu as au moins fait l'essai ?



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet hamster
Le 30/11/2018 à 22:03, Pascal Hambourg a écrit :
>> En effet, la destination n'est pas un système de fichiers. Par contre la
>> destination est dans un système de fichiers :
>
> Tu n'as pas l'impression de te contredire dans la même phrase ?

Heu non. Fais donc touch toto, tu obtiendra un fichier qui s'appelle
toto. Applique ma phrase a ce fichier, tu verra qu'elle est valide et ne
contiens pas de contradiction. Sous unix tout est fichier. Ma phrase
s'applique aussi bien a ce fichier "toto" qu'au fichier /dev/sdc.

>
>> le système fichier racine.
>
> Raté. /dev est un système de fichiers temporaire en mémoire distinct
> de la racine.
>
> $ df -hT /dev
> Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
> udev devtmpfs    10M   0   10M   0% /dev

OK. Et alors, qu'est-ce que ca change ? Le périphérique n'est pas un
système de fichiers, mais il est bien dans un système de fichiers.

>> La destination, c'est un fichier, le fichier /dev/sdc dans ce cas.
>
> Non. /dev/sdc est un fichier spécial qui représente un périphérique
> bloc, mais n'est pas le périphérique bloc. Quand on écrit dans
> /dev/sdc, on écrit sur le disque qu'il représente, pas dans le système
> de fichiers qui contient /dev. Facile à démontrer en remontant /dev en
> lecture seule par exemple : on peut encore écrire dans /dev/sdc.
>
>> Quand
>> on écrit dans ce fichier, les données sont mises dans le cache du
>> système de fichiers racine et sync permet de vider ce cache.
>
> Non puisqu'on n'écrit pas dans un système de fichiers.
>
>> On peut s'amuser a faire rien que la commande dd. Ca travaille un
>> moment, puis ca rend le prompt. A ce moment la, on fait a la main la
>> commande sync, et on voit que de nouveau ca travaille un moment. C'est
>> le signe qu'il restait des choses a écrire sur la clef dans le cache.
>
> Effectivement ce serait le signe si ça se passait ainsi, mais
> justement je ne l'ai jamais constaté avec mes clés USB qui ont toutes
> un voyant d'activité. Quand ça s'est arrêté de clignoter et j'exécute
> sync, ça ne clignote pas plus.
>
> Par contre l'écriture n'est pas forcément finie lorsque dd rend la
> main. On le voit bien avec le clignotement qui continue. Il y a donc
> un cache quelque part, mais distinct de celui sur lequel sync agit.

OK, tu connais mieux que moi les subtilités du fonctionnement d'unix.
Mais je persiste a trouver un avantage a sync : ca permet de savoir
quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce
que meme si le cache concerné n'est pas celui sur lequel agit sync,
cette commande ne rend pas le prompt tant que l'écriture n'est pas
finie, contrairement a dd. A moins que la encore je me trompe ?



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet Pascal Hambourg

Le 30/11/2018 à 08:13, hamster a écrit :

Le 30/11/2018 à 07:42, Pascal Hambourg a écrit :

Le 30/11/2018 à 04:26, hamster a écrit :

Le 29/11/2018 à 23:06, Alban Gruin a écrit :


   # dd if=debian-9.6.0-amd64-i386-netinst.iso of=/dev/sdc bs=4M


C'est une bonne méthode, mais il faut faire sync après :


Inutile, sync est sans effet car la destination n'est pas un système
de fichiers.


En effet, la destination n'est pas un système de fichiers. Par contre la
destination est dans un système de fichiers :


Tu n'as pas l'impression de te contredire dans la même phrase ?


le système fichier racine.


Raté. /dev est un système de fichiers temporaire en mémoire distinct de 
la racine.


$ df -hT /dev
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
udev devtmpfs10M   0   10M   0% /dev


La destination, c'est un fichier, le fichier /dev/sdc dans ce cas.


Non. /dev/sdc est un fichier spécial qui représente un périphérique 
bloc, mais n'est pas le périphérique bloc. Quand on écrit dans /dev/sdc, 
on écrit sur le disque qu'il représente, pas dans le système de fichiers 
qui contient /dev. Facile à démontrer en remontant /dev en lecture seule 
par exemple : on peut encore écrire dans /dev/sdc.



Quand
on écrit dans ce fichier, les données sont mises dans le cache du
système de fichiers racine et sync permet de vider ce cache.


Non puisqu'on n'écrit pas dans un système de fichiers.


On peut s'amuser a faire rien que la commande dd. Ca travaille un
moment, puis ca rend le prompt. A ce moment la, on fait a la main la
commande sync, et on voit que de nouveau ca travaille un moment. C'est
le signe qu'il restait des choses a écrire sur la clef dans le cache.


Effectivement ce serait le signe si ça se passait ainsi, mais justement 
je ne l'ai jamais constaté avec mes clés USB qui ont toutes un voyant 
d'activité. Quand ça s'est arrêté de clignoter et j'exécute sync, ça ne 
clignote pas plus.


Par contre l'écriture n'est pas forcément finie lorsque dd rend la main. 
On le voit bien avec le clignotement qui continue. Il y a donc un cache 
quelque part, mais distinct de celui sur lequel sync agit.



Ca
se voit en particulier très bien avec une clef bas de gamme, c'est a
dire avec une vitesse d'écriture lente.


Mes clés USB plafonnent à 5 Mo/s en écriture. C'est assez lent ?



Re: auth.log toujours vide : résolu

2018-11-30 Par sujet ajh-valmer
On Thursday 29 November 2018 23:26:39 fab wrote:
> Il n'écrit pas dans auth.log.1 par hasard ? :
Non, pas de auth.log.1
> 
> J'ai eu ça il y a quelques temps et il m'a fallu redémarrer rsyslogd.
> Sinon, as-tu essayé de purger et de réinstaller le paquet rsyslog ? il 
> va te remettre une conf de base :

Ça a marché, auth.log se remplit bien maintenant,

comme un seau en bas d'une gouttière pendant un orage :-)

Merci beaucoup et à tous ceux qui m'ont aidé.

A. Valmer



Re: technologie pour brontosaures

2018-11-30 Par sujet Erwan David
On Fri, Nov 30, 2018 at 01:54:37PM CET, Pierre Chevalier 
 said:
> J'ai lu brontosaure, j'ai ouvert.
> 
> Bonjour,
> 
> Le 28/11/2018 à 15:58, Bernard Schoenacker a écrit :
> > bonjour,
> > 
> > je voudrais voir s'il est encore possible de monter
> > une passerelle uucp à l'heure actuelle ?
> > 
> > l'objectif est de pouvoir faire passer du
> > courriel d'un pays ayant des infrastructures
> > réseau faibles vers l'europe ...
> 
> Très intéressant. J'ai régulièrement ces soucis, depuis l'Afrique et 
> aussi depuis les campagnes françaises particulièrement mal connectées.
> 
> Dans mon cas, c'est plus pour du partage de fichiers que des courriels.
> 
> 
> > merci de votre aimable attention
> 
> Merci de soulever cet intéressante chose.
> 
> Je lis le reste du fil de discussion, à bientôt.
> 
> À+
> Pierre

Oui UUCP marche, c'est tout.

-- 
Erwan



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet Bernard Schoenacker



- Mail original -
> De: "Alban Gruin" 
> À: debian-user-french@lists.debian.org
> Envoyé: Vendredi 30 Novembre 2018 14:21:28
> Objet: Re: Installation de Debian par USB, l’ordinateur se fige
> 
> Le 30/11/2018 à 10:07, hamster a écrit :
> 
> Bonne idée, j’essayerai ça se soir.
> 
> Sinon, je suis tombé sur l’image pour clef USB[0], à tenter aussi.
> 
> [0]
> https://www.debian.org/releases/stable/amd64/ch04s03.html.fr#usb-copy-easy


bonjour,

pour copier une clé facilement : etcher

merci
slt
bernard



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet Alban Gruin
Le 30/11/2018 à 10:07, hamster a écrit :
> Le 30/11/2018 à 09:45, Daniel Caillibaud a écrit :
> > Et si tu formates la clé, la laisse vide, l'insère puis démarre, tu
> > accèdes
> > au bios ?
> 
> Ca c'est pas bete. Tu peux aussi la remettre complètement a zero, meme
> le MBR et la table de partitions, en faisant :
> dd bs=4M if=/dev/zero of=/dev/sdx
> bien sur, il faut adapter /dev/sdx avec la lettre qui correspond a ta clef.
> 
> Pas la peine d'écraser ainsi toute la clef, seul le début est important
> pour tester le démarrage, tu laisse donc tourner quelques secondes puis
> tu arrete avec ctrl-C.

Bonne idée, j’essayerai ça se soir.

Sinon, je suis tombé sur l’image pour clef USB[0], à tenter aussi.

[0] https://www.debian.org/releases/stable/amd64/ch04s03.html.fr#usb-copy-easy






Re: Comment transferer des DB d'un serveur a un autre

2018-11-30 Par sujet Pierre Chevalier

Bonjour,

J'arrive encore plus tard et je rajoute encore du sel ;-D

Le 29/11/2018 à 14:28, Daniel Caillibaud a écrit :

Bonjour,
...
J'arrive un peu tard mais j'ajoute quand même mon grain de sel ;-)
Et avant de démarrer le serveur de destination, vérifier les droits sur les
fichiers (mais si c'est les mêmes users des deux cotés ça doit pas poser de
pb).



Plein d'excellents conseils.
Avec un PostgreSQL, un pg_dumpall fait tout le boulot, ou presque. Trop 
facile.




--
Daniel

Le respect de la démocratie veut que j'ai le dernier mot.
Georges Marchais (1973)


Un grand humoriste. Mais je suis étonné qu'il n'ait pas employé le 
subjonctif; n'aurait-il pas plutôt écrit que "le respect de la 
démocratie veut que j'ai*e* le dernier mot"?


À+
Pierre GrainDeSelDémocrate
--
Pierre Chevalier   Mesté Duran 32100 Condom
  Tél :  09 75 27 45 62  - 06 37 80 33 64
  http://pierremariechevalier.free.fr/
  Logiciels Libres dans le Gers: http://gnusquetaires.org/ <= 404 sur 
un plateau




Re: technologie pour brontosaures

2018-11-30 Par sujet Bernard Schoenacker



- Mail original -
> De: "Pierre Chevalier" 
> À: "Bernard Schoenacker" , "Liste Debian" 
> 
> Envoyé: Vendredi 30 Novembre 2018 13:54:37
> Objet: Re: technologie pour brontosaures
> 
> J'ai lu brontosaure, j'ai ouvert.
> 
> Bonjour,
> 
> Le 28/11/2018 à 15:58, Bernard Schoenacker a écrit :
> 
> Très intéressant. J'ai régulièrement ces soucis, depuis l'Afrique et
> aussi depuis les campagnes françaises particulièrement mal
> connectées.
> 
> Dans mon cas, c'est plus pour du partage de fichiers que des
> courriels.
> 
> 
> Merci de soulever cet intéressante chose.
> 
> Je lis le reste du fil de discussion, à bientôt.
> 
> À+
> Pierre

bonjour,

j'ai fait quelques recherches supplémentaires :

https://serverfault.com/questions/435318/secure-copy-uucp-style#436131
https://www.bortzmeyer.org/uucp-over-ssh.html
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa500/uucico.htm
https://www.airs.com/ian/uucp-doc/uucp_6.html

remarque: 

le tuto de Stéphane Bortzmeyer est pas mal, mais le lien
sur uucpssh est mort et pointe sur un site asiatique de
"babes" 


merci

slt
bernard



Re: Comment transferer des DB d'un serveur a un autre

2018-11-30 Par sujet Pierre Chevalier

Bonjour,

Le 26/11/2018 à 12:59, Hugues MORIN a écrit :
@Bernard: Non je ne peux pas changer de DB et passer sous postgesql. 
Cela me demanderai trop de travail


Ah, il peut aisément se trouver des gens qui feraient ça en un 
tournemain. Et des bénévoles qui feraient ça bien aussi.


Ça dépend beaucoup de ce qu'il y a dans la base mysql, s'il y a des vues 
un peu compliquées et qui ne respectent pas les standards, ça peut être 
délicat. Mais certainement pas infaisable.




D'une manière générale, depuis une dizaine d'années que travaille avec 
PostgreSQL, vu la volumétrie de votre système, vu ce que vous en 
attendez, je pense sincèrement que vous auriez intérêt à envisager de 
passer à PostgreSQL, pour un grand nombre de raisons que je ne saurais 
développer sans passer pour un prêcheur.


Parmi ces raisons (tout de même), la réplication multi-maîtres, des 
solutions d'équilibrage de charge, des stratégies simples à mettre en 
œuvre pour peaufiner les performances, même pour des cas d'usages 
démentiels.

Bref/


Anecdote: voilà la raison pour laquelle j'ai choisi PostgreSQL par 
rapport à MySQL, il y a une dizaine d'années de cela, au fond du Sahara:



06/08/2007 21:55:14
temperature: 51 C
Je teste postgresql et mysql, pour comparer: ya pas photo! Avec les mêmes 
données:
mysql:
mysql> select count(id) from collars where id in (select id from collars 
group by id having count(id)>1) ;
+---+
| count(id) |
+---+
	|   251 | 
	+---+

1 row in set (46.16 sec)

postgresql:
pierre=# \timing
Chronométrage activé.
pierre=# select count(id) from collars where id in (select id from collars 
group by id having count(id)>1) ;
	 count 
	---

   251
(1 ligne)

Temps : 15,906 ms

Ordre de grandeur 1000 fois + rapide. Bon, mon choix est fait!



https://image.slidesharecdn.com/presentationgeolllibrepostgeolfr-160531183107/95/prsentation-geolllibre-postgeol-23-638.jpg?cb=1464722795

À+
Pierre
--
Pierre Chevalier   Mesté Duran 32100 Condom
  Tél :  09 75 27 45 62  - 06 37 80 33 64
  http://pierremariechevalier.free.fr/
  Logiciels Libres dans le Gers: http://gnusquetaires.org/ <= 404 sur 
un plateau




Re: technologie pour brontosaures

2018-11-30 Par sujet Pierre Chevalier

J'ai lu brontosaure, j'ai ouvert.

Bonjour,

Le 28/11/2018 à 15:58, Bernard Schoenacker a écrit :

bonjour,

je voudrais voir s'il est encore possible de monter
une passerelle uucp à l'heure actuelle ?

l'objectif est de pouvoir faire passer du
courriel d'un pays ayant des infrastructures
réseau faibles vers l'europe ...


Très intéressant. J'ai régulièrement ces soucis, depuis l'Afrique et 
aussi depuis les campagnes françaises particulièrement mal connectées.


Dans mon cas, c'est plus pour du partage de fichiers que des courriels.



merci de votre aimable attention


Merci de soulever cet intéressante chose.

Je lis le reste du fil de discussion, à bientôt.

À+
Pierre
--
Pierre Chevalier   Mesté Duran 32100 Condom
  Tél :  09 75 27 45 62  - 06 37 80 33 64
  http://pierremariechevalier.free.fr/
  Logiciels Libres dans le Gers: http://gnusquetaires.org/ <= 404 sur 
un plateau




Re: Sid les dernières mises à jours veulent supprimer Xsane et digikam

2018-11-30 Par sujet Haricophile
Le Fri, 23 Nov 2018 18:14:30 +0100,
MERLIN Philippe  a écrit :

> Bonjour,
> Mon installation est une Debian Sid AMD64 depuis plusieurs jours les
> dernières mises à jours veulent supprimer des logiciels importants comme
> xsane , digikam et hplip , ce qui me fait refuser ces dernières. Es ce que
> vous savez ce qui cause ce problème et si possible dans combien de temps cela
> va être corrigé ? Philippe Merlin

Si on se pose ce genre de question sous SID il vaudrait peut-être mieux penser
à utiliser autre chose.

- Dans les versions de développement, que ce soit SID ou Testing il faut
toujours faire les mises a jour de manière "sure" (safe-upgrade avec aptitude)
et vérifier les problème de dépendances paquet par paquet avant de faire une
mise a jour de manière forcée (full-upgrade avec aptitude). Si SID est beaucoup
plus dynamique que Testing il faut quand même de temps en temps avoir de la
patience.

- De même il faut consulter les listes de bugs.

- Pour compléter, ne pas trop faire confiance aux meta-paquets dans SID. Il
 peut y avoir a supprimer l'attribut "installé automatiquement" sur certains
 paquets (unmarkauto avec aptitude).

Bref, si on n'est pas a l'aise avec la gestion des paquets et de leur
dépendance, avoir SID en version de production n'est pas franchement
recommandé. Ça ne l'est d'ailleurs jamais dans la doc de Debian ;)



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet Damien

Le Fri, Nov 30, 2018 at 12:06:14PM +0100, Eric Degenetais a écrit :

De mémoire, ce n'est pas une bonne idée de faire un dd brut sur un
device monté, donc la paire mount/umount n'est impliquée dans cette
opération.


A bah oui, je suis con ...

Je serais étonné que les écriture soit asynchrone sur un block cela dit.



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet Eric Degenetais
De mémoire, ce n'est pas une bonne idée de faire un dd brut sur un
device monté, donc la paire mount/umount n'est impliquée dans cette
opération.
__
Éric Dégenètais
Henix

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

__
Éric Dégenètais
Henix

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



Le ven. 30 nov. 2018 à 11:59, Damien  a écrit :
>
> Satut
>
> Le Fri, Nov 30, 2018 at 08:13:15AM +0100, hamster a écrit :
>
> >En effet, la destination n'est pas un système de fichiers. Par contre la
> >destination est dans un système de fichiers : le système fichier racine.
> >La destination, c'est un fichier, le fichier /dev/sdc dans ce cas. Quand
> >on écrit dans ce fichier, les données sont mises dans le cache du
> >système de fichiers racine et sync permet de vider ce cache. Si on ne le
> >fait pas, au moment ou on débranche il y a toutes les chances que la fin
> >de ce qu'on voulait écrire soit en fait resté dans le cache.
>
> Dans tous les cas la bonne manière de débrancher un clé est de la
> démonté proprement (unmount ...) ce qui fait que le sync est redondante ;)
>
> - Damien
>



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet Damien

Satut

Le Fri, Nov 30, 2018 at 08:13:15AM +0100, hamster a écrit :


En effet, la destination n'est pas un système de fichiers. Par contre la
destination est dans un système de fichiers : le système fichier racine.
La destination, c'est un fichier, le fichier /dev/sdc dans ce cas. Quand
on écrit dans ce fichier, les données sont mises dans le cache du
système de fichiers racine et sync permet de vider ce cache. Si on ne le
fait pas, au moment ou on débranche il y a toutes les chances que la fin
de ce qu'on voulait écrire soit en fait resté dans le cache.


Dans tous les cas la bonne manière de débrancher un clé est de la
démonté proprement (unmount ...) ce qui fait que le sync est redondante ;)

- Damien



Re: serveur de mail minimal (MTA) : nullmailer (ou exim4)?

2018-11-30 Par sujet Yves Rutschle
On Fri, Nov 30, 2018 at 09:13:33AM +0100, Daniel Caillibaud wrote:
> > À quoi bon s'arracher les cheveux à monter un
> > service de mail sur son serveur dans le seul but qu'il passe la main à un
> > autre qu'il faudrait louer ?
> 
> Le pb de Basile était d'envoyer les mails locaux d'une machine vers
> l'extérieur (que ce soit un serveur mail loué ou que tu administre), et
> c'est très simple à résoudre.

C'est très simple en passant par un smarthost (cf ton autre
mail sur les gentils grands acteurs qui nous font faire du
saut d'obstacle pour accepter nos mails).

Et en général, la "location" est comprise dans le forfait
Internet de ton FAI: la plupart te fournissent "de base" un
smarthost qui fera l'acheminement du courrier pour toi. Pour
Free, la seule limite est 200 mails par jour, si je me
souviens bien.

Y.



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet didier gaumet
OTG, On-the-Go (cf https://fr.wikipedia.org/wiki/USB_On-The-Go),
introduit à partir de la norme USB 2.0 pourrait éventuellement être à
l'origine de tes problèmes.

A une époque j'ai acheté deux clés USB 3.0 OTG pour pouvoir les utiliser
facilement avec mes deux PC sous Debian et mon smartphone Lineage OS.

 Il s'avère qu'en tant que mémoire de masse ça fonctionnait parfaitement
dans tous ces cas.

 Par contre si j'essayais de booter mes PC dessus en y ayant mis une
image d'installation Debian, systématiquement ces deux clés figeaient
l'affichage et plantaient mes deux PC, à un stage plus ou moins avancé:
de mémoire, parfois je n'arrivais même pas à entrer dans le BIOS si je
le souhaitais, parfois j'arrivais à démarrer la procédure d'installation
avant que ça plante (je ne suis pas totalement sûr, ça fait déjà un moment).



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet hamster
Le 30/11/2018 à 09:45, Daniel Caillibaud a écrit :
> Et si tu formates la clé, la laisse vide, l'insère puis démarre, tu
> accèdes
> au bios ?

Ca c'est pas bete. Tu peux aussi la remettre complètement a zero, meme
le MBR et la table de partitions, en faisant :
dd bs=4M if=/dev/zero of=/dev/sdx
bien sur, il faut adapter /dev/sdx avec la lettre qui correspond a ta clef.

Pas la peine d'écraser ainsi toute la clef, seul le début est important
pour tester le démarrage, tu laisse donc tourner quelques secondes puis
tu arrete avec ctrl-C.



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet Daniel Caillibaud
Le 30/11/18 à 09:38, Alban Gruin  a écrit :
> > Si tu peux pas entrer dans le bios ni atteindre le menu de selection du
> > boot, c'est qu'il a pas encore essayé de lancer l'installateur qui est
> > sur la clef. J'aurai donc tendance a suspecter un problème materiel sur
> > la clef. T'a essayé avec une autre clef ?

> Oui, j’ai essayé avec deux clefs (une en USB 2, une autre en 3).

Vraiment bizarre…

Et si tu formates la clé, la laisse vide, l'insère puis démarre, tu accèdes
au bios ?

Sinon, y'a un pb avec le controleur USB, je sais pas si ton bios permet de
sauvegarder sa config (pour retenter la même chose après un reset du bios à
ses valeurs par défaut, et remettre en suite ta conf actuelle).

(à prendre avec un peu de distance, je suis une quiche sur les pb
hardware / bios & co)


-- 
Daniel

Ten years ago, we had Steve Jobs, Johnny Cash and Bob Hope.
Now, we have no job, no cash and no hope.



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet Alban Gruin
Le 30/11/2018 à 09:23, hamster a écrit :
> Le 30/11/2018 à 08:46, Alban Gruin a écrit :
> -%<-
> > Si j’insère la clef avant de démarrer l’ordinateur, il se fige dès qu’il
> > affiche une image – sans même afficher la taille de la mémoire ou la liste
> > des disques connectés.  Je ne peux donc pas entrer le BIOS ou dans le
> > menu de sélection de boot.  Par contre, ça ne pose pas de problèmes avec
> > l’installateur de FreeBSD.
> 
> Si tu peux pas entrer dans le bios ni atteindre le menu de selection du
> boot, c'est qu'il a pas encore essayé de lancer l'installateur qui est
> sur la clef. J'aurai donc tendance a suspecter un problème materiel sur
> la clef. T'a essayé avec une autre clef ?
> 

Oui, j’ai essayé avec deux clefs (une en USB 2, une autre en 3).

> Mais tu me dis que ca marche avec l'installeur de freebsd, est-ce avec
> la meme clef ? Si oui, je sais plus quoi te dire…

J’ai essayé les trois Debian sur les deux clefs, mais pour FreeBSD je me suis 
contenté de la clef USB 2. J’ai aussi essayé sur plusieurs prises différentes.






Re: auth.log toujours vide

2018-11-30 Par sujet Daniel Caillibaud
Le 29/11/18 à 19:31, "ajh-valmer"  a écrit :

> On Thursday 29 November 2018 18:35:00 winnt wrote:
> > Ne serait-ce pas que c'est journalctl qui est actif pour les logs et
> > non rsyslog.
> > Un simple "journalctl" devrait confirmer ou infirmer cette supposition.
> > Winnt  
> 
> "journalctl" m'informe des mails, pas des connexions.
> 
> J'ai besoin des 2...

À priori journald traite tout, et devrait faire suivre à rsyslog mais ne
semble pas le faire dans ton cas.

Pour vérifier que journald récupère bien tes logs avec facility auth, tu
peux essayer

journalctl --since=today SYSLOG_FACILITY=10 |tail

(10 => auth+authpriv, cf https://tools.ietf.org/html/rfc5424#section-6.2.1)

Si tu as bien des entrées de log là-dedans, reste à savoir pourquoi ça
n'arrive pas jusqu'à rsyslog, y'a p'tet l'info dans les logs, essaie 

  journalctl -p 4 --since=today

pour voir tous les warnings (et supérieurs, cf lien ietf ci-dessus) de
tous les services, au cas où y'aurait l'info…

Sinon, purger le paquet rsyslog et le réinstaller règlera peut-être le pb,
mais tu sauras pas ce que c'était…

backup /etc avant et compare avant / après, à priori la conf rsyslog est
dans

/etc/default/rsyslog
/etc/rsyslog.conf
/etc/rsyslog.d/*

et tu devrais avoir un symlink

/etc/systemd/system/syslog.service -> /lib/systemd/system/rsyslog.service

-- 
Daniel

Si Dieu descendait sur la Terre, tous les peuples se mettraient a genoux, 
excepté les français qui diraient : "Ah ! Vous êtes là ! C'est pas trop 
tôt ! On va pouvoir discuter un peu !".
Lord Balfour



Re: Installation de Debian par USB, l’ordinateur se fige

2018-11-30 Par sujet hamster
Le 30/11/2018 à 08:46, Alban Gruin a écrit :
>> Il se fige instantanément quand tu connecte la clef. Ca veut dire qu'il
>> tournait déjà avant que tu connecte la clef ?
>>
>> Il faut mettre la clef quand il est arreté, puis le demarrer avec la
>> clef déjà dedans. Et en général aller faire un tour dans les réglages du
>> BIOS pour lui dire de booter sur la clef.
>>
> Si j’insère la clef avant de démarrer l’ordinateur, il se fige dès qu’il 
> affiche une image – sans même afficher la taille de la mémoire ou la liste 
> des 
> disques connectés.  Je ne peux donc pas entrer le BIOS ou dans le menu de 
> sélection de boot.  Par contre, ça ne pose pas de problèmes avec 
> l’installateur de FreeBSD.

Si tu peux pas entrer dans le bios ni atteindre le menu de selection du
boot, c'est qu'il a pas encore essayé de lancer l'installateur qui est
sur la clef. J'aurai donc tendance a suspecter un problème materiel sur
la clef. T'a essayé avec une autre clef ?

Mais tu me dis que ca marche avec l'installeur de freebsd, est-ce avec
la meme clef ? Si oui, je sais plus quoi te dire…



Re: serveur de mail minimal (MTA) : nullmailer (ou exim4)?

2018-11-30 Par sujet Daniel Caillibaud
Le 30/11/18 à 01:05, "Ph. Gras"  a écrit :
> À quoi bon s'arracher les cheveux à monter un
> service de mail sur son serveur dans le seul but qu'il passe la main à un
> autre qu'il faudrait louer ?

Le pb de Basile était d'envoyer les mails locaux d'une machine vers
l'extérieur (que ce soit un serveur mail loué ou que tu administre), et
c'est très simple à résoudre.

Ce qui est plus compliqué c'est la conf d'un serveur MX, qui va recevoir,
stocker et mettre à disposition les mails d'un domaine, Basile a choisi de
payer qqun qui s'en occupe et je le comprend (même si je continue à
maintenir le mien).

Les 2 pbs sont vraiment distincts (il y a un seul MX pour ton domaine mais
tu peux avoir pleins de serveurs qui lui envoient leurs mails locaux).

-- 
Daniel

C'est facile d'arrêter de fumer, j'arrête 20 fois par jour!
Oscar Wilde



Re: serveur de mail minimal (MTA) : nullmailer (ou exim4)?

2018-11-30 Par sujet Daniel Caillibaud
Le 30/11/18 à 03:11, Basile Starynkevitch  a
écrit :
> (des membres de ma famille ont perdu des méls importants, çàd ne les ont 
> jamais reçus).

Ça c'est pas la faute de roundcube (qui se contente de t'afficher en mode
web des mails qu'il lit dans une boite, via imap ou localement), c'est
probablement le smtp (ou le serveur imap, mais c'est rarement le cas car en
général c'est systématique et on s'en aperçoit vite).

> Il y aussi autre chose: à 60 ans -dans quelques mois-, administrer un 
> service mail ne m'amuse plus (et le mél est devenu plus compliqué 
> qu'avant). 

Tout à fait d'accord, ça devient vraiment pénible d'administrer un serveur
mail qui marche bien, je pense surtout pour la "délivrabilité des mails
sortant", faut régulièrement s'adapter aux lubies des "gros" fournisseurs
de mails qui appliquent de nouvelles règles sorties de leur chapeau,
contourner les pbs posés par ceux qui blacklistent régulièrement une grosse
range d'ip de ton hébergeur parce que ton voisin en ip a spammé, etc.

-- 
Daniel

Tout homme qui fait quelque chose a contre lui ceux qui 
voudraient faire la même chose, ceux qui font précisément 
le contraire et surtout la grande armée de gens d'autant 
plus sévères qu'ils ne font rien du tout.
Jules Clarétie