Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #212757 > unrolled thread

dbus-deamon avoiding reboot after upgrade

Back to article view | Back to linux.debian.user

Contents

  dbus-deamon avoiding reboot after upgrade john doe <johndoe65534@mail.com> - 2019-08-13 20:10 +0200
    Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-13 21:30 +0200
      Re: dbus-deamon avoiding reboot after upgrade john doe <johndoe65534@mail.com> - 2019-08-14 07:50 +0200
        Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-14 08:50 +0200
          Re: dbus-deamon avoiding reboot after upgrade Sven Hartge <sven@svenhartge.de> - 2019-08-14 09:00 +0200
            Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-14 09:30 +0200
              Re: dbus-deamon avoiding reboot after upgrade Curt <curty@free.fr> - 2019-08-14 10:30 +0200
        Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-15 19:00 +0200
          Re: dbus-deamon avoiding reboot after upgrade <tomas@tuxteam.de> - 2019-08-15 19:20 +0200
            Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-15 20:50 +0200
              Re: dbus-deamon avoiding reboot after upgrade <tomas@tuxteam.de> - 2019-08-15 21:10 +0200
                Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-15 21:50 +0200
                  Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-16 09:00 +0200
                    Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-16 12:20 +0200
                    Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-16 20:20 +0200
                      Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-16 21:40 +0200
                        Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-17 00:30 +0200
                          Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-17 12:00 +0200
                            Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-17 13:20 +0200
              Re: dbus-deamon avoiding reboot after upgrade Tixy <tixy@yxit.co.uk> - 2019-08-15 23:20 +0200
                Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-15 23:40 +0200
                  Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-16 09:00 +0200
                    Re: dbus-deamon avoiding reboot after upgrade Greg Wooledge <wooledg@eeg.ccf.org> - 2019-08-16 14:50 +0200
                      Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-16 16:30 +0200
            Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-15 21:00 +0200
          Re: dbus-deamon avoiding reboot after upgrade john doe <johndoe65534@mail.com> - 2019-08-16 11:10 +0200
            Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-16 12:10 +0200
              Re: dbus-deamon avoiding reboot after upgrade <tomas@tuxteam.de> - 2019-08-16 12:30 +0200
                Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-16 12:50 +0200
                  Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-16 13:00 +0200
                    Re: dbus-deamon avoiding reboot after upgrade <tomas@tuxteam.de> - 2019-08-16 13:10 +0200
                      Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-16 13:20 +0200
                        Re: dbus-deamon avoiding reboot after upgrade <tomas@tuxteam.de> - 2019-08-16 13:30 +0200
                          Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-16 13:50 +0200
                            Re: dbus-deamon avoiding reboot after upgrade <tomas@tuxteam.de> - 2019-08-16 14:00 +0200
                  Re: dbus-deamon avoiding reboot after upgrade <tomas@tuxteam.de> - 2019-08-16 13:00 +0200
            Re: dbus-deamon avoiding reboot after upgrade <tomas@tuxteam.de> - 2019-08-16 12:30 +0200
    Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-17 20:20 +0200
      Re: dbus-deamon avoiding reboot after upgrade john doe <johndoe65534@mail.com> - 2019-08-18 12:30 +0200
        Re: dbus-deamon avoiding reboot after upgrade Brian <ad44@cityscape.co.uk> - 2019-08-18 15:20 +0200
          Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-18 17:00 +0200
            Re: dbus-deamon avoiding reboot after upgrade john doe <johndoe65534@mail.com> - 2019-08-19 09:30 +0200
              Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-19 09:40 +0200
                Re: dbus-deamon avoiding reboot after upgrade john doe <johndoe65534@mail.com> - 2019-08-19 10:00 +0200
                  Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-19 10:50 +0200
                  Re: dbus-deamon avoiding reboot after upgrade Andrei POPESCU <andreimpopescu@gmail.com> - 2019-08-19 21:10 +0200
                    Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-19 21:20 +0200
                Re: dbus-deamon avoiding reboot after upgrade Bastien Durel <bastien@durel.org> - 2019-08-19 10:50 +0200
                  Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-19 11:00 +0200
                    Re: dbus-deamon avoiding reboot after upgrade Bastien Durel <bastien@durel.org> - 2019-08-19 12:00 +0200
                      Re: dbus-deamon avoiding reboot after upgrade Reco <recoverym4n@enotuniq.net> - 2019-08-19 12:10 +0200
                      Re: dbus-deamon avoiding reboot after upgrade Greg Wooledge <wooledg@eeg.ccf.org> - 2019-08-19 16:20 +0200
                        Re: dbus-deamon avoiding reboot after upgrade Bastien Durel <bastien@durel.org> - 2019-08-19 18:20 +0200
          Re: dbus-deamon avoiding reboot after upgrade john doe <johndoe65534@mail.com> - 2019-08-18 17:00 +0200

