smartd - Currently unreadable (pending) sectors

[Raimo Niskanen]

Hi all.

I just wanted to share a small success story, partly for the archives.

I have an OpenBSD 6.5 amd64 server whose smartd has been whining about:
  smartd[666]: Device: /dev/sd0c, 1 Currently unreadable (pending) sectors

smartctl -a /dev/sd0c showed attribute 197 Current_Pending_Sector to be 1.

The disk is part of a softraid mirror sd2, so I offlined the disk
and rebuilt the mirror, thusly:
  bioctl -O /dev/sd0a sd2
  bioctl -R /dev/sd0a sd2

After a few hours of parity rebuild smartd has stopped spamming
/var/log/messages, and smartctl -a shows Current_Pending_Sector to be 0.
The parity rebuild, as expected, must have re-written the broken sector and
the disk reallocated the sector.

Sysadmin is happy!

Except that smartctl -a informs me that the disk predicts its power-on
lifetime to be 382 days, which apparently is not good.  The other disk
in the mirror says nothing of this, so I have a very early warning
about getting a new disk...  (sd0a's Reallocated_Sector_Ct is 148
while sd0b's is 0)

Best regards
-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Re: When will OpenBSD become a friendly place for bug reporters?

[ropers]

On 11/07/2019, Ingo Schwarze  wrote:
> Hi Ian,

Hi Ingo,

I've just noticed yet another false positive where Gmail has
classified your email as spam here for the n-th time.  I'm not sure if
that's just happening to my mailbox, or if it's Gmail-wide or, worse,
if lots of MTAs out there treat your emails as spam.
(There seems to be a trend where big corps are quite happy to
discourage people from running their own MTAs and increasingly throw
their weight around rejecting anything that isn't credentialled up the
wazoo with SPF, DKIM, DMARC or whatever, and of course there are
powerful interests who want to deanonymise the Net, which may be
related.)
Either way, maybe this is something you'll want to look into from your end?

> ropers wrote on Thu, Jul 11, 2019 at 12:41:45AM +0200:
>
>> While I'm personally only or mainly interested in Alt+numeric input,
>> if altnumd existed, it would probably be comparatively easy to then
>> extend it and add support for Alt+u thru Alt+u10, with the U
>> becoming a reserved keyword unambiguously signifying that what follows
>> will be a Unicode code point between U+ and U+10.
>
> There is no reason to make it different.  ASCII is a subset of Unicode,
> with the same numbering.  So the "U" looks redundant to me.

There are several reasons why it isn't redundant:

1. Alt codes are decimal, but Unicode code points are hexadecimal.
Alt+73, Alt+78, Alt+71, Alt+79 "INGO" would become "sxqy" if treated as hex.

2. Unicode code points (format: U+, mostly, though it goes up to U+10)
are NOT character bytes. I quoted Wikipedia on this in my email two days ago:
>> [4] :
>> "The compromise solution that was eventually found and developed into
>> Unicode was to break the assumption (dating back to telegraph codes)
>> that each character should always directly correspond to a particular
>> sequence of bits. Instead, characters would first be mapped to a
>> universal intermediate representation in the form of abstract numbers
>> called __code points__. Code points would then be represented in a
>> variety of ways and with various default numbers of bits per character
>> (__code units__) depending on context. To encode code points higher
>> than the length of the code unit, such as above 256 for 8-bit units,
>> the solution was to implement variable-width encodings where an escape
>> sequence would signal that subsequent bits should be parsed as a
>> higher code point."
You are correct that in the case of the variable-length UTF-8 and for
the 128 (non-extended/7-bit) ASCII characters only, this isn't a
problem, because with them, code points (U+) and code units
(bytes) actually ARE still substantially identical. That saving grace
pretty much does not exist with other, non-UTF-8 Unicode encodings.
Okay, maybe it still does if you drop all the leading zeroes over
multiple bytes. However:

3. I would be wary of dropping leading zeroes in the case of Unicode
code point support. With Alt codes, the precedent of optionally
allowing the dropping of leading zeroes has been set, but pretty much
all Unicode documentation I'm aware of consistently prints code points
in the U+ format (or longer, up to U+10 where applicable).
There's a good argument for supporting code point entry exactly as
written, and nobody writes U+0 through U+FFF.
If you install the gucharmap package
, it has a Character Details tab
where you can not only see how much UTF-8 code units (bytes) can
differ from code points (U+), but you can also see that even for
those low code points where both match, the U+ is still not
printed with leading zeroes omitted.

4. One also should be as restrained and conservative as is practical
in terms of "claiming" key combinations, especially claiming them
system-wide. Yes, users could set up some hotkey somewhere that kills
and relaunches altnumd (I'm not even sure if that belongs in altnumd
itself), but you don't want to do that all the time just to type a key
combo that collides with altnumd. "Hold down Alt while typing U,
 then release Alt" is quite specific, and could reduce
cases where a sequence in .altnumrc collides with something else.
"Hold down Alt while typing up to three digits on the number pad, then
release Alt" is also relatively specific, though perhaps one might
accept non-numpad digit entry too, or make that choice configurable.
Alt+ single digit is more likely to collide with something, though
the long-standing precedent of Alt codes existing at least on some
platforms may make that less likely.

5. Perhaps there could be an opportunity for simplifying and unifying
Alt+U and existing iffy Ctrl+Shift U+ support? OTOH, maybe
it's better to deliberately not collide with that other method and
maybe that's a good reason for a universal Unicode code point method
to reside at its own key combo. Remember, my actual goal is Alt code
suppor

pflow version 10 not set on boot

[Andrew Klaus]

I noticed that my pflow device keeps rebooting with Netflow version 5,
despite "pflowproto 10" being set in /etc/hostname.pflow0. I'm running
OpenBSD 6.5 with the latest patches.

ifconfig:
pflow0: flags=41 mtu 1448
index 9 priority 0 llprio 3
pflow: sender: [] receiver: []:2055 version: 5
groups: pflow

/etc/hostname.pflow0:
up
flowdst []:2055 flowsrc []
pflowproto 10

After boot, if I manually initiate "sh /etc/netstart pflow0", it then
starts using version Netflow v10 as expected. I may be able to add to
/etc/rc.local to do this on reboot, but thought I'd see if there was
anything else that it could be.

Thanks,
Andrew

Re: When will OpenBSD become a friendly place for bug reporters?

[Ingo Schwarze]

Hi NilsOla,

NilsOla Nilsson wrote on Thu, Jul 11, 2019 at 11:24:24PM +0200:

> I am using cwm and ksh and at present my compose key
> work in st and in gvim, but not in xterm.
> I am on current updated a few weeks ago.

Oh.  Thank you for the hint.  Given my clumsiness with X keyboard
configuration, i assumed it was just me, but your additional data
indicates there may actually be a regression in xterm(1).

Who knows what a GTK leviathan like gvim is doing.  But suckless
software is about the opposite of bloatware and i would be quite
surprised if it internally re-implemented the Compose mechanism.
So the fact that Compose works in the x11/st(1) port (which i
can confirm) means that i probably do have Compose correctly
configured and that xterm(1) is somehow breaking the characters
it receives from X - not all of them, but those where Compose
was involved.

The above suspicion is supported by the fact that Compose also
works in xedit(1).  It even works in xclipboard(1), xman(1),
nedit(1), except that these programs don't support UTF-8 but
appear to be hardcoded to Latin-1, such that the entered UTF-8
characters appear as garbage two-character sequences.

To me, this looks suspiciously like a bug now.  :-(

Yours,
  Ingo


> On Thu, Jul 11, 2019 at 09:18:41PM +0200, Ingo Schwarze wrote:
> > Hi Ian,
> > 
> > ropers wrote on Thu, Jul 11, 2019 at 12:41:45AM +0200:
> > 
> > > While I'm personally only or mainly interested in Alt+numeric input,
> > > if altnumd existed, it would probably be comparatively easy to then
> > > extend it and add support for Alt+u thru Alt+u10, with the U
> > > becoming a reserved keyword unambiguously signifying that what follows
> > > will be a Unicode code point between U+ and U+10.
> > 
> > There is no reason to make it different.  ASCII is a subset of Unicode,
> > with the same numbering.  So the "U" looks redundant to me.
> > 
> > > There's a huge competence gap between us,
> > 
> > Quite likely.  I'm so clueless that right now, i can't even seem to get
> > Compose to work even though i'm sure i had it working in the past.
> > This is on amd64-current, inside xterm(1) and ksh(1):
> > 
> >$ locale
> >   LANG=
> >   LC_COLLATE="en_US.UTF-8"
> >   LC_CTYPE="en_US.UTF-8"
> >   LC_MONETARY="en_US.UTF-8"
> >   LC_NUMERIC="en_US.UTF-8"
> >   LC_TIME="en_US.UTF-8"
> >   LC_MESSAGES="en_US.UTF-8"
> >   LC_ALL=en_US.UTF-8
> >$ setxkbmap -query -v -v -v 
> >   Setting verbose level to 8
> >   locale is en_US.UTF-8
> >   Trying to load rules file ./rules/base...
> >   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
> >   Success.
> >   Applied rules from base:
> >   rules:  base
> >   model:  pc105
> >   layout: de
> >   Trying to build keymap using the following components:
> >   keycodes:   xfree86+aliases(qwertz)
> >   types:  complete
> >   compat: complete
> >   symbols:pc+de+inet(pc105)+terminate(ctrl_alt_bksp)
> >   geometry:   pc(pc105)
> >   rules:  base
> >   model:  pc105
> >   layout: de
> > 
> > At this point, the caps key toggles caps lock, i.e. pressing
> > 
> >   caps a caps a
> > 
> > results in the input "Aa".
> > 
> >$ setxkbmap -option compose:caps -v -v -v   
> >   Setting verbose level to 8
> >   locale is en_US.UTF-8
> >   Trying to load rules file ./rules/base...
> >   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
> >   Success.
> >   Applied rules from base:
> >   rules:  base
> >   model:  pc105
> >   layout: de
> >   options:compose:caps
> >   Trying to build keymap using the following components:
> >   keycodes:   xfree86+aliases(qwertz)
> >   types:  complete
> >   compat: complete
> >   symbols:pc+de+inet(pc105)+terminate(ctrl_alt_bksp)+compose(caps)
> >   geometry:   pc(pc105)
> > 
> > Now, the caps key no longer toggles caps lock and becomes a dead key,
> > i.e. pressing
> > 
> >   caps , c caps " a
> > 
> > results in the input "ca".  However, the resulting input is really
> > ASCII-c ASCII-a rather than the expected c-cedille a-umlaut.
> > It looks like Compose works well enough to discard the , and ",
> > but not well enough to actually generate non-ASCII characters.
> > 
> > Somewhat grumpy today,
> >   Ingo
> 
> -- 
> Nils Ola Nilsson, 🐞 email nils...@abc.se, tel +46-70-374 69 89

Re: When will OpenBSD become a friendly place for bug reporters?

[NilsOla Nilsson]

I am using cwm and ksh and at present my compose key
work in st and in gvim, but not in xterm.
I am on current updated a few weeks ago.

/NilsOla

On Thu, Jul 11, 2019 at 09:18:41PM +0200, Ingo Schwarze wrote:
> Hi Ian,
> 
> ropers wrote on Thu, Jul 11, 2019 at 12:41:45AM +0200:
> 
> > While I'm personally only or mainly interested in Alt+numeric input,
> > if altnumd existed, it would probably be comparatively easy to then
> > extend it and add support for Alt+u thru Alt+u10, with the U
> > becoming a reserved keyword unambiguously signifying that what follows
> > will be a Unicode code point between U+ and U+10.
> 
> There is no reason to make it different.  ASCII is a subset of Unicode,
> with the same numbering.  So the "U" looks redundant to me.
> 
> > There's a huge competence gap between us,
> 
> Quite likely.  I'm so clueless that right now, i can't even seem to get
> Compose to work even though i'm sure i had it working in the past.
> This is on amd64-current, inside xterm(1) and ksh(1):
> 
>$ locale
>   LANG=
>   LC_COLLATE="en_US.UTF-8"
>   LC_CTYPE="en_US.UTF-8"
>   LC_MONETARY="en_US.UTF-8"
>   LC_NUMERIC="en_US.UTF-8"
>   LC_TIME="en_US.UTF-8"
>   LC_MESSAGES="en_US.UTF-8"
>   LC_ALL=en_US.UTF-8
>$ setxkbmap -query -v -v -v 
>   Setting verbose level to 8
>   locale is en_US.UTF-8
>   Trying to load rules file ./rules/base...
>   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
>   Success.
>   Applied rules from base:
>   rules:  base
>   model:  pc105
>   layout: de
>   Trying to build keymap using the following components:
>   keycodes:   xfree86+aliases(qwertz)
>   types:  complete
>   compat: complete
>   symbols:pc+de+inet(pc105)+terminate(ctrl_alt_bksp)
>   geometry:   pc(pc105)
>   rules:  base
>   model:  pc105
>   layout: de
> 
> At this point, the caps key toggles caps lock, i.e. pressing
> 
>   caps a caps a
> 
> results in the input "Aa".
> 
>$ setxkbmap -option compose:caps -v -v -v   
>   Setting verbose level to 8
>   locale is en_US.UTF-8
>   Trying to load rules file ./rules/base...
>   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
>   Success.
>   Applied rules from base:
>   rules:  base
>   model:  pc105
>   layout: de
>   options:compose:caps
>   Trying to build keymap using the following components:
>   keycodes:   xfree86+aliases(qwertz)
>   types:  complete
>   compat: complete
>   symbols:pc+de+inet(pc105)+terminate(ctrl_alt_bksp)+compose(caps)
>   geometry:   pc(pc105)
> 
> Now, the caps key no longer toggles caps lock and becomes a dead key,
> i.e. pressing
> 
>   caps , c caps " a
> 
> results in the input "ca".  However, the resulting input is really
> ASCII-c ASCII-a rather than the expected c-cedille a-umlaut.
> It looks like Compose works well enough to discard the , and ",
> but not well enough to actually generate non-ASCII characters.
> 
> Somewhat grumpy today,
>   Ingo

-- 
Nils Ola Nilsson, 🐞 email nils...@abc.se, tel +46-70-374 69 89


signature.asc
Description: PGP signature

Re: lenovo thinkpoad with nvidia and intel graphics?

[paul wisehart]

Thanks! That's very helpful :)

On Wed, Jul 10, 2019 at 06:14:33PM +0100, Tommi Pernila wrote:
> On Wed, 10 Jul 2019 at 16.45, Matthew Graybosch 
> > I have a T430s with both Intel integrated graphics and discrete NVidia
> > graphics. I disabled the latter at the BIOS level since Xenocara
> > doesn't support it, and the system worked fine with just the integrated
> > Intel graphics.
> >
> > You might be able to do the same with most of the T440p and T540p
> > units, but check the specs to be sure.
> >
> 
> It's good to note that most Lenovo laptops that have Intel and Nvidia GPUs,
> have the external displays wired only to the Nvidia GPU (T540p for sure as
> i have this model).
> So think if you can you can live without the external displays.

Re: When will OpenBSD become a friendly place for bug reporters?

[Ingo Schwarze]

Hi Ian,

ropers wrote on Thu, Jul 11, 2019 at 12:41:45AM +0200:

> While I'm personally only or mainly interested in Alt+numeric input,
> if altnumd existed, it would probably be comparatively easy to then
> extend it and add support for Alt+u thru Alt+u10, with the U
> becoming a reserved keyword unambiguously signifying that what follows
> will be a Unicode code point between U+ and U+10.

There is no reason to make it different.  ASCII is a subset of Unicode,
with the same numbering.  So the "U" looks redundant to me.

> There's a huge competence gap between us,

Quite likely.  I'm so clueless that right now, i can't even seem to get
Compose to work even though i'm sure i had it working in the past.
This is on amd64-current, inside xterm(1) and ksh(1):

   $ locale
  LANG=
  LC_COLLATE="en_US.UTF-8"
  LC_CTYPE="en_US.UTF-8"
  LC_MONETARY="en_US.UTF-8"
  LC_NUMERIC="en_US.UTF-8"
  LC_TIME="en_US.UTF-8"
  LC_MESSAGES="en_US.UTF-8"
  LC_ALL=en_US.UTF-8
   $ setxkbmap -query -v -v -v 
  Setting verbose level to 8
  locale is en_US.UTF-8
  Trying to load rules file ./rules/base...
  Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
  Success.
  Applied rules from base:
  rules:  base
  model:  pc105
  layout: de
  Trying to build keymap using the following components:
  keycodes:   xfree86+aliases(qwertz)
  types:  complete
  compat: complete
  symbols:pc+de+inet(pc105)+terminate(ctrl_alt_bksp)
  geometry:   pc(pc105)
  rules:  base
  model:  pc105
  layout: de

At this point, the caps key toggles caps lock, i.e. pressing

  caps a caps a

results in the input "Aa".

   $ setxkbmap -option compose:caps -v -v -v   
  Setting verbose level to 8
  locale is en_US.UTF-8
  Trying to load rules file ./rules/base...
  Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
  Success.
  Applied rules from base:
  rules:  base
  model:  pc105
  layout: de
  options:compose:caps
  Trying to build keymap using the following components:
  keycodes:   xfree86+aliases(qwertz)
  types:  complete
  compat: complete
  symbols:pc+de+inet(pc105)+terminate(ctrl_alt_bksp)+compose(caps)
  geometry:   pc(pc105)

Now, the caps key no longer toggles caps lock and becomes a dead key,
i.e. pressing

  caps , c caps " a

results in the input "ca".  However, the resulting input is really
ASCII-c ASCII-a rather than the expected c-cedille a-umlaut.
It looks like Compose works well enough to discard the , and ",
but not well enough to actually generate non-ASCII characters.

Somewhat grumpy today,
  Ingo

Re: adding ipv6 and pppoe to my firewall

[Stuart Henderson]

On 2019-07-11, shadrock uhuru  wrote:
>> hi  everyone
>> i have a dual redundant firewall setup the same as the example given at
>> https://www.openbsd.org/faq/pf/carp.html
>> i was originally with virgin media but have moved to a provider
>> offering ipv4, ipv6 and fixed ip addresses,
>> i am now trying  to add ipv6 and pppoe to the firewall.
>> i haven't found an example on the web of a carp, pppoe and ipv6 firewall ,
>> so i've had to pieced together bits of info from different places
>> using the following hypothetical addresses this is my planned
>> configuration ,
>> please feel free to correct where there are mistakes.
>>
>> IPv6 Address:
>> ND Prefix: :::::/64
>> PD Prefix: ::::/48
>> IPv4 Address:     12.34.56.78 (Subnet mask 255.255.255.255)
>>
>>     fw1 em0: 192.168.2.2 (lan)
>>     fw1 em1: 192.168.3.2 (wan)
>>     fw1 em2: 192.168.4.1 (pfsync)
>>     fw2 em0: 192.168.2.3 (lan)
>>     fw2 em1: 192.168.3.3 (wan)
>>     fw2 em2: 192.168.4.2 (pfsync)
>>     LAN shared IP: 192.168.2.1 (carp_lan)
>>     WAN/internet shared IP: 12.34.56.78 (carp_wan)
>>
>> fw1
>> /etc/hostname.em0
>> inet 192.168.2.2 255.255.255.0 NONE
>> inet6 autoconf -autoconfprivacy -soii
>> inet6 alias :::::100 64
>>
>> /etc/hostname.em1
>> inet 192.168.3.2 255.255.255.0 NONE
>> inet6 autoconf -autoconfprivacy -soii
>> inet6 alias :::::200 64
>>
>> /etc/hostname.em2
>> inet 192.168.4.1 255.255.255.0 NONE
>>
>> /etc/hostname.carp_lan.nic
>> inet 192.168.2.1 255.255.255.0 192.168.2.255 vhid 1 carpdev em0 advskew
>> 5 pass $PASSWORDIN
>> inet6 autoconf -autoconfprivacy -soii
>> inet6 alias :::::300 prefixlen 64 vhid 1 carpdev em0
>> advskew 5 pass $PASSWORDIN
>>
>> /etc/hostname.carp_wan.nic
>> inet 12.34.56.78 255.255.255.255 'broadcast_addr' vhid 2 carpdev em1
>> advskew 100 pass $PASSWORDOUT
>> inet6 autoconf -autoconfprivacy -soii
>> inet6 alias :::::400 prefixlen 64 vhid 2 carpdev $em1
>> advskew 100 pass $PASSWORDOUT
>>
>>
>> fw2
>> /etc/hostname.em0
>> inet 192.168.2.3 255.255.255.0 NONE
>> inet6 autoconf -autoconfprivacy -soii
>> inet6 alias :::::150 64
>>
>> /etc/hostname.em1
>> inet 192.168.3.3 255.255.255.0 NONE
>> inet6 autoconf -autoconfprivacy -soii
>> inet6 alias :::::250 64
>>
>> /etc/hostname.em2
>> inet 192.168.4.2 255.255.255.0 NONE
>>
>> /etc/hostname.carp_lan.nic
>> inet 192.168.2.1 255.255.255.0 192.168.2.255 vhid 1 carpdev em0 advskew
>> 5 pass $PASSWORDIN
>> inet6 autoconf -autoconfprivacy -soii
>> inet6 alias :::::350 prefixlen 64 vhid 1 carpdev em0
>> advskew 5 pass $PASSWORDIN
>>
>> /etc/hostname.carp_wan.nic
>> inet 12.34.56.78 255.255.255.255 'broadcast_addr' vhid 2 carpdev em1
>> advskew 100 pass $PASSWORDOUT
>> inet6 autoconf -autoconfprivacy -soii
>> inet6 alias :::::450 prefixlen 64 vhid 2 carpdev $em1
>> advskew 100 pass $PASSWORDOUT
>>
>> /etc/hostname.pppoe
>> mtu 1500
>> inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev em1/carp2 authproto chap
>> authname "XXX@isp" authkey "XXX" up
>> dest 0.0.0.1
>> inet6 -autoconfprivacy
>> inet6 autoconf
>> !/sbin/route add default -ifp pppoe0 0.0.0.1
>> !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 -priority 8
>>
>> % cat /etc/rc.d/dhcp6c
>> #!/bin/sh
>>
>> daemon="/usr/local/sbin/dhcp6c"
>>
>> . /etc/rc.d/rc.subr
>>
>> rc_reload=NO
>>
>> rc_cmd $1
>>
>> % cat /etc/dhcp6c.conf
>> interface pppoe0 {
>>     send ia-pd 0;
>>     send domain-name-servers;
>>     send rapid-commit;
>> };
>>
>> id-assoc pd {
>>     prefix-interface em1 {
>>         sla-id 0;
>>         sla-len 8;
>>     };
>> };
>>
>> % echo 'dhcp6c_flags=pppoe0' | tee -a /etc/rc.conf.local
>> dhcp6c_flags=pppoe0
>>
>> % echo '!/etc/rc.d/dhcp6c restart' | tee -a /etc/hostname.pppoe0
>> !/etc/rc.d/dhcp6c restart
>>
>> % /etc/rc.d/dhcp6c restart
>> dhcp6c(ok)
>>     };
>> };
>>
>> question 1
>> in hostname.pppoe do i set pppoedev to the wan facing nic or the wan
>> carp interface on each firewall

