Re: avahi-daemon allow/deny interfaces question

[Ram Ramesh]

On 7/14/22 09:15, Ram Ramesh wrote:

Hi Ramesh,

There are numerous reports (mostly old, afaics) of the issue you 
describe, but with various suggested reasons.


I suspect the avahi related part is a consequence rather than a cause 
- I didn't think avahi was capable of disabling interfaces, the 
message looks like it's updating a table/list (etc) and "...no longer 
relevant..." messages appear in my syslog if I deliberately 
disconnect from wifi.


Please can you provide syslog extracts from just before and during a 
time when this has happened, using:


$ sudo cat /var/log/syslog | grep -i -E "avahi|network"
(must be capital -E and no spaces around the | inside the speech marks)

Is there anything that seems relevant in

$ sudo dmesg -T

?

Out of interest, did you try running for a while with just the power 
management tweak?


Thanks,
Gareth
Yes, I believe I did. I did not use /sys/... power/control method. 
Instead, I kept the network alive by "ping -i 60 ". 
However, I am not 100% sure of this. So, I will revert some of my 
changes and get you the relevant logs.


Thanks for your continued interested in this matter.

Regards
Ramesh

Mmm... It has been about 10 hours since my reboot after removing 
"deny-interfaces=$extif," and I have not had the earlier issue of 
interface disappearing. I will let it run overnight to see. However, I 
think I wont be able to reproduce the problem.


Earlier, I was trying to keep the interface alive with "ping -i 60 xxx"  
instead of setting "/sys/usb/ power/control" to "on". Not sure if 
that was not enough and $extif actually powered off in between pings and 
avahi-daemon was simply reporting this in daemon.log. However, kernel 
reset the interface status and (may be) dhclient was not written to 
handle this sort of issue. So, it simply could not work with the 
interface anymore as it was not initialized to perform DHCP. I wonder 
why this did not affect ping as it was chugging along without any 
issues. That is too many wild guesses and I am not sure why the problem 
does not exists now.


I will update again later tomorrow when it has run another 12+ hours.

Regards
Ramesh

Re: SSH resources, specifically on certificates (certificate authentication)

[tomas]

On Thu, Jul 14, 2022 at 08:01:19PM -0400, rhkra...@gmail.com wrote:

[...]

> I'll probably start with a post to describe one of the most surprising things 
> I learned about ssh so far -- to jump ahead and spoil it, it turns out that 
> public key encryption is not used for the exchange of the real "user" / 
> payload data, but instead a symmetric (one of a variety, iiuc) encryption 
> algorithm, with the same encryption key used by both the client and server, 
> but developed by each independently and never exchanged "over the wire".

This is standard for public key cryptography, be it "interactive style"
(e.g. SSH, TLS, where both parties exchange message) or "deferred style"
(e.g. PGP/GPG, where one party prepares an encrypted message ahead of time
for the other to decrypt).

See, asymmetrical encryption (e.g. RSA, Elliptic Curve) is far too expensive
to use on bulk data, so it typically is used to encrypt a key (generated on
the spot), called "session key". The latter is used to symmetrically (e.g.
AES) encrypt the bulk data. You use that style typically in the deferred
case.

Perhaps there's even a security advantage in that, since the session key,
as being used for more data gives a potential cryptanalist more material
to chew on: then just the session key would be compromised, and you throw
that away for the next round. I don't know.

> This is done by a process named Diffie_Hellman key exchange, and the 
> Wikipedia 
> article on that (URL below) explains it quite well, with one example done in 
> terms of colors of paint (i.e., that people without an extensive background 
> in 
> math or cryptography can understand).

Diffie Hellman is only used in the "interactive" case above, to establish
a secure path without having exchanged /any/ keys before; after that, you
have to do a key exchange to make sure you are talking to whom you think
you are (that's the "authenticity" part of the scheme [1]). You can't use
Diffie-Hellman for mails or encrypted files/disks, since the other party
has gone to sleep when you find the "message" :-)

With D-H you can have confidentiality with some random second party. Just
think of that. It makes me dizzy after all that years ;-)

But in both cases (interactive, deferred), you agree on a session key for
symmetric encryption to carry the brunt. It's so much faster than everything
else that it's not even funny, and it is cryptographically much better
understood.

Cheers

[1] Remember that the whole thing has three goals
   confidentiality - no one else can read in on the message
   authenticity - you are talking to whom you think you are
   integriry - nothing has tampered with the message on its way

-- 
tomás


signature.asc
Description: PGP signature

