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

though speaking of pstack, does it use the agent lwp to grab the info?

jbk: I should't think so

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

[illumos-gate] 15841 Some man pages contain incorrect bin paths -- Peter Tribble <peter.tribble⊙gc>

[illumos-gate] 15835 Update AMD microcode to 20230808 -- Andy Fiddaman <illumos⊙fn>

pmooney just an observation after all the tsc changes to bhyve/gate gist.github.com/sjorge/9252c376e49ac4ae191a2abf16116f58

On the upside, it seems my VMs are no longer eventually falling back to hpet

Doesn't seem to negatively effect the guest

sjorge: that indicates slowness of reading whatever clocksource its using for the watchdog

(I believe)

guests are all still on tsc (what they pick at booth), before they would eventually switch to hpet

date output still look good though

so it seems as though something in the pam stack is preventing a 15 character password from authenticating for users over ldap

is this a known limitation?

it worked with an 11 character password, but I didn't test it enough to find the absolute limit

i very vaguely remember 14-character limit on username, but not on password

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.

that 14-char limit on username was on LOCAL usernames, not on ldap ones.

IIRC

KungFuJesus: which encryption scheme do you have in place?

let me find my manual ldapclient command

illumos.org/issues/15842 <-- created an issue

→ BUG 15842: pam stack fails to authenticate with ldap if password is 15 characters in length (New)

what service mechanisms are you using?

isn't the password cached somewhere?

in inapropriate format or what

nevertheless, off now.

"authenticationMethod=simple,credentialLevel=proxy"

as far as nssswitch...one sec

hrm.. that should just find the DN of the user, then do an ldap bind using the supplied password

unless libpam is truncating it, I don't think the backend ldap stuff should be

isn't the password cached somewhere?

jbk: that seems plausible

(i.e. very strange)

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

passwords aren't cached..

yeah, didn't think they were

that might be handy, bugs getting that correct aside (for offline access)

yeah, there's been talk (at least in the context of the smb server) for caching passwords

ldapclient is querying the shadow entry for that user fine and they had been able to get in via a kerberos ticket, too

jbk: not sure if this helps or not, but here's our full ldap mapping: pastebin.com/uaGHyXx9

if you're storing userPassword, that's basically storing an old unix hash and using that

instead of binding as the user

(which lets you use whatever the ldap server wants)

ahhh, so do I remove that mapping? What should it be?

now i'm trying to remember.. it's one of the profile options that says 'just do an ldap bind'

i used to remember all of this, but that was like 10 years ago :)

for that i saved ldap_client_file and ldap_client_cred so i did not have to do ldapclient init on all clients

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?

yes, that'd probably be better..

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

and really, doing an ldap bind is nicer, since it should get you all the same account management as you would from say AD

in terms of 'must change password, expiration, etc'

is there something intrinsic to the unix hash that limits the character length?

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)

that's not really arbitrary as much as that is what the traditional unix hash algorithm supported

i think it was solaris 8 (maybe 10, but i swear it was sooner) added alternate, more secure methods

that weren't subject to the limitation

anyway to make pam_unix use those hashes and not break the LDAP integration?

i think i had issue with that in the past too

i don't think so

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?

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?

yes, you'll need to use a proxy account that has permissions to modify that attribute for any user

well it's the difference between using LDAP as a dumb data store for basically the exact contents of /etc/passwd and /etc/shadow

and using LDAP to hold the passwd data and using it more as an authentication service (using pam_ldap)

if that makes any sense

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

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?

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

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

it also can synchronize the local ldap profile from an entry in LDAP

KungFuJesus: in such cases, I usually leave an additional root window or two open so i can undo anything

if using openindiana or omnios, you could also backup the be before making changes

yeah, though this thing is a pretty heavily used file server in production

or create a new be, temporairly activate it, make changes... then only if they're ok, activate it

(that way a reboot automatically reverts it)

yeah.. i wouldn't suggest making such changes outside of a maintenance window if it's in use

docs.oracle.com/cd/E53394_01/html/E…4912/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?

that looks right from what I recall, but i'd try to test it somewhere

just to be safe

hmm, might make sense to setup a zone or VM or something to do this

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?

and can I still have those manual attribute mappings appended to the command (sans the password one, of course)

yeah.. the proxy account is just used to lookup those attributes

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

[illumos-gate] 15464 viona should copy tx buffers by default -- Jorge Schrauwen <sjorge⊙bb>

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.