iDRAC? That’s what it’s for. It’ll allow remote access to your server but somebody would still need passwords, etc. it’s been around for ages so there’s going to be good practice guides on how to set it up.
this post was submitted on 18 Dec 2023
14 points (100.0% liked)
Self Hosted - Self-hosting your services.
11410 readers
2 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules
- No harassment
- crossposts from c/Open Source & c/docker & related may be allowed, depending on context
- Video Promoting is allowed if is within the topic.
- No spamming.
- Stay friendly.
- Follow the lemmy.ml instance rules.
- Tag your post. (Read under)
Important
Beginning of January 1st 2024 this rule WILL be enforced. Posts that are not tagged will be warned and if not fixed within 24h then removed!
- Lemmy doesn't have tags yet, so mark it with [Question], [Help], [Project], [Other], [Promoting] or other you may think is appropriate.
Cross-posting
- [email protected] is allowed!
- [email protected] is allowed!
- [email protected] is allowed!
- [email protected] is allowed if topic has to do with selfhosting.
- [email protected] is allowed!
If you see a rule-breaker please DM the mods!
founded 3 years ago
MODERATORS
I was under the impression you need a license to use remote access via idrac. Do you know if it also requires a second run of ethernet cable separate from the server NIC?
An r320 is new enough that iDrac Express (two IPs on one interface) is available in the BIOS. The server needs a license for some features (like remotely attaching an ISO, and remote KVM), but not for the basics like controlling the power.
Idrac, wake on lan, and plug-in behavior: power in bios are all great options here.
Answering the question directly, your intuition is right that you'll want to limit the ways that your machine can be exploited. Since this is a Dell machine, I would think iDRAC is well suited to be the control mechanism here. iDRAC can accept SNMP commands and some newer versions can receive REST API calls.
But stepping back for a moment, is there any reason why you cannot configure the "AC Power Recovery" option in the system setup to boot the machine when power is restored? The default behavior is to remain as it was but you can configure it to always boot up.
From your description, it sounds like your APC unit notifies the server that the grid is down, which results in the OS shutting down. Ostensibly, the APC unit will soon diminish its battery supply and then the r320 will be without AC power. When the grid comes back up, the r320 will receive AC power and can then react by booting up, if so configured. Is this not feasible?
Due to my understanding of it, I was hesitant to use AC recovery in the case that the power goes down more than once in a short period. It could drain the UPS to the point that it might not be able to sustain enough runtime for a proper shutdown. But I'm also a bit confused about the setup here. If the server is sent a signal to shutdown due to a grid outage, who is telling it the grid was restored? The server would always detect power because of the battery backup, so I don't think AC Power Recovery would work in this case, no? I believe I have the UPS comm server (probably apcupsd) installed on the server itself, so there's no way for it to know to wake up unless from an outside source.
Maybe you have some further incite into how to make that setup work properly.
I'm brainstorming here, but would it be possible/feasible to have the Unifi Dream Machine execute a script everytime it turns on telling the server idrac to power up. I'd have to see if the UDM has that ability as well. The UDM turning on would only really happen if power was restored from an outage. Otherwise I could send a command manually once I have access to the network.
If the server is sent a signal to shutdown due to a grid outage, who is telling it the grid was restored?
Ah, I see I forgot to explain a crucial step. When the UPS detects that grid power is lost, it sends a notification to the OS. In your case, it is received by apcupsd. What happens now is a two step process: 1) the UPS is instructed to power down after a fixed time period -- one longer than it would take for the OS to shut down, and 2) the OS is instructed to shut down. Here is one example of how someone has configured their machine like this. The UPS will stay off until grid power is restored.
In this way, the server will indeed lose power, shortly after the OS has already shut down. You should be able to configure the relevant delay parameters in apcupsd to preserve however much battery state you need to survive multiple grid events.
The reason the UPS is configured with a fixed time limit -- as opposed to, say, waiting until power draw drops below some number of watts -- is that it's easy and cheap to implement, and it's deterministic. Think about what would happen if an NFS mount or something got stuck during shutdown, thereby running down the battery, ending up with the very unexpected power loss the UPS was meant to avoid. Maybe all the local filesystems were properly unmounted in time, but when booting up later and mounting the filesystems, a second grid fault and a depleted battery state could result in data loss. Here, the risk of accidentally cutting off the shutdown procedure is balanced with the risk of another fault on power up.
I'm going through the same thing with a pfsense bare metal nuc that doesn't have power settings in bios. I'm planning to set up a switchbot linked with a switchbot smart plug to automatically press the power button.
Set up the smart plug in a different outlet with something that automatically turns on when power is restored (isp router, or maybe your ups).
In switchbot app, when plug power use goes up from 0, tell switchbot to press pfsense nuc power button.
Something to that effect. I'm still waiting on stuff to arrive. You could also just set up a switchbot and manually press the button whenever you want remotely through the app.