Raphaël G. a écrit 1927 commentaires

Je pensais avoir choisi mes mots avec soin.

Les personnes qui ont un usage réellement utile de SELinux me semblent aussi nombreuses que les militaires dans la population générale, soit une proportion congrue.

Tu sembles considérer que tout le monde à le besoin d'avoir de multiples couches de sécurité et durcir tous les couches, ce n'est généralement pas le cas dans la vrai vie…

Je n'ai jamais dis que SELinux était moins puissant que les acls.

Je pense avoir voulu dire que dans 99% des cas, les acls suffisent.

Pour une application web par exemple et ça va se borner à des bons vieux :
setfacl -m u:apache:rwX vers/le/cache
setfacl -m u:apache:r /etc/app.conf

Quel intérêt d'aller explique que php peut rien exécuter dans vers/le/cache, tu peux très bien configurer apache-mod_php en collant un RemoveType .php sur le répertoire qui suffira largement.

Passé un temps SELinux marchait même pas sur XFS par défaut, fallait changer la taille par défaut de l'inode de 128 à 512 à la création du filesystem…

Me moinsez pas s'il vous plait :)

Sinon il est peut-être l'heure de donner votre coup de main à la finalisation de la Mageia 8 qui est en cours.

Vous aurez ainsi une distribution flambant neuve pour tous les usages dont vous rêviez, du franco-français à la base et soutenu par une équipe internationale de compétition ^_^

Pour contribuer c'est par ici :
https://www.mageia.org/

Perso j'ai mon accès contributeur depuis des lustres et je fixe tout ce qui me va pas chaque fois que je suis assez énervémotivé et ça fait une super distribution.

Big up à ennael et les autres sans qui ce projet n'aurait jamais existé :)

L'organisation en rpm c'est un fichier spec qui fait toute la procédure de génération du paquet.

Au final ça se résume à avoir le tar.gz/bz2/xz + fichiers patch dans SOURCES et le fichier .spec dans SPECS.

Pour ce qui est des fichiers debians, c'est un peu la fête du slip, t'as le fichier source, auquel est appliqué un patch tar.* qui pose un répertoire debian avec tout un tas de chose dedans.

Je suis pas objectif, je package pour Mageia, mais le format debian, je n'y vois vraiment aucun avantage, même maintenant…

Le seul "défaut" du rpm, c'est qu'on a besoin d'un système de gestion de dépendance qui n'est pas fourni par rpm, mais urpmi/dnf/yum/yast/up2date/etc…

Si on regarde côté debian, de toute façon, personne installe un .deb à coup de dkpg -i, au final apt-get update & apt-get install ça revient bien au urpmi.update -a & urpmi.

Franchement SELinux c'est un peu de la sodomisation intellectuelle…

J'ai eu a subir ça chez un employeur, il faut deviner une partie des accès parce que ça ne remonte pas une partie des accès à des ressources de manière explicite et tout le monde trouve ça normal…

C'est vraiment limité au cas de figure où tu mets en place une application ou service en qui tu as pas confiance, si t'as la maîtrise de ce que tu mets en place ça a ZÉRO intérêt à mon avis.

Sur n'importe quelle distribution de base normale (Mageia, Fedora, *Rpm, *Deb, etc) t'as accès aux droits unix et éventuellement aux acls et franchement ça suffit largement dans la plupart des cas.

Ils ont aussi passé les patchs du kernel en un patch fusionné à cause des pompeurs à sens unique de oracle unbreakable linux qui avait tendance à un peu trop faire du copié/collé à pas cher et oublier la partie contribuer en retour…

L'api interne entre php5 et php7 n'est pas compatible et demande de gros changements comme passer une majorité de paramètres par référence, des macros qui changent, etc…

Pour porter une vieille extension pour php7, c'est juste une galère, faut que je m'y remette d'ailleurs.

Autant la documentation utilisateur final php est un modèle sur lequel tous les autres langages pourraient copier les yeux fermés.

Pour ce qui est de la documentation de l'api interne, c'est franchement ni fait, ni à faire.
Pour trouver des informations sur certains fonctionnalités tu dois parfois dégainer archives.org ou le cache d'un moteur de recherche.

Oui, tout à fait.

C'est pour cela qu'on reçois du démarchage téléphonique comme par magie pour te fournir une mutuelle santé ou le bilan économie énergie juste après que tu soit inscrit chez eux.

Démarcheurs téléphoniques indélicats qui refusent bien sur de fournir où ils ont récupéré ton numéro et raccrochent en totale violation de la loi…

Il y a des fois, où on se demande si c'est de l'incompétence. Ou s'ils ont plus que moins discrètement fourni à la NSA des portes d'entrée béantes pour de nombreuses années en toute connaissance de cause…

Il ne reste qu'à le monter sur une carte au format Arduino et à l'intégrer dans l'IDE du même nom. À quand le financement participatif ?

