The other day I made a silly mistake when modifying some IAM policies on our terraform environment, I applied a change where I wanted to ADD a policy, when in fact it took this as the ONLY policy to exist so wiped out some of the vital IAM policies for service accounts to run GKE etc. Not my best day to say the least (an lesson learnt!).
Everything has been put back to normal manually for now, as the service account permissions were never set via TF anyway - they're the sort of permissions that are applied when enabling APIs on GCP so its done by them in the background. Our GKE cluster can now be managed again and can autoscale etc.
However, now when I run our terraform plan I receive a 500 error on a resource that was never previously a problem (redacted sensivite info):
2021-09-09T18:47:50.794Z [INFO] provider.terraform-provider-google-beta_v3.60.0_x5: 2021/09/09 18:47:50 [DEBUG] Retry Transport: Finished waiting 4s before next retry: timestamp=2021-09-09T18:47:50.794Z
2021-09-09T18:47:50.794Z [INFO] provider.terraform-provider-google-beta_v3.60.0_x5: 2021/09/09 18:47:50 [DEBUG] Retry Transport: request attempt 5: timestamp=2021-09-09T18:47:50.794Z
2021-09-09T18:47:50.794Z [INFO] provider.terraform-provider-google-beta_v3.60.0_x5: 2021/09/09 18:47:50 [DEBUG] Google API Request Details:
---[ REQUEST ]---------------------------------------
GET /v1/services/servicenetworking.googleapis.com/connections?alt=json&network=projects%2F411211291013%2Fglobal%2Fnetworks%2F**********&prettyPrint=false HTTP/1.1
Host: servicenetworking.googleapis.com
User-Agent: google-api-go-client/0.5 Terraform/1.0.6 (+https://www.terraform.io) Terraform-Plugin-SDK/2.4.4 terraform-provider-google-beta/dev
X-Goog-Api-Client: gl-go/1.14.5 gdcl/20210211
Accept-Encoding: gzip
-----------------------------------------------------: timestamp=2021-09-09T18:47:50.794Z
2021-09-09T18:47:51.601Z [INFO] provider.terraform-provider-google-beta_v3.60.0_x5: 2021/09/09 18:47:51 [DEBUG] Google API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 500 Internal Server Error
Cache-Control: private
Content-Type: application/json; charset=UTF-8
Date: Thu, 09 Sep 2021 18:47:51 GMT
Server: ESF
Vary: Origin
Vary: X-Origin
Vary: Referer
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 0
{
"error": {
"code": 500,
"message": "An internal exception occurred.,
"errors": [
{
"message": "An internal exception occurred.\nHelp Token: Ae-hA1PlQyCLBCgXD3Lle******************************************vhHU8zy1z9h",
"domain": "global",
"reason": "backendError"
}
],
"status": "INTERNAL"
}
}
│ Error: googleapi: Error 500: An internal exception occurred.
│ Help Token: Ae-hA1ONdq************************************m0k, backendError
│
│ with google_service_networking_connection.private_vpc_connection,
│ on vpc.tf line 81, in resource "google_service_networking_connection" "private_vpc_connection":
│ 81: resource "google_service_networking_connection" "private_vpc_connection"
Has anyone had similar happen before? Things I've tried so far:
I've triple checked all permissions are now as they were
I can successfully get/list the details of service_networking peering as my account manually as well as the terraform service account that runs the plan
Service networking peering is showing fine in the console
Update: This was due to a missing permission on the servicenetworking API. The default service account created needed roles/servicenetworking.serviceAgent permission again after it had been wiped.
More details here
Related
I am trying to execute a simple POST request from nifi using the InvokeHTTP processor. The target server responds with the response "error: invalid request". I am able to POST successfully with curl from nifi's host.
I have set the processor's HTTP method to "POST", and the URL to "http://myhost:1234", other fields are set to the defaults. The incoming flowfile's mime.type is application/json and the flowfile content is valid json.
Here's what I tried (server names etc. were replaced with fake names):
I confirmed that the target server is ok with curl using seemingly equal parameters to the InvokeHTTP processor (with and without the --http2 flag, equally on the InvokeHTTP processor I tried with the "HTTP/2 Disabled" property on true and false):
curl -v --http2 -POST -H "content-type: application/json" http://myhost:1234/ -d '\[{"key":"value"\]'
For the data I used the actual content of the flowfile used by InvokeHTTP.
* Trying <ip>...
* TCP_NODELAY set
* Connected to myhost (<ip>) port 1234 (#0)
> POST / HTTP/1.1
> Host: myhost:1234
> User-Agent: curl/7.61.1
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
> content-type: application/json
> Content-Length: 17
>
* upload completely sent off: 17 out of 17 bytes
< HTTP/1.1 201 Created
< Server: <servername>
< Content-Length: 0
<
* Connection #0 to host myhost left intact
With InvokeHTTP, the response is routed to the NoRetry output with the following attributes added to the flowfile:
invokehttp.response.body
error: invalid request
invokehttp.response.url
http://myhost:1234/
invokehttp.status.code
400
invokehttp.status.message
Forbidden
I tried logging the request by setting the org.apache.nifi.processors.standard.InvokeHTTP logger to DEBUG. The resulting logs:
2022-11-17 11:22:03,384 DEBUG [Timer-Driven Process Thread-4] o.a.nifi.processors.standard.InvokeHTTP InvokeHTTP[id=<guid>]
Request to remote service:
http://myhost:1234/
date: Thu, 17 Nov 2022 11:22:03 GMT
user-agent:
2022-11-17 11:22:03,384 DEBUG [Timer-Driven Process Thread-4] o.a.nifi.processors.standard.InvokeHTTP InvokeHTTP[id=<guid>]
Request to remote service:
http://myhost:1234/
date: Thu, 17 Nov 2022 11:22:03 GMT
user-agent:
2022-11-17 11:22:03,391 DEBUG [Timer-Driven Process Thread-4] o.a.nifi.processors.standard.InvokeHTTP InvokeHTTP[id=<guid>]
Response from remote service:
http://myhost:1234/
content-length: 23
server: <servername>
2022-11-17 11:22:03,391 DEBUG [Timer-Driven Process Thread-4] o.a.nifi.processors.standard.InvokeHTTP InvokeHTTP[id=<guid>]
Response from remote service:
http://myhost:1234/
content-length: 23
server: <servername>
At this point I don't know what to do. I don't know if the logged requests are purposefully limited to these fields or if there's actually a lot of information missing from the requests themselves such as the payload and the content type. I'm also wondering why the requests are logged twice, or whether they're actually sent twice (I'm on a single node environment).
I expect this processor to be able to perform such a simple request without much trouble, and have confirmed that the target server is not the issue. Did I miss something? How can I debug this further (e.g. see the actual raw request sent by InvokeHTTP)?
Thank you.
Check the mime.type attribute. That is automatically translated to a header for you, and you could be sending form-encoded parameters as the mime type or something like that instead of the expected json.
First time poster with a bizarre issue I am having. I usually install software through conda, but from one moment to the other I stopped being able to use conda install because of a 403 I get from conda trying to access some configuration files. When trying to download those files with wget --spider --debug https://conda.anaconda.org/anaconda/noarch/current_repodata.json, I get the same 403 error.
DEBUG output created by Wget 1.19.4 on linux-gnu.
Reading HSTS entries from /home/jsequeira/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'current_repodata.json' (UTF-8) -> 'current_repodata.json' (UTF-8)
Spider mode enabled. Check if remote file exists.
--2020-07-30 11:25:59-- https://conda.anaconda.org/anaconda/noarch/current_repodata.json
Resolving conda.anaconda.org (conda.anaconda.org)... 104.17.92.24, 104.17.93.24, 2606:4700::6811:5d18, ...
Caching conda.anaconda.org => 104.17.92.24 104.17.93.24 2606:4700::6811:5d18 2606:4700::6811:5c18
Connecting to conda.anaconda.org (conda.anaconda.org)|104.17.92.24|:443... connected.
Created socket 5.
Releasing 0x000056545deb1850 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 5 to SSL handle 0x000056545deb2700
certificate:
subject: CN=anaconda.org,O=Cloudflare\\, Inc.,L=San Francisco,ST=CA,C=US
issuer: CN=Cloudflare Inc ECC CA-3,O=Cloudflare\\, Inc.,C=US
X509 certificate successfully verified and matches host conda.anaconda.org
---request begin---
HEAD /anaconda/noarch/current_repodata.json HTTP/1.1
User-Agent: Wget/1.19.4 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: conda.anaconda.org
Connection: Keep-Alive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 403 Forbidden
Date: Thu, 30 Jul 2020 11:25:59 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
CF-Chl-Bypass: 1
Set-Cookie: __cfduid=d3cd3a67d3926551371d8ffe5a840b04f1596108359; expires=Sat, 29-Aug-20 11:25:59 GMT; path=/; domain=.anaconda.org; HttpOnly; SameSite=Lax
Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 01 Jan 1970 00:00:01 GMT
X-Frame-Options: SAMEORIGIN
cf-request-id: 044111dd9600005d4732b73200000001
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Vary: Accept-Encoding
Server: cloudflare
CF-RAY: 5baeb8dc2ba65d47-LIS
---response end---
403 Forbidden
cdm: 1
Stored cookie anaconda.org -1 (ANY) / <permanent> <insecure> [expiry 2020-08-29 11:25:59] __cfduid d3cd3a67d3926551371d8ffe5a840b04f1596108359
URI content encoding = ‘UTF-8’
Closed 5/SSL 0x000056545deb2700
Remote file does not exist -- broken link!!!
These files are accessible through the browser, and were always accessible with wget and conda until yesterday, when I was installing some tools not related to these network accesses. How can wget fail to download them?
So this was fixed by reinstalling apt-get. Some configuration file there must have been messed up.
I have wifidog installed on a TP-LINK
(openwrt 18.06.2)
I have wifidog-auth-laravel installed on a OVH Debian
github /wifidog/wifidog-auth-laravel)
If I use curl, chrome and wget; I get the pong response for the authetication url
But if wifidog attempts to get the pong response I get a 301 Permanantly moved response.
How can that be?
[7][Mon May 20 13:44:54 2019][5977](centralserver.c:302) Level 1: Connecting to auth server example.com:80
[7][Mon May 20 13:44:54 2019][5977](centralserver.c:331) Level 1: Successfully connected to auth server example.com:80
[7][Mon May 20 13:44:54 2019][5977](centralserver.c:141) Unlocking config
[7][Mon May 20 13:44:54 2019][5977](centralserver.c:141) Config unlocked
[7][Mon May 20 13:44:54 2019][5977](centralserver.c:147) Connected to auth server
[6][Mon May 20 13:44:54 2019][5977](wd_util.c:116) AUTH_ONLINE status became ON
[7][Mon May 20 13:44:54 2019][5977](simple_http.c:77) Sending HTTP request to auth server: [GET /ping/?gw_id=EC086B35444C&sys_uptime=1820&sys_memfree=6096&sys_load=0.70&wifidog_uptime=3 HTTP/1.0
User-Agent: WiFiDog 1.2.1
Host: example.com
]
[7][Mon May 20 13:44:54 2019][5977](simple_http.c:87) Reading response
[7][Mon May 20 13:44:54 2019][5977](simple_http.c:111) Read 725 bytes
[7][Mon May 20 13:44:54 2019][5977](simple_http.c:124) HTTP Response from
Server: [HTTP/1.1 301 Moved Permanently
Date: Mon, 20 May 2019 13:44:54 GMT
Server: Apache/2.4.25 (Debian)
Location: http://example.com/ping?gw_id=EC086B35444C&sys_uptime=1820&sys_memfree=6096&sys_load=0.70&wifidog_uptime=3
Content-Length: 415
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved here.</p>
<hr>
<address>Apache/2.4.25 (Debian) Server at example.com Port 80</address>
</body></html>
]
[4][Mon May 20 13:44:54 2019][5977](ping_thread.c:191) Auth server did NOT say Pong!
[7][Mon May 20 13:44:54 2019][5977](firewall.c:140) Marking auth server down
I found the solution:
The Wifidog userAgent formed the url different from the other user agents:
a workaround is in the wifidog.conf
AuthServer {
Hostname example.com
SSLAvailable yes
Path /
PingScriptPathFragment ping?
LoginScriptPathFragment login?
PortalScriptPathFragment portal?
MsgScriptPathFragment gw_message.php?
AuthScriptPathFragment auth?
}
bivm:/home/biadmin/Desktop # curl -i "http://bivm.ibm.com:14000/webhdfs/v1/tmp/newfile?op=OPEN"
HTTP/1.1 401 Access to the HttpFS server is restricted. Please obtain proper credential from the BigInsights Console first.
Content-Type: text/html; charset=iso-8859-1
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 1589
Server: Jetty(6.1.x)
I am getting the above mentioned error, when I am trying to access a file in my cluster using the WebHDFS REST API call through the HttpFS server (running on port 14000 by default). Please advice.
I have a web server using nginx, configured with HTTPS and Basic Authentication.
I'm attempting to query it with my WebClient with PowerShell
$wc = new-object System.Net.WebClient
$wc.Credentials = Get-Credential
return $wc.DownloadString($url)
This works fine with the following $urls
https://server.com
https://server.com/
https://server.com/directory/
https://server.com/page.php
https://server.com/directory/index.php
But for the following $urls, I get The remote server returned an error: (401) Unauthorized.
https://server.com/directory
https://server.com/otherdirectory
https://server.com/directory/directory
I thought at first it was due to redirection, but that wouldn't make sense given some of the working examples. Perhaps it's my nginx configuration?
I currently believe this is a bug in the WebClient class. Here is a summary of my interactions with the server:
------------------------------------------------------------------------
GET /directory HTTP/1.1
Host: example.com
------------------------------------------------------------------------
HTTP/1.1 401 Unauthorized
Server: nginx/1.4.6 (Ubuntu)
Date: Fri, 27 Jun 2014 02:37:45 GMT
Content-Type: text/html
Content-Length: 203
Connection: keep-alive
WWW-Authenticate: Basic realm="sup"
<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.4.6 (Ubuntu)</center>
</body>
</html>
------------------------------------------------------------------------
GET /directory HTTP/1.1
Authorization: Basic bmFjaHQ6aGVsbG8=
Host: example.com
------------------------------------------------------------------------
HTTP/1.1 301 Moved Permanently
Server: nginx/1.4.6 (Ubuntu)
Date: Fri, 27 Jun 2014 02:37:46 GMT
Content-Type: text/html
Content-Length: 193
Location: http://example.com/directory/
Connection: keep-alive
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.4.6 (Ubuntu)</center>
</body>
</html>
------------------------------------------------------------------------
GET /directory/ HTTP/1.1
Host: example.com
------------------------------------------------------------------------
HTTP/1.1 401 Unauthorized
Server: nginx/1.4.6 (Ubuntu)
Date: Fri, 27 Jun 2014 02:37:47 GMT
Content-Type: text/html
Content-Length: 203
Connection: keep-alive
WWW-Authenticate: Basic realm="sup"
<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.4.6 (Ubuntu)</center>
</body>
</html>
------------------------------------------------------------------------
At this point, the WebClient throws an exception, stating that the server returns the error stated in the question.
It should probably provide the auth token with the third request, or at the very least respond to the 401 with another request with the auth token provided.
I would like to have this confirmed by someone else (preferably with .NET 4.5.2) so I can accept this as the answer.