Re: How can I remove sets installed by sysupgrade?
cho...@jtan.com wrote: > It seems that the OpenBSD devs and/or project "support" only an > installation which has not not taken advantage of any of the optional > non-extras (primarily: not installing sets) the installer has to > offer. I understand and agree with the reasons for this but I grumble > somewhat about the way it's presented. It is rather fundamental. When we provide more choices to users, it means we must support the code that supplies more choices, and must test those cases before shipping releases. This type of testing is very often not done for releases, because the non-default cases are used by a minority, so it is where things break. I have threatened a few times to get merge all sets into one, because the few people non-deliberately choosing the non-default case are tripping over their incorrectly tied shoelaces too much.
Re: How can I remove sets installed by sysupgrade?
cho...@jtan.com wrote: > Patronisation aside, your computer's storage is a lot cheaper than the > mental effort required to deal with a system that's non-standard but > only by having a few bits wasted by their _complete lack of use_. well said.
Re: How can I remove sets installed by sysupgrade?
On 9/17/19 12:23 PM, Marc Espie wrote: > On Tue, Sep 17, 2019 at 02:31:59PM -, Stuart Henderson wrote: >> (To be clear, I think installing a restricted subset of the OS for >> security reasons is pointless here, but can be really helpful when you >> have to deal with limited space in partitions - and those just saying >> "storage is cheap" are ignoring the often very real cost of getting >> to the machine to replace the storage :) > > Ditto. > > We still run on somewhat cramped machines, and even replacing an SD card > with a bigger model might sometimes be an issue because of various reasons. > > ... or stuff with utterly outdated controler formats, where you may > get in situations that your SCSI3 disk buys it and that's it, no more > full installs for you. > Ditto followed by a single quote? We also work great on some really slow storage, like USB flash drives. Leaving out x*tgz, and compXX.tgz are big time savers when upgrading a flash based install. On the other hand, KARL and library randomization are also killing those solutions...so I guess it might be time to move on? Nick.
Re: How can I remove sets installed by sysupgrade?
On Tue, Sep 17, 2019 at 02:31:59PM -, Stuart Henderson wrote: > (To be clear, I think installing a restricted subset of the OS for > security reasons is pointless here, but can be really helpful when you > have to deal with limited space in partitions - and those just saying > "storage is cheap" are ignoring the often very real cost of getting > to the machine to replace the storage :) Ditto. We still run on somewhat cramped machines, and even replacing an SD card with a bigger model might sometimes be an issue because of various reasons. ... or stuff with utterly outdated controler formats, where you may get in situations that your SCSI3 disk buys it and that's it, no more full installs for you.
Re: How can I remove sets installed by sysupgrade?
>> | > Where sysupgrade ? reboot the machine, see your disks overflow. Boom
>> machine
>> | > kaput.
Disk overflow -> boom can happen anyway even if you had installed all sets
previously.
>> | The problem boils down to: how does sysupgrade, or any other tool, know
>> | which sets have been installed?
>>
>> By having each set install a specific file in a well-known location.
>> Before sysupgrade I wrote my own script to upgrade machines, this uses
>> /var/db/sets/{base,comp,game,man,xbase,xfont,xserve,xshare} to
>> determine what has been installed and upgrade only those sets.
>
> We actually know what file belongs to which set.
> see /usr/lib/locate/src.db
Because sysupgrade depends on boot loader changes in late 6.5-current
snapshots, it doesn't need to concern itself with identifying installed
sets from <=6.5, adding a simple flag file to each set would be enough
to detect them. Something like this untested diff (plus an analogue
in x's mkr).
(To be clear, I think installing a restricted subset of the OS for
security reasons is pointless here, but can be really helpful when you
have to deal with limited space in partitions - and those just saying
"storage is cheap" are ignoring the often very real cost of getting
to the machine to replace the storage :)
Index: etc/Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.471
diff -u -p -r1.471 Makefile
--- etc/Makefile12 Aug 2019 09:49:21 - 1.471
+++ etc/Makefile17 Sep 2019 14:17:47 -
@@ -66,7 +66,8 @@ RCDAEMONS=amd apmd bgpd bootparamd cron
spamlogd sshd statd switchd syslogd tftpd tftpproxy unbound \
unwind vmd watchdogd wsmoused xenodm ypbind ypldap ypserv
-MISETS=base${OSrev}.tgz comp${OSrev}.tgz man${OSrev}.tgz
game${OSrev}.tgz
+MISETLIST=base comp man game
+MISETS=${MISETLIST:=${OSrev}.tgz}
all clean cleandir depend etc install:
@@ -222,6 +223,8 @@ distribution-etc-root-var: distrib-dirs
${DESTDIR}/etc/rc.d
cd ${DESTDIR}/var; ln -fs ../tmp
chown -h root:wheel ${DESTDIR}/var/tmp
+ cd ${DESTDIR}/var/db/sets; touch ${MISETLIST}
+ chown -R -h root:wheel ${DESTDIR}/var/db/sets
touch ${DESTDIR}/var/sysmerge/etcsum
chown root:wheel ${DESTDIR}/var/sysmerge/etcsum
chmod 644 ${DESTDIR}/var/sysmerge/etcsum
Index: etc/mtree/4.4BSD.dist
===
RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
retrieving revision 1.312
diff -u -p -r1.312 4.4BSD.dist
--- etc/mtree/4.4BSD.dist 27 Jul 2019 14:10:21 - 1.312
+++ etc/mtree/4.4BSD.dist 17 Sep 2019 14:20:04 -
@@ -630,6 +630,8 @@ var
..
pkg
..
+sets
+..
yubikeyuname=root gname=auth mode=0770
..
..
Index: distrib/sets/lists/base/mi
===
RCS file: /cvs/src/distrib/sets/lists/base/mi,v
retrieving revision 1.961
diff -u -p -r1.961 mi
--- distrib/sets/lists/base/mi 19 Aug 2019 19:55:54 - 1.961
+++ distrib/sets/lists/base/mi 17 Sep 2019 14:17:47 -
@@ -7481,6 +7481,8 @@
./var/db/ldap
./var/db/ns
./var/db/pkg
+./var/db/sets
+./var/db/sets/base
./var/db/yubikey
./var/empty
./var/games
Index: distrib/sets/lists/comp/mi
===
RCS file: /cvs/src/distrib/sets/lists/comp/mi,v
retrieving revision 1.1469
diff -u -p -r1.1469 mi
--- distrib/sets/lists/comp/mi 9 Sep 2019 16:49:34 - 1.1469
+++ distrib/sets/lists/comp/mi 17 Sep 2019 14:17:47 -
@@ -3033,3 +3033,4 @@
./usr/share/misc/gprof.callg
./usr/share/misc/gprof.flat
./var/db/libc.tags
+./var/db/sets/comp
Index: distrib/sets/lists/game/mi
===
RCS file: /cvs/src/distrib/sets/lists/game/mi,v
retrieving revision 1.28
diff -u -p -r1.28 mi
--- distrib/sets/lists/game/mi 6 Apr 2019 17:44:51 - 1.28
+++ distrib/sets/lists/game/mi 17 Sep 2019 14:17:47 -
@@ -165,6 +165,7 @@
./usr/share/man/man6/worm.6
./usr/share/man/man6/worms.6
./usr/share/man/man6/wump.6
+./var/db/sets/game
./var/games/phantasia
./var/games/phantasia/characs
./var/games/phantasia/gold
Index: distrib/sets/lists/man/mi
===
RCS file: /cvs/src/distrib/sets/lists/man/mi,v
retrieving revision 1.1531
diff -u -p -r1.1531 mi
--- distrib/sets/lists/man/mi 15 Sep 2019 07:25:18 - 1.1531
+++ distrib/sets/lists/man/mi 17 Sep 2019 14:17:47 -
@@ -2566,3 +2566,4 @@
./usr/share/man/man8/ypxfr.8
./usr/share/man/man8/zdump.8
./usr/share/man/man8/zic.8
+./var/db/sets/man
Re: How can I remove sets installed by sysupgrade?
Paul de Weerd writes:
> On Tue, Sep 17, 2019 at 03:14:22PM +0200, Marc Espie wrote:
> | On Tue, Sep 17, 2019 at 01:48:19PM +0200, Paul de Weerd wrote:
> | > On Tue, Sep 17, 2019 at 01:27:23PM +0200, Marc Espie wrote:
> | > | > By having each set install a specific file in a well-known location.
> | > | > Before sysupgrade I wrote my own script to upgrade machines, this uses
> | > | > /var/db/sets/{base,comp,game,man,xbase,xfont,xserve,xshare} to
> | > | > determine what has been installed and upgrade only those sets.
> | > |
> | > | We actually know what file belongs to which set.
> | > | see /usr/lib/locate/src.db
> | >
> | > This doesn't list files from x-sets.
> |
> | ... there's obviously the corresponding database for x in xbase, duh
>
> Right. Wasn't aware of that one, but doesn't really make it easier:
>
> So, if /usr/lib/locate/src.db exists, we can ...
I rest my case.
Matthew
Re: How can I remove sets installed by sysupgrade?
On Tue, Sep 17, 2019 at 03:14:22PM +0200, Marc Espie wrote:
| On Tue, Sep 17, 2019 at 01:48:19PM +0200, Paul de Weerd wrote:
| > On Tue, Sep 17, 2019 at 01:27:23PM +0200, Marc Espie wrote:
| > | > By having each set install a specific file in a well-known location.
| > | > Before sysupgrade I wrote my own script to upgrade machines, this uses
| > | > /var/db/sets/{base,comp,game,man,xbase,xfont,xserve,xshare} to
| > | > determine what has been installed and upgrade only those sets.
| > |
| > | We actually know what file belongs to which set.
| > | see /usr/lib/locate/src.db
| >
| > This doesn't list files from x-sets.
|
| ... there's obviously the corresponding database for x in xbase, duh
Right. Wasn't aware of that one, but doesn't really make it easier:
So, if /usr/lib/locate/src.db exists, we can see if the files that it
knows about can be found on the local filesystem and then per set pick
a file to check for existence. And if /usr/X11R6/lib/locate/xorg.db
exists, we can do the same for the x-sets.
What if I chose to only install xfont, to use the TTF fonts with my
webserver? Then I don't have the xorg.db locate database but would
still have a working system, but now you're not upgrading xfont?
The "file to set"-mapping isn't very convenient to determine which sets
were installed and have to be upgraded. Having each set contain one
small (empty?) file in a known location would make this trivial at a
very small cost.
But I repeat: the argument that not installing all sets gives you a
'non standard' system suggests that this approach isn't viable.
Cheers,
Paul
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: How can I remove sets installed by sysupgrade?
On Tue, Sep 17, 2019 at 01:48:19PM +0200, Paul de Weerd wrote:
> On Tue, Sep 17, 2019 at 01:27:23PM +0200, Marc Espie wrote:
> | > By having each set install a specific file in a well-known location.
> | > Before sysupgrade I wrote my own script to upgrade machines, this uses
> | > /var/db/sets/{base,comp,game,man,xbase,xfont,xserve,xshare} to
> | > determine what has been installed and upgrade only those sets.
> |
> | We actually know what file belongs to which set.
> | see /usr/lib/locate/src.db
>
> This doesn't list files from x-sets.
... there's obviously the corresponding database for x in xbase, duh
Re: How can I remove sets installed by sysupgrade?
On Tue, Sep 17, 2019 at 01:27:23PM +0200, Marc Espie wrote:
| > By having each set install a specific file in a well-known location.
| > Before sysupgrade I wrote my own script to upgrade machines, this uses
| > /var/db/sets/{base,comp,game,man,xbase,xfont,xserve,xshare} to
| > determine what has been installed and upgrade only those sets.
|
| We actually know what file belongs to which set.
| see /usr/lib/locate/src.db
This doesn't list files from x-sets.
Cheers,
Paul
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: How can I remove sets installed by sysupgrade?
On Tue, Sep 17, 2019 at 01:08:45PM +0200, Florian Obser wrote: > On Tue, Sep 17, 2019 at 09:43:20AM +0200, Marc Espie wrote: > > I'm a bit surprised nobody looked at instrumenting what sets are actually > > installed on a machine during install/manual upgrade and cloning that > > into sysupgrade to avoid this kind of surprise... > > > > Yeah, I think sysupgrade was a mistake. Too many people want different > things from it while at the same time the upgrade mechanism in bsd.rd > is perfectly stream lined and has all the options people need. I disagree. I update my systems way more frequently now that I have sysupgrade. It went from "almost" automated to fully automated, and that takes a load off the brain. However, there's about zero reason not to somehow use the sets installed information to have sysupgrade "just upgrade the installed sets" by default.
Re: How can I remove sets installed by sysupgrade?
On Tue, Sep 17, 2019 at 09:01:47AM +0100, cho...@jtan.com wrote: > Marc Espie writes: > > I'm a bit surprised nobody looked at instrumenting what sets are actually > > installed on a machine during install/manual upgrade and cloning that > > into sysupgrade to avoid this kind of surprise... > > I mentioned the possibility wrt. syspatch but it was rejected in favour > of expecting users to run a default system or, in effect, become > developers. Not a stance I entirely agree with but which nevertheless > has its merits. syspatch(8) tries to skip uninstalled sets. -- Antoine
Re: How can I remove sets installed by sysupgrade?
On Tue, Sep 17, 2019 at 01:15:06PM +0200, Paul de Weerd wrote:
> On Tue, Sep 17, 2019 at 09:39:00AM +0100, cho...@jtan.com wrote:
> | Marc Espie writes:
> | > On Tue, Sep 17, 2019 at 09:01:47AM +0100, cho...@jtan.com wrote:
> | > > Marc Espie writes:
> | > > > I'm a bit surprised nobody looked at instrumenting what sets are
> actually
> | > > > installed on a machine during install/manual upgrade and cloning that
> | > > > into sysupgrade to avoid this kind of surprise...
> | > >
> | > > I mentioned the possibility wrt. syspatch but it was rejected in favour
> | > > of expecting users to run a default system or, in effect, become
> | > > developers. Not a stance I entirely agree with but which nevertheless
> | > > has its merits.
> | >
> | > But sysupgrade is a much "simpler" mechanism than syspatch.
> | >
> | > More importantly,
> | > - sysupgrade is definitely about the sets
> | > - if you have a non default installation, syspatch happens *at user level*
> | > so you have every opportunity to figure out what's going on.
> | > Where sysupgrade ? reboot the machine, see your disks overflow. Boom
> machine
> | > kaput.
> |
> | The problem boils down to: how does sysupgrade, or any other tool, know
> | which sets have been installed?
>
> By having each set install a specific file in a well-known location.
> Before sysupgrade I wrote my own script to upgrade machines, this uses
> /var/db/sets/{base,comp,game,man,xbase,xfont,xserve,xshare} to
> determine what has been installed and upgrade only those sets.
We actually know what file belongs to which set.
see /usr/lib/locate/src.db
Re: How can I remove sets installed by sysupgrade?
On Tue, Sep 17, 2019 at 09:39:00AM +0100, cho...@jtan.com wrote:
| Marc Espie writes:
| > On Tue, Sep 17, 2019 at 09:01:47AM +0100, cho...@jtan.com wrote:
| > > Marc Espie writes:
| > > > I'm a bit surprised nobody looked at instrumenting what sets are
actually
| > > > installed on a machine during install/manual upgrade and cloning that
| > > > into sysupgrade to avoid this kind of surprise...
| > >
| > > I mentioned the possibility wrt. syspatch but it was rejected in favour
| > > of expecting users to run a default system or, in effect, become
| > > developers. Not a stance I entirely agree with but which nevertheless
| > > has its merits.
| >
| > But sysupgrade is a much "simpler" mechanism than syspatch.
| >
| > More importantly,
| > - sysupgrade is definitely about the sets
| > - if you have a non default installation, syspatch happens *at user level*
| > so you have every opportunity to figure out what's going on.
| > Where sysupgrade ? reboot the machine, see your disks overflow. Boom machine
| > kaput.
|
| The problem boils down to: how does sysupgrade, or any other tool, know
| which sets have been installed?
By having each set install a specific file in a well-known location.
Before sysupgrade I wrote my own script to upgrade machines, this uses
/var/db/sets/{base,comp,game,man,xbase,xfont,xserve,xshare} to
determine what has been installed and upgrade only those sets.
However, the argument that not installing all sets gives you a 'non
standard' system suggests that this approach isn't viable.
Cheers,
Paul 'WEiRD' de Weerd
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: How can I remove sets installed by sysupgrade?
On Tue, Sep 17, 2019 at 09:43:20AM +0200, Marc Espie wrote: > I'm a bit surprised nobody looked at instrumenting what sets are actually > installed on a machine during install/manual upgrade and cloning that > into sysupgrade to avoid this kind of surprise... > Yeah, I think sysupgrade was a mistake. Too many people want different things from it while at the same time the upgrade mechanism in bsd.rd is perfectly stream lined and has all the options people need. -- I'm not entirely sure you are real.
Re: How can I remove sets installed by sysupgrade?
Marc Espie writes: > On Tue, Sep 17, 2019 at 09:01:47AM +0100, cho...@jtan.com wrote: > > Marc Espie writes: > > > I'm a bit surprised nobody looked at instrumenting what sets are actually > > > installed on a machine during install/manual upgrade and cloning that > > > into sysupgrade to avoid this kind of surprise... > > > > I mentioned the possibility wrt. syspatch but it was rejected in favour > > of expecting users to run a default system or, in effect, become > > developers. Not a stance I entirely agree with but which nevertheless > > has its merits. > > But sysupgrade is a much "simpler" mechanism than syspatch. > > More importantly, > - sysupgrade is definitely about the sets > - if you have a non default installation, syspatch happens *at user level* > so you have every opportunity to figure out what's going on. > Where sysupgrade ? reboot the machine, see your disks overflow. Boom machine > kaput. The problem boils down to: how does sysupgrade, or any other tool, know which sets have been installed? That information is not tracked anywhere to the best of my knowledge. sysupgrade would have to determine which sets are installed either by heuristics, making its code much more complicated, or by being informed by the user, recursing back to the initial problem - perform maintainence who's actions differ depending on which sets are installed without the user being required to keep track of that set of sets. Or by abandoning an installation process as simple as 2½ steps. Don't get me wrong, I'd love it if those tools tracked sets such that they could be treated a little more like The Other Side handles the entire operating system as a set of packages, but it's not as simple a problem to solve as it initially appears, as if it ever is, which is why I didn't push the issue. Just see the plethora of package managers that exist. Matthew
Re: How can I remove sets installed by sysupgrade?
On Tue, Sep 17, 2019 at 09:01:47AM +0100, cho...@jtan.com wrote: > Marc Espie writes: > > I'm a bit surprised nobody looked at instrumenting what sets are actually > > installed on a machine during install/manual upgrade and cloning that > > into sysupgrade to avoid this kind of surprise... > > I mentioned the possibility wrt. syspatch but it was rejected in favour > of expecting users to run a default system or, in effect, become > developers. Not a stance I entirely agree with but which nevertheless > has its merits. But sysupgrade is a much "simpler" mechanism than syspatch. More importantly, - sysupgrade is definitely about the sets - if you have a non default installation, syspatch happens *at user level* so you have every opportunity to figure out what's going on. Where sysupgrade ? reboot the machine, see your disks overflow. Boom machine kaput.
Re: How can I remove sets installed by sysupgrade?
In particular, installing OpenBSD requires the following steps: 1) Partition and format the disc. 2) Untar a bunch of stuff (or in the case of /bsd*, copy). 3) Install the bootloader. That's _it_. The few other tasks performed by the installer, like installing /etc/hostname.*, KARL and configuring /etc/rc.conf.local, users, etc., are not at all necessary for a functioning *and future-proof*[*] system and can be entirely wrapped up in siteXX.tgz or install.sub's autoinstall.conf file. It would be nice to put more intelligence into the system maintainence tools to encapsulate some of the methods available for adapting that simple process, but a process as simple as that for performing a task as complex installing an entire operating system should not be given up lightly. Matthew [*] Useful is in the eye of the beholder.
Re: How can I remove sets installed by sysupgrade?
Marc Espie writes: > I'm a bit surprised nobody looked at instrumenting what sets are actually > installed on a machine during install/manual upgrade and cloning that > into sysupgrade to avoid this kind of surprise... I mentioned the possibility wrt. syspatch but it was rejected in favour of expecting users to run a default system or, in effect, become developers. Not a stance I entirely agree with but which nevertheless has its merits. Matthew
Re: How can I remove sets installed by sysupgrade?
On Sun, Sep 15, 2019 at 08:02:05AM +0200, Marcus MERIGHI wrote: > Morning Judah! > > koche...@hotmail.com (Judah Kocher), 2019.09.15 (Sun) 05:12 (CEST): > > I ran it and found too late that it installed all the x*, Comp and Game > > sets, which were not part of the original install. Unfortunately this > > overfilled my /usr partition and I'm getting errors on boot. > > > > Is there a simple way to uninstall these sets? I need the space but > > would much rather not start over from scratch. > > please do *not* copy/paste/run this command! > something along these lines for the sets you did not want: > > $ ftp -MVo- $( tzf - | xargs rm > > you are aware that it is recommended to run with all sets? Well, games and xserv are definitely not needed in some cases at least. And we moved stuff to base in the past to avoid depending on comp. There are some quaint machines with little space to spare and where extra disk space is actually expensive/impossible to obtain. I'm a bit surprised nobody looked at instrumenting what sets are actually installed on a machine during install/manual upgrade and cloning that into sysupgrade to avoid this kind of surprise...
Re: How can I remove sets installed by sysupgrade?
> > My reasoning behind NOT installing the X, Comp and Game sets have > little > to do with saving space, although I am using an 8GB SSD. I learned in my > research that one of the most fundamental ways to improve network/system > security is to minimize the attack surface by not installing unneeded > software. If it isn't installed, any potential vulnerabilities, known or > not, are irrelevant. > What is not irrelevant is the person/program that somehow has a shell on your box can paste the required 500 bytes of hex data into "openssl base64 -d" to get a binary on your system, so removing the Comp set is one of those "it would be super hard for me to imagine what I need to run a local privilege escalation so it must require all these tools" whereas the hackers that do own other boxes will already have the short_ASM_sequence* tested locally and only need to get those over the same path the exploit took in order to get a better foothold on your machine. So removing comp sets just mean you can't patch locally when a scary advisory comes out, it also means you need to special-case your sysupgrades and those two choices will probably mean you will stay vulnerable for a longer time just because you hoped leaving cc(1),as(1) and battlestar(6) out of the box will "save" you. Yes, I can imagine some few scenarios where it might, but as the other reply you already got says, when you make your own box a surprise to administer and reason about, you are making it worse already so the comparisons about what choice is safer doesn't even start from the same level. *) SEE ALSO: https://en.wikipedia.org/wiki/SQL_Slammer -- May the most significant bit of your life be positive.
Re: How can I remove sets installed by sysupgrade?
Judah Kocher writes: > My router is headless. I have never run into an issue where I have > needed anything from the X sets Apparently you just did. > Therefore it seems like sound logic to not have those > bits and bytes present on the system so any > mis-configurations/bugs/vulnerabilities cannot impact my network security. This idea stems from sound advice but you are neglecting the parable of Chesterton's Fence[1]. > My router is not unbootable but I am not sure how secure it is anymore This says it all really. You should be, in spite of your present setback. You should not have set up your system in a way that permits you to be put in a position of not knowing how secure it is. Go back to first principles and redesign. > All of my partitions have at least 75% free space, except /usr which > after the sysupgrade is listed by df as being filled to 104% capacity. > I'm not even sure how that's possible. Because filesystems. They're documented. > I don't particularly look forward to having to rebuild it > from scratch or how long it will be before I find the time to do so. Good thing you have backups then, eh? > That being said, I realize there is plenty I do not know, First thing: A backup that cannot be [proven to be] restored is not a backup. > I experiment with making changes on a VM and observing the results until > I feel like I have a solid grasp on what will occur before pushing > anything to my live system, which sometimes takes months due to life, Good practice. > reading the sysupgrade manpage there is nothing > which even hints that any software which was explicitly rejected during > the original install will be installed anyway by this tool. *grumble* It seems that the OpenBSD devs and/or project "support" only an installation which has not not taken advantage of any of the optional non-extras (primarily: not installing sets) the installer has to offer. I understand and agree with the reasons for this but I grumble somewhat about the way it's presented. Passively-aggressive only because I have no solution on hand to fix problems I can't quite even describe. If your system is not a match then on your own head be it. It's a big, complicated thing but it's not that hard to understand. I suggest reading the sources to the boot loader, installer and the kernel's main startup routine to get a solid handle on things before progressing onto what /etc/rc and pals are doing and the layout of the filesystem etc.. > It looks like my best chance to be certain I have the router in the > state I think I do will be to do a fresh install and then use sysupgrade > using a variation of the script Leo mentioned in his email on 7/9/19: Or just store some bits in a place where they can't possibly be used so that you don't have to waste any of your limited effort on something that has no impact on anything? Your emphasis on security is admirable but misguided. Matthew [1] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
Re: How can I remove sets installed by sysupgrade?
Thanks for the replies and ideas. I was introduced to OpenBSD after an acquaintance had their home router compromised in 2016 and I started looking into network hardening/security. In my research trying to find the best firewall that didn't require purchasing commercial hardware/licensing I found PF and OpenBSD so I started learning. My reasoning behind NOT installing the X, Comp and Game sets have little to do with saving space, although I am using an 8GB SSD. I learned in my research that one of the most fundamental ways to improve network/system security is to minimize the attack surface by not installing unneeded software. If it isn't installed, any potential vulnerabilities, known or not, are irrelevant. My router is headless. I have never run into an issue where I have needed anything from the X sets, and don't compile anything from source so I don't need that, and I certainly don't play games on it so I don't need that either. Therefore it seems like sound logic to not have those bits and bytes present on the system so any mis-configurations/bugs/vulnerabilities cannot impact my network security. I am running a couple of OpenVPN servers which some friends and family rely on, using DNSCrypt-Proxy, experimenting with Wireguard, playing around with certificates and authentication, and since I use a variety of automation/embedded devices which have dubious or no security of their own I rely on my firewall to prevent them from "phoning home" if they come or become compromised. I've slowly built my pf.conf, tables and anchors to a point I'm pretty happy with. I also have experimented with running OpenBSD with a read-only filesystem as just another layer of defense and annoyance for any potential invader although I'm not currently doing so. I'm sure with my limited although always expanding knowledge that there are still many ways my network could be compromised but I'm doing my best to at least plug the easily filled holes and adding any unused stuff feels like a step backwards. My router is not unbootable but I am not sure how secure it is anymore because on boot I get several failures related to being "Out of space" and also the kernel relink fails, which I understand is a significant part of what makes OpenBSD more secure. All of my partitions have at least 75% free space, except /usr which after the sysupgrade is listed by df as being filled to 104% capacity. I'm not even sure how that's possible. This is just a personal system and if I screw it up no one is harmed except me and my users, and anyone else who might be attacked by my compromised system I guess, but it took me a long time to get it set up this way and I don't particularly look forward to having to rebuild it from scratch or how long it will be before I find the time to do so. That being said, I realize there is plenty I do not know, and as a rule I experiment with making changes on a VM and observing the results until I feel like I have a solid grasp on what will occur before pushing anything to my live system, which sometimes takes months due to life, work and family, but reading the sysupgrade manpage there is nothing which even hints that any software which was explicitly rejected during the original install will be installed anyway by this tool. In the interest of protecting others from the same mistake I hope that a simple sentence explaining that it also installs any previously rejected sets could be added there. It looks like my best chance to be certain I have the router in the state I think I do will be to do a fresh install and then use sysupgrade using a variation of the script Leo mentioned in his email on 7/9/19: #!/bin/sh sysupgrade -n rm /home/_sysupgrade/x* rm /home/_sysupgrade/game* reboot Thanks again, Judah > Marcus MERIGHI writes: >> please do *not* copy/paste/run this command! >> something along these lines for the sets you did not want: >> >> $ ftp -MVo- $(> tzf - | xargs rm >> >> you are aware that it is recommended to run with all sets? > Despite previous posts requesting assistance with not doing so, I second > this recommendation to anyone not able to construct that ftp/tar/rm > command from first principles (and with a clear need to do so). > > Patronisation aside, your computer's storage is a lot cheaper than the > mental effort required to deal with a system that's non-standard but > only by having a few bits wasted by their _complete lack of use_. > > FilesystemUsedMounted on > > The system proper is tiny: > > /dev/sd0a 148M/ > /dev/sd0e 860M/usr > /dev/sd0h 203M/usr/X11R6 > /dev/sd0g70.9M/var > > The user/development environment is little bigger: > > /dev/sd0i 4.7G/usr/local > /dev/sd0m 1.1G/usr/obj > /dev/sd0l 685M/usr/ports > /dev/sd0j 1.0G/usr/src > /dev/sd0k 688M/usr/xenocara > /dev/sd0n 2.0K
Re: How can I remove sets installed by sysupgrade?
On 2019-09-15, Judah Kocher wrote:
> Thanks to the OpenBSD team for their awesome software!
>
> I have been running an Openbsd router for a few years now, mostly
> following current. Today I decided to try out sysupgrade rather than
> going through the usual manual process. I've read up on it a few times
> and it seemed pretty straightforward.
>
> I ran it and found too late that it installed all the x*, Comp and Game
> sets, which were not part of the original install. Unfortunately this
> overfilled my /usr partition and I'm getting errors on boot.
>
> Is there a simple way to uninstall these sets? I need the space but
> would much rather not start over from scratch.
>
> I did find an email (too late) on this list about how there is no way to
> tell sysupgrade to just upgrade an existing system without adding
> everything else too. As a grateful user of free software I would also
> like to ask, is that an option that might find its way into the system
> sometime?
While you can do that (see other replies), if it's not too painful
and you have say 8GB or more storage capacity I would advise saving
config and reinstalling -current allowing more space for /usr.
On some storage devices (notably the common 16GB SSD that
is often used with pc engines APUs) the old disklabel auto default
sizes were a bit too small to handle upgrades comfortably, this has been
revised in -current in the last month or so and the new defaults will
now give a little breathing space.
If you are currently faced with a non-booting system I would
suggest booting bsd.rd, choose to upgrade, ^Z, rm -r the following:
/mnt/usr/{bin,sbin,lib*,share}
/mnt/usr/X11R6/*
then "fg" and start the upgrade with whatever sets you need.
Re: How can I remove sets installed by sysupgrade?
Marcus MERIGHI writes: > please do *not* copy/paste/run this command! > something along these lines for the sets you did not want: > > $ ftp -MVo- $( tzf - | xargs rm > > you are aware that it is recommended to run with all sets? Despite previous posts requesting assistance with not doing so, I second this recommendation to anyone not able to construct that ftp/tar/rm command from first principles (and with a clear need to do so). Patronisation aside, your computer's storage is a lot cheaper than the mental effort required to deal with a system that's non-standard but only by having a few bits wasted by their _complete lack of use_. FilesystemUsedMounted on The system proper is tiny: /dev/sd0a 148M/ /dev/sd0e 860M/usr /dev/sd0h 203M/usr/X11R6 /dev/sd0g70.9M/var The user/development environment is little bigger: /dev/sd0i 4.7G/usr/local /dev/sd0m 1.1G/usr/obj /dev/sd0l 685M/usr/ports /dev/sd0j 1.0G/usr/src /dev/sd0k 688M/usr/xenocara /dev/sd0n 2.0K/usr/xobj Putting part-built binaries and /usr/local aside, that's only 1.2GB. 4.7GB is large for /usr/local but that's because this is my "throw everything at it" system. Even with this fully-packed system and the full source code the total is just a shade over 8GB. Despite space earmarked for growth it's difficult to stretch the base system to 16GB. I don't know about anyone else but I can't even find storage media that small any more. I'm all for minimising waste but effort where it's due. But see also https://twitter.com/rob_pike/status/966896123548872705 Matthew ps. FWIW where my systems were concerned I was looking at minimising waste through repetition of many VMs but there are other, in ways better, methods of doing that. Any which involve me thinking about it have a priori failed. pps. Reinstalling is not actually that big a deal. Partition, install boot sector, extract sets, install packages and finally site-specific files to /etc, /home, /var and possibly /srv or something. The installer can be easily configured to do all of this without human interaction prior to the first live boot.
Re: How can I remove sets installed by sysupgrade?
Morning Judah! koche...@hotmail.com (Judah Kocher), 2019.09.15 (Sun) 05:12 (CEST): > I ran it and found too late that it installed all the x*, Comp and Game > sets, which were not part of the original install. Unfortunately this > overfilled my /usr partition and I'm getting errors on boot. > > Is there a simple way to uninstall these sets? I need the space but > would much rather not start over from scratch. please do *not* copy/paste/run this command! something along these lines for the sets you did not want: $ ftp -MVo- $( I did find an email (too late) on this list about how there is no way to > tell sysupgrade to just upgrade an existing system without adding > everything else too. do you mean "sysupgrade -n; rm /home/_sysupgrade/xserv66.tgz; reboot"? Marcus
How can I remove sets installed by sysupgrade?
Thanks to the OpenBSD team for their awesome software! I have been running an Openbsd router for a few years now, mostly following current. Today I decided to try out sysupgrade rather than going through the usual manual process. I've read up on it a few times and it seemed pretty straightforward. I ran it and found too late that it installed all the x*, Comp and Game sets, which were not part of the original install. Unfortunately this overfilled my /usr partition and I'm getting errors on boot. Is there a simple way to uninstall these sets? I need the space but would much rather not start over from scratch. I did find an email (too late) on this list about how there is no way to tell sysupgrade to just upgrade an existing system without adding everything else too. As a grateful user of free software I would also like to ask, is that an option that might find its way into the system sometime? Thanks, Judah
