I made it, and I don't even think I saved a copy

aw

not sure it would be of any use to you since it didn't really have any nvidia support

oh i was just wanting to peek into the code out of curiosity, in the meantime i'm going nuclear and rebuilding x with cursed studio FCS

I thought it was on hg.openindiana.org at one point, but that's long gone now

Never looked deeply into audit, but can it be made to make a syslog entry if a user does a write to a specific file, say, /etc/passwd ?

not as far as i know

one thing i've never looked at other than noting it's there

is that part of the zfs acls is an 'audit' auction that AFAIK does nothing

(like goggles :P)

a thought i had a _long_ time ago would be an audit action that'd just trigger on files with such permissions

yeah, I know its there, and its complicated, but never tried it

of course

what happens if someone does like an mv

seems I can use "auditreduce" to look for specific files

and replaces the file

etc.

but that appears to be something you run after.. not produced to syslog

because yeah, it'd be nice to be able to say 'hey a write happened to /etc/passwd or /etc/shadow'

but something wrote to /tmp or /var/tmp? probably not as interesting to log

definitely

though at least the model is generally more useful

granted it's been a long time

but when i looked at the auditing available on redhat or centos, it seemed pretty worthless in that it didn't seem to really capture anything of interest

(suse seemed like it _might_ have been better, but that wasn't an option)

(IIRC, openbsd modeled their auditing after the solaris/illumos model)

in this case, its not something I think is worthwhile - but the mgrs have said we have to send syslog if someone writes to passwd

dtrace is a bit heavy to run :)

if it's that specific, i wonder if you could write something using file monitoring w/ event ports

