Re: Re : Backuppc et caractères accentués

[Migrec]

Le 25/03/2019 à 18:13, nicolas.patr...@gmail.com a écrit :

Bonjour,

Je ne sais pas ce que contient ce message quand je clique dessus, Balsa me le 
montre tout blanc.
Je dois y répondre pour voir son contenu.

nicolas patrois : pts noir asocial


Bonjour,

Désolé, il devait être en HTML. Celui-ci devrait être en texte.
Voici l'original :

Directement dans le fichier de configuration /etc/backuppc/machine.pl ?

Est-ce que dans l'interface de configuration, on ne peut pas passer 
outre pour cette histoire d'accent ? J'ai tenté de mettre "utf8" dans 
ClientCharsetLegacy 
 
sans succès.


--
Migrec

Re : Backuppc et caractères accentués

[nicolas . patrois]

Bonjour,

Je ne sais pas ce que contient ce message quand je clique dessus, Balsa me le 
montre tout blanc.
Je dois y répondre pour voir son contenu.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: [Debian 8] - Paquet indisponible

[hamster]

Le 25/03/2019 à 16:59, pierre bourget a écrit :
> Re bonjour,
>
> je vois que plusieurs paquets ne sont plus dispo dans les
> jessie-backports en fait : gpsd notamment.
> C’est définitif ? Si oui pourquoi les avoir retiré ? Sinon, où puis-je
> les trouver svp ?

comme déjà dit : Les paquets de jessie ont récamment été retirés des
dépots. Ils sont maintenant disponibles dans les archives :

https://lists.debian.org/debian-devel-announce/2019/03/msg6.html

les archives, c'est http://archive.debian.org/

Re: Backuppc et caractères accentués

[Migrec]

  
  
Le 25/03/2019 à 09:06, Jacques a écrit :

  Je ne sais plu comment j'en suis arrivé là, mais en pratique et ça tombe en marche dans ma configuration backuppc, je remplace le caractère é par le caractère hexadecimal E9


Directement dans le fichier de configuration
/etc/backuppc/machine.pl ?

Est-ce que dans l'interface de configuration, on ne peut pas passer
outre pour cette histoire d'accent ? J'ai tenté de mettre "utf8"
dans ClientCharsetLegacy
sans succès.

--
Migrec
  

Re: [Debian 8] - Paquet indisponible

[pierre bourget]

Re bonjour,

je vois que plusieurs paquets ne sont plus dispo dans les jessie-backports en 
fait : gpsd notamment.
C’est définitif ? Si oui pourquoi les avoir retiré ? Sinon, où puis-je les 
trouver svp ?

Merci et bonne fin de journée,

Pierre BOURGET
Administrateur systèmes et réseaux

9 rue des Tuiliers - 69003 Lyon




> Le 25 mars 2019 à 12:25, Alban Vidal  a écrit :
> 
> Bonjour Pierre,
> 
> La présente liste de diffusion est à destination de l'équipe française
> de traduction.
> 
> Pour des question plus généralistes sur Debian, merci de bien vouloir
> utiliser l'adresse suivante (que j'ai mis en copie) :
> debian-user-french@lists.debian.org
> 
> Le 25/03/2019 à 11:56, pierre bourget a écrit :
>> Bonjour,
>> 
>> le paquet «  openjdk-8-jre-headless » est indisponible pour debian
>> Jessie, alors qu’il l’était récemment…
>> J’ai une erreur sur cette page
>> : https://packages.debian.org/fr/jessie-backports/openjdk-8-jre-headless
>> 
>> J’oublie quelque chose ? 
>> 
>> Merci pour votre aide, 
>> 
>> Pierre
> 
> Sinon pour quand même répondre à la question :
> Le paquet « openjdk-8-jre-headless » n'existe pas sous Debian Jessie, il
> s'agirait de la version « openjdk-7-jre-headless ».
> 
> Paquets openjdk dans Jessie :
> https://packages.debian.org/search?keywords=openjdk=names=oldstable=all
> 
> Paquets openjdk dans Stretch :
> https://packages.debian.org/search?keywords=openjdk=names=stable=all
> 
> 
> Il n'y a pas d'openjdk dans les dépôts jessie-backports ou
> jessie-backports-sloppy.
> 
> Cordialement,
> 
> Alban
> 
> 

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

