[00:07:57] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #smartos
[00:11:15] *** andy_js <email@example.com> has quit IRC (Quit: andy_js)
[00:43:44] *** blackwood821 <blackwood821!~blackwood@2601:484:8002:2fa0:8d79:cfb9:6a3b:5141> has quit IRC ()
[02:58:02] *** axonpoet <axonpoet!~axonpoet@fsf/member/axonpoet> has quit IRC (Quit: leaving)
[03:09:38] *** axonpoet <axonpoet!~axonpoet@fsf/member/axonpoet> has joined #smartos
[03:15:49] *** hotbox <hotbox!~hotbox@2001:41d0:fe8f:b70a:20d:b9ff:fe47:7c05> has joined #smartos
[03:34:26] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[03:34:26] *** nde <nde!uid414739@gateway/web/irccloud.com/x-ctfzyukdpufuciro> has quit IRC (Quit: Connection closed for inactivity)
[05:21:38] *** blackwood821 <blackwood821!~blackwood@2601:484:8002:2fa0:512e:d0de:1502:6d5d> has joined #smartos
[07:07:41] *** morgib <morgib!uid342182@gateway/web/irccloud.com/x-ancvtrwunqfjclcz> has joined #smartos
[07:08:50] <sjorge> danmcd build without any patches went OK, applying yours and rebuilding now
[07:25:08] *** blackwood821 <blackwood821!~blackwood@2601:484:8002:2fa0:512e:d0de:1502:6d5d> has quit IRC (Ping timeout: 248 seconds)
[08:00:11] *** glasspelican <glasspelican!~quassel@2607:5300:201:3100::325> has quit IRC (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
[08:01:14] *** glasspelican <glasspelican!~quassel@2607:5300:201:3100::325> has joined #smartos
[08:22:49] *** neuroserve <firstname.lastname@example.org> has joined #smartos
[08:29:58] *** wiedi <email@example.com> has quit IRC (Quit: ^C)
[08:52:47] *** kayront- <kayront-!~kayront@unaffiliated/kayront> has joined #smartos
[08:54:24] <kayront-> "Static gateways must be IPv4 addresses" --> how to set the ipv6 default gw for a zone?
[08:54:50] <kayront-> it doesn't seem to work in "gateways": [ "ipv6-addr-of-router" ]
[08:54:56] *** kayront- is now known as kayront
[08:55:24] <jperkin> we don't really support ipv6 very well, unfortunately
[08:58:10] <jperkin> though if you are sending RAs I think it should just work
[08:58:40] <kayront> I am not, yet. setting v6 up from scratch now
[08:59:13] <kayront> is there some technical reason why the v6 gateway cannot be set in the aptly-called gateways ? or is it the case that no one has gotten around to implement it yet
[09:00:24] <jperkin> just not implemented yet in the node code, SmartOS itself is of course fully IPv6 capable but it's all the tooling around that isn't
[09:01:14] <jperkin> though I find despite having the best ipv6-capable ISP in the UK I still turn it off completely on my network because when it doesn't work it's a nightmare to debug
[09:01:36] <kayront> hmm
[09:01:49] <kayront> and here I am executing the plan to go ipv6-native
[09:01:52] <kayront> maybe not the brightest idea then
[09:02:46] <kayront> i found some old posts from 2015 mentioning that for RAs to work, ip spoofing had to be enabled for the vm receiving them. do you know if that is that still the case today?
[09:02:57] <jperkin> last time it was due to ipv6 bugs in the linux kernel that my dsl model was running which meant packets were just being dropped
[09:02:58] <kayront> if that is still*
[09:03:24] <jperkin> I don't remember having to enable that, but it was a while ago
[09:04:44] <kayront> ok
[09:05:31] <kayront> i'm going to need a virtualized router+firewall too, never really did it before in smartos (i find pf a lot better than ipf) .. does it work well in general as a router?
[09:06:02] <jperkin> it was ok, but I'm much happier with my separate openbsd firewall now
[09:06:04] <kayront> no complaints with freebsd performance as a router, even better would be openbsd (more recent pf) but for whatever reasons the overhead is much bigger there
[09:06:29] <jperkin> things like the bandwidth limiting didn't work at all on SmartOS, and I need that to ensure my kids don't hog my line ;)
[09:06:35] <kayront> hehe
[09:06:44] <kayront> so your obsd is not virtualized?
[09:07:01] <jperkin> no, I bought one of those edgerouter lite things, lovely little devices for ~£100
[09:08:05] <kayront> i see -- i ask because i was running some tests on virtualized obsd on smartos some months back, and it was... trickly
[09:08:09] <kayront> tricky*
[09:08:39] <kayront> iirc if bhyve then it crashed/hung on boot, with kvm the cpu usage was higher than i'd expected for an idle vm
[09:08:58] <kayront> also something about importing a custom image from some friendly guy around here for reasons I don't quite remember anymore
[09:09:15] <kayront> 27e9ddda-7c9c-11e9-bf93-9fcb2c19286b openbsd-6.5 20190522 bsd zvol 2019-05-22
[09:09:17] <kayront> indeed, indeed
[09:11:08] <jperkin> my SmartOS server is still an N36L which isn't really the most suitable thing for running VMs, though sysinfo does say it's bhyve capable
[09:11:35] <jperkin> yeh
[09:11:41] <kayront> nice
[09:12:29] *** basvdlei <basvdlei!~basvdlei@2001:980:a4c3:1:b88b:1590:d6bf:fbee> has quit IRC (Quit: basvdlei)
[09:12:34] <kayront> ok, while i recover from the shock of not being able to set a default ipv6 gw (:p), something i was thinking about very vaguely about the other day -- what would be the minimum way to get a smartos zone to run on a freebsd/bhyve system?
[09:12:38] <kayront> is such a thing even feasible?
[09:13:05] <kayront> perhaps running smartos virtualized under bhyve, and then leveraging some apis to request zone creations from the fbsd host
[09:13:17] *** wiedi <firstname.lastname@example.org> has joined #smartos
[09:13:35] <kayront> i was thinking it would be cool for more people with linux/bsd servers to be able to try out smartos in an easier way
[09:14:09] <jperkin> well it should just run virtualised? the difficulty will always be networking
[09:14:34] <kayront> yes, i was trying to wrap my head around that .. would the anti ip spoofing still work in theory?
[09:14:48] <kayront> and how about drivers for good networking performance when running virtualized?
[09:16:12] <jperkin> pass, I don't know if the drivers LeftWing was working on for azure/gcp help with virtio bits
[09:19:17] <kayront> hmm, hmm
[09:19:34] <kayront> btw, do you know what happened to project-fifo?
[09:24:21] <jperkin> no idea, heinz used to hang out here but not any more I guess, maybe he went on to do something else
[09:24:51] *** bens1 <email@example.com> has joined #smartos
[09:34:45] *** DigiDaz <DigiDaz!sid115572@gateway/web/irccloud.com/x-ezymwjrqkbjowpwy> has quit IRC (Ping timeout: 248 seconds)
[09:34:56] *** DigiDaz <DigiDaz!sid115572@gateway/web/irccloud.com/x-oiteioafbesavdvx> has joined #smartos
[09:35:16] *** morgib <morgib!uid342182@gateway/web/irccloud.com/x-ancvtrwunqfjclcz> has quit IRC (Ping timeout: 248 seconds)
[09:35:16] *** yo61 <yo61!sid15293@gateway/web/irccloud.com/x-jihecqhgbdhfhlax> has quit IRC (Ping timeout: 248 seconds)
[09:35:17] *** scoobybejesus <scoobybejesus!sid271506@gateway/web/irccloud.com/x-lqmqlqzanwzjngpt> has quit IRC (Ping timeout: 248 seconds)
[09:37:33] *** yo61 <yo61!sid15293@gateway/web/irccloud.com/x-qbtqafnigvpvzoax> has joined #smartos
[09:37:38] *** scoobybejesus <scoobybejesus!sid271506@gateway/web/irccloud.com/x-edhvdfyhqytihgah> has joined #smartos
[09:38:36] *** morgib <morgib!uid342182@gateway/web/irccloud.com/x-ydklzcflmwqamloe> has joined #smartos
[09:57:10] *** morgib <morgib!uid342182@gateway/web/irccloud.com/x-ydklzcflmwqamloe> has quit IRC (Quit: Connection closed for inactivity)
[10:06:00] *** hhdave <firstname.lastname@example.org> has joined #smartos
[10:08:43] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Ping timeout: 240 seconds)
[10:10:07] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #smartos
[10:13:41] <sjorge> danmcd with your patch applied (only your patch) build is broken again for me
[10:14:20] <sjorge> I think 'gmake clean' might be broken?
[10:14:28] *** andy_js <email@example.com> has joined #smartos
[10:14:39] <sjorge> As after the OK build, I applied the aptch to projects/illumos and ran 'gmake clean; gmake world'
[10:14:50] <sjorge> And the world complains about the proto strap archive
[10:21:17] <sjorge> Looks like it is not picking up the
[10:25:16] <sjorge> Even without your patch a 2nd builds fails if I run 'gmake clean world live' after the first OK
[10:27:58] *** nikolam <nikolam!~Nikolam@unaffiliated/nikolam> has joined #smartos
[10:28:03] *** nikolam <nikolam!~Nikolam@unaffiliated/nikolam> has quit IRC (Remote host closed the connection)
[10:28:56] <sjorge> Something in the build isn ow pretty broken
[10:29:16] <sjorge> Doing a full clean start (removed smartos-live) butwith your aptch and it is at nightly
[10:29:23] <sjorge> So 'gmake clean' seems broken atm
[10:34:42] <kayront> jperkin: remind me, with the pkgbuild image, to start a new chroot session was it not: "run-sandbox trunk-x86_64" ?
[10:36:36] <sjorge> kayront AFAIK, yeah as I do run-sandbox 2018Q4-x86_64
[10:36:45] <sjorge> but you need to run that via sudo -i or as root IIRC
[10:36:55] <sjorge> And you can only have one sandbox active at a time
[10:38:21] <kayront> yes
[10:38:37] <kayront> it's saying it cannot create it because it already exists, safe to nuke the directory ?
[10:38:51] <kayront> i was working ont his some months ago, forgot quite a few things about the setup it seems
[10:43:07] <jperkin> yes it's safe to rmsandbox <chrootdir>
[10:51:10] *** man_u <firstname.lastname@example.org> has joined #smartos
[11:02:58] *** cann0nballrun <email@example.com> has joined #smartos
[11:04:30] <cann0nballrun> jperkin, how can I choose the php version when I build a module? (for example php72-geoip-1.1.1 instead of php73-geoip-1.1.1)
[11:48:49] <jperkin> cann0nballrun: PHP_VERSION_DEFAULT=72
[11:50:02] <cann0nballrun> I've already tried PHP_VERSION_DEFAULT=72 bmake ...but it compile php73-geoip ...
[11:50:16] <jperkin> did you already have php73 installed?
[11:53:15] <cann0nballrun> I'm in the pkgsrc sandbox
[11:53:46] <jperkin> ah ok, so you're probably being bitten by us already setting the default to 73
[11:54:53] <cann0nballrun> how can I change it?
[11:55:50] <cann0nballrun> I need to compile some modules for php73 and php72
[11:56:32] <jperkin> if you remove any php73 packages and retry with PHP_VERSION_REQD=72 it should forcibly pull in 72
[12:00:45] <cann0nballrun> jperkin, PHP_VERSION_REQD instead of PHP_VERSION_DEFAULT?
[12:01:12] <jperkin> yeh, I should have suggested that in the first place, I forgot that we already set _DEFAULT
[12:02:13] <jperkin> (if you look in /data/pkgbuild/include/pkgoptions/trunk.mk you'll see it being set which will take precedence over any environment variables you've set)
[12:02:56] *** xmerlin_ <firstname.lastname@example.org> has joined #smartos
[12:04:02] <xmerlin_> jperkin, ERROR: Package accepts PHP7.2, but different version is installed ...but I've recreated the sandbox with exit and run-sandbox 2019Q4-x86_64
[12:09:44] <jperkin> perhaps a dependency is pulling in a different version from somewhere, try installing php72 first
[12:17:35] <jperkin> if we ever get to the stage where you can install multiple php versions simultaneously then that issue would disappear
[12:18:07] <jperkin> (if anyone wanted a medium-size but not very difficult project...)
[13:05:28] <sjorge> danmcd got it build, but had to start from scratch again, gmake clean seems to nuke the proto-strap make target and it does not get recreated
[13:07:02] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has quit IRC (Quit: 410 Gone)
[13:16:35] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has joined #smartos
[13:32:23] <sjorge> jlevon I think your last 2 Makefile changes broke 'gmake clean; gmake world' on vanilla smartos
[13:32:45] <sjorge> It is unable to restore the strap stuff and alternates between a dir or a broken symmlink
[13:35:10] <jlevon> do you know what happens
[13:35:30] <sjorge> first build starting from a git clone smartos-live works fine, and there is a proto.strap (directory) with a buynch of files
[13:35:38] <sjorge> after gmake clean this dir is empty but it fails on
[13:35:51] <sjorge> /root/smartos-live/tools/build_strap make -a /root/smartos-live/illumos-adjunct.20130131.tgz -d /root/smartos-live/proto.strap -j 128
[13:35:57] <sjorge> which seems to assume that it is a symlink?
[13:36:04] <sjorge> So it fails on the 'rm'
[13:36:26] <sjorge> if I manually remove the dir using rmdir... that step creates a symlink proto.strap but it is stil lborken
[13:36:34] <sjorge> It also has a weird path
[13:36:40] <jlevon> so you're building without a cache?
[13:36:43] <sjorge> lrwxrwxrwx 1 root root 80 Feb 19 12:34 7d3d5fd52c4f9652ad8735869512edc363e630ce -> /opt/SmartOS/build-cache//2018Q4/x86_64/7d3d5fd52c4f9652ad8735869512edc363e630ce
[13:36:53] <jlevon> hmm
[13:36:58] <sjorge> that stuff has another symlink called 7d3d5fd52c4f9652ad8735869512edc363e630ce
[13:37:13] <sjorge> As for how i am building: git clone smartos-live; ./configure; gmake world live (works fine)
[13:37:25] <sjorge> do a change ; gmake clean world live
[13:37:40] <sjorge> After the gmake clean, gmake world fails on the stuff above
[13:38:00] <sjorge> Sorry the ls output was from inside the proto.strap dir
[13:38:17] <sjorge> but the proto.strap is at the point also a symlink to /opt/SmartOS/build-cache//2018Q4/x86_64/7d3d5fd52c4f9652ad8735869512edc363e630ce
[13:38:43] <jlevon> yeah so it tried to create a symlink when one already existed
[13:39:31] <sjorge> after the first gmake clean; proto.strap is a directory though
[13:39:50] <sjorge> and then it exit 2's on rm /root/smartos-live/proto.strap
[13:40:02] <sjorge> So I thought I'd help it by cleaning it up,. then the symlink madness starts
[13:40:37] <jlevon> so gmake clean for a start should leave the -stamp files in place
[13:40:45] <jlevon> so a world won't even try to rebuild the strap?
[13:40:47] <sjorge> it does not
[13:40:57] <jlevon> oh wait crap
[13:41:08] <sjorge> I was under the impression only 'clobber' should remove htem, but... clean does too
[13:42:44] <sjorge> This is the last line output by gmake clean => rm -f 0-*-stamp 1-*-stamp
[13:43:05] <sjorge> Also after a gmake clean... '
[13:43:12] <sjorge> proto.strap is a directory again
[13:43:47] <jlevon> do you have a matching strap cache in /opt
[13:47:25] <jlevon> so the error 2 is easy to fix up
[13:47:32] <jlevon> I suspect the rest of it comes from that failure
[13:49:13] <sjorge> I just ran gmake clean again so now I have the empty dir
[13:49:20] <sjorge> and gmake world does nothing wit it (can't do the rm(
[13:49:30] <sjorge> Do yo want me to rmdir the dir and run gmake world?
[13:50:05] <jlevon> I don't understand how you're getting an empty dir
[13:50:07] <jlevon> exactly
[13:50:36] <jlevon> again, do you have a suitable build-cache in /opt?
[13:50:54] <sjorge> I have this ? /opt/SmartOS/build-cache/2018Q4/x86_64/7d3d5fd52c4f9652ad8735869512edc363e630ce/
[13:51:07] <sjorge> he empty dir seems to be create by 'gmake clean'
[13:51:18] <sjorge> If I rmdir proto.strap and run gmake clean, the dir is back
[13:52:06] <jlevon> hmm
[13:52:57] <jlevon> good spot. interesting.
[13:53:50] <sjorge> So rmdir, gmake clean, dir is back :)
[13:53:55] <sjorge> Ofcourse then gmake world fails
[13:54:43] <sjorge> aha! rmdir proto.strap; gmake world
[13:55:07] <sjorge> Now seems to eb doign stuff! I also removed /opt/SmartOS/build-cache/2018Q4/x86_64/7d3d5fd52c4f9652ad8735869512edc363e630c/7d3d5fd52c4f9652ad8735869512edc363e630ce (the self looping symlink)
[13:56:28] <jlevon> afaict that mkdir of proto.strap was always broken
[13:57:22] <sjorge> I think... the combo of doing a rmdir between the gmake clean and gmake world... with removal of the symlink in /opt/... seems to have fixed it
[13:57:25] <sjorge> Well until I run clean again
[13:58:29] <jlevon> there were two minor problems really
[14:00:11] *** tru_tru <email@example.com> has joined #smartos
[14:06:44] <sjorge> Something easy to fix?
[14:06:58] <jlevon> think so
[14:08:23] <kayront> also, is it normal that the gnupg20 package is *not* installed in the chroot?
[14:11:09] <sjorge> will curl|patch -p1 it
[14:11:17] <sjorge> And do a gmake clean world
[14:14:03] <cann0nballrun> jperkin, is parallel build supported (pkgsrc sandbox)?
[14:16:00] <sjorge> jlevon seems to be spinning on "/usr/bin/bash -c cd $CODEMGR_WS/usr/src && dmake clobber" now
[14:16:17] <jlevon> spinning?
[14:16:19] <sjorge> So clean == clobber now?
[14:16:32] <sjorge> it's been s tuck on that for ~1min with all processes in sleep state
[14:16:51] <jlevon> clean always did that
[14:17:00] <jlevon> do you have a .make.state.lock in projects/illumos
[14:18:34] <sjorge> I was just about to look, but it finished the clean
[14:18:38] <sjorge> doing gmake world now ...
[14:18:55] <sjorge> looks good, it's doing nightly now
[14:18:58] <sjorge> WIll comment on the PR
[14:19:35] <jlevon> ta
[14:19:59] <sjorge> thanks for the quick fix
[14:21:39] <jlevon> pleasure
[14:23:53] <jperkin> kayront: the agent runs outside of the sandbox, which then mounts /root/.gnupg inside
[14:23:59] <sjorge> back to trying to get a PI with both bhyve-sync and the fix from dan
[14:24:41] <kayront> jperkin: ok. and about gpg2 not being installed in the chroot, even though it is in the zone?
[14:24:41] <jperkin> cann0nballrun: depends what you mean by parallel, building with make -j is very simple, just set MAKE_JOBS to the number of jobs you want - building multiple packages in parallel is more involved, you need to set up pbulk as per https://github.com/joyent/pkgsrc/wiki/pkgdev:bulk
[14:25:08] <jperkin> kayront: the mksandbox script should install the correct gnupg package into /opt/tools
[14:27:02] <kayront> jperkin: where exactly would it be? I can't seem to locate it
[14:28:45] <jperkin> /opt/tools/bin/gpg2
[14:29:25] <kayront> not there indeed
[14:29:35] <kayront> any idea what could be causing it not to be copied?
[14:30:02] <jperkin> it's installed not copied, try removing the >/dev/null from /data/pkgbuild/scripts/mksandbox and re-creating
[14:30:22] <jperkin> sjorge ran into an issue where for some reason the package downloads were failing
[14:30:26] <jperkin> maybe something similar?
[14:30:37] <kayront> i thought about it, but pkgin works from the zone
[14:30:43] <kayront> let's see if removing the devnull brings some new clues
[14:31:23] <jperkin> you can also run pkg_info manually against the downloaded packages in /data/packages to verify they're ok (will be in the tools/ directory for whatever version sandbox you are creating)
[14:32:41] <kayront> ===========================================================================
[14:32:41] <kayront> pkg_add: Short read from package
[14:32:41] <kayront> pkg_add: Failed to read from archive for gnupg20-2.0.30: truncated gzip input
[14:32:46] <jperkin> no doubt the error handling in the script could be improved
[14:32:52] <jperkin> there we go
[14:33:00] <sjorge> jperkin the cached downloaded package was incomplete
[14:33:09] <sjorge> I had to rm it and it would download a fresh one
[14:33:21] <sjorge> i think the pkgbuild 2018Q4 (atleast) image might ship wit it?
[14:33:46] <jperkin> I don't think so, normally only the bootstraps are shipped
[14:35:00] <jperkin> wonder if node-fs-caching-server is not removing incomplete files in error
[14:35:05] <kayront> i'm a bit confused
[14:35:05] <jperkin> *on
[14:35:30] <kayront> which file would that be? (above) I removed it from /var/db/pkgin/cache and still the same
[14:35:50] <jperkin> which sandbox are you trying to create?
[14:35:57] <kayront> trunk-x86_64
[14:36:11] <jperkin> ok, so it'll be under /data/packages/SmartOS/trunk/tools/All
[14:36:31] <sjorge> kayront that the wrong one, its one under /data/packages/SmartOS something deeper
[14:36:34] <sjorge> Ah... the one jperkin said :D
[14:36:51] <sjorge> Just removing gnupg20 from there should be OK
[14:37:04] <kayront> right
[14:37:21] <kayront> so i just rm -rf /data/chroot/dev-trunk-x86_64
[14:37:25] <kayront> and major snafu
[14:37:25] <jperkin> here's briefly how it works: pkgbuild ships with the pkg_* tools and a caching proxy for /data/packages, when you create your first sandbox the pkg_add commands download packages from pkgsrc.joyent.com through the proxy, save the files to /data/packages, and create the sandbox. then the next time you run mksandbox, it uses the cached downloads
[14:37:38] <kayront> gazillions of ..
[14:37:48] <kayront> rm: cannot remove 'chroot/dev-trunk-x86_64/proc/71520/argv': Operation not applicable
[14:37:48] <kayront> rm: cannot remove 'chroot/dev-trunk-x86_64/proc/72393/as': Operation not applicable
[14:37:48] <kayront> rm: cannot remove 'chroot/dev-trunk-x86_64/proc/72393/ctl': Operation not applicable
[14:37:48] <kayront> rm: cannot remove 'chroot/dev-trunk-x86_64/proc/72393/status': Operation not applicable
[14:37:48] <kayront> rm: cannot remove 'chroot/dev-trunk-x86_64/proc/72393/lstatus': Operation not applicable
[14:37:48] <kayront> rm: cannot remove 'chroot/dev-trunk-x86_64/proc/72393/psinfo': Operation not applicable
[14:37:49] <kayront> and now only chroot in /data
[14:37:52] <kayront> damn
[14:38:03] <jperkin> if we shipped the packages in the image it would get ridiculously bloated (we'd need to do it for every potential package set you might want to build)
[14:38:15] <kayront> on the bright side, the gnupg20 package was successfully deleted (lol)
[14:38:24] <jperkin> if we didn't have the caching proxy then mksandbox would take ages to run each time as the packages are re-downloaded
[14:39:02] <jperkin> yeh that won't work, you use rmsandbox to remove sandboxes, that does all the unmount operations in the correct order and uses rmdir to ensure directories are only removed when empty
[14:39:18] <jperkin> I'd start from a fresh pkgbuild, you've deleted a bunch of stuff that's required
[14:39:22] <jperkin> like the bootstraps
[14:40:16] <kayront> i can recover the mk.conf etc from ansible
[14:40:41] <kayront> other than that i think only the signing key in /root/.gnupg
[14:40:44] <kayront> would need backup
[14:41:32] <jperkin> I wasn't going to post it until I completed a few more, but I have a video tutorial that goes through the sandbox process: https://youtu.be/WhS5XEg2QAY
[14:41:57] <jperkin> not getting time to work on the rest recently so I may as well get some feedback on it
[14:42:38] <kayront> is there an easy way to regen the missing bits w/o having to redo the zone jperkin ?
[14:42:44] <kayront> noted re tutorial, will watch later
[14:43:24] <kayront> lol damn it, even the pkgsrc checkout is gone
[14:43:25] <kayront> good job :D
[14:43:35] * kayront sighs
[14:44:01] <cann0nballrun> jperkin, is there a way to regenerate .pkginfo files after an offline signing of packages?
[14:44:11] <jperkin> yeh you've lost a lot, you could possible recover it but it's probably not worth it, and there's always a danger that you'll miss something that will affect builds
[14:44:46] <jperkin> cann0nballrun: as long as you're using our release branches they should be generated with 'bmake package'
[14:45:13] <jperkin> they aren't part of the main pkgsrc tree so if you're developing against netbsd/trunk or something then they won't
[14:45:15] <kayront> it's just crossed my mind that auto-snapshotting the zone datasets from the host would probably be a good idea for situations like this
[14:45:26] <kayront> with a limit of snapshots by zone/vm etc
[14:45:29] <cann0nballrun> jperkin, I've many unsigned packages already build
[14:45:31] <kayront> did anyone write such a thing yet?
[14:46:49] <jperkin> cann0nballrun: you can generate them manually with 'pkg_info -X <package.tgz> > package.pkginfo'
[14:47:04] <cann0nballrun> jperkin, perfect thank you
[14:51:00] <kayront> jperkin: completely unrelated, are the centos/debian lx-dataset images still maintained ?
[14:51:25] <jperkin> I have no idea, but would assume not
[14:52:24] <sjorge> IIRC newer centos/debian have issues with systemd
[14:52:29] <sjorge> but it's been a while
[14:52:49] <kayront> yes, i tested some months ago and like 14 services were failing with centos
[14:52:49] <sjorge> Although OmniOS has ubuntu 19.x workign... so I think in theory SmartOS should aleast be able to get an image for that too
[14:54:00] <kayront> i see there are newer base-64 images for zones, is it possible to stop the zone, vmadm update and change the image_uuid, restart the zone and be back up with a newer base?
[14:54:29] <jperkin> almost certainly not
[14:55:12] <kayront> so what sort of stuff am I missing on by not updating there? security updates in the userland (not pkgsrc stuff) '
[14:55:59] <jperkin> images are all pkgsrc, userland comes from the GZ mounted read-only to /usr
[15:03:37] <kayront> what's the easiest way to see what the image is made of? explore the fs in /zones/$image_uuid ?
[15:04:22] <jperkin> yeh just find across it
[15:04:49] <jperkin> the root/ directory
[15:05:43] <kayront> cool
[15:10:51] *** blackwood821 <blackwood821!~blackwood@2601:484:8002:2fa0:d407:426b:4e99:c58e> has joined #smartos
[15:49:34] *** nde <nde!uid414739@gateway/web/irccloud.com/x-tkixvnweygpowdif> has joined #smartos
[15:49:51] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #smartos
[15:55:00] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Ping timeout: 248 seconds)
[16:04:36] *** tru_tru <firstname.lastname@example.org> has quit IRC (Ping timeout: 265 seconds)
[16:06:44] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #smartos
[17:22:43] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Ping timeout: 240 seconds)
[17:25:57] *** neuroserve <email@example.com> has quit IRC (Ping timeout: 260 seconds)
[17:26:01] <sjorge> kayront to nuance jperkin's reply a bit... you cannot vmadm update the image_uuid, you can however use vmadm reprovision... BUT ...
[17:26:23] <sjorge> That will a vmadm create of a zone with the new image_uuid with the same network/quota/...
[17:26:52] <sjorge> I have all my data on a lofs mount and I bootstrap salt to configure everything, so in my case... I usually can... but in general no it will delete all the stuff
[17:33:03] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #smartos
[17:40:00] *** tozhu <firstname.lastname@example.org> has joined #smartos
[17:45:28] *** wonko <email@example.com> has quit IRC (Remote host closed the connection)
[17:50:44] *** bens1 <firstname.lastname@example.org> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[17:57:56] <wilbury> i provision a new zone, migrate apps and mounts, shutdown the old zone, switch the old IP to new zone
[18:10:45] *** tozhu <email@example.com> has quit IRC (Ping timeout: 240 seconds)
[18:28:38] *** man_u <firstname.lastname@example.org> has quit IRC (Ping timeout: 245 seconds)
[18:31:22] *** wiedi <email@example.com> has quit IRC (Ping timeout: 268 seconds)
[18:36:00] *** hhdave <firstname.lastname@example.org> has quit IRC (Quit: hhdave)
[18:42:29] *** noahmehl <email@example.com> has joined #smartos
[18:59:17] *** tozhu <firstname.lastname@example.org> has joined #smartos
[19:07:42] <kayront> on the other hand, if the only difference between newer zone images is pkgsrc stuff, then keeping the zone current via pkgin should be easier?
[19:07:53] <kayront> also - has anyone tried to get timescaledb to work/compile on smartos?
[19:16:33] <kayront> No results found for opensmtpd --> it's in pkgsrc but not compiling on illumos, i tried to fix it a few months ago and got it to compile with little C knowledge in about 1 hour, but unfortunately it was segfaulting on startup. just dropping it here in case someone more skilled has interest in taking a look
[19:26:56] *** ledoktre <ledoktre!ledoktre@gateway/vpn/nordvpn/ledoktre> has joined #smartos
[19:27:06] <ledoktre> greetings all.
[19:28:55] *** JtH <JtH!~5CE0A708@unaffiliated/cmdlnkid> has joined #smartos
[19:47:57] *** simmel <email@example.com> has quit IRC (*.net *.split)
[19:48:11] *** simmel <firstname.lastname@example.org> has joined #smartos
[19:48:49] *** trisk <trisk!~trisk@2601:196:4700:3a:8:20ff:fe3e:890e> has quit IRC (Ping timeout: 272 seconds)
[19:51:15] *** trisk <trisk!~trisk@2601:196:4700:3a:8:20ff:fe3e:890e> has joined #smartos
[19:56:46] *** neuroserve <email@example.com> has joined #smartos
[20:02:07] *** trisk <trisk!~trisk@2601:196:4700:3a:8:20ff:fe3e:890e> has quit IRC (Ping timeout: 272 seconds)
[20:06:26] *** plluksie <firstname.lastname@example.org> has quit IRC (Ping timeout: 240 seconds)
[20:12:07] *** ledoktre <ledoktre!ledoktre@gateway/vpn/nordvpn/ledoktre> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[20:12:42] *** trisk <email@example.com> has joined #smartos
[20:17:08] *** wiedi <firstname.lastname@example.org> has joined #smartos
[20:29:21] *** hhdave <email@example.com> has joined #smartos
[20:30:29] <kayront> tcpdump -w /tmp/wtf.pcap
[20:30:30] <kayront> dropped privs to _tcpdump
[20:30:30] <kayront> tcpdump: /tmp/wtf.pcap: No such file or directory
[20:30:31] <kayront> ...?
[20:51:00] <dsockwell> what OS is that on? doesn't SmartOS have `snoop` for packets?
[20:51:15] *** jinni <firstname.lastname@example.org> has joined #smartos
[20:53:25] *** trisk <email@example.com> has quit IRC (Ping timeout: 240 seconds)
[20:53:42] <dsockwell> if it's an LX zone, tcpdump is one of the things I'd expect to have compatibility problems with, since it interacts with the kernel expecting it to be a real Linux kernel, but I'd have to research the specifics to really say so
[20:55:38] <Smithx10> find /native | grep snoop
[20:55:51] <dsockwell> find /native -name 'snoop'
[20:55:53] *** trisk <trisk!~trisk@2601:196:4700:3a:8:20ff:fe3e:890e> has joined #smartos
[20:55:57] <Smithx10> dsockwell: you fancy.
[20:56:28] <dsockwell> knee-jerk correction, was unnecessary
[20:56:54] <dsockwell> kayront: does that help you
[20:57:45] *** ledoktre <ledoktre!ledoktre@gateway/vpn/nordvpn/ledoktre> has joined #smartos
[20:58:09] <Smithx10> kayront: for things like tcpdump, traceroute, route, ping etc I usually use /native (which houses the native smartos bins)
[20:58:49] <Smithx10> if you need to you can .... use find / native -dsockwellisthecoolest '$bin'
[20:58:50] <Smithx10> :P
[21:14:48] <kayront> dsockwell: it's tcpdump from pkgsrc
[21:14:54] <kayront> it used to work
[21:15:30] <dsockwell> does the manpage help?
[21:15:42] <kayront> actually, nevermind, i'm not 100% sure i've used -w on smartos before
[21:15:47] <dsockwell> is _tcpdump a real user?
[21:15:52] <kayront> yes
[21:15:54] <dsockwell> did you try a different path?
[21:15:57] <kayront> yes
[21:16:06] <dsockwell> what OS is it really?
[21:16:13] <kayront> Smithx10: i know about snoop, but i prefer tcpdump
[21:16:19] <kayront> dsockwell: a smartos zone
[21:16:23] <dsockwell> im guessing real SmartOS because you used pkgin
[21:17:01] <Smithx10> Ohhhh, I’d imagine that should work
[21:17:12] <kayront> yeah
[21:17:20] <kayront> unexpected snafu
[21:17:21] <Smithx10> Sorry kayront, my apologies
[21:17:32] <Smithx10> Thought this was LX
[21:17:32] <kayront> no need for apologies Smithx10 :)
[21:17:46] <Smithx10> I’d just blame dsockwell
[21:18:09] <kayront> i'm curious about lx, are they still a thing? the debian & centos lx images don't seem to have been updated for ages, and at least for the centos image last I checked, it boots with many failed services
[21:18:14] <Smithx10> :P
[21:18:56] <kayront> i'm going with bhyve because of selinux for a use case where sadly it really has to be linux anyway, but curious because so much work was put into making lx a reality some years ago
[21:19:26] <Smithx10> arekinath: has a Image out there
[21:19:43] <Smithx10> I’ve got the void Linux image that Bahamas cleaned up
[21:19:48] <Smithx10> You could try those
[21:20:07] <Smithx10> Systemd for the most part is the only big gotcha
[21:21:19] <ledoktre> Hey guys. I am pretty new to smartos(illumos). I am trying to work on a bhyve zone that I had added some additional storage (zvol) but can't see to see how to detach the storage without destroying it. Example - extra storage for virtual hosting , where I can detach the storage, reprovision the base OS, and reattach the storage
[21:21:36] <ledoktre> Anyone here know how you might detach (and preserve) additional storage?
[21:22:00] <Smithx10> ledoktre zfs send
[21:22:42] <jbk> you could try adding a hold on the dataset or just snapshot + clone it to somewhere else..
[21:23:31] <ledoktre> yeah I tried twice (not your idea) once with destroying the vm, once with detaching. In both cases the zvol was toast.
[21:23:51] <ledoktre> I was trying to find a way to preserve it without having to send it to another dataset first.
[21:24:17] <ledoktre> I am familiar with kvm (debian) and it wasnt too hard to detach a qcow2 file and attach it to another vm.
[21:24:19] <jbk> I think reprovision was at least originally intended for native zones (mostly for updating triton services)
[21:24:22] <ledoktre> just trying to find the quivilent
[21:25:02] <jbk> so i don't know what'll actually happen for an HVM instance instead of a native one...
[21:25:18] <kayront> Smithx10: is there any website with all those unofficial images floating around?
[21:25:20] <kayront> hard to keep up
[21:25:35] <Smithx10> i think that void one you can just build
[21:25:43] *** bahamat <firstname.lastname@example.org> has quit IRC (Quit: ZNC - http://znc.in)
[21:25:57] <Smithx10> the one that arekinath made Im not sure of
[21:26:15] *** bahamat <email@example.com> has joined #smartos
[21:26:42] <ledoktre> jbk: hmm. I am not adverse to using native zones. I would probably prefer it. But for whatever reason the ones available seem to be kind of old. For example the debian is v9.
[21:26:58] <jbk> native, not lx
[21:27:32] <jbk> though i would imagine lx would probably be fine w/ reprovision too...
[21:28:03] <kayront> ledoktre: imo a smartos zone should be your default choice while running under smartos, it integrates a little bit nicer with all the rest, but the downside is that there is a lot less documentation for illumos/smartos specific stuff
[21:28:14] <kayront> and missing packages in pkgsrc sometimes (vs bsd or linux)
[21:31:10] <jbk> what _might_ work, though I haven't tried it, and it might take a bit of manual work...
[21:31:20] <kayront> ledoktre: actually, the example you gave: perfect example: if it was a zone, you could just update its quota
[21:31:23] <jbk> is if you delegate a dataset
[21:31:48] <jbk> then create zvols as children of that (zones/<uuid>/data).. and then add them w/ the no create option to the vm
[21:32:22] <jbk> I _think_ that should allow a reprovision to preserve it (since it just preserves the '/data' dataset + children)
[21:32:28] <jbk> however
[21:32:53] <jbk> since it's more about non-HVM zones, it may also do horrible things to such instances :)
[21:33:06] <jbk> (i.e. take appropriate precautions when testing)
[21:41:49] <ledoktre> kayront: jbk: Another use case scenario I was playing with but havent gotten too far on is to use smartos as a nas. originally i was trying to use the kernel smb server interface but Ive had a lot of issues with permissions (presumably because its running in a non-global zone). So where I had gone after that was perhaps throw up a ubuntu instance and attach a zvol with samba
[21:42:11] <ledoktre> But if you detach the zvol to update the os to the latest image available, you cant have it deleting your data either! :)
[21:43:12] <ledoktre> i am fine (with this last example) running samba in a smartos zone, but I couldnt find a recent copy of samaba and im trying to avoid building a whole bunch of packages every time i update too
[21:43:46] <sjorge> we being me if you guys would think it would get merged
[21:43:48] <ledoktre> ultimately Id like to figure out how to make the kernel based one work for my needs but thats a discsuion for another day I suppose
[21:44:07] <sjorge> then you can delegate data/vmname and create zvols on there, because zones/UUID/data still gets destroy when you destroy the zone
[21:48:03] <ledoktre> jbk: so it sounds like when you create a zvol in smart os, then you attach it to a bhyve image, you can;t detach it without destroying it? It seems sort of curious - if you could create it outside of any vm why you cant detach it again. I could understand if the vm created the zvol but in my case no, i created it, then attached it.
[21:48:30] <ledoktre> specifically because i was trying to emulate the delegated datasets
[21:48:47] <ledoktre> detach reattach to another vm
[21:52:12] <sjorge> ledoktre it can only work when the zvol is not under zones/UUIDofVM
[21:52:34] <ledoktre> it was under zones/persist/
[21:52:43] <ledoktre> i did not create it under zones.UUID
[21:53:03] <sjorge> ledoktre as long as zones/persist is added as a dataset to the bhyve zone, it should not touch it
[21:53:09] <sjorge> Assuming your PI is from 2020
[21:53:28] <sjorge> I fixed the super agressive destroy all the datasets bits in Q4 last year
[21:58:49] <bahamat> ledoktre: The reason you can't detach it is because once it's under the control of the zone, the untrusted zone owner can do whatever they want to it, which may not be safe if the dataset is taken outside of a zoned context.
[21:59:22] <ledoktre> sjorge: zones/persist was added on smartos itself, then I created (from smartos) the zvol under zones/persist. the release is current within the past 30-60 days
[21:59:51] <bahamat> Incidentally, you *can* do that with zonecfg/zfs if you are sure that it's safe and you really want to.
[22:00:25] <ledoktre> bahamat: I have read (and followed) the doc you linked to. The problem I ran into was dealing with permissions. It seems to be related to NFSv4 permissions and not being in the global zone (I think). I had a ton of issues when trying to configure multiple users and multiple groups.
[22:00:36] <ledoktre> brb (phone call)
[22:01:58] <bahamat> It works in a zone for me, so I'd need to see whatever error message you're getting.
[22:03:19] <neuroserve> Smithx10 : trying to boot an lx-zone with void-linux - but provisioning errors out at cnapi.wait_task (vmadm create) with ERROR: Unsupported distribution!
[22:03:57] <Smithx10> neuroserve: did you build from the branch
[22:04:42] <neuroserve> I tried to follow the instructions from github
[22:05:41] <Smithx10> Look at the code, one of the branches / forks has alpine
[22:05:44] <Smithx10> And one has void
[22:06:14] <Smithx10> Not sure if Bahamas pushed a patch into the platform to handle void instead of pigging backing of void
[22:06:25] <Smithx10> Backing off *alpine
[22:10:46] <ledoktre> bahamat: Im still on the phone, but I just wanted to say, in both cases, I did not get an error. I was able to in the first case destroy the bhyve image, which destroyed the zvol. not terribly surprised, i recreated the test, detach the zvol from the bhyve image, and it did that but also removed it from the system entirely again.
[22:10:54] <neuroserve> ok ./guesttools/install.sh contains install.alpine ...
[22:11:51] <bahamat> ledoktre: I was talking about smb.
[22:15:00] <neuroserve> hm - I see a master and a pre_lx_boot_void branch
[22:19:32] <ledoktre> aahh. how I was trying to do it was to connect to the share as the owner of the folder that was shared. this worked fine. I could read and write files. when I tried to edit the settings on the security tab in windows (such as to add groups and users with read or read/write permissions, I could not save.
[22:20:22] <ledoktre> I think maybe here on IRC some time ago someone helped me with a script I could run to set the files to do some ACL stuff on the files and folders, and it sort of worked for me, but it was rough
[22:22:35] <ledoktre> the bigger picture is not the smb thing today but rather the ability to detach zvols and attach them to other vms
[23:16:26] <sjorge> papertigers nice, the PR is open for the sync stuff!
[23:16:55] <sjorge> also, did you have a chance to peak at the extra dtrace stuff?
[23:17:00] <papertigers> yeah and then I need to go from sept 2019 -> present day :P haha
[23:17:10] <papertigers> sjorge: I haven't but I can now
[23:21:21] *** andy_js <firstname.lastname@example.org> has quit IRC (Quit: andy_js)
[23:49:57] <ryzokuken> hey
[23:50:11] <ryzokuken> the `find` binary on SmartOS is acting up.
[23:52:41] <ryzokuken> `find . -path "*"` won't return anything