Re: SSH resources, specifically on certificates (certificate authentication)

[David Wright]

On Thu 14 Jul 2022 at 10:00:29 (-0400), Frank Pikelner wrote:

> SSH certificate authentication is not complicated and has many
> advantages. Some organizations use SSH certificates to provide limited
> access for admins to servers. In my opinion using SSH certificates is
> preferred to just using ssh keys. There are a number of guides on how
> to implement ssh certificates - if you are unable to locate, ping me
> directly and I may have a document I wrote for myself a while back.

Please consider yourself pinged. (3 Jun 2021)

Cheers,
David.

Re: SSH resources, specifically on certificates (certificate authentication)

[rhkramer]

Intentionally top posting.

Thanks for the reply!

I'm thinking of two or three paths forward -- one is to give up on this, but 
I've invested a lot of calandar days (and non-"spare" manhours so far, so I 
don't want to do that.

Another is to make another pass through some of what I consider the best 
documentation I've found so far and see if I can puzzle out the answers and 
such that I'm looking for.

The third is to ask questions on this list, and I think that is at least part 
of what I'll try.  Some of my questions (and even the entire subject) will 
probably involve some fairly wordy introduction to the questions.

Sorry about that.

I'll probably start with a post to describe one of the most surprising things 
I learned about ssh so far -- to jump ahead and spoil it, it turns out that 
public key encryption is not used for the exchange of the real "user" / 
payload data, but instead a symmetric (one of a variety, iiuc) encryption 
algorithm, with the same encryption key used by both the client and server, 
but developed by each independently and never exchanged "over the wire".

This is done by a process named Diffie_Hellman key exchange, and the Wikipedia 
article on that (URL below) explains it quite well, with one example done in 
terms of colors of paint (i.e., that people without an extensive background in 
math or cryptography can understand).

[[https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange][Diffie–
Hellman key exchange - Wikipedia]]

I guess this serves as that first post I mentioned.  No questions so far.

Nothing new below this line.

On Thursday, July 14, 2022 11:35:50 AM to...@tuxteam.de wrote:
> As someone else said, I agree that the certificate way is quite a bit more
> complex than just distributing public keys. It'll play out its advantages
> if you have many servers /and/ many users -- the disadvantages are clear:
> you have to manage your CA (where the root of trust resides), /and/ your
> servers need regular access to the CRLs (certificate revocation lists) for
> the case anything gets compromised (of course, you could do whithout, but
> then, why use certs at all?).
> 
> An alternative for a more central and orderly key distribution is to put
> pubkeys in some form of directory service (say, LDAP). In our $COMPANY
> (sub-100s of servers, sub-50 of IDs) we chose that path. Newer ssh servers
> can delegate the authorized_keys to a script (i.e. the server doesn't
> look things up in a file but runs a small program/shell script which is
> supposed to output something looking like the authorized_keys file).
> 
> OTOH, if all you want is to learn how this cert stuff works, that's
> *always* a strong reason to try!
> 
> Cheers

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid top 
posting; and keep it "on list".  (Oxford comma included at no charge.)  If you 
change topics, change the Subject: line. 

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

Re: SSH resources, specifically on certificates (certificate authentication)

[David Christensen]

On 7/14/22 09:59, rhkra...@gmail.com wrote:

On Wednesday, July 13, 2022 07:58:14 PM David Christensen wrote:

Buy and read "TLS Mastery" by Lucas:

https://mwl.io/nonfiction/networking#tls


Replying off list intentionally:  AFAIK, TLS doesn't have much, if anything, to
do with ssh certificates.  It may be (probably is) relevant to ssl certificates.



Modern encryption is a large and complex subject that is constantly 
evolving.  I seem to recall that you stated that you were having a hard 
time finding current and coherent information.  I buy Lucas books 
because he provides both.  I think you would find the book useful.




Maybe I should reply on list "for the record".



I am replying to the list.



Thanks for your reply, and have a good day!



Same to you.  :-)


David

Re: cups broken FIXED!!!!

[gene heskett]

On 7/14/22 13:08, Brian wrote:

On Thu 14 Jul 2022 at 11:56:10 -0400, gene heskett wrote:


On 7/14/22 05:19, Brian wrote:


[...]


But now the "add printer" just re-configures the existing one. "Add"
does not make a new profile. I need both profiles to show up in both
firefox's, print dialog, and in the system dialog if you scroll all the
way down in the FF dialog  and select that instead.

How can is this done with this new cups?

Just specify a new destination name: XXX instead of AAA. Keep the same
URI (the connection).

