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