search

linuxmuster / linuxmuster-linbo

Linbo imaging system for linuxmuster.net
23 stars 22 forks source link

Explicit start.conf parameter for "linbo-remote mode" #161

Closed dorianim closed 3 years ago

dorianim commented 3 years ago

Hi @HappyBasher,

I noticed that the usage of a linbo-remote command like

linbo-remote -g ubuntu_vanilla -w 60 -c sync:1

Sets StartEnabled, SyncEnabled and NewEnabled to no for all OSs. Would it be possible to create a new parameter like PassiveGuiMode or GuiInRemoteMode to clearly indicate that the GUI is not supposed to be used?

Regards Dorian

HappyBasher commented 3 years ago

Sure you mean the -c parameter? This is used when the client is online and the gui is already started.

dorianim commented 3 years ago

In my case this command wakes all clients of the group ubuntu_vanilla, waits for 60 seconds and syncs OS 1. When I looked into the start.conf of the clients, I noticed, that StartEnabled, SyncEnabled and NewEnabled set to no for all OSs. Where is that done? Should it do something different?

HappyBasher commented 3 years ago

This is done on boot by init.sh. The buttons are disabled to prevent users from starting an os etc. while the admin is doing linbo-remote stuff with the client. Anyway this makes only sense if the client boots an os or shuts down finally. With the new gui we can think about an alternative procedure.

dorianim commented 3 years ago

Ok. I was thinking about adding some kind of interface that allow to control the GUI from outside (eg. for that exact purpose). I came up with two options:

  1. Using a file
  2. Using a Socket (UNIX or TCP) Using a file would be simple and straightforward in my Opinion. What do you think?

Once we have this interface, you can use it in linbo_wrapper to tell the GUI to become passive.

HappyBasher commented 3 years ago

Good idea. A control socket would be fine.

dorianim commented 3 years ago

What kind of socket would you prefer? And how are you going to talk to it?

HappyBasher commented 3 years ago

Suggest something, I'm not familiar with it.

HappyBasher commented 3 years ago

Unix socket will be better to handle IMHO.

dorianim commented 3 years ago

One possible solution would be this: I create a second static Qt binary which would be called linbo_cli (or similar). This binary would connect to the GUI via a socket and could be used to send instructions to it. eg.: linbo_cli become_passive

This would be a first step. I think we could also use this opportunity to get rid of redundant code. As of now, all code in linbo_wrapper is also present in the GUI. I think this is unnecessary. Instead we could also create commands like linbo_cli start:1

What do you think about that @HappyBasher ? Maybe this could be a start to "untangle the Linbo Code-Monster" ;)

The cool thing is that we can do this step-by-step.

Regards Dorian

HappyBasher commented 3 years ago

Ok, excellent idea. Agreed. Contact me if I can help.

dorianim commented 3 years ago

Ok, cool :+1: I am however not totally sure how to structure this yet. I think there are two options

  1. Leave the backend and the GUI in one binary and make the linbo_cli talk to ist
  2. Split the backend into a different binary (linbo_backend) which runs as a daemon and make the gui and the cli talk to it. This would have the benefit that linbo_cli could be run independent of linbo_gui (could be different packages), I am not sure if this is necessary, though.

What do you think? Probably the second option would be cleaner, but I am not sure if it is worth the effort... Another question in this regard: How are you planning to deal with the different packages in the future? Will linuxmuster-linbo depend on linuxmuster-linbo-gui7?

I am excited to discuss and get started on this :slightly_smiling_face:

Regards Dorian

HappyBasher commented 3 years ago

I also prefer the second option. As you said different packages would be cleaner. I propose

HappyBasher commented 3 years ago

What do you thing about a linbo_cli web service with a rest api remotely secured with ssl and an api key and plain connections from localhost? Or is this not practible for this purpose?

dorianim commented 3 years ago

In my opinion the cleanest possible solution would be this (using four Qt projects):

  1. linbo_backend: runs as a daemon, controls all Linbo actions, its state machine and provides an API server (of some kind) -> replaces and extends linbo_cmd. I would like to have the option to keep an open connection (using a custom TCP-based protocol) from clients to the backend, as this allows linbo_backend to send updates to its clients, eg. for logging and when its state changes. If we use just REST on HTTP, the clients would have to poll constantly to make this possible.
  2. linbo_client_libs: A Qt Library that contains all code that is necessary to communicate with the backend, will be used in linbo_cli and linbo_gui. This should have its own repo and can be included into the linbo_cli and linbo_gui repos using Git subdirs.
  3. linbo_cli: command line client for linbo_backend. It connects to the linbo_backend server and can be used to execute basic tasks and retrieve information. eg: linbo_cli start:1
  4. linbo_gui: graphical client for linbo_backend. It also connects to the linbo_backend server and provides the same functionality as linbo_cli, just in GUI form.

=> This would bring the maximum possible flexibility. The linbo_client_libs could event be used in linbo_remote to talk to the linbo_backend of clients from the server.

I just realized that this might be much more work than I initially anticipated. And it might even be too much, it will be a huge amount of work to set this up. Another project of mine works exactly like this, over there I have a server that is similar to what the linbo_backend would be and many client applications that can be compared to linbo_cli and linbo_gui. I got all of this to a point where it works mostly flawless, but it took about two years in which I spent most of my free time on it. Maybe we should rethink this and come up with a simpler (probably less optimal) solution to make it less complicated.

What is your opinion and do you have an idea how to simplify this?

HappyBasher commented 3 years ago

I think we should involve the other developers especially @PLanB2008, @kiarn, Maurice to discuss this.

dorianim commented 3 years ago

Yes, I totally agree. When is the next developer conference planned?

HappyBasher commented 3 years ago

We should plan one. I'll write to the others.

HappyBasher commented 3 years ago

Would it be possible to create a new parameter like PassiveGuiMode or GuiInRemoteMode to clearly indicate that the GUI is not supposed to be used?

I will implement this as `GuiDisabled = yes|no' in the global section, default is 'no', of course.

Ok?

dorianim commented 3 years ago

Yes that's fine. Thank you :)

HappyBasher commented 3 years ago

Disabling the gui during remote sessions makes only sense with online commands (linbo-remote parameter -c). Therefore disabling the gui during boot (-p) will be removed and replaced with the ability to disable and restore the gui before and after online commands. This implies a new linbofs helper script gui_ctl to disable and restore the gui, which will be invoked by linbo-remote with parameter -d in conjunction with -c. So far.

HappyBasher commented 3 years ago

linbo-remote with option -d in conjunction with -c disables the gui during remote actions:

dorianim commented 3 years ago

That's cool! It'll do the job until we have a final solution :) I'll implement it during the next days.