electro575 a écrit 888 commentaires

=> 2ème conclusion : avec des HDD et non des SSD, c'est encore plus mal barré pour faire des sauvegardes je pense à cause des latances !

=> comment reformater lentement mes deux disques dur qui ont subi le coup du rsync ?

Oui, les SSD sont peut être plus approprié, je ne sais pas, …

Mes deux disques dur sont branchés sur chacun un port USB de ma raspberry pi de 2To chacun.

J'ai effectué un rsync entre mes deux disques dur.

Je me retrouve avec cette erreur :

rsync: mkstemp "/mnt/my_data_clone/Archives_D/" failed:Read-only file system (30)

puis après me voici avec un disque dur démonté et avec ces erreurs lors d'un fsck :

j@jpcportable:~$ sudo fsck /dev/sdb
fsck de util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Numéro magique invalide dans le super-bloc fsck.ext2 : Superbloc invalide, tentons d'utiliser les blocs de sauvetage... fsck.ext2: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sdb

Le superbloc n'a pu être lu ou ne contient pas un système de fichiers ext2/ext3/ext4 correct. 
Si le périphérique est valide et qu'il contient réellement un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre), alors le superbloc est corrompu, et vous pourriez tenter d'exécuter e2fsck avec un autre superbloc :
    e2fsck -b 8193 <périphérique>
 ou
    e2fsck -b 32768 <périphérique>

Trouvé une table de partitions gpt dans /dev/sdb

=> Conclusion :
1-trouver un autre schéma de boot
2-mettre les deux disques dans mon PC fixe et réveiller le PC fixe à chaque sauvegarde.
3-soit mettre le hub USB en plus mais les disques durs sont alimentés -> Possibilité d'obtenir les même erreurs
4-booter sur la carte SD et monter les 2 HDD dans le /mnt sachant que la carte microSD sera utilisé ! Possibilité d'obtenir les même erreurs

J'obtiens ceci lors de la communication avec 2ème disque dur externe et la pi :

    pi@raspberrypi:~ $ journalctl -r -p err
    -- Logs begin at Thu 2016-11-03 17:16:43 UTC, end at Mon 2018-01-08 17:46:28 UTC. --
    Jan 08 17:46:28 raspberrypi kernel: Buffer I/O error on dev sdb2, logical block 486281216, async page read
    Jan 08 17:46:28 raspberrypi kernel: blk_update_request: critical medium error, dev sdb, sector 3907028992
    Jan 08 17:46:28 raspberrypi kernel: Buffer I/O error on dev sdb1, logical block 2097136, async page read
    Jan 08 17:46:28 raspberrypi kernel: blk_update_request: critical medium error, dev sdb, sector 16779136
    Jan 08 17:46:16 raspberrypi kernel: Buffer I/O error on dev sdb2, logical block 486281216, async page read
    Jan 08 17:46:16 raspberrypi kernel: blk_update_request: critical medium error, dev sdb, sector 3907028992
    Jan 08 17:46:16 raspberrypi kernel: blk_update_request: critical medium error, dev sdb, sector 3907028992
    Jan 08 17:46:16 raspberrypi kernel: Buffer I/O error on dev sdb1, logical block 2097136, async page read
    Jan 08 17:46:16 raspberrypi kernel: blk_update_request: critical medium error, dev sdb, sector 16779136
    Jan 08 17:46:16 raspberrypi kernel: blk_update_request: critical medium error, dev sdb, sector 16779136
    Jan 08 17:37:51 raspberrypi kernel: JBD2: Error -5 detected when updating journal superblock for sdb2-8.
    Jan 08 17:37:51 raspberrypi kernel: Buffer I/O error on dev sdb2, logical block 242778112, lost sync page write
    Jan 08 17:37:51 raspberrypi kernel: Aborting journal on device sdb2-8.
    Jan 08 17:37:51 raspberrypi kernel: JBD2: Error -5 detected when updating journal superblock for sdb2-8.
    Jan 08 17:37:51 raspberrypi kernel: Buffer I/O error on dev sdb2, logical block 242778112, lost sync page write
    Jan 08 17:37:51 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 1959004160
    Jan 08 17:37:51 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 50337920
    Jan 08 17:37:51 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 50337680
    Jan 08 17:37:50 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 50337440
    Jan 08 17:37:50 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 50337200
    Jan 08 17:37:50 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 50336960
    Jan 08 17:37:50 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 50336720
    Jan 08 17:37:50 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 50336480
    Jan 08 17:37:49 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 50336240
    Jan 08 17:37:49 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 50336000

J'ai pu modifier l'UUID avec Gparted mais comme j'ai fait un coup de clonezilla je me retrouve avec le même PARTUUID.

A priori ce n'est pas ça qui pause problème.

Il m'a été dit ceci :

