hbquikcomjamesl's questions

We have a development EC2 instance, originally spun up (if memory serves) from a free canned AMI with Trac and SVN running under Amazon Linux, to which we added Tomcat.

Some time ago, I tried to set up an Amazon Linux 2 version of this, in an attempt to get Let's Encrypt working through Certbot; this attempt failed miserably (fortunately, I was able to get Let's Encrypt working through Lego).

Now that the original Amazon Linux is deprecated, I once again have a reason to migrate this instance to Amazon Linux 2. Can anybody give me guidance on how to do this?

Our three Beanstalks are currently running on the "Tomcat 8.5 with Java 8 running on 64bit Amazon Linux" platform, either on the canned "ami-0e469f970b0c3b65c" AMI, or (for one of them) on a customized version of that AMI with Java compilation capability added.

Creating a new Beanstalk with the platform "Tomcat 8.5 with Corretto [x] running on 64bit Amazon Linux 2" seems straightforward enough, but what do I do about the existing Beanstalks? Do I start from scratch, with new Beanstalks? Or is there a way to convert the existing ones?

We have an application on AWS, that uses a MySQL database and an EFS file store. We've got the database set up with multi-AZ redundancy, but I don't see anything similar for the EFS file store.

Is there a way to get a similar redundancy and failover capability for EFS? Or for something else that an EC2 Linux instance can mount as a file system?

I've recently implemented DMARC where I work.

Most of the list-servers work just fine, either rewriting the from address or passing my posts unchanged, so they pass DKIM. One of them appears to be a problem, though.

When I look at the DMARC report, the morning after posting to that one List, the traffic shows up as "forwarded," rather than "compliant," "non-compliant," or "threat/unknown," and when I look at the details, I get this:

I don't know whether my traffic is going out to the list or not (though I strongly suspect the latter).

After the first failed test, and after the List owner ignored my email asking for his help, I tried adding an "a:lists.xxxxxxxxxxxx.com" clause to our SPF TXT record; the above screen shot was from a post I sent the day after I added the clause.

Any suggestions on what to try next?

Re: the comment from "Paul," turning enforcement off and getting the headers from one of my own posts might be problematical, but here are the complete headers (edited for privacy) from somebody else's recent post, if that will help:

Delivered-To: [email protected]
Received: by 2002:a2e:3503:0:0:0:0:0 with SMTP id z3csp1496776ljz;
        Fri, 25 Jun 2021 10:44:13 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJy18k71C++zpNe55rLDEJltbevs69VyzzesCMGd/8tPX/qbI0Lac5wkA5469ycwf0wg5iAc
X-Received: by 2002:a9d:80a:: with SMTP id 10mr8226253oty.192.1624643053207;
        Fri, 25 Jun 2021 10:44:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1624643053; cv=none;
        d=google.com; s=arc-20160816;
        b=uOIgfjalLyaRogOrYH1cvr6kKRXXuTcKTCRtaVZHajEKElKrec+yTJRto4GKcFkfwb
         dcAK2/ySO5Q7jwRUOhl82XUfwRkhDEgIrKGwzeLVOMU9ofPaNF3tQcDsSAtphsAqg00C
         QRhU/d0jmLe8bUzeL5I2tP9T1QD3LOxeFTJsbrOEv8EGVCyMs/D92Fb4JSh86f934F2Y
         3Nw5GU19kNAwAQLS5CZ+fS9PyyQia7Xoh/KH7b6kuSKTKjhSlYzOMbxQd9GUqW92CFdk
         LsQ6MYl3vPNEagtKRGr7mOFxFAoDvvi4+She60YTu6m5QKV0Diy96UR7gigtCC7xNu7u
         kY/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=sender:errors-to:list-subscribe:list-help:list-post
         :list-unsubscribe:list-id:reply-to:precedence:subject
         :content-language:in-reply-to:mime-version:user-agent:date
         :message-id:from:references:to;
        bh=5+f0Tt+6o1VY9gqg/hi3WOfyNITDoc6GvFVfwLx6Rf4=;
        b=srIV+BeEvZsdZQbD3Qt9+PC5b0mbHO4IE3858BpLyDtZXULtVSt7mg3PXy6pVSQswV
         8TjwWmUbzuXNuK0985BvvPM0k/87iWZ3e+WYcvvieOHol1sXMct3U/nK7wHDgY7kN1X2
         GkP/JXBcYx8oP4YANlq2v20J7fTPdMoS3qUJZXO5eDpn2AhFHEFqoekwSdPmZ+yNru92
         vl3N18ixf1H+3T4UR/DA9x+6ZrfEFenSlcRxoMOH+MahnNuz6XeYJmIxQZg3g4k7Ud3b
         We6EiHf0juIPlmIXVJEOY4uM2LlbbHFkRabpFl6Cg9z8rdzZOT7fP0dP/PuD1K1DvYLX
         lLQA==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: best guess record for domain of [email protected] designates aaa.bbb.ccc.ddd as permitted sender) [email protected]
