Re: Removal of old libraries
Thu, 17 Nov 2016 00:11:36 -0700 Clint Pachl > You're absolutely right Anton. After rereading what I wrote, I see I got > a little out of line. > > Thanks, > Clint Hi Clint, To be fair I am a one strict in course of thought fellow, so I know very well when and why you're solid with this. This is right for you, please also allow me to thank everyone in OpenBSD for providing an upgrade path as the Time optimisation tool. I am, therefore, only writing it for me. I would be glad to read your next posts regarding backup-restore advice. Yet please allow room for the convergent comb tools to exist gracefully. What I see as most helpful is troubleshooting, and improving procedures. Kind regards, Anton > li...@wrant.com wrote on 11/16/16 16:47: > > Tue, 15 Nov 2016 00:29:56 -0700 Clint Pachl > > [...] > >> This sounds like someone who is not confident in their backup/restore > >> procedure, if one even exists. I think you need to worry more about that > >> than me saving a few megabytes with my upgrade process. > > Hi Clint, > > > > You need not worry at all. That is other people's data on their own sites. > > > >> Like I mentioned a couple times in the thread, I have "level 0" dumps; > >> that's consistency. I would not classify that as "nothing." There is a > >> reason why restore(8) and ftp(1) are included on bsd.rd. > > Whatever.. Nobody cares much about what you have. We system operators care > > about the choices, and options the operating system, and tool kits provide.. > > > >> Oh yeah, and before you know it your crufty libc.so.84.2 is 2 years old > >> and full of security vulnerabilities. Thank god your users can still use > >> it and you don't have to bother them with a recompile. > > That is a system policy depending from site to site, you need not police it. > > > >> I thought the philosophy of the project is to move forward for the sake > >> of proactive security and correctness, not to rely on buggy legacy code > >> because it's convenient and lazy. > > You think too much. There is no such thing as philosophy of the project and > > this kind of over-hyped black and white thinking is... obsolete and useless. > > There are many upgrade and maintain choices, don't try to sell bibles here.. > > > > Kind regards, > > Anton
Re: Removal of old libraries
Tue, 15 Nov 2016 00:29:56 -0700 Clint Pachl [...] > This sounds like someone who is not confident in their backup/restore > procedure, if one even exists. I think you need to worry more about that > than me saving a few megabytes with my upgrade process. Hi Clint, You need not worry at all. That is other people's data on their own sites. > Like I mentioned a couple times in the thread, I have "level 0" dumps; > that's consistency. I would not classify that as "nothing." There is a > reason why restore(8) and ftp(1) are included on bsd.rd. Whatever.. Nobody cares much about what you have. We system operators care about the choices, and options the operating system, and tool kits provide.. > Oh yeah, and before you know it your crufty libc.so.84.2 is 2 years old > and full of security vulnerabilities. Thank god your users can still use > it and you don't have to bother them with a recompile. That is a system policy depending from site to site, you need not police it. > I thought the philosophy of the project is to move forward for the sake > of proactive security and correctness, not to rely on buggy legacy code > because it's convenient and lazy. You think too much. There is no such thing as philosophy of the project and this kind of over-hyped black and white thinking is... obsolete and useless. There are many upgrade and maintain choices, don't try to sell bibles here.. Kind regards, Anton
Re: Removal of old libraries
Jan Stary wrote on 11/14/16 03:00: On Nov 14 00:14:19, pa...@ecentryx.com wrote: But the very next step in the upgrade blows away the system by overwriting it anyway. Right? What could happen? What if following the normal procedure of untaring the OS sets on top of the existing system fails midway? Then you have an inconsistent system too. Yes, you have an inconsistent system, as opposed to nothing. This sounds like someone who is not confident in their backup/restore procedure, if one even exists. I think you need to worry more about that than me saving a few megabytes with my upgrade process. Like I mentioned a couple times in the thread, I have "level 0" dumps; that's consistency. I would not classify that as "nothing." There is a reason why restore(8) and ftp(1) are included on bsd.rd. This behavior of mine may stem from my days as a hard-real-time embedded systems engineer where we had to get rid of every single byte that did not matter. I used to count the assembly instructions and add up all the clock cycles for each hardware interrupt routine to make sure we would never stall/slow the system. I just like minimal I guess. Say I compile a C program on your system, which gets linked to /usr/lib/libc.so.84.2. After an upgrade, my program no longer works. Bad, bad admin! Oh yeah, and before you know it your crufty libc.so.84.2 is 2 years old and full of security vulnerabilities. Thank god your users can still use it and you don't have to bother them with a recompile. I thought the philosophy of the project is to move forward for the sake of proactive security and correctness, not to rely on buggy legacy code because it's convenient and lazy.
Re: Removal of old libraries
On Nov 14 00:14:19, pa...@ecentryx.com wrote: > But the very next step in the upgrade blows away the system by overwriting > it anyway. Right? > > What could happen? What if following the normal procedure of untaring the OS > sets on top of the existing system fails midway? Then you have an > inconsistent system too. Yes, you have an inconsistent system, as opposed to nothing. > This behavior of mine may stem from my days as a hard-real-time embedded > systems engineer where we had to get rid of every single byte that did not > matter. I used to count the assembly instructions and add up all the clock > cycles for each hardware interrupt routine to make sure we would never > stall/slow the system. I just like minimal I guess. Say I compile a C program on your system, which gets linked to /usr/lib/libc.so.84.2. After an upgrade, my program no longer works. Bad, bad admin!
Re: Removal of old libraries
Amit Kulkarni wrote on 11/08/16 07:22: On Tue, Nov 8, 2016 at 12:53 AM, Clint Pachl wrote: Ax0n wrote on 09/03/16 13:12: I've got a Toshiba NB305 netbook that's been my daily-use laptop for more than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in early May 2011. I've been quite happy with how it works, and I've been doing bsd.rd upgrades and M:Tier binary updates ever since. There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an atime of my last level 0 dump several months ago. Looks like pkg_add -u left a bunch of stuff behind. Is there a recommended way to clean this stuff up, or should I just start chopping away with something like: find /usr/local/lib -type f -atime +90 | doas xargs rm (after a new level 0 dump, obviously...) Ax0n wrote on 09/03/16 13:12: I've got a Toshiba NB305 netbook that's been my daily-use laptop for more than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in early May 2011. I've been quite happy with how it works, and I've been doing bsd.rd upgrades and M:Tier binary updates ever since. There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an atime of my last level 0 dump several months ago. Looks like pkg_add -u left a bunch of stuff behind. Is there a recommended way to clean this stuff up, or should I just start chopping away with something like: find /usr/local/lib -type f -atime +90 | doas xargs rm (after a new level 0 dump, obviously...) I've been removing the old system during the upgrade script since 4.9, coincidentally. I haven't had a problem yet while upgrading two production servers and my two laptops, from release to release. After selecting the OS sets during the upgrade, but before hitting ENTER, type ! at the “Set name(s)?� prompt to enter a shell. Then run: `cd /mnt && rm -rf bin sbin usr/!(local) && exit`. Then just hit enter and continue running the upgrade script. WARNING: this will wipe out your system, so if the upgrade fails for some reason, you are TOTALLY SCREWED! I periodically (every few releases) clean out /usr/local. First, get a list of manually installed packages using `pkg_info -m`. Then uninstall everything. It is interesting to see what gets left behind. If any garbage is left over, remove it. Then reinstall from your generated list. I don't do this very often anymore as `pkg_delete -a` seems to clean up quite well. As insurance, I take level 0 dumps just before upgrading or cleaning /usr/local. Also, one of my laptops is a spare that has all the same software installed as the production servers and my main laptop. So this laptop is a test run if you will. If there are quirks, my main laptop is my second chance to make sure I know what the hell I'm doing before finally upgrading my two production systems. Also, just a public announcement, test your restore-from-backup process once in awhile. I've always thought about sharing this process, but always thought it is probably not the best advice. Clint, pkg_add sysclean This will restore your system as close to a new install as possible. What you are doing is quite dangerous. But the very next step in the upgrade blows away the system by overwriting it anyway. Right? What could happen? What if following the normal procedure of untaring the OS sets on top of the existing system fails midway? Then you have an inconsistent system too. I'd rather start with a clean slate and build on top of that than chip away at an existing, running system, which others have recommended via the sysclean package (I haven't looked at the code so I don't know what it does, but I wouldn't trust it until I inspected the code). I have all my OS sets and packages stored on a local server along with my level 0 dumps, which I've never needed by the way. If the worst happens, I just PXE boot the ramdisk image and do a quick restore of the system to where it was just before the upgrade. I've always liked the clean install process, and this modified process gets me close without actually doing a clean install. I've done this for 11 releases now with 4 systems without any problems. Just thought I'd share, but with the warnings I provided earlier. This behavior of mine may stem from my days as a hard-real-time embedded systems engineer where we had to get rid of every single byte that did not matter. I used to count the assembly instructions and add up all the clock cycles for each hardware interrupt routine to make sure we would never stall/slow the system. I just like minimal I guess.
Re: Removal of old libraries
On Tue, Nov 8, 2016 at 12:53 AM, Clint Pachl wrote: > Ax0n wrote on 09/03/16 13:12: > >> I've got a Toshiba NB305 netbook that's been my daily-use laptop for more >> than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in >> early May 2011. I've been quite happy with how it works, and I've been >> doing bsd.rd upgrades and M:Tier binary updates ever since. >> >> There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with >> an >> atime of my last level 0 dump several months ago. Looks like pkg_add -u >> left a bunch of stuff behind. Is there a recommended way to clean this >> stuff up, or should I just start chopping away with something like: >> >> find /usr/local/lib -type f -atime +90 | doas xargs rm >> >> (after a new level 0 dump, obviously...) >> >> > Ax0n wrote on 09/03/16 13:12: > > I've got a Toshiba NB305 netbook that's been my daily-use laptop for more > > than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in > > early May 2011. I've been quite happy with how it works, and I've been > > doing bsd.rd upgrades and M:Tier binary updates ever since. > > > > There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with > an > > atime of my last level 0 dump several months ago. Looks like pkg_add -u > > left a bunch of stuff behind. Is there a recommended way to clean this > > stuff up, or should I just start chopping away with something like: > > > > find /usr/local/lib -type f -atime +90 | doas xargs rm > > > > (after a new level 0 dump, obviously...) > > I've been removing the old system during the upgrade script since 4.9, > coincidentally. I haven't had a problem yet while upgrading two production > servers and my two laptops, from release to release. > > After selecting the OS sets during the upgrade, but before hitting ENTER, > type ! at the âSet name(s)?â prompt to enter a shell. Then run: `cd /mnt && > rm -rf bin sbin usr/!(local) && exit`. Then just hit enter and continue > running the upgrade script. > > WARNING: this will wipe out your system, so if the upgrade fails for some > reason, you are TOTALLY SCREWED! > > I periodically (every few releases) clean out /usr/local. First, get a > list of manually installed packages using `pkg_info -m`. Then uninstall > everything. It is interesting to see what gets left behind. If any garbage > is left over, remove it. Then reinstall from your generated list. I don't > do this very often anymore as `pkg_delete -a` seems to clean up quite well. > > As insurance, I take level 0 dumps just before upgrading or cleaning > /usr/local. Also, one of my laptops is a spare that has all the same > software installed as the production servers and my main laptop. So this > laptop is a test run if you will. If there are quirks, my main laptop is my > second chance to make sure I know what the hell I'm doing before finally > upgrading my two production systems. > > Also, just a public announcement, test your restore-from-backup process > once in awhile. > > I've always thought about sharing this process, but always thought it is > probably not the best advice. > > Clint, pkg_add sysclean This will restore your system as close to a new install as possible. What you are doing is quite dangerous.
Re: Removal of old libraries
Ax0n wrote on 09/03/16 13:12: I've got a Toshiba NB305 netbook that's been my daily-use laptop for more than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in early May 2011. I've been quite happy with how it works, and I've been doing bsd.rd upgrades and M:Tier binary updates ever since. There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an atime of my last level 0 dump several months ago. Looks like pkg_add -u left a bunch of stuff behind. Is there a recommended way to clean this stuff up, or should I just start chopping away with something like: find /usr/local/lib -type f -atime +90 | doas xargs rm (after a new level 0 dump, obviously...) Ax0n wrote on 09/03/16 13:12: > I've got a Toshiba NB305 netbook that's been my daily-use laptop for more > than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in > early May 2011. I've been quite happy with how it works, and I've been > doing bsd.rd upgrades and M:Tier binary updates ever since. > > There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an > atime of my last level 0 dump several months ago. Looks like pkg_add -u > left a bunch of stuff behind. Is there a recommended way to clean this > stuff up, or should I just start chopping away with something like: > > find /usr/local/lib -type f -atime +90 | doas xargs rm > > (after a new level 0 dump, obviously...) I've been removing the old system during the upgrade script since 4.9, coincidentally. I haven't had a problem yet while upgrading two production servers and my two laptops, from release to release. After selecting the OS sets during the upgrade, but before hitting ENTER, type ! at the “Set name(s)?” prompt to enter a shell. Then run: `cd /mnt && rm -rf bin sbin usr/!(local) && exit`. Then just hit enter and continue running the upgrade script. WARNING: this will wipe out your system, so if the upgrade fails for some reason, you are TOTALLY SCREWED! I periodically (every few releases) clean out /usr/local. First, get a list of manually installed packages using `pkg_info -m`. Then uninstall everything. It is interesting to see what gets left behind. If any garbage is left over, remove it. Then reinstall from your generated list. I don't do this very often anymore as `pkg_delete -a` seems to clean up quite well. As insurance, I take level 0 dumps just before upgrading or cleaning /usr/local. Also, one of my laptops is a spare that has all the same software installed as the production servers and my main laptop. So this laptop is a test run if you will. If there are quirks, my main laptop is my second chance to make sure I know what the hell I'm doing before finally upgrading my two production systems. Also, just a public announcement, test your restore-from-backup process once in awhile. I've always thought about sharing this process, but always thought it is probably not the best advice.
Re: Removal of old libraries
Thank you very much, all! Giving it a shot now. On Sat, Sep 3, 2016, 16:35 Juan Francisco Cantero Hurtado wrote: > On Sat, Sep 03, 2016 at 03:12:53PM -0500, Ax0n wrote: > > I've got a Toshiba NB305 netbook that's been my daily-use laptop for more > > than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in > > early May 2011. I've been quite happy with how it works, and I've been > > doing bsd.rd upgrades and M:Tier binary updates ever since. > > > > There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with > an > > atime of my last level 0 dump several months ago. Looks like pkg_add -u > > left a bunch of stuff behind. Is there a recommended way to clean this > > stuff up, or should I just start chopping away with something like: > > > > find /usr/local/lib -type f -atime +90 | doas xargs rm > > > > (after a new level 0 dump, obviously...) > > > > pkg_add sysclean > > man sysclean > > -- > Juan Francisco Cantero Hurtado http://juanfra.info
Re: Removal of old libraries
On Sat, Sep 03, 2016 at 03:12:53PM -0500, Ax0n wrote: > I've got a Toshiba NB305 netbook that's been my daily-use laptop for more > than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in > early May 2011. I've been quite happy with how it works, and I've been > doing bsd.rd upgrades and M:Tier binary updates ever since. > > There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an > atime of my last level 0 dump several months ago. Looks like pkg_add -u > left a bunch of stuff behind. Is there a recommended way to clean this > stuff up, or should I just start chopping away with something like: > > find /usr/local/lib -type f -atime +90 | doas xargs rm > > (after a new level 0 dump, obviously...) > pkg_add sysclean man sysclean -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Removal of old libraries
pkg_delete -a El 3 sept. 2016 3:12 PM, Ax0n escribió: > > I've got a Toshiba NB305 netbook that's been my daily-use laptop for more > than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in > early May 2011. I've been quite happy with how it works, and I've been > doing bsd.rd upgrades and M:Tier binary updates ever since. > > There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an > atime of my last level 0 dump several months ago. Looks like pkg_add -u > left a bunch of stuff behind. Is there a recommended way to clean this > stuff up, or should I just start chopping away with something like: > > find /usr/local/lib -type f -atime +90 | doas xargs rm > > (after a new level 0 dump, obviously...)
Removal of old libraries
I've got a Toshiba NB305 netbook that's been my daily-use laptop for more than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in early May 2011. I've been quite happy with how it works, and I've been doing bsd.rd upgrades and M:Tier binary updates ever since. There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an atime of my last level 0 dump several months ago. Looks like pkg_add -u left a bunch of stuff behind. Is there a recommended way to clean this stuff up, or should I just start chopping away with something like: find /usr/local/lib -type f -atime +90 | doas xargs rm (after a new level 0 dump, obviously...)
