Re: NIS client performance seems very poor under network load

2001-10-03 Thread Thyer, Matthew

"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

2001-10-03 Thread Maxim Sobolev

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

2001-10-03 Thread Stephan van Beerschoten

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 ?

2001-10-03 Thread Dmitry Karasik

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

2001-10-03 Thread $B>.Ln42@8(B

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

2001-10-03 Thread Martin Blapp


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

2001-10-03 Thread Bernd Walter

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

2001-10-03 Thread Alexander N. Kabaev

> 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

2001-10-03 Thread Riccardo Torrini

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

2001-10-03 Thread Nate Williams

> 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

2001-10-03 Thread Jordan Hubbard

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

2001-10-03 Thread Alfred Perlstein

* 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

2001-10-03 Thread Jordan Hubbard

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

2001-10-03 Thread Alfred Perlstein

> > * 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

2001-10-03 Thread Jordan Hubbard

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

2001-10-03 Thread Marcel Moolenaar

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

2001-10-03 Thread Thyer, Matthew

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

2001-10-03 Thread Garance A Drosihn

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..

2001-10-03 Thread Jim Bryant

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

2001-10-03 Thread Andrew Gallatin


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

2001-10-03 Thread Terry Lambert

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

2001-10-03 Thread Lyndon Nerenberg

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

2001-10-03 Thread Jordan Hubbard

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

2001-10-03 Thread Terry Lambert

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

2001-10-03 Thread Nate Williams

> > > 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..

2001-10-03 Thread Jim Bryant

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

2001-10-03 Thread Matthew Jacob


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

2001-10-03 Thread Terry Lambert

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

2001-10-03 Thread Nate Williams

> 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

2001-10-03 Thread Garrett Wollman

< 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

2001-10-03 Thread Bernd Walter

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

2001-10-03 Thread Lyndon Nerenberg

> 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

2001-10-03 Thread Jordan Hubbard

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..

2001-10-03 Thread Kris Kennaway

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

2001-10-03 Thread Bernd Walter

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