J'attends avec impatience le lancement d'une telle campagne de financement ;)

Je sais que ce n'est sans doute pas la même chose, mais entre 20k€ et 1€24 (frais de port compris chez JIAQISHENG) la carte finie avec un STM32F103C8T6, c'est un peu dur l'équation économique du matériel libre…

Je sais très bien que ali le rapide chinois est sponsorisé au niveau transport par le parti communiste chinois qui ne nous fais pas payer le vrai prix, mais au vu des ordres de grandeur, ça fait un peu suicide économique…

Je ne mets pas le lien pour ne pas faire de pub déloyale à ce beau projet :)

En Python, Node.js, Ruby, Go, Rust on a pip, npm, gem, go-get, cargo qui simplifie le téléchargement des dépendances, et l’intégration au projet avec un import xxxx. De plus, certains IDE prennent en charge cette gestion des dépendances.

Tu nous cites ça comme de super outil, j'ai une autre vision de la chose.

Ces outils dépendent d'un site internet (piratable), qui va tirer tout un tas de dépendances sans aucun contrôle de ta part.

Il y a déjà eu des exemples où un type t'explique qu'il a ajouté une porte dérobée dans une super librairie de coloration utilisée par plein de monde.

Un système de packaging qui marche, c'est celui de ta distribution ou faut pas hésiter à remonter un patch.

urpmi lib(64)machin(_version)-devel ou yum install lib(64)machin-dev(el?) ou apt-get install lib(64)machin-dev

Comme ça, tu as un suivi de dépendance, la livraison de correctifs de sécurité si le contributeur fait sa veille correctement et le reste. Modulo une compatibilité d'abi de mémoire, tout ça…

Tout ça c'est sans compter sur les temps de déploiement.

Si on prends un exemple PHP, comme cette bouse de composer.

Quand tu veux déployer ton projet, il faut que le site liant projet et adresse de dépôt fonctionne, que TOUS les dépôts git répondent et seulement à la fin ton projet sera prêt à être déployé.

Pour avoir codé une version Perl pour déployer du symfony en prod sans passé par composer, mon code faisait le déploiement en une trentaine de secondes modulo les temps de réponse des dépôts, composer de son côté c'était minimum 5 minutes…

Pour résumer, ces nouveaux outils de gestion de dépendance de nouveaux langages, c'est des catastrophes, codées par des développeurs qui n'ont pas trempé dans la gestion de dépendance des distribution linux. Ils ré-inventent très souvent la roue en codant avec les pieds (et/ou en dépit du bon sens), ajoute une passoire niveau sécurité et des gros SPOF (single point of failure ou point unique de défaillance).

Donc se mettre une dépendance sur ces bouses quand c'est pour un projet perso, pourquoi pas.

Dépendre d'un truc pas fiable quand on a un client à livrer en temps contraint c'est une connerie.

Packager la librairie dans ta distribution t'aurait pris beaucoup moins de temps que ça au final et ça ne t'exploses pas à la figure au moment où tu dois livrer un correctif en urgence ou de sécurité.

Un grand merci pour les pierres d'angles et tous les petits cailloux apportés à l'édifice de la grande cathédrale du logiciel libre au côté de tous ces contributeurs connus ou anonymes.

Repose en paix.

Merci Marja, Ysabeau et tous les autres.

A mon modeste niveau ce que j'aime dans mageia c'est d'avoir un accès contributeur sur la cauldron (version de développement), quand un bug m'a gavé depuis (bien) trop longtemps, l'ouverture de la chasse au bug c'est sympa.

J'ai la possibilité de le fixer et remonter ça dans la distribution, même en maj en suivant une procédure un peu pénible, mais qui se justifie, sécurité tout ça…

Je suis pas super actif, mais pouvoir apporter sa pierre quand on peut ça n'a pas de prix :)

Merci pour ce super projet inclusif et aux contributeurs du cœur (kernel, glibc, gcc, …) bien plus assidus que moi ;)

Et dire que cette alchimie a commencée sous mandrake durant mes années étudiantes en 2003-2004.

Spéciale dédicace à Ennael qui a porté ce projet à bras le corps et réussi son lancement au fosdem à Bruxelles il y a quelques années déjà :)
(ce petit moment de bonheur restera à jamais gravé, même si j'ai oublié l'année)

J'ai une MSI vega rx 64 depuis sa sortie sur un FX8370E. J'ai du attendre que le pilote soit inclus par défaut dans le noyau pour que ça marche directement sur ma Mageia, soit kernel linux 4.15 de mémoire.

Au niveau bruit, tout ça je sais pas trop, j'ai collé un watercooling dessus (D5/360). Sous linux ça chauffe jamais vraiment, la pompe et les ventilateurs en pwm restent au minimum même en regardant des vidéos sur smplayer/chrome. Idem en code.

