Re: Building electron on OpenBSD

[Dave Cohen]

I haven't built those projects specifically, but I've had luck building Go 
projects on OpenBSD.

I recommend building Go from source.  It's quite straightforward.  On OpenBSD 
5.9, you can install Go from ports, then use that to bootstrap the latest 1.7.3 
version.  I leave the ports version intact, and set $GOROOT to the copy I've 
built from source.

Again, I haven't built projects you link to.  But I think those projects are 
the place to ask, rather than OpenBSD mailing lists.  They would likely be able 
to tell you how to get around the errors you encounter, if any.

-Dave

On Wed, Nov 2, 2016, at 04:46 PM, Ax0n wrote:
> In talking to some folks at SpiderOak few months ago, their technical
> co-founder said that the ability to get Go 1.6+ and Electron working on
> OpenBSD are the major technical hurdles to getting Semaphor (which is a
> privacy-friendly, security-minded collaborative platform one might compare
> to Slack or HipChat) running on our favorite operating system. 

Re: Is 6.1 expected to happen soon?

[Claus Reheis]

Thank you and all the people involved in OpenBSD development for 
providing me with a system I can trust and rely on!


I am running OpenBSD Current since a few months without any major issues 
on my desktop



Greetings

rehcla

On 11/04/16 01:32, Theo de Raadt wrote:

Aren't the snapshots running fairly well vetted code anyway - only
using code that's been accepted into the source tree?  Obviously not
as well vetted as the -STABLE and -RELEASE, of course.

Snapshots are generated as fast as we can, from what is commited.

What gets commited may contain errors.  It happens.  We keep an
eye out to fix those errors and move on.

They also contain features.  Features mail contain errors.  Read
the previous sentence.

It is best effort, but 20 years of best effort has produced something
kind of cool -- and a big piece is that people run snapshots and find
bugs early after commit while developers are fresh, so they can be
fixed.

It is a healthy feedback loop.  Not unique to OpenBSD, but it is the
fundamental component that drives quality in open source projects --
if both sides care about quality.

Not all our users need to be part of this feedback loop, but it is
healthy when there are enough people taking part.  Enough is an
unquantifiable number.  If bugs get found by snapshot users, it is
working.  When they don't find bugs, we don't know if there are too
few bugs or too few snapshot users.

Re: Oddness with pkg_add

[trondd]

On Thu, November 3, 2016 9:52 pm, Chris Huxtable wrote:
> Nothing funky with users in pf. I have tried to strip my pf.conf way back
> in
> an attempt to remove possible issues
> but that hasnâ**t improved anything. I filter by interface, ip, and port,
> thats all (so far).
>
> Nothing odd in dmesg. What really has me for a loop is why does everything
> work except this one program.
>
> # cat /etc/doas.conf
> permit nopass root as _pkgfetch
>
> # doas -u _pkgfetch host ftp.openbsd.org
> ftp.openbsd.org is an alias for openbsd.sunsite.ualberta.ca.
> openbsd.sunsite.ualberta.ca has address 129.128.5.191
>
> This is interestingâ*¦ I donâ**t really know where to go with this though.
> Any
> suggestions?
>
> # doas -u _pkgfetch ftp -o /tmp/text.html
> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
> ftp: ftp.openbsd.org: no address associated with name
>

Try substituting the IP for the hostname.  Is it just DNS that's the
problem or all network connectivity?

Then I'd start using tcpdump...


>> On Nov 3, 2016, at 9:26 PM, trondd  wrote:
>>
>> On Thu, November 3, 2016 9:19 pm, trondd wrote:
>>> On Thu, November 3, 2016 9:07 pm, Chris Huxtable wrote:
 Same as before unfortunately.

 # pkg_add -v nano
 Error from http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
 ftp: ftp.openbsd.org: no address associated with name
 http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/ is empty
 Error from
 http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/
 ftp: openbsd.cs.toronto.edu: no address associated with name
 http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/ is empty
 Error from
 http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/
 ftp: athena.caslab.queensu.ca: no address associated with name
 http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/ is
 empty
 Can't find nano

 Could this be a pledge issue?

>>>
>>> Check dmesg, but on a clean install, probably not.
>>>
>>> Are you doing something funky with pf, like only allowing certain users
>>> internet access?  pkg_add downloads as the _pfetch user.  Try doas -u
>>> _pfetch host ftp.openbsd.org
>>>
>>
>> Correction:  6.0 changed the user to _pkgfetch.

Re: Oddness with pkg_add

[Chris Huxtable]

Nothing funky with users in pf. I have tried to strip my pf.conf way back in
an attempt to remove possible issues
but that hasn’t improved anything. I filter by interface, ip, and port,
thats all (so far).

Nothing odd in dmesg. What really has me for a loop is why does everything
work except this one program.

# cat /etc/doas.conf
permit nopass root as _pkgfetch

# doas -u _pkgfetch host ftp.openbsd.org
ftp.openbsd.org is an alias for openbsd.sunsite.ualberta.ca.
openbsd.sunsite.ualberta.ca has address 129.128.5.191

This is interesting… I don’t really know where to go with this though. Any
suggestions?

# doas -u _pkgfetch ftp -o /tmp/text.html
http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
ftp: ftp.openbsd.org: no address associated with name

> On Nov 3, 2016, at 9:26 PM, trondd  wrote:
>
> On Thu, November 3, 2016 9:19 pm, trondd wrote:
>> On Thu, November 3, 2016 9:07 pm, Chris Huxtable wrote:
>>> Same as before unfortunately.
>>>
>>> # pkg_add -v nano
>>> Error from http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
>>> ftp: ftp.openbsd.org: no address associated with name
>>> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/ is empty
>>> Error from http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/
>>> ftp: openbsd.cs.toronto.edu: no address associated with name
>>> http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/ is empty
>>> Error from
>>> http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/
>>> ftp: athena.caslab.queensu.ca: no address associated with name
>>> http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/ is empty
>>> Can't find nano
>>>
>>> Could this be a pledge issue?
>>>
>>
>> Check dmesg, but on a clean install, probably not.
>>
>> Are you doing something funky with pf, like only allowing certain users
>> internet access?  pkg_add downloads as the _pfetch user.  Try doas -u
>> _pfetch host ftp.openbsd.org
>>
>
> Correction:  6.0 changed the user to _pkgfetch.

