I've tried following the guide provided on supabase:
https://supabase.io/docs/guides/self-hosting
I went with Option 1 & 2 in which both resulted in the same error 404 when I try to reach localhost:8000/v1?APIKEY=.
192.168.32.1 - - [17/Jun/2021:07:32:29 +0000] "GET /v1 HTTP/1.1" 404 48 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36"
Or perhaps there isn't a management page like the hosted one?
Here are my started containers.
From the top of the page you linked to:
The self-hosted version of Supabase does not include a UI yet. We are working on this in stages, starting with our UI library (more context).
They recommend various Postgres clients as alternatives.
Related
I am working with ready spree shop site. It is worked fine on production deploy, from this source code tree. But in development it asks basic auth. Database is backup form production. Users account which is worked on production are not helps pass this basic auth. It looks slike this:
Rails console:
192.168.0.1 - - [28/Jan/2020:14:52:28 +0000] "GET / HTTP/1.0" 401 - 0.0271
Nginx log:
192.168.0.1 - - [28/Jan/2020:17:52:28 +0300] "GET / HTTP/1.1" 401 0 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0"
Nginx error log is empty
What is this? How to run it properly? How to find and fix this feature or oprion? What "Beta access" string from dialog window on screen is about? What can I do to make situation more clear?
We have an ALB load balancing 2 targets. But we are experiencing 502 responses from ALB quite often, that interrupts UI to throw an error. Our application is UI based running on node js and uses socket.io.
Sample log from ALB access log.
https 2019-06-10T09:29:46.987095Z app/DES-G1-USE4-ext-elb/7c8fddfc050d66f6 184.51.199.55:55418 10.72.72.155:8888 0.000 8.697 -1 502 - 876 485 "GET https://designer-use4.genesyscloud.com:443/socket.io/?EIO=3&transport=polling&t=Mj0kC0w HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:us-east-1:361190373704:targetgroup/DES-G1-USE4-tg-desg/4cc8feabb9ee8f89 "Root=1-5cfe2302-b19c6d5059c2fc6096e048e0" "-" "session-reused" 0 2019-06-10T09:29:38.289000Z "forward" "-" "-"
Here -1 502 - means that request is forwarded to the backend by ELB, but the target is not responded. And the connection is b/w ELB and target is closed somehow. As per https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html.
In our application log, there is no trace of this request reached our application.
Please help us to debug this issue from ALB.
Make sure that your application is responding with a 200-399 response code on the / path. The behavior that you are mentioning is often because the Load Balancer Health Check is not able to verify that your application is running correctly. Also, make sure that your server is able to respond on HTTP that path ( HTTP/2 is not yet supported ).
Potential causes of this:
firewall: make sure security groups of your application server and ELB are able to connect to each other on the designated port.
health check: the load balancer will kick an application server that crashes a few times. Make sure that the application server is attached and showing as healthy on the dashboard.
I selected bellow area and pressed command+C.
cloud shell capture
Following string is pasted from my clipboard.
You are viewing an offline list of runtimes. For up to dat
My browser is Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
This is a known limitation.
Note: FireFox/IE may not support clipboard permissions properly.
For more details, refer "Limitations of Azure Cloud Shell".
My Rails application is deployed on Amazon elastic beanstalk using Docker. Web requests flow into an nginx web server that forwards them to the thin rails server residing in docker. Somewhere along the way there's a bottleneck. Once every 50 requests (or so) I see nginx reports serving time which is x40 higher than the time the rails thin server reports.
here's an example:
NGINX (7490ms):
146.185.56.206 - silo [18/Mar/2015:13:35:55 +0000] "GET /needs/117.json?iPhone HTTP/1.1" 200 2114 "-" "Mozilla/5.0 (Macintosh;
Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/40.0.2214.115 Safari/537.36" 7.490 7.490 .
THIN (rails server): 171ms
2015-03-18 13:35:48.349 [INFO] method=GET path=/needs/117.json
format=json controller=needs action=show status=200
duration=171.96 view=109.73 db=29.20 time=2015-03-18 13:35:47
Can anyone supply some guidance how to troubleshoot such a situation? How do I find the source of the response time difference? I guess it could be either nginx or docker or thin or linux.
It sounds like one of the thin processes is under load doing a heavy task and nginx is still sending requests to the busy one. If there were a problem of queuing in Thin, the request would take a short time to be processed itself, but longer to get to the top of the queue. So first, check others requests before or around that request.
Second, if you are using upstream to serve (http://nginx.org/en/docs/http/ngx_http_upstream_module.html), apparently you could get among others $upstream_response_time and try to log it.
Third, you could also try to reproduce a similar setup in dev/qa and try a stress test. If you manage to reproduce it consistently, you could see number of request on each queue (i.e. http://comments.gmane.org/gmane.comp.lang.ruby.unicorn.general/848).
I am trying to use fiddler on IPad by connecting it to PC by wireless connection so I could use auto-responder to 'mock' some data.
Tutorial tells me that I should use my machine IP to connect IPad and check if it works, my problem is that I have multiple IP's (or at least it seems that I do).
One candidate would be 192.168.1.23 another 192.168.1.41
How to check which of IP addresses is localhost, or they both are pointing to same place?
This is just 'an' answer not 'the' answer, but this worked for me.
First I navigated to http://192.168.1.23:8888/ and got
Fiddler Echo Service
GET / HTTP/1.1
Host: 192.168.1.23:8888
Proxy-Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
This page returned a HTTP/200 response
Originating Process Information: chrome:10568
To configure Fiddler as a reverse proxy instead of seeing this page, see Reverse Proxy Setup
You can download the FiddlerRoot certificate
I then navigated to http://192.168.1.41:8888/
and got same exact response.
I believe it is safe to assume that both IP addresses are pointing to same place. Not sure if this is always the case, but it is true in mine.
It would appear that I am using multihoming.