Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=""` in rc.conf.local?
On 2015-01-28, James Ryland Miller wrote: > As a brand new OpenBSD user, I *love* how the flags work in rc.conf.local: > > "" says to me that the daemon is being called with no flags. Unfortunately you run into an inconsistency here, which occurs exactly because of this double-duty: "" actually means "use the default flags from the daemon_flags line in /etc/rc.d/somefile.rc".
Re: carp failover problem
On 2015-01-27, Christopher Barry wrote: > On Tue, 27 Jan 2015 12:01:37 -0500 > "Leclerc, Sebastien" wrote: >>/etc/hostname.carp0 >>advskew 0 carpdev em0 carppeer 192.168.3.10 pass secret1 state master >>vhid 1 inet 192.0.2.2/28 Maybe unrelated, but it's not usual to set "state master" like this. Also "inet" should normally be at the start of a line in hostname.if. Do things work if you use the default multicast, rather than carppeer? This mail was missing a few things. dmesg and ifconfig -A output would be useful for starters (then we don't have to wonder how netstart parsed your files). > Well, it's been many years since I ran carp, so I cannot actually help > with the carp config, but I can absolutely say that I have experienced a > lot of unexplainable weirdness with ProCurve switches, so I can > appreciate your suspicions there. I'll never buy another. Procurve switches have been working nicely for me in various setups involving carp etc. I've used various: 2626 2824 2510-24 4200vl 5300zl 2530-24g etc. Not saying it's impossible but other areas seem more likely.
Re: LibreSSL Official T-shirts
Op Thu, 29 Jan 2015 17:53:10 +0100 schreef OpenBSD Store Misc : Some new awesome LibreSSL T-shirts are available to help fund developments. You can see them on https://www.openbsdstore.com. Why not use Comic Sans? Or: "This T-shirt specifically designed to annoy web hipsters" -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Preserving unbound cache across reboots
Hi all,
I wrote two simple functions for rc.shutdown and rc.login that
save/restore unbound cache when the system is restarted. Since each
record has a relative TTL field, the cache can only be restored within
a short time window to avoid serving stale data to clients. I set this
window to 10 minutes; enough to survive a reboot, but not for any
extended downtime. Is there any interest in including this
functionality in the base OS (moved to /etc/rc)?
- Max
--- /var/backups/etc_rc.shutdown.currentMon Aug 4 21:03:16 2014
+++ /etc/rc.shutdownFri Jan 30 10:06:11 2015
@@ -8,3 +8,17 @@
powerdown=NO # set to YES for powerdown
# Add your local shutdown actions here.
+
+save_unbound_cache() {
+ local db=/var/db/unbound.cache
+ /etc/rc.d/unbound check || return
+ echo -n 'saving unbound cache: '
+ if unbound-control dump_cache > $db; then
+ chmod 0600 $db
+ echo 'done.'
+ else
+ rm -f $db
+ fi
+}
+
+save_unbound_cache
--- /var/backups/etc_rc.local.current Mon Aug 4 21:03:16 2014
+++ /etc/rc.local Fri Jan 30 10:07:00 2015
@@ -4,3 +4,17 @@
# can be done AFTER your system goes into securemode. For actions
# which should be done BEFORE your system has gone into securemode
# please see /etc/rc.securelevel.
+
+restore_unbound_cache() {
+ local db=/var/db/unbound.cache
+ test -s $db && /etc/rc.d/unbound check || return
+ echo -n 'restoring unbound cache: '
+ if [ $(($(date '+%s') - $(stat -qf '%m' $db))) -lt 600 ]; then
+ unbound-control load_cache < $db
+ else
+ echo 'failed (cache expired).'
+ fi
+ rm -f $db
+}
+
+restore_unbound_cache
Che Puffy t-shirt
Hi guys, I'd really like see a Che Puffy t-shirt available for purchase & there may hopefully be a possibility of it happening. Just wondering who'd like to see such a thing happen & would purchase one or more? If you're wondering what I'm referring to http://upload.wikimedia.org/wikipedia/en/2/25/LibreSSL_logo.jpg Sevan / Venture37
Re: Preserving unbound cache across reboots
Hi,
Maxim Khitrov wrote on Fri, Jan 30, 2015 at 10:22:23AM -0500:
> I wrote two simple functions for rc.shutdown and rc.login that
> save/restore unbound cache when the system is restarted. Since each
> record has a relative TTL field, the cache can only be restored within
> a short time window to avoid serving stale data to clients. I set this
> window to 10 minutes; enough to survive a reboot, but not for any
> extended downtime. Is there any interest in including this
> functionality in the base OS (moved to /etc/rc)?
The purpose of rebooting is to reset the system to a clean state,
so clearing caches looks like a feature rather than a bug. Given
that even "unbound-control reload" flushes the cache, a reboot
should certainly do that, too. So i wouldn't even recommend showing
this to people as something they might add to their local scripts
if they want to. It just seems wrong.
Also note that the unbound-control(8) manual explicitly marks
load_cache as a debugging feature and warns that it may cause wrong
data to be served. On top of that, the version of unbound(8) running
after the reboot might be newer than the version running before,
so compatibility is questionable as well, so your proposal is very
fragile at best.
Besides, even if the goal would be desirable, which it is not, my
feeling is that this code is too specialized for adding to the boot
scripts.
Yours,
Ingo
> --- /var/backups/etc_rc.shutdown.currentMon Aug 4 21:03:16 2014
> +++ /etc/rc.shutdownFri Jan 30 10:06:11 2015
> @@ -8,3 +8,17 @@
> powerdown=NO # set to YES for powerdown
>
> # Add your local shutdown actions here.
> +
> +save_unbound_cache() {
> + local db=/var/db/unbound.cache
> + /etc/rc.d/unbound check || return
> + echo -n 'saving unbound cache: '
> + if unbound-control dump_cache > $db; then
> + chmod 0600 $db
> + echo 'done.'
> + else
> + rm -f $db
> + fi
> +}
> +
> +save_unbound_cache
>
> --- /var/backups/etc_rc.local.current Mon Aug 4 21:03:16 2014
> +++ /etc/rc.local Fri Jan 30 10:07:00 2015
> @@ -4,3 +4,17 @@
> # can be done AFTER your system goes into securemode. For actions
> # which should be done BEFORE your system has gone into securemode
> # please see /etc/rc.securelevel.
> +
> +restore_unbound_cache() {
> + local db=/var/db/unbound.cache
> + test -s $db && /etc/rc.d/unbound check || return
> + echo -n 'restoring unbound cache: '
> + if [ $(($(date '+%s') - $(stat -qf '%m' $db))) -lt 600 ]; then
> + unbound-control load_cache < $db
> + else
> + echo 'failed (cache expired).'
> + fi
> + rm -f $db
> +}
> +
> +restore_unbound_cache
Re: Preserving unbound cache across reboots
On Fri, Jan 30, 2015 at 12:54 PM, Ingo Schwarze wrote: > Hi, > > Maxim Khitrov wrote on Fri, Jan 30, 2015 at 10:22:23AM -0500: > >> I wrote two simple functions for rc.shutdown and rc.login that >> save/restore unbound cache when the system is restarted. Since each >> record has a relative TTL field, the cache can only be restored within >> a short time window to avoid serving stale data to clients. I set this >> window to 10 minutes; enough to survive a reboot, but not for any >> extended downtime. Is there any interest in including this >> functionality in the base OS (moved to /etc/rc)? > > The purpose of rebooting is to reset the system to a clean state, > so clearing caches looks like a feature rather than a bug. Given > that even "unbound-control reload" flushes the cache, a reboot > should certainly do that, too. So i wouldn't even recommend showing > this to people as something they might add to their local scripts > if they want to. It just seems wrong. > > Also note that the unbound-control(8) manual explicitly marks > load_cache as a debugging feature and warns that it may cause wrong > data to be served. On top of that, the version of unbound(8) running > after the reboot might be newer than the version running before, > so compatibility is questionable as well, so your proposal is very > fragile at best. > > Besides, even if the goal would be desirable, which it is not, my > feeling is that this code is too specialized for adding to the boot > scripts. Fair enough, though I would note that this feature is available in pfSense, which is also using unbound. Some resolvers persist their cache to disk automatically, so it's not that strange of an idea. I wanted to share the code anyway for others who might be interested in doing the same thing. My thinking on this is that if the cache was valid before the reboot, there is no good reason to clear it two minutes later just because the kernel was upgraded. It creates a traffic spike and a noticeable performance hit for the clients, especially with DNSSEC enabled. An explicit "reload" is different because you do it when you change the unbound configuration. Version upgrades are easily handled and I've now added that to my scripts, so thanks for the suggestion.
Re: carp failover problem
Jan 30, 2015; 8:10am Stuart Henderson wrote : >>/etc/hostname.carp0 >>advskew 0 carpdev em0 carppeer 192.168.3.10 pass secret1 state master >>vhid 1 inet 192.0.2.2/28 >Maybe unrelated, but it's not usual to set "state master" like this. I know, it was not in the config at first, I added it to test. >Also "inet" should normally be at the start of a line in hostname.if. Fails miserably if I do it :( Only aliases get assigned to the interface, and a message indicates that the address cannot be assigned to the interface (I don't have the exact message, I rebooted after the failure, and it's not in the logs...) My config was like this : inet 192.0.2.2/28 advskew 0 carpdev em0 pass secret1 state master vhid 1 alias 192.0.2.3/32 I also tried with this, with the same result : inet 192.0.2.2/28 advskew 0 carpdev em0 pass secret1 state master vhid 1 alias 192.0.2.3/32 >Do things work if you use the default multicast, rather than carppeer? As you can see above, I removed the carppeer from the config. I had to add back the addresses manually to the carp interfaces, but then I got worst results : fw1 was master on all carp interfaces, but fw2 was backup on carp0 and carp2, and master on carp1 So I reverted to my previous configuration. I changed some pf rules yesterday (removed antispoof) and disabled sasyncd, and rebooted during the night. At least in the morning, everything was ok, but inspecting our monitoring system, here is what I found : Rebooted fw2 at 3h02, fw1 kept master state, but had downtime until 3h12 Rebooted fw1 at 3h15, got downtime until 4h10, fw1 got master state at 3h16, fw2 got backup state at the same time Thanks for your help >This mail was missing a few things. dmesg and ifconfig -A output would >be useful for starters (then we don't have to wonder how netstart parsed >your files). Fw1 : lo0: flags=8049 mtu 33144 priority: 0 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff00 em0: flags=8b43 mtu 1500 lladdr 00:25:90:f2:6e:9a priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.3.9 netmask 0xfffc broadcast 192.168.3.11 inet6 fe80::225:90ff:fef2:6e9a%em0 prefixlen 64 scopeid 0x1 em1: flags=8b43 mtu 1500 lladdr 00:25:90:f2:6e:9b priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.3.1 netmask 0xfff8 broadcast 192.168.3.7 inet6 fe80::225:90ff:fef2:6e9b%em1 prefixlen 64 scopeid 0x2 em2: flags=8b43 mtu 1500 lladdr 00:25:90:f2:6e:9c priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.3.13 netmask 0xfffc broadcast 192.168.3.15 inet6 fe80::225:90ff:fef2:6e9c%em2 prefixlen 64 scopeid 0x3 em3: flags=8843 mtu 1500 lladdr 00:25:90:f2:6e:9d priority: 0 media: Ethernet autoselect (1000baseT full-duplex,master,rxpause,txpause) status: active inet 192.168.3.17 netmask 0xfffc broadcast 192.168.3.19 inet6 fe80::225:90ff:fef2:6e9d%em3 prefixlen 64 scopeid 0x4 enc0: flags=41 priority: 0 groups: enc status: active tun0: flags=8051 mtu 1500 priority: 0 groups: tun status: active inet 10.233.0.1 --> 10.233.0.2 netmask 0x pfsync0: flags=41 mtu 1500 priority: 0 pfsync: syncdev: em3 syncpeer: 192.168.3.18 maxupd: 128 defer: off groups: carp pfsync pflog0: flags=141 mtu 33144 priority: 0 groups: pflog carp0: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:01 priority: 0 carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 0 carppeer 192.168.3.10 groups: carp egress status: master inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0x7 inet 192.0.2.2 netmask 0xfff0 broadcast 192.0.2.15 inet 192.0.2.3 netmask 0x inet 192.0.2.4 netmask 0x inet 192.0.2.5 netmask 0x carp1: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:02 priority: 0 carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 0 carppeer 192.168.3.4 groups: carp status: master inet6 fe80::200:5eff:fe00:102%carp1 prefixlen 64 scopeid 0x8 inet 192.168.3.6 netmask 0x carp2: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:03 priority: 0 carp: MASTER carpdev em2 vhid 3 advbase 1 advskew 0 carppeer 192.168.3.14 groups: carp status: master inet6 fe80::200:5eff:fe00:103%carp2 prefixlen 64 scopeid 0x9 inet 192.0.2.17 netmask 0xfff0 broadcast 192.0.2.31 inet 192.0.2.29 netmask 0x And Fw2 : lo0: flags=8049 mtu 32768 priority: 0 groups: lo inet6 ::1 prefixlen 128 inet6 fe80:
Re: Che Puffy t-shirt
On 2015-01-30, Sevan / Venture37 wrote: > Hi guys, > I'd really like see a Che Puffy t-shirt available for purchase & there > may hopefully be a possibility of it happening. > Just wondering who'd like to see such a thing happen & would purchase > one or more? > > If you're wondering what I'm referring to > http://upload.wikimedia.org/wikipedia/en/2/25/LibreSSL_logo.jpg > > Sevan / Venture37 > > I would. (And the 5.3 tshirt if they became available again..)
Re: Che Puffy t-shirt
On Fri, January 30, 2015 20:12, Sevan / Venture37 wrote: > Hi guys, > I'd really like see a Che Puffy t-shirt available for purchase & there > may hopefully be a possibility of it happening. > Just wondering who'd like to see such a thing happen & would purchase > one or more? +1 (or even 2) M size > > If you're wondering what I'm referring to > http://upload.wikimedia.org/wikipedia/en/2/25/LibreSSL_logo.jpg > > Sevan / Venture37
ath client issues
My legacy ThinkPad died so I've resurrected a legacy HP notebook to
replace it for the time being and the built-in ath can't see my 2.4GHz
SSIDs (behavior doesn't change when the SSID's channel changes).
While it does see my 5GHz SSID most of the time, connectivity is very
problematic and, when it eventually connects, there's a lot of packet
loss. FWIW, the AP is from Ruckus and all my varied wireless devices
connect to it without issue (this AP works better than my previous
Cisco AP, but this is the first time I've installed OpenBSD on this
notebook).
Any thoughts appreciated. The relevant details are below and the
dmesg contains information from a fresh reboot and nothing else was
done with ath. In the case below, connectivity to the AP failed to be
established. I can also provide the debug output when it occasionally
connects (I can see the association and 4-way handshake, but there's
nothing after that and packet loss varies greatly). c0:8a:de:1e:44:*
is the MAC of the AP.
$ cat hostname.ath0
debug
-powersave
nwid
wpakey
dhcp
$ cat dmesg.boot
OpenBSD 5.7-beta (GENERIC) #689: Wed Jan 28 15:28:23 MST 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) M processor 1600MHz ("GenuineIntel"
686-class) 1.60 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,EST,TM2,PERF
real mem = 2146779136 (2047MB)
avail mem = 2099380224 (2002MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 08/30/06, BIOS32 rev. 0 @ 0xf, SMBIOS rev.
2.3 @ 0xfa1ee (31 entries)
bios0: vendor Hewlett-Packard version "68BDD Ver. F.15" date 08/30/2006
bios0: Hewlett-Packard HP Compaq nc6000 (DQ880A#ABA)
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT
acpi0: wakeup devices C056(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 1 (C045)
acpiprt1 at acpi0: bus 2 (C056)
acpiprt2 at acpi0: bus 0 (C044)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: C16D, resource for C169
acpipwrres1 at acpi0: C13D, resource for C16E
acpipwrres2 at acpi0: C184, resource for C183
acpipwrres3 at acpi0: C18B, resource for C185
acpipwrres4 at acpi0: C195, resource for C193
acpipwrres5 at acpi0: C0E6, resource for C0AA
acpipwrres6 at acpi0: C20B, resource for C20F
acpipwrres7 at acpi0: C20C, resource for C210
acpipwrres8 at acpi0: C20D, resource for C211
acpipwrres9 at acpi0: C20E, resource for C212
acpitz0 at acpi0: critical temperature is 103 degC
acpitz1 at acpi0: critical temperature is 115 degC
acpitz2 at acpi0: critical temperature is 103 degC
acpibat0 at acpi0: C137 model "Primary" serial 31163 2004/02/06 type
LIon oem "Hewlett-Packard"
acpibat1 at acpi0: C136 not present
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: C139
acpibtn1 at acpi0: C138
acpivideo0 at acpi0: C0CF
bios0: ROM list: 0xc/0x1
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: Enhanced SpeedStep 1595 MHz: speeds: 1600, 1400, 1200, 1000, 800, 600 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82855PM Host" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xb000, size 0x1000
ppb0 at pci0 dev 1 function 0 "Intel 82855PM AGP" rev 0x03
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility M10" rev 0x00
drm0 at radeondrm0
radeondrm0: irq 10
uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x03: irq 10
uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x03: irq 10
uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x03: irq 10
ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x03: irq 10
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x83
pci2 at ppb1 bus 2
ath0 at pci2 dev 4 function 0 "Atheros AR5212" rev 0x01: irq 11
ath0: AR5213 5.6 phy 4.1 rf5111 1.7 rf2111 2.3 eeprom 3.4, WOR0W,
address 00:0b:cd:5a:28:bb
cbb0 at pci2 dev 6 function 0 "O2 Micro OZ711E0 CardBus" rev 0x00: irq 10
cbb1 at pci2 dev 6 function 1 "O2 Micro OZ711E0 CardBus" rev 0x00: irq 10
"O2 Micro OZ711Mx Misc" rev 0x00 at pci2 dev 6 function 2 not configured
cbb2 at pci2 dev 6 function 3 "O2 Micro OZ711E0 CardBus" rev 0x00: irq 10
bge0 at pci2 dev 14 function 0 "Broadcom BCM5705M Alt" rev 0x03,
BCM5705 A3 (0x3003): irq 11, address 00:08:02:de:d3:2d
brgphy0 at bge0 phy 1: BCM5705 10/100/1000baseT PHY, rev. 2
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 3 device 0 cacheline 0x0, lattimer 0x20
pcmcia0 at cardslot0
cardslot1 at cbb1 slot 1 flags 0
cardbus1 at cardslot1: bus 4 device 0 cacheline 0x0, lattimer 0x20
pcmcia1 at cardslot1
cardslot2 at cbb2 slot 2 flags 0
cardbus2 at cardslot2: bus 5 device 0 cacheline 0x0, lattimer 0x20
pcmcia2 at cardslot2
ichpcib0 at pci0 dev 31 function 0 "Intel 82801DBM LPC" rev 0x0
Re: carp failover problem
> Rebooted fw2 at 3h02, fw1 kept master state, but had downtime until 3h12 > Rebooted fw1 at 3h15, got downtime until 4h10, fw1 got master state at 3h16, > fw2 got backup state at the same time > Inspecting further my logs, I see that smtp services were functioning between wan and dmz during the downtime period. Our monitoring is done from the lan, so I suspect the 5300xl is causing the problem... Any thoughts? Thanks Sebastien
Re: What's wrong with script(1)?
On 2015-01-29 05:16 PM, openda...@hushmail.com wrote: Thanks, I had no idea. Would it be possible though to mention some use cases where the noise is necessary? Many thanks! O.D. Debugging bad terminal behaviour - bugs in either termcap(5), terminfo(5), curses(3), xterm(1), screen(1), tmux(1), vi(1), etc... anything where the non-visible output is actually the important part. -- -Adam Thompson athom...@athompso.net +1 (204) 291-7950 - cell +1 (204) 489-6515 - fax
Syslogd remote hostname
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hey everyone, I have a central rsyslog server and multiple rsyslog server sending him their log. Now I have an OpenBSD server with syslogd. But syslogd doesn't send his hostname to this central server. Is there a way to set hostname to send ? I saw some mails in a mailing list talking about that but that's a dev list. So I didn't get it at all. Could you help me ? - -- CHUNKZ.NET - dodgy DIYer and computer technician Bertrand Caplet, Flers (FR) Feel free to send encrypted/signed messages Key ID: FF395BD9 GPG FP: DE10 73FD 17EB 5544 A491 B385 1EDA 35DC FF39 5BD9 iQJKBAEBCgA0BQJUzBHmLRxCZXJ0cmFuZCBDYXBsZXQgPGJlcnRyYW5kLmNhcGxl dEBjaHVua3oubmV0PgAKCRAe2jXc/zlb2YRGD/0WqiKW3QeM2GwzQLB+KowI3K3L 2bCxH41DbH8lSTYhceuTS3kL14Weyex7ftNX0BpR04fy8QowDWIwgUXTVsVpfC79 weSjxOqE+vrSn4N5Hn20FzitTL5N4jPWkm5Ne8nuO++k5J1Uy9ZMiyzdKl8+pIrg 1UvJK5ducgnD7JV9GEN4nt9d0w4sNTqHHG2sGoe/zqJIJQFCrt0KpzBtm3IJSgGS u0DO2OpiZStJmfxqGJE4xA1bp+VxC4wTTK7wkNhQHS1NAl+n5GZ0g48wjAradrjD 1TFKCD2MssiPHrULkH8vKdzzAKZ7Ppiii4wU4TNxo1VIBqXOF3H8Dedc0i+Nnr4Y gtQS6MWU4/KByzLE5285sZMjTRk5zNZLYusXwz3cvTNrT7XsnlCG8X22oEIKcHv1 g+BxE5f3Ps1zB3W7Begdzym3P6oaa+6msQkVBEl3C7kbVTjihmuRTzZaYgtaW5HY +6bnAtdiE/NTuv4JCE+lpY9adFaCmn6gr3Wo4w8Sfhxt20N0HMHvgbJV1DorIsHr Z317hcCq06w9yqWbRrZ8sqT/sGvpmzFXrWF7WeA6Xpqvf3P8cUALVViLn7XVDCBs dRxbFzAcXX894NypfXu7TOARNUeA8+GpPbWarm1MO2CNtHHMUSY2mku5fHb2P/1d gSkzdkXuGl+fBJWLQA== =qLBk -END PGP SIGNATURE-
Re: carp failover problem
On Fri, 30 Jan 2015 17:18:07 -0500 "Leclerc, Sebastien" wrote: >> Rebooted fw2 at 3h02, fw1 kept master state, but had downtime until >> 3h12 Rebooted fw1 at 3h15, got downtime until 4h10, fw1 got master >> state at 3h16, fw2 got backup state at the same time >> > >Inspecting further my logs, I see that smtp services were functioning >between wan and dmz during the downtime period. Our monitoring is >done from the lan, so I suspect the 5300xl is causing the problem... >Any thoughts? > >Thanks > >Sebastien > the issue I had with Procurve switches was related to it's STP implementation. strange things were happening while trying to PXE boot a large number of Linux cluster nodes using gpxe. Swapping out the switch with a different brand solved the problem, and I never revisited it. if you can do a quick test on a different switch, that would at least rule that out as your issue. if not, try disabling STP and retest. -C
Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=""` in rc.conf.local?
On Fri, Jan 30, 2015 at 8:49 PM, Stuart Henderson wrote: > On 2015-01-28, James Ryland Miller wrote: >> As a brand new OpenBSD user, I *love* how the flags work in rc.conf.local: >> >> "" says to me that the daemon is being called with no flags. > > Unfortunately you run into an inconsistency here, which occurs exactly > because of this double-duty: "" actually means "use the default flags from > the daemon_flags line in /etc/rc.d/somefile.rc". > Which is half of what opendaddy is missing. I half-sympathize with his concerns. It _seems_ nice to have the bundle of patch cables all connected and ready, and one switch separate from the patch cable bundle to actually turn the box on and patch it in. "Seems" being the operational word, and the issue of where one is looking for the switch being, perhaps, the missed point? -- Joel Rees
Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=""` in rc.conf.local?
On Fri, Jan 30, 2015 at 5:49 AM, Stuart Henderson wrote: > On 2015-01-28, James Ryland Miller wrote: >> As a brand new OpenBSD user, I *love* how the flags work in rc.conf.local: >> >> "" says to me that the daemon is being called with no flags. > > Unfortunately you run into an inconsistency here, which occurs exactly > because of this double-duty: "" actually means "use the default flags from > the daemon_flags line in /etc/rc.d/somefile.rc". Yes, I understand that now. It still makes more sense to me the way it is currently implemented. -- James R. Miller
Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=""` in rc.conf.local?
On 2015/01/30 18:25, James Ryland Miller wrote: > On Fri, Jan 30, 2015 at 5:49 AM, Stuart Henderson > wrote: > > On 2015-01-28, James Ryland Miller wrote: > >> As a brand new OpenBSD user, I *love* how the flags work in rc.conf.local: > >> > >> "" says to me that the daemon is being called with no flags. > > > > Unfortunately you run into an inconsistency here, which occurs exactly > > because of this double-duty: "" actually means "use the default flags from > > the daemon_flags line in /etc/rc.d/somefile.rc". > > Yes, I understand that now. It still makes more sense to me > the way it is currently implemented. It does, until you really want no parameters whatsoever and need to use foo_flags=" " to work around it ;)
Re: Syslogd remote hostname
On Sat, Jan 31, 2015 at 12:21:11AM +0100, Bertrand Caplet wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hey everyone, > I have a central rsyslog server and multiple rsyslog server sending him their > log. Now I have an OpenBSD server with syslogd. But syslogd doesn't send his > hostname to this central server. > Is there a way to set hostname to send ? The syslogd(8) -h option may be what you are asking about.
Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=""` in rc.conf.local?
On Thu, 29 Jan 2015 07:53:13 -0500 Nick Holland wrote: >rsyncd_flags="" >slowcgi_flags= >unbound_flags="" am I understanding correctly that in the snippet above, slowcgi will not be started, while the other two (will|may) start with default flags? -- Regards, Christopher Barry Random geeky fortune: A chicken is an egg's way of producing more eggs.
Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=""` in rc.conf.local?
Hi,
Joel Rees wrote on Sat, Jan 31, 2015 at 09:17:09AM +0900:
> On Fri, Jan 30, 2015 at 8:49 PM, Stuart Henderson
> wrote:
>> Unfortunately you run into an inconsistency here, which occurs exactly
>> because of this double-duty: "" actually means "use the default flags
>> from the daemon_flags line in /etc/rc.d/somefile.rc".
The description of how it works is correct, but the double-duty
does not cause this quirk. For ports daemons, we have the same
logic ("" -> default flags, " " -> empty flags) even though there
is no double duty for ports, enabling/disabling being controlled
by the pkg_scripts variable.
Eliminating the double duty would not solve the problem of
distinguishing "default flags" and "no flags".
Keeping the double duty does not prevent solving the admittedly not
very intuitive distinction of "" and " ". For example, one could
redefine "" as "no flags" and use something like "DEFAULT" for
"default flags" - but that would make rc.conf.local(8) very ugly
("DEFAULT" on almost every line) and error-prone (easy to forget
putting "DEFAULT" there; defaults should be, well, the default,
without explicitly asking for them). One could also define something
like "NOFLAGS" to mean "no flags" without conflicting with the
existing "NO" - but that looks like a gratuitious change with no
functional advantage over " ". So i think we should just leave it
as it is.
> Which is half of what opendaddy is missing.
>
> I half-sympathize with his concerns. It _seems_ nice to have the
> bundle of patch cables all connected and ready, and one switch
> separate from the patch cable bundle to actually turn the box on and
> patch it in.
>
> "Seems" being the operational word, and the issue of where one is
> looking for the switch being, perhaps, the missed point?
If you maintain rc.conf.local(8) by hand, you can just comment out
the flags line and add flags=NO to disable a base daemon. That's
your master switch to throw without ripping out all your beautiful
patch cables.
If you use a configuration management tool to maintain configurations
across many machines, that's a job for the configuration management
tool, not for rc.conf.local(8). For that reason, ajacoutot@ is
adamant that rcctl(8) will always delete the flags from rc.conf.local(8)
when disabling a daemon.
Yours,
Ingo
Re: Wouldn't `daemon_enable=YES` make more sense than `daemon_flags=""` in rc.conf.local?
Hi Christopher, Christopher Barry wrote on Fri, Jan 30, 2015 at 07:45:31PM -0500: > On Thu, 29 Jan 2015 07:53:13 -0500 > Nick Holland wrote: >>rsyncd_flags="" >>slowcgi_flags= >>unbound_flags="" > am I understanding correctly No. > that in the snippet above, slowcgi will not be started, > while the other two (will|may) start with default flags? They will all start with default flags (assuming that rsyncd, which is a package daemon, is mentioned in pkg_scripts). To disable a base daemon (like slowcgi), you need slowcgi_flags=NO This is explained in rc.conf.local(8), by the way. Yours, Ingo
Re: carp failover problem
if you can do a quick test on a different switch, that would at least rule that out as your issue. if not, try disabling STP and retest That was my guess, using a trunk to link the vlan to an edge switch not affected by stp, and connecting the firewalls there. This way, the 5300xl won't have to detect which port is connected to the gateway (the 5300xl is a routing switch for the lan) Will try it during the weekend... Sebastien
Is there a daemon rollcall tool?
What I'm thinking of is a tool that would allow one to query whether a daemon is installed, and, for installed daemons, to query what the basic commands for status, start, and stop, are? I'm also thinking of a roll-register (or similar name) to call from the initialization scripts of daemons I want to be in the roll-call. The roll-register call's parameters could specify the daemon name and the commands that the rollcall tool would look up. I've been thinking of building such a tool, but don't want to dig in and find I'm duplicating effort. (Not that it should be a hard tool to build.) -- Joel Rees
Re: Is there a daemon rollcall tool?
Hi Joel, Joel Rees wrote on Sat, Jan 31, 2015 at 03:16:02PM +0900: > What I'm thinking of is a tool that would allow one to query > whether a daemon is installed, pkg_info(1) and ls /etc/rc.d/ > and, for installed daemons, to query what the > basic commands for status, start, and stop, are? The same for all of them, see rc.d(8). > I'm also thinking of a roll-register (or similar name) to call from > the initialization scripts of daemons I want to be in the roll-call. > The roll-register call's parameters could specify the daemon name and > the commands that the rollcall tool would look up. > > I've been thinking of building such a tool, but don't want to dig in > and find I'm duplicating effort. (Not that it should be a hard tool to > build.) I don't understand all you are saying here, but i suspect you would be duplicating rcctl(8). Yours, Ingo
