It is possible for Sympa to store its user information using a relational database. Currently you can use one of the following RDBMS : MySQL, PostgreSQL, Oracle, Sybase. Interfacing with other RDBMS requires only a few changes in the code, since the API used, DBI (DataBase Interface), has DBD (DataBase Drivers) for many RDBMS.
You need to have a DataBase System installed (not necessarily on the same host as Sympa), and the client libraries for that Database installed on the Sympa host ; provided, of course, that a PERL DBD (DataBase Driver) is available for your chosen RDBMS! Check the DBI Module Availability.
Sympa will use DBI to communicate with the database system and
therefore requires the DBD for your database system. DBI and
DBD::YourDB (Msql-Mysql-modules for MySQL) are distributed as
CPAN modules. Refer to , page
for installation
details of these modules.
The sympa database structure is slightly different from the structure of a subscribers file. A subscribers file is a text file based on paragraphs (similar to the config file) ; each paragraph completely describes a subscriber. If somebody is subscribed to two lists, he/she will appear in both subscribers files.
The DataBase distinguishes information relative to a person (e-mail, real name, password) and his/her subscription options (list concerned, date of subscription, reception option, visibility option). This results in a separation of the data into two tables : the user_table and the subscriber_table, linked by a user/subscriber e-mail.
The create_db script below will create the sympa database for you. You can find it in the script/ directory of the distribution (currently scripts are available for MySQL, PostgreSQL, Oracle and Sybase).
## MySQL Database creation script CREATE DATABASE sympa; ## Connect to DB \r sympa CREATE TABLE user_table ( email_user varchar (100) NOT NULL, gecos_user varchar (150), password_user varchar (40), cookie_delay_user int, lang_user varchar (10), PRIMARY KEY (email_user) ); CREATE TABLE subscriber_table ( list_subscriber varchar (50) NOT NULL, user_subscriber varchar (100) NOT NULL, date_subscriber datetime NOT NULL, update_subscriber datetime, visibility_subscriber varchar (20), reception_subscriber varchar (20), bounce_subscriber varchar (30), comment_subscriber varchar (150), PRIMARY KEY (list_subscriber, user_subscriber), INDEX (user_subscriber,list_subscriber) );
You can execute the script using a simple SQL shell such as mysql or psql.
Example:
# mysql < create_db.mysql
You can import subscribers data into the database from a text file having one entry per line : the first field is an e-mail address, the second (optional) field is the free form name. Fields are spaces-separated.
Example:
## Data to be imported ## email gecos john.steward@some.company.com John - accountant mary.blacksmith@another.company.com Mary - secretary
To import data into the database :
cat /tmp/my_import_file | sympa.pl --import=my_list
(see 3.6, page ).
If a mailing list was previously setup to store subscribers into subscribers file (the default mode in versions older then 2.2b) you can load subscribers data into the sympa database. The simple way is to edit the list configuration using WWSympa (this requires listmaster privileges) and change the data source from file to database ; subscribers data will be loaded into the database at the same time.
If the subscribers file is too big, a timeout may occur with the FastCGI (You can set longer timeout with -idle-timeout option of FastCgiServer Apache configuration directive). Then you should use load_subscribers.pl script.
To store subscriber information in your newly created database, you first need to tell Sympa what kind of database to work with, then you must configure your list to access the database.
You define the database source in sympa.conf : db_type, db_name, db_host, db_user, db_passwd.
If you are interfacing Sympa with an Oracle database, db_name is the SID.
All your lists are now configured to use the database, unless you set list parameter user_data_source to file or include.
Sympa will now extract and store user information for this list using the database instead of the subscribers file. Note however that subscriber information is dumped to subscribers.db.dump at every shutdown, to allow a manual rescue restart (by renaming subscribers.db.dump to subscribers and changing the user_data_source parameter), if ever the database were to become inaccessible.