Configure dns to provide internet to clients

d78ui98 commented 6 years ago

I did a basic internet connection test by pinging google dns server. It worked. But unable to browse internet from client. This means it is a problem with /etc/resolv.conf. But editing it directly is not recommended. So we have to delete old one and create new one dynamically.

This screenshot describes the problem - https://preview.ibb.co/fU0Gu8/9ce797c2_6812_4767_80a0_9a8e98728381.jpg

d78ui98 commented 6 years ago

I have commits ready for fixing this issue. will push changes after https://github.com/docker-scripts/dev--LTSP/pull/81 gets merged.

akash0x53 commented 6 years ago

Instead of hardcoding netmask and ip in Vagrantfile, you should try auto_config option in Vagrantfile. It will configure everything for you.

dashohoxha commented 6 years ago

Akash, if you check the diagrams here: https://github.com/docker-scripts/dev--LTSP/wiki/LTSP-Modes-of-Operation you will notice that:

The LTSP server in standalone mode should have only 2 network interfaces, one of them bridged.
The LTSP server in normal mode should have only 1 network interface, bridged to the LAN, with the right IP for communicating with the other computers in the LAN.
The DHCP server should have only 2 network interfaces.
The LTSP client should have only 1 network interface.

I am not sure whether auto_config does the right thing in all these cases.

akash0x53 commented 6 years ago

Agreed. But in testing i found config.vm.network "public_network", ip: LAN_IP, netmask: "255.255.255.0", bridge: LAN_IF this will set the server ip to LAP_IP irrespective of mode of operation. In case of Normal mode, If user sets LAN_IP=192.168.1.10 and that ip already assigned to other machine then there will be problems.

So, we can use auto_config for normal_mode and set IP manually for standalone mode. Any thoughts?

dashohoxha commented 6 years ago

So, we can use auto_config for normal_mode and set IP manually for standalone mode.

This seems like a good idea.

However, if the IP of the ltsp-server appears on some configuration files (for example on /etc/dnsmasq.d/ltsp-server-dnsmasq.conf), we have to make sure that this configuration file is changed (and the corresponding service restarted) each time that the server is booted, since auto_config may change the IP of the server from time to time. This is why I have recommended a fixed IP for the server (on this blog: http://dashohoxha.fs.al/ltsp-pnp/).

There may be other problems as well if the IP of the server changes. For example the configuration of epoptes clients may contain the IP of the server, and this configuration maybe changes only when the client image is created. However I am not sure about this, it has to be tested.

If we use a fixed IP (like we do now), the user has to make sure that this IP is not being used by some other computers on the LAN (for example it is out of the range of the DHCP server). However this has to be explained clearly on the docs and instructions. So, auto_config is better, if we can make it work properly.

d78ui98 commented 6 years ago

However, if the IP of the ltsp-server appears on some configuration files (for example on /etc/dnsmasq.d/ltsp-server-dnsmasq.conf), we have to make sure that this configuration file is changed

Yes this would be a problem. While using a fixed IP do not use a IP address that is already assigned. I think this part should be understood by a normal vagrant user. As they have also given it in the warning section of documentation here- https://www.vagrantup.com/docs/networking/private_network.html#static-ip

Maybe in the readme file we should mention that users should first try to ping LAN_IP in the settings.sh to make sure it is not already being used.

dashohoxha commented 6 years ago

I think this part should be understood by a normal vagrant user. As they have also given it in the warning section of documentation here- https://www.vagrantup.com/docs/networking/private_network.html#static-ip

This software is for teachers, not for vagrant users. So don't assume that they know everything (or anything) about vagrant. I am an expert (in many things but not in vagrant), I have used vagrant many times, but I have not read all the docs of vagrant and I don't know everything about vagrant.

In general, don't expect the users to know everything or to read every docs. I hate when they tell me to read tons of docs, when they could could just tell me a couple of commands to accomplish the task. Somebody can be an expert on something, or on a lot of things, but cannot be an expert on everything.

Maybe in the readme file we should mention that users should first try to ping LAN_IP in the settings.sh to make sure it is not already being used.

Not "maybe", but it "has to" mention something about that. However, this solution (with ping) is not a good one. If they ping and the IP is not assigned today, this does not guarantee that it will be unassigned tomorrow as well. This is not a problem for the computers of the classroom because they will be booted after the server, but there may be other computers on the LAN that do not boot from network (for example computers of the administration, printers, etc.).

d78ui98 commented 6 years ago

Okay. Good point.

So, we can use auto_config for normal_mode and set IP manually for standalone mode.

This can be simply done by using if else statement in ruby. But we need to find a way to load the IP address in install.sh to cofigure /etc/dnsmasq.d/ltsp-server-dnsmasq.conf. Then we need to make changes in test.sh and dhcp server to make sure everything works as expected. working on this.

d78ui98 commented 6 years ago

Should I push changes in https://github.com/docker-scripts/dev--LTSP/pull/84 or create another PR?

d78ui98 commented 6 years ago

Issues with auto_config

We cannot mention the interface name. This would halt testing with test.sh by prompting for which interface to use.
There is not flexibility to switch virtual interface
There is also no flexiblity to switch network
client.sh also fails. We have to manually add the interface connected All this suggests auto_config is creating more problems then it is solving.
Solution

Another script to check which ip address is available and add that IP to settings.sh. Something like this

for i in {1..100}; do
IP=192.168.1.$i
pin=$(ping -c 1 $IP | grep bytes | wc -l)
if [[ $pin -eq 1 ]]; then
    sed -i settings.sh -e "/LAN_IP=""/ c LAN_IP=\"$IP\""
    exit 1
fi    
done

@dashohoxha @akash0x53 Do let me know if you have a better solution in mind.

akash0x53 commented 6 years ago

@d78ui98 You can specify interface to use for bridging. config.vm.network "public_network", auto_config: true, bridge: LAN_IF and set the interface in settings.sh, this works perfectly fine. Vagrant is basically used for automation purpose so they will not miss this feature :)

dashohoxha commented 6 years ago

I think that @akash0x53 is right. I have never used this feature, but I guess that auto_config: true makes it ask for an IP from a DHCP server in the network. But you can still specify the interface with bridge: LAN_IF.

d78ui98 commented 6 years ago

Yes he is. But even after implementing auto_config correctly internet on client does not work. As dnsmasq is not configured properly for linuxmin19

dashohoxha commented 6 years ago

As dnsmasq is not configured properly for linuxmin19

You are wrong about this. See this comment: https://github.com/docker-scripts/dev--LTSP/pull/84#discussion_r202701750

d78ui98 commented 6 years ago

Internet now works on client. The issue is now fixed in the new version of LTSP.

docker-scripts-archived / dev--LTSP

Configure dns to provide internet to clients #83

Issues with auto_config

Solution