Starting uWSGI server without sudo - flask

I'm trying to deploy my Flask app using uWSGI, but I can't seem to do it without sudo.
Here is my start script:
#!/bin/bash
set -v
set -e
cd /var/hpit/hpit_services
/var/hpit/hpit_services/env/bin/uwsgi --http [::]:80 --master --module wsgi --callable app --processes 4 --daemonize ../log/uwsgi.log --pidfile ../server_pid_file.pid
echo server started
Here is what I get in the logs:
*** Starting uWSGI 2.0.9 (64bit) on [Mon Jan 26 15:53:26 2015] ***
compiled with version: 4.8.2 on 23 January 2015 20:35:44
os: Linux-3.18.1-x86_64-linode50 #1 SMP Tue Jan 6 12:14:10 EST 2015
nodename: <<blocked out>>
machine: x86_64
clock source: unix
detected number of CPU cores: 2
current working directory: /var/hpit/hpit_services
writing pidfile to ../server_pid_file.pid
detected binary path: /var/hpit/hpit_services/env/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 7962
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
bind(): Permission denied [core/socket.c line 764]
Core/socket.c line 764 has this:
if (bind(serverfd, (struct sockaddr *) &uws_addr, addr_len) != 0) {
if (errno == EADDRINUSE) {
uwsgi_log("probably another instance of uWSGI is running on the same address (%s).\n", socket_name);
}
uwsgi_error("bind()");
uwsgi_nuclear_blast();
return -1;
}
But I don't have instances of uWSGI running. This seems to be a permissions issue. My permissions for /var/hpit, /var/hpit/hpit_services (the location of the app) and /var/hpit/log are bsauer:www-data. My user us bsauer.
If I append sudo -E to the line in my start script that calls the uWSGI binary, it seems to start fine, but I read that a server should not be started as sudo. I inherited this sysadmin role at work and am a little new to all of this.
Here are my hunches/musings:
I know that uWSGI can start as one user and drop into another user role, but I don't really understand this process, so perhaps that's the problem.
uWSGI is trying to access something on the system I'm not aware of
Thanks for your help, I can provide more details if necessary.
EDIT
Oddly, my /var/hpit/log/uwsgi.log file is owned by bsauer:bsauer, not bsauer:www-data or www-data:www-data as I would have expected...
EDIT2
Ok, from looking at http://projects.unbit.it/uwsgi/wiki/Example at the bottom of the page, it looks like the problem is running on port 80. I changed it to 8080, but its still running as bsauer, which I don't think I want.

This is what I came up with as far as I understand it, if anyone wants to put this is clearer sysadmin language I'll be happy to edit.
The solution had nothing to do with the logs after all. The problem was that port 80, the default HTTP port, is protected by the system, and only root can bind to that port. Without sudo, it won't let you bind. Binding to another port, like port 8080, worked fine.
I wanted to bind to port 80 but still run the server as www-data, so I ended up following the very bottom of this page: http://projects.unbit.it/uwsgi/wiki/Example . Basically, the socket to port 80 is shared, and uWSGI can access it first as sudo, and then drop down into www-data to run the server.
I still had to use sudo -E before calling the uWSGI binary, because it needs root permissions to change uWSGI's user and group ID, but it's ok because the end result is the server then runs in the very restricted www-data user.
In the end, my server start line was:
sudo -E /var/hpit/hpit_services/env/bin/uwsgi --shared-socket [::]:80 --http =0 --uid 33 --gid 33 --master --module wsgi --callable app --processes 4 --daemonize ../log/uwsgi.log --pidfile ../server_pid_file.pid

Related

How can I get uwsgi quickstart 'Hello World' to work on Digital Ocean?

