Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src
On Mon, 18 Aug 2014, Jason Tubnor wrote: On 2 June 2014 10:23, Ted Unangst t...@tedunangst.com wrote: Part of the deprecation / migration process is identifying the weird ways people use vnd and finding solutions for them. But as we've seen, people never move forward without the occasional push. So the most appropriate way to use vnd(4) as an encrypted container going forward would be to lay down softraid(4) CRYPTO inside it to achieve a like-for-like outcome or would this be over-complicating things? I have had success in testing this use case but I am aware it may not be supported. To revive this old thread again (I missed the recent post): I tesed the same or similar (softraid(4) crypto volume on top of unencrypted vnd(4) device in my case) in July this year and I saw some kind of write amplification effect by a factor of two. The resulting effective writing speed was quite low. The sector size of the underlying hard drive was 4K bytes. Regards, David
Re: problem with CARP+VLAN+OpenBSD 5.5
Morning,
On 15/10/14 03:18, Stuart Henderson wrote:
On 2014-10-14, Federico Donati nix.b...@gmail.com wrote:
On 10/14/2014 06:53 PM, Andy wrote:
Why do you have so many CARP interfaces?
Generally it's good practice to have one CARP interface per broadcast
domain / VLAN etc, and have all your alias IP addresses defined in that
one CARP interface.
NB; when adding;
inet alias ipaddress mask Always set the mask for each alias to
255.255.255.255
This is apparently correct according to the devs. cite; something I was
told a long time ago even though you'll get a spurious error in the logs
at fail-over time..
I ignore that advice because I am announcing my carp networks into OSPF,
the bad effects *seem* to be limited to some arp: attempt to add entry ..
on carpXX / arp: attempt on vlanXX flip-flop in the logs.
Hi, yea that's the error that you see if you have 255.255.255.255, but
apparently it can be ignored. And is correct.
It would be nice if a developer could confirm what subnet mask should be
set on alias IP addresses nowadays?
A /32 subnet only needs to be defined on the alias IP addresses. The
first IP in a CARP interface should have a subnet that matches the
physical/VLAN interface's subnet.
Hello Andy,
we use so many carp interfaces because we have separate subnets, so the
netmask 255.255.255.255 can't fit our requirements.
In past, we tried to use the subnet netmask (i.e. 255.255.255.240), but
we didn't feel so confident about this configuration, and the official
documentation does not elaborate on the topic.
Does it always start once you get to 19?
I seem to remember having to increase the number of BPF devices which
high numbers of VLANS etc..
This is only needed if you have programs using those bpf devices
(common users include dhcpd, dhcrelay, LLDP listeners).
fstat | grep bpf will show what's in use.
Sorry, maybe I wasn't so clear on the suggestion. I was only saying that
it is good practice to have a single subnet on a single broadcast
domain, and have a single CARP interface in that subnet and broadcast
domain and define alias IP addresses on the CARP interface for all the
IPs you need.
for(( i=10; i = 30; i++ )); do mknod /dev/bpf$i c 23 $i; done
for(( i=10; i = 30; i++ )); do chmod o-r,g-r /dev/bpf$i; done
That's intresting. On a similar machine I have only 10 bpf devices
(0-9). I will study this tomorrow.
Please, don't recommend people do it this way. The right tool for the
job is MAKEDEV (which also takes into account any possible arch
differences in the device major)
# cd /dev
# sh MAKEDEV bpf{10,11,12,...}
That's good to know, thanks for the advice.
This all generally looks ok and seems like you know what you're doing.
The usual thing which causes multi master is PF. Also rememer to *not*
sync your carp states over pfsync, this works for us;
pass out quick proto carp keep state (no-sync) set prio 7
pass quick proto carp from { fe80::/10 } to { ff00::/8 } keep state (no-sync)
pass quick proto carp from { $all_carpv4_ips } keep state (no-sync)
pass quick on { $if_pfsync_dev } proto pfsync keep state (no-sync)
block drop quick proto carp
Using no-sync is the right thing to do for carp and pfsync states.
IIRC the prio is set automatically for carp, but forcing it doesn't hurt.
FWIW I haven't hit this ..
$ ifconfig carp|grep -c ^carp
29
The most common cause I've seen for split carp states is a mismatch of
IP addresses between master/secondary, though I would think that a
combination of using defer and not using no-sync on the carp/pfsync
states could very well cause problems like this.
Re: shutdown/reboot on acpi/qemu signals
On 13/10/14 22:50, Mike Larkin wrote: On Mon, Oct 13, 2014 at 07:42:34PM +0100, Nux! wrote: Hello, I'm having an issue with my OpenBSD cloud instance in that it completely ignores the signals sent to it by qemu-kvm, so instead of getting shut down or rebooted gracefully it has to be reset. Anyone hit this issue before and can advise on the matter? Thanks, Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro What version of OpenBSD? We fixed this in April. I can also verify that in at least one of my vms (current / i386 / SP) acpi shutdown now works (on ovirt/RHEV). This was not the case a couple of months ago and I was also using disabled mpbios. Thanks for the change :) G
Re: current snapshot installer not recognising USB devices
On Tue, 14 Oct 2014, at 10:24 AM, Carlin Bingham wrote: On Tue, 14 Oct 2014, at 09:05 AM, Martin Pieuchot wrote: On 14/10/14(Tue) 06:40, Carlin Bingham wrote: I have booted the latest (11/10/14) snapshot install56.fs from a USB drive and want to install it to an external USB drive but the drive (and other USB devices) are not being recognised. No kernel messages are being displayed when USB devices are added/removed, and if I run `sh MAKEDEV sd2` it gives device not configured when trying to mount it. In the installer with 5.5 release, it just works and kernel messages are displayed as expected. Has something changed that would cause this? Or is there something I need to do now to bring USB up? This is on a Lenovo T440p. dmesg for 5.5 and the snapshot (both from the install shell): [...] OpenBSD 5.6-current (RAMDISK_CD) #380: Sat Oct 11 16:04:03 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD [...] uhub2 at uhub0 port 1 vendor 0x8087 product 0x8008 rev 2.00/0.04 addr 2 uhub3 at uhub1 port 1 vendor 0x8087 product 0x8000 rev 2.00 SIZE 0.04 addr 2 This is really weird. Is it really what you're seeing? Apparently you don't get any interrupt from your rate-matching hub. That would explain why you don't see any new blue lines when connecting a device. Do you have an option in your BIOS to toggle USB3 support? Does it make any difference? In BIOS, USB 3.0 Mode was set to [AUTO], changing that to [DISABLED] fixed it and, as expected, changing it to [ENABLED] breaks it. Thanks for your help. Just out of curiosity, what would have changed that would cause USB 3.0 Mode being set to [AUTO] no longer work when it did work fine in 5.5? -- Carlin
Re: current snapshot installer not recognising USB devices
On 16/10/14(Thu) 00:07, Carlin Bingham wrote: On Tue, 14 Oct 2014, at 10:24 AM, Carlin Bingham wrote: On Tue, 14 Oct 2014, at 09:05 AM, Martin Pieuchot wrote: On 14/10/14(Tue) 06:40, Carlin Bingham wrote: I have booted the latest (11/10/14) snapshot install56.fs from a USB drive and want to install it to an external USB drive but the drive (and other USB devices) are not being recognised. No kernel messages are being displayed when USB devices are added/removed, and if I run `sh MAKEDEV sd2` it gives device not configured when trying to mount it. In the installer with 5.5 release, it just works and kernel messages are displayed as expected. Has something changed that would cause this? Or is there something I need to do now to bring USB up? This is on a Lenovo T440p. dmesg for 5.5 and the snapshot (both from the install shell): [...] OpenBSD 5.6-current (RAMDISK_CD) #380: Sat Oct 11 16:04:03 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD [...] uhub2 at uhub0 port 1 vendor 0x8087 product 0x8008 rev 2.00/0.04 addr 2 uhub3 at uhub1 port 1 vendor 0x8087 product 0x8000 rev 2.00 SIZE 0.04 addr 2 This is really weird. Is it really what you're seeing? Apparently you don't get any interrupt from your rate-matching hub. That would explain why you don't see any new blue lines when connecting a device. Do you have an option in your BIOS to toggle USB3 support? Does it make any difference? In BIOS, USB 3.0 Mode was set to [AUTO], changing that to [DISABLED] fixed it and, as expected, changing it to [ENABLED] breaks it. Thanks for your help. Just out of curiosity, what would have changed that would cause USB 3.0 Mode being set to [AUTO] no longer work when it did work fine in 5.5? I've no idea, I don't know what the BIOS is doing and I don't have such hardware. If you want you can try to find which change introduced that, that might be useful... who knows. Martin
Re: problem with CARP+VLAN+OpenBSD 5.5
On 10/15/2014 04:18 AM, Stuart Henderson wrote:
The most common cause I've seen for split carp states is a mismatch of
IP addresses between master/secondary, though I would think that a
combination of using defer and not using no-sync on the carp/pfsync
states could very well cause problems like this.
Hello Stuart,
I've removed defer from /etc/hostname.pfsync0, and I also added some
bpf device (one for every carp I have) with MAKEDEV, as you suggested.
Then, I've added no-sync to pf, so the running pf.conf is:
set skip on lo0
pass quick on em0 proto pfsync keep state (no-sync)
pass quick on em0
pass quick on { vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 vlan1002 vlan1003 }
proto { carp pfsync } keep state (no-sync)
pass in quick
pass out quick
but my problem persists.
I've checked again my hostname.carpXX files using diff, and the only
difference is the advskew.
When I reboot the BACKUP machine (system-2), it comes back with some
random interfaces in MASTER state. For these interfaces, if I run ksh
/etc/netstart carpXX on system-1 server, everything start working fine
again.
On system-1, after the reboot of system-2 I see these messages:
nd6_na_input: duplicate IP6 address fe80:1e::200:5eff:fe00:17d
nd6_na_input: duplicate IP6 address fe80:1f::200:5eff:fe00:17e
nd6_na_input: duplicate IP6 address fe80:20::200:5eff:fe00:17f
I can't find anything strange in log files.
Any idea?
ath stops working until a manual scan
ath started misbehaving really bad recently. it works for a couple of minutes and then i have to do ifconfig ath0 scan, and starts working again. i know ath support is very picky, but this one is an older one, and except a hiccup here and there, i dont recall frustration on this scale. any ideas? $ ifconfig ath0 ath0: flags=28863UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500 lladdr x priority: 4 groups: wlan egress media: IEEE802.11 autoselect (DS11 mode 11b) status: active ieee80211: nwid chan 6 bssid 00:22:b0:a2:6a:c0 wpakey not displayed wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip inet 10.10.10.60 netmask 0xff00 broadcast 10.10.10.255 $ netstat -ni NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls lo0 32768 Link 0 00 0 0 lo0 32768 ::1/128 ::1 0 00 0 0 lo0 32768 fe80::%lo0/ fe80::1%lo0 0 00 0 0 lo0 32768 127/8 127.0.0.10 00 0 0 em0*1500 Link x0 00 0 0 ath01500 Link x32752782375111 0 ath01500 10.10.10/24 10.10.10.60 32752782375111 0 enc0* 0 Link 0 00 0 0 pflog0 33192 Link 0 04 0 0 OpenBSD 5.6-current (GENERIC.MP) #368: Sun Oct 5 21:44:34 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF real mem = 2137354240 (2038MB) avail mem = 2090033152 (1993MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/18/07, BIOS32 rev. 0 @ 0xfd690, SMBIOS rev. 2.4 @ 0xe0010 (67 entries) bios0: vendor LENOVO version 7BETC9WW (2.10 ) date 04/18/2007 bios0: LENOVO 1705CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 97 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4629 serial 327 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) bios0: ROM list: 0xc/0xea00! 0xcf000/0x1000 0xd/0x1000 0xdc000/0x4000! 0xe/0x1! cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1667, 1333, 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel 82945GM Video rev 0x03 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Analog Devices AD1981HD, 0x/0x, using Analog Devices AD1981HD audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 1 int 20 pci1
Re: host(1) prints errors to STDOUT
On 2014-10-14 Tue 10:41 AM |, Theo de Raadt wrote: Unfortunately host is maintained upstream, in the bind codebase, by ISC. You should file your bug report there, because that is the right way to get change into the ecosystem. Submitted, with their GITWEB line number refs. ISC's bug database is not publicly readable, in order to protect the privacy of users who have included identifying information or attached logs or crash dumps to their bug reports. http://www.isc.org/community/report-bug/ -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: ath stops working until a manual scan
On Wed, Oct 15, 2014 at 05:22:00PM +0200, frantisek holop wrote: ath started misbehaving really bad recently. it works for a couple of minutes and then i have to do ifconfig ath0 scan, and starts working again. Can you elaborate on what recently means? Did it ever work properly, and if so, when?
Re: ath stops working until a manual scan
Stefan Sperling, 15 Oct 2014 17:36: On Wed, Oct 15, 2014 at 05:22:00PM +0200, frantisek holop wrote: ath started misbehaving really bad recently. it works for a couple of minutes and then i have to do ifconfig ath0 scan, and starts working again. Can you elaborate on what recently means? Did it ever work properly, and if so, when? recently = this week. however this notebook has been in storage for ~2 years, so i would lie if i said i remember exactly how it was. but i do remember that it was usable on a daily basis (and it was used for around a year) without doing scans to resume online activity. then it went into storage. a bit of a soap opera, but that's life. since i sent that email, connections have not dropped. i will try to disable -powersave if it happens again (although i did not try to turn it on) -f -- i am so open-minded my brain falls out.
Re: carp not reverting to master
On Thu, 02 Oct 2014 18:02:23 +0100 Andy a...@brandwatch.com wrote: Hi Try setting the advskew to a number greater than 200 and less then 254. This seems to be the most stable. For best practice our primary runs with carp and pfsync values of '1'. And the backup runs with carp and pfsync values of '2'. We do this for two reasons. 1) it is extremely stable! 2) We found that CARP master is almost random/unstable when both firewalls have the same value (esp '0'), because; When advbase is set to 0 the skew value alone is used to calculate how often advertisements are sent (the advertisement window) using this formula: Window in microseconds = advskew * 100 / 256 E.g. 100 * 100 / 256 = 390625us So it would take much to cause a flip.. Setting advbase to 1 on both is better as this is more stable if you want to have the same carp demote counters.. Good luck :) Andy Andy, thank you for the tip for increasing advskew value, I'm gonna try it out. I had failover on another pair of firewalls, this time external ones, running bgp. Carp is not reverting to master some 5 hours so far. On master, while down, carp is demoted, pfsync is not: pacija@bgp1:~ $ ifconfig -g carp carp: carp demote count 1 pacija@bgp1:~ $ ifconfig -g pfsync pfsync: carp demote count 0 On backup, while master, neither is demoted: pacija@bgp2:~ $ ifconfig -g carp carp: carp demote count 0 pacija@bgp2:~ $ ifconfig -g pfsync pfsync: carp demote count 0 In /var/log/messages on downed master, I can see there was some turbulence: Oct 14 15:21:19 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:21:19 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:21:22 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:21:22 bgp1 /bsd: carp2: state transition: BACKUP - MASTER Oct 14 15:22:52 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:22:52 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:22:53 bgp1 /bsd: carp3: state transition: MASTER - BACKUP Oct 14 15:23:02 bgp1 /bsd: carp3: state transition: BACKUP - MASTER Oct 14 15:23:03 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:23:03 bgp1 /bsd: carp2: state transition: BACKUP - MASTER Oct 14 15:23:41 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:23:41 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:23:41 bgp1 /bsd: carp3: state transition: MASTER - BACKUP Oct 14 15:23:54 bgp1 /bsd: carp3: state transition: BACKUP - MASTER Oct 14 15:23:56 bgp1 /bsd: carp2: state transition: BACKUP - MASTER Oct 14 15:23:56 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:26:04 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:26:04 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:26:04 bgp1 /bsd: carp3: state transition: MASTER - BACKUP And in /var/log/daemon there is also bgp flapping at that time: Oct 14 15:22:53 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: directly connected Oct 14 15:23:02 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: via 82.117.192.124 Oct 14 15:23:41 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: directly connected Oct 14 15:23:54 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: via 82.117.192.124 Oct 14 15:26:04 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: directly connected 82.117.192.124 is address of one of three carp interfaces. I have 'demote carp' in bgpd.conf, so that master does not reclaim its master role before bgp routes are up. The question remains, why is it not reverting back to master once everything is ok? -- Marko Cupać https://www.mimar.rs
Re: carp not reverting to master
On Wed, Oct 15, 2014 at 2:13 PM, Marko Cupać marko.cu...@mimar.rs wrote: Oct 14 15:21:19 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:21:19 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:21:22 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:21:22 bgp1 /bsd: carp2: state transition: BACKUP - MASTER Oct 14 15:22:52 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:22:52 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:22:53 bgp1 /bsd: carp3: state transition: MASTER - BACKUP Oct 14 15:23:02 bgp1 /bsd: carp3: state transition: BACKUP - MASTER Oct 14 15:23:03 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:23:03 bgp1 /bsd: carp2: state transition: BACKUP - MASTER This looks to me like you have flapping taking place because of your ifstated configuration. Something is wrong with /etc/ifstated.conf on one end or the other. -- “Don't eat anything you've ever seen advertised on TV” - Michael Pollan, author of In Defense of Food
Re: rcctl ansible service support
On Oct 13, 2014 10:40 PM, Patrik Lundin patrik.lundin@gmail.com wrote: On Sat, Sep 13, 2014 at 02:39:04AM +0200, Patrik Lundin wrote: armani@ has laid the groundwork for this and I recently started contributing to his fork as well. The work-in-progress can be found here: https://github.com/jarmani/ansible/tree/openbsd_rcctl/library/system Just a heads up: ansible has since had its modules split into two new repositories, core and extras. The current service module (with additional fixes that requires a recent rcctl(8)) can be found here: https://github.com/jarmani/ansible-modules-core/blob/openbsd_rcctl/system/service.py Regards, Patrik Lundin Thanks, I appreciate the heads up. I've been using this module for a few weeks and everything is working well. Is a recent rcctl post the 5.6 freeze or will this work with the next release? Thanks again.
Re: rcctl ansible service support
On Wed, Oct 15, 2014 at 11:48:20AM -0700, xSAPPYx wrote: On Oct 13, 2014 10:40 PM, Patrik Lundin patrik.lundin@gmail.com wrote: On Sat, Sep 13, 2014 at 02:39:04AM +0200, Patrik Lundin wrote: armani@ has laid the groundwork for this and I recently started contributing to his fork as well. The work-in-progress can be found here: https://github.com/jarmani/ansible/tree/openbsd_rcctl/library/system Just a heads up: ansible has since had its modules split into two new repositories, core and extras. The current service module (with additional fixes that requires a recent rcctl(8)) can be found here: https://github.com/jarmani/ansible-modules-core/blob/openbsd_rcctl/system/service.py Regards, Patrik Lundin Thanks, I appreciate the heads up. I've been using this module for a few weeks and everything is working well. Is a recent rcctl post the 5.6 freeze or will this work with the next release? Extract from 'man rcctl': rcctl first appeared in OpenBSD 5.7. -- Antoine
Re: Route-to with a dynamic 'next hop'
On 15-10-2014 01:38, Justin Mayes wrote: Thanks to both of you for the advice Just to followup I ended up with the relayd 'routers' setup as described in man page but with a script monitor rather than icmp. The monitor finds gateway for interface in route table and pings it with -I interface source address. Seems to work as desired. I also got it to work with ifstated but it seemed like more script and also a 2nd process when I have to run relayd for other purpose anyway. Glad that you got it working. But I really don't think a ifstated running alongside your relayd daemon would hurt your performance. And it would give you interface failure detection for free. Just keep in mind that detecting if you gateway is up, doesn't necessarily means detecting if that given gateway has internet connectivity. You might also need to ping some internet addresses for that. Cheers [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
pf matching the ttl of a packet
My DNS server is being used in a reflection attack. I can tell its a reflection attack by the incoming ttl of the DNS packet and the ping ttl as returned with ping. They differ, meaning it's spoofed from another site. While the system it's on is FreeBSD and it's pf is outdated, I didn't see an option in OpenBSD's pf that allows matching a packet by its ttl. Because if I had that I could block the reflection attacker and still allow the valid query from that IP through. Is there will for such an option in OpenBSD? If not I won't waste anyones time furthermore. Cheers, -peter
Re: [Bulk] Re: [Bulk] Re: openbsdstore: enable javascript and buy something or gtfo
On Tue, 7 Oct 2014 05:11:30 +0300 Matti Karnaattu wrote: Like removing that stupid web browser idiom that where is addressbar and back/forward buttons. The address bar is one of the only things you can trust when browsing a web page to the point that some mal-sites or mal-ads actually try to go full-screen and use a mock address bar within the page where incidentally the attack could be made much more effective/dangerous with javascript akin to the more widely known html for emails allowing fonts that make urls fool people. Get rid of the address bar! and allow javascript everywhere, you must work for Google ;-)
Re: RAID1C discipline and alternatives
On Thu, Oct 16, 2014 at 12:36 AM, Joerg Jung m...@umaxx.net wrote: Am 15.10.2014 um 00:58 schrieb Vladislav Manchev v...@bin.bz: I need to set up a few machines in the coming weeks and was wondering what's the status of stacked softraid and especially RAID1C discipline - i.e. CRYPTO on top of RAID1? Works fine here. Unfortunately I don't have the hardware right now so I can't really try it out, but any input is appreciated. Would using a hardware RAID controller and setting up softraid CRYPTO discipline on top of it do the trick? This would also work. Is this approach recommended for production use? IMHO, softraid is never a good idea for important production stuff and hardware raid should be preferred. One last question -- can you point me to particular RAID Controllers that are well supported under OpenBSD? areca http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/arc.4?query=arc Some of my readily available options are Adaptec RAID 6405E, LSI 3ware 9750-4i, LSI MegaRAID 9271-4i and HP Smart Array P222 but I'm open to any suggestions that will play better with OpenBSD. search the archives... Thanks for the input. I forgot to mention that my goal is actually FDE combined with RAID1 and not just setting up a CRYPTO volume on top of RAID1. Any insights? Best, Vladislav
Re: carp not reverting to master
Please excuse typos, sent from my phone On 15 Oct 2014, at 19:13, Marko Cupać marko.cu...@mimar.rs wrote: On Thu, 02 Oct 2014 18:02:23 +0100 Andy a...@brandwatch.com wrote: Hi Try setting the advskew to a number greater than 200 and less then 254. This seems to be the most stable. For best practice our primary runs with carp and pfsync values of '1'. And the backup runs with carp and pfsync values of '2'. We do this for two reasons. 1) it is extremely stable! 2) We found that CARP master is almost random/unstable when both firewalls have the same value (esp '0'), because; When advbase is set to 0 the skew value alone is used to calculate how often advertisements are sent (the advertisement window) using this formula: Window in microseconds = advskew * 100 / 256 E.g. 100 * 100 / 256 = 390625us So it would take much to cause a flip.. Setting advbase to 1 on both is better as this is more stable if you want to have the same carp demote counters.. Good luck :) Andy Andy, thank you for the tip for increasing advskew value, I'm gonna try it out. I had failover on another pair of firewalls, this time external ones, running bgp. Carp is not reverting to master some 5 hours so far. On master, while down, carp is demoted, pfsync is not: pacija@bgp1:~ $ ifconfig -g carp carp: carp demote count 1 pacija@bgp1:~ $ ifconfig -g pfsync pfsync: carp demote count 0 On backup, while master, neither is demoted: pacija@bgp2:~ $ ifconfig -g carp carp: carp demote count 0 pacija@bgp2:~ $ ifconfig -g pfsync pfsync: carp demote count 0 Hi, maybe in not reading your problem correctly but for as long as bgp1 has a demotion counter higher than bgp2 it will never go master. In /var/log/messages on downed master, I can see there was some turbulence: Oct 14 15:21:19 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:21:19 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:21:22 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:21:22 bgp1 /bsd: carp2: state transition: BACKUP - MASTER Oct 14 15:22:52 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:22:52 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:22:53 bgp1 /bsd: carp3: state transition: MASTER - BACKUP Oct 14 15:23:02 bgp1 /bsd: carp3: state transition: BACKUP - MASTER Oct 14 15:23:03 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:23:03 bgp1 /bsd: carp2: state transition: BACKUP - MASTER Oct 14 15:23:41 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:23:41 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:23:41 bgp1 /bsd: carp3: state transition: MASTER - BACKUP Oct 14 15:23:54 bgp1 /bsd: carp3: state transition: BACKUP - MASTER Oct 14 15:23:56 bgp1 /bsd: carp2: state transition: BACKUP - MASTER Oct 14 15:23:56 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:26:04 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:26:04 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:26:04 bgp1 /bsd: carp3: state transition: MASTER - BACKUP And in /var/log/daemon there is also bgp flapping at that time: Oct 14 15:22:53 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: directly connected Oct 14 15:23:02 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: via 82.117.192.124 Oct 14 15:23:41 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: directly connected Oct 14 15:23:54 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: via 82.117.192.124 Oct 14 15:26:04 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: directly connected 82.117.192.124 is address of one of three carp interfaces. I have 'demote carp' in bgpd.conf, so that master does not reclaim its master role before bgp routes are up. The question remains, why is it not reverting back to master once everything is ok? -- Marko Cupać https://www.mimar.rs
Re: [Bulk] Re: [Bulk] Re: openbsdstore: enable javascript and buy something or gtfo
On 15-10-2014 17:56, Kevin Chadwick wrote: The address bar is one of the only things you can trust when browsing a web page Provided your dns isn't spoofed. And you're are not being targeted with a mitm attack. And perhaps a few other things. But yeah, the address bar can normally be trusted. Get rid of the address bar! and allow javascript everywhere, you must work for Google;-) It's funny you said that, because the POODLE vulnerability released yesterday (ironically from Google), besides needing a mitm attack, uses javascript on the user's browser for it's attack vector. People need more proof that javascript is harmful? Cheers [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: carp not reverting to master
Please excuse typos, sent from my phone On 15 Oct 2014, at 19:13, Marko Cupać marko.cu...@mimar.rs wrote: On Thu, 02 Oct 2014 18:02:23 +0100 Andy a...@brandwatch.com wrote: Hi Try setting the advskew to a number greater than 200 and less then 254. This seems to be the most stable. For best practice our primary runs with carp and pfsync values of '1'. And the backup runs with carp and pfsync values of '2'. We do this for two reasons. 1) it is extremely stable! 2) We found that CARP master is almost random/unstable when both firewalls have the same value (esp '0'), because; When advbase is set to 0 the skew value alone is used to calculate how often advertisements are sent (the advertisement window) using this formula: Window in microseconds = advskew * 100 / 256 E.g. 100 * 100 / 256 = 390625us So it would take much to cause a flip.. Setting advbase to 1 on both is better as this is more stable if you want to have the same carp demote counters.. Good luck :) Andy Andy, thank you for the tip for increasing advskew value, I'm gonna try it out. I had failover on another pair of firewalls, this time external ones, running bgp. Carp is not reverting to master some 5 hours so far. On master, while down, carp is demoted, pfsync is not: pacija@bgp1:~ $ ifconfig -g carp carp: carp demote count 1 pacija@bgp1:~ $ ifconfig -g pfsync pfsync: carp demote count 0 On backup, while master, neither is demoted: pacija@bgp2:~ $ ifconfig -g carp carp: carp demote count 0 pacija@bgp2:~ $ ifconfig -g pfsync pfsync: carp demote count 0 In /var/log/messages on downed master, I can see there was some turbulence: Oct 14 15:21:19 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:21:19 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:21:22 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:21:22 bgp1 /bsd: carp2: state transition: BACKUP - MASTER Oct 14 15:22:52 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:22:52 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:22:53 bgp1 /bsd: carp3: state transition: MASTER - BACKUP Oct 14 15:23:02 bgp1 /bsd: carp3: state transition: BACKUP - MASTER Oct 14 15:23:03 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:23:03 bgp1 /bsd: carp2: state transition: BACKUP - MASTER Oct 14 15:23:41 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:23:41 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:23:41 bgp1 /bsd: carp3: state transition: MASTER - BACKUP Oct 14 15:23:54 bgp1 /bsd: carp3: state transition: BACKUP - MASTER Oct 14 15:23:56 bgp1 /bsd: carp2: state transition: BACKUP - MASTER Oct 14 15:23:56 bgp1 /bsd: carp1: state transition: BACKUP - MASTER Oct 14 15:26:04 bgp1 /bsd: carp2: state transition: MASTER - BACKUP Oct 14 15:26:04 bgp1 /bsd: carp1: state transition: MASTER - BACKUP Oct 14 15:26:04 bgp1 /bsd: carp3: state transition: MASTER - BACKUP And in /var/log/daemon there is also bgp flapping at that time: Oct 14 15:22:53 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: directly connected Oct 14 15:23:02 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: via 82.117.192.124 Oct 14 15:23:41 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: directly connected Oct 14 15:23:54 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: via 82.117.192.124 Oct 14 15:26:04 bgp1 bgpd[1380]: nexthop 82.117.192.124 now valid: directly connected Hi, You'll see these BGP messages as a result of the netstat -rn routing table changes when a box goes from master to backup or visa versa. When a box is the backup, access to the carp IP will be in state connected as the routing table with have a MAC address for the CARP IP on the physical connected interface (taking you to the master), but when the box is the master there will be no MAC for the IP as its a local IP, hence the via. I've always thought this problematic as this also causes issues with the BGP nexthop validation logic as when it's the master it considers the CARP IP not in the same broadcast domain as the subnet with the BGP peer. On old versions anyway, things may have changed.. 82.117.192.124 is address of one of three carp interfaces. I have 'demote carp' in bgpd.conf, so that master does not reclaim its master role before bgp routes are up. The question remains, why is it not reverting back to master once everything is ok? -- Marko Cupać https://www.mimar.rs
libressl.org broken link
I'm not sure where this sort of thing is supposed to be reported but the Project Goals link on libressl.org (http://libressl.org/goals.html) is giving me a 404 error.
Re: libressl.org broken link
Sigh, its sad when a project with that much potential has no goals. Hopefully its just a phase. Daniel Dyla wrote: I'm not sure where this sort of thing is supposed to be reported but the Project Goals link on libressl.org (http://libressl.org/goals.html) is giving me a 404 error.
Re: [Bulk] Re: Shadow TCP stacks
On Wed, Oct 15, 2014 at 4:47 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Sat, 11 Oct 2014 13:38:49 -0400 Ian Grant wrote: No, the pre-shared keys are communicated over the VPN, as are the keys which encrypt the VPN's own data as it appears in the actual TCP packets which carry the tunnel through which the VPN operates. Perhaps I have missed something but if you have a ssh tunnel or something then just put that in front of the service without increasing Moved to misc. Yes, you missed something: the point :-) The idea is that the existence of this entire 'ultranet' is undetectable by even someone snooping all national traffic. So a TCP port 80 connection looks to the snooper _exactly_ like an HTTP connection handshake. Only the ISN and the source address mark the connection as 'ultra' and take it into a back room where it connects to the real network. If the snooper tries to connecto to that port they the same HTTP service that all the other muggles see. Ian
Re: [Bulk] Re: Shadow TCP stacks
2014-10-16 2:22 GMT+02:00 Ian Grant ian.a.n.gr...@googlemail.com: Perhaps I have missed something but if you have a ssh tunnel or something then just put that in front of the service without increasing Moved to misc. Yes, you missed something: the point :-) The idea is that the existence of this entire 'ultranet' is undetectable by even someone snooping all national traffic. So a TCP port 80 connection looks to the snooper _exactly_ like an HTTP connection handshake. Only the ISN and the source address mark the Or a service on a port is invisible unless a magic SYN packet appears. Best Martin
Re: libressl.org broken link
Sigh, its sad when a project with that much potential has no goals. Hopefully its just a phase. Just a phase. New web pages are being written and commited now. Don't be such a web hipster :)
