DietPi-Software | vaultwarden: Rename from Bitwarden_RS #4334
Conversation
|
@MichaIng |
|
Hmhmhm. Another argument to force the reinstall is that the software name in the menu (uninstall, reinstall) and the docs changes as well. It might be confusing when one installed Bitwarden_RS and finally finds a vaultwarden install but no Bitwarden anymore and searching for Bitwarden in the docs does not show any result. At least we'd need to add a G_WHIP_MSG anyway, and then we can also say "sorry but due to this major upstream change we need to do a reinstall to apply it now. Grab yourself a coffee and you'll have the newest and safest password manager as reward for your patience!" or so 😄? How long was it on RPi Zero? 1.5 hours if I remember right, or do I mix it up with another build? @CactiChameleon9 |
MichaIng
changed the title
|
I think you should force the reinstall. The main reason for me saying that is that dietpi-update is (to some extent) optional and completely manual (not automatic) process - therefore people should be aware that its happening and that these things can take a long time, as with all updates. This would also remove the extra effort of maintaining the migration code. Furthermore - you can notify people of the change (to prevent confusion) as you stated earlier. BTW, I think you are correct in the 1.5 hour compile time on a pi zero (could be longer???) |
|
Ok let's go for the migration right on |
|
Maybe make it a |
|
Yes, I like that idea. I think you should do the warning if bitwarden_rs was installed, and explain it has been renamed and so the update will take a while. Maybe an estimate too?? I assume that should be done before any changes were made, possibly point out to the user that its OK to cancel and update later if they want too (raven beat me too it :D) |
|
first clean installation on my RPi4B was working well. Compiling was done in around 30-35 minutes. One strange thing I observed. One the web page it is stating
maybe the version tag was not updated? I placed a question on vaultwarden git. EDIT |
@Joulinar |
|
you are right @CactiChameleon9 |
|
@MichaIng |
|
Okay, let's go with forced reinstall. The reinstall/migration needs to be done in patches, as pre-patches are executed before any scripts have been updated, so a reinstall would then fail. For the |
|
ok I could try to get this moved into respective files if you are ok.
Would |
Jep. I didn't implement the old structure of |
|
Probably we should change wording inside user notification. Like |
|
Makes sense. I mean users will probably remember best how long it took on their particular hardware when installing it the first time. |
+ DietPi-Patches | vaultwarden migration: Reorder migration steps so that the data directory that is checked for whether to do the migration or not is renamed last, so that in case anything fails until the reinstall, it is repeated on next dietpi-update call. + DietPi-Patches | vaultwarden migration: Assure that no migration step can fail by checking for existing file/dir in every case, and error-handle everything. Assure that any renaming is done after all related edits are done, so that all related migration steps are repeated in case of failure. + DietPi-Patches | vaultwarden migration: Instead of error-handling the dietpi-software reinstall itself, exit with error code directly when it fails, as dietpi-software itself uses the error handler internally. So choosing "Exit" from within dietpi-software means then exiting dietpi-update as well.
|
I reordered the migration steps a bit so that in case of any failure, steps which have not yet been done are assured to be repeated. Only when the dietpi-software reinstall call failed, it would not be done, but it's probably best to call dietpi-software directly then. Ahh, actually it makes sense to allow the reinstall itself to error out and not exit the updater in this case. As all migration steps have been done, dietpi-update had no task left, so its okay to allow it finishing and print info to the user to reinstall the new vaultwarden option instead (and skip the updater wrapper/overhead by this). This also allows users to CTRL+C interrupt the reinstall and return to it later, of course with a nun-functional Bitwarden_RS/vaultwarden then. |
|
Jep, dietpi-software output needs to be there, but it is as it is not wrapped into G_EXEC now. This does not make much sense as it uses G_EXEC internally. In case of failure, when user cannot fix the issue by repeating or such and hits Exit, (s)he would land in a second error handler prompt then, which is a bit strange? But as said above, I think we should allow the final reinstall to fail. ... jep I think that is fine. Would be bad to abort the whole update when everything else has been successfully finished. So users can choose when they find time to repeat the lengthy reinstall. |
|
I removed the second "during", it is still a correct sentence 😅? |
|
I guess users are more happy with good coding instead of grammar 🤣 |
|
Shall we add an info that all data and configs will be preserved? |
|
That's actually a good idea |
Strange, when running the command to get the version manually, it works fine: Temporary connection issue? Will do reinstall anyway, but please check whether you see this error as well when testing. |
|
At least during my test it was wondering. Will do another one |
|
I did 2 test now. Both are fine from my side |
|
Strange is that I also didn't see any curl error message (which is always shown, including HTTP error codes), like the connection was fine, but the content not as expected. However, seems to have been some temporary issue then, second run in my case went fine as well. One thing we need to change is the amount of required memory, at least when more than one core is available. With VMs I ran into compile failures as the memory was full. They have 2 GB RAM (which makes the installer use two of four available cores) and a little higher idle usage (as e.g. APT cache + lists are in RAM) but it seems to be quite close and it would be a nightmare if you wait for hours on an RPi Zero and it fails in the middle with unspecified error message (it does not say something about OOM in a word) and even retries to compile the same thing with the other cores (when available) for a while which is doomed to fail. We could also limit the build jobs/core to 1, but that would ~double the compile time. |
|
Probably better to increase swap instead. On my RPi3B+ I added 4GB swap to enable compiling on all 4 core. |
|
reinstall + uninstall was working for me during my test. |
|
Jep works all fine here as well. I'll merge it. Memory usage will be addressed in a separate PR as probably this requires an extension for dietpi-set_swapfile to e.g. allow auto-applying a swap size so that 2.5 GiB overall memory is available. Currently only for 2 GiB overall memory, the swap size can be auto-applied. |
|
Changelog: e32e44f |
Project has been renamed to avoid legal issues with the original Bitwarden software dani-garcia/vaultwarden#1642
Status: Testing
vaultwardeninstallvaultwardenreinstallvaultwardenuninstalldietpi-updateReference: #4325
Commit list/description: