OpenBSD 6.2 Released

hitest · 10-09-2017, 11:01 AM

OpenBSD 6.2 Released.

Code:

$ uname -a
OpenBSD bsd 6.2 GENERIC.MP#134 amd64

http://www.openbsd.org/62.html

YesItsMe · 10-10-2017, 06:48 AM

Hmm,

this was the first time my OpenBSD server failed to connect its ethernet correctly after the reboot. Probably a sysmerge thing...

Randicus Draco Albus · 10-10-2017, 07:35 AM

It may be related to the configuration changes. Keep in mind that I actually do not know and this is strictly conjecture on my part.

Quote:

Configuration and syntax changes

hostname.if. The keyword rtsol is no longer supported in hostname.if(5). Replace it with inet6 autoconf.
install.site. The execution of the {install,upgrade}.site scripts in bsd.rd is postponed to the end of the installer script. If you use this feature, make sure your script still works as expected. The script will now run after these steps:
make underlying device nodes for softraid devices
install the boot-block on disk
switch to MP kernel on multi-processor systems
update kernel.SHA256 and relink kernel
prepare execution of sysmerge(8), fw_update(8) and syspatch(8) on reboot.
prepare mail with response file to root/admin user
ifconfig. The vlan(4) and svlan(4) specific configuration options in ifconfig(8) and hostname.if(5) have been deprecated in favour of the generic parent and vnetid handling.
The vlan, vlandev, and -vlandev options are now deprecated in favour of vnetid, -vnetid, parent, and -parent when using ifconfig(8) or in hostname.if(5) configuration files. Use of the vlan option must be replaced with vnetid. Because VLAN tag 0 is invalid according to the relevant VLAN specifications, the vnetid option does not accept 0 as a valid network identifier. To use VLAN tag 0 on the wire the vnetid can be unconfigured with -vnetid. Use of vlandev and -vlandev must be replaced with parent and -parent respectively.

Unlike vlan and vlandev, vnetid and parent do not implicitly bring the vlan interface up. Similarly, the vlan option is no longer implied by the interface's minor when it is not explicitly set.

ifconfig(8) no longer outputs a vlan specific status line, or separate vnetid and parent lines. The vnetid and parent lines have been merged into a single encap line containing the VLAN tag and parent information.

An example of the changes to a vlan(4) configuration file and the ifconfig(8) output is below. Before the changes:

Code:

  # cat /etc/hostname.vlan7
  vlandev em0 # vlan 7 and up are implied
  lladdr random
  # ifconfig vlan7
  vlan7: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          lladdr 70:a7:3a:75:da:2d
          index 7 priority 0 llprio 3
          vlan: 7 parent interface: em0
          vnetid: 7
          parent: em0
          status: active

After the changes:

Code:

  # cat /etc/hostname.vlan7
  vnetid 7 parent em0
  up
  lladdr random
  # ifconfig vlan7
  vlan7: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          lladdr 60:e8:d7:0d:10:6d
          index 7 priority 0 llprio 3
          encap: vnetid 7 parent: em0
          groups: vlan
          status: active

YesItsMe · 10-10-2017, 07:36 AM

I was able to just start dhclient manually which made all issues go away, but I really wonder what happened. I need to examine this over the next weekend or so.

hitest · 10-10-2017, 09:48 AM

Upgrade cycle complete. Very smooth.

rufwoof · 11-06-2017, 04:10 PM

New to OpenBSD (from Debian Jessie). My uname -a shows 6.2 GENERIC.MP#0 amd64 whereas I've seen other having GENERIC.MP#134 adm64. Is that because I'm running with -release rather than stable or current?

Still trying to get my head around OpenBSD updating for a single user desktop setup. I installed using a http based installation CD so I assume any security updates/fixes would have been automatically installed as part of that. I'd rather stay with -release and could just leave things as-is between those, but I'm mindful of leaving security holes by not applying security updates. Content to just use pre-built's (pkg_add). What is the 'typical' end user desktop procedure/setup for security updating OpenBSD? (I only have 10 or so additional packages installed above and beyond the base system as shown here)

TIA

hitest · 11-06-2017, 04:15 PM

Quote:

Originally Posted by rufwoof

What is the 'typical' end user desktop procedure/setup for security updating OpenBSD? (I only have 10 or so additional packages installed above and beyond the base system as shown here)
TIA