To cups that destination=queuename, so I added _photo to the first 
columns name.

like this:

Brother_MFC-J6920DW_photo 



You're da man, it works! I loaded tray 1 with 40 or so sheets of good glossy
photo paper, face down in the tray cuz it turns it glossy side up to print.
Beautiful test page. Took it about 2 minutes wall time. But I had to cheat
and tell it it was brother paper. More like wallmart's better stuff.

Thank you very much Brian.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page

Re: cups broken

[Brian]

On Thu 14 Jul 2022 at 11:56:10 -0400, gene heskett wrote:

> On 7/14/22 05:19, Brian wrote:
> > On Wed 13 Jul 2022 at 21:31:24 -0400, gene heskett wrote:
> > 
> > > On 7/13/22 19:27, Brian wrote:
> > > > On Wed 13 Jul 2022 at 16:10:56 -0400, gene heskett wrote:
> > > > 
> > > > > On 7/13/22 15:14, Brian wrote:
> > > > > > On Wed 13 Jul 2022 at 13:21:07 -0400, gene heskett wrote:
> > > > > > 
> > > > > > [Broken lines mended to give a readable original post.]
> > > > > > 
> > > > > Blame that in tbird.
> > > > Yet another part of the compting experience tou are unable to
> > > > control?
> > > > > > > I give up, the driverless printer cups installs automaticaly 
> > > > > > > cannot be
> > > > > > > deleted and has taken over from the brother drivers that work,
> > > > > > > preventing me from using the printer at all.
> > > > > > > 
> > > > > > > So how do I disable the driverless junk? Is that a separate 
> > > > > > > package
> > > > > > > that is removable?  cups doesn't even offer to disable this
> > > > > > > non-working garbage.  Thanks for any good clues.
> > > > > > Driverless printing is only possible when avahi-daemon is on the
> > > > > > system. Your solution is obvious.
> > > > > > 
> > > > > avahi-daemon 0.8-5 is installed.
> > > > Is this the avahi-daemon that, in the past, you have characterised as
> > > > unfit to be used on a local network and that didn't deserve any of
> > > > your disk space.
> > > True, but that is all, none of its kin is.  And I did find out how to 
> > > defeat
> > > it. But
> > > when I went to look, that file has vanished and its still working.
> > > 
> > > So what happened that got /etc/dhcpcd.conf removed?
> > > It had a fallback stanza near the bottom that I had edited in
> > > the default eth0 config.  That finally got rid of the totally bogus
> > > 169.xx.yy.zz
> > > routing address. Now the file is gone,  and its still working.
> > Good.
> > 
> > > > >   See the ppd driverless attached to 
> > > > > my
> > > > > previous msg it just now made.
> > > > > It looks busted to me.
> > > > Broken files are best not used. Remove and follow my previos advice.
> > > > 
> > > I have. and cups brings it back automatically on the restart that does.
> > > Probably
> > > 20 times I've deleted it. Its back before I can look to see if its gone.
> > That is cups-browsed doing auto-setup. As far as you are concerned
> > that is its sole job. It doesn't do anything else for you or the
> > printing system. Therefore:
> > 
> >apt purge cups-browsed
> Will that then allow brothers drivers to work normally?

The Brother drivers should work normally with or without purging
cups-browsed.

> This printer is normally shared to the rest of my network. So
> I can fire up geany on any of the other 5 machines here,
> make an adjustment to one of the LinuxCNC configuration files,
> and print it right from that machine which might be a minutes
> walk away in another building.
> 
> Done, all versions of this printer are deleted and stay gone.

As predicted!

> Ok, it works, sort of. I did have it setup as two printers before
> this last cups update a week or so back, one for  color photos,
> from thick glossy paper from tray 1 (top tray).
> And another copy setup to do fast utility duplexed printing
> from tray 2, the bottom tray, which can hold 300 sheets of 22 lb.

Any CUPS update on bullseye would be for a secuity issue only. There
shouldn't be any change in its basic operation.

> But now the "add printer" just re-configures the existing one. "Add"
> does not make a new profile. I need both profiles to show up in both
> firefox's, print dialog, and in the system dialog if you scroll all the
> way down in the FF dialog  and select that instead.
> 
> How can is this done with this new cups?

Just specify a new destination name: XXX instead of AAA. Keep the same
URI (the connection).

-- 
Brian.

Re: SSH resources, specifically on certificates (certificate authentication)

[rhkramer]

