Show HN: Manage on-prem servers from my smartphone
github.comHi everyone,
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.
If you're on iOS, you can create a Shortcut that runs a script over SSH. I'm not sure if it's one of the native actions, or provided by an app called "Actions" which you can download from the App Store and which defines a bunch of useful actions.
Interesting. Do you have a specific link ? I didn't find anything. My main interrogations are how the private key and command are stored.
Just looking at it on my phone, you need to "enable scripting" in Settings > Shortcuts > Advanced. Then when you add the shortcut, you can select password authentication or SSH Key. If you use a key, it generates one for you, and there is a button to "copy public key" which you'll then need to add to authorized_keys on your server. I assume the private key is stored locally on the device.
I've been managing remote (and local) servers from my smartphone with RDP and SSH for almost 2 decades, not sure why I would use anything else.
I've tried from a bunch of different phones to use RDP, and apart from launching some SW/service or run a batch, I just cannot without the pixels/screen. It's just too darn small. I wonder what smartphones you got.. some phablet with 7"-8" or a typical 6"-6.4"?
Right now a Galaxy Fold 4. It's pretty great. But I was doing this stuff on an HTC wizard back in 2005.
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.
I mean IMHO RDP has too many vulnerabilities too often to have it exposed to any network your phone also can promiscuously join. I would far rather expose a simple HTTP API for limited actions I consider safe.
Nobody should be exposing a service like this directly to the internet. It should either be behind or wrapped by some better authentication system.
Smartphones can certainly join VPNs and be secure using RDP. I don't have RDP exposed publicly.
Some random HTTP solution is the last thing I would trust.
What about something with something like TailScale?
Behind a VPN is fine, at least for personal use. At work, phones are never able to get on the same network as our servers though, and considering the random nature of apps people often install, my recommendation would be that they should not.
An underrated advantage of ChromeOS is easily running mobile apps that expose intuitive UI like this. Combined with the floating window mode I have enjoyed using bambu handy for 3d printing and vSphere mobile.
If you use Python, you can restart the computer in one line using subprocess. Example:
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.
Yes of course, the spec can be implemented in any language. I've used Go mainly for personal preferences and portability with only one binary to scp on the server. I'm going to try to propose other implementations as you suggest.
Go totally slipped my mind. It's also a good choice for the design I outlined.
After one of my AWS accounts (with 2fa and an email I basically never used) was compromised I'm incredibly careful to expose services like this onto the public internet. What steps did you take to ensure the pipeline of your app to server endpoints was secure and in theory not vulnerable to someone traulling open ssh ports etc?
You could put it behind a Wireguard VPN. That way you aren't exposing SSH or the like directly on the internet. Properly-configured SSH with public key authentication is not something I worry about though.
Ouch, I'm sorry to hear that.
What do you mean by "traulling open ssh ports" ?
I think they likely meant "trawling": https://en.m.wikipedia.org/wiki/Trawling. (ie casting a net and "fishing" for open ssh)
Does it have FreeBSD support and any instructions for not using it with docker?
Of course you can compile the server from source if you have Go and the OpenAPI generator JAR (https://github.com/OpenAPITools/openapi-generator?tab=readme...)
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.
Cool, Ill give it a whack. Thanks.
neat but ssh from your phone is hard to beat
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
Nice use case. I'd be curious to see how it behaves by using the SSH feature.
> on-premise
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).
You're absolutely right. The fun thing is that I googled it and saw a couple of articles doing the comparison between both. And to be honest, that's why I used the "on-prem" shortcut most of the time.
I think it's very complicated and I'm not sure what it does, or why it has a go http server and calls itself a specification.
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.
The Go HTTP server is an implementation of the spec (swagger.json). It actually plays the same role as your web app. It's just to make it compatible with the native app, and not rely on Web.
How happy are you with that setup? Would you use it for anything more complicated, like app deployments or maintenance tasks on your on prem / vpss?
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.
I haven't done it yet, just been fantasizing about it.
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.
surely it's easier to send SSH commands over SMS (with the appropriate protections) than use this janky Go thing?
There is probably no amount of protections which are appropriate for using SMS to send commands to a server. It's not only unencrypted the entire trip but SIM-jacking and caller ID spoofing are all very well-worn exploit paths.
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.
webmin
Thank you for a trip down memory lane :) Not seen that name in decades!