00:28:38 <zi> thresh: ive implemented a fix for the branch you're tracking (re pkg) and it should show up within an hour or so for you
00:28:53 <zi> thresh: there were a couple of others that were impacted that are already fixed/live
01:17:57 <wavefunction> "known issue" being the gigantic data file size?
01:18:18 <wavefunction> (Not trying to snark, just validating my understanding)
01:48:15 <kevans> wavefunction: yes
04:45:16 <gbon121> zi: would you mind to show a link to the relevant commits?
05:05:20 <kevans> gbon121: his resolution would have been outside repos in cluster/builder config, iirc
08:51:35 <crest_> does anyone else have problems fetching packages from the FreeBSD package mirrors right now?
08:51:57 <crest_> i get "Error 503 Response object too large" trying to upgrade thunderbird
08:52:15 <crest_> for this URL: https://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/latest/All/Hashed/thunderbird-153.0_1~2$zmpyrrq1.pkg
09:02:14 <ForeverNoob[m]> Hi, I have a frew question about HAST.
09:02:22 <ForeverNoob[m]> 1). I'm not sure if I should se the `memsync` and `async` algo. The secondary machine will be in a different geographical location, so ping time of <50ms would be some good times.
09:02:24 <ForeverNoob[m]> Does `memsync` validate first local write when first block is set to arrive to the secondary or when all blocks actually have arrived over the wire and are set to be written to the secondary?
09:02:34 <ForeverNoob[m]> 2). Did I understand correctly that HAST auto-configures a secondary machine to be primary in case of sustained timeout of the primary machine? If so, is there a way to turn this behavior off?
09:05:20 <ForeverNoob[m]> *if I should use the `memsync` _or_ `async` algo.
09:10:49 <crest_> memsync means the remote machine acks the write the moment it has received it
09:11:06 <crest_> async means the local machine doesn't even wait for the remote machine to see the write
09:11:34 <crest_> with 50ms latency waiting a roundtrip means disk sync write performance has to suck
09:12:05 <crest_> because what takes <0.1ms on a local nvme drive now take at least 500 times longer
09:12:37 <crest_> with memsync the remote system still has to see the write and send back a success message
09:13:01 <crest_> unless you're in a really nice datacenter network that will take longer than a write to a local ssd
09:14:32 <crest_> iirc hast has no builtin automatic failover. you need something else e.g. consul, etcd, etc. to trigger the failover
09:14:57 <crest_> remember two nodes can't form a consensus
09:15:20 <crest_> you need at least 3 systems so that the remaining two can form a quorum
09:15:35 <crest_> (or for five for better redundancy)
09:24:46 <ForeverNoob[m]> Ah ok. Yeah so I could live with the fact if memsync just acks a write at the moment the 1st block gets sent over the network, but otherwise in my case it would most likely be best to choose async and some mechanism to alert me of prolonged dirty extents on the primary.
09:24:53 <ForeverNoob[m]> There will just be 2 machines, and it's going to be pretty obvious if either of them is down, so I'll just prefer to set primary / secondary role myself.
09:45:15 <crest_> async runs the realistic chance of corrupting the hast "disk" if something goes wrong
09:45:29 <crest_> if you write on your current master device and fail over
09:45:42 <crest_> and the disk was being written to
09:45:49 <crest_> you will see writes being lost
09:45:55 <crest_> file systems don't like that
09:46:27 <crest_> and applications don't like it either if you "undo" writes
09:46:44 <crest_> e.g. upload a file, failover, fsck the filesystem/force import the zfs pool
09:46:58 <crest_> and the file you wrote is lost forever
09:47:11 <crest_> is that an acceptable behaviour for your usecase?
09:47:35 <crest_> also why do you want async aka best effort replication at the block level instead of at the file level?
10:29:47 <daftaupe> Morning, trying to run /usr/share/examples/bhyve/vmrun.sh -v -c 1 -m 1G -E -d /dev/zvol/build/vms/9front -i -I 9front-11554.amd64.iso  9front I get Assertion failed: (error == 0), function modify_bar_registration, file /usr/src/usr.sbin/bhyve/pci_emul.c, line 708.
10:29:48 <daftaupe> I've read that error did appear when some folks try to do some passthrough, but it's not my case, any pointer would help me, I tried to follow https://wiki.freebsd.org/bhyve/9front and have the same issue
11:09:57 <crest_> does ist work if you follow the steps exactly without vmrun.sh?
11:10:18 <crest_> and which freebsd version are you running on your host?
11:48:30 <ForeverNoob[m]> crest_: Yeah async has some definite downsides, although it's still probably a better than "send daily zfs snapshots" which I had in mind before learning about HAST.
11:49:05 <crest_> i would recommend just doing more frequent zfs snapshot + send
11:49:35 <crest_> there is nothing wrong with a snapshot every 5 minutes that gets destroyed as soon as it's received
11:50:11 <crest_> just don't keep too many because deleting them is annoying and they clutter the cli output
11:50:30 <crest_> funnily the cheapest thing about a zfs snapshot is creating them
11:55:10 <ForeverNoob[m]> > just don't keep too many because deleting them is annoying and they clutter the cli output
11:55:53 <ForeverNoob[m]> That was one of my concerns as well, but this sounds like something that some scripting might solve. I'll definitely reconsider ZFS snapshots.
12:54:02 <daftaupe> crest_ nope, doesn't run with the exact steps in my case, I'm running 15.1
12:55:32 <polarian> pkg: https://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/latest/All/Hashed/qbittorrent-5.2.3~2$ci5shz6g.pkg: Service Unavailable
12:55:36 <polarian> something weird going on here lol
12:57:14 <polarian> pkg: https://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/latest/All/Hashed/go125-1.25.12~2$w83fwpg1.pkg: Service Unavailable
12:57:16 <polarian> ditto go
12:57:23 <polarian> whats with the $ strings in them
12:57:34 <polarian> oh because they are hashed...
12:58:23 <polarian> Error 503 Response object too large
13:03:20 <polarian> yeah all large ports are unable to download, someones fucked the webserver config
13:04:15 <crest_> polarian: https://mastodon.social/@_bapt_/116962204010624175
13:04:46 <crest_> the problem is known the the right people and in the process of begin fixed
13:05:04 <crest_> the scripts are running and there is nothing you can do speed it up
13:05:21 <polarian> crest_: nice!
13:05:37 <polarian> thx for the info
13:06:13 <polarian> crest_: out of curiosity can you explain what is repo?
13:06:23 <polarian> I assume its a tool
13:08:14 <crest_> repo = short repository
13:08:39 <crest_> a repo is a collection of packages and meta about those packages
13:09:15 <crest_> the format of the metadata was extended to allow asking the repo which package would install a specific file
13:09:50 <crest_> you can already run `pkg which $file` to find out which package (if any) has installed it on your system
13:10:28 <crest_> but a new `pkg rwhich` (short for remote which) command would be able to answer which of the packages inside the repo would install the file
13:10:36 <crest_> without having to install all packages first
13:10:49 <crest_> the problem is that this feature caused the metadata size to explode
13:11:19 <crest_> explode to such a degree that the content delivery network that hosts the packages refuses to deliver the bloated files
13:12:43 <polarian> yeah that makes sense :)
13:24:31 <polarian> crest_: what does bapt's comment on repo -l mean?
13:24:38 <polarian> (sorry to ping again)
13:25:18 <crest_> polarian: https://github.com/freebsd/pkg/releases/tag/2.8.0 (search for -l)
13:25:19 <polarian> oh wait nevermind
13:25:21 <polarian> https://man.freebsd.org/cgi/man.cgi?query=pkg-repo&sektion=8
13:25:40 <polarian> I was trying to find "repo" but I didnt realise it had a "pkg-" prefix to it
13:27:48 <polarian> also this isn't the first time that pkg has broken in the last few years due to an update
13:27:59 <polarian> I remember a while back some SQL error
13:29:50 <polarian> thanks again for the great explanation!!!
13:31:45 <polarian> will move my follow up question to #pkg :)
16:00:50 <polarian> https://wiki.freebsd.org/clusteradm can someone explain to me why the example layout is designed like this :3
16:00:52 <polarian> im interested
16:49:07 <ForeverNoob[m]> All I can say is that I'm stealing that Moss gif.
17:12:48 <rtprio> hi friends
17:26:16 <rtprio> anyone have some ideas what to check: sometimes the laptop wakes from s3 okay, but if it sleeps too long, it goes into a cold boot
17:26:24 <rtprio> is that a bios setting?
17:39:45 <CrtxReavr> o_O
17:40:04 <CrtxReavr> In my day S3 was a video chipset. . . kind of a pain in the ass video chipset.
17:40:25 <rtprio> i remember s3
17:41:23 <CrtxReavr> It foolishly parked its fat ass on 0x2f8 I/O address space, same as com2 defaulted to.
17:42:06 <CrtxReavr> Spent *A LOT* of time when I wokred at MS supporting Win95 working around that on people's systems.
17:43:34 <CrtxReavr> The only worse piece of hardware was this sound card that wanted !!*THREE*!! IRQs.
18:06:06 <thresh> thanks zi, it seems to work fine now
18:10:22 <zi> thresh: welcome, sorry about that
18:17:56 <thresh> no worries, mistakes happen
18:18:25 <thresh> its kinda cool that you guys run the infra on the latest and greatest
18:22:53 <mosaid> Oh, those weird DDOSes on hosting companies and other stuff happened for me were made by KimWolf DDoS botnet
18:23:23 <mosaid> owner arrested on end of may https://www.justice.gov/usao-ak/pr/canadian-man-arrested-international-authorities-charged-administrating-kimwolf-ddos
18:51:03 <bsdrobert> that's a bit sad. the time should match the crime and i dont think thats gonna happen. probably looking at decades if not life.
19:03:09 <ek> bsdrobert: Says he's only facing one count and up to 10 years?
19:03:45 <ek> Probably a slap on the wrist in the end.
19:36:26 <mason> Better fodder for #freebsd-social
20:22:51 <hodapp> meanwhile: https://www.bbc.com/news/articles/c62qw1qk95eo
21:38:10 <polarian> ForeverNoob[m]: haha, yeah the Moss gif is amaqzing
22:03:18 <mewt> ok, I guess I'll ask here even though it's probably me not knowing a thing...
22:04:06 <mewt> I'm trying to get an IPv6 IP via SLAAC on a box. restarting rtsold shows router solicitation and advertisement on a link-local addr. There is one thing on the link-local broadcast that isn't me. Prefix len is 64, default gateway should be ::1
22:04:29 <mewt> After neighbor discovery with the same IP that sent the router advertisement, it stops and nothing more happens
22:05:17 <mewt> starting dhcp6c gives me three rounds of neighbor solicitation for my hostname/subdomain/... on the link local broadcast, I think?
22:05:24 <mewt> (this is looking with tcpdump)
22:05:32 <mewt> What have I done wrong here?
22:06:32 <mewt> for the nic, nd6 options=8023<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,DEFAULTIF>. I have a link-local addr but only that
22:08:05 <mewt> starting rtsold with flags -imF [network interface here]. ipv6_activate_all_interfaces="YES", rtsold_enable="YES"
22:08:41 <mewt> ifconfig_myinteface_ipv6="inet6 accept rtadv"
22:08:52 <mewt> What else do I need to do?
22:10:45 <mewt> I've also tried ifconfig_myinteface_ipv6="inet6 accept rtadv prefixlen 64", seems that 64 is the default
22:46:39 <CrtxReavr> It is for for v6.
22:47:10 <CrtxReavr> And should be used for any segment/VLAN/prefix with endpoint devices.
23:30:17 <Macer> The commit in question severed our
23:30:17 <Macer> ports tree mirroring to github.com due to their filesize hard limit of 100MB,
23:30:17 <Macer> and introduced a blob of questionable licensing into the repository history.
23:30:57 <Macer> Why did that paste in 3 lines? I wonder what they mean by a blob of questionable licensing.
23:34:12 <kevans> Macer: just a binary that we don't really know we can legally redistribute like this
23:36:10 <dnp1> Thanks kevans, makes sense
23:36:12 <kevans> we don't know and we already need it purged anyways because of the size, but we wanted to make it clear that size isn't the only concern
23:53:31 <mewt> "It is for for v6." What does this mean?
23:53:50 <mewt> I know this is for IPv6, IPv6 is the point of the exercise here
23:54:29 <mewt> Oh, you mean the prefix length
23:59:36 <satanist> > default gateway should be ::1
23:59:55 <mewt> Indeed