Re: Is 6.1 expected to happen soon?

[Theo de Raadt]

> >>Aren't the snapshots running fairly well vetted code anyway - only
> >>using code that's been accepted into the source tree?  Obviously not
> >>as well vetted as the -STABLE and -RELEASE, of course.
> > 
> > Snapshots are generated as fast as we can, from what is commited.
> 
> Doesn't uncommitted code occasionally find its way into snapshots?

Randomly, rarely and sporatically.

A selection of stuff that is benign but subtle, and stuff that is
subtle and non-benign.  Generally in the kernel, so it runs of crashes.

We need to learn somehow.  Sometimes the commit-pullout-recommit-
pullout-recommit-pullout-recommit-pullout-recommit-pullout-recommit
process is too costly.  Want to help shortcut?  Run snapshots?

Afraid of that?  Don't worry, it happens randomly, rarely and
sporatically and you likely won't get hit except 1 round of builds.
Someone will hit it first, we hope.

Otherwise run releases, and don't participate in the process that
makes the next release better.  We ask for a bit of snapshot use, but
you get to make your own choices.

Re: Oddness with pkg_add

[trondd]

On Thu, November 3, 2016 9:19 pm, trondd wrote:
> On Thu, November 3, 2016 9:07 pm, Chris Huxtable wrote:
>> Same as before unfortunately.
>>
>> # pkg_add -v nano
>> Error from http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
>> ftp: ftp.openbsd.org: no address associated with name
>> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/ is empty
>> Error from http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/
>> ftp: openbsd.cs.toronto.edu: no address associated with name
>> http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/ is empty
>> Error from
>> http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/
>> ftp: athena.caslab.queensu.ca: no address associated with name
>> http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/ is empty
>> Can't find nano
>>
>> Could this be a pledge issue?
>>
>
> Check dmesg, but on a clean install, probably not.
>
> Are you doing something funky with pf, like only allowing certain users
> internet access?  pkg_add downloads as the _pfetch user.  Try doas -u
> _pfetch host ftp.openbsd.org
>

Correction:  6.0 changed the user to _pkgfetch.

Re: Is 6.1 expected to happen soon?

[Ax0n]

My advice: If you really want the performance boost and you think a recent
snapshot will provide it, make sure your backups are good and test the
snapshot on comparable hardware as best you can. I usually restore the dump
to a similar system, then boot from a snapshot bsd.rd and choose "Upgrade",
and if it works fine, then do the same upgrade in the production
environment. If it doesn't work right, troubleshoot it and file a bug
report, or wait a few days and try another snapshot. Or both. Whenever I've
had to do this in prod or on a system I rely on daily, I tend to stick with
that one working snapshot unless something gets strange.

You can jump back from your mid-cycle snapshot to -RELEASE when 6.1 becomes
available (presuming the changes you want are included in the release), and
then, track -STABLE with cvs, manual patches from errata or use M:Tier's
openup script.


On Thu, Nov 3, 2016 at 8:01 PM,  wrote:

> >>Aren't the snapshots running fairly well vetted code anyway - only
> >>using code that's been accepted into the source tree?  Obviously not
> >>as well vetted as the -STABLE and -RELEASE, of course.
> >
> > Snapshots are generated as fast as we can, from what is commited.
>
> Doesn't uncommitted code occasionally find its way into snapshots?
>
> sl

Re: Oddness with pkg_add

[trondd]

On Thu, November 3, 2016 9:07 pm, Chris Huxtable wrote:
> Same as before unfortunately.
>
> # pkg_add -v nano
> Error from http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
> ftp: ftp.openbsd.org: no address associated with name
> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/ is empty
> Error from http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/
> ftp: openbsd.cs.toronto.edu: no address associated with name
> http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/ is empty
> Error from http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/
> ftp: athena.caslab.queensu.ca: no address associated with name
> http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/ is empty
> Can't find nano
>
> Could this be a pledge issue?
>

Check dmesg, but on a clean install, probably not.

Are you doing something funky with pf, like only allowing certain users
internet access?  pkg_add downloads as the _pfetch user.  Try doas -u
_pfetch host ftp.openbsd.org

Re: Oddness with pkg_add

[Chris Huxtable]

Same as before unfortunately.

# pkg_add -v nano
Error from http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
ftp: ftp.openbsd.org: no address associated with name
http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/ is empty
Error from http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/
ftp: openbsd.cs.toronto.edu: no address associated with name
http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/ is empty
Error from http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/
ftp: athena.caslab.queensu.ca: no address associated with name
http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/ is empty
Can't find nano

Could this be a pledge issue?

> On Nov 3, 2016, at 9:01 PM, Ax0n  wrote:
>
> That config looks completely rational. Perhaps add -v (or -vv .. -v) to
get more and more verbose error messages and see if something useful pops up
in the verbose output.
>
> On Thu, Nov 3, 2016 at 3:19 PM, Chris Huxtable mailto:ch...@huxtable.ca>> wrote:
> # cat /etc/pkg.conf
> installpath = http://ftp.openbsd.org/%m/ 
> installpath += http://openbsd.cs.toronto.edu/%m/

> installpath += http://athena.caslab.queensu.ca/%m/

