Consequences of disabling vtrnd

[Max Baroi]

If this is not the appropriate place, I apologize.

Installing on an instance on vultr.com from booting from the standard image 
hangs. This is pretty well documented, and the equally well documented 
workaround is disabling vtrnd.

But are there lingering consequences from setting hint.vtrnd.disabled in the 
boot menu? The man page says virtio_random supplies the guest with high-quality 
random bits from the host. With this disabled, is the guest's entropy pool 
populated from a different high quality source or does the workaround leave the 
guest with only low entropy sources?

Thanks for any reply,
Max Baroi

Re: trpt(8) to be decomissioned

[Max Baroi]

Gleb,

Thank you for the response. I rescind my suggestion.

-Max

On 11/4/2022 9:40 AM, Gleb Smirnoff wrote:

   Max,

the reason I want to retire it is not that it consumes 40 Kb
in the repository.  The reason is that knows kernel structures,
and fails to compile after changes to them.  So the tool that
nobody uses requires special care when working on TCP.  The
kernel headers disclose the structures for trpt (with some
protection with _WANT_TCPCB, though) and some software from
ports (not calling names!) would start use them too. Now a
kernel developer needs to care not only about trpt, but
about this software, too.

On the kernel side there is also TCPDEBUG code that needs
to be kept compilable, while apparently nobody uses it.

On Fri, Nov 04, 2022 at 07:19:19AM +, Max Baroi wrote:
M> I'm sorry if this is an inappropriate suggestion, but I think it would be neat if there was a 
place in the ports hierarchy for retired programs like trpt. Maybe a "historical" or 
"archival" directory for programs phased out of from base, especially ones that are almost 
four decades old.
M>
M> -Max
M>
M> Nov 3, 2022 11:04:07 PM Mike Karels :
M>
M> > On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote:
M> >
M> >>   Hi,
M> >>
M> >> trpt(8) is utility to pull TCP debugging data from the kernel
M> >> in 4.2BSD. We still have it in the base, with corresponding
M> >> TCPDEBUG option in the kernel and SO_DEBUG socket option.
M> >>
M> >> At the same time we have much more powerful debugging facilities
M> >> for TCP, e.g. the Dtrace probing, the TCP black box logging and
M> >> siftr.  These are the tools that modern developers use.
M> >>
M> >> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@.
M> >> None of them new what trpt(8) is :) Looks like a good justification
M> >> to me.
M> >
M> > I have used trpt, but not for many years.  It was done before tcpdump
M> > as well.  Its time has long since gone.
M> >
M> >     Mike
M> >> --
M> >> Gleb Smirnoff
M>
M>

Re: trpt(8) to be decomissioned

[Max Baroi]

I'm sorry if this is an inappropriate suggestion, but I think it would be neat 
if there was a place in the ports hierarchy for retired programs like trpt. 
Maybe a "historical" or "archival" directory for programs phased out of from 
base, especially ones that are almost four decades old.

-Max

Nov 3, 2022 11:04:07 PM Mike Karels :

> On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote:
> 
>>   Hi,
>> 
>> trpt(8) is utility to pull TCP debugging data from the kernel
>> in 4.2BSD. We still have it in the base, with corresponding
>> TCPDEBUG option in the kernel and SO_DEBUG socket option.
>> 
>> At the same time we have much more powerful debugging facilities
>> for TCP, e.g. the Dtrace probing, the TCP black box logging and
>> siftr.  These are the tools that modern developers use.
>> 
>> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@.
>> None of them new what trpt(8) is :) Looks like a good justification
>> to me.
> 
> I have used trpt, but not for many years.  It was done before tcpdump
> as well.  Its time has long since gone.
> 
>     Mike
>> -- 
>> Gleb Smirnoff