OwnCloud 6
owncloud.org
owncloud.org
If you're running ownCloud with nginx and php5-fpm on a low-performance host (not necessarily a Raspberry Pi but perhaps a cheap VPS) and keep getting "gateway timeout" errors when the desktop client uploads large files despite the relevant adjustments to php.ini [1] try to set
fastcgi_read_timeout 600;
for ownCloud's php files' location in the nginx site configuration file (e.g., /etc/nginx/sites-enabled/default). That resolved the problem for me. The timeout errors notwithstanding, the files that I tried (up to approx. 600 MB in size each) still got uploaded to the server and their checksums matched when redownloaded.Overall, it seems quite usable with the client; however, the web UI is painfully slow much of the time when hosted on the Pi.
Has anyone here used ownCloud "in production", which is to say, as a full-time replacement for Dropbox? Have you had any hiccups with synchronization?
[1] See, e.g., the first post at http://forum.owncloud.org/viewtopic.php?f=23&t=9440.
P.S. Although I wish they'd just use existing framework like ZF2 or Symfony2 instead of reinventing the wheel.
Edit: "Shoebox" jokes aside, their setup looks fairly impressive: http://www.raspberrypi.org/archives/3685.
[1]https://chrome.google.com/webstore/detail/butt-to-butt-plus/...
Hey mmanfrin, I wanna touch your cloud ;)
There's basically nothing that can achieve that level of deployability besides PHP.
Hearing that reasoning helped me with some of the concerns I had about its implementation language. It sounds like they know what they are doing, and are very careful (including careful code review), they just want the software to be as widely usable as possible.
http://owncloud.org/about/security/advisories/
I'll say to their credit that at least they're serious enough to publish security advisories.
Some of these errors just shouldn't be possible in a well written code base, though. I would never run OwnCloud on my own servers, or use it to store anything remotely sensitive.
for example, if you work with other people and you have a command to generate thumbnails from the shell, you may have a layout like this one
chmod user group path
2770 www-data devs /srv/www
2777 foo devs /srv/www/site/thumbnails/
/srv/www/site/thumbnails may be accessed only by people in the 'devs' or 'www-data' group ('foo' can read it only if he's in the group 'devs'). The obvious alternative would be to set that directory as owned by 'www-data', but you need root access to do that (unless you put everybody in group 'www-data', but then everyone can access every site). This way every user in the group 'devs' can make directories usable by both his teammates and the webserver, without having root power or being in group www-data. Have more than one team? Use different groups for each team.Agreed. Biblical implications aside, chmod 666 and chmod 777 are rarely a good idea.
(http://www.gotothings.com/linux/permissions-with-the-chmod-c...)
How so?
Unless you've used this service and have specific php security and maintenance concerns relating to this specific site?
By chance, setting up OwnCloud was my project for this afternoon and it is humming along nicely, but I always feel uneasy about exposing something to the interwebs that is only set up "sort-of" securely by some layman (me).