Logging - targets, retention etc

[charlesnw]

I briefly searched the forum and didn't find anything on this topic. Feel free to point me to existing topics.

1. Is off-box/remote logging possible? I presume I can drop to the root shell and tweak the (r)syslog configuration to send things to a remote target. I would prefer a UI/API way todo this task (to ensure it doesn't break anything).

2. Same for other logging settings (retention/rotation).

3. Integration of logwatch

4. Is the /etc/aliases (root) alias setup to send to whatever Cloudron (SuperAdmin)(s) e-mail addresses?

5. What about docker logs? (Targeting/retention)?

Cloudron is wonderful and covers many of my needs. However I also have a Coolify server and it's running things like Graylog/Librenms and other infrastructure bits that Cloudron doesn't provide. For those of us with a bit bigger "enterprise" type setup/requirements, Cloudron could use some lightweight integration points/support.

[BrutalBirdie]

@charlesnw said in Logging - targets, retention etc:

Is off-box/remote logging possible? I presume I can drop to the root shell and tweak the (r)syslog configuration to send things to a remote target. I would prefer a UI/API way todo this task (to ensure it doesn't break anything).

For 1. and 2.
Not from the UI, yet
Has to be done manually at the moment.

3. Hmmm might be something to look at.

4. I don't think so

5.
Not 100 % sure hmmm.
Same as 1. and 2. I guess.

[charlesnw]

@BrutalBirdie Thanks.

I also notice that /etc/aliases isn't setup and no mail command exists.

How is mail to/from root handled by Cloudron? That's particularly important for things like logwatch. Also what about cron jobs running as root etc?

I realize that Cloudron is meant (and does a fantastic job) of abstracting away from the underlying VPS (essentially the VPS can be treated as "read only" after Cloudron install).

Still, the OS may occasionally alert on something. Especially if say someone is running a RAID array and wants alerts or has smartmon setup etc. The default/easiest way most of those OS level tools work is e-mailing root , and the expectation is that any forwarding etc is handled by /etc/aliases and an OS level SMTP setup.

I do see that docker is listening on 25:

root@tsys-cloudron:~/.ssh# netstat -punta|grep 25
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 1192/dockerd

Perhaps something like msmtp could be setup to listen to 127.0.0.1:25 and forward to the Cloudron SMTP instance?

[BrutalBirdie]

I am using nullmailer for my systems, which is confiugred to use a Cloudron Server SMTP for sending.
This might be something that could be setup by default in the future when Clouron is first setup.
Since every domain in Cloudron, by default, can send mails, even if they might land in spam at first.

@staff might interesting going further

[necrevistonnezr]

@BrutalBirdie
Can you share your config? I don’t get it to work:
/etc/nullmailer/defaultdomain

cloudron@mydomain.com

/etc/nullmailer/remotes

my.domain.com smtp --port=587 --starttls --user=user@mydomain.com --pass=apppassword                              

Yet, mails are rejected as they are being sent as „user@cloudron“ instead of „cloudron@mydomain.com“

[BrutalBirdie]

@necrevistonnezr my config, with redacted details
/etc/nullmailer/remotes:

mail.DOMAIN.TLD --port=587 --auth-login --user=sendernullmailer@DOMAIN.TLD --pass=that-is-one-secure-password --starttls

/etc/nullmailer/adminaddr:
note: this is the mailbox where to send the mailto

nullmailer@safeserver.de

/etc/nullmailer/allmailfrom

sendernullmailer@DOMAIN.TLD

restart the nullmailer.service after changing the files:

systemctl restart nullmailer.service

---

From https://wiki.debian.org/nullmailer

Check the configuration by sending a test email.

echo "hello" | NULLMAILER_NAME="Testsytem check" mail -s "This is just a test with nullmailer" "target-email-address@your-domain.net"

[necrevistonnezr]

Thanks! I didn’t have /etc/nullmailer/allmailfrom even after sudo dpkg-reconfigure nullmailer and it’s not mentioned on the debian site?

[BrutalBirdie]

@necrevistonnezr uhhhmmm
Since I set up everything with ansible, I once found this out, put in my playbook and forgot about it.
That it does not exist in the deb doc is questionable.