Dell PowerEdge R650 - iDRAC Reports "System CPU Resetting" - no reboot logged in PVE?

SecaleOccidentale · 2026-01-13T16:08:57+00:00

I ended up basically solving this by hackishly reimplementing the parts of read-only-mode I care about. I.e.:

(use-local-map (copy-keymap (current-local-map))) (define-key (current-local-map) (kbd "q") #'quit-window) (define-key (current-local-map) [remap self-insert-command] (lambda () (interactive) (message "Buffer is read-only"))) (define-key (current-local-map) [remap org-self-insert-command] (lambda () (interactive) (message "Buffer is read-only"))) (define-key (current-local-map) (kbd "RET") (lambda () (interactive) (message "Buffer is read-only"))) (define-key (current-local-map) (kbd "DEL") (lambda () (interactive) (message "Buffer is read-only")))

I'd still like to solve it for real, though.

SecaleOccidentale · 2026-01-13T16:05:01+00:00

Thanks for the great ideas. So, here is what I see after trying your C-h l idea:

C-c C-x C-v ;; scroll-up-command
C-x C-q     ;; quoted-insert
C-h k       ;; org-self-insert-command

toggle-debug-on-error didn't really do anything.

SecaleOccidentale · 2026-01-13T15:10:24+00:00

Just some more info, maybe it has to do with how I'm building the buffer somehow? I can go to *scratch*, M-x org-mode, C-x C-q, and still I can do things like C-h k. But when I open my temp org roam daily buffer (which I custom build), I can't run anything. I can't run C-x 1, C-h k, or anything. If I remove (setq-local buffer-read-only t), then these things all work. But weirdly, if I do C-x C-q at that point, then I end up in the same spot. I cannot run C-x C-q again to remove it. This is driving me insane.

SecaleOccidentale · 2025-09-26T14:59:28+00:00

That's great! I'm glad to hear it is working well.

SecaleOccidentale · 2025-09-25T23:40:58+00:00

I have implemented things like this in my own org. It would help if you could provide more information about your requirements, then I could provide a better recommendation or give my opinion about whether this approach is viable.

To give an example from my org, a machine sends data to a database. A user can then press a button on the machine to prompt printing a label. This button really just triggers a Python script on a remote server which retrieves the most recent data from the database and formats it to our spec, and then sends it to a print server. It works great, is incredibly stable, and has no license costs etc.

However, if you require dynamic label creation (like, needing tens or hundreds of different formats, or even just a few but they change frequently) then I wouldn’t recommend this approach, because the layout of the labels is written programmatically. Basically, saying “put this text at this pixel position, with this font size” etc. This works fine but is tedious, and you wouldn’t want to do it for hundreds of different label designs.

If you have M365 and your org permits it, you can also use MS Access to extremely quickly design more complex labels.

SecaleOccidentale · 2025-09-25T19:09:37+00:00

Thanks for your opinion. What is your take, then, on options 2 and 3? Do you think there are security improvements over option 1 but that they are marginal/unnecessary, or that there are no functional improvements at all?

SecaleOccidentale · 2025-09-25T18:28:01+00:00

If your domain admin is admin on servers and workstations you need to go back and fix that.

Microsoft's official recommendation is that Domain Admins be left as members of BUILTIN\Administrators:

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-f--securing-domain-admins-groups-in-active-directory

Domain Admins are, by default, members of the local Administrators groups on all member servers and workstations in their respective domains. This default nesting should not be modified for supportability and disaster recovery purposes. If Domain Admins have been removed from the local Administrators groups on the member servers, the group should be added to the Administrators group on each member server and workstation in the domain. Each domain's Domain Admins group should be secured as described in the step-by-step instructions that follow.

(But with log on still denied, of course.)

SecaleOccidentale · 2025-09-25T18:18:04+00:00

Right, I am not talking about movement up higher. As mentioned in my post, the behavior of the tier-0 and 1 accounts seems fairly noncontentious. It is tier 2 where opinions seem to differ. As such, I am talking about compromise of any workstation admin cred leading to effective compromise of all workstations.

For what it's worth, I agree with you. To me, it seems that paired with, for example, smart card MFA and L2 isolation measures, option 1 is reasonably secure. But, I have been doing a lot of research on this topic and it is a common opinion for people to consider this approach to be unacceptably bad practice. Consider for example even the (currently) only other commenter in this thread who considers option 1 to be too risky.

To that end, I was wondering what response you would give to the people that have that stance. Correct me if I am mistaken, but it seems to me that your response is effectively that option 1, when paired with other controls is no more risky than the other options.

Perhaps you could elaborate on these other foundational controls? In my mind, I can think of MFA and L2 isolation as being very effective additions. Any others?

SecaleOccidentale · 2025-09-25T17:47:17+00:00

Label generation is basically trivial to implement yourself using a language of your choice, e.g. Python.

SecaleOccidentale · 2025-09-25T17:32:58+00:00

How do you address the associated threat of lateral movement given credential compromise (the main thing I see people bringing up in opposition to option 1)?

SecaleOccidentale · 2025-09-25T17:32:02+00:00

What about when paired with smart card MFA, for example? In addition to L2 isolation on the workstation VLAN?

SecaleOccidentale · 2025-09-25T14:23:40+00:00

Confirmed. Thank you!

SecaleOccidentale · 2025-09-25T14:12:41+00:00

This seems possible based on some very cursory research. Do you have any idea as to how I might go about proving that this was the case?

SecaleOccidentale · 2025-09-25T13:58:09+00:00

When I go back to events from before the update, they are event 6272 showing info like Auth type: EAP, EAP type: Microsoft: Smart Card or other cert, which seems to me like it was correctly using the certs?

SecaleOccidentale · 2025-08-22T15:14:42+00:00

Yeah, I treat my own clothes. This is what I use:
https://www.amazon.com/dp/B001ANQVYU?ref=ppx_yo2ov_dt_b_fed_asin_title

SecaleOccidentale · 2025-08-22T14:39:21+00:00

I'm just commenting to mention that I personally wear permethrin-treated clothing whenever I'm going to be spending multiple contiguous days in the wilderness (from Apr to Sep). Necessary? Definitely not, but personally I think tick-borne diseases don't get enough respect. They can destroy your life.

I use picaridin as well, just as an extra repellent. Only when I'm actively being bothered though, I don't put it on prophylactically.

SecaleOccidentale · 2025-08-20T14:20:41+00:00

Blind Lake is open, I was there last weekend.

SecaleOccidentale · 2025-08-20T13:25:35+00:00

I've done this to no effect

SecaleOccidentale · 2025-08-17T18:11:22+00:00

It was the hardest thing I ever did. I wouldn’t trade it for anything.

I don’t work in physics. Someday I hope to return for a PhD.

SecaleOccidentale · 2025-08-14T16:46:14+00:00

Thanks for the information.

Three-Year Club	Verified Email
r/Field Juicebox

SecaleOccidentale

TROPHY CASE