An administration's page is provided as part of the SurgeLDAP in order to let the system administrator to view how SurgeLDAP is doing. On this page it is also possible to setup a sucking feed, to download data from another LDAP server.

To access the administration's page, the HTTP module needs to be setup and working. The module line to enable HTTP is located in your surgeldap.ini file ('c:/winnt' or '/etc' directories). This line should look like this:

module http all 6680 3600 50 web 127.0.0.1,1.2.3.*

You will also need to setup the following ini setting to enable the 'admin.cgi':

admin_cgi_name admin.cgi

This will enable the the following url which will display a login page:

http://my.site.com/admin.cgi

The username/password that you enter here can be any user that has been setup in the user.dat file with ADMIN access rights. An example of a admin user in the user.dat file is show below:

# Manager Login
manager:pass:*:ALL,ADMIN
cn=manager,dc=example,dc=com:pass:*:ALL,HIDDEN20,ADMIN

The password field in this file is automatically encoded using {ssha} encoding method, if any plain text fields are detected.
An example of the manager's page (after entering the password) is shown below:

Once you are logged in you should see a page like the following:

On this page the list of Schemas is on the left, for quick reference and the main server information in the main body of the page. Their are 3 Modules (Replicate, LDAP and HTTP) have been setup and currently working. You will notice that the 'Replicate' module is clickable this will give you more details about the Repicates that have been setup.

Also that their is 1 connection currently setup that is a HTTP connection in this case the admin.cgi display the administration page. On every connection their is a 'close' link that when pressed will force the SurgeLDAP to close the selected connection.

Also On this page is the 'IP Limiting' Rules that have been setup. In this case the 'main' and 'web' have IP limiting setup to help stop site from attacking SurgeLDAP. If you click on the link 'IP Details' this will give you more details about the current list of IP's and stats on each IP.

From this page you can reload and shutdown SurgeLDAP, view the main log and display the memory usage in SurgeLDAP. When you do a reload the all the modules are shutdown including any connections and the surgeldap.ini and schema files are reloaded. As long as their aren't any schema issues SurgeLDAP will restart the modules again. If you shutdown SurgeLDAP you can only restart SurgeLDAP manually, by runing the start script or by reboot your machine.

In the top left are four menu options 'Site Status', 'Site Setup' , 'Sucking Data' and 'User Interface'.

'Site Status' - is page that display all the base SurgeLDAP information as see in the above image.

'User Interface' - This will move you to the user interface allowing you to add, modify, delete and modrn data within SurgeLDAP. You will already be login as the manager when you move to the user interface.

'Site Setup' - display a page like this:

This page shows you the current valid usernames and what they are allowed to connect to. From this page you can also change your user.dat and surgeldap.ini files also.

'Sucking Data' - allows you to import LDIF files or suck data from another LDAP server into SurgeLDAP. This will display a page like the following.

All you need to do is fill in the form and click on the 'Import LDIF File' or 'Suck Records' link. For this to work correctly the base DN object needs to able to be created. So parent object of the 'base dn' will first need to be created for the suck to work. When sucking their are 4 or 5 options which are explained below:

Do Whole Tree - (Default to only 1 level)

If this box is not ticked SurgeLDAP will only download the base dn and all the nodes off this dn. If ticked it will download all the dn that come off the base dn, asumming that all intervening dn's are successfully correctly..

If any problems occurr, remove any successfull records.

If while the data is being downloaded into SurgeDLAP an error occurs, any record that has been already successfully added will be removed.

Replace current records.

If while downloading data the 'DN' entery already exists in SurgeLDAP, it will replace the record with the one on teh remote LDAP server. If an error occurs and you also have 'If any problems occurr, remove any successfull records.' the 'DN' will also be remove. The orginial will NOT be returned. Use this setting with care.

If dn already exists ignore.

While downloaded SurgeLDAP notices that you already have the 'DN' then SurgeLDAP will ignore it and continue.

Do not stop on errors.

Normally if an error occurs durning the sucking SurgeLDAP will stop. Ticking this will make the SurgeLDAP log the error and continue with the download.

SurgeLDAP v1.0k and higher has been updated to provide easier setup and control of your backup and replicating requirements of SurgeLDAP servers. There is an a web administration page that you setup to enable this feature.

To locate this new section you will need to login to your SurgeLDAP administration web page and the main heading 'Site Setup' (top right) there is a 'backup/Replicate Setup' link which will take you to the setup page which looks like this:

Any changes you do to this page and save will update a file called: replicate.ini within your SurgeLDAP workarea.

WARNING: Any changes will NOT take effect untill you restart SurgeLDAP

Backup and Replicating SurgeLDAP allows you to either spread the load and/or give a higher reliability access to your data. Thoughout this section their will be diagrams to help show how to setup SurgeLDAP in each method.

• SurgeLDAP Backup Servers
• SurgeLDAP In Star Formation
• SurgeLDAP Replicating
• SurgeLDAP Replicating with Backup Server with Router
• SurgeLDAP Replicating with Backup Server without Router

