nomad: last time I tried to use NUT I think I ran it in a pkgsrc zone

Hello. :)

hi everyone, I was trying to build nginx package from omnios-extra repository using command ./build.sh -r file:///my/repo/dir (from omnios-extra/build/nginx) or ./build-128.sh. Everything is ok, but then I try to install nginx / nginx-128 to my own image (for example using kayak), build is crashes with a error, because nginx package requires

nginx-common package. I also use pkgrepo list -s file:///my/repodir and see what this my repo doesn't contains nginx-common (only nginx or nginx-128).

What am I doing wrong?

the only one mention of nginx-common package in omnios-extra is in omnios-extra/build/nginx/nginx.p5m file

sjorge, I just need the upsmon part so my OmniOS hosts know when to shut down. They listen to a primary that I've already got running elsewhere. No need for a zone for that.

Or am I misunderstanding what a 'pkgsrc zone' is?

Well you can run pkgsrc in the GZ too, I just find it clutters it up. Although I am not sure what the best way to run it their is. The pkgsrc zone brand is just very convenient

@nomad : not that I am aware of. I did file a ticket a couple of years ago, hoping someone would tinker with this (maybe me, maybe not), but it did not get addressed yet.

this said, it should not be hard to build it - prerequisites and techniques are documented, several OmniOS VMs are among the NUT CI farm builders.

in recent months I did turn an eye towards packaging issues, although largely in the context of getting OBS to build NUT on numerous distros, so far more as addition to multi-platform CI than as end-user deliverable. There are probably some wrinkles to iron out regarding package layout and which files belong where, which is a common problem to solve across the dozens of OSes.

Ideally the lists would be maintained once and included into different spec/deb/p5m/... recipe files.

as another long-standing pain point (since Solaris 10/SXCE) with SMF, we are are missing out on late-shutdown integration with the UPS power-cycling

with init scripts (Solaris 9 and before) or framework supported hooks (systemd) or perhaps some hand-off into initrd-style environment running/mounted outside what the OS thinks is `init`, it was/is possible to check AFTER all services/processes stopped or were killed, and maybe filesystems remounted read-only, the magic file and see if `upsmon` initiated the system shutdown...

if it did - talk to the UPS (start another copy of the driver) to tell it to cut power (and hopefully wake up when wall power returns)

and for devices that do not power-cycle the load if wall power did already return, this part of the logic can sleep for a "long time" (longer than batteries would hold) and `reboot`

so the systems are not halted forever

I suppose with SMF this could require that someone creates a special restarter that can run such post-shutdown hooks, or extend the standard one, but so far I failed to dedicate time to it or coerce someone else to do this

the last I looked, the show-stopper is that SMF startd kills all userland processes 90s after shutdown was initiated (IIRC the delay was even hard-coded?) so any such scripts talking to the UPS and "sleeping long" as part of usual service shutdown are really short-lived

with some UPSes it is possible to command "turn off or reboot 60 seconds from now" or similar, but that is not with all UPSes, and you have no good guarantee that it would really be 60s or whatever you request

and if you command this as part of ordinary shutdown (before the forced kill) - that in this particular uptime really everything will safely stop within the hopeful delay you used

and if there is a need for power-race avoidance (power coming back before the UPS is restarted, so the subpar model one has does not restart and you want to reboot after the big delay) - you are out of luck with SMF...

All of these sorts of things feel pretty risky/unreliable anyway, to be honest?

The potential for things not sequencing correctly and starting themselves up seems pretty high haha

Given you can cheaply buy small computers these days it seems probably better to just have a separate tiny control computer that manages the bigger computer(s) and the UPS

You would leave the control machine turned on, and either it'll lose power when the UPS does and come back on later, or it'll be able to tell that power has come back and restart the main systems

that is also an option, yes

but Solaris lost the ability to be such a machine, sadly

as for sequencing - AFAIK it did work with all sorts of NUT client systems

BTW the power-race avoidance generally concerns also the clients (numerous systems fed by an UPS that is directly managed by one)

if the wall power returns and the UPS refuses to power-cycle the load or reboot itself (and there are/were models like this out there), without a "long sleep" you end up with a rack of halted machines unless you do out-of-band tricks with IPMI, ePDU, etc.

