@andyf maybe we can look at the man page for viona at FOSDEM?

Or at least get me started.

This is starting to happen on a pretty routine basis: illumos.org/issues/14730 last night it was due to the switches having a blip for 2 minutes

→ BUG 14730: When only site DC reboots, chaos ensues with LDAP and SMB (New)

is there anything that can be done for this?

Like, why does it never attempt to reach the DC again after those 2 minutes?

KungFuJesus: I don't know about the idmapd things but if unix login is not possible it might be that pam settings prevent local logins completely

And also the order of services in nsswitch.conf matters. Make sure files are first

In general all of the user account stuff is very configurable so we will need to know the configs to be able to help

sure, what do you need?

the idmap service is configured in IDMU mode

nssswitch: pastebin.com/gspn0pi5

The hanging login bit I'm almost certain is this one: illumos.org/issues/15024

→ BUG 15024: NFS can exhaust pool threads getting RPCSEC_GSS credentials (In Progress) | code.illumos.org/c/illumos-gate/+/2402

sort of a separate issue, but...related. I'm really really hoping that one gets merged soon, it's been a big problem for us

KungFuJesus: Well the only place would be in pam.conf where the local login thing could be fixed. As said I have no clue about the idmap issues or modes

local login sometimes works afterward, if a ton of threads aren't being consumed by that bug

and sometimes then, restarting the smb and ldap client services fixes it

Yeah then I won't be able to help

COnfig is working but it' can't launch bash I assume

essentially, yes

the not being able to launch processes is likely the thread pools being exhausted in the kernel

very

but that's only a symptom of the general bug of smb and ldap services not being able to recover when a KDC is unreachable

e.g. LDAP logins, smb accesses and nfs access would still be broken without manually kicking over those services, regardless

I don't understand why the smb and ldap services don't have a retry path

toasterson this needs AD setup with at least 2 AD nodes:D

unix local login?

fixing nss

tsoome_: We do but...for a long time the secondary DC in smbd would have all sorts of bizarro issues

I dunno is gordon fixed that yet or not but I'm very hesistant to put in more than one DC

however in the last particular outage it wouldn't have helped, since the switch may have lost power / rebooted

is it ldap or kerberos issue?

both ports on the link aggregation were down for ~2 minutes

In general one DC should not become lockup reason for the OS

the lockup reason is triggered by the kerberized NFS access

true, but then again, we do not even have decent DC cache...

however, even with that absent, we still have an issue where the SMB _and_ ldap client services never try to talk to the DC again after the timeout

That part of nss probably needs a redo

well, if the issue is about single kdc, then ofc kdc needs backup, with ad, thats of course second dc.

I mean we have that and I think my ldapclient command even specifies the second site. However in this case, it wouldn't have helped. The 2 minute network outage made both DCs unreachable

but if you also have ldap config, then ldapcachemgr is also from years ago and does not cope with ms ad well...

-a defaultServerList="et-cin-dc01.INTERNAL.ETEGENT.COM et-day-dc01.INTERNAL.ETEGENT.COM"

I can add a secondary DC to the smb service properties as well, assuming it doesn't cause issues anymore. Can anyone confirm that those issues went away?

I have no facilities to test ad atm:)

and I have code.illumos.org/c/illumos-gate/+/2584 which would be really nice to get tested against ad...

→ CODE REVIEW 2584: 15296 libsmb: array subscript is of type 'char' (NEW) | illumos.org/issues/15296

Hmm, that one seems like it might be _marginally_ ub but not likely to cause issues with most compilers

actually no, the subscripts aren't characters at all. That should not be triggering that warning

Or is it just not happy with the bit shifts that happen to the values? I guess that could be some form of UB depending on if it's a logical or arithmetic shift

interpretation of sign could matter a bit, there

about that warning? array subscription must be int (size does not matter), char is not int, but uint8_t is int.

right but from the MR it looked as though the index was always integer but I didn't see prior versions of it

I've definitely seen issues with signed v unsigned char on big endian platforms

but looking at the comments, it's also been raised that the bitshifts of the values in that array could be problematic if signed and that's why you're using uint8_t

are any of you (hadfl? toasterson? tsoome?) using clang 15?

wacki is currently trying to compile it. Firefox seems to need it

omnios-extra is using it for some packages

yeh there are a few things that hard require it now

to be sure, did you all spot I was asking about 15 specifically?

yes, 15.0.7 currently in pkgsrc

great, but also shit.

richlowe: yep

are you running into the problem where it doesn't build with gcc10?

see DM, but maybe?

[illumos-gate] 15284 tools: remove pragma ident -- Toomas Soome <tsoome⊙mc>

richlowe I'd use but I have no time to build it:D

tsoome_: well, sounds like andyf has one for you :)

and jperkin

:)

tsoome_: offer to access to the OI build server still stands :) With dedicated user

I can take no credit for the omnios packages

and fritz :)

:)

well. but now there is this issue that code.illumos.org/c/illumos-gate/+/2577 and code.illumos.org/c/illumos-gate/+/2578 but there are many files..... I have feeling, the webrev would be better option:D

→ CODE REVIEW 2577: 15289 cmd: remove pragma ident (NEW) | illumos.org/issues/15289

KungFuJesus sounds very similar to illumos.org/issues/13326

→ BUG 13326: nscd stops returning results from LDAP until it is restarted (GSSAPI) (New)

tsoome_: being able to sort on that "Size" column would help

tsoome_: or having separate diffs for "just remove it" and "clean up nits"

mm, I guess thats a point where .editorconfig did backfire a bit:D

I have to admit at this point I thought doing that diff wise was easy, but the manual page isn't helping me

I thought there was a negative -G or a --diff-filter thing

so you could say "give me all the diffs that aren't ident"

oh, git diff -I

might let you say "give me diffs that aren't ident", and then git apply them to a scratch branch to show us

without it being way too much work

it doesn't, because of the blank line removal too

tsoome_: I figure these `git diff --numstat -w illumos/master...remotes/gerrit/changes/78/2578/4 | awk '$1 != 0 || $2 > 2'` are the interesting ones

and possibly only those with additions, really, if wsdiff is clean too.

there's like 100 files with additions, and 600 if you include more than expected delitions

(and I think that's across all your branches, because of how they're stacked)

dunno how easy it would be to pull those out to let people only view the surprising ones.

danmcd: let me know if you are interested in working together to get that 14892 stuff over the line

sorry I sorta dropped the ball on it once it came time to write tests

I will let you know. I have to look at what's here, and what I'm seeing in the customer dump.

Expect to hear from me, but maybe not until later this week? Lots of shit flying, this is only some of it.

that's fine, I have plenty on my plate

if it's a burning issue for y'all, it might be worth trying to replicate the postgres reproducer on some other machine

if you get it blowing up in the same manner, then it'd be at least one smoke-tests for the new bits

it's not like I had a whole suite of signalfd consumers lined up when I did the overhaul

AndyF is going to provide me a VM image with his I-think-reliable reproducer.

Also I had a merge conflict with LX stuff in signalfd. Two lines, but they need to move in your new world order.

(OmniOS will have the same problem because of LX.)

which lines, out of curiosity?

Around here: /* Convert k_siginfo into external, datamodel independent, struct. */

We have a brand-check and a brand-call for signal number conversion.

if you diff signalfd.c between illumos-{joyent,omnios} and -gate you'll see.

It didn't merge easily because of your rewrite (not a shock), but I need to make sure I moved the check-and-conversion prior to USAGE.

So if you diff between the just-now-created illumos-joyent:14892 branch's signalfd.c and your one for -gate, you'll see a similar diff as comparing -{joyent,omnios} to -gate.

I'm back home and on with building the reproducer now

If you look at TritonDataCenter/illumos-joyent #432 it should drop right into illumos-omnios since I did the merge-heck for the LX changes in signalfd.c

ah, that makes sense

Thank you andyf for reproducer building. It's almost dinnertime US/Eastern, so I'll let the smartos-live reality-check build finish in the bg.

is our 'upstream' for mandoc the openbsd one?

I don't know if there's a portable- like for other things, but yes.

yuripv is the main person to talk to about it though.

jbk: There's a regular release tarballs they put out.

I've done recent syncs there. What's up?

hallo!

yes, i know, we speak english here :)

if you spoke complicated german to me i would be lost anyway

I'm actually finally transfering my dev box to a vm, i really need the machine

had one donated especially for illumos but he's apparently busy :(

and i know the sys v way is to use find and cpio but i'm used to tar so i'm using that

oh, i should use p option with tar though... it's my home dir right now so i don't care