I have installed redis in my AWS server. I have followed this: https://www.digitalocean.com/community/tutorials/how-to-install-secure-redis-centos-7
$ systemctl start redis.service
$ systemctl enable redis
-> Created symlink /etc/systemd/system/multi-user.target.wants/redis.service → /usr/lib/systemd/system/redis.service.
$ systemctl status redis.service
● redis.service - Redis persistent key-value database
Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/redis.service.d
└─limit.conf
Active: failed (Result: exit-code) since Wed 2020-08-26 02:28:25 UTC; 10s ago
Main PID: 5012 (code=exited, status=1/FAILURE)
Aug 26 02:28:25 ip-xxx-xx-xx-xx.ap-southeast-2.compute.internal systemd[1]: Starting Redis persistent key-value database...
Aug 26 02:28:25 ip-xxx-xx-xx-xx.ap-southeast-2.compute.internal systemd[1]: Started Redis persistent key-value database.
Aug 26 02:28:25 ip-xxx-xx-xx-xx.ap-southeast-2.compute.internal systemd[1]: redis.service: Main process exited, code=exited, status=1/FAILURE
Aug 26 02:28:25 ip-xxx-xx-xx-xx.ap-southeast-2.compute.internal systemd[1]: redis.service: Failed with result 'exit-code'.
And when I check the /var/log/redis/redis.log this is what I see:
5012:C 26 Aug 2020 02:28:25.574 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
5012:C 26 Aug 2020 02:28:25.574 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=5012, just started
5012:C 26 Aug 2020 02:28:25.574 # Configuration loaded
5012:C 26 Aug 2020 02:28:25.574 * supervised by systemd, will signal readiness
5012:M 26 Aug 2020 02:28:25.575 # Could not create server TCP listening socket 127.0.0.1:6379: bind: Address already in use
And upon checking the ports:
$ netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 2812/redis-server *
tcp6 0 0 :::6379 :::* LISTEN 2812/redis-server *
This is showing the port 6379 is actually being used by redis-server.
So why cannot it start then?
Do I need to add any inbound/outbound rules in AWS? Please help.
UPDATE
ExecStart=/usr/bin/redis-server /etc/redis.conf --supervised systemd command on terminal returns bash: /etc/redis.conf: Permission denied. Looks like need to give right permission to /etc/redis.conf file.
$ ls -l /etc/redis.conf
-rw-r-----. 1 redis redis 62189 Aug 26 03:04 /etc/redis.conf
So what permission do I need to give here? Who should own this file?
I am trying to stop Clamav service in Linux, but I am not able to do that.
I have installed Clamav in a seperate directory.
When running below command:
$ systemctl stop clamav-daemon
I get this error message:
Warning: Stopping clamav-daemon.service, but it can still be activated by:
clamav-daemon.socket
When running:
$ systemctl status clamav-daemon
I get:
clamav-daemon.service - Clam AntiVirus userspace daemon
Loaded: loaded (/usr/lib/systemd/system/clamav-daemon.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2020-04-29 13:23:33 IST; 7s ago
Docs: man:clamd(8)
man:clamd.conf(5)
https://www.clamav.net/documents/
Main PID: 32213 (clamd)
Tasks: 1
CGroup: /system.slice/clamav-daemon.service
└─32213 /usr/local/sbin/clamd --foreground=true
Any help will be appreciated. Thanks.
When you are logged in as a normal user which can be understood by seeing the $ sign in your command, clamav won't stop. You need to perform the following command.
It will stop clamav for only logged-in session
$ sudo systemctl stop clamav-daemon
To see the status
$ sudo systemctl status clamav-daemon
It will return:
● clamav-daemon.service - Clam AntiVirus userspace daemon
Loaded: loaded (/lib/systemd/system/clamav-daemon.service; disabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/clamav-daemon.service.d
└─extend.conf
Active: inactive (dead)
Docs: man:clamd(8)
man:clamd.conf(5)
https://www.clamav.net/documents/
Aug 20 08:58:53 machine clamd[808]: Thu Aug 20 08:58:53 2020 -> HTML support enabled.
Aug 20 08:58:53 machine clamd[808]: Thu Aug 20 08:58:53 2020 -> XMLDOCS support enabled.
Aug 20 08:58:53 machine clamd[808]: Thu Aug 20 08:58:53 2020 -> HWP3 support enabled.
Aug 20 08:58:53 machine clamd[808]: Thu Aug 20 08:58:53 2020 -> Self checking every 3600 seconds.
Aug 20 09:58:53 machine clamd[808]: Thu Aug 20 09:58:53 2020 -> SelfCheck: Database status OK.
Aug 20 10:57:51 machine systemd[1]: Stopping Clam AntiVirus userspace daemon...
Aug 20 10:57:52 machine clamd[808]: Thu Aug 20 10:57:52 2020 -> --- Stopped at Thu Aug 20 10:57:52 >
Aug 20 10:57:52 machine clamd[808]: Thu Aug 20 10:57:52 2020 -> Socket file removed.
Aug 20 10:57:52 machine systemd[1]: clamav-daemon.service: Succeeded.
Aug 20 10:57:52 machine systemd[1]: Stopped Clam AntiVirus userspace daemon.
If you have created symbolic link of clamav daemon to start the program automatically when pc boot then you need to remove that link so that clamav shouldn't start automatically
$ sudo systemctl disable clamav-daemon
I'm trying to figure out why my HTTPS sites go down everytime my server's DHCP lease gets renewed.
It happens consistently, but HTTP sites continue to work just fine.
Restarting systemd-networkd brings the sites back, but until that happens the HTTPS sites are basically unreachable.
Any tips on where to look first?
The weird thing is these sites come back after the next DHCP lease renewal, then I lose connectivity on the next one, then it comes back, then I lose it, on and on.
This is what I see in syslog when it happens.
Apr 13 18:06:25 www-1 systemd-networkd[13973]: ens4: DHCP lease lost
Apr 13 18:06:25 www-1 systemd-networkd[13973]: ens4: DHCPv4 address 10.138.0.29/32 via 10.138.0.1
Apr 13 18:06:25 www-1 systemd-networkd[13973]: ens4: IPv6 successfully enabled
Apr 13 18:06:25 www-1 dbus-daemon[579]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.231' (uid=101 pid=13973 comm="/lib/systemd/systemd-networkd " label="unconfined")
Apr 13 18:06:25 www-1 systemd-networkd[13973]: ens4: Configured
Apr 13 18:06:25 www-1 systemd[1]: Starting Hostname Service...
Apr 13 18:06:25 www-1 dbus-daemon[579]: [system] Successfully activated service 'org.freedesktop.hostname1'
Apr 13 18:06:25 www-1 systemd[1]: Started Hostname Service.
Apr 13 18:06:25 www-1 systemd-hostnamed[17589]: Changed host name to 'www-1.us-west1-b.c.camp-fire-259800.internal'
This issue seems to be related to the following:
https://moss.sh/name-resolution-issue-systemd-resolved/
and
https://github.com/systemd/systemd/issues/9243
I've disabled systemd-resolved and am using a static /etc/resolv.conf copied from /run/systemd/resolve/resolv.conf
For internal DNS I'm using a private Google DNS Zone.
Thanks.
I installed Paraya 5(.193) on CentOS 7 server and the installation is a success. Since I aim to host a JEE website on it, I changed the default http port (of Payara) from 8080 to 80 (after disabling apache web server in order to keep the port 80 free). However, when I rerun Payara (with Port 80 as a default one), I get the following error -
-- Unit payara.service has failed.
--
-- The result is failed.
Nov 20 14:39:42 server1.gdfnow.org systemd[1]: Unit payara.service entered failed state.
Nov 20 14:39:42 server1.gdfnow.org systemd[1]: payara.service failed.
Nov 20 14:39:42 server1.gdfnow.org polkitd[541]: Unregistered Authentication Agent for unix-process:16831:1426530 (system bus name :1.137, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disc
Nov 20 14:39:44 server1.gdfnow.org unix_chkpwd[16992]: password check failed for user (root)
Nov 20 14:39:44 server1.gdfnow.org sshd[16990]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.88.201.58 user=root
Nov 20 14:39:44 server1.gdfnow.org sshd[16990]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Nov 20 14:39:46 server1.gdfnow.org sshd[16990]: Failed password for root from 115.88.201.58 port 51698 ssh2
Nov 20 14:39:46 server1.gdfnow.org sshd[16990]: Received disconnect from 115.88.201.58 port 51698:11: Bye Bye [preauth]
Nov 20 14:39:46 server1.gdfnow.org sshd[16990]: Disconnected from 115.88.201.58 port 51698 [preauth]
lines 1101-1128/1128 (END)
Any insight into this would be greatly appreciated.
PS - In the error log, I have no clue what this IP Address of 115.88.201.58. It is certainly not a Public IP of my client computer.
Thanks
I have the following file below and I would like to have a some regex expressions that could parse the file and give me an output like
139.162.78.135:41448 TLS Error: TLS handshake failed
139.162.78.135:41448 Connection reset, restarting
TLS Error: incoming packet authentication failed from [AF_INET]139.162.78.135:41448
139.162.78.135:41448 Fatal TLS Error
139.162.78.135:41448 VERIFY ERROR
139.162.78.135:41448 Bad encapsulated packet length
Note: this is for a program called fail2ban so that I can easily ban these ips that are trying to intrude my server.
I tried to parse the connection reset line like this \d+\.\d+\.\d+\.\d+:\d+ Connection reset, restarting But I don't know how to form another expression that can match the rest in one go.
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: 139.162.78.135:41448 Connection reset, restarting [0]
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: 139.162.78.135:41448 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]139.162.78.135:41828
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: 139.162.78.135:41828 WARNING: Bad encapsulated packet length from peer (18245), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: 139.162.78.135:41828 Connection reset, restarting [0]
Jun 19 04:27:29 Server ovpn-openvpn_tcp[856]: 139.162.78.135:41828 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 04:52:47 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]67.52.172.103:2577
Jun 19 04:52:47 Server ovpn-openvpn_tcp[856]: 67.52.172.103:2577 Connection reset, restarting [0]
Jun 19 04:52:47 Server ovpn-openvpn_tcp[856]: 67.52.172.103:2577 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 04:52:48 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]67.52.172.103:63975
Jun 19 04:52:48 Server ovpn-openvpn_tcp[856]: 67.52.172.103:63975 Connection reset, restarting [-1]
Jun 19 04:52:48 Server ovpn-openvpn_tcp[856]: 67.52.172.103:63975 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 04:56:52 Server ovpn-openvpn_udp[811]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]185.200.118.55:55292
Jun 19 09:17:44 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]154.16.133.10:13456
Jun 19 09:17:44 Server ovpn-openvpn_tcp[856]: 154.16.133.10:13456 Connection reset, restarting [-1]
Jun 19 09:17:44 Server ovpn-openvpn_tcp[856]: 154.16.133.10:13456 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 09:17:44 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]154.16.133.10:13769
Jun 19 09:17:59 Server ovpn-openvpn_tcp[856]: 154.16.133.10:13769 Connection reset, restarting [-1]
Jun 19 09:17:59 Server ovpn-openvpn_tcp[856]: 154.16.133.10:13769 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 09:19:25 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]184.105.139.70:50240
Jun 19 09:19:26 Server ovpn-openvpn_tcp[856]: 184.105.139.70:50240 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Jun 19 09:19:26 Server ovpn-openvpn_tcp[856]: 184.105.139.70:50240 Connection reset, restarting [0]
Jun 19 09:19:26 Server ovpn-openvpn_tcp[856]: 184.105.139.70:50240 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 14:11:58 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]223.146.71.5:59970
Jun 19 14:11:58 Server ovpn-openvpn_tcp[856]: 223.146.71.5:59970 Connection reset, restarting [0]
Jun 19 14:11:58 Server ovpn-openvpn_tcp[856]: 223.146.71.5:59970 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 14:11:59 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]223.146.71.5:60145
Jun 19 14:11:59 Server ovpn-openvpn_tcp[856]: 223.146.71.5:60145 WARNING: Bad encapsulated packet length from peer (21331), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Jun 19 14:11:59 Server ovpn-openvpn_tcp[856]: 223.146.71.5:60145 Connection reset, restarting [0]
Jun 19 14:11:59 Server ovpn-openvpn_tcp[856]: 223.146.71.5:60145 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 19 14:25:16 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]112.113.195.89:3079
Jun 19 14:26:16 Server ovpn-openvpn_tcp[856]: 112.113.195.89:3079 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jun 19 14:26:16 Server ovpn-openvpn_tcp[856]: 112.113.195.89:3079 TLS Error: TLS handshake failed
Jun 19 14:26:16 Server ovpn-openvpn_tcp[856]: 112.113.195.89:3079 Fatal TLS error (check_tls_errors_co), restarting
Jun 19 14:26:17 Server ovpn-openvpn_tcp[856]: 112.113.195.89:3079 SIGUSR1[soft,tls-error] received, client-instance restarting
Jun 19 16:27:19 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]213.202.230.144:2616
Jun 19 16:28:19 Server ovpn-openvpn_tcp[856]: 213.202.230.144:2616 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jun 19 16:28:19 Server ovpn-openvpn_tcp[856]: 213.202.230.144:2616 TLS Error: TLS handshake failed
Jun 19 16:28:19 Server ovpn-openvpn_tcp[856]: 213.202.230.144:2616 Fatal TLS error (check_tls_errors_co), restarting
Jun 19 16:28:19 Server ovpn-openvpn_tcp[856]: 213.202.230.144:2616 SIGUSR1[soft,tls-error] received, client-instance restarting
Jun 19 16:59:10 Server ovpn-openvpn_udp[811]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]185.200.118.41:40431
Jun 19 19:00:17 Server ovpn-openvpn_tcp[856]: TCP connection established with [AF_INET]178.73.215.171:23509
Jun 19 19:00:17 Server ovpn-openvpn_tcp[856]: 178.73.215.171:23509 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Jun 19 19:00:17 Server ovpn-openvpn_tcp[856]: 178.73.215.171:23509 Connection reset, restarting [0]
Jun 19 19:00:17 Server ovpn-openvpn_tcp[856]: 178.73.215.171:23509 SIGUSR1[soft,connection-reset] received, client-instance restarting
Use | to separate different options that you would like to capture. Since most of the options start with IP address, you could share your IP-matching regex among all of them.
Here is a regex with some "formatting" for easier understanding of what is going on; remove unnecessary spaces and end-of-line markers in the real regex:
\d+\.\d+\.\d+\.\d+:\d+
(?:
Connection reset, restarting
| TLS Error: TLS handshake failed
| Fatal TLS Error
| VERIFY ERROR
| Bad encapsulated packet length
)
| TLS Error: incoming packet authentication failed from [AF_INET]\d+\.\d+\.\d+\.\d+:\d+
Demo.
I think this problem may be divided into 2 parts:
What regex is used to represent the patterns, and
How to capture the IP address the OP is interested in.
Represent the patterns with the "or" and "group" operators
I think the multiple possibilities that follow the IP address may be handled by using the | operator and the ( ) grouping operator:
\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:\d{1,5} (Connection reset|TLS Error|Fatal TLS Error|VERIFY ERROR|Bad encapsulated packet length)
The more complicated case is the last possibility that the IP address appears the last, such as in the message
Jun 19 16:59:10 Server ovpn-openvpn_udp[811]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]185.200.118.41:40431
I think a quick and dirty solution might be to wrap this case with a pair of ()and the other cases with another pair of () and then | them together:
((TLS Error.+\[AF_INET\])(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:\d{1,5}))|(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:\d{1,5} (Connection reset|TLS Error|Fatal TLS Error|VERIFY ERROR|Bad encapsulated packet length))
With this regex, a user will be able to obtain the lines that contain the interesting patterns. This pattern includes both the IP address and the error info, and now with 1 further step, the user can extract the parts of interest (in this case, IP address and port number) ---
Return only the matched parts
To tell a regex that some part is not part of the match result (and are used only as delimiters, for example), you can declare them as "lookaheads" ( (?=blah blah) ). The following shows how a one-liner with grep extracts the intruders:
$ grep -P "((?=TLS Error.+\[AF_INET\])(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:\d{1,5}))|((\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:\d{1,5}) (?=Connection reset|TLS Error|Fatal TLS Error|VERIFY ERROR|Bad encapsulated packet length))" -o temp.txt
67.52.172.103:63975
154.16.133.10:13456
154.16.133.10:13769
184.105.139.70:50240
223.146.71.5:59970
223.146.71.5:60145
112.113.195.89:3079
112.113.195.89:3079
213.202.230.144:2616
213.202.230.144:2616
178.73.215.171:23509
The -o tells grep to return only the matched parts; -P tells grep to use PCRE regex rather than POSIX regex.
Hope this may be useful!