rwp: like alpine linux already has a selection of nginx modules as nginx-mod-http-fancyindex and nginx-mod-http-brotli and so on

and also from what I'm looking, only the acme and stream modules are available :c

Looks like those are not in the ports tree. Looks like for FreeBSD you will need to build it yourself.

swee: The fancyindex and other modules are definitely available via port options. I'm using them now.

port options?

I'd guess not via packages, though. :(

swee: Yes. You can build custom packages with FreeBSD ports.

yeah no i just want to use pkg

swee: I'm guessing because it's a 3rd party module, it'll need some tinkering. Not sure how that would be incorporated into the package outside of a FLAVOR.

Ah. They pull it in via Tuple.

Yeah. Bummer. That would be a ton of work to build all variants of Nginx with those 3rd party modules.

swee: You could use Poudriere to build those, though. And install the packages from there.

swee: I do have a Poudriere package of Nginx with fancyindex if you want to try to use it. pkg.purplehat.org/packages/main-HEAD/All/nginx-1.28.2_11%2C3.pkg

Doesn't have brotli or zstd, though.

Hello, if this is the wrong place, feel free to point me in the right direction, however, I'm curious about the current support for Snapdrgon X1 in FreeBSD? Is it usable? On which hardware if so?

nimaje: It's not really a bug. The -U option tells it to sort all variables, disregarding the rules.

ah, ok, without knowing you used that it seems strange and I hope that option comes with a waring that it will produce garbage for text variables like COMMENT

-U Always sort variables.

ok, the openvpn docs for --mktun are a bit confusing, it is only for platforms, that don't support creating persistent tun devices nativly (so only linux?), but still I can't convince openvpn to let my scripts handle the interface while getting the server to push me ip and route information. And creating the tun interface beforehand is worse as openvpn now exits when it can't configure the

