Lenovo 110s Laptop - bug or unsupported hardware?

[J Vans]

I decided to post this in misc because I am not sure if this a bug or 
unsupported hardware. It is a Lenovo 110s laptop.

Apm works on this machine. Suspend and resume work on this machine.

When running X, and doing things that require a lot of memory (open firefox and 
watch a youtube video + 3 or 4 more tabs + open evince and open a sizeable PDF 
was my test) this machine freezes, and the screen goes black. Sometimes this 
happens in 30 seconds, sometimes it takes 10 minutes or more. I also tested 
with Chrome and Midori, and got the same behavior. I also tested playing video 
locally and the results were the same. On a few occasions it crashed while not 
doing much, but for the most part if I keep memory usage low (i.e. use a text 
based browser, for example) it does not crash. DDB is opening in the background 
after the crash, but I cannot see it. I type ps, and trace, but they do not 
show up in the messages after rebooting. I have however been able to get 
several core dumps. They look identical to eachother, which leads me to believe 
it is the same problem happening in each crash.

The above behavior is consistant across i3, Fvwm, and Cwm, with apmd enabled or 
no, across all flag settings of apm, and machdep.aperture=0, 1, and 2.

Serial console is not an option on this machine but I have quite a collection 
of core dumps. Any advice on trouble shooting this further (or if it's 
unsupported hardware) would be appreciated.

The below info was generated using a kernel built from GENERIC's config + 
makeoptions DEBUG="-g", built from the CURRENT tree on 10/26.

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.2".
(gdb) file bsd.8
Reading symbols from /home/utilis/CRASH/102717/607pm/bsd.8...done.
(gdb) target kvm bsd.8.core
#0  0x8167c544 in dumpsys () at 
/usr/src/sys/arch/amd64/amd64/machdep.c:949
949 error = (*dump)(dumpdev, blkno, va, n);
Current language:  auto; currently minimal
(gdb) where
#0  0x8167c544 in dumpsys () at 
/usr/src/sys/arch/amd64/amd64/machdep.c:949
#1  0x8167bfea in boot (howto=0)
at /usr/src/sys/arch/amd64/amd64/machdep.c:743
#2  0x813cccf5 in reboot (howto=Variable "howto" is not available.
) at /usr/src/sys/kern/kern_xxx.c:70
#3  0x81009f7e in db_boot_crash_cmd (addr=Variable "addr" is not 
available.
)
at /usr/src/sys/ddb/db_command.c:790
#4  0x8100986d in db_command (last_cmdp=0x0, cmd_table=Variable 
"cmd_table" is not available.
)
at /usr/src/sys/ddb/db_command.c:303
#5  0x8100a331 in db_command_loop () at 
/usr/src/sys/ddb/db_command.c:703
#6  0x816694d4 in db_trap (type=Variable "type" is not available.
) at /usr/src/sys/ddb/db_trap.c:93
#7  0x812a75ca in db_ktrap (type=0, code=0, regs=0x0)
at /usr/src/sys/arch/amd64/amd64/db_interface.c:152
#8  0x811c150c in trap (frame=0x0)
at /usr/src/sys/arch/amd64/amd64/trap.c:188
#9  0x81618a25 in calltrap ()
#10 0x81405af0 in pmap_flush_cache (addr=18446603336235712512, 
len=Variable "len" is not available.
)
at /usr/src/sys/arch/amd64/amd64/pmap.c:1288
#11 0x815b1a2b in gen8_ppgtt_clear_pte_range (vm=0x80994000, 
pdp=0x809941a0, start=Variable "start" is not available.
)
at /usr/src/sys/dev/pci/drm/i915/i915_gem_gtt.c:394
#12 0x81068ae8 in __i915_vma_unbind (vma=0x156, wait=Variable "wait" is 
not available.
)
at /usr/src/sys/dev/pci/drm/i915/i915_gem.c:3784
#13 0x8106aa3e in i915_gem_free_object (gem_obj=0x80dd16d0)
at /usr/src/sys/dev/pci/drm/i915/i915_gem.c:3817
#14 0x81332741 in drm_gem_object_handle_unreference_unlocked (obj=0x156)
at /usr/src/sys/dev/pci/drm/drm_gem.c:900
#15 0x81332626 in drm_gem_handle_delete (filp=0x1a7ec083, handle=3)
at /usr/src/sys/dev/pci/drm/drm_gem.c:424
#16 0x8169da2c in drm_do_ioctl (dev=0x3, minor=Variable "minor" is not 
available.
)
at /usr/src/sys/dev/pci/drm/drm_drv.c:859
#17 0x8169db2f in drmioctl (kdev=Variable "kdev" is not available.
)
at /usr/src/sys/dev/pci/drm/drm_drv.c:886
#18 0x8172fc5e in VOP_IOCTL (vp=Variable "vp" is not available.
) at /usr/src/sys/kern/vfs_vops.c:259
#19 0x8101d99d in vn_ioctl (fp=0x80dd7c80, com=205, 
data=Variable "data" is not available.
)
at /usr/src/sys/kern/vfs_vnops.c:487
#20 0x81479405 in sys_ioctl (p=0x80003020e028, v=0x3, 
retval=Variable "retval" is not available.
)
at /usr/src/sys/kern/sys_generic.c:516
#21 0x811c1a2c in syscall (frame=0xcd) at syscall_mi.h:78
#22 0x8105f2db in Xsyscall ()
(gdb)




