wruckie's questions

I am using Ubuntu 22.04 LTS and Postfix to send messages out through SendGrid. I followed the tutorial at here https://www.twilio.com/docs/sendgrid/for-developers/sending-email/postfix

I have several VPS's and I use nicknames to keep them separate in my head - this one I named COCONUT. Some messages are going out if the from address is spelled out, but all system messages fail to send. When sending a ps -ely | mailx -s Testing [email protected], it tries to send from from=<root@coconut> I get the error because SendGrid knows I do not have permissions from just "coconut" hence the sender's identity error.

log entries from /var/log/mail.log when running a ps -ely | mailx -s Testing [email protected]

...
Jul 19 09:28:57 coconut postfix/pickup[624347]: 290E754988: uid=0 from=<root@coconut>
Jul 19 09:28:57 coconut postfix/cleanup[624480]: 290E754988: message-id=<[email protected]>
Jul 19 09:28:57 coconut postfix/qmgr[624348]: 290E754988: from=<root@coconut>, size=17599, nrcpt=1 (queue active)
Jul 19 09:28:57 coconut postfix/smtp[624482]: 290E754988: to=<[email protected]>, relay=smtp.sendgrid.net[44.239.172.8]:587, delay=0.83, delays=0.01/0.01/0.6/0.2, dsn=5.0.0, status=bounced (host smtp.sendgrid.net[44.239.172.8] said: 550 The from address does not match a verified Sender Identity. Mail cannot be sent until this error is resolved. Visit https://sendgrid.com/docs/for-developers/sending-email/sender-identity/ to see the Sender Identity requirements (in reply to end of DATA command))
Jul 19 09:28:57 coconut postfix/cleanup[624480]: F2DC254989: message-id=<[email protected]>
Jul 19 09:28:57 coconut postfix/bounce[624483]: 290E754988: sender non-delivery notification: F2DC254989
Jul 19 09:28:57 coconut postfix/qmgr[624348]: F2DC254989: from=<>, size=20071, nrcpt=1 (queue active)
Jul 19 09:28:57 coconut postfix/qmgr[624348]: 290E754988: removed
...

Here is my /etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
myhostname = coconut.example.com
myorigin = example.com
mydestination = $myhostname, localhost #added to no effect

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2

#header_checks = regexp:/etc/postfix/my_custom_header
inet_protocols = ipv4
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = encrypt
header_size_limit = 4096000
relayhost = [smtp.sendgrid.net]:587

Here is the contents of my /etc/mailname

example.com

Here is the contents of my /etc/hostname

coconut.example.com

Any ideas on how to fix the system emails as being sent from root@coconut?

After an upgrade to Ubuntu 20.04 LTS, my WordPress site is stuck in Maintenance mode. mySQL is trying to start with these same 10 lines repeating every couple of seconds in the /var/log/mysql/error.log file. At least for me, a quick search of the term unknown variable 'query_cache_limit=1M' only yields pages telling how to implement this parameter. How do I get it working again?

2020-11-12T16:12:25.733349Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2020-11-12T16:12:25.735469Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.22-0ubuntu0.20.04.2) starting as process 20068
2020-11-12T16:12:25.746199Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2020-11-12T16:12:26.131087Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2020-11-12T16:12:26.307241Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2020-11-12T16:12:26.370126Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2020-11-12T16:12:26.370481Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2020-11-12T16:12:26.377752Z 0 [ERROR] [MY-000067] [Server] unknown variable 'query_cache_limit=1M'.
2020-11-12T16:12:26.378449Z 0 [ERROR] [MY-010119] [Server] Aborting
2020-11-12T16:12:27.821939Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.22-0ubuntu0.20.04.2)  (Ubuntu).

After an upgrade to Ubuntu 20.04, some packages have "{u}" in their name. I have looked for the answer, but it looks like either google is promptly ignoring the curly braces during search or this is does not happen much. Can someone help me with links to documentation? What does the {u} signify in these package names?

user@server:~# sudo aptitude update && sudo aptitude upgrade && sudo apt-get autoremove
Hit http://mirrors.linode.com/ubuntu focal InRelease
Hit http://mirrors.linode.com/ubuntu focal-updates InRelease
Hit http://mirrors.linode.com/ubuntu focal-backports InRelease
Hit http://security.ubuntu.com/ubuntu focal-security InRelease
Hit http://ppa.launchpad.net/ondrej/php/ubuntu focal InRelease

The following packages will be REMOVED:
  ack{u} libargon2-0{u} libfile-next-perl{u} libicu65{u}
  python-pkg-resources{u}