On Wednesday, July 13, 2022 07:09:33 PM Jeremy Ardley wrote:
> I understand that certificate based SSH authentication has problems with
> overall security management on a network. Password only has similar
> problems.

I'm not sure it has any more problems than ssh public key authentication, 
maybe even less, but that is part of what I'm trying to learn / determine.

> The correct solution seems to be a centrally managed authentication
> server but I haven't found any simple guide to implementing that in the
> Debian environment. Is there any useful tutorial available?

tomas makes one suggestion in a later post to this thread.

Another way that I think is along the lines you're talking about is referred 
to as gssapi (iirc) (at least in some of the man pages), of which Kerberos is 
one variety (iiuc) -- there are apparently other varieties.

I don't plan on digging into that. ;-)

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid top 
posting; and keep it "on list".  (Oxford comma included at no charge.)  If you 
change topics, change the Subject: line. 

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

Re: cups broken

[gene heskett]

On 7/14/22 05:19, Brian wrote:

On Wed 13 Jul 2022 at 21:31:24 -0400, gene heskett wrote:


On 7/13/22 19:27, Brian wrote:

On Wed 13 Jul 2022 at 16:10:56 -0400, gene heskett wrote:


On 7/13/22 15:14, Brian wrote:

On Wed 13 Jul 2022 at 13:21:07 -0400, gene heskett wrote:

[Broken lines mended to give a readable original post.]


Blame that in tbird.

Yet another part of the compting experience tou are unable to
control?

I give up, the driverless printer cups installs automaticaly cannot be
deleted and has taken over from the brother drivers that work,
preventing me from using the printer at all.

So how do I disable the driverless junk? Is that a separate package
that is removable?  cups doesn't even offer to disable this
non-working garbage.  Thanks for any good clues.

Driverless printing is only possible when avahi-daemon is on the
system. Your solution is obvious.


avahi-daemon 0.8-5 is installed.

Is this the avahi-daemon that, in the past, you have characterised as
unfit to be used on a local network and that didn't deserve any of
your disk space.

True, but that is all, none of its kin is.  And I did find out how to defeat
it. But
when I went to look, that file has vanished and its still working.

So what happened that got /etc/dhcpcd.conf removed?
It had a fallback stanza near the bottom that I had edited in
the default eth0 config.  That finally got rid of the totally bogus
169.xx.yy.zz
routing address. Now the file is gone,  and its still working.

Good.


  See the ppd driverless attached to my
previous msg it just now made.
It looks busted to me.

Broken files are best not used. Remove and follow my previos advice.


I have. and cups brings it back automatically on the restart that does.
Probably
20 times I've deleted it. Its back before I can look to see if its gone.

That is cups-browsed doing auto-setup. As far as you are concerned
that is its sole job. It doesn't do anything else for you or the
printing system. Therefore:

   apt purge cups-browsed

Will that then allow brothers drivers to work normally?
This printer is normally shared to the rest of my network. So
I can fire up geany on any of the other 5 machines here,
make an adjustment to one of the LinuxCNC configuration files,
and print it right from that machine which might be a minutes
walk away in another building.

Done, all versions of this printer are deleted and stay gone.

Ok, it works, sort of. I did have it setup as two printers before
this last cups update a week or so back, one for  color photos,
from thick glossy paper from tray 1 (top tray).
And another copy setup to do fast utility duplexed printing
from tray 2, the bottom tray, which can hold 300 sheets of 22 lb.

But now the "add printer" just re-configures the existing one. "Add"
does not make a new profile. I need both profiles to show up in both
firefox's, print dialog, and in the system dialog if you scroll all the
way down in the FF dialog  and select that instead.

How can is this done with this new cups?

Thanks Brian, take care & stay well.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: SSH resources, specifically on certificates (certificate authentication)

[tomas]

On Thu, Jul 14, 2022 at 08:55:34AM -0400, rhkra...@gmail.com wrote:
> 
> 
> dsr, Thanks for the reply!
> 
> Like I said, I think I went down a rabbit hole, and I wish I had realized 
> that 
> before I went there.

As someone else said, I agree that the certificate way is quite a bit more
complex than just distributing public keys. It'll play out its advantages
if you have many servers /and/ many users -- the disadvantages are clear:
you have to manage your CA (where the root of trust resides), /and/ your
servers need regular access to the CRLs (certificate revocation lists) for
the case anything gets compromised (of course, you could do whithout, but
then, why use certs at all?).

