Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600
On Wed, Feb 12, 2014 at 02:37:30AM -0500, RD Thrush wrote: On 02/11/14 19:45, Jonathan Gray wrote: On Mon, Feb 10, 2014 at 01:20:46PM -0500, Kenneth Westerback wrote: On 10 February 2014 13:11, RD Thrush openbsd-m...@thrush.com wrote: With a somewhat recent i7 desktop, using startx, X seems to run ok; however, at 1024x768 rather than the expected 1920x1200 resolution. ctl-alt-keypad+ or - have no effect on resolution. ctl-alt-backspace correctly reverts to text mode. I then tried Xorg -configure to look for hints to improve resolution; however, that resulted in a segfault almost immediately. I'm pretty sure vga1 at pci0 dev 2 function 0 Intel HD Graphics 4600 rev 0x06 is not supported in the sense of working as opposed to being recognized. i.e. 1024x768 is likely as good as it gets until support is added. Even 4400 is problematic at the moment. But I'm willing to be corrected by people more in the know. :-) Haswell graphics should work since a few months now. It does work; however, only @ vesa 1024x768 resolution. That same hardware yields 1920x1200 w/ win7. Is 1024x768 the upper limit for -current w/ vga and this graphics hardware? 1024x768 is the mode chosen if the monitor does not send a mode when probed. If you want to make all of this a lot easier to debug remove the radeon card. X segfaulting at a low address normally means the framebuffer could not be mmap'd due to the /dev/drm* permissions not being set correctly. Here's what I have: a8v2:home/rd 2181ls -l /dev/drm* crw--- 1 root wheel 87, 0 Jan 24 02:58 /dev/drm0 crw--- 1 root wheel 87, 1 Jan 24 02:58 /dev/drm1 crw--- 1 root wheel 87, 2 Jan 24 02:58 /dev/drm2 crw--- 1 root wheel 87, 3 Jan 24 02:58 /dev/drm3 I didn't expect those perms to matter w/ Xorg -configure -keepPriv. In any case, I added /dev/drm[123] to /etc/fbtab as you suggested in the other post but observed the same segfault. Xorg -configure is known to be broken for quite a while http://lists.freedesktop.org/pipermail/xorg/2013-June/055813.html avoid it.
Re: Documentation on rc.conf.local lacks important warning
Hi, Giancarlo Razzolini wrote on Mon, Feb 10, 2014 at 03:18:39PM -0200: The main issue here is, that, the human brain, although being this wonderful machine, makes a lot of assumptions to fill in the gaps, even when there are *no *gaps to be filled. I don't know if the documentation needs to be clearer in this specific case. Even though the misunderstanding does not seem to occur often, it does seem somewhat unsurprising because a lot of other software encourages the (imho questionable) practice of copying example configuration files. So here is what i came up with to make this clearer without making it longer or more redundant. OK? Ingo Index: rc.conf.8 === RCS file: /cvs/src/share/man/man8/rc.conf.8,v retrieving revision 1.20 diff -u -r1.20 rc.conf.8 --- rc.conf.8 17 Mar 2012 14:46:40 - 1.20 +++ rc.conf.8 12 Feb 2014 09:40:09 - @@ -49,9 +49,9 @@ .Nm rc.conf untouched, and instead create and edit a new .Nm rc.conf.local -file. -Variables set in this file will override variables previously set in -.Nm rc.conf . +file, setting just those variables whose +.Nm rc.conf +default values are intended to be overridden. .Pp Some variables are used to turn features on or off. For example, whether the system runs the
Re: Does OpenBSD's wpa_supplicant support PSK?
Em 11-02-2014 19:15, Frank Brodbeck escreveu: I am using wpa-supplicant with wired 802.1X at work and I do start it from hostname.if(5). But keep in mind that this means that you've got to store your password in cleartext somewhere on your disk. This is the one and only case I see the need for a network manager who's capable of talking to some sort of keyring like gnome does it. Frank. If you're are talking about the network manager in ubuntu and others, it do not keep the password in a keyring but instead, it keeps it in clear text in /etc. For mitigate this, you should use full disk encryption. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Documentation on rc.conf.local lacks important warning
Em 12-02-2014 07:48, Ingo Schwarze escreveu: Hi, Giancarlo Razzolini wrote on Mon, Feb 10, 2014 at 03:18:39PM -0200: The main issue here is, that, the human brain, although being this wonderful machine, makes a lot of assumptions to fill in the gaps, even when there are *no *gaps to be filled. I don't know if the documentation needs to be clearer in this specific case. Even though the misunderstanding does not seem to occur often, it does seem somewhat unsurprising because a lot of other software encourages the (imho questionable) practice of copying example configuration files. So here is what i came up with to make this clearer without making it longer or more redundant. OK? Ingo Index: rc.conf.8 === RCS file: /cvs/src/share/man/man8/rc.conf.8,v retrieving revision 1.20 diff -u -r1.20 rc.conf.8 --- rc.conf.8 17 Mar 2012 14:46:40 - 1.20 +++ rc.conf.8 12 Feb 2014 09:40:09 - @@ -49,9 +49,9 @@ .Nm rc.conf untouched, and instead create and edit a new .Nm rc.conf.local -file. -Variables set in this file will override variables previously set in -.Nm rc.conf . +file, setting just those variables whose +.Nm rc.conf +default values are intended to be overridden. .Pp Some variables are used to turn features on or off. For example, whether the system runs the HI Ingo, I've sent a patch on tech@, and there was a discussion about it, but there wasn't a consensus. I encourage you to join tech and the discussion. Send your proposal there too. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Interface/IP limit on isakmpd, no listen-on in ipsec.conf, IPSec failover enhancement, IPSec tunnel rebuild enhancement
Hi,
I think this is a fairly simple one.
Our firewalls are growing in complexity and the number of interfaces and
IPs as time goes on, and we recently hit an isakmpd limit.
When isakmpd starts it tries to bind to *every* single IP on the system.
We have a LOT of IPs and isakmpd now fails to initialise;
2014-02-12T10:40:29.386318+00:00 brfw1 isakmpd[404]: udp_encap_make:
socket (2, 2, 17): Too many open files
2014-02-12T10:40:29.386352+00:00 brfw1 isakmpd[404]: virtual_bind_if:
failed to create a socket on 10.2.8.254
2014-02-12T10:40:29.386657+00:00 brfw1 isakmpd[404]: virtual_init: could
not bind the ISAKMP port(s) on all interfaces: Too many open files
More log at bottom..
We only want isakmpd to listen on the CARP IP address on the external
interface (and probably the physical IPs on the external interface), not
*all* IPs.
The work around for now was to add '-4' to the isakmpd daemon to restrict
it to our v4 addresses. However we will very soon have even too many v4
addresses for isakmpd to cope and so need a way to instruct isakmpd to only
bind the necessary IPs.
This would also provide a security enhancement??
Others have reported this limitation before;
http://www.monkey.org/openbsd/archive2/misc/200502/msg00686.html
Also if someone else finds these useful (I will commit to source one
day..), I have two primitive but *very* effective enhancements I have made
to /etc/rc.d/sasyncd and /etc/rc.d/isakmpd to share when running IPSec on a
carp pair (I am absolutely sure these could be more elegant in
implementation, but they work and you should get the idea)..
First enhancement, when running isakmpd with carp and sasyncd, you must
use the -S and -K flags on isakmpd. This ensures isakmpd starts in passive
mode and does not start negotiating with the other side *unless* it is the
carp master. Makes perfect sense..
On the master, isakmpd starts in passive, discovers it is master and so
reads and loads ipsec.conf, and starts negotiating with other side
On the backup, isakmod starts in passive, does nothing more.
If a failover occurs however, the VPNs do not work for a lng time!
(this is because isakmpd on the backup never read the ipsec.conf file so
when it is made active it doesn't know what to do..)
/etc/rc.d/sasyncd;
#!/bin/sh
#
# $OpenBSD: sasyncd,v 1.1 2011/07/06 18:55:36 robert Exp $
daemon=/usr/sbin/sasyncd
. /etc/rc.d/rc.subr
pexp=sasyncd: \[priv\]
rc_start() {
sleep 10
${rcexec} ${daemon} ${daemon_flags} ${_bg}
sleep 5
ipsecctl -f /etc/ipsec.conf
}
rc_cmd $1
This fix simply ensures that the carp-backup isakmpd reads the ipsec.conf
after starting in passive mode and has settled. VPN failover's now happen
in ~2-3 seconds.
Second enhancement, when stopping isakmpd on the master or backup with
'/etc/rc.d/isakmpd' stop or restart, subsequent starting of the tunnels can
take a very long time. This seems to be because stopping isakmpd simply
tears the daemon down without deconstructing the trust keys / policies.
Leaving obsolete expiring policies on the remote side. So restarting
isakmpd can take a long time until the other side flushes or times out.
/etc/rc.d/isakmpd;
#!/bin/sh
#
# $OpenBSD: isakmpd,v 1.1 2011/07/06 18:55:36 robert Exp $
daemon=/sbin/isakmpd
. /etc/rc.d/rc.subr
pexp=isakmpd: monitor \[priv\]
rc_pre() {
[ X${sasyncd_flags} != XNO ] \
daemon_flags=-S ${daemon_flags}
return 0
}
rc_stop() {
if [ `ifconfig | grep status: master | wc -l` 0 ]; then ipsecctl
-d -f /etc/ipsec.conf; fi
sleep 1
if [ `ifconfig | grep status: master | wc -l` 0 ]; then ipsecctl
-d -f /etc/ipsec.conf; fi
if [ `ifconfig | grep status: master | wc -l` 0 ]; then ipsecctl
-F -f /etc/ipsec.conf; fi
pkill -f ^${pexp}
}
rc_cmd $1
This fix simply gracefully deletes the flows (and informs the other side
to do the same), and flushes the SPD's and SAD's cleanly before destroying
the daemon. Subsequent restarts now allow IPSec tunnels to come up
immediately..
Hope this helps someone :)
Cheers, Andy.
isakmpd binding error;
2014-02-12T10:40:29.382031+00:00 brfw1 isakmpd[404]: udp_encap_make:
transport 0x20615b500 socket 120 ip fe80:14::200:5eff:fe00:103 port 4500
2014-02-12T10:40:29.382242+00:00 brfw1 isakmpd[404]: udp_make: transport
0x20615bd00 socket 121 ip 10.0.1.254 port 500
2014-02-12T10:40:29.382423+00:00 brfw1 isakmpd[404]: udp_encap_make:
transport 0x20615ba80 socket 122 ip 10.0.1.254 port 4500
2014-02-12T10:40:29.382655+00:00 brfw1 isakmpd[404]: udp_make: transport
0x20615bc80 socket 123 ip 10.2.3.254 port 500
2014-02-12T10:40:29.382873+00:00 brfw1 isakmpd[404]: udp_encap_make:
transport 0x20615bf80 socket 124 ip 10.2.3.254 port 4500
2014-02-12T10:40:29.383485+00:00 brfw1 isakmpd[404]: udp_make: transport
0x20615b880 socket 127 ip fe80:15::200:5eff:fe00:104 port 500
2014-02-12T10:40:29.383524+00:00 brfw1 isakmpd[404]: udp_encap_make:
socket (24, 2, 17): Too many open files
2014-02-12T10:40:29.383549+00:00 brfw1 isakmpd[404]:
Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600
On 02/12/14 03:01, Jonathan Gray wrote: On Wed, Feb 12, 2014 at 02:37:30AM -0500, RD Thrush wrote: On 02/11/14 19:45, Jonathan Gray wrote: On Mon, Feb 10, 2014 at 01:20:46PM -0500, Kenneth Westerback wrote: On 10 February 2014 13:11, RD Thrush openbsd-m...@thrush.com wrote: With a somewhat recent i7 desktop, using startx, X seems to run ok; however, at 1024x768 rather than the expected 1920x1200 resolution. ctl-alt-keypad+ or - have no effect on resolution. ctl-alt-backspace correctly reverts to text mode. I then tried Xorg -configure to look for hints to improve resolution; however, that resulted in a segfault almost immediately. I'm pretty sure vga1 at pci0 dev 2 function 0 Intel HD Graphics 4600 rev 0x06 is not supported in the sense of working as opposed to being recognized. i.e. 1024x768 is likely as good as it gets until support is added. Even 4400 is problematic at the moment. But I'm willing to be corrected by people more in the know. :-) Haswell graphics should work since a few months now. It does work; however, only @ vesa 1024x768 resolution. That same hardware yields 1920x1200 w/ win7. Is 1024x768 the upper limit for -current w/ vga and this graphics hardware? 1024x768 is the mode chosen if the monitor does not send a mode when probed. If you want to make all of this a lot easier to debug remove the radeon card. This i7 only has onboard graphics. The other i7 has both graphics hardware. I only brought it up to corroborate the resolution and segfault problems seen in the initial report. X segfaulting at a low address normally means the framebuffer could not be mmap'd due to the /dev/drm* permissions not being set correctly. Here's what I have: a8v2:home/rd 2181ls -l /dev/drm* crw--- 1 root wheel 87, 0 Jan 24 02:58 /dev/drm0 crw--- 1 root wheel 87, 1 Jan 24 02:58 /dev/drm1 crw--- 1 root wheel 87, 2 Jan 24 02:58 /dev/drm2 crw--- 1 root wheel 87, 3 Jan 24 02:58 /dev/drm3 I didn't expect those perms to matter w/ Xorg -configure -keepPriv. In any case, I added /dev/drm[123] to /etc/fbtab as you suggested in the other post but observed the same segfault. Xorg -configure is known to be broken for quite a while http://lists.freedesktop.org/pipermail/xorg/2013-June/055813.html avoid it. Amending the faq[1] might help avoid this unproductive path... [1]http://www.openbsd.org/faq/faq11.html#amd64i386example
Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600
On 02/11/14 19:53, Jonathan Gray wrote: On Tue, Feb 11, 2014 at 10:32:25AM -0500, RD Thrush wrote: On 02/10/14 13:20, Kenneth Westerback wrote: On 10 February 2014 13:11, RD Thrush openbsd-m...@thrush.com wrote: With a somewhat recent i7 desktop, using startx, X seems to run ok; however, at 1024x768 rather than the expected 1920x1200 resolution. ctl-alt-keypad+ or - have no effect on resolution. ctl-alt-backspace correctly reverts to text mode. I then tried Xorg -configure to look for hints to improve resolution; however, that resulted in a segfault almost immediately. I'm pretty sure vga1 at pci0 dev 2 function 0 Intel HD Graphics 4600 rev 0x06 is not supported in the sense of working as opposed to being recognized. i.e. 1024x768 is likely as good as it gets until support is added. Even 4400 is problematic at the moment. But I'm willing to be corrected by people more in the know. :-) Ken Thanks for the feedback. Apparently, Intel HD Graphics 4000 is similarly not yet supported... Ivy bridge works fine, what you didn't point out is that you have both radeondrm and inteldrm in that machine. Setups with multiple cards may have been broken by the fbtab changes Try adjust your /etc/fbtab along these lines and restart your xorg server. --- fbtab.prevWed Feb 12 11:46:14 2014 +++ fbtab Wed Feb 12 11:47:15 2014 @@ -2,6 +2,6 @@ # login(1) reads this file to determine which devices should be chown'd to # the new user. Format is: # login-tty permdevice:[device]:... -/dev/ttyC0 0600 /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/drm0 +/dev/ttyC0 0600 /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/drm0:/dev/drm1:/dev/drm2:/dev/drm3 # samples #/dev/ttyC0 0600/dev/fd0 I will make that change in the next few days and report back. Further info: Both the onboard vga and the radeon display port interface are connected to the same monitor (Dell U2412M). The machine is usually running win8 w/ the monitor in display port mode. When running OpenBSD, I have the monitor in vga mode.
Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600
On 02/12/14 02:53, Philip Guenther wrote: On Tue, Feb 11, 2014 at 11:37 PM, RD Thrush openbsd-m...@thrush.com wrote: ... I didn't expect those perms to matter w/ Xorg -configure -keepPriv. With the perms on /dev/drm[0-3] set so that you own them, what happens when you don't use the -configure and -keepPriv options? Thanks. I see the root screen. Cursor tracks mouse. ctl-alt-backspace transitions cleanly to text mode. I've appended the typescript, associated Xorg.0.log and dmesg. (You don't say why you use -configure, so I'll just quote Matthieu I was expecting better than 1024x768 resolution and the X11 section of the faq http://www.openbsd.org/faq/faq11.html#amd64i386example suggested Xorg -configure. Herb from July 2012(!): Also forget about X -configure. It's known to be more or less broken and nowadays you don't need an xorg.conf file to run X in most cases. ) I'll stop using X -configure. Other recommendations for getting better resolution? ### typescript ### Script started on Wed Feb 12 07:06:58 2014 a8v2:home/rd 384export DISPLAY= a8v2:home/rd 385Xorg X.Org X Server 1.14.5 Release Date: 2013-12-12 X Protocol Version 11, Revision 0 Build Operating System: OpenBSD 5.5 amd64 Current Operating System: OpenBSD a8v2.thrush.com 5.5 GENERIC.MP#287 amd64 Build Date: 10 February 2014 11:19:30AM Current version of pixman: 0.32.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Wed Feb 12 07:07:20 2014 (==) Using system config directory /usr/X11R6/share/X11/xorg.conf.d Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Loading extension GLX (EE) Server terminated successfully (0). Closing log file. a8v2:home/rd 386exit Script done on Wed Feb 12 07:07:50 2014 # Xorg.0.log ### [250360.398] (--) checkDevMem: using aperture driver /dev/xf86 [250360.421] (--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode (version 3.32) [250361.450] X.Org X Server 1.14.5 Release Date: 2013-12-12 [250361.450] X Protocol Version 11, Revision 0 [250361.450] Build Operating System: OpenBSD 5.5 amd64 [250361.450] Current Operating System: OpenBSD a8v2.thrush.com 5.5 GENERIC.MP#287 amd64 [250361.451] Build Date: 10 February 2014 11:19:30AM [250361.451] [250361.451] Current version of pixman: 0.32.4 [250361.451]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [250361.451] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [250361.451] (==) Log file: /var/log/Xorg.0.log, Time: Wed Feb 12 07:07:20 2014 [250361.452] (==) Using system config directory /usr/X11R6/share/X11/xorg.conf.d [250361.452] (==) No Layout section. Using the first Screen section. [250361.452] (==) No screen section available. Using defaults. [250361.452] (**) |--Screen Default Screen Section (0) [250361.452] (**) | |--Monitor default monitor [250361.453] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [250361.453] (==) Disabling SIGIO handlers for input devices [250361.453] (==) Automatically adding devices [250361.453] (==) Automatically enabling devices [250361.453] (==) Not automatically adding GPU devices [250361.453] (==) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF/, /usr/X11R6/lib/X11/fonts/Type1/,
Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600
On 02/12/14 12:32, RD Thrush wrote: On 02/12/14 02:53, Philip Guenther wrote: On Tue, Feb 11, 2014 at 11:37 PM, RD Thrush openbsd-m...@thrush.com wrote: ... I didn't expect those perms to matter w/ Xorg -configure -keepPriv. With the perms on /dev/drm[0-3] set so that you own them, what happens when you don't use the -configure and -keepPriv options? Thanks. I see the root screen. Cursor tracks mouse. ctl-alt-backspace transitions cleanly to text mode. I've appended the typescript, associated Xorg.0.log and dmesg. (You don't say why you use -configure, so I'll just quote Matthieu I was expecting better than 1024x768 resolution and the X11 section of the faq http://www.openbsd.org/faq/faq11.html#amd64i386example suggested Xorg -configure. Herb from July 2012(!): Also forget about X -configure. It's known to be more or less broken and nowadays you don't need an xorg.conf file to run X in most cases. ) I'll stop using X -configure. Other recommendations for getting better resolution? xrandr(1) and mode lines from cvt(1) or gtf(1) might give you better resolution. cvt has solved resolution issues for me where gtf failed. hth Fred PS in theory you can just put the mode lines in xorg.conf - but I didn't have much luck trying that approach...
Snmpd question
Is it possible to have a shell script modify the contents of a user defined OID that is setup in snmpd.conf? I would like to have a cron event run a shell script and that script modify the OID values so that a remote SNMP server can monitor the changes using SNMP gets and mgets. I do not want to use SNMP traps. Thanks for any feedback!
Re: Can't ping CARP interface from CARP master box.
On Tue, Feb 11, 2014 at 10:17:46PM +, andy wrote: Hi, You should be able to ping the CARP IP addresses from any host (including the master), so something is wrong here. This can sometimes be due to a routing problem. Your routing table should look similar to; 10.0.0.1 10.0.0.1 UH 04 - 4 carp0 10.0.0.2 127.0.0.1 UGHS 02 33144 8 lo0 10.0.0.2/32 10.0.0.2 U 00 - 4 carp0 10.0.0.3 127.0.0.1 UGHS 02 33144 8 lo0 10.0.0.3/32 10.0.0.3 U 00 - 4 carp0 Here 10.0.0.1 is the primary IP, and 10.0.0.2 and 10.0.0.3 are secondary carp IPs. Your /etc/hostname.carp file should look like; inet 10.0.0.1 255.255.255.0 10.0.0.255 vhid 1 pass carpsecurehashpasswd advbase 1 advskew 0 inet alias 10.0.0.2 255.255.255.255 inet alias 10.0.0.3 255.255.255.255 Notice the secondary IP's have a /32 subnet (which is correct despite the spurious errors in dmesg during carp fail-overs). It is having the /32 subnet on the secondaries which causes the creation of the additional route entry to lo0. What does your routing table and carp look like? Hi Andy, My routing table looks like this: $ netstat -rn | grep '^46.21.116.5' 46.21.116.546.21.116.5UH 0 15 - 4 carp116 $ netstat -rn | grep '^213.215.29' 213.215.29.254 213.215.29.254 UH 00 - 4 carp0 Please note carp0 is fine WRT icmp-echo.
Re: Snmpd question
On 12.02.2014, at 18:25, Bales, Tracy tracy.ba...@williams.com wrote: Is it possible to have a shell script modify the contents of a user defined OID that is setup in snmpd.conf? I would like to have a cron event run a shell script and that script modify the OID values so that a remote SNMP server can monitor the changes using SNMP gets and mgets. I do not want to use SNMP traps. Thanks for any feedback! No. You would have to restart snmpd, there is no way to change it on runtime. But AgentX support might solve this in the future (you still need an shell - AgentX wrapper). Reyk
Re: Documentation on rc.conf.local lacks important warning
Hi Jason, Jason McIntyre wrote on Mon, Feb 10, 2014 at 08:29:24AM +: On Sun, Feb 09, 2014 at 03:19:36PM -0800, Philip Guenther wrote: On Sun, Feb 9, 2014 at 3:02 PM, d...@genunix.com d...@genunix.com wrote: Question .. where do I get all the man pages? I have some of them but then others are absent : # man reboot REBOOT(8) OpenBSD System Manager's Manual REBOOT(8) [...] SEE ALSO reboot(2), utmp(5), boot_alpha(8), boot_amd64(8), boot_hp300(8), boot_hppa(8), boot_hppa64(8), boot_i386(8), boot_luna88k(8), boot_macppc(8), boot_mvme68k(8), boot_mvme88k(8), boot_sparc(8), boot_sparc64(8), boot_vax(8), boot_zaurus(8), rc.d(8), rc.shutdown(8), savecore(8), shutdown(8), sync(8) Hmm, that may be incorrect notation for the pages which are architecture specific: the boot_*(8) manpages are in the architecture specific sections. They can be seen on all platforms using the -S option to man, ala: man -S i386 boot_i386 man -S sparc boot_sparc ...etc By default, man uses the architecture that you're running, so if you're running on i386, you should be able to just say man boot_i386 I'm not 100% sure if the cross-references in the SEE ALSO section should be indicating that; I could have sworn that I saw syntax like whatever(8/i386) elsewhere. Jason, Ingo, what the Right Thing here? we use 8/i386 notation in man -k (apropos) output, not in man pages, though you can use 8/i386 instead of just 8, and mandoc won;t complain. i suspect ingo will tell us it'll break other tools. Actually, both mandoc and groff would be happy with stuff like .Xr boot_alpha 8/alpha and off the top of my head, i don't see which tools might break. Certainly not our Perl makewhatis(8), it doesn't parse that deeply. And mandocdb(8) does the right thing out of the box, using it, you can even search for pages containing arch-specific .Xrs: $ ./obj/apropos Xr=/alpha halt(8), reboot(8) - stopping and restarting the system $ ./obj/apropos -O Xr Xr=/alpha halt(8), reboot(8) - [...] # rc.conf(8) # boot_alpha(8/alpha) # [...] Given that neither groff_mdoc(7) nor mdoc(7) mention this possibility, i'm not 100% sure all exotic tools will cope, but i don't consider problems very likely. Most tools are quite lenient when parsing macro arguments, roff and groff traditionally do almost no validation, and most other tools refrain from parsing random content macros, anyway. So if you see value in making this explicit, i'd suggest asking on the groff list whether anybody else expects problems, and if not, documenting and using it. in this case it seems clear the intent is to list all the boot_ pages and assume the reader will understand. it's a fair assumption. For boot_alpha(8), it's nearly obvious; but stuff like inb(2) may confuse readers quite a bit unless the arch is made explicit. the alternative is to remove all the platform dependent cross references. That seems like a bad idea. i don;t really have a problem with its current format. we do have other pages that reference (by neccesity) platform dependent pages, though they themselves are usually platform dependent. Sure, that mitigates the issue. Yours, Ingo
Re: Documentation on rc.conf.local lacks important warning
On 2/12/14, Giancarlo Razzolini grazzol...@gmail.com wrote: Em 12-02-2014 07:48, Ingo Schwarze escreveu: Hi, Giancarlo Razzolini wrote on Mon, Feb 10, 2014 at 03:18:39PM -0200: The main issue here is, that, the human brain, although being this wonderful machine, makes a lot of assumptions to fill in the gaps, even when there are *no *gaps to be filled. I don't know if the documentation needs to be clearer in this specific case. Even though the misunderstanding does not seem to occur often, it does seem somewhat unsurprising because a lot of other software encourages the (imho questionable) practice of copying example configuration files. So here is what i came up with to make this clearer without making it longer or more redundant. OK? Ingo Index: rc.conf.8 === RCS file: /cvs/src/share/man/man8/rc.conf.8,v retrieving revision 1.20 diff -u -r1.20 rc.conf.8 --- rc.conf.817 Mar 2012 14:46:40 - 1.20 +++ rc.conf.812 Feb 2014 09:40:09 - @@ -49,9 +49,9 @@ .Nm rc.conf untouched, and instead create and edit a new .Nm rc.conf.local -file. -Variables set in this file will override variables previously set in -.Nm rc.conf . +file, setting just those variables whose +.Nm rc.conf +default values are intended to be overridden. .Pp Some variables are used to turn features on or off. For example, whether the system runs the HI Ingo, I've sent a patch on tech@, and there was a discussion about it, but there wasn't a consensus. I encourage you to join tech and the discussion. Send your proposal there too. maybe some people should lurk more. --patrick
Firefox crashes on OpenBSD
Hi, On my 5.4 desktop, I'm getting several of those issues when running firefox. (firefox:26140): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion `targets != NULL' failed out of memory: 0x00016958 bytes requested Segmentation fault (core dumped) Is that a known issue ? If it is, has it been fixed in -current ? -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Re: Firefox crashes on OpenBSD
On 13/02/14 00:31 +0400, Loganaden Velvindron wrote: Hi, On my 5.4 desktop, I'm getting several of those issues when running firefox. (firefox:26140): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion `targets != NULL' failed out of memory: 0x00016958 bytes requested Segmentation fault (core dumped) Is that a known issue ? If it is, has it been fixed in -current ? It seems that you're OOM. Is your system running out of memory/is the user you're running it as limited in heap size? [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Documentation on rc.conf.local lacks important warning
On Wed, Feb 12, 2014 at 09:13:43PM +0100, Ingo Schwarze wrote: Hi Jason, Jason McIntyre wrote on Mon, Feb 10, 2014 at 08:29:24AM +: On Sun, Feb 09, 2014 at 03:19:36PM -0800, Philip Guenther wrote: On Sun, Feb 9, 2014 at 3:02 PM, d...@genunix.com d...@genunix.com wrote: Question .. where do I get all the man pages? I have some of them but then others are absent : # man reboot REBOOT(8) OpenBSD System Manager's Manual REBOOT(8) [...] SEE ALSO reboot(2), utmp(5), boot_alpha(8), boot_amd64(8), boot_hp300(8), boot_hppa(8), boot_hppa64(8), boot_i386(8), boot_luna88k(8), boot_macppc(8), boot_mvme68k(8), boot_mvme88k(8), boot_sparc(8), boot_sparc64(8), boot_vax(8), boot_zaurus(8), rc.d(8), rc.shutdown(8), savecore(8), shutdown(8), sync(8) Hmm, that may be incorrect notation for the pages which are architecture specific: the boot_*(8) manpages are in the architecture specific sections. They can be seen on all platforms using the -S option to man, ala: man -S i386 boot_i386 man -S sparc boot_sparc ...etc By default, man uses the architecture that you're running, so if you're running on i386, you should be able to just say man boot_i386 I'm not 100% sure if the cross-references in the SEE ALSO section should be indicating that; I could have sworn that I saw syntax like whatever(8/i386) elsewhere. Jason, Ingo, what the Right Thing here? we use 8/i386 notation in man -k (apropos) output, not in man pages, though you can use 8/i386 instead of just 8, and mandoc won;t complain. i suspect ingo will tell us it'll break other tools. Actually, both mandoc and groff would be happy with stuff like .Xr boot_alpha 8/alpha and off the top of my head, i don't see which tools might break. Certainly not our Perl makewhatis(8), it doesn't parse that deeply. And mandocdb(8) does the right thing out of the box, using it, you can even search for pages containing arch-specific .Xrs: $ ./obj/apropos Xr=/alpha halt(8), reboot(8) - stopping and restarting the system $ ./obj/apropos -O Xr Xr=/alpha halt(8), reboot(8) - [...] # rc.conf(8) # boot_alpha(8/alpha) # [...] Given that neither groff_mdoc(7) nor mdoc(7) mention this possibility, i'm not 100% sure all exotic tools will cope, but i don't consider problems very likely. Most tools are quite lenient when parsing macro arguments, roff and groff traditionally do almost no validation, and most other tools refrain from parsing random content macros, anyway. So if you see value in making this explicit, i'd suggest asking on the groff list whether anybody else expects problems, and if not, documenting and using it. i wouldn;t want this to happen at all, to be honest. i just wanted to point out that you could do it. try adding it to the page, then see how ugly it becomes. jmc in this case it seems clear the intent is to list all the boot_ pages and assume the reader will understand. it's a fair assumption. For boot_alpha(8), it's nearly obvious; but stuff like inb(2) may confuse readers quite a bit unless the arch is made explicit. the alternative is to remove all the platform dependent cross references. That seems like a bad idea. i don;t really have a problem with its current format. we do have other pages that reference (by neccesity) platform dependent pages, though they themselves are usually platform dependent. Sure, that mitigates the issue. Yours, Ingo
ssh 'tokens' like smtpd tokens
Hi,
I was just doing some chrooted sftp work and I've
thought it would be nice if sshd_config's 'ChrootDirectory'
and sftp-server '-d - start directory' would support
more sofisticated token format like smtpd.conf states.
I could imagine following would be useful for sftp
hosting providers:
Match Group sftp
X11Forwarding no
AllowTcpForwarding no
PermitTTY no
ForceCommand internal-sftp -d %u
ChrootDirectory /home/sftp/%{u[0]}/%u
ChrootDirectory would for user 'foo' expand to:
/home/sftp/f/foo
and a sftp user would be switched to:
/home/sftp/f/foo/foo
This way a hosting provider could easier define
more sofisticated sftp homedirs.
Sorry, I'm not able to provide diffs :(
jirib
Re: Can't ping CARP interface from CARP master box.
On Wed, 12 Feb 2014 20:26:32 +0100, Laurent CARON lca...@unix-scripts.info wrote: On Tue, Feb 11, 2014 at 10:17:46PM +, andy wrote: Hi, You should be able to ping the CARP IP addresses from any host (including the master), so something is wrong here. This can sometimes be due to a routing problem. Your routing table should look similar to; 10.0.0.1 10.0.0.1 UH 04 - 4 carp0 10.0.0.2 127.0.0.1 UGHS 02 33144 8 lo0 10.0.0.2/32 10.0.0.2 U 00 - 4 carp0 10.0.0.3 127.0.0.1 UGHS 02 33144 8 lo0 10.0.0.3/32 10.0.0.3 U 00 - 4 carp0 Here 10.0.0.1 is the primary IP, and 10.0.0.2 and 10.0.0.3 are secondary carp IPs. Your /etc/hostname.carp file should look like; inet 10.0.0.1 255.255.255.0 10.0.0.255 vhid 1 pass carpsecurehashpasswd advbase 1 advskew 0 inet alias 10.0.0.2 255.255.255.255 inet alias 10.0.0.3 255.255.255.255 Notice the secondary IP's have a /32 subnet (which is correct despite the spurious errors in dmesg during carp fail-overs). It is having the /32 subnet on the secondaries which causes the creation of the additional route entry to lo0. What does your routing table and carp look like? Hi Andy, My routing table looks like this: $ netstat -rn | grep '^46.21.116.5' 46.21.116.546.21.116.5UH 0 15 - 4 carp116 $ netstat -rn | grep '^213.215.29' 213.215.29.254 213.215.29.254 UH 00 - 4 carp0 Please note carp0 is fine WRT icmp-echo. From what you have sent I guess you are talking about trying to ping the primary IP address on carp116 from the carp master itself. If you run 'ping 46.21.116.5' I'm guessing you see the count (15 above) on the route increase, even if you don't see the echo reply? When pinging the carp address on my master firewall from self (successfully) and running 'tcpdump -netti carp0' or 'tcpdump -netti lo0' I don't see any matches interestingly. So I guess this means the reply is coming from somewhere else. Do you see anything with 'tcpdump -netti pflog0 icmp' when you run the ping? Andy.
Re: Baffling Syntax Errors When Adding altq Rules to pf Firewall
On Wed, Feb 12, 2014 at 9:18 PM, Scott Vanderbilt li...@datagenic.com wrote: I am at my wits' end trying to figure out why I keep getting syntax errors when loading the pf ruleset below. The rules worked fine until I started to add altq rules, in anticipation of adding VOIP service to the local network. I am following the example in Peter Hansteen's tutorial [1] and his Book of PF, more or less. When checking the rule set, pfctl issues syntax errors on the two lines which define my child queues (indented in ruleset below), and I am at a loss to figure what it finds objectionable. WHY DIDN'T YOU QUOTE THE ERROR OUTPUT? This is running OpenBSD 5.5-beta on i386 (Jan. 22 snapshot). The hardware is a Soekris 6501. So you're saying you're running -current, but haven't read http://www.openbsd.org/faq/current.html#20131012 ? Note: the 'queue' keyword should only be changed where it starts a line and not in the middle of the altq line...though you'll want to read pf.conf(5) and replace the altq line Real Soon Now... For those following along at home, here's how I did this: 1) copy provided pf.conf lines into a file /tmp/f 2) since the error message wasn't quoted by the original poster (HINT HINT HINT), run pfctl -f /tmp/f -nv to see if more info was present that the poster left out 3) hmm, darn. Add a blank line and rerun to verify it moves with the 'queue' line. 4) man pf.conf, search for 'queue'. scan some hits; search for 'altq' and get *no* hits. wait, what? 5) read current.html and search for 'altq' (No, really, those were the steps I performed.) Philip Guenther
Re: Baffling Syntax Errors When Adding altq Rules to pf Firewall
On Wed, Feb 12, 2014 at 09:18:09PM -0800, Scott Vanderbilt wrote:
This is running OpenBSD 5.5-beta on i386 (Jan. 22 snapshot).
5.5-beta has the new traffic shaping code in it, and there was an
irresolvable conflict over the 'queue' keyword.
In the general case I would say you could opt to switch over
to the new queues system (which requires a bit of man page reading
or waiting until the refreshed Book of PF that I'm working on comes out)
or for now do a simple search and replace to replace 'queue' with
'oldqueue' and keep most ALTQ setups intact until you have read up on
the new system a bit. But seeing that you use only priorities, you could
skip the queueing for now and just use the priorities that we've
had since OpenBSD 5.0.
This means, ditch this part
altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
queue q_pri on $ext_if priority 7
queue q_def on $ext_if priority 1 priq(default)
and replace this with
match out on $ext_if from $localnet nat-to ($ext_if) queue (q_def, q_pri )
something like
match out on $ext_if from $localnet nat-to ($ext_if) set prio (3, 6)
(the default priority is 3, do the two-priority trick with priorities only,
no queues necessary)
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
Remember to set the evil bit on all malicious network traffic
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
