Přeložit do češtiny pomocí Google Translate ...

Labs: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14.

Table of contents

This lab focuses on networking in Linux. We will start with the basic network utilities that would allow you to read your network configuration and debug connectivity issues.

We will also look at SSH port forwarding and talk about daemons (i.e. services such as SSH server or a web server).

This text assumes that you have basic knowledge of networking. Terms such as IP address, interface or port shall not be new for you. If you need a refresher, we have set-up a short page with a brief overview of networking. Feel free to skip or just skim through it for a quick refresh.

Basic network configuration

For the following text we will assume your machine is connected to the Internet (this includes your virtualized installation of Linux).

The basic command for setting network configuration is ip. If you run it with no parameters, you will see that the general syntax is the following.

ip [OPTIONS] OBJECT SUBCOMMAND

The OBJECT can be state of your interface (network card), routing table etc.

IP addresses

Probably the most useful one is ip addr.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 54:e1:ad:9f:db:36 brd ff:ff:ff:ff:ff:ff
3: wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 44:03:2c:7f:0f:76 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.105/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp58s0
       valid_lft 6209sec preferred_lft 6209sec
    inet6 fe80::9ba5:fc4b:96e1:f281/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
8: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff

It lists four interfaces (lo, enp0s31f6, wlp58s0 and vboxnet0) that are available on the machine. Your list will differ as well as the naming.

The name signifies interface type.

  • lo is the loopback device that will be always present. With loopback device, you can test network applications even without having a “real” connectivity.
  • enp0s31f6 (often also eth*) is a wired ethernet.
  • wlp58s0 is a wireless adapter.
  • vboxnet0 is a virtual network card used by VirtualBox when you create a virtual subnet for your virtual machines (you will probably not have this one there).

The state of the interface (up and running or not) is at the same line as the adapter name.

The link/ denotes the MAC address of the adapter. Lines inet specify the IP address assigned to this interface, including network. In this example, lo has 127.0.0.1/8 (obviously), enp0s31f6 is without an address (state DOWN) and wlp58s0 has address 192.168.0.105/24 (i.e., 192.168.0.105 with netmask 255.255.255.0).

Your addresses will be slightly different but typically you will see also a private address (behind a NAT) as you are probably connecting through a router to your ISP.

Routing table

Running ip route will show the routing table (i.e. through which interfaces are packets sent based on their destination address).

default via 192.168.0.1 dev wlp58s0 proto dhcp metric 600
192.168.0.0/24 dev wlp58s0 proto kernel scope link src 192.168.0.105 metric 600

Here the table says that default rule sends packets to 192.168.0.1 which serve as a gateway for this machine. The second rule specifies that packets to the 192.168.0.0/24 network are sent via the wireless interface.

Basic networking utilities

We will not substitute the networking courses here but mention three important and useful commands that could help you debug basic network-related problems.

ping (a.k.a. are you there?)

The ping command is the basic tool to determine whether a machine with given IP address is up (and responding to a network traffic).

The usage is extremely simple: you tell it the DNS name (or IP address) of the machine you wish to connect and it starts sending packets. Typically, the session looks like this.

ping d3s.mff.cuni.cz

PING d3s.mff.cuni.cz (195.113.20.60) 56(84) bytes of data.
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=1 ttl=50 time=16.8 ms
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=2 ttl=50 time=14.9 ms
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=3 ttl=50 time=15.0 ms
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=4 ttl=50 time=36.1 ms
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=5 ttl=50 time=14.3 ms
64 bytes from d3s.mff.cuni.cz (195.113.20.60): icmp_seq=6 ttl=50 time=15.0 ms
^C
--- d3s.mff.cuni.cz ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5271ms
rtt min/avg/max/mdev = 14.328/18.688/36.068/7.809 ms

By default, ping will send the ICMP packet forever, you can terminate it with Ctrl-C (notice that the utility has to have a signal handler to print the summary statistics at the end).

