The applications from libresh

add mailserver

My mailserver is coming along nicely - incoming email is now working, although there still is some problem with relaying outgoing email. I have to move it from gh:michielbdejong/mail to here.

Not very urgent maybe, but right now, to update DNS I have to log in to namecheap and to gandi. Running the authoritative DNS server on our own servers (one each, for instance?) would allow to automate things more in the long run. It would also be nice to make sure we implement things like ipv6, dnssec, and dane.

https://registry.hub.docker.com/search?q=bind

data formats should be tagged in image names

discard the current format without tagging it
start a branch for the proper data format, with /data/server-wide/IMG/ and /data/per-user/DOMAIN/IMG/.
from there on, data format versioning is 100% per IMG, meaning we don't really need to tag the server-wide portion (being just this super minimal directory path scheme).
if we ever need to make a breaking change in the data format of an image, then we rename the image, and possibly create a migration script. This means some users may be running 'resite' and some may be running 'resite2', on the same server, without any problem.

Move etherpad from IndiePaaS

bouncer certs should live on `/data/domain.com/bouncer/`, not `/data/default/bouncer/cert`

Move discourse, libreboard and etherpad to IndieHosters repo

Yep!

What do you think of moving these 3 apps to IndieHosters repo?
https://github.com/IndiePaaS

I prefer to have each app on a separate repo, then it is really easy to keep track of everything. It's really modular this way.
We could have then one repo, like this one, that have them all as git submodules.

If you like these 3 images and are ready to merge them into IndieHosters app, and ready to offer them to your clients as well, then, I'll start to rewrite the other apps to fit this "standard" nad move them little by little to this repo.

For me this is the best plan.

What do you think?

there should be an authoritative contact email address in `/data/domain.com/contact.txt`

Ouh, I'm getting excited :)

So the idea would be to have a manifest file for each of app we support.

I will write a BDD scenario:
Given a user (john) wants to access his wordpress the first time
And the user has already an account with indiehosters
When he goes to his app store page
And he clicks on wordpress
Then he is redirected to john.indiegue.st/wordpress
And our user sees a waiting page
Then our backend catches this http request
And our backend understands that there is no wordpress for this user
And our backend read the manifest file for wordpress
And our backend satisfies MySQl dependencie
(Given a user (john) wants to access his mysql the first time...)
And our backend satisfies all dependencies
And our backend send the http request to the service ambassador
And the service ambassador responds

The idea is that I don't want poor failover made by hand. Technology is mature for kickass failover. I want to have a rocking service. When one of the VM is down, I don't want the service down for the user :) So yes, one MySQL per user, but a replicated master-master one! And every services consuming MySQL are able to do it so, even if one MySQL instance is down :)

I'm still hoping that we don't have to write this manifest file, and could handle it at the Fleet or Docker level.

And about some services that are shared among users (mail, jabber..), I strongly believe we should use the same scemas as for users. We should dog food it ;) It's not a special case, it's just that the user is Michiel instead of John ;)

And I don't think we will run backup of services of each others (cross hosters). I will personaly have 3 VMs, and they'll backup each other. It's either that, or we share a common cluster (3 VMs also, but we can grow them to more).

converge our servers

@pierreozoux we're now both running our personal website on Docker, but we're each using a different setup to do so. Let's talk about how we can converge our setups, so that they become compatible with each other and we can develop it twice as fast! :)

Add piwik

add owncloud

https://github.com/michielbdejong/owncloud

init script should generate files only if missing

add idno

https://github.com/michielbdejong/idno

Add gitlab

https://registry.hub.docker.com/search?q=gitlab&searchfield=

https://github.com/search?utf8=%E2%9C%93&q=docker+gitlab&type=Repositories&ref=searchresults

initscript should take hostname `/data/default/mail/hostname.txt`

per-user volumes should be per hostname

so /data/michielbdejong.com/ instead of /data/michiel/

server move sometimes wipes out dump.sql in lamp-based images

moved from michielbdejong/snickers-applications#4

add ghost

https://registry.hub.docker.com/search?q=ghost

https://github.com/search?utf8=%E2%9C%93&q=docker+ghost&type=Repositories&ref=searchresults

discussion about which meta-software to offer

I think it's quite clear we want to offer certain base functionality:

identity: a domain name you control, with a (static) website served over https
decentralized communication: email, jabber, pubsubhubbub
blogging: tools so that you can more easily publish content on the web
file hosting: tools so that you can keep your photos and files on your server

And then there are miscellaneous apps that have some specific functionality, which are each sort of isolated and light-weight to add, like maybe:

gitlab,
etherpad,
bugzilla,
addressbook,
calendar,
etcetera.

but at another level, there is a number of important meta-software projects out there that we may just want to offer hosting for, without them being necessarily a miscellaneous app. Each of them covers basically file sharing + a lot of miscellaneous apps, and each user would need only one of those, because they replace each other. i think at the moment the most important ones in terms of momentum are (my knowledge may be incomplete here?):

owncloud
cozycloud
sandstorm
yunohost
arkos
turnkeylinux

i'm sure there will be others over the years. would it make sense to just try to offer hosting for each of these? i guess each have their pros and cons, and it's good if people can try them out, compare them, and use the best one for daily use on their domain name, hosted by their indiehoster.

Can we remove yunohost?

email password should be in `/data/michielbdejong.com/mail/password/anything`

Add redmatrix

Add cozy

Moved from michielbdejong/snickers-applications#5

Add webmail

Add known

add https plugin to wordpress image

