i think you can change permissions temporarily with chown even if its a mounpoint, and to do it permanently do it in fstab
Without change any permission at the moment, a fast upgrade... hoping that somebody will give me some suggestions... I said that: Well, if SERVER1 is on and I'll reboot SERVER2, it start to work properly again...
I guess you should try to contact the glusterfs developers and ask them for the reson of this behaviour.
Ok summarize it: BEGINNING: SERVER1 and SERVER2 are online The master-master replication is working just fine SERVER1 crash, so SERVER2 is master I still have all the files in /var/vmail (so I have all the emails), but when I try to check an email with roundcube, I can enter in that email, but I can not see all the stored email. I can send emails(it is delivered properly), but the roundcube page is blocked in "sending message". If I close the page and enter again in the webmail, in "sent folder" I can't see nothing. I can not receive emails. If I try to send an email to [email protected] managed by this mailserver and after I'll check the webmail of that email address, I can't see any email. SERVER1 is up again If I'll check [email protected] webmail page on SERVER1, I can find the emails sent when SERVER1 was down. If I'll check [email protected] webmail page on SERVER2, I can not find any email. If I'll reboot SERVER2, it will start to work properly again... To be honest I don't think it's something releated with glusterfs and /var/vmail... I think it's something releated with postfix... (because roundcube read the IMAP server). What do you think? Come on guys, the howto for a fault tolerance mail server is almost ready... Cheers Michele
I shutdown the SERVER1 and I'm checking from Roundcube webpage an email that had some emails stored. I can not see any of them. I had a look to the /var/log/mail.log and this is the situation: Code: Sep 16 09:44:41 srv2 imapd: Connection, ip=[::ffff:127.0.0.1] Sep 16 09:44:41 srv2 imapd: LOGIN, [email protected], ip=[::ffff:127.0.0.1], port=[44032], protocol=IMAP Sep 16 09:44:42 srv2 imapd: LOGOUT, [email protected], ip=[::ffff:127.0.0.1], headers=0, body=0, rcvd=71, sent=652, time=1 It's look like a problem of postfix. Should I change in /etc/postfix/main.cf the word srv1 instead of srv2 for "myhostname" and "mydestination" ???? Thanks Michele
Can you still see the files in /var/vmail on the secondary server on the shell (e.g. with ls) when you shutdown the primary server? If no, its a glusterfs problem.
Yes I can still see the folder /var/vmail with all the email files... If, when SERVER1 is down, I enter in ISPConfig on SERVER2 and I create a new email for example, where will be not a new folder for that email... but when I'll switch on again SERVER1, he will create it... The same with the emails: if I send an email to an email address managed by the mail server when SERVER1 is down, I can not see it from SEVER2, but if I switch on the SERVER1 again, I'll find the email. The SERVER2 will not work properly till, when SERVER1 is on, I'll reboot it... Thanks for your help Michele
I really don't know that is wrong in this configuration... Could somebody give me some suggestions? I'm getting crazy with this mail server... Thank you very much Michele PS: maybe it's better if one of the administrator of the forum change the title of this discussion... maybe the new name could be "master-master replication of the mailserver managed by ISPConfig", so that even for the future could be easier for somebody to find it...
I've changed the title of the thread. Not sure why it does not work. But as it seems that there is a problem with accessing the shared directory, I would really recommend that you consult the glusterfs developers on that, maybe one of them has an idea why there is a problem with accessing the files.
Thanks for your suggestion. I've sent an email to glusterfs users mailing list... I'm waiting an answer... But what I think is: glusterfs just replicare that folder. Once that I can see that files, the job of glusterfs is done. Maybe could be a problem of permissions, but in that case I could solve it with some commands. So I think I've to focus my mind to the problem between ISPConfig and the /var/vmail folder. Do you know where I can find some logs about that? I was reading some logs, but I can't see something wrong. Can you suggest me also some other tests that I could do? Thanks a lot Michele
ISPConfig is not interacting in the mail process at all, so ISPConfig itself can not cause this. The applications in the mail process are: postfix as MTA courier-maildrop as LDA courier pop3 and imap as pop3 and imap server ISPConfig is just a interface to add values into a database and to write some config files. All the daemons involved are logging into the mail log file.
Ok right... So it could be a problem with postfix... Do you know which kind of test I can do to try to solve the problem? Thanks Michele
I mean, where can I check if postfix is looking in /var/vmail for the emails? Where can I see if postfix have a permission problem? Thanks
Hi Till, as I wrote on the page before, if I'm checking the mail.log file of the SERVER2 when SERVER1 is down, I can see just: Code: Sep 16 09:44:41 srv2 imapd: Connection, ip=[::ffff:127.0.0.1] Sep 16 09:44:41 srv2 imapd: LOGIN, [email protected], ip=[::ffff:127.0.0.1], port=[44032], protocol=IMAP Sep 16 09:44:42 srv2 imapd: LOGOUT, [email protected], ip=[::ffff:127.0.0.1], headers=0, body=0, rcvd=71, sent=652, time=1 So it's look like he just check the email and doesn't find nothing... but no errors are written... I also tried to send an email from SERVER2 via telnet... it's look like working but after into mail.log I can not see nothing... Another thing that I thinking now: the 2 servers are not the same machines in terms of hardware and OS (SERVER1 has Centos minimal 5.3, SERVER2 has Ubuntu Server 8.04). Could it be a problem for some reasons? Thanks again Michele
I've to add the results of a new test: this time I tried to switch off the SERVER2 and see what's happen. Well, SERVER1 is working without problems. The only inconsistency is about the mark for unread email, but it's not a big problem). So for the moment, if I don't find the solution, I can use SERVER2 as the primary server and, when it will crash, SERVER1 will substitute it... But of course it's a temporary solution... If somebody have suggestions... they are really wellcome! Thanks Michele
Ok a fast upgrade. Glusterfs is look like working quite good... the only think is that you've to access to /var/vmail folder to upgrade the state. I've found a problem in the master-master replication (I've used this howtohttp://www.howtoforge.com/mysql-5-master-master-replication-fedora-8) Basically when I change something in one of the 2 databases, the database write in a field that I've change something and store also the time and the date, so that it can check to the replication the modify and see what is the new one. Well happens that I reboot both servers at the same time, and unfortunately the databases wrote at the same time 2 different things...to the replication was inconsistent. I think I can solve this problem adding a new table in "monitor_data" and setup it with autoincrement in the first database. After that, I can replicate it and I should avoid this problem. But it could be great if is possible to separate the email part of dbispconfig to all the other functionality of ISPConfig, so that I can replicate just the email part of the database. Somebody think that is it possible??? Thanks Michele
If you add or modify a table definition in the ispconfig database you will loose all database data on the next update. Mysql should take care about that automatically, it uses its binary log for that. Works quite well.
Yes, but a couple of days ago, during my test, happens that they wrote into the same table in "monitor_data" 2 different things and the replication crashed... How can I avoid this problem? Do you think is possible separate the email part of the dbispconfig database, so that i can replicate just that part? Thanks Michele
