Cloudron Forum

I think unless the package is modified heavily, it's not going to work .

@d19dotca If you exec into the mail container, you can run doveadm index -u mail@domain.com '*' . That does the indexing . Maybe the solr index got corrupt and it's throwing some errors?

You can also see the logs in /run/solr/solr.log

To clear the index:

Exec into the mail container (docker exec -ti mail /bin/bash) supervisorctl stop dovecot supervisorctl stop solr rm -rf /app/data/solr/dovecot supervisorctl start solr gosu cloudron:cloudron /app/code/solr/bin/solr create -c dovecot supervisorctl start dovecot doveadm index -u mail@domain.com '*'

@nebulon Fully agree, it's really odd that Wix doesn't allow AAAA records in this day and age.

I'll change that domain to noop for now then as recommended, but my preference is to have the logic of the location DNS propagation check change so that domains in manual status can still be successful even if only one IPv4 or one IPv6 address is set rather than both. The noop is for development after all, isn't it?

As long as one of the DNS records exists, that should be seen as successful IMO, since it will work in terms of getting traffic to the site still. There shouldn't be a reason to fail that.

@d19dotca it seems the yarn cache was note cleared. Clearing it brought down the size . It's in the new package.

For an marketing intro to passkeys -

My understanding is that they can be supported via WebAuthn - https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API

That makes sense, not sure why I hadn't thought of that one. I temporarily moved the invoice Ninja app to a different subdomain, created a quick LAMP app on the original subdomain with the file I needed, then verified and undid it all. Thank you for the idea @robi. 🙂

Good to know, thanks Girish. It never happened again, only once so I guess it was transient in nature. 🙂

Well I'm kind of ashamed to say it but I gave up, I spent far too many hours on this one (felt like ~25 between the last three days) just on this one single issue in order to avoid an IP block for my clients as Microsoft was blocking the IP of the host machine, and I still couldn't get it to work. I eventually opted instead to create a new Public Cloud instance at OVH instead, migrated all the data to it, using the floating IP, and things seem to be working fine now (only accessible with one public IP address so Docker had no other choice, lol). 🤷 Sorry there's no confirmed solution to this one.

This is now fixed with https://git.cloudron.io/cloudron/box/-/commit/c8cd67258ad0329214e46b841de62e26e36842de

@nebulon I’m not sure I understand… if my server had 128 GB to set, why does Cloudron allow me to set nearly 256 GB? That doesn’t make sense to me.

Well then looks like OVH is not setting the DMI/SMBIOS values then properly. I guess there is not much to be done to remedy this from our side, unless some other metadata standard is used by them instead.

It seems the issue here may have been a lot of CPU steal on my VPS, my provider has moved my VPS to a different host server and now it seems to be no longer timing out. Still monitoring, but seems to be the situation.

@d19dotca said in Blocked IP addresses in Cloudron but still able to access WordPress sites:

I know that this feature was likely originally intended to be a manual update rather than importing a giant list and works well for that, but as threats/spam become more common place, I think we’ll need Cloudron to keep up. Is it possible to prioritize improving this feature soon for us to allow thousands of IP addresses being added?

Fully agree! A strong network filter / block would be another USP

@d19dotca right, the 30d one seems to be 54975 size. I have increased the size of the ipset now to 262144 elements. If these things are growing more, we can look into making this size dynamic .

@necrevistonnezr Ah yes, that has some good stuff too, thanks for sharing that! 🙂 I think that article's steps still has some long downtime (at least when using object storage since it's so slow) but at least it's a bit more automated which is really cool.

@dsp76 indeed, thanks for reporting. The error message should read Hetzner instead of OVH when you select Hetzner. I have fixed this for the next release.

@robi @d19dotca identified the issue at https://forum.cloudron.io/topic/10434/email-event-log-loading-very-slowly-seems-tied-to-overall-email-domain-list-health-checks/9 . When we switch views, pending http requests of the old view are not canceled .

That seemed to do the trick - thanks so much @girish 🙂

@girish said in Suggestion for prereleases:

Some are updating to pre-release on production instances (despite the warnings about unstable) and expecting fixes quickly. To us, quickly even means 1 month.

Just to clarify from my perspective a couple of things and add my two cents...

