diff --git a/en/conspectus/stable/2000/05/29.sgml b/en/conspectus/stable/2000/05/29.sgml index a48dc6b826..861cb4df7c 100644 --- a/en/conspectus/stable/2000/05/29.sgml +++ b/en/conspectus/stable/2000/05/29.sgml @@ -1,490 +1,490 @@ - + %includes;]> &header;
Dates # Posts Subject
May 23 - May 27 20 Re: ad0 drivers revisited
May 25 - 29 May 19 Problems compiling FreeBSD stable
May 24 - May 26 10 4-stable won't boot
May 23 - May 23 1 solved Re: spontaneous reboots
May 26 - May 27 5 making 4.0 DOS resistant
May 23 - May 23 2 Problems with NFS on FreeBSD 4.0
May 27 - May 29 3 Strange message
May 24 - May 27 5 Transparent proxies and fetch
May 23 - May 23 6 tun0: Warning: CHAP 0x81 not supported
May 23 - May 23 4 Re: -CURRENT Mylex on stable?
May 24 - May 25 7 ntpdate could not sync time from any server
May 25 - May 26 4 3DNow! binutils & Mesa for -STABLE

May 23 - May 27 (20 posts): Re: ad0 drivers revisited

Last week's thought-provoking debate - continued this week; the discussion focused on a a few possible + continued this week; the discussion focused on a few possible workarounds for circumventing the well-known ad driver bug early in the booting process. It seems that an effective solution has not still been implemented. However, a number of interesting suggestions were offered.

The point is that, in order to prevent any HD damage, PIO mode should be set by default very early at boot time. Albeit the bug only manifests itself in the worst form in a very limited number of cases -- ie rather special combinations of hardware components -- when it does, it does ...

May 25 - May 29 (19 posts): Problems compiling FreeBSD stable

On May 25, 2000, [Graham Wheeler] met a number of errors in the make world process while compiling gcc. After some experimentation, he got rid of them by using the "i" option for make. He seems to be the only person in the forum to have found these errors; probably, they were caused by an incorrect updating procedure.

Although the problems were soon easily solved, several fine points were hinted at in this thread: in particular, such a secondary specific procedure as "make includes", which is (usually) relevant to -CURRENT.

May 24 - May 26 (10 posts):  4-stable won't boot

The boot problem in question turned out to be trivial: the ata device was commented out (!) in the kernel configuration file.

The correspondents, subsequently, went on to describe their experience with such dangerous options as AUTO_EOI_1 and AUTO_EOI_2.

May 23 - May 23 (1 posts): solved Re: spontaneous reboots

On May 23, 2000, [Fritz Heinrichmeyer] announced that he had solved his spontaneous reboot problem by upgrading to -STABLE -- the SMP cleanups seemed to require a recompilation.

Incidentally, I have read about spontaneous reboots a good number of times in the FreeBSD mailing lists. The most common cause is bad hardware; sometimes, as in the present situation, the cause is of software nature. Upgrading to -STABLE, as is very often the case, is the solution to that vexed question.

On May, 29, however, Fritz wrote again. Other spontaneous reboots, in fact, occurred a few days later. Also, [MI] reported on the same matter -- MI, too, has been running SMP boards. This anomalous behavio(ur) seems to be specifically related to the SMP code, and is currently under investigation.

May 26 - May 27 (5 posts): making 4.0 DOS resistant

[Sameer R.Manek] was seeking information about FreeBSD strategies for handling DOS attacks.

[Bill Fumerola] pointed out that such options as ICMP_BANDLIM, TCP_DROP_SYNFIN, and TCP_RESTRICT_RST, albeit useful in fighting DOS attacks (e.g. attacks on IRC servers), cannot cope with spoofed ip syn floods. In particular, Bill is going to publish some (on-line) material about DOS attacks at large:

stay tuned... though I'll probably post my findings/suggestions on -security when I finally write them up.

May 23 - May 23 (2 posts): Problems with NFS on FreeBSD 4.0

[Paul A. Howes] , answering a letter of [Zherdev Anatoly]'s, suggested a procedure for installing ports over a network:

What I usually do is perform the first-time build and install on the server. Then, when I need one of the applications in /usr/ports on a different system, I NFS-mount /usr/ports and perform a "make reinstall" to get the application installed, but not built from scratch, on the client.

I do it this way, because I had been alerted to permission problems in the building of various components. It's just simpler to do all of the builds on a server, and only do the installs on the client. Besides, my server is a faster machine than the clients I have, so builds go MUCH faster on it.

May 27 - May 29 (3 posts): Strange message

[Derek Tattersall] wrote:

I am getting a message shortly after boot-up finishes which puzzles me. The message follows:

   lorne /kernel: arplookup 0.0.0.0 failed: host is not on local network.

[Lucas Ertl] replied:

I had almost the same message here, but it was host 13.10.15.10 instead of 0.0.0.0. The problem was a program called "LanGuard", installed on the Win2k box of one of my co-workers, that continously sent out arp requests but spoofed the MAC address of the machines NIC.

You could try:

   tcpdump -n -e -p arp

and then hunt down the MAC address.

May 24 - May 27 (5 posts): Transparent proxies and fetch

[Joe Shevland] found this error:

      Attempting to fetch from http://people.FreeBSD.org/~andreas/download/.
       fetch: empty reply from people.FreeBSD.org

Both the stable forum and the c.u.b.f.m. newsgroup provided him with the long sought-after answer:

Try

      "make FETCH_BEFORE_ARGS=-tb"

or add

      "FETCH_BEFORE_ARGS=-tb"

to

      /etc/make.conf.

May 23 - May 23 (6 posts):  tun0: Warning: CHAP 0x81 not supported

After setting up a pptp vpn (using pptp client from ports), [Michael Lucas] read these messages while trying to connect:

      May 23 10:02:24 proxybox (unknown)[2067]: log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:531]: 
       Client connection established.
       May 23 10:02:25 proxybox (unknown)[2067]: log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:637]:
       Outgoing call established.
       May 23 10:02:28 proxybox ppp[2065]: tun0: Warning: CHAP 0x81 not supported

[Brian Somers] responded:

This (CHAP 0x81) is M$CHAPv2. An implementation will be committed to -current RSN. The work has been done by [Nathan Binkert]

May 22 - May 23 (4 posts): Re: -CURRENT Mylex on stable?

[Shawn Barnhart] asked for the diffs making Mylex work under -STABLE.

[Mike Smith] rejoined:

1) Get the diffs.

You will need a CVS repository, or use the cvsweb interface at http://www.freebsd.org/cgi/cvsweb.cgi to extract the diffs. Note that mlx.c, mlx_disk.c, mlx_pci.c and mlxvar.h all changed in this fix.

2) Apply the diffs.

Shawn Barnhart:

I'm missing where the end result of diff/patch differs from the files themselves. It's a nice exercise, but kind of a PITA when you're not a CVS user.

Mike Smith:

The goal is to extract the changes I made to portions of the driver that are largely common between the two versions.

May 24 - May 25 (7 posts): ntpdate could not sync time from any server

[Lev Serebryakov] could not syncronize time on his homebox via ntpdate over a V.90 connection.

On the same wavelenght, complaining about ntpdate not syncing over a DSL line, [Glen Gross] added:

I have had the same experience, with a DSL line. I don't know if ntpdate requires the time to be within a certain threshold before it will sync or not.
Does anyone know the answer to this?

[Ian Smith] replied:

Yes, it does; -t sets the time ntpdate will wait for a valid response. Still get one of these logged once every few days when upstream PPP link is extra heavily used, but used to get it much more often before using:

      ntpdate -t 2.4 -s ntp.ml.csiro.au ntp.cs.mu.oz.au judge.lis.net.au

That's 2.4 seconds. man ntpdate isn't exactly clear re the unit format, but it does say that the default of 1 second is suitable for a LAN.

May 25 - May 26 (4 posts): 3DNow! binutils & Mesa for -STABLE

[Randall Hopper] posted the following message:

Thanks to David O'Brien for upgrading -current's binutils. This new version supports AMD 3DNow! for the K6-2, K6-III, and Athelon folks.

Wanting 3DNow support in gas, I pulled a copy from CVS and built it for 3.4-RELEASE (w/ gdb commented out). Now Mesa and friends detect and build in 3DNow support for Mesa on -stable.

For other -stable folks that want to give it a shot, just fetch copies of src/contrib/binutils and src/gnu/usr.bin/binutils modules from the latest CVS

   ("cvs checkout <module>").

Also, I'll be happy to send binutils exec binaries to anyone running 3.4.

[Wilko Bulte] asked:

Do thinks like fxtv use 3dnow to their advantage (I guess not)? But I assume the various mpeg* things might?

[Randall Hopper] remarked:

No fxtv doesn't, and I think you're right. As I recall MMX adds SIMD integer ops which is where the boost would be for things like pixel repacking. 3DNow's primary add was parallel floating/fixed point I believe.

Rather than reinvent the wheel, I'll likely stack fxtv on the hermes port one of these days if there isn't a big turn-out for an alternative video API.

Salvo Bartolotta

&footer; diff --git a/en/conspectus/stable/2000/06/12.sgml b/en/conspectus/stable/2000/06/12.sgml index b522f34423..4763b1071e 100644 --- a/en/conspectus/stable/2000/06/12.sgml +++ b/en/conspectus/stable/2000/06/12.sgml @@ -1,611 +1,611 @@ - + %includes;]> &header;
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 + In our case, inetd was receiving connections to the smtp + port, 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.

Salvo Bartolotta

&footer; diff --git a/en/news/sou1999.sgml b/en/news/sou1999.sgml index 1f9f78ffe9..c1df875ce7 100644 --- a/en/news/sou1999.sgml +++ b/en/news/sou1999.sgml @@ -1,375 +1,375 @@ - + %includes; ]> - + &header;

