Re: How to handle different sections with new man.conf?

[Theo de Raadt]

> > > there must be a way to call tcl85 and tcl86 something else than both
> > > "Tcl" right?  Meaning maybe also seek ways to reconcile these in Tcl
> > > land & potentially other multiple versions environments.  W/ regards,
> > > please excuse me, if this is out of line or just plain inappropriate.  
> > 
> > I don't think renaming stuff in ports would be wise.  It would cause
> > a considerable maintenance burden for the port maintainer, and
> > having stuff renamed to something differing from upstream might
> > also surprise people who only use one single version.
> 
> I agree completely, thank you for enumerating these consequences as well.
> I presumed it'd be offsetting to add the question of branching & version
> numbering of software (programming languages most frequently), ending up
> in various cuts (as the "maintained" releases).  Still I wanted to query
> your stance on the version names in relation to manual pages, as this is
> where it all ends (and just begins depending on view point, introductory
> approach, development methods).  Thanks for considering this byway point.

That's a lot of talk for

"Wow, you are suggesting I should do the work, but I my only
 skill is to post to misc, and wow, that feels too much like
 a call".

End of story.

Please shut up "lists".  Everyone tires of your well articulated
agenda pushes.

Re: Audio quality

[Theo de Raadt]

> Just thought I would take a moment to appreciate the OpenBSD audio
> subsystem. I don't know if it is just me, but instead of using my
> phone to listen to Youtube I plugged the headphones into my desktop
> machine. It's a small PC with an older model Atom processor and
> Realtek ALC887 on the board. Headphones are ~$10 from Monoprice.
> 
> Good Lord, it sounds fantastic.

It is pretty good.  Surprising integration.  There are a few problems
with MUTE buttons on some laptops, in particular some generations of
thinkpads.  But on the whole, a surprisingly small subsystem that
operates quite well with the weak realtime gaurantees of OpenBSD.

Audio quality

[Pavan Maddamsetti]

Hey,

Just thought I would take a moment to appreciate the OpenBSD audio
subsystem. I don't know if it is just me, but instead of using my
phone to listen to Youtube I plugged the headphones into my desktop
machine. It's a small PC with an older model Atom processor and
Realtek ALC887 on the board. Headphones are ~$10 from Monoprice.

Good Lord, it sounds fantastic.

Re: How to handle different sections with new man.conf?

[lists]

