os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add the conspectus for w/e 12th June

Browse source
This commit is contained in:
Nik Clayton 2000-07-03 23:49:29 +00:00
parent a7bde8e00c
commit 010ac9105f
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=7495
2 changed files with 613 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

611
en/conspectus/stable/2000/06/12.sgml Normal file
View file

@ -0,0 +1,611 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
<!ENTITY title "FreeBSD-stable Conspectus, week ending 12th June 2000">
<!ENTITY date "$FreeBSD$">
<!ENTITY base "../../../..">
<!ENTITY % includes SYSTEM "../../../../includes.sgml"> %includes;]>
<html>
&header;
<table cellpadding="0" cellspacing="0">
<tbody>
<tr>
<th align="left">Dates</th>
<th align="center"># Posts</th>
<th align="left">Subject</th>
</tr>
<tr>
<td valign="top">June 06 - 07 June</td>
<td valign="top" align="center">2</td>
<td valign="top"><a href="#1">HEADS UP: More important Vinum
information</a></td>
</tr>
<tr>
<td valign="top">June 09 - June 09</td>
<td valign="top" align="center">1</td>
<td valign="top"><a href="#2">HEADS UP: OpenSSH 2.1.0
merge</a></td>
</tr>
<tr>
<td valign="top">June 08 - June 08</td>
<td valign="top" align="center">1</td>
<td valign="top"><a href="#3">"sbsize" path for testing!!</a>
</td>
</tr>
<tr>
<td valign="top">June 08 - June 08</td>
<td valign="top" align="center">1</td>
<td valign="top"><a href="#4">[PATCH] psmintr out of
sync..</a></td>
</tr>
<tr>
<td valign="top">June 08 - June 08</td>
<td valign="top" align="center">1</td>
<td valign="top"><a href="#5">PS/2 mouse driver
updates - can someone commit these?</a></td>
</tr>
<tr>
<td valign="top">June 07 - June 07</td>
<td valign="top" align="center">2</td>
<td valign="top"><a href="#6">4.0-STABLE crashes ...(SMP?)</a>
</td>
</tr>
<tr>
<td valign="top">June 07 - June 10</td>
<td valign="top" align="center">9</td>
<td valign="top"><a href="#7">Inetd problems</a></td>
</tr>
<tr>
<td valign="top">June 08 - June 09</td>
<td valign="top" align="center">9</td>
<td valign="top"><a href="#8">APC Back-UPS Pro</a></td>
</tr>
<tr>
<td valign="top">June 11 - June 12</td>
<td valign="top" align="center">5</td>
<td valign="top"><a href="#9">Re: AHA 1542 CP
Configuration problems</a></td>
</tr>
<tr>
<td valign="top">June 09 - June 09</td>
<td valign="top" align="center">2</td>
<td valign="top"><a href="#10">linprocfs
</a></td>
</tr>
<tr>
<td valign="top">June 06 - June 07</td>
<td valign="top" align="center">3</td>
<td valign="top"><a href="#11">ABIT BE6-II(hpt366) & ata in
-stable</a></td>
</tr>
<tr>
<td valign="top">June 07- June 07</td>
<td valign="top" align="center">5</td>
<td valign="top"><a href="#12">Passive mode for FTP</a></td>
</tr>
</tbody>
</table>
<!-- 1 -->
<hr noshade>
<h3><a name="1"></a>June 06 - June 07 (2 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=331207+0+archive/2000/freebsd-stable/20000611.freebsd-stable">HEADS UP: More important Vinum information</a></h3>
<p>No sooner had <a href="mailto:grog@lemis.com">[Greg Lehey]</a> fixed a
<a
href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=133384+0+archive/2000/freebsd-stable/20000611.freebsd-stable">Vinum bug</a> than he found out another.</p>
<p>The next day, he <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=232300+0+archive/2000/freebsd-stable/20000611.freebsd-stable">added</a>
that his /src/sys/dev/vinum/vinumrevive.c commit (to -CURRENT)
would probably solve the problem -- he was still testing.</p>
<p>On June 7, 2000, Greg <a
href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=232300+0+archive/2000/freebsd-stable/20000611.freebsd-stable">announced</a> that he had just
merged with 4.0-STABLE the fixes for the RAID-5 revive corruption
bug. He strongly recommended 4.0-STABLE and 5-CURRENT users to update as
soon as possible, and, until then, not to attempt anything on RAID-5
plexes that had lost (or would lose) a subdisk. Finally, he promised
that he would very soon commit a large MFC to 3-STABLE so that the
matter might be settled for that branch as well.</p>
<!-- 2 -->
<hr noshade>
<h3><a name="2"></a>June 09 - June 09 (1 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=394565+0+archive/2000/freebsd-stable/20000611.freebsd-stable">HEADS UP: OpenSSH 2.1.0 merge</a></h3>
<p>On June 9, 2000, <a href="mailto:kris@FreeBSD.ORG">[Kris Kennaway]</a>
proclaimed that he had merged with -stable the OpenSSH 2.1.0 code
from -current.</p>
<p>He also provided the following information:</p>
<blockquote>
<p><i>The major new feature of OpenSSH 2.x is support for the
SSH2 protocol and DSA keys, freeing it from the dependency
on RSAREF for USA people. It interoperates well with the
ssh2 port and other SSH2 clients/servers - see
<a href="http://www.openssh.com">http://www.openssh.com</a>
for more interop details. Another new feature is support for
OPIE passwords in SSH1 mode.</i></p>
<p><i>Missing from OpenSSH 2.1.0 is support for OPIE and Kerberos in
SSH2 mode, which will be hopefully added later.</i></p>
<p><i>For more information on how to use OpenSSH 2.1, see the
manpages, the file /usr/src/crypto/openssh/README.openssh2
and <a href="http://www.openssh.com">www.openssh.com</a>.
Server DSA key generation is automatic the next time you
boot with sshd_enable=YES in rc.conf, or you can do it by
hand (see the above README).</i></p>
</blockquote>
<p>Owing to some syntax errors, the OpenSSH MFC caused a temporary
breach of -STABLE; the difficulty, however, was soon overcome.</p>
<!-- 3 -->
<hr noshade>
<h3><a name="3"></a>June 08 - June 08 (1 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=374736+0+archive/2000/freebsd-stable/20000611.freebsd-stable">"sbsize" path for testing!!</a></h3>
<p>On June 8, 2000, <a href="mailto:green@FreeBSD.ORG">[Brian Fundakowski
Feldman]</a> made the following announcement:</p>
<blockquote>
<p><i>Per request of users and the security officer, I've
backported the changes from 4.0/5.0 which allow
administrative control over the socket resources a user can
allocate. I need testers to get this done before
3.5-RELEASE, as my crash-box is -CURRENT. I think I have
caught all of the problematic parts of the code and merged
things correctly, so I do not _expect_ anything to go wrong.</i></p>
<p><i>The big problem is that people are using the DoS (indeed,
it has just been reposted on BugTraq for some unknown
reason), and something must be done to prevent a user from
crashing the system like that. Changing the limit is as
easy as modifying /etc/login.conf, and a default value
should be in place. I don't know what the default value
should be, so I invite estimates on how much socket buffer
space a user really needs.</i></p>
<p><i>The patch, which will necessitate both a make world and
new kernel/modules build, is located at:
<a
href="http://people.FreeBSD.org/~green/sbsize_etc.RELENG_3.patch">http://people.FreeBSD.org/~green/sbsize_etc.RELENG_3.patch</a>.</i></p>
<p><i>In addition to the sbsize change, there's a relatively
minor change to struct socket which does break binary
compatibility of kernel modules if they use that member
(so_cred). Anything groveling in the kernel memory, like
pidentd, would need to be recompiled/modified, but pidentd
itself (now uses the proper interface to get the data it
needs.</i></p>
<p><i>So, anyone who can, test it out and report back.
I need to get this done within the week or so :)</i></p>
</blockquote>
<!-- 4 -->
<hr noshade>
<h3><a name="4"></a>June 08 - June 08 (1 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=380320+0+archive/2000/freebsd-stable/20000611.freebsd-stable">[PATCH] psmintr out of sync..</a></h3>
<p>On June 8, 2000, <a
href="mailto:yokota@zodiac.mech.utsunomiya-u.ac.jp">[Kazutaka
Yokota]</a> posted a patch for the psm driver. The "diff" in question,
as Kazutaka pointed out, was not intended for the "psmintr out of sync"
issue; furthermore, it needed testing; finally, it had been designed
with more general goals in mind.</p>
<p>Incidentally,
<a href="mailto:pir@pir.net">[Peter Radcliffe]</a>,
<a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=238074+0+archive/2000/freebsd-stable/20000611.freebsd-stable">in a letter of his</a>,
described another approach to the psmintr out of sync problem:
<blockquote>
<p><i>My workaround for this, for the moment, is to use the
serial adaptor that came with the mouse and use it on the
first serial port. Works fine, but somewhat annoying to lose
a serial port ...</i></p>
</blockquote>
<!-- 5 -->
<hr noshade>
<h3><a name="5"></a>June 08 - June 08 (1 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=337360+0+archive/2000/freebsd-stable/20000611.freebsd-stable">PS/2 mouse driver updates - can someone commit these?</a></h3>
<p><a href="mailto:gram@cequrux.com">[Graham Wheeler]</a>
modified the psm driver to supply support for the Synaptics
touch pads, and posted his patches on June 8, 2000.</p>
<p>He noticed that, in some respects, his code seemed to behave
even better than Synaptics' driver.</p>
<!-- 6 -->
<hr noshade>
<h3><a name="6"></a>June 07 - June 07 (2 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=254404+0+archive/2000/freebsd-stable/20000611.freebsd-stable">4.0-STABLE crashes ...(SMP?)</a></h3>
<p>On June 7, 2000, <a href="mailto:jesper@skriver.dk">[Jesper
Skriver]</a> wrote that his -STABLE SMP system -- sources as of June 2
-- had been crashing regularly. He said that he had kernel crash dumps,
too.</p>
<p>I have been reading about SMP crashes in the -stable forum for
several weeks ; at the moment, I do not know about results or
solutions, though.
<!-- 7 -->
<hr noshade>
<h3><a name="7"></a>June 07 - June 10 (9 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=296643+0+archive/2000/freebsd-stable/20000611.freebsd-stable">Inetd problems</a></h3>
<p><a href="mailto:vladimir-bsd-stable@math.uic.edu">[Vladimir Egorin]</a>
had been recording a number of inetd coredumps for the previous
few weeks, and requested the -stable forum to help.</p>
<p>It turned out that the coredumps were due to underscore
characters in remote hostnames. Vladimir submitted a bug report
as well as patches. </p>
<p>Next, he asked: </p>
<blockquote>
<p><i>BTW, should the '_' character be considered a valid
character for a hostname? I think rfc1034 only gives
recommendations, but doesn't insist on them. It would make
sense for gethostbyname() to return results for such hosts.
In our case, we inetd was receiving connections to the smtp
port, and and we were losing mail from this particular host
(mail_dxb.zu.ac.ae).</i></p>
</blockquote>
<p><a href="mailto:chad@DCFinc.com">[Chad Larson]</a> replied:</p>
<blockquote>
<p><i>I can't quote you references right now, but we came to the
conclusion that the '_' character was invalid in host
names. We had similar problems delivering reports to
customer's networked printers that contained underscores in
their names. We eventually got the customer to change the
'_' to '-'.</i></p>
</blockquote>
<p><a href="mailto:pir@pir.net">[Peter Radcliffe]</a> stated:</p>
<blockquote>
<p><i>"_" is not a valid character in a name in the IN zone of
DNS but is not invalid in DNS, strictly.</i></p>
<p><i>Valid characters in the IN zone are [0-9a-zA-Z-].</i></p>
<p><i>bind used to allow _ in names by default, so pople used
them. More recent versions of bind disallow this in primary
zones by default (but you can turn it off in case you arn't
serving IN zones) but to only warn about it in secondary
zones.</i></p>
<p><i>It's going to take a long time to get rid of all the
entries containing "_" out there, so expect to have to
deal with it :/</i></p>
</blockquote>
<p><a href="mailto:@">[Cy Schubert]</a> remarked:</p>
<blockquote>
<p><i>The standard was changed about 5 years ago.</i></p>
</blockquote>
<!-- 8 -->
<hr noshade>
<h3><a name="8"></a>June 08 - June 09 (9 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=347767+0+archive/2000/freebsd-stable/20000611.freebsd-stable">APC Back-UPS Pro</a></h3>
<p>While running an APC Back-UPS Pro with upsd in the default
configuration,
<a href="mailto:psyrawt@nottingham.ac.uk">[Andrew Tulloch]</a>
saw messages such as:</p>
<pre> upsd[355]: apc_tune: negative repsonse: N
upsd[355]: apc_tune: negative repsonse: ^M
upsd[355]: apc_tune: negative repsonse: ^M
upsd[355]: apc_tune: negative repsonse: N
upsd[355]: apc_tune: negative repsonse: NO
upsd[355]: apc_tune: negative repsonse: NO</pre>
<p><a href="mailto:dwhite@resnet.uoregon.edu">[Doug White]</a>
answered:</p>
<blockquote>
<p><i>That looks like either the UPS or upsd getting confused
as to where to expect responses. Check your config and make
sure you aren't adding extra spaces.</i></p>
<p><i>I woudn't discount that the APC is doing wierd serial
things -- it always seemed flakey to me when I was working
on upsd.</i></p>
<p><i>upsd hasn't been touched in years so it's possible it
still has bugs :)</i></p>
</blockquote>
<p>On a related note, <a href="mailto:dl@tyfon.net">[Dan Larsson]</a>
wrote:</p>
<blockquote>
<p><i>I had similar troubles on a Smart-UPS using the port
/usr/ports/sysutils/nut The problem however seemed to reside
in the source used when building the port</i></p>
<p><i>After doing a 'manual' build of the very latest source the
problem was fixed.</i></p>
</blockquote>
<p><a href="mailto:nate@yogotech.com">[Nate Williams]</a>,
replying to Andres's letter, commented:</p>
<blockquote>
<p><i>You can safely ignore this. I've got a system that sees
these and has been running for almost 3 years w/out any
problems, and actually has had do the 'UPS' shutdown thing
once or twice, plus it's lived through thousands of
brownouts and power failures.</i></p>
</blockquote>
<p>The following day, the discussion focused on the security
aspect in an environment composed of multiple machines running
off one ups.</p>
<p>Doug White put forward this remark:</p>
<blockquote>
<p><i>The problem with this is doing it securely. You can have
one monitor machine but having some automated way of telling
the others to shutdown that can't be tricked is a tough
problem. ssh with a null-passphrase RSA key is about as
close as you can get, but that doesn't keep root on one
machine from telling the others to shutdown, but that may
not be a problem in your environment :)</i></p>
</blockquote>
<p><a href="mailto:swb@grasslake.net">[Shawn Barnhart]</a>
rejoined:</p>
<blockquote>
<p><i>It seems like it would be safer for a client machine to
poll the UPS-monitoring server for power status vs. having
the monitoring server alert its clients to do something
like shut down.</i></p>
<p><i>On the more sophisticated end you could do it as an SNMP
trap, or you could just write the UPS status to a file on
the monitoring box and the clients could fetch the status
periodically and make their own decisions about what to do
when the power went off.</i></p>
</blockquote>
<p><a href="mailto:winter@jurai.net">[Matthew Dodd]</a>
concluded the conversation by observing:</p>
<blockquote>
<p><i>Isn't this what 'NUT' is for?</i></p>
<p><i><a href="http://www.exploits.org/nut/">http://www.exploits.org/nut/</a></i></p>
<p><i>/usr/ports/sysutils/nut</i></p>
</blockquote>
<p>The next day, <a href="mailto:djfast@telus.net">[Donald Fast]</a>,
reminded Shawn that one could also use the multi-computer option,
which can be found at
<a href="http://http://www.apcc.com/products/management/shareups_smartslot_spec.cfm">this address</a>,
and then each machine could decide on its own.</p>
<!-- 9 -->
<hr noshade>
<h3><a name="9"></a>June 11 - June 12 (5 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+archive/2000/freebsd-stable/20000618.freebsd-stable">Re: AHA 1542 CP Configuration problems</a></h3>
<p><a href="mailto:jmanely@metronet.com">[Jim Manley]</a>
had trouble with the configuration of his AHA1542CP SCSI
adapter.</p>
<p><a href="mailto:brian@Awfulhak.org">[Brian Somers]</a>
sent him a patch, and told him that disabling the PnP probe
should make the patch (and the adapter) work.
<a href="mailto:imp@FreeBSD.ORG">[Warner Losh]</a> was also
informed (cc'ed) of that.</p>
<p>Brian hypothesized that the difficulties, which seemed to arise
under special circumstances, were due to some other PnP entry
inducing a probe that the AHA found intrusive. He promised that
he would investigate as soon as he found time.</p>
<!-- 10 -->
<hr noshade>
<h3><a name="10"></a>June 09 - June 09 (2 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=399560+0+archive/2000/freebsd-stable/20000611.freebsd-stable">linprocfs</a></h3>
<p><a href="mailto:sketchy@netcraft.com">[Jonathan Perkin]</a>
was able to build the latest linprocfs commits, but he found an
error related to textvp_fullpath (not defined).</p>
<p><a href="mailto:@">[David Malone]</a> replied that someone had
already sent a PR, that the question had been assigned to DES,
and that the function textvp_fullpath simply needed to be
MFCed.</p>
<!-- 11 -->
<hr noshade>
<h3><a name="11"></a>June 06 - June 07 (3 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=177916+0+archive/2000/freebsd-stable/20000611.freebsd-stable">ABIT BE6-II(hpt366) & ata in -stable</a></h3>
<p><a href="mailto:lavr@unix1.jinr.dubna.su">[Andrey Lavrentyev]</a>
experienced a dreadful plight in trying to make his board
function.</p>
<p>Subsequently, he got rid of his woes:
<blockquote>
<p><i> I resolved my problem (see subj), was test some ata/66
disks & controllers...</i></p>
<p><i>Summary: this problems in hardware combinations various
udma controllers and disks vendors, but this wasn't shock
for me, i was very surprise after disk tests: disks run in
pio-mode faster than in dma. :)</i></p>
<p><i>PS. sysctl -w hw.atamodes=pio,...,pio, resolved udma
problems.</i></p>
</blockquote>
<!-- 12 -->
<hr noshade>
<h3><a name="12"></a>June 07 - June 07 (5 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=294819+0+archive/2000/freebsd-stable/20000611.freebsd-stable">Passive mode for FTP</a></h3>
<p>On June 7, 2000,
<a href="mailto:stephen@math.missouri.edu">[Stephen Montgomery-Smith]</a>
was wondering how to properly configure ftp (passive mode) so
that it might correctly operate behind a firewall. At first, he
thought that passive mode was broken, but, in an ensuing letter,
he made it clear that it was not the case:</p>
<blockquote>
<p><i>Suppose I do:</i></p>
<pre> ftp ftp.freebsd.org</pre>
<p><i>and log on as anonymous. When I type</i></p>
<pre> ls</pre>
<p><i>I get the messages</i></p>
<pre> 500 'EPSV': command not understood.
500 'LPSV': command not understood.
Passive mode refused.</pre>
<p><i>This worked in earler versions of FreeBSD 4.0, even when
I had a firewall.</i></p>
</blockquote>
<p><a href="mailto:jim@thehousleys.net">[James Housley]</a>
suggested:</p>
<blockquote>
<p><i>This is from /etc/login.conf:</i></p>
<pre>default:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=NO:\</pre>
<p><i>I changed FTP_PASSIVE_MODE=YES to NO and all was right in
the world </i></p>
<p><i>Don't forget cap_mkdb.</i></p>
</blockquote>
<p><a href="mailto:spork@super-g.com">[Charles Sprickman]</a>
went on to say:</p>
<blockquote>
<p><i> If you pull the IPV6 stuff out of your kernel, ftp seems
to work fine, I assume it must "ifdef" the problematic parts
of the ftp program out. I have a number of machines running
-stable and have no problems, but I also always comment out
the v6 stuff.</i></p>
<p><i> cap_mkdb is to be run like so whenever you've changed
login.conf:</i></p>
<pre> "cap_mkdb /etc/login.conf".</pre>
<p><i>You will have to log out (all the way to the login prompt
if you're at the console) and log back in for changes to
take effect. A reboot should not be necessary.</i></p>
</blockquote>
<hr noshade>
<ul>
<li>
<p>The present Conspectus expresses my strictly personal
understanding of what occurred on the FreeBSD-stable mailing
list during the specified week.</p>
<li>
<p>I may have made errors and/or mistakes as well as typos.
If you feel that this is indeed the case, and/or that I have
omitted some significant thread or part of a thread, feel free
to contact me via email. Constructive criticism is more than
welcome.</p>
</ul>
<p align="right"><a href="mailto:bartequi@neomedia.it">Salvo
Bartolotta</a></p>
&footer;
</body>
</html>
<!--
Local Variables:
mode: sgml
sgml-indent-data: t
sgml-omittag: nil
sgml-always-quote-attributes: t
End:
-->

3
en/conspectus/stable/2000/06/Makefile
View file

@ -1,9 +1,10 @@
# $FreeBSD: www/en/conspectus/stable/2000/05/Makefile,v 1.1 2000/05/31 20:35:47 nik Exp $
# $FreeBSD: www/en/conspectus/stable/2000/06/Makefile,v 1.1 2000/06/17 13:13:11 nik Exp $
.if exists(../Makefile.conf)
.include "../Makefile.conf"
.endif
DOCS= 05.sgml
DOCS+= 12.sgml
.include "../../../../web.mk"