Return-Path: <[email protected]>
Received: from mail2.xxxxxxxxxxxx.com (mail2.xxxxxxxxxxxx.com. [aaa.bbb.ccc.ddd])
        by mx.google.com with ESMTPS id y13si7142121oih.66.2021.06.25.10.44.12
        for <[email protected]>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 25 Jun 2021 10:44:13 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of [email protected] designates aaa.bbb.ccc.ddd as permitted sender) client-ip=aaa.bbb.ccc.ddd;
Authentication-Results: mx.google.com;
       spf=pass (google.com: best guess record for domain of [email protected] designates aaa.bbb.ccc.ddd as permitted sender) [email protected]
Received: from xxxxxxxxxxxx.com (xxxxxxxxxxxx.com [www.xxx.yyy.zzz])
    by mail2.xxxxxxxxxxxx.com (8.15.2/8.15.2) with ESMTP id 15PHaLsP072664;
    Fri, 25 Jun 2021 13:36:22 -0400 (EDT)
    (envelope-from [email protected])
Received: from xxxxxxxxxxxx.com (xxxxxxxxxxxx.com [www.xxx.yyy.zzz])
    by xxxxxxxxxxxx.com (8.14.4/8.14.7) with ESMTP id 15PHbRHQ032311;
    Fri, 25 Jun 2021 12:37:28 -0500 (CDT)
    (envelope-from [email protected])
X-Mailman-Handler: $Id: mm-handler 5100 2002-04-05 19:41:09Z bwarsaw $
Received: from xxxxxxxxxxxx.com (xxxxxxxxxxxx.com [www.xxx.yyy.zzz])
    by xxxxxxxxxxxx.com (8.14.4/8.14.7) with ESMTP id 15PHbPBf032295
    for <[email protected]>;
    Fri, 25 Jun 2021 12:37:25 -0500 (CDT)
    (envelope-from [email protected])
Received: from grungy.xxxxxxxxxxxx.com (grungymail@localhost)
    by xxxxxxxxxxxx.com (8.14.4/8.14.7/Submit) with ESMTP id 15PHbN4m032272
    for <[email protected]>;
    Fri, 25 Jun 2021 12:37:23 -0500 (CDT)
    (envelope-from [email protected])
X-Authentication-Warning: xxxxxxxxxxxx.com: grungymail owned process doing -bs
Received: from [127.0.0.1] (localhost [127.0.0.1])
    by grungy.xxxxxxxxxxxx.com (8.15.2/8.15.2) with ESMTP id 15PHbIUc008701
    for <[email protected]>;
    Fri, 25 Jun 2021 12:37:18 -0500 (CDT)
    (envelope-from [email protected])
To: [email protected]
References: <OF1F227294.95B6DA5A-ONC12586FE.002643EF-C12586FE.00272521@zzzzzzzzzzzzzz.it>
    <[email protected]>
    <OF16B0EB8D.A01226D6-ONC12586FF.0058F2FC-C12586FF.005B0A15@zzzzzzzzzzzzzz.it>