# ps 

Re: Chrome crashes with 6.2

[Mihai Popescu]

> I've just tried Iridium, from UX it's basically Chromium from 6.1 -

> The i386 package of Chrome on 6.1 was slow

Folks, this is misc@ not ports@ or wishes@ !

Re: pf integration with dhcpd

[Carlos Cardenas]

On 10/27/17 12:04, Sonic wrote:

On Fri, Oct 27, 2017 at 2:48 PM, Carlos Cardenas  wrote:

On a 6.2-syspatch box, I wanted to start leveraging the pf integration dhcpd



pfctl -t dhcpd_X -T show


Do you see the current leases in "/var/db/dhcpd.leases"? A "reserved"
address would not show up there, nor would it be placed in the leased
table. Must truly be a dynamic lease.



That's what I thought...operator error.

I was expecting entries to appear in tables for reserved addresses as well.

Verified everything works (various tables being populated, entries being 
added/deleted)
using dynamic leases.

+--+
Carlos

Re: pf integration with dhcpd

[Sonic]

On Fri, Oct 27, 2017 at 2:48 PM, Carlos Cardenas  wrote:
> On a 6.2-syspatch box, I wanted to start leveraging the pf integration dhcpd

> pfctl -t dhcpd_X -T show

Do you see the current leases in "/var/db/dhcpd.leases"? A "reserved"
address would not show up there, nor would it be placed in the leased
table. Must truly be a dynamic lease.

pf integration with dhcpd

[Carlos Cardenas]

Howdy.

On a 6.2-syspatch box, I wanted to start leveraging the pf integration dhcpd 
has with the
* Abandoned
* Changed
* Leased

tables.

In pf, as a first step I added the table definitions:
table  persist
table  persist
table  persist

and loaded the rules.

Then added the respective flags to dhcpd via rcctl:
-A dhcpd_abandoned -C dhcpd_changed -L dhcpd_leased em1

Restarted dhcpd (now noticed that there's a dhcpd: pf table handler process).

I booted up some boxes and renewed some other dhcp leases to get some entries
in the tables but when I attempted to print them out via pfctl nothing is in 
them.

pfctl -t dhcpd_X -T show

pfctl -vvsTables also shows 0 entries for those tables

I guessing this is operator error on my part; Arethere any other items I need
to do to get it working?

Thanks in advance.

+--+
Carlos

Re: Chrome crashes with 6.2

[Allan Streib]

Cág  writes:

> I've just tried Iridium, from UX it's basically Chromium from 6.1 -
> gtk2, none of that dreadfull new design - whoever thought that it was a
> good idea to add A LOT of space, make letters even smaller and of an
> almost indistinguishable from the background colour for my half-blind
> eyes.

I'm running chromium-61.0.3163.100 from packages, OpenBSD 6.2 release amd64.

No crashes, no issues.

Allan

Re: Chrome crashes with 6.2

[Cág]

> Iridium is based on Chromium, isn't it slow on an i386 too?
> I actually would rather see Pale Moon or GTK+2 Chromium (as a separate
> package/flavour).

I've just tried Iridium, from UX it's basically Chromium from 6.1 -
gtk2, none of that dreadfull new design - whoever thought that it was a
good idea to add A LOT of space, make letters even smaller and of an
almost indistinguishable from the background colour for my half-blind
eyes.

-- 
caóc

Re: Chrome crashes with 6.2

[Dumitru Mișu Moldovan]

On 10/27/17 17:58, Cág wrote:
> Dumitru Mișu Moldovan wrote:
> 
>> If anyone wonders if there's still a usable (possibly full-blown)
>> browser for i386, I'm running SeaMonkey and Iridium (the latter for some
>> web apps, such as Google Music).  Firefox has got too bloated,
>> especially since 52.x builds (starting with 6.1) use multiple processes
>> and GTK+ 3.x.
> 
> Iridium is based on Chromium, isn't it slow on an i386 too?
> 
> I actually would rather see Pale Moon or GTK+2 Chromium (as a separate
> package/flavour).

