Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Self-hosted alternatives to popular cloud services

liminality.xyz

Post reply on HN
Print view View original

111–120 of 148 posts

Re: Self-hosted alternatives to popular cloud services

#111

Post by gingerlime »

hiq wrote: post #31
pmlnr wrote: post #18

some other weapons of choice: WordPress - https://wordpress.org/ - because "WordPress is the Kalashnikov of the web." ( https://t.co/QgsYYUFTbo ) Syncthing - https://syncthing.net/ - for distributed file syncing Baikal - http://baikal-server.com/ - for contact & calendar syncing rss2email - https://pypi.python.org/pypi/rss2email - because email is stable, solid, and not going anywhere Tox - https://tox.chat/ - p2p, e…

Syncthing is awesome, I don't understand why some people still use bittorrent sync. If you use ownCloud only for file syncing you'd also be better off using Syncthing instead. The developer is also a super nice guy, answering all bug and performance reports on github. Regarding contact & calendar syncing, I just wish more apps could just use files instead of always setting a new server and reinventing the wheel to sy…

I'm really tempted to switch but do they have an iPhone app? It's quite useful to sync my photos with my desktop using btsync

Re: Self-hosted alternatives to popular cloud services

#112

Post by antsar »

sytse wrote: post #103
favadi wrote: post #101

Earlier quoted context omitted.

Its official installer doesn't contain a 3 web servers, 1 CI server and 1 chat server?

:) Thanks for your response. For other people some context, the GitLab Omnibus packages contains one web server (nginx, but you can also use it with Apache). The CI server is now integrated in GitLab itself (no longer a separate app). And you have the option to run Mattermost (but if you choose not to set this up it will not consume any ram or CPU). The Omnibus packages allow you to quickly install GitLab without hav…

Just wanted to +1 the parent comment. I'm sure you're tired of hearing this, but it feels pretty backwards that we have to disable parts of the installation just to get it to work alongside other stuff (with a shared nginx instance, etc).

Its understandable why you wanted to bundle everything, and I bet it makes installation much easier for beginners and/or lazy sysadmins.

That said, it would be even better if the installation worked with existing software instead of installing its own copy of everything. It seems like apt package dependencies would be more elegant than bundling everything together.

Its great to have the installation from source as a supported option. But lets be honest, that's a world of pain that's simply unnecessary for a standard deployment.

- A happy GitLab user

Re: Self-hosted alternatives to popular cloud services

#113

Post by unethical_ban »

kentonv wrote: post #16

"N self-hosted alternatives to popular cloud services" is becoming a meme. Here's 43 self-hosted alternatives to popular cloud services, with one-click demos you can try yourself! https://apps.sandstorm.io/ Tiny Tiny RSS, Ghost, Gitlab, and Rocket.Chat are in there. ownCloud is missing, but you can try Davros, which is compatible with the ownCloud client apps. https://apps.sandstorm.io/app/8aspz4sfjnp8u89000mh2v1xrdy…

The problem with sandstorm is the dependence on third-party auth. Until sandstorm has internal user stores, it's not a viable self-hosting solution.

Re: Self-hosted alternatives to popular cloud services

#114

Post by thaumasiotes »

kentonv wrote: post #16

"N self-hosted alternatives to popular cloud services" is becoming a meme. Here's 43 self-hosted alternatives to popular cloud services, with one-click demos you can try yourself! https://apps.sandstorm.io/ Tiny Tiny RSS, Ghost, Gitlab, and Rocket.Chat are in there. ownCloud is missing, but you can try Davros, which is compatible with the ownCloud client apps. https://apps.sandstorm.io/app/8aspz4sfjnp8u89000mh2v1xrdy…

My first RSS reader was self-hosted. When I went away on vacation and came back to learn that my computer had shut down during that time, I switched to Google Reader.

Re: Self-hosted alternatives to popular cloud services

#115

Post by tedunangst »

thaumasiotes wrote: post #114
kentonv wrote: post #16

"N self-hosted alternatives to popular cloud services" is becoming a meme. Here's 43 self-hosted alternatives to popular cloud services, with one-click demos you can try yourself! https://apps.sandstorm.io/ Tiny Tiny RSS, Ghost, Gitlab, and Rocket.Chat are in there. ownCloud is missing, but you can try Davros, which is compatible with the ownCloud client apps. https://apps.sandstorm.io/app/8aspz4sfjnp8u89000mh2v1xrdy…

My first RSS reader was self-hosted. When I went away on vacation and came back to learn that my computer had shut down during that time, I switched to Google Reader.

Curious. I had the opposite experience. Went away on vacation and came back to learn Google Reader had shut down.

Re: Self-hosted alternatives to popular cloud services

#116

Post by LukasReschke »

gingerlime wrote: post #109
LukasReschke wrote: post #44

