Organize deployment of production environment

curio-team / sdlogin

MIT License

0 stars 1 forks source link

Organize deployment of production environment #42

Open luttje opened 6 months ago

luttje commented 6 months ago

Taken from #40

[ ] Back-up old database
[ ] Perform local test update
[x] Check if the server has PHP 8.2+
[ ] Find a time to roll-out the update

Unrelated to this, but related to the sdclient package:

[ ] Update all our projects that depend on amoclient to sdclient (like done here: https://github.com/curio-team/narrowblast/pull/14) - so they're on the curio packagist

bartjroos commented 6 months ago

Server is still running php 7.0 on ubuntu 16.04.

Might be easer to spin up a new server based on the latest template, run this for a while under something like nieuw.login.curio.codes and when the time comes, we'll point the current subdomain to that new servers ip.

Updating the current server would probably be quite a hassle, and would likely even break the current loginservice; giving us no time to slowly migrate.

To be clear; I think sdlogin should keep it's own server, to make sure it will never in any way be affected by deploying other apps. The other servers are a bit more of a playground, therefore sdlogin should live on it's own more protected server.

bartjroos commented 6 months ago

[x] Set-up e-mails on the new server/application (or maybe just rip this out and have students always ask a teacher to reset password... this would need a more dedicated page/button)

bartjroos commented 6 months ago

[ ] This would also allow for testing the shortlinks / redirector functionality on the actual domains

luttje commented 6 months ago

[x] Set-up e-mails on the new server/application (or maybe just rip this out and have students always ask a teacher to reset password... this would need a more dedicated page/button)

In order to not land in spam we need a domain that does not contain 'curio'. I believe phishing filters block curio.codes

luttje commented 5 months ago

I've made some changes with regards to the password resetting. The email functionality has been removed (for the reason I mentioned above). Teachers can now force users to reset their password after they've changed it for them (default). Additionally I removed the password complexity restriction for admins, so they can set a simpler temporary password.

I'll move this into production in 2 weeks when we move to login2

luttje commented 3 months ago

FYI: Didn't manage to move this into production during the recent vacation. Will have to wait till end of the school year