The library 'libhostpolicy.so' required to execute the application was not found - .net-core

During running a dotnet console application I encountered this error. I ran it from a directory that had the .dll and .pdb file copied into it.
What is the cause of this error?

Please check chmod of application folder. When I change folder access mode, problem was resolved. I know it is a little weird but sometimes it can be related to that :)
You have to determine them like that;
sudo chown -R yourusername:yourusername /var/www/
sudo setfacl -R -d -m u:yourusername:rwx,g:yourusername:rwx,o::r /var/www/
If you don't have setfacl command please install ACL package via this command;
sudo apt install acl
If this doesn't work, please use this command when publishing your project(in Package Manager Console of Visual Studio);
dotnet publish -c Release --self-contained --runtime linux-x64 -o out
And it will create "out" folder in your solution directory, you can copy its contain to server.

the deps.json and runtimeconfig.json must also be copied into the directory that the .dll is invoked in. Without these files you will encounter this error.
If you're doing post-build copies, make sure to include these files.

I receive this error when I had compiled the dll using the incorrect runtime.
Running a linux-x64 binary on a linux-arm64 system will show this error and vice versa.

If you are running a solution that has multiple projects, check to make sure the correct startup project is set.

Related

Unable to access dotnet via sudo dotnet in CentOS

I'm using CentOS headless server on azure, & I set up .Net core there.
I'm able to access dotnet --info but unable to access sudo dotnet --info. Provided, I cant access root user.
Looking deeper into sudo here, I found out that, When running sudo, many systems are configured to clear the environment of all non-whitelisted values, and to reset the PATH variable to a sanitized value.
This was actually clearing out the PATH for dotnet, restricting the command to not be executed with sudo.
For the solution, You will find Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin in /etc/sudoers. Removing that line from sudoers file will resolve that issue.
You can access sudoers file by visudo command.

Error "could not delete" with Composer on Vagrant

