I have installed Docker and Portainer on my Asustor home NAS. This issue appears to be specific to the implementation of Docker/Portainer provided in their app store. I have been working directly with the Portainer staff and they have not seen this issue before.
I have been following instructions from Portainer (https://www.youtube.com/watch?v=V0OvPyJZOAI) to deploy an agent in the program and found where Docker stores volumes (non-standard Linux location), however now I am getting an error that I believe is also caused by the non-standard implementation on Linux used by the NAS OS. This error happens when I go to start the service when following the stops in the video linked above. The error I am getting is "starting container failed: error creating external connectivity network: cannot restrict inter-container communication: please ensure that br_netfilter kernel module is loaded"
The response I got from Asustor Support is
The kernel module is in the [NAS OS].
So if you want you to need to manually insert the module to have it
working.
But please note that we have not yet tested it so there might be a
risk to the stability of the system.
I have located the filepath of the kernal module by logging in via SSH but I do not know what I need to do in regards to inserting the module as the Asustor support team told me to do.
Screenshot of Portainer error
Related
I am new to the tech world, I want to get to know eclipse hawkBit, I am a total noob and beginner so any help is mucha appreciated.
My scenario:
I have a Windows 10 OS with VMware workstation on it, I have installed Ubuntu on it to run eclipse hawkBit and docker ofcourse.
My internet connection is a highspeed mobile internet connection, I use my smarphone to tether(Mobile hotspot).
What I want to do:
I want to start eclipse hawkBit so basically run it simulate some devices and get to know how to use hawkBit.
My problem: so to run hawkBit according to the official documentation i just need to give this on the terminal: docker run -p 8080:8080 hawkbit/hawkbit-update-server:latest
I have seen a youtube video where if hawkBit works it will show me the localhost port info and say successfully connected(or something similar to that)
but the error or problem i keep encountering is this: 2021-06-17 11:35:19.312 INFO 1 --- [tContainer#1-56] o.s.a.r.c.CachingConnectionFactory : Attempting to connect to: [localhost:5672]
Here is a picture of it:
I would really appreciate if you guys could help me with this, there is not much support or videos of this problem, infact its hard to find decent reference material for hawkBit.
any help is much appreciated.
The exception you see here is due to a missing (or misconfigured) RabbitMQ service.
You will need to configure the environment variable SPRING_RABBITMQ_HOST to point to the running RabbitMQ instance.
docker run -p 8080:8080 -e SPRING_RABBITMQ_HOST=ip-of-rabbitmq-service hawkbit/hawkbit-update-server:latest
For an easier setup, you could use the docker compose file for hawkbit (Option B or C), which already has a preconfigured RabbitMQ as well as MySQL container.
TL;DR: Everything network-related is working perfectly except one specific binary (in this case - elm).
I am running a new arch machine - I am connected via wifi and have networks access.
However - elm does not seem to know that. Running elm make fails when it tries to download the dependencies. (This is a project imported from somewhere else).
I could not connect to https://package.elm-lang.org to get the latest list of
packages, and I was unable to verify your dependencies with the information I
have cached locally.
Are you able to connect to the internet? These dependencies may work once you
get access to the registry!
Adding the IP of package.elm-lang.org to /etc/hosts fixes that, but it then throws a similar error for github.com. I can keep doing that, but surely there is a way to convince elm to access the internet.
I'm not using a proxy or anything like that. My connection obviously works and seem stable. elm init also fails for the same reasons so i'm unable to test on a brand new directory.
Thank you all for your help :)
Apparently fresh arch uses the systemd-resolved daemon for DNS, but elm decides to just read resolv.conf directly (which is blank), and then defaults to 127.0.0.1 as the DNS server.
Setting a DNS server manually in resolv.conf did the trick.
I made a VM for making a Image in Azure.
After I made the linux vm(Redhat), I stop the vm and made image.
But I failed making the vm from image.
Both cases have the same problems
-1st case:I didn't install anything.
-2nd case:I install something and made ssh key(rsa)
If i execute this command 'sudo waagent -deprovision+user', there is no error.
BUT my ssh key disappear so my VMs from image cannot connect each other, which means that I cannot generate a cluster by using Ambari.
Is there any way to solve this problem?
this is error I got when I failed making a VM from image.
--------error---- Provisioning failed. OS Provisioning for VM 'master0' did not finish in the
allotted time. However, the VM guest agent was detected running. This
suggests the guest OS has not been properly prepared to be used as a
VM image (with CreateOption=FromImage). To resolve this issue, either
use the VHD as is with CreateOption=Attach or prepare it properly for
use as an image: * Instructions for Windows:
https://azure.microsoft.com/documentation/articles/virtual-machines-windows-upload-image/
* Instructions for Linux: https://azure.microsoft.com/documentation/articles/virtual-machines-linux-capture-image/.
OSProvisioningTimedOut
Before you create a image, you should execute sudo waagent -deprovision+user. If you don't do it, you will get this error.
According to your scenario, you could configure Provisioning.RegenerateSshHostKeyPair=n (/etc/waagent.conf). According this official document
deprovision: Attempt to clean the system and make it suitable for
re-provisioning. This operation deleted the following:
All SSH host keys (if Provisioning.RegenerateSshHostKeyPair is 'y' in
the configuration file)
If it does not work for you, I suggest you could add publickey to your VMs by using Azure Portal.
I am having trouble adding an external process to my CouchDB database. Currently the database contains a few records, all of which have standalone attachments in the form of PNG or JPG. I want to add the Couch_Image_Resizer (by KlausTrainer) to the database so that I can use the queries offered by the Image Resizer to dynamically resize the images on request. However currently it only returns an error when the URL command is used:
http://virtualMachineAddress/_image/archive/test/the_starry_night_painting.jpg?resize=500x500
{"error":"error","reason":"{conn_failed,{error,econnrefused}}"}
I have followed the instructions to the letter, replacing any instance of localhost or 127.0.0.1 with the IP address of my virtual machine (which has been made elastic so should never change) where needed.
I have also altered the local.ini file as was instructed so that it includes the following:
[httpd_global_handlers]
_image = {couch_httpd_proxy, handle_proxy_req, <<"http://127.0.0.1:5985">>}
Finally I have ensured that the program is running via the ./start.sh command. If this is run more than once it returns the following, I am usure as to if it is relevant:
root#couchdb couchdb/couch_image_resizer# ./start.sh
Crash dump was written to: erl_crash.dump
Kernel pid terminated (application_controller) {application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}})
Crash dump was written to: erl_crash.dump
Kernel pid terminated (application_controller) {application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}})`
Some info that might be helpful
erl_crash.dump: pastebin
Server is a virtual AWS machine running Debian 7.9 Wheezy.
The database is hosted externally on this server.
CouchDB version: 1.2.0
The database is not in Admin Party mode, accounts with permissions are in use.
GitHub link: Couch_Image_Resizer
Erlang: erts-5.9.1 64-bit
ImageMagick: 6.8.9-9
I am clearly missing something here, if you need anything else just ask. If anyone can shed any light on what I am missing I would greatly appreciate it!
I have found a solution to this although there may be others.
Stop the service, set its permissions to be owned exclusively by the couchdb user and then adding the start.sh file path to the [osdaemon] section of CouchDB's local.ini before restarting the database and also launching the application as a root user. Doing this was able to kick-start the service and it now functions normally and as intended.
I've just installed Neo4j 1.8.2 onto Azure by following this step-by-step process...
http://de.slideshare.net/neo4j/neo4j-on-azure-step-by-step-22598695
Unfortunately, when I browse to http://:7474/webadmin Fiddler says Error 10061 - No connection could be made because the target machine actively refused it.
I've followed the instructions exactly and haven't received any errors.
Any help much appreciated.
So, I think I got to the bottom of this. I think it was due to the size of compute / VM I was creating. It looks like the problem is caused when running on Extra Small instances. I created a new installation using a Small instance and everything now works :).
Try setting the server to accept connections form all hosts, and maybe use a newer Neo4j, say 1.9.4
http://docs.neo4j.org/chunked/stable/security-server.html#_secure_the_port_and_remote_client_connection_accepts
The way the VM Depot image is set up, it's pre-configured to allow all hosts to connect, and the Neo4j server will auto-start. The only thing you need to take care of, when constructing your VM, is to open an Input Endpoint, with any public port you want (preferably 7474 to stay true to Neo4j) and internal port 7474.
Note that the UI changed a bit since the how-to was published: You can specify the endpoint as the last step before creating your virtual machine. Other than that, the instructions should be the same. And... once the VM is up and running (it'll take about 5-10 minutes), you just visit http://yourservicename.cloudapp.net:7474 and you should see the web admin. Note: this is not the same as your vm name. If you named your VM something like 'neo' then you do not want http://neo:7474 or http://neo.cloudapp.net:7474. You need to use your cloud service name (you had to create a name for the service when you deployed the VM.
I've deployed that image several times in demos, and just tried again right now to make sure nothing wonky happened. Worked perfectly.