Re: UPDATE: sysutils/syslog-ng

[Brian A. Seklecki (Mobile)]

SM:

It seems fine.  Tested on 4.4/i386 and 4.3/i386.  Looking forward to it
in 4.5.

2008 Nov  9 03:18:07 -05:00 seawing [syslog-ng][1790] [syslog] [notice]
syslog-ng[1790]: syslog-ng starting up; version='2.1.1'

$ pkg_info -L syslog-ng-2.1.1
Information for inst:syslog-ng-2.1.1

Files:
/usr/local/man/man5/syslog-ng.conf.5
/usr/local/man/man8/syslog-ng.8
/usr/local/sbin/syslog-ng
/usr/local/share/doc/syslog-ng/index.html
/usr/local/share/examples/syslog-ng/syslog-ng.conf.sample

Binary Package:
http://people.collaborativefusion.com/~seklecki/syslog-ng-2.1.1.tgz for
4.4/i386 package.

~BAS

On Wed, 2008-11-05 at 21:40 +0100, Steven Mestdagh wrote:
> Steven Mestdagh [2008-10-08, 21:34:33]:
> > this requires the new sysutils/eventlog port sent earlier.
> > 
> > please test/comment/ok.
> 
> so has no one tested this?
> 
> > 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/sysutils/syslog-ng/Makefile,v
> > retrieving revision 1.8
> > diff -u -r1.8 Makefile
> > --- Makefile6 Oct 2008 16:09:13 -   1.8
> > +++ Makefile8 Oct 2008 19:29:28 -
> > @@ -2,50 +2,39 @@
> >  
> >  COMMENT=   syslogd replacement
> >  
> > +DISTNAME=  syslog-ng-2.1.1
> >  CATEGORIES=sysutils
> >  
> > -DISTNAME=  syslog-ng-1.6.8
> > -LIBOL= libol-0.3.16
> > +MAINTAINER=Steven Mestdagh <[EMAIL PROTECTED]>
> >  
> > -MAINTAINER=Jakob Schlyter <[EMAIL PROTECTED]>
> > +HOMEPAGE = http://www.balabit.com/network-security/syslog-ng/
> >  
> > -MASTER_SITE_SYSLOGNG=\
> > -   http://www.balabit.com/downloads/files/syslog-ng/sources/
> > +# GPL v2
> > +PERMIT_PACKAGE_CDROM = Yes
> > +PERMIT_PACKAGE_FTP =   Yes
> > +PERMIT_DISTFILES_CDROM =   Yes
> > +PERMIT_DISTFILES_FTP = Yes
> >  
> > -MASTER_SITES=  ${MASTER_SITE_SYSLOGNG:=1.6/src/}
> > -MASTER_SITES0= ${MASTER_SITE_SYSLOGNG:=libol/0.3/}
> > +MASTER_SITES = 
> > http://www.balabit.com/downloads/files/syslog-ng/sources/2.1/src/
> >  
> > -HOMEPAGE=  http://www.balabit.com/products/syslog_ng/
> > +WANTLIB =  c iconv intl wrap
> >  
> > -DISTFILES= ${DISTNAME}.tar.gz \
> > -   ${LIBOL}.tar.gz:0
> > +LIB_DEPENDS =  glib-2.0::devel/glib2 \
> > +   evtlog::sysutils/eventlog
> >  
> > -# GPL
> > -PERMIT_PACKAGE_CDROM=  Yes
> > -PERMIT_PACKAGE_FTP=Yes
> > -PERMIT_DISTFILES_CDROM=Yes
> > -PERMIT_DISTFILES_FTP=  Yes
> > -WANTLIB=   c
> > +CONFIGURE_STYLE =  gnu
> > +CONFIGURE_ARGS +=  --enable-tcp-wrapper
> >  
> > -CONFIGURE_STYLE=   gnu
> > -CONFIGURE_ARGS+=   --with-libol=${WRKDIR}/${LIBOL} \
> > -   --enable-tcp-wrapper
> > +DOC =  ${PREFIX}/share/doc/syslog-ng/
> > +EXAMPLES = ${PREFIX}/share/examples/syslog-ng/
> >  
> > -DOC=   ${PREFIX}/share/doc/syslog-ng
> > -EXAMPLES=  ${PREFIX}/share/examples/syslog-ng
> > -
> > -pre-configure:
> > -   cp -f ${PORTSDIR}/infrastructure/db/config.guess \
> > - ${PORTSDIR}/infrastructure/db/config.sub ${WRKDIR}/${LIBOL}
> > -   cd ${WRKDIR}/${LIBOL}; ./configure ; ${MAKE}
> > +post-extract:
> > +   tar -C ${WRKBUILD} -xzf ${WRKSRC}/doc/reference/syslog-ng.html.tar.gz
> >  
> >  post-install:
> > ${INSTALL_DATA_DIR} ${DOC}
> > -   ${INSTALL_DATA} ${WRKSRC}/doc/sgml/*.{ps,sgml,txt} ${DOC}
> > -   (cd ${DOC} ;\
> > -   tar xzf ${WRKSRC}/doc/sgml/syslog-ng.html.tar.gz ;\
> > -   ln -s book1.html syslog-ng.html/index.html )
> > +   ${INSTALL_DATA} ${WRKBUILD}/syslog-ng.html/index.html ${DOC}
> > ${INSTALL_DATA_DIR} ${EXAMPLES}
> > -   ${INSTALL_DATA} ${WRKSRC}/doc/syslog-ng.conf.sample ${EXAMPLES}
> > +   ${INSTALL_DATA} ${WRKSRC}/doc/examples/syslog-ng.conf.sample ${EXAMPLES}
> >  
> >  .include 
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/sysutils/syslog-ng/distinfo,v
> > retrieving revision 1.7
> > diff -u -r1.7 distinfo
> > --- distinfo5 Apr 2007 17:26:13 -   1.7
> > +++ distinfo8 Oct 2008 19:29:28 -
> > @@ -1,10 +1,5 @@
> > -MD5 (libol-0.3.16.tar.gz) = Hym+P0vN21svPZZeePBABg==
> > -MD5 (syslog-ng-1.6.8.tar.gz) = /7rX6ObcvjhYILj/uiO2Ig==
> > -RMD160 (libol-0.3.16.tar.gz) = ts8Hi0sH/EyHm/SicZpto+lvT8Y=
> > -RMD160 (syslog-ng-1.6.8.tar.gz) = EcZ5miRCaYao/ZdDxjQH4ums+mc=
> > -SHA1 (libol-0.3.16.tar.gz) = bW4e+U2Lbdnd2OkkUMXky54wGIo=
> > -SHA1 (syslog-ng-1.6.8.tar.gz) = cIEq8c7jIXlwlcryoK32CvyBpwA=
> > -SHA256 (libol-0.3.16.tar.gz) = aL69o59D/V+hO0ARqRxAsmhP4mKvKkCeKC99mn0o7J4=
> > -SHA256 (syslog-ng-1.6.8.tar.gz) = 
> > PIQf2JWZ/7dwzfKERCaYDXXcPasS4PcH5Mu1GTf2El4=
> > -SIZE (libol-0.3.16.tar.gz) = 345231
> > -SIZE (syslog-ng-1.6.8.tar.gz) = 383589
> > +MD5 (syslog-ng-2.1.1.tar.gz) = f/7jARSKZ41cGLGRDLe+HQ==
> > +RMD160 (syslog-ng-2.1.1.tar.gz) = H/iIJPTV1D3CxjmK6Am8tKas8As=
> > +SHA1 (syslog-ng-2.1.1.tar.gz) = EeX7CzsrnxzgJlGXVVCcMkz0orQ=
> > +SHA256 (syslog-ng-2.1.1.tar.gz) = 
> > is0YN/w

Re: UPDATE: sysutils/syslog-ng

[Brian A. Seklecki]

===
> RCS file: /cvs/ports/sysutils/syslog-ng/pkg/PLIST,v
> retrieving revision 1.5
> diff -u -r1.5 PLIST
> --- pkg/PLIST 19 Sep 2005 13:35:17 -  1.5
> +++ pkg/PLIST 8 Oct 2008 19:29:28 -
> @@ -1,27 +1,9 @@
>  @comment $OpenBSD: PLIST,v 1.5 2005/09/19 13:35:17 jakob Exp $
>  @man man/man5/syslog-ng.conf.5
>  @man man/man8/syslog-ng.8
> -sbin/syslog-ng
> [EMAIL PROTECTED] sbin/syslog-ng
>  share/doc/syslog-ng/
> -share/doc/syslog-ng/syslog-ng.html/
> -share/doc/syslog-ng/syslog-ng.html/book1.html
> -share/doc/syslog-ng/syslog-ng.html/destinations.html
> -share/doc/syslog-ng/syslog-ng.html/index.html
> -share/doc/syslog-ng/syslog-ng.html/intro.html
> -share/doc/syslog-ng/syslog-ng.html/logpath.html
> -share/doc/syslog-ng/syslog-ng.html/msgroute.html
> -share/doc/syslog-ng/syslog-ng.html/reference.html
> -share/doc/syslog-ng/syslog-ng.html/tuning.html
> -share/doc/syslog-ng/syslog-ng.html/x172.html
> -share/doc/syslog-ng/syslog-ng.html/x361.html
> -share/doc/syslog-ng/syslog-ng.html/x728.html
> -share/doc/syslog-ng/syslog-ng.html/x768.html
> -share/doc/syslog-ng/syslog-ng.html/x900.html
> -share/doc/syslog-ng/syslog-ng.html/x906.html
> -share/doc/syslog-ng/syslog-ng.html/x97.html
> -share/doc/syslog-ng/syslog-ng.ps
> -share/doc/syslog-ng/syslog-ng.sgml
> -share/doc/syslog-ng/syslog-ng.txt
> +share/doc/syslog-ng/index.html
>  share/examples/syslog-ng/
>  @sample ${SYSCONFDIR}/syslog-ng/
>  share/examples/syslog-ng/syslog-ng.conf.sample
> 
-- 
Brian A. Seklecki <[EMAIL PROTECTED]>
Collaborative Fusion, Inc.

Re: How to Create an OpenBSD Port and Package

[Brian A. Seklecki]

On Sun, 2008-08-10 at 10:28 -0500, Chris Bennett wrote:
> Thanks,
> that was the problem.
> Cut and paste is mostly helpful ---But...

:set list

...in vim(1) can help find these things.  Also Port Lint ?

Re: vpnc unknown host

[Brian A. Seklecki]

> hostname works.
> 
> Why would this application alone be unable to resolve a hostname?

Try: 

options debug

in resolv.conf(5) to see what the heck its doing wrong.  failing that,
try ktrace(8)/kdump(8).  ~BAS


> Weldon Goree
> 

Re: mod_auth_mysql.so: undefined symbol 'mysql_connect'

[Brian A. Seklecki (Mobile)]

Show:

$ pkg_info | grep -i sql

Also:

$ ldd /usr/lib/apache/modules/mod_auth_mysql.so

Does the reference to the mysql lib have a valid path?  Likely the
package is simply not installed.

~BAS

On Sun, 2008-02-03 at 14:30 -0600, L. V. Lammert wrote:
> At 08:22 PM 2/3/2008 +, Simon H wrote:
> >Hi all
> >
> >I recently inherited an old php/mysql app which I have migrated onto
> >OpenBSD 4.2 with the latest MySQL/PHP packages and modules.
> >
> >I installed the mod_auth_mysql package after realizing the app did
> >basic auth with this backend and when trying to start the server again
> >I get:
> >
> >/usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_mysql.so: undefined
> >symbol 'mysql_connect'
> 
> You don't have a mysql connection - check php_info(), .. are you running 
> chroot'd? If so, test with -u or copy all your libraries into the chroot.
> 
>  Lee
> 
> 
> 
> 
> 
> 
> 




IMPORTANT: This message contains confidential information and is intended only 
for the individual named. If the reader of this message is not an intended 
recipient (or the individual responsible for the delivery of this message to an 
intended recipient), please be advised that any re-use, dissemination, 
distribution or copying of this message is prohibited.  Please notify the 
sender immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system.

Re: Samba 3.0.27a for OpenBSD 4.2-stable

[Brian A. Seklecki (Mobile)]

On Thu, 2007-11-29 at 20:22 +1100, Ian McWilliam wrote:
> Brian A. Seklecki (Mobile) wrote:
> > Here's my CVS diff to make 3.0.27a:

I forgot to mention -- that patch was from the fight to make it work on
4.1-stable.  

I was in a hurry yesterday and fighting 4.2 ports syntax on 4.1 makes
one hostile.  Some stupid autoconf crap (I had enough last week w/
Bacula for two life times)

~BAS


> >
> >   
> I'm interested to know what you tree you diffed this against. 4.2 
> shipped with

Re: Samba 3.0.27a for OpenBSD 4.2-stable

[Brian A. Seklecki (Mobile)]

Here's my CVS diff to make 3.0.27a:


cvs server: Diffing .
Index: Makefile
===
RCS file: /cvs/ports/net/samba/Makefile,v
retrieving revision 1.79
diff -u -r1.79 Makefile
--- Makefile2007/02/06 07:01:13 1.79
+++ Makefile2007/11/28 21:19:39
@@ -3,7 +3,7 @@
 COMMENT-main=  "SMB and CIFS client and server for UNIX"
 COMMENT-docs=  "documentation and examples for samba"
 
-DISTNAME=  samba-3.0.24
+DISTNAME=  samba-3.0.27a
 FULLPKGNAME-docs=  ${DISTNAME:S/-/-docs-/}
 SHARED_LIBS=   smbclient   0.3 \
msrpc   0.2
@@ -42,8 +42,8 @@
 SUBST_VARS= CONFDIR LOCALBASE SYSCONFDIR
 
 SEPARATE_BUILD= concurrent
-AUTOCONF_VERSION= 2.59
-CONFIGURE_STYLE= autoconf
+#AUTOCONF_VERSION= 2.59
+CONFIGURE_STYLE=gnu
 CONFIGURE_ARGS= --localstatedir="/var" \
--sbindir="${PREFIX}/libexec" \
--with-configdir="${CONFDIR}" \
Index: distinfo
===
RCS file: /cvs/ports/net/samba/distinfo,v
retrieving revision 1.6
diff -u -r1.6 distinfo
--- distinfo2007/02/06 07:01:13 1.6
+++ distinfo2007/11/28 21:19:39
@@ -2,3 +2,8 @@
 RMD160 (samba-3.0.24.tar.gz) = f208dca645d07a195169e005a50fb4c4879254eb
 SHA1 (samba-3.0.24.tar.gz) = 216020b58abca191b8146f76f98a8bda3508fcd3
 SIZE (samba-3.0.24.tar.gz) = 17708128
+MD5 (samba-3.0.27a.tar.gz) = 57aedd342cafddbb28e2936c15dde96b
+RMD160 (samba-3.0.27a.tar.gz) =
601c095fdfd5a66e3ce9d57a2d3874d37641ba3f
+SHA1 (samba-3.0.27a.tar.gz) = 4bed2619d2f92ce41f7f84f00537a487c1bef7c9
+SHA256 (samba-3.0.27a.tar.gz) =
33e4998366e30ff7d6bdd70446fe9222badb0d4386d929e3d7cd28933685b6ae
+SIZE (samba-3.0.27a.tar.gz) = 18159377
cvs server: Diffing files
cvs server: Diffing pkg
Index: pkg/PFRAG.shared-main
===
RCS file: /cvs/ports/net/samba/pkg/PFRAG.shared-main,v
retrieving revision 1.1
diff -u -r1.1 PFRAG.shared-main
--- pkg/PFRAG.shared-main   2006/11/25 13:00:41 1.1
+++ pkg/PFRAG.shared-main   2007/11/28 21:19:39
@@ -5,8 +5,6 @@
 lib/samba/charset/
 lib/samba/charset/CP437.so
 lib/samba/charset/CP850.so
[EMAIL PROTECTED] lib/samba/libmsrpc.so.${LIBmsrpc_VERSION}
[EMAIL PROTECTED] lib/samba/libsmbclient.so.${LIBsmbclient_VERSION}
 lib/samba/vfs/
 lib/samba/vfs/audit.so
 lib/samba/vfs/cap.so
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/net/samba/pkg/PLIST-main,v
retrieving revision 1.2
diff -u -r1.2 PLIST-main
--- pkg/PLIST-main  2006/12/14 09:07:56 1.2
+++ pkg/PLIST-main  2007/11/28 21:19:39
@@ -73,11 +73,8 @@
 @man man/man8/nmbd.8
 @man man/man8/pdbedit.8
 @man man/man8/smbd.8
[EMAIL PROTECTED] man/man8/smbmnt.8
[EMAIL PROTECTED] man/man8/smbmount.8
 @man man/man8/smbpasswd.8
 @man man/man8/smbspool.8
[EMAIL PROTECTED] man/man8/smbumount.8
 @man man/man8/swat.8
 @man man/man8/tdbbackup.8
 @man man/man8/tdbdump.8

~BAS


On Fri, 2007-11-23 at 15:30 -0500, Brian A. Seklecki (Mobile) wrote:
> On Fri, 2007-11-23 at 09:35 +1100, Ian McWilliam wrote:
> > Attached is a port of Samba 3.0.27a for people using 4.2-stable.
> 
> Thank you -- I will test on Monday and provide any feedback.
> 
> ~BAS
> 
> > Samba 3.0.27 is a security release to address CVE-2007-4572 
> > <http://samba.org/samba/security/CVE-2007-4572.html> and CVE-2007-5398 
> > <http://samba.org/samba/security/CVE-2007-5398.html>.
> > 
> > http://news.samba.org/releases/3.0.27/
> > 
> > Those of us not running current in production may want to test this.
> > 
> > Ian McWilliam.
> > 
> > 
> > 
> > 
> > 
> > 

Re: Samba 3.0.27a for OpenBSD 4.2-stable

[Brian A. Seklecki]

On Fri, 2007-11-23 at 09:35 +1100, Ian McWilliam wrote:
> Attached is a port of Samba 3.0.27a for people using 4.2-stable.
> 
> Samba 3.0.27 is a security release to address CVE-2007-4572 
>  and CVE-2007-5398 
> .


Either samba updated their tarball (Is it them who likes to do that?) or
the distinfo file included w/ your tarball was wrong:


MD5 (samba-3.0.27a.tar.gz) = 57aedd342cafddbb28e2936c15dde96b
RMD160 (samba-3.0.27a.tar.gz) = 601c095fdfd5a66e3ce9d57a2d3874d37641ba3f
SHA1 (samba-3.0.27a.tar.gz) = 4bed2619d2f92ce41f7f84f00537a487c1bef7c9
SHA256 (samba-3.0.27a.tar.gz) =
33e4998366e30ff7d6bdd70446fe9222badb0d4386d929e3d7cd28933685b6ae
SIZE (samba-3.0.27a.tar.gz) = 18159377

~BAS

> http://news.samba.org/releases/3.0.27/
> 
> Those of us not running current in production may want to test this.
> 
> Ian McWilliam.
> 
> 
> 
> 
> 
> 

Re: Samba 3.0.27a for OpenBSD 4.2-stable

[Brian A. Seklecki (Mobile)]

On Fri, 2007-11-23 at 09:35 +1100, Ian McWilliam wrote:
> Attached is a port of Samba 3.0.27a for people using 4.2-stable.

Thank you -- I will test on Monday and provide any feedback.

~BAS

> Samba 3.0.27 is a security release to address CVE-2007-4572 
>  and CVE-2007-5398 
> .
> 
> http://news.samba.org/releases/3.0.27/
> 
> Those of us not running current in production may want to test this.
> 
> Ian McWilliam.
> 
> 
> 
> 
> 
> 

Syslog-NG 2.0.5 on OpenBSD 4.2

[Brian A. Seklecki]

http://people.collaborativefusion.com/~seklecki/openbsd42_port_syslog-ng205_evtlog025.tar


# pkg_info | egrep -i "syslog|event"
eventlog-0.2.5  eventlog syslog-ng library
syslog-ng-2.0.5 syslogd replacement

# syslog-ng -V
syslog-ng 2.0.5

# uname -a
OpenBSD build-openbsd-i386-42 4.2 GENERIC#375 i386


Pkgsrc is next but I have to catch a bus.

~BAS

# tar tzvf /usr/ports/packages/i386/all/eventlog-0.2.5.tgz 
-r--r--r--  1 root wheel  698 Nov 20 13:56 +CONTENTS
-r--r--r--  1 root wheel  149 Nov 20 13:56 +DESC
-rwxr-xr-x  1 root bin  56325 Nov 20 13:52
lib/libevtlog.so.0.0
-r--r--r--  1 root bin   6602 Nov 20 13:52
include/eventlog/evtlog.h
-r--r--r--  1 root bin   2168 Nov 20 13:52
include/eventlog/evtmaps.h
-rw-r--r--  1 root bin  90848 Nov 20 13:52 lib/libevtlog.a
-rwxr-xr-x  1 root bin811 Nov 20 13:52 lib/libevtlog.la
-r--r--r--  1 root bin237 Nov 20 13:52
lib/pkgconfig/eventlog.pc


# tar tzvf /usr/ports/packages/i386/all/syslog-ng-2.0.5.tgz 
-r--r--r--  1 root wheel  528 Nov 20 14:23 +CONTENTS
-r--r--r--  1 root wheel  568 Nov 20 14:23 +DESC
-r--r--r--  1 root bin   5899 Nov 20 14:23
man/man5/syslog-ng.conf.5
-r--r--r--  1 root bin   3268 Nov 20 14:23
man/man8/syslog-ng.8
-r-xr-xr-x  1 root bin1215516 Nov 20 14:23 sbin/syslog-ng

Bacula 2.2.6 Client for OpenBSD 4.1/i386 (back/foward Port)

[Brian A Seklecki (Mobile)]

All:

OpenBSD 4.1 still has 6-9 months before EOS/EOL.  Here are the Bacula
2.2.6 client-only binaries for OpenBSD 4.1/i386 (back/forward Port)

-Backport for Bacula (Bacula was added to ports after 4.1)
-Forward port for OpenBSD (Port version is 2.0.x still)

http://people.collaborativefusion.com/~seklecki/bacula-2.2.6.tgz
http://people.collaborativefusion.com/~seklecki/bacula-client-2.2.6.tgz
http://people.collaborativefusion.com/~seklecki/openbsd_41_bacula_226_clientlony.diff

The patch is hella-ugly since the Ports infrastructure changed massively
between 4.1 and 4.2.

http://people.collaborativefusion.com/~seklecki/obsd_bacula.html

-

bofh-fd Version: 2.2.6 (10 Nov 2007) i386-unknown-openbsd4.1 openbsd 4.1
Daemon started 20-Nov-07 12:00, 0 Jobs run since started.
 Heap: heap=0 smbytes=14,195 max_bytes=23,546 bufs=56 max_bufs=99
 Sizeof: boffset_t=8 size_t=4 debug=0 trace=0

Running Jobs:

$ tar tzvf bacula-client-2.2.6.tgz 
-rw-r--r--  0 root   wheel 925 Nov 20 11:57 +CONTENTS
-rw-r--r--  0 root   wheel 881 Nov 20 11:57 +DESC
-rw-r--r--  0 root   wheel 329 Nov 20 11:57 +DISPLAY
-rwxr-xr--  0 root   bin   5027 Nov 20 11:57
libexec/bacula/bacula-ctl-fd
-rw-r--r--  0 root   bin   687 Nov 20 11:57 man/man8/bacula-fd.8.gz
-rwxr-xr--  0 root   bin453341 Nov 20 11:57 sbin/bacula-fd
-r--r--r--  0 root   bin   972 Nov 20 11:57
share/examples/bacula/bacula-fd.conf



~BAS

Re: PATCH: net-snmp-5.4.1p1 for sparc64

[Brian A. Seklecki]

On Sun, 2007-10-07 at 11:56 +0200, Rolf Sommerhalder wrote:
> The patch below resolves a "Arithmetic exception (core dumped)" when
> performing once snmwalk or snmpget access agent hardware memory
> information. Also, on sparc64 the unpatched snmpd consumes all CPU and

RS: You'll want to fwd this onto:

  Thomas Anders <[EMAIL PROTECTED]>  

He has been very useful and receptive in the past to accepting upstreams
commits for bsd-specific bugs.  So has: 

   Dave Shield <[EMAIL PROTECTED]>   

~BAS

> memory resources within minutes after starting as in the background.
> Interestingly, if run in the foreground (snmpd -f)., it does not hog
> those resources and behaves.
> 
> Without this patch, these problems occur on sparc64-current, whereas
> on i386-current I did not observe them. I noticed the problems already
> in 4.1 and before upgrading to net-snmp-5.4.1, but back then, I never
> got around to track it down.
> 
> Please test and propose improvements for my somewhat naive,
> quick&dirty patch before committing. I do not understand the details
> of sysctl and uvmexp yet, thus just used getpagesize(3).
> 
> OK on sparc64.
> 
> Thanks,
> Rolf
> 
> 
> # diff -urN net-snmp net-snmp-5.4.1p1
> diff -urN net-snmp/Makefile net-snmp-5.4.1p1/Makefile
> --- net-snmp/Makefile   Wed Sep 26 22:03:42 2007
> +++ net-snmp-5.4.1p1/Makefile   Sun Oct  7 09:40:05 2007
> @@ -4,7 +4,7 @@
>  COMMENT-perl=  SNMP modules for Perl
> 
>  DISTNAME=  net-snmp-5.4.1
> -PKGNAME-main=  ${DISTNAME}
> +PKGNAME-main=  ${DISTNAME}p1
>  PKGNAME-perl=  p5-SNMP-5.4.1
>  SHARED_LIBS=   netsnmp 7.0 \
> netsnmpagent7.0 \
> diff -urN 
> net-snmp/patches/patch-agent_mibgroup_hardware_memory_memory_netbsd_c
> net-snmp-5.4.1p1/patches/patch-agent_mibgroup_hardware_memory_memory_netbsd_c
> --- net-snmp/patches/patch-agent_mibgroup_hardware_memory_memory_netbsd_c
>   Thu Jan  1 01:00:00 1970
> +++ 
> net-snmp-5.4.1p1/patches/patch-agent_mibgroup_hardware_memory_memory_netbsd_c
>   Sun Oct  7 09:42:54 2007
> @@ -0,0 +1,29 @@
> +--- agent/mibgroup/hardware/memory/memory_netbsd.c.orig Mon Mar  6
> 17:23:52 2006
>  agent/mibgroup/hardware/memory/memory_netbsd.c  Sun Oct  7
> 09:33:56 2007
> +@@ -30,7 +30,11 @@
> + long   pagesize;
> +
> + struct uvmexp  uvmexp;
> +-intuvmexp_size  = sizeof(uvmexp);
> ++#ifdef __OpenBSD__
> ++ size_tuvmexp_size  = sizeof(uvmexp);
> ++#else
> ++ int   uvmexp_size  = sizeof(uvmexp);
> ++#endif
> + intuvmexp_mib[] = { CTL_VM, VM_UVMEXP };
> +
> + struct vmtotal total;
> +@@ -50,7 +54,11 @@
> + sysctl(total_mib,2, &total,&total_size,NULL, 0);
> + sysctl(phys_mem_mib, 2, &phys_mem, &mem_size,  NULL, 0);
> + sysctl(user_mem_mib, 2, &user_mem, &mem_size,  NULL, 0);
> +-pagesize = uvmexp.pagesize;
> ++#ifdef __OpenBSD__
> ++ pagesize = getpagesize();
> ++#else
> ++ pagesize = uvmexp.pagesize;
> ++#endif
> +
> + /*
> +  * ... and save this in a standard form.
> +
> #
> 
> 
> Here is an illustration of the problem on sparc64-current
> 
> A) snmpd.conf is minimal:
> 
> # cat /etc/snmp/snmpd.conf
> rocommunity  public
> 
> 
> B) snmpd run in the foreground within gdb
> 
> [EMAIL PROTECTED]:snmp]# gdb /usr/local/sbin/snmpd
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "sparc64-unknown-openbsd4.2"...(no
> debugging symbols found)
> 
> (gdb) run -f -Lo -D
> ..
> verbose:sess_select: timer due in 4.996670 sec
> verbose:sess_select: setting timer to 4.996670 sec, clear block (was 0)
> trace: receive(): snmpd.c, 1144:
> snmpd/select: select( numfds=12, ..., tvp=0xfffead10)
> trace: receive(): snmpd.c, 1146:
> timer: tvp 4.996670
> trace: receive(): snmpd.c, 1148:
> snmpd/select: returned, count = 0
> trace: run_alarms(): snmp_alarm.c, 251:
> snmp_alarm: run alarm 2
> trace: netsnmp_cpu_get_byIdx(): hardware/cpu/cpu.c, 69:
> cpu: cpu_get_byIdx -1 (found)
> trace: netsnmp_cpu_get_byIdx(): hardware/cpu/cpu.c, 69:
> cpu: cpu_get_byIdx 0 (found)
> trace: run_alarms(): snmp_alarm.c, 253:
> snmp_alarm: alarm 2 completed
> trace: snmp_sess_select_info(): snmp_api.c, 5868:
> sess_select: for all sessions: 11 7
> sess_select: next alarm 4.996349 sec
> verbose:sess_select: timer due in 4.996349 sec
> verbose:sess_select: setting timer to 4.996349 sec, clear block (was 0)
> trace: receive(): snmpd.c, 1144:
> snmpd/select: select( numfds=12, ..., tvp=0xfffead10)
> trace: receive(): snmpd.c, 1146:
> timer: tvp 4.996349
> ..
> {
>  C) the above repeats until we launch from another host:
>   $ snmpwalk -v 2c -c 

Re: Merging Joel Knight's SNMP MIB into net/net-snmp

[Brian A. Seklecki]

Oh god please yes!  

I'm working on pfsync and a general "OPENBSD-NETSTAT-MIB" for feeding
"netstat -s" stats into a MIB.

I've also written a small Nagios plugin that uses the Net-SNMP bindings
to walk the CARP Interface Status Table
("OPENBSD-CARP-MIB::carpIfTable") to check for proper active/standby
configs:

http://www.nagiosexchange.org/Networking.53.0.html?&tx_netnagext_pi1[p_view]=1021


There's also a check_pf:

http://www.nagiosexchange.org/Networking.53.0.html?&tx_netnagext_pi1[p_view]=895


Also, I'm hoping to switch one of or lab policy routers back to pf(4)
this weekend, and I'll be able to improve my OBENBSD-PF-MIB MRTG
Templates and upload them (*hopefully*) to:

http://howto.aphroland.org/HOWTO/MRTG//

Which seems to be the definitive MRTG Template/OID Reference (if such a
place exists -- MRTG is almost 10 years old and that idea never occurred
to anyone), but the site has been unresponsive as of late.

Might be time for a separate Wiki.

~BAS

On Tue, 2007-06-26 at 15:48 -0600, Christopher Snell wrote:
> Hi,
> 
> Has anybody considered merging Joel Knight's OpenBSD SNMP MIB work
> into ports/net-snmp?  His patch works great and has been in production
> here at Backcountry.com for six months now.  OpenBSD probably will
> want it's own enterprise number, too.
> 
> I'm willing to lend a hand, if it's needed.
> 
> Thanks,
> 
> Chris
> 

> 
-- 
Brian A. Seklecki <[EMAIL PROTECTED]>
Collaborative Fusion, Inc.




IMPORTANT: This message contains confidential information and is intended only 
for the individual named. If the reader of this message is not an intended 
recipient (or the individual responsible for the delivery of this message to an 
intended recipient), please be advised that any re-use, dissemination, 
distribution or copying of this message is prohibited.  Please notify the 
sender immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system.

[Samhain-announce] samhain 2.3.3 (fwd)

[Brian A. Seklecki]

FYI to the maintainer: new OpenBSD kernel support (I haven't tested yet)

~BAS

l8*
-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
   http://www.spiritual-machines.org/

-- Forwarded message --
Date: Tue, 27 Mar 2007 23:46:30 +0200
From: Announcement list for samhain <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Samhain-announce] samhain 2.3.3

Dear Sir / Madam,

version 2.3.3 of the samhain file integrity / intrusion detection tool has
been released and can be downloaded from:
http://la-samhna.de/samhain/samhain-current.tar.gz

Changes:


 - kernel check supports OpenBSD 4
 - on Linux, kernel check also checks PCI ROMs
 - incompatibilities of the samhain_hide module with
   kernel 2.6.19/2.6.20 have been fixed
 - workaround for a libmysql bug on x86-64
 - cross-compiling has been fixed
 - closing open file descriptors on startup has been
   modified to fix problems with prelude
 - a bug has been fixed that caused incorrect reporting
   of a double leading slash for the target of symlinks
   in the root directory

best regards,
rainer
___
samhain labs / support http://www.la-samhna.de [EMAIL PROTECTED]

Please do not reply to this message, as it was sent from an unattended
mailbox. Instead, mail to [EMAIL PROTECTED] for any questions.
You are receiving this mail because you are subscribed to the announcement
mailing list for the samhain file integrity checking / intrusion detection
system. To unsubscribe, please visit:
http://lists.la-samhna.de/listinfo/samhain-announce

OpenBSD ports snmpd Net-SNMP Segfault Sig11 Update

[Brian A. Seklecki]

Just as an FYI:  I went to go revisit this via our internal ticket system 
and found that the 5.4 binaries from an experimental unofficial 
port/package someone sent me have been running fine and stable without 
segfaults for 4+ months.


I highly recommend that the port maintainers consider bringing in 5.4 into 
the -current ports tree for the 4.1-RELEASE


~~BAS


On Wed, 28 Feb 2007, Brian A. Seklecki wrote:



No it still rocks out a segfault for me even with the experimental version 
(5.3) that Opti circulated.


~BAS

On Wed, 28 Feb 2007, Lauren Austin wrote:


Hi Brian,

I saw your posting about getting a sig 11 segfault in net-snmp-5.1.3p4 on 
OpenBSD 4.0/i386 but I didn't see a summary so don't know if you sorted it?


I was getting a similar problem with the same versions of net-snmp and 
OpenBSD - snmpd would run for a couple of minutes then core dump with a 
segmentation fault.


I had in my snmpd.conf the lines:

Re: [Bacula-users] Building bacula on OpenBSD

[Brian A. Seklecki]

spital
> > 30 Bond Street
> > Toronto, Ontario
> > M5B 1W8
> > 
> > Office: 416-864-5981
> > 
> > e-Mail: [EMAIL PROTECTED]
> > www.stmichaelshospital.com
> > 
> > On 13/12/06, Kern Sibbald <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > Since this is directed to me, and assuming I wrote the double >>'ed
> > sections
> > > below (which sound a lot like me but so much is snipped that I cannot
> > be
> > > sure), I can assure you that, my intention, if I am the guity party
> > was not
> > > to insult any person or any particular OS, but just to point out that
> > it
> > > appears to me to be an OS compatibility problem (actually a system
> > header
> > > file to be more correct).
> > >
> > > See notes below, where I assume that I wrote the offending statements:
> > >
> > > On Wednesday 13 December 2006 18:28, Brian A. Seklecki wrote:
> > > > > > Stop in /usr/local/src/bacula-1.38.11/src/stored.
> > > > >
> > > > > It looks to me like the OS' header file is badly broken -- at
> > least in the
> > > > > sense that if it is a Unix system, both mt_fileno and mt_blkno
> > should be
> > > > > defined in the struct mtget.
> > > > >
> > > > > Someone should fix the OS, barring that we will need a patch.
> > > >
> > > > Kern, Rus, et al:
> > > >
> > > > We have to be really careful with regard how we word things here. 
> > The
> > > > way you assert that could be easily misinterpreted or misconstrued
> > to
> > > > have a vendor-bashing tone.
> > >
> > > I'm sorry, I did not intend to be vendor bashing.  I stand by what is
> > written.
> > > If it is a Unix system and there are not mt_fileno and mt_blkno in the
> > struct
> > > mtget, there are serious compatibility problems, since I don't have an
> > > OpenBSD system, assuming the OS is not going to change, we would need
> > a patch
> > > to Bacula to fix it.
> > >
> > > >
> > > > Moreover, conceding the unavailability of compatibility with the
> > OpenBSD
> > > > platform doesn't gain us any additional users; a very large group of
> > > > talented individuals with tremendous experience writing highly
> > secure,
> > > > reliable, and _portable_ code who could contribute greatly to the
> > > > project.
> > > >
> > > > -- To set the record straight, and encourage mutual cooperation --
> > > >
> > > > The reality here is that OpenBSD is very selective about where it
> > > > focuses its development efforts, and the st(4) driver is not one of
> > > > those places.
> > > >
> > > > Therefore, the assertion that "The OS is broken" is not correct, it
> > > > simply hasn't been implemented or maintained as it should.
> > >
> > > Yes, broken was a poor choice of words.  I would rephrase it to say it
> > is not
> > > Unix compatible.
> > >
> > > >
> > > > Before I go on and make my own silly assertions, I should note: '
> > > >
> > > >Things are always subject to change, and this is F/OSS and you're
> > > >always welcome to do the work yourself or have corporate
> > sponsorship.
> > > >
> > > > OpenBSD is not the platform for a Bacula director.  You wont see it
> > (at
> > > > present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte
> > StorageTek
> > > > Powderhorn Tape Silo connected via Brocade FC switches.(1)
> > > >
> > > > However you will see it at the perimeter and on the wire keeping the
> > > > packet kiddies from stealing all of your customers data.  It could
> > be
> > > > the ideal system for the job with features like enhanced crypto
> > > > acceleration via crypto(9) and the existing improvements on scsi(4)
> > and
> > > > recent HBA support.
> > > >
> > > > Anyway, not a director, not now at least, and probably not a SD
> > Storage
> > > > Daemon either.
> > >
> > > Yes, since the problem above arises when compiling the SD.
> > >
> > > >
> > > > But most definitely a management console and file daemon.
> > >
> > > I think these already exist.  Bacula does have some code t

Re: override '@cwd /usr/local' with -L on pkg_add(8)

[Brian A. Seklecki]

You want to help ? Try to build a full ports tree with
LOCALBASE != /usr/local, and report breakage and write patches so
that this can work.


I thought about this -- as a work around, rebuild all of my packages with 
LOCALBASE=/, but that gets tricky because you can potentially pollute your 
build environment.  I also considered many of the pkg_create(8) flags.



There's absolutely no sense in adding buttons
that will fail a lot of the time, or work only in very limited
circumstances, to the base tools.


I'm just trying to find a mutually agreeable set of flags that
accomplish the same functionality on three platforms.

$PKG_DBDIR   $PREFIX/$LOCALBASE/$PKG_DESTDIR
[-K pkg_dbdir]   [-p prefix]

I just wanted to confirm with someone (you) that the best thing to do is 
work-around this caveat instead of reinventing the wheel.


~BAS


Our top-priority is reliability.  User tweaks is fairly low.

If you want to diverge from the OpenBSD tools, you're free.
The package infrastructure is fairly open, and the tools are way easier
to tweak than the freebsd/netbsd ones, because they've been engineered
that way, as layers you can modify and test very easily (yes, perl is
a deliberate decision, and it helps a lot there).



l8*
    -lava (Brian A. Seklecki - Pittsburgh, PA, USA)
   http://www.spiritual-machines.org/

"...from back in the heady days when "helpdesk" meant nothing, "diskquota"
meant everything, and lives could be bought and sold for a couple of pages
of laser printout - and frequently were."

override '@cwd /usr/local' with -L on pkg_add(8)

[Brian A. Seklecki]

Why do we declare this static here?  Other systems set plist entries 
relative to @LOCALBASE@ or $PREFIX or something relative.  We have -L, but 
it won't actually permit for changes to binary packages at install time.


I've got a system similar to:

/sandbox
$USR_ROOT = /sandbox/usr_root
$RD_ROOT = /sandbox/rd_root

These file systems must be parallel in a build environment heirachy. 
They cannot be a heirachy of each other (temp MFS mounts, chroot, disk 
space estimation code, etc.).


So essentially:

case $platform in
openbsd*|freebsd*)
 PKG_DIRNAME=local
 ;;
netbsd*)
 PKG_DIRNAME=pkg
 ;;
esac

Then:
PKG_LIST="bash-3.2 libiconv-1.9.2p3 expat-2.0.0\
gettext-0.14.6"

export PKG_PATH=/usr/ports/packages/i386/all
export PKG_DBDIR=${RD_ROOT}/var/db/pkg/
export PKG_DESTDIR=${USR_ROOT}/${PKG_DIRNAME}
export LOCALBASE=${USR_ROOT}/${PKG_DIRNAME}

pkg_add -L / -f libdepends $PKG_LIST

This approach (different pkg_add(8) flags works fine in NetBSD/FreeBSD, 
but that's because they rely on $PREFIX being inherited from the 
environment.


But:

obsd# pkg_add -L / -v -f libdepend bash-3.2 libiconv-1.9.2p3 expat-2.0.0

Localbase mismatch: package has: /usr/local , user wants: /
/usr/sbin/pkg_add: bash-3.2:Fatal error

However, I *can* do:

# pkg_add -{B,Q} $PKG_DESTDIR -v -f libdepend [packages]

But I'll end up with:

/sandbox/usr_root/usr/local/_/usr/local/{bin,lib,etc.}_

In theory, following the OpenBSD ports approach, I would set $PKG_DESTDIR 
to /sandbox; and symlink usr_root/ to usr/, but that's dangerous because 
/sandbox/usr_root is an entirely arbitrary path that the user can set (and 
it may be a symlink itself)


I'll work-around this limitation for now by telling pax(1) to use:

cd ${USR_ROOT}/${PKG_DIRNAME}/usr/local/ && pax [flags] when $platform = 
openbsd.


But that's cheap and dirtythere areally are some nasty assumptions 
flying around in the current approach that are not conducive to building 
embedded systems where you're assembling your desination file system on a 
build host.


Another nasty one is checking for libc dependency (and presumably by 
implication a specific minimum OpenBSD version) in packages.  Of course, I 
can work around that with -f libdepends ... but this is a whole new issue.


One approach I may try to take to solve this problem is to forgoe "make 
package" and use pkg_create(1) with a varety of flags, but that doesn't 
look very promising right now.



l8*
-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
   http://www.spiritual-machines.org/

Re: [Nagiosplug-devel] nagios check_carp for OpenBSD carp(4)

[Brian A. Seklecki]

Chris:

Right, when I have a second here, I was going to ry to merge the PF-MIB 
patch into opti@'s new version of Net-SNMP 5.4 (the PF-MIB I have right 
now is for the old-school ucd-snmp !)


http://www.packetmischief.ca/openbsd/snmp/

~BAS

On Mon, 18 Dec 2006, Christopher Snell wrote:


On 12/15/06, Brian A. Seklecki <[EMAIL PROTECTED]> wrote:

Thoughts? Strategies? Ideas?
---

Ask the machine directly? Ask an adjacent machine?


Joel Knight just released an updated OpenBSD SNMP MIB that supports
reading data from the sensors framework.  Perhaps he could be
persuaded to add support for CARP state detection?  :)

Chris

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Nagios Plugin Development Mailing List [EMAIL PROTECTED]
Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null



l8*
-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
   http://www.spiritual-machines.org/

"...from back in the heady days when "helpdesk" meant nothing, "diskquota"
meant everything, and lives could be bought and sold for a couple of pages
of laser printout - and frequently were."

Re: UPDATE net/net-snmp

[Brian A. Seklecki]

I rolled the 5.4 opti@ supplied this morning.  We'll see how it does.  The 
only thing that I had to do with the tarball was regen pkg/{PLIST,PFRAG}*.


# sudo /usr/local/sbin/snmpd -f -Ls 1  10.0.0.3:161
Dec 18 09:22:17 br0 snmpd[11804]: NET-SNMP version 5.4

Also, we have to talk about PF-MIB in a _big_ way.

Thomas: I'll be in touch with you soon off-list soon.

~BAS

On Tue, 28 Nov 2006, Marc Balmer wrote:


* Tim Kornau wrote:


- The shared libs probably need a major version bump.


i just did that but it is in my opinion not a major version bump but
we can adress this later on when the other issues are fixed.


did the API change?  Did a structure in a header change? Bump the major.

did an API get extended (by a new function)?  Bumb the minor.




l8*
    -lava (Brian A. Seklecki - Pittsburgh, PA, USA)
   http://www.spiritual-machines.org/

Re: [Bacula-users] Building bacula on OpenBSD

[Brian A. Seklecki]

On Wed, 2006-12-13 at 19:27 +0100, Kern Sibbald wrote:
> On Wednesday 13 December 2006 18:28, Brian A. Seklecki wrote:
> > > > Stop in /usr/local/src/bacula-1.38.11/src/stored.
> > > 
> > > It looks to me like the OS' header file is badly broken -- at
> least in the 
> > > sense that if it is a Unix system, both mt_fileno and mt_blkno
> should be 
> > > defined in the struct mtget.
> > > 
> > > Someone should fix the OS, barring that we will need a patch.
> > 
> > Kern, Rus, et al:
> > 
> > We have to be really careful with regard how we word things here.
> The
> > way you assert that could be easily misinterpreted or misconstrued
> to
> > have a vendor-bashing tone.
> 
> I'm sorry, I did not intend to be vendor bashing.  I stand by what is
> written. 
> If it is a Unix system and there are not mt_fileno and mt_blkno in the
> struct 
> mtget, there are serious compatibility problems, since I don't have
> an 
> OpenBSD system, assuming the OS is not going to change, we would need
> a patch 
> to Bacula to fix it.

Coincidental, regarding a post from Theo:

From: Theo de Raadt <[EMAIL PROTECTED]> 
 
To:[EMAIL PROTECTED]
   
Subject: www.openbsd.org/want.html  
   

   
various developers have added new entries to the "want list"
   
at www.openbsd.org/want.html
   

   
it would be nice if people would review the page again, to see if they  
  


There is a entry for:

--
"SCSI tape changers (libraries) for hacking on ch(4), st(4) and related
utilities needed in Alberta, Canada. Contact [EMAIL PROTECTED]"
--

So perhaps, if someone is willing to donate the hardware, there is a
bright future for mtio(4), mt(8), ch(4), st(4), and friends

We have an OEM dell unit that we could donate; but the picker
meta-device no longer probes on the SCSI bus; only the drive.  It has to
be manually operated via the LCD on the front.

~~BAS


> > 
> > Moreover, conceding the unavailability of compatibility with the
> OpenBSD
> > platform doesn't gain us any additional users; a very large group of
> > talented individuals with tremendous experience writing highly
> secure,
> > reliable, and _portable_ code who could contribute greatly to the
> > project.
> > 
> > -- To set the record straight, and encourage mutual cooperation -- 
> > 
> > The reality here is that OpenBSD is very selective about where it
> > focuses its development efforts, and the st(4) driver is not one of
> > those places.
> > 
> > Therefore, the assertion that "The OS is broken" is not correct, it
> > simply hasn't been implemented or maintained as it should.
> 
> Yes, broken was a poor choice of words.  I would rephrase it to say it
> is not 
> Unix compatible.
> 
-- 
Brian A. Seklecki <[EMAIL PROTECTED]>
Collaborative Fusion, Inc.

Re: [Bacula-users] Building bacula on OpenBSD

[Brian A. Seklecki]

Just adding readline and OpenSSL support.  Good to go now.

...OpenBSD doesn't have a "portlint" equiv, does it?

~BAS

On Wed, 13 Dec 2006, GUILLON Gabriel wrote:


This link:
http://people.collaborativefusion.com/~seklecki/bacula_openbsd_port.tar

seems to be broken

Brian A. Seklecki a écrit :


Here is a functional FD on OpenBSD 4.0/i386:

bash-3.2# uname -a
OpenBSD vmware-sandbox.pgh.priv.collaborativefusion.com 4.0
GENERIC.MP+RAIDFRAME#1

bash-3.2# /usr/local/sbin/bacula-fd -u root -g wheel  -d128 -v -c
/usr/local/etc/bacula-fd.conf -f
vmware-sandbox-fd: jcr.c:129 read_last_jobs seek to 188
vmware-sandbox-fd: jcr.c:136 Read num_items=0
vmware-sandbox-fd: filed.c:223 filed: listening on port 9102
vmware-sandbox-fd: bnet_server.c:98 Addresses host[ipv4:0.0.0.0:9102]
vmware-sandbox-fd: bnet.c:1154 who=client host=192.168.4.55 port=36387
vmware-sandbox-fd: find.c:81 init_find_files ff=-7e0f0be8
vmware-sandbox-fd: job.c:216  ssl=0
vmware-sandbox-fd: cram-md5.c:131 cram-get: auth cram-md5
<[EMAIL PROTECTED]> ssl=0
vmware-sandbox-fd: cram-md5.c:150 sending resp to challenge:
TS/yz8d8e9BM/gxwO9++iC
vmware-sandbox-fd: job.c:341 OK Authenticate
vmware-sandbox-fd: job.c:216 http://people.collaborativefusion.com/~seklecki/obsd_bacula.html

This illustrates basic support.

I've submited sendbug(1) to OpenBSD GNATS, but it does not appear to
have made it through:

bash-3.2$ Nov 12 09:08:11 vmware-sandbox sm-mta[10302]: kACE7scF013066:
to=<[EMAIL PROTECTED]>,
ctladdr=<[EMAIL PROTECTED]>
(1016/10), delay=00:00:16, xdelay=00:00:16, mailer=esmtp, pri=31100,
relay=cvs.openbsd.org. [199.185.137.3], dsn=4.3.0, stat=Deferred: 451
Temporary failure, please try again later.

Possibly greylisting....~

~BAS


On Wed, 13 Dec 2006, Brian A. Seklecki wrote:


Stop in /usr/local/src/bacula-1.38.11/src/stored.


It looks to me like the OS' header file is badly broken -- at least
in the
sense that if it is a Unix system, both mt_fileno and mt_blkno should be
defined in the struct mtget.

Someone should fix the OS, barring that we will need a patch.


Kern, Rus, et al:

We have to be really careful with regard how we word things here.  The
way you assert that could be easily misinterpreted or misconstrued to
have a vendor-bashing tone.

Moreover, conceding the unavailability of compatibility with the OpenBSD
platform doesn't gain us any additional users; a very large group of
talented individuals with tremendous experience writing highly secure,
reliable, and _portable_ code who could contribute greatly to the
project.

-- To set the record straight, and encourage mutual cooperation --

The reality here is that OpenBSD is very selective about where it
focuses its development efforts, and the st(4) driver is not one of
those places.

Therefore, the assertion that "The OS is broken" is not correct, it
simply hasn't been implemented or maintained as it should.

Before I go on and make my own silly assertions, I should note: '

  Things are always subject to change, and this is F/OSS and you're
  always welcome to do the work yourself or have corporate sponsorship.

OpenBSD is not the platform for a Bacula director.  You wont see it (at
present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek
Powderhorn Tape Silo connected via Brocade FC switches.(1)

However you will see it at the perimeter and on the wire keeping the
packet kiddies from stealing all of your customers data.  It could be
the ideal system for the job with features like enhanced crypto
acceleration via crypto(9) and the existing improvements on scsi(4) and
recent HBA support.

Anyway, not a director, not now at least, and probably not a SD Storage
Daemon either.

But most definitely a management console and file daemon.

Russel: You'll probably notice that Bacula builds perfectly fine up
until it gets to the director, then you get into OS-specific kernel
knits and hooks where either OpenBSD lacks the framework/API (pthreads,
st(4), etc.) or kernel-specific code needs to be added to Bacula.

In the mean time, we should endeavor to create a "bacula-clientonly"
Port in OpenBSD ports, or "bacula" port with a "clientonly" flavor.

This has been done before, but the work was never commited (CC:)

1. http://www.arsc.edu/resources/silo.html

I will take the lead on this if I have to.

~BAS



I checked the man page for st, where all other Unix systems define
the packet.
They include no definition, so you will need to consult the header file
directly sys/mtio.h.   Sorry, but you are pretty much on your own on
this.






  == Error in /usr/local/src/bacula-1.38.11/src/stored ==


==>Entering directory /usr/local/src/bacula-1.38.11/src/tools
 Make of tools is good 







l8*
-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
   http://www.spiritual-machines.org/

"...from back in the heady days when "helpdesk"

Re: [Bacula-users] Building bacula on OpenBSD

[Brian A. Seklecki]

Here is a functional FD on OpenBSD 4.0/i386:

bash-3.2# uname -a
OpenBSD vmware-sandbox.pgh.priv.collaborativefusion.com 4.0 
GENERIC.MP+RAIDFRAME#1


bash-3.2# /usr/local/sbin/bacula-fd -u root -g wheel  -d128 -v -c 
/usr/local/etc/bacula-fd.conf -f

vmware-sandbox-fd: jcr.c:129 read_last_jobs seek to 188
vmware-sandbox-fd: jcr.c:136 Read num_items=0
vmware-sandbox-fd: filed.c:223 filed: listening on port 9102
vmware-sandbox-fd: bnet_server.c:98 Addresses host[ipv4:0.0.0.0:9102]
vmware-sandbox-fd: bnet.c:1154 who=client host=192.168.4.55 port=36387
vmware-sandbox-fd: find.c:81 init_find_files ff=-7e0f0be8
vmware-sandbox-fd: job.c:216 vmware-sandbox-fd: cram-md5.c:71 send: auth cram-md5 
<[EMAIL PROTECTED]> ssl=0
vmware-sandbox-fd: cram-md5.c:131 cram-get: auth cram-md5 
<[EMAIL PROTECTED]> ssl=0
vmware-sandbox-fd: cram-md5.c:150 sending resp to challenge: 
TS/yz8d8e9BM/gxwO9++iC

vmware-sandbox-fd: job.c:341 OK Authenticate
vmware-sandbox-fd: job.c:216 Job=*Console*.2006-12-13_13.09.33 SDid=0 SDtime=0 Authorization=dummy

vmware-sandbox-fd: job.c:232 Executing JobId= command.
vmware-sandbox-fd: job.c:435 JobId=0 Auth=dummy
vmware-sandbox-fd: job.c:216 Executing status command.

vmware-sandbox-fd: job.c:322 Calling term_find_files
vmware-sandbox-fd: job.c:325 Done with term_find_files
vmware-sandbox-fd: job.c:327 Done with free_jcr

The code for this may be found at:

http://people.collaborativefusion.com/~seklecki/obsd_bacula.html

This illustrates basic support.

I've submited sendbug(1) to OpenBSD GNATS, but it does not appear to have 
made it through:


bash-3.2$ Nov 12 09:08:11 vmware-sandbox sm-mta[10302]: kACE7scF013066: 
to=<[EMAIL PROTECTED]>, 
ctladdr=<[EMAIL PROTECTED]> 
(1016/10), delay=00:00:16, xdelay=00:00:16, mailer=esmtp, pri=31100, 
relay=cvs.openbsd.org. [199.185.137.3], dsn=4.3.0, stat=Deferred: 451 
Temporary failure, please try again later.


Possibly greylisting~

~BAS


On Wed, 13 Dec 2006, Brian A. Seklecki wrote:


Stop in /usr/local/src/bacula-1.38.11/src/stored.


It looks to me like the OS' header file is badly broken -- at least in the
sense that if it is a Unix system, both mt_fileno and mt_blkno should be
defined in the struct mtget.

Someone should fix the OS, barring that we will need a patch.


Kern, Rus, et al:

We have to be really careful with regard how we word things here.  The
way you assert that could be easily misinterpreted or misconstrued to
have a vendor-bashing tone.

Moreover, conceding the unavailability of compatibility with the OpenBSD
platform doesn't gain us any additional users; a very large group of
talented individuals with tremendous experience writing highly secure,
reliable, and _portable_ code who could contribute greatly to the
project.

-- To set the record straight, and encourage mutual cooperation --

The reality here is that OpenBSD is very selective about where it
focuses its development efforts, and the st(4) driver is not one of
those places.

Therefore, the assertion that "The OS is broken" is not correct, it
simply hasn't been implemented or maintained as it should.

Before I go on and make my own silly assertions, I should note: '

  Things are always subject to change, and this is F/OSS and you're
  always welcome to do the work yourself or have corporate sponsorship.

OpenBSD is not the platform for a Bacula director.  You wont see it (at
present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek
Powderhorn Tape Silo connected via Brocade FC switches.(1)

However you will see it at the perimeter and on the wire keeping the
packet kiddies from stealing all of your customers data.  It could be
the ideal system for the job with features like enhanced crypto
acceleration via crypto(9) and the existing improvements on scsi(4) and
recent HBA support.

Anyway, not a director, not now at least, and probably not a SD Storage
Daemon either.

But most definitely a management console and file daemon.

Russel: You'll probably notice that Bacula builds perfectly fine up
until it gets to the director, then you get into OS-specific kernel
knits and hooks where either OpenBSD lacks the framework/API (pthreads,
st(4), etc.) or kernel-specific code needs to be added to Bacula.

In the mean time, we should endeavor to create a "bacula-clientonly"
Port in OpenBSD ports, or "bacula" port with a "clientonly" flavor.

This has been done before, but the work was never commited (CC:)

1. http://www.arsc.edu/resources/silo.html

I will take the lead on this if I have to.

~BAS



I checked the man page for st, where all other Unix systems define the packet.
They include no definition, so you will need to consult the header file
directly sys/mtio.h.   Sorry, but you are pretty much on your own on this.






  == Error in /usr/local/src/bacula-1.38.11/src/stored ==


==>Entering directory /usr/local/src/bacula-1.38.11/src/t

Re: [Bacula-users] Building bacula on OpenBSD

[Brian A. Seklecki]

> > Stop in /usr/local/src/bacula-1.38.11/src/stored.
> 
> It looks to me like the OS' header file is badly broken -- at least in the 
> sense that if it is a Unix system, both mt_fileno and mt_blkno should be 
> defined in the struct mtget.
> 
> Someone should fix the OS, barring that we will need a patch.

Kern, Rus, et al:

We have to be really careful with regard how we word things here.  The
way you assert that could be easily misinterpreted or misconstrued to
have a vendor-bashing tone.

Moreover, conceding the unavailability of compatibility with the OpenBSD
platform doesn't gain us any additional users; a very large group of
talented individuals with tremendous experience writing highly secure,
reliable, and _portable_ code who could contribute greatly to the
project.

-- To set the record straight, and encourage mutual cooperation -- 

The reality here is that OpenBSD is very selective about where it
focuses its development efforts, and the st(4) driver is not one of
those places.

Therefore, the assertion that "The OS is broken" is not correct, it
simply hasn't been implemented or maintained as it should.

Before I go on and make my own silly assertions, I should note: '

   Things are always subject to change, and this is F/OSS and you're
   always welcome to do the work yourself or have corporate sponsorship.

OpenBSD is not the platform for a Bacula director.  You wont see it (at
present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek
Powderhorn Tape Silo connected via Brocade FC switches.(1)

However you will see it at the perimeter and on the wire keeping the
packet kiddies from stealing all of your customers data.  It could be
the ideal system for the job with features like enhanced crypto
acceleration via crypto(9) and the existing improvements on scsi(4) and
recent HBA support.

Anyway, not a director, not now at least, and probably not a SD Storage
Daemon either.

But most definitely a management console and file daemon.

Russel: You'll probably notice that Bacula builds perfectly fine up
until it gets to the director, then you get into OS-specific kernel
knits and hooks where either OpenBSD lacks the framework/API (pthreads,
st(4), etc.) or kernel-specific code needs to be added to Bacula.

In the mean time, we should endeavor to create a "bacula-clientonly"
Port in OpenBSD ports, or "bacula" port with a "clientonly" flavor.

This has been done before, but the work was never commited (CC:)

1. http://www.arsc.edu/resources/silo.html

I will take the lead on this if I have to.

~BAS

> 
> I checked the man page for st, where all other Unix systems define the 
> packet.  
> They include no definition, so you will need to consult the header file 
> directly sys/mtio.h.   Sorry, but you are pretty much on your own on this.
> 
> 
> 
> > 
> > 
> >   == Error in /usr/local/src/bacula-1.38.11/src/stored ==
> > 
> > 
> > ==>Entering directory /usr/local/src/bacula-1.38.11/src/tools
> >  Make of tools is good 
> > 

Re: Sig 11 Segfault in net/net-snmp net-snmp-5.1.3p4 in 4.0/i386

[Brian A. Seklecki]

And with internal debugging:

[...]
snmp_agent: REMOVE session == 0x7d6bbc80
trace: free_agent_snmp_session(): snmp_agent.c, 1257:
snmp_agent: agent_session 0x7d6bbc80 released
trace: handle_snmp_packet(): snmp_agent.c, 1794:
snmp_agent: end of handle_snmp_packet, asp = 0x7d6bbc80
trace: snmp_sess_select_info(): snmp_api.c, 5630:
sess_select: for all sessions: 17 16 13 11 8
trace: _sess_read(): snmp_api.c, 5216:
sess_read: not reading 17 (fdset 0xcf7de6c0 set 0)
trace: _sess_read(): snmp_api.c, 5216:
sess_read: not reading 16 (fdset 0xcf7de6c0 set 0)
trace: netsnmp_callback_recv(): snmpCallbackDomain.c, 188:
transport_callback: hook_recv enter
trace: netsnmp_callback_recv(): snmpCallbackDomain.c, 214:
transport_callback: hook_recv exit
trace: _sess_process_packet(): snmp_api.c, 4898:
sess_process_packet: session 0x8abdafb0 fd 13 pkt 0x88f86000 length 1
trace: callback_debug_pdu(): snmpCallbackDomain.c, 91:
dump_recv_callback_transport: PDU: command = 162, errstat = 0, errindex = 
0

trace: callback_debug_pdu(): snmpCallbackDomain.c, 93:
dump_recv_callback_transport:   var 2:UCD-SNMP-MIB::prErrorFlag.1 = 
INTEGER: 0

trace: _sess_read(): snmp_api.c, 5216:
sess_read: not reading 11 (fdset 0xcf7de6c0 set 0)
trace: _sess_read(): snmp_api.c, 5216:
sess_read: not reading 8 (fdset 0xcf7de6c0 set 0)
trace: mte_get_response(): disman/mteTriggerTable.c, 3107:
mteTriggerTable: got a variables: UCD-SNMP-MIB::prErrorFlag.1 = INTEGER: 0
trace: mte_run_trigger(): disman/mteTriggerTable.c, 3375:
mteTriggerTable: received UCD-SNMP-MIB::prErrorFlag.1 = INTEGER: 0 (type 
2)

trace: mte_run_trigger(): disman/mteTriggerTable.c, 3528:
mteTriggerTable: value: 0 0 0 x: 0 0 0
trace: mte_run_trigger(): disman/mteTriggerTable.c, 3536:
mteTriggerTable: boolean result: x=0 != configured=0 = 0
trace: header_complex_add_data_by_oid(): header_complex.c, 417:
header_complex_add_data: adding something...
Segmentation fault (core dumped)


On Mon, 11 Dec 2006, Brian A. Seklecki wrote:



With debugging symbols:

#0  0x008b8d71 in memmove () from /usr/lib/libc.so.39.3
#1  0x0ecaaf7e in snmp_set_var_objid (vp=0x2c, objid=0x7d8c7018, 
name_length=11) at snmp_client.c:652
#2  0x0ecd1bac in snmp_varlist_add_variable (varlist=0x87618844, 
name=0x7d8c7018, name_length=11, type=5 '\005', value=0x0,

   len=0) at snmp_api.c:6259
#3  0x0ecd1b3c in snmp_pdu_add_variable (pdu=0x87618800, name=0x7d8c7018, 
name_length=11, type=5 '\005', value=0x0, len=0)

   at snmp_api.c:6232
#4  0x0ecaa87b in snmp_add_null_var (pdu=0x87618800, name=0x7d8c7018, 
name_length=11) at snmp_client.c:157
#5  0x01bcdb35 in mte_run_trigger (clientreg=1) at 
disman/mteTriggerTable.c:3309

#6  0x0ecea9c3 in run_alarms () at snmp_alarm.c:248
#7  0x1c003da5 in SnmpdCatchRandomSignal ()
#8  0x1c003204 in SnmpdCatchRandomSignal ()
#9  0x1c001ea0 in ?? ()
#10 0x0005 in ?? ()
#11 0xcf7f7df4 in ?? ()
#12 0xcf7f7e0c in ?? ()
#13 0x1c001e31 in ?? ()
#14 0xcf7f7f6c in ?? ()
#15 0xcf7f7dd0 in ?? ()
#16 0x1c001885 in ?? ()
#17 0x1c001e8e in ?? ()
#18 0x in ?? ()


Running it in -f -D -L now ~BAS

On Mon, 11 Dec 2006, Brian A. Seklecki wrote:



I've got a pretty consistent segfault:

[EMAIL PROTECTED]:/home/seklecki# gdb /usr/local/sbin/snmpd 
/home/seklecki/snmpd.core


Core was generated by `snmpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libnetsnmpagent.so.6.3...(no debugging 
symbols found)...done.

Loaded symbols for /usr/local/lib/libnetsnmpagent.so.6.3
Reading symbols from /usr/local/lib/libnetsnmpmibs.so.6.3...done.
Loaded symbols for /usr/local/lib/libnetsnmpmibs.so.6.3
Reading symbols from /usr/local/lib/libnetsnmphelpers.so.6.3...done.
Loaded symbols for /usr/local/lib/libnetsnmphelpers.so.6.3
Reading symbols from /usr/lib/libwrap.so.4.0...done.
Loaded symbols for /usr/lib/libwrap.so.4.0
Reading symbols from /usr/local/lib/libnetsnmp.so.6.3...done.
Loaded symbols for /usr/local/lib/libnetsnmp.so.6.3
Reading symbols from /usr/lib/libkvm.so.8.0...done.
Loaded symbols for /usr/lib/libkvm.so.8.0
Reading symbols from /usr/lib/libz.so.4.1...done.
Loaded symbols for /usr/lib/libz.so.4.1
Reading symbols from /usr/lib/libcrypto.so.13.0...done.
Loaded symbols for /usr/lib/libcrypto.so.13.0
Reading symbols from /usr/lib/libm.so.2.3...done.
Loaded symbols for /usr/lib/libm.so.2.3
Reading symbols from /usr/lib/libc.so.39.3...done.
Loaded symbols for /usr/lib/libc.so.39.3
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so

#0  0x089b3d71 in memmove () from /usr/lib/libc.so.39.3
(gdb) bt
#0  0x089b3d71 in memmove () from /usr/lib/libc.so.39.3
#1  0x0cf6bede in snmp_set_var_objid () from 
/usr/local/lib/libnetsnmp.so.6.3
#2  0x0cf92b0c in snmp_varlist_add_variable () from 
/usr/local/lib/libnetsnmp.so.6.3
#3  0x0cf92a9c in snmp_pdu_add_variable () from 
/usr/local/lib/libnetsnmp.so.6.3
#4  0x0cf6b7db in snmp_add_null_var () from 
/usr/local/lib/libnetsnmp.so.6.3
#5 

Re: Sig 11 Segfault in net/net-snmp net-snmp-5.1.3p4 in 4.0/i386

[Brian A. Seklecki]

With debugging symbols:

#0  0x008b8d71 in memmove () from /usr/lib/libc.so.39.3
#1  0x0ecaaf7e in snmp_set_var_objid (vp=0x2c, objid=0x7d8c7018, 
name_length=11) at snmp_client.c:652
#2  0x0ecd1bac in snmp_varlist_add_variable (varlist=0x87618844, 
name=0x7d8c7018, name_length=11, type=5 '\005', value=0x0,

len=0) at snmp_api.c:6259
#3  0x0ecd1b3c in snmp_pdu_add_variable (pdu=0x87618800, name=0x7d8c7018, 
name_length=11, type=5 '\005', value=0x0, len=0)

at snmp_api.c:6232
#4  0x0ecaa87b in snmp_add_null_var (pdu=0x87618800, name=0x7d8c7018, 
name_length=11) at snmp_client.c:157
#5  0x01bcdb35 in mte_run_trigger (clientreg=1) at 
disman/mteTriggerTable.c:3309

#6  0x0ecea9c3 in run_alarms () at snmp_alarm.c:248
#7  0x1c003da5 in SnmpdCatchRandomSignal ()
#8  0x1c003204 in SnmpdCatchRandomSignal ()
#9  0x1c001ea0 in ?? ()
#10 0x0005 in ?? ()
#11 0xcf7f7df4 in ?? ()
#12 0xcf7f7e0c in ?? ()
#13 0x1c001e31 in ?? ()
#14 0xcf7f7f6c in ?? ()
#15 0xcf7f7dd0 in ?? ()
#16 0x1c001885 in ?? ()
#17 0x1c001e8e in ?? ()
#18 0x in ?? ()


Running it in -f -D -L now ~BAS

On Mon, 11 Dec 2006, Brian A. Seklecki wrote:



I've got a pretty consistent segfault:

[EMAIL PROTECTED]:/home/seklecki# gdb /usr/local/sbin/snmpd 
/home/seklecki/snmpd.core

Core was generated by `snmpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libnetsnmpagent.so.6.3...(no debugging 
symbols found)...done.

Loaded symbols for /usr/local/lib/libnetsnmpagent.so.6.3
Reading symbols from /usr/local/lib/libnetsnmpmibs.so.6.3...done.
Loaded symbols for /usr/local/lib/libnetsnmpmibs.so.6.3
Reading symbols from /usr/local/lib/libnetsnmphelpers.so.6.3...done.
Loaded symbols for /usr/local/lib/libnetsnmphelpers.so.6.3
Reading symbols from /usr/lib/libwrap.so.4.0...done.
Loaded symbols for /usr/lib/libwrap.so.4.0
Reading symbols from /usr/local/lib/libnetsnmp.so.6.3...done.
Loaded symbols for /usr/local/lib/libnetsnmp.so.6.3
Reading symbols from /usr/lib/libkvm.so.8.0...done.
Loaded symbols for /usr/lib/libkvm.so.8.0
Reading symbols from /usr/lib/libz.so.4.1...done.
Loaded symbols for /usr/lib/libz.so.4.1
Reading symbols from /usr/lib/libcrypto.so.13.0...done.
Loaded symbols for /usr/lib/libcrypto.so.13.0
Reading symbols from /usr/lib/libm.so.2.3...done.
Loaded symbols for /usr/lib/libm.so.2.3
Reading symbols from /usr/lib/libc.so.39.3...done.
Loaded symbols for /usr/lib/libc.so.39.3
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so

#0  0x089b3d71 in memmove () from /usr/lib/libc.so.39.3
(gdb) bt
#0  0x089b3d71 in memmove () from /usr/lib/libc.so.39.3
#1  0x0cf6bede in snmp_set_var_objid () from /usr/local/lib/libnetsnmp.so.6.3
#2  0x0cf92b0c in snmp_varlist_add_variable () from 
/usr/local/lib/libnetsnmp.so.6.3
#3  0x0cf92a9c in snmp_pdu_add_variable () from 
/usr/local/lib/libnetsnmp.so.6.3

#4  0x0cf6b7db in snmp_add_null_var () from /usr/local/lib/libnetsnmp.so.6.3
#5  0x08757bf5 in mte_run_trigger () from 
/usr/local/lib/libnetsnmpmibs.so.6.3

#6  0x0cfab923 in run_alarms () from /usr/local/lib/libnetsnmp.so.6.3
#7  0x1c003da5 in SnmpdCatchRandomSignal ()
#8  0x1c003204 in SnmpdCatchRandomSignal ()
#9  0x1c001ea0 in ?? ()
#10 0x0005 in ?? ()
#11 0xcf7df148 in ?? ()
#12 0xcf7df160 in ?? ()
#13 0x1c001e31 in ?? ()
#14 0xcf7df2bc in ?? ()
#15 0xcf7df124 in ?? ()
#16 0x1c001885 in ?? ()
#17 0x1c001e8e in ?? ()
#18 0x in ?? ()
(gdb)

This system 4.0-stable as of last Wednesday with a slightly modified kernel 
(RAIDFrame enabled):


[EMAIL PROTECTED]:/home/seklecki# uname -a
OpenBSD br0 4.0 GENERIC+RAIDFrame#2 i386 (full dmesg below)

I will try to recompile Net-SNMP from source to see if the mismatch between 
GENERIC and the "recommended" 4.0 binaries is the cause.  I will also try to 
figure out why it's only partially being built with debugging symbols.


~BAS

l8*
-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
   http://www.spiritual-machines.org/

"...from back in the heady days when "helpdesk" meant nothing, "diskquota"
meant everything, and lives could be bought and sold for a couple of pages
of laser printout - and frequently were."

OpenBSD 4.0-stable (GENERIC+RAIDFrame) #2: Wed Dec  6 22:26:09 EST 2006
   [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC+RAIDFrame
cpu0: Intel(R) Xeon(TM) CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,

SSE3,MWAIT,DS-CPL,CNXT-ID,CX16
real mem  = 534921216 (522384K)
avail mem = 479571968 (468332K)
using 4256 buffers containing 26849280 bytes (26220K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 08/18/05, BIOS32 rev. 0 @ 0xffe90, 
SMBIOS rev. 2.3 @ 0xf0450 (92 entries)

bios0: Dell Inc. PowerEdge SC1420
apm0 at bios0: Power Management spec V1.

Sig 11 Segfault in net/net-snmp net-snmp-5.1.3p4 in 4.0/i386

[Brian A. Seklecki]

I've got a pretty consistent segfault:

[EMAIL PROTECTED]:/home/seklecki# gdb /usr/local/sbin/snmpd 
/home/seklecki/snmpd.core


Core was generated by `snmpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libnetsnmpagent.so.6.3...(no debugging 
symbols found)...done.

Loaded symbols for /usr/local/lib/libnetsnmpagent.so.6.3
Reading symbols from /usr/local/lib/libnetsnmpmibs.so.6.3...done.
Loaded symbols for /usr/local/lib/libnetsnmpmibs.so.6.3
Reading symbols from /usr/local/lib/libnetsnmphelpers.so.6.3...done.
Loaded symbols for /usr/local/lib/libnetsnmphelpers.so.6.3
Reading symbols from /usr/lib/libwrap.so.4.0...done.
Loaded symbols for /usr/lib/libwrap.so.4.0
Reading symbols from /usr/local/lib/libnetsnmp.so.6.3...done.
Loaded symbols for /usr/local/lib/libnetsnmp.so.6.3
Reading symbols from /usr/lib/libkvm.so.8.0...done.
Loaded symbols for /usr/lib/libkvm.so.8.0
Reading symbols from /usr/lib/libz.so.4.1...done.
Loaded symbols for /usr/lib/libz.so.4.1
Reading symbols from /usr/lib/libcrypto.so.13.0...done.
Loaded symbols for /usr/lib/libcrypto.so.13.0
Reading symbols from /usr/lib/libm.so.2.3...done.
Loaded symbols for /usr/lib/libm.so.2.3
Reading symbols from /usr/lib/libc.so.39.3...done.
Loaded symbols for /usr/lib/libc.so.39.3
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so

#0  0x089b3d71 in memmove () from /usr/lib/libc.so.39.3
(gdb) bt
#0  0x089b3d71 in memmove () from /usr/lib/libc.so.39.3
#1  0x0cf6bede in snmp_set_var_objid () from 
/usr/local/lib/libnetsnmp.so.6.3
#2  0x0cf92b0c in snmp_varlist_add_variable () from 
/usr/local/lib/libnetsnmp.so.6.3
#3  0x0cf92a9c in snmp_pdu_add_variable () from 
/usr/local/lib/libnetsnmp.so.6.3
#4  0x0cf6b7db in snmp_add_null_var () from 
/usr/local/lib/libnetsnmp.so.6.3
#5  0x08757bf5 in mte_run_trigger () from 
/usr/local/lib/libnetsnmpmibs.so.6.3

#6  0x0cfab923 in run_alarms () from /usr/local/lib/libnetsnmp.so.6.3
#7  0x1c003da5 in SnmpdCatchRandomSignal ()
#8  0x1c003204 in SnmpdCatchRandomSignal ()
#9  0x1c001ea0 in ?? ()
#10 0x0005 in ?? ()
#11 0xcf7df148 in ?? ()
#12 0xcf7df160 in ?? ()
#13 0x1c001e31 in ?? ()
#14 0xcf7df2bc in ?? ()
#15 0xcf7df124 in ?? ()
#16 0x1c001885 in ?? ()
#17 0x1c001e8e in ?? ()
#18 0x in ?? ()
(gdb)

This system 4.0-stable as of last Wednesday with a slightly modified 
kernel (RAIDFrame enabled):


[EMAIL PROTECTED]:/home/seklecki# uname -a
OpenBSD br0 4.0 GENERIC+RAIDFrame#2 i386 (full dmesg below)

I will try to recompile Net-SNMP from source to see if the mismatch 
between GENERIC and the "recommended" 4.0 binaries is the cause.  I will 
also try to figure out why it's only partially being built with debugging 
symbols.


~BAS

l8*
    -lava (Brian A. Seklecki - Pittsburgh, PA, USA)
   http://www.spiritual-machines.org/

"...from back in the heady days when "helpdesk" meant nothing, "diskquota"
meant everything, and lives could be bought and sold for a couple of pages
of laser printout - and frequently were."

OpenBSD 4.0-stable (GENERIC+RAIDFrame) #2: Wed Dec  6 22:26:09 EST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC+RAIDFrame
cpu0: Intel(R) Xeon(TM) CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,

SSE3,MWAIT,DS-CPL,CNXT-ID,CX16
real mem  = 534921216 (522384K)
avail mem = 479571968 (468332K)
using 4256 buffers containing 26849280 bytes (26220K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 08/18/05, BIOS32 rev. 0 @ 
0xffe90, SMBIOS rev. 2.3 @ 0xf0450 (92 entries)

bios0: Dell Inc. PowerEdge SC1420
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfeb00/256 (14 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801EB/ER LPC" rev 
0x00)

pcibios0: PCI bus #6 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x800 0xc8800/0x1800! 
0xca000/0x2000

cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel E7520 MCH" rev 0x09
"Intel E7520 MCH ERR" rev 0x09 at pci0 dev 0 function 1 not configured
ppb0 at pci0 dev 2 function 0 "Intel MCH PCIE" rev 0x09
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel PCIE-PCIE" rev 0x00
pci2 at ppb1 bus 2
vga1 at pci2 dev 12 function 0 "ATI Mach64 GO" rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb2 at pci1 dev 0 function 2 "Intel PCIE-PCIE" rev 0x00
pci3 at ppb2 bus 3
xl0 at pci3 dev 13 function 0 "3Com 3c905C 100Base-TX" rev 0x74: irq 10, 
address 00:50:da:28:37:7f

bmt