The i386 package of Chrome on 6.1 was slow, but reliable (once you got
it started, as it crashed often when launched, as referenced in this
thread).  On 6.2 (both x86 arches), Chrome is even slower (because of
GTK+ 3.x, I suppose) and completely unusable for me on i386, as said.
Iridium on 6.2, on both arches, seems to be on par with Chrome from 6.1
(it's also built against GTK 2.x and perhaps a couple of versions ahead
of it).

For what it's worth, this is a reverse of a trend, up to 6.1 Chrome was
getting more and more usable with every release on i386 (I think I've
started using it in 5.8).  Not complaining, the writing is on the wall
for this arch.  Just trying to get what life is left in some old but
still usable hardware, fighting consumerism along the way.



signature.asc
Description: OpenPGP digital signature

Re: Chrome crashes with 6.2

[Cág]

Dumitru Mișu Moldovan wrote:

> If anyone wonders if there's still a usable (possibly full-blown)
> browser for i386, I'm running SeaMonkey and Iridium (the latter for some
> web apps, such as Google Music).  Firefox has got too bloated,
> especially since 52.x builds (starting with 6.1) use multiple processes
> and GTK+ 3.x.

Iridium is based on Chromium, isn't it slow on an i386 too?

I actually would rather see Pale Moon or GTK+2 Chromium (as a separate
package/flavour).

-- 
caóc

Re: Chrome crashes with 6.2 (Please update official download sites!)

[Cág]

Federico Giannici wrote:

> As this snapshot package will soon disappear for new ones with incompatible
> dependences, I think that it would be VERY useful for A LOT of people that
> this package be put in the official download sites.

They would have to wait for 6.3 or follow -current.

-- 
caóc

Re: mandoc output paper size

[Ingo Schwarze]

[ sending this particular one back to the list
  because it contains something useful for everyone and nothing private ]


Hi Jan,

Jan Stary wrote on Fri, Oct 27, 2017 at 12:46:00PM +0200:

> I produced a PS output with "man -Tps rm > rm.ps",
> with output paper set to a3, a4, and a5 in man.conf.
> This results, respectively, in
> 
>   %%DocumentMedia: Default 841 1190 0 () ()
>   %%DocumentMedia: Default 595 841 0 () ()
>   %%DocumentMedia: Default 419 595 0 () ()
> 
> which apparently are the right dimensions. However,
> the Minolta will print all of them on A4 paper,
> although it does have a stash of A3 and A5 too.
> 
> That's where I thought it might take a hint from the DSC comment,
> if I changed the "Default" to "A3" or "A4" or "A5", or if mandoc(1)
> itself put that in the DSC comments. I rewrote it manually before
> each printing, but the Minolta still prints them all on an A4:

That's interesting, but anecdotal.  It is neither surprising that
a specific printer selects paper as configured (in whichever way),
as opposed to inspecting fikes it is sent; nor would it be surprising
if other printers, or even the same one, or printer drivers on the
print server, could be configured to inspect the contents of
PostScript files to select paper.

The trouble is, i just don't know what firmwares and softwares do,
what they should do according to standards, and where to look for
standards in this respect.

Does anybody else know?

> Hm, so I can remove man.conf altogether,
> because even the default "letter" manpages
> will get printed on A4, which is what I want.

