After losing a fair bit of hair due to quality and reliability issues
with our home laser multifunctional (
Brother
DCP1600-series,
which we bought after checking it was meant to work on Linux And it
does, but with a very buggy, proprietary driver Besides being the
printer itself of quite low quality), we decided it was time to survey
the market again, and get a color inkjet printer. I was not very much
an enthusiast of the idea, until I found all of the major
manufacturers now offer refillable ink tanks instead of the darn
expensive cartridges of past decades. Lets see how it goes!
Of course, with over 20 years of training, I did my homework. I was
about to buy an Epson printer, but decided for an
HP Ink Tank 410
Wireless
printer. The day it arrived, not wanting to fuss around too much to
get to see the results, I connected it to my computer using the USB
cable. Everything ran smoothly and happily! No driver hunting needed,
print quality is superb I hope, years from now, we stay with this
impression.
Next day, I tried to print over WiFi. Of course, it requires
configuration. And, of course, configuration
strongly wants you to
do it from a Windows or MacOS machine which I don t have. OK, fall
back to Android For which an app download is required (and does not
thrill me, but what can I say. Oh and the app needs
location
services to even run. Why Maybe because it interacts with the
wireless network in
WiFi Direct, non-authenticated way?)
Anyway, things seem to work. But they don t My computers can
identify and connect with the printer from CUPS, but nothing ever
comes out.
Printer paused, they say. Entering the printer s web
interface is somewhat ambiguous Following the old HP practices, I
tried
http://192.168.1.75:9100/ (no point in hiding my internal IP),
and got a partial webpage sometimes (and nothing at all
othertimes). Seeing the printer got detected over
ipps://, my
immediate reaction was to try pointing the browser to port 631. Seems
to work! Got some odd messages But it seems I ll soon debug the
issue away. I am not a familiar meddler in the dark lands of
cups,
our faithful print server, but I had to remember my toolkit..
# cupsenable HP_Ink_Tank_Wireless_410_series_C37468_ --release
Sucess in enabling, but self-auto-disabled right away
lpstat -t
was not more generous, reporting only it was still paused.
Some hours later (mix in attending kids and whatnot), I finally
remember to try
cupsctl --debug-logging, and magically,
/var/log/cups/error_log turns from being quiet to being quite
chatty. And, of course, my first print job starts being processed:
D [10/May/2020:23:07:20 -0500] Report: jobs-active=1
(...)
D [10/May/2020:23:07:25 -0500] [Job 174] Start rendering...
(...)
D [10/May/2020:23:07:25 -0500] [Job 174] STATE: -connecting-to-device
(...)
Everything looks fine and dandy so far! But, hey, given nothing came
out of the printer keep reading one more second of logs (a couple
dozen lines)
D [10/May/2020:23:07:26 -0500] [Job 174] Connection is encrypted.
D [10/May/2020:23:07:26 -0500] [Job 174] Credentials are expired (Credentials have expired.)
D [10/May/2020:23:07:26 -0500] [Job 174] Printer credentials: HPC37468 / Thu, 01 Jan 1970 00:00:00 GMT / 28A59EF511A480A34798B6712DEEAE74
D [10/May/2020:23:07:26 -0500] [Job 174] No stored credentials.
D [10/May/2020:23:07:26 -0500] [Job 174] update_reasons(attr=0(), s=\"-cups-pki-invalid,cups-pki-changed,cups-pki-expired,cups-pki-unknown\")
D [10/May/2020:23:07:26 -0500] [Job 174] STATE: -cups-pki-expired
(...)
D [10/May/2020:23:08:00 -0500] [Job 174] envp[16]="CUPS_ENCRYPTION=IfRequested"
(...)
D [10/May/2020:23:08:00 -0500] [Job 174] envp[27]="PRINTER_STATE_REASONS=cups-pki-expired"
My first stabs were attempts to get CUPS not to care about expired
certificates, but it seems to have been hidden or removed from its
usual place. Anyway, I was already frustrated.
WTF Well, yes, turns out that from the Web interface, I paid some
attention to this the first time around, but let it pass (speaks
wonders about my security practices!):
So, the
self-signed certificate the printer issued at itself expired
116 years before even being issued. (is this maybe a Y2k38 bug?
Sounds like it!) Interesting thing, my CUPS log mentions the printer
credentials to expire at the beginning of the Unix Epoch
(
01 Jan 1970 00:00:00 GMT).
OK, lets clickety-click away on the Web interface Didn t take me
long to get to
Network Advanced settings Certificates:
However, clicking on
Configure leads me to the not very
reassuring
I don t remember what I did for the next couple of minutes. Kept
fuming Until I parsed again the output of
lpstat -t, and found
that:
# lpstat -t
(...)
device for HP_Ink_Tank_Wireless_410_series_C37468_: ipps://HPF43909C37468.local:443/ipp/print
(...)
Hmmmm CUPS is connecting using good ol port 443, as if it were a
Web thingy What if I do the same?
Click on New self-signed certificate , click on
Next, a couple of
reloads And a very nice color print came out of the printer, yay!
Now, it still baffles me (of course I checked!): The self-signed
certificate is now said to come from
Issuer : CN=HPC37468, L=Vancouver, ST=Washington, C=US, O=HP,OU=HP-IPG,
alright not that it matters (I can import a more meaningful one if I really feel like
it), but, why is it
Issued On: 2019-06-14 and set to
Expires On: 2029-06-11?
Anyway, print quality is quite nice. I hope to keep the printer long
enough to rant at the certificate being expired in the future!
Every couple of months, one of my users falls prey to phishing
attacks, and send their login/password data to an unknown somebody
who poses as Well, as me, their always-friendly and always-helpful
systems administrator.
What follows is, of course, me spending a week trying to get our
systems out of all of the RBLs/DNSBLs. But, no matter how fast I act,
there s always distruption and lost mails (bounced or classified as
spam) for my users.
Most of my users use the Webmail I have configured on our institute s
servers, Roundcube, for which I have the
highest appreciation. Only that Of course, when a user yields their
username and password to an attacker, it is very successful
at Sending huge amounts of unrequested mail, leading to my server
losing its reputation
This week, I set two bits of mitigation strategies. The first one,
most straightforward, was to ask Roundcube to disallow sending mails
with over ten recipients. In a Debian install, this is as easy as
setting up the following variable in 
This FLISOL was hosted by the always great and always interesting
Oh Yes, 
So, the State had record of a child being born, and we knew where to
look if we came to need this information. But, many years later, a
very sensible tecnification happened: all records (after a certain
date, I guess) were digitized. Great news! I can now get my birth
certificate without moving from my desk, paying a quite reasonable fee
(~US$4). What s there not to like?
Digitally certified and all! So great! But But Oh, there s a
problem.
Of course Making sense of the handwriting as you can see is
somewhat prone to failure. And I cannot blame anybody for failing to
understand the details of my record.
So, my mother s first family name is Iszaevich. It was digitized as
Iszaerich. Fortunately, they do acknowledge some errors could have
made it into the process, and 
Yes, the mailing contact is in the 
So finally, the greatest and meanest Raspberry is fully supported with
a pure Debian image! (only tarnished by the nonfree
OK, one step back. Why are we doing this? Because our hardworking
friends of the DebConf20 video team recommended so. In order to
minimize connecitvity issues from the variety of speakers throughout
the world, we were requested to pre-record the exposition part of
our talks, send them to the video team (deadline: today
2020-08-16, in case you still owe yours!), and make sure to be present
at the end of the talk for the Q&A session. Of course, for a 45 minute
talk, I prepared a 30 minute presentation, saving time for said Q&A
session.
Anyway, I used the excellent 
With lots of help (say, all of the heavy lifting) from the 
Only... _Some_ blocking did hurt Telmex's users: The ability to play
an active role in Tor. The ability to host Tor relays at home. Why?
Because the *consensus protocol* requires relays to be reachable in
order to be measured from the network's *DirAuths*.
### Technical work to prove the blocking
We dug into the issue as part of the work we carried out in the
project I was happy to lead between 2018 and 2019, *UNAM/DGAPA/PAPIME
PE102718*. In March 2019, I presented a paper titled [Distributed
Detection of Tor Directory Authorities Censorship in
Mexico](https://www.thinkmind.org/index.php?view=article&articleid=icn_2019_6_20_38010)
([alternative download](http://ru.iiec.unam.mx/4538/) in the [Topic on
Internet Censorship and Surveillance (TICS) track](https://tics.site/)
of the XVIII International Conference on Networks.
Then... We had many talks inside our group, but nothing seemed to move
for several months. We did successfully push for increasing the number
of Tor relays in Mexico (we managed to go from two to eleven stable
relays not much in absolute terms, but quite good relatively, even
more considering most users were not technically able to run one!)
So, we are already halfway through DebCamp (which means, you can come
and hang out with us in the