On Mon, Apr 7, 2014 at 1:48 AM, Nikolaos Milas <nmilas@xxxxxx> wrote: > Hello, > > I am trying to create a failover server. > > vmail.example.com is the primary server and vmail1.example.com is the > failover one. Servers are running Postfix / Dovecot / Squirrelmail. > > Incoming mail is received from mailgateway1.example.com and > mailgateway2.example.com and is forwarded to vmail.example.com or to > vmail1.example.com (if the former is unreacheable). > > IMAP is replicated (two-way, near-real-time sync) using Dovecot dsync. > > There will be NO automatic user redirection (via proxy or DNS). In case Why? Why expose the architecture of your system to your users? Why should they care? Why put the burden of remembering what the URI to your failover server is on them? How are they supposed to know what circumstances dictate using the backup server? How are they supposed to know when to start using your primary server again when using your backup? What's to say they won't just keep using your backup for a long time? > vmail.example.com is unreacheable by users, they will be able to login > to vmail1.example.com via webmail (Squirrelmail latest version from ) to > work for the time being, until the primary server is up again. > > I am trying to figure out the best way to replicate Squirrelmail between > the two servers, so that it will behave the right way regardless the > user logs in from vmail or from vmail1. > > In order to do that I am thinking to sync the directories > /var/local/squirrelmail/data and /var/local/squirrelmail/attach between > the two servers. I think that it would suffice to setup an automatic, > near-real-time one-way sync, vmail ----> vmail1, via lsyncd and rsync. > > The only thing I can think it can create a mess it is "security tokens". > If (accessibility to both servers is restored at some point in time and) > a user finds him/her-self logged in at the same time on both servers' > squirrelmail, while the above directories are being synced constantly. > > Due to the fact that pref files are mostly updated to record the > security_tokens, I am examining whether it would be advisable to disable > recording of security_tokens to pref files (on both servers): > > Set $disable_security_tokens to TRUE in config/config.php > > Please advise on this and on other possible issues, and suggest a best > practice. I doubt there are a lot of real-world exploits that rely on CSRF for SquirrelMail right now, but removing a security feature just to work with a questionable system design doesn't seem like a good idea. > Thinking it over again, I believe it will be enough to periodically > (e.g. once a day or every couple of days or even less) sync only the > data dir (vmail ---> vmail1) just to make sure we have updated users' > settings and leave security_tokens enabled. > > I can think of only one scenario which might cause problems: In case > users are using vmail1 (due to inaccessibility to vmail) and during that > time vmail gets live again (while users continue using vmail1) and > happens that a cron job executes during this time and syncs the data dir > (vmail ---> vmail1), could this data directory synchronization cause > application problems to squirrelmail on vmail1 due to the fact that > security token values in pref files on vmail1 will be overwritten (with > those of vmail server)? You do know that you can store user preferences in a database, right? -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donate_paul_lesniewski.php ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ----- squirrelmail-users mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List archives: http://news.gmane.org/gmane.mail.squirrelmail.user List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
