Re: backing up backups
On Sun, Apr 10, 2022 at 09:44:59PM -0700, David Christensen wrote: > On 4/10/22 19:58, Default User wrote: > > Hello! > > > > My setup: > > - single home x86-64 computer running Debian 11 Stable, up to date. > > - one 4-Tb external usb hard drive to use as a backup device, labeled MSD1. > > - another identical usb hard drive, labeled MSD2, to use as a copy of the > > backups on MSD1. > > - the computer and all storage devices are formatted ext4, not encrypted. > > - two old Clonezilla disk images from when I installed Debian 11 last year > > (probably irrelevant). > > - Timeshift to daily back up system EXCEPT for data directories. > > - Back in Time to daily back up data directories. > > - Borgbackup to also daily back up data directories. > > - Rsync to frequently backup any changed data between the daily Back in > > Time and Borgbackup backups of data directories, using this command: > > > > sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 --exclude-from > > "/home/default/rsync_exclude_list.txt" /home > > /media/default/MSD1/rsync_backups_of_host_home_directory_only > > > > Each type of backup is in a separate subdirectory on MSD1 (Timeshift, Back > > in TIme, Rsync, etc.). > > > > It "seems" to work okay, BUT . . . > > > > Then I try to use rsync to make an identical copy of backup device MSD1 on > > an absolutely identical 4-Tb external usb hard drive, > > labeled MSD2, using this command: > > > > sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 > > /media/default/MSD1/ /media/default/MSD2 > > > See 'man 1 rsync'. You have a slash at the end of SRC, but not at the end > of DEST. I would add a slash after "MSD2": The only thing I find in rsync's man page about trailing slashes in the `dest' argument would be relevant if MSD2 didn't exist (in the OP's case it seems it does, no?) Cheers -- t signature.asc Description: PGP signature
Re: backing up backups
On 4/10/22 19:58, Default User wrote: Hello! My setup: - single home x86-64 computer running Debian 11 Stable, up to date. - one 4-Tb external usb hard drive to use as a backup device, labeled MSD1. - another identical usb hard drive, labeled MSD2, to use as a copy of the backups on MSD1. - the computer and all storage devices are formatted ext4, not encrypted. - two old Clonezilla disk images from when I installed Debian 11 last year (probably irrelevant). - Timeshift to daily back up system EXCEPT for data directories. - Back in Time to daily back up data directories. - Borgbackup to also daily back up data directories. - Rsync to frequently backup any changed data between the daily Back in Time and Borgbackup backups of data directories, using this command: sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 --exclude-from "/home/default/rsync_exclude_list.txt" /home /media/default/MSD1/rsync_backups_of_host_home_directory_only Each type of backup is in a separate subdirectory on MSD1 (Timeshift, Back in TIme, Rsync, etc.). It "seems" to work okay, BUT . . . Then I try to use rsync to make an identical copy of backup device MSD1 on an absolutely identical 4-Tb external usb hard drive, labeled MSD2, using this command: sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 /media/default/MSD1/ /media/default/MSD2 See 'man 1 rsync'. You have a slash at the end of SRC, but not at the end of DEST. I would add a slash after "MSD2": sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 /media/default/MSD1/ /media/default/MSD2/ I have experienced USB connection failures with external drives, resulting in filesystem corruption. I prefer mobile racks and caddies for my backup drives, and black SATA 6 GBps cables with locking connectors: https://www.startech.com/en-us/hdd/drw150satbk https://www.cablematters.com/pc-187-156-3-pack-straight-60-gbps-sata-iii-cable.aspx Here's the problem. Although the size and number of items in each subdirectory on MSD1 and MSD2 seem to be identical, more space in total seems to be taken up on MSD2 than on MSD1: df -h /dev/sdb1 Filesystem Size Used Avail Use% Mounted on /dev/sdb1 3.6T 68G 3.4T 2% /media/default/MSD1 df -h /dev/sdc1 Filesystem Size Used Avail Use% Mounted on /dev/sdc1 3.6T 69G 3.4T 2% /media/default/MSD2 df /dev/sdb1 Filesystem 1K-blocks Used AvailableUse% Mounted on /dev/sdb1384451788071255588 35778967642% /media/default/MSD1 df /dev/sdc1 Filesystem 1K-blocksUsed AvailableUse% Mounted on /dev/sdc1384451788071906088 35772462642% /media/default/MSD2 I have tried "everything", even re-formatted MSD2 and re-done: sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 /media/default/MSD1/ /media/default/MSD2 but the results were exactly the same. I doubt that this is a problem with hard links, as I am using the "H" option in rsync. Now , pardon me for thinking that a copy of backups should not take up any more or less space than the original. And I consider backups to be much too important to not be absolutely "correct". So, what SHOULD be done so that MSD2 will always be EXACTLY the same as MSD1? Is there a way to do this using rsync? Do you pause Timeshift, Back in Time, Borgbackup, etc., before using rsync(1) to copy MSD1 to MSD2? Have you compared MSD1 to MSD2 using diff(1) afterwards? If diff(1) is happy, I would call it good. If diff(1) finds differences, figure out why. I suppose I could just make images of MSD1, using dd for example. But then each time wouldn't I just be backing up not just the changed data, but all the data, AND backing up all of the free space on MSD1 also. Aside from wasting TONS of space, each time it could take many hours or even days to do. Which means it just won't get done. So much for redundancy! I agree that dd(1) is overkill and impractical for this use-case. So . . . what IS the correct way to make "backups of backups"? For ext4 backups and ext4 copies of backups, I use rsync(1). Are you doing any integrity checking? E.g. generating a checksum file of the backup contents? Without such, you are exposed to bit rot. David
Re: Strange syslog behaviour [Solved]
On 11/4/22 11:46 am, David Wright wrote: There are tabooext and taboopat directives for ignoring files in logrotated.d, and I would have thought it reasonable to exclude these sorts of housekeeping files by default, because they're very likely to contain some duplication. I would file a bug against logrotate. Keywords tabooext and taboopat don't appear in /etc/* I did get a hit in binary file /usr/sbin/rsyslogd Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: backing up backups
On Sun, Apr 10, 2022 at 11:13 PM David wrote: > On Mon, 11 Apr 2022 at 12:59, Default User > wrote: > > > Then I try to use rsync to make an identical copy of backup device MSD1 > on an absolutely identical 4-Tb external usb hard drive, > > labeled MSD2, using this command: > > > > sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 > /media/default/MSD1/ /media/default/MSD2 > > > > Here's the problem. Although the size and number of items in each > subdirectory on MSD1 and MSD2 seem to be identical, more space in total > seems to be taken up on MSD2 than on MSD1: > > I suggest to try adding option -S to rsync, and see if that makes > any difference. It might only affect the creation of new files, I'm > unsure about that aspect. > Hi David, thanks for the reply. I really don't know anything about sparse blocks, but I will check it out and give it a try.
Re: Strange syslog behaviour [Solved]
On Mon 11 Apr 2022 at 10:07:53 (+0800), Jeremy Ardley wrote: > I have systems (armbian) that had anomalous behaviour. > > This included sometimes writing to /var/log/syslog.1 rather than to > /var/log/syslog (which was created, but zero size) > > Additionally the logrotate was happening daily or twice daily when > seemingly configured for weekly rotates > > Anyway long story short, at some stage some package updates must have > written an extra file into /etc/logrotate.d that had duplicate entries > to the normal files. > > This was interpreted by the logrotate process as well as the intended > files such as /etc/logrotated.d/rsyslog So presumably one instance was still writing to /var/log/syslog when the other one rotated it and created a new one. > On one system this unexpected file was called rsyslog.dpkg-old on > another system it was rsyslog.dpkg-dist Should we assume that you know how these files came to be present, ie that rsyslog had been modified, after which, during upgrading, apt had been given the responses "keep the old one" (Debian's new version becomes ….dpkg-dist) and "replace by the new one (your old version is renamed ….dpkg-old). > Removing these files ( but not /etc/logrotate.d/dpkg ) now has a > correctly configured log rotation There are tabooext and taboopat directives for ignoring files in logrotated.d, and I would have thought it reasonable to exclude these sorts of housekeeping files by default, because they're very likely to contain some duplication. I would file a bug against logrotate. Cheers, David.
Re: backing up backups
On Mon, 11 Apr 2022 at 12:59, Default User wrote: > Then I try to use rsync to make an identical copy of backup device MSD1 on an > absolutely identical 4-Tb external usb hard drive, > labeled MSD2, using this command: > > sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 > /media/default/MSD1/ /media/default/MSD2 > > Here's the problem. Although the size and number of items in each > subdirectory on MSD1 and MSD2 seem to be identical, more space in total seems > to be taken up on MSD2 than on MSD1: I suggest to try adding option -S to rsync, and see if that makes any difference. It might only affect the creation of new files, I'm unsure about that aspect.
backing up backups
Hello! My setup: - single home x86-64 computer running Debian 11 Stable, up to date. - one 4-Tb external usb hard drive to use as a backup device, labeled MSD1. - another identical usb hard drive, labeled MSD2, to use as a copy of the backups on MSD1. - the computer and all storage devices are formatted ext4, not encrypted. - two old Clonezilla disk images from when I installed Debian 11 last year (probably irrelevant). - Timeshift to daily back up system EXCEPT for data directories. - Back in Time to daily back up data directories. - Borgbackup to also daily back up data directories. - Rsync to frequently backup any changed data between the daily Back in Time and Borgbackup backups of data directories, using this command: sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 --exclude-from "/home/default/rsync_exclude_list.txt" /home /media/default/MSD1/rsync_backups_of_host_home_directory_only Each type of backup is in a separate subdirectory on MSD1 (Timeshift, Back in TIme, Rsync, etc.). It "seems" to work okay, BUT . . . Then I try to use rsync to make an identical copy of backup device MSD1 on an absolutely identical 4-Tb external usb hard drive, labeled MSD2, using this command: sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 /media/default/MSD1/ /media/default/MSD2 Here's the problem. Although the size and number of items in each subdirectory on MSD1 and MSD2 seem to be identical, more space in total seems to be taken up on MSD2 than on MSD1: df -h /dev/sdb1 Filesystem Size Used Avail Use% Mounted on /dev/sdb1 3.6T 68G 3.4T 2% /media/default/MSD1 df -h /dev/sdc1 Filesystem Size Used Avail Use% Mounted on /dev/sdc1 3.6T 69G 3.4T 2% /media/default/MSD2 df /dev/sdb1 Filesystem 1K-blocks Used AvailableUse% Mounted on /dev/sdb1384451788071255588 35778967642% /media/default/MSD1 df /dev/sdc1 Filesystem 1K-blocksUsed AvailableUse% Mounted on /dev/sdc1384451788071906088 35772462642% /media/default/MSD2 I have tried "everything", even re-formatted MSD2 and re-done: sudo rsync -aAXHxvv --delete --info=progress2,stats2,name2 /media/default/MSD1/ /media/default/MSD2 but the results were exactly the same. I doubt that this is a problem with hard links, as I am using the "H" option in rsync. Now , pardon me for thinking that a copy of backups should not take up any more or less space than the original. And I consider backups to be much too important to not be absolutely "correct". So, what SHOULD be done so that MSD2 will always be EXACTLY the same as MSD1? Is there a way to do this using rsync? I suppose I could just make images of MSD1, using dd for example. But then each time wouldn't I just be backing up not just the changed data, but all the data, AND backing up all of the free space on MSD1 also. Aside from wasting TONS of space, each time it could take many hours or even days to do. Which means it just won't get done. So much for redundancy! So . . . what IS the correct way to make "backups of backups"?
Re: Apparmor problem.
On 2022-04-09 at 23:09 +0300, George wrote:
> Thanks for the reply!
>
> So any ideas how to solve that problem? I tried a lot of things with
> no luck. I didnt find the particular file at that place.
> I clean the log files and still get these annoying notifications.
Try adding
owner @{HOME}/.mozilla/**/*.{db,parentlock,sqlite}* k,
Unrelated to your issues, but I would recommend as well to:
- change all those /home/*/ to @{HOME}
- Wildcard this one level up, as 8i0h8b60.default-esr is the name of
*your* current profile:
owner /home/*/.cache/mozilla/firefox/8i0h8b60.default-esr/** rw,
- This will break if you run under a different user (1000 is your uid)
owner /run/user/1000/ICEauthority r,
- Have a look at /etc/apparmor.d/usr.bin.thunderbird profile for ideas,
too.
Best regards
Strange syslog behaviour [Solved]
I have systems (armbian) that had anomalous behaviour. This included sometimes writing to /var/log/syslog.1 rather than to /var/log/syslog (which was created, but zero size) Additionally the logrotate was happening daily or twice daily when seemingly configured for weekly rotates Anyway long story short, at some stage some package updates must have written an extra file into /etc/logrotate.d that had duplicate entries to the normal files. This was interpreted by the logrotate process as well as the intended files such as /etc/logrotated.d/rsyslog On one system this unexpected file was called rsyslog.dpkg-old on another system it was rsyslog.dpkg-dist Removing these files ( but not /etc/logrotate.d/dpkg ) now has a correctly configured log rotation -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Tildes y eñes en consola de X.
Hola, - Alguna sugerencia para activar las tildes y eñes en la consola de X? Todo bien en la consola modo texto pero no así en la consola de X. - Se mantiene la desactivación de X para que al iniciar, el sistema se quede en consola? Recuerdo en las versiones anteriores era así: update-rc.d gdm3 disable luego, para levantar la interfaz gráfica ejecutar: startx Pregunto pues no quiero echar a perder nada pues volver a instalar algo gordo, y sin una buena conexión, es una odisea '< -- Saludos, Luis
Re: updatedb.mlocate
On Mon, 11 Apr 2022 at 09:50, Greg Wooledge wrote: > On Mon, Apr 11, 2022 at 09:34:42AM +1000, David wrote: > > On Mon, 11 Apr 2022 at 09:24, David Wright wrote: > > > > > systemctl disable mlocate.service before you fiddle with its > > > configuration, then enable it afterwards. > > > > Hi, I think you need "stop" and "start" there, not "disable" and > > and "enable". > > > > Or maybe "systemctl daemon-reload" although I'm not sure > > about that because I don't know much about systemd. > > > > But a quick test here shows that a "disable" command on a > > running service does not stop it. > > It's not a running service. It's a service that's started by a timer. > The other David's proposal was to disable it, in the hope that this > would prevent the timer from being able to start it. Ah, you're right, I wasn't paying sufficient attention and missed that, sorry for adding noise to the thread.
Re: networking.service fails
Dear Debian community, First of all many thanks to everybody who has replied to my message and contributed ideas to solve the issue. On 3 Apr 2022 22:41:44, Greg Wooledge wrote: > So... you've got some wild stuff going on here. > > You have two interfaces. One of them was named enp2s0 and then got > renamed to eth0, which is usually the opposite direction from what one > expects. > > The other was named enp3s0 and then got renamed to eth1. Which, again, > is the opposite of what one expects. > > Normally, the kernel assigns the name eth0 temporarily to the first > interface that it finds, and then renames it to some "predictable" > name according to obtuse schemes. In your case, I'm imagining that > your interface started as eth0, then got renamed to enp2s0, then renamed > a second time back to eth0. > > At the time when ifup tried to run, the interface was named enp2s0, but > your configuration tried to address it by the name eth0. > > So, there are many questions here. > > How many different interface configuration schemes are you using here? > Which ones are they? > > a) Do you set the net.ifnames kernel parameter? If so, what value are >you setting it to? No, in my initial setup I didn't have this parameter. > b) Do you have any non-loopback interfaces configured in the >/etc/network/interfaces file? If so, which ones, and how are >they configured? The configuration is trivial: it adds both eth0 eth1 to the bridge br0. === cut /etc/network/interfaces === auto lo auto eth0 auto eth1 iface lo inet loopback auto br0 iface br0 inet static address 10.0.1.100 gateway 10.0.1.1 netmask 255.0.0.0 bridge_ports eth0 eth1 bridge_maxwait 60 === cut === > c) Do you have an /etc/udev/rules.d/70-persistent-net.rules file? Note >that this file was deprecated in buster. If it continued to work in >buster, that was just a happy accident. If it stopped working in >bullseye, that is not a surprise. In my initial setup I had this file. > d) Do you have any /etc/systemd/network/*.link files? If so, what's in >them? No, no files in that directory. > e) Do you have network-manager installed? If so, I don't know what >followup questions to ask about it, because I don't use it. No, I don't have network-manager installed. > f) Do you have any /etc/systemd/network/*.network files? If so, what's >in those? No, no files in that directory. > g) Do you have any *other* interface configuration schemes in play that >I don't know about? Nothing special I can think about. > Once you've identified all of the moving parts in this puzzle, then you > can figure out which ones you actually want to keep, and which ones > you should rip out. > > For comparison, my system (Debian 11 bullseye) has one interface. I > configure its name using a file in /etc/systemd/network/ which sets > the name to lan0. Then I configure its in /etc/network/interfaces > using that name. > > Some relevant log file lines: > > Mar 26 08:01:54 unicorn kernel: [1.042579] r8169 :02:00.0 eth0: > RTL8168gu/8111gu, 18:60:24:77:5c:ec, XID 509, IRQ 127 > [...] > Mar 26 08:01:54 unicorn kernel: [1.057022] r8169 :02:00.0 lan0: > renamed from eth0 > [...] > Mar 26 08:01:59 unicorn kernel: [ 20.372606] r8169 :02:00.0 lan0: Link > is Up - 100Mbps/Full - flow control rx/tx > > That's just one of many possible ways to configure network interfaces. > You might be using a different scheme. The important thing is that > you pick *one* scheme and set it up correctly. If you've got two or > more competing schemes in play, and they're undoing each other's work, > that's not desirable. > > It's also worth pointing out that /etc/udev/rules.d/70-persistent-net.rules > was deprecated in buster (Debian 10). According to the release notes, > it *may* work, or it may not. Users were instructed to migrate away > from it. > > It would not surprise me one bit if there's a race condition which causes > the renaming done by 70-persistent-net.rules to occur at the wrong time, > if it even happens at all. Greg, thanks for your remarks and questions – I have learned something new while looking here and there. On 4 Apr 2022 08:50:42, Reco wrote: > As /var/log/messages helpfully show, your udev rules work. > The problem is, next thing udev does is renaming your network interfaces > back to (Un)Predictable Naming™ scheme. > > Thus whatever stanzas you have in your interfaces(5) about eth0 and eth1 > fail, thus the whole networking.service fails. > > > The conclusion is simple too: > > 1) Remove 70-persistent-net.rules, it's not doing what it should anyway. > > 2) Either use (Un)Predictable Network names in your interfaces, such as > enp2s0 and enp3s0. > > 3) Or use systemd network link files to rename network interfaces. > > 4) Or add "net.ifnames=0" to kernel's cmdline, as others suggested. > > Reco Reco, I have applied (1) and (2), namely what I did: *
Re: updatedb.mlocate
On Mon, Apr 11, 2022 at 09:34:42AM +1000, David wrote: > On Mon, 11 Apr 2022 at 09:24, David Wright wrote: > > > systemctl disable mlocate.service before you fiddle with its > > configuration, then enable it afterwards. > > Hi, I think you need "stop" and "start" there, not "disable" and > and "enable". > > Or maybe "systemctl daemon-reload" although I'm not sure > about that because I don't know much about systemd. > > But a quick test here shows that a "disable" command on a > running service does not stop it. It's not a running service. It's a service that's started by a timer. The other David's proposal was to disable it, in the hope that this would prevent the timer from being able to start it. However, I don't think that would work. I think you'd need to mask it. That said, I have not tested either of those things.
Re: updatedb.mlocate
On Mon, 11 Apr 2022 at 09:24, David Wright wrote: > systemctl disable mlocate.service before you fiddle with its > configuration, then enable it afterwards. Hi, I think you need "stop" and "start" there, not "disable" and and "enable". Or maybe "systemctl daemon-reload" although I'm not sure about that because I don't know much about systemd. But a quick test here shows that a "disable" command on a running service does not stop it. It's my understanding that "enable" and "disable" only control whether the service is started at boot time. Someone who knows better is welcome to confirm or correct if I am mistaken, thanks.
Re: updatedb.mlocate
On Sun 10 Apr 2022 at 09:52:15 (-0500), Roy J. Tellason, Sr. wrote: > On Saturday 09 April 2022 01:22:08 pm Charles Curley wrote: > > On Sat, 9 Apr 2022 11:04:18 -0500 > > "Roy J. Tellason, Sr." wrote: > > > > > How do I find out where this is invoked, so I can get rid of it? > > > > You may not want to get rid of it. That's the process that updates the > > database for the locate utility, which is very useful. > > Yeah, it's useful if you change things on the system. I don't do that all > that often, though. Bear in mind it indexes /home, so you can use it for your own files. Obviously, it's a lot faster than find. > > I was about to add, think instead about adding a nice value to its cron > > entry. > > There is some stuff about that in the script in question, but rather than > working my way through all that I just made that script not executable. > > > However it look like mlocate is now handled by systemd, and I > > don't know enough to advise you on how to do that. > > I don't understand the reason for so many things getting pushed in that > direction. It's far more flexible than cron and anacron. But cron is still there, so you could move it back. But I think Greg's contributions to this thread have enough information to make it straightforward for you to change the time to suit. Cheers, David.
Re: updatedb.mlocate
On Sun 10 Apr 2022 at 10:04:53 (-0400), Greg Wooledge wrote: > On Sun, Apr 10, 2022 at 11:33:53AM +0200, Linux-Fan wrote: > > Greg Wooledge writes: > > > unicorn:~$ less /lib/systemd/system/mlocate.timer > > > [Unit] > > > Description=Updates mlocate database every day > > > > > > [Timer] > > > OnCalendar=daily > > > AccuracySec=24h > > > Persistent=true > > > > > > [Install] > > > WantedBy=timers.target > > > > > > ... it doesn't even say when it runs? What silliness is this? > > I was mistaken: it *does* say when it runs, but only if you've read at > least two different man pages. > > systemd.timer(5) says that OnCalendar= specifies a "calendar event > expression", and refers to systemd.time(7) to explain what that means. > > systemd.time(7) says that a "calendar event" defines one or more points > in time, and then gives some examples. By reading these examples, > one may infer that this thing specifies when the timer will trigger. > > It also explains that the keyword "daily" doesn't just mean "once a day". > It actually says: > > daily → *-*-* 00:00:00 > > In other words, "daily" explicitly means "once a day at local midnight", > assuming you can infer that "*-*-*" means "once a day". To be fair, man systemd.time is extremely comprehensive, with abundant examples (* is expressly defined). So I'm not surprised that it's hived off into a separate man page to avoid repeating it elsewhere. > > Specifically in the case of `cron`, I think it is an improvement that user- > > specific timers are now kept in the user's home directory > > (~/.config/systemd/user directory) rather than a system directory > > (/var/spool/cron/crontabs). > > I am extremely skeptical of how useful it is to specify a systemd timer > at the --user level. They'll only run when the systemd --user service > manager is running, which is only when the user is logged in. > > What kind of jobs would you schedule in a timer, that you would want > to run *only* when you are logged in? I can't really think of any. > Most scheduled jobs would be things I would want to trigger regardless > of whether I'm logged in (cleaning up logs and temp files, retrieving > email from a remote mail server). I guess *some* things could be > deferred until login, like randomizing an email .signature file, but > those would be the exceptions. I don't think it's in the nature of systemd to be proscriptive. One of its advantages is its extreme, almost overwhelming, flexibility. > unicorn:~$ cat /etc/systemd/system/mlocate.timer.d/time.conf > [Timer] > OnCalendar= > OnCalendar=04:20 > > I created a three-line override file which clears out the previous > OnCalendar= event(s), and then sets up a new event that runs the thing > at 04:20 each day, instead of midnight each day. > > unicorn:~$ sudo systemctl daemon-reload > unicorn:~$ systemctl list-timers | grep mlocate > Mon 2022-04-11 04:20:00 EDT 18h leftSun 2022-04-10 09:58:20 EDT 16s ago >mlocate.timermlocate.service > > Slight oops -- after I updated the daemon, the new time for the timer > had already expired, so it ran immediately. That's definitely not how > cron works (changing the time on a cron job doesn't cause an immediate > job execution). I wonder how one would go about changing the time on > a systemd timer *without* triggering an immediate execution in the middle > of the work day. I'm guessing two possibilities might be worth trying: systemctl disable mlocate.service before you fiddle with its configuration, then enable it afterwards. touch /var/lib/systemd/timers/stamp-mlocate.timer with a time in the future, so that systemd thinks it has already been run. I don't think they're mutually exclusive. Cheers, David.
Re: CUPS - how to match autodetected printers to physical ones
On Sunday, 10 April 2022 09:54:34 EDT Brian wrote: > On Sun 10 Apr 2022 at 09:19:43 -0400, gene heskett wrote: > > On Sunday, 10 April 2022 08:40:29 EDT Brian wrote: > > > /usr/lib/cups/backend/snmp > > > > The only machine I have here that has that file installed, an rpi4, > > does not expose the printers address, only: > > pi@rpi4:~ $ sudo /usr/lib/cups/backend/snmp > > network lpd://BRN30055C8A2DC8/BINARY_P1 "Brother MFC-J6920DW" > > "Brother > > MFC-J6920DW" "MFG:Brother;CMD:HBP,BRPJL,URF;MDL:MFC- > > J6920DW;CLS:PRINTER;CID:Brother IJ > > Type3;URF:SRGB24,W8,CP1,IS1-13,MT1-8-11,OB9,PQ4-5,RS200-300,OFU0,V1.2 > > ,DM4;" "coyote.coyote.den" > > > > The only location identifier is the resolved "coyote.coyote.den" > > which is this machine. > > > > None of the buster boxes have it, so they all report file not found. > > BUT they were all installed from a buster respin by the linuxcnc > > folks. But geany the editor, can drive that printer from any > > locatiom my cat5 cable reaches. > > > > And I just checked because there is a 2nd printer, another brother > > HL2320 B duplex capable laser, on this machine, and although the > > above command only shows one printer, I can feed both printers from > > geany running on any machine, all 6 of the profiles I have defined > > are available for geany to use as an output device. I suspect the > > laser doesn't do snmp, its a $120 printer. Probably some brother > > version of plc5 since its running on brothers own drivers. > > Thank you, Gene. Your investigations are vey useful and point to my > forgetfulness. > Your forgetfullness Brian? I'm 87, so it is std proceedure for me to either repeat the experiment or spend a couple weeks sorting thru the sometimmes decades old stuff in my mental attic, and FWIW I also claim any references to oldtimers too. Surely you aren't that ancient. ;-) > The snmp backend is not installed in the location I gave but has > to be moved there. Do either > > mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp > > or > > dpkg-reconfigure cups > > -- > Brian. > > . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Weird printing issue...
On sab, 2022-04-09 at 04:28 -0400, Bijan Soleymani wrote: > On 2022-04-09 03:52, nimrod wrote: > > Thanks for your advice. Unfortunately I couldn't find any setting > > about > > Postscript, PCL or such in CUPS, HPLIP and the usual Gnome > > utilities to > > manage printers. > > > > The only spot where I see something like what you say is from > > Libreoffice printer's details, File / Printer settings / Properties > > / > > Device / Printer language type. The choice is currently "Automatic: > > PDF", but I can choose also 3 level of Postscript or "Postscript: > > level > > from driver". > > So there are two stages here. One the app (libre office) converts the > document to postscript or PDF. And two cups converts the PDF or > postscript to some format your printer understands. It is possible > that > either of these steps fails. > > This is why I recommended trying print to file (which default to pdf) > and seeing if that pdf file prints properly if opened and printed via > chrome. That way you can tell whether it is stage one or stage two > above > which has an issue. Also I think there must be a cups command line > command to print pdf and ps files that you could try, if it works in > chrome, to see if chrome does another level of processing that fixes > things. > > Bijan > Hi, I tried on my usual laptop a very simple test: I have two version of my printer, so I printed the "ugly" file on both, and only one shows the black stripes. Unfortunately, nor CUPS, nor Gnome printers app shows any option dealing with PCL, but I found a reference to PCL in the PPD file of the "good" one. Strangely enough, the "bad" printer was installed by HP Toolbox provided by the hplip package. I need to install a printer with that package in order to use the scan function, which is extremely important for me and is almost impossibile to use with the "good" printer. Having several printers just to manage all the features of the hardware printer is not very elegant, but as far as it works I could simply rename the "bad" printer "scanner" and the "good" one "printer", just to avoid confusion because now they have very long names which differ just for the last characters. Thank you again for your advice.
Re: updatedb.mlocate
On Sunday, 10 April 2022 10:04:53 EDT Greg Wooledge wrote: > On Sun, Apr 10, 2022 at 11:33:53AM +0200, Linux-Fan wrote: > > Greg Wooledge writes: > > > unicorn:~$ less /lib/systemd/system/mlocate.timer > > > [Unit] > > > Description=Updates mlocate database every day > > > > > > [Timer] > > > OnCalendar=daily > > > AccuracySec=24h > > > Persistent=true > > > > > > [Install] > > > WantedBy=timers.target > > > > > > ... it doesn't even say when it runs? What silliness is this? > > I was mistaken: it *does* say when it runs, but only if you've read at > least two different man pages. > > systemd.timer(5) says that OnCalendar= specifies a "calendar event > expression", and refers to systemd.time(7) to explain what that means. > > systemd.time(7) says that a "calendar event" defines one or more points > in time, and then gives some examples. By reading these examples, one > may infer that this thing specifies when the timer will trigger. > > It also explains that the keyword "daily" doesn't just mean "once a > day". It actually says: > > daily → *-*-* 00:00:00 > > In other words, "daily" explicitly means "once a day at local > midnight", assuming you can infer that "*-*-*" means "once a day". > > So, apparently it's the Debian developers who decided to make a bunch > of jobs all run at the same time (local midnight), either by making a > bad choice, or by being lazy. > > > # systemctl list-timers > > NEXT LEFT LAST > > PASSEDUNIT ACTIVATES Mon 2022-04-11 > > 00:00:00 CEST 12h left Sun 2022-04-10 00:00:01 CEST 11h ago > > mlocate.timermlocate.service > > > > It shows that at least on my system, it is going to run on 00:00 > > local time. > Yeah, but... it doesn't say *why* or how to change it. See above. > > > I can imagine that the idea behind not specifying the actual time in > > the individual unit allows you to configure the actual time of > > invocation somehwere else. This way if you have a lot of machines > > all online you can avoid having bursts of activity in the entire > > network/datacenter just as the clock turns to 00:00. > > Indeed, the Debian developers have passed that burden on to the local > system administrator. Worse, they didn't give any guidance or even a > cargo-cultable example for how to override it. Users are expected to > figure it out themselves. > > > Specifically in the case of `cron`, I think it is an improvement that > > user- specific timers are now kept in the user's home directory > > (~/.config/systemd/user directory) rather than a system directory > > (/var/spool/cron/crontabs). > > I am extremely skeptical of how useful it is to specify a systemd timer > at the --user level. They'll only run when the systemd --user service > manager is running, which is only when the user is logged in. > > What kind of jobs would you schedule in a timer, that you would want > to run *only* when you are logged in? I can't really think of any. > Most scheduled jobs would be things I would want to trigger regardless > of whether I'm logged in (cleaning up logs and temp files, retrieving > email from a remote mail server). I guess *some* things could be > deferred until login, like randomizing an email .signature file, but > those would be the exceptions. > > Now, let's see if I can figure out how to override the time at which > mlocate runs its update. I'll apply some previous systemd knowledge > that I happen to possess already, which is that in order to override > the getty@.service configuration, one must create a directory named > /etc/systemd/system/getty@.service.d and put *.conf files in it. > > So, extrapolating from that, let's try creating... > > unicorn:~$ sudo mkdir -p /etc/systemd/system/mlocate.timer.d > [sudo] password for greg: > unicorn:~$ sudo vi /etc/systemd/system/mlocate.timer.d/time.conf > unicorn:~$ cat /etc/systemd/system/mlocate.timer.d/time.conf > [Timer] > OnCalendar= > OnCalendar=04:20 > > I created a three-line override file which clears out the previous > OnCalendar= event(s), and then sets up a new event that runs the thing > at 04:20 each day, instead of midnight each day. > > unicorn:~$ sudo systemctl daemon-reload > unicorn:~$ systemctl list-timers | grep mlocate > Mon 2022-04-11 04:20:00 EDT 18h leftSun 2022-04-10 09:58:20 EDT 16s > ago mlocate.timermlocate.service > > Slight oops -- after I updated the daemon, the new time for the timer > had already expired, so it ran immediately. That's definitely not how > cron works (changing the time on a cron job doesn't cause an immediate > job execution). I wonder how one would go about changing the time on > a systemd timer *without* triggering an immediate execution in the > middle of the work day. > > . anacron? Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please
Re: CUPS - how to match autodetected printers to physical ones
On Sun 10 Apr 2022 at 21:29:30 +0200, to...@tuxteam.de wrote: > On Sun, Apr 10, 2022 at 08:19:52PM +0100, Brian wrote: > > [...] > > > > forbidden of trying to do network scans, but the sysadmin wants to > > > know. I can't blame him (I'm on speaking terms with him ;-) > > > > Not forbidden? > > > > I know a corporate network or two which would get you disconnected > > if you do that : > > > > Disconnected? That doesn't sound permissive. > > In my book, forbidden would mean *you* get disconnected from the > institution. Your machine disconnected from the network and having > to do "pretty please" to the admin... I'd say "fair enough". Wouldn't > be *my* policy, but I can live with that. I wouldn't say "fair enough", but the dictatorial and irrational decisions of sysadmins might oblige me to live with that. Just as I live with the agents of survellance capitalism. > > > > I was once reprimamaned by Amazon for nmapping my own network. That's > > > > what I call real devotion to stamping out network discovery. > > > > > > Now now. No reprimands. The firewall notices and disables that one port, > > > That's all. > > > > I was controlled by an inaminte agency? Is that any better than being > > controlled by an agent of survellance capitalism? Either way, my actions > > are monitored. My communications are intercepted and censorship applied. > > Could be worse, believe me. At a lower protocol level [1] it's even part > of the protocol, i.e. mandatory :) OK, I know when I am beaten into the ground. :) -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Sun, Apr 10, 2022 at 08:19:52PM +0100, Brian wrote: [...] > > forbidden of trying to do network scans, but the sysadmin wants to > > know. I can't blame him (I'm on speaking terms with him ;-) > > Not forbidden? > > I know a corporate network or two which would get you disconnected > if you do that : > > Disconnected? That doesn't sound permissive. In my book, forbidden would mean *you* get disconnected from the institution. Your machine disconnected from the network and having to do "pretty please" to the admin... I'd say "fair enough". Wouldn't be *my* policy, but I can live with that. > > > I was once reprimamaned by Amazon for nmapping my own network. That's > > > what I call real devotion to stamping out network discovery. > > > > Now now. No reprimands. The firewall notices and disables that one port, > > That's all. > > I was controlled by an inaminte agency? Is that any better than being > controlled by an agent of survellance capitalism? Either way, my actions > are monitored. My communications are intercepted and censorship applied. Could be worse, believe me. At a lower protocol level [1] it's even part of the protocol, i.e. mandatory :) Cheers [1] https://en.wikipedia.org/wiki/Ethernet#Jabber -- t signature.asc Description: PGP signature
Re: CUPS - how to match autodetected printers to physical ones
On Sun 10 Apr 2022 at 20:39:15 +0200, to...@tuxteam.de wrote: > On Sun, Apr 10, 2022 at 06:47:36PM +0100, Brian wrote: > > On Sun 10 Apr 2022 at 15:40:28 +0200, to...@tuxteam.de wrote: > > > > > On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote: > > > > > > [...] > > > > > > > Many printers provide an snmp (Simple Network Management Protocol) > > > > service on port 9100. Check with > > > > > > > > nmap 10.76.172.100 > > > > > > I know a corporate network or two which would get you disconnected > > > if you do that :) > > > > > > Then you've got to go to the firewall admin and beg for being reconnected. > > > So if you try it, first make sure you are on speaking terms with the > > > network/firewall admins (a good idea, regardless...) > > > > Strange world we live in! One looks at a shop window and the heavy mob > > appear to harass you. Survellance capitalism in action? Or the sysadmin > > is so unsure of the network security in place that it requires drastic > > and immediate action to prevent a peep at services being offered? :) > > No. The sysadmin has seen folks running around with Kali Linux USB > sticks and has decided to play safe rather than sorry. Folks are not "safe rather than sorry"? We see the result of that strategy in Europe today. The sysadmin has overreacted, presumably because he has little faith in the security of the network he has devised. How would he react if he saw folks running around with with Windows USB sticks? :) > forbidden of trying to do network scans, but the sysadmin wants to > know. I can't blame him (I'm on speaking terms with him ;-) Not forbidden? I know a corporate network or two which would get you disconnected if you do that : Disconnected? That doesn't sound permissive. > > I was once reprimamaned by Amazon for nmapping my own network. That's > > what I call real devotion to stamping out network discovery. > > Now now. No reprimands. The firewall notices and disables that one port, > That's all. I was controlled by an inaminte agency? Is that any better than being controlled by an agent of survellance capitalism? Either way, my actions are monitored. My communications are intercepted and censorship applied. -- Brian. -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On 2022-04-10 at 14:25, Brian wrote: > On Sun 10 Apr 2022 at 08:52:09 -0400, The Wanderer wrote: > >> On 2022-04-10 at 08:38, Brian wrote: > > [...] > >>> The CUPS web interface is not designed to show the IP address but >>> to display the URI. >> >> This, I think, is exactly the detail that's being complained of. If >> CUPS knows the IP address, it should be possible to get CUPS to >> reveal that IP address. >> >> If on the other hand CUPS *doesn't* know the IP address, but only >> the hostname et cetera (because that's part of the URI, and CUPS >> only knows/stores the URI), then that might be reasonable. > > CUPS uses the standard networking APIs (getaddrinfo, for example) > for resolving DNS names to get IP addresses, just like every other > network service on Linux. CUPS rolling its own DNS resolver would > cause problems on systems with working resolvers. Why reinvent the > wheel? I'm not suggesting that CUPS roll its own DNS resolver. I'm just suggesting (or, rather, was just assuming) that after having first learned the IP address during the discovery process, which probably involves using an external DNS resolver (whether automated or in the form of sysadmin entering IP address manually), it would cache that IP address and make use of that cached value rather than repeating the - presumably relatively expensive - discovery lookup every time. This was based, at least in part, on the expectation that there would/will not be DNS lookup for the printer's IP address from its hostname, since I have rarely if ever seen a network where such lookup was functioning (never mind one where the printer's hostname was reliably meaningful or discoverable by any other means than connecting to it by IP address and asking). If that expectation was out of sync with reality, then so be it. > Basically, CUPS leaves it to libnss-mdns. Why should it have any > record of an IP address when it can easily ask libnss-mdns? We do the > same with avahi-browse. Because the lookup will be more expensive than connecting to the IP address, which is unlikely to have changed - and if it *has* changed, you've got little or no way of telling whether or not the printer you're connecting to now is the same one as used to be at the previously-known address. >> (My previous comments were based on the assumption that all >> communication with the printer would be done based on IP address, >> rather than on symbolic name and on connect-time resolution. That >> may in turn be based on my experience in the Windows world, where >> printer hostnames and DNS lookup are in my experience wildly >> unreliable and as a consequence are very rarely used; I reflexively >> expect that the parts of a system which communicate with a printer >> will always know it primarily, if not exclusively, by its IP >> address.) > > Of corse the IP address is needed, but not by the user. The user is > better served by having the queue name matching the printer. That depends on what information the user is going to be able to access about the printer. I have frequently seen printers which have a front-panel display that will show the IP address. I have never, that I recall, seen a printer which has a display that will readily show the queue name, or the hostname, or any other seemingly-relevant information about the printer's identity. (Besides the model, which tends to also be displayed as part of the printer's physical shell.) In the case which started this thread, the user had the printer's IP address (via a label which, I imagine, stood in the stead of such a display; we also sometimes apply such labels in case the printer loses its IP address in a power outage and has to have it re-applied), but did not have the queue name. Whether or not the queue name matches the printer is irrelevant when the queue name is not what the user can get from the printer itself. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: updatedb.mlocate
On Sun 10 Apr 2022 at 12:04:05 (-0400), Greg Wooledge wrote: > On Sun, Apr 10, 2022 at 03:49:02PM +0100, Darac Marjal wrote: > > Systemd already supports this. > > > > * AccuracySec= Specify the accuracy the timer shall elapse with. [...] > > Within this time window, the expiry time shall be placed at a host-specific, > > randomized, but stable position. > > > > * RandomizedDelaySec = Delay the timer by a randomly selected, evenly > > distributed amount of time between 0 and the specified time value. > > > > > > So, "OnCalendar=daily" together with "AccuracySec=24h" *seems* to imply > > "once per day, but at a random time during the day". > > If that's the case, it's not working correctly on my system. mlocate > has OnCalendar=daily and AccuracySec=24h, but before I changed it, it > was scheduled to run *exactly* at midnight. > > /lib/systemd/system/man-db.timer has OnCalendar=daily and AccuracySec=12h > and it's scheduled to run *exactly* at midnight. > > /lib/systemd/system/logrotate.timer has OnCalendar=daily and AccuracySec=1h > and it's scheduled to run *exactly* at midnight. I think that's because there are two more options whose default values are zero and false, so they're not specified in our .timer files. AIUI, setting RandomizedDelaySec=24hr would get you the effect it seems you expected above, but I seriously think you wouldn't want. AccuracySec appears to allow several expiring timers to be grouped into one instant if that instant is within the range allowed, hence minimising wakeups; RandomizedDelaySec does the opposite, spreading them out, hence minimising spikes in system load. If you set RandomizedDelaySec=24hr, then mlocate/whatever would run at random times of day each day. Setting FixedRandomDelay=true would make mlocate/whatever run at the same time each day, and that time would be whatever happened to be chosen on the first day. (I think buster/241 lacks the fixed one.) I'm quite happy for mlocate to run (almost) first thing in the morning when I turn on the computer (assuming I didn't run it beyond midnight last night). Cheers, David.
Re: CUPS - how to match autodetected printers to physical ones
On Sun, Apr 10, 2022 at 06:47:36PM +0100, Brian wrote: > On Sun 10 Apr 2022 at 15:40:28 +0200, to...@tuxteam.de wrote: > > > On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote: > > > > [...] > > > > > Many printers provide an snmp (Simple Network Management Protocol) > > > service on port 9100. Check with > > > > > > nmap 10.76.172.100 > > > > I know a corporate network or two which would get you disconnected > > if you do that :) > > > > Then you've got to go to the firewall admin and beg for being reconnected. > > So if you try it, first make sure you are on speaking terms with the > > network/firewall admins (a good idea, regardless...) > > Strange world we live in! One looks at a shop window and the heavy mob > appear to harass you. Survellance capitalism in action? Or the sysadmin > is so unsure of the network security in place that it requires drastic > and immediate action to prevent a peep at services being offered? :) No. The sysadmin has seen folks running around with Kali Linux USB sticks and has decided to play safe rather than sorry. Folks are not forbidden of trying to do network scans, but the sysadmin wants to know. I can't blame him (I'm on speaking terms with him ;-) > I was once reprimamaned by Amazon for nmapping my own network. That's > what I call real devotion to stamping out network discovery. Now now. No reprimands. The firewall notices and disables that one port, That's all. Cheers -- t signature.asc Description: PGP signature
Re: CUPS - how to match autodetected printers to physical ones
On Sun 10 Apr 2022 at 08:52:09 -0400, The Wanderer wrote: > On 2022-04-10 at 08:38, Brian wrote: [...] > > The CUPS web interface is not designed to show the IP address but to > > display the URI. > > This, I think, is exactly the detail that's being complained of. If CUPS > knows the IP address, it should be possible to get CUPS to reveal that > IP address. > > If on the other hand CUPS *doesn't* know the IP address, but only the > hostname et cetera (because that's part of the URI, and CUPS only > knows/stores the URI), then that might be reasonable. CUPS uses the standard networking APIs (getaddrinfo, for example) for resolving DNS names to get IP addresses, just like every other network service on Linux. CUPS rolling its own DNS resolver would cause problems on systems with working resolvers. Why reinvent the wheel? Basically, CUPS leaves it to libnss-mdns. Why should it have any record of an IP address when it can easily ask libnss-mdns? We do the same with avahi-browse. > (My previous comments were based on the assumption that all > communication with the printer would be done based on IP address, rather > than on symbolic name and on connect-time resolution. That may in turn > be based on my experience in the Windows world, where printer hostnames > and DNS lookup are in my experience wildly unreliable and as a > consequence are very rarely used; I reflexively expect that the parts of > a system which communicate with a printer will always know it primarily, > if not exclusively, by its IP address.) Of corse the IP address is needed, but not by the user. The user is better served by having the queue name matching the printer. -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Sun 10 Apr 2022 at 15:40:28 +0200, to...@tuxteam.de wrote: > On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote: > > [...] > > > Many printers provide an snmp (Simple Network Management Protocol) > > service on port 9100. Check with > > > > nmap 10.76.172.100 > > I know a corporate network or two which would get you disconnected > if you do that :) > > Then you've got to go to the firewall admin and beg for being reconnected. > So if you try it, first make sure you are on speaking terms with the > network/firewall admins (a good idea, regardless...) Strange world we live in! One looks at a shop window and the heavy mob appear to harass you. Survellance capitalism in action? Or the sysadmin is so unsure of the network security in place that it requires drastic and immediate action to prevent a peep at services being offered? :) I was once reprimamaned by Amazon for nmapping my own network. That's what I call real devotion to stamping out network discovery. -- Brian.
Re: updatedb.mlocate
On Sun, Apr 10, 2022 at 03:49:02PM +0100, Darac Marjal wrote: > Systemd already supports this. > > * AccuracySec= Specify the accuracy the timer shall elapse with. [...] > Within this time window, the expiry time shall be placed at a host-specific, > randomized, but stable position. > > * RandomizedDelaySec = Delay the timer by a randomly selected, evenly > distributed amount of time between 0 and the specified time value. > > > So, "OnCalendar=daily" together with "AccuracySec=24h" *seems* to imply > "once per day, but at a random time during the day". If that's the case, it's not working correctly on my system. mlocate has OnCalendar=daily and AccuracySec=24h, but before I changed it, it was scheduled to run *exactly* at midnight. /lib/systemd/system/man-db.timer has OnCalendar=daily and AccuracySec=12h and it's scheduled to run *exactly* at midnight. /lib/systemd/system/logrotate.timer has OnCalendar=daily and AccuracySec=1h and it's scheduled to run *exactly* at midnight. unicorn:~$ systemctl list-timers | grep 00:00 Mon 2022-04-11 00:00:00 EDT 13h leftSun 2022-04-10 00:00:00 EDT 10h ago logrotate.timer logrotate.service Mon 2022-04-11 00:00:00 EDT 13h leftSun 2022-04-10 00:00:00 EDT 10h ago man-db.timer man-db.service Further evidence in the form of timestamps on files in /var/log: -rw-r- 1 rootadm 1559363 Apr 9 23:59 auth.log.1 -rw-r- 1 rootadm 568405 Apr 9 23:59 mail.log.1 -rw-r- 1 rootadm 568405 Apr 9 23:59 mail.info.1 -rw-r- 1 rootadm 0 Apr 10 00:00 mail.warn -rw-r- 1 rootadm 0 Apr 10 00:00 debug -rw-r- 1 rootadm 740788 Apr 10 00:00 syslog.1 -rw-r- 1 rootadm 46660 Apr 10 00:00 daemon.log.1 Previously I had noted that the mlocate db timestamp was at midnight as well.
Re: Libreoffice: printing "dirties" the file being printed
On 2022-04-10, rhkra...@gmail.com wrote: > On Friday, April 08, 2022 08:17:14 AM gene heskett wrote: >> I think Ben Franklin said it first, First, we get rid of all the lawyers. > > Billy (Shakespeare) said it before Ben. But I would not be surprised to find > that someone said it much earlier than that. > > I once looked into the origin of ~"I wrote you a long letter because I didn't > have time to write a short letter" -- I found sources that attributed it to > Cicero, but I wouldn't be surprised to find out it was talked about around > the > cavemen's (and women's) campfires. > > Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte. Les provinciales (1656), XVI de Blaise Pascal https://en.wikipedia.org/wiki/Lettres_provinciales "I would have written a shorter letter, but I did not have the time." (Letter XVI)
Re: updatedb.mlocate
On Saturday 09 April 2022 05:11:39 pm Greg Wooledge wrote: > On Sat, Apr 09, 2022 at 04:59:04PM -0400, gene heskett wrote: > > On Saturday, 9 April 2022 16:35:26 EDT Greg Wooledge wrote: > > > grep daily /etc/crontab > > > > Matches mine too Greg, so I expect thats default, but why is Roy's going > > off at about midnight? > > We'd have to see what his /etc/crontab contains, Trying to paste it in here, but after opening it, copying it, paste seems to have no effect? > and what his system clock is set to. UTC. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
Re: updatedb.mlocate
On 10/04/2022 15:29, Greg Wooledge wrote: On Sun, Apr 10, 2022 at 06:03:13AM -0400, gene heskett wrote: Thats fine, as long as the systemd stuff is disabled by finding an entry in the presently logged in users ~/.config, but I do not consider that as a user item. thats (updatedb) sysadmin stuff, and much of this hoohah could be prevented by setting the trigger time at install time with a random time between 1 and 4 AM when most users are inactive anyway. How many lines of bash code would it take to do that, 3? 4? IDK but it could be done... The mlocate package includes a /lib/systemd/system/mlocate.timer file. It's static content. If the package maintainer wanted to randomize the contents, they would need to write code in the mlocate.postinst script to change the static file -- which is a really BAD idea. A slightly better idea: don't include the static file at all, but include code in the mlocate.postinst which generates a randomized mlocate.timer file. The mlocate.postinst script is not a bash script. It's an sh script. So, the "obvious" way to do it in bash (a here document with $((RANDOM%...)) expressions in it) won't work. They would need to call out to some external process (perhaps awk) to generate some random numbers, store those in variables, and then use the variables in the here document. They would also need to arrange for the randomized mlocate.timer file to be cleaned up when the package is removed, so that's even more code to write. Kind of a pain in the ass. Even if randomizing the times is more trouble than it's worth, I wonder how much support might exist for simply specifying a different static time for each package that currently runs at midnight. E.g. have mlocate run at 00:05, have man-db run at 00:10, have logrotate run at 00:15, and so on. I don't know how many different timers all run at midnight -- just the ones that *I* happen to have. There are probably lots more. Systemd already supports this. * AccuracySec= Specify the accuracy the timer shall elapse with. [...] Within this time window, the expiry time shall be placed at a host-specific, randomized, but stable position. * RandomizedDelaySec = Delay the timer by a randomly selected, evenly distributed amount of time between 0 and the specified time value. So, "OnCalendar=daily" together with "AccuracySec=24h" *seems* to imply "once per day, but at a random time during the day". OpenPGP_signature Description: OpenPGP digital signature
Re: CUPS - how to match autodetected printers to physical ones
On Sun 10 Apr 2022 at 09:31:59 -0400, gene heskett wrote: > On Sunday, 10 April 2022 08:54:07 EDT Brian wrote: > > On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote: > > > > [...] > > > > > This, FWIW, has nothing to do with cups and printer sharing, cups > > > does > > > its own advertising. All printers here are attached to this machine, > > > marked as shareable and I can put stuff on their output trays from > > > any > > > machine including the rpi4 on my local network. > > > > Indeed, CUPS does do its own advertising of print queue and uses > > mDNS/DNS-SD. That is its *only* technique it has available for > > sharing the queues. > > > > mDNS/DNS-SD requires avahi-daemon to be active. Without it there > > isn't any sharing and advertising. > > > > So, I do not understand "...has nothing to do with...". > > > The avahi-daemon has either been removed by rm. or by chmod -x on all > machines here, yet cups shared printers (plural) can use those shared > printers just as if they were plugged into that machine. So IMO removing > or disabling avahi-daemon has nothing to do with cups sharing. > You are saying it won't work, but it does here. What else is there except > cups. You can print from an rpi4 to a printer attached to another machine on the network. There are only two ways this can happen: * The rpi4 knows about the print server via mDNS/DNS-SD. * There is a manual queue set up on the rpi4. Only you can decide which it is. -- Brian.
Re: updatedb.mlocate
On Saturday 09 April 2022 01:22:08 pm Charles Curley wrote: > On Sat, 9 Apr 2022 11:04:18 -0500 > "Roy J. Tellason, Sr." wrote: > > > How do I find out where this is invoked, so I can get rid of it? > > You may not want to get rid of it. That's the process that updates the > database for the locate utility, which is very useful. Yeah, it's useful if you change things on the system. I don't do that all that often, though. > I was about to add, think instead about adding a nice value to its cron > entry. There is some stuff about that in the script in question, but rather than working my way through all that I just made that script not executable. > However it look like mlocate is now handled by systemd, and I > don't know enough to advise you on how to do that. I don't understand the reason for so many things getting pushed in that direction. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
Re: CUPS - how to match autodetected printers to physical ones
On Sun 10 Apr 2022 at 10:05:09 -0400, The Wanderer wrote: > On 2022-04-10 at 09:54, Brian wrote: > > > The snmp backend is not installed in the location I gave but has > > to be moved there. Do either > > > > mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp > > > > or > > > > dpkg-reconfigure cups > > I've never taken specific action in either of these directions, but on > my machine, this file exists in both of those locations. I suspect that > they're actually hardlinked together. > > I imagine that this is probably the result of my choosing a particular > option when configuring CUPS in the first place, but I have no > recollection of what option that might have been, nor even specifically > of having been given any CUPS-related prompts when installing this system. > > The point of which is: it's possible that the default for this might > actually now be to have this enabled. TBH, I am not in the mood for deciphering postinst files for cups and cups-daemon. If the snmp backend file is not where it is on ny stable and unstable machines, it is easy enough to adjust. OTOH, reports of the technique I suggested are more than welcome. -- Brian.
Re: updatedb.mlocate
On Saturday 09 April 2022 12:39:45 pm Roberto C. Sánchez wrote: > On Sat, Apr 09, 2022 at 11:04:18AM -0500, Roy J. Tellason, Sr. wrote: > > So around midnight I am seeing a burst of activity, which sometimes > > interferes with whatever else I happen to be doing at the time. Looking at > > the process list, I see the above-referenced come and go. I didn't want > > this, and it's not apparent to me how to deal with it. > > > > How do I find out where this is invoked, so I can get rid of it? > > > You can uninstall the mlocate package. Or, you can edit > /etc/cron.daily/mlocate and comment out the cron entry. That would > leave the package installed, but you would need to keep the database > updated manually. Okay, I found the script by that name and made it not executable. We'll see if that works. What I'd really like to know is, why is this happening now when it wasn't happening before? It probably changed after my last round of updating things... -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
Re: updatedb.mlocate
On Sun, Apr 10, 2022 at 06:03:13AM -0400, gene heskett wrote: > Thats fine, as long as the systemd stuff is disabled by finding an entry > in the presently logged in users ~/.config, but I do not consider that as > a user item. thats (updatedb) sysadmin stuff, and much of this hoohah > could be prevented by setting the trigger time at install time with a > random time between 1 and 4 AM when most users are inactive anyway. How > many lines of bash code would it take to do that, 3? 4? IDK but it could > be done... The mlocate package includes a /lib/systemd/system/mlocate.timer file. It's static content. If the package maintainer wanted to randomize the contents, they would need to write code in the mlocate.postinst script to change the static file -- which is a really BAD idea. A slightly better idea: don't include the static file at all, but include code in the mlocate.postinst which generates a randomized mlocate.timer file. The mlocate.postinst script is not a bash script. It's an sh script. So, the "obvious" way to do it in bash (a here document with $((RANDOM%...)) expressions in it) won't work. They would need to call out to some external process (perhaps awk) to generate some random numbers, store those in variables, and then use the variables in the here document. They would also need to arrange for the randomized mlocate.timer file to be cleaned up when the package is removed, so that's even more code to write. Kind of a pain in the ass. Even if randomizing the times is more trouble than it's worth, I wonder how much support might exist for simply specifying a different static time for each package that currently runs at midnight. E.g. have mlocate run at 00:05, have man-db run at 00:10, have logrotate run at 00:15, and so on. I don't know how many different timers all run at midnight -- just the ones that *I* happen to have. There are probably lots more.
Re: CUPS - how to match autodetected printers to physical ones
On 2022-04-10 at 09:54, Brian wrote: > The snmp backend is not installed in the location I gave but has > to be moved there. Do either > > mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp > > or > > dpkg-reconfigure cups I've never taken specific action in either of these directions, but on my machine, this file exists in both of those locations. I suspect that they're actually hardlinked together. I imagine that this is probably the result of my choosing a particular option when configuring CUPS in the first place, but I have no recollection of what option that might have been, nor even specifically of having been given any CUPS-related prompts when installing this system. The point of which is: it's possible that the default for this might actually now be to have this enabled. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: updatedb.mlocate
On Sun, Apr 10, 2022 at 11:33:53AM +0200, Linux-Fan wrote: > Greg Wooledge writes: > > unicorn:~$ less /lib/systemd/system/mlocate.timer > > [Unit] > > Description=Updates mlocate database every day > > > > [Timer] > > OnCalendar=daily > > AccuracySec=24h > > Persistent=true > > > > [Install] > > WantedBy=timers.target > > > > ... it doesn't even say when it runs? What silliness is this? I was mistaken: it *does* say when it runs, but only if you've read at least two different man pages. systemd.timer(5) says that OnCalendar= specifies a "calendar event expression", and refers to systemd.time(7) to explain what that means. systemd.time(7) says that a "calendar event" defines one or more points in time, and then gives some examples. By reading these examples, one may infer that this thing specifies when the timer will trigger. It also explains that the keyword "daily" doesn't just mean "once a day". It actually says: daily → *-*-* 00:00:00 In other words, "daily" explicitly means "once a day at local midnight", assuming you can infer that "*-*-*" means "once a day". So, apparently it's the Debian developers who decided to make a bunch of jobs all run at the same time (local midnight), either by making a bad choice, or by being lazy. > # systemctl list-timers > NEXT LEFT LAST > PASSEDUNIT ACTIVATES > Mon 2022-04-11 00:00:00 CEST 12h left Sun 2022-04-10 00:00:01 CEST 11h > ago mlocate.timermlocate.service > > It shows that at least on my system, it is going to run on 00:00 local time. Yeah, but... it doesn't say *why* or how to change it. See above. > I can imagine that the idea behind not specifying the actual time in the > individual unit allows you to configure the actual time of invocation > somehwere else. This way if you have a lot of machines all online you can > avoid having bursts of activity in the entire network/datacenter just as the > clock turns to 00:00. Indeed, the Debian developers have passed that burden on to the local system administrator. Worse, they didn't give any guidance or even a cargo-cultable example for how to override it. Users are expected to figure it out themselves. > Specifically in the case of `cron`, I think it is an improvement that user- > specific timers are now kept in the user's home directory > (~/.config/systemd/user directory) rather than a system directory > (/var/spool/cron/crontabs). I am extremely skeptical of how useful it is to specify a systemd timer at the --user level. They'll only run when the systemd --user service manager is running, which is only when the user is logged in. What kind of jobs would you schedule in a timer, that you would want to run *only* when you are logged in? I can't really think of any. Most scheduled jobs would be things I would want to trigger regardless of whether I'm logged in (cleaning up logs and temp files, retrieving email from a remote mail server). I guess *some* things could be deferred until login, like randomizing an email .signature file, but those would be the exceptions. Now, let's see if I can figure out how to override the time at which mlocate runs its update. I'll apply some previous systemd knowledge that I happen to possess already, which is that in order to override the getty@.service configuration, one must create a directory named /etc/systemd/system/getty@.service.d and put *.conf files in it. So, extrapolating from that, let's try creating... unicorn:~$ sudo mkdir -p /etc/systemd/system/mlocate.timer.d [sudo] password for greg: unicorn:~$ sudo vi /etc/systemd/system/mlocate.timer.d/time.conf unicorn:~$ cat /etc/systemd/system/mlocate.timer.d/time.conf [Timer] OnCalendar= OnCalendar=04:20 I created a three-line override file which clears out the previous OnCalendar= event(s), and then sets up a new event that runs the thing at 04:20 each day, instead of midnight each day. unicorn:~$ sudo systemctl daemon-reload unicorn:~$ systemctl list-timers | grep mlocate Mon 2022-04-11 04:20:00 EDT 18h leftSun 2022-04-10 09:58:20 EDT 16s ago mlocate.timermlocate.service Slight oops -- after I updated the daemon, the new time for the timer had already expired, so it ran immediately. That's definitely not how cron works (changing the time on a cron job doesn't cause an immediate job execution). I wonder how one would go about changing the time on a systemd timer *without* triggering an immediate execution in the middle of the work day.
Re: CUPS - how to match autodetected printers to physical ones
On Sun 10 Apr 2022 at 09:19:43 -0400, gene heskett wrote: > On Sunday, 10 April 2022 08:40:29 EDT Brian wrote: > > /usr/lib/cups/backend/snmp > The only machine I have here that has that file installed, an rpi4, does > not expose the printers address, only: > pi@rpi4:~ $ sudo /usr/lib/cups/backend/snmp > network lpd://BRN30055C8A2DC8/BINARY_P1 "Brother MFC-J6920DW" "Brother > MFC-J6920DW" "MFG:Brother;CMD:HBP,BRPJL,URF;MDL:MFC- > J6920DW;CLS:PRINTER;CID:Brother IJ > Type3;URF:SRGB24,W8,CP1,IS1-13,MT1-8-11,OB9,PQ4-5,RS200-300,OFU0,V1.2,DM4;" > "coyote.coyote.den" > > The only location identifier is the resolved "coyote.coyote.den" which is > this machine. > > None of the buster boxes have it, so they all report file not found. BUT > they were all installed from a buster respin by the linuxcnc folks. But > geany the editor, can drive that printer from any locatiom my cat5 cable > reaches. > > And I just checked because there is a 2nd printer, another brother HL2320 > B duplex capable laser, on this machine, and although the above command > only shows one printer, I can feed both printers from geany running on > any machine, all 6 of the profiles I have defined are available for geany > to use as an output device. I suspect the laser doesn't do snmp, its a > $120 printer. Probably some brother version of plc5 since its running on > brothers own drivers. Thank you, Gene. Your investigations are vey useful and point to my forgetfulness. The snmp backend is not installed in the location I gave but has to be moved there. Do either mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp or dpkg-reconfigure cups -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote: [...] > Many printers provide an snmp (Simple Network Management Protocol) > service on port 9100. Check with > > nmap 10.76.172.100 I know a corporate network or two which would get you disconnected if you do that :) Then you've got to go to the firewall admin and beg for being reconnected. So if you try it, first make sure you are on speaking terms with the network/firewall admins (a good idea, regardless...) So careful. Cheers -- t signature.asc Description: PGP signature
Re: CUPS - how to match autodetected printers to physical ones
On Sun 10 Apr 2022 at 08:10:17 -0400, gene heskett wrote: > On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote: > > On 2022-04-10 at 07:08, gene heskett wrote: > > > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote: > > >> I just don't install it. > > > > > > And how do you accomplish that? Its automatically installed AFAIK. > > > And once installed, apt will not remove it without destroying the > > > install. rm or chmod -x seems to be the only way, and nothing > > > complains. > > > > What package(s), by exact name, are you referring to? That is, which > > package(s) is it that produce this effect when you try to remove them? > > > > On my computer, I have several libavahi* packages, which could not be > > removed without removing large swaths of packages - but I also have > > avahi-daemon and avahi-utils, which can be removed with few if any side > > effects (as far as triggering removal of other packages goes). > > > > And since the subject at hand in this branch of the thread appears to > > be avahi-daemon, surely removing that single package should be enough > > to prevent avahi from doing anything undesirable? > > Which IMO It should be but apt will not remove avahi-daemon on any of my > buster machines or on bullseye without taking "large swaths" of stuff > with it. > > Tomas just found, and I have now edited /etc/default/avahi-daemon to > officialy shut it off, ditto for brytty, leaving a killed orca spewing 20 I do not think AVAHI_DAEMON_DETECT_LOCAL does what you think it does. It applies to detection of *unicast* dns servers. -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Sunday, 10 April 2022 08:54:07 EDT Brian wrote: > On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote: > > [...] > > > This, FWIW, has nothing to do with cups and printer sharing, cups > > does > > its own advertising. All printers here are attached to this machine, > > marked as shareable and I can put stuff on their output trays from > > any > > machine including the rpi4 on my local network. > > Indeed, CUPS does do its own advertising of print queue and uses > mDNS/DNS-SD. That is its *only* technique it has available for > sharing the queues. > > mDNS/DNS-SD requires avahi-daemon to be active. Without it there > isn't any sharing and advertising. > > So, I do not understand "...has nothing to do with...". > The avahi-daemon has either been removed by rm. or by chmod -x on all machines here, yet cups shared printers (plural) can use those shared printers just as if they were plugged into that machine. So IMO removing or disabling avahi-daemon has nothing to do with cups sharing. You are saying it won't work, but it does here. What else is there except cups. > -- > Brian. > > . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: CUPS - how to match autodetected printers to physical ones
On Sunday, 10 April 2022 08:40:29 EDT Brian wrote: > /usr/lib/cups/backend/snmp The only machine I have here that has that file installed, an rpi4, does not expose the printers address, only: pi@rpi4:~ $ sudo /usr/lib/cups/backend/snmp network lpd://BRN30055C8A2DC8/BINARY_P1 "Brother MFC-J6920DW" "Brother MFC-J6920DW" "MFG:Brother;CMD:HBP,BRPJL,URF;MDL:MFC- J6920DW;CLS:PRINTER;CID:Brother IJ Type3;URF:SRGB24,W8,CP1,IS1-13,MT1-8-11,OB9,PQ4-5,RS200-300,OFU0,V1.2,DM4;" "coyote.coyote.den" The only location identifier is the resolved "coyote.coyote.den" which is this machine. None of the buster boxes have it, so they all report file not found. BUT they were all installed from a buster respin by the linuxcnc folks. But geany the editor, can drive that printer from any locatiom my cat5 cable reaches. And I just checked because there is a 2nd printer, another brother HL2320 B duplex capable laser, on this machine, and although the above command only shows one printer, I can feed both printers from geany running on any machine, all 6 of the profiles I have defined are available for geany to use as an output device. I suspect the laser doesn't do snmp, its a $120 printer. Probably some brother version of plc5 since its running on brothers own drivers. Cheers Brian, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: CUPS - how to match autodetected printers to physical ones
On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote: [...] > This, FWIW, has nothing to do with cups and printer sharing, cups does > its own advertising. All printers here are attached to this machine, > marked as shareable and I can put stuff on their output trays from any > machine including the rpi4 on my local network. Indeed, CUPS does do its own advertising of print queue and uses mDNS/DNS-SD. That is its *only* technique it has available for sharing the queues. mDNS/DNS-SD requires avahi-daemon to be active. Without it there isn't any sharing and advertising. So, I do not understand "...has nothing to do with...". -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On 2022-04-10 at 08:38, Brian wrote: > On Sat 09 Apr 2022 at 20:21:12 -0400, The Wanderer wrote: > >> On 2022-04-09 at 07:56, Brian wrote: >>> It is straightforward, I don't know about obvious to all users. >>> >>> avahi-browse -rt _ipp._tcp >> >> Does that get the information from CUPS? >> >> It looks to me as if it gets the information from the network, via >> what are probably the same discovery methods as CUPS used to get >> it. >> >> That's not the same as getting the information *from CUPS*, which >> must logically already have that information. >> >> Having a way to get the information at all (and we already seem to >> have at least two of those, from this thread, one of them being the >> one you just cited) is not the same as having a way to get the >> information *from where it must logically already be*, and the >> apparent lack of the latter is what's bothering me about the >> described behavior. > > CUPS delegates resolution of hosts and services to mDNS; I am happy > to follow in its footsteps. > > CUPS may very well know the IP address but it is not of direct > interest to the user, That will very definitely vary depending on the user. > who is better served by being informed of the URI. This may be true in some cases, but is very definitely not true in all. > For various reasons, IP addresses can change, of course; printers > being moved round the network, for example. This is based on a set of assumptions which may apply in some cases, but very definitely do not apply in all cases. I don't want to dive deep into them, however, since this has already gone on long enough. >>> CUPS uses mDNS/DNS-sd for discovery. The user does the same: >>> >>> avahi-browse -rt _ipp._tcp >> >> This seems to be confirming the hypothesis above: that this is not >> getting CUPS to reveal the information, but performing the same >> discovery method that CUPS used to get the information. > > Yes. > >> If, for example, the printer was online when CUPS discovered it and >> is therefore listed in the CUPS interface, but is offline now >> (perhaps someone accidentally unplugged the network cable from the >> printer?), I would be mildly surprised if this would still result >> in showing the IP address of the printer. CUPS, however, must still >> have that address, from its past discovery. > > The CUPS web interface is not designed to show the IP address but to > display the URI. This, I think, is exactly the detail that's being complained of. If CUPS knows the IP address, it should be possible to get CUPS to reveal that IP address. If on the other hand CUPS *doesn't* know the IP address, but only the hostname et cetera (because that's part of the URI, and CUPS only knows/stores the URI), then that might be reasonable. (My previous comments were based on the assumption that all communication with the printer would be done based on IP address, rather than on symbolic name and on connect-time resolution. That may in turn be based on my experience in the Windows world, where printer hostnames and DNS lookup are in my experience wildly unreliable and as a consequence are very rarely used; I reflexively expect that the parts of a system which communicate with a printer will always know it primarily, if not exclusively, by its IP address.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: CUPS - how to match autodetected printers to physical ones
On Sunday, 10 April 2022 08:02:32 EDT to...@tuxteam.de wrote: > On Sun, Apr 10, 2022 at 07:46:37AM -0400, gene heskett wrote: > > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote: > > > AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon. > > > > Checking all my machines, all but one was set to 1, fixed the others > > and redid the initramfs as it said in 2 of the 5, in that file. > > > > Thank you for that Tomas, now its done by the official way including > > on this bullseye box. I also took advantage and disabled brltty by > > similar means. That leaves orca dirtying the logs with about 20 > > lines every 15 seconds. And that leads to a reboot about weekly by > > filling up the /var partition. Orca however, does not appear in > > /etc/default. Where is it started so I can officially stop it? That > > would extend my uptimes I expect. > > As it came out in That Other Thread :) I think this is some rogue USB > serial adapter fooling udev that it is a Braille input. Find that, fix > your udev rules (or dump the adapter). > > Background: whenever you stick an USB into your device tree, it tells > udev "hi, I'm a new mouse". Or a "memory stick". Or "a camera". But > of course, this comes roundabout: it tells the maker and the maker's > device model as a pair of numbers. > > There's a lot of things which may go wrong there: from an inexact > device database to some cheap manufacturer skimping on the USB > consortium membership and squatting on wrong identifiers. > Or even ducks the issue by all-balling the identifiers. Those most often encountered looking like a usb key gismo and soon find the trash can. But since fdti is the only maker of seriel adaptors that actually works, proliic tried but failed miserably, I see no reason not to reach thru the adaptor and see if its actually a braille device, rather that blindly assuming it is when there are many other often legacy devices that need the adaptor. The cm11a to control your lights and appliances interface is likely at least 30 years old, and the protocol was known in the mid 80's. I wrote software in the late 80's to do that from a trs-80 Color Computer running os9-level one, then jim hines and I moved it to amigados using ARexx and sold registered copies of it for a few years. Called it ezhome based on something else we wrote called ezcron since amigados had no cron utility. We gave that away. > Once we have more details perhaps someone can lead you through the > process. But test-booting the thing while some USB devices are > unplugged until you find the culprit is something only you can do. True Tomas, but my attempts to install w/o it have all failed as it will not reboot without it so a reboot turns into a new install, 20 some times now, which I'm sick of doing, hence my questions that keep harping on getting rid of it gracefully AFTER the install. Basicly, whats done should have an undo method and I will keep asking until the magic phrase comes out of someones fingertips. In the meantime I am reminded of it by the need to reboot weekly in order to have a usable machine. > Hint: binary search may be helpful (unstick first half of the USBs > and so on). > > Cheers > -- > t Take care and stay well, Tomas. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: CUPS - how to match autodetected printers to physical ones
On Fri 08 Apr 2022 at 13:22:26 -0400, Greg Wooledge wrote: > On Fri, Apr 08, 2022 at 06:03:47PM +0100, Tixy wrote: > > On Fri, 2022-04-08 at 17:59 +0100, Tixy wrote: > > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote: > > > > Unfortunately, I was not able to find ANY way to determine the IP > > > > addresses of the autodetected printers that were presented to me. > > > > > > If I go to http://localhost:631/printers/ > > > > I should say I got to that URL from the CUPs interface at > > http://localhost:631/ then clicking the 'Admininitation' tab at the top > > followed by the 'Manage Printers' button on the page that showed. > > Here is what I have on that page: > > = > Showing 7 of 7 printers. > > Queue NameDescription LocationMake and Model Status > Canon_LBP351dn_f9_7a_4a_ CNLBP712C CNLBP712C, > driverless, cups-filters 1.28.7Idle > Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_ > CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7Idle > Cups_PDF_oc3261540276 Cups_PDF_oc3261540276 Local Raw Printer > Paused > HP_LaserJet_4100_Series_0001E6A68D3D_ HP_LaserJet_4100_Series_0001E6A68D3D_ > HP LaserJet 4100 Series , driverless, cups-filters 1.28.7 Idle > hp_LaserJet_4250_621E13_ hp_LaserJet_4250_621E13_hp > LaserJet 4250, driverless, cups-filters 1.28.7 Idle > HP_LaserJet_P3010_Series_0FCDD7_ HP_LaserJet_P3010_Series_0FCDD7_ > HP LaserJet P3010 Series, driverless, cups-filters 1.28.7 Idle > PostScript_oc3261540276 PostScript_oc3261540276 Local Raw > Printer Paused > = [...] > Looking at the stuff that I pasted here, how am I supposed to know whether > this corresponds to the physical printer with IP address 10.76.172.100? Another idea that may or may not grip you. It's not guaranteed to work ( whereas the avahi-browse command should be reliable) but it could be worth a try. Many printers provide an snmp (Simple Network Management Protocol) service on port 9100. Check with nmap 10.76.172.100 It would be unusual for the service not to be offered because it dates from the dawn of time and is very simple to implement. There isn't any reliance on avahi-daemon (just TCP/IP) and it works with non-ipp printers. Execute /usr/lib/cups/backend/snmp The output should include an IP address and a printer make and model. Thanks to The Wanderer for sparking this thought. -- Brian.
Re: CUPS - how to match autodetected printers to physical ones
On Sat 09 Apr 2022 at 20:21:12 -0400, The Wanderer wrote: > On 2022-04-09 at 07:56, Brian wrote: > > > On Fri 08 Apr 2022 at 19:45:41 -0400, The Wanderer wrote: > > > >> (This is probably both overly long and overly repetitive, among > >> possibly other undesirable things, but I'm running short on time.) > > > > So I hope you do not mind if I do not reply to every point you make. > > I don't strongly mind that, no. A few of them were probably rephrasings > of the same thing in different ways. > > >> On 2022-04-08 at 18:44, Brian wrote: > > > > >> What Greg was asking about, as far as I can tell, is a way to get > >> CUPS to tell him that network-location information - so that he, as > >> someone external to the printing system, could then apply that > >> information to his additional knowledge about the physical location > >> of the printer with a specific IP address. > >> > >> I'm not sure we (in this thread) have yet found a way to do that > >> directly; we've found what appear to be two different ways to find > >> the IP address of the printer with the name that CUPS is reporting, > >> but it looks to me as if both of them are getting that information > >> via an external method (probably similar to how CUPS found the > >> printer in the first place), rather than getting that information > >> from CUPS itself. > >> > >> The IP-address (etc.?) information must exist within CUPS, since > >> CUPS is able to actually send jobs to the printer; why isn't it > >> straightforward and obvious how to get that information *from* > >> within CUPS *to* someplace visible? > > > > It is straightforward, I don't know about obvious to all users. > > > > avahi-browse -rt _ipp._tcp > > Does that get the information from CUPS? > > It looks to me as if it gets the information from the network, via what > are probably the same discovery methods as CUPS used to get it. > > That's not the same as getting the information *from CUPS*, which must > logically already have that information. > > Having a way to get the information at all (and we already seem to have > at least two of those, from this thread, one of them being the one you > just cited) is not the same as having a way to get the information *from > where it must logically already be*, and the apparent lack of the latter > is what's bothering me about the described behavior. CUPS delegates resolution of hosts and services to mDNS; I am happy to follow in its footsteps. CUPS may very well know the IP address but it is not of direct interest to the user, who is better served by being informed of the URI. For various reasons, IP addresses can change, of course; printers being moved round the network, for example. > >>> CUPS knows how to route the job. The physical location of the > >>> printer is not involved in the routeing. > >> > >> True, and I don't understand why you thought it was involved (as > >> relates to CUPS) at all. > >> > >> The IP address, however, *is* involved in the routing - and > >> therefore CUPS must know it. (Or some proxy piece of information, > >> as above.) > >> > >> The original question as I understand it was how to get CUPS to > >> reveal that piece of information which it must know. > > > > CUPS uses mDNS/DNS-sd for discovery. The user does the same: > > > > avahi-browse -rt _ipp._tcp > > This seems to be confirming the hypothesis above: that this is not > getting CUPS to reveal the information, but performing the same > discovery method that CUPS used to get the information. Yes. > If, for example, the printer was online when CUPS discovered it and is > therefore listed in the CUPS interface, but is offline now (perhaps > someone accidentally unplugged the network cable from the printer?), I > would be mildly surprised if this would still result in showing the IP > address of the printer. CUPS, however, must still have that address, > from its past discovery. The CUPS web interface is not designed to show the IP address but to display the URI. However, the URI might give an IP address if it is a socket://... or lpd://... URI. An offlin machine would continue to list information for manually set up queues. If CUPS retains an address of a previous connection, I am not aware of a way to extract it > What I understood Greg as asking about is how to get CUPS to > *tell* you what the IP address it knows about for a given > printer object is. That doesn't seem to be an unreasonable > thing to want to know, or to expect CUPS to be able to provide; > I'd want the same thing, in anything remotely like his place. > > > > avahi-browse -rt _ipp._tcp > > As above. > > >>> Finding the IP address is easy: > >>> > >>> ippfind -T 5 ipp://envy4500.local:631/ipp/print ping -c 3 > >>> envy4500.local > >> > >> That only works if IPP is in use, which isn't guaranteed. > > > > Communication between CUPS servers is guaranteed to be by IPP. > > Between CUPS and modern printers is only via IPP. > >
Re: Libreoffice: printing "dirties" the file being printed
On Friday, April 08, 2022 08:17:14 AM gene heskett wrote: > I think Ben Franklin said it first, First, we get rid of all the lawyers. Billy (Shakespeare) said it before Ben. But I would not be surprised to find that someone said it much earlier than that. I once looked into the origin of ~"I wrote you a long letter because I didn't have time to write a short letter" -- I found sources that attributed it to Cicero, but I wouldn't be surprised to find out it was talked about around the cavemen's (and women's) campfires.
Re: CUPS - how to match autodetected printers to physical ones
On 2022-04-10 at 08:10, gene heskett wrote: > On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote: > >> On 2022-04-10 at 07:08, gene heskett wrote: >>> And how do you accomplish that? Its automatically installed >>> AFAIK. And once installed, apt will not remove it without >>> destroying the install. rm or chmod -x seems to be the only way, >>> and nothing complains. >> >> What package(s), by exact name, are you referring to? That is, >> which package(s) is it that produce this effect when you try to >> remove them? >> >> On my computer, I have several libavahi* packages, which could not >> be removed without removing large swaths of packages - but I also >> have avahi-daemon and avahi-utils, which can be removed with few if >> any side effects (as far as triggering removal of other packages >> goes). >> >> And since the subject at hand in this branch of the thread appears >> to be avahi-daemon, surely removing that single package should be >> enough to prevent avahi from doing anything undesirable? > > Which IMO It should be but apt will not remove avahi-daemon on any of > my buster machines or on bullseye without taking "large swaths" of > stuff with it. Based on what Tomas said in his reply, I'm guessing that that's because you've got GNOME or some similar fancy DE installed, and that DE's packages declare a dependency on avahi-daemon directly. I don't use such a DE (preferring, instead, a WM so niche that it's not even packaged and in the repositories anymore), so it's no surprise that I wouldn't see that effect - and also, if you do, no surprise that you would. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: CUPS - how to match autodetected printers to physical ones
On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote: > On 2022-04-10 at 07:08, gene heskett wrote: > > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote: > >> I just don't install it. > > > > And how do you accomplish that? Its automatically installed AFAIK. > > And once installed, apt will not remove it without destroying the > > install. rm or chmod -x seems to be the only way, and nothing > > complains. > > What package(s), by exact name, are you referring to? That is, which > package(s) is it that produce this effect when you try to remove them? > > On my computer, I have several libavahi* packages, which could not be > removed without removing large swaths of packages - but I also have > avahi-daemon and avahi-utils, which can be removed with few if any side > effects (as far as triggering removal of other packages goes). > > And since the subject at hand in this branch of the thread appears to > be avahi-daemon, surely removing that single package should be enough > to prevent avahi from doing anything undesirable? Which IMO It should be but apt will not remove avahi-daemon on any of my buster machines or on bullseye without taking "large swaths" of stuff with it. Tomas just found, and I have now edited /etc/default/avahi-daemon to officialy shut it off, ditto for brytty, leaving a killed orca spewing 20 lines of errors into the log every 15 seconds until it takes so long to append the log that the machine is unusable for over 30 seconds at a time and must be rebooted about weekly to recover, all because the installer thinks ANY usb to seriel adaptor plugged in is driving a braille interface. Theres a lot of other reasons to have such on a system, and in fact I have 2 of them, one serviceing my ups, and one servicing a cm-11a interface for heyu. I dare say that is a more common a use than a braille interface. Or a speech synth that isn't understandable, which category orca certainly is in. So I'll repeat my request as to how do I turn off orca AND get rid of the every 15 second error spew to the log because its been killed? > -- >The Wanderer > > The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man. -- George Bernard > Shaw Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: CUPS - how to match autodetected printers to physical ones
On Sun, Apr 10, 2022 at 07:46:37AM -0400, gene heskett wrote: > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote: > > > AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon. > > Checking all my machines, all but one was set to 1, fixed the others and > redid the initramfs as it said in 2 of the 5, in that file. > > Thank you for that Tomas, now its done by the official way including on > this bullseye box. I also took advantage and disabled brltty by similar > means. That leaves orca dirtying the logs with about 20 lines every 15 > seconds. And that leads to a reboot about weekly by filling up the /var > partition. Orca however, does not appear in /etc/default. Where is it > started so I can officially stop it? That would extend my uptimes I > expect. As it came out in That Other Thread :) I think this is some rogue USB serial adapter fooling udev that it is a Braille input. Find that, fix your udev rules (or dump the adapter). Background: whenever you stick an USB into your device tree, it tells udev "hi, I'm a new mouse". Or a "memory stick". Or "a camera". But of course, this comes roundabout: it tells the maker and the maker's device model as a pair of numbers. There's a lot of things which may go wrong there: from an inexact device database to some cheap manufacturer skimping on the USB consortium membership and squatting on wrong identifiers. Once we have more details perhaps someone can lead you through the process. But test-booting the thing while some USB devices are unplugged until you find the culprit is something only you can do. Hint: binary search may be helpful (unstick first half of the USBs and so on). Cheers -- t signature.asc Description: PGP signature
Re: CUPS - how to match autodetected printers to physical ones
On Sun, Apr 10, 2022 at 07:17:42AM -0400, The Wanderer wrote: > On 2022-04-10 at 07:08, gene heskett wrote: > > > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote: > > >> I just don't install it. > > > > And how do you accomplish that? Its automatically installed AFAIK. > > And once installed, apt will not remove it without destroying the > > install. rm or chmod -x seems to be the only way, and nothing > > complains. > > What package(s), by exact name, are you referring to? That is, which > package(s) is it that produce this effect when you try to remove them? > > On my computer, I have several libavahi* packages, which could not be > removed without removing large swaths of packages - but I also have > avahi-daemon and avahi-utils, which can be removed with few if any side > effects (as far as triggering removal of other packages goes). The lib* things are different. That's the price we pay for a binary distribution. I have quite a few libsystemd around. The alternative would be to compile everything. I'm not that uncompromising :) > And since the subject at hand in this branch of the thread appears to be > avahi-daemon, surely removing that single package should be enough to > prevent avahi from doing anything undesirable? Yes, that would be the one implementing zeroconf. As I see, gnome is listed as avahi-daemon dependency. So that could be what happens to Gene. "I'm going to remove Gnome now" does sound scary :) Cheers -- t signature.asc Description: PGP signature
Re: CUPS - how to match autodetected printers to physical ones
On Sun, Apr 10, 2022 at 07:08:36AM -0400, gene heskett wrote: > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote: [...] > > be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some > > /etc/default/avahi-daemon. > > Then whyintarnation does it not say that in what serves as a man page? Sometimes systems become... complex. I guess (just guess) that avahi-daemon has some command-line parameters to manage that. Those would be in the man page. The /etc/default hierarchy is rather a Debian-specific things to provide start-up options to system-wide services (and also to the boot process). Those are picked up from there. > > No need to rm it. But if it satisfies you, you're your box's boss :) > > Exactly. > > > I just don't install it. > > And how do you accomplish that? Its automatically installed AFAIK. And > once installed, apt will not remove it without destroying the install. rm > or chmod -x seems to be the only way, and nothing complains. There are things depending on avahi. I don't need them. I've to jump through some hoops to keep systemd or dbus to be installed (but it's manageable), but avahi hasn't ever tried, yet :-) Current desktop environments won't like that, mind you. But I don't particularly like them, either. Cheers -- t signature.asc Description: PGP signature
Re: CUPS - how to match autodetected printers to physical ones
On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote: > AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon. Checking all my machines, all but one was set to 1, fixed the others and redid the initramfs as it said in 2 of the 5, in that file. Thank you for that Tomas, now its done by the official way including on this bullseye box. I also took advantage and disabled brltty by similar means. That leaves orca dirtying the logs with about 20 lines every 15 seconds. And that leads to a reboot about weekly by filling up the /var partition. Orca however, does not appear in /etc/default. Where is it started so I can officially stop it? That would extend my uptimes I expect. Thanks Tomas. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: CUPS - how to match autodetected printers to physical ones
On 2022-04-10 at 07:08, gene heskett wrote: > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote: >> I just don't install it. > > And how do you accomplish that? Its automatically installed AFAIK. > And once installed, apt will not remove it without destroying the > install. rm or chmod -x seems to be the only way, and nothing > complains. What package(s), by exact name, are you referring to? That is, which package(s) is it that produce this effect when you try to remove them? On my computer, I have several libavahi* packages, which could not be removed without removing large swaths of packages - but I also have avahi-daemon and avahi-utils, which can be removed with few if any side effects (as far as triggering removal of other packages goes). And since the subject at hand in this branch of the thread appears to be avahi-daemon, surely removing that single package should be enough to prevent avahi from doing anything undesirable? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: CUPS - how to match autodetected printers to physical ones
On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote: > On Sun, Apr 10, 2022 at 05:46:35AM -0400, gene heskett wrote: > > [...] > > > Then why, after a decade and change of bitching about it because it > > insists on putting a 169.254.xx,yy address in ones routing table that > > only removing avahi fixes, has it not been fixed? > > This would be an IPv4 link-local [0] address. Correctly naming > things is always the first step to taking control over them: > casting spells and that ;-) > > Setting that up is zeroconf's [1] job, which, AFAIK, is actually > done by the avahi daemon. I can't check it myself, because my > box has no avahi. > > But if you know how the thing's called, you can throw your spells > at a search engine (hopefully not the one of survellance capitalism, > but I disgress ;-) and find things like [2]. It tells you how to > convince different systems to not do that; under Debian, this would > be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some > /etc/default/avahi-daemon. Then whyintarnation does it not say that in what serves as a man page? > No need to rm it. But if it satisfies you, you're your box's boss :) Exactly. > I just don't install it. And how do you accomplish that? Its automatically installed AFAIK. And once installed, apt will not remove it without destroying the install. rm or chmod -x seems to be the only way, and nothing complains. > Cheers > -- > t Take care and stay well Tomas. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: CUPS - how to match autodetected printers to physical ones
On Sun, Apr 10, 2022 at 05:46:35AM -0400, gene heskett wrote: [...] > Then why, after a decade and change of bitching about it because it > insists on putting a 169.254.xx,yy address in ones routing table that > only removing avahi fixes, has it not been fixed? This would be an IPv4 link-local [0] address. Correctly naming things is always the first step to taking control over them: casting spells and that ;-) Setting that up is zeroconf's [1] job, which, AFAIK, is actually done by the avahi daemon. I can't check it myself, because my box has no avahi. But if you know how the thing's called, you can throw your spells at a search engine (hopefully not the one of survellance capitalism, but I disgress ;-) and find things like [2]. It tells you how to convince different systems to not do that; under Debian, this would be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon. No need to rm it. But if it satisfies you, you're your box's boss :) I just don't install it. Cheers -- t signature.asc Description: PGP signature
Re: updatedb.mlocate
On Sunday, 10 April 2022 05:33:53 EDT Linux-Fan wrote: > Greg Wooledge writes: > > On Sat, Apr 09, 2022 at 09:26:58PM -0600, Charles Curley wrote: > > > Two of my machines have their database files dated at midnight or > > > one > > > minute after. > > > > > > Possibly because updatedb is run by a systemd timer, not cron. > > [...] > > > # skip in favour of systemd timer > > if [ -d /run/systemd/system ]; then > > > > exit 0 > > > > fi > > [...] > > > > Wow. That's incredibly annoying! > > It provides a mechanism that adjusts to the init system at runtime. > Maybe there are better ways to do it, but it seems to work OK? > > > unicorn:~$ less /lib/systemd/system/mlocate.timer > > [Unit] > > Description=Updates mlocate database every day > > > > [Timer] > > OnCalendar=daily > > AccuracySec=24h > > Persistent=true > > > > [Install] > > WantedBy=timers.target > > > > ... it doesn't even say when it runs? What silliness is this? > > Try > > # systemctl list-timers > NEXT LEFT LAST > PASSEDUNIT ACTIVATES Mon 2022-04-11 > 00:00:00 CEST 12h left Sun 2022-04-10 00:00:01 CEST 11h ago > mlocate.timermlocate.service > > It shows that at least on my system, it is going to run on 00:00 local > time. > > I can imagine that the idea behind not specifying the actual time in > the individual unit allows you to configure the actual time of > invocation somehwere else. This way if you have a lot of machines all > online you can avoid having bursts of activity in the entire > network/datacenter just as the clock turns to 00:00. > > > Oh well. It clearly isn't bothering me (I'm usually in bed before > > midnight, though not always), so I never had to look into it. I'm > > sure someone felt it was a "good idea" to move things from perfectly > > normal and well-understood crontab files into this new systemd timer > > crap that nobody understands, and that I should respect their > > wisdom, but I don't see the advantages at this time. > > I think systemd tries to provide an alternative for all the `...tab` > files that used to be the standard (/etc/inittab, /etc/crontab, > /etc/fstab come to mind). IMHO the notable advantage over the > traditional method is that on systemd-systems one can query all the > status information with a single command: `systemctl status > `. Similarly, the lifecycle of start/stop/enable/disable > can all be handled by the single command `systemctl > start/stop/enable/disable `. All stdout/stderr outputs > available via `journalctl -u `. In theory this could > eliminate the need to know about or remember the individual services' > log file names. > > Specifically in the case of `cron`, I think it is an improvement that > user- specific timers are now kept in the user's home directory > (~/.config/systemd/user directory) rather than a system directory > (/var/spool/cron/crontabs). Thats fine, as long as the systemd stuff is disabled by finding an entry in the presently logged in users ~/.config, but I do not consider that as a user item. thats (updatedb) sysadmin stuff, and much of this hoohah could be prevented by setting the trigger time at install time with a random time between 1 and 4 AM when most users are inactive anyway. How many lines of bash code would it take to do that, 3? 4? IDK but it could be done... > IMHO systemd's interface is not the best design-wise and in terms of > its strange defaults, formats and names (paged output by default is > one of the things I disable all the time, INI-derivatives are really > not my favorite configuration syntax, binary logfiles, semantics of > disable/mask can be confusing...). IMHO it does provide a lot of > useful features that were missing previously, though. > > YMMV > Linux-Fan > > öö Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: CUPS - how to match autodetected printers to physical ones
On Sunday, 10 April 2022 02:33:21 EDT to...@tuxteam.de wrote: > On Sat, Apr 09, 2022 at 08:21:12PM -0400, The Wanderer wrote: > > [...] > > > I honestly don't know the subject very well myself, but I'd > > definitely > > like to know it better than I do. > > > > One aspect of Windows printer sharing is that it makes it possible to > > connect a printer not directly to the network, but locally to a > > particular computer, and then configure that computer to advertise > > the > > printer over the network. Other computers can then send jobs to that > > printer via that computer, which is de-facto a print server for that > > printer. > > > > Do you know whether CUPS is capable of interacting with printers > > which > > are shared in that way? (This is a tangent to the topic of the > > thread, > > but it fits this local context and it's a thing I'd be interested > > in.) > > If that local printer is known to CUPS and the local sysadmin has > marked it as shareable (however you do that in CUPS), that would, > as I have understood it, be Avahi's job, which is a service > (advertisement and) discovery protocol. Then why, after a decade and change of bitching about it because it insists on putting a 169.254.xx,yy address in ones routing table that only removing avahi fixes, has it not been fixed? You can spec the correct address other places such as in /etc/networking/interfaces.d/ anyfilename, or in the last two paragraphs of /etc/dhcpcd.conf, but if avahi is executable, it will override your settings and kill your networking setup dead in the water. And what I mean is that removing it is done behind apt's back by hunting it down and rm-ing it. apt will not remove it w/o destroying the rest of the system. For those of us using hosts files for networking on our little home networks of less that say 16 machines, avahi is the first thing we hunt down and rm after the installers reboot. Only then can we spec a 192.168.xx.yy address to our local gateway and make it stick. Of note is that NOTHING else in the system considers a missing avahi as a loggable event. ONLY apt thinks it is valuable enough to cause its dependencies to destroy the system if you try to remove it with apt as the package manager. Which suits me just fine as its been a headache, looking for a problem that does not exist since it came on the scene. Here, at the coyote.den domain, it does not exist in executable form. Except to pull my trigger when someone recommends that broken concept utility for anything. This, FWIW, has nothing to do with cups and printer sharing, cups does its own advertising. All printers here are attached to this machine, marked as shareable and I can put stuff on their output trays from any machine including the rpi4 on my local network. The missing avahi has nothing to do with that. The only disadvantage is the long walk to retrieve the printout, but I probably needed the exercise anyway. > Cheers > -- > t Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: updatedb.mlocate
Greg Wooledge writes: On Sat, Apr 09, 2022 at 09:26:58PM -0600, Charles Curley wrote: > Two of my machines have their database files dated at midnight or one > minute after. > > Possibly because updatedb is run by a systemd timer, not cron. [...] # skip in favour of systemd timer if [ -d /run/systemd/system ]; then exit 0 fi [...] Wow. That's incredibly annoying! It provides a mechanism that adjusts to the init system at runtime. Maybe there are better ways to do it, but it seems to work OK? unicorn:~$ less /lib/systemd/system/mlocate.timer [Unit] Description=Updates mlocate database every day [Timer] OnCalendar=daily AccuracySec=24h Persistent=true [Install] WantedBy=timers.target ... it doesn't even say when it runs? What silliness is this? Try # systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Mon 2022-04-11 00:00:00 CEST 12h left Sun 2022-04-10 00:00:01 CEST 11h ago mlocate.timermlocate.service It shows that at least on my system, it is going to run on 00:00 local time. I can imagine that the idea behind not specifying the actual time in the individual unit allows you to configure the actual time of invocation somehwere else. This way if you have a lot of machines all online you can avoid having bursts of activity in the entire network/datacenter just as the clock turns to 00:00. Oh well. It clearly isn't bothering me (I'm usually in bed before midnight, though not always), so I never had to look into it. I'm sure someone felt it was a "good idea" to move things from perfectly normal and well-understood crontab files into this new systemd timer crap that nobody understands, and that I should respect their wisdom, but I don't see the advantages at this time. I think systemd tries to provide an alternative for all the `...tab` files that used to be the standard (/etc/inittab, /etc/crontab, /etc/fstab come to mind). IMHO the notable advantage over the traditional method is that on systemd-systems one can query all the status information with a single command: `systemctl status `. Similarly, the lifecycle of start/stop/enable/disable can all be handled by the single command `systemctl start/stop/enable/disable `. All stdout/stderr outputs available via `journalctl -u `. In theory this could eliminate the need to know about or remember the individual services' log file names. Specifically in the case of `cron`, I think it is an improvement that user- specific timers are now kept in the user's home directory (~/.config/systemd/user directory) rather than a system directory (/var/spool/cron/crontabs). IMHO systemd's interface is not the best design-wise and in terms of its strange defaults, formats and names (paged output by default is one of the things I disable all the time, INI-derivatives are really not my favorite configuration syntax, binary logfiles, semantics of disable/mask can be confusing...). IMHO it does provide a lot of useful features that were missing previously, though. YMMV Linux-Fan öö pgpcH9a30fVSj.pgp Description: PGP signature
Re: Impressions partielles avec Brother-HL2150N
Le samedi 09 avril 2022 à 19:19 +0200, ajh-valmer a écrit : > On Saturday 09 April 2022 17:31:17 kaliderus wrote: > > Le sam. 9 avr. 2022 à 11:06 a écrit : > > > - tes pilotes d'impression sont fournis par Debian? ou par > > > Brother? > > > J'aurais tendance à dire que si ton imprimante est supportée par > > > défaut par Debian, installer des trucs Brother, > > > ne fera que compliquer les choses : > > Pourquoi ? > Aucune complication, c'est un test, retirer le driver cups-debian, > installer le driver Brother-HL2150N. > Si l'impression partielle disparait, c'est qu'il y a un bug dans le > cups-debian. > > J'obtiens un meilleur rendu avec le driver Epson proprio. > > ajh Valmer Ma précédente intervention n'est pas un jugement de valeurs affirmant que les utilisateurs Debian doivent suivre aveuglément et docilement une hypothétique doctrine Debian obligatoire :-) Simplement ce que je veux dire c'est: - évolutivité/pérennité: CUPS à l'avenir ne va plus fournir de nouveaux drivers et IPP fonctionne déjà. Donc si on a une imprimante compatible IPP (et la plupart le sont depuis un certain temps, même, je pense, les récentes qui ne sont pas réseau via une couche de compatibilité USB), le plus simple et fonctionnel est de fonctionner en IPP driverless. C'est comme ça que le constructeur de l'imprimante veut fonctionner pour faciliter la vie de ses utilisateurs, selon moi. - fiabilité: statistiquement, plus on utilise un environnement/contexte connu et populaire (au sens largement adopté), meilleure est la fiabilité, simplement parce que les retours d'utilisation, les rapports de bugs et les corrections de bugs sont plus nombreux. En ce sens utiliser du pur Debian est plus logique. ça ne signifie par exemple pas que tu ne peux pas utiliser Trinity plutôt que Gnome (le DE par défaut de Debian), mais tu vas vraisemblablement être confronté à des problèmes plus nombreux qui nécessiteront une plus grande capacité de ta part à résoudre les problèmes - dépendance à un fournisseur: a) si tu utilises une imprimante en driverless, tu dépends en gros de la communauté globale des constructeurs d'imprimantes mais aussi de PC, tablettes et smartphones. C'est une large population et elle a intérêt à ce que IPP fonctionne bien pour simplifier la vie de ses utilisateurs et ainsi gagner de l'argent b) si tu utilises des drivers CUPS empaquetés par Debian, tu dépends de CUPS à fournir ces drivers (et CUPS a renoncé à l'élaboration de nouveaux drivers pour les futures imprimantes, en gros) et tu dépends de Debian à les empaqueter. Ta dépendance est déjà selon moi plus grande qu'en a) c) si tu utilises des drivers Epson (pour une imprimante pure, je ne suis pas sûr qu'ils soient proprio (pour un combo scanner/printer, oui, je pense), mais un empaquetage de drivers CUPS et de trucs maison possiblement close ou open source. Le jour où Epson décide que ça n'est plus intéressant/rentable de maintenir ces drivers, tu te retrouves le bec dans l'eau. Pense aux drivers graphiques propriétaires Nvidia: un jour tu as des drivers graphiques Nvidia proprio, le lendemain, non, c'est fini. Encore une fois, je ne cherche pas à *dicter* le comportement d'autrui: tant que ça n'impacte pas les autres, chacun est libre de fonctionner comme il lui plaît. Par contre ça peut être important d'évaluer préalablement les avantages et inconvénients de chaque solution pour éviter des déconvenues ultérieures :-)
Re: Problemas con Mutt (era: Resolución de pantalla en las tty)
El 2022-04-09 a las 13:42 -0500, Aristobulo Pinzon Gmail escribió: > Gracias por tu interés. > Tenía mutt como aplicación de correo configurada en el navegador y en > aplicaciones predeterminadas. > Pero de pronto sucede que cuando deseo contestar algún mensaje, no abre el > Mutt para escribir la respuesta si no que envía un mensaje vacío al clicar en > la dirección. Y además no conserva el hilo de los mensajes ni se como > contestar incluyendo el mensaje enviado como Usted los hace… :-( > Debo tener algunos errores en el .muttrc. Por lo que dices, me da la sensación de que lo que falla es la integración de Mutt con el navegador. Pero vayamos por partes. Para responder a los mensajes de esta lista manteniendo el contenido del remitente, tienes que recibir los correos a través de Mutt o desde cualquier cliente de correo electrónico, como p. ej., el webmail de Gmail. Si pulsas en los enlaces de respuesta que hay en la página web del archivo de la lista¹ no te funcionará, ni con Mutt ni con ningún cliente de correo electrónico, ya que esos enlaces preformarteados sólo generan un nuevo correo con el asunto y el campo «in-reply-to:» para matener el hilado pero el nuevo correo que generas no mantiene el texto del cuerpo del mensaje al que respondes. Eso también me sucede a mí y tengo Thunderbird configurado como cliente de correo predeterminado. Quizá si explicas con más detalle cómo haces para enviar y recibir los correos de la lista te podamos concretar algo más. ¹https://lists.debian.org/debian-user-spanish/2022/04/msg00049.html Saludos, -- Camaleón
Re: CUPS - how to match autodetected printers to physical ones
On Sat, Apr 09, 2022 at 08:21:12PM -0400, The Wanderer wrote: [...] > I honestly don't know the subject very well myself, but I'd definitely > like to know it better than I do. > > One aspect of Windows printer sharing is that it makes it possible to > connect a printer not directly to the network, but locally to a > particular computer, and then configure that computer to advertise the > printer over the network. Other computers can then send jobs to that > printer via that computer, which is de-facto a print server for that > printer. > > Do you know whether CUPS is capable of interacting with printers which > are shared in that way? (This is a tangent to the topic of the thread, > but it fits this local context and it's a thing I'd be interested in.) If that local printer is known to CUPS and the local sysadmin has marked it as shareable (however you do that in CUPS), that would, as I have understood it, be Avahi's job, which is a service (advertisement and) discovery protocol. Cheers -- t signature.asc Description: PGP signature
Re: updatedb.mlocate
On Sat, Apr 09, 2022 at 11:59:07PM -0400, Greg Wooledge wrote: [...] > Oh well. It clearly isn't bothering me (I'm usually in bed before > midnight, though not always), so I never had to look into it. I'm sure > someone felt it was a "good idea" to move things from perfectly normal > and well-understood crontab files into this new systemd timer crap that > nobody understands, and that I should respect their wisdom, but I don't > see the advantages at this time. FWIW, Debian is (still) perfectly viable with SysV, something I thank daily Debian developers for. Cheers -- t signature.asc Description: PGP signature
Re: Problem downloading "Installation Guide for 64-bit PC (amd64)"
On 04/09/2022 01:17 PM, davidson wrote: On Sat, 9 Apr 2022 Richard Owlett wrote: On 04/08/2022 01:18 AM, Tixy wrote: On Thu, 2022-04-07 at 09:40 -0500, Richard Owlett wrote: I need a *HTML* copy of "Installation Guide for 64-bit PC (amd64)" for *OFFLINE* use. The HTML links on [https://www.debian.org/releases/stable/installmanual] lead *ONLY* to Page 1. You can download all the pages using a recursive wget: wget -r -k -np https://www.debian.org/releases/stable/amd64/ That's 774kB of files when I tried it (I know internet data usage is important to you). I've never used wget. I just did an initial reading of its quite detailed man page. Is there a recommended introduction to wget. I'm not thinking of a tutorial so much as a "What wget can do for you" intro. $ info --index-string=Examples wget Same material on public web pages: https://www.gnu.org/software/wget/manual/html_node/Examples.html Thank you. That's the type of page I'm looking for. The HTML format is more practical than straight text as I can preset a suitable font size.
