The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.
Le manuel de php en ce qui concerne la partie administration est une vaste blague.
php a été conçu pour faire fonctionner du code web directement. Sans l'intermédiaire d'une architecture n-tiers compliquée.
Le principe est simple le serveur web -> l'interpréteur -> le code. On ne passe même pas par une lib (comme en perl use CGI)...
Ce principe implique que l'interpréteur sert directement l'application. Donc si on ne met pas de sécurité dans l'interpréteur ? On la met où ?
La philosophie unix veux que l'on sépare les choses très distinctement. L'état de l'art (les DESIGN PATTERN et tou l'toutim) expliquent à peu près la même chose.
php prends le partie inverse. Ce n'est bien sûr pas obligatoire de l'utiliser comme ça. Mais c'est possible et même encouragé ( ne serais-ce qu'en mélangeant le html et le php dans le même fichier).
PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.
Donc de deux choses l'une soit php nécessite une séparation claire de la logique applicative (écrire des fichiers, envoyer des mails ...), soit php fournie les moyens de sécuriser son interpréteur.
quelqu'un qui ecrit :
<? mail($_POST[to],$_POST[subject],$_POST[message],$_POST[headers]);
?>
Dans un fichier et le laisse accessible depuis le web. Tu fait comment avec tes droits unix, ta mta et tes mises à jour de sécurité pour empêcher un spammeur de l'utiliser.
Tu fait le goret... tu lis/filtre les mails sortants, tu compte les mails ...
C'est pas un problème en l'air. C'est un exemple pratique et bien concret auquel le manuel php ne donne aucune réponse. Celui de java le fait, celui de RoR également.
> It is architecturally incorrect
php is architecturally incorrect c'est d'ailleurs pour ça qu'il est si facile à utiliser.
>Ces hébergeurs font tourner tous leurs sites webs sous un même utilisateur unix (www-data souvent, c'est le plus simple),
Tu perd alors tous le bénéfice du safe-mode. Qui est justement de pouvoir distinguer un script légitime d'un script uploadé malicieusement.
>Le gros problème c'est que ça ne devrait à mon avis pas être le rôle d'un interpréteur de limiter ça.
Tout à fait c'est le rôle d'un serveur d'application.
>Iptables, les droits unix et des mises à jour de sécurité régulières
Non. Si quelqu'un uploade un mass mailer (ce qui est le cas le plus courent), ni iptable, ni les mises à jour du serveur et des logiciels, ni les droits unix ne pourront te permettre de prévenir l'envoie de spam.
>(vous savez, l'aberration qui fait croire aux hébergeurs qu'ils ne sont pas obligés de sécuriser leurs serveurs)
Y en a un peu marre de ce fud perpétuel sur les hébergeurs qui n'ont pas déployés php comme dans "mon ubuntu"
Le safe-mode est la seule tentative sérieuse de faire de php (l'interpréteur), un environnement d'exécution un tant soit peu adapté à son usage.
La problématique des hébergeurs est de faire fonctionner du code globalement mauvais, et pour ainsi dire jamais mis à jour dans un environnement un tant soit peu sécurisé et avec des contraintes budgétaires fortes.
La question n'est donc pas d'empêcher le code malicieux d'être injecté (puisqu'en l'occurrence l'hébergeur n'a pas la main sur ce point). La question est de limiter la casse. De faire en sorte que le code malicieux ne se transforme pas en spam, en vol massif de données ou pire en exploit.
Bien utiliser le safe-mode permet de repérer les scripts uploadés via des failles et de restreindre sans l'interdire l'usage de la fonction exec. Il permet également de protèger la machine contre certains ini_set malheureux.
Je doute que beaucoup d'hébergeurs fasse du safe_mode leur seul outil en terme de sécurité.
Maintenant quand son site se fait pirater, c'est toujours plus simple de blâmer l'hébergeur qui en plus t'as honteusement coupé que de se dire que tu as écris/utilisé du code vulnérable.
Si le safe_mode est désagréable, c'est qu'il est contraint par le fonctionnement interne de php. Soit j'interdis, soit j'autorise. Je ne peux pas restreindre et pour cause, je n'ai pas de serveur d'application (oups)
Par ailleurs, quand tu vois les failles qu'il y a dans des choses aussi populaires que joomla, spip, phpbb ou drupal, quand tu vois que beaucoup d'agences vendent des sites sans maintenance, tu peux peux-être, en faisant un petit effort, comprendre qu'un hébergeur n'est sans doute pas le plus à blâmer.
Je vais même te dire le fond de ma pensée. Moi j'aime bien mettre le safe_mode. Tu sais pourquoi ? Parce que je suis sûr qu'au moins quelqu'un aura une fois mis le nez dans le code déployé sur le serveur. Parce que le truc ne va pas marcher from scratch est qu'au moins une fois, quelqu'un aura jeté un oeil à la gueule du code.
Moi je veux bien qu'on critique. Mais je prefererai qu'on m'éclaire sur la bonne façon de faire. Parce qu'en tout cas, c'est pas la doc de php qui va m'expliquer comment déployer son bordel.
>... faudrait en profiter pour prévenir quelques administrateurs dont, par exemple, ceux de free
php est la plate-forme web la plus merdique et la plus difficile à déployer. Tout simplement parce qu'elle nie complètement être une plate-forme, parce qu'elle souffre de choix de conception mauvais (genre url_fopen ou register_globals pour ne citer que les plus montrueux), parce qu'elle est une nébuleuse dans laquelle on trouve tout et n'importe quoi.
Enfin parce que beaucoup de développeurs en php pensent que le monde est un vaste windows et php une plate forme normée et que donc si du code marche chez tel hébergeur, il doit forcement marcher partout et pour une durée infinie.
Je pense que tu serais surpris de voir à quel point les admin en question connaissent le code de php et sont capable d'en comprendre les mécanismes, les problèmes et les évolutions. À quel point également php est souvent patché de façon importante, à quel point les choix des versions, et des libs associés demande du temps et de la validation.
Un exemple con : fsockopen.
fsockopen est une fonction toxique qui est souvent utilisée pour flooder. Il vaut mieux passer par l'implémentation directe des protocoles : imap, smtp, snmp ...
Bref on peut raisonnablement dire que sur un serveur web, fsockopen n'a rien à faire. Le code d'un site web n'a pas en géneral à ouvrir directement des sockets. Et bien sans fsockopen, aucun webmail ne fonctionne.
vi fsock.c
host="localhost";
C'est crade mais comment faire ? Filtrer les paquets sortants ?
> Ça serait complètement génial qu'on puisse sauvegarder la config directement sur le serveur IMAP
Si la config était un petit fichier simple qu'on pourrai mettre sur un serveur http par exemple ça faciliterai les choses. Par exemple pour distribuer des configs aux utilisateurs de façon centralisée. Ou encore un système de config déportée.
>Dans le même ordre d'idées, partager un annuaire de contacts ça serait pas mal
C'est sur qu'un truc plus simple (stockage imap des vcards par exemple ) serait quand même pas mal
>Toujours pour les même raisons, j'ai tendance à ne pas utiliser la gestion des calendriers avec Lightning. Il n'y a en effet pas de moyens satisfaisants pour avoir accès à mes calendriers quelque soit l'instance TB que j'utilise.
>Je suis conscient qu'avec un peu plus de volonté, j'aurai pu trouver des extensions qui répondent à mes besoins. Mais je pense que ça serait mieux que ce genre de foctionnalités soient intégrés directement à TB.
Thunderbird est lourdingue à configurer. C'est également mon point de vue.
Si tu veux vraiment interdire msn monter que tu peux savoir tout ce qu'ils font et souvent plus utile que de filtrer.
<la vie de mon pote>
Il reçoit un mail de sa direction :
- pourquoi vous êtes vous connecté en ssh à tel serveur tel jour à telle heure ?
- pourquoi avez-vous essayé de camoufler votre connexion ssh dans un tunnel http ?
>fermeture de ticket avec une réponse en carton
Pour déclencher ça à coup sûr:
-> "j'ai essayé sur un autre serveur, ça marche"
-> "je vous passe le gars du support XYZ ce sera plus simple"
-> "je sais pas, sous Windows ça s'installe tout seul"
-> "Je viens de me rendre compte que mon appli ne marche plus depuis 19 janvier 2007"
-> "Je voudrait faire un CNAME pour pointer le port 80 vers l'ip 82.145..."
Ou en deux temps :
1 - je peux avoir les logs ?
voila
2 - j'en fais quoi maintenant ?
...
Ou en 4 temps :
- comment je fait ça ?
comme ci
- c'est bon ce que j'ai fait là ?
oui impec
- finalement c'est simple
c'est pas très compliqué, non
- vous pouvez pas le faire directement ?
Je vous jure qu'avec moi, ça marche à tous les coups
Il m'a toujours semblé que Thunderbird était surtout un moyen pour la MoFo de prouver qu'on pouvait faire autre chose avec ses technologies (gecko, XUL ...)
Aujourd'hui il semble que cet objectif soit devenu obsolète.
La bonne question est peut-être de savoir ce qu'est thunderbird ?
- Un simple client mail
Dans ce cadre, il n'a que peu de chance de trouver autre chose qu'un succès d'estime et un public restreint. Sous Windows il y a déjà un client natif et la concurrence des Webmails. Sous Mac OS même topo. Sous Linux, les concurrents pullulent : evolution, kmail, claws-mail, mutt ...
Pour résumer utiliserons Thunderbird - une portion des linuxiens et les windowsien anti-microsoft; ça fait maigre.
- Un client kilKa cool hyper branché.
A mon sens c'est insuffisant. Le support de facebook, des flux rss de MSN ... n'est pas une mauvaise idée en soit. Je doute toutefois que ça apporte une vrai clientèle. Il me semble que justement dans cet usage, l'un des but et de pouvoir se connecter partout, en toutes circonstances. Un client riche me semble mal adapté à l'usage. De plus, courir après les évolutions de protocoles propriétaire est, nous le savons tous bien, se destiner à toujours avoir une version de retard; Il me semble que ce qui réussit à la MoFo c'est de provoquer l'innovation et pas de courir derrière.
- Un client groupware
Voilà peut être un manque. A condition toutefois de considérant qu'un client groupware n'est pas simplement un client mail gérant un carnet d'adresse partagé et un calendrier.
Il me semble qu'un groupware, peut se définir ainsi : partager les ressources de l'entreprise, dans le but de faciliter le travail de chacun et d'organiser la communication avec l'extérieur.
C'est une définition qui vaut ce qu'elle vaut mais partant de la, on peut imaginer ce qu'est un client groupware :
- un moyen d'accéder de façon unifié a ses ressource et aux ressources partagés. C'est à dire à la louche : contacts (réseau social), agendas (temps et espace), mails (communications), fichiers (contenu), bases de données (information structuré)
- un moyen d'éditer de façon unifié et collaborative ces différentes ressource
- un moyen d'organiser et de contrôler le flux des informations (droits, validation, version, todo)
C'est pourquoi je pense qu'aujourd'hui l'avenir de Thunderbird est dans l'intégration et le support unifié des standards (LDAP, OpenDocumnent, Jabber, WebDAV, ical ...), dans la simplification maximale des mécanismes de paramétrages et de l'interface (l'exemple du choix du format de mail est révélateur à ce titre). Alors une connexion à Facebook aura un sens parce qu'elle amènera ce média dans l'entreprise, alors il y aura sans doute des extensions dont nous ne pourrons plus nous passer.
Bon c'est pas dans la charte du forum mais sur la page d'accueil : http://www.mandrivalinux-online.eu/
Notre devise : "Un maximum d'interface graphique, au revoir la console !".
>Tout cela pour donner de la visibilite a l'ideologie GNU
Oui enfin gnu c'est pas qu'une idéologie.
A la louche dans n'importe quelle distro de base tu as : autoconf, automake, make, gcc, bison, gettext, m4, libtool, groff, patch, readline, ncurses, coreutils, diffutils, findutils, inetutils, la glibc, bash bien sûr et grub et souvent les implémentations gnu de awk, sed, gzip, grep, less, bc ...
Bref si tu enlève gnu et à moins que tu aille te servir chez les BSD, il ne te reste pas grand chose pour faire marcher ta distro.
Sauf que le bind dans le chroot n'est pas mis a jour aussi facilement que les binaires de la distribution... Bref, j'ai vu des bind en chroot qui n'étaient clairement plus mis à jour.
Personnellement je n'utilise bind qu'avec FreeBSD. Je suis assez surpris d'apprendre que certaines distro distribuent un bind non chrooté.
Vu la modernité du truc je pense qu'une bonne partie d'entre eux est incapable de booter sans Bipper.
Du genre pas de bipper c'est 4 bip ... etc ...
Et comme ils ont plus les sources chez phenix (Gégé - des archives - s'étant curé les ongles des pieds avec la carte perforée originelle - Sacré Gégé !), ils continuent à mettre des bippers ce qui ne doit pas couter plus cher que quelqu'un capable de comprendre (et à condition qu'un telle personne existe) l'architecture des processeurs intel/compatibles.
De plus dans compatible PC il y a compatible. Compatible ça veut dire parfait de base. Donc tu nous fais pas, avec ton bipper, le neo gauchiste nostalgique de l'époque ou alpha était autre chose qu'un version de google et ou les jeux et les crack s'échangeaient dans les petites annonces de "joystick" . Tu encaisse ton bip au démarrage ou tu fais comme tout le monde, une paire de pinces ou un fer à souder ...
[^] # Re: du mordernisme marketing.
Posté par Joris Dedieu (site web personnel) . En réponse au journal Nouvelles fonctionnalités de Snow Léopard. Évalué à 2.
[^] # Re: Pour awk
Posté par Joris Dedieu (site web personnel) . En réponse au message inserer un espace dans une sortie de 'cut'. Évalué à 4.
awk '{print substr($0, 22, 4) " " substr($0,47, 9) " " substr($0,56,9)}'
Tu peux mettre des virgules pour faire les espaces. C'est plus élégant.
awk '{print substr($0, 22, 4),substr($0,47, 9),substr($0,56,9)}'
[^] # Re: Also also featuring...
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Sortie de PHP 5.2.10. Évalué à 1.
security manager
>et RoR
Le modèle MVC
Même perl propose quelque chose (-T)
>ne peut envoyer de mail
Le problème n'est pas d'envoyer un mail mais de sécuriser ses variables.
[^] # Re: Also also featuring...
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Sortie de PHP 5.2.10. Évalué à 1.
Je ne connaissais pas ce worker. On gagne beaucoup par rapport à suexc / fastcgi mpm-worker ?
[^] # Re: Oh !
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Les journaux LinuxFr.org de la semaine. Évalué à 2.
Un genre de msn aussi : la tribune
[^] # Re: Also also featuring...
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Sortie de PHP 5.2.10. Évalué à 2.
The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.
Le manuel de php en ce qui concerne la partie administration est une vaste blague.
php a été conçu pour faire fonctionner du code web directement. Sans l'intermédiaire d'une architecture n-tiers compliquée.
Le principe est simple le serveur web -> l'interpréteur -> le code. On ne passe même pas par une lib (comme en perl use CGI)...
Ce principe implique que l'interpréteur sert directement l'application. Donc si on ne met pas de sécurité dans l'interpréteur ? On la met où ?
La philosophie unix veux que l'on sépare les choses très distinctement. L'état de l'art (les DESIGN PATTERN et tou l'toutim) expliquent à peu près la même chose.
php prends le partie inverse. Ce n'est bien sûr pas obligatoire de l'utiliser comme ça. Mais c'est possible et même encouragé ( ne serais-ce qu'en mélangeant le html et le php dans le même fichier).
PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.
Donc de deux choses l'une soit php nécessite une séparation claire de la logique applicative (écrire des fichiers, envoyer des mails ...), soit php fournie les moyens de sécuriser son interpréteur.
quelqu'un qui ecrit :
<? mail($_POST[to],$_POST[subject],$_POST[message],$_POST[headers]);
?>
Dans un fichier et le laisse accessible depuis le web. Tu fait comment avec tes droits unix, ta mta et tes mises à jour de sécurité pour empêcher un spammeur de l'utiliser.
Tu fait le goret... tu lis/filtre les mails sortants, tu compte les mails ...
C'est pas un problème en l'air. C'est un exemple pratique et bien concret auquel le manuel php ne donne aucune réponse. Celui de java le fait, celui de RoR également.
> It is architecturally incorrect
php is architecturally incorrect c'est d'ailleurs pour ça qu'il est si facile à utiliser.
[^] # Re: Also also featuring...
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Sortie de PHP 5.2.10. Évalué à 1.
Suhosin n'est pas php et c'est pas du vent loin de là.
suPHP à cause de la gateway cgi aux performances désastreuses n'est souvant pas utilisable. Ce n'est pas php non plus.
J'aurais du dire 'la seule emmenant directement de php".
[^] # Re: Also also featuring...
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Sortie de PHP 5.2.10. Évalué à 4.
Tu perd alors tous le bénéfice du safe-mode. Qui est justement de pouvoir distinguer un script légitime d'un script uploadé malicieusement.
>Le gros problème c'est que ça ne devrait à mon avis pas être le rôle d'un interpréteur de limiter ça.
Tout à fait c'est le rôle d'un serveur d'application.
>Iptables, les droits unix et des mises à jour de sécurité régulières
Non. Si quelqu'un uploade un mass mailer (ce qui est le cas le plus courent), ni iptable, ni les mises à jour du serveur et des logiciels, ni les droits unix ne pourront te permettre de prévenir l'envoie de spam.
[^] # Re: Also also featuring...
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Sortie de PHP 5.2.10. Évalué à 10.
Y en a un peu marre de ce fud perpétuel sur les hébergeurs qui n'ont pas déployés php comme dans "mon ubuntu"
Le safe-mode est la seule tentative sérieuse de faire de php (l'interpréteur), un environnement d'exécution un tant soit peu adapté à son usage.
La problématique des hébergeurs est de faire fonctionner du code globalement mauvais, et pour ainsi dire jamais mis à jour dans un environnement un tant soit peu sécurisé et avec des contraintes budgétaires fortes.
La question n'est donc pas d'empêcher le code malicieux d'être injecté (puisqu'en l'occurrence l'hébergeur n'a pas la main sur ce point). La question est de limiter la casse. De faire en sorte que le code malicieux ne se transforme pas en spam, en vol massif de données ou pire en exploit.
Bien utiliser le safe-mode permet de repérer les scripts uploadés via des failles et de restreindre sans l'interdire l'usage de la fonction exec. Il permet également de protèger la machine contre certains ini_set malheureux.
Je doute que beaucoup d'hébergeurs fasse du safe_mode leur seul outil en terme de sécurité.
Maintenant quand son site se fait pirater, c'est toujours plus simple de blâmer l'hébergeur qui en plus t'as honteusement coupé que de se dire que tu as écris/utilisé du code vulnérable.
Si le safe_mode est désagréable, c'est qu'il est contraint par le fonctionnement interne de php. Soit j'interdis, soit j'autorise. Je ne peux pas restreindre et pour cause, je n'ai pas de serveur d'application (oups)
Par ailleurs, quand tu vois les failles qu'il y a dans des choses aussi populaires que joomla, spip, phpbb ou drupal, quand tu vois que beaucoup d'agences vendent des sites sans maintenance, tu peux peux-être, en faisant un petit effort, comprendre qu'un hébergeur n'est sans doute pas le plus à blâmer.
Je vais même te dire le fond de ma pensée. Moi j'aime bien mettre le safe_mode. Tu sais pourquoi ? Parce que je suis sûr qu'au moins quelqu'un aura une fois mis le nez dans le code déployé sur le serveur. Parce que le truc ne va pas marcher from scratch est qu'au moins une fois, quelqu'un aura jeté un oeil à la gueule du code.
Moi je veux bien qu'on critique. Mais je prefererai qu'on m'éclaire sur la bonne façon de faire. Parce qu'en tout cas, c'est pas la doc de php qui va m'expliquer comment déployer son bordel.
[^] # Re: Bonne nouvelle, et du coup...
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Sortie de PHP 5.2.10. Évalué à 10.
php est la plate-forme web la plus merdique et la plus difficile à déployer. Tout simplement parce qu'elle nie complètement être une plate-forme, parce qu'elle souffre de choix de conception mauvais (genre url_fopen ou register_globals pour ne citer que les plus montrueux), parce qu'elle est une nébuleuse dans laquelle on trouve tout et n'importe quoi.
Enfin parce que beaucoup de développeurs en php pensent que le monde est un vaste windows et php une plate forme normée et que donc si du code marche chez tel hébergeur, il doit forcement marcher partout et pour une durée infinie.
Je pense que tu serais surpris de voir à quel point les admin en question connaissent le code de php et sont capable d'en comprendre les mécanismes, les problèmes et les évolutions. À quel point également php est souvent patché de façon importante, à quel point les choix des versions, et des libs associés demande du temps et de la validation.
Un exemple con : fsockopen.
fsockopen est une fonction toxique qui est souvent utilisée pour flooder. Il vaut mieux passer par l'implémentation directe des protocoles : imap, smtp, snmp ...
Bref on peut raisonnablement dire que sur un serveur web, fsockopen n'a rien à faire. Le code d'un site web n'a pas en géneral à ouvrir directement des sockets. Et bien sans fsockopen, aucun webmail ne fonctionne.
vi fsock.c
host="localhost";
C'est crade mais comment faire ? Filtrer les paquets sortants ?
[^] # Re: Mon avis
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Comment peut-on sauver Thunderbird alors que le courrier électronique se meurt ?. Évalué à 1.
si on utilise deliver pour à la place de procmail, on peut effet utiliser sieve.
http://wiki.dovecot.org/LDA
Ensuite il y a une extenssion pour TB (pas testé) : https://addons.mozilla.org/fr/thunderbird/addon/2548
> Ça serait complètement génial qu'on puisse sauvegarder la config directement sur le serveur IMAP
Si la config était un petit fichier simple qu'on pourrai mettre sur un serveur http par exemple ça faciliterai les choses. Par exemple pour distribuer des configs aux utilisateurs de façon centralisée. Ou encore un système de config déportée.
>Dans le même ordre d'idées, partager un annuaire de contacts ça serait pas mal
Avec ldap c'est quand même pas la mort :
http://www.azolia.com/thunderbird-ldap-ecriture-contacts
Mais c'est un peu un marteau pour écraser une mouche.
C'est sur qu'un truc plus simple (stockage imap des vcards par exemple ) serait quand même pas mal
>Toujours pour les même raisons, j'ai tendance à ne pas utiliser la gestion des calendriers avec Lightning. Il n'y a en effet pas de moyens satisfaisants pour avoir accès à mes calendriers quelque soit l'instance TB que j'utilise.
Tu peux mettre en place un serveur caldav comme DAViCal par exemple :
http://rscds.sourceforge.net/
>Je suis conscient qu'avec un peu plus de volonté, j'aurai pu trouver des extensions qui répondent à mes besoins. Mais je pense que ça serait mieux que ce genre de foctionnalités soient intégrés directement à TB.
Thunderbird est lourdingue à configurer. C'est également mon point de vue.
[^] # Re: Les rêgles
Posté par Joris Dedieu (site web personnel) . En réponse au message Filtrage MSN. Évalué à 1.
<la vie de mon pote>
Il reçoit un mail de sa direction :
- pourquoi vous êtes vous connecté en ssh à tel serveur tel jour à telle heure ?
- pourquoi avez-vous essayé de camoufler votre connexion ssh dans un tunnel http ?
Fin du problème.
</la vie de mon pote>
[^] # Re: les administrateurs systeme
Posté par Joris Dedieu (site web personnel) . En réponse au journal allez, installe moi unzip !. Évalué à 3.
Pour déclencher ça à coup sûr:
-> "j'ai essayé sur un autre serveur, ça marche"
-> "je vous passe le gars du support XYZ ce sera plus simple"
-> "je sais pas, sous Windows ça s'installe tout seul"
-> "Je viens de me rendre compte que mon appli ne marche plus depuis 19 janvier 2007"
-> "Je voudrait faire un CNAME pour pointer le port 80 vers l'ip 82.145..."
Ou en deux temps :
1 - je peux avoir les logs ?
voila
2 - j'en fais quoi maintenant ?
...
Ou en 4 temps :
- comment je fait ça ?
comme ci
- c'est bon ce que j'ai fait là ?
oui impec
- finalement c'est simple
c'est pas très compliqué, non
- vous pouvez pas le faire directement ?
Je vous jure qu'avec moi, ça marche à tous les coups
# Thunderbird pour qui ?
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Comment peut-on sauver Thunderbird alors que le courrier électronique se meurt ?. Évalué à 3.
Aujourd'hui il semble que cet objectif soit devenu obsolète.
La bonne question est peut-être de savoir ce qu'est thunderbird ?
- Un simple client mail
Dans ce cadre, il n'a que peu de chance de trouver autre chose qu'un succès d'estime et un public restreint. Sous Windows il y a déjà un client natif et la concurrence des Webmails. Sous Mac OS même topo. Sous Linux, les concurrents pullulent : evolution, kmail, claws-mail, mutt ...
Pour résumer utiliserons Thunderbird - une portion des linuxiens et les windowsien anti-microsoft; ça fait maigre.
- Un client kilKa cool hyper branché.
A mon sens c'est insuffisant. Le support de facebook, des flux rss de MSN ... n'est pas une mauvaise idée en soit. Je doute toutefois que ça apporte une vrai clientèle. Il me semble que justement dans cet usage, l'un des but et de pouvoir se connecter partout, en toutes circonstances. Un client riche me semble mal adapté à l'usage. De plus, courir après les évolutions de protocoles propriétaire est, nous le savons tous bien, se destiner à toujours avoir une version de retard; Il me semble que ce qui réussit à la MoFo c'est de provoquer l'innovation et pas de courir derrière.
- Un client groupware
Voilà peut être un manque. A condition toutefois de considérant qu'un client groupware n'est pas simplement un client mail gérant un carnet d'adresse partagé et un calendrier.
Il me semble qu'un groupware, peut se définir ainsi : partager les ressources de l'entreprise, dans le but de faciliter le travail de chacun et d'organiser la communication avec l'extérieur.
C'est une définition qui vaut ce qu'elle vaut mais partant de la, on peut imaginer ce qu'est un client groupware :
- un moyen d'accéder de façon unifié a ses ressource et aux ressources partagés. C'est à dire à la louche : contacts (réseau social), agendas (temps et espace), mails (communications), fichiers (contenu), bases de données (information structuré)
- un moyen d'éditer de façon unifié et collaborative ces différentes ressource
- un moyen d'organiser et de contrôler le flux des informations (droits, validation, version, todo)
C'est pourquoi je pense qu'aujourd'hui l'avenir de Thunderbird est dans l'intégration et le support unifié des standards (LDAP, OpenDocumnent, Jabber, WebDAV, ical ...), dans la simplification maximale des mécanismes de paramétrages et de l'interface (l'exemple du choix du format de mail est révélateur à ce titre). Alors une connexion à Facebook aura un sens parce qu'elle amènera ce média dans l'entreprise, alors il y aura sans doute des extensions dont nous ne pourrons plus nous passer.
Mes deux cents
Joris
[^] # Re: Des mythes, vraiment ?
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Notre opinion sur GNU/Linux doit-elle être mise à jour ?. Évalué à 1.
http://www.mandrivalinux-online.eu/
Notre devise : "Un maximum d'interface graphique, au revoir la console !".
[^] # Re: Des mythes, vraiment ?
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Notre opinion sur GNU/Linux doit-elle être mise à jour ?. Évalué à 9.
Je vous invite a titre d'expérience a vous rendre sur le forum de mlo
http://forum.mandrivalinux-online.eu/ .
Lisez bien la charte, inscrivez-vous et répondez aux newibies qui posent des question.
La règle du jeu est simple pas de ligne de commande. Tout à la cliquette.
Personnellement ça m'a gonflé au bout de deux minutes.
Question pourquoi essayer de faire des outils que nous n'aimons pas au lieu de rendre ceux que nous aimons plus accessibles ?
[^] # Re: Cooool, on vient d'inventer un nouveau troll totalement inutile.
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Night of the living BSDeads. Évalué à 3.
Oui enfin gnu c'est pas qu'une idéologie.
A la louche dans n'importe quelle distro de base tu as : autoconf, automake, make, gcc, bison, gettext, m4, libtool, groff, patch, readline, ncurses, coreutils, diffutils, findutils, inetutils, la glibc, bash bien sûr et grub et souvent les implémentations gnu de awk, sed, gzip, grep, less, bc ...
Bref si tu enlève gnu et à moins que tu aille te servir chez les BSD, il ne te reste pas grand chose pour faire marcher ta distro.
[^] # Re: Parce que
Posté par Joris Dedieu (site web personnel) . En réponse au message Pourquoi chrooter bind ?. Évalué à 1.
Personnellement je n'utilise bind qu'avec FreeBSD. Je suis assez surpris d'apprendre que certaines distro distribuent un bind non chrooté.
[^] # Re: Origine du bip
Posté par Joris Dedieu (site web personnel) . En réponse au journal Mort au bip. Évalué à 3.
Vu la modernité du truc je pense qu'une bonne partie d'entre eux est incapable de booter sans Bipper.
Du genre pas de bipper c'est 4 bip ... etc ...
Et comme ils ont plus les sources chez phenix (Gégé - des archives - s'étant curé les ongles des pieds avec la carte perforée originelle - Sacré Gégé !), ils continuent à mettre des bippers ce qui ne doit pas couter plus cher que quelqu'un capable de comprendre (et à condition qu'un telle personne existe) l'architecture des processeurs intel/compatibles.
De plus dans compatible PC il y a compatible. Compatible ça veut dire parfait de base. Donc tu nous fais pas, avec ton bipper, le neo gauchiste nostalgique de l'époque ou alpha était autre chose qu'un version de google et ou les jeux et les crack s'échangeaient dans les petites annonces de "joystick" . Tu encaisse ton bip au démarrage ou tu fais comme tout le monde, une paire de pinces ou un fer à souder ...
# La réponse est dans ton texte
Posté par Joris Dedieu (site web personnel) . En réponse au message Comment empêcher la création d'une route ?. Évalué à 2.
ifconfig eth0:1 192.168.10.11/32
# Attention au titre
Posté par Joris Dedieu (site web personnel) . En réponse au journal han les salauds, ils ont tué Colargol !. Évalué à 7.
[1] http://geekz.co.uk/lovesraymond/archive/so-i-married-a-kerne(...)
[2] http://fr.wikipedia.org/wiki/Calogero
[^] # Re: Il faut écrire des scripts bourne
Posté par Joris Dedieu (site web personnel) . En réponse au message CSH : nombre de jobs. Évalué à 2.
[^] # Re: aie
Posté par Joris Dedieu (site web personnel) . En réponse au journal voyages-sncf semble meme avoir un probleme avec Léa !. Évalué à 2.
[^] # Re: Elle a de l'humour
Posté par Joris Dedieu (site web personnel) . En réponse au journal voyages-sncf semble meme avoir un probleme avec Léa !. Évalué à 8.
[^] # Re: aie
Posté par Joris Dedieu (site web personnel) . En réponse au journal voyages-sncf semble meme avoir un probleme avec Léa !. Évalué à 2.
Décidément c'était mieux avant