I want to install a configuration file from my Wix setup project to C: drive, MyConfig folder.
I have a hard time to specify C:\ in directory, as the character ":" is not permitted in the attribute "Name".
Also I would like the file to be installed conditionally, and in such a way that is NOT removed during uninstall.
After some trial and error I found the answer. I just need to simply add SetDirectory element that will override my C Drive directory, like that.
<PropertyRef Id="ENV_DEPLOY"/>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="CompanyName" Name="!(bind.property.Manufacturer)">
<Directory Id="INSTALLFOLDER" Name="!(bind.property.ProductName)" />
</Directory>
</Directory>
<Directory Id="CDrive" Name="CDrive">
<Directory Id="ConfigDir" Name="MyConfig" />
</Directory>
</Directory>
<SetDirectory Id="CDrive" Value="C:\" />
<ComponentGroup Id="EnvironmentSetup" Directory="ConfigDir" >
<Component Id="currentEnvironment_DEVELOPMENT" Guid="*" Permanent="yes" >
<Condition>ENV_DEPLOY="DEVELOPMENT"</Condition>
<File Id="ConfigFile_DEVELOPMENT" Source="DEVELOPMENT\currentEnvironment.config" />
</Component>
<Component Id="currentEnvironment_PRODUCTION" Guid="*" Permanent="yes" >
<Condition>ENV_DEPLOY="PRODUCTION"</Condition>
<File Id="ConfigFile_PRODUCTION" Source="PRODUCTION\currentEnvironment.config" />
</Component>
</ComponentGroup>
I know you just want an answer, but please consider other solution options. This construct fights the Windows Installer design, and I can guarantee you it will fight back. This fight is not worth it. All of Windows Installer is designed to not allow such unusual (and unnecessary) deployment constructs. There must be alternatives.
Why do you want to access the C:\Config folder? We really need to know to understand what you want to achieve. This is an internal system folder for the Windows Installer engine. It generally stores rollback files for any running MSI installs. I can't think of a single reason to do anything in this folder at all - it is just not safe.
Related
I'm trying to create a setup file (MSI) that runs without admin privileges. for that, I've tried the bellow option.
I've set InstallAlluser property to false as bellow.
Also set InstallAllUsersVisible to false
I've also changed Default location with [AppDataFolder]
After changes above properties It still required Administrator permission to execute MSI file that created using Setup project.
Can you please help me to resolve this issue.
Thanks in Advance.
When you open your MSI with Orca (or equivalent MSI viewer), do you see the "UAC Compliant" check box checked? Sample screenshot here:
You should really use a more flexible and capable MSI tool than the Visual Studio Installer projects. They are good for a few purposes, but lack flexibility and there are numerous other problems: summary of VS Project problems (short form).
Per-User setups considered harmful: Some words of warning against per user setups. Here is one more answer on that.
A simple per-user folder installation in WiX (insert UPPERCASE GUIDs in locations shown with "PUT-GUID-HERE" (2 occurrences) - you can use this GUID generator):
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="PerUserSample" Language="1033" Version="1.0.0.0" Manufacturer="-" UpgradeCode="PUT-GUID-HERE">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perUser" InstallPrivileges="limited" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate EmbedCab="yes" />
<UIRef Id="WixUI_Mondo" />
<Feature Id="ProductFeature" Title="PerUserSample" Level="1" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="AppDataFolder">
<Directory Id="Something" Name="Something">
<Component Feature="ProductFeature" Guid="PUT-GUID-HERE">
<RegistryValue Root="HKCU" Key="Software\[Manufacturer]\[ProductName]\Test"
Name="installed" Type="integer" Value="1" KeyPath="yes"/>
<File Source="C:\Windows\Notepad.exe" />
<RemoveFolder Id="Something" Directory="Something" On="uninstall" />
</Component>
</Directory>
</Directory>
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="PerUserSample" />
</Directory>
</Directory>
</Product>
</Wix>
I just download via svn controle version a CakePHP 2.5.2 app to a test server .
After database configuration, the app does not open the css files located at app/webroot dir (bootstrap, jquery, main.css).
Is the some aditional config parameter ?
I try changing the owner but did not work.
It looks like a mod_rewrite problem.
Make sure you have .htaccess in your DocumentRoot, and your Apache server is configured properly.
Everything is described in detail in the CookBook.
CakePHP 2.x URL Rewriting
Edit: As described in the comments, it was solved by the OP by replacing the Directory definition in the apache vhost configuration file (/etc/apache2/sites-available/default.conf) with the following:
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride FileInfo
Order Allow,Deny
Allow from all
</Directory>
In my Apache configuration, I first deny access to the entire filesystem:
<Directory />
Require all denied
</Directory>
Then, in the configuration for each virtual host, I allow unrestricted access:
<VirtualHost ...>
<Directory /var/www/example.com/>
Require all granted
</Directory>
</VirtualHost>
Or require authenticated access:
<VirtualHost ...>
<Directory /var/www/example.com/>
AuthType Basic
AuthName "example.com"
AuthUserFile htpasswd
Require valid-user
</Directory>
</VirtualHost>
I noticed in the Apache documentation that:
For content that lives in the filesystem, use <Directory> and <Files>. An exception is <Location />, which is an easy way to apply a configuration to the entire server.
And I wondered whether using <Location /> might be a way to require authenticated access for a particular virtual host:
<VirtualHost ...>
<Location />
AuthType Basic
AuthName "example.com"
AuthUserFile htpasswd
Require valid-user
</Location>
</VirtualHost>
But the Apache documentation states that:
<Location> directives should not be used to control access to filesystem locations.
Which led me to wonder whether should not was a recommendation for <Location> directives in general, and whether in certain situations a <Location /> directive in particular may be used as an exception to allow access, or in other words, can the Apache <Location> directive be safely used to configure access to a server?
No. Also from the Apache documentation:
Pay particular attention to the interactions of Location and Directory directives; for instance, even if <Directory /> denies access, a <Location /> directive might overturn it.
My understanding is that because any <Location> directive could potentially overturn any <Directory> directive[1], the least restrictive <Location> directive must not be less restrictive than the most restrictive <Directory> directive across the entire server.
Starting with a sensible <Directory /> default of Require all denied and following the above rule would require any <Location> directive to not be less restrictive than Require all denied, which would of course make it impossible to access the server at all.
Note also that the purpose of the <Location> directive is to configure resources which reside outside of the filesystem.
Bottom line is that for any requests which might touch the filesystem, for any <Location> directives which might apply to any of those requests, the applicable <Location> directives must not include the Require statement.[2]
[1]: For example, using symbolic links.
[2]: It is possible to use filesystem permissions or tools like apparmor to mitigate the security hole opened by including a Require statement in certain <Location> directives, but remember the principle of Defense In Depth.
I've been running Vagrant successfully for about a week. Last night I ran vagrant reload and now I can no longer access my sites.
VirtualBox version 4.2.16
Vagrant version 1.2.7
My Vagrantfile and bootstrap.sh: https://github.com/kriskd/vagrant-settings
Running on Mac
My files live at /vagrant/Sites. At first my "welcome page" which lives at /vagrant/Sites rendered at
http://localhost:4567/
All my projects are folders under Sites. For example, /vagrant/Sites/test won't render index.html. I get the following
Forbidden
You don't have permission to access / on this server.
Apache/2.4.6 (Ubuntu) Server at localhost Port 4567
The vhost looks like:
<VirtualHost *:80>
DocumentRoot "/vagrant/Sites/test"
ServerName test
<Directory "/vagrant/Sites/test">
AllowOverride All
</Directory>
</VirtualHost>
The vhosts are owned by root. My project files are owned by vagrant and chmod'ed 0777.
After no success, I did a full vagrant destroy followed by vagrant up and then the localhost host welcome page stopped rendering as well with the forbidden error.
My hunch is that this is not a vagrant issue at all but solely an Apache configuration glitch. There are a few things I can think to check.
First, obviously, is to confirm that the user that apache is running under has read and execute permissions for the DocumentRoot folder.
Since you mentioned Apache 2.4, there have been changes in the configs from 2.2. Make sure your Allow from all statements now read Require all granted. (If you were still on 2.2, you'd want to make sure they said Allow from all instead of Deny from all.) In either case, you can set this in each <VirtualHost> individually, or set a default in your <Directory /> block of the main httpd.conf file.
Getting more obscure, you could check for selinux, although I'm pretty sure this isn't present in Ubuntu by default. (It is in CentOS, for example.)
This is solved and in the end came down to some very simple things.
Use "Require All granted" instead of "Allow from All"
Put each websites' content at the same level namely /vagrant/Sites/default, /vagrant/Sites/test, /vagrant/Sites/real-site
Add .conf extension to vhost names such as test.conf and real-site.conf
Add AllowOverride All to vhosts to respect sites' .htaccess file (I realize that was in my original post, it got lost as I tried to solve this)
All very basic things that eluded me for a better part of a week. I hope this can help someone else.
I had the same problem when changing the DocumentRoot.
Since you've changed your DocumentRoot to "/any/path/foo/bar", make sure you have the permissions set on "apache2.conf" for this path.
Search for:
<Directory /any/path/foo/bar>
in apache2.conf
And add a new block like this:
<Directory /any/path/foo/bar>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
And my guess is that everything is gonna be fine!
cd /etc/apache2/sites-available
for file in `ls *`; do sed 's/\(.*<\/Directory.*>\)/Require\ all\ granted\n\1/' $file > $file.new;mv $file.new $file ; done;
because it worked before, I would not waste time on fix file by file
We have an installer created using Wix 3.5 for our application. We have users of our application that have existing data in the Common Application Data Folder that we would like to "fix" the permissions on so that our users no longer need to be Administrators on their PCs.
So during the install I added the following section to the Wix Project so that it modifies our folders permissions. This works great for new users, but any existing files in those folders still retain the old ACL and don't allow non-admin users to read/modify them.
<Directory Id="CommonAppDataFolder">
<Directory Id="CommonAppOurCompany" Name="OurCompany">
<Directory Id="MODELLIBPATH" Name="Library">
<Component Id="LibraryUserPermissions" Guid="12BC499B-4601-449F-9515-4C58A8F29603">
<CreateFolder>
<util:PermissionEx GenericRead="yes" GenericWrite="yes" GenericExecute="yes" Delete="yes" DeleteChild="yes" User="Users" Domain="[MachineName]"/>
</CreateFolder>
</Component>
</Directory>
</Directory>
</Directory>
What can I do to recursively apply the new ACL to each file in the folder and its subfolders, without deleting or modifying the files (other than their security settings)?
Normally an installer creates and sets the permissions so that new folders and files will inherit. In your situation you'll need to write a custom action to call cacls or similar to recursive the structure and apply the permissions. There's no built in ability in MSI or WiX to do this to the best of my knowledge.
Folder permission:
<ComponentGroup Id="" Directory="" Source="">
<Component Id="CompID" Guid="*">
<CreateFolder>
<Permission User="Administrators" GenericAll="yes"/>
<Permission User="Users" GenericAll="no" GenericRead="yes" GenericExecute="yes"/>
<---- keep adding required user permission --->
</CreateFolder>
File Permission:
Little tricky. I tried using Cacl.exe in Customaction but did not help. First you need to remove existing file to clear existing ACL then create new file:
<RemoveFile Id="fileID" Name="FileName" On="both" />
<File Id ="fileID" KeyPath="yes">
<Permission User="Administrators" GenericAll="yes"/>
<Permission User="Users" GenericAll="no" GenericRead="yes" GenericExecute="yes" GenericWrite="no"/>
</File>
</Component>
</ComponentGroup>