Re: Viewport for man.openbsd.org -- readability on phones

[Vadim Zhukov]

If you REALLY want something like we had, without JS and non-standard
features, you can try something like:

@media screen and (min-width: 1000px) {
html { max-width: 100ex }
html { max-width: 80ch }
}

The @media queries is a long-standing feature and should just work.
The "ch" isn't supported by IE <=8 and Opera <=20, so if you really
care, you can use doubled declaration: this way browsers that don't
support "ch" will use old "ex". Using "ex" for specifying width is
ugly and it probably should be something like "65em" instead anyway...

--
  WBR,
  Vadim Zhukov


2018-05-18 4:08 GMT+03:00 Ingo Schwarze :
> Hi Ken,
>
> Ken M wrote on Thu, May 17, 2018 at 08:50:53PM -0400:
>
>> I will probably have to duck and run
>> for suggesting javascript as the answer here...
>
> Precisely.  :)
>
>> But for the most part the modern industry standard to make pages
>> scale well across many devices and screen orientations is to use
>> a responsive design library, most notably bootstrap.
>
> We are talking about a simplistic one-column layout here,
> and avoiding that kind of bloat (in particular javascript)
> is among the top four design goals, together with support
> for hyperlinks, support for semantic annotations, and avoiding
> gratuitous presentational differences when compared to terminal
> output (just to avoid misunderstandings, not every difference
> is gratuitous: for example, terminals naturally use fixed-width
> fonts, HTML naturally uses proportional fonts).
>
> But no, javascript is an even worse suggestion than the
> original idea of "meta viewport".
>
> Yours,
>   Ingo
>

Re: Viewport for man.openbsd.org -- readability on phones

[Stuart Longland]

On 18/05/18 12:09, Ken M wrote:
> In all honesty I wasn't thinking of the suggestion as a cautious one because 
> of
> bloat. I think bootstrap minified and compressed is like 20k. I mean how big 
> is
> the entire man page collection?

20kB may not sound like a lot, but consider, say, the `sh` man page:

http://man.openbsd.org/sh

The man page itself (the file in /usr/share/man) is about 53kB in size.
There are bigger man pages; some over 1MB (perltoc for example), I
picked that one arbitrarily.

Rendered as HTML; Firefox tells me that link and all its resources is
about 153kB.

Throwing bootstrap in there adds an extra 13% to the total page download
size (173/153 =~ 1.13).  The only saving grace here is that the browser
ought to be caching that shared resource, and in ordinary circumstances
it will, but you're at the mercy of what the browser (and intermediate
proxies) decide to cache.

If they decide to not cache: you'll be hit with that extra 20kB on each
page view.  It doesn't sound like a lot, but it adds up.

Back when I was learning web design (did a few-week intensive course
back in 2001), I recall the recommendations to design for 800×600 screen
resolutions, and to keep load times below 30 seconds when viewed on a
28.8kbps modem link.

I don't know what they teach today, but I don't think today's widely
available broadband links and high-resolution displays are a good excuse
to throw the kitchen sink at the problem.  More code means more can go
wrong.

I find it refreshing to hit an OpenBSD website page, and have it load
nearly instantly, and work on any browser released in the last 25~30
years, and without exposing the user to risks such as CDNs going out of
business and getting taken over¹.

Removing a problematic line from the CSS sounds like a more robust
solution than adding unnecessary complexity to the page.

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

1.
https://blog.hboeck.de/archives/889-Abandoned-Domain-Takeover-as-a-Web-Security-Risk.html

Re: Viewport for man.openbsd.org -- readability on phones

[Todd C. Miller]

On Fri, 18 May 2018 02:47:29 +0200, Ingo Schwarze wrote:

> I must say i never particularly liked that line in the CSS file.
> It always felt like fiddling with details that it might be better
> not to touch, given that display devices running browsers differ
> more than terminal emulators.  And here we are with a suspicion
> that it actually causes accessibility issues, even if the suspicion
> is still unconfirmed...
>
> Depending on the feedback i get here with respect to how
>   https://man.openbsd.org/
> now looks, i shall consider deleting the offending line for good.
>
> In general, i like the idea of making things better by *removing*
> harmful tweaks rather than adding new goo...

For what it's worth I removed that line from mandoc.css when I
switched the sudo online manuals to mandoc.

My vote is to remove it here too.

 - todd

Re: Viewport for man.openbsd.org -- readability on phones

[Ken M]

