What I'm about to say applies just as much to appliances but making people think they can do everything with one-click breeds a load of ignorant and lazy "sysadmins" with very capable, very connected and extremely exploitable Linux servers sitting exposed (by design) on home networks.
The commoditisation of VPS (and cloud) servers brings exactly the same problem. Updates aren't automatic by default and so many VPS holders are devs sitting in Windows without a clue about anything past the `sudo apt-get install lamp-server^` they read on a forum. Months pass without updates and before you know it, there's a remote update a script can catch.
Webapp updating is another thing altogether. Relatively few are well packaged and even fewer have nice automatic update migrations. So they go stale and get exploited.
The [immediate] future of internet security looks pretty dismal.
This is true because only a few people are looking at how we should be writing, deploying and maintaining software for the cloud and embedded devices. There are other approaches out there which are getting more mature by the day, which (imho) are far superior. For example you can look over the Mirage work for an intro to the Unikernel approach.
I think there's a need for a small, self-contained system that is just so simple that it should be inherently secure and thus never need updating; HTTP and many of the related protocols are over a decade old, if not more. They should be so well-understood enough by now that a simple, correct implementation is possible. Maybe it will not have the latest features, but that's not the goal here - reliability and simplicity is.
Being able to host a personal site comprising a few static pages, which is something that would fit well with the goals of this project, shouldn't require all that much in the way of software; maybe even a full Linux kernel is overkill.
I definitely think you'd find the unikernel approach interesting and should take a look [1]. I've got a version of my website deployed this way too [2].
I guess what I meant was there any "heroku" like platforms that offer mirage. I've been kicking the idea around for a while (I think unikernel is the future of PaaS/SaaS/Cloud) and wondering what the field looks like. :)
Yup, I did understand what you meant but I stopped short of saying 'Heroku for Unikernels' (even though this how I think of it). I didn't want to give you a false impression of the first steps, which will be FOSS tools for anyone to deploy to the cloud. Ultimately, we may be able to run something as a service with much more fine-grained billing than current providers.
There are managed services for simple stuff. I'm not saying that self-hosting is impossible, I'm just saying that many are starting to run supercomputers with gigabit connections and aren't paying any attention to security "because it's Linux and that can't be hacked". Might sound stupid but a lot of people stumble onto Ask Ubuntu spouting things like that.
I'm not sure "never needs updating" is ever going to be achievable. As long as it's connected and there could be a vulnerability, it could be exploited.
So there are updates needed from time-to-time, but I agree that running a small webserver shouldn't require constant updates to fix neverending security bugs.
Have you ever wondered why "VPS (and cloud) servers" don't do the "sudo apt-get update && sudo apt-get upgrade && sudo reboot" automatically?
Anyways, if those Yuno people are smart enough, they do this once a day automatically via CRON. And if their systems are expensive enough, they consist of 2 redundant engines.
I mean just think of a file server. Everybody can tell you how much of a security nightmare an FTP server is. Why? Probably because the ftp daemons are so complex and have so many options. So people turned to Dropbox and other expensive but simple solutions.
I wouldn't like to perform update && upgrade (and also reboot!) automatically every day or so. Why? Because updates/upgrades are always something that should be overseen by a capable administrator. Sometimes updates break, sometimes they override your personal config files with less secure default files, sometimes the system crashes and you're left in an inconsistent and dangerous state, etc etc.
I definitely don't want to automate my server's updates in such a way.
I haven't looked too closely at this particular project, but if I were writing something similar, I'd explicitly make it hard to access any of the security-related settings, and make the defaults (for which upgrades are tested) secure by default. In this case, changes to security settings to deal with new threats would be distributed through the package update mechanism, not overridden by it.
That is, the really interesting target user here is not the one who will drop into the command line to tweak /etc/ssh/sshd_config and then get annoyed when their changes are overwritten on the next update.
This ship has kind of sailed; there are plenty of routers out there running Linux that aren't updated either. Not to mention the Internet of Exploitable Lightbulbs coming over the horizon.
I think that what is happening here in the hosting sphere is the same thing that happened in the OS/user space, inasmuch as packaging has become the solution to solving the layers of abstraction. Todays .ipa archive is yesterdays .app bundle, was last centuries filesystem-containing standalone .exe, is todays 'one dock fits all' deployable-application solution.
Whereas in systems past the user was required to absorb a cognitive load of abstraction ("C:\DOS"), yet today we have far friendly flick and execute interfaces, the same is true of sysadmin abstractions becoming less and less significant and more and more point and click. Yesterdays 'tar xvf somesources.tar.gz && cd somesources && ./configure && make install' is todays 'docker run -i -t someapp', and so on ..
But yet, we still must face the quandry that the more these abstractions become compartmentalized, the more we can just pile new crap on top and end up with new abstractions requiring eventual compartmentalization, ad infi...
I applaud efforts to make self-hosting easier and more accessible for people but I think using the existing toolstacks for this is fundamentally flawed (security, deployment/maintenance, provenance, etc). FWIW, I'm working with others on new tools for building resilient, distributed systems, which you can read about at http://nymote.org. There's more technical info at http://openmirage.org.
OpenMirage and YunoHost looks to me like they serve two completely different audiences/purposes.
If an average user (non full-time server admin) wants to set up a server that has common apps like Wordpress, Roundcube and Transmission, YunoHost seems like the OS for the job.
How would a user like that go about this with OpenMirage? Is there a similar web interface for setting up mail, web and torrents (for example)? There's a lot of technical documentation, but how would they actually set up these services?
After reading the overview link, I'd wager that most users still don't really know why it's better than YunoHost, or even what OpenMirage actually is.
I think the point is that any system which is meant for people to self-host AND which is based on a Linux distro (Debian, Red Hat, etc. -- YunoHost is based on Debian) is broken by design.
Running "sudo apt-get update" and "sudo apt-get upgrade" in a cron job is not a security solution.
Operating systems have to be designed so that a security hole in a single application can't compromise the entire system. If not, I would argue they are unsuitable for the average user to "self host". Modern Linux distros don't meet this criteria.
OpenMirage is solving some of the same problems as YunoHost, just on a longer time scale and with real solutions rather than hacks piled on top of hacks (I'm not affiliated with the project). apt-get is a big hack and not suitable for distributed computing.
I'd say that YunoHost only makes sense for people who already know what the words nginx, postfix, LDAP, etc. mean -- I don't consider those people 'average users'. As others on this thread have alluded to, running a server using the existing tools and methods and not being a full-time sysadmin is a recipe for getting pwned. The tools we have right now are porous and difficult to maintain and debug when something goes wrong. Taking a clean-slate approach to the problem can yield new insights and solutions.
I don't really mean to suggest that Mirage/Nymote is ready for use by the public right now (I'm supportive of things that give users that option today). However, I do believe it will be better to build self-hosting options using the Mirage stack later, hence the link to the Nymote work.
Eben Moglen gave a great speech on what we're giving up by using centralized services. His call to action was to basically build what YunoHost now is. This video of the speech is an hour long but a good one: https://www.youtube.com/watch?v=QOEMv0S8AcA
There is a common sentiment that web is being centralized nowadays and this is a threat to its formerly open nature. It's not hard to complain about it as it's probably true, but the problem is, unfortunately, not in awareness. Lot of simple tools are missing, so: huge kudos to this effort! It's a hard thing to do.
The first URL returns an HTTP redirect to another page; so when you press back, you go back to the URL which immediately redirects you to another page.
I've wondered for a while why browsers don't catch this and let you back-button over the redirect. Perhaps there are some cases where it would be the wrong thing in an annoying way. It is annoying when I can't back button. For me, neither OSX Chrome nor OSX Firefox skips the URL with the redirect, both of them leave the back button not working well. (You can still hold down to get the back history menu, to skip over the redirect)
With more personal storage/NAS oriented features, a more desktop-like interface with file management features and this could become a nice open-source competitor to the likes of Synology. If this ever becomes a direction you'd like to take with this project, I'd love to contribute. My email address is aniki [at] pantswrestling [dot] com. My relevant skills/experience include: ZFS/btrfs/ext[2-4], Linux/*BSD hacking of all sorts, Python/Ruby/Node/etc.
Is this: https://yunohost.org/images/home_panel.jpg part of the actual UI? If so, I would suggest adding a line of info on what each of these apps does. Most users will probably know what Wordpress and Owncloud do; beyond that, most of the names are not exactly self-explanatory.
Round cube looks just like Zimbra and is clearly an e-mail client ... I agree with the rest of your comment completely. There is a description ofmeach on the "apps" page but when I tried to get to Roundcube's documentation I found that the page hadn't been written yet.
This looks cool - I just tried an install on a Ubuntu server - but it seems Debian really is needed, I guess that's why they said that :) - So going to spin up a Debian vps and try again.
1. The demo user has changed its password as it seems atm.
2. I installed it and it's really nice, but why can't i add other dynamic dns services? Why do I even have to have a domain for that and can't just use my digital ocean ip?
It lists services (i.e. postfix) but I can not see any way to configure them. Services like postfix, slapd don't just work, they need to be configured first.
Most but not all, and that won't change without consumer pressure in that direction. Projects like this, if they become popular, can help create that pressure.
The commoditisation of VPS (and cloud) servers brings exactly the same problem. Updates aren't automatic by default and so many VPS holders are devs sitting in Windows without a clue about anything past the `sudo apt-get install lamp-server^` they read on a forum. Months pass without updates and before you know it, there's a remote update a script can catch.
Webapp updating is another thing altogether. Relatively few are well packaged and even fewer have nice automatic update migrations. So they go stale and get exploited.
The [immediate] future of internet security looks pretty dismal.