> *** openbsd-compat/bsd-nextstep.h.orig Sun Feb 4 00:16:16 2001 > --- openbsd-compat/bsd-nextstep.h Sun Feb 4 00:19:09 2001 > *************** > *** 48,52 **** > --- 48,56 ---- > speed_t cfgetispeed(const struct termios *t); > int cfsetospeed(struct termios *t, int speed); > int cfsetispeed(struct termios *t, int speed); > + > + /* LIMITS */ > + #define NGROUPS_MAX 16 > +Hey, Steve.. since you put together the group access patch to OpenBSD. Do you recomend a better place or a better value for NGROUPS_MAX? It's not defined within the NeXTStep headers. Otherwise I'd perfer to put it in defines.h as a fall back incase NGROUPS_MAX is not found. - Ben
On Sun, 4 Feb 2001 mouring at etoh.eviladmin.org wrote: : Hey, Steve.. since you put together the group access patch to OpenBSD. Do : you recomend a better place or a better value for NGROUPS_MAX? It's not : defined within the NeXTStep headers. Otherwise I'd perfer to put it in : defines.h as a fall back incase NGROUPS_MAX is not found. i think defines.h is a good place, but it should probably be 0 if not defined, which indicates that supplementary groups are not supported: #ifndef NGROUPS_MAX #define NGROUPS_MAX 0 #endif the groupaccess code does handle this case, and you get the old behaviour of using just the primary group.
-----BEGIN PGP SIGNED MESSAGE----- At 4:42 AM -0600 2/4/01, mouring at etoh.eviladmin.org wrote:>> *** openbsd-compat/bsd-nextstep.h.orig Sun Feb 4 00:16:16 2001 >> --- openbsd-compat/bsd-nextstep.h Sun Feb 4 00:19:09 2001 >> *************** >> *** 48,52 **** >> --- 48,56 ---- >> speed_t cfgetispeed(const struct termios *t); >> int cfsetospeed(struct termios *t, int speed); >> int cfsetispeed(struct termios *t, int speed); >> + >> + /* LIMITS */ >> + #define NGROUPS_MAX 16 >> + > >Hey, Steve.. since you put together the group access patch to OpenBSD. Do >you recomend a better place or a better value for NGROUPS_MAX? It's not >defined within the NeXTStep headers. Otherwise I'd perfer to put it in >defines.h as a fall back incase NGROUPS_MAX is not found. > >- BenTo be more precise, NGROUPS_MAX *is* defined (as above) in the NeXTStep headers if _POSIX_SOURCE is defined, but undefined otherwise.>The daemon still runs, but does no logging except for the mysterious > > Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol > error: type 50 plen 516 > Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol > error: type 50 plen 550 >errors, which get logged to /usr/adm/messages, but not LOCAL0, where >they are supposed to go.Please submit this logging issue to the openssh mailinglist. Last time I looked at NeXT's syslogd it was massively brain damaged and I could not get any code to correctly log events to it. However others may have a better idea on what to look at or try. OK. here goes . . . Somewhere between the 20010119 and the 20010126 snapshots, the NeXTStep build developed an issue. I have sshd configured to log to LOCAL0. With the 20010119 snapshot and earlier, it works fine. With later builds, the daemon seems to function OK, but *nothing* gets logged to LOCAL0. Instead, I get the following error messages logged to /usr/adm/mesages every time a client connects to the daemon: Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol error: type 50 plen 516 Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol error: type 50 plen 550 I have not had any of Ben's troubles with NeXT's syslogd. In fact, up to and including the 20010119 build, logging has worked fine. I realize there's a week's worth of changes between 20010119 and 20010126. If there is strong motivation, I could try to narrow down exactly when things broke. But some ideas as to what might be going on would be helpful. Jacques -----BEGIN PGP SIGNATURE----- Version: PGP Comment: Public Key - http://golem.ph.utexas.edu/~distler/distler.asc iQCVAwUBOn3YOaIBi34rsX+ZAQF2IwQAz8HZlRhZ7b83I6vJ8It2gox2q4AyC+TM SLGYCZQoztbqbOh+CVQTlwx31VCu7KERn2ooU7eqWQ+Zxex1G47kOdsazuXzCHQk 9F2YRoAZYwnIAmRqM3xbKOwE0EBTE28ap8FATxXeEJLP5yaSKHzIrZQa8l9q+rl7 MsUsAWjYyao=9+nd -----END PGP SIGNATURE-----
On Sun, Feb 04, 2001 at 04:31:02PM -0600, Jacques Distler wrote:> I have sshd configured to log to LOCAL0. With the 20010119 snapshot > and earlier, it works fine. With later builds, the daemon seems to > function OK, but *nothing* gets logged to LOCAL0. Instead, I get the > following error messages logged to /usr/adm/mesages every time a > client connects to the daemon: > > Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol > error: type 50 plen 516 > Feb 4 00:23:45 golem sshd[17861]: error: Hm, dispatch protocol > error: type 50 plen 550what client versions? do you have ssh -v and/or sshd -d output? -m
-----BEGIN PGP SIGNED MESSAGE----- Markus Friedl wrote:>On Sun, Feb 04, 2001 at 04:31:02PM -0600, Jacques Distler wrote: >> I have sshd configured to log to LOCAL0. With the 20010119 snapshot >> and earlier, it works fine. With later builds, the daemon seems to >> function OK, but *nothing* gets logged to LOCAL0.Ooops! That would appear to be my screwup -- a problem with an include file. I recompiled log-server.c and logging seems to be working fine now. Now that the "dispatch protocol error" business seems to be resolved, the NeXT build is working fine. Jacques - -- PGP public key: http://golem.ph.utexas.edu/~distler/distler.asc -----BEGIN PGP SIGNATURE----- Version: PGP Charset: noconv iQCVAwUBOoLsbaIBi34rsX+ZAQEJ8QQAyBqMa+sI4dWd1i15kKm5R6cJLQDtK+7H 4JsRcwXAAvwrKxTlqD9ShWSJIcBCkexM5lJsdeWY8gLY8Q8SoSyKo6Ac9AK+45Zf JvOsFMhj5SE2GDONa2rraaWMBaw9V/DfAs0CaiLHq0evtAdyIZjI2uIP/vOxXfqy LoPXrKP/MuI=WKR+ -----END PGP SIGNATURE-----