| Multiple front-end architecture [message #123048] |
Thu, 23 July 2015 18:58  |
CJE Networx
Messages: 5
Registered: May 2015
Location: Richmond, VA
|
|
|
|
Hi,
I've seen mention of a diagram for multiple front end servers. I'm interested in a scenario deploying the primary front-end in a separate DMZ and the rest of the components in a lower security area. I'm also curious about how client connectivity works with KOFF and multiple backend/frontend servers. I would have some users connecting from the WAN, going through the DMZ and then connecting to a backend server in the lower security area. There would also be users connecting from the LAN - now, would they hit the main FE server in the DMZ and then be handed off to a second FE server on the LAN?
Also, unrelated to be above: Is there a plan in place for OS upgrades or component server replacement in the multi-server setup?
[Updated on: Thu, 23 July 2015 20:36] Report message to a moderator |
|
|
|
| Re: Multiple front-end architecture [message #123108 is a reply to message #123048] |
Tue, 28 July 2015 01:02  |
nate.keegan
Messages: 46
Registered: June 2015
|
|
|
|
I can't speak to the DMZ setup exactly although I think you could do this using a load balancer if the LB masked the source meaning the Kerio systems only see the LB interface on their network talking to them.
It would depend on if the back-end Kerio Multi-Server systems see/care about the service name/VIP name you provide when setting up the Puppet role (enter the internet hostname (public FQDN for frontend)) or not.
For the second point the documentation says that once an update is available the process works like this:
Find the 64-bit Debian download for the version you are looking to move to
On the Puppet server
cd /var/packages/pool/non-free
wget <the url of the new package>
Once you run the command below all Multi-Server systems will update within 30 minutes
update-archive
As far as replacing a role what I have worked out so far is the following which assumes that the host needing replacement will have the same hostname as the host it replaces:
Clear the DHCP server lease for the target hostname
Setup a new VMDK file for the new server
On the Puppet server run 'puppet cert clean <fqhn of target host>'
Boot the new VMDK, choose the appropriate role, assign same host name as system you are replacing
Configure new VM, restore backup, etc
|
|
|
|
| Re: Multiple front-end architecture [message #123109 is a reply to message #123108] |
Tue, 28 July 2015 02:11 |
CJE Networx
Messages: 5
Registered: May 2015
Location: Richmond, VA
|
|
|
|
|
Thanks. I ended up abandoning multiserver for the time being. My brick wall was too little time to work out how to get it properly hooked to AD for accounts with the directory server. Do you just bail on the directory server and hook each backend to AD as you would in a single server environment?
|
|
|
|
| Re: Multiple front-end architecture [message #123132 is a reply to message #123109] |
Tue, 28 July 2015 17:05 |
nate.keegan
Messages: 46
Registered: June 2015
|
|
|
|
Multi-Server uses its own directory/LDAP server for some item.
I dumped the DIT from it to make sure it could be backed up, not much in there:
dc=foo, dc=org
ou=Users, dc=foo,dc=org
ou=Groups, dc=foo, dc=org
cn=admin, dc=foo, dc=org
dc=foo, dc=org
No actual entries beyond the admin user which means I'm unable to dump the whole tree without using a more elaborate slapcat command with authentication or the in-skin directory server is used if you do not hook up to an AD directory.
With an AD directory you can hook up to it using the AD connector just like you would with a single Kerio Connect installation although the process is slightly more involved.
For example, on Multi-Server you go to your first Back-End server and under the Configuration widget > Domains right click for Add > Distributed Domain, enter the email domain on the General tab, select the Directory Service tab, and enter your AD options.
Once that is done you would add the Distributed Domain to each Back-End Server via the same process (Configuration widget > Domains > Add > Distributed Domain > choose from list and confirm).
The same is true for setting up Kerberos authentication on each Back-End Server - same process as a single Kerio Connection installation to allow single-sign on for Windows thick clients - but on each Back-End Server.
The role of the in-skin directory server and whether or not AD/Kerberos were used in Multi-Server was not clear to me before we started installing it in a lab several times.
|
|
|
|
Members
Search
Help
Register
Login
Home
