Open mostafa-abdelbrr opened 2 years ago
I encountered the same thing with PlanetScale. I was unable to find in the docs via Diesel (Rust) nor MySQL to get the TLS connection to terminate properly. I am currently using https://filess.io/ for their free database offering.
There is additionally https://freedb.tech/ and https://www.freemysqlhosting.net/
Of course, please consider taking backups as needed. If you were using PostgresSQL, you will need to convert into MySQL (my original database is in MySQL so I just ran a clone job to backup there instead).
According to this: https://bend.green/blog/pedal-to-the-metal-with-planetscale-and-rust The problem is that Diesel didn't support root CA certificates until recently and the article authors had to implement it themselves and it is supported in Diesel version 2.0, while VaultWarden uses 1.4.8.
According to this: https://bend.green/blog/pedal-to-the-metal-with-planetscale-and-rust The problem is that Diesel didn't support root CA certificates until recently and the article authors had to implement it themselves and it is supported in Diesel version 2.0, while VaultWarden uses 1.4.8.
Nice catch! I played around with feeding root CA to the MySQL URI, but to no avail. Thanks for researching that. We can keep a note in the event it gets bumped to 2.0 in Vaultwarden.
I agree, we can do either that or try to make a workflow to build a custom image from Vaultwarden every time, but the problem is that Diesel v2.0 is not yet a stable release so that might be counter-productive for now.
I agree, we can do either that or try to make a workflow to build a custom image from Vaultwarden every time, but the problem is that Diesel v2.0 is not yet a stable release so that might be counter-productive for now.
I think that's probably more work than we want to go through. If it came down that route, I feel like an intermediary proxy between the two might be better than modifying the source code for Vaultwarden. Definitely not a Rust programmer and I'm sure we could clobber something together, but I don't think at this time it's the right move given there are many free database offerings for MySQL and Postgres.
What I suggested doesn't involve much Rust programming afaik, but I agree with what you said. I will use any of the alternatives you suggested.
@mostafa-abdelbrr Are you referring to basically bumping Diesel in the cargo.toml here to 2.0+ to resolve? If it's just bumping Diesel, I'm open to trying it!
Yes, but apparently there might be another simple change pointed out in the article as well at the very end.
This introduces one breaking change—you'll have to also change the decorator on line 18 of dal/org.rs
#[diesel(table_name = orgs)]
Yes, but apparently there might be another simple change pointed out in the article as well at the very end.
This introduces one breaking change—you'll have to also change the decorator on line 18 of dal/org.rs
#[diesel(table_name = orgs)]
I'm not sure I understand the specific decorator change they call out. Do you know how that would link in relation to Vaultwarden's database models?
After finding the line specified, it appears every line in VW's code that is like:
#[table_name = "some_table_name" ]
needs to be replaced by
#[diesel(table_name = some_table_name)]
without the quotes around the name, I think. I am no Rust programmer btw, sorry.
My search produced 13 such occurrences in VW code btw: https://github.com/dani-garcia/vaultwarden/search?p=1&q=%23%5Btable_name+%3D
Alright, let me see if I can do some patches and do what we did with Vaultwarden and just pull down a copy, replace, and build from Docker source versus prepackaged now. Thanks for the help so far!
I just hope I was of actual help! Thank YOU for your work on facilitating hosting VW for free!
@mostafa-abdelbrr I see with Vaultwarden 1.27 release, Diesel was bumped up to 2.0. Does this mean we can support root CA certificates now (including Planetscale)?
@davidjameshowell I will check now via checking their code and by testing it out, Filess.io has a weird quirk where it tells me every 30 days that I have not used it and it gets deactivated even though it is connected to my VaultWarden instance, so I dunno if I don't use it at all or something, I probably misunderstood how VW uses the DB.
Code wise: Update to diesel2 In this commit, they update the syntax so it looks promising, time to test it.
Yup, works thankfully. Tested making a clone of the repo, bumped the version number, and pushed. When using PlanetScale's connection url, it didn't crash this time. Had to delete my VaultWarden account first though because it caused problems due to migration files trying to run on a non-existing DB table, maybe there is a fix for that I don't know of.
Amazing! I'll have to swing back around on this and see if I can't rework it!
Honestly it might matter only if you use the KDF option, if you didn't tweak it then I think there is a chance it could work, but either way you will need to import your passwords hence backing up, deleting the account, then recreating it is a must imo.
I apologise if this is irrelevant/out of your scope, but you mentioned you used PlanetScale as DB backend, after creating an account there and trying to deploy this Dockerfile, I get this error with the failed deploys:
I used the details provided from PlanetScale for Symfony connection since it provides a DB URL as my
DATABASE_URL
environment variable.