Yes Martijn, I definitely understand about the solid reasons not to take on the major task of maintaining something that has no valid purpose in your business.
Let me ask you this … (Because this is the reason behind my interest.) Do you have any clients or CipherMail/Djigzo installations that are either clustered, configured for high availability or possibly replicating configurations/certificates across multiple sites in a live-live configuration? (Not a live-standby.) Since all of our mail goes through your gateway, it does become a single point of failure. I guess we could set a mapping in Postfix to filter out the subject line tag for outgoing and incoming email, but that is a little beyond my capabilities and doesn’t necessary guarantee a CipherMail-based correspondence will be properly processed. Or maybe I am just overcomplicating things too much! I do currently have two CipherMail installations now configured to share the same PostgreSQL database. The original goal was to have a bidirectionally replicated PostgreSQL, but I’ve got to do a lot more testing and that’s at least a half-dozen VM’s down the road (ha ha). MySQL replication is very well done for databases that aren’t extremely active with hundreds of thousands or millions of transactions going on. So that was my thought … Again, I do agree with you that it is a lot of work to maintain something new that is outside of the given standard (ex, CipherMail appliance). And with any modifications to the existing version to support MySQL, the same would have to be done on my end to support MySQL in new versions. But yes I would love to see your notes if you don’t mind. I looked at the datatype conversion tables supplied by MySQL for PostgreSQL migration. That was giving me a little bit of an issue at first, with the datatypes you mentioned. All in all, this was simply my approach to build a HA cluster of CipherMail. I have no problem with PostreSQL, just my poor little brain likes to live in its comfort zone. :-) ~ Laz Peterson Paravis, LLC Ph: 951.319.3240 x201 > On Jul 1, 2015, at 4:49 AM, Martijn Brinkers <[email protected]> wrote: > > On 07/01/2015 10:51 AM, [email protected] wrote: >> Quoting "Laz C. Peterson" <[email protected]>: >> >>> It turned out be a lot more difficult than I had expected. >> >> me2! :/ >> >> May you send me your MaraDB database scheme? > > Supporting MySQL (MariaDB) requires a few minor changes to the code. The > database schema generated by Hibernate (when using the MySQL dialect) > contains a number of statements which MySQL does not like. For example > the database name 'blob' and the column name "index" are reserved names > for MySQL (not for Postgres). Also MySQL does not support long strings > in indexes (see for more info > http://stackoverflow.com/questions/1827063/mysql-error-key-specification-without-a-key-length). > Hibernate also generates TINYBLOB for byte arrays but these are too > small for most binary data (certificates etc.) so these must be changed > to LONGBLOB. Because Hibernate generates a faulty database scheme, all > unit tests that are using databases will fail because the unit tests > will for each test clear the database and generate a fresh database > using the automatically generated database scheme. With MySQL this will > therefore not work because the scheme is not correct. > > Changing the Blob table name, quoting the index column name, replacing > text with varchar and removing some indexes fixes the issues for MySQL. > However this results in a database schema change which then impacts all > the existing CipherMail databases. Another option would be to use a > different database naming strategy only for MySQL but this requires > extensive testing. The tests can be changed to directly import sql > instead of using the Hibernate tools but since there are a lot of tests > it might be a lot of work. > > The backup/restore functionality depends on Postgres so the > backup/restore will not work unless the backup/restore script is > modified to support MySQL. Even though in principle MySQL (and other > databases) can be supported, it's probably not something we are going to > support unless there is a good business reason to do so. Changing the > code to support MySQL is not the biggest problem. Maintaining it is > something else. Testing the gateway on all supported flavours of Linux > is already a lot of work. If we add MySQL to the mix, testing and > maintaining becomes even harder. > > Similar to other products we have a "black-box" version of our gateway. > The virtual appliance is a fully tested solution and what kind of > database it uses should in principle be just an implementation detail. > Because we standardize on a number of products for the virtual appliance > we can maintain a high level of reliability. > > To sum, we have it working on MySQL and in principle it's doable. But > unless there is a good business reason to support MySQL we will not > officially support it. > > I can give you the information on the changes to be made to get it > working with MySQL. > > Kind regards, > > Martijn Brinkers > > > -- > CipherMail email encryption > > Open source email encryption gateway with support for S/MIME, OpenPGP > and PDF messaging. > > https://www.ciphermail.com > > Twitter: http://twitter.com/CipherMail > _______________________________________________ > Users mailing list > [email protected] > https://lists.djigzo.com/lists/listinfo/users _______________________________________________ Users mailing list [email protected] https://lists.djigzo.com/lists/listinfo/users
