[kdepim-users] Re: Akonadi + nfs home directories

[Martin (KDE)]

Am Dienstag, 5. April 2011 schrieb Lars Behrens:
> Am 05.04.2011 00:52, schrieb Myrosia Dzikovska:
> > rm -r ~/.local/share/akonadi
> > mkdir -p /tmp/akonadi-USERNAME/akonadi
> > cd ~/.local/share
> > ln -s /tmp/akonadi-USERNAME/akonadi .
> > 
> > Then edit $HOME/.config/akonadi/akonadiserverrc and add
> > 
> > [Connection]
> > SocketDirectory=/tmp/akonadi-USERNAME/
> 
> Thanks for that.
> 
> > This re-directs the socket to /tmp, which is local in our setup
> > Note that this solution is not entirely stable: any change to the
> > resources through the Akonadi GUI breaks the setup, by
> > automatically adding the following line into akonadiserverrc
> > Options="UNIX_SOCKET=/home/USERNAME/mysql.socket"
> > 
> > So any time you configure KDE resources, you have to exit KDE,
> > delete that line from the config file, and restart, or else
> > everything stops working.
> 
> Plus, this has to be done per user, inside their ~ directory. Thus
> probably not our way to go.

This has to be done per script. This should not be that hard to 
implement. Add this script to /etc/kde/env (on fedora - on suse this 
path may be different) it takes car of the correct settings. But don't 
use /tmp for this. These data may be deleted automatically or at every 
reboot. Use /var/tmp.

Adding the UNIX_SOCKET line at every config setup may be a bug. Is 
this overwritten if you set this socket to /var/tmp/akonadi-
USERNAME/mysql.socket?

> 
> > I will probably be forced to move away from kdepim soon, to my
> > regret.
> 
> Likewise here. We were sticking with the last working version of
> SUSE, but it will soon reach eol.
> 
> > Our local support (who are very highly skilled in Linux) are
> > pointing out that lack of support for networked file systems
> > makes it unsuitable for enterprise environment, the resources
> > needed for tech support under circumstances are unreasonable, so
> > all our 500+ users are being strongly encouraged to use
> > Thunderbird, or at least Evolution.
> 
> The sad thing is: Thunderbird (and also Firefox) nowadays are also
> incapable of dealing with network file systems. And let's wait how
> Evolution will develop under Gnome 3...

I think it is due to all the databases laying around. In the old days 
with text based files only this is no problem. Altering database files 
from two (or even more) different host will kill it (sooner or later).

If the db files were used for caching data only they can be moved to 
another place (/var/cache or similar) but modern programs even stores 
configuration data into db files. Configuration have to be stored in 
users home directory. Even if you split cache db from config db the 
problem will remain. If both programs try to store their configuration 
into the db at the same time it may be get corrupt.

> 
> With all the cloud mania these days we are testing the use of
> terminal server atm, maybe this might be the way to go, a bit
> ridiculous though, with a herd of dual core machines being used as
> terminals :-\

But why don't you want to sync the home directory from/to the server 
at login/logout? May be Microsoft is not the reference here, but they 
do it since the beginning (at least can do).

And terminals don't get around the problem. If a user is logged in 
twice the programs will run twice as well. Only if the user gets two 
different views of the same desktop this will work. But I don't know 
of any system implementing this.

I do it with my notebook user. This works very smooth but there are 
still some problems. It would be great to have a pam module taking 
care of this so that I can use encrypted partitions and 
synchronization together. And this will work regardless of desktop 
environment (my solution currently works for KDE only).

Martin

> 
> Cheerz,
> Lars
> _______________________________________________
> KDE PIM users mailing list
> Subscription management:
> https://mail.kde.org/mailman/listinfo/kdepim-users

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users