I have been trying to use shellinabox. I cloned the github repo below and followed the steps mentioned.
https://github.com/shellinabox/shellinabox
My /etc/default/shellinabox file is like below:-
# Should shellinaboxd start automatically
SHELLINABOX_DAEMON_START=1
# TCP port that shellinboxd's webserver listens on
SHELLINABOX_PORT=4200
# Parameters that are managed by the system and usually should not need
# changing:
# SHELLINABOX_DATADIR=/var/lib/shellinabox
# SHELLINABOX_USER=shellinabox
# SHELLINABOX_GROUP=shellinabox
# Any optional arguments (e.g. extra service definitions). Make sure
# that that argument is quoted.
SHELLINABOX_ARGS="--o-beep"
All steps were same for me except the deb package installation which I downloaded from a resource which is shellinabox_2.20_armel.deb which i kept in the root folder.
On the other hand I tried all steps in below link too :-
https://askubuntu.com/questions/414930/access-webpage-through-ssh
and have watched the below video from youtube:-
https://www.youtube.com/watch?v=2viORNwxNTY
But I am not able to run the localhost using my IP address to access it. https://myipaddress:4200/
When I try to access the url in web browser I see
This site can’t be reached.
myipaddress refused to connect.
Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED
What am I missing or doing wrong?
Related
I have a virtual machine that is supposed to be the host, which can receive and send data. The first picture is the error that I'm getting on my main machine (from which I'm trying to send data from). The second picture is the mosquitto log on my virtual machine. Also I'm using the default config, which as far as I know can't cause these problems, at least from what I have seen from other examples. I have very little understanding on how all of this works, so any help is appreciated.
What I have tried on the host machine:
Disabling Windows defender
Adding firewall rules for "mosquitto.exe"
Installing mosquitto on a linux machine
Starting with the release of Mosquitto version 2.0.0 (you are running v2.0.2) the default config will only bind to localhost as a move to a more secure default posture.
If you want to be able to access the broker from other machines you will need to explicitly edit the config files to either add a new listener that binds to the external IP address (or 0.0.0.0) or add a bind entry for the default listener.
By default it will also only allow anonymous connections (without username/password) from localhost, to allow anonymous from remote add:
allow_anonymous true
More details can be found in the 2.0 release notes here
You have to run with
mosquitto -c mosquitto.conf
mosquitto.conf, which exists in the folder same with execution file exists (C:\Program Files\mosquitto etc.), have to include following line.
listener 1883 ip_address_of_the_machine(192.168.1.1 etc.)
By default, the Mosquitto broker will only accept connections from clients on the local machine (the server hosting the broker).
Therefore, a custom configuration needs to be used with your instance of Mosquitto in order to accept connections from remote clients.
On your Windows machine, run a text editor as administrator and paste the following text:
listener 1883
allow_anonymous true
This creates a listener on port 1883 and allows anonymous connections. By default the number of connections is infinite. Save the file to "C:\Program Files\Mosquitto" using a file name with the ".conf" extension such as "your_conf_file.conf".
Open a terminal window and navigate to the mosquitto directory. Run the following command:
mosquitto -v -c your_conf_file.conf
where
-c : specify the broker config file.
-v : verbose mode - enable all logging types. This overrides
any logging options given in the config file.
I found I had to add, not only bind_address ip_address but also had to set allow_anonymous true before devices could connect successfully to MQTT. Of course I understand that a better option would be to set user and password on each device. But that's a next step after everything actually works in the minimum configuration.
For those who use mosquitto with homebrew on Mac.
Adding these two lines to /opt/homebrew/Cellar/mosquitto/2.0.15/etc/mosquitto/mosquitto.conf fixed my issue.
allow_anonymous true
listener 1883
you can run it with the included 'no-auth' config file like so:
mosquitto -c /mosquitto-no-auth.conf
I had the same problem while running it inside docker container (generated with docker-compose).
In docker-compose.yml file this is done with:
command: mosquitto -c /mosquitto-no-auth.conf
Have spent over a day trying to get PhpStorm to debug a Drupal site inside a Vagrant virtual machine running Xdebug and I feel I'm close - but just not quite there yet.
Currently, in PhpStorm when debugging I have an error:
Waiting for incoming connection with ide key 'PHPSTORM'
In the Xdebug log in the VM (at /tmp/xdebug.log)
[2094] I: Checking remote connect back address.
[2094] I: Checking header 'HTTP_X_FORWARDED_FOR'.
[2094] I: Checking header 'REMOTE_ADDR'.
[2094] I: Remote address found, connecting to 192.168.88.1:9000.
[2161] E: Time-out connecting to client (Waited: 200 ms). :-(
[2161] Log closed at 2020-12-15 04:25:32
I tried setting up the Zero-configuration debugging without any luck.
For the debugging configuration, I have a PHP Remote Debug that validates correctly although it always defaults to the 'Local Web Server or Shared Folder' rather than the 'Remote Web Server' option.
When I started the project I set it up as a local web server option and I'm worried that I haven't changed the correct settings to now make this a remote web server. The connection type for the deployment is now 'Local or mounted folder' but originally this was 'In-place'.
Under Languages & Frameworks --> PHP --> Servers, I set this up on port 80, using Xdebug and without path mappings. I tried changing the port etc but then it doesn't validate so I'm confident that the server settings are correct and that PhpStorm is talking to the virtual machine correctly.
I changed the /etc/php/7.4/cli/php.ini file but phpinfo() says the configuration is coming from /etc/php/7.4/fpm/php.ini. The changes I made in the php.ini file are active though. phpinfo() is showing:
xdebug.idekey: PHPSTORM
xdebug.remote_host: 10.0.2.2
xdebug.remote_port: 9000
xdebug.remote_autostart: Off
xdebug.remote_connect_back: On
Really at a loss now as to what to try next. It is incredibly frustrating so hope someone can shed some light.
EDIT --- As per comment here is the screenshots of the setup:
Deployment: Local or mounted folder
PHP settings
The server setup
Debug settings
Validate the debugger from the remote server
Run Chrome with the debug addon running
The error message
The Run debug configuration settings
Start of the phpinfo with the config file showing where the xdebug settings need to be edited.
The Xdebug settings of phpinfo()
Some of the tests as per the comments:
After logging in to 'vagrant SSH' it shows the IP address to be used (10.0.2.2). The local computer is also IP 10.1.1.150 a telnet test of both of these works.
A 'sudo nano' of the Xdebug ini file
NOTE: Changing the remote connect back to 0 fixed the connection:
xdebug.remote_connect_back=0
And then the path mapping needed to be turned on in the Server settings and then everything was working correctly.
Big thanks to LazyOne for his helpful and thorough comments. :)
1) Check if there are separate php.ini files used by web server, -- you need to edit the right php.ini file.
Run phpinfo() and check to see if there is an ini file for Xdebug. In my case this was at /etc/php/7.4/fpm/conf.d/20-xdebug.ini
2) What's your Xdebug version?
Version 2 and 3 of Xdebug have slightly different parameters. In my case I was running Xdebug 2.9.5
3) What is the IP address of your Host OS as seen from the inside the VM? That's where Xdebug should connect (as it's Xdebug that connects to IDE and NOT other way around).
When you first log in to the SSH there will be an IP address shown. This is what the IP should be for Xdebug. In my example, this was 10.0.2.2
4) xdebug.remote_connect_back: On -- try set it off and ensure that you have correct xdebug.remote_host (as Xdebug v2 may not fallback to remote_host value when autodetected IP fails.
This fixed my connection!
sudo nano /etc/php/7.4/fpm/conf.d/20-xdebug.ini
Then change:
xdebug.remote_connect_back=1
To:
xdebug.remote_connect_back=0
Save, and then restart the server.
Test the connection again. After this step I had a connection between the host and remote server but I also had to turn on path mapping in PhpStorm to get the debugger working 100%.
5) Ensure that PhpStorm is the one that listens on Xdebug port when "phone handle" icon is enabled (use netstat or alike to confirm) and is allowed in firewall.
6) If you know the correct IP and sure that PhpStorm is listening -- you can just use telnet from inside the VM and try to connect to IDE on Xdebug port -- if connected then IP, port and firewall is most likely set up correctly.
Even with the error messages, the telnet check was working. So it pointed to the issue being with the Xdebug setup rather than the handshaking between the host and remote server.
Thanks to LazyOne's comments for finding the answer and for presenting a great workflow to help identify the problem.
I was experiencing something very similar to what you described.
I was able to start a debug session from the xdebug cli tool (dbgpClient) which proved to me that it was an issue with phpStorm.
My project is using a legacy version of xdebug. (2.2.7)
Downgrading to phpStorm 2020.2.4 resolved my issue.
(It's one-click in the jetbrains toolbox to downgrade)
Thanks for the answers in this issue. It took me half a day to find out that xdebug 2.2.7 with php5.3.10 doesn't work on Phpstorm 2020.3. So I downgraded to 2020.2.4 and it works again.
I'm trying to install Docker on a Windows computer but I get this message:
Running pre-create checks...
(default) No default Boot2Docker ISO found locally, downloading the latest release...
Error with pre-create check: "Get https://api.github.com/repos/boot2docker/boot2docker/releases/latest: dial tcp 192.30.252.124:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond."
Looks like something went wrong in step 'Checking if machine default exists'...
Press any key to continue...
Any suggestions on how to resolve this?
Editing the start.sh file may come up with other error things.
Instead that, just put your boot2docker.iso in below location as.
c:\user\USERNAME\\.docker\machine\cache
and restart your Docker terminal.
You may behind a firewall. If so, you will need to configure an http proxy.
According to https://github.com/boot2docker/boot2docker-cli/issues/230 you can do this one of a couple of ways:
(1) Edit start.sh and add the following before boot2docker.exe is called
export HTTP_PROXY=<proxy>
export HTTPS_PROXY=<proxy>
(2) Add HTTP_PROXY and HTTPS_PROXY (and their values) to your System Variables or User Variables in your Windows config.
The proxy value should be of the form http://hostname:port
I am trying to debug PHP files which sit on a remote server (on the same network) without success.
Here is my php.ini config for xdebug on the remote server where PHP and xdebug are installed:
xdebug.remote_enable=1
xdebug.remote_host=192.168.128.56
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_autostart=0
192.168.128.56 is the IP address of my PC on which my editor is installed.
I have tried to get this working with both Atom and Sublime Text 3 without success. I think that my path bindings may be incorrect.
I log into the remote linux machine using SFTP. I can then double click on php files in my application and they will open in my editor where I can work on them and save them. How can I set up the path bindings to debug these remote php files? I'm not sure what the second (local) part of the path binding should actually be? Do I need to add the location where the FTP software stores a temporary copy of the file I am working on as the local part of the binding?
I have tried the following:
URL - the address of where the app runs on the remote server:
e.g. http://www.mywebsite.com/testapp/
Path Binding - remote path to the application root on linux : path to the local copy of the files on my machine where the FTP software stores them:
e.g. /web/testApp/ : C:\Users\me\AppData\Local\Temp\scp18929\
I'm a little confused about how the path binding works, and what the values should be. Am I doing this correctly? Can this even be done?
If anyone can help that would be great.
Probably, the first thing to check is whether Xdebug actually tries to connect to your IDE. You can do that, by adding:
xdebug.remote_log=/tmp/xdebug.log
to your php.ini file. When you then initiate debugging, there should be information in the /tmp/xdebug.log file, where it will tell you where it tried to connect too, and whether the connection succeeded or failed.
If you get something like:
I: Remote address found, connecting to 192.168.128.56:9000.
E: Could not connect to client. :-(
That means that either your IDE wasn't listening for something, or that there is a firewall preventing an incoming connection, or that the IP address is incorrect.
I am using hosted Chef for quite some time. Wanted to explore the opensource chef server. hence I am trying to setup my Chef-Server 11 on EC2 instance.
I have Chef-server running and I can access the web GUI for the same. I have the chef-workstation configured on another ec2 instance that is also working fine.
Problem: I am not able to upload any cookbook.
I get below error when I try uploading the cookbook:
# knife cookbook upload getting-started
Uploading getting-started [0.4.0]
/opt/chef/embedded/lib/ruby/1.9.1/net/http.rb:763:in `initialize': Connection refused - connect(2) (Errno::ECONNREFUSED)
However, other list commands of knife are working fine.
I did my home work and bumped on below links:
http://www.opscode.com/blog/2013/03/11/chef-11-server-up-and-running/
http://www.curvve.com/blog/servers/2013/script-to-configure-and-set-your-hostname-and-fqdn-on-ec2-instances/
So,
It is mentioned that the chef-server needs a working FQDN to work. I set the my public ec2 host name as the hostname of the server as well as set it up in /etc/hosts. Rebooted the instance. Ran chef-server-ctl reconfigure again. And still facing the same error.
QUESTION: How to figure out the FQDN part of the EC2 instance for chef-server to work? if anyone has set up chef-server successfully on EC2 and was able to upload the cookbooks, then please share your steps for FQDN workout.
I was having a hard time with this but this solution worked!
Edit /etc/chef-server/chef-server.rb and add these lines (create the file if it doesn't exist):
server_name = "THE PUBLIC IP OF YOUR INSTANCE"
api_fqdn server_name
nginx['url'] = "https://#{server_name}"
nginx['server_name'] = server_name
lb['fqdn'] = server_name
bookshelf['vip'] = server_name
I found the solution here
http://sahebjade.blogspot.com/2013/05/check-your-knife-configuration-and.html
This is how i got it working. updated the public DNS name of my ec2 instance (chef-server) in /etc/sysconfig/network and service network restart. Now I am able to upload the cookbooks fine.
Need to think about elastic IP as potential option for my chef-server.
Edit /etc/chef-server/chef-server.rb and add these lines (create the file if it doesn't exist):
bookshelf["vip"] = node["ipaddress"]
bookshelf["url"] = "https://#{node["ipaddress"]}"
erchef['s3_url_ttl'] = 3600
The first two lines will point your chef-server URL to the machine's IP and the third will solve a timeout issue that apparently always exist when the Chef Server is on EC2.
I wanted to expand some on the answers since they don't give a complete picture. This applies to Chef 11 (hopefully Chef 12 is smarter)
In my case I rolled a master up under VPC #1 which gave it an internal address like this
ip-10-0-0-10.ec2.internal
Because I was only playing with the VPC initially, I had misconfigured some things I needed so I had to drop it and I created a new scheme. Thankfully, I was able to snapshot the old Chef master and bring it up under the new VPC but I found that I couldn't log into Chef anymore. It took some digging but I found in my /var/log/chef-server/chef-server-webui/current log that the install had glommed onto the old hostname and set that as the internal URL for... everything. This caused problems after the internal hostname change
2014-12-24_16:19:09.46680 SocketError: Error connecting to https://ip-10-0-0-10.ec2.internal/users/admin - getaddrinfo: Name or service not known
Now, to the OP answer
Need to think about elastic IP as potential option for my chef-server
In my case, I just added a CNAME to CloudFlare and set that as my permanent address. Since I can set CloudFlare to a low TTL on that one address it makes it easy to move it around between IP changes (I don't need an Elastic IP while I'm just getting it configured). This way I could then tell Chef to always look for the same URL and not worry about an EIP.
Once that was done, I had to update Chef. I don't know what changed (this is 11.16.4) but I found the configs live in /var/opt/chef-server/chef-server-webui/etc/chefserver.rb as opposed to some of the other answers listing chef-server.rb. Not sure if that's a YMMV thing or not.
I changed the following towards the bottom of that file
# Environment specific application configuration.
# These values override the ones set in 'RAILS_ROOT/config/application.rb'
#config.chef_server_url = "https://ip-10-0-0-10.ec2.internal"
config.chef_server_url = "https://chef.mydomain.com"
I also changed /var/opt/chef-server/nginx/etc/chef_https_lb.conf
server_name chef.mydomain.com;
Finally I restarted Chef
chef-server-ctl restart
That seems to have done the trick. Logins work again.