| 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 | +
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.
+ + + +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.
+ + + +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 :)
+
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 ...
+
[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.
+ + + +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. + + + +
[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.
+
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?
+ + + +/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.
+ + + +[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.
+ + + +[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.
+ + + +[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.
+
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.
+