That's a bad idea.  The purpose of the -Opaper= option is not to
select paper, but to adjust the width and height that the document
content will require, and the primary purpose of the DocumentMedia
DSC instruction isn't selecting paper either.  but to inform how
the content was arranged.  If you use -Opaper=letter, margins will
be reasonable for letter size paper, but ugly for A4:  Since letter
paper is wider than A4 but not as tall, printing on A4 without
-Opaper=a4 will usually result in an awkwardly narrow right margin
and in wasted space at the bottom.

Yours,
  Ingo

Re: mandoc output paper size

[Ingo Schwarze]

Hi Walter,

Walter Alejandro Iglesias wrote on Fri, Oct 27, 2017 at 12:12:21PM +0200:

> First of all, I'm just a user like you trying to figure out
> how things work.

So am I.  That's how it starts.  I also read documentation,
standards, and code at need, and start fixing them once i
understand enough of them.

> So, don't expect from me some deep analysis, for that Ingo
> is the right person.

Not really.  I know a lot about mdoc(7), but almost nothing about
PostScript, DSC, and PDF.

Yours,
  Ingo

Re: mandoc output paper size

[Walter Alejandro Iglesias]

In article <20171027104221.gd9...@www.stare.cz> Jan Stary  wrote:
> On Oct 27 12:12:21, w...@roquesor.com wrote:
> > In article <20171026193138.ga41...@www.stare.cz> Jan Stary  
> > wrote:
> > > > > > In the ps file generated by mandoc you should have this line:
> > > > > > 
> > > > > >   %%DocumentMedia: Default 595 841 0 () ()
> > > > > > 
> > > > > > Where 595 841 correspond to A4.  If you set output paper to "letter"
> > > > > > that line will say:
> > > > > > 
> > > > > >   %%DocumentMedia: Default 612 790 0 () ()
> > > 
> > > Yes. It seems that these are just _comments_ to the PS interpreter
> > > and the "Default" is just an arbitrary given name, right?
> > > (Sorry, I don't know the language.) So GV just shows that,
> > > but it does not _determine_ the actual media size, right?
> > > Looking at term_ps.c, mandoc writes "Default ... " for every paper size.
> > > 
> > 
> > First of all, I'm just a user like you trying to figure out how things
> > work.  So, don't expect from me some deep analysis, for that Ingo is the
> > right person.
> > 
> > I answered you - based in what I intuitively observed - that mandoc
> > honors the paper size, and explained you why I think so.
> > 
> > I know about postcript language as much as you, as well as what gv takes
> > in care to print the document on the screen, so first I grep in the
> > ps file for 'a4|letter' strings and got nothing, then searching on the
> > Internet I found the dots equivalence and repeated the search this time
> > using '595 841|612 790'.  I did the same with documents generated by GNU
> > roff.  I found the "comment" I mentioned in the other message, so
> > I opened the ps file with vi(1), changed those numbers, and then
> > I opened the modified file with gv.  That's how I found out gv takes in
> > care that "comment" to figure out physical page dimensions.
> 
> Apparently, it does not: the dimensions are given explicitly in e.g.
> "%%DocumentMedia: Default 595 841 0 () ()", and the "Default"
> could just as well be "Foobar", as Ingo explained.
> 

That's the "comment" we're talking about since the beginning of the
thread, aren't we?  As I told you what I modified to do the test was the
numbers.

> > Finally, "default" means "default". :-)  Perhaps (guessing again), since
> > page size use is related to region settings, who designed postscript
> > (hence gv) thought convenient to honor some wide system setting (based
> > on locale?).
> 
> With output paper set to A3, A4, A5 in man.conf, "man -Tps rm > rm.ps"
> will produce a PostScript file with the correct dimensions,
> calling all the formats "Default". A printer (such us my Minolta)
> will print them all on A4, although it does have A3 and A5 paper too.
> Changing the "%%DocumentMedia: Default ..." line manualy to "A3" or "A5"
> does not change that.
> 
> I am not saying mandoc should write A3 or A4 or A5 instead of Default
> (it's the actual dimensions that matter), but perhaps such a DSC comment
> might help some appications. Apparently not GV, which just repeats the name,
> and not my Minolta, which prints on A4 anyway.

You know, too much people developing software without caring about what
others did before.  Who developed your Minolta software is not an
exception. ;-)


> 
> Jan
> 
> 

Walter

Re: mandoc output paper size

[Jan Stary]

