Re: rdist remove option and default behaviour
Hmm. OK... perhaps I was not clear enough. I was not really reporting an issue (did not think it was an issue yet) more like I wanted to see if my understanding was correct. I thought we could specify "destination" folder to be different from the one used in the source (hence dest_opt_name), but I can see it is there for a different reason. Yes rsync is there, but I thought rdist is still being used. openbsd.amsterdam is using it and some other folks. Anyhow, I guess I now confirmed rdist behaviour, so all is well, thank you. On Wednesday, December 14, 2022 at 03:08:33 p.m. GMT+9, Philip Guenther wrote: On Mon, Dec 12, 2022 at 9:02 PM All wrote: > I wanted to clarify. > > In manpage for rdist I see that we can use option -o remove . > remove Remove extraneous files. If a directory is being > updated, any files that exist on the remote host that > do > not exist in the master directory are removed. This > is > useful for maintaining truly identical copies of > directories. > However, this seems to be the default anyway. > > If I specify "install /tmp/" and try to copy /tmp/test.file all the files > in /tmp/ > on the remote host will be wiped out and only test.file will remain there > after copy. > This behaviour seems to fit with "directory update" feature of "remove" > (like > if we do "install -o remove /tmp/"). Yet, "remove" was not specified above. > > Is my understanding of default behaviour correct? This how it supposed to > be working? > When reporting an issue, please include precise information about both * what your desired end result / goal was, and * what you tried, including how you invoked the command and/or the config used. If you leave out the former, then we'll be guessing as to why the result wasn't what you wanted. If you leave out the latter, then we'll be guessing as to what you did that didn't work as desired. ...or be prepared to be accepting of people guessing wrong. ALSO: rdist has been largely superseded by rsync, which has a much more efficient underlying protocol and, in my experience, a more regular set of behaviors. Before committing to rdist and its (limited by history) behavior, you should consider using rsync instead. It seems you * wanted to copy /tmp/test.file to /tmp/test.file on one or more other hosts? * you tried a distfile like this: whatever: ( /tmp/test.file ) -> HOSTNAME install /tmp/; ? You're correct that the latter does not achieve the former. To achieve the former, you would need to either * leave off the opt_dest_name from the 'install' directive, so that rdist would know to install the source to the exact same path on the target host * specify the full target path in the 'install' directive, ala "install /tmp/test.file" * have multiple source files, so that it treated opt_dest_name as a target directory and not a target path (like cp) So, what happened with what you _did_ try? Well, it was taken as a request install the contents of the file "/tmp/test.file" as a file "/tmp/"! rdist is smart enough to know that it can't remove a directory without first removing its contents, so it tried that and presumably failed. If it _could_ remove the contents it would then remove the directory...and then fail when it tried to create a tempfile with prefix "/tmp/". Could rdist's behavior be improved? In some ways, yes, but lots of sharp corners (e.g., single vs multiple source handling) would remain. Frankly, if rsync serves your purposes, you should use it instead. Philip Guenther
Re: rdist remove option and default behaviour
On Mon, Dec 12, 2022 at 9:02 PM All wrote: > I wanted to clarify. > > In manpage for rdist I see that we can use option -o remove . > remove Remove extraneous files. If a directory is being > updated, any files that exist on the remote host that > do > not exist in the master directory are removed. This > is > useful for maintaining truly identical copies of > directories. > However, this seems to be the default anyway. > > If I specify "install /tmp/" and try to copy /tmp/test.file all the files > in /tmp/ > on the remote host will be wiped out and only test.file will remain there > after copy. > This behaviour seems to fit with "directory update" feature of "remove" > (like > if we do "install -o remove /tmp/"). Yet, "remove" was not specified above. > > Is my understanding of default behaviour correct? This how it supposed to > be working? > When reporting an issue, please include precise information about both * what your desired end result / goal was, and * what you tried, including how you invoked the command and/or the config used. If you leave out the former, then we'll be guessing as to why the result wasn't what you wanted. If you leave out the latter, then we'll be guessing as to what you did that didn't work as desired. ...or be prepared to be accepting of people guessing wrong. ALSO: rdist has been largely superseded by rsync, which has a much more efficient underlying protocol and, in my experience, a more regular set of behaviors. Before committing to rdist and its (limited by history) behavior, you should consider using rsync instead. It seems you * wanted to copy /tmp/test.file to /tmp/test.file on one or more other hosts? * you tried a distfile like this: whatever: ( /tmp/test.file ) -> HOSTNAME install /tmp/; ? You're correct that the latter does not achieve the former. To achieve the former, you would need to either * leave off the opt_dest_name from the 'install' directive, so that rdist would know to install the source to the exact same path on the target host * specify the full target path in the 'install' directive, ala "install /tmp/test.file" * have multiple source files, so that it treated opt_dest_name as a target directory and not a target path (like cp) So, what happened with what you _did_ try? Well, it was taken as a request install the contents of the file "/tmp/test.file" as a file "/tmp/"! rdist is smart enough to know that it can't remove a directory without first removing its contents, so it tried that and presumably failed. If it _could_ remove the contents it would then remove the directory...and then fail when it tried to create a tempfile with prefix "/tmp/". Could rdist's behavior be improved? In some ways, yes, but lots of sharp corners (e.g., single vs multiple source handling) would remain. Frankly, if rsync serves your purposes, you should use it instead. Philip Guenther
Re: pf question - set skip on wildcards ?
Am 13.12.2022 22:11 schrieb J Doe: set skip on !$ext_if ... with the idea that this skips all interfaces (virtual or otherwise) _EXCEPT_ em0, which is the real Ethernet NIC that I want to perform filtering on ? Yes, but likely to need a space between ! and $. ciao -- pb
Re: pf question - set skip on wildcards ?
On 2022-12-13 01:23, Philipp Buehler wrote:
Am 13.12.2022 06:02 schrieb J Doe:
set skip on { lo0, vif* }
in pf.conf(5) the GRAMMAR shows:
ifspec = ( [ "!" ] ( interface-name | interface-group ) ) |
"{" interface-list "}"
So you could do "set skip on { lo0 vif0 vif1 }" for explicit, or you
use interface-group, alas "set skip on vif". If that "one" interface
is e.g. vif7 within vif(4) this MIGHT go: "set skip on { vif !vif7 }".
Hi Philipp,
Ok, so the "!" is a NOT operation ?
If that is the case, could I use:
ext_if = "em0"
set skip on !$ext_if
... with the idea that this skips all interfaces (virtual or otherwise)
_EXCEPT_ em0, which is the real Ethernet NIC that I want to perform
filtering on ?
Thanks,
- J
Re: sysupgrade fails with "FAILED" when "verifying sets"?
On 2022-12-12, Why 42? The lists account. wrote: > Today sysupgrade failed for me, but I'm not sure why? Here's the output: As the various mirrors get updated, this should be coming back to normal now.
Re: premature end of data for lang/go package (mips64)
On 2022-12-13, Janne Johansson wrote: > Den sön 11 dec. 2022 kl 17:42 skrev void : >> Alternatively, is it feasible to build an amd64 vm and cross-compile >> there, for mips64/octeon? > > I think it is. I think I have tried it for simpler stuff but unless I > am very mistaken you just set GOARCH and fire off the build, then move > the binary over. For go, generally yes, though you will have different binaries compared to a native build. In particular it links with libc differently; native build records a dependency on the libc version on the machine, go's crosscompiling just records it as "libc.so" (see objdump -p). There's no infrastructure for cross-compiling in the ports tree (and it's not particularly wanted in general) - you might be able to tweak individual ports to get usable binaries out of them with some languages and copy them out of the fake-install dir, but producing installable tgz packages will be trickier. -- Please keep replies on the mailing list.
