migrations/update-oo.sh

+#!/bin/bash -eux
+
+# Verify they are all in sync with git, if not, print the domain name.
+for oo  in `ls -d ./oo-*`;do
+  cd $oo
+  if ! git diff --exit-code --quiet; then
+    echo $oo
+  fi
+  cd ..
+done
+
+# Update all oo
+for oo  in `ls -d ./oo-*`;do
+  cd $oo
+  libre update
+  cd ..
+done

scripts/ca.pem

------BEGIN CERTIFICATE-----
-MIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
-MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
-Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
-dGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9
-MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
-U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh
-cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUA
-A4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZk
-pMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXWeUyAN3rf
-OQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/C
-Ji/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYT
-Kqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNi
-HzvEvqBTViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMM
-Av+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w
-+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+
-Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3
-Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B
-26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwID
-AQABo4ICUjCCAk4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYE
-FE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
-ZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3Js
-LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFM
-BgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
-Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFy
-dGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3Rh
-cnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlh
-YmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg
-dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFp
-bGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJ
-YIZIAYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNT
-TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ
-9GYMNPXQhV59CuzaEE44HF7fpiUFS5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8
-jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk4gNXcGmXCPleWKYK34wGmkUW
-FjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENNZEXO3SipXPJz
-ewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1
-ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5L
-EUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYu
-L6lwhceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+Pwq
-yvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuC
-O3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6V
-um0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEkkySh
-NOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14=
------END CERTIFICATE-----

scripts/setup.sh

