All the the documentation here assumes that you are running all of the services on a single box, and that you have root access to that box. It is possible, however, to set the system up without having root access, depending on what you have to run, but as each case will be different, and the user rights you have will be different, we are not going to discuss the issues here.
However, as much as possible, SSiS is designed to be modular. The PHP front end does not have to run on the same server as the MySQL server, nor does the LDAP system need to run on the same box as the coldsync system. The system therefore has a certain amount of scalability built in.
A SSiS box should never be placed on a public network. The art of sharing information is at the opposite end of the spectrum to the art of securing information. Certain options, like PDA's have little or no password faciliteis, and world writable FTP areas and Samba shares are services are not something you want on the Internet. Because of this we are assuming that you are using SSiS in a network behind a good firewall (try IP Cop), and you are have a relatively trusted network.
Some services can be locked down better than others, but there is nothing you can do if a disgruntled employee wipes every single contact from his/her PDA, and then syncronisies it before you get a chance to remove the PDA from the authorised list. Let me rephrase that. There is something you can do, it's called backing up!
Apart from loading the two initial scripts, to set up the tables, and set up the default data, there is little to maintain within MySQL. The system uses a single MySQL password which is set to have full rights over just the SSiS database tables, so there will be no need to add users and passwords, but there will be a need to back up the data.
Because the system stores all of it's data in a single set of tables, the only backing up actually required from a data recovery point of view is best done by a mysqldump. There is an example of a backup script in ssis/scripts which I use to back up the database every hour, from 8:00am to 8:00pm, 7 days a week. A single 100Mb IDE ZIP drive has enough capacity to store these 12 x 7 backup files in a sensible directory structure.
In the event of a user accidentally deleing a record, all you have to do is to open up a backup file (is something like less) that predates the mistake, locate the appropriate "insert" line for the missing data, copy it, open up a mysql client session, paste it into the command line and hit enter.
None of the tables are interdependent, so there is no need to worry about data being in more than one table. This is deliberate, as we are working to the lowest common denominator. We are not using MySQL for it's power, but it's flexibility and versatility.
The PHP interface is, at present, very simple. It is not designed to be pretty, but functional. As far as I am aware, nothing we have done needs any special settings. All you need to do to get it to work is to make a symbolic link to the ssis/public_html (or enter a directory entry in httpd.conf). We will implement a .htaccess password system in a future version, with the .htaccess password being stored in the SSiS user table.
We are trying to stay within a standard setup wherever we can, so the LDAP export / update works with a standard schema setup for OpenLDAP. We have decided to use inetOrgPerson, which is a child of organizationalPerson, which in turn is a child of person. We are also going to locate the data at the top of the LDAP tree, in an organizationalUnit called "ssis". The data is mapped as follows:
| MySQL | LDAP | Notes |
| ID | uid | We will use the UID as a way of linking records. |
| Category | businessCategory | |
| LastName | sn | We will combine FirstName and LastName to give both the cn and displayName. |
| FirstName | givenName | |
| Company | o | "Organisation". |
| Work (Phone) | telephoneNumber | We are assuming this is a DDI number (or at least unique to this person). |
| Fax (Phone) | facsimileTelephoneNumber | |
| Home (Phone) | homePhone | |
| Email (Phone) | ||
| Mobile (Phone) | mobile | |
| Main (Phone) | telephoneNumber | We are assuming this is the organisation's main phone number - we may use it in a OU record. |
| Pager (Phone) | pager | |
| Other (Phone) | Until we decide what other really means, it is a bit hard to map! (ISDN, Telex, Teletex...) | |
| Address | postalAddress | At the moment we are not distinguishing between home and work address (see Custom2). |
| City | l | "Location" |
| State | st | |
| ZipCode | postalCode | |
| Country | Here's bizzare. There doesn't appear to be a unique field in the schemas for the country... | |
| Title | title | |
| Custom1 | labeledURI | Provisionally used for Web Site address. |
| Custom2 | We may use this field to distinguish between a work address and a home address. | |
| Custom3 | We may use this field as an Accounts code for project / time management. | |
| Custom4 | ||
| Note | There seems to be no need to map this. | |
| Private | As we are not going to export private records, there isn't much point in try to map this. |