[devel] Упаковка python-приложение

[devel] Упаковка python-приложение

[Eugene Prokopiev]

Здравствуйте!

Покажите пожалуйста на примере
http://git.altlinux.org/people/enp/packages/webvirtmgr.git показать, в
чем моя ошибка в упаковке python-приложения?

Основной вопрос: почему модули устанавливаются в
/usr/lib/python2.7/site-packages, однако при этом %python_sitelibdir
указывает на usr/lib64/python2.7/site-packages? И требуется ли
python-module- в качестве префикса именно для приложения (а не для
модулей, которые могут быть кем-то еще использованы)?

Есть ли актуальное полиси, в котором это все было бы описано?

-- 
WBR,
Eugene Prokopiev

Re: [devel] Упаковка python-приложение

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

Здравствуйте!

On Thu, 7 Jul 2016, Eugene Prokopiev wrote:

> Покажите пожалуйста на примере
> http://git.altlinux.org/people/enp/packages/webvirtmgr.git показать, в
> чем моя ошибка в упаковке python-приложения?
>
> Основной вопрос: почему модули устанавливаются в
> /usr/lib/python2.7/site-packages, однако при этом %python_sitelibdir
> указывает на usr/lib64/python2.7/site-packages? И требуется ли
> python-module- в качестве префикса именно для приложения (а не для
> модулей, которые могут быть кем-то еще использованы)?

Тут похожий вопрос проскакивал недавно. Проще всего должно быть сделать 
этот подпакет noarch, и тогда путь будет установлен соответствующий. (Если 
содержимое действительно noarch.)

(Я когда в связи с такими вопросами задумываюсь, мне кажется, что в 
упаковке питоновских штук происходит сдвиг по сравнению с обычной 
ситуацией: вместо /usr/share/ для noarch кладут в /usr/lib/pythonNN/, а 
вот для 64 (но не i586) есть отдельная /usr/lib64/pythonNN/. И на эту тему 
в sisyphus_check проверка, эмулирующая обычную проверку arch vs noarch 
упаковки -- из-за нестандартной семантики путей.)

> Есть ли актуальное полиси, в котором это все было бы описано?

Полностью актуального документа нет. Но в целом общая идея такая же, как 
записано на wiki, в sisyphus_check.

Мои недавние изменения в rpm-build-python3 и sisyphus_check мало что 
меняют для пишущего спек. Про автозависмости в пакетах с питоном в 
нестандартных местах я писал тут письмо (при обсуждении gedit). А для 2.7 
я ещё меньше менял.

-- 
Best regards,
Ivan

Re: [devel] Упаковка python-приложение

[Антон Мидюков]

07.07.2016 15:41, Eugene Prokopiev пишет:
> Здравствуйте!
>
> Покажите пожалуйста на примере
> http://git.altlinux.org/people/enp/packages/webvirtmgr.git показать, в
> чем моя ошибка в упаковке python-приложения?
Секция files не прописана. Если это приложение, а не модуль, должен же 
быть и %_bindir ?
> Основной вопрос: почему модули устанавливаются в
> /usr/lib/python2.7/site-packages, однако при этом %python_sitelibdir
> указывает на usr/lib64/python2.7/site-packages?
Модуль noarch. Нужно указать BuildArch: noarch как в примере 
https://www.altlinux.org/SampleSpecs/pythonmodule
>   И требуется ли
> python-module- в качестве префикса именно для приложения (а не для
> модулей, которые могут быть кем-то еще использованы)?
Для приложения не требуется указывать. Но вы можете подпакет модуля 
вынести, собрав его и с python и с python3. Вот вам пример: 
https://packages.altlinux.org/en/Sisyphus/srpms/youtube-dl/spec

-- 
С уважением Антон Мидюков <antohami@altlinux.org>

Re: [devel] Упаковка python-приложение

[Eugene Prokopiev]

7 июля 2016 г., 12:38 пользователь Ivan Zakharyaschev
<imz@altlinux.org> написал:

>> Основной вопрос: почему модули устанавливаются в
>> /usr/lib/python2.7/site-packages, однако при этом %python_sitelibdir
>> указывает на usr/lib64/python2.7/site-packages? И требуется ли
>> python-module- в качестве префикса именно для приложения (а не для
>> модулей, которые могут быть кем-то еще использованы)?
>
>
> Тут похожий вопрос проскакивал недавно. Проще всего должно быть сделать этот
> подпакет noarch, и тогда путь будет установлен соответствующий. (Если
> содержимое действительно noarch.)

