Problems Detected i...
 
Notifications
Clear all

Problems Detected in New Installation

5 Posts
3 Users
1 Reactions
693 Views
 Bic
(@bic)
Joined: 12 months ago
Posts: 7
Topic starter  

Hello, I apologize for my poor English, and I hope to explain correctly, and that my report can be helpful. I am installing Carbonio CE on Ubuntu 20.04 server for testing purposes, as I would like to migrate from Zimbra like many other users by December 31st. I have encountered two issues:

  1. I followed the installation guide perfectly on a fresh Ubuntu installation, but the carbonio-prometheus-nginx-exporter.service still does not work. I completed the installation regardless, but carbonio-prometheus-nginx-exporter.service does not start. I've seen other users on YouTube with the same problem.

  2. There is something wrong with the space quota for individual accounts. I have many accounts to transfer, and some have a customized quota higher than the one set in COS. Here's an example:

    • I set 250MB space for accounts in COS.
    • I created a new email, test@xxx.com, and in advanced settings, I set 500MB of space for this account.

    Now, when I check in the administration panel under account > details for test@xxx.com, it says 0 out of 250MB (this is an error; it should be 500MB). If I look in the advanced settings for the test@xxx.com account, it correctly shows 500MB of available space. However, when I log into the webmail as a non-administrator user and go to settings to check the used space, it says, "User Quota: Unlimited Space Available," which is also an error; it should be 500MB.

Thank you in advance.


   
Quote
(@stefanodavid)
Joined: 3 years ago
Posts: 185
 

@bic

Thank you for the report.

about point 1., please read this post: https://community.zextras.com/forum/carbonio-setup/the-issues-while-installing-follow-the-oficial-guide/#post-5863

about point 2. I will report this to our developers and QA team. 

 


   
ReplyQuote
(@0x3f8)
Joined: 11 months ago
Posts: 5
 

For what it's worth I followed these instructions on CE 23.9.0 for a single server installation and the nginx exporter would still not start even after the install was complete and everything restarted.  Perhaps I misconfigured something during the installation and there's a better way to fix this.  For the time being my solution to make it work was to modify the file

/opt/zextras/conf/nginx/templates/nginx.conf.web.https.template

to allow queries from my IP instead of 127.0.0.1 in the nginx_status directive

    location ^~ /nginx_status {
        # Location block to enable the stub status module

        stub_status on;
        access_log off;
        allow 127.0.0.1;
        allow <YOUR IP>;
        deny all;
    }

 

Now the exporter can access the URL and starts fine.  SSL certificate status shouldn't matter as the exporter is configured not to check the certificate validity.

 

For anyone else that wanders this way on a totally unrelated note, I had to use the Canonical AMI for Ubuntu in AWS. If I used the Ubuntu 20.04 suggested AMI, Carbonio would fail to bootstrap and there were numerous issues that weren't worth working through.  Just make sure to use the official image.

 


   
ReplyQuote
 Bic
(@bic)
Joined: 12 months ago
Posts: 7
Topic starter  

@0x3f8 Thank you 🙂 Your solution worked for me as well. Now, when I restart the exporter service, it starts normally. However, there is still an issue. In my case, I have to manually restart carbon-prometheus-nginx-exporter.service every time I reboot the server; otherwise, I find it stopped when the server starts.

root@mail:/home/tino# systemctl status carbonio-*
● carbonio-prometheus-nginx-exporter.service - Carbonio Prometheus NGINX exporter
     Loaded: loaded (/lib/systemd/system/carbonio-prometheus-nginx-exporter.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2023-10-13 10:45:59 CEST; 5min ago
    Process: 992 ExecStart=/usr/bin/carbonio-prometheus-nginx-exporter $ARGS (code=exited, status=1/FAILURE)
   Main PID: 992 (code=exited, status=1/FAILURE)

Oct 13 10:45:59 mail.sample.it systemd[1]: carbonio-prometheus-nginx-exporter.service: Main process exited, code=exited, status=1/FAILURE
Oct 13 10:45:59 mail.sample.it systemd[1]: carbonio-prometheus-nginx-exporter.service: Failed with result 'exit-code'.
Oct 13 10:45:59 mail.sample.it systemd[1]: carbonio-prometheus-nginx-exporter.service: Scheduled restart job, restart counter is at 5.
Oct 13 10:45:59 mail.sample.it systemd[1]: Stopped Carbonio Prometheus NGINX exporter.
Oct 13 10:45:59 mail.sample.it systemd[1]: carbonio-prometheus-nginx-exporter.service: Start request repeated too quickly.
Oct 13 10:45:59 mail.sample.it systemd[1]: carbonio-prometheus-nginx-exporter.service: Failed with result 'exit-code'.
Oct 13 10:45:59 mail.sample.it systemd[1]: Failed to start Carbonio Prometheus NGINX exporter.

I am also on a single server. Do you have the same problem?


   
ReplyQuote
(@0x3f8)
Joined: 11 months ago
Posts: 5
 

@Bic

Yes, I see the same thing.

It looks like the issue is the service doesn't depend on the nginx proxy being started first. It comes up with everything else, fails 5 times, then quits trying.

One solution that's probably better long term in case carbonio changes up the official systemd unit is to create an override.

you can do this

# mkdir  /etc/systemd/system/carbonio-prometheus-nginx-exporter.service.d

# cd  /etc/systemd/system/carbonio-prometheus-nginx-exporter.service.d

In that folder create the file override.conf and add the following contents

[Unit]
After=carbonio-proxy-sidecar.service

[Service]
Restart=always
RestartSec=30

 

Reboot and wait a few minutes.   I saw the exporter fail for a couple of cycles while it waited for nginx to start, then it eventually started.

I suspect the "After" directive above isn't really helping much since nginx takes so long to come up anyway.  It'd be more useful if "After" confirmed the service was running and responding to requests but it doesn't.  There's probably a more efficient way to solve this but for now this just works.

I am concerned that updates will roll right over the template change earlier as well but short of making that file immutable and potentially causing other problems I don't have a better solution for that yet.  Just check on it after updates unless you have a ci/cd pipeline, ansible, or terraform type tools to validate the allow directive after each update 😉

 


   
thecube reacted
ReplyQuote