wiki.smartos.org/persistent-configuration-for-the-global-zone -- here it says: "/usbkey/ssh/sshd_config is in here so if you want to do things like require MFA or refuse Password login, you change it here and reboot" ... in FreeBSD i use "pam_google_authenticator-1.09,1 PAM module for two-step authentication from Google" to achieve that ... but the module does not seem to be available for smartos (at least the gz) on pkgsrc.

so how does one go about setting up 2FA via TOTP for SSH logins on the GZ?

also, what was the command to reread /usbkey/config ? so that i could re-apply the configuration without a long reboot

also also (lol coffee) what is a modern tool to generate service manifests? back in the day manifold was the thing

also also also, i'm sharing the administration of this gz with 2 other people, it would be nice not to have to share tmux sessions and what not. how much pain am I getting into if I try to create admin accounts and make them persist across reboots?

for 2FA, we ship a duo package, but as yet don't provide a 32-bit version of it for the GZ to work with PAM - you might be able to bodge the regular version though in the meantime

restarting smartdc-config _might_ reread /usbkey/config, but I can't guarantee it, and you get to keep both pieces if it fails (I'd just reboot tbh)

for SMF I just copy/edit one of the many existing ones in pkgsrc, they're generally 99% identical

there are docs on creating users in the gz, but again not recommended, you keep both pieces when it breaks, etc

generally once you have multiple people administrating things you're better off with triton

looks like the google-authenticator package in pkgsrc could do with an update, would also be interesting to know if it actually works!

gonzosysadm[m]: serious question, but why use TOTP and not FIDO keys with split key?

Did anyone notices that from, say, the begining of this year or so, console output in, say man and while searching man is very slow, much slower then before.. (on Smartos global zone, over SSH, but it is the same on VGS console)..

I don't know if mailing-list participant "thomas" is on here, but I apologize for mismerging vioscsi(4D) into SmartOS, and am constructing a deliverable (PI tgz, ISO, or USB) with a fix for it. smartos.org/bugview/OS-8418 fix is TritonDataCenter/illumos-joyent #425

So I did some googling, maybe not enough, but is there a packing list of opensource projects/dependencies with licensing for SmartOS/Triton/etc? Like a packing slip for PI's and API's/agent....blah blah

Sort of...

illumos-joyent and smartos-live are CDDL. Things in illumos-extra have licensing included

when I was at CA we had to distribute a list of opensource software that was in our dom0 hosts in order to repackage our proprietary stuff

illumos-kvm is GPL, and IIRC illumos-kvm-cmd is also gpl? But I'm not 100% sure on that one.

At California?

Yeah, I figured, but most of the binaries in /usr/bin,etc are illumos right?

Like to get gnu binaries you go through pkgsrc?

Computer Associates

Stuff from illumos-extra are also in /usr/bin

I guess the general question should have been phrased like, besides KVM, are there GPL licensed binaries in the GZ?

For Triton it's all MPL-2.0, or some of the node modules we produce are MIT. Each repo has its own license.

Cool so no separately licensed binary dependencies in the node projects?

3rd party node modules are used under the 3rd party license, and the licence declaration should be included in the package.json for every node module.

Ah, you see my limited node knowledge now :)

There's also a few other 3rd party things that are part of Triton. E.g., postgres for manatee, zookeeper (and by proxy Java) for binder

openjdk or sun/oracle?

OpenJDK 8 currently

Good to know, I wouldn't have figured Joyent would repackage oracle java lol

Okay so I should be able in a sense just clone the github repo's and generate a list of whats included in the 'pi' under CDDL.

from illumos that is

Outside of bug fixes, drivers, enhancements,etc, the GZ doesn't get new binaries added regularly in my experience, or is that an incorrect assumption?

No, it doesn't get new binaries added very often

Thanks man always a pleasure chatting

New versions of existing things are much more frequent.

not that you asked, but if anyone happened to want something similar for packages that are installed then "pkg_info -Q LICENSE '*' | sort | uniq"

Thank you jperkin, that is an excellent shortcut

I wonder if I can generate a decent list if it could be commited to illumos-joyent as a packing slip in the PI for others to use if needed

It's something that would need to be generated on every build.

hmmm, so a build tool perhaps might be the better route

or a make target even

Yeah.

Surprised this doesn't exist already, I'll go see if something already exists on github

Compiling a static list is nice, but I wouldn't accept that as a pull request, because then it's perpetually on me to always update it every time.

What would you require to get it in? Like entirely automatic? I'm thinking packing slip with licenses and maybe even a hash column

We do already ship a manifest which enumerates every file included on the platform image.

Aha

entirely automatic

That might be all that I need

Where is it located?

usbkey?

It's /usr/share/smartos/manifest

Wow I had no idea

Hopefully IRC is still archived somewhere on the web in case someone is looking for this in the future.

I think the manifest file itself is the only file not included in the manifest.

hard to manifest yourself

Because calculating its hash so that we can include the hash in the manifest is a tricky problem.

chicken+egg lol

jperkin: I maybe sending you a pkgsrc commit in the next couple of days. May need to DM with you though its for a pkg in the joyent repo

you can just send a PR to pkgsrc-joyent

K

I'll get around to renaming it at some point, need to sort out SUPERSEDES support in pkgin first