>
> # echo $PKG_PATH
>
> PKG_PATH is empty as I use pkg.conf
>
>> On Nov 3, 2016, at 3:43 PM, Ax0n mailto:a...@h-i-r.net>>
wrote:
>>
>> Can we see the contents of /etc/pkg.conf and/or your $PKG_PATH variable
from inside root's session?
>>
>> On Wed, Nov 2, 2016 at 6:48 PM, Chris Huxtable mailto:ch...@huxtable.ca>> wrote:
>> OpenBSD Community,
>>
>> I upgraded my OpenBSD router from 5.9 to 6.0 by clean install and copied a
>> number of my old configs to the new install. I have almost everything in a
>> working state except one program, pkg_add. I have tried to sort this out,
done
>> another clean install, reviewed all my configs, and reached the end of my
>> understanding. Below are tests I have preformed and their output and
configs I
>> think may be relevant.
>>
>> # pkg_add nano
>> Error from http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/

>> ftp: ftp.openbsd.org : no address associated with
name
>> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
 is empty
>> Error from http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/

>> ftp: openbsd.cs.toronto.edu : no address
associated with name
>> http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/
 is empty
>> Error from http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/

>> ftp: athena.caslab.queensu.ca : no
address associated with name
>> http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/
 is empty
>> Can't find nano
>>
>> $ uname -a
>> OpenBSD xyz.abc.def 6.0 GENERIC.MP#2319  amd64
>>
>> $ host ftp.openbsd.org 
>> ftp.openbsd.org  is an alias for
openbsd.sunsite.ualberta.ca .
>> openbsd.sunsite.ualberta.ca  has
address 129.128.5.191
>>
>> $ dig ftp.openbsd.com 
>> […]
>> ;; ANSWER SECTION:
>> ftp.openbsd.com .21599   IN  CNAME
openbsd.sunsite.ualberta.ca .
>> openbsd.sunsite.ualberta.ca . 21599 IN
A   129.128.5.191
>>
>> ;; Query time: 789 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> […]
>>
>> $ ping -c 1 google.com 
>> PING google.com  (172.217.0.174): 56 data bytes
>> 64 bytes from 172.217.0.174 : icmp_seq=0 ttl=59
time=5.488 ms
>> --- google.com  ping statistics ---
>> 1 packets transmitted, 1 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 5.488/5.488/5.488/0.000 ms
>>
>> $ cat /etc/resolv.conf
>> search abc.def ghi.jkl mno.pqr
>> nameserver 127.0.0.1
>> nameserver 8.8.8.8
>> nameserver 8.8.4.4
>> lookup bind file
>>
>> $ cat /etc/hostname.pppoe0
>> inet 0.0.0.0 255.255.255.255 NONE \
>> pppoedev em1 authproto pap \
>> authname 'thisIsNotMyAuthName' authkey 'thisIsNotMyAuthKey' up
>> dest 0.0.0.1
>>
>> group egress
>>
>> !/sbin/route add default -ifp pppoe0 0.0.0.1
>>
>> $ cat /etc/hostname.em1
>> group egress
>>
>> up
>>
>> $ ftp -o /tmp/test.html
>> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/

>> Trying 129.128.5.

Re: Oddness with pkg_add

[Ax0n]

That config looks completely rational. Perhaps add -v (or -vv .. -v) to
get more and more verbose error messages and see if something useful pops
up in the verbose output.

On Thu, Nov 3, 2016 at 3:19 PM, Chris Huxtable  wrote:

> # cat /etc/pkg.conf
> installpath = http://ftp.openbsd.org/%m/
> installpath += http://openbsd.cs.toronto.edu/%m/
> installpath += http://athena.caslab.queensu.ca/%m/
>
> # echo $PKG_PATH
>
> PKG_PATH is empty as I use pkg.conf
>
> On Nov 3, 2016, at 3:43 PM, Ax0n  wrote:
>
> Can we see the contents of /etc/pkg.conf and/or your $PKG_PATH variable
> from inside root's session?
>
> On Wed, Nov 2, 2016 at 6:48 PM, Chris Huxtable  wrote:
>
>> OpenBSD Community,
>>
>> I upgraded my OpenBSD router from 5.9 to 6.0 by clean install and copied a
>> number of my old configs to the new install. I have almost everything in a
>> working state except one program, pkg_add. I have tried to sort this out,
>> done
>> another clean install, reviewed all my configs, and reached the end of my
>> understanding. Below are tests I have preformed and their output and
>> configs I
>> think may be relevant.
>>
>> # pkg_add nano
>> Error from http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
>> ftp: ftp.openbsd.org: no address associated with name
>> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/ is empty
>> Error from http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/
>> ftp: openbsd.cs.toronto.edu: no address associated with name
>> http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/ is empty
>> Error from http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd
>> 64/
>> ftp: athena.caslab.queensu.ca: no address associated with name
>> http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/ is empty
>> Can't find nano
>>
>> $ uname -a
>> OpenBSD xyz.abc.def 6.0 GENERIC.MP#2319  amd64
>>
>> $ host ftp.openbsd.org
>> ftp.openbsd.org is an alias for openbsd.sunsite.ualberta.ca.
>> openbsd.sunsite.ualberta.ca has address 129.128.5.191
>>
>> $ dig ftp.openbsd.com
>> […]
>> ;; ANSWER SECTION:
>> ftp.openbsd.com.21599   IN  CNAME
>> openbsd.sunsite.ualberta.ca.
>> openbsd.sunsite.ualberta.ca. 21599 IN   A   129.128.5.191
>>
>> ;; Query time: 789 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> […]
>>
>> $ ping -c 1 google.com
>> PING google.com (172.217.0.174): 56 data bytes
>> 64 bytes from 172.217.0.174: icmp_seq=0 ttl=59 time=5.488 ms
>> --- google.com ping statistics ---
>> 1 packets transmitted, 1 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 5.488/5.488/5.488/0.000 ms
>>
>> $ cat /etc/resolv.conf
>> search abc.def ghi.jkl mno.pqr
>> nameserver 127.0.0.1
>> nameserver 8.8.8.8
>> nameserver 8.8.4.4
>> lookup bind file
>>
>> $ cat /etc/hostname.pppoe0
>> inet 0.0.0.0 255.255.255.255 NONE \
>> pppoedev em1 authproto pap \
>> authname 'thisIsNotMyAuthName' authkey 'thisIsNotMyAuthKey' up
>> dest 0.0.0.1
>>
>> group egress
>>
>> !/sbin/route add default -ifp pppoe0 0.0.0.1
>>
>> $ cat /etc/hostname.em1
>> group egress
>>
>> up
>>
>> $ ftp -o /tmp/test.html
>> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
>> Trying 129.128.5.191...
>> Requesting http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
>> 100% |**|  1171 KB
>> 00:02
>> 1199135 bytes received in 2.65 seconds (441.42 KB/s)
>>
>>
>> Would anyone have insight as to why everything works except pkg_add? Any
>> help
>> would be appreciated.
>>
>> Regards,
>>
>> Chris

