TypeDB•4mo ago

What's the version of your server?

18 Replies

Thank you so much for looking into this @georgii It is running version 3.3.0. Please see the attached screenshot. I am running typedb server in a proxmox LXD container (left). It is started via a systemd unit file.

root@typedb-server-prod:~# cat /etc/systemd/system/typedb-server.service 
[Unit]
Description=Type Server
After=network.target

[Service]
Type=simple
User=typedb-server
Group=typedb-server
WorkingDirectory=/home/typedb-server
Environment="HOME=/home/typedb-server"
ExecStart=bash -c "/home/typedb-server/typedb-all-linux-x86_64-3.3.0/typedb server"
Restart=always
RestartSec=10
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=typedb-server

[Install]
WantedBy=multi-user.target
root@typedb-server-prod:~#

root@typedb-server-prod:~# cat /etc/systemd/system/typedb-server.service 
[Unit]
Description=Type Server
After=network.target

[Service]
Type=simple
User=typedb-server
Group=typedb-server
WorkingDirectory=/home/typedb-server
Environment="HOME=/home/typedb-server"
ExecStart=bash -c "/home/typedb-server/typedb-all-linux-x86_64-3.3.0/typedb server"
Restart=always
RestartSec=10
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=typedb-server

[Install]
WantedBy=multi-user.target
root@typedb-server-prod:~#

Installation is via downloading the .tar.gz file, untar it and that's it.

georgiiOP•4mo ago

Okay, http://localhost:8000 works without LXD What are your LXD settings? Can it be that it internally tries to connect to the binding 0.0.0.0 address, not localhost or 127.0.0.1? Can you try reviewing the configuration and trying this?

kenho811•4mo ago

Hi @georgii When connecting to localhost, it works perfectly, both via i. the webserver and ii. typedb CLI. But when connected to typedb-server-prod in the LXD container, only the typedb CLI works. I am now using the typedb CLI instead. It is so cool. btw, I am using the AI Chatbot on typedb website to correct my TQL and am enjoying it so far. I guess I don't need the webserver for now (except perhaps the visualisation on the webserver)!

georgiiOP•4mo ago

I don't have enough knowledge about LXD to understand what can be wrong, unfortunately. My guess is still the same, and more debugging on the webserver side is needed. I hope your current setup is enough to make you feel comfortable using TypeDB! Maybe @alex will have other ideas when he comes back

kenho811•4mo ago

btw, is there a way to make the server output verbose logs? Hoping to diagnose this issue from time to time

kenho811•4mo ago

@georgii I notice something weird. I have this experiment. Inside the LXD container, I spin up an http server using python with the below

python -m http.server

python -m http.server

Then I try to reach this http server in two ways. i. I try to use both the browser https://studio.typedb.com/connect to connect ; and ii. I try to use postman to connect When using i, the http.server does not output any logs. When using ii. the http.server errors out with path not found (which is expected, because it is just a python server). Is there anything in the browser which prevents it from sending the request to the server? Attached is the screen recording of this experiment

georgiiOP•4mo ago

@Joshua I don't think it's configurable for an executable, right? That's exactly the reason why I thought that it had something to do with the settings of the LXD container 🙂 The request does not reach the application at all @alex , our web expert and the author of TypeDB Studio, will be online tomorrow, and I will ask him to check this out! Maybe there are issues on our side or specific things to consider while using browsers Thanks for exploring this so thoroughly!

kenho811•4mo ago

Another sign is that when I use the web browser to reach localhost, the request headers have more details. when I use typedb-server-prod (the URL for the LXD container), it has nothing in the request For this experiment. - i have nothing running on localhost. - i have typedb runing on typedb-server-prod

georgiiOP•4mo ago

I know nothing about LXD containers, but I am aware that it's a favorite joke of multiplexers and other web servers of a similar job to override or clean some metadata. This is indeed an interesting observation

kenho811•4mo ago

Right. But at the same time, the experiment shows that the python http server in the LXD container is reachable from outside. So that it could be a combination of the settings of LXD container and the typedb web console which made it as if the request did not reach typedb server in the LXD container. 🙏

georgiiOP•4mo ago

