Re: puppet and cross-platform password hashes

[Raf Czlonka]

On Fri, Feb 05, 2016 at 03:48:02PM GMT, Joshua Smith wrote:
> On Fri, Feb 05, 2016 at 04:04:47PM +0100, Joerg Jung wrote:
> > > On 05 Feb 2016, at 08:33, Peter N. M. Hansteen  wrote:
> > >
> > > I'm assuming I'm not the first to encounter this -
> > >
> > > the scenario is a group of admins who have so far run mainly Linux and 
> > > some
> > Solaris,
> > > and who have a fairly well developed Puppet setup for maintaining among
> > other things
> > > local users for admins to log in and fix, running sudo as required. For
> > non-admin role
> > > users, LDAP (AD) is considered good enough, but that's out of scope here.
> > >
> > > The interesting part is when we start introducing OpenBSD machines to the
> > mix, and
> > > creating users with the password hashes from Linux or Solaris fails,
> > apparently because
> > > the hashes are not bcrypt hashes.
> > >
> > > I see two obvious solutions to this. Either
> > >
> > > 1) skip password logins, require key logins for all local users (they're
> > >   admins after all), tackle any extra privilege needs via specific sudo or
> > >   doas config, or
> > >
> > > 2) maintain a separate set of user definitions with bcrypt hashes for the
> > OpenBSD
> > >   boxes in the puppet setup. Then supplement as before with sudo or doas
> > tricks.
> > >
> > > My next question is, what other workable options are there? When you found
> > yourself
> > > in a similar situation, introducing OpenBSD to an existing environment of
> > other
> > > unixes, what did you do? Are there other solutions out there, possibly 
> > > with
> > more
> > > sophisticated approaches than the ones I've mentioned here?
> > 
> > There is: 3) dynamically chose the pass hash string depending on OS.
> > Last time I used puppet was with 2.x release, so I do not know the exact
> > syntax,
> > but something like this should work:
> > 
> > @user {
> > myuser:
> > comment => “my user”,
> > ensure = “present”,
> > password => case $operatingsystem {
> > OpenBSD: { “$2b$….” },
> > RedHat: { “$6$...” },
> > Solaris: { “...” }
> >}
> > }
> > 
> > I do similar in Ansible, setting a dynamic variable “user_hash” to either
> > “blowfish” or “sha512”
> > depending on the OS, and the use this variable to choose the right hash 
> > string
> > from an dict,
> > which looks like this:
> > 
> > users:
> >   root:
> > blowfish: $2b$...
> > sha512: $6$…
> > 
> > …referencing it later (in loops), like this:
> > 
> > user: name=root password=users[root][user_hash]
> > 
> > > Good suggestions may merit a beverage of choice (within reason) at the
> > first
> > > possible opportunity.
> > > --
> > > Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> > > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> > > "Remember to set the evil bit on all malicious network traffic"
> > > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
> 
> +1 for Joerg's suggestion, he beat me to typing it but we do something
> similar here.  We have a "local_user" wrapper class that has some logic
> built in to determine the proper password hash to apply based on the OS
> and some other things.

I also use case statement for this and other, not necessarily
OS-dependant, bits.

Raf

Re: puppet and cross-platform password hashes

[Solène Rapenne]

Le 2016-02-05 08:33, Peter N. M. Hansteen a écrit :

I'm assuming I'm not the first to encounter this -

The interesting part is when we start introducing OpenBSD machines to
the mix, and
creating users with the password hashes from Linux or Solaris fails,
apparently because
the hashes are not bcrypt hashes.

I see two obvious solutions to this. Either


Hi, there may be a third option, using bcrypt for passwords on OpenBSD.
See man 5 login.conf, field localcipher

I never tried but it should do what you want.

Re: puppet and cross-platform password hashes

[Stuart Henderson]

On 2016-02-05, Solène Rapenne  wrote:
> Le 2016-02-05 08:33, Peter N. M. Hansteen a écrit :
>> I'm assuming I'm not the first to encounter this -
>> 
>> The interesting part is when we start introducing OpenBSD machines to
>> the mix, and
>> creating users with the password hashes from Linux or Solaris fails,
>> apparently because
>> the hashes are not bcrypt hashes.
>> 
>> I see two obvious solutions to this. Either
>
> Hi, there may be a third option, using bcrypt for passwords on OpenBSD.
> See man 5 login.conf, field localcipher
>
> I never tried but it should do what you want.
>
>