If the machine is not reachable (that might mean a problem anywhere on the route or on the destination machine itself), you will get behavior like in the following examples.

ping: connect: Network is unreachable

PING 195.113.20.60 (195.113.20.60) 56(84) bytes of data.
From 192.168.88.1 icmp_seq=1 Destination Net Prohibited
From 192.168.88.1 icmp_seq=2 Destination Net Prohibited
From 192.168.88.1 icmp_seq=3 Destination Net Prohibited
From 192.168.88.1 icmp_seq=4 Destination Net Prohibited
^C
--- 195.113.20.60 ping statistics ---
5 packets transmitted, 0 received, +4 errors, 100% packet loss, time 4042ms
pipe 3

ping is the basic tool if you suddenly loose a connection to some server. Ping the destination server and ping some well known server too If the packets are going through, you know that the problem is on a different layer. If only packets to the well-known server gets through, the problem is probably with the server in question. If both fails, your network is probably down.

traceroute (a.k.a. the path is the goal)

Sometimes, it can be handy to know the precise path, which the packets travel. For this kind of task, we can use traceroute.

Similarly to ping, we need to just specify the destination.

traceroute 1.1.1.1

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  _gateway (10.16.2.1)  2.043 ms  1.975 ms  1.948 ms
 2  10.17.0.1 (10.17.0.1)  1.956 ms  1.971 ms  1.961 ms
 3  gw.sh.cvut.cz (147.32.30.1)  1.947 ms  1.973 ms  1.977 ms
 4  r1sh-sush.net.cvut.cz (147.32.252.238)  2.087 ms  2.262 ms  2.527 ms
 5  r1kn-konv.net.cvut.cz (147.32.252.65)  1.856 ms  1.849 ms  1.847 ms
 6  kn-de.net.cvut.cz (147.32.252.57)  1.840 ms  1.029 ms  0.983 ms
 7  195.113.144.172 (195.113.144.172)  1.894 ms  1.900 ms  1.885 ms
 8  195.113.235.99 (195.113.235.99)  4.793 ms  4.748 ms  4.723 ms
 9  nix4.cloudflare.com (91.210.16.171)  2.264 ms  2.807 ms  2.814 ms
10  one.one.one.one (1.1.1.1)  1.883 ms  1.800 ms  1.834 ms

The first column corresponds to the hop count. The second column represents the address of that hop and after that, you see three space-separated times in milliseconds. traceroute command sends three packets to the hop and each of the time refers to the time taken by the packet to reach the hop. So from the foregoing output we can see that the packages visited 10 hops on its way between the local computer and the destination.

This tool is especial useful, when you have network troubles and you are not sure where the issue is.

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  10.21.20.2 (10.21.20.2)  0.798 ms  0.588 ms  0.699 ms
 2  10.21.5.1 (10.21.5.1)  0.593 ms  0.506 ms  0.611 ms
 3  192.168.88.1 (192.168.88.1)  0.742 ms  0.637 ms  0.534 ms
 4  10.180.2.113 (10.180.2.113)  1.696 ms  4.106 ms  1.483 ms
 5  46.29.224.17 (46.29.224.17)  14.343 ms  13.749 ms  13.806 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

From this log we can see that the last visited hop was 46.29.224.17, so we can focus our attention to this network element.

telnet (a.k.a. text protocols to the rescue)

telnet is a simple tool if you need to communicate with any server (that uses text-based protocol) manually. Typically, that could be a web server or an SMTP one. Although with the SSL being omnipresent, the usefulness of telnet is decreasing (on the other hand, cURL works in many cases even better).

We will try to communicate with the webserver manually. Recall that HTTP is a text protocol so it shall not be that difficult. We will use lab.d3s.mff.cuni.cz as the machine has simpler configuration than, for example, d3s.mff.cuni.cz.

Execute the following, 80 denotes the well-known HTTP port.

telnet lab.d3s.mff.cuni.cz 80

