Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/8/19, Gene Heskett  wrote:
> On Monday 08 July 2019 14:48:59 Lee wrote:
>
>> On 7/8/19, Andrei POPESCU  wrote:
>> > On Lu, 08 iul 19, 13:37:26, Lee wrote:
>> >> On 7/7/19, andreimpope...@gmail.com 
> wrote:
>> >> > The dangers are not at all obvious to me, possibly because I
>> >> > haven't used it much (if at all).
>> >>
>> >> Read the first three paragraph of the "Security Considerations"
>> >> section https://tools.ietf.org/html/rfc6762#section-21
>> >>
>> >> Assuming everything on the network is a trusted host is a dangerous
>> >> assumption, so paragraph 1 is N/A
>> >>
>> >> Assuming a trusted host won't get hacked is a dangerous assumption,
>> >> so paragraph 3 is N/A.
>> >>
>> >> All that's left is paragraph 2 -- and uninstalling whatever
>> >> software uses mDNS :)
>> >
>> > Security is not a black/white thing, it's more like a balancing act.
>>
>> Agreed
>>
>> > In my opinion mDNS/zeroconf can make perfect sense in some
>> > environments and be a complete no-go in others.
>>
>> Apparently it's not clear that I agree :(
>>
>> I thought about concluding with something about different people
>> making different assumptions & some not wanting or able to set up
>> their own dns server & living with the risk, but it seemed like such
>> an obvious conclusion that I didn't bother.
>>
>> Regards,
>> Lee
>
> If referring to my problem Lee,

Nope, this sub-thread is a result of my offering a hyperbolic opinion
to someone else.

You're very clearly in the "my network, my rules" camp, so I won't be
offering any opinions on how you should/shouldn't run your own network
:)

Regards,
Lee

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Monday 08 July 2019 14:48:59 Lee wrote:

> On 7/8/19, Andrei POPESCU  wrote:
> > On Lu, 08 iul 19, 13:37:26, Lee wrote:
> >> On 7/7/19, andreimpope...@gmail.com  
wrote:
> >> > The dangers are not at all obvious to me, possibly because I
> >> > haven't used it much (if at all).
> >>
> >> Read the first three paragraph of the "Security Considerations"
> >> section https://tools.ietf.org/html/rfc6762#section-21
> >>
> >> Assuming everything on the network is a trusted host is a dangerous
> >> assumption, so paragraph 1 is N/A
> >>
> >> Assuming a trusted host won't get hacked is a dangerous assumption,
> >> so paragraph 3 is N/A.
> >>
> >> All that's left is paragraph 2 -- and uninstalling whatever
> >> software uses mDNS :)
> >
> > Security is not a black/white thing, it's more like a balancing act.
>
> Agreed
>
> > In my opinion mDNS/zeroconf can make perfect sense in some
> > environments and be a complete no-go in others.
>
> Apparently it's not clear that I agree :(
>
> I thought about concluding with something about different people
> making different assumptions & some not wanting or able to set up
> their own dns server & living with the risk, but it seemed like such
> an obvious conclusion that I didn't bother.
>
> Regards,
> Lee

If referring to my problem Lee, dns the way I have it setup since roughly 
1998 works perfectly. Its the lack of a dhcpd-like server, which adds 
needless complexity IMO to an otherwise working system I've been using 
since before I retired my amiga in 2000. In my case, both avahi-daemon 
and dchpcd5 were inventing bogus ip addresses, and setting the metric 
very low, forcing the system to use the bogus 169.254.etc numbers.  And 
they were cached, I suspect in /proc/network, so in order to achieve a 
working system, issueing the testing pings from the machines own 
address, asking the router for the NAT translation.  The router of 
course is running dnsmasq so it caches the common stuff, and if it does 
not have it in the cache its asks my ISP's dns. Takes about 90 ms if it 
has to ask a shentel dns server.

But both the router and the managed switch that connects the rest of my 
machines, respond only to 192.168.71.00/24 stuff, so 169 stuff 
is /dev/nulled as it should be.

So I had no external network access from that machine. I do have a dhcpd 
server in the router, facing the radio when its turned on and supposedly 
responding only to the MAC's of my sons smartfones.  So they can use my 
bandwidth when within range, but their smartfones can't see me. Most of 
the time they are 1000+ miles out of range.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Brian]

On Mon 08 Jul 2019 at 13:37:26 -0400, Lee wrote:

> On 7/7/19, andreimpope...@gmail.com  wrote:
> > On Sb, 06 iul 19, 15:36:37, Lee wrote:
> >>
> >> "an accident waiting to happen" was from me and I also gave the rfc
> >> for mdns, so that's hardly "nothing of substance to support that
> >> view."  If you're having trouble finding the rfc, it's here
> >>   https://tools.ietf.org/html/rfc6762
> >
> > Care to elaborate though?
> 
> While reading about a security issue I came across the line "An
> insecure protocol will eventually be exploited." - which sounds right
> to me.  And the standard q for most security issues involving an
> insecure protocol seems to be
> q: how do i prevent  from happening?
> a: by not allowing it in the first place.
> 
> Hopefully we're clear about my bias now :)

Indeed we are. Everyone has a bias of one sort or another. It is often
what makes things interesting.
> 
> > The dangers are not at all obvious to me, possibly because I haven't
> > used it much (if at all).
> 
> Read the first three paragraph of the "Security Considerations" section
>   https://tools.ietf.org/html/rfc6762#section-21
> 
> Assuming everything on the network is a trusted host is a dangerous
> assumption, so paragraph 1 is N/A
> 
> Assuming a trusted host won't get hacked is a dangerous assumption, so
> paragraph 3 is N/A.
> 
> All that's left is paragraph 2 -- and uninstalling whatever software
> uses mDNS :)

I am unsure your analysis necessarily leads to to the conclusion you
make. Perhaps it does for you, but the section is, after all, dealing
only with considerations. You have assessed them and come to a decision
which fits your situation. 

Anyway, thank you for this diligent response. It is differs somewhat
from

 > I'd also consider exterminating avahi with extreme prejudice,
 > i.e. 'aptpurge avahi-daemon'. Really simplifies things. Not
 > installing this software in the first place works even better.

This lead only to boltstering the OP's inate prejudices against software
he lacks understanding of and that does not fit into his world view..

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/8/19, Andrei POPESCU  wrote:
> On Lu, 08 iul 19, 13:37:26, Lee wrote:
>> On 7/7/19, andreimpope...@gmail.com  wrote:
>>
>> > The dangers are not at all obvious to me, possibly because I haven't
>> > used it much (if at all).
>>
>> Read the first three paragraph of the "Security Considerations" section
>>   https://tools.ietf.org/html/rfc6762#section-21
>>
>> Assuming everything on the network is a trusted host is a dangerous
>> assumption, so paragraph 1 is N/A
>>
>> Assuming a trusted host won't get hacked is a dangerous assumption, so
>> paragraph 3 is N/A.
>>
>> All that's left is paragraph 2 -- and uninstalling whatever software
>> uses mDNS :)
>
> Security is not a black/white thing, it's more like a balancing act.

Agreed

> In my opinion mDNS/zeroconf can make perfect sense in some environments
> and be a complete no-go in others.

Apparently it's not clear that I agree :(

I thought about concluding with something about different people
making different assumptions & some not wanting or able to set up
their own dns server & living with the risk, but it seemed like such
an obvious conclusion that I didn't bother.

Regards,
Lee

Re: Assorted arm-buster problems - network configuration

[Brian]

On Sat 06 Jul 2019 at 18:14:04 -0400, Gene Heskett wrote:

> So I now have a working network. Free of the bogus inventions of dhcpd5 
> and avahi.  That _was_ the point of all this hoopla in the first place.
> 
> Now, I have learned what works to _my_ satisfaction.
> 
> Have you? Or did you quit reading the instant I went off the edge of your 
> menu?

No; I read it three times before going to bed. A good dose of fiction
helps me sleep better. :)

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[Andrei POPESCU]

On Lu, 08 iul 19, 13:37:26, Lee wrote:
> On 7/7/19, andreimpope...@gmail.com  wrote:
> 
> > The dangers are not at all obvious to me, possibly because I haven't
> > used it much (if at all).
> 
> Read the first three paragraph of the "Security Considerations" section
>   https://tools.ietf.org/html/rfc6762#section-21
> 
> Assuming everything on the network is a trusted host is a dangerous
> assumption, so paragraph 1 is N/A
> 
> Assuming a trusted host won't get hacked is a dangerous assumption, so
> paragraph 3 is N/A.
> 
> All that's left is paragraph 2 -- and uninstalling whatever software
> uses mDNS :)

Security is not a black/white thing, it's more like a balancing act.

In my opinion mDNS/zeroconf can make perfect sense in some environments 
and be a complete no-go in others.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/7/19, Curt  wrote:
> On 2019-07-06, Lee  wrote:
>>
>> "an accident waiting to happen" was from me and I also gave the rfc
>> for mdns, so that's hardly "nothing of substance to support that
>
> I see. So the totality of the mdns rfc (*somewhat* more succinct than a
> 19th century Russian novelistic endeavor) is the substantive foundation
> of your sound technical argument that avahi and its daemons are "an
> accident waiting to happen" (whatever that means exactly, but I fear to
> ask because you might refer me to Webster's Unabridged or the L.A. phone
> book circa 1974, which would entrain just too much summer reading for
> me, friend, as I prefer to do my wading through the sea).

In other words, you didn't even take a quick peek at the security
considerations section.  Right?

Regards,
Lee

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/7/19, andreimpope...@gmail.com  wrote:
> On Sb, 06 iul 19, 15:36:37, Lee wrote:
>>
>> "an accident waiting to happen" was from me and I also gave the rfc
>> for mdns, so that's hardly "nothing of substance to support that
>> view."  If you're having trouble finding the rfc, it's here
>>   https://tools.ietf.org/html/rfc6762
>
> Care to elaborate though?

While reading about a security issue I came across the line "An
insecure protocol will eventually be exploited." - which sounds right
to me.  And the standard q for most security issues involving an
insecure protocol seems to be
q: how do i prevent  from happening?
a: by not allowing it in the first place.

Hopefully we're clear about my bias now :)

> The dangers are not at all obvious to me, possibly because I haven't
> used it much (if at all).

Read the first three paragraph of the "Security Considerations" section
  https://tools.ietf.org/html/rfc6762#section-21

Assuming everything on the network is a trusted host is a dangerous
assumption, so paragraph 1 is N/A

Assuming a trusted host won't get hacked is a dangerous assumption, so
paragraph 3 is N/A.

All that's left is paragraph 2 -- and uninstalling whatever software
uses mDNS :)

Regards,
Lee

Re: Assorted arm-buster problems - network configuration

[David Wright]

On Mon 08 Jul 2019 at 08:36:38 (-0400), Greg Wooledge wrote:
> On Sat, Jul 06, 2019 at 08:46:19AM -0500, David Wright wrote:
> > On Fri 05 Jul 2019 at 20:10:42 (-0400), Gene Heskett wrote:
> > > But that begs another question Greg.  If it hasn't anything to do with 
> > > avahi-daemon, whyinhell did purging avahi-daemon take the libnsswitch 
> > > package with it?
> 
> > I'm puzzled too. Can you tell us which package you're talking about as
> > I can only find:
> > 
> > Package lib32nss-mdns
> > Package libnss3
> [snip]
> 
> I'm pretty sure Gene means this one:
> 
> wooledg:~$ apt-cache show avahi-daemon | grep libnss
> Recommends: libnss-mdns
> 
> As I demonstrated somewhere else in this thread,[1] removing avahi-daemon
> also removes libnss-mdns, and installing avahi-daemon also installs
> libnss-mdns, at least when using apt with whatever settings I'm currently
> using.  Which are probably pretty close to the defaults.
> 
> [1] https://lists.debian.org/debian-user/2019/07/msg00258.html

Yes, thanks for that; posting saves others from having to test what's
going on. I guess we should hardly be surprised. So the Debian system
that's allegedly completely broken (and has been "nuked" into who
knows what shape) turns out to be not a Debian system at all. Such a
waste of time.

Cheers,
David.

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Monday 08 July 2019 08:36:38 Greg Wooledge wrote:

> On Sat, Jul 06, 2019 at 08:46:19AM -0500, David Wright wrote:
> > On Fri 05 Jul 2019 at 20:10:42 (-0400), Gene Heskett wrote:
> > > But that begs another question Greg.  If it hasn't anything to do
> > > with avahi-daemon, whyinhell did purging avahi-daemon take the
> > > libnsswitch package with it?
> >
> > I'm puzzled too. Can you tell us which package you're talking about
> > as I can only find:
> >
yes, thats the one

> > Package lib32nss-mdns
> > Package libnss3
>
> [snip]
>
> I'm pretty sure Gene means this one:
>
> wooledg:~$ apt-cache show avahi-daemon | grep libnss
> Recommends: libnss-mdns
>
> As I demonstrated somewhere else in this thread,[1] removing
> avahi-daemon also removes libnss-mdns, and installing avahi-daemon
> also installs libnss-mdns, at least when using apt with whatever
> settings I'm currently using.  Which are probably pretty close to the
> defaults.
>
> [1] https://lists.debian.org/debian-user/2019/07/msg00258.html

ditto's here. But I think I'll disable the kernel pinning until such time 
as I get a realtime built and installed.

Thanks Greg.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Greg Wooledge]

On Sat, Jul 06, 2019 at 08:46:19AM -0500, David Wright wrote:
> On Fri 05 Jul 2019 at 20:10:42 (-0400), Gene Heskett wrote:
> > But that begs another question Greg.  If it hasn't anything to do with 
> > avahi-daemon, whyinhell did purging avahi-daemon take the libnsswitch 
> > package with it?

> I'm puzzled too. Can you tell us which package you're talking about as
> I can only find:
> 
> Package lib32nss-mdns
> Package libnss3
[snip]

I'm pretty sure Gene means this one:

wooledg:~$ apt-cache show avahi-daemon | grep libnss
Recommends: libnss-mdns

As I demonstrated somewhere else in this thread,[1] removing avahi-daemon
also removes libnss-mdns, and installing avahi-daemon also installs
libnss-mdns, at least when using apt with whatever settings I'm currently
using.  Which are probably pretty close to the defaults.

[1] https://lists.debian.org/debian-user/2019/07/msg00258.html

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Sunday 07 July 2019 12:28:21 Andrei POPESCU wrote:

> On Du, 07 iul 19, 07:17:33, Gene Heskett wrote:
> > On Sunday 07 July 2019 02:58:46 andreimpope...@gmail.com wrote:
> > > BTW, it's still not clear to me whether this is about a clean
> > > buster install or some image based on buster.
> >
> > Its the raspian image based on buster-rc2 AIUI.
>
> As suspected...
>
> > Reinstalling avahi-daemon
>
> Unlikely...
>
> > or dhcpcd5 will poison the routing, making the default route a
> > 169.254.0.0/16 address
>
> This I believe. It's most likely due to some Raspbian-specific startup
> script that tries to set up networking with DHCP.
>
> > So it appears I finally have a working network.
> > But so far, no one has addressed the next problem. I do not have
> > seating in any shape in front of the pi's own monitor and keyboard,
> > and my standing time w/o excruciating back pain from two crushed
> > disks in my back is maybe 15 minutes.  I would take a tall bar stool
> > which there is no room for to make the position usable for an hour.
> >
> > Therefore its imperative that ssh start on a reboot, which it does
> > not do now,
>
> It's almost impossible to guess (remotely) what *other* changes have
> been done to the Raspbian image. You might want to try asking in the
> Raspbian support channels instead.
>
> Technically I could download the image and inspect it locally,
> assuming I can even find it (including at least a download link would
> have been nice).
>
> At the moment I do have other stuff to do which is (hopefully) helping
> more people actually running Debian.
>
> You might try that as well (running pure Debian that is). According to
> this page  https://wiki.debian.org/RaspberryPi3 Debian runs unchanged
> on the Raspberry Pi 3.
>
> The images linked from there are not official, but they are build by a
> Debian Developer. The likelihood of custom scripts is, I believe,
> close to zero (though apparently this image is also set up for DHCP by
> default, have fun :) ).
>
> For a system that works as you expect it I suggest you do your own
> installation, either with Debian Installer or even with debootstrap.
>
> Thoroughly document in detail every step (e.g. using --variant=minbase
> for debootstrap can make a *huge* difference to the final image), or
> even better, script it.
>
> That way whenever you run into issues you can just post the script
> used and potential helpers will know what you did or did not.
>
> Good luck with fixing your ssh.
>
It has been fixed, and the last reboot finally mounted a 10Gig swap too, 
so thats another problem addressed as the default 100Meg swapfile on the 
u-sd card is not big enough to assemble all of the rs-274-D interpreter 
in linuxcnc. Add the 10G swap and it marches straight thru it on the 
build. Now we just need to work around the missing dependencies that 
buster for armv7 has thrown at us.  And fixing that is well above my pay 
grade. Darnit.

> Kind regards,
> Andrei


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Reco]

Hi.

On Sun, Jul 07, 2019 at 09:58:46AM +0300, andreimpope...@gmail.com wrote:
> On Sb, 06 iul 19, 18:14:04, Gene Heskett wrote:
> > 
> > If you read the full thread, you will find where I found and fixed that 
> > problem, by killing dhcpd5 with htop, and restarting networking, and 
> > the problem was fixed, everything then worked correctly, 
> 
> Did you ever find out why dhcpcd5 was even starting?

I solved this mystery.
Took an upgrade to buster, and somewhat botched network configuration in
the result. But it was worth it.

First, unlike ISC dhclient, which is the 'goto' DHCP client in Debian,
Raspbian promoted dhcpcd5 into this role.

Second, unlike dhclient, dhcpcd5 can work as a systemwide daemon, and if
run like that it tries to get a lease on every network interface if it's
UP and it's not a "lo". This can be changed via dhcpcd.conf, but it's
not done by default.

Third, /etc/init.d/dhcpcd contains a useful safeguard - a single
interface defined as "inet dhcp" in e/n/i prevents systemwide daemon
from running. In full accordance with Debian policy, dhcpcd5 tries to
run such daemon by default.

So far - so good, but buster's dhcpcd added fourth - a systemd unit that
runs /usr/sbin/dhcpcd regardless of a safeguard.
A result, assuming systemd as PID 1 - stretch's dhcpcd respects e/n/i,
buster's - does not. As an added "bonus" - buster's dhcpcd does not
respect "metric" setting in these circumstances.


A fun parts here are:

1) Problem is easily solved with the usual "systemctl disable/systemctl
stop" combo.

2) Debian does not exibit this behaviour by default, user has to install
dhcpcd5 package (which I do, because $REASONS).

3) Raspbian seem to be broken by default in this regard, but … you're
not supposed to edit e/n/i if using Raspbian as far as I understand.
Because you can always get DHCP lease and it's confusing to the user and
all that :)


As an upside, they finally fixed dhcpcd's ntp hook - it was broken in
stretch.

Reco

Re: Assorted arm-buster problems - network configuration

[Andrei POPESCU]

On Du, 07 iul 19, 07:17:33, Gene Heskett wrote:
> On Sunday 07 July 2019 02:58:46 andreimpope...@gmail.com wrote:
> >
> > BTW, it's still not clear to me whether this is about a clean buster
> > install or some image based on buster.
> >
> Its the raspian image based on buster-rc2 AIUI.

As suspected...
 
> Reinstalling avahi-daemon

Unlikely...

> or dhcpcd5 will poison the routing, making the default route a 
> 169.254.0.0/16 address

This I believe. It's most likely due to some Raspbian-specific startup 
script that tries to set up networking with DHCP.
 
> So it appears I finally have a working network.
> But so far, no one has addressed the next problem. I do not have seating 
> in any shape in front of the pi's own monitor and keyboard, and my 
> standing time w/o excruciating back pain from two crushed disks in my 
> back is maybe 15 minutes.  I would take a tall bar stool which there is 
> no room for to make the position usable for an hour.
> 
> Therefore its imperative that ssh start on a reboot, which it does not 
> do now, 

It's almost impossible to guess (remotely) what *other* changes have 
been done to the Raspbian image. You might want to try asking in the 
Raspbian support channels instead.

Technically I could download the image and inspect it locally, assuming 
I can even find it (including at least a download link would have been 
nice).

At the moment I do have other stuff to do which is (hopefully) helping 
more people actually running Debian.

You might try that as well (running pure Debian that is). According to 
this page  https://wiki.debian.org/RaspberryPi3 Debian runs unchanged on 
the Raspberry Pi 3.

The images linked from there are not official, but they are build by a 
Debian Developer. The likelihood of custom scripts is, I believe, close 
to zero (though apparently this image is also set up for DHCP by 
default, have fun :) ).

For a system that works as you expect it I suggest you do your own 
installation, either with Debian Installer or even with debootstrap.

Thoroughly document in detail every step (e.g. using --variant=minbase 
for debootstrap can make a *huge* difference to the final image), or 
even better, script it.

That way whenever you run into issues you can just post the script used 
and potential helpers will know what you did or did not.

Good luck with fixing your ssh.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[David Wright]