From: Sxxxx Kxxxxxx <[email protected]>
Message-ID: <[email protected]>
Date: Fri, 25 Jun 2021 12:37:19 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
    Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <OF16B0EB8D.A01226D6-ONC12586FF.0058F2FC-C12586FF.005B0A15@zzzzzzzzzzzzzz.it>
Content-Language: en-US
X-Spam-Status: No, score=-1.0 required=8.0 tests=ALL_TRUSTED,HTML_MESSAGE
    autolearn=unavailable autolearn_force=no version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
    grungy.xxxxxxxxxxxx.com
Subject: Re: [Ftpapi] Rif: Re: Rif: Re: In: Re: In: HTTPAPI - Example 7 -
 Upload a file from IFS - No file attached!
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: FTPAPI/HTTPAPI mailing list <[email protected]>
List-Id: FTPAPI/HTTPAPI mailing list <ftpapi.lists.xxxxxxxxxxxx.com>
List-Unsubscribe: <http://xxxxxxxxxxxx.com/mailman/options/ftpapi>,
    <mailto:[email protected]?subject=unsubscribe>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://xxxxxxxxxxxx.com/mailman/listinfo/ftpapi>,
    <mailto:[email protected]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1888169630713480664=="
Errors-To: [email protected]
Sender: [email protected]

This seems like an exceptionally dumb question, but as my high school woodshop teacher said, the only dumb question is the one that doesn't get asked.

I'm not entirely sure what assets are in a given VPC, or how to determine this.

I have Elastic Beanstalks, EC2 instances (both Beanstalk-generated and otherwise), a MySQL RDB instance, and a Redis ElastiCache instance, all part of the same application.

Assuming I'm able to determine that everything is within the VPC, is there any reason to have in-transit encryption of data flowing between those assets?

New information: All assets of interest here have at least one security group listed with the VPC, and no security groups not listed with the VPC.

I could not find any explicit VPC reference on the EFS, but all of its subnets are listed with the VPC. Ditto for the Redis Elasticache.

Everything else does have an explicit reference to the VPC.

May I assume from this that all the assets of interest live -- and talk to each other -- entirely within the VPC?

We have discovered that we really ought to have encrypted the MySql database and EFS volume on our application, at the time of creation. We are now attempting to correct the oversight.

I've read the Amazon document about converting a database from unencrypted to encrypted, as well as the ServerFault thread about changing encryption keys.

What would be the best and most practical way to do something similar for the EFS volume?

(And is anybody aware of any ways to improve the process on the database side?)

I have a subdomain set up in Apache httpd, that is front-ending for a Tomcat server, with the httpd server secured by Let's Encrypt.

If I have the following rewrite active in the conf file, then certbot fails.

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

If I comment it out, then certbot works.

I'm not entirely sure, but I think it's 100% consistent. Of course, with challenge-caching, I can't get another meaningful test result for a full month after a successful renewal.

Having (I hope) solved my problems with mutually independent httpd and Tomcat servers on an Amazon Linux ("not 2") instance, I now have a situation in which I do want Tomcat running behind an existing, running, httpd, on an Amazon Linux 2 instance that's already obtaining a Let's Encrypt cert via certbot. But the last time I experimented with this one (several months ago, like the one I finally got working with Lego), I had a fair amount of trouble getting it even partially functional, and something I did badly screwed up the auto-renewal, which we didn't find out about until the cert expired on us.

Here is the (actual names and IP addresses redacted) httpd conf file I added, to provide the virtual host for the new subdomain. It makes no difference to me whether browser requests sent to port 80 get redirected to https or not; the important part is that (1) Certbot and Let's Encrypt can see and do what they need to, (2) users can reach all webapp contexts on the Tomcat server, including ROOT, and (3) only the specified IP addresses can see manager and host-manager.

