An administration's page is provided as part of the SIDVault in order to let the system administrator to view how SIDVault 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 sidvault.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 SIDVault 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 SIDVault. 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 SIDVault, view the main log and display the memory usage in SIDVault. When you do a reload the all the modules are shutdown including any connections and the sidvault.ini and schema files are reloaded. As long as their aren't any schema issues SIDVault will restart the modules again. If you shutdown SIDVault you can only restart SIDVault 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 SIDVault 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 SIDVault. 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 sidvault.ini files also.

'Sucking Data' - allows you to import LDIF files or suck data from another LDAP server into SIDVault. 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 SIDVault 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 SIDVault, 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 SIDVault notices that you already have the 'DN' then SIDVault will ignore it and continue.

Do not stop on errors.

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

SIDVault v1.0k and higher has been updated to provide easier setup and control of your backup and replicating requirements of SIDVault 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 SIDVault 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 SIDVault workarea.

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

Backup and Replicating SIDVault 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 SIDVault in each method.

• SIDVault Backup Servers
• SIDVault In Star Formation
• SIDVault Replicating
• SIDVault Replicating with Backup Server with Router
• SIDVault 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:

SIDVault 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 SIDVault 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.
SIDVault In Star Formation
	This setup is were all data on each server is replicate to every other SIDVault 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 SIDVault 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 SIDVault servers. The example on the left shows 5 servers setup each mirroring the data to each other. You can also setup a ring of SIDVault 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.
SIDVault Replicating
	In this case all the data on the main server is replicate to other SIDVault 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 sidvault.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.
SIDVault Replicating with Backup Server with Router
	In this case all the data on the main server is replicate to other SIDVault 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 sidvault.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.
SIDVault Replicating with Backup Server without Router
	In this case all the data on the main server is replicate to other SIDVault 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 sidvault.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 SIDVault have be extended to work with LDAPAuth, which is one external authenation module available in the following Netwins products:

DNews
SurgeMail/DMail
SurgeFTP
Netauth

See the Step-by-Step Guide on how to setup SurgeMail to use SIDVault, if you wish to upgrade a current SurgeMail to use SIDVault, or you can download and install our Mail Server installation that includes SurgeMail/LDAPAuth and SIDVault already setup and working with 1 easy to install solution.

If you have any questions you should contact sidvault@alphacentauri.co.nz

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 SIDVault calls which will translates netmeeting comands into correct LDAP commands.

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

/usr/local/sidvault/sidvault.ini
/usr/local/sidvault/user.dat

With the following changes:

sidvault.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.