Fri, 1 Jul 2016 22:59:16 +0200 Ingo Schwarze 
> Hi Andy,
> 
> >>> Using OpenBSD 5.8-stable.
> >>> 
> >>> I used to have the following in /etc/man.conf:
> >>> 
> >>> tcl85   /usr/local/lib/tcl/tcl8.5/man/
> >>> tcl86   /usr/local/lib/tcl/tcl8.6/man/
> >>> 
> >>> Which made it easy to view one or the other by using the section
> >>> argument:
> >>> 
> >>> man tcl85 Tcl
> >>> man tcl86 Tcl
> >>> 
> >>> man(1) still appears to be documented to have this functionality:
> >>> 
> >>>  man [-acfhklw] [-C file] [-I os=name] [-K encoding] [-M path] [-m path]
> >>>  [-O option=value] [-S subsection] [-s section] [-T output] [-W level]
> >>>  [section] name ...
> >>>  ^
> >>> 
> >>> But I see no  way of expressing it in the new  man.conf or addressing it
> >>> in the  command line.  Here is what  I have added  according to  the new
> >>> man.conf(5):
> >>> 
> >>> manpath /usr/local/lib/tcl/tcl8.5/man
> >>> manpath /usr/local/lib/tcl/tcl8.6/man  
> 
> That's not necessarily a good idea; it adds both directories to the
> default search path, so you may end up seeing Tcl documentation
> when looking for something completely different.  Then again, nothing
> wrong with that if you do indeed want to have both Tcl dirs searched
> by default...
> 
> >>> But I don't see how to use [section] anymore. man(1) does mention using
> >>> [-s section] with n as the section, but that only seems to display the
> >>> first match of tcl8.5 and does not allow further granularity (as far as
> >>> I can tell).
> >>> 
> >>> Have I missed something in the man pages, or what am I doing wrong?  
> 
> >> i don;t think it's currently possible to do exactly what you propose.
> >> i think ingo stripped man.conf pretty bare.  
> 
> Correct.
> 
> In my 2015 BSDCan talk, i offered to implement, in man.conf(5),
> 
>   alias aliasname dirname
> 
> such that for example
> 
>   alias tcl85 /usr/local/lib/tcl/tcl8.5/man
> 
> would allow saying
> 
>   man -M tcl85 Tcl
> 
> But i also said:
> 
>   "So far, there is no noticeable demand -> KISS."
> 
> That is still true a year later, and personally, i consider
> shell aliases a very good solution, not merely a workaround.
> 
> All the same, if enough people want the feature, in particular if
> somebody can present a compelling argument why shell aliases are
> not a good solution, i'm still willing to implement it.
> 
> >> the workarounds would be:
> >> 
> >> - have multiple conf files and use man -C to get the one you want
> >> - use man -m on the command line (or aliases) to get what you want  
> 
> That's what i recommend.  For example:
> 
>   alias man85="man -M /usr/local/lib/tcl/tcl8.5/man"
> 
> That doesn't even require editing /etc/man.conf,
> and it can be used like this:
> 
>$ man85 -k search
>   Tcl_GetEncodingSearchPath(3) - Tcl_GetEncodingSearchPath
>   Tcl_SetEncodingSearchPath(3) - Tcl_SetEncodingSearchPath
>   lsearch(n) - lsearch
>$ man85 lsearch
>   lsearch(n)  Tcl Built-In Commands lsearch(n)
>   [...]
> 
> >> i think man(1) is currently wrong regarding the section values in -s
> >> (i'll look into that).  
> 
> That was just fixed.
> 
> > The multiple configuration files is one working approach to multiple
> > work directory invocation, and these can coexist.  Then more over so,
> > there must be a way to call tcl85 and tcl86 something else than both
> > "Tcl" right?  Meaning maybe also seek ways to reconcile these in Tcl
> > land & potentially other multiple versions environments.  W/ regards,
> > please excuse me, if this is out of line or just plain inappropriate.  
> 
> I don't think renaming stuff in ports would be wise.  It would cause
> a considerable maintenance burden for the port maintainer, and
> having stuff renamed to something differing from upstream might
> also surprise people who only use one single version.

I agree completely, thank you for enumerating these consequences as well.
I presumed it'd be offsetting to add the question of branching & version
numbering of software (programming languages most frequently), ending up
in various cuts (as the "maintained" releases).  Still I wanted to query
your stance on the version names in relation to manual pages, as this is
where it all ends (and just begins depending on view point, introductory
approach, development methods).  Thanks for considering this byway point.

> Having manual pages of the same name is not a problem as long as they
> live in different manpath trees.
> 
> Yours,
>   Ingo

Re: Issue with numbers of pty

[Stuart Henderson]

On 2016-07-01, Gabriel N  wrote:
> Open pty´s without limits is something I hope a long time ago. I use Authpf
> for securing a large network and need to overcome the limit of 992 ptys . I
> refuse to use FreeBSD to overcome this limit .

See PermitTTY in sshd_config(5).

Re: support update

[Ingo Schwarze]

Hi Todd,

Todd M. Kover wrote on Sat, Jun 25, 2016 at 05:19:56PM -0400:

> 0
> C USA
> P VA
> T Purcellville
> Z 20132
> O Omniscient Technologies
> I Todd M. Kover
> A 36051 Birch Hollow Lane
> M openbsd-consult...@omniscient.com
> U http://www.omniscient.com/
> B +1-540-668-7602
> NWashington D.C. based consulting group with a broad array of experience in
> *BSD, Solaris, Linux and many other varieties of unix specializing in
> highly scalable systems, systems integration and network security.
> Custom application design also available.

Committed.
  Ingo

Re: How to handle different sections with new man.conf?

[Ingo Schwarze]

Hi Andy,

li...@wrant.com wrote on Sun, Jun 26, 2016 at 01:50:34PM +0300:
> Jason McIntyre wrote: 
>> Andy Bradford wrote:

>>> Using OpenBSD 5.8-stable.
>>> 
>>> I used to have the following in /etc/man.conf:
>>> 
>>> tcl85   /usr/local/lib/tcl/tcl8.5/man/
>>> tcl86   /usr/local/lib/tcl/tcl8.6/man/
>>> 
>>> Which made it easy to view one or the other by using the section
>>> argument:
>>> 
>>> man tcl85 Tcl
>>> man tcl86 Tcl
>>> 
>>> man(1) still appears to be documented to have this functionality:
>>> 
>>>  man [-acfhklw] [-C file] [-I os=name] [-K encoding] [-M path] [-m path]
>>>  [-O option=value] [-S subsection] [-s section] [-T output] [-W level]
>>>  [section] name ...
>>>  ^
>>> 
>>> But I see no  way of expressing it in the new  man.conf or addressing it
>>> in the  command line.  Here is what  I have added  according to  the new
>>> man.conf(5):
>>> 
>>> manpath /usr/local/lib/tcl/tcl8.5/man
>>> manpath /usr/local/lib/tcl/tcl8.6/man

That's not necessarily a good idea; it adds both directories to the
default search path, so you may end up seeing Tcl documentation
when looking for something completely different.  Then again, nothing
wrong with that if you do indeed want to have both Tcl dirs searched
by default...

>>> But I don't see how to use [section] anymore. man(1) does mention using
>>> [-s section] with n as the section, but that only seems to display the
>>> first match of tcl8.5 and does not allow further granularity (as far as
>>> I can tell).
>>> 
>>> Have I missed something in the man pages, or what am I doing wrong?

>> i don;t think it's currently possible to do exactly what you propose.
>> i think ingo stripped man.conf pretty bare.

Correct.

In my 2015 BSDCan talk, i offered to implement, in man.conf(5),

  alias aliasname dirname

such that for example

  alias tcl85 /usr/local/lib/tcl/tcl8.5/man

would allow saying

  man -M tcl85 Tcl

But i also said:

  "So far, there is no noticeable demand -> KISS."

That is still true a year later, and personally, i consider
shell aliases a very good solution, not merely a workaround.

All the same, if enough people want the feature, in particular if
somebody can present a compelling argument why shell aliases are
not a good solution, i'm still willing to implement it.

>> the workarounds would be:
>> 
>> - have multiple conf files and use man -C to get the one you want
>> - use man -m on the command line (or aliases) to get what you want

That's what i recommend.  For example:

  alias man85="man -M /usr/local/lib/tcl/tcl8.5/man"

That doesn't even require editing /etc/man.conf,
and it can be used like this:

   $ man85 -k search
  Tcl_GetEncodingSearchPath(3) - Tcl_GetEncodingSearchPath
  Tcl_SetEncodingSearchPath(3) - Tcl_SetEncodingSearchPath
  lsearch(n) - lsearch
   $ man85 lsearch
  lsearch(n)  Tcl Built-In Commands lsearch(n)
  [...]

>> i think man(1) is currently wrong regarding the section values in -s
>> (i'll look into that).

That was just fixed.

> The multiple configuration files is one working approach to multiple
> work directory invocation, and these can coexist.  Then more over so,
> there must be a way to call tcl85 and tcl86 something else than both
> "Tcl" right?  Meaning maybe also seek ways to reconcile these in Tcl
> land & potentially other multiple versions environments.  W/ regards,
> please excuse me, if this is out of line or just plain inappropriate.

I don't think renaming stuff in ports would be wise.  It would cause
a considerable maintenance burden for the port maintainer, and
having stuff renamed to something differing from upstream might
also surprise people who only use one single version.  Having manual
pages of the same name is not a problem as long as they live in
different manpath trees.

Yours,
  Ingo

Re: Issue with numbers of pty

[Gabriel N .]

Theo de Raadt  cvs.openbsd.org> writes:

> 
> > Todd C. Miller wrote:
> > > On Fri, 01 Jul 2016 10:50:24 -0400, "Ted Unangst" wrote:
> > > 
> > > > Stuart Henderson wrote:
> > > > > On 2016-06-30, Oriol Demaria  the-grid.xyz> wrote:
> > > > > > Trying tmuxinator here I have noticed that I ran out of pty,
according
> > > > > > to man pty(4) there is a kernel parameter specifiying the max
> > > > > > number. I'm running a snapshot from last Friday, and I don't seem to
> > > > > > have kern.tty.maxptys.
> > > > > 
> > > > > You probably just ran out of device nodes, the default (62) is a
bit small
> > > > > for some uses (often exhibited as not being able to open new
xterms), but y
> > > > ou
> > > > > can create more like this:
> > > > > 
> > > > > cd /dev
> > > > > sh MAKEDEV pty1
> > > > 
> > > > This shouldn't be a problem for software using openpty().
> > > 
> > > I don't think that is correct.  You still need to device nodes in
> > > /dev to exist.  Otherwise, the PTMGET ioctl will fail.
> > 
> > oh, my bad. I thought ptm would create the pty nodes as needed, but
apparently
> > not.
> 
> That would be a little strange.  Even just thinking of the first special case
> (chroot) makes me feel uneasy.
> 
> 

Open pty´s without limits is something I hope a long time ago. I use Authpf
for securing a large network and need to overcome the limit of 992 ptys . I
refuse to use FreeBSD to overcome this limit .
Thank you.

Re: I am not sure if it is a problem with OpenBSD's httpd

[C. L. Martinez]

On Fri  1.Jul'16 at 16:21:27 +, Stuart Henderson wrote:
> On 2016-07-01, C. L. Martinez  wrote:
> >  Recently, I have installed an OpenBSD virtual machine in my laptop with 
> > TT-RSS, and all works perfectlly. Until I try to subscribe to a new feed. 
> > Every time, tt-rss returns the error "6 Couldn't resolve host". It is 
> > strange, because all other feeds migrated from other linux host, works ok.
> 
> It might be this, which used to be in faq 10 but was removed a while ago:
> 
> << Name Resolution: httpd(8) inside the chroot(2) will NOT be able to
> use the system /etc/hosts or /etc/resolv.conf. Therefore, if you have
> applications which require name resolution, you will need to populate
> /var/www/etc/hosts and/or /var/www/etc/resolv.conf in the chroot(2)
> environment. Note that some applications expect the resolution of
> "localhost" to work. >>
> 

It was!! .. Perfect, now it works. Many thanks Stuart

-- 
Greetings,
C. L. Martinez

Re: I am not sure if it is a problem with OpenBSD's httpd

[Kamil Cholewiński]

Oh my god, just realised TTRSS is a self-hosted web app... makes sense,
Stuart is right - it must be the chroot...

Re: I am not sure if it is a problem with OpenBSD's httpd

[Stuart Henderson]

On 2016-07-01, C. L. Martinez  wrote:
>  Recently, I have installed an OpenBSD virtual machine in my laptop with 
> TT-RSS, and all works perfectlly. Until I try to subscribe to a new feed. 
> Every time, tt-rss returns the error "6 Couldn't resolve host". It is 
> strange, because all other feeds migrated from other linux host, works ok.

It might be this, which used to be in faq 10 but was removed a while ago:

<< Name Resolution: httpd(8) inside the chroot(2) will NOT be able to
use the system /etc/hosts or /etc/resolv.conf. Therefore, if you have
applications which require name resolution, you will need to populate
/var/www/etc/hosts and/or /var/www/etc/resolv.conf in the chroot(2)
environment. Note that some applications expect the resolution of
"localhost" to work. >>

Re: Issue with numbers of pty

[Theo de Raadt]

> Todd C. Miller wrote:
> > On Fri, 01 Jul 2016 10:50:24 -0400, "Ted Unangst" wrote:
> > 
> > > Stuart Henderson wrote:
> > > > On 2016-06-30, Oriol Demaria  wrote:
> > > > > Trying tmuxinator here I have noticed that I ran out of pty, according
> > > > > to man pty(4) there is a kernel parameter specifiying the max
> > > > > number. I'm running a snapshot from last Friday, and I don't seem to
> > > > > have kern.tty.maxptys.
> > > > 
> > > > You probably just ran out of device nodes, the default (62) is a bit 
> > > > small
> > > > for some uses (often exhibited as not being able to open new xterms), 
> > > > but y
> > > ou
> > > > can create more like this:
> > > > 
> > > > cd /dev
> > > > sh MAKEDEV pty1
> > > 
> > > This shouldn't be a problem for software using openpty().
> > 
> > I don't think that is correct.  You still need to device nodes in
> > /dev to exist.  Otherwise, the PTMGET ioctl will fail.
> 
> oh, my bad. I thought ptm would create the pty nodes as needed, but apparently
> not.

That would be a little strange.  Even just thinking of the first special case
(chroot) makes me feel uneasy.

Re: Issue with numbers of pty

[Ted Unangst]

Todd C. Miller wrote:
> On Fri, 01 Jul 2016 10:50:24 -0400, "Ted Unangst" wrote:
> 
> > Stuart Henderson wrote:
> > > On 2016-06-30, Oriol Demaria  wrote:
> > > > Trying tmuxinator here I have noticed that I ran out of pty, according
> > > > to man pty(4) there is a kernel parameter specifiying the max
> > > > number. I'm running a snapshot from last Friday, and I don't seem to
> > > > have kern.tty.maxptys.
> > > 
> > > You probably just ran out of device nodes, the default (62) is a bit small
> > > for some uses (often exhibited as not being able to open new xterms), but 
> > > y
> > ou
> > > can create more like this:
> > > 
> > > cd /dev
> > > sh MAKEDEV pty1
> > 
> > This shouldn't be a problem for software using openpty().
> 
> I don't think that is correct.  You still need to device nodes in
> /dev to exist.  Otherwise, the PTMGET ioctl will fail.

oh, my bad. I thought ptm would create the pty nodes as needed, but apparently
not.

Re: Issue with numbers of pty

[Todd C. Miller]

On Fri, 01 Jul 2016 10:50:24 -0400, "Ted Unangst" wrote:

> Stuart Henderson wrote:
> > On 2016-06-30, Oriol Demaria  wrote:
> > > Trying tmuxinator here I have noticed that I ran out of pty, according
> > > to man pty(4) there is a kernel parameter specifiying the max
> > > number. I'm running a snapshot from last Friday, and I don't seem to
> > > have kern.tty.maxptys.
> > 
> > You probably just ran out of device nodes, the default (62) is a bit small
> > for some uses (often exhibited as not being able to open new xterms), but y
> ou
> > can create more like this:
> > 
> > cd /dev
> > sh MAKEDEV pty1
> 
> This shouldn't be a problem for software using openpty().

I don't think that is correct.  You still need to device nodes in
/dev to exist.  Otherwise, the PTMGET ioctl will fail.

 - todd

Re: Question about NTP server

[Leonardo Santagostini]

Just to say thank you all for your responses.

I will tell you the final set of NTP servers =)

Yours, Leonardo

Saludos.-
Leonardo Santagostini






2016-06-30 18:08 GMT-03:00 Zé Loff :

> > On 30/06/2016, at 20:30, Martin Schröder  wrote:
> >
> > 2016-06-30 21:24 GMT+02:00 Leonardo Santagostini <
> lsantagost...@gmail.com>:
> >> 1) Is there some calculus for making those ntp boxes efficient in terms
> of
> >> not overstate (sorry, but english is not my mothers tongue) or right
> size
> >> the hardware.
> >
> > A Rasberry Pi would suffice (but it's not supported by OpenBSD).
> > Any old server you have lying around will be more than enough.
>
> Not too old, though. I've had problems with clocks in aging hardware (e.g.
> a
> Pentium II machine about 5 years ago) starting to drift so bad that not
> even
> NTP could keep them in sync. That being said, prices drop fast enough so
> that
> you can find fairly recent machines at very low prices.
>
> >
> >> 2) Im wondering also to set up this boxes virtualized using KVM. I know
> >> that using RTC its a really pain in the ass, but maybe you can give me
> some
> >> advice for this config.
> >
> > Don't virtualize your ntp servers.
> >
> > Best
> >   Martin