Faudrait que je teste la montée en température quand X4 foundations sera disponible.

Sous plateforme propriétaire ça change, en jeu un peu de cold noise des condensateurs céramique qui vibrent et ça se transforme en bon chauffage sur le jeu.

Jamais eu vraiment de bugs majeurs, très content de cette carte sous linux.

Avant j'avais eu une 6870, ça avait marché directement quand je l'ai eu. Au début il y avait un script de phoronix pour patcher le binaire pour enlever un tatouage "carte non supportée" sur le rendu à l'écran. Tout marchait parfaitement en dehors de ça.

Bref, aucun regret de fendre la tirelire pour prendre des cartes graphiques et processeurs chez amd qui a vraiment fait l'effort de faire marcher leurs produits sous linux avec du driver libre !

Quand ton frigo est vide, ils changent d'offres comme les autres, les gilets jaunes pauvres.

Perso, je suis passé en Miséricable à 10€/mois.

Ils ont remboursés que 3 mois au lieu d'un an qui aurait du l'être, pas d'ipv6, j'utilise pas leurs dns menteurs et je redémarre la box quand ça pédale dans la semoule.

Au final pour avoir juste de l'internet à pas cher, c'est pas trop mal.
(2 pannes dont une de 15j en 2ans)

L'ipv4 semble fixe, pas eu de changement, même après plusieurs redémarrage de la box depuis au moins 1 an.

T'as aucune excuse, le seul rôle du pôle informatique est d'apprendre à l'étudiant à les contourner !!! (et lire man ssh, redirection de port et le réseau par effet de bord)

La première chose apprise en IUT a été de monter un tunnel SSH sur un proxy à la maison pour avoir de l'internet dans les salles de classes quand c'était bloqué.

L'admin s'en est rendu compte et a laissé en place son PALC (proxy à la con) contournable, pour lui si on arrive à le contourner c'est qu'on a appris ce qu'il fallait apprendre de réseau dans l'IUT.