pppoe runs directly on an ethernet or vlan interface. OpenBSD doesn't
have any particular support for failover with pppoe carp+pppoe.
I would suggest disabling the second machine while you get it
working on one.

You can then probably bring the second one into play using ifstated
to only bring the pppoe interface up and run rad when the machine has
master on another carp interface (but tbh I've never got round to
setting that up anywhere at a pppoe site ..)

>> question 2
>> in dhcpv6.conf do i set the interface and prefix_interface to the wan
>> and lan facing nic or the wan and lan carp interface on each firewall

If you need DHCPv6-PD then don't hardcode the addresses on the
inside interfaces, just let PD fetch them. (I have no idea about the
ancient wide-dhcpv6, for the config I'm using for ipv6 with
PPPoE and DHCPv6-PD, pkg_add dhcpcd and look at the pkg-readme).

But your ISP might just route you the block anyway without using
PD. In tha

Re: uvm_fault / page fault trap GENERIC.MP#114 amd64

[Stuart Henderson]

On 2019-07-11, Wolly  wrote:
> How can I get the crash trace etc., when the keyboard after the crash is
> not working?
>
> Is there a possibilty to boot in a trace/debug mode with logging all?
>
> I can't enter any command from here:
> https://www.openbsd.org/ddb.html
>
> Todays current Kernel is crashing directly after the boot.
> Keyboard, IPMI is not working.
>
> all kernel > #109 are crashing here.
>
>>> uvm_fault (0x81da40f8, 0xe4, 0, 2) -> e
>>> kernel: page fault trap,code=0
>>> Stopped at pfi_kif_ref +0x3f: addl $0x1,0xe4(%rdi)
>
>

