Re: recommended input methods?
On 2014-10-14 14:02:52, Joel Rees joel.r...@gmail.com wrote: What're the recommended input methods for Japanese and Spanish? I can't speak for anything officially recommended, but for Japanese at least, I use ports/inputmethods/anthy with ports/inputmethods/uim and it works well. The only complaint I have is that for some applications, namely xombrero and xfe, they either do not accept Japanese input unless their locale is specifically changed to Japanese, such as is the case with xombrero, which has the side-effect of changing all fonts to Japanese equivalents which makes for rather ugly font choices made for the Latin alphabet, or in the case of xfe where it just does not accept Japanese input at all no matter what I have tried. An xterm invoked as uxterm and started with a Japanese font allows me to have a terminal which supports the input and display of Japanese however, so I'm not quite sure what keeps xombrero and xfe from working out-of-the box like Firefox, editors/leafpad, and devel/geany, for example. If anyone knows, please let me know. I do have export XMODIFIERS=@im=uim export GTK_IM_MODULE=uim in my .xinitrc file. As far as Spanish is concerned, I simply have a dead-key set up in my .xinitrc setxkbmap -rules base -model pc105 -option compose:menu which sets the menu key in-between the right-ALT and right-CTRL keys to a dead-key such that pressing MENUa will produce an 'a' with umlauts. There are many other combinations as well. You could probably use uim to to switch between a Spanish layout, but it might be easier to do that with setxkbmap if you're planning on typing in Spanish a lot, and are not just in need of an occasional extended-Latin character. If you'll only occasionally need an extended-Latin character, then using a dead-key would probably be the easiest route. I'd be interested in what other people use for the above tasks as well. Hope this was helpful! -- Bryan
Re: recommended input methods?
On Tue, Oct 14, 2014 at 1:14 AM, Bryan Linton b...@shoshoni.info wrote: On 2014-10-14 14:02:52, Joel Rees joel.r...@gmail.com wrote: What're the recommended input methods for Japanese and Spanish? I can't speak for anything officially recommended, but for Japanese at least, I use ports/inputmethods/anthy with ports/inputmethods/uim and it works well. The only complaint I have is that for some applications, namely xombrero and xfe, they either do not accept Japanese input unless their locale is specifically changed to Japanese, such as is the case with xombrero, which has the side-effect of changing all fonts to Japanese equivalents which makes for rather ugly font choices made for the Latin alphabet, or in the case of xfe where it just does not accept Japanese input at all no matter what I have tried. An xterm invoked as uxterm and started with a Japanese font allows me to have a terminal which supports the input and display of Japanese however, so I'm not quite sure what keeps xombrero and xfe from working out-of-the box like Firefox, editors/leafpad, and devel/geany, for example. If anyone knows, please let me know. I do have export XMODIFIERS=@im=uim export GTK_IM_MODULE=uim in my .xinitrc file. As far as Spanish is concerned, I simply have a dead-key set up in my .xinitrc setxkbmap -rules base -model pc105 -option compose:menu which sets the menu key in-between the right-ALT and right-CTRL keys to a dead-key such that pressing MENUa will produce an 'a' with umlauts. There are many other combinations as well. You could probably use uim to to switch between a Spanish layout, but it might be easier to do that with setxkbmap if you're planning on typing in Spanish a lot, and are not just in need of an occasional extended-Latin character. If you'll only occasionally need an extended-Latin character, then using a dead-key would probably be the easiest route. I'd be interested in what other people use for the above tasks as well. Hope this was helpful! -- Bryan For spanish I also just map whatever key is more comfortable on each particular keyboard to dead_acute (for accents) - which is the most common used, and set a modifier key where I see fit and declare extra keysyms for those keycodes: $ cat .Xmodmap [...] keycode 10 = 1 exclam exclamdown keycode 20 = slash question questiondown keycode 25 = comma less guillemotleft keycode 26 = period greater guillemotright keycode 41 = u U udiaeresis Udiaeresis keycode 46 = n N ntilde Ntilde keycode 75 = dead_acute keycode 94 = Mode_switch [...] $
Re: recommended input methods?
Hi Bryan, Bryan Linton writes: I can't speak for anything officially recommended, but for Japanese at least... (snip) As far as Spanish is concerned... (snip) I'd be interested in what other people use for the above tasks as well. For typing non-ASCII characters, I use a compose key (see Compose(5)). $ setxkbmap -option compose:ralt With XCompose you can remap your dead key sequences as much as you like too, since they're just extra compose keys. Works great for European languages with occasional accents as well as arbitrary UTF-8 symbols which I end up using very often. Multi_key comma c : ç Multi_key grave e : è Multi_key apostrophe e : é Multi_key asciicircum e : ê Multi_key quotedbl e : ë Multi_key asciitilde n : ñ Multi_key asterisk G : Γ Multi_key minus l : → Multi_key plus minus : ± And so on. Sadly, this isn't really suitable for a language like Japanese that really needs a true IME. yasuoka@ has suggested uim/anthy in the past (http://yasuoka.net/~yasuoka/openbsd-desktop.html), and I haven't seen anyone suggest an alternate method for Japanese input. It beats typing romaji into Google Translate. -- Anthony J. Bentley
NetMap in OpenBSD
NetMap (http://info.iet.unipi.it/~luigi/netmap/) in OpenBSD would be a great idea. It's a simple API for solving an important problem, at least its core parts. Is OBSD's kernel structure suited as it is for NetMap? What's the interest out there for NetMap on OBSD? Thanks, Mikael
Re: NetMap in OpenBSD
* Mikael mikael.tr...@gmail.com [2014-10-14 10:24]: NetMap (http://info.iet.unipi.it/~luigi/netmap/) in OpenBSD would be a great idea. for what? to create even more broken userland networking stuff? We kinda like our stack. What's the interest out there for NetMap on OBSD? roughly somewhere between 0 and zero. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
cvs update: move away any file; it is in the way
Hi there, I am puzzled with a strange behaviour of CVS. In my .profile I have PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/ CVSROOT=anon...@ftp.hostserver.de:/cvs export PKG_PATH CVSROOT Now when updating e.g. /usr/src I get the following: /usr/src $ sudo cvs -q up -Pd cvs update: move away bin/ln/Makefile; it is in the way C bin/ln/Makefile cvs update: move away bin/ln/ln.1; it is in the way C bin/ln/ln.1 cvs update: move away bin/ln/ln.c; it is in the way C bin/ln/ln.c cvs update: move away bin/ln/symlink.7; it is in the way C bin/ln/symlink.7 This goes on like this for any file in /usr/src. Is this expected behaviour??? I doubt it ... dmesg and sysctl -all below. Any other input needed to investigate further? Anybody any ideas? (Beside deleting the sources and GETing a fresh checkout?) TIA. Cheers, STEFAN OpenBSD 5.6-current (GENERIC.MP) #415: Mon Oct 13 16:19:37 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3203203072 (3054MB) avail mem = 3109289984 (2965MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO version 79ETC9WW (2.09 ) date 12/22/2006 bios0: LENOVO 2007VG2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1994.60 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,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1994.33 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,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 92P1139 serial 2887 type LION oem Panasonic acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 1994 MHz: speeds: 2000, 1667, 1333, 1000 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82945GM PCIE rev 0x03: msi pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 0 function 0 ATI Radeon Mobility X1300 M52-64 rev 0x00 drm0 at radeondrm0 radeondrm0: apic 1 int 16 azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog Devices AD1981HD audio0 at azalia0 ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: msi pci2 at ppb1 bus 2 em0 at pci2 dev 0 function 0 Intel 82573L rev 0x00: msi, address 00:15:58:81:15:fb ppb2 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: msi pci3 at ppb2 bus 3 wpi0 at pci3 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: msi, MoW2, address 00:19:d2:85:6f:4d ppb3 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: msi pci4 at ppb3 bus 4 ppb4 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: msi pci5 at ppb4 bus 12 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 16 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 1 int 17 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 1 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 1 int 19 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb5 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2 pci6 at ppb5
Re: NetMap in OpenBSD
Dear Henning, Thank you for your thoughtful response. 2014-10-14 11:02 GMT+02:00 Henning Brauer hb-open...@ml.bsws.de: * Mikael mikael.tr...@gmail.com [2014-10-14 10:24]: NetMap (http://info.iet.unipi.it/~luigi/netmap/) in OpenBSD would be a great idea. We kinda like our stack. Of course, OBSD has a very good stack as it is, but it has no NetMap functionality i.e. there's no way for a userland application to do high speed packet-level IO. for what? There is a whole world of need of network monitoring and manipulation and other specialized networking software. The benefit with doing this on OBSD is that it's more robust than other systems and at least in my world that's hard currency. Chris got NetMap to compile on OBSD though I have no clue if/how well present subsystems deliver for it. Mikael
Re: cvs update: move away any file; it is in the way
Hi Stefan,
Stefan Wollny wrote on Tue, Oct 14, 2014 at 02:25:04PM +0200:
I am puzzled with a strange behaviour of CVS.
In my .profile I have
PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/
CVSROOT=anon...@ftp.hostserver.de:/cvs
export PKG_PATH CVSROOT
When updating a tree, there are two places where cvs(1) looks for
the CVSROOT that applies to each directory: (1) In the CVS/Root
file of the directory, if any and (2) in the CVSROOT environment
variable or the cvs -d command line option. If (1) and (2) mismatch,
you get conflicts for all affected files. Note that your .profile
shown above may or may not have influenced what was put into some
CVS/Root files in the past and may or may not have influenced your
current CVSROOT setting in the environment: .profile is somewhat
unrelated to your problem.
Now when updating e.g. /usr/src I get the following:
/usr/src $ sudo cvs -q up -Pd
cvs update: move away bin/ln/Makefile; it is in the way
C bin/ln/Makefile
cvs update: move away bin/ln/ln.1; it is in the way
C bin/ln/ln.1
cvs update: move away bin/ln/ln.c; it is in the way
C bin/ln/ln.c
cvs update: move away bin/ln/symlink.7; it is in the way
C bin/ln/symlink.7
This goes on like this for any file in /usr/src.
Is this expected behaviour??? I doubt it ...
It really depends on what your are actually doing.
Your first step should be to figure out the state of your tree:
$ find /usr/src -path \*/CVS/Root -print -exec cat {} \;
Do not post the result because it is likely very long.
If all those files have identical content, you can fix your problem
by simply running against that server again (set CVSROOT in your
*current* environment - not .profile - or run cvs with -d).
If those files have *different* content, you need to figure out
whether you did that on purpose or accidentally. If you did that
on purpose and have a CVS/Root file in each directory, simply
using these files by unsetting the CVSROOT environment variable
may be enough - but note that will update different parts of the
tree against different servers.
I doubt you did it on purpose or you wouldn't be asking this question.
If you did *not* do this on purpose, removing the CVS/Root files
is likely to solve your problem:
$ find /usr/src -path \*/CVS/Root -print -exec rm {} \;
Obviously, do *NOT* do that in a tree where you intentionally
mixed content from different servers, or where you might forget
which servers parts of it came from. Also, note that short of
manually recreating CVS/Root files in all directories, you will
never again be able to use a tree where you did that without
having CVSROOT set or specifying cvs -d.
After running the removal, simply set CVSROOT to the server you
want and cvs up -dP away. Note that some CVS/Root files will
reappear in the future, but only in newly created directories.
Beside deleting the sources and GETing a fresh checkout?
In case you are unsure about the state of your tree, for example
if you think you ran various commands of unknown effect without
knowing what you were doing, and in case it is important that the
tree be reliable, for example because you want to build releases
from it that you want to run in production, that might be advisable.
In case you are sure that the only bad thing you did was running
cvs up against varying (as opposed to untrusted!) servers and nothing
except CVS/Root files is corrupt, that is not needed. It is your
call to decide whether you still trust your tree. Only you know
what you did to it, or if you do not, well, that's a data point,
too...
Yours,
Ingo
Re: NetMap in OpenBSD
On Tue, Oct 14, 2014 at 8:55 AM, Mikael mikael.tr...@gmail.com wrote: Dear Henning, Thank you for your thoughtful response. 2014-10-14 11:02 GMT+02:00 Henning Brauer hb-open...@ml.bsws.de: * Mikael mikael.tr...@gmail.com [2014-10-14 10:24]: NetMap (http://info.iet.unipi.it/~luigi/netmap/) in OpenBSD would be a great idea. We kinda like our stack. Of course, OBSD has a very good stack as it is, but it has no NetMap functionality i.e. there's no way for a userland application to do high speed packet-level IO. for what? There is a whole world of need of network monitoring and manipulation and other specialized networking software. The benefit with doing this on OBSD is that it's more robust than other systems and at least in my world that's hard currency. Chris got NetMap to compile on OBSD though I have no clue if/how well present subsystems deliver for it. Mikael IMHO netmap is for hypervisor, OpenBSD is not an hypervisor. -- - () ascii ribbon campaign - against html e-mail /\
Re: NetMap in OpenBSD
* Mikael mikael.tr...@gmail.com [2014-10-14 14:57]: 2014-10-14 11:02 GMT+02:00 Henning Brauer hb-open...@ml.bsws.de: * Mikael mikael.tr...@gmail.com [2014-10-14 10:24]: NetMap (http://info.iet.unipi.it/~luigi/netmap/) in OpenBSD would be a great idea. We kinda like our stack. Of course, OBSD has a very good stack as it is, but it has no NetMap functionality yeah, and that is good. netmap bypasses teh stack and you look at reimplementing the stack in userland, repeating mistakes, bugs and whatnot from many decades. i.e. there's no way for a userland application to do high speed packet-level IO. there are plenty of methods actually. userland reimplementing the stack for the sake of speed is beyond idiotic. i rather spend the time to make the stack even faster than it already is. There is a whole world of need of network monitoring and manipulation and other specialized networking software. I read a collection of buzzwords with nothing specific. A solution in dire need of a problem. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: NetMap in OpenBSD
2014-10-14 16:15 GMT+02:00 Henning Brauer hb-open...@ml.bsws.de: Of course, OBSD has a very good stack as it is, but it has no NetMap functionality yeah, and that is good. netmap bypasses teh stack and you look at reimplementing the stack in userland, repeating mistakes, bugs and whatnot from many decades. i.e. there's no way for a userland application to do high speed packet-level IO. there are plenty of methods actually. Like what? userland reimplementing the stack[...] I didn't necessarily/specifically suggest that. There is a whole world of need of network monitoring and manipulation and other specialized networking software. I read a collection of buzzwords with nothing specific. A solution in dire need of a problem. Will be more clear on this one following your response. Last for completing reflections - Most devices in a system can be accessed with good performance from userland as it is now, for instance block devices, USB, serial ports, video and audio. Ethernet is a rare exception and NetMap solved this in a neat way - Prior to NetMap, those who wanted to make high-performance ethernet IO in userland would run their app as root and effectively implement NIC hardware drivers in userland. NetMap generalized this entire problem to one hardware-agnostic interface.
Re: cvs update: move away any file; it is in the way
Hi Ingo!
Thank you very, very much for your valuable, in-depth answer and advice!
I have issues with the system loosing it's routes. Because of this I had
tried several mirror sites and must have caught the divergent entries
doing so. Your advice solved the problem. Thanks again! Cheers,STEFAN
Gesendet: Dienstag, 14. Oktober 2014 um 15:24 Uhr
Von: Ingo Schwarze schwa...@usta.de
An: Stefan Wollny stefan.wol...@web.de
Cc: openbsd-misc misc@openbsd.org
Betreff: Re: cvs update: move away any file; it is in the wayHi Stefan,
Stefan Wollny wrote on Tue, Oct 14, 2014 at 02:25:04PM +0200:
I am puzzled with a strange behaviour of CVS.
In my .profile I have
PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/
CVSROOT=anon...@ftp.hostserver.de:/cvs
export PKG_PATH CVSROOT
When updating a tree, there are two places where cvs(1) looks for
the CVSROOT that applies to each directory: (1) In the CVS/Root
file of the directory, if any and (2) in the CVSROOT environment
variable or the cvs -d command line option. If (1) and (2) mismatch,
you get conflicts for all affected files. Note that your .profile
shown above may or may not have influenced what was put into some
CVS/Root files in the past and may or may not have influenced your
current CVSROOT setting in the environment: .profile is somewhat
unrelated to your problem.
Now when updating e.g. /usr/src I get the following:
/usr/src $ sudo cvs -q up -Pd
cvs update: move away bin/ln/Makefile; it is in the way
C bin/ln/Makefile
cvs update: move away bin/ln/ln.1; it is in the way
C bin/ln/ln.1
cvs update: move away bin/ln/ln.c; it is in the way
C bin/ln/ln.c
cvs update: move away bin/ln/symlink.7; it is in the way
C bin/ln/symlink.7
This goes on like this for any file in /usr/src.
Is this expected behaviour??? I doubt it ...
It really depends on what your are actually doing.
Your first step should be to figure out the state of your tree:
$ find /usr/src -path \*/CVS/Root -print -exec cat {} \;
Do not post the result because it is likely very long.
If all those files have identical content, you can fix your problem
by simply running against that server again (set CVSROOT in your
*current* environment - not .profile - or run cvs with -d).
If those files have *different* content, you need to figure out
whether you did that on purpose or accidentally. If you did that
on purpose and have a CVS/Root file in each directory, simply
using these files by unsetting the CVSROOT environment variable
may be enough - but note that will update different parts of the
tree against different servers.
I doubt you did it on purpose or you wouldn't be asking this question.
If you did *not* do this on purpose, removing the CVS/Root files
is likely to solve your problem:
$ find /usr/src -path \*/CVS/Root -print -exec rm {} \;
Obviously, do *NOT* do that in a tree where you intentionally
mixed content from different servers, or where you might forget
which servers parts of it came from. Also, note that short of
manually recreating CVS/Root files in all directories, you will
never again be able to use a tree where you did that without
having CVSROOT set or specifying cvs -d.
After running the removal, simply set CVSROOT to the server you
want and cvs up -dP away. Note that some CVS/Root files will
reappear in the future, but only in newly created directories.
Beside deleting the sources and GETing a fresh checkout?
In case you are unsure about the state of your tree, for example
if you think you ran various commands of unknown effect without
knowing what you were doing, and in case it is important that the
tree be reliable, for example because you want to build releases
from it that you want to run in production, that might be advisable.
In case you are sure that the only bad thing you did was running
cvs up against varying (as opposed to untrusted!) servers and nothing
except CVS/Root files is corrupt, that is not needed. It is your
call to decide whether you still trust your tree. Only you know
what you did to it, or if you do not, well, that's a data point,
too...
Yours,
Ingo
problem with CARP+VLAN+OpenBSD 5.5
Hello,
I am experiencing some problems with OpenBSD 5.5, specifically with CARP
and VLAN.
My setup is: 2 Dell R415 servers, MASTER (system-1)/BACKUP (system-2)
with 8 vlan interfaces (2 WAN + 6 LAN) + 49 carp interfaces (40 WAN + 9
LAN) + pfsync interface + pf configured with several rules. Switching is
provided by 4 Dell 5524 (two for the LAN interfaces, two for the WAN
interfaces).
sw-dmz-1-sw-dmz-2
||
system-1pfsync---system-2
||
sw-lan-1-sw-lan-2
On the switches, ports are configured a follows:
interface gigabitethernet1/0/1
spanning-tree portfast
switchport mode trunk
This is what happens: if system-1 is rebooted, system-2 becomes the new
MASTER. When system-1 comes back, some carp interfaces (randomly, even
from different physical interfaces) on system-2 stay in MASTER state, so
I have a kind of split brain.
All of the above didn't happens with OpenBSD 5.4, so I can't figure out
where the problem is.
For debugging, I've removed 2 switches, so now I have only one switch
per interface.
I've noticed that if I turn off PF, the configuration works perfectly.
I then tried with a simpler configuration of pf (pass quick in, pass
quick out), and again it doesn't works, so the problem seems to be with pf.
I've noticed that when the split is ongoing, with tcpdump I can see
advertisement packet from both of servers, as if they are ignoring each
other.
I tried to remove some carp interface, then add them again one at a
time, and I discovered that when I have 19 carp interfaces, the
behaviour described above starts again.
When the split is ongoing, if I run ksh /etc/netstart carpXX on
system-1, system-2 switch the same interface in BACKUP mode.
This is my test configuration (not patched, but in the production
environment is patched to the last errata release):
# uname -a (both machines)
OpenBSD system-1.my.domain 5.5 GENERIC#271 amd64
# grep carp /etc/sysctl.conf (both machines)
net.inet.carp.allow=1
net.inet.carp.preempt=1
net.inet.carp.log=7
# ifconfig -g carp (both machines)
carp: carp demote count 0
# cat /etc/pf.conf (both machines)
set skip on { lo0 em0 }
pass quick proto { carp pfsync }
pass in quick
pass out quick
This is an example of how I configured interfaces on the servers (carp5):
# carp5 system-1
inet 192.168.26.17 255.255.255.240 192.168.26.31 vhid 125 carpdev vlan3
pass password advskew 10
# carp5 system-2
inet 192.168.26.17 255.255.255.240 192.168.26.31 vhid 125 carpdev vlan3
pass password advskew 200
And this is vlan3:
inet 192.168.26.29 255.255.255.240 NONE vlan 3 vlandev bnx1
In bnx0 and bnx1 (vlan root interfaces) I've just put up.
# pfsync0 system-1
up syncdev em0 syncpeer 10.10.26.4 defer
# pfsync0 system-2
up syncdev em0 syncpeer 10.10.26.3 defer
# /etc/hostname.em0 system-1
inet 10.10.26.3 255.255.255.0 NONE
# /etc/hostname.em0 system-2
inet 10.10.26.4 255.255.255.0 NONE
Anyone can help? This issue is driving me crazy
Following: dmesg from system-1 (system-2 is pretty the same, except for
interface macaddress).
TIA
OpenBSD 5.5 (GENERIC) #271: Wed Mar 5 09:31:16 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 17136455680 (16342MB)
avail mem = 16671719424 (15899MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdf79c000 (63 entries)
bios0: vendor Dell Inc. version 2.0.2 date 10/22/2012
bios0: Dell Inc. PowerEdge R415
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT
EINJ IV__ SRAT SLIT SSDT TCPA
acpi0: wakeup devices PCI0(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX9(S5) PEXB(S5)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Opteron(tm) Processor 4238 , 3300.54 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 6MB 64b/line 64-way L3 cache
cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully
associative
cpu0: DTLB 32 4KB entries fully associative, 32 4MB entries fully
associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at
host(1) prints errors to STDOUT
$ host loopy.loo.found.not; print $? Host loopy.loo.found.not not found: 3(NXDOMAIN) 1 $ host loopy.loo.found.not /dev/null; print $? 1 $ host loopy.loo.found.not 2/dev/null; print $? Host loopy.loo.found.not not found: 3(NXDOMAIN) 1 There's a printf at line 429 of /usr/src/usr.sbin/bind/bin/dig/host.c Line 569's printf may also be going to STDOUT. Maybe others Successful output to STDOUT: $ host www.example.org; print $? www.example.org has address 93.184.216.119 www.example.org has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7 0 $ host www.example.org /dev/null; print $? 0
Re: host(1) prints errors to STDOUT
Unfortunately host is maintained upstream, in the bind codebase, by ISC. You should file your bug report there, because that is the right way to get change into the ecosystem. We could fix it here, and be different, then there will be even more problems. (Unfortunately, I expect them to mumble something like oops and then backwards compatibility, which basically is the modern way of of once a bug goes into the ecosystem, we stand behind it and support it fully. $ host loopy.loo.found.not; print $? Host loopy.loo.found.not not found: 3(NXDOMAIN) 1 $ host loopy.loo.found.not /dev/null; print $? 1 $ host loopy.loo.found.not 2/dev/null; print $? Host loopy.loo.found.not not found: 3(NXDOMAIN) 1 There's a printf at line 429 of /usr/src/usr.sbin/bind/bin/dig/host.c Line 569's printf may also be going to STDOUT. Maybe others Successful output to STDOUT: $ host www.example.org; print $? www.example.org has address 93.184.216.119 www.example.org has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7 0 $ host www.example.org /dev/null; print $? 0
Re: problem with CARP+VLAN+OpenBSD 5.5
On 14/10/14 17:03, Fede wrote:
Hello,
I am experiencing some problems with OpenBSD 5.5, specifically with
CARP and VLAN.
My setup is: 2 Dell R415 servers, MASTER (system-1)/BACKUP (system-2)
with 8 vlan interfaces (2 WAN + 6 LAN) + 49 carp interfaces (40 WAN +
9 LAN) + pfsync interface + pf configured with several rules.
Switching is provided by 4 Dell 5524 (two for the LAN interfaces, two
for the WAN interfaces).
Why do you have so many CARP interfaces?
Generally it's good practice to have one CARP interface per broadcast
domain / VLAN etc, and have all your alias IP addresses defined in that
one CARP interface.
NB; when adding;
inet alias ipaddress mask Always set the mask for each alias to
255.255.255.255
This is apparently correct according to the devs. cite; something I was
told a long time ago even though you'll get a spurious error in the logs
at fail-over time..
sw-dmz-1-sw-dmz-2
||
system-1pfsync---system-2
||
sw-lan-1-sw-lan-2
On the switches, ports are configured a follows:
interface gigabitethernet1/0/1
spanning-tree portfast
switchport mode trunk
This is what happens: if system-1 is rebooted, system-2 becomes the
new MASTER. When system-1 comes back, some carp interfaces (randomly,
even from different physical interfaces) on system-2 stay in MASTER
state, so I have a kind of split brain.
All of the above didn't happens with OpenBSD 5.4, so I can't figure
out where the problem is.
For debugging, I've removed 2 switches, so now I have only one switch
per interface.
I've noticed that if I turn off PF, the configuration works perfectly.
I then tried with a simpler configuration of pf (pass quick in, pass
quick out), and again it doesn't works, so the problem seems to be
with pf.
I've noticed that when the split is ongoing, with tcpdump I can see
advertisement packet from both of servers, as if they are ignoring
each other.
I tried to remove some carp interface, then add them again one at a
time, and I discovered that when I have 19 carp interfaces, the
behaviour described above starts again.
When the split is ongoing, if I run ksh /etc/netstart carpXX on
system-1, system-2 switch the same interface in BACKUP mode.
Does it always start once you get to 19?
I seem to remember having to increase the number of BPF devices which
high numbers of VLANS etc..
for(( i=10; i = 30; i++ )); do mknod /dev/bpf$i c 23 $i; done
for(( i=10; i = 30; i++ )); do chmod o-r,g-r /dev/bpf$i; done
This is my test configuration (not patched, but in the production
environment is patched to the last errata release):
# uname -a (both machines)
OpenBSD system-1.my.domain 5.5 GENERIC#271 amd64
# grep carp /etc/sysctl.conf (both machines)
net.inet.carp.allow=1
net.inet.carp.preempt=1
net.inet.carp.log=7
# ifconfig -g carp (both machines)
carp: carp demote count 0
It's nice to keep them at 1 so if you loose control of one of the
servers, you can increase the other to 0 and preempt it remotely quickly
and the fix it in your own time.. If it's local then doesn't matter so
much I guess..
# cat /etc/pf.conf (both machines)
set skip on { lo0 em0 }
pass quick proto { carp pfsync }
pass in quick
pass out quick
This is an example of how I configured interfaces on the servers (carp5):
# carp5 system-1
inet 192.168.26.17 255.255.255.240 192.168.26.31 vhid 125 carpdev
vlan3 pass password advskew 10
# carp5 system-2
inet 192.168.26.17 255.255.255.240 192.168.26.31 vhid 125 carpdev
vlan3 pass password advskew 200
And this is vlan3:
inet 192.168.26.29 255.255.255.240 NONE vlan 3 vlandev bnx1
We generally define the broadcast (even though its implied by the mask)
and use carppeer to make it unicast..
In bnx0 and bnx1 (vlan root interfaces) I've just put up.
# pfsync0 system-1
up syncdev em0 syncpeer 10.10.26.4 defer
# pfsync0 system-2
up syncdev em0 syncpeer 10.10.26.3 defer
Why are you using defer? I'm guessing you know what this does and that
it slows things down..
Usually only see this on systems with BGP (incase packets are recieved
on the backup), or on active-active systems.
# /etc/hostname.em0 system-1
inet 10.10.26.3 255.255.255.0 NONE
# /etc/hostname.em0 system-2
inet 10.10.26.4 255.255.255.0 NONE
Anyone can help? This issue is driving me crazy
:q!
This all generally looks ok and seems like you know what you're doing.
The usual thing which causes multi master is PF. Also rememer to *not*
sync your carp states over pfsync, this works for us;
pass out quick proto carp keep state (no-sync) set prio 7
pass quick proto carp from { fe80::/10 } to { ff00::/8 } keep state
(no-sync)
pass quick proto carp from { $all_carpv4_ips } keep state (no-sync)
pass quick on { $if_pfsync_dev } proto pfsync keep state (no-sync)
block drop quick proto carp
The fact it works fine until you fail-over could be a state thing..!?!
Though having sooo many
Route on self pointing to internal CARP to allow VPN to work causes error arpresolve: 10.16.0.254: route without link local address
Hi, We have pairs of firewalls at all our remote office sites, with CARP interfaces on all physical interfaces. Head office also has a pair.. Every remote office site has IPSec VPNs to the head office (built against the CARP IPs and using sasyncd etc..). NB: VPN fail-over works brilliantly whether its a fail-over at the head office or remote office :) To allow the remote firewalls themselves to use the VPNs (for monitoring/reporting back to HQ etc) we have to add a static route for the head office network onto the remote office firewalls which goes via the remote office firewalls local internal CARP interface. This ensures the packet is generated by the remote office firewall with a source IP of it's internal interface (so as to match the IPSec VPN Policy based route), and so that the backup firewall sends its traffic to the current master which is running the VPN. E.g. 10.0.0/24 is the head office network on the other side of the VPN. 10.16.0.254 is the CARP interface on the inside of the remote office firewalls [OFFICE]root@stfw2:~# netstat -rn | grep 10.0.0 Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface 10.0.0/24 10.16.0.254UGS2 4342 - 8 em1 Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 10.0.0/24 0 10.16.0/24 0 0 178.78.113.100/esp/use/in 10.16.0/24 0 10.0.0/24 0 0 178.78.113.100/esp/require/out However, the master firewall throws this error (*many* times a second continuously); arpresolve: 10.16.0.254: route without link local address This seems to happen because on the master the route for the CARP interface has no MAC; DestinationGatewayFlags Refs Use Mtu Prio Iface 10.16.0.254 10.16.0.254 UH 14 - 4 carp1 Is their a way around this? We just want both of the remote firewalls to be able to use the IPSec VPN back to head office. This error can't be good or healthy to just ignore with the rate it occurs :( Cheers, Andy.
Re: NetMap in OpenBSD
On Oct 14 16:33:23, mikael.tr...@gmail.com wrote: Most devices in a system can be accessed with good performance from userland as it is now, for instance block devices, USB, serial ports, video and audio. Repeat after me: userland is not supposed to access devices. It is supposed to talk to a defined interface and let thr kernel talk to the device. Ethernet is a rare exception and NetMap solved this in a neat way - Prior to NetMap, those who wanted to make high-performance ethernet IO in userland would run their app as root and effectively implement NIC hardware drivers in userland. NetMap generalized this entire problem to one hardware-agnostic interface. Repeat after me: it is kernel's job to make high-performance ethernet IO.
Re: NetMap in OpenBSD
* Mikael mikael.tr...@gmail.com [2014-10-14 16:35]: 2014-10-14 16:15 GMT+02:00 Henning Brauer hb-open...@ml.bsws.de: i.e. there's no way for a userland application to do high speed packet-level IO. there are plenty of methods actually. Like what? bpf, for example. but since you still don't mention what problem you're trying to solve... userland reimplementing the stack[...] I didn't necessarily/specifically suggest that. but that's what you effectively HAVE TO DO with netmap, unless you're creating some layer2 bridge (which belongs in kernel space), or just want to listen (there is bpf for that). There is a whole world of need of network monitoring and manipulation and other specialized networking software. I read a collection of buzzwords with nothing specific. A solution in dire need of a problem. Will be more clear on this one following your response. Last for completing reflections - Most devices in a system can be accessed with good performance from userland as it is now, for instance block devices, USB, serial ports, video and audio. Ethernet is a rare exception and NetMap solved this in a neat way - bolloks. foremost, in almost all cases you don't speak ethernet, you speak IP (just like you don't speak USB to access a umass in userland). Prior to NetMap, those who wanted to make high-performance ethernet IO in userland would run their app as root and effectively implement NIC hardware drivers in userland. NetMap generalized this entire problem to one hardware-agnostic interface. ok, still bla bla without a use case, not even speaking about a valid one or one that is common enough to push yet another network subsystem into the kernel. still stinks like a solution in need of a problem. netmap is luigi's research framework, and he used it for some cool research an sure will do so more in the future. no more, no less. All this stack bypassing and (partial and buggy) reimplementation in userland baloony has to stop. Introducing interop and security issues just to look a little better in made up microbenchmarks, without any real world relevance, what an awesome deal. The time needed to port netmap (which includes touching EVERY NIC driver) plus the time for the fruitless attempt to get IP processing close to right in userland to make a specific application a little faster is spent much better improving the network stack itself - for all applications. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
sudo bad practice or inconsistency?
Dear list, I was playing with xfe (which by the way I consider a great program) and noticed that opening a root window with sudo in OBSD doesn't work. After a bit of debugging, I found out that the root cause is the following definition inside xfedefs.h: #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup xfe /dev/null sleep 1' Now, launching sudo that way returns an error: just22@poseidon:[xfe] sudo su -c ls su: no such login class: ls so basically sudo is parsing the -c option instead of passing it to su. Probably this is just a bad practice in sudo usage, nevertheless I never encountered such a problem in the Linux world... Now: which should be the right suggestion to make upstream? How the command should be written (preferably preserving the su call, just to minimize the impact on the code)? From the sudo's man page: -- The -- option indicates that sudo should stop processing command line arguments. I tried something like this, without luck: just22@poseidon:[xfe] sudo -- su -c ls su: no such login class: ls (but it's very likely I'm misinterpreting the option). And, in any case, why the same command works in Linux? do they use a modified/patched version? Thanks in advance for your time -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: sudo bad practice or inconsistency?
On Tue, 14 Oct 2014 20:58:56 +0200, Alessandro DE LAURENZIS wrote: Now, launching sudo that way returns an error: just22@poseidon:[xfe] sudo su -c ls su: no such login class: ls so basically sudo is parsing the -c option instead of passing it to su. Probably this is just a bad practice in sudo usage, nevertheless I never encountered such a problem in the Linux world... No, su is parsing the -c option instead of passing it to the shell. It should be running: su root -c ls or: su -- -c ls This really has nothing to do with sudo. - todd
Re: sudo bad practice or inconsistency?
just22@poseidon:[xfe] sudo su -c ls su: no such login class: ls so basically sudo is parsing the -c option instead of passing it to su. No, it is not. If it were, the error message would come from sudo, not from su. And, in any case, why the same command works in Linux? do they use a modified/patched version? They use a different su(1). You might want to check the third example in the OpenBSD manual page for su.
Re: NetMap in OpenBSD
* Henning Brauer hb-open...@ml.bsws.de [2014-10-14 20:52]: netmap is luigi's research framework, and he used it for some cool research an sure will do so more in the future. no more, no less. I should clarify: I am aware of a few use cases that profit enormously from netmap. Let's look at what netmap really is, pardon some slight inaccuracies for the sake of clarity: netmap is a ring buffer shoveling raw packets from the NIC's RX ring into userland and vice versa (to the TX ring of course). As such it is similar to BPF, but bpf does more, which is one reason why netmap is faster. Now these use cases are relatively rare; introducing yet another interface that is somewhat like an existing doesn't come for free - neither is the porting work done by sending an email to misc, nor is maintainance free. IPX and appletalk have their use cases too, and yet we deleted them - because they are to rare to justify the maintainance burden. Now if you want to spend time on improving these few use cases, that time is much better spent improving the existing interface imo - with all the existing consumers profiting. There's plenty of room without changing anything userland visible, esp. the no-filter case can probably speed up significantly without too much effort. Might even bring some ideas from netmap in (some would probably require minimal adjustments for existing consumers to profit, still way less effort than converting to a new interface). And let me repeat: all attempts to reimplement the IP stack in userland are not smart, heck, even dangerous. Not all cases fall into that category, but working w/ and in the network stack for more than a decade, I keep thinking I have a pretty good idea on what great ideas some people end up with. Luigi and I discussed netmap before, at length. We even mostly agree, it's for some very specific cases only. We disagree on the question whether it belongs into a general purpose OS kernel, plus, as I keep mentioning - it's not done by porting it, there is ongoing maintainance - our manpower is limited and we're not remotely out of ideas on how to improve networking for everyone. Now pardon me, beer is calling :) -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: problem with CARP+VLAN+OpenBSD 5.5
On 10/14/2014 06:53 PM, Andy wrote:
Why do you have so many CARP interfaces?
Generally it's good practice to have one CARP interface per broadcast
domain / VLAN etc, and have all your alias IP addresses defined in that
one CARP interface.
NB; when adding;
inet alias ipaddress mask Always set the mask for each alias to
255.255.255.255
This is apparently correct according to the devs. cite; something I was
told a long time ago even though you'll get a spurious error in the logs
at fail-over time..
Hello Andy,
we use so many carp interfaces because we have separate subnets, so the
netmask 255.255.255.255 can't fit our requirements.
In past, we tried to use the subnet netmask (i.e. 255.255.255.240), but
we didn't feel so confident about this configuration, and the official
documentation does not elaborate on the topic.
Does it always start once you get to 19?
I seem to remember having to increase the number of BPF devices which
high numbers of VLANS etc..
for(( i=10; i = 30; i++ )); do mknod /dev/bpf$i c 23 $i; done
for(( i=10; i = 30; i++ )); do chmod o-r,g-r /dev/bpf$i; done
That's intresting. On a similar machine I have only 10 bpf devices
(0-9). I will study this tomorrow.
# pfsync0 system-1
up syncdev em0 syncpeer 10.10.26.4 defer
# pfsync0 system-2
up syncdev em0 syncpeer 10.10.26.3 defer
Why are you using defer? I'm guessing you know what this does and that
it slows things down..
Usually only see this on systems with BGP (incase packets are recieved
on the backup), or on active-active systems.
Yes, sorry, defer was an experiment done while trying to understand
where was the problem.
# /etc/hostname.em0 system-1
inet 10.10.26.3 255.255.255.0 NONE
# /etc/hostname.em0 system-2
inet 10.10.26.4 255.255.255.0 NONE
Anyone can help? This issue is driving me crazy
:q!
This all generally looks ok and seems like you know what you're doing.
The usual thing which causes multi master is PF. Also rememer to *not*
sync your carp states over pfsync, this works for us;
pass out quick proto carp keep state (no-sync) set prio 7
pass quick proto carp from { fe80::/10 } to { ff00::/8 } keep state
(no-sync)
pass quick proto carp from { $all_carpv4_ips } keep state (no-sync)
pass quick on { $if_pfsync_dev } proto pfsync keep state (no-sync)
block drop quick proto carp
Thank you very much for your contribute.
I have no access to the servers right now, tomorrow I will check on your
advices.
Thank you!
Re: NetMap in OpenBSD
Sorry, replied to fast and to OP only. Below is one use case and a lot o things that Henning have said, put from my point of view. -- Forwarded message -- From: Raimundo Santos rait...@gmail.com Date: 14 October 2014 15:02 Subject: Re: NetMap in OpenBSD To: Mikael mikael.tr...@gmail.com On 14 October 2014 11:33, Mikael mikael.tr...@gmail.com wrote: userland reimplementing the stack[...] I didn't necessarily/specifically suggest that. The only case I can see to not reimplement full stack is working on pure Ethernet. All other really nice one can do with TCP/IP are sadly going to be reimplemented. This is how netmap works, barely: put packets in ring buffers, bypassing all the neat work of years in the OS network stack. How do you route a packet within netmap logic? How do you check for source or destiny addresses or TCP/UDP ports? You need to reimplement it on your own program, and do that for EVERY program using netmap. There is a whole world of need of network monitoring and manipulation and other specialized networking software. I read a collection of buzzwords with nothing specific. A solution in dire need of a problem. Here I see the limit of a general purpose OS. Well, lets deal with all the corner cases, and all the possibilities, and lets create a general purpose OS that is a specific purpose for everyone who uses it. Makes no sense to me. Specific needs that are not covered by the general facilities of such an OS must be covered by specific work of who needs it. You can even make a profitable product of this work. :) Bypass years of correct and conscious work to make all the stack more secure just because the needs of a few are for speed? It is a bad choice. netmap have one thing that really interests me: the ability to enforce specific per-ip bandwidth with dummynet, but at the cost of doing this with netmap-ipfw, reimplementing all the needed stack parts. Why, my sacred believes, WHY?! So, instead of improving that stack to do a free for all, correct and conscious speed up, lets do it by reimplementing the needed parts in every application. sosplice(9) may serve us with a starting point to that really fast things of zero-copy hype. http://www.openbsd.org/papers/eurobsdcon_2013_sosplice-slides.pdf Summarizing: netmap bypasses ALL the OS network stack. Period. Therefore, you must reimplement such things. Best regards, Raimundo Santos
RAID1C discipline and alternatives
Hello, I need to set up a few machines in the coming weeks and was wondering what's the status of stacked softraid and especially RAID1C discipline - i.e. CRYPTO on top of RAID1? Unfortunately I don't have the hardware right now so I can't really try it out, but any input is appreciated. Would using a hardware RAID controller and setting up softraid CRYPTO discipline on top of it do the trick? Is this approach recommended for production use? One last question -- can you point me to particular RAID controllers that are well supported under OpenBSD? Some of my readily available options are Adaptec RAID 6405E, LSI 3ware 9750-4i, LSI MegaRAID 9271-4i and HP Smart Array P222 but I'm open to any suggestions that will play better with OpenBSD. Best, Vladislav
Re: problem with CARP+VLAN+OpenBSD 5.5
On 2014-10-14, Federico Donati nix.b...@gmail.com wrote:
On 10/14/2014 06:53 PM, Andy wrote:
Why do you have so many CARP interfaces?
Generally it's good practice to have one CARP interface per broadcast
domain / VLAN etc, and have all your alias IP addresses defined in that
one CARP interface.
NB; when adding;
inet alias ipaddress mask Always set the mask for each alias to
255.255.255.255
This is apparently correct according to the devs. cite; something I was
told a long time ago even though you'll get a spurious error in the logs
at fail-over time..
I ignore that advice because I am announcing my carp networks into OSPF,
the bad effects *seem* to be limited to some arp: attempt to add entry ..
on carpXX / arp: attempt on vlanXX flip-flop in the logs.
Hello Andy,
we use so many carp interfaces because we have separate subnets, so the
netmask 255.255.255.255 can't fit our requirements.
In past, we tried to use the subnet netmask (i.e. 255.255.255.240), but
we didn't feel so confident about this configuration, and the official
documentation does not elaborate on the topic.
Does it always start once you get to 19?
I seem to remember having to increase the number of BPF devices which
high numbers of VLANS etc..
This is only needed if you have programs using those bpf devices
(common users include dhcpd, dhcrelay, LLDP listeners).
fstat | grep bpf will show what's in use.
for(( i=10; i = 30; i++ )); do mknod /dev/bpf$i c 23 $i; done
for(( i=10; i = 30; i++ )); do chmod o-r,g-r /dev/bpf$i; done
That's intresting. On a similar machine I have only 10 bpf devices
(0-9). I will study this tomorrow.
Please, don't recommend people do it this way. The right tool for the
job is MAKEDEV (which also takes into account any possible arch
differences in the device major)
# cd /dev
# sh MAKEDEV bpf{10,11,12,...}
This all generally looks ok and seems like you know what you're doing.
The usual thing which causes multi master is PF. Also rememer to *not*
sync your carp states over pfsync, this works for us;
pass out quick proto carp keep state (no-sync) set prio 7
pass quick proto carp from { fe80::/10 } to { ff00::/8 } keep state (no-sync)
pass quick proto carp from { $all_carpv4_ips } keep state (no-sync)
pass quick on { $if_pfsync_dev } proto pfsync keep state (no-sync)
block drop quick proto carp
Using no-sync is the right thing to do for carp and pfsync states.
IIRC the prio is set automatically for carp, but forcing it doesn't hurt.
FWIW I haven't hit this ..
$ ifconfig carp|grep -c ^carp
29
The most common cause I've seen for split carp states is a mismatch of
IP addresses between master/secondary, though I would think that a
combination of using defer and not using no-sync on the carp/pfsync
states could very well cause problems like this.
Re: Route-to with a dynamic 'next hop'
Thanks to both of you for the advice
Just to followup I ended up with the relayd 'routers' setup as described in man
page but with a script monitor rather than icmp. The monitor finds gateway for
interface in route table and pings it with -I interface source address. Seems
to work as desired. I also got it to work with ifstated but it seemed like more
script and also a 2nd process when I have to run relayd for other purpose
anyway.
-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Stuart Henderson
Sent: Friday, October 10, 2014 4:56 PM
To: misc@openbsd.org
Subject: Re: Route-to with a dynamic 'next hop'
On 2014-10-09, Justin Mayes jma...@careered.com wrote:
Ok I got it working. Here is what I did
Enabled multipath routing (sysctl)
Added the relayd anchor to pf.conf
Created a relayd.conf with this in it
gw1=fxp0
gw2=fxp1
table gateways { $gw1 ip ttl 1, $gw2 ip ttl 1 } router uplinks {
route 0.0.0.0/0
forward to gateways check icmp
}
Your relayd test here just pings your own interface's local IP addresses.
For example if fxp0's address is 10.0.0.2, it is pinging 10.0.0.2.
ifconfig fxp0 down will cause it to be detected, but it won't even notice you
pulling out the cable. Also I don't believe it will track your dynamic address.
One thing you could do in your situation is to use a route-to for the
connection where you have a static address, and use a probability
PF rule to load balance, allowing other traffic to be hit the normal default
route.
Another thing you could do is to use multiple route tables, and similarly use
pf rules to direct traffic to use one table or another.
For failover you can have some external checker (maybe run from ifstated, or
maybe a simple shell script run from cron) that adjusts the PF ruleset as
appropriate. You could either switch the whole ruleset out by pointing pfctl -f
to a different file, or put the relevant route-to pieces in an anchor.
Re: sudo bad practice or inconsistency?
On Tue 14/10 19:08, Miod Vallat wrote: just22@poseidon:[xfe] sudo su -c ls su: no such login class: ls so basically sudo is parsing the -c option instead of passing it to su. No, it is not. If it were, the error message would come from sudo, not from su. And, in any case, why the same command works in Linux? do they use a modified/patched version? They use a different su(1). You might want to check the third example in the OpenBSD manual page for su. Todd, Miod, My bad, two times (I misinterpreted the error message and I didn't read the documentation, where the behavior is explicitly mentioned - into the BUGS section of the su's man page, incidentally). Thanks for your hints, that have pointed me in the right direction. Cheers -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
