I've just released the public repository of RebootX On-Prem (https://github.com/c100k/rebootx-on-prem), letting anyone to connect and manage their infra on their smartphone.
In my case the infra is pretty simple : 3 Raspberry Pi. But I'd love to have your feedback and see interesting use cases you could use this for.
I have lots of ideas for the next steps. For example, creating a Prometheus integration as well.
Looking forward to hearing from you and I would be glad to help if you encounter any issue getting started with the repo.
But it's clear that your goal is to reboot on-prem servers through your phone. Something I've wanted to do with rundeck and a very simple web app that uses the rundeck API.
I'm using ansible right now, and a custom playbook.sh script for some sort of auditing - what was run where and by whom. Kinda works but much more maintenable than let's say ansible tower.
Should be very possible though, Rundeck has Ansible integration and with Ansible playbooks you do anything.
So all your custom website has to do is provide buttons for those pre-defined Ansible playbooks in rundeck.
I can email my house, which is at least encrypted in transit, and then I stack an extra couple nonstandard abuses of email headers to validate the source, which all is impossible with SMS.
https://en.m.wikipedia.org/wiki/HTC_Wizard
It had a slide-out keyboard which I loved. I would even write code remotely to fix a critical bug, and deploy it, while I was out having lunch with my team. No need to rush back to the office. Granted, I had better eyesight 20 years ago, but now I just use readers, can see the screen just fine.
Some random HTTP solution is the last thing I would trust.
What do you mean by "traulling open ssh ports" ?
https://www.tutorialspoint.com/python-script-to-restart-comp...
You can also use two scripts for security:
1. One that’s privileged for the shutdown command.
2. One with no privileges to accept the network request (eg Flask/REST), safely parse it, and send a message to process 1.
You could send the message in many ways. It doesn’t even have to be parsed or contain more than one byte. The reboot process might act if it receives any message from the other process in their dedicated channel.
Set both of these processes to run on startup however you normally do on your system.
If not a message, you could have the network enabled process write to a file in a shared directory. The reboot process periodically checks for the file’s existence. If it sees it, then it reboots the system. That file can be cleared on startup. I say on startup to reduce the risk of any kind of contention causing a problem later on.
The reboot process could also be easily ported to a systems language for resource efficiency. I’d keep the network-facing app in a memory-safe language just in case. D or Rust could handle both, though.
Follow these steps : https://github.com/c100k/rebootx-on-prem/blob/master/.github...
And then :
(cd ./impl/http-server-go && GOARCH=amd64 GOOS=openbsd go build -o rebootx-on-prem-http-server-go-openbsd-amd64 -v)
By adapting the arch if needed. Not tested, but it should work.
Sharing my current use case in case it's useful:
reboot PARTITION: to reboot to a different partition
systemctl stopping a service and starting another
launching a wget checking if wget is still up and hasn't crashed
I think the correct term here would be "on-premises".
A premise and a premises are not related concepts except in the sense that the "premise" of this comment is to let you know that "premises" is the correct term to use.
I'll also accept "on-prem" because it could reasonably be a shortened form of "on-premises" (even though most people probably don't realize this and are instead reinforcing their misconception when they use it).
