Valdes

  • 24 sept. 2023
  • Inscrit 4 sept. 2007
  • 0 meilleure réponse
  • Petit nouveau Adepte du forum Posteur fou Rédacteur potentiel
  • Pour information, tu as acheté un onduleur "off-line", ce qui veut dire qu'il ne filtre pas la tension qui le traverse (sauf, selon le constructeur, les surtensions). Il va basculer sur la batterie lorsqu'il détectera une chute de tension, ce qui va impliquer un temps de latence de quelques ms (ce qui ne devrait pas éteindre ton PC mais peut quand même éteindre d'autre trucs que tu aurais branché dessus, le cas échéant).

    Si ta ligne a des soucis comme tu le dis, ce n'est peut-être pas l'onduleur le plus adapté étant donné que les sous-tensions ne seront pas corrigées (ni les parasites sur la ligne).

    Pour une protection maximale il y a les onduleurs "on-line" qui alimentent ton matériel directement depuis la batterie (et la batterie est branchée à la ligne). Le signal électrique qui sort de ton onduleur est donc quasi-parfait et totalement insensible aux perturbations ainsi qu'à toutes les formes de coupures. En revanche, c'est plus cher.

    J'arrive un peu après la guerre mais ça me semblait utile de le préciser 🙂

    Par contre, ça m'intéresserait de savoir si tu as encore des coupures avec ton onduleur (savoir s'il réagit assez vite pour ton PC et par exemple une lampe). Je me suis toujours tâté à en acheter un par sécurité mais le prix m'a toujours refroidi et je ne sais pas vraiment ce que ça vaut...
  • Justement, je déploie ma conf via Ansible. J'ai un role "common" qui déploie ma zone publique partout et certains rôles qui déploient des services sur certaines machines. Je ne peux donc pas écraser dans chaque rôle le fichier de zone ; avoir un firewalld qui se base sur la présence ou non de fichiers pour activer des services serait donc bien plus pratique (et propre) (un fichier de zone commun à tous et des services en plus selon les machines).

    Mais tant pis, je vais utiliser le module firewalld d'Ansible pour activer à la volée les services requis dans chaque rôle et garder une zone publique commune à tous.

    Merci !
  • Hello,

    Non tu as mal compris je pense : je veux déclarer de nouveaux services et faire en sorte que firewalld les détecte et les active, sans passer par firewall-cmd. Comme par exemple tu pourrais dropper une conf Nginx / Apache dans son conf.d et reload le service pour qu'il détecte les changements.

    Là je dois mettre ces services dans /etc/firewalld/services ET écrire en dur dans le fichier de zone que je veux les activer.
    Je parle d'une utilisation serveur de Fedora bien entendu.

    Si c'est pas possible c'est pas grave, c'est juste que je n'arrive pas à trouver si c'est possible ou pas.
  • Hello,

    Ptin ça faisait un moment que j'étais plus venu ici ! Ça fait plaisir de voir que certains anciens sont toujours là 🙂

    Bref, je cherche un moyen de faire ouvrir des services à firewalld à travers des fichiers de service selon leur présence. Par exemple, je veux que sur telle machine le FTP soit ouvert : je pose ftp.xml dans /etc/firewalld/services, je reload le daemon et le tour est joué. Là je ne peux pas étant donné qu'il faut également que j'ajoute un tag <service> dans ma zone public.xml (et j'ai pas envie de toucher aux fichiers de zones).

    Je ne sais pas du tout si ce que je cherche à faire est faisable, mais je n'arrive pas à trouver de doc sur ça sur les Internets (d'ailleurs la doc de firewalld de manière générale n'est pas super claire je trouve).
    Si vous avez des idées, je suis preneur !

    Merci.
  • Je ne connaissais pas zed, mais je dois avouer que je préfère utiliser tar + gzip / xz + openssl / gpg plutôt qu'un seul truc qui fait tout et on sait pas comment (en plus avec zed t'es bloqué en AES-CBC...).
  • [root@pc-47 ~]# dnf whatprovides 'libhttp_parser*'
    Last metadata expiration check: 1:52:30 ago on Fri Sep 29 08:40:51 2017.
    http-parser-2.7.1-3.fc24.x86_64 : HTTP request/response parser for C
    Repo        : @System
    
    http-parser-2.7.1-3.fc24.i686 : HTTP request/response parser for C
    Repo        : updates
    
    http-parser-2.7.1-3.fc24.x86_64 : HTTP request/response parser for C
    Repo        : updates
    
    http-parser-2.6.0-2.fc24.i686 : HTTP request/response parser for C
    Repo        : fedora
    
    http-parser-2.6.0-2.fc24.x86_64 : HTTP request/response parser for C
    Repo        : fedora
    
    T'as installé l'une de ces libs ?
  • Hello,
    Edouard_le_homard wrote:Je mets / et /boot sur le SSD, et /tmp /var /home et swap sur le HDD ; c'est bien le mieux à faire ? Pour /boot, je mets 2 ou 3 Go ?
    Pourquoi /tmp et /var ? Si /tmp est sur HDD, tous les programmes seront ralentis lors des accès disques (et /tmp sert justement à mettre plein de bazar du runtime). Si l'argument c'est "pour pas user le SSD", c'est pas du tout une raison valable. Les SSD récents ont des MTBF largement suffisantes pour mettre tout dessus (y compris la swap, mais quand tu tapes dans la swap c'est qu'il y a un problème, donc autant la laisser sur le HDD).
    Donc en gros : mets tout sur ton SSD, sauf ce qui prend de la place (genre /home). Et encore, t'as plein de fichiers de conf et de tmp dans ton /home, donc le plus performant c'est de mettre /home sur ton SSD et un sous-dossier (dans lequel tu vas stocker ton gros bordel) sur le HDD. Mais bon c'est chiant à faire donc en général /home => HDD.

    Par contre, oublie pas de dire à ton kernel de swapper le moins possible (ça sert à rien de swapper, ça rame ; t'as de la RAM, autant t'en servir) : voir doc
    Edouard_le_homard wrote:Est-il nécessaire de mettre en place un LVM ? comment fait-on dans pour l'install a proprement parler ? J'imagine qu'il faut aller dans partitionnement personnalisé ?
    Non pas nécessaire, c'est comme tu veux.
    Edouard_le_homard wrote:Est-ce 64go pour le SSD c'es suffisant ? ou trop large au contraire ? je n'ai pas envie de me ruiner à acheter un disque que je ne vais utiliser qu'à 10%... par contre je suis preneur de conseils pour acheter un SSD de bonne qualité.
    Si c'est que pour le système et les applis, oui ça suffit.
    Par contre, il vaut mieux un gros SSD plus cher mais utilisé à 40% qu'un petit SSD moins cher mais utilisé à 80%. Plus y'a de place libre, plus le SSD peut répartir les données entre les blocs mémoire et du coup il va moins les user => ton SSD va durer plus longtemps.

    Pour la marque de SSD, j'ai un OCZ Vertex 3 depuis des années et j'ai eu juste un problème une fois, pris dans la garantie. Les Intel sont moins performants (sur le papier) mais plus fiables (et plus cher en général aussi je crois). Celui que t'as mis en lien semble bien.

    ++
  • Les VPN / Tor / whatever ne vont que masquer ton IP perso. Ils ne vont en aucun cas masquer les informations que ton navigateur offre à tout site Internet (version, OS, langage, informations sur l'écran via Javascript, ...).
    Pour ça, tu auras besoin d'un proxy qui ira faire les requêtes HTTP à ta place (et donc le site de destination ne verra que le navigateur du proxy).
    Sauf que du coup, le mec qui tient le proxy verra absolument tout ton trafic Internet.

    Donc il te faudrait un VPN + proxy, le tout administré par tes soins sur un serveur dédié afin que tu sois le seul à maîtriser les infos qui passent par lui.

    C'est quoi le but ? Juste cacher les informations sans intérêt que tout le monde fournit sur Internet ? Aucune utilité. Tout le monde s'en tape de ta résolution d'écran. Quand tu sors dans la rue, tout le monde voit ta couleur de peau, ta taille, ton sexe, ton âge approximatif... Tu te caches pour autant ?
    Tu as peur que les gens voient ton adresse IP ? Quand tu donnes ton adresse postale à quelqu'un, le problème est le même. De toutes façons, les pirates n'ont pas besoin que tu leur donne ton IP, ils la scannent tous seuls.

    Être anonyme sur Internet sans être son propre FAI, c'est impossible. Ton FAI sait déjà tout de toi (où tu vas, quand tu y vas, ce que tu y fais...). Ça m'étonnerait que ça soit totalement surveillé, mais c'est tout à fait possible.

    En revanche, tu n'es pas obligé de fournir des informations sur toi à des entreprises comme Facebook, Google & Cie.

    Évidemment que c'est mieux d'essayer de protéger sa vie privée autant que possible, mais dans ce cas là c'est toute l'utilisation d'Internet qu'il faut revoir, pas juste ton User Agent.
  • Non mais là tu confonds tout. Ceci est ma dernière tentative, après j'abandonne.
    Eric L. wrote:- TRIM n'est pas inutile, au contraire, mais les problèmes qui pouvaient survenir en utilisant LUKS (raison pour laquelle j'avais placé un lien vers l'article How to properly activate TRIM for your SSD on Linux: fstrim, lvm and dm-crypt, http://tinyurl.com/cxptkh8) n'existent plus lorsque le chiffrement est matériel.
    Oui, pour la n-ième fois, lorsque le chiffrement est matériel, l'OS n'a même pas conscience du chiffrement sous-jacent. Par conséquent, il n'y a aucun paramètre spécial à préciser (que ce soit pour le TRIM ou pour autre chose) justement parce que le disque se comporte exactement comme un disque normal du point de vue OS / système de fichiers.
    Eric L. wrote:- l'article vers lequel tu renvoyais explicitait ledit blabla (voir aussi le paragraphe How is the access to the drive secured to allow only the Authorized user to access it? Is there a boot- up password that is entered via a BIOS dialog?, vers lequel renvoyais le lien placé dans mon premier message, http://tinyurl.com/c7pzn6e).
    Oui, le disque demande à l'utilisateur de s'identifier pour pouvoir y accéder. Je vois pas le rapport avec un "logiciel installé en lecture-seule". La première chose que le disque répond au BIOS / UEFI, c'est "Identifie-toi". Ton "logiciel en lecture-seule", c'est le BIOS / UEFI.
    Eric L. wrote:- la raison pour laquelle Crucial demande d'utiliser BitLocker Windows 8, c'est que c'est l'OS qui active le chiffrement matériel des données (mode de sécurité) et qui gère la clé d'accès (voir ce fil de discussion sur le forum Crucial : http://tinyurl.com/o8u5eto), pas le BIOS/UEFI.
    Oui, BitLocker (ou n'importe quel soft de chiffrement) est capable de stocker de manière chiffré des datas même si le disque est déjà chiffré en dessous. L'avantage de BitLocker sous Windows, à priori, c'est qu'il est capable de savoir si le disque est chiffré matériellement en dessous et de ne pas re-chiffrer logiciellement par dessus. Comme l'auteur explique, pour avoir son boot sur une partition chiffrée, il faut que le BIOS / UEFI soit compatible. Sinon, il est toujours possible de faire une partition chiffrée matériellement et faire en sorte que BitLocker la débloque au démarrage (mais pour cela il faut que l'OS soit démarré ; la partition en question est donc une partition de données standard - comprendre : pas l'OS).
    Eric L. wrote:De nombreux textes (dont l'échange du forum Crucial cité ci-dessus) confirment l'incapacité de pouvoir utiliser conjointement GNU/Linux et le chiffrement matériel (SED).

    Mais je n'ai pas trouvé de publications, postérieures à avril 2014, confirmant cette impossibilité .
    Pas du tout, mon Vertex 3 est chiffré matériellement depuis mon BIOS. Au boot, mon BIOS me demande le mot de passe, sinon je ne peux pas y accéder. C'est juste que Linux n'a aucun moyen de savoir si le disque est chiffré matériellement ou pas.
    Eric L. wrote:Sachant que Red Hat (enfin « David Howells, un développeur de Red Hat qui travaille sur le noyau Linux ») s'était déjà attiré les foudres de Linus Torvald pour avoir été le premier à proposer « d’intégrer un patch au Kernel permettant d’ajouter des clés dynamiquement afin que toutes les distributions Linux puissent prendre en charge le Secure Boot » (http://tinyurl.com/bro8v3v), j'avais l'espoir que des solutions existent, dont Fedora 21 aurait pu bénéficier.
    Alors ça, ça n'a strictement rien à voir avec le chiffrement du disque. Le principe du Secure Boot, c'est juste de signer la partition de boot afin qu'un malware ne puisse pas la modifier discrètement. Ça ne garantit rien d'autre.
    Eric L. wrote:En même temps, s'il se confirme que les technologies de sécurité (UEFI, chiffrement matériel) ferment la porte à GNU/Linux en obligeant l'utilisation de solutions propriétaires mais que certaines distributions s'engouffrent dans la brèche pour répondre aux besoins exprimés (ici et ailleurs)... cela confirmerait les craintes exprimées par Linux Torvald, il y a plus d'un an et demi (https://lkml.org/lkml/2013/2/21/196).
    Pareil, rien à voir avec le chiffrement du disque, ça parle de Secure Boot.
  • @anche : tu confonds chiffrement logiciel et chiffrement matériel. Avec du chiffrement logiciel (LUKS), ton noyau boote, te demande la clé pour déchiffrer les partitions chiffrées, les déchiffre et continue l'amorçage. Avec du chiffrement matériel, ton OS n'est même pas au courant qu'il est sur un disque chiffré. L'intégralité du disque est chiffré, le disque est déchiffré au moment du démarrage (donc avant même de pouvoir ne serait-ce que lire la table d'allocation). Ton BIOS/UEFI doit donc être en mesure de demander au disque de se déchiffrer avant de pouvoir lancer quoi que ce soit dessus.

    @eric L. : soit j'ai mal lu l'article, soit il n'est à aucun moment question de l'inutilité du TRIM avec un disque chiffré (logiciellement ou matériellement). Dans tous les cas ton FS doit faire savoir à ton disque qu'il n'utilise plus certains blocs du SSD afin qu'il puisse les flusher.
    Concernant le "logiciel installé en lecture seule qui se trouve sur le disque caché monté blabla", je vois pas de quoi tu parles. À moins que tu parles d'un chiffrement logiciel de type LUKS, auquel cas ce "logiciel", c'est le noyau. Mais il me semblait que tu t'intéressais davantage au chiffrement matériel.
  • Non c'était très clair comme question, pour peu que l'on connaisse les rudiments de l'informatique et de la cryptographie.

    À priori, tu n'as pas besoin de faire quoi que ce soit, le disque, par défaut, va chiffrer tout ce qu'il stocke avec une clé qu'il possède.
    Si maintenant tu veux totalement sécuriser ton système, tu dois fournir au disque un mot de passe avec lequel il va chiffrer cette clé (elle sera donc illisible pour un éventuel hacker, tout autant que les données sur le disque). En revanche, étant donné que le chiffrement se fait au niveau physique, ta machine doit connaître le mot de passe de la clé avant même de pouvoir booter (sinon il ne peut pas déchiffrer ce qu'il doit booter...). Cette configuration se fait dans le BIOS/UEFI, l'OS n'intervient à aucun moment dans le process.
    Il est possible que tous les BIOS/UEFI ne supportent pas cette fonctionnalité, notamment ceux intégrés dans le matériel grand public.

    Plus d'infos ici.

    Ceci dit, même si ton disque est totalement chiffré, il suffit qu'un virus ait accès à ta machine pour pouvoir récupérer toutes les données du disque (une fois l'OS lancé, le disque est vu comme non chiffré - de la même manière qu'un chiffrement de type LUKS).

    Quel est le besoin ?
  • Ça veut dire quoi "faire carrière dans le libre" ?
  • Ok merci pour les infos, je vais passer mon tour alors. Je vais rester sur les bonnes vieilles Fedup, surtout que le rythme d'un an maintenant est plus simple à suivre.
  • Tiens je profite qu'on parle de la rawhide pour squatter le fil (juste une question 🙂) : est-ce que c'est stable ? Ça peut être utilisé comme distro de tous les jours ou ça risque vraiment péter à tout moment ?

    Ce qui m'intéressait serait d'avoir une version mise à jour en permanence, plus la peine de faire de Fedup ou de réinstallation complète.
  • Ça marche pas probablement parce que pour faire écouter openssh-server sur plusieurs ports, la syntaxe est la suivante :
    Port 22
    Port 443
    Ceci dit, c'est pas franchement une bonne idée de faire écouter openssh-server sur le port par défaut du HTTPS, ou, de manière générale, sur un port connu qui n'a rien à voir. Un peu de cohérence et d'homogénéité n'a jamais fait de mal.
  • Non il ne faut pas être développeur pour utiliser Fedora.

    Et tes disques meurent car ils sont probablement trop vieux. Fedora gère très bien les disques, qu'ils soient HDD ou SSD.

    De toutes façons, c'est toujours une bonne idée de tester autre chose parfois. Fais-toi des Live USB/CD d'Ubuntu ou Mint pour voir si ça te plaît pas plus que Fedora. T'as rien signé quand t'as installé Fedora y'a des années, tu peux aller voir ailleurs sans scrupules. Et si ça se trouve, au final, tu reviendra sur Fedora encore plus convaincu qu'avant 😉
  • destonio wrote:Oui mais comment le lire, on dirait qu'il est crypté. Je le trouve dans /var/log/journal/system.journal mais libreoffice m'ouvre des dizaines de ##
    Ouais enfin ouvrir un journal système avec LibreOffice c'est aussi la pire idée de la terre.
    Il va falloir mettre les mains dans la console et apprendre à utiliser less ou vim (ou pour le coup journalctl vu que ce journal est en binaire).
  • pierrotlalune wrote:Bonjour Valdes,
    [...]
    Merci à toi.
    pll
    De rien. Content de voir que des vieux posts d'un an servent encore 😉
  • $ for file in *.mp3; do iconv -f UTF-16 -t UTF-8 -o $file_utf8 $file; done
    Mais iconv sait ne traiter que la partie "tag" du fichier et ne pas toucher à la data ?
  • Le modèle c'est pas important, si c'est pas la même techno tu pourras pas les installer de toutes façons (y'a des détrompeurs). Au pire, tu vas mettre une barrette un peu nulle qui va "ralentir" les autres. Mais je doute que la quête de la performance absolue soit ton objectif.
    Sinon, si t'as la place, mets tout ! Il vaut mieux trop que pas assez.