Reprise du message précédent :

on est déjà passé en mode camps de rééducation agricole ?

le sport c'est pas si bon que ça pour la santé

Ma voisine, l'année dernière, faisait de la gym le midi avec son boulot. Elle est tombée en reculant, sa tête a cogné le sol => perte de l'odorat et du goût. C'est toujours pas revenu, donc ça semble définitif .. (non c'est pas le COVID )

J'adore quand google m'envoie un code par sms pour confirmer que c'est bien moi, mais que l'UI android ne m'affiche pas le clavier pour saisir le code reçu ensuite...c'est pratique

Clair

Ça m'est déjà arrivé en plus, et ça avait duré longtemps cette saloperie..

Et il n'y a pas grand chose à faire.. peut être s'enfiler des pains de glace dans le trouffion, mais je suis pas fan de l'idée.

Fini le day07 aussi. Pour la part 1 j'ai utilisé quelque chose d'opti je pense. Mais la deuxième, j'ai bouclé comme un sagouin.
 

C’est “marrant” à quel point swapoff est lent. Le SSD fait >400MB/s en lecture, mais `swapoff -a` atteint pas à 45 (il met 3mn à bouger 8GB de la swap à la mémoire).

c'est relou ça ... courage

 
ouais, moi aussi à la suite d'un choc a la con.
j'ai douillé pendant un bon mois, si ce n'est pas un peu plus (je ne me rapelle plus trop).

Je continue mes questions de n00b, vous me dites si je vous embête ou si c'est pas la place hein.
 
Donc l'autre jour je demandais (pour une app php/mysql) où stocker les variables du genre login/pass de bdd, clés, adresse email où envoyer les messages d'erreur, ...
La réponse qu'on m'a faite c'est "dans les variables d'environnement".
 
J'avais pas trop creusé, mais l'environnement pour vous c'est où ?
1/ Dans le fichier de config de l'host Apache par exemple ? (et ensuite accéder aux contenu des variables via $_SERVER['LA_VARIABLE'] ?
 
2/ Ca me semble assez étrange comme approche mais pourquoi pas. Qu'est-ce qui justifie ce choix ? quand je prends une app populaire comme... wordpress, il y a quand même des secrets stockés dans un bête fichier php (wp-config.php) sans que ça ait spécialement l'air de poser problème.
 
3/ Du coup il vaut mieux limiter au strict nécessaire j'imagine, le reste c'est quoi le plus logique ? bdd avec le reste des données de l'appli ?

1/ non dans les variables d'environnement de l'operating system et tu t accèdes avec $_ENV ou getenv.
 
2/ car comme ça tu n'as qu'à configurer un serveur et ton app est transportable: https://12factor.net
 
3/ oui
 
après ca ce sont les best practice, comme tu le vois plein d'app viennent avec leur fichiers de conf etc, mais les var d'env c'est universel

ok, merci
 
Donc pour le 1/ ça suppose d'aller modifier l'environnement de l'utilisateur avec lequel tourne php (php-fpm pour être précis), qui doit être www-data par défaut (et il n'a pas de /home le coquin). Ca ne risque pas de mettre le bazar si on a plusieurs applis ou déclinaisons de la même appli sur le même serveur ? On va se marcher sur les pieds non ? Il faut s'assurer de ne pas avoir 2 fois la même variable d'environnement (genre un truc standard type "sgbd_pass" ). C'est zarb. [edit : j'ai comme une idée de la réponse mais je préfère demander].
 
2/ oui je capte l'idée. Donc j'imagine aussi au passage qu'il faut avoir une doc bien à jour pour lister les variables à créer pour que l'appli puisse tourner ))
 
3/ imaginons que dans la bdd je veuille (pour de la config) stocker des infos sensibles d'un service tiers partenaire (genre des clés pour accéder à son API). La stocker en clair me semble une mauvaise idée... mais la stocker chiffrée suppose de se faire tout un back-office pour chiffrer ces clés (avec une clé issue d'une var de l'environnement par exemple)... parce que sinon je ne vois pas trop comment la chiffrer AVANT de la stocker en bdd. ça fait pas mal de taf pour une bête variable... je passe à côté de quelque chose ?

3ème dose faite, on va voir si je deviens plus performant à l'AoC  

1/ Des variables applicatives dans les vars d'environnement de l'OS?
J'en connais un qui a jamais déployé deux applis sur le même serveur.
Tu gères un/des fichier(s) de conf et puis c'est tout.

 
Quand je fais des tests de sécu sur le code (sonarqube par ex), ça couine quand il voit $db_pass = "toto" ; dans mon fichier de config actuel
Il y a aussi le risque de voir le fichier de conf dans git (d'ailleurs je ne vais pas mentir, actuellement il y est, et même avec un switch selon que le fichier s'éxécute en dev ou en prod !).

 
1/ ça semble se faire beaucoup dans le monde des containers

 
Pourquoi juste pas un fichier de prod en prod et un fichier de dev en dev?

 
Ouais j'appelle pas ça une "best practice".
 
Pour moi le "standard" c'est le fichier de conf dans /etc/ dans un format standard (yaml, json...)

