TimWolla

I'm surprised you find the documentation lacking. What type of API are you talking about? The internal C API? Lua? Configuration? Something else?

Disclosure: I'm a community contributor to HAProxy and help maintain the issue tracker.

There's this comment which is newer: https://news.ycombinator.com/item?id=32026565. There's also comments on some test submission: https://news.ycombinator.com/item?id=32026568 that itself got deleted: https://news.ycombinator.com/item?id=32026567

> EDIT: `-O resident` might be what is doing it though, I wasn't aware of this option.

Indeed. This will use FIDO 2 Discoverable Credentials / Resident Keys. Those are fully stored on-key (but their number is limited): https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu....

Non-resident keys will basically give out the private key encrypted with a static master key as the key handle and thus support an unlimited number of keys. If you lose the key handle, then the key is gone. That's probably what you were experiencing with your Titan.

Unfortunately updates are required here; to support new PHP versions. To the best of my knowledge the current version of Adminer still is not fully compatible with PHP 8.0 (it will emit warnings into an exported SQL dump):

https://github.com/vrana/adminer/pull/429 https://github.com/TimWolla/docker-adminer/issues/108#issuec...

Disclosure: I'm the TimWolla of the repository in the second link :-)

WebAuthn binds the credential to the domain. Under the assumption that your web browser and security key is operating according to spec this is unphishable. If your web browser or key contains a bug, or the domain is breached then all bets are off anyway.

This doesn't make sense. As a website author, why would I visibly restrict the security keys to backdoored government keys, when I can simply give the government an invisible backdoor API or direct database access?

WebAuthn supports sending an attestation certificate during the initial registration. But with an implementation according to the spec this certificate only identifies the model of the security key used and thus is shared across a 5 to 6 digit number of physical keys.

This attestation is meant to allow the service to verify that you use a "blessed" security key with certain security properties (e.g. only a YubiKey 5 they verified to be secure and not some random $5 key with broken RNG off Amazon).

You can use OATHTOOL [1] on the command line or even roll your own TOTP implementation [2] in just a few lines of code in your favorite programming language.

[1] https://www.nongnu.org/oath-toolkit/oathtool.1.html [2] https://datatracker.ietf.org/doc/html/rfc6238

Yes, but the TOTP is only usable once and cannot be reused across unrelated sites ("password stuffing"). And with WebAuthn / U2F the second factor is completely unphishable.

Yep, same here. I create many topical channels to discuss some narrow-ish topic and archive them after the matter is concluded. Some of those channels just live a few days or even just hours - other live for several weeks but with several days of silence in-between messages. If I need to look something up I can grab the channel from the archive and won't have messages for unrelated topics in-between.

Databases, Caches or the authentication service? For me read-only requests are working fine and I've not seen any issues. Submitting new contents (e.g. comments) is where it's failing for me. It might be that their database primary is falling over.

-f does not sound like a good idea to me in a script like that.

It's not part of the SMTP spec. SMTP treats the local part as an opaque identifier. It's somewhat common though and RFC 5233 extends the sieve filtering language to support it: https://datatracker.ietf.org/doc/html/rfc5233

Neither a mutt, nor an offlineimap user, but I believe those two are often used in combination: http://www.offlineimap.org/

> What are the benefits of SSE vs long polling?

The underlying mechanism effectively is the same: A long running HTTP response stream. However long-polling commonly is implemented by "silence" until an event comes in and then performing another request to wait for the next event, whereas SSE sends you multiple events per request.

> RFC 8441, released on September 2018, tries to fix this limitation by adding support for “Bootstrapping WebSockets with HTTP/2”. It has been implemented in Firefox and Chrome. However, as far as I know, no major reverse-proxy implements it.

HAProxy supports RFC 8441 automatically. It's possible to disable it, because support in clients tends to be buggy-ish: https://cbonte.github.io/haproxy-dconv/2.4/configuration.htm...

Generally I can second recommendation of using SSE / long running response streams over WebSockets for the same reasons as the article.

Laravel definitely is everything, but light-weight. It's the slowest of the large names in PHP.

