La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
Câblage => Discussion démarrée par: Johannol le 06 juillet 2022 à 20:33:13
-
L'objectif du projet est d'avoir une solution adapté en rénovation, lorsque l'espace est compté en largeur et en profondeur, mais qu'on souhaite néanmoins disposer d'une partie "communication" potentiellement performante: caser des prises RJ45/fibre, un PTO, des switch, une box, des prises 230V...
Les rack 10" répondent coté largeur, mais sont souvent trop profond pour être placés dans une entrée, en dessous de l'électricité.
(https://lafibre.info/cablage/rack-10-22u-pas-cher-impression-3d/?action=dlattach;attach=129173)
Sur ce projet, la structure a été pensé pour:
- être peu profonde, actuellement 10,5cm, afin de s'intégrer correctement dans un appartement, par exemple avec un coffrage bois, mais néanmoins suffisant pour permettre une box en vertical, un switch type TL-SG105, un Raspberry PI pour la domotique, etc. Je rajouterai des modèles d'équerres + profondes si besoin / demande.
- pouvoir fixer le PTO sur la partie murale, sur le rail DIN, mais pouvoir dans un 2eme temps démonter les rails pour différentes raisons, comme changer la profondeur.
- Pouvoir ajuster un peu la hauteur du rail DIN en fonction du modèle de PTO (3 positions possible)
- Avoir une grande hauteur, afin de compenser la faible largeur et caser tout le matériel.
Le projet a été réalisé avec 1 rail
https://www.thomann.de/fr/adam_hall_61552_blk_rackschiene.htm
coupé en 2, ce qui donne 22U de hauteur, et entre le rail + port, et l'impression, on arrive globalement à un cout de 40 euro ! ;D
Plan de la structure Rack:
https://www.thingiverse.com/thing:5426640
En option mais c'est mieux:
- Le(s) rail(s) à couper et visser:
https://www.amazon.fr/gp/product/B07V69SYTX/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1
- Un bornier terre (Obligatoire dans la norme NFC-15100)
https://www.amazon.fr/gp/product/B01ARYXH4O/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1
-
On va parler des accessoires sympa (le message va vivre un peu dans le temps):
1) Un support "rackpi".
Qu'est que ce truc? C'est un format hérité de système audio d'effet de guitare/etc, car il est idiot de monopoliser 1U d'un rack 19" pour une petite électronique. qui se montent dans des racks. Donc le format permet de monter 10 modules dans 2U d'un rack 19", et 5 modules dans 2U d'un rack, dans ce type de support:
https://www.musicstore.com/fr_BE/EUR/DAP-2-HE-Rackblende-f-Modulsystem-10-Segmente-MP-1/art-PAH0017160-000;pgid=R8igIecFoLBSRplpOdFjJn7V0000WhqCaZgD
https://www.thingiverse.com/thing:1793758
Et quelqu'un (Krapozok ?) a eu l'idée d'utiliser ce format pour les Raspberry Pi, d'où le nom "Rackpi", et le succès a généré l'apparition de modules pour tous les PI, mais aussi électronique TNT, Arduino, etc... en fait tout petite électronique qu'on ne sais jamais trop comment caser proprement dans un rack. D'un point de vue domestique, on peut penser à un Raspberry Pi pour la domotique, pour un PiHole, à un ampli TNT, ou un diffuseur de TNT sur le réseau, etc...
Pour le rack 10", il existe un plan de support 100% imprimable ( https://www.thingiverse.com/thing:4087382 ) mais je souhaitais quelque chose de + robuste, à ma manière, en métal, donc il y a 2 oreilles imprimables et un gabarit de perçage avant taraudage pour rail alu 10*12 trouvable dans tout magasin de bricolage. C'est très simple à faire, et le gabarit peut être utilisé pour un 10" ou 19".
Lien thingiverse pour montage 10": https://www.thingiverse.com/thing:5428819
-
Ce qui est dommage avec ce type de montage, c'est que la carte se trouve dans le rack et comme c'est le point faible, pour la changer, il faudra sortir le Pi.
Un système avec le Pi sur glissières serait le top 8)
-
Ce qui est dommage avec ce type de montage, c'est que la carte se trouve dans le rack et comme c'est le point faible, pour la changer, il faudra sortir le Pi.
Un système avec le Pi sur glissières serait le top 8)
La remarque peut s'entendre, et pour que les autres puissent comprendre, cela fait référence aux cartes SD qui peuvent mal vieillir et lâcher avec l'utilisation en tant que support d'un OS qui fait de l'écriture régulière, d'où la nécessité de faire des backup réguliers.
Il existe des plan avec des glissières, mais ce n'est plus ce même "format" avec l'avantage de profiter de tous les autres plans disponibles pour tout et n'importe quoi. Et cela prends 1min pour enlever les 2 vis tout en étant dissuasif pour un petit enfant...
Mais même en prenant vraiment en compte ce problème, ce que j'ai fais moi même, il y a plusieurs réponses possible:
- Accéder facilement à la carte pour l'extraire: quelqu'un a fait le plan d'un Rackpi avec la carte facilement accessible avec un connecteur "rallonge". Carte en façade donc.
- Oublier l'extraction de la carte et l'interruption de service, et faire des backups automatisé du système par le réseau sur un NAS ou un PC. J'ai vérifié que c'est faisable avec Home Assistant
- Fiabiliser le problème à la source, oublier la carte SD et utiliser un SSD à la place. C'est la méthode que j'ai choisi, et le module domotique comprends donc un Raspberry PI, un SSD et un récepteur Zigbee
La finition n'est pas là (une peinture à venir certainement) mais c'est fonctionnel. ;D
-
- Fiabiliser le problème à la source, oublier la carte SD et utiliser un SSD à la place. C'est la méthode que j'ai choisi, et le module domotique comprends donc un Raspberry PI, un SSD et un récepteur Zigbee
Ou bien utiliser une carte de qualité (par ex SanDisk Extreme) voire carrément une carte industrielle (par ex SwissBit) qui encaissera sans problème quelques TBW :)
Ou bien configurer correctement son OS pour qu'il n'écrive rien ou presque (je suis entre 0 et 500KB par jour sur mes différents Pi, suivant l'usage).
Mes 2 sioux :)
-
Un sujet qui en parle Optimisation d'un serveur Linux pour un SSD : réduire au maximum les écritures sur le SSD (https://lafibre.info/serveur-linux/optimisation-ssd/)
À noter que le forum est toujours sur le même SSD Samsung depuis 2016 (mais un SSD est plus endurant qu'une carte SD).
-
ou externaliser le stockage et booter sur le réseau ?
-
ou externaliser le stockage et booter sur le réseau ?
Je ne sais pas si c'est possible ça ???
Bon, sinon, j'ai publié sur thingiverse le "helper" pour faire le support rackpi pour rack 10" ou 19"
-
C'est de toute façon en marge de votre sympathique projet.
Une recherche de type "rpi iscsi boot" ou dans le genre devrait conduire à pas mal de résultats pour des modèles assez récents.
Je viens de passer 5 mns dessus par curiosité. Il y a quelques variations suivant le modèle. Si on ne peut pas toujours directement booter sur iSCSI on peut vraisemblablement avoir à défaut le root sous NFS et puis le reste comme on veut.
Au passage, pas spécialement pour le fond de l'article mais pour quelques photos de montage de rpi si ça peut donner des idées : https://blog.alexellis.io/state-of-netbooting-raspberry-pi-in-2021/
-
Ou bien utiliser une carte de qualité (par ex SanDisk Extreme) voire carrément une carte industrielle (par ex SwissBit) qui encaissera sans problème quelques TBW :)
Ou bien configurer correctement son OS pour qu'il n'écrive rien ou presque (je suis entre 0 et 500KB par jour sur mes différents Pi, suivant l'usage).
Je suis en train de préparer le 2ème module, stream TV/TNT en recyclant un PI 1b et en utilisant le logiciel tvheadend, et je suis ici avec l'approche "SanDisk Extreme" et faible écriture.
Tu aurais le tuto qui va bien vu tes résultats?
-
Je suis en train de préparer le 2ème module, stream TV/TNT en recyclant un PI 1b et en utilisant le logiciel tvheadend, et je suis ici avec l'approche "SanDisk Extreme" et faible écriture.
Tu aurais le tuto qui va bien vu tes résultats?
Pas vraiment de tuto vu que je fais ça à l'habitude, mais les principes de base (sur une raspbian) c'est désinstaller/désactiver tout ce qui ne sert à rien (désinstaller c’est mieux: ça réduit les données écrites lors des upgrades, debfoster est mon meilleur ami pour ça), en particulier rsyslog et logrotate (je ne garde que le log RAM de systemd-journald) et les autoupdates des repos apt, mettre resolv.conf en symlink vers /run, et /var/lib/dhcp en symlink vers /tmp (ou monter un tmpfs dedans), et là on est déjà mieux.
J'ai un raspi 0 avec le tvhat, j'ai exactement ça qui tourne dessus:
1 ? Ss 0:16 /sbin/init
86 ? Ss 0:04 /lib/systemd/systemd-journald
109 ? Ss 0:01 /lib/systemd/systemd-udevd
150 ? Ssl 0:01 /lib/systemd/systemd-timesyncd
227 ? Ss 0:04 avahi-daemon: running [rPiTV.local]
233 ? S 0:00 \_ avahi-daemon: chroot helper
229 ? Ss 0:00 /usr/sbin/cron -f
231 ? Ss 0:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
232 ? Ssl 0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.
248 ? Ss 0:01 /lib/systemd/systemd-logind
251 ? Ss 0:00 /usr/sbin/dropbear -p 22 -W 65536
1474 ? S 0:00 \_ /usr/sbin/dropbear -p 22 -W 65536
1475 pts/0 Ss 0:00 \_ -bash
1481 pts/0 R+ 0:00 \_ ps fax
375 ? Ssl 4:24 /usr/sbin/collectd
397 ? Ss 0:00 /sbin/rpcbind -f -w
401 ? Ssl 17:28 /usr/bin/tvheadend -f -p /run/tvheadend.pid -u hts -g video
collectd évidemment non nécessaire, rien d'écrit en local tout est poussé vers un serveur distant, je pourrais sans doute me passer du cron, d'avahi (et donc de dbus) et j'ai installé dropbear plutôt qu'openssh. le rpcbind c'est parce que j'ai monté en NFS un volume pour tvheadend pouvoir notamment faire un peu d'enregistrement programmé en cas de besoin. Sur ce système, si je ne me connecte pas en ssh je suis à ~0 écriture (j'ai conservé l'usage de wtmp/lastlog, même si ce n'est pas vraiment nécessaire).
Sur certains pi je peux même arriver à monter tout le filesystem en read-only (typiquement je remplace timesyncd par chrony car timesyncd est incapable de tourner en full read-only). Dans les cas intermédiaires j'utilise http://hacks.slashdirt.org/sw/flashybrid/ mais je crois qu'il y a d'autres solutions du même genre qui sont un peu plus abouties.
Voilà dans les grandes lignes les principes. J'utilise typiquement des cartes SanDisk Ultra de 16GB (l'overprovisionning en taille est une autre méthode pour prolonger la durée de vie des cartes) et j'attends toujours la première panne, en sachant que mon plus vieux pi (un modèle 1A) tourne 24/7 depuis 2016 avec la même carte, donc je dirais que c'est honnête comme résultat :)
J'espère que ça répond un peu à ta question.
-
Pas vraiment de tuto vu que je fais ça à l'habitude,
Même sans tuto, tu m'a donné pas mal de pistes intéressantes, je ne connaissais pas debfoster par exemple. Et j'ai trouvé quelques idées ailleurs. Merci
N’empêche, ta commande ps m'a donné un point de comparaison même si non directement comparable avec un système récent... et j'ai pu voir que de partir d'une image "minimal" est déjà une excellente base de travail.
-
Regardez du coté de U-Boot, il y a eu pas mal de modifications sur l'intégration de file-system embarqués.
-
N’empêche, ta commande ps m'a donné un point de comparaison même si non directement comparable avec un système récent...
Pour info le ps que j'ai posté est pris sur un système "bullseye" (upgradé à la mano, install d'origine en buster de mémoire):
cat /etc/debian_version
11.3
et j'ai pu voir que de partir d'une image "minimal" est déjà une excellente base de travail.
Oui j'ai oublié de le préciser tellement c'était évident à mes yeux ;)
-
Pour info le ps que j'ai posté est pris sur un système "bullseye" (upgradé à la mano, install d'origine en buster de mémoire):
J'ai dis cela car mon ps renvoie par exemple la liste kthreadd et étrangement pas toi. :-[ Mais il y a des trucs qui te paraissent + évident à toi qu'a moi ;D
pi@tvheadend:~ $ ps fax
PID TTY STAT TIME COMMAND
2 ? S 0:00 [kthreadd]
5 ? I 0:03 \_ [kworker/u2:0-events_unbound]
6 ? I< 0:00 \_ [mm_percpu_wq]
7 ? S 0:00 \_ [rcu_tasks_rude_]
8 ? S 0:00 \_ [rcu_tasks_trace]
9 ? S 0:04 \_ [ksoftirqd/0]
10 ? S 0:00 \_ [kdevtmpfs]
11 ? I< 0:00 \_ [netns]
12 ? I< 0:00 \_ [inet_frag_wq]
13 ? I 0:00 \_ [kworker/0:1-events_power_efficient]
14 ? S 0:00 \_ [kauditd]
15 ? S 0:00 \_ [khungtaskd]
16 ? S 0:00 \_ [oom_reaper]
17 ? I< 0:00 \_ [writeback]
18 ? S 0:00 \_ [kcompactd0]
33 ? I< 0:00 \_ [kblockd]
34 ? I< 0:00 \_ [blkcg_punt_bio]
35 ? S 0:00 \_ [watchdogd]
37 ? I 0:00 \_ [kworker/u2:2-events_unbound]
38 ? I< 0:00 \_ [rpciod]
39 ? I< 0:00 \_ [kworker/u3:0]
40 ? I< 0:00 \_ [xprtiod]
41 ? S 0:00 \_ [kswapd0]
42 ? I< 0:00 \_ [nfsiod]
43 ? I< 0:00 \_ [iscsi_eh]
44 ? I< 0:00 \_ [iscsi_conn_clea]
45 ? I< 0:00 \_ [dwc_otg]
46 ? I< 0:00 \_ [DWC Notificatio]
48 ? S< 0:00 \_ [vchiq-slot/0]
49 ? S< 0:00 \_ [vchiq-recy/0]
50 ? S< 0:00 \_ [vchiq-sync/0]
51 ? I< 0:00 \_ [zswap-shrink]
53 ? I 0:00 \_ [kworker/0:3-events_power_efficient]
54 ? I< 0:00 \_ [mmc_complete]
55 ? I< 0:00 \_ [kworker/0:1H-kblockd]
56 ? S 0:00 \_ [jbd2/mmcblk0p2-]
57 ? I< 0:00 \_ [ext4-rsv-conver]
59 ? I< 0:02 \_ [kworker/0:2H-mmc_complete]
60 ? I< 0:00 \_ [mld]
61 ? I< 0:00 \_ [ipv6_addrconf]
138 ? S 0:00 \_ [vchiq-keep/0]
139 ? S< 0:00 \_ [SMIO]
149 ? I< 0:00 \_ [mmal-vchiq]
151 ? I< 0:00 \_ [mmal-vchiq]
152 ? I< 0:00 \_ [mmal-vchiq]
153 ? I< 0:00 \_ [mmal-vchiq]
154 ? I< 0:00 \_ [mmal-vchiq]
155 ? I< 0:00 \_ [mmal-vchiq]
157 ? I< 0:00 \_ [mmal-vchiq]
284 ? I< 0:00 \_ [cfg80211]
338 ? S 0:00 \_ [cec-vc4]
339 ? S 0:00 \_ [irq/64-vc4 hdmi]
340 ? S 0:00 \_ [card0-crtc0]
341 ? S 0:00 \_ [card0-crtc1]
342 ? S 0:00 \_ [card0-crtc2]
343 ? S 0:00 \_ [card0-crtc3]
380 ? S 0:00 \_ [kdvb-ad-0-fe-0]
549 ? I 0:00 \_ [kworker/0:0-events]
565 ? I< 0:00 \_ [kworker/0:0H]
579 ? I 0:00 \_ [kworker/u2:1-events_unbound]
580 ? I 0:00 \_ [kworker/u2:3-events_unbound]
1 ? Ss 0:13 /sbin/init
101 ? Ss 0:01 /lib/systemd/systemd-journald
123 ? Ss 0:01 /lib/systemd/systemd-udevd
245 ? Ss 0:00 avahi-daemon: running [tvheadend.local]
248 ? S 0:00 \_ avahi-daemon: chroot helper
246 ? Ss 0:00 /usr/sbin/cron -f -L 0
247 ? Ss 0:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
263 ? Ss 0:01 /lib/systemd/systemd-logind
267 ? Ss 0:00 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user nobody --deviceglob /dev/input/event*
306 ? SLsl 0:00 /usr/sbin/rngd -r /dev/hwrng
311 tty1 Ss 0:00 /bin/login -f
452 tty1 S+ 0:00 \_ -bash
312 ? Ss+ 0:00 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 ttyAMA0 vt220
316 ? Ss 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
486 ? Ss 0:00 \_ sshd: pi [priv]
512 ? S 0:00 \_ sshd: pi@pts/0
513 pts/0 Ss 0:00 \_ -bash
620 pts/0 R+ 0:00 \_ ps fax
349 ? Ss 0:01 /lib/systemd/systemd --user
350 ? S 0:00 \_ (sd-pam)
351 ? Ssl 1:23 /usr/bin/tvheadend -f -p /run/tvheadend.pid -u hts -g video
451 ? Ssl 0:00 /lib/systemd/systemd-timesyncd
464 ? Ss 0:00 /usr/sbin/dhcpcd -w -
-
J'ai dis cela car mon ps renvoie par exemple la liste kthreadd et étrangement pas toi. :-[ Mais il y a des trucs qui te paraissent + évident à toi qu'a moi ;D
J'avais en effet supprimé tous les ktrheads du résultat: ils n'ont aucun intérêt pour l'explication qui se concentrait sur les processus (démons) actifs :)
-
J'avais en effet supprimé tous les ktrheads du résultat: ils n'ont aucun intérêt pour l'explication qui se concentrait sur les processus (démons) actifs :)
Et moi j'ai cru que tu utilisais un vieux système. ;D
Bon, je commence à avoir un système fini, j'ai ajouté le montage smb d'un NAS pour les enregistrements TV, ça marche au poil. Je vais peut-être tester avec une 2eme clef voir si le PI 1B arrive à suivre, et après, conception du boitier en intégrant le(s) clef(s) pour mieux les protéger.
-
Je vais peut-être tester avec une 2eme clef voir si le PI 1B arrive à suivre, et après, conception du boitier en intégrant le(s) clef(s) pour mieux les protéger.
Je tourne sur un pi 0 à environ 25% de CPU en streaming (avec le tv hat il est vrai et un adaptateur USB/ethernet pour la connexion réseau), et le CPU ne décolle pas de sa fréquence de base 700MHz. Donc je pense qu'un Pi 1B n'aura aucun problème, du moment que tu n'utilises pas le wifi.