Hi,
Just some words to share my experience with the Single Server installation on a RockyLinux 9.
- Be (still and always) cautious with the way you write the hostname in /etc/hosts
- 10.2.3.4 myhost.example.com myhost is fine
- 10.2.3.4 myhost myhost.example.com is NOT as they lead to a not-fqdn zimbra_server_hostname
This was already the case with Zimbra OSE, and that has not been fixed.
- amavis-mc wants take advantage of zeromq but the needed prerequisites were not installed on my box, so :
- dnf install -y perl-Unix-Syslog zeromq-devel
- cpan install ZMQ::LibZMQ3
- service-discoverd crashes dump :
```
service-discoverd[1303]: panic: runtime error: invalid memory address or nil pointer dereference
service-discoverd[1303]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x50 pc=0x5dd9be]
service-discoverd[1303]: goroutine 1 [running]:
service-discoverd[1303]: github.com/go-ldap/ldap.(*Conn).nextMessageID(...)
service-discoverd[1303]: /home/agent/go/pkg/mod/github.com/go-ldap/ldap@v3.0.3+incompatible/conn.go:235
service-discoverd[1303]: github.com/go-ldap/ldap.(*Conn).SimpleBind(0x0, 0xc0000d1bd8)
service-discoverd[1303]: /home/agent/go/pkg/mod/github.com/go-ldap/ldap@v3.0.3+incompatible/bind.go:54 +0x13e
service-discoverd[1303]: github.com/go-ldap/ldap.(*Conn).Bind(0xc0000c42e0?, {0xc0000c47a0?, 0x43ca20?}, {0xc000012a45?, 0x60ed60?})
service-discoverd[1303]: /home/agent/go/pkg/mod/github.com/go-ldap/ldap@v3.0.3+incompatible/bind.go:116 +0x53
service-discoverd[1303]: github.com/zextras/service-discover/pkg/carbonio.connect(0xc000016600, 0x4a?)
service-discoverd[1303]: /tmp/service-discover/pkg/carbonio/ldap.go:216 +0x1eb
service-discoverd[1303]: github.com/zextras/service-discover/pkg/carbonio.(*ldapContext).QueryAllServersWithService(0x16?, {0x654469, 0x10})
service-discoverd[1303]: /tmp/service-discover/pkg/carbonio/ldap.go:149 +0x65
service-discoverd[1303]: main.queryAllServiceDiscoverServers({0x6bf018?, 0xc000016600?})
service-discoverd[1303]: /tmp/service-discover/cmd/service-discoverd/service-discoverd.go:318 +0x31
service-discoverd[1303]: main.runServiceDiscoverDaemon({0x6bfb08, 0x869100}, {0xc000014040, 0x2, 0xc0000061c0?})
service-discoverd[1303]: /tmp/service-discover/cmd/service-discoverd/service-discoverd.go:132 +0x3d7
service-discoverd[1303]: main.main()
service-discoverd[1303]: /tmp/service-discover/cmd/service-discoverd/service-discoverd.go:92 +0x36
```
This is systematic at each reboot, though I cannot reproduce when running the same binary on foreground. But I wonder if the service-discoverd would not try to connect to a LDAP daemon which, unfortunately, has not yet started at that time...
4. I also had to `zmprov sp zextras@example.com myPassword` before connecting to the Admin UI. The document would probably takes advantage of adding a word about that.
At the moment, seems that ldap, proxy, mta work fine. I have to debug all the mesh architecture..
Hope that may help.
Regards
Pierre
Hello,
Still on the road of cleaning up error messages found in the journal after the install.
First, I do confirm that starting the service-discoverd daemon when ldap is ready (i.e. as soon as slapd.pid exists) prevents the previously reported segfault. I get now "envoy" info log lines, which I didn't have before. Fine.
I have had to fix some permissions reacting to some error messages in the journal :
- mkdir -m 0755 /var/log/carbonio/storages && chown carbonio-storages:carbonio-storages /var/log/carbonio/storages
- chown -R carbonio-message-dispatcher /opt/zextras/common/lib/mongooseim/log
So user and admin UI, proxy, mta and ldap (the core) work well (at least I send mails even if my current firewall config doesn't let me receive any), but collaboration services nor any mesh component do not work. I get lot of connection errors in the journal :
- `service-discover-wait.sh[4630]: 2024-12-04T10:06:19.409+0100 [WARN] agent: Check TCP connection failed: check=service:carbonio-message-dispatcher-auth-sidecar-proxy:1 error="dial tcp 127.78.0.23:21012: connect: connection refused`
All collaboration services seem to be concerned :(About 15 pending-setups are present.
What I currently suppose is that all the errors I see come from a postgresql database issue.
Particularly, I wonder about the command `carbonio-message-dispatcher-migration carbonio_adm 127.78.0.10 20000` : 20000 here is the postgresql port we are addressing (POSTGRES_PORT in the script). I don't understand at the moment how it is expected to work as the postgresql listening port is 5432.
Any help more than appreciated 🙂
My adventures of this day.
First, I have checked every service defined in /lib/systemd/system/carbonio-*, and found that most of them were OK. Fine (and a good surprise).
Just, amavis was not properly setup. I have had to `mkdir /var/amavis && chown zextras:zextras /var/amavis` in order to have the msg-forwarder service up and running.
Services which are not OK :
- carbonio-docs-connector-db-sidecar and carbonio-docs-connector-sidecar
- carbonio-files-db-sidecar, carbonio-files-sidecar and carbonio-files
- carbonio-mailbox-db-sidecar
- carbonio-message-dispatcher-db-sidecar
- carbonio-storages-sidecar (though carbonio-storages is OK)
- carbonio-tasks-db-sidecar, carbonio-tasks-sidecar and carbonio-tasks
- carbonio-ws-collaboration-db-sidecar, carbonio-ws-collaboration-sidecar and carbonio-ws-collaboration
So as I found yesterday, the core of the mail server is fine, but collaboration components are not.
I am stucked here as I just discover the consul mesh architecture, and do not really understand it at the moment. So do not know what to look at..
I have configured my ws to gain access to the Mess Administration Interface which says that 12 services are not ok (but consul services are not same than systemd services). Though I am logged in with the bootstrap token, the UI says than there is no Roles, nor Auth methods, nor Peers (or I don't have acl:read or peering:read permissions), though this later may be normal in a single server installation.
Regarding the last line posted yesterday, I have understood that 127.78.0.10 20000 addresses the carbonio-message-dispatcher-db consul service, which I suppose acts as a sort of proxy to postgre... But that doesn"t lead very far : I have a process listening on this ip:port, but its child is defunc 🙁
Once again, any help would be very appreciated.
Regards
Pierre