basic prototype now lives in https://git.cloudron.io/fbartels/bitwardenrs-app

cannot build it at the moment, though. since its stuck at

$ cloudron build                                                                                                                                                                                                                  
Building com.github.bitwardenrs@0.1.0

Build scheduled with id 9fcf31f1-04f9-445e-b687-79b2f7d54659
Waiting for build to begin, this may take a bit...

@girish is the backend maybe hanging?

edit: by now the build has finished

@necrevistonnezr said in Bitwarden - Self-hosted password manager:

even with 1 GB of memory assigned, I get a "ran out of memory" quite often
currently the app is quite unresponsive as it's searching for favicons (as I can see from the logs)
Importing from Enpass 6 (json) worked fine for me

This probably depends quite a bit on the amount of data you throw at it. I actually started with an empty vault since password history etc would not have carried over anyways. But in my case it's easy to keep a portable version of keepass around if I need a password from the old database.

Maybe the icon caching is causing some troubles for you? You could deactivate this from the settings. Probably also a good idea to get in touch with the upstream project if they are already aware on this and if there is anything to lighten the load a bit

@necrevistonnezr said in Bitwarden - Self-hosted password manager:

how are updates done? Or will your app eventually become an "official" cloudron app?

My idea is to have a good base so that @nebulon can make this an official app.

Hi everyone,

I was checking my cloudron backend yesterday since I wondered if I had already gotten the upgrade to the latest 4.2.x version and noticed that the automated updated failed since the server could not finish the backup run that is part of the upgrade. At that point the server had gone six days without a proper backup.

The issue was with the reverse proxy of my Minio installation (it seems that the 4.2.2 changed something in relation to max package size and that triggered a misconfiguration in my reverse proxy).

To make a long story short: I would have started looking earlier into it, if i'd had known that Cloudron had troubles backing up. For such a critical issue both a notification on the cloudron panel and an email would be nice. I do remember receiving mails in the past for certificates that could not be extended.

Hi,

I'm thinking about creating a Cloudron app that uses fetchmail to fetch external mailboxes and deliver their mails to local accounts. Depending if I find a good example for a config ui this would then be configurable either from a small web ui or by simply editing the fetchmailrc file from the console.

Anyone else interested?

Since all apps are running within containers there is a reverse proxy (Nginx) running that facilitates access to these apps. While it is currently not possible to configure this through the Cloudron UI (and manual modifications will likely be overwritten) I think it could be a good idea to have options to add ip access restrictions to apps and optionally also do sso on the webserver (nginx running on cloudron, not in the app) level.

Something like https://github.com/vouch/vouch-proxy/ could then do the oauth part towards the cloudron user management.

Maybe https://pleroma.social/ could be an alternative to Mastodon

From https://blog.soykaf.com/post/what-is-pleroma/:

Pleroma is a microblogging server software that can federate (= exchange messages with) other servers that support the same federation standards (OStatus and ActivityPub). What that means is that you can host a server for yourself or your friends and stay in control of your online identity, but still exchange messages with people on larger servers. Pleroma will federate with all servers that implement either OStatus or ActivityPub, like GNU Social, Friendica, Hubzilla and Mastodon.

How is it different from Mastodon?

If you are currently using Mastodon, you are probably interested in the differences between Mastodon and Pleroma. Here are some of the big ones.

Lower system requirements.
{...}
Less moving parts.
{...}
Internally ActivityPub.
{...}
Compatible with Mastodon clients (including the Mastodon frontend).

Hi @nebulon ,

I made a few tests today since I remembered that there is a dockerImage value in CloudronManifest.json, but I am not quite sure how to use it.

My current experiment is at https://github.com/fbartels/bitwarden_rs/tree/cloudron/cloudron. It uses a new Dockerfile that uses the multi stage Dockerfile as a base and uses a Cloudron Base Image for the last stage. But it seems he does not take my dockerImage. The only way he pulls in my image is by calling cloudron install --image fbartels/bitwarden-cloudron from the commandline.

