So uwsgi is pretty crazy:
# ./bin/uwsgi --help|wc -l
857
I'm using it under runit to manage some graphite processes, the problem I was having, was that I simply couldn't get it to restart with sv t, or stop with sv d.
Turns out, this is because UWSGI's default behaviour is to "brutally reload" when it receives the TERM signal, unlike most other things you'd use under runit which would normally die.
Luckily, one of uwsgi's 857 options fixes this:
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.
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.
| index.html |
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
ltsp-server-standalone from the Ubuntu Archivesudo ltsp-build-clientmount -t proc none /opt/ltsp/amd64/proc
| BWPRICE = 0.045 | |
| COLPRICE = 0.12 | |
| unless ARGV[0] then | |
| puts "Usage: #{$0} [#bwpages] [#colpages] [#copies] [binding-price/copy]" | |
| exit 1 | |
| end | |
| binding_price = ARGV[3].to_f | |
| ## 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 |
| #! /usr/bin/env python | |
| import sys, os | |
| import httplib # JSON Retrieval | |
| import simplejson # JSON Parsing | |
| class Story(object): | |
| """ | |
| Class to represent a single Reddit story. |