ownCloud est sorti en version 4. Pour mémoire, ownCloud est un service en ligne qui permet de stocker vos fichiers, de jouer vos musiques, d'afficher votre calendrier, de gérer vos contact, etc. Il offre un accès aux fichiers via WebDAV, un client de synchronisation sous Linux et Windows pour avoir la même version entre votre ordinateur et le serveur et offre aussi de partager votre calendrier et vos contacts via CardDAV et CalDAV. Il existe aussi un client pour synchroniser vos fichiers avec votre ordinateur.
Tout cela s'installe facilement et ne nécessite que PHP et une base MySQL ou PostgreSQL. Et si vous ne voulez pas l'installer, il existe plusieurs sites qui vous proposent un compte sur leurs installations. ownCloud.com propose même des solutions pour les entreprises.
NdA : Merci à eMerzh, Benoît et Altor pour leur aide lors de la rédaction de cette dépêche.
Cette nouvelle version apporte :
- le chiffrement des fichiers sur le serveur ;
- le versionnement des fichiers ;
- l'envoi de fichiers via glisser-déposer sur le site ;
- le partage de calendrier ;
- les catégories dans le calendrier ;
- la visualisation de fichiers ODF ;
- le logging via syslog ;
- et évidemment plein de corrections de bugs et d'améliorations
Aller plus loin
- Annonce officielle de la sortie (291 clics)
- Site Demo (1445 clics)
- Site officiel (604 clics)
- Liste des fonctionnalités (210 clics)
# oudClown, une solution qu’elle est bien pour mon nuage
Posté par jyes . Évalué à 9. Dernière modification le 24 mai 2012 à 07:59.
Ou même sqlite pour les moins gourmands (ou les plus auto-hébergés).
Vu la rapidité d’installation, j’ai mis à jour mon ownCloud vers cette nouvelle version dès sa sortie et suis vraiment impressionné par ce projet au développement rapide par la qualité du résultat. La seule vraie difficulté avec ownCloud, c’est de trouver un bon client CalDAV et CardDAV libre pour en profiter pleinement.
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par claudex . Évalué à 5.
J'ai aussi mis à jour dès la sortie mais j'ai été un peu déçu, je trouve que certaines fonctionnalités sont un peu buggué. Par exemple, il n'y a pas moyen de supprimer une tâche. Et je n'ai pas trouvé comment limité le nombre de versions sauvegardées.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Olivier Guerrier . Évalué à 6.
Je confirme la difficulté de trouver des clients *dav efficaces. Et idéalement il faut trouver pour le bureau, et pour le mobile/smartphone (ne pas utiliser les services google et étant sous android est un sport quotidien…)
Si certains ici ont les suggestions ou des retours d'expérience à proposer … je suis à l'écoute.
J'utilise lightning sur le bureau, qui s'en sort pas trop mal pour les calendriers, et carddav-sync sur android (pas libre).
Je n'ai pas trouvé de client android qui sache gérer les taches de façon exploitable. acal est libre, mais demande un gros travail d'avant de pouvoir être utilisable.
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par claudex . Évalué à 5.
Pour les contacts et le calendriers, j'ai utilisé Thunderbird et Kontact avec Owncloud sans problème particulier. Comme je n'ai pas d'android, je n'ai rien testé là-dessus. Mais, ils annoncent qu'ils sortiront bientôt un client pour Android, il faudra voir ce que ça donne.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Sak . Évalué à 2.
Pour les contacts, il y a l'extension SOGo pour Thunderbird. Testé vite fait sur une v12, ça a l'air ok.
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par ondex2 . Évalué à 5.
Niveau client caldav/carddav, il y a le choix. Avec SOGo, j'utilise, avec succès les clients suivant :
- Thunderbird + lightning (+connecteur SOGo) : CalDAV et CardDAV
- Evolution : CalDAV et CardDAV
- le "truc" de KDE 4 avec Kontact & co : CalDAV et CardDAV
- Mac OS X iCal et Address Book : CalDAV et CardDAV
- iOS Agenda et Contacts : CalDAV et CardDAV
- Android, CalDAV-Sync et CardDAV-Sync : CalDAV et CardDAV
Tout ça fonctionne bien à très bien avec SOGo donc j'imagine que si l'implémentation de OwnCloud est correct, ça le fait. Pour info, le moins bon est Evolution car il faut rentrer tous les agendas et carnets d'adresses à la main (par de detection auto des inscriptions).
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Flyinva . Évalué à 2.
Pour android, acal fonctionne avec ownCLoud. Il permet de synchroniser l'agenda et les contacts. C'est un logiciel libre.
Visiblement, les URLs *DAV ont changé dans la version 4 de ownCloud mais les anciennes fonctionnent toujours.
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Larry Cow . Évalué à 3.
Sauf si ça a changé récemment, acal ne synchronise pas : il affiche une vue du calendrier et des contacts dans son interface à lui. L'application "Agenda" fournie par Android restera vide des événements d'Owncloud, à la différence de ce que fait CardDAV-Sync/CalDAV-Sync. Ces derniers se libèrent d'ailleurs progressivement.
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Mr Kapouik (site web personnel) . Évalué à -2.
Bah justement si ça ne synchronise pas l'application agenda fourni par défaut c'est un point excellent car pour tout les couillons qui comme moi ne synchronise pas leur téléphone sur leur compte gmail et qui n'ont pas de calendrier sur google : maintenant ils peuvent en avoir un. Donc tu n'as pas soulevé un défaut mais un gros avantage.
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par lesensei . Évalué à 4.
Il me semble pourtant que l'on peut parfaitement utiliser l'application "Agenda" présente sur Android sans pour autant avoir un compte Google. Donc je ne vois pas trop où est l'avantage, puisque de nombreuses autres applications et widget perdent ainsi la possibilité d'interagir avec ton agenda…
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Paul . Évalué à 4.
Ouais je confirme, c'est bien un énorme inconvénient et non pas un avantage.
Rien n'oblige à utiliser un compte Google, et caldav-sync et carddav-sync synchronisent bien le calendrier et les contacts « Android » directement. C'est-à-dire celui qui est bien intégré à l'OS. C'est-à-dire un peu le seul utilisable sérieusement.
Il est prévu que carddav-sync et caldav-sync soient libérés à la sortie de la première version stable (qui n'arrivera peut-être que dans 10 ans bien sûr, voire jamais).
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Flyinva . Évalué à 1.
En effet, pour être très, aCal propose sa propre interface de calendrier et de tâches qui peuvent être synchronisés avec owncloud. De plus, il n'est pas possible de créer le contact sur le téléphone, la synchronisation ne fonctionne que du sens serveur vers aCal.
Je n'utilise pas les applications google (cyanogenmod + f-droid uniquement).
Je ne comprends pas bien ce que ça veut dire : c'est libre ? pas libre ? ça va le devenir ? Tu as peux être des infos qui ne sont pas sur le site du projet.
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Paul . Évalué à 2.
Tu n'utilises pas le gestionnaire de contacts d'Android non plus ? Le calendrier est fourni avec CyanogenMod, il fait partie du projet Android, il est libre, bref rien de méchant. (j'utilise aussi CyanogenMod et FDroid uniquement) (sauf multiling keyboard qui est de très très loin le meilleur clavier bépo pour android que je vais chercher sur le site du projet directement)
Normalement, info dispo sur le site de davical, ça devrait être libéré à la sortie de la première version considérée comme stable par l'auteur. La 1.0 quoi. Peut-être dans 10 ans, peut-être la semaine prochaine, peut-être jamais…
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Flyinva . Évalué à 1.
Autant pour moi. Je croyais que cela faisait partie des applis Google.
Je cherchais une solution libre pour synchroniser calendrier/contacts et un serveur. Je suis tombé sur aCal qui fait le boulot. C'est loin d'être parfait mais ça marche. Je n'ai donc jamais utilisé le calendrier d'Android. Pour les contacts, aCal les synchronise bien avec le gestionnaire de contacts d'Android.
Ce n'est pas vraiment le meilleur moyen pour obtenir des contributeurs… En attendant que ce soit libre, je vais continuer à m'en passer ;-)
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Larry Cow . Évalué à 2.
Je n'ai pas vu de synchro chez moi, il reprend trois plombes à chaque ouverture d'aCal, comme s'il n'avait pas les données en local. Si c'est juste pour afficher des données locales, c'est un gros problème de performances.
Perso, j'utilise les applis Google mais que sur des comptes non-Google (Owncloud, notamment). Donc effectivement, aCal est très juste de ce point de vue.
C'est pas libre, mais l'auteur a promis depuis le début de le libérer à la version 1.0 (cf. https://play.google.com/store/apps/details?id=org.dmfs.caldav.lib&feature=more_from_developer ). Sinon, il a une section à ce sujet sur son site: http://dmfs.org/wiki/index.php?title=Open_source_status
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Flyinva . Évalué à 0.
J'utilise aCal depuis deux mois. Mon téléphone et thunderbird (via lightning et sogo) sont synchronisés avec owncloud (agenda + contacts). Je crée mes rendez-vous sur le téléphone, le PC ou via l'interface web. Par contre, l'ajout de contacts ne fonctionne que depuis le web ou thunderbird.
Au début j'ai galéré pour trouver les bonnes URL *DAV de owncloud. C'est pour cela que j'ai fait la doc sur le wiki projet. Depuis, ça marche suffisamment pour mon usage.
J'avoue que aCal peut ramer un peu par moment. Si c'est le prix de la liberté, je l'assume ;-)
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Larry Cow . Évalué à 1.
Pratique, si tu n'es pas toujours devant ton/un ordinateur…
Soyons juste : ça rame et c'est laid. On dirait une mauvaise skin WinAmp. En moins bien intégré.
Ma liberté vaut plus cher que ça.
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Flyinva . Évalué à 2.
Les goûts et les couleurs…
Mouais, elle ne doit pas valoir si cher que cela, tu laisses Google et les développeurs de CardDAV-Sync t'en priver.
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Christophe Boyanique . Évalué à 1.
C'est fou comment certains s'obstinent. Le monsieur te dit que google n'a rien à voir dans cette histoire.
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par Larry Cow . Évalué à 2.
Ok. J'ai voulu mettre une capture d'écran, mais il n'y en a pas sur le site d'aCal. Pas fous…
Heureusement, on arrive à en trouver ailleurs, genre : http://www.morphoss.com/products/android/aCal
# PHP, ou comment condamner un bon projet à sa naissance
Posté par Thomas Lecavelier . Évalué à -9.
Encore une bonne idée, encore un bon projet qui va attirer des libristes de bonne foi. Encore un projet qui va mourir à cause de sa structure de base: PHP.
Il est juste impossible qu'un projet de longue haleine survive à ce langage, passer une demi douzaine d'années d’existence, ce langage pourrit le source qui devient impossible à étendre, à maintenir.
Regardez statusnet: superbe idée, réalisation sympa mais PHP l'a rendu inamovible, voir même difficile à installer à cause des incompatibilités de versions, de configuration, de stack webserver/php.
En temps normal, je serais le premier à tester ownCloud dans tout les sens, vérifier toutes ses fonctionnalités, remonter des ano', publier de la doc. Mais là, non. Pas envie. Pas envie d'investir dans un mort-né.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
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…
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 7.
Je ne comprend pas qui tu critique. Owncloud pour ne pas mettre en place des solutions ou c'est une critique générale sur le manque de solution de ce type que pourrait utilisé owncloud ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
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
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 5.
Le problème, c'est que tu compare des choses qui n'ont rien à voir, par exemple, samba utilise un protocole connecté, et ne doit pas forker à chaque rapatriement de fichier alors qu'avec HTTP, tu dois faire un fork à chaque clic de l'utilisateur (ou presque) ou alors tu maitiens des serveurs sous différentes identité avec un timeout mais il faut gérer la communication avec le serveur central. J'ai l'impression que ça risque d'introduire plus de faille que de sécurité.
Déjà, il me me semble que pas mal d'hébergement web ne propose qu'un seul login, du coup, ça revient au même.
Pourquoi ne pas faire un montage webdav ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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 !
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 3.
Et ce n'est pas du tout répandu et certains sont très critique sur la technologie parce que ça monopolise inutilement des ressources.
Je suis d'accord mais il faut l'implémenter à un moment ce design.
Je parlais d'un seul login de bdd.
Si tu écrit ton code de manière à empêcher l'injection SQL, ça n'arrive pas non plus.
Et les données ont été volée/détruite et tu as uniquement l'adresse mail de la personne (dans le meilleur des cas), si le compte n'a pas été piraté. Donc tu n'es pas vraiment plus avancé.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Arg… J'héberge tous mes serveurs (RENATER) donc j'oublie parfois les contraintes du privé ;-)
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 !
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 3.
Et combien concerne la page de login ? Vu qu'après on fait ce qu'on veut de toute façon.
Mais la problématique principale, c'est le vol d'information, on s'en fout un peu de perdre les données la plupart du temps (il y a le backup). Mais tes utilisateurs ne seront pas content qu'on leur ait volé leur adresse mail ou numéro de carte de crédit.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . Évalué à 0.
Les WebSockets ne sont pas triviales à mettre en place, le support au niveau des HTTPd est souvent expérimental, ou existe uniquement sous la forme de plugins contribués non officiels.
Il ne faut pas oublier que les WebSockets sont un gros hack du protocole HTTP, qui a probablement inventé parce que les gens ont oublié ce qu'est un socket à la base. C'est bien c'est beau c'est vendeur et ça passe les proxy, supaire, mais en dehors de ça, c'est une surcouche bien immonde au protocole HTTP (qui n'a jamais été conçu pour ça), et en dessous c'est pas encore super bien pris en charge par l'écosystème applicatif actuel.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par rakoo (site web personnel) . Évalué à 1.
Owncloud propose deja de faire du webdav. Et comme il s'agit d'un fs tout bete en dessous, tu peux deja faire du samba/NFS en parallele. Ou alors tu veux les mettre dans owncloud ? Ca m'a l'air de ressembler a une petite usine a gaz …
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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…
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 3.
Les fichiers apartiennent à www-data mais il y a peut-être moyen de jouer avec les acl pour que ça soit possible. Par contre, je ne vois pas l'intérêt de faire du samba en parallèle du webdav.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
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.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 4.
Je ne suis pas sûr que monter l'aborescence entière dans owncloud soit une bonne idée. Il vaut mieux partir sur un truc mixte ou abandonner owncloud qui n'a pas l'air de correspondre à tes besoins.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
De mon experience, suexec n'est pas vraiment pénalisant. Le problème est surtout de passer de module vers fastcgi.
En fastcgi tu as moulte solutions qui permettent de contourner ce problème : suexec, spawn_fcgi, php-fpm
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
# apt-get install apache2-mpm-itk
Problème réglé.
Y'a aussi le MPM PerUser qui est plus efficace il paraît, mais je crois pas qu'il soit déjà dispo dans debian.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 3.
Ce n'est pas spécifique par vhost?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
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.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par djano . Évalué à 2.
Oui python a le GIL :)
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par François LE QUEMENER (site web personnel) . Évalué à 5.
La mauvaise structure vient plutôt de l'écriture de code et de la gestion de projet, pas du langage. Il est tout a fait possible de créer des projets dans la durée en PHP (les exemples ne manquent pas : SPIP, Wordpress, Magento…), comme il est possible de faire des projets jetables en Java.
Là où je suis d'accord, c'est que le PHP n'est utilisable pour des projets sérieux que depuis pas très longtemps.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par rycks . Évalué à 7. Dernière modification le 24 mai 2012 à 09:38.
Mouarf, le troll est lancé … et alors si le mec code du php avec <trouve un éditeur trollistique du genre emacs/vi/kate/gedit/netbeans> sur une <distribution trollistique windows/osx/ubuntu/android> avec deux <instruments trollesques pieds gauches/moufles/yeux bandés> tu dis quoi ?
Patience, encore 24h et on pourra se lâcher :)
eric.linuxfr@sud-ouest.org
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par YBoy360 (site web personnel) . Évalué à -2. Dernière modification le 24 mai 2012 à 09:46.
Je pense exactement comme toi, tous les projets en PHP que j'ai installé en entreprise ont été désinstallés (il n'y en a pas non plus des masses). Les autres projets, tous basés sur Java tiennent de coup sans emmerder personne.
PHP ça permet de commencer sur les chapeaux de roue, ça plaît à l'administrateur car il peut directement taper dans le code, ça paraît simple à installer, c'est assez séduisant sur certains aspects, surtout il y a de nombreuses solutions clé en main.
Maintenant, quand on commence à voir tout ce que l'on peut faire avec d'autres technologies (je pense principalement au monde Java), où l'on est incité à utiliser des briques génériques, fiables, bien maintenus et hyper intégrées (prenez Grails, Talend, Kettle, Android, Spring, Shiro, je pourrai en mettre 3 pages …), qui offrent bien plus de souplesses dès que l'on commence à savoir tout ce que l'on peut faire avec, il y a pas photo.
C'est dommage que sur ce site, Java soit si mal vu. C'est vrai que les débuts en java sont plus compliqués qu'avec PHP, et que si l'on ne dispose pas d'un super IDE, Java c'est mort. J'ai changé d'avis sur Java à partir du moment où je me suis mis à Eclipse, après avoir commencé à développer des plug-in/Appli RCP avec (avant je ne jurai que par Qt).
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 8.
PHP a l'avantage d'être léger en mémoire alors que Java nécessite de base beaucoup plus de mémoire (et je m'en fous qu'il monte mieux en charge, je suis tout seul sur mon serveur, ou presque). C'est donc bien plus adapté aux petites installation que Java. Sur mon serveur, j'ai 256 mb de ram, avec mysql, pgsql, mail, plusieurs appli php différentes… je doute que java tiennent en plus là-dessus.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Pierrick Le Gall (site web personnel) . Évalué à 3.
Je suis parfaitement d'accord : Java c'est lourd dès le départ, ça consomme beaucoup de ressources même pour ne rien faire. Par contre, et cela a changé par rapport aux débuts de Java : c'est performant maintenant.
Il y a quelques années, je gardais à l'esprit le Java que j'avais appris à l'école (vers 2000) et qui était assez lent, notamment sur des serveurs d'appli comme Tomcat. Maintenant on peut dire que c'est très rapide, même s'il nécessit davantage de ressources que pour une appli PHP.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 7.
Je ne nie pas les performances, je parle uniquement de l'inadéquation avec la cible d'un projet comme owncloud.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Encore que ça dépend. Les applications web sont très rarement stateless. En PHP ça veut dire qu'il faut ajouter un stockage (base de données, fichier…) même pour des données temporaires.
Et je ne parle pas de la nature synchrone de PHP.
Si on prend en compte Apache + PHP + MySQL, pas sûr que les ressources nécessaires soient si faibles que ça comparées à une JVM + Jetty ou Tomcat.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 3.
Sauf que la plupart du temps, tu dois quand même avoir un stockage permanent. Tu as donc JVM + Tomcat/Jetty + MySQL/PgSQL comparé à PHP + Apache/nginx + MySQL/PgSQL.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . Évalué à 2.
Déjà il ne faut pas comparer l'incomparable: les applications Java tournent souvent dans un serveur d'application au sein duquel la mémoire est partagée pour toutes les requêtes entrantes.
PHP fonctionne en mode CGI, quant bien même il consomme peu de mémoire (et ce n'est pas toujours vrai, ça dépend de l'application au dessus) toutes les requêtes entrantes vont consommer sensiblement la même quantité de mémoire. Ceci y compris quand on l'utilise en mode démon (FPM et ancêtres).
La conséquence de ceci c'est que PHP consommera linéairement autant de mémoire que de requêtes concurrente arrivent, ce qui normalement ne se produit pas quand on utilise un serveur d'application portant des applications bien conçues capable de partager correctement les ressources.
Encore une fois, ça reste incomparable et cette remarque est non pertinente car la consommation mémoire dépend de l'application, pas du langage, et très peu de la VM (car oui, PHP aussi fonctionne dans une VM).
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par claudex . Évalué à 5.
Il faut lire les parenthèse, tu parle des avantages avec plusieurs utilisateur, ce qui n'est pas du tout la situation que je décris. Le serveur d'application et la jvm ont une occupation mémoire non négligeable pour une utilisation avec peu de connexion.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . Évalué à 2. Dernière modification le 24 mai 2012 à 14:50.
Bien sûr, mais ça reste un détail important.
Entre parenthèses, concernant l'utilisation mono-utilisateur, ça ne veut pas dire que ton application ne va pas essuyer des traitements parallèles, surtout dans le web d'aujourd'hui où les applications vont aller s'amuser à faire des requêtes HTTP asynchrones dans tous les sens (AJAX) etc…
De plus, dans le cadre d'une application comme OwnCloud, on va très vite, même si mono-utilisateur, y brancher plusieurs logiciels (client mail, client pour son calendrier, montages WebDAV pour les fichiers, lecture de musique en ligne, etc…), ce qui tend à faire exploser le nombre de requêtes parallèles que va traiter ton application.
Même tout seul, ma remarque à un peu de sens, encore une fois ça dépend de l'application.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Pierrick Le Gall (site web personnel) . Évalué à 3.
Sauf que owncloud n'a, à mon avis, pas vocation à être installé "en entreprise". La technologie utilisée dépend aussi du contexte. Il n'y a pas un langage miracle qui s'adapte à toutes les situations.
On ne peut pas comparer une appli lourde comme Talend (j'ai fait parti de l'équipe de dev des premières versions) à une appli web comme Owncloud. De même qu'on n'écrit rarement des scripts en Java ou en PHP mais plutôt en Shell ou en Perl.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par meumeu1402 . Évalué à 3.
Faux …
enterprise-edition
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par GEDsismik (site web personnel) . Évalué à 3.
Java est un excellent langage. Il a été bien pensé, est suffisamment strict pour limiter (j'ai dit limiter mais pas éviter) le mauvais code, est normalisé et propose par défaut le support de beaucoup de chose. Le langage est bon. Par contre, les JVM…
Aussi, je préfère en général miser sur une appli codée proprement en langage comme le PHP et me servir d'Apache HTTP Server que de d'installer une application JavaEE qui plombe les perfs de la machine, requiert souvent son propre serveur d'application et sa propre JVM (parce que l'application n'est compatible qu'avec une certaine version de JVM qui n'est pas forcément celle installé avec l'OS et encore moins celle des autres applications qui tournent sur la machine. Véridique).
Les projets PHP ne durent pas forcément en entreprise parce qu'ils sont gratuits. Quand ils ont un support payant ou que l'entreprise est de taille modeste, ils sont plus pérennes. Même si il y a dans le lot des projets mal codés, la durée de vie n'est pas forcément liée à la qualité du langage. Et à contrario, les produits Java (notamment JavaEE) que je vois déployé font pour la plupart chier les gens.
Il s'agit de deux manières de penser un peu différente. A mon sens, exclure un projet parce qu'il a été développé en PHP est un mauvais argument.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par YBoy360 (site web personnel) . Évalué à 1.
Je ne parle même plus du "langage" java, mais de la plateforme. Prends un truc comme AspectJ, comme Spring, comme Grails, on est loin de seulement "le langage java". Tout ça est parfaitement intégré, tu fais un site plus rapidement qu'avec Drupal (avec plus de souplesse et de vrais perfo, malgré Groovy … ).
Je veux surtout pas critiquer OwnCloud, je trouve que l'idée est super, juste, arrêtez de moinsser systématiquement les mecs qui parle de Java, c'est vraiment dommage, c'est très riche comme univers, le libre y est très présent et très souhaité.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par B16F4RV4RD1N . Évalué à -1.
c'est pas ce que souhaite Oracle visible, vu qu'ils font des procès à ceux qui, comme Google, utilisent la liberté induite par sa libération.
D'autre part, pour un logiciel destiné à être utilisé sur le maximum de serveurs web, qui ne mettent pas forcément à disposition java, ruby, python et autres, le php me semble indispensable.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par ckyl . Évalué à 3.
Il n'y a absolument aucun rapport entre la création d'OpenJDK et l'utilisation de Java pour android. Android utilise une VM home made plutôt qu'Hotspot et la bibliothèque ne respect pas Java SE et utilise Apache Harmony commme base. Et la création d'OpenJDK n'a rien changé quand à la possibilité, ou non possibilité, et d'implémenter Java.
[^] # Re: PHP, ou comment condamner un bon projetàsa naissance
Posté par Juke (site web personnel) . Évalué à 7.
Foutaises !
[^] # Re: PHP, ou comment condamner un bon projetàsa naissance
Posté par YBoy360 (site web personnel) . Évalué à -6.
Très drôle. Tu mérites franchement un +10, tu dis Preums au prochain message?
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Pierrick Le Gall (site web personnel) . Évalué à 8.
Merci, j'ai bien ri :-)
La survie/évolution d'un projet n'est pas uniquement lié au langage utilisé. La maintenabilité d'un code varie surtout en fonction des développeurs et non du langage.
Techniquement PHP est une excellente solution car facile dès le départ, très performante et disponible absolument partout sur les serveurs web, surtout mutualisés. Va déployer du Java, Ruby ou du Python sur des offres mutualisées, c'est très compliqué.
Je suis bien content d'avoir démarré Piwigo en PHP il y 10 ans et de constater qu'il continue à évoluer et qu'il reste tout à fait lisible, simple dans son architecture et qu'il est installable sur n'importe quel offre d'hébergement mutualisée.
Les exemples de projets en PHP démarrés il y a plus de 6 ans sont nombreux (Wordpress, Drupal, Joomla, SPIP, Piwigo, des centaines d'autres) et montrent à quel point l'affirmation "PHP = condamnation du projet" n'a aucun fondement.
Retour de troll : je pense qu'aujourd'hui, le pire choix qu'on peut faire pour un projet qu'on veut distribuer, c'est Ruby car il n'est pas très dispo et très couteux en ressources.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par xcomcmdr . Évalué à 0.
Comment ça très coûteux en ressources ?
Tu as des chiffres ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Pierrick Le Gall (site web personnel) . Évalué à -2.
Non, je n'ai pas spécialement de chiffre. Simplement des mauvaises expériences : sur un serveur dédié tout simple, faire tourner une appli Ruby on Rails avec une configuration par défaut ça fait vite planter le serveur dès que la fréquentation augmente.
Par exemple, j'ai voulu remplacé Trac (gestionnaire de projet en Python) par Redmine (gestionnaire de projet en Ruby) et plantages rapides du serveur. Déjà que Trac est très consommateur, c'était encore pire avec Redmine. Je suis resté sur Trac car je n'ai pas trouvé d'équivalent en PHP malheureusement. Mais j'ai dû faire des recherches et divers essais de tuning côté serveur pour réduire la consommation de ressources. Cette nécessité n'arrive que très rarement en PHP, le couple Apache + mod_php étant par défaut très performant (même si on peut faire beaucoup mieux avec du nginx par exemple).
L'une des grandes forces de PHP, c'est que l'environnement d'exécution est simple à mettre en place, par défaut très performant et peu consommateur.
Cela ne veut pas dire que Ruby c'est nul dans l'absolu. C'est sans doute intéressant pour des projets "spécifiques" qui n'ont pas vocation à être distribués (encore faut-il trouver des développeurs Ruby… et là encore PHP domine)
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par xcomcmdr . Évalué à 2.
Heureusement que Twitter et GitHub n'utilisent pas Ruby On Rails alors : http://rubyonrails.org/applications
Et que personne n'utilise Redmine: http://www.redmine.org/projects/redmine/wiki/WeAreUsingRedmine
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Pierrick Le Gall (site web personnel) . Évalué à 1.
Twitter et Github c'est exactement ce que j'appelle un logiciel qui n'est pas distribué : c'est un développement "spécifique", qui tourne sur une infrastructure spécifique et optimisée pour ce cas d'utilisation. Je suis convaincu que le choix de Ruby On Rails n'est pas une mauvaise idée dans ce genre de cas. La clef de mon argumentaire, c'est de savoir si le logiciel a pour vocation d'être largement distribué ou non.
Concernant Redmine, oui je suis d'accord qu'il y a des utilisateurs et que c'est un super produit fonctionnellement parlant. Simplement faut pas vouloir l'installer sur un environnement très basique, ou alors il y a eu des gros progrès depuis mes dernières tentatives avec un environnement simple à installer, sans configuration avancée et qui consomme peu de ressources.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par feth . Évalué à 7.
PHP est troué tous les matins, les corrections de bugs de sécu PHP se contentent de changer la forme de la faille. Les tests unitaires sur PHP qui ne passent pas ne paniquent personne. D'ailleurs personne ne comprend comment les décisions sont prises, sur PHP.
Un exemple parmi des milliers d'explication de ce qui ne va pas : http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Mais bon, comme on dit, PHP est populaire, des millions de codeurs ne peuvent pas se tromper.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . Évalué à 0.
PHP ne fait pas que corriger des failles de sécurité qui lui appartiennent, mais pose aussi des brides liées au protocole HTTP, que les serveurs web eux-même ne corrigent pas toujours.
Dire que le langage est mauvais parce qu'ils corrigent beaucoup de failles et un peu facile, il faut aussi se placer dans le contexte.
Pour information, la dernière fois que j'ai lancé les tests unitaires de PHP, seuls 7 (sur plusieurs milliers) ne sont passés, et ce sont des comportements connus liés à l'architecture 64bits, qui, à ma connaissance, n'ont pas d'impact sur le code utilisateur.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par feth . Évalué à 3.
J'aime bien cette synthèse de l'histoire récente par haypo : https://plus.google.com/u/1/111631720833482085895/posts/9LD6Bg1UbHk
Et je n'ai pas l'impression que ça parle de bugs liés à HTTP.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . Évalué à 5. Dernière modification le 24 mai 2012 à 17:42.
Le protocole HTTP n'a pas de bugs en soit, probablement des failles je ne suis pas assez expert sur le sujet pour en discuter, cependant pour ce qui est de PHP, un certain nombre de récents patch on mis place des protections contre d'éventuelles DDoS liés à des envois excessifs de données pouvant amener à des écrasements de données.
De mémoire, ce n'est pas le seul langage/application à mettre en place ces protections dans le même laps de temps. Faudrait que je retrouve des liens là dessus.
Plusieurs choses:
- Déjà, le lien fourni qui pointe vers un bug Ubuntu repose sur une version PHP patchée Suhosin, ce qui déjà en soit potentiellement induit des comportements différents de PHP vanilla;
- De plus, il est lié à une fonctionnalité obsolète (magic_quote_gpc) que plus personne n'utilise. Dans les applications récentes les seules références qu'on puisse en voir sont souvent pour corriger des problèmes liés à un environnement où cette option obsolète serait par mégarde activée. Les applications PHP qui nécessitent cette option ont surement de beaucoup plus gros problèmes puisqu'apparemment elles n'ont pas évolué depuis 10 ans (contrairement au langage et à la VM);
- En ce qui concerne les régressions qu'il indique, on peut quand même voir que l'espacement entre la release qui créé cette régression et celle qui la corrige est un peu plus de deux semaines, c'est certes beaucoup, mais aucune distribution considérée comme stable n'aura normalement mis à jour à ce rythme là.
On pourrait en discuter pendant longtemps, et oui PHP à beaucoup de bugs, mais c'est pas le seul. J'ai bien l'impression que les gens ici s'acharnent sur un langage qu’apparemment ils ne connaissent pas ou peu. Sa couche objet était certes très pauvre jusqu'à peu, ils ont fait des choix étonnants en terme de syntaxe, mais je veux dire, d'autres l'ont fait aussi, certains langages sont encore whitespace based (WTF seriously).
Attention, ne vous méprenez pas, j'ai beau le défendre, je donnerais beaucoup pour retourner faire du Java ou du C# de temps en temps; je ne suis ni un fanatique, ni un molusque mono-langage, cependant j'aimerais quand même que les gens soient un peu plus objectifs quand ils émettent ce genre de critiques.
Pour travailler avec la stack L**P presque quotidiennement depuis quelques années, je sais ce très bien ce qu'il en est des bugs PHP, j'en rencontre moi même de temps en temps, mais dans l'absolu, à l'utilisation quotidienne, une bonne connaissance du langage et de ses capacités produisent du code qui n'est quasiment jamais impacté.
Et puis, très honnêtement, avant de pouvoir exploiter une faille d'exécution de code arbitraire, faut déjà avoir la main sur la machine ou tomber sur une application qui ne filtre aucune entrée utilisateur, c'est pas trivial.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par feth . Évalué à 2. Dernière modification le 24 mai 2012 à 22:37.
Merci de cette réponse argumentée. Pour ce qui est de langages dans lesquels chaque caractère tapé a un sens (whitespace based, donc), perso je trouve ça beaucoup plus ergonomique, et je ne suis pas très surpris que Python, parce qu'il est conçu et utilisé par des perfectionnistes (contrairement à PHP) soit le langage de choix pour l'enseignement de la programmation aux jeunes.
Pour ce qui est des dernières failles PHP, elles sont consternantes puisqu'à plusieurs reprises il s'agissait de corriger le correctif précédent…
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . Évalué à 1.
Oui ça déborde parfois un peu chez PHP, mais globalement ça corrige plus de choses que ça n'en rouvre à travers le temps, ce qui fait que en moyenne en ça.
Content que t'ai vu ma petite pique sur Python, c'était juste gratuit^ J'en fais moi même de temps en temps.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par jroger . Évalué à 3.
La programmation c'est trivial: des boucles et des conditions.
Après si les devs sont inexpérimentés et/ou bordéliques, qu'ils n'analysent pas avant de coder, qu'ils ne structurent et ne documentent pas correctement, ça fera une bouse quel que soit le langage utilisé.
En fait, le langage on s'en fout un peu. Les raisons d'en choisir un plutôt qu'un autre, c'est la prise en compte de l'existant, la plateforme utilisée, le coté économique, les affinités des devs, et parfois un peu l'adaptation technique au projet.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par barmic . Évalué à 2.
Des exemples de projets en PHP, Java, Perl, Python, Ruby ou C# qui se sont cassé la gueule sur la techno tu pourra toujours en trouver. Le premier point vraiment important c'est d'utiliser une techno que tu connais. Il vaut mieux un ownclound en forth qu'en . Ensuite la maintenabilité c'est une question de génie logiciel plus qu'autre chose.
Au passage pour des contre-exemples facebook utilise PHP uniquement comme langage (tout le reste c'est du natif), comme quoi ils s'attachent et s'investissent (développer un compilateur PHP->C++) réellement dans ce langage c'est que ça doit leur plaire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Littleboy . Évalué à 3.
Disons que lorsqu'on trouve ce genre de truc dans le code source, on peut commencer a se poser certaines questions (genre si la securite du truc est du meme niveau…)
Ou parce qu'ils ont une large base de code dans ce language (et l'experience) et que ca serait tres con de tout reecrire.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par barmic . Évalué à 2.
Oui et ce n'est pas une question de langage.
Je ne sais pas ce qui est le plus « con » entre récrire sa base de code ou réécrire toute la stack sous le langage (même s'il s'agit de réutiliser un langage et des bibliothèques existantes, dans les deux cas).
D'un point de vu taille de la tâche non plus je ne sais pas ce qui est le plus lourd, d'un coté tu reste sur un domaine où tu as un tas de compétences internes (tu change de langage mais tu reste sur du web avec du HTML, du js et de l'HTTP) de l'autre tu doit acquérir des compétences en analyse syntaxique, etc pour écrire ton compilateur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Owncloud social
Posté par MTux . Évalué à 6.
Mon idée va paraitre étrange, mais quand je vois l'étendue des fonctionnalités de Owncloud je me dis qu'avec des plugins sociaux ce serait le remplaçant de facebook, ou du moins l'alternative libre que nous attendons. Du moins bien plus proche que movim et diaspora qui visent à être des copies qui seront prêtes quand la mode sera terminée c'est à dire trop tard.
Owncloud permet de gérer l'intégralité de nos documents, de la musique aux photos en passant par les fichiers Open/Libre-Office, et avec un système de timeline partagée on pourrait faire quelque chose de bien…
# Chiffrement???
Posté par Olivier Filipe . Évalué à 4.
Bonjour,
Il est écrit que cette nouvelle version apporte le chiffrement des fichiers sur le serveur.
D'accord mais c'est quoi comme chiffrement quel est l'algo utilisé?
Parce que j'ai cherché sur leur site (bon ok pas très longtemps) mais je n'ai pas trouvé.
[^] # Re: Chiffrement???
Posté par Memiks (site web personnel) . Évalué à 3.
peut etre dans le gitorious:
https://gitorious.org/owncloud/owncloud/blobs/master/apps/files_encryption/lib/crypt.php
Blowfish apparemment…
[^] # Re: Chiffrement???
Posté par mickabouille . Évalué à 1.
D'après quelques commentaire que j'ai vus là https://lwn.net/Articles/498163/ de gens qui ont regardé le code, c'est pas terrible.
Le chiffrement est fait sur le serveur, donc si on récupère le fichier chiffré (donc on a déjà compromis le serveur…), on a tout le temps qu'on veut pour casser le chiffrement.
[^] # Re: Chiffrement???
Posté par Larry Cow . Évalué à 3.
Si on a le fichier chiffré, qu'est ce que ça change qu'il ait été chiffré sur le serveur ou le client?
[^] # Re: Chiffrement???
Posté par teoB . Évalué à 2.
Je n'y connais pas grand chose, mais a priori, je dirais que si c'est le serveur qui chiffre/déchiffre et qu'il est compromis, le pirate récupère le fichier chiffré et potentiellement les clefs de chiffrement/déchiffrement. Alors que si c'est le client qui chiffre, le serveur compromis, seul le fichier chiffré est disponible, ce qui avec un chiffrement fort ne sert pas à grand chose.
[^] # Re: Chiffrement???
Posté par claudex . Évalué à 5.
Si le serveur est compromis, l'attaquant modifie le js qu'il envoie au client pour ne pas chiffrer les données (ou chiffrer avec sa clef) et il obtient les données.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Chiffrement???
Posté par jyes . Évalué à 3.
Ça va toutefois être plus compliqué de faire exécuter le JavaScript au client à travers WebDAV…
# ownCloud Sauvegarde en ligne
Posté par Totoffe (site web personnel) . Évalué à 2.
ownCloud pourrait bien être la solution que je cherche pour me faire une sauvegarde de mon home sur mon hébergement.
En effet, j'avais plus de 90 Go dispo sur mon hébergement et un home de 70 Go. Mais j'hésitais encore sur la manière de procéder :
tout envoyer dans un dossier dédié avec un bon gros rsync : pas pratique à consulter (mais c'était pas le but recherché), et surtout risqué : si un vilain trouve une faille dans un des logiciels sur le reste de mon hébergement (dotclear, iGalerie, etc.), il va pouvoir se balader dans les répertoires et donc faire ses courses dans mes fichiers perso.
Faire un gros .tar.gz chiffré et l'envoyer : sécurisé, mais impossible à maintenir à jour, je me vois mal re-génerer une grosse archive tous les jours et uploader 70 Go à chaque fois !
Du coup, si ownCloud chiffre côté serveur, ça pourrait être la bonne solution : un logiciel client qui maintient à jour les fichiers sans qu'on ait besoin de s'en occuper, un chiffrement côté serveur qui permet de ne pas craindre qu'on vienne se servir dans vos fichiers perso, et cerise sur le gâteau, la possibilité de consulter de n'importe où.
Je vais donc étudier ça en détail, notamment le chiffrement utilisé, et voir si c'est installable sur mon hébergement chez Octave de Roubaix.
[^] # Re: ownCloud Sauvegarde en ligne
Posté par ckyl . Évalué à 4.
Premièrement les hébergeurs un tant soit peu sérieux te proposent d'avoir autant de login que tu veux pour un compte d'hébergement. Donc tu peux cloisonner tes applications.
Deuxièmement des solutions de backup qui chiffrent, ca existe depuis des lustres. Duplicity en est un parmi d'autres.
[^] # Re: ownCloud Sauvegarde en ligne
Posté par Psychofox (Mastodon) . Évalué à 5.
franchement pour du backup, owncloud est overkill.
rsync + gpg fait déjà beaucoup.
[^] # Re: ownCloud Sauvegarde en ligne
Posté par rakoo (site web personnel) . Évalué à 1.
Heureusement que des outils existent pour ca, notamment duplicity. Ya meme une super GUI chez Ubuntu qui marche du tonnerre.
On en revient a la polemique classique : si c'est le serveur qui chiffre, il peut avoir acces a tes donnees (puisqu'il a la cle). A l'inverse, duplicity chiffre tes donnees du cote client, et stocke que de l'incomprehensible sur le serveur.
[^] # Re: ownCloud Sauvegarde en ligne
Posté par Anthony Jaguenaud . Évalué à 1.
Le problème se pose de la sauvegarde de la clé… parce que si ton PC craque, tu as accès à du bruit :-)
Pour ce cas là, soit un certificat sur plusieurs clés USB, soit une pass-phrase pour le chiffrage, soit une pass-phrase pour chiffrer le fichier certificat. Dans tous les cas, c’est la pass-phrase le maillon faible.
# C'est très bien, mais...
Posté par Romuald Riem . Évalué à 1.
J'ai installé ownCloud pour l'évaluer. Cela à l'air très intéressant, mais il a un petit problème (ou un gros bug) avec le module de lecture des fichiers ODF.
En attendant que cela soit réglé, il semble préférable de le désactiver, ou de réaliser une petite manœuvre d'édition d'un fichier (il faut supprimer une ligne vierge, voir iciou là.
Je ne veux pas entrer dans une polémique quelconque sur la valeur du PHP ou autre mais je suis surpris de constater qu'une simple ligne vierge puisse être à l'origine d'un tel disfonctionnement.
[^] # Re: C'est très bien, mais...
Posté par eMerzh (site web personnel) . Évalué à 2.
Le plugin ODF viewer est corrigé dans le gestionnaire de code et une version de maintenance devrais sortir d'ici une semaine…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.