boa-fix-upgrade script is not compatible with IPv6 and breaks nginx config

I replaced the "IPv6-without-letters-and-:-plus-IPv4" with the complete IPv6 address only, in /data/disk/o1/config/includes/nginx_modern_include.conf in 2 places as well as the same 2 places in /var/aegir/config/includes/nginx_modern_include.conf and nginx passes the config test and restarts fine.

I tried to include both IPv4 and IPv6 addresses in those files in the allow directive, but I couldn't get the syntax right if 2 allow directives are even allowed in that file. Would an array work within the outer array?

I imagine that this fix must be made to all the other nginx .conf files in both the o1 and the /var/aegir locations, unless you are going to put the fix in the hot-fix script?

This problem MUST have been caused by the hot-fix upgrade script, since the nightly cron run was the first time nginx was (attempted) restarted since I ran the hot-fix update script yesterday. I have confirmed this problem on a second server - the IPv6 address's numbers ONly run straight into the IPv4 address, and nginx won't be able to restart. I believe the date of the hot-fix update script I ran was nov 28 or 29, even though I ran it on nov 30. I'll manually correct the nginx_include.conf files in both locations for now, and wait to hear from you if a new version of the hot-fix script needs to be run or not.

I have posted the output - anonymized, from the above commands, and I used 33.333.33.333 as the correct IPv4 address

I fixed my octopus by adding ONLY the full IPv6 IP address to the include files, and it seems to work fine. I have just seen your latest commit (Use IPv4-strict hostname and IP checks only.) and I want to make sure I am not setting myself up for trouble by putting the IPv6 IP address in those include files. Could this be a potential problem with a future boa up-stable? Do you recommend only listing the IPv4 address in those include files? Thanks for the clarification.

I woke up today, Sunday to find the server down, no sites, no ssh, nginx hadn't re-started at some point on the early Sunday AM (Saturday night cron run?) Is there something special that happens once a week at this time?

I looked at the same config include files and found that the "allow" had been changed to 127.0.0.1: (around line 128 for advanced and modern_include):

at /data/disk/fast1/config/includes/nginx_modern_include.conf

###
### Allow local access to support wget method in Aegir settings
### for running sites cron.
###
location = /cron.php {
tcp_nopush off;
keepalive_requests 0;
access_log off;
allow 127.0.0.1;
deny all;
try_files $uri =404;
fastcgi_pass 127.0.0.1:9090;
}

###
### Allow local access to support wget method in Aegir settings
### for running sites cron in Drupal 8.
###
location = /core/cron.php {
tcp_nopush off;
keepalive_requests 0;
access_log off;
allow 127.0.0.1;
deny all;
try_files $uri =404;
fastcgi_pass 127.0.0.1:9090;

Is this how it is suppossed to be, or should the server's IPv4 address be after allow in those two places?

I have also seen that the similarily named files in /var/aegir/config/includes/
( such as nginx_modern_include.conf) also have the localhost IP 127.0.0.1 instead of the IPv4 - can you confirm that this is intended, please?

Thank you for your response.

I have not run the fix-upgrade-script again. I did run a boa up-stable to install a second octopus instance, but that was 4 or 5 days ago, and the server only was down this morning, Sunday morning.

You never answered my # 9, and it was your bad script that got me into this mess in the first place. So, I have done everything you have asked me to help you improve your script(s). WOuld you please answer this for me:

Should the config include files in either

a) o1/config/includes, or

b) var/aegir/config/includes

have 127.0.0.1 for the "allow" for location = /cron.php and location = /core/cron.php ? If so, which files (the ones in var/aegir ... only or all of them including those in the o1 /config/includes location)?

- or are all of those values (in BOTH the o1 and the var locations suppossed to be the iPv4 address. Please answer this. Thank you

OK, I followed your instructions and there were two errors -
After "syncing provision backend db_passwd" :
ERROR 1045 (28000) Access denied for user 'root'@'localhost' (using password = yes), and

and after "var/aegir/.drush/provision/platform/migrate.provision.inc":
ERROR 1045 (28000) Access denied for user 'aegir_root'@'localhost' (using password = yes),

This happened during the Aegir Master Instance Upgrade during the barracuda up-stable , and it happened again for 'root' and for 'o1' MySQL user during the octopus up-stable all aegir.

I then ran the boa-fix-upgrade.sh script and since then notice that in the optopus o1 instance "localhost" did not verify, and I cannot delete a few clone platforms (unable to connect with db errors). Because I forced the MySQL rebuild during the barracuda up-stable, I am going to run it all again, to see if that solves this access denied problem. I use strong passwords.

I received the exact same errors during the second up-stable. Do you recommend using the sync passwords script that I had to use once before?

I know how to deal with MySQL, this whole problem began because I didn't know that the upgrade script would not work if I added the servers IPv6 address to /etc/hosts - that was the problem, it seems. Thank you for the syncpass commands - that did the trick.