curl: (28) Resolving timed out after 5515 milliseconds

If you encounter an error like curl: (28) Resolving timed out after 5515 milliseconds

[user1@hpc-node1 ~]# curl -fsS https://dlang.org/install.sh | bash -s dmd
curl: (28) Resolving timed out after 5515 milliseconds
curl: (28) Resolving timed out after 5512 milliseconds
curl: (28) Resolving timed out after 5514 milliseconds
curl: (28) Resolving timed out after 5513 milliseconds
curl: (28) Resolving timed out after 5514 milliseconds
curl: (28) Resolving timed out after 5514 milliseconds
curl: (28) Resolving timed out after 5515 milliseconds
curl: (28) Resolving timed out after 5514 milliseconds
curl: (28) Resolving timed out after 5515 milliseconds
curl: (28) Resolving timed out after 5515 milliseconds

It is likely a DNS Lookup Resolution Issue. You might want to take a look at /etc/resolv.conf . you may want to change the DNS to another nameserver that resolves faster like one from Google Public DNS IP Addresses

# Generated by NetworkManager
nameserver 192.168.0.1

To another nameserver, maybe like Google Public DNS IP Addresses. You can find more information at https://developers.google.com/speed/public-dns/docs/using

# Generated by NetworkManager
nameserver 8.8.8.8
nameserver 8.8.4.4

Apache Log4j Zero-Day Vulnerability

Taken from https://www.lunasec.io/docs/blog/log4j-zero-day/

What is Apache Log4j Zero-Day Vulnerability?

Apache Log4j has a serious unauthenticated Remote Code Execution (RCE) vulnerability which was just disclosed. The exploit code for this has also been released, and the vulnerability is actively exploited in the wild. By crafting a special string that is passed to the application/service log via Log4j, attackers can execute arbitrary code loaded from remote servers. This can potentially lead to a complete compromise of the server.

What versions are vulnerable?

Any software using Apache Log4j (as a component) version between 2.0 and 2.14.1, inclusive.

What do I need to do?

A. Servers running custom Java application/services

  1. If your Log4j version is vulnerable, install the latest patched version log4j-2.15.0-rc2 available on GitHub at https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2.

B. Servers running Commercial off-the-shelf (COTS) products

  1. Plese refer to https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 for a list of advisories from the major vendors and follow the advisory.

How can I check if I have been hacked/compromised?

Check your applications’ log files for strings resembling “jndi:ldap”.

For more information

See https://www.lunasec.io/docs/blog/log4j-zero-day/