Re: Merging pf redirection rules with macros?

2013-01-20 Thread Remco
pekka wrote:

 Hi,
 
 is there a way to shorten these redirection rules with some macros
 
 server1 = 192.168.140.1
 server2 = 192.168.140.2
 server3 = 192.168.140.3
 server4 = 192.168.140.4
 rdp_port1 = 10001
 rdp_port2 = 10002
 rdp_port3 = 10003
 rdp_port4 = 10004
 
 pass in log on $ext_if proto tcp from any to $ext_if port $rdp_port1 \
 rdr-to $server1 port 3389
 pass in log on $ext_if proto tcp from any to $ext_if port $rdp_port2 \
 rdr-to $server2 port 3389
 pass in log on $ext_if proto tcp from any to $ext_if port $rdp_port3 \
 rdr-to $server3 port 3389
 pass in log on $ext_if proto tcp from any to $ext_if port $rdp_port4 \
 rdr-to $server4 port 3389
 
 The port number is always server number + 1
 
 The manual says port ranges are supported with:
 
 pass in on tl0 proto tcp from any to any port 10001:10004 \
 rdr-to 192.168.140.1 port 3389
 
 but is there a way to use similar accemding ordering for servers
 somehow like this:
 
 pass in on tl0 proto tcp from any to any port 10001:10004 \
 rdr-to 192.168.140.1:192.168.140.4 port 3389
 
 -pekka-

I'm not aware of such functionality.

If it's not too much trouble I'd like to suggest using a script to generate 
these rules, e.g.:

#!/bin/sh

start=10;
i=${start};
port=0;
server=192.168.0.;
nsrv=2;

while [ $i != $((nsrv+start)) ];
do
echo port $((port+i)) rdr-to ${server}${i};
i=$((i+1));
done

generates:

port 10 rdr-to 192.168.0.10
port 11 rdr-to 192.168.0.11