Да, спасибо, помогло. Однако в результате %python_install я получаю:

$ ls ~/build/chroot/usr/src/tmp/webvirtmgr-buildroot/usr/lib/python2.7/site-packages/
console  create  hostdetail  instance  interfaces  networks  secrets
serverlog  servers  storages  vrtManager  webvirtmgr
webvirtmgr-4.8.9-py2.7.egg-info

У меня такое ощущение, что это не очень правильно - складывать такую
кучу (которая вполне может конфликтовать с другими пакетами) прямо в
%python_sitelibdir. Есть ли простой способ отучить приложение от
этого?

>> Есть ли актуальное полиси, в котором это все было бы описано?
>
>
> Полностью актуального документа нет. Но в целом общая идея такая же, как
> записано на wiki, в sisyphus_check.

А дайте ссылку пожалуйста

-- 
WBR,
Eugene Prokopiev

Re: [devel] Упаковка python-приложение

[Eugene Prokopiev]

7 июля 2016 г., 13:30 пользователь Антон Мидюков <midyukov-anton@ya.ru> написал:

>> Основной вопрос: почему модули устанавливаются в
>> /usr/lib/python2.7/site-packages, однако при этом %python_sitelibdir
>> указывает на usr/lib64/python2.7/site-packages?
>
> Модуль noarch. Нужно указать BuildArch: noarch как в примере
> https://www.altlinux.org/SampleSpecs/pythonmodule

О! Спасибо, именно это мне было нужно. Я исправил спек, однако в
%python_sitelibdir оказалось слишком много - см. мое предыдущее
письмо.

--
WBR,
Eugene Prokopiev

Re: [devel] Упаковка python-приложение

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On Thu, 7 Jul 2016, Eugene Prokopiev wrote:

> Да, спасибо, помогло. Однако в результате %python_install я получаю:
>
> $ ls ~/build/chroot/usr/src/tmp/webvirtmgr-buildroot/usr/lib/python2.7/site-packages/
> console  create  hostdetail  instance  interfaces  networks  secrets
> serverlog  servers  storages  vrtManager  webvirtmgr
> webvirtmgr-4.8.9-py2.7.egg-info
>
> У меня такое ощущение, что это не очень правильно - складывать такую
> кучу (которая вполне может конфликтовать с другими пакетами) прямо в
> %python_sitelibdir. Есть ли простой способ отучить приложение от
> этого?

Не знаю. (Не разбираюсь особенно во внутренностях setup-tools и т.п., но 
по мере работы приходится что-то узнавать о них.)

Будем надеяться на чей-нибудь ещё совет.

>>> Есть ли актуальное полиси, в котором это все было бы описано?
>>
>>
>> Полностью актуального документа нет. Но в целом общая идея такая же, как
>> записано на wiki, в sisyphus_check.
>
> А дайте ссылку пожалуйста

http://git.altlinux.org/gears/r/rpm-build-python.git?p=rpm-build-python.git;a=tree;f=rpm-build-python/policy;h=9aa241594152ad0a3179e8a501cf6fd0c952ed4c;hb=HEAD

-- 
Best regards,
Ivan

Re: [devel] Упаковка python-приложение

[Eugene Prokopiev]

7 июля 2016 г., 14:35 пользователь Ivan Zakharyaschev
<imz@altlinux.org> написал:

> Будем надеяться на чей-нибудь ещё совет.

Совет нашелся в спеке для RHEL:ямо

%install
%{__python} setup.py install --skip-build
--install-lib=%{python_sitelib}/%{name} --root %{buildroot}
опытки
Однако дальше в спеке предполагается, что приложение будет запускаться
в %python_sitelibdir/%name прямо от рута.

Попытки запускать приложение не от рута упираются сначала в:

IOError: [Errno 13] Permission denied:
'/usr/lib/python2.7/site-packages/webvirtmgr/webvirtmgr/local/.secret_key_store'

а после chmod в:

webvirtmgr.utils.secret_key.FilePermissionError: Insecure key file permissions!

Похоже, что опакечивание django-приложений - еще один случай, когда
овчинка выделки не стоит :(

-- 
WBR,
Eugene Prokopiev

Re: [devel] Упаковка python-приложение

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 956 bytes --]

On Fri, 8 Jul 2016, Eugene Prokopiev wrote:

> Совет нашелся в спеке для RHEL:ямо
>
> %install
> %{__python} setup.py install --skip-build
> --install-lib=%{python_sitelib}/%{name} --root %{buildroot}

