Hi Roberto,
I tried running the Emperor as root but it didn't seem to like it.
I get this error:
Dec 31 21:31:30 ip-172-20-12-105 uwsgi: spawned uWSGI master process (pid:
2313)
Dec 31 21:31:30 ip-172-20-12-105 uwsgi: error removing unix socket,
unlink(): Permission denied [core/socket.c line 198]
Dec 31 21:31:30 ip-172-20-12-105 uwsgi: bind(): Address already in use
[core/socket.c line 230]
Anyway, I've rebuilt with the patch applied and the build fails with:
core/emperor.c: In function 'uwsgi_emperor_spawn_vassal':
core/emperor.c:1188:16: error: initialization makes integer from pointer
without a cast [-Werror]
gid_t gid = NULL;
R.
On 31 December 2014 at 20:46, Roberto De Ioris <[email protected]> wrote:
>
> > Hi,
> >
> > I'm using uwsgi 2.0.9 on CentOS 7, built from the Fedora 21 2.0.7
> > packages.
> > SRPM and RPM are here: http://repo.yo61.net/el/7/
> >
> > uwsgi is run under systemd in emperor mode. This is the main config I'm
> > using (/etc/uwsgi.ini):
> >
> > [uwsgi]
> > uid = uwsgi
> > gid = uwsgi
> > pidfile = /run/uwsgi/uwsgi.pid
> > emperor = /etc/uwsgi.d
> > stats = /run/uwsgi/stats.sock
> > emperor-tyrant = true
> > emperor-tyrant-initgroups = true
> > cap = setgid,setuid
> >
> > I'm running the puppetboard app as a vassal with the following config
> > (/etc/uwsgi.d/puppetboard.ini):
> >
> > [uwsgi]
> > plugins = python
> > http-socket = :8080
> > wsgi-file = /var/www/puppetboard/wsgi.py
> > uid = puppetboard
> > gid = puppetboard
> > enable-threads = true
> > thunder-lock = true
> >
> > Ownership on puppetboard.ini is puppetboard:puppetboard
> >
> > The puppetboard user is also a member of the puppet group. This is so
> > puppetboard can read a cert key from /var/lib/puppet/ssl/private_keys/ as
> > there are directories in that path that are mode 0750 and with ownership
> > by
> > puppet:puppet
> >
> > However, the additional group is not getting set on the puppetboard.ini
> > app
> > processes - they just get puppetboard:puppetboard and consequently they
> > are
> > not able to read the puppet certs.
> >
> > From top:
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
> COMMAND
> > GROUP SUPGRPS
> > 1293 puppetb+ 20 0 333616 5864 1796 S 0.0 0.2 0:00.06 httpd
> > puppetb+ puppet,puppetboard
> > 1460 puppetb+ 20 0 243400 19352 5112 S 0.0 0.5 0:00.28 uwsgi
> > puppetb+ -
> > 1467 puppetb+ 20 0 249512 19072 3604 S 0.0 0.5 0:00.12 uwsgi
> > puppetb+ -
> >
> > The process that *does* have the correct supplementary groups is the same
> > app running under apache and mod_wsgi.
> >
> > Am I configuring this wrongly, or is this a bug?
> >
>
>
> --emperor-tyrant-initgroups is a 2.1 option
>
>
> by default the Emperor calls setgroups(0, NULL) that basically disables
> additional groups (this is the behaviour changed by
> --emperor-tyrant-initgroups)
>
> You can use uWSGI 2.1 only for the Emperor or apply this diff to 2.0:
>
>
> https://github.com/unbit/uwsgi/commit/ab506626580c8b68db5061d800fb5e8f04bfd852
>
> (it should be pretty readable even if you do not know uWSGI internals)
>
> The other solution is running the Emperor as root and let the single
> instance drop privileges (but this is obviously less 'secure' than tyrant
> mode + capabilities)
>
> --
> Roberto De Ioris
> http://unbit.com
> _______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