or at best if the managing machine can "long sleep" and then tell the UPS to reboot (and if it does) before/instead of rebooting itself - then you can be in for so,e luck

back to sequencing: as a recap, NUT secondary clients (only fed by the UPS) stop first in an emergency, and the primary client (who has connections to manage it) goes down last and does things to try and get it to power-cycle

as for things starting themselves up - that's where the "long" part in the final sleep comes into play

normally the battery would die (and computer go down) before that sleep expires; ideally the battery would not even die but the UPS honours the request to turn off

the sekf-restart kicks in if the server is still alive awter way too long

and saves you a trip to server room or data center to press reset

i started in a uni campus network, cobbled from users' pool of money

this was tested a lot with the powers that be (or not to be) in those old buildings

that you may not even exit/enter during a night curfew

and you ran the cheapest corners-cut things you could get hands on, so many fancy UPS features at a premium that cost like 3 more UPSes or half a what you could call server wre out of the question

I think ePDUs as a product appeared years later, at least on that market

were a lifesaver - but much later

I spent six years at a Uni haha. I agree it can be tough without a budget! If I couldn't produce another machine for control purposes, I would just make the primary machine ride it out until either power off or it's time to turn secondaries back on

so these setups with NUT were well-tested :)

and eventually i became a maintainer

Systems already have to deal with being interrupted arbitrarily anyway

5

If you want to do a graceful shutdown of, say, a database or whatever, you can just do a transient SMF shutdown on the database service and leave it disabled until the power comes back on or the machine is interrupted

You don't actually have to shut down the host

(I understand that it was relatively easy to do that in the /etc/rc.d era, but I think it's actually easier just to deal with specific services in the SMF era)

depends on the outage

In what way?

with a long one you want to not-drain the battery, because a good ups would actually sit charging until a level where it is safe to turn on the load and guarantee a shutdown time if it blacks out again just then

that's for the case when the UPS would go down when told

If it's a "good" UPS then presumably you can just instruct it to power the host back on when things are OK, and trust it, right

and might not have a delay timer for that (so you historically want it after `remount -ro`)

I agree it seems best if you cna just ... tell it do what you want, rather than sort of try and convince it to maybe do the right thing by proxy

and that part of goodness comes in layers of pricing and other aspects

which you often learn of after you have the box

datasheets and marketing materials are not always truthful or say anything about this at all

The delay timer part seems unnecessary: systems have to be able to deal with arbitrary interruption, you don't actually need to do a complete shutdown, you can just turn off the power etc

If you've been given enough notice, you can turn off a database service if a checkpoint would make it happier on reboot, and then just ... turn off

ZFS will be fine etc

The system could, after all, panic at any time, or someone could kick the power out, or the UPS itself might shit itself and cut the power anyway

yeah, but the risks are deemed smaller and all that

nearing midnight, gotta hop off I'm told

so I agree that if stars align design/hw/sw/...-wise, this conplexity is overkill

there are also cases when it is indispensable

infra project wise (NUT, OS) I think we should cater to both extremes

I have explained earlier , I'd like to have modular firewall configs for my zones, but IPF doesn't supports the include directive, i tought I could make a simple script to build the firewall rulesets for me. I have tried to accomplish this first with m4, but it was terrible experience. Now I have attempted to do it with python, and it seems to be working fine. github.com/extrowerk/firewall_rules

for cheapy PC type systems one belt and braces trick I used was setting a startup time in the bios wakeup settings, at least then if things went really wrong and it didn't start up immediately when power returned it should start up at some point in the following 24 hours (depending on what time was set). Similarly turning on things like WoL so it could potentially get booted from something else that had

returned.

fair point too

the script takes the zone-specific input file github.com/extrowerk/firewall_rules/blob/main/gz.in and the macros, and builds something like this: paste.omnios.org/?5db469ba780c5f70#…DTcjTwQyQtWsLvWQ3YFEW7UYYuyZqfnDo8U

I'm just hoping to save myself a bit of work. I'm getting ansible working for my file servers (OmniOS LTS) and was hoping I could just have it install the appropriate package for upsmon. I guess I get to build (and rebuild as needed) that package myself. It's not the end of the world, I'm just being whiny :)