Re: Deploy Django app - strategy?

2018-09-16 Thread Ken MacKenzie
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-Proto $scheme;
proxy_pass http://unix:/applications/deploy/core-api.sock:/;
}

This example is from a CentOS 7.4 box.

On Sun, Sep 16, 2018 at 2:43 PM Bogdan Kulbida  wrote:

> Hi Ken,
>
> Can you please be more specific on Nginx talking via sockets? Any URLs on
> that topic will be appreciated. Thank you.
>
> On Sun, Sep 16, 2018 at 09:46 Ken M  wrote:
>
>> On Sun, Sep 16, 2018 at 09:05:33AM +0300, ??  wrote:
>> > I deploy my django app using uwsgi and venv in my home dir
>> > uWSGi starts on its default port and httpd server uses this port
>> > to handle my app requests. Everything just like in the official manual
>> of
>> > uwsgi.
>> >
>>
>> Don't know if this is helpful for Django apps, or if httpd in openbsd can
>> use
>> unix sockets. Anyway with a couple of falcon api's I setup with Gunicorn I
>> actually used unix sockets instead of creating ports. If my proxy is on
>> the same
>> server as the api's I found that a little easier to manage. Granted in
>> this case
>> it was on centos and I was using nginx. Also in the process of figuring
>> out how
>> to do that I found a lot of the documentation on nginx syntax talking to
>> a unix
>> socket was wrong. But that is another story.
>>
>> Ken
>>
>> --
> ---
> Best regards,
> Bogdan Kulbida
> Founder and CEO, Konstankino LLC 
> +1.802.793.8295
>
>
>


Re: programs crash on Dell Latitude E7470

2018-05-25 Thread Ken MacKenzie
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


Re: CVE-2018-8897

2018-05-10 Thread Ken MacKenzie
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 yesterday.

Ken

On Thu, May 10, 2018 at 07:39:28AM -0700, Mike Larkin wrote:
> On Thu, May 10, 2018 at 10:22:48AM -0400, Predrag Punosevac wrote:
> > Does this
> >
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2018-8897
> >
> > affect 6.3 stable?
> >
> > Best,
> > Predrag
> >
>
> OpenBSD is not affected.
>
> -ml
>


Re: Best Practices python virtualenv

2018-05-01 Thread Ken MacKenzie
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 will look like on several target
environments.
Write once and run everywhere doesn't always work out exactly like that with
python. It sounds nice but is rarely reality.

In general though if I have a specific project to code, I am starting from
several pre-canned requirements files or docker images/compose scripts that
I
have already set up for specific types of projects.

So this is a case more of understanding how one of my use cases fits in the
OpenBSD eco system more so than just trying to setup a dev environment to do
XYZ.

Ken

On Tue, May 01, 2018 at 10:28:36PM +0200, Ve Telko wrote:
> Hi, Ken.
>
> Did you noticed that you are spending much more time
> with setting up your env every time you want to run your
> python apps than with programming itself?
>
> No offense but I think this is not normal.
>
> Ve.
>


Re: Best Practices python virtualenv

2018-05-01 Thread Ken MacKenzie
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 wxallowed.

On the topic of pip install vs pkg_add for python pieces, this relates back
to
some thoughts I had about dealing with python development on FreeBSD. Let's
face
it things like docker exist in part because of the mess deploying python
virtualenvs can become in production. I had the though of submitting an
extension to iocage (my preferred jail manager, which is now written in
python)
so that you could basically translate a venv + pip workflow into a jail
create
and pkg add pyv-package type setup.

However that also sounds like a big mess to maintain. Maybe something that
would
be more workable is something that quick translate a pip requirements.txt
file
into a pkg_add install script.  That could work probably for any *BSD
flavor.
Another option is that in the scope of venv after the pkg is added through
pkg_add symlinks are created in venv.

I guess the only thing to figure out is what to do when a requirements file
has
version specifications that are incompatible with what is in the pkg system.

Ken.



On Tue, May 01, 2018 at 09:46:36AM -0600, Theo de Raadt wrote:
> Leonid Bobrov  wrote:
> > I have a plan how to completely get rid of wxallowed mount option,
> > but I am not yet skilled to fix W|X ports, especially the ones
> > written in C++ (I've started learning C++ recently).
>
> Is that like
>
>"I have a plan to build a flying car, but I don't
>yet have any metal work skills"
>
> Or, aspiring to commit your life to working on world peace, from
> your basement?
>
> Not impressive.
>


Best Practices python virtualenv

2018-04-30 Thread Ken MacKenzie
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 that truly the preferred way.
Seems to make a new attack surface for anything in home.

The other option I am thinking is to create a dev-username location in
/usr/local somewhere and then ln -s that into my home structure accordingly.

Since I am new to OpenBSD I figured I would ask first and did not find much
on
this topic other than third parties that seem to want to casually just add
home
to wxallowed.

Thanks in advance for any guidance,

Ken