Re: Is 6.1 expected to happen soon?

[sl]

>>Aren't the snapshots running fairly well vetted code anyway - only
>>using code that's been accepted into the source tree?  Obviously not
>>as well vetted as the -STABLE and -RELEASE, of course.
> 
> Snapshots are generated as fast as we can, from what is commited.

Doesn't uncommitted code occasionally find its way into snapshots?

sl

Re: Is 6.1 expected to happen soon?

[Theo de Raadt]

>Aren't the snapshots running fairly well vetted code anyway - only
>using code that's been accepted into the source tree?  Obviously not
>as well vetted as the -STABLE and -RELEASE, of course.

Snapshots are generated as fast as we can, from what is commited.

What gets commited may contain errors.  It happens.  We keep an
eye out to fix those errors and move on.

They also contain features.  Features mail contain errors.  Read
the previous sentence.

It is best effort, but 20 years of best effort has produced something
kind of cool -- and a big piece is that people run snapshots and find
bugs early after commit while developers are fresh, so they can be
fixed.

It is a healthy feedback loop.  Not unique to OpenBSD, but it is the
fundamental component that drives quality in open source projects --
if both sides care about quality.

Not all our users need to be part of this feedback loop, but it is
healthy when there are enough people taking part.  Enough is an
unquantifiable number.  If bugs get found by snapshot users, it is
working.  When they don't find bugs, we don't know if there are too
few bugs or too few snapshot users.

Re: Is 6.1 expected to happen soon?

[Aaron Mason]

Aren't the snapshots running fairly well vetted code anyway - only
using code that's been accepted into the source tree?  Obviously not
as well vetted as the -STABLE and -RELEASE, of course.

On Fri, Nov 4, 2016 at 1:01 AM, Peter N. M. Hansteen  wrote:
> On Thu, Nov 03, 2016 at 01:56:09AM -0400, alexmcwhir...@triadic.us wrote:
>> I know, it'll happen when it happens...
>>
>> I have a few servers that could really use the updated SMP stuff that
>> -current has. For some applications it's a night and day difference, but I'm
>> not all to comfortable running -current on production machines. I'm just
>> trying to gauge whether or not i should hold out a bit longer or just bite
>> the bullet and test some snapshots. With 6.0 being released in September i
>> am not sure if i should expect 6.1 any time soon.
>
> For most of the project's history, it has followed the six month release cycle
> quite consistently, with some deviations when absolutely necessary (such as
> the events that lead to PF being written), but generally releases have been
> dated May 1st or November 1st.
>
> As far as I know no schedule has been published for upcoming releases, but I
> would speculate that the six month cycle is quite well embedded in the 
> developers'
> lives and will be the norm going forward.  That said, the ongoing SMP work is
> one of those things that could have tentacles that have to be dealt with 
> during
> a slightly longer timespan than the ordinary six month cycle.
>
> Do keep in mind that it's only early November - if the project had stuck to
> the ordinary release schedule, we would only have had 6.0-release since the 
> day
> before yesterday. Come May (or possibly earlier) we'll know for sure how 
> closely
> the 6.1 release will stick to the established schedule.
>
> In the meantime, there are worse things knowledgeable OpenBSD users can do 
> with
> their time than trying out snapshots to get the feel for how development is
> progressing.
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>



-- 
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse

Re: npppd troubles

[Marina Brown]

On 11/03/2016 03:36 PM, Stefan Sperling wrote:
> On Thu, Nov 03, 2016 at 03:17:40PM -0400, Marina Brown wrote:
>> Hi All:
>>
>> I have been trying to create an nppp connection across my property -
>> about 100M for one of my friends who lives here. He wants less security
>> than i like behind my firewall. I have not been able to get OpenBSD to
>> route his connection out of the network. Here are my settings.
> 
>> # NAT Rule to translate from internal to External NET
>> pass out on em0 inet from em1:network to any nat-to (em0)
> 
> You're using NAT when passing out on em0 here, and...
>  
>> external = em0
> 
>> pass out quick on $external from 10.0.0.103/32 to any
> 
> ... my guess is that you're missing 'nat-to ($external)' here ^
> 

Thanks - is there a way to exclude the npppd users from the nat
altogether. That is the reason for the excersize. If i put him
behind the nat we are right where we started. He runs games that
don't play well with strict NAT settings and i don't want the rest of my
network exposed to reduced security.

I thought he would be on pppx0. Is there a way to do this.


--- Marina Brown




signature.asc
Description: OpenPGP digital signature

Re: vmm: panic: root filesystem has size 0

[Patrik Lundin]

On Thu, Nov 03, 2016 at 04:02:50PM -0400, trondd wrote:
> 
> You actually have to install OpenBSD into that image.  Try -k /bsd.rd first.
> 

Ahh, so obvious in retrospect, thank you!

-- 
Patrik Lundin

Re: Oddness with pkg_add

[Chris Huxtable]