Update to a newer snap, this has been fixed today.

Alternatively boot single-user and temporarily remove PF rules
that use source tracking (max-src-conn-rate and friends)

Re: Apache 2.4 not running php OpenBSD 6.4

[Georgs]

Hi,

Seems like Apache is not using the module, i.e. it treats as text, it needs to 
run you php code. I think if you share some relevant parts of your 
configuration and prove that you have the necessary tools installed and working 
you will get better feedback.

Regards,
George


On July 11, 2019 2:40:42 AM EDT, mansoor  wrote:
>Hi,
>I hope you guys are doing great.
>
>I am using OpenBSD 6.4, apache-httpd-2.4.35, php version 5.6.
>I have disabled default httpd of OpenBSD, now apache2 is showing plain
>php
>code in browser it doesn't process php at all.
>
>I couldn't find solution to this problem on stackOverflow (or any other
>site
>on internet).
>Please help me if anyone know about this problem. 
>Thanks.
>
>
>
>
>--
>Sent from:
>http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: uvm_fault / page fault trap GENERIC.MP#114 amd64

[Wolly]

How can I get the crash trace etc., when the keyboard after the crash is
not working?

Is there a possibilty to boot in a trace/debug mode with logging all?

I can't enter any command from here:
https://www.openbsd.org/ddb.html