I have a Vagrant running Linux and I'm trying to install Symfony.
After the command composer create-project symfony/framework-standard-edition ./ "2.5.*" I have the error :
[RuntimeException]
Could not delete ./.git/objects/pack/tmp_idx_llwUKb:
If I try to composer update another project, I always have this kind of error Could not delete
Any ideas?
Edit: For a simple sudo composer update -vvv on another project:
- Installing sonata-project/admin-bundle (dev-master 8a022aa)
Failed to download sonata-project/admin-bundle from source: Could not delete /vagrant/crm_neo/vendor/sonata-project/admin-bundle/.git/objects/pack/tmp_idx_hchQhc:
Now trying to download from dist
- Installing sonata-project/admin-bundle (dev-master 8a022aa)
Failed: [RuntimeException] Could not delete /vagrant/crm_neo/vendor/sonata-project/admin-bundle/.git/objects/pack/tmp_idx_hchQhc:
[RuntimeException]
Could not delete /vagrant/crm_neo/vendor/sonata-project/admin-bundle/.git/o
bjects/pack/tmp_idx_hchQhc:
Exception trace:
() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:193
Composer\Util\Filesystem->unlink() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:151
Composer\Util\Filesystem->removeDirectoryPhp() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:129
Composer\Util\Filesystem->removeDirectory() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:35
Composer\Util\Filesystem->remove() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:80
Composer\Util\Filesystem->emptyDirectory() at phar:///usr/local/bin/composer/src/Composer/Downloader/FileDownloader.php:108
Composer\Downloader\FileDownloader->doDownload() at phar:///usr/local/bin/composer/src/Composer/Downloader/FileDownloader.php:89
Composer\Downloader\FileDownloader->download() at phar:///usr/local/bin/composer/src/Composer/Downloader/ArchiveDownloader.php:35
Composer\Downloader\ArchiveDownloader->download() at phar:///usr/local/bin/composer/src/Composer/Downloader/DownloadManager.php:201
Composer\Downloader\DownloadManager->download() at phar:///usr/local/bin/composer/src/Composer/Installer/LibraryInstaller.php:156
Composer\Installer\LibraryInstaller->installCode() at phar:///usr/local/bin/composer/src/Composer/Installer/LibraryInstaller.php:87
Composer\Installer\LibraryInstaller->install() at phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php:152
Composer\Installer\InstallationManager->install() at phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php:139
Composer\Installer\InstallationManager->execute() at phar:///usr/local/bin/composer/src/Composer/Installer.php:548
Composer\Installer->doInstall() at phar:///usr/local/bin/composer/src/Composer/Installer.php:217
Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/UpdateCommand.php:128
Composer\Command\UpdateCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:889
Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:193
Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:135
Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:124
Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:84
Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:43
require() at /usr/local/bin/composer:15
It happened once to me and it turns out that I was hitting composer's timeout.
You could take the following measures to gain some speed:
Increase composer process-timeout (default 300) (not really needed if the following settings will help you gain speed, but can't hurt)
Set dist as preferred install type.
Enable https protocol for github, which is faster.
~/.composer/config.json
{
"config": {
"process-timeout": 600,
"preferred-install": "dist",
"github-protocols": ["https"]
}
}
If you still have problems after that, you can also clear composer's cache:
rm -rf ~/.composer/cache
I was trying to update project dependencies (using composer update) during a Laravel Framework upgrade exercise in my local Homestead environment (having run vagrant ssh to login as the default "vagrant" user) and none of the previous answers in this thread made any difference to the...
Could not delete /home/vagrant/projects/projectname/vendor/kylekatarnls/update-helper/src/UpdateHelper
...error message I repeatedly encountered.
The only thing that worked for me was to include a composer option as follows:
composer update --no-plugins
Plugins are used to alter or extend the functionality of Composer. The above command disables all installed plugins. Unfortunately, I'm not clear as to why this command worked for me, as I certainly haven't written any plugins myself. All I can conclude is that there was an erroneous Composer plugin installed that was causing this issue.
TL;DR Switch to Docker. It is the industry standard.
I came across this issue and spent quite some time doing research. I've tried every possible option to fix it but none of them worked for me. For me, the bug occurred on GNU/Linux host with Vagrant and VirtualBox provider.
It turns out it's a VirtualBox bug related to the file system layer and race conditions when creating/deleting files. It occurs only for VirtualBox shared folders, not for regular ones. The sad part is that it seems like it's not going to be fixed any time soon.
Some guys reported that they were able to solve the problem using the following tricks:
Downgrading to VirtualBox version 6.0.4.
Using nfs or rsync instead of shared folders.
Patching composer to add some pauses after certain operations.
Disabling plugin usage with --no-plugins option.
But all of this seemed dirty to me. I personally was able to use a workaround suggested on GitHub which is to configure composer to install packages from sources. That's a simple and kind of clean trick which should not have significant negative side effects on your workflow. Try putting the following config into your ~/.config/composer/config.json. Or instead you can edit your composer.json accordingly depending on your needs. Keep in mind that composer.json will override your global config.
{
"config": {
"preferred-install": "source"
}
}
Just got the same issue.
I see the problem in accessing to some local files. In my case target directory was under "root" and I'm not the root user.
Solution
Change permissions/owner of your files/directory.
Redefine owner:
sudo chown myuser:myuser -R /path/to
Maybe there is some lack of permissions for group which you are in.
So, try to run:
sudo chmod g+rwX -R /path/to
Or maybe you may run your command with "sudo" if it works for you (not recommended). :)
P.S. Never use 777. It's not secure.
UPD1
Another thing, you may found out useful to solve the root of the cause, to wrap up your composer binary to run it always behalf a certain user.
$ cat /usr/local/bin/composer
#!/bin/bash
# run composer behalf www-data user
set -o pipefail
set -o errexit
set -o nounset
#set -o xtrace
[[ "${DEBUG:-}" = "true" ]] && set -o xtrace || true
composer_debug=$([[ 'true' != "${COMPOSER_DEBUG:-}" ]] || echo '-vvv' )
sudo -u www-data -- /usr/bin/composer ${composer_debug:-} $#
I had this problem when provisioning the machine, which was bootstrapped to run composer install. I simply exited the VM and ran composer install on the code on my host machine and it worked.
So, if you're facing this problem while running Composer inside the VM, just try running Composer from outside the VM.
Update: As pointed in the comments below, this can pose some problems with different versions of packages being installed owing to the difference in system configurations between the local and Vagrant environments, so exercise appropriate caution while trying this.
We're running into issues also. There are several people who seem to have this issue, a fix has not been provided. For more information you can look into github issues of vagrant-winnfsd.
for my case, I only used the NFS folders type instead of the shared folders and it works:
folders:
- map: ~/code/cs-cart-trial
to: /home/code/cs-cart-trial
type: "nfs"
Just run
sudo chmod -R 777 /folder/path
This will give you write access to the folder you are running composer in.
I know this is an old post but this works so I have to share it.
In my case I was trying composer update but I got
[RuntimeException]
Could not delete .../vendor/bin/php-parse:
Despite I'm using Laravel framework, this question was the first link in Google, so I decided to post an answer.
My solution was to grant ownership for vendor: sudo chown -R $USER:www-data vendor/ and
sudo chown -R $USER:www-data composer.json
Update: my host OS was Ubuntu 16.04.
Having the same issue for Cakephp 4.2.1
Error:
Could not delete /var/www/vendor/cakephp/plugin-installer/src:
Solution:
Based of https://stackoverflow.com/a/63139337/1110760
After trying out several options mentioned above, for me this was the easiest way to solve it.
composer install --prefer-source
The argument --no-plugins worked as well, sort of. It skipped some packages but my localhost seemed to work just fine. This is faster, but it's missing some.
On AWS I got this error while deploying Yii framework project there was this
/var/app/current/vendor/
folder i deleted everything inside it came back to my document root and ran composer update it fetched all the repos again.
In my case , by removing the plugin and re-create the box solve the issue.
For me it caused by composer's timeout. I checked my internet speed and found it dropped to 0.7M which is nearly unusable. After I reconnected the wifi and have my internet connection speed back to normal, the errors are gone.
This has something do to with the synchronization of the folders between host and guest OSes, the folder might be simply temporarily locked from your host machine.
The solution is simply to delete the offending .git folder from your host OS or reboot the machine and launch composer install again.
Ideally each OS has its own dependencies and different binaries, therefore you should isolate your /vendor folder out from the rsync/vagrant folder share, likewise you would do the same with /node_modules on a Nodejs project.
Another thing to check for, Composer needs to run in the context of a directory it has permissions to.
In my case I was trying to issue a create-project command from /var/www, aimed against /var/www/html. /var/www is owned by root, /var/www/html is owned by the same user I executed Composer as (www-data). I got the following error; Could not delete /var/www/html/:
Issued the same Composer command from within /var/www/html itself and it worked perfectly.
To me it helped to install a (new) version via command line from download homepage https://getcomposer.org/download/. I can exclude some file permissions as I was root with chmod +R 0777, though I had virtualbox mounted drive. Anyway since new version worked, would mean it was version, or running a new version via php phar, and the original bin belonged to root
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === '48e3236262b34d30969dca3c37281b3b4bbe3221bda826ac6a9a62d6444cdb0dcd0615698a5cbe587c3f0fe57a54d8f5') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
I have solved the problem by creating a mount :
In /home/vagrant create a folder named vendor
then apply command : mount --bind /home/vagrant/vendor /path/to/source/vendor
It's a bit unrelated with the question, but in my case with Docker. It was failing because Webpack was watching and it didn't allow other files to be deleted.
It worked when I turned off Webpack.
I had same problems trying composer install
- Installing aws/aws-sdk-php (3.218.3): Extracting archive
Install of aws/aws-sdk-php failed
In Filesystem.php line 330:
Could not delete /home/vagrant/code/my-project/vendor/composer/cefa44c2/aws-aws-sdk-php-a1bd217/src:
What I did I comment it out
type: "nfs"
from my homestead.yaml
and make a fresh vagrant provision
I'm using Oracle Virtual box 6.1 on Windows 10.
Turn of Dropbox or other file sync
Best hack i found was to replace the unlink commands with the one below. I am running ubuntu.
sudo nano +219 /usr/share/php/Composer/Util/Filesystem.php
exec("sudo rm -rf $path");
return true;
For Windows users
Wow, I can't believe how long it took me to realize this, and sadly it has happened multiple times, and I'm finally writing this note so that I and others can quickly recover next time.
Just use Windows Explorer to go delete the /vendor/whatever_project_name folder instead of trying to delete it from the Vagrant command line.
Then run composer update to reinstall the dependencies.

