jiphex

Keybase proof

I hereby claim:

• I am jiphex on github.
• I am jiphex (https://keybase.io/jiphex) on keybase.
• I have a public key whose fingerprint is AA0D 95BB B25B 595A 14B9 6906 25E1 4B9F 86A2 49D4

To claim this, I am signing this object:

jiphex

Running OpenBSD on BigV

Use the normal virtio profile, everything just works

Networking

To get IPv6 to work, configure hostname.vio0 as follows:

dhcp

up

jiphex

Keybase proof

I hereby claim:

• I am jiphex on github.
• I am jiphex (https://keybase.io/jiphex) on keybase.
• I have a public key whose fingerprint is 5006 A070 19BB 6D7C 38FF 8EEF BEB5 C536 D46D A098

To claim this, I am signing this object:

jiphex

---
- hosts: all
  sudo: yes
  tasks:
  - name: make sure lsb_release is installed
    apt: name=lsb-release
  - name: add squeeze-lts repo if squeeze
    apt_repository: repo='deb http://mirror.bytemark.co.uk/debian/ squeeze-lts main contrib non-free'
    when: ansible_distribution_major_version == "6" and ansible_distribution == "Debian"
  - name: upgrade bash to the latest version

jiphex

## This is supposed to find (and freeze in the queue) any messages which are sent from
## PHP scripts that are owned by the www-data user, so it should stop someone from executing
## the following common attack scenario:
##
## 1. Malicious person finds exploitable upload form on a website that allows writing
##    arbitrary PHP files to the web root of the server
## 2. Person uploads a PHP script used to send out email spam
## 3. Person executes that script either with exec() or via the web browser to send out spam
##
## This ACL should mean that messages just get stuck in the queue. A legitimate developer will

jiphex

Creating a functional LTSP environment

with Ubuntu Trusty and Nvidia ION based thin clients

1. Install Trusty server
2. Do updates
3. Install the desktop crap (Gnome and stuff, including probably xubuntu-desktop and gnome-fallback)
4. Install ltsp-server-standalone from the Ubuntu Archive
5. Configure networking, you need to have a second NIC with a static 192.168.8.0/24 address on it, and a DHCP server running there (the config comes with the aforementioned standalone package)
6. Run sudo ltsp-build-client
7. mount -t proc none /opt/ltsp/amd64/proc

jiphex

I need a new router. I've had lots of bad ones, let's fix that once and for all. We need to handle lots of simultaneous connections, and Internet connections at home are only going to get faster.

When I'm at home, if I'm not in bed then I'm probably not far from using some kind of Internet connection, so this thing should be good and the money I have available to spend on it should be proportional to the amount that this thing is going to get used. For this reason, it should also support emerging protocols such as 802.11AC.

It's time to stop relying on third party operating systems. The news over the past year has shown how shady governments and companies can be, let's run an Open operating system on this thing, and configure it from scratch.

Once it's configured, I should never have to do anything to this box. It should never go down for no reason, and I shouldn't have to think about it working, it should just get on with it. That's not to say it should be locked down completely, just that once stable, it

jiphex

index.html

jiphex

Sudo Weirdness

In a continuing series of documenting weird things that I find on Linux in case I have to come back to them in the future, today I came across some weirdness when trying to do something very specific with sudo.

The [sudoers man page][sudoersman] is long and complicated, it's even mentioned in an [XKCD Comic][xkcdsudoers].

In this case, I wanted to express the following:

Users in a specified group, "managed", must be able to execute /usr/bin/git as a specific (non-root) user, "person", without specifying a password.

jiphex

Apache Weirdness

Today I've spent a fairly large amount of time trying to track down a weird Apache edge-case, related to how self-referential URLs are generated. This is mostly-relevant if you're running Varnish (or any HTTP proxy really), and Apache 2.4 (although this probably affects other versions of Apache as well).

The configuration I'd normally use for Varnish/Apache is this:

[client] -> [varnish on port 80] -> [apache on high port, e.g 8080]

This normally (in my experience) works fine, and can be fairly transparent to the user.