Problems with starting the chroot service of the local Labdoo installation

×

Missatge d'estat

You are not a member of this team. If you want to be part of this team, click on 'Subscribe to this team'.
Tipus: 
General task
Estat: 
Resolved
Prioritat: 
Normal
Descripció: 

Hi Jordi,
I am working on a Windows 10 machine and I am using VirtualBox and Windows HyperV to create a Virtual Machine with Ubuntu 16
Host-OS: Windows 10
Guest-OS: Ubuntu 16

6 days ago I installed the local installation for the first time on a vm (virtual machine). I followed the steps for the local installation from labdoos github repository found here: https://github.com/Labdoo/Labdoo
At first I installed it on a vm on VirtualBox and it worked. I could access my local installation in the browser via www.labdoo-dev.org. But I had problems with the network connection to the host. I just could not figure out a way to let the host access my local installation (www.labdoo-dev.org). I tried to solve that for many hours. I ried every suggestions and tutorials available...without any luck. Finally I decided to switch to a vm on Hyper-V Manager and deleted my vm on VirtualBox.
The problem now is that, also I again did follow the instruction, I can not start the chroot-lbd service on the vm on Hyper-V. I tried to go back to VirtualBox and so again created a vm on VirtualBox and after following all the installation steps again I could not start the service there as well. So now I can not start the chroot-lbd on either Hyper-V or VirtualBox. I don't understand why it is not working and why it did work on my first created vm (which I already deleted)..

Any chance, you ever had the same problem while starting the service?
If I try to start the service that happens:
"root@lisabellhv-Virtual-Machine:/var/chroot/labdoo# service chroot-lbd start
Job for chroot-lbd.service failed because the control process exited with error code. See "systemctl status chroot-lbd.service" and "journalctl -xe" for details."

I attached the outcome of "systemctl status chroot-lbd.service" and "journalctl -xe"

Greetings
Lisa

Comentaris

imatge de jordi
Enviat per jordi el dl., 10/23/2017 - 20:03

Hi Lisa,

Could you attach also the file nohup.out generated during the installation of Labdoo?

One quick thing to check, make sure there is enough disk space. Run 'df' to verify that your partition is not 100% full.

Here is what i would do:

- Create new new Ubuntu VM using VirtualBox from scratch.
- Install Labdoo following the instruction in https://github.com/Labdoo/Labdoo/.
- Check in nohup.out that the installation was correct. If something went wrong, send back the nohup.out file so we can check where it failed.
- Also if it fails, report which Ubuntu version you are using.

The above steps should work, but let me know how it goes if something fails again.

As for connecting the host computer with your VM, make sure you set up your VirtualBox VM with bridge mode networking: https://www.virtualbox.org/manual/ch06.html#network_bridged

Greetings.

imatge de lisabell
Enviat per lisabell el dj., 10/26/2017 - 16:15

Hi Jordi,
thank you for your answer. We now have our own internet connection and I installed the chroot service while being online via LAN connection and it worked! :) The service is running. Very nice!
BUT: Now I am back to problem number 1. The windows host and the ubuntu guest share an internal network conecction. I am able to ping the guest (ubuntu) from the host system and if I enter the guest IP address in my host browser I get redirected to https://www.labdoo-dev.org/ but the page is not loading and after a while it says "connection timeout". I have disabled my firewall, but it is still not working. Do you have any idea what could cause the problem?

Greetings
Lisa

imatge de jordi
Enviat per jordi el dj., 10/26/2017 - 17:20

Lisa could you send me the output of running the following command from the Windows Host command shell?

telnet [IP address of the Ubuntu guest] 80

Here is an example of the above command against our production Labdoo server:

$ telnet 184.73.165.187 80
Trying 184.73.165.187...
Connected to ec2-184-73-165-187.compute-1.amazonaws.com.
Escape character is '^]'.
GET /
[!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"]
[clipped]
Connection closed by foreign host.

After this, try the same command by running it locally from the Ubuntu guest. Tell me the output.

Also, could you tell me what is the IP address of the Ubuntu guest and the Windows guest?

Finally, can you ping your Windows host from the Ubuntu guest?

imatge de lisabell
Enviat per lisabell el dj., 10/26/2017 - 18:36

Thanks for your quick reply. I attached 3 screenshots showing the output of the telnet command and the ping from guest to Host.
Currently my Guest IP is: 192.168.137.190 and my host IP is: 87.183.41.245
But I already tried with setting the IPs manually to 192.168.1.21 and 192.168.1.22 with the same result.
I searched the internet many times. I was thinking about posting a question on stackoverflow.
There actually is a similar question about that here: https://unix.stackexchange.com/questions/40510/cannot-connect-to-my-virt... but it was not solved.

imatge de lisabell
Enviat per lisabell el dj., 10/26/2017 - 19:13

If I use : telnet [guest ip]
(without the port) I can access my ubuntu 16 os guest from windows, after entering username and password. should I maybe switch the webserver of the labdoo installation? makes that sense? I will try now.

imatge de jordi
Enviat per jordi el dv., 10/27/2017 - 10:08

Hi Lisa,

I believe the reason is because you are probably using NAT instead of Bridge mode for your network connectivity. Notice that the IP address of the guest VM is a private IP address (192.168.137.190) whereas the IP address of the host is a public IP address provided by your network telco. That means they are in different subnets, and most likely that's because your VM has its network configured in NAT mode.

Could you change your VM configuration to Bridge mode? see the screenshot i am attaching.

One other thing to consider is that it looks like your computer is directly attached to the Internet since it's directly getting a public IP address. If your Internet provider only gives you access to one IP, then Bridge mode won't work (as that will require having 2 public IP addresses, one for the host another for the guest). If that's the case, i would recommend connecting your computer to a router and the router to Internet, to ensure your computer can get an IP address from the router and not from your Internet provider. That's also a safer configuration because if your computer has a public IP address attached to it, it means anyone in the world can ping it and see your computer. Putting a router (doing NAT itself) in between your computer and the Internet will protect your computer.

I am sure this should work as i use this some times too, it's likely some small configuration that needs to be tuned. Making this work can be useful as it allows you to work from anywhere even if you don't have Internet connection (even if you are in the mountains as you do now :) )

But yes, we do have a developer server in the AWS cloud too. I will send you the credentials to access the developer server via email in case you want to use that. My recommendation would be to use both, this way you always have a plan B in case one does not work.

imatge de lisabell
Enviat per lisabell el dv., 10/27/2017 - 11:12

Hi Jordi, i am currently not using virtual box, but Hyper-v. The naming of the networks is different, but it should be a bridged network.
I will try that again with virtual box. Both, hyper-v and virtual box) are not able to run at the same time, because virtual box need windows hyper-v function to be disabled (including a full restart of my laptop..).
I have tried bridge modus as well as NAT and others before...but I will try again :)

The problem of the IP part is, that I do not fully understand how that is possible. Our internet connection from the internet provider is IP based, so yes, we have only one public IP. I am connected to a router (via LAN) or wifi.
The routers Dashboard shows that it gives every device its own IP in the same subnetwork 192.168.178.XX
I changed a bit in the routers configuration and hopefully now it will work.
I will install a new vm on virtualbox with Ubuntu 16 and a bridged network and let you know about the update.
I also believe there is just a tiny bit not working or stopping the connection (like a firewall or sth) I hope it will work soon...
Thank you for your help.
Greetings
Lisa

imatge de lisabell
Enviat per lisabell el ds., 10/28/2017 - 12:48

