Re: syspatch question
After reading this thread I wondered why haven't I gotten an update in a while. So I checked and syspatch -c show no output but found it had a 1 return code. It turns out my URL in /etc/installurl was no longer a valid mirror for some reason (didn't investigate, just fixed). I suppose it's a good idea to check the return code rather than misinterpreting/misunderstanding an empty output. On Wed, Aug 9, 2017 at 11:04 AM, Marko Cupać wrote: > On Tue, 8 Aug 2017 18:17:35 -0400 > Taylor Stearns wrote: > > > On Tue, Aug 08, 2017 at 01:10:22PM -0400, tec...@protonmail.com wrote: > > > I had this exact issue a few days ago, I just re-partitioned to a > > > bigger size so not have to face the issue again as was a new install > > > anyway. But, sure would be nice to see this added. Thanks > > > > > > > From: marko.cu...@mimar.rs > > > > - at the moment of writing this, there are 025 patches. If > > > > applying them all at once, they (perhaps needlessly) need quite > > > > some space in /tmp (my mfs for /tmp is 256m, and it got filled > > > > already at 012), as a result of (I guess) > > > > deleting /tmp/syspatch.XX only after all the patches are > > > > applied, or after /tmp gets filled up. Perhaps it is possible to > > > > flush /tmp earlier in the process (maybe after each patch is > > > > applied successfully)? > > > > Have you tried with -current? Here is a change from June that might be > > what you're looking for: > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ > syspatch/syspatch.sh#rev1.108 > > That's it, thank you. Also rev1.108 appears to work on 6.1-release > without problems - I've just overwritten rev1.93 included in > 6.1-release. > -- > Before enlightenment - chop wood, draw water. > After enlightenment - chop wood, draw water. > > Marko Cupać > https://www.mimar.rs/ > >
Re: syspatch question
On Tue, 8 Aug 2017 18:17:35 -0400 Taylor Stearns wrote: > On Tue, Aug 08, 2017 at 01:10:22PM -0400, tec...@protonmail.com wrote: > > I had this exact issue a few days ago, I just re-partitioned to a > > bigger size so not have to face the issue again as was a new install > > anyway. But, sure would be nice to see this added. Thanks > > > > > From: marko.cu...@mimar.rs > > > - at the moment of writing this, there are 025 patches. If > > > applying them all at once, they (perhaps needlessly) need quite > > > some space in /tmp (my mfs for /tmp is 256m, and it got filled > > > already at 012), as a result of (I guess) > > > deleting /tmp/syspatch.XX only after all the patches are > > > applied, or after /tmp gets filled up. Perhaps it is possible to > > > flush /tmp earlier in the process (maybe after each patch is > > > applied successfully)? > > Have you tried with -current? Here is a change from June that might be > what you're looking for: > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/syspatch/syspatch.sh#rev1.108 That's it, thank you. Also rev1.108 appears to work on 6.1-release without problems - I've just overwritten rev1.93 included in 6.1-release. -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: syspatch question
On Tue, Aug 08, 2017 at 01:10:22PM -0400, tec...@protonmail.com wrote: > I had this exact issue a few days ago, I just re-partitioned to a > bigger size so not have to face the issue again as was a new install > anyway. But, sure would be nice to see this added. Thanks > > > From: marko.cu...@mimar.rs > > - at the moment of writing this, there are 025 patches. If applying > > them all at once, they (perhaps needlessly) need quite some space > > in /tmp (my mfs for /tmp is 256m, and it got filled already at 012), > > as a result of (I guess) deleting /tmp/syspatch.XX only > > after all the patches are applied, or after /tmp gets filled up. > > Perhaps it is possible to flush /tmp earlier in the process (maybe > > after each patch is applied successfully)? Have you tried with -current? Here is a change from June that might be what you're looking for: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/syspatch/syspatch.sh#rev1.108
Re: syspatch question
I had this exact issue a few days ago, I just re-partitioned to a bigger size so not have to face the issue again as was a new install anyway. But, sure would be nice to see this added. Thanks > Original Message > Subject: Re: syspatch question > Local Time: August 8, 2017 4:20 PM > UTC Time: August 8, 2017 3:20 PM > From: marko.cu...@mimar.rs > To: Antoine Jacoutot > misc@openbsd.org, Igor Falcomata' > On Tue, 08 Aug 2017 13:14:43 +0200 > Antoine Jacoutot wrote: >> I"ll have a look at it thanks. > I"m aware that noone is going to optimize syspatch for my corner case, > but here are a few observations regarding my experience with it: > - at the moment of writing this, there are 025 patches. If applying > them all at once, they (perhaps needlessly) need quite some space > in /tmp (my mfs for /tmp is 256m, and it got filled already at 012), > as a result of (I guess) deleting /tmp/syspatch.XX only > after all the patches are applied, or after /tmp gets filled up. > Perhaps it is possible to flush /tmp earlier in the process (maybe > after each patch is applied successfully)? > - syspatch silently fails if it cannot contact installurl server. > Perhaps some warning could be added? > Best regards, > -- > Before enlightenment - chop wood, draw water. > After enlightenment - chop wood, draw water. > Marko Cupać > https://www.mimar.rs/
Re: syspatch question
On Tue, 08 Aug 2017 13:14:43 +0200 Antoine Jacoutot wrote: > I'll have a look at it thanks. I'm aware that noone is going to optimize syspatch for my corner case, but here are a few observations regarding my experience with it: - at the moment of writing this, there are 025 patches. If applying them all at once, they (perhaps needlessly) need quite some space in /tmp (my mfs for /tmp is 256m, and it got filled already at 012), as a result of (I guess) deleting /tmp/syspatch.XX only after all the patches are applied, or after /tmp gets filled up. Perhaps it is possible to flush /tmp earlier in the process (maybe after each patch is applied successfully)? - syspatch silently fails if it cannot contact installurl server. Perhaps some warning could be added? Best regards, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: syspatch question
On August 8, 2017 12:28:46 PM GMT+02:00, Igor Falcomata' wrote: >On Thu, Aug 31, 2017 at 13:56:13, Marko Cupa?? wrote: > >>...but the problem I am facing is that syspatch -l shows installed >>patches up to 013: > >I got the same problem; after a quick investigation i found that >syspatch will >silently fail if TMPDIR is defined and isn't /tmp (i suspect is related >to the >ftp part, because it quits just after the CWD, but i haven't >investigated more >deeply): > >CWD pub/OpenBSD/syspatch/6.1/amd64 >250 CWD command successful >QUIT > >This way should work: ># TMPDIR=/tmp syspatch -c > >ciao, >I. I'll have a look at it thanks. -- Antoine
Re: syspatch question
On Thu, Aug 31, 2017 at 13:56:13, Marko Cupa?? wrote: >...but the problem I am facing is that syspatch -l shows installed >patches up to 013: I got the same problem; after a quick investigation i found that syspatch will silently fail if TMPDIR is defined and isn't /tmp (i suspect is related to the ftp part, because it quits just after the CWD, but i haven't investigated more deeply): CWD pub/OpenBSD/syspatch/6.1/amd64 250 CWD command successful QUIT This way should work: # TMPDIR=/tmp syspatch -c ciao, I.
Re: syspatch question
On 07/31/2017 03:56 PM, Marko Cupać wrote:
> Hi,
>
> first of all, thanx for syspatch. One-liner to apply all the errata
> patches instead of syncing source and rebuilding stuff are welcomed on
> my fleet of geographically remote OpenBSD firewalls running on PC
> Engines' apu2d4, not only because of its speed and simplicity, but also
> because of SDcard tear&wear minimisation.
>
> Now, I know I'm in unsupported waters because I noticed this on a box
> with only / mounted read-only, and /dev /var and /tmp as writable mfs
> file systems described (warning! blatant self-promotion below!) here:
> [https://www.mimar.rs/blog/how-to-increase-openbsds-resilience-to-power-outages]
>
> ...but the problem I am facing is that syspatch -l shows installed
> patches up to 013:
>
> pacija@zemun:~ $ doas syspatch -l
> 001_dhcpd
> 002_vmmfpu
> 003_libressl
> 004_softraid_concat
> 005_pf_src_tracking
> 006_libssl
> 007_freetype
> 008_exec_subr
> 009_icmp_opts
> 010_perl
> 012_wsmux
> 013_icmp6_linklocal
>
> ...whereas syspatch -c returns zero, while I guess it should return
> 014_libcrypto at the time of writing this. Another identical box which
> was patched up to 012 shows correct information (-l up to 012, -c 013
> and 014).
>
> I'm not whining or anything, I trust my OpenBSD firewalls to be more
> secure than any other solution out there even without these patches.
> But maybe someone with more knowledge of syspatch finds this behaviour
> worth investigating, even on unsupported setup.
>
> Finally, my question: How does syspatch check current patchlevel? By
> checking contents of /var/syspatch or some other way? I guess I'm
> showing my ignorance here :)
>
> Best regards,
>
If you file(1) /usr/sbin/syspatch, you'll see it's just a shell script;
that should probably help you understand what's going on, though it's
fairly terse shell script. I'll be tracing the execution of -c.
$ file /usr/sbin/syspatch
/usr/sbin/syspatch: Korn shell script text executable
syspatch -c contacts the mirrors in /etc/installurl at
${_MIRROR}/syspatch/${_KERNV[0]}/$(machine), for example:
https://ftp.fau.de/pub/OpenBSD/syspatch/6.1/amd64/ -- $_MIRROR is
https://ftp.fau.de/pub/OpenBSD, $_KERNV[0] is 6.1 (obtained from sysctl
-n kern.version), machine(1) returned amd64 and downloads SHA256 and
SHA256.sig. Then it verifies SHA256 against SHA256.sig.
It then parses the filenames in the SHA256 file in a format that's
compatible with syspatch -l and checks that list against the list
returned by syspatch -l.
syspatch -l checks /var/syspatch and lists directories those that have a
rollback.tgz inside them. It then sorts them using sort -V.
I'm not 100% sure on the details since I'm not the most experienced
shell scripter in the world, but this ought to be accurate enough for
debugging. If I'm wrong, I hope someone will come along and me.
My guess is that the mirror in /etc/installurl is either down or points
at a local file or something along those lines.
syspatch question
Hi, first of all, thanx for syspatch. One-liner to apply all the errata patches instead of syncing source and rebuilding stuff are welcomed on my fleet of geographically remote OpenBSD firewalls running on PC Engines' apu2d4, not only because of its speed and simplicity, but also because of SDcard tear&wear minimisation. Now, I know I'm in unsupported waters because I noticed this on a box with only / mounted read-only, and /dev /var and /tmp as writable mfs file systems described (warning! blatant self-promotion below!) here: [https://www.mimar.rs/blog/how-to-increase-openbsds-resilience-to-power-outages] ...but the problem I am facing is that syspatch -l shows installed patches up to 013: pacija@zemun:~ $ doas syspatch -l 001_dhcpd 002_vmmfpu 003_libressl 004_softraid_concat 005_pf_src_tracking 006_libssl 007_freetype 008_exec_subr 009_icmp_opts 010_perl 012_wsmux 013_icmp6_linklocal ...whereas syspatch -c returns zero, while I guess it should return 014_libcrypto at the time of writing this. Another identical box which was patched up to 012 shows correct information (-l up to 012, -c 013 and 014). I'm not whining or anything, I trust my OpenBSD firewalls to be more secure than any other solution out there even without these patches. But maybe someone with more knowledge of syspatch finds this behaviour worth investigating, even on unsupported setup. Finally, my question: How does syspatch check current patchlevel? By checking contents of /var/syspatch or some other way? I guess I'm showing my ignorance here :) Best regards, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
