sensorsd and acpiac0.indicator0?

[Job Snijders]

Hi all,

I'm tweaking how my laptop behaves depending on whether it is pluggde
into AC or not. Any hints or alternative suggestions are welcome.

This is my config:

/etc/sensorsd.conf:

acpiac0.indicator0:command=/etc/sensorsd/ac_power %2

and this is the script:

#!/bin/sh

echo $1 >> /root/test

case $1 in
On)
/sbin/sysctl -w machdep.lidaction=0
;;
Off)
/sbin/sysctl -w machdep.lidaction=1
;;
*)
echo "unknown state $1"
exit 1
;;
esac

I'd expect the lidaction to change when I plug my X270 into AC, or
unplug it, but nothing seems to happen. Running 'sensorsd -d -c 1'
didn't output anything. /root/test stays empty.



Kind regards,

Job

Re: Image viewer alternative to eog

[Matthew Fioravante]

You can try the display program that comes with the imagemagick package.
Pretty barebones image viewer.

On Mon, Nov 27, 2017 at 9:17 AM, Marko Cupać  wrote:

> On Sun, 26 Nov 2017 20:15:14 -0200
> "x9p"  wrote:
>
> > Is there a good/safe and light image viewer? Was used to eog, but it
> > has too many "vfprintf %s NULL" in messages. gimp is too big and good
> > for play with images, In need of smth fast.
> ...
> > Thank you all for the inputs. feh suited best. lots of command line
> > options, folder slideshow and option to specify geometry was a big
> > plus.
>
> I don't know if that counts as 'good/safe and light', but I use XFCE's
> ristretto. When jumping sinking ship of GNOME some years ago I tried
> to go all the way down to openbox and its ecosystem (including feh),
> but it was a bit too much of a change for me for my primary work
> environment (I still use openbox and friends in some thin client
> setups).
>
> XFCE and its ecosystem are not as lightweight, but from my point of
> view they have balanced usability and weight for my primary laptop use
> case.
> --
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
>
> Marko Cupać
> https://www.mimar.rs/
>
>

Re: Image viewer alternative to eog

[Marko Cupać]

On Sun, 26 Nov 2017 20:15:14 -0200
"x9p"  wrote:

> Is there a good/safe and light image viewer? Was used to eog, but it
> has too many "vfprintf %s NULL" in messages. gimp is too big and good
> for play with images, In need of smth fast.
...
> Thank you all for the inputs. feh suited best. lots of command line
> options, folder slideshow and option to specify geometry was a big
> plus.

I don't know if that counts as 'good/safe and light', but I use XFCE's
ristretto. When jumping sinking ship of GNOME some years ago I tried
to go all the way down to openbox and its ecosystem (including feh),
but it was a bit too much of a change for me for my primary work
environment (I still use openbox and friends in some thin client
setups).

XFCE and its ecosystem are not as lightweight, but from my point of
view they have balanced usability and weight for my primary laptop use
case.
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: Intel HSUART/8250 LPSS

[Kevin Chadwick]

On Fri, 24 Nov 2017 20:26:02 +0100 (CET)


> > I am looking into getting Intel HSUART/8250 LPSS support working.
> > Has anyone done any work on this out of tree. Or is there anything
> > I should be aware of.  

Unfortunately whilst this would have made a nice introduction to
OpenBSD coding we have taken the decision to add our own UARTS to give
us independence from the ridiculous Intel firmware insecurities so if
Intel Trusted Execution and other configuration changes cannot mitigate
the risks then we can switch to e.g. an older AMD board as needed.

NERF is Linux only apparently.

Sorry for the noise and I hope I can pick this up in my free time
(not that i have had much for a looong time) but wouldn't be surprised
if this gets done by others way before then. Gives me the opportunity to
observe OpenBSD practices for longer in any case (less annoying
questions ;)).

Regards

Re: IPSec Flow and SA to unexpected subnet

[Tobias Urdin]

Had the same problem with a shitty Netgear on the other end.

OpenBSD happily accepted the flow with a 0/0 from forcing all traffic to
the destination over that tunnel.


I logged in to the Netgear GUI and explicitly set the subnets to tunnel
instead of all which was selected before.

Best regards


On 11/27/2017 05:52 AM, Paul Suh wrote:
> Folks, 
>
> I set up a router using 6.2-stable, and created IKEv1 tunnels using isakmpd, 
> something I've done many times before. The other end is a Sonicwall NSA 4500, 
> which I've used as an endpoint before as well. My ipsec.conf file is: 
>
>> ike active esp \
>> from 192.168.144.0/24 \
>> to {   10.101.0.0/16, \
>> 10.102.0.0/16, \
>> 10.103.0.0/16, \
>> 10.104.0.0/16, \
>> 172.27.199.0/24 } \
>> peer [Sonicwall IP] \
>> main \
>> auth hmac-sha1 \
>> enc aes-128 \
>> group modp2048 \
>> lifetime 28800 \
>> quick \
>> auth hmac-sha1 \
>> enc aes-128 \
>> group modp2048 \
>> lifetime 28800 \
>> psk [PSK redacted]
> However, the output of ipsecctl -s flow is: 
>
>> # ipsecctl -s flow   
>> 
>> FLOWS:
>> flow esp in from 10.104.0.16 to 192.168.144.0/24 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type use
>> flow esp out from 192.168.144.0/24 to 10.104.0.16 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type require
>> flow esp in from 10.103.0.16 to 192.168.144.0/24 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type use
>> flow esp out from 192.168.144.0/24 to 10.103.0.16 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type require
>> flow esp in from 10.102.0.16 to 192.168.144.0/24 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type use
>> flow esp out from 192.168.144.0/24 to 10.102.0.16 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type require
>> flow esp in from 10.104.0.0/16 to 192.168.144.0/24 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type use
>> flow esp out from 192.168.144.0/24 to 10.104.0.0/16 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type require
>> flow esp in from 10.103.0.0/16 to 192.168.144.0/24 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type use
>> flow esp out from 192.168.144.0/24 to 10.103.0.0/16 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type require
>> flow esp in from 10.102.0.0/16 to 192.168.144.0/24 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type use
>> flow esp out from 192.168.144.0/24 to 10.102.0.0/16 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type require
>> * flow esp in from 172.16.0.0/16 to 192.168.144.0/24 peer 65.75.99.66 
>> srcid 24.51.107.65/32 dstid 65.75.99.66/32 type use
>> * flow esp out from 192.168.144.0/24 to 172.16.0.0/16 peer 65.75.99.66 
>> srcid 24.51.107.65/32 dstid 65.75.99.66/32 type require
>> flow esp in from 172.27.199.0/24 to 192.168.144.0/24 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type use
>> flow esp out from 192.168.144.0/24 to 172.27.199.0/24 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type require
>> flow esp in from 10.101.0.0/16 to 192.168.144.0/24 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type use
>> flow esp out from 192.168.144.0/24 to 10.101.0.0/16 peer 65.75.99.66 srcid 
>> 24.51.107.65/32 dstid 65.75.99.66/32 type require
> Note the two starred flows that are not listed in my ipsec.conf 
> configuration. The 172.16.0.0/16 subnet does exist on the Sonicwall end, and 
> I'm pretty sure that the Sonicwall is requesting that a flow be set up for 
> that subnet. However, I would think that my OpenBSD router would not create 
> that flow since it's not in my ipsec.conf. 
>
> Any ideas why it's being created anyway? I won't be in a position to see if 
> the flow is really live until tomorrow morning. 
>
>
> --Paul
>
>
>
>