[BERTRAND Joël]

Olivier a écrit :
> 
> 
> Le lun. 25 mars 2019 à 12:19, BERTRAND Joël  > a écrit :
> 
> 
> 
>         Pas chez moi :
> 
> 
> @Joel:
> Que donne 'SELECT host, user, password, plugin FROM mysql.user;' sur ta
> machine ?
> Sur la mienne, j'ai bien le plugin unix_socket qu'Alexandre mentionne
> dans son message.

Je vire toujours la socket Unix.

MariaDB [(none)]> select host,user,password,plugin from mysql.user where
user='root';
+---+--+---++
| host  | user | password  | plugin |
+---+--+---++
| localhost | root | *8DD098CAB69587D2A67BE8E8A66010A99DF39A75 ||
| rayleigh  | root | *8DD098CAB69587D2A67BE8E8A66010A99DF39A75 ||
+---+--+---++
2 rows in set (0.000 sec)

Je considère que ce n'est pas un trou de sécurité, mais une faille
délirante. root doit se connecter avec un mot de passe.

JKB

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

[Olivier]

Le lun. 25 mars 2019 à 12:19, BERTRAND Joël  a
écrit :

>
>
> Pas chez moi :
>
>
> @Joel:
Que donne 'SELECT host, user, password, plugin FROM mysql.user;' sur ta
machine ?
Sur la mienne, j'ai bien le plugin unix_socket qu'Alexandre mentionne dans
son message.

@Alexandre:
Merci pour ton lien: il explique bien le nouveau paramétrage.
Le lien [1] le détaille aussi.
Pour l'instant, je conserve ce nouveau fonctionnement en l'état.
Je marque néanmoins ce fil de discussion comme RESOLU car je pense qu'il
pourra être utile à d'autres.

Merci à vous

[1] https://mariadb.com/kb/en/library/authentication-plugin-unix-socket/

Re: [Debian 8] - Paquet indisponible

[hamster]

Le 25/03/2019 à 11:56, pierre bourget a écrit :
>> le paquet «  openjdk-8-jre-headless » est indisponible pour debian
>> Jessie, alors qu’il l’était récemment…

Les paquets de jessie ont récamment été retirés des dépots. Ils sont
maintenant disponibles dans les archives :
https://lists.debian.org/debian-devel-announce/2019/03/msg6.html

Re: [Debian 8] - Paquet indisponible

[Alban Vidal]

Bonjour Pierre,

La présente liste de diffusion est à destination de l'équipe française
de traduction.

Pour des question plus généralistes sur Debian, merci de bien vouloir
utiliser l'adresse suivante (que j'ai mis en copie) :
debian-user-french@lists.debian.org

Le 25/03/2019 à 11:56, pierre bourget a écrit :
> Bonjour,
>
> le paquet «  openjdk-8-jre-headless » est indisponible pour debian
> Jessie, alors qu’il l’était récemment…
> J’ai une erreur sur cette page
> : https://packages.debian.org/fr/jessie-backports/openjdk-8-jre-headless
>
> J’oublie quelque chose ? 
>
> Merci pour votre aide, 
>
> Pierre

Sinon pour quand même répondre à la question :
Le paquet « openjdk-8-jre-headless » n'existe pas sous Debian Jessie, il
s'agirait de la version « openjdk-7-jre-headless ».

Paquets openjdk dans Jessie :
https://packages.debian.org/search?keywords=openjdk=names=oldstable=all

Paquets openjdk dans Stretch :
https://packages.debian.org/search?keywords=openjdk=names=stable=all


Il n'y a pas d'openjdk dans les dépôts jessie-backports ou
jessie-backports-sloppy.

Cordialement,

Alban




signature.asc
Description: OpenPGP digital signature

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ?

[Alexandre Goethals]

Bonjour,

pour la connexion au compte root sans mot de passe (en local), c'est
parce que ce compte utilise le plugin unix socket:

|SELECThost,user,password,plugin FROMmysql.user; devrait donner quelque
chose comme: 
||+---+--+--+-+|host
|user|password |plugin
|+---+--+--+-+|localhost
|root ||unix_socket
|+---+--+--+-+ Donc il
faut faire: ||UPDATEmysql.userSETplugin =''WHEREuser='root'ANDhost 
='localhost';FLUSH
PRIVILEGES; redémarrer mariadb source:
https://stackoverflow.com/questions/7179894/how-to-disable-mysql-root-logins-when-no-password-is-supplied
|

Le 25/03/2019 à 12:19, BERTRAND Joël a écrit :
> Olivier a écrit :
>> Bonjour,
>   Bonjour,
>
>> Je travaille sur une configuration de Freeradius avec une base de
>> données pour Debian Buster.
>>
>> Comme la documentation de Freeradius avec base de données se réfère
>> massivement à MySQL, j'ai installé sur une VM, MySQL/MariaDB avec la
>> commande apt-get install default-mysql-server suivie de
>> mysql_secure_installation.
>>
>> J'ai volontairement installé default-mysql-servercar dans mon cas, je
>> suis indifférent au choix MySQL/MariaDB: je souhaite juste mettre au
>> point une configuration qui fonctionnera quand Buster sera la version
>> stable de Debian.
>>
>> Ce faisant, j'ai été surpris de constater qu'après ces 2 commandes, la
>> méthode d'accès à MySQL/MariaDB avait changé:
>>
>> - l'utilisateur root peut se connecter sans mot de passe ou avec un mot
>> de passe erroné
>   Pas chez moi :
>
> Root rayleigh:[~] > mysql -uroot -p
> Enter password:
> ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
> password: YES)
> Root rayleigh:[~] >
>
>   Naturellement, si je fournis le bon mot de passe, ça fonctionne comme
> attendu.
>
>> - un utilisateur lambda ne peut plus se connecter en tant qu'utilisateur
>> MySQL/MariaDB root même en fournissant le bon mot de passe.
>   Pas chez moi :
>
> rayleigh:[~] > mysql -uroot -p
> Enter password:
> Welcome to the MariaDB monitor.  Commands end with ; or \g.
> Your MariaDB connection id is 10044
> Server version: 10.3.13-MariaDB-1-log Debian buildd-unstable
>
> Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
>
> Type 'help;' or '\h' for help. Type '\c' to clear the current input
> statement.
>
> MariaDB [(none)]> quit
> Bye
> rayleigh:[~] > whoami
> bertrand
>
>   À mon avis, le problème est ailleurs ;-)
>
>   Je commencerais pas jeter un oeil à la configuration de mariadb.
>
>   Bien cordialement,
>
>   JKB
>

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ?

[BERTRAND Joël]

Olivier a écrit :
> Bonjour,

Bonjour,

> Je travaille sur une configuration de Freeradius avec une base de
> données pour Debian Buster.
> 
> Comme la documentation de Freeradius avec base de données se réfère
> massivement à MySQL, j'ai installé sur une VM, MySQL/MariaDB avec la
> commande apt-get install default-mysql-server suivie de
> mysql_secure_installation.
> 
> J'ai volontairement installé default-mysql-servercar dans mon cas, je
> suis indifférent au choix MySQL/MariaDB: je souhaite juste mettre au
> point une configuration qui fonctionnera quand Buster sera la version
> stable de Debian.
> 
> Ce faisant, j'ai été surpris de constater qu'après ces 2 commandes, la
> méthode d'accès à MySQL/MariaDB avait changé:
> 
> - l'utilisateur root peut se connecter sans mot de passe ou avec un mot
> de passe erroné

Pas chez moi :

Root rayleigh:[~] > mysql -uroot -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
password: YES)
Root rayleigh:[~] >

