#Country ban with UFW#
Grab your different country ip addresses and save as Linux IPTables
http://www.ip2location.com/free/visitor-blocker
##Add country## Run the following command
Ansible playbook to setup HTTPS using Let's encrypt on nginx. | |
The Ansible playbook installs everything needed to serve static files from a nginx server over HTTPS. | |
The server pass A rating on [SSL Labs](https://www.ssllabs.com/). | |
To use: | |
1. Install [Ansible](https://www.ansible.com/) | |
2. Setup an Ubuntu 16.04 server accessible over ssh | |
3. Create `/etc/ansible/hosts` according to template below and change example.com to your domain | |
4. Copy the rest of the files to an empty directory (`playbook.yml` in the root of that folder and the rest in the `templates` subfolder) |
#Country ban with UFW#
Grab your different country ip addresses and save as Linux IPTables
http://www.ip2location.com/free/visitor-blocker
##Add country## Run the following command
This is inspired by A half-hour to learn Rust and Zig in 30 minutes.
Your first Go program as a classical "Hello World" is pretty simple:
First we create a workspace for our project:
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
sudo su | |
yum --enablerepo=extras install epel-release | |
yum -y install patch dkms kernel-devel perl | |
yum update | |
#Required for kernel num 5: | |
yum --enablerepo=elrepo-kernel -y install kernel-ml-devel | |
reboot |
#standardsql | |
WITH a AS ( | |
SELECT * FROM UNNEST([1,2,3,4]) AS n | |
), b AS ( | |
SELECT * FROM UNNEST([4,5,6,7]) AS n) | |
SELECT * FROM a |
#!/usr/bin/env python | |
# coding: utf-8 | |
import argparse | |
import os | |
import sys | |
import time | |
import atexit | |
import logging | |
import signal |
Services declared as oneshot
are expected to take some action and exit immediatelly (thus, they are not really services,
no running processes remain). A common pattern for these type of service is to be defined by a setup and a teardown action.
Let's create a example foo
service that when started creates a file, and when stopped it deletes it.
Create executable file /opt/foo/setup-foo.sh
:
{ "path": "/content/geometrixx/my-first-jinja-page", | |
"properties": [ | |
{ "name": "jcr:primaryType", | |
"value": "cq:Page" }], | |
"nodes": [ | |
{ "path": "jcr:content", | |
"properties": [ | |
{ "name": "jcr:primaryType", | |
"value": "cq:PageContent"}, |
import boto3 | |
import json | |
import logging | |
import time | |
logger = logging.getLogger() | |
logger.setLevel(logging.INFO) | |
def notify_on_error(message): |