| tunnel.enabled = true |
This was initially posted in an kubernetes-sigs/kustomize issue.
We are using Kustomize's vars feature. Initially we didn't understand how to use it for our purpose, but it is a 100% fit. One example is our Ingress resource, which looks like this:
# file: base/ingress.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: services
Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.
Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.
Wayland proponents make it seem like Wayland is "the successor" of Xorg, when in fact it is not. It is merely an incompatible alternative, and not even one that has (nor wants to have) feature parity (missing features). And unlike X11 (the X Window System), Wayland protocol designers actively avoid the concept of "windows" (making up incompr
| #!/bin/bash | |
| # Unlock the directory, we need the unencrypted versions of the files | |
| git crypt unlock | |
| # Re-initialize git crypt, generating a new key | |
| rm .git/git-crypt/keys/default | |
| git crypt init | |
| # Make the key available to the current users |
| #!/usr/bin/env bash | |
| # | |
| # Script to remove GPG user (recipient) with git-crypt | |
| # | |
| # It will re-initialize git-crypt for the repository and re-add all keys except | |
| # the one requested for removal. | |
| # | |
| # Note: You still need to change all your secrets to fully protect yourself. | |
| # Removing a user will prevent them from reading future changes but they will | |
| # still have a copy of the data up to the point of their removal. |
| #!/usr/bin/env bash | |
| UA="Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0" | |
| COOKIES="cookies-google-com.txt" | |
| _URLS_PER_PROC=20 | |
| _MAX_PROCS=6 | |
| _METER_WIDTH=50 | |
| queue=0 |
This is an investigation into our susceptibility to Slow HTTP Attacks. These attacks take advantage of how typical web servers process requests and employ several strategies to achieve the same result. By keeping connections open longer than normal, they thereby prevent new connections from being opened and the server will either hang or return 503.
The question is less about whether we are vulnerable, but rather to what extent. Any server can be DoS’d, it’s just a matter of how easy it is to execute.
| provider "openstack" { | |
| user_name = "calvinh" | |
| tenant_name = "canonical_30039" | |
| tenant_id = "6a74f3b9a17847588d9fdee581cbb01a" | |
| password = <password> | |
| auth_url = "https://api-jed1-vdc.bluvalt.com/identity/v3" | |
| region = "RegionOne" | |
| user_domain_name ="jed1" | |
| project_domain_name = "jed1" | |
| } |
| $ git clone git@github.com:xxxxx/xxxx.git my-awesome-proj | |
| Cloning into 'my-awesome-proj'... | |
| ssh: connect to host github.com port 22: Connection timed out | |
| fatal: Could not read from remote repository. | |
| $ # This should also timeout | |
| $ ssh -T git@github.com | |
| ssh: connect to host github.com port 22: Connection timed out | |
| $ # but this might work |
| # Tested on QNAP TVS-1282T3 | |
| # connect to NAS thru SSH (ssh -p <port> admin@<NAS IP>) | |
| ROOTCA=<custom-rootca>.crt | |
| cp /share/NFSv\=4/<somewhere>/<custom-rootca>.crt /usr/certs | |
| ln -s /usr/certs/$ROOTCA /usr/certs/`openssl x509 -hash -noout -in /usr/certs/$ROOTCA`.0 |
