Sytoka Modon a écrit 4551 commentaires

La philosophie UNIX repose aussi sur la notion de processus père fils. Il n'y a pas de variable globale. Les variables d'environnement s'exporte du père au fils si on le demande.

Comme ce concept est parfois insuffisant, on peux avoir des segments de mémoire partagé mais l'important est que par défaut, tout tourne dans ce cadre bien cloisonné.

Les méta-serveurs complexe avec les bus puissant vont être un gouffre à bogue. C'est évident. L'étape suivante logique est bien sur les cgroup et au delà, de faire tourner chaque service dans un container. C'est vrai qu'on peux se poser la question du pourquoi faire aussi complexe au central ?

A mon sens, un des premiers coins dans la philosophie UNIX tel que tu l'as décrit a été le langage Perl car Larry en avait marre de chaîner les commandes dans des pipes au final plus compréhensible… Je dois dire que Perl est quand même un super langage pour le système…

Ce qui me gène plus est cet amas de chose binaire au coeur de l'espace utilisateur et que tout cela semble fort peu scriptable donc modifiable par un administrateur système moyen.

Avec pam_group, tu donnes (donnait) les droits qui vont bien en mettant la personne dans un groupe. Pas ssh, tu ne donnait pas le groupe audio et c'était tout.

Bref, une bête gestion par groupe… simple à comprendre et qui marchait plutôt bien.

A ma connaissance, php n'est pas tread safe… donc sur ma debian, je fonctionne encore en mode prefork pour le php. Ce n'est pas le cas pour les applications web en Python ou en Perl.

Pour les jeunes, le Perl est has-been… et donc les propos dessus sont rapidement tournés en dérision. C'est un peu pareil avec Fortran d'ailleurs ;-)

Comme un post plus haut, on voit que l'idée qu'en Perl il faut construire ses objets à la main à la vie dure… Il y a tout plein de framework qui vont bien et qui sont clair.

Je fais (rarement) du Python mais je préfère Perl. Dès que j'ai un module Perl, je fais un man sur celui-ci et j'ai une doc correcte la plupart du temps. Je ne retrouve pas cela avec Python. Idem avec php.

Je me suis amusé à faire un petit programme utilisant la libcoro, c'est une manière de faire de l'asynchrone sans passer par l'usine à gaz POE, du pur bonheur.

Bref, il y a aussi des effets de mode.

Je parlais d'un seul login de bdd.

Arg… J'héberge tous mes serveurs (RENATER) donc j'oublie parfois les contraintes du privé ;-)

Si tu écrit ton code de manière à empêcher l'injection SQL, ça n'arrive pas non plus.

Mauvaise réponse, il suffit de voir les alertes régulières du CERT. On a bon bien programmer, on finit toujours par trouver un bogue un jour. Le cloisonnement permet d'espérer rendre ce bogue peu critique…

Exemple, Perl en rajoutant de l'aléatoire dans ses tables de hachages il y a 10 ans n'a pas subit le bogue dernièrement contrairement à PHP ou Python…

Un bon design évite parfois des futurs soucis !

Samba permet de faire du DFS ce qui permet par exemple de montrer aux utilisateurs une racine unique…

Coté perf, les derniers WebDAV que j'ai monté étaient très lent. Pratique en externe mais en interne, si on peux aller plus vite, tant mieux. J'utilise du WebDAV pour de l'upload de fichier à diffuser donc assez statique mais pas sur des documents de travail.

Ai je dis que c'était tout pareil ?

Il me semble que les websockets, c'est quand même fait pour faire du connecté… Bref, je ne suis pas dans la technique bas niveau, mes propos se veulent être sur du design très général.

Peut être qu'une application web simple et un montage fuse par exemple suffise à basculer les données finale sous la bonne identité et résolve en partie le soucis ?

Sinon, le login pour l'hébergement ne te sers qu'a mettre à jour ton application, il ne sers à rien pour l'application elle-même et ne se retrouve pas sur le serveur. Je ne vois donc pas pourquoi cela reviendrait au même ? Pour moi, cela n'a rien à voir avec ce que je proposait.

Exemple : si le code php login.php n'avait accès à la base de données qu'en lecture, on éviterait toute écriture sur la BDB tant que la personne n'est pas identifiée. Ensuite, sur les autres pages php, si une personne attaque, elle a un identifiant donc peut être tracée et surtout ce type d'attaque relève du règlement intérieur de l'établissement… Bref, je ne vois que des avantages à cloisonner un peu mieux les requêtes SQL afin des les rendre plus robuste aux bogues !

Justement, si tu me relis, je veux le faire en //. Mais pour cela, il faut que les fichiers sur le FS n'appartiennent pas tous à la même personne. Je n'ai pas testé OwnCloud donc je ne sais pas comment il gère les fichiers…

Il me semble que c'est plus un travail de fond :

• modularisation du coeur de Perl
• passage en UNICODE

L'objectif me semble clairement le long terme. L'avantage est de pouvoir ajouter des choses de manière plus modulaire donc moins risquée et plus stable. Les ajouts venant de Perl6 ne sont pas tous géniaux (j'ai lus plein de truc comme quoi l'opération ~~ était mal définis par exemple, il me semble que "given" pose aussi des soucis…).

Bref, une base solide pour la suite ;-)

C'est plus une constatation générale… Par exemple, samba fork sous l'identité de la personne et écrit les fichiers sur les disques avec cette identité.

Un fork de serveur pour changer d'identité, cloisonner et espérer améliorer la sécurité est une chose très classique (postfix…).

Au niveau des serveurs web, je trouve qu'on profite pas beaucoup des fonctionnalités de l'OS au dessous. En règle générale, tout tourne sous une seule identité et tous les fichiers appartiennent à cette personne. Avec les cgroup, il y a plein de chose bien qui pourrait être envisageable si le service changeait d'identité après le login de la personne. La même remarque pourrait être faite coté base de donnée car en générale, l'application web n'utilise qu'un seul login pour accéder à la base, que ce soit pour les requêtes en lecture seules (SELECT), celles en écriture (UPDATE) et celles de mise à jour (ALTER, DROP..). J'ai du mal à comprendre pourquoi la stratégie n'est pas de créer 3 identifiants par défaut… sauf la facilité pour l'utilisateur lambda qui veut tout installer en 3 click.

Coté Owncloud, j'aimerais que les utilisateurs puissent avoir accès a leur fichier via un partage samba ou nfs en interne… J'ai cru comprendre qu'on pouvait accéder depuis celui-ci à des partages samba mais j'ai pas été plus loin. Il ne faut pas prendre la voie d'Alfresco ou si j'ai bien compris, ils ont reprogrammé dans leur serveur un serveur CIFS en Java…

Mon idée serait plutôt de mettre en place un service Webdav en parallèle de Samba et NFS et OwnCloud a l'avantage d'avoir un développement qui me semble actif et communautaire. Je regarde aussi du coté d'un petit projet qui fait cela et juste cela : webdavcgi

http://webdavcgi.sourceforge.net/doc.html

Je vois que tu préfères les usines à gaz en Java ;-)

SPIP est un bon exemple de projet qui évolue et qui marche…

Ce qui m'inquiète plus, c'est que j'ai l'impression que ce genre de service tourne presque toujours sous l'identité www-data par défaut donc cela revient à mettre les données des utilisateurs sur une grosse partition FAT32 ! Il serait temps de faire des services web efficace qui bascule du compte root vers un compte utilisateur afin de pouvoir profiter de la couche de sécurité d'EXT4, XFS, BTRFS…

Il y a suexec mais d'après ce que j'ai lu, aucun n'est vraiment efficace en terme de performance…

Faut être motiver avec cette bête là, les alertes se succèdent…

Nous on utilise SPIP comme plein de laboratoire CNRS, avec l'écran de sécurité plus une autre astuce, pas eu de problème depuis l'origine… et pourtant, j'ai des SPIP pas toujours super à jour !

Astuce SPIP : interdire /ecrire en http, et mettre une authentification Apache sur https. Ainsi, il faut commencer à percer Apache qui est bien plus robuste que n'importe quel code PHP à mon avis !

Mais donc : quelle est l'utilité du fric public? Dans ce cas, ben… Si c'est pas pour le public

Question : public veut'il dire universelle ?

Sans vouloir personnellement prendre partie, pour certain, public veut dire Français ou Européen… La recherche cache aussi des subventions aux groupes industriels pour les maintenir à la pointe ! Tous les états font cela.

Ayant été mis au courant d'un certain nombre de cas, j'ai clairement pas de bonne solution a cette question. Personnellement, si j'étais chercheur, je ferais tout mon possible pour éviter ce genre de contrat.

but WITHOUT ANY WARRANTY;

C'est pas aussi facile… Si c'est un thésard d'un copain qui est dans un autre laboratoire, tu peux te retrouver un peu coincés… A ce niveau là de recherche, le monde est petit, tout le monde se connaît un peu et ils sont tous un jour ou l'autre dans les jurys de thèse ou les jurys d'admissions des laboratoires voisins (en thématique). Ton équipe peut aussi être sur des ANR commune…

Bref, pas toujours facile de dire non, surtout que le demandeur ne se rend pas toujours compte du temps réel que prends n'importe quel support.

C'est exact mais dans la concurrence internationale, on va te dire que tel sujet est ultra sensible et il ne faut pas que tel ou tel pays accède trop facilement aux résultats (ou plutôt au savoir faire). Il y a parfois une problématique de secret défense ou de stratégie industriel sur lesquelles je n'ai aucune compétence mais qui sont réelle en science pour l'ingénieur…

Je pense par exemple qu'une bonne partie des recherches sur les futures fusées sont loin d'être complètement libre…

C'est pas aussi simple…

Je suis dans un laboratoire de recherche publique. La subvention de base est inférieur à 20% de notre budget (or salaire des fonctionnaire). Donc plus de 80% de nos moyens sont sur contrat, certains publiques (ANR, Europe…), d'autres privés. Penser que l'argent arrive tout seul est un doux rêve du passé. Les chercheurs passent leur temps à répondre à des appels d'offre puis à rédiger de la publication au kilomètre…

Ensuite, il y a une certaine concurrence internationale… Il y a des chercheurs qui ne souhaitent pas se faire "piquer" leur code (ou tout simplement le montrer). J'ai un chercheur par exemple qui m'a dis hier qu'il ne voulait pas car il ne veut pas faire le support (notamment, il ne veut pas faire le support pour un le thésard d'un autre chercheur si celui-ci ne veut pas mettre les mains dans le cambouis). Très souvent, il y a aussi des problèmes de licences qui sont loin d'être clair.

Bref, on a un certain nombre de code libre disponible sur le net. Je pousse a en libérer encore plus… même si ce n'est pas tous les jours faciles. Mais ce ne sera jamais 100% !

Je vois qu'un post a sortis les anciennes base db* (mais qui servent toujours beaucoup). Pour être complet, il ne faut pas oublier les bases de données "matricielles" très utilisés dans le calcul scientifique, notamment NetCDF et HDF (d'ailleurs la dernière version de NetCDF(4) est basée sur HDF(5)).

Ce genre de base est parfait pour stocker des matrices numériques. On peux les attaquer à distance en HTTP via le protocole DAP (exemple de petit serveur qui marche bien : pydap).

Limite hors sujet … mais à connaître tout de même.

Si toutes les affaires en cours vont à terme, il n'est pas sur que Sarko soit blanc comme neige coté salaire caché… Ceci dis, on va attendre !

Sinon, je trouve que Sarko a pas mal appliqué un bout de la méthode indiquée dans 1984 par Orwell. Une chance au final qu'il ne soit pas renouvelé.

Il suffit de voir le résultat de 2002, plus de 80% pour Chirac.

Le FN ne gère aucune ville, aucun département… Rien. Ils sont dangereux et l'immense majorité n'en veut pas.

Pourquoi on nous a été saoulé pendant la campagne avec Le Pen comme à chaque fois ?

Un autre système de votre a aussi des travers (voir théorème d'Arrow) mais celui que nous avons actuellement en a de très gros.

Le point très positif est aussi de replacer le vote Le Pen a sa juste place. On sais qu'avec un vote a deux tours, on peux gagner et/ou avoir des effets de loupe impressionnant.

Avec ce résultat, on aurait pu espérer avoir une campagne moins borné sur les thèses infâmes et rabâchées du FN

En effet ce type de vote ne marche pas, on voit que l'élu est celui dont tout le monde se fout (le plus de note 0).

Faut, dans le test (auquel j'ai participé), on votait aussi pour un second tour classique or Bayrou gagnait TOUS les duels.

Un p'tit lien n'aurait pas fait de mal pour rendre l'appel plus efficace…

J'ai tendance à faire presque toute la doc utilisateur en POD… Il y a bien sur un wiki mais c'est en plus. J'intègre si possible la doc POD dans le fichier source (possible en Perl bien sur mais aussi avec bash, Fortran…) et une petite règle dans un Makefile me mouline tout cela en des fichiers man et même temps que la compilation !

Je trouve que pour beaucoup de chose, la doc au format man est bien pratique. C'est souvent bien pratique d'avoir tout sur sa machine et qui ne prennent pas 3Go de disque ni dix milliard de cycles CPU lors de l'utilisation !

Exemple à ne pas suivre, les dernières version du compilateur intel prennent plus de 2Go d'espace disque juste pour pouvoir faire icc ou ifort… Tout cela car il y a un bordel de doc et de java complètement inutile mais placé dans une arborescence digne d'Adobe ;-)

J'ai un pu le même soucis… mais je me demandais si on ne pouvais pas changer dans le LDAP le nom du domaine, sachant que sous Windows, les noms importent peu puisque normalement, ce sont les SID les vrais identifiant.

Si tu change le nom du domaine, les postes clients basculent'ils tout seuls sur le nouveau nom ?

Il faut dire que c'est la 6.0 car la précédente était la 5.9 mais que c'est une version mineure à mon sens…

LDAP est plutôt un exemple de base SNMP tellement le lien entre les deux est proche.