One of CUPS 's ( also ) many features is that it can(try to) log reports of how many pages got printed to what printerby who; this is set by the PageLog directive in cups-files.conf . We set thisin our CUPS configuration because it's a useful aid for debuggingand broadly tracking usage, probably as do many people who run CUPSas a central print server. I've recently been exploring some of thethings involved in this logging, due to discovering that

In theory Python 2 is now dead ( sort of ). Inpractice we have a significant number of Python 2 scripts and programs(including a Django web app , probably likemany other places. Converting these to Python 3 is a make-work projectwe want to avoid, especially since it risks breaking important thingsthat are working fine. One big and obvious issue for keeping on usingPython 2 is that we use Linux (primarily Ubuntu) and normally use thesystem version of Python 2 in /usr/bin

Back in early December I wrote about Why udev may be trying torename your VLAN interfaces to bad names ,where modern versions of udev tried to rename VLAN devices from thearbitrary names you give them to the base name of the network devicethey're on. Since the base name is already taken, this fails.

There turns out to be a simple cause and workaround for this, atleast in my configuration, from Zbigniew Jędrzejewski-Szmek . In Fedora,all I need to do is add '

These days, a number of core Go standardpackages support functions that take a context.Context argument and abort theiroperation if the context is cancelled. This is an interesting trickin Go, because normally you can't gracefully interrupt a goroutinedoing network IO ( which leads to problems in practice ). When I started looking into the relevantstandard library code I expected to find that things like net.Dialer.DialContext() had special hooks into the runtime's network poller (netpoller) todo this.

Mercurial's Journey to and Reflections on Python 3 is about what it sounds like, by one of the core maintainers of Mercurial . It also contains someinteresting notes on why Mercurial is going to have to keep supportingPython 2 for quite some time and what some of the consequences ofthat are.

Not too long ago, I was modernizing some of our Apache TLS settings.As I usually do, I went to the Mozilla SSL configuration generator ( which is what I think youshould do ) and more or less accepted itsrecommendations for our Apache and OpenSSL version. These days,that includes OCSP stapling . I didn't reallythink much about this. Then some things happened recently , and today my co-workers asked moreor less if we should be doing OCSP stapling at all. Unfortunately,the more

Probably like many people, I've been hearing for years now thatJanuary of 2020 was the end of life for Python 2, specificallyJanuary 1st. As a result, I was rather surprised to hear that therewill be another release of Python 2 in April, although I could haveread the actual details in PEP 373 and avoided this.

The official dates, from PEP 373 , are:

Planned future release dates:

• 2.7.18 code freeze January,

When I initially set up OCSP stapling while I was modernizingour Apache TLS configurations, I followed the standard setup from the Mozilla SSL configuration generator ( as is my usual habit ). For OCSPstapling, the configuration this generates was (and is) just:

SSLUseStapling OnSSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

Then recently our web servers at work couldn't get a good answerfrom Let's Encrypt's OCSP servers , for reasonsthat aren't clear

Every new process and thread on Linux gets a new PID (short forprocess ID). PIDs are normally assigned sequentially until theyhit some maximum value and roll over . Thetraditional maximum PID value on Unixes has been some number relatedto a 16-bit integer, either signed or unsigned, and Linux is noexception; the kernel default is generally still 32768 (which is2^15 exactly, and so not quite authentic to a signed 16-bit int).

(