Re: empty directories under /usr/src/sys/gnu

[Otto Moerbeek]

On Fri, Jul 01, 2016 at 09:49:22PM +0800, Teng Zhang wrote:

> hi,  why the empty directory /usr/src/sys/gnu didn't be removed ?
> Is it the reason of the limit of GNU license or some other reasons ?

You probably did not use the -P option with cvs co or update.

-Otto

Re: I am not sure if it is a problem with OpenBSD's httpd

[Kamil Cholewiński]

>  Arrived to this point, could be a problem with OpenBSD's httpd daemon
>  that runs in chroot??

None of the symptoms you've described has anything at all to do with
local httpd, or any other web server you might be running locally.

> But when I try to resolve DNS googleprojectzero.blogspot.com name in
> the shell, works ok:

That's right, DNS works at a lower layer than HTTP. So DNS may resolve,
but the remote host may still be unable to service your request.

You may want to run something like this to help you diagnose:

curl -v http://googleprojectzero.blogspot.com/feeds/posts/default

Cheers,
K.

On Fri, 01 Jul 2016, "C. L. Martinez"  wrote:
> Hi all
>
>  Recently, I have installed an OpenBSD virtual machine in my laptop with 
> TT-RSS, and all works perfectlly. Until I try to subscribe to a new feed. 
> Every time, tt-rss returns the error "6 Couldn't resolve host". It is 
> strange, because all other feeds migrated from other linux host, works ok.
>
>  For example, if I try to subscribe to 
> http://googleprojectzero.blogspot.com/feeds/posts/default feed, error is 
> rturned. But when I try to resolve DNS googleprojectzero.blogspot.com name in 
> the shell, works ok:
>
> Last login: Fri Jul  1 07:06:54 2016 from 172.22.55.1
> OpenBSD 5.9 (GENERIC) #4: Thu May 19 08:23:10 CEST 2016
>
> Welcome to OpenBSD: The proactively secure Unix-like operating system.
>
> Please use the sendbug(1) utility to report bugs in the system.
> Before reporting a bug, please try to reproduce it with the latest
> version of the code.  With bug reports, please try to ensure that
> enough information to reproduce the problem is enclosed, and if a
> known fix for it exists, include that as well.
>
> root@edinburgh:~# nslookup googleprojectzero.blogspot.com 
>   
> 
> Server: 172.22.55.1
> Address:172.22.55.1#53
>
> Non-authoritative answer:
> googleprojectzero.blogspot.com  canonical name = 
> blogspot.l.googleusercontent.com.
> Name:   blogspot.l.googleusercontent.com
> Address: 216.58.208.225
>
>  Arrived to this point, could be a problem with OpenBSD's httpd daemon that 
> runs in chroot??
>
> Thanks.
>
>
> -- 
> Greetings,
> C. L. Martinez