interface that was moved to a jail, instead of just printing a warning :( (yes, I already set ifconfig-noexec and route-noexec, it still tries to do stuff with the interface)

I realized there is no noto-sans-cuneiform, should I just make the port and go the usual route or are there port groups that are basically reserved only for one maintainer, because all the noto-sans-* are maintained by a single person?

you could CC the maintainer of the other noto ports and offer them maintainership when you submit the port

there are also some other noto sans fonts that are missing, at least NotoSansGujarati, NotoSansGurmukhi, NotoSansMalayalam and NotoSansOriya

ill take a look later

so should I then leave MAINTAINER empty or put myself there for now?

ek: (Response to ZFS send stuff) Yes I did a new manual snapshot and tried sending that.

From what I understand, the issue is that I need to send the current snapshot and any other parent snapshots (?) it depends on.

I wanted to send a filesystem (or dataset, I don't know which one js the correct term) like ".../jails/14.3" that contained all my current jails (".../jails/14.3/$name") so I made a new "recursive" snapshot and tried. Then it failed on send, but I don't have the error at hand. I've been making liberal use of snapshots and clones in there.

I don't think it has happened to me before because I've done a similar thing before when migrating those jails from HDD to SSD, so it took me by surprise this time.

dango, Without knowing exactly what commands you used or what the errors were it is not possible to know what went wrong. If you share those details though then likely someone can help you.

rwp: Ah yeah no worries, I'm not looking for help, just kinda responding to previous comments that ZFS snapshots were painless; which I also thought until this week, because it's the first time that I've had issues with them and zfs-send.

It's likely self-inflicted in some way.

zelf-inflicted

from the little you shared it could be that you tried to use incremental send without ensuring that the recieving side had the base-snapshot

Was it possible you created the dataset manually on the destination and then tried to send to it? That's the most natural thing to try to do but sets up the same failure. I tripped over that myself until I realized that wasn't the way.

nimaje: I don't have the exact commands at hand, but it was something like a `zfs snapshot -r 'originalpool/jails/14.3@TIMESTAMP'` followed by `zfs send -R 'originalpool/jails/14.3@TIMESTAMP' | zfs receive -v -e 'destpool/jails'` (expecting it to create `destpool/jails/14.3`).

No `-i` flag, which might have been the issue (or not).

IIRC the send command complained about it missing a snapshot or something, so I tried to run `zfs promote originalpool/jails/14.3/$JAILNAME` for every jail in there, which then complained about a naming conflict in the snapshot, which I tried to resolve by doing `zfs rename $CONFLICTING $OTHERNAME`, but got the error again with a previous snapshot's name, and I gave up.

Sounds like you became sucked into the machinery. It's okay to promote a snapshot but not while trying to fix a send-recv problem.

Some errors from trying to promote snapshots from the `originalpool/jails/14.3/$SOMETHING@$SNAPSHOT` were mentioning `originalpool/jails/14.2/$SOMETHING@$SNAPSHOT` (14.3 vs 14.2, I don't remember the error, only that there was this difference), and it was at that point that I didn't bother anymore.

So it's probably because I abused snapshots and clones across 14.2->14.3 upgrades of jails, rather than creating them anew.

Are you trying to replicate dataset snapshots into a different pool? Or trying to copy data from one dataset into another dataset in the same pool?

s/Are/Were/. Different pools.

My probably flawed understanding is that it required snapshots from a different dataset (originalpool/jails/14.2, rather than originalpool/jails/14.3) to also be sent at the same time because they were a parent snapshot that was depended upon by the current datasets, but I (stubbornly) didn't want to transfer anything from 14.2.

I think -R originalpool/jails/14.3@TIMESTAMP does not need anything from originalpool/jails/14.2 but it will need all of the incremental data that has not been transferred for 14.3 and that is almost certainly going to want the -I option.

On the destination zfs list -t snap and determine the most recent of the previously transferred snapshots. Then use that as the base for the next incremental zfs send transfer.

Something like: zfs send -R -I @TIMESTAMP1 originalpool/jails/14.3@TIMESTAMP2

The first time you transfer originalpool/jails/14.3 it has never been transferred before and not yet created on the destination and so it will be a full transfer. But the next time you transfer it then it should be an incremental based upon the previous most recent snapshot specified with -I.

[[ I always use zfs recv -s too so that if the transfer is interrupted then I can get the receive_resume_token and use it to resume the transfer. ]]

Nice info to write down on my notebook of important commands.

I'll abuse the channel just a little and say a few more examples to clarify things in the hope that it is useful. Here is an example from my notes on the first copy of a new dataset from one system to another system.

time zfs send zroot/var/data@2024-10-25 | ssh nas3 zfs recv -s zroot/var/data

That runs to completion and sends the data. (There are more variations possible. Out of disk space and such.)

Then I want to update. I take a new snapshot of the source dataset. Then I use that as the destination snap for the dst dataset.

zfs snapshot zroot/var/data@2024-10-27

time zfs send -I @2024-10-25 zroot/var/data@2024-10-27 | ssh nas3 zfs recv -s zroot/var/data

I think I got that example right. That's the simplest method using ssh to do the transfer between two systems. At some point you will want to play around with other methods. But start there first because even if not as fast as possible it is fast enough.

After you have a good understanding of how that works and are comfortable with it then building on that to get the size of the transfer with -nvP and then using that size to give a progress bar of the transfer is nice feedback.

Then adding in zstd compression and mbuffer to avoid encryption overhead as an advanced maneuver.

I have a crontab job to restart unbound (with _oomprotect=YES). If the job just does "service unbound restart", it complains that "protect: option requires an argument -- p". If, however, I run service with -d or -v ("service -v unbound restart), everything works fine. /o\

vkarlsen, On which specific version of FreeBSD? Is this the local_unbound in base? Or the unbound in ports/pkgs?

I use local_unbound. I can stop it no warnings. If I start it there are multiple warnings. But none of them your reported -p error.

I suggest using "sh -x /etc/rc.d/local_unbound restart" to trace through the script.