| Found valid GPT with protective MBR; using GPT | |
| Disk /dev/block/mmcblk0: 61071360 sectors, 1148M | |
| Logical sector size: 512 | |
| Disk identifier (GUID): 98101b32-bbe2-4bf2-a06e-2bb33d000c20 | |
| Partition table holds up to 44 entries | |
| First usable sector is 34, last usable sector is 61071326 | |
| Number Start (sector) End (sector) Size Code Name | |
| 1 16384 180223 80.0M 0700 modem |
| --- | |
| name: 'Max Mustermann' | |
| database: | |
| host: 'localhost' | |
| database: 'mydb' |
On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.
Support for keeping a long-lived (disk) cache of OCSP responses.
This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server
Prerequisites : the letsencrypt CLI tool
This method allows your to generate and renew your Lets Encrypt certificates with 1 command. This is easily automatable to renew each 60 days, as advised.
You need nginx to answer on port 80 on all the domains you want a certificate for. Then you need to serve the challenge used by letsencrypt on /.well-known/acme-challenge.
Then we invoke the letsencrypt command, telling the tool to write the challenge files in the directory we used as a root in the nginx configuration.
I redirect all HTTP requests on HTTPS, so my nginx config looks like :
server {
Chromium OS is cool. Chromium OS with crouton is cooler. Chromium OS with Docker is even cooler. This is specifically a guide for the Chromebook Pixel 2 (2015), but I can't think of any reason it wouldn't work with other devices.
Setting project:
gcloud config set project tidy-bindery-110323
Creating a cluster:
gcloud container clusters create web --num-nodes=1 --machine-type=g1-small --zone=us-east1-b
This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.
In that post I talked about 3 main reasons for moving from require.js to webpack:
Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.
| #!/bin/bash | |
| echo -e '\e[1;31m' | |
| echo " ┌───────────────────────────────────┐" | |
| echo " │ Taking Screenshot. Say Cheese! │ " | |
| echo " └───────────────────────────────────┘" | |
| echo " ╱" | |
| echo " ▀▄ ▄▀" | |
| echo -e " ▄█▀███▀█▄ " | |
| echo -e " █▀███████▀█" |
| # Hello, and welcome to makefile basics. | |
| # | |
| # You will learn why `make` is so great, and why, despite its "weird" syntax, | |
| # it is actually a highly expressive, efficient, and powerful way to build | |
| # programs. | |
| # | |
| # Once you're done here, go to | |
| # http://www.gnu.org/software/make/manual/make.html | |
| # to learn SOOOO much more. |
