Lodion

joined 1 year ago
[–] Lodion@lemmy.click 1 points 1 year ago

I didn't, I spun up an entirely new instance.

[–] Lodion@lemmy.click 0 points 1 year ago (2 children)

Nah, part of the playbook sets up the initial Lets Encrypt certificate... so DNS needs to point to the new VPS. And the hostname needs to match the existing instance as it is referenced in the database.

Doesn't matter now anyway, I went a different route :)

1
Instance relocation (lemmy.click)
submitted 1 year ago* (last edited 1 year ago) by Lodion@lemmy.click to c/lemmy@lemmy.ml
 

I'm planning to move my instance to a new VPS provider that will allow me to scale more simply.

Has anyone done this already and can sanity check my plan? My current setup was spun up using the ansible playbook here.

Current plan is:

Lower DNS TTL to 60 seconds (already done)

Shutdown on current VPS: docker-compose down

backup /srv/lemmy// and copy to new host

sudo tar -zcvpf backup.tar.gz /srv/lemmy//

scp backup.tar.gz user@newhost

update dns A and AAAA records, wait 1 minute, verify DNS has updated

run ansible script

Shutdown on new VPS: docker-compose down

restore backup to /srv/lemmy//

Startup on new VPS with restored DB etc: docker-compose up -d

test

destroy old VPS

Increase DNS TTL to 86400

Anything I've missed? :)

[–] Lodion@lemmy.click 0 points 1 year ago (3 children)

Is there a newbie guide written up already somewhere? This is exactly the sort of things it needs, which should be linked to new signups.

[–] Lodion@lemmy.click 0 points 1 year ago (2 children)

Are there any published guidelines on the server requirements for an instance? I have my own instance running, seems to be working fine. But I'm reluctant to open it publically without an idea of if I'm setting myself up for failure or not.

Related, is there a way to entirely disable image uploads to my instance? I'm ok with it being a "reader" instance, but don't want to be hosting content directly.

[–] Lodion@lemmy.click 1 points 1 year ago* (last edited 1 year ago) (3 children)

Ok, figured it out myself. For anyone else that needs it..

Run a shell within the postgres docker container:

docker exec -it _postgres_1 sh

Connect to the postgres service:

psql -U lemmy -h 127.0.0.1 -p 5432 -d lemmy

Connect to the lemmy database:

\c lemmy

Then the user table: \d local_user

Find the user ID of the account you want to manually toggle, probably #1:

SELECT * from local_user;

Then update the email_verified and _accepted_application flag on the first account:

UPDATE local_user SET email_verified = 't', accepted_application = 't' WHERE id = 1;

lemmy=# UPDATE local_user SET email_verified = 't', accepted_application = 't' WHERE id = 3; UPDATE 1 lemmy=# UPDATE local_user SET email_verified = 't', email_verified= 't' WHERE id = 3; UPDATE 1 lemmy=#

[–] Lodion@lemmy.click 0 points 1 year ago (4 children)

Thats what I figured... I just have no idea how to do it. Can you point me to any info on how to do that? :)

 

I’ve hit an issue with Lemmy. Initial startup was fine… I created my admin user and logged in. Then I created this account.

Third account I went to test with failed to login… then my other accounts also failed, so I rebooted.

Now when I try to log into my admin account, it just spins forever. Checking logs, I see this:

lemmy_server::api_routes_websocket: email_not_verified: email_not_verified

Can anyone tell me how I can manually flag my admin account as having been email verified already?