Date: Tue, 4 Jul 2000 00:33:29 +0100 From: Nik Clayton <nik@freebsd.org> To: stable@freebsd.org Subject: [Conspectus] -stable, week ending 12th June 2000 Message-ID: <20000704003329.A81853@catkin.nothing-going-on.org>
next in thread | raw e-mail | index | archive | help
[ Posting on behalf of Salvo Bartolotta, who did all the hard work. See http://www.FreeBSD.org/conspectus/index.html for more information. To contribute, contact doc@FreeBSD.org -- N ] FreeBSD-stable Conspectus, week ending 12th June 2000 Dates # Posts Subject June 06 - 07 June 2 HEADS UP: More important Vinum information June 09 - June 09 1 HEADS UP: OpenSSH 2.1.0 merge June 08 - June 08 1 "sbsize" path for testing!! June 08 - June 08 1 [PATCH] psmintr out of sync.. June 08 - June 08 1 PS/2 mouse driver updates - can someone commit these? June 07 - June 07 2 4.0-STABLE crashes ...(SMP?) June 07 - June 10 9 Inetd problems June 08 - June 09 9 APC Back-UPS Pro June 11 - June 12 5 Re: AHA 1542 CP Configuration problems June 09 - June 09 2 linprocfs June 06 - June 07 3 ABIT BE6-II(hpt366) & ata in -stable June 07- June 07 5 Passive mode for FTP --------------------------------------------------------------------------- June 06 - June 07 (2 posts): HEADS UP: More important Vinum information No sooner had [Greg Lehey] fixed a Vinum bug than he found out another. The next day, he added that his /src/sys/dev/vinum/vinumrevive.c commit (to -CURRENT) would probably solve the problem -- he was still testing. On June 7, 2000, Greg announced 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. --------------------------------------------------------------------------- June 09 - June 09 (1 posts): HEADS UP: OpenSSH 2.1.0 merge On June 9, 2000, [Kris Kennaway] proclaimed that he had merged with -stable the OpenSSH 2.1.0 code from -current. He also provided the following information: 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 http://www.openssh.com for more interop details. Another new feature is support for OPIE passwords in SSH1 mode. Missing from OpenSSH 2.1.0 is support for OPIE and Kerberos in SSH2 mode, which will be hopefully added later. For more information on how to use OpenSSH 2.1, see the manpages, the file /usr/src/crypto/openssh/README.openssh2 and www.openssh.com. 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). Owing to some syntax errors, the OpenSSH MFC caused a temporary breach of -STABLE; the difficulty, however, was soon overcome. --------------------------------------------------------------------------- June 08 - June 08 (1 posts): "sbsize" path for testing!! On June 8, 2000, [Brian Fundakowski Feldman] made the following announcement: 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. 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. The patch, which will necessitate both a make world and new kernel/ modules build, is located at: http://people.FreeBSD.org/~green/ sbsize_etc.RELENG_3.patch. 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. So, anyone who can, test it out and report back. I need to get this done within the week or so :) --------------------------------------------------------------------------- June 08 - June 08 (1 posts): [PATCH] psmintr out of sync.. On June 8, 2000, [Kazutaka Yokota] 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. Incidentally, [Peter Radcliffe], in a letter of his, described another approach to the psmintr out of sync problem: 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 ... --------------------------------------------------------------------------- June 08 - June 08 (1 posts): PS/2 mouse driver updates - can someone commit these? [Graham Wheeler] modified the psm driver to supply support for the Synaptics touch pads, and posted his patches on June 8, 2000. He noticed that, in some respects, his code seemed to behave even better than Synaptics' driver. --------------------------------------------------------------------------- June 07 - June 07 (2 posts): 4.0-STABLE crashes ...(SMP?) On June 7, 2000, [Jesper Skriver] wrote that his -STABLE SMP system -- sources as of June 2 -- had been crashing regularly. He said that he had kernel crash dumps, too. 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. --------------------------------------------------------------------------- June 07 - June 10 (9 posts): Inetd problems [Vladimir Egorin] had been recording a number of inetd coredumps for the previous few weeks, and requested the -stable forum to help. It turned out that the coredumps were due to underscore characters in remote hostnames. Vladimir submitted a bug report as well as patches. Next, he asked: 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). [Chad Larson] replied: 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 '-'. [Peter Radcliffe] stated: "_" is not a valid character in a name in the IN zone of DNS but is not invalid in DNS, strictly. Valid characters in the IN zone are [0-9a-zA-Z-]. 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. 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 :/ [Cy Schubert] remarked: The standard was changed about 5 years ago. --------------------------------------------------------------------------- June 08 - June 09 (9 posts): APC Back-UPS Pro While running an APC Back-UPS Pro with upsd in the default configuration, [Andrew Tulloch] saw messages such as: 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 [Doug White] answered: 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 woudn't discount that the APC is doing wierd serial things -- it always seemed flakey to me when I was working on upsd. upsd hasn't been touched in years so it's possible it still has bugs :) On a related note, [Dan Larsson] wrote: 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 After doing a 'manual' build of the very latest source the problem was fixed. [Nate Williams], replying to Andres's letter, commented: 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. The following day, the discussion focused on the security aspect in an environment composed of multiple machines running off one ups. Doug White put forward this remark: 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 :) [Shawn Barnhart] rejoined: 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. 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. [Matthew Dodd] concluded the conversation by observing: Isn't this what 'NUT' is for? http://www.exploits.org/nut/ /usr/ports/sysutils/nut The next day, [Donald Fast], reminded Shawn that one could also use the multi-computer option, which can be found at this address, and then each machine could decide on its own. --------------------------------------------------------------------------- June 11 - June 12 (5 posts): Re: AHA 1542 CP Configuration problems [Jim Manley] had trouble with the configuration of his AHA1542CP SCSI adapter. [Brian Somers] sent him a patch, and told him that disabling the PnP probe should make the patch (and the adapter) work. [Warner Losh] was also informed (cc'ed) of that. 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. --------------------------------------------------------------------------- June 09 - June 09 (2 posts): linprocfs [Jonathan Perkin] was able to build the latest linprocfs commits, but he found an error related to textvp_fullpath (not defined). [David Malone] 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. --------------------------------------------------------------------------- June 06 - June 07 (3 posts): ABIT BE6-II(hpt366) & ata in -stable [Andrey Lavrentyev] experienced a dreadful plight in trying to make his board function. Subsequently, he got rid of his woes: I resolved my problem (see subj), was test some ata/66 disks & controllers... 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. :) PS. sysctl -w hw.atamodes=pio,...,pio, resolved udma problems. --------------------------------------------------------------------------- June 07 - June 07 (5 posts): Passive mode for FTP On June 7, 2000, [Stephen Montgomery-Smith] 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: Suppose I do: ftp ftp.freebsd.org and log on as anonymous. When I type ls I get the messages 500 'EPSV': command not understood. 500 'LPSV': command not understood. Passive mode refused. This worked in earler versions of FreeBSD 4.0, even when I had a firewall. [James Housley] suggested: This is from /etc/login.conf: default:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=NO:\ I changed FTP_PASSIVE_MODE=YES to NO and all was right in the world Don't forget cap_mkdb. [Charles Sprickman] went on to say: 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. cap_mkdb is to be run like so whenever you've changed login.conf: "cap_mkdb /etc/login.conf". 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. --------------------------------------------------------------------------- * The present Conspectus expresses my strictly personal understanding of what occurred on the FreeBSD-stable mailing list during the specified week. * 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. Salvo Bartolotta To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000704003329.A81853>