-#!/bin/bash -eux
-
-if [ $# -ge 1 ]; then
-  HOSTNAME=$1
-else
-  echo "Usage: sh /data/indiehosters/scripts/setup.sh k1.you.indiehosters.net"
-  exit 1
-fi
-
-# Install cloud-config
-if [ -f /tmp/vagrantfile-user-data ]; then
-  mv /tmp/vagrantfile-user-data /var/lib/coreos-vagrant/vagrantfile-user-data
-fi
-
-# Pull relevant docker images
-docker pull pierreozoux/haproxy
-docker pull pierreozoux/confd
-docker pull pierreozoux/email-forwarder
-docker pull pierreozoux/nginx
-docker pull pierreozoux/mysql
-docker pull pierreozoux/wordpress
-docker pull pierreozoux/known
-docker pull ibuildthecloud/systemd-docker
-
-# Install unit-files
-sudo cp /data/indiehosters/unit-files/* /etc/systemd/system && systemctl daemon-reload
-
-# Create Directory structure
-mkdir -p /data/domains
-mkdir -p /data/runtime/haproxy/approved-certs
-mkdir -p /data/runtime/postfix
-
-# Configure and start HAproxy
-cp /data/indiehosters/scripts/unsecure-certs/indiehosters.dev.pem /data/runtime/haproxy/approved-certs/default.pem
-systemctl enable confd.service
-systemctl start  confd.service
-systemctl enable haproxy.path
-systemctl start  haproxy.path
-
-# Configure and start postfix
-touch /data/runtime/postfix/hostname
-touch /data/runtime/postfix/destinations
-touch /data/runtime/postfix/forwards
-
-systemctl enable email-forwarder.service
-systemctl start  email-forwarder.service
-
-# Adds backup ssh key to the list of known hosts
-ssh -o StrictHostKeyChecking=no `cat /data/BACKUP_DESTINATION` "exit"

scripts/sub.class2.server.ca.pem

------BEGIN CERTIFICATE-----
-MIIGNDCCBBygAwIBAgIBGzANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEW
-MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
-Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
-dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjA1NzA5WhcNMTcxMDI0MjA1NzA5WjCB
-jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
-IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
-YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVyIENBMIIB
-IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4k85L6GMmoWtCA4IPlfyiAEh
-G5SpbOK426oZGEY6UqH1D/RujOqWjJaHeRNAUS8i8gyLhw9l33F0NENVsTUJm9m8
-H/rrQtCXQHK3Q5Y9upadXVACHJuRjZzArNe7LxfXyz6CnXPrB0KSss1ks3RVG7RL
-hiEs93iHMuAW5Nq9TJXqpAp+tgoNLorPVavD5d1Bik7mb2VsskDPF125w2oLJxGE
-d2H2wnztwI14FBiZgZl1Y7foU9O6YekO+qIw80aiuckfbIBaQKwn7UhHM7BUxkYa
-8zVhwQIpkFR+ZE3EMFICgtffziFuGJHXuKuMJxe18KMBL47SLoc6PbQpZ4rEAwID
-AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYD
-VR0OBBYEFBHbI0X9VMxqcW+EigPXvvcBLyaGMB8GA1UdIwQYMBaAFE4L7xqkQFul
-F2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDov
-L29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0
-YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3
-dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0
-c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAu
-BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0
-BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl
-LnBkZjANBgkqhkiG9w0BAQsFAAOCAgEAbQjxXHkqUPtUY+u8NEFcuKMDITfjvGkl
-LgrTuBW63grW+2AuDAZRo/066eNHs6QV4i5e4ujwPSR2dgggY7mOIIBmiDm2QRjF
-5CROq6zDlIdqlsFZICkuONDNFpFjaPtZRTmuK1n6gywQgCNSIrbzjPcwR/jL/wow
-bfwC9yGme1EeZRqvWy/HzFWacs7UMmWlRk6DTmpfPOPMJo5AxyTZCiCYQQeksV7x
-UAeY0kWa+y/FV+eerOPUl6yy4jRHTk7tCySxrciZwYbd6YNLmeIQoUAdRC3CH3nT
-B2/JYxltcgyGHMiPU3TtafZgLs8fvncv+wIF1YAF/OGqg8qmzoJ3ghM4upGdTMIu
-8vADdmuLC/+dnbzknxX6QEGlWA8zojLUxVhGNfIFoizu/V/DyvSvYuxzzIkPECK5
-gDoMoBTTMI/wnxXwulNPtfgF7/5AtDhA4GNAfB2SddxiNQAF7XkUHtMZ9ff3W6Xk
-FldOG+NlLFqsDBG/KLckyFK36gq+FqNFCbmtmtXBGB5L1fDIeYzcMKG6hFQxhHS0
-oqpdHhp2nWBfLlOnTNqIZNJzOH37OJE6Olk45LNFJtSrqIAZyCCfM6bQgoQvZuIa
-xs9SIp+63ZMk9TxEaQj/KteaOyfaPXI9778U7JElMTz3Bls62mslV2I1C/A73Zyq
-JZWQZ8NU4ds=
------END CERTIFICATE-----

scripts/unsecure-certs/indiehosters.dev.pem

------BEGIN CERTIFICATE-----
-MIIFljCCA34CCQDXgLjASWHpmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMC
-UFQxETAPBgNVBAgTCFBvcnR1Z2FsMQ8wDQYDVQQHEwZMaXNib24xFTATBgNVBAoT
-DEluZGllSG9zdGVyczEZMBcGA1UEAxMQaW5kaWVob3N0ZXJzLmRldjEnMCUGCSqG
-SIb3DQEJARYYY29udGFjdEBpbmRpZWhvc3RlcnMubmV0MB4XDTE0MTAxMDE0MzY1
-NVoXDTE1MTAxMDE0MzY1NVowgYwxCzAJBgNVBAYTAlBUMREwDwYDVQQIEwhQb3J0
-dWdhbDEPMA0GA1UEBxMGTGlzYm9uMRUwEwYDVQQKEwxJbmRpZUhvc3RlcnMxGTAX
-BgNVBAMTEGluZGllaG9zdGVycy5kZXYxJzAlBgkqhkiG9w0BCQEWGGNvbnRhY3RA
-aW5kaWVob3N0ZXJzLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
-AKBOylYEoL1P3q7skTJsRA8yQj6fVHWHS3kPg6tcVavZawc6tRxIiDc41/EWjL7i
-Owb6io2UbKaD/g8695CFER9FvcW1iukrC/tUV5/AVd0SDcvS3RnGUndKh82HCNrM
-rUDU/XH8smEpfjuXrq0YPuiGbY1zSLQKirjYTiasJODfGkxSbobNfjdL7aEo+3HX
-BQq5mGIj9A4PYmeyFGkHCN8tRvf4lY1KfPJoWtDL4kmO4SFNZ4FAehH9AJ6vTN8y
-MFcHtFzpp2636TYTBQsLu48nrKs6MqOOyU0R/Ufw9QjiWDLo3Co6pcCTmVf16skO
-odg9BNdEhMXefpiEE1NOL6ZOkSUG5WSY0Q5Il649QcJOYzw2A0Nk3IOxoIexXat4
-siCgSlNfgyRmBn5HNcZo5aEDf9+3gEqFzEFSyH3ClIApC7RePbpPvsCAgpagBOXC
-PgO2w2VW9HfNHkwpF3Yqn7cqw0FQKwKREufVdnSvs9fgFlMZnqA3sMym8o99Fcvq
-WBaTuh54ePfNGmawPt1N8vUZUYXXOasWKmnjfan3S1rsNAf5M2ntLqEJRDwihdSm
-ZSO+B51hDO5jzHoqxHwA71CwUAp4hRO83xR6ziB1KR2834I/7LBzbpZ0EWm9adez
-8V+dwgBhTt0LYEUGLJN22XRi9d4RPhnRJpSLPV/h0Fa/AgMBAAEwDQYJKoZIhvcN
-AQEFBQADggIBAFzYeGiomhKZW//aUM4V4RLMVIf0B4uixSMxZGQIUWVtYckmyG2N
-t8qNBHAQ3gl811NqnqestIQ4DpGkNQRCv/iDa5OwdLJHTOQUxajUE/1xmidHtpzR
-ReBZvW48k0dLEM2gmIrt7qQwqqecjlWjvSQlvJxYWrn6TBAkFL6Quu8gfoPK9/cE
-HG/aRQ0PCywGV20LSZ+J03LN7MlACClgVTB7dJuWIN0dNi7TsqpIupk11ZQ3ybBY
-WPQmLnIiCAijL69kBmBynLvJT5XDy2C4ChyzZ5Y73CXhgJwCqOZJwbO7Doig9PZQ
-yVLtui18W3uVQ7ZlIxCAQUeFzSkZf3/XNlr2FkP+efw4LLGH8kiKMsyKuoLuthO1
-1YrXvI0sjuDOxQwrlNQ2CLVANLBpUMH2U1aiYbA6iICSHr8ORAc84StgG9mFLeyN
-w32/04MGPvZfset8gRCOuvA2sLTjylqh0IpaPWlnT77neqOFtETtzJ+3UuOcdfnN
-t2bxqimHT8WhBB823WajWlLdXcc902e9LLhe9M1/bwOqFIIlKDqtCndjyXpe/qhA
-s0YB8TqJLxJQqvdnmYiBFfGrDTgNBpjt6AKJHRGd4xgsYsmQ3zLJ0Z8mNNQhlLf/
-osGXa2s/ZX7ernfvSDQIOB70gohCLFtBok0unyBJhtHxXmZ7UmpuIanx
------END CERTIFICATE-----
------BEGIN RSA PRIVATE KEY-----
-MIIJKAIBAAKCAgEAoE7KVgSgvU/eruyRMmxEDzJCPp9UdYdLeQ+Dq1xVq9lrBzq1
-HEiINzjX8RaMvuI7BvqKjZRspoP+Dzr3kIURH0W9xbWK6SsL+1RXn8BV3RINy9Ld
-GcZSd0qHzYcI2sytQNT9cfyyYSl+O5eurRg+6IZtjXNItAqKuNhOJqwk4N8aTFJu
-hs1+N0vtoSj7cdcFCrmYYiP0Dg9iZ7IUaQcI3y1G9/iVjUp88mha0MviSY7hIU1n
-gUB6Ef0Anq9M3zIwVwe0XOmnbrfpNhMFCwu7jyesqzoyo47JTRH9R/D1COJYMujc
-KjqlwJOZV/XqyQ6h2D0E10SExd5+mIQTU04vpk6RJQblZJjRDkiXrj1Bwk5jPDYD
-Q2Tcg7Ggh7Fdq3iyIKBKU1+DJGYGfkc1xmjloQN/37eASoXMQVLIfcKUgCkLtF49
-uk++wICClqAE5cI+A7bDZVb0d80eTCkXdiqftyrDQVArApES59V2dK+z1+AWUxme
-oDewzKbyj30Vy+pYFpO6Hnh4980aZrA+3U3y9RlRhdc5qxYqaeN9qfdLWuw0B/kz
-ae0uoQlEPCKF1KZlI74HnWEM7mPMeirEfADvULBQCniFE7zfFHrOIHUpHbzfgj/s
-sHNulnQRab1p17PxX53CAGFO3QtgRQYsk3bZdGL13hE+GdEmlIs9X+HQVr8CAwEA
-AQKCAgEAgDpF8sRE5ukqUHV+Nv0O+7DR+FFuN4x/PFjCk6GKDaodyGyXTgZenv1j
-Db9h2ZYQbSafCVy+A/v0jq42NG2cIo2gnLL4aEY8kU8HwAsTI4A7dNw4a1ONx0ng
-ku/+jzXFJ+S2ziS5cqrEBFryKBcKyugsXUbn0svT5sNuz9RGs3ECEialrkJVQVoE
-vDKR3p+Fsux+DZKAt3Zq2lNBrDkqSYpoCBXZWmlIxIXgjr9nRDt7rS3DK0ot2pGr
-m0LRlH8K17Kb/O4RNaj6bHyOPiWmY33yygwFUXr3XiSTmqYM+oxCzIYjBcxfpUjr
-EcbthOGlZ9h3NNHj+npcfRa4dpxF09c8gW2AVG+nXVhciZpcnLDZ5z/Nd/510axU
-0m0PlCPfh+3L5tiia9k7zlRxjyzER/GofNiJ6v8oo8YZFvhVdbBBQoGs8aadSLH9
-5Kf3fPwm8ZhmmOTVWbFJZul/3o0Ho3yFxMVMq86Qu8Pm+h6Q1Pn7yZsXMg/ECXP/
-/ErBaWA+zuBZkgCSbdZk58cxkN45PGWGkoHHACVUvCbG8IuYQ989JeCy5w01FgFV
-IXm4squNtWgyhLZgvkhl2Hnc4pR+iYJRgh+ouyv7nELQde7hpM6YJLLUpMfjo7r5
-lJyWasZtb9E4iEl4/JrdQYMJCDEyBfDN6sTKr1Ai2txjzQA4uOECggEBAM9LDpJ+
-RR+b1rdYgtS6VL5OR1bWUHSi1W9L8Xz20wSQGbRxfEJfWmSslOU0COXvA01eOxQ9
-OvHcWxISiHdiM3QxpYNtbsgATCQbsSgegMHpbaEgJPadEkUWxdWejbtpA1ypKmGg
-iFB5H5IIcz65wWNFC3g29wrXyBsRevi+K/PTbwOzOlad7AAcbuuHiv73wxi5xo1P
-i6IZfjgQMKzD9AJbACAAqyvg70XT+3vlIo5ABKOw1kLuejbNBaXd1af7OfVXReL7
-BGGJmG6IzI0qP9q7fX3Iq4Gx34Sf0TSomSyW4kxtsDMPXVURMU4ssxeshh0zYFsZ
-GQgsr36mOW5cvbkCggEBAMX5gJTrAW47GgObnQWtYIHRvYO0g7Ge1fN12VzHLiap
-3a3RfhEDTVKkiugO1GxRC1NY0tcDUwrUzS/00ovDZ/8dVqMHITFj6zfA8aX6vnzA
-TnoUWINawPxFBB6FrEuXyGIVbykinuvFyk+z/DzgKzL8X5MaLymYSV+eT+9jjLHO
-pJ37S86evkljq24Ow6KB1rKb8mMsk8GDZB4JalDdGWzlG1qJkHMg7ULkEHx2lDTW
-mcuHwRtMimFPCBGqH0i+p3O1IUkodJPNYbldrEfAkzRdD4lH9B+DNYBgxP4FWhY2
-d9DTHAGCa9ZV0HjnGgPOILRmV69+9yQhNhu5010qNDcCggEABq1VP9S/Z0A+z1MT
-i8SgvCyLUbm/h7JDC723fp34uBnoKg7JwN2PbNS+Sw+9BaMISTKy1nkOcAH4EQH1
-0Vqha6m5uh0JR3ny+erGbxNkdFqPhHQjnKn8j6snHjVoPVQpno94ZQKlwWnVYX/S
-LoAPQaJUtz+V/4xpzq1md6Kwib8SwVzBkU6u7mX8EKwiBwp2B1LcmWqphcQqc6XZ
-24bIUlcaDu3Wlag+LNKiNCByV4CqZZdpn2hNGXzLJMebfTizajqwbppFTtr+xPi1
-Fgr5WZNWfHm9RIU1PPFk7LxNisklau7RkSN6jyXpn6oC7s1I2KHyBZ0uWDwQPxUd
-nndwSQKCAQA/gmrdWwZ6djtCLQmSaKws+TvypFYbBPldwNCaEsubW6Lhv/LRQl3r
-xR1KlHdQyC757eS1VTuundW1LLTeYTFbhe3lHsRnM8ahfCQJOwcgvhBu2VgLy3Fd
-fEZ2BCvhlC+UR4wBhjm1KR5dsz+Xx9IT6SI/7oZysYfYRNEf2q+n2sK0a4lGH2ar
-5G16QQJBf6WAZsa7SfGcgqn7eMnCZytg456CzN6qEEYMz1z6kI+6450yzboFJ+i8
-jr3n7Mtcas0NMW4cKf477AcNkB9UZVLT2YbCY3LNKSpgpKqNUuozdgW51/+D/HLb
-r2vRXVHbJqUXOj2m7vQZgw34lwRXPtLBAoIBAChJgVltpcWKUWqltYXCQsdPPbb4
-DQMb4bb2vV2iON2kl+UlcCdhr0f5yWoAyKjs49lcHBN2Ny4zVR0vIu/IDeX47Fx7
-n0OfcFgcnqiqiFhXkWGcfU2JHq/q5tmk5M04aCgkFM8IyEsG6ZLoi849Km9r8quu
-VfclpJ6SsMGnWo/A2eIVP9GsfqRys9ZWKJ9inZRP5Lmx6pCZa12Mn6ey0h/kxOqh
-ruJQDdV0O4PsvZhTQFhahSVyNmSKnLguq3zsyBwKRsNI9TVXMv/hs0nnwfFgtBK1
-K61c7AL4+9dtAWEnuwqy/1srZEeBr/jgTqyFyr+GQFYUMuE/uXNKCDWlIRI=
------END RSA PRIVATE KEY-----

tests/clean.sh

-#!/bin/bash -eux
-source /etc/environment
-image=$1
-
-systemctl stop web@$image.test
-
-systemctl list-units | grep -c "$image\.test" | grep 0
-
-rm -rf /data/runtime/domains/$image.test
-rm -rf /data/domains/$image.test
-
-ssh $BACKUP_DESTINATION "rm -rf $image.test"
-

tests/finish.sh

-#!/bin/bash -eux
-
-systemctl list-units | grep -c failed | grep 0
-
-applications=( static wordpress known )
-
-for application in "${applications[@]}"
-do
-  /data/indiehosters/tests/clean.sh $application
-done

tests/force-clean.sh

-#!/bin/bash -eux
-source /etc/environment
-
-image=$1
-systemctl stop web@$image.test
-if [ "$image" == "static" ]; then
-  systemctl disable $image@$image.test
-else
-  systemctl disable lamp@$image.test
-fi
-
-systemctl stop *@$image.test.timer
-systemctl stop *@$image.test
-systemctl reset-failed
-rm -rf /data/runtime/domains/$image.test
-rm -rf /data/domains/$image.test
-ssh $BACKUP_DESTINATION "rm -rf $image.test"
-systemctl list-units | grep "$image\.test"
-

tests/start.sh

-#!/bin/bash -eux
-
-applications=( static wordpress known )
-
-for application in "${applications[@]}"
-do
-  /data/indiehosters/tests/test.sh $application
-done

tests/test.sh

-#!/bin/bash -eux
-
-cp /data/indiehosters/unit-files/* /etc/systemd/system && sudo systemctl daemon-reload
-
-image=$1
-
-# prepare data
-folder=/data/domains/$image.test
-mkdir -p ${folder}/TLS
-cp /data/indiehosters/scripts/unsecure-certs/example.dev.pem ${folder}/TLS/$image.test.pem
-
-echo "EMAIL=test@test.org" > ${folder}/.env
-
-case "$image" in
-"static" )
-  echo "APPLICATION=nginx" >> ${folder}/.env
-  echo 'DOCKER_ARGUMENTS="-v /data/domains/static.test/static/www-content:/app"' >> ${folder}/.env
-  ;;
-"wordpress" )
-  echo "APPLICATION=$image" >> ${folder}/.env
-  echo 'DOCKER_ARGUMENTS="--link mysql-wordpress.test:db \
-  -v /data/domains/wordpress.test/wordpress/data:/app/wp-content \
-  -v /data/domains/wordpress.test/wordpress/.htaccess:/app/.htaccess \
-  --env-file /data/domains/wordpress.test/wordpress/.env"' >> ${folder}/.env
-  ;;
-"known" )
-  echo "APPLICATION=$image" >> ${folder}/.env
-  echo 'DOCKER_ARGUMENTS="--link mysql-known.test:db \
-  -v /data/domains/known.test/known/data:/app/Uploads \
-  -v /data/domains/known.test/known/.htaccess:/app/.htaccess \
-  --env-file /data/domains/known.test/known/.env"' >> ${folder}/.env
-  ;;
-esac
-
-if [ "$image" == "static" ]; then
-  systemctl start $image@$image.test
-  systemctl enable $image@$image.test
-  sleep 20
-else
-  systemctl start lamp@$image.test
-  systemctl enable lamp@$image.test
-  sleep 60
-fi
-
-systemctl list-units | grep "$image\.test" | grep -c failed | grep 0
-ip=`docker inspect --format {{.NetworkSettings.IPAddress}} $image.test`
-curl -L $ip
-

to_migrate/doc/adding-an-application.md

-# Adding an application
-
-There are two types of application: server-wide, and per-user. Right now, server-wide applications are the postfix-forwarder,
-and the haproxy. Available per-user applications right now are wordpress, static, and static-git.
-
-# Adding a server-wide application
-
-To add a server-wide application, first make sure it can run on one IPv4 address for multiple domains. If it can, then:
-
-* Package it into one Dockerfile per process, and add these to the [dockerfiles](https://github.com/indiehosters/dockerfiles) repo.
-* Add `docker pull`, `systemctl enable` and `systemctl start` commands to `scripts/setup.sh`.
-* Make it take user data from /data/PROCESS/, and data that is needed at runtime but should not be backed up can
-go into /data/runtime/PROCESS
-* Create a systemd unit file for each process in the `unit-files/` folder
-* Either add functionality to `scripts/add-site.sh` to configure domains on this new service, or describe the manual steps for this
-in [deploying-a-server.md](deploying-a-server.md).
-* Double-check all documentation to see if it is all still correct.
-
-# Adding a per-user application
-
-To add a per-user application, first make sure it can run behind an SNI offloader. For instance, for WordPress to work behind an SNI
-offloader, we had to activate the "https" plugin. If it can, then:
-
-* First study how for instance the WordPress application works in this repo, the easiest approach is to copy it as a starting point.
-* Package it into one Dockerfile per process, and add these to the [dockerfiles](https://github.com/indiehosters/dockerfiles) repo.
-* Add `docker pull` commands to `scripts/setup.sh`.
-* Make it take user data from /data/domains/DOMAIN.COM/PROCESS/, and data that is needed at runtime but should not be backed up can
-go into /data/runtime/domains/DOMAIN.COM/PROCESS.
-* Create a systemd unit file for each process in the `unit-files/` folder, ending in "@.service", so they get symlinked for each domain.
-* If there are cronjobs to be added, then this is done with "@.timer" files.
-* Link the processes together, using docker linking and systemd dependencies.
-* Add import logic, and if there is any pre-backup action necessary to make sure all relevant data is under /data/domain, then add this as
-a pre-step to the backup unit.
-* Either add functionality to `scripts/add-site.sh` to configure domains on this new service, or describe the manual steps for this
-in [deploying-a-server.md](deploying-a-server.md).
-* Double-check all documentation to see if it is all still correct.

to_migrate/doc/architecture-overview.md

-# Architecture based on systemd, docker, haproxy, and some bash scripts
-Our architecture revolves around a
-[set of systemd unit files](https://github.com/indiehosters/indiehosters/tree/master/unit-files). They come in various types:
-
-## Server-wide processes
-
-The haproxy.* and postfix.* unit files correspond to two server wide processes. They run Docker containers from images in the
-[server-wide/ folder of our dockerfiles repo](https://github.com/indiehosters/dockerfiles/tree/master/server-wide).
-The haproxy-confd service unit starts configuration service for haproxy. It monitors `etcdctl ls /services` to see if any new backends were created, and updates the haproxy configuration files. The files lives in `/data/runtime/haproxy/` on the host sytem. It is required by the haproxy.* unit. That means that when you run `systemctl start haproxy`, and then run `docker ps` or `systemctl list-units`, you will see that systemd not only started the haproxy container, but also the haproxy-confd container.
-
-There is currently no similar service for updating `/data/runtime/postfix/`, so you will have to update the configuration files in that folder manually, and then run `systemctl restart postfix`.
-
-Etcd is configured in the `cloud-config` file. The `scripts/setup.sh` takes care of enabling and starting the haproxy and postfix service, and the haproxy-confd to listen for changes in the backends configuration in [etcd](https://github.com/coreos/etcd). New backends are automatically added to the haproxy configuration as soon as their private docker IP address is written into etcd.
-
-## HAProxy backends: static, static-git, wordpress
-
-A per user process is a haproxy backend for a specific domain name. For now, we have three applications available: static, static-git and wordpress. But we are working on adding more. Please, if you want, you can create more :)
-
-You will notice there are also some other units in the `unit-files/` folder of this repository, like the gitpuller and mysql ones.
-
-Whenever you start a wordpress unit, it requires a mysql service.
-
-Whenever you start a static-git unit, it wants a static-git-puller unit.
-
-In all three cases, an -importer unit and a -discovery unit are required.
-This works through a
-[`Requires=` directive](https://github.com/indiehosters/indiehosters/blob/0.1.0/unit-files/nginx@.service#L6-L7) which systemd interprets, so that if you start one service, its dependencies are also started (you can see that in `systemctl list-units`).
-
-## Discovery
-
-The `-discovery` units check find out the local IP address of the backend, checks if it is up by doing a `curl`, and if so, writes the IP address into etcd. The `haproxy-confd` service notices this, and update the haproxy config.
-
-## Import
-
-The `-import` units check if data exists, and if it doesn't, tries to import from the `/data/import` folder, and create initial data state, for instance by doing a git clone, untarring the content of a vanilla wp-content for wordpress installation.
-
-Note that some initialization is also done by the Docker images themselves - for instance the wordpress image runs a [shell script](https://github.com/pierreozoux/tutum-docker-wordpress-nosql/blob/master/run-wordpress.sh) at container startup, that creates the initial mysql database if it didn't exist yet.
-
-We are working on merging everything inside the docker image.
-
-## Gitpuller
-
-The `-gitpuller` unit is scheduled to run every 10 minutes by the .timer file. When it runs, it does a git pull to update the website content at one of the haproxy backends from the git repository mentioned in the GITURL file.
-
-## Scripts
-
-There is one important script you can run at your server. You can also run the commands they contain manually, then you just use them as a cheatsheet of how to [set up a new server](https://github.com/indiehosters/indiehosters/tree/master/scripts/setup.sh).
-
-There are also deploy scripts which do the same from a jump box, so you can orchestrate multiple servers from one central vantage points. They are in the
-[deploy/](https://github.com/indiehosters/indiehosters/tree/master/deploy)
- folder of this repo, and they are the scripts referred to in the 'how to deploy a server' document. They basically run the scripts from the scripts/ folder over ssh.

to_migrate/doc/deploying-a-server.md

-# Deploying a server
-
-## Before you start
-Make sure you read [getting started](getting-started-as-a-hoster.md) first.
-
-### Prepare your servers
-
-#### with CoreOS
-
-* Get 2 CoreOS server, for instance from [RackSpace](rackspace.com), [Vultr](vultr.com), or [Hetzner](http://serverboerse.de/).
- * let's call them k1 and k2
- * they will be backup of each other
-* Modify the cloud-config according to your needs
- * make sure the backup user get the ssh public key of the root of the other server
-
-#### other linuxes
-* * If you prefer another operating system, you can also run our Docker images [using just Docker and bash](using-just-docker-and-bash.md).
-* If you didn't add your public ssh key during the order process (e.g. through your IaaS control panel or a cloud-config file),
-  scp your laptop's public ssh key (probably in `~/.ssh/id_rsa.pub`) to `.ssh/authorized_keys` for the remote user
-  you will be ssh-ing and scp-ing as (the default remote user of our deploy scripts is 'core').
-* Give the new server a name (in this example, we call the server 'k3')
-* Add k3 to your /etc/hosts with the right IP address
-* If you have used this name before, run `ssh-keygen -R k3`
-* Ssh into your server, and run `ssh-keygen -t rsa`  (use all the default settings, empty passphrase)
-* Set up a backups server at an independent location (at least a different data center, but preferably also a different IaaS provider, the bu25 plan of https://securedragon.net/ is a good option at 3 dollars per month).
-* Set up a git server by following http://www.git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server (no need to set up any repos like 'project.git' yet).  Let's call the backup server 'bu25' (add this to /etc/hosts on k3).
-* Add the ssh key from k3:.ssh/id_rsa.pub to the authorized_keys for the git user (not the root user) on bu25.
-* Check that you can `ssh git@bu25` from k3.
-* Exit from the double ssh back to your laptop, and from the root folder of this repository, run `sh ./deploy/deploy.sh k3 git@bu25 master root`
-* The rest should be automatic! (ignore the warning about backup.dev, and note that haproxy will not start as long as there are no websites on your server).
-
-### Adding an existing website
-* The IndieHosters architecture is migration-oriented, so it aims to make moving a domain from one server to another very easy.
-* If you already have a domain in backups, say example.com, then it's easy to add it to this new server.
-* Say domain example.com runs the 'static' image. Then ssh into k3, and run:
-
-````bash
-    systemctl enable static@example.com
-    systemctl start static@example.com
-````
-
-* This will automatically do the following things:
-  * Clone the backup repo from bu25
-  * Set up an hourly backup job for the user data (which will live in `/data/domains/example.com` on k3)
-  * Start an nginx container
-  * Note its IP address in etcd
-  * Rewrite the haproxy configuration
-  * (Re)start haproxy
-
-* If the domain runs wordpress (and similarly if it runs Known), then:
-  * the git clone from backup will fail because of [issue 46](https://github.com/indiehosters/indiehosters/issues/46), so make sure to follow the workaround steps from there.
-  * initial wordpress setup will be impossible with the redirect because of [Dockerfiles issue 39](https://github.com/indiehosters/dockerfiles/issues/39), so make sure to follow the workaround steps from there.
-  * Indiewebifying the WordPress instance is still a manual process, so make sure you know the user's preferred username (you can use this for the SiteName as well), and preferred language.
-  * Configure an arbitrarily long password, and save it in wordpress/login.txt in /data/domains/domain.com/wordpress/login.txt. The user will be logging in with IndieAuth, but it's good to make a not of which password you set.
-  * Activate the IndieWeb plugins/themes/widget as per [Dockerfiles issue 40](https://github.com/indiehosters/dockerfiles/issues/40).
-
-* Make sure to edit the files in /data/runtime/postfix/ to set up email forwarding. Also, ask another indiehoster to add the same forwarding and act as a fallback MX.
-
-### Adding a new website to your server
-* For each site you want to deploy on the server, e.g. example.com, do the following:
-  * Does example.com already exist as a domain name?
-    * If yes, then find out to what extent it's currently in use (and needs to be migrated with care). There are a few options:
-      * Transfer the domain into your DNR account
-      * Set up DNS hosting for it and ask the owner to set authoritative DNS to the DNS servers you control
-      * Ask the user to keep DNR and DNS control where it is currently, but to switch DNS when it's ready at the new server, and every time
-        you add or remove an IP address (not a good idea, unless the user insists that they prefer this option)
-      * In any case, you will probably need access to the hostmaster@example.com email address, for the StartSSL process *before*
-        the final DNS switch. You could also ask them to tell you the verification code that arrives there, but that has to be done
-        in real time, immediately when you click 'verify' in the StartSSL UI. If they forward the email the next day, then the token
-        will already have expired.
-    * If no, register it (at Namecheap or elsewhere).
-  * Decide which image to run as the user's main website software (in version 0.2.2, 'static', 'static-git', 'wordpress', and 'known' are supported)
-  * For the 'wordpress' image, all you need is the TLS certificate. Use the 'static-git' image if you already have some static
-    content that should go on there, and which you can put in a public git repository somewhere.
-  * Unless you already have a TLS certificate for example.com, get one
-    (from StartSSL if you own the domain in question, from namecheap or elsewhere if you do not), and concatenate the certificate
-    and its unencrypted private key into one file.
-  * Make sure the TLS certificate is valid (use `scripts/check-cert.sh` for this), and scp it to `/data/import/example.com/TLS/example.com.pem` on k3.
-  * Now ssh into k3, and if for instance 'wordpress' is the image you chose, run:
-
-    systemctl enable wordpress@example.com
-    systemctl start wordpress@example.com
-
-  * In case you're going for the 'static-git' repo, store the git url with the content in `/data/domains/example.com/static-git/GITURL`.
-  * In case you're going for the 'static' repo, store the html content under `/data/domains/example.com/static/www-content`.
-  * Test the site using your /etc/hosts. You should see the data from the git repo, or the static content, or a wordpress start page
-    on both http and https.
-  * If all looks well, switch DNS and monitoring.
-  * If not, check what happened by looking at what's in `/data/domains/example.com`, `data/runtime/domains/example.com`, and `/data/runtime/haproxy` on k3. Note that this part of our scripts is currently a bit complex, we will clean this up in a next version. There are six different scripts that try to initialize the contents of `/data/domains/example.com`:
-    * The git clone from the back up service (will try to initialize an empty git repository)
-    * The local data import process (will try to move the data from `/data/import/example.com` into place
-    * The wordpress image (which we used from the wordpress-stackable Dockerfile published by Tutum)
-    * The mysql image (which we used from the mysql Dockerfile published by Tutum)
-    * The wordpress importer (a one-time systemd task)
-    * The mysql importer (a one-time systemd task)
-  * It might help to remove /data/domains/example.com, /data/runtime/domains/example.com, and /etc/systemd/system/*/*example.com*, and remove the git@bu25:example.com repo from the backup server, make sure /data/import/example.com/TLS/example.com.pem exists, make sure /data/BACKUP_DESTINATION contains git@bu25 (and not core@backup.dev), shutdown -r now, and retry.
-  * If you're setting up a fresh wordpress site, you have to access the admin panel over http first (e.g. run it `-p 80:80`), and activate the [https plugin](https://wordpress.org/plugins/wordpress-https/) before it will work behind the haproxy SSL-offloader.

to_migrate/doc/developing-dockerfiles-and-infrastructure.md

-# Developing Dockerfiles and infrastructure
-
-## Developing Dockerfiles
-
-To develop Dockerfiles, you can use a server that's not serving any live domains, use `docker` locally on your laptop, or use the `vagrant up` instructions to run the infrastructure inside vagrant.
-
-## Developing infrastructure
-
-To develop the infrastructure, create a branch on this repo and specify that branch at the end of the deploy command, for instance:
-
-```bash
-sh ./deploy/deploy.sh k4 dev
-```
-
-That will deploy a server at whatever IP address "k4" points to in your /etc/hosts, using the "dev" branch of https://github.com/indiehosters/indiehosters.
-
-## Testing new Dockerfiles in the infrastructure
-
-To test the infrastructure with a changed Dockerfile, you need to take several steps:
-
-* Develop the new Dockerfiles as described above at "Developing Dockerfiles"
-* When you're happy with the result, publish this new Dockerfile onto the docker hub registry under your own username (e.g. michielbdejong/haproxy-with-http-2.0)
-* Now create a branch on the infrastructure repo (e.g. "dev-http-2.0")
-* In this branch, grep for the Dockerfile you are updating, and replace its name with the experimental one everywhere:
-  * the `docker pull` statement in scripts/setup.sh
-  * the `docker run` statement in the appropriate systemd service file inside unit-files/
-* Push the branch to the https://github.com/indiehosters/indiehosters repo (if you don't have access to that, you will have to edit
-  `deploy/onServer.sh` to use a different repo, to which you do have access).
-* Now deploy a server from your experimental infrastructure branch (which references your experimental Docker image), as described above at "Developing infrastructure"