Todays current Kernel is crashing directly after the boot.
Keyboard, IPMI is not working.

all kernel > #109 are crashing here.

>> uvm_fault (0x81da40f8, 0xe4, 0, 2) -> e
>> kernel: page fault trap,code=0
>> Stopped at pfi_kif_ref +0x3f: addl $0x1,0xe4(%rdi)

Re: Apache 2.4 not running php OpenBSD 6.4

[Solene Rapenne]

On Wed, Jul 10, 2019 at 11:40:42PM -0700, mansoor wrote:
> Hi,
> I hope you guys are doing great.
> 
> I am using OpenBSD 6.4, apache-httpd-2.4.35, php version 5.6.
> I have disabled default httpd of OpenBSD, now apache2 is showing plain php
> code in browser it doesn't process php at all.
> 
> I couldn't find solution to this problem on stackOverflow (or any other site
> on internet).
> Please help me if anyone know about this problem. 
> Thanks.
> 

You need to install the php apache module. It should be explained in the
php README file in /usr/local/share/doc/pkg-readmes/

Re: Apache 2.4 not running php OpenBSD 6.4

[Tony Boston]

IT is not about going to sites like stackoverflow or asking for solutions on 
mailing lists especially THIS topic doesn’t have anything to do with openbsd.
You should learn the basics and your “issue” is very basic. 
I bet the logs you’ll get from either application tell you what the problem is 
but you don’t seem to even know that this would be the first start to solving 
problems..


