Is there any support for using Microsoft SQL Server 2005 or 2008 as the SQL database for users? Although I would prefer to do it other ways, the company I work for has all of their virtual hosting authentication tied into a SQL Server. Any ideas? Thank you.
Bryan
On Fri, 21 May 2010 09:26:51 -0400 Bryan Vyhmeister <dovecot@bsdjournal.net> articulated:
Is there any support for using Microsoft SQL Server 2005 or 2008 as the SQL database for users? Although I would prefer to do it other ways, the company I work for has all of their virtual hosting authentication tied into a SQL Server. Any ideas? Thank you.
If you can access the Microsoft SQL Server from the machine hosting Dovecot, there should be no problem at all. I have used Microsoft's SQL sever for for several projects and it is an extremely fast and robust piece of software.
Perhaps you could post a clearer picture of exactly what you are attempting to accomplish.
-- Jerry Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
If a person kills their clone is it murder or suicide?
On Fri, May 21, 2010 at 4:10 PM, Jerry <dovecot.user@seibercom.net> wrote:
If you can access the Microsoft SQL Server from the machine hosting Dovecot, there should be no problem at all. I have used Microsoft's SQL sever for for several projects and it is an extremely fast and robust piece of software.
Perhaps you could post a clearer picture of exactly what you are attempting to accomplish.
Sorry. I should have been more specific. I want to use SQL Server for the userdb and password database. I looked through the wiki and did a number of searches but could not find an answer. If I were to use sqlite, mysql, or pgsql, these would be listed under driver = in the dovecot-sql.conf (or whatever you want to name it). How would you go about using SQL Server? There is no sql-server driver as far as I know. I have and am currently using dovecot from passwd files and from sqlite databases so I am pretty familiar with how everything works. I am just not sure how to go about this for SQL Server. Thank you.
Bryan
Bryan Vyhmeister put forth on 5/21/2010 5:00 PM:
On Fri, May 21, 2010 at 4:10 PM, Jerry <dovecot.user@seibercom.net> wrote:
If you can access the Microsoft SQL Server from the machine hosting Dovecot, there should be no problem at all. I have used Microsoft's SQL sever for for several projects and it is an extremely fast and robust piece of software.
Perhaps you could post a clearer picture of exactly what you are attempting to accomplish.
Sorry. I should have been more specific. I want to use SQL Server for the userdb and password database. I looked through the wiki and did a number of searches but could not find an answer. If I were to use sqlite, mysql, or pgsql, these would be listed under driver = in the dovecot-sql.conf (or whatever you want to name it). How would you go about using SQL Server? There is no sql-server driver as far as I know. I have and am currently using dovecot from passwd files and from sqlite databases so I am pretty familiar with how everything works. I am just not sure how to go about this for SQL Server. Thank you.
I think you're SOL Bryan until someone adds mssql driver support to Dovecot. If you are a C veteran and know mssql at a development level, you could possibly grab the source for one of the other sql drivers and rewrite it for mssql duty. The current sql driver source files are:
driver-mysql.c driver-pgsql.c driver-sqlite.c
Source files for stable Dovecot are available here: http://www.dovecot.org/releases/1.2/dovecot-1.2.11.tar.gz
Good luck.
-- Stan
On 05/22/2010 09:03 AM Stan Hoeppner wrote:
I think you're SOL Bryan until someone adds mssql driver support to Dovecot.
I think Timo will add SQL Server support as soon as the company in Redmond has made the GPL/BSD licensed release. ;-)
If you are a C veteran and know mssql at a development level, you could possibly grab the source for one of the other sql drivers and rewrite it for mssql duty. …
In the meantime the FreeTDS <http://www.freetds.org/> libraries may be useful: "FreeTDS is a set of libraries for Unix and Linux that allows your programs to natively talk to Microsoft SQL Server and Sybase databases."
Regards, Pascal
The trapper recommends today: c01dcafe.1014209@localdomain.org
Pascal Volk put forth on 5/22/2010 2:36 AM:
In the meantime the FreeTDS <http://www.freetds.org/> libraries may be useful: "FreeTDS is a set of libraries for Unix and Linux that allows your programs to natively talk to Microsoft SQL Server and Sybase databases."
I should have looked around before posting. FreeTDS might just save Bryan a little development time. :)
Have you ever used FreeTDS Pascal?
-- Stan
On 05/21/10 18:00, Bryan Vyhmeister wrote:
On Fri, May 21, 2010 at 4:10 PM, Jerry<dovecot.user@seibercom.net> wrote:
If you can access the Microsoft SQL Server from the machine hosting Dovecot, there should be no problem at all. I have used Microsoft's SQL sever for for several projects and it is an extremely fast and robust piece of software.
Perhaps you could post a clearer picture of exactly what you are attempting to accomplish.
Sorry. I should have been more specific. I want to use SQL Server for the userdb and password database. I looked through the wiki and did a number of searches but could not find an answer. If I were to use sqlite, mysql, or pgsql, these would be listed under driver = in the dovecot-sql.conf (or whatever you want to name it). How would you go about using SQL Server? There is no sql-server driver as far as I know. I have and am currently using dovecot from passwd files and from sqlite databases so I am pretty familiar with how everything works. I am just not sure how to go about this for SQL Server. Thank you.
Bryan
You can specify arbitrary .NET DLL functions to be executed from triggers in Microsoft SQL Server, and there are .NET libraries to talk to Postgres, so just do it the other way around: run Dovecot off of a local Postgres install, and feed it data from Microsoft SQL every time something changes.
Here's an example assembly.
/* Begin C# */ using System; using System.Net;
public class StoredProcedures {
public static void InsertPostgres(string username, string password) { /* This part is your job. */ }
public static void UpdatePostgres(string username, string password) { /* This part is your job. */ }
public static void DeletePostgres(string username, string password) { /* This part is your job. */ }
} /* End C# */
Now,
Compile the assembly to a DLL. Call it e.g. PostgresStoredProcedures.
Enable CLR code to run within the database:
EXEC sp_configure 'clr enabled', 1; RECONFIGURE;
Make your database trustworthy. This is necessary because it will be accessing external resources.
ALTER DATABASE <exampledb> SET TRUSTWORTHY ON
Add the assembly to your database. This will fail if you haven't set TRUSTWORTHY ON in step 3. Note that this should be done *within* the database, not to SQL server in general (i.e. the master database).
CREATE Assembly PostgresStoredProcedures FROM '<dll_path>' WITH PERMISSION_SET = EXTERNAL_ACCESS
Create the stored procedures within the database. Their signatures should match those of the class methods.
CREATE PROCEDURE InsertPostgres(@username nvarchar(256), @password nvarchar(256)) AS EXTERNAL NAME PostgresStoredProcedures.StoredProcedures.InsertPostgres
CREATE PROCEDURE UpdatePostgres(@username nvarchar(256), @password nvarchar(256)) AS EXTERNAL NAME PostgresStoredProcedures.StoredProcedures.UpdatePostgres
CREATE PROCEDURE DeletePostgres(@username nvarchar(256), @password nvarchar(256)) AS EXTERNAL NAME PostgresStoredProcedures.StoredProcedures.DeletePostgres
You can now execute the stored procedures from within SQL:
exec InsertPostgres 'user@example.com' 'password'
At this point, you just need to define three triggers on your user database -- one for each of insert, update, and delete -- that will execute those stored procedures. This is left as an exercise (but really is trivial once you've made it that far).
On 5/22/10 9:59 PM, Michael Orlitzky wrote:
If you can access the Microsoft SQL Server from the machine hosting Dovecot, there should be no problem at all. I have used Microsoft's SQL sever for for several projects and it is an extremely fast and robust piece of software.
Perhaps you could post a clearer picture of exactly what you are attempting to accomplish.
Sorry. I should have been more specific. I want to use SQL Server for the userdb and password database. I looked through the wiki and did a number of searches but could not find an answer. If I were to use sqlite, mysql, or pgsql, these would be listed under driver = in the dovecot-sql.conf (or whatever you want to name it). How would you go about using SQL Server? There is no sql-server driver as far as I know. I have and am currently using dovecot from passwd files and from sqlite databases so I am pretty familiar with how everything works. I am just not sure how to go about this for SQL Server. Thank you.
You can specify arbitrary .NET DLL functions to be executed from triggers in Microsoft SQL Server, and there are .NET libraries to talk to Postgres, so just do it the other way around: run Dovecot off of a local Postgres install, and feed it data from Microsoft SQL every time something changes. ... [excellent example snipped]
Wow, very nice. This'll give you the benefit of not having your mail system go down every time Windows blows up.
-Dave
-- Dave McGuire Port Charlotte, FL
I appreciate all the responses. I will look into the different options. Thanks again.
Bryan
You can use the old sybase driver on unix to access MSSQL. You'll likely need to patch dovecot to support it beyond that.
~Max
On May 21, 2010, at 6:26 AM, Bryan Vyhmeister wrote:
Is there any support for using Microsoft SQL Server 2005 or 2008 as the SQL database for users? Although I would prefer to do it other ways, the company I work for has all of their virtual hosting authentication tied into a SQL Server. Any ideas? Thank you.
Bryan
You can use the old sybase driver on unix to access MSSQL. You'll likely need to patch dovecot to support it beyond that.
~Max
participants (7)
-
Bryan Vyhmeister
-
Dave McGuire
-
Jerry
-
Maxwell Reid
-
Michael Orlitzky
-
Pascal Volk
-
Stan Hoeppner