Another off-topic question (using this forum as your author page is quite discouraging about sending you emails ....)

What's the reason for naming cyclog files with the time they were closed? (other than that's how djb did it?), since this information is available easily with 'ls -l'?

I use a logger that opens a $CREATE_TIMESTAMP.u file, and makes "current" a symbolic link to it; and on close renames it to ".s", which I find more intuitive and informative (also provides time between log creation and first message, which is unavailable with cyclog). I was considering changing the ".u"/".s" marking to be an attribute (-w or +i or +t to signify "safely closed") to help repeated rsyncs of log directories, but haven't done that yet.

I'm sure there's some useful aspect of existing cyclog/multilog behaviour that I'm missing, but I haven't been able to figure what it is for the last 10 years ...

* http://www.skarnet.org/lists.html

As for the filenames, yes the original reason was for compatibility with multilog, and of course all of the other tools that can process these log directories. I did set out, after all, to produce a cyclog workalike, with lessons from multilog incorporated. Note that said tools might not deal well with log directories where the same log file is available via two names, both "current" and something else.

Moreover, if you go and look at follow-log-directories you can see an additional benefit that it very efficiently skips its cursors over old files without having to look at their i-nodes because it knows that the filename is guaranteed to be a timestamp at or after the last log entry in the file.

Furthermore, if you go and read the cyclog manual, you'll find out why using the w permission bit had problems. (-:

1.41 is building up changes, by the way.

Thanks, that's two thing I've missed (because I never used it, I guess ..): This optimization and follow-log-directories+export-to-rsyslog which was introduced at a time I wasn't looking :)

> Furthermore, if you go and read the cyclog manual, you'll find out why using the w permission bit had problems. (-:

:) Indeed, thanks.

> 1.41 is building up changes, by the way.

Thanks! And since I've missed follow-log-directories (and export-to-rsyslog) before, maybe there's another tool I've missed that would make shipping log directories more efficient? I'm concerned with very-low-bandwidth, very-intermittently-connected servers in which rsync is a godsend and e.g. rsyslog and friends proved much less reliable and efficient; And the renaming of "current" makes it miss the fact that it already has an (almost complete) copy of said file under a different name.

Thanks again!

This is, of course, more of an rsync problem. And it seems that there are approaches to having rsync detect renamed files and handle them more efficiently.

What happened?

The short version: > "As you can see, the GNU inetutils and NET-3 net-tools ifconfigs have some marked deficiencies, with respect to IPv6, with respect to interfaces that have multiple addresses, and with respect to functionality like -l.

> The IPv6 problem is in part some missing code in the tools themselves. But in the main it is caused by the fact that Linux does not (as other operating systems do) provide IPv6 functionality through the ioctl() interface. It only lets programs see and manipulate IPv4 addresses through the networking ioctl()s.

> Linux instead provides this functionality through a different interface, send() and recv() on a special, and somewhat odd, address family of sockets, AF_NETLINK.

> The GNU and NET-3 ifconfigs could have been adjusted to use this new API. The argument against doing so was that it was not portable to other operating systems, but these programs were in practice already not portable anyway so that was not much of an argument.

> But they weren't adjusted, and remain as aforeshown to this day."

Edit: Interesting,

https://jdebp.uk has the correct cert configured, whereas https://jdebp.uk. serves the cert as mentioned above.

The Apache web server that the bulk host is using for that site has a fairly poor implementation of HTTPS. It's unsatisfactory in various ways, some very technical, but what you're seeing here is the weird way it handles SNI.

By default when you say you want jdebp.uk. and there is no such virtual host (there's only jdebp.uk with no trailing dot) Apache will pick a default virtual host and act as though you asked for that, sending over the certificate for that host and so on. In this case, at a bulk hosting site, it's some unrelated Antiques Shop outfit, likely because that begins with 'A' which is the first letter of the alphabet.

This actually caused a problem for Let's Encrypt because their tls-sni-01 challenge type assumed nobody would be crazy enough to answer queries for a random name with a certificate chosen by somebody else entirely. But that's exactly what Apache is doing here. The current tls-alpn-01 challenge was introduced to fix that - it asks for a reserved ALPN service instead of a spurious SNI server name.

You'll see the same for various other providers that crawl the IPv4 Internet looking for services. My last job (it seems prescient now to have no job, very convenient in current situation to have no reason to go outside anyway) had me trying to fit some of this data to other service discovery information.

For example, try the following:

  openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk."

  openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk"

According to the Server header returned:

  Server: Apache/2.4.41 (cPanel) OpenSSL/1.1.1d mod_bwlimited/1.4 Phusion_Passenger/5.3.7

> "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using UTF-8 encoding, without a trailing dot.

More information: https://news.ycombinator.com/item?id=22632959

Apart from that, to circumvent badly configured paywall filters?