Installing Nginx-auth-ldap on Debian

I tried to install Nginx-auth-ldap on my Debian server, but I can't understand how to do it right. I have been looking on https://github.com/kvspb/nginx-auth-ldap/wiki/How-to-install and tried the commands for Linux.
The thing I can't understand is
./configure --add-module=path_to_http_auth_ldap_module
make install
I don't have a folder called configure in the Nginx folder.
Please help me to understand how I will make that work.
The key is one sentence from the linked page that you skipped. The whole instructions say:
cd ~ && git clone https://github.com/kvspb/nginx-auth-ldap.git
in nginx source folder
./configure --add-module=path_to_http_auth_ldap_module
make install
"In nginx source folder" refers to a directory where you would have the source code of nginx. This means you are supposed to re-build nginx with the new module.
What you should do
Download the nginx sources 1
Download the nginx-auth-ldap module
Compile nginx with the module
However, I did not test this, so it is possible that you need additional libraries or sources like the ones for ldap...
Don't install nginx through Debian's package manager. Instead, as jasperado suggested, you'll want to download nginx from source.
You can download the mainline version thus:
wget http://nginx.org/download/nginx-1.9.2.tar.gz && tar xzf nginx-1.9.2.tar.gz
Before you build, you may want to make sure PCRE3 is installed on your system because ngx_http_rewrite_module requires it, and the installer will try to load this module.
When ready, you go into the nginx source directory and then you can do the whole configure and make thing. You might find this article helpful.
For example,
./configure --prefix=/usr/local --with-http_stub_status_module --add-module=$HOME/nginx-auth-ldap
make
sudo make install

