Closed dorianim closed 3 years ago
Sure you mean the -c
parameter? This is used when the client is online and the gui is already started.
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?
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.
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:
Once we have this interface, you can use it in linbo_wrapper to tell the GUI to become passive.
Good idea. A control socket would be fine.
What kind of socket would you prefer? And how are you going to talk to it?
Suggest something, I'm not familiar with it.
Unix socket will be better to handle IMHO.
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
Ok, excellent idea. Agreed. Contact me if I can help.
Ok, cool :+1: I am however not totally sure how to structure this yet. I think there are two options
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
I also prefer the second option. As you said different packages would be cleaner. I propose
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?
In my opinion the cleanest possible solution would be this (using four Qt projects):
linbo_cli start:1
=> 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?
I think we should involve the other developers especially @PLanB2008, @kiarn, Maurice to discuss this.
Yes, I totally agree. When is the next developer conference planned?
We should plan one. I'll write to the others.
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?
Yes that's fine. Thank you :)
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.
linbo-remote with option -d in conjunction with -c disables the gui during remote actions:
GuiDisabled = yes
in start.confGuiDisabled = no
in start.confThat's cool! It'll do the job until we have a final solution :) I'll implement it during the next days.
Hi @HappyBasher,
I noticed that the usage of a linbo-remote command like
Sets
StartEnabled
,SyncEnabled
andNewEnabled
to no for all OSs. Would it be possible to create a new parameter likePassiveGuiMode
orGuiInRemoteMode
to clearly indicate that the GUI is not supposed to be used?Regards Dorian