I broke my SSH to jails after 7.2-8.0 src upgrade

[Garrett Cooper]

On Thu, Mar 11, 2010 at 8:41 PM, Xin LI <delphij at delphij.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2010/03/11 20:33, Garrett Cooper wrote:
>> I've done a few RELENG_8_0 to STABLE-8 to 9-CURRENT upgrades lately
>> and mergemaster was goofing up the contents a bit based on the RCS
>> versions. I had to hand-edit a crapload of stuff going from 8 to 9,
>> and I still don't trust mergemaster's automatic merging logic because
>> it goofs up on /etc/group // /etc/passwd still (doesn't merge
>> anything, discards my info, etc) for starters.
>>
>> -a doesn't actually do any merging though, FWIW:
>>
>>      -a          Run automatically.  This option will leave all the files that
>>                  differ from the installed versions in the temporary directory
>>                  to be dealt with by hand.  If the temproot directory exists,
>>                  it creates a new one in a previously non-existent directory.
>>                  This option unsets the verbose flag, but other than -U it is
>>                  compatible with all other options.  Setting -a makes -w
>>                  superfluous.
>>
>> Also, "add path pts unhide" unmasks all psuedo TTY dev nodes so that
>> applications that use openpty(3) and friends (like sshd) can allocate
>> them at login.
>
> Yes that's right.  Thanks for posting, perhaps we can document it in FAQ?

Unfortunately this doesn't really fit in a FAQ because it could be any
of the failures caused by openpty failure:

ERRORS
     The openpty() function may fail and set the global variable errno for any
     of the errors specified for the grantpt(3), posix_openpt(3), ptsname(3),
     and unlockpt(3) functions and the revoke(2) system call.

     In addition to this, forkpty() may set it to any value as described for
     fork(2).

Note how openpty(3) isn't descriptive in terms of _what_ individual
failures can be reported by it, but instead point to other manpages
:)... I've run into whacky ass issues with /var/run permissions in the
past, etc, which is why I don't suggest putting this into a FAQ -- the
bucket is way too huge to deal with.

Steve's right though -- if you're willing to use an option and the
documentation clearly states the exact behavior and caveats, you are
responsible for the results of any failure through misuse of the tool
(exceptions being IMO NUL pointer exceptions, abort(3) calls not
thrown by assert(3)s, etc). You're more than welcome to make
suggestions on how things can be improved, but as I've discovered in
some areas, some of the suggestions one makes aren't necessarily
accepted with open minds.

Excessive and/or redundant documentation (as I'm starting to
understand after playing the opposite side for a while) is no better
than little or no documentation; complete and concise documentation is
what's needed more than anything else.

Thanks,
-Garrett