I am not sure if it is a problem with OpenBSD's httpd

[C. L. Martinez]

Hi all

 Recently, I have installed an OpenBSD virtual machine in my laptop with 
TT-RSS, and all works perfectlly. Until I try to subscribe to a new feed. Every 
time, tt-rss returns the error "6 Couldn't resolve host". It is strange, 
because all other feeds migrated from other linux host, works ok.

 For example, if I try to subscribe to 
http://googleprojectzero.blogspot.com/feeds/posts/default feed, error is 
rturned. But when I try to resolve DNS googleprojectzero.blogspot.com name in 
the shell, works ok:

Last login: Fri Jul  1 07:06:54 2016 from 172.22.55.1
OpenBSD 5.9 (GENERIC) #4: Thu May 19 08:23:10 CEST 2016

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

root@edinburgh:~# nslookup googleprojectzero.blogspot.com   


Server: 172.22.55.1
Address:172.22.55.1#53

Non-authoritative answer:
googleprojectzero.blogspot.com  canonical name = 
blogspot.l.googleusercontent.com.
Name:   blogspot.l.googleusercontent.com
Address: 216.58.208.225

 Arrived to this point, could be a problem with OpenBSD's httpd daemon that 
runs in chroot??

Thanks.


-- 
Greetings,
C. L. Martinez

