I am using Dokku on DigitalOcean to deploy my_app.
My app has a dependency which points to a private repo git#github.com:my_org/my_app.git.
Step 10 : RUN <some_command_to_install_deps>
---> Running in ceada9d96c61
* Getting my_repo (git#github.com:my_org/my_app.git)
remote: verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I've tried adding deploy keys using https://github.com/cedricziel/dokku-deployment-keys to no avail. Any help is greatly appreciated.
Along with the deployment keys plugin, you will also need the hostkeys plugin to add github.com to the container's known_hosts file. For example, to approve github.com across all applications on the machine, simply do...
Install the plugin...
dokku plugin:install https://github.com/cedricziel/dokku-hostkeys-plugin.git hostkeys-keys
Then run...
sudo dokku hostkeys:shared:autoadd github.com
If you still face issues after doing this, there is something wrong with your deployment keys setup. In that case, leave a comment and I'll help troubleshoot it
Related
I'm running Sonatype Nexus 3 inside a docker container, with the following startup command:
docker run -d -p 80:8081 --ulimit nofile=65536:65536 --name nexus -v nexus-data:/nexus-data -e INSTALL4J_ADD_VM_PARAMS="-Xms4g -Xmx4g -XX:MaxDirectMemorySize=6717m -Djava.util.prefs.userRoot=${NEXUS_DATA}/javaprefs" sonatype/nexus3
After updating the docker image version from 3.30.0 to 3.40.1, I keep getting the following warnings regarding user prefs.
2022-07-18 13:14:45,860+0000 WARN [Timer-0] *SYSTEM java.util.prefs - Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
2022-07-18 13:15:15,860+0000 WARN [Timer-0] *SYSTEM java.util.prefs - Could not lock User prefs. Unix error code 2.
As you can see from the startup command, the user prefs directory is inside the docker volume and at directory /nexus-data/javaprefs . I have tried looking for existing locks inside the directory, but found none. I've also tried completely deleting the directory and saw that the warning still came up and the folder itself wasn't being created by Nexus.
I honestly don't even know if this is an important issue or not, since there is little to no documentation about the user preferences folder.
Even a way to turn off the warning log which fires every 30s would be useful.
----UPDATE----
I've tried doing a clean installation of Nexus through Docker, following the simple instructions inside the github sonatype nexus3 docker repository, and still find these warnings.
I even tried on a different OS (Windwos instead of linux, through Docker Desktop) and with and without a volume for /nexus-data.
At this point I believe it to be a bug in a newer Nexus version.
TLDR: Adding -Djava.util.prefs.userRoot=/nexus-data/javaprefs should solve the problem, assuming the nexus data directory is at /nexus-data/.
Just had the same issue after upgrading from 3.38.1 to 3.42.0. After some investigation found that indeed the java.util.prefs.userRoot property got lost somewhere between those versions. The default value in the vanilla Nexus 3.38.1 is /nexus-data/javaprefs.
I am currently running CE version 8.17.4 and am attempting to setup a deploy key with write access (as of 8.16) so that my runner instance may commit build artifacts back to the repository. I took the following steps to set this up:
On the runner instance, I generated the ssh keypair with the command:
sudo ssh-keygen -t rsa -C "label" -b 4096
The generated keypair was saved to /home/gitlab-runner/.ssh/id_rsa and password protected.
Within Gitlab, I created a public deploy key from the admin console and pasted the contents of id_rsa.pub into the appropriate field and verified that the key fingerprints matched. I checked the "Write access allowed" box.
In the private project that I wished to enable repository access from the runner, I enabled the newly created public deploy key.
This is a LaTeX document respository, so in the .gitlab-ci.yml file, I issue the following script after building the pdf:
after_script:
- "git commit -am 'autobuild PDF'"
- "git push origin master"
When the changes were committed, the build ran successfully on the runner up until the git push origin master command, and this error was thrown:
fatal: Authentication failed for 'http://gitlab-ci-token:xxxxxxxxxxxxxxxx#host/project.git/'
Ok. A couple questions:
If the deploy key is just an SSH key, shouldn't it be connecting on the secure port or does this matter? I haven't found much documentation on using this new write-permission deploy key feature, so am I missing something in the steps I took above?
Do I need to include [ci skip] in the commit message to avoid looping CI builds? I saw this concern come up in the original issue tickets for this feature, but did not see whether this step was required or not.
Thanks for any help!
Jawad's comment worked for me: you need to force SSH. for example
git remote add ssh_remote git#host:user/project.git
git push ssh-remote HEAD:dev
thanks jawad
I want to setup apache openwhisk on-premise in my organization. so that we can use it internally within the org. i am not able to find much on the net on this. i tried cloning the code from git and building it in the windows. but it doesn't work. kindly help
Follow these steps to start the platform in a virtual machine in your local environment.
# Clone openwhisk
git clone --depth=1 https://github.com/openwhisk/openwhisk.git
# Change directory to tools/vagrant
cd openwhisk/tools/vagrant
# Run script to create vm and run hello action
./hello
If this works, you should see the following output.
wsk action invoke /whisk.system/utils/echo -p message hello --result
{
"message": "hello"
}
If you encounter problems with these steps, please open an issue in the Github repository for the project.
Deploy OpenWhisk using the ansible playbook in high-availability mode.
I downloaded and unzipped the Apache Apollo distribution as described in their site.
~/Developer/Web/MQTT/apache-apollo-1.7.1/bin/apollo create mybroker
I got teh below output in the Terminal.
Creating apollo instance at: mybroker
ERROR: mybroker/etc/log4j.properties (No such file or directory)
That command is supposed to create the etc sub directory among others.
Any idea why this error is occurring?
Okay, I resolved it. I installed Apollo via Homebrew successfully. Then I cd'ed to /var/lib and ran the following command. This time with sudo.
sudo apollo create mybroker
It created the broker successfully. Then I ran the below command to run it. Again with sudo.
sudo mybroker/bin/apollo-broker run
Which started the broker and I could login via the web dashboard at http://127.0.0.1:61680/ too.
I use Ubuntu 16.0.4. And I encountered the same problem. I resolved by this:
use "sudo apollo create......"
it seems because the apollo didn't have authorities to create document in /etc/
I have a problem with the deployment of the project on the production server. We use Capistrano and Passenger. The problem is that we moved the project repository on GitHub to another account. I changed the repository address in the file deploy.rb, however, during the 'cap production deploy ", after authentication by the production server, Capistrano is looking for an old repository, which fails. I suspect that this is a change in the repository. git on production, but I do not know how to do it.
servers: ["85.xxx.xxx.xxx"]
Password:
[85.xxx.xxx.xx] executing command
** [85.xxx.xxx.xx:: err] ERROR: repo / repo.git does not exist. Did you enter it correctly?
** [85.xxx.xxx.xx:: err] fatal: The remote end hung up unexpectedly
command finished in 4220ms
*** [deploy: update_code] rolling back
Try editing shared/cached-copy/.git/config and modify the git repo listed there. If you're using the remote_cache method, it keeps a local git repo and updates that on the remote machine. Repoint that to your new git repo and you should be good to go.