hrm...

it seems like incremental building has stopped working with smartos

jperkin: is there a timeframe when trunk will have a backported xz-package?

very soon, packages are uploading now

jperkin: thx will update as soon as possible :-)

I'm working on designing an IPv6 deployment for our subscribers and want to use some Triton instances for backend services. I can create a v6 network in Triton and assign the NIC tag to a server, but am getting an error when I try to use it with an instance: network_uuid: InvalidParameter: The network UUID is valid, but its address family must be IPv4: Invalid parameters

Is there a way to make this work?

maybe "allow_ip_spoofing" would work and just configure the interface on the VM manually...

@jbk what happened?

There are some pushes that force you to start over...

well this always worked previous (but maybe it was by accident?).. i could bldenv illumos.sh; cd dir; dmake -e install; exit out of that, remove proto/buildstamp, and gmake live and it'd just rebuilt the tgz... now it does a full nightly

(after doing a full clean build)

so if you're iterating on something, do don't have to do a full nightly every single time... save that for when you're (hopefully) done

`gmake live` depends on the filled-in-or-not of the 0-*-stamp files.

If it built nightly, it detected a 0-*-stamp was missing or otherwise invalid.

Did you do "gmake update", as that certainly will remove 0-illumos-stamp if it updates projects/illumos

the 0-illumos-stamp exists

+file

no

I've done what you describe and, AFAICT, it worked.

Now lemme try again, now that you have me curious.

I just did steps I'll put a gist for and I had no problems regenerating the tarball with a replacement kernel module.

(Except for the part where the *&(^&^%&^% terminal scrollback got cut off, thanks Terminal.app).

( I added some blank lines to ipsecesp.c and built a replacement ipsecesp.c module).

Did you alter any header files?!

no

since it's not deliberate though (my big question), I can try to dig into it a bit later

$WORK has taken an interest in my tpm driver that i had been working on on my own (since before I started here), so i get to work on it during working hours now... and I just got the CRB interface (there's two different defined HW interfaces) working, but going back to make sure all the tweaks necessary didn't break the other interface w/ the common code (it's easier to test w/ my home machine that has one

installed)

it still only allows one open(2) at a time, which is enough to at least kick the tires on stuff

but my intention was to put it out for review after I had finished the bits to support multiple clients (i.e. more than one process can open(2) it at a time)

Cool!

(unfortunately that involves more work than the driver acting analogous to a mutex.. there's TPM state that you have to swap in/out depending on the situation)

yeah... it'd actually work well as an alternate to yubikeys for the encrypted CN stuff (among other things)

unlike the 1.2 devices, 2.0 have reasonable mandatory required mechanisms and such

(AES, ECC, SHA2, etc)

jdt: I've got some stuff for IPv6

jdt: github.com/bahamat/smartos-ipv6-smf and github.com/TritonDataCenter/triton-…master/plugins/allow_ip_spoofing.js

jdt: First, you use the plugin to allow specific users to have allow_ip_spoofing auto enabled on specific networks. Second, is the ipv6 smf turn up stuff.

jdt: it does this all outside of Triton's control, so there's potential for malicious activity, so be judicious about who is allowed to do this (that's why the cloudapi plugin is restricted to specific users on specific networks).

jdt: Otherwise, I use that for all of my stuff at home.

I would love to bring full IPv6 support to Triton, but it's not a trivial project, and we've got too much going on right now for me to be able to focus on that.

Okay, thanks for the tips bahamat. I did find that allow_ip_spoofing along with disabling cloud-init in my Debian container gets me most of the way there, so I think I have what I need to keep pushing forward. I'll take a look at those links, too.