An alternative for a more central and orderly key distribution is to put
pubkeys in some form of directory service (say, LDAP). In our $COMPANY
(sub-100s of servers, sub-50 of IDs) we chose that path. Newer ssh servers
can delegate the authorized_keys to a script (i.e. the server doesn't
look things up in a file but runs a small program/shell script which is
supposed to output something looking like the authorized_keys file).

OTOH, if all you want is to learn how this cert stuff works, that's
*always* a strong reason to try!

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: avahi-daemon allow/deny interfaces question

[Ram Ramesh]

Hi Ramesh,

There are numerous reports (mostly old, afaics) of the issue you describe, but 
with various suggested reasons.

I suspect the avahi related part is a consequence rather than a cause - I didn't think 
avahi was capable of disabling interfaces, the message looks like it's updating a 
table/list (etc) and "...no longer relevant..." messages appear in my syslog if 
I deliberately disconnect from wifi.

Please can you provide syslog extracts from just before and during a time when 
this has happened, using:

$ sudo cat /var/log/syslog | grep -i -E "avahi|network"
(must be capital -E and no spaces around the | inside the speech marks)

Is there anything that seems relevant in

$ sudo dmesg -T

?

Out of interest, did you try running for a while with just the power management 
tweak?

Thanks,
Gareth
Yes, I believe I did. I did not use /sys/... power/control method. 
Instead, I kept the network alive by "ping -i 60 ". 
However, I am not 100% sure of this. So, I will revert some of my 
changes and get you the relevant logs.


Thanks for your continued interested in this matter.

Regards
Ramesh

Re: SSH resources, specifically on certificates (certificate authentication)

[Frank Pikelner]

On Thu, Jul 14, 2022 at 8:56 AM  wrote:
>
> 
>
> dsr, Thanks for the reply!
>
> Like I said, I think I went down a rabbit hole, and I wish I had realized that
> before I went there.
>
> I've invested quite a few calendar days (and "spare" manhours) in trying to
> figure this out, so I'm not quite ready to give up.
>
> I do have some ideas (an idea) for another pass through some of the
> documentation that might clarify what I need / want to know, but, especially
> if that doesn't work, I may write a WikiLearn page or two that mainly just
> warns about the rabbit hole.
>
> I'm almost certain I will be back with some specific questions that maybe you
> or someone else on the list can answer.
>
> Thanks again!
>
> On Thursday, July 14, 2022 02:11:30 AM Dan Ritter wrote:
> > Dan Purgert wrote:
> ...
> > > > > On Jul 13, 2022, rhkra...@gmail.com wrote:
> > > > > > I seem to have gone down a rabbit hole.
>
> > Right, the problem is in everything to support that: running a
> > certificate authority in a secure manner is extremely
> > non-trivial. Running it in a secure and reliable manner is even
> > more non-trivial.
> >
> > In general, I don't recommend it. Consider this:
> >
> > - an SSH certificate has a date on which it will expire. When
> > that day comes, it will stop functioning. If you don't have
> > infrastructure to remind you to re-issue this in advance, you
> > may be locked out of whatever you are trying to access.
> >
> > - conversely, if you want to revoke an SSH certificate before
> > the expiration date, you need to maintain and distribute a
> > revocation list of all the certs that you no longer approve of.
> > Miss a machine and the old cert is still valid up to the
> > expiration date.
> >
> > For most people in most cases, those are not the behaviors that
> > they want.
> >
> > > I've never seen this implemented in any place I've worked in
> > > the last 2 decades (granted, I "only" have said 2 decades of
> > > "professional" experience); rather they've always used either (a) keys,
> > > or (b) password + RSA Token (or other 2FA / TOTP mechanism)
> >
> > And the reason is that those fit what people want more closely
> > than the cert mechanism.
> >
> > If you've got a very large organization, you may want to support
> > the infrastructure to generate new SSH certs for people daily,
> > with expiration dates of 24 hours. Then you need to make sure
> > that mechanism is working perfectly and has appropriate
> > redundancy, so that you don't accidentally lock out the whole
> > organization tomorrow.
> >
> > -dsr-
>
> --


SSH certificate authentication is not complicated and has many
advantages. Some organizations use SSH certificates to provide limited
access for admins to servers. In my opinion using SSH certificates is
preferred to just using ssh keys. There are a number of guides on how
to implement ssh certificates - if you are unable to locate, ping me
directly and I may have a document I wrote for myself a while back.

Best,

Frank

Re: SSH resources, specifically on certificates (certificate authentication)

[rhkramer]

dsr, Thanks for the reply!

