Fix for broken ./build.sh (fails), need to add code to the /base/Dockerfile about fopnp

[brandon-rhodes]

Thanks for the extended notes! I have linked to them from the main documentation so that others can benefit from them.

[tdarrow]

Can this be set up to run on ESXi?

[brandon-rhodes]

I don't know — alas, I don't have any experience with ESXi.

[Modagiri]

How can I run the Playground on Ubuntu 16.04 (No Virtualmachine/VirtualBox)

[brandon-rhodes]

@Modagiri — If you have Docker installed, it's possible you could skip down to the "Building the Playground" section of the README and follow the instructions for ./build.sh and ./launch.sh.

[cn-pkmer]

What's error???

vagrant@vagrant-ubuntu-trusty-64:~$ ./launch.sh
++ dirname ./launch.sh

• cd .
• grep -q docker
  ++ groups
• echo vagrant
• sudo adduser vagrant docker
  adduser: The group `docker' does not exist.

[janus]

I changed "from 14.04" to "from 16.04" and added the needed libffi-dev and libssl-dev. I also changed the Vagrant file to xenial64. I was able to get started, I got build.sh and launch.sh up and running. I was able to do "ssh h[1-4]" but I have to manually copied ssh-config. But ssh www and their like failed. I noticed that they were no more included in the ssh-config file. But traceroute www.example.com also failed.
I have done a quick check and I have noticed that you changed a couple of areas in previous commits.
I noticed that "ip -a" ( works for hosts h[1-4])
My question is this, what can I do to get traceroute www.example.com to really work and "route n"

NB
vagrant@ubuntu-xenial:~/fopnp/playground$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02421e9d94df no veth0ce2759
veth7cc2652
vetha20a496
vetha6ca388
exampleCOM 8000.1ec262496bc4 no example-eth1
ftp-eth0
www-eth0
homeA 8000.460183d56d1a no h1-eth1
h2-eth1
h3-eth1
modemA-eth1
homeB 8000.36edb6133c8e no h4-eth1
modemB-eth1

[janus]

@Q10Viking
cd to playground and run ./build.sh there?
BTW what is the issue you faced?

[zseusz]

Brendon, thanks so much for your Playground - its on another level.
Please any one know how to install the playground box on a Windows 10 system running either VMware or VirtualBox. Much appreciated.

[brandon-rhodes]

For folks following this thread — someone pointed out to me recently that a few instructions were out of date in the various README files, so I've gone through and have made sure that none of the files still talks about the "play.sh" script, since it's been replaced with plain SSH as the way to connect to one of the playground hosts h1 through h4.

[rlefever]

Let me start by saying thanks for all the effort you have put into this. i am enjoying the book.

I Tried to set this up on Ubuntu 16.04 and had issues. Using vagrant I get up to vagrant up but it times out and I am never able to get further. The VM seems to be running and the 2222 port is there but it does not seem to be talking to anything on the VirtualBox side. unsure how to trouble shoot this.

Tried to do the stand alone docker version and again had some issues. Followed the advice above, had to use wzurowski/vivid64.

in DockerFile
Had to add 'RUN pip install -U pip' before the requirements2.txt ADD line.
Had to add 'RUN pip3 install -U pip' before the requirements.txt ADD line.

in build.sh and launch.sh had to comment out the adding vagrant to docker group
seems vagrant install via apt-get did not create the vagrant user and bootstrap.sh was not used.

Also had to add the h1 h2 h3 h4 to the /etc/hosts file. This caused ssh h1 to ssh into the localhost so had to ssh -p 2201 [email protected] but finally got to the Ubuntu 14 hosts. Seems I have to put the password each time so I may have to manually add the the key to my trusted_keys file.

Last problem I am having is that h1 has eth0 172.17.0.x and eth1 192.168.1.11. I can ping to a couple of the 172 addresses but the 192's all fail as does traceroute and nslookup do I cannot tell if the other hosts are alive.

Any help would be greatly appreciated on getting either or both working. Thanks again.

[brandon-rhodes]

@rlefever Your problems remind me of the symptoms that I have seen when the IP addresses of part of a machine’s network are overlapping with the range of IP addresses that Docker is trying to use — only, of course, you are using raw VirtualBox and Vagrant. But a problem with connectivity would explain why Vagrant is timing out, if the packets were going to the wrong network interface?

[rlefever]

So, Windows 7 running VirtualBox. Vagrant Host is a Ubuntu 16.04 VM running Vagrant and VirtualBox. Docker Host is an Ubuntu 16.04 VM running Docker. The Vagrant Host shows enp0s3 as 10.0.2.15/24 and the lo. network is set to NAT in Main host VirtualBox settings. The Docker host is showing docker0 as 172.17.0.1/16 and enp0s3 at 192.168.100.251/24 again a VM in VirtualBox, network set to Bridge. The docker0 was assigned by the code I assume as I did not set it up. changed Vagrant Host to Bridge and got the same results on vagrant up, just times out. changed the Docker host to NAT, The docker0 is still 172.168.0.1/16, enp0s3 changed to 10.0.2.15/24. All the Docker images are using IPv6 addresses. The 100.x/24 is my local network. What are should I change to fix either/both? Thanks

…

@rlefever Your problems remind me of the symptoms that I have seen when the IP addresses of part of a machine�s network are overlapping with the range of IP addresses that Docker is trying to use � only, of course, you are using raw VirtualBox and Vagrant. But a problem with connectivity would explain why Vagrant is timing out, if the packets were going to the wrong network interface? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #16 (comment)

[brandon-rhodes]

Alas, I have never tried running with a vagrant host separate from the docker host. Without a couple of hours to sit down with your computer and explore which network connections and pings do and don’t work between the different hosts, I doubt if I could make any headway in figuring out how to get the different hosts talking successfully.

[rlefever]

I was hoping you could direct me to the files I needed to modify to attempt making the corrections. Especially since I used the directions in the README and the issue to get to this point. I find I learn best doing troubleshooting. Any guidance would be appreciated but I understand you cannot be expected to maintain the playground forever and on every possible environment. Any and all assistance/clues appreciated.

…

Alas, I have never tried running with a vagrant host separate from the docker host. Without a couple of hours to sit down with your computer and explore which network connections and pings do and don�t work between the different hosts, I doubt if I could make any headway in figuring out how to get the different hosts talking successfully. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #16 (comment)

[rlefever]

Seems that where I am on the Vagrant box is that I cannot talk to the VM to start the Docker containers. It seems the box.ovf says the vmname and uuid are different that what are reported running by 'VBoxManage list runningvms'. The box.ovf says vmname is playground_<numbers>_<numbers>. The running one is <user>_<numbers>_<numbers>.

…

Alas, I have never tried running with a vagrant host separate from the docker host. Without a couple of hours to sit down with your computer and explore which network connections and pings do and don�t work between the different hosts, I doubt if I could make any headway in figuring out how to get the different hosts talking successfully. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #16 (comment)

[rlefever]

I think I have discovered the reason Option A (Vagrant Host) of the playground would not work for me. It seems the VirtualBox VM requires AMD-V support and I am running an Intel CPU. The VM therefore fails to start is why the SSH connection never works. I cannot find a way around that. Any ideas on where to start to get networking operational on the Option B (Docker Host)? I am not running boot2docker, any suggestions on what to change in the launch.sh? Seems to me the place to start. Thanks

…

Alas, I have never tried running with a vagrant host separate from the docker host. Without a couple of hours to sit down with your computer and explore which network connections and pings do and don�t work between the different hosts, I doubt if I could make any headway in figuring out how to get the different hosts talking successfully. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #16 (comment)

[rlefever]

On the Option B docker only setup I have used https://success.docker.com/article/troubleshooting-container-networking to determine which hosts can or cannot talk to each other. Seems the endpoints cannot talk to their respective 'router's (modemA, modemB, and example). I have also found that the iptables -L command returns: iptables v.1.8.3 (legacy): can't initialize iptables table 'filter': Permission denied (you must be root) Perhaps iptables or your kernel needs to be upgraded When I issue whoami it returns root so I don't think that is the issue. The host, Ubuntu 16.04, says the same message except v1.6.0 when I try to iptables -L as a non-root user. Could it be a conflict of the iptables version or is there a module not loading on the host or container side? check if modules are loaded on the modemA container lsmod | grep ip ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables x_tables nf_nat nf_conntrak multipath Any thoughts? My hopes are that you have this running and can/will compare. Thanks.

…

Alas, I have never tried running with a vagrant host separate from the docker host. Without a couple of hours to sit down with your computer and explore which network connections and pings do and don�t work between the different hosts, I doubt if I could make any headway in figuring out how to get the different hosts talking successfully. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #16 (comment)

[brandon-rhodes]

I’ve just gone into the requirements.txt files and added the exact
version numbers of each package that are installed in the official
playground image. This means that folks building the playground
themselves (a) should no longer have errors because newer versions of
some packages require a more recent version of pip, and (b) that the
home-made playground they come out with should work the same inside as
the official playground image.

@zseusz — Apologies that I didn’t answer your question last year, I must
have missed it. Alas, I don’t use Windows, and so I’m not sure if
Windows machines require any extra steps beyond the usual vagrant init, vagrant up, and vagrant ssh steps.

@rlefever — First, I have edited the README instructions for folks
building the playground themselves, so it correctly specifies the SSH
configuration file that will allow login to h1 through h4 without
running into any problems with hostnames or port numbers or needing a
password. (In the official playground image that file gets installed as
the ~/.ssh/config file itself, so no extra argument is needed for
folks running the official image.)

Second, I spent today launching the playground myself on a modern Ubuntu
box — your hope that “you have this running” is, alas, mistaken; I have
been using the official image for years and only today had time to try
out the old “build.sh” and “launch.sh” scripts on a modern machine. I
found that modern Linux + Ubuntu + Docker no longer allows packets to
flow between across the virtual bridges that the script sets up between
the virtual hosts, so I have added “iptables” commands to “launch.sh”
that make the packets start flowing for me. Try them out yourself, and
see if they make “ping” and other commands start working successfully!

Third, you typically can’t run iptables from inside the containers,
because the main host retains the right to impose iptables rules; always
run iptables from outside the various virtual hosts.

Good luck! Let me know what happens.

[rlefever]

You are awesome! Option B (Building the Playground) works like a champ. Thank you so much for taking the time to make it work.

…

I�ve just gone into the `requirements.txt` files and added the exact version numbers of each package that are installed in the official playground image. This means that folks building the playground themselves (a) should no longer have errors because newer versions of some packages require a more recent version of pip, and (b) that the home-made playground they come out with should work the same inside as the official playground image. @zseusz � Apologies that I didn�t answer your question last year, I must have missed it. Alas, I don�t use Windows, and so I�m not sure if Windows machines require any extra steps beyond the usual `vagrant init`, `vagrant up`, and `vagrant ssh` steps. @rlefever � First, I have edited the README instructions for folks building the playground themselves, so it correctly specifies the SSH configuration file that will allow login to `h1` through `h4` without running into any problems with hostnames or port numbers or needing a password. (In the official playground image that file gets installed as the `~/.ssh/config` file itself, so no extra argument is needed for folks running the official image.) Second, I spent today launching the playground myself on a modern Ubuntu box � your hope that �you have this running� is, alas, mistaken; I have been using the official image for years and only today had time to try out the old �build.sh� and �launch.sh� scripts on a modern machine. I found that modern Linux + Ubuntu + Docker no longer allows packets to flow between across the virtual bridges that the script sets up between the virtual hosts, so I have added �iptables� commands to �launch.sh� that make the packets start flowing for me. Try them out yourself, and see if they make �ping� and other commands start working successfully! Third, you typically can�t run iptables from inside the containers, because the main host retains the right to impose iptables rules; always run iptables from outside the various virtual hosts. Good luck! Let me know what happens. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #16 (comment)

[brandon-rhodes]

I'm glad the fix got things working for you again, and that you're able to learn more about networking thanks to the example network!