00:18:32 <jbk> specifically, for go binaries, it'd be nice if stripped (due to size) that enough symbols remain to enable things like pstack (I want to extend pstack to understand go threads) and such
01:47:26 <jbk> though speaking of pstack, does it use the agent lwp to grab the info?
06:00:32 <jclulow> jbk: I should't think so
06:01:20 <jclulow> You do have to stop a thread in order to be able to look at the register state and get a stack, but I don't believe the agent is necessary for that
07:02:06 <gitomat> [illumos-gate] 15841 Some man pages contain incorrect bin paths -- Peter Tribble <peter.tribble⊙gc>
10:15:11 <gitomat> [illumos-gate] 15835 Update AMD microcode to 20230808 -- Andy Fiddaman <illumos⊙fn>
13:59:11 <sjorge> pmooney just an observation after all the tsc changes to bhyve/gate https://gist.github.com/sjorge/9252c376e49ac4ae191a2abf16116f58
13:59:24 <sjorge> On the upside, it seems my VMs are no longer eventually falling back to hpet
14:00:21 <sjorge> Doesn't seem to negatively effect the guest
14:04:19 <pmooney> sjorge: that indicates slowness of reading whatever clocksource its using for the watchdog
14:04:28 <pmooney> (I believe)
14:24:40 <sjorge> guests are all still on tsc (what they pick at booth), before they would eventually switch to hpet
14:25:10 <sjorge> date output still look good though
18:32:17 <KungFuJesus> so it seems as though something in the pam stack is preventing a 15 character password from authenticating for users over ldap
18:32:25 <KungFuJesus> is this a known limitation?
18:33:46 <KungFuJesus> it worked with an 11 character password, but I didn't test it enough to find the absolute limit
18:34:17 <otis> i very vaguely remember 14-character limit on username, but not on password
18:35:02 <rmustacc> Sounds like a bug we need to track down, but I similarly have a vague feeling of having had long ldap passwords in the past. But I'll admit it's been some time.
18:35:55 <otis> that 14-char limit on username was on LOCAL usernames, not on ldap ones.
18:36:02 <otis> IIRC
18:36:30 <otis> KungFuJesus: which encryption scheme do you have in place?
18:38:19 <KungFuJesus> let me find my manual ldapclient command
18:38:27 <KungFuJesus> https://www.illumos.org/issues/15842 <-- created an issue
18:38:29 <fenix> → BUG 15842: pam stack fails to authenticate with ldap if password is 15 characters in length (New)
18:40:15 <jbk> what service mechanisms are you using?
18:40:44 <otis> isn't the password cached somewhere?
18:40:51 <otis> in inapropriate format or what
18:40:59 <otis> nevertheless, off now.
18:41:02 <KungFuJesus> "authenticationMethod=simple,credentialLevel=proxy"
18:41:44 <KungFuJesus> as far as nssswitch...one sec
18:41:54 <jbk> hrm.. that should just find the DN of the user, then do an ldap bind using the supplied password
18:42:21 <KungFuJesus> https://pastebin.com/u2XJdyJE
18:42:28 <jbk> unless libpam is truncating it, I don't think the backend ldap stuff should be
18:42:45 <otis> isn't the password cached somewhere?
18:42:49 <KungFuJesus> jbk: that seems plausible
18:43:03 <jbk> (i.e. very strange)
18:44:03 <KungFuJesus> otis: I don't think there's a cache.  The name service cache was wiped, which did clear some of the things that ldapclient had cached.  I'm not sure that the actual password hash is one of them, though
18:44:18 <jbk> passwords aren't cached..
18:44:25 <KungFuJesus> yeah, didn't think they were
18:44:43 <KungFuJesus> that might be handy, bugs getting that correct aside (for offline access)
18:45:14 <jbk> yeah, there's been talk (at least in the context of the smb server) for caching passwords
18:45:21 <KungFuJesus> ldapclient is querying the shadow entry for that user fine and they had been able to get in via a kerberos ticket, too
18:47:00 <KungFuJesus> jbk: not sure if this helps or not, but here's our full ldap mapping: https://pastebin.com/uaGHyXx9
18:48:03 <jbk> if you're storing userPassword, that's basically storing an old unix hash and using that
18:48:07 <jbk> instead of binding as the user
18:48:17 <jbk> (which lets you use whatever the ldap server wants)
18:48:44 <KungFuJesus> ahhh, so do I remove that mapping?  What should it be?
18:49:42 <jbk> now i'm trying to remember.. it's one of the profile options that says 'just do an ldap bind'
18:50:03 <jbk> i used to remember all of this, but that was like 10 years ago :)
18:50:55 <otis> for that i saved ldap_client_file and ldap_client_cred so i did not have to do ldapclient init on all clients
18:57:41 <KungFuJesus> so it would seem that pam_unix_* is imposing this limitation?  I suspect whatever command through ldapclient to do what jbk is suggesting would configure the pam stack to use pam_ldap?
18:58:25 <jbk> yes, that'd probably be better..
18:59:01 <jbk> i've not tried it, but my recollection (which it's been long enough) that really the only cross-platform value of the password in a shadow file is the traditional unix hash form
18:59:37 <jbk> and really, doing an ldap bind is nicer, since it should get you all the same account management as you would from say AD
18:59:46 <jbk> in terms of 'must change password, expiration, etc'
19:00:09 <KungFuJesus> is there something intrinsic to the unix hash that limits the character length?
19:00:58 <KungFuJesus> I seem to remember a very long time ago when I did unix administration in college that Solaris 8 had these weird arbitrary limits (I think it was like 8 characters)
19:01:21 <jbk> that's not really arbitrary as much as that is what the traditional unix hash algorithm supported
19:01:41 <jbk> i think it was solaris 8 (maybe 10, but i swear it was sooner) added alternate, more secure methods
19:01:47 <jbk> that weren't subject to the limitation
19:02:22 <KungFuJesus> anyway to make pam_unix use those hashes and not break the LDAP integration?
19:07:21 <sjorge> i think i had issue with that in the past too
19:07:36 <jbk> i don't think so
19:11:52 <KungFuJesus> so it sounds like I need enableShadowUpdate somehow.  Any guides on how to do this properly?  It sounds like there needs to be an admin user with creds stored locally for that to work?
19:12:19 <KungFuJesus> if I didn't care about enabling the direct integration with passwd, could I still get the longer password limits with just a proxy user like I am now?
19:12:26 <jbk> yes, you'll need to use a proxy account that has permissions to modify that attribute for any user
19:12:51 <jbk> well it's the difference between using LDAP as a dumb data store for basically the exact contents of /etc/passwd and /etc/shadow
19:13:09 <jbk> and using LDAP to hold the passwd data and using it more as an authentication service (using pam_ldap)
19:14:06 <jbk> if that makes any sense
19:14:17 <KungFuJesus> gotcha, so the ldap/client service is doing some weird surrogate temporary stand-ins for the normal unix files that nsswitch is querying so that pam_unix continues to function
19:15:16 <KungFuJesus> and they seem to be imcompatible with each other, does that mean I can't make pam_ldap fall through to pam_unix for local accounts?
19:16:02 <jbk> the ldap/client service basically periodically pings the LDAP servers listed in the profile to see which one(s) are up or not for use with nss_ldap and pam_ldap
19:16:20 <KungFuJesus> I'm a bit leery of touching the pam stack at all, too many cases of locking myself out and leaving the keys in the car
19:16:42 <jbk> it also can synchronize the local ldap profile from an entry in LDAP
19:17:16 <jbk> KungFuJesus: in such cases, I usually leave an additional root window or two open so i can undo anything
19:17:38 <jbk> if using openindiana or omnios, you could also backup the be before making changes
19:18:00 <KungFuJesus> yeah, though this thing is a pretty heavily used file server in production
19:18:05 <jbk> or create a new be, temporairly activate it, make changes... then only if they're ok, activate it
19:18:22 <jbk> (that way a reboot automatically reverts it)
19:18:39 <jbk> yeah.. i wouldn't suggest making such changes outside of a maintenance window if it's in use
19:20:33 <KungFuJesus> https://docs.oracle.com/cd/E53394_01/html/E54912/clientsetup-89.html#SVLDPgpqor <-- is this more or less the instructions?  What else would I need to do from the ldapclient command side of things?
19:23:05 <jbk> that looks right from what I recall, but i'd try to test it somewhere
19:23:11 <jbk> just to be safe
19:24:28 <KungFuJesus> hmm, might make sense to setup a zone or VM or something to do this
19:25:45 <KungFuJesus> if I don't care about the shadowupdate stuff and I'm ok with it being readonly, will just not enabling that but still doing the "init" process with a plain proxy user result in something that can use pam_ldap?
19:26:31 <KungFuJesus> and can I still have those manual attribute mappings appended to the command (sans the password one, of course)
19:27:16 <jbk> yeah.. the proxy account is just used to lookup those attributes
19:27:58 <jbk> then when a user authenticates, it looks up the DN using the proxy account, then creates a new connection and binds as the user's DN and the supplied password
22:51:54 <gitomat> [illumos-gate] 15464 viona should copy tx buffers by default -- Jorge Schrauwen <sjorge⊙bb>
23:22:57 <sjorge> yay! I can finally remove my hacky workaround now. Well upgrade once bloody pulls it in I guess as my current be already runs this code.