(I'll leave it to you to fill in the blanks)

If you redirect the output to a file, e.g. /etc/pf/rdp.rules, you can include 
that in your main pf.conf.



Re: ldapd and The Diffie Hellman prime sent by the server is not acceptable

2013-01-20 Thread Gilles Chehade
Hi Vadim,

I only use ldapd in a local context but I'll have a look tomorrow and
come up with a diff for that.

Thanks,
Gilles


On Sat, Jan 19, 2013 at 01:56:12PM +0100, Vadim Agarkov wrote:
 Hello!
 
 Debian's (as well as Ubuntu's) openldap client is linked against
 GnuTLS library in contrast to the OpenBSD one which is linked
 against openssl library. Recent GnuTLS versions have more strict
 settings - they won't allow dh params with 512 bits or less and
 OpenBSD's ldapd daemon uses 512bits DH params. There is a function
 gnutls_dh_set_prime_bits which overrides default GnuTLS settings,
 but it looks like it is not supported by openldap client yet.
 
 Here are some links regarding GnuTLS problem:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440344
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196117
 
 The good fix for this would be setting dh params with strong (more
 than 512) bits on the ldapd server side, but it is not possible with
 current version of ldapd:
 
 http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ldapd/ssl.c?rev=1.4;content-type=text%2Fplain
 
 there is a hardcoded 512bit DH value as you can see. And it would be
 nice if there was an option to set dh params like it is in OpenSMTPd
 (or at least set default bits for DH to be 1024 - as it is now in
 the same said OpenSMTPd):
 
 http://www.opensmtpd.org/smtpd.conf.5.html
 
 Host certificates may be used for these connections, and are
 searched for in the /etc/mail/certs directory. If certificate is
 specified, a certificate name.crt, a key name.key, a certificate
 authority name.ca and Diffie-Hellman parameters name.dh are
 searched for. If no certificate is specified, the default interface
 name is instead used, for example fxp0.crt, fxp0.key, fxp0.ca, and
 fxp0.dh. If no DH parameters are provided, smtpd will use built-in
 parameters. Creation of certificates is documented in starttls(8).
 
 http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/ssl.c?rev=1.51;content-type=text%2Fplain
 
 
 And as for now, the real workaround, that I see, is either to allow
 insecure ldap connections or use third-party tools like stunnel - it
 has default dh params with long enough primes and also can be set to
 use your custom dh params file.
 
 JFYI, you can check dh params returned by the server using
 gnutls-cli utility. For example, the things should look like the
 following for 2048bits DH params:
 =
 $ gnutls-cli -s -p 636 ldap.your_cool_server.net
 Resolving 'ldap.your_cool_server.net'...
 Connecting to 'XX:636'...
 
 - Simple Client Mode:
 
 click ctrl+d
 *** Starting TLS handshake
 - Ephemeral Diffie-Hellman parameters
  - Using prime: 2048 bits
  - Secret key: 2047 bits
  - Peer's public key: 2048 bits
 - Certificate type: X.509
  - Got a certificate list of 1 certificates.
  - Certificate[0] info:
 ...
 =
 
 
 Hope that sheds some light on this problem..
 
 P.S. I CC'ed ldapd developers in order to have some hope this might
 be fixed one day..
 
 ---
 thanks,
 VA
 
 On 2011-01-21 19:21, Joel Carnat wrote:
 Hello,
 
 On a Ubuntu Linux 8.04 machine, I can't query my OpenBSD 4.9
 ldapd(8).
 It works from the local OpenBSD and from a remote NetBSD server.
 All machines have the CA file installed in the OpenSSL directory
 and the ldap.conf file configured to use that particular CA file.
 
 Here's what I get on the Linux box:
 $ ldapsearch -d 1 -x -H ldaps://ldap.tumfatig.net -D
 cn=email,dc=tumfatig,dc=net \
 -W -b ou=users,dc=tumfatig,dc=net mail=j...@carnat.net
 ldap_url_parse_ext(ldaps://ldap.tumfatig.net)
 ldap_create
 ldap_url_parse_ext(ldaps://ldap.tumfatig.net:636/??base)
 Enter LDAP Password:
 ldap_sasl_bind
 ldap_send_initial_request
 ldap_new_connection 1 1 0
 ldap_int_open_connection
 ldap_connect_to_host: TCP ldap.tumfatig.net:636
 ldap_new_socket: 3
 ldap_prepare_socket: 3
 ldap_connect_to_host: Trying 10.0.0.50:636
 ldap_pvt_connect: fd: 3 tm: -1 async: 0
 TLS: can't connect: The Diffie Hellman prime sent by the server is
 not acceptable \
 (not long enough)..
 ldap_err2string
 ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
 
 Not sure if that matters, but the OpenBSD's openssl.cnf (which was
 used to generate
 and sign the CA and certificate files) contains:
 default_bits = 4096
 
 Is there a way to tell ldapd(8) to use a bigger DH value ?
 
 TIA,
   Jo
 

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg



Re: rc.d start claims to have failed, but actually succeeds

2013-01-20 Thread Forman, Jeffrey
On Sun, Jan 20, 2013 at 12:03 AM, Matthew Weigel uni...@idempot.net wrote:

 On 1/19/2013 10:23 PM, Forman, Jeffrey wrote:

  One thing to note, is that the (failed) shows up after 5-10 seconds, not
  immediately. But the issue is that the Python script itself is actually
  running on the machine. Only rc.d claims it has failed.

 When rc_bg=YES, rc_cmd start does the equivalent of rc_cmd check
 waiting
 for the named daemon to show up in the process list.

 Since /usr/local/pf-graphite/pfloggraphite is a Python script, the process
 listing begins with /usr/local/bin/python (or whichever python), *not*
 /usr/local/pf-graphite/pfloggraphite.

  I have read the rc.d and rc.subr man pages but perhaps am missing an
 import
  detail in my rc.d file or script itself. Anyone able to shed some light?

 I believe you need to define pexp after sourcing rc.subr.


You were exactly right. I ended up looking at a daemon just like this one,
puppetd which runs under Ruby, and it had a similar pexp variable. I added

pexp=.*python.* ${daemon}

to my rc.d file after sourcing rc.subr, and things work perfectly. Thanks
Matthew.



 --
  Matthew Weigel
  hacker
  unique  idempot . ent



unable to build -current from 5.2 beta

2013-01-20 Thread Ivo Chutkin

Hello,
I am trying to build -current from 5.2 beta from Jul 1 but getting the 
following error:


{standard input}: Assembler messages:
{standard input}:105: Error: no such instruction: `rdrand %rbx'
*** Error code 1

Stop in /usr/src/sys/arch/amd64/compile/GENERIC (line 89 of 
/usr/share/mk/sys.mk).


I am getting the same error with GENERIC and GENERIC.MP

Is this know problem or I am doing something wrong?
Dmesg bellow.

Thanks for the help,
Ivo


OpenBSD 5.2-beta (GENERIC.MP) #340: Sun Jul  1 23:18:37 MDT 2012
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8560926720 (8164MB)
avail mem = 8310677504 (7925MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb4c0 (56 entries)
bios0: vendor American Megatrends Inc. version 2.00 date 05/08/2012
bios0: Supermicro X9SCL/X9SCM
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG PRAD HPET SSDT SPMI SSDT SSDT 
SPCR EINJ ERST HEST BERT BGRT
acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) P0P1(S4) 
USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) PXSX(S4) 
RP01(S4) PXSX(S4) R
P02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) 
RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) 
PEG2(S4) PEG3(S

4) GLAN(S4) EHC1(S4) EHC2(S4) HDEF(S4) PWRB(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) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3093.46 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,

EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.97 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,

EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.97 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,

EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.97 MHz
cpu3: 
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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,

EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu3: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus 2 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0: Failed to read resource settings
acpicpu0 at acpi0: C3, C1, PSS
acpicpu1 at acpi0: C3, C1, PSS
acpicpu2 at acpi0: C3, C1, PSS
acpicpu3 at acpi0: C3, C1, PSS
acpipwrres0 at acpi0: FN00
acpipwrres1 at acpi0: FN01
acpipwrres2 at acpi0: FN02
acpipwrres3 at acpi0: FN03
acpipwrres4 at acpi0: FN04
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 3093 MHz: speeds: 3101, 3100, 3000, 2900, 2800, 
2700, 2600, 2500, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600 MHz

pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor Intel, unknown product 0x0158 
rev 0x09
em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x05: msi, address 
00:25:90:77:64:19

ehci0 at pci0 dev 26 function 0 Intel 6 Series USB rev 0x05: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb0 at pci0 dev 28 function 0 Intel 6 Series PCIE rev 0xb5: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 4 Intel 6 Series PCIE rev 0xb5: msi
pci2 at ppb1 bus 2
em1 at pci2 dev 0 function 0 Intel 

Re: unable to build -current from 5.2 beta

2013-01-20 Thread Brad Smith
On Sun, Jan 20, 2013 at 03:43:22PM +0200, Ivo Chutkin wrote:
 Hello,
 I am trying to build -current from 5.2 beta from Jul 1 but getting
 the following error:
 
 {standard input}: Assembler messages:
 {standard input}:105: Error: no such instruction: `rdrand %rbx'
 *** Error code 1
 
 Stop in /usr/src/sys/arch/amd64/compile/GENERIC (line 89 of
 /usr/share/mk/sys.mk).
 
 I am getting the same error with GENERIC and GENERIC.MP
 
 Is this know problem or I am doing something wrong?

Upgrade using a snapshot.

 Dmesg bellow.
 
 Thanks for the help,
 Ivo
 
 
 OpenBSD 5.2-beta (GENERIC.MP) #340: Sun Jul  1 23:18:37 MDT 2012
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8560926720 (8164MB)
 avail mem = 8310677504 (7925MB)
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb4c0 (56 entries)
 bios0: vendor American Megatrends Inc. version 2.00 date 05/08/2012
 bios0: Supermicro X9SCL/X9SCM
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S1 S4 S5
 acpi0: tables DSDT FACP APIC FPDT MCFG PRAD HPET SSDT SPMI SSDT SSDT
 SPCR EINJ ERST HEST BERT BGRT
 acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) P0P1(S4)
 USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4)
 PXSX(S4) RP01(S4) PXSX(S4) R
 P02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4)
 PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4)
 PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S
 4) GLAN(S4) EHC1(S4) EHC2(S4) HDEF(S4) PWRB(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) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3093.46 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,
 EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: apic clock running at 99MHz
 cpu1 at mainbus0: apid 2 (application processor)
 cpu1: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.97 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,
 EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu2 at mainbus0: apid 4 (application processor)
 cpu2: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.97 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,
 EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
 cpu2: 256KB 64b/line 8-way L2 cache
 cpu3 at mainbus0: apid 6 (application processor)
 cpu3: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.97 MHz
 cpu3: 
 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,
 EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
 cpu3: 256KB 64b/line 8-way L2 cache
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
 acpimcfg0 at acpi0 addr 0xf800, bus 0-63
 acpihpet0 at acpi0: 14318179 Hz
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 3 (P0P1)
 acpiprt2 at acpi0: bus 1 (RP01)
 acpiprt3 at acpi0: bus -1 (RP02)
 acpiprt4 at acpi0: bus -1 (RP03)
 acpiprt5 at acpi0: bus -1 (RP04)
 acpiprt6 at acpi0: bus 2 (RP05)
 acpiprt7 at acpi0: bus -1 (RP06)
 acpiprt8 at acpi0: bus -1 (RP07)
 acpiprt9 at acpi0: bus -1 (RP08)
 acpiprt10 at acpi0: bus -1 (PEG0)
 acpiprt11 at acpi0: bus -1 (PEG1)
 acpiprt12 at acpi0: bus -1 (PEG2)
 acpiprt13 at acpi0: bus -1 (PEG3)
 acpiec0 at acpi0: Failed to read resource settings
 acpicpu0 at acpi0: C3, C1, PSS
 acpicpu1 at acpi0: C3, C1, PSS
 acpicpu2 at acpi0: C3, C1, PSS
 acpicpu3 at acpi0: C3, C1, PSS
 acpipwrres0 at acpi0: FN00
 acpipwrres1 at acpi0: FN01
 acpipwrres2 at acpi0: FN02
 acpipwrres3 at acpi0: FN03
 acpipwrres4 at acpi0: FN04
 acpitz0 at acpi0: critical temperature is 106 degC
 acpitz1 at acpi0: critical temperature is 106 degC
 acpibat0 at acpi0: BAT0 not present
 acpibat1 at acpi0: BAT1 not present
 acpibat2 at acpi0: BAT2 not present
 acpibtn0 at acpi0: PWRB
 acpibtn1 at acpi0: LID0
 acpivideo0 at acpi0: GFX0
 acpivout0 at acpivideo0: DD02
 ipmi at mainbus0 not configured
 cpu0: Enhanced SpeedStep 3093 MHz: speeds: 3101, 3100, 3000, 2900,
 2800, 2700, 2600, 2500, 2300, 2200, 2100, 2000, 1900, 1800, 1700,
 1600 MHz
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 vendor Intel, unknown product
 0x0158 rev 0x09
 em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x05: msi, address
 00:25:90:77:64:19
 ehci0 at pci0 dev 26 function 0 Intel 6 Series USB rev 0x05: apic 2 int 16
 usb0 at ehci0: USB revision 2.0
 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
 ppb0 at pci0 dev 28 

