How often upgrade current?

[Valus]

Hi,
I would like to ask how often should I upgrade current. I have this kernel on my virtual web, mail server:

OpenBSD 5.7-current (GENERIC) #909: Sat May  2 09:13:13 MDT 2015
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 520081408 (495MB)
avail mem = 500568064 (477MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x1ffffec0 (10 entries)
bios0: vendor Seabios version "0.5.1" date 01/01/2007
bios0: Red Hat KVM

Thanks
Valus

[TronDD]

As often as you'd like. It's usually pretty stable but you might run into times when something is out of sync or not working correctly. Something low-risk can take that chance more often.

I update my laptop every few weeks or when something interesting gets checked in or an errata gets released. I update my remote server less often as it'd be a lot harder to recover from a failed install.

[Valus]

Originally Posted by TronDD

As often as you'd like. It's usually pretty stable but you might run into times when something is out of sync or not working correctly. Something low-risk can take that chance more often.

I update my laptop every few weeks or when something interesting gets checked in or an errata gets released. I update my remote server less often as it'd be a lot harder to recover from a failed install.

Thanks for the answer. I thought mainly server running H24,because it is more critical than laptop. I think that upgrading current of the same version (ex. 5.7) should be possible every time this version is current, for example I did upgrade after release 5.7 and I should be able to upgrade without problem 5.7 current before 5.8 release. Am I wrong?

[jggimi]

Users of -current should subscribe to the Email change logs for the OS and for ports.

Any changes to the system or for installed ports (including run dependencies) that impact reliability, availability, or security will indicate an update is required. Relatively frequent upgrades are recommended, because it is not always clear when a change to the OS or a port affects RAS. It appears to me that most -current users who use it on workstations update at least once or twice each month.

---

I used to run -current everywhere, but no longer. Now, I only use -current on workstations and lab machines. I run -stable on all production servers. Unlike -current, patches to the OS or ports that are tagged for the -stable branch always address reliability / availability / security issues.

[Valus]

Originally Posted by jggimi

Users of -current should subscribe to the Email change logs for the OS and for ports.

Any changes to the system or for installed ports (including run dependencies) that impact reliability, availability, or security will indicate an update is required. Relatively frequent upgrades are recommended, because it is not always clear when a change to the OS or a port affects RAS. It appears to me that most -current users who use it on workstations update at least once or twice each month.

---

I used to run -current everywhere, but no longer. Now, I only use -current on workstations and lab machines. I run -stable on all production servers. Unlike -current, patches to the OS or ports that are tagged for the -stable branch always address reliability / availability / security issues.

Thanks for the explanation. I read about stable http://www.openbsd.org/stable.html , but it seems to me complicated to compile, so I stay with current and will upgrade current at least once a month. Where I can subscribe to the Email change logs for the OS and for ports? Thanks.

[ocicat]

Originally Posted by Valus

Where I can subscribe to the Email change logs for the OS and for ports?

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

[ocicat]

Originally Posted by Valus

I read about stable http://www.openbsd.org/stable.html , but it seems to me complicated to compile...

You may want to consider using M:Tier which delivers binary patches.

I do not use M:Tier, so I cannot comment further on its voracity, however, some of the project developers also are affiliated with M:Tier. Some members to this site use M:Tier, & may comment further on its use.

[hitest]

Originally Posted by ocicat

I do not use M:Tier, so I cannot comment further on its voracity, however, some of the project developers also are affiliated with M:Tier. Some members to this site use M:Tier, & may comment further on its use.

In the recent past I only used errata to update my -release box. I now use M:Tier to patch my 5.7 box. I have found the openup utility to be reliable and trustworthy. The openup utility also has an added advantage in that it provides binary updates to programs that the errata doesn't. I was skeptical initially of M:Tier, but, it is now something I regularly use. It is something to look at if you find it difficult to use the errata.

P.S. You will need to have your source files installed for openup to work.

[shep]

Originally Posted by hitest

P.S. You will need to have your source files installed for openup to work.

I do not believe this is entirely accurate for amd64 and i386 systems. M:tier package updates can be accessed by adding their repository to PKG_PATH. I have an old Via C3 based system that running an upto date 5.7 with binpatches/pkg updates, via openup, that I never installed src.tar.gz, sys.tar.gz and xenocara.tar.gz

The binary updates can also be added manually as described on the M:tier website.

Installing binpatches

Since binpatches will update parts of the base system, you have to manually install them for now. When an update is available for a binpatch you will be able to update it with pkg_add -u like a regular package.

Installing a binpatch works just like a regular package. So for example:

pkg_add binpatch57-amd64-openssl-1.0.tgz

M:tier also has a utility that automates patch downloading, application and compilation. Although I have not used this utility, I suspect it requires the source tree.

BINPATCH-NG
Binpatch-NG is a framework for creating binary patches for OpenBSD on all platforms in a semi-automatic way. It can automatically download the source patches published by OpenBSD, apply them, build them, and package the result into binary patches which can be installed (and uninstalled) using the OpenBSD pkg_* tools, pkg_add(1) and pkg_delete(1).

We also provide binpatches ready for use which include the latest OpenBSD errata for OpenBSD/amd64 and OpenBSD/i386.

[ocicat]

Originally Posted by jggimi

Users of -current should subscribe to the Email change logs for the OS and for ports.

To underscore this latter point, changes to the ports tree will be done at -current first. Some ports will receive multiple updates in a development cycle while some may get one, & others will get none.

Personally, I read source-changes@ & ports-changes@ very carefully. When an application I regularly use is updated, I may upgrade my systems. When something of interest is updated in the base system, I have to gauge whether this is the first of many check-in's related to the issue, or whether everything is now in CVS. Discussions on tech@ & to a lesser extend misc@ will help answer that question.

Having said this, because -current is where all active development occurs, one has to have a specific reason for running code which may be volatile & may not be fully vetted. This is also covered in Section 5.1 of the FAQ.

• If a new/upgraded feature is only in -current, this may be a reason to use -current.
• If a newer version of an application is needed, this may be a reason to use -current.
• If you are tracking down a bug, it is imperative to test on -current before engaging the project developers.

If an honest answer cannot be given to these questions, one should more likely run -release or -stable.

Using -current will mean at some point that mismatched libraries, missing code, & other vagaries will be seen. If this is not something you can deal with, don't run -current.

[betweendayandnight]

Originally Posted by jggimi

Users of -current should subscribe to the Email change logs for the OS and for ports.

Originally Posted by jggimi

It appears to me that most -current users who use it on workstations update at least once or twice each month.

Originally Posted by jggimi

I used to run -current everywhere, but no longer. Now, I only use -current on workstations and lab machines.

Hi jggimi,

I hope you can clarify a point for me: ISOs, packages and ports of -current version are found in http://ftp.openbsd.org/pub/OpenBSD/snapshots/ ??

[ocicat]

Originally Posted by betweendayandnight

ISOs, packages and ports of -current version are found in http://ftp.openbsd.org/pub/OpenBSD/snapshots/ ??

I am not jggimi, but I will pass on my commentary on this subject.

• ISO's found at pub/OpenBSD/snapshots consist of the kernels, filesets, & supporting binaries for -current -- the head of the CVS repository. Snapshots of the popular architectures will be generated perhaps daily -- sometimes several times a day. Other architectures will not see new snapshots at the same frequency.
• -current packages are generated at a slower rate, but will be found at pub/OpenBSD/snapshots/packages. The fact that packages may lag behind changes in the base system may lead to some library mismatches. Those running -current need to be aware of this, & factor in potential down-time when upgrading. Library mismatches may mean that -current users will need to build packages from source, or wait several days for new packages to appear. -current users also see the need of back-ups, & factor this into their upgrade practices.
• Because of project constraints, not all applications in the ports tree will made available for -current users. Again, -current users are expected to have the technical skills needed to deal with building issues.
• The CVS tree(s) (kernel, userland, ports, documentation, etc.) are available at a different set of servers. http://www.openbsd.org/anoncvs.html will list available sources.
• -release & -stable are intentionally meant to be library compatible -- meaning that packages compiled for -stable should run as expected on -release, & vice-versa.

[betweendayandnight]

Originally Posted by ocicat

I am not jggimi, but I will pass on my commentary on this subject.

• ISO's found at pub/OpenBSD/snapshots consist of the kernels, filesets, & supporting binaries for -current -- the head of the CVS repository........................................ ..............................................

ocicat, thanks for the detailed explanation and I appreciate you taking the time to do that.

My I suggest that what you wrote above be put into a file called README1st and uploaded to the snapshots directory of all the FTP mirrors. This way new converts to OpenBSD will have a clear idea of what they are going to download.

Now regarding your detailed and useful explanation, I've some questions for you:

1. What's meant by "head of the CVS repository?

& supporting binaries for -current -- the head of the CVS repository.

2. Does building packages from source cause the --current version to become insecure (that is, vulnerable) and unstable?

Library mismatches may mean that -current users will need to build packages from source,

[ibara]

Originally Posted by betweendayandnight

My I suggest that what you wrote above be put into a file called README1st and uploaded to the snapshots directory of all the FTP mirrors. This way new converts to OpenBSD will have a clear idea of what they are going to download.

No. For one, ocicat isn't a developer, so he can't drop anything onto the FTP site.
Second, this is not the place for suggestions. tech@ is, preferably with a diff.
Third, this is why the FAQ makes clear that if you're new, start with an official release CD: http://www.openbsd.org/faq/faq3.html#BuyCD
And the FAQ does make clear what the snapshots directory is: http://www.openbsd.org/faq/faq5.html#Flavors
By the way, the FAQ is on the mirror sites, under doc/

Originally Posted by betweendayandnight

1. What's meant by "head of the CVS repository?

The very latest code, i.e. -current.

Originally Posted by betweendayandnight

2. Does building packages from source cause the --current version to become insecure (that is, vulnerable) and unstable?

I'm not really sure what you're trying to ask here.
If you're asking "will building a -current port on a release or -stable machine cause the machine to become insecure and/or unstable?" then the answer is "maybe, but probably not." More likely, smaller ports will be "whatever" with that arrangement and larger ports won't build.

[ocicat]

Originally Posted by betweendayandnight

My I suggest that what you wrote above be put into a file called README1st and uploaded to the snapshots directory of all the FTP mirrors. This way new converts to OpenBSD will have a clear idea of what they are going to download.

Various points. Note that I am editorializing from my own experience.

• While this is a nice idea, daemonforums is a third-party site which has no affliliation with the OpenBSD project. There are a few project developers who read & respond to questions here, but the majority of members & regulars are simply users just like you. I am a user just as you. I have submitted diff's & bug reports, & some have been incorporated into CVS, but I have no commit privileges.
• The OpenBSD project is small, & it gets a lot accomplished with very little resources. The culture focuses on submitted diff's, & rightfully so. Ultimately, it is the behavior of code which defines the system, & talk is cheap. Keeping discussion at the level of "what specific changes need to take place in the code" helps move conversation forward. Any user is free to submit diff's to the project, & the developers will earnestly evaluate whether those changes work & advance the goals of the project. All submitted diff's are not accepted, & that is the way development should occur. There may be a better way to accomplish the same goal.

If you believe a newbie document needs to be made available, construct what you think needs to be its contents, & submit it to the project for consideration. I would suggest you study all collateral documentation first to determine if your proposal(s) are not already found elsewhere.

What's meant by "head of the CVS repository?

CVS is a source control software, & the one used by the OpenBSD project. You can download the repository or view it online:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/

Basically, all revisions of code are tracked & maintained.

Periodically, code is tagged with a label which also defines a branch. As examples,

• All code defining OpenBSD 5.7-release can be found in the branch called OPENBSD_5_7_BASE. The official CD images are pressed from this branch, & once created, this branch never changes. Ever.
• When OPENBSD_5_7_BASE is created, the tag for OPENBSD_5_7 is also created. This defines the -stable branch. Some changes will be back-ported to this branch.
• All code checked into CVS which does not target a specific branch implicitly go into HEAD which is the development branch.

The "head of the CVS repository" is the branch defining -current. Yes, the parlance of source control can be odd, but this is the world developers live in.

More information can be found at the cvs(1) manpage.

Does building packages from source cause the --current version to become insecure (that is, vulnerable) and unstable?

Some consessions have to be made in building ports. You will find discussion in Section 15 of the FAQ. I would recommend you study this section first, & come back with further questions based on your readings.

[jggimi]

Yes, managing -current can seem easier*, if you are upgrading from snapshot to snapshot and using snapshot packages. But there are risks to doing so, since -current is the development branch. As TronDD noted above, it is possible that backup/recovery requirements or other risk mitigations needed for -current on remote systems might outweigh the benefits of having it deployed remotely.

See the source-changes and ports-changes lists on the Mailing Lists page of the Project website. Daily and weekly digest subscriptions, of instant notification of each patch committed are available.

* The Project does not have the resources to build -stable releases or packages, leaving the building of these to the user community. The company M:Tier offers binary builds of -stable releases and packges as a public service to the OpenBSD community. https://stable.mtier.org/

[jggimi]

Today, ocicat and I have been posting similar information, as we are writing comments simultaneously.

Neither of us use M:Tier's services, but we think they should be investigated if building the system from source per FAQ 5 or release(8) seems confusing, complicated, or difficult.

FAQ 15 doesn't provide step-by-step instructions for comparing interlocking run dependencies in the ports tree against the installed package database, and the building the resulting required package set. This may be another reason to investigate M:Tier's services.

Generally, -current users should have the knowledge and skills needed to manage the development branch beyond installation and upgrade. In those instances where the admin doesn't have this but -current is an operational requirement, the astute admin takes steps to mitigate risk. This might be backup and disaster recovery procedures, commercial support agreements, or the admin taking steps to obtain required knowledge and skill through education and training. Or a combination of these.

[Valus]

Thanks ocicat and jggimi for extensive explanation. I started to use current because I needed feature which was not in release 5.6. I have to consider the risks and effort. I thought about installing another virtual server with release and I will have backup server if upgrade of this current fails, but this is another topic. Of course I do backup of important data regularly. In case of problem I have to reinstall server. I did not know about M:Tier maybe I will use it. Thanks.

[ibara]

I use M:Tier on computers that are for family members. It's great, and my mother even learned how to update her laptop herself with their update script.
All I have to do is spend the 5 minutes updating each release once every 6 months.

[shep]

The BSD way is to separate the base system (/usr) from user added code (/usr/local). For both OpenBSD and FreeBSD this evolved into two separate code groups each with its mechanism of updating.

M:tier is flexible so that both base and/or userland can be updated. For my main system, I uses OpenBSD patches I apply myself and M:tier for package updates.

It is even possible to make an M:tier menu entry, requiring root confirmation, into a DE/WM. I incorporated this into the latest iteration of a SimpleDE for OpenBSD