Re: Issue with numbers of pty

[Ted Unangst]

Stuart Henderson wrote:
> On 2016-06-30, Oriol Demaria  wrote:
> > Trying tmuxinator here I have noticed that I ran out of pty, according
> > to man pty(4) there is a kernel parameter specifiying the max
> > number. I'm running a snapshot from last Friday, and I don't seem to
> > have kern.tty.maxptys.
> 
> You probably just ran out of device nodes, the default (62) is a bit small
> for some uses (often exhibited as not being able to open new xterms), but you
> can create more like this:
> 
> cd /dev
> sh MAKEDEV pty1

This shouldn't be a problem for software using openpty().

empty directories under /usr/src/sys/gnu

[Teng Zhang]

hi,  why the empty directory /usr/src/sys/gnu didn't be removed ?
Is it the reason of the limit of GNU license or some other reasons ?

Re: uefi

[YASUOKA Masahiko]

On Thu, 30 Jun 2016 10:41:39 -0300
Friedrich Locke  wrote:
> i would like to know if there is anyone in this list that is running
> Windows and OBSD 5.9 amd 64 on the same machine with UEFI and doing,
> naturally, multiboot.

Both my vaio laptops and dell desktop boot both OpenBSD and Windows.

As for the boot program, I think many ways exist.  But my favoite way
is following:

  1. Set the first boot priority to OpenBSD
 Set the next to Windows
  2. Enter "machine exit" on OpenBSD efiboot when you want to use
 Windows.  Just wait when you use OpenBSD.

