Configuring User Profiles automatically on login - rhel

I am trying to set up user profiles on a rhel 8 system for all users authenticated through a windows domain controller. I have set up the user accounts and configured the rhel 8 box as necessary for the user to login and display its credentials using sssd.conf. My issue begins with how to configure the user profiles without having to interact with the system every time.
The first of the two ways I would like to set up the user profiles is configuring gnome-tweaks. I would like to have the applications menu present and hold the classification banner at the top. I see how to modify these setting opening up gnome-tweaks on each user. I would like to somehow script and save these configurations so that when a new user logs in they all display the same menu items.
This brings me to my second issue. I created a script and added it to /etc/profile.d to copy files and create a folder so that my application menus looks the way I want after the gnome-tweaks changes. However, I'm running into an issue where the script only executes as root. So when root logs in, the script runs fine, the files get copies. When I log in as a different authenticated user, the script doesn't run. Could this have something to do with local vs domain accounts?
The file location I am coping to is the .local/share/applications folder and making a new folder in .config called menus and copying a file there as well. I created a script to do all of this, and I know it works when executed manually as a user, I need assistance on how to automate this executing for every new user.

Related

AppData Folder Redirection manual registry change

We have app data folder redirection group policy in place. We are moving back to local appdata which is currently redirected to network share. Also, the option to move the contents to new location in gpo is enabled. On many occasions the policy is failing due to content move with several reasons (256 character limit, permission issues, etc).
My question is lets say hypothetically disabling the move content to new location in GPO is not an option here. I am changing the registry HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders AppData to %userprofile%\AppData\Roaming on user’s laptop, getting the user to reboot the machine. After that, when user logs in, the GPO will now check the registry which is already set to local, it will not move the contents and successfully complete the policy. I have tested and it works.
This may not be right way of doing it, will there be any issues using this method going forward in terms of user’s app data location ?

Run Linux GUI (X) application as another (system, non-root) user

i am trying to write a custom (GUI) program installer which needs to run as a specific (system) user (without a home directory) - let's call him "installer". Things i have tried or pondered to achieve this in a couple of different ways:
launching the GUI installer app as user "installer" through (gk)su(do) (-u). the problem is that a. these commands are not available on every
distribution or do not behave the same everywhere thanks to internal aliases, and b. the x server does not allow me to connect as a different user without some potentially insecure "xhost +" modification (the old "cannot connect to X server :0.0" problem).
avoiding the X server for the installer routine and create a separate (CLI) binary for the chmod/file copy process, while the GUI runs in current user mode. the problem is that i have to give the password to the (sudo -S) command in clear text, which shows up in the logs, so not a good idea either.
several command combinations of export display, .Xauthority, xhost and anything i could find on stackoverflow, without much success.
so, what do i actually need?
a distro-independent, secure way of launching a GUI application as another (non-root, but "/home"-less system) user
an elegant way of asking the current user for the password of user "installer"
a solution that does not require the current user to enter the root password first, or install the application as root.
i'd be thankful for any thoughts on the matter.
[edit] to clarify, i do not rally want to install new programs into the established linux file structure. The whole setup is this:
I have a main program that will be installed by the root. this program can be extended by modules.
these modules will be installed into a custom folder (let's call it "/progmodules") which is owned by the "installer" user. the goal is to have authorized users to be able to install new modules, without giving them full root access.
any users who want to install new modules should be able to run the installer GUI app, enter the "installer" user password, and then have the files transferred.

Install sample documents to users personal folder upon running application

I have a Basic MSI Project in InstallShield 2012 Spring. This project installs sample documents to the current user's Documents folder (Not the Public Documents folder). When I then log onto another user, I see the application installed, but I do not see those sample documents in the second user's Documents folder (this makes sense). My question is, is there a setting in InstallShield or a way to have the sample documents install for this second user when the second user launches the application? Can launching the application detect that there are files missing in the user's Documents folder and then trigger a repair?
While this is possible, I would not recommend it. The user should control what goes in his or her documents folder; the large number of applications out there that do not respect this is not a good reason for another not to do so. Instead the application should have a way to browse the samples, open them as templates, etc., and then allow the user to save them in the documents folder. If you need them to start in the documents folder, have the application copy them in, and track somewhere that it has done so.
If you do try to automatically install these through Windows Installer, the simplest approach is to make per-user components with key files reflecting the documents location, and ensure your application's shortcuts are advertised. Launching through an advertised shortcut will scan for missing key files, and then auto-repair will install them. But auto-repair is not an experience that users like, and this approach will replace the files if the user deletes them all. (Alternately you can use a per-user registry key as the indicator, which may be less likely to be deleted.)

Setting up users' home directories before they use mintty for the first tme

I'm trying to set up some Cygwin users on a Windows 2008 Server (that I have Administrator privileges on) but I'm struggling to get their home directories set up.
Usually, if a user runs mintty as a login shell when their home directory doesn't exist (e.g. the first time they use "Cygwin Terminal"), the home directory gets created and copies of the the skeleton .bashrc, .profile, etc., from /etc/skel are added to it.
The problem I have is that I want to add some setup to the .bashrc for these users without changing the skeleton version (these settings won't necessarily be applicable for all future users).
I've tried creating the directory and copying the files over manually, but I can't then change the user/group ownership to the intended users - I get a "Permission denied" error from chown.
So, questions:
Why can't I (or how can I) get chown to assign ownership of a directory/file that I own to another user/group?
Is there actually a better way of creating a user's home directory and copying the skeleton files so I can modify them? (I'd like to avoid having to rely on the users doing something themselves to make the changes after they've logged in for the first time)
Answer to question 1: Because I wasn't running the Cygwin shell as an adminstrator (i.e. right-click the Cygwin Terminal in the Start Menu and select "Run As Administrator", then the chown/chgrp both work as expected)
Answer of sorts to question 2: there is no magic involved in setting up the user's home directory for the first time: it's done by the default profile that bash executes if it can't find the user's home directory.

Getting Application Data folder for every user

In my application, every user has its own settings, that I save to a subdirectory in that user's Application Data directory. During uninstall, I want to delete those settings for every user on the computer. How can I do that in Inno Setup?
In other words, I need to get a list that contains Application Data directory for each user (not the shared Application Data directory), so that I can delete the MyAwesomeApp directory from there. Is there some way to do that?
You can't, due to the design of Windows.
The same design stops you accessing the profile folders too.
On top of this, it's accepted best practice to leave the user's data behind in case they want to reinstall it, roaming profiles, etc.
Assuming that your uninstaller runs with administrator priviledges, you can just get the User directory and then enumerate all the user directories there.
You can run an executable from Inno Setup written in whatever language you want. In it you can first get the current user's Application Data directory, using the SHGetSpecialFolderPath function. It would look something like this for Win7:
c:\Users\MyUser\AppData\Roaming\
You can use GetUserName to get the user's name (MyUser in this case), and find the parent directory and split the string to the parent directory "C:\Users\" and "AppData\Roaming\". You can then use FindFirstFile/FindNextFile to enumerate all users directories, and just append the second part "AppData\Roaming\" to them, and check if the file exists. By splitting the directory you get from SHGetSpecialFolderPath you ensure it would work both in XP (which would return something like C:\Documents and Settings\MyUser\Application Data") and in Win7. Basically you just replace MyUser with all the users' names in the string returned by SHGetSpecialFolderPath.
I have no idea if this avoids OS security or if it works with roaming users.

Resources