Re: Are pthreads hopeless in 5.0?

2013-01-20 Thread Tobias Ulmer
On Sat, Jan 19, 2013 at 11:18:37PM -0500, Alan Corey wrote:
 They seem to work for my programs, but I'm trying to use rtl_fm from
 the osmocom group at http://sdr.osmocom.org/trac/wiki/rtl-sdr.  This
 machine boots into OpenBSD and an old Debian Linux and the program
 runs fine under Linux.  If I can figure out how to make it work under
 OpenBSD I'd like to submit some ifdefs for it.
 
 The program is for software defined radio using a $20 dongle plugged
 into a USB port that tunes 24 - 1700 MHz.  It works under Linux and
 Windows, but under OpenBSD the demodulation doesn't keep up with the
 incoming data. The driver uses a callback routine when it has data,
 which does a sem_post that should enable a demodulation thread.  It
 works after a fashion, but by the time it starts 5 or 6 more batches
 of data have come along and most of them get lost (in OpenBSD).  I
 think maybe I need to change the priority on the thread if possible.
 
 I posted this question originally to StackOverflow:
 http://stackoverflow.com/questions/14392158/pthread-priority-scheduling-under-openbsd
 
 Have I run into one of the shortcomings of pthreads as implemented in
 5.0?

Maybe, but 5.0 is not supported anymore (and the first suggestion would
by to try a new snapshot). We've switched to a completely different
threading model in 5.2.  See http://www.openbsd.org/52.html#new
Due to this, it makes even less sense to start looking into issues on
5.0.

 I'll probably upgrade to 5.3 when it comes out, but that
 involves hours of sitting in a car using a public WiFi connection
 which I don't plan to do until warmer weather.