Hi Jordi,
now I have installed Ubuntu on a virtualbox vm and connected it via bridge mode. I am able to ping the guest from the host and the host from the guest (if the firewall on the host is disabled).
IPs are:
Guest: 192.168.178.30
Host: 192.168.178.25
But the problem is again, that I cannot access the server :(
I did telnet [ip] 80 again and attached the screenshots..

I also checked the open ports on my ubuntu guest and attached the screenshot of it.

I am able to access www.labdoo-dev.org on the ubuntu vm.

imatge de lisabell
Enviat per lisabell el dg., 10/29/2017 - 00:52

I can open https://www.labdoo-dev.org/ on the guest ubuntu. But if I enter either https://www.labdoo-dev.org/ or https://192.168.178.30 in the browser on the host windows machine it says: "Err_connection_refused" "www.labdoo-dev.org refused the connection.
Today with help of my router software I assigned a public IP to my virtual machine and port 80 ( I will not post the ip here :) but I could send it to you via email. Of course it is only accessible when the vm is running). I just wanted to make sure that my computer is not the problem. I tried to access that public IP with my smartphone and on a second laptop and the IP address I entered each time got resolved to www.labdoo-dev.org but the connection was refused. The problem seems to be with the labdoo local installation.
I had no proxyies enabled, nor firewall on either ubuntu, windows or the router.

I attached screenshots of the browser on the host trying to access the guest IP and a screenshot of the output of "service chroot-lbd status" on the guest.

You have used the local installation on a vm before and were able to access it from your host?

Maybe I should just start using our test system on the Amazon AWS cloud system.

Translation (by google translate) of the browser text. Unfortunately the browser do not give a status number.

Chrome says:
"This website is not available

www.labdoo-dev.org has declined the connection.
Try the following:
Check connection
Proxy and firewall
ERR_CONNECTION_REFUSED"

Firefox says:
"Error: Connection failed

Firefox can not connect to the server at www.labdoo-dev.org.

     The site could be temporarily unavailable, please try again later.
     If you can not access another website, please check the network / internet connection.
     If your computer or network is protected by a firewall or a proxy, please make sure that Firefox is allowed to access the Internet."

imatge de jordi
Enviat per jordi el dg., 10/29/2017 - 06:49

I think i may know what's happening.

In looking at your browser error, you are getting ERR_CONNECTION_REFUSED. This is the error you get when one is trying to establish a TCP connection on port XYZ against a server which has no listening port established on XYZ. Internally, the TCP stack immediately sends back a RESET packet to the client, resulting in to the connection refused. (This is different from a connection timeout, which is typically the error you get if the problem is with the firewall, which results in a silent packet drop and an eventual timeout).

So it's clear to me that your request is trying to access a destination server which has no socket listening on the destination port. Notice that the destination port in our case is actually port 443 (not port 80), since we are using HTTPS protocol. I have the feeling that for some reason, your request is being routed to your Windows machine (instead of the Ubuntu). Since the Windows machine does not have any HTTPS server running, you get the ERR_CONNECTION_REFUSED from the Windows machine, not the Ubuntu.

One reason could be the following.

