Re: OpenSMTPD on OpenBSD 5.9

[Rod Whitworth]

On Sat, 9 Apr 2016 10:12:23 -0500, Edgar Pettijohn wrote:

>On 04/08/16 23:25, Rod Whitworth wrote:
>> I'm trying to replace Postfix with OpenSMTPD and I'm having a battle.
>>
>> I don't seem to be able to get the clues to match the hardware and the
>> configure recipes that I need.
>>
>> The most up to date I can find breaks at the second stanza and I can
>> guess that the instructions for configuring for PF are for OpenBSD 5.6
>> means that I should find a up to date have clue set.
>>
>> Does anyone have pointer to a rescue?
>>
>> Rod/
>> (who doesn't want to revert to Postfix..)
>>
>> *** NOTE *** Please DO NOT CC me. I  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.
>>
>I think you may need to describe what you are trying to achieve. Perhaps 
>your old postfix configuration as well.
>

What I am trying to achieve is a copy of the up-to-date instructions.

As I said the most recent copy is around 5.6.
I am running 5.9.

The most recent recipe is written by someone who makes considerable
mods and I like to   refrain from making changes until I find a change
that appears to have a solid reason.

Postfix is no help in getting OpenSMTPD working. Believe me and I've
been running Postfix since about OpenBSD 2.5 and doing it for some
large businesses.

The present instructions for OpenSMTPD go likes this:
1 Install some packages (3)

2 Create Maildir

Crash. Well it doesn't work as it is suppose to.

Study further and realise that you need up to date instructions.

So try to install 5.9 OpenBSD and run
http://puffysecurity.com/wiki/opensmtpd.html

Lots-a-luck.

Rod/

>From the land "down under": Australia.
Do we look  from up over?

Re: bioctl disk encryption

[Matt Schwartz]

Okay, I wasn't screaming - cheering on a great operating system, most
definitely. I'll dig into the source code a bit to see what I can learn.

On Apr 9, 2016 9:12 PM, "Jiri B" wrote:
>
> On Sat, Apr 09, 2016 at 08:18:11PM -0400, Matt Schwartz wrote:
> > I really like the bioctl full disk encryption feature. I would love to
see
> > it extended to support multiple users/passkeys. I once worked with a
> > commercial full disk encryption product that allowed this and could
even be
> > managed over a network. Coming up with a solution to manage encryption
keys
> > over a network is trivial but I'd love to see the full disk encryption
> > extended to support multiple users with individual passkeys.
> >
> > Thanks for listening!
>
> This is not how things work in OpenBSD. So you are screaming 'do that work
> for me!!!'. Understand the reality, it's hobbist project mostly, there are
> not paid by you or any big corporation (yes, there's some funding).
>
> So send your own diffs or do not expect your wish to become reality. There
> are more important things to work on (if you at least follow recent
OpenBSD
> development - SMP, threads/performance,...).
>
> j.

bioctl disk encryption

[Matt Schwartz]

I really like the bioctl full disk encryption feature. I would love to see
it extended to support multiple users/passkeys. I once worked with a
commercial full disk encryption product that allowed this and could even be
managed over a network. Coming up with a solution to manage encryption keys
over a network is trivial but I'd love to see the full disk encryption
extended to support multiple users with individual passkeys.

Thanks for listening!

Re: recommendations for 10GBase Ethernet on OpenBSD

[Joel Wirāmu Pauling]

Has any one used the Melanox X3 or the Intel 720's? I ask for the vxlan
offload features, which are pretty useful if you are going the SDN way (or
potentially might do)

-Joel

On 9 April 2016 at 09:54, Kapetanakis Giannis 
wrote:

> On 08/04/16 19:35, Joe Crivello wrote:
>
>> Intel X520 cards seem to work nicely in our shop.
>>
>>
> x520 work fine for us too.
>
> G

Re: xbacklight / screen brightness

[lists]

Thu, 7 Apr 2016 22:05:26 +0200 (CEST) Mark Kettenis

> > There are a few instances of this bug. You can also see it with cpu
> > frequency and audio volume.
> > 
> > Most drivers maintain soft state that should mirror the hardware
> > state. Except when it doesn't. Sometimes the driver has a bug,
> > sometimes the hardware lies, sometimes something else goes
> > wrong. The many layers of abstraction and acpi don't help either.  
> 
> There are defenitely machines out there where the acpi implementation
> sufferes from exactly this problem.  The AML method that reports back
> the current brightness level doesn't actually query the hardware, but
> simply reports back the soft state.  And that soft state isn't
> properly initialized!  It wouldn't surprise me if Windows never
> actually calls that method, or at least always explicitly sets the
> level it wants withour querying the hardware.
> 
> > It's a bug and it's worth reporting as much info about your hardware as
> > possible, but don't expect a quick fix. As a workaround, just run 
> > 'xbacklight
> > 50 ; xbacklight 100' or whatever you want.  
> 
> Or better, add lines like:
> 
> display.brightness=50
> display.brightness=100
> 
> to /etc/wsconsctl.conf.
> 
> To be able to fix problems like this we need dmesg and acpidump
> output.  If you use sendbug(1) to file a bug report, that information
> is automatically included if you run it as root.  As a bonus, the mail
> gets sent to an address that developers actually read...

There is a recent change in behaviour in xbacklight operation on a N280
1005ha, which brings the back-lighting behaviour in consistency with XP.

Previously the other OS would change it from very dark to full bright
in steps of about 10 (never counted) them, while our behaviour was to
go from complete off 0 to full bright 100 in steps of 1.  I liked our.

After the recent change, our behaviour is similar to the other OS, i.e.
that it goes from very dark but NOT off, 0 to 100 in steps of about 7.7
points, which gives coarser adjust, and does not seem more appropriate.

If however it is more correct in terms of ACPI consistency, I have no
objection, have already changed my way around it.  Just mentioning it.

Re: man pages diff

[lists]

Thu, 7 Apr 2016 21:40:24 +0100 Jason McIntyre 
> On Thu, Apr 07, 2016 at 10:13:02PM +0200, Ingo Schwarze wrote:
> > Hi,
> > 
> > Jason McIntyre wrote on Thu, Apr 07, 2016 at 08:35:52PM +0100:  
> > > On Thu, Apr 07, 2016 at 03:15:01PM -0400, Rob Pierce wrote:  
> >   
> > >> Change "super user" to "superuser".  
> >   
> > > hmm. you have the weight of the man pages behind you, since they
> > > overwhelmingly use "superuser".  
> > 
> > In that case, ...
> >   
> > > the trouble is, i don;t think "super
> > > user" is wrong, and i'm reluctant to do this...
> > > 
> > > i've made changes like this before, when we have a real majority of
> > > spelling leading one way. but they always creep back in. i think we
> > > should just accept that we can spell things more than one way sometimes.
> > > 
> > > but then grep ;(
> > > 
> > > jmc, indecisive...  
> > 
> >  ... just commit it, in particular when the work was already done.
> > 
> > Sure, it's not a big deal either way, and it doesn't do much harm
> > if a few spelling variants creep back in, no need to waste a lot
> > of time paying attention that they don't, but if we can improve
> > consistency almost for free, why not?
> > 
> > It can also help developers who look for spelling help in existing
> > pages if they find consistent usage.  That tends to reduce the time
> > spent trying to figure out whether there is a preferred form.  On
> > the other hand, consistency doesn't slow down people who don't care
> > as long as we don't yell at them.
> > 
> > Yours,
> >   Ingo
> >   
> 
> hi.
> 
> as far as i'm concerned, "super user" is not wrong.

it is wrong, however, to use two words in place of one, so backing up
the single word "superuser" change suggestion, would commit it without
much thought why 'not', as more reasons exist towards why 'yes', thanks

> for me, there's not a clear enough benefit to make the change. and i
> don;t like to somehow enforce spelling in a particular way.

1 space saved
easier grep (saves mind and fingers)
consistency path forward

we can rumble 2 min longer, yet please converge towards simplicity

> > > > Index: src/share/man/man4/pty.4
> > > > ===
> > > > RCS file: /cvs/src/share/man/man4/pty.4,v
> > > > retrieving revision 1.21
> > > > diff -u -p -r1.21 pty.4
> > > > --- src/share/man/man4/pty.421 Nov 2015 08:04:20 -  1.21
> > > > +++ src/share/man/man4/pty.47 Apr 2016 19:12:07 -
> > > > @@ -298,7 +298,7 @@ device nodes following the naming conven
> > > >  .Ox .
> > > >  Since
> > > >  .Pa ptm
> > > > -impersonates the super user for some operations it needs to perform
> > > > +impersonates the superuser for some operations it needs to perform
> > > >  to complete the allocation of a pseudo terminal, the
> > > >  .Pa /dev
> > > > -directory must also be writeable by the super user.
> > > > +directory must also be writeable by the superuser.
> > > > 
> > > > Index: src/share/man/man5/login.conf.5
> > > > ===
> > > > RCS file: /cvs/src/share/man/man5/login.conf.5,v
> > > > retrieving revision 1.62
> > > > diff -u -p -r1.62 login.conf.5
> > > > --- src/share/man/man5/login.conf.5 30 Mar 2016 06:58:06 -  
> > > > 1.62
> > > > +++ src/share/man/man5/login.conf.5 7 Apr 2016 19:12:07 -
> > > > @@ -683,7 +683,7 @@ to indicate if the user is in group whee
> > > >  Some authentication types require the user to be in group wheel when 
> > > > using
> > > >  the
> > > >  .Xr su 1
> > > > -program to become super user.
> > > > +program to become superuser.
> > > >  .El
> > > >  .Pp
> > > >  When the authentication program is executed,
> > > > 
> > > > Index: src/usr.sbin/cron/crontab.1
> > > > ===
> > > > RCS file: /cvs/src/usr.sbin/cron/crontab.1,v
> > > > retrieving revision 1.33
> > > > diff -u -p -r1.33 crontab.1
> > > > --- src/usr.sbin/cron/crontab.1 26 Oct 2015 15:50:06 -  1.33
> > > > +++ src/usr.sbin/cron/crontab.1 7 Apr 2016 19:12:07 -
> > > > @@ -65,7 +65,7 @@ be listed in the
> > > >  .Pa /var/cron/cron.deny
> > > >  file in order to use
> > > >  .Nm .
> > > > -If neither of these files exists then only the super user
> > > > +If neither of these files exists then only the superuser
> > > >  will be allowed to use
> > > >  .Nm .
> > > >  .Em NOTE :  

Bad X performance, possible bug with radeon card

[Federico Carrone]

Hi,

I have just started using OpenBSD in my desktop computer. Up to now I have
been using different Linux distributions in my desktop computer . The
installation and the setup of everything I use was incredible easy. Thanks
for the great work!

The only issue I am having is with X. In general the performance seems
laggy. I runned glxgears and got 7 FPS in average using the radeon driver.
On Linux I get 60 FPS.

I have seen some strange lines in dmesg and the X logs. Any idea of what I
can do?

Regards,
Federico.

*Dmesg extract*
error: [drm:pid0:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x850C)=0xCAFEDEAD)
drm:pid0:si_init *ERROR* disabling GPU acceleration
drm:pid0:radeon_bo_unpin *WARNING* 0xdb48e1a0 unpin not necessary
radeondrm0: 1600x900
wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0


*Full dmesg:*
https://gist.github.com/unbalancedparentheses/a91e2800ef0212eab5435d5b0c8663b5

*Xorg.0.log extract*
[  2410.057] (--) RADEON(0): Chipset: "VERDE" (ChipID = 0x683f)
[  2410.093] (II) RADEON(0): GPU accel disabled or not working, using
shadowfb for KMS


*Full Xorg.0.log*
https://gist.github.com/unbalancedparentheses/33b8c05a0de2460c8aec44b567584684

Re: shm_unlink and pledge

[Calvin]

I should note it's Mono itself calling cpath and vminfo. Changing the
runtime
to be more pledge friendlier (i.e: SHM dealloc concerns, store
boottime for
later) would require surgery in it. I was just curious
about if SHM
manipulation was documented to need a pledge.

From: owner-m...@openbsd.org
[owner-m...@openbsd.org] on behalf of Theo Buehler [t...@math.ethz.ch]
Sent:
April 9, 2016 5:35 PM
To: misc@openbsd.org
Subject: Re: shm_unlink and pledge
On Sat, Apr 09, 2016 at 12:52:16PM +, Calvin wrote:
> Recently, I've
created a pledge wrapper for C#. [1] I discovered that pledge
> seems to
trigger on shared memory manipulations, which aren't mentioned in the
> man
page for pledge. For example, Mono uses shared memory, which triggers
> pledge
unless I add the "cpath" promise. (It also uses "vminfo," to check for
> boot
time, but this seems fairly ays, should SHM operations be mentioned in the man
> page, or is this a bug?

The pledge manual generally only lists the
supported system calls, not
the library functions (with only a few
exceptions). Not sure the shm_*
functions would qualify as they are
practically unused in the base
system.

The shm_*(3) library functions should
be supported by the appropriate
pledge promises (mostly filesystem
manipulations). As is the case with
most other libc functions, you need to
inspect them and see what system
calls they use internally. Your example:
shm_unlink(3) calls unlink(2),
which, in turn, requires "cpath", so everything
is as expected.

On the other hand, the shmat(2), shmdt(2), shmget(2) and
shmctl(2)
system calls are not currently supported by pledge. As far as I
know,
there are currently no plans of adding support for those. If they are
used, you need to make sure the pledge call comes after them.

Concerning the
"vminfo" pledge: is it possible to fetch that value
and store it before you
call pledge?

> A backtrace of Mono tripping up
> on exit without the promise:
>
> (gdb) bt
> #0  0x196ea192113a in unlink () at
> :2
> #1
0x196ea18bf018 in shm_unlink (path=Variable "path" is not
> available.) at
/usr/src/lib/libc/gen/shm_open.c:87
> #2  0x196bc332e085 in
>
mono_shared_area_remove () from /usr/local/bin/mono
> #3  0x196ea191bcc7
in
> *_libc___cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:159
> #4
> 0x196ea191a07e in *_libc_exit (status=0) at
>
/usr/src/lib/libc/stdlib/exit.c:57
> #5  0x196bc312dce8 in _start () from
> /usr/local/bin/mono
> #6  0x in ?? ()
>
> Oh, and just in
case, if
> you omit "vminfo" instead:
>
> (gdb) bt
> #0  0x1e868df09eaa in
sysctl () at
> :2
> #1  0x1e844fa302c0 in mono_free () from
/usr/local/bin/mono
> #2
> 0x1e844f9deed0 in mono_gchandle_get_target ()
from /usr/local/bin/mono
> #3
> 0x1e844f9da27e in mono_runtime_cleanup ()
from /usr/local/bin/mono
> #4
> 0x1e844f82e63b in
mono_get_runtime_build_info () from /usr/local/bin/mono
> #5
0x1e844f8964d7 in mono_main () from /usr/local/bin/mono
> #6
>
0x1e844f82dce1 in _start () from /usr/local/bin/mono
> #7
>
0x in ?? ()
>
> [1] https://github.com/NattyNarwhal/pledge.cs

Re: shm_unlink and pledge

[Theo Buehler]

On Sat, Apr 09, 2016 at 12:52:16PM +, Calvin wrote:
> Recently, I've created a pledge wrapper for C#. [1] I discovered that pledge
> seems to trigger on shared memory manipulations, which aren't mentioned in the
> man page for pledge. For example, Mono uses shared memory, which triggers
> pledge unless I add the "cpath" promise. (It also uses "vminfo," to check for
> boot time, but this seems fairly ays, should SHM operations be mentioned in 
> the man
> page, or is this a bug?

The pledge manual generally only lists the supported system calls, not
the library functions (with only a few exceptions). Not sure the shm_*
functions would qualify as they are practically unused in the base
system.

The shm_*(3) library functions should be supported by the appropriate
pledge promises (mostly filesystem manipulations). As is the case with
most other libc functions, you need to inspect them and see what system
calls they use internally. Your example: shm_unlink(3) calls unlink(2),
which, in turn, requires "cpath", so everything is as expected.

On the other hand, the shmat(2), shmdt(2), shmget(2) and shmctl(2)
system calls are not currently supported by pledge. As far as I know,
there are currently no plans of adding support for those. If they are
used, you need to make sure the pledge call comes after them.

Concerning the "vminfo" pledge: is it possible to fetch that value
and store it before you call pledge?

> A backtrace of Mono tripping up
> on exit without the promise:
> 
> (gdb) bt
> #0  0x196ea192113a in unlink () at
> :2
> #1  0x196ea18bf018 in shm_unlink (path=Variable "path" is not
> available.) at /usr/src/lib/libc/gen/shm_open.c:87
> #2  0x196bc332e085 in
> mono_shared_area_remove () from /usr/local/bin/mono
> #3  0x196ea191bcc7 in
> *_libc___cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:159
> #4
> 0x196ea191a07e in *_libc_exit (status=0) at
> /usr/src/lib/libc/stdlib/exit.c:57
> #5  0x196bc312dce8 in _start () from
> /usr/local/bin/mono
> #6  0x in ?? ()
> 
> Oh, and just in case, if
> you omit "vminfo" instead:
> 
> (gdb) bt
> #0  0x1e868df09eaa in sysctl () at
> :2
> #1  0x1e844fa302c0 in mono_free () from /usr/local/bin/mono
> #2
> 0x1e844f9deed0 in mono_gchandle_get_target () from /usr/local/bin/mono
> #3
> 0x1e844f9da27e in mono_runtime_cleanup () from /usr/local/bin/mono
> #4
> 0x1e844f82e63b in mono_get_runtime_build_info () from /usr/local/bin/mono
> #5  0x1e844f8964d7 in mono_main () from /usr/local/bin/mono
> #6
> 0x1e844f82dce1 in _start () from /usr/local/bin/mono
> #7
> 0x in ?? ()
> 
> [1] https://github.com/NattyNarwhal/pledge.cs

Re: MAC addresses on vmd guests

[Vijay Sankar]

  Thank you very much for the detailed explanation and of course for the
virtualization project.

Vijay

Quoting Mike Larkin :

> On Fri, Apr 08, 2016 at 05:45:12PM -0500, Vijay Sankar wrote:
>> Hi,
>>
>> I was trying to test patches for vmm and uvm by Stefan Kempf. Everything
>> works great and copies between the host and guest are faster with the
>> patches but I noticed the following.
>>
>> Whenever I reboot the VMM host (running OpenBSD 5.9 -current from
>> yesterday
>> with custom kernel enabled with vmm0 at mainbus0) the guest OS (OpenBSD
>> 5.9
>> -release) has a different MAC address for the same vio0 interface.
>>
>> Is this expected behavior? Reason for asking this is that if it is not
>> expected behavior then probably I may be doing all this incorrectly and
>> any
>> feedback from my tests would just be a time waste for developers. So
>> wanted
>> to avoid that if possible.
>
> Each interface in each VM receives a random MAC presently. There is
> provision
> in the virtio spec to provide a user-defined mac, but this has not been
> plumbed
> all the way down from vmctl (yet).
>
> Take a look at the very end of /usr/src/usr.sbin/vmd/virtio.c[1] for a
> place you
> could set your MAC if you wanted. The MAC address is part of
> vm_create_params,
> so you could, in theory plumb it down from vmctl with another option or
> parse
> flavor if you wanted.
>
> We have not done this yet because the interface specification command
line
> argument starts to look really ugly. I think reyk@ is contemplating a vm
> config
> file definition at some point to handle these extended parameters.
>
> Eg, we don't want something like this:
>
> vmctl start foo -c -k /bsd -i 2,11:22:33:44:55:66,77:88:99:AA:BB:CC
>
> ... although you could probably add that to vmctl in your own local tree
> without
> much hassle (I'm not interested in seeing that diff though as we have
> already
> discussed this and ruled it out).
>
> -ml
>
>> I am running dhcpd on the host and the lease file looks as follows. I
>> only
>> have one VM guest on this test system.
>>
>> builder.lab.foretell.ca$ cat /var/db/dhcpd.leases
>>  ??
>> lease 192.168.1.33 {
>> ?? starts 5 2016/04/08 21:09:17 UTC;
>> ?? ends 6 2016/04/09 09:09:17 UTC;
>> ?? hardware ethernet fe:e1:ba:d0:a6:73;
>> ?? uid 01:fe:e1:ba:d0:a6:73;
>> }
>> lease 192.168.1.32 {
>> ?? starts 5 2016/04/08 21:00:45 UTC;
>> ?? ends 6 2016/04/09 09:00:45 UTC;
>> ?? hardware ethernet fe:e1:ba:d0:40:32;
>> ?? uid 01:fe:e1:ba:d0:40:32;
>> }
>> lease 192.168.1.34 {
>> ?? starts 5 2016/04/08 21:11:55 UTC;
>> ?? ends 6 2016/04/09 09:11:55 UTC;
>> ?? hardware ethernet fe:e1:ba:d0:ee:a5;
>> ?? uid 01:fe:e1:ba:d0:ee:a5;
>> }
>>
>> lease 192.168.1.35 {
>> ?? starts 5 2016/04/08 21:49:46 UTC;
>> ?? ends 6 2016/04/09 09:49:46 UTC;
>> ?? hardware ethernet fe:e1:ba:d0:98:23;
>> ?? uid 01:fe:e1:ba:d0:98:23;
>> }
>>
>> DMESG from VMM HOST
>>
>> OpenBSD 5.9-current (GENERIC.MP) #0: Fri Apr?? 8 13:59:37 CDT 2016
>> ??
>> r...@builder.lab.foretell.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> real mem = 16806883328 (16028MB)
>> avail mem = 16293249024 (15538MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb410 (106 entries)
>> bios0: vendor American Megatrends Inc. version "0509" date 05/09/2012
>> bios0: ASUSTeK COMPUTER INC. P8H77-V LE
>> acpi0 at bios0: rev 2
>> acpi0: sleep states S0 S1 S3 S4 S5
>> acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT SSDT
>> acpi0: wakeup devices UAR1(S4) PS2K(S4) PS2M(S4) P0P1(S4) PXSX(S4)
>> RP01(S4)
>> PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) BR10(S4)
>> RP06(S4) PXSX(S4) [...]
>> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>> cpu0 at mainbus0: apid 0 (boot processor)
>> cpu0: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.50 MHz
>> cpu0:
>>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
>> cpu0: 256KB 64b/line 8-way L2 cache
>> cpu0: smt 0, core 0, package 0
>> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
>> cpu0: apic clock running at 102MHz
>> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
>> cpu1 at mainbus0: apid 2 (application processor)
>> cpu1: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.00 MHz
>> cpu1:
>>

Re: Recording computer sound.

[Henrique N. Lengler]

On Sat, Apr 09, 2016 at 01:18:11PM +0200, Alexandre Ratchov wrote:
> On Fri, Apr 08, 2016 at 07:09:59PM -0300, Henrique N. Lengler wrote:
> > Hi,
> > 
> > Is there a way to record the sound playing on my speakers?
> > Like duplicating it and saving on my computer everything that goes out to 
> > the
> > speaker.
> > 
> > I would like to to this to record some screencast.
> > 
> > Any way of doing this?
> > 
> 
> First you have to create a record-whay-you-hear device (aka
> monitoring), for instance add these options to /etc/rc.conf.local:
> 
> sndiod_flags=-s default -m play,mon -s mon
> 
> see -m and -s options in sndiod man page for more details.  Then,
> restart sndiod with:
> 
> rcctl restart sndiod
> 
> Then, use your favourite program to record audio and configure it
> to record from device "snd/0.mon".  Example:
> 
> aucat -f snd/0.mon -o file.wav
> 
> at this point whatever your system plays is recorded into file.wav.
> 
> HTH
> 

Thank you, that worked.

Henrique N. Lengler.

Re: MAC addresses on vmd guests

[Stefan Kempf]

Vijay Sankar wrote:
>   Hi,
> 
> I was trying to test patches for vmm and uvm by Stefan Kempf. Everything
> works great and copies between the host and guest are faster with the
> patches but I noticed the following.

thanks for testing!
 
> Whenever I reboot the VMM host (running OpenBSD 5.9 -current from yesterday
> with custom kernel enabled with vmm0 at mainbus0) the guest OS (OpenBSD 5.9
> -release) has a different MAC address for the same vio0 interface.
> 
> Is this expected behavior? Reason for asking this is that if it is not
> expected behavior then probably I may be doing all this incorrectly and any
> feedback from my tests would just be a time waste for developers. So wanted
> to avoid that if possible.

Yes, it's expected. vmd(8) does not yet support having the user define
the MAC address of a vio(4) interface. So vio(4) generates a random one.
 
> I am running dhcpd on the host and the lease file looks as follows. I only
> have one VM guest on this test system.
> 
> builder.lab.foretell.ca$ cat /var/db/dhcpd.leases
>  ??
> lease 192.168.1.33 {
> ?? starts 5 2016/04/08 21:09:17 UTC;
> ?? ends 6 2016/04/09 09:09:17 UTC;
> ?? hardware ethernet fe:e1:ba:d0:a6:73;
> ?? uid 01:fe:e1:ba:d0:a6:73;
> }
> lease 192.168.1.32 {
> ?? starts 5 2016/04/08 21:00:45 UTC;
> ?? ends 6 2016/04/09 09:00:45 UTC;
> ?? hardware ethernet fe:e1:ba:d0:40:32;
> ?? uid 01:fe:e1:ba:d0:40:32;
> }
> lease 192.168.1.34 {
> ?? starts 5 2016/04/08 21:11:55 UTC;
> ?? ends 6 2016/04/09 09:11:55 UTC;
> ?? hardware ethernet fe:e1:ba:d0:ee:a5;
> ?? uid 01:fe:e1:ba:d0:ee:a5;
> }
> 
> lease 192.168.1.35 {
> ?? starts 5 2016/04/08 21:49:46 UTC;
> ?? ends 6 2016/04/09 09:49:46 UTC;
> ?? hardware ethernet fe:e1:ba:d0:98:23;
> ?? uid 01:fe:e1:ba:d0:98:23;
> }
> 
> DMESG from VMM HOST
> 
> OpenBSD 5.9-current (GENERIC.MP) #0: Fri Apr?? 8 13:59:37 CDT 2016
> ??
> r...@builder.lab.foretell.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16806883328 (16028MB)
> avail mem = 16293249024 (15538MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb410 (106 entries)
> bios0: vendor American Megatrends Inc. version "0509" date 05/09/2012
> bios0: ASUSTeK COMPUTER INC. P8H77-V LE
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT SSDT
> acpi0: wakeup devices UAR1(S4) PS2K(S4) PS2M(S4) P0P1(S4) PXSX(S4) RP01(S4)
> PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) BR10(S4)
> RP06(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.50 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 102MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.00 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.00 MHz
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.00 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 1 (application processor)
> cpu4: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 

Re: OpenSMTPD on OpenBSD 5.9

[Edgar Pettijohn]

On 04/08/16 23:25, Rod Whitworth wrote:

I'm trying to replace Postfix with OpenSMTPD and I'm having a battle.

I don't seem to be able to get the clues to match the hardware and the
configure recipes that I need.

The most up to date I can find breaks at the second stanza and I can
guess that the instructions for configuring for PF are for OpenBSD 5.6
means that I should find a up to date have clue set.

Does anyone have pointer to a rescue?

Rod/
(who doesn't want to revert to Postfix..)

*** NOTE *** Please DO NOT CC me. I  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.

I think you may need to describe what you are trying to achieve. Perhaps 
your old postfix configuration as well.

Re: MAC addresses on vmd guests

[Mike Larkin]

On Fri, Apr 08, 2016 at 05:45:12PM -0500, Vijay Sankar wrote:
>   Hi,
> 
> I was trying to test patches for vmm and uvm by Stefan Kempf. Everything
> works great and copies between the host and guest are faster with the
> patches but I noticed the following.
> 
> Whenever I reboot the VMM host (running OpenBSD 5.9 -current from yesterday
> with custom kernel enabled with vmm0 at mainbus0) the guest OS (OpenBSD 5.9
> -release) has a different MAC address for the same vio0 interface.
> 
> Is this expected behavior? Reason for asking this is that if it is not
> expected behavior then probably I may be doing all this incorrectly and any
> feedback from my tests would just be a time waste for developers. So wanted
> to avoid that if possible.

Each interface in each VM receives a random MAC presently. There is provision
in the virtio spec to provide a user-defined mac, but this has not been plumbed
all the way down from vmctl (yet).

Take a look at the very end of /usr/src/usr.sbin/vmd/virtio.c for a place you
could set your MAC if you wanted. The MAC address is part of vm_create_params,
so you could, in theory plumb it down from vmctl with another option or parse
flavor if you wanted.

We have not done this yet because the interface specification command line
argument starts to look really ugly. I think reyk@ is contemplating a vm config
file definition at some point to handle these extended parameters.

Eg, we don't want something like this:

vmctl start foo -c -k /bsd -i 2,11:22:33:44:55:66,77:88:99:AA:BB:CC

... although you could probably add that to vmctl in your own local tree without
much hassle (I'm not interested in seeing that diff though as we have already 
discussed this and ruled it out).

-ml

> 
> I am running dhcpd on the host and the lease file looks as follows. I only
> have one VM guest on this test system.
> 
> builder.lab.foretell.ca$ cat /var/db/dhcpd.leases
>  ??
> lease 192.168.1.33 {
> ?? starts 5 2016/04/08 21:09:17 UTC;
> ?? ends 6 2016/04/09 09:09:17 UTC;
> ?? hardware ethernet fe:e1:ba:d0:a6:73;
> ?? uid 01:fe:e1:ba:d0:a6:73;
> }
> lease 192.168.1.32 {
> ?? starts 5 2016/04/08 21:00:45 UTC;
> ?? ends 6 2016/04/09 09:00:45 UTC;
> ?? hardware ethernet fe:e1:ba:d0:40:32;
> ?? uid 01:fe:e1:ba:d0:40:32;
> }
> lease 192.168.1.34 {
> ?? starts 5 2016/04/08 21:11:55 UTC;
> ?? ends 6 2016/04/09 09:11:55 UTC;
> ?? hardware ethernet fe:e1:ba:d0:ee:a5;
> ?? uid 01:fe:e1:ba:d0:ee:a5;
> }
> 
> lease 192.168.1.35 {
> ?? starts 5 2016/04/08 21:49:46 UTC;
> ?? ends 6 2016/04/09 09:49:46 UTC;
> ?? hardware ethernet fe:e1:ba:d0:98:23;
> ?? uid 01:fe:e1:ba:d0:98:23;
> }
> 
> DMESG from VMM HOST
> 
> OpenBSD 5.9-current (GENERIC.MP) #0: Fri Apr?? 8 13:59:37 CDT 2016
> ??
> r...@builder.lab.foretell.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16806883328 (16028MB)
> avail mem = 16293249024 (15538MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb410 (106 entries)
> bios0: vendor American Megatrends Inc. version "0509" date 05/09/2012
> bios0: ASUSTeK COMPUTER INC. P8H77-V LE
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT SSDT
> acpi0: wakeup devices UAR1(S4) PS2K(S4) PS2M(S4) P0P1(S4) PXSX(S4) RP01(S4)
> PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) BR10(S4)
> RP06(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.50 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 102MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.00 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.00 MHz
> cpu2:
> 

Re: What's the proper way to add a "link-local" route?

[Matthieu Herrb]

On Sat, Apr 09, 2016 at 10:16:51AM +0200, Jeremie Le Hen wrote:
> Hi,
>
> My interface has a /32 IP address and the gateway is .254.  Obviously I
> need to do something special with the routing table because the router
> is not accessible.
>
> Until 5.7 I used to add a direct route to the router and then add a
> default route as usual:
>
> # ifconfig em0 inet a.b.c.d/32
> # route add -llinfo -iface -host a.b.c.254 a.b.c.254 -ifp em0
> # route add dfault a.b.c.254
>
>
> Then it broke on 5.8 and I had to switch to:
>
> # ifconfig em0 inet a.b.c.d/32
> # route add -llinfo -iface -net default a.b.c.254 -ifp em0
>
>
> But on 5.9, boths setups don't work:
>
> # ping a.b.c.254
> PING a.b.c.254 (a.b.c.254): 56 data bytes
> ping: sendto: Invalid argument
> ping: wrote a.b.c.254 64 chars, ret=-1
>
>
> Can anyone advise the proper way to do this please?

This is broken in 5.9 indeed. You can either switch to -current or
apply this patch to 5.9 sources:
http://marc.inf½?l=openbsd-tech=145701234317330=2

--
Matthieu Herrb

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: ifconfig down but routing still tries to use the interface's routes

[Stuart Henderson]

On 2016-04-08, Doran Mori  wrote:
> I see what you're saying, but this is a router not a server. It's my job to
> stop the routing loop. That shorter prefix might actually work. This isn't
> how it works on other routers I've used.

It is routers not servers where the loop is *more* of a problem...

Re: MAC addresses on vmd guests

[Vijay Sankar]

Thank you very much.

Sent from my iPhone

> On Apr 9, 2016, at 08:21, Stefan Kempf  wrote:
>
> Vijay Sankar wrote:
>>  Hi,
>>
>> I was trying to test patches for vmm and uvm by Stefan Kempf. Everything
>> works great and copies between the host and guest are faster with the
>> patches but I noticed the following.
>
> thanks for testing!
>
>> Whenever I reboot the VMM host (running OpenBSD 5.9 -current from
yesterday
>> with custom kernel enabled with vmm0 at mainbus0) the guest OS (OpenBSD
5.9
>> -release) has a different MAC address for the same vio0 interface.
>>
>> Is this expected behavior? Reason for asking this is that if it is not
>> expected behavior then probably I may be doing all this incorrectly and
any
>> feedback from my tests would just be a time waste for developers. So
wanted
>> to avoid that if possible.
>
> Yes, it's expected. vmd(8) does not yet support having the user define
> the MAC address of a vio(4) interface. So vio(4) generates a random one.
>
>> I am running dhcpd on the host and the lease file looks as follows. I only
>> have one VM guest on this test system.
>>
>> builder.lab.foretell.ca$ cat /var/db/dhcpd.leases
>>  ??
>> lease 192.168.1.33 {
>> ?? starts 5 2016/04/08 21:09:17 UTC;
>> ?? ends 6 2016/04/09 09:09:17 UTC;
>> ?? hardware ethernet fe:e1:ba:d0:a6:73;
>> ?? uid 01:fe:e1:ba:d0:a6:73;
>> }
>> lease 192.168.1.32 {
>> ?? starts 5 2016/04/08 21:00:45 UTC;
>> ?? ends 6 2016/04/09 09:00:45 UTC;
>> ?? hardware ethernet fe:e1:ba:d0:40:32;
>> ?? uid 01:fe:e1:ba:d0:40:32;
>> }
>> lease 192.168.1.34 {
>> ?? starts 5 2016/04/08 21:11:55 UTC;
>> ?? ends 6 2016/04/09 09:11:55 UTC;
>> ?? hardware ethernet fe:e1:ba:d0:ee:a5;
>> ?? uid 01:fe:e1:ba:d0:ee:a5;
>> }
>>
>> lease 192.168.1.35 {
>> ?? starts 5 2016/04/08 21:49:46 UTC;
>> ?? ends 6 2016/04/09 09:49:46 UTC;
>> ?? hardware ethernet fe:e1:ba:d0:98:23;
>> ?? uid 01:fe:e1:ba:d0:98:23;
>> }
>>
>> DMESG from VMM HOST
>>
>> OpenBSD 5.9-current (GENERIC.MP) #0: Fri Apr?? 8 13:59:37 CDT 2016
>> ??
>> r...@builder.lab.foretell.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> real mem = 16806883328 (16028MB)
>> avail mem = 16293249024 (15538MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb410 (106 entries)
>> bios0: vendor American Megatrends Inc. version "0509" date 05/09/2012
>> bios0: ASUSTeK COMPUTER INC. P8H77-V LE
>> acpi0 at bios0: rev 2
>> acpi0: sleep states S0 S1 S3 S4 S5
>> acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT SSDT
>> acpi0: wakeup devices UAR1(S4) PS2K(S4) PS2M(S4) P0P1(S4) PXSX(S4)
RP01(S4)
>> PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) BR10(S4)
>> RP06(S4) PXSX(S4) [...]
>> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>> cpu0 at mainbus0: apid 0 (boot processor)
>> cpu0: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.50 MHz
>> cpu0:
>>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AV
X,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
>> cpu0: 256KB 64b/line 8-way L2 cache
>> cpu0: smt 0, core 0, package 0
>> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
>> cpu0: apic clock running at 102MHz
>> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
>> cpu1 at mainbus0: apid 2 (application processor)
>> cpu1: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.00 MHz
>> cpu1:
>>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AV
X,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
>> cpu1: 256KB 64b/line 8-way L2 cache
>> cpu1: smt 0, core 1, package 0
>> cpu2 at mainbus0: apid 4 (application processor)
>> cpu2: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.00 MHz
>> cpu2:
>>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AV
X,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
>> cpu2: 256KB 64b/line 8-way L2 cache
>> cpu2: smt 0, core 2, package 0
>> cpu3 at mainbus0: apid 6 (application processor)
>> cpu3: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.00 MHz
>> cpu3:
>>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX

shm_unlink and pledge

[Calvin]

Recently, I've created a pledge wrapper for C#. [1] I discovered that
pledge
seems to trigger on shared memory manipulations, which aren't
mentioned in the
man page for pledge. For example, Mono uses shared
memory, which triggers
pledge unless I add the "cpath" promise. (It
also uses "vminfo," to check for
boot time, but this seems fairly
expected.) Anyways, should SHM operations be
mentioned in the man
page, or is this a bug?

A backtrace of Mono tripping up
on exit without the promise:

(gdb) bt
#0  0x196ea192113a in unlink () at
:2
#1  0x196ea18bf018 in shm_unlink (path=Variable "path" is not
available.) at /usr/src/lib/libc/gen/shm_open.c:87
#2  0x196bc332e085 in
mono_shared_area_remove () from /usr/local/bin/mono
#3  0x196ea191bcc7 in
*_libc___cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:159
#4
0x196ea191a07e in *_libc_exit (status=0) at
/usr/src/lib/libc/stdlib/exit.c:57
#5  0x196bc312dce8 in _start () from
/usr/local/bin/mono
#6  0x in ?? ()

Oh, and just in case, if
you omit "vminfo" instead:

(gdb) bt
#0  0x1e868df09eaa in sysctl () at
:2
#1  0x1e844fa302c0 in mono_free () from /usr/local/bin/mono
#2
0x1e844f9deed0 in mono_gchandle_get_target () from /usr/local/bin/mono
#3
0x1e844f9da27e in mono_runtime_cleanup () from /usr/local/bin/mono
#4
0x1e844f82e63b in mono_get_runtime_build_info () from /usr/local/bin/mono
#5  0x1e844f8964d7 in mono_main () from /usr/local/bin/mono
#6
0x1e844f82dce1 in _start () from /usr/local/bin/mono
#7
0x in ?? ()

[1] https://github.com/NattyNarwhal/pledge.cs

Re: Several hardware issues on 13" MacBook Pro 2015

[Ulf Brosziewski]

Hi,

the hardware driver for your touchpad model isn't up-to-date yet.
I believe it's not much that's missing, so maybe it will be changed
soon.

On 04/09/2016 05:24 AM, Joe Schillinger wrote:
> Hi,
> 
> New OpenBSD user here, I decided to install OpenBSD 5.9 (now on -current) on 
> my MacBook this past week. Installation was smooth, but now I'm having a few 
> seemingly hardware-related issues.
> 
> Firstly, I'm experiencing some quite crippling graphical glitches in X11 that 
> make the system nearly unusable. Terminal windows (urxvt) are often missing 
> text, and windows will flash and just generally "glitch out". I realize this 
> description isn't probably too helpful, but I don't know how else to describe 
> it. Here are a couple pictures that I could capture of what's going on. I'm 
> using spectrwm, although these issues exist in other WM's as well (I tried 
> fvwm).
> https://u.teknik.io/Gapfb.png https://u.teknik.io/ckdGa.png 
> https://u.teknik.io/1Ji7K.png https://u.teknik.io/uJjQZ.png
> 
> Secondly, the audio from the speakers is tinny and quiet. I've tried changing 
> values in mixerctl with no success. I think it seems as though the bass 
> speakers aren't being used. The volume I'm getting while in OpenBSD seems to 
> be about half of what I'm able to get in OS X and Windows on the same machine.
> 
> Thirdly, this is probably a synaptics driver issue, but when I two-finger 
> scroll in an application like Chromium, and let go of my second finger, the 
> cursor will jump up about a quarter of the screen height. In general, the 
> cursor jumps around my screen an awful lot, and I've never had this problem 
> in the past.
> 
> I mention these issues only because I've not had them in either of the Linux 
> distros I've installed on here (Arch and CRUX). If there's any other 
> information I can provide, I'd love to help. I think OpenBSD is a wonderfully 
> designed system and I really would love to use it.
> 
> dmesg: http://sprunge.us/MAVR
> Xorg.0.log: http://sprunge.us/jgCH
> mixerctl: http://sprunge.us/JUCh
> 
> Thanks,
> Joe

Re: Recording computer sound.

[Alexandre Ratchov]

On Fri, Apr 08, 2016 at 07:09:59PM -0300, Henrique N. Lengler wrote:
> Hi,
> 
> Is there a way to record the sound playing on my speakers?
> Like duplicating it and saving on my computer everything that goes out to the
> speaker.
> 
> I would like to to this to record some screencast.
> 
> Any way of doing this?
> 

First you have to create a record-whay-you-hear device (aka
monitoring), for instance add these options to /etc/rc.conf.local:

sndiod_flags=-s default -m play,mon -s mon

see -m and -s options in sndiod man page for more details.  Then,
restart sndiod with:

rcctl restart sndiod

Then, use your favourite program to record audio and configure it
to record from device "snd/0.mon".  Example:

aucat -f snd/0.mon -o file.wav

at this point whatever your system plays is recorded into file.wav.

HTH

5.9, samsung nc 10, battery always full

[S V]

Hello,

I have fresh install of 5.9/i386 on netbook samsung NC10.

sysctl hw shows no changes in battery (always full). But I recall that in
old versions it shows usage.

How can I "debug"/"test" it and try to fix?

Thanks in advance.




-- 
Nerfur Dragon
-==(UDIC)==-

What's the proper way to add a "link-local" route?

[Jeremie Le Hen]

Hi,

My interface has a /32 IP address and the gateway is .254.  Obviously I
need to do something special with the routing table because the router
is not accessible.

Until 5.7 I used to add a direct route to the router and then add a
default route as usual:

# ifconfig em0 inet a.b.c.d/32
# route add -llinfo -iface -host a.b.c.254 a.b.c.254 -ifp em0
# route add dfault a.b.c.254


Then it broke on 5.8 and I had to switch to:

# ifconfig em0 inet a.b.c.d/32
# route add -llinfo -iface -net default a.b.c.254 -ifp em0


But on 5.9, boths setups don't work:

# ping a.b.c.254
PING a.b.c.254 (a.b.c.254): 56 data bytes
ping: sendto: Invalid argument
ping: wrote a.b.c.254 64 chars, ret=-1


Can anyone advise the proper way to do this please?
Thanks!
-- 
Jeremie Le Hen

My PIN is the last four digits of Pi.

Re: man pages diff

[Alexander Hall]

On April 7, 2016 10:40:24 PM GMT+02:00, Jason McIntyre  
wrote:
>On Thu, Apr 07, 2016 at 10:13:02PM +0200, Ingo Schwarze wrote:
>> Hi,
>> 
>> Jason McIntyre wrote on Thu, Apr 07, 2016 at 08:35:52PM +0100:
>> > On Thu, Apr 07, 2016 at 03:15:01PM -0400, Rob Pierce wrote:
>> 
>> >> Change "super user" to "superuser".
>> 
>> > hmm. you have the weight of the man pages behind you, since they
>> > overwhelmingly use "superuser".
>> 
>> In that case, ...
>> 
>> > the trouble is, i don;t think "super
>> > user" is wrong, and i'm reluctant to do this...
>> > 
>> > i've made changes like this before, when we have a real majority of
>> > spelling leading one way. but they always creep back in. i think we
>> > should just accept that we can spell things more than one way
>sometimes.
>> > 
>> > but then grep ;(
>> > 
>> > jmc, indecisive...
>> 
>>  ... just commit it, in particular when the work was already done.
>> 
>> Sure, it's not a big deal either way, and it doesn't do much harm
>> if a few spelling variants creep back in, no need to waste a lot
>> of time paying attention that they don't, but if we can improve
>> consistency almost for free, why not?
>> 
>> It can also help developers who look for spelling help in existing
>> pages if they find consistent usage.  That tends to reduce the time
>> spent trying to figure out whether there is a preferred form.  On
>> the other hand, consistency doesn't slow down people who don't care
>> as long as we don't yell at them.
>> 
>> Yours,
>>   Ingo
>> 
>
>hi.
>
>as far as i'm concerned, "super user" is not wrong. that's the rub. we
>have lots of alternate spellings in english, and i don;t see the point
>of trying to enforce one or the other. if they were spelled differently
>within the same page, then yes, fair enough.

I can't help comparing "superman" to "super man". It's a role or name which we 
seem to prefer - "the superuser" - rather than a great person with a login - "a 
super user". I'm sure the English language is flexible or ambiguous enough to 
prove me wrong, but that's my 2 cents anyway. 

/Alexander 

>
>for me, there's not a clear enough benefit to make the change. and i
>don;t like to somehow enforce spelling in a particular way.
>
>jmc
>
>> 
>> > > Index: src/share/man/man4/pty.4
>> > >
>===
>> > > RCS file: /cvs/src/share/man/man4/pty.4,v
>> > > retrieving revision 1.21
>> > > diff -u -p -r1.21 pty.4
>> > > --- src/share/man/man4/pty.4 21 Nov 2015 08:04:20 -  1.21
>> > > +++ src/share/man/man4/pty.4 7 Apr 2016 19:12:07 -
>> > > @@ -298,7 +298,7 @@ device nodes following the naming conven
>> > >  .Ox .
>> > >  Since
>> > >  .Pa ptm
>> > > -impersonates the super user for some operations it needs to
>perform
>> > > +impersonates the superuser for some operations it needs to
>perform
>> > >  to complete the allocation of a pseudo terminal, the
>> > >  .Pa /dev
>> > > -directory must also be writeable by the super user.
>> > > +directory must also be writeable by the superuser.
>> > > 
>> > > Index: src/share/man/man5/login.conf.5
>> > >
>===
>> > > RCS file: /cvs/src/share/man/man5/login.conf.5,v
>> > > retrieving revision 1.62
>> > > diff -u -p -r1.62 login.conf.5
>> > > --- src/share/man/man5/login.conf.5  30 Mar 2016 06:58:06
>-  1.62
>> > > +++ src/share/man/man5/login.conf.5  7 Apr 2016 19:12:07 -
>> > > @@ -683,7 +683,7 @@ to indicate if the user is in group whee
>> > >  Some authentication types require the user to be in group wheel
>when using
>> > >  the
>> > >  .Xr su 1
>> > > -program to become super user.
>> > > +program to become superuser.
>> > >  .El
>> > >  .Pp
>> > >  When the authentication program is executed,
>> > > 
>> > > Index: src/usr.sbin/cron/crontab.1
>> > >
>===
>> > > RCS file: /cvs/src/usr.sbin/cron/crontab.1,v
>> > > retrieving revision 1.33
>> > > diff -u -p -r1.33 crontab.1
>> > > --- src/usr.sbin/cron/crontab.1  26 Oct 2015 15:50:06 -  1.33
>> > > +++ src/usr.sbin/cron/crontab.1  7 Apr 2016 19:12:07 -
>> > > @@ -65,7 +65,7 @@ be listed in the
>> > >  .Pa /var/cron/cron.deny
>> > >  file in order to use
>> > >  .Nm .
>> > > -If neither of these files exists then only the super user
>> > > +If neither of these files exists then only the superuser
>> > >  will be allowed to use
>> > >  .Nm .
>> > >  .Em NOTE :