El_RIDO
Gives me an 97 and 88 respectively[2] on that pagespeed tool.
[0] https://wordpress.org/plugins/wp-super-cache/
[1] https://github.com/simonrupf/docker-php-wp/blob/master/etc/n...
[2] https://pagespeed.web.dev/analysis/https-bobcat-dssr-ch/0ziq... / https://pagespeed.web.dev/analysis/https-simon-rupf-net/auk5...
Clearly you have gotten some unfortunate hands on experience with those edge cases. In my uses the dual-stacking of IPv4 & IPv6 has been a big benefit in that I have to worry a lot less about locking myself out of systems, as I can always reconnect and correct configuration mistakes on the second stack.
Comparing the IPv4+IPv6 dual-stack story to the one from the 90s of IPv4 with IPX/SPX (Novell Netware) and/or NetBIOS (Microsoft Windows), the current state is a lot more smooth and robust.
I've so far only run into 3 issues over the years (2013 till now). A local train operator running IPv6 on routers that didn't properly support non-default MTU sizes (fragmented packages getting dropped) and Microsoft where Github is still IPv4-only and Teams recently developed an IPv6-only failure on a single API endpoint.
Should we ever turn off IPv4 during my working life-time, I hope we have at that point introduced a successor to IPv6, so I can keep using a dual- or triple-stack solution, using different network protocols for robustness.
Nginx Unit https://unit.nginx.org/ - like Apache + mod_php runs as a single service, handles the multiprocessing of php (and other languages), static files, reverse proxy and even lets you configure both itself and php via a single configuration (either as a file or dynamically at runtime, via a socket): https://unit.nginx.org/configuration/#php
Here is an IRL config example: https://github.com/PrivateBin/docker-unit-alpine/blob/master...
The resulting container image can be pretty small: https://hub.docker.com/r/privatebin/unit-alpine
Prior to that bomber crews operated using electrically heated flight suites, gloves and used oxygen masks, when reaching those altitudes.
http://www.303rdbg.com/uniforms-gear3.html https://en.wikipedia.org/wiki/Boeing_B-29_Superfortress#Pres...
https://spamassassin.apache.org/full/3.0.x/dist/doc/sa-learn... https://cwiki.apache.org/confluence/display/spamassassin/Bay...
For a small instance with only a handful of friend and family accounts that effort (spam, abuse, legal stuff) will take less than 1h per month. On a large instance that can become a full persons job.
Source: I'm running my own fediverse instance since 2011 (using Friendica, predates Mastodon) - as well as my own mail server.
Google Plus and it's "circles" of contacts was a better design in that regard.
For example, in this project we use nginx + php-fpm to serve some PHP app:
https://github.com/PrivateBin/docker-nginx-fpm-alpine
It uses s6 to handle nginx + php-fpm services, meaning we have to maintain configuration for s6 services (written in execline), nginx webserver configuration files (nginx proprietary format) and php-fpm (INI format).
I've created a fork that replaces that stack with nginx unit:
https://github.com/PrivateBin/docker-unit-alpine
No need for a service manager and both webserver and php configuration are in one file[1]. What is not well documented IMHO is that you don't have to load the config at runtime - if you place the JSON file in the (compile time changeable) /var/lib/unit directory it will be loaded on startup, similar to a traditional /etc config file. But it also will get updated at runtime, if configuration is uploaded on the config socket, making it persist service restarts, hence /var is more appropriate than /etc.
[1] https://github.com/PrivateBin/docker-unit-alpine/blob/master...
- https://kislyuk.github.io/yq/
- https://github.com/kyle-long/yq#yq
- https://github.com/up1/yq-1#yq-command-line-yamlxml-processo...
- https://github.com/onixspot/yq-2#yq-command-line-yamlxmltoml...
https://jitsi.github.io/handbook/docs/community/community-in...
Servers on the other hand, I will provision with a static IP subnet on deploy, as part of the PXE install or configuration management process, depending on the environment. They will have an ephemeral address during the install, but then query for and persist their allotted address before rebooting into the installed environment as part of their post-install.
I guess we agree that we need a single source of truth, what physical device has what IP (range) in their possession at any time. DNS is a classic way to do that, but there are other solutions, from ITIL-style CMDBs to simple config management git repos. And of course the latter doesn't mean that we don't also update DNS based on IP-assignement, DHCP is not the only tool that can be made to interface with a DNS service.
The result then contains if the user clicked OK, Cancel, [X] to close the modal or any other state transition that you may have added to that dialog. The recipient (not necessarily the caller that initiated the dialog, in case you chain the responses) can then act accordingly and presumably triggers a different action on OK then the other state transitions.
Here is an example configuration file for nginx: https://snip.dssr.ch/?7a4e21dde5f7916b#2aPagYEg3kuWg3YN8Q5oz...
Though I would argue that the header-embedded CSS is still code, regardless how it is delivered.
Personally I share the same experience: In the 30 years I've been using personal computers at home and work, only 2 disks failed on me, one was an error on my part during an OS upgrade and the second was an external disk that physically fell off my bed while I had it plugged into my notebook. So both of these weren't really those random failures.
On the other hand, while working in an IT infra team of a 60 developer company with 4 racks full of servers for 3 years, we'd get to see about one failed SSD per 2 months and 2-3 failed disks or SSDs per year in servers.
During the 1 year I worked for the IT infra team at a smaller hospital of a medium sized city with a large VDI environment and two HP EVAs in a two datacenter configuration each, we'd get 3-4 disk failures per week. Those had over 140 disk per storage each and were approaching the end of their support life, being around 5 years old, so the failure ratio started to get higher.
See Ken Thompson, Reflections on Trusting Trust, 1984 https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
This was previously discussed in https://news.ycombinator.com/item?id=26188324
A downside of encrypting yourself is that you can't benefit from the hardware compression either, hence the articles suggestion to do that in software before compressing as well.
Personally, my tape writing workflow is: dar (per file compression, skips uncompressable mime types + encryption) followed by par2cmdline with 30% redundancy. For comparison: CD-ROMs have 33% redundancy information (8 bits per 24 bits, CIRC encoding).
I have been running it on those for a while, but also on other SBCs. You can grow the single master by attaching one or more workers to it. The "pain" is mainly that you can't expand the single-master to a multi-master setup, so once you want to go beyond a single master, you have to re-install it all. On the other hand, with k8s you have all deployments, etc. in yaml files and you simply redeploy these on the new cluster.
My remaining pain-point is persistent storage - it's simple to run complex setups with stateless containers or that can retrieve there data at initialization (i.e. a secondary name server that populates itself from the master at startup), but for classic databases I currently still have a manual step to import the DB dump once the service got (re)started/migrated.
Sources: - https://k3s.io/ - https://www.jeffgeerling.com/blog/2020/installing-k3s-kubern...
My oldest, still active, website was created in that style around 20 years ago and only in recent years did I change to a git and ansible based deployment instead of just editing the raw files on the server over ssh.
While I considered myself a decent Windows NT admin, 20 years ago, the reason I went all in on Linux and FLOSS software at the turn of the century was because I dreaded the powerlessness that these proprietary solutions gave me, when they failed. You'd call the vendors, pored through logs, finding obscure, undocumented error codes, etc. With FLOSS and self-hosting youve got all the information at your fingertips. And if you encountered bugs and you can dig into the sources, patch them, re-compile and fix things - and share them with others and feel that you're contributing to our profession.
When I got the chance to do cloud projects over the last 5 - 10 years, I always took these opportunities, hoping to ensure that I keep up with the tech. At first I was hopeful to offload the boring ops tasks, take our config management to the next level and automate even more. With every platform I got to work with, AWS, Azure and GCP so far, we kept finding bugs in their APIs, outdated or otherwise incorrect documentation and very unpredictable performance, unless you actually can run stacks at scale to average it out (as in more then just 10 - 20 instances or a larger clustered SaaS of the cloud vendor). Many times we also encountered undocumented limits that required requesting support and waiting for approval by the cloud vendor, to get even their mid-sized resources allocated. It all works very nicely on the free-tier-eligible, smallest instances and services, if as slow and high latency as is to be expected, but as soon as you actually need some decently sized storage, compute or bandwidth, it becomes quickly more expensive than what you can put in two or three datacenters for redundancy yourself, if you look at the yearly costs. So far none of the PoCs I was involved with ever got approved long term. They mostly end up as reference implementations for our customers or show case material for the corporate blog. :-(
No thanks, I don't want to go back to feel that powerless as I did on closed systems ever again. Luckily, although many seem to think that cloud is the only option to run at a global scale, you can still provide lots of valuable services on the internet using robust hardware, housed in well connected datacenters.
IMHO it really shines on dedicated, small VMs or for headless SBC use cases.
There's only 5 daemons running after the installation (provider in brackets, the installer asks which one for ssh and ntp): - init (OpenRC) - ssh (dropbear or OpenSSH) - ntp (chrony or busybox) - crond (busybox) - syslog (busybox)
The diskless mode it offers is ideal for SBC's or other use cases with SD-cards or such.
So it's niche seems to be with very lightweight or hardened servers.
As a Front-end Developer at LzLabs, you will be responsible for the development of an advanced web UI interacting with the LzLabs Software Defined Mainframe®. You will be involved in many stages of our development lifecycle, from planning and design to implementation. You will work in a UI team as you develop and test new features. You’ll also work daily with other LzLabs development teams.
Please apply online on our HR page, which also lists further details on the position, at https://lzlabs.peoplehr.net/Pages/JobBoard/Opening.aspx?v=d7...
Client → (HTTP/2) → Cloudflare ingress → (???) → Cloudflare egress → (???) → Your endpoint → (???) → Your web app
On your endpoint (LB or webserver) logs you can check if the requests coming in from Cloudbees are using HTTP/2 or not. If they do use HTTP/2, they internally might still do translation down to HTTP/1.1 and back.
But more importantly, you should investigate how your LB or webserver talks to the web app. In many cases that part won't be TLS encrypted and therefore on an HTTP/1.1 channel.
The exception is if your outward facing, TLS terminating, webserver interacts with the web app via CGI or FastCGI. While that part of the call stack would not be affected by this particular attack, (Fast)CGI comes with it's own set of risks.
In the end, the only part that you can't easily validate yourself of being susceptible to this attack (aka having to translate between HTTP/2 and HTTP/1.1) is the bit that occurs internally to Cloudflare.