grok.elemental.org/source/xref/illu…md/watch_dir/watch_dir.c?r=71b43f2a has an example both of event ports and inotify (though inotify is mostly for linux compat, and might not be in whichever distro you're using)

watchign a directory, but might help as a guide

there is fswatcher yes - could be an option

but I thought events wasin Sol11, thus not in illumos?

there might be some additional bits not implemented in illumos (haven't looked) but there are at least a decent set of file based events

the port_associate(3C) man page has more details on what events are there for files

fswatch compiled at least

lundman : what about /etc/security/audit_event and the output in /var/audit ?

i have no idea - audit seems like a really large hammer

For what it's worth, though that exact behaviour might not be present yet, that's exactly the kind of thing audit is for

DTrace would be a poor choice for auditing because you can make it drop events

And using FEN to watch the file or whatever will tell you (after) that it has changed, but won't tell you how many times and who did it

jbk the smbios address is coming from efi-systab

i nuked the kernel from a live image by accident

why is the fb console so slow

i assume it's using the PROM framebuffer routines (int 16)?

slow where?

and uefi or bios version?

a pkg update/fix/etc takes ages to do if nvidia braindumps

because it's taking longer to update the display than actually doing the package operation

ah, when os is running. you can do few things about it. get better gfx card, tune down depth (only in BIOS mode), switch to text mode (only in BIOS mode).

ah

yeah i don't have a separate EFI framebuffer so i'd be even worse off if i used the EFI boot monitor instead of BIOS

if you are using UEFI, then there is no text mode (no VGA BIOS), and the only supported depth is 32.

i.e. the ryzen 7 series requires a gpu

yeah

drm-kms would help, but I'm still trying to learn about it (we only have limited gpu support there anyhow)

is it possible to change the default console font

or is that baked into the kernel

yes, from loader

oh

set screen-font will list you available ones

no times, we can only use bitmap fonts and the current list is selection from terminus + you can load gallant with loadfont command (ls /boot/fonts)

ah

at this time, for FB mode, we only can draw directly on linear frame buffer, for better results the drm would be needed (I do not think it is worth to invest time into in kernel vbe)

> first thing in the ips docs: do not subset packages

i see

ok so it's not nearly as bad

worst case would be to drop into real mode to call PROM INT16

in kernel, we do use ram buffer for primitive double buffering

but ofc it is not as good as page flipping etc

outlook: neutral (at least it doesn't core immediately)

core is usually hint about bug in code:D

yeah there's at least one bug in the nvidia GLX driver but at least a studio-built xorg isn't making things worse

lundman : audit is active on triton smartos CNs by default (I have not activated it)

lundman : I wasn't aware of it until I watched youtube.com/watch?v=96PGoXHli3Q

[illumos-gate] 13217 Allow building with python 3.9 -- Andy Fiddaman <omnios⊙ccu>

[illumos-gate] 13220 Add support for the IA32_FEATURE_CONTROL MSR in bhyve -- Jason King <jason.king⊙jc>

so, python3 is only built 64-bit, right?

depends on the python and the distro, I guess

indeed, well, we have no python on gate

anyhow, and 2.7 is dead, so distros are dropping it?

reports of 2.7's death are somewhat exaggerated

:D

but yes, generally we're trying to move away from it

there's still quite a large part of the world that hasn't moved to python3 though

so, what shall happen with this line: file path=usr/lib/mdb/proc/libpython$(PYTHON_VERSION).so group=sys mode=0555

that one is related to 2.7, as we also do have PYTHON3_VERSION.

jbk I hope this final build will end up clean now and I can confirm OK:)

ok

despair do not sleep next to computer:P

the mapfile stuff?

jbk yes

ok

tiny room, tiny apt :-(

i meant to reply to your questions, but this l2arc stuff derailed me

those are just small ones, nothing to stop things:)

i don't think we've removed the lint stuff yet for sparc

ips manual: "do not subset packages" me: need to break out the x gate to build separately

(it's not used, but still there for the kernel stuff)

oh we have lint bits all over the place anyhow

so at least for some of those, the comment is still relevant in so much as describing what the (dead) parts of the makefile are for

so it might be better to keep it until those bits are yanked out

ok. id you see the note about smbios?

yeah

did*

and thanks

ok

i wanted to confirm that

someone has a system that panics _early_ in the boot, but only when using EFI

(might have seen it on the smartos-discuss list)

we are picking it up from dboot btw

and it's when it the smbios device is opened

hm

no, i haven't seen it

(but only when booting EFI -- legacy bios boots fine)

so i wanted to understand what _should_ be happening

and it does look like an address is getting passed to the kernel

so now I need to understand how that should related to the rest of the memory info :)

err relate

I _think_ (i need to look closer) one of the reserved memory ranges (as displayed by prom_debug) seems to contain the smbios address given to the kernel

i've not looked much at the early boot stuff

so i need to dig to understand if that's expected or not (assuming my math was right)

(unless someone else here happens to know :P)

I don't think there's anything different there between smartos and illumos-gate, so it's likely something that would impact any distro

so, if its listed as reserved, the mapping is not created and it will blow up?

i don't know :)

you can check smbios entries from loader show command

we get some simple data extracted

0x14802b30 smbios-address = len=8 00000000beaea740

that's what gets passed to the kernel

but then it does with 'hat_devload: loading a mapping to free page fffffe00061991f8'

err dies

i don't know if it matters that the starting physical address isn't page aligned (I'm guessing no)

process_efi64() in dboot_startkern.c is setting address to struct xboot_info *bi;

yeah, it looks like the right physical address is getting passed into psm_map_phys_new

(in the code there's a fallback path if the smbios address isn't provided, so first thing was to establish which path it was taking -- we know it's being provided, and it's being passed in)

yea, the bios version is performing the search

there is another thing about memory maps; the efi version will start kernel with efi memory map, but we do not really do anything with it, except there is rough translation to smap like list.

yeah, i need to look at that output and a hex calculator :)

ficl-sys :D

with all the trailing 0s and most of the output as (addr, len) trying to figure out what lies within what isn't easy

unless your max and think in hex :P

err you're

ok, so those pages should not end up in freelist, isn't is what the panic is telling us?

yeah, but not sure how things are normally supposed to work (yet)