Re: OpenBSD 5.5 on mSATA SSD unit in PC Engines APU.1C - "bad dir ino 2 at offset 0: mangled entry"
It think the designer wanted to keep the board compatible with the old case, or the other way around. To cool the CPU more one needs better pads ( i doubt there are much better, since the industry has standards) or adds a fan. Current situation is like this: \__/ - CPU - PAD == - Aluminium heatsink - PAD - CASE A better approach is a cast aluminium case, but this is too expensive. So one can do pressed steel sheet like this: \__/ - CPU - PAD . ../ \... - CASE ^^^ bend area This way, one pad and the extra aluminium heat spreader can be out of equation. Of course, and extra bending of the bottom sheet is needed. Maybe the price will go higher, maybe the CPU is too far and the bending distance is too much for the sheet. This is just the industry method, excuse my ASCII "art", please.
Re: OpenBSD 5.5 on mSATA SSD unit in PC Engines APU.1C - "bad dir ino 2 at offset 0: mangled entry"
One of the best pads around are Fujipoly [1] with thermal conductivity of 17 W/mK. These made a big difference on several laptop workstations that were having overheating issues. Some default pads are good enough, but in some cases thermal conductivity is a problem and you just need a better pad. [1] http://www.frozencpu.com/products/17499/thr-181/ On 06/27/2014 09:59 AM, Mihai Popescu wrote: It think the designer wanted to keep the board compatible with the old case, or the other way around. To cool the CPU more one needs better pads ( i doubt there are much better, since the industry has standards) or adds a fan. Current situation is like this: \__/ - CPU - PAD == - Aluminium heatsink - PAD - CASE A better approach is a cast aluminium case, but this is too expensive. So one can do pressed steel sheet like this: \__/ - CPU - PAD . ../ \... - CASE ^^^ bend area This way, one pad and the extra aluminium heat spreader can be out of equation. Of course, and extra bending of the bottom sheet is needed. Maybe the price will go higher, maybe the CPU is too far and the bending distance is too much for the sheet. This is just the industry method, excuse my ASCII "art", please.
support new
0 C Cyprus P Nicosia T Strovolos I Socrates Papachilleos M socratesp1...@gmail.com B +35799222339 N Over 10 years of experience Technical Support and Consulting for Linux/ OpenBSD networking and Server Administration. Providing fully customized solutions for Routers/Firewalls,VPN servers, IDS systems.
Re: nat-to private address
Hi,all.
I was able to do it thanks to the instruction of misc all
.I report it.
In addition , this openBSD is running on USB memory only .
sd1 at scsibus2 targ 1 lun 0: SCSI4
0/direct removable serial.85641000CE38A0VNSTPO
sd1: 30944MB, 512 bytes/sector, 63373312 sectors
OpenBSD
---
more /etc/sysctl.conf
# $OpenBSD: sysctl.conf,v 1.54 2012/09/20 12:51:43 yasuoka Exp $
#
# This file contains a list of sysctl options the user wants set at
# boot time. See sysctl(3) and sysctl(8) for more information on
# the many available variables.
#
net.inet.ip.forwarding=1# 1=Permit forwarding (routing) of IPv4 packets
cat /etc/hostname.rum0
#ext_if
dhcp nwid URoad-662EA0 wpakey 04271
cat /etc/hostname.bge0
#int_if
inet 192.168.11.1 255.255.255.0 NONE
cat /etc/dhcpd.interfaces
bge0
cat /etc/dhcpd.conf
option domain-name-servers 192.168.100.254 ;
subnet 192.168.11.0 netmask 255.255.255.0 {
option routers 192.168.11.1;
range 192.168.11.10 192.168.11.11;
}
cat /etc/pf.conf
# macros
int_if="bge0"
ext_if="rum0"
tcp_services="{ 22, 113 }"
icmp_types="echoreq"
# options
set block-policy return
set loginterface egress
set skip on lo
# FTP Proxy rules
anchor "ftp-proxy/*"
pass in quick on $int_if inet proto tcp to any port ftp divert-to
127.0.0.1 port 8021
# match rules
match out on $ext_if inet from !($ext_if:network) to any nat-to ($ext_if:0)
# filter rules
block in log
pass out quick
antispoof quick for { lo $int_if }
pass in on egress inet proto tcp from any to (egress) \
port $tcp_services
pass in inet proto icmp all icmp-type $icmp_types
pass in on $int_if
pfctl -ss
all tcp 192.168.11.1:22 <- 192.168.11.10:34071 ESTABLISHED:ESTABLISHED
all udp 192.168.11.255:631 <- 192.168.11.10:631 NO_TRAFFIC:SINGLE
pfctl -sr
anchor "ftp-proxy/*" all
pass in quick on bge0 inet proto tcp from any to any port = 21 flags
S/SA divert-to 127.0.0.1 port 8021
match out on rum0 inet from ! (rum0:network) to any nat-to (rum0:0)
block return in log all
pass out quick all flags S/SA
block drop in quick on ! lo inet6 from ::1 to any
block drop in quick on ! lo inet from 127.0.0.0/8 to any
block drop in quick inet from 127.0.0.1 to any
block drop in quick on ! bge0 inet from 192.168.11.0/24 to any
block drop in quick inet from 192.168.11.1 to any
block drop in quick inet6 from ::1 to any
block drop in quick on lo0 inet6 from fe80::1 to any
block drop in quick on bge0 inet6 from fe80::21e:c9ff:fe05:78fc to any
pass in on egress inet proto tcp from any to (egress) port = 22 flags S/SA
pass in on egress inet proto tcp from any to (egress) port = 113 flags S/SA
pass in inet proto icmp all icmp-type echoreq
pass in on bge0 all flags S/SA
puppy linux (dhcp client)
---
fconfig -a
eth0 Link encap:Ethernet HWaddr 00:00:39:E3:38:99
inet addr:192.168.11.10 Bcast:192.168.11.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1711 errors:0 dropped:0 overruns:0 frame:0
TX packets:1990 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1103913 (1.0 MiB) TX bytes:313349 (306.0 KiB)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
cat /etc/resolv.conf
# Generated by dhcpcd for interface eth0
nameserver 192.168.100.254 (wifi router's addreee)
ping www.openbsd.org
PING www.openbsd.org (129.128.5.194): 56 data bytes
64 bytes from 129.128.5.194: seq=0 ttl=227 time=311.753 ms
64 bytes from 129.128.5.194: seq=1 ttl=227 time=312.358 ms
^C
--- www.openbsd.org ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 311.753/312.055/312.358 ms
route -e
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.11.0* 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 192.168.11.10.0.0.0 UG0 0 0 eth0
THANKS! THANKS!
--
tuyosi takesima
Re: ssh-add: June 26 snap cannot read an id_rsa file
On 2014-06-27, Josh Grosse wrote: > I just updated from a June 17 to June 26 snapshot. The ssh-add utility > now fails immediately: [...] > > Between these two snapshots there was a major bump for libcrypto from 28.0 > to 29.0, but that may not be relevant. It's most likely fallout from the ssh changes on June 23: New key API: refactor key-related functions to be more library-like, existing API is offered as a set of wrappers. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: ssh-add: June 26 snap cannot read an id_rsa file
On Fri, Jun 27, 2014 at 4:29 AM, Christian Weisgerber wrote: > On 2014-06-27, Josh Grosse wrote: > >> I just updated from a June 17 to June 26 snapshot. The ssh-add utility >> now fails immediately: [...] >> >> Between these two snapshots there was a major bump for libcrypto from 28.0 >> to 29.0, but that may not be relevant. > > It's most likely fallout from the ssh changes on June 23: > > New key API: refactor key-related functions to be more library-like, > existing API is offered as a set of wrappers. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > Seeing the same here. I tested re-creating my keys, and the problem seems to be with password. With password, it fails; without, it works.
Re: ssh-add: June 26 snap cannot read an id_rsa file
On 2014-06-27 08:21, Kent Fritz wrote: On Fri, Jun 27, 2014 at 4:29 AM, Christian Weisgerber wrote: It's most likely fallout from the ssh changes on June 23: Yes, there were significant revisions, and they are integrated, as I cannot back off ssh-add.c r1.110 alone. I'd mucked about with ktrace output diffs to see if I could determine where the branch in logic occurred, but didn't really have the time to investigate fully. Seeing the same here. I tested re-creating my keys, and the problem seems to be with password. With password, it fails; without, it works. If I didn't have passphrases, I wouldn't use ssh-add. :)
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
I can also confirm that newest snapshot works now. On Thu, Jun 26, 2014 at 7:45 AM, Nils R wrote: > Works now with the latest snapshot (dsdt.c rev. 1.211), thanks!
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
I know on my laptop no acpi meant doesn't work. My saving grace is I always keep a kernel from the previous snapshot I tried as obsd. So if bsd doesn't work, I just boot from that. Do you have an older snapshot kernel you can tell tech support to boot into? On Thu, Jun 26, 2014 at 7:36 PM, Scott Vanderbilt wrote: > Having done a little man page reading on boot-time configuration, I learned > about the existence of ukc. I'm wondering whether something like > > ukc> disable acpi0 > > might circumvent the kernel panic and allow the boot to successfully > complete. I'm hoping that since this is a server, ACPI is non-essential. > Just grasping at straws in an effort to get this machine up and running > again. > > Thanks. > > > > > On 6/26/2014 4:21 PM, Scott Vanderbilt wrote: >> >> I have this exact same kernel panic. Unfortunately, it's occurring on a >> host at a remote co-lo. Does anyone know a way that I can get the >> on-site tech to suppress the assertion by way of some boot-time >> configuration? Then at least I can get this machine up and running so I >> can immediately upgrade to the latest snapshot, which apparently fixes >> this issue. >> >> Thanks. >> >> >> On 6/25/2014 8:05 AM, Jason Crawford wrote: >>> >>> My system panic's from the KASSERT() call at line 2269 after dsdt.c was >>> updated to 1.210. >>> >>> All I have is the basic panic message and the dmesg from the last known >>> working snapshot kernel. I tried to get more information but my USB >>> keyboard does not work in the kernel debugger, and my on-board keyboard >>> no longer works at all (I use the laptop as a desktop now). I typed up >>> everything I could see of that panic message by hand. >>> >>> Any patches that need to be tested I will be glad to try out. >>> >>> Here's the panic message and dmesg output. >>> >>> --- panic --- >>> acpi0 at bios0: rev 2panic: kernel diagnostic assertion >>> "rgn->v_opregion.iobase % sz == 0" failed: file >>> "../../../../dev/acpi/dsdt.c", line 2269 >>> Stopped atDebugger+0x9:leave >>> panic() at panic+0xfe >>> __assert() at __assert+0x25 >>> aml_rwgas() at aml_rwgas+0x1fd >>> aml_rwfield() at aml_rwfield+0x205 >>> aml_eval() at aml_eval+0x1ae >>> aml_parse() at aml_parse+0x183d >>> aml_parse() at aml_parse+0x1ff >>> aml_parse() at aml_parse+0x1ff >>> aml_parse() at aml_parse+0x1ff >>> end trace frame: 0x81ef48f0, count: 0 >>> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS >>> PANIC! >>> IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, >>> TOO. >>> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! >>> >>> >>> --- dmesg --- >>> OpenBSD 5.5-current (GENERIC.MP) #219: Thu Jun 19 22:16:22 MDT 2014 >>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >>> real mem = 4209770496 (4014MB) >>> avail mem = 4088930304 (3899MB) >>> mpath0 at root >>> scsibus0 at mpath0: 256 targets >>> mainbus0 at root >>> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdbeda000 (35 entries) >>> bios0: vendor Phoenix Technologies LTD version "V1.04" date 10/22/2009 >>> bios0: Gateway NV53 >>> acpi0 at bios0: rev 2 >>> acpi0: sleep states S0 S3 S4 S5 >>> acpi0: tables DSDT FACP SLIC SSDT APIC MCFG HPET >>> acpi0: wakeup devices LID0(S3) SLPB(S3) PB2_(S4) PB3_(S4) PB4_(S4) >>> PB5_(S4) PB6_(S4) PB7_(S4) PB9_(S4) PB10(S4) OHC0(S3) OHC1(S3) OHC2(S3) >>> OHC3(S3) OHC4(S3) EHC0(S3) [...] >>> acpitimer0 at acpi0: 3579545 Hz, 32 bits >>> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >>> cpu0 at mainbus0: apid 0 (boot processor) >>> cpu0: AMD Athlon(tm) II Dual-Core M300, 2000.97 MHz >>> cpu0: >>> >>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI >>> >>> T,ITSC >>> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB >>> 64b/line 16-way L2 cache >>> cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully >>> associative >>> cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully >>> associative >>> cpu0: AMD erratum 721 detected and fixed >>> cpu0: smt 0, core 0, package 0 >>> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges >>> cpu0: apic clock running at 200MHz >>> cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE >>> cpu1 at mainbus0: apid 1 (application processor) >>> cpu1: AMD Athlon(tm) II Dual-Core M300, 2000.03 MHz >>> cpu1: >>> >>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI >>> >>> T,ITSC >>> cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB >>> 64b/line 16-way L2 cache >>> cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully >>> associative >>> cpu1: DTLB 48 4KB entries fully associative, 48 4MB
root's password
Hi misc@-readers! I have once more read man afterboot(8) and a question came up related to the superuser's password. In section 'root password' advisory is given to "choose a password that has digits and special characters (not space)". This last advice is what I do not understand - all of my passwords have spaces, including root's, and I never noticed any drawbacks. Actually I consider spaces within a password to be a security feature making it a 'passphrase' which should be harder to crack (yes - it is as looong password for root ;-) ) Now: Is this advice in afterboot(8) 'out-of-date' or am I just lucky? STEFAN
Re: ssh-add: June 26 snap cannot read an id_rsa file
On Fri, Jun 27, 2014 at 6:12 AM, Josh Grosse wrote: > On 2014-06-27 08:21, Kent Fritz wrote: >> Seeing the same here. I tested re-creating my keys, and the problem >> seems to be with password. With password, it fails; without, it >> works. > > > If I didn't have passphrases, I wouldn't use ssh-add. :) > Yes, obviously! ssh-keygen -p seems to have a problem, but works regardlesss: $ ssh-keygen -p Enter file in which the key is (/home/kent/.ssh/id_rsa): key_load_private: invalid format Enter old passphrase: Key has comment 'rsa w/o comment' Enter new passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved with the new passphrase.
Re: root's password
On Fri, Jun 27, 2014 at 16:50, Stefan Wollny wrote: > Hi misc@-readers! > > I have once more read man afterboot(8) and a question came up related > to the superuser's password. > > In section 'root password' advisory is given to "choose a password > that has digits and special characters (not space)". This last advice > is what I do not understand - all of my passwords have spaces, > including root's, and I never noticed any drawbacks. Actually I > consider spaces within a password to be a security feature making it a > 'passphrase' which should be harder to crack (yes - it is as looong > password for root ;-) ) > > Now: Is this advice in afterboot(8) 'out-of-date' or am I just lucky? I can't think of a reason why it wouldn't work. I might stay away from control characters and unicode because you may have keyboard / byte sequence translation issues, but space should be reliable enough. The only place I can think spaces would be a problem is command line arguments, which 1) affects other characters as well 2) is a bad idea.
Re: root's password
On Fri, Jun 27, 2014 at 12:56:33PM -0400, Ted Unangst wrote: > On Fri, Jun 27, 2014 at 16:50, Stefan Wollny wrote: > > Hi misc@-readers! > > > > I have once more read man afterboot(8) and a question came up related > > to the superuser's password. > > > > In section 'root password' advisory is given to "choose a password > > that has digits and special characters (not space)". This last advice > > is what I do not understand - all of my passwords have spaces, > > including root's, and I never noticed any drawbacks. Actually I > > consider spaces within a password to be a security feature making it a > > 'passphrase' which should be harder to crack (yes - it is as looong > > password for root ;-) ) > > > > Now: Is this advice in afterboot(8) 'out-of-date' or am I just lucky? > > I can't think of a reason why it wouldn't work. I might stay away from > control characters and unicode because you may have keyboard / byte > sequence translation issues, but space should be reliable enough. > > The only place I can think spaces would be a problem is command line > arguments, which 1) affects other characters as well 2) is a bad idea. I never read that advise and hgave been using passwords with spaces for many years. Passwords to be entered in webforms is another story, of course ;-) -Otto
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
Unfortunately, not. It was a fresh install from a CD image to a hard drive which I then shipped to the ISP for installation, which replaced a failing drive in my machine co-located there. In any event, bypassing acpi in ukc got the machine up again, and I was able to upgrade to the latest snapshot which does indeed resolve the issue. All is well again. Thanks to Chris for confirming the boot-time config option. On 6/27/2014 6:44 AM, Jason Crawford wrote: I know on my laptop no acpi meant doesn't work. My saving grace is I always keep a kernel from the previous snapshot I tried as obsd. So if bsd doesn't work, I just boot from that. Do you have an older snapshot kernel you can tell tech support to boot into? On Thu, Jun 26, 2014 at 7:36 PM, Scott Vanderbilt wrote: Having done a little man page reading on boot-time configuration, I learned about the existence of ukc. I'm wondering whether something like ukc> disable acpi0 might circumvent the kernel panic and allow the boot to successfully complete. I'm hoping that since this is a server, ACPI is non-essential. Just grasping at straws in an effort to get this machine up and running again. Thanks. On 6/26/2014 4:21 PM, Scott Vanderbilt wrote: I have this exact same kernel panic. Unfortunately, it's occurring on a host at a remote co-lo. Does anyone know a way that I can get the on-site tech to suppress the assertion by way of some boot-time configuration? Then at least I can get this machine up and running so I can immediately upgrade to the latest snapshot, which apparently fixes this issue. Thanks. On 6/25/2014 8:05 AM, Jason Crawford wrote: My system panic's from the KASSERT() call at line 2269 after dsdt.c was updated to 1.210. All I have is the basic panic message and the dmesg from the last known working snapshot kernel. I tried to get more information but my USB keyboard does not work in the kernel debugger, and my on-board keyboard no longer works at all (I use the laptop as a desktop now). I typed up everything I could see of that panic message by hand. Any patches that need to be tested I will be glad to try out. Here's the panic message and dmesg output. --- panic --- acpi0 at bios0: rev 2panic: kernel diagnostic assertion "rgn->v_opregion.iobase % sz == 0" failed: file "../../../../dev/acpi/dsdt.c", line 2269 Stopped atDebugger+0x9:leave panic() at panic+0xfe __assert() at __assert+0x25 aml_rwgas() at aml_rwgas+0x1fd aml_rwfield() at aml_rwfield+0x205 aml_eval() at aml_eval+0x1ae aml_parse() at aml_parse+0x183d aml_parse() at aml_parse+0x1ff aml_parse() at aml_parse+0x1ff aml_parse() at aml_parse+0x1ff end trace frame: 0x81ef48f0, count: 0 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO. DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! --- dmesg --- OpenBSD 5.5-current (GENERIC.MP) #219: Thu Jun 19 22:16:22 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4209770496 (4014MB) avail mem = 4088930304 (3899MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdbeda000 (35 entries) bios0: vendor Phoenix Technologies LTD version "V1.04" date 10/22/2009 bios0: Gateway NV53 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT APIC MCFG HPET acpi0: wakeup devices LID0(S3) SLPB(S3) PB2_(S4) PB3_(S4) PB4_(S4) PB5_(S4) PB6_(S4) PB7_(S4) PB9_(S4) PB10(S4) OHC0(S3) OHC1(S3) OHC2(S3) OHC3(S3) OHC4(S3) EHC0(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) II Dual-Core M300, 2000.97 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI T,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) II Dual-Core M300, 2000.03 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI T,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associati
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
On 2014-06-26, Scott Vanderbilt wrote: > Having done a little man page reading on boot-time configuration, I > learned about the existence of ukc. I'm wondering whether something like > >ukc> disable acpi0 > > might circumvent the kernel panic and allow the boot to successfully > complete. I'm hoping that since this is a server, ACPI is non-essential. > Just grasping at straws in an effort to get this machine up and running > again. I think you should consider ACPI essential on pretty much any x86 machine from the last 4-5 years or so - servers, laptops, standard PCs. In an emergency such as this you might get away with it briefly, but some devices are likely not to work, and it's not recommended leaving it like that for any length of time, ACPI is involved in a lot of system controls (thermal controls, power etc) and most modern machines are just not designed/tested to work without it.
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
> On 2014-06-26, Scott Vanderbilt wrote: > > Having done a little man page reading on boot-time configuration, I > > learned about the existence of ukc. I'm wondering whether something like > > > >ukc> disable acpi0 > > > > might circumvent the kernel panic and allow the boot to successfully > > complete. I'm hoping that since this is a server, ACPI is non-essential. > > Just grasping at straws in an effort to get this machine up and running > > again. > > I think you should consider ACPI essential on pretty much any x86 > machine from the last 4-5 years or so - servers, laptops, standard PCs. Yes, ACPI is essential. It is the modern way to interface to the hardware; it is the modern BIOS API. The other BIOS interfaces (MPBIOS and PCIBIOS) are totally unreliable and rotting on most machines these days. The vendors include support, but they do not verify their correctness. > In an emergency such as this you might get away with it briefly, but > some devices are likely not to work, and it's not recommended leaving > it like that for any length of time, ACPI is involved in a lot of > system controls (thermal controls, power etc) and most modern machines > are just not designed/tested to work without it. Stuart is correct. Those of you turning off ACPI are relying on an interface model we have repeatedly described as broken.
Re: root's password
Em 27-06-2014 11:50, Stefan Wollny escreveu: > Hi misc@-readers! > > I have once more read man afterboot(8) and a question came up related > to the superuser's password. > > In section 'root password' advisory is given to "choose a password > that has digits and special characters (not space)". This last advice > is what I do not understand - all of my passwords have spaces, > including root's, and I never noticed any drawbacks. Actually I > consider spaces within a password to be a security feature making it a > 'passphrase' which should be harder to crack (yes - it is as looong > password for root ;-) ) > > Now: Is this advice in afterboot(8) 'out-of-date' or am I just lucky? > > STEFAN > Perhaps you should take a look at this funny and very accurate xkcd comic strip: http://xkcd.com/936/ Passwords are all about entropy. Spaces, special characters, don't mean much for brute force attacks. If you take a look at the most new, state of the art password cracking tools, you'll find that they are very, very good at guessing passwords. I believe that using long phrases composed of random words as passwords is way more effective than these special, punctuation, spaces, passwords. But, that's me. Don't take my word for it. The man page still does give good advice, specially because the cryptography used on the OpenBSD passwords is much stronger than other oses. Take a look at crypt(3) man page. You'll see that you can have a password with 72 characters. I believe that cryptographic attacks on the hashing are very hard. And remote attacks on your machine are unlikely. But remember, it's all about entropy. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
On 6/27/2014 12:10 PM, Stuart Henderson wrote: On 2014-06-26, Scott Vanderbilt wrote: Having done a little man page reading on boot-time configuration, I learned about the existence of ukc. I'm wondering whether something like ukc> disable acpi0 might circumvent the kernel panic and allow the boot to successfully complete. I'm hoping that since this is a server, ACPI is non-essential. Just grasping at straws in an effort to get this machine up and running again. I think you should consider ACPI essential on pretty much any x86 machine from the last 4-5 years or so - servers, laptops, standard PCs. In an emergency such as this you might get away with it briefly, but some devices are likely not to work, and it's not recommended leaving it like that for any length of time, ACPI is involved in a lot of system controls (thermal controls, power etc) and most modern machines are just not designed/tested to work without it. Thanks for clarifying. Disabling acpi was only meant to be a stopgap measure so I could get around the assertion in the kernel that caused a panic on boot. Once I was able to boot the machine, I upgraded to a later snapshot in which the assertion was removed. I never intended to permanently disable acpi. As the machine was at a remote co-lo, I felt had no other choice. Is there some better way that I should have handled this situation?
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
On Fri, Jun 27, 2014 at 01:15:59PM -0600, Theo de Raadt wrote: > > On 2014-06-26, Scott Vanderbilt wrote: > > > Having done a little man page reading on boot-time configuration, I > > > learned about the existence of ukc. I'm wondering whether something like > > > > > >ukc> disable acpi0 > > > > > > might circumvent the kernel panic and allow the boot to successfully > > > complete. I'm hoping that since this is a server, ACPI is non-essential. > > > Just grasping at straws in an effort to get this machine up and running > > > again. > > > > I think you should consider ACPI essential on pretty much any x86 > > machine from the last 4-5 years or so - servers, laptops, standard PCs. > > Yes, ACPI is essential. It is the modern way to interface to the hardware; > it is the modern BIOS API. > > The other BIOS interfaces (MPBIOS and PCIBIOS) are totally unreliable and > rotting on most machines these days. The vendors include support, but they > do not verify their correctness. > > > In an emergency such as this you might get away with it briefly, but > > some devices are likely not to work, and it's not recommended leaving > > it like that for any length of time, ACPI is involved in a lot of > > system controls (thermal controls, power etc) and most modern machines > > are just not designed/tested to work without it. > > Stuart is correct. Those of you turning off ACPI are relying on an > interface model we have repeatedly described as broken. > I have some hardware that doesn't work. Should I just disable mainbus? That way it doesn't attach. Maybe that would fix the problem. -ml
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
On Fri, Jun 27, 2014 at 12:37:33PM -0700, Scott Vanderbilt wrote: > On 6/27/2014 12:10 PM, Stuart Henderson wrote: > >On 2014-06-26, Scott Vanderbilt wrote: > >>Having done a little man page reading on boot-time configuration, I > >>learned about the existence of ukc. I'm wondering whether something like > >> > >>ukc> disable acpi0 > >> > >>might circumvent the kernel panic and allow the boot to successfully > >>complete. I'm hoping that since this is a server, ACPI is non-essential. > >>Just grasping at straws in an effort to get this machine up and running > >>again. > > > >I think you should consider ACPI essential on pretty much any x86 > >machine from the last 4-5 years or so - servers, laptops, standard PCs. > > > >In an emergency such as this you might get away with it briefly, but > >some devices are likely not to work, and it's not recommended leaving > >it like that for any length of time, ACPI is involved in a lot of > >system controls (thermal controls, power etc) and most modern machines > >are just not designed/tested to work without it. > > > > Thanks for clarifying. > > Disabling acpi was only meant to be a stopgap measure so I could get > around the assertion in the kernel that caused a panic on boot. Once > I was able to boot the machine, I upgraded to a later snapshot in > which the assertion was removed. I never intended to permanently > disable acpi. As the machine was at a remote co-lo, I felt had no > other choice. > > Is there some better way that I should have handled this situation? > Keep another kernel in / that is known working. -ml
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
On 6/27/14, Theo de Raadt wrote: >> On 2014-06-26, Scott Vanderbilt wrote: >> > Having done a little man page reading on boot-time configuration, I >> > learned about the existence of ukc. I'm wondering whether something >> > like >> > >> >ukc> disable acpi0 >> > >> > might circumvent the kernel panic and allow the boot to successfully >> > complete. I'm hoping that since this is a server, ACPI is non-essential. >> > >> > Just grasping at straws in an effort to get this machine up and running >> > >> > again. >> >> I think you should consider ACPI essential on pretty much any x86 >> machine from the last 4-5 years or so - servers, laptops, standard PCs. > > Yes, ACPI is essential. It is the modern way to interface to the hardware; > it is the modern BIOS API. viva pragmatism! http://www.openbsd.org/lyrics.html#45 :) --patrick > The other BIOS interfaces (MPBIOS and PCIBIOS) are totally unreliable and > rotting on most machines these days. The vendors include support, but > they > do not verify their correctness. > >> In an emergency such as this you might get away with it briefly, but >> some devices are likely not to work, and it's not recommended leaving >> it like that for any length of time, ACPI is involved in a lot of >> system controls (thermal controls, power etc) and most modern machines >> are just not designed/tested to work without it. > > Stuart is correct. Those of you turning off ACPI are relying on an > interface model we have repeatedly described as broken.
Re: relayd url redirection
For people who might stumble on this thread I ended up using Nginx with
a configuration file which looks similar to this.
Predrag
# $OpenBSD: nginx.conf,v 1.16 2014/01/28 14:48:53 stephan Exp $
#user www;
worker_processes 4;
#syslog local5 nginx;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#error_log syslog:notice|logs/error.log;
#pidlogs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
index index.html index.htm;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
#access_log syslog:notice|logs/access.log main;
#tcp_nopush on;
keepalive_timeout 65;
server_tokens off;
# Virtual hosts
server {
listen myIP:80;
server_name www.test.org;
location /www1 {
proxy_pass http://www1.int.test.org;
proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
proxy_redirect off;
proxy_buffering off;
proxy_set_headerHost$host;
proxy_set_headerX-Real-IP $remote_addr;
proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
}
location /www2 {
proxy_pass http://www2.int.test.org;
proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
proxy_redirect off;
proxy_buffering off;
proxy_set_headerHost$host;
proxy_set_headerX-Real-IP $remote_addr;
proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
}
}
}
Re: root's password
On 2014-06-27, Giancarlo Razzolini wrote: > Perhaps you should take a look at this funny and very accurate xkcd > comic strip: > > http://xkcd.com/936/ "yes, cracking a stolen hash is faster, but it's not what the average user should worry about" I disagree, that is *exactly* what the average user should worry about. And knowing that some people use xkcd style passwords, who would start on a brute force attack before they've finished with a decent wordlist run? > Passwords are all about entropy. Spaces, special characters, don't mean > much for brute force attacks. If you take a look at the most new, state > of the art password cracking tools, you'll find that they are very, very > good at guessing passwords. I believe that using long phrases composed > of random words as passwords is way more effective than these special, > punctuation, spaces, passwords. Using a long phrase is *much* worse than an equally long string of random characters. But of course most people can't remember the latter. It's a trade off. > And remote attacks on your machine are unlikely. /var/log/authlog on pretty much any machine with exposed ssh tells a different story ... (not that you really want people even getting as far as being able to attempt passwords..)
Re: root's password
Em 27-06-2014 19:48, Stuart Henderson escreveu: > "yes, cracking a stolen hash is faster, but it's not what the average user > should worry about" > > I disagree, that is *exactly* what the average user should worry about. > And knowing that some people use xkcd style passwords, who would start on > a brute force attack before they've finished with a decent wordlist run? For someone to be able to stole a hash, they already got into your machine. I believe that, at this point, you have much more to worry than just your password being crackable. The wordlist run as you mentioned, will get the weak passwords, based on one, two or tree small words with special chars variations. But with four, or five big words, things start to get a little more complicated. Specially if you throw in the mix a foreign language word. > Using a long phrase is *much* worse than an equally long string of random > characters. But of course most people can't remember the latter. It's a trade > off. Yes, that was entirely the point of the comic. The trade off. But, the entropy of a letter "a" is the same of "@". As I mentioned, and someone asked me off list, the most modern password cracking tools, know all these variations people use. This one: http://hashcat.net/oclhashcat/ is the better AFAIK. So, with that in mind, using these special chars and punctuation barely keep your password from being hacked. Specially if you are using a word and only changing some letters with them. > /var/log/authlog on pretty much any machine with exposed ssh tells > a different story ... > > (not that you really want people even getting as far as being able > to attempt passwords..) > Well, pf come in handy on these cases. In other systems I use fail2ban. It's worse than pf, but it is what can be done with iptables on linux anyway. And there are options for not needing to keep your ssh exposed. I never got a machine hacked, even when not using any mitigation techniques. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: nat-to private address
Hi all . i add some . USB memory only 2GB running openbsd works as dhcpd + nat . namely sd1 at scsibus2 targ 1 lun 0: SCSI0 0/direct removable serial.1d0d0211078C0D1310DE sd1: 1900MB, 512 bytes/sector, 3891200 sectors root on sd1a (4ef3e82a493a09dc.a) swap on sd1b dump on sd1b # df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/sd1a 3697340481116 303136014%/ and original pf.conf + match out on rum0 from !rum0:network to any nat-to (rum0) can nat . it is very convinient to remember. later think deeply , and rewrite pf.conf. sorry , I abbrebiate 1 point . cat /etc/rc.conf.local dhcpd_flags="" #NO # for normal use: "" cat /etc/pf.conf # $OpenBSD: pf.conf,v 1.53 2014/01/25 10:28:36 dtucker Exp $ set skip on lo block return# block stateless traffic pass# establish keep-state ### match out on rum0 from !rum0:network to any nat-to (rum0) ### # rum0 is firewall's ext_if # By default, do not permit remote connections to X11 block return in on ! lo0 proto tcp to port 6000:6010 # pfctl -ss all tcp 192.168.11.1:22 <- 192.168.11.3:35074 ESTABLISHED:ESTABLISHED all udp 192.168.11.255:631 <- 192.168.11.3:631 NO_TRAFFIC:SINGLE # pfctl -sr block return all pass all flags S/SA match out on rum0 inet from ! 192.168.100.0/24 to any nat-to (rum0) round-robin block return in on ! lo0 proto tcp from any to any port 6000:6010 In linux I pkg_add udhcpd , and iptables is too complex to deal with . So ,openbssd is greeat . - Bye . tuyosi takesima . http://openbsd-akita.blogspot.jp/2014/06/openbsad-runs-on-usb-memory-no-need-hdd.html
