An example from one of my setups:
location /api/deploy/core {
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded
Minor OTA
This morning, before my coffee, this email really messed with me.
> $ uname -a
> OpenBSD ultron.hulten.org 6.3 GENERIC.MP#45 amd64
One of my machines is named ultron as well...
Ken
Dare I ask what lead to OpenBSD not being affected.
Sorry if it is a dumb question but since this hit FreeBSD as well I am
wondering
what OpenBSD did differently.
Was this caught in an audit?
I am just curious about causality that kept OpenBSD in the clear of this one
that made such headlines ye
Not exactly. For starters right now I am getting to know OpenBSD as a
platform
so at this point is more about evaluating if and how to alter my workflows
to
better fit with the platform.
Next off though is in general with python code I do consider it important to
think about what the deployment wi
I power my flying car with flying monkeys...
I think the best answer from all this comes back to, at least for python 3,
switching over to the built in venv in python3.
Other than that the symlink to a location in /usr/local for venv is another
option for python 2 or packages that need to wxallow
Is there a recommended best practice when setting up an environment with
python
virtualenv with regards to wxallowed.
My typical workflow is under my home directory I have a
dev/language/project/.venv type structure. I guess the simple solution is to
mount /home as wxallowed in /etc/fstab, but is
6 matches
Mail list logo
