I installed RHEL 6.1 with KDE 4.3.4 using LDAP on a PC and have now the problem to specific a user/Profile specific start menu.

I have used already the kmenuedit tool and tailored for one user a specific menu, successfully.
I changed as an example the konsole submenu.
The kmenuedit was generating a user specific file kde-konsole.setup of the edited menu file an stores it in the directory .local/share/applications/. This file was generated from the global menu file kde4-konsole.desktop stored in the directory /usr/share/applications/kde4/.
My question is, where can I store this generated user/profile that it is used when a new generated user is logging in the first time.
Before RHEL 6.x/ KDE 4.x always a mechanism with the /etc/skel directories was used, which seems to be not longer used.

Addtionally I had a look on the kiostool, but that does not longer work correctly for RHEL 6.x/KDE 4.x.

Does anyone have suggestions to solve this problem?

"a mechanism with the /etc/skel directories was used, which seems to be not longer used"

I beg your pardon? Does now systemd also create users and does so in a totally new and exciting way or what?

/etc/skel invocation is not a feature of KDE.
If it's not used, i'd frankly file a bug against in this case fedora (because it's sadly a reasonable assumption, that they scratched that. Unbelievable - but reasonable assumption)

You should be able to export KDEDIRS to inject an interim path (that is looked up after the users KDEHOME but before the "regular" KDEDIR, ie. eg. /usr so that you can place your customized settings there.

see viewtopic.php?f=63&t=61892

Sorry, I expressed me wrong. Obviously the /etc/skel is still used in RHEL 6.x, but I was thinking about a modified Start Menu and the installation of it at the first login of the user.
Thanks a lot for your answer. I was reading the referenced topic.
The referenced topic tells me that I can install/use a modified Start Menu by appending the directory, containing the modified Start Menu files, to the KDE "path". As an example it would look like that; KDEDIR = /home/<user>/.local/share/<modified Start Menu files directory>; /usr
Is that correct?

nearly
export KDEDIRS=/opt/kde-defaults:$KDEDIRS

/opt/kde-defaults would then contain share/applications/... where you can put files to shadow those in /usr/share/applications for all users

If you actually really wanted to act when the user logs in for the very first time (instead when creating the userdir) you'd likely have to bring your own pam module.

You mean I have to use the pam_mkhomedir.so and pass the directory path (where the modified menus are stored) in?

yesno - depends
the pam will create a homedir if there is none (first login or not) and only in that case (no solution for existing users) and the parameter you can pass is the (alternative) path to /etc/skel

if understood you correctly, you'll probably have to write a specific pam (which checks for the presence of specific files on (very first?) login and adds them in case.
However i assume that shadwing the default config files with a customized default behind the user config (you don't want kiosk, ie. enforce certain settings for users, do you?) will do what you want (without having to copy around files)

I would like to install, i.e. creating the user home directory, install the restricted Start Menus and enforve certain settiings for the users (or better groups of users) at the first login of the appropriate user. So, I would not have to check for existing files/directories at the first login, as they will get created/copied at first login time.
You talk about Kiosk, do you mean the Kiosk framework or do you mean the Kiosktool (it does not work on KDE 4.x!?)?

http://techbase.kde.org/KDE_System_Admi ... troduction
Judging from your other thread, you already found that

I however think we've a misunderstanding here - you seem to be interested in kiosk ("restricted Start Menus") what completely rules out installing stuff to the users homedir. Whatever you place there should be writable by the user (nuking the "restricted" part of the term - the user's just gonna remove the restrictions)
The correct approach for this is to rely on kiosk, ie. forbid reading the users configuration (of certain keys) - not forcing a certain config file into the userdir.
http://quickgit.kde.org/?p=kdelibs.git& ... sk&o=plain

To clarify this: do you want to control the users settings or do you want to override the defaults (as installed by the distro packages or implememted in code)?

For the latter one, extend KDEDIRS, for the other (controlling) one, kiosk is the way to go.
/etc/skel is good to get the user some config base that s/he can work on (basic .bashrc) w/o preventing them from altering the settings (cuter prompt or whatever) - this can NOT be used to control some settings because the user can simply delete the file (as long as he's write permissions on the ~/.kde/share/config or ~/.local/share/applications dirs) and then fall through to the global settings

I want to control the user settings (i.e. what is available in the start menu or user cannot start konsole with ALT-F2 ...).
Kiosk seems to be the key, but the Kiosktool does not work for KDE 4.x.
In the case of using the Kiosk framework I would have to control the user via KDE Action Restrictions in the kdeglobals file?
I tried already to control the ALT-F2 with the kdeglobals, but could not get it to work (you answered already on that topic).

There's http://websvn.kde.org/trunk/extragear/s ... kiosktool/
No idea whether porting has ever been finished but AUR (ArchUserRepositary) provides kiosktool-svn requiring kde-workspace 4.0
So i would give that a try (but not rely on it - activity there stopped 2 years ago)