Re: Communication between hosts on different network interfaces
This is very much doable with DHCP one liner: add the following to your dhcpd.conf ((!) inside the block of your 192.168.2.0/24 network) option classless-static-routes 192.168.3.0/24 192.168.2.1; This will install static route into all machines in 192.168.2.0/24 network. When they will try to reach 192.168.3.0/24 machines they will send packets to 192.168.2.1 On Sunday, January 7, 2024 at 02:03:10 p.m. GMT+9, Nick Holland wrote: On 1/6/24 15:09, Ibsen S Ripsbusker wrote: > Dear colleagues, > > > > I have various network appliances that I don't really trust, like > a printer. I have these plugged into an unmanaged switch and > connected to network interface igc2. > > I want to allow the igc1 network to make web requests to the igc2 > network, and I want the igc2 network to have very restricted access > outside of igc2. what does a printer need internet access for? nevermind. Don't answer that. It's the 21st century. Many people think their bloomin' thermostats should have Internet access...(I'm really close to replacing my non-internet connected digital programmable thermostat with a 100% mechanical. Because...they don't suck) > (My main computer is connected to network interface igc1. > And the egress interface is igc0.) > > MY QUESTION: What would be a normal way of achieving this? let's abstract this a bit... (in large part because a sequence of letters and numbers confuses me quickly.) So you have a trusted network, an untrusted network, and of course, the Internet, which we will just call "The Evil". While you can do it with a bridge, I don't want to think that hard. And it would be a lot of work. [snip bridge stuff] > I also tried setting different subnets. yeah. that's the way I'd go. trusted: > /etc/hostname.igc1:> inet 192.168.2.1/24 untrusted: > /etc/hostname.igc2: > inet 192.168.3.1/24 > > With this everything works as I want except that > the only way I figured out to allow hosts on 192.168.2.1/24 > to access 192.168.3.1/24 was with NAT, and that can't be right. yeah, the problem is, it sounds like your barrier machine is not your primary gateway/firewall. So when your trusted machine in 192.168.2/24 talks to an address in 192.168.3/24, it talks to your primary gateway, and your gateway says, "whoa, dude. wazzat?" I'd fix this by making your main firewall the barrier machine. This would require a three or more port firewall. Pass in from trusted to anywhere. block in quick on untrusted to trusted Pass from untrusted to anywhere (but trusted is already blocked) Failing that, with a separate barrier machine, you will need to add a static route for the 192.168.3/24 subnet to point to the "trusted" address of your barrier machine. That way, when your trusted network machines try to access the untrusted network, they know to route through your barrier machine. Every single trusted machine that wants to access something in that subnet will need that extra route added. Clumsy at best (probably doable with the DHCP server. I just glanced, looks kinda ugly). I guess if there is only one untrusted device, you could just use an inbound NAT tunnel for whatever ports need to access that device, then just use the barrier's IP address to access the device. But I don't normally think in quantities of one, and this doesn't scale well. But if there's only one device, or several devices, but they can all be hit on different ports, that's an option. Another way to do it is with two NATting firewalls: Evil <--[NAT-FW] <- untrusted network [NAT-FW] <- trusted network. (internet) (192.168.3/24) (192.168.2/24) traffic flows unimpeded in the direction of the arrows, and is blocked going backwards. Your trusted machines can hit untrused machines or the internet, untrusted machines can hit the Internet, but they can't dig through to your trusted network. Yeah, the down side is that the trusted network has to jump through two routers, so the untrusted network potentially has better access than the trusted network, and that's just not fair. But ... it's easy. I've done the opposite, what I call "portable DMZ"s, where untrusted machines need access to the Internet but shouldn't be allowed to touch the trusted machines, but unlike your situation, the untrusted machines don't need to be accessed by the trusted. Small machine, two NICs. One NIC is DHCP to the trusted network, NAT and DCHP server on the untrustedv side, maybe a logging DNS server. Block all from the untrusted to the trusted subnet, pass everything else (internet). These don't need those inbound static routes. Nick.
Re: gre over carp
Yes, exactly. The fail-back never worked. All SAs would disappear and subsequent failover to slave dropped SAs there too. There was a story behind this from the developer somewhere in the mail archives. A while back. On Wednesday, December 13, 2023 at 05:55:50 p.m. GMT+9, Janne Johansson wrote: Den ons 13 dec. 2023 kl 04:15 skrev All : > > >I'd like to add sasyncd in the mix and a 2nd router for higher > availability. > Don't do it. sasyncd is known not to work properly in failover scenarios. > When I ran it it did work fine for the first fail-over, but seldom (or perhaps never?) on fail-back when the master returned, so it was ok for giving me nice redundancy if the current carp master died, then I could choose a suitable time after fixing this node when to take a the hit of a new tunnel-setup as I flipped back. Never knew why it would only work one-way for me, but we had certain issues with broadcom bnx(4) cards and multicast at the time, so it could have been related to that. > >Will gre over carp work? > I think you can just try out in a vm. Don't see the reason why it would > not. > But perhaps there are some features that CARP interface doesn't support > for gre. > Do mind that carp on software-defined switch networks might need some settings in order to allow the virtual eth cards to send out frames with "bogus" mac-addresses, since some hypervisors keep good track of which macs they have given to a VM and drop ethernet frames sent with not-those mac-addresses as source. But to add to the original reply, I would probably go for two gre's towards the non-carp ips, since you are using ospf anyhow, you might just tell ospfd that one gre has a slightly higher cost than the other, and let it deal with the new network map when one of them fails. -- May the most significant bit of your life be positive.
Re: gre over carp
>I'd like to add sasyncd in the mix and a 2nd router for higher availability. Don't do it. sasyncd is known not to work properly in failover scenarios. >Will gre over carp work? I think you can just try out in a vm. Don't see the reason why it would not. But perhaps there are some features that CARP interface doesn't support for gre. On Tuesday, December 12, 2023 at 09:01:53 p.m. GMT+9, Kapetanakis Giannis wrote: I was wondering if anyone runs gre tunnels over carp. We have an OpenBSD router that does ipsec over gre tunnels with remote location routers in order to pass voip traffic. Routing is done with ospf on top of gre. I'd like to add sasyncd in the mix and a 2nd router for higher availability. Will gre over carp work? I'd prefer to use the carped IP in the tunnel and not the real IP of each server, so eventually 1 tunnel (active) per remote router. How will this work when I demote master and go via backup? Thanks, G
Re: OpenBSD xen and AWS
Antoine, I actually did use that repo for building and running openbsd on AWS. Unfortunately, I don't have access to physical openbsd machine to create vmdk now. So, I had to resort to running qemu and installing openbsd there, followed by the steps I outlined below. There was a community AMI in us-east-1 till about last week (openbsd 7.0). It is now gone though. On Friday, October 27, 2023 at 12:21:45 a.m. GMT+9, Antoine Jacoutot wrote: On Thu, Oct 26, 2023 at 12:01:06PM +, All wrote: > OK, thanks to Mike and Antoine! > I tried with t2 instances (current generation - the only choice present), yet > still no dice. Perhaps, the issue is with how I created the image. > I used qemu, created qcow2, installed openbsd, converted qcow2 to raw > and then with vmdktool converted raw to vmdk. > AWS recognized vmdk with out any issue and booted it. But no xnf0 interfaces > were detected. Try this. Somehat ugly but it works for me (tm). https://github.com/ajacoutot/aws-openbsd
Re: OpenBSD xen and AWS
OK, thanks to Mike and Antoine! I tried with t2 instances (current generation - the only choice present), yet still no dice. Perhaps, the issue is with how I created the image. I used qemu, created qcow2, installed openbsd, converted qcow2 to raw and then with vmdktool converted raw to vmdk. AWS recognized vmdk with out any issue and booted it. But no xnf0 interfaces were detected. On Thursday, October 26, 2023 at 04:47:18 p.m. GMT+9, Antoine Jacoutot wrote: On Tue, Oct 24, 2023 at 10:40:34PM +, All wrote: > Hi, > > There was a time when we could run OpenBSD on AWS. > Antoine Jacoutot did a great work to make that possible. > These days, xnf0 interface is not being initialized. Xen is being > identified as Xen 4.11 (12?) but no xnf interfaces are sowing up > after boot. NetBSD has xennet0 being initiated and FreeBSD (I guess) xnb. > > Did anyone else faced similar problem? Actually Mike Belopuhov (mikeb@) did all the work, I just assembled things. For me me it still works with old generation of ec2 instances (e.g. t2). New generations are using KVM but we are missing the ENA driver for network (and maybe other things). Cheers! -- Antoine
OpenBSD xen and AWS
Hi, There was a time when we could run OpenBSD on AWS. Antoine Jacoutot did a great work to make that possible. These days, xnf0 interface is not being initialized. Xen is being identified as Xen 4.11 (12?) but no xnf interfaces are sowing up after boot. NetBSD has xennet0 being initiated and FreeBSD (I guess) xnb. Did anyone else faced similar problem?
Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI
Your network has first usable IP address 108.181.26.177, not 108.181.26.178. Also, your broadcast address is 108.181.26.191 and not 108.181.26.190 On Saturday, July 29, 2023 at 12:17:47 p.m. GMT+9, Chris Bennett wrote: Hi. My server company either was bought by another company or just hooked up new IP ranges. I have a super cheap server with 13 IP addresses. This only has ancient Java KVM which I can't hook up to, but I can use the console preview only as single refreshable images. So I had to coach them along. I had to really rush due to the cutoff date. I made a few mistakes, inet isn't spelled ine, etc. A power screwup, my fault. Watching someone trying to use ed was amusing. I had to get /home commented out since it needed manual fsck. It was a long day and all night and morning today. Everything is apparently working fine, but a little different than my previous setup. I would like some help to know if this setup will work after a reboot. I really don't want to ask for more help from support. The network is 108.181.26.176/28. Right now,the first IP is 108.181.26.178 and the last regular address is 108.181.26.190, which might be wrong. I'm too tired to read any more man pages or web pages. I needed more than 2hrs of sleep. I'm super worn out, so forgive my mistakes. Any help appreciated. I don't want the next syspatch reboot to fail. Chris Bennett cat /etc/hostname.em1 inet 108.181.26.178 0xfff0 108.181.26.190 inet alias 108.181.26.179 255.255.255.255 inet alias 108.181.26.180 255.255.255.255 inet alias 108.181.26.181 255.255.255.255 inet alias 108.181.26.182 255.255.255.255 inet alias 108.181.26.183 255.255.255.255 inet alias 108.181.26.184 255.255.255.255 inet alias 108.181.26.185 255.255.255.255 inet alias 108.181.26.186 255.255.255.255 inet alias 108.181.26.187 255.255.255.255 inet alias 108.181.26.188 255.255.255.255 inet alias 108.181.26.189 255.255.255.255 #inet alias 108.181.26.190 255.255.255.255 cat /etc/hosts 127.0.0.1 localhost ::1 localhost #108.181.26.177 gateway 108.181.26.178 bennettconstruction.us 108.181.26.179 strengthcouragewisdom.rocks 108.181.26.180 mail.strengthcouragewisdom.rocks 108.181.26.181 freedomforlife.rocks 108.181.26.182 mx.freedomforlife.rocks 108.181.26.183 bsd-sec.dev 108.181.26.184 mx.bennettconstruction.us 108.181.26.185 bsd-sec.com 108.181.26.186 mail.bsd-sec.com 108.181.26.187 cowboyup.xyz 108.181.26.188 mail.cowboyup.xyz 108.181.26.189 capuchado.com 108.181.26.190 # Using for development, unassigned cat /etc/myname bennettconstruction.us cat /etc/mygate 108.181.26.177 route -n show Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 108.181.26.177 UGS 11 25504 - 8 em1 108/8 108.181.26.179 UCn 11 0 - 4 em1 108.136.59.3 00:1f:6d:eb:60:00 UHLc 0 4 - 3 em1 108.136.125.137 00:1f:6d:eb:60:00 UHLc 0 2 - 3 em1 108.136.179.191 00:1f:6d:eb:60:00 UHLc 0 9 - 3 em1 108.136.182.161 00:1f:6d:eb:60:00 UHLc 0 9 - 3 em1 108.136.235.206 00:1f:6d:eb:60:00 UHLc 0 8 - 3 em1 108.136.238.232 00:1f:6d:eb:60:00 UHLc 0 10 - 3 em1 108.136.248.92 00:1f:6d:eb:60:00 UHLc 0 9 - 3 em1 108.137.2.3 00:1f:6d:eb:60:00 UHLc 0 3 - 3 em1 108.137.73.28 00:1f:6d:eb:60:00 UHLc 0 15 - 3 em1 108.137.74.160 00:1f:6d:eb:60:00 UHLc 0 4 - 3 em1 108.137.155.209 00:1f:6d:eb:60:00 UHLc 0 3 - 3 em1 108.181.26.176/28 108.181.26.178 UCn 1 2 - 4 em1 108.181.26.177 00:1f:6d:eb:60:00 UHLch 1 44 - 3 em1 108.181.26.178 00:25:90:6c:43:43 UHLl 0 4741 - 1 em1 108.181.26.179 00:25:90:6c:43:43 UHLl 0 3443 - 1 em1 108.181.26.180 00:25:90:6c:43:43 UHLl 0 4510 - 1 em1 108.181.26.180/32 108.181.26.180 UCn 0 0 - 4 em1 108.181.26.181 00:25:90:6c:43:43 UHLl 0 3004 - 1 em1 108.181.26.181/32 108.181.26.181 UCn 0 0 - 4 em1 108.181.26.182 00:25:90:6c:43:43 UHLl 0 4192 - 1 em1 108.181.26.182/32 108.181.26.182 UCn 0 0 - 4 em1 108.181.26.183 00:25:90:6c:43:43 UHLl 0 4767 - 1 em1 108.181.26.183/32 108.181.26.183 UCn 0 0 - 4 em1 108.181.26.184 00:25:90:6c:43:43 UHLl 0 8119 - 1 em1 108.181.26.184/32 108.181.26.184 UCn 0 0 - 4 em1 108.181.26.185 00:25:90:6c:43:43 UHLl 0 4902 - 1 em1 108.181.26.185/32 108.181.26.185 UCn 0 0 - 4 em1 108.181.26.186 00:25:90:6c:43:43 UHLl 0 3049 - 1 em1 108.181.26.186
Re: libvirtd on openbsd
For some reason I didn't get reply from Stuart to my inbox. Its on the mailing lists though. Thank you for your reply. I guess there are no solutions to run VMs with a graphical interface yet. Unless, I run qemu and vnc to a VM. On Monday, July 24, 2023 at 09:21:58 p.m. GMT+9, All wrote: Hi, I have installed libvirtd and virt-manager on 7.3. It seems not matter what I do, libvirtd doesn't not want to start. It always errors with no such group "root". I have changed unix_group to wheel and tried staff also, but it seems no matter which group I specify in .conf files (libvirtd.conf, qemu.conf, etc) it complains about "root" group. Did anyone managed to run libvirtd under Openbsd?
libvirtd on openbsd
Hi, I have installed libvirtd and virt-manager on 7.3. It seems not matter what I do, libvirtd doesn't not want to start. It always errors with no such group "root". I have changed unix_group to wheel and tried staff also, but it seems no matter which group I specify in .conf files (libvirtd.conf, qemu.conf, etc) it complains about "root" group. Did anyone managed to run libvirtd under Openbsd?
Re: syslog.conf syntax to specify several clients
Thank you. I was still guessing if my understanding was correct about !, !!, + and ++ being respectively same but for prog vs host. It is nice to have ti clarified. On Thursday, March 9, 2023 at 06:16:04 p.m. GMT+9, Paul de Weerd wrote: On Thu, Mar 09, 2023 at 04:00:24AM +, All wrote: | Right. | That is what I was suspecting. I did use wildcard, but some hosts | use completely different fqdns, so... | Anyway, thank you and blocks per host it is then. | | One question. | What is the difference between ++host and +host? Same effect as !prog vs !!prog, as mentioned in the documentation: "work the same way as their prog counterparts". Again, from the same syslog.conf(5) manpage: > !!prog causes the subsequent block to abort evaluation when a message > matches, ensuring that only a single set of actions is taken. !* can be > used to ensure that any ensuing blocks are further evaluated (i.e. > cancelling the effect of a !prog or !!prog). Please carefully read that page, it has all the information you need. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: syslog.conf syntax to specify several clients
Right. That is what I was suspecting. I did use wildcard, but some hosts use completely different fqdns, so... Anyway, thank you and blocks per host it is then. One question. What is the difference between ++host and +host? On Thursday, March 9, 2023 at 01:47:44 a.m. GMT+9, Paul de Weerd wrote: On Wed, Mar 08, 2023 at 03:39:07PM +0100, Noth wrote: | On 07/03/2023 06:35, All wrote: | | > Hi all, | > | > I have a server that acts as a syslog aggregator | > for several other servers. I was trying to see whether | > clients can be specified on one line but I can't see anything | > regarding syntax for such cases in man pages. | > | > Do we need to specify each client on the separate line? | > Like: | > | Hi, yes you do. | > I tried several kinds of semicolon, comma and plus syntax | > but have not being able to make it work. | > I can only see the very first host (eg. server1) in the log, not others. | | From the man page for syslog.conf: | | # Log everything coming from host bastion to a separate file. | ++bastion | *.* /var/log/bastion | +* If you look closely at the manpage[1], it says: > Blocks starting with +host or ++host or +* work the same way as their > prog counterparts, but they match on the hostname instead of the program > name. And for the 'prog counterparts' there's this bit: > Each block of lines is separated from the previous block by a tag. The > tag is a line beginning with !prog and each block will be associated with > calls to syslog from that specific program (matched using glob(7) rules). Note the '(matched using glob(7) rules)' bit. I have this in my /etc/syslog.conf: --- syslog.conf snippet -- # - send logs from ubiquiti wifi access points to their own logfiles ++ubiquiti-*.alm.weirdnet.nl *.* /var/log/ubi +* -- Which sends the logs from ubiquiti-1, ubiquiti-2, ubiquiti-3 and so on and so forth to /var/log/ubi. So, no, you do NOT need to specify each client on a separate line, but you may have to do so if you can't glob(7) the systems together. Cheers, Paul 'WEiRD' de Weerd [1]: https://man.openbsd.org/syslog.conf.5 -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
syslog.conf syntax to specify several clients
Hi all, I have a server that acts as a syslog aggregator for several other servers. I was trying to see whether clients can be specified on one line but I can't see anything regarding syntax for such cases in man pages. Do we need to specify each client on the separate line? Like: +server1 *.blah /some/dir +server2 *.blah /some/dir Or can we do something like this? +server1, +server2 *.blah /some/dir or +server1,server2 *.blah /some/dir I tried several kinds of semicolon, comma and plus syntax but have not being able to make it work. I can only see the very first host (eg. server1) in the log, not others.
Re: Stretch/L2VPN between two datacenters
As far as I remember, I could only get gre to work over wg. Anything that is ethernet (like tmpr, etherip, etc) didn't work. My wild guess is that packet overhead is becoming to big as there is a lot of encapsulation. Also, wg interfaces do not have same features like normal interfaces so for example you can't add them to bridges and the like. On Friday, January 20, 2023 at 08:48:58 a.m. GMT+9, Lars Bonnesen wrote: I have been fighting with this for a while now, trying to make it work reading man pages... But it does not work as I want it to work. tcpdump can see a lot of arp requests on bridge0, egre0, vlan172 - but nothing seems to get to wg0. This is my ifconfig filtered for public IPs: lo0: flags=8049 mtu 32768 index 5 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff00 vmx0: flags=8843 mtu 1500 lladdr 00:50:56:b4:a5:ab index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (10GbaseT) status: active inet qq.ww.ee.rr netmask 0xff00 broadcast ee.rr.tt.yy vmx1: flags=8802 mtu 1500 lladdr 00:50:56:b4:0d:26 index 2 priority 0 llprio 3 media: Ethernet autoselect (10GbaseT) status: active vmx2: flags=8b43 mtu 1600 lladdr 00:50:56:b4:ef:b4 description: corp index 3 priority 0 llprio 3 media: Ethernet autoselect (10GbaseT) status: active enc0: flags=0<> index 4 priority 0 llprio 3 groups: enc status: active pflog0: flags=141 mtu 33136 index 6 priority 0 llprio 3 groups: pflog lo1: flags=8008 rdomain 1 mtu 32768 index 8 priority 0 llprio 3 groups: lo wg0: flags=80c3 mtu 1420 index 9 priority 0 llprio 3 wgport 51820 wgpubkey GIWFxfaaxt1VmURRvEtJkG/mZQgVLNtHuEtPa6vt/kM= wgpeer MSS4DjJjPtp9DsTpMbNQ1ict6jEx07DICfipOpnOUR4= wgendpoint aa.bb.cc.dd 51820 tx: 1690108800, rx: 2934539600 last handshake: x seconds ago wgaip 192.168.5.1/32 groups: wg inet 192.168.5.2 netmask 0xff00 broadcast 192.168.5.255 egre0: flags=8943 mtu 1500 lladdr fe:e1:ba:d0:31:5b index 14 priority 0 llprio 3 encap: vnetid 172 txprio 0 rxprio packet groups: egre tunnel: inet 172.24.90.92 --> 172.24.90.91 ttl 64 nodf vlan172: flags=8943 mtu 1500 lladdr 00:50:56:b4:ef:b4 index 24 priority 0 llprio 3 encap: vnetid 172 parent vmx2 txprio packet rxprio outer groups: vlan media: Ethernet autoselect (10GbaseT) status: active inet 172.24.90.94 netmask 0xff00 broadcast 172.24.90.255 bridge0: flags=41 mtu 1500 index 25 llprio 3 groups: bridge priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp vlan172 flags=3 port 24 ifpriority 0 ifcost 0 egre0 flags=3 port 14 ifpriority 0 ifcost 0 vmx2 flags=3 port 3 ifpriority 0 ifcost 0 On the other end the ifconfig is similar wg0 is working. I can ping 192.168.5.1 from 192.168.5.2 and visa versa. 172.24.90.0/24 (vlan172) is the network that I want to strech... and is presented to the obsd as vmx2 connected to an access port on a switch Can anyone guide me in the right direction, thx? Regards, Lars. On Wed, Jan 4, 2023 at 7:24 AM Lars Bonnesen wrote: > Thanks for your replies. It has been Xmas and I have been delayed, but I > have now read up upon it. I am going for the tpmr(4). We are going to > replicate a lot of live data from Site1 to Site2, and my experiences with > OpenVPN is that it is great, but not high performing. So I have established > a WireGuard connection with one OBSD on each site, and I am planning to > tunnel tpmr through this - I guess that tpmr itself is not encrypted in any > way? > > Regards, Lars. > > On Fri, Dec 16, 2022 at 4:30 PM deich...@placebonol.com < > deich...@placebonol.com> wrote: > >> I've run L2 over an IPsec tunnel using egre (gre(4)) and bridge (bridge >> (4)) to connect systems in different locations together. >> >> This was done before David Gwynne created tpmr(4). I've been to lazy to >> reimplement my current configuration. >> >> 73 >> diana >> >
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
rdist remove option and default behaviour
Hi, 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?
Re: dhcpinform only on dhcpd -u
Hi, Perhaps I was not really clear about this. What is the rationale to only have DHCP server to reply to DHCPINFORM messages and never serve any ip leases while we bind it to UDP socket? Currently, dhcp server will only serve ip addresses if its using raw sockets, replaying to broadcasts etc. On Wednesday, October 26, 2022 at 08:43:16 p.m. GMT+9, All wrote: Hi, in dhcpd.c we have: if (is_udpsock && packet->packet_type != DHCPINFORM) { log_info("Unable to handle a DHCP message type=%d on UDP " "socket", packet->packet_type); return; } Why do we not want to process normal dhcp messages like discover/request? If you want dhcpd to not bother with raw packets and broadcasts and just focus on unicasts this would be a logical option.
Re: PF rules to block out every IP from a given country
Considering you solved the issue with getting all IPs for a given country correctly (and perhaps updating it sometimes): 1. Dump all IP addresses/ranges into a file (eg. blocked.ips) 2. add table file /path/to/blocked.ips add "persist" if you want. 3. create rule to block all incoming connections from Alternatively, you can just create a file with IPs you allow, create table and write rules to allow connections from IPs in that file. On Wednesday, December 7, 2022 at 09:44:34 a.m. GMT+9, Damian McGuckin wrote: Has anybody created rules such as this and if so, do you have an example? Stay safe - Damian Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037 Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here Views & opinions here are mine and not those of any past or present employer
Recouvrement de creances : service TOUT COMPRIS
Si vous ne visualisez pas ce message, suivez ce lien Pour chaque dossier transmis par Internet, 1 ? est versi ` l'association + Entrepreneurs du Monde ;, qui accompagne des dizaines de milliers de micro-entreprises dans le monde par l'attribution de microcridits accordis aux entrepreneurs les plus dishiritis. Le slogan de l'association est Avec presque rien on peut changer presque tout. Recouvrement de criances amiable et judiciaire, France International depuis 1970 Pour l'encaissement de vos impayis : PAS DE SUCCHS, PAS D'HONORAIRES Binificiez en plus de l'option TOUT COMPRIS Les frais de procidure judiciaire sont avancis par FRANCE CREANCES. L'option TOUT COMPRIS vous est offerte ` la remise du dossier. Sociiti spicialisie depuis 1970, en recouvrement amiable et judiciaire, en France et ` l'international, FRANCE CREANCES est membre de l'ANCR et signataire de la charte de diontologie professionnelle qui implique la couverture par une assurance responsabiliti professionnelle souscrite auprhs de la Cie MMA. La certification ISO 9001 (dilivrie par l'AFAQ) garantit le respect des procidures de traitement des dossiers de recouvrement confiis ` FRANCE CREANCES. Le montant des encaissements est reversi au 30 de chaque mois et le bilan de la sociiti fait apparantre trhs clairement les sommes disponibles pour le compte de ses clients, en sus d'une caution bancaire. Rifirencie par des centaines de PME#8260;PMI, FRANCE CREANCES intervient aussi pour des grands groupes, des banques et des Etablissements Publics Industriels et Commerciaux. Le centre de traitement International de FRANCE CREANCES travaille en Anglais, Allemand, Espagnol, Italien, Polonais. Pour vous disabonner, collez ce lien dans votre navigateur : http://www.gce-mailer-3.com/unsuscribe.asp?lang=francaisid_formulaire=4email=misc@openbsd.orgid_message=810
Visit us at http://www.aboutyoga.go.ro
http://www.aboutyoga.go.ro