In all honesty I wasn't thinking of the suggestion as a cautious one because of
bloat. I think bootstrap minified and compressed is like 20k. I mean how big is
the entire man page collection?

I was more hesitant to make the suggestion because if there was ever a community
that en masse browsed with js disabled I would think it would be this one.

Ken

On Fri, May 18, 2018 at 03:08:25AM +0200, Ingo Schwarze wrote:
> Hi Ken,
> 
> Ken M wrote on Thu, May 17, 2018 at 08:50:53PM -0400:
> 
> > I will probably have to duck and run
> > for suggesting javascript as the answer here...
> 
> Precisely.  :)
> 
> > But for the most part the modern industry standard to make pages
> > scale well across many devices and screen orientations is to use
> > a responsive design library, most notably bootstrap.
> 
> We are talking about a simplistic one-column layout here,
> and avoiding that kind of bloat (in particular javascript)
> is among the top four design goals, together with support
> for hyperlinks, support for semantic annotations, and avoiding
> gratuitous presentational differences when compared to terminal
> output (just to avoid misunderstandings, not every difference
> is gratuitous: for example, terminals naturally use fixed-width
> fonts, HTML naturally uses proportional fonts).
> 
> But no, javascript is an even worse suggestion than the
> original idea of "meta viewport".
> 
> Yours,
>   Ingo

Re: Viewport for man.openbsd.org -- readability on phones

[Ingo Schwarze]

Hi Ken,

Ken M wrote on Thu, May 17, 2018 at 08:50:53PM -0400:

> I will probably have to duck and run
> for suggesting javascript as the answer here...

Precisely.  :)

> But for the most part the modern industry standard to make pages
> scale well across many devices and screen orientations is to use
> a responsive design library, most notably bootstrap.

We are talking about a simplistic one-column layout here,
and avoiding that kind of bloat (in particular javascript)
is among the top four design goals, together with support
for hyperlinks, support for semantic annotations, and avoiding
gratuitous presentational differences when compared to terminal
output (just to avoid misunderstandings, not every difference
is gratuitous: for example, terminals naturally use fixed-width
fonts, HTML naturally uses proportional fonts).

But no, javascript is an even worse suggestion than the
original idea of "meta viewport".

Yours,
  Ingo

Re: Viewport for man.openbsd.org -- readability on phones

[Ken M]

I will probably have to duck and run for suggesting javascript as the answer
here...

But for the most part the modern industry standard to make pages scale well
across many devices and screen orientations is to use a responsive design
library, most notably bootstrap.

Ken

On Fri, May 18, 2018 at 10:07:27AM +0930, Jack Burton wrote:
> On Thu, 17 May 2018 18:32:44 -0400
> Aner Perez  wrote:
> > First non-comment line of mandoc.css says:
> > 
> > html {  max-width: 100ex; }
> > 
> > Removing this line allows the use of the full browser width.  I'm
> > sure that it was put there for a reason (maybe to approximate the
> > width of a terminal?).
> 
> Some browsers simply don't calculate lengths expressed in exes correctly
> -- seen that in many other contexts. Last time I checked (about 3 years
> ago, so it might well have changed since), two of the four most common
> browsers still exhibited that fault.
> 
> As a quick experiment, try looking up the metrics of the font your
> browser actually uses to render man pages, then convert 100ex into ems
> for your font and put the result in the max-width attribute in your
> local copy of mandoc.css.
> 
> If that fixes your width issue then you'll have clear evidence that the
> bug lies in the browser (specifically in its routine for converting
> exes to whatever its native display length unit is).
> 

Re: Viewport for man.openbsd.org -- readability on phones

[Ingo Schwarze]

Hi Aner,

Aner Perez wrote on Thu, May 17, 2018 at 06:32:44PM -0400:
> On 05/17/2018 05:22 PM, x...@dr.com wrote:
>> "Ingo Schwarze"  wrote:

>>> Absolutely not.
>>> Mandoc output is not optimized for any device.
>>>
>>> Which elements or rules in the current HTML or CSS code
>>> make you think it is optimized or it discriminates against
>>> any device?

>> I don't know which element or rule is the problem, however
>> if I delete mandoc.css the text does fill the screen.
>> 
>> I understand that what I am trying to do is not supported,
>> so I'll do something else instead.

> First non-comment line of mandoc.css says:
> 
> html {max-width: 100ex; }
> 
> Removing this line allows the use of the full browser width.