Not sure what you're doing, but an update on a system that is properly
maintained takes probably 30 minutes, less if you have some practise.
You could also pull down the files and do the actual update at home.
It's more work the longer you wait...

 
   Alan
 
 -- 
 Credit is the root of all evil.  - AB1JX



Re: Are pthreads hopeless in 5.0?

2013-01-20 Thread Alan Corey
On 1/20/13, Tobias Ulmer tobi...@tmux.org wrote:
 On Sat, Jan 19, 2013 at 11:18:37PM -0500, Alan Corey wrote:
 They seem to work for my programs, but I'm trying to use rtl_fm from
 the osmocom group at http://sdr.osmocom.org/trac/wiki/rtl-sdr.  This
 machine boots into OpenBSD and an old Debian Linux and the program
 runs fine under Linux.  If I can figure out how to make it work under
 OpenBSD I'd like to submit some ifdefs for it.

 The program is for software defined radio using a $20 dongle plugged
 into a USB port that tunes 24 - 1700 MHz.  It works under Linux and
 Windows, but under OpenBSD the demodulation doesn't keep up with the
 incoming data. The driver uses a callback routine when it has data,
 which does a sem_post that should enable a demodulation thread.  It
 works after a fashion, but by the time it starts 5 or 6 more batches
 of data have come along and most of them get lost (in OpenBSD).  I
 think maybe I need to change the priority on the thread if possible.

 I posted this question originally to StackOverflow:
 http://stackoverflow.com/questions/14392158/pthread-priority-scheduling-under-openbsd

 Have I run into one of the shortcomings of pthreads as implemented in
 5.0?

 Maybe, but 5.0 is not supported anymore (and the first suggestion would
 by to try a new snapshot). We've switched to a completely different
 threading model in 5.2.  See http://www.openbsd.org/52.html#new
 Due to this, it makes even less sense to start looking into issues on
 5.0.

 I'll probably upgrade to 5.3 when it comes out, but that
 involves hours of sitting in a car using a public WiFi connection
 which I don't plan to do until warmer weather.

 Not sure what you're doing, but an update on a system that is properly
 maintained takes probably 30 minutes, less if you have some practise.
 You could also pull down the files and do the actual update at home.
 It's more work the longer you wait...


   Alan

 --
 Credit is the root of all evil.  - AB1JX



