Benjamin Black benjaminblack

With a modern UEFI motherboard, it is possible to boot Linux directly from the UEFI boot manager, without relying on a boot loader like GRUB.

First, the kernel has to be compiled with the "EFI boot stub" option enabled, which modifies the kernel so that it can be directly executed by the UEFI boot manager.

Debian enables this flag: grep CONFIG_EFI_STUB /boot/config-*

Second, the EFI System Partition (ESP) must be large enough to hold the kernel and the initrd image. The UEFI boot manager executable files must be on the ESP; therefore, the kernel and initrd must be on the ESP, since the kernel is the EFI executable, and the kernel requires the initrd to be somewhere it can find it.

The ESP in Debian is usually 100-250 MB, which is fine.

If the Linux kernel is compiled with the EFI stub loader (grep CONFIG_EFI_STUB /boot/config-*), then an EFI BIOS can boot the kernel directly, without the need for a bootloader like GRUB. This only requires that the kernel and the initrd exist on the EFI partition. The EFI boot menu and boot order can be managed with the command-line utility efibootmgr.

Copying the kernel image and initrd onto the EFI partition the first time is simple; the problem is keeping them up-to-date as the system is updated. In particular, lots of software packages can trigger the initrd to be rebuilt. The most recent kernel image and initrd need to be copied to the EFI partition every time they are updated.

The Debian Linux Kernel Handbook documents initramfs hooks, stating that "Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/initramfs/post-update.d

Edit: Deprecated as of 380.67 - see documentation

If https_crt_save variable is turned off, turn it on:

# nvram get https_crt_save
0

# nvram set https_crt_save=1
# nvram get https_crt_save

Nginx server configuration location block which will match //host/s3/{bucket}/{path/to/resource} and transform it into a reverse proxy for an S3 bucket configured with static website hosting and named with a conventional prefix (adjust region accordingly), like //{s3prefix}-{bucket}.s3-website-us-east-1.amazonaws.com/{path/to/resource}.

E.g. assuming I prefix all of my S3 buckets with bb, like s3://bb-mybucket, and create my buckets in the us-east-1 region, then:

http://example.com/s3/mybucket/img/header.jpg

will be transformed into a proxied request to

http://bb-mybucket.s3-website-us-east-1.amazonaws.com/img/header.jpg

From two articles on stackoverflow and an MDN article:

In external SVG files (which should be served as image/svg+xml):

Include the prolog:

<?xml version="1.0" encoding="utf-8"?>

Include a DTD:

After much head-scratching trying to figure out from where by default Nginx decides to read its main configuration file, and where it decides to write its log files, it turns out that they are all set at compile time (configuration options broken onto separate lines for clarity):

$ nginx -V
nginx version: nginx/1.12.1
built by clang 8.1.0 (clang-802.0.42)
built with OpenSSL 1.1.0f  25 May 2017
TLS SNI support enabled
configure arguments: 
--prefix=/usr/local/Cellar/nginx/1.12.1

Keybase proof

I hereby claim:

I am benjaminblack on github.
I am benjaminblack (https://keybase.io/benjaminblack) on keybase.
I have a public key whose fingerprint is C3E6 79C4 C079 03C0 6C1C 8746 C27D 77E6 FAF4 E2DB

To claim this, I am signing this object:

Using HTTPS in local development

Beginning June 2018, Chrome 68 will begin marking HTTP as "Not Secure". Other browsers may swiftly follow Chrome's lead.

The push for Secure Contexts Everywhere and enforcement of HTTPS for all new features is also motivation to secure local development environments, to reduce the delta between development and production environments.

In short, the Web is rapidly moving all traffic to HTTPS, and local development environments should be no different.

The Problem

Easing the use of HTTPS in local environments, where each project gets a domain like ${project_name}.localhost, means automating the process of creating a self-signed certificate for each project, configuring the web server to use it, and locally trusting the certificates. (A new certificate for each project is required in this configuration, because a cer

⌘-⇧-. (Command-Shift-Period)

	TweenLite.to({val: 1}, 1.0, {
	val: 100,
	onUpdateParams: ['{self}'],
	onUpdate: ({target: {val}}) => console.log(val),
	});