Page 1 of 3  [1] 2 3  Next page →

#212757 — dbus-deamon avoiding reboot after upgrade

Hi,

While upgrading the dbus deamon, I get the following:

"A reboot is required to replace the running dbus-daemon.
Please reboot the system when convenient."


I have no plan to reboot that server, what are the pros and cons of not
doing that or how can I avoid rebooting altogether?

--
John Doe

[toc] | [next] | [standalone]

#212760

On Tue, Aug 13, 2019 at 08:07:49PM +0200, john doe wrote:
> I have no plan to reboot that server, what are the pros and cons of not
> doing that

Pro: keeping uptime
Con: keeping previous, possibly buggy, version for dbus running.

> or how can I avoid rebooting altogether?

dbus is not mandatory and is redundant for typical server software.
If you don't need it - just uninstall it. Simple as that.

Reco

[toc] | [prev] | [next] | [standalone]

#212772

Hi Rico, and thanks for your answer.

On 8/13/2019 9:25 PM, Reco wrote:
> On Tue, Aug 13, 2019 at 08:07:49PM +0200, john doe wrote:
>> I have no plan to reboot that server, what are the pros and cons of not
>> doing that
>
> Pro: keeping uptime
> Con: keeping previous, possibly buggy, version for dbus running.
>
>> or how can I avoid rebooting altogether?
>
> dbus is not mandatory and is redundant for typical server software.
> If you don't need it - just uninstall it. Simple as that.
>

okay, dbus is only required when a DE (Gnome,Mate, ...) is present.
If I'm correct, and given the fact that I don't use a DE, I could look
at safely remove it?

In other words, why is dbus a dependency when no DE is installed or what
are the corner cases when dbus is needed without a DE.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#212776

	Hi.

On Wed, Aug 14, 2019 at 07:36:21AM +0200, john doe wrote:
> > dbus is not mandatory and is redundant for typical server software.
> > If you don't need it - just uninstall it. Simple as that.
> 
> okay, dbus is only required when a DE (Gnome,Mate, ...) is present.
> If I'm correct, and given the fact that I don't use a DE, I could look
> at safely remove it?

Yup.

> In other words, why is dbus a dependency when no DE is installed or what
> are the corner cases when dbus is needed without a DE.

dbus is an optional dependency to systemd.
The reasons of such dependency are:

1) libpam-systemd, loginctl and friends.
Useful for a workstation, useless for a server.

2) Privilege escalation of systemctl, which is hardwired to PolicyKit.
Same as above.

Reco

[toc] | [prev] | [next] | [standalone]

#212777

Reco <recoverym4n@enotuniq.net> wrote:

> 1) libpam-systemd, loginctl and friends.
> Useful for a workstation, useless for a server.

I wouldn't go this far. libpam-systemd and loginctl can be useful on a
server, depening on its job and role.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#212779

	Hi.

On Wed, Aug 14, 2019 at 08:58:56AM +0200, Sven Hartge wrote:
> Reco <recoverym4n@enotuniq.net> wrote:
> 
> > 1) libpam-systemd, loginctl and friends.
> > Useful for a workstation, useless for a server.
> 
> I wouldn't go this far. libpam-systemd and loginctl can be useful on a
> server, depening on its job and role.

Let me rephrase. On a typical database server, file server, DNS server
and/or web server - libpam-systemd is virtually useless.
The reason for this is - all interactive user logins are used for
management tasks, not running resource-consuming programs.

Reco

[toc] | [prev] | [next] | [standalone]

#212781

On 2019-08-14, Reco <recoverym4n@enotuniq.net> wrote:
> 	Hi.
>
> On Wed, Aug 14, 2019 at 08:58:56AM +0200, Sven Hartge wrote:
>> Reco <recoverym4n@enotuniq.net> wrote:
>> 
>> > 1) libpam-systemd, loginctl and friends.
>> > Useful for a workstation, useless for a server.
>> 
>> I wouldn't go this far. libpam-systemd and loginctl can be useful on a
>> server, depening on its job and role.
>
> Let me rephrase. On a typical database server, file server, DNS server
> and/or web server - libpam-systemd is virtually useless.
> The reason for this is - all interactive user logins are used for
> management tasks, not running resource-consuming programs.

There's actually a bug report concerning this very issue (well, the OP
issue as it stood before the inevitable thread bifurcation), which
explains the why, if not the how.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805449

> Reco
>
>


-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

[toc] | [prev] | [next] | [standalone]

#212833

On Wed 14 Aug 2019 at 07:36:21 +0200, john doe wrote:

> Hi Rico, and thanks for your answer.
> 
> On 8/13/2019 9:25 PM, Reco wrote:
> > On Tue, Aug 13, 2019 at 08:07:49PM +0200, john doe wrote:
> >> I have no plan to reboot that server, what are the pros and cons of not
> >> doing that
> >
> > Pro: keeping uptime
> > Con: keeping previous, possibly buggy, version for dbus running.
> >
> >> or how can I avoid rebooting altogether?
> >
> > dbus is not mandatory and is redundant for typical server software.
> > If you don't need it - just uninstall it. Simple as that.
> >
> 
> okay, dbus is only required when a DE (Gnome,Mate, ...) is present.
> If I'm correct, and given the fact that I don't use a DE, I could look
> at safely remove it?

You are not correct. 'apt rdepends dbus' is worth looking at.
> 
> In other words, why is dbus a dependency when no DE is installed or what
> are the corner cases when dbus is needed without a DE.

Those setting up a print server would likely not see a corner case here.

-- 
Brian. 

[toc] | [prev] | [next] | [standalone]

#212834

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 15, 2019 at 05:52:39PM +0100, Brian wrote:

[...]

> Those setting up a print server would likely not see a corner case here.

CUPS depends on avahi depends somehow on dbus. Try some day lprng,
works a charm :-)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#212836

On Thu 15 Aug 2019 at 19:14:19 +0200, tomas@tuxteam.de wrote:

> On Thu, Aug 15, 2019 at 05:52:39PM +0100, Brian wrote:
> 
> [...]
> 
> > Those setting up a print server would likely not see a corner case here.
> 
> CUPS depends on avahi depends somehow on dbus. Try some day lprng,
> works a charm :-)

I wouldn't try to dissuade anyone from using last century's technology
if they have their heart set on it. At the same time, I would have a
hard time convincing an enterprise organisation (or someone with a small
home network) that lprng fits seamlessly into today's modern printer
market or the mobile world.

Mangles still squeeze water out of wet, washed linen. But spin dryers
reign supreme in many households. :)

The fact remains that dbus is not a DE only package. How did anyone get
the idea it was? connman on a server would not be out of place. It needs
dbus.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#212838

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 15, 2019 at 07:41:06PM +0100, Brian wrote:

> I wouldn't try to dissuade anyone from using last century's technology
> if they have their heart set on it [...]

C'mon. You /know/ you're talking nonsense. Old is old, and new is new.
Beyond that...

BTW I still use TeX, so... 1980s. Works a charm, too.

Use what works for you, whether old or new doesn't matter

"Enterprise". Something like "mauve" database servers [1]?

Cheers

[1] https://dilbert.com/strip/1995-11-17
    Also last-century. And yes, I've had my stints at enterprises.
    Dilbert is almost always spot-on.

-- t

[toc] | [prev] | [next] | [standalone]

#212839

On Thu 15 Aug 2019 at 21:05:10 +0200, tomas@tuxteam.de wrote:

> On Thu, Aug 15, 2019 at 07:41:06PM +0100, Brian wrote:
> 
> > I wouldn't try to dissuade anyone from using last century's technology
> > if they have their heart set on it [...]
> 
> C'mon. You /know/ you're talking nonsense. Old is old, and new is new.
> Beyond that...
> 
> BTW I still use TeX, so... 1980s. Works a charm, too.

The technology I am referring to (as I think you very well know) is the
printing system. No more, no less. Nowadays that system often relies on
printer/print queue Bonjour broadcasts. Not only that, but printers have
changed considerable since lprng was conceived and it is completely
unable to handle them. Tex, on the other hand, is still able to handle
document processing.

dbus "...is redundant for typical server software" appears to deserve
some explanation.

> Use what works for you, whether old or new doesn't matter

