electro575 a écrit 841 commentaires

Comment tu as fait pour installer tes propres instances ?

Une instance pour stocker, visionner, partager des données.

Une autre instance pour chater.

C'était une erreur de ma part.

le fichier dovecot.conf n'incluait pas les fichiers du dossier conf.d

Dans le fichier /etc/dovecot/conf.d/90-sieve.conf

J'ai ceci :

sieve_plugins = sieve_imapsieve sieve_extprograms
sieve_global_extensions = +vnd.dovecot.pipe
sieve_pipe_bin_dir = /etc/dovecot/sieve

Dans le fichier /etc/dovecot/sieve/report-ham.sieve,

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];

if environment :matches "imap.mailbox" "*" {
  set "mailbox" "${1}";
}

if string "${mailbox}" "Trash" {
  stop;
}

if environment :matches "imap.email" "*" {
  set "email" "${1}";
}

pipe :copy "train-ham.sh" [ "${email}" ];

Une mise en veille après inactivité serait le mieux adapté à priori !?

Je mount et umount une fois la sauvegarde terminée, ça devrait passer

Avec cette commande, hdparm -y /dev/sdb

Pourquoi il est écrit : issuing standby command

Alors qu'au final, ça à l'air de fonctionner.

La commande hdparm -Y /dev/sdb ne fonctionne pas.

Le disque reste en standby, je n'ai jamais réussi à le mettre en sleep.

Je pense que /dev/sdd1 était un disque en plus non configuré.

Ca ne m'a pas posé de problèmes au final.

Je suis partie sur une config sans chiffrer le système par manque de temps pour investiguer.

/dev/system/system était le montage via gnome-disk-utility après avoir déchiffrer un disque à mon souvenir.

Merci pour votre aide.

Je reviens à mon besoin initial.

J'ai,

HDD1 : système debian
HDD2 : home

HDD3 : mes données

Quel moyen permet d'ajouter de l'espace à "mes données" ? Le LVM seulement ?

Merci

Le but est de pouvoir ajouter de l'espace supplémentaire au stockage des données.

Pour le moment, 1 PV est dedié pour 1 LV de DATA.

Si j'ai bien saisi, il vaut mieux chiffrer le LV si l'on veut par la suite ajouter un disque dur et étendre le LV ?

Depuis un live USB j'effectue les commandes suivantes,

sudo -s
mkdir /mnt/
mount /dev/system/system /mnt/

mount -o bind /dev/ /mnt/dev
mount -o bind /sys/ /mnt/sys
mount -t proc proc /mnt/proc
mount -o bind /run/ /mnt/run
# chroot pour acces au système debian
chroot /mnt
mount -a

Jusqu'ici, j'ai bien monté l'existant sur mon système debian.

J'update grub.

root@debian:/# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.19.0-14-amd64
Found initrd image: /boot/initrd.img-4.19.0-14-amd64
Found linux image: /boot/vmlinuz-4.19.0-13-amd64
grub-probe: error: cannot find a GRUB drive for /dev/sdd1.  Check your device.map.
Adding boot menu entry for EFI firmware configuration
done

Pour finir, j'effectue un initramfs.