# cat /etc/pkg.conf
installpath = http://ftp.openbsd.org/%m/
installpath += http://openbsd.cs.toronto.edu/%m/
installpath += http://athena.caslab.queensu.ca/%m/

# echo $PKG_PATH

PKG_PATH is empty as I use pkg.conf

> On Nov 3, 2016, at 3:43 PM, Ax0n  wrote:
>
> Can we see the contents of /etc/pkg.conf and/or your $PKG_PATH variable from
inside root's session?
>
> On Wed, Nov 2, 2016 at 6:48 PM, Chris Huxtable mailto:ch...@huxtable.ca>> wrote:
> OpenBSD Community,
>
> I upgraded my OpenBSD router from 5.9 to 6.0 by clean install and copied a
> number of my old configs to the new install. I have almost everything in a
> working state except one program, pkg_add. I have tried to sort this out,
done
> another clean install, reviewed all my configs, and reached the end of my
> understanding. Below are tests I have preformed and their output and configs
I
> think may be relevant.
>
> # pkg_add nano
> Error from http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/

> ftp: ftp.openbsd.org : no address associated with
name
> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
 is empty
> Error from http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/

> ftp: openbsd.cs.toronto.edu : no address
associated with name
> http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/
 is empty
> Error from http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/

> ftp: athena.caslab.queensu.ca : no address
associated with name
> http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/
 is empty
> Can't find nano
>
> $ uname -a
> OpenBSD xyz.abc.def 6.0 GENERIC.MP#2319  amd64
>
> $ host ftp.openbsd.org 
> ftp.openbsd.org  is an alias for
openbsd.sunsite.ualberta.ca .
> openbsd.sunsite.ualberta.ca  has
address 129.128.5.191
>
> $ dig ftp.openbsd.com 
> […]
> ;; ANSWER SECTION:
> ftp.openbsd.com .21599   IN  CNAME
openbsd.sunsite.ualberta.ca .
> openbsd.sunsite.ualberta.ca . 21599 IN
A   129.128.5.191
>
> ;; Query time: 789 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> […]
>
> $ ping -c 1 google.com 
> PING google.com  (172.217.0.174): 56 data bytes
> 64 bytes from 172.217.0.174 : icmp_seq=0 ttl=59
time=5.488 ms
> --- google.com  ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 5.488/5.488/5.488/0.000 ms
>
> $ cat /etc/resolv.conf
> search abc.def ghi.jkl mno.pqr
> nameserver 127.0.0.1
> nameserver 8.8.8.8
> nameserver 8.8.4.4
> lookup bind file
>
> $ cat /etc/hostname.pppoe0
> inet 0.0.0.0 255.255.255.255 NONE \
> pppoedev em1 authproto pap \
> authname 'thisIsNotMyAuthName' authkey 'thisIsNotMyAuthKey' up
> dest 0.0.0.1
>
> group egress
>
> !/sbin/route add default -ifp pppoe0 0.0.0.1
>
> $ cat /etc/hostname.em1
> group egress
>
> up
>
> $ ftp -o /tmp/test.html
> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/

> Trying 129.128.5.191...
> Requesting http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/

> 100% |**|  1171 KB00:02
> 1199135 bytes received in 2.65 seconds (441.42 KB/s)
>
>
> Would anyone have insight as to why everything works except pkg_add? Any
help
> would be appreciated.
>
> Regards,
>
> Chris

Re: vmm: panic: root filesystem has size 0

[trondd]

On Thu, November 3, 2016 3:45 pm, Patrik Lundin wrote:
> Hello,
>
> I am trying to start a VMM guest based on the example commands in vmctl(8)
> without luck. The guest is panicking like so:
> ===
> panic: root filesystem has size 0
> ===
>
> Here are the commands I use:
> ===
> # vmctl create disk.img -s 4.5G
> vmctl: imagefile created
>
> # ls -lh disk.img
> -rw---  1 root  wheel   4.5G Nov  3 20:24 disk.img
>
> # vmctl start "myvm" -m 512M -i 1 -d disk.img -k /bsd -c
> Connected to /dev/ttyp4 (speed 9600)


You actually have to install OpenBSD into that image.  Try -k /bsd.rd first.


