Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - RAB

Pages: [1] 2
Other modules / Re: zentyal.loggerd.service
« on: January 07, 2019, 04:54:09 pm »
upgraded to 5.1.3 and completely stripped the server from GUI (LXDE and X) - behavior still occurs roughly anywhere from once an hour to one minute in between occurrences.

Other modules / zentyal.loggerd.service
« on: November 15, 2018, 09:42:13 am »
Looking into freezes of my Zentyal 5.1.1 server I run into repeated occurrences of the below in /var/logs/syslog

Code: [Select]
Nov 15 09:29:41 my-server systemd[1]: zentyal.loggerd.service: Main process exited, code=exited, status=9/n/a
Nov 15 09:29:41 my-server systemd[1]: zentyal.loggerd.service: Unit entered failed state.
Nov 15 09:29:41 my-server systemd[1]: zentyal.loggerd.service: Failed with result 'exit-code'.
Nov 15 09:29:42 my-server systemd[1]: zentyal.loggerd.service: Service hold-off time over, scheduling restart.
Nov 15 09:29:42 my-server systemd[1]: Stopped Zentyal logger daemon.
Nov 15 09:29:42 my-server systemd[1]: Started Zentyal logger daemon.

Any suggestions on what may cause this behavior (and how to fix it  ;)) are most appreciated!

OK - solved

Changed the content of:

/var/lib/samba/private/tls/cert.pem to contain the content of the *-cert.crt file in the key-certificate package form the zentyal CA
/var/lib/samba/private/tls/key.pem to contain the content of the *-private-key.pem file in the key-certificatepackage form the zentyal CA
/var/lib/samba/private/tls/ca.pem to empty (no content). The file somehow needs to exist otherwise the start of the zentyal samba service fails.

/usr/share/zentyal/stubs/samba/smb.conf.mas to include at the end:

tls enabled  = yes
tls keyfile  = tls/key.pem
tls certfile = tls/cert.pem
tls cafile   =

Restart the zentyal samba service:

sudo zs samba stop
sudo zs samba stop

NOTE: Despite the empty setting for tls cafile in smb.config.mas, the start of the zentyal samba service fails if no tls/ca.pem file exists. Having an empty tls/ca.pem resolved this for me.

Ok - figured it out for the most part.

Just cannot find where Zentyal configures the samba certificates (the settings below from a plain samba config):

tls enabled  = yes
tls keyfile  = tls/myKey.pem
tls certfile = tls/myCert.pem
tls cafile   = tls/myIntermediate .pem  # if not required, set empty

The certificates used (default setup) for LDAPS on port 636 is the one found in

per this is the default location and tls is enabled per default.


Suggests that the certificates in
would only e used for LDAP.


This post:,32039.0.html

suggests that the certificates are located here on the Zentyal server:

Is this correct?
Can I just replace these by a certificate generated by the Zentyal CA or will this generate issues with the existing AD functionality?

The LDAP conf file also contains a reference to a certificate.

What is the role of this certificate? Does it require changing as well? Should it rather point to a certificate in


LDAPS is working but the certificate used does not seem to be issued by the CA (which is working fine for other services/servers) ... With LDAPS I am getting messages that the certificate is not valid.

Two questions:

1. Can I replace the certificate myself, and how can I make it persistent?
2. Is it possible to have LDAPS listed as a service in the Certification Authority under Services Certificates?


Never mind, the module list is just one layer deeper.

Just use an arbitrary module name that does not exist and on the unknown modulename the zs command will still display which modules are available.

for example:

# sudo zs myfakemodule restart


Could you also provide a list of the module names available in Zentyal 5 ?

I did put some effort into it but could not find an up-to-date list.

In particular I am looking for the module name of the zentyal web interface which froze on me (apache is up).


(behavior on Zentyal 5.0.7)

Whilst manually migrating from Zentyal 3.4 to Zentyal 5.0 I ran into the following which may or may not be expected behavior ... it was hard to isolate an may be of benefit to others.

Kept both Zentyal machines alive on different subnets, each being a DHCP server on their own subnet.
Old subnet will be used for servers, new subnet will be used for clients.
The subnets are routed via an external router for now, later they will both interface directly to the Zentyal 5.0 machine.

Transferred the server LDAP authentication to the Zentyal 5.0 machine in the new subnet.
This was working.

Then at some point the server LDAP authentication broke. It appeared that the servers with a fixed/reserved IP address (old subnet) could no longer reach the new Zentyal machine (no LDAP, no ping, no traceroute). When disabling the firewall on the new Zentyal 5.0 machine all was working as expected.

It took a while to figure out the problem, the cause was in the definition of a network Object on the new Zentyal 5.0 machine containing the servers in the subnet of the old Zentyal 3.4 machine.

I created a network Object "Servers" to be used in the future for fixed/reserved DHCP IP addresses.
The Names and IP/MAC addresses were identical to the "Servers" Object defined in the old Zentyal 3.4 machine as I plan to keep my servers in that old subnet.
In the Zentyal 5.0 machine no network interface was assigned to this subnet (yet), however the subnet was as stated above routed via an external router.
The network Object was NOT in use anywhere (not for fixed/reserved DHCP addresses) on the Zentyal 5.0 machine. It just was defined.
Interestingly enough, once the network object was created, the server machines (same reserved/fixed IP/MAC DHCP addresses as in the new "Servers" network object) from the old subnet could no longer contact the new Zentyal 5.0 machine.
The cients still in the old subnet (regular DHCP clients) had no issue in contacting the new Zentyal 5.0 machine.

Once I deleted the network object "Servers" on the new machine all was working again ...

It seems that he firewall definition / ip tables are generated using the network object whist nothing is being done with the network object (yet).

* Adding a firewall rule to the internal network to accept any service originating form the "Servers" network object did not seem to take any effect.

Used this in an attempt  to solve the nginx 504 timeout issue and it seems to be successful.

First create the stub (see above).
# nano /etc/zentyal/stubs/core/nginx.conf.mas

What seemed to work is to insert the lines

Code: [Select]
proxy_read_timeout 300;
uwsgi_read_timeout 300;

in the http context (look for the section below):

Code: [Select]
http {

    # Basic Settings

    # 20150513 Attempt to prevent nginx 504 timeout WSOD error in webadmin
    proxy_read_timeout 300;
    uwsgi_read_timeout 300;

    sendfile on;
    tcp_nopush on;

And finally restart webadmin:

# service zentyal webadmin stop
# service zentyal webadmin start

Note that after succesfull stop "service zentyal webadmin status" shows [RUNNING] - the webadmin does no longer respond however.

I have not seen 504's anymore since ...

Pages: [1] 2