Ta config est différente de la mienne, je n'ai jamais essayé de bouter depuis USB avec 2 disques branchés.
Ici: https://github.com/raspberrypi/firmware/issues/647 il est indiqué de rajouter un fichier (vide, on dirait) nommé "timeout" à côté de bootcode.bin dans la SD.

Je regarde ce qui bloque ce soir et revient vers vous.

Oui je peux mettre ceci.

Par contre dans le fichier cmdline.txt qui sera mis en cmdline.usb, j'ai cette commande :

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait rootdelay=5

Je n'arrive pas à remplacer root=/dev/sda1 par UUID, ça ne fonctionne pas.

Je ne lance pas le système de fichier de la carte microSD donc je boot sur un disque dur externe de la pi.

Dans l'ordre branché des disques dur je suis sur de booter sur le bon disque dur mais si jamais je change l'ordre, je suis bon pour un tour.

Il n'y a pas d'autres moyens de se baser sur l'UUID depuis la carte microSD ? Même le LABEL ne fonctionne pas. J'avais essayé.

Si les disques sont alimentés en externe, il ne devrait pas y avoir de problème je pense.

A voir avec l'utilisation de rsync. Je n'utilise pas le hdmi

Résultat d'un petit Wireshark.

Les ports que je peux ouvrir dans mon firewall sont les suivants :
53
443

Les ports qui sont utilisés aléatoirement :
35260
49008

Les IP :
10.0.0.1
10.0.0.3
2.18.117.197

=> Comment autoriser les ports d'entrées utilisés aléatoirement en sortie ? avec les états RELATED,ESTABLISHED

En complément à cela,

J'ai lancé la commande suivante :

ss -nltp

LISTEN   0   5 :::443   :::*   users:(("certbot",pid=3437,fd=8))

A ce qu'on m'a dit c'est de l'ipv6 :::443

Je vous recopie mon pare feu ipv4 avec iptables-persistant (j'ai créé l'exception pour le port 443 tout de même, … je ne comprend pas)

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [13:1456]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4448 -j ACCEPT

#-A OUTPUT -p udp --dport 53 -j ACCEPT
#-A OUTPUT -p tcp --dport 21 -j ACCEPT
#-A OUTPUT -p tcp --dport 80 -j ACCEPT

#-A INPUT -p udp --dport 53 -j ACCEPT
#-A INPUT -p tcp --dport 21 -j ACCEPT
#-A INPUT -p tcp --dport 80 -j ACCEPT

-A INPUT -p tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

#-A OUTPUT -p tcp -m multiport --dports 80,443,8000 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
#-A INPUT -p tcp -m multiport --sports 80,443,8000 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m tcp --dport 5222 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5269 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5280 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5281 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth0 -p icmp -j ACCEPT

Enfin voila, avec mon pare feu certbot ne fonctionne pas (toujours la même erreur), même un aptitude install en fonctionne pas !

En effet serveur1.fr n'est pas nom de domaine.

Par contre, j'ai remarqué qu'en supprimant les règles de mon part-feu de ma raspberry et avec les ports 443 & 80 ouvert de ma box redirigé vers la raspberry, j'ai réussi à générer un certificat -> plus d'erreur.

Pourtant j'avais bien ajouté les exceptions au port 443 et 80 en INPUT, qu'est-ce que je devrais ajouter en plus comme exception à mon part-feu ?

Voici les règles concernant le port 443 et 80 :

# Certificat (Prosody)
/sbin/iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
/sbin/iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT

root@raspberrypi:/home/pi# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:4448
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:xmpp-client state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:xmpp-server state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:5280 state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:5281 state NEW,RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere

Je ne vois pas ce qui peut pauser problème. Qu'est-ce que je dois ajouter comme exception pour que la commande suivante se fasse sans erreur du port 443 : certbot certonly -d serveur1.fr !?

Merci d'avance

Merci pour vos remarques.

J'ai retenté la commande ce matin. J'ai redirigé le port box 443 vers 443 (ou autre du service XMPP) de la pi et idem pour le 80 mais rien n'y fait, j'ai toujours la même erreur (26/12/17 à 19:11) en lançant l'une des deux commandes :

certbot renew --deploy-hook "prosodyctl --root cert import /etc/letsencrypt/live"

certbot renew --dry-run

Effectivement mais je ne vois pas pourquoi je n'arrive pas à en créer ! Il faut que le port 443 soit ouvert ?

Egalement avec la commande qui va bien est-ce que le certificat sera auto-signé => en gros ai-je besoin de le transférer manuellement sur les téléphones ou alors le certificat sera proposé automatiquement ?

Merci

Voici l'erreur que j'ai en ce moment, je pense que c'est parce que je n'ai pas ouvert le port 443 sur ma box mais ouvert sur ma pi.

