Restricting access

Important for restricting access:

https://httpd.apache.org/docs/2.4/howto/access.html

Added conf file to the extra folder: block-offending-ips.conf

Here:

/usr/local/etc/httpd/extra

Code to add to file:

<LocationMatch "/.*">
<RequireAll>
Require all granted
Require not ip 39.94.137.167
#Repeat the "Require not ip ..." for each IP you want to block
</RequireAll>
</LocationMatch>

The linked to httpd.conf with:

Include /usr/local/etc/httpd/extra/block-offending-ips.conf

Other methods are available for limiting access including hosts and domains. But, I was seeing some hacking attempts and want a method to block IP addresses that are appearing in the tail commands:

tail -n 200 -f /usr/local/var/log/httpd/access_log
tail -n 200 -f /usr/local/var/log/httpd/error_log

I feel like I can control things more effectively now. Wish there were a simple tool to add IP addresses rather than editing this file. Would make life easier.

PHP 8.0

Not so fast. I can get it up and running, but WordPress is vexed by it, so back to 7.4. It only got released today, so no harm

But, I’m noticing interesting anomalies on how to make sure we have things running right and it centers around su vs. regular user on brew services. Me thinks I have a problem. Not sure yet, since it is working. But, need to check why I have an error in services list on regular use, versus sudo use.

Will check back on this.

Yet another issue with mysql

Seems I had corrupted database again. Most likely because I continue to use beta releases of MacOS and have to keep updating Homebrew to keep up. But maybe not…

This time, even with recovery from timemachine backup, I still had trouble with the Aria plugin engine. It had a corruped log file that I couldn’t seem to lick.

Finally found a reference to a routine to run on all my MIA files –

aria_chk -r *.MIA

When followed with deletion of all the aria_log.xxx files, this seems to resolve all the remaining issues with the tables. All of this predicated with…

brew services stop mariadb

Watching the log file (Mac-Pro.lan.err) found the errors and all clean now…

2020-04-05 7:47:50 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-04-05 7:47:50 0 [Note] InnoDB: Uses event mutexes
2020-04-05 7:47:50 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-04-05 7:47:50 0 [Note] InnoDB: Number of pools: 1
2020-04-05 7:47:50 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-04-05 7:47:50 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2020-04-05 7:47:50 0 [Note] InnoDB: Completed initialization of buffer pool
2020-04-05 7:47:50 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-04-05 7:47:50 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-04-05 7:47:50 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait …
2020-04-05 7:47:50 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2020-04-05 7:47:50 0 [Note] InnoDB: Waiting for purge to start
2020-04-05 7:47:50 0 [Note] InnoDB: 10.4.11 started; log sequence number 1383411434; transaction id 1238187
2020-04-05 7:47:50 0 [Note] InnoDB: Loading buffer pool(s) from /usr/local/var/mysql/ib_buffer_pool
2020-04-05 7:47:50 0 [Note] Plugin 'FEEDBACK' is disabled.
2020-04-05 7:47:50 0 [Note] InnoDB: Buffer pool(s) load completed at 200405 7:47:50
2020-04-05 7:47:50 0 [Note] Server socket created on IP: '::'.
2020-04-05 7:47:51 0 [Note] Reading of all Master_info entries succeeded
2020-04-05 7:47:51 0 [Note] Added new Master_info '' to hash table
2020-04-05 7:47:51 0 [Note] /usr/local/opt/mariadb/bin/mysqld: ready for connections.
Version: '10.4.11-MariaDB' socket: '/tmp/mysql.sock' port: 3306 Homebrew

All golden!

Another fix…

Again necessary to fix mariadb by using TimeMachine. Log showed a bad shutdown this morning corrupted tables and couldn’t be fixed. So, back to TimeMachine and got yesterdays backup for the folder:

/usr/local/var/mysql

Then, restarted with

mysql.server start

… and all was good with the world again.

Then decided to make sure and ran the database upgrade to make sure everything looked good.

mysql_upgrade -u root -p [password]

Everything good with OK all the way down the page. Nice!!

Brew doctor says all is good!