Apache TLS Handshakes Timeout after DHCP Lease Renewal - google-cloud-platform

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.

Related

Google Cloud VM SSH No supported authentication methods available

I have a Google cloud VM instance with Debian OS. I have hosted Wordpress sites. After upgrading OS version all was working fine and I was able to connect via SSH using 'Open SSH in browser' option.
Now I try to connect my VM instance using 'Open SSH in browser' it just keep retrying. I checked the serial console output but there is no error message. Please refer below
However, I am able to connect via FTP using same key but when I try to connect via SSH at that time facing the issue. I checked for port 22 for that instance and project and it's open
Below is the Last few lines of serial console log after I restarted the VM,
Dec 6 09:01:20 localhost sendmail[383]: Starting Mail Transport Agent (MTA): sendmail.
Dec 6 09:01:20 localhost systemd[1]: Started LSB: powerful, efficient, and scalable Mail Transport Agent.
Dec 6 09:01:21 localhost systemd[1]: Started MariaDB 10.3.31 database server.
Dec 6 09:01:21 localhost systemd[1]: Reached target Multi-User System.
Dec 6 09:01:21 localhost systemd[1]: Reached target Graphical InterfacDec 6 09:01:21 localhost systemd[1]: Startup finished in 4.063s (kernel) + 9.852s (userspace) = 13.915s.
Dec 6 09:01:21 localhost /etc/mysql/debian-start[567]: Upgrading MySQL tables if necessary.
Dec 6 09:01:21 localhost /etc/mysql/debian-start[570]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Dec 6 09:01:21 localhost /etc/mysql/debian-start[570]: Looking for 'mysql' as: /usr/bin/mysql
Dec 6 09:01:21 localhost /etc/mysql/debian-start[570]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Dec 6 09:01:21 localhost /etc/mysql/debian-start[570]: Version check failed. Got the following error when calling the 'mysql' command line client
Dec 6 09:01:21 localhost /etc/mysql/debian-start[570]: ERROR 1045 (28000): Access denied for user 'root'#'localhost' (using password: NO)
Dec 6 09:01:21 localhost /etc/mysql/debian-start[570]: FATAL ERROR: Upgrade failed
Dec 6 09:01:21 localhost /etc/mysql/debian-start[580]: Checking for insecure root accounts.
Dec 6 09:01:21 localhost debian-start[564]: ERROR 1045 (28000): Access denied for user 'root'#'localhost' (using password: NO)
Debian GNU/Linux 10 localhost ttyS0
localhost login: Dec 6 09:01:28 localhost systemd[1]: Stopping User Manager for UID 110...
Dec 6 09:01:28 localhost systemd[497]: Stopped target Default.
Dec 6 09:01:28 localhost systemd[497]: Stopped target Basic System.
Dec 6 09:01:28 localhost systemd[497]: Stopped target Timers.
Dec 6 09:01:28 localhost systemd[497]: Stopped target Paths.
Dec 6 09:01:28 localhost systemd[497]: Stopped target Sockets.
Dec 6 09:01:28 localhost systemd[497]: gpg-agent-browser.socket: Succeeded.
Dec 6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Dec 6 09:01:28 localhost systemd[497]: dirmngr.socket: Succeeded.
Dec 6 09:01:28 localhost systemd[497]: Closed GnuPG network certificate management daemon.
Dec 6 09:01:28 localhost systemd[497]: gpg-agent-ssh.socket: Succeeded.
Dec 6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Dec 6 09:01:28 localhost systemd[497]: gpg-agent.socket: Succeeded.
Dec 6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent and passphrase cache.
Dec 6 09:01:28 localhost systemd[497]: gpg-agent-extra.socket: Succeeded.
Dec 6 09:01:28 localhost systemd[497]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Dec 6 09:01:28 localhost systemd[497]: Reached target Shutdown.
Dec 6 09:01:28 localhost systemd[497]: systemd-exit.service: Succeeded.
Dec 6 09:01:28 localhost systemd[497]: Started Exit the Session.
Dec 6 09:01:28 localhost systemd[497]: Reached target Exit the Session.
Dec 6 09:01:28 localhost systemd[1]: user#110.service: Succeeded.
Dec 6 09:01:28 localhost systemd[1]: Stopped User Manager for UID 110.
Dec 6 09:01:28 localhost systemd[1]: Stopping User Runtime Directory /run/user/110...
Dec 6 09:01:28 localhost systemd[1]: run-user-110.mount: Succeeded.
Dec 6 09:01:28 localhost systemd[1]: user-runtime-dir#110.service: Succeeded.
Dec 6 09:01:28 localhost systemd[1]: Stopped User Runtime Directory /run/user/110.
Dec 6 09:01:28 localhost systemd[1]: Removed slice User Slice of UID 110.
Tried following solutions which I get from google search
Solution 1 : Using PuTTYGen & Putty
Generated key using PuttyGen and put the public key under meta data as well tried adding under instance. I have set enable-oslogin to FALSE.
But got the following error message.
Solution 2 : Using serial ports
When I tried to connect using diff serial ports it just stack at connection screen and I checked the console log for that serial port but it's blank.
Solution 3 : New Instance with disk image
Created image of current disk and then created new instance with that image. When I try to connect to that new instance then I am facing same issue.
Solution 4 : Use diff machine to setup CLI
I setup fresh Google Cloud CLI into a new machine and tried to connect but no success. Same error I faced.
Solution 5 : Increase Disk Space
Increased the disk space from 20GB to 35GB, but didn't work. Usually if there is disk space error the we get it into serial console log. But in my case there is no error message in serial console log.
Please help and let me know if any additional information is required.
Thanks