From Jordan Hubbard <jkh@FreeBSD.ORG>, Sunday January 10th, 1999.

Well, it's another year behind us, folks, and probably high time for another state of the union report!

Ahem... I'm never quite sure how to word these things since I'm always reminded of a U.S. president sitting in front of fireplace, trying to sound down-home and folksy for the corn growing states, or perhaps England's Queen on Christmas day, giving her usual somber-yet-hopeful address on how things went for Britannia during the previous year and what everyone should perhaps think about for the next. Neither one of those is really me, basically, so perhaps I'll just cut to the chase and focus on the most pertinent lessons (and objectives) to come out of the year 1998 for me.

1998 was, of course, the year that the Internet got bigger (no surprise), various "internetpraneurs" (gag) got richer and FreeBSD's user base, as measured by the ftp download stats grew at its usual 200-300% rate. More companies also entered the FreeBSD arena, either offering add-ons for or solutions incorporating FreeBSD, and our PR machine, as flimsy and low-key as it often is, managed to ratchet things up another notch. All in all, it was a very good year for FreeBSD and I don't think that even the most paranoid of us could claim otherwise - Microsoft took one in the shorts, we got bigger and just a bit better known, life was good.

Well, mostly. Whipping off my rosy glasses for a second, I can also say that there were still a number of rocks in the road and unexpected bends that left us not always in the best of control there. While downloads have gone up, CD sales aren't quite following suit since the whole CD market in general is suffering from increased Internet availability and its erosion of some of the CD's fundamental advantages. We still did quite well, considering the market's gradual implosion, but it would be foolish to continue to rely on a single CD product to provide the kinds of subsidies that have been steadily oiling the project's gears (we more than doubled the size of the FreeBSD.org computing cluster, for example, and significantly enlarged our developer equipment grant program in 1998, all things which cost $$$). It's fairly obvious that Walnut Creek CDROM will need to increase the number of products it offers if it wishes to remain an effective player in the FreeBSD game and we must continue, as a project, to be flexible in exploring all types of relationships with those who may now have a vested interest in FreeBSD's success. Things are well past the point where we can do everything that needs to be done as a serious and "grown up" solution just on good will and volunteerism alone.

With that in mind, sites like the FreeBSD Mall have been set up to try and market a wider variety of FreeBSD-related products and we've also begun exploring relationships with various companies who can derive measurable value from any PR campaign that enhances FreeBSD's reputation (translation: we want them to help pay for it :). As many people have somewhat bitterly pointed out by now, this business has become a 10% technology and 90% perception equation as far as the direction in which people stampede is concerned, and hate them for the mindless little sheep that they are, you still need to understand people's tendencies and behavioral patterns when it comes to dealing with anything they don't really understand. We've done a great job on the technology, we really have (and should be proud of that), but all too frequently we just throw up our hands over the perception issue and tell people to think whatever the hell they want to. Bad techies! Myopic techies! :-)

What can we do to change this in 1999? Well, I've also heard our advocate corps calling for logistical support ("Backup! We need some backup here!!") and I've listened to them, part of my project for the new years being to get more digital daemon imagery made available (which I have already commissioned), more glossies with various handy comparison charts on them ("FreeBSD and NT", "FreeBSD and Solaris", "FreeBSD and Linux", etc) and more newsletters for passing out to people. We can also produce more marketing periphenalia like buttons, stickers, new T-shirts, etc. to give people a wider array of stuff to proudly point to in support of the "emerging FreeBSD phenomenon." If we can manage to raise more money for PR, we can also perhaps buy some of these items in bulk to use as give-aways in various promotional deals. Other than that, I'm always open to suggestions. We need to do more effective PR, that much is inarguable, it's only a question of picking our targets for maximum effect given a limited operating budget.

The core team:

1998 also ended with a bit of a bang as far as FreeBSD's project management was concerned, frustration with a mostly recumbent core team goading a couple of bearded Danish Vikings into staging a midnight raid on -current, ruthlessly culling the weak and the lame from the source tree. Unfortunately, some of those weak or lame bits of code were still in use at the time and, with no prior public warning having been given, it did not exactly leave the various followers of -current with the feeling that the event was going to be the highlight of their Christmas season. Their complaints led, in turn, to something of a constitutional crisis within core, the rival factions each accusing one another of either impeding progress or using cowboy tactics to achieve that progress, and each faction had its legitimate points just as it had its wholly unreasonable ones. Coming out of this, various suggestions were bandied about concerning how we might put together a "better core team" to which such things simply did not happen (or, if they did, would not be our fault since we'd all be long gone :-) and many of these suggested cures were eventually deemed, quite rightly, to be worse than the disease. So what did we learn from the exercise then?

First off, I think everyone is now pretty much in agreement that these sorts of drive-by shootings are just not an option for the future, no matter what the justification. Anyone who contemplates a major addition or removal of functionality from the source tree MUST communicate those intentions well in advance and give the readership of -current, -stable or -announce (the former two depending on the branch the changes affect and the latter on the extent of the changes) ample time to respond. If there is a conclusively negative response to a proposed change, it just doesn't happen until and unless the proposal somehow manages to win people over through sheer dint of persuasive argument in its favor. If it's more a mixed bag of reactions, or there is little reaction at all, the developer is free to proceed at his or her discretion but still never without advance notice.

Second, in reaction to the various proposals put forward to either gut core or have core elected by popular vote, let me just say that we're not going to do that. There are probably several people currently in core who would gladly step aside and retire if they felt that adequate replacements had been found and the project was in good hands, but none of us like the scenario where anyone is overtly forced out of core. It's just not a reasonable way of going about it when so many less painful alternatives exist, and I, for one, would far rather simply grow core and let the inactive members fall off when they themselves have come to a decision that they have nothing left to contribute at a "core level", resignation from core having not stopped several folks from remaining as effective committers or making other valuable contributions.

We're a free software project and nobody's paid to be in core, no matter how seriously we may be tempted to take the whole core thing sometimes, and we need to remember that all of this started as a bunch of folks who simply wanted to work together in creating something useful and interesting. The day we lose that kind of informal atmosphere of productivity over politics is the day that something pretty fundamental goes out at the center of core and also the day that I'll retire from it myself, handing my hat to a replacement and wishing everyone the very best of luck.

I can also only sound a similar cautionary note about the idea of electing core from the user base, or with committers serving as a kind of "electoral college", as nice and democratic an idea as that might sound. The FreeBSD core team does not represent a democratically selected body and was, in fact, very carefully put together in a very non-democratic way. We picked core with the specific intention that it represent as diverse a set of hard-core FreeBSD evangelist/developers as we knew how to find and we've continued to add people using the same criteria.

In bringing someone into core, we don't look at whether they've been winning popularity contests lately or won the Programming Olympiad 3 times in a row, we ask ourselves: "Does this person bring a unique talent or viewpoint to the group? Will the resulting whole be greater than the sum of its parts?" These are our two most overriding concerns and, in fact, are the only grounds on which we've ever felt it necessary to actually ask for someone's resignation from core. We can tolerate quite a bit from people but not when it impacts core's fundamental ability to work together or seeks to undermine the very diversity of opinion we've worked so hard to cultivate. It's good to be an effective group of decision makers as a core team, and we do have our moments (both ways), but sometimes it's even better to know simply when to stay out of the way and just make sure the train stays roughly on the tracks. We've prevented a lot more stupidity through having such a diverse and carefully selected core team than I think we've ever caused and I do not trust the democratic process to leave us with the same thing after a few elections.

Core is also continuing to work on drafting some internal documents which cover, in much better detail, just what our rules as committers are, those superseding any "core member privileges", governing how large-scale code removal and addition operations should be carried out. We'll post something to committers just as soon as we finally flesh it out to our mutual satisfaction but, in a nutshell, it basically just insists that people need to be warned before such changes happen and that the owner of a given body of code should be given first say as to whether or not it's time to kill it in the name of obsolescence or redundancy. Finally, we are looking at the general issue of communication inside and outside core and the question of whether or not to bring in some new member(s) at this time. That discussion is ongoing and I'll do my best to keep everyone up to date on that as things progress.

Release numbering:

Other decisions on the horizon concern returning to our former practice of using "major" version numbers for branches and "minor" numbers for releases, the revision number field only being used to denote point-releases which were done for some reason significant enough to merit such a special release. This means that the next release will be 3.1, not 3.0.1, and the new branch will be 4.0-current instead of 3.1-current. Is this just a marketing ploy? No, it's not, though marketing has indeed been a frequent casualty of our current numbering scheme.

We have frequently made fairly large changes between our "point releases", jumps like 2.2.5->2.2.6 and 2.2.6->2.2.7 being a lot bigger than most folks gave them credit for given that it was just one little revision number being changed. This one simple facet of human nature reduced the effectiveness of these releases and under-sold the work being done by our developers to substantially improve every release we do, regardless of which branch it's on.

This is not a trend which seems to be reversing itself and so I feel quite safe in saying that 3.1 will be a "full release" over 3.0 in its own right and not merely the "3.0.1" which conveys such a different impression. It's also very important to note that since our branches seem to typically last from 12-18 months these days, no matter what we try in attempting to kill a branch earlier, a major version bump (4.0) is entirely merited for something which won't see full release status until sometime in the year 2000. This will make the marketing people happy since they won't have such an uphill battle on number perception and it will make the users happy since they'll get a clearer picture of what changed in, say, 3.1 to 3.2 vs 3.1 to 3.1.1 (which might be an important security update). It will also make this particular developer happy since I'll have the revision number space back again for doing point releases. It's a win and so we're going to do it. 3.0.1 is dead, long live 3.1! :)

Technology:

This last year also saw a successful transition to ELF from a.out format and a new kernel loadable module scheme which allows modules to be read in without a runtime dependency on /usr/bin/ld. We also got a new boot loader (with a forth interpreter!) to aggregate a "kernel" at boot time. These are both powerful new mechanisms and, coupled with some new stuff which will be coming in 1999, should give us a far more dynamic and extensible system than we've ever had before.

Not to be overlooked is also our new SCSI CAM system, giving us more robust behavior with large drive arrays and supporting more of the high-end SCSI controllers, or the support for multiple processors on the x86. We made considerable progress all across the board with the release of 3.0, finally reaching a point with the DEC Alpha architecture port where people starting worrying more about the packages collection than they did about working kernels or a /usr/src which built. That represents considerable progress towards "genuine usefulness" and I hope that 1999 will see a fully desktop capable release of FreeBSD/axp (to say nothing of a server capable one), various difficulties with X server technology making the Alpha desktop a unique milestone in its own right, especially if it's on an ARC or AlphaBIOS machine. 1999 may also see the early release of a SPARC port, though it's still far too early to say anything more definite than that. Join the sparc@FreeBSD.org mailing list if you want to follow these efforts.

IPv6 and IPSec were also hotly debated topics in 1998, FreeBSD's refusal to back any specific implementation being cited by many as an example of core's over-conservatism in action. Happily for everyone, our wait-and-see attitude proved to be the right one when the two major "competing" groups, KAME and INRIA, finally agreed to merge their implementations. We have, in turn, committed to adopting this merged implementation and have several people from the KAME/INRIA groups on the FreeBSD development team who will be importing and maintaining this code as it becomes available.

There is also substantial work underway with the VM system and the filesystem code, much of which is either being tested quietly in small groups (Dillon/Dyson/Greenman) or is awaiting the 4.0 branch event, still scheduled for January 15th, 1999. In other areas, we have Kazu's very welcome total redesign of the console driver coming into -current along with USB support, courtesy of Nick Hibma and others. This is just to name a few of the projects underway and I don't mean to slight anyone by not mentioning theirs directly, these are just 3 ongoing projects right off the top of my head. We seem to be gaining a lot of technical momentum, and that's great, just so long as we can also keep our heads during the times where not everyone is in total agreement about which technical direction to take.

Tech support:

A point which should also be obvious to everyone yet still somehow requires frequent reinforcement is the fact that we need to maintain participation in this project as something which is also enjoyable for the developer/participants or they will just as quickly go away again and stop giving each and every one of us the benefit of their volunteer labor (on which a dollar value could not even be put). This is something which each and every one of our users needs to be aware of, at least somewhere in the back of their minds, for those times when they're tempted to start thinking of FreeBSD as just another shrink-wrap solution from Software, Inc. and start treating project members like personal employees. Those looking for actual FreeBSD employees should send mail to jobs@FreeBSD.org and indicate how much money they're willing to pay, otherwise don't do it.

I don't mean to come across so harshly here that people don't even bother asking us for help, I'm simply saying that those users who avail themselves of the various FreeBSD volunteer tech support mechanisms out there (mail, news, irc, etc) should always understand that asking another perfect stranger for help is just not much different from asking a random person on the street for a dollar. If you want to get free handouts, you'd better at the very least learn to ask politely and when to take "no" for an answer! :-) I've seen a lot of abuse of the various tech support forum volunteers this last year and it frankly sucks. People just need to be more considerate and stop regarding free tech support as a god-given right rather than a - very special privilege. If you want on-demand tech support, to to + very special privilege. If you want on-demand tech support, go to www.freebsdmall.com and order yourself a tech support contract. You get what you pay for! :)

Looking forward:

What do I see ahead for 1999? Well, assuming that we don't all vanish in some pre-millennial holocaust, I see more interesting new features, improved marketing, more commercial interest, more magazine articles and press attention, basically more of the same if we can just try to stay reasonably well focused on what we need to do and not get distracted into chasing weird desktop dreams or suddenly become overly minimalist or kitchen-sink biased in /usr/src, continuing to chart the middle course we're more famous for. The FreeBSD core team, one year older and hopefully a little wiser, needs to continue keeping a light but steady hand on the tiller, relying on our developers as usual to provide much of the actual motive force behind FreeBSD.

Our users also need to become more involved and I'm hoping that 1999 will be the year when a lot more local user groups and other self-help type of organizations are formed. The Handbook and FAQ are documents which are getting better, hopefully another trend we'll see continue into 1999 as Nik Clayton, our fearless new Documentation Project leader, continues at the helm. We still have to remember, however, that for many users the handbook and FAQ docs are just not enough.

Linux has succeeded largely because of a large grass-roots support and evangelism network which allows it to reach such people and communicate the message to them. If FreeBSD's own users want to see FreeBSD doing better against whomever they most perceive as its competition, and 1998 was certainly a year where I heard a lot of complaining about this, then they're going to simply have to get off their collective duffs and put in more of this kind of work. When was the last time a bunch of FreeBSD users got together to hand out FreeBSD literature at a Microsoft product launch, for example, or held an install-a-thon at a local computer show?

The Linux folks do things like that all the time, apparently, whereas only a very few die-hard FreeBSD users currently do it now, so why not help these people out? Join the advocacy@FreeBSD.org mailing list and discuss your plans there so that others with more enthusiasm than ideas can also learn from and perhaps help you with yours. Write short articles for the new advocacy sites like www.daemonnews.org or www.freebsdrocks.com and help promote the success of BSD evangelical publications.

Phrases like "this is your FreeBSD" and "it all depends on you" may seem shop-worn and trite, but they're also unfortunately still true when there's so few of us and so many of you. If FreeBSD is to really continue to succeed in 1999, it will only be with substantial user participation and that means you, users! Start a local user group, donate some of your older CD releases to the local library, try and convince a local small business or ISP to use FreeBSD, these are just a few of the many things that can be done if you're truly interested in putting some energy into FreeBSD and ideas for what to do will be the least of your worries if you're truly motivated.

Executive Summary: 1999, rah rah rah, let's do it! :)

