Let's look at some basic kubectl output options.
Our intention is to list nodes (with their AWS InstanceId) and Pods (sorted by node).
We can start with:
kubectl get no
#!/bin/bash | |
# This script purges the local history older than 90 days in some rooms, that you can define in an array | |
# | |
# crontab -e | |
# 23 4 * * * bash /home/irc-bridge/.synapse/EIGENE_purge_history_daily > /dev/null 2>&1 | |
cd /home/irc-bridge/.synapse/ | |
DOMAIN="matrix.yourserver.org" | |
ADMIN="@some_adminuser:matrix.yourserver.org" |
#!/bin/bash | |
name=$RANDOM | |
url='http://localhost:9093/api/v1/alerts' | |
echo "firing up alert $name" | |
# change url o | |
curl -XPOST $url -d "[{ | |
\"status\": \"firing\", |
This is a guide that I wrote to improve the default security of my website https://fortran.io , which has a certificate from LetsEncrypt. I'm choosing to improve HTTPS security and transparency without consideration for legacy browser support.
I would recommend these steps only if you have a specific need for information security, privacy, and trust with your users, and/or maintain a separate secure.example.com domain which won't mess up your main site. If you've been thinking about hosting a site on Tor, then this might be a good option, too.
The best resources that I've found for explaining these steps are https://https.cio.gov , https://certificate-transparency.org , and https://twitter.com/konklone
While I'm learning how to use Nginx, I was instructed to update the server_names_hash_bucket_size
(/etc/nginx/nginx.conf
) value from 32 to 64, but I don't understand why should I increase the value to 64.
References that have been read so far:
# import config. | |
# You can change the default config with `make cnf="config_special.env" build` | |
cnf ?= config.env | |
include $(cnf) | |
export $(shell sed 's/=.*//' $(cnf)) | |
# import deploy config | |
# You can change the default deploy config with `make cnf="deploy_special.env" release` | |
dpl ?= deploy.env | |
include $(dpl) |
Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.
My 3 developers team has just developed React.js application with 7668
lines of CSS (and just 2 !important
).
During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.
Here are main principles we use to write CSS for modern (IE11+) browsers:
Building realtime applications is hard.
A scalable solution to this problem involves many cumbersome steps: