Re: Reinstall to upgrade
On November 26, 2020 10:23:33 AM GMT+01:00, Stuart Henderson wrote: >On 2020/11/25 23:56, Alexander Hall wrote: >> >> >> On November 25, 2020 11:09:02 PM GMT+01:00, Stuart Henderson > wrote: >> >On 2020-11-25, Manuel Giraud wrote: >> >> I have one (somewhat) related question left: is possible to >capture >> >the >> >> output of pkg_delete -an in a file? I tried the following (without >> >> luck): >> >>$ pkg_delete -an > /tmp/foo >> > >> >Here you redirect stdout from the process to /tmp/foo >> > >> >>$ pkg_delete -an > /tmp/foo 2>&1 >> > >> >And here you redirect stdout from the process to /tmp/foo, and then >> >stderr to stdout. >> > >> >What you need is: >> > >> > $ pkg_delete -an 2>&1 > /tmp/foo >> > >> >- redirect stderr to stdout, then redirect stdout (which now >includes >> >stderr) to /tmp/foo. >> >> I think you're wrong. I hope I'm not. > >Ah yes, you are right, I had it exactly the wrong way round. There's no doubt in my mind you do know these things. :-) What you described would apply if there was a pipe in between though, so that could be how you fooled yourself; $ pkg_delete -an 2>&1 | cat > /tmp/foo /Alexander
Re: Security & Compliance - A/V
On Nov 26 11:35, Nick Holland wrote: > I have a similar situation at $DAYJOB. Not OpenBSD, but an OS that > similarly has little malware written for it (and an environment with > lots of softer targets than the OS anyway). For LOTS of reasons, we > didn't want to put AV on the "important" systems, but we needed to > hit that checkbox that says, "AV scans!" > > Our compliance people work with me pretty well, and what we came up > was to run the AV against our BACKUPS of those boxes. We rsync > the data from the systems to a central backup, and we run the AV on > that box against the data. Increased the backup by a few GB/box and > grabbed the binaries, too, and ta-da, we got a pretty good AV scan > taking place with /zero/ additional impact on the systems. This is a great idea. For realtime, we can protect critical content with something like mtree(8) output verified with signify(1), running in security(8) daily.
Re: Security & Compliance - A/V
On 2020-11-25 17:10, Brogan Beard wrote: > In the enterprise context, there are often extensive security compliance > rules, which include but are not limited to anti-virus software > requirements. There are, of course, exceptions to these rules but generally > policies drive the technology in use or allow it to be used. I am not aware > of any anti-virus software that supports openbsd or any bsd for that matter > (not saying it needs it ;) ). > > How does OpenBSD handle the compliance aspects of security in regards to > A/V? Is there an, "it's already under the hood," response based on modern > security standards? > > I would like to use OpenBSD in future projects, beyond just personal > interest. And with that, I am sure these types of questions will arise. > > Thanks in advance for thoughtful comments! Something to consider: run the AV against your boxes -- elsewhere! I have a similar situation at $DAYJOB. Not OpenBSD, but an OS that similarly has little malware written for it (and an environment with lots of softer targets than the OS anyway). For LOTS of reasons, we didn't want to put AV on the "important" systems, but we needed to hit that checkbox that says, "AV scans!" Our compliance people work with me pretty well, and what we came up was to run the AV against our BACKUPS of those boxes. We rsync the data from the systems to a central backup, and we run the AV on that box against the data. Increased the backup by a few GB/box and grabbed the binaries, too, and ta-da, we got a pretty good AV scan taking place with /zero/ additional impact on the systems. Yes, perhaps not as "real time" as a system which hooks into the OS and watches every disk read and write, but I don't think you even want that on a Unix-like OS (even if it was possible on many Unix- like OSs). Nick.
Re: Reinstall to upgrade
On 2020/11/25 23:56, Alexander Hall wrote: > > > On November 25, 2020 11:09:02 PM GMT+01:00, Stuart Henderson > wrote: > >On 2020-11-25, Manuel Giraud wrote: > >> I have one (somewhat) related question left: is possible to capture > >the > >> output of pkg_delete -an in a file? I tried the following (without > >> luck): > >>$ pkg_delete -an > /tmp/foo > > > >Here you redirect stdout from the process to /tmp/foo > > > >>$ pkg_delete -an > /tmp/foo 2>&1 > > > >And here you redirect stdout from the process to /tmp/foo, and then > >stderr to stdout. > > > >What you need is: > > > > $ pkg_delete -an 2>&1 > /tmp/foo > > > >- redirect stderr to stdout, then redirect stdout (which now includes > >stderr) to /tmp/foo. > > I think you're wrong. I hope I'm not. Ah yes, you are right, I had it exactly the wrong way round. > Is it rather possibly so that pkg_delete handles output to a TTY different > than to a non-TTY? yep.
Re: Reinstall to upgrade
Stuart Henderson writes: [...] > What you need is: > > $ pkg_delete -an 2>&1 > /tmp/foo > > - redirect stderr to stdout, then redirect stdout (which now includes > stderr) to /tmp/foo. This does not really work. There is some information left but not the list of unused dependencies. This list seems to be part of the progress bar. With script, as proposed by Navan, the output is mangled with * and escape sequence. And if you use -x, you do not get the list either. -- Manuel Giraud