to_migrate/doc/getting-started-as-a-hoster.md

-Getting started as an IndieHosters hoster
-===========
-
-# Prerequisites
-
-Each IndieHoster is an entirely autonomous operator, without any infrastructural ties to other IndieHosters.
-These scripts and docs will help you run and manage servers and services as an IndieHoster, whether you're
-certified as a branch of the IndieHosters franchise or not.
-
-# Hoster data
-
-If you're used to working with git as a versioning tool, then it's a good idea to make `hoster-data` and
-`billing` into (private!) git repos where you keep track of what you're doing, including e.g. TLS certificates, so
-that you can track changes over time, and search the history to resolve mysteries when they occur. You may also use a different
-versioning system, or just take weekly and daily backups (but then it's probably a good idea to retain the weeklies for a couple
-of years, and even then it will not be as complete as a history in a versioning system).
-
-The hoster-data is about what each one of your servers *should* be doing at this moment.
-This is fed into CoreOS (systemd -> etcd -> confd -> docker) to make sure the server actually starts and keeps doing these things,
-and also into monitoring, to make sure you get alerted when a server misbehaves.
-
-You probably also want to keep track of Domain Name Registration, Transport
-Layer Security, Monitoring, and Domain Name System services which you are probably getting from
-third-party service providers, alongside the services which
-you run on your own servers.
-Note that although it's probably inevitable that you resell DNR and TLS services from some third party, and your monitoring would ideally
-also run on a system that's decoupled from your actual servers, you may not be reselling DNS
-hosting. If you host DNS for your customer on server-wide bind services that directly read data from files on the per domain data folders,
-then DNS data will be considered user-data for you.
-
-# User data
-User data is data owned by one of your users. Which human owns which site is something you can administer
-by hand somehow in the `billing` folder.
-All user data is *untrusted* from your point of view, it is not owned by you as a hoster,
-and users may change it at any time (and then probably contact you for a backup whenever they mess up!). It makes sense to give users
-only read-only access to this data by default, and have a big "Are you sure? Warranty will be void!" warning before they can activate
-write-access to their own data (and then probably trigger an extra backup run just before allowing them to edit their own raw data).
-This is how some operating systems on user devices also deal with this.
-But in the end, the user, and not you, owns this data, and they can do with it what they want, at their own risk.
-
-Just like a mailman is not supposed to open and read letters, you also should treat each user's data as a closed envelope
-which you never open up, unless in the following cases:
-
-* There may be things you need to import from specific files on there (like a user-supplied TLS certificate or DNS zone)
-* When running backups, you sometimes can't avoid seeing some of the modified filenames flying by (depending on the backup software)
-* After explicit permission of the user, when this is useful for tech support (e.g. fix a corrupt mysql database for them)
-
-In version 0.1 no user data exists because the TLS cert is part of the hoster-data, and so are the secondary email address to forward
-to and the git repository to pull the website content from. We don't need to back up users' websites, because they are already versioned
-and backed up in the git repository from which we're pulling it in.
-
-# Backups
-Your user-data, hoster-data, and billing folders together contain all the critical data
-of your operations as an IndieHoster, from start to finish, so make sure you don't
-ever lose it, no matter what calamity may strike. Once a month, put a copy of it on a USB stick, and put that in a physically safe place.
-
-You may give a trusted person an emergency key to your infrastructure, in case you walk under a bus. Think about the risk of data loss and
-establish an emergency recovery plan for when, for instance, the hard disk of your laptop or of one of your servers die.
-
-Make sure you often rsync the live data from each of your servers to somewhere else, and store snapshots of it
-regularly. Users *will* contact you sooner or later asking for "the backup from last Tuesday"
-and they will expect you to have one.
-
-# Basic digital hygiene
-At the same time, be careful who may obtain access to your critical data. Is your laptop really safe? Does the NSA have access to the servers you run?
-
-Someone may plant a Trojan on a computer in an internet cafe from where you access your Facebook account, access your gmail account
-for which you use the same password, reset your RackSpace password and restore a backup from your Cloud Files to somewhere else.
-
-Make a diagram of how your laptop talks to your USB sticks and your servers. Then make a diagram of the services you use and to which
-email addresses they send password reset emails. Draw a perimeter of trust in both diagrams, and start taking some basic measures to
-keep your daily operations secure.
-
-Don't mix accounts and email addresses which you may
-use from other computers, and keep your IndieHosters passwords and accounts separate from your other passwords and accounts, and reset
-them every few months. It might even
-make sense to dual-boot your laptop or boot from a live disk which resets on boot to make sure everything you do with IndieHosters data
-is done in a sterile environment. Ubuntu has a 'guest account' option on the login screen which maybe also be handy for this.
-
-Also: lock your screen when walking away from your laptop, and think about what someone could do with it if they were to steal your bag,
-or your smartphone.
-
-# Do I have to use this?
-As an IndieHoster you can of course use any infrastructure and scripts you want, as long as it doesn't change the format of each user-data folder, so that
-your customers can still migrate at will between you and other IndieHosters. However, you might find some of the scripts in this repo
-helpful at some point, and we hope you contribute any features you add to it back upstream to this repo.
-Thanks for taking the time to read through these general considerations - the next topic is [deploying a server](deploying-a-server.md)! :)