--
Tony

GPG-FP: 49CC8250 CDCF2183 6209C1AE 625677C1 F7783D5F
Threema: DN8PJX4Z





> On 11. Jul 2019, at 08:40, mansoor  wrote:
> 
> Hi,
> I hope you guys are doing great.
> 
> I am using OpenBSD 6.4, apache-httpd-2.4.35, php version 5.6.
> I have disabled default httpd of OpenBSD, now apache2 is showing plain php
> code in browser it doesn't process php at all.
> 
> I couldn't find solution to this problem on stackOverflow (or any other site
> on internet).
> Please help me if anyone know about this problem. 
> Thanks.
> 
> 
> 
> 
> --
> Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
> 

Apache 2.4 not running php OpenBSD 6.4

[mansoor]

Hi,
I hope you guys are doing great.

I am using OpenBSD 6.4, apache-httpd-2.4.35, php version 5.6.
I have disabled default httpd of OpenBSD, now apache2 is showing plain php
code in browser it doesn't process php at all.

I couldn't find solution to this problem on stackOverflow (or any other site
on internet).
Please help me if anyone know about this problem. 
Thanks.




--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html

Re: Problem with SSH Internet traffic outgoing endpoint with dynamic port forwarding

[Darren Tucker]

On Thu, 11 Jul 2019 at 20:55, morgan.loner  wrote:
[...]
> What was missing? Please advice.

