11:46:26 nomad: last time I tried to use NUT I think I ran it in a pkgsrc zone 14:49:21 Hello. :) 17:58:49 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 17:58:49 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). 17:59:07 What am I doing wrong? 18:00:52 the only one mention of nginx-common package in omnios-extra is in omnios-extra/build/nginx/nginx.p5m file 18:13:36 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. 18:13:53 Or am I misunderstanding what a 'pkgsrc zone' is? 19:24:26 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 21:41:27 @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. 21:42:18 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. 21:44:55 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. 21:45:43 Ideally the lists would be maintained once and included into different spec/deb/p5m/... recipe files. 21:47:01 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 21:49:13 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... 21:49:46 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) 21:50:26 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` 21:50:33 so the systems are not halted forever 21:51:45 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 21:56:54 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 21:58:33 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 21:59:18 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 22:00:54 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... 22:01:51 All of these sorts of things feel pretty risky/unreliable anyway, to be honest? 22:02:20 The potential for things not sequencing correctly and starting themselves up seems pretty high haha 22:07:04 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 22:07:54 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 22:16:29 that is also an option, yes 22:17:02 but Solaris lost the ability to be such a machine, sadly 22:18:05 as for sequencing - AFAIK it did work with all sorts of NUT client systems 22:19:29 BTW the power-race avoidance generally concerns also the clients (numerous systems fed by an UPS that is directly managed by one) 22:21:58 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. 22:22:54 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 22:25:02 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 22:26:47 as for things starting themselves up - that's where the "long" part in the final sleep comes into play 22:28:09 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 22:28:35 the sekf-restart kicks in if the server is still alive awter way too long 22:29:04 and saves you a trip to server room or data center to press reset 22:29:51 i started in a uni campus network, cobbled from users' pool of money 22:30:19 this was tested a lot with the powers that be (or not to be) in those old buildings 22:30:36 that you may not even exit/enter during a night curfew 22:31:54 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 22:32:56 I think ePDUs as a product appeared years later, at least on that market 22:33:12 were a lifesaver - but much later 22:33:24 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 22:33:41 so these setups with NUT were well-tested :) 22:33:51 and eventually i became a maintainer 22:33:52 Systems already have to deal with being interrupted arbitrarily anyway 22:34:22 5 22:34:46 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 22:34:53 You don't actually have to shut down the host 22:35:51 (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) 22:37:34 depends on the outage 22:38:37 In what way? 22:39:07 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 22:39:25 that's for the case when the UPS would go down when told 22:39:57 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 22:40:15 and might not have a delay timer for that (so you historically want it after `remount -ro`) 22:40:30 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 22:40:50 and that part of goodness comes in layers of pricing and other aspects 22:41:14 which you often learn of after you have the box 22:41:50 datasheets and marketing materials are not always truthful or say anything about this at all 22:42:00 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 22:42:30 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 22:42:34 ZFS will be fine etc 22:43:05 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 22:44:35 yeah, but the risks are deemed smaller and all that 22:44:48 nearing midnight, gotta hop off I'm told 22:45:34 so I agree that if stars align design/hw/sw/...-wise, this conplexity is overkill 22:45:48 there are also cases when it is indispensable 22:46:18 infra project wise (NUT, OS) I think we should cater to both extremes 22:46:46 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. https://github.com/extrowerk/firewall_rules 22:46:51 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 22:46:57 returned. 22:47:34 fair point too 22:49:01 the script takes the zone-specific input file https://github.com/extrowerk/firewall_rules/blob/main/gz.in and the macros, and builds something like this: https://paste.omnios.org/?5db469ba780c5f70#8jd9kiy4GDTcjTwQyQtWsLvWQ3YFEW7UYYuyZqfnDo8U 23:13:05 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 :)