[BUG]: Solr image is oudated and does not support arm64 about docker-mailserver HOT 17 CLOSED

I understand. I just thought that won't fix was a better description than Resolved (as we did not resolve it but nuked it out of existence to avoid resolving it)

Nuking it is, for me, a way of resolving it 😉

from docker-mailserver.

I just tried using the official image instead and I get some errors from DMS:

May 20 11:03:44 f9b1fdbc38a6 dovecot: indexer-worker([email protected])<1215><1/B0+t4YAsFdWWg7:6PfOEfARS2a/BAAAMN9mZQ>: Error: fts_solr: Lookup failed: 404 Not Found

May 20 11:03:44 f9b1fdbc38a6 dovecot: indexer-worker([email protected])<1215><1/B0+t4YAsFdWWg7:6PfOEfARS2a/BAAAMN9mZQ>: Error: Mailbox Archive: Status lookup failed: Internal error occurred. Refer to server log for more information. [2024-05-20 11:03:44]

I'll look into what needs to be changed in the config.

from docker-mailserver.

Seems like Xapian is working and K9Mail just cannot search text.

from docker-mailserver.

I'm open to dropping the docs page

I've made a PR dropping Solr:
#4025

from docker-mailserver.

This sort of thing can happen with community contributed content and features unfortunately.

There's no way around that sadly. But at least this way what community uses the community maintains so the new cool things work while the old ones are dropped. Like you said updating my chagnelog:

If you use Solr, support can be restored if you're willing to contribute docs for the feature that resolves the concerns raised.

I'll go ahead and close this as Won't Fix before the PR closes it as Fixed. Someone may get the false sense of the issue being solved and look for a solution in the comments.

from docker-mailserver.

I understand. I just thought that won't fix was a better description than Resolved (as we did not resolve it but nuked it out of existence to avoid resolving it)

from docker-mailserver.

Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it.

Parece que você encontrou um problema com a compatibilidade da arquitetura arm64 ao tentar configurar o Solr para pesquisa de texto completo no Docker Mail Server (DMS). O problema é causado pelo uso de uma imagem Docker (lmmdock/dovecot-solr:latest) que não foi atualizada para suportar a arquitetura arm64.

Uma solução possível seria substituir a imagem lmmdock/dovecot-solr:latest pela imagem oficial do Solr disponível no Docker Hub, que suporta múltiplas arquiteturas, incluindo arm64. Você pode fazer isso atualizando o arquivo de configuração docker-compose.yml para usar a imagem oficial do Solr. Aqui está um exemplo de como você poderia configurar isso:

solr:
    image: solr:latest
    volumes:
      - ./docker-data/dms/config/dovecot/solr-dovecot:/opt/solr/server/solr/dovecot
    restart: always

Certifique-se de verificar a documentação oficial do Solr para garantir que o caminho do volume esteja correto e que todas as configurações necessárias para a integração com o Dovecot estejam configuradas corretamente.

Além disso, recomendo verificar se há atualizações ou discussões sobre este problema nos repositórios ou na documentação do Docker Mail Server, pois pode haver soluções ou atualizações específicas para essa integração.

This comment was generated by Glime.

from docker-mailserver.

Here are the image details:

from docker-mailserver.

From the looks of it it seems that Solr took longer than DMS to start up. Adding a healthcheck and recreating the container stack seems to get rid of the issue.

services:
  mailserver:
    image: ghcr.io/docker-mailserver/docker-mailserver:latest
    container_name: mailserver
    depends_on:
      solr:
        condition: service_healthy
    ...
  solr:
    image: solr:latest
    volumes:
      - /ext/email-data/docker-data/dms/config/dovecot/solr-dovecot:/opt/solr/server/solr/dovecot
    restart: always
    healthcheck:
      test: curl -sSf 'http://localhost:8983/' || exit 1
      interval: 10s
      timeout: 5s
      retries: 10

No further error indication in logs:

[   INF   ]  Welcome to docker-mailserver v13.3.1

[   INF   ]  Checking configuration

[   INF   ]  Configuring mail server

[   INF   ]  Starting daemons

[   INF   ]  mail.example.com is up and running

May 20 11:12:40 ffd6242e6045 postfix/postfix-script[1155]: starting the Postfix mail system

May 20 11:12:40 ffd6242e6045 postfix/master[1156]: daemon started -- version 3.5.23, configuration /etc/postfix

from docker-mailserver.

From a quick search using Snappymail everything seems fine.

from docker-mailserver.

Looks like Snappymail does a local search by fetching the emails? Using K9Mail returns this error in DMS logs:

May 20 11:37:37 ffd6242e6045 dovecot: imap([email protected])<5424><EXSqc98YuteT5bRZ>: Error: fts_solr: Lookup failed: 404 Not Found