Dans la mesure ou tu met ces variables dans le vhost de ton hébergement, ça peut être pas mal...
Après c'est vraiment pousser loin la sécurité, je part du principe que si l'utilisateur à accès en ftp, il peut déjà quasiment tout faire, donc je trouve plus simple et plus lisible d'avoir des fichiers de config.

Parce que c'est vachement pratique
Même fichier de config pour 90% des choses + petit switch pour les variables qui sont différentes entre la prod et le dev (genre login/pass sgbd, du serveur de mails, quelques variables du genre remplacer paypal.com par la sandbox de paypal...)
C'est pas bien mais qu'est-ce que c'est pratique
 
D'où mes questions pour améliorer ça

Le réparateur de téléphone qui me demande mon code de déverrouillage c'est pas carrément louche ?

La question se pose même pas là c'est mon tél pro (encore que ça change pas grand chose) mais bon, rien que demander je trouve que ça pue. Il va me faire une gfive junior et me le bloquer si ça se trouve...

 
Dans des boites un peu plus grosses on utilise puppet ou autres pour générer la conf. Le coup des doublons/historique ne se pose donc pas.
 
Sinon trois fichiers de confs :  
- un commun
- un dev qui inclus le fichier commun
- un prod qui inclus le fichier commun

 
ouais, dans un conteneur ça s'entend - c'est pas fait pour être partagé. Mais présenter ça comme une recommandation hors contexte, je dis non!

Perso ça me pose aucun problème. Tant que tes fichiers de conf sont dans une arborescence dédiée, et bien évidemment uniquement en version "exemple" dans le dépôt des sources.

C'est une pratique très répandu depuis le lancement d'Heroku :
https://12factor.net/config

le fichier de conf hors racine, ça serait quoi l'idée derrière ? s'il est accessible par l'app (donc par le process php), où qu'il soit stocké son contenu est librement lisible à partir du moment où on a accès au code.
 
Si quelqu'un a accès (ftp/ssh) au contenu du code, il voit qu'on appelle /etc/monapp/maconfig.conf et donc il peut ouvrir sans souci le fichier dans /etc/monapp/maconfig.conf vu qu'il a les mêmes droits que les fichiers du code.

Si c'est pour changer la vitre oui
Si c'est pour tester ta réception GSM parce que tu droppes 80% des appels en moins de 20secondes non
 
Quand j'ai été dans le deuxième cas j'ai ré initialisé mon téléphone avant de lui refiler (et c'était en Apple store)

En // tu nous vends l'idée de déployer plusieurs app en vrac dans le même OS

Ok alors

 
et non accessible depuis un navigateur  
 
bref, ça fait des vérifs en plus , avec de vraies conséquences, qui ne sont pas nécessaires avec des variables d'environnement

C’est une recommandation hors contexte, je pense surtout que t’as interpolé que les envvars sont globales alors que pas du tout. Tous les outils de gestion de process (genre systemd & co) permettent de configurer l’environnement d’exécution d’un process, c’est ça qui est utilisé, ou pire des cas des wrappers sur env(1).
 
C’est utilisé comme un moyen simple de passer des k:v sans devoir les stocker en dur sur le FS (donc en limitant leur accessibilité) et ça permet une sorte de scoping dynamique (si ton soft lance d’autres outils tu peux aussi les configurer comme ça),

 
Bienvenue dans la vraie vie d'un service d'exploitation avec bcp d'historique.
 

 
C'était évidemment l'idée de "dans une arbo dédiée".
 

 
J'entends ce que tu dis, mais je reste franchement pas convaincu. Si je dois faire autre chose que des fichiers de conf perso je passe directement à un stockage de la conf dans la base de données, le paramétrage d'accès à cette dernière restant seul dans un fichier de conf.

Bon on a fait un mob programming pour l'AoC du jour histoire de meubler la com' de la boite. C'est dommage d'être tombé sur un problème comme ça.
 
Une des devs a eu l'intuition de la médiane.
 
Comme personne n'était sûr que c'était la solution on a fait la solution bourrine, et on a raffiné ensuite.
 
j'avoue que je me rappelais pas (ou j'ai jamais su) que la médiane minimise les écarts absolus

On parle trop souvent de moyenne uniquement, alors qu'on devrait toujours donner la médiane en plus (ou mieux, l'écart type )

Je le savais plus non plus, mais c'est assez simple à réaliser : si il y a plus de crabes à gauche qu'à droite, se déplacer vers la gauche est forcément rentable : on augmente le coup de nDroite et on le diminue de nGauche.

j'espère que vous avez été chercher la médiane en O(n) au lieu de O(nlg n)

En mode bourrin mais concis :

Je dirais même plus: quand t'es à la médiane il est évident que quelle que soit la direction dans laquelle tu pars le coût augmente.

Pareil, pour une fois que j'ai une bonne intuition mathématique.
 
Pour la 2e partie si j'avais fait du mob programming j'imagine que mes collègues qui calculent des centroïdes à longueur de journée m'auraient tout de suite dit comment faire.

Le fiston qui fait des suites en maths a bien aidé, dans ça je me serais peut être pas souvenir du n(n+1)/2

 
Le mien est en CM2, il m'a été d'aucune aide pour le coup, je me suis contenté d'un bête

   
 
Mais oui.. la formule de Gauss... ça remonte si loin