Re: ipv6 nd
On Tue, Mar 20, 2018 at 12:19:09AM +, Peter van Oord van der Vlies wrote: > > > > Is slaacd or a dhcpv6 client running? > > Yes i tried with slaacd > Does `slaacctl show interface $if` reflect that a router advertisement > has been received? No, only this : #slaacctl show interface pppoe0 pppoe0: index: 10 running: yes privacy: yes lladdr: 00:00:00:00:00:00 inet6: fe80::200:24ff:fed0:1db0%pppoe0 > -- > 0x7D964D3361142ACF
Re: Relinking unique kernel failed after syspatch
Thus said Leo Unglaub on Tue, 20 Mar 2018 04:57:55 +0100 Hello, today I wanted to apply the latest patches on our servers. They all worked fine, only on one server where i was missing some previous patches as well it got an error from syspatch. Does this explain it? https://marc.info/?l=openbsd-cvs&m=152148043420143&w=2 http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/syspatch/bsd.syspatch.mk
Re: Relinking unique kernel failed after syspatch
Hey, On 03/20/18 05:43, Predrag Punosevac wrote: 1095 KB00:00 Installing patch 010_ahauth Relinking to create unique kernel... failed! I looked into /usr/share/compile/GENERIC.MP/relink.log but the only thing in there is: (SHA256) /bsd: FAILED https://marc.info/?l=openbsd-misc&m=151245106222333&w=2 thank you for the link. I am not sure it fits my case because i did not modify the kernel myself. This server is as unmodified as it gets, there are no packages installed, no binaries changed, ... . The only thing i modified on that server is /etc/ntpd.conf. Thanks anyway and greetings Leo
Re: Relinking unique kernel failed after syspatch
Leo Unglaub wrote: > Hello, > today I wanted to apply the latest patches on our servers. They all > worked fine, only on one server where i was missing some previous > patches as well it got an error from syspatch. > > > # syspatch > > > Get/Verify syspatch62-005_ahopts.tgz 100% \ > > > |**| > \ > > 703 KB00:00 Installing patch 005_ahopts > > Get/Verify syspatch62-006_prevhdr... 100% \ > > > |**| > \ > > 783 KB00:00 Installing patch 006_prevhdr > > Get/Verify syspatch62-007_etherip... 100% \ > > > |**| > \ > > 1030 KB00:00 Installing patch 007_etherip > > Get/Verify syspatch62-008_unbound... 100% \ > > > |**| > \ > > 1294 KB00:00 Installing patch 008_unbound > > Get/Verify syspatch62-009_meltdow... 100% \ > > > |**| > \ > > 40344 KB00:13 Installing patch 009_meltdown > > Get/Verify syspatch62-010_ahauth.tgz 100% \ > > > |**| > \ > > 1095 KB00:00 Installing patch 010_ahauth > > Relinking to create unique kernel... failed! > > I looked into /usr/share/compile/GENERIC.MP/relink.log but the only > thing in there is: > > > (SHA256) /bsd: FAILED > https://marc.info/?l=openbsd-misc&m=151245106222333&w=2
Relinking unique kernel failed after syspatch
Hello, today I wanted to apply the latest patches on our servers. They all worked fine, only on one server where i was missing some previous patches as well it got an error from syspatch. # syspatch Get/Verify syspatch62-005_ahopts.tgz 100% |**| 703 KB00:00 Installing patch 005_ahopts Get/Verify syspatch62-006_prevhdr... 100% |**| 783 KB00:00 Installing patch 006_prevhdr Get/Verify syspatch62-007_etherip... 100% |**| 1030 KB00:00 Installing patch 007_etherip Get/Verify syspatch62-008_unbound... 100% |**| 1294 KB00:00 Installing patch 008_unbound Get/Verify syspatch62-009_meltdow... 100% |**| 40344 KB00:13 Installing patch 009_meltdown Get/Verify syspatch62-010_ahauth.tgz 100% |**| 1095 KB00:00 Installing patch 010_ahauth Relinking to create unique kernel... failed! I looked into /usr/share/compile/GENERIC.MP/relink.log but the only thing in there is: (SHA256) /bsd: FAILED I have not rebooted the server in case there is some additional information I need to provide in order to fix this. (Is there even something to fix? Or is there already an improvement for this in 6.3)? Is it safe for me to reboot this server or do I have something else i need todo before rebooting the server? Here is a full dmesg from that machine: OpenBSD 6.2 (GENERIC.MP) #2: Sun Dec 10 21:14:42 CET 2017 r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6843424 (65294MB) avail mem = 66384637952 (63309MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcbe08000 (78 entries) bios0: vendor FUJITSU // American Megatrends Inc. version "V5.0.0.11 R1.21.0 for D3401-H1x" date 05/15/2017 bios0: FUJITSU D3401-H1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT UEFI SSDT DMAR ASF! acpi0: wakeup devices PEGP(S4) PEG0(S4) PS2K(S3) PS2M(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4) RP01(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) Core(TM) i7-6700 CPU @ 3.40GHz, 3408.00 MHz 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 340800 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3408.00 MHz 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3408.00 MHz cpu2: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3408.00 MHz cpu3: FPU,
What's the inc. SSH conn. launch seq., rel. to login.conf rlimit enforcement?
Hi, When connecting to SSHD and authenticating as a user, in what sequence are various processes launched (shell / shell with "-l" argument / sshd child / login(1)), and in particular, at what stage are login.conf settings enforced into the process context by login(1)? I would guess this is what's described by the "LOGIN PROCESS" section in the sshd(8) man page: * A child SSHD process is spawned already at connect time, meaning prior to step 1, * Steps 1 up to 4 are run as root by the sshd child, * login(1) is execve:ed at step "4. Changes to run with normal user privileges.", and it will * enforce login.conf settings in the process context (rlimits, umask, etc.) while still root, * change user, and * execve /bin/sh (or sshd??) to perform the remaining steps (5-9) * The user's shell (without "-l") is execve:ed in step 9. http://man.openbsd.org/sshd.8#LOGIN_PROCESS http://man.openbsd.org/login.conf.5 Also I'd guess it should be a similar process for SFTP, telnet, and other authenticated services. Is this any correctly understood? Tinker
Re: ipv6 nd
On Tue, Mar 20, 2018 at 12:19:09AM +, Peter van Oord van der Vlies wrote: > > > > Is slaacd or a dhcpv6 client running? > > Yes i tried with slaacd Does `slaacctl show interface $if` reflect that a router advertisement has been received? -- 0x7D964D3361142ACF
Re: ipv6 nd
> Is slaacd or a dhcpv6 client running? Yes i tried with slaacd > -- > 0x7D964D3361142ACF On Mon, Mar 19, 2018, at 16:27, Peter van Oord van der Vlies wrote: > Hello Misc, > > > Today i replaced my cisco 881 because it wasn't able to handle the > bandwidth anymore. > > > I had a working ipv6 setup for years with the following relevant part > from my cisco wan interface > > config part: > > ipv6 address autoconfig > > ipv6 enable > > ipv6 nd ra interval 30 > > ipv6 dhcp client pd my_prefix rapid-commit > > On my obsd wan interface i did ifconfig pppoe0 inet6 autoconf but i am not > getting any global address. > > Anyone here that can set me into the right direction ? > > Thanks! > > Peter > >
Re: ipv6 nd
Is slaacd or a dhcpv6 client running? -- 0x7D964D3361142ACF On Mon, Mar 19, 2018, at 16:27, Peter van Oord van der Vlies wrote: > Hello Misc, > > > Today i replaced my cisco 881 because it wasn't able to handle the > bandwidth anymore. > > > I had a working ipv6 setup for years with the following relevant part > from my cisco wan interface > > config part: > > ipv6 address autoconfig > > ipv6 enable > > ipv6 nd ra interval 30 > > ipv6 dhcp client pd my_prefix rapid-commit > > On my obsd wan interface i did ifconfig pppoe0 inet6 autoconf but i am not > getting any global address. > > Anyone here that can set me into the right direction ? > > Thanks! > > Peter > >
ipv6 nd
Hello Misc, Today i replaced my cisco 881 because it wasn't able to handle the bandwidth anymore. I had a working ipv6 setup for years with the following relevant part from my cisco wan interface config part: ipv6 address autoconfig ipv6 enable ipv6 nd ra interval 30 ipv6 dhcp client pd my_prefix rapid-commit On my obsd wan interface i did ifconfig pppoe0 inet6 autoconf but i am not getting any global address. Anyone here that can set me into the right direction ? Thanks! Peter
Re: minor too small - pkg_add
> You updated from a base snapshot that had libssl.so.44.8 to one that > has 45.0, but skipped the intervening 44.9 one. Unfortunately, the > package snapshot had been built against 44.9. > > > a similar issue with libm. Now I can get around the error by building > > the packages in ports, but I was wondering if there was an easy fix. > > Wait a few hours until the next packages, built against 45.0, hit > the mirrors. > Oh that makes a lot more sense, I'll check it out when I get back from work. Thanks
Re: the Alpha lives...
last update .. Theo has built a new snapshot which I installed on the alpha. It works well, and after booting into it the nsd configure run works just fine. So, thanks to Theo for the latest snap :) Cheers, Paul 'WEiRD' de Weerd [ using 1135448 bytes of bsd ELF symbol table ] consinit: not using prom console Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.3 (GENERIC) #0: Sun Mar 18 18:43:53 MDT 2018 dera...@alpha.openbsd.org:/usr/src/sys/arch/alpha/compile/GENERIC Digital Personal WorkStation 600au, 598MHz 8192 byte page size, 1 processor. real mem = 536870912 (512MB) rsvd mem = 1941504 (1MB) avail mem = 515727360 (491MB) mainbus0 at root cpu0 at mainbus0: ID 0 (primary), 21164A-0 (unknown minor type 0) cpu0: architecture extensions: 1 cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 1 cia0: extended capabilities: 1 cia0: using BWX for PCI config and bus access cia0: WARNING: Pyxis pass 1 DMA bug; no bets... pci0 at cia0 bus 0 dc0 at pci0 dev 3 function 0 "DEC 21142/3" rev 0x30: dec 550 irq 0, address 00:00:f8:76:04:64 nsphy0 at dc0 phy 5: DP83840 10/100 PHY, rev. 1 pciide0 at pci0 dev 4 function 0 "CMD Technology PCI0646" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:0:0): using PIO mode 3, DMA mode 1 pciide0: channel 1 disabled (no drives) sio0 at pci0 dev 7 function 0 "Intel 82378IB ISA" rev 0x43 qlw0 at pci0 dev 12 function 0 "QLogic ISP1020" rev 0x05: dec 550 irq 8 qlw0: firmware rev 4.66.0, attrs 0x0 scsibus1 at qlw0: 16 targets, initiator 7 sd0 at scsibus1 targ 8 lun 0: SCSI2 0/direct fixed serial.SEAGATE_ST34371W_JDD273270M5E3P sd0: 4148MB, 512 bytes/sector, 8496884 sectors sd1 at scsibus1 targ 9 lun 0: SCSI2 0/direct fixed serial.IBM_DCAS-34330W_F3TD8398_ sd1: 4134MB, 512 bytes/sector, 8467200 sectors sd2 at scsibus1 targ 10 lun 0: SCSI2 0/direct fixed serial.IBM_DCAS-34330W_F3TE2118_ sd2: 4134MB, 512 bytes/sector, 8467200 sectors ppb0 at pci0 dev 20 function 0 "DEC 21152" rev 0x02 pci1 at ppb0 bus 1 fxp0 at pci1 dev 8 function 0 "Intel 8255x" rev 0x0c, i82550: dec 550 irq 12, address 00:02:b3:61:21:e3 inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4 fxp1 at pci1 dev 9 function 0 "Intel 8255x" rev 0x08, i82559: dec 550 irq 16, address 00:02:b3:21:cd:c2 inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4 vga0 at pci1 dev 10 function 0 "Matrox MGA 1064SG 220MHz" rev 0x02 wsdisplay0 at vga0 mux 1 wsdisplay0: screen 0-5 added (80x25, vt100 emulation) isa0 at sio0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x3bc/4 irq 7 mcclock0 at isa0 port 0x70/2: mc146818 or compatible stray isa irq 14 stray isa irq 3 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (92145ab06ead027c.a) swap on sd0b dump on sd0b fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec stray isa irq 3 -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: minor too small - pkg_add
Patrick Marchand: > I updated to the latest snapshot yesterday and when I run > pkg_add -Dsnap -u a bunch of pkg will not upgrade because it cant find > ssl.44.9 > > It does find 44.8 and 45 but not that specific version, last week I had You updated from a base snapshot that had libssl.so.44.8 to one that has 45.0, but skipped the intervening 44.9 one. Unfortunately, the package snapshot had been built against 44.9. > a similar issue with libm. Now I can get around the error by building > the packages in ports, but I was wondering if there was an easy fix. Wait a few hours until the next packages, built against 45.0, hit the mirrors. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: OpenSMTPd maillist "compatible" manager Majordomo or what?
On Mon, 19 Mar 2018 18:59:45 +0300 > I have Sendmail + Majordomo setup which works for seven years > excellent. Now I'm trying to update that setup to OpenSMTP with > keeping Majordomo functionality for mail list management. > > What do "the best" software to work with OpenSMTP? Any suggestions > will be helpful. > > Denis > > > I like http://ports.su/mail/mlmmj
Re: acpidump and bsd.rd
No. bsd.rd is for installation. It is not a diagnostic tool. There are other ways to do diagnostics. > does it make sense to add acpidump to bsd.rd ? > I've tried to install snapshot on Dell R640 and installation went well > but booting stops with this error: > http://kosjenka.srce.hr/~hrvoje/zaprocvat/r640-01.jpg > > i also noticed this ahci2 log while booting > http://kosjenka.srce.hr/~hrvoje/zaprocvat/r640-02.jpg > > So I thought to make release and to add acpidump and maybe pcidump in > bsd.rd. Or maybe to collect acpi stuff from linux? > >
acpidump and bsd.rd
Hi all, does it make sense to add acpidump to bsd.rd ? I've tried to install snapshot on Dell R640 and installation went well but booting stops with this error: http://kosjenka.srce.hr/~hrvoje/zaprocvat/r640-01.jpg i also noticed this ahci2 log while booting http://kosjenka.srce.hr/~hrvoje/zaprocvat/r640-02.jpg So I thought to make release and to add acpidump and maybe pcidump in bsd.rd. Or maybe to collect acpi stuff from linux?
OpenSMTPd maillist "compatible" manager Majordomo or what?
I have Sendmail + Majordomo setup which works for seven years excellent. Now I'm trying to update that setup to OpenSMTP with keeping Majordomo functionality for mail list management. What do "the best" software to work with OpenSMTP? Any suggestions will be helpful. Denis
Re: minor too small - pkg_add
> It seems you have to update your snapshot because it's too old. It was > shipped with the lib version 44.8 and the current is now 44.9 from the > output. That mean your snapshot is too old and the packages have been built > against a more recent snapshot. > > Regards Hhmm I guess it's possible that the snapshot was updated at the same time I was installing the last snapshot. I'll try updating again and will report back.
Re: minor too small - pkg_add
Le 2018-03-19 16:18, Patrick Marchand a écrit : Hello, I updated to the latest snapshot yesterday and when I run pkg_add -Dsnap -u a bunch of pkg will not upgrade because it cant find ssl.44.9 It does find 44.8 and 45 but not that specific version, last week I had a similar issue with libm. Now I can get around the error by building the packages in ports, but I was wondering if there was an easy fix. Thanks, Patrick Hello, It seems you have to update your snapshot because it's too old. It was shipped with the lib version 44.8 and the current is now 44.9 from the output. That mean your snapshot is too old and the packages have been built against a more recent snapshot. Regards
minor too small - pkg_add
Hello, I updated to the latest snapshot yesterday and when I run pkg_add -Dsnap -u a bunch of pkg will not upgrade because it cant find ssl.44.9 It does find 44.8 and 45 but not that specific version, last week I had a similar issue with libm. Now I can get around the error by building the packages in ports, but I was wondering if there was an easy fix. Thanks, Patrick
Re: last snapshot points to /pub/OpenBSD/6.3/ instead to /pub/OpenBSD/snapshots/
Hi Peter, thanks for your information. Everything is fine now :) Thanks, Sven On 03/19/18 12:43, Peter N. M. Hansteen wrote: On Mon, Mar 19, 2018 at 12:34:43PM +0100, Sven Wolf wrote: I've updated my system to the latest amd64 snapshot. When I run a system updade from bsd.rd and pkg_add then it points to /pub/OpenBSD/6.3/ instead to /pub/OpenBSD/snapshots/. The problem occurs in my opinion since last friday. Is there something which I can fix on my machine? Or is this an error from kernel? Not the kernel, but the snapshot is close enough to release that this is expected behavior. for a little while now, you will need to prepend -D snap to your other pkg_add options if you're running a snapshot. It's in the pkg_add man page, but easy to miss I guess. - Peter
Re: relayd clients on same network with servers
On 19/03/18 13:51, Mischa wrote: > Hi Giannis, > > From my experience dealing with a lot of load balancers in my time, and also > working for different vendors, the easiest is to use source-nat. > This is just configuration on the relayd itself without making "major" > changes in the rest of the network or servers. Which you would need to do to > when choosing different VLANs or DSR. > > Your concern about source-net and hiding the client IP is valid, but easily > fixed with Client-IP header in http, if http is the protocol, otherwise you > will loose the client IP. ;) > One more thing to remember with source-nat is the maximum amount of > concurrent connections you can handle in a single IP, if that is below 64k > you are fine, otherwise you will have to create a pool of IPs to source-nat > from. > > In my opinion DSR is only relevant for services like FTP and NNTP, where you > have a lot more traffic going out than coming in, so you don't have to put > that burden through the single load balancer interface. > > If you have the ability to change the VLANs that of course the cleanest of > all the option and source-nat the dirtiest, but it's also the simplest. :) > > Good luck! > > Mischa Thanks for the reply Mischa, Well since most of traffic is not http based I cannot use the headers for client IP :-/ This will also be a problem with firewalling on the real servers as well. So that probably leaves out SNAT and relay proxy. I also agree that DSR is not needed. Yes, multiple VLANs is the cleanest solution. My concern is mainly with 1 VLAN and multiple subnets which does the trick of returning the traffic through the LB as well as keeping the setup simple. Another solution would also be some kind of private vlans with openvswitch thanks, Giannis
Re: Ruby On Rails application with httpd
Le 2018-03-19 15:55, Artur Pedziwilk a écrit : On 15 Feb 2018, at 12:03, Wesley MOUEDINE ASSABY wrote: Is there a way to get a 'Ruby on Rails' application running with the embedded OpenBSD httpd(+slowcgi??) ? Why like that? Relayd is perfect for that on OpenBSD IMHO. Do you have an example ? (httpd + relayd) Thank's anyway. /Wesley
Re: Ruby On Rails application with httpd
> On 15 Feb 2018, at 12:03, Wesley MOUEDINE ASSABY > wrote: > > Is there a way to get a 'Ruby on Rails' application running with the embedded > OpenBSD httpd(+slowcgi??) ? Why like that? Relayd is perfect for that on OpenBSD IMHO.
Re: Dual-ISP home router setup problems
And of course, too much copy paste while trying to use documentation IP ranges. The two gateways in pf.conf above should be isp_a_gw = "198.51.100.1" isp_b_gw = "203.0.113.1" The rest stands. On Mon, Mar 19, 2018 at 1:40 PM, Samuel Wagen wrote: > Hello, > > I'm trying to build a home router with OpenBSD. I have two ISPs, both are > giving me real IPs, one with straight DHCP (ISP_A), the other - via PPPoE > (ISP_B). I've described the topology with more detail in the diagram below. > > I wanted to use PF with routing domains instead of multipath forwarding, due > to multipath being very finicky when a link goes down. My current setup is > described below. I have the following issues: > > - Initially I can't pass traffic from the LAN. I think this is due to the > packets on em0 being dropped before PF has a chance to reach them, due > to missing default route on rdomain 0. If I execute the following two > commands: > # route -T 0 add 198.51.100.0/24 127.0.0.1 > # route -T 0 add 203.0.113.0/24 127.0.0.1 > then traffic starts passing half of the time - if the round-robin > decides it should go over the PPPoE link (ISP_B) - traffic from the LAN > flows. If, however, it decides to go through the other link (ISP_A) - > nothing passes, and I get the following kernel messages: > > arpresolve: 198.51.100.0: route contains no arp information > > - Traffic from the gateway itself to the Internet always fails, unless I > specify a routing domain manually (route -T 1 exec whatever). Not sure > what bogus route to add here, so that packets aren't dropped before PF, > and what to add to PF so that they flow. > > In other words, I'm stuck, and need some pointers on how to continue and what > am I doing wrong. I'm running latest snapshot, but also tried with 6.2. > > Many thanks in advance. > > Here's the info about my config, let me know if you need me to provide some > more. The "internet" networks are from RFC5737 for illustration purposes. > > 1. Network diagram > >+-+ +-+ >| ISP_A | | ISP_B | >+---+-+ +---+-+ >| | >| | >| | > ++-+-+++ > || em1 em2/pppoe0 || > || DHCP client real IP || > || IP: 198.51.100.20IP: 203.0.113.40 || > || Net: 198.51.100.0/24 Net: 203.0.113.0/24 || > || GW: 198.51.100.1 GW: 203.0.113.1 || > || rdomain 1rdomain 2|| > G| group isp_a group isp_b |G > A||A > T||T > E+- - - - - - - - - - - NAT- - - - - - - - - - - -+E > W||W > A||A > Y| em0 |Y > || DHCP server || > || IP: 172.16.16.1 || > || Net: 172.16.16.0/24 || > || rdomain 0|| > || group lan|| > +++---++ > | > | > | >+--++ >|LAN| >+---+ > > > 2. Interface config files > > - /etc/hostname.em0 > > inet 172.16.16.1 255.255.255.0 172.16.16.255 group lan > > - /etc/hostname.em1 > > dhcp group isp_a rdomain 1 > > - /etc/hostname.em2 > > up > > - /etc/hostname.pppoe0 > > inet 0.0.0.0 255.255.255.255 NONE \ > pppoedev em2 authproto chap \ > authname 'user' authkey 'verysecret' \ > group isp_b \ > rdomain 2 \ > up > dest 0.0.0.1 > !/sbin/route -T 2 add default -ifp pppoe0 0.0.0.1 > > > 3. DHCP server config (/etc/dhcpd.conf) > > subnet 172.16.16.0 netmask 255.255.255.0 { > option domain-name-servers 172.16.16.2, 172.16.16.3; > option routers 172.16.16.1; > range 172.16.16.100 172.16.16.199; > } > > > 4. PF config > > # Need to figure out how avoid hardcoding these > isp_a_gw = "172.16.18.1" > isp_b_gw = "192.168.68.1" > > set debug debug > > match in log all scrub (no-df random-id max-mss 1440) > > match out log on em1 from (lan:network) nat-to (em1) > match out log on pppoe0 from (lan:network) nat-to (pppoe0) > > pass out log on lan to (lan:network) > pass in log quick on lan from (lan:network) to (lan) > > pass in log on lan from (lan:network) \ > route-to { (em1 $isp_a_gw), (pppoe0 $isp_b_gw) } \ > round-robin > > pass out log on em1 from pppoe0
Re: relayd clients on same network with servers
Hi Giannis, >From my experience dealing with a lot of load balancers in my time, and also >working for different vendors, the easiest is to use source-nat. This is just configuration on the relayd itself without making "major" changes in the rest of the network or servers. Which you would need to do to when choosing different VLANs or DSR. Your concern about source-net and hiding the client IP is valid, but easily fixed with Client-IP header in http, if http is the protocol, otherwise you will loose the client IP. ;) One more thing to remember with source-nat is the maximum amount of concurrent connections you can handle in a single IP, if that is below 64k you are fine, otherwise you will have to create a pool of IPs to source-nat from. In my opinion DSR is only relevant for services like FTP and NNTP, where you have a lot more traffic going out than coming in, so you don't have to put that burden through the single load balancer interface. If you have the ability to change the VLANs that of course the cleanest of all the option and source-nat the dirtiest, but it's also the simplest. :) Good luck! Mischa > On 19 Mar 2018, at 11:20, Kapetanakis Giannis > wrote: > > Hi, > > I'm designing a new setup with relayd and multiple pools. I'm using redirects > with forward. > > The problem I have is that all the real server as in the same VLAN. > In advance the servers in one pool need to access the servers in another > pool, through the load balancer, thus having a problem with replies not > passing through the LB (ie IMAP server accessing LDAP servers) > > I've thought of different solutions for this and I've come up to the > following. I need a second opinion: > > 1) Use different VLAN per pool of servers > 2) 1 VLAN, with 1 bridge and multiple subnets on vether devices > 3) Source NAT to hide client IP > 4) Use a relay as a proxy (instead of redirect on the $int_if) > 5) Use DSR (route-to) with sloppy states > > Solution 1 seems the best to me but it has overhead of adding/managing the > vlans everywhere. > Solution 2 seems to work but I'm not quite sure about it > 3 and 4 hide the client IP so I want to avoid it > 5 also want to avoid, has problems with failover, don't like the half states > > So 2 seems ok, I have basic separation of pools and I guess since I control > all the servers the jumping from one subnet to another is not a serious > security problem. > > appreciate any opinions on this > > Giannis > ps. whole setup with carp-pfsync >
Re: last snapshot points to /pub/OpenBSD/6.3/ instead to /pub/OpenBSD/snapshots/
On Mon, Mar 19, 2018 at 12:34:43PM +0100, Sven Wolf wrote: > I've updated my system to the latest amd64 snapshot. When I run a system > updade from bsd.rd and pkg_add then it points to /pub/OpenBSD/6.3/ instead > to /pub/OpenBSD/snapshots/. > > The problem occurs in my opinion since last friday. Is there something which > I can fix on my machine? Or is this an error from kernel? Not the kernel, but the snapshot is close enough to release that this is expected behavior. for a little while now, you will need to prepend -D snap to your other pkg_add options if you're running a snapshot. It's in the pkg_add man page, but easy to miss I guess. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Dual-ISP home router setup problems
Hello, I'm trying to build a home router with OpenBSD. I have two ISPs, both are giving me real IPs, one with straight DHCP (ISP_A), the other - via PPPoE (ISP_B). I've described the topology with more detail in the diagram below. I wanted to use PF with routing domains instead of multipath forwarding, due to multipath being very finicky when a link goes down. My current setup is described below. I have the following issues: - Initially I can't pass traffic from the LAN. I think this is due to the packets on em0 being dropped before PF has a chance to reach them, due to missing default route on rdomain 0. If I execute the following two commands: # route -T 0 add 198.51.100.0/24 127.0.0.1 # route -T 0 add 203.0.113.0/24 127.0.0.1 then traffic starts passing half of the time - if the round-robin decides it should go over the PPPoE link (ISP_B) - traffic from the LAN flows. If, however, it decides to go through the other link (ISP_A) - nothing passes, and I get the following kernel messages: arpresolve: 198.51.100.0: route contains no arp information - Traffic from the gateway itself to the Internet always fails, unless I specify a routing domain manually (route -T 1 exec whatever). Not sure what bogus route to add here, so that packets aren't dropped before PF, and what to add to PF so that they flow. In other words, I'm stuck, and need some pointers on how to continue and what am I doing wrong. I'm running latest snapshot, but also tried with 6.2. Many thanks in advance. Here's the info about my config, let me know if you need me to provide some more. The "internet" networks are from RFC5737 for illustration purposes. 1. Network diagram +-+ +-+ | ISP_A | | ISP_B | +---+-+ +---+-+ | | | | | | ++-+-+++ || em1 em2/pppoe0 || || DHCP client real IP || || IP: 198.51.100.20IP: 203.0.113.40 || || Net: 198.51.100.0/24 Net: 203.0.113.0/24 || || GW: 198.51.100.1 GW: 203.0.113.1 || || rdomain 1rdomain 2|| G| group isp_a group isp_b |G A||A T||T E+- - - - - - - - - - - NAT- - - - - - - - - - - -+E W||W A||A Y| em0 |Y || DHCP server || || IP: 172.16.16.1 || || Net: 172.16.16.0/24 || || rdomain 0|| || group lan|| +++---++ | | | +--++ |LAN| +---+ 2. Interface config files - /etc/hostname.em0 inet 172.16.16.1 255.255.255.0 172.16.16.255 group lan - /etc/hostname.em1 dhcp group isp_a rdomain 1 - /etc/hostname.em2 up - /etc/hostname.pppoe0 inet 0.0.0.0 255.255.255.255 NONE \ pppoedev em2 authproto chap \ authname 'user' authkey 'verysecret' \ group isp_b \ rdomain 2 \ up dest 0.0.0.1 !/sbin/route -T 2 add default -ifp pppoe0 0.0.0.1 3. DHCP server config (/etc/dhcpd.conf) subnet 172.16.16.0 netmask 255.255.255.0 { option domain-name-servers 172.16.16.2, 172.16.16.3; option routers 172.16.16.1; range 172.16.16.100 172.16.16.199; } 4. PF config # Need to figure out how avoid hardcoding these isp_a_gw = "172.16.18.1" isp_b_gw = "192.168.68.1" set debug debug match in log all scrub (no-df random-id max-mss 1440) match out log on em1 from (lan:network) nat-to (em1) match out log on pppoe0 from (lan:network) nat-to (pppoe0) pass out log on lan to (lan:network) pass in log quick on lan from (lan:network) to (lan) pass in log on lan from (lan:network) \ route-to { (em1 $isp_a_gw), (pppoe0 $isp_b_gw) } \ round-robin pass out log on em1 from pppoe0 route-to (pppoe0 $isp_b_gw) pass out log on pppoe0 from em1 route-to (em1 $isp_a_gw) pass out log quick on em1 inet from (em1) modulate state rtable 1 pass out log quick on pppoe0 from (pppoe0) modulate state rtable 2 5. Additional issues - How to avoid hardcoding the ISP defaut routes? - How to use sticky sessions instead of round-robin? - How to deal with links going down? E.g. not try to send traffic to a failed link. -- sw
last snapshot points to /pub/OpenBSD/6.3/ instead to /pub/OpenBSD/snapshots/
Hi, I've updated my system to the latest amd64 snapshot. When I run a system updade from bsd.rd and pkg_add then it points to /pub/OpenBSD/6.3/ instead to /pub/OpenBSD/snapshots/. The problem occurs in my opinion since last friday. Is there something which I can fix on my machine? Or is this an error from kernel? When I installed the snapshot from 2018-03-10 (about a week ago) everything worked as expected. Here are the kernel informations from dmesg: OpenBSD 6.3 (GENERIC.MP) #68: Fri Mar 16 01:24:47 MDT 2018 OpenBSD 6.3 (RAMDISK_CD) #64: Sun Mar 18 15:14:26 MDT 2018 OpenBSD 6.3 (GENERIC.MP) #72: Sun Mar 18 15:09:43 MDT 2018 I've tested the upgrade via bsd.rd and also via install63.fs. Thanks and best regards, Sven
Re: stop syslogd from opening port 514 UDP
> it is your test methodology that is broken Well, I said "I want the machine to be invisible", so I don't think there is anything wrong with me testing which ports are open and checking what I can do (besides pf) to close them. Anyway, thanks for your help! Cheers!
Re: httpd / acme-client confusion
On 2018-03-19, Markus Rosjat wrote: > Hi, > >> acme-client can only validate an authorization that way. >> >> but for a forced renewal for something that's already active, there's >> likely to already be a validated authorization on the letsencrypt account, >> in which case it wouldn't need to revalidate. >> > > I did a forced renew after I got a valid certificate and stoped the > httpd before I did the forced renew If you need to force a renewal it means the certificate isn't that old in the first place and very likely to be in the window in which you already have a valid authorization. > I will do the suggested changes to the config and keep an eye on it. Just place a file in the .well-known/acme-challenge directory and make sure you can fetch it. Then you don't have to wait for a possible failure sometime in the future when you're not thinking about it.
Re: Installing a snapshot to a USB key using bsd.rd
It turns out that the snapshot on Aarnet failed to match its checksum for a blindingly obvious reason. It was corrupt. I installed a snapshot from another mirror, started X, and crashed the kernel. I'll try to post the details to bugs@ in a day or two, but some hand holding would be appreciated. Thanks everyone Rodney
relayd clients on same network with servers
Hi, I'm designing a new setup with relayd and multiple pools. I'm using redirects with forward. The problem I have is that all the real server as in the same VLAN. In advance the servers in one pool need to access the servers in another pool, through the load balancer, thus having a problem with replies not passing through the LB (ie IMAP server accessing LDAP servers) I've thought of different solutions for this and I've come up to the following. I need a second opinion: 1) Use different VLAN per pool of servers 2) 1 VLAN, with 1 bridge and multiple subnets on vether devices 3) Source NAT to hide client IP 4) Use a relay as a proxy (instead of redirect on the $int_if) 5) Use DSR (route-to) with sloppy states Solution 1 seems the best to me but it has overhead of adding/managing the vlans everywhere. Solution 2 seems to work but I'm not quite sure about it 3 and 4 hide the client IP so I want to avoid it 5 also want to avoid, has problems with failover, don't like the half states So 2 seems ok, I have basic separation of pools and I guess since I control all the servers the jumping from one subnet to another is not a serious security problem. appreciate any opinions on this Giannis ps. whole setup with carp-pfsync
Re: httpd / acme-client confusion
Hi, acme-client can only validate an authorization that way. but for a forced renewal for something that's already active, there's likely to already be a validated authorization on the letsencrypt account, in which case it wouldn't need to revalidate. I did a forced renew after I got a valid certificate and stoped the httpd before I did the forced renew if you really stopped httpd and there is still something listening then there is another webserver process running. You can check locally with netstat(1) or 'ps -aux' there was no other process running since I checked that before I did the forced renew. I will do the suggested changes to the config and keep an eye on it. My main problem was with the block statement the other thing I just noticed as I did testing with the config and started forcing the renew of the certificate regards -- Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de G+H Webservice GbR Gorzolla, Herrmann Königsbrücker Str. 70, 01099 Dresden http://www.ghweb.de fon: +49 351 8107220 fax: +49 351 8107227 Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you print it, think about your responsibility and commitment to the ENVIRONMENT
Re: stop syslogd from opening port 514 UDP
2018-03-19 8:07 GMT+01:00 Torsten : > >> On my OpenBSD 6.2 syslogd is listening to port 514 > >> [...] > >> prevent syslogd from opening that port in the first place? > > > If [...] no logging rules exist to send to a remote > > host the socket is closed per default since 6.2. Perhaps you are logging > > to a remote host? > > Thank you for you answer, indeed I am logging to a remote host. However, > I don't understand why logging to a remote host opens port 514 incoming. > > Because that is how UDP works. The code will not collect anything incoming to that port, but it will still look like it's "listening" because its open, and its open so that syslog can send on it. > Anyway, I understand you're saying that this is intended behaviour and > cannot be circumvented other than using pf, right? > > Well, given how it actually works, it is your test methodology that is broken (ie assuming an open port means someone will read and act on the data and that this in turn means you are in trouble) so "circumventing" a faulty assumption is hard to give a decent answer to. Sure, you should PF all ports that you don't want to receive packets on so that is still valid for UDP on port 514 and 512 and 30044, but you don't have to do it in order for syslog to not fill up your harddrive with spoofed log lines which you already concluded, so PF is always good, and it is also a solution to the non-problem you already knew you had. Other syslog daemons may be worse in this regard and reading guidelines about them might lead you to think that you also must do X,Y and Z for this particular daemon, but that is not so. You might actually be able to find previous discussions on misc/tech about it, since it comes up now and then. -- May the most significant bit of your life be positive.
Re: the Alpha lives...
I know you're all on the edge of your seat for the next episode in this saga .. so here goes. `make build` failed during the night (after 431 minutes build time) while running configure for nsd. Here's the failing test: checking size of off_t... pid 87911 (conftest): unaligned access: va=0xdfdfdfdfdfdfdfef pc=0xbd7b2fe0 ra=0xbd7b3380 op=ldq configure: error: in `/usr/src/usr.sbin/nsd/obj': configure: error: cannot compute sizeof (off_t) See `config.log' for more details *** Error 77 in usr.sbin/nsd (Makefile.bsd-wrapper:53 'config.status') *** Error 1 in usr.sbin (:48 'all') *** Error 1 in . (:48 'all') *** Error 1 in . (Makefile:95 'do-build') *** Error 1 in /usr/src (Makefile:74 'build') However, there was one other issue like that just before it (also while configuring nsd): checking whether the C compiler (cc) accepts the "format" attribute... yes checking whether the C compiler (cc) accepts the "unused" attribute... yes checking if memcmp compares unsigned... pid 27732 (conftest): unaligned access: va=0xdfdfdfdfdfdfdfef pc=0x9de96fe0 ra=0x9de97380 op=ldq no checking whether ctime_r works with two arguments... yes checking for libevent... found in /usr Already talking to Florian (CC:'d) about this issue. Paul 'WEiRD' de Weerd On Sun, Mar 18, 2018 at 07:47:30PM +0100, Paul de Weerd wrote: | Building a -current kernel took over an hour (I forgot to time it), | but it worked! I'm now going to build a release, but that's going to | take several hours, if the kernel build time is any indication... | | So here's the 6.3 dmesg (with some extra SCSI devices thrown into the | mix, for fun): | | [ using 1147568 bytes of bsd ELF symbol table ] | consinit: not using prom console | Copyright (c) 1982, 1986, 1989, 1991, 1993 | The Regents of the University of California. All rights reserved. | Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org | | OpenBSD 6.3 (GENERIC) #0: Sun Mar 18 18:48:27 CET 2018 | we...@alfalfa.alm.weirdnet.nl:/usr/src/sys/arch/alpha/compile/GENERIC | Digital Personal WorkStation 600au, 598MHz | 8192 byte page size, 1 processor. | real mem = 536870912 (512MB) | rsvd mem = 1941504 (1MB) | avail mem = 515710976 (491MB) | mainbus0 at root | cpu0 at mainbus0: ID 0 (primary), 21164A-0 (unknown minor type 0) | cpu0: architecture extensions: 1 | cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 1 | cia0: extended capabilities: 1 | cia0: using BWX for PCI config and bus access | cia0: WARNING: Pyxis pass 1 DMA bug; no bets... | pci0 at cia0 bus 0 | dc0 at pci0 dev 3 function 0 "DEC 21142/3" rev 0x30: dec 550 irq 0, address 00:00:f8:76:04:64 | nsphy0 at dc0 phy 5: DP83840 10/100 PHY, rev. 1 | pciide0 at pci0 dev 4 function 0 "CMD Technology PCI0646" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility | atapiscsi0 at pciide0 channel 0 drive 0 | scsibus0 at atapiscsi0: 2 targets | cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable | cd0(pciide0:0:0): using PIO mode 3, DMA mode 1 | pciide0: channel 1 disabled (no drives) | sio0 at pci0 dev 7 function 0 "Intel 82378IB ISA" rev 0x43 | qlw0 at pci0 dev 12 function 0 "QLogic ISP1020" rev 0x05: dec 550 irq 8 | qlw0: firmware rev 4.66.0, attrs 0x0 | scsibus1 at qlw0: 16 targets, initiator 7 | cd1 at scsibus1 targ 0 lun 0: SCSI2 5/cdrom removable | cd2 at scsibus1 targ 1 lun 0: SCSI2 5/cdrom removable | cd3 at scsibus1 targ 2 lun 0: SCSI2 5/cdrom removable | cd4 at scsibus1 targ 3 lun 0: SCSI2 5/cdrom removable | cd5 at scsibus1 targ 4 lun 0: SCSI2 5/cdrom removable | sd0 at scsibus1 targ 5 lun 0: SCSI2 0/direct removable | sd0: 96MB, 512 bytes/sector, 196608 sectors | st0 at scsibus1 targ 6 lun 0: SCSI2 1/sequential removable | sd1 at scsibus1 targ 8 lun 0: SCSI2 0/direct fixed serial.SEAGATE_ST34371W_JDD273270M5E3P | sd1: 4148MB, 512 bytes/sector, 8496884 sectors | sd2 at scsibus1 targ 9 lun 0: SCSI2 0/direct fixed serial.I
Re: stop syslogd from opening port 514 UDP
>> On my OpenBSD 6.2 syslogd is listening to port 514 >> [...] >> prevent syslogd from opening that port in the first place? > If [...] no logging rules exist to send to a remote > host the socket is closed per default since 6.2. Perhaps you are logging > to a remote host? Thank you for you answer, indeed I am logging to a remote host. However, I don't understand why logging to a remote host opens port 514 incoming. Anyway, I understand you're saying that this is intended behaviour and cannot be circumvented other than using pf, right?