We’ve just upgraded GitLab v13 to v14 and have encountered some problems with our gitlab-pages config. Pages was working fine with v13, but with v14 we are now getting 502 errors when attempting to access the hosted pages. (We did follow the upgrade path to 13.12.x before upgrading to v14.)
The error seems to be ca-cert/authority related. The last entry in /var/log/gitlab/gitlab-pages/current is
{“error”:“failed to connect to internal Pages API: Get “https://gitlab-vm.intranet/api/v4/internal/pages/status”:
x509: certificate signed by unknown authority”,“level”:“warning”,“msg”:“attempted to connect to the API”,“time”:“2021-07-08T10:35:35Z”}
Here, gitlab-vm is the server name of the VM hosting gitlab and gitlab-pages, but our pages are accessed at https://project.gitlab-pages.intranet. I diddn’t expect the name of the machine to appear in the api url (in the log entry above), but nevertheless the ‘unknown authority’ rather than a ‘cert not found’ type message would tend to suggest that paths are resolving correctly and that it’s an issue with the ca itself (which was previously working fine).
Has anything changed with regard to how CAs / certs are handled in GitLab v14, in particular w.r.t. the API?
Any pointers to where to start looking to fix this would be much appreciated.
After applying the update to 14.2.1 (from 14.0.4) the issue with gitlab-pages appears to be fixed.
Related
I know it sounds a lot like other issues here in Stackoverflow, bear with me, it's not (not that I could tell)
I have a scraping app (using Puppeteer) that I use to scrape an Amazon public page.
It works great, I've debugged it by setting the headless: false and I see it works, and it gives me back the expected result.
The same app fails on Heroku, but the problem is not with launching or using Puppeteer (I have several indications), but probably because I'm being identified as a robot.
The error returned is:
waiting for selector `#link_continue input` failed: timeout 30000ms exceeded
Important to say that the error is a generic Puppeteer error that indicates that the selector I'm waiting for just doesn't appear on-page.
I know it should as it's a selector on the first page I navigate to, and it works locally (as mentioned before) - the selector always exists if the page loads.
I had the exactly same error when I've tried to run the scraping on my local machine before setting a User-Agent header. But at that time I could use the headless:false so I saw in my eyes that I'm being rejected due to illegal operations on their page (robots-like operations) so I was redirected to an error page that didn't contain this selector on it.
For this reason, I suspect it recognizes me as a robot, but I don't know how to debug it, it drives me crazy.
Now, if you'd like to reproduce the problem:
You need to wait for the mentioned selector on this site:
https://sellercentral.amazon.com/hz/fba/profitabilitycalculator/index
and then deploy it to Heroku and try to run it maybe 2-3 times
** Two questions: **
How can I proceed from here, I'm 99.9% sure it's the same issue I had previously, but I can't verify... any suggestions?
Given that this is actually the problem, can anyone suggest an easy-to-use/deploy hosting that also allow easy VPN configuration? I think Heroku doesn't give you to do that unless you have an enterprise account
Thanks
I would like to point out that Amazon is very good at blocking IPs. It is very likely that they already blacklisted IPs of cloud services like Heroku, Azure, etc... Previously I have observed services like Cloudflare, Akamai etc... blacklisting these known IPs.
In this scenario Rotating proxies could help you to avoid getting blocked.
has anyone seen this before so I am getting a 502 bad gateway error on my app, the issue I have is that the detailed error information I am getting says my requested url is https://SOX:80/api however my site is configured to use https://sox.domain.com and the site largely works pulling the various JS files required
my app service name is SOX in the azure dashboard so I assume that is where it is picking up SOX from but I have no idea why it is using this.
So overall the issue had me perplexed... however with more testing I soon figured out what was going on.
my backend is Dotnet core Azure throwing the 502 bad gateway was its way of handling exceptions ultimately the problem was code based.
I am mentioning this purely so that it will help others
my first issue was based on cert handling it seems dotnet runs in a container that is specified by your app name as i mentioned above https://SOX:80
the below was causing my issues
sslPolicyErrors = X509StoreStoreHelper.ValidateSSLPolicy(cert.Thumbprint, cert);
after commenting this out for testing my problem went away(we are putting in a proper fix )
my second issue came from using an unsupported view in Azure SQL master.sys.master_files which again just threw a 502 bad gateway error referencing https://SOX:80
please note I have used https://SOX:80 as a reference to mask the real site.
hope this helps the next person.
Based on your description, I have checked your site (https://sox.azurewebsites.net/) and found that it contains three static files (index.html,generic.html,elements.html). I viewed your website in Chrome incognito window as follows:
I did not find any requests against https://SOX:80/api in your html page or JavaScript files. Please try to access your website in a new incognito window to isolate the cache issue or just press CTRL + F5 to refresh your current page to narrow this issue. Moreover, you need to check whether you have configured URL Rewrite. If you still could not solve this issue, you need to update your question with the details for us to reproduce this issue.
I try to use the rest api of JIRA with nodejs. I want to login, list issues, get issues, resolve issues. But I have problems. I stuck at the beginning.
Firstly, I checked my JIRA version.
It says;
Bug tracking and project tracking for software development powered by Atlassian JIRA (v4.2.1)
Then to be able to see the documentation of this version's rest api,
I navigate to; https://docs.atlassian.com/jira/REST/4.2.1/
When I try to go to the link;
https://MYHOSTNAME/jira/rest/api/2.0.alpha1/version
it throws an error as;
HTTP Status 404 - /jira/rest/api/2.0.alpha1/version
I don't understand, does my JIRA version is not supported? What am I missing?
This is incomplete URL, you need to give the version id
Try to use this URL
/api/2.0.alpha1/version/{id}
Where id is your version number
404(Not Found)- Returned if the version does not exist or the currently authenticated user does not have permission to view it.
200(success) - application/json
Source URL
I had written a mini App in asp classic this week. It worked perfectly on the test server connecting to the test data base. Then yesterday evening I moved it from the test server to the live server updating the connection strings to the live db.
I published it as an application to the default website in the default app pool. Then I tested it and it worked perfectly.
This morning however both myself and another user receive a 500 -internal Server error when we try and save changes to the database(there appears to be no issue reading from the db) yet my two other collogues have no issue at all.
Even more odd is that the same thing is happening on the test server where the code hasn't been changed in weeks. But this morning I cannot commit to the db from there either.
I have attempt to enable more detailed error tracking and logging but the property options for the server are seem unavailable when i tried to set up custom Active Server Pages (ASP) error pages off online tutorials.
The server is used by a lot of people so I was wondering is their a permission issue depending on the user that restricts writting to the database. Or something else that may have changed to allow some users to write data and others to receive the error.
Im very knew to IIS so it may be something glaringly obvious that I haven't considered.
Thanks
This article should help you:
In earlier versions of IIS, error messages from classic ASP scripts
were sent to a Web browser, by default. Because these error messages
might reveal sensitive information to malicious users, IIS 7 and above
disables this feature by default. When your classic ASP scripts
encounter an error in IIS, you receive the following error message by
default:
An error occurred on the server when processing the URL. Please contact the system administrator.
If you are the system administrator please click here to find out more about this error.
I use the TortoiseSVN to checkout source code from URL (browser) and get Error as follows :
Could not resolve hostname : The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for.
I have seen similar error being reported in this forum but wonder what was the exact solution to resolve the said error.
Among solutions proposed were :
'Everything was fixed by yet another reboot (2 reboots after TSVN update).'
posted Nikolay R
'The solution for me involved setting the appropriate proxy settings within Tortoise
SVN -> Settings -> Network (which were already setup in my browser, hence being able
to view the repository fine there). So if you are behind a proxy server, make sure
you setup TSVN appropriately'
posted by Chris
May I know what TSVN/network settings were changed to resolve this error?
Thank you.