For everyone else reading this. This is up until now only a build, the app is still missing all integration pieces and won't work withing Cloudron (yet).

Docker has recently been updated on the cloudron buildserver, which means multi stage builds and COPY --from now works within Dockerfiles.

I have a longer train ride on friday, maybe I can now make something happen with Bitwarden_rs.

I've now spent a bit of time to get the admin page "properly" working. Registrations are now disabled in the app itself, but users that are in the cloudron admin group can login to /admin to create the required users.

Stuff like Websockets support (for folder notifications) is still missing, as well as automatic SMTP configuration but I would say the general app is "done".

Looking forward to feedback.

I know "don't feed the troll", but

@murgero said in Spigot-MC-Server:

At this point, I am no longer going to work on this.

Props for keeping up so long with this ungrateful and entitled behavior.

I think in the end this pretty much depends on the individual application as not all are following the same mechanisms for distribution. All dns based lookups you could already configure yourself, although it surely makes it easier of Cloudron can set these entries up as well, for http based lookups a generic "forward this url from app x to app y" sounds like a simple task.

@necrevistonnezr then this here in the settings would probably be helpful for you:

I don't know enough about the internal workings of cloudron to give a definite answer, but from what I see I would guess your first install failed (because it could seemingly not fetch the right image) and now the app is in a failed state.

One way to get out of this is to try restore an earlier backup (but it also said => Backup - undefined) so its unclear if one exists, or remove the app and start anew.

@necrevistonnezr it seems to fail at downloading the image, so it has nothing to do with the app per se.

Can you also post the output of cloudron build?

Maybe it could also help to remove the existing app before (but since it fails at downloading I would doubt that).

@necrevistonnezr said in Bitwarden - Self-hosted password manager:

Could the "version" entry in CloudronManifest.jsonbe the culprit?

No, at least not from my experience. It always depends from where you installed an app previously. So for example when you initially installed an app from the official appcenter you can not easily update it with a locally build app. To make it recognize an existing app you can add the --app parameter to the install command.

So e.g. cloudron update --app bit

But make sure that the applications are actually compatible with each other.

@murgero said in Bitwarden - Self-hosted password manager:

This requires the build service app to be installed on your cloudron

That is not true. Its build locally and then pushed into the github account.

@iamthefij its not a technical problem, the approach isn't bad either. I think both (LDAP and MySQL) simply add unneeded complexity.

@murgero building is much easier now. when you call cloudron build it will ask for the registry to upload to. so you just have to enter your-username/your-chosen-name-for-the image, e.g. fbartels/cloudron-bitwardenrs. cloudron install will then automatically use this image.

@will I am still not a huge believer in the ldap sync and the mysql backend of bitwarden. I have updated my repo to the last version and also picked some smtp things from @iamthefij. Sending invites still does not seem to work, will need to look further into this.

Edit: Managed to fix the issue with sending invites. the value of SMTP_AUTH_MECHANISM needs to be quoted, but when exporting it, these quotes are normally removed. Working and up to date version is in the git repo.

@necrevistonnezr said in Runcloud.io vs ServerPilot.io vs Cloudron vs Sandstorm:

I don't remember this link being there (that you removed) when this topic was opened a few months ago

you can see the edit history of a posting. It was only added on the 19th of november at 23:40. Honestly also @KathleenMcArthur feels a bit like a spam bot posting backlinks to earn some referrals.

Hi @girish,

@girish said in Cloudron 4.3 released:

LDAP Connector

I was wondering about that, bit did not dare to try it since I only have my "production" cloudron. What happens when there is a user with the same name in my ldap, but that already exists locally? Can I map these users?

@girish said in Cloudron 4.3 released:

Custom Apps - Development and deployment of custom apps (using Docker

Does that mean that the requirement to base containers in the cloudron image is gone? (I must say I like this, since makes backups easy).