Naturellement, si je fournis le bon mot de passe, ça fonctionne comme
attendu.

> - un utilisateur lambda ne peut plus se connecter en tant qu'utilisateur
> MySQL/MariaDB root même en fournissant le bon mot de passe.

Pas chez moi :

rayleigh:[~] > mysql -uroot -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 10044
Server version: 10.3.13-MariaDB-1-log Debian buildd-unstable

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.

MariaDB [(none)]> quit
Bye
rayleigh:[~] > whoami
bertrand

À mon avis, le problème est ailleurs ;-)

Je commencerais pas jeter un oeil à la configuration de mariadb.

Bien cordialement,

JKB

Conseils sur l'administration de MySQL/MariaDB sur Buster ?

[Olivier]

Bonjour,

Je travaille sur une configuration de Freeradius avec une base de données
pour Debian Buster.

Comme la documentation de Freeradius avec base de données se réfère
massivement à MySQL, j'ai installé sur une VM, MySQL/MariaDB avec la
commande apt-get install default-mysql-server suivie de
mysql_secure_installation.

J'ai volontairement installé default-mysql-servercar dans mon cas, je suis
indifférent au choix MySQL/MariaDB: je souhaite juste mettre au point une
configuration qui fonctionnera quand Buster sera la version stable de
Debian.

Ce faisant, j'ai été surpris de constater qu'après ces 2 commandes, la
méthode d'accès à MySQL/MariaDB avait changé:

- l'utilisateur root peut se connecter sans mot de passe ou avec un mot de
passe erroné
- un utilisateur lambda ne peut plus se connecter en tant qu'utilisateur
MySQL/MariaDB root même en fournissant le bon mot de passe.

J'ai trouvé sur Internet vraiment très peu de doc sur l'administration de
MySQL/MariaDBsous Buster.

Avez-vous des conseils sur ceci dans le cas où on a besoin d'exécuter des
scripts de création-configuration de base de données MySQL ?

Faut-il installer MySQL plutôt que MariaDB ? Le contraire ?
Y-a-t-il une autre commande que mysql_secure_installation à exécuter ?
Peut-on sans état d'âme ignorer cette différence avec les versions de MySQL
sous Jessie ou autre ?
Documentation ?

Slts

Re: installation Debian avec home sur disque dur usb

[hamster]

Le 25/03/2019 à 10:08, Erwann Le Bras a écrit :
> Le 24/03/2019 à 20:29, hamster a écrit :
>> Le 24/03/2019 à 20:14, alex.pad...@laposte.net a écrit :
>>>
>>> Bonsoir à tous,
>>>
>>>
>>> Je souhaiterai faire une installation Debian sur un mini-pc avec un
>>> disque dur SSD, Debian sera installé sur le disque SSD tandis que mon
>>> home devra être installer impérativement sur un disque dur usb externe.
>>>
>>> Je souhaiterai que mon home soit crypté ou chiffré.
>>>
>>> Comment faire tout cela à l'installation du système.
>>>
>> Tout cela est prévu dans l'installeur. Autant le fait de chiffrer que de
>> séparer le /home sur une partition de ton choix.
>>
>
> Tout à fait : faire une install classique avec le disque externe en
> place pour préciser, au moment du partitionnement (choisir
> "personnalisé") la cible et l'état des partitions.

J'ajoute que chiffrer le /home ne suffit pas. Quand tu va utiliser ton
ordi, tu va taper ta phrase de passe pour acceder a tes données. Cette
phrase va etre stockée en mémoire vive. Si a ce moment la tu hiberne, le
contenu de la mémoire vive (avec ta phrase de passe) sera copié dans la
swap. Il faut donc chiffrer aussi la swap. Et tant que t'y est, si tu
chiffre aussi la partition système c'est pas plus mal.

Re: installation Debian avec home sur disque dur usb

[Erwann Le Bras]

Le 24/03/2019 à 20:29, hamster a écrit :

Le 24/03/2019 à 20:14, alex.pad...@laposte.net a écrit :