Suggestions:
 - run "ssh -vvv" to crank up the ssh client's verbosity, you should
see the port forward requests (or not, if ssh is not seeing them for
some reason).
 - test with nc -x as the socks client to an IP address as well as
domain name.  The test to an IP address will remove the DNS variable.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Problem with SSH Internet traffic outgoing endpoint with dynamic port forwarding

[morgan.loner]

I try to setup SSH tunnel with SOCKS listener to have dynamic port forwarding.

Connection between SSH client and SSHd server established successfully, and SSH
SOCKS listener accepts all the incoming connections from SOCKS proxy, but no 
outgoing
traffic to public Internet IPs on servers' side has appeared.

As DNS resolver I use DNSCrypt proxy on Clients' side and all the 53 UDP DNS 
requests
redirects by PF to DNSCrypt and out from Clients' machine without SSH 
tunneling. So
SSH tunnel is intended to protect traffic only, not DNS.

What was missing? Please advice.

-
Client on OpenBSD 6.4 ssh SOCKS listener
/usr/bin/ssh -f -N -D 127.0.0.1: user@1.2.3.4 -i /etc/ssh/ssh_host_key

All 53 UDP -> DNSCrypt proxy 127.0.0.1:53 -> Encrypted DNS to Internet from 
Client
# cat /etc/pf.conf
pass out quick on egress inet proto {tcp, udp} from (egress) to any user \
_dnscrypt-proxy flags S/SA keep state queue (dnscrypt_egress, ack_egress)
-
||
\/
-
Server OpenBSD 6.5 sshd traffic outgoing point
IP 1.2.3.4:22
PF is disabled by pfctl -d
# cat /etc/mygate
4.3.2.1

