search

vexim / vexim2

Virtual Exim 2
Other
70 stars 47 forks source link

Updated MySQL setup script #173

Closed rimas-kudelis closed 8 years ago

rimas-kudelis commented 8 years ago

The SQL file itself was created using mysqldump and edited manually afterwards, that's why most of the file differs: mysqldump adds backticks around fields and indents them differently from what we had.

All FK's are currently ON UPDATE CASCADE ON DELETE CASCADE. This might need some tuning, although I'm not exactly sure.

@Udera: would you mind checking this out? I thought it might be nice to introduce these changes before finalizing the upgrade script to 2.3 in #72. On the other hand, these foreign key aren't that necessary and if we decide not to go that way in 2.3, I could make a much smaller alternative patch for point 3 only.

Udera commented 8 years ago

Great idea to remove the requirement to change the uid/gid in the SQL file.

I will try to get an old version of vexim installed on FreeBSD (it's my first time). They have ported a version which might already contain some fixes and then try the migration to vexim 2.3. And then a fresh setup of vexim 2.3.

On 2016-07-30 14:27, Rimas Kudelis wrote:

  • All id columns have been changed to int(10) unsigned not null
    • Foreign keys have been added to all tables referencing other tables
    • Default uid and gid values in domains table have been changed to
  • This alleviates the need to edit this file manually before applying it. From looking at the code, it seems to me that uid and gid are always passed when creating a domain, so this requirement to edit the SQL default value is most likely unnecessary.

The SQL file itself was created using mysqldump and edited manually afterwards, that's why most of the file differs: mysqldump adds backticks around fields and indents them differently from what we had.

All FK's are currently ON UPDATE CASCADE ON DELETE CASCADE. This might need some tuning, although I'm not exactly sure.

@Udera [1]: would you mind checking this out? I thought it might be nice to introduce these changes before finalizing the upgrade script to 2.3 in #72 [2]. On the other hand, these foreign key aren't that necessary and if we decide not to go that way in 2.3, I could make a

much smaller alternative patch for point 3 only.

YOU CAN VIEW, COMMENT ON, OR MERGE THIS PULL REQUEST ONLINE AT:

https://github.com/vexim/vexim2/pull/173

COMMIT SUMMARY

  • Updated MySQL setup script

FILE CHANGES

  • M setup/mysql.sql 3

PATCH LINKS:

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [4], or mute the thread [5].

*

Links:

[1] https://github.com/Udera [2] https://github.com/vexim/vexim2/pull/72 [3] https://github.com/vexim/vexim2/pull/173/files#diff-0 [4] https://github.com/vexim/vexim2/pull/173 [5] https://github.com/notifications/unsubscribe-auth/AGCFFEccq16Wpm4SWjL2MncWS4HDRU6Dks5qa0M8gaJpZM4JYy-t

rimas-kudelis commented 8 years ago

So shall I merge this in right away?

Udera commented 8 years ago

Why not. With too many PR open, it is difficult to test.

On 2016-07-30 15:58, Rimas Kudelis wrote:

So shall I merge this in right away?

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

*

Links:

[1] https://github.com/vexim/vexim2/pull/173#issuecomment-236366688 [2] https://github.com/notifications/unsubscribe-auth/AGCFFP345BW5hDlQ4FODr7ypNSFiRN_Nks5qa1iEgaJpZM4JYy-t

rimas-kudelis commented 8 years ago

@Udera do you think it would be wrong to change the vacation field from varchar(1024) to text? I see no reason for limiting the size of that message, do you?

rimas-kudelis commented 8 years ago

I added some more changes in 8cb216c5e73c6acaa3ac7d12152138e041b8fe10. Among them, dropped the commented out section which allowed to update siteadmin password to a bcrypt-hashed version. SHA512 is supported in FreeBSD since 10.0, and we now enforce password change on first login anyway, so it doesn't seem reasonable for me to bother the user with unnecessary instructions. Instead of that, I think it might be reasonable to have a note in the wiki explaining how to change the password manually via database if SHA512 is not supported for some reason.