In our documentation (https://github.com/Labdoo/Labdoo), we ask the user to:

> Make sure to include the following lines in your /etc/hosts file (outside the chroot):
> 127.0.0.1 www.labdoo-dev.org localhost

For some reason, i think the Windows machine is trying to access local IP address 127.0.0.1, which results into trying to access the Windows machine itself.

Could you check that your Windows machine does not have a mapping that forces any request to www.labdoo-dev.org to go to 127.0.0.1? basically, i would focus the debugging effort to ensure that your request to https://www.labdoo-dev.org/ does not go to the Windows host itself, it needs to go to the Ubuntu guest.

I would recommend the following:

- Go back to the previous configuration in which you had both your computer and the guest Ubuntu with private IP addresses.
- Tell me which are the two new IP private addresses assigned (the host and the guest)
- Run the command "ping www.labdoo-dev.org" from the host. What output do you get? the output will indicate the IP address of the destination, is this IP address the one from the guest or the one from the host?

In the meantime yes you can use the AWS machine for development, while you debug this.

imatge de lisabell
Enviat per lisabell el dg., 10/29/2017 - 19:35

I had an Error connection timeout before, but I guess I must have had the firewall enabled.

I checked my etc/hosts file on my windows host computer and there is no entry regarding labdoo (see attached screenshot).
I did add the line mentioned to the etc/hosts file in the guest and I checked and it is still there.

I deleted the public IP configuration, connected the vm via bridge mode and started the service and disabled firewall.
Ip adresses are:
Guest: 192.168.178.30
Host: 192.168.178.20
I did run "ping www.labdoo-dev.org" on both, host and guest ( I attached screenshots).
The result on the guest makes sense, but not the output on the host.
Do you have any explanation for that? I don't know what that ip is (62.138.238.45) and how it is connected to www.labdoo-dev.org.

I can access the page https://www.labdoo-dev.org/ on the guest and if I enter either the guest IP or https://www.labdoo-dev.org on the host it says ERR_CONNECTION_REFUSED, but only after a while (>5sec). If I enter 127.0.0.1 on my host it will say ERR_CONNECTION_REFUSED after a second.
If I enter the guest IP in the host it gets directed to https://www.labdoo-dev.org. I mean, I enter the IP of the guest in the browser and after some seconds it says connection refused, but instead of the IP now it shows https://www.labdoo-dev.org in the address bar.
For me that looks like it reaches the guest, gets redirected by the guest to https://www.labdoo-dev.org but for some reason can not access the https://www.labdoo-dev.org page. So "ERR_CONNECTION_REFUSED" seems to be related to the labdoo server on the guest, it seems like it is refusing to connect to the host.

imatge de jordi
Enviat per jordi el dg., 10/29/2017 - 23:52

Hi Lisa,

That's interesting indeed. I just followed your steps using my own computer, running Virtual Box with Ubuntu 16 as guest, on a macbook as host. Things work well for me.

The IP address of my guest is 192.168.1.25. When i try to access https://192.168.1.25 from the host, the browser takes me to the usual warning message (since the security key is not certified). After accepting that warning, then the browser displays the labdoo.org site. See the two screenshots for each of these two steps.

It's difficult for me to think of a possible issue on the server side, also since this appears to work for me. I am wondering if there is an issue with some host name or IP address resolution being locally cached in your host computer. The IP address 62.138.238.45 (which is geolocated in Germany https://ipinfo.io/62.138.238.45) is indeed very strange. Is there a way that you can try to reset all your local DNS caches or your local host name mappings?

imatge de lisabell
Enviat per lisabell el dl., 10/30/2017 - 14:33

Oh my god. I was going mad!
Thank you for putting me on the right track!!!
What I did:
At first I deleted the DNS cache on my windows host. But that did not help (see attached screenshot). If I did "ping www.labdoo-org.dev" on my windows host it would still somehow show this weird german IP.
So I just thought, maybe I have to add "[guest-ip] www.labdoo-dev.org" to my etc/hosts file on my windows host!
So I did that. I added 192.168.178.30 www.labdoo-dev.org.
Then I did the ""ping www.labdoo-org.dev" again and it now was getting an answer from the guest IP instead of this unknown german IP.
So I opened https://www.labdoo-dev.org/ in my browser and...FINALLY!! it asks me for the security exceptions and then opens the labdoo page.
WOW!! Just took me 1 week to get it running ;)
I still don't understand why I had to do that, but it works now.
Thank you so much for your time and help. From what I see in the news things are crazy in Catalonia and Spain at the moment, so thank you for your help even more.
Cheers (I am having a glass of (non alcoholic) sparkling wine))! Just wonderful. It works :) Finally I can focus on developing :)

imatge de lisabell
Enviat per lisabell el dl., 10/30/2017 - 15:00

I just searched the internet for that issue and it seems to be related to my internet provider, which is "Deutsche Telekom".
If a domain is unknown to the provider (like www.labdoo-dev.org) than it forward the client to one of their own pages called "Telekom Navigationhelp".
This "service" can only be disabled by calling the provider. My provider is the biggest in Germany, but maybe other providers (in other countries) do that as well. I will add this problem and solution as a hint to the documentation on how to set up the vm environment.

imatge de jordi
Enviat per jordi el dl., 10/30/2017 - 16:46

Great finding and congrats on getting this to work! enjoy your well-deserved (non-alcohol) glass of wine :).

Yes feel free to extend the existing documentation with your learning lessons as it will be helpful for others.

Good debugging work!