# cat /etc/ssh/sshd_config
Port 22
#AddressFamily any
ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
LogLevel DEBUG

# Authentication:

#LoginGraceTime 30s
PermitRootLogin yes
#PermitRootLogin forced-commands-only
#StrictModes yes
MaxAuthTries 3
MaxSessions 5

PubkeyAuthentication yes

AuthorizedKeysFile  .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

#PasswordAuthentication yes
#PermitEmptyPasswords no

#ChallengeResponseAuthentication yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
GatewayPorts clientspecified
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
ClientAliveInterval 1
ClientAliveCountMax 2
#UseDNS no
#PidFile /var/run/sshd.pid

#MaxStartups 10:30:100
PermitTunnel yes
#ChrootDirectory none
#VersionAddendum none

#Banner none

Subsystem   sftp/usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server
-

Re: possible athn(4) bug in 6.5-current involving AR5418 chipset on used ThinkPad T60

[Stefan Sperling]

On Wed, Jul 10, 2019 at 08:43:26PM -0400, Matthew Graybosch wrote:
> On Wed, 10 Jul 2019 18:32:37 +0200
> Stefan Sperling  wrote:
> 
> > So 11g works, and only 11n mode is broken?
> > Your AP probably doesn't support 11a mode.
> 
> Sorry, Stefan, but I didn't think to try 11n mode. I must have taken
> your instructions too literally.
> 
> However, I tried 11n at home after work, and that didn't work. Neither
> did 11a or 11g. Worse, when I tried connecting to my phone's access
> point using 11g, that didn't work either. Nor did rebooting help.
> 
> I *was* able to make wifi work using a MX Linux LiveUSB, so I don't
> think it's the hardware (and I really don't want to go back to Linux).

Sounds like the driver is unable to send any frames at all :-/

> > If you could test kernels of older releases and check whether 11n mode
> > was working at some point, that would help me.
> 
> Would pulling the bsd.rd for 6.4 and temporarily reverting to that
> release help?

Testing just bsd.rd is enough. If the bsd.rd environment is too limiting
you could also install to a USB stick and boot from it for testing purposes.

Either approach should suffice to test a wifi connection.

Re: When will OpenBSD become a friendly place for bug reporters?

[ropers]