Bonsoir à tous,


Je souhaiterai faire une installation Debian sur un mini-pc avec un
disque dur SSD, Debian sera installé sur le disque SSD tandis que mon
home devra être installer impérativement sur un disque dur usb externe.

Je souhaiterai que mon home soit crypté ou chiffré.

Comment faire tout cela à l'installation du système.


Tout cela est prévu dans l'installeur. Autant le fait de chiffrer que de
séparer le /home sur une partition de ton choix.



Tout à fait : faire une install classique avec le disque externe en 
place pour préciser, au moment du partitionnement (choisir 
"personnalisé) la cible et l'état des partitions.


Bien réfléchir avant car selon le point de montage et la protection mise 
sur le disque externe, le système pourrait ne pas démarrer sans le 
disque externe ou le disque externe pas pouvoir être lu sur un autre 
système.


Erwann

Re: Backuppc et caractères accentués

[Jacques]

Le 25/03/2019 à 09:06, Jacques a écrit :
> 
> ...> Une des façons de procéder avec vi:
> pour passer en mode edition hexadecimal: :%!xxd (en mode commande)
> pour revenir en mode normal: :%!xxd -r
> 
> N'oublie pas de sauvegarder ton fichier de configuration si jamais le remède 
> est pire que le mal
> 
> Bonne journée
> 

Encore plus simple sous vi, charger le fichier et effectuer la conversion 
utf8/iso-8859-1 par:
:set fileencoding=latin1

Re: Backuppc et caractères accentués

[Jacques]

Le 24/03/2019 à 22:36, Migrec a écrit :
> Bonjour,
> 
> Je rencontre un problème avec l'argument BackupFilesExclude 
> 
>  de backuppc.
> Je ne souhaite pas sauvegarder le répertoire Téléchargements mais il est tout 
> de même inclut dans les sauvegardes. Je soupçonne un problème avec les 
> accents.
> 
> Voici le log de backuppc
> 
> incr backup started back to 2019-03-22 15:00:11 (backup #146) for directory 
> /home
> Running: /usr/bin/ssh -q -x -l root skeleton /usr/bin/rsync --server --sender 
> --numeric-ids --perms --owner --group -D --links --hard-links --times 
> --block-size=2048 --recursive . /home/
> Xfer PIDs are now 26881
> Got remote protocol 31
> Negotiated protocol version 28
> Sent exclude: */.local/share/Trash
> Sent exclude: */tmp
> Sent exclude: */T�l�chargements
> Sent exclude: michel/VirtualBox VMs
> Xfer PIDs are now 26881,26882
> 
> J'ai tenté de rajouter  |--iconv=utf8,iso88591 |mais sans succès.
> 
> Une idée ?
> --
> Migrec
> 
> ||

Bonjour,

Je ne sais plu comment j'en suis arrivé là, mais en pratique et ça tombe en 
marche dans ma configuration backuppc, je remplace le caractère é par le 
caractère hexadecimal E9

Une des façons de procéder avec vi:
pour passer en mode edition hexadecimal: :%!xxd (en mode commande)
pour revenir en mode normal: :%!xxd -r

N'oublie pas de sauvegarder ton fichier de configuration si jamais le remède 
est pire que le mal

Bonne journée

Re: Smokeping et ce de systemd

[Lucas Nussbaum]

On 25/03/19 at 07:24 +0100, BERTRAND Joël wrote:
> Lucas Nussbaum a écrit :
> > 
> > Et quand tu lances smokeping à la main avec /usr/sbin/smokeping
> > --pid-dir=/run/smokeping, où crée-t-il smokeping.pid ?
> > 
> > est-ce que tu peux faire 'systemctl cat smokeping.service' pour vérifier
> > que tu as bien le même contenu que ci-dessus (cad que tu n'as pas
> > d'overrides dans /etc) ?
> 
> Root rayleigh:[/lib/systemd/system] > systemctl cat smokeping.service
> # /lib/systemd/system/smokeping.service
> [Unit]
> Description=Latency Logging and Graphing System
> Documentation=man:smokeping(1)
> file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf
> After=network.target
> 
> [Service]
> # It would in theory be simpler to run smokeping with the --nodaemon
> option and
> # Type=simple, but smokeping does not work properly when in "slave" mode
> with
> # --nodaemon set.
> Type=forking
> RuntimeDirectory=smokeping
> PIDFile=/run/smokeping/smokeping.pid
> User=smokeping
> Group=smokeping
> StandardError=syslog
> 
> # If you need to run smokeping in slave/master mode, see the example unit
> # override in /usr/share/doc/smokeping/examples/systemd/slave_mode.conf
> ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping
> 
> ExecReload=/bin/kill -HUP $MAINPID
> 
> [Install]
> WantedBy=multi-user.target
> Root rayleigh:[/lib/systemd/system] >
> 
>   Ça semble bien être la même chose (petite remarque en passant, le truc
> qui intercepte les scripts SysV me semble lui aussi être une connerie
> sans nom au fonctionnement aléatoire dans le machin systemd, on est bien
> loin du KISS du monde Unix...).
> 
>   Si je lance le daemon à la main :
> Root rayleigh:[/lib/systemd/system] > /usr/sbin/smokeping
> --pid-dir=/run/smokeping
> 
> je récupère un pid dans /run :
> Root rayleigh:[/lib/systemd/system] > ls /run/
> ...
> smokeping.pid
> ...
> 
>   Je pensais naïvement qu'il devait être dans 
> /run/smokeping/smokeping.pid...
> 
>   Même si je crée avant de lancer smokeping un répertoire /run/smokeping,
> je me retrouve avec le pid dans /run/smokeping.pid.

Voila, donc à la fin, c'est un probleme coté smokeping qui ne semble pas
respecter l'option --pid-dir. Rien à voir avec systemd. Je t'invite à
ouvrir un bug sur le paquet smokeping.

Lucas

Re: Smokeping et ce de systemd

[BERTRAND Joël]

Lucas Nussbaum a écrit :
> 
> Et quand tu lances smokeping à la main avec /usr/sbin/smokeping
> --pid-dir=/run/smokeping, où crée-t-il smokeping.pid ?
> 
> est-ce que tu peux faire 'systemctl cat smokeping.service' pour vérifier
> que tu as bien le même contenu que ci-dessus (cad que tu n'as pas
> d'overrides dans /etc) ?

Root rayleigh:[/lib/systemd/system] > systemctl cat smokeping.service
# /lib/systemd/system/smokeping.service
[Unit]
Description=Latency Logging and Graphing System
Documentation=man:smokeping(1)
file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf
After=network.target

[Service]
# It would in theory be simpler to run smokeping with the --nodaemon
option and
# Type=simple, but smokeping does not work properly when in "slave" mode
with
# --nodaemon set.
Type=forking
RuntimeDirectory=smokeping
PIDFile=/run/smokeping/smokeping.pid
User=smokeping
Group=smokeping
StandardError=syslog

# If you need to run smokeping in slave/master mode, see the example unit
# override in /usr/share/doc/smokeping/examples/systemd/slave_mode.conf
ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping

ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
Root rayleigh:[/lib/systemd/system] >

Ça semble bien être la même chose (petite remarque en passant, le truc
qui intercepte les scripts SysV me semble lui aussi être une connerie
sans nom au fonctionnement aléatoire dans le machin systemd, on est bien
loin du KISS du monde Unix...).

Si je lance le daemon à la main :
Root rayleigh:[/lib/systemd/system] > /usr/sbin/smokeping
--pid-dir=/run/smokeping

je récupère un pid dans /run :
Root rayleigh:[/lib/systemd/system] > ls /run/
...
smokeping.pid
...

Je pensais naïvement qu'il devait être dans 
/run/smokeping/smokeping.pid...

Même si je crée avant de lancer smokeping un répertoire /run/smokeping,
je me retrouve avec le pid dans /run/smokeping.pid.

Bien cordialement,

JB