Is there anything obvious that I'm doing wrong?

 <VirtualHost *:80>
 ServerName xyweb.frobozz.com
 DocumentRoot /var/www/html/test
 ServerAdmin [email protected]
 <Directory /var/www/html/test>
 AllowOverride All
 </Directory>
 # RewriteEngine on
 # RewriteCond %{HTTP_HOST} !^www\. [NC]
 # RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
 </VirtualHost>

 <IfModule mod_ssl.c>
 <VirtualHost *:443>
 ServerName xyweb.frobozz.com
 DocumentRoot /var/www/html/test
 ServerAdmin [email protected]
 <Location /manager>
  Require ip ww.xx.yy.zz aa.bb.cc.dd ee.ff.gg.hh
 </Location>
 <Location /host-manager>
  Require ip ww.xx.yy.zz aa.bb.cc.dd ee.ff.gg.hh
 </location>
 ProxyPass "/" "http://127.0.0.1:8080/"
 ProxyPassReverse "/" "http://127.0.0.1:8080/"
 ProxyRequests Off
 Include /etc/letsencrypt/options-ssl-apache.conf
 SSLCertificateFile /etc/letsencrypt/live/fizmo.com/fullchain.pem
 SSLCertificateKeyFile /etc/letsencrypt/live/fizmo.com/privkey.pem
 </VirtualHost>
 </IfModule>

We have an Amazon Linux (not Amazon Linux 2) instance, running a fairly old Bitnami Trac/SVN stack, and also running a Tomcat server. It has two instances of httpd: the one that's part of the Bitnami stack, and the one that came with the OS. Tomcat is running independently. Lego is already present, as is bncert-tool, but the Bitnami directory is not "/opt/bitnami," but "/opt/trac-1.2.3-11."

The OS httpd, when up, listens on 80, unsecured. The Bitnami httpd listens on 8000, secured, and can also listen on 81. The Tomcat server runs independently of httpd, and listens on 8443, secured (with an iptables redirection from 443) and 7443 (also secured).

Working on a spot instance, cloned from the most recent backup of the live server, with a domain mapped to it in Route 53, and ports 80 and 443 open to the world in one of the assigned security groups, I've been attempting to follow the instructions under "Alternative Approach" on the page at https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#alternative-approach without success.

Skipping step 1 in the procedure, since Lego is already present, and going straight to step 2, I stopped Bitnami with "ctlscript.sh stop." I then (running under root authority) attempted to get the cert, using the command given in the procedure, adjusted to match the circumstances. (Note that the domain name has been changed, "to protect the innocent.")

sudo /opt/trac-1.2.3-11/letsencrypt/lego --tls --email="[email protected]" --domains="test.bar.net" --path="/opt/trac-1.2.3-11/letsencrypt" run

I got this:

2020/08/04 18:01:29 No key found for account [email protected]. Generating a P384 key.
2020/08/04 18:01:29 Saved key to /opt/trac-1.2.3-11/letsencrypt/accounts/acme-v02.api.letsencrypt.org/[email protected]/keys/[email protected]
2020/08/04 18:01:30 Please review the TOS at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
Do you accept the TOS? Y/n
Y
2020/08/04 18:01:43 [INFO] acme: Registering account for [email protected]
!!!! HEADS UP !!!!

        Your account credentials have been saved in your Let's Encrypt
        configuration directory at "/opt/trac-1.2.3-11/letsencrypt/accounts".
        You should make a secure backup of this folder now. This
        configuration directory will also contain certificates and
        private keys obtained from Let's Encrypt so making regular
        backups of this folder is ideal.
2020/08/04 18:01:43 [INFO] [test.bar.net] acme: Obtaining bundled SAN certificate
2020/08/04 18:01:43 [INFO] [test.bar.net] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/6317334421
2020/08/04 18:01:43 [INFO] [test.bar.net] acme: use tls-alpn-01 solver
2020/08/04 18:01:43 [INFO] [test.bar.net] acme: Trying to solve TLS-ALPN-01
2020/08/04 18:01:50 [INFO] Unable to deactivated authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/6317334421
2020/08/04 18:01:50 Could not obtain certificates:
    acme: Error -> One or more domains had a problem:
[test.bar.net] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Cannot negotiate ALPN protocol "acme-tls/1" for tls-alpn-01 challenge, url: 

I then tried shutting down the OS httpd instance, and repeating the command. I got the same result, from the "Obtaining bundled SAN certificate" message on down.

Then, I tried shutting down Tomcat. This time, I got a different message for the last line:

[test.bar.net] acme: error: 400 :: urn:ietf:params:acme:error:connection :: Connection refused, url:

Clearly something is wrong here, but what is my next step?

I have a Tomcat 8.5 server running on an Amazon Linux EC2 Linux instance. Tomcat is running on port 8443, with IPTables remapping 443 to it.

I've changed the "sslProtocol" clause of the connector to specify TLS 1.2 protocol. And the change doesn't work: it 's still accepting TLS 1.0 and 1.1 as well as 1.2. Anybody know what the problem could be?

The Connector looks like this (sensitive information redacted):

<Connector port="8443" proxyPort="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
 compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json"
               maxThreads="1000" socket.appReadBufSize="1024" socket.appWriteBufSize="1024" bufferSize="1024" SSLEnabled="true" scheme="https" secure="true"
               keystoreFile="/etc/tomcat8/dev.REDACTED.net.ks" keyAlias="REDACTED" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,               TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
               TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA"
               clientAuth="false" sslProtocol="TLSv1.2" />

(previously, the "sslProtocol" clause was 'sslProtocol="TLS"')

The same "sslProtocol" clause works just fine in the connector tag of a Tomcat 7 server running on a customer's AS/400, restricting it to TLS 1.2.

I recently (and I think it was on either ServerFault, StackOverflow, or some other StackExchange forum) found out that Bitnami stacks provide a tool for using Let's Encrypt, one that apparently uses something other than certbot (something called "lego," is it?).

