Re: multiple ipsec-nat-t clients behind same ip address (pr 5562)
On Mon, 2010-12-06 at 12:58 +, Mikolaj Kucharski wrote: Hi, I had a chance to test pr 5562 and would like to confirm that on OpenBSD current the issue is still present. OpenBSD 4.8-current (GENERIC) #510: Sat Dec 4 12:03:30 MST 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC After applying attached patch (taken from url in pr 5562) issue is resolved. See reference urls for more detailed explanation. Would be possible to get this patch commited? References 1. http://marc.info/?t=12016804851r=1w=2 2. http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yesnumbers=5562 3. http://www.bzero.se/patches/isakmpd-multi-nat-peers-patch.diff Committed. Thanks for verifying. -martin
Re: document ldapd schema files
4 nov 2010 kl. 20.10 skrev Adam M. Dutko: I can't really comment on the accuracy because I'm trying to avoid learning about LDAP at all cost, but this gives me enough info to start searching with, so I think it's a great addition. What is the technical reason behind not wanting to learn about LDAP? I'd be interested to hear feedback/input from you and the rest of the list. I can't speak for Ted, but I would guess having other priorities or lack of time. Anyway, I should perhaps mention the 'relax schema' keyword in the ldapd.conf file, if you don't want to write a schema definition. Basically it bypasses all attribute checking of stored entries, so you can use it as a simple key-value store. Any attribute will be accepted. Don't use if you want any kind of interoperability. -martin
document ldapd schema files
On Wed, Nov 03, 2010 at 01:19:26PM -0400, Ted Unangst wrote: Am I missing something, or is there no documentation for the schema files? man ldapd.conf tells me I can include additional schema files via the schema keyword, but nothing tells me what to put in those files. Following diff attempts to documents the schema file syntax. Only a brief synopsis of the attribute type and object class syntax is given, the rest is referred to the RFC. I couldn't get the long synopsis lines to display as I wanted, so I'm hoping for some mdoc help :) -martin Index: ldapd.conf.5 === RCS file: /cvs/src/usr.sbin/ldapd/ldapd.conf.5,v retrieving revision 1.11 diff -u -p -u -r1.11 ldapd.conf.5 --- ldapd.conf.53 Nov 2010 11:21:11 - 1.11 +++ ldapd.conf.53 Nov 2010 19:47:39 - @@ -132,6 +132,9 @@ Password for the root user. Specified either in plain text, or in hashed format. .It schema Ar filename Add schema definitions from the specified file. +For a description of the schema file syntax see +.Sx SCHEMA +below. .El .Sh NAMESPACES A namespace is a subtree of the global X.500 DIT (Directory Information Tree), @@ -250,16 +253,79 @@ Typically used to allow users to modify Enable compression of entries and optionally specify compression level (0 - 9). By default, no compression is used. .El +.Sh SCHEMA +Schema files define the structure and format of entries in the directory tree. +There are three types of definitions in a schema file: +.Bl -tag -width Ds +.It attributetype +\*(lp +.Ar oid +.Op NAME name +.Op DESC description +.Op OBSOLETE +.Op SUP oid +.Op EQUALITY oid +.Op ORDERING oid +.Op SUBSTR oid +.Op SYNTAX oid +.Op SINGLE-VALUE +.Op COLLECTIVE +.Op NO-USER-MODIFICATION +.Op USAGE Brq userApplications | directoryOperation | distributedOperation | dSAOperation +\*(rp +.Pp +An attribute type definition specifies the syntax of attribute values, whether +it allows multiple values and how it can be compared in search requests. +For a complete description of attribute type defitions, see section +4.1.2 in RFC 4712. +.It objectclass +\*(lp +.Ar oid +.Op NAME name +.Op DESC description +.Op OBSOLETE +.Op SUP oids +.Op Brq ABSTRACT | STRUCTURAL | AUXILIARY +.Op MUST oids +.Op MAY oids +\*(rp +.Pp +An object class definition specifies which attributes are required +and which are allowed. +For a complete description of object class definitions, see section +4.1.1 in RFC 4712. +.It objectidentifier Ar symbolic-name Ar OID +Defines a symbolic name for the object identifier. +A symbolic name can be used in place of a numeric OID in definitions +of attribute types, object classes and other symbolic OIDs. +A descendant OID can be defined in terms of another symbolic OID by appending +a numeric OID after a colon, for example: +.Bd -literal -offset indent +objectidentifier MyOidRoot 1.2.3.4 +objectidentifier MyOidAttributes MyOidRoot:5.6 +objectidentifier MyOidObjects MyOidRoot:7 +.Ed +.Pp +This would define MyOidAttributes as a symbolic name for the OID +1.2.3.4.5.6, and MyOidObjects for 1.2.3.4.7. +.El .Sh FILES .Bl -tag -width /etc/ldap/ldapd.confXXX -compact .It Pa /etc/ldapd.conf Default .Xr ldapd 8 configuration file. +.It Pa /etc/ldap/*.schema +Default schema definition files. .El .Sh SEE ALSO .Xr ldapctl 8 , .Xr ldapd 8 +.Rs +.%R RFC 4512 +.%T Lightweight Directory Access Protocol (LDAP): Directory Information Models +.%D June 2006 +.Re .Sh HISTORY The .Nm
Re: snmpd sensorMIBObjects vs. sensorsMIBObject
20 sep 2010 kl. 16.45 skrev Stuart Henderson:
I was looking at getting the net-snmp port to pick up our mibs
by default and noticed there's a mismatch between mib.c and
/usr/share/snmp/mibs in the naming of the sensors mib.
OPENBSD-SNMPD-CONF.txt:sensorsMIBObjects
OPENBSD-BASE-MIB.txt:sensorsMIBObjects OBJECT IDENTIFIER ::= { openBSD 2
}
..etc..
mib.c: { MIB(sensorMIBObjects),OID_MIB },
Does this diff make sense?
sure, why not, if it annoys you ;-)
ok martinh
Having net-snmp pick up the mibs by default would be nice.
Index: mib.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.40
diff -u -p -r1.40 mib.c
--- mib.c 11 Jun 2010 10:45:36 - 1.40
+++ mib.c 20 Sep 2010 14:44:31 -
@@ -1221,7 +1221,7 @@ char*mib_sensorvalue(struct sensor *);
intmib_memiftable(struct oid *, struct ber_oid *, struct ber_element **);
static struct oid openbsd_mib[] = {
- { MIB(sensorMIBObjects),OID_MIB },
+ { MIB(sensorsMIBObjects), OID_MIB },
{ MIB(sensorNumber),OID_RD, mib_sensornum },
{ MIB(sensorIndex), OID_TRD, mib_sensors },
{ MIB(sensorDescr), OID_TRD, mib_sensors },
Index: mib.h
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.h,v
retrieving revision 1.20
diff -u -p -r1.20 mib.h
--- mib.h 11 Jun 2010 10:45:36 - 1.20
+++ mib.h 20 Sep 2010 14:44:31 -
@@ -398,8 +398,8 @@
/* OPENBSD-MIB */
#define MIB_pfMIBObjects MIB_openBSD, 1
-#define MIB_sensorMIBObjects MIB_openBSD, 2
-#define MIB_sensors MIB_sensorMIBObjects, 1
+#define MIB_sensorsMIBObjectsMIB_openBSD, 2
+#define MIB_sensors MIB_sensorsMIBObjects, 1
#define MIB_sensorNumber MIB_sensors, 1
#define MIB_sensorTable MIB_sensors, 2
#define MIB_sensorEntry MIB_sensorTable, 1
@@ -683,7 +683,7 @@
{ MIBDECL(vantronix) }, \
{ MIBDECL(openBSD) }, \
\
- { MIBDECL(sensorMIBObjects) }, \
+ { MIBDECL(sensorsMIBObjects) }, \
{ MIBDECL(sensors) }, \
{ MIBDECL(sensorNumber) }, \
{ MIBDECL(sensorTable) }, \
Re: fts(3) typo
26 nov 2009 kl. 07.26 skrev Nick Guenther: fts(3) says in the intro: It is possible to walk the hierarchy ``logically'' (ignoring symbolic links) or physically (visiting symbolic links), order the walk of the hi- erarchy, or prune and/or re-visit portions of the hierarchy. Which struck me as backwards. And indeed later: FTS_LOGICAL This option causes the fts routines to return FTSENT struc- tures for the targets of symbolic links instead of the sym- bolic links themselves. FTS_PHYSICAL This option causes the fts routines to return FTSENT struc- tures for symbolic links themselves instead of the target files they point to. Am I reading this wrong or is there a long-lost typo here? I think you're reading it wrong. If I we're to ignore that an entry was a symbolic link, I would (logically) expect to get the target back, not the link itself. -martin