0 packages upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 34.4 MB will be freed.
Do you want to continue? [Y/n/?]

Tonight I upgraded my VPS from Ubuntu 16.04 LTS to Ubuntu 18.04 LTS. Everything worked as expected, had a little cleanup on php aisle 5.6 and some stocking shelves on php aisle 7.4. Apache restarted without a whimper after all my config and mod changes; thought I was good to go. But 3 of my 4 sites would not load; no clean 404 page, just this misconfiguration message.

Internal Server Error 
The server encountered an internal error or misconfiguration and was unable to complete your request.

After reviewing the /var/log/apache2/error.log, I found this:

[Wed May 06 03:55:16.190469 2020] [core:alert] [pid 5657] [client 10.10.10.10:56897] 
/var/www/abc/example.com/.htaccess: No comments are allowed here, referer: https://example.com/

After trying several different things, it seems that comments that start the line are NOT the issue, it is comments that end a normal line of the file. Removing or moving these #main office comments to their own lines bring everything back online. The # Allow from this IP address line is still in my .htaccess file but does not cause me any grief.

<Files wp-login.php>
    order deny,allow
    Deny from all
#   
#   Allow from this IP address
    allow from 10.10.10.10      #main office
    allow from 10.10.11.10      #satellite office
</Files>

Is this a 'bug' or a 'feature'? A search in Google for ".htaccess: No comments are allowed here" brings up almost nothing. (You know you are in trouble when the 4th hit is in a foreign language). Obviously the jump to Ubuntu 18.04 or the associated apache or php updates are the 'when', but WHY? Why is this in-line documentation problematic? What gives?

I bought a web app that does not use special characters. In reviewing my logs, I am seeing probing by threat actors who attempt to see if my site is vulnerable to SQL injection by adding apostrophes and other char() characters that are never normally used. I trust the security of my app (mostly), but wanted to see if a rewrite rule or some other methodology would black-hole their request. My web app gives out its standard error. I am looking for rules or ideas to 1.) give the attacker as little info as possible without 2.) adding a lot of overhead to the server. There are lots of rewrite rule examples out there, but none that I have found that deal with this angle.

Simple Example of the probing: https://sub.domain.com/default.aspx?page=3500'A=0&Id=497066

I am using certbot to generate a ssl certificate for a third party web app. Because I cannot get into the source code or folder structure, I am using DNS validation. To further complicate things, my DNS provider does not make it clear when the changes have been applied and are propagating. I have to start the process, get the values, publish them to DNS, wait a long while, and hit ENTER to complete the validation. If the time I waited was not long enough, or the terminal session to the server dies, I have to start over -- which generates new values to be put into DNS.

I would like to query my DNS name servers to see if and when my _acme_challenge value has propagated. Let's Encrypt has a means to check this value, but I cannot seem to figure this one out. All the online forums that I am finding are for querying the default TXT record that is used for SPF.

Output of the certbot validation process

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.app.mydomain.com with the following value:

4Rn5ZNCdLYDYK9uQnyZ7k3CJ8kNsNyIJa9QeXCeOCMI

Before continuing, verify the record is deployed.
(This must be set up in addition to the previous challenges; do not remove,
replace, or undo the previous challenge tasks yet. Note that you might be
asked to create multiple distinct TXT records with the same name. This is
permitted by DNS standards.)

How do I query this named TXT record?

Pci DSS compliance stated that by June 2016 TLSv1.0 must be disabled. My cursory search taught me that a -TLSv1 in the SSLProtocals portion of the apache config would care for it (right next to the -SSLv3). I have tried each of the following lines in my /etc/apache2/conf_available/https.conf, but to no avail. I cannot figure out why changing these protocols makes no difference on my server (Apache/2.4.25 on Ubuntu 16.04)

SSLProtocol -all -SSLv3 -TLSv1 +TLSv1.1 +TLSv1.2
SSLProtocol -all +TLSv1.2
SSLProtocol +TLSv1.1 +TLSv1.2
SSLProtocol -TLSv1 +TLSv1.1 +TLSv1.2

Everytime I test with https://www.ssllabs.com/ssltest/index.html, I get the same result - TLSv1 is never turned off. What am I missing here? Are the TLS versions dependent on each other?

Promising Links that did not work for me
http://utdream.org/post.cfm/how-to-disable-tlsv1-0-for-pci-compliance-in-apache-2-2
https://ubuntuforums.org/showthread.php?t=2288000