to_migrate/doc/migration-format.md

-# IndieHosters migration format
-
-## Deprecated
-
-Deprecated by the [web app migration procedure](../proc/webapp.md)
-
-
-## Version 0.2.2 (deprecated)
-
-When a user exports their data for domain.com, they get a zip or tar file that contains different files, depending on which application is
-running on their domain:
-
-### If using the 'static' application
-
-* TLS/domain.com.pem - Concatenation of the unencrypted private and public key of the TLS certificate, and intermediate CA cert if applicable.
-* static/www-content - static content to be placed in the web root
-
-### If using the 'static-git' application
-
-* TLS/domain.com.pem - Concatenation of the unencrypted private and public key of the TLS certificate, and intermediate CA cert if applicable.
-* static-git/GITURL - git url to pull the static website content from
-
-### If using the 'WordPress' application
-
-* TLS/domain.com.pem - Concatenation of the unencrypted private and public key of the TLS certificate, and intermediate CA cert if applicable.
-* mysql/dump.sql - the dump of all their MySQL databases
-* mysql/.env - contains the MySQL password
-* wordpress/.env - contains the MySQL password
-* wordpress/login.txt - username and password for the WordPress admin panel
-* wordpress/.htaccess - htaccess file for WordPress
-* wordpress/wp-content - php files to be placed in the web root
-
-### If using the 'Known' application
-
-* TLS/domain.com.pem - Concatenation of the unencrypted private and public key of the TLS certificate, and intermediate CA cert if applicable.
-* mysql/dump.sql - the dump of all their MySQL databases
-* mysql/.env - contains the MySQL password
-* known/ - php files to be placed in the web root
-* known/.env - contains the MySQL password
-* known/login.txt - email address and password for the Known admin panel