On Oct 27 12:12:21, w...@roquesor.com wrote:
> In article <20171026193138.ga41...@www.stare.cz> Jan Stary  
> wrote:
> > > > > In the ps file generated by mandoc you should have this line:
> > > > > 
> > > > >   %%DocumentMedia: Default 595 841 0 () ()
> > > > > 
> > > > > Where 595 841 correspond to A4.  If you set output paper to "letter"
> > > > > that line will say:
> > > > > 
> > > > >   %%DocumentMedia: Default 612 790 0 () ()
> > 
> > Yes. It seems that these are just _comments_ to the PS interpreter
> > and the "Default" is just an arbitrary given name, right?
> > (Sorry, I don't know the language.) So GV just shows that,
> > but it does not _determine_ the actual media size, right?
> > Looking at term_ps.c, mandoc writes "Default ... " for every paper size.
> > 
> 
> First of all, I'm just a user like you trying to figure out how things
> work.  So, don't expect from me some deep analysis, for that Ingo is the
> right person.
> 
> I answered you - based in what I intuitively observed - that mandoc
> honors the paper size, and explained you why I think so.
> 
> I know about postcript language as much as you, as well as what gv takes
> in care to print the document on the screen, so first I grep in the
> ps file for 'a4|letter' strings and got nothing, then searching on the
> Internet I found the dots equivalence and repeated the search this time
> using '595 841|612 790'.  I did the same with documents generated by GNU
> roff.  I found the "comment" I mentioned in the other message, so
> I opened the ps file with vi(1), changed those numbers, and then
> I opened the modified file with gv.  That's how I found out gv takes in
> care that "comment" to figure out physical page dimensions.

Apparently, it does not: the dimensions are given explicitly in e.g.
"%%DocumentMedia: Default 595 841 0 () ()", and the "Default"
could just as well be "Foobar", as Ingo explained.

> Finally, "default" means "default". :-)  Perhaps (guessing again), since
> page size use is related to region settings, who designed postscript
> (hence gv) thought convenient to honor some wide system setting (based
> on locale?).

With output paper set to A3, A4, A5 in man.conf, "man -Tps rm > rm.ps"
will produce a PostScript file with the correct dimensions,
calling all the formats "Default". A printer (such us my Minolta)
will print them all on A4, although it does have A3 and A5 paper too.
Changing the "%%DocumentMedia: Default ..." line manualy to "A3" or "A5"
does not change that.

