comfytoday's questions

Using the official CentOS 7 Marketplace AMI on an EC2 Instance, the network adapter appears to default to using Jumbo Frames:

ip link show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 0a:09:37:73:0f:7a brd ff:ff:ff:ff:ff:ff

What is the best method for disabling this? Why does it default to mtu 9001?

Editing /etc/sysconfig/network-scripts/ifcfg-ens5 does not seem to be an option:

# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=dhcp
DEVICE=ens5
HWADDR=0a:09:37:73:0f:7a
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

I would like the change to persist.

Default Tomcat 8.5 logs do not appear to show any failed requests, or anything about the SSL handshakes. Specifically the localhost log and catalina.out

See this question for context about the type of failed request: Intermittent Curl 35 error when using self signed certificate on Tomcat

This question seems to indicate that it is not possible....? Tomcat access logs - are failed requests included?

I tried turning on debug, but still couldn't find anything related to a failed request.

We are using self signed certificate behind a range of load balancers, the endpoints use Self Signed Certificates.

When testing the endpoints directly using CURL, we get intermittent SSL Connect errors (Code 35)

Here is an example output of a failed attempt:

curl --insecure example.com/index.html

• Trying 9773...
• TCP_NODELAY set
• Connected to example.com (10.8.49.98) port 9773 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• successfully set certificate verify locations:
• CAfile: /etc/ssl/cert.pem CApath: none
• TLSv1.2 (OUT), TLS handshake, Client hello (1):
• TLSv1.2 (IN), TLS handshake, Server hello (2):
• TLSv1.2 (IN), TLS handshake, Certificate (11):
• TLSv1.2 (IN), TLS handshake, Server key exchange (12):
• TLSv1.2 (IN), TLS handshake, Server finished (14):
• TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
• TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.2 (OUT), TLS handshake, Finished (20):
• LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com
• Closing connection 0 curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:9773

Is this due to a misconfiguration? Server performance issue? Network?

Server is Tomcat 8.

Command used to create the certificate:

openssl req -x509 -newkey rsa:4096 -nodes -keyout private.pem -out public.crt -days 365 -subj '/CN=example.com'

The associated Tomcat SSL configuration:

<Connector port="9773" protocol="org.apache.coyote.http11.Http11AprProtocol"
               maxThreads="150"
               SSLEnabled="true"
               scheme="https"
               secure="true"
               compression="on"
               address="0.0.0.0"
               >
        <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
        <SSLHostConfig
                protocols="TLSv1.2"
                >
            <Certificate
                certificateFile="/ssl/certs/public.crt"
                certificateKeyFile="/ssl/certs/private.pem"
            />
        </SSLHostConfig>
    </Connector>

In order to shutdown a Tomcat docker container gracefully, is it possible to issue a remote SHUTDOWN command? rather than setting up docker to catch the kill request, and shutting down gracefully.

Default server.xml:

<Server port="8005" shutdown="SHUTDOWN">