I'm on dialup, that's the only thing available in this area.
Installing 5.0 took me about 3 months by the time I got everything the
way I wanted it.  I've never done an update, only clean installs.
Usually I wait until the hard drive warranty runs out and replace it
and the OS at the same time, putting the old drive on the shelf to
copy forgotten things off from.  So maybe in May I can do something
about this, if I remember it.

  Alan
-- 
Credit is the root of all evil.  - AB1JX



Re: Are pthreads hopeless in 5.0?

2013-01-20 Thread Nicolai
On Sun, Jan 20, 2013 at 11:11:37AM -0500, Alan Corey wrote:
 I'm on dialup, that's the only thing available in this area.
 Installing 5.0 took me about 3 months by the time I got everything the
 way I wanted it.

Installations are SO FAST when you have the CDs.  They also include some
of the most common packages and their dependencies, so you can just
pkg_add huge swaths destined to /usr/local from the mounted CD.

Nicolai



Re: Still possible to get OpenBSD onto Soekris net5501 via qemu install to flashcard?

2013-01-20 Thread Sarah Caswell
Hi all,

Thanks for all the replies to my call for help.

The soekris install command that worked was:

shell# sudo qemu-system-i386 -hda /dev/rsd1c -cdrom install52.iso -boot d

Turns out I was not using the raw device (/dev/rsd1c) in my command but was 
trying to install /dev/sd0c.