I am not saying mandoc should write A3 or A4 or A5 instead of Default
(it's the actual dimensions that matter), but perhaps such a DSC comment
might help some appications. Apparently not GV, which just repeats the name,
and not my Minolta, which prints on A4 anyway.

Jan

Re: mandoc output paper size

[Walter Alejandro Iglesias]

In article <20171026193138.ga41...@www.stare.cz> Jan Stary  
wrote:
> > > > In the ps file generated by mandoc you should have this line:
> > > > 
> > > >   %%DocumentMedia: Default 595 841 0 () ()
> > > > 
> > > > Where 595 841 correspond to A4.  If you set output paper to "letter"
> > > > that line will say:
> > > > 
> > > >   %%DocumentMedia: Default 612 790 0 () ()
> 
> Yes. It seems that these are just _comments_ to the PS interpreter
> and the "Default" is just an arbitrary given name, right?
> (Sorry, I don't know the language.) So GV just shows that,
> but it does not _determine_ the actual media size, right?
> Looking at term_ps.c, mandoc writes "Default ... " for every paper size.
> 

First of all, I'm just a user like you trying to figure out how things
work.  So, don't expect from me some deep analysis, for that Ingo is the
right person.

I answered you - based in what I intuitively observed - that mandoc
honors the paper size, and explained you why I think so.

I know about postcript language as much as you, as well as what gv takes
in care to print the document on the screen, so first I grep in the
ps file for 'a4|letter' strings and got nothing, then searching on the
Internet I found the dots equivalence and repeated the search this time
using '595 841|612 790'.  I did the same with documents generated by GNU
roff.  I found the "comment" I mentioned in the other message, so
I opened the ps file with vi(1), changed those numbers, and then
I opened the modified file with gv.  That's how I found out gv takes in
care that "comment" to figure out physical page dimensions.

As far as I understand postscript draws page contents using coordinates
and using the postscript dot as unit (as Ingo explained).  What gv does
is just trying to figure out the best way to print the document on
screen; when you select A4|Letter in the menu it only modifies the page,
the rest of dimensions stay the same.  Ingo will correct me if I'm wrong
about this, we're talking specifically about how gv shows you the
document in screen, it shouldn't affect how the document is printed on
paper (what I *guess* gv does in this case is to send the postscript
file "as is" to lpr or cups.)

Finally, "default" means "default". :-)  Perhaps (guessing again), since
page size use is related to region settings, who designed postscript
(hence gv) thought convenient to honor some wide system setting (based
on locale?).


> Jan
> 
> 

Walter

Re: Chrome crashes with 6.2

[Dumitru Mișu Moldovan]

On 10/26/17 14:26, Cág wrote:
> Federico Giannici wrote:
> 
>> Since I upgraded from OBSD 6.1 to 6.2 (amd64), at least half the time I
>> launch Chrome it crashes (with a "use after free").
> 
> We had a discussion in the ports@ list a couple of days ago:
> https://marc.info/?t=15085986372=1=2

Had these intermittent Chrome start-up crashes since at least OpenBSD
6.0, but now they seem to be gone with the latest package from -current
(brazenly installed on 6.2, as suggested on ports@).  Also an issue for
Iridium (crashes about every 5 launches).

By the way, on i386 Chrome has become unusable for me after updating to
6.2 (extensions crash on start, only simple pages such as openbsd.org
load, but the rendering process associated with the tab still crashes
after a few seconds).

Also, netsurf on i386 crashes every time for me with 6.2, even with no
saved settings.  The errors look similar:

netsurf-gtk(18043) in free(): use after free 0x831b7420

Will look into using sendbug(1) for the first time.



If anyone wonders if there's still a usable (possibly full-blown)
browser for i386, I'm running SeaMonkey and Iridium (the latter for some
web apps, such as Google Music).  Firefox has got too bloated,
especially since 52.x builds (starting with 6.1) use multiple processes
and GTK+ 3.x.

In the end, a plea to the awesome maintainer(s) of the most usable
Chromium BSD port: please consider Chrome/Iridium binary updates for
-stable, as the amazing Landry Breuil builds for Firefox and Thunderbird
since 6.1.  Not sure many people know about these third-party updates,
more at http://undeadly.org/cgi?action=article=20170425173917.

Shoutouts to the wonderful people of M:Tier too, I use their binary
updates as well!  Sadly, -current on amd64 is not an option for me, as I
use OpenBSD for work too and need to run a custom Python runtime, only
built for -release.  And using -current on i386 (for my home router / AP
/ multimedia station) is too painful…

Thanks for the great releases!  ;-]





signature.asc
Description: OpenPGP digital signature

Re: Chrome crashes with 6.2 (Please update official download sites!)

[Federico Giannici]

On 10/26/17 13:26, Cág wrote:

Federico Giannici wrote:


Since I upgraded from OBSD 6.1 to 6.2 (amd64), at least half the time I
launch Chrome it crashes (with a "use after free").


We had a discussion in the ports@ list a couple of days ago:
https://marc.info/?t=15085986372=1=2


I installed the current snapshot package (chromium-61.0.3163.100p1.tgz) 
and it solved the problem! Now I can use chrome again...


As this snapshot package will soon disappear for new ones with 
incompatible dependences, I think that it would be VERY useful for A LOT 
of people that this package be put in the official download sites.


Thank you

Re: Need help setting http headers using relayd (and httpd)

[Andreas Thulin]

Hi again!

So, read the book as suggested, got relayd working, headers set, HTTP
methods blocked just like I wanted (on my "test" box). However, when
starting to use TLS-by-relayd rather than by httpd, it seems I lost OCSP
stapling support. Does relayd.conf understand a line like

tls ocsp "/etc/ssl/pejorative.andreasthulin.se.ocsp"

or are there other ways of resolving this?

Cheers,
Andreas

--- httpd.conf ---

# $OpenBSD: httpd.conf,v 1.14 2015/02/04 08:39:35 florian Exp $
# Made from /etc/examples/httpd.conf 2015-03-19

# --

# Include MIME types instead of the built-in ones
types {
include "/usr/share/misc/mime.types"
}