Pre-releases in the past have nearly always gone very smoothly (which is awesome! 🙂 ) and I suspect this is why more and more people are open to running the pre-release builds even on production instances, because major issues are thankfully so rare. Combine that with long-awaited features or fixes users have been eager for, it's all a great incentive for more users to test out the pre-release. And personally I think that's a really good situation to have experienced users on the pre-release as we've been able to help the Cloudron team identify many issues that likely would not have been caught as soon otherwise. This helps improve then Cloudron product for everyone. I think there's perhaps a difference of opinion with different users and Cloudron team on what "quickly" means to them. In most of the software I use (and I suspect this applies to others too), software updates are often seen every 1-3 weeks especially soon after a major version release since they tend to be more buggy and need an initial bug fix patch released quickly rather than waiting for the next major release months later. On top of that, I think part of the "quick release" expectation by some users comes from seeing how quickly fixes are completed by the amazing Cloudron team here when we report issues, often fixed in 24-48 hours or less I find, so when we see that being so quick then waiting 1-2+ months for the fix just seems understandably unusual or unexpected.

@girish said in Suggestion for prereleases:

Cloudron is really like an OS, there are lots of packages, docker images and deps and is not a simple tarball on github and let the user figure it out. As a comparison, there is a reason distros are not pushing new releases every week or two.

While I tend to agree, even on an OS distro there is usually an easy way to get later versions of various applications. This isn't something that's possible in Cloudron currently so we're more reliant on the "OS" (aka Cloudron) here for bug fixes.

@girish said in Suggestion for prereleases:

Providing a way to update to unstable easily (just click a button) and then not providing fixes quickly is bound to disappoint at some point and it seems that point is now given this is upvoted a bit.

Maybe something to consider... two different branches. Pre-release and stable. Users can pick which one they want to run on their systems, and pre-releases get updates every 1-2 weeks perhaps, and stable every few months or whenever a new release is ready and considered stable. More and more software applications seem to be doing it this way, such as 1Password for example and nearly any browser, and more. This might satisfy those users who want to stick to stable releases and those who want quicker bug fixes and such and enjoy reporting issues on pre-release software to better help the Cloudron community. I see this also as an opportunity for Cloudron to grow better quicker by getting more rapid feedback from experienced users. 🙂

@girish said in Suggestion for prereleases:

As a lesson, we will become more conservative about pre-releases i.e we will release only after we have tested extensively ourselves and also completed the features. This is how we did it before and we actually didn't have many complaints. We only implemented pre-releases because people were enthusiastic to test early and seems like this is more trouble than it's worth.

I tend to disagree on this one. In software - as you're well aware - beta testing is a critically important piece of the development cycle so that the final release is as least-buggy as possible. I know Cloudron used to beta test with only new deployments of Cloudron installs back in the day if I recall correctly, but the unfortunate part of that is that it isn't targeting the advanced users who want to test and report these types of issues encountered (I'm guessing most people installing Cloudron who would unknowingly get the new release would be newer users).

I think the Cloudron team should really embrace the beta testing / pre-release process and embrace working with experienced users in the forum here who are actively testing and reporting issues and enjoy helping improve the software with the fantastic Cloudron team. Tightening the process up I fear will only make things worse / more buggy before the final release as more things may go uncaught. You've got a good amount of people willing to test the product for you for basically free, why not take advantage it? It may create more bug reports which in-turn may be more work, sure, but that's a good thing IMO because they may otherwise go unnoticed and will then be sure to improve it for those who are not willing to beta test.

Side note: Maybe calling it a "beta" or even an "alpha" may be better because pre-release to some people implies it's close to a "release candidate" which in-turn implies it should be fairly stable. If the Cloudron team doesn't want so many people testing, then perhaps naming it as "beta" will give some users a bit more pause on installing it and only those experienced would be more willing to do it.

I know that's a long write-up (I offer my typical Canadian apology, lol), but I hope you can tell that I've given this a lot of thought and I hope that some of the notes above will be considered for how to handle releases in the future. 🙂 I'm always happy to discuss further if any questions at all.

Thanks for the report. This is fixed with https://git.cloudron.io/cloudron/box/-/commit/3a5d570e3c558e95b2110dfb529bd9f928bbaf35