--
Thanks also to Nick Holland for suggesting some alternative ways to install 
OBSD on Soekris that one might also call simple.
I'll definitely try them.

I do think that using quemu is a good (and simple) way to go for me because:

- I have qemu installed on my box for other reasons
- one only needs an attached cf card and a current version of install.iso (no 
CD burning or laptop reboot required)
- with qemu the install to cf can happen alongside other tasks within my usual 
work environment (e.g. browsing, word processing, etc)

Thanks again.

:-)

Sarah



  Hi all,
  
  I'm having a frustrating problem getting OpenBSD-current (or
  snapshot) to run on my Soekris net5501.
  
  With previous versions of OBSD I was able to use qemu to install to a
  compact flashcard directly, by connecting the flashcard to my laptop
  and then starting qemu like so:
  
  sudo qemu -hda /dev/sd0i -cdrom install52.iso -boot d  (and many
  variations of this command mostly pertaining to the /dev/sd0
  section)
 
 funny definition of directly.
 ...
  P.S.:  I know there are other ways to get OpenBSD running on a
  Soekris but I've always liked the utter simplicity of the qemu-based
  install.
 
 using an emulator = simple?
 If you don't understand the tools well enough to troubleshoot the problem, I 
 really \
 don't believe your assessment there. I don't know much about qemu, but I see 
 a \
 problem in the command line. 
 This is what *I* call simple:
 Take your USB flash card reader to a free machine with a USB port.  Put an 
 OpenBSD \
 CD in it.  Boot off CD.  Install to CF device.  Use DUIDs. Create a \
 /etc/hostname.vr0 (or whatever your soekris uses for its primary NIC), and do 
 other \
 network configuration as needed.  Put flash device in Soekris.  Done.  
 direct, \
 simple, bare minimum of extra tools.  Machine doesn't even have to be able 
 to \
 boot from the USB port, though you can't test it before installing on soekris 
 if it \
 isn't. 
 (variation: install bare minimum system on flash drive, move to Soekris, at 
 the \
 boot prompt, tell it bsd.rd and re-install exactly as you wish.  If *I* were 
 doing \
 that, I could do it from an installed OpenBSD machine of the same platform 
 without \
 taking down the machine or booting from a CD. I'd call that simple, but I \
 understand some basic tools that we try to keep normal people from having to 
 use.  \
 The info for figuring out how to do that is all in the OpenBSD FAQ, though 
 not in \
 recipe form.) 
 Nick.


-- 
I Cannot Do All the Good that the World Needs, But the World Needs All the 
Good That I Can Do--Jana Stanfield



Re: Still possible to get OpenBSD onto Soekris net5501 via qemu install to flashcard?

2013-01-20 Thread Alexander Hall

On 01/20/13 20:19, Sarah Caswell wrote:

Hi all,