# pejorative.andreasthulin.se - HTTP
server "pejorative.andreasthulin.se" {
listen on * port 8080
block return 301 "https://$SERVER_NAME$REQUEST_URI;
log syslog
}

# pejorative.andreasthulin.se - HTTPS
server "pejorative.andreasthulin.se" {
hsts subdomains
listen on * tls port 8082
tls certificate "/etc/ssl/pejorative.andreasthulin.se.fullchain.pem"
tls key "/etc/ssl/private/pejorative.andreasthulin.se.key"
tls ocsp "/etc/ssl/pejorative.andreasthulin.se.ocsp"
root "/htdocs/andreasthulin.se"
location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
directory { index "index.php" }
log syslog
}

--- relayd.conf ---

# $OpenBSD: relayd.conf,v 1.3 2014/12/12 10:05:09 reyk Exp $

# /etc/relayd.conf 2017-10-12

table  { 127.0.0.1 }
ext_ip = "192.168.1.40"

http protocol https {
tcp { nodelay, sack, socket buffer 65536, backlog 100 }
return error
block method CONNECT
block method DELETE
block method HEAD
block method OPTIONS
block method PUT
match response header remove "X-Powered-By"
match response header set "X-Bogus-Header" value "False"
match response header set "X-Frame-Options" value "deny"
match response header set "X-Content-Type-Options" value "nosniff"
match response header set "X-XSS-Protection" value "1; mode=block"
match response header append "Content-Security-Policy" value
"default-src 'none'"
match response header append "Content-Security-Policy" value
"script-src 'self'"
match response header append "Content-Security-Policy" value "style-src
'self'"
match response header append "Content-Security-Policy" value "img-src
'self'"
match response header append "Content-Security-Policy" value
"connect-src 'self'"
match response header append "Content-Security-Policy" value
"frame-ancestors 'none'"
}

relay "tlsforward" {
listen on $ext_ip port 4433 tls
protocol https
forward with tls to  port 8082 mode loadbalance check tcp
}

fre 13 okt. 2017 kl 09:28 skrev Andreas Thulin :

> Thank you, I just bought the Kindle version. :-)
>
> BR, Andreas
> fre 13 okt. 2017 kl. 02:16 skrev Bryan Harris :
>
>> There is a book called relayd and httpd. I think it has what you need.
>>
>> V/r,
>> Bryan
>>
>>
>>
>> > On Oct 12, 2017, at 1:33 PM, Andreas Thulin 
>> wrote:
>> >
>> > Hi!
>> >
>> > Before anything, thanks for yet another awesome OpenBSD release! I’ll
>> > extend my gratitude into the pockets of the Foundation and finally
>> donate
>> > this time.
>> >
>> > Then:
>> >
>> > I’m a relayd virgin. Consider all the following a lab exercise, I want
>> to
>> > learn and understand more.
>> >
>> > My target:
>> > Understanding how to score an A+ on the htbridge web server security
>> test.
>> > https://www.htbridge.com/websec/?id=BT1UmswV
>> >
>> > First objective:
>> > Set HTTP headers, such as
>> >
>> > CONTENT-SECURITY-POLICY
>> > X-CONTENT-TYPE-OPTIONS
>> > X-XSS-PROTECTION
>> >
>> > using relayd (since httpd can’t help out here).
>> >
>> > Assumptions etc:
>> > - I suppose only https traffic is in scope, since all http traffic is
>> > redirected to https.
>> > - Both httpd and relayd are (will be) run on the same 6.2 machine.
>> > - httpd runs just fine and scores an A+ on the htbridge TLS Server Test
>> > more or less out of the box. The web server test, however, was a
>> > disappointing F. :-)
>> >
>> > I’m only a mortal, so simply reading the relayd.conf man page and do
>> some
>> > trial-and-error has so far only made me go all CAPS. I seek examples (of
>> > something similar to the above use-case), a guide, turorial, or even a
>> > how-to to make this happen. I can learn all the config options and
>> settings
>> > afterwards, and keep tweaking and understanding.
>> >
>> > Anyone?
>> >
>> > Humbly,
>> > Andreas
>>
>

Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0

[Tom Smyth]

Hello Theo, Mike, All,

@Theo Understood it is important to protect developers and the project goals
... @Mike Thanks for your Generosity in the time you took on this thread,
Yes I want Mike to make VMM more awesome :)  @Mike keep up the good work