There is also a fun fact that tools like curl (and maybe Postman, I don't remember!) do something to requests targeting 0.0.0.0 so it actually works, while it should not I'm not sure it's related to the issue, but it's something to consider while I'm unaware of how networking works in LXD 🙂

alex•4mo ago

let us know how you get on with this! another useful experiment to try- run this in your browser devtools console

await fetch('http://localhost:8000/v1/signin')

await fetch('http://localhost:8000/v1/signin')

this takes Studio out of the equation, it's basically testing if your browser can communicate with your TypeDB server in your LDX container the expected output [in chrome] is

GET http://localhost:8000/v1/signin net::ERR_ABORTED 405 (Method Not Allowed)

GET http://localhost:8000/v1/signin net::ERR_ABORTED 405 (Method Not Allowed)

kenho811•4mo ago

Thanks @alex I have typdb running in the LXD container (typedb-server-prod). Left in the screenshot. Then in chrome, as per your advice, ran

await fetch('http://typedb-server-prod:8000/v1/signin')

await fetch('http://typedb-server-prod:8000/v1/signin')

Got this error

polyfills-DXJ4KTXW.js:2 Mixed Content: The page at 'https://studio.typedb.com/connect' was loaded over HTTPS, but requested an insecure resource 'http://typedb-server-prod:8000/v1/signin'. This request has been blocked; the content must be served over HTTPS.
(anonymous) @ polyfills-DXJ4KTXW.js:2
t.<computed> @ polyfills-DXJ4KTXW.js:1
(anonymous) @ VM853:1
polyfills-DXJ4KTXW.js:3 Uncaught TypeError: Failed to fetch
    at polyfills-DXJ4KTXW.js:2:3140
    at t.<computed> (polyfills-DXJ4KTXW.js:1:13716)
    at <anonymous>:1:7

polyfills-DXJ4KTXW.js:2 Mixed Content: The page at 'https://studio.typedb.com/connect' was loaded over HTTPS, but requested an insecure resource 'http://typedb-server-prod:8000/v1/signin'. This request has been blocked; the content must be served over HTTPS.
(anonymous) @ polyfills-DXJ4KTXW.js:2
t.<computed> @ polyfills-DXJ4KTXW.js:1
(anonymous) @ VM853:1
polyfills-DXJ4KTXW.js:3 Uncaught TypeError: Failed to fetch
    at polyfills-DXJ4KTXW.js:2:3140
    at t.<computed> (polyfills-DXJ4KTXW.js:1:13716)
    at <anonymous>:1:7

========= Then I used https and ran

await fetch('https://typedb-server-prod:8000/v1/signin')

await fetch('https://typedb-server-prod:8000/v1/signin')

And got this

           GET https://typedb-server-prod:8000/v1/signin net::ERR_SSL_PROTOCOL_ERROR
(anonymous) @ polyfills-DXJ4KTXW.js:2
t.<computed> @ polyfills-DXJ4KTXW.js:1
(anonymous) @ VM861:1
polyfills-DXJ4KTXW.js:3 Uncaught TypeError: Failed to fetch
    at polyfills-DXJ4KTXW.js:2:3140
    at t.<computed> (polyfills-DXJ4KTXW.js:1:13716)
    at <anonymous>:1:7

           GET https://typedb-server-prod:8000/v1/signin net::ERR_SSL_PROTOCOL_ERROR
(anonymous) @ polyfills-DXJ4KTXW.js:2
t.<computed> @ polyfills-DXJ4KTXW.js:1
(anonymous) @ VM861:1
polyfills-DXJ4KTXW.js:3 Uncaught TypeError: Failed to fetch
    at polyfills-DXJ4KTXW.js:2:3140
    at t.<computed> (polyfills-DXJ4KTXW.js:1:13716)
    at <anonymous>:1:7

alex•4mo ago

The SSL error almost certainly means the server expected HTTP but you sent it HTTPS As for the other error ... my best guess would be your browser has a security policy that is blocking the HTTP connection? When I run typedb in a local Docker container, https://studio.typedb.com connects to it just fine So I think we're looking at browser security policy or a quirk of LXD or your LXD setup

kenho811•4mo ago

Thanks @alex I further tested out the below command in different webpages

await fetch('http://typedb-server-prod:8000/v1/signin')

await fetch('http://typedb-server-prod:8000/v1/signin')

External websites - URL: https://studio.typedb.com/connect - URL: https://google.com Internal websites (All using http) - URL: http://marimo-prod:8000/ - URL: http://airflow-prod/home All internal websites can run the fetch command successfully. And all the external website fail with this error

VM704:1 Mixed Content: The page at 'https://www.google.com/' was loaded over HTTPS, but requested an insecure resource 'http://typedb-server-prod:8000/v1/signin'. This request has been blocked; the content must be served over HTTP

VM704:1 Mixed Content: The page at 'https://www.google.com/' was loaded over HTTPS, but requested an insecure resource 'http://typedb-server-prod:8000/v1/signin'. This request has been blocked; the content must be served over HTTP

Is it because from the browser, if it is an HTTP website, it can connect to another HTTP website . But if it is a HTTPS website, it cannot connect to an HTTP website?

TypeDB Studio

TypeDB Studio enables software engineers to build data applications faster, with a modern language that avoids complexity.

Google

Search the world's information, including webpages, images, videos and more. Google has many special features to help you find exactly what you're looking for.

kenho811•4mo ago

@alex Thanks to your suggestion, I found it! The issue is indeed with the browser. I asked deepseek to solve the issue and it told me to - go to chrome://flags/#unsafely-treat-insecure-origin-as-secure - add the http site under Insecure origins treated as secure It is working like a charm!!! I am so happy it is working now!!! cc: @georgii

alex•4mo ago

awesome! I wonder if localhost and 0.0.0.0 are special exemptions to Chrome's rule of blocking HTTP requests in HTTPS sites 🤔 https://groups.google.com/a/chromium.org/g/security-dev/c/PbbRn9Mwd3s aha

Private Network Access dev here, sorry I missed this email in my inbox. Chris is correct: this deprecation in itself only requires that the initiating website be served over HTTPS, not the target website. This is already the case for you, so you should have nothing to worry about. The requirement on the target website comes from Mixed Content, which has shipped for a while in Chromium. Mixed Content prevents secure websites from making insecure fetches in most cases, but not when talking to localhost. This carveout is intended to be permanent.

georgiiOP•4mo ago

An interesting case with things to learn from 🙂

Gaming

Programming

What's the version of your server?

Did you find this page helpful?