Execute project in Qt Creator as root

I have an existing cmake project which i am opening with qtcreator. it is build successfully but the generated executable has to be run as root since it needs a connection to the eth0 interface.
I have no possibility to add these "custom build settings" (it's disabled) and if i try to
ssh-askpass Sudo Password | sudo -S bash /to/my/executable/file
i got an
cannot execute binary file
error.
i don't want to run qtcreator as root. is there any possibility to ask for the root password while running the executable. i am pretty new to cmake and qtcreator.
i'd appreciate any help.
thanx!
Just create a one-line file at the same location than your executable:
Content of launcher.sh:
echo "root password" | sudo -S ./executable
Don't forget to chmod:
sudo chmod a+x launcher.sh // Yeah it's dirty I know!
Then, launch QtCreator normally, open your project, go to the settings and create a new Run configuration. The executable should be your launcher.sh file.
Tick the checkbox "Run in terminal"

meteor bundled application redirects to ssl

My meteor project gets bundled with a script and run with forever. Until now, the process used to work fine but for my last project it does not work.
I setup a clean server with no httpd process running to be sure there is no interference.
there are no errors but when I go to my application on http://dev.sertal.ch:4020 I get redirected to https://dev.sertal.ch
This is the bundle script:
#!/bin/bash
cd /root/projects/tablet-reporting/app
git pull
rm -Rf /opt/sertal/tablet-reporting-test
rm -f /opt/sertal/tablet-reporting-test.tgz
meteor bundle /opt/sertal/tablet-reporting-test.tgz
cd /opt/sertal
tar -xvzf tablet-reporting-test.tgz
mv bundle tablet-reporting-test
cd /opt/sertal/tablet-reporting-test/programs/server/node_modules
rm -Rf fibers
npm install fibers
this is how the app is started:
MONGO_URL="mongodb://localhost:27017/tablet-reporting-test" PORT=4020 ROOT_URL="http://dev.sertal.ch:4020" node tablet-reporting-test/main.js
it says
LISTENING
You might have the force-ssl package installed.
meteor remove force-ssl
Then rebundle and redeploy. Please let know if it doesn't work it might be some proxy thing instead.

Resources