>
> [ using 1220352 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2016 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
>
> OpenBSD 6.0-current (GENERIC.MP) #0: Wed Nov  2 18:41:56 MDT 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 520093696 (496MB)
> avail mem = 499834880 (476MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0
> acpi at bios0 not configured
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2493.68 MHz
> cpu0:
> FPU,VME,DE,PSE,MSR,PAE,MCE,CX8,SEP,PGE,MCA,CMOV,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV
> cpu0: smt 0, core 0, package 0
> pvbus0 at mainbus0: OpenBSD
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "OpenBSD VMM PCI Host Bridge" rev 0x00
> virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00
> viornd0 at virtio0
> virtio0: irq 3
> virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00
> vioblk0 at virtio1
> scsibus1 at vioblk0: 2 targets
> sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct
> fixed
> sd0: 4608MB, 512 bytes/sector, 9437184 sectors
> virtio1: irq 5
> virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
> vio0 at virtio2: address fe:e1:bb:d1:84:90
> virtio2: irq 7
> isa0 at mainbus0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns8250, no fifo
> com0: console
> vmm disabled by firmware
> vmm at mainbus0 not configured
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> root on sd0a swap on sd0b dump on sd0b
> panic: root filesystem has size 0
> Stopped at  Debugger+0x9:   leave
>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> *0  0  0 0x1  0x2000  swapper
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> dk_mountroot() at dk_mountroot+0xf6
> main() at main+0x56e
> end trace frame: 0x0, count: 11
> https://www.openbsd.org/ddb.html describes the minimum info required in
> bug
> reports.  Insufficient info makes it difficult to find and fix bugs.
> ddb{0}>
> ===
>
> Output of vmd -dvvv when this happens:
> ===
> # vmd -dvvv
> startup
> failed to open /etc/vm.conf: No such file or directory
> vm_priv_ifconfig: interface tap0 description vm1-if0-myvm
> myvm: started vm 14 successfully, tty /dev/ttyp4
> run_vm: initializing hardware for vm myvm
> run_vm: starting vcpu threads for vm myvm
> vcpu_reset: resetting vcpu 0 for vm 14
> run_vm: waiting on events for VM myvm
> i8253_reset: unsupported counter mode 0xe
> vmd: unknown exit reason 48
> ===
>
> I notice the man-page runs "vmctl create" as an unspecified unprivileged
> user so I have tried doing "chown _vmd:_vmd disk.img", placing disk.img
> in "/home/vm" also owned by _vmd. I still get the same panic however.
>
> Complete dmesg of the host system in case it is interesting:
> ===
> OpenBSD 6.0-current (GENERIC.MP) #0: Wed Nov  2 18:41:56 MDT 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> RTC BIOS diagnostic error 80
> real mem = 4156157952 (3963MB)
> avail mem = 4025647104 (3839MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (67 entries)
> bios0: vendor LENOVO version "8DET63WW (1.33 )" date 07/19/2012
> bios0: LENOVO 429137G
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA
> SSDT SSDT UEFI UEFI UEFI
> acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4)
> EHC1(S3) EHC2(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.32 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,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

vmm: panic: root filesystem has size 0

[Patrik Lundin]

Hello,

I am trying to start a VMM guest based on the example commands in vmctl(8)
without luck. The guest is panicking like so:
===
panic: root filesystem has size 0
===

Here are the commands I use:
===
# vmctl create disk.img -s 4.5G
vmctl: imagefile created

# ls -lh disk.img
-rw---  1 root  wheel   4.5G Nov  3 20:24 disk.img

# vmctl start "myvm" -m 512M -i 1 -d disk.img -k /bsd -c
Connected to /dev/ttyp4 (speed 9600)

[ using 1220352 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2016 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.0-current (GENERIC.MP) #0: Wed Nov  2 18:41:56 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 520093696 (496MB)
avail mem = 499834880 (476MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2493.68 MHz
cpu0: 
FPU,VME,DE,PSE,MSR,PAE,MCE,CX8,SEP,PGE,MCA,CMOV,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV
cpu0: smt 0, core 0, package 0
pvbus0 at mainbus0: OpenBSD
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "OpenBSD VMM PCI Host Bridge" rev 0x00
virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00
viornd0 at virtio0
virtio0: irq 3
virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio1
scsibus1 at vioblk0: 2 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 4608MB, 512 bytes/sector, 9437184 sectors
virtio1: irq 5
virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio2: address fe:e1:bb:d1:84:90
virtio2: irq 7
isa0 at mainbus0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns8250, no fifo
com0: console
vmm disabled by firmware
vmm at mainbus0 not configured
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a swap on sd0b dump on sd0b
panic: root filesystem has size 0
Stopped at  Debugger+0x9:   leave
   TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
*0  0  0 0x1  0x2000  swapper
Debugger() at Debugger+0x9
panic() at panic+0xfe
dk_mountroot() at dk_mountroot+0xf6
main() at main+0x56e
end trace frame: 0x0, count: 11
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
ddb{0}>
===

Output of vmd -dvvv when this happens:
===
# vmd -dvvv
startup
failed to open /etc/vm.conf: No such file or directory
vm_priv_ifconfig: interface tap0 description vm1-if0-myvm
myvm: started vm 14 successfully, tty /dev/ttyp4
run_vm: initializing hardware for vm myvm
run_vm: starting vcpu threads for vm myvm
vcpu_reset: resetting vcpu 0 for vm 14
run_vm: waiting on events for VM myvm
i8253_reset: unsupported counter mode 0xe
vmd: unknown exit reason 48
===

I notice the man-page runs "vmctl create" as an unspecified unprivileged
user so I have tried doing "chown _vmd:_vmd disk.img", placing disk.img
in "/home/vm" also owned by _vmd. I still get the same panic however.

Complete dmesg of the host system in case it is interesting:
===
OpenBSD 6.0-current (GENERIC.MP) #0: Wed Nov  2 18:41:56 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 4156157952 (3963MB)
avail mem = 4025647104 (3839MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (67 entries)
bios0: vendor LENOVO version "8DET63WW (1.33 )" date 07/19/2012
bios0: LENOVO 429137G
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT 
SSDT UEFI UEFI UEFI
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) 
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.32 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,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 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 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,HT

Re: Oddness with pkg_add

[Ax0n]

Can we see the contents of /etc/pkg.conf and/or your $PKG_PATH variable
from inside root's session?

On Wed, Nov 2, 2016 at 6:48 PM, Chris Huxtable  wrote:

> OpenBSD Community,
>
> I upgraded my OpenBSD router from 5.9 to 6.0 by clean install and copied a
> number of my old configs to the new install. I have almost everything in a
> working state except one program, pkg_add. I have tried to sort this out,
> done
> another clean install, reviewed all my configs, and reached the end of my
> understanding. Below are tests I have preformed and their output and
> configs I
> think may be relevant.
>
> # pkg_add nano
> Error from http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
> ftp: ftp.openbsd.org: no address associated with name
> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/ is empty
> Error from http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/
> ftp: openbsd.cs.toronto.edu: no address associated with name
> http://openbsd.cs.toronto.edu/pub/OpenBSD/6.0/packages/amd64/ is empty
> Error from http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/
> ftp: athena.caslab.queensu.ca: no address associated with name
> http://athena.caslab.queensu.ca/pub/OpenBSD/6.0/packages/amd64/ is empty
> Can't find nano
>
> $ uname -a
> OpenBSD xyz.abc.def 6.0 GENERIC.MP#2319 amd64
>
> $ host ftp.openbsd.org
> ftp.openbsd.org is an alias for openbsd.sunsite.ualberta.ca.
> openbsd.sunsite.ualberta.ca has address 129.128.5.191
>
> $ dig ftp.openbsd.com
> […]
> ;; ANSWER SECTION:
> ftp.openbsd.com.21599   IN  CNAME
> openbsd.sunsite.ualberta.ca.
> openbsd.sunsite.ualberta.ca. 21599 IN   A   129.128.5.191
>
> ;; Query time: 789 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> […]
>
> $ ping -c 1 google.com
> PING google.com (172.217.0.174): 56 data bytes
> 64 bytes from 172.217.0.174: icmp_seq=0 ttl=59 time=5.488 ms
> --- google.com ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 5.488/5.488/5.488/0.000 ms
>
> $ cat /etc/resolv.conf
> search abc.def ghi.jkl mno.pqr
> nameserver 127.0.0.1
> nameserver 8.8.8.8
> nameserver 8.8.4.4
> lookup bind file
>
> $ cat /etc/hostname.pppoe0
> inet 0.0.0.0 255.255.255.255 NONE \
> pppoedev em1 authproto pap \
> authname 'thisIsNotMyAuthName' authkey 'thisIsNotMyAuthKey' up
> dest 0.0.0.1
>
> group egress
>
> !/sbin/route add default -ifp pppoe0 0.0.0.1
>
> $ cat /etc/hostname.em1
> group egress
>
> up
>
> $ ftp -o /tmp/test.html
> http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
> Trying 129.128.5.191...
> Requesting http://ftp.openbsd.org/pub/OpenBSD/6.0/packages/amd64/
> 100% |**|  1171 KB
> 00:02
> 1199135 bytes received in 2.65 seconds (441.42 KB/s)
>
>
> Would anyone have insight as to why everything works except pkg_add? Any
> help
> would be appreciated.
>
> Regards,
>
> Chris

Re: npppd troubles

[Stefan Sperling]

On Thu, Nov 03, 2016 at 03:17:40PM -0400, Marina Brown wrote:
> Hi All:
> 
> I have been trying to create an nppp connection across my property -
> about 100M for one of my friends who lives here. He wants less security
> than i like behind my firewall. I have not been able to get OpenBSD to
> route his connection out of the network. Here are my settings.

> # NAT Rule to translate from internal to External NET
> pass out on em0 inet from em1:network to any nat-to (em0)

You're using NAT when passing out on em0 here, and...
 
> external = em0

> pass out quick on $external from 10.0.0.103/32 to any

... my guess is that you're missing 'nat-to ($external)' here ^

npppd troubles

[Marina Brown]

Hi All:

I have been trying to create an nppp connection across my property -
about 100M for one of my friends who lives here. He wants less security
than i like behind my firewall. I have not been able to get OpenBSD to
route his connection out of the network. Here are my settings.


# uname -a
OpenBSD bernie.mesh.local 6.0 GENERIC.MP#2319 amd64


-

# $OpenBSD: npppd.conf,v 1.2 2014/03/22 04:32:39 yasuoka Exp $
# sample npppd configuration file.  see npppd.conf(5)

tunnel L2TP protocol l2tp
tunnel PPTP protocol pptp
tunnel PPPOE protocol pppoe {
listen on interface em1
}

ipcp IPCP {
pool-address 10.0.0.2-10.0.0.254
dns-servers 208.67.222.222 8.8.8.8
}
interface tun0 address 10.0.0.1 ipcp IPCP
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
bind tunnel from L2TP authenticated by LOCAL to tun0
bind tunnel from PPTP authenticated by LOCAL to tun0
bind tunnel from PPPOE authenticated by LOCAL to tun0

---

---
# more /etc/npppd/npppd

npppd-users  npppd.conf   npppd.conf.OLD
# more /etc/npppd/npppd-users

# $OpenBSD: npppd-users,v 1.1 2012/09/20 12:51:43 yasuoka Exp $
# sample npppd-users file.  see npppd-users(5)

#taro:\
#   :password=taro's password:\
#   :framed-ip-address=10.0.0.101:
#hana:\
#   :password=hana's password:\
#   :framed-ip-address=10.0.0.102:
kevin:\
:password=XX:\
:framed-ip-address=10.0.0.103:
laura:\
:password=testvpn:\
:framed-ip-address=10.0.0.104:
#
---

# npppctl session all

Ppp Id = 33
  Ppp Id  : 33
  Username: kevin
  Realm Name  : LOCAL
  Concentrated Interface  : tun0
  Assigned IPv4 Address   : 10.0.0.103
  Tunnel Protocol : PPPoE
  Tunnel From : 74:44:01:7a:13:e7
  Start Time  : 2016/11/03 12:53:59
  Elapsed Time: 3149 sec (52 minutes)
  Input Bytes : 69314 (67.7 KB)
  Input Packets   : 1986
  Input Errors: 1056 (34.7%)
  Output Bytes: 13021 (12.7 KB)
  Output Packets  : 1100
  Output Errors   : 0 (0.0%)
#
--
# route show
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio
Iface
defaultc-73-114-67-1.hsd1 UGS  432 27284883 - 8
em0
BASE-ADDRESS.MCAST localhost  URS0  205 32768 8
lo0
10.0.0.128/26  localhost  UGB00 3276856
lo0
10.0.0.64/26   localhost  UGB00 3276856
lo0
10.0.0.192/27  localhost  UGB00 3276856
lo0
10.0.0.32/27   localhost  UGB0   14 3276856
lo0
10.0.0.8/29localhost  UGB01 3276856
lo0
10.0.0.4/30localhost  UGB0   20 3276856
lo0
10.0.0.2/31localhost  UGB00 3276856
lo0
10.0.0.1   tun0   UHl1   45 - 1
tun0
10.0.0.1/3210.0.0.1   UC 00 - 4
tun0
10.0.0.1   localhost  UGH00 3276856
lo0
10.0.0.16/28   localhost  UGB00 3276856
lo0
10.0.0.103 10.0.0.1   UGH0   55  149256
tun0
10.0.0.224/28  localhost  UGB00 3276856
lo0
10.0.0.240/29  localhost  UGB00 3276856
lo0
10.0.0.248/30  localhost  UGB00 3276856
lo0
10.0.0.252/31  localhost  UGB00 3276856
lo0
10.0.0.254/32  localhost  UGB00 3276856
lo0
73.114.67/24   c-73-114-67-57.hsd UC 10 - 4
em0
c-73-114-67-1.hsd1 00:5f:86:93:c4:22  UHLc   1  225 - 4
em0
c-73-114-67-57.hsd 00:00:24:d2:16:e0  UHLl   0   396542 - 1
em0
73.114.67.255  c-73-114-67-57.hsd UHb00 - 1
em0
loopback   localhost  UGRS   00 32768 8
lo0
localhost  localhost  UHl   15   15 32768 1
lo0
192.168.1/24   apache UC 6  749 - 4
em1
apache 00:00:24:d2:16:e1  UHLl   0   137387 - 1
em1
192.168.1.15   40:8d:5c:18:94:22  UHLc   0  2505472 - 4
em1
192.168.1.22   40:8d:5c:83:01:16  UHLc   1  4272213 - 4
em1
192.168.1.29   d0:50:99:7c:c7:95  UHLc   3  4213308 - 4
em1
192.168.1.51   90:6e:bb:03:3e:ff  UHLc   0   466079 - 4
em1
192.168.1.56   10:1f:74:5e:8b:67  UHLc   0 1173 - 4
em1
192.168.1.126  4c:cc:6a:09:fd:14  UHLc   0  4434626 - 4
em1
192.168.1.255  apache UHb0  

Re: Attach EBS volume on aws OpenBSD instance

[Mike Belopuhov]

On 1 November 2016 at 16:46, zack  wrote:
> Hi,
>
> I'm running OpenBsd 6.0 instance on AWS using the public AMI. Attached
> EBS volume as /dev/xvda as i found in previous discussion, but it don't
> seems to get detected on the instance, nothing shows up on dmesg nor i
> can't find the new device. How does this attached volume appear on the
> instance?
>
> Thanks
> Zack
>

Hi Zack,

If the volume that you're attaching is not the one you're booting
from, then it won't appear on the instance at all because all
non-boot volumes are attached as paravirtualized disk interfaces
for which we lack driver support.  Right now we're limited to a
single volume but you may add additional BSD disk labels and/or
growfs existing filesystems.  I plan to add support for
paravirtualized disk interfaces, but don't have time to do it
right now.

Cheers,
Mike

Re: Is 6.1 expected to happen soon?

[Peter N. M. Hansteen]

On Thu, Nov 03, 2016 at 01:56:09AM -0400, alexmcwhir...@triadic.us wrote:
> I know, it'll happen when it happens...
> 
> I have a few servers that could really use the updated SMP stuff that
> -current has. For some applications it's a night and day difference, but I'm
> not all to comfortable running -current on production machines. I'm just
> trying to gauge whether or not i should hold out a bit longer or just bite
> the bullet and test some snapshots. With 6.0 being released in September i
> am not sure if i should expect 6.1 any time soon.

For most of the project's history, it has followed the six month release cycle
quite consistently, with some deviations when absolutely necessary (such as 
the events that lead to PF being written), but generally releases have been
dated May 1st or November 1st. 

As far as I know no schedule has been published for upcoming releases, but I
would speculate that the six month cycle is quite well embedded in the 
developers'
lives and will be the norm going forward.  That said, the ongoing SMP work is
one of those things that could have tentacles that have to be dealt with during
a slightly longer timespan than the ordinary six month cycle. 

Do keep in mind that it's only early November - if the project had stuck to
the ordinary release schedule, we would only have had 6.0-release since the day
before yesterday. Come May (or possibly earlier) we'll know for sure how closely
the 6.1 release will stick to the established schedule.

In the meantime, there are worse things knowledgeable OpenBSD users can do with
their time than trying out snapshots to get the feel for how development is
progressing.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Is 6.1 expected to happen soon?

[Joseph Pumphrey]

Warning: Feckless opining

This is one of the nicer things about OpennBSD from a syadmin perspective.
The release cycle is predictable, and while you may not get a feature you
want from the core utils in the n+1 next release you can be sure that any
new features have been dogfooded thoroughly and are reasonably well-vetted.
Rather than waiting 3-5 years for a "Feature" release and hoping they had
time test all those weird and wonderful new things they are trying to make
their system do.

On Nov 3, 2016 08:45, "Özgür Kazancci"  wrote:

> +1
>
> On Thu, Nov 3, 2016 at 8:56 AM,  wrote:
>
> > I know, it'll happen when it happens...
> >
> > I have a few servers that could really use the updated SMP stuff that
> > -current has. For some applications it's a night and day difference, but
> > I'm not all to comfortable running -current on production machines. I'm
> > just trying to gauge whether or not i should hold out a bit longer or
> just
> > bite the bullet and test some snapshots. With 6.0 being released in
> > September i am not sure if i should expect 6.1 any time soon.

Re: Is 6.1 expected to happen soon?

[ludovic coues]

If you need a rough estimate, you can add 6 months to the date of the
last release.

2016-11-03 6:56 GMT+01:00  :
> I know, it'll happen when it happens...
>
> I have a few servers that could really use the updated SMP stuff that
> -current has. For some applications it's a night and day difference, but I'm
> not all to comfortable running -current on production machines. I'm just
> trying to gauge whether or not i should hold out a bit longer or just bite
> the bullet and test some snapshots. With 6.0 being released in September i
> am not sure if i should expect 6.1 any time soon.
>



-- 

Cordialement, Coues Ludovic
+336 148 743 42