It's not quite that simple. People actually tried to update net-tools ifconfig (one of the two ifconfigs back in 2018).
In 2019, I simply wrote an ifconfig that uses the netlink API, because for portability I needed a Linux ifconfig that had a FreeBSD-like command-line syntax. It doesn't have the old interface aliasing mentioned in the headlined article, and has no problems setting up and reporting IPv6 addresses or additional IPv4 addresses.
I have a system to convert Debian /etc/network/interfaces into a BSD-style rc.conf, which then in turn gets converted into a suite of native service bundles. One of the service bundles is ifconfig@interface , which invokes ifconfig with a uniform command-line syntax across Linux and FreeBSD, hence the need for a more FreeBSD-alike ifconfig on Linux.
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 ...
If you want more than just my perspective, look to Laurent Bercot's Supervision Mailing list. M. Bercot is of course there, as well as a few other people.
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. (-:
> 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.
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.
I don't know off the top of my head, but then I don't know all of the tools that exist for multilog/cyclog log directories.
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.
It's a comprehensive reply -- good stuff, and worth a read.
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."
That split where ioctl() is used for ipv4, and the send()/recv()/AF_NETLINK setup for ipv6 is interesting. I'm curious why the Linux folks chose that route. I'd get it as a temporary thing, but shouldn't they have migrated everything onto AF_NETLINK?
That's exactly what happened. Nobody bothered rewriting ifconfig to use the new APIs, because `ip` was the new hotness (and much more flexible and if not saner, at least differently insane).
Off-topic: I can't help but be nosy and check the https version of your page. You seem to be serving a cert with CN=albertstreetantiquescentre.co.uk. Might want to get this looked at :)
So, firstly don't put a dot at the end. Whatever you might feel about it, the decision in practice was that the host part of the URL is an FQDN but doesn't need a dot at the end. So don't write one there. The browser should probably trim it out when you type in or follow such a link.
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 can configure the first default apache vhost to be something else other than a "customer" site, that's what we do at my hosting company. though it still leads to a certificate error. that used to matter, but nowadays we just automatically lets encrypt everything that we host.
Censys gets these defaults (you could probably measure a slight bias in their data towards alphabetically earlier names as a result, but I have never checked) for sites using Apache, and for other servers with a default they get that default (in nginx I believe you have to explicitly configure a default if you want one). If there is no default the site says you need to specify which name you wanted or too bad.
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.
It seems that the server running on the other end doesn't properly match the certificate from the SNI if the domain sent by the browser is a FQDN (i.e. ends in a .)
The relevant RFC says not to send a trailing dot in SNI. Browsers should probably trim the dot out if present. Maybe they aren't doing so because it causes some unexpected compatibility mishap, maybe in reality it rarely causes any trouble so nobody got around to it.
> "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.
That's the page on a shared hosting service, not served by me. See the site history page (still in the same place that it was a couple of years ago when it came up on Hacker News).
This might be the first time in quite a few years that I've seen people using a dot like that. Any reasons to do so? I figured most people do not have weird DNS search domains or some such to warrant that dot.
In 2019, I simply wrote an ifconfig that uses the netlink API, because for portability I needed a Linux ifconfig that had a FreeBSD-like command-line syntax. It doesn't have the old interface aliasing mentioned in the headlined article, and has no problems setting up and reporting IPv6 addresses or additional IPv4 addresses.
* https://unix.stackexchange.com./a/504084/5132
* http://jdebp.uk./Softwares/nosh/guide/commands/ifconfig.xml
I have a system to convert Debian /etc/network/interfaces into a BSD-style rc.conf, which then in turn gets converted into a suite of native service bundles. One of the service bundles is ifconfig@interface , which invokes ifconfig with a uniform command-line syntax across Linux and FreeBSD, hence the need for a more FreeBSD-alike ifconfig on Linux.
* http://jdebp.uk./Softwares/nosh/guide/rcconf-amalgamation.ht...
* http://jdebp.uk./Softwares/nosh/guide/rcconf.html
* http://jdebp.uk./Softwares/nosh/guide/networking.html