Archlinux.fr [Forums]

Bonjour communauté !

Je me tourne vers vous pour avoir un maximum d'avis !
Je possède un EliteBook de chez HP :

- I7 octo core 2G 3,3ghz
- 8G ram DDR3
- SSD 180G : 254803968*octets (255 MB) copiés, 1,95701*s, 130 MB/s
- USB 4G x1 : 370970624*octets (371 MB) copiés, 22,6875*s, 16,4 MB/s
- USB 8G x2 : 370970624*octets (371 MB) copiés, 22,762*s, 16,3 MB/s | 370970624*octets (371 MB) copiés, 23,961*s, 15,5 MB/s
- USB 128G x1 : 370970624*octets (371 MB) copiés, 31,8314*s, 11,7 MB/s

(Je peux eventuellement au besoin acheter clé usb / micro sdhc de bonne perf')

Réservé uniquement pour kali linux 2.0, je souhaite partionnner au maximum ma configuration pour pouvoir ajuster les options de montage, la taille des partitions, la sécurité, la réactivité. (LVM / luks ou mieux ?)
Je souhaites également préservé mon SSD d'écriture répété et futile.
Toujours dans ma liste de souhaits, je compte utiliser cette approche pour le bootage de la machine :

* clé de boot insérée + clé de chiffrement pas insérée : boot avec demande de password
* clé de boot insérée + clé de chiffrement insérée : boot automatiquement
* clé de boot pas insérée : pas de boot

( le cryptsetup de kali serait patché pour utilisé un mode "d'autodestruction" supprimant les clé d'accès, des retours sur les propriétés réel du procéder ? )

Pour finir la liste, je ne me suis pas renseigné sur le sujet avant de vous poser la question, est-il possible de rendre complètement illisible/inrestaurable (à la façon de kali pour le mode autodestruc' ?) une partition ou plusieurs uniquement et le tout en script activable à la volé dans un terminal ?

Pour aider, quelques infos, je peux me casser la tête pendant longtemps pour mettre en place un système robuste, sécurisé et réactive (script/partionnement/etc). Je peux sacrifier les performances pour la sécurité, je peux investire comme dit plus haut, mais je dois absolument pouvoir rester mobile et tout doit tenir sans cable (usb ou micro sd/sdhc (pas possible de mettre un deuxième ssd ou hdd en interne) ).

Une idée que je me suis faite approximativement du partitionnement pour la présentation :
(Une partition par ligne)

_ SDD
- boot
- /, etc, bin, sbin, lib, dev
- root
- media
- mnt
_ RAM
- tmp
- var
_ USB
- opt
- usr
- home
- swap
- data

Voila, qu'en pensez-vous ? Comment optimiser ceci ? Qu'avez-vous à me proposer ? Quel type de file system pour chaque partition ? Avez-vous des questions ?
Merci de prendre du temps à me répondre, j'espère trouver ici des réponses construtives.

A votre clavier !

RestInPeace a écrit :Réservé uniquement pour kali linux 2.0, je souhaite partitionnner au maximum ma configuration
(Une partition par ligne)...

Bonjour,
Quelque chose m'échappe, Kali est une distribution Debian, et tu dis vouloir lui réserver entièrement ton portable.
Quel rapport avec Archlinux ?
En tout cas, fractionner une partition de la façon que tu envisages n'apporte rien en réactivité, au contraire.
Je ne parlerai pas du casse-tête des sauvegardes...

Pour une table de partitionnement ms/dos tu n'as besoin que de 3 partitions :
* Une pour la swap
* Une pour l' OS, montée en /
* Une pour le home, montée en /home

Pour une table GPT il faut rajouter une partition FAT32 montée en /boot/efi.
Après, choisir LUKS, LVM, etc..., tu devrais demander conseil sur le forum de Kali : https://www.kali-linux.fr/forum/

Bonjour waitnsea,

Le partitionnement sous kali Linux n'est pas différent des autres distributions, tout ce que je peux optimiser sur Arch Linux peut être répété sur Kali.

Je ne compte pas faire uniquement trois partitions le plus souvent utilisé pour ceux qui ne cherche pas trop à se prendre la tête, ce n'est pas mon cas. Autant de partition ne peut que améliorer la réactive si on la joue intelligemment sur le type de file system, peut être pas tous.
Merci de votre retour , à vous lire

_ SDD
- /bin est sous Archlinux un lien symbolique vers /usr/bin
- /lib est sous Archlinux un lien symbolique vers /usr/lib
- /sbin est sous Archlinux un lien symbolique vers /usr/bin
- /etc doit être un répertoire de / (tu peux essayer de faire une partition, pour le plaisir de te prendre la tête avec ton initramfs)
- /dev est en mémoire
- root
- media --> Lien vers /run
- mnt --> N'est qu'un répertoire sous lequel on ne fait que monter des partitions (mais chacun fait ce qu'il veut de ce répertoire).
_ USB
- opt
- usr
- home
- swap : as-tu besoin d'un swap ? Si pas d'hibernation et à moins d'avoir des applis ultra-gourmande (style montage vidéo) avec 8 Go de RAM tu n'utiliseras jamais le swap.
- data

Après pour le choix du filesystem je suis convaincu que dans 99.99% des cas l'utilisateur est incapable de sentir une différence entre ext4, btrfs, xfs. Je te laisse lire des benchs pour te faire ton opinion (ou mieux : faire tes propres bench).

Mettre /var en RAM me parait être une belle conn.. ie . Si tu veux administrer ton système il te faut des logs pour comprendre pourquoi ça plante. Et avec /var en RAM, adieu les logs au reboot. Sans compter que pacman stocke toute sa config dans /var (comme un paquet d'applications).
Cela fait des années que les SSD ne sont plus en sucre (dixit @Banjarobin), tu ne vas pas le flinguer et y stockant /var dessus.

Bonsoir oktoberfest,

Merci de ton retour !

- /bin est sous Archlinux un lien symbolique vers /usr/bin
- /lib est sous Archlinux un lien symbolique vers /usr/lib
- /sbin est sous Archlinux un lien symbolique vers /usr/bin

Intéressant ! Merci de cette information, malheureusement sous kali ça ne sera pas utile car ça n'est pas implémenter, mais ça peut très facilement se mettre en place sur kali n'est-ce pas ?

- /etc doit être un répertoire de / (tu peux essayer de faire une partition, pour le plaisir de te prendre la tête avec ton initramfs)

C'est toujours utile selon les configurations de pouvoir les sauvegarder/formater.

- /dev est en mémoire

Pourquoi cela ?

- media --> Lien vers /run

Sur archlinux ou globalement ? Car sur kali ce n'est pas le cas.

- swap : as-tu besoin d'un swap ? Si pas d'hibernation et à moins d'avoir des applis ultra-gourmande (style montage vidéo) avec 8 Go de RAM tu n'utiliseras jamais le swap.

Ca peut toujours servir et c'est pas le si peu de place que ça prend (1G juste pour dire que si y'a débordement je peux prévoir. Avec 8G c'est compliqué^^)

Après pour le choix du filesystem je suis convaincu que dans 99.99% des cas l'utilisateur est incapable de sentir une différence entre ext4, btrfs, xfs. Je te laisse lire des benchs pour te faire ton opinion (ou mieux : faire tes propres bench).

Là, je ne suis pas d'accord avec toi, jouer avec les filesystem ne peut que s'avérer bénéfique, c'est tout, après pour le ressenti, si tu lui demande de lire 10mo ou écrire 10mo m'ouais, si tu lui demandes de compiler, que tu lui demande de trier d'énorme quantité de DATA tu le ressentira si tu pouvais comparer avec un autre ordi identique mais pas optimisé.

Mettre /var en RAM me parait être une belle conn.. ie . Si tu veux administrer ton système il te faut des logs pour comprendre pourquoi ça plante. Et avec /var en RAM, adieu les logs au reboot. Sans compter que pacman stocke toute sa config dans /var (comme un paquet d'applications)

.

Je ne pense pas non plus, c'est plus que conseillé (y'a pas plus rapide que lire/écrire en ram) on peut analyser les logs et selon mot clé sauvegarder ce qu'il y a besoin. Si ça plante, ce qui n'est pas censé arrivé avec des bêtes bien monté, il sera possible de récupérer les informations de la ram. Je n'ai pas pacman donc ça résout le problème et une solution est sûrement envisageable.

Cela fait des années que les SSD ne sont plus en sucre (dixit @Banjarobin), tu ne vas pas le flinguer et y stockant /var dessus.

Ce n'est pas une raison, on cherche ici l'optimisation, ni la facilité ni le déni, c'est pas parce qu'on peut digérer les excréments qu'on les mangent ? C'est pas parce qu'il peut encaisser qu'on peut pas le coucher, etc ...

Je te remercie encore de ton retour, en espérant une réponse de ta part et de la communauté.

- /etc doit être un répertoire de / (tu peux essayer de faire une partition, pour le plaisir de te prendre la tête avec ton initramfs)

C'est toujours utile selon les configurations de pouvoir les sauvegarder/formater.

Le fait que /etc soit séparé ne change en rien la facilité ou la possibilité de la sauvegarder. Sinon je crois qu'aucune distribution ne supporte /etc séparé, après si tu veux tenter une telle chose, libre à toi, mais juste pour information le processus init lit le fichier /etc/fstab pour savoir comment monter les partitions... Si /etc est dans une autre partition que /bin/init cela va être un problème. Problème que tu peux résoudre via un montage au plus tôt dans l'initramfs (non trivial pour un débutant)

- /dev est en mémoire

Pourquoi cela ?

Car c'est comme cela... Ce ne sont que des fichiers "virtuels" généré au boot...

- media --> Lien vers /run

Sur archlinux ou globalement ? Car sur kali ce n'est pas le cas.

Je pense que oktoberfest à fait une erreur sur ce point là... Mais globalement je ne vois vraiment pas l’intérêt de séparer /media, car généralement c'est utilisé pour placer des points de montage statique... donc ce dossier ne possède que des dossiers vides...

- swap : as-tu besoin d'un swap ? Si pas d'hibernation et à moins d'avoir des applis ultra-gourmande (style montage vidéo) avec 8 Go de RAM tu n'utiliseras jamais le swap.

Ca peut toujours servir et c'est pas le si peu de place que ça prend (1G juste pour dire que si y'a débordement je peux prévoir. Avec 8G c'est compliqué^^)

Je ne suis absolument pas d'accord avec ce raisonnement, si tu as une quantité suffisante de mémoire vive et que tu ne veux pas hiberner cela sert à quoi le SWAP ? A part avoir un système ultra lent quand tu seras en manque de mémoire vive (donc inutilisable). Je préfère 1000 fois que le kernel kill l'application qui utilise trop de mémoire (après chacun fait ce qu'il veut, il y a tellement d'autres raisons d'avoir un SWAP)...

Là, je ne suis pas d'accord avec toi, jouer avec les filesystem ne peut que s'avérer bénéfique, c'est tout, après pour le ressenti, si tu lui demande de lire 10mo ou écrire 10mo m'ouais, si tu lui demandes de compiler, que tu lui demande de trier d'énorme quantité de DATA tu le ressentira si tu pouvais comparer avec un autre ordi identique mais pas optimisé.

Alors ici je pense que le choix doit d'abord être fait en fonction des fonctionnalités du filesystem et ensuite en fonction des performances. Choisir btrfs n'a pas vraiment d’intérêt si tu n'utilises pas par exemple le système de snapshots, autant choisir ext4 qui aura de bien meilleur performance.

Mettre /var en RAM me parait être une belle conn.. ie . Si tu veux administrer ton système il te faut des logs pour comprendre pourquoi ça plante. Et avec /var en RAM, adieu les logs au reboot. Sans compter que pacman stocke toute sa config dans /var (comme un paquet d'applications)

Je ne pense pas non plus, c'est plus que conseillé (y'a pas plus rapide que lire/écrire en ram) on peut analyser les logs et selon mot clé sauvegarder ce qu'il y a besoin. Si ça plante, ce qui n'est pas censé arrivé avec des bêtes bien monté, il sera possible de récupérer les informations de la ram. Je n'ai pas pacman donc ça résout le problème et une solution est sûrement envisageable.

C'est bien pire qu'une énorme connerie, c'est même stupide, le système s'attend à ce que les données persistent entre boot, ce n'est pas comme s'il y avait la base de donnée de pacman dedans (un détail...) et ce n'est qu'un exemple, je peux citer la base de donnée mysql, le cache de pacman, la "base de donnée" de dkms pour la compilation des modules kernel, le niveau/volume audio, ...

Bref, et pour les log, si tu ne veux pas les avoir sur disque mais uniquement en mémoire vive, avec systemd tu peux (ce n'est qu'une ligne de configuration), mais tout mettre en mémoire vive pour les logs est juste stupide: perdre les logs de pacman par exemple...

Ce n'est pas une raison, on cherche ici l'optimisation, ni la facilité ni le déni ...

Ce que tu préconises ne pourras que ralentir on système, mettre /var en mémoire vive par exemple rendre juste ton système non opérationnel. Et éviter d'avoir des logs écrit sur le disque me fait bien rire, écrire ~10Mo c'est sûr que cela va mettre à genou ton PC: C'est très très loin d'user ton SSD (mettre un SWAP à bien plus de chance de le faire, et encore dans ce cas tu es loin de l'utiliser au point de le tuer)

Bonjour,

Fais une livechdd à ce niveau lol

Bonjour thejeff35,

Fais une livechdd à ce niveau lol

Merci de ton retour, mais, techniquement, ça revient au même qu'un bon système sans trace.

Bonjour benjarobin !

Merci de ton retour !

Le fait que /etc soit séparé ne change en rien la facilité ou la possibilité de la sauvegarder. Sinon je crois qu'aucune distribution ne supporte /etc séparé, après si tu veux tenter une telle chose, libre à toi, mais juste pour information le processus init lit le fichier /etc/fstab pour savoir comment monter les partitions... Si /etc est dans une autre partition que /bin/init cela va être un problème. Problème que tu peux résoudre via un montage au plus tôt dans l'initramfs (non trivial pour un débutant)

Merci de cette information ! Donc d'apès toi, ce n'est pas utile, ça ne change rien en rien, mise à part que ça complique la chose ? Ca ne me dérange pas de toucher à initramfs, donc si besoin je choisirai la meilleure option.

Car c'est comme cela... Ce ne sont que des fichiers "virtuels" généré au boot...

Merci encore pour cette information, j'ai été me renseigner et effectivement.

Je pense que oktoberfest à fait une erreur sur ce point là... Mais globalement je ne vois vraiment pas l’intérêt de séparer /media, car généralement c'est utilisé pour placer des points de montage statique... donc ce dossier ne possède que des dossiers vides...

Il me semble (arrête moi si je me trompe), c'est mnt qui à été principalement conçu pour du statique, media la détrôné mais est en théorie le point de montage des périphériques temporaire non ?

Je ne suis absolument pas d'accord avec ce raisonnement, si tu as une quantité suffisante de mémoire vive et que tu ne veux pas hiberner cela sert à quoi le SWAP ? A part avoir un système ultra lent quand tu seras en manque de mémoire vive (donc inutilisable). Je préfère 1000 fois que le kernel kill l'application qui utilise trop de mémoire (après chacun fait ce qu'il veut, il y a tellement d'autres raisons d'avoir un SWAP)...

Je ne suis qu'à moitié d'accord avec toi, avoir un swap est une sécurité, il n'est pas forcément plus lent si il est sur un bon ssd (ce qui ne sera pas le cas ici, certes.). Ceci dit, en cas de pépin non prévu, on ne peut pas penser à tout... Il sera possible de rattraper le problème avant qu'il ne soit trop tard. Kill l'application est une bonne idée à mettre en place, mais ça aussi, ce n'est qu'une sécurité, pour moi 1 + 1 = 2, c'est mieux que 1 tout seul non ?

Alors ici je pense que le choix doit d'abord être fait en fonction des fonctionnalités du filesystem et ensuite en fonction des performances. Choisir btrfs n'a pas vraiment d’intérêt si tu n'utilises pas par exemple le système de snapshots, autant choisir ext4 qui aura de bien meilleur performance.

C'est là où j'ai besoin de vos conseils, de vos expériences pour en débattre avec vous selon mon utilisation.

C'est bien pire qu'une énorme connerie, c'est même stupide, le système s'attend à ce que les données persistent entre boot, ce n'est pas comme s'il y avait la base de donnée de pacman dedans (un détail...) et ce n'est qu'un exemple, je peux citer la base de donnée mysql, le cache de pacman, la "base de donnée" de dkms pour la compilation des modules kernel, le niveau/volume audio, ...


Bref, et pour les log, si tu ne veux pas les avoir sur disque mais uniquement en mémoire vive, avec systemd tu peux (ce n'est qu'une ligne de configuration), mais tout mettre en mémoire vive pour les logs est juste stupide: perdre les logs de pacman par exemple...

Il est possible de sauvegarder les fichiers importants e(donc bdd / log ) avant l'extinction ça résous donc le problème non ? Voir laisser quelques dossiers important de var sur le ssd ?


Merci encore pour tes réponses, en attente d'autres retours, merci

Clairement toucher à l'initramfs pour /etc est une très très mauvaise idée.

C'est /run/media pour les périphériques temporaires. /media (n'existe pas par défaut sur Arch Linux), possède le même rôle que /mnt, mais j'ai gardé l'habitude de mettre mes points de montages statiques dans /media.

Pour le SWAP si ton but c'est juste une simple sécurité, n'utilise pas de SWAP, cela ne changera rien (au niveau sécurité / stabilité du système), surtout si tu as un SWAP rapide. Pour rappel quand il n'y a plus assez de mémoire vive, le kernel kill une application plus ou moins au hasard (dépend d'un algorithme interne), Windows fait de même...

Tous les fichiers de /var sont importants, ils ne sont pas là pour faire "jolie". Sinon je ne suis pas ton raisonnement, quel est l’intérêt de sauvegarder et restaurer les fichiers de /var à chaque démarrage, quel est ton but ? Ce n'était pas pour éviter des lectures/écritures sur disque ? Sinon pour information mon /var fait 800Mo et il n'y a que 140 Mo de log dans le tas (j'ai configuré la taille maximal du log systemd pour 128Mo)

Bonjour benjarobin !

Merci d'avoir encore répondu !

Clairement toucher à l'initramfs pour /etc est une très très mauvaise idée.

Peux-tu être plus précis s'il te plaît ? Si tu sais ce que tu fais et que c'est susceptible de fonctionner pourquoi ne pas le faire ? Après effectivement, si ça sert vraiment à rien...

C'est /run/media pour les périphériques temporaires. /media (n'existe pas par défaut sur Arch Linux), possède le même rôle que /mnt, mais j'ai gardé l'habitude de mettre mes points de montages statiques dans /media.

Merci pour l'information !

Pour le SWAP si ton but c'est juste une simple sécurité, n'utilise pas de SWAP, cela ne changera rien (au niveau sécurité / stabilité du système), surtout si tu as un SWAP rapide. Pour rappel quand il n'y a plus assez de mémoire vive, le kernel kill une application plus ou moins au hasard (dépend d'un algorithme interne), Windows fait de même...

Peut-être est-il possible que l'app' killed ne me convienne pas, peut-être dev' un script qui s'active avant celui du kernel pour "choisir" ceux qui peuvent être kill non? Peut-être est-il possible de surcharger la ram et contourner la protection du kernel ? La une sécurité supplément serait essentiel (swap) non ?

Tous les fichiers de /var sont importants, ils ne sont pas là pour faire "jolie". Sinon je ne suis pas ton raisonnement, quel est l’intérêt de sauvegarder et restaurer les fichiers de /var à chaque démarrage, quel est ton but ? Ce n'était pas pour éviter des lectures/écritures sur disque ? Sinon pour information mon /var fait 800Mo et il n'y a que 140 Mo de log dans le tas (j'ai configuré la taille maximal du log systemd pour 128Mo)

Si, maintenant que tu le dis c'est vrai c'est complètement con, mais, les données ne seront techniquement écrites que deux fois sur le disque dur pendant un usage, au lieu de plusieurs fois si c'était directement sur le ssd, de plus seulement ce qui aura changé sera sauvegardé sur le disque dur, donc si rien ne change, rien ne s'enregistre, rien n'est copié vu que tout est déjà présent sur le ssd, mon raisonnement est-il bon ?
Merci de tes réponses, en attente de complément d'informations.

Déplacer /etc n'apporte rien de plus, à part des ennuis...
Sinon pour /var ton raisonnement est bon (si j'ai bien compris)

Bonsoir benjarobin, merci d'avoir répondu,

Bien, je te remercie de ton temps, si tu as d'autres informations, conseils ou autres, je suis preneur