"old" doesn't work for modern printing systems. Otherwise, I couldn't
care less what a user uses.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#212849

On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
> On Thu 15 Aug 2019 at 21:05:10 +0200, tomas@tuxteam.de wrote:
>
> > On Thu, Aug 15, 2019 at 07:41:06PM +0100, Brian wrote:
> >
> > > I wouldn't try to dissuade anyone from using last century's
> > > technology
> > > if they have their heart set on it [...]
> >
> > C'mon. You /know/ you're talking nonsense. Old is old, and new is
> > new.
> > Beyond that...
> >
> > BTW I still use TeX, so... 1980s. Works a charm, too.
>
> The technology I am referring to (as I think you very well know) is
> the printing system. No more, no less.

Which is last century by itself.


> Nowadays that system often relies on printer/print queue Bonjour
> broadcasts.

And that is called "jumping to conclusions".
Printing itself haven't changed a bit for last 15 years - a print server
takes user's PS or PDF, mangles it to fit printer's representation (be
it PCL or something else), and feeds it to the printer. By utilizing
unicasts of course.
A user can discover a print server via mDNS multicasts (*not*
broadcasts). Or a user can be told a location of such print server.

avahi is useful for discovery of CUPS, and that's about it.


> dbus "...is redundant for typical server software" appears to deserve
> some explanation.
>
> > Use what works for you, whether old or new doesn't matter
>
> "old" doesn't work for modern printing systems.

Of course it does.

Reco

[toc] | [prev] | [next] | [standalone]

#212853

On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote:

> On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
> > On Thu 15 Aug 2019 at 21:05:10 +0200, tomas@tuxteam.de wrote:
> >
> > > On Thu, Aug 15, 2019 at 07:41:06PM +0100, Brian wrote:
> > >
> > > > I wouldn't try to dissuade anyone from using last century's
> > > > technology
> > > > if they have their heart set on it [...]
> > >
> > > C'mon. You /know/ you're talking nonsense. Old is old, and new is
> > > new.
> > > Beyond that...
> > >
> > > BTW I still use TeX, so... 1980s. Works a charm, too.
> >
> > The technology I am referring to (as I think you very well know) is
> > the printing system. No more, no less.
> 
> Which is last century by itself.
> 
> 
> > Nowadays that system often relies on printer/print queue Bonjour
> > broadcasts.
> 
> And that is called "jumping to conclusions".
> Printing itself haven't changed a bit for last 15 years - a print server
> takes user's PS or PDF, mangles it to fit printer's representation (be
> it PCL or something else), and feeds it to the printer. By utilizing
> unicasts of course.
> A user can discover a print server via mDNS multicasts (*not*
> broadcasts). Or a user can be told a location of such print server.
> 
> avahi is useful for discovery of CUPS, and that's about it.

Printer discovery is an important aspect of a modern printing system.
If a user or institution can get by without it, fine. If not, dbus is
required.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#212884

On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote:

> On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
> 
> > Nowadays that system often relies on printer/print queue Bonjour
> > broadcasts.
> 
> And that is called "jumping to conclusions".
> Printing itself haven't changed a bit for last 15 years - a print server
> takes user's PS or PDF, mangles it to fit printer's representation (be
> it PCL or something else), and feeds it to the printer. By utilizing
> unicasts of course.

I was going to let this go because it takes us beyond the server
situation we are discussing and is a reasonable, succinct description
of classic printing (which will become unsupported by CUPS in a few
years time).

However, modern printers will accept and print jobs (e.g. PDF and JPEG)
without the mangling. These AirPrint-enabled, IPP printers completely
do away with having to use non-free software or plugins also. What is
there to dislike about that?

> A user can discover a print server via mDNS multicasts (*not*
> broadcasts). Or a user can be told a location of such print server.

So - I give my VIP, Android-using customer a piece of paper with a URI
to type into his phone rather than telling him which printer to use to
print out the multimillion Euro contract he has just signed? Very last
century. Anyone fancy carrier pigeons?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#212890