Before setting up a backup or replicating servers you must assign each computer a unique tag name. To make it easy to follow the web admin interface is setup to assign them the tag names: main, back, rep1, rep2, rep3, rep4, rep5, rep6

The key to the following diagrams is:

SurgeLDAP Backup Server
	This is one of the easiest to setup and maintain. All data on each server is replicate to the other. Within the admin interface you should setup each machine like the following:
On machine 'main' you would set these settings up: Tag Name:   main Tagname   LDAP Server DN back   backup.server.ip:6630 * Accepted Incomming DN's: *
On machine 'back' you would set these settings up: Tag Name:   back Tagname   LDAP Server DN main   main.server.ip:6630 * Accepted Incomming DN's: *
Since the data is the same on both servers you can either setup a router around the two servers to either give a load balance or fail over situation. If SurgeLDAP server goes down, for what ever reason (power cut, network failure etc..), once the server comes backup it will be updated from the other server.
SurgeLDAP In Star Formation
	This setup is were all data on each server is replicate to every other SurgeLDAP server. This setup is ONLY available in v1.0k or higher. In this case the tag names of the machines ('main, 'backup', 'rep1') are just guide lines. Any of them could be used as the main server. Within the admin interface you should setup each machine like the following:
On machine 'main' you would set these settings up: Tag Name:   main Tagname   LDAP Server DN back   backup.server.ip:6630 * rep1   rep1.server.ip:6630 * Accepted Incomming DN's: *
On machine 'back' you would set these settings up: Tag Name:   back Tagname   LDAP Server DN main   main.server.ip:6630 * rep1   rep1.server.ip:6630 * Accepted Incomming DN's: *
On machine 'rep1' you would set these settings up: Tag Name:   rep1 Tagname   LDAP Server DN main   main.server.ip:6630 * back   backup.server.ip:6630 * Accepted Incomming DN's: *
Since the data is the same on all servers you can either setup a router around the servers to either give a load balance or fail over situation. If SurgeLDAP server goes down, for what ever reason (power cut, network failure etc..), once the server comes backup it will be updated from the other server.
	This can also be extended to more replicate servers to allow larger number of SurgeLDAP servers. The example on the left shows 5 servers setup each mirroring the data to each other. You can also setup a ring of SurgeLDAP server as well, were the data flows around the ring and not across. You can also setup on 2 seperate star networks and setup only 1 link between the two networks to limit transmitting bandwidth over a WAN.
SurgeLDAP Replicating
	In this case all the data on the main server is replicate to other SurgeLDAP servers. This is helps with large system were load balancing is required. The end user never access the main server, they only ever access via any of the Replicate Servers. Wither you setup a router around the Replicate Servers for load balancing or provide IP to selected customers to use it does not matter. Each Replicate Server has a complete copy of database to give quick read access, which are done locally on the Replicate Server. But any time the site request to add/modify/delete data from the server it will pass the command to the Main Server which will then update all the replicate servers.
On machine 'main' you would set these settings up: Tag Name:   main Tagname   LDAP Server DN rep1   rep1.server.ip:6630 * rep2   rep2.server.ip:6630 * rep3   rep3.server.ip:6630 * ...   ... * Accepted Incomming DN's: *
On machine 'Replicate Server' you would add these surgeldap.ini settings: Tag Name:   rep* Accepted Incomming DN's: * Enable Write Though:   yes Main IP:   main.server.ip:389
Any data changes to any of the Replicate Servers will be passed back to the Main Server which will accept the database change (or refuse) and then update all Replicate Servers with any change. If any of the Replicate Servers server goes down, for what ever reason (power cut, network failure etc..), once the server comes backup it will be updated from the Main Server. If the Main Server goes down, then any data changes will be refused until it comes backup. But reading of the data will still be able to be done since using the Replicate Servers which are still up.
SurgeLDAP Replicating with Backup Server with Router
	In this case all the data on the main server is replicate to other SurgeLDAP servers. This is helps with large system were load balancing is required. And also the Main Server is setup with a Backup Server. Were a router is setup to direct the Replicate Servers which server they should talk to. The end user never accesses the Main Server, they only ever access via any of the Replicate Servers. Wither you setup a router around the replicate servers for load balancing or provide IP to selected customers to use it does not matter. Each Replicate Server has a complete copy of database to give quick read access, which are done locally on the Replicate Server. But any time the site request to add/modify/delete data from the server it will pass the command to the Main Server/Backup Sever which will then update all the Replicate Servers.
On machine 'main' you would set these settings up: Tag Name:   main Tagname   LDAP Server DN back   backup.server.ip:6630 * rep1   rep1.server.ip:6630 * rep2   rep2.server.ip:6630 * rep3   rep3.server.ip:6630 * ...   ... * Accepted Incomming DN's: *
On machine 'back' you would set these settings up: Tag Name:   back Tagname   LDAP Server DN main   main.server.ip:6630 * rep1   rep1.server.ip:6630 * rep2   rep2.server.ip:6630 * rep3   rep3.server.ip:6630 * ...   ... * Accepted Incomming DN's: *
On machine 'Replicate Server' you would add these surgeldap.ini settings: Tag Name:   rep* Accepted Incomming DN's: * Enable Write Though:   yes Main IP:   router.ip:389
Any data changes to any of the Replicate Servers will be passed back to the Main Server which will accept the database change (or refuse) and then update all Replicate Servers with any change. If any of the Replicate Servers server goes down, for what ever reason (power cut, network failure etc..), once the server comes backup it will be updated from the Main Server. If the Main Server goes down, then any data changes will be refused until it comes backup. But reading of the data will still be able to be done since using the Replicate Servers which are still up.
SurgeLDAP Replicating with Backup Server without Router
	In this case all the data on the main server is replicate to other SurgeLDAP servers. This is helps with large system were load balancing is required. And also the main server is setup with a backup. The end user never access the Main Server, they only access via any of the Replicate Servers. Wither you setup a router around the Replicate Servers for load balancing or provide IP to selected customers to use it does not matter. Each Replicate Server has a complete copy of database to give quick read access, which are done locally on the Replicate Server. But any time the site request to add/modify/delete data from the server it will pass the command to the Main Server or if not available to the Backup Sever which will then update all the Replicate Servers.
On machine 'main' you would set these settings up: Tag Name:   main Tagname   LDAP Server DN back   backup.server.ip:6630 * rep1   rep1.server.ip:6630 * rep2   rep2.server.ip:6630 * rep3   rep3.server.ip:6630 * ...   ... * Accepted Incomming DN's: *
On machine 'back' you would set these settings up: Tag Name:   back Tagname   LDAP Server DN main   main.server.ip:6630 * rep1   rep1.server.ip:6630 * rep2   rep2.server.ip:6630 * rep3   rep3.server.ip:6630 * ...   ... * Accepted Incomming DN's: *
On machine 'Replicate Server' you would add these surgeldap.ini settings: Tag Name:   rep* Accepted Incomming DN's: * Enable Write Though:   yes Main IP:   main.server.ip:389 Backup IP:   backup.server.ip:389
Any data changes to any of the Replicate Servers will be passed back to the Main Server (or to the Backup Server) which will accept the database change (or refuse) and then update all Replicate Servers with any change. If any of the Replicate Servers server goes down, for what ever reason (power cut, network failure etc..), once the server comes backup it will be updated from the Main Server or the Backup Server. If the Main Server goes down, then any data changes will be refused until it comes backup. But reading of the data will still be able to be done since using the Replicate Servers which are still up.

The default schemas setup in SurgeLDAP have be extended to work with LDAPAuth, which is one external authenation module available in the following Netwins products:

DNews
SurgeMail/DMail
SurgeFTP
Netauth

When setting up LDAPAuth to authenate via SurgeLDAP you will need the setup the following ldapauth.ini file.

# Welcome to Auth ini File.
# Leading # makes line a comment

# Main LDAP connection Information
ldap_host ldap.host
ldap_port 389

ldap_mgr_dn cn=manager,dc=netwin,dc=co,dc=nz
ldap_mgr_pw mpass

# LDAP Main Fields
ldap_search_base dc=netwin,dc=co,dc=nz
ldap_scope LDAP_SCOPE_ONELEVEL

# ldap_objectclass person
# ldap_search_name mail


# LDAP Optional Fields
# --------------------

# SurgeMail/DMail and NetAuth Settings
# ------------------------------------
# info_fields created created
ldap_dmail_forward fwd
info_fields quota quota

# SurgeMail and NetAuth Settings
# ------------------------------
# info_fields pass_question pass_question
# info_fields pass_answer pass_answer

# SurgeMail/DMail and DNews Settings
# ----------------------------------
# info_fields groups groups


# SurgeFTP Settings
# -----------------
# info_fields ftphome ftphome
# info_fields ftpquota ftpquota
# info_fields ftpfromip ftpfromip
# info_fields ftpgid ftpgid
# info_fields ftpuid ftpuid
# info_fields accountstatus accountstatus



# LDAP MUST HAVE fields
must_set_fields sn name
must_set_fields cn name

# NWAuth Password Method
# unix_password true

you should only uncomment the fields that you wish to be stored and used in the LDAP server. If you have any questions you should contact support-surgeldap@netwinsite.com

Nearly all windows installation have 'Microsoft NetMeeting Client' installed.

Start Menu --> Programs --> Acessories --> Communications --> NetMeeting

Since that NetMeeting does not follow standard LDAP protocols, you need to use the program called: 'netmeeting' that SurgeLDAP calls which will translates netmeeting comands into correct LDAP commands.

To setup SurgeLDAP to correctly use this you need to edit 2 SurgeLDAP files:

/usr/local/surgeldap/surgeldap.ini
/usr/local/surgeldap/user.dat

With the following changes:

surgeldap.ini:

user.dat:

The above settings are commented out in a v1.0b standard installation or higher.

NOTE: If you do uncomment the settings ensure that their are no leading spaces.