I cant disagree with any point that Theo made in his email on this tread
that said,
unfortunately I cant always choose my hypervisor and I dearly want to run
OpenBSD on it proxmox...

I do think (based on the fact that OpenBSD 6.0-6.2 works on PVE 4.4 it is
probably a (virtual Hardware issue ) .. not necessarily an OpenBSD issue
I will raise this with the PVE Support guys (as I have already done since mid
July )

Any further posts on this thread from me will be (hopefully for other OpenBSD
 users benefit (if I make progress)
and certainly not intended as a request or a distraction for Core
OpenBSD Developers

All the Best,

Tom Smyth

On 27 October 2017 at 06:37, Theo de Raadt  wrote:
> Tom,
>
> A virtual machine setup is an operating system running on an operating
> system on top of an operating system.
>
> OK, not quite.  The middle one, the VM itself, is as a bit less
> complex than a full operating system as machine-independent code goes,
> but nevertheless the machine-dependent bat-shit-crazy stuff is far
> more complex with gobs of extremely messy nuances face it on both
> sides because x86 is a fucking minefield
>
> Everyone needs to adjust their expectation that all 3 layers are
> perfect, AND not assume that it is our layer doing the wrong thing
>
> Really the layers should simplify but the current marketplace is still
> gaining more value out of product differentiation than
> simplification+convergence, both sw and hw
>
> Even if our subsystem isn't doing something 'right', it is NOT the
> stated goal of OpenBSD to run well on every garbage VM, because it has
> become impossible for the little guy to be perfect.
>
> Concerted efforts to diagnose and improve these low-level issues uses
> the same crowd of people who are trying to improve other edges which
> may be more important.  do you want our vmm to work well?  or do you
> want us to work better on someone else's vmm?  Sorry, limited
> skillset, pick what you want mlarkin to focus on!  But that is unfair,
> and even if he listened to your wishlist, UNPRODUCTIVE.
>
> Where does this go?  Get ready for monopolies in everything, or
> oligopolies at best... or fight their establishment.
>
>> Just to say the gaps in ping response seems  get worse as the uptime 
>> increases
>> ie
>> with the uptime around 5 minutes the gaps between ping results are around 1 
>> sec
>> (what I consider normal)
>> with the uptime around 2 hrs 45 minutes the gaps between ping results are 13 
>> sec
>> with the uptime 8 hrs 30 minutes  the gaps between ping results are 35 
>> seconds
>>
>> Output of sysctl kern.timecounter below
>>
>> kern.timecounter.tick=1
>> kern.timecounter.timestepwarnings=0
>> kern.timecounter.hardware=acpihpet0
>> kern.timecounter.choice=i8254(0) acpihpet0(1000) acpitimer0(1000)
>> dummy(-100)
>>
>> I will change the ACPI  now to i8254  and report back later on
>> Thanks
>>
>>
>> On 26 October 2017 at 20:25, Mike Belopuhov  wrote:
>> > On Thu, Oct 26, 2017 at 19:05 +0100, Tom Smyth wrote:
>> >> Lads,
>> >>
>> >> Im pleased to say that my testing of OpenBSD 6.1  and OpenBSD 6.2
>> >> Release
>> >> amd64 ,
>> >> appear to work  a little better  in Proxmox PVE5.1 as released this week,
>> >>
>> >> I used iso version 5.1-722cc488-1 from Proxmox
>> >> Updated on 24 October 2017
>> >>
>> >> The Console no longer freezes but after a few hours
>> >> the console (vga console accessed via Proxmox webinterface seems
>> >> to lag a little
>> >> the interval between pings for instance takes up to 13 seconds, which
>> >> is a bit strange...  ie it takes 13 seconds for each line of Ping result
>> >> which is u
>> >> Ill report more feedback later, but at least OpenBSD is not freezing
>> >> as bad in this
>> >> version of Proxmox PVE 5.1
>> >>
>> >
>> > Hi,
>> >
>> > Can you please show us the output of "sysctl kern.timecounter".
>> > If you're currently using an acpihpet0, can you please try
>> > switching to the acpitimer0 (and if that doesn't help, i8254) via
>> >
>> >  sysctl kern.timecounter.hardware=acpitimer0
>> >
>> > and attempt to reproduce the 13 secod delay.
>> >
>> > Regards,
>> > Mike
>>
>