That is a very useful bit of information.
Thanks for investigating and reporting it.

For testing purposes, i removed that line from
  https://man.openbsd.org/mandoc.css

xcv@, could you check with your phone whether this solves
your original issue?

> I'm sure that it was put there for a reason
> (maybe to approximate the width of a terminal?).

Correct.  The original reason was that for -T ascii and -T utf8
output, the default is -O width=78.  The reason for that is that
it's conventional wisom in typography that readability of text
suffers with excessive column width - even though some recent
research raises doubts whether that is really true.  Either way,
people tend to feel strongly about it.

I must say i never particularly liked that line in the CSS file.
It always felt like fiddling with details that it might be better
not to touch, given that display devices running browsers differ
more than terminal emulators.  And here we are with a suspicion
that it actually causes accessibility issues, even if the suspicion
is still unconfirmed...

Depending on the feedback i get here with respect to how
  https://man.openbsd.org/
now looks, i shall consider deleting the offending line for good.

In general, i like the idea of making things better by *removing*
harmful tweaks rather than adding new goo...

Yours,
  Ingo

Re: Viewport for man.openbsd.org -- readability on phones

[Jack Burton]

On Thu, 17 May 2018 18:32:44 -0400
Aner Perez  wrote:
> First non-comment line of mandoc.css says:
> 
> html {max-width: 100ex; }
> 
> Removing this line allows the use of the full browser width.  I'm
> sure that it was put there for a reason (maybe to approximate the
> width of a terminal?).

Some browsers simply don't calculate lengths expressed in exes correctly
-- seen that in many other contexts. Last time I checked (about 3 years
ago, so it might well have changed since), two of the four most common
browsers still exhibited that fault.

As a quick experiment, try looking up the metrics of the font your
browser actually uses to render man pages, then convert 100ex into ems
for your font and put the result in the max-width attribute in your
local copy of mandoc.css.

If that fixes your width issue then you'll have clear evidence that the
bug lies in the browser (specifically in its routine for converting
exes to whatever its native display length unit is).

Re: no default httpd.conf?

[justina colmena]

On Thu, 17 May 2018 11:26:54 + (UTC)
Stuart Henderson  wrote:
> No need to run multiple copies of php-fpm yourself, it handles multi
> uid itself. Various ways to handle chroot as well, you can chroot them
> separately, or use a shared chroot and rely on permissions. This
> should give you some ideas:

I rather like the idea of separate chroots, or at least a chroot that
would keep the listening socket out of reach. Separate sockets for
separate users are not very useful if, for example, one user is allowed
to fopen() another user's socket, for which the PHP function is just a
thin wrapper over the C call. I'm quoting here from OpenBSD's stock
configuration file (from ports & packages.)

==%<-- /etc/php-fpm.conf
; Set permissions for unix socket, if one is used. In Linux, read/write
; permissions must be set in order to allow connections from a web
; server. Many BSD-derived systems allow connections regardless of
; permissions.
; Default Values: user and group are set as the running user
; mode is set to 0660
listen.owner = www
listen.group = www
listen.mode = 0660
; When POSIX Access Control Lists are supported you can set them using
; these options, value is a comma separated list of user/group names.
; When set, listen.owner and listen.group are ignored
;listen.acl_users =
;listen.acl_groups =
==%<--

I'm not trying to be hung up on PHP especially, either. This is rather
a general issue, because we would have exactly the same problem in
Perl, Python, Ruby, or any of several other popular web languages out
there.

On Thu, 17 May 2018 11:20:29 +0300
Vadim Zhukov  wrote:
> Regarding su-php, I'd go with per-user php-fpm process, actually,
> that's much safer, and rarely used ones can easily wait in swap
Do you think I have thousands of customers, and the little people's web
pages are taking too long to load? No, that's a whole other issue ...