to_migrate/doc/migration-procedure.md

-# Migration procedure version 0.3
-
-The IndieHosters network aims to allow users to easily migrate their hosted services from one hosting provider to another.
-To this goal, we describe a number of services which a hosting provider may offer, and a migration procedure for each of these.
-In this document, we will say the "user" migrates "services" from the "old hoster" to the "new hoster".
-
-We distinguish two types of migration: full migrations, and partial migrations. A full migration includes the migration of
-the domain name registration, DNS hosting, and all other hosted applications from the old hoster to the new hoster, and the user
-will no longer be a customer of old hoster once the full migration is complete.
-
-In a partial migration, only some services are migrated, and others are not. For instance, the IndieHosters product "Known hosting 0.3"
-consists of:
-
-* a domain name registration at a well-known registrar
-* DNS hosting
-* email forwarding
-* a redirect from http to https on port 80
-* a TLS certificate on port 443
-* version 0.6.5-mysql of the Known application running behind that
-
-If the old hoster offers this product, but the new hoster does not offer email forwarding, then only a partial migration is
-possible. The user will then have to accept that their email forwarding will stop working. Presumably, the user is OK with
-that, since they picked the new hoster themselves. But it's worth mentioning that this is then only a partial migration.
-
-Migration procedures:
-
-* [Domain name registration](../proc/dnr.md)
-* [DNS hosting](../proc/dns.md)
-* [Email forwarding](../proc/email.md)
-* [TLS certificate](../proc/tls.md)
-* [Web application](../proc/webapp.md)

