I have created a bug report: https://github.com/miroslavpejic85/mirotalksfu/issues/200
avatar1024
Posts
-
reconnecting to the meeting randomly -
reconnecting to the meeting randomlyThings seems to have gone better for a while. But since the past couple of days it's gone really bad again. It feels like it is something on my end given other participants do not have those constant disconnections. Yet my internet seems very stable and for example with Jitsi or Teams (🤮) it's working totally fine and I have no disconnections...
I can't see anything in particular in the logs but happy to share the full log with @MiroTalk if useful.
I tried both with chromium and firefox and on two different servers (both cloudron with fresh install of mirotalk sfu)
-
Planka - A Trello-like Kanban board React/Redux@jadudm said in Planka - A Trello-like Kanban board React/Redux:
If the Cloudron team thought this was good to add to the stable of apps, I'd give it a go.
I'm sure they have nothing against it
. As far as I know they don't give a go ahead regarding apps or have a selection / veto process. If someone from community packages an app, they'll be super happy, they'll do some final checks to ensure it's done well and they'll publish it.
It's more for the app they package themselves that they select usually from the wishlist depending on votes, or from their own needs. But there again, it's just a way to prioritise, rather than to say they wouldn'd happy to publish others.
-
Unable to detect IPv6. API server (ipv6.api.cloudron.io) unreachableDid you set-up a PTR record for your IPv6 and checked all of the IPv6 threads on the forum (if you haven't you'll find several using the search function)?
-
Email search errorHi, did you check this, this and this? I got the similar errors when trying to run the indexing but after a few retry it works.
I tried to index email mailbox separately (by running the command inside the rebuild-index.sh for each mailbox separately) and identified which one caused the problem, then I had to open/read the problematic folders with a mail client, and then the index worked.
Given this feels like another duplicate, @staff, there might be something up / to improve with how the indexing is handled.
-
Email search not working properly@joseph said in Email search not working properly:
The tika error seems to be because tika was down .
What's tika?
Btw I did all mailboxes manually, I had to retry a couple but they all ended up indexing without errors in the end.
@joseph said in Email search not working properly:
I think a UI button to rebuild index will help a lot.
Yes to that! Though whatever the solution chosen it's gotta be robust against the process failing / encountering errors. So either a button per mailbox, or if global, then it needs to make sure it carries on even if if there are errors on one mailbox.
-
Email search not working properlyOk so I followed the steps indicated in the doc and there was a quirk. On a mailbox I got some errors:
Error: Mailbox INBOX/somefolder: Precache for UID=47 failed: Internal error occurred. Refer to server log for more information. [2025-03-30 07:54:41] doveadm(mail@domain.coop): Error: fts_tika: PUT http://127.0.0.1:9998/tika/ failed: connect(127.0.0.1:9998) failed: Connection refused
And then this stopped the indexing process altogether. So I had to manually run the command in the rebuil-index.sh script separately for all my mailboxes, avoiding the one that caused troubles, and on any mailbox where rebuilding the index worked, then search works again
Here is the detailed log related to the error above
2025-03-30 07:54:41.788 INFO (searcherExecutor-16-thread-18-processing-dovecot localhost-1846) [c: s: r: x:dovecot t:localhost-1846] o.a.s.c.QuerySenderListener QuerySenderListener done. 2025-03-30 07:54:41.789 INFO (searcherExecutor-16-thread-18-processing-dovecot localhost-1846) [c: s: r: x:dovecot t:localhost-1846] o.a.s.c.SolrCore Registered new searcher autowarm time: 3 ms 2025-03-30 07:54:41.802 INFO (qtp2067925017-24-localhost-1846) [c: s: r: x:dovecot t:localhost-1846] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update params={}{commit=} 0 129 2025-03-30 07:54:41.818 INFO (qtp2067925017-25-localhost-1847) [c: s: r: x:dovecot t:localhost-1847] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update params={}{add=[1/7824dd26093d43618202000011c04ec4/mail@domain.coop (1828004856394153984)]} 0 9 2025-03-30 07:54:41.831 INFO (searcherExecutor-16-thread-18-processing-dovecot localhost-1848) [c: s: r: x:dovecot t:localhost-1848] o.a.s.c.QuerySenderListener QuerySenderListener done. 2025-03-30 07:54:41.832 INFO (searcherExecutor-16-thread-18-processing-dovecot localhost-1848) [c: s: r: x:dovecot t:localhost-1848] o.a.s.c.SolrCore Registered new searcher autowarm time: 4 ms 2025-03-30 07:54:41.833 INFO (qtp2067925017-24-localhost-1848) [c: s: r: x:dovecot t:localhost-1848] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update params={}{commit=} 0 13 2025-03-30 07:54:41.922 INFO (qtp2067925017-25-localhost-1849) [c: s: r: x:dovecot t:localhost-1849] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update params={}{add=[1/288a8522203d43618202000011c04ec4/mail@domain.coop (1828004856499011584)]} 0 13 2025-03-30 07:54:41.934 INFO (searcherExecutor-16-thread-18-processing-dovecot localhost-1850) [c: s: r: x:dovecot t:localhost-1850] o.a.s.c.QuerySenderListener QuerySenderListener done. 2025-03-30 07:54:41.936 INFO (searcherExecutor-16-thread-18-processing-dovecot localhost-1850) [c: s: r: x:dovecot t:localhost-1850] o.a.s.c.SolrCore Registered new searcher autowarm time: 3 ms 2025-03-30 07:54:41.936 INFO (qtp2067925017-24-localhost-1850) [c: s: r: x:dovecot t:localhost-1850] o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/update params={}{commit=} 0 12
These seem to relate to some kind of time out issues. I also got some of these errors on another mailbox which I have set-up on a desktop email client, and by opening the problematic folders with the mail client and then rerunning the rebuilding of the index then it worked.
So wonder if something could be improve to make building/rebuilding the index more robust?
-
infomaniak IPv6 issues@jdaviescoates said in Email sending broken after updating to 8.2.x (due to IPv6 issues):
but 1) you have to pay 6 months in advance (whereas with Hetzner you can just pay for an hour if you cancel), 2) their default Ubuntu is stripped down and so installing Cloudron doesn't work until you mess around installing full Ubuntu first 3) their UI/ UX is just no way near as good as Hetzner's, etc.
Just to say, I used to be with Hetzner and I am now with Netcup and regarding: 1) you do NOT have to pay 6 months in advance (it's just cheaper if you do); 2) I had no such issue with their ubuntu version. I've installed Cloudron from blank ubuntu from Netcup and I've been running several Cloudron instances with no problems. Totally agree with 3), Hetzner UI is SO much better...but then their prices are also significantly higher so I'd rather get better hardware and a lesser friendly UI.
However on my servers, and despite following all the right steps, I kept having issue with IPv6. PTR records and DNS all check OK on Cloudron, MX checks etc, but I keep getting random email bounce from Gmail. The only final solution was to disable IPv6 completely. Perhaps Hetzner is better in that respect.
-
Planka - A Trello-like Kanban board React/Redux@ekevu123 said in Planka - A Trello-like Kanban board React/Redux:
Planka looks nice, sure, but it doesn't seem to offer a proper mobile layout or an app.
Actually I think it does:
https://github.com/plankanban/planka?tab=readme-ov-file#mobile-app
https://github.com/LouisHDev/planka_app -
Planka - A Trello-like Kanban board React/ReduxI know we already have wekan, kanboard, etc but this one has a really lovely and clean interface. Less feature rich but great for easy use and actively developed. Don't know how hard it might be to package but it would be cool to have.
-
Email search not working properly@joseph said in Email search not working properly:
@avatar1024 try https://docs.cloudron.io/email/#solr-index-corruption . The index is probably corrupt .
Thanks! I'll properly test tonight in downtime hours....but how the f**k have I missed that in the doc
Sorry for the bother if the solution is that simple and thanks for everyone's help.
-
Email search not working properlyI've tried again the above steps but now I used
doveadm -c /run/dovecot.conf index -u mail@domain.com '*'
as the index command and I'm not getting any errors...but also not getting any search results (all searches in roundcube returnSearch found no matches
). I tried on a very small mailbox where indexing shouldn't take anytime at all. Don't know if that's what's supposed to happen but that index command return to the prompt instantaneously, which seems weird.Also for info, I gave the mail service 6GB ram so shouldn't be a resource issue.
-
Email search not working properlyThank you, I followed those steps but I'm getting a lot of:
Error: fts_solr: Indexing failed: 404 Not Found
I've looked at that thread in more details as it seems like @d19dotca was facing similar issues when following those steps, yet the link that @girish provided doesn't exist anymore so I couldn't really see how to solve it. I tried to add the -c argument to the index command but that on its own didn't work and I was still getting those errors.
I have disabled full text search for now and at least basic searches are working normally until this is resolved.
-
Email search not working properlyHello,
I've noticed that email search has been weird over the past few days (might have been longer, not sure when it started), where the search in roundcube and snappymail returned result from email only from the last week but not for older emails.
I tried to deactivated and reactive full text search in Cloudron but since then I get no search result at all
...
I read the Cloudron doc but couldn't see anything obvious.
Running Cloudron 8.3.1.
-
Nextcloud OIDC integrationOk this regex to whitelist all groups except "admin" seems to work well
: ^(?!admin$).+$
-
Nextcloud OIDC integration@joseph Thanks, that worked!
So far I haven't been able to allow all groups but exclude "admin", but when I only allow only a specific group then the admin group is not provisioned and works as expected.
-
Nextcloud OIDC integration@joseph said in Nextcloud OIDC integration:
can nextcloud admin group have an arbitrary name or should it be admin(s) ?
In NC the group name for Admins is "admin". You can't change that and you can't create another group with admin rights. And in Cloudron one cannot create a group called "admin" (as you say the name is reserved). It feels like either:
- Cloudron admins and Super admins should be mapped with the NC admin group
- OIDC group syncing should exclude syncing the NC admin group
-
Authentication ConfigurationAnyone know if there is there a way to customize the OIDC login button for Listmonk? Currently for me it says "Login with .org.uk" instead of my domain or organisation name which is rather unhelpful. Thanks!
-
Nextcloud OIDC integration@jdaviescoates Yeah so it also works for me if I don't activate group mapping / syncing but I was asking if there is a solution to add admins users with that enabled.
On one instance we used LDAP groups syncing and so switching to OIDC we need to also sync groups...but then we also needs admins
Anyone got a clue?
PS: I've tried with my user who is a cloudron superadmin and with another user who is a Cloudron admin. None of them appear in the NC admin group or can be added to it.
-
Nextcloud OIDC integration@jdaviescoates Thanks! Have you activated group mapping / syncing though? For me it's not working. I cannot add myself to the admin group (and I have definitely logged in - in fact that's how I know I'm not an admin
). I can login with the "admin" user via the Nextcloud form but cannot add anyone else to the admin group, including myself.