root@raspberrypi:/home/pi# certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/serveur1.fr.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator standalone, Installer None
Attempting to renew cert (serveur1.fr) from /etc/letsencrypt/renewal/serveur1.fr.conf produced an unexpected error: HTTPSConnectionPool(host='acme-staging.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x76a50af0>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',)). Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/serveur1.fr/fullchain.pem (failure)

-------------------------------------------------------------------------------
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/serveur1.fr/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
-------------------------------------------------------------------------------
1 renew failure(s), 0 parse failure(s)

A priori la raison est parce que le certificat créé n'est pas créé par une autorité.

Par quel organisation passer pour créer mon certificat ?

Lien chat secure : https://chatsecure.org/blog/page3/

Actuellement,

1°) oui configurer fail2ban

ssh : OK via fail2ban

sftp : IP non banni si trop de tentatives

xmpp : analyser les logs xmpp

2°) fail2ban avec script d'envoie de mail si IP banni
Si 1°) -> OK pas besoin du 2°)

3°) gérer les IP, non nécessaire si 1°) mis en place.
Nécessaire si changement IP & hacker
->

4°) Cas de figure si trop d'essai via plusieurs machines dans la même journée

Bonne feuille de route, merci

Bonjour,

Tu peux aller regarder dans les logs, syslog peut être pour te renseigner.

Oui merci à vous deux

J'ai fait la mise à jour hier.

Tout c'est bien passé, je l'ai fait depuis ssh de mon pc portable.

Par contre, comment je peux récupérer tous le flux qui est passé dans mon terminal ?

Cette commande n'a pas fonctionné :

apt-get dist-upgrade > sortie.txt

Ha okey merci.

Je vais voir ça ce soir.

Bon je vais rester en mode simple sur xfce4.

Je te remercie.

Bonne soirée.

Merci

Oui, et donc est-ce qu'on remet juste les fichiers de configs pour les avoirs à nouveau ?

Soit disant qu'ils disparaissent avec la mise à niveau ! ?

Faut-il désinstaller les paquets avant d'effectuer une mise à jour ?

Bon il y a quelques points obscures encore du manuel pour moi sans avoir pratiqué une mise à niveau. mais quand faut y aller faut y aller.

De mon côté j'ai écris ceci :

I-SAUVEGARDES

1-Complète : Ghost Clonezilla du système

2-Sauvegardes principales :

/etc
/var/lib/dpkg
/var/lib/apt/extended_states
dpkg --get-selections "*" > $HOME/sortie.out

si utilisation de aptitude
/var/lib/aptitude/pkgstates

$HOME

3-Les fichiers de configuration des logiciels

???

II-ETAT DU SYSTEME

1-Lister les paquets installés

aptitude search '~i(!~ODebian)'
apt-forktracer | sort

-Vérifier les actions en cours sur les paquets

vous devez lancer aptitude en mode terminal complet et appuyer sur g (« Go »), … voit site

3-Désactiver l'épinglage APT

Si vous avez configuré APT pour installer certains paquets d'une distribution autre que stable (par exemple, de testing), … voir site

4-Vérifier l'état des paquets

Tous les paquets qui sont dans l'état « Half-Installed » ou « Failed-Config », ainsi que ceux qui sont dans un état d'erreur :

dpkg –audit

5-Vérifier si des sources stretch pour des paquets non-officiels

III-PREPARER LA MISE A NIVEAU

1-Modifier le /etc/apt/source.list

Modifier jessie vers stretch

2-Mise en place « script maj_debian_jessie2stretch.log »

script -t 2>~/upgrade-stretchetape.time -a ~/upgrade-stretchetape.script

3-Se connecter à la machine à upgrade via SSH

ssh user@192.168.X.X

4-Télécharger les sources stretch

apt-get update

5-Mise à jour minimale du système

apt-get upgrade

=> on peut observer si les paquets sont toujours présent.

6-Mise à jour complète du système

apt-get dist-upgrade

---

Il y a t-il besoin d'upgrade avec aptitude également ?

1°) la sauvegarde

Il était écrit dans le manuel officiel que l'upgrade va supprimer des fichiers de mise à jour.

Il suffi de sauvegarder le /etc et de le remettre après la mise à jour pour retrouver la conf des logiciels ?

Idem pour le /home/monuser ?

2°) l'upgrade

apt safe-upgrade te fait une liste des paquets qui vont subir une mise à jour ?

Merci pour l'historique de l'évolution.

3°) lister les paquets d'un distri

Est-il nécessaire de supprimer les paquets installés ou l'on peut les laisser en les surveillant avec apt safe-upgrade ?

En fait pour ristretto, si il ne peut pas envoyer l'image à la corbeille, il me met en erreur alors que Gthumb me propose la suppression définitive.