I run syspatch and that installs all of my available security updates for OpenBSD 6.2. Either run syspatch as root or use doas if you have that set up.

# syspatch

doas syspatch

rufwoof · 11-06-2017, 04:31 PM

Thanks hitest. May I ask whether you also run pkg_add -u before/after that (syspatch the base system for security updates and update to later versions of security fixed non-base programs)? [Of course having backed up beforehand just in case a later program version involves config file changes being required (i.e. breaks a previously working system)]

So far the base systems fvwm has been working great for me. I did try using jwm for a while however libre spreadsheet seems to run much better under fvwm than jwm. I am conscious however that the base systems fvwm is a very dated 2.2.5 version that I believe isn't supported anymore (dating back to something like the 1990's). Is it ok to run with that for general use, or is it just there to fulfil historic dependencies and not really intended to be used as a daily primary boot wm?

hitest · 11-06-2017, 04:38 PM

Quote:

Originally Posted by rufwoof

Thanks hitest. May I ask whether you also run pkg_add -u before/after that (syspatch the base system for security updates and update to later versions of security fixed non-base programs)?

Rarely. OpenBSD doesn't update packages that often between releases. To update packages there is also the openup utility provided by M:tier. You could also run ports. I just use syspatch these days.

https://www.mtier.org/solutions/apps/openup/

rufwoof · 11-06-2017, 04:51 PM

Quote:

Originally Posted by hitest

I just use syspatch these days

Nice and easy, like it. Thanks.

YesItsMe · 11-06-2017, 05:07 PM

Note that openup wraps syspatch in newer versions: It performs kernel patches with syspatch and then tries to update your packages from M:Tier.

rufwoof · 11-06-2017, 05:31 PM

Quote:

Originally Posted by YesItsMe

Note that openup wraps syspatch in newer versions: It performs kernel patches with syspatch and then tries to update your packages from M:Tier.

Thanks YesItsMe, helpful to be made aware of.

I have 9 (10 including the systems 'quirks') packages installed on top of the base system that cater for all my browsing, file management, office, diary/calendar, image editing and video watching ... etc. needs.

Code:

# pkg_info -mz 
firefox-esr--
libreoffice--
mpv--
mtpaint--
numlockx--
osmo--
quirks--
radiotray--
stalonetray--
xfe--
#

Easy and simple enough to just pkg_add -Uuv to update them and deal with any breakages due to changes in configuration files or whatever as and when that might occur (non critical desktop system setup).

I've been up the hill (having loads of things installed) to roll back down again ... to now liking the simplicity of a lean OpenBSD. I did try FreeBSD for a while, also nice, but OpenBSD comes much more pre-configured, with X out of the box (in base system) and by chance works really well on my hardware.

YesItsMe · 11-06-2017, 05:36 PM

I find FreeBSD to be too friendly in some things: it just feels like it does not want me to play with its possibilities.

anisoptera · 11-07-2017, 04:07 AM

I'm not sure where you get that impression? FreeBSD pretty much configures nothing for you. It uses BSD RC style init and the base system is very stripped down and simple. I've never found it especially "friendly" when it comes to setting things up and just getting a working system though. Granted, it's easier to get up and running than it was in the 7- or 8-release days, but still requires RTFM and manual configuration.

By comparison OpenBSD seems ready to go out of the box and YMMV, but I've always found better hardware support (for me) in OpenBSD as well. Configuring wireless for example, couldn't be simpler. Upgrades have got a lot simpler in the last few years as well.

rufwoof · 11-07-2017, 08:46 PM

Is is OK to use the base systems fvwm (2.2.5) which is so old it isn't even supported by the developers anymore? I know I could install the more recent package based version (2.6.5), and some suggest you should use that, however the OpenBSD base system version works fine for me. My thinking is that the base system fvwm is audited as part of the general security auditing (which is more intensive than for packages) and it may have even be changed in 5.9 for better security (changelog suggests fvwm/fvwm-pager were changed to use pledge (which restricts system operations)) ... but then again that might have been for the package based (later) version of fvwm).

My understanding is that the fvwm developers changed the licensing such that later versions after 2.2.5 wont be incorporated into OpenBSD base system, but if sticking with the older version were a security issue I would have thought it would have been pulled out altogether, and that if its still in the base system then its OK to use.