Set of scripts to deploy locally, vault and configure TLS server and user certificates for testing TLS AUTH.
credit to @reard3n (https://github.com/reard3n) and @v6 (https://github.com/v6) for the gist this grew from
This was tested using Vagrant and Ubuntu
Vault secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing. Vault is primarily used in production environments to manage secrets. Vault is a complex system that has many different pieces. There is a clear separation of components that are inside or outside of the security barrier. Only the storage backend and the HTTP API are outside, all other components are inside the barrier.
Figure 1: Architecture of Vault and Spring App (Click to enlarge)
The storage backend is untrusted and is used to durably store encrypted data. When the Vault server is started, it must be provided with a storage backend so that data is available across restarts. The HTTP API similarly must be started by the Vault server on start so that clients can interact with it.
| --- | |
| version: '2' | |
| services: | |
| jupyter: | |
| image: jupyter/scipy-notebook | |
| container_name: jupyter | |
| command: start.sh jupyter lab --LabApp.token='*******************' --LabApp.allow_remote_access='True' --LabApp.allow_origin='*' | |
| restart: always |
The best way to get a clean installation of PyTorch, is to install the pre-compiled binaries from the Anaconda distribution. Therefore, we need to setup Anaconda first.
| # Login to AWS registry (must have docker running) | |
| docker-login: | |
| $$(aws ecr get-login --no-include-email --region us-east-1 --profile=mycompany) | |
| # Build docker target | |
| docker-build: | |
| docker build -f Dockerfile --no-cache -t mycompany/myapp . | |
| # Tag docker image | |
| docker-tag: |
04/26/2103. From a lecture by Professor John Ousterhout at Stanford, class CS142.
This is my most touchy-feely thought for the weekend. Here’s the basic idea: It’s really hard to build relationships that last for a long time. If you haven’t discovered this, you will discover this sooner or later. And it's hard both for personal relationships and for business relationships. And to me, it's pretty amazing that two people can stay married for 25 years without killing each other.
[Laughter]
> But honestly, most professional relationships don't last anywhere near that long. The best bands always seem to break up after 2 or 3 years. And business partnerships fall apart, and there's all these problems in these relationships that just don't last. So, why is that? Well, in my view, it’s relationships don't fail because there some single catastrophic event to destroy them, although often there is a single catastrophic event around the the end of the relation
| # Convert an existing docker container into a "docker run" command line. | |
| # | |
| # This is useful when trying to debug containers that have been created | |
| # by orchestration tools. | |
| # | |
| # Install jq: stedolan.github.io/jq/ | |
| function format_run() { | |
| cid=$1 |
| // The following data should be run in the console while viewing the page https://read.amazon.com/ | |
| // It will export a CSV file called "download" which can (and should) be renamed with a .csv extension | |
| var db = openDatabase('K4W', '2', 'thedatabase', 1024 * 1024); | |
| getAmazonCsv = function() { | |
| // Set header for CSV export line - change this if you change the fields used | |
| var csvData = "ASIN,Title,Authors,PurchaseDate\n"; | |
| db.transaction(function(tx) { |
| File | Purpose |
|---|---|
/etc/compose/docker-compose.yml |
Compose file describing what to deploy |
/etc/systemd/system/docker-compose.service |
Service unit to start and manage docker compose |
/etc/systemd/system/docker-compose-reload.service |
Executing unit to trigger reload on docker-compose.service |
/etc/systemd/system/docker-compose-reload.timer |
Timer unit to plan the reloads |