Note that we are connecting over plain HTTP. For HTTPS we would be using port 443 and we would need some kind of SSL wrapper around our communication.

After the welcome message, type the standard HTTP GET request.

GET / HTTP/1.0

Note that the second line is empty (i.e. hit Enter twice).

You should get back headers and the HTML code of the index page. Note that you have received a complete response, including the headers.

nmap (a.k.a. let me scan your network)

Warning: nmap is a very powerful tool. Unfortunately, even an innocent – but repeated – usage could be easily misinterpreted as a malicious scan of vulnerabilities that are susceptible for attack. Use this tool with care and experiment in your home network. Reckless scanning of the university network can actually ban your machine from connecting at all for quite some time.

nmap is the basic network scanning tool. If you want to know which network services are running on a machine you can try connecting to all of its ports to check which are opened.

And that is one of the functions that nmap provides.

Try first scanning your loopback device for internal services running on your machine.

nmap localhost

The result could look like this (the machine has a print server and a proxy HTTP server).

Starting Nmap 7.91 ( https://nmap.org ) at 2021-05-04 16:38 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00011s latency).
Other addresses for localhost (not scanned): ::1
rDNS record for 127.0.0.1: localhost.localdomain
Not shown: 998 closed ports
PORT     STATE SERVICE
631/tcp  open  ipp
3128/tcp open  squid-http

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds

If you want to see more information, you can try adding -A switch.

nmap -A localhost

And if you run it under root (i.e. sudo nmap -A localhost) nmap can try to detect the remote operating system too.

By default, nmap scans only first few ports. You can specify a different range with the -p option.

nmap -p1-65535 localhost

This instructs nmap to scan all TCP ports (-p1-65535) on localhost.

Warning Again: do not scan like this machines on the university network.

As an exercise, which web server is used on our GitLab? And which one is on our University website? Solution.

SSH port forwarding

Generally, a machine should disclose as little information about itself as possible for security reasons. Therefore, most ports – whether used or unused – are hidden behind a firewall controlling access to them.

Sometimes, a service may be enabled only on the loopback device. That way, only a local user (i.e., one having a SSH-enabled account) can access it.

As an example, you will find that on port 8080 on linux.ms.mff.cuni.cz is a web server. That webserver is not available when you try to access it as linux.ms.mff.cuni.cz but accessing it locally (when logged to linux.ms.mff.cuni.cz) works.

curl http://linux.ms.mff.cuni.cz:8080                # Fails
ssh linux.ms.mff.cuni.cz curl --silent http://localhost:8080  # Works

SSH allows you to create a secure tunnel and forward such ports to your machine. In essence, you will connect to a loopback device on your machine and SSH will forward that communication to the remote server and back, effectively making the remote port accessible.

The following command will make port 8888 behave like port 8080 on the remote machine. The 127.0.0.1 part refers to the loopback on the remote server.

ssh -L 8888:127.0.0.1:8080 -N linux.ms.mff.cuni.cz

The -N makes this connection usable only for forwarding – use Ctrl-C to terminate it (without it, you will log-in to the remote machine too).

Open http://localhost:8888 in your browser to check that you can see the same content as with the ssh linux.ms.mff.cuni.cz curl http://localhost:8080 command above.

Reverse port forwarding

SSH allows to create also a so-called reverse forward.

It basically allows you to open a connection from the remote server to your local machine. Practically, you can setup a reverse port forward from your desktop you have at home to a machine in Rotunda, for example, and then use this reverse forward to connect from Rotunda back to your desktop.

This feature will work even if the machine is behind NAT, i.e. the situation where direct connection from the outside is not possible.

The following command sets the reverse port forward such that connecting to port 2222 on the remote machine (on loopback, i.e. on 127.0.0.1 or localhost) will be treated as connecting to port 22 on the local machine.

ssh -N -R 2222:127.0.0.1:22 u-plN.ms.mff.cuni.cz

When trying this, ensure your sshd daemon is running (see section below for explanation why sudo systemctl start sshd is needed) and use a different port than 2222 to prevent collisions.

In order to connect to your desktop via this port forward, you have to do so from rotunda lab via ssh -p 2222 your-desktop-login@127.0.0.1 as the connection is only bound to the loopback interface, not to the actual network adapter available to lab computers (and if you tried to bind the port forward to the public IP of the machine in rotunda, you would probably fail because of tight security of machines in rotunda lab).

Network Manager

There are several ways how to configure networking in Linux. Server admins often prefer to use bare ip command; on desktops most distributions today use NetworkManager and we will show it here too. Note that ArchLinux Wiki page about NetworkManager contains a lot of information too.

NetworkManager has a GUI (you probably used its applet without knowing about it), a TUI (which can be run with nmtui) and finally a CLI. We will (for obvious reasons) focus on the command-line interface here. Without parameters, nmcli will display information about current connections.

wlp58s0: connected to TP-Link_1CE4
        "Intel 8265 / 8275"
        wifi (iwlwifi), 44:03:2C:7F:0F:76, hw, mtu 1500
        ip4 default
        inet4 192.168.0.105/24
        route4 0.0.0.0/0
        route4 192.168.0.0/24
        inet6 fe80::9ba5:fc4b:96e1:f281/64
        route6 fe80::/64
        route6 ff00::/8

p2p-dev-wlp58s0: disconnected
        "p2p-dev-wlp58s0"
        wifi-p2p, hw

enp0s31f6: unavailable
        "Intel Ethernet"
        ethernet (e1000e), 54:E1:AD:9F:DB:36, hw, mtu 1500

vboxnet0: unmanaged
        "vboxnet0"
        ethernet (vboxnet), 0A:00:27:00:00:00, hw, mtu 1500

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 192.168.0.1 8.8.8.8
        interface: wlp58s0

...

Compare the above with the output of ip addr. Notice that NetworkManager explicitly states the routes by default and also informs you that some interfaces are not controlled by it (here, lo or vboxnet0).

Changing IP configuration

While most networks offer DHCP (at least those you will connect to with your desktop), sometimes you need to setup IP addresses manually.

A practical situation is when you need to connect two machines temporarily, e.g. to transfer a large file over a wired connection.

The only thing you need to decide on is which network you will create. Do not use the same one as your home router uses; our favourite selection is 192.168.177.0/24.

Assuming the name from above, following command adds a connection named wired-static-temp on enp0s31f6.

sudo nmcli connection add \
    con-name wired-static-temp \
    ifname enp0s31f6 \
    type ethernet \
    ip4 192.168.177.201/24

It is often necessary to bring this connection up with the following command.

sudo nmcli connection up wired-static-temp

Follow the same procedure on the second host but use a different address (e.g., .202). You should be able to ping the other machine via the following command.

ping 192.168.177.201

To demonstrate how ping behaves when the connection goes down, you can try unplugging the wire, or (in software way the same) execute.

sudo nmcli connection down wired-static-temp

Services (and daemons too)

In the context of an operating system, the term service usually refers to any program that is running on the background (typically, no GUI, stdin from /dev/null) and provides some kind of service to other programs.

A typical example can be a printing service that takes care of printer discovery and provides end-user applications list of printers (i.e. the end-user applications do not need to make the discovery themselves). Another example is a web server: it provides files over the HTTP protocol to web browsers.

In the world of Unix systems, such programs are often called daemons (this probably comes from ancient Greek mythology where daemon is a being working in the background), traditionally such programs end with letter d. For example, the popular Apache web server is actually launched as a program httpd and the SSH server is running as sshd.

Daemons operate differently from normal programs. When started, they read their configuration (typically from a file under /etc/), start and listen for requests (imagine a web server listening on port 80). Changing their behavior is usually done by changing their configuration file and restarting them. Because they are started in background, they do not have access to an interactive stdin and the restart (or shutdown) is performed via signals.

Because the need to restart a running daemon is quite common (and sending signals is not very straightforward as you need to know the PID), there are special programs that are able to find the PID for you and send the right signal. We can call them control scripts and for some daemons you will find files daemond (with the actual daemon code) and daemonctl for controlling it.

Unified daemon control

Because the above principles are virtually the same for all daemons, there usually exists a set of scripts unifying this behavior. So, instead of calling a specific daemonctl, the distribution will typically offer a special command where you can control any daemon. Usually, one will use something along the following lines.

service [start|stop|restart] daemon

Currently, the most often used software for this task is called systemd.

Systemd

Systemd is today one of the most widely used system service management tools in Linux.

We will not go into detail and just review the two most important commands: systemctl and journalctl.

Notice how systemd itself is a daemon that distinguishes systemd and systemctl.

Starting and stopping a service

Starting a service with systemd is very simple. The following commands starts sshd: the SSH server.

sudo systemctl start sshd

If the service was already running, nothing will happen.

Check that you can now connect to your machine via the following command.

ssh your-login@localhost

To check the state of the service, the status subcommand is used (note that status can be run without sudo but may display less information).

sudo systemctl status sshd

● sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2021-03-01 14:31:40 CET; 2 months 3 days ago
   Main PID: 560 (sshd)
      Tasks: 1 (limit: 9230)
     Memory: 900.0K
        CPU: 16ms
     CGroup: /system.slice/sshd.service
             └─560 sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups

Warning: journal has been rotated since unit was started, output may be incomplete.

We see that the service is running, most items shall be self explanatory. The /usr/lib/systemd/system/sshd.service file contains service configuration itself (i.e. how to restart the service etc.), not the actual configuration of SSH daemon that is inside /etc/ssh.

It is safer to stop SSH daemon on your laptop if you are not going to use it.

sudo systemctl stop sshd

Enabling and disabling a service

If you wish to start the service with each boot, you can enable the service. Systemd will take care of proper ordering of the individual services (so that SSH server is started only when network is initialized etc.).

sudo systemctl enable sshd

If you no longer wish to have SSH daemon started by default, call the command with disable instead.

Note that both enable and disable do not change the current state of the service: you still need to start/stop it as needed if you do not want to wait for reboot.

Logs

Most services provide so-called logs. There they record every significant action they performed.

For example, a web server typically logs which pages it served together with information about the client.

Usually, for each service you can specify how detailed the logging shall be. Debugging a configuration issue requires a more detailed level, on a production server you usually limit the amount of logged information to minimum for performance reasons.

Usually the log files are stored inside /var/log, for some services you can inspect them with journalctl: the logging (journaling) subsystem of systemd. Note that system of logging is quite fragmented as different services use different means of logging. Slowly, unification via journald is taking place but some daemons will probably forever remain with their format for compatibility reasons.

Following command shows logs for the SSH daemon.

journalctl -u sshd

More …

If you are interested in this topic, please, consult the relevant manual pages. Take these few paragraphs as a very brief introduction to the topic that allows you basic management of your system.

Graded tasks

Your own SSH server (30 points)

In this task we want from you to try running SSH server on your own machine (it can be a virtualized installation too). Because most of your machines are behind NAT, we will check that via reverse port forward on linux.ms.mff.cuni.cz.

It is not necessary to run the SSH server for a long time (i.e. no need for systemctl enable, simple start and stop later is sufficient). We will also not actually log-in on your machine but only check that your SSH server is listening (i.e. accepting connections).

Recall that you really do not have to worry about security of your machine. The connection is hidden inside the SSH tunnel so it is rather difficult to even learn about its presence at all. The reverse connection will be active only when your session is active, so it can be literally for few seconds only. It will be thus only visible to other users on linux.ms.mff.cuni.cz. We strongly warn you against any attempt to try to access machines of your colleagues or any other form of malicious action with respect to this task.

To prevent collision of port numbers, run the following on linux.ms.mff.cuni.cz to learn the port number you are supposed to use.

nswi177-reverse-port id

To actually complete the task, set-up the reverse port forward on that port to your own SSH server. Then execute with parameter test to check the connection (it will try to connect to the server but without trying any form of authentication). We will call the ssh-keyscan program for that.

nswi177-reverse-port test

If the script prints the following message, you are good to go.

Looks good, there is SSH daemon at the other side.

Then execute with submit and follow the instructions on the screen. Note that for the actual submission, you will have only one try (so make sure test works first).

nswi177-reverse-port submit

Note that you check the SSH access by actually logging back to your machine prior running the above commands.

This task is not checked by your GitLab pipeline.

11/port_forward.txt (20 points)

There is (yet) another web server running on linux.ms.mff.cuni.cz on port 8177.

This webserver is not accessible from the outside but only locally.

Use your SSH connection to make this server accessible on your local machine on port 8011. Then copy the designated text from http://127.0.0.1:8011/?student=LOGIN (replace LOGIN with your SIS/GitLab username) into your GitLab submission repository.

The copied text must include your username too.

11/ip_addr.json (30 points)

First, a bit of a context.

Because ping and ip addr are the starting points for virtually any debugging of network configuration, we want you to be able to read the output of ip addr. We have set-up a virtual machine connected to linux.ms.mff.cuni.cz and in this task you will read IP configuration. The task is not about creating a script but about reading the information manually.

For technical reasons, you will not have direct access to the machine but instead we have set-up a forced command wrapper on linux.ms.mff.cuni.cz that will print the configuration for you.

The actual task description starts here.

Use the private pair of the key you have uploaded as part of 06 and connect as user lab11 to linux.ms.mff.cuni.cz. This will print for you a result of ip addr of a certain machine.

Read this configuration and create a simple JSON with the following structure. The JSON would be a dictionary (mapping) where the key would be the network interface name and its value would be its IP address (IPv4 only), including network specification (e.g. 192.168.1.177/18). If the network is down (i.e., no IP address assigned), store the string "none".

As an example, the output from this lab would be stored in the following manner.

{
    "lo": "127.0.0.1/8",
    "enp0s31f6": "none",
    "wlp58s0": "192.168.0.105/24",
    "vboxnet0": "none"
}

The tests will check the basic format of your answer, for obvious reasons they do not compare your answers with the actual correct solution.

Regarding your public keys: at the moment of publication of this task we have added keys that were available in your repositories. If you have skipped this task, feel free to upload your key even after deadline.

We will try to update the list of authorized keys regularly.

Do not postpone this task to the last moment – we cannot guarantee that we will be able to update the configuration more often than every day.

11/ws.txt (20 points)

UPDATE Seems that some of you already experienced an IP ban for the CUNI network. Please, execute nmap on linux.ms.mff.cuni.cz (the hidden server is exposed on localhost too) to prevent such ban. Note that we expect you would combine nmap with telnet to determine the manufacturer.

Find out on which (non-standard) port is listening a web server on linux.ms.mff.cuni.cz. And what kind (manufacturer) of web server it is?

Store the answer in a plain text file in the following format.

PORT:MANUFACTURER

We expect you would use nmap here. Use it carefully (recall the warning above).

For example, the above mentioned web server on port 8080 would result in the following file.

8080:nginx

Note that neither the ports 8080 nor 80 (standard web server port) are correct answers.

Do not forget to query the server to verify it is the right one. You will recognize the right one immediatelly.

Do not forget to check that on the given port is really a webserver (i.e. you shall see a HTML page in your browser).

As a hint, the correct server is not Nginx and not Apache.

Deadline: May 31, AoE

Solutions submitted after the deadline will not be accepted.

Note that at the time of the deadline we will download the contents of your project and start the evaluation. Anything uploaded/modified later on will not be taken into account!

Note that we will be looking only at your master branch (unless explicitly specified otherwise), do not forget to merge from other branches if you are using them.

Changelog

2021-05-11: Warning about IP ban for ws.txt task.