When you use docker with "multiple commands", you will write scripts like this:
run.sh
#!/bin/sh -e
pip install --upgrade poetry
poetry config settings.virtualenvs.create false
poetry install
use std::sync::{Arc, Mutex}; | |
use std::thread; | |
fn main() { | |
let a = Arc::new(Mutex::new(0)); | |
let b = Arc::new(Mutex::new(0)); | |
let mut handles = vec![]; | |
{ | |
let a = Arc::clone(&a); |
Recently, Let's Encrypt launched free wildcard certificates. While this is good news in and of itself, as it removes one of the last remaining reasons for expensive commercial certificates, I've unfortunately seen a lot of people dangerously misunderstand what wildcard certificates are for.
Therefore, in this brief post I'll explain why you probably shouldn't use a wildcard certificate, as it will put your security at risk.
It's generally pretty poorly understood (and documented!) how TLS ("SSL") works, so let's go through a brief explanation of the parts that are important here.
The general (simplified) idea behind how real-world TLS deployments work, is that you:
# ssh key generator data source expects the below 3 inputs, and produces 3 outputs for use: | |
# "${data.external.ssh_key_generator.result.public_key}" (contents) | |
# "${data.external.ssh_key_generator.result.private_key}" (contents) | |
# "${data.external.ssh_key_generator.result.private_key_file}" (path) | |
data "external" "ssh_key_generator" { | |
program = ["bash", "${path.root}/../ssh_key_generator.sh"] | |
query = { | |
customer_name = "${var.customer_name}" | |
customer_group = "${var.customer_group}" |
# Convert to TSV | |
# Note -r flag | |
# to_entries creates an array of key,value maps, the trailing [] converts this array to stream items | |
cat api-docs.json | jq -r '.paths | to_entries[] | .key as $path | .value | to_entries[] | [.key,$path,.value.tags[0]] | @tsv' | |
# Transform into different JSON... | |
cat api-docs.json | jq '[ .paths | to_entries[] | .key as $path | .value | to_entries[] | { path:$path, method:.key, tag:.value.tags[0] } ]' |
#!/bin/bash | |
interfaces=( $(netstat -in | egrep 'utun\d .*\d+\.\d+\.\d+\.\d+' | cut -d ' ' -f 1) ) | |
rulefile="rules.tmp" | |
echo "" > $rulefile | |
sudo pfctl -a com.apple/tun -F nat | |
for i in "${interfaces[@]}" | |
do | |
RULE="nat on ${i} proto {tcp, udp, icmp} from 192.168.64.0/24 to any -> ${i}" | |
echo $RULE >> $rulefile | |
done |
This is my attempt to give Scala newcomers a quick-and-easy rundown to the prerequisite steps they need to a) try Scala, and b) get a standard project up and running on their machine. I'm not going to talk about the language at all; there are plenty of better resources a google search away. This is just focused on the prerequisite tooling and machine setup. I will not be assuming you have any background in JVM languages. So if you're coming from Python, Ruby, JavaScript, Haskell, or anywhere… I hope to present the information you need without assuming anything.
Disclaimer It has been over a decade since I was new to Scala, and when I was new to Scala, I was coming from a Java and Ruby background. This has probably caused me to unknowingly make some assumptions. Please feel free to call me out in comments/tweets!
One assumption I'm knowingly making is that you're on a Unix-like platform. Sorry, Windows users.
# Compiled source # | |
################### | |
*.com | |
*.class | |
*.dll | |
*.exe | |
*.o | |
*.so | |
# Packages # |
/** | |
* Takes a Sails Model object (e.g. User) and a ValidationError object and translates it into a friendly | |
* object for sending via JSON to client-side frameworks. | |
* | |
* To use add a new object on your model describing what validation errors should be translated: | |
* | |
* module.exports = { | |
* attributes: { | |
* name: { | |
* type: 'string', |
module.exports = { | |
/** | |
* | |
* Using raw socket.io functionality from a Sails.js controller | |
* | |
*/ | |
index: function (req,res) { |