On Sun 07 Jul 2019 at 00:57:58 (-0400), Gene Heskett wrote:
> On Sunday 07 July 2019 00:11:43 David Wright wrote:
> > On Sat 06 Jul 2019 at 18:14:04 (-0400), Gene Heskett wrote:
> > > On Saturday 06 July 2019 15:35:10 Brian wrote:
> > > > On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote:
> > > > > On Friday 05 July 2019 15:23:38 Brian wrote:
> > > > > > I was rather hoping someone would clarify why not having
> > > > > > avahi-daemon in the first place was a good thing in general.
> > > > > > Your problem doesn't particularly interest me because it is
> > > > > > probably something you have brought on yourself due to
> > > > > > previous actions.
> > > > > >
> > > > > > > Here is your Clarification: I used apt to purge avahi-daemon
> > > > > > > which took nsswitch with it,
> >
> > That was your claim. Then I read the following:
> >
> >   Greg> Whatever Gene did, it's absolutely not normal or desirable for
> >   Greg> nsswitch.conf to vanish.  I still think he deleted it by hand
> > and then Greg> forgot the exact sequence of steps which led to its
> > disappearance, so Greg> he simply blamed it on purging ahavi-daemon.
> >
> >   Gene> I didn't say that. If I made that impression I didn't intend
> > to. I Gene> removed it by hand about 2 hours back but that u-sd has
> > not been Gene> inserted in the pi yet as I'm also the chief cook […]
> > Gene> […] recycle the dishwasher. :(
> >
> >   https://lists.debian.org/debian-user/2019/07/msg00306.html
> >
> > > > > > I stopped reading there. I am not into fantasy.
> > > > >
> > > > > Which proves another theorem of mine. Folks with a sheepskin on
> > > > > the office wall stop learning, and by your stopping without
> > > > > reading the explanation is evidence of that effect. I can lead
> > > > > you to the facts, but
> > > >
> > > > Your first "fact" is demonstrably incorrect and has been shown to
> > > > be so. Indeed, you seem to have backed away from your claim that
> > > > avahi-daemon is the cause of your difficulties. The only place you
> > > > lead people is up the misleading garden path. A clear statement of
> > > > what you did and what happened is more likely to bring results;
> > > > making attacking software a lifestyle choice gets a bit boring
> > > > after a while.
> > > >
> > > > > like the horse refusing to drink when led to water, I'll drop
> > > > > the reins. You may, or may not drink the water of knowledge. I
> > > > > can't control that.
> > > >
> > > > Is this an attempt at some self-promotion as the fount of
> > > > knowledge? I never thought I would live to see the day!
> > >
> > > If you read the full thread, you will find where I found and fixed
> > > that problem, by killing dhcpd5 with htop, and restarting
> > > networking, and the problem was fixed, everything then worked
> > > correctly, but I have not reinstalled avahi-daemon to see if it
> > > returns.  Perhaps I should because it appears there were 2 sources
> > > of that trash.
> >
> > Perhaps you mean dhcpcd5? I thought you said that you're "the last one
> > on the planet using hosts files and no dhcpd's of any kind".
> >
> That last as a qualifier was a bad reference too, as I now see the name 
> of that function having been changed sometime in the last 20 years.
> 
> > If you were running this, did you try using the -L or --noipv4ll
> > option?
> 
> No, and whereintunket would I find that in reference to my problem?>

As you might guess, I don't have dhcpcd5 installed and have no
interest in it, so I typed   man dhcpcd5   into google. Kind of
obvious really.

> > > Yes, I purged what was left as it wouldn't reinstall, then
> > > reinstalled avahi-daemon.  results:
> > >
> > > With avahi-daemon running. the trash in the ip a report was back
> > > after a networking restart, BUT allthough it showed in an ip r
> > > report with a metric of 202, I could still ping yahoo.com. I could
> > > not before.
> > >
> > > So I service avahi-daemon stopped it, and restarted the networking,
> > > trash 169.254 junk gone. An yahoo.com still pinged.
> > >
> > > So I've purged it again.  And restarted the networking yet again.
> > > ip a:
> > > pi@picnc:~ $ ip a
> > > 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> > > group default qlen 1000
> > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > > inet 127.0.0.1/8 scope host lo
> > >valid_lft forever preferred_lft forever
> > > inet6 ::1/128 scope host
> > >valid_lft forever preferred_lft forever
> > > 2: eth0:  mtu 1500 qdisc pfifo_fast
> > > state UP group default qlen 1000
> > > link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
> > > inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
> > >valid_lft forever preferred_lft forever
> > > inet6 fe80::8815:60eb:fe0a:d5bc/64 scope link
> > >valid_lft forever preferred_lft forever
> > > 3: wlan0:  mtu 1500 qdisc
> > > pfifo_fast state DOWN group default qlen 1000
> > > link/ether b8:27:eb:86:12:78 brd 

Re: Assorted arm-buster problems - network configuration

[Jonas Smedegaard]

Quoting Gene Heskett (2019-07-07 13:17:33)
> On Sunday 07 July 2019 02:58:46 andreimpope...@gmail.com wrote:
> 
> > On Sb, 06 iul 19, 18:14:04, Gene Heskett wrote:
> > > If you read the full thread, you will find where I found and fixed
> > > that problem, by killing dhcpd5 with htop, and restarting
> > > networking, and the problem was fixed, everything then worked
> > > correctly,
> >
> > Did you ever find out why dhcpcd5 was even starting?
> >
> > As far as I know DHCP clients start only when called by network
> > managing software (ifupdown, network-manager, etc.), or some custom
> > networking scripts on your system. In this case it might show up again
> > on the next reboot.
> >
> > BTW, it's still not clear to me whether this is about a clean buster
> > install or some image based on buster.
> >
> Its the raspian image based on buster-rc2 AIUI.

So *not* Debian.

Have a nice day.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Sunday 07 July 2019 03:05:41 andreimpope...@gmail.com wrote:

> On Sb, 06 iul 19, 20:30:02, Gene Heskett wrote:
> > Its part of the buster-rc2 installed image,
>
> Is this an image you downloaded from somewhere (where?) or of your own
> creation (what method? Debian Installer, debootstrap, etc.)
>
Downloaded directly from raspian as a zip, expanded with pk7zip and dd'd 
to the u-sd card. Built on 06-20-2019.

> Kind regards,
> Andrei


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Sunday 07 July 2019 02:58:46 andreimpope...@gmail.com wrote:

> On Sb, 06 iul 19, 18:14:04, Gene Heskett wrote:
> > If you read the full thread, you will find where I found and fixed
> > that problem, by killing dhcpd5 with htop, and restarting
> > networking, and the problem was fixed, everything then worked
> > correctly,
>
> Did you ever find out why dhcpcd5 was even starting?
>
> As far as I know DHCP clients start only when called by network
> managing software (ifupdown, network-manager, etc.), or some custom
> networking scripts on your system. In this case it might show up again
> on the next reboot.
>
> BTW, it's still not clear to me whether this is about a clean buster
> install or some image based on buster.
>
Its the raspian image based on buster-rc2 AIUI.
And to get rid of the route poisoning that kills out of local networking 
by making it use a 169.254.0.0/16 address for anything NOT in ones hosts 
file, I have purged avahi-daemon and dhcpdc5 and whatever dependencies 
they take out with them. And it takes a powerdown reboot to flush all 
the poisoning and make it work for out-of-the-local-net addresses.

I have finally achieved an overnight uptime with a working network.

pi@picnc:/var/log $ ip r
default via 192.168.71.1 dev eth0 onlink
192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12

pi@picnc:/etc/apt $ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000
link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::ba27:ebff:fed3:472d/64 scope link
   valid_lft forever preferred_lft forever
3: wlan0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff
and I can
pi@picnc:/etc/apt $ ping -c1 yahoo.com
PING yahoo.com (98.137.246.7) 56(84) bytes of data.
64 bytes from media-router-fp1.prod1.media.vip.gq1.yahoo.com 
(98.137.246.7): icmp_seq=1 ttl=50 time=87.2 ms

--- yahoo.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 87.205/87.205/87.205/0.000 ms

Reinstalling avahi-daemon or dhcpcd5 will poison the routing, making the 
default route a 169.254.0.0/16 address that only gets past the router at 
the dns phase, but the actual ping comes from the 169.254.0.0/16 address 
block, and I am not sure it even gets to the cat6 plugged into the pi, 
but for sure is blocked by the managed switch or the router connected to 
the ARRIS cable modem upstream of the switch.

So it appears I finally have a working network.
But so far, no one has addressed the next problem. I do not have seating 
in any shape in front of the pi's own monitor and keyboard, and my 
standing time w/o excruciating back pain from two crushed disks in my 
back is maybe 15 minutes.  I would take a tall bar stool which there is 
no room for to make the position usable for an hour.

Therefore its imperative that ssh start on a reboot, which it does not do 
now, making me get out of this office chair, make my way to the other 
end of the house and out the back door, then into the garage where this 
pi is, stepping up on a $400 pile of mahogany for a furniture project 
and back off just to get to its workstation and restart ssh.

Then just now I find that synaptic won't run on wayland. So whats the 
substitute for synaptic? Something that will give me something graphical 
in front of apt so that I can see what sources are available.

the next step after making ssh work, is building and installing an 
rt-preempt version of this 4.19.50 kernel since its somewhat aware of 
the newer video drivers that 4.14.91-rt-v7 likely knows nothing about . 
I have tried RealtimePi 4 times now, but its newest kernel is 
4.14.91-rt-v7, which when booted doesn't find the wireless keyboard or 
mouse, nicely rendering it a quadraplegic. Meaning I've no clue if it 
will work even if it did find my keyboard and mouse. That particular 
keyboard nor mouse come in wired versions, and the square sided keys are 
a basic requirement around machinery that throws metal chips as it 
works, the slanted sides of all other keyboards keytop allow the metal 
chips to follow the key down, then wedge the key in the down position, 
an extremely dangerous situation thats cost me the loss of several hours 
work several times and several hundred $ in broken cutting tools.

> Kind regards,
> Andrei

Thank you Andrei 

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must 

Re: Assorted arm-buster problems - network configuration

[Curt]

On 2019-07-06, Lee  wrote:
>
> "an accident waiting to happen" was from me and I also gave the rfc
> for mdns, so that's hardly "nothing of substance to support that

I see. So the totality of the mdns rfc (*somewhat* more succinct than a
19th century Russian novelistic endeavor) is the substantive foundation
of your sound technical argument that avahi and its daemons are "an
accident waiting to happen" (whatever that means exactly, but I fear to
ask because you might refer me to Webster's Unabridged or the L.A. phone
book circa 1974, which would entrain just too much summer reading for
me, friend, as I prefer to do my wading through the sea).


-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Sb, 06 iul 19, 20:30:02, Gene Heskett wrote:
> 
> Its part of the buster-rc2 installed image, 

Is this an image you downloaded from somewhere (where?) or of your own 
creation (what method? Debian Installer, debootstrap, etc.)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Sb, 06 iul 19, 18:14:04, Gene Heskett wrote:
> 
> If you read the full thread, you will find where I found and fixed that 
> problem, by killing dhcpd5 with htop, and restarting networking, and 
> the problem was fixed, everything then worked correctly, 

Did you ever find out why dhcpcd5 was even starting?

As far as I know DHCP clients start only when called by network managing 
software (ifupdown, network-manager, etc.), or some custom networking 
scripts on your system. In this case it might show up again on the next 
reboot.

BTW, it's still not clear to me whether this is about a clean buster 
install or some image based on buster.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Sb, 06 iul 19, 15:36:37, Lee wrote:
> 
> "an accident waiting to happen" was from me and I also gave the rfc
> for mdns, so that's hardly "nothing of substance to support that
> view."  If you're having trouble finding the rfc, it's here
>   https://tools.ietf.org/html/rfc6762

Care to elaborate though?

The dangers are not at all obvious to me, possibly because I haven't 
used it much (if at all).
 
Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Sunday 07 July 2019 00:11:43 David Wright wrote:

> On Sat 06 Jul 2019 at 18:14:04 (-0400), Gene Heskett wrote:
> > On Saturday 06 July 2019 15:35:10 Brian wrote:
> > > On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote:
> > > > On Friday 05 July 2019 15:23:38 Brian wrote:
> > > > > I was rather hoping someone would clarify why not having
> > > > > avahi-daemon in the first place was a good thing in general.
> > > > > Your problem doesn't particularly interest me because it is
> > > > > probably something you have brought on yourself due to
> > > > > previous actions.
> > > > >
> > > > > > Here is your Clarification: I used apt to purge avahi-daemon
> > > > > > which took nsswitch with it,
>
> That was your claim. Then I read the following:
>
>   Greg> Whatever Gene did, it's absolutely not normal or desirable for
>   Greg> nsswitch.conf to vanish.  I still think he deleted it by hand
> and then Greg> forgot the exact sequence of steps which led to its
> disappearance, so Greg> he simply blamed it on purging ahavi-daemon.
>
>   Gene> I didn't say that. If I made that impression I didn't intend
> to. I Gene> removed it by hand about 2 hours back but that u-sd has
> not been Gene> inserted in the pi yet as I'm also the chief cook […]
> Gene> […] recycle the dishwasher. :(
>
>   https://lists.debian.org/debian-user/2019/07/msg00306.html
>
> > > > > I stopped reading there. I am not into fantasy.
> > > >
> > > > Which proves another theorem of mine. Folks with a sheepskin on
> > > > the office wall stop learning, and by your stopping without
> > > > reading the explanation is evidence of that effect. I can lead
> > > > you to the facts, but
> > >
> > > Your first "fact" is demonstrably incorrect and has been shown to
> > > be so. Indeed, you seem to have backed away from your claim that
> > > avahi-daemon is the cause of your difficulties. The only place you
> > > lead people is up the misleading garden path. A clear statement of
> > > what you did and what happened is more likely to bring results;
> > > making attacking software a lifestyle choice gets a bit boring
> > > after a while.
> > >
> > > > like the horse refusing to drink when led to water, I'll drop
> > > > the reins. You may, or may not drink the water of knowledge. I
> > > > can't control that.
> > >
> > > Is this an attempt at some self-promotion as the fount of
> > > knowledge? I never thought I would live to see the day!
> >
> > If you read the full thread, you will find where I found and fixed
> > that problem, by killing dhcpd5 with htop, and restarting
> > networking, and the problem was fixed, everything then worked
> > correctly, but I have not reinstalled avahi-daemon to see if it
> > returns.  Perhaps I should because it appears there were 2 sources
> > of that trash.
>
> Perhaps you mean dhcpcd5? I thought you said that you're "the last one
> on the planet using hosts files and no dhcpd's of any kind".
>
That last as a qualifier was a bad reference too, as I now see the name 
of that function having been changed sometime in the last 20 years.

> If you were running this, did you try using the -L or --noipv4ll
> option?

No, and whereintunket would I find that in reference to my problem?>

> > Yes, I purged what was left as it wouldn't reinstall, then
> > reinstalled avahi-daemon.  results:
> >
> > With avahi-daemon running. the trash in the ip a report was back
> > after a networking restart, BUT allthough it showed in an ip r
> > report with a metric of 202, I could still ping yahoo.com. I could
> > not before.
> >
> > So I service avahi-daemon stopped it, and restarted the networking,
> > trash 169.254 junk gone. An yahoo.com still pinged.
> >
> > So I've purged it again.  And restarted the networking yet again.
> > ip a:
> > pi@picnc:~ $ ip a
> > 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> > group default qlen 1000
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > inet 127.0.0.1/8 scope host lo
> >valid_lft forever preferred_lft forever
> > inet6 ::1/128 scope host
> >valid_lft forever preferred_lft forever
> > 2: eth0:  mtu 1500 qdisc pfifo_fast
> > state UP group default qlen 1000
> > link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
> > inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
> >valid_lft forever preferred_lft forever
> > inet6 fe80::8815:60eb:fe0a:d5bc/64 scope link
> >valid_lft forever preferred_lft forever
> > 3: wlan0:  mtu 1500 qdisc
> > pfifo_fast state DOWN group default qlen 1000
> > link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff
> >
> > ip r:
> > pi@picnc:~ $ ip r
> > default via 192.168.71.1 dev eth0 onlink
> > 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12
>
> That looks very like what I posted, except for "onlink"; also I'm
> connected by wireless rather than wire. But myps -ef   listing
> and nsswitch.conf file show:
> $ ps -ef | grep avahi | grep -v grep ; grep hosts 

Re: Assorted arm-buster problems - network configuration

[David Wright]

On Sat 06 Jul 2019 at 21:38:10 (-0400), Gene Heskett wrote:
> On Saturday 06 July 2019 20:30:02 Gene Heskett wrote:
> > On Saturday 06 July 2019 12:02:51 David Wright wrote:
> > > On Fri 05 Jul 2019 at 21:19:29 (-0400), Gene Heskett wrote:
> > > > On Friday 05 July 2019 12:08:45 David Wright wrote:
> > > > > On Fri 05 Jul 2019 at 06:06:30 (-0400), Gene Heskett wrote:
> > > > > > On Thursday 04 July 2019 16:48:56 andreimpope...@gmail.com wrote:
> > > > > > > On Jo, 04 iul 19, 11:40:30, Gene Heskett wrote:
> > > > > > > > > 1. content of /etc/network/interfaces and all files
> > > > > > > > > under /etc/network/interfaces.d/
> > > > > > > >
> > > > > > > > pi@picnc:~ $ cat /etc/network/interfaces.d/*
> > > > > > >
> > > > > > > Is below the literal output of the cat above?
> > > > > > >
> > > > > > > Please post also /etc/network/interfaces.
> > > > > > >
> > > > > > > > auto eth0
> > > > > > > >
> > > > > > > > iface eth0 inet static
> > > > > > > > address 192.168.71.12/24
> > > > > > > > gateway 192.168.71.1
> > > > > > > > post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> > > > > > > >
> > > > > > > > Which the last line disables ipv6  on this machines mostly
> > > > > > > > stretch install.
> > > > > > >
> > > > > > > It doesn't, but IPv6 is not your problem anyway.
> > > > >
> > > > > […]
> > > > >
> > > > > > > In addition to the full /etc/network/interfaces please post
> > > > > > > also the output of
> > > > > >
> > > > > > Its unmodified, and contains only the line to source whatever
> > > > > > may be in the interfaces.d directory.
> > > > >
> > > > > Technically, that just doesn't cut it, and I'm not sure what
> > > > > makes you coy about posting them. Which files get used depends
> > > > > on how the source line is expressed (source/source-directory),
> > > > > and then on what the filenames are for the files which you cat'd
> > > > > with * (that have to match a filename pattern).
> > > > >
> > > > > On Debian, it's normal for the d-i to write (and sometimes
> > > > > unwrite) the /e/n/i file. But what gets written depends on the
> > > > > installation method. But it's not even clear that you used the
> > > > > d-i to install your system, if I've followed the thrread
> > > > > correctly.
> > > >
> > > > d-i? Define please so we're both on the same jargon page.
> > >
> > > Sorry, I thought you were familiar with these terms, which I see we
> > > were conversing with years ago. d-i Debian installer, /e/n/i
> > > /etc/network/interfaces.
> > >
> > > > And yes, until
> > > > N-M was sufficiently house broken & trained to leave a static
> > > > setup alone, and it had so many dependencies you could only neuter
> > > > it by a chatttr +i on the stuff you didn't want it editing. Or
> > > > find it and use the F8 key in mc.  Six of one, half a dozen of the
> > > > other as later as wheezy.
> > >
> > > I've read enough of this to know that it's not worth treating
> > > seriously. Over the years you've frequently posted (and reposted)
> > > malformed configuration files which you defend vehemently.
> > >
> > > > > As I've said, though, I'll go no further in looking at the
> > > > > problems you have because I think that many of them are of your
> > > > > own making.
> > > >
> > > > Thats also true, simply because I'm the last one on the planet
> > > > using hosts files and no dhcpd's of any kind.
> > >
> > > "I'm the last one …" might be true, but there's no evidence for your
> > > writing "because".
> > >
> > > > So no one has answered me with a
> > > > howto to get rid of all the 169.254.xx.xx bull shit in my network
> > > > configs that stopped it from working.  I turned out, after I had
> > > > removed ALL the avahi sources, it was still there, so I next
> > > > killed dhcp, no effect, but it all disappeared when I removed
> > > > dhcpd5, that stopped all the poisoning of my network configs.
> > > >
> > > > IMO having a dhcpd5 invent bogus numbers when there is not an
> > > > accessable server, is both a huge security hole that could be
> > > > exploited, and grounds for 30 lashes useing a cat-o-9-tails made
> > > > out of wet noodles being applied to whoever thought it was a good
> > > > idea. It was, IMNSHO, a very very bad idea.
> > >
> > > I don't really have much idea of what you're talking about, except
> > > to ask why, if you don't like DHCP and claim not to be runnning it
> > > (above), you installed all this stuff (on picnic, I assume). What
> > > was it there for?
> >
> > Its part of the buster-rc2 installed image, and I just now found that
> > even with that stuff removed, something times out and restores the
> > bogus default route, screwing up what 30 seconds before was a works
> > perfectly network, but the default route has, without me doing
> > anything but running ip r, has reset the default route to
> > 169.254.0.0/16 with a metric (which I'm told is a priority) of 202,
> > which wins the battle since the default metric is 1024. So now my
> > network is again unusable 

Re: Assorted arm-buster problems - network configuration

[David Wright]

On Sat 06 Jul 2019 at 18:14:04 (-0400), Gene Heskett wrote:
> On Saturday 06 July 2019 15:35:10 Brian wrote:
> > On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote:
> > > On Friday 05 July 2019 15:23:38 Brian wrote:
> > > > I was rather hoping someone would clarify why not having
> > > > avahi-daemon in the first place was a good thing in general. Your
> > > > problem doesn't particularly interest me because it is probably
> > > > something you have brought on yourself due to previous actions.
> > > >
> > > > > Here is your Clarification: I used apt to purge avahi-daemon
> > > > > which took nsswitch with it,

That was your claim. Then I read the following:

  Greg> Whatever Gene did, it's absolutely not normal or desirable for
  Greg> nsswitch.conf to vanish.  I still think he deleted it by hand and then
  Greg> forgot the exact sequence of steps which led to its disappearance, so
  Greg> he simply blamed it on purging ahavi-daemon.

  Gene> I didn't say that. If I made that impression I didn't intend to. I
  Gene> removed it by hand about 2 hours back but that u-sd has not been
  Gene> inserted in the pi yet as I'm also the chief cook […]
  Gene> […] recycle the dishwasher. :(

  https://lists.debian.org/debian-user/2019/07/msg00306.html

> > > > I stopped reading there. I am not into fantasy.
> > >
> > > Which proves another theorem of mine. Folks with a sheepskin on the
> > > office wall stop learning, and by your stopping without reading the
> > > explanation is evidence of that effect. I can lead you to the facts,
> > > but
> >
> > Your first "fact" is demonstrably incorrect and has been shown to be
> > so. Indeed, you seem to have backed away from your claim that
> > avahi-daemon is the cause of your difficulties. The only place you
> > lead people is up the misleading garden path. A clear statement of
> > what you did and what happened is more likely to bring results; making
> > attacking software a lifestyle choice gets a bit boring after a while.
> >
> > > like the horse refusing to drink when led to water, I'll drop the
> > > reins. You may, or may not drink the water of knowledge. I can't
> > > control that.
> >
> > Is this an attempt at some self-promotion as the fount of knowledge?
> > I never thought I would live to see the day!
> 
> If you read the full thread, you will find where I found and fixed that 
> problem, by killing dhcpd5 with htop, and restarting networking, and the 
> problem was fixed, everything then worked correctly, but I have not 
> reinstalled avahi-daemon to see if it returns.  Perhaps I should because 
> it appears there were 2 sources of that trash.

Perhaps you mean dhcpcd5? I thought you said that you're "the last one
on the planet using hosts files and no dhcpd's of any kind".

If you were running this, did you try using the -L or --noipv4ll option?

> Yes, I purged what was left as it wouldn't reinstall, then reinstalled 
> avahi-daemon.  results:
> 
> With avahi-daemon running. the trash in the ip a report was back after a 
> networking restart, BUT allthough it showed in an ip r report with a 
> metric of 202, I could still ping yahoo.com. I could not before.
> 
> So I service avahi-daemon stopped it, and restarted the networking, trash 
> 169.254 junk gone. An yahoo.com still pinged.
> 
> So I've purged it again.  And restarted the networking yet again.
> ip a:
> pi@picnc:~ $ ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
> default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast 
> state UP group default qlen 1000
> link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
> inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
>valid_lft forever preferred_lft forever
> inet6 fe80::8815:60eb:fe0a:d5bc/64 scope link
>valid_lft forever preferred_lft forever
> 3: wlan0:  mtu 1500 qdisc pfifo_fast 
> state DOWN group default qlen 1000
> link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff
> 
> ip r:
> pi@picnc:~ $ ip r
> default via 192.168.71.1 dev eth0 onlink
> 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12

That looks very like what I posted, except for "onlink"; also I'm
connected by wireless rather than wire. But myps -ef   listing
and nsswitch.conf file show:
$ ps -ef | grep avahi | grep -v grep ; grep hosts /etc/nsswitch.conf
avahi  653 1  0 21:23 ?00:00:00 avahi-daemon: running 
[wren.local]
avahi  666   653  0 21:23 ?00:00:00 avahi-daemon: chroot helper
hosts:  files mdns4_minimal [NOTFOUND=return] dns
$ 

> So I now have a working network. Free of the bogus inventions of dhcpd5 
> and avahi.  That _was_ the point of all this hoopla in the first place.
> 
> Now, I have learned what works to _my_ satisfaction.

Glad to hear it. I 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Saturday 06 July 2019 20:30:02 Gene Heskett wrote:

> On Saturday 06 July 2019 12:02:51 David Wright wrote:
> > On Fri 05 Jul 2019 at 21:19:29 (-0400), Gene Heskett wrote:
> > > On Friday 05 July 2019 12:08:45 David Wright wrote:
> > > > On Fri 05 Jul 2019 at 06:06:30 (-0400), Gene Heskett wrote:
> > > > > On Thursday 04 July 2019 16:48:56 andreimpope...@gmail.com 
wrote:
> > > > > > On Jo, 04 iul 19, 11:40:30, Gene Heskett wrote:
> > > > > > > > 1. content of /etc/network/interfaces and all files
> > > > > > > > under /etc/network/interfaces.d/
> > > > > > >
> > > > > > > pi@picnc:~ $ cat /etc/network/interfaces.d/*
> > > > > >
> > > > > > Is below the literal output of the cat above?
> > > > > >
> > > > > > Please post also /etc/network/interfaces.
> > > > > >
> > > > > > > auto eth0
> > > > > > >
> > > > > > > iface eth0 inet static
> > > > > > > address 192.168.71.12/24
> > > > > > > gateway 192.168.71.1
> > > > > > > post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> > > > > > >
> > > > > > > Which the last line disables ipv6  on this machines mostly
> > > > > > > stretch install.
> > > > > >
> > > > > > It doesn't, but IPv6 is not your problem anyway.
> > > >
> > > > […]
> > > >
> > > > > > In addition to the full /etc/network/interfaces please post
> > > > > > also the output of
> > > > >
> > > > > Its unmodified, and contains only the line to source whatever
> > > > > may be in the interfaces.d directory.
> > > >
> > > > Technically, that just doesn't cut it, and I'm not sure what
> > > > makes you coy about posting them. Which files get used depends
> > > > on how the source line is expressed (source/source-directory),
> > > > and then on what the filenames are for the files which you cat'd
> > > > with * (that have to match a filename pattern).
> > > >
> > > > On Debian, it's normal for the d-i to write (and sometimes
> > > > unwrite) the /e/n/i file. But what gets written depends on the
> > > > installation method. But it's not even clear that you used the
> > > > d-i to install your system, if I've followed the thrread
> > > > correctly.
> > >
> > > d-i? Define please so we're both on the same jargon page.
> >
> > Sorry, I thought you were familiar with these terms, which I see we
> > were conversing with years ago. d-i Debian installer, /e/n/i
> > /etc/network/interfaces.
> >
> > > And yes, until
> > > N-M was sufficiently house broken & trained to leave a static
> > > setup alone, and it had so many dependencies you could only neuter
> > > it by a chatttr +i on the stuff you didn't want it editing. Or
> > > find it and use the F8 key in mc.  Six of one, half a dozen of the
> > > other as later as wheezy.
> >
> > I've read enough of this to know that it's not worth treating
> > seriously. Over the years you've frequently posted (and reposted)
> > malformed configuration files which you defend vehemently.
> >
> > > > As I've said, though, I'll go no further in looking at the
> > > > problems you have because I think that many of them are of your
> > > > own making.
> > >
> > > Thats also true, simply because I'm the last one on the planet
> > > using hosts files and no dhcpd's of any kind.
> >
> > "I'm the last one …" might be true, but there's no evidence for your
> > writing "because".
> >
> > > So no one has answered me with a
> > > howto to get rid of all the 169.254.xx.xx bull shit in my network
> > > configs that stopped it from working.  I turned out, after I had
> > > removed ALL the avahi sources, it was still there, so I next
> > > killed dhcp, no effect, but it all disappeared when I removed
> > > dhcpd5, that stopped all the poisoning of my network configs.
> > >
> > > IMO having a dhcpd5 invent bogus numbers when there is not an
> > > accessable server, is both a huge security hole that could be
> > > exploited, and grounds for 30 lashes useing a cat-o-9-tails made
> > > out of wet noodles being applied to whoever thought it was a good
> > > idea. It was, IMNSHO, a very very bad idea.
> >
> > I don't really have much idea of what you're talking about, except
> > to ask why, if you don't like DHCP and claim not to be runnning it
> > (above), you installed all this stuff (on picnic, I assume). What
> > was it there for?
>
> Its part of the buster-rc2 installed image, and I just now found that
> even with that stuff removed, something times out and restores the
> bogus default route, screwing up what 30 seconds before was a works
> perfectly network, but the default route has, without me doing
> anything but running ip r, has reset the default route to
> 169.254.0.0/16 with a metric (which I'm told is a priority) of 202,
> which wins the battle since the default metric is 1024. So now my
> network is again unusable because anything out of the 192.168.71.00/24
> block does not get thru the router to actually access the internet at
> large.
>
> So my next question is: what the hell is discovering that 169.254 bull
> shit is missing, and automatically re-adding it to the 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Saturday 06 July 2019 12:02:51 David Wright wrote:

> On Fri 05 Jul 2019 at 21:19:29 (-0400), Gene Heskett wrote:
> > On Friday 05 July 2019 12:08:45 David Wright wrote:
> > > On Fri 05 Jul 2019 at 06:06:30 (-0400), Gene Heskett wrote:
> > > > On Thursday 04 July 2019 16:48:56 andreimpope...@gmail.com wrote:
> > > > > On Jo, 04 iul 19, 11:40:30, Gene Heskett wrote:
> > > > > > > 1. content of /etc/network/interfaces and all files under
> > > > > > > /etc/network/interfaces.d/
> > > > > >
> > > > > > pi@picnc:~ $ cat /etc/network/interfaces.d/*
> > > > >
> > > > > Is below the literal output of the cat above?
> > > > >
> > > > > Please post also /etc/network/interfaces.
> > > > >
> > > > > > auto eth0
> > > > > >
> > > > > > iface eth0 inet static
> > > > > > address 192.168.71.12/24
> > > > > > gateway 192.168.71.1
> > > > > > post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> > > > > >
> > > > > > Which the last line disables ipv6  on this machines mostly
> > > > > > stretch install.
> > > > >
> > > > > It doesn't, but IPv6 is not your problem anyway.
> > >
> > > […]
> > >
> > > > > In addition to the full /etc/network/interfaces please post
> > > > > also the output of
> > > >
> > > > Its unmodified, and contains only the line to source whatever
> > > > may be in the interfaces.d directory.
> > >
> > > Technically, that just doesn't cut it, and I'm not sure what makes
> > > you coy about posting them. Which files get used depends on how
> > > the source line is expressed (source/source-directory), and then
> > > on what the filenames are for the files which you cat'd with *
> > > (that have to match a filename pattern).
> > >
> > > On Debian, it's normal for the d-i to write (and sometimes
> > > unwrite) the /e/n/i file. But what gets written depends on the
> > > installation method. But it's not even clear that you used the d-i
> > > to install your system, if I've followed the thrread correctly.
> >
> > d-i? Define please so we're both on the same jargon page.
>
> Sorry, I thought you were familiar with these terms, which I see we
> were conversing with years ago. d-i Debian installer, /e/n/i
> /etc/network/interfaces.
>
> > And yes, until
> > N-M was sufficiently house broken & trained to leave a static setup
> > alone, and it had so many dependencies you could only neuter it by a
> > chatttr +i on the stuff you didn't want it editing. Or find it and
> > use the F8 key in mc.  Six of one, half a dozen of the other as
> > later as wheezy.
>
> I've read enough of this to know that it's not worth treating
> seriously. Over the years you've frequently posted (and reposted)
> malformed configuration files which you defend vehemently.
>
> > > As I've said, though, I'll go no further in looking at the
> > > problems you have because I think that many of them are of your
> > > own making.
> >
> > Thats also true, simply because I'm the last one on the planet using
> > hosts files and no dhcpd's of any kind.
>
> "I'm the last one …" might be true, but there's no evidence for your
> writing "because".
>
> > So no one has answered me with a
> > howto to get rid of all the 169.254.xx.xx bull shit in my network
> > configs that stopped it from working.  I turned out, after I had
> > removed ALL the avahi sources, it was still there, so I next killed
> > dhcp, no effect, but it all disappeared when I removed dhcpd5, that
> > stopped all the poisoning of my network configs.
> >
> > IMO having a dhcpd5 invent bogus numbers when there is not an
> > accessable server, is both a huge security hole that could be
> > exploited, and grounds for 30 lashes useing a cat-o-9-tails made out
> > of wet noodles being applied to whoever thought it was a good idea. 
> > It was, IMNSHO, a very very bad idea.
>
> I don't really have much idea of what you're talking about, except to
> ask why, if you don't like DHCP and claim not to be runnning it
> (above), you installed all this stuff (on picnic, I assume). What was
> it there for?
>
Its part of the buster-rc2 installed image, and I just now found that 
even with that stuff removed, something times out and restores the bogus 
default route, screwing up what 30 seconds before was a works perfectly 
network, but the default route has, without me doing anything but 
running ip r, has reset the default route to 169.254.0.0/16 with a 
metric (which I'm told is a priority) of 202, which wins the battle 
since the default metric is 1024. So now my network is again unusable 
because anything out of the 192.168.71.00/24 block does not get thru the 
router to actually access the internet at large.

So my next question is: what the hell is discovering that 169.254 bull 
shit is missing, and automatically re-adding it to the routing?  I've 
killed it with ip route del 169.254.0.0/16 dev eth0, restarted the 
networking, run ip r to see its clean, rerun ip r 30 seconds later and 
in been restored again and my network is dead again.

Thats a long question but I'm hoping the answer is 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Saturday 06 July 2019 15:35:10 Brian wrote:

> On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote:
> > On Friday 05 July 2019 15:23:38 Brian wrote:
> > > I was rather hoping someone would clarify why not having
> > > avahi-daemon in the first place was a good thing in general. Your
> > > problem doesn't particularly interest me because it is probably
> > > something you have brought on yourself due to previous actions.
> > >
> > > > Here is your Clarification: I used apt to purge avahi-daemon
> > > > which took nsswitch with it,
> > >
> > > I stopped reading there. I am not into fantasy.
> >
> > Which proves another theorem of mine. Folks with a sheepskin on the
> > office wall stop learning, and by your stopping without reading the
> > explanation is evidence of that effect. I can lead you to the facts,
> > but
>
> Your first "fact" is demonstrably incorrect and has been shown to be
> so. Indeed, you seem to have backed away from your claim that
> avahi-daemon is the cause of your difficulties. The only place you
> lead people is up the misleading garden path. A clear statement of
> what you did and what happened is more likely to bring results; making
> attacking software a lifestyle choice gets a bit boring after a while.
>
> > like the horse refusing to drink when led to water, I'll drop the
> > reins. You may, or may not drink the water of knowledge. I can't
> > control that.
>
> Is this an attempt at some self-promotion as the fount of knowledge?
> I never thought I would live to see the day!

If you read the full thread, you will find where I found and fixed that 
problem, by killing dhcpd5 with htop, and restarting networking, and the 
problem was fixed, everything then worked correctly, but I have not 
reinstalled avahi-daemon to see if it returns.  Perhaps I should because 
it appears there were 2 sources of that trash.

Yes, I purged what was left as it wouldn't reinstall, then reinstalled 
avahi-daemon.  results:

With avahi-daemon running. the trash in the ip a report was back after a 
networking restart, BUT allthough it showed in an ip r report with a 
metric of 202, I could still ping yahoo.com. I could not before.

So I service avahi-daemon stopped it, and restarted the networking, trash 
169.254 junk gone. An yahoo.com still pinged.

So I've purged it again.  And restarted the networking yet again.
ip a:
pi@picnc:~ $ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000
link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::8815:60eb:fe0a:d5bc/64 scope link
   valid_lft forever preferred_lft forever
3: wlan0:  mtu 1500 qdisc pfifo_fast 
state DOWN group default qlen 1000
link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff

ip r:
pi@picnc:~ $ ip r
default via 192.168.71.1 dev eth0 onlink
192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12

So I now have a working network. Free of the bogus inventions of dhcpd5 
and avahi.  That _was_ the point of all this hoopla in the first place.

Now, I have learned what works to _my_ satisfaction.

Have you? Or did you quit reading the instant I went off the edge of your 
menu?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/6/19, Curt  wrote:
> On 2019-07-05,   wrote:
>>
>> On Fri, Jul 05, 2019 at 09:27:29PM +0100, Brian wrote:
>>
>> [...]
>>
>>> Some users are always fearful of new technology. They find all sorts of
>>> ways to rubbish it, usually without any strong technical grounds but by
>>> an appeal to tradition and emotion.
>>
>> Some other people always try to skirt a sound technical argument by
>> reducing dissenting standpoints to psychological "reasons", e.g.
>> "resistance to change".
>
> You've offered no sound technical arguments whatsoever against avahi
> that I have seen.  In fact, you often seem to find it quite irresistible
> to pipe up with the fuzziest stuff at the fuzziest moments (like
> expressing for the umpteenth time here your OT detestation of Google et.
> al. and the vast conspiracy you believe is behind them all).
>
> The part you snipped above I believe opined that avahi was "an accident
> waiting to happen" with nothing of substance to support that view. Is
> that your idea of sound argumentation?

"an accident waiting to happen" was from me and I also gave the rfc
for mdns, so that's hardly "nothing of substance to support that
view."  If you're having trouble finding the rfc, it's here
  https://tools.ietf.org/html/rfc6762

I have a dns server, so I don't need "the ability to perform DNS-like
operations on the local link in the absence of any conventional
Unicast DNS server."  Others might need that ability and so their
risk/reward answer will be different than mine.

In any case, you have a link to the rfc now and can make your own
informed decision.

Regards,
Lee

Re: Assorted arm-buster problems - network configuration

[Brian]

On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote:

> On Friday 05 July 2019 15:23:38 Brian wrote:
> 
> > I was rather hoping someone would clarify why not having avahi-daemon
> > in the first place was a good thing in general. Your problem doesn't
> > particularly interest me because it is probably something you have
> > brought on yourself due to previous actions.
> >
> > > Here is your Clarification: I used apt to purge avahi-daemon which
> > > took nsswitch with it,
> >
> > I stopped reading there. I am not into fantasy.
> 
> Which proves another theorem of mine. Folks with a sheepskin on the 
> office wall stop learning, and by your stopping without reading the 
> explanation is evidence of that effect. I can lead you to the facts, but

Your first "fact" is demonstrably incorrect and has been shown to be so.
Indeed, you seem to have backed away from your claim that avahi-daemon
is the cause of your difficulties. The only place you lead people is up
the misleading garden path. A clear statement of what you did and what
happened is more likely to bring results; making attacking software a
lifestyle choice gets a bit boring after a while.
 
> like the horse refusing to drink when led to water, I'll drop the reins.  
> You may, or may not drink the water of knowledge. I can't control that.

Is this an attempt at some self-promotion as the fount of knowledge?
I never thought I would live to see the day!

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[David Wright]

On Fri 05 Jul 2019 at 21:19:29 (-0400), Gene Heskett wrote:
> On Friday 05 July 2019 12:08:45 David Wright wrote:
> > On Fri 05 Jul 2019 at 06:06:30 (-0400), Gene Heskett wrote:
> > > On Thursday 04 July 2019 16:48:56 andreimpope...@gmail.com wrote:
> > > > On Jo, 04 iul 19, 11:40:30, Gene Heskett wrote:
> > > > > > 1. content of /etc/network/interfaces and all files under
> > > > > > /etc/network/interfaces.d/
> > > > >
> > > > > pi@picnc:~ $ cat /etc/network/interfaces.d/*
> > > >
> > > > Is below the literal output of the cat above?
> > > >
> > > > Please post also /etc/network/interfaces.
> > > >
> > > > > auto eth0
> > > > >
> > > > > iface eth0 inet static
> > > > > address 192.168.71.12/24
> > > > > gateway 192.168.71.1
> > > > > post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> > > > >
> > > > > Which the last line disables ipv6  on this machines mostly
> > > > > stretch install.
> > > >
> > > > It doesn't, but IPv6 is not your problem anyway.
> >
> > […]
> >
> > > > In addition to the full /etc/network/interfaces please post also
> > > > the output of
> > >
> > > Its unmodified, and contains only the line to source whatever may be
> > > in the interfaces.d directory.
> >
> > Technically, that just doesn't cut it, and I'm not sure what makes you
> > coy about posting them. Which files get used depends on how the source
> > line is expressed (source/source-directory), and then on what the
> > filenames are for the files which you cat'd with * (that have to match
> > a filename pattern).
> >
> > On Debian, it's normal for the d-i to write (and sometimes unwrite)
> > the /e/n/i file. But what gets written depends on the installation
> > method. But it's not even clear that you used the d-i to install your
> > system, if I've followed the thrread correctly.
> >
> d-i? Define please so we're both on the same jargon page.

Sorry, I thought you were familiar with these terms, which I see we
were conversing with years ago. d-i Debian installer, /e/n/i
/etc/network/interfaces.

> And yes, until 
> N-M was sufficiently house broken & trained to leave a static setup 
> alone, and it had so many dependencies you could only neuter it by a 
> chatttr +i on the stuff you didn't want it editing. Or find it and use 
> the F8 key in mc.  Six of one, half a dozen of the other as later as 
> wheezy.

I've read enough of this to know that it's not worth treating seriously.
Over the years you've frequently posted (and reposted) malformed
configuration files which you defend vehemently.

> > As I've said, though, I'll go no further in looking at the problems
> > you have because I think that many of them are of your own making.
> 
> Thats also true, simply because I'm the last one on the planet using 
> hosts files and no dhcpd's of any kind.

"I'm the last one …" might be true, but there's no evidence for your
writing "because".

> So no one has answered me with a 
> howto to get rid of all the 169.254.xx.xx bull shit in my network 
> configs that stopped it from working.  I turned out, after I had removed 
> ALL the avahi sources, it was still there, so I next killed dhcp, no 
> effect, but it all disappeared when I removed dhcpd5, that stopped all 
> the poisoning of my network configs.
> 
> IMO having a dhcpd5 invent bogus numbers when there is not an accessable 
> server, is both a huge security hole that could be exploited, and 
> grounds for 30 lashes useing a cat-o-9-tails made out of wet noodles 
> being applied to whoever thought it was a good idea.  It was, IMNSHO, a 
> very very bad idea.

I don't really have much idea of what you're talking about, except to
ask why, if you don't like DHCP and claim not to be runnning it (above),
you installed all this stuff (on picnic, I assume). What was it there for?

Here's the (mangled) output from this PC:

$ dpkg -l | grep avahi
ii avahi-autoipd  0.6.32-2 amd64 Avahi IPv4LL network address 
configuration daemon
ii avahi-daemon   0.6.32-2 amd64 Avahi mDNS/DNS-SD daemon
ii avahi-discover 0.6.32-2 all   Service discover user interface 
for avahi
ii avahi-utils0.6.32-2 amd64 Avahi browsing, publishing and 
discovery utilities
ii libavahi-client3:amd64 0.6.32-2 amd64 Avahi client library
ii libavahi-common-data:amd64 0.6.32-2 amd64 Avahi common data files
ii libavahi-common3:amd64 0.6.32-2 amd64 Avahi common library
ii libavahi-core7:amd64   0.6.32-2 amd64 Avahi's embeddable mDNS/DNS-SD 
library
ii libavahi-glib1:amd64   0.6.32-2 amd64 Avahi GLib integration library
ii python-avahi   0.6.32-2 amd64 Python utility package for Avahi
$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp1s0:  mtu 1500 qdisc pfifo_fast state 
DOWN group default qlen 

Re: Assorted arm-buster problems - network configuration

[David Wright]

On Fri 05 Jul 2019 at 20:10:42 (-0400), Gene Heskett wrote:
> On Friday 05 July 2019 08:41:47 Greg Wooledge wrote:
> > On Fri, Jul 05, 2019 at 06:35:53AM -0400, Gene Heskett wrote:
> > > yup, and if the repos were open...  They are not as I've previously
> > > posted. I can report that apt --purge does not, I still see
> > > an /etc/nsswitch.conf, even though ts been purged.
> >
> > ... what.
> >
> > Gene, /etc/nsswitch.conf is NOT part of any Debian package.  It's part
> > of the core installation.  It is absolutely fundamental to the
> > operation of basically every single piece of the operating system
> > above the boot loader, the kernel, the ld.so shared library loader,
> > and libc.
> 
> IOW, the image I have in my pocket probably don't work until I locate a 
> copy and put it back in. But just for grins, check the buster its 
> running:  yes, its still there and I think intact:
> gene@shop:~$ cat /etc/nsswitch.conf
> # /etc/nsswitch.conf
> #
> # Example configuration of GNU Name Service Switch functionality.
> # If you have the `glibc-doc-reference' and `info' packages installed, 
> try:
> # `info libc "Name Service Switch"' for information about this file.
> 
> passwd: compat
> group:  compat
> shadow: compat
> 
> hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
> networks:   files
> 
> protocols:  db files
> services:   db files
> ethers: db files
> rpc:db files
> 
> netgroup:   nis
> 
> But that begs another question Greg.  If it hasn't anything to do with 
> avahi-daemon, whyinhell did purging avahi-daemon take the libnsswitch 
> package with it?
> 
> > If you remove /etc/nsswitch.conf, you won't be able to look up user
> > names, or service port names, or host names, or basically *any* kind
> > of names of anything at all.  (Or, at best, you'll get some sort of
> > default behavior compiled into the C library routines, if any.)
> >
> > wooledg:~$ dpkg -S /etc/nsswitch.conf
> > dpkg-query: no path found matching pattern /etc/nsswitch.conf
> >
> > Since nsswitch.conf isn't part of a package, there is absolutely no
> > reason you should think that purging ANY package would remove it.  And
> > there is absolutely no reason you should *want* to remove it.
> 
> The only reason I removed it, was to complete the libnsswitch removal 
> that removing avahi-daemon took out. Somehow I am missing an actual 
> dependency of one on the other.  Call me puzzled. 

I'm puzzled too. Can you tell us which package you're talking about as
I can only find:

Package lib32nss-mdns
Package libnss3
Package libnss3-1d
Package libnss3-dbg
Package libnss3-dbgsym
Package libnss3-dev
Package libnss3-tools
Package libnss3-tools-dbgsym
Package libnss-cache
Package libnss-cache-dbgsym
Package libnss-db
Package libnss-db-dbgsym
Package libnss-dns-udeb
Package libnss-docker
Package libnss-docker-dbgsym
Package libnss-extrausers
Package libnss-extrausers-dbgsym
Package libnss-files-udeb
Package libnss-gw-name
Package libnss-gw-name-dbgsym
Package libnss-ldap
Package libnss-ldapd
Package libnss-ldap-dbgsym
Package libnss-ldapd-dbgsym
Package libnss-libvirt
Package libnss-libvirt-dbgsym
Package libnss-lwres
Package libnss-lwres-dbgsym
Package libnss-mdns
Package libnss-mdns-dbgsym
Package libnss-mdns-i386
Package libnss-myhostname
Package libnss-myhostname-dbgsym
Package libnss-mymachines
Package libnss-mymachines-dbgsym
Package libnss-mysql-bg
Package libnss-pgsql2
Package libnss-pgsql2-dbgsym
Package libnss-rainbow2
Package libnss-rainbow2-dbgsym
Package libnss-resolve
Package libnss-resolve-dbgsym
Package libnss-securepass
Package libnss-securepass-dbgsym
Package libnss-sss
Package libnss-sss-dbgsym
Package libnss-systemd
Package libnss-systemd-dbgsym
Package libnss-unknown
Package libnss-unknown-dbgsym
Package libnss-winbind
Package libnss-winbind-dbgsym
Package libnss-wrapper
Package libnss-wrapper-dbgsym
Package libpam-ccreds
Package libpam-ldap
Package nslcd
Package nsscache
Package nss-passwords
Package nss-updatedb
Package pynslcd
Package winbind

Cheers,
David.

Re: Assorted arm-buster problems - network configuration

[tomas]

On Sat, Jul 06, 2019 at 08:13:03AM -, Curt wrote:
> On 2019-07-05,   wrote:
> >
> > On Fri, Jul 05, 2019 at 09:27:29PM +0100, Brian wrote:
> >
> > [...]
> >
> >> Some users are always fearful of new technology. They find all sorts of
> >> ways to rubbish it, usually without any strong technical grounds but by
> >> an appeal to tradition and emotion.
> >
> > Some other people always try to skirt a sound technical argument by
> > reducing dissenting standpoints to psychological "reasons", e.g.
> > "resistance to change".
> 
> You've offered no sound technical arguments whatsoever against avahi
> that I have seen.  In fact, you often seem to find it quite irresistible
> to pipe up with the fuzziest stuff at the fuzziest moments (like
> expressing for the umpteenth time here your OT detestation of Google et.
> al. and the vast conspiracy you believe is behind them all). 

Meh.

I have my reasons to avoid Avahi. Among other things, as a sysadmin,
the last thing I want is lots of entities in my network broadcasting
"Hey, I'm a database: wanna play with me?".

But that wasn't my point, was it?

Cheers
-- t


signature.asc
Description: Digital signature

Re: Assorted arm-buster problems - network configuration

[Curt]

On 2019-07-05,   wrote:
>
> On Fri, Jul 05, 2019 at 09:27:29PM +0100, Brian wrote:
>
> [...]
>
>> Some users are always fearful of new technology. They find all sorts of
>> ways to rubbish it, usually without any strong technical grounds but by
>> an appeal to tradition and emotion.
>
> Some other people always try to skirt a sound technical argument by
> reducing dissenting standpoints to psychological "reasons", e.g.
> "resistance to change".

You've offered no sound technical arguments whatsoever against avahi
that I have seen.  In fact, you often seem to find it quite irresistible
to pipe up with the fuzziest stuff at the fuzziest moments (like
expressing for the umpteenth time here your OT detestation of Google et.
al. and the vast conspiracy you believe is behind them all). 

The part you snipped above I believe opined that avahi was "an accident
waiting to happen" with nothing of substance to support that view. Is
that your idea of sound argumentation?

-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Vi, 05 iul 19, 06:35:53, Gene Heskett wrote:
> On Thursday 04 July 2019 23:54:21 andreimpope...@gmail.com wrote:
> >
> > Just the fact that you are running Raspbian instead of pure Debian is
> > already an important clue and possibly a major hindrance in helping
> > you (we don't know what other customizations have been done to that).
> >
> Humm, someplace, in the last week, I read on a debian site, that raspian 
> was the officially supported armhf version of debian ???  Or was that my 
> imagination, out to play without a chaperone?

The clue is in the name: if it's not Debian it's not called Debian.

Raspbian was initially created because Debian's armhf port did not work 
on the Raspberry Pi model B. It was basically just recompiling official 
Debian packages to work on the Raspberry Pi.

Various parties started creating images based on Raspbian, including the 
Raspberry Pi foundation. What *other* changes they did to those images 
one can only guess.

This is the same with all other images provided by various projects 
and/or manufacturers and/or community members.

I've seen customizations starting from changing the default bash prompt 
up to proprietary kernels (with serious security bugs) and libraries, or 
custom scripts to resize your partitions and configure your network.

It was a very happy moment for me when I could use pure Debian on my 
Pine A64 ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Vi, 05 iul 19, 21:19:29, Gene Heskett wrote:
> On Friday 05 July 2019 12:08:45 David Wright wrote:
> 
> > As I've said, though, I'll go no further in looking at the problems
> > you have because I think that many of them are of your own making.
> 
> Thats also true, simply because I'm the last one on the planet using 
> hosts files and no dhcpd's of any kind.

Because many home networks do have a working DHCP server (typically the 
internet modem/router) it makes sense to have this as a *default* 
configuration. It just works for so many users.

I'm using as static network right now, as I'm sure many other 
debian-user readers do. It is a basic functionality of every software 
designed to manage your network, including Network Manager.

In order to switch to static one has to figure out:

 1. How is networking configured on this particular device

If you can't figure it out ask the ones providing the 
device/software. In case of Raspbian / Armbian it is *not* Debian 
(the clue is in the name).

 2. What is the *correct* method to alter its configuration

   This is usually quite straightforward once you figured out 1.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Vi, 05 iul 19, 15:17:16, Reco wrote:
> 
> Debian may or may not get there - for instance, I heard some good news
> about Raspberry Pi support in buster (not to be confused with Raspbian).

Care to submit an entry for the Release Notes, similar to the one for 
Allwinner A64 based boards?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 15:23:38 Brian wrote:

> On Fri 05 Jul 2019 at 04:33:42 -0400, Gene Heskett wrote:
> > On Thursday 04 July 2019 16:42:11 Brian wrote:
> > > If nobody objects I would like to reword that statement. Many,
> > > many users will have avahi-daemon on their systems; a few won't.
> > > The idea that
> > >
> > >   > Not installing this software in the first place works even
> > >   > better.
> > >
> > > requires clarification.
> >
> > Aha! Took several more hours but I found the SOB screwing my static
> > network!  S
>
> I was rather hoping someone would clarify why not having avahi-daemon
> in the first place was a good thing in general. Your problem doesn't
> particularly interest me because it is probably something you have
> brought on yourself due to previous actions.
>
> > Here is your Clarification: I used apt to purge avahi-daemon which
> > took nsswitch with it,
>
> I stopped reading there. I am not into fantasy.

Which proves another theorem of mine. Folks with a sheepskin on the 
office wall stop learning, and by your stopping without reading the 
explanation is evidence of that effect. I can lead you to the facts, but 
like the horse refusing to drink when led to water, I'll drop the reins.  
You may, or may not drink the water of knowledge. I can't control that. 

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 13:00:42 Jonas Smedegaard wrote:

> Quoting Gene Heskett (2019-07-05 17:45:54)
>
> > On Friday 05 July 2019 07:34:42 Jonas Smedegaard wrote:
> > > Quoting Gene Heskett (2019-07-05 12:54:05)
> > >
> > > > Its not quite that simple on the arm's. You do the install there
> > > > by dd'ing the complete filesystem image to the boot media,
> > > > usually a u-sd, so you get that crap regardless and must
> > > > physically remove it before a staticly defined, hosts file based
> > > > network that has not had a functioning dhcpd server even in my
> > > > original 1998 install of red hat 5.0 will work.
> > >
> > > Please stop speading misinformation about how Debian is installed.
> > >
> > > Official way to install Debian is using debian-installer, also for
> > > boards using U-boot.
>
> Official way to install Debian is using debian-installer.
>
> > >  See e.g. the user notes for Allwinner-based boards at
> > > https://wiki.debian.org/InstallingDebianOn/Allwinner#Install_Using
> > >_Debian-Installer
> >
> > I have looked at that page, hoping to see some mention of the pi's
> > since the allwinner doesn't appear in their advertising as a hugely
> > important detail,
>
> Official way to install Debian is using debian-installer, regardless
> of the fact that Raspberry Pi does not use a System-on-Chip from
> Allwinner.
>
> > and I've had rather a zoo full of arm based boards here. But the pi
> > wasn't mentioned so I went on my way. I'm not even sure all the pi's
> > are allwinner based.
>
> Official way to install Debian is using debian-installer, regardless
> of the amount of boards you have piled up at home.
>
> > > It is true that you can leave it to others to prepare an
> > > installation for you, so that you only need to dump their
> > > pre-installed image onto your boot disk device - e.g. as done with
> > > the preview image for Raspberry Pi offered at
> > > https://wiki.debian.org/RaspberryPi3.
> >
> > Does it actually work?
>
> Official way to install Debian is using debian-installer, regardless
> of how broken or not Raspberry Pi and/or Debian may be.
>
> > > It is also true that you can have others make a derivative of
> > > Debian and offer you that as a pre-installed image - e.g. as done
> > > by Raspbian and Armbian projects.
> > >
> > > The "crap" you get using unofficial pre-installed images is not on
> > > Debian but on those pre-installing and on you using those instead
> > > of Debian.
> >
> > This may be true, but how long will it take to get the new, faster
> > video drivers into your official version? Or will they ever get in?
>
> Official way to install Debian is using debian-installer, regardless
> of how frustratingly long time it takes reverse-engineer the
> closed-source parts of Raspberry Pi making it frustratingly difficult
> to use with Free software operating systems like Debian.
>
Somebody go jiggle that turntable, we've a bad case of a stuck needle 
here :)
>
>  - Jonas


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 12:08:45 David Wright wrote:

> On Fri 05 Jul 2019 at 06:06:30 (-0400), Gene Heskett wrote:
> > On Thursday 04 July 2019 16:48:56 andreimpope...@gmail.com wrote:
> > > On Jo, 04 iul 19, 11:40:30, Gene Heskett wrote:
> > > > > 1. content of /etc/network/interfaces and all files under
> > > > > /etc/network/interfaces.d/
> > > >
> > > > pi@picnc:~ $ cat /etc/network/interfaces.d/*
> > >
> > > Is below the literal output of the cat above?
> > >
> > > Please post also /etc/network/interfaces.
> > >
> > > > auto eth0
> > > >
> > > > iface eth0 inet static
> > > > address 192.168.71.12/24
> > > > gateway 192.168.71.1
> > > > post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> > > >
> > > > Which the last line disables ipv6  on this machines mostly
> > > > stretch install.
> > >
> > > It doesn't, but IPv6 is not your problem anyway.
>
> […]
>
> > > In addition to the full /etc/network/interfaces please post also
> > > the output of
> >
> > Its unmodified, and contains only the line to source whatever may be
> > in the interfaces.d directory.
>
> Technically, that just doesn't cut it, and I'm not sure what makes you
> coy about posting them. Which files get used depends on how the source
> line is expressed (source/source-directory), and then on what the
> filenames are for the files which you cat'd with * (that have to match
> a filename pattern).
>
> On Debian, it's normal for the d-i to write (and sometimes unwrite)
> the /e/n/i file. But what gets written depends on the installation
> method. But it's not even clear that you used the d-i to install your
> system, if I've followed the thrread correctly.
>
d-i? Define please so we're both on the same jargon page.  And yes, until 
N-M was sufficiently house broken & trained to leave a static setup 
alone, and it had so many dependencies you could only neuter it by a 
chatttr +i on the stuff you didn't want it editing. Or find it and use 
the F8 key in mc.  Six of one, half a dozen of the other as later as 
wheezy.

> As I've said, though, I'll go no further in looking at the problems
> you have because I think that many of them are of your own making.

Thats also true, simply because I'm the last one on the planet using 
hosts files and no dhcpd's of any kind. So no one has answered me with a 
howto to get rid of all the 169.254.xx.xx bull shit in my network 
configs that stopped it from working.  I turned out, after I had removed 
ALL the avahi sources, it was still there, so I next killed dhcp, no 
effect, but it all disappeared when I removed dhcpd5, that stopped all 
the poisoning of my network configs.

IMO having a dhcpd5 invent bogus numbers when there is not an accessable 
server, is both a huge security hole that could be exploited, and 
grounds for 30 lashes useing a cat-o-9-tails made out of wet noodles 
being applied to whoever thought it was a good idea.  It was, IMNSHO, a 
very very bad idea.
 
> Not a shotgun (I liked that image), but a nuclear bomb: you said it
> yourself.

Given a sufficiently large pile of sheckles, I could probably make one, 
as I am fairly well up in the physics. My formal education may have 
stopped in the 9th grade, but my informal has never stopped. I read with 
high interest the makings of what may yet be a TOE that includes dark 
matter and gravity, all based on 5 events that are outside of the 
expected boundaries of neutrino physics, detected by both ICE CUBE and 
ANITA down near the south pole. It should still be on the front page of 
most webish news sites. Events that are well beyond the newly rebuilt 
LHC's ability to duplicate.
> […]
>
> > There are folks here who will violently disapprove of my
> > sledgehammer or shotgun approach to this, and I would remind people
> > that I bought these things to USE, and whatever makes them usable is
> > what I will do.  As shipped, the armhf images are NOT usable. Make
> > them usable as shipped, and I will use them as shipped. It really is
> > that simple.
>
> Cheers,
> David.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 09:17:47 Greg Wooledge wrote:

> On Fri, Jul 05, 2019 at 04:02:36PM +0300, Reco wrote:
> > On Fri, Jul 05, 2019 at 08:41:47AM -0400, Greg Wooledge wrote:
> > > Gene, /etc/nsswitch.conf is NOT part of any Debian package.
> >
> > Actually, nsswitch.conf is created by postinst script of libc-bin
> > package, to technically nsswitch.conf is a part of libc-bin.
>
> Even if it's created by libc-bin's postinst, it still wouldn't be
> removed when libc-bin is (hypothetically) purged, because it's not a
> registered conffile of that package.
>
> Of course, one should NOT purge libc-bin.
>
> wooledg:~$ dpkg -s libc-bin
> Package: libc-bin
> Essential: yes
> [...]
> Conffiles:
>  /etc/bindresvport.blacklist 4c09213317e4e3dd3c71d74404e503c5
>  /etc/default/nss d6d5d6f621fb3ead2548076ce81e309c
>  /etc/gai.conf 28fa76ff5a9e0566eaa1e11f1ce51f09
>  /etc/ld.so.conf 4317c6de8564b68d628c21efa96b37e4
>  /etc/ld.so.conf.d/libc.conf d4d833fd095fb7b90e1bb4a547f16de6
> [...]
>
> Whatever Gene did, it's absolutely not normal or desirable for
> nsswitch.conf to vanish.  I still think he deleted it by hand and then
> forgot the exact sequence of steps which led to its disappearance, so
> he simply blamed it on purging ahavi-daemon.

I didn't say that. If I made that impression I didn't intend to. I 
removed it by hand about 2 hours back but that u-sd has not been 
inserted in the pi yet as I'm also the chief cook and bottle washer here 
and it was time I played chef with a bag of beef stir fry to feed the 
two of us.  With the missus disabled, I do it all. And next is to go 
recycle the dishwasher. :(

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 08:59:41 Greg Wooledge wrote:

> On Fri, Jul 05, 2019 at 04:33:42AM -0400, Gene Heskett wrote:
> > Here is your Clarification: I used apt to purge avahi-daemon which
> > took nsswitch with it,
>
> Let's test this assertion.
>
>
> wooledg:~$ ls -l /etc/nss*
> -rw-r--r-- 1 root root 545 Apr  1 08:58 /etc/nsswitch.conf
> wooledg:~$ sudo cp /etc/nsswitch.conf /etc/nsswitch.conf.GW-backup
> [sudo] password for wooledg:
> wooledg:~$ sudo apt purge avahi-daemon
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages will be REMOVED:
>   avahi-daemon* libnss-mdns*
> 0 upgraded, 0 newly installed, 2 to remove and 1 not upgraded.
> After this operation, 407 kB disk space will be freed.
> Do you want to continue? [Y/n]
> (Reading database ... 107764 files and directories currently
> installed.) Removing libnss-mdns:amd64 (0.14.1-1) ...
> Removing avahi-daemon (0.7-4+b1) ...
> Created symlink /run/systemd/system/avahi-daemon.service → /dev/null.
> Removed /run/systemd/system/avahi-daemon.service.
> Processing triggers for man-db (2.8.5-2) ...
> Processing triggers for dbus (1.12.16-1) ...
> Processing triggers for libc-bin (2.28-10) ...
> (Reading database ... 107717 files and directories currently
> installed.) Purging configuration files for avahi-daemon (0.7-4+b1)
> ...
> rmdir: failed to remove '/var/run/avahi-daemon': Directory not empty
> Purging configuration files for libnss-mdns:amd64 (0.14.1-1) ...
> libnss-mdns.postrm: Checking NSS setup...
> libnss-mdns.postrm: Removing mdns from NSS setup
> Processing triggers for dbus (1.12.16-1) ...
> Processing triggers for systemd (241-5) ...
> wooledg:~$ ls -l /etc/nss*
> -rw-r--r-- 1 root root 513 Jul  5 08:51 /etc/nsswitch.conf
> -rw-r--r-- 1 root root 545 Jul  5 08:51 /etc/nsswitch.conf.GW-backup
> wooledg:~$ diff -u /etc/nsswitch.conf.GW-backup /etc/nsswitch.conf
> --- /etc/nsswitch.conf.GW-backup2019-07-05 08:51:38.640595350
> -0400 +++ /etc/nsswitch.conf  2019-07-05 08:51:52.812542805 -0400
> @@ -9,7 +9,7 @@
>  shadow: compat
>  gshadow:files
>
> -hosts:  files mdns4_minimal [NOTFOUND=return] dns
> +hosts:  files dns
>  networks:   files
>
>  protocols:  db files
>
>
> So... purging avahi-daemon actually does *touch* the nsswitch.conf
> file (see the "libnss-mdns.postrm: Removing mdns from NSS setup"
> message).  But it doesn't completely *remove* the file.  That would
> be madness.
>
> If your multiple-times-customized Raspbian system's avahi-daemon
> package or libnss-mdns package completely *removes* the nsswitch.conf
> file, you should either fix that (if it's one of your customizations
> that did it), or file a bug report against Raspbian (if it's one of
> theirs).

So I'll put it back, edited as shown above.  One less head-scratcher.

Thanks.
>
> In any case, the behavior you describe is not what Debian (or any sane
> operating system) does.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 08:41:47 Greg Wooledge wrote:

> On Fri, Jul 05, 2019 at 06:35:53AM -0400, Gene Heskett wrote:
> > yup, and if the repos were open...  They are not as I've previously
> > posted. I can report that apt --purge does not, I still see
> > an /etc/nsswitch.conf, even though ts been purged.
>
> ... what.
>
> Gene, /etc/nsswitch.conf is NOT part of any Debian package.  It's part
> of the core installation.  It is absolutely fundamental to the
> operation of basically every single piece of the operating system
> above the boot loader, the kernel, the ld.so shared library loader,
> and libc.

IOW, the image I have in my pocket probably don't work until I locate a 
copy and put it back in. But just for grins, check the buster its 
running:  yes, its still there and I think intact:
gene@shop:~$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, 
try:
# `info libc "Name Service Switch"' for information about this file.

passwd: compat
group:  compat
shadow: compat

hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis

But that begs another question Greg.  If it hasn't anything to do with 
avahi-daemon, whyinhell did purging avahi-daemon take the libnsswitch 
package with it?

> If you remove /etc/nsswitch.conf, you won't be able to look up user
> names, or service port names, or host names, or basically *any* kind
> of names of anything at all.  (Or, at best, you'll get some sort of
> default behavior compiled into the C library routines, if any.)
>
> wooledg:~$ dpkg -S /etc/nsswitch.conf
> dpkg-query: no path found matching pattern /etc/nsswitch.conf
>
> Since nsswitch.conf isn't part of a package, there is absolutely no
> reason you should think that purging ANY package would remove it.  And
> there is absolutely no reason you should *want* to remove it.

The only reason I removed it, was to complete the libnsswitch removal 
that removing avahi-daemon took out. Somehow I am missing an actual 
dependency of one on the other.  Call me puzzled. 

Thanks Greg.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[tomas]

On Fri, Jul 05, 2019 at 09:27:29PM +0100, Brian wrote:

[...]

> Some users are always fearful of new technology. They find all sorts of
> ways to rubbish it, usually without any strong technical grounds but by
> an appeal to tradition and emotion.

Some other people always try to skirt a sound technical argument by
reducing dissenting standpoints to psychological "reasons", e.g.
"resistance to change".

It cuts both ways ;-P

Cheers
-- t


signature.asc
Description: Digital signature

Re: Assorted arm-buster problems - network configuration

[Brian]

On Fri 05 Jul 2019 at 16:17:11 -0400, Lee wrote:

> On 7/5/19, Brian  wrote:
> > On Fri 05 Jul 2019 at 04:33:42 -0400, Gene Heskett wrote:
> >
> >> On Thursday 04 July 2019 16:42:11 Brian wrote:
> >>
> >> > If nobody objects I would like to reword that statement. Many, many
> >> > users will have avahi-daemon on their systems; a few won't. The idea
> >> > that
> >> >
> >> >   > Not installing this software in the first place works even better.
> >> >
> >> > requires clarification.
> >>
> >> Aha! Took several more hours but I found the SOB screwing my static
> >> network!  S
> >
> > I was rather hoping someone would clarify why not having avahi-daemon
> > in the first place was a good thing in general.
> 
> avahi-daemon is the thing that does multicast dns - right?  I think
> using mDNS is an accident waiting to happen.  The other viewpoint
> would be RFC 6762:
> 
> 1.  Introduction
> 
>Multicast DNS and its companion technology DNS-Based Service
>Discovery [RFC6763] were created to provide IP networking with the
>ease-of-use and autoconfiguration for which AppleTalk was well-known
>[RFC6760].

Some users are always fearful of new technology. They find all sorts of
ways to rubbish it, usually without any strong technical grounds but by
an appeal to tradition and emotion.

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/5/19, Brian  wrote:
> On Fri 05 Jul 2019 at 04:33:42 -0400, Gene Heskett wrote:
>
>> On Thursday 04 July 2019 16:42:11 Brian wrote:
>>
>> > If nobody objects I would like to reword that statement. Many, many
>> > users will have avahi-daemon on their systems; a few won't. The idea
>> > that
>> >
>> >   > Not installing this software in the first place works even better.
>> >
>> > requires clarification.
>>
>> Aha! Took several more hours but I found the SOB screwing my static
>> network!  S
>
> I was rather hoping someone would clarify why not having avahi-daemon
> in the first place was a good thing in general.

avahi-daemon is the thing that does multicast dns - right?  I think
using mDNS is an accident waiting to happen.  The other viewpoint
would be RFC 6762:

1.  Introduction

   Multicast DNS and its companion technology DNS-Based Service
   Discovery [RFC6763] were created to provide IP networking with the
   ease-of-use and autoconfiguration for which AppleTalk was well-known
   [RFC6760].

Regards,
Lee

Re: Assorted arm-buster problems - network configuration

[Brian]

On Fri 05 Jul 2019 at 04:33:42 -0400, Gene Heskett wrote:

> On Thursday 04 July 2019 16:42:11 Brian wrote:
> 
> > If nobody objects I would like to reword that statement. Many, many
> > users will have avahi-daemon on their systems; a few won't. The idea
> > that
> >
> >   > Not installing this software in the first place works even better.
> >
> > requires clarification.
> 
> Aha! Took several more hours but I found the SOB screwing my static
> network!  S

I was rather hoping someone would clarify why not having avahi-daemon
in the first place was a good thing in general. Your problem doesn't
particularly interest me because it is probably something you have
brought on yourself due to previous actions.

> Here is your Clarification: I used apt to purge avahi-daemon which 
> took nsswitch with it,

I stopped reading there. I am not into fantasy.

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 08:17:16 Reco wrote:

>   Hi.
>
> On Fri, Jul 05, 2019 at 06:54:05AM -0400, Gene Heskett wrote:
> > > > The idea
> > > > that
> > > >
> > > >   > Not installing this software in the first place works even
> > > >   > better.
> > > >
> > > > requires clarification.
> > >
> > > Easy. You don't understand what the software does (Gene's here),
> > > or you don't need its functions (I'm here) - you just do not
> > > install it. You don't fight with it, you don't try to "disable" it
> > > in myriad ways, and you do not build assorted kludges alongside of
> > > it - you do not install it, simple as that.
> >
> > Its not quite that simple on the arm's.
>
> But it's simple as that.
> dd-ready images are provided for the user's convenience, but they're
> not the only way one installs the OS on arm.
> For instance, I personally ran debian-installer on Marvell Orion,
> Armada and Exynos boards to my full satisfaction (i.e. - a real Debian
> installed with the parts I need).
>
> It's true, that some boards (namely, Raspberry Pi) aren't true Open
> Hardware so they require non-free blobs just to boot.
> There are boards (Amazon's Annapurna) which are downright hostile in
> this regard as there are no mainline support worthy to speak of.
>
> Debian may or may not get there - for instance, I heard some good news
> about Raspberry Pi support in buster (not to be confused with
> Raspbian).
>
> Reco

So have I Reco. And I just got done building a raspian buster image with 
a 4.14.91-rt-v7 kernel, which is a step backwards from the 4.19.50 
non-rt kernel that the zip comes with. But the build ended doing quite a 
few things I not seen it do before, including printing a big success in 
green text.  So despite the fact that I really need to fork the rider 
and demolish 7" of grass, I'm going out to Wallies and getting two more 
64GB PNY brand cards and I'm going to burn that image, then mount it and 
nuke what screwed me out of 4 days of my life so it can't do it again, 
and install the network configs from this card, then take it to the pi 
and boot it.  Then comes the real fun, building linuxcnc on buster. That 
may take some coding skills I don't have as I am told buster has removed 
some stuff that linuxcnc needs, probably older python stuff. Some of 
linuxcnc dates back to before linux even, since what it is, is the 
growth of a NIST project to update our countries manufacturing machinery 
so as to remain competitive with the progress the rest of the world was 
making after WW-II. So the history goes back a long ways, governed by 
NIST rules about public domain but gradually rewritten in clean rooms so 
the much better protections of the gpl and lgpl could be applied.  So 
while its close to 60 years old now, it is still under active 
development as new machines using different tech come online, often with 
poorly written proprietary software, but we have interfaces that can 
drive 90% of then OOTB.  Sometimes at 10x the speed the OEM drivers 
could do it. And usually adding to the list of things the machine can 
do, none of my machines need to change gears (they don't even have gears 
unless the spindle is multispeed) to switch from inches to mm's, and all 
of then can drive a tap into a hole at exactly the taps pitch, then back 
it out of the hole by the same rules. A $30 carbide 4-40 tap has at one 
makers site, tapped around 40,000 holes with no noticeable wear, in 1/8" 
alu plate simply because its being used correctly.  That old bridgeport 
mill was never made to do that, works great when the screws have been 
replaced with ball screws turned by motors controlled to the micron by 
linuxcnc.

But I digress, so I'll play an Andy Capp and shudup.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/5/19, Gene Heskett  wrote:
> On Friday 05 July 2019 05:13:48 Brian wrote:
>
>> On Fri 05 Jul 2019 at 09:56:39 +0300, Reco wrote:
>>
>> > Third, whatever good avahi does is limited to a single L2 network
>> > segment by the very definition of how it works. This particular
>> > problem shows it BTW.
>> >
> And does it very well both for avahi-daemon, and the dhcpd's that invent
> avahi like addresses out of thin air, and then giving that BS priority
> over the admins attempts to setup his network to his liking by giving
> them a metric of 202 when the default priority/metric is 1024.
>
> So his (and my) only recourse is to rip that stuff out, with a root rm -f
> if that what it takes to get rid of them.  IMO, bug reports should be
> filed against the dhcpd's both 4 and 6 to get rid of their reporting
> bogus data if there are no servers responding to their requests.

Hi Gene,

Please understand that assigning a 169.254.0.0/16 address to an
interface that doesn't get a reply from a dhcp server is 'standards
compliant' behavior.  So if you do file a bug report, rants about
'bogus data' won't help your case; quoting RFC 3927 section 1.9.2
might.

RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses

1.9.  When to configure an IPv4 Link-Local address

  2. If a host finds that an interface that was previously
 configured with an IPv4 Link-Local address now has an operable
 routable address available, the host MUST use the routable
 address when initiating new communications, and MUST cease
 advertising the availability of the IPv4 Link-Local address
 through whatever mechanisms that address had been made known to
 others.

Regards,
Lee

Re: Assorted arm-buster problems - network configuration

[Brian]

On Fri 05 Jul 2019 at 11:11:11 -0400, Gene Heskett wrote:

> On Friday 05 July 2019 05:13:48 Brian wrote:
> 
> > On Fri 05 Jul 2019 at 09:56:39 +0300, Reco wrote:
> >
> > > Second, contrary to the popular thinking here, the world does not
> > > start and does not end with GNOME and x86 along with the CUPS
> > > installed. And while avahi enhances CUPS' usability indeed, it has
> > > little usefulness otherwise.
> >
> > The enhancements it brings to the printing system are sufficient to
> > more than justify its place on a user's machine.
> >
> That is a very poorly demonstrated fact at this site. Since before 

The thousands of well-administered sites probably have a different
story to relate. Most are aware that a user encountering a problem
often lashes out the nearest target without much thought to looking
at his own motes. The claim that purging avahi-daemon removes the
nsswitch.conf file is likely to raise an eyebrow or two at the very
least.

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[Jonas Smedegaard]

Quoting Gene Heskett (2019-07-05 17:45:54)
> On Friday 05 July 2019 07:34:42 Jonas Smedegaard wrote:
> 
> > Quoting Gene Heskett (2019-07-05 12:54:05)
> >
> > > Its not quite that simple on the arm's. You do the install there 
> > > by dd'ing the complete filesystem image to the boot media, usually 
> > > a u-sd, so you get that crap regardless and must physically remove 
> > > it before a staticly defined, hosts file based network that has 
> > > not had a functioning dhcpd server even in my original 1998 
> > > install of red hat 5.0 will work.
> >
> > Please stop speading misinformation about how Debian is installed.
> >
> > Official way to install Debian is using debian-installer, also for 
> > boards using U-boot.

Official way to install Debian is using debian-installer.


> >  See e.g. the user notes for Allwinner-based boards at 
> > https://wiki.debian.org/InstallingDebianOn/Allwinner#Install_Using_Debian-Installer
> 
> I have looked at that page, hoping to see some mention of the pi's 
> since the allwinner doesn't appear in their advertising as a hugely 
> important detail,

Official way to install Debian is using debian-installer, regardless of 
the fact that Raspberry Pi does not use a System-on-Chip from Allwinner.


> and I've had rather a zoo full of arm based boards here. But the pi 
> wasn't mentioned so I went on my way. I'm not even sure all the pi's 
> are allwinner based.

Official way to install Debian is using debian-installer, regardless of 
the amount of boards you have piled up at home.


> > It is true that you can leave it to others to prepare an installation
> > for you, so that you only need to dump their pre-installed image onto
> > your boot disk device - e.g. as done with the preview image for
> > Raspberry Pi offered at https://wiki.debian.org/RaspberryPi3.
> 
> Does it actually work?

Official way to install Debian is using debian-installer, regardless of 
how broken or not Raspberry Pi and/or Debian may be.


> > It is also true that you can have others make a derivative of Debian 
> > and offer you that as a pre-installed image - e.g. as done by 
> > Raspbian and Armbian projects.
> >
> > The "crap" you get using unofficial pre-installed images is not on 
> > Debian but on those pre-installing and on you using those instead of 
> > Debian.
> 
> This may be true, but how long will it take to get the new, faster 
> video drivers into your official version? Or will they ever get in?

Official way to install Debian is using debian-installer, regardless of 
how frustratingly long time it takes reverse-engineer the closed-source 
parts of Raspberry Pi making it frustratingly difficult to use with Free 
software operating systems like Debian.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Assorted arm-buster problems - network configuration

[David Wright]

On Fri 05 Jul 2019 at 06:06:30 (-0400), Gene Heskett wrote:
> On Thursday 04 July 2019 16:48:56 andreimpope...@gmail.com wrote:
> > On Jo, 04 iul 19, 11:40:30, Gene Heskett wrote:
> > > > 1. content of /etc/network/interfaces and all files under
> > > > /etc/network/interfaces.d/
> > >
> > > pi@picnc:~ $ cat /etc/network/interfaces.d/*
> >
> > Is below the literal output of the cat above?
> >
> > Please post also /etc/network/interfaces.
> >
> > > auto eth0
> > >
> > > iface eth0 inet static
> > > address 192.168.71.12/24
> > > gateway 192.168.71.1
> > > post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> > >
> > > Which the last line disables ipv6  on this machines mostly stretch
> > > install.
> >
> > It doesn't, but IPv6 is not your problem anyway.

[…]

> > In addition to the full /etc/network/interfaces please post also the
> > output of
> 
> Its unmodified, and contains only the line to source whatever may be in 
> the interfaces.d directory.

Technically, that just doesn't cut it, and I'm not sure what makes you
coy about posting them. Which files get used depends on how the source
line is expressed (source/source-directory), and then on what the
filenames are for the files which you cat'd with * (that have to match
a filename pattern).

On Debian, it's normal for the d-i to write (and sometimes unwrite)
the /e/n/i file. But what gets written depends on the installation
method. But it's not even clear that you used the d-i to install your
system, if I've followed the thrread correctly.

As I've said, though, I'll go no further in looking at the problems
you have because I think that many of them are of your own making.
Not a shotgun (I liked that image), but a nuclear bomb: you said it
yourself.

[…]

> There are folks here who will violently disapprove of my sledgehammer or 
> shotgun approach to this, and I would remind people that I bought these 
> things to USE, and whatever makes them usable is what I will do.  As 
> shipped, the armhf images are NOT usable. Make them usable as shipped, 
> and I will use them as shipped. It really is that simple.

Cheers,
David.

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 07:34:55 to...@tuxteam.de wrote:

> On Fri, Jul 05, 2019 at 06:54:05AM -0400, Gene Heskett wrote:
>
> [...]
>
> > Its not quite that simple on the arm's. You do the install there by
> > dd'ing the complete filesystem image to the boot media, usually a
> > u-sd,
>
> so far, so good...
>
> > so you get that crap regardless and must physically remove it before
> > a
>
> That is not true: Raspbian, for example, has a "normal" Debian repo at
> https://archive.raspbian.org. With debootstap, schroot and Qemu you
> can build a customized Raspbian system. The firmware (i.e. the binary
> stuff needed for the VideoCore IV "co"-processor plus the kernel
> images can also be had at https://github.com/raspberrypi/firmware.git.
>
> With all that you can build a viable image to "burn" on an SD card,
> all from the confort of your powerful desktop machine.
>
> I know because I've done it. My writeup is still pretty incomplete,
> not yet fit for publishing, but others have written about it:
>
> https://raspberrypi.stackexchange.com/questions/78232/install-base-ras
>pbian-from-repository-not-using-an-image/
> https://blog.kmp.or.at/build-your-own-raspberry-pi-image/

Interesting, and I'd be very interested in doing exactly that since what 
I'm doing with a pi-3b is not (that I know of) being done on a day to 
day business by anyone else on this planet.  There may be others on the 
LCNC (emc-users) mailing list that have played with this, but AFAIK I am 
the only one actually making hot swarf with a pi. 
 
> How do you think the Raspberry Pi founadion builds its images?
>
No clue Tomas. The problems I've had haven't given me any time to think 
about that.

> Cheers
> -- tomás

Take care Tomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 07:34:42 Jonas Smedegaard wrote:

> Quoting Gene Heskett (2019-07-05 12:54:05)
>
> > Its not quite that simple on the arm's. You do the install there by
> > dd'ing the complete filesystem image to the boot media, usually a
> > u-sd, so you get that crap regardless and must physically remove it
> > before a staticly defined, hosts file based network that has not had
> > a functioning dhcpd server even in my original 1998 install of red
> > hat 5.0 will work.
>
> Please stop speading misinformation about how Debian is installed.
>
> Official way to install Debian is using debian-installer, also for
> boards using U-boot.  See e.g. the user notes for Allwinner-based
> boards at
> https://wiki.debian.org/InstallingDebianOn/Allwinner#Install_Using_Deb
>ian-Installer

I have looked at that page, hoping to see some mention of the pi's since 
the allwinner doesn't appear in their advertising as a hugely important 
detail, and I've had rather a zoo full of arm based boards here. But the 
pi wasn't mentioned so I went on my way. I'm not even sure all the pi's 
are allwinner based.

> It is true that you can leave it to others to prepare an installation
> for you, so that you only need to dump their pre-installed image onto
> your boot disk device - e.g. as done with the preview image for
> Raspberry Pi offered at https://wiki.debian.org/RaspberryPi3.

Does it actually work?
>
> It is also true that you can have others make a derivative of Debian
> and offer you that as a pre-installed image - e.g. as done by Raspbian
> and Armbian projects.
>
> The "crap" you get using unofficial pre-installed images is not on
> Debian but on those pre-installing and on you using those instead of
> Debian.

This may be true, but how long will it take to get the new, faster video 
drivers into your official version? Or will they ever get in?
>
>  - Jonas


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 07:29:52 Tixy wrote:

> On Fri, 2019-07-05 at 06:54 -0400, Gene Heskett wrote:
> > On Friday 05 July 2019 02:56:39 Reco wrote:
>
> [...]
>
> > > Easy. You don't understand what the software does (Gene's here),
> > > or you don't need its functions (I'm here) - you just do not
> > > install it. You don't fight with it, you don't try to "disable" it
> > > in myriad ways, and you do not build assorted kludges alongside of
> > > it - you do not install it, simple as that.
> >
> > Its not quite that simple on the arm's. You do the install there by
> > dd'ing the complete filesystem image to the boot media, usually a
> > u-sd,
>
> That may be the simplest way, but not the only way. You could boot the
> installer and install the OS from scratch.
>
> > so you get that crap regardless and must physically remove it
>
> [...]
>
> That's the price you pay for having the convenience of using prebuilt
> images. The alternative of using Debian's installer would have it's
> own headaches of trying to work out how to run it, then after to
> install and get working the non-free drivers for graphics (and wifi?).
> And no doubt there are other mods needed to get things working
> properly for a particular board, e.g. getting kernel updates
> installing correctly.
>
> So, prebuilt images with networking choices that don't suit you is
> probably the lesser of the two evils ;-)

Thats an conclusion I'm forced to come to also. To that end I'd suggest a 
script and man page describing the scripts function is to rip out that 
stuff.  That way there would be a one shot fix for the case where its 
booted into a hosts file based network that has no dhcpd servers, one 
could even offer to do this on first boot. In the event the installer 
gives it the ok to clean house, the house cleaning should include 
itself.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 05:13:48 Brian wrote:

> On Fri 05 Jul 2019 at 09:56:39 +0300, Reco wrote:
> > On Thu, Jul 04, 2019 at 09:42:11PM +0100, Brian wrote:
> > > On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:
> > > > On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> > > > > On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > > > > > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > I'd also consider exterminating avahi with extreme
> > > > > > > prejudice, i.e. 'apt
> > > > > > > purge avahi-daemon'. Really simplifies things. Not
> > > > > > > installing this software in the first place works even
> > > > > > > better.
> > > > > >
> > > > > > Gene Heskett can follow this advice if he wishes. It is to
> > > > > > be hoped that every other user ignores it.
> >
> > Oh, it seems that I've touched a nerve. My apologies just in case.
>
> No need to apologise. I was intrigued with the suggestion and simply
> wondered what the technical reason was and how not installing avahi
> would benefit a user.
>
> > > > > Why? It's advice I decided for myself 10 or more years ago
> > > > > after seeing constant reports of zeroconf bugs in various OSes
> > > > > and kit, and realising that sort of thing was also running on
> > > > > my Linux machines. The whole idea of automagically setting up
> > > > > networks just sounds like a problem and security hole waiting
> > > > > to happen. So I decided to nuke it from orbit, it was the only
> > > > > safe thing to do.
> > > >
> > > > As always, all generalizations suck. Some do avahi, others don't
> > > > (full disclosure: I am in the "don't" camp, as many may have
> > > > guessed :-)
> > >
> > > If nobody objects I would like to reword that statement. Many,
> > > many users will have avahi-daemon on their systems; a few won't.
> >
> > [1] says that half of the Debian users participating in popcon have
> > avahi-daemon installed. Your assertion that "don't camp" is a
> > minority is off. That's a first.
>
> Popularity contest statistics are a rough and ready basis for deciding
> on a course of action, but sufficient to counter a rough and ready
> argument.
>
> http://joeyh.name/blog/entry/the_popcon_problem/
>
> > Second, contrary to the popular thinking here, the world does not
> > start and does not end with GNOME and x86 along with the CUPS
> > installed. And while avahi enhances CUPS' usability indeed, it has
> > little usefulness otherwise.
>
> The enhancements it brings to the printing system are sufficient to
> more than justify its place on a user's machine.
>
That is a very poorly demonstrated fact at this site. Since before 
wheezy, its been my policy to create a cups.client file on any and all 
machines whose main function is to enable browsing of the server, which 
is this machine. I can to to any machine on this local network and print 
to either of the printers sitting one on the right rear of this table, 
or to a much larger, tabloid sized ink squirting brother sitting on top 
of its supplies cabinet on the next table over. Unforch I must admit 
that since theres not a cupsd running on the buster, and apparently lynx 
cannot follow paths like FF can I can't print without going to its own 
keyboard and lxde gui.

> > Third, whatever good avahi does is limited to a single L2 network
> > segment by the very definition of how it works. This particular
> > problem shows it BTW.
> >
And does it very well both for avahi-daemon, and the dhcpd's that invent 
avahi like addresses out of thin air, and then giving that BS priority 
over the admins attempts to setup his network to his liking by giving 
them a metric of 202 when the default priority/metric is 1024.

So his (and my) only recourse is to rip that stuff out, with a root rm -f 
if that what it takes to get rid of them.  IMO, bug reports should be 
filed against the dhcpd's both 4 and 6 to get rid of their reporting 
bogus data if there are no servers responding to their requests. Whoever 
thought that those bogus numbers that looked like avahi's work might be 
useful ought to be lashed with wet noodles until they've received that 
message. They are not helpfull in any definition of the word useful, or 
vice versa.

> > > The idea
> > > that
> > >
> > >   > Not installing this software in the first place works even
> > >   > better.
> > >
> > > requires clarification.
> >
> > Easy. You don't understand what the software does (Gene's here), or
> > you don't need its functions (I'm here) - you just do not install
> > it. You don't fight with it, you don't try to "disable" it in myriad
> > ways, and you do not build assorted kludges alongside of it - you do
> > not install it, simple as that.
> >
> >
> > [1] https://qa.debian.org/popcon.php?package=avahi
>
> Not installing avahi-daemon or purging it when it is not required is
> reasonable; I do both on some machines here.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 05:13:36 Curt wrote:

> On 2019-07-05, Gene Heskett  wrote:
> > pi@picnc:/ $ sudo apt update
> > Get:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
> > [15.0 kB] Get:2 http://archive.raspberrypi.org/debian buster
> > InRelease [25.1 kB] Reading package lists... Done
> > E: Release file for
> > http://raspbian.raspberrypi.org/raspbian/dists/buster/InRelease is
> > not valid yet (invalid for another 12d 21h 12min 47s). Updates for
> > this repository will not be applied. E: Release file for
> > http://archive.raspberrypi.org/debian/dists/buster/InRelease is not
> > valid yet (invalid for another 10d 12h 43min 27s). Updates for this
> > repository will not be applied.
> >
> > So what sort of a surprise are they fixing to throw at us this time?
>
> Check your system clock/timezone?
>
Now that you mention it, its as bogus as a $3 bill. But then I didn't 
have a network nor have I set it up to use this machine for a relay.  
But now thats its had a network for 4 or 5 hours, I see ntp has brought 
it up to date.  And now so has apt.

> > Anyway, now I know what to do to get that stuff out of my thinning
> > hair.
> >
> > And I can do it while the u-sd card is still in the writer gizmo
> > before its ever plugged into the pi.
> >
> > Heck, maybe running on buster, I can get RealtimePi to build me a
> > 4.19.50-rt-v7 kernel?  'Spose?  ;-)
> >
> > Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Greg Wooledge]

On Fri, Jul 05, 2019 at 04:02:36PM +0300, Reco wrote:
> On Fri, Jul 05, 2019 at 08:41:47AM -0400, Greg Wooledge wrote:
> > Gene, /etc/nsswitch.conf is NOT part of any Debian package.
> 
> Actually, nsswitch.conf is created by postinst script of libc-bin
> package, to technically nsswitch.conf is a part of libc-bin.

Even if it's created by libc-bin's postinst, it still wouldn't be removed
when libc-bin is (hypothetically) purged, because it's not a registered
conffile of that package.

Of course, one should NOT purge libc-bin.

wooledg:~$ dpkg -s libc-bin
Package: libc-bin
Essential: yes
[...]
Conffiles:
 /etc/bindresvport.blacklist 4c09213317e4e3dd3c71d74404e503c5
 /etc/default/nss d6d5d6f621fb3ead2548076ce81e309c
 /etc/gai.conf 28fa76ff5a9e0566eaa1e11f1ce51f09
 /etc/ld.so.conf 4317c6de8564b68d628c21efa96b37e4
 /etc/ld.so.conf.d/libc.conf d4d833fd095fb7b90e1bb4a547f16de6
[...]

Whatever Gene did, it's absolutely not normal or desirable for
nsswitch.conf to vanish.  I still think he deleted it by hand and then
forgot the exact sequence of steps which led to its disappearance, so
he simply blamed it on purging ahavi-daemon.

Re: Assorted arm-buster problems - network configuration

[Reco]

Hi.

On Fri, Jul 05, 2019 at 08:41:47AM -0400, Greg Wooledge wrote:
> On Fri, Jul 05, 2019 at 06:35:53AM -0400, Gene Heskett wrote:
> > yup, and if the repos were open...  They are not as I've previously 
> > posted. I can report that apt --purge does not, I still see 
> > an /etc/nsswitch.conf, even though ts been purged.
> 
> ... what.
> 
> Gene, /etc/nsswitch.conf is NOT part of any Debian package.

Actually, nsswitch.conf is created by postinst script of libc-bin
package, to technically nsswitch.conf is a part of libc-bin.

> It's part of the core installation.  It is absolutely fundamental to
> the operation of basically every single piece of the operating system
> above the boot loader, the kernel, the ld.so shared library loader,
> and libc.

nsswitch.conf(5) says:

The Name Service Switch (NSS) configuration file, /etc/nsswitch.conf, is
used by the GNU C Library...


> wooledg:~$ dpkg -S /etc/nsswitch.conf
> dpkg-query: no path found matching pattern /etc/nsswitch.conf

grep nsswitch /var/lib/dpkg/info/*

Reco

Re: Assorted arm-buster problems - network configuration

[Greg Wooledge]

On Fri, Jul 05, 2019 at 04:33:42AM -0400, Gene Heskett wrote:
> Here is your Clarification: I used apt to purge avahi-daemon which 
> took nsswitch with it,

Let's test this assertion.


wooledg:~$ ls -l /etc/nss*
-rw-r--r-- 1 root root 545 Apr  1 08:58 /etc/nsswitch.conf
wooledg:~$ sudo cp /etc/nsswitch.conf /etc/nsswitch.conf.GW-backup
[sudo] password for wooledg: 
wooledg:~$ sudo apt purge avahi-daemon
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  avahi-daemon* libnss-mdns*
0 upgraded, 0 newly installed, 2 to remove and 1 not upgraded.
After this operation, 407 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 107764 files and directories currently installed.)
Removing libnss-mdns:amd64 (0.14.1-1) ...
Removing avahi-daemon (0.7-4+b1) ...
Created symlink /run/systemd/system/avahi-daemon.service → /dev/null.
Removed /run/systemd/system/avahi-daemon.service.
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for dbus (1.12.16-1) ...
Processing triggers for libc-bin (2.28-10) ...
(Reading database ... 107717 files and directories currently installed.)
Purging configuration files for avahi-daemon (0.7-4+b1) ...
rmdir: failed to remove '/var/run/avahi-daemon': Directory not empty
Purging configuration files for libnss-mdns:amd64 (0.14.1-1) ...
libnss-mdns.postrm: Checking NSS setup...
libnss-mdns.postrm: Removing mdns from NSS setup
Processing triggers for dbus (1.12.16-1) ...
Processing triggers for systemd (241-5) ...
wooledg:~$ ls -l /etc/nss*
-rw-r--r-- 1 root root 513 Jul  5 08:51 /etc/nsswitch.conf
-rw-r--r-- 1 root root 545 Jul  5 08:51 /etc/nsswitch.conf.GW-backup
wooledg:~$ diff -u /etc/nsswitch.conf.GW-backup /etc/nsswitch.conf
--- /etc/nsswitch.conf.GW-backup2019-07-05 08:51:38.640595350 -0400
+++ /etc/nsswitch.conf  2019-07-05 08:51:52.812542805 -0400
@@ -9,7 +9,7 @@
 shadow: compat
 gshadow:files
 
-hosts:  files mdns4_minimal [NOTFOUND=return] dns
+hosts:  files dns
 networks:   files
 
 protocols:  db files


So... purging avahi-daemon actually does *touch* the nsswitch.conf
file (see the "libnss-mdns.postrm: Removing mdns from NSS setup"
message).  But it doesn't completely *remove* the file.  That would
be madness.

If your multiple-times-customized Raspbian system's avahi-daemon package
or libnss-mdns package completely *removes* the nsswitch.conf file, you
should either fix that (if it's one of your customizations that did it),
or file a bug report against Raspbian (if it's one of theirs).

In any case, the behavior you describe is not what Debian (or any sane
operating system) does.

Re: Assorted arm-buster problems - network configuration

[Greg Wooledge]

On Fri, Jul 05, 2019 at 06:35:53AM -0400, Gene Heskett wrote:
> yup, and if the repos were open...  They are not as I've previously 
> posted. I can report that apt --purge does not, I still see 
> an /etc/nsswitch.conf, even though ts been purged.

... what.

Gene, /etc/nsswitch.conf is NOT part of any Debian package.  It's part
of the core installation.  It is absolutely fundamental to the operation
of basically every single piece of the operating system above the
boot loader, the kernel, the ld.so shared library loader, and libc.

If you remove /etc/nsswitch.conf, you won't be able to look up user names,
or service port names, or host names, or basically *any* kind of names of
anything at all.  (Or, at best, you'll get some sort of default behavior
compiled into the C library routines, if any.)

wooledg:~$ dpkg -S /etc/nsswitch.conf
dpkg-query: no path found matching pattern /etc/nsswitch.conf

Since nsswitch.conf isn't part of a package, there is absolutely no reason
you should think that purging ANY package would remove it.  And there is
absolutely no reason you should *want* to remove it.

Re: Assorted arm-buster problems - network configuration

[Reco]

Hi.

On Fri, Jul 05, 2019 at 06:54:05AM -0400, Gene Heskett wrote:
> > > The idea
> > > that
> > >
> > >   > Not installing this software in the first place works even
> > >   > better.
> > >
> > > requires clarification.
> >
> > Easy. You don't understand what the software does (Gene's here), or
> > you don't need its functions (I'm here) - you just do not install it.
> > You don't fight with it, you don't try to "disable" it in myriad ways,
> > and you do not build assorted kludges alongside of it - you do not
> > install it, simple as that.
> >
> Its not quite that simple on the arm's.

But it's simple as that.
dd-ready images are provided for the user's convenience, but they're not
the only way one installs the OS on arm.
For instance, I personally ran debian-installer on Marvell Orion, Armada
and Exynos boards to my full satisfaction (i.e. - a real Debian
installed with the parts I need).

It's true, that some boards (namely, Raspberry Pi) aren't true Open
Hardware so they require non-free blobs just to boot.
There are boards (Amazon's Annapurna) which are downright hostile in
this regard as there are no mainline support worthy to speak of.

Debian may or may not get there - for instance, I heard some good news
about Raspberry Pi support in buster (not to be confused with Raspbian).

Reco

Re: Assorted arm-buster problems - network configuration

[tomas]

On Fri, Jul 05, 2019 at 06:54:05AM -0400, Gene Heskett wrote:

[...]

> Its not quite that simple on the arm's. You do the install there by 
> dd'ing the complete filesystem image to the boot media, usually a u-sd, 

so far, so good...

> so you get that crap regardless and must physically remove it before a 

That is not true: Raspbian, for example, has a "normal" Debian repo at
https://archive.raspbian.org. With debootstap, schroot and Qemu you can
build a customized Raspbian system. The firmware (i.e. the binary stuff
needed for the VideoCore IV "co"-processor plus the kernel images can
also be had at https://github.com/raspberrypi/firmware.git.

With all that you can build a viable image to "burn" on an SD card, all
from the confort of your powerful desktop machine.

I know because I've done it. My writeup is still pretty incomplete, not
yet fit for publishing, but others have written about it:

https://raspberrypi.stackexchange.com/questions/78232/install-base-raspbian-from-repository-not-using-an-image/
https://blog.kmp.or.at/build-your-own-raspberry-pi-image/

How do you think the Raspberry Pi founadion builds its images?

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Assorted arm-buster problems - network configuration

[Jonas Smedegaard]

Quoting Gene Heskett (2019-07-05 12:54:05)
> Its not quite that simple on the arm's. You do the install there by 
> dd'ing the complete filesystem image to the boot media, usually a 
> u-sd, so you get that crap regardless and must physically remove it 
> before a staticly defined, hosts file based network that has not had a 
> functioning dhcpd server even in my original 1998 install of red hat 
> 5.0 will work.

Please stop speading misinformation about how Debian is installed.

Official way to install Debian is using debian-installer, also for 
boards using U-boot.  See e.g. the user notes for Allwinner-based boards 
at 
https://wiki.debian.org/InstallingDebianOn/Allwinner#Install_Using_Debian-Installer

It is true that you can leave it to others to prepare an installation 
for you, so that you only need to dump their pre-installed image onto 
your boot disk device - e.g. as done with the preview image for 
Raspberry Pi offered at https://wiki.debian.org/RaspberryPi3.

It is also true that you can have others make a derivative of Debian and 
offer you that as a pre-installed image - e.g. as done by Raspbian and 
Armbian projects.

The "crap" you get using unofficial pre-installed images is not on 
Debian but on those pre-installing and on you using those instead of 
Debian.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Assorted arm-buster problems - network configuration

[Tixy]

On Fri, 2019-07-05 at 06:54 -0400, Gene Heskett wrote:
> On Friday 05 July 2019 02:56:39 Reco wrote:
[...]
> > Easy. You don't understand what the software does (Gene's here), or
> > you don't need its functions (I'm here) - you just do not install it.
> > You don't fight with it, you don't try to "disable" it in myriad ways,
> > and you do not build assorted kludges alongside of it - you do not
> > install it, simple as that.
> >
> Its not quite that simple on the arm's. You do the install there by 
> dd'ing the complete filesystem image to the boot media, usually a u-sd,

That may be the simplest way, but not the only way. You could boot the
installer and install the OS from scratch.

> so you get that crap regardless and must physically remove it
[...]

That's the price you pay for having the convenience of using prebuilt
images. The alternative of using Debian's installer would have it's own
headaches of trying to work out how to run it, then after to install
and get working the non-free drivers for graphics (and wifi?). And no
doubt there are other mods needed to get things working properly for a
particular board, e.g. getting kernel updates installing correctly.

So, prebuilt images with networking choices that don't suit you is
probably the lesser of the two evils ;-)

-- 
Tixy

Re: Assorted arm-buster problems - network configuration

[Jonas Smedegaard]

Quoting Gene Heskett (2019-07-05 12:35:53)
> On Thursday 04 July 2019 23:54:21 andreimpope...@gmail.com wrote:
> > Just the fact that you are running Raspbian instead of pure Debian 
> > is already an important clue and possibly a major hindrance in 
> > helping you (we don't know what other customizations have been done 
> > to that).
> >
> Humm, someplace, in the last week, I read on a debian site, that 
> raspian was the officially supported armhf version of debian ???  Or 
> was that my imagination, out to play without a chaperone?

Raspbian is a _derivative_ of Debian, not official Debian: 
https://wiki.debian.org/Derivatives/Census/Raspbian


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Friday 05 July 2019 02:56:39 Reco wrote:

> On Thu, Jul 04, 2019 at 09:42:11PM +0100, Brian wrote:
> > On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:
> > > On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> > > > On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > > > > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > I'd also consider exterminating avahi with extreme
> > > > > > prejudice, i.e. 'apt
> > > > > > purge avahi-daemon'. Really simplifies things. Not
> > > > > > installing this software in the first place works even
> > > > > > better.
> > > > >
> > > > > Gene Heskett can follow this advice if he wishes. It is to be
> > > > > hoped that every other user ignores it.
>
> Oh, it seems that I've touched a nerve. My apologies just in case.
>
> > > > Why? It's advice I decided for myself 10 or more years ago after
> > > > seeing constant reports of zeroconf bugs in various OSes and
> > > > kit, and realising that sort of thing was also running on my
> > > > Linux machines. The whole idea of automagically setting up
> > > > networks just sounds like a problem and security hole waiting to
> > > > happen. So I decided to nuke it from orbit, it was the only safe
> > > > thing to do.
> > >
> > > As always, all generalizations suck. Some do avahi, others don't
> > > (full disclosure: I am in the "don't" camp, as many may have
> > > guessed :-)
> >
> > If nobody objects I would like to reword that statement. Many, many
> > users will have avahi-daemon on their systems; a few won't.
>
> [1] says that half of the Debian users participating in popcon have
> avahi-daemon installed. Your assertion that "don't camp" is a minority
> is off. That's a first.
>
> Second, contrary to the popular thinking here, the world does not
> start and does not end with GNOME and x86 along with the CUPS
> installed. And while avahi enhances CUPS' usability indeed, it has
> little usefulness otherwise.
>
I have a networkable printer. Avahi has not in a decade or more ever 
found anything usefull. I've been trying to see it do something usefull, 
but it hasn't been anything but an excedrin headache here.  If it ever 
had a legit use, I've not observed it do anything but break networking 
by feeding bogus info into the system.  That its very good at.

> Third, whatever good avahi does is limited to a single L2 network
> segment by the very definition of how it works. This particular
> problem shows it BTW.
>
> > The idea
> > that
> >
> >   > Not installing this software in the first place works even
> >   > better.
> >
> > requires clarification.
>
> Easy. You don't understand what the software does (Gene's here), or
> you don't need its functions (I'm here) - you just do not install it.
> You don't fight with it, you don't try to "disable" it in myriad ways,
> and you do not build assorted kludges alongside of it - you do not
> install it, simple as that.
>
Its not quite that simple on the arm's. You do the install there by 
dd'ing the complete filesystem image to the boot media, usually a u-sd, 
so you get that crap regardless and must physically remove it before a 
staticly defined, hosts file based network that has not had a 
functioning dhcpd server even in my original 1998 install of red hat 5.0 
will work.
>
> [1] https://qa.debian.org/popcon.php?package=avahi
>
> Reco


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 23:54:21 andreimpope...@gmail.com wrote:

> On Jo, 04 iul 19, 04:42:40, Gene Heskett wrote:
> > On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:
> > > 3. Information on anything (and I do mean anything) else you might
> > > have done to your network configuration after installing buster,
> > > including but not limited to:
> > >  * installing stuff, especially if from source
> >
> > First, on a u-booting raspi you don't "install". You either download
> > an image and put it on a u-sd card with dd, or you generate your own
> > image.
> >
> > Which is what I have done by using a utility from guysoft called
> > RealtimePi, which takes the June 20th version of raspian buster lite
> > apart, and supposedly puts it back together with a realtime patched
> > version of a compatible kernel, which should have been a
> > 4.19.50-rt-v7 kernel, but when put on a u-sd, and the u-sd booted,
> > turns out to have the unpatched kernel in it.  Why I watched it
> > spend an hour building the older 4.4.114-rt-v7 kernel and then it
> > didn't use it is something I have not found yet in the build.log.
> > Which I can't get to ATM because ssh isn't working either.
>
> Just the fact that you are running Raspbian instead of pure Debian is
> already an important clue and possibly a major hindrance in helping
> you (we don't know what other customizations have been done to that).
>
Humm, someplace, in the last week, I read on a debian site, that raspian 
was the officially supported armhf version of debian ???  Or was that my 
imagination, out to play without a chaperone?
   
> I will bet you this though: that image has usable dpkg and apt. If I'm
> right, do you promise to put the "shotgun" away? :)

yup, and if the repos were open...  They are not as I've previously 
posted. I can report that apt --purge does not, I still see 
an /etc/nsswitch.conf, even though ts been purged.

> If I'm wrong I offer to dig up my Raspberry Pi and try to reproduce
> your problems.

I have solved both problems, so that won't be needed.  OTOH, I would be 
interested in how you might make anything newer than wheezy actually 
work on a staticly defined host file based network without a dhcpd 
server on any machine accessible to the local network.  Even wheezy took 
some mods to make it work starting with setting a chattr +i on 
everything network related because that N-M had not yet been taught to 
leave a 'static' defined network alone, or you could load up a root copy 
of mc, and nuke anything that looked like it belonged to N-M. It didn't 
spam the logs with squawks about the immutable flags, so that was a 
plus.

> Kind regards,
> Andrei

Thanks Andrei.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 16:48:56 andreimpope...@gmail.com wrote:

> On Jo, 04 iul 19, 11:40:30, Gene Heskett wrote:
> > > 1. content of /etc/network/interfaces and all files under
> > > /etc/network/interfaces.d/
> >
> > pi@picnc:~ $ cat /etc/network/interfaces.d/*
>
> Is below the literal output of the cat above?
>
> Please post also /etc/network/interfaces.
>
> > auto eth0
> >
> > iface eth0 inet static
> > address 192.168.71.12/24
> > gateway 192.168.71.1
> > post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> >
> > Which the last line disables ipv6  on this machines mostly stretch
> > install.
>
> It doesn't, but IPv6 is not your problem anyway.
>
> > > (I seem to recall you are using ifupdown)
> >
> > What ever works. More often than not, a reboot.
>
> 'ifupdown' is the name of the package providing
> /etc/network/interfaces.
>
> > But if I reboot it from
> > here, I'll have to go to that machine and restart ssh, so lets start
> > with fixing that.
> >
> > > 2. Full output of:
> > > apt list --installed 'network-manager*' # might be empty
> >
> > pi@picnc:~ $ sudo apt list --installed 'network-manager*'
> > Listing... Done
> >
> > > apt list --installed 'avahi*' # might be empty
> >
> > pi@picnc:~ $ sudo apt list --installed 'avahi*'
> > Listing... Done
> > avahi-daemon/testing,now 0.7-4+b1 armhf [installed]
>
> In my understanding 169.254.*.* addresses are configured by
> avahi-autoipd, not avahi-daemon, so this is also not your problem.

I don't recall seeing it. In any event avahi-* has been purged.

> > > systemctl status systemd-networkd
> >
> > pi@picnc:~ $ sudo systemctl status systemd-networkd
> > ● systemd-networkd.service - Network Service
> >Loaded: loaded (/lib/systemd/system/systemd-networkd.service;
> > disabled; vendor preset: enabled) Active: inactive (dead)
> >  Docs: man:systemd-networkd.service(8)
>
> systemd-networkd is also not running, so you can stop blaming systemd.

No, I won't as it created my no ssh problem.  Editing some of the wants 
files fixed that.

> > > ip a # short for 'ip address'
> >
> > pi@picnc:~ $ ip a
> > 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> > group default qlen 1000 link/loopback 00:00:00:00:00:00 brd
> > 00:00:00:00:00:00
> > inet 127.0.0.1/8 scope host lo
> >valid_lft forever preferred_lft forever
> > inet6 ::1/128 scope host
> >valid_lft forever preferred_lft forever
> > 2: eth0:  mtu 1500 qdisc pfifo_fast
> > state UP group default qlen 1000 link/ether b8:27:eb:d3:47:2d brd
> > ff:ff:ff:ff:ff:ff
> > inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
> >valid_lft forever preferred_lft forever
> > inet 169.254.163.253/16 brd 169.254.255.255 scope global
> > noprefixroute eth0 valid_lft forever preferred_lft forever
>
> This is not a problem.

It isn't? Then pray tell, why does it ping yahoo.com from a 169 address?

> > inet6 fe80::1445:918c:cf73:6a79/64 scope link
> >valid_lft forever preferred_lft forever
> > 3: wlan0:  mtu 1500 qdisc
> > pfifo_fast state DOWN group default qlen 1000 link/ether
> > b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff
> >
> > > ip r # short for 'ip route'
> >
> > pi@picnc:~ $ ip r
> > default dev eth0 scope link src 169.254.163.253 metric 202
>
> But this is...
>
> In addition to the full /etc/network/interfaces please post also the
> output of

Its unmodified, and contains only the line to source whatever may be in 
the interfaces.d directory.

> pgrep -a dhcp

no longer exists. apt --purge dhcp made no detectable difference.

Its working correctly now with the killing of the dhcpd5 module and its 
purging.

So I now know what will make it just work. Next is to figure out how to 
get this kernel installed to that image so that 4.19.50-rt-v7 is booted.

Then I can build linuxcnc for it, I hope, but that mailing list tells me 
that some linuxcnc dependencies have been removed from buster, so the 
build will no doubt _not_ be fun.

There are folks here who will violently disapprove of my sledgehammer or 
shotgun approach to this, and I would remind people that I bought these 
things to USE, and whatever makes them usable is what I will do.  As 
shipped, the armhf images are NOT usable. Make them usable as shipped, 
and I will use them as shipped. It really is that simple.

> Kind regards,
> Andrei

Thank you very much for trying to help Andrei, it in fact was quite 
helpfull, as was a comment some else made about dhcp making up stuff 
when there was no available server.  Thats BS that will with the right 
amount of rain, grow 200+ bushels an acre, it should return NOTHING AT 
ALL except a no server found error if there is not a server.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Curt]

On 2019-07-05, Gene Heskett  wrote:
>
> pi@picnc:/ $ sudo apt update
> Get:1 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
> Get:2 http://archive.raspberrypi.org/debian buster InRelease [25.1 kB]
> Reading package lists... Done
> E: Release file for 
> http://raspbian.raspberrypi.org/raspbian/dists/buster/InRelease is not valid 
> yet (invalid for another 12d 21h 
> 12min 47s). Updates for this repository will not be applied.
> E: Release file for 
> http://archive.raspberrypi.org/debian/dists/buster/InRelease is not valid yet 
> (invalid for another 10d 12h 43min 
> 27s). Updates for this repository will not be applied.
>
> So what sort of a surprise are they fixing to throw at us this time?

Check your system clock/timezone?

> Anyway, now I know what to do to get that stuff out of my thinning hair.
>
> And I can do it while the u-sd card is still in the writer gizmo before
> its ever plugged into the pi.
>
> Heck, maybe running on buster, I can get RealtimePi to build me a 
> 4.19.50-rt-v7 kernel?  'Spose?  ;-)
>
> Cheers, Gene Heskett


-- 
"These findings demonstrate that under appropriate conditions the isolated,
intact large mammalian brain possesses an underappreciated capacity for
restoration of microcirculation and molecular and cellular activity after a
prolonged post-mortem interval." From a recent article in *Nature*. Holy shit. 

Re: Assorted arm-buster problems - network configuration

[Brian]

On Fri 05 Jul 2019 at 09:56:39 +0300, Reco wrote:

> On Thu, Jul 04, 2019 at 09:42:11PM +0100, Brian wrote:
> > On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:
> > 
> > > On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> > > > On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > > > > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > I'd also consider exterminating avahi with extreme prejudice, i.e.
> > > > > > 'apt
> > > > > > purge avahi-daemon'. Really simplifies things. Not installing this
> > > > > > software in the first place works even better.
> > > > > 
> > > > > Gene Heskett can follow this advice if he wishes. It is to be hoped
> > > > > that every other user ignores it.
> 
> Oh, it seems that I've touched a nerve. My apologies just in case.

No need to apologise. I was intrigued with the suggestion and simply
wondered what the technical reason was and how not installing avahi
would benefit a user.
 
> > > > Why? It's advice I decided for myself 10 or more years ago after seeing
> > > > constant reports of zeroconf bugs in various OSes and kit, and
> > > > realising that sort of thing was also running on my Linux machines. The
> > > > whole idea of automagically setting up networks just sounds like a
> > > > problem and security hole waiting to happen. So I decided to nuke it
> > > > from orbit, it was the only safe thing to do.
> > > 
> > > As always, all generalizations suck. Some do avahi, others don't (full
> > > disclosure: I am in the "don't" camp, as many may have guessed :-)
> > 
> > If nobody objects I would like to reword that statement. Many, many
> > users will have avahi-daemon on their systems; a few won't.
> 
> [1] says that half of the Debian users participating in popcon have
> avahi-daemon installed. Your assertion that "don't camp" is a minority
> is off. That's a first.

Popularity contest statistics are a rough and ready basis for deciding
on a course of action, but sufficient to counter a rough and ready
argument.

http://joeyh.name/blog/entry/the_popcon_problem/

> Second, contrary to the popular thinking here, the world does not start
> and does not end with GNOME and x86 along with the CUPS installed.
> And while avahi enhances CUPS' usability indeed, it has little
> usefulness otherwise.

The enhancements it brings to the printing system are sufficient to more
than justify its place on a user's machine.

> Third, whatever good avahi does is limited to a single L2 network
> segment by the very definition of how it works. This particular problem
> shows it BTW.
> 
> 
> > The idea
> > that
> > 
> >   > Not installing this software in the first place works even better.
> > 
> > requires clarification.
> 
> Easy. You don't understand what the software does (Gene's here), or you
> don't need its functions (I'm here) - you just do not install it. You
> don't fight with it, you don't try to "disable" it in myriad ways, and
> you do not build assorted kludges alongside of it - you do not install
> it, simple as that.
> 
> 
> [1] https://qa.debian.org/popcon.php?package=avahi

Not installing avahi-daemon or purging it when it is not required is
reasonable; I do both on some machines here.

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 16:44:14 to...@tuxteam.de wrote:

> On Thu, Jul 04, 2019 at 09:42:11PM +0100, Brian wrote:
> > On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:
>
> [...]
>
> > > As always, all generalizations suck. Some do avahi, others don't
> > > (full disclosure: I am in the "don't" camp, as many may have
> > > guessed :-)
> >
> > If nobody objects I would like to reword that statement. Many, many
> > users will have avahi-daemon on their systems; a few won't. The idea
> > that
> >
> >   > Not installing this software in the first place works even
> >   > better.
> >
> > requires clarification.
>
> Clever move :-)
>
> Cheers
> -- t

Just one problem when dealing with an armhf or arm64 that u-boots.  Short 
of writing the image to the u-sd, then mounting it and editing that 
image to delete the stuff, which is how I will do the next image I burn, 
there is with the present method of assembling that image, no way to 
prevent its installation. That build script needs a user usable editor. 
But I've no clue if that script has ever been publicly shared.

I will be very interested in the armbian release, which apparently uses 
xfce4, but I've not noted that they have an image for the armhf's.  The 
arm64 version running on a 4Gig rock64 is very impressive, at least 10x 
faster than the pi. And so far stable.  I only know of one app that will 
crash it, amanda, the backup program.  When the server touches it to get 
an estimate, it locks up tight till a powerdown reboot.  Stretch 
version.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 16:42:11 Brian wrote:

> On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:
> > On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> > > On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > > > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > > >
> > > > [...]
> > > >
> > > > > I'd also consider exterminating avahi with extreme prejudice,
> > > > > i.e. 'apt
> > > > > purge avahi-daemon'. Really simplifies things. Not installing
> > > > > this software in the first place works even better.
> > > >
> > > > Gene Heskett can follow this advice if he wishes. It is to be
> > > > hoped that every other user ignores it.
> > >
> > > Why? It's advice I decided for myself 10 or more years ago after
> > > seeing constant reports of zeroconf bugs in various OSes and kit,
> > > and realising that sort of thing was also running on my Linux
> > > machines. The whole idea of automagically setting up networks just
> > > sounds like a problem and security hole waiting to happen. So I
> > > decided to nuke it from orbit, it was the only safe thing to do.
> >
> > As always, all generalizations suck. Some do avahi, others don't
> > (full disclosure: I am in the "don't" camp, as many may have guessed
> > :-)
>
> If nobody objects I would like to reword that statement. Many, many
> users will have avahi-daemon on their systems; a few won't. The idea
> that
>
>   > Not installing this software in the first place works even better.
>
> requires clarification.

Aha! Took several more hours but I found the SOB screwing my static
network!  S

Here is your Clarification: I used apt to purge avahi-daemon which 
took nsswitch with it, no help on networking restart, killed dhcp, 
restart unaffected, killed dhcpd5, restarted networking and 
everything works like it is supposed to.  Crawls the net like a pro.

ip a out for eth0 now:
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
   valid_lft forever preferred_lft forever

ip r out for eth0 now:
pi@picnc:/ $ ip r
default via 192.168.71.1 dev eth0 onlink
192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12

Just one fly in this ointment, can't update via apt, repos are locked 
until 12d ahead for one server, and 10d ahead for the other.

pi@picnc:/ $ sudo apt update
Get:1 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Get:2 http://archive.raspberrypi.org/debian buster InRelease [25.1 kB]
Reading package lists... Done
E: Release file for 
http://raspbian.raspberrypi.org/raspbian/dists/buster/InRelease is not valid 
yet (invalid for another 12d 21h 
12min 47s). Updates for this repository will not be applied.
E: Release file for 
http://archive.raspberrypi.org/debian/dists/buster/InRelease is not valid yet 
(invalid for another 10d 12h 43min 
27s). Updates for this repository will not be applied.

So what sort of a surprise are they fixing to throw at us this time?

Anyway, now I know what to do to get that stuff out of my thinning hair.

And I can do it while the u-sd card is still in the writer gizmo before
its ever plugged into the pi.

Heck, maybe running on buster, I can get RealtimePi to build me a 
4.19.50-rt-v7 kernel?  'Spose?  ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Reco]

On Thu, Jul 04, 2019 at 09:42:11PM +0100, Brian wrote:
> On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:
> 
> > On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> > > On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > > > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > I'd also consider exterminating avahi with extreme prejudice, i.e.
> > > > > 'apt
> > > > > purge avahi-daemon'. Really simplifies things. Not installing this
> > > > > software in the first place works even better.
> > > > 
> > > > Gene Heskett can follow this advice if he wishes. It is to be hoped
> > > > that every other user ignores it.

Oh, it seems that I've touched a nerve. My apologies just in case.


> > > Why? It's advice I decided for myself 10 or more years ago after seeing
> > > constant reports of zeroconf bugs in various OSes and kit, and
> > > realising that sort of thing was also running on my Linux machines. The
> > > whole idea of automagically setting up networks just sounds like a
> > > problem and security hole waiting to happen. So I decided to nuke it
> > > from orbit, it was the only safe thing to do.
> > 
> > As always, all generalizations suck. Some do avahi, others don't (full
> > disclosure: I am in the "don't" camp, as many may have guessed :-)
> 
> If nobody objects I would like to reword that statement. Many, many
> users will have avahi-daemon on their systems; a few won't.

[1] says that half of the Debian users participating in popcon have
avahi-daemon installed. Your assertion that "don't camp" is a minority
is off. That's a first.

Second, contrary to the popular thinking here, the world does not start
and does not end with GNOME and x86 along with the CUPS installed.
And while avahi enhances CUPS' usability indeed, it has little
usefulness otherwise.

Third, whatever good avahi does is limited to a single L2 network
segment by the very definition of how it works. This particular problem
shows it BTW.


> The idea
> that
> 
>   > Not installing this software in the first place works even better.
> 
> requires clarification.

Easy. You don't understand what the software does (Gene's here), or you
don't need its functions (I'm here) - you just do not install it. You
don't fight with it, you don't try to "disable" it in myriad ways, and
you do not build assorted kludges alongside of it - you do not install
it, simple as that.


[1] https://qa.debian.org/popcon.php?package=avahi

Reco

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Jo, 04 iul 19, 04:42:40, Gene Heskett wrote:
> On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:
> >
> > 3. Information on anything (and I do mean anything) else you might
> > have done to your network configuration after installing buster,
> > including but not limited to:
> >  * installing stuff, especially if from source
> First, on a u-booting raspi you don't "install". You either download an 
> image and put it on a u-sd card with dd, or you generate your own image.
> 
> Which is what I have done by using a utility from guysoft called 
> RealtimePi, which takes the June 20th version of raspian buster lite 
> apart, and supposedly puts it back together with a realtime patched 
> version of a compatible kernel, which should have been a 4.19.50-rt-v7 
> kernel, but when put on a u-sd, and the u-sd booted, turns out to have 
> the unpatched kernel in it.  Why I watched it spend an hour building the 
> older 4.4.114-rt-v7 kernel and then it didn't use it is something I have 
> not found yet in the build.log. Which I can't get to ATM because ssh 
> isn't working either.

Just the fact that you are running Raspbian instead of pure Debian is 
already an important clue and possibly a major hindrance in helping you 
(we don't know what other customizations have been done to that).

I will bet you this though: that image has usable dpkg and apt. If I'm 
right, do you promise to put the "shotgun" away? :)

If I'm wrong I offer to dig up my Raspberry Pi and try to reproduce your 
problems.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 16:05:09 to...@tuxteam.de wrote:

> On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> > On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > >
> > > [...]
> > >
> > > > I'd also consider exterminating avahi with extreme prejudice,
> > > > i.e. 'apt
> > > > purge avahi-daemon'. Really simplifies things. Not installing
> > > > this software in the first place works even better.
> > >
> > > Gene Heskett can follow this advice if he wishes. It is to be
> > > hoped that every other user ignores it.
> >
> > Why? It's advice I decided for myself 10 or more years ago after
> > seeing constant reports of zeroconf bugs in various OSes and kit,
> > and realising that sort of thing was also running on my Linux
> > machines. The whole idea of automagically setting up networks just
> > sounds like a problem and security hole waiting to happen. So I
> > decided to nuke it from orbit, it was the only safe thing to do.
>
> As always, all generalizations suck. Some do avahi, others don't (full
> disclosure: I am in the "don't" camp, as many may have guessed :-)
>
> Still, I dislike such statements as "exterminate". But YMMV.
>
> Cheers
> -- t
In this case, it made zero difference. It. nsswtch, dhcpd and all its ilk 
have been purged, but the default routes remain stubbornly, even over 
powerdown reboots, at 169.254.0.0/16. I next will grep the whole system 
looking for it and any file containing it will get edited to replace it 
with MY 192.168.nn/24 domain. If that doesn't fix it, it gets nuked. 
Since It nothing but a 64GB u-sd card I can rewrite in 10 minutes, I 
officially don't care if I destroy its ability to boot. It also has a 
duff kernel, RealtimePi having been watched as it spent an hour building 
a 4.4.114 rt kernel, but then reused the 4.19.50 kernel in the original 
image's zip. So I wind up with an identicaly functioning 2019-06-20 
buster image for nominally 4 hours work by the pi 3b.

I do have a good stretch version but with an earlier rt kernel, which 
works very well except for the nominal 2 frames a second video speeds. 
latency-test reports 28 u-secs of jitter in the 1 kilohertz servo 
thread, compared to a jessie builds 70+ microseconds.

Buster however is supposed to have faster video, but w/o a network I 
can't install the test tools to measure it, this is the main pusher to 
make buster work.  And I can't measure the video speeds without a 
network.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Jo, 04 iul 19, 11:40:30, Gene Heskett wrote:
> >
> > 1. content of /etc/network/interfaces and all files under
> > /etc/network/interfaces.d/
> pi@picnc:~ $ cat /etc/network/interfaces.d/*

Is below the literal output of the cat above?

Please post also /etc/network/interfaces.

> auto eth0
> 
> iface eth0 inet static
> address 192.168.71.12/24
> gateway 192.168.71.1
> post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> 
> Which the last line disables ipv6  on this machines mostly stretch install.

It doesn't, but IPv6 is not your problem anyway.

> > (I seem to recall you are using ifupdown)
> What ever works. More often than not, a reboot.

'ifupdown' is the name of the package providing /etc/network/interfaces.

> But if I reboot it from
> here, I'll have to go to that machine and restart ssh, so lets start 
> with fixing that.
> >
> > 2. Full output of:
> > apt list --installed 'network-manager*' # might be empty
> pi@picnc:~ $ sudo apt list --installed 'network-manager*'
> Listing... Done
> 
> > apt list --installed 'avahi*' # might be empty
> pi@picnc:~ $ sudo apt list --installed 'avahi*'
> Listing... Done
> avahi-daemon/testing,now 0.7-4+b1 armhf [installed]

In my understanding 169.254.*.* addresses are configured by 
avahi-autoipd, not avahi-daemon, so this is also not your problem.

> > systemctl status systemd-networkd
> pi@picnc:~ $ sudo systemctl status systemd-networkd
> ● systemd-networkd.service - Network Service
>Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; 
> vendor preset: enabled)
>Active: inactive (dead)
>  Docs: man:systemd-networkd.service(8)
 
systemd-networkd is also not running, so you can stop blaming systemd.

> > ip a # short for 'ip address'
> pi@picnc:~ $ ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
> default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> group default qlen 1000
> link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
> inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
>valid_lft forever preferred_lft forever
> inet 169.254.163.253/16 brd 169.254.255.255 scope global noprefixroute 
> eth0
>valid_lft forever preferred_lft forever

This is not a problem.

> inet6 fe80::1445:918c:cf73:6a79/64 scope link
>valid_lft forever preferred_lft forever
> 3: wlan0:  mtu 1500 qdisc pfifo_fast state 
> DOWN group default qlen 1000
> link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff
> 
> > ip r # short for 'ip route'
> pi@picnc:~ $ ip r
> default dev eth0 scope link src 169.254.163.253 metric 202

But this is...

In addition to the full /etc/network/interfaces please post also the 
output of

pgrep -a dhcp

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Assorted arm-buster problems - network configuration

[tomas]

On Thu, Jul 04, 2019 at 09:42:11PM +0100, Brian wrote:
> On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:

[...]

> > As always, all generalizations suck. Some do avahi, others don't (full
> > disclosure: I am in the "don't" camp, as many may have guessed :-)
> 
> If nobody objects I would like to reword that statement. Many, many
> users will have avahi-daemon on their systems; a few won't. The idea
> that
> 
>   > Not installing this software in the first place works even better.
> 
> requires clarification.

Clever move :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Assorted arm-buster problems - network configuration

[Brian]

On Thu 04 Jul 2019 at 22:05:09 +0200, to...@tuxteam.de wrote:

> On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> > On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > > 
> > > [...]
> > > 
> > > > I'd also consider exterminating avahi with extreme prejudice, i.e.
> > > > 'apt
> > > > purge avahi-daemon'. Really simplifies things. Not installing this
> > > > software in the first place works even better.
> > > 
> > > Gene Heskett can follow this advice if he wishes. It is to be hoped
> > > that every other user ignores it.
> > 
> > Why? It's advice I decided for myself 10 or more years ago after seeing
> > constant reports of zeroconf bugs in various OSes and kit, and
> > realising that sort of thing was also running on my Linux machines. The
> > whole idea of automagically setting up networks just sounds like a
> > problem and security hole waiting to happen. So I decided to nuke it
> > from orbit, it was the only safe thing to do.
> 
> As always, all generalizations suck. Some do avahi, others don't (full
> disclosure: I am in the "don't" camp, as many may have guessed :-)

If nobody objects I would like to reword that statement. Many, many
users will have avahi-daemon on their systems; a few won't. The idea
that

  > Not installing this software in the first place works even better.

requires clarification.

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[tomas]

On Thu, Jul 04, 2019 at 08:56:45PM +0100, Tixy wrote:
> On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> > On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> > 
> > [...]
> > 
> > > I'd also consider exterminating avahi with extreme prejudice, i.e.
> > > 'apt
> > > purge avahi-daemon'. Really simplifies things. Not installing this
> > > software in the first place works even better.
> > 
> > Gene Heskett can follow this advice if he wishes. It is to be hoped
> > that every other user ignores it.
> 
> Why? It's advice I decided for myself 10 or more years ago after seeing
> constant reports of zeroconf bugs in various OSes and kit, and
> realising that sort of thing was also running on my Linux machines. The
> whole idea of automagically setting up networks just sounds like a
> problem and security hole waiting to happen. So I decided to nuke it
> from orbit, it was the only safe thing to do.

As always, all generalizations suck. Some do avahi, others don't (full
disclosure: I am in the "don't" camp, as many may have guessed :-)

Still, I dislike such statements as "exterminate". But YMMV.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Assorted arm-buster problems - network configuration

[Tixy]

On Thu, 2019-07-04 at 20:01 +0100, Brian wrote:
> On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:
> 
> [...]
> 
> > I'd also consider exterminating avahi with extreme prejudice, i.e.
> > 'apt
> > purge avahi-daemon'. Really simplifies things. Not installing this
> > software in the first place works even better.
> 
> Gene Heskett can follow this advice if he wishes. It is to be hoped
> that every other user ignores it.

Why? It's advice I decided for myself 10 or more years ago after seeing
constant reports of zeroconf bugs in various OSes and kit, and
realising that sort of thing was also running on my Linux machines. The
whole idea of automagically setting up networks just sounds like a
problem and security hole waiting to happen. So I decided to nuke it
from orbit, it was the only safe thing to do.

-- 
Tixy

Re: Assorted arm-buster problems - network configuration

[Brian]

On Thu 04 Jul 2019 at 19:18:13 +0300, Reco wrote:

[...]

> I'd also consider exterminating avahi with extreme prejudice, i.e. 'apt
> purge avahi-daemon'. Really simplifies things. Not installing this
> software in the first place works even better.

Gene Heskett can follow this advice if he wishes. It is to be hoped
that every other user ignores it.

-- 
Brian.

Re: Assorted arm-buster problems - network configuration

[Lee]

On 7/4/19, Gene Heskett  wrote:
> On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:
>
>> On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
>> > On Wednesday 03 July 2019 16:12:31 Reco wrote:
>> >
>> > And Gene moved. Question unanswered yet.
>> >
>> > >  Hi.
>> > >
>> > > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
>> > > > Regardless of what I do, I cannot get rid of the avahi junk in
>> > > > an ip a report, so my local 192.168.xx.nn/24 net is the only
>> > > > thing that works. pinging a net name like yahoo.com gets me a
>> > > > successful address. But no response from yahoo because its
>> > > > sending the ping from an avahi based address, which since thats
>> > > > outside of my /24 netmask, doesn't get thru the router.
>> > > >
>> > > > So, how do I get rid of the avahi stuff?
>> > > >
>> > > > I've a nominally 10 machine 192.168.nn.xx that is 100% static
>> > > > based on host files so I want avahi absolutely and totally
>> > > > neutered, emasculated, gone Forever plus 100 years at least.
>> > > >
>> > > > How can I do that?
>>
>> It's not necessarily avahi doing that. A DHCP client might also
>> configure a 169.254.*.* address for you if it doesn't receive a reply.
>>
>> In order to have the slightest chance of helping you it is necessary
>> for you to provide the information as per below.
>>
>> Files should preferably be attached, to avoid issues with copy-paste.
>>
>> Please do not edit anything except to obscure private information
>> (e.g. passwords or a public IP you don't want to post).
>>
> I have restarted ssh, so now thats working and I'm logged in.  I will use
> copy/paste but I'll do word wrapping by hand.
>>
>> 1. content of /etc/network/interfaces and all files under
>> /etc/network/interfaces.d/
> pi@picnc:~ $ cat /etc/network/interfaces.d/*
> auto eth0
>
> iface eth0 inet static
> address 192.168.71.12/24
> gateway 192.168.71.1
> post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
>
> Which the last line disables ipv6  on this machines mostly stretch install.
>
>> (I seem to recall you are using ifupdown)
> What ever works. More often than not, a reboot.  But if I reboot it from
> here, I'll have to go to that machine and restart ssh, so lets start
> with fixing that.
>>
>> 2. Full output of:
>> apt list --installed 'network-manager*' # might be empty
> pi@picnc:~ $ sudo apt list --installed 'network-manager*'
> Listing... Done
>
>> apt list --installed 'avahi*' # might be empty
> pi@picnc:~ $ sudo apt list --installed 'avahi*'
> Listing... Done
> avahi-daemon/testing,now 0.7-4+b1 armhf [installed]
>
>> systemctl status systemd-networkd
> pi@picnc:~ $ sudo systemctl status systemd-networkd
> ● systemd-networkd.service - Network Service
>Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled;
> vendor preset: enabled)
>Active: inactive (dead)
>  Docs: man:systemd-networkd.service(8)
>
>
>> ip a # short for 'ip address'
> pi@picnc:~ $ ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
> default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
> inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
>valid_lft forever preferred_lft forever
> inet 169.254.163.253/16 brd 169.254.255.255 scope global noprefixroute
> eth0
>valid_lft forever preferred_lft forever
> inet6 fe80::1445:918c:cf73:6a79/64 scope link
>valid_lft forever preferred_lft forever
> 3: wlan0:  mtu 1500 qdisc pfifo_fast
> state DOWN group default qlen 1000
> link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff

I'm guessing that
1. your machine is set up to request an ip address via dhcp
2. the dhcp client software isn't smart enough to realize you've
configured a static address on the interface and tries to get an
address via dhcp anyway, fails, and assigns a 169.254.x.x address to
the interface

Best bet would be to turn off dhcp on that interface.  I don't
remember if I couldn't figure out how to disable dhcp or if it was
just that I _really_ don't want anything of mine doing mDNS; in any
case, I nuked avahi:

$ apt list --installed 'avahi*'
Listing... Done

Regards,
Lee

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 12:18:13 Reco wrote:

>   Hi.
>
> On Thu, Jul 04, 2019 at 11:40:30AM -0400, Gene Heskett wrote:
> > On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:
> > > On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
> > > > On Wednesday 03 July 2019 16:12:31 Reco wrote:
> > > >
> > > > And Gene moved. Question unanswered yet.
>
> Some of us are still working every day to earn that paycheck at the
> end of the month, you know ;)

Yeah, terrible state of affairs. :)  Social Security, the biggest ponzi 
scheme on the planet. If you or I done it. they'd jack up the jail, 
throw us under it and set it back down on us. And claim they've never 
heard of us. :( 

>
> > > > > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
> > > > > > Regardless of what I do, I cannot get rid of the avahi junk
> > > > > > in an ip a report, so my local 192.168.xx.nn/24 net is the
> > > > > > only thing that works. pinging a net name like yahoo.com
> > > > > > gets me a successful address. But no response from yahoo
> > > > > > because its sending the ping from an avahi based address,
> > > > > > which since thats outside of my /24 netmask, doesn't get
> > > > > > thru the router.
> > > > > >
> > > > > > So, how do I get rid of the avahi stuff?
> > > > > >
> > > > > > I've a nominally 10 machine 192.168.nn.xx that is 100%
> > > > > > static based on host files so I want avahi absolutely and
> > > > > > totally neutered, emasculated, gone Forever plus 100 years
> > > > > > at least.
>
> ...
>
> > pi@picnc:~ $ cat /etc/network/interfaces.d/*
> > auto eth0
> >
> > iface eth0 inet static
> > address 192.168.71.12/24
> > gateway 192.168.71.1
> > post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> >
> > > ip r # short for 'ip route'
> >
> > pi@picnc:~ $ ip r
> > default dev eth0 scope link src 169.254.163.253 metric 202
> > 169.254.0.0/16 dev eth0 scope link src 169.254.163.253 metric 202
> > 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12
>
> These caught my attention.
> What about this trick (metric is 1024 unless you define it, and
> default route with lower metric wins):
>
Those that are set are set to metric 202.  And the metric 24 had no 
effect, and error someplace it does not identify.

> auto eth0
>   iface eth0 inet static
>   address 192.168.71.12/24
>   gateway 192.168.71.1
>   metric 64
>   post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
But I'll leave it that way and reboot, which means I'll have to goto its 
own keyboard and restart ssh. Which then works...???  Why is that?

> There's also another dirty trick:
>
> mkdir /etc/systemd/system/avahi-daemon.service.d
> cat > /etc/systemd/system/avahi-daemon.service.d/override.conf < [Service]
> PrivateNetwork=yes
> EOF
> systemctl daemon-reload
> systemctl restart avahi-daemon

With it purged, waste of time by my reasoning, but I'll print this and go 
do it anyway.

> I'd also consider exterminating avahi with extreme prejudice, i.e.
> 'apt purge avahi-daemon'. Really simplifies things. Not installing
> this software in the first place works even better.
>
That also has been done just before a powerdown reboot. But now, even 
though service ssh status says it up and running, I can't login from 
here. And getting rid of avahi and libnsswch or whatever its called made 
no difference in the ip a or ip r reports. But hang on, I'm going to see 
why ssh isn't working at all now.

Thanks Reco


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[mick crane]

On 2019-07-04 15:40, Gene Heskett wrote:

On Thursday 04 July 2019 06:15:56 mick crane wrote:


On 2019-07-04 09:42, Gene Heskett wrote:


> Sorry, I don't see it that way, I see a concentrated effort to make
> me use dhcpd, instead of static, every machine in the system knows
> the address of ALL the other machines on my local 192.168.xx.nn/24
> network.
>
> Using dhcp means I'd have to setup a 2nd this side of my router. I
> will try to make ssh work later today, and I will reanswer this
> message if I can do that.

I like having ipfire or pfsense  on a separate box doing DHCP server.
you can make other PCs static by making their lease fixed.
and then everything is in one place.
well that's how I understand it anyway.

mick.

I do have a dhcpd configured in dd-wrt. but its set to only respond to
the MAC's of my sons smartfones when they come by and I enable the
radio. That way their phones can use my bandwidth. If I could control
which way those are bridged so the local AMC's see locals at fixed
addresses, while the wifi stuff is bridged only to the internet, that
would be ideal.


pfsense, ipfire have got handy web GUI's for all that.
I have WAP plugged in that is blocked to the local network but allowed 
to the internet.


got to say I admire your tenacity.

cheers

mick

--
Key ID4BFEBB31

Re: Assorted arm-buster problems - network configuration

[Reco]

Hi.

On Thu, Jul 04, 2019 at 11:40:30AM -0400, Gene Heskett wrote:
> On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:
> 
> > On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
> > > On Wednesday 03 July 2019 16:12:31 Reco wrote:
> > >
> > > And Gene moved. Question unanswered yet.

Some of us are still working every day to earn that paycheck at the end
of the month, you know ;)


> > > > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
> > > > > Regardless of what I do, I cannot get rid of the avahi junk in
> > > > > an ip a report, so my local 192.168.xx.nn/24 net is the only
> > > > > thing that works. pinging a net name like yahoo.com gets me a
> > > > > successful address. But no response from yahoo because its
> > > > > sending the ping from an avahi based address, which since thats
> > > > > outside of my /24 netmask, doesn't get thru the router.
> > > > >
> > > > > So, how do I get rid of the avahi stuff?
> > > > >
> > > > > I've a nominally 10 machine 192.168.nn.xx that is 100% static
> > > > > based on host files so I want avahi absolutely and totally
> > > > > neutered, emasculated, gone Forever plus 100 years at least.
...
> pi@picnc:~ $ cat /etc/network/interfaces.d/*
> auto eth0
> 
> iface eth0 inet static
> address 192.168.71.12/24
> gateway 192.168.71.1
> post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> 

> > ip r # short for 'ip route'
> pi@picnc:~ $ ip r
> default dev eth0 scope link src 169.254.163.253 metric 202
> 169.254.0.0/16 dev eth0 scope link src 169.254.163.253 metric 202
> 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12

These caught my attention.
What about this trick (metric is 1024 unless you define it, and default
route with lower metric wins):

auto eth0
iface eth0 inet static
address 192.168.71.12/24
gateway 192.168.71.1
metric 64
post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6

There's also another dirty trick:

mkdir /etc/systemd/system/avahi-daemon.service.d
cat > /etc/systemd/system/avahi-daemon.service.d/override.conf <

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:

> On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
> > On Wednesday 03 July 2019 16:12:31 Reco wrote:
> >
> > And Gene moved. Question unanswered yet.
> >
> > >   Hi.
> > >
> > > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
> > > > Regardless of what I do, I cannot get rid of the avahi junk in
> > > > an ip a report, so my local 192.168.xx.nn/24 net is the only
> > > > thing that works. pinging a net name like yahoo.com gets me a
> > > > successful address. But no response from yahoo because its
> > > > sending the ping from an avahi based address, which since thats
> > > > outside of my /24 netmask, doesn't get thru the router.
> > > >
> > > > So, how do I get rid of the avahi stuff?
> > > >
> > > > I've a nominally 10 machine 192.168.nn.xx that is 100% static
> > > > based on host files so I want avahi absolutely and totally
> > > > neutered, emasculated, gone Forever plus 100 years at least.
> > > >
> > > > How can I do that?
>
> It's not necessarily avahi doing that. A DHCP client might also
> configure a 169.254.*.* address for you if it doesn't receive a reply.
>
> In order to have the slightest chance of helping you it is necessary
> for you to provide the information as per below.
>
> Files should preferably be attached, to avoid issues with copy-paste.
>
> Please do not edit anything except to obscure private information
> (e.g. passwords or a public IP you don't want to post).
>
I have restarted ssh, so now thats working and I'm logged in.  I will use 
copy/paste but I'll do word wrapping by hand.
>
> 1. content of /etc/network/interfaces and all files under
> /etc/network/interfaces.d/
pi@picnc:~ $ cat /etc/network/interfaces.d/*
auto eth0

iface eth0 inet static
address 192.168.71.12/24
gateway 192.168.71.1
post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6

Which the last line disables ipv6  on this machines mostly stretch install.

> (I seem to recall you are using ifupdown)
What ever works. More often than not, a reboot.  But if I reboot it from
here, I'll have to go to that machine and restart ssh, so lets start 
with fixing that.
>
> 2. Full output of:
> apt list --installed 'network-manager*' # might be empty
pi@picnc:~ $ sudo apt list --installed 'network-manager*'
Listing... Done

> apt list --installed 'avahi*' # might be empty
pi@picnc:~ $ sudo apt list --installed 'avahi*'
Listing... Done
avahi-daemon/testing,now 0.7-4+b1 armhf [installed]

> systemctl status systemd-networkd
pi@picnc:~ $ sudo systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; 
vendor preset: enabled)
   Active: inactive (dead)
 Docs: man:systemd-networkd.service(8)


> ip a # short for 'ip address'
pi@picnc:~ $ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
   valid_lft forever preferred_lft forever
inet 169.254.163.253/16 brd 169.254.255.255 scope global noprefixroute eth0
   valid_lft forever preferred_lft forever
inet6 fe80::1445:918c:cf73:6a79/64 scope link
   valid_lft forever preferred_lft forever
3: wlan0:  mtu 1500 qdisc pfifo_fast state 
DOWN group default qlen 1000
link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff

> ip r # short for 'ip route'
pi@picnc:~ $ ip r
default dev eth0 scope link src 169.254.163.253 metric 202
169.254.0.0/16 dev eth0 scope link src 169.254.163.253 metric 202
192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12

>
> 3. Information on anything (and I do mean anything) else you might
> have done to your network configuration after installing buster,
> including but not limited to:
>  * installing stuff, especially if from source
>  * removing stuff (especially if not 'purged', dpkg -l would tell)
>  * manual changes to files (deletions/permissions/etc.
>  (especially those unnecessary "fixes" you call "neutering")
>
> For the record/archives: other users are not seeing your problems.
>
> Buster is - at least for me - the best Debian release yet.
>
> The problems you are seeing are, at least partially, of your own
> doing, most likely due to wrong configuration and an

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 06:15:56 mick crane wrote:

> On 2019-07-04 09:42, Gene Heskett wrote:
> 
>
> > Sorry, I don't see it that way, I see a concentrated effort to make
> > me use dhcpd, instead of static, every machine in the system knows
> > the address of ALL the other machines on my local 192.168.xx.nn/24
> > network.
> >
> > Using dhcp means I'd have to setup a 2nd this side of my router. I
> > will try to make ssh work later today, and I will reanswer this
> > message if I can do that.
>
> I like having ipfire or pfsense  on a separate box doing DHCP server.
> you can make other PCs static by making their lease fixed.
> and then everything is in one place.
> well that's how I understand it anyway.
>
> mick.
I do have a dhcpd configured in dd-wrt. but its set to only respond to 
the MAC's of my sons smartfones when they come by and I enable the 
radio. That way their phones can use my bandwidth. If I could control 
which way those are bridged so the local AMC's see locals at fixed 
addresses, while the wifi stuff is bridged only to the internet, that 
would be ideal.  But I don't believe I can control the bridge direction 
based on the MAC of the client. So I'd have to setup a separate server, 
ideally in the distribution switch, that assigned a dhcp address 
according to the incoming MAC. In my lashup, I have a managed switch, 
but its running the default setup which does not enable a dhcpd, if it 
even has one.  And I can't think of a way to ping picnc, and reliably 
hit 192.168.xx.yy, the address of picnc. Using host files for local dns 
is so much simpler.

Now I've been standing in front of its monitor for about an hour, a neck 
breaker because its well above my eye level. With NIX-Crafts ip tutorial 
in hand, trying to get rid of the default route in the 169.254 range, 
and while it may not return a syntax error thats usually gibberish, 
showing something thats totally disconnected from what I told it to do, 
there is no way in hell to delete the 169.junk from an ip r report. And 
this is with a sudo in front of whatever.

If I try to ping yahoo.com it properly asks my isp's dns for an address 
for yahoo, gets it and displays it but then pings it from the 169 
address, which is of coarse sent to /dev/null in the router if it even 
gets that far as it must traverse the switch to get that far.

I've tried to dpkg --purge the dhcp* stuff I can see, but dpkg says its 
not installed so it must be in the kernel, a non-realtime 4.19.50 for 
armhf.  So unless someone can tell me how to nuke, or at least change 
its preference for the 169 crap as defaults, this rpi-3b will never be 
able to run on buster. I must be able to make it use the 
192.168.nn.hostname-address for everything. But something is overriding 
me.

What is it?  And can I nuke or otherwise disable it?

The scripts in /etc/init.d for both avahi-daemon and dhcpd have been 
removed by rm.  Made absolutely zero difference to an ip a or ip r 
report. I can only conclude that systemd thinks its smarter than me. I 
have armbian installed on a rock64, and there I had a heck of a time 
with the stretch version of this same routing problem, but duplicating 
that setup on buster, and getting working results cannot be done with 
the tools at hand.

Someone gave me a link to a systemd tut, a pdf I was gonna print but its 
almost 40 pages thats both 5 years out of date, and by page 2 has 
dissolved into undecypherable jargon that needs translated to working 
English. Is there an uptodate one for dummies that actually covers 
buster?

Thanks everybody.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[mick crane]

On 2019-07-04 09:42, Gene Heskett wrote:


Sorry, I don't see it that way, I see a concentrated effort to make me
use dhcpd, instead of static, every machine in the system knows the
address of ALL the other machines on my local 192.168.xx.nn/24 network.

Using dhcp means I'd have to setup a 2nd this side of my router. I will
try to make ssh work later today, and I will reanswer this message if I
can do that.


I like having ipfire or pfsense  on a separate box doing DHCP server.
you can make other PCs static by making their lease fixed.
and then everything is in one place.
well that's how I understand it anyway.

mick.

--
Key ID4BFEBB31

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 05:25:05 Felix Miata wrote:

> Gene Heskett composed on 2019-07-04 04:42 (UTC-0400):
> > every release newer than wheezy has made it progressively
> > more difficult to make a staticly defined network work.
>
> Given the myriad of successes in your 8+ decades, I'm baffled that you
> are continually flummoxed by fixed IP networking. Maybe it's because I
> only use X86 hardware, but DHCP is the only thing that has given me
> any trouble lately, and that's only because of a NIC driver that is
> apparently quite broken. Fixed IP here just continues to work as
> before. Could it be because I've been planting net.ifnames=0 on every
> cmdline since before Wheezy, along with 70-persistent-net.rules (which
> seems unnecessary any more), and a shared hosts file?

The shared hosts file has been a feature here since the second came 
online it round '00 to run an harbor freight milling machine, 

And I'm not sure in a pi's config, where to put the net.ifnames=0.

/boot/cmdline.txt maybe?  You have grub to splice all that together, but 
the pi's are u-boot, as most of the arm stuff is. But with the pi4 
coming online, with 4Gigs a dram, I'd sure like to see grub-2 ported to 
arms.  That would greatly simplicate kernel swapping.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Assorted arm-buster problems - network configuration

[Felix Miata]

Gene Heskett composed on 2019-07-04 04:42 (UTC-0400):

> every release newer than wheezy has made it progressively 
> more difficult to make a staticly defined network work.
Given the myriad of successes in your 8+ decades, I'm baffled that you are
continually flummoxed by fixed IP networking. Maybe it's because I only use X86
hardware, but DHCP is the only thing that has given me any trouble lately, and
that's only because of a NIC driver that is apparently quite broken. Fixed IP 
here
just continues to work as before. Could it be because I've been planting
net.ifnames=0 on every cmdline since before Wheezy, along with
70-persistent-net.rules (which seems unnecessary any more), and a shared hosts 
file?
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Assorted arm-buster problems - network configuration

[Gene Heskett]

On Thursday 04 July 2019 03:16:31 andreimpope...@gmail.com wrote:

> On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
> > On Wednesday 03 July 2019 16:12:31 Reco wrote:
> >
> > And Gene moved. Question unanswered yet.
> >
> > >   Hi.
> > >
> > > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
> > > > Regardless of what I do, I cannot get rid of the avahi junk in
> > > > an ip a report, so my local 192.168.xx.nn/24 net is the only
> > > > thing that works. pinging a net name like yahoo.com gets me a
> > > > successful address. But no response from yahoo because its
> > > > sending the ping from an avahi based address, which since thats
> > > > outside of my /24 netmask, doesn't get thru the router.
> > > >
> > > > So, how do I get rid of the avahi stuff?
> > > >
> > > > I've a nominally 10 machine 192.168.nn.xx that is 100% static
> > > > based on host files so I want avahi absolutely and totally
> > > > neutered, emasculated, gone Forever plus 100 years at least.
> > > >
> > > > How can I do that?
>
> It's not necessarily avahi doing that. A DHCP client might also
> configure a 169.254.*.* address for you if it doesn't receive a reply.
>
> In order to have the slightest chance of helping you it is necessary
> for you to provide the information as per below.
>
> Files should preferably be attached, to avoid issues with copy-paste.
>
> Please do not edit anything except to obscure private information
> (e.g. passwords or a public IP you don't want to post).
>
>
> 1. content of /etc/network/interfaces and all files under
> /etc/network/interfaces.d/
>
> (I seem to recall you are using ifupdown)
>
> 2. Full output of:
> apt list --installed 'network-manager*' # might be empty
> apt list --installed 'avahi*' # might be empty
> systemctl status systemd-networkd
> ip a # short for 'ip address'
> ip r # short for 'ip route'
>
> 3. Information on anything (and I do mean anything) else you might
> have done to your network configuration after installing buster,
> including but not limited to:
>  * installing stuff, especially if from source
First, on a u-booting raspi you don't "install". You either download an 
image and put it on a u-sd card with dd, or you generate your own image.

Which is what I have done by using a utility from guysoft called 
RealtimePi, which takes the June 20th version of raspian buster lite 
apart, and supposedly puts it back together with a realtime patched 
version of a compatible kernel, which should have been a 4.19.50-rt-v7 
kernel, but when put on a u-sd, and the u-sd booted, turns out to have 
the unpatched kernel in it.  Why I watched it spend an hour building the 
older 4.4.114-rt-v7 kernel and then it didn't use it is something I have 
not found yet in the build.log. Which I can't get to ATM because ssh 
isn't working either.

I can't get any of that until I can make ssh work, which it is not at the 
moment. ISTR if I restart it from its own console, it might work. 
Depends on the phase of the moon because it might decide to use the 169 
addresses for everything. these two lines at the top of /e/n/i.d/eth0

auto eth0
iface eth0 inet static

is supposed to tell n-m and company to keep their hands off that 
interface, and plainly it is not. It is totally ignoreing the rest of 
that file, so while I may get a valid address, but not one fixed 
gateway|route.  Sitting here. playing with ip on this machine, I finally 
figured out how to get rid of the 169.254.xx.yy trash in the eth0 setup, 
and its possible I might be able to put a postup command or two to clean 
house and make it work, like I did with stretch on a rock64.

>  * removing stuff (especially if not 'purged', dpkg -l would tell)
>  * manual changes to files (deletions/permissions/etc.
>  (especially those unnecessary "fixes" you call "neutering")

I will do whatever it takes to make it "Just Work". But so much has been 
changed with buster that I don't really know where to start. Jessie ran 
good, but realtime wasn't as real as needed, stretch runs a much better 
realtime, but each "upgrade" has been harder and harder to make the 
networking Just Work.

> For the record/archives: other users are not seeing your problems.

Am I the only holdout on the whole English speaking planet still useing 
static networking configs?  I really, seriously, doubt that. But I will 
state that every release newer than wheezy has made it progressively 
more difficult to make a staticly defined network work. Way too many 
chefs stirring in the same pot is how I see it.

> Buster is - at least for me - the best Debian release yet.

It may well be, but its worth

Re: Assorted arm-buster problems - network configuration

[andreimpopescu]

On Mi, 03 iul 19, 21:03:19, Gene Heskett wrote:
> On Wednesday 03 July 2019 16:12:31 Reco wrote:
> 
> And Gene moved. Question unanswered yet.
> > Hi.
> >
> > On Wed, Jul 03, 2019 at 02:57:35PM -0400, Gene Heskett wrote:
> > > Regardless of what I do, I cannot get rid of the avahi junk in an ip
> > > a report, so my local 192.168.xx.nn/24 net is the only thing that
> > > works. pinging a net name like yahoo.com gets me a successful
> > > address. But no response from yahoo because its sending the ping
> > > from an avahi based address, which since thats outside of my /24
> > > netmask, doesn't get thru the router.
> > >
> > > So, how do I get rid of the avahi stuff?
> > >
> > > I've a nominally 10 machine 192.168.nn.xx that is 100% static based
> > > on host files so I want avahi absolutely and totally neutered,
> > > emasculated, gone Forever plus 100 years at least.
> > >
> > > How can I do that?

It's not necessarily avahi doing that. A DHCP client might also 
configure a 169.254.*.* address for you if it doesn't receive a reply.

In order to have the slightest chance of helping you it is necessary for 
you to provide the information as per below.

Files should preferably be attached, to avoid issues with copy-paste. 

Please do not edit anything except to obscure private information (e.g. 
passwords or a public IP you don't want to post).


1. content of /etc/network/interfaces and all files under 
/etc/network/interfaces.d/

(I seem to recall you are using ifupdown)

2. Full output of:
apt list --installed 'network-manager*' # might be empty
apt list --installed 'avahi*' # might be empty
systemctl status systemd-networkd
ip a # short for 'ip address'
ip r # short for 'ip route'

3. Information on anything (and I do mean anything) else you might have 
done to your network configuration after installing buster, including 
but not limited to:
 * installing stuff, especially if from source
 * removing stuff (especially if not 'purged', dpkg -l would tell)
 * manual changes to files (deletions/permissions/etc.
 (especially those unnecessary "fixes" you call "neutering")

For the record/archives: other users are not seeing your problems.

Buster is - at least for me - the best Debian release yet.

The problems you are seeing are, at least partially, of your own doing, 
most likely due to wrong configuration and an approach of using the 
equivalent of a shotgun to kill a fly and then complaining your walls 
are full of holes.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: debian 9 network configuration

[john doe]

On 8/14/2018 10:39 AM, Remigio wrote:

Il giorno martedì 14 agosto 2018 10:20:04 UTC+2, john doe ha scritto:

On 8/14/2018 9:05 AM, Remigio wrote:

Hi there,
recently I installed Debian 9 Stretch and I noticed that the network 
configuration management method was substantially changed.
Infact the file /etc/network/interfaces is almost empty despite I've inserted 
the network parameters during the installation process and network works now.
I tried searching on the web about this topic but I found lots of different 
answers.
Could you help me please to understand where are network configuration files 
and how to manage them?
Thank you so much
Regards



If your '/etc/network/interfaces' is empty with the exception of the lo
interface, it is most likely that your interfaces are configured by an
other software (NetworkManager, (NM), WICD, systemd-networkd ...).

What is the content of '/etc/resolv.conf'?:

$ cat /etc/resolv.conf

--
John Doe


Hi John, :-)

root@debian:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback



Looks good when using NM.



and

root@debian:~# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 10.30.10.140



In addition to the other answers you could also configure NetworkManager:

https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html

Uninstalling a program is never an option you need to understand how 
that program works! :)
In the case of NM it's easier to use the front end but it is always nice 
to go command line or using config files  when needed.


--
John Doe

Re: debian 9 network configuration

[Remigio]

Il giorno martedì 14 agosto 2018 14:50:04 UTC+2, Greg Wooledge ha scritto:
> On Tue, Aug 14, 2018 at 12:05:34AM -0700, Remigio wrote:
...

Many thanks Greg for your clear exposition, I think that's what I was looking 
for.
Regards

Re: debian 9 network configuration

[Joe]

On Tue, 14 Aug 2018 12:31:22 +0100
Darac Marjal  wrote:

> On Tue, Aug 14, 2018 at 01:35:56AM -0700, Remigio wrote:
> > desktop or what other software did you install - XFCE, or Gnome  
> >> or KDE?  Then folks might be able to help ...
> >>
> >> Also, how would you -like- to configure your networking?  
> >
> >Hi Zenaan, :-)
> >the desktop environment is Xfce and I'd love to configure the
> >networking via shell. Thanks and regards
> >  
> 
> You can configure NetworkManager from a shell by using the nmcli
> command (upstream documentation at
> https://developer.gnome.org/NetworkManager/stable/nmcli.html)
> 
> For example:
>  nmcli radio wifi on
>  nmcli wifi list --rescan
>  nmcli dev wlp4s0 con "My Home Hotspot" password S3cure name "Home"
>  nmcli con up id "My Home Hotspot"
> 
> 

I think the context here is not so much the physical act of typing or
moving a mouse, it's having network software which is understood, and
which won't mess about with your settings when you're not looking.

I use NM on my netbook, and laptop when booted to Linux, and I find it
useful in dealing with assorted wifi and VPN situations. These days, it
Just Works, at least for me. But I would never allow it onto a server
or even a fixed workstation, nothing must ever change then, and a means
of configuration using a fixed text file cannot be beaten.

-- 
Joe

Re: debian 9 network configuration

[Greg Wooledge]

On Tue, Aug 14, 2018 at 12:05:34AM -0700, Remigio wrote:
> recently I installed Debian 9 Stretch
[...]
> Could you help me please to understand where are network configuration files 
> and how to manage them?

If, during the installation, you choose to install a Desktop Environment,
then Network Manager gets installed, and the configuration that would
normally go into /etc/network/interfaces (/e/n/i for short) is wiped out.

With your ethernet and/or wifi interfaces not listed in /e/n/i, NM takes
over and manages those interfaces.  For better or worse.

If, on the other hand, during the installation, you choose NOT to install
a Desktop Environment, then the installer writes the network configuration
stuff into /e/n/i for you, and NM is not installed.

On Tue, Aug 14, 2018 at 10:05:47AM +0100, Brian wrote:
> apt purge network-manager
> apt --purge autoremove
> 
> Then configure /e/n/i to your liking.

I second this recommendation for a desktop machine or a server.  I don't
know about laptops.

Re: debian 9 network configuration

[Darac Marjal]

On Tue, Aug 14, 2018 at 01:35:56AM -0700, Remigio wrote:

desktop or what other software did you install - XFCE, or Gnome

or KDE?  Then folks might be able to help ...

Also, how would you -like- to configure your networking?


Hi Zenaan, :-)
the desktop environment is Xfce and I'd love to configure the networking via 
shell.
Thanks and regards



You can configure NetworkManager from a shell by using the nmcli command 
(upstream documentation at https://developer.gnome.org/NetworkManager/stable/nmcli.html)


For example:
nmcli radio wifi on
nmcli wifi list --rescan
nmcli dev wlp4s0 con "My Home Hotspot" password S3cure name "Home"
nmcli con up id "My Home Hotspot"


--
For more information, please reread.


signature.asc
Description: PGP signature

Re: debian 9 network configuration

[Remigio]

...
> What desktop or what other software did you install - XFCE, or Gnome
> or KDE?  Then folks might be able to help ...
> 
> Also, how would you -like- to configure your networking?

Hi Zenaan, :-)
the desktop environment is Xfce and I'd love to manage networking via shell.
Thanks and regards

Re: debian 9 network configuration

[Brian]

On Tue 14 Aug 2018 at 01:14:45 -0700, Remigio wrote:

> ..-
> > What desktop or what other software did you install - XFCE, or Gnome
> > or KDE?  Then folks might be able to help ...
> > 
> > Also, how would you -like- to configure your networking?
> 
> Hi Zenaan, :-)
> the desktop is Xfce and I'de love to configure the networking via shell.
> Thanks and regards

apt purge network-manager
apt --purge autoremove

Then configure /e/n/i to your liking.

-- 
Brian.