OpenBSD already supports bcrypt, but only supports bcrypt (in base, anyway;
you could of course provide a bsd-auth authentication type to handle something
else, the interface is reasonably simple to work with).

Another possibility would be to teach the other OS about bcrypt, maybe this 
helps
http://serverfault.com/questions/10585/enable-blowfish-based-hash-support-for-crypt/11685#11685

Re: puppet and cross-platform password hashes

[Joshua Smith]

On Fri, Feb 05, 2016 at 04:04:47PM +0100, Joerg Jung wrote:
> > On 05 Feb 2016, at 08:33, Peter N. M. Hansteen  wrote:
> >
> > I'm assuming I'm not the first to encounter this -
> >
> > the scenario is a group of admins who have so far run mainly Linux and some
> Solaris,
> > and who have a fairly well developed Puppet setup for maintaining among
> other things
> > local users for admins to log in and fix, running sudo as required. For
> non-admin role
> > users, LDAP (AD) is considered good enough, but that's out of scope here.
> >
> > The interesting part is when we start introducing OpenBSD machines to the
> mix, and
> > creating users with the password hashes from Linux or Solaris fails,
> apparently because
> > the hashes are not bcrypt hashes.
> >
> > I see two obvious solutions to this. Either
> >
> > 1) skip password logins, require key logins for all local users (they're
> >   admins after all), tackle any extra privilege needs via specific sudo or
> >   doas config, or
> >
> > 2) maintain a separate set of user definitions with bcrypt hashes for the
> OpenBSD
> >   boxes in the puppet setup. Then supplement as before with sudo or doas
> tricks.
> >
> > My next question is, what other workable options are there? When you found
> yourself
> > in a similar situation, introducing OpenBSD to an existing environment of
> other
> > unixes, what did you do? Are there other solutions out there, possibly with
> more
> > sophisticated approaches than the ones I've mentioned here?
> 
> There is: 3) dynamically chose the pass hash string depending on OS.
> Last time I used puppet was with 2.x release, so I do not know the exact
> syntax,
> but something like this should work:
> 
> @user {
> myuser:
> comment => “my user”,
> ensure = “present”,
> password => case $operatingsystem {
> OpenBSD: { “$2b$….” },
> RedHat: { “$6$...” },
> Solaris: { “...” }
>}
> }
> 
> I do similar in Ansible, setting a dynamic variable “user_hash” to either
> “blowfish” or “sha512”
> depending on the OS, and the use this variable to choose the right hash string
> from an dict,
> which looks like this:
> 
> users:
>   root:
> blowfish: $2b$...
> sha512: $6$…
> 
> …referencing it later (in loops), like this:
> 
> user: name=root password=users[root][user_hash]
> 
> > Good suggestions may merit a beverage of choice (within reason) at the
> first
> > possible opportunity.
> > --
> > Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> > "Remember to set the evil bit on all malicious network traffic"
> > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

+1 for Joerg's suggestion, he beat me to typing it but we do something
similar here.  We have a "local_user" wrapper class that has some logic
built in to determine the proper password hash to apply based on the OS
and some other things.
-- 
Joshua Smith
Lead Systems Administrator WVNET

Montani Semper Liberi

Re: puppet and cross-platform password hashes

[Joerg Jung]

> On 05 Feb 2016, at 08:33, Peter N. M. Hansteen  wrote:
>
> I'm assuming I'm not the first to encounter this -
>
> the scenario is a group of admins who have so far run mainly Linux and some
Solaris,
> and who have a fairly well developed Puppet setup for maintaining among
other things
> local users for admins to log in and fix, running sudo as required. For
non-admin role
> users, LDAP (AD) is considered good enough, but that's out of scope here.
>
> The interesting part is when we start introducing OpenBSD machines to the
mix, and
> creating users with the password hashes from Linux or Solaris fails,
apparently because
> the hashes are not bcrypt hashes.
>
> I see two obvious solutions to this. Either
>
> 1) skip password logins, require key logins for all local users (they're
>   admins after all), tackle any extra privilege needs via specific sudo or
>   doas config, or
>
> 2) maintain a separate set of user definitions with bcrypt hashes for the
OpenBSD
>   boxes in the puppet setup. Then supplement as before with sudo or doas
tricks.
>
> My next question is, what other workable options are there? When you found
yourself
> in a similar situation, introducing OpenBSD to an existing environment of
other
> unixes, what did you do? Are there other solutions out there, possibly with
more
> sophisticated approaches than the ones I've mentioned here?

