Bitwarden - Self-hosted password manager
-
@will Strange. It looks like you're getting some validation issue from
bionic-*
for some reason. Possibly the clocks are off. Maybe try again? That's not specific to this project.It looks like you could reproduce with an new
Dockerfile
below, or just rebuild the existing one as caching should be in place now.FROM cloudron/base:1.0.0@sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617 RUN apt-get update
Does it work now? If not, check your system clock and timezone.
-
Interesting note:
I was using Ubuntu on Windows Subsystem for Linux last night. I performed the following steps:
01 Installing the App
$ sudo docker login
$ sudo cloudron login my.example.com
$ git clone https://git.cloudron.io/fbartels/bitwardenrs-app
$ cd bitwardenrs-app
$ sudo cloudron build
Enter repository (e.g registry/username/com.github.bitwardenrs): docker-hub-username/docker-hub-public-repo
$ sudo cloudron install
Location: bitwarden.example.comAfter that the apps worked in Cloudron, worked great!
Today I uninstalled the app, and ran through the same steps on a Fedora WSL box, the app deploys, but it seems to not be serving anything. I checked the logs and found this:
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.13. Set the 'ServerName' directive globally to suppress this message
Everything else looks good with the startup of the container. Thoughts?If Fedora isn't a supported dev enviroment, I'll swap back over to Ubuntu. Thanks guys!EDIT: It was DNS propagation with this issue! It's always DNS....
-
@will Mostly, we are just super short on time To release an app, we need to test the package, write docs, write tests, make sure updates work, make sure we understand packaging, all so that we can support it. Cloudron customers also ask us many app related questions so we have to be in a position to (reasonably) answer them.
Of course, we can just publish the app and skip all the above. I understand there is a need to "just publish" and we have a great bunch of early adopters here who will put up with all the above. I just spoke to @nebulon about this, we will get unstable package for bitwarden shortly without any of the above.
-
@will just a note, I don't believe fbartels version supports a using a dump for backing up the database. This means that if the backup is taken while the db is in a transaction, it could be corrupted.
Bitwarden_rs now supports an admin API for making sqlite backups, but does not have any cron embedded. Similar to the way the LDAP sync tool works, an additional script could be added to periodically make dumps of the sqlite database so that it can be properly backed up.
Instead, the version I have is using MySQL, which leverages the native Cloudron backup and restore functionality.
That and the LDAP invite service are the real differences between the two forks. If you do not wish to use automated LDAP invites on my fork, you can select to opt out when installing. This is covered in the readme.
-
-
-
thanks @iamthefij
For those looking to install this:
$ git clone ssh://git@git.cloudron.io:6000/iamthefij/bitwardenrs-app.git $ cd bitwardenrs-app $ cloudron install --image iamthefij/cloudron-app-bitwarden:0.3.0
Aaaannd it's running:
After installing, both my users got an invite to join bitwarden. Very cool.
-
@jdaviescoates Yes, tests plus making sure we can actually maintain it in the long run (for example, if everything is pinned properly in the docker file, things like that). Usually, @nebulon and also do a round of manual testing and put some basic docs before putting it in unstable.
@yusf yes, both users got the invite automatically.
-
@girish said in Bitwarden - Self-hosted password manager:
@yusf yes, both users got the invite automatically.
I'm guessing perhaps @yusf was asking because what if you don't want to invite all users automatically?
-
@jdaviescoates Namesake reads my mind.