Re: NIS client performance seems very poor under network load
"Brandon D. Valentine" wrote: > do intend to work on this. At the moment I sit daily in front of an SGI > Indigo2 running IRIX because it's better than Linux and integrates quite > well with our environment. I really want a FreeBSD workstation on my > desk, so I'll likely end up writing the patches just so I can get that > FreeBSD workstation integrated. But, no promises on a timeframe so if > someone else wants to get started now, then by all means charge right > ahead with it. I'm not sure why you aren't using FreeBSD here. Myself, I sit in front of FreeBSD on an Athlon 1200 MHz box complete with dual head 19" monitors running XFree86 4.1.0 in xinerama mode so my X server is stretched across the two displays. This is good in that I can keep the NT world on one display (Windows Terminal Server via either Citrix ICA, rdesktop RDP or X11 but most will use RDP due to cheaper licencing) and I can even switch one of my monitors to its BNC input to use my aging Sparc 10 (which I dont do anymore since its hard disk died). I am a NIS client but most of the users who use my machine have local home directories but I am not averse to having /home/user being a sym link to /net/expensive-server/export/home/user because I do run amd solely to provide /net automounting. I get backed up by HP OpenView OmniBack (as discussed elsewhere on FreeBSD lists). I even run the Matrox drivers for my G400 dual head card. The main thing that's bugging me right now is the NIS client performance but it appears that no-one on these lists runs a FreeBSD NIS client (or they do but dont stress their network). I see that overnight when there is lots of network traffic due to backups that my periodically run jobs fail to run because NIS cant get stuff from the server. The NIS server does coordinate a lot of the backups and is probably under network load itself at the time. Most people will say something along the lines of "crummy network", "crummy NIS server" or something like that to which I'd have to say "Why dont other people on my network have this problem ?". Yes these other people are NIS clients. I can see this poor performance in just trying to start an xterm under network load and can create 24 -> 32 second delays with a test as follows: % cd /usr/ports/distfiles/xc % ftp nis-server(my home there is local to that box) ftp> prompt ftp> mput *.tgz Just after pressing enter on the above line, start two xterms. Now thats quite a bit of data even when myself and the server are on 100Mbit/s full-duplex switched ethernet links. -rw-r- 1 user group 237098 Oct 3 17:55 X336contrib.tgz -rw-r- 1 user group17388037 Oct 3 17:55 X336src-1.tgz -rw-r- 1 user group14834083 Oct 3 17:55 X336src-2.tgz -rw-r- 1 user group21994230 Oct 3 17:55 X401src-1.tgz -rw-r- 1 user group18971060 Oct 3 17:55 X401src-2.tgz -rw-r- 1 user group23880758 Oct 3 17:56 X402src-1.tgz -rw-r- 1 user group18918369 Oct 3 17:56 X402src-2.tgz -rw-r- 1 user group24990773 Oct 3 17:56 X410src-1.tgz -rw-r- 1 user group22496001 Oct 3 17:56 X410src-2.tgz The transfers go well with the larger files achieving between 5.14 and 7.78 MB/s however the xterms dont appear until after the whole FTP mput is finished. i.e. the timing was: T+0I press enter on the "mput *.tgz" FTP command T+3s I launch xterm 1 from another xterm T+5s I launch xterm 2 from another xterm T+25s FTP mput completes T+27s xterm 1 appears on my display T+37s xterm 2 appears on my display Now xterm 1 has the message "yp_first: clnt_call: RPC: Timed out" as its first line and xterm 2 has two of these messages. So I'd like to do a little bit of investigation and was wonderring if other people have some insight as to where to look. This is not a short term problem and has been present across many months of -CURRENT (last build 19th September 2001 and typically built monthly) ever since I became a NIS client about 18 to 24 months ago. Further info: The nis-server runs HP-UX 10.20. The network is expensive Cisco switched ethernet with everything tied down to 100 MBit full-duplex at all ends except my FreeBSD box which is autonegotiating its "3Com 3c905B-TX Fast Etherlink XL" card simply because I have the line ifconfig_xl0="DHCP" in my /etc/rc.conf and I dont know how to set media options with ifconfig when DHCPing (anyone ??). -- Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Edinburgh PO Box 1500 Edinburgh South Australia 5111 IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete
Re: ACPI: problem with fdc resource allocation
Mike Smith wrote:
> This just isn't going to work. The _CRS data stream stops at byte 0x17,
> and these extra items are simply mis-aimed.
>
> The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie.
> this is a BIOS bug, and should be reported to the vendor. (It should
> also have failed the Microsoft ACPI validation suite...)
>
> The correct action should probably be to silently discard the write
> operations outside of a defined buffer, and return Zeroes or Ones for a
> read outside a buffer.
Do you have a patch to test this approach? While I understand that the best way to
resolve the problem is to convince vendors to fix their ACPI implementations, but
obviously this isn't going to happen any time soon, so appropriate workarround is
really a must.
-Maxim
> > Hi, I've just made a workaround for this. Intel folks, could you review
> > it as always?
> >
> > > The problem is here, right?
> > > > can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT
> > >
> > > I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some
> > > problems (not sure in BIOS or ACPICA yet). I could reproduce the problem
> > > which you reported. Trace attached in this mail.
> > [snip]
> > > dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer si
> > ze 192 (bits)
> > > PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8)
> > > Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIM
> > IT
> >
> > This method is like this;
> > Method(_CRS) {
> > Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
> > 0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
> > 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0
> > })
> > CreateByteField(BUF0, 0x2, IOLO)
> > CreateByteField(BUF0, 0x3, IOHI)
> > CreateByteField(BUF0, 0x4, IORL)
> > CreateByteField(BUF0, 0x5, IORH)
> > CreateByteField(BUF0, 0x19, IRQL)
> > CreateByteField(BUF0, 0x1c, DMAV)
> > Return(BUF0)
> > }
> >
> > The problem is that this AML is trying to create a field at exceeded
> > position (0x19) of the Buffer (size is 0x18).
> > I couldn't find how AML interprepter treat this in ACPI Spec. so I'm
> > not sure wether AWRDACPI violates the Spec. or ACPICA can have a workaround
> > for this.
> > Anyway, I made a patch to reallocate a large enough buffer for the
> > requested operation.
> >
> > Thanks
> >
> > Index: dsopcode.c
> > ===
> > RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsopcode.c,v
> > retrieving revision 1.1.1.10
> > diff -u -r1.1.1.10 dsopcode.c
> > --- dsopcode.c7 Sep 2001 01:22:24 - 1.1.1.10
> > +++ dsopcode.c1 Oct 2001 18:58:41 -
> > @@ -615,11 +615,24 @@
> > if ((BitOffset + BitCount) >
> > (8 * (UINT32) SrcDesc->Buffer.Length))
> > {
> > +UINT32 Length;
> > +UINT8 *Pointer;
> > +
> > ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
> > "Field size %d exceeds Buffer size %d (bits)\n",
> > BitOffset + BitCount, 8 * (UINT32) SrcDesc->Buffer.Length))
> > ;
> > -Status = AE_AML_BUFFER_LIMIT;
> > -goto Cleanup;
> > +Length = ((BitOffset + BitCount) / 8) +
> > + (((BitOffset + BitCount) % 8) ? 1 : 0);
> > +Pointer = ACPI_MEM_CALLOCATE (Length);
> > +if (!Pointer)
> > +{
> > +Status = AE_NO_MEMORY;
> > +goto Cleanup;
> > +}
> > +MEMCPY (Pointer, SrcDesc->Buffer.Pointer, SrcDesc->Buffer.Length
> > );
> > +ACPI_MEM_FREE (SrcDesc->Buffer.Pointer);
> > +SrcDesc->Buffer.Pointer = Pointer;
> > +SrcDesc->Buffer.Length = Length;
> > }
> >
> >
>
> --
> ... every activity meets with opposition, everyone who acts has his
> rivals and unfortunately opponents also. But not because people want
> to be opponents, rather because the tasks and relationships force
> people to take different points of view. [Dr. Fritz Todt]
>V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
newcard options and WL100
Hi Warner, I hope you can point me in the right direction or directly answer the question I have. I'm an active -CURRENT user and have aquired a Compaq WL100 wireless nic which does not work with the 'NEWCARD' options defined. In order to get my 3Com card to work, I need these options since this card is a 32bit cardbus card. Do you know what the planns are to sync the NEWCARD code with the 'old' code so that my (and probably a lot more) card(s) do work ? If not, could you give me a lead to where to look for this info myself? With regards, Stephan -- Stephan van Beerschoten [SVB21-RIPE] [EMAIL PROTECTED] PGP fingerprint: 4557 9761 B212 FB4C 778D 3529 C42A 2D27 "To err is human, to forgive is Not Company Policy" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/dev/cuaa broken ?
Hello! After upgrade to 3.5 to 4.3-stable we encoutered a problem with our custom device connected to com-port. The device accepts command strings and returns strings in response, but under 4.3 it strangely does not respond to commands that are longer than 15 bytes ( 16 with \r). The device is controlled by a code, which, if stripped to functional minimum is as such: open F, "+< /dev/cuaa0" or die "Cannot:$!\n"; system "/bin/stty -f /dev/cuaa0 gfmt1:ispeed=19200:ospeed=19200 cstopb"; print F "123\r";# <- works under both 3.5 and 4.3 # print F "1234567890123456\r" # <- doesn't work under 4.3 print "|$_|\n" while ; close F; One more strange effect is, that under cu(1) it works. That makes us assume that the programming technique used into our program is inappropriate - but it seems pretty straightforward and we are just clueless about what implicit 16-byte buffers might be involved here. My suspicion is that it's the device driver bug, but unfortunately we cannot afford tracking the exact commit that caused the malfunction. Any help will be appreciated - change to the code, or to the kernel variables, or whatever. Please help. -- Sincerely, Dmitry --- www.karasik.eu.org --- Life ain't fair, but the root password helps. - BOFH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current install failure
I tried to install current snapshot as of October 2, 2001 from current.jp.FreeBSD.org, but it seems to fail at sysinstall.c:installFilesystems(). The function installFilesystems() calls MakeDevChunk() of lib/libdisk/create_chunk.c, which then calls mknod(2) via MakeDev(). The error message I see come from MakeDev() which, after mknod(2) failure, says: mknod of /dev/rad0a1b returned failure status! Typing `mount' from fixit shell, the install kernel of the Octover 2nd's snapshot has devfs enabled. I could start installation with the snapshot of September 11, with which devfs seems to be disabled (I do not see "devfs on /dev (devfs, local)" by typing `mount' on the fixit shell). Is there any way to install current with recent snapshots' install floppies? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Staroffice6.0 Linux beta with FreeBSD
While Openoffice for BSD is still milestones away from compiling, I tried to port the linux version of SO6.0 beta to FreeBSD. I got it extracted, and could run setup.bin, which fails miserably: > 79358 setup.bin RET read 4096/0x1000 > 79358 setup.bin CALL linux_mmap(0xbfbfcfac) > 79358 setup.bin RET linux_mmap 697401344/0x29918000 > 79358 setup.bin CALL mprotect(0x29932000,0x50ec,0) > 79358 setup.bin RET mprotect 0 > 79358 setup.bin CALL linux_mmap(0xbfbfcfac) > 79358 setup.bin RET linux_mmap 697507840/0x29932000 > 79358 setup.bin CALL linux_mmap(0xbfbfcfac) > 79358 setup.bin RET linux_mmap 697528320/0x29937000 > 79358 setup.bin CALL close(0x6) > 79358 setup.bin RET close 0 > 79358 setup.bin PSIG SIGSEGV SIG_DFL > 79358 setup.bin NAMI "setup.bin.core" A full linux_kdump output is available. If someone knows more about this I'd be happy. BTW: This is CURRENT from today with a "old" linux base installed. Martin Blapp, [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: 57E 7CCD 2769 E7AC C5FA DF2C 19C6 DCD1 1B3A EC9C -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Different host behaviour
On Tue, Oct 02, 2001 at 09:23:50PM +0200, Riccardo Torrini wrote: > Different behaviour from 4.4 to 5.0 of host command. Why? > Yes, I got finally delegation for reverse (with RFC 2317). > Yes, my -CURRENT is really old, but I'm reading this list... ;) That's your problem. You see that this has been fixed at least since a month: ticso@cicely8> host 217.58.169.99 99.169.58.217.IN-ADDR.ARPA is a nickname for 99.96-28.169.58.217.IN-ADDR.ARPA ticso@cicely8> uname -v FreeBSD 5.0-CURRENT #2: Fri Aug 3 15:05:53 CEST 2001 [EMAIL PROTECTED]:/net/10.1.5.7/var/d9/src-2001-07-04/src/sys/i386/compile/CICELY8 ticso@cicely9> host 217.58.169.99 99.169.58.217.IN-ADDR.ARPA is a nickname for 99.96-28.169.58.217.IN-ADDR.ARPA 99.96-28.169.58.217.IN-ADDR.ARPA domain name pointer gw-fi.esaote.com ticso@cicely9> uname -v FreeBSD 5.0-CURRENT #1: Tue Sep 11 11:27:34 CEST 2001 [EMAIL PROTECTED]:/var/d8/FreeBSD-2001-09-03-ev56/src/sys/alpha/compile/CICELY9 -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird PCI BIOS - long
> You lose. Until someone writes a fallback for machines that don't
> have the BIOS32 entry point for PCIBIOS, you are stuck.
>
> Warner
No I don't. I knew I will get bitten by putting my comments at the end
of the long message, but I did it nonetheless :(. Anyway, here is shorter
and hopefully more clear explanation:
When kernel boots, PCI BIOS call entry _is_ found, according to the
following log output:
bios32: Found BIOS32 Service Directory header at 0xc00fd800
bios32: Entry = 0xfd820 (c00fd820) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0xfd880+0x0
^^ Here
Hovewher, kernel fails to realize, that the call entry is here because
entry address is a pair of non-zero base (0xfd880) and zero offset.
The code in sys/i386/pci_cfgreg.c is checking only offset to be non-null
and ignores base altogether and as a result it mistakenly thinks that
PCI BIOS call entry is not available. I patched the kernel to check for
base + offset with the patch below and now pci_get_version is able to to
a bios32 call and is correctly reporting PCI BIOS 2.10 present.
Unfortunately, that is the only good result caused by the patch, as
kernel freezes shortly after any key has been pressed on the console :(
Patch also changes pci_cfgintr to print out the PCI BIOS version
returned from pcibios_get_version and here are relevant lines from the
boot -v output produced by the modified kernel:
pcard0: on pcic0
pci_cfgintr: using BIOS 2.10 for interrupt routing
^^^
pci_cfgintr_virgin: using routable PCI-only interrupt 11
pci_cfgintr: ROUTE_INTERRUPT failed.
pcic1: mem 0x20821000-0x20821fff at device 2.1
on pci0
pci_cfgintr: using BIOS 2.10 for interrupt routing
pci_cfgintr_virgin: using routable PCI-only interrupt 11
pci_cfgintr: ROUTE_INTERRUPT failed.
pcic1: No PCI interrupt routed, trying ISA.
pcic1: Polling mode
pcic1: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][CSC
parallel isa irq]
The patch is here:
Index: pci_cfgreg.c
===
RCS file: /usr/ncvs/src/sys/i386/pci/pci_cfgreg.c,v
retrieving revision 1.80
diff -u -r1.80 pci_cfgreg.c
--- pci_cfgreg.c28 Aug 2001 16:35:01 - 1.80
+++ pci_cfgreg.c2 Oct 2001 19:10:07 -
@@ -94,7 +94,7 @@
{
struct bios_regs args;
-if (PCIbios.entry == 0) {
+if (BIOS_VADDRTOPADDR(PCIbios.ventry) == 0) {
PRVERB(("pcibios: No call entry point\n"));
return (0);
}
@@ -244,7 +244,12 @@
"pci_cfgintr: BIOS %x.%02x doesn't support interrupt routing\n",
(v & 0xff00) >> 8, v & 0xff));
return (255);
+} else {
+ PRVERB((
+ "pci_cfgintr: using BIOS %x.%02x for interrupt routing\n",
+ (v & 0xff00) >> 8, v & 0xff));
}
+
if ((bus < 0) || (bus > 255) || (device < 0) || (device > 255) ||
(pin < 1) || (pin > 4))
return(255);
@@ -496,7 +501,7 @@
{
u_int16_t v = 0;
-if (PCIbios.entry != 0 && enable_pcibios) {
+if (BIOS_VADDRTOPADDR(PCIbios.ventry) != 0 && enable_pcibios) {
v = pcibios_get_version();
if (v > 0)
printf("pcibios: BIOS version %x.%02x\n", (v & 0xff00) >> 8,
E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]>
Date: 03-Oct-2001
Time: 10:55:24
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Different host behaviour
On 03-Oct-2001 (14:14:57/GMT) Bernd Walter wrote: >> Yes, my -CURRENT is really old, but I'm reading this list... ;) > That's your problem. Pilot error :-( Ok, sorry for that. > You see that this has been fixed at least since a month: > ticso@cicely9> uname -v > FreeBSD 5.0-CURRENT #1: Tue Sep 11 11:27:34 CEST 2001 Have you a suggestion of a date of a _not_too_much_ dangerous -current to cvs? I really want to build world again, so I can avoid this really stupid questions... 0:-) Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> All these "solutions" assume that everyone is wired up with IP > connectivity. The original questions was "who uses UUCP?" Correct. > One answer is: "those without IP connectivity." Do you mean 'full-time IP connectivity', because if you can setup a UUCP connection, you can just as easily setup a PPP connection over the same medium, giving you IP connectivity. > Part of the problem > here I suspect is that the people who develop and maintain FreeBSD > live a life where a T-3 into your livingroom is just something you > take for granted. Not so. > UUCP has many valid uses. Even today. If you don't understand the > software, that's fine with me. Just don't use your ignorance as > an excuse to dike the software out. Or more precisely, admit > you want to rip the code out because you don't understand what > it is, rather than making up specious excuses for it's removal. Cheap shot. Some of us who favor diking out UUCP were heavily involved with the Internet back when it was essntially Usenet over UUCP. :) I favor diking it out because there are in almost all cases (but not necessarily *ALL* cases) a better solution that exists. Because of this, I don't believe that UUCP is a mainstream solution, and therefore doesn't belong in the mainstream release. It *is* still available as an add-on port, so those who need it can still get it, but it doesn't clutter up the regular distributions. Finally, the security issues make it a non-starter to keep in the default distribution. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current install failure
As you've already noticed, sysinstall basically tries to create the device nodes it needs under the old assumption that /dev will be mostly empty. Now that devfs is the default, phk needs to update libdisk so that it doesn't attempt to make the device nodes in this way. Fortunately, the person who wrote libdisk is also the same person who made devfs the default, so this ball is very clearly in his court. :-) - Jordan > I tried to install current snapshot as of October 2, 2001 from > current.jp.FreeBSD.org, but it seems to fail at > sysinstall.c:installFilesystems(). > > The function installFilesystems() calls MakeDevChunk() of > lib/libdisk/create_chunk.c, which then calls mknod(2) via > MakeDev(). The error message I see come from MakeDev() which, after > mknod(2) failure, says: > mknod of /dev/rad0a1b returned failure status! > Typing `mount' from fixit shell, the install kernel of the Octover > 2nd's snapshot has devfs enabled. > I could start installation with the snapshot of September 11, with > which devfs seems to be disabled (I do not see "devfs on /dev (devfs, > local)" by typing `mount' on the fixit shell). > > Is there any way to install current with recent snapshots' install floppies? > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current install failure
* Jordan Hubbard <[EMAIL PROTECTED]> [011003 15:33] wrote: > As you've already noticed, sysinstall basically tries to create the > device nodes it needs under the old assumption that /dev will be > mostly empty. Now that devfs is the default, phk needs to update > libdisk so that it doesn't attempt to make the device nodes in this > way. Fortunately, the person who wrote libdisk is also the same > person who made devfs the default, so this ball is very clearly in his > court. :-) Just reminding you all that phk's suggested way of finding this information out is to test for the presense of the devfs sysctl as done in vinum. If libdisk does it a different way, then vinum should be updated. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current install failure
sysinstall, by design, knows very little about devices. It uses libdisk(3) as the abstraction for dealing with all disks in particular. > * Jordan Hubbard <[EMAIL PROTECTED]> [011003 15:33] wrote: > > As you've already noticed, sysinstall basically tries to create the > > device nodes it needs under the old assumption that /dev will be > > mostly empty. Now that devfs is the default, phk needs to update > > libdisk so that it doesn't attempt to make the device nodes in this > > way. Fortunately, the person who wrote libdisk is also the same > > person who made devfs the default, so this ball is very clearly in his > > court. :-) > > Just reminding you all that phk's suggested way of finding this > information out is to test for the presense of the devfs sysctl as > done in vinum. > > If libdisk does it a different way, then vinum should be updated. > > -- > -Alfred Perlstein [[EMAIL PROTECTED]] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current install failure
> > * Jordan Hubbard <[EMAIL PROTECTED]> [011003 15:33] wrote: > > > As you've already noticed, sysinstall basically tries to create the > > > device nodes it needs under the old assumption that /dev will be > > > mostly empty. Now that devfs is the default, phk needs to update > > > libdisk so that it doesn't attempt to make the device nodes in this > > > way. Fortunately, the person who wrote libdisk is also the same > > > person who made devfs the default, so this ball is very clearly in his > > > court. :-) > > > > Just reminding you all that phk's suggested way of finding this > > information out is to test for the presense of the devfs sysctl as > > done in vinum. > > > > If libdisk does it a different way, then vinum should be updated. >--^^^ * Jordan Hubbard <[EMAIL PROTECTED]> [011003 15:51] wrote: > sysinstall, by design, knows very little about devices. It uses > libdisk(3) as the abstraction for dealing with all disks in > particular. You just said the same thing that I did except you did this... *makes up/down hand waving motion* :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current install failure
Well, since I don't own libdisk(3) and had no idea why you'd be addressing this to me unless you were still confused, I presumed you were confused. In any case, you need to be talking to phk about this. - Jordan From: Alfred Perlstein <[EMAIL PROTECTED]> Subject: Re: current install failure Date: Wed, 3 Oct 2001 16:12:21 -0500 > > > * Jordan Hubbard <[EMAIL PROTECTED]> [011003 15:33] wrote: > > > > As you've already noticed, sysinstall basically tries to create the > > > > device nodes it needs under the old assumption that /dev will be > > > > mostly empty. Now that devfs is the default, phk needs to update > > > > libdisk so that it doesn't attempt to make the device nodes in this > > > > way. Fortunately, the person who wrote libdisk is also the same > > > > person who made devfs the default, so this ball is very clearly in his > > > > court. :-) > > > > > > Just reminding you all that phk's suggested way of finding this > > > information out is to test for the presense of the devfs sysctl as > > > done in vinum. > > > > > > If libdisk does it a different way, then vinum should be updated. > > >--^^^ > > * Jordan Hubbard <[EMAIL PROTECTED]> [011003 15:51] wrote: > > sysinstall, by design, knows very little about devices. It uses > > libdisk(3) as the abstraction for dealing with all disks in > > particular. > > > You just said the same thing that I did except you did this... > > *makes up/down hand waving motion* > > > :-) > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Staroffice6.0 Linux beta with FreeBSD
On Wed, Oct 03, 2001 at 03:58:06PM +0200, Martin Blapp wrote: > > > 79358 setup.bin RET close 0 > > 79358 setup.bin PSIG SIGSEGV SIG_DFL > > 79358 setup.bin NAMI "setup.bin.core" > > > BTW: This is CURRENT from today with a "old" linux base installed. What if you try it with linux_base-7? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NIS client performance seems very poor under network load
Andrew Gallatin wrote: > > Thyer, Matthew writes: > > > > Now xterm 1 has the message "yp_first: clnt_call: RPC: Timed out" > > as its first line and xterm 2 has two of these messages. > The problem is that there is no global caching of NIS maps. Each app > maintains its own cache.. Since these are libc functions being used (gethostbyname, gethostbyaddr, getpwent etc etc) it is under the control of the operating system to do such caching and if most other operating systems do cache we are not likely to see many apps caching themselves. So the answer is a name service caching daemon ala nscd on Solaris. That's my preferred option as we still have control and can invalidate cache entries (nscd -i passwd) if required. The Solaris nscd is quite configurable.. see /etc/nscd.conf from Solaris 7: # # Copyright (c) 1994 by Sun Microsystems, Inc. # All rights reserved. # #ident "@(#)nscd.conf 1.3 96/10/09 SMI" # # # Currently supported cache names: passwd, group, hosts # # logfile /var/adm/nscd.log # enable-cachehosts no debug-level 0 positive-time-to-live passwd 600 negative-time-to-live passwd 5 suggested-size passwd 211 keep-hot-count passwd 20 old-data-ok passwd no check-files passwd yes positive-time-to-live group 3600 negative-time-to-live group 5 suggested-size group 211 keep-hot-count group 20 old-data-ok group no check-files group yes positive-time-to-live hosts 3600 negative-time-to-live hosts 5 suggested-size hosts 211 keep-hot-count hosts 20 old-data-ok hosts no check-files hosts yes Other options are to follow IRIX and have "nsd" and nsadmin to control it but I think following Sun would be more popular. -- Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Edinburgh PO Box 1500 Edinburgh South Australia 5111 IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lpd: Host name for your address (fe80:....%xl0) unknown
At 1:52 AM +0900 10/3/01, Hajimu UMEMOTO wrote: > > On Tue, 2 Oct 2001 12:30:33 -0400 > > Garance A Drosihn <[EMAIL PROTECTED]> said: >drosih> The print queue for 'lp' on oink refers to a remote machine that >drosih> is named neutron. That hostname maps to an IPv6 address. Thus, >drosih> lpq/lpr/lprm have no choice on how to connect to that remote host. >drosih> They use the IPv6 address. (note, for instance, that your 'ping6' >drosih> knows about neutron via IPv6, not IPv4). So, the print client >drosih> connects to the print server via IPv6. When the print client >drosih> connects to the print server, the print server looks up the IPv6 >drosih> address of the *client*, because the client made an IPv6 connection >drosih> to the server. Again, this has nothing to do with 'lpd -4' on the >drosih> client. The print server apparently can not find a hostname to >drosih> match the IPv6 address of the client, so it returns the first error >drosih> message, listing the IPv6 address of the client. > >No, a client does query RR for IPv6 and A RR for IPv4. If >RR is found, a client tries to connect using IPv6, 1st. However, lpd >accepts only IPv4 connection, in this case. Then, if A RR is found, a >client falls down and tries to connect using IPv4. So, a client never >connects using IPv6 to an IPv4 only listening server. Let me see if I have everything figured out now. If I understand what Alex has said, 1) on the print client, lpd is started with 'lpd -4' 2) he has not said how lpd is started on the print server. 3) because the print server came back with the error of "Host name for your address (fe80::250:baff:fed4:a512%xl0) unknown" I assume the print server, in this case, was NOT running with 'lpd -4'. Thus, the IPv6 connection DID work, but the print server could not come up with the hostname for the IPv6 address. 4) when he changed the print client to explicitly use the IPv4 address, the print server came back with an error message of "Host name for your address (192.168.0.19) unknown" This implies that when an IPv4 connection is made to the print server, the print server does it's reverse-lookup using the IPv4 address of the client. Since this works as expected, that again implies that the error message in part #3 does mean that the print server did get an IPv6 connection from the client. All this makes sense to me (I think...), although it looked wrong to Alex because he was seeing that IPv6 address in the message from the print server. Of course, I first need to find out how lpd was started on the print *server* (neutron), as opposed to the print client. #1, above, is irrelevant to how lpq on the client will connect to a remote machine. If 'lpd' is not started with -4 on his print server, then I think this all makes sense, and everything worked as I would expect it to. The only change to lpr which might be worth making is to add an 'rm4=' option to possible printcap settings for a queue, which would be like 'rm=' except that it would not even attempt to make an IPv6 connection. I'm not sure that's really necessary, but there might be situations where it would be useful. It might be that a particular hostname does have an IPv6 address, for instance, but for some reason it would be better to make an IPv4 connection to it. If people think this would be useful, I could add it, or something like it. Other than that one change, I think the code in lpr is working right, and no changes need to be made for the situation that Alex describes. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP kernel & burncd change..
Kris Kennaway wrote: > On Wed, Oct 03, 2001 at 01:56:11PM -0500, Jim Bryant wrote: > >>This may sounds strange, but as I don't actually recall seeing any actual changes to >burncd unless i missed something in my cvsup >>early this morning CDT... >> >>I just decided to give it another try before booting into the kernel built this >morning, and it seems that it was a "world" issue, >>and not a kernel issue, as I'm running the same kernel I reported below, but a world >from early THIS morning, and burncd DOES work now. >> > > There were changes recently..if your kernel is out of sync with your > world, you'll often get problems. > > Kris > actually, it was in sync, and it didn't work until i had made and installed a world and kernel from almost 24 hours ago, yet without rebooting. so i was using a kernel from around 48 hours ago and a world of about 24 hours ago before it would work. whatever it was was in the world stuff. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - "Religious fundamentalism is the biggest threat to international security that exists today." United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NIS client performance seems very poor under network load
Thyer, Matthew writes: > > Now xterm 1 has the message "yp_first: clnt_call: RPC: Timed out" > as its first line and xterm 2 has two of these messages. What's really fun is when you've got a rack or two of machines which are NIS clients and their switch blows out overnight. As soon as they regain network connectivity, they'll try to melt your mailserver down. Why? Because cron is going to send mail to root, bitching about "yp_first: clnt_call: RPC: Timed out" every 5 minutes (from atrun). For one rack of 1Us, that's an accumulation of at least 504msgs per hour (actually, its a lot more) > So I'd like to do a little bit of investigation and was wonderring > if other people have some insight as to where to look. The problem is that there is no global caching of NIS maps. Each app maintains its own cache.. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How to distinguish the SMP kernel and the UP kernel
Kazutaka YOKOTA wrote: > > Is there any way for the loadable module to detect if > the kernel is configured for SMP or UP? There is a global variable, "ncpu". Its name may have changed recently, so you will want to look at the SYSCTL() stuff in /sys/i386/i386 to be sure. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
All these "solutions" assume that everyone is wired up with IP connectivity. The original questions was "who uses UUCP?" One answer is: "those without IP connectivity." Part of the problem here I suspect is that the people who develop and maintain FreeBSD live a life where a T-3 into your livingroom is just something you take for granted. These folks need to spend some time living in the Northwest Territories or Central America (where IP connectivity is not just a luxury -- it's often not available) to really appreciate the ramifications of the decision to remove this software. UUCP has many valid uses. Even today. If you don't understand the software, that's fine with me. Just don't use your ignorance as an excuse to dike the software out. Or more precisely, admit you want to rip the code out because you don't understand what it is, rather than making up specious excuses for it's removal. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
reinstatement of MSDOSFS on boot floppy fails
sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt 1440 /R/stage/image.kern 8 fd1440 disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) super-block backups (for fsck -b #) at: 32 cpio: write error: No space left on device *** Error code 1 We're back where we started. The other stuff wasn't enough. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
Nate Williams wrote: > > POP and IMAP (I think) will lose all the envelope information, > > You've been listening to Terry too long. It's certainly not the case, > although I've decided to quit arguing with Terry, since it's an > excercise in futility. No matter what you say, he'll either change the > subject or simply overwhelm you with useless/unrelated material until > you simply abandon any hope of trying to give out useful information. Alternately, you could also read the fetchmail documentation as to why it is not an MTA. Really, Nate, you should have received enough SPAM by now to know that the "From:", "To:", and "Cc:" headers have no bearing on who the message is delivered to. FWIW, I have ensured that this message will be delivered twice (once on the list, once on) to both you an Julian, on the basis of envelope information, even though this information will not show up in headers. Feel free to read RFC 821, RFC 2505, and RFC 2554 (rationale), with specific attention to what information is maintained or lost when leaving an RFC 821 transport, and the disposition of the "Bcc:" header on client to server submissions. > See above. fetchmail + pop works fine. I've been get all of my envelope > information, and there is no worries. Perhaps you aren't using it in "multidrop" mode, for virtual domain delivery? Otherwise your ISP is tunneling envelope information in the headers (e.g. qmail's "Delivered-To:" -- which the RFC's require to be named "X-Delivered-To:", but of course DJB is not known for following RFC's -- or an "X-Frontier-To:" or "X-Envelope-To:"). Tell me, is your mail compliant with the non-disclosure of "Bcc:" recipients requirement? If fetchmail doesn't strip the tunneling headers (it doesn't), then the headers disclose "Bcc:"'ed recipients to anyone who chooses to look. Alternately, your ISP has set "single delivery mode", so that the "Received:" timestamp line contains the optional "for ", which is left out if there are multiple recipients for the mail message, since to do otherwise would require duplication. And doing that would disable the duplicate supression in the SMTP server software (hmmm... I will "Bcc:" you at the fully qualified domain name as well -- let us all know if you get 3 instead of just 2 copies of this email... also let us know if you have a "for [EMAIL PROTECTED]" "Received:" timestamp line). If the latter, you should count yourself lucky that the ISP does not do domain fan out on one machine, and POP3 maildrop hosting on another: fetchmail includes the mail server from which you are retrieving the mail, since fetchmail erroneously assumes that this machine is a designated MX for your domain. If you are using tunneled information, you should count yourself luck that your ISP does the header insertion prior to other insertion, since fetchmail will blindly deliver to the first header it deems to be deliverable, rather than priority sorting which header it uses based on confidence. > For 'fetching' email, fetchmail is a very good solution. However, there > is also another fairly trivial solution that works well, *IF* you have a > static IP address. > > ETRN also is a good 'fetch' mechanism, if your ISP sets up MX records > for you. When you come up, you simply telnet into your ISP's mail > server, then type 'ETRN foobar.com', and it'll dump all your email to > the IP address of your static configuration. > > However, this won't work for roving users. Yeah, for that there's "ATRN", which is really pretty dumb, since we could have just changed the semantics of "ETRN" in the presence of authentication. Too bad there are no public implementations of "ATRN"; the only implementations I've heard of are the one at Qualcomm, and the one that Whistle did -- SURPRISE! That's where Julian and I worked! Alternately, of course, there's UUCP... pull methods frequently work much better than triggered push mechansims. PS: I'm surprised you didn't mention the "finger" or the "PPP linkup script" methods. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> > > POP and IMAP (I think) will lose all the envelope information, > > > > You've been listening to Terry too long. It's certainly not the case, > > although I've decided to quit arguing with Terry, since it's an > > excercise in futility. No matter what you say, he'll either change the > > subject or simply overwhelm you with useless/unrelated material until > > you simply abandon any hope of trying to give out useful information. > > > See above. fetchmail + pop works fine. I've been get all of my envelope > > information, and there is no worries. > > Perhaps you aren't using it in "multidrop" mode, for virtual > domain delivery? That's correct. I'm not, which is something POP was never intended on doing. (However, in this case, I am my own ISP, since I have a full-time connection with my own mailserver and domain.) I'm using fetchmail + pop to fetch my already delivered email so that I can also retrieve email securely when on business trips. For single users, this works great. > Tell me, is your mail compliant with the non-disclosure of "Bcc:" > recipients requirement? If fetchmail doesn't strip the tunneling > headers (it doesn't), then the headers disclose "Bcc:"'ed > recipients to anyone who chooses to look. It sure is, because it's the responsibility of the mail sending program to handle this. Fetchmail is a mail retrieval program, so it's only job is to fetch the mail that is already delivered to me. > PS: I'm surprised you didn't mention the "finger" or the "PPP > linkup script" methods. Finger is an abomination, and PPP linkup scripts are really only useful for certain kinds of accounts. When I'm away on business, why dialin when I have a perfectly good internet connection that doesn't use PPP? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP kernel & burncd change..
This may sounds strange, but as I don't actually recall seeing any actual changes to burncd unless i missed something in my cvsup early this morning CDT... I just decided to give it another try before booting into the kernel built this morning, and it seems that it was a "world" issue, and not a kernel issue, as I'm running the same kernel I reported below, but a world from early THIS morning, and burncd DOES work now. Apparently, it wasn't a kernel issue, unless just leaving the machine up for a day released a lock that should never have been granted... 1:46:59pm wahoo(110): burncd -s 12 -f /dev/acd0c data StarOffice-x86.iso fixate next writeable LBA 0 addr = 0 size = 587956224 blocks = 287088 writing from file StarOffice-x86.iso size 574176 KB written this track 574176 KB (100%) total 574176 KB fixating CD, please wait.. Jim Bryant wrote: > Heheh... Just to clarify for some... my standard practice involves > following buildworld with installworld... > > Jim Bryant wrote: > >> Søren Schmidt wrote: >> >>> Kernel and burncd must be in sync again, a make kernel followed >>> by a make world should do it. >>> >>> -Søren >> >> >> >> >> acd0: CD-RW at ata1-master PIO4 >> >> This is from -current as of about 1am or so CDT today. I did a make >> buildworld instead of a make world, but I would assume that wouldn't >> be the cause of this. >> >> 2:51:10pm wahoo(112): burncd -s 12 -f /dev/acd0c data >> StarOffice52.iso fixate >> burncd: ioctl(CDIOCSTART): Device busy >> >> jim > > > -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - "Religious fundamentalism is the biggest threat to international security that exists today." United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: reinstatement of MSDOSFS on boot floppy fails
D'ya think it might be time for a 3rd floppy? On Wed, 3 Oct 2001, Jordan Hubbard wrote: > sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt >1440 /R/stage/image.kern 8 fd1440 > disklabel: ioctl DIOCWLABEL: Operation not supported by device > Warning: Block size restricts cylinders per group to 6. > Warning: 1216 sector(s) in last cylinder unallocated > /dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors > 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) > super-block backups (for fsck -b #) at: > 32 > cpio: write error: No space left on device > *** Error code 1 > > We're back where we started. The other stuff wasn't enough. > > - Jordan > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
Julian Elischer wrote: > > See above. fetchmail + pop works fine. I've been get all of my envelope > > information, and there is no worries. > > This has noty been the case where I have seen.. > > This requires that you have a mailbox set up on the server which can > 'encode' all of the envelope information (e.g. other delivery addresses) > and that fetchmail can extract this information in such a way that it can > reconstruct the original mail address information without getting it > confused with the header infiormation within the mail headers, which of > course should be completely ignored when it comes to delivery. > > Unfortunatly I have not see this done completely successfully. > > UUCP can do this with very little work and does it very well. > (as if keeps the 'command' information separate from the > "data" information). > > I"m not saying that this is not possible, just that it's very complicated > to get right compared to a basic "out of the box" uucp connection that > can do it completely correctly with almost no work... FWIW: Ricoh, Japan allowed me to dictate their SMTP/POP3 server setup to them for use with the InterJet, which at the time was running fetchmail for the "POP3 lookup" feature. I was able to dictate single delivery of messages by their SMTP server, which resulted in valid "for " optional portions of the "Received:" timestamp line. The fetchmail in question included my patches to permit the command line override of the seperate delivery/fanout machine assuming that the delivery machine hosted the POP3 maildrop (Eric Raymond did not respond to several emails where I tried to get these patches included in fetchmail, as an overload of an otherwise duplicate command line option). Given this change to fetchmail, and the timestamp envelope information, the single deliver did not exposed "Bcc:" envelope data to anyone but the recipient who was "Bcc:"'ed. So I can vouch for POP3 based domain fanout working in hundreds of installations... IFF you and your ISP take special pains to cooperate on both ends. When we moved to the PMTA code, all of the fetchmail related problems went away (a good cathedral beats a bazaar any day). The IBM Web Connections NOC supported fanout delivery from day one (of course, since I was the architect for that NOC). > > ETRN also is a good 'fetch' mechanism, if your ISP sets up MX records > > for you. When you come up, you simply telnet into your ISP's mail > > server, then type 'ETRN foobar.com', and it'll dump all your email to > > the IP address of your static configuration. > > It doesn't even work well for static users in large configurations.. > as it requires a full queue scan. (some mail servers do this better > than others). Yes. 8-). David Wolfskill and I rewrote portions of sendmail to support per domain mail queues, as you well know, and were able to successfully support 100,000 domains on a single mail server with a load of 400,000 messages per day. Comparatively, Telenor had a SPARC Center 1 that crashed under a once-per-hour ETRN polling load for only 300 virtual domains (without the sendmail changes we did). I believe our patches for sendmail 8.9.3 are still up on the ftp.whistle.com server... Interestingly, Microsoft Exchange is one of the few commercial SMTP servers that can handle more than a few hundred ETRN based virtual domain instances. Go figure... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> Interestingly, Microsoft Exchange is one of the few commercial > SMTP servers that can handle more than a few hundred ETRN based > virtual domain instances. Go figure... Any Q-Mail based solution using the commonly available ETRN patch also scales well, although you have to 'roll your own' release and integrate the patch separately. However, this is arguably not much harder than configuring the ETRN portions of the configuration. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SIOCGIFDATA
< said: > I was wondering if anyone had thought of implementing the above ioctl. Right > now from what I can tell, (from wmnet, and netstat) all stats for a network > device are kvm_read out of the kernel. These applications should use sysctl instead. All of the information is available through the interface mib. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
On Wed, Oct 03, 2001 at 02:34:51PM -0600, Lyndon Nerenberg wrote: > > Do you mean 'full-time IP connectivity', because if you can setup a UUCP > > connection, you can just as easily setup a PPP connection over the same > > medium, giving you IP connectivity. > > True, but there's a lot more infrastructure overhead involved in > setting up a group of disconnected machines via dialup IP than > there is connecting them via UUCP. And where dialup time is precious > UUCP is the hands-down winner for not wasting any of that dialup > resource. > > > therefore doesn't belong in the mainstream release. It *is* still > > available as an add-on port, so those who need it can still get it > > So the base distribution contains /bin/sh, /sbin/init, and > /sbin/pkg_add? Me, I like my bikesheds painted in white and green > zebra stripes. > > > Finally, the security > > issues make it a non-starter to keep in the default distribution. > > I would like to see evidence of where --config is *required* to > make someone's UUCP setup work. And what percentage of the overall > UUCP user population are represented by those people? I still > contend the "problem" can be fixed by removing --config. While that > fix will apparently impact some people, the impact of that fix is > a lot lower than ripping out UUCP altogether. There are many other points - some examples I know of: The /var/spool/uucppublic which is writeable by everyone. Usually you don't want this. Ever received a mail with an envelope like "foo bar"@company.com? It's legal and sendmail accepts them - but rmail doesn't like the space as it gets to arguments out of it. This is maybe even exploitable. uux forwarding to a site with exact 8 letters in size doesn't work. Yes - tranditional sites are limited to 7 letters but users don't care. There is a port and thus packages will be build and you can install it whenever you need it. If you don't need it - which is the by far most common case - you don't want to see such a critical and unmaintained software installed. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp user shell and home directory
> Do you mean 'full-time IP connectivity', because if you can setup a UUCP > connection, you can just as easily setup a PPP connection over the same > medium, giving you IP connectivity. True, but there's a lot more infrastructure overhead involved in setting up a group of disconnected machines via dialup IP than there is connecting them via UUCP. And where dialup time is precious UUCP is the hands-down winner for not wasting any of that dialup resource. > therefore doesn't belong in the mainstream release. It *is* still > available as an add-on port, so those who need it can still get it So the base distribution contains /bin/sh, /sbin/init, and /sbin/pkg_add? Me, I like my bikesheds painted in white and green zebra stripes. > Finally, the security > issues make it a non-starter to keep in the default distribution. I would like to see evidence of where --config is *required* to make someone's UUCP setup work. And what percentage of the overall UUCP user population are represented by those people? I still contend the "problem" can be fixed by removing --config. While that fix will apparently impact some people, the impact of that fix is a lot lower than ripping out UUCP altogether. --lyndon We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true. -- Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: reinstatement of MSDOSFS on boot floppy fails
Sure, I just don't have time to work on this right now. - jordan > > D'ya think it might be time for a 3rd floppy? > > > On Wed, 3 Oct 2001, Jordan Hubbard wrote: > > > sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt >1440 /R/stage/image.kern 8 fd1440 > > disklabel: ioctl DIOCWLABEL: Operation not supported by device > > Warning: Block size restricts cylinders per group to 6. > > Warning: 1216 sector(s) in last cylinder unallocated > > /dev/md0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors > > 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) > > super-block backups (for fsck -b #) at: > > 32 > > cpio: write error: No space left on device > > *** Error code 1 > > > > We're back where we started. The other stuff wasn't enough. > > > > - Jordan > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP kernel & burncd change..
On Wed, Oct 03, 2001 at 01:56:11PM -0500, Jim Bryant wrote: > This may sounds strange, but as I don't actually recall seeing any actual changes to >burncd unless i missed something in my cvsup > early this morning CDT... > > I just decided to give it another try before booting into the kernel built this >morning, and it seems that it was a "world" issue, > and not a kernel issue, as I'm running the same kernel I reported below, but a world >from early THIS morning, and burncd DOES work now. There were changes recently..if your kernel is out of sync with your world, you'll often get problems. Kris msg32392/pgp0.pgp Description: PGP signature
Re: uucp user shell and home directory
On Wed, Oct 03, 2001 at 12:55:08PM -0600, Nate Williams wrote: > > Tell me, is your mail compliant with the non-disclosure of "Bcc:" > > recipients requirement? If fetchmail doesn't strip the tunneling > > headers (it doesn't), then the headers disclose "Bcc:"'ed > > recipients to anyone who chooses to look. > > It sure is, because it's the responsibility of the mail sending program > to handle this. Fetchmail is a mail retrieval program, so it's only job > is to fetch the mail that is already delivered to me. You have missed the point: It's the responsibility of of the sending program not to put bcc informations into the data part of the mail. Since POP3 only stores the data part you won't see it unless the mailserver puts envelope informations into the data part. Now that it's the job of the POP3 client to remove these and reuse it as envelope informations. The typical Problems are: - Cheap implementations try to guess envelope informations from the To: and CC: Header. - Better implementations require envelope informations put into the header part by the MTA on the POP3 Server. - Realy working implementations also need to remove the helper headers. Otherwise a recpient would get the header encoded envelope. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
