Re: Upgrade procedure (6.4 -> 6.5)

2019-05-08 Thread Dumitru Moldovan

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)

2019-05-07 Thread Nick Holland
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)

2019-05-07 Thread Ingo Schwarze
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)

2019-05-07 Thread Dumitru Moldovan

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)

2019-05-06 Thread Wolfgang Pfeiffer

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=155634461814603=2



Yours,
 Ingo




Re: Upgrade procedure (6.4 -> 6.5)

2019-05-05 Thread Ingo Schwarze
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)

2019-05-05 Thread Otto Moerbeek
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)

2019-05-05 Thread Ingo Schwarze
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)

2019-05-04 Thread Wolfgang Pfeiffer

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)

2019-05-04 Thread Strahil Nikolov
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 

Re: Upgrade procedure (6.4 -> 6.5)

2019-05-04 Thread Noth



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 

Re: Upgrade procedure (6.4 -> 6.5)

2019-05-03 Thread Nick Holland
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)

2019-05-03 Thread Predrag Punosevac
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)

2019-05-03 Thread Strahil Nikolov
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)

2019-05-03 Thread Steve Williams

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)

2019-05-03 Thread Noth



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)

2019-05-03 Thread Consus
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)

2019-05-03 Thread Gonzalo L. Rodriguez
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)

2019-05-02 Thread Ingo Schwarze
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)

2019-05-02 Thread Chris Cappuccio
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)

2019-05-02 Thread Ingo Schwarze
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)

2019-05-02 Thread Stephen Gregoratto
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)

2019-05-02 Thread Consus
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)

2019-05-02 Thread Nick Holland
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)

2019-05-02 Thread Noth



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)

2019-05-02 Thread Stuart Henderson
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)

2019-05-02 Thread Consus
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)

2019-05-02 Thread Markus Hennecke
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