There is: 3) dynamically chose the pass hash string depending on OS.
Last time I used puppet was with 2.x release, so I do not know the exact
syntax,
but something like this should work:

@user {
myuser:
comment => “my user”,
ensure = “present”,
password => case $operatingsystem {
OpenBSD: { “$2b$….” },
RedHat: { “$6$...” },
Solaris: { “...” }
   }
}

I do similar in Ansible, setting a dynamic variable “user_hash” to either
“blowfish” or “sha512”
depending on the OS, and the use this variable to choose the right hash string
from an dict,
which looks like this:

users:
  root:
blowfish: $2b$...
sha512: $6$…

…referencing it later (in loops), like this:

user: name=root password=users[root][user_hash]

> Good suggestions may merit a beverage of choice (within reason) at the
first
> possible opportunity.
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: panic: mtx_enter: locking against myself

[mxb]

Any one from @devs have time to pick it up?

This is a new env. , so I have time to investigate.
Access can be provided on need bases.

//mxb

> On 4 feb. 2016, at 15:46, mxb  wrote:
>
> Found it in dmesg buffer:
>
> Stopped at  Debugger+0x9:   leave
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
> IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
>
> ddb{0}> trace
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> mtx_enter() at mtx_enter+0x60
> sofree() at sofree+0xa0
> in_pcbdetach() at in_pcbdetach+0x40
> tcp_close() at tcp_close+0xad
> tcp_timer_2msl() at tcp_timer_2msl+0x90
> softclock() at softclock+0x315
> softintr_dispatch() at softintr_dispatch+0x8b
> Xsoftclock() at Xsoftclock+0x1f
> --- interrupt ---
> (null)() at 0x8
> end of kernel
> end trace frame: 0x11020001, count: -11
>
> ddb{0}>  show registers
> rdi  0x1
> rsi0x282
> rbp   0x8000221c68f8
> rbx   0x813285e0mtx_enter+0x60
> rdx0
> rcx   0x8188c640cpu_info_primary
> rax  0x1
> r80x8000221c6818
> r9   0x1
> r100
> r11   0x8000221c66b0
> r120x100
> r13   0x8000221c6908
> r14   0xff011d088010
> r150
> rip   0x81343b09Debugger+0x9
> cs   0x8
> rflags 0x286
> rsp   0x8000221c68e8
> ss  0x10
> Debugger+0x9:   leave
>
> ddb{0}> ps
> PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
> 19921  12801  19921  0  30x83  poll  systat
> 12801569  12801  0  30x8b  pause ksh
>   569  23137569  0  30x92  selectsshd
> 13678  1  13678  0  30x83  ttyin getty
>  9776  1   9776  0  30x83  ttyin getty
>  3392  1   3392  0  30x83  ttyin getty
> 24230  1  24230  0  30x83  ttyin getty
> 14469  1  14469  0  30x83  ttyin getty
> 29209  1  29209  0  30x80  poll  cron
>  4796   4087   4087 95  30x90  kqreadsmtpd
>   269   4087   4087 95  30x90  kqreadsmtpd
> 28144   4087   4087 95  30x90  kqreadsmtpd
> 13626   4087   4087 95  30x90  kqreadsmtpd
>  4756   4087   4087 95  30x90  kqreadsmtpd
> 23276   4087   4087103  30x90  kqreadsmtpd
>  4087  1   4087  0  30x80  kqreadsmtpd
> 29277  28344  28344 89  30x90  kqreadrelayd
> 15361  28344  28344 89  30x90  kqreadrelayd
> 28344  26987  28344 89  30x90  kqreadrelayd
> *18801   1528   1528 89  70x10relayd
> 15066   1528   1528 89  30x90  kqreadrelayd
>  1528  26987   1528 89  30x90  kqreadrelayd
> 14013  26987  14013 89  30x90  kqreadrelayd
> 25397  26987  25397 89  30x90  kqreadrelayd
> 26987  1  26987  0  30x80  kqreadrelayd
> 23945  0  0 85  30x90  kqreadospfd
> 12948  0  0 85  30x90  kqreadospfd
> 0  1  0  0  30x80  kqreadospfd
> 23137  1  23137  0  30x80  selectsshd
> 10031  27507981 83  30x90  poll  ntpd
> 27507981981 83  30x90  poll  ntpd
>   981  1981  0  30x80  poll  ntpd
> 12220  25415  25415 74  30x90  bpf   pflogd
> 25415  1  25415  0  30x80  netio pflogd
>  3275  32486  32486 73  30x90  kqreadsyslogd
> 32486  1  32486  0  30x80  netio syslogd
> 14861  0  0  0  3 0x14200  pgzerozerothread
> 24670  0  0  0  3 0x14200  aiodoned  aiodoned
> 29165  0  0  0  3 0x14200  syncerupdate
> 27875  0  0  0  3 0x14200  cleaner   cleaner
>   645  0  0  0  3 0x14200  reaperreaper
> 17692  0  0  0  3 0x14200  pgdaemon  pagedaemon
>   766  0  0  0  3 0x14200  bored crypto
>  4241  0  0  0  3 0x14200  pftm  pfpurge
>  9257  0  0  0  3  0x40014200  acpi0 acpi0
> 25569  0  0  0  7  0x40014200idle1
>  7980  0  0  0  3 0x14200  

