Find which process holds a particular connection to a MySQL database

Finding which process holds a particular connection to a MySQL database is often not immediately obvious or well documented.

First do this in your mysql command line client:

mysql> show full processlist;
+-----+--------+-----------------+----------+---------+------+----------+-----------------------+
| Id  | User   | Host            | db       | Command | Time | State    | Info                  |
+-----+--------+-----------------+----------+---------+------+----------+-----------------------+
|   2 | root   | localhost       | adspider | Query   |    0 | starting | show full processlist |
| 257 | fotios | localhost:35828 | adspider | Sleep   |   20 |          | NULL                  |
| 259 | fotios | localhost:35832 | adspider | Sleep   |   17 |          | NULL                  |
| 261 | fotios | localhost:35836 | adspider | Sleep   |    3 |          | NULL                  |
| 263 | fotios | localhost:35840 | adspider | Sleep   |    1 |          | NULL                  |
+-----+--------+-----------------+----------+---------+------+----------+-----------------------+
5 rows in set (0.00 sec)

Then, on your Linux command line do this to see which process holds the socket to the port of interest:

[root@li1849-192 ~]# netstat -np | grep 35828
tcp6       0      0 127.0.0.1:35828         127.0.0.1:3306          ESTABLISHED 28509/java
tcp6       0      0 127.0.0.1:3306          127.0.0.1:35828         ESTABLISHED 28432/mysqld

In my case the connection to MySQL was being made by a java process via JDBC

letsencrypt.org makes everyone less secure

letsencrypt.org have taken DV (Domain Validation) certificate issuance requirements a notch down.

So, verification of domain ownership simply requires access to the server where the domain points - no domain administrative contact email verification, no registration with the site/CA required. This is very convenient, especially as the certs are also free and their installation (even their renewal) is done automatically on Apache by letsencrypt's software agent (see here), but it is also fairly insecure, which given that this is a CA that issues SSL certs acceptable by all major browsers, makes everyone less secure.

To explain, using them, an attacker that has compromised a DNS A record can also spoof the website normally under that domain WITHOUT breaking https. That cannot be good.