> (I feel that you're trying to pack as much users as possible).

Ok, sure, but if you can't do that, then what is the point of a
multi-user operating system, anyways? A one-user webserver? Because
everybody has permission somehow or another to read everybody else's
scripts and database passwords.

So let's start with a much simpler use case: I need to be able to add a
test user and try out some stupid or crazy web programming project or
idea without risking my production stuff that happens to be hosted on
the same machine. Customers do that anyways at any web hosting
provider.

> Did you ever looked in /etc/examples?

"Jesus saith unto them, Did ye never read in the scriptures, ... ?"

That's almost a little bit of a mess, because these are not actual
settings applied to system configuration, and I would not have expected
to find them in the /etc directory. I was looking for examples more
in /usr/share somewhere before my system locate database was populated.
That one (/etc/examples/httpd.conf) somewhat "encourages" https-only,
without actually using hsts.

That would be okay, except a lot of times I am at a coffee shop or
similar, and I have to visit a plain http page to trigger a redirect
for login, because I am not willing to waive the certificate validation
error that I get when I try to visit a secure site from public wifi
somewhere.

> OpenBSD HTTPd is a web server, but not each web server is
> fully-featured Apache HTTP Server replacement. So, yes, no UserDir.
> If you need this functionality, then just install apache-httpd from
> packages.

Apache has plenty of its own shortcomings, and I'm sure there was good
cause to throw it out of base OpenBSD.

Re: Viewport for man.openbsd.org -- readability on phones

[Aner Perez]

On 05/17/2018 05:22 PM, x...@dr.com wrote:

"Ingo Schwarze"  wrote:

Absolutely not.
Mandoc output is not optimized for any device.

Which elements or rules in the current HTML or CSS code
make you think it is optimized or it discriminates against
any device?


I don't know which element or rule is the problem, however
if I delete mandoc.css the text does fill the screen.

I understand that what I am trying to do is not supported,
so I'll do something else instead.



First non-comment line of mandoc.css says:

html {  max-width: 100ex; }

Removing this line allows the use of the full browser width.  I'm sure that it was put 
there for a reason (maybe to approximate the width of a terminal?).


- Aner

Re: Viewport for man.openbsd.org -- readability on phones

[xcv]

"Ingo Schwarze"  wrote:
> Absolutely not.
> Mandoc output is not optimized for any device.
>
> Which elements or rules in the current HTML or CSS code
> make you think it is optimized or it discriminates against
> any device?

I don't know which element or rule is the problem, however 
if I delete mandoc.css the text does fill the screen. 

I understand that what I am trying to do is not supported, 
so I'll do something else instead.

Re: Viewport for man.openbsd.org -- readability on phones

[Ingo Schwarze]

Hi Marc,

Marc Espie wrote on Wed, May 16, 2018 at 11:28:31AM +0200:
> On Tue, May 15, 2018 at 10:51:43PM +0200, Ingo Schwarze wrote:
>> x...@dr.com wrote on Tue, May 15, 2018 at 07:47:45PM +0200:

>>> The "viewport" meta tag significantly improves readability and 
>>> usability on my phone when I add it to http://man.openbsd.org pages:
>>> 
>>> [meta name="viewport" content="width=device-width, initial-scale=1.0"]

>> There is no way i will use that.
>> It is not defined in any standard.

> As someone pointed it out, it is in a proposal, improves things on several
> devices, and is harmless on others.
> 
> You quite well know that the web evolves by practice first, and 
> standardization later.
> 
> We are talking about something that's currently already written, will
> likely become a standard in some months, and helps using tools.
> 
> Why resist ?

Because web design is full of cruft.

If i would put in every micro-optimization tweak that somebody
suggests for making something better in some situation, we would
soon end up with HTML code and a style sheet that are large and
unreadable.

For example, just last week, somebody requested that i change
  "font-family: monospace;"
to
  "font-family: monospace, monospace;"
for exactly the same reasons you are putting forward:  It (arguably)
looks better in some situations, it is (arguably) harmless in some
other situations, it is widespread practice in the industry, and
it is interpreted in similar ways by several popular browsers.

No.  The only way to stay sane is to restrict ourselves to elements
and rules that are really required.  Our HTML and CSS should only
contain elements and rules with respect to topics that we do want
to say something about.

I do *not* want to restrict what the browser does with the viewport,
so there is no reason to write code for fiddling with the browser's
viewport settings.

Yours,
  Ingo

Re: Viewport for man.openbsd.org -- readability on phones

[Ingo Schwarze]

Hi,

x...@dr.com wrote on Thu, May 17, 2018 at 05:04:12PM +0200:

> I think it boils down to the site being optimized
> for common PC screen sizes,

Absolutely not.
Mandoc output is not optimized for any device.

Which elements or rules in the current HTML or CSS code
make you think it is optimized or it discriminates against
any device?

> If I understand the "viewport" tag correctly, it basically
> says that it is OK to let the viewable content fill the screen.

That makes no sense at all.

The size of the viewport depends on the device and on how big the
user made the browser window.  How the browser uses the space that
happens to be available to it is *always* up to the browser, no
matter whether there is a viewport tag or not - except, of course,
if the author requests a specific viewport size with the viewport
tag, which i'm not doing, and which you do not propose either.

Note that mandoc is specifically *not* restricting the browser's
decision on how to use the available space, and it is *not* requiring
a large width or a large viewport size or anything.  So if the
browser sets an unreasonably large viewport size that doesn't match
the actual size of the device, i don't think you can blame that on
mandoc.

Yours,
  Ingo

Re: Viewport for man.openbsd.org -- readability on phones

[xcv]

"Ingo Schwarze"  wrote:
> I'm absolutely uninterested in test results.

I understand that many times the designer of a web site may
have different priorities than I do.

Nevertheless, when a site performs poorly I can only:
- close the tab and open another site
- try to persuade the designer to modify the site
- report the site to the browser vendor, hoping they'll add it
  to the quirks list
- use browser extensions such as Adblock to rewrite the site
- make a wrapper app for the site

Most content on http://www.openbsd.org renders just fine and
some pages even use the particular tag. There is no need for
sites to perform poorly on small screen devices.

> I stick to (reasonably established) standards, and it's the job
> of browsers to implement them.  

In the case of "viewport"; Apple, Mozilla, Google, Microsoft
and Opera all happen to do it the same way. Isn't that a 
"reasonably established" web industry standard?

BTW, Safari and Opera on iOS 4.2.1 also support the tag and are
helped by it. Same goes for IE on Windows Phone 8.1.

Furthermore, some "validators" have no issue with the tag:

https://validator.w3.org/nu/?doc=https%3A%2F%2Fviewports.github.io%2Fman%2Fafterboot
https://html5.validator.nu/?doc=https%3A%2F%2Fviewports.github.io%2Fman%2Fafterboot
 
https://checker.html5.org/?useragent=Validator.nu%2FLV==https%3A%2F%2Fviewports.github.io%2Fman%2Fafterboot

> ... If a browser failes to implement
> a standard that has been in force for a long time, that's a bug
> in the browser and not my problem

> ... You also fail to state whether you have any
> idea what the root cause of the unstated problem might be.
> For example, is it somehow related to the CSS rule
>
>   html { max-width: 100ex; } ?

I think it boils down to the site being optimized for common
PC screen sizes, causing problems on "phone" devices as they
have much smaller screens. If so, the bug is not in all (?)
mobile browsers but in the website. I'm assuming that W3C,
WHATWG and whatever do not mandate sites to be optimized for
common PC screen sizes only.

If I understand the "viewport" tag correctly, it basically
says that it is OK to let the viewable content fill the screen.

Of course, there are other possible fixes, however the ones I
can think of are far more complex.

Re: no default httpd.conf?

[Vadim Zhukov]

2018-05-17 14:26 GMT+03:00 Stuart Henderson :
> On 2018-05-17, Vadim Zhukov  wrote:
>> 17 мая 2018 г. 5:50:16 GMT+03:00, justina colmena  
>> пишет:
>>
>> Regarding su-php, I'd go with per-user php-fpm process, actually,
>> that's much safer, and rarely used ones can easily wait in swap (I
>> feel that you're trying to pack as much users as possible). You
>> can ever use symlinks to create, e.g., /etc/rc.d/phpXY_fpm_USER1,
>> /etc/rc.d/phpXY_fpm_USER2 and so on, and then set up different flags
>> like "-u USER1" for those in rc.conf.
>
> No need to run multiple copies of php-fpm yourself, it handles multi
> uid itself. Various ways to handle chroot as well, you can chroot them
> separately, or use a shared chroot and rely on permissions. This should
> give you some ideas:
>
> [global]
> error_log = syslog
> syslog.facility = daemon
> log_level = notice
>
> [www]
> user = www
> group = www
> listen = /var/www/run/php-fpm.sock
> listen.owner = www
> listen.group = www
> listen.mode = 0600
> pm = dynamic
> pm.max_children = 20
> pm.start_servers = 2
> pm.min_spare_servers = 1
> pm.max_spare_servers = 3
> chroot = /var/www
>
> [web1]
> user = _web1
> group = _web1
> listen = /var/www/run/php-fpm-web1.sock
> listen.owner = www
> listen.group = www
> listen.mode = 0600
> pm = dynamic
> pm.max_children = 20
> pm.start_servers = 2
> pm.min_spare_servers = 1
> pm.max_spare_servers = 2
> chroot = /var/www
> env[TMP] = /var/www/web1/tmp
> env[TMPDIR] = /var/www/web1/tmp

Now that breakfast is gone I start to think you (and Josh earlier) are
right: single php-fpm process should be fine. :)

