I have an old web project that gets rsynced to some Ubuntu box using a little script. I'm planning on using Fabric for my deployment but one thing that always bothered me - and won't be different when using Fabric - is that I never got my file access rights right.
So - I'm rsyncing all that project stuff using a different user then the one who's running the project (and of course needs at read/write access for these files) so I'm ending up with new files being created that can only be accessed by the sync-user and not by the project-user. I guess when I'm using Fabric I could "fix" the rights after syncing - so the project-user can read them - but I'm wondering if I got the problem wrong in the first place.
Maybe this isn't a problem with the scripts or the syncing but just some file access rights problem? Since I don't do Linux all day I guess that's an option. :)
I hope I could clearly state my problem. Any ideas?
Only privileged process can set owner of files it can set user id of files it creates to any other than their own.
I don't think it's reasonable to run rsync privileged from security point of view, so you have to run the synchronization as the project user.
Related
I have to install and configure Microsoft Application Virtualization v5.1 (known as appv 5.1). I have already installed the server side on a WS2012R2 (SQL is on too), the sequencer and client are on W10 and my domain controller is on a WS2016.
I have deployed tiny packages like Python3 and Notepad++ but they have local files stored at AppData and maybe at others folders.
Then I don't know how to store those local files on directories server to avoid file overflow.
My goal is to have a different directory for every users where application files related are stored.
Could you please explain me how to do this ?
Thanks for reading.
You have not grasped quite how the App-V infrastructure and client works yet. What you want is not possible and not something you actually want.
All packages local to one client (be in RDS-server or Win10 machine) are stored in one location and shared. There is however a "cache" that is layered on top of the package for every user. This is stored under AppData and in the registry, per user.
I advice you read up on the basic App-V infrastructure and how App-V works.
Here is one place to get started.
https://www.appvirtguru.com/ has some good resources on design etc.
http://www.tmurgent.com/appv/en/ has info on all versions, and many other resources.
I wanted to setup a computer with a variety of settings which I basicly have to do over and over and over again everytime a new user joins our company or changes the computer and I wanted to know if there was a possible way to configure those with a script like I already did with an information colletor script (batch file) and which now works perfectly fine thanks to this webside.
So since I know that here are some really awesome IT Guys with way more experience then me I would love to so something automatic as the next step to save loads of time by simply running a script to configure things like setting up the screensaver, InternetOptions, removing Apps/Softwarelinks in the Start Menu or perhaps even adding links to the bookmark list in firefox or chrome so the user can just start to work and I got loads of time for other important things.
For now it would already be a help to setup a script for Windows 7 but I think we will move more and more to windows 10 so would it be possible to write something to use on both systems without any big changes?
... configure things like setting up the screensaver, InternetOptions,
removing Apps/Softwarelinks in the Start Menu or perhaps even adding
links to the bookmark list in firefox or chrome so the user can just
start to work and I got loads of time for other important things.
Everything you ask about can be configured in a centralized fashion via Active Directory Group Policy. Check the Group Policy Survival Guide page to get started designing the policy for your organization and users.
Group Policy can be defined using PowerShell and via Group Policy Management Console which is GUI-based.
Note that the above will only work if you are in Active Directory domain. If you are not, you still can use Local Group Policy, but you will have to run a script on every user's computer. I am not sure whether there are native PowerShell cmdlets to manage Local Group Policy, but AFAIK you can do that via Windows Registry or using special tools.
I am using C# with .net 2.0
I am saving my program data in a file under: C:\ProgramData\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data") and then I reinstall the application, and ran it.
The strange thing is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\ProgramData\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin privileges instead of getting:
C:\ProgramData\MyProgramName\fileName.xml
I get
C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml
and indeed there was a file that existed from the previous installation (that I obviously didn't delete, because I didn't know it existed).
So just guide me how could I stop this when apps running with no admin right.
I do not want to create any file automatically in VirtualStore folder. Please discuss all the possible ways to stop this.
First, ask yourself, do this need to be globally saved for all users?
If it doesn't have to be, save the file in Application Data instead, you can get the path with Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), it should always reliably expand to C:\Users\Username\AppData\Roaming\. Do note that this path is unique for each user though.
If you have to, you're out of luck. There is no reliable way to store application data for all users without admin rights (or UAC) on any Windows post-XP that's not extremely hacky, like storing your data in the Public user (which may or may not be possible, I can't check right now).
An approach to solving this is to use the Environment.SpecialFolder.CommonApplicationData location, but with some very important caveats & setup.
CommonApplicationData is
The directory that serves as a common repository for
application-specific data that is used by all users.
This location is described further here and here.
Important requirements and restrictions are given in another SO answer: https://stackoverflow.com/a/22107884/3195477
which said in part:
The recommended solution is for your installer to create a sub
directory of C:\ProgramData for your shared storage. And that sub
directory must be given a permissive ACL by the installation program.
That is what grants the desired access to all standard users.
Otherwise the program running with standard user permission will still not be all equally able to read/write files in that location for all users.
I found a work around for this issue when transferring a very old win32 app to windows 7 & 10. The program wrote to a database on C:\Program Files... but the OS auto changed the path to virtual store. However the database was required globally. By changing compatablilty mode to Windows 95 or XP SP2 and always running as administrator the database was worked on directly in C:\Program Files\etc.
There are security implications for this and the box was removed from all networks and adapters disabled etc.
I have a very simple CRUD app that uses SQL Server Compact (version 3.5) I want to deploy through private deployment vs. the click once installers. I have my installer created and everything works fine, minus one hiccup. The app won't work without Windows LUA elevation (Right clicking and selecting "Run as administrator").
The root cause of this, and this is my guess, is that my sdf data base is sitting inside the Program Files Directory. I think I remember reading somewhere, some time ago, that this directory was read only by default with LUA. Am I remembering correctly?
Also, any work-arounds to this that you've run across? I thought about throwing the sdf in the User's directory, but if another User logs on to the computer, they will not be able to access databases.
Your best bet is to place the file in %ProgramData% - create a folder there, and set the proper ACL via a script. I have some suggestion for manipulating DataDirectory here: http://erikej.blogspot.com/2011/02/using-sql-server-compact-40-with.html (also applies to 3.5)
We have an app that currently installs itself into 'program files\our app', and it puts the internal data files into the common Application Data folder. This means the program is available to any user on that particular PC.
Now we want to make a multi-user version of this program, multiple PCs accessing the program at the same time across the network.
In the bad old days, under XP, we'd just have the user who installed the app 'share' the app directory and off we'd go. In principle, is this still the 'right' way to do it under Vista/Windows 7?
We'd like to do this 'properly' and be as compliant as possible! Is there a recommended 'Microsoft' approach for doing this, or is it largely down to whatever we can get away with and subsequently support (hah!). I've tried researching this on the MS websites but not found anything too helpful at all - it'd be really useful to have a 'if you're trying to install this kind of thing, put it here' type guide for developers!
I think the recommended way to deal with this is one of the following:
Package the application as an MSI and distribute it via group policies to all machines on the domain. Yes, this will install it on every machine but that's usually how it should be done.
Install the application once on a server with terminal services and push a shortcut for running the program on that server to every client machine. You can transparently use single applications on a terminal server. Afaik you can even associate file types with those on the client machines.
Reading between the lines from other resources, and trying to make sense of it all, I've decided that the 'right' place to put the program data for this stuff really will be in the AppData (Roaming) folder, and the right place to put the program binary files themselves really will be the Program Files folder of the host computer, which I can then share out.