Re: Upgrade procedure (6.4 -> 6.5)
On Tue, May 07, 2019 at 08:15:16PM -0400, Nick Holland wrote: On 5/7/19 8:32 AM, Dumitru Moldovan wrote: On Sun, May 05, 2019 at 05:05:11PM +0200, Ingo Schwarze wrote: Hi, Consus wrote on Fri, May 03, 2019 at 02:24:10PM +0300: Maybe it's a good idea to note this on the upgrade page? Something like "the upgrade procedure may leave some files behing; you can manually clean them up using sysclean package"? [...] For example, it is definitely useful to remove stale Perl libraries. It is also useful for stale header files if you compile software from source. It is useful (but not terribly important) for stale manual pages. It is usually detrimental for old versions of shared libraries, unless you are *really* short on disk space (which is getting less common nowadays) *and* you are very careful. For most use cases, we do not recommend using sysclean. I think there's a less common scenario not covered in this thread. Suppose you have locally-compiled binaries, linked to previous versions of libraries, belonging to an older version of the OS. Those libs will never get patched after you upgrade, so any vulnerabilities they expose will remain exploitable in the binaries linked to them. Ok, I admire your confidence that the problem in your local binaries are the OpenBSD libraries. :D This swings both ways. When doing an upgrade, if the upgrade deleted all those libraries BEFORE you had a chance to upgrade that binary, it would quit working. While I'm all for "Fail Closed", it might be premature to call it a failure. Or not. It is very hard to please all, and even harder to cover all possible situations. You're mostly right, but just to be clear... Although it's true I'm a purist on this and would prefer that binaries linked to old libs will fail after an OS upgrade, there's no confidence to be admired on my side. This is why I used "I think" and "suppose you have" above. Thanks for the understanding!
Re: Upgrade procedure (6.4 -> 6.5)
On 5/7/19 8:32 AM, Dumitru Moldovan wrote: > On Sun, May 05, 2019 at 05:05:11PM +0200, Ingo Schwarze wrote: >>Hi, >> >>Consus wrote on Fri, May 03, 2019 at 02:24:10PM +0300: >> >>> Maybe it's a good idea to note this on the upgrade page? Something like >>> "the upgrade procedure may leave some files behing; you can manually >>> clean them up using sysclean package"? >> > > [...] > >> >>For example, it is definitely useful to remove stale Perl libraries. >>It is also useful for stale header files if you compile software >>from source. It is useful (but not terribly important) for stale >>manual pages. It is usually detrimental for old versions of shared >>libraries, unless you are *really* short on disk space (which is getting >>less common nowadays) *and* you are very careful. >> >>For most use cases, we do not recommend using sysclean. > > I think there's a less common scenario not covered in this thread. > Suppose you have locally-compiled binaries, linked to previous versions > of libraries, belonging to an older version of the OS. Those libs will > never get patched after you upgrade, so any vulnerabilities they expose > will remain exploitable in the binaries linked to them. Ok, I admire your confidence that the problem in your local binaries are the OpenBSD libraries. :D This swings both ways. When doing an upgrade, if the upgrade deleted all those libraries BEFORE you had a chance to upgrade that binary, it would quit working. While I'm all for "Fail Closed", it might be premature to call it a failure. Or not. It is very hard to please all, and even harder to cover all possible situations. Nick.
Re: Upgrade procedure (6.4 -> 6.5)
Hi Dumitru, Dumitru Moldovan wrote on Tue, May 07, 2019 at 05:33:20PM +0300: > On Sun, May 05, 2019 at 05:05:11PM +0200, Ingo Schwarze wrote: >> Consus wrote on Fri, May 03, 2019 at 02:24:10PM +0300: >>> Maybe it's a good idea to note this on the upgrade page? Something like >>> "the upgrade procedure may leave some files behing; you can manually >>> clean them up using sysclean package"? >> For example, it is definitely useful to remove stale Perl libraries. >> It is also useful for stale header files if you compile software >> from source. It is useful (but not terribly important) for stale >> manual pages. It is usually detrimental for old versions of shared >> libraries, unless you are *really* short on disk space (which is getting >> less common nowadays) *and* you are very careful. >> >> For most use cases, we do not recommend using sysclean. > I think there's a less common scenario not covered in this thread. > Suppose you have locally-compiled binaries, linked to previous versions > of libraries, belonging to an older version of the OS. Those libs will > never get patched after you upgrade, so any vulnerabilities they expose > will remain exploitable in the binaries linked to them. That is indeed true, and an important observation. When you compile programs locally (as opposed to using packages), special care is needed to keep them up to date. The operating system cannot do that for you, neither with nor without sysclean. Yours, Ingo
Re: Upgrade procedure (6.4 -> 6.5)
On Sun, May 05, 2019 at 05:05:11PM +0200, Ingo Schwarze wrote: Hi, Consus wrote on Fri, May 03, 2019 at 02:24:10PM +0300: Maybe it's a good idea to note this on the upgrade page? Something like "the upgrade procedure may leave some files behing; you can manually clean them up using sysclean package"? [...] For example, it is definitely useful to remove stale Perl libraries. It is also useful for stale header files if you compile software from source. It is useful (but not terribly important) for stale manual pages. It is usually detrimental for old versions of shared libraries, unless you are *really* short on disk space (which is getting less common nowadays) *and* you are very careful. For most use cases, we do not recommend using sysclean. I think there's a less common scenario not covered in this thread. Suppose you have locally-compiled binaries, linked to previous versions of libraries, belonging to an older version of the OS. Those libs will never get patched after you upgrade, so any vulnerabilities they expose will remain exploitable in the binaries linked to them.
Re: Upgrade procedure (6.4 -> 6.5)
Ingo, and Everyone, On Sun, May 05, 2019 at 02:58:18PM +0200, Ingo Schwarze wrote: Hi Wolfgang, Wolfgang Pfeiffer wrote on Sat, May 04, 2019 at 06:34:04PM +0200: On Sat, May 04, 2019 at 01:07:34AM -0400, Nick Holland wrote: Spend a little time learning OpenBSD, Yes: time needed, I think: Took me a while until I got that ... :) [ .. ] Bottom line, chances are that the time you need for learning is vastly outweighted by the time you save because the system is so much simpler to use. So likely, you will save time starting on day one. First: Thanks a lot for taking the time for your answer. But I disagree. Bigly. While my experience with OBSD certainly isn't extended enough, yet, to tell how much time I will save by using the system, my guess would be that you are right: I don't think I ever experienced an install that quick and smooth like the OBSD one I did on two Macintosh computers some time ago. With hickups, IIRK, yes, but nevertheless great. The point where I differ is where you seem to indicate that first it is some sort of a loss when we have to study the system, and that this effort is outweighed later on by the time we save. Half-true it is ... :) Because: if we seriously work through the big holes of missing knowledge in whatever territory, it will nearly always end up a win situation. Provided one doesn't give up. Because while we study we become more knowledgeable. That's the first win, coming nearly always with minimal intelligence and enough effort. The second one will come the moment we start to master the territory we studied. So: Double-win, hopefully ... :) Extended version: We need to be interested in the territory of our studies: if grandma' just needs a computer to send emails to her friends, or video-calling her grand-kids it's okay to just install her some Linux or Windows. Provided - at least in the latter case - she doesn't intend to do her internet banking with such an OS. But if she really wanted to understand the tool she's using, she will need to learn before asking lazy questions on a computer mailing list. Because the people on this list - probably any mailing list - are not here to do the work she needs to do herself. Theo de Raadt recently wrote that OBSD is "software we primarily develop for ourselves -- in the hope that other people are like us and need similar things." [1] I think this is an important approach to any work: if we're not interested in what we do, if we strive to help others, if we sacrifice our life to others, if we pretend that others are more important than us, and all of this out of some concept of moral duty, we will in the end have cannibalized ourselves. Which is another form of suicide (Ayn Rand has more on that: "altruism"). And OBSD might die an ugly death - I obviously don't want that. And instead try to do my homework. HTH, Kind Regards, and Thanks again, Ingo, Wolfgang [1] https://marc.info/?l=openbsd-misc&m=155634461814603&w=2 Yours, Ingo
Re: Upgrade procedure (6.4 -> 6.5)
Hi, Consus wrote on Fri, May 03, 2019 at 02:24:10PM +0300: > Maybe it's a good idea to note this on the upgrade page? Something like > "the upgrade procedure may leave some files behing; you can manually > clean them up using sysclean package"? We have worse problems with the upgrade page right now, Specifically, we lack a maintainer for the file faq/upgrade66.html. Besides, the sentence you are proposing is misleading. Whether or not removing left-behind files provides benefit or rather causes pointless risk depends on the specific files and on the specific situation. For example, it is definitely useful to remove stale Perl libraries. It is also useful for stale header files if you compile software from source. It is useful (but not terribly important) for stale manual pages. It is usually detrimental for old versions of shared libraries, unless you are *really* short on disk space (which is getting less common nowadays) *and* you are very careful. For most use cases, we do not recommend using sysclean. I was specifically considering the (admittedly minor, but none the less slightly annoying) issue of stale manual pages. Yours, Ingo
Re: Upgrade procedure (6.4 -> 6.5)
On Sat, May 04, 2019 at 10:33:26AM +0300, Strahil Nikolov wrote: > On May 4, 2019 10:11:07 AM GMT+03:00, Nick Holland > wrote: > >On 5/3/19 2:32 PM, Strahil Nikolov wrote: > >> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland > >> wrote: > >>> On 5/2/19 1:52 AM, Consus wrote: > Hi, > > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I > see that /etc/networks and some other files (like malloc.conf.5) > are > >>> still > present, although there is no use for them in the new release. > > Is there a reason why these files are not listed in "FIles to > >>> remove"? > Is there a way to track them? It's not like something gonna > break, > >>> but > old configuration files (and manual pages) lying around can make > someone's life harder during the debug session. > >>> > >>> There is no promise that an upgraded machine will be file-for-file > >>> identical to a fresh install. Here is the list of problems this > >>> might cause you, as you can see, it's a long list and quite > >>> horrible: > >>> > >>> * If you use the same hw for 20 years, you might run out of disk > >>> space? > >>> > >>> Ok, not very long and not very horrible. > >>> > >>> You are trying to solve a non-problem. And sometimes, 'specially > >>> on an upgraded machine, it's great to see how things WERE when the > >>> machine was set up. If you really care, go ahead, delete stuff. > >>> > >>> Nick. > >> > >> Hi All, > >> > >> As I linux guy (my experience in openBSD can be easily measured in > >> days) I can share the view of less experienced user that was planing > >> to upgrade from 6.4 to 6.5 and that eneded with a full reinstall. > >> > >> I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to > >> 6.5 and thus it seemed that booting from the 6.5 DVD will do the > >> trick. Sadly the installer never checked the avalable space , but > >> just started to do it's stuff until reporting that not enough space > >> is available. > > > >The installer didn't check. Neither did you. Let's blame the > >installer. > > Well, O can't presict how big are the new tars's size -yet the updater > shoulddo that. > If my /usr is too small - it should make the calculation for me and refuse to > update. > > How do you estinate how much space do you need for the update ? Get the iso > and extract each archive to predict that ? > Nah let's blame the newbie. > > >Ok, sure, might be nice, but when there are a snootload of different > >platforms with radically different size binaries, it's not trivial. > Well, if it's done in linux , its doable in openBSD. Of course it is doable. But nobody has done it. Probably because nobody (developer or otherwise) thought it a priority. I'd say that even while it is not a priority, the install/upgrade proces already does the right thing in many, many circumstances. A even more foolproof install/upgrade is nice to have, but given the resources available, there are more pressing things to do. -Otto
Re: Upgrade procedure (6.4 -> 6.5)
Hi Wolfgang, Wolfgang Pfeiffer wrote on Sat, May 04, 2019 at 06:34:04PM +0200: > On Sat, May 04, 2019 at 01:07:34AM -0400, Nick Holland wrote: >> Spend a little time learning OpenBSD, > Yes: time needed, I think: Took me a while until I got that ... :) While i don't doubt it may feel like that for some, your mileage may wary even in that respect. Before 2001, i had mostly used DEC/OSF-1 and bit of HP-UX and AIX, as well as lots of Linux, a bit of Redhat but mostly SuSE and Debian. When a colleague made me set up and run an OpenBSD server with that background, i immediately noticed that for typical sysadmin tasks, it took me about three times less time to get them done with OpenBSD than with Debian. Even though i was experienced with Debian and totally new to OpenBSD. Around the same time, it happened to me that a friend wanted a home firewall installed with Debian. After another friend had wrestled with the installation for more than an hour before finally giving up, i quickly and smoothly installed OpenBSD on that box and we were done with it. The guy who failed with Debian was far from stupid, even more experienced then i was with either of the systems at the time. Bottom line, chances are that the time you need for learning is vastly outweighted by the time you save because the system is so much simpler to use. So likely, you will save time starting on day one. Yours, Ingo
Re: Upgrade procedure (6.4 -> 6.5)
On Sat, May 04, 2019 at 01:07:34AM -0400, Nick Holland wrote:
On 5/3/19 2:32 PM, Strahil Nikolov wrote:
On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland
wrote:
On 5/2/19 1:52 AM, Consus wrote:
[ ... ]
I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to
6.5 and thus it seemed that booting from the 6.5 DVD will do the
trick. Sadly the installer never checked the avalable space , but
just started to do it's stuff until reporting that not enough space
is available.
A default Fedora installation here is using 39GB from a whole disk
(no VM), after two or three years of using it, with a a few upgrades
in between. Now admittedly there a few big files in that sum. But even
if I count those big ones off I'd assume that a default install or
upgrade of any OS (Windows, Linux, whatever ...) on a disk with just
10(!) GB might be just a little, little bit too small: and it takes no
installer to tell me that ... ;)
[ ... ]
And ... considering the number of times I've seen and heard about Linux
systems hose themselves with upgrades, I question your implication.
Major Linux upgrade? Most people I know just say "Screw it. Rebuild,
reload".
Even on that Fedora Linux from where I'm writing this, it takes a
bit of preparation for a major upgrade: like close down X, the DM,
move to a console, start (as an example) some tmux, and from there
start very specific steps to upgrade. To just believe one can press an
upgrade button in Fedora and hope this will work is akin to asking for
trouble right on my knees ... ;)
But I admit, Fedora users might be to lured into this
"just-press-the-upgrade-button" easily - not being sure why this is
so ...
[ .. ]
Why did the installer allow installation despite the available space
is low ( even windows checks available space :) )???
see above ... ;)
Here comes my favorite part:
OpenBSD has what I call a "Learning Curb". You gotta lift your feet.
Not a lot, it's not hard, but you can't just shuffle along mindlessly
and expect to be carried to the next level without your engaging your brain
Well: it is hard. It takes time to learn. Tho' no university grades
being needed to succeed in that, I think.
If you used Linux for a little bit and figured that OpenBSD is "just
like Linux, but different", yeah, no, you are going to be disappointed.
Different beast.
From a management perspective, I'd say Linux and Windows are much
more alike than Linux and OpenBSD.
+1
Linux is written for and by those frustrated with Windows
("Reinventing Windows, poorly"). OpenBSD is Unix. It's probably the
simplest Unix out there to use and manage, but it's not Windows (or
Linux).
Or... Think of Linux (and windows) as the big cushy luxury car.
Easy to drive, assuming you work within the anticipated parameters,
but you really have no idea what's going on under the hood. "you
aren't supposed to". That's the design goal, and it works pretty
well...until it doesn't.
again: +1
OpenBSD is more like a semi-primative small car with tight
suspension and a stick-shift trans. It's got antilock brakes, but for
the most part, it assumes you know what you are doing when you get
behind the wheel. When it gets a little wonky, you pop the hood, look
around, see what's not right. Grab a couple tools from the trunk
(included!) fix it, and be back on the road before the guy in the Luxury
car has figured out how to call for a tow truck.
Spend a little time learning OpenBSD,
Yes: time needed, I think: Took me a while until I got that ... :)
and you will find you can make it do amazing things.
Nick.
Thanks, and Regards,
Wolfgang
Re: Upgrade procedure (6.4 -> 6.5)
On May 4, 2019 10:11:07 AM GMT+03:00, Nick Holland wrote: >On 5/3/19 2:32 PM, Strahil Nikolov wrote: >> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland >> wrote: >>> On 5/2/19 1:52 AM, Consus wrote: Hi, I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see that /etc/networks and some other files (like malloc.conf.5) are >>> still present, although there is no use for them in the new release. Is there a reason why these files are not listed in "FIles to >>> remove"? Is there a way to track them? It's not like something gonna break, >>> but old configuration files (and manual pages) lying around can make someone's life harder during the debug session. >>> >>> There is no promise that an upgraded machine will be file-for-file >>> identical to a fresh install. Here is the list of problems this >>> might cause you, as you can see, it's a long list and quite >>> horrible: >>> >>> * If you use the same hw for 20 years, you might run out of disk >>> space? >>> >>> Ok, not very long and not very horrible. >>> >>> You are trying to solve a non-problem. And sometimes, 'specially >>> on an upgraded machine, it's great to see how things WERE when the >>> machine was set up. If you really care, go ahead, delete stuff. >>> >>> Nick. >> >> Hi All, >> >> As I linux guy (my experience in openBSD can be easily measured in >> days) I can share the view of less experienced user that was planing >> to upgrade from 6.4 to 6.5 and that eneded with a full reinstall. >> >> I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to >> 6.5 and thus it seemed that booting from the 6.5 DVD will do the >> trick. Sadly the installer never checked the avalable space , but >> just started to do it's stuff until reporting that not enough space >> is available. > >The installer didn't check. Neither did you. Let's blame the >installer. Well, O can't presict how big are the new tars's size -yet the updater shoulddo that. If my /usr is too small - it should make the calculation for me and refuse to update. How do you estinate how much space do you need for the update ? Get the iso and extract each archive to predict that ? Nah let's blame the newbie. >Ok, sure, might be nice, but when there are a snootload of different >platforms with radically different size binaries, it's not trivial. Well, if it's done in linux , its doable in openBSD. >But >feel free to send in a patch. Test on two or three different >platforms, >first, though, please. I would, if I find some time... which is currently my most precious resource. >And ... considering the number of times I've seen and heard about Linux >systems hose themselves with upgrades, I question your implication. >Major Linux upgrade? Most people I know just say "Screw it. Rebuild, >reload". Linux might have the edge on incremental upgrades, but >eventually, you are going to need to move to the more current >release...and then OpenBSD starts looking REALLY GOOD. Maybe you haven't used RHEL or SUSE - they both support major upgrade (Red Hat released the tool for migration from 6 to 7. Check the release notes for RHEL 7.5) >10g disk? When I first started working with OpenBSD, that was really >big. But then, I had to manually partition the disk. 20 years later, >10G is tiny. The installer auto-partioner is really intended for >bigger >disks. Yeah, you are in "Special Case" territory, which isn't a good >spot to be as a new user. If I'm so special, then where was the warning of the installer in the first place? Just a short notice like 'You have a very small disk and upgrades might not be supported!' would be enough to keep my mouth shut. Still, there was no such warning in the first place. >> Why did the installer allow installation despite the available space >> is low ( even windows checks available space :) )??? > >The average windows user doesn't know what the units of storage mean. Yet, we are not windows users :) Are we ? openBSD is great, but it needs some improvement s and that's what I was trying to imply here, not to criticize. >> Why should the end-user delete old unnecessary/problematic files ? > >That's my question. What's the big deal? On a modern disk, just >ignore >them. They won't be a problem until long after your rotate out the hw. >Problem is, you used a 2001 vintage size disk. You should have rotated >that out around 2005. I saw that at least the man pages will be wrong if I keep them - and of course this will cause issues in the future. >And I'm curious how a CentOS 6 to Centos 7 upgrade would go on a 10G >disk. I have my suspicions, and I suspect it would be entertaining to >watch...assuming it wasn't something you were dependent upon. I'm quite active in the CentOS forum and I can assure you that the tool that Red Hat use has no maintainers and thus it doesn't work. The community will be happy if become a maintainer and start working o
Re: Upgrade procedure (6.4 -> 6.5)
On 04/05/2019 07:07, Nick Holland wrote:
On 5/3/19 2:32 PM, Strahil Nikolov wrote:
On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland
wrote:
On 5/2/19 1:52 AM, Consus wrote:
Hi,
I've upgraded my systems from 6.4 to 6.5 without a glitch, but I
see that /etc/networks and some other files (like malloc.conf.5)
are
still
present, although there is no use for them in the new release.
Is there a reason why these files are not listed in "FIles to
remove"?
Is there a way to track them? It's not like something gonna
break,
but
old configuration files (and manual pages) lying around can make
someone's life harder during the debug session.
There is no promise that an upgraded machine will be file-for-file
identical to a fresh install. Here is the list of problems this
might cause you, as you can see, it's a long list and quite
horrible:
* If you use the same hw for 20 years, you might run out of disk
space?
Ok, not very long and not very horrible.
You are trying to solve a non-problem. And sometimes, 'specially
on an upgraded machine, it's great to see how things WERE when the
machine was set up. If you really care, go ahead, delete stuff.
Nick.
Hi All,
As I linux guy (my experience in openBSD can be easily measured in
days) I can share the view of less experienced user that was planing
to upgrade from 6.4 to 6.5 and that eneded with a full reinstall.
I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to
6.5 and thus it seemed that booting from the 6.5 DVD will do the
trick. Sadly the installer never checked the avalable space , but
just started to do it's stuff until reporting that not enough space
is available.
The installer didn't check. Neither did you. Let's blame the installer.
Ok, sure, might be nice, but when there are a snootload of different
platforms with radically different size binaries, it's not trivial. But
feel free to send in a patch. Test on two or three different platforms,
first, though, please.
And ... considering the number of times I've seen and heard about Linux
systems hose themselves with upgrades, I question your implication.
Major Linux upgrade? Most people I know just say "Screw it. Rebuild,
reload". Linux might have the edge on incremental upgrades, but
eventually, you are going to need to move to the more current
release...and then OpenBSD starts looking REALLY GOOD.
10g disk? When I first started working with OpenBSD, that was really
big. But then, I had to manually partition the disk. 20 years later,
10G is tiny. The installer auto-partioner is really intended for bigger
disks. Yeah, you are in "Special Case" territory, which isn't a good
spot to be as a new user.
Why did the installer allow installation despite the available space
is low ( even windows checks available space :) )???
The average windows user doesn't know what the units of storage mean.
Why should the end-user delete old unnecessary/problematic files ?
That's my question. What's the big deal? On a modern disk, just ignore
them. They won't be a problem until long after your rotate out the hw.
Problem is, you used a 2001 vintage size disk. You should have rotated
that out around 2005.
And I'm curious how a CentOS 6 to Centos 7 upgrade would go on a 10G
disk. I have my suspicions, and I suspect it would be entertaining to
watch...assuming it wasn't something you were dependent upon.
Usually we do have package management system to take care of that (or
at least to rename those files in case we really need them).
Yeah, you need to wait until Linux "package management" screws itself
into a knot for you.
For me, system upgrade is a very complicated and error prone
procedure.
OpenBSD has what I call a "Learning Curb". You gotta lift your feet.
Not a lot, it's not hard, but you can't just shuffle along mindlessly
and expect to be carried to the next level without your engaging your brain
If you used Linux for a little bit and figured that OpenBSD is "just
like Linux, but different", yeah, no, you are going to be disappointed.
Different beast. From a management perspective, I'd say Linux and
Windows are much more alike than Linux and OpenBSD. Linux is written
for and by those frustrated with Windows ("Reinventing Windows,
poorly"). OpenBSD is Unix. It's probably the simplest Unix out there
to use and manage, but it's not Windows (or Linux).
Or... Think of Linux (and windows) as the big cushy luxury car. Easy
to drive, assuming you work within the anticipated parameters, but you
really have no idea what's going on under the hood. "you aren't
supposed to". That's the design goal, and it works pretty well...until
it doesn't. OpenBSD is more like a semi-primative small car with tight
suspension and a stick-shift trans. It's got antilock brakes, but for
the most part, it assumes you know what you are doing when you get
behind the wheel. When it gets a little wonky, you pop the hood, look
around, see what's not right. Grab a couple tools fr
Re: Upgrade procedure (6.4 -> 6.5)
On 5/3/19 2:32 PM, Strahil Nikolov wrote:
> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland
> wrote:
>> On 5/2/19 1:52 AM, Consus wrote:
>>> Hi,
>>>
>>> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I
>>> see that /etc/networks and some other files (like malloc.conf.5)
>>> are
>> still
>>> present, although there is no use for them in the new release.
>>>
>>> Is there a reason why these files are not listed in "FIles to
>> remove"?
>>> Is there a way to track them? It's not like something gonna
>>> break,
>> but
>>> old configuration files (and manual pages) lying around can make
>>> someone's life harder during the debug session.
>>
>> There is no promise that an upgraded machine will be file-for-file
>> identical to a fresh install. Here is the list of problems this
>> might cause you, as you can see, it's a long list and quite
>> horrible:
>>
>> * If you use the same hw for 20 years, you might run out of disk
>> space?
>>
>> Ok, not very long and not very horrible.
>>
>> You are trying to solve a non-problem. And sometimes, 'specially
>> on an upgraded machine, it's great to see how things WERE when the
>> machine was set up. If you really care, go ahead, delete stuff.
>>
>> Nick.
>
> Hi All,
>
> As I linux guy (my experience in openBSD can be easily measured in
> days) I can share the view of less experienced user that was planing
> to upgrade from 6.4 to 6.5 and that eneded with a full reinstall.
>
> I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to
> 6.5 and thus it seemed that booting from the 6.5 DVD will do the
> trick. Sadly the installer never checked the avalable space , but
> just started to do it's stuff until reporting that not enough space
> is available.
The installer didn't check. Neither did you. Let's blame the installer.
Ok, sure, might be nice, but when there are a snootload of different
platforms with radically different size binaries, it's not trivial. But
feel free to send in a patch. Test on two or three different platforms,
first, though, please.
And ... considering the number of times I've seen and heard about Linux
systems hose themselves with upgrades, I question your implication.
Major Linux upgrade? Most people I know just say "Screw it. Rebuild,
reload". Linux might have the edge on incremental upgrades, but
eventually, you are going to need to move to the more current
release...and then OpenBSD starts looking REALLY GOOD.
10g disk? When I first started working with OpenBSD, that was really
big. But then, I had to manually partition the disk. 20 years later,
10G is tiny. The installer auto-partioner is really intended for bigger
disks. Yeah, you are in "Special Case" territory, which isn't a good
spot to be as a new user.
> Why did the installer allow installation despite the available space
> is low ( even windows checks available space :) )???
The average windows user doesn't know what the units of storage mean.
> Why should the end-user delete old unnecessary/problematic files ?
That's my question. What's the big deal? On a modern disk, just ignore
them. They won't be a problem until long after your rotate out the hw.
Problem is, you used a 2001 vintage size disk. You should have rotated
that out around 2005.
And I'm curious how a CentOS 6 to Centos 7 upgrade would go on a 10G
disk. I have my suspicions, and I suspect it would be entertaining to
watch...assuming it wasn't something you were dependent upon.
> Usually we do have package management system to take care of that (or
> at least to rename those files in case we really need them).
Yeah, you need to wait until Linux "package management" screws itself
into a knot for you.
> For me, system upgrade is a very complicated and error prone
> procedure.
OpenBSD has what I call a "Learning Curb". You gotta lift your feet.
Not a lot, it's not hard, but you can't just shuffle along mindlessly
and expect to be carried to the next level without your engaging your brain
If you used Linux for a little bit and figured that OpenBSD is "just
like Linux, but different", yeah, no, you are going to be disappointed.
Different beast. From a management perspective, I'd say Linux and
Windows are much more alike than Linux and OpenBSD. Linux is written
for and by those frustrated with Windows ("Reinventing Windows,
poorly"). OpenBSD is Unix. It's probably the simplest Unix out there
to use and manage, but it's not Windows (or Linux).
Or... Think of Linux (and windows) as the big cushy luxury car. Easy
to drive, assuming you work within the anticipated parameters, but you
really have no idea what's going on under the hood. "you aren't
supposed to". That's the design goal, and it works pretty well...until
it doesn't. OpenBSD is more like a semi-primative small car with tight
suspension and a stick-shift trans. It's got antilock brakes, but for
the most part, it assumes you know what you are doing when you get
behind the wheel. When it gets
Re: Upgrade procedure (6.4 -> 6.5)
Strahil Nikolov wrote: > > On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland > \ > wrote: > > On 5/2/19 1:52 AM, Consus wrote: > > > Hi, > > > > > > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see > > > that /etc/networks and some other files (like malloc.conf.5) are > > still > > > present, although there is no use for them in the new release. > > > > > > Is there a reason why these files are not listed in "FIles to > > remove"? > > > Is there a way to track them? It's not like something gonna break, > > but > > > old configuration files (and manual pages) lying around can make > > > someone's life harder during the debug session. > > > > There is no promise that an upgraded machine will be file-for-file > > identical to a fresh install. Here is the list of problems this might > > cause you, as you can see, it's a long list and quite horrible: > > > > * If you use the same hw for 20 years, you might run out of disk space? > > > > Ok, not very long and not very horrible. > > > > You are trying to solve a non-problem. And sometimes, 'specially on an > > upgraded machine, it's great to see how things WERE when the machine > > was > > set up. If you really care, go ahead, delete stuff. > > > > Nick. > > Hi All, > > As I linux guy (my experience in openBSD can be easily measured in days) > I can share the view of less experienced user that was planing to > upgrade from 6.4 to 6.5 and that eneded with a full reinstall. > I just upgraded 18 servers running mission critical network infrastructure and services for a research group of 150 people. Everything went without a glitch. Some of the servers have been continuously upgraded since OpenBSD 5.4. That is a solid 5 years which is a typical lifespan of a production server. Just as a comparison, I am still afraid to upgrade dozen or so file servers and jail hosts running FreeBSD 11.2 to 12.0 in-spite of root on the ZFS mirror and beadm. I typically wait at least year and a half after initial release of Red Hat to do fresh re-installation of our computing nodes. Red Hat as you know doesn't support upgrade between the major releases. Ubuntu (deep learning guys love that crap) upgrade from 16.04 to 18.04 should not be attempted on the production server. On the top of it network stack on Ubuntu 18.04 is completely broken (at lease running as Xen DomU. I was too afraid to try on our AWS instances). > I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to 6.5 > and thus it seemed that booting from the 6.5 DVD will do the trick. > Sadly the installer never checked the avalable space , but just started > to do it's stuff until reporting that not enough space is available. > > Why did the installer allow installation despite the available space is > low ( even windows checks available space :) )??? > > Why should the end-user delete old unnecessary/problematic files ? Because Theo's misplaced his crystal ball and without it, it's impossible for him to tell which of your files are old and unnecessary and which once are your local modifications and important data files. > Usually we do have package management system to take care of that (or at > least to rename those files in case we really need them). > > For me, system upgrade is a very complicated and error prone > procedure. > Just move on. Stick to what you know and feel comfortable working with. Cheers, Predrag > P.S.: No offence here, just sharing my thoughts. > > Best Regards, > Strahil Nikolov
Re: Upgrade procedure (6.4 -> 6.5)
On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland wrote: >On 5/2/19 1:52 AM, Consus wrote: >> Hi, >> >> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see >> that /etc/networks and some other files (like malloc.conf.5) are >still >> present, although there is no use for them in the new release. >> >> Is there a reason why these files are not listed in "FIles to >remove"? >> Is there a way to track them? It's not like something gonna break, >but >> old configuration files (and manual pages) lying around can make >> someone's life harder during the debug session. > >There is no promise that an upgraded machine will be file-for-file >identical to a fresh install. Here is the list of problems this might >cause you, as you can see, it's a long list and quite horrible: > >* If you use the same hw for 20 years, you might run out of disk space? > >Ok, not very long and not very horrible. > >You are trying to solve a non-problem. And sometimes, 'specially on an >upgraded machine, it's great to see how things WERE when the machine >was >set up. If you really care, go ahead, delete stuff. > >Nick. Hi All, As I linux guy (my experience in openBSD can be easily measured in days) I can share the view of less experienced user that was planing to upgrade from 6.4 to 6.5 and that eneded with a full reinstall. I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to 6.5 and thus it seemed that booting from the 6.5 DVD will do the trick. Sadly the installer never checked the avalable space , but just started to do it's stuff until reporting that not enough space is available. Why did the installer allow installation despite the available space is low ( even windows checks available space :) )??? Why should the end-user delete old unnecessary/problematic files ? Usually we do have package management system to take care of that (or at least to rename those files in case we really need them). For me, system upgrade is a very complicated and error prone procedure. P.S.: No offence here, just sharing my thoughts. Best Regards, Strahil Nikolov
Re: Upgrade procedure (6.4 -> 6.5)
On 02/05/2019 6:23 a.m., Stephen Gregoratto wrote:
On 2019-05-02 11:46, Noth wrote:
I set up a script for sysclean:
cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done
Nitpick, but this could be shortened to:
xargs rm -rf < sysclean??.txt
Just tested this on my server, so it should work fine.
If there are filenames with spaces in them, I think that command won't
work as expected.
Cheers,
Steve Williams
Re: Upgrade procedure (6.4 -> 6.5)
On 03/05/2019 10:48, Gonzalo L. Rodriguez wrote:
On Thu, 02 May 2019 at 11:46:20 +0200, Noth wrote:
On 02/05/2019 11:02, Consus wrote:
On 10:27 Thu 02 May, Markus Hennecke wrote:
Am 02.05.2019 um 09:52 schrieb Consus:
I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
that /etc/networks and some other files (like malloc.conf.5) are still
present, although there is no use for them in the new release.
Is there a reason why these files are not listed in "FIles to remove"?
Is there a way to track them? It's not like something gonna break, but
old configuration files (and manual pages) lying around can make
someone's life harder during the debug session.
Take a look at the sysutils/sysclean port.
That's pretty much how I discovered this. But I want to know the
"official" way. Maybe there is a reason why e.g. perl files are to be
removed, but man pages are not.
I set up a script for sysclean:
cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done
You probably want some /etc/sysclean.ignore bits before that
Agreed, thanks for the suggestion. Hadn't read the manpage properly,
just for a change. With that you can just pipe sysclean's output to a
delete script...
Re: Upgrade procedure (6.4 -> 6.5)
On 15:08 Thu 02 May, Ingo Schwarze wrote: > Hi Nick, > > Nick Holland wrote on Thu, May 02, 2019 at 08:04:32AM -0400: > > > There is no promise that an upgraded machine will be file-for-file > > identical to a fresh install. Here is the list of problems this might > > cause you, as you can see, it's a long list and quite horrible: > > > > * If you use the same hw for 20 years, you might run out of disk space? > > > > Ok, not very long and not very horrible. > > > > You are trying to solve a non-problem. And sometimes, 'specially on an > > upgraded machine, it's great to see how things WERE when the machine was > > set up. If you really care, go ahead, delete stuff. > > There is (at least) one slight issue that doesn't have an official > solution yet: manual pages. > > It might be a good idea to do > > # rm -rf /usr/share/man/* /usr/X11R6/man/* > > immediately before an upgrade. > > If you don't do that, man(1) might serve you stale manual pages > afterwards that were removed from the sets, containing information > that no longer applies. > > All the same, so far, we don't officially recommend it, and even i > usually forget about it when doing upgrades. > > Should that be automated? Or are there risks of downsides or side > effects? I'm not sure. Either way, it's hardly a very serious > problem, it's merely slightly annoying. > > Yours, > Ingo Maybe it's a good idea to note this on the upgrade page? Something like "the upgrade procedure may leave some files behing; you can manually clean them up using sysclean package"?
Re: Upgrade procedure (6.4 -> 6.5)
On Thu, 02 May 2019 at 11:46:20 +0200, Noth wrote:
>
> On 02/05/2019 11:02, Consus wrote:
> > On 10:27 Thu 02 May, Markus Hennecke wrote:
> > > Am 02.05.2019 um 09:52 schrieb Consus:
> > > > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
> > > > that /etc/networks and some other files (like malloc.conf.5) are still
> > > > present, although there is no use for them in the new release.
> > > >
> > > > Is there a reason why these files are not listed in "FIles to remove"?
> > > > Is there a way to track them? It's not like something gonna break, but
> > > > old configuration files (and manual pages) lying around can make
> > > > someone's life harder during the debug session.
> > > Take a look at the sysutils/sysclean port.
> > That's pretty much how I discovered this. But I want to know the
> > "official" way. Maybe there is a reason why e.g. perl files are to be
> > removed, but man pages are not.
> >
> I set up a script for sysclean:
>
> cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done
You probably want some /etc/sysclean.ignore bits before that
> sysclean65.txt is obtained by running sysclean -a >>sysclean65.txt . I don't
> run that line in sysclean65.sh because the files have to be reviewed to
> prevent deletion of any additional files you may have added, like certs or
> scripts.
>
> HTH
>
> Noth
>
--
- gonzalo
Re: Upgrade procedure (6.4 -> 6.5)
Hi Chris, Chris Cappuccio wrote on Thu, May 02, 2019 at 12:08:07PM -0700: > Ingo Schwarze [schwa...@usta.de] wrote: >> It might be a good idea to do >> >> # rm -rf /usr/share/man/* /usr/X11R6/man/* >> >> immediately before an upgrade. > I go one step further, and rm -rf /usr/include /usr/share /usr/X11R6 > before a new snapshot is applied. This is a bit overkill That may well be adequate for your personal needs, though we certainly can't make that the default. In particular, you are deleting /usr/X11R6/lib/ which means that many installed packages stop working, and also private programs that you may have compiled from source. Sure, you should run "pkg_add -u" anyway, and also recompile whatever you compiled by hand. All the same, for the average user, the expectation is that doing an upgrade will usually *not* result in programs linked against old libraries being broken - except, of course, in the case of major flag days described in upgrade*.html and current.html. Yours, Ingo > but it's easier than trying to remember what subdirectories to > include during any given release transition.
Re: Upgrade procedure (6.4 -> 6.5)
Ingo Schwarze [schwa...@usta.de] wrote: > > It might be a good idea to do > > # rm -rf /usr/share/man/* /usr/X11R6/man/* > > immediately before an upgrade. > I go one step further, and rm -rf /usr/include /usr/share /usr/X11R6 before a new snapshot is applied. This is a bit overkill but it's easier than trying to remember what subdirectories to include during any given release transition.
Re: Upgrade procedure (6.4 -> 6.5)
Hi Nick, Nick Holland wrote on Thu, May 02, 2019 at 08:04:32AM -0400: > There is no promise that an upgraded machine will be file-for-file > identical to a fresh install. Here is the list of problems this might > cause you, as you can see, it's a long list and quite horrible: > > * If you use the same hw for 20 years, you might run out of disk space? > > Ok, not very long and not very horrible. > > You are trying to solve a non-problem. And sometimes, 'specially on an > upgraded machine, it's great to see how things WERE when the machine was > set up. If you really care, go ahead, delete stuff. There is (at least) one slight issue that doesn't have an official solution yet: manual pages. It might be a good idea to do # rm -rf /usr/share/man/* /usr/X11R6/man/* immediately before an upgrade. If you don't do that, man(1) might serve you stale manual pages afterwards that were removed from the sets, containing information that no longer applies. All the same, so far, we don't officially recommend it, and even i usually forget about it when doing upgrades. Should that be automated? Or are there risks of downsides or side effects? I'm not sure. Either way, it's hardly a very serious problem, it's merely slightly annoying. Yours, Ingo
Re: Upgrade procedure (6.4 -> 6.5)
On 2019-05-02 11:46, Noth wrote:
> I set up a script for sysclean:
>
> cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done
Nitpick, but this could be shortened to:
xargs rm -rf < sysclean??.txt
Just tested this on my server, so it should work fine.
--
Stephen Gregoratto
PGP: 3FC6 3D0E 2801 C348 1C44 2D34 A80C 0F8E 8BAB EC8B
Re: Upgrade procedure (6.4 -> 6.5)
On 09:42 Thu 02 May, Stuart Henderson wrote: > The upgrade notes only list files which are likely to cause a problem > if they're left lying around. Oh, okay.
Re: Upgrade procedure (6.4 -> 6.5)
On 5/2/19 1:52 AM, Consus wrote: > Hi, > > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see > that /etc/networks and some other files (like malloc.conf.5) are still > present, although there is no use for them in the new release. > > Is there a reason why these files are not listed in "FIles to remove"? > Is there a way to track them? It's not like something gonna break, but > old configuration files (and manual pages) lying around can make > someone's life harder during the debug session. There is no promise that an upgraded machine will be file-for-file identical to a fresh install. Here is the list of problems this might cause you, as you can see, it's a long list and quite horrible: * If you use the same hw for 20 years, you might run out of disk space? Ok, not very long and not very horrible. You are trying to solve a non-problem. And sometimes, 'specially on an upgraded machine, it's great to see how things WERE when the machine was set up. If you really care, go ahead, delete stuff. Nick.
Re: Upgrade procedure (6.4 -> 6.5)
On 02/05/2019 11:02, Consus wrote:
On 10:27 Thu 02 May, Markus Hennecke wrote:
Am 02.05.2019 um 09:52 schrieb Consus:
I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
that /etc/networks and some other files (like malloc.conf.5) are still
present, although there is no use for them in the new release.
Is there a reason why these files are not listed in "FIles to remove"?
Is there a way to track them? It's not like something gonna break, but
old configuration files (and manual pages) lying around can make
someone's life harder during the debug session.
Take a look at the sysutils/sysclean port.
That's pretty much how I discovered this. But I want to know the
"official" way. Maybe there is a reason why e.g. perl files are to be
removed, but man pages are not.
I set up a script for sysclean:
cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done
sysclean65.txt is obtained by running sysclean -a >>sysclean65.txt . I
don't run that line in sysclean65.sh because the files have to be
reviewed to prevent deletion of any additional files you may have added,
like certs or scripts.
HTH
Noth
Re: Upgrade procedure (6.4 -> 6.5)
On 2019-05-02, Consus wrote: > On 10:27 Thu 02 May, Markus Hennecke wrote: >> Am 02.05.2019 um 09:52 schrieb Consus: >> > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see >> > that /etc/networks and some other files (like malloc.conf.5) are still >> > present, although there is no use for them in the new release. >> > >> > Is there a reason why these files are not listed in "FIles to remove"? >> > Is there a way to track them? It's not like something gonna break, but >> > old configuration files (and manual pages) lying around can make >> > someone's life harder during the debug session. >> >> Take a look at the sysutils/sysclean port. > > That's pretty much how I discovered this. But I want to know the > "official" way. Maybe there is a reason why e.g. perl files are to be > removed, but man pages are not. > > The upgrade notes only list files which are likely to cause a problem if they're left lying around.
Re: Upgrade procedure (6.4 -> 6.5)
On 10:27 Thu 02 May, Markus Hennecke wrote: > Am 02.05.2019 um 09:52 schrieb Consus: > > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see > > that /etc/networks and some other files (like malloc.conf.5) are still > > present, although there is no use for them in the new release. > > > > Is there a reason why these files are not listed in "FIles to remove"? > > Is there a way to track them? It's not like something gonna break, but > > old configuration files (and manual pages) lying around can make > > someone's life harder during the debug session. > > Take a look at the sysutils/sysclean port. That's pretty much how I discovered this. But I want to know the "official" way. Maybe there is a reason why e.g. perl files are to be removed, but man pages are not.
Re: Upgrade procedure (6.4 -> 6.5)
Am 02.05.2019 um 09:52 schrieb Consus: > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see > that /etc/networks and some other files (like malloc.conf.5) are still > present, although there is no use for them in the new release. > > Is there a reason why these files are not listed in "FIles to remove"? > Is there a way to track them? It's not like something gonna break, but > old configuration files (and manual pages) lying around can make > someone's life harder during the debug session. Take a look at the sysutils/sysclean port. Regards Markus
