How To Set Folder Permissions in Elastic Beanstalk Using YAML File? - c#

I have a C# Web API Elastic Beanstalk app which needs a folder outside the deployment directory that the IUSER and IIS_USERS users can write to. I've created a .config file and put this in the top level .ebextensions folder in my project. The contents are below:
commands:
0_mkdir:
command: mkdir C:\\AppFolder\\
1_set_iuser_permissions:
command: cacls C:\\AppFolder\\ /t /e /g IUser:f IIS_Users:f
However while the folder is created successfully the permissions aren't set. If anyone has any idea what I am doing wrong I would be hugely grateful. Big thanks in advance.

In the end I switched to using Json instead of YAML as, despite my YAML being validated by several online YAML testers, AWS still wouldn't accept it. It always had issues with the parameters passed to icacls. I also changed to a folder within the application App_Data folder as setting permissions on any directory external to the application didn't appear to work. So, my final configuration file is as follows:
{
"container_commands": {
"01": {
"command": "icacls \"C:/inetpub/wwwroot/AppName_deploy/App_Data/AppFolder\" /grant DefaultAppPool:(OI)(CI)F"
}
}
}
Hope this helps someone else out.

It looks like you are using invalid .net accounts (unless these are custom accounts you created). That is part of the reason why your permissions are not being set. They should be IUSR or IIS_IUSRS
Furthermore, container_commands executes after your app/server environment has been setup, but before your deployment has started. There is no other way to set permissions on files/folders within your deployment directory other than using a wpp.targets file within visual studio.
The following SO post is a good read using wpp.targets to solve your issue.
Can Web Deploy's setAcl provider be used on a sub-directory?

Place a file 01_fix_permissions.config inside .ebextensions folder.
contents:
files:
"/opt/elasticbeanstalk/hooks/appdeploy/pre/49_change_permissions.sh":
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
sudo chown -R ec2-user:ec2-user tmp/

Related

Internal.Cryptography.CryptoThrowHelper.WindowsCryptographicException

I'm getting the following error message from Visual Studio 2017 on first run of the ASP.NET Core MVC Boilerplate template (DotNet Core) regarding the SSL certificate:
"Internal.Cryptography.CryptoThrowHelper.WindowsCryptographicException
occurred HResult=0x80070002 Message=The system cannot find the
file specified Source=
StackTrace: at
Internal.Cryptography.Pal.CertificatePal.FromBlobOrFile(Byte[]
rawData, String fileName, String password, X509KeyStorageFlags
keyStorageFlags) at
System.Security.Cryptography.X509Certificates.X509Certificate..ctor(String
fileName, String password, X509KeyStorageFlags keyStorageFlags) at
Microsoft.AspNetCore.Hosting.KestrelServerOptionsHttpsExtensions.UseHttps(KestrelServerOptions
options, String fileName, String password) ... "
All other projects using SSL work fine and I've double checked that my localhost certificate is in the Trusted Root Certification Authorities for my local machine and has not expired.
The project is running IISExpress - perhaps it's not looking the correct place? I'm not sure. Any ideas where I'm going wrong?
Recently had this same issue with ASP.NET Core MVC Boilerplate.
Close Visual Studio, right click on it, "Run as Administrator". Worked for me.
One of two problems is going on.
1) The file "exists", but is a symlink. That tends to confuse the underlying system. (The response is to do File.ReadAllBytes and use the byte[] constructor).
2) The file doesn't exist.
To help diagnose #2 you can read Environment.CurrentDirectory to know where "here" is, and use Directory.EnumerateFiles() to see what is present in the directory and why your file doesn't exist.
Of course, if you didn't think you were loading by file, but thought you were loading from a certificate store: Check your configuration and try again... since you're loading from file :).
If you're running in docker, another workaround is doing a copy at startup.
# The copy is done, because wildcard_certificate.pfx is put into the container using docker secrets, which makes it a symlink.
# Reading a certificate as a symlink is not supported at this moment: https://stackoverflow.com/q/43955181/1608705
# After doing a copy, the copied version is not a symlink anymore.
ENTRYPOINT (IF EXIST "c:\certificates\wildcard_certificate.pfx" (copy c:\certificates\wildcard_certificate.pfx c:\app\wildcard_certificate.pfx)) && dotnet webapplication.dll
My application runs in the "c:\app" folder and I put my "to be copied" certificates in "c:\certificates". At startup the certificate is copied to "c:\app", which my environment variables point to.
version: "3.7"
services:
webapplication:
image: ({CONTAINER_REGISTRY})/webapplication:({LABEL})
environment:
- ASPNETCORE_URLS=https://+;http://+
- ASPNETCORE_HTTPS_PORT=443
- ASPNETCORE_Kestrel__Certificates__Default__Path=wildcard_certificate.pfx
secrets:
- source: config_secrets
target: C:/app/appsettings.json
- source: wildcard_certificate_pfx
target: c:\certificates\wildcard_certificate.pfx
Context
I'm setting up a new dotnet 6 mvcapp website and trying to install Certbot generated certificate locally. The settings for kestrel to load certificate from file was simple enough but I keep getting above errors.
Reason for that like someone has mentioned, the fullchain.pem is actually a symlink or in other word: a shortcut.
Solution for that is to right click on the '.pem file' shortcut and select Open file location and then get the actual .pem files.
Updating your settings to point to the actual files and you should be ok.
Wrong path points to live folder
"Certificates": {
"Default": {
"Path": "C:\\Certbot\\live\\{my domain}\\fullchain.pem",
"KeyPath": "C:\\Certbot\\live\\{my domain}\\privkey.pem"
}
}
Correct path points to archive folder
"Certificates": {
"Default": {
"Path": "C:\\Certbot\\archive\\{my domain}\\fullchain.pem",
"KeyPath": "C:\\Certbot\\archive\\{my domain}\\privkey.pem"
}
}
I've just spent all morning fixing this error....
I'm using the Azure.Security.KeyVault.Certificates nuget package to download a certificate from a KeyVault and use it for IdentityServer.
I recently updated nuget packages for our project so refactored a bit of code, deleting the key bit of the jigsaw.
var signingCertificate = certificateClient.DownloadCertificate(new DownloadCertificateOptions(signingCertificateName)
{
KeyStorageFlags = System.Security.Cryptography.X509Certificates.X509KeyStorageFlags.MachineKeySet,
});
X509KeyStorageFlags.MachineKeySet is the secret sauce to getting it running on Azure. I tried several other options before landing back on this one. The annoying thing is, had this in originally before I started refactoring!