--yasuoka

firefox and thunderbird crashes

[Stefan Wollny]

Hi there!

Trying to use the latest available snapshot of amd64-current I notice
that lately firefox and thunderbird crash way too often. Does s.o. else
experience this as well?

firefox-47.0Mozilla web browser
firefox-i18n-de-47.0 de language pack for Firefox
thunderbird-45.1.1  Mozilla e-mail, rss and usenet client
thunderbird-i18n-de-45.1.1 de language pack for Thunderbird

'wxallowed' is set on /usr.

Might be some dependencies or add-ons...

Best,
STEFAN


OpenBSD 6.0-beta (GENERIC.MP) #2241: Fri Jul  1 00:22:57 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17082359808 (16291MB)
avail mem = 16560115712 (15792MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb500 (35 entries)
bios0: vendor American Megatrends Inc. version "1.05.01" date 08/05/2015
bios0: Notebook W65_67SZ
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT ASF! SSDT SSDT SSDT MCFG HPET SSDT
SSDT SSDT DMAR
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4)
RP03(S4) PXSX(S4) RP04(S4) RLAN(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4)
PXSX(S4) RP07(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) i5-4210M CPU @ 2.60GHz, 3093.25 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus 3 (RP03)
acpiprt3 at acpi0: bus 4 (RP04)
acpiprt4 at acpi0: bus 1 (P0P2)
acpiprt5 at acpi0: bus -1 (P0PA)
acpiprt6 at acpi0: bus -1 (P0PB)
acpiprt7 at acpi0: bus 1 (PEG0)
acpiec0 at acpi0
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 120 degC
"INT3F0D" at acpi0 not configured
"MSFT0001" at acpi0 not configured
"ETD0403" at acpi0 not configured
"PNPC000" at acpi0 not configured
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: LID0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "BAT" serial 0001 type LION oem "Notebook"
"PNP0C14" at acpi0 not configured
"INT340E" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: LCD0
cpu0: Enhanced SpeedStep 3093 MHz: speeds: 2601, 2600, 2500, 2300, 2200,
2100, 2000, 1800, 1700, 1600, 1400, 1300, 1200, 1100, 900, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06
ppb0 at pci0 dev 1 function 0 "Intel 

Re: Clean OpenBSD's httpd logs

[C. L. Martinez]

On Fri  1.Jul'16 at  7:39:13 +, Stuart Henderson wrote:
> On 2016-06-30, C. L. Martinez  wrote:
> > Hi all,
> >  
> >  Sorry if this question sounds stupid, but how can I avoid this type of 
> > entry in OpenBSD's httpd access.log:
> >
> > 172.22.55.1:44710 -> 172.22.55.10, /favicon.ico (404 Not Found), [/] 
> > [/favicon.ico]
> 
> Untested, but in theory: set a location that matches the favicon.ico file and
> disable logging (e.g. "no log") in that location block.
> 

Perfect!!! .. Works like a charm. Many thanks Stuart.

-- 
Greetings,
C. L. Martinez

Re: Issue with numbers of pty

[Oriol Demaria]

Yes, that was the issue. Thank you very much :)

Stuart Henderson  writes:

> On 2016-06-30, Oriol Demaria  wrote:
>> Trying tmuxinator here I have noticed that I ran out of pty, according
>> to man pty(4) there is a kernel parameter specifiying the max
>> number. I'm running a snapshot from last Friday, and I don't seem to
>> have kern.tty.maxptys.
>
> You probably just ran out of device nodes, the default (62) is a bit small
> for some uses (often exhibited as not being able to open new xterms), but you
> can create more like this:
>
> cd /dev
> sh MAKEDEV pty1
>
> If you need even more, you can do pty2,...pty15, you get 62 for each number
> (0 is /dev/ptyp[0-9a-zA-Z], 1 is ptyq*, etc).


