Re: pf on carp backup resets connection after failover
Hello @misc,
Just some further information on this.
When I stop relayd and enter the pf rules like relayd does with
its anchor, then it's - more or less - working as expected.
When I start an upload within an SFTP session and failover, then
the session is "stalled" nearly forever. When I set the
tcp.established to 60 (instead of 600), then the "state" times
out but the SFTP client starts reconnecting after a while
(about 2-3 minutes) and the sessions keeps running.
So it looks like relayd is "terminating" the session when
carp fails over. With relayd and doing a carp failover, I get
an
Broken pipe. Connection reset by peer
immediately.
I just want to know, if this is a normal behaviour with this setup.
Thanks.
Robert
> Gesendet: Mittwoch, 12. Oktober 2016 um 14:21 Uhr
> Von: "Robert Paschedag"
> An: "Robert Paschedag"
> Cc: misc@openbsd.org
> Betreff: Aw: Re: pf on carp backup resets connection after failover
>
> This time it should be better. Again sorry..
>
>
> Hi all,
>
> basically, if have exactly this problem already described here
>
(https://groups.google.com/forum/#!topic/bit.listserv.openbsd-pf/yZn4EUjxwfY)
.
> But because there is no answer since 2009, I'll give it a try.
>
> The setup of the 2 servers is also the same as in the other thread
> only exception is, that my boxes are behind a "master" firewall
> which I do not manage.
>
> I have 2 OpenBSD 6.0 servers that should just act as a load balancer
> for SFTP connections. We use DSR mode because huge files get
> downloaded from the SFTP servers and don't want the "load" to
> pass completly through the OpenBSD load balancers.
>
> Everything is working as long as I don't do a failover to the backup
system.
> In this situation, I see, that the "new" carp master "resets" the
connection
> of the client. Immediatly opening a new SFTP sessions then works as
> expected through the "new" carp master.
>
> This is my /etc/pf.conf (identical on both). Still testing..
>
> # cat /etc/pf.conf
> carp_if = "vmx0"
> sync_if = "vmx1"
> # already allow pfsync and carp protocols
> pass quick on $sync_if proto pfsync keep state (no-sync)
> pass on $carp_if proto carp keep state (no-sync)
> # allow relayd to communicate with pf and set rules
> anchor "relayd/*"
>
> And this is the relayd.conf
>
> log updates
> prefork 5
> fx_vip = "VIP"
> table {
> "host1"
> "host2"
> }
> redirect FX-SFTP {
> listen on $fx_vip port 22 interface vmx0
> route to check tcp interface vmx0
> sticky-address
> }
>
> This is the "ruleset" (identical on both) after reloading pf
>
> # pfctl -a '*' -s rules
> pass quick on vmx1 proto pfsync all keep state (no-sync)
> pass on vmx0 proto carp all keep state (no-sync)
> anchor "relayd/*" all {
> anchor "FX-SFTP" all {
> pass in quick on vmx0 on rdomain 0 inet proto tcp from any to VIP port =
22
> flags any keep state (sloppy, tcp.established 600)
> route-to @vmx0 round-robin sticky-address
> }
> }
>
> When the first connection is made, I see the state on the
> backup carp machine. But with slightly different content.
>
> This is on "master"
>
> all tcp VIP:22 <- CLIENT:43334 ESTABLISHED:ESTABLISHED
>[0 + 1] [946261580 + 2]
>age 00:00:35, expires in 00:09:37, 16:0 pkts, 913:0 bytes, anchor 2, rule
2, sloppy
>id: 57fbd552a2b4 creatorid: d4cdd00a
>
> "expires" is 10 minutes (tcp.established 600) and I see the anchor and rule
> which generated state
>
> This in on "backup"
>
> all tcp VIP:22 <- CLIENT:43334 ESTABLISHED:ESTABLISHED
>[0 + 1] [946261580 + 2]
>age 00:00:32, expires in 23:59:41, 0:0 pkts, 0:0 bytes, sloppy
>id: 57fbd552a2b4 creatorid: d4cdd00a
>
> expires is 1 day (?) and "backup" did not yet see any packes.
>
> Now, how can I get this to work, so the sessions won't be terminated
> in case of a failover.
>
> Every help will be appreciated.
>
> Kind regards,
> Robert
>
>
> > Gesendet: Mittwoch, 12. Oktober 2016 um 14:18 Uhr
> > Von: "Robert Paschedag"
> > An: misc@openbsd.org
> > Betreff: Re: pf on carp backup resets connection after failover
> >
> > Sorry for this bad web mailer formatting. I didn't want that.Am 12.10.2016
2:08 nachm. schrieb Robert Paschedag :
> > >
> > > Hi all, basically, if have exactly this problem already described
here(https://groups.google.com/forum/#!topic/bit.listserv.openbsd-pf/yZn4EUjx
wfY).But
> > > because there is no answer since 2009, I'll give it a try. The setup of
> > > the 2 servers is also the same as in the other threadonly exception is,
> > > that my boxes are behind a "master" firewallwhich I do not manage. I
have
> > > 2 OpenBSD 6.0 servers that should just act as a load balancerfor SFTP
> > > connections. We use DSR mode because huge files getdownloaded from the
> > > SFTP servers and don't want the "load" topass completly through the
> > > OpenBSD load balancers. Everything is working as long as I don't do a
> > > failover to the backup system.In this situation, I see, that the "new"
> > > carp mast
USB mouse not working
Hiya I'm having trouble getting my USB mouse to work in the latest snapshots. Unless my memory is faulty, this mouse used to work only a few months ago I have noticed that the kernel disables the device at boot (see bold text in dmesg below). I've tried disabling xhci, but that doesn't help. Other than that, I'm not really sure what else to do. Does anyone know anything I can try to fix or track down the root cause of this issue? I also have an 3.5mm audio in/out <-> USB converter that appears not to work, again with the kernel disabling the device. I've not looked into this one though. Perhaps it's the same issue Cheers :) OpenBSD 6.0-current (GENERIC.MP) #2473: Sun Sep 18 23:24:19 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17118060544 (16325MB) avail mem = 16594767872 (15826MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xee310 (26 entries) bios0: vendor American Megatrends Inc. version "P1.80" date 10/24/2014 bios0: ASRock 970 Pro3 R2.0 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG AAFT HPET SSDT IVRS BGRT acpi0: wakeup devices SBAZ(S4) UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PC02(S4) PC04(S4) PC09(S4) PC0A(S4) PC0B(S4) PC0D(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD FX(tm)-8320 Eight-Core Processor, 3492.88 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN T,AES,XSAVE,OSXSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPI CSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPE XT,ITSC,BMI1 cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 17 (application processor) cpu1: AMD FX(tm)-8320 Eight-Core Processor, 3492.49 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN T,AES,XSAVE,OSXSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPI CSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPE XT,ITSC,BMI1 cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 18 (application processor) cpu2: AMD FX(tm)-8320 Eight-Core Processor, 3492.49 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN T,AES,XSAVE,OSXSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPI CSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPE XT,ITSC,BMI1 cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 19 (application processor) cpu3: AMD FX(tm)-8320 Eight-Core Processor, 3492.49 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN T,AES,XSAVE,OSXSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPI CSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPE XT,ITSC,BMI1 cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 20 (application processor) cpu4: AMD FX(tm)-8320 Eight-Core Processor, 3492.49 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN T,AES,XSAVE,OSXSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPI CSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPE XT,ITSC,BMI1 cpu4:
Re: Full disk encryption by auto install
This has been discussed previously... And recently. Search the mailing lists and you will find your answers. â£â On Oct 17, 2016, 23:12, at 23:12, "Tito Mari Francis Escaño" wrote: >Hello everyone, >Is full disk encryption via auto install script feasible? Has anyone >tried this before? Maybe somebody can share pointers on what to watch >out for if it's already been done. >I was wondering how the full disk encryption password can be secured >during auto install. Maybe somebody can share their practices on this. >Thanks so much.
Full disk encryption by auto install
Hello everyone, Is full disk encryption via auto install script feasible? Has anyone tried this before? Maybe somebody can share pointers on what to watch out for if it's already been done. I was wondering how the full disk encryption password can be secured during auto install. Maybe somebody can share their practices on this. Thanks so much.
Re: How assign some logic to handle system-gone-totally-unresponsive events (if not else then to enable admin with differentiated failure tracking between userland and hardware failures)
Anton, On 2016-10-18 09:46, li...@wrant.com wrote: Hi Tinker, [..] How to trig some event logic when the system has become vegetable because of overload by the userland? You're referring here to a watchdog timer, as present in some (most) BMC controllers, this usually requires an OS timer reset process, see these: [..] The watchdog is realised in HW with a BIOS option to enable its timeout. When timer is not cleared by the OS process, the BMC reboots the system. [..] timer with a SW guard process. This is an ARM SBC, it has no BMC and AFAIK no watchdog or other timer that can be programmed to cause a reboot, if you are aware of anything like that on ARM SBC:s let me know? My limited experience here says that system overload caused by user processes can lead to that all processes die or freeze, and that the system goes otherwise unresponsive, except for that terminal input still is echoed. Well, what are the process limits used for then, these should help here? Then as difficult as it gets, the mission is to run the system reliably. Because of limited RAM, RAM is scarce and under some pressure. Running out of RAM is closer to happening on a limited-resources machine like this where one process may rather consume 50-90% of the system's RAM than say 10% which would be more typical on server hardware. However RAM exhaustion could happen on a server also if processes collectively use up all of it. Also I guess there are resources other than RAM whereby userland could exhaust the system. And for that I speculated that such event logic could be implemented as some in-kernel code e.g. as a kernel thread, if those have some kind of higher execution guarantee than user process code, Most probably, you are well aware of kernel level tracing and debugging. [..] Debugging user programs, and the kernel, is well documented in manuals. Maybe you have some idea or proposal, that I am not able to understand. What I was looking for is some foolproof logic for system exhaustion caused by the userland, to dump state, sync filesystems, and reboot. Kernel tracing and debugging functionality is perhaps involved in some sense but not in the ordinary sense of being used by an admin via the console. SoftECC (a bit-flip detection mechanism / an ECC emulator) wouldn't help this. If you have any thought about how make that happen feel free to share. Anyhow in the absence of any such logic, just doing a hardware reset is fine, it's just a bit constrained as it comes without automated reporting&recording that could be used to distinguish hardware/kernel issues from userland issues, which encourages hardware replacement and userland software debugging beyond what's really necessary. Tinker
Re: How assign some logic to handle system-gone-totally-unresponsive events (if not else then to enable admin with differentiated failure tracking between userland and hardware failures)
Tue, 18 Oct 2016 08:43:39 +0800 Tinker > Hi Anton, > > You misread me - Hi Tinker, This was intentional, as SoftECC is what you'd relate to, in contrast to the hardware ECC (SECDED), see: https://en.wikipedia.org/wiki/ECC_memory After the article page below references there is an external link called SoftECC: A System for Software Memory Integrity Checking http://pdos.csail.mit.edu/papers/softecc:ddopson-meng/softecc_ddopson-meng.pdf > What I queried for was not how to trig some event logic on bit flip > errors (because on a non-ECC machine those will generally appear as data > corruption or undefined behavior only) or other hardware or kernel > error, but: > > How to trig some event logic when the system has become vegetable > because of overload by the userland? You're referring here to a watchdog timer, as present in some (most) BMC controllers, this usually requires an OS timer reset process, see these: https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface https://en.wikipedia.org/wiki/Watchdog_timer > My limited experience here says that system overload caused by user > processes can lead to that all processes die or freeze, and that the > system goes otherwise unresponsive, except for that terminal input still > is echoed. Well, what are the process limits used for then, these should help here? Then as difficult as it gets, the mission is to run the system reliably. > And for that I speculated that such event logic could be implemented as > some in-kernel code e.g. as a kernel thread, if those have some kind of > higher execution guarantee than user process code, Most probably, you are well aware of kernel level tracing and debugging. > E.g., when a userland watchdog/monitoring process didn't send any "I'm > OK" signal to that thread for 60 seconds, that thread would dump the > system's state to the console and reboot the machine. The watchdog is realised in HW with a BIOS option to enable its timeout. When timer is not cleared by the OS process, the BMC reboots the system. > This way I'd be able to distinguish userland-caused system crashes from > hardware/kernel crashes, as the further always make that output and > reboot, whereas the latter don't (but instead reboot, crash to kernel > debug console, or just freeze the system altogether). Debugging user programs, and the kernel, is well documented in manuals. Maybe you have some idea or proposal, that I am not able to understand. > Do you see where I was heading now? > > Tinker > Let's hope there're some pointers, or you further expand your concepts. Both HW ECC & watchdog timer are available on server class main boards, & work as advertised: ECC transparently, timer with a SW guard process. What I want to know, however, is how is OpenBSD handles ECC, if at all? Kind regards, Anton
Re: How assign some logic to handle system-gone-totally-unresponsive events (if not else then to enable admin with differentiated failure tracking between userland and hardware failures)
On 2016-10-18 05:25, li...@wrant.com wrote: Mon, 17 Oct 2016 18:00:39 +0200 Karel Gardas 1) use machine with proper ECC support Hello Karel, Please explain this "proper ECC support" for every laptop user out there? [..] Mon, 17 Oct 2016 21:48:47 +0800 Tinker Sometimes a machine goes unresponsive. In this case, a non-ECC RAM machine. Hello Tinker, This is one very intriguing problem with a very trivial solution: reboot. The idea to work around missing ECC support with software is as practical [..] Hi Anton, You misread me - What I queried for was not how to trig some event logic on bit flip errors (because on a non-ECC machine those will generally appear as data corruption or undefined behavior only) or other hardware or kernel error, but: How to trig some event logic when the system has become vegetable because of overload by the userland? My limited experience here says that system overload caused by user processes can lead to that all processes die or freeze, and that the system goes otherwise unresponsive, except for that terminal input still is echoed. And for that I speculated that such event logic could be implemented as some in-kernel code e.g. as a kernel thread, if those have some kind of higher execution guarantee than user process code, E.g., when a userland watchdog/monitoring process didn't send any "I'm OK" signal to that thread for 60 seconds, that thread would dump the system's state to the console and reboot the machine. This way I'd be able to distinguish userland-caused system crashes from hardware/kernel crashes, as the further always make that output and reboot, whereas the latter don't (but instead reboot, crash to kernel debug console, or just freeze the system altogether). Do you see where I was heading now? Tinker
Re: How to both redirect to console and screen
On Mon, Oct 17, 2016 at 11:34:02AM +, Mik J wrote: > Hello, > It is possible to redirect the boot sequence to the console using > # cat /etc/boot.conf > set tty com0 > But then there is no screen output. How is it possible to have both of them ? > > > Thank you This does not answer your question, but I'd like to point you at # dmesg -s which may or may not be an alternative solution to the problem at hand. /Alexander
Re: How assign some logic to handle system-gone-totally-unresponsive events (if not else then to enable admin with differentiated failure tracking between userland and hardware failures)
Mon, 17 Oct 2016 18:00:39 +0200 Karel Gardas > 1) use machine with proper ECC support Hello Karel, Please explain this "proper ECC support" for every laptop user out there? I am not sure my system implements "proper ECC support", how to validate? Can you advise why OpenBSD developers still run laptops if they lack ECC? Kind regards, Anton Mon, 17 Oct 2016 21:48:47 +0800 Tinker > Sometimes a machine goes unresponsive. In this case, a non-ECC RAM > machine. Hello Tinker, This is one very intriguing problem with a very trivial solution: reboot. The idea to work around missing ECC support with software is as practical as using a system without hardware accelerated graphics / virtualisation. You're looking for ways to implement this yourself as I would not use it, unless obvious there is minimal performance penalty. It looks like there is absolutely no practical use of my expensive ECC setup, where I upgrade more often than I see the (any) ECC errors and the lockups you advertise. Can someone please explain how (if) OpenBSD does get ECC events reported? Kind regards, Anton
Re: How to both redirect to console and screen
On Montag, 17. Oktober 2016 11:34:02 PYST Mik J wrote: > Hello, > It is possible to redirect the boot sequence to the console using > # cat /etc/boot.conf > set tty com0 > But then there is no screen output. How is it possible to have both of them > ? > > > Thank you what about doas script -a /dev/ttyp1 from ttyp0? Oh, you mean during boot? Cheers -- Eike Lantzsch ZP6CGE
Re: How to both redirect to console and screen
On 2016-10-17, Mik J wrote: > Hello, > It is possible to redirect the boot sequence to the console using > # cat /etc/boot.conf > set tty com0 > But then there is no screen output. How is it possible to have both of them ? There's no dual-console support in OpenBSD.
Re: How assign some logic to handle system-gone-totally-unresponsive events (if not else then to enable admin with differentiated failure tracking between userland and hardware failures)
1) use machine with proper ECC support 2) man sendbug -- and following it report your OpenBSD kernel misbehavior On Mon, Oct 17, 2016 at 3:48 PM, Tinker wrote: > Sometimes a machine goes unresponsive. In this case, a non-ECC RAM machine. > > The reason could be that something in the hardware or kernel failed, e.g. a > bit flip error [1]. > > In this case (for a non-kernel developer), tough luck, and the proper thing > would be to reboot, and keep statistics over failures on that machine and > replace the hardware should the crashes go above some frequency threshold.
Re: How to both redirect to console and screen
Hello, write in /etc/boot.conf stty com0 115200 # Set the correct baud rate for com port set tty com0 # Redirect output to console port com0 Edit your baudrate. For e.g. APU2 it's 115200, may differ from other pc's. -stefan Von: owner-m...@openbsd.org [owner-m...@openbsd.org] im Auftrag von Mik J [mikyde...@yahoo.fr] Gesendet: Montag, 17. Oktober 2016 13:34 Uhr An: Miscellaneous OBSD Betreff: Re: How to both redirect to console and screen Hello, It is possible to redirect the boot sequence to the console using # cat /etc/boot.conf set tty com0 But then there is no screen output. How is it possible to have both of them ? Thank you
How assign some logic to handle system-gone-totally-unresponsive events (if not else then to enable admin with differentiated failure tracking between userland and hardware failures)
Sometimes a machine goes unresponsive. In this case, a non-ECC RAM machine. The reason could be that something in the hardware or kernel failed, e.g. a bit flip error [1]. In this case (for a non-kernel developer), tough luck, and the proper thing would be to reboot, and keep statistics over failures on that machine and replace the hardware should the crashes go above some frequency threshold. OR, the reason could be that the user process(es) that do the work on the machine, consumed all resources, in particular RAM, in such a particularly nasty way that it stopped responding - (those) process(es) shut down, OpenSSHD shut down, no console responsivity including CTRL+ALT+DEL (didn't ever try kernel debug shortcut when I experienced something like this though). I think I've seen cases of that where this is the case and it's totally unlikely that the machine not was busy swapping to disk. The primary reason for such a failure, then, I guess, would be that memory had run so low that malloc() failures took down processes or at least froze them. Any failure of this category would provide a good reason to debug the userland software. The most interesting thing to know from a failed machine would be which of these two categories of crashes it was that happened, as the response is so different. And, to figure this a bit, I wanted to raise the question with you, if there's any way to guaranteedly trig some logic when userland died totally. E.g. as a kernel thread. I guess "died totally" could be defined as that some watchdog/monitoring process in userland hadn't given the kernel an "I'm okay" signal in 90 seconds. I guess proper response would be to print a complete report to the (serial) console e.g. names and stacks of all running processes, unmount and sync the filesystems, and reboot - all in a malloc()-failure proof way. So to sum up: * Did anyone have any problems of this kind (total system unresponsivity after supposed system overload due to userland malbehavior)? * Does anyone feel a logic something like this (to distinguish HW/kernel failure from userland malbehavior) would be materially relevant? * If so where and how do you think it would be best implemented, is there anything in the box that could fill this function in an as foolproof way as possible already? Thanks! Tinker [1] http://stackoverflow.com/questions/23587591/software-memory-bit-flip-detection-for-platforms-without-ecc
Re: How to both redirect to console and screen
Hello, It is possible to redirect the boot sequence to the console using # cat /etc/boot.conf set tty com0 But then there is no screen output. How is it possible to have both of them ? Thank you
Re: What are the security features in OpenBSD 6.0 that are by default disabled?
On Mon, 17 Oct 2016 14:38:00 +0300 Gregory Edigarov wrote: > On 14.10.16 22:48, Raul Miller wrote: > > On Fri, Oct 14, 2016 at 2:50 PM, thrph.i...@gmail.com > > wrote: > >> " The only truly secure system is one that is powered off, cast in > >> a block of concrete and sealed in a lead-lined room with armed > >> guards - and even then I have my doubts." > > Powered off works surprisingly well for some other operating > > systems. > well, not any more, in the presence of Intel AMT... It's not just Intel either: https://www.amd.com/en-us/innovations/software-technologies/security Catering to low-level laziness at the expense of everyone who dares use these chips. There appears to be a niche market possibly emerging in Russia as a result of this kind of thing. http://russia-insider.com/en/technology/russias-next-generation-elbrus-8c-chips-be-ready-2016/ri7551 https://meduza.io/en/feature/2015/06/02/when-there-s-no-shame-in-made-in-russia Disclaimer: do not ignore the possibility of Russian backdoors. Still, it would be nice if they would ship it worldwide, we may even have OpenBSD/elbrus.
Re: What are the security features in OpenBSD 6.0 that are by default disabled?
On 14.10.16 22:48, Raul Miller wrote: On Fri, Oct 14, 2016 at 2:50 PM, thrph.i...@gmail.com wrote: " The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts." Powered off works surprisingly well for some other operating systems. well, not any more, in the presence of Intel AMT...