We have a Bitnami Trac/SVN stack running on an AWS EC2 instance (original Amazon Linux). I note that there are apparently two separate httpd instances present on the box; the one in the Bitnami stack is the active one, hosting Trac and SVN. (I think I started the other one, some months ago, in connection with a failed attempt to get certbot working, and may have left it up, but it isn't actually doing much of anything.)

The Bitnami httpd is set up for HTTP on port 81 (which is not currently reachable from the outside), and HTTPS on port 8000 (which is reachable), and is currently using a cert from Comodo, which expires in July.

And I don't remember what the original "as-delivered" port configuration was for the httpd in the Bitnami stack.

I've been reading the instructions for this "bncert-tool," and I'm wondering whether it's going to work with our setup. From my failed experiments with certbot, I was under the impression that Let's Encrypt expects to find http open on 80.

Can anybody shed any light on this?

May 18 Update

I finally remembered this project at a time when I could actually devote some time to it. I cloned the instance to a spot instance, and then (1) disabled the "stock" httpd that came with Linux, and (2) changed the httpd in the Bitnami stack to listen on 80. When I ran bncert-tool, I got this:

An error occurred creating certificates with Let's Encrypt:

acme: Error -> One or more domains had a problem:
[test.wintouch.net] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized 
:: Cannot negotiate ALPN protocol "acme-tls/1" for tls-alpn-01 challenge, url:

Now what?

(I have saved the log file.)

May 22 Update

It occurred to me that as the server is currently configured, it is impossible to get to anything without a password.

So I tried another spot instance. After some futzing around, I configured it so that it listens on 80, without a password, and serves a static page on that port, located far away from the SVN and Trac data.

But the results were exactly the same as before. As before I terminated the spot request and removed the Route 53 A record as part of the cleanup.

After the day's experiment, I looked into setting up my spot instance from whatever it was I used when I set up the original, and discovered something rather odd: all of the Bitnami SVN and Trac AMIs I could see are either Debian or Ubuntu. But this is on Amazon Linux (original, not Amazon Linux 2). So either it's from an AMI that no longer exists, or I spun up the instance from a "vanilla" Amazon Linux AMI, and then installed the Bitnami SVN/Trac stack on it.

I will note that the stack, including bncert-tool, does not live at /opt/bitnami, but at /opt/trac-1.2.3-11

So then, stymied about inspecting an "as-delivered" configuration, I looked around, wondering what bncert-tool uses to find the stack, and I eventually found /opt/trac-1.2.3-11/properties.ini

hostname=
[Support]
installed_components=apache
apache_logs=apache{,2}/logs/error*log logs/error_log
apache_conf=apache{,2}/conf/{*.conf,bitnami/*.conf} etc/httpd.conf apps/*/conf/ht*.conf
apache_acl=apache apache2
[Apache]
apache_server_port=81
apache_user=daemon
apache_group=daemon
apache_server_ssl_port=443
apache_root_directory=/opt/trac-1.2.3-11/apache2
apache_htdocs_directory=/opt/trac-1.2.3-11/apache2/htdocs
apache_domainname=ip-172-31-8-195.us-east-2.compute.internal
apache_configuration_directory=/opt/trac-1.2.3-11/apache2/conf
apache_version=2.4.39
[Subversion]
subversion_port=3690
subversion_root_directory=/opt/trac-1.2.3-11/subversion

which appears unchanged since installation (everything in /opt/trac-1.2.3-11 has a datestamp of June 6, 2019).

Could it be that bncert-tool uses that configuration file, and already is telling Let's Encrypt to use port 81 instead of 80?

I will note that contrary to the above configuration file, the Bitnami instance of httpd listens for SSL/TLS on 8000, not 443, a Tomcat server (independent of the Bitnami stack) listens on 8443 (and shows up in netstat -l --numeric-ports as) 8443, mapped into 443 via iptables, and nothing listens directly on port 443.

I have an existing Apache httpd server. All of the existing virtual hosts have php landing pages (i.e., index.php). The new one, however, has a plain, old-fashioned, html landing page (i.e., index.html).

I can get the html landing page to come up if I explicitly specify it in the url, e.g., http://qux.baz.com/index.html (not the real URL).

But if I don't explicitly specify the landing page in the url, e.g., http://qux.baz.com, it immediately redirects to https://www.qux.baz.com, which fails.

I've tried putting a DirectoryIndex directive in the qux.baz.conf file; no effect, even after restarting httpd.

The only existing DirectoryIndex directive I've found anywhere is the one in php.conf. I tried adding "index.html" onto the end of it. Also no effect.

My new conf file looks like this (the URLs have been changed to protect the innocent):

<VirtualHost *:80>
ServerName qux.baz.com
ServerAlias corge.baz.com
DocumentRoot /var/www/html/test
ServerAdmin [email protected]
<Directory /var/www/html/test>
AllowOverride All
</Directory>
# RewriteEngine on
# RewriteCond %{HTTP_HOST} !^www\. [NC]
# RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

(note that I've deliberately commented out everything to do with rewriting)

and the httpd -S output (again, URLs changed to protect the innocent) looks like

*:443                  is a NameVirtualHost
         default server www.foo.com (/etc/httpd/conf.d/foo-le-ssl.conf:2)
         port 443 namevhost www.foo.com (/etc/httpd/conf.d/foo-le-ssl.conf:2)
                 alias foo.com
         port 443 namevhost ip-172-32-29-49.ec2.internal (/etc/httpd/conf.d/ssl.conf:56)
         port 443 namevhost www.plugh.com (/etc/httpd/conf.d/plugh-le-ssl.conf:2)
                 alias plugh.com
         port 443 namevhost www.baz.com (/etc/httpd/conf.d/baz-le-ssl.conf:2)
                 alias baz.com
         port 443 namevhost www.bar.com (/etc/httpd/conf.d/bar-le-ssl.conf:2)
                 alias bar.com
*:80                   is a NameVirtualHost
         default server www.foo.com (/etc/httpd/conf.d/foo.conf:1)
         port 80 namevhost www.foo.com (/etc/httpd/conf.d/foo.conf:1)
                 alias foo.com
         port 80 namevhost www.plugh.com (/etc/httpd/conf.d/plugh.conf:1)
                 alias plugh.com
         port 80 namevhost www.baz.com (/etc/httpd/conf.d/baz.conf:1)
                 alias baz.com
         port 80 namevhost www.bar.com (/etc/httpd/conf.d/bar.conf:1)
                 alias bar.com
         port 80 namevhost qux.baz.com (/etc/httpd/conf.d/qux.baz.conf:1)
                 alias corge.baz.com
ServerRoot: "/etc/httpd"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/etc/httpd/logs/error_log"
Mutex authdigest-opaque: using_defaults
Mutex watchdog-callback: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex authdigest-client: using_defaults
Mutex lua-ivm-shm: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex authn-socache: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/run/httpd/" mechanism=default 
Mutex mpm-accept: using_defaults
Mutex cache-socache: using_defaults
PidFile: "/run/httpd/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="apache" id=48
Group: name="apache" id=48

I'm clearly doing something wrong here, but I have not the slightest idea what.

I finally got certbot-auto installed on the AWS EC2 Linux instance that was giving me trouble, and I'm trying to get a wildcard cert from Let's Encrypt.

I was told to put up a TXT record under the name (changed to protect the innocent) _acme-challenge.foo.bar.net, with a given value.

So I go to the Route 53 console page, and select the bar.net hosted zone. I add the _acme-challenge.foo.bar.net record, with the specified value, click "Save Record Set," and wait a few minutes. Then I select it, and click "Test Record Set," and Route 53 thinks it's published.

But when I tell certbot-auto to proceed, and Let's Encrypt looks for the record, it isn't there. And if I do an nslookup -q=txt _acme-challenge.foo.bar.net, I get

server can't find _acme-challenge.foo.bar.net

and for nslookup -q=txt foo.bar.net, I get

server can't find foo.bar.net

And yet, if I do a regular nslookup on foo.bar.net, I find it.

What is going wrong?

I'm trying to install certbot on the instance where we have a Bitnami Trac/SVN stack and a Tomcat server installed, and when I do

yum install -y certbot python2-certbot-apache

I keep getting

No package certbot available.
No package python2-certbot-apache available.
Error: Nothing to do

But it worked fine on another (newer) instance, the one hosting our web site!

/etc/os-release on the Trac/SVN/Tomcat instance (the one where it won't install) shows:

NAME="Amazon Linux AMI"
VERSION="2018.03"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2018.03"
PRETTY_NAME="Amazon Linux AMI 2018.03"
ANSI_COLOR="0;33"
CPE_NAME="cpe:/o:amazon:linux:2018.03:ga"
HOME_URL="http://aws.amazon.com/amazon-linux-ami/"

while on the web site instance (the one where it was successfully installed), it shows:

NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"

Can anybody explain what's going wrong? And what can be done about it?

I've tried what was suggested at https://stackoverflow.com/questions/53545436/no-package-certbot-available , with no success.

We have Amazon RDS MySQL instances. Our application appears to connect to it simply by being in the same security group and same VPC, and the relevant developer is 90% certain that SSL is not involved.

We also connect to it for maintenance and inspection, typically via Sequel Pro. Looking at the Sequel Pro connection dialog, we are using SSL/TLS for these connections, but are connecting by username and password, with the "connect using SSL" checkbox set, but no key file, certificate, or CA certificate set. We also have restrictions on the MySQL port, only allowing outside connections from specific IP addresses.

Does the impending certificate change affect us?

Edit: Note that I'm asking not so much in terms of the cert change being necessary on the server side, as in terms of whether complementary changes are necessary in the application, or in Sequel Pro, for the users with direct maintenance access.

I've got a real puzzle on my hands.

I've got a single Amazon EC2 instance, that I set up around 6 months ago. It's running an Apache HTTPD on ports 81 (unsecured) and 8000 (secured). It's also running a Tomcat on port 8443. But the outside world sees Tomcat (secured) on 443.

There's no load balancer involved (we have load balanced clusters; I know what that looks like).

The Tomcat and HTTPD servers are running independently of each other.

If I do a netstat on the EC2 instance, it shows that it's listening on 8443, but not 443. The active connector in the Tomcat's server.xml includes a "proxyPort" clause for 443.

If I do a curl from my desktop to the Tomcat server, on 443, I get something back. If I do a curl from the EC2 instance to localhost, on 443, I get nothing; if I do so on 8443, I get a complaint about the cert being wrong for "localhost," so it's obviously connecting. So apparently, the mapping between 443 and 8443 is external to the instance.

And like a complete idiot, I left myself no notes whatsoever on what I did to make this thing work. Can anybody tell me what I did, and how I did it? Or at least tell me what to look for? I see a security group, but it doesn't say anything about remapping any ports.

This has happened a couple of times since we moved our cluster project from Google to AWS.

We have an EFS volume that's mounted on a load-balanced cluster in a Beanstalk project.

I will be in the middle of setting something up, either uploading a large ZIP file to that EFS volume (via an instance on the load-balanced cluster), or unzipping one from an ssh session on the cluster instance, and I will suddenly find the instance ripped out from under me, and find that the cluster has bred two (or more) new instances, and is shutting down the one I was accessing.

What is going on here? The instances are all "t2-micro" instances; are they inadequate to the sustained load, and running out of burst capacity? Has anybody seen anything like this?

We've got our Tomcat application running in a load-balanced Beanstalk environment, and we've got HTTPS up and running. But I've found that if I try to connect to web services hosted by that application, from an AS/400 running V6R1, I can only use HTTP -- if I try to use HTTPS, I get

SSL Handshake: (GSKit) No compatible cipher suite

It appears that this slightly out-of-date AS/400 can do these ciphers: RSA_AES_128_CBC_SHA
RSA_RC4_128_SHA
RSA_RC4_128_MD5
RSA_AES_256_CBC_SHA
RSA_3DES_EDE_CBC_SHA
RSA_DES_CBC_SHA
RSA_EXPORT_RC4_40_MD5
RSA_EXPORT_RC2_CBC_40_MD5 RSA_NULL_SHA
RSA_NULL_MD5

How do I adjust what our AWS environment will accept?

We have a web application, running on Google Cloud. It's still in development at the moment. We've got a load balancer tied to three separate instance groups, for three different functions, all of them running in Tomcat 8 servers.

One of these instance groups, I'll call it the report group, had been running the same WAR file for several months, and we just, within the past hour, updated it.

Before the update, I'd never seen the report group exceed a single instance. Just before the update, I looked at Tomcat Manager on that instance, and it was showing over a thousand active sessions.

After the update, we ran a test, and POOF, we had two instances, and looking at their Tomcat Managers, they were each showing a few hundred sessions, but an aggregate total of well under 1000. At one point, as I was typing this, it briefly went up to four instances.

Can somebody offer me any insight into what happened, why the behavior changed, and how load balancers and instance groups decide to spawn off additional instances?

And how to keep the instances from multiplying like excessively frisky gerbils?

As recently as yesterday, I was able to connect to our development instance via my local ssh client, using one of several ssh keys listed under sshKeys in the instance's custom metadata (the old-fashioned way). ("Block project-wide ssh keys" is checked). Also that afternoon, while connected, I was doing something where a second ssh session would be convenient. I tried opening a second connection through the local ssh client, and got "Permission denied (publickey)." I tried opening a second connection from the instance console page, and it wouldn't connect, either. Meanwhile, the ssh session I was using continued to work just fine.

This morning I can't get an ssh session on that instance AT ALL.

The only thing I can remember doing yesterday, that was the least bit unusual, was a chmod on my home directory, setting it to "777."

I tried yanking out the sshKeys metadata, and trying the console ssh again. No joy. Then I looked at the serial port 1 log, and noticed this, with timestamps showing GMT for approximately when I tried it:

Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.
Nov 28 21:26:49 bitnami-trac-dm-87ea google-accounts: INFO Removing user <redacted>.

I can get to the password prompt on the serial port, but I've never set myself up with password access, to the best of my recollection.