Live data from Hacker News

Show HN: rallyup – Lightweight Wake-on-LAN Scheduler

github.com

21–28 of 28 posts

Re: Show HN: rallyup – Lightweight Wake-on-LAN Scheduler

#22

Is wake on LAN any good these days? I remember it being flaky in the late 90s early 00s...

I have weird desktop system on ASRock motherboard. I have 2 ethernet (10gbe and 1gbe) ports and WiFi build in. i have 10gbe network so ofc I want to use 10gbe port.

the issue that I discovered after many hours of debugging is that 10gbe port is powered down completely on suspend/power off. so it have no way to work.

because I had limited number of ethernet ports available I set up system to use wake up over WiFi (with wake also on key rotation or disconnect)

Re: Show HN: rallyup – Lightweight Wake-on-LAN Scheduler

#23

Earlier quoted context omitted.

I only had one problem with it, and that was that it isn't enough to enable it in the BIOS, but I needed to flip a switch on Windows and set up a systemd service on Linux (I dual boot). For Linux set it to "g": https://wiki.archlinux.org/title/Wake-on-LAN#Make_it_persist... For Windows you need to enable "Wake on Magic Packet": https://www.windowscentral.com/how-enable-and-use-wake-lan-w...

I always wondered: why make it so difficult to turn on? Is it a security issue? I mean, an off-by-default OS setting and an off-by-default BIOS setting? How dangerous is this thing??

It draws more power because the NIC can't power off completely. So Microsoft and every hardware vendor are incentiviced to turn it off to look good. (And probably to please regulations)

That it is defaulted off I feel is motivated, but to make it so hard to turn it on is pretty pathetic.

The fury Microsoft generated by turning it off in a Windows update still fuels me. I had a remote PC that I need to access remotely during holiday season. And Microsoft turns off my ability to power it on, with me left trying to figure out why I can't access the machine anymore.

Re: Show HN: rallyup – Lightweight Wake-on-LAN Scheduler

#24
post #12

Would love to see exactly this but running on an ESP style board (with Ethernet). As well as an API or web interface to trigger manual WoL calls. Nice project, thanks for sharing!

Thanks! Getting it working on an embedded system would be a fun addition and a nice intro/training project for one of our new engineers (I think…).

What type of API are you thinking of? It already runs on a YAML config, so maybe a web server that takes the config as a JSON body instead?

Re: Show HN: rallyup – Lightweight Wake-on-LAN Scheduler

#25

Earlier quoted context omitted.

I only had one problem with it, and that was that it isn't enough to enable it in the BIOS, but I needed to flip a switch on Windows and set up a systemd service on Linux (I dual boot). For Linux set it to "g": https://wiki.archlinux.org/title/Wake-on-LAN#Make_it_persist... For Windows you need to enable "Wake on Magic Packet": https://www.windowscentral.com/how-enable-and-use-wake-lan-w...

"set it to 'g'". Awesome. G for maGic, I presume?

Yep, pretty sure. m is for multicast. From arch wiki: d (disabled), p (PHY activity), u (unicast activity), m (multicast activity), b (broadcast activity), a (ARP activity), g (magic packet activity)

Re: Show HN: rallyup – Lightweight Wake-on-LAN Scheduler

#26
post #2

Is the project named spinup or rallyup? The HN post title differs from the GitHub repo

Thanks for catching that! Updated to match. The names I liked was already taken on crates.io but never got it out of my head

A very relatable struggle. Cool project! I remember getting into WoL as a kid playing with our home PC, felt like magic to press a button on my phone and watch the fully powered off machine come to life.

Never sorted out a reliable enough system for it to be practically useful, but this gives me some ideas...

Re: Show HN: rallyup – Lightweight Wake-on-LAN Scheduler

#28
post #27

Isn't it bad design in the first place if you require "right order" of boot up? What if some, but not all, servers crash and reboot? How do you ensure the correct order in that case?

That’s a good point. Ideally, if we had complete control over how applications behave on startup, we could design them to “self-heal” and avoid dependency issues altogether. However, many of the components in the systems we work with are either closed source or require more experience and expertise to modify.

We’ve also noticed that, in practice, for many data-critical production systems, many of our customers prefer to manually control the boot process to confirm data integrity.

The scenario of partial crashes is interesting. I need to think about how to handle that a bit more. Thanks for the feedback!

Post reply on HN