502 Bad Gateway (nginx) after Update to 2.3
-
Ah, not familiar with the pfSense patch system. :)
OK, first thing to do is reverse what you have done, put everything back as it was.
Next, go into pfSense and select Package Manager from the System Menu, select 'Available Packages' and find the 'System Patches' package and install it.
You will now have a 'Patches' option in the system menu - Select it.
Click on add new patch.
In the URL/Commit ID enter the patch ID 028be76, give a description in the Description box and press save.
Now click on Test, it should say can be applied cleanly. Now click on Apply.
Job done.
-
Thank you again. I replaced the original file and re-applied the patch the proper way for pfSense. Other than some extra spaces I had it correct.
The router continues to be stable with this patch. -
That's good.
The advantage of using the patch system, apart from saving you a lot of work, is that you have a setting in the patch that allows for it to be automatically re-applied when you update pfSense. It checks to see whether it can be re-applied cleanly and does so. Obviously, if the file(s) the patches are applied against change in a way that means the patch will not cleanly apply then it does not do so, so when you use patches it's advisable to check after an update. For the average user who is not on the beta trail this means only a two or three times a year, beta testers should check every time they update.
-
tward800 thanks for your feedback, even if there is no problems, feedback is good, as it helps developers make a decision on if a patch is safe enough to rollout or not.
-
The patch gives me some errors when I test it:
/usr/bin/patch –directory=/ -t -p2 -i /var/patches/5a269040d9477.patch --check --forward --ignore-whitespace
Hmm... Looks like a unified diff to me...
The text leading up to this was:|From 2c131b10b25db593331048d4f2b28fbf9bf5662e Mon Sep 17 00:00:00 2001
|From: marjohn56
|Date: Wed, 29 Nov 2017 23:18:51 +0000
|Subject: [PATCH] Increase FPM process availability in high ram systems
|
|To reduce chance of nginx gateway error when interacting with FPM backend, this patch does the following, starts up extra FOM server processes at startup, allows more to stay running on standby, increases automatic shutdown time from 5 seconds to one hour. On systems with a gig or more of ram
|–-
| src/etc/rc.php_ini_setup | 29 +++++++++++++++++++++--------
| 1 file changed, 21 insertions(+), 8 deletions(-)
|
|diff --git a/src/etc/rc.php_ini_setup b/src/etc/rc.php_ini_setup
|index 5ce0ef7a31..03bc1178d9 100755
|--- a/src/etc/rc.php_ini_setup+++ b/src/etc/rc.php_ini_setup Patching file etc/rc.php_ini_setup using Plan A... Hunk #1 succeeded at 265. Hunk #2 failed at 317. Hunk #3 failed at 340. 2 out of 3 hunks failed while patching etc/rc.php_ini_setup done I'm using a new Pfsense 2.4.2 install and using the patch manager from the gui.
-
Try patch 2c131b1.
Yes, I had to re-sync with upstream. In doing so my Github desktop threw one and I had to pull it back and re-do the PR. However, it's against 2.4.3, so it may not work for 2.4.2 now.
-
@marjohn56:
Try patch 2c131b1.
Yes, I had to re-sync with upstream. In doing so my Github desktop threw one and I had to pull it back and re-do the PR. However, it's against 2.4.3, so it may not work for 2.4.2 now.
Exactly the same error, so indeed not for 2.4.2. I'll do the changes manually :)
-
@marjohn56:
Try patch 2c131b1.
Yes, I had to re-sync with upstream. In doing so my Github desktop threw one and I had to pull it back and re-do the PR. However, it's against 2.4.3, so it may not work for 2.4.2 now.
I am getting patch fetch failed when I try this
-
Works fine for me, just re-entered that I'd and fetched it again, no problem.
-
@marjohn56:
Works fine for me, just re-entered that I'd and fetched it again, no problem.
Does this look right?
-
Strange I get a different ID.
Try the full ID 2c131b10b25db593331048d4f2b28fbf9bf5662e
-
That fails as well
here is what is in the logDec 5 16:46:00 php-fpm 70317 /system_patches.php: Download file failed with status code 0\. URL: https://github.com/pfsense/pfsense/commit/2c131b10b25db593331048d4f2b28fbf9bf5662e.patch -
This is silly. ???
Here's the full URL that I have just used.
https://github.com/pfsense/pfsense/commit/2c131b1.patch
-
will not fetch that one either. This is weird
-
BeerCan, can you get into https://github.com
If your browser gives you an error, you will have problems downloading. It is something to do with HSTS.
-
BeerCan, can you get into https://github.com
If your browser gives you an error, you will have problems downloading. It is something to do with HSTS.
I can't get in with FF or chrome
-
Even stranger… :)
I think this is one for the Netgate developers to answer, as they maintain it.
-
I don t think netgate maintains the github.com certificates.
It sounds to me like like a invasive proxy with ssl bump.Edit:
Or perhaps pfBlocker dnsblock list that redirects to a pfSense hosted site for tracking blocking statistics.. -
It works fine for me though, and others apparently, it's only BeerCan who is having an issue I think.
PiBa, can you try and fetch the patch, see if it's working for you?
To be honest, I only have to click on the link I posted yesterday and I can see the patch.
I did not think that netgate maintains the Github certs, just the pfsense repository, it's just that maybe they may have an idea what's causing the issue.
I've just checked Github's cert and it reports it as OK on my system.
-
Fetch patch works fine, both the link in a browser and the 2c131b1 id in patches package.
So a proxy like squid with ssl bump or dns-intercept (DNSBL pfBlockerNG) are the likely causes imho.