The reason I asked this question is that every other question regarding the subject that I have seen on Stack Overflow is more complicated than mine. I am not trying to get uwsgi to work with anything else. I am simply trying to get the most basic implementation of it to actually do something.
I am following these instructions:
https://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html
My domain is called "prosaurus.com" and It's registered on Godaddy. I have hosting through Digital Ocean which has provided me with the following IP address: 143.198.142.59
In Digital Ocean I have set up two A records to point to the associated droplet/IP address. One is for "prosuaurus.com" the other is for "*.prosuarus.com"
I have followed the instructions exactly, opting for PIP to install uwsgi (as opposed to using wget and make).
I have created a file called 'foobar.py' as suggested and entered the suggested contents.
I have started the server as suggested on port 9090. This is the output I get:
uwsgi --http :9090 --wsgi-file foobar.py
*** Starting uWSGI 2.0.20 (64bit) on [Wed Sep 7 16:45:00 2022] ***
compiled with version: 11.2.0 on 02 September 2022 19:04:11
os: Linux-5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51:15 UTC 2022
nodename: ubuntu-s-1vcpu-1gb-intel-sfo3-01
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/deployer
detected binary path: /home/deployer/.local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 3721
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on :9090 fd 4
spawned uWSGI http 1 (pid: 59211)
uwsgi socket 0 bound to TCP address 127.0.0.1:46629 (port auto-assigned) fd 3
Python version: 3.10.4 (main, Jun 29 2022, 12:14:53) [GCC 11.2.0]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x55b300c4fb30
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72920 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x55b300c4fb30 pid: 59210 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 59210, cores: 1)
oba
Everything appears to have worked correctly. I saw no error messages in any of the above steps (There was one warning suggesting I should use a virtual environment but this was just a warning right?)
yet, I do not see my hello world page. I don't see it on http://prosaurus.com:9090 or http://www.prosaurus.com:9090 or http://143.198.142.59:9090
What could I have possibly missed?
Side note: This server does have nginx installed on it, however I specifically turned it off before this test.
Firewall...
sudo ufw allow 9090
It would have been nice if they had mentioned this possibility in the docs.

No welcome page after openCPU install in fresh Ubuntu 18.04 instance

