On Thu, Apr 10, 2014 at 8:14 AM, Nikolaos Milas wrote:
> On 7/4/2014 6:39 μμ, Paul Lesniewski wrote:
>
>>> 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?
>
> Thank you for your replies Paul. Regarding prefs replication:
>
> As I understand, even if I store prefs in a db, the same issues will
> arise when replicating the db. For example, if we setup a master-master
> replication on the MySQL squirrelmail DBs of the two servers, the same
> problem occurs.
If you design a sensible MySQL cluster, you won't have any problems.
> The question remains, and I rephrase it: Can Security Token
> synchronization from master to slave (or vice versa) cause application
> problems to squirrelmail, due to the fact that security tokens are
> passed from one server to the other?
Probably not, but it depends on how you use it. You're still far more
likely to run into general usability problems and unwarranted end-user
annoyances with the kind of system you've described.
> In another scenario, if running under a proxy (so that the end user will
> be connected to a working server at any one moment), when the proxy
> switches a user from one server to the other (and the prefs between the
> two are synced via db or file), is squirrelmail (as an application)
> expected to work transparently to the user without application issues
> (i.e. the user has started a session on one server and continues to the
> other - or even (s)he is switched back to the first server again before
> the session ends)?
You can use session-based proxy measures to prevent that kind of
problem. Or you can configure PHP and SquirrelMail to store session
data in your database so it's not tied to any one machine.
--
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
-
squirrelmail-users mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-users@lists.sourceforge.net
List archives: http://news.gmane.org/gmane.mail.squirrelmail.user
List info (subscribe/unsubscribe/change options):
https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