Thanks for all the replies to my call for help.

The soekris install command that worked was:

shell# sudo qemu-system-i386 -hda /dev/rsd1c -cdrom install52.iso -boot d

Turns out I was not using the raw device (/dev/rsd1c) in my command but was 
trying to install /dev/sd0c.


I think you're mixing things up here (sd0 vs sd1). Also, you actually 
claimed to have used /dev/sd0i, which, while likely being some MSDOS 
partition, could be just anywhere on the disk. I would have expected 
/dev/sd1c to work too, but indeed the raw device should be the way to go.


/Alexander



Delayed deliverey

2013-01-20 Thread Friedrich Locke
Hi folks,

have anyone here already order a OBSD cd set and have them not delivered.
Then you ask a a replacement cd set and by the day this new replacement is
sent when original set (sent from the first time) arrives ?

Thanks in advance.



Re: Are pthreads hopeless in 5.0?

2013-01-20 Thread Alan Corey
I have bought official CDs, they haven't been all that useful.  Even
the stickers faded when I put them on my car.  I also supported by
regular Paypal donation when I was working.

I like to build from distfiles.  I'd like to see a set of DVDs that
had distfiles for everything in a particular OpenBSD version, so all
the dependencies were met.  As far as I know the distfiles are generic
enough so they work on multiple architectures.

I'd make a list, drive about 2 miles, download everything on my list,
come home and start building.  When I found some dependency missing it
went on the next day's list and I went on to something else.
Eventually I got all that working and thought of more stuff I wanted.
I have 515 ports by pkg_info, 552 on my laptop under 4.7, plus a lot
of things that aren't in the ports collection just built from sources,
like Fldigi, Gnuradio and snd.  There isn't a hamradio category like
in FreeBSD.  Just about any unix program with a decent configure
script and a lot without I've managed to get working.

I've been using OpenBSD since 2.7 and rarely download binaries, except
maybe Firefox.  I like OpenBSD because it's small and simple (compared
to FreeBSD or most Linuxes) and it doesn't insist on installing Gnome
or KDE or something else to run your life.  Fvwm is fine, typing
startx is fine, and don't tell me I can't log in as root if I want to.
 It doesn't try to work like Windows (or Ubuntu).  My first unix
experiences were with Data General and DEC unix in the 90s and this is
more like those than anything else I've tried.  It's about all I've
used since I retired a few years ago.

But occasionally I find a few rough edges like pthreads. I'd heard
there were pthreads issues and I knew they'd been replaced in newer
versions, I'm just wondering if I've run into some of those problems.
Most of the Osmocom group's programs like rtl_adsb, rtl_tcp don't work
quite right under OpenBSD even though they compile fine (once you get
rid of a -lrt here and there). There's probably a common cause and
pthreads could be it. 6 different programs, 6 different problems.
Very nice set of programs other than that.  Command line software
defined radio, originally for ARM machines like the Raspberry pi.
About 1% of the size of Gnuradio, which is nice in it's own way but a
little more bloatware than most people need or want.

  Alan



On 1/20/13, Rogier Krieger rkrie...@gmail.com wrote:
 On Sun, Jan 20, 2013 at 5:11 PM, Alan Corey alan01...@gmail.com wrote:
 I'm on dialup, that's the only thing available in this area.
 Installing 5.0 took me about 3 months by the time I got everything the
 way I wanted it.

 Assuming the 3 months is spent on fiddling with a system rather than
 downloading: It may pay off investing time in tools such as puppet or
 cfengine (available through ports) that allow you to re-install more
 easily, from a set of recipes/changes created by you.

 Additionally, there's features such as siteXX.tgz, as desribed in FAQ
 4.15 [1]. I've found that rather helpful in bootstrapping a system.

 Regards,

 Rogier


 References
 1. OpenBSD FAQ - 4.15 - How can I install a number of similar systems?
 http://www.openbsd.org/faq/faq4.html#Multiple



-- 
Credit is the root of all evil.  - AB1JX