I am trying to install OpenCPU 2.1 on a fresh free tier AWS server. I followed
[https://aws.amazon.com/getting-started/tutorials/?awsf.getting-started-content=use-case-tmt%23websites-apps], and launched a
Ubuntu Server 18.04 LTS (HVM), x86, free tier server, and obtained
public and private IP's. Then I follow [https://opencpu.github.io/server-manual/opencpu-server.pdf], section 2.2
sudo apt-get update
sudo apt-get upgrade
I respond to grub prompt to keep local version installed
sudo add-apt-repository ppa:opencpu/opencpu-2.1 -y
sudo apt-get update
sudo apt-get install opencpu-server
and OK to defaults on pop-up on mailname and smarthost prompts.
The results all look OK. The last section reads:
To activate the new configuration, you need to run:
systemctl restart apache2
Enabling opencpu in apache...
Reloading apparmor...
Restarting apache...
Installation done!
Setting up libxml-twig-perl (1:3.50-1) ...
Setting up libnet-dbus-perl (1.1.0-4build2) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Processing triggers for systemd (237-3ubuntu10.13) ...
Processing triggers for ureadahead (0.100.0-20) ...
Processing triggers for ufw (0.35-5) ...
When I then try to point my browser to http(s)://your.server.com/ocpu (of course with the the IP replaced by public IP I got from AWS, and using either http:// or https://), then I get a time-out in the browser window after a minute or so.
Checking sudo systemctl status apache2.service provides
● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/apache2.service.d
└─apache2-systemd.conf
Active: active (running) since Thu 2019-02-28 09:41:19 UTC; 1min 14s ago
Process: 30750 ExecStop=/usr/sbin/apachectl stop (code=exited, status=0/SUCCESS)
Process: 30755 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
Main PID: 30771 (apache2)
Tasks: 6 (limit: 1152)
CGroup: /system.slice/apache2.service
├─30771 /usr/sbin/apache2 -k start
├─30773 /usr/sbin/apache2 -k start
├─30774 /usr/sbin/apache2 -k start
├─30775 /usr/sbin/apache2 -k start
├─30776 /usr/sbin/apache2 -k start
└─30777 /usr/sbin/apache2 -k start
Feb 28 09:41:19 ip-zzz-zz-zz-zz systemd[1]: Stopped The Apache HTTP Server.
Feb 28 09:41:19 ip-zzz-zzz-zz-zz systemd[1]: Starting The Apache HTTP Server...
Feb 28 09:41:19 ip-zzz-zzz-zz-zz systemd[1]: Started The Apache HTTP Server.
which seems OK. Also, trying a restart:
sudo a2ensite opencpu
Site opencpu already enabled
does not activate the welcome page. Is there something else that needs to be activated or set?
First try to connect to the server locally to test if it running. On the server run:
curl --insecure http://localhost/ocpu/info
If you get a response with some info about the server, opencpu is running and the issue is likely the amazon security group is blocking HTTP traffic. See the section below on how to enable this.
On the other hand if the curl command above did not work (it gave a timeout erorr), there is a problem with the server and you need to check /var/log/apache2/error.log.
Enable HTTP(S) in the amazon security group (firewall)
If you still not connect from your browser, the issue is likely that your have not opened the http ports in your EC2 firewall (security group). To check this, open the EC2 management console in your browser and lookup the security group is associated with your EC2 instance. Then add inbound rules to this secruity group to allow port 80 and 443 from any host.
First lookup the security group that is associated with your instance:
And then add an inbound rule to allow port 80 (HTTP) and 443 (HTTPS):

Basic uwsgi configuration with Linode

I am following a tutorial on configuring Django, nginx and uwsgi.
https://gist.github.com/evildmp/3094281
The first part of which involves configuring uwsgi to run this python file
/home/ofey/djangoenv/bin/test.py
def application(env, start_response):
start_response('200 OK', [('Content-Type','text/html')])
return "Hello world"
djangoenv is the virtualenv directory.
It contains the binary uwsgi, which was installed to this environment using
$ pip install uwsgi
Just to note, I have stopped nginx with,
$ sudo systemctl stop nginx
and also stopped uwsgi which was running as a service with systemd.
$ sudo systemctl stop uwsgi
Running test.py and the output,
(djangoenv) [ofey#ofeyspi bin]$ uwsgi --http :8000 --master --wsgi-file test.py
*** Starting uWSGI 2.0.14 (64bit) on [Tue Nov 29 21:54:09 2016] ***
compiled with version: 6.2.1 20160916 (Red Hat 6.2.1-2) on 28 November 2016 14:39:40
os: Linux-4.8.6-x86_64-linode78 #1 SMP Tue Nov 1 14:51:21 EDT 2016
nodename: ofeyspi
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/ofey/djangoenv/bin
detected binary path: /home/ofey/djangoenv/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 7982
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on :8000 fd 4
uwsgi socket 0 bound to TCP address 127.0.0.1:41335 (port auto-assigned) fd 3
Python version: 2.7.12 (default, Sep 29 2016, 13:30:34) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0xb72990
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145520 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0xb72990 pid: 11493 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 11493)
spawned uWSGI worker 1 (pid: 11494, cores: 1)
spawned uWSGI http 1 (pid: 11495)
I would expect to see 'hello world' at http://qqiresources.com:8000
but nothing.
I do know that qqiresources.com is working because I see the nginx default homepage when I turn on nginx.
This is running on Linode with a virtual deployment of Fedora 24.
I did previously post a question trying to configure Django, wsgi and nginx on Linode but I think I need to figure out the above simpler situation first.
Linode Django uwsgi Nginx
Any help would be greatly appreciated,
Thanks

How do I run uWSGI as a limited-access user?

I have Django setup in NGINX + uWSGI. I'm able to get it running fine under my current logged in user (with help from a question I asked few days back) but now I want to run uwsgi --ini uwsgi.ini as a limited-access user.
Here is what I've done so far:
1. Created a user djangouser without login access and without a home directory.
2. Added user nginx into group djangouser
3. Placed my django files into /mnt/django directory and changed file permissions of django to drwxrwx--- djangouser djangouser (recursive)
4. Changed the conf files to match the file locations
uwsgi.ini file
[uwsgi]
chdir=/mnt/django/project/awssite
module=awssite.wsgi
home=/mnt/django/project
master=true
processes=2
uid=djangouser
gid=djangouser
socket=/mnt/django/djangosocket/awssite.socket
chmod-socket
vacuum=true
When I try to run uwsgi --ini uwsgi.ini, this is the error I get
[uWSGI] getting INI configuration from uwsgi.ini
*** Starting uWSGI 2.0.12 (64bit) on [Thu Feb 18 00:18:25 2016] ***
compiled with version: 4.8.3 20140911 (Red Hat 4.8.3-9) on 01 February 2016 04:17:11
os: Linux-4.1.13-19.31.amzn1.x86_64 #1 SMP Wed Jan 20 00:25:47 UTC 2016
nodename: ip-10-200-1-89
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/ec2-user
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
chdir() to /mnt/django/project/awssite
chdir(): Permission denied [core/uwsgi.c line 2586]
chdir(): Permission denied [core/uwsgi.c line 1608]
Note: When I added my logged in user to djangouser group, uwsgi --ini uwsgi.ini ran fine and I was able to load the django pages.
I'm not sure where else to add permissions to allow this to work. Adding sudo chown-socket=djangouser:djangouser in uwsgi.ini didn't work either.
I appreciate the help :)
If you want to run uWSGI as particular user, there are only 2 options:
run uWSGI server directly from this user
run uWSGI as root and add uid and gid options.
You can create a user and set the uid/gid properties in your uwsgi ini file.
[uwsgi]
...
uid=myuser
gid=mygroup
I tested this with uwsgi version 2.0.12-debian and it worked for a simple cgi app using a python3 virtualenv.
http://uwsgi-docs.readthedocs.io/en/latest/Options.html#uid