Re: panic: mtx_enter: locking against myself

[Mark Kettenis]

> panic: mtx_enter: locking against myself
> Starting stack trace...
> panic() at panic+0x10b
> mtx_enter() at mtx_enter+0x60
> sofree() at sofree+0xa0
> in_pcbdetach() at in_pcbdetach+0x40
> tcp_close() at tcp_close+0xad
> tcp_timer_2msl() at tcp_timer_2msl+0x90
> softclock() at softclock+0x315
> softintr_dispatch() at softintr_dispatch+0x8b
> Xsoftclock() at Xsoftclock+0x1f

This has been fixed in -current; see kern/uipc_socket.c rev 1.142.

Perhaps you can trick somebody to get that one into -stable.

Re: gnome crashes with current snapshot

[Tiemen Werkman]

> -Oorspronkelijk bericht-
> Van: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Namens
> Tiemen Werkman
> Verzonden: donderdag 4 februari 2016 17:49
> Aan: misc@openbsd.org
> Onderwerp: gnome crashes with current snapshot
>
> >Synopsis:gnome crashes
> >Environment:
>   System  : OpenBSD 5.9
>   Details : OpenBSD 5.9 (GENERIC.MP) #1868: Mon Feb  1
> 20:02:36 MST 2016
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.M
> P
>
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> gnome crashes with the following error:
>
> "Oh no! Something has gone wrong.
> A problem has occurred and the system can't recover.
> please log out and try again."
>
> The only thing I've altered is to disable my ATI Radeon 270
> with the
> following command:
> # config -e -o /bsd /bsd
> > disable radeondrm
> > quit
> # reboot
>
> The bios is set to use cpu graphics without multimonitor
> support to
> make sure that radeondrm isn't in some way interfering with
> Xorg.
>
> I first installed snapshot version #1866 and updated each time
> there
> was a newer version. The current version I am running is #1868.
> I've also tried it with and without uefi, but that didn't make
> a
> difference. UEFI runs fine btw.
>
> I've added the dmesg using sendbug run as root and Xorg.0.log
> below.
>
> If somebody could help me out I would appreciate it.
> If you need more information please let me know, I would be
> happy to
> provide anything you need.
>

I've been looking through all settings today and I finally made it
work.
The problem was the machdep.allowaperture was set to 2 in
/etc/sysctl.conf. I commented out the line (the only line in
sysctl.conf) and gnome started up without a hitch.
I didn't create the sysctl.conf file, it was generated by the installer.
I think the question about running X answered yes creates it.

Anyway I'm happy everything works, I thought I'd let others know

Tiemen Werkman

Why regexp works different in stock vi vs. vim

[Артур Истомин]

I have file where first symbols are tabs:

Sally tried really really hard
Timmy tried really really really hard
Johnny tried really really really really hard

