Cloudron Forum

@girish yes, I meant this configuration option.

Thanks for sharing . Right... our current domain/location configuration follows an all or nothing approach. If one or more fail, it will refuse to bring the app up and will get "stuck" forever . We have a task somewhere to make this more smart and also make the app repair feature smarter but it always gets pushed out as low priority.

I have moved the session files out of the data directory now. Maybe we should move to redis even later.

@girish said in Immutable server os:

There goes my weekend to investigate...

I am sorry for that 😆 but to be honest I have also spent good amounts of past weekends diving into this topic.

@girish said in Immutable server os:

I had great hopes for CoreOS

Yes, fcos is actually the successor of this, but has meanwhile gotten a bunch of new components such as the usage of ignition instead of cloud-init.

I forgot to mention one other cool this about fcos. Once you have generated your ignition file you can use the coreos-installer to bake it into an iso file. I don't know if there is an easier way to generate a software appliance out there. And inside of the ignition file you can merge or even completely replace it at runtime with files it can fetch from the internet at runtime.

https://major.io/p/coreos-as-pet/ is another blog that highlights some of the potentials of fcos outside of the usual Kubernetes usage.

Sorry for the noise. I am not quite sure what I made differently before, but while I am 100% I got the sendmail error with the smtp option selected, after redoing it is working now for me as well.

Case closed.

@eddowding you have to modify the file /home/yellowtent/box/src/cron.js and the systemctl restart box.

If you are not comfortable making the changes, you can write to us at support@cloudron.io and we can apply the changes for you.

In the browser, it says : "2FA token is invalid".
In the app logs, I can see no error

Cloudron is the ultimate flywheel business. More users -> more community -> more insight -> more relevance -> more traffic -> more users -> more investment -> more apps -> more relevance -> more community -> more users 🔁

The whole reason I invest in this forum, and the crafting of my posts with SEO considerations, is the ROI I get from its growth in capabilities and like-minds to compare notes.

It's like having the best sys admin team to work with, everyone's here for the results, the better results everyone gets, the more come here to help with more positive results.

All the wins from one very reasonable subscription / membership. Long may it grow, and become an increasing part of a healthier online future.

Thanks, this now works after the update to 1.4.2

Thanks for reporting. That is fixed with 7.5.1

Already fixed bugs are the best bugs 😆

@girish I think in the case of Gitea it probably makes sense to not move from ldap to oidc, but to rather configure both. Their ux seemed quite clear to me even when logging in with oidc for a user which had it not configured beforehand. Instead of creating a completely new user it asked again for the username and password of my existing ldap user to link these two accounts together.

When last experimenting with Vikunja it preferred creating new users instead of combining them like Gitea does, so for some apps it makes sense to move to oidc only, while others are good in a combination of ldap and oidc.

Thanks! I did not expect such a quick fix after your first response, but the change looks sensible.

@girish ok, sounds good to me.

This should be fixed in 7.3.6

@timconsidine said in Silver Bullet is an extensible, open source, personal knowledge management application.:

deployed SilverBullet on another VPS, and it's nice

I agree. I also have tested it on another VPS and am in the progress of figuring out the best way to self-host this at home for now.

Zef has recently added a page that might be helpful.
Deploy Silverbullet and Cloudflare in Portainer
https://silverbullet.md/Guide/Deployment/Cloudflare and Portainer

OK, the mystery remains then. Nothing has changed on our side to cause this issue as such 🤔 .

@shanelord01 (waves) it auto-approves after a few minutes assuming your side is set up cleanly - I see you and welcome!

Many people have tried to relay over the past few weeks. Some don't have SSL (hard pass), some are using fake FQDN (hard pass), and then of course, we had a few bad actors come along and I had to boot em.

Be mindful of your blocks and mutes - whole instance blocking is a big sledgehammer unless it's just a whole instance of bad. Also, if you see someone on my relay and you're like, ewe, Derek should know about that, please ping me (at)derek(at)toot.thedoodleproject.net - I am watching but it's a LOT to watch and any visibility on bad instances is appreciated - let me know and I'll block em at the relay.

@andreasdueren i think I just followed their documentation: https://goauthentik.io/docs/providers/ldap/generic_setup