Re: Using /32 resp. /128 netmask for carp ips
To add to this, just as when using other first-hop redundancy protocols like VRRP or HSRP on a Router or Layer-3 switch, we only want the single IP address to float between the redundant hosts, and not the entire subnet. So we define the most specific subnet mask for IPv4, which is 255.255.255.255 or /32 or if using IPv6, /128. On Fri, Nov 23, 2018 at 1:16 PM Janne Johansson wrote: > Den fre 23 nov. 2018 kl 18:50 skrev Joerg Streckfuss < > streckf...@dfn-cert.de>: > > > > Dear list, > > > > i want to know why it is good practice to use /32 netmask for ipv4 > > respectively /128 netmask for ipv6 addresses on carp interfaces, while > using the > > "real" netmask for example /24 for a dedicated address on an interface. > > So that the real interface gets used for outgoing traffic generated on > the boxes, like ntp, > syslog, mails and so forth, even if the carp currently is not up (ie not > master) > > -- > May the most significant bit of your life be positive. > >
Re: Syncthing
On Fri, 23 Nov 2018 at 19:48:04 +0100, Jan Betlach wrote: > Hi all, > > I am trying to sync my media libraries via Syncthing with other machine. > However Syncthing on OBSD complains about "too many open files" and refuses > therefore to scan and synchronize the folder. > > I have increased sysctl kern.maxfiles as well as openfiles-max for the > staff group (of which the user is a member) in login.conf. Probably still > not enough. > > What are safe maximal values for both (kern.maxfiles and openfiles-max) to > use? Hi, Newer versions of syncthing use kqueue by default to watch for file changes which ends up using a couple file descriptors per-sub-directory. You may be better off just disabling this on large shared folders and go back to periodic scanning. This can be done through the web interface by clicking on the folder, then Edit, then Advanced, then uncheck 'Watch for Changes'. https://github.com/syncthing/syncthing/issues/5025
Re: non-interactive sh and SIGTERM
Sorry about the wrong report, I just tested again and I can see the same behaviour with OpenBSD 6.4: sending SIGTERM to the sh process after launching sh -c 'sleep 1000' does not result in sh sending a SIGTERM to the sleep process. Philip, what was your test? Thanks On Fri, Nov 23, 2018 at 09:50:29AM +0100, Olivier Taïbi wrote: > After some testing, this issue does not seem to be directly caused by > ksh. Compiling ksh from a year ago, I get the same behaviour: SIGTERM is > not passed on to child. I'm not sure what to try next. Bisecting > /usr/src? > > On Fri, Nov 23, 2018 at 08:55:16AM +0100, Olivier Taïbi wrote: > > On Thu, Nov 22, 2018 at 05:14:38PM -0800, Philip Guenther wrote: > > > On Thu, Nov 22, 2018 at 3:08 PM Olivier Taïbi wrote: > > > > > > > It seems that non-interactive sh(1) (i.e. sh -c command or sh file) > > > > ignores the TERM signal. I'm surprised, is this the intended behaviour? > > > > The man page says that interactive shells will ignore SIGTERM, but does > > > > not mention the non-interactive case. > > > > > > > > > > In my quick test it doesn't ignore SIGTERM, so you'll need to provide > > > additional information for us to help you. > > > > Oops, I did not notice that sh ignores SIGTERM on my -current > > installation but not on 6.4 (different machine though). The minimal test > > is: > > sh -c 'sleep 1000' > > then kill this sh process. Nothing happens, but killing the sleep > > process terminates it. > > > > In fact it is not completely true that sh ignores SIGTERM, but it seems > > that it is waiting for the current running command to terminate on its > > own, rather than forwarding the signal. That is, after running > > sh -c 'while [ -z "" ]; do sleep 10; echo test; done' > > and sending SIGTERM to sh, it will terminate (and print 'Terminated') > > after the sleep is complete. > > > > I did not imagine this was recent because I thought that this behaviour > > was the reason for this bug: > > https://github.com/lervag/vimtex/issues/1032 > > that I can reproduce. > > > > Thanks for your help. > > > > > > > > Philip Guenther
Syncthing
Hi all, I am trying to sync my media libraries via Syncthing with other machine. However Syncthing on OBSD complains about "too many open files" and refuses therefore to scan and synchronize the folder. I have increased sysctl kern.maxfiles as well as openfiles-max for the staff group (of which the user is a member) in login.conf. Probably still not enough. What are safe maximal values for both (kern.maxfiles and openfiles-max) to use? Thank you Jan
Re: Using /32 resp. /128 netmask for carp ips
Den fre 23 nov. 2018 kl 18:50 skrev Joerg Streckfuss : > > Dear list, > > i want to know why it is good practice to use /32 netmask for ipv4 > respectively /128 netmask for ipv6 addresses on carp interfaces, while using > the > "real" netmask for example /24 for a dedicated address on an interface. So that the real interface gets used for outgoing traffic generated on the boxes, like ntp, syslog, mails and so forth, even if the carp currently is not up (ie not master) -- May the most significant bit of your life be positive.
Using /32 resp. /128 netmask for carp ips
Dear list, i want to know why it is good practice to use /32 netmask for ipv4 respectively /128 netmask for ipv6 addresses on carp interfaces, while using the "real" netmask for example /24 for a dedicated address on an interface. Any advice ? Thanks, Joerg
OpenBGPD set nexthop blackhole qualify question
Hi misc@ readers, I have a question regarding the "set nexthop blackhole" nexthop qualification in OpenBGPD 6.4 stable. It looks like I have to add "nexthop qualify via default" in order for the blackholed route to make it from the rib to the fib. I understand this is standard behaviour for normal BGP nexthop qualification, but is this mandatory/normal/expected for blackholed prefixes too ? I would have thought that since I am blackholing the prefix there's nothing to qualify for anyway. Thanks for your help and tremendous work ! Have a nice day ! Arnaud
Re: Supermicro X7SPA-HF D510 and OpenBSD
Thanks for your answers. Probably I will buy one and check it out. > Everything seems to work just fine, only problems are that it can't > support a lot of graphical modes (xenocara will run, just not very well, > since the gpu only has 8 MB of memory and it comes from the main pool of > memory anyway). It does not matter to me. 8MB is OK for OS installation. I am not gonna use X, serial console and ssh is all I need. On Thu, 22 Nov 2018 12:01:36 -0800 Misc User wrote: > On 11/22/2018 6:13 AM, Stuart Henderson wrote: > > On 2018-11-22, Radek wrote: > >> Hello, > >> does anybody run OpenBSD 6.3/amd64 or 6.4/amd64 on SUPERMICRO X7SPA-HF > >> D510? > >> Does it work well together? > >> > >> I need to build a backup server (rsync only) with 2-3x 4TB HDD, 3U/4U Rack > >> case for better cooling. RAID is not needed. > >> It must be as silent as possible. Low power consumption is also welcomed. > >> > >> Thanks! > > > > Not sure if I have that *exact* board but I have something very similar, > > I wouldn't expect any problems with this. > > > > > > I am running the X7SPA-HF-D525 version (Same board, different chip. The > D525 and D510 are really just the same chip anyway, just that the D510 > has a slightly different set of bits burned into the configuration fuses). > > Everything seems to work just fine, only problems are that it can't > support a lot of graphical modes (xenocara will run, just not very well, > since the gpu only has 8 MB of memory and it comes from the main pool of > memory anyway). That and you can't communicate with the IPMI interface > from within the OS (But doesn't prevent you from using the IPMI > interface, you'd just need to do any configuration of it via BIOS or the > IPMI's web interface). > > dmesg from my system is below > > > OpenBSD 6.4 (GENERIC.MP) #0: Sat Nov 17 22:15:46 CET 2018 > > r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4277665792 (4079MB) > avail mem = 4138745856 (3947MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9ac00 (19 entries) > bios0: vendor American Megatrends Inc. version "1.2" date 09/14/11 > bios0: Supermicro X7SPA-HF > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST > acpi0: wakeup devices P0P1(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) > EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) P0P6(S4) > P0P7(S4) P0P8(S4) P0P9(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.30 MHz, 06-1c-0a > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu0: 512KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 207MHz > cpu0: mwait min=64, max=64, C-substates=0.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1872.00 MHz, 06-1c-0a > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu1: 512KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 3 pa 0xfec0, version 20, 24 pins, remapped > acpimcfg0 at acpi0 > acpimcfg0: addr 0xe000, bus 0-255 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 4 (P0P1) > acpiprt2 at acpi0: bus 1 (P0P4) > acpiprt3 at acpi0: bus -1 (P0P5) > acpiprt4 at acpi0: bus -1 (P0P6) > acpiprt5 at acpi0: bus -1 (P0P7) > acpiprt6 at acpi0: bus 2 (P0P8) > acpiprt7 at acpi0: bus 3 (P0P9) > acpicpu0 at acpi0: C1(@1 halt!) > acpicpu1 at acpi0: C1(@1 halt!) > acpicmos0 at acpi0 > acpibtn0 at acpi0: PWRB > ipmi at mainbus0 not configured > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02 > ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi > pci1 at ppb0 bus 1 > ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi > pci2 at ppb1 bus 2 > em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address > 00:25:90:62:cc:46 > ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi > pci3 at ppb2 bus 3 > em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address > 00:25:90:62:cc:47 > uhci0 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 23 > uhci1 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 19 > ehci0 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 23 > usb0 at ehci0: USB revision
Re: non-interactive sh and SIGTERM
After some testing, this issue does not seem to be directly caused by ksh. Compiling ksh from a year ago, I get the same behaviour: SIGTERM is not passed on to child. I'm not sure what to try next. Bisecting /usr/src? On Fri, Nov 23, 2018 at 08:55:16AM +0100, Olivier Taïbi wrote: > On Thu, Nov 22, 2018 at 05:14:38PM -0800, Philip Guenther wrote: > > On Thu, Nov 22, 2018 at 3:08 PM Olivier Taïbi wrote: > > > > > It seems that non-interactive sh(1) (i.e. sh -c command or sh file) > > > ignores the TERM signal. I'm surprised, is this the intended behaviour? > > > The man page says that interactive shells will ignore SIGTERM, but does > > > not mention the non-interactive case. > > > > > > > In my quick test it doesn't ignore SIGTERM, so you'll need to provide > > additional information for us to help you. > > Oops, I did not notice that sh ignores SIGTERM on my -current > installation but not on 6.4 (different machine though). The minimal test > is: > sh -c 'sleep 1000' > then kill this sh process. Nothing happens, but killing the sleep > process terminates it. > > In fact it is not completely true that sh ignores SIGTERM, but it seems > that it is waiting for the current running command to terminate on its > own, rather than forwarding the signal. That is, after running > sh -c 'while [ -z "" ]; do sleep 10; echo test; done' > and sending SIGTERM to sh, it will terminate (and print 'Terminated') > after the sleep is complete. > > I did not imagine this was recent because I thought that this behaviour > was the reason for this bug: > https://github.com/lervag/vimtex/issues/1032 > that I can reproduce. > > Thanks for your help. > > > > > Philip Guenther
