Re: how to , apache's ' AuthType Basic '
Tuyosi Takesima nakajin.fu...@gmail.com wrote: hi ,all . in arch linux , apache's 'AuthType Basic' is easy . i follow http://www.atmarkit.co.jp/flinux/rensai/linuxtips/698apachebasic.html as a whole. detail is a little different . the following . # ls -l /srv/http/ -rw-r--r-- 1 root root 28 12??? 10 12:03 index.html drwxr-xr-x 2 root root 4096 12??? 10 13:09 member # head /etc/httpd/conf/httpd.conf Directory /srv/http/member AuthType Basic AuthName Secret Zone AuthUserFile /etc/httpd/.htpasswd Require user secret /Directory htpasswd -c /etc/httpd/.htpasswd secret but openbsd's apache is defferent . this method is out . there is little iformation on iternet about openbsd's 'AuthType Basic' . what should i do ? the newest is not best . the best is best . You have not adequately explained your problem, but I will try to answer. First I will note that you want to look for material in English. I cannot verify this first-hand, because I do not understand Japanese writings, but I feel that there is not going to be much on OpenBSD in Japanese. There is no official Japanese documentation. The project originates from an English-speaking part of the world, and there is simply not enough manpower to keep international documentation up to date. The best documentation is the manuals that come with the system and the FAQ on http://www.openbsd.org/faq/. This is the only official documentation. It is always kept up to date, unlike the tutorials you may find elsewhere. As for the immediate question, OpenBSD base had a fork of Apache 1.x prior to 5.6. This was removed in 5.6 and is no longer available. In 5.6 the Apache 1.x httpd was replaced with a OpenBSD-specific httpd. OpenBSD base also contains nginx. It is also possible to install Apache 2.x on OpenBSD from ports. OpenBSD httpd does not support authentication. So that will not work for you. Your options are to learn to configure nginx or to install Apache 2.x and configure it. If you install Apache 2.x it will work just like any other installation of Apache. -- Martin
Re: OpenBSD 5.6 - amd64 on Lenovo G480
On 15.12.2014 04:46, Leonardo Santagostini wrote: Hello bodie, Tried snapshot with same results. Mmm I have similar crap at home. Lenovo G580 model 20150. I would be surprised if anything behind Windows and Linux (with a lot of complications as I found) will be running properly here. One of those - hey we propagate this inside, but in fact there's this inside secretely hidden :-) --- dmesg --- Dec 14 20:14:41 notleo syslogd: start Dec 14 20:14:41 notleo /bsd: OpenBSD 5.6-current (RAMDISK_CD) #631: Sun Dec 14 10:45:08 MST 2014 Dec 14 20:14:41 notleo /bsd: dera...@amd64.openbsd.org: /usr/src/sys/arch/amd64/compile/RAMDISK_CD Dec 14 20:14:41 notleo /bsd: RTC BIOS diagnostic error 80clock_battery Dec 14 20:14:41 notleo /bsd: real mem = 4138713088 (3946MB) Dec 14 20:14:41 notleo /bsd: avail mem = 4026851328 (3840MB) Dec 14 20:14:41 notleo /bsd: mainbus0 at root Dec 14 20:14:41 notleo /bsd: bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6fd0 (59 entries) Dec 14 20:14:41 notleo /bsd: bios0: vendor LENOVO version 5ECN95WW(V9.00) date 12/19/2012 Dec 14 20:14:41 notleo /bsd: bios0: LENOVO 20150 Dec 14 20:14:41 notleo /bsd: acpi0 at bios0: rev 2 Dec 14 20:14:41 notleo /bsd: acpi0: sleep states S0 S3 S4 S5 Dec 14 20:14:41 notleo /bsd: acpi0: tables DSDT FACP SLIC UEFI ASF! HPET APIC MCFG SSDT BOOT ASPT DBGP FPDT MSDM SSDT SSDT Dec 14 20:14:41 notleo /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat Dec 14 20:14:41 notleo /bsd: cpu0 at mainbus0: apid 0 (boot processor) Dec 14 20:14:41 notleo /bsd: cpu0: Intel(R) Pentium(R) CPU B980 @ 2.40GHz, 2394.92 MHz Dec 14 20:14:41 notleo /bsd: 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC Dec 14 20:14:41 notleo /bsd: cpu0: 256KB 64b/line 8-way L2 cache Dec 14 20:14:41 notleo /bsd: cpu0: apic clock running at 99MHz Dec 14 20:14:41 notleo /bsd: cpu at mainbus0: not configured Dec 14 20:14:41 notleo /bsd: ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins Dec 14 20:14:41 notleo /bsd: acpiprt0 at acpi0: bus 0 (PCI0) Dec 14 20:14:41 notleo /bsd: acpiprt1 at acpi0: bus -1 (P0P1) Dec 14 20:14:41 notleo /bsd: acpiprt2 at acpi0: bus 1 (RP01) Dec 14 20:14:41 notleo /bsd: acpiprt3 at acpi0: bus 2 (RP02) Dec 14 20:14:41 notleo /bsd: acpiprt4 at acpi0: bus -1 (RP03) Dec 14 20:14:41 notleo /bsd: acpiprt5 at acpi0: bus -1 (RP04) Dec 14 20:14:41 notleo /bsd: acpiprt6 at acpi0: bus -1 (RP05) Dec 14 20:14:41 notleo /bsd: acpiprt7 at acpi0: bus -1 (RP06) Dec 14 20:14:41 notleo /bsd: acpiprt8 at acpi0: bus -1 (RP07) Dec 14 20:14:41 notleo /bsd: acpiprt9 at acpi0: bus -1 (RP08) Dec 14 20:14:41 notleo /bsd: acpiprt10 at acpi0: bus -1 (PEG0) Dec 14 20:14:42 notleo /bsd: acpiprt11 at acpi0: bus -1 (PEG1) Dec 14 20:14:43 notleo /bsd: acpiprt12 at acpi0: bus -1 (PEG2) Dec 14 20:14:43 notleo /bsd: acpiprt13 at acpi0: bus -1 (PEG3) Dec 14 20:14:43 notleo /bsd: pci0 at mainbus0 bus 0 Dec 14 20:14:43 notleo /bsd: pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09 Dec 14 20:14:43 notleo /bsd: vga1 at pci0 dev 2 function 0 Intel HD Graphics 2000 rev 0x09 Dec 14 20:14:43 notleo /bsd: wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) Dec 14 20:14:43 notleo /bsd: xhci0 at pci0 dev 20 function 0 Intel 7 Series xHCI rev 0x04: msi Dec 14 20:14:43 notleo /bsd: usb0 at xhci0: USB revision 3.0 Dec 14 20:14:43 notleo /bsd: uhub0 at usb0 Intel xHCI root hub rev 3.00/1.00 addr 1 Dec 14 20:14:43 notleo /bsd: Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured Dec 14 20:14:43 notleo /bsd: ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 0 int 16 Dec 14 20:14:43 notleo /bsd: ehci0: timed out waiting for BIOS Dec 14 20:14:43 notleo /bsd: usb1 at ehci0: USB revision 2.0 Dec 14 20:14:43 notleo /bsd: uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 Dec 14 20:14:43 notleo /bsd: Intel 7 Series HD Audio rev 0x04 at pci0 dev 27 function 0 not configured Dec 14 20:14:43 notleo /bsd: ppb0 at pci0 dev 28 function 0 Intel 7 Series PCIE rev 0xc4: msi Dec 14 20:14:43 notleo /bsd: pci1 at ppb0 bus 1 Dec 14 20:14:43 notleo /bsd: Attansic Technology AR8162 rev 0x10 at pci1 dev 0 function 0 not configured Dec 14 20:14:43 notleo /bsd: ppb1 at pci0 dev 28 function 1 Intel 7 Series PCIE rev 0xc4: msi Dec 14 20:14:44 notleo /bsd: pci2 at ppb1 bus 2 Dec 14 20:14:44 notleo /bsd: Atheros AR9485 rev 0x01 at pci2 dev 0 function 0 not configured Dec 14 20:14:44 notleo /bsd: ehci1 at pci0 dev 29 function 0 Intel 7 Series USB rev 0x04: apic 0 int 23 Dec 14 20:14:44 notleo /bsd: ehci1: timed out waiting for BIOS Dec 14 20:14:44 notleo /bsd: usb2 at ehci1: USB revision 2.0 Dec 14 20:14:44 notleo /bsd: uhub2 at usb2 Intel EHCI root hub rev 2.00/1.00 addr 1 Dec 14 20:14:44 notleo /bsd: Intel HM76 LPC rev 0x04 at pci0 dev 31 function 0
Re: OpenBSD 5.6 - amd64 on Lenovo G480
I don't have this particular Lenovo, but the three that I do have, a W530, a B590, and a V470 all work fine with either OpenSUSE, Ubuntu, or Fedora. On Mon, 15 Dec 2014, bodie wrote: On 15.12.2014 04:46, Leonardo Santagostini wrote: Hello bodie, Tried snapshot with same results. Mmm I have similar crap at home. Lenovo G580 model 20150. I would be surprised if anything behind Windows and Linux (with a lot of complications as I found) will be running properly here. One of those - hey we propagate this inside, but in fact there's this inside secretely hidden :-) --- dmesg --- Dec 14 20:14:41 notleo syslogd: start Dec 14 20:14:41 notleo /bsd: OpenBSD 5.6-current (RAMDISK_CD) #631: Sun Dec 14 10:45:08 MST 2014 Dec 14 20:14:41 notleo /bsd: dera...@amd64.openbsd.org: /usr/src/sys/arch/amd64/compile/RAMDISK_CD Dec 14 20:14:41 notleo /bsd: RTC BIOS diagnostic error 80clock_battery Dec 14 20:14:41 notleo /bsd: real mem = 4138713088 (3946MB) Dec 14 20:14:41 notleo /bsd: avail mem = 4026851328 (3840MB) Dec 14 20:14:41 notleo /bsd: mainbus0 at root Dec 14 20:14:41 notleo /bsd: bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6fd0 (59 entries) Dec 14 20:14:41 notleo /bsd: bios0: vendor LENOVO version 5ECN95WW(V9.00) date 12/19/2012 Dec 14 20:14:41 notleo /bsd: bios0: LENOVO 20150 Dec 14 20:14:41 notleo /bsd: acpi0 at bios0: rev 2 Dec 14 20:14:41 notleo /bsd: acpi0: sleep states S0 S3 S4 S5 Dec 14 20:14:41 notleo /bsd: acpi0: tables DSDT FACP SLIC UEFI ASF! HPET APIC MCFG SSDT BOOT ASPT DBGP FPDT MSDM SSDT SSDT Dec 14 20:14:41 notleo /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat Dec 14 20:14:41 notleo /bsd: cpu0 at mainbus0: apid 0 (boot processor) Dec 14 20:14:41 notleo /bsd: cpu0: Intel(R) Pentium(R) CPU B980 @ 2.40GHz, 2394.92 MHz Dec 14 20:14:41 notleo /bsd: 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC Dec 14 20:14:41 notleo /bsd: cpu0: 256KB 64b/line 8-way L2 cache Dec 14 20:14:41 notleo /bsd: cpu0: apic clock running at 99MHz Dec 14 20:14:41 notleo /bsd: cpu at mainbus0: not configured Dec 14 20:14:41 notleo /bsd: ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins Dec 14 20:14:41 notleo /bsd: acpiprt0 at acpi0: bus 0 (PCI0) Dec 14 20:14:41 notleo /bsd: acpiprt1 at acpi0: bus -1 (P0P1) Dec 14 20:14:41 notleo /bsd: acpiprt2 at acpi0: bus 1 (RP01) Dec 14 20:14:41 notleo /bsd: acpiprt3 at acpi0: bus 2 (RP02) Dec 14 20:14:41 notleo /bsd: acpiprt4 at acpi0: bus -1 (RP03) Dec 14 20:14:41 notleo /bsd: acpiprt5 at acpi0: bus -1 (RP04) Dec 14 20:14:41 notleo /bsd: acpiprt6 at acpi0: bus -1 (RP05) Dec 14 20:14:41 notleo /bsd: acpiprt7 at acpi0: bus -1 (RP06) Dec 14 20:14:41 notleo /bsd: acpiprt8 at acpi0: bus -1 (RP07) Dec 14 20:14:41 notleo /bsd: acpiprt9 at acpi0: bus -1 (RP08) Dec 14 20:14:41 notleo /bsd: acpiprt10 at acpi0: bus -1 (PEG0) Dec 14 20:14:42 notleo /bsd: acpiprt11 at acpi0: bus -1 (PEG1) Dec 14 20:14:43 notleo /bsd: acpiprt12 at acpi0: bus -1 (PEG2) Dec 14 20:14:43 notleo /bsd: acpiprt13 at acpi0: bus -1 (PEG3) Dec 14 20:14:43 notleo /bsd: pci0 at mainbus0 bus 0 Dec 14 20:14:43 notleo /bsd: pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09 Dec 14 20:14:43 notleo /bsd: vga1 at pci0 dev 2 function 0 Intel HD Graphics 2000 rev 0x09 Dec 14 20:14:43 notleo /bsd: wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) Dec 14 20:14:43 notleo /bsd: xhci0 at pci0 dev 20 function 0 Intel 7 Series xHCI rev 0x04: msi Dec 14 20:14:43 notleo /bsd: usb0 at xhci0: USB revision 3.0 Dec 14 20:14:43 notleo /bsd: uhub0 at usb0 Intel xHCI root hub rev 3.00/1.00 addr 1 Dec 14 20:14:43 notleo /bsd: Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured Dec 14 20:14:43 notleo /bsd: ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 0 int 16 Dec 14 20:14:43 notleo /bsd: ehci0: timed out waiting for BIOS Dec 14 20:14:43 notleo /bsd: usb1 at ehci0: USB revision 2.0 Dec 14 20:14:43 notleo /bsd: uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 Dec 14 20:14:43 notleo /bsd: Intel 7 Series HD Audio rev 0x04 at pci0 dev 27 function 0 not configured Dec 14 20:14:43 notleo /bsd: ppb0 at pci0 dev 28 function 0 Intel 7 Series PCIE rev 0xc4: msi Dec 14 20:14:43 notleo /bsd: pci1 at ppb0 bus 1 Dec 14 20:14:43 notleo /bsd: Attansic Technology AR8162 rev 0x10 at pci1 dev 0 function 0 not configured Dec 14 20:14:43 notleo /bsd: ppb1 at pci0 dev 28 function 1 Intel 7 Series PCIE rev 0xc4: msi Dec 14 20:14:44 notleo /bsd: pci2 at ppb1 bus 2 Dec 14 20:14:44 notleo /bsd: Atheros AR9485 rev 0x01 at pci2 dev 0 function 0 not configured Dec 14 20:14:44 notleo /bsd: ehci1 at pci0 dev 29 function 0 Intel 7
Re: OpenBSD 5.6 - amd64 on Lenovo G480
Yup, il install 5.5 again and will wait to 5.7 maybe will work in 5.7 Regards and thanks! Saludos.- Leonardo Santagostini http://ar.linkedin.com/in/santagostini 2014-12-15 2:10 GMT-03:00 bodie bodz...@openbsd.cz: On 15.12.2014 04:46, Leonardo Santagostini wrote: Hello bodie, Tried snapshot with same results. Mmm I have similar crap at home. Lenovo G580 model 20150. I would be surprised if anything behind Windows and Linux (with a lot of complications as I found) will be running properly here. One of those - hey we propagate this inside, but in fact there's this inside secretely hidden :-) --- dmesg --- Dec 14 20:14:41 notleo syslogd: start Dec 14 20:14:41 notleo /bsd: OpenBSD 5.6-current (RAMDISK_CD) #631: Sun Dec 14 10:45:08 MST 2014 Dec 14 20:14:41 notleo /bsd: dera...@amd64.openbsd.org: /usr/src/sys/arch/amd64/compile/RAMDISK_CD Dec 14 20:14:41 notleo /bsd: RTC BIOS diagnostic error 80clock_battery Dec 14 20:14:41 notleo /bsd: real mem = 4138713088 (3946MB) Dec 14 20:14:41 notleo /bsd: avail mem = 4026851328 (3840MB) Dec 14 20:14:41 notleo /bsd: mainbus0 at root Dec 14 20:14:41 notleo /bsd: bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6fd0 (59 entries) Dec 14 20:14:41 notleo /bsd: bios0: vendor LENOVO version 5ECN95WW(V9.00) date 12/19/2012 Dec 14 20:14:41 notleo /bsd: bios0: LENOVO 20150 Dec 14 20:14:41 notleo /bsd: acpi0 at bios0: rev 2 Dec 14 20:14:41 notleo /bsd: acpi0: sleep states S0 S3 S4 S5 Dec 14 20:14:41 notleo /bsd: acpi0: tables DSDT FACP SLIC UEFI ASF! HPET APIC MCFG SSDT BOOT ASPT DBGP FPDT MSDM SSDT SSDT Dec 14 20:14:41 notleo /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat Dec 14 20:14:41 notleo /bsd: cpu0 at mainbus0: apid 0 (boot processor) Dec 14 20:14:41 notleo /bsd: cpu0: Intel(R) Pentium(R) CPU B980 @ 2.40GHz, 2394.92 MHz Dec 14 20:14:41 notleo /bsd: 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,EST,TM2,SSSE3,CX16, xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE, NXE,LONG,LAHF,PERF,ITSC Dec 14 20:14:41 notleo /bsd: cpu0: 256KB 64b/line 8-way L2 cache Dec 14 20:14:41 notleo /bsd: cpu0: apic clock running at 99MHz Dec 14 20:14:41 notleo /bsd: cpu at mainbus0: not configured Dec 14 20:14:41 notleo /bsd: ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins Dec 14 20:14:41 notleo /bsd: acpiprt0 at acpi0: bus 0 (PCI0) Dec 14 20:14:41 notleo /bsd: acpiprt1 at acpi0: bus -1 (P0P1) Dec 14 20:14:41 notleo /bsd: acpiprt2 at acpi0: bus 1 (RP01) Dec 14 20:14:41 notleo /bsd: acpiprt3 at acpi0: bus 2 (RP02) Dec 14 20:14:41 notleo /bsd: acpiprt4 at acpi0: bus -1 (RP03) Dec 14 20:14:41 notleo /bsd: acpiprt5 at acpi0: bus -1 (RP04) Dec 14 20:14:41 notleo /bsd: acpiprt6 at acpi0: bus -1 (RP05) Dec 14 20:14:41 notleo /bsd: acpiprt7 at acpi0: bus -1 (RP06) Dec 14 20:14:41 notleo /bsd: acpiprt8 at acpi0: bus -1 (RP07) Dec 14 20:14:41 notleo /bsd: acpiprt9 at acpi0: bus -1 (RP08) Dec 14 20:14:41 notleo /bsd: acpiprt10 at acpi0: bus -1 (PEG0) Dec 14 20:14:42 notleo /bsd: acpiprt11 at acpi0: bus -1 (PEG1) Dec 14 20:14:43 notleo /bsd: acpiprt12 at acpi0: bus -1 (PEG2) Dec 14 20:14:43 notleo /bsd: acpiprt13 at acpi0: bus -1 (PEG3) Dec 14 20:14:43 notleo /bsd: pci0 at mainbus0 bus 0 Dec 14 20:14:43 notleo /bsd: pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09 Dec 14 20:14:43 notleo /bsd: vga1 at pci0 dev 2 function 0 Intel HD Graphics 2000 rev 0x09 Dec 14 20:14:43 notleo /bsd: wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) Dec 14 20:14:43 notleo /bsd: xhci0 at pci0 dev 20 function 0 Intel 7 Series xHCI rev 0x04: msi Dec 14 20:14:43 notleo /bsd: usb0 at xhci0: USB revision 3.0 Dec 14 20:14:43 notleo /bsd: uhub0 at usb0 Intel xHCI root hub rev 3.00/1.00 addr 1 Dec 14 20:14:43 notleo /bsd: Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured Dec 14 20:14:43 notleo /bsd: ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 0 int 16 Dec 14 20:14:43 notleo /bsd: ehci0: timed out waiting for BIOS Dec 14 20:14:43 notleo /bsd: usb1 at ehci0: USB revision 2.0 Dec 14 20:14:43 notleo /bsd: uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 Dec 14 20:14:43 notleo /bsd: Intel 7 Series HD Audio rev 0x04 at pci0 dev 27 function 0 not configured Dec 14 20:14:43 notleo /bsd: ppb0 at pci0 dev 28 function 0 Intel 7 Series PCIE rev 0xc4: msi Dec 14 20:14:43 notleo /bsd: pci1 at ppb0 bus 1 Dec 14 20:14:43 notleo /bsd: Attansic Technology AR8162 rev 0x10 at pci1 dev 0 function 0 not configured Dec 14 20:14:43 notleo /bsd: ppb1 at pci0 dev 28 function 1 Intel 7 Series PCIE rev 0xc4: msi Dec 14 20:14:44 notleo /bsd: pci2 at ppb1 bus 2 Dec 14 20:14:44 notleo /bsd: Atheros AR9485 rev 0x01 at pci2 dev 0 function 0 not configured Dec 14 20:14:44 notleo /bsd: ehci1 at pci0 dev 29 function 0 Intel 7 Series USB rev 0x04: apic 0 int 23 Dec
Problem With Default Route Over IPSEC Site-To-Site Tunnel VPN
Hello,
I am having a problem with a particular aspect of my attempt to establish
an IPSEC site-to-site tunnel between two gateways using ISAKMPD/IKEv1. I
seem to be doing something wrong, but I have exhausted all of the resources
that I know of in my quest to fix the problem (MAN pages, OpenBSD.org FAQ,
Google, etc). I am hoping that someone with more OpenBSD experience than
myself will be able to help me... either way, thanks so much for your time!
The routers in question both run OpenBSD 5.6, situated at either end of
long range wifi bridge link. Router 1 also has a interface connecting to
an ISP router, which provides a route to the Internet:
Internet == Router 1
172.16.5.1
||
Wifi
||
172.16.5.2
Router 2 == Local Networks
(172.16.6.1/24, 172.16.7.1/24)
The intention is to establish an IPSEC tunnel between Router 1 and Router
2, over which Router 2 should send all traffic not destined for one of it's
local networks. Accordingly, I set the default route of Router 2 to
172.16.5.1, and I configured the tunnel like so:
## Router 1
ike passive esp \
from any to { 172.16.5.2/32, 172.16.6.0/24, 172.16.7.0/24 } \
local 172.16.5.1 peer 172.16.5.2 \
main auth hmac-sha2-512 enc aes-256 group modp2048 \
quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \
srcid SNIP: Router 1 \
dstid SNIP: Router 2
## Router 2
ike active esp \
from { 172.16.5.2/32, 172.16.6.0/24, 172.16.7.0/24 } to any \
local 172.16.5.2 peer 172.16.5.1 \
main auth hmac-sha2-512 enc aes-256 group modp2048 \
quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \
srcid SNIP: Router 2 \
dstid SNIP: Router 1
This configuration (correctly) causes six SAs to be established:
## Router 1
# ipsecctl -sa
FLOWS:
flow esp in from 172.16.5.2 to 0.0.0.0/0 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type use
flow esp out from 0.0.0.0/0 to 172.16.5.2 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type require
flow esp in from 172.16.7.0/24 to 0.0.0.0/0 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type use
flow esp out from 0.0.0.0/0 to 172.16.7.0/24 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type require
flow esp in from 172.16.6.0/24 to 0.0.0.0/0 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type use
flow esp out from 0.0.0.0/0 to 172.16.6.0/24 peer 172.16.5.2 srcid SNIP:
Router 1 dstid SNIP: Router 2 type require
SAD:
esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x0eec4a02 auth hmac-sha2-512
enc aes-256-ctr
esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0x1cde0906 auth hmac-sha2-512
enc aes-256-ctr
esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x6769c99e auth hmac-sha2-512
enc aes-256-ctr
esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0xad29e69c auth hmac-sha2-512
enc aes-256-ctr
esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xaf8c3502 auth hmac-sha2-512
enc aes-256-ctr
esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xcdad877e auth hmac-sha2-512
enc aes-256-ctr
## Router 2
# ipsecctl -sa
FLOWS:
flow esp in from 0.0.0.0/0 to 172.16.5.2 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type use
flow esp out from 172.16.5.2 to 0.0.0.0/0 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type require
flow esp in from 0.0.0.0/0 to 172.16.7.0/24 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type use
flow esp out from 172.16.7.0/24 to 0.0.0.0/0 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type require
flow esp in from 0.0.0.0/0 to 172.16.6.0/24 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type use
flow esp out from 172.16.6.0/24 to 0.0.0.0/0 peer 172.16.5.1 srcid SNIP:
Router 2 dstid SNIP: Router 1 type require
SAD:
esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x0eec4a02 auth hmac-sha2-512
enc aes-256-ctr
esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0x1cde0906 auth hmac-sha2-512
enc aes-256-ctr
esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x6769c99e auth hmac-sha2-512
enc aes-256-ctr
esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0xad29e69c auth hmac-sha2-512
enc aes-256-ctr
esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xaf8c3502 auth hmac-sha2-512
enc aes-256-ctr
esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xcdad877e auth hmac-sha2-512
enc aes-256-ctr
The problem is that as soon as these flows are established, Router 2
becomes unreachable from all of it's local networks (and vice-versa). This
appears to occur because the flows specify that all traffic originating
from Router 2's IP addresses (172.16.5.2, 172.16.6.1, and 172.16.7.1)
should be protected with ESP. Thus, Router 2 starts to encapsulate all
traffic originating from it's IPs, even if it is destined for one of it's
local networks. Normally this wouldn't happen because the local networks
wouldn't be included in the networks of the other side of the tunnel.
For
Re: poor-man's sandbox (for web browser security, etc.)
In message http://marc.info/?l=openbsd-miscm=141848398918562w=1, Joel Rees wrote: I've used sudo to make a poor-man's sandbox in the past, like this: http://reiisi.blogspot.jp/2011/08/simple-sandbox-for-firefox.html Trying this on openbsd seems to work [[...]] It seems to run firefox just fine: sudo -H -u hexed-me firefox [[...]] I would appreciate any critiques or out-right criticisms of this. Is it worth the trouble? Does it perhaps open up new vulnerabilities instead? This is better than nothing, but it still gives the firefox process unlimited access to the X protocol and (through the X protocol) the X server. If firefox process were to be pwned (e.g., a drive-by web attack were to exploit a firefox buffer overrun), you could have malicious code doing some very nasty things. For example: (a) create a transparent window covering the entire screen, i.e., a keylogger, and use this to sniff passwords (b) write to various user-hexme scripts to make the exploit persistent (c) inject malicious input (e.g. 'rm -rf $HOME ') into various shells (d) send anything stored in the firefox password manager to evil.com I outlined some ideas for mitigating some of these risks in the thread starting at http://marc.info/?l=openbsd-miscm=141616701418506w=1; lots of people responded with useful suggestions. Basically, my proposal was (is) to run firefox as a separate nonpriviliged user, but via an ssh -X tunnel to localhost, using public-key authentication: #!/bin/sh ssh -X -i $HOME/.ssh/firefox _firefox@localhost \ firefox.bin -no-remote -new-instance \ 21 /dev/null This means that the firefox process is subjected to the X11 Security Extension restrictions, which (in theory) would prevent the firefox process from interfering with other X clients. That is, in theory this approach blocks exploits (a) and (c). I've been using this for a while now on 5.6-stable/amd64, and it works pretty well. The main problem I've found so far is with X cut-n-paste; in http://marc.info/?l=openbsd-miscm=141721398509425w=1, tedu@ pointed out that this is a feature, not a bug, of the way X security works. The result is: * cut-n-paste from other clients into firefox works fine * cut-n-paste from firefox out to other clients doesn't work; a shell script like this provides an 80% workaround to access the cut-n-pasted-from-firefox text #!/bin/sh ssh -X -i $HOME/.ssh/firefox _firefox@localhost \ xsel -o echo '' I suspect that a slightly fancier script could then insert that text back into the regular outside-the-sandbox X cut buffer, but I haven't gotten around to trying that yet. ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. -- George Orwell, 1984
Re: how to , apache's ' AuthType Basic '
i thank you for very nice advise. i will try apache-httpd-2.2.27p4.tgz. translation site is https://translate.google.com/ . please input URL , then the site translate it in english .
Re: how to , apache's ' AuthType Basic '
Hi, mar...@martinbrandenburg.com wrote on Mon, Dec 15, 2014 at 08:07:01AM +: As for the immediate question, OpenBSD base had a fork of Apache 1.x prior to 5.6. This was removed in 5.6 and is no longer available. That is not true. It is still available from ports: apache-httpd-openbsd Unless you need specific Apache 2 features, it's still a better choice than Apache 2 because moving it from base to ports obviously didn't invalidate the security audits done years ago. OpenBSD base also contains nginx. That is no longer true, but nginx is available from ports. Yours, Ingo
Re: how to , apache's ' AuthType Basic '
i managed to work 'Basic Auth' but there may be mistakes . please correct them . www root is /var/apache2/htdocs/ . conf file is /etc/apache2/httpd2.conf . cd /etc/apache2/ htpasswd .htpasswd XXX chmod 644 .htpasswd - correct ? # head /etc/apache2/httpd2.conf Directory /var/apache2/htdocs/YYY AuthType Basic AuthName Secret Zone AuthUserFile /etc/apache2/.htpasswd Require user XXX /Directory --- tuyosi
Dovecot happy on 5.6?
I have been trying out dovecot for some years and it has always had some irritating bug or limitation and I have seen a few gripes from others. It seems to have been very quiet lately so I thought I'd have another attempt to get it running whilst choosing options that look like ones to suit me. Any happy users? Absolute haters who have really tried hard? (Description of problem?) Thanx, *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
What happened when 5.5 met my old reliable box
[dmesg follows] I have several light weight i386 boxes made by Aopen around y2k at the time of the shonky motherboard caps. A customer gave me all the ones that had not failed until well out of warranty and I bought a bag of superior caps and swapped out all the bad ones and they all have been running for at least 8 years. One box is due to be brought up with a new install. It crashed on 5.6 at the point where it was due to get the sets from the CD. I wish I could catch what it says but it closes the message too fast for my eyes. I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. dmesg: OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Celeron(TM) CPU 1300MHz (GenuineIntel 686-class) 1.31 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX, FXSR,SSE,PERF real mem = 527953920 (503MB) avail mem = 507879424 (484MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/27/02, BIOS32 rev. 0 @ 0xfb4b0, SMBIOS rev. 2.3 @ 0xf0800 (35 entries) bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 02/27/2002 bios0: VIA Technologies, Inc. VT8601 apm0 at bios0: Power Management spec V1.2 (slowidle) acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0xde94 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfde10/128 (6 entries) pcibios0: PCI Exclusive IRQs: 5 10 11 pcibios0: PCI Interrupt Router at 000:07:0 (VIA VT82C596A ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xc000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 VIA VT8601 PCI rev 0x05 viaagp0 at pchb0: v2 agp0 at viaagp0: aperture at 0xe000, size 0x1000 ppb0 at pci0 dev 1 function 0 VIA VT82C601 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 Trident CyberBlade i1 rev 0x6a wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 7 function 0 VIA VT82C686 ISA rev 0x40 pciide0 at pci0 dev 7 function 1 VIA VT82C571 IDE rev 0x06: ATA100, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: Maxtor 6Y080L0 wd0: 16-sector PIO, LBA, 78167MB, 160086528 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: ATAPI-CD, ROM-DRIVE-52MAX, 52AW ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4 uhci0 at pci0 dev 7 function 2 VIA VT83C572 USB rev 0x1a: irq 5 uhci1 at pci0 dev 7 function 3 VIA VT83C572 USB rev 0x1a: irq 5 viapm0 at pci0 dev 7 function 4 VIA VT82C686 SMBus rev 0x40: SMI iic0 at viapm0 iic0: addr 0x2d 00=01 01=40 02=97 03=ff 04=ff 07=50 08=ad 09=3d 0b=55 13=d7 14= 45 16=78 17=8a 1d=40 1f=7f 20=a6 21=96 22=7d 23=d0 24=d2 25=cd 26=cc 27=80 28 =80 29=a1 2b=ff 2d=d6 2e=c1 2f=d4 30=bf 31=cd 32=ba 33=cb 34=b8 37=08 38=02 39 =ff 3d=ff 3f=a2 40=01 43=ff 44=ff 47=50 48=ad 49=3d 4b=55 53=7f 54=12 56=f8 57=81 5d=40 5f=7f 60=a6 61=96 62=7d 63=d0 64=d2 65=cd 66=cc 67=80 68=80 69=a5 6b=ff 6d=d6 6e=c1 6f=d4 70=bf 71=cd 72=ba 73=cb 74=b8 77=08 78=02 79=ff 7d=ff 7f=a2 80 =01 83=ff 84=ff 87=50 88=ad 89=3d 8b=55 93=7f 94=1b 96=15 97=01 9d=40 9f=7f a0 =a6 a1=96 a2=7d a3=d0 a4=d2 a5=cd a6=cc a7=80 a8=80 a9=a5 ab=ff ad=d6 ae=c1 af=d4 b0=bf b1=cd b2=ba b3=cb b4=b8 b7=08 b8=02 b9=ff bd=ff bf=a2 c0=01 c3=ff c4 =ff c7=50 c8=ad c9=3d cb=55 d3=7f d4=15 d6=06 d7=01 dd=40 df=7f e0=a6 e1=96 e2= 7d e3=d0 e4=d2 e5=cd e6=cc e7=80 e8=80 e9=a5 eb=ff ed=d6 ee=c1 ef=d4 f0=bf f1 =cd f2=ba f3=cb f4=b8 f7=08 f8=02 f9=ff fd=ff ff=a2 words 00=01ff 01=00ff 02=00ff 03 = 04= 05=00ff 06=00ff 07=50ff spdmem0 at iic0 addr 0x50: 256MB SDRAM non-parity PC133CL2 spdmem1 at iic0 addr 0x51: 256MB SDRAM non-parity PC133CL2 viapm0: 24-bit timer at 3579545Hz rl0 at pci0 dev 17 function 0 Realtek 8139 rev 0x10: irq 11, address 00:01:80:0f:2b:94 rlphy0 at rl0 phy 0: RTL internal PHY isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 VIA UHCI root hub rev 1.00/1.00 addr 1 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 VIA UHCI root hub rev 1.00/1.00 addr 1 mtrr: Pentium Pro MTRR support vscsi0 at root
Re: What happened when 5.5 met my old reliable box
On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. 2. get a video camera. smartphone should be good enough. 3. brute force. build kernels from source from 5.4 onwards. the good news is this will only take about seven kernels to find the offending commit; the bad news is building old snapshot ramdisk kernels is quite a pain.
BGP, PF and CARP together
I'm trying to do something somewhat similar to Loïc Blot was attempting, as described in http://openbsd.7691.n7.nabble.com/PF-sync-doesn-t-not-work-very-well-tc230786.html#none but have the additional complication that I *do* need to do NAT for one subnet on the BGP routers, and I am using a mix of both CARP and dual-sessions depending on the BGP peer. I'm pushing up to ~1gbps through this pair of routers, each is more than capable of that much traffic on its own (in fact, they are right now). So far, I'm not doing NAT on these routers, and my pf rulesets on both consist of pass. I am not using pfsync, as there's no point (no rules). Current topology is shown at http://r1.customhosting.ca/BGP-plus-NAT.png. I now need to do NAT for one subnet and set up some actual pf rules. Should I configure pfsync? Should I just use sloppy state? (Admittedly, I know very little about running pf in this situation. Cluebats welcome.) -- -Adam Thompson athom...@athompso.net
Re: Dell R630 high interrupts on acpi0
On 16 Dec 2014, at 15:16, Jonathan Matthew jonat...@d14n.org wrote:
On Sun, Dec 14, 2014 at 06:22:37PM +0100, Hrvoje Popovski wrote:
Hi all,
I have got two new Dell R630 and have current on them from Sun Dec
14 15:07:17. Installation went great and very fast.
The problem is that I see around 11k interrupts on acpi0. First I
thought that problem is similar to this thread
http://marc.info/?l=openbsd-miscm=140551906923931w=2
But if in dell bios system profile settings is set to performance or
to DAPC there are always interrupts on acpi0.
In links bellow you can find acpidump and dmesg from performance and
DAPC settings in dell bios.
We just got some r630s too, so I spent some time last week figuring out what's
going on here. Something in the AML wants to talk to the intel MEI device.
Normally this works, but on the new generation of dell machines (we've seen it
on r630s and r730s), it's been moved outside the pci memory range we currently
allow on amd64. You can see this in your dmesgs:
0:22:0: mem address conflict 0x3303000/0x10
0:22:1: mem address conflict 0x3302000/0x10
The interrupt will keep triggering until it manages to talk to the device,
which will never happen.
we've also experienced this on r720s configured in Performance mode in the BIOS
too. others have hit this on r620s as well (look for Dell R620 high ACPI
Interrupt rate on misc@). the diff below fixes them too.
dlg
kettenis@ says we can get the pci memory range information we need to deal
with
this from acpi. Until that happens, expanding the allowed pci memory range
makes things work properly.
ok?
Index: pci_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.59
diff -u -p -u -p -r1.59 pci_machdep.c
--- pci_machdep.c 19 Apr 2014 11:53:42 - 1.59
+++ pci_machdep.c 16 Dec 2014 04:21:53 -
@@ -622,13 +622,17 @@ pci_init_extents(void)
* here. As long as vendors continue to support
* 32-bit operating systems, we should never see BARs
* outside that region.
+ *
+ * Dell 13G servers have important devices outside the
+ * 36-bit address space. Until we can extract the address
+ * ranges from acpi, expand the allowed range to suit.
*/
pcimem_ex = extent_create(pcimem, 0, 0xUL,
M_DEVBUF, NULL, 0, EX_NOWAIT);
if (pcimem_ex == NULL)
return;
- extent_alloc_region(pcimem_ex, 0x10UL,
- 0xfff0UL, EX_NOWAIT);
+ extent_alloc_region(pcimem_ex, 0x400UL,
+ 0xfc00UL, EX_NOWAIT);
for (bmp = bios_memmap; bmp-type != BIOS_MAP_END; bmp++) {
/*
Cannot determine prefetch area error with OpenBSD current autoinstall
OpenBSD 5.6-current (RAMDISK_CD) #573: Sun Dec 14 20:08:49 MST 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD An initial interactive install was succesful. A next autonstall using bsd,rd gave a Cannot determine prefetch area after selecting the sets. (Complete dmesg and install.conf will follow) === Let's install the sets! Location of sets? (disk http or 'done') [http] http HTTP proxy URL? (e.g. 'http://proxy:8080', or 'none') [none] none (Unable to get list from ftp.openbsd.org, but that is OK) HTTP Server? (hostname or 'done') hercules.utp.xnet Server directory? [pub/OpenBSD/snapshots/i386] snapshots/i386 Select sets by entering a set name, a file name pattern or 'all'. De-select sets by prepending a '-' to the set name, file name pattern or 'all'. Selected sets are labelled '[X]'. [X] bsd [X] base56.tgz[X] xbase56.tgz [X] xserv56.tgz [X] bsd.rd[X] comp56.tgz[X] xshare56.tgz [ ] site56.tgz [ ] bsd.mp[X] man56.tgz [X] xfont56.tgz Set name(s)? (or 'abort' or 'done') [done] -all bsd bsd.rd bsd.mp base56.tgz site56.tgz done Cannot determine prefetch area. Continue without verification? [no] no failed; check /ai.log === Note that all sets were specified in a single reply in the install.conf here. A retry with only listing a single set for each prompt, gave the same error: ===Select sets by entering a set name, a file name pattern or 'all'. De-select sets by prepending a '-' to the set name, file name pattern or 'all'. Selected sets are labelled '[X]'. [X] bsd [X] base56.tgz[X] xbase56.tgz [X] xserv56.tgz [X] bsd.rd[X] comp56.tgz[X] xshare56.tgz [ ] site56.tgz [ ] bsd.mp[X] man56.tgz [X] xfont56.tgz Set name(s)? (or 'abort' or 'done') [done] -all [ ] bsd [ ] base56.tgz[ ] xbase56.tgz [ ] xserv56.tgz [ ] bsd.rd[ ] comp56.tgz[ ] xshare56.tgz [ ] site56.tgz [ ] bsd.mp[ ] man56.tgz [ ] xfont56.tgz Set name(s)? (or 'abort' or 'done') [done] bsd [X] bsd [ ] base56.tgz[ ] xbase56.tgz [ ] xserv56.tgz [ ] bsd.rd[ ] comp56.tgz[ ] xshare56.tgz [ ] site56.tgz [ ] bsd.mp[ ] man56.tgz [ ] xfont56.tgz Set name(s)? (or 'abort' or 'done') [done] bsd.rd [X] bsd [ ] base56.tgz[ ] xbase56.tgz [ ] xserv56.tgz [X] bsd.rd[ ] comp56.tgz[ ] xshare56.tgz [ ] site56.tgz [ ] bsd.mp[ ] man56.tgz [ ] xfont56.tgz Set name(s)? (or 'abort' or 'done') [done] bsd.mp [X] bsd [ ] base56.tgz[ ] xbase56.tgz [ ] xserv56.tgz [X] bsd.rd[ ] comp56.tgz[ ] xshare56.tgz [ ] site56.tgz [X] bsd.mp[ ] man56.tgz [ ] xfont56.tgz Set name(s)? (or 'abort' or 'done') [done] base56.tgz [X] bsd [X] base56.tgz[ ] xbase56.tgz [ ] xserv56.tgz [X] bsd.rd[ ] comp56.tgz[ ] xshare56.tgz [ ] site56.tgz [X] bsd.mp[ ] man56.tgz [ ] xfont56.tgz Set name(s)? (or 'abort' or 'done') [done] site56.tgz [X] bsd [X] base56.tgz[ ] xbase56.tgz [ ] xserv56.tgz [X] bsd.rd[ ] comp56.tgz[ ] xshare56.tgz [X] site56.tgz [X] bsd.mp[ ] man56.tgz [ ] xfont56.tgz Set name(s)? (or 'abort' or 'done') [done] done Cannot determine prefetch area. Continue without verification? [no] no failed; check /ai.log The install.conf for this retry: ===Terminal type? = vt220 System hostname = andromache Which network interface do you wish to configure? = xl0 IPv4 address for = 192.168.222.188 Netmask for = 255.255.255.0 IPv6 address for = none Which network interface do you wish to configure? = done Default IPv4 route? = 192.168.222.10 DNS domain name? = utp.xnet DNS nameservers? = 192.168.222.10 Password for root account? = dfsdfsdfdf Public ssh key for root account? = ecdsa-sha2-nistp256 E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBCMPEpNB1XOPiaIcv2NJhG1c5Os595IebooZdnloA0OT+npTyk9FQbysijlFq+GWyc7Wu27qaELlhikj//qAyGc= adri...@hercules.utp.xnet Start sshd(8) by default? = yes Start ntpd(8) by default? = yes NTP server? = default Do you expect to run the X Window System? = no Do you want the X Window System to be started by xdm(1)? = no Do you want to suspend on lid close? = no Change the default console to com0? = yes Which speed should com0 use? = 19200 What timezone are you in? = Europe/Amsterdam Setup a user? = no Which disk is the root disk? = sd0 Use DUIDs rather than device names in fstab? = yes Use (W)hole disk or (E)dit the MBR? = W Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? = a Which disk do you wish to initialize? = done Location of sets? = http HTTP proxy URL? = none HTTP Server? = hercules.utp.xnet Server directory? = snapshots/i386 Set name(s)? = -all Set name(s)? = bsd Set name(s)? = bsd.rd Set name(s)? = bsd.mp Set name(s)? = base56.tgz Set name(s)? = site56.tgz Set name(s)? = done Checksum test for site56.tgz
Re: What happened when 5.5 met my old reliable box
On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) 2. get a video camera. smartphone should be good enough. 3. brute force. build kernels from source from 5.4 onwards. the good news is this will only take about seven kernels to find the offending commit; the bad news is building old snapshot ramdisk kernels is quite a pain. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Dovecot happy on 5.6?
On 12/15/14 23:48, Rod Whitworth wrote: I have been trying out dovecot for some years and it has always had some irritating bug or limitation and I have seen a few gripes from others. It seems to have been very quiet lately so I thought I'd have another attempt to get it running whilst choosing options that look like ones to suit me. It's been quiet because the bugs in OpenBSD were fixed and it just works. It works fine for tons of people. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Dell R630 high interrupts on acpi0
On Sun, Dec 14, 2014 at 06:22:37PM +0100, Hrvoje Popovski wrote:
Hi all,
I have got two new Dell R630 and have current on them from Sun Dec
14 15:07:17. Installation went great and very fast.
The problem is that I see around 11k interrupts on acpi0. First I
thought that problem is similar to this thread
http://marc.info/?l=openbsd-miscm=140551906923931w=2
But if in dell bios system profile settings is set to performance or
to DAPC there are always interrupts on acpi0.
In links bellow you can find acpidump and dmesg from performance and
DAPC settings in dell bios.
We just got some r630s too, so I spent some time last week figuring out what's
going on here. Something in the AML wants to talk to the intel MEI device.
Normally this works, but on the new generation of dell machines (we've seen it
on r630s and r730s), it's been moved outside the pci memory range we currently
allow on amd64. You can see this in your dmesgs:
0:22:0: mem address conflict 0x3303000/0x10
0:22:1: mem address conflict 0x3302000/0x10
The interrupt will keep triggering until it manages to talk to the device,
which will never happen.
kettenis@ says we can get the pci memory range information we need to deal with
this from acpi. Until that happens, expanding the allowed pci memory range
makes things work properly.
ok?
Index: pci_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.59
diff -u -p -u -p -r1.59 pci_machdep.c
--- pci_machdep.c 19 Apr 2014 11:53:42 - 1.59
+++ pci_machdep.c 16 Dec 2014 04:21:53 -
@@ -622,13 +622,17 @@ pci_init_extents(void)
* here. As long as vendors continue to support
* 32-bit operating systems, we should never see BARs
* outside that region.
+*
+* Dell 13G servers have important devices outside the
+* 36-bit address space. Until we can extract the address
+* ranges from acpi, expand the allowed range to suit.
*/
pcimem_ex = extent_create(pcimem, 0, 0xUL,
M_DEVBUF, NULL, 0, EX_NOWAIT);
if (pcimem_ex == NULL)
return;
- extent_alloc_region(pcimem_ex, 0x10UL,
- 0xfff0UL, EX_NOWAIT);
+ extent_alloc_region(pcimem_ex, 0x400UL,
+ 0xfc00UL, EX_NOWAIT);
for (bmp = bios_memmap; bmp-type != BIOS_MAP_END; bmp++) {
/*
Re: Cannot determine prefetch area error with OpenBSD current autoinstall
On Tue, Dec 16, 2014 at 07:01, Adriaan wrote: OpenBSD 5.6-current (RAMDISK_CD) #573: Sun Dec 14 20:08:49 MST 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD An initial interactive install was succesful. A next autonstall using bsd,rd gave a Cannot determine prefetch area after selecting the sets. this probably means there wasn't a partition with enough free space available. looks like you have a pretty small disk.
Re: What happened when 5.5 met my old reliable box
On Tue, Dec 16, 2014 at 17:09, Rod Whitworth wrote: 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) set tty com0 or something at the boot prompt. man boot.
Re: What happened when 5.5 met my old reliable box
From the OpenBSD FAQ: At the boot loader prompt, enter boot *set tty com0* This will tell OpenBSD to use the first serial port (often called COM1 or COMA in PC documentation) as a serial console. The default baud rate is 9600. You set the speed higher by first typing stty com0 19200 This is documented in the boot.conf man page. On your workstation you can use tip(1) as terminal emulator. You can easily record the session to file by creating a .tiprc file: beautify record='LOGS/serial-log.txt' script verbose Create the LOGS directory, add yourself to the dialer group. With something liketip -v -19200 tty00 you can then start tip. If you have an USB-Serial converter you need to use ttyU0 as mentioned in ucom(4) On Tue, Dec 16, 2014 at 7:09 AM, Rod Whitworth glis...@witworx.com wrote: On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) 2. get a video camera. smartphone should be good enough. 3. brute force. build kernels from source from 5.4 onwards. the good news is this will only take about seven kernels to find the offending commit; the bad news is building old snapshot ramdisk kernels is quite a pain. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Dovecot happy on 5.6?
On 16/12/14 06:11, Brad Smith wrote: On 12/15/14 23:48, Rod Whitworth wrote: I have been trying out dovecot for some years and it has always had some irritating bug or limitation and I have seen a few gripes from others. It seems to have been very quiet lately so I thought I'd have another attempt to get it running whilst choosing options that look like ones to suit me. It's been quiet because the bugs in OpenBSD were fixed and it just works. It works fine for tons of people. +1 Bernd
Re: Cannot determine prefetch area error with OpenBSD current autoinstall
On Tue, Dec 16, 2014 at 01:01:51AM EST, Adriaan wrote: An initial interactive install was succesful. A next autonstall using bsd,rd gave a Cannot determine prefetch area after selecting the sets. [...] Cannot determine prefetch area. Continue without verification? [no] no I see that tedu@ already mentioned the fact about your local storage is probably too small. I'll only add a link to the FAQ[0] in case you have missed it. failed; check /ai.log Have you checked '/ai.log'? Checksum test for site56.tgz failed. Continue anyway? = yes Unverified sets: site56.tgz. Continue without verification? = yes Checksum test for site56-andromache.tgz failed. Continue anyway? = yes Unverified sets: site56-andromache.tgz. Continue without verification? = yes Given that the initial installation finishes just fine, I conclude that the second attempt fails due to your 'site*.tgz'[1] file sets being too big - try again without them. [0] http://www.openbsd.org/faq/faq4.html#InstMedia [1] http://www.openbsd.org/faq/faq4.html#site Regards, Raf
Re: Cannot determine prefetch area error with OpenBSD current autoinstall
On Tue, Dec 16, 2014 at 7:35 AM, Ted Unangst t...@tedunangst.com wrote: On Tue, Dec 16, 2014 at 07:01, Adriaan wrote: OpenBSD 5.6-current (RAMDISK_CD) #573: Sun Dec 14 20:08:49 MST 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD An initial interactive install was succesful. A next autonstall using bsd,rd gave a Cannot determine prefetch area after selecting the sets. this probably means there wasn't a partition with enough free space available. looks like you have a pretty small disk. Yes, the disk is 3GB but I only installed the minimum: $ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 837M 44.4M750M 6%/ /dev/wd0e 323M 14.8M292M 5%/home /dev/wd0d 1.7G205M1.4G13%/usr During the install there is even more space, because then, the site56.tgz has not yet installed some packages, that are PKG_CACHEd in /home/packages. ls -l /home/packages ; du -h $_ total 30160 -rw-r--r-- 1 root wheel 3265288 Dec 16 07:19 alpine-2.11p3.tgz -rw-r--r-- 1 root wheel 3273159 Dec 16 07:19 aspell-0.60.6.1p1.tgz -rw-r--r-- 1 root wheel 125754 Dec 16 07:19 bzip2-1.0.6p1.tgz -rw-r--r-- 1 root wheel 5213261 Dec 16 07:19 gettext-0.19.3.tgz -rw-r--r-- 1 root wheel 1540225 Dec 16 07:18 libiconv-1.14p1.tgz -rw-r--r-- 1 root wheel 1374388 Dec 16 07:19 lynx-2.8.9pl1p0.tgz -rw-r--r-- 1 root wheel 7580 Dec 16 07:18 quirks-2.43.tgz -rw-r--r-- 1 root wheel 166936 Dec 16 07:19 unzip-6.0p5.tgz -rw-r--r-- 1 root wheel 320970 Dec 16 07:19 xz-5.0.7.tgz 14.7M /home/packages
