Bitwarden - Self-hosted password manager
-
@fbartels was there a reason for moving the bitwarden image from the COPY statement to a FROM statement at the beginning? I'm picking up LDAP support again now that the hostname is available and I'm getting the binary from a published images as well.
Was it just to avoid pulling when modifying any config values?
-
@girish Hmm... it doesn't seem to be working correctly.
I'm getting:
Jun 26 17:55:25 thread 'main' panicked at 'Could not authenticate with http://8e50545e-6293-459d-8aa8-5abdb13695dc-ldap_sync:3000. Error { kind: Hyper(Error { kind: Connect, cause: Os { code: 111, kind: ConnectionRefused, message: "Connection refused" } }), url: Some("http://8e50545e-6293-459d-8aa8-5abdb13695dc-ldap_sync:3000/admin/") }', src/bw_admin.rs:62:17
It appears that the hostname is the hostname of the
ldap_sync
container that the cron job spawned? Is that correct? When I open a terminal for the app, it just gives the first part withoutldap_sync
, which seems right. -
@iamthefij do you mean https://git.cloudron.io/fbartels/bitwardenrs-app/blob/master/Dockerfile#L1 ?
That was so that just a single line needs to be changed when bitwarden is updated.
-
@girish roger. That worked! Now I'm getting some new error from within Bitwarden_rs, which is good and means that it's actually hitting the server!
@fbartels got it. That could also be facilitated using an
ARG
.It doesn't matter too much. The difference is really just in caching, but it doesn't look like the Cloudron build servers do caching.
-
-
@girish is there anything that might prevent this container from querying LDAP?
I'm getting the following error:
Jun 27 18:30:57 thread 'main' panicked at 'rc=1 (operationsError), dn: "ou=users, dc=cloudron", text: "No such app"', src/main.rs:21:9
To verify that it's something to do with the cron container, I generate the config file and cat it to the log in the main application as well as the schedule container. I diffed the two configs and they are identical.
However, when I run the sync script from the terminal attached to the main container, it works correctly. From the scheduled container, I get this error.
Any ideas? I'm actually unable to find out where the "No such app" comes from. It is a pretty generic term, so searching online isn't much help. I did check the
bitwarden_ldap_sync
codebase, the Rustldap3
codebase, and thebox
codebase, but no luck. -
@iamthefij I think that's the LDAP server not allowing scheduler containers from accessing it. Can you try this - https://git.cloudron.io/cloudron/box/commit/22d731f06da98af196c43e6713bf0ce551107fa6 ?
-
@fbartels in addition to the admin page issue described above, I'm running into email sending issues again.
This time I'm not having success with any setting.
Explicit TLS only: Bitwarden hangs and times out when trying to invite/send with a panic:
Jun 28 03:35:56 thread 'main' panicked at 'Could not call with http://90859b46-d863-4609-a83a-79c5f010254c:3000/admin/invite. Error { kind: Io(Custom { kind: TimedOut, error: StringError("timed out") }), url: Some("http://90859b46-d863-4609-a83a-79c5f010254c:3000/admin/invite") }', src/bw_admin.rs:134:21 Jun 28 03:35:56 stack backtrace: Jun 28 03:35:56 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace Jun 28 03:35:56 at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39 Jun 28 03:35:56 1: std::sys_common::backtrace::_print Jun 28 03:35:56 at src/libstd/sys_common/backtrace.rs:70 Jun 28 03:35:56 2: std::panicking::default_hook::{{closure}} Jun 28 03:35:56 at src/libstd/sys_common/backtrace.rs:58 Jun 28 03:35:56 at src/libstd/panicking.rs:200 Jun 28 03:35:56 3: std::panicking::default_hook Jun 28 03:35:56 at src/libstd/panicking.rs:215 Jun 28 03:35:56 4: std::panicking::rust_panic_with_hook Jun 28 03:35:56 at src/libstd/panicking.rs:478 Jun 28 03:35:56 5: std::panicking::continue_panic_fmt Jun 28 03:35:56 at src/libstd/panicking.rs:385 Jun 28 03:35:56 6: std::panicking::begin_panic_fmt Jun 28 03:35:56 at src/libstd/panicking.rs:340 Jun 28 03:35:56 7: bitwarden_rs_ldap::bw_admin::Client::invite Jun 28 03:35:56 8: bitwarden_rs_ldap::invite_from_ldap Jun 28 03:35:56 9: bitwarden_rs_ldap::main Jun 28 03:35:56 10: std::rt::lang_start::{{closure}} Jun 28 03:35:56 11: std::panicking::try::do_call Jun 28 03:35:56 at src/libstd/rt.rs:49 Jun 28 03:35:56 at src/libstd/panicking.rs:297 Jun 28 03:35:56 12: __rust_maybe_catch_panic Jun 28 03:35:56 at src/libpanic_unwind/lib.rs:87 Jun 28 03:35:56 13: std::rt::lang_start_internal Jun 28 03:35:56 at src/libstd/panicking.rs:276 Jun 28 03:35:56 at src/libstd/panic.rs:388 Jun 28 03:35:56 at src/libstd/rt.rs:48 Jun 28 03:35:56 14: main
Enable SSL only: Bitwarden hangs and times out when trying to invite/send
Jun 28 03:37:54 [Fri Jun 28 03:37:54.553168 2019] [proxy_http:error] [pid 34] (70007)The timeout specified has expired: [client 172.18.0.1:36626] AH01102: error reading status line from remote server 127.0.0.1:3000, referer: https://bitwarden.iamthefij.com/admin
With both enabled: I get the handshake error.
Jun 28 03:40:52 [2019-06-28 03:40:52][bitwarden_rs::error][ERROR] Error sending email. handshake error
-
@iamthefij yes, http auth is working in my branch.
I think I should add that I am not using the app for my production bitwarden install. This is still running on a different system.
I have also seen quite some weird behaviour in regards to the mail integration, but did not yet have the time or interest in really digging into it.
-
-
@d19dotca Apps that are not published yet have to be built by hand. It's easy to build though:
git clone <app repo> npm install -g cloudron-cli cloudron build # this will ask your cloudron.io login cloudron install # this will ask you for your cloudron's login
-
@murgero It's available to anyone, using the cli tool (https://cloudron.io/blog/2017-03-08-cli-part2.html)