Skip to content

Instantly share code, notes, and snippets.

View skottler's full-sized avatar

Sam Kottler skottler

View GitHub Profile
Interval Since Last Panic Report: 276904 sec
Panics Since Last Report: 1
Anonymous UUID: A32457F1-519F-4B3F-83DD-FD6519CA313D
Wed Nov 16 21:43:55 2011
panic(cpu 2 caller 0xffffff80002c266d): Kernel trap at 0xffffff8000539801, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0xfffffffffffffe6d, CR3: 0x000000002ffa4085, CR4: 0x00000000000606e0
RAX: 0xffffff800d08a808, RBX: 0xffffff800bca4a68, RCX: 0x0000000000000024, RDX: 0xffffff800cdf8800
RSP: 0xffffff807fb6bd50, RBP: 0xffffff807fb6bd90, RSI: 0xffffff8010193098, RDI: 0xffffff800cdf8800
R8: 0xffffff80008bdb40, R9: 0xffffff800778da10, R10: 0xfffffe800168c2a8, R11: 0x00000000001592f4
server {
listen 80;
server_name localhost;
location / {
proxy_pass localhost:8090;
}
}
server {
listen 8090;
server_name localhost;
location / {
proxy_pass localhost;
}
}
Ohai.plugin(:Trim) do
# This ohai plugin provides data about TRIM support on each underlying block
# device available on the system. Its functionality is rather simple - it
# iterates over each physical device, ignoring partitions, and then runs
# hdparm to find the drives' capabilities, finally grepping for TRIM support.
provides "block_device/trim"
depends "block_device"
collect_data(:default) do

Before:

samkottler@ubuntu:~$ cat /proc/meminfo
MemTotal:        2042728 kB
MemFree:          599932 kB
Buffers:           33268 kB
Cached:          1240816 kB
SwapCached:         3396 kB
Active: 1051100 kB
require 'spec_helper'
describe command("env x='() { :;}; echo vulnerable' bash -c 'echo this is a test'") do
its(:exit_status) { is_expected.to eq 0 }
its(:stdout) { is_expected.not_to match(/vulnerable/) }
end

I'm gonna forgot how to fix this next time I come across it, so using this gist to document the issue. This occurs on Debian 7.5 with the following package installed from testing: openssh-server 1:6.6p1-5, which was pulled in through the ssh metapackage.

Could not load host key: /etc/ssh/ssh_host_ed25519_key

Apparently this is a bug in the debian packaging. Luckily there's a pretty great command for fixing it: ssh-keygen -A, which will generate any missing keys. If you're running with a VM make sure you've got enough available entropy to generate those aforementioned keys. If you don't want to run the creation command for all the missing keys, then you can just run this instead: /usr/bin/ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ''.

Keybase proof

I hereby claim:

  • I am skottler on github.
  • I am shk (https://keybase.io/shk) on keybase.
  • I have a public key whose fingerprint is 76EE 0F0F FF19 5505 81F3 0E2F 499C 8210 826E 8956

To claim this, I am signing this object: