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.
16
Installation and Upgrades / Re: Additional Domain Controller not Providing Fail Over
« on: May 26, 2014, 10:07:57 pm »
Well it turns out that you cannot restore the configuration for an additional domain controller:
Also, unfortunately, if you trying to create a new Zentyal server with the same name and ip address of a currently dead domain controller, you'll get error telling you that LDAP object already exists.
Making matters worse, there is no where in the Zentyal Web Interface to remove all remnants of a previously added domain controller.
If you go to here:
Zentyal Web Interface > OFFICE > Users and Computers > Manage
You'll see an entry in the tree structure for domain controllers, but uselessly, it doesn't list any of the ones you've previously added. If it did, that would be good place for the developers to provide a way of deleting a domain controller from LDAP. So you could then add it back again with the same name and IP address without receiving "already exists" error.
At this point, I've tried 5 fresh installations attempting to get this additional domain controller back online. This time I'm going to try giving the server a different name and ip address and see if I then have better success joining it.
Code: [Select]
Restore is only possible if the server is the unique domain controller of the forestAlso, unfortunately, if you trying to create a new Zentyal server with the same name and ip address of a currently dead domain controller, you'll get error telling you that LDAP object already exists.
Making matters worse, there is no where in the Zentyal Web Interface to remove all remnants of a previously added domain controller.
If you go to here:
Zentyal Web Interface > OFFICE > Users and Computers > Manage
You'll see an entry in the tree structure for domain controllers, but uselessly, it doesn't list any of the ones you've previously added. If it did, that would be good place for the developers to provide a way of deleting a domain controller from LDAP. So you could then add it back again with the same name and IP address without receiving "already exists" error.
At this point, I've tried 5 fresh installations attempting to get this additional domain controller back online. This time I'm going to try giving the server a different name and ip address and see if I then have better success joining it.
17
Installation and Upgrades / Re: Removing dead domain controllers
« on: May 26, 2014, 09:32:30 pm »
Zentyal really needs to have a place in their web GUI that allows you remove all remanets of a previously added Domain Controller.
In order to upgrade from 3.3.10 to 3.4.3, I had to completely rebuild my servers and restore their configurations. The "upgrade to 3.4" button fails.
When I tried to restore the configuration of my additional domain controller I got an error that said:
"Restore is only possible if the server is the unique domain controller of the forest"
So far, all my attempts to get this additional domain controller joined again have failed. I'm suspect I'm going to have to give this server a new name and IP address on my local LAN before I will actually succeed in getting it to become a functioning additional domain controller again.
In order to upgrade from 3.3.10 to 3.4.3, I had to completely rebuild my servers and restore their configurations. The "upgrade to 3.4" button fails.
When I tried to restore the configuration of my additional domain controller I got an error that said:
"Restore is only possible if the server is the unique domain controller of the forest"
So far, all my attempts to get this additional domain controller joined again have failed. I'm suspect I'm going to have to give this server a new name and IP address on my local LAN before I will actually succeed in getting it to become a functioning additional domain controller again.
18
Installation and Upgrades / Additional Domain Controller not Providing Fail Over
« on: May 25, 2014, 06:23:59 pm »
I recently upgraded my two zentyal domain controllers to 3.4 from 3.3.10.
I was unable to successfully upgrade by just clicking the "Upgrade to 3.4" button. I upgraded by backing up my configuration and then installing 3.4 onto both servers and then restoring their respective configurations.
Everything works fine when the Additional Domain Controller is turned completely off. But when it is on, some people cannot login to their workstation.
Both of these servers are providing DHCP and DNS. I have two dhcp pools, one on each server.
In 3.3.10, I could turn off either one of these servers and users could function normally as long as one of them is on. With either server on, they could successfully:
1) Log into their workstations
2) Access file shares located on windows servers
3) Received a DHCP issued IP address
4) Access Internet Web Pages
In 3.4.3, if I turn off the Primary Zentyal domain controller (while leaving the additional domain controller on):
1) Some users cannot Login to their workstations, but some can oddly enough.
2) Many users who can login to their workstations cannot access all of the file shares located on windows servers on the LAN
I've confirmed however, that Active Directory replications is occurring, for example
1) If I add a user on the Primary Domain Controller, it promptly appears in the Zentyal Web Interface of the Additional Domain controller
2) If I add a user using the Additional Domain Controller, it promptly appears in the Web Interface of the Primary Domain Controller
3) Same is true when I delete users from either of these servers.
So, the additional domain controller is working to some degree, but when it is turned on it has a negative effect on some user's ability to login to their workstations and those who can have issues accessing certain windows shares.
In 3.3.10, this additional domain controller worked flawlessly as a fail over. I could turn either of my domain controllers off and users would keep accessing every thing they needed to. Since upgrading to 3.4.3, I have to turn this additional domain controller completely off to not experience access problems.
The next thing I'm going to try, is just redoing the additional domain controller from scratch (freshly joining it to the domain).
I'll report back here what that accomplishes.
To me, these services in Zentyal should be priority number one; nothing is more fundamental than having a healthy domain controller and a fail over domain controller (so that the whole LAN doesn't come to a halt if the primary goes down).
I was unable to successfully upgrade by just clicking the "Upgrade to 3.4" button. I upgraded by backing up my configuration and then installing 3.4 onto both servers and then restoring their respective configurations.
Everything works fine when the Additional Domain Controller is turned completely off. But when it is on, some people cannot login to their workstation.
Both of these servers are providing DHCP and DNS. I have two dhcp pools, one on each server.
In 3.3.10, I could turn off either one of these servers and users could function normally as long as one of them is on. With either server on, they could successfully:
1) Log into their workstations
2) Access file shares located on windows servers
3) Received a DHCP issued IP address
4) Access Internet Web Pages
In 3.4.3, if I turn off the Primary Zentyal domain controller (while leaving the additional domain controller on):
1) Some users cannot Login to their workstations, but some can oddly enough.
2) Many users who can login to their workstations cannot access all of the file shares located on windows servers on the LAN
I've confirmed however, that Active Directory replications is occurring, for example
1) If I add a user on the Primary Domain Controller, it promptly appears in the Zentyal Web Interface of the Additional Domain controller
2) If I add a user using the Additional Domain Controller, it promptly appears in the Web Interface of the Primary Domain Controller
3) Same is true when I delete users from either of these servers.
So, the additional domain controller is working to some degree, but when it is turned on it has a negative effect on some user's ability to login to their workstations and those who can have issues accessing certain windows shares.
In 3.3.10, this additional domain controller worked flawlessly as a fail over. I could turn either of my domain controllers off and users would keep accessing every thing they needed to. Since upgrading to 3.4.3, I have to turn this additional domain controller completely off to not experience access problems.
The next thing I'm going to try, is just redoing the additional domain controller from scratch (freshly joining it to the domain).
I'll report back here what that accomplishes.
To me, these services in Zentyal should be priority number one; nothing is more fundamental than having a healthy domain controller and a fail over domain controller (so that the whole LAN doesn't come to a halt if the primary goes down).
19
Installation and Upgrades / Re: HA Experiences
« on: May 24, 2014, 11:10:57 pm »
Since upgrading to 3.4, I'm having the same issues you mention.
I have another dhcp pool on my additional domain controller. When workstations switch pools, I'm having all kinds of issues.
Sometimes the users can't login to their workstation, and sometime they can't access file shares that are on the windows servers.
I can't figure it out. All worked fine in 3.3.10
I have another dhcp pool on my additional domain controller. When workstations switch pools, I'm having all kinds of issues.
Sometimes the users can't login to their workstation, and sometime they can't access file shares that are on the windows servers.
I can't figure it out. All worked fine in 3.3.10
20
Installation and Upgrades / Re: HA Experiences
« on: May 23, 2014, 08:20:19 pm »
What do you mean by HA? High Availability?
21
Installation and Upgrades / Re: Errors after enable HA
« on: May 23, 2014, 07:58:54 pm »
I'm getting these same errors:
Code: [Select]
2014/05/23 12:02:22 INFO> SmbClient.pm:65 EBox::Samba::SmbClient::new - Connection to Samba SMB successful after 4 tries.
2014/05/23 12:02:22 WARN> zentyal.psgi:43 main::__ANON__ - Use of uninitialized value $dir_path in concatenation (.) or string at /usr/share/perl5/HTML/Mason/Tools.pm line 117.
2014/05/23 12:02:22 WARN> zentyal.psgi:43 main::__ANON__ - Use of uninitialized value $dir_path in concatenation (.) or string at /usr/share/perl5/HTML/Mason/Tools.pm line 117.
2014/05/23 12:02:22 WARN> zentyal.psgi:43 main::__ANON__ - Use of uninitialized value $dir_path in concatenation (.) or string at /usr/share/perl5/HTML/Mason/Tools.pm line 117.
22
Installation and Upgrades / Default Domain Policy - 504 Gateway Time-out nginx
« on: May 23, 2014, 06:02:50 pm »
Go here:
Zentyal 3.4.3 Web Interface > Office > Domain > Group Policy Objects > Default Domain Policy
After a very long wait, this what I get:
504 Gateway Time-out
Sometimes, the page actually resolves. When I add a batch script, I will also get this 504 error. I did this 3 times in a row getting this error 3 times. When I finally looked again, the same batch script was added 3 times; apparently, even though nginx was timing out, it was still indeed adding the batch script each time.
Any suggestions?
Zentyal 3.4.3 Web Interface > Office > Domain > Group Policy Objects > Default Domain Policy
After a very long wait, this what I get:
504 Gateway Time-out
Sometimes, the page actually resolves. When I add a batch script, I will also get this 504 error. I did this 3 times in a row getting this error 3 times. When I finally looked again, the same batch script was added 3 times; apparently, even though nginx was timing out, it was still indeed adding the batch script each time.
Any suggestions?
23
Installation and Upgrades / Re: Port Forwarding doesn't work for internal LAN
« on: May 22, 2014, 11:40:29 pm »
Did you take a look at my set up?
https://forum.zentyal.org/index.php/topic,16572.msg66067.html#msg66067
Typically, every port-forwarder I've even done goes from my Zentyal gateway's external public IP to a internal private IP of another server on my LAN.
Honestly, I do not understand your situation and what you are trying to accomplish, but if you read my set up, it might help you.
https://forum.zentyal.org/index.php/topic,16572.msg66067.html#msg66067
Typically, every port-forwarder I've even done goes from my Zentyal gateway's external public IP to a internal private IP of another server on my LAN.
Honestly, I do not understand your situation and what you are trying to accomplish, but if you read my set up, it might help you.
24
Installation and Upgrades / Re: Port Forwarding doesn't work for internal LAN
« on: May 21, 2014, 08:06:56 pm »
So, does your eth0 wan port's public IP dynamically change from time to time?
I've set up port-forwarding, but all my eth0's public IPs never change. Seems like port-forwarding would be more tricky in an environment where the public IP address(es) (of your server) change based on what ever the ISP gives you upon a reboot...
In such an instance, I suspect you would have to create a network object for eth0 based on its mac address (since the IP address itself changes) and then set up port-forwarding from that network object to the internal private IP. This way, no matter what public IP address is issued to eth0, the Zentyal firewall will know that the traffic is to be forward to a specific internal IP/port.
I've set up port-forwarding, but all my eth0's public IPs never change. Seems like port-forwarding would be more tricky in an environment where the public IP address(es) (of your server) change based on what ever the ISP gives you upon a reboot...
In such an instance, I suspect you would have to create a network object for eth0 based on its mac address (since the IP address itself changes) and then set up port-forwarding from that network object to the internal private IP. This way, no matter what public IP address is issued to eth0, the Zentyal firewall will know that the traffic is to be forward to a specific internal IP/port.
25
Installation and Upgrades / Re: Zentyal forum cookies usage
« on: April 25, 2014, 11:04:43 pm »
Same here!
26
Installation and Upgrades / Re: Can't Ping Local computers (by name)
« on: April 25, 2014, 09:21:35 pm »
In another environment, where Zentyal is both primary and secondary domain controller, I have no issue resolving IPs by name. This documentation reveals why:
https://wiki.zentyal.org/wiki/Dynamic_DNS
Apparently, Zentyal DNS and DHCP work together to achieve this.
However, in this environment, where Windows is doing primary AD, DNS, and DHCP, I'm not sure the Zentyal DNS can be informed of such things. I'm not sure how to make it a legitimate DNS that local machines can use for both local and remote hostnames.
https://wiki.zentyal.org/wiki/Dynamic_DNS
Apparently, Zentyal DNS and DHCP work together to achieve this.
However, in this environment, where Windows is doing primary AD, DNS, and DHCP, I'm not sure the Zentyal DNS can be informed of such things. I'm not sure how to make it a legitimate DNS that local machines can use for both local and remote hostnames.
27
Installation and Upgrades / Re: Additional Domain Controller's DNS Not Acting Quite Right
« on: April 25, 2014, 08:53:21 pm »
I've been reading documentation today.
One thing I have never truly understand, in Zentyal, is how the domain controller and DNS work with each other.
I'm using Zentyal 3.4 as an additional domain controller, where the primary domain controller is a Windows Active Directory. This Zentyal server is clearly successful at doing AD authentication (because Pidgin users are consuming Zentyal's Jabber service using their AD credentials).
So, I know that AD is propagating to Zentyal fine.
However, how much does AD tell Zentyal? Does it tell Zentyal the IP addresses of all machines on the LAN? It clearly tells the names of all the computers joined to the domain; that can be seen in the OFFICE > Users and Computers section of the Zentyal web interface.
So having a list of computer names is one step towards being able to provide DNS for those names, but does it also get (from the primary domain controller) the IP addresses currently associated with each computer name?
If so, why doesn't it pass this information along to the INFRASTRUCTURE > DNS (server), so that workstation trying to ping other computers (by name) can resolve those local IP addresses?
So far, in my testing, I've set my laptop to consume DNS from this Zentyal "additional domain controller", but I see no clear and automatic way to make this DNS server aware the IPs of local computer names.
One thing I have never truly understand, in Zentyal, is how the domain controller and DNS work with each other.
I'm using Zentyal 3.4 as an additional domain controller, where the primary domain controller is a Windows Active Directory. This Zentyal server is clearly successful at doing AD authentication (because Pidgin users are consuming Zentyal's Jabber service using their AD credentials).
So, I know that AD is propagating to Zentyal fine.
However, how much does AD tell Zentyal? Does it tell Zentyal the IP addresses of all machines on the LAN? It clearly tells the names of all the computers joined to the domain; that can be seen in the OFFICE > Users and Computers section of the Zentyal web interface.
So having a list of computer names is one step towards being able to provide DNS for those names, but does it also get (from the primary domain controller) the IP addresses currently associated with each computer name?
If so, why doesn't it pass this information along to the INFRASTRUCTURE > DNS (server), so that workstation trying to ping other computers (by name) can resolve those local IP addresses?
So far, in my testing, I've set my laptop to consume DNS from this Zentyal "additional domain controller", but I see no clear and automatic way to make this DNS server aware the IPs of local computer names.
28
Installation and Upgrades / Re: Remote admin Woes
« on: April 25, 2014, 12:11:48 am »
That's weird. Typically I've never seen this issue. Usually, there's no issue with accessing the web panel from another computer on the LAN. You just go to https://192.168.x.x .
Also, ssh always works on the LAN (every time I've install Zentyal), without additional configuration.
Have you make any configuration changes to the Firewall in the Zentyal web interface? Are you should your networking configuration is set up correctly?
What you're describing seem unusual to me.
Also, ssh always works on the LAN (every time I've install Zentyal), without additional configuration.
Have you make any configuration changes to the Firewall in the Zentyal web interface? Are you should your networking configuration is set up correctly?
What you're describing seem unusual to me.
29
Installation and Upgrades / Can't Ping Local computers (by name)
« on: April 24, 2014, 10:53:23 pm »
In an environment where MS Windows is the primary domain controller, I've added Zentyal 3.4 as an additional domain controller.
Also, this same server is successfully providing Jabber service for the LAN, where users are successfully consuming Jabber via Pidgin (where they are logging in successful with their Active Directory user credentials).
For testing, I've manually configured my laptop so that it only uses the Zentyal 3.4 server for DNS. Through Zentyal, my laptop is resolving the IP address of public websites just fine.
However, I can't seem to ping local machines by name, even if I include their fully qualified local domain name.
For example, I have computer named "test" at 192.168.100.5 and its fully qualified domain name would be test.company.local.
If I tried to ping just "test" I get:
If I try to ping test.company.local I get:
This Zentyal Additional Domain controller is located at 192.168.100.3. I'm able to verify that it knows where test.company.local is with this command:
This correctly returns 192.168.100.5.
But yet, if I ping "test" or test.company.local it says it is an unknown host. It's the same for any machine on the LAN. It won't even ping the Zentyal server itself by name.
Why would the dig command prove that this additional domain controller knows the ip of test.company.local, while ping doesn't resolve the host?
Shouldn't LDAP be telling DNS these local machine names and their IPs?
Also, this same server is successfully providing Jabber service for the LAN, where users are successfully consuming Jabber via Pidgin (where they are logging in successful with their Active Directory user credentials).
For testing, I've manually configured my laptop so that it only uses the Zentyal 3.4 server for DNS. Through Zentyal, my laptop is resolving the IP address of public websites just fine.
However, I can't seem to ping local machines by name, even if I include their fully qualified local domain name.
For example, I have computer named "test" at 192.168.100.5 and its fully qualified domain name would be test.company.local.
If I tried to ping just "test" I get:
Code: [Select]
ping: unknown host testIf I try to ping test.company.local I get:
Code: [Select]
ping: unknown host test.company.localThis Zentyal Additional Domain controller is located at 192.168.100.3. I'm able to verify that it knows where test.company.local is with this command:
Code: [Select]
dig @192.168.100.3 test.company.localThis correctly returns 192.168.100.5.
But yet, if I ping "test" or test.company.local it says it is an unknown host. It's the same for any machine on the LAN. It won't even ping the Zentyal server itself by name.
Why would the dig command prove that this additional domain controller knows the ip of test.company.local, while ping doesn't resolve the host?
Shouldn't LDAP be telling DNS these local machine names and their IPs?
30
Installation and Upgrades / Re: Server sizing for AD replacement
« on: April 23, 2014, 09:05:05 pm »
That's funny, I had just +1 you first.