npppd radius on current jan 21
Hi,
I run in to a issue using npppd with radius. It look to me the parsing
of radius port info is not working.
I have: authentication section:
authentication RADIUS type radius {
authentication-server {
address 192.168.0.1 port 1812 secret hogehoge
}
accounting-server {
address 192.168.0.1 port 1813 secret hogehoge
}
}
If i start npppd and try to authenticate is starts communicating with
the radius server 192.168.0.1 on port 5127.
If i change port number to 1645 (old radius) i get 27910 ...
It really looks like there is a bug of memory corruption. Also i tried
for fun port 1 and got port 256 in tcpdump.
Also if
address 192.168.0.1 secret hogehoge
is used it completely does not talk to the radius server and in
/var/log/daemon you get a message like
npppd[]: connect() failed in radius_prepare_socket: Can't assign requested
address
Authenticating with localfile works fine and is tested.
I have looked at parse.y and serveral other items in
/usr/src/usr.sbin/npppd/npppd but my C is not up to it yet :(
Can someone point me in direction to solve this.
Note: It was working with the 5.1 release manual build and old
config style.
Regards
Robert
Re: npppd radius on current jan 21
Yasuoka forgot to commit his fix.
I have it working.
//maxim
On 30 jan 2013, at 11:54, Robert Blacquiere open...@blacquiere.nl wrote:
Hi,
I run in to a issue using npppd with radius. It look to me the parsing
of radius port info is not working.
I have: authentication section:
authentication RADIUS type radius {
authentication-server {
address 192.168.0.1 port 1812 secret hogehoge
}
accounting-server {
address 192.168.0.1 port 1813 secret hogehoge
}
}
If i start npppd and try to authenticate is starts communicating with
the radius server 192.168.0.1 on port 5127.
If i change port number to 1645 (old radius) i get 27910 ...
It really looks like there is a bug of memory corruption. Also i tried
for fun port 1 and got port 256 in tcpdump.
Also if
address 192.168.0.1 secret hogehoge
is used it completely does not talk to the radius server and in
/var/log/daemon you get a message like
npppd[]: connect() failed in radius_prepare_socket: Can't assign requested
address
Authenticating with localfile works fine and is tested.
I have looked at parse.y and serveral other items in
/usr/src/usr.sbin/npppd/npppd but my C is not up to it yet :(
Can someone point me in direction to solve this.
Note: It was working with the 5.1 release manual build and old
config style.
Regards
Robert
Re: vnd and softraid panic
On Wed, 30 Jan 2013, Eivind Evensen wrote: On Wed, Jan 23, 2013 at 02:33:16AM +1100, Joel Sing wrote: On Thu, 3 Jan 2013, Eivind Evensen wrote: On Mon, Dec 31, 2012 at 07:21:08PM +1100, Joel Sing wrote: On Mon, 31 Dec 2012, Eivind Evensen wrote: Hello. Trying to play around a bit with softraid using vnd reliably results in a panic when assembling the raid volume. I think the first time I tried this was around 4.9 so it's not something new. ... FWIW this should now be rectified in -current. I tried a snapshot downloaded on 21.th (OpenBSD 5.2-current (GENERIC) #17: Fri Jan 18 19:42:57 MST 2013) which produced the same results. I waited a few days in case the snapshot was too old and built from sources from yesterday, still giving the same results. I don't need such a setup so it's not a big deal, but here's output and dmesg in case it may be helpful: Thanks for the report. For some reason I thought you had tried using softraid crypto on a vnd and overlooked the fact that you were trying to use RAID 5 (and now RAID 1). To clarify, RAID 0, CONCAT and CRYPTO should all now work on top of a vnd - RAID 1, RAID 4 and RAID 5 will still break in the manner given below (panic related to active workunits). These disciplines require the same changes that I've made to the other three, however they're a little more complex and time consuming. I'll try to get to them fixed soon. root:skoeske dd if=/dev/zero of=disk1 bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 2.875 secs (36462177 bytes/sec) root:skoeske r disk1=disk2 dd if=/dev/zero of=disk2 bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 3.219 secs (32567739 bytes/sec) root:skoeske r disk2=disk3 dd if=/dev/zero of=disk3 bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 3.569 secs (29378164 bytes/sec) root:skoeske vnconfig vnd0 disk1 root:skoeske vnconfig vnd1 disk2 root:skoeske vnconfig vnd2 disk3 root:skoeske fdisk -iy vnd0 Warning CHS values out of bounds only saving LBA values Writing MBR at offset 0. root:skoeske fdisk -iy vnd1 Warning CHS values out of bounds only saving LBA values Writing MBR at offset 0. root:skoeske fdisk -iy vnd2 Warning CHS values out of bounds only saving LBA values Writing MBR at offset 0. root:skoeske printf a\n\n\n\nRAID\nw\nq\n\n | disklabel -E vnd0 Label editor (enter '?' for help at any prompt) partition: [a] offset: [128] size: [204672] FS type: [4.2BSD] No label changes. root:skoeske printf a\n\n\n\nRAID\nw\nq\n\n | disklabel -E vnd1 Label editor (enter '?' for help at any prompt) partition: [a] offset: [128] size: [204672] FS type: [4.2BSD] No label changes. root:skoeske printf a\n\n\n\nRAID\nw\nq\n\n | disklabel -E vnd2 Label editor (enter '?' for help at any prompt) partition: [a] offset: [128] size: [204672] FS type: [4.2BSD] No label changes. root:skoeske bioctl -c 1 -l /dev/vnd0a,/dev/vnd1a,/dev/vnd2a softraid0 sd0 at scsibus1 targ 1 lun 0: OPENBSD, SR RAID 1, 005 SCSI2 0/direct fixed sd0: 99MB, 512 bytes/sector, 204144 sectors softraid0: SR RAID 1 volume attached as sd0 panic: softraid0: sr_wu_init got active wu Stopped at Debugger+0x4: popl%ebp RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb trace Debugger(d08fcddc,f2087de8,d08d0da4,f2087de8,d0a7e540) at Debugger+0x4 panic(d08d0da4,d0f8c014,f2087dfc,d036ccf3,d0fedab8) at panic+0x5d sr_wu_init(d1055000,d0fedab8,f2087e3c,d1055a30,d1057f00) at sr_wu_init+0x73 sr_wu_put(d1055000,d0fedab8,f2087e3c,f2087e3c,d02030dd) at sr_wu_put+0x2f scsi_io_put(d1055a30,d0fedab8,8000,d0fedab8,d0fedab8) at scsi_io_put+0x19 scsi_xs_put(f2027000,f2027000,f2087e8c,d041de18,d1055000) at scsi_xs_put+0x37 sr_raid1_intr(d1065000,f1fabdc4,f17dc000,200,52000) at sr_raid1_intr+0x107 vndstrategy(d1065000,0,0,50,d1065000) at vndstrategy+0x70 spec_strategy(f2087f48,0,f2087f6c,d03f2c28,d1053d90) at spec_strategy+0x3d VOP_STRATEGY(d1065000,0,0,0,d0fedaf8) at VOP_STRATEGY+0x2c sr_startwu_callback(d1055000,d0fedab8,d02008bf,d1053d80,d03f2c50) at sr_startwu _callback+0x39 workq_thread(d1053d80) at workq_thread+0x36 Bad frame pointer: 0xd0bc8ed8 ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND *23369 0 0 0 70x100200srdis 19292 1571 6315 1000 30x80 ttyin less 1571 6315 6315 1000 30x88 pause sh 6315 30722 6315 1000 30x80 wait man 30722 11048 30722 1000 30x88 pause ksh 11048 2130 2130 1000 30x80 selectsshd 2130 1703 2130 0 30x80 poll sshd 2513 1 2513 0 20x80ksh 20983 1 20983 0 30x80 ttyin
OpenBSD 5.2 isakmpd sequence number problem
Hi Misc. I have two location A i B in my lab. In the location A there is isakmpd + carp + pfsync + sasync cluster on which there is installed OpenBSD 5.2 GENERIC.MP#339 i386 In the location B there is single OpenBSD 5.2 GENERIC#278 i386 installation. I have successfully established IPsec site-to-site connection between those two location and everything works fine until failover occurs in the cluster in location A ( I am using ifconfig -g carp carpdemote 128 command on the MASTER node to force the failover). When failover occurs pfsync increase sequence number on the new MASTER node by 16384 and cluster continues sending ESP packets with the new, increased value (for example if the last seq number on the old MASTER was sent with the value equal to 100 the new MASTER will send his first packet with seq number equal to 16484). On the OpenBSD 5.2 in location B, using tcpdump I am able to see ESP packets, with the new increased seq number, on the phisical interface, but I do not see any transmition on enc0 interface. The ESP packets are continuously going out of the cluster A and are continuously, silently dropped on OpenBSD in location B. All IPsec transmition is broken until new SA are established and seq number is reset to 0. I noted that starting from version OpenBSD 5.2 there is added support for Extended Sequence Numbers in the IPsec stack, so I go back with the version of OpenBSD on the server located in B from 5.2 to 5.1 GENERIC#160 i386, copied all configuration files to it, established once again IPsec beetwen A and B and from that point everything started to work perfectly. Now I am able to switch nodes in cluster A (ofcourse seq number, everytime I switch nodes is increased by 16384) and OpenBSD 5.1 in location B successfully decrypt and encrypt connection. I am able to see packets, going in both directions, on interface enc0 as well I am able to see ESP packet on phisical interface on OpenBSD 5.1. Is there bug in inplementation ESN in new IPsec stack on OpenBSD 5.2 or do I need additional configuration to make above setup to started to work properly. Please let me know if You need any additional information. Thanks for advise regards, Bartosz Brzozowski
CARP best practices
I finally got to deploy a CARP firewall cluster (HA failover for now). Using only the official OpenBSD.org documentation, everything went very smoothly even though the setup is not quite trivial (14 carp addresses on 6 active interfaces). I even got system replication going using rdist(1). While testing the failover and trying to ssh to a carp address I got hit with the server key mismatch; hence this email. What is considered best practice wrt ssh keys in a carp cluster -- install the same keys on all member nodes to avoid the alerts or just live with the occasional mismatch? Thanks in advance. OpenBSD 5.2-stable (GENERIC.MP) #0: Tue Jan 1 19:44:42 EST 2013
OpenBSD 5.2, high idle interrupts with stable amd64 bsd.mp
Running stable OpenBSD 5.2 and in the top I see high interrupt CPU utilization despite machine being idle. I am not sure if I should be worried or if the is some sort of bug. Please advise. dmesg: OpenBSD 5.2-stable (MERCURY.MP) #0: Sun Jan 27 21:58:30 JST 2013 r...@mercury.askyan.com:/usr/src/sys/arch/amd64/compile/MERCURY.MP real mem = 4149907456 (3957MB) avail mem = 4017065984 (3830MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb770 (76 entries) bios0: vendor American Megatrends Inc. version V1.1 date 07/30/2012 bios0: MSI MS-7808 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT ASF! acpi0: wakeup devices PS2K(S3) PS2M(S3) P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(S4) PWRB(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-3220T CPU @ 2.80GHz, 2794.06 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,XSAVE,AVX,NXE,LONG,LAHF cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-3220T CPU @ 2.80GHz, 2793.66 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,XSAVE,AVX,NXE,LONG,LAHF cpu1: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (P0P1) acpiprt2 at acpi0: bus 2 (RP01) acpiprt3 at acpi0: bus 3 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus 1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0: Failed to read resource settings acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: FN00 acpipwrres1 at acpi0: FN01 acpipwrres2 at acpi0: FN02 acpipwrres3 at acpi0: FN03 acpipwrres4 at acpi0: FN04 acpitz0 at acpi0: critical temperature is 92 degC acpitz1 at acpi0: critical temperature is 92 degC acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID0 acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 2794 MHz: speeds: 2800, 2700, 2600, 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Xeon E3-1200v2 Host rev 0x09 ppb0 at pci0 dev 1 function 0 vendor Intel, unknown product 0x0151 rev 0x09: msi pci1 at ppb0 bus 1 em0 at pci1 dev 0 function 0 Intel PRO/1000 PT (82571EB) rev 0x06: apic 2 int 16, address 00:15:17:21:2a:3e em1 at pci1 dev 0 function 1 Intel PRO/1000 PT (82571EB) rev 0x06: apic 2 int 17, address 00:15:17:21:2a:3f vga1 at pci0 dev 2 function 0 Intel HD Graphics 2500 rev 0x09 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp at vga1 not configured Intel 7 Series xHCI rev 0x04 at pci0 dev 20 function 0 not configured Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 2 int 16 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 28 function 0 Intel 7 Series PCIE rev 0xc4: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 1 Intel 7 Series PCIE rev 0xc4: msi pci3 at ppb2 bus 3 re0 at pci3 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E-VL (0x2c80), apic 2 int 17, address d4:3d:7e:35:62:7b rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5 ehci1 at pci0 dev 29 function 0 Intel 7 Series USB rev 0x04: apic 2 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xa4 pci4 at ppb3 bus 4 pcib0 at pci0 dev 31 function 0 Intel B75 LPC rev 0x04 ahci0 at pci0 dev 31 function 2 Intel 7 Series AHCI rev 0x04: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, M4-CT064M4SSD2, 040H SCSI3 0/direct fixed naa.500a075109196cd0 sd0: 61057MB, 512 bytes/sector, 125045424 sectors, thin ichiic0
Re: CARP best practices
On Wed, Jan 30, 2013 at 8:56 AM, System Administrator ad...@bitwise.net wrote: I finally got to deploy a CARP firewall cluster (HA failover for now). Using only the official OpenBSD.org documentation, everything went very smoothly even though the setup is not quite trivial (14 carp addresses on 6 active interfaces). I even got system replication going using rdist(1). While testing the failover and trying to ssh to a carp address I got hit with the server key mismatch; hence this email. What is considered best practice wrt ssh keys in a carp cluster -- install the same keys on all member nodes to avoid the alerts or just live with the occasional mismatch? Don't monitor SSH on the CARP address.
Re: CARP best practices
On 01/30/13 17:56, System Administrator wrote: I finally got to deploy a CARP firewall cluster (HA failover for now). Using only the official OpenBSD.org documentation, everything went very smoothly even though the setup is not quite trivial (14 carp addresses on 6 active interfaces). I even got system replication going using rdist(1). While testing the failover and trying to ssh to a carp address I got hit with the server key mismatch; hence this email. What is considered best practice wrt ssh keys in a carp cluster -- install the same keys on all member nodes to avoid the alerts or just live with the occasional mismatch? Is the ssh service one of the failover'able services? If it is, I believe it makes sense to share the keys (that's what I do anyway), alternatively you could have a second sshd configured with a shared HostKey. If it is not, I'd suggest letting sshd listen only on the host address and not on the carp address. /Alexander
Re: CARP best practices
On 30 Jan 2013 at 9:29, Johan Beisser wrote: On Wed, Jan 30, 2013 at 8:56 AM, System Administrator ad...@bitwise.net wrote: I finally got to deploy a CARP firewall cluster (HA failover for now). Using only the official OpenBSD.org documentation, everything went very smoothly even though the setup is not quite trivial (14 carp addresses on 6 active interfaces). I even got system replication going using rdist(1). While testing the failover and trying to ssh to a carp address I got hit with the server key mismatch; hence this email. What is considered best practice wrt ssh keys in a carp cluster -- install the same keys on all member nodes to avoid the alerts or just live with the occasional mismatch? Don't monitor SSH on the CARP address. Sorry, I'm not following you
Re: CARP best practices
On Wed, Jan 30, 2013 at 9:44 AM, System Administrator ad...@bitwise.net wrote: On 30 Jan 2013 at 9:29, Johan Beisser wrote: While testing the failover and trying to ssh to a carp address I got hit with the server key mismatch; hence this email. What is considered best practice wrt ssh keys in a carp cluster -- install the same keys on all member nodes to avoid the alerts or just live with the occasional mismatch? Don't monitor SSH on the CARP address. Sorry, I'm not following you Do you need to be able to ssh in to the firewall(s) via the CARP addresses? If the answer is yes, share the host keys between them. Or set up a redirect for the CARP addresses that goes to an alternate sshd port from port 22. Which uses the same host keys between the systems.
a possible rdist bug
To simplify maintenance of a carp firewall cluster, I setup system
replication with rdist(1), which works rather nicely with one notable
exception where cmdspecial fires even when there are no updated files.
It is the only instance of cmdspecial that misfires, it is also the
only instance that specifies globbing explicitly.
If this is known (or a feature), where is it documented? If this is a
bug, how do I go about tracking it down?
Relevant parts of Distfile:
(Yes, there is a bunch of pf.conf* files in addition to the main one --
each logical function of the firewall is in its own anchor loaded via a
separate pf.conf.anchor file.)
NOTIFY = ( root ad...@bitwise.net )
SAVED = ( \\.OLD\$ )# previously saved
TRASH = ( \\..*\\.swp\$ ~\$ ) # vim junk
USERS = ( /etc/{master.passwd,passwd,{,s}pwd.db} )
LOCAL = ( myname hostname.* ssh/ssh_host_*key* *.orig
disklabels dumpdates iked isakmpd rndc.key )
etc:
/etc - ${HOSTS}
install -compare,savetargets,updateperm,younger ;
notify ( ${NOTIFY} ) ;
except ( /etc/${LOCAL} ${USERS} ) ;
except_pat ( ${TRASH} ${SAVED} );
cmdspecial ( /etc/pf.conf* )/sbin/pfctl -f /etc/pf.conf ;
special /etc/relayd.conf/usr/sbin/relayctl reload ;
special /etc/syslogd.conf /etc/rc.d/syslogd reload ;
special /etc/inetd.conf /etc/rc.d/inetd reload ;
special /etc/ntpd.conf /etc/rc.d/ntpd restart ;
special /etc/ssh/sshd_config/usr/sbin/sshd -qt
/etc/rc.d/sshd reload
|| mv -f \$FILE.OLD \$FILE ;
mfs / mount_mfs(8) memory usage never shrinks?
Hello misc@, On OpenBSD 5.2 amd64, I'm storing 1.4GB of source code files and about 8x 150MB indices on an mfs partition, plus a gig or two of other automatically-generated files. If I run mount_mfs to load all this stuff from a regular drive, then the amount of memory used by mount_mfs(8) is about the same as the amount of Used disc space as reported by df(1). However, if I re-run index generation on an mfs, then after it's all done, memory usage by mount_mfs(8) noticeably exceeds Used disc space. As a workaround, I found that it's possible to copy all the files over to a new mount_mfs(8) process, after the indices have been re-generated, and the new process will at first have a much better memory usage, but this seems a little inconvenient and would also require a temporary burst of extra RAM to accomplish. Should I worry that on a 6GB partition that is only 4GB full, mount_mfs uses 5GB of memory after about 3GB of data gets mingled? Is mount_mfs swappable? If I end up being short on memory, would that extra 1GB from mount_mfs(8) be swapped out without affecting the performance? Or is there a way to run some kind of garbage collector or otherwise improve on an mfs memory use? % df -hi | fgrep -e Used -e mfs ; mount | fgrep mfs ; ps aux | fgrep -e USER -e mfs Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on mfs:18610 5.9G4.1G1.5G73% 439864 35770255% /grok/mfs mfs:18610 on /grok/mfs type mfs (asynchronous, local, nodev, nosuid, size=12582912 512-blocks) USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 18610 0.0 40.2 6291936 5048352 ?? IsSun07PM0:22.56 /sbin/mount_mfs -o rw -s6G -f2048 Cheers, Constantine.
Re: CARP best practices
Thank you Alexander (and Johan) for confirming what I kinda suspected -- use shared keys if it is a published (ie. failover required) service, otherwise bind only to dedicated address(es) using dedicated keys. On 30 Jan 2013 at 18:33, Alexander Hall wrote: On 01/30/13 17:56, System Administrator wrote: I finally got to deploy a CARP firewall cluster (HA failover for now). Using only the official OpenBSD.org documentation, everything went very smoothly even though the setup is not quite trivial (14 carp addresses on 6 active interfaces). I even got system replication going using rdist(1). While testing the failover and trying to ssh to a carp address I got hit with the server key mismatch; hence this email. What is considered best practice wrt ssh keys in a carp cluster -- install the same keys on all member nodes to avoid the alerts or just live with the occasional mismatch? Is the ssh service one of the failover'able services? If it is, I believe it makes sense to share the keys (that's what I do anyway), alternatively you could have a second sshd configured with a shared HostKey. If it is not, I'd suggest letting sshd listen only on the host address and not on the carp address. /Alexander
Re: CARP best practices
On Wed, Jan 30, 2013 at 09:29:42AM -0800, Johan Beisser wrote: On Wed, Jan 30, 2013 at 8:56 AM, System Administrator ad...@bitwise.net wrote: I finally got to deploy a CARP firewall cluster (HA failover for now). Using only the official OpenBSD.org documentation, everything went very smoothly even though the setup is not quite trivial (14 carp addresses on 6 active interfaces). I even got system replication going using rdist(1). While testing the failover and trying to ssh to a carp address I got hit with the server key mismatch; hence this email. What is considered best practice wrt ssh keys in a carp cluster -- install the same keys on all member nodes to avoid the alerts or just live with the occasional mismatch? Don't monitor SSH on the CARP address. Doesn't it depend on the purpose of this SSH service? If it is to manage individual boxes, then sshd should not listen on CARP ip address. If it is authentication for external users like authpf, file uploads, I would create another sshd instance which would flow between boxes sharing same key, still keeping individual sshd for each box. We were doing this for a file upload cluster, though that was not OpenBSD but the issue about the key and virtual ip is the same. jirib
Re: CARP best practices
On Wed, Jan 30, 2013 at 2:03 PM, Jiri B ji...@devio.us wrote: On Wed, Jan 30, 2013 at 09:29:42AM -0800, Johan Beisser wrote: Don't monitor SSH on the CARP address. Doesn't it depend on the purpose of this SSH service? If it is to manage individual boxes, then sshd should not listen on CARP ip address. Maybe. Or, perhaps you have a pool of servers that are essentially identical, and the failover service runs over SSH. In that case, having identical host keys would clear up that specific error. But, if a host fails out of the pool, you may not know right away. If it is authentication for external users like authpf, file uploads, I would create another sshd instance which would flow between boxes sharing same key, still keeping individual sshd for each box. We were doing this for a file upload cluster, though that was not OpenBSD but the issue about the key and virtual ip is the same. Yes. I covered that in a later email. But, that's defined by the function you're trying to use. The orginal complaint was I'm sshing in to the CARP address, and the host keys keep changing making SSH throw an error. Like any doctor who gets a complaint of it hurts when I do this!, the first answer is well, don't do that. Until you get more information, and can actually help the person out.
Re: mfs / mount_mfs(8) memory usage never shrinks?
On 2013-01-30, Constantine A. Murenin muren...@gmail.com wrote: Hello misc@, On OpenBSD 5.2 amd64, I'm storing 1.4GB of source code files and about 8x 150MB indices on an mfs partition, plus a gig or two of other automatically-generated files. If I run mount_mfs to load all this stuff from a regular drive, then the amount of memory used by mount_mfs(8) is about the same as the amount of Used disc space as reported by df(1). However, if I re-run index generation on an mfs, then after it's all done, memory usage by mount_mfs(8) noticeably exceeds Used disc space. As a workaround, I found that it's possible to copy all the files over to a new mount_mfs(8) process, after the indices have been re-generated, and the new process will at first have a much better memory usage, but this seems a little inconvenient and would also require a temporary burst of extra RAM to accomplish. Should I worry that on a 6GB partition that is only 4GB full, mount_mfs uses 5GB of memory after about 3GB of data gets mingled? Is mount_mfs swappable? If I end up being short on memory, would that extra 1GB from mount_mfs(8) be swapped out without affecting the performance? Or is there a way to run some kind of garbage collector or otherwise improve on an mfs memory use? % df -hi | fgrep -e Used -e mfs ; mount | fgrep mfs ; ps aux | fgrep -e USER -e mfs Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on mfs:18610 5.9G4.1G1.5G73% 439864 35770255% /grok/mfs mfs:18610 on /grok/mfs type mfs (asynchronous, local, nodev, nosuid, size=12582912 512-blocks) USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 18610 0.0 40.2 6291936 5048352 ?? IsSun07PM0:22.56 /sbin/mount_mfs -o rw -s6G -f2048 Cheers, Constantine. This is expected with mfs, don't set the filesystem to be larger than the amount of memory you would like it to use. I don't know how it behaves with swapping.
frontiernet mirror
I think the openbsd.mirror.frontiernet.net mirror is stale; its most recent packages are dated Jan 8th to me. Does anyone else see this? -- Sincerely, Andrew Ngo
Re: npppd with tun interface not work on i386?
Hi,
On Tue, 29 Jan 2013 20:20:24 +0100
csszep css...@gmail.com wrote:
I tried to start npppd with the default config with tun0 interface on
my Alix board:
I get the following error message:
# npppd -d
2013-01-29 19:54:38:NOTICE: Starting npppd pid=13464 version=5.0.0
2013-01-29 19:54:38:NOTICE: Load configuration
from='/etc/npppd/npppd.conf' successfully.
2013-01-29 19:54:38:ERR: tun0 delete ipaddress tun0 failed: Device not
configured
This was from a bug. I fixed it on cvs. Please update your source
code from cvs or apply a patch below.
Thank you for your report.
Index: privsep.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/privsep.c,v
retrieving revision 1.7
diff -u -p -r1.7 privsep.c
--- privsep.c 28 Sep 2012 23:46:00 - 1.7
+++ privsep.c 31 Jan 2013 02:03:36 -
@@ -463,7 +463,7 @@ priv_get_if_addr(const char *ifname, str
struct PRIVSEP_GET_IF_ADDR_RESP r;
a.cmd = PRIVSEP_GET_IF_ADDR;
- strlcpy(a.ifname, ifname, sizeof(ifname));
+ strlcpy(a.ifname, ifname, sizeof(a.ifname));
if ((retval = send(privsep_sock, a, sizeof(a), 0)) 0)
return retval;
if ((retval = recv(privsep_sock, r, sizeof(r), 0)) 0) {
@@ -488,7 +488,7 @@ priv_delete_if_addr(const char *ifname)
struct PRIVSEP_DEL_IF_ADDR_ARG a;
a.cmd = PRIVSEP_DEL_IF_ADDR;
- strlcpy(a.ifname, ifname, sizeof(ifname));
+ strlcpy(a.ifname, ifname, sizeof(a.ifname));
if ((retval = send(privsep_sock, a, sizeof(a), 0)) 0)
return retval;
retval = privsep_common_resp();
@@ -503,7 +503,7 @@ priv_set_if_addr(const char *ifname, str
struct PRIVSEP_SET_IF_ADDR_ARG a;
a.cmd = PRIVSEP_SET_IF_ADDR;
- strlcpy(a.ifname, ifname, sizeof(ifname));
+ strlcpy(a.ifname, ifname, sizeof(a.ifname));
a.addr = *addr;
if ((retval = send(privsep_sock, a, sizeof(a), 0)) 0)
return retval;
@@ -519,7 +519,7 @@ priv_get_if_flags(const char *ifname, in
struct PRIVSEP_GET_IF_FLAGS_RESP r;
a.cmd = PRIVSEP_GET_IF_FLAGS;
- strlcpy(a.ifname, ifname, sizeof(ifname));
+ strlcpy(a.ifname, ifname, sizeof(a.ifname));
if ((retval = send(privsep_sock, a, sizeof(a), 0)) 0)
return retval;
if ((retval = recv(privsep_sock, r, sizeof(r), 0)) 0) {
@@ -543,7 +543,7 @@ priv_set_if_flags(const char *ifname, in
struct PRIVSEP_SET_IF_FLAGS_ARG a;
a.cmd = PRIVSEP_SET_IF_FLAGS;
- strlcpy(a.ifname, ifname, sizeof(ifname));
+ strlcpy(a.ifname, ifname, sizeof(a.ifname));
a.flags = flags;
if ((retval = send(privsep_sock, a, sizeof(a), 0)) 0)
return retval;
Re: a possible rdist bug
On Wed, Jan 30, 2013 at 11:46 AM, System Administrator ad...@bitwise.net wrote: To simplify maintenance of a carp firewall cluster, I setup system replication with rdist(1), which works rather nicely with one notable exception where cmdspecial fires even when there are no updated files. It is the only instance of cmdspecial that misfires, it is also the only instance that specifies globbing explicitly. If this is known (or a feature), where is it documented? If this is a bug, how do I go about tracking it down? My inclination would be to leave the behavior (I can see it as useful, and actually wonder if I may have used this by accident in a past life) as is but have your command check the $FILES env variable and do nothing if it's empty: The cmdspecial command is similar to the special command, except it is executed only when the entire command is completed instead of after each file is updated. The list of files is placed in the FILES environment variable. Each file name in FILES is separated by a `:' (colon). Philip Guenther
Re: vnd and softraid panic
On Thu, Jan 31, 2013 at 12:20:14AM +1100, Joel Sing wrote: On Wed, 30 Jan 2013, Eivind Evensen wrote: On Wed, Jan 23, 2013 at 02:33:16AM +1100, Joel Sing wrote: On Thu, 3 Jan 2013, Eivind Evensen wrote: On Mon, Dec 31, 2012 at 07:21:08PM +1100, Joel Sing wrote: On Mon, 31 Dec 2012, Eivind Evensen wrote: Hello. Trying to play around a bit with softraid using vnd reliably results in a panic when assembling the raid volume. I think the first time I tried this was around 4.9 so it's not something new. ... FWIW this should now be rectified in -current. I tried a snapshot downloaded on 21.th (OpenBSD 5.2-current (GENERIC) #17: Fri Jan 18 19:42:57 MST 2013) which produced the same results. I waited a few days in case the snapshot was too old and built from sources from yesterday, still giving the same results. I don't need such a setup so it's not a big deal, but here's output and dmesg in case it may be helpful: Thanks for the report. For some reason I thought you had tried using softraid crypto on a vnd and overlooked the fact that you were trying to use RAID 5 (and now RAID 1). To clarify, RAID 0, CONCAT and CRYPTO should all now work on top of a vnd - RAID 1, RAID 4 and RAID 5 will still break in the manner given below (panic related to active workunits). These disciplines require the same changes that I've made to the other three, however they're a little more complex and time consuming. I'll try to get to them fixed soon. I see, thanks for the explanation. Eivind.
Re: CARP best practices
Please keep in mind that if the cluster should fail over while you are logged in via ssh, you will stop being logged in. On 2013 Jan 30 (Wed) at 15:50:14 -0500 (-0500), System Administrator wrote: :Thank you Alexander (and Johan) for confirming what I kinda suspected -- : use shared keys if it is a published (ie. failover required) service, :otherwise bind only to dedicated address(es) using dedicated keys. : :On 30 Jan 2013 at 18:33, Alexander Hall wrote: : : On 01/30/13 17:56, System Administrator wrote: : I finally got to deploy a CARP firewall cluster (HA failover for now). : Using only the official OpenBSD.org documentation, everything went very : smoothly even though the setup is not quite trivial (14 carp addresses : on 6 active interfaces). I even got system replication going using : rdist(1). : : While testing the failover and trying to ssh to a carp address I got : hit with the server key mismatch; hence this email. What is considered : best practice wrt ssh keys in a carp cluster -- install the same keys : on all member nodes to avoid the alerts or just live with the : occasional mismatch? : : Is the ssh service one of the failover'able services? : : If it is, I believe it makes sense to share the keys (that's what I do : anyway), alternatively you could have a second sshd configured with a : shared HostKey. : : If it is not, I'd suggest letting sshd listen only on the host address : and not on the carp address. : : /Alexander : -- We can defeat gravity. The problem is the paperwork involved.