-- 
Oriol Demaria
0x58415679

Re: DNS lookup utility with port

[Stuart Henderson]

On 2016-06-30, Kapetanakis Giannis  wrote:
> On 30/06/16 16:01, Stuart Henderson wrote:
>> On 2016-06-30, Kapetanakis Giannis  wrote:
>>> Hi,
>>>
>>> a) I'm asking if there is any program in base for dns lookups that support 
>>> port for name server.
>> 
>> Not in base, you will need packages.
>> 
>>> b) would a patch for this in src/usr.sbin/bind/ be accepted or is
>>> there a reason for this to be out (except for the ancient version)?
>> 
>> It was disabled so that tighter pledge(2) restrictions could be used.
>
> understood and thanks for the reply.
>
> Would you think to add libldns/drill in base or is it out of question?

If it were added, it would likely also use "dns" pledge and you would have
the same problem.

Re: Clean OpenBSD's httpd logs

[Stuart Henderson]

On 2016-06-30, C. L. Martinez  wrote:
> Hi all,
>  
>  Sorry if this question sounds stupid, but how can I avoid this type of entry 
> in OpenBSD's httpd access.log:
>
> 172.22.55.1:44710 -> 172.22.55.10, /favicon.ico (404 Not Found), [/] 
> [/favicon.ico]

Untested, but in theory: set a location that matches the favicon.ico file and
disable logging (e.g. "no log") in that location block.

Re: Issue with numbers of pty

[Stuart Henderson]

On 2016-06-30, Oriol Demaria  wrote:
> Trying tmuxinator here I have noticed that I ran out of pty, according
> to man pty(4) there is a kernel parameter specifiying the max
> number. I'm running a snapshot from last Friday, and I don't seem to
> have kern.tty.maxptys.

You probably just ran out of device nodes, the default (62) is a bit small
for some uses (often exhibited as not being able to open new xterms), but you
can create more like this:

cd /dev
sh MAKEDEV pty1

If you need even more, you can do pty2,...pty15, you get 62 for each number
(0 is /dev/ptyp[0-9a-zA-Z], 1 is ptyq*, etc).