Re: dbus-deamon avoiding reboot after upgrade
Hi. On Mon, Aug 19, 2019 at 10:08:10PM +0300, Andrei POPESCU wrote: > On Lu, 19 aug 19, 09:54:08, john doe wrote: > > Hi Rico, thanks for your answer. > > On 8/19/2019 9:37 AM, Reco wrote: > > > On Mon, Aug 19, 2019 at 09:25:56AM +0200, john doe wrote: > > >> > > >> Here is the requested output from a test server: > > >> > > >> $ apt purge dbus -s > > > <...> > > >> dbus* libpam-systemd* > > > > > > So, dbus is not needed there. > > > > > > > Okay, one more question, can you give me an example where dbus is > > required on a non-desktop env or is cups requiring dbus? > > I believe libpam-systemd (Depends: dbus) is necessary if you need > systemd user instances. I'm genuinely interested in a usecase of these on *a server*. Reco
Re: dbus-deamon avoiding reboot after upgrade
On Lu, 19 aug 19, 09:54:08, john doe wrote: > Hi Rico, thanks for your answer. > On 8/19/2019 9:37 AM, Reco wrote: > > On Mon, Aug 19, 2019 at 09:25:56AM +0200, john doe wrote: > >> > >> Here is the requested output from a test server: > >> > >> $ apt purge dbus -s > > <...> > >> dbus* libpam-systemd* > > > > So, dbus is not needed there. > > > > Okay, one more question, can you give me an example where dbus is > required on a non-desktop env or is cups requiring dbus? I believe libpam-systemd (Depends: dbus) is necessary if you need systemd user instances. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: dbus-deamon avoiding reboot after upgrade
Le lundi 19 août 2019 à 10:15 -0400, Greg Wooledge a écrit : > On Mon, Aug 19, 2019 at 11:41:33AM +0200, Bastien Durel wrote: > > Ok, there muste have been an error somewhere ... > > > > root@corrin-2:~# apt-cache policy systemd-container > > systemd-container: > > Installed: (none) > > Candidate: 241-5 > > Version table: > > 241-5 500 > > 500 http://ftp.fr.debian.org/debian buster/main amd64 > > PackagesPackages > > root@corrin-2:~# dpkg -S /usr/bin/systemd-nspawn > > dpkg-query: no path found matching pattern /usr/bin/systemd-nspawn > > Are you saying that you installed systemd-nspawn from something other > than a Debian package, *and* you put it in the /usr/bin directory? > That's a really poor decision -- local add-ons should be in > /usr/local > or in /opt. > > Also, it appears you were relying on various dependenent packages, > like > dbus, without knowing it, since the thing that was actually using > them > wasn't installed via the packaging system. That's something you will > have to track yourself. There's no way apt can do it for you. > No, I had a problem during the jessie > strech migration, which leds to /var/lib/dpkg corruption. I "recovered" via a manual re-installation of all jessie deb files found in /var/cache/apt, but some packages seems to have been missing from dpkg index, despite beeing installed. I found a few other files related to non-recorded jessie packages in /usr/bin, like /usr/bin/pydoc3.4 or /usr/bin/mutt-org [1] I re-installed some of the packages, purged some others, and I won't do a full reinstall because I'm too lazy ;) [1] https://paste.debian.net/1096576/ -- Bastien
Re: dbus-deamon avoiding reboot after upgrade
On Mon, Aug 19, 2019 at 11:41:33AM +0200, Bastien Durel wrote: > Ok, there muste have been an error somewhere ... > > root@corrin-2:~# apt-cache policy systemd-container > systemd-container: > Installed: (none) > Candidate: 241-5 > Version table: > 241-5 500 > 500 http://ftp.fr.debian.org/debian buster/main amd64 > PackagesPackages > root@corrin-2:~# dpkg -S /usr/bin/systemd-nspawn > dpkg-query: no path found matching pattern /usr/bin/systemd-nspawn Are you saying that you installed systemd-nspawn from something other than a Debian package, *and* you put it in the /usr/bin directory? That's a really poor decision -- local add-ons should be in /usr/local or in /opt. Also, it appears you were relying on various dependenent packages, like dbus, without knowing it, since the thing that was actually using them wasn't installed via the packaging system. That's something you will have to track yourself. There's no way apt can do it for you. (It's also why I disable apt's autoremove features -- I don't ever want apt to decide I'm *not* using something, because I do have a bunch of local add-ons, and apt can't know what's actually safe to remove.)
Re: dbus-deamon avoiding reboot after upgrade
On Mon, Aug 19, 2019 at 11:41:33AM +0200, Bastien Durel wrote: > Le lundi 19 août 2019 à 11:54 +0300, Reco a écrit : > > Hi. > > > > On Mon, Aug 19, 2019 at 10:23:54AM +0200, Bastien Durel wrote: > > > Le lundi 19 août 2019 à 10:37 +0300, Reco a écrit : > > > > > $ apt purge dbus -s > > > > <...> > > > > >dbus* libpam-systemd* > > > > > > > > So, dbus is not needed there. > > > > > > Hello. Same here, but with dbus removed, my jobs using systemd- > > > nspawn > > > fails with: > > > > > > Failed to open system bus: Connection refused > > > > > > So testing your system after removal may be a good idea, apt > > > insight is > > > not sufficient ;) > > > > $ apt show systemd-container | grep dbus > > Depends: libacl1 (>= 2.2.23), ..., dbus > > > > apt cannot help you if you're using it wrong. > > Ok, there muste have been an error somewhere ... And I'd solve it with "apt install systemd-container". Reco
Re: dbus-deamon avoiding reboot after upgrade
Le lundi 19 août 2019 à 11:54 +0300, Reco a écrit : > Hi. > > On Mon, Aug 19, 2019 at 10:23:54AM +0200, Bastien Durel wrote: > > Le lundi 19 août 2019 à 10:37 +0300, Reco a écrit : > > > > $ apt purge dbus -s > > > <...> > > > >dbus* libpam-systemd* > > > > > > So, dbus is not needed there. > > > > Hello. Same here, but with dbus removed, my jobs using systemd- > > nspawn > > fails with: > > > > Failed to open system bus: Connection refused > > > > So testing your system after removal may be a good idea, apt > > insight is > > not sufficient ;) > > $ apt show systemd-container | grep dbus > Depends: libacl1 (>= 2.2.23), ..., dbus > > apt cannot help you if you're using it wrong. > > Reco > Ok, there muste have been an error somewhere ... root@corrin-2:~# apt-cache policy systemd-container systemd-container: Installed: (none) Candidate: 241-5 Version table: 241-5 500 500 http://ftp.fr.debian.org/debian buster/main amd64 PackagesPackages root@corrin-2:~# dpkg -S /usr/bin/systemd-nspawn dpkg-query: no path found matching pattern /usr/bin/systemd-nspawn :/ -- Bastien
Re: dbus-deamon avoiding reboot after upgrade
Hi. On Mon, Aug 19, 2019 at 10:23:54AM +0200, Bastien Durel wrote: > Le lundi 19 août 2019 à 10:37 +0300, Reco a écrit : > > > $ apt purge dbus -s > > <...> > > >dbus* libpam-systemd* > > > > So, dbus is not needed there. > > Hello. Same here, but with dbus removed, my jobs using systemd-nspawn > fails with: > > Failed to open system bus: Connection refused > > So testing your system after removal may be a good idea, apt insight is > not sufficient ;) $ apt show systemd-container | grep dbus Depends: libacl1 (>= 2.2.23), ..., dbus apt cannot help you if you're using it wrong. Reco
Re: dbus-deamon avoiding reboot after upgrade
Le lundi 19 août 2019 à 10:37 +0300, Reco a écrit : > > $ apt purge dbus -s > <...> > >dbus* libpam-systemd* > > So, dbus is not needed there. Hello. Same here, but with dbus removed, my jobs using systemd-nspawn fails with: Failed to open system bus: Connection refused So testing your system after removal may be a good idea, apt insight is not sufficient ;) -- Bastien
Re: dbus-deamon avoiding reboot after upgrade
On Mon, Aug 19, 2019 at 09:54:08AM +0200, john doe wrote: > >> If things goes well on this server, which is a test server, I'll > >> consider purging dbus from my production server(s) on which a reboot is > >> to be avoided. > >> > >> Here is the requested output from a test server: > >> > >> $ apt purge dbus -s > > <...> > >> dbus* libpam-systemd* > > > > So, dbus is not needed there. > > > > Okay, one more question, can you give me an example where dbus is > required on a non-desktop env or is cups requiring dbus? Let's see. firewalld. Yet another netfilter/nft frontend. One of favorite Red Hat toys. pacemaker. For those who think that cluster is "it's not down if it's restarted on a neighbour host". nfs-ganesha. Userspace NFS server, designed to be run in a container. Slow as a snail, but is useful to somebody. teamd. Linux bonding has a huge implementation deficiency - it does not depend on dbus :) This one does. avahi-daemon. Was mentioned in this very thread. And last, but not least - any terminal server, like LTSP. Reco
Re: dbus-deamon avoiding reboot after upgrade
Hi Rico, thanks for your answer. On 8/19/2019 9:37 AM, Reco wrote: > Hi. > > On Mon, Aug 19, 2019 at 09:25:56AM +0200, john doe wrote: >> On 8/18/2019 4:59 PM, Reco wrote: >>> On Sun, Aug 18, 2019 at 04:56:34PM +0200, john doe wrote: On 8/18/2019 3:19 PM, Brian wrote: > On Sun 18 Aug 2019 at 12:17:59 +0200, john doe wrote: > >> On 8/17/2019 8:15 PM, Brian wrote: >>> On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote: 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? >>> >>> In the light of Curt's reference to #805449 and your reluctance to >>> provide any extra information on the server setup you have in mind, >>> your plan will have to accomodate reality. Reboot and be done with >>> it. >>> >> >> From reading this thread, here's what I understand: >> >> Despide the word desktop being thrown everyware (URL of the page given >> in this thread, ...) it has now moved to be use or at the very least >> installed, on non-desktop host. >> >> If the above is correct, is there a rule to determine if dbus is >> required? >> Relying on apt/apt-get is something that I'm not comfortable with! :) > > The -s option to apt could make you feel more comfortable if you are > concerned about damaging the system. Otherwise, 'aptitude why dbus'. > Thank you, Apt/apt-get will do what I tell it to do but what I don't understand is on what bases should I remove dbus. In other words, in what cases is dbus not redondent/when do I need dbus on a non-desktop environment. >>> >>> Show us 'apt purge dbus -s' output please. >> >> If things goes well on this server, which is a test server, I'll >> consider purging dbus from my production server(s) on which a reboot is >> to be avoided. >> >> Here is the requested output from a test server: >> >> $ apt purge dbus -s > <...> >> dbus* libpam-systemd* > > So, dbus is not needed there. > Okay, one more question, can you give me an example where dbus is required on a non-desktop env or is cups requiring dbus? > >> Is apt the only way to know if dbus is redundant? > > No, but it's an easiest one. > > Hard one would be to answer "what function this server serves", > following by "what software performs said function", following by "what > the software in question really needs to be operational". Requires > knowing your software and a good memory, as usual. > > >> Sorry for not providing the output earlier, but I was hoping for a more >> general way to determine on which server dbus can be safely removed. > > Replace "dbus" with "some annoying dependency", and you'll see that some > questions are better left answered by machine, not a human. > Duly noted, thanks again. -- John Doe
Re: dbus-deamon avoiding reboot after upgrade
Hi. On Mon, Aug 19, 2019 at 09:25:56AM +0200, john doe wrote: > On 8/18/2019 4:59 PM, Reco wrote: > > On Sun, Aug 18, 2019 at 04:56:34PM +0200, john doe wrote: > >> On 8/18/2019 3:19 PM, Brian wrote: > >>> On Sun 18 Aug 2019 at 12:17:59 +0200, john doe wrote: > >>> > On 8/17/2019 8:15 PM, Brian wrote: > > On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote: > >> > >> 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? > > > > In the light of Curt's reference to #805449 and your reluctance to > > provide any extra information on the server setup you have in mind, > > your plan will have to accomodate reality. Reboot and be done with > > it. > > > > From reading this thread, here's what I understand: > > Despide the word desktop being thrown everyware (URL of the page given > in this thread, ...) it has now moved to be use or at the very least > installed, on non-desktop host. > > If the above is correct, is there a rule to determine if dbus is > required? > Relying on apt/apt-get is something that I'm not comfortable with! :) > >>> > >>> The -s option to apt could make you feel more comfortable if you are > >>> concerned about damaging the system. Otherwise, 'aptitude why dbus'. > >>> > >> > >> Thank you, Apt/apt-get will do what I tell it to do but what I don't > >> understand is on what bases should I remove dbus. > >> > >> In other words, in what cases is dbus not redondent/when do I need dbus > >> on a non-desktop environment. > > > > Show us 'apt purge dbus -s' output please. > > If things goes well on this server, which is a test server, I'll > consider purging dbus from my production server(s) on which a reboot is > to be avoided. > > Here is the requested output from a test server: > > $ apt purge dbus -s <...> > dbus* libpam-systemd* So, dbus is not needed there. > Is apt the only way to know if dbus is redundant? No, but it's an easiest one. Hard one would be to answer "what function this server serves", following by "what software performs said function", following by "what the software in question really needs to be operational". Requires knowing your software and a good memory, as usual. > Sorry for not providing the output earlier, but I was hoping for a more > general way to determine on which server dbus can be safely removed. Replace "dbus" with "some annoying dependency", and you'll see that some questions are better left answered by machine, not a human. Reco
Re: dbus-deamon avoiding reboot after upgrade
On 8/18/2019 4:59 PM, Reco wrote: > On Sun, Aug 18, 2019 at 04:56:34PM +0200, john doe wrote: >> On 8/18/2019 3:19 PM, Brian wrote: >>> On Sun 18 Aug 2019 at 12:17:59 +0200, john doe wrote: >>> On 8/17/2019 8:15 PM, Brian wrote: > On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote: > >> 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? > > In the light of Curt's reference to #805449 and your reluctance to > provide any extra information on the server setup you have in mind, > your plan will have to accomodate reality. Reboot and be done with > it. > From reading this thread, here's what I understand: Despide the word desktop being thrown everyware (URL of the page given in this thread, ...) it has now moved to be use or at the very least installed, on non-desktop host. If the above is correct, is there a rule to determine if dbus is required? Relying on apt/apt-get is something that I'm not comfortable with! :) >>> >>> The -s option to apt could make you feel more comfortable if you are >>> concerned about damaging the system. Otherwise, 'aptitude why dbus'. >>> >> >> Thank you, Apt/apt-get will do what I tell it to do but what I don't >> understand is on what bases should I remove dbus. >> >> In other words, in what cases is dbus not redondent/when do I need dbus >> on a non-desktop environment. > > Show us 'apt purge dbus -s' output please. > If things goes well on this server, which is a test server, I'll consider purging dbus from my production server(s) on which a reboot is to be avoided. Here is the requested output from a test server: $ apt purge dbus -s Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: dbus* libpam-systemd* 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. Purg libpam-systemd [241-5] Purg dbus [1.12.16-1] Is apt the only way to know if dbus is redundant? P.S. Sorry for not providing the output earlier, but I was hoping for a more general way to determine on which server dbus can be safely removed. -- John Doe
Re: dbus-deamon avoiding reboot after upgrade
On Sun, Aug 18, 2019 at 04:56:34PM +0200, john doe wrote: > On 8/18/2019 3:19 PM, Brian wrote: > > On Sun 18 Aug 2019 at 12:17:59 +0200, john doe wrote: > > > >> On 8/17/2019 8:15 PM, Brian wrote: > >>> On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote: > >>> > 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? > >>> > >>> In the light of Curt's reference to #805449 and your reluctance to > >>> provide any extra information on the server setup you have in mind, > >>> your plan will have to accomodate reality. Reboot and be done with > >>> it. > >>> > >> > >> From reading this thread, here's what I understand: > >> > >> Despide the word desktop being thrown everyware (URL of the page given > >> in this thread, ...) it has now moved to be use or at the very least > >> installed, on non-desktop host. > >> > >> If the above is correct, is there a rule to determine if dbus is required? > >> Relying on apt/apt-get is something that I'm not comfortable with! :) > > > > The -s option to apt could make you feel more comfortable if you are > > concerned about damaging the system. Otherwise, 'aptitude why dbus'. > > > > Thank you, Apt/apt-get will do what I tell it to do but what I don't > understand is on what bases should I remove dbus. > > In other words, in what cases is dbus not redondent/when do I need dbus > on a non-desktop environment. Show us 'apt purge dbus -s' output please. Reco
Re: dbus-deamon avoiding reboot after upgrade
On 8/18/2019 3:19 PM, Brian wrote: > On Sun 18 Aug 2019 at 12:17:59 +0200, john doe wrote: > >> On 8/17/2019 8:15 PM, Brian wrote: >>> On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote: >>> 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? >>> >>> In the light of Curt's reference to #805449 and your reluctance to >>> provide any extra information on the server setup you have in mind, >>> your plan will have to accomodate reality. Reboot and be done with >>> it. >>> >> >> From reading this thread, here's what I understand: >> >> Despide the word desktop being thrown everyware (URL of the page given >> in this thread, ...) it has now moved to be use or at the very least >> installed, on non-desktop host. >> >> If the above is correct, is there a rule to determine if dbus is required? >> Relying on apt/apt-get is something that I'm not comfortable with! :) > > The -s option to apt could make you feel more comfortable if you are > concerned about damaging the system. Otherwise, 'aptitude why dbus'. > Thank you, Apt/apt-get will do what I tell it to do but what I don't understand is on what bases should I remove dbus. In other words, in what cases is dbus not redondent/when do I need dbus on a non-desktop environment. -- John Doe
Re: dbus-deamon avoiding reboot after upgrade
On Sun 18 Aug 2019 at 12:17:59 +0200, john doe wrote: > On 8/17/2019 8:15 PM, Brian wrote: > > On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote: > > > >> 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? > > > > In the light of Curt's reference to #805449 and your reluctance to > > provide any extra information on the server setup you have in mind, > > your plan will have to accomodate reality. Reboot and be done with > > it. > > > > From reading this thread, here's what I understand: > > Despide the word desktop being thrown everyware (URL of the page given > in this thread, ...) it has now moved to be use or at the very least > installed, on non-desktop host. > > If the above is correct, is there a rule to determine if dbus is required? > Relying on apt/apt-get is something that I'm not comfortable with! :) The -s option to apt could make you feel more comfortable if you are concerned about damaging the system. Otherwise, 'aptitude why dbus'. -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On 8/17/2019 8:15 PM, Brian wrote: > On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote: > >> 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? > > In the light of Curt's reference to #805449 and your reluctance to > provide any extra information on the server setup you have in mind, > your plan will have to accomodate reality. Reboot and be done with > it. > From reading this thread, here's what I understand: Despide the word desktop being thrown everyware (URL of the page given in this thread, ...) it has now moved to be use or at the very least installed, on non-desktop host. If the above is correct, is there a rule to determine if dbus is required? Relying on apt/apt-get is something that I'm not comfortable with! :) Thanks to anyone who has given me their thoughts. -- John Doe
Re: dbus-deamon avoiding reboot after upgrade
On Tue 13 Aug 2019 at 20:07:49 +0200, john doe wrote: > 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? In the light of Curt's reference to #805449 and your reluctance to provide any extra information on the server setup you have in mind, your plan will have to accomodate reality. Reboot and be done with it. -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
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:// is all you need. Eventually we hit on ipp:///. The resource name format depends on whether a queue or printer is being printed to. -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
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:// is all you need. Reco [2] https://stackoverflow.com/questions/19232082/printing-using-ipp-without-drivers-ipp-client
Re: dbus-deamon avoiding reboot after upgrade
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.
Re: dbus-deamon avoiding reboot after upgrade
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
Re: dbus-deamon avoiding reboot after upgrade
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.
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 08:39:43 -0400, Greg Wooledge wrote: > On Fri, Aug 16, 2019 at 09:53:20AM +0300, Reco wrote: > > On Thu, Aug 15, 2019 at 10:36:57PM +0100, Brian wrote: > > > On Thu 15 Aug 2019 at 22:15:59 +0100, Tixy wrote: > > > > > > > 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 > > > > > > Jumping to conclusions is the ideal way of neglecting facts and promoting > > > fallacious assertions. I have given two examples that challenge > > > > > > dbus "...is redundant for typical server software" > > > > The first one being "apt cache rdepends"? You can do better than this. > > > > The second one being CUPS? dbus is not required for printing itself. > > Also, most servers don't deal with ink-and-paper printing. At all. I don't quite follow that, but is it of great importance? Some do, and then dbus will be involved in advertising print queues to clients. > Brian asked how people would conclude things about D-Bus, and Tixy gave > a completely legitimate answer. It was an answer I had been considering > writing myself, but I was lazy. > > The name is *literally* an abbreviation for Desktop Bus, and you (Brian) > claim you don't understand why people think it's only for desktop systems? > Come on. I own up to reading solely the primary source at freedesktop. I can find no reference there to dbus being required only when (to quote John Doe) > a DE (Gnome,Mate, ...) is present. Whatever the genesis of the application's name and function, it has evidently moved on in the last 10+ years. firewalld (which looks like a good candidate for use on a server) also depends on dbus. -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 09:53:20AM +0300, Reco wrote: > On Thu, Aug 15, 2019 at 10:36:57PM +0100, Brian wrote: > > On Thu 15 Aug 2019 at 22:15:59 +0100, Tixy wrote: > > > > > 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 > > > > Jumping to conclusions is the ideal way of neglecting facts and promoting > > fallacious assertions. I have given two examples that challenge > > > > dbus "...is redundant for typical server software" > > The first one being "apt cache rdepends"? You can do better than this. > > The second one being CUPS? dbus is not required for printing itself. Also, most servers don't deal with ink-and-paper printing. At all. Brian asked how people would conclude things about D-Bus, and Tixy gave a completely legitimate answer. It was an answer I had been considering writing myself, but I was lazy. The name is *literally* an abbreviation for Desktop Bus, and you (Brian) claim you don't understand why people think it's only for desktop systems? Come on.
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 12:46:17PM +0100, Brian wrote: > On Fri 16 Aug 2019 at 13:21:11 +0200, to...@tuxteam.de wrote: > > I'm getting old, so this piqued somewhat my vanity. I double-checked: [...] > It's a fair cop! :-) Cheers -- t signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 13:21:11 +0200, to...@tuxteam.de wrote: > On Fri, Aug 16, 2019 at 12:15:18PM +0100, Brian wrote: > > On Fri 16 Aug 2019 at 13:01:10 +0200, to...@tuxteam.de wrote: > > [...] > > > > No, I didn't get that idea -- wasn't it you who reminded us that CUPS > > > doesn't require avahi-daemon? > > > > I don't think so; not in this thread anyway. > > I'm getting old, so this piqued somewhat my vanity. I double-checked: > > In Message-ID: <15082019194357.c7ba6d840...@desktop.copernicus.org.uk> > > [me] > >> CUPS depends on avahi depends somehow on dbus. Try some day lprng, > >> works a charm :-) > > [you] > >> I forgot: the cups package does not depend on avahi-daemon; it is a > >> Recommends:. avahi-daemon does depend on dbus. It's a fair cop! -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 12:15:18PM +0100, Brian wrote: > On Fri 16 Aug 2019 at 13:01:10 +0200, to...@tuxteam.de wrote: [...] > > No, I didn't get that idea -- wasn't it you who reminded us that CUPS > > doesn't require avahi-daemon? > > I don't think so; not in this thread anyway. I'm getting old, so this piqued somewhat my vanity. I double-checked: In Message-ID: <15082019194357.c7ba6d840...@desktop.copernicus.org.uk> [me] >> CUPS depends on avahi depends somehow on dbus. Try some day lprng, >> works a charm :-) [you] >> I forgot: the cups package does not depend on avahi-daemon; it is a >> Recommends:. avahi-daemon does depend on dbus. Cheers -- t signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 13:01:10 +0200, to...@tuxteam.de wrote: > On Fri, Aug 16, 2019 at 11:54:50AM +0100, Brian wrote: > > On Fri 16 Aug 2019 at 11:48:30 +0100, Brian wrote: > > > > > On my print server with buster: > > > > > > root@futro:~# apt purge dbus > > > Reading package lists... Done > > > Building dependency tree > > > Reading state information... Done > > > The following packages will be REMOVED: > > > dbus* libpam-systemd* > > > 0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded. > > > After this operation, 1,057 kB disk space will be freed. > > > > Don't get the idea I am using lprng. avahi-daemon is not on the list > > because I choose not to advertise the print queues on this server. > > No, I didn't get that idea -- wasn't it you who reminded us that CUPS > doesn't require avahi-daemon? I don't think so; not in this thread anyway. -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 11:54:50AM +0100, Brian wrote: > On Fri 16 Aug 2019 at 11:48:30 +0100, Brian wrote: > > > On my print server with buster: > > > > root@futro:~# apt purge dbus > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > The following packages will be REMOVED: > > dbus* libpam-systemd* > > 0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded. > > After this operation, 1,057 kB disk space will be freed. > > Don't get the idea I am using lprng. avahi-daemon is not on the list > because I choose not to advertise the print queues on this server. No, I didn't get that idea -- wasn't it you who reminded us that CUPS doesn't require avahi-daemon? Cheers -- tomás signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 11:48:30AM +0100, Brian wrote: > On Fri 16 Aug 2019 at 12:24:14 +0200, to...@tuxteam.de wrote: > > > On Fri, Aug 16, 2019 at 11:03:41AM +0100, Brian wrote: > > > > [...] > > > > > https://www.freedesktop.org/wiki/Software/dbus/ > > ^^^ > > > > ;-) > > DE - Desktop *Environment*. A case of selective censorship? :) Censorship? I didn't get that pun (promised! :) [...] Cheers -- t signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 11:48:30 +0100, Brian wrote: > On my print server with buster: > > root@futro:~# apt purge dbus > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages will be REMOVED: > dbus* libpam-systemd* > 0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded. > After this operation, 1,057 kB disk space will be freed. Don't get the idea I am using lprng. avahi-daemon is not on the list because I choose not to advertise the print queues on this server. -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 12:24:14 +0200, to...@tuxteam.de wrote: > On Fri, Aug 16, 2019 at 11:03:41AM +0100, Brian wrote: > > [...] > > > https://www.freedesktop.org/wiki/Software/dbus/ > ^^^ > > ;-) DE - Desktop *Environment*. A case of selective censorship? :) > [...] > > > As Reco said: > > > > > If you don't need it - just uninstall it. > > > > What do you get for 'apt purge dbus'? > > Not the OP, but here's mine: > > tomas@trotzki:~$ sudo apt purge dbus > [sudo] password for tomas: > Reading package lists... Done > Building dependency tree > Reading state information... Done > Package 'dbus' is not installed, so not removed > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. On my print server with buster: root@futro:~# apt purge dbus Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: dbus* libpam-systemd* 0 upgraded, 0 newly installed, 2 to remove and 3 not upgraded. After this operation, 1,057 kB disk space will be freed. Mmm. I think Reco has led me to a state of enlightenment! -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 11:03:41AM +0100, Brian wrote: [...] > https://www.freedesktop.org/wiki/Software/dbus/ ^^^ ;-) [...] > As Reco said: > > > If you don't need it - just uninstall it. > > What do you get for 'apt purge dbus'? Not the OP, but here's mine: tomas@trotzki:~$ sudo apt purge dbus [sudo] password for tomas: Reading package lists... Done Building dependency tree Reading state information... Done Package 'dbus' is not installed, so not removed 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. And this is: tomas@trotzki:~$ uname -a Linux trotzki 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64 GNU/Linux tomas@trotzki:~$ cat /etc/debian_version 9.9 so it's Stretch, aka oldstable. And oh, of course with an X GUI. Cheers -- tomás signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 11:06:43AM +0200, john doe wrote: [...] > Okay, as far as I understand it, depends means that it will be pulled as > an dependency but not that it is required for it to work properly. > What I'm starting to realise is that to much dependencies are pulled to > implement lots of feature that is not always necessery. That very much depends on the application: some (mis?) use dbus as a dynamic linking facility which could be as well served by shared objects. Kind of a Rube Goldberg way of doing dynamic linking -- but that's my opinion, you'll find others. Bluez is one example. Since it is the only bluetooth framework available under Linux, that means: no dbus -> no bluetooth. Others just complain that there's no dbus and carry on (X is one example. This from my Xorg.0.log (line wrap by me): [ 354.912] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory) > Before posting to the list, a google search let me think that dbus is > only required when DE is wanted. > Do you have online documentation that would explain why dbus is required > when no DE is used? It is a desktop invention (it was introduced by Havoc Pennington, after much frustration trying to adopt Corba for the Gnome Desktop: compared to that, DBus was, indeed, progress. KDE had a similar frustration with its own distributed object monster -- uh -- model and followed suit). But since then it has expanded to non-desktop things. I've got quite a few beefs with DBus, which I won't expand here, but that's why I try to find out how far I can go without it. Turns out, for my use case, pretty far. Cheers -- tomás signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
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, to...@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.
Re: dbus-deamon avoiding reboot after upgrade
On Fri 16 Aug 2019 at 11:06:43 +0200, john doe wrote: > On 8/15/2019 6:52 PM, Brian wrote: > > 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. > >> > > Okay, as far as I understand it, depends means that it will be pulled as > an dependency but not that it is required for it to work properly. > What I'm starting to realise is that to much dependencies are pulled to > implement lots of feature that is not always necessery. > > > Before posting to the list, a google search let me think that dbus is > only required when DE is wanted. > Do you have online documentation that would explain why dbus is required > when no DE is used? As https://www.freedesktop.org/wiki/Software/dbus/ says: > D-Bus is a message bus system, a simple way for applications to > talk to one another. There is no mention of DEs on that page. dbus is for any application to talk to any other application. > P.S. > > The Debian bugreport provided in this thread seems to corroborate your > pointbut I can't find something tangible to back that up. As Reco said: > If you don't need it - just uninstall it. What do you get for 'apt purge dbus'? -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On 8/15/2019 6:52 PM, Brian wrote: > 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. >> Okay, as far as I understand it, depends means that it will be pulled as an dependency but not that it is required for it to work properly. What I'm starting to realise is that to much dependencies are pulled to implement lots of feature that is not always necessery. Before posting to the list, a google search let me think that dbus is only required when DE is wanted. Do you have online documentation that would explain why dbus is required when no DE is used? P.S. The Debian bugreport provided in this thread seems to corroborate your pointbut I can't find something tangible to back that up. -- John Doe
Re: dbus-deamon avoiding reboot after upgrade
On Thu, Aug 15, 2019 at 10:36:57PM +0100, Brian wrote: > On Thu 15 Aug 2019 at 22:15:59 +0100, Tixy wrote: > > > 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 > > Jumping to conclusions is the ideal way of neglecting facts and promoting > fallacious assertions. I have given two examples that challenge > > dbus "...is redundant for typical server software" The first one being "apt cache rdepends"? You can do better than this. The second one being CUPS? dbus is not required for printing itself. Reco
Re: dbus-deamon avoiding reboot after upgrade
On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote: > On Thu 15 Aug 2019 at 21:05:10 +0200, to...@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
Re: dbus-deamon avoiding reboot after upgrade
On Thu 15 Aug 2019 at 22:15:59 +0100, Tixy wrote: > 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 Jumping to conclusions is the ideal way of neglecting facts and promoting fallacious assertions. I have given two examples that challenge dbus "...is redundant for typical server software" -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
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
Re: dbus-deamon avoiding reboot after upgrade
On Thu 15 Aug 2019 at 21:05:10 +0200, to...@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.
Re: dbus-deamon avoiding reboot after upgrade
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 signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
On Thu 15 Aug 2019 at 19:14:19 +0200, to...@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 forgot: the cups package does not depend on avahi-daemon; it is a Recommends:. avahi-daemon does depend on dbus. The OP is setting up a "server". Whatever he means by that is left unsaid. -- Brian.
Re: dbus-deamon avoiding reboot after upgrade
On Thu 15 Aug 2019 at 19:14:19 +0200, to...@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.
Re: dbus-deamon avoiding reboot after upgrade
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 signature.asc Description: Digital signature
Re: dbus-deamon avoiding reboot after upgrade
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.
Re: dbus-deamon avoiding reboot after upgrade
On 2019-08-14, Reco wrote: > Hi. > > On Wed, Aug 14, 2019 at 08:58:56AM +0200, Sven Hartge wrote: >> Reco 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
Re: dbus-deamon avoiding reboot after upgrade
Hi. On Wed, Aug 14, 2019 at 08:58:56AM +0200, Sven Hartge wrote: > Reco 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
Re: dbus-deamon avoiding reboot after upgrade
Reco 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.
Re: dbus-deamon avoiding reboot after upgrade
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
Re: dbus-deamon avoiding reboot after upgrade
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
Re: dbus-deamon avoiding reboot after upgrade
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