On 11/07/2019, Matthew Graybosch  wrote:
> On Thu, 11 Jul 2019 00:41:45 +0200
> ropers  wrote:
>
>> Any hints on how to even start with that hardest part, or what to read
>> or where to look would be MORE than welcome.
>
> Hi, ropers. I've been reading this thread about altnumd and using
> alt+000 to enter arbitrary Unicode characters like people did on DOS
> and Windows. I noticed that nobody mentioned that X11 already has a
> method for entering arbitrary Unicode characters using pre-defined key
> sequences. It's called the "Compose" key (aka the Multi_Key in X11
> header files).

I mentioned that, somewhat near the top of my earlier email:

>> I am very aware of the Compose key support in X11, and this isn't
>> about that. This isn't about inputting characters in a good or better
>> way. This is about inputting characters in exactly THAT way
>> (Alt+Numpad), "just like mammy used to".

However, I didn't go into details, and though Compose doesn't solve
what I want to do, you're right that these details may help somebody,
so thanks anyway.

> https://en.wikipedia.org/wiki/Compose_key
>
> PC and Mac keyboards don't provide a physical compose key, but you can
> remap a key you don't usually use (like Caps Lock or the right-hand ALT
> or CTRL keys) using setxkbmap(1).
>
> Here's the command I use in my ~/.xsession file:
>
> setxkbmap -option compose:caps &
>
> Hopefully this helps somebody.

(Personally, I like to use compose:rwin, though that right Windows key
doesn't exist on some (old or laptop) keyboards.)

I'm pretty damn sure Ingo knows about Compose too. His complaint was
subtly different also:

> > I'm not aware of a simple method of entering Unicode codepoints
> > numerically that works everywhere, and i find that lack annoying.

Emphasis on "that works everywhere".

I am aware of the "Ctrl+Shift U " Unicode input method too,
but this again does not work everywhere:


However (this also from my above email):

>> [4] Also, the console would only support a small subset anyway; I have
some questions and thoughts on that too, but that's really another
issue for another day, perhaps.

Plus, Ingo wrote:

> > What might be useful is understanding all the details of how
> > all the existing methods in ws* and X* (and possibly elsewhere?)
> > work, then simplify them.

Even if Ingo's interest in understanding and simplifying existing
methods, --and arguably Alt codes *are* an existing method, albeit one
that works "elsewhere" but not on Unix-likes thus far--, could be
partially aligned with what I want to do, and would hopefully be
simplifying things instead of being like the invention of another text
editor ,
Unicode support on console would necessarily be limited.  I alluded to
that in my [4] footnote, and maybe I should write up my extensive
thoughts on that, Real Soon Now.  The major limitation there is that
console font support is limited to 256 characters, or hackishly 512,
and the ways around that are not pretty.  So while Alt+, and
*perhaps* also Alt+u could possibly be made to work the same
throughout X11 and console, Alt+u would be limited on console.
I am aware that Alt+u would compete with Ctrl+Shift U
(which latter doesn't work everywhere).
Either way, actual Unicode character input methods like this, and
let's include Compose here, could perhaps only *input* characters
like, say, the ☃ U+2603 SNOWMAN, but the console would at best
*display* \xE2\x98\x83 in place of that, because the Unicode snowman
is not in any console font.
If we want to be precise about it, console "support" for *displaying*
a character that was typed is a different issue than inputting it
though, and being limited to a subset here and there shouldn't count
against the idea of installing universal plumbing.

And again, to me the hardest part of that is figuring out
>> how or where or what exactly to insert into the, or what, keyboard buffer.
>> (...)
>> Any hints on how to even start with that hardest part, or what to read
or where to look would be MORE than welcome.

Many thanks in advance,
Ian

Re: dhcpd on openbsd no class / if

[Stuart Henderson]

On 2019/07/11 09:00, Mik J wrote:
> Hello Stuart,
> 
> I had read it
> AUTHORS: dhcpd is based on software from the Internet Software Consortium
> 
> But maybe I didn't ask my question properly.
> 
> It seems that a lot of features are missing and when I read "based" I 
> understood that there was
> little differences.

It's based on a version from c.2004 and has had major changes.

> Everything about classes seems not to work so I was wondering if there was a 
> different syntax
> or if some features were not supported.

If it's not in the manpage, it's not supported.

Re: dhcpd on openbsd no class / if

[Mik J]

 Hello Stuart,
I had read itAUTHORS: dhcpd is based on software from the Internet Software 
Consortium
But maybe I didn't ask my question properly.
It seems that a lot of features are missing and when I read "based" I 
understood that there was little differences.
Everything about classes seems not to work so I was wondering if there was a 
different syntax or if some features were not supported.
Regards

Le mercredi 10 juillet 2019 à 19:29:42 UTC+2, Stuart Henderson 
 a écrit :  
 
 On 2019-07-10, Mik J  wrote:
> Hello,
> I'm wondering if the dhcpd provided by openbsd is the same as the one from isc

see AUTHORS in dhcpd(8).

The ISC one is available in the isc-dhcp-server package, but it doesn't have the
privsep and BPF locking that base dhcpd has.