how to get Jenkins to be assessable from aws ec2 instance

so this is the problem I have installed open jdk 8 for jenkins. jenkins is insalled and running given
● jenkins.service - LSB: Start Jenkins at boot time
Loaded: loaded (/etc/init.d/jenkins; generated)
Active: active (exited) since Thu 2021-10-21 19:22:55 UTC; 20min ago
Docs: man:systemd-sysv-generator(8)
Process: 437 ExecStart=/etc/init.d/jenkins start (code=exited, status=0/SUCCESS)
Oct 21 19:22:52 ip-172-31-30-187 systemd[1]: Starting LSB: Start Jenkins at boot time...
Oct 21 19:22:53 ip-172-31-30-187 jenkins[437]: Correct java version found
Oct 21 19:22:53 ip-172-31-30-187 jenkins[437]: * Starting Jenkins Automation Server jenkins
Oct 21 19:22:54 ip-172-31-30-187 su[619]: (to jenkins) root on none
Oct 21 19:22:54 ip-172-31-30-187 su[619]: pam_unix(su-l:session): session opened for user jenkins by (u>
Oct 21 19:22:54 ip-172-31-30-187 su[619]: pam_unix(su-l:session): session closed for user jenkins
Oct 21 19:22:55 ip-172-31-30-187 jenkins[437]: ...done.
Oct 21 19:22:55 ip-172-31-30-187 systemd[1]: Started LSB: Start Jenkins at boot time.
however, using serverip:8080 brings up nothing
used this tutorial https://www.youtube.com/watch?v=B6K1IF-489M&t=36s
port 8080 is also added to security group
this problem was not solved but making a fresh ec2 instance and installing Jenkins by following that tutorial did the trick

OpenVPN config error- cannot connect client to server?

Currently learning how to config an openVPN server on an AWS Linux server as a bit of a self-taught exercise. I've managed to set everything up to trying to connect to it via the OpenVPN client GUI, but it's not working. The error message in the log below:
Enter Management Password:
Mon May 18 14:59:57 2020 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon May 18 14:59:57 2020 Need hold release from management interface, waiting...
Mon May 18 14:59:57 2020 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'state on'
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'log all on'
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'echo all on'
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'bytecount 5'
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'hold off'
Mon May 18 14:59:57 2020 MANAGEMENT: CMD 'hold release'
Mon May 18 14:59:57 2020 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Mon May 18 14:59:57 2020 OpenSSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
Mon May 18 14:59:57 2020 Cannot load private key file client.key
Mon May 18 14:59:57 2020 SIGUSR1[soft,private-key-password-failure] received, process restarting
Mon May 18 14:59:57 2020 MANAGEMENT: >STATE:1589810397,RECONNECTING,private-key-password-failure,,,,,
Mon May 18 14:59:57 2020 Restart pause, 5 second(s)
Here's the configs I have for server and client:
client
dev tun
proto udp
remote [MY AWS IP GOES HERE] 1194
ca ca.crt
cert client.crt
key client.key
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
cipher AES-256-CBC
auth SHA512
resolv-retry infinite
auth-retry none
nobind
persist-key
persist-tun
ns-cert-type server
comp-lzo
verb 3
tls-client
tls-auth pfs.key
Server
port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server.crt
key /etc/openvpn/easy-rsa/pki/private/server.key
dh /etc/openvpn/easy-rsa/pki/dh.pem
cipher AES-256-CBC
auth SHA512
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 3
tls-server
tls-auth /etc/openvpn/pfs.key

CentOS 7 - Payara 5 fails to run on Port 80

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

Trouble with email setup for Wikimedia site

I'm using Google Cloud Engine, Bitnami, and Mailgun to set up a Mediawiki site (v1.33.1-1 on Debian 9). I'm very new to every one of things.
My Mailgun is properly set up and verified, and I'm following the documentation provided here: https://cloud.google.com/compute/docs/tutorials/sending-mail/using-mailgun
When I run:
echo 'Test passed.' | mail -s 'Test-Email' EMAIL#EXAMPLE.COM
And then:
tail -n 5 /var/log/syslog
These are my results:
root#bitnami-mediawiki-860c:~# tail -n 5 /var/log/syslog
Nov 15 03:58:39 bitnami-mediawiki-860c postfix/qmgr[13119]: 8E84FA13DA: from=<>, size=2918, nrcpt=1 (queue active)
Nov 15 03:58:39 bitnami-mediawiki-860c postfix/bounce[13144]: 7A557A13D9: sender non-delivery notification: 8E84FA13DA
Nov 15 03:58:39 bitnami-mediawiki-860c postfix/qmgr[13119]: 7A557A13D9: removed
Nov 15 03:58:39 bitnami-mediawiki-860c postfix/smtp[13142]: 8E84FA13DA: to=<root#bitnami-mediawiki-860c>, relay=none, delay=0.01, delays=0.01/0/0/0, dsn=
5.4.4, status=bounced (Host or domain name not found. Name service error for name=bitnami-mediawiki-860c type=AAAA: Host not found)
Nov 15 03:58:39 bitnami-mediawiki-860c postfix/qmgr[13119]: 8E84FA13DA: removed
Can anyone tell me how to fix this? Be specific if you can, as I'm beginning from nearly zero prior knowledge.
Google Cloud by default has always blocked the port 25, however, you can use different ports, i.e. 587 and 465.
Those ports should work to send mails from an VM instance, which could be the root cause for this to not being working as expected. It should work as mentioned on the comments with the port 2525.