When I search tabs in stock vi with '/\t'. It finds all words 'tried'. In
vim it finds tabs. Why? In fact, I can't find tabs in stock vi anyhow.My 
system is OpenBSD 5.8

Thanks.

Re: Why regexp works different in stock vi vs. vim

[Tethys]

On Fri, Feb 5, 2016 at 6:13 PM, Артур Истомин
 wrote:

> When I search tabs in stock vi with '/\t'. It finds all words 'tried'. In
> vim it finds tabs. Why?

Because \t is a literal t in a standard regular expression. vim uses a
different regular expression library that interprets it as a tab. If
you want to search for a tab, you can just use a literal tab in the
search string. In the past, I've needed to prefix it with ^v, but that
doesn't seem to be necessary on any of the systems I have in front of
me right now.

Tet

--
I saw cout being shifted "Hello world" times to the left and stopped
right there. — Steve Gonedes

Re: Why regexp works different in stock vi vs. vim

[Ax0n]

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ex.1?query=vi

⟨*literal next*⟩Escape the next character from any special meaning. The
⟨literal next⟩ character is usually ⟨control-V⟩.

This does the trick for me:
/^V


On Fri, Feb 5, 2016 at 12:13 PM, Артур Истомин
 wrote:

> I have file where first symbols are tabs:
>
> Sally tried really really hard
> Timmy tried really really really hard
> Johnny tried really really really really hard
>
> When I search tabs in stock vi with '/\t'. It finds all words 'tried'. In
> vim it finds tabs. Why? In fact, I can't find tabs in stock vi anyhow.My
> system is OpenBSD 5.8
>
> Thanks.

Re: providing users with equal bandwidth

[Tarkan Açan]

thank you david. i am reading and experimenting around. peter also gave me this 
very interesting tip about overloading tables and i am researching in my spare 
time. i will try to create a setup that uses these capability of pf. i also 
know that pf is very impressive in managing tcp connections, connection counts 
from the same ip, etc. maybe i can find a way to manage bandwidth per ip by 
watching state counts, limiting tcp connections, adjusting window size, 
creating different tables, assigning them priorities and so on. i really do not 
know enough openbsd and the inner mechanics of unix to get involved with the C 
API but thanks also for that tip.

i really hope to find a practical application. it does not have to be exact to 
the point. neither are other mechanisms on the market. they mostly provide 
statistical fairness. but this kind of queueing is really important for many 
network admins. especially those who manage publicly accessible or campus 
networks with changing users. instead of chasing rabbits, divide bandwidth 
equally and give the users (some) freedom in how they want to use their 
bandwidth and be done with it.

anyway, i will try to formulate something and let you guys know. expect more 
questions on the way :)

thanks to all.

On 05 Feb 2016, at 11:59, Dahlberg, David 
> 
wrote:

Am Donnerstag, den 04.02.2016, 14:41 + schrieb Tarkan Açan:
what i want to achieve is, say we have a parent queue of 10M. when 5
users connect, they should all receive 2M bandwidth each. when 5 more
users connect, i want to bog down their bandwidth to 1M each. when the
connected users drop down to 8, i want to give them 1.25M each. i do
not have a certain number of users. the number constantly changes.

What you can do is the following:

queue root on em0 bandwidth 10M max 10M
queue q01 parent root bandwidth 2M max 2M
queue q02 parent root bandwidth 2M max 2M
...
queue q99 parent root bandwidth 2M max 2M

What this will do is the following: It gives all users an equal
linkshare[1] that maxes out at 2M[2].



[1] The absolute number in "bandwidth 2M" is really irrelevant. In
reality it is just a better memorizable wording for the link-share (m2)
service curve of HFSC[3]. So "2M/2M/2M/2M" = "1/1/1/1" = "1G/1G/1G/1G" =
"equal link-sharing".

[2] If you just want link-sharing without a maximum, remove the "max"
parameter.

[3] http://conferences.sigcomm.org/sigcomm/1997/papers/p011.pdf
http://linux-ip.net/articles/hfsc.en/
http://linux-tc-notes.sourceforge.net/tc/doc/sch_hfsc.txt
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-5.4/man5/pf.conf.5
Vocabulary:
  "bandwidth" ~= "linkshare/ls m2"
  "min" ~= "realtime/rt"
  "max" ~= "upperlimit/ul"

