kemis
asked on
How do I configure gconf to control user profiles in a NIS/NFS environment?
I am trying to get a gconf configuration to work on my NIS/NFS network. Perhaps I am missing something rather simple. I have searched several online documents as well as the man pages for gconf information, and I am confused about certain basic gconf workings. Here is the scenario:
All data and logins are on a single NIS/NFS Master server - seville. All user home folders exist at /export/students on seville, which is exported via NFS. As each person logs in to the NIS domain on a workstation, their home folder on seville is mounted on the local computer via the NFS share. I have searched the existing gconf documentation, and there appears to be certain points that I am missing.
Please consider the following questions:
I do not understand how the gconf configuration editor communicates with each of the clients. In the above scenario, I am using the gconf configuration editor on seville. Keeping in mind that the home directories exist on seville, then exported via nfs to the workstations, should not all gconf communication take place on seville?
When the gconf daemon communicates with clients through its xml database, how is this communication initiated? ...monitored? ...from where to where?
I have created a test user, and deleted all hidden (.*) files from his home folder. When that user next logs in to a workstation X environment, all the necessary hidden files are recreated, as expected. I was hoping that the gconf daemon would take control of the newly created .gonf series of files. No luck. Where do the new .gconf series files come from after they are deleted? Why are they not under the control of the gconf daemon on seville? How do I get the gconf daemon on seville to take control of the home directories on seville? Please note that all this activity is taking place locally, on seville, then exported via NFS as the user logs in to any of several workstations.
I created a local user on seville. I logged in locally to seville as that user, whose home directory is in /home/user on seville. The test user is not a NIS user, nor is his home directory or structure subject to the NIS/NFS routines. I assumed that the gconf daemon was valid for this user. No luck. The user had the default background/environment. I did the above test: deleted all hidden files in the user's home folder. Logged in again: same scenario.
Yes, the gconfd-2 daemon is running on seville.
All data and logins are on a single NIS/NFS Master server - seville. All user home folders exist at /export/students on seville, which is exported via NFS. As each person logs in to the NIS domain on a workstation, their home folder on seville is mounted on the local computer via the NFS share. I have searched the existing gconf documentation, and there appears to be certain points that I am missing.
Please consider the following questions:
I do not understand how the gconf configuration editor communicates with each of the clients. In the above scenario, I am using the gconf configuration editor on seville. Keeping in mind that the home directories exist on seville, then exported via nfs to the workstations, should not all gconf communication take place on seville?
When the gconf daemon communicates with clients through its xml database, how is this communication initiated? ...monitored? ...from where to where?
I have created a test user, and deleted all hidden (.*) files from his home folder. When that user next logs in to a workstation X environment, all the necessary hidden files are recreated, as expected. I was hoping that the gconf daemon would take control of the newly created .gonf series of files. No luck. Where do the new .gconf series files come from after they are deleted? Why are they not under the control of the gconf daemon on seville? How do I get the gconf daemon on seville to take control of the home directories on seville? Please note that all this activity is taking place locally, on seville, then exported via NFS as the user logs in to any of several workstations.
I created a local user on seville. I logged in locally to seville as that user, whose home directory is in /home/user on seville. The test user is not a NIS user, nor is his home directory or structure subject to the NIS/NFS routines. I assumed that the gconf daemon was valid for this user. No luck. The user had the default background/environment. I did the above test: deleted all hidden files in the user's home folder. Logged in again: same scenario.
Yes, the gconfd-2 daemon is running on seville.
ASKER
Thanks, elf_bin. This helps a little, but doesn't get me to where I need to be.
Q: Should all gconf communication take place on seville?
A: No! The gconf daemon exists on the local machine!
Got this. Yes, the daemon is running and working well on the client machine. However, I must assume that when I want to push out a global configuration setting, it's done from the server, seville. Right?
The key-value pairs I can understand. The path, locations, default/mandatory, etc. I can understand. I cannot get to where the communication of a new setting is effective. When I open the gconf settings editor on seville, go to desktop/gnome/background, then right-click and make the setting mandatory, it does not take effect on any client. Why? How does the communication take place between the client and the server? I would assume that global settings are done on the server - seville? Otherwise, I'd be going to each client machine to make the setting changes - not desirable.
Further, if I delete the .gconf and .gconfd folders from a user's home folder, they are recreated upon next login, per expectation. Where do these new .gconf folders come from? The new settings are not the default that I have initiated. Perhaps my question is thus: WHERE ARE GLOBAL SETTINGS INITIATED? WITH WHAT gconf SETTINGS MANAGER DOES THE CLIENT COMMUNICATE AND HOW?
Again, thanks for your input.
Q: Should all gconf communication take place on seville?
A: No! The gconf daemon exists on the local machine!
Got this. Yes, the daemon is running and working well on the client machine. However, I must assume that when I want to push out a global configuration setting, it's done from the server, seville. Right?
The key-value pairs I can understand. The path, locations, default/mandatory, etc. I can understand. I cannot get to where the communication of a new setting is effective. When I open the gconf settings editor on seville, go to desktop/gnome/background, then right-click and make the setting mandatory, it does not take effect on any client. Why? How does the communication take place between the client and the server? I would assume that global settings are done on the server - seville? Otherwise, I'd be going to each client machine to make the setting changes - not desirable.
Further, if I delete the .gconf and .gconfd folders from a user's home folder, they are recreated upon next login, per expectation. Where do these new .gconf folders come from? The new settings are not the default that I have initiated. Perhaps my question is thus: WHERE ARE GLOBAL SETTINGS INITIATED? WITH WHAT gconf SETTINGS MANAGER DOES THE CLIENT COMMUNICATE AND HOW?
Again, thanks for your input.
You seem (at least to me) to be thinking that gconf is somehow the equivalent of GPO in Windows? Perhaps I'm wrong.
Generally, each user has only one copy of gconf running, if a user logs into another machine, the second machine will communicate with the first machine's gconf to ensure there's no lock contention or share issues with the files. GConfd is a CORBA implementation.
Depending on the distribution you're using, in RH, /etc/gconf/2/path is where you configure sources (so you could use one of your NFS sources as the source of a setting - but then what happens when the NFS share breaks in some way?). Well y'know, the easiest way is just to put a whole bunch of gconf-editor statements in the start scripts. Depending on your distribution, you can update the skel files (so new users get these settings) and update the "global" profile files so that everyone gets the new setting.
Does this help?
Generally, each user has only one copy of gconf running, if a user logs into another machine, the second machine will communicate with the first machine's gconf to ensure there's no lock contention or share issues with the files. GConfd is a CORBA implementation.
Depending on the distribution you're using, in RH, /etc/gconf/2/path is where you configure sources (so you could use one of your NFS sources as the source of a setting - but then what happens when the NFS share breaks in some way?). Well y'know, the easiest way is just to put a whole bunch of gconf-editor statements in the start scripts. Depending on your distribution, you can update the skel files (so new users get these settings) and update the "global" profile files so that everyone gets the new setting.
Does this help?
ASKER
Thanks again, elfbin. This begins to help. Yes, I"m accustomed to Windows GPO. As gconf is touted, I am probably hooked to those concepts. I'd like to take a close look at your third paragraph, above:
"Depending on the distribution you're using, in RH, /etc/gconf/2/path is where you configure sources (so you could use one of your NFS sources as the source of a setting - but then what happens when the NFS share breaks in some way?)." -> The NFS shares are working properly - at this point. How/where could this be done? What do I use as the global source within the NFS share?
"Well y'know, the easiest way is just to put a whole bunch of gconf-editor statements in the start scripts. " -> OK, let's consider that I do this. Then when I want to make changes, I have to update all the startup scripts on all the machines? Wow, I thought that's what gconf was to eliminate...???
"Depending on your distribution, you can update the skel files (so new users get these settings) and update the "global" profile files so that everyone gets the new setting." -> The distro is CentOS 5.2, RH equivalent. Updating skel files, no problem. Please consider these two questions, and if I'm out of the ballpark, let me know:
1. Where are the global profile files? When the .gconf directory is automatically generated in a user's home directory, where does it come from? Where are the settings coming from?
2. Is it possible to alter/change a gconf setting from a master controller (anywhere on the network), and have that setting propagated out to all the machines in the NIS domain? I was under the impression that this was/is the glory of gconf...? Am I right or wrong? If it's not possible, I'll amend my approach. If it is possible, how do I do it?
Ultimately, the question is: can I propagate user settings out to the domain from a single location using gconf?
Thanks, have a good weekend. I appreciate your input. I'm locked out of our network until Monday, but I'll respond as soon as I can to anything you post.
"Depending on the distribution you're using, in RH, /etc/gconf/2/path is where you configure sources (so you could use one of your NFS sources as the source of a setting - but then what happens when the NFS share breaks in some way?)." -> The NFS shares are working properly - at this point. How/where could this be done? What do I use as the global source within the NFS share?
"Well y'know, the easiest way is just to put a whole bunch of gconf-editor statements in the start scripts. " -> OK, let's consider that I do this. Then when I want to make changes, I have to update all the startup scripts on all the machines? Wow, I thought that's what gconf was to eliminate...???
"Depending on your distribution, you can update the skel files (so new users get these settings) and update the "global" profile files so that everyone gets the new setting." -> The distro is CentOS 5.2, RH equivalent. Updating skel files, no problem. Please consider these two questions, and if I'm out of the ballpark, let me know:
1. Where are the global profile files? When the .gconf directory is automatically generated in a user's home directory, where does it come from? Where are the settings coming from?
2. Is it possible to alter/change a gconf setting from a master controller (anywhere on the network), and have that setting propagated out to all the machines in the NIS domain? I was under the impression that this was/is the glory of gconf...? Am I right or wrong? If it's not possible, I'll amend my approach. If it is possible, how do I do it?
Ultimately, the question is: can I propagate user settings out to the domain from a single location using gconf?
Thanks, have a good weekend. I appreciate your input. I'm locked out of our network until Monday, but I'll respond as soon as I can to anything you post.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
elf_bin:
Thanks for all this. I get enough of the picture that I can work with it all now.
Thanks for all this. I get enough of the picture that I can work with it all now.
ASKER
Please consider the direct questions that I ask, and address them specifically. I finally got enough of a picture to work with my problem. I tried to post direct specific questions that often were not specifically addressed. Thanks, it helps a lot.
A: No! The gconf daemon exists on the local machine!
Maybe a quick overview of gconf would help. Gconf is implemented as a virtual filesystem (like most of GNOME). So when you ask gconf-editor to do something you provide arguments in a filesystem format, for example to change background I'd do something like:
gconftool-2 -t str --set /desktop/gnome/background/
This will modify $HOME/.gconf/desktop/gnome
<entry name="picture_filename" mtime="1227690001" type="string">
<stringvalue>/usr/share/ba
</entry>
So the "keyword" is "picture_filename", with a modify time of 1227690001, the arguments it accepts are of type string. So we look for the string node in this element, which is indicated by stringvalue (which contains the file name of our picture). Finally we close the element (as XML mandates) with </entry>
You can query gconf settings using something like:
gconftool-2 -R /desktop/gnome
(print out recursively all gnome settings for the desktop).
Gconf looks for each value in a series of storage locations (which gconf calls "configuration sources"). These are specified in a file called /etc/gconf/<version>/path.
xml:readonly:/etc/gconf/gc
include "$(HOME)/.gconf.path"
xml:readwrite:$(HOME)/.gco
xml:readonly:/etc/gconf/gc
If a value is set in the first source, which is read only, then users can't delete that value, and thus can't set a value of their own. These settings become mandatory for all users. The "include" line allows users to insert their own configuration sources into the search path by creating a file in their home directory called .gconf.path. The readwrite source ~/.gconf is where user settings are normally written.
Hope this helps.