Re: Deprecating base system ftpd?

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

Don't forget that Telnet is an actual protocol, which telnet(1)
implements.  nc is (for the most part) just a byte-copying middleman.

There's still gear out there that speaks Telnet, and expects the
client to support it (primarily for things like line mode editing).

--lyndon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

Ruben van Staveren via freebsd-stable writes:

> It is time to deprecate ftp altogether, and any other protocols that =
> embed protocol information in layer 7, thus hurting any #IPv6 migration =
> and deployment technology (SIIT-DC e.g).

> ftp, a protocol not using TLS protection [...]

You seem to be a couple of decades behind the times.

RFC4217 (Securing FTP with TLS) was published on 2005.  IPv6 suopport
dates back to 1998 in RFC 2428 (FTP Extensions for IPv6 and NATs).

It would be nice if the base system ftpd grew TLS support.  OpenBSD has
had this for years.

--lyndon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Intel Xeon D-2146NT SoC Support

[Lyndon Nerenberg]

[ I asked this on -hardware but didn't get any responses, so I'm
  widening the scope a bit. ]

We're looking a buying a Supermicro system with the X11SDV-8C-TP8F
motherboard.  This uses a Xeon D-2146NT SoC.  It's not clear what
the embedded chipset is, so it's proving a bit tricky to confirm
whether or not the board will get along with 11.2.

In particular, we need to ensure that we can talk to each of the
12 SATA ports as a standalone (JBOD) disk (this will be a ZFS
fileserver), and that the SFP+ ports will run with 10 Gb/s optics.

If anyone is running this board (or anything else running that D-2146NT
chip) I'd appreciate hearing from you.

FWIW, the system we're looking at is the SSG-5019D8-TR12P:

  https://www.supermicro.com/products/system/1U/5019/SSG-5019D8-TR12P.cfm

Thanks!

--lyndon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LAGG and Jumbo Frames

[Lyndon Nerenberg]

> On Sep 19, 2016, at 3:08 PM, Slawa Olhovchenkov  wrote:
> 
> This is because RTT of this link for jumbo frames higher 1500 bytes
> frame for store-and-forward switch chain.

For TCP, RTT isn't really a factor (in this scenario), as the windowing and 
congestion avoidance algorithms will adapt to the actual bandwidth-delay 
product of the link, and the delays in each direction will be symmetrical.

Now the ack for a single 9000 octet packet will take longer than that for a 
1500 octet one, but that's because you're sending six times as many octets 
before the ACK can be generated.  The time to send six 1500 octet packets and 
receive the ACK from sixth packet is going to be comparable to that of 
receiving the ack from a single 9000 octet packet.  It's simple arithmetic to 
calculate the extra protocol header overhead for 6x1500 vs 1x9000.

If there *is* a significant difference (beyond the extra protocol header 
overhead), it's time to take a very close look at the NICs you are using in the 
end hosts.  A statistically significant difference would hint at poor interrupt 
handling performance on the part of one or more of the NICs and their 
associated device drivers.

The intermediate switch overhead will be a constant (unless the switch 
backplane becomes saturated from unrelated traffic).

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: LAGG and Jumbo Frames

[Lyndon Nerenberg]

Everything on physical Ethernet has support for it Including the LAN 
interface of Firewall, and talks to it just fine over a single interface with 
Jumbo frames enabled.


Well, before you get too carried away, try this:

1) Run a ttcp test between a pair of local hosts using the exiting 
jumboframes (pick two that you expect high volume traffic between).


2) Run the same test, but with the default MTU.

If you don't see a very visible difference in throughput (e.g. >15%), it's 
not worth the hassle.


Just as a datapoint, we're running 10-gigE off some low-end Supermicro 
boxes with 10.3-RELEASE.  Using the default MTU we're getting > 750 MB/s 
TCP throughput.  I can't believe that you won't be able to fully saturate 
a 1 Gb/s link running the default MTU on anything with more oomph than a 
dual-core 32-bit Atom.


IOW, don't micro-optimize.  Life's too short ...

--lyndon

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LAGG and Jumbo Frames

[Lyndon Nerenberg]

This is almost certainly a PMTUd issue.

Unless your end-to-end paths to everything you talk to have jumboframes 
configured, there's no benefit to setting them up on the lagg.  Just go 
with the default MTU.


--lyndon

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ssh-keygen between SuSE and FreeBSD

[Lyndon Nerenberg]

That made it possible for me to ssh from SuSE server to FreeBSD server, 
but now when I ssh from my Mac to SuSE server it wants a password now:


ssh-agent holds your keys in memory for you, and provides them to remote 
systems when needed. You need to run it on each system you log in to.


If you have a single workstation you normally use, start ssh-agent there 
and set your ssh client to forward keys to remote systems.


DOn't you have a local IT helpdesk? This is pretty basic stuff that they 
should have documentation for.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD vs Region Code DVDs

[Lyndon Nerenberg]

I've had similar experiences with DaVinci Code and Casino Royal.


Casino Royale is using something new.  It managed to trip up Mac The 
Ripper, which so far has had a 100% success rate for me.


In general the Sony infections imbed bad sectors on the disks in locations 
that a DVD player parsing the data stream will skip over.  In most cases 
if you ignore the read errors and just carry on, things work fine (MTR 
does this to good effect).  I don't know what the latest trick is.


Make sure to return your DVDs for a refund, and send a letter to the 
manufactures telling them to go fsck themselves.


--lyndon

  /* Pre-C-Preprocessor to translate ANSI trigraph idiocy in BUF
 before main CCCP processing.  Name `pcp' is also in honor of the
 drugs the trigraph designers must have been on. */
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

eMachines T3304

[Lyndon Nerenberg]

If you're running FreeBSD on an eMachines T3304 system, could you please 
send me a copy of your /var/run/dmesg.boot?  Thanks!


--lyndon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [OT] resolv.conf and dhclient

[Lyndon Nerenberg]

Unfortunately, supersede doesn't cut it (for me).

I have two interfaces, one wired and one wireless.  Both addresses are
negotiated via DHCP.  However, I do /not/ want to use the DNS servers
provided via the wireless connection.



interface ath0 {
supersede domain-name orthanc.ca;
supersede domain-name-servers 127.0.0.1;
}

interface bge0 {
supersede domain-name orthanc.ca;
supersede domain-name-servers 127.0.0.1;
}

And then just run a local instance of named.

--lyndon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [OT] resolv.conf and dhclient

[Lyndon Nerenberg]

And what happens when I'm connected at home, and need to view portions of
DNS that are only accessible to the wired network?


Split DNS is a PITA.  If your nameservers are smart enough they will see 
which path a query took, and act appropriately.  Sadly, ours at work 
aren't.  Yet.


But as someone else mentioned, you've now gone beyond the realm of simple 
DHCP configuration.  DHCP was never intented to deal with policy routing 
issues (at whatever layer of the stack).


--lyndon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: resolver doesn't see resolv.conf changes

[Lyndon Nerenberg]

On Apr 8, 2006, at 1:39 AM, Ulrich Spoerlein wrote:


Good idea, but this defeates the hierarchical purpose of DNS. Now my
caching DNS is always querying the root DNS servers.


That's how the DNS works.  You query the root once for the TLD, then  
cache the NS records for the TLD's servers, point one level down, and  
repeat until you find the target.



And there might be ISPs who disallow outgoing DNS connections to
somewhere else than their own DNS servers.


In my experience, these are few and far between.


Additionally, when jacking into someone else's LAN, I usually want to
use their local DNS servers, to resolve local names.


And sites running split-DNS are also rare.

But worry not: dhclient can deal with these, too.  A quick perusal of  
dhclient.conf(5) turns up the prepend and append modifiers.   
Choose whichever best implements your preferred policy.


The two scenarios you describe are rare enough that it's not worth  
writing glue to fudge up forwarders entries in named.conf and the  
associated headaches.  Or, you could port nscd over from Solaris.


--lyndon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: resolver doesn't see resolv.conf changes

[Lyndon Nerenberg]

Is the resolver supposed to periodically check for updates to the
resolv.conf, or are the applications somehow caching the IP of the DNS
server?


No, resolv.conf is only read once when the resolver routines initialize.

The solution is to run a local caching nameserver instance.  You should do 
this anyway, for performance reasons. Add 'named_enable=YES' to 
/etc/rc.conf, and modify your /etc/dhclient.conf as follows:


interface ath0 {
supersede domain-name orthanc.ca;
supersede domain-name-servers 127.0.0.1;
}

interface bge0 {
supersede domain-name orthanc.ca;
supersede domain-name-servers 127.0.0.1;
}

Change the domain string to something more appropriate, and adjust the 
interface names to match your laptop. You'll need to start named and 
restart the dhclient instances (in that order) for the changes to take 
effect.


--lyndon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Changing release version on source

[Lyndon Nerenberg]

If the software you're using gets the version in the same manner as  
uname, then all you should need is a new kernel.


Or maybe just LD_PRELOAD a replacement for uname() that fakes out the  
release information?


--lyndon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Jail to jail network performance?

[Lyndon Nerenberg]

On Sep 13, 2005, at 11:59 PM, Uwe Doering wrote:

Now, for security reasons jails normally are confined in separate  
filesystems, or at least in separate parts of a common one.  So in  
case of MySQL you would have to use TCP sockets to communicate  
between jails.  This socket type typically consumes more CPU  
because of TCP's protocol overhead.  However, whether you would  
actually notice any difference in speed basically depends on how  
much excess CPU power there is available on that server.


Ignoring security (or filesystem namespace issues) I will just note  
that using named sockets for local IPC is a Good Thing.  When I  
worked at Messaging Direct I taught sendmail to speak LMTP over named  
sockets, and our local delivery rate (to our IMAP server) went up by  
a factor of 10.


It would be really cool if we could figure out a way to do AF_UNIX  
between jails, but I confess to not having thought about any of the  
implications ...  (Maybe netgraph can help here?)


--lyndon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ENOMEM in swap_pager

[Lyndon Nerenberg]

On Sep 14, 2005, at 4:13 PM, John-Mark Gurney wrote:

IIRC GEOM should handle ENOMEMs by retrying the IO, but I'm  
asking just in

case - are these errors something I should worry about?



I/O errors suggest your disk is failing.



Unless for some reason his disk is running out of memory:
grep 12 /usr/include/errno.h
#defineENOMEM12/* Cannot allocate memory */


The error occurs when sys/vm/swap_pager:swapgeom_strategy() can't  
allocate a copy of an underlying I/O request buffer. The log message  
lies a bit; this isn't a physical disk I/O error.


--lyndon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

non-root /var/run files (was Re: Sendmail, smmsp, and pid file)

[Lyndon Nerenberg]

[Redirecting to the hackers list -- please respect the reply-to header]

 Claus == Claus Assmann [EMAIL PROTECTED] writes:

Claus On Mon, May 27, 2002, Philip J. Koenig wrote:
 Any particular reason why the sendmail with 4.6-RC is writing sm-
 client.pid into /var/spool/clientmqueue instead of /var/run?

Claus Permissions.

This points out a short-fall in the /var/run scheme: it can only be used
by processes running with an euid of 0 at the time they create the file.

If we have a /var/run/sendmail directory owned by the smmsp user then
sendmail can create its pid files there. Likewise for bind. The purgedir
function in /etc/rc (used to clean /var/run) will preserve the existing
directory structure under /var/run, so the sub-directory tree will
survive reboots.

--lyndon

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: tail

[Lyndon Nerenberg]

 Donn == Donn Miller [EMAIL PROTECTED] writes:

Donn Yeah, and you can do cat dirname | strings;

Another recipient of the Gratuitous Use of Cat award. 'strings dirname'
works just fine. (And if he didn't have ls available, it's a safe bet
that strings wasn't there, either ;-)

--lyndon

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: tail

[Lyndon Nerenberg]

 Juha == Juha Saarinen [EMAIL PROTECTED] writes:

Juha Note the rare situations -- it's not useful when you make
Juha a typo, or a mistake.

A better fix would be to change your shell to /usr/local/bin/ispell.

Juha So the best thing to do is to keep the current behaviour for
Juha tail et al, but make it accessible through a flag.

No, the best thing to do is to run Windows. Microsoft Excels (nyuk nyuk)
in telling you all the things you shouldn't do.

--lyndon

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message