CAVEATS:
10M is probably be a very low percentage of your overall interface
bandwidth (1%?). Currently, the OpenBSD's new queueing system does not
work very well in these circumstances because of HZ discretization and
rounding errors.

the config set of pf does not change until you load pf.conf again so
adding and removing queues dynamically seems not possible to me.

If you principally know your users in advance, you can configure them
statically. The link-share calculation only takes into account the
resources that are actually used.

But pf also supports dynamics:

tables:
* Configure as many queues as you're likely to require at the
  same time.
* Classify with tables.
* Tables are modifiable during runtime (pfctl -t)

anchors:
* Uhm, dunno. You probably have to use some C API. Find out yourself.

Cheers,

David

Re: Cannot Cleanly Exit FVWM / X Windows System

[spython01]

On 02/05/2016 03:41 AM, Dahlberg, David wrote:

Am Donnerstag, den 04.02.2016, 16:40 -0500 schrieb Samir Parikh:


If you investigate more closely, you will probably find out, that
the
system still works, just the graphics is fscked up: Try logging in
via
ssh, or shutting down the system by blindly typing into ttyC0.


I know this is a stupid question but should I try logging into ttyC0
via
CRTL-ALT-F1 while FVWM/X.org is still running or when I am in the
original shell at login?


When xenocara hangs, you may press e.g. Ctrl-Alt-F2 and enter blindly:
| 
| 
| shutdown -p now

In the other posting you were saying that pressing the power button
shortly wouldn't work. At least on my 2015 Lenovo you need to press the
power button for aprox. 2 seconds to send an ACPI powerdown.


Any ideas or suggestions?


1) Use modesetting(4) in xorg.conf and wait for 5.9


Does not work on 5.8 yet -> See Jonathan Grey's comment. He is one of
the devs, who ported the Broadwell support.

So basically you have two options:

If you want to stay on -stable:

You have to work around the but. E.g. by starting the X server with
startx and killing it from the console instead of regularly logging out.

If you use XDM put the following into /etc/X11/xdm/xdm-config:
| DisplayManager.*.resetSignal: 9

This still destroys the graphics on your consoles, but at least you get
a shiny new X server login after exiting.

In that situation, most graphical Desktop environments won't work, but
the more simplistic ones do. The following setup worked okay'ish for me:
xfce4, with xfce4-power-manager, no xscreensaver installed
(xfce4-power-manager + xscreensaver triggers the bug)


3) Update to a recent snapshot.


Ok.  Thank you for the ideas.  Perhaps I'll look into a recent
snapshot
if not other methods work


The `problem' with a snapshot is that from then on you will be following
current and keep on updating. It was bad luck for you to buy the wrong
machine at the wrong time. I did the same though, knowing quite well
that a lot of the OpenBSD developers use the same Laptop as me and thus
will feel the same pain ;-)

Regarding Broadwell Graphics support:
Matthew Dillon and wrote it first for DragonflyBSD. The OpenBSD people
could not directly import it, as the graphics stacks seem to differ
significantly between Open and Dragonfly.

After Matt Dillon also ported his Broadwell support to Linux, jsg@ and
kettenis@ started to implement it in OpenBSD. This was shortly after the
5.8 release.

Be assured that the Ubuntus and RedHats have not been faster either and
AFAIK FreeBSD/PC-BSD is still working on Haswell support ;-)


maybe OpenBSD is not the right OS for my skills and laptop.  I hope
that
is not the case though!)


Don't be afraid. Your problem is that you have bought the latest and
greatest of models and open source support takes usually a few month.

If you install 5.9 (to be released 1st of May), it will probably work
fine for you. And about the simplicity: If it works, it is IMHO easier
to master than most of the Linux distros that I know of. And
definitively better documented :-)

Cheers,

David



David, Jonathan --

Thanks for your help and tips.  As you say, perhaps I've got the right 
laptop and the wrong time.  Unfortunately, I don't have the technical 
skills to keep up with all of the updates with a snapshot or -RELEASE at 
this point.  I was able to successfully run Fedora 23 and Ubuntu MATE 
15.10 with no problems, including wireless and the screen brightness 
keys so I think I'll stay with that for now and look at putting on 
OpenBSD or FreeBSD on this older T61.  I promise I'll be back with more 
questions as I really would like to make BSD work for me!


Samir