see http://www.phpbenchmarks.com/en/comparator/framework or https://www.techempower.com/benchmarks/#section=data-r20&hw=...

This is my experience with Laravel as well. Laravel looks great on the surface for a simple CRUD application, but once you need to do something non-trivial with it, you need to start fighting the framework. Also I dislike the large amount of magic happening within the framework. I want to understand what the code is doing, so that I can properly debug it in an emergency.

As a specific example I needed to override half of the classes of Laravel Passport within the DI container to fix issues upstream wouldn't acknowledge at the time / doesn't acknowledge. Some of them are fixed by now (e.g. they finally support non auto increment Client IDs OOTB), some of them are not when I last checked.

I wouldn't choose Laravel again.

In Discord, yes. Unfortunately not in Slack, though.

It's likely that Hetzner doesn't make a loss on that machine, so they won't need to adjust prices there.

UDP itself is stateless, but QUIC itself is stateful. Without knowing the background I would assume the issue to be that the incoming UDP packets will be routed to the new process after the reload and that new process is not aware of the existing QUIC connections, because the state resides in the old process. Thus it is not able to decrypt the packets for example.

This is already possible. You can configure whether you want inetd style socket activation (where systemd calls accept() and passes you the client socket)), or just systemd listening to the socket (where systemd passes you the listen socket and your binary calls accept()).

https://www.freedesktop.org/software/systemd/man/systemd.soc...

That makes sense, because the attachment is going to be base64 encoded within the email and thus the size is inflated by 33%. This results in the size being roughly 47 MB in size.

I am not taking raw money with friends either. But when it's assistance I can't offer virtually, i.e. when I need to drive to them in person, then I expect them to order pizza to eat together in return after the job's done. It brings the point across that my time's not free, but it's not as unpersonal as handing over a Euro bill. One can also have a nice chat while eating.

One thing would be indicating that you are a maintainer in your comment, when it's not immediately obvious, so that readers are able to understand your comment in a proper context. Like I will do at the bottom of my comment:

Disclosure: Not a Caddy user. Turned off from it by the maintainers shamelessly plugging Caddy as the best thing since sliced bread whenever a competitor is mentioned somewhere. I'm also a community contributor to HAProxy which might or might not be considered a competitor.

It does not for me. If the current command line is not completely empty it will not do anything (both with bash and fish). So if the terminal does not close after pressing Ctrl+D I will know that something is wrong and check more carefully.

I can't say what they had in mind when typing `systemctl`. Even they couldn't. Because of the delay in the shutdown to cleanly stop the services, they had already forgotten that they just exited a SSH session and thus the connection between the machine being dead and typing `exit` was not obvious.

Maybe it was `systemctl status`. Maybe it was intended to be a `reload` (which would require elevated privileges).

A peer of mine was exiting their SSH sessions with 'exit'. One time apparently they already typed 'systemctl', probably in an attempt to check the status of a service, changed their mind and then later wanted to close the session using 'exit', actually executing 'systemctl exit'. This translated into a shutdown of the machine in question.

After being able to piece together what happened with the machine's logs and the bash history I recommended to simply exit all programs/sessions with Ctrl+D. It works almost everywhere and would have prevented this exact issue.

I have configured SSH with `UpdateHostKeys yes` and got a message about the SSH key for github.com (ECDSA) and the respective IP address (RSA) mismatching.

I assume that GitHub did not serve traffic on the IP address in question for me in the last while, while it formerly did. So I only have the RSA key for the IP, but the new ECDSA (and the RSA) for the hostname - causing the mismatch.

I could fix this without removing any stored host keys from my known hosts by manually connecting to the IP address. This caused my SSH client to grab all the other host keys due to `UpdateHostKeys yes`. Afterwards connecting to github.com as usual worked like it should.

> Just wanted a middle ground - oldschool style just less cluttered and less unnecessary info. Did I miss something? Did no one figure it out?

I'd say WoltLab Suite (https://www.woltlab.com/en/) matches that description. The forum part of the software is not free/OSS, though. There is also other modern, commercial, PHP-based forum software that would match your description (XenForo).

Disclosure: WoltLab is my employer.