Headless install for Linux please!

[pbelbin]

Trying to try it out on Linux.

Given 'ontime' is a web-based tool, is there really a reason why this package, on Linux, seems to need all sorts of support libraries for an X-based application?

There's an installation package for Docker, so I'm unclear why it's being packaged the way it is for native installation on Linux.

?

[cpvalente]

Hi @pbelbin , thank you for reaching out.

Ontime is really an UI made in react and a server running in nodejs
The two are completely detached, ie: you could potentially run Ontime without our UI.

At build time, we compile the UI and add it to be served by the server process; users reaching out to the server (via the browser) would get the UI along with all the runtime data. This means that, at runtime, all you really need is the server process.

In the docker image, this is what you get. An image that has node and starts ontime's server process in it.

To facilitate the distribution to other platforms, we package the app with Electron.
Electron leverages a chromium install to give us a desktop app feeling and (more importantly) manage the packaging and cross platform distribution, as well as management of the nodejs dependency.

The extra libraries you are finding are likely related to chromium, coming from Electron.
We dont exactly need it, but we are paying the price of shipping chromium for the convenience that we give to the users.

I am unsure exactly what is the issue that we are pointing at here, is your question just a curiosity on "whats all of this" or have you found any potential issues that we should look into?
Either way, I hope my answer is not off target and that helps with some context.

[pbelbin]

Thank you for responding.

Hmmmm. Well, I tried installing it on a remote linux machine, since it's, like you say, a Node server with a web based front end. The bit about also providing an Electron app, I guess, is what's causing the issue.

I'm trying to install your app package, since that's what you've provided for Linux. Each time I tried running the installer, it complained about a missing library, so I ended up installing a bunch of libraries, and after that was done, it complained that it didn't have the DISPLAY environment variable set.

So..... what's the best solution here for really installing like the Docker situation, but not in a Docker image? (machine does not have Docker installed).? ie: a native linux install without the X demands. Just the node server side of things.

I wonder if, now that it's complaining about X not being available, it's actually now able to run the Node server aspect of it?

[pbelbin]

I suppose, I can just download the project zip file from GitHub and go down the dev build path.....

[cpvalente]

Yes, that is a good option if you want the slimmest possible install.

You can follow the steps to make a package and just skip the last bit
https://github.com/cpvalente/ontime/blob/master/DEVELOPMENT.md#create-an-installable-file-windows--macos--linux

[cpvalente]

I apologise @pbelbin, I just realised you had another answer here, I am sorry I answered the wrong thing.
The self build path is definitely OK if you want to have the smallest footprint, but not particularly convenient.

If you are having issues with the installation we should definitely figure it out

I have just realised that I misread what you are requesting. If I understand correctly, you want to run Ontime from terminal without a UI?

We dont really have a distribution of the node process on its own.
I guess building yourself is not particularly complex since you will already have to install all the dependencies on your own.

If there is enough user interest in consuming a node package of the app we can look into making it happen

[pbelbin]

Hmmmmmm. OK. I have it built, but, I would like to expose access to it via cloudflare tunnel.

With cloudflare tunnel, they let me set up a public hostname that maps to an internal port address, like http://localhost:3000.

But, that's only working for access to the front end, and the front end wants to make queries to the same host name at port 4001 to talk to the API/server. So, it breaks, because I'm unable to set up the same hostname that maps to the server backend port.

Is there a configuration setting somewhere where I can cause back-end server API requests to go via a different host name instead of it wanting to talk to the same host name via port 4001?

eg: ontime.[my domain] -> http://localhost:3000, while api.ontime.[my domain] -> http://localhost:4001 ? don't know if that would work for sure.

[pbelbin]

Another option, I think, would be to use a path, like: http://ontime.[my domain]/app -> http://localhost:3000 while http://ontime.[my domain]/api -> http://localhost:4001

Or, put another way, I suppose, is there a recommended way to deploy so that it's usable via Cloudflare's tunnel service?

https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/

[pbelbin]

I have just realised that I misread what you are requesting. If I understand correctly, you want to run Ontime from terminal without a UI?

Yes, exactly. Linux server sitting somewhere, and just install the node servers so that someone can then use the web page remotely. Web only.

I did do a local 'dev' type install/execution to get it running, but, as you can see (earlier comment), now, due to the desire to be able to use Cloudflare's 'tunnel' service, seem to be running into a different kind of issue.

[jwetzell]

Hello @pbelbin, we have made some progress on a headless version of ontime. Here is a link to a zip with binaries for win, linux and mac that should run a headless ontime. If you don't mind trying it out and providing any feedback that would be greatly appreciated.

[pbelbin]

OK, I will give it a try! Thank you. I'll let you know how it goes.

[pbelbin]

Testing it now, I managed to install (well, run) it without any drama at all on Linux, and, I see that it's also usable via cloudflare tunnel as well!!! Double-yay! Thank you! Keep up the good work!

[jwetzell]

Thanks for the quick reply! We will continue down this route for headless and hopefully this will be a good option for non-ui setups, can definitely imagine some cool use cases!

[jwetzell]

@pbelbin thanks for helping us test this process out. If I could ask for one more test from you. If you have a NodeJS version >= 18 on a system could you try the following.

• run the command: npm install -g @getontime/cli@dev
• run the command: ontime (this will be added by the above command)

This should launch a headless instance of ontime.

[pbelbin]

OK, yep, that works just fine in terms of installing and running.

I would say though, that some care ought to be taken with the instructions you've provided.

If the machine had a truely global Node install, I'd be installing the command (and all the dependencies) for everyone on the machine.

I'd much rather that this not be leaking into a global command on the machine.

I used a non-global Node with the PATH set up so that it points to the bin folder within the local node, and install -g created a link to the ontime there. So, that's not bad, I suppose.

Another alternative is to create a local package.json and a script there for "ontime": "ontime" and for this to then be used via npm run ontime.

But, yeah, it was nice to just be able to run the command, and not have to manually download, unzip, etc, etc.

[jwetzell]

Good things to consider and look into before writing up some docs. Another method for running with this is using just npx @getontime/cli@dev which I believe installs in a temp area that is more scoped to the running user.

[pbelbin]

That also is true.

Very nice to be able to get it running with so little hassle.

Thank you!

[jwetzell]

@pbelbin hopefully last update on this! The cli version of ontime has been merged in and will be rolled out with the regular release of ontime starting with v3.3.0! I'll close out this issue with that update and if you have any further feedback feel free to reach out or open up another issue!

[pbelbin]

many thanks! makes it soooo much simpler for installing!