Repository navigation
Idea: Shutdown machines in linbo_sync #209
Description
Activity
I can implement the Backend, but someone else has to do the frontend for this 🙂
Hi,
I wanted to achieve this feature, and I would love to have it in my network, but there's too many constraint for this :
- for Linbo, nothing to say, it's already done with
linbo-remote - for Linux : you need a root ssh access for this, which many of us don't have for security reasons, and you need a ssh server on the client. If it's the case, then you have to
- provide a ssh access with key
- or tipp each time the password or save it in a config file, which is also insecure ( I must consolidate it in ajenti ).
- for Windows© : I don't support it
I can naturally develop my own methods for my own network, but the webui has to stay as general as possible, and I don't see a simple way to achieve this, because you need control on the client.
Arnaud
- for Linbo, nothing to say, it's already done with
Yes, you are right, It's not optimal. A solution for linuxclients could be to automatically setup ssh in the linuxclient7 or with Linbo. But we need to discuss this.
I'm glad you came up to this idea, that's exactly what I wanted to silently suggest :)
Reacted by Dorian ZedlerReacted by Dorian ZedlerJust adding my 2 cents to this:
I would like to see something like this as well. I wouldn't mind to share the public key of the school server to all the linux clients as requirement.
For security reasons one could add another user to these machines (eg. lmn-system), and provide this key just for this user having the permissions to shutdown.
I personally would not go this route. In my opinion the private key on the lmn server is secure enough to be able to login on all linux clients in the education network - but I get your point.For the implementation: This should not be part of the webui. The webui can of course trigger this but we need to have this separated like all the other functions we have right now.
This is the basic idea of the lmn7 rewrite: There must not exist any feature in the webui an admin cannot use directly via a cli tool.If @dorianim is okay with it I would suggest he can provide a backend solution which we can add to linuxmuster-base or its own package (we already had this discussion in the last developer conference if such things needs its own package or should be added to base, i would prefer last.). Afterwards we, or should I say @kiarn ;), can implement this in the linbo_sync plugin. Having the backend tool in linuxmuster-base would make this easier because the plugin does not have to check for the separate plugin as dependency...
This was way more in detail than intended... :)
I would not like to use ssh. It is a pain to setup in windows and its not particularly fast to connect to it.
I would prefer the following solution:
- the server runs an mqtt broker
- all clients run a daemon which connects to that broker
- the clients publish some status values like OS, uptime, logged in users, ...
- the server publishes actions for the clients to execute like shutdown, reboot, suspend, ...
This way we have a bidirectional communication between server and client, wich ist very flexible and could be used for a variety of things. And most importantly, we'd have a unified interface for all clients.
I would suggest using golang for the daemon, as it compiles to a static binary with no dependencies and can run on any platform.
I agree that this should be shipped with base.I'd love this solution, but it would require some effort and you guys would need to become familiar with mqtt and (in case we decide to use it) gloang.
I get your point and see the benefits of having a real unified client-software running on each client.
On the other hand we would've the disadvantage of developing and maintaining another tool rather than using default standards provided for the operating system.I agree not using ssh for windows, using rpc commands should be the way to go for this, I did not adressed windows at all in my post.
Before choosing a toolchain we should first discuss if we wan't to choose door one, simply communicate via default system calls like ssh and rpc or take the yellow envelope in form of a more complex but also more flexible communication via a system daemon.The problem with using the default tools is again, that we don't have a nice way for determining what os the client is running. Currently we only use port scanning and this may be unreliable in some cases.
So in the worst case, we'd have to try both which may make the process kinda slow.In addition to that, we would not have the ability to get fine-grained information fron the client in a fast way. E.g. uptime, logged in useres, os version, available updates, ...
But I am getting off-topic, sorry. We should start with a small proof-of concept which will only provide the functionality for this issue. If that works and we are hapoy with it, we can go further 😅
Reacted by Andreas Till and MCGood, we all have a lot of differents ideas, what a time to be creative.
Let's talk about this in our next meeting, I think it is then simplier to focus on our needs and roadmap for this.Reacted by Dorian Zedler and MCWe have this functionality within a simple bash script we use for some years now.
Host OS detection is done by checking certain ports (2222 -> Linbo) and timeouts (for devices powered off or disconnected).
Shutdown/Restart is done via public key ssh (password-access was also possible before) - in windows this works fine with the now included Linux subsystem.This script also allows to issue Linbo commands that are then run with the -p parameter before a restart.
If this script is of any interest, I can provide it. But technically it is quite basic stuff.
Reacted by highTower.SU
Hi,
I think, it might be a nice to have feature to be able to shut down machines in Linbo_sync. It could work like this:
ssh -o ConnectTimeout=2 -o StrictHostKeyChecking=no -p 2222 root@$IP /sbin/poweroffssh -o ConnectTimeout=2 -o StrictHostKeyChecking=no root@$IP shutdown nownet rpc -S $IP -U global-admin%$PASSWORD shutdown -t 1 -fFor windows, it might be possible to use the
--use-kerberosparameter. If that does not work, the user has to input their password. (see the docs)Regards,
Dorian