To install the wordpress wp cli, the setup procedure of the WordPress Dockerfile should run the following as root:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp
chmod +x /usr/local/bin/wp
wp --allow-root --info
DB_HOST=172.17.0.5 DB_PORT=3306 DB_NAME=wordpress DB_USER=admin DB_PASS=foo wp --allow-root plugin install wordpress-https
DB_HOST=172.17.0.5 DB_PORT=3306 DB_NAME=wordpress DB_USER=admin DB_PASS=foo wp --allow-root plugin activate wordpress-https

Work-around, on a server that is not live, while using the current wordpress image after you run systemctl start [email protected] on your server, do the following:

systemctl stop haproxy-confd
edit /data/runtime/haproxy/haproxy.cfg, changing the line:

redirect scheme https code 301

to:

use_backend domain.com

If you want to add a wordpress domain to a live server, you will have to do something smarter. :)

systemctl restart haproxy
cd /data/domains/domain.com/wordpress/wp-content/
mkdir plugins
set the owner and permissions to be the same as for ./uploads, so in my case this was:
- chown 33:33 plugins
- chmod 770 plugins
visit http://domain.com/wp-login.php?a with your browser (the '?a' will clear the 301 out of the browser cache)
run the setup wizard if you hadn't already
log in and go to plugins -> add new -> https
install "WordPress HTTPS (SSL)" by Mike Ems
make sure to also activate it! Just installing it does nothing.
systemctl start haproxy-confd
cat /data/runtime/haproxy/haproxy.cfg, and make sure the 301 redirect is back in place.

add cozy

https://github.com/cozy/cozy-setup

mailserver's changed config files should be symlinks to `/data/default/mail/etc/postfix/*` etc.

Automate Known user setup

Moved from michielbdejong/snickers-applications#7

add wordpress

@pierreozoux - which dockerfile are you running for wordpress on your server? can you add it to this repo?

mailserver's `/var/mysql/data` should be a symlink to `/data/default/mail/var/mysql/data`

move run.sh to systemd

for integration in CoreOS and also on other operating systems, a good to make sure containers are restarted when they die

Rename the repo

I think a better name would be michiel-app-store or michiel-implementation. I'll have my own also, and then from October, we'll work on merging both. (it will be easier to do this AFK)

Don't you think it's better to put mail in server-wide?

allow running on >1 host

right now, the server-wide services assume that the user's data volume is on the same server. They also assume that all per-user containers are running on the same server. It would be nice to allow for bigger server farms, where one server acts as a load balancer, one as a file server, one as an application server, etcetera.

Store inmutable php files outside /data in lamp-based images

moved from michielbdejong/snickers-applications#14

Use IndiePaas images as a base

We can leave the IndiePaas images where they are https://registry.hub.docker.com/search?q=indiepaas and then add in a mysql server and a /snapshot.sh script where desired/necessary. This is maybe easier than the git submodule approach we tried last week.

@pierreozoux do you agree with this approach?

consider adding LDAP for user management

i just learned a bit about how ynh does this: http://community.remotestorage.io/t/sandstorm-io-personal-cloud-platform/212/5

@pierreozoux you brought this up already, that it's a shitty experience to not have SSO / one single password reset option. maybe we could at least use LDAP as much as possible? we could actually reuse a lot of the packaging work from ynh, there (maybe just Dockerize each ynh app? or even run a ynh server inside Docker or even just without Docker?)

init script should be server-wide `server-init.sh` + `domain-init.sh`

so not specific to the mailserver

Add owncloud

static-html server-wide runner

This application has a simple manifest file (author: Tim Berners-Lee ;) ) and tared data folder.

I think that our implementation, should be system-wide. For this particular case, I imagine an nginx conf for every /data/user/static-file.
In this folder (like every FOSIA package) there might be a CNAME file, and a corresponding SSL certificate. The nginx conf must take the appropriate decisions regarding these files. (It means either using it, or in case not present, using the default name scheme: user-name.indiehosters.net/service with our certificate)
The folder /data/server-wide/static-html/ link to every per-user folder.
There is also a /data/server-wide/static-html/site-available link to /data/server-wide/static-html/site-available-{timestamp}/.

Then, there is a process watching /data/*/static-html/CNAME,*.cert directory for changes. In case of change, it must:

re-render nginx.conf template of each relevant site. /data/server-wide/static-html/site-available-{timestamp}/
check nginx conf files
update link /data/server-wide/static-html/site-available
start a new nginx with these confs
re-render HAproxy/bouncer configuration to point to the new nginx docker (and kill the old one)
re-render relevant DNS configuration template.
clean
(if any of the operations fail, it stops the pipeline)

For now, all the automatic part, I'll do by hand. But what do you think in a general manner about this?

(this implementation is compatible with multi servers if you reconfigure the main HAproxy)

Comments?

IndieWeb plugin, by pfefferle (including all the plugins it requires and recommends!)
IndieAuth plugin, by pfefferle
SemPress theme
A 'Follow me on social media' text widget with content for instance:

<div>
<a href="https://twitter.com/username" rel="me">@username on Twitter</a>
<a href="https://github.com/username" rel="me">@username on GitHub</a>
<div>

I am testing this right now, to see if it is enough to enable login with IndieAuth.

simplify Known Dockerfile by using their env vars

looking at https://github.com/idno/idno/blob/master/docs/install/instructions.rst#use-environment-variables I think what they mean is config.ini is needed for the things that don't change, but we can get rid of the lines that paste env vars into that file

libresh / applications Goto Github PK

applications's People

Contributors

Stargazers

Watchers

Forkers

applications's Issues

Recommend Projects

Recommend Topics

Recommend Org