&footer; diff --git a/en/releases/2.0/notes.sgml b/en/releases/2.0/notes.sgml index 05a9e4ad87..db7536ca04 100644 --- a/en/releases/2.0/notes.sgml +++ b/en/releases/2.0/notes.sgml @@ -1,657 +1,657 @@ - + %includes; ]> - + &header; 
 
                                  RELEASE NOTES
                                     FreeBSD
                                   Release 2.0
 
 1. Technical overview
 ---------------------
 
 FreeBSD is a freely available, full source 4.4 BSD Lite based release
 for Intel i386/i486/Pentium (or compatible) based PC's.  It is based
 primarily on software from U.C. Berkeley's CSRG group, with some
 enhancements from NetBSD, 386BSD, and the Free Software Foundation.
 
 Since our first release of FreeBSD 1.0 some 18 months ago, FreeBSD
 has changed almost entirely.  A new port from the Berkeley 4.4 code
 base was done, which brought the legal status of the system out of the
 shadows with the blessing of Novell (new owners of USL and UNIX).  The
 port to 4.4 has also brought in a host of new features, filesystems
 and enhanced driver support.  With our new unencumbered code base, we
 have every reason to hope that we'll be able to release quality
 operating systems without further legal encumbrance for some time to
 come!
 
 FreeBSD 2.0 represents the culmination of almost 2 years of work and
 many thousands of man hours put in by an international development team.
 We hope you enjoy it!
 
 Many packages have also been upgraded or added, such as XFree86 3.1,
 xview 3.2, elm, nntp, mh, InterViews and dozens of other miscellaneous
 utilities have been ported and are now available as add-ons.  See the
 ports collection (or the package collection) for a complete summary.
 
 For a list of contributors, please see the file "CONTRIB.FreeBSD",
 which should be bundled with your bindist distribution.
 
 Also see the new "REGISTER.FreeBSD" file for information on registering
 with the "Free BSD user counter".  We've also provided a list of who's
 responsible for what (so that you may query them directly) in the
 "ROSTER.FreeBSD" file; use of this file is encouraged to ensure faster
 resolution of any problems you may have!
 
 The core of FreeBSD does not contain DES code which would inhibit its
 being exported outside the United States.  There is an add-on package
 to the core distribution, for use only in the United States, that
 contains the programs that normally use DES.  The auxiliary packages
 provided separately can be used by anyone.   A freely (from outside the
 U.S.) exportable European distribution of DES for our non U.S. users also
 exists and is described in the FreeBSD FAQ.
 
 If password security for FreeBSD is all you need, and you have no
 requirement for copying encrypted passwords from different hosts (Suns,
 DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5
 based security may be all you require!  We feel that our default security
 model is more than a match for DES, and without any messy export issues
 to deal with.  If you're outside (or even inside) the U.S., give it a try!
 
 
 1.1 What's new in 2.0?
 ----------------------
 
 4.4 Lite
 --------
 As previously stated, this release is based entirely on CSRG's
 latest (and last) BSD release - 4.4 Lite.  This features a number
 of improvements over 4.2BSD (Net/2), not least of which are:
 
 o       Legal approval of Novell & U.C. Berkeley.  After the settlement
         of the longstanding lawsuit between USL/UCB/Novell/BSDI, all
         parties were (strongly) encouraged to move to 4.4 Lite in order
         to avoid future legal entanglements.  The fact that we've now done
         so should make this release much more attractive to potential
         commercial users.
 
 o       Many new filesystem types, such as stackable filesystems, union
         filesystems, "portals", kernfs, a simple log-structured filesystem, a
         new version of NFS (NQNFS), etc.  While some of these new filesystems
         are also rather unpolished and will require significant additional
         work to be truly robust, they're a good start.
 
 o       64bit offsets, allowing filesystems of up to 2^63 bytes in size.
 
 o       Further work towards full POSIX compliance.
 
 IP multicast support
 --------------------
 The IP multicast support has been upgraded from the woefully ancient
 1.x code in 4.4-Lite to the most current and up-to-date 3.3 release
 from Steve D. and Ajit.  The non-forwarding code is known to work (for
 some limited test cases).  The multicast forwarder and user-mode
 multicast routing process are known to compile, but have not been
 significantly tested (hopefully this will happen before 2.0 release).
 
 Owner:                  wollman
 Sources involved:       sys/netinet, usr.sbin/mrouted
 
 Loadable Kernel Modules
 -----------------------
 David Greenman incorporated NetBSD's port of Terry Lambert's loadable
 kernel module support.  Garrett Wollman wrote the support for loadable
 file systems, and Søren Schmidt did the same for loadable execution
 classes.
 
 Owner:                  core
 Sources involved:       sys/kern, sbin/modload, sbin/modunload,
                         usr.bin/modstat
 
 
 Loadable filesystems
 --------------------
 Most filesystems are now dynamically loadable on demand, with the
 exception of the UFS family (FFS, LFS, and MFS).  With the exception
 of NFS, all such filesystems can be unloaded when all references are
 unmounted.  To support this functionality, the 
 
 getvfsbyname(3)
 
 family of functions has been added to the C library and the 
 lsvfs(1)
 
 command provides the same information at the shell level.  Be aware of
 the following current restrictions:
 
         - /usr/bin may not reside on a dynamically loaded filesystem.
         - There must be a writable /tmp directory available
           before filesystems are loaded (moving / to the top of your
           /etc/fstab file will accomplish this).
         - Some of the more esoteric filesystems simply don't work when loaded
           dynamically (though they often don't work "static", either.)
 
 Owner:                  wollman
 Sources involved:       sys/*fs, lkm/*fs, usr.bin/lsvfs, lib/libc/gen
 
 
 S/Key
 -----
 Since version 1.1.5, FreeBSD has supported the S/Key one time password
 scheme.  The version used is derived from the logdaemon package of Wietse
 Venema.
 Some of the features new in 2.0 are:
         - New access control table format to impose the use of S/Keys
           based on: hostname, ip address, port, username, group id.
         - S/Key support can be disabled by not having the access control
           table.
 The second item explains the absence of skey.access in the installed /etc.
 To enable S/Key support, create a file skey.access in /etc and fill it
 according to your needs. See also skey.
 access(5)
 and the example in
 /usr/share/examples/etc/skey.access.
 
 Owner:                  pst, guido
 Sources involved:       lib/libskey, usr.bin/key* (plus patches to others)
 
 
 TCP/IP over parallel (printer) port
 -----------------------------------
 You can now run TCP/IP over a standard LapLink(tm) cable, if both ends
 have an interrupt-driven printerport.  The interface is named "lp0"
 where '0' is the same as the lpt# unit number.  This is not compatible
 with PLIP.  If you run NFS, try setting MTU to 9180, otherwise leave
 it at 1500 unless you have a good reason to change it.  Speed varies
 with the CPU-type, with up to 70 kbyte/sec having been seen and 50
 kbyte/sec being the norm.
 
 Owner:                  phk
 Sources involved:       isa/lpt.c
 
 
 ProAudioSpectrum SCSI driver
 ----------------------------
 If you have a PAS board with a CD-ROM, and the MS-DOS driver is called
 TSLCDR.SYS, then the "pas" driver should work on your card.  You can
 attach disks, CDROMs and tapes, but due to the nature of the hardware
 involved, the transfer rate is limited to < 690 kbyte/sec.  For CD-ROM
 use, this is generally more than enough.
 
 Owner:                  phk
 Sources involved:       isa/pas.c
 
 
 Adaptec 2742/2842 SCSI driver
 -----------------------------
 Despite the non-cooperation of Adaptec in providing technical
 information, we now have a driver for the AHA-274x and AHA-284x
 series SCSI controller family.  This driver uses the GPL'd
 Linux sequencer code, so until we find an alternative, this
 will be part of the kernel that requires source code to be
 distributed with it at all times.  This shouldn't be a problem
 for any of FreeBSD's current users.
 
 Owner:                  gibbs
 Sources involved:       isa/aic7770.c sys/gnu/misc/*
 
 
 Gzip'd binaries
 ----------------
 We have an experimental implementation for direct execution of gzip'ed
 binaries in this release.  When enabled, it allows you to simply gzip
 your binaries, remove the '.gz' extension and make the file
 executable.  There is a big speed and memory consumption penalty for
 doing this, but for laptop users it may be worthwhile.  The maximum
 savings are generally around 10 Mb of disk space.
 
 Owner:                  phk
 Sources involved:       kern/imgact_gzip.c kern/inflate.c
 
 
 Diskless booting
 ----------------
 
 Diskless booting in 2.0 is much improved since 1.1.5.  The
 boot-program is in src/sys/i386/boot/netboot, and can be run from an
 MSDOS system or burned into an EPROM.  Local swapping is also
 possible.  WD, SMC, 3COM and Novell ethernet cards are currently
 supported.
 
 Owner:                  Martin Renters & phk
 Sources involved:       i386/boot/netboot, sys/nfs/nfs_vfsops.h
 
 
 Device configuration database
 -----------------------------
 The kernel now keeps better track of which device drivers are active and
 where the devices are attached; this information is made available to
 user programs via the new 
 sysctl(3)
 management interface.  Current
 applications include 
 lsdev(8),
 which lists the currently configured
 devices.  In the future, we expect to use this code to automatically
 generate a configuration file for you at installation time.
 
 Owner:                  wollman
 Sources involved:       sys/i386, sys/scsi, sys/kern/kern_devconf.c,
                         sys/sys/devconf.h, usr.sbin/lsdev
 
 
 Kernel management interface
 ---------------------------
 With 4.4-Lite, we now have a better management interface for the endless
 series of kernel variables and parameters which were previously manipulated
 by reading and writing /dev/kmem.  Many programs have been rewritten to
 use this interface, although many old-style programs still remain.  Some
 variables which were never accessible before are now available through
 the 
 sysctl(1)
 program.  In addition to the standard 4.4BSD MIB variables,
 we have added support for YP/NIS domains (kern.domainname), controlling
 the update daemon (kern.update), retrieving the OS release date
 (kern.osreldate), determining the name of the booted kernel (kern.bootfile),
 and checking for hardware floating-point support (hw.floatingpoint).
 We have also added support to make management queries of devices and
 filesystems.
 
 Owner:                  core
 Sources involved:       sys, usr.bin/sysctl
 
 
 iBCS2 support
 -------------
 FreeBSD now supports running iBCS2 compatible binaries (currently
 SCO UNIX 3.2.2 & 3.2.4 and ISC 2.2 COFF format are supported).
 The iBCS2 emulator is in its early stages, but it is functional, we
 haven't been able to do exhaustive testing (lack of commercial apps),
 but almost all of SCO's 3.2.2 binaries are working, so is an old
 INFORMIX-2.10 for SCO. Further testing is necessary to complete this
 project. There is also work under way for ELF & XOUT loaders, and
 most of the svr4 syscall wrappers have been written.
 
 Owner:                  Soren Schmidt (sos) & Sean Eric Fagan (sef)
 Sources involved:       sys/i386/ibcs2/* + misc kernel changes.
 
 
 2. Supported Configurations
 ---------------------------
 
 FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus
 based PC's, ranging from 386sx to Pentium class machines (though the
 386sx is not recommended).  Support for generic IDE or ESDI drive
 configurations, various SCSI controller, network and serial cards is
 also provided.
 
 Following is a list of all currently known disk controllers and
 ethernet cards known to work with FreeBSD.  Other configurations may
 very well work, and we have simply not received any indication of
 this.
 
 
 2.1. Disk Controllers
 
 WD1003 (any generic MFM/RLL)
 WD1007 (any generic IDE/ESDI)
 [Note: the new Extended IDE controllers in newer PC's work, although no
 extended features are used.]
 
 Adaptec 152x series ISA SCSI controllers
 Adaptec 154x series ISA SCSI controllers
 Adaptec 174x series EISA SCSI controller in standard and enhanced mode.
 Adaptec 2742/2842 series ISA/EISA SCSI controllers
 Adaptec AIC-6260 and AIC-6360 based boards, which includes
 the AHA-152x and SoundBlaster SCSI cards.
 
 ** Note: You cannot boot from the Soundblaster cards
 as they have no on-board BIOS, which is necessary for mapping
 the boot device into the system BIOS I/O vectors.
 They're perfectly usable for external tapes, CDROMs, etc,
 however.  The same goes for any other AIC-6x60 based card
 without a boot ROM.  Some systems DO have a boot ROM, which
 is generally indicated by some sort of message when the system
 is first powered up or reset.  Check your system/board documentation
 for more details.
 
 [Note that Buslogic was formerly known as "Bustec"]
 Buslogic 545S & 545c
 Buslogic 445S/445c VLB SCSI controller
 Buslogic 742A, 747S, 747c EISA SCSI controller.
 Buslogic 946c PCI SCSI controller
 
 NCR 53C810 and 53C825 PCI SCSI controller.
 
 DTC 3290 EISA SCSI controller in 1542 emulation mode.
 
 UltraStor 14F, 24F and 34F SCSI controllers.
 
 Seagate ST01/02 SCSI controllers.
 
 Future Domain 8xx/950 series SCSI controllers.
 
 With all supported SCSI controllers, full support is provided for
 SCSI-I & SCSI-II peripherals, including Disks, tape drives (including
 DAT) and CD ROM drives.  Note: This and the mcd driver (Mitsumi CDROM
 interface card) are the only way a CD ROM drive may be currently
 attached to a FreeBSD system; we do not support SoundBlaster
 (non-SCSI) CDROM interface, or other "non-SCSI" adapters.  The
 ProAudio Spectrum SCSI and SoundBlaster SCSI controllers are
 supported.
 
 Some controllers have limitations with the way they deal with >16MB of
 memory, due to the fact that the ISA bus only has a DMA address space of
 24 bits.  If you do your arithmetic, you'll see that this makes it
 impossible to do direct DMA to any address >16MB.  This limitation is
 even true of some EISA controllers (which are normally 32 bit) when
 they're configured to emulate an ISA card, which they then do in *all*
 respects.  This problem is avoided entirely by IDE controllers (which do
 not use DMA), true EISA controllers (like the UltraStor or Adaptec
 1742A) and most VLB (local bus) controllers.  In the cases where it's
 necessary, the system will use "bounce buffers" to talk to the
 controller so that you can still use more than 16Mb of memory without
 difficulty.
 
 
 2.2. Ethernet cards
 
 SMC Elite 16 WD8013 ethernet interface, and most other WD8003E,
 WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT
 based clones.  SMC Elite Ultra is also supported.
 
 DEC EtherWORKS III NICs (DE203, DE204, and DE205)
 DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422)
 
 Isolan AT 4141-0 (16 bit)
 Isolink 4110     (8 bit)
 
 Novell NE1000, NE2000, and NE2100 ethernet interface.
 
 3Com 3C501 cards
 
 3Com 3C503 Etherlink II
 
 3Com 3C507 Etherlink 16/TP
 
 3Com 3C509 and 3C579 Etherlink III
 
 Toshiba ethernet cards
 
 PCMCIA ethernet cards from IBM and National Semiconductor are also
 supported.
 
 2.3. Misc
 
 AST 4 port serial card using shared IRQ.
 
 ARNET 8 port serial card using shared IRQ.
 
 BOCA ATIO66 6 port serial card using shared IRQ.
 
 STB 4 port card using shared IRQ.
 
 Mitsumi (all models) CDROM interface and drive.
 
 Soundblaster SCSI and ProAudio Spectrum SCSI CDROM interface and drive.
 
 Adlib, Soundblaster, Soundblaster Pro, ProAudioSpectrum, Gravis UltraSound
 and Roland MPU-401 sound cards.
 
 FreeBSD currently does NOT support IBM's microchannel (MCA) bus, but
 support is apparently close to materializing.  Details will be posted
 as the situation develops.
 
 
 3. Obtaining FreeBSD.
 ---------------------
 
 You may obtain FreeBSD in a variety of ways:
 
 1. FTP/Mail
 
 You can ftp FreeBSD and any or all of its optional packages from
 `freebsd.cdrom.com' - the official FreeBSD release site.
 
 For other locations that mirror the FreeBSD software see the file
 MIRROR.SITES.  Please ftp the distribution from the nearest site
 to you netwise.
 
 If you do not have access to the internet and electronic mail is your
 only recourse, then you may still fetch the files by sending mail to
 `ftpmail@decwrl.dec.com' - putting the keyword "help" in your message
 to get more information on how to fetch files from freebsd.cdrom.com.
 Note: This approach will end up sending many *tens of megabytes*
 through the mail, and should only be employed as an absolute LAST
 resort!
 
 
 2. CDROM
 
 FreeBSD 2.0 may be ordered on CDROM from:
 
         Walnut Creek CDROM
         4041 Pike Lane, Suite D
         Concord CA  94520
         1-800-786-9907, +1-510-674-0783, +1-510-674-0821 (fax)
 
 Or via the internet from orders@cdrom.com.  Their current catalog can
 be obtained via ftp as ftp.cdrom.com:/cdrom/catalog.
 
 Cost is $39.95.  Shipping (per order not per disc) is $5 in the US, Canada,
 or Mexico and $10.00 overseas.  They accept Visa, Mastercard, American
 Express, and ship COD to the United States.  California residents please
 add 8.25% sales tax.
 
 Should you be dissatisfied for any reason, the CD comes with an
 unconditional return policy.
 
 Note that Walnut Creek CDROM does NOT provide technical support for FreeBSD,
 you need to contact the FreeBSD team for that.  Please see section 5 for
 more information.
 
 
 4. Preparing for the installation.
 ----------------------------------
 
 1. Floppy Installation
 
 If you must install from floppy disks, either due to space constraints
 on your hard disk or just because you enjoy doing things the hard
 way, you must first prepare some floppies for the install.
 
 You will need either 10 1.44MB floppies or 12 1.2MB floppies to
 store just the bindist (binary distribution).  These *must* be
 formatted using MS-DOS, using either the FORMAT command in MS-DOS
 or the File Manager in Microsoft Windows to prepare the floppies
-(though factory preformatted floppies will also well well, provided
+(though factory preformatted floppies will also work well, provided
 that they haven't been previously used for something else).
 
 After you've formatted the floppy disks, you'll need to copy the
 files onto them.  There are 56 total files for the bindist itself,
 plus three small files (CKSUMS, do_cksum.sh, and extract.sh) for
 the install program to use.  ALL of these files must be copies onto
 the floppies.  Each of the bindist files are named "bindist.??",
 where the "??" is replaced by the letter sequence aa through cd.
 Copy these files onto the floppies, placing the three small install
 files onto the final floppy.  The order in which you copy the files
 to floppy is not important, but it makes labelling the disks easier
 if you go in some sort of alphabetical order.
 
 After you've done this, the floppy disks are ready for the install
 program to use.
 
 Later on, after you get the binary distribution installed and everything
 is going great, the same instructions will apply for the other
 distributions, such as the manpages distribution or the XFree86 distribution.
 The number of floppies required will, of course, change for bigger or
 smaller distributions.
 
 
 2. Hard Disk Installation
 
 To prepare for installation from an MS-DOS partition, you should simply
 copy the files from the distribution into a directory with the same
 name as the distribution.  For example, if you are preparing to
 install the bindist set, then make a directory on your C: drive named
 C:\BINDIST and copy the files there.  This will allow the installation
 program to find the files automatically.
 
 
 3. QIC/SCSI Tape Installation.
 
 Installing from tape is probably the easiest method, short of an
 on-line install using ftp or installing from a CDROM.  The installation
 program expects the files to be simply tar'red onto the tape, so after
 getting all of the files for distribution you're interested in, simply
 tar them onto the tape with something like:
 
         cd <where the *.?? files are>
         tar cvf /dev/rwt0 (or /dev/rst0) .
 
 from a directory with just the distribution files in it.  Make sure
 that you remember to put CKSUMS, do_cksum.sh, and extract.sh files
 in this directory as well!
 
 If you wish to install multiple *dist releases from one tape, do the
 following:
 
 1. cd to the parent directory of the distributions and put them on tape
    like so:
                 tar cvf /dev/rwt0 (or /dev/rst0) bindist srcdist ...
 
 2. Install the first distribution on the tape using the tape installation
    method as normal.  Afterwards, *do not* erase the contents of the temporary
    directory.  Get a shell with ESC-ESC and cd to the temporary directory
    yourself.  For each additional *dist you want to load, cd to its
    subdirectory and type `sh ./extract.sh'.
 
 
 5. Reporting problems, making suggestions, submitting code.
 -----------------------------------------------------------
 
 Your suggestions, bug reports and contributions of code are always
 valued - please do not hesitate to report any problems you may find
 (preferably with a fix attached if you can!).
 
 The preferred method to submit bug reports from a machine with internet
 mail connectivity is to use the send-pr command.  Bug reports will be
 dutifully filed by our faithful bugfiler program and you can be sure
 that we'll do our best to respond to all reported bugs as soon as
 possible.
 
 If, for some reason, you are unable to use the send-pr command to
 submit a bug report, you can try to send it to:
 
                 bugs@FreeBSD.org
 
 
 Otherwise, for any questions or suggestions, please send mail to:
 
                 questions@FreeBSD.org
 
 Additionally, being a volunteer effort, we are always happy to have
 extra hands willing to help - there are already far more enhancements
 to be done than we can ever manage to do by ourselves!  To contact us
 on technical matters, or with offers of help, you may send mail to:
 
                 hackers@FreeBSD.org
 
 Since these mailing lists can experience significant amounts of
 traffic, if you've got slow or expensive mail access and you're
 only interested in keeping up with significant FreeBSD events, you may
 find it preferable to subscribe to:
 
                 announce@FreeBSD.org
 
 
 All but the FreeBSD-bugs groups can be freely joined by anyone wishing
 to do so.  Send mail to MajorDomo@FreeBSD.org and include the keyword
 `help' on a line by itself somewhere in the body of the message.  This
 will give you more information on joining the various lists, accessing
 archives, etc.  There are a number of mailing lists targeted at
 special interest groups not mentioned here, so send mail to majordomo
 and ask about them!
 
 
 6. Acknowledgements
 -------------------
 
 FreeBSD represents the cumulative work of many dozens, if not
 hundreds, of individuals from around the world who have worked very
 hard to bring you this release.  It would be very difficult, if not
 impossible, to enumerate everyone who's contributed to FreeBSD, but
 nonetheless we shall try (in alphabetical order, of course). If your
 name is not mentioned, please be assured that its omission is entirely
 accidental.
 
 
 The Computer Systems Research Group (CSRG), U.C. Berkeley.
 
 Bill Jolitz, for his extensive work with 386BSD.
 
 The FreeBSD "core" team:
 
         Andrew A. Chernov
         John Dyson
         Bruce Evans
         David Greenman
         Rodney W. Grimes
         Jordan K. Hubbard
         Poul-Henning Kamp
         Rich Murphey
         Gary Palmer
         Geoff Rehmet
         Paul Richards
         Soren Schmidt
         Andreas Schulz
         Jack Vogel
         Garrett A. Wollman
 
 
 Special mention to:
 
         Robert Bruce and Jack Velte of Walnut Creek CDROM, without
         whose help (and continuing support) this release would never
         have been possible.
 
         Dermot McDonnell for his donation of a Toshiba XM3401B CDROM
         drive.
 
         The NetBSD group for their frequent assistance and commentary.
 
         Additional FreeBSD helpers and beta testers:
 
         J.T. Conklin                            Julian Elischer
         Sean Eric Fagan                         Jeffrey Hsu
         Terry Lambert                           L Jonas Olsson
         Chris Provenzano                        Dave Rivers
         Guido van Rooij                         Steven Wallace
         Atsushi Murai                           Scott Mace
         Andrew Moore                            Nate Williams
 
         And everyone at Montana State University for their initial support.
 
 
 Thanks to everyone, especially those not mentioned, and we sincerely
 hope you enjoy this release of FreeBSD!
 
 
                         The FreeBSD Core Team
 
 Id: RELNOTES.FreeBSD,v 1.21 1994/12/02 20:27:11 jkh Exp

Release Home &footer; diff --git a/en/releases/2.1.5R/announce.sgml b/en/releases/2.1.5R/announce.sgml index 1d6ec6eb08..aa6b921529 100644 --- a/en/releases/2.1.5R/announce.sgml +++ b/en/releases/2.1.5R/announce.sgml @@ -1,270 +1,270 @@ - + %includes; ]> &header;

FreeBSD 2.1.5-RELEASE is now available on ftp.FreeBSD.org and various FTP mirror sites throughout the world. It can also be ordered on CD from -from Walnut Creek CDROM.

+Walnut Creek CDROM.

FreeBSD 2.1.5 represents the culmination of over a year's worth of work on the 2.1-STABLE branch of FreeBSD since it began with FreeBSD 2.0.5. In the 7 months since 2.1 -was released, many many bug fixes, updates and careful enhancements +was released, many bug fixes, updates and careful enhancements have been made, the results of which you now see here.

The STABLE branch was conceived out of the need to allow FreeBSD to grow and support long-term development projects (like devfs, NFSv3, IPX, PCCARD, etc.) while at the same time not jeopardizing the stability of its existing user base. FreeBSD 2.1.5 marks the finishing point for that effort and, barring any small "slipstream" releases done to solve significant problems, no further releases along the 2.1-STABLE branch are anticipated. The concept of "stable" and "experimental" tracks is not being abandoned, we'll simply be doing this somewhat differently in the future.

For more information on the 2.1.5 release itself, please consult the Release Notes.

The official sources for FreeBSD are available via anonymous FTP from: ftp.FreeBSD.org. Or via the WEB at: www.FreeBSD.org. And on CD-ROM from Walnut Creek CDROM: 

      Walnut Creek CDROM
      4041 Pike Lane, #D
      Concord CA, 94520 USA
      Phone: +1 510 674-0783
      Fax: +1 510 674-0821
      Tech Support: +1 510 603-1234
      Email: info@cdrom.com
      WWW: http://www.cdrom.com

Additionally, FreeBSD is available via anonymous FTP from the following mirror sites. If you choose to obtain FreeBSD via anonymous FTP, please try to use a site near you:

Australia

In case of problems, please contact hostmaster@au.FreeBSD.org.

Brazil

In case of problems, please contact hostmaster@br.FreeBSD.org.

Canada

In case of problems, please contact hostmaster@ca.FreeBSD.org

Czech Republic

Estonia

In case of problems, please contact hostmaster@ee.FreeBSD.org.

Finland

In case of problems, please contact hostmaster@fi.FreeBSD.org.

France

Germany

In case of problems, please contact hostmaster@de.FreeBSD.org.

Hong Kong

Ireland

In case of problems, please contact hostmaster@ie.FreeBSD.org.

Israel

Japan

In case of problems, please contact hostmaster@jp.FreeBSD.org.

Korea

In case of problems, please contact hostmaster@kr.FreeBSD.org.

Netherlands

In case of problems, please contact hostmaster@nl.FreeBSD.org.

Poland

Portugal

Russia

In case of problems, please contact hostmaster@ru.FreeBSD.org.

South Africa

In case of problems, please contact hostmaster@za.FreeBSD.org.

Sweden

In case of problems, please contact the hostmaster@se.FreeBSD.org.

Taiwan

In case of problems, please contact hostmaster@tw.FreeBSD.org.

Thailand

USA

In case of problems, please contact hostmaster@FreeBSD.org.

UK

In case of problems, please contact hostmaster@uk.FreeBSD.org.

The latest versions of export-restricted code for FreeBSD (2.0C or later) (eBones and secure) are being made available at the following locations. If you are outside the U.S. or Canada, please get secure (DES) and eBones (Kerberos) from one of the following foreign distribution sites:

South Africa

Brazil

Finland

Release Home &footer; diff --git a/en/releases/2.2.2R/errata.sgml b/en/releases/2.2.2R/errata.sgml index 03c32742c4..646d7c1d40 100644 --- a/en/releases/2.2.2R/errata.sgml +++ b/en/releases/2.2.2R/errata.sgml @@ -1,79 +1,79 @@ - + %includes; ]> - + &header; 
 Last minute errata:
 -------------------
 o login as root produces "login_getclass: unknown class 'root'" on system console.
 
 Fix:  If you have the source distribution installed, simply
       cp /usr/src/etc/login.conf /etc
       otherwise, get it from the FreeBSD FTP site using this URL:
       ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/etc/login.conf
       instead.  Simply cd to /etc and then run fetch(1) with the provided URL.
 
 
 o sysconfig scrambles rc.conf if run again.
 
 Fix:  Get updated /usr/src from RELENG_2_2 branch and build
       /usr/src/release/sysinstall, copying the new binary to /stand.
 
       If you do not have enough space for src then you could also
       use the boot/fixit floppy combo from a later 2.2-YYMMDD-RELENG
       release to simply mount your root partition (using the Fixit
       option) and copy /stand/sysinstall from the floppy to /stand on
       your root fs.
 
 
 o Installation floppy does not boot at all - whereas the 2.2.1 floppy
   worked fine.  I get a "panic: double fault" right after it tries to
   change the root device to fd0c.
 
-Fix:  The problem is that you have 48MB of RAM and something very very
+Fix:  The problem is that you have 48MB of RAM and something very
       mysterious has happened to FreeBSD twixt 2.2.1 and 2.2.2 which makes
       it fail with just that exact memory size.  Given the popularity of
       16MB simms, it also explains why none of us have seen it since we
       typically have either 16MB, 32MB or 64MB of memory in our systems. :)
 
       We're working on finding and fixing this problem, but until then
       the following work-around is in effect for 48MB systems:
 
       1. Boot the 2.2.2 boot floppy and when it comes to the first menu which
          asks you whether or not you want to go into the kernel configuration
          editor, choose the "experts only" CLI mode option.  Now type:
 
 	      iosize npx0 32768
 	      visual
 	      < and do your visual kernel configuration as normal then exit>
 
          If you can get through to the installation, go to step 3.
 
       2. If the above does not work, physically remove all but 32MB of memory
          from your machine and then boot the boot floppy.  Unless your problem
          is totally weird and something we've not seen at all before, you
          should now be able to go on to step 3.
 
       3. Complete the installation and then boot off your hard disk.  This
          boot should work fine, since you are no longer using the memory
          filesystem that the installation uses and which seems to interact
          badly with these memory size issues to create the failure you saw.
 
          You will also want to boot with the -c flag at some point and
          say "iosize npx0 0" to get the full use of all your memory back
          since the old value of 32768 will have been saved to disk during
          the initial installation.  If you already plan on building a custom
          kernel, you can skip this step since the value will be reset anyway.

Release Home &footer; diff --git a/en/security/advisories.xml b/en/security/advisories.xml index 0f4427ac7c..c9851ed7f0 100644 --- a/en/security/advisories.xml +++ b/en/security/advisories.xml @@ -1,609 +1,609 @@ - + %includes; ]> - + &header;

Introduction

This web page is designed to assist both new and experienced users in the area of security for the FreeBSD Operating System. The FreeBSD Development team takes security very seriously and is constantly working on making the OS as secure as possible.

Here you will find additional information, or links to information, on how to protect your system against various types of outside attack, whom to contact if you find a security related bug, etc. There is also a section on the various ways that the systems programmer can become more security conscious so he or she is less likely to introduce security holes in the first place.

Table of Contents

The FreeBSD Security Officer

To better coordinate information exchange with others in the security community, FreeBSD has a focal point for security related communications: The FreeBSD security officer. The position is actually staffed by a team of dedicated security officers, their main tasks being to send out advisories when there are known security holes and to act on reports of possible security problems with FreeBSD.

If you need to contact someone from the FreeBSD team about a possible security bug, you should therefore please send mail to the Security Officer with a description of what you've found and the type of vulnerability it represents. The Security Officers also communicate with the various CERT and FIRST teams around the world, sharing information about possible vulnerabilities in FreeBSD or utilities commonly used by FreeBSD. The Security Officers are also active members of those organizations.

If you do need to contact the Security Officer about a particularly sensitive matter, please use their PGP key to encrypt your message before sending it.

FreeBSD Security Advisories

The FreeBSD Security Officers provide security advisories for the following releases of FreeBSD:

At this time, security advisories are being released for:

Older releases are not maintained and users are strongly encouraged to upgrade to one of the supported releases mentioned above.

Like all development efforts, security fixes are first brought into the FreeBSD-current branch. After a couple of days and some testing, the fix is retrofitted into the supported FreeBSD-stable branch(es) and an advisory then sent out.

Some statistics about advisories released during 2000:

Advisories are sent to the following FreeBSD mailing lists:

Advisories are always signed using the FreeBSD Security Officer PGP key and are archived, along with their associated patches, at our FTP CERT repository. At the time of this writing, the following advisories are currently available (note that this list may be a few days out of date - for the very latest advisories please check the FTP site):

FreeBSD Security Mailing Lists Information

If you are administering or using any number of FreeBSD systems, you should probably be subscribed to one or more of the following lists:

 freebsd-security                General security related discussion
 freebsd-security-notifications  Security notifications (moderated mailing list)
Send mail to majordomo@FreeBSD.ORG with 
      subscribe <listname>  [<optional address>]
in the body of the message in order to subscribe yourself. For example: 
 % echo "subscribe freebsd-security" | mail majordomo@FreeBSD.org
and if you would like to unsubscribe from a mailing list: 
 % echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org

Secure Programming Guidelines

A useful auditing tool is the its4 port, located in /usr/ports/security/its4/. This is an automated C code auditor which highlights potential trouble-spots in the code. It is a useful first-pass tool, but should not be relied upon as being authoritative, and a complete audit should include human examination of the entire code.

For more information on secure programming techniques and resources, see the How to Write Secure Code resource center.

FreeBSD Security Tips and Tricks

There are several steps one must take to secure a FreeBSD system, or in fact any Unix system:

There is also a FreeBSD Security How-To available which provides some advanced tips on how to improve security of your system. You can find it at http://www.FreeBSD.org/~jkb/howto.html.

Security is an ongoing process. Make sure you are following the latest developments in the security arena.

What to do when you detect a security compromise

Other Related Security Information

&footer diff --git a/en/security/security.sgml b/en/security/security.sgml index 0f4427ac7c..c9851ed7f0 100644 --- a/en/security/security.sgml +++ b/en/security/security.sgml @@ -1,609 +1,609 @@ - + %includes; ]> - + &header;

Introduction

This web page is designed to assist both new and experienced users in the area of security for the FreeBSD Operating System. The FreeBSD Development team takes security very seriously and is constantly working on making the OS as secure as possible.

Here you will find additional information, or links to information, on how to protect your system against various types of outside attack, whom to contact if you find a security related bug, etc. There is also a section on the various ways that the systems programmer can become more security conscious so he or she is less likely to introduce security holes in the first place.

Table of Contents

The FreeBSD Security Officer

To better coordinate information exchange with others in the security community, FreeBSD has a focal point for security related communications: The FreeBSD security officer. The position is actually staffed by a team of dedicated security officers, their main tasks being to send out advisories when there are known security holes and to act on reports of possible security problems with FreeBSD.

If you need to contact someone from the FreeBSD team about a possible security bug, you should therefore please send mail to the Security Officer with a description of what you've found and the type of vulnerability it represents. The Security Officers also communicate with the various CERT and FIRST teams around the world, sharing information about possible vulnerabilities in FreeBSD or utilities commonly used by FreeBSD. The Security Officers are also active members of those organizations.

If you do need to contact the Security Officer about a particularly sensitive matter, please use their PGP key to encrypt your message before sending it.

FreeBSD Security Advisories

The FreeBSD Security Officers provide security advisories for the following releases of FreeBSD:

At this time, security advisories are being released for:

Older releases are not maintained and users are strongly encouraged to upgrade to one of the supported releases mentioned above.

Like all development efforts, security fixes are first brought into the FreeBSD-current branch. After a couple of days and some testing, the fix is retrofitted into the supported FreeBSD-stable branch(es) and an advisory then sent out.

Some statistics about advisories released during 2000:

Advisories are sent to the following FreeBSD mailing lists:

Advisories are always signed using the FreeBSD Security Officer PGP key and are archived, along with their associated patches, at our FTP CERT repository. At the time of this writing, the following advisories are currently available (note that this list may be a few days out of date - for the very latest advisories please check the FTP site):

FreeBSD Security Mailing Lists Information

If you are administering or using any number of FreeBSD systems, you should probably be subscribed to one or more of the following lists:

 freebsd-security                General security related discussion
 freebsd-security-notifications  Security notifications (moderated mailing list)
Send mail to majordomo@FreeBSD.ORG with 
      subscribe <listname>  [<optional address>]
in the body of the message in order to subscribe yourself. For example: 
 % echo "subscribe freebsd-security" | mail majordomo@FreeBSD.org
and if you would like to unsubscribe from a mailing list: 
 % echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org

Secure Programming Guidelines

A useful auditing tool is the its4 port, located in /usr/ports/security/its4/. This is an automated C code auditor which highlights potential trouble-spots in the code. It is a useful first-pass tool, but should not be relied upon as being authoritative, and a complete audit should include human examination of the entire code.

For more information on secure programming techniques and resources, see the How to Write Secure Code resource center.

FreeBSD Security Tips and Tricks

There are several steps one must take to secure a FreeBSD system, or in fact any Unix system:

There is also a FreeBSD Security How-To available which provides some advanced tips on how to improve security of your system. You can find it at http://www.FreeBSD.org/~jkb/howto.html.

Security is an ongoing process. Make sure you are following the latest developments in the security arena.

What to do when you detect a security compromise

Other Related Security Information

&footer diff --git a/en/y2kbug.sgml b/en/y2kbug.sgml index 657dd525d4..e49eb83445 100644 --- a/en/y2kbug.sgml +++ b/en/y2kbug.sgml @@ -1,402 +1,402 @@ + %includes; ]> - + &header;

As management understanding of the Year 2000 problem (aka, "The Millennium Bug") increases, more and more companies are demanding official statements from the vendors of their hardware and software as to how their product will handle the year 2000 date rollover.

Organizations that use unix and unix like operating systems such as FreeBSD are already one step ahead of the problem. FreeBSD will properly maintain time long after year 2000 passes.

Background information

(This section based on the text from the Linux Y2K compliance page)

As with all Unix and Unixlike operating systems, time and dates in FreeBSD are represented internally as the number of seconds since the 1st of January 1970 (the Unix "epoch"). Currently, that figure is stored as a 32 bit integer, and will run out part way through 2038. By then we should (hopefully) be using a counter of 64 bits (or greater) which should be good until the end of the universe.

Note that the OS being Y2K compliant will not fix errant applications that are not Y2K compliant.

Note also that the OS expects to read the current date and time from the CMOS clock of your computer. Not all of these devices correctly handle the year 2000. You are advised to test each platform individually to ensure that your hardware clock behaves correctly when going from 1999 to 2000, and that it correctly interprets the year 2000 as a leap year.

What you can do

FreeBSD will continue to properly maintain time well into the next century. Third party applications, however, might not. Your best defense against year 2000 issues is a good offense. Listening to stories claiming the coming meltdown of the world as we know it are not the way to solve the millennium bug. Nor is waiting until the last minute. The FreeBSD Project recommends that your organization apply sound system administration principles as the millennium approaches.

There are tests that you can perform to see how your system will respond. Set your clock to a few minutes before midnight on New Year's Eve and watch the system time. Your system should display the year as 2000 and not 1900. If the year is displayed incorrectly, then you will have plenty of time to update your hardware. Operating your organizations information systems under their normal daily load with the clock set forward can provide valuable insight into your vulnerability to year 2000 issues.

Important: Do not do this on a live production system. You may confuse any applications you have which rely on dates (billing systems, backup regimes, and so on). Always conduct tests like this on development systems which can not affect any live data you may have.

FreeBSD Year 2000 Statement

"After extensive analysis and testing, we believe that FreeBSD is 100% Y2K compliant. In the unlikely event that something has been overlooked, we will do our best to fix it as soon as possible."

David Greenman
Principal Architect, The FreeBSD project

Fixed problems

The following Y2K problems have been identified and fixed in FreeBSD.

misc/1380
Several programs have a hardcoded 19%d in responses for the year. Affected programs include: yacc, ftpd, and make. [Fixed: yacc v1.2 1999/01/18; ftpd v1.7 1996/08/05; make v1.4 1996/10/06; fixes in FreeBSD-2.2 and above]
conf/1382
The sed script in /etc/rc.local that builds the host/kernel ID line for the message of the day relies on the year not going past 1999. [Fixed v1.21 1996/10/24; fixes in FreeBSD-2.2 and above]
misc/3465
The etc/namedb/make-localhost command generates the DNS serial number as YYMMDD. In the year 2000, this will be generated as 1YYMMDD. [Fixed v1.2 1997/08/11; fixes in FreeBSD-2.2.5 and above]
gnu/4930 and gnu/8321
groff tmac macros have hardcoded 19 for generating some dates. [Fixed: tmac.e v1.3 1998/12/06; doc-common v1.10 1999/01/19; fixes in FreeBSD-3.1 and above]
bin/9323
In its obsolescent form, touch doesn't treat the two digit year - year specification correctly. Years in the range 00-68 are treated + specification correctly. Years in the range 00-68 are treated as 1900-1968 instead of 2000-2068. [Fixed v1.7 1999/01/05; fixes in FreeBSD-3.1 and above]
xntpd/parse/util/dcfd.c
The leap year calculations for the number of days in a year, and the conversion of DCF77 time to seconds since the Epoch were wrong. These errors affected all years. [Fixed v1.6 1999/01/12; fixes in FreeBSD-3.1 and above]
tar/getdate.y
Function Convert() was hard-coded for two digit years in range 70-99. Now adjusted to allow two digit years for 1970-2069. The function does not allow for century non-leap years - y2k1 alert! [Fixed v1.4 1999/01/12; fixes in FreeBSD-3.1 and above]
fetch/http.c
The HTTP protocol includes an obsolete date format which uses a two-digit year. Previous versions of fetch would interpret all such dates in the 1900s; subsequent to this revision, the pivot described in RFC 2068 is employed, which causes two-digit years to be interpreted as always belonging to the current century unless they would be 50 or more years in the future. Since the HTTP servers which use this obsolete format are no longer widespread, this is not expected to have a significant impact. [Fixed v1.24 1999/01/15; fixes in FreeBSD-3.1 and above]
misc/9500
The `edithook' script in the CVSROOT directory uses a raw tm_year and will therefore display 01/01/100 for 2000-JAN-01. [Fixed v1.2 1999/01/17; not relevant to FreeBSD releases]
bin/9501
Several cvs contrib files are not Y2K compliant. The log.pl and sccs2rcs.csh scripts prepend `19' to the year resulting in a display of 19100 for 2000. The log_accum.pl script uses a two digit year in one place and in another place assumes that the tm_year is year within century rather than years since 1900. [Fixed: log.pl v1.2 1999/01/15; sccs2rcs.csh v1.3 1999/01/15; fixes in FreeBSD-3.1 and above]
bin/9502
The groff number register `yr' is assigned from a (struct tm).tm_year and therefore represents the number of years since 1900, not the year within the century (see definition in troff/input.cc). [Fixed, now set mod 100, troff/input.cc V1.2 1999/06/03; fixed in FreeBSD-3.3]
bin/9503
PicoBSD's simple_httpd uses a raw tm_year and will therefore display 01/01/100 for 2000-JAN-01. [Fixed v1.2 1999/01/16; fixes in FreeBSD-3.1 and above]
bin/9505
Adduser uses a raw tm_year and will therefore display 100/01/01 for 2000-JAN-01. [Fixed v1.42 1999/01/15; fixes in FreeBSD-3.1 and above]
bin/9506
Cron uses a raw tm_year and will therefore display 100 for 2000. [Fixed v1.7 1999/01/16; fixes in FreeBSD-3.1 and above]
bin/9507
tcpslice(8) uses a raw tm_year and will therefore display 100y01m01d... for 2000-JAN-01. For compatibility, use a two-digit year until 2000.[Fixed v1.8 1999/01/20; fixes in FreeBSD-3.1 and above]
bin/14472
Date command does not take thousand/hundred digits. [Fixed v1.31 1999/11/10]
misc/14511
Chpass has a problem using 00 for expiration year.
bin/15852 and gnu/16045 and bin/16207
Groff predefined \*(DT [\*(td] string has Y2K bug. [Fixed with import of version 1.15 2000/01/12]
bin/15872
at(1) has a problem with valid time specifications if tm_year is 100, reports `garbled time'.
misc/16238
KerberosIV install does not work properly because there is a hard-wired expiration date of 12/31/99 in the Kerberos source for the ticket granter. [Fixed v1.24 1999/09/19]

Problematic applications

ports/7681
TkDesk 1.0 uses a hardcoded 19 in the file listing window. A file with a date > 2000 is displayed with a year looking like "191xx" where xx is the last two numbers of the real date. This bug has been fixed in version 1.1. [Port updated 1998/10/10; fixes in FreeBSD-3.0 and above]
ports/9295
INN 1.7.2 suffers from 2 Y2K related problems. One occurs when pulling news (-f option to nntpget) and the other relates to the Expire header with relative dates past 2000. [Both INN ports upgraded to INN 2.2 1999/05/02; fixes in FreeBSD-3.2 and above]
ports/9298
Knews suffers from 2 Y2K related problems. One occurs during the generation of the NNTP NEWGROUPS command. The other occurs because knews doesn't think that 2000 is a leap year. Both are fixed in knews-1.0b.1. [Port updated 1999/01/07; fixes in FreeBSD-3.1 and above]
ports/9300
Nntp-t5 suffers from a Y2K problem during the generation of the NEWNEWS command. [Port patched 1999/01/05; fixes in FreeBSD-3.1 and above]
ports/11144
The tiff port has a hardcoded 19xx. While this is in the contrib section (for converting Sun rasterfile format to TIFF), and not installed by default, this should be patched. [Port patched 1999/04/18, followed by upgrade 1999/05/11; fixes in FreeBSD-3.2 and above]
ports/11145
The dgs port suffers from the same TIFF related problem as the tiff port. [contrib routine for converting Sun rasterfiles to TIFF] [Port patched 1999/04/18; fixes in FreeBSD-3.2 and above]
ports/13694
The slurp port has a problem generating a correctly formatted host file name when tm_year is greater than 100. [Port patched 1999/10/27; fixes in FreeBSD-3.3-STABLE and above]
ports/15477
wwwstat port has a hardcoded 19.
ports/15789
proftpd has a minor Y2K problem. [Port patched 1999/12/22]
ports/15820
sendfile has a problem not setting the atime and mtime properly for files sent after year 1999.
ports/15854
dclock uses localtime and in particular the references to tm_year do not take into account the year 2000. [Port patched 2000/01/04]
ports/15868
The reporting function of hylafax (xferstats) is not y2k compatible. [Port patched 2000/01/24]
ports/15926
A y2k bug in leafnode+ 2.9 considers incoming news articles with the (arguably bogus) Date: header like `Wed, 05 Jan 00 15:01:40 GMT' to be too old, so these incoming articles are dropped. [Fixed by upgrading port to version 2.10 2000/01/24]
ports/16062
Japanese e2ps port has hardcoded 19. [Port patched 2000/01/24]
ports/16073
nntp port 1.5.11.5 has Y2K related problems. [Port upgraded to version 1.5.12.2 2000/01/12]
ports/16167
This is a bug-fix release that corrects a y2k bug in INN 2.2.1 that will show up in the NEWNEWS and NEWGROUPS commands after 2000-01-01 00:00:00 when the date specified to the command is before 2000-01-01 00:00:00. [Port upgraded to version 2.2.2 2000/01/28]
NetHack 3.2.2 and earlier versions are not Y2K compliant (the score file used 2 digit years and will be corrupted if added to in the year 2000). [Port updated to version 3.2.3 2000/01/05]
Japanese mnews port has Y2K problems. [Port updated to version 1.22 1999/12/26]

More information

If you have further questions about FreeBSD's year 2000 compliance, or you have discovered an application running under FreeBSD that is not Y2K compliant, please contact the project at freebsd-bugs@FreeBSD.ORG.

&footer; diff --git a/share/sgml/advisories.xml b/share/sgml/advisories.xml index 0f4427ac7c..c9851ed7f0 100644 --- a/share/sgml/advisories.xml +++ b/share/sgml/advisories.xml @@ -1,609 +1,609 @@ - + %includes; ]> - + &header;

Introduction

This web page is designed to assist both new and experienced users in the area of security for the FreeBSD Operating System. The FreeBSD Development team takes security very seriously and is constantly working on making the OS as secure as possible.

Here you will find additional information, or links to information, on how to protect your system against various types of outside attack, whom to contact if you find a security related bug, etc. There is also a section on the various ways that the systems programmer can become more security conscious so he or she is less likely to introduce security holes in the first place.

Table of Contents

The FreeBSD Security Officer

To better coordinate information exchange with others in the security community, FreeBSD has a focal point for security related communications: The FreeBSD security officer. The position is actually staffed by a team of dedicated security officers, their main tasks being to send out advisories when there are known security holes and to act on reports of possible security problems with FreeBSD.

If you need to contact someone from the FreeBSD team about a possible security bug, you should therefore please send mail to the Security Officer with a description of what you've found and the type of vulnerability it represents. The Security Officers also communicate with the various CERT and FIRST teams around the world, sharing information about possible vulnerabilities in FreeBSD or utilities commonly used by FreeBSD. The Security Officers are also active members of those organizations.

If you do need to contact the Security Officer about a particularly sensitive matter, please use their PGP key to encrypt your message before sending it.

FreeBSD Security Advisories

The FreeBSD Security Officers provide security advisories for the following releases of FreeBSD:

At this time, security advisories are being released for:

Older releases are not maintained and users are strongly encouraged to upgrade to one of the supported releases mentioned above.

Like all development efforts, security fixes are first brought into the FreeBSD-current branch. After a couple of days and some testing, the fix is retrofitted into the supported FreeBSD-stable branch(es) and an advisory then sent out.

Some statistics about advisories released during 2000:

Advisories are sent to the following FreeBSD mailing lists:

Advisories are always signed using the FreeBSD Security Officer PGP key and are archived, along with their associated patches, at our FTP CERT repository. At the time of this writing, the following advisories are currently available (note that this list may be a few days out of date - for the very latest advisories please check the FTP site):

FreeBSD Security Mailing Lists Information

If you are administering or using any number of FreeBSD systems, you should probably be subscribed to one or more of the following lists:

 freebsd-security                General security related discussion
 freebsd-security-notifications  Security notifications (moderated mailing list)
Send mail to majordomo@FreeBSD.ORG with 
      subscribe <listname>  [<optional address>]
in the body of the message in order to subscribe yourself. For example: 
 % echo "subscribe freebsd-security" | mail majordomo@FreeBSD.org
and if you would like to unsubscribe from a mailing list: 
 % echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org

Secure Programming Guidelines

A useful auditing tool is the its4 port, located in /usr/ports/security/its4/. This is an automated C code auditor which highlights potential trouble-spots in the code. It is a useful first-pass tool, but should not be relied upon as being authoritative, and a complete audit should include human examination of the entire code.

For more information on secure programming techniques and resources, see the How to Write Secure Code resource center.

FreeBSD Security Tips and Tricks

There are several steps one must take to secure a FreeBSD system, or in fact any Unix system:

There is also a FreeBSD Security How-To available which provides some advanced tips on how to improve security of your system. You can find it at http://www.FreeBSD.org/~jkb/howto.html.

Security is an ongoing process. Make sure you are following the latest developments in the security arena.

What to do when you detect a security compromise

Other Related Security Information

&footer