Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • lupa/compose.libre.sh
  • libre.sh/compose.libre.sh
  • ecobytes/compose.libre.sh
  • jordan.mitchell/compose.libre.sh
  • timothee/compose.libre.sh
5 results
Show changes
Hide whitespace changes
Inline Side-by-side
Showing
with 0 additions and 730 deletions
scripts/sub.class2.server.ca.pem deleted 100644 → 0
View file @ b0e6a82c
-----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/example.dev.pem deleted 100644 → 0
View file @ b0e6a82c
-----BEGIN CERTIFICATE-----
MIIFjDCCA3QCCQDmo57ouPDhnTANBgkqhkiG9w0BAQUFADCBhzELMAkGA1UEBhMC
UFQxETAPBgNVBAgTCFBvcnR1Z2FsMQ8wDQYDVQQHEwZMaXNib24xFTATBgNVBAoT
DEluZGllSG9zdGVyczEUMBIGA1UEAxMLZXhhbXBsZS5kZXYxJzAlBgkqhkiG9w0B
CQEWGGNvbnRhY3RAaW5kaWVob3N0ZXJzLm5ldDAeFw0xNDEwMTAxNTA3MDVaFw0x
NTEwMTAxNTA3MDVaMIGHMQswCQYDVQQGEwJQVDERMA8GA1UECBMIUG9ydHVnYWwx
DzANBgNVBAcTBkxpc2JvbjEVMBMGA1UEChMMSW5kaWVIb3N0ZXJzMRQwEgYDVQQD
EwtleGFtcGxlLmRldjEnMCUGCSqGSIb3DQEJARYYY29udGFjdEBpbmRpZWhvc3Rl
cnMubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAm/gbDGFtfMzT
nVZaPBQNl7SqMUMhTlDoR2C24W53QPslLuqBGkatbBs+9jWKGm2XPWeuK0uC2ot6
fIie72wghFepmzIdAb7SU0lpFVw49dk1nGVHIqwbFA3G6pYL7hY5ocD4HziNKnuj
ZA42a+rjpYl3zx/4GgcWnNyuawlsIMI8rdvuv5Mg77fGaVSXriJKQ1nTJ/Z65CDU
U6c9vzXSGkye3i0gv/8tZ0VA8xgV9FoXsLWhP7NLWDAh5+X/4aJpIFjvwzYSJLBr
3O9siP17NZuJI+7zB6KVlBeoSt2Dmt3k7fG2YrpwTzFlFBMr4Hq6T+wp+Q2J1JQP
Jm1s3lr2vJwmLVKlUspgT+zpuTAsUHOv2xxmbb+8k8ZE5II9IzAcE85C75bvL3An
fG0xQlF2+dOcXgvYFtRyeJ8fCIEjQBkOoUJq4H2inTwM2IYo060FF32jEVgFB5ZP
xuEsxEOGusUmOFsm8dIwaXv/WCPXopt1EGKFcNZWLSMC0jX0d4jZP74D1K0u4VPV
/kkQS6lUCK4qrq6tNm1R4TQlquefbfcwEhE8hVyUGcyDX6FOCL5z4lXal3gyUgbC
B50WrOST4hShb8+cWngcvDTO78kLg/OhqYZZVbpAshcF60sugEYke0xGNArWMQMU
5uxaWqPA3/gA3u4rJfWhLOwFIU+4ewsCAwEAATANBgkqhkiG9w0BAQUFAAOCAgEA
JiUIK43wZ6PHYrinKZu1wgDSbL7g3mNxSf2NiTMbu11J0JvypJc19DZHoSq5S0XH
yalW9Xeml9U8u/zHaciTwAaxWyj/gzqWyLBbd1xHTmdx+WvoG+OjcnYJYelrFzDH
bd4XumR+oHBXUsCiCIyF0d4gJZRUH8OxpDN/dD828FlcmMaeaPBl/xLm1G5ZXnPE
KNA8VR6ylo4w4HayQCjXI6qef29Y9I2Jvt9lREEpR5YoEnc1aj1ZJofeEzISfmhm
3D2BiI2Hx6mMlBwE95D+c9HZZAQyvdPyUdcTto7dOiJUGGt3EqhBRPebhe0HNlj8
L5h2/w1zChlQKWoFCZ4Uz6AJeibvPMZTEgihWtNWPyRAbjWL39GH1Emb/0m8ydaR
NmQEFL9VApMAsUm0mNHjWZQOTL5PYwgfKloXWMJ+rCd9N54sUUj5tt+Zc7G4irUN
Lnu8fYAaFC2BljANwQdy0H7pkVCYBcwwqvtKsrhX+FBGukkUjMo43FWep+fA82BU
uU6mlnPKm9vRYHC9gkKJejzFNgDZaC7p+xiwOO53oY/mFPgEVoCWwO0zAc1AXaZV
mJkkeYhRWpqmuxvqP+tpXFSfHu2Ee/RKBrrowWDOad3IlWuV7gt7Bo5ZBj+iqbPf
Km1Y5oFRF+Kp1NoIL527LHGj7dDV8eXinRIb7CPtbL4=
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
MIIJKQIBAAKCAgEAm/gbDGFtfMzTnVZaPBQNl7SqMUMhTlDoR2C24W53QPslLuqB
GkatbBs+9jWKGm2XPWeuK0uC2ot6fIie72wghFepmzIdAb7SU0lpFVw49dk1nGVH
IqwbFA3G6pYL7hY5ocD4HziNKnujZA42a+rjpYl3zx/4GgcWnNyuawlsIMI8rdvu
v5Mg77fGaVSXriJKQ1nTJ/Z65CDUU6c9vzXSGkye3i0gv/8tZ0VA8xgV9FoXsLWh
P7NLWDAh5+X/4aJpIFjvwzYSJLBr3O9siP17NZuJI+7zB6KVlBeoSt2Dmt3k7fG2
YrpwTzFlFBMr4Hq6T+wp+Q2J1JQPJm1s3lr2vJwmLVKlUspgT+zpuTAsUHOv2xxm
bb+8k8ZE5II9IzAcE85C75bvL3AnfG0xQlF2+dOcXgvYFtRyeJ8fCIEjQBkOoUJq
4H2inTwM2IYo060FF32jEVgFB5ZPxuEsxEOGusUmOFsm8dIwaXv/WCPXopt1EGKF
cNZWLSMC0jX0d4jZP74D1K0u4VPV/kkQS6lUCK4qrq6tNm1R4TQlquefbfcwEhE8
hVyUGcyDX6FOCL5z4lXal3gyUgbCB50WrOST4hShb8+cWngcvDTO78kLg/OhqYZZ
VbpAshcF60sugEYke0xGNArWMQMU5uxaWqPA3/gA3u4rJfWhLOwFIU+4ewsCAwEA
AQKCAgBGDvYnY4QIsQDFBcrWfbN1V4OzSRIm2ZTcqwa60CHlIGqdXlzLbr/rdXmc
ooP8RwnOXUoQzIRkoo5MbhnmNc2NZMscmTAKXqqfGrSHEbvMQtsf+yYu3tvy8BVP
vkJxma4diE5rx70xPgQwp2muo/3Jl6wnb5bEKjbwEviNv9fABz+2YLond3Et/IC1
Q3g2kdSF2E1PABpHaq+1O8QypXxQr+YUqnSxiW/dmXAJQeJqtiU6DPv3XxQS8tvo
DJoZwhgynYBlUV5o+I4a2bkI98NmWw0JBQZJgbBqqw2/Qy0gXVe9wftI8bINAIUE
tW/aD4as68oWwwwMXs1HV5O1dWqqrncx9SGNUSO+oqZPzjPBUtGpBj8sBOA6AgaU
ohnUhx4NLd3KEl+3yLgyv16VsW3XkOCCdtEwKfhLMfPM95LtOx0z1YsGP2DHQIb1
Q7lv81n5YCThIBxiRbDi46GgOAFukORb7rKfzu18qxiWyLLJ79QyONCdDZWU2jgA
8t3Fwzv28nXIetfxoRj8v0+B3NPxWS2StZ8Gltj/zVdbqiUyAU4TeV655la9bI2R
5NEQWW0q66BdJsSEnJ+6etM3yvaJ6rGw0Fz28JJuIwmc2uod14MgXFv3/ylg3bBK
Ddhuaw78iOz+hYq2rOk6xGB1q+HTTc61bFe1iKouTrVKT2jBoQKCAQEAyzfVyfzv
NS43ZcEe/MC+S8+zbjoxsS6b57hB6+lyokz2/YmliTpsmMgHnPSAWDUtXanGQjFY
IsDpt3r1x9wyOuNblKN4Xj/LqK+8ZS+qIwmFc84r9b7I8Evm3YOsYkUSRoroDhz1
eU09Df0YdLJaSTcJTvMm2LX+h3Yy6UTkHAg8nxI3PDF4SonV4QSf1LDWw1HGPiLv
quBPHGOrgcXvEpNOuOCzjmW90LKrRyk1V1rX9F+8e+Dr1rWpJKLFYVz6DgB5NFEI
rlz3PaZwQSdaeTMURt2Z9MErC3GHtGc+saf1vLdhQjoD2KAwG9FsqdtiaGX86Qh0
3Llblry0FkOHQwKCAQEAxHqkuAWS9DOcZPTs4VlQHItnHI+qRcp8hQZtz/8R204O
x8IbmMc7BQLLNKZj8yOP13d1uL+2RB3wJON6Z+GzfwLPG5ZuaklZv1j0c1r6/WZf
E9AMxO3IgC0o5tYxfB9JIPUfDbm7fpm2EZvlIK//29m5iC5Ii6E9PIbWenTjXpvy
NjDzRJDXoEa7lDzY0nKdwiiDrK+Hfte2CkS+4ESQALw8l84B8EPJ9mXFiFR4l6CG
ZlI8uLdb/FraChC1qgOknonEGS7WLwfxKhXoEo2X0cTDjR7awUtrXVB0yfpEGzsu
gxvmDMKudwBGM6BotkLuE337t44gUajiG/GB7syMmQKCAQEAuHespzfkY9/aBZHy
cPj9RI/7jplgtjda6lLF9EHq/wziP2+NRi40mdMppf4D6w4KajVMdJWaLaH0Bcum
A5AMQIxVe22QO+2pDyzG1QsZY8imzWJfYSmX+RjNLlLyThno5wP8daMv6LaGL4aJ
hpTHhCJjXrk1kA5UR96xhDI25oNLlBHS9d7qFK9d6G5sL4N+z7oRPCI2cGRBK8IF
0z07MR9qnEPMefw8+47UDzqG4w7hbUDiNYkMS9CHA2yFw0XE7qTbYPQV70EQZXQJ
/fqdE9ucEl/h+tzGGBMsXkRCEr4mQPItZRKIn0F5qibGfsFYaO/7TgWRHzNawk/1
ISiXRQKCAQBGXBkSoURf2P+fk6okhORQZId3TedO+NUgmg3HF3OgklJurI9PZcE3
6Sk14IQYdNq08V2h3F18BTCTNTcHbmbmC+541aUSwNO31zYq/SC2j+tqX+3Cs9hC
NmnYSEoORfHdMIp/UszW6Fqv8aDa1MwOQejT4KcwAXy5aRvzXFpz7eqOB3eGTUw6
ZDoWOrf2nP7robCNrYobHUpeYQHts//Rk5crUaWWEeCIMSfMy1soCV830ylViKwT
McG1KwizKnzQHUuxLPmce/6b8J5bzoLYptrUdYEnCUgYcZBxKAMtsULVxq7aUPlD
OkDpif8VjeBN8Kass+PU+mKGWTULfAq5AoIBAQCRd1bJmD/nAB90B19yzat7i1eZ
r6BUpMQ6vTMDA/u9uxn7A92kcZ6PFIPN3ez4ThIgSonAQHBKQYIblrDgPEQ/ixqe
YoKmvVQg5/fEXcpBZbKy3oNr437ZDWShbkPVsV7SvIsye3ckFQf/ASSOtKLY6E2Z
YQC1S9lXaIv7LOpZpIbGnrQuw/uXkuuW682vIjOsS+zGaq+UdLHVv0ZcTqbbmurh
HaWktTlH8htMK65JgvRv2Ze4a+xe83vCtinmK45yFdFJvkyVkTGGtE7wVeKaCyH/
2PRNVB8SMzV2lmvsr0jXi7FS8slvxzsLeMbLe+sYStIhatOYoBggnhSi/p9j
-----END RSA PRIVATE KEY-----
scripts/unsecure-certs/indiehosters.dev.pem deleted 100644 → 0
View file @ b0e6a82c
-----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-image.sh deleted 100755 → 0
View file @ b0e6a82c
#!/bin/bash -eux
image=$1
if [ "$image" == "wordpress" ] || [ "$image" == "known" ]; then
systemctl stop lamp@$image.test
sleep 11
else
systemctl stop $image@$image.test
fi
systemctl list-units | grep -c "$image\.test" | grep 0
rm -rf /data/import/$image.test
rm -rf /data/runtime/domains/$image.test
rm -rf /data/domains/$image.test
systemctl stop *@$image.test.timer
systemctl stop *@$image.test
systemctl reset-failed
if [ "$image" == "wordpress" ] || [ "$image" == "known" ]; then
systemctl disable lamp@$image.test
else
systemctl disable $image@$image.test
fi
systemctl list-units | grep -c "$image\.test" | grep 0
tests/deep-clean.sh deleted 100755 → 0
View file @ b0e6a82c
#!/bin/bash -eux
image=$1
BACKUP_DESTINATION=`cat /data/BACKUP_DESTINATION`
/data/indiehosters/tests/clean-image.sh $image
ssh $BACKUP_DESTINATION "rm -rf $image.test"
tests/finish.sh deleted 100755 → 0
View file @ b0e6a82c
#!/bin/bash -eux
systemctl list-units | grep -c failed | grep 0
applications=( static static-git wordpress known)
for application in "${applications[@]}"
do
/data/indiehosters/tests/test-image.sh $application
/data/indiehosters/tests/deep-clean.sh $application
done
tests/image.sh deleted 100755 → 0
View file @ b0e6a82c
#!/bin/bash -eux
cp /data/indiehosters/unit-files/* /etc/systemd/system && sudo systemctl daemon-reload
image=$1
# prepare data
mkdir -p /data/import/$image.test/TLS
cp /data/indiehosters/scripts/unsecure-certs/example.dev.pem /data/import/$image.test/TLS/$image.test.pem
echo "APPLICATION=$image" > /data/import/$image.test/.env
if [ "$image" == "wordpress" ] || [ "$image" == "known" ]; then
echo "VOLUME=$(cat /data/indiehosters/dockerfiles/services/$image/VOLUME)" >> /data/import/$image.test/.env
echo "EMAIL=test@test.org" >> /data/import/$image.test/.env
fi
# start image from import
if [ "$image" == "wordpress" ] || [ "$image" == "known" ]; then
systemctl start lamp@$image.test
else
systemctl start $image@$image.test
fi
# tests
/data/indiehosters/tests/test-image.sh $image
# start image from backup
## make sure to backup first
systemctl start backup@$image.test
/data/indiehosters/tests/clean-image.sh $image
if [ "$image" == "wordpress" ] || [ "$image" == "known" ]; then
systemctl enable lamp@$image.test
systemctl start lamp@$image.test
else
systemctl enable $image@$image.test
systemctl start $image@$image.test
fi
# tests
/data/indiehosters/tests/test-image.sh $image
tests/start.sh deleted 100755 → 0
View file @ b0e6a82c
#!/bin/bash -eux
applications=( static wordpress known)
for application in "${applications[@]}"
do
/data/indiehosters/tests/image.sh $application
done
tests/test-image.sh deleted 100755 → 0
View file @ b0e6a82c
#!/bin/bash -eux
image=$1
if [ "$image" == "wordpress" ] || [ "$image" == "known" ]; then
sleep 70
else
sleep 10
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 deleted 100644 → 0
View file @ b0e6a82c
# 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 deleted 100644 → 0
View file @ b0e6a82c
# 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 deleted 100644 → 0
View file @ b0e6a82c
# 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 deleted 100644 → 0
View file @ b0e6a82c
# 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 deleted 100644 → 0
View file @ b0e6a82c
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 deleted 100644 → 0
View file @ b0e6a82c
# 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 deleted 100644 → 0
View file @ b0e6a82c
# 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 deleted 100644 → 0
View file @ b0e6a82c
# 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 deleted 100644 → 0
View file @ b0e6a82c
# 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 deleted 100644 → 0
View file @ b0e6a82c
# Migration procedure version 0.3
### Email forwarding
The old hoster tells the new hoster what the user's forwarding address is.
to_migrate/proc/tls.md deleted 100644 → 0
View file @ b0e6a82c
# Migration procedure version 0.3
## TLS certificate
### Without a passphrase
The old hoster sends the certificate to the new hoster over a secure channel, as one or more .pem files.
### With a passphrase
The old hoster sends the certificate to the new hoster as one or more .pem files, where the .pem file containing the private key is
encrypted with a passphrase.
The old hoster sends the passphrase over a different and secure medium, in an unrelated message. For instance, if the .pem files were sent via
scp, the passphrase may be sent via PGP-encrypted email.