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.

Topics - RAB

Pages: [1]
Other modules / Zentyal CA - CRL / OCSP
« on: April 20, 2023, 10:58:15 am »
The Zentyal (7.0) Certificate Authority allows for revocation of certificates.

However - it seems that the CA is not configured to provide certificate revocation information.

I noticed this when using curl to query a web server which uses a Zentyal CA provided certificate (of course with the Zentyal root CA provided to curl using --cacert).

Looking at the certificates no CRL endpoints are included, nor any reference to OCSP.
(Inspect for example the certificate of and such information is included)

>> Is it correct that Zentyal CA does not provide certificate revocation information?
--> If so - has anyone succeeded in adding this functionality and how?
--> If not so - what is/are the endpoint(s) for CRL and/or OCSP - and how can I include this information in the Zentyal CA generated certificates?

I am trying to set up a hidden share.

Followed these instructions for a stub to detect a dot in the name of the share and set browseable to no for that share.

Result is that users without access to the share do not see the share showing up.
So far so good.

However - for users with access rights the share shows up (in windows explorer) without the leading dot in the share name.

".Backup" shows up as "Backup" - it does not work/open when clicked/navigated in windows explorer.

Manually navigating to \\ZENTYALSERVER\.Backup  (with leading dot) does work and shows the share contents.

Any tips for making Samba show/apply the leading dot in the Share name?

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!


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?


(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.

I seem to hit this bug

I can not find a way to start jabber (despite the webadmin interface sayin that the module started correctly, the module status says "stopped". "/etc/init.d/zentyal jabber status" shows "stopped". a commandline restart takes forever to no avail.

The credentials in /etc/ejabberd/ejabberd.cgf match the ones provided in the webinterface. External ldap explorer works fine with the same credentials.

Any help would be appreciated!

From /var/log/ejabberd/ejabberd.log.1 (this is repeated many many many times):

=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.291.0>:eldap:983) : LDAP connection on

=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.281.0>:eldap:983) : LDAP connection on

=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.373.0>:eldap:983) : LDAP connection on

=INFO REPORT==== 2014-02-11 20:28:42 ===
I(<0.347.0>:eldap:983) : LDAP connection on

=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.347.0>:eldap:931) : LDAP bind failed on
Reason: invalidCredentials

=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.373.0>:eldap:931) : LDAP bind failed on
Reason: invalidCredentials

=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.281.0>:eldap:931) : LDAP bind failed on
Reason: invalidCredentials

=WARNING REPORT==== 2014-02-11 20:28:42 ===
W(<0.291.0>:eldap:931) : LDAP bind failed on
Reason: invalidCredentials

I am working on an upgrading our server from ebox 1.4.9 to Zentyal 2.2.

The latter is a fresh install on new hardware. The number of users, groups etc is fairly limited so I decided to manually configure the new server rather than importing users and groups etc. The domain name and server ip address remains the same after the upgrade.

Now if I log on as a user that is already existing on my Windows client (Win7Pro), the Windows client machine creates a new user profile. This is not what I want, I want to upgrade without disturbing any of the clients.

I have Google-ed my way around and searched the forum but cannot find any resolution.

What should I do to make sure that the users keep on using their existing client profiles? Maybe migrate some user key/id from ebox to the new Zentyal server or edit the windows client registry to mach some new id?

Thanks in advance for any useful hints!

Pages: [1]