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/arc
4 nov 2010 kl. 21.22 skrev Ted Unangst:
On Thu, Nov 4, 2010 at 3:53 PM, Ted Unangst wrote:
>> On Thu, Nov 4, 2010 at 3:10 PM, Adam M. Dutko
wrote:
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
st
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
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 att
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.
On Tue, Jun 01, 2010 at 04:12:19AM +0200, Dawe wrote:
> ber_calc_len() is not an internal function in snmpd(8) and ypldap(8).
> It's used this way in ldapd(8), but it's likely better to keep the binding
> consistent.
fixed, thanks
-martin
> Index: ldapd/ber.c
>
This fixes the documentation to conform to the code.
-martin
Index: usr.sbin/snmpd/ber.3
===
RCS file: /cvs/src/usr.sbin/snmpd/ber.3,v
retrieving revision 1.6
diff -u -N -p usr.sbin/snmpd/ber.3
--- usr.sbin/snmpd/ber.3
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.
>
Hello,
I've been writing a small ldap server recently and thought I'd see if
there was any interest in such a thing here. It's ISC-licensed with a
small and readable code base. Still in a very early stage, but at
least usable as a simple address book, although I wouldn't trust it
with rea