У нас %python_sitelibdir

> опытки
> Однако дальше в спеке предполагается, что приложение будет запускаться
> в %python_sitelibdir/%name прямо от рута.
>
> Попытки запускать приложение не от рута упираются сначала в:

От обычного пользователя-человека или от специального для сервера?

> IOError: [Errno 13] Permission denied:
> '/usr/lib/python2.7/site-packages/webvirtmgr/webvirtmgr/local/.secret_key_store'

Ну данные по-хорошему должны быть где-то в $HOME или /var/lib/%name/

> а после chmod в:
>
> webvirtmgr.utils.secret_key.FilePermissionError: Insecure key file permissions!
>
> Похоже, что опакечивание django-приложений - еще один случай, когда
> овчинка выделки не стоит :(

Возможно, да, сделать это удобно не просто.

-- 
Best regards,
Ivan

Re: [devel] Упаковка python-приложение

[Alexey Shabalin]

> Похоже, что опакечивание django-приложений - еще один случай, когда
> овчинка выделки не стоит :(

мне на память приходят пара пакетов django-приложений:
python-module-django-horizon и noc.
Посмотри, может что-то поможет.

-- 
Alexey Shabalin

Re: [devel] Упаковка python-приложение

[Alexey Shabalin]

8 июля 2016 г., 13:27 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:
>> Похоже, что опакечивание django-приложений - еще один случай, когда
>> овчинка выделки не стоит :(
>
> мне на память приходят пара пакетов django-приложений:
> python-module-django-horizon и noc.
> Посмотри, может что-то поможет.

Я на основе твоего репо переделал пакет.
Посмотри у меня в git.
пара вариантов на выбор: apache2+mod_wsgi или nginx+gunicorn
Я ближайшую неделю проверить не смогу, если проверите и отпишитесь,
будет здорово.


-- 
Alexey Shabalin

Re: [devel] Упаковка python-приложение

[Eugene Prokopiev]

29 ноября 2016 г., 21:45 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:
> 8 июля 2016 г., 13:27 пользователь Alexey Shabalin
> <a.shabalin@gmail.com> написал:
>>> Похоже, что опакечивание django-приложений - еще один случай, когда
>>> овчинка выделки не стоит :(
>>
>> мне на память приходят пара пакетов django-приложений:
>> python-module-django-horizon и noc.
>> Посмотри, может что-то поможет.
>
> Я на основе твоего репо переделал пакет.
> Посмотри у меня в git.
> пара вариантов на выбор: apache2+mod_wsgi или nginx+gunicorn
> Я ближайшую неделю проверить не смогу, если проверите и отпишитесь,
> будет здорово.

Попробовал собрать и установить webvirtmgr и webvirtmgr-gunicorn.
Замечания такие:

1) нужно добавить openssl в зависимости, у меня его не оказалось
2) сервис webvirtmgr не рабочий:

# systemctl status webvirtmgr
● webvirtmgr.service - WebVirtMgr Gunicorn Server
   Loaded: loaded (/lib/systemd/system/webvirtmgr.service; disabled;
vendor preset: disabled)
   Active: failed (Result: exit-code) since Ср 2016-11-30 10:38:46 MSK; 4s ago
  Process: 1486 ExecStart=/usr/bin/gunicorn --pid
/var/run/webvirtmgr/webvirtmgr.pid --bind
unix:/var/run/webvirtmgr/socket -c /etc/webvirtmgr/gunicorn.conf.py
/usr/share/webvirtmgr/webvirtmgr/wsgi.py (code=exited, status=217
 Main PID: 1486 (code=exited, status=217/USER)

Started WebVirtMgr Gunicorn Server.
webvirtmgr.service: Main process exited, code=exited, status=217/USER
webvirtmgr.service: Unit entered failed state.
webvirtmgr.service: Failed with result 'exit-code'.

В моем рабочем рабочий юните запуск выглядит проще:

WorkingDirectory=/home/kvm/webvirtmgr
ExecStart=/usr/bin/gunicorn -b 127.0.0.1 webvirtmgr.wsgi:application

Дальше не смотрел, потому что пока нет практической необходимости, у
меня webvirtmgr работает из домашней директории, а следующей
инсталляции пока не предвидится. Впрочем с тестированием до состояния
"подключились и увидели виртуальные машины" помочь могу.

-- 
WBR,
Eugene Prokopiev

Re: [devel] Упаковка python-приложение

[Alexey Shabalin]

30 ноября 2016 г., 10:59 пользователь Eugene Prokopiev <enp@itx.ru> написал:
> 29 ноября 2016 г., 21:45 пользователь Alexey Shabalin
> <a.shabalin@gmail.com> написал:
>> 8 июля 2016 г., 13:27 пользователь Alexey Shabalin
>> <a.shabalin@gmail.com> написал:
>>>> Похоже, что опакечивание django-приложений - еще один случай, когда
>>>> овчинка выделки не стоит :(
>>>
>>> мне на память приходят пара пакетов django-приложений:
>>> python-module-django-horizon и noc.
>>> Посмотри, может что-то поможет.
>>
>> Я на основе твоего репо переделал пакет.
>> Посмотри у меня в git.
>> пара вариантов на выбор: apache2+mod_wsgi или nginx+gunicorn
>> Я ближайшую неделю проверить не смогу, если проверите и отпишитесь,
>> будет здорово.
>
> Попробовал собрать и установить webvirtmgr и webvirtmgr-gunicorn.
> Замечания такие:

сделал еще один заход на упаковку.
смотри git.

> 1) нужно добавить openssl в зависимости, у меня его не оказалось
теперь уже не надо. убрал этот хак.

> 2) сервис webvirtmgr не рабочий:
сейчас запускается.
Вот только увидел интересную особенность, раньше с таким не встречался.
webvirtmgr.socket - определяет где слушать. Сейчас указал сокет и 127.0.0.0:8000
webvirtmgr.service - ничего не указываю, где слушать. Даже если
указать( -b 127.0.0.0:8001) - игнорируется. Странно.

если особых возражений нет, давай пошлю в сизиф.

>
> # systemctl status webvirtmgr
> ● webvirtmgr.service - WebVirtMgr Gunicorn Server
>    Loaded: loaded (/lib/systemd/system/webvirtmgr.service; disabled;
> vendor preset: disabled)
>    Active: failed (Result: exit-code) since Ср 2016-11-30 10:38:46 MSK; 4s ago
>   Process: 1486 ExecStart=/usr/bin/gunicorn --pid
> /var/run/webvirtmgr/webvirtmgr.pid --bind
> unix:/var/run/webvirtmgr/socket -c /etc/webvirtmgr/gunicorn.conf.py
> /usr/share/webvirtmgr/webvirtmgr/wsgi.py (code=exited, status=217
>  Main PID: 1486 (code=exited, status=217/USER)
>
> Started WebVirtMgr Gunicorn Server.
> webvirtmgr.service: Main process exited, code=exited, status=217/USER
> webvirtmgr.service: Unit entered failed state.
> webvirtmgr.service: Failed with result 'exit-code'.
>
> В моем рабочем рабочий юните запуск выглядит проще:
>
> WorkingDirectory=/home/kvm/webvirtmgr
> ExecStart=/usr/bin/gunicorn -b 127.0.0.1 webvirtmgr.wsgi:application
>
> Дальше не смотрел, потому что пока нет практической необходимости, у
> меня webvirtmgr работает из домашней директории, а следующей
> инсталляции пока не предвидится. Впрочем с тестированием до состояния
> "подключились и увидели виртуальные машины" помочь могу.
>
> --
> WBR,
> Eugene Prokopiev



-- 
Alexey Shabalin

Re: [devel] Упаковка python-приложение

[Eugene Prokopiev]

8 декабря 2016 г., 17:45 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:

> сделал еще один заход на упаковку.
> смотри git.

При установке:

# apt-get install webvirtmgr-4.8.9-alt2.noarch.rpm
webvirtmgr-gunicorn-4.8.9-alt2.noarch.rpm
...
43: python-module-websockify

###################################[ 86%]
warning: user webvirtmgr does not exist - using root
44: webvirtmgr

###################################[ 88%]
45: python-module-paste

################################### [ 90%]

И пользователя webvirtmgr нету, а группа есть.

Создал руками, потом:

-- Начат процесс запуска юнита webvirtmgr.socket.
дек 09 09:42:01 localhost systemd[1008]: Failed to chown socket at
step GROUP: No such process
дек 09 09:42:01 localhost systemd[1]: webvirtmgr.socket: Control
process exited, code=exited status=216
дек 09 09:42:01 localhost systemd[1]: Failed to listen on WebVirtMgr
Gunicorn socket.
-- Subject: Ошибка юнита webvirtmgr.socket

При запуске руками ругается так:

IOError: [Errno 2] No such file or directory:
'/var/lib/webvirtmgr/.secret_key_store'

Ну и:

$ rpm -qli webvirtmgr | grep /var
/var/log/webvirtmgr
/var/run/webvirtmgr
$ rpm -q webvirtmgr
webvirtmgr-4.8.9-alt2

-- 
WBR,
Eugene Prokopiev

Re: [devel] Упаковка python-приложение

[Alexey Shabalin]

9 декабря 2016 г., 9:57 пользователь Eugene Prokopiev <enp@itx.ru> написал:
> 8 декабря 2016 г., 17:45 пользователь Alexey Shabalin
> <a.shabalin@gmail.com> написал:
>
>> сделал еще один заход на упаковку.
>> смотри git.
>
> При установке:
>
> # apt-get install webvirtmgr-4.8.9-alt2.noarch.rpm
> webvirtmgr-gunicorn-4.8.9-alt2.noarch.rpm
> ...
> 43: python-module-websockify
>
> ###################################[ 86%]
> warning: user webvirtmgr does not exist - using root
> 44: webvirtmgr
>
> ###################################[ 88%]
> 45: python-module-paste
>
> ################################### [ 90%]
>
> И пользователя webvirtmgr нету, а группа есть.
>
> Создал руками, потом:

поправил создание пользователя.

> -- Начат процесс запуска юнита webvirtmgr.socket.
> дек 09 09:42:01 localhost systemd[1008]: Failed to chown socket at
> step GROUP: No such process
> дек 09 09:42:01 localhost systemd[1]: webvirtmgr.socket: Control
> process exited, code=exited status=216
> дек 09 09:42:01 localhost systemd[1]: Failed to listen on WebVirtMgr
> Gunicorn socket.
> -- Subject: Ошибка юнита webvirtmgr.socket
>
> При запуске руками ругается так:
>
> IOError: [Errno 2] No such file or directory:
> '/var/lib/webvirtmgr/.secret_key_store'
потому что должна быть директория /var/lib/webvirtmgr/, как домашняя у
пользователя webvirtmgr

попробуй еще раз.

>
> Ну и:
>
> $ rpm -qli webvirtmgr | grep /var
> /var/log/webvirtmgr
> /var/run/webvirtmgr
> $ rpm -q webvirtmgr
> webvirtmgr-4.8.9-alt2

-- 
Alexey Shabalin

Re: [devel] Упаковка python-приложение

[Eugene Prokopiev]

> попробуй еще раз.

И снова пользователя создать не удалось, однако я нашел причину: у
меня не было группы _webserver. Впрочем она появляется с установкой
nginх, так что может это и не совсем ошибка.

Хуже то, что демон все же не работает. Он запускается, но при логине
получаю 500 internal server error, в логе регулярно появляется:

дек 09 16:49:32 localhost gunicorn[1696]: [2016-12-09 13:49:32 +0000]
[2185] [ERROR] Exception in worker process:
дек 09 16:49:32 localhost gunicorn[1696]: Traceback (most recent call last):
дек 09 16:49:32 localhost gunicorn[1696]:   File
"/usr/lib/python2.7/site-packages/gunicorn/arbiter.py", line 503, in
spawn_worker
дек 09 16:49:32 localhost gunicorn[1696]:     worker.init_process()
дек 09 16:49:32 localhost gunicorn[1696]:   File
"/usr/lib/python2.7/site-packages/gunicorn/workers/base.py", line 122,
in init_process
дек 09 16:49:32 localhost gunicorn[1696]:     self.run()
дек 09 16:49:32 localhost gunicorn[1696]:   File
"/usr/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 116,
in run
дек 09 16:49:32 localhost gunicorn[1696]:     self.run_for_multiple(timeout)
дек 09 16:49:32 localhost gunicorn[1696]:   File
"/usr/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 94,
in run_for_multiple
дек 09 16:49:32 localhost gunicorn[1696]:     for listener in ready:
дек 09 16:49:32 localhost gunicorn[1696]: TypeError: 'NoneType' object
is not iterable
дек 09 16:49:32 localhost gunicorn[1696]: Traceback (most recent call last):
дек 09 16:49:32 localhost gunicorn[1696]:   File
"/usr/lib/python2.7/site-packages/gunicorn/arbiter.py", line 503, in
spawn_worker
дек 09 16:49:32 localhost gunicorn[1696]:     worker.init_process()
дек 09 16:49:32 localhost gunicorn[1696]:   File
"/usr/lib/python2.7/site-packages/gunicorn/workers/base.py", line 122,
in init_process
дек 09 16:49:32 localhost gunicorn[1696]:     self.run()
дек 09 16:49:32 localhost gunicorn[1696]:   File
"/usr/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 116,
in run
дек 09 16:49:32 localhost gunicorn[1696]:     self.run_for_multiple(timeout)
дек 09 16:49:32 localhost gunicorn[1696]:   File
"/usr/lib/python2.7/site-packages/gunicorn/workers/sync.py", line 94,
in run_for_multiple
дек 09 16:49:32 localhost gunicorn[1696]:     for listener in ready:
дек 09 16:49:32 localhost gunicorn[1696]: TypeError: 'NoneType' object
is not iterable
дек 09 16:49:32 localhost gunicorn[1696]: [2016-12-09 13:49:32 +0000]
[2185] [INFO] Worker exiting (pid: 2185)
дек 09 16:49:32 localhost gunicorn[1696]: [2016-12-09 16:49:32 +0000]
[2188] [INFO] Booting worker with pid: 2188


-- 
WBR,
Eugene Prokopiev

Re: [devel] Упаковка python-приложение

[Alexey Shabalin]

9 декабря 2016 г., 16:50 пользователь Eugene Prokopiev <enp@itx.ru> написал:
>> попробуй еще раз.
>
> И снова пользователя создать не удалось, однако я нашел причину: у
> меня не было группы _webserver. Впрочем она появляется с установкой
> nginх, так что может это и не совсем ошибка.
В принципе можно обойтись и без группы _webserver. Тогда надо
webvirtmgr запускать только на порту, без сокета. Группа нужна что бы
nginx мог добраться до сокета.
Не рекомендуют gunicorn использовать как http-сервер. Хотя и возможно.

В общем тут получается слишком много вариантов запуска
django-приложения, все предусмотреть не получится. Надо выбрать что-то
одно.
Я задумывал 2 варианта: apachw+mod-wsgi и nginx+gunicorn. Про
standalone gunicorn я не думал.

> Хуже то, что демон все же не работает. Он запускается, но при логине
> получаю 500 internal server error, в логе регулярно появляется:
Я надеюсь что ты посмотрел /etc/webvirtmgr/local_settings и создал
базу, как описано в документации
su -s /bin/bash - webvirtmgr
cd /usr/share/webvirtmgr/
./manage.py syncdb

-- 
Alexey Shabalin

Re: [devel] Упаковка python-приложение

[Eugene Prokopiev]

9 декабря 2016 г., 17:34 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:
> 9 декабря 2016 г., 16:50 пользователь Eugene Prokopiev <enp@itx.ru> написал:
>>> попробуй еще раз.
>>
>> И снова пользователя создать не удалось, однако я нашел причину: у
>> меня не было группы _webserver. Впрочем она появляется с установкой
>> nginх, так что может это и не совсем ошибка.
> В принципе можно обойтись и без группы _webserver. Тогда надо
> webvirtmgr запускать только на порту, без сокета. Группа нужна что бы
> nginx мог добраться до сокета.
> Не рекомендуют gunicorn использовать как http-сервер. Хотя и возможно.
>
> В общем тут получается слишком много вариантов запуска
> django-приложения, все предусмотреть не получится. Надо выбрать что-то
> одно.
> Я задумывал 2 варианта: apachw+mod-wsgi и nginx+gunicorn. Про
> standalone gunicorn я не думал.

Для "потрогать" standalone gunicorn - самый очевидный вариант :)

>> Хуже то, что демон все же не работает. Он запускается, но при логине
>> получаю 500 internal server error, в логе регулярно появляется:
> Я надеюсь что ты посмотрел /etc/webvirtmgr/local_settings и создал
> базу, как описано в документации
> su -s /bin/bash - webvirtmgr
> cd /usr/share/webvirtmgr/
> ./manage.py syncdb

Нет, хотя должен был догадаться. Вообще хорошо бы создавать БД при
установке пакета :)

Но с созданием БД проблема не решилась (да и сообщения были не о БД) :(

Вообще webvirtmgr разрабатывался, как я понял, под предыдущую версию
django, а с нашей текущей даже в /home работать не хотел, для решения
проблемы я оформил в виде коммитов несколько советов из багтрекера
проекта - однако автор мои пулл-реквесты принимать не торопится,
свежих коммитов нет, проект производит впечатление заброшенного :(

Впрочем, мои "патчи" - это затычки, самым грубым образом адаптирующие
код к новому API django, графики потребления ресурсов я уже с моими
познаниями в python/django починить не в состоянии.

-- 
WBR,
Eugene Prokopiev