from docker-mailserver.

Thanks for spotting this. The solr docs would have been contributed a long time ago (I've been a maintainer for several years and these existed prior to my early contribution of moving from Github Wiki to proper docs in git that we can review via PRs).

My understanding is that solr is less desirable for use with DMS, the alternative documented with xapian is the one I see encouraged more. Once the next Dovecot release is out it's expected that there will be official support for a better solution again.

Is there a specific interest in using solr for you? Or was this just from browsing our docs and deciding to try it?

I'm open to dropping the docs page, clearly there's been little interest in it if you're the first one to report these concerns 😅 (and that I've seen very little mention of solr usage from user engagement). If you find value in solr over alternatives that's helpful to know.

I'm a bit low on time to assist further on this, we're wanting to get a release out with a deadline at the end of the month, so I'll need to prioritize my time to some other tasks until then.

from docker-mailserver.

Is there a specific interest in using solr for you? Or was this just from browsing our docs and deciding to try it?

I basically decided to try it as it's supposed to use less space than xapian. Also there's an implication that Solar can index on demand rather than using a cron job? But basically there's no significant reason.

Once the next Dovecot release is out it's expected that there will be official support for a better solution again.

Should I then just wait for that or use xapian in the meantime?

I'm open to dropping the docs page, clearly there's been little interest in it if you're the first one to report these concerns

Yup, I figured. If its will be dropped I'll stop trying to make it work (it's crashing while loading the dovecot schema file and I cannot for the love of god make it load)

I'm a bit low on time to assist further on this, we're wanting to get a release out with a deadline at the end of the month, so I'll need to prioritize my time to some other tasks until then.

I understand. I'll probably drop this anyway, at least until there's time for a solution with you rather than me bodging my way further until it breaks something else.

from docker-mailserver.

Should I then just wait for that or use xapian in the meantime?

I think it's called flatcurve, we have an issue open issue tracking that. We've been waiting for the new Dovecot release for quite some time, but it's unclear when that'll land (and subsequently become available via our base image, currently Debian).

Yup, I figured. If its will be dropped I'll stop trying to make it work (it's crashing while loading the dovecot schema file and I cannot for the love of god make it load)

Yeah it's probably not something we can consider worthwhile to maintain. We can drop it from our docs so other users don't get misled and waste time, if someone feels strongly about it again, they can take the docs from a prior release and update them with working advice.

This sort of thing can happen with community contributed content and features unfortunately.

from docker-mailserver.

Why did it close again and as completed? For god's sake Github

from docker-mailserver.

It's good practice not to close such issues manually, and GitHub did well when re-closing this.

We provide a PR template that you can use to close such an issue automatically (this is what the "Fixes: ####" is for). This way, the issue is automatically closed when the PR (and therefore the corresponding changes) is merged :)

from docker-mailserver.

Comment migrated to separate issue: #4052

docker compose start solr (or up -d)
docker compose exec solr create -c dovecot

  solr:
    image: solr:latest
    container_name: solr
    volumes:
      - /path/to/solr-dovecot:/var/solr
    networks:
      - backend
    command:
      - solr-precreate
      - dovecot
    restart: always

rm -f /path/to/solr-dovecot/data/dovecot/conf/schema.xml
rm -f /path/to/solr-dovecot/data/dovecot/conf/managed-schema
rm -f /path/to/solr-dovecot/data/dovecot/conf/solrconfig.xml

curl -o /path/to/solr-dovecot/data/dovecot/conf/schema.xml https://github.com/dovecot/core/raw/a9cbc569ad0d3d827d81bf954088987b2de1d27c/doc/solr-schema-9.xml
curl -o /path/to/solr-dovecot/data/dovecot/conf/solrconfig.xml 
  https://github.com/dovecot/core/raw/a9cbc569ad0d3d827d81bf954088987b2de1d27c/doc/solr-config-9.xml

--- /var/data/dms/config/dovecot/solr-dovecot/data/dovecot/conf/solrconfig.xml	2024-05-03 15:55:51.708712626 +0200
+++ solr-config-9.xml	2024-06-06 18:26:52.543138695 +0200
@@ -76,7 +76,7 @@
 
     <!-- Load ICU analyser -->
     <lib dir="/opt/solr/modules/analysis-extras/lib" regex="icu4j-70.1.jar"/>
-    <lib dir="/opt/solr/modules/analysis-extras/lib" regex="lucene-analysis-icu-9.10.0.jar"/>
+    <lib dir="/opt/solr/modules/analysis-extras/lib" regex="lucene-analysis-icu-9.8.0.jar"/>
   <!-- an exact 'path' can be used instead of a 'dir' to specify a
        specific jar file.  This will cause a serious error to be logged
        if it can't be loaded.

from docker-mailserver.