Earlier quoted context omitted.

> Here's their 'Records of security issues' page: https://seacloud.cc/group/3/wiki/security-records/ Just take a look who reported their recent issue allowing a lot of attack vectors. (more than they mentioned though) :) Actually if somebody had a local user account themselves they could bruteforce the secret key in seconds. And SeaFile has additionally modified the default Django components making it more insecure:…

On mobile so please excuse me if I missed something subtle, but what's more insecure about this change? From what I know constant time compare protects against timing side channel attacks, so isn't it improving security here?

That was actually the part where they partially mitigated the vulnerability with. So before it was more insecure. The green one is the "fix" :)

The constant time comparison is pretty irrelevant here. Check https://github.com/haiwen/seahub/commit/7cdb70368aa7acbf0546..., basically a valid password reset token in default Django requires an attacker to know:

- Primary Key of the user (User ID)

- Hashed version of the user password

- Timestamp of the last login (1 second accuracy)

- Number of days since 2001-1-1 converted to base 36

- The configured SECRET_KEY

Basically except the configured SECRET_KEY and the hashed version of the password everything is known to an attacker. And even if an attacker knows the SECRET_KEY they would not be able to generate a valid token as the old password hash is required.

However, Seafile has removed the hashed password out of their version of "tokens.py". This means that if somebody knows the SECRET_KEY they could create valid password reset tokens. That the initial SECRET_KEY was basically generated by `str(random.randint(0,100000))` did make this all much more worse… (https://github.com/haiwen/seahub/blob/b6f8935c0f355cc70145f9...)

Bad thing about this is that this basically makes a lot of old Seafile instances insecure unless they get a new SECRET_KEY. They did somewhat tell users to regenerate it within a forum post and some wiki page (https://seacloud.cc/group/3/wiki/whats-new-in-the-next-versi...) but that's not really a good way to spread awareness…

Re: Self-hosted alternatives to popular cloud services

#117

Post by fapjacks »

OwnCloud eats files in the most insidious manner, and this is known to the devs, who in the past have suggested that the workaround is to use another sync application. DO NOT USE OWNCLOUD if you value your data!! We discovered OwnCloud eating files after about three months of office paranoia, beginning to wonder if it was an inside job of a disgruntled employee. Turns out it was an inside job of incompetent software.

Also OwnCloud DOES NOT support "delta sync" (i.e. uploading file chunks when tiny portions of files are changed, instead of, for example, needing to upload the ENTIRE gigabytes-large file when only 10KB have changed). The core devs have kicked the can down the road at every opportunity (for example take a look at the huge BountySource bug for that issue, it's like USD 1200 or something, in addition to the issue being locked to contributors because of all the +1s). This means for any use case involving large files (e.g. TrueCrypt/VeraCrypt volumes), you will quickly find yourself in a messy situation of continually uploading gigabytes of data. It was painful to experience even on a gigabit LAN.

Re: Self-hosted alternatives to popular cloud services

#118

Post by XJOKOLAT »

tedunangst wrote: post #115
thaumasiotes wrote: post #114

Earlier quoted context omitted.

My first RSS reader was self-hosted. When I went away on vacation and came back to learn that my computer had shut down during that time, I switched to Google Reader.

Curious. I had the opposite experience. Went away on vacation and came back to learn Google Reader had shut down.

LOL, sorry. Brilliant.

Re: Self-hosted alternatives to popular cloud services

#119

Post by kentonv »

unethical_ban wrote: post #113
kentonv wrote: post #16

"N self-hosted alternatives to popular cloud services" is becoming a meme. Here's 43 self-hosted alternatives to popular cloud services, with one-click demos you can try yourself! https://apps.sandstorm.io/ Tiny Tiny RSS, Ghost, Gitlab, and Rocket.Chat are in there. ownCloud is missing, but you can try Davros, which is compatible with the ownCloud client apps. https://apps.sandstorm.io/app/8aspz4sfjnp8u89000mh2v1xrdy…

The problem with sandstorm is the dependence on third-party auth. Until sandstorm has internal user stores, it's not a viable self-hosting solution.

You can log in to Sandstorm using any email address.

Eventually, we plan to support logging in using a PGP key.

We see "internal user stores" (e.g. basic username/password with no connected email address) as problematic because a major design goal of Sandstorm is the ability to move data between hosts easily. Say you and five friends have been using Rocket.Chat on Sandstorm Oasis, and then you decide to transfer it to a self-hosted Sandstorm server -- or vice versa. It would be nice if after moving, Rocket.Chat can still recognize your five friends and being the same people, so that you don't lose your PM history and such. This is only possible by using some form of federated identities which all Sandstorm servers can independently authenticate. Username/password is inherently per-server so doesn't provide that.

Post reply on HN