Like I said, I think I went down a rabbit hole, and I wish I had realized that 
before I went there.

I've invested quite a few calendar days (and "spare" manhours) in trying to 
figure this out, so I'm not quite ready to give up.

I do have some ideas (an idea) for another pass through some of the 
documentation that might clarify what I need / want to know, but, especially 
if that doesn't work, I may write a WikiLearn page or two that mainly just 
warns about the rabbit hole.

I'm almost certain I will be back with some specific questions that maybe you 
or someone else on the list can answer.

Thanks again!

On Thursday, July 14, 2022 02:11:30 AM Dan Ritter wrote:
> Dan Purgert wrote:
...
> > > > On Jul 13, 2022, rhkra...@gmail.com wrote:
> > > > > I seem to have gone down a rabbit hole.

> Right, the problem is in everything to support that: running a
> certificate authority in a secure manner is extremely
> non-trivial. Running it in a secure and reliable manner is even
> more non-trivial.
> 
> In general, I don't recommend it. Consider this:
> 
> - an SSH certificate has a date on which it will expire. When
> that day comes, it will stop functioning. If you don't have
> infrastructure to remind you to re-issue this in advance, you
> may be locked out of whatever you are trying to access.
> 
> - conversely, if you want to revoke an SSH certificate before
> the expiration date, you need to maintain and distribute a
> revocation list of all the certs that you no longer approve of.
> Miss a machine and the old cert is still valid up to the
> expiration date.
> 
> For most people in most cases, those are not the behaviors that
> they want.
> 
> > I've never seen this implemented in any place I've worked in
> > the last 2 decades (granted, I "only" have said 2 decades of
> > "professional" experience); rather they've always used either (a) keys,
> > or (b) password + RSA Token (or other 2FA / TOTP mechanism)
> 
> And the reason is that those fit what people want more closely
> than the cert mechanism.
> 
> If you've got a very large organization, you may want to support
> the infrastructure to generate new SSH certs for people daily,
> with expiration dates of 24 hours. Then you need to make sure
> that mechanism is working perfectly and has appropriate
> redundancy, so that you don't accidentally lock out the whole
> organization tomorrow.
> 
> -dsr-

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid top 
posting; and keep it "on list".  (Oxford comma included at no charge.)  If you 
change topics, change the Subject: line. 

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

Re: cups broken

[Brian]

On Wed 13 Jul 2022 at 21:31:24 -0400, gene heskett wrote:

> On 7/13/22 19:27, Brian wrote:
> > On Wed 13 Jul 2022 at 16:10:56 -0400, gene heskett wrote:
> > 
> > > On 7/13/22 15:14, Brian wrote:
> > > > On Wed 13 Jul 2022 at 13:21:07 -0400, gene heskett wrote:
> > > > 
> > > > [Broken lines mended to give a readable original post.]
> > > > 
> > > Blame that in tbird.
> > Yet another part of the compting experience tou are unable to
> > control?
> > > > > I give up, the driverless printer cups installs automaticaly cannot be
> > > > > deleted and has taken over from the brother drivers that work,
> > > > > preventing me from using the printer at all.
> > > > > 
> > > > > So how do I disable the driverless junk? Is that a separate package
> > > > > that is removable?  cups doesn't even offer to disable this
> > > > > non-working garbage.  Thanks for any good clues.
> > > > Driverless printing is only possible when avahi-daemon is on the
> > > > system. Your solution is obvious.
> > > > 
> > > avahi-daemon 0.8-5 is installed.
> > Is this the avahi-daemon that, in the past, you have characterised as
> > unfit to be used on a local network and that didn't deserve any of
> > your disk space.
> True, but that is all, none of its kin is.  And I did find out how to defeat
> it. But
> when I went to look, that file has vanished and its still working.
> 
> So what happened that got /etc/dhcpcd.conf removed?
> It had a fallback stanza near the bottom that I had edited in
> the default eth0 config.  That finally got rid of the totally bogus
> 169.xx.yy.zz
> routing address. Now the file is gone,  and its still working.

Good.

> > >  See the ppd driverless attached to my
> > > previous msg it just now made.
> > > It looks busted to me.
> > Broken files are best not used. Remove and follow my previos advice.
> > 
> I have. and cups brings it back automatically on the restart that does.
> Probably
> 20 times I've deleted it. Its back before I can look to see if its gone.

That is cups-browsed doing auto-setup. As far as you are concerned
that is its sole job. It doesn't do anything else for you or the
printing system. Therefore:

  apt purge cups-browsed

-- 
Brian.