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.
Pages: [1]
1
Directory and Authentication / (Solved) Setup As additional domain controller fails
« on: February 02, 2016, 11:10:58 pm »
I figured this out by myself finally. I'm adding it here since I couldn't find any help when searching for it.
Error is " The following modules failed while saving their changes. Their state is unknown: samba"
In the logs ( /var/log/zentyal/zentyal.log ) the relevant error is "Error: Command output: Usage: samba-tool domain join..."
In this case it was caused by the way the script reads the domain admin password. It ends up not putting quotes around it, so any password containing spaces or possibly other 'special' characters will cause the setup script to fail. Changing the password to something without special chars will fix this error.
If your password isn't the problem, look for other information that may be passed to the samba-tool command without proper quoting (server names, domain, other settings, etc. ).
Error is " The following modules failed while saving their changes. Their state is unknown: samba"
In the logs ( /var/log/zentyal/zentyal.log ) the relevant error is "Error: Command output: Usage: samba-tool domain join..."
In this case it was caused by the way the script reads the domain admin password. It ends up not putting quotes around it, so any password containing spaces or possibly other 'special' characters will cause the setup script to fail. Changing the password to something without special chars will fix this error.
If your password isn't the problem, look for other information that may be passed to the samba-tool command without proper quoting (server names, domain, other settings, etc. ).
2
Directory and Authentication / Re: Issue Pushing Group Policy to Windows Client
« on: December 02, 2015, 05:04:34 pm »
I had a lot of trouble with this too. In my case it turned out to be a combination of things. First, make sure your users are in the correct OU for the policies. Also, check the security filtering to make sure the policies apply to the right groups. Use the group policy results tool in the Group Policy Management Console to make sure the policies are applied in the way you expect.
You said Zentyal was the PDC. Do you have additional domain controllers? If so, make sure replication is working:
samba-tool drs showrepl
I ended up having to set up a cron job to restart the replication service (samba-ad-dc) hourly before it would work reliably.
[Edit]
Also, read the logs on the clients to see if there are any errors.
You said Zentyal was the PDC. Do you have additional domain controllers? If so, make sure replication is working:
samba-tool drs showrepl
I ended up having to set up a cron job to restart the replication service (samba-ad-dc) hourly before it would work reliably.
[Edit]
Also, read the logs on the clients to see if there are any errors.
3
Installation and Upgrades / Re: [SOLVED] IP process is 100% CPU since last security update for Zentyal 4.1
« on: December 01, 2015, 05:19:05 pm »
Just a little more background & info:
This just got backported to 4.0, so I got to deal with it today. In addition to IP, the Cut process was also at 100%. It prevented DNS, DHCP, SAMBA, NTP and other important things from loading.
Here are Ubuntu bug reports on the issue:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1516052
https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1514785
It looks like there are several kernel versions affected, so this may come up again with future upgrades.
It stems from a bug in the kernel that makes the ip command output the first rule infinitely. You can use this command to see if you're affected:
ip route ls
Broken Output:
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
<repeats indefinitely - ctrl+c to quit>
In Zentyal, this causes one of the network scripts to hang because it's waiting for that command to end. This prevents loading of other services and resulted in my network being severely broken.
Besides the previously mentioned fix of rolling back the kernel, you can modify the script in question:
/usr/share/zentyal-network/flush-fwmarks
I just copied the file to flush-fwmarks.old, then edited the original commenting everything out. I like this solution because I still get the benefit of the security fixes in the new kernel. The down side is that the ip command is broken and firewall marks don't get flushed, but I don't really care about those If you do care about those and have some shell scripting ability, it should be relatively easy to modify that script to notice that ip is broken and move on.
This just got backported to 4.0, so I got to deal with it today. In addition to IP, the Cut process was also at 100%. It prevented DNS, DHCP, SAMBA, NTP and other important things from loading.
Here are Ubuntu bug reports on the issue:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1516052
https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1514785
It looks like there are several kernel versions affected, so this may come up again with future upgrades.
It stems from a bug in the kernel that makes the ip command output the first rule infinitely. You can use this command to see if you're affected:
ip route ls
Broken Output:
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
<repeats indefinitely - ctrl+c to quit>
In Zentyal, this causes one of the network scripts to hang because it's waiting for that command to end. This prevents loading of other services and resulted in my network being severely broken.
Besides the previously mentioned fix of rolling back the kernel, you can modify the script in question:
/usr/share/zentyal-network/flush-fwmarks
I just copied the file to flush-fwmarks.old, then edited the original commenting everything out. I like this solution because I still get the benefit of the security fixes in the new kernel. The down side is that the ip command is broken and firewall marks don't get flushed, but I don't really care about those If you do care about those and have some shell scripting ability, it should be relatively easy to modify that script to notice that ip is broken and move on.
Pages: [1]