--
  WBR,
  Vadim Zhukov

Re: no default httpd.conf?

[Stuart Henderson]

On 2018-05-17, Vadim Zhukov  wrote:
> 17 мая 2018 г. 5:50:16 GMT+03:00, justina colmena  пишет:
>
> Regarding su-php, I'd go with per-user php-fpm process, actually,
> that's much safer, and rarely used ones can easily wait in swap (I
> feel that you're trying to pack as much users as possible). You
> can ever use symlinks to create, e.g., /etc/rc.d/phpXY_fpm_USER1,
> /etc/rc.d/phpXY_fpm_USER2 and so on, and then set up different flags
> like "-u USER1" for those in rc.conf.

No need to run multiple copies of php-fpm yourself, it handles multi
uid itself. Various ways to handle chroot as well, you can chroot them
separately, or use a shared chroot and rely on permissions. This should
give you some ideas:

[global]
error_log = syslog
syslog.facility = daemon
log_level = notice

[www]
user = www
group = www
listen = /var/www/run/php-fpm.sock
listen.owner = www
listen.group = www
listen.mode = 0600
pm = dynamic
pm.max_children = 20
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
chroot = /var/www

[web1]
user = _web1
group = _web1
listen = /var/www/run/php-fpm-web1.sock
listen.owner = www
listen.group = www
listen.mode = 0600
pm = dynamic
pm.max_children = 20
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 2
chroot = /var/www
env[TMP] = /var/www/web1/tmp
env[TMPDIR] = /var/www/web1/tmp

ping blocked for 12 minutes

[Axel Rau]

Hi,

a firewall box blocks ICMP packets (from icinga2 hostalive4 check_command) for 
12 minutes.
This happens nearly every night. mtr shows 100% loss on the last hop.

The ICMP echo requests (10/minute) are directed to the firewall box itself.
If this is from a rate-limiting feature, how can I adjust it?
My related sysctls are:

net.inet.icmp.maskrepl=0
net.inet.icmp.bmcastecho=0
net.inet.icmp.errppslimit=1000
net.inet.icmp.rediraccept=0
net.inet.icmp.redirtimeout=600
net.inet.icmp.tstamprepl=1

Also I see ierrs on external and internal interface:

NameMtu   Network Address  Ipkts IerrsOpkts Oerrs Colls

em0 150000:60:e0:5a:75:34 377973673  4274 322178969 0 0
em0 1500  91.216.35.1 91.216.35.124 377973673  4274 322178969 0 0
em0 1500  fe80::%em0/ fe80::260:e0ff:fe 377973673  4274 322178969 0 0
em0 1500  2a05:bec0:2 2a05:bec0:26:2::a 377973673  4274 322178969 0 0
em1*150000:60:e0:5a:75:350 00 0 0
em2 150000:60:e0:5a:75:36 587989351  4377 408807684 0 0
em2 1500  109.230.225 109.230.225.234   587989351  4377 408807684 0 0
em2 1500  fe80::%em2/ fe80::260:e0ff:fe 587989351  4377 408807684 0 0
em2 1500  2a05:bec0:f 2a05:bec0:ff::27  587989351  4377 408807684 0 0

Are they related?

If this is no rate-limiting feature, what else may be the reason?

Any help appreciated,
Axel

PS:
# dmesg
OpenBSD 6.2 (GENERIC.MP) #6: Wed Feb 28 21:13:02 CET 2018

r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4264062976 (4066MB)
avail mem = 4127748096 (3936MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f98a000 (53 entries)
bios0: vendor American Megatrends Inc. version "5.6.5" date 05/19/2014
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP FPDT MCFG WDAT UEFI APIC BDAT HPET SSDT HEST BERT ERST 
EINJ
acpi0: wakeup devices PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) EHC1(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C2358 @ 1.74GHz, 1750.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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: TSC frequency 1750319340 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU C2358 @ 1.74GHz, 1750.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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX1)
acpiprt2 at acpi0: bus 2 (PEX2)
acpiprt3 at acpi0: bus 3 (PEX3)
acpiprt4 at acpi0: bus 4 (PEX4)
acpicpu0 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
"PNP0003" at acpi0 not configured
"PNP0C33" at acpi0 not configured
cpu0: Enhanced SpeedStep 1750 MHz: speeds: 1744, 1743, 1660, 1577, 1494, 1411, 
1328, 1245, 1162 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x1f0e rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi, address 
00:60:e0:5a:75:34
ppb1 at pci0 dev 2 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03: msi, address 
00:60:e0:5a:75:35
ppb2 at pci0 dev 3 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 4 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci4 at ppb3 bus 4
vendor "Intel", unknown product 0x1f18 (class processor subclass Co-processor, 
rev 0x02) at pci0 dev 11 function 0 not configured
pchb1 at pci0 dev 14 function 0 "Intel Atom C2000 RAS" rev 0x02
"Intel Atom C2000 RCEC" rev 0x02 at pci0 dev 15 function 0 not configured
"Intel Atom C2000 SMBus" rev 0x02 at pci0 dev 19 function 0 not configured
em2 at pci0 dev 20 function 0 "Intel I354 SGMII" rev 0x03: msi, address 
00:60:e0:5a:75:36
em3 at pci0 dev 20 

Re: no default httpd.conf?

[Vadim Zhukov]

17 мая 2018 г. 5:50:16 GMT+03:00, justina colmena  пишет:
>I just recently installed OpenBSD 6.3, and I was looking for an example
>httpd.conf, but I did not find one. The manual page does document
>more or less how to create one, but there still appears to be some lack
>of ease and safety putting up a basic web page with dynamic content (I
>am most used to PHP and PostgreSQL for that purpose, but of course
>there are many options that more or less replace the ubiquitous "LAMP"
>or "Linux/Apache/MySQL/PHP" stack.
>
>Now there is nothing in OpenBSD's httpd really like Apache's "UserDir"
>directive. Of course the real user directory has to dwell somewhere in
>the "/var/www" chroot on OpenBSD. The alternative to "UserDirs" of
>course, is wildcard subdomains, but those do not really cooperate all
>that well with https, dnssec, or caa records, or with certain other
>general goals of security.
>
>The other thing I am curious about is something like "su-php" which
>appears to be deprecated and outdated. So, assuming some sort of
>UserDir
>scenario, (probably more sophisticated than my very basic one I
>have hacked together below,) does php-fpm have a way to prevent one
>user's malicious php script from reading another user's database
>access credentials?
>
>%<
># /etc/httpd.conf for amarillo.colmena.biz
>
>server "default" {
>listen on * port 80
>listen on :: port 80
>listen on * tls port 443
>listen on :: tls port 443
>tls certificate "/etc/ssl/fullchain.pem"
>directory index index.php
>location "/.well-known/acme-challenge/*" {
>root "/acme"
>root strip 2
>}
>location match "/~justina/.*%.php" {
>root "/justina"
>root strip 1
>fastcgi socket "/run/php-fpm.sock"
>}
>location "*.php" {
>fastcgi socket "/run/php-fpm.sock"
>}
>location "/~justina/*" {
>root "/justina"
>root strip 1
>directory auto index
>}
>location "/~justina" {
>block return 301 "/~justina/"
>}
>}
>types {
>include "/usr/share/misc/mime.types"
>}

Did you ever looked in /etc/examples?

OpenBSD HTTPd is a web server, but not each web server is fully-featured Apache 
HTTP Server replacement. So, yes, no UserDir. If you need this functionality, 
then just install apache-httpd from packages.

Regarding su-php, I'd go with per-user php-fpm process, actually, that's much 
safer, and rarely used ones can easily wait in swap (I feel that you're trying 
to pack as much users as possible). You can ever use symlinks to create, e.g., 
/etc/rc.d/phpXY_fpm_USER1, /etc/rc.d/phpXY_fpm_USER2 and so on, and then set up 
different flags like "-u USER1" for those in rc.conf.

-- 
  WBR,
Vadim Zhukov

Re: 6.3-current kernel panic: aml_die aml_parse:4194 on PowerEdge

[Jan Vlach]

> Hi,
> 
> could you please try this diff from kettenis@
> https://marc.info/?l=openbsd-tech=152650279308779=2
> 

Hi Hrvoje, misc@,

I'm sorry, but I don't access to the hardware (Dell PowerEdge R440) anymore.
I've returned it to the supplier already as this was leased only for
testing.

Sorry,
Jan