Beaucoup de logiciels utilisent le .NET Framework (2.0, 4.0, 4.5, 4.6, 4.7, à ce jour), DirectX
(1/2/4/5/6/7/8/9/10/11/12), le runtime MSVC (beaucoup trop de versions), les API du kernel (kernel32, …),
les API de User32.dll (du genre LoadIcon, ou pour lire/écrire dans le presse-papier, parmi beaucoup
d'autres fonctions), et j'en passe.

Sous windows, ça choque personne la place disque bouffée par toutes les versions du framework .Net, directX et consort ?

Pour avoir voulu toucher un peu au monde du dev sous windows, c'est juste un enfer sans nom…

Sous un linux, tu vas installer les paquets lib64xyz-devel, la lib64xyzXYZ qui va avec, tu compiles et c'est mare.

Et le pire c'est que les librairies de développements ne sont pas les mêmes que celles redistribuables.
Donc si tu fais pas attention tu te retrouves avec des dépendances sur les version debug des dll, qui sont pas disponibles sans installer des Go de l'environnement de développement. Et le pire dans tout ça c'est le packaging des derniers compilateurs MSVC qui forcent à installer tout l'environnement de développement.

Au final ça m'a pris moins de place de monter une vm virtualbox, un environnement de développement linux complet que d'installer l'environnement sur windows…

Sur mageia, de quel paquet s'agissait-il ?

Si tu as un peu de temps, je t'invite à créer un compte et demander à être mainteneur de ton paquet, tu seras le bienvenu :)

Je suis contributeur depuis un bon moment, le principal problème, c'est de trouver le temps de s'occuper de ses paquets favoris, les journées n'ont que 24h :p

Et ils vivent 10 ans de moins que les européens en moyenne avec leur super système qui leur coûte deux fois plus cher de mémoire. Voir le documentaire de Michael Moore sur le sujet.

Ce qui m'embête c'est que soit t'as un vhost comme ceci, avec un hack immonde de ré-écriture de l'en-tête Destination, parce qu'à priori un dev apache a pas voulu corriger ce bug en 2008… : https://bz.apache.org/bugzilla/show_bug.cgi?id=45449

<VirtualHost *:443>
        ServerAdmin user@example.com
        ServerName git.example.com

        <Directory /var/www/git>
                DAV on
                Options ExecCgi FollowSymLinks

                # Fix dav header
                RequestHeader edit Destination ^https: http: early

                # Gitweb config
                AddHandler cgi-script .cgi
                DirectoryIndex gitweb.cgi
                SetEnv GITWEB_CONFIG gitweb.conf

                AuthType Basic
                AuthName "Git repositories"
                AuthUserFile /var/www/git/.htpasswd

                Require method GET OPTIONS PROPFIND
                <LimitExcept GET OPTIONS PROPFIND>
                        Require valid-user
                </LimitExcept>
        </Directory>
</VirtualHost>

Soit t'es obligé d'avoir un truc comme ça :

<VirtualHost *:443>
        ServerAdmin user@example.com
        ServerName git.example.com

        DocumentRoot /var/www/git

        <IfModule alias_module>
                AliasMatch "^/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$" /var/www/git/$1
                AliasMatch "^/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$" /var/www/git/$1
                ScriptAliasMatch "^/(.*/(HEAD|info/refs|objects/info/[^/]+|git-(upload|receive)-pack))$" /var/www/git/git-http-backend/$1
        </IfModule>

        <Directory /var/www/git>
                Options ExecCgi FollowSymLinks

                # Git http backend config
                SetEnv GIT_PROJECT_ROOT /var/www/git
                SetEnv GIT_HTTP_EXPORT_ALL

                # Gitweb config
                AddHandler cgi-script .cgi
                DirectoryIndex gitweb.cgi
                SetEnv GITWEB_CONFIG gitweb.conf

                AuthType Basic
                AuthName "Git repositories"
                AuthUserFile /var/www/git/.htpasswd

                # Allow non push git request
                Require expr "(%{QUERY_STRING} !~ /service=git-receive-pack/) && (%{REQUEST_URI} !~ /git-receive-pack$/)"
                # Allow push for valid user
                Require valid-user
        </Directory>
</VirtualHost>

Le problème c'est que rien ne te garantis, que un jour quelqu'un autorisera pas a pousser des données via autre chose que git-receive-pack, déjà il y a deux méthodes pour pousser des données…

Des gens ont réussi une configuration simple sur https de git ?

Avec (au hasard) :
- gitweb pour un listing joli
- accès en lecture anonyme
- accès en écriture avec authentification

Parce que j'ai tenté pas mal de combinaisons, DAV échoue sur les opérations MOVE avec une 502 pour on se sait quelle raison.

Et pour git-http-backend, il faut utiliser deux AliasMatch et un ScriptAliasMatch et se baser sur une détection immonde du paramètre git-receive-pack dans QUERY_STRING ou REQUEST_URI…

Sans oublier un git config http.receivepack true sur tous les dépôts…

Tout ça pour juste autoriser l'accès en lecture seule…

Je parles pas des centaines de tutoriaux buggués sur internet qui ne fonctionnent plus sur apache 2.4.x et git 2.9.

Problème pas si rare que ça, tu as créé le chemin trop long sous linux, copié/collé ou logiciel sans la limitation.

Quand tu vas tenter de supprimer l'arborescence, windows 7 par exemple va échouer.

Tu vas devoir couper des branches de l'arborescence à la racine pour pouvoir finir de supprimer tout l'arbre…

J'ai utilisé un autre solution que le +site qui se retrouve bloqué dans 90% des cas par les formulaires de validation.

Tu prends un nom de domaine : example.com

Et tu crées une redirection pour chaque entreprise :
voyages-sncf@example.com -> example@example.com
bisounours@example.com -> example@example.com
etc…

Comme ça le jour où un service te soûle avec son spam, tu dégages l'alias et fini les spams :)

Il faut par contre penser à se faire des identités correspondantes dans ton client mail et bien penser à utiliser l'identité adéquate pour le message.

Le coût, quelques euros par ans pour le nom de domaine et le filtrage est simplifié :p

Ça m'intéresse, au nom de quoi ils t'ont forcé à revenir à l'ancien système ?

Pour avoir eu une masse suffisante de retour des comportements des fs sur disque dur mourant (du concret) NTFS est très fragile !

XFS ne se réparera pas, mais tu vas te retrouver avec la possibilité de récupérer les fichiers en lecture seule quand même (tant qu'un superblock existe encore).

EXT2/3/4 idem.

BTRFS à voir, pas encore eu de surprise, je testerais pour voir sur un vieux disque mourant.

NTFS, j'ai réussi dans de nombreux cas à récupérer les données, mais dans certaines configuration impossible, même en dumpant le contenu total du disque sur un neuf et là tu pleure.
(et linux est aussi affecté car ntfs-3g refuse maintenant de monter le fs, quand il est dans certaines configuration où t'as juste envie de récupérer les données)

Après au niveau long terme, les fs linux ont pas tendance à se fragmenter et pourrir tout seul, si on remplis pas à 90% le fs, contrairement à un moment t'es forcé de formater et remettre les données sous windows… (parce qu'ils ont des supers fichiers spéciaux planqués intouchable qui fragmentent tout seul)

Je comprends pas, il est possible de booter depuis fort longtemps sur XFS depuis grub…

C'est surtout red hat qui a retiré le support xfs de leur installeur par défaut depuis les rhel (voir sous la red hat 9.0).

Personnellement je boot via grub sur du xfs depuis la mandrake 2006 (de mémoire) sans gros soucis.