Starting uWSGI service fails silently

I'm having a problem which is driving me nuts. I'm trying to create an Ubuntu 15.04 Upstart job, which would start uWSGI server (uWSGI version 2.0.7-debian) running a Django application.
I've configured the service as a follows and try to start the job by issuing command $ sudo service uwsgi start. There is no output in log files, no socket file created and no error.
# file: /etc/init/uwsgi.conf
description "uWSGI server"
start on runlevel [2345]
stop on runlevel [!2345]
exec /usr/bin/uwsgi --ini /srv/configs/uwsgi.ini
service uwsgi status says
● uwsgi.service - LSB: Start/stop uWSGI server instance(s)
Loaded: loaded (/etc/init.d/uwsgi)
Active: active (exited) since Tue 2015-05-05 09:40:08 EEST; 1s ago
Docs: man:systemd-sysv-generator(8)
Process: 21405 ExecStop=/etc/init.d/uwsgi stop (code=exited, status=0/SUCCESS)
Process: 21460 ExecStart=/etc/init.d/uwsgi start (code=exited, status=0/SUCCESS)
May 05 09:40:08 web-2 systemd[1]: Starting LSB: Start/stop uWSGI server instance(s)...
May 05 09:40:08 web-2 uwsgi[21460]: * Starting app server(s) uwsgi
May 05 09:40:08 web-2 uwsgi[21460]: ...done.
May 05 09:40:08 web-2 systemd[1]: Started LSB: Start/stop uWSGI server instance(s).
The uWSGI app is configured as
[uwsgi]
uid = www-data
gid = www-data
socket = /srv/sockets/uwsgi.sock
chmod-socket = 666
master = true
processes = 4
enable-threads = true
plugins = python
chdir = /srv/sites/current
module = wsgi:application
virtualenv = /srv/environments/current
logto = /srv/logs/uwsgi.log
logfile-chown = true
touch-reload = /srv/sites/current/wsgi.py
The service starts fine and everything works ok if the service is started directly, e.g. by issuing command:
sudo -u www-data /usr/bin/uwsgi --ini /srv/configs/uwsgi.ini
For the socket dir and log files directories I've set the most relaxed permissions.
So, I'm at a loss. What to do next?
Thanks to nmgeeks comment, I started looking at other places where uWSGI is configured.
While trying to move everything our own app related under /srv I deleted /run/uwsgi directory, where uWSGI is trying to create a PID file.
You can find the reference at /usr/share/uwsgi/conf/default.ini.
Too bad uWSGI doesn't produce any error in this situation, which left me frustrated for a day.
I just want to put some additional details. In my case I didn't delete anything, but, for some reasons, systemd was not able to create /run/uwsgi directory. So, I did echo "/run/uwsgi 0755 www-data www-data -" > /etc/tmpfiles.d/uwsgi.conf. After that I restarted my VM (I didn't find a way to apply this changes without restarting) and uwsgi started to work!
Yes, it's too bad that uWSGI doesn't produce any error in this situation.