On Fri, Aug 16, 2019 at 07:14:58PM +0100, Brian wrote:
> On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote:
> 
> > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
> > 
> > > Nowadays that system often relies on printer/print queue Bonjour
> > > broadcasts.
> > 
> > And that is called "jumping to conclusions".
> > Printing itself haven't changed a bit for last 15 years - a print server
> > takes user's PS or PDF, mangles it to fit printer's representation (be
> > it PCL or something else), and feeds it to the printer. By utilizing
> > unicasts of course.
> 
> I was going to let this go because it takes us beyond the server
> situation we are discussing and is a reasonable, succinct description
> of classic printing (which will become unsupported by CUPS in a few
> years time).
> 
> However, modern printers will accept and print jobs (e.g. PDF and JPEG)
> without the mangling. These AirPrint-enabled, IPP printers completely
> do away with having to use non-free software or plugins also. What is
> there to dislike about that?

Nothing. But it also means that one only needs something like ipptool
([1]) on client-side, leaving CUPS (and a whole notion of a "print
server") out of the equation completely.


> > A user can discover a print server via mDNS multicasts (*not*
> > broadcasts). Or a user can be told a location of such print server.
> 
> So - I give my VIP, Android-using customer a piece of paper with a URI
> to type into his phone rather than telling him which printer to use to
> print out the multimillion Euro contract he has just signed?
> Very last century.

Multicasts are limited to a single L2 network segment by their very
definition.
Putting your printers (or print servers) within a guest network (WiFi
for Android customers) - that's a last century indeed.

Besides, "multimillion Euro contract" can involve some pretty secretary
lady who's happy to print said contract. Just saying.

Reco

[1] https://github.com/istopwg/ippsample

[toc] | [prev] | [next] | [standalone]

#212898

On Fri 16 Aug 2019 at 22:39:09 +0300, Reco wrote:

> On Fri, Aug 16, 2019 at 07:14:58PM +0100, Brian wrote:
> > On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote:
> > 
> > > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
> > > 
> > > > Nowadays that system often relies on printer/print queue Bonjour
> > > > broadcasts.
> > > 
> > > And that is called "jumping to conclusions".
> > > Printing itself haven't changed a bit for last 15 years - a print server
> > > takes user's PS or PDF, mangles it to fit printer's representation (be
> > > it PCL or something else), and feeds it to the printer. By utilizing
> > > unicasts of course.
> > 
> > I was going to let this go because it takes us beyond the server
> > situation we are discussing and is a reasonable, succinct description
> > of classic printing (which will become unsupported by CUPS in a few
> > years time).
> > 
> > However, modern printers will accept and print jobs (e.g. PDF and JPEG)
> > without the mangling. These AirPrint-enabled, IPP printers completely
> > do away with having to use non-free software or plugins also. What is
> > there to dislike about that?
> 
> Nothing. But it also means that one only needs something like ipptool
> ([1]) on client-side, leaving CUPS (and a whole notion of a "print
> server") out of the equation completely.

ipptool depends on libcups2.

> > > A user can discover a print server via mDNS multicasts (*not*
> > > broadcasts). Or a user can be told a location of such print server.
> > 
> > So - I give my VIP, Android-using customer a piece of paper with a URI
> > to type into his phone rather than telling him which printer to use to
> > print out the multimillion Euro contract he has just signed?
> > Very last century.
> 
> Multicasts are limited to a single L2 network segment by their very
> definition.

DNS-SD/Bonjour not scaling on typical multi-segment networks is a
recognised issue by CUPS upstream. Developments at

 https://tools.ietf.org/wg/dnssd/

could produce a solution that CUPS could take advantage of.
 
> Putting your printers (or print servers) within a guest network (WiFi
> for Android customers) - that's a last century indeed.
> 
> Besides, "multimillion Euro contract" can involve some pretty secretary
> lady who's happy to print said contract. Just saying.

I have no idea whether a secretary likes to be typecast, but is being
pretty, male and amenable a prerequisite to obtaining the post? 

Anyway, the secretary has knocked off and I am left to instruct my VIP
how to use his Android phone to type the printer location without a
mistype:

 dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2

So much for telling a user a location. While he is typing I could rivet
him with describing the difference between a broadcast and a multicast.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#212911

On Fri, Aug 16, 2019 at 11:23:48PM +0100, Brian wrote:
> On Fri 16 Aug 2019 at 22:39:09 +0300, Reco wrote:
> 
> > On Fri, Aug 16, 2019 at 07:14:58PM +0100, Brian wrote:
> > > On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote:
> > > 
> > > > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
> > > > 
> > > > > Nowadays that system often relies on printer/print queue Bonjour
> > > > > broadcasts.
> > > > 
> > > > And that is called "jumping to conclusions".
> > > > Printing itself haven't changed a bit for last 15 years - a print server
> > > > takes user's PS or PDF, mangles it to fit printer's representation (be
> > > > it PCL or something else), and feeds it to the printer. By utilizing
> > > > unicasts of course.
> > > 
> > > I was going to let this go because it takes us beyond the server
> > > situation we are discussing and is a reasonable, succinct description
> > > of classic printing (which will become unsupported by CUPS in a few
> > > years time).
> > > 
> > > However, modern printers will accept and print jobs (e.g. PDF and JPEG)
> > > without the mangling. These AirPrint-enabled, IPP printers completely
> > > do away with having to use non-free software or plugins also. What is
> > > there to dislike about that?
> > 
> > Nothing. But it also means that one only needs something like ipptool
> > ([1]) on client-side, leaving CUPS (and a whole notion of a "print
> > server") out of the equation completely.
> 
> ipptool depends on libcups2.

Which does not make it require CUPS on the other side - [2].
And note - a conventional RFC1918 IP is used there. No "discovery"
involved.


> > > > A user can discover a print server via mDNS multicasts (*not*
> > > > broadcasts). Or a user can be told a location of such print server.
> > > 
> > > So - I give my VIP, Android-using customer a piece of paper with a URI
> > > to type into his phone rather than telling him which printer to use to
> > > print out the multimillion Euro contract he has just signed?
> > > Very last century.
> > 
> > Multicasts are limited to a single L2 network segment by their very
> > definition.
> 
> DNS-SD/Bonjour not scaling on typical multi-segment networks is a
> recognised issue by CUPS upstream.

An interesting example of corporate doublespeak, but it does not change
what I wrote - you need multicasts working - you put both sender and
receiver in a single network segment.
And that's bad for security, and is so last century.


> > Besides, "multimillion Euro contract" can involve some pretty secretary
> > lady who's happy to print said contract. Just saying.
> 
> I have no idea whether a secretary likes to be typecast, but is being
> pretty, male and amenable a prerequisite to obtaining the post? 
> 
> Anyway, the secretary has knocked off and I am left to instruct my VIP
> how to use his Android phone to type the printer location without a
> mistype:
> 
>  dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2

You overcomplicate things without the need.
ipp://<ur_printer> is all you need.

Reco

[2] https://stackoverflow.com/questions/19232082/printing-using-ipp-without-drivers-ipp-client

[toc] | [prev] | [next] | [standalone]

#212912

On Sat 17 Aug 2019 at 12:59:16 +0300, Reco wrote:

> On Fri, Aug 16, 2019 at 11:23:48PM +0100, Brian wrote:
> > 
> > ipptool depends on libcups2.
> 
> Which does not make it require CUPS on the other side - [2].
> And note - a conventional RFC1918 IP is used there. No "discovery"
> involved.

Anything from Kurt Pfeifle is always a worthwhile read.
 
> > DNS-SD/Bonjour not scaling on typical multi-segment networks is a
> > recognised issue by CUPS upstream.
> 
> An interesting example of corporate doublespeak, but it does not change
> what I wrote - you need multicasts working - you put both sender and
> receiver in a single network segment.
> And that's bad for security, and is so last century.

I don't think the principal upstream CUPS developer is given to
speaking with a forked tongue or pulling the wool over people's
eyes,

> > Anyway, the secretary has knocked off and I am left to instruct my VIP
> > how to use his Android phone to type the printer location without a
> > mistype:
> > 
> >  dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2
> 
> You overcomplicate things without the need.

Neither myself nor my VIP know what we are doing. We just wish the
sysadmin had had the commensense to set up printing so a tap on a
queue/printer name would have sufficed.

> ipp://<ur_printer> is all you need.

Eventually we hit on ipp://<IP_address>/<resource>. The resource name
format depends on whether a queue or printer is being printed to.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#212841

On Thu, 2019-08-15 at 19:41 +0100, Brian wrote:
> The fact remains that dbus is not a DE only package. How did anyone
> get the idea it was?

Perhaps because D-Bus stands for Desktop Bus and according to Wikipedia
[1]

   D-Bus was developed as part of the freedesktop.org project [...] to
   standardize services provided by Linux desktop environments such as
   GNOME and KDE.

It's seems quite reasonable to me for people to jump to the conclusion
that it's not likely relevant for servers.

[1] https://en.wikipedia.org/wiki/D-Bus

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web