root@debian:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.19.0-14-generic
cryptsetup: WARNING: target 'luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262' not
found in /etc/crypttab
```

La target 'luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262' n'est pas trouvé alors qu'elle est présente dans le fichier /etc/crypttab.

Ou se situe le problème ? C'est le fait de monter les partitions sur le système debian à mettre à jour ?

Si j'installe Debian avec une clé ou un CD et je crypte le système '/', pas de problème la partition luks-XXX est détecté au démarrage.

Lorsque je reprends mon système serveur et que je le copie à la place de celui installé avec le live USB, la partition système luks-XXX n'est pas détecté alors que les luks-XXX du DATA et HOME sont détectées.

Ok.

Le fait d'avoir le système chiffré empeche l'update-initramfs -u de voir cette partition système chiffré.

Est-ce à cause du chroot et des mounts à effectuer pour faire : grub-install, update-grub et update-initiramfs -u ?

Merci

J'ai créé une partition EFI et une autre BOOT et après le système.

L'initiramfs m'a reglé le problème quand j'avais juste le HOME et les DATA de chiffrés.

J'ai remis un coup d'installeur debian pour chiffrer aussi le SYSTEME + HOME + DATA.

Je recopie toutes mes données sauf EFI et le BOOT créé par l'installeur debian et je ferais un update-grub et update-initramfs.

Tout devrait rentrer dans l'ordre.

Oui ça fonctionne pour les archives avec "dd".

Pour celles avec "ext4", il suffit d'installer partclone pour utiliser l'outil partclone.ext4.

Soit,

gzip -d -c my_part.dd-pctl-img.gz.* >sda1.img

Puis,

partclone.ext4

Ok, merci pour vos réponses !

Il est possible d'installer le driver mais il semble quelque peu générique.

sudo dpkg-deb -x epson-inkjet-printer-escpr2-1.1.28-1lsb3.2_amd64.deb xp_15000_tmp
sudo dpkg-deb --control epson-inkjet-printer-escpr2-1.1.28-1lsb3.2_amd64.deb xp_15000_tmp/DEBIAN
sudo gedit xp_15000_tmp/DEBIAN/control
sudo dpkg -b xp_15000_tmp xp_15000_all.deb
sudo dpkg -i xp_15000_all.deb

puis

chown -Rv root:root /opt/epson-inkjet-printer-escpr2/
systemctl restart cups
ls -lhd $(dpkg -L epson-inkjet-printer-escpr2)
ln -sv /lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3

et hop on peut imprimer avec le driver epson escpr2.

Je pense également que le driver gutenprint libre est exploitable.

J'aimerais compiler ce driver.

Est-ce que tu connais le flow de compilation ?

https://github.com/torvalds/linux/blob/master/drivers/media/i2c/ov5670.c

Ok, je reprécise les 2 matériels.

Caméra ov5670 -> kernel 5.10
Unicam HM2051 -> pas dans le kernel 5.10

Il y a un sujet similaire pour les modèles presque identique suivant.

OV5648 and HM2056 cameras not yet supported by the kernel.
https://bugzilla.kernel.org/show_bug.cgi?id=195877

Dans mon cas, il faudrait quand même reconstruire un noyau ?

Je n'ai que cette piste pour le moment pour la ov5670.
https://linuxtv.org/downloads/v4l-dvb-apis/admin-guide/i2c-cardlist.html

Je continue de chercher suivant les indications que tu as pu me donner.

Oui bien sur, mais mettons que le noyau ne gère pas actuellement un autre modèle de caméra integré.

Comment ferais-tu si tu avais les sources du driver lié à cette caméra ?

Si je compile le driver, je ne peux pas intégrer le driver au noyau directement ? (Sans avoir besoin de recompiler le noyau)

Oui tout à fait.

On ne peut pas compiler le driver et faire ensuite un modprobe pour l'activer ?

Compiler le noyau en entier, on me dit que ça n'est pas aisé mais bon.

Je pense que c'est faisable aujourd'hui, plus facilement qu'avant.

Si tu as un lien concernant ceci, je veux bien.

Donc les deux caméras sont,
Camera sensor ov5670
Camera sensor unicam hm2051

Pour la caméra ov5670, son driver est intégré dans le noyau linux 5.10.

Quelqu'un saurait m'indiquer quand cette version 5.10 de sid basculera dans le dépot buster-backports ?

Je ferais déjà un premier test.

https://linuxtv.org/downloads/v4l-dvb-apis/admin-guide/i2c-cardlist.html

Merci beaucoup.

Si je reviens sur le sujet,

Non mature,
Ubports installer : Ubuntu touch
Debian mobile

Bonne option,
/e/ os
sailfish OS => drivers , middleware (mer), Sailfish OS (composants Qt proprio) mais bon

Librem 5 / PureOS : OK mais si je ne me trompe pas on est américain non ? Sinon, ça m'a l'air bien

Un bon article à propos :
https://mart-e.be/post/2020/03/25/letat-du-libre-dans-les-telephones-2020/

Oui c'est bien ça que j'ai vu.

N'ayant pas eu connaissance de cela,

J'avais commencé par opensmtp à la place de postfix.

Est-ce bien "canonical_maps" qui est concerné ?

https://postfix.traduc.org/index.php/postconf_trie.html

Aujourd'hui voici mes logs,

postfix/smtpd: client=unknown[10.5.30.1], sasl_method=PLAIN, sasl_username=prenom.nom
postfix/qmgr: from=<prenom.nom@domain.fr>, size=726, nrcpt=1 (queue active)
postfix/smtpd: disconnect from unknown[10.5.30.1] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8

postfix/local: to=<prenom.nom@domain.fr>, relay=local, delay=24, delays=24/0.01/0/0.05, dsn=5.1.1, status=bounced (unknown user: "prenom")
postfix/qmgr: removed

D'accord, merci pour tes infos.

Quand je disais que le ping fonctionne, c'est que je vois la requete avec wireshark sur le PC que je ping.

Il n'y a en revanche pas de retour de la part du PC qui est pingé.

224.0.0.1 sera l'adresse à pinguer pour les machines dans le reseau 224.0.0.x/24

Donc il doit me manquer un serveur pour prendre en charge les adresses du groupe multicast pour pouvoir peut être répondre, même si ça n'est pas le but du multicast.

J'avais vu smcroute, je ne sais pas si cela correspond parfaitement à mon besoin.

Oui, je suis d'accord. On a toujours plus d'idées en équipe.

Désolé pour le temps perdu.

Une histoire de cable que je pensais bon, …

Comme j'en fais passer dans le mur, … peut être que j'ai du les endommager, …