Now, if you're going to cross reference that manifest with every file present on a running system, you need to know that some files are auto generated at boot, so wouldn't be in the manifest.

And some things get modified during the normal course of operation, so the hash will differ

(e.g., /etc/zones/index)

I'm not worried about dynamic changes

Mainly just binaries

Like binaries present on the system.

I know that we're using openssh as well which I believe is BSD licensed

So there must be some projects that are not CDDL included in the PI

Well like I said, things that are in illumos-extra have their own license

Also, not *everything* in illumos-joyent is CDDL. Bhyve, for example is BSD.

Also, following up on that CMON issue that I was having yesterday, I ran `cns-hook update_remotevm <uuid> <cmon.X.cns.X.io>` but the cert's are still not updating on remote zones. I just copied them manually for the time being

Excellent

Sorry for all the questions I haven't dug into the source and done a build in ages

Well, it uses sdc-oneachnode to copy the files over, so maybe look at that?

Yeah, I `set -x` before I ran it and saw the oneachnode commands run, but didn't pay enough attnetion to see if there was a failure. I'll give it another shot

I'll dig through the script some more too. Just thought you might know of an issue before I spent too much time on it.

anyways, thanks again, maybe I can return all the help you guys have given me in the future.

I will say that triton-dehydrated expects there to be a working Triton :-)

If that's not the case, there's no guarantee it will work :-)

is libumem the right place to look for querying vmm through syscalls btw? Just wondering for telegraf ram metrics

Oh there is a full triton/manta deployment in the environment

Now where I am hacking/cheating a bit is I want to get cmon working on a vanilla smartOS node

But I mean if your sdc-oneachnode is broken, then there's nothing that triton-dehydrated can do about it.

sdc-oneachnode is working perfectly currently

I don't think cmon on standalone smartos will work.

It has heavy dependencies on sapi.

Damn even with manually written configs?

Or does it look for config-agent/registrar stuff?

And if you're standing up sapi, you'll need moray, manatee, and binder

It uses config-agent

Right so may as well just run triton haha

You might be able to fudge enough to get cmon-agent running on standalone smartos

but that's not the same as cmon itself.

cmon also requires vmapi, cnapi, and ufds

Ah shit I didn't think about that

So you're not far away from full triton at that point.

Is there another metric interface written for smartOS like CMON that could run standalone and be scraped by prometheus?

Triton isn't really a bunch of reusable components.

The reusable parts we publish as node modules

but like any one Triton service, generally has strong dependencies on other Triton services.

So I guess glue the node modules together haha

Sounds like we're getting deep into node at that point.

I have SmartOS nodes sprinkled about the globe that I want to monitor but really dont want to keep replying on Zabbix

Plus I haven't built zabbix on current platform in ages

Guess my telegraf plugins will have to do if there isn't another native interface like cmon

I mean, cmon-agent fundamentally is just a prometheus exporter that happens to be zone-aware.

So hack away at cmon-agent and configure it connect to a prom?

bypassing cmon proxy altogether?

Does it rely in anyway on promtail libraries maybe ported to node?

cmon handles account based authentication, once the request is authenticated, it's just a pure proxy to cmon-agent

Forgot about the UFDS aspect

but cmon-agent is just an open ended api right?

It's an unauthenticated exposition endpoint.

I feel a bit more clear on this

I hesitate to even call it an API, because all you can do is GET

true, but would one need a prometheus zone locally to query cmon-agent directly? I guess cmon doesn't do metric shipping since prom pulls the metrics

This getting hackier by the moment :)

Oh well, guess I'll go back to ansible hell for the time being hehe. Maybe I'll get time to mess with this another day

Did you see my previous question about libumem? Curious if that is the correct system library name for querying ram

I missed your question about libumem, but it's not for querying ram.

It's a debugger for memory allocation.

I know that you can use kstat for that but like which system header would you call on illumos for ram?

You LD_PRELOAD it into your app, and it tracks memory allocation, then when you get a core of the process you can use mdb to better account for memory usage in the dore dump

s/dore/core/

libumem is a bit more than that

ah that makes much more sense

I was doing some reading on it last night, saw that it has been ported to windows and linux, but didn't get super deep

it's a malloc/free replacement that implements similar memory management as the kernel does (slab allocation, magazines) for higher performance allocation

the debugging aspects are additional features

But you wouldn't be able to import a libumem header to query memory usage or statitics from a monitoring plugin perspective right?

maybe a dtrace script would be better for that

yeah, if you're wanting to know about system memory usage, kstats is basically your main option

I was trying to build something with rust not long ago and I remember it lacked malloc calls or something I do not remember the exact detail but while I was trying to hack something together to make it build and get memory but couldn't determine the correct system libraries for that

On illumos that is

Was made for linux like everything else

i thought rust on illumos is already using libumem for it's allocations.. but maybe i'm misremembering

it's been a while since I worked on the illumos target

It probably is now, I know that perkin did a lot for the rust bootstrap on pkgsrc

I was only wondering for future issues that I may hit on project or another. Whether its go or rust or whatever, just wanted to try to figure out how to translate memory syscalls from linux to illumos if needed. Figured if I could just find the right library it wouldn't be much effort. But hell finding the correct library is an effort in and of itself lol

yeh I've always built everything in pkgsrc with libumem, though I believe rust ensures it's always linked against it by default for the illumos target too