UWP AppX Install parameters

I develop client-server UWP app, and I want it to be deployed by sideloading (probably using WinAppDeployCmd or MDM) to the large set of devices by administrator.
But to launch, my application needs to know server IP address, which varies for each customer. I need to pass this setting somehow during deployment by administrator to every device.
Is there a way to set remote application settings? Or pass an XML config file along with appx? Or any other way to add some parameters during installation process?
Unlike e.g. MSI, there's no option to pass along "initial data" with a package for installation. One option is to install the package and then add your 'data' e.g.
Add-AppxPackage foo.appx
appdata = ApplicationDataManager.CreateForPackageFamily(foo_pkg_family)
appdata.LocalSettings.CreateContainer("x").values["y"] = z
Step 1 installs the package, most notably it will register the package for the user. That creates the package's appdata storage resources for the user. You can then use ApplicationDataManager (from a Win32/non-UWP process) to access appdata.
You may find AppData.exe handy. A simple exe using ApplicationDataManager to provide a cmdline interface to AppData. Given this or equivalent you could write a batch file
#ECHO Off
powershell -c Add-AppxPackage foo.appx
appdata.exe SET foopkgfamilyname local\configuration --value=x --type=string --data=y

TeamCity building with MsBuild and NuGet: "Unable to connect to the remote server"

I have setup my TeamCity to build using MsBuild a project that NuGet packages.
During the build, the following command to install packages is issued, but fails:
..\nuget.exe install "C:\TeamCity\buildAgent\work\811b6866c8757c46\Service\packages.config" -source "https://nuget.org/api/v2/" -RequireConsent -solutionDir "..\ "
Error:
Unable to connect to the remote server
with exit code 1.
Interesting to note is that when I run this exact same command on the cmd prompt (inside the same path), it succeeds without any errors.
This is what I have done so far:
Add a new Build Parameter under environment variables in TeamCity: env.EnableNuGetPackageRestore and set it to 'true'
Add a specific path to the package sources (https://nuget.org/api/v2/) inside the ..nuget\nuget.targets file (as described here)
To provide the additinal paths ways to supply a path:
Modified the nuget.config file inside the .nuget folder (..nuget\nuget.config)
Modified the nuget.config for the SYSTEM account that the build runner is executing under (C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\nuget.Config) (as described here)
What I was thinking is that this has something to do with a roaming profile of the System user (that the build agents runs with) because it all works when build agent runs with my account. But the nuget.config is the same for both profiles, and I'm out of ideas. Maybe the System user doesn't have access to the Internet on WinServer2012R2? Maybe it needs additional permissions? Which ones?
Do you have any ideas of what to try?
The error turned out to be the setting for the ISA server we have on our network (the TMG client). By default this isn't set up for new (local) users and therefore the SYSTEM account didn't have access to the web.
I've set this up for a new local user (non-domain, with password that doesn't expire), added it to Administrators group and now it works just fine.

Deployment issue with Azure Emulator

I'm trying to run a local instance of an Azure Worker Role for debugging and testing, but for some reason, my Role will not deploy to the Emulator locally, it is saying, "The compute emulator had a error: Found too many .csdef files.."
The problem is, I checked the project directory, and there is only one csdef file...
I have already built the file as required with CSPack, and my CSRun command looks like this:
csrun.exe /run:C:\ODA
T\WorkerRole\WorkerRole;C:\ODAT\WorkerRole\WorkerRole\
ServiceDefinition.csdef
And this is being ran at the following director: C:\Program Files\Windows Azure Emulator\emulator
Any help is greatly appreciated!
Try using the cscfg file not the csdef and use the .csx directory for the emulator.
csrun C:\ODAT\WorkerRole\WorkerRole.csx C:\ODAT\WorkerRole\WorkerRole.cscfg
If you don't have a .cscfg file you can have cspack create it for you by specifying the /generateConfigurationFile:ServiceConfiguration.cscfg

Enable - SP Feature fails to find the configuration section in the web apps config

I have a site for which i want to activate feature using powershell
When i run the following command :
enable-spfeature FEATURE NAME -url http://URL
it throws an error :value cannot be null parameter name section.
it basically fails to find the configuration section located under the web application configuration.If i create a file with name powershell.exe.config and place it under the
powershell folder ,it works fine but i dont want to touch the system folder.
Is it possible to give powershell a path of config located int some other folder and ask it to use that while activating feature.
I have tried something like this but with no luck
$configpath = "C:\DevTools.exe.config"
[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE",$configpath)
enable-spfeature Feature name -url http://url
Why arn't you putting the configuration information in the web application web.config file?
#Lee Activating the feature from powershell expects the configuration to be under the hosting process which is powershell in this case.
The solution to my problem was to load the configuration at run time as shown below and using windows powershell instead of using sharepoint management shell :
[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE",$configpath)
add-type -path C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Configuration.dll
Add-PSSnapin Microsoft.Sharepoint.PowerShell
enable-spfeature $FeatureName -url http:\\url

Categories