to_migrate/proc/dnr.md

-# Migration procedure version 0.3
-
-## Domain name registration
-
-How to migrate a domain name from one hosting provider to another depends on the extension, and even for a given extension, there
-are serveral possibilities. In version 0.3 of this migration procedure, we will only consider one basic case, which is quite easy
-to deal with:
-
-* the domain name registration is in an account at a well-known registrar (e.g. NameCheap)
-* this registrar account is under control of the old hoster (not of the user directly)
-* the new hoster also has an account at this same well-known registrar, or is willing to create one
-* the registrar offers a "Transfer to another account" option
-
-The migration process is then as follows:
-
-* user has a service of type "domain name registration" with old hoster. Registrant is well-known and all above points apply
-* old hoster is listed in the IndieHosters migration network as supporting emigrations with type 'domain name registration'
-* new hoster is listed in the IndieHosters migration network as supporting immigrations with
-  * type: 'domain name registration'
-  * registrar: 'NameCheap' (or whichever well-known registrar)
-* user contacts old hoster, stating clearly and unmistakably that they want to migrate to new hoster
-* old hoster contacts new hoster to:
-  * confirm they will accept the migration
-  * agree on compensation for registration fee for months left until the domain is up for renewal at registrar
-  * agree on possible transfer of user's prepaid credit, e.g. if they were paying yearly at old hoster
-  * double check the new hoster's account identifier at the well-known registrar
-* old hoster transfers the domain name registration into the new hoster's account at the well-known registrar
-* old hoster notifies new hoster and user that this has been done, to reconfirm to the user what the next upcoming renewal date
-is for the domain name registration, and if any account credit was transferred

to_migrate/proc/dns.md

-# Migration procedure version 0.3
-
-### DNS hosting
-
-The migration of DNS hosting will usually result automatically when transferring a domain name registration and/or other hosted
-services. However, if the user had custom DNS records, then these may be transferred as a text file.

to_migrate/proc/email.md

-# Migration procedure version 0.3
-
-### Email forwarding
-
-The old hoster tells the new hoster what the user's forwarding address is.