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] 3
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 ...

This worked for me in Zentyal 3.4. supposedly this issue is fixed in Zentyal 3.5(+??)

Customize the ntp stub:

sudo mkdir /etc/zentyal/stubs/ntp
sudo cp /usr/share/zentyal/stubs/ntp/ntp.conf.mas /etc/zentyal/stubs/ntp
sudo nano /etc/zentyal/stubs/ntp/ntp.conf.mas

change the (last) line from:
ntpsigndsocket /opt/samba4/var/lib/ntp_signd/

ntpsigndsocket /var/lib/samba/ntp_signd/

Change permissions on the ntp socket directory:
sudo chgrp ntp /var/lib/samba/ntp_signd

Restart the ntp service:
sudo service zentyal ntp restart

Test from your Win7 machine (as admin):
w32tm /resync /rediscover

Voila ...

PS: some more info here:

News and Announcements / Re: Zentyal 4.0 Roadmap Published!
« on: September 10, 2014, 11:16:22 am »
So there is a lot of talk on modules that are being abandoned. Although  I do agree that it is for some modules regretful and for sure inconvenient - I also think it is something that is a fact and the company's good right.

However - the incrementally scrapping of supported modules over the last releases leaves me (and I presume many others) in uncertainty on what I can rely on for the future. It makes me very hesitant and wonder if and how Zentyal fits into my infrastructure (be it commercial or community edition).

It would be extremely helpful if Zentyal could list the modules they are (and will be) committed to supporting such that I can make a founded decision on the future position of Zentyal in my organization.

Thank you!


This is what I've got on 3.4.6 after a troublesome upgrade from 3.3.10 (3.4.6 webadmin is working now):

cat /etc/haproxy/haproxy.cfg

        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        user haproxy
        group haproxy

        log     global
        mode    http
        option  httplog
        option  dontlognull
        contimeout 5000
        clitimeout 50000
        srvtimeout 50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

Modified this to read

% if ($sharedroster) {
  {mod_shared_roster_ldap, [
    {ldap_filter, ""},
    {ldap_rfilter, "(&(objectClass=posixGroup)(!(internal=1)))"},
    {ldap_gfilter, "(&(objectClass=posixGroup)(cn=%g)(cn=jabberusers)(!(internal=1)))"},
    {ldap_ufilter, "(&(uid=%u)(objectClass=userJabberAccount))"},
    {ldap_groupattr, "cn"},
    {ldap_groupdesc, "description"},
    {ldap_memberattr, "member"},
    {ldap_memberattr_format, "uid=%u,<% $usersDn %>"},
    {ldap_useruid, "uid"},
    {ldap_userdesc, "cn"}

Now only the jabberusers group shows up.

Note that the group must have a description to show up in the shared roster.

solved - not sure which steps were necessary.

did a

apt-get remove -purge zentyal-jabber
apt-get autoremove -purge

Then reinstalled jabber through zentyal webadmin

Still not running, only a crash report in /var/log/ejabberd

Then ran into this post:

Which led me to kill some processes:

Rebooting the server isn't necessary, just make sure there's no beam, beam.smp and epmd processes running.
You can find them like this:
# ps axc|grep beam
# ps axc|grep epmd

Note that the epmd process comes up again after killing it.

And - tada - jabber can be started (I used "service zentyal jabber start" but I presume the webinterface would have worked as well ....

So - wanted to try and install ejabberd 2.1.13 to see if this solves the issue.

However the installer wants to configure from scratch so not sure if it is wise to proceed.

Any hints on how to just upgrade ejabberd within the Zentyal setting?

the used ejabberd version is indeed 2.1.10.

ejabberd 2.1.12 has an erlang related ldap fix on board ...

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

Dank je wel Ian - ik zal er eens naar kijken ... (Thanks Ian - I'll have a look at it ...)

OK - so it seems to be a user/group/computer sid thing rather than a domain sid thing.

Will look closer at batch export and import of users/groups/computers etc ...

EDIT: Interestingly enough the SID of both servers are the same so I do not expect it will resolve anything.

Is this the answer? Could I just run these commands without breaking anything in Zentyal?

You can restore a domain SID from the old to the new Samba server by using

net getdomainsid


net setdomainsid

This way you can run the new Samba server with the same domain SID as the old one. No need to change the clients.


Pages: 1 [2] 3