Question about KDE in a mixed Linux network.

karozans · January 26, 2012, 9:49pm

Hi everyone. Sorry for the long winded post. Skip down to the question if you like.

Background:
I am running several flavors of linux with different versions of KDE on a special cloud type network. On all of the client machines I have to install a special utility that redirects the home directories to a large server farm. I am not an expert on the utility so I don’t know exactly what the utility is doing, but I do know that NO users and NO home directories (except root) actually exist on the local machine hard drive. This utility modifies several things in linux so that you can login via LDAP authentication. The utility also does other stuff with pam_LDAP and NFS and whatnot.

Anyway, when a person logs into a client for the first time ever, Linux/KDE sets up all of their settings in their home directory ~/.kde. This works great.

With the utility that I am using, the entire contents of their home directory is stored on the cloud.

Since I am using different flavors and versions of Linux/KDE, when a user goes to a different client machine that is running a different version of Linux/KDE and logs in, Linux/KDE looks at the ~/.kde that is on the cloud that was created by the other client machine.

When this happens the KDE environment seems to freak out and become unstable.

Question:
So basically my question is…

Is there a way to change the local machine’s KDE variables to GLOBALLY redirect every users ~/.kde directory to a different directory on the local machine hard drive? Keep in mind that no users exist on the local machine. The users home directories and accounts are stored on the cloud servers.

I tried to use the utility Kiosk Admin Tool, but this doesn’t do me any good because the users accounts are not located on the local machine.

I realize that by moving the .kde directory to the local machine, that the user will have to setup their KDE desktop every time they move to a different computer, but unfortunately that is the only solution that I think will work.

I read somewhere that the KDEHOME env variable can only be set when you compile KDE. That seems a little ridiculous to me.

Is there a way to change the .kde after installation or during installation?

Thanks

martin_helm · January 26, 2012, 10:08pm

I am far from being an expert, so take this with a grain of salt if it
is plain stupid.

What about making ~/.kde a symbolic link which is changed depending on
the client who logs in and points to a different ~/.kde-CLIENTNAME or
similar for every client before kde is started?

knurpht · January 26, 2012, 10:41pm

The utility is, I assume, NIS, but that’s not the problem.

Some distro’s, don’t ask me which ones, have reverted from a ~/.kde4 to ~/.kde, that’s already one problem, since f.e. openSUSE and KDE4 expect and store in a ~/.kde4, putting only KDE3 based app settings and data in a ~/.kde.
Then, older versions of KDE4 work in a “KDE4” session, newer work in a “KDE Plasma Workspace” session.
And then, some plasmoids available through all KDE4 versions, are not (completely) backward compatible with older config files, this leading to plasma crashes.

Even in a completely openSUSE based network I’ve met trouble like you describe. And this is not only KDE. One of the machines ran an older version of Thunderbird, this on special request of the user. When the office was closed for a painting job, the user logged on on another machine, Thunderbird converted the mail databases to a newer format, the next day he could not access his mail on “his own” machine. I solved these issues by standardization, i.e. if one machine moves to a new (openSUSE or) KDE version, all others move to. Either all, or none. I mention openSUSE as well, since some users can already go berserk on seeing differences in branding.

What Martin suggest could be a solution, but is not. If f.e. the Kontact suite is used on latest KDE the data and config files will be converted, but when the user comes back on an other machine with an “older” KDE, his Kontact will be completely inaccessible or he will be missing information since his latest actions were stored in a different ~/.kde4.

karozans · January 26, 2012, 10:41pm

Hi Martin, thanks for the reply.

I am not an expert either. I am more of a moderate user.

Your suggestion might work. I suppose I would need a script on the local machine that runs every time the users log in before the ~/.kde directory is probed by KDE.

Does anyone else think that would work?

martin_helm · January 26, 2012, 10:54pm

Am 26.01.2012 22:46, schrieb Knurpht:
> What Martin suggest could be a solution, but is not. If f.e. the
> Kontact suite is used on latest KDE the data and config files will
> be converted, but when the user comes back on an other machine with
> an “older” KDE, his Kontact will be completely inaccessible or he
> will be missing information since his latest actions were stored in a
> different ~/.kde4.
>
I see that my naive idea will result in a mess here, since obviously
many of the hidden directories would need a special treatment.

karozans · January 26, 2012, 10:59pm

Thanks for the reply Knurpht.

Actually the utility is the IBM Global Storage Architecture client. I think NIS is part of it. It is a very proprietary utility, I don’t think it is opensource.

Yea, it seems like this is becoming more of a problem for a lot of people since clouds have become more popular and Linux clients are becoming more user friendly.

Hopefully someone is able to find a solution to this problem and role it out.

I guess I will just need to put suse 12.1 on all of my machines.

Thanks.

knurpht · January 26, 2012, 11:00pm

It won’t. We were probably cross posting. I’ve been working on this for quite a long time, trying a lot. I found this out by putting the latest KDE on one machine using a brandnew test account. Then logged in on a machine with an older KDE version, which resulted in a completely unstable KDE, in fact a non-working desktop; then cleaned out the account, logged in on an older KDE first, no problem, logged out, went to the other machine with the latest KDE on it, logged in, configs and data were converted, only some minor plasma issues, yet a working desktop; then went back to the “older KDE” machine, logged in on the test account, result a broken KDE. Now the network has one openSUSE version for all clients, with the stock KDE. That works.