Postgres to Ubuntu Docker container linking not working - django

[EDIT]: I'm able to reproduce this without any of my own custom code. I just created a fresh Linode image running Ubuntu 14.04 and installed Docker according to the steps on Docker's website.
I then ran:
docker run -d --name db postgres
and can see it running:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9d335e8fc70b postgres "/docker-entrypoint. 7 minutes ago Up 7 minutes 5432/tcp db
Then I start an interactive Ubuntu container, linked to db, and try to test the link via nc and curl:
$docker run -it --link db ubuntu /bin/bash
root#eb02f4e7b89e:/# apt-get install curl
...
root#eb02f4e7b89e:/# curl http://$DB_PORT_5432_TCP_ADDR:$DB_PORT_5432_TCP_PORT/
curl: (7) Failed to connect to 172.17.0.2 port 5432: Connection timed out
What am I missing?
I'm trying to link a postgres container with an app container running Django but it doesn't seem to be linking properly.
The commands to start the containers were:
$ docker run -d --name db postgres
$ docker run -d --name web --link db -p 8000:80 test_image
Both containers appear to be running fine:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5838047eb14c test_image "/test/.docker/st 40 minutes ago Up 40 minutes 0.0.0.0:8000->80/tcp web
d2d6754430a2 postgres "/docker-entrypoint. 44 minutes ago Up 44 minutes 5432/tcp db
And seem to be correctly linked:
$ docker inspect -f "{{ .HostConfig.Links }}" web
[/db:/web/db]
However, when I try to run "python manage.py migrate" in the web container it doesn't seem to be able to connect to the postgres container:
# python manage.py migrate
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py", line 93, in handle
executor = MigrationExecutor(connection, self.migration_progress_callback)
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/executor.py", line 19, in __init__
self.loader = MigrationLoader(self.connection)
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/loader.py", line 47, in __init__
self.build_graph()
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/loader.py", line 180, in build_graph
self.applied_migrations = recorder.applied_migrations()
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/recorder.py", line 59, in applied_migrations
self.ensure_schema()
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/recorder.py", line 49, in ensure_schema
if self.Migration._meta.db_table in self.connection.introspection.table_names(self.connection.cursor()):
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 164, in cursor
cursor = self.make_cursor(self._cursor())
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 135, in _cursor
self.ensure_connection()
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 130, in ensure_connection
self.connect()
File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 97, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 130, in ensure_connection
self.connect()
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 119, in connect
self.connection = self.get_new_connection(conn_params)
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/postgresql_psycopg2/base.py", line 172, in get_new_connection
connection = Database.connect(**conn_params)
File "/usr/lib/python2.7/dist-packages/psycopg2/__init__.py", line 179, in connect
connection_factory=connection_factory, async=async)
django.db.utils.OperationalError: could not connect to server: Connection timed out
Is the server running on host "db" (172.17.0.42) and accepting
TCP/IP connections on port 5432?
I'm able to connect to the postgres container directly:
$ docker exec -it db bash
root#d2d6754430a2:/# cat /etc/hosts
172.17.0.42 d2d6754430a2
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
root#d2d6754430a2:/# su postgres
$ psql
psql (9.4.4)
Type "help" for help.
postgres=#
But not from inside the web container:
# curl http://$DB_PORT_5432_TCP_ADDR:$DB_PORT_5432_TCP_PORT/
curl: (7) Failed to connect to 172.17.0.42 port 5432: Connection timed out
My host machine is running Ubuntu 14.04.
Any ideas what I'm missing?

Check that your postgresql.conf has listen_addresses = '*'
The default is listen_addresses = 'localhost', which would behave in the manner you describe.
Edit:
This works for me, does it work for you?
$ docker pull postgres
$ docker pull django
$ docker run -d --name db -d postgres
$ docker run -it --link db:db django bash
root#11c767bd3d09:/# psql -h db -U postgres
psql (9.4.3, server 9.4.4)
Type "help" for help.
postgres=#
Edit (Docker 1.7.1 output)
$ docker rm $(docker ps -a -q)
$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
django latest 29755dd6751b 3 days ago 434.5 MB
postgres latest f33438ff9aef 3 days ago 265.5 MB
$ docker -v
Docker version 1.7.1, build 786b29d
$ docker run -d --name db -d postgres
$ docker run -it --link db:db django bash
root#11c767bd3d09:/# psql -h db -U postgres
psql (9.4.3, server 9.4.4)
Type "help" for help.
postgres=#

Related

Unable to run migrations for a django web service with postgresql backend through docker

I am trying to grow on a bookstore project mentioned in the book titled
Django for Professionals by Vincent
As I try to grow on it my requirements.txt has grown to
asgiref==3.5.2
Django==4.0.4
psycopg2-binary==2.9.3
sqlparse==0.4.2
django-crispy-forms==1.14.0
crispy-bootstrap5==0.6
django-allauth==0.50.0
with my Dockerfile as
FROM python:3.8-slim-bullseye
# set environment variables
ENV PIP_DISABLE_PIP_VERSION_CHECK 1
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1
# # Set working directory
WORKDIR /code
# # Installing python dependencies
COPY ./requirements.txt .
RUN pip install -r requirements.txt
and my docker-compose.yml as
# Mentioning which format of dockerfile
version: "3.9"
# services or nicknamed the container
services:
# web service for the web
web:
# you should use the --build flag for every node package added
build: .
# Add additional commands for webpack to 'watch for changes and bundle it to production'
command: python manage.py runserver 0.0.0.0:8000
volumes:
- type: bind
source: .
target: /code
ports:
- "8000:8000"
depends_on:
- db
environment:
- "DJANGO_SECRET_KEY=django-insecure-m#x2vcrd_2un!9b4la%^)ou&hcib&nc9fvqn0s23z%i1e5))6&"
- "DJANGO_DEBUG=True"
# postgreSQL database server being constructed alongside
db:
image: postgres:13
#
volumes:
- postgres_data:/var/lib/postgresql/data/
# unsure of what this environment means.
environment:
- "POSTGRES_HOST_AUTH_METHOD=trust"
# Volumes set up
volumes:
postgres_data:
I have been unable to run migrations or create a super user. The primary reasoning that I see is that the relation doesn't exist.
Attempting to debug it, the following is a list of tables in my postgres database.
root#a8988e22cd23:/# psql -U postgres
psql (13.8 (Debian 13.8-1.pgdg110+1))
Type "help" for help.
postgres=# \dt
List of relations
Schema | Name | Type | Owner
--------+-------------------+-------+----------
public | django_migrations | table | postgres
(1 row)
The error that I see is from the python command
P:\StockWhiz> docker compose exec web python manage.py migrate
Operations to perform:
Apply all migrations: account, admin, auth, contenttypes, sessions, sites, socialaccount
Running migrations:
Applying account.0001_initial...Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 89, in _execute
return self.cursor.execute(sql, params)
psycopg2.errors.UndefinedTable: relation "accounts_customuser" does not exist
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 22, in <module>
main()
File "manage.py", line 18, in main
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.8/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.8/site-packages/django/core/management/__init__.py", line 440, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 414, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 460, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 98, in wrapped
res = handle_func(*args, **kwargs)
File "/usr/local/lib/python3.8/site-packages/django/core/management/commands/migrate.py", line 290, in handle
post_migrate_state = executor.migrate(
File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 89, in _execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python3.8/site-packages/django/db/utils.py", line 91, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value
File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 89, in _execute return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "accounts_customuser" does not exist
error from the compose console:
stockwhiz-db-1 | 2022-11-04 13:36:40.562 UTC [36] ERROR: relation "accounts_customuser" does not exist
", "accounts_customuser"."password", "accounts_customuser"."last_login", "accounts_customuser"."is_superuser", "accounts_customuser"."username", "accounts_customuser"."first_name", "accounts_customuser"."last_name", "accounts_customuser"."email", "accounts_customuser"."is_staff", "accounts_customuser"."is_active", "accounts_customuser"."date_joined" FROM "accounts_customuser" WHERE "accounts_customuser"."username" = 'admin' LIMIT 21
stockwhiz-db-1 | 2022-11-04 13:38:26.019 UTC [41] ERROR: relation "accounts_customuser" does not existstockwhiz-db-1 | 2022-11-04 13:38:26.019 UTC [41] STATEMENT: ALTER TABLE "account_emailaddress" ADD CONSTRAINT "account_emailaddress_user_id_2c513194_fk_accounts_customuser_id" FOREIGN KEY ("user_id") REFERENCES "accounts_customuser" ("id") DEFERRABLE INITIALLY DEFERRED
Could you please direct me towards a solution.
Have you run makemigrations before running migrate? If yes, do you get any error from it?
So it's of importance the order in which the migrations occur, and since my error involved the accounts_customuser table I had to run
python manage.py makemigrations accounts
which was the app involving the accounts_customuser model.
A general makemigrations prior to migrate may not work.

Gunicorn can't access lets encrypt files

(venv) ubuntu#ip-172-31-6-77:~/redrebelgames_python$ gunicorn redrebelgames_python.wsgi:application
[2021-11-25 20:01:09 +0000] [3758] [INFO] Starting gunicorn 20.1.0
Traceback (most recent call last):
File "/home/ubuntu/redrebelgames_python/venv/bin/gunicorn", line 8, in <module>
sys.exit(run())
File "/home/ubuntu/redrebelgames_python/venv/lib/python3.8/site-packages/gunicorn/app/wsgiapp.py", line 67, in run
WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]").run()
File "/home/ubuntu/redrebelgames_python/venv/lib/python3.8/site-packages/gunicorn/app/base.py", line 231, in run
super().run()
File "/home/ubuntu/redrebelgames_python/venv/lib/python3.8/site-packages/gunicorn/app/base.py", line 72, in run
Arbiter(self).run()
File "/home/ubuntu/redrebelgames_python/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 198, in run
self.start()
File "/home/ubuntu/redrebelgames_python/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 155, in start
self.LISTENERS = sock.create_sockets(self.cfg, self.log, fds)
File "/home/ubuntu/redrebelgames_python/venv/lib/python3.8/site-packages/gunicorn/sock.py", line 162, in create_sockets
raise ValueError('certfile "%s" does not exist' % conf.certfile)
ValueError: certfile "/etc/letsencrypt/live/api.redrebelgames.com/cert.pem" does not exist
How do I allow gunicorn to access these files? For some reason it's not working and simply changing the chmod permissions won't work because certbot will eventually change them back.
The certbot files are owned by one identity (typically root). You are running Gunicorn under a different identity. The key is to grant permission to the Gunicorn identity to read the Let's Encrypt files. Typically you can add the Gunicorn username to the Let's Encrypt identity group name and make the files readable by the group.
Example command:
sudo usermod -a -G groupname username
The identity username must re-login after changing group membership. It is simpler to just restart the system.
Another method (not recommended) is to run Gunicorn as a privileged process. That has security risks.

Django + Vagrant VM suddenly says Errno 111: connection refused

I'm sure this is my fault, but my system has been working for months and now does not work. I've looked in Django docs and here on stackoverflow, and I understand the issue that 'connection refused' means nobody is listening on the socket; but I don't understand why, and don't know how to go forward.
I use Vagrant + VirtualBox on a MacPro, and for six months I have been able to create virtual machines and run my app with no problems. I have some VM's where everything works as expected.
On my newly-created Vagrant VM's, I install and configure my django apps and run them using 'python manage.py runserver --settings=mumble.settings.py 0.0.0.0:8000'. Note that this is Django 1.8.3, but again,it works fine on some VM's.
For mysterious reasons, when I create a new vagrant VM and install my django payload (using deploy scripts that haven't changed), and connect to the django server, I get Errno 111 Connection refused:
+ python ./manage.py runserver --settings=mydjango.settings 0.0.0.0:8000
.....
_d^^^^^^^^^b_
.d'' ``b.
.p' `q.
.d' `b.
.d' `b. * Mezzanine 4.0.1
:: :: * Django 1.8.3
:: M E Z Z A N I N E :: * Python 2.7.12
:: :: * MySQL 5.7.18
`p. .q' * Linux 4.4.0-75-generic
`p. .q'
`b. .d'
`q.. ..p'
^q........p^
''''
Performing system checks...
System check identified no issues (0 silenced).
May 31, 2017 - 09:50:50
Django version 1.8.3, using settings 'mydjango.settings'
Starting development server at http://0.0.0.0:8000/
Quit the server with CONTROL-C.
Traceback (most recent call last):
File "/usr/lib/python2.7/wsgiref/handlers.py", line 85, in run
self.result = application(self.environ, self.start_response)
File "/vagrant/repos_here/www.mydjango.org/venv/www/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line 189, in __call__
response = self.get_response(request)
File "/vagrant/repos_here/www.mydjango.org/venv/www/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 204, in get_response
'request': request
File "/usr/lib/python2.7/logging/__init__.py", line 1185, in error
Log 'msg % args' with severity 'ERROR'.
File "/usr/lib/python2.7/logging/__init__.py", line 1193, in error
self._log(ERROR, msg, args, **kwargs)
File "/usr/lib/python2.7/logging/__init__.py", line 1286, in _log
self.handle(record)
File "/usr/lib/python2.7/logging/__init__.py", line 1296, in handle
self.callHandlers(record)
File "/usr/lib/python2.7/logging/__init__.py", line 1336, in callHandlers
hdlr.handle(record)
File "/usr/lib/python2.7/logging/__init__.py", line 759, in handle
self.emit(record)
File "/vagrant/repos_here/www.mydjango.org/venv/www/local/lib/python2.7/site-packages/django/utils/log.py", line 129, in emit
self.send_mail(subject, message, fail_silently=True, html_message=html_message)
File "/vagrant/repos_here/www.mydjango.org/venv/www/local/lib/python2.7/site-packages/django/utils/log.py", line 132, in send_mail
mail.mail_admins(subject, message, *args, connection=self.connection(), **kwargs)
File "/vagrant/repos_here/www.mydjango.org/venv/www/local/lib/python2.7/site-packages/django/core/mail/__init__.py", line 98, in mail_admins
mail.send(fail_silently=fail_silently)
File "/vagrant/repos_here/www.mydjango.org/venv/www/local/lib/python2.7/site-packages/django/core/mail/message.py", line 303, in send
return self.get_connection(fail_silently).send_messages([self])
File "/vagrant/repos_here/www.mydjango.org/venv/www/local/lib/python2.7/site-packages/django/core/mail/backends/smtp.py", line 100, in send_messages
new_conn_created = self.open()
File "/vagrant/repos_here/www.mydjango.org/venv/www/local/lib/python2.7/site-packages/django/core/mail/backends/smtp.py", line 58, in open
self.connection = connection_class(self.host, self.port, **connection_params)
File "/usr/lib/python2.7/smtplib.py", line 256, in __init__
(code, msg) = self.connect(host, port)
File "/usr/lib/python2.7/smtplib.py", line 316, in connect
self.sock = self._get_socket(host, port, self.timeout)
File "/usr/lib/python2.7/smtplib.py", line 291, in _get_socket
return socket.create_connection((host, port), timeout)
File "/usr/lib/python2.7/socket.py", line 575, in create_connection
raise err
error: [Errno 111] Connection refused
[31/May/2017 09:50:55]"GET /donate/ HTTP/1.1" 500 59
Things I know:
'python ./manage.py' with no arguments will run fine, and shows the help message.
All forms of addressing the web server will fail:
curl http://localhost:8000
curl http://127.0.0.1:8000
curl http://192.168.33.10:8000
from a browser: http://192.168.33.10:8000
nginx is serving on port 80, no problem
my database is a copy of the production database, and it looks fine through 'mysql'
And here is a weird thing: I brought down the Django tutorial, used the 'runserver' command, and it worked!
[vagrant][~/tmp/django_tutorial/mysite]
$ python manage.py runserver 0.0.0.0:8000
Performing system checks...
System check identified no issues (0 silenced).
May 30, 2017 - 20:36:44
Django version 1.8.3, using settings 'mysite.settings'
Starting development server at http://0.0.0.0:8000/
Quit the server with CONTROL-C.
[30/May/2017 20:37:05]"GET / HTTP/1.1" 200 1767
Any suggestions on how to debug this?
The answer has nothing to do with my environment. My co-worker added a name to settings.ADMINS, which had been an empty list before that. When ADMINS is a non-empty list, any error triggers an attempt to send email to all of the email addresses in ADMINS, and my VM was not configured to send email. This is documented but not emphasized. The problem did not happen to my coworker, because that associated changes did not trigger a server error.

Celery on Django not working

Sending emails with Celery works fine on production server.
Trying to use it on local dev (VM) and does not work.
I get this when restart:
Starting web server apache2 [ OK ]
Starting message broker rabbitmq-server [ OK ]
Starting celery task worker server celeryd [ OK ]
Starting celeryev...
: No such file or directory
Also I get this error in console when running the page:
error: [Errno 104] Connection reset by peer
Production setting:
import djcelery
djcelery.setup_loader()
BROKER_HOST = "127.0.0.1"
BROKER_PORT = 5672 # default RabbitMQ listening port
BROKER_USER = "vs_user"
BROKER_PASSWORD = "user01"
BROKER_VHOST = "vs_vhost"
CELERY_BACKEND = "amqp" # telling Celery to report the results back to RabbitMQ
CELERY_RESULT_DBURI = ""
When i ran:
sudo rabbitmqctl list_vhosts
I get this:
Listing vhosts ...
/
...done.
What i need to change in this setting to run it successfully on local VM?
UPDATE
vhost and user were definitely missing so I ran suggested commands.
They executed ok but still it does not work ,same error.
It must be one more thing that prevents it from working and celeryev is suspect.
This is what i get when stopping and starting server:
Stopping web server apache2 ... waiting . [ OK ]
Stopping message broker rabbitmq-server [ OK ]
Stopping celery task worker server celeryd start-stop-daemon: warning: failed to kill 28006: No such process
[ OK ]
Stopping celeryev...NOT RUNNING
Starting web server apache2 [ OK ]
Starting message broker rabbitmq-server [ OK ]
Starting celery task worker server celeryd [ OK ]
Starting celeryev...
: No such file or directory
Traceback (most recent call last):
File "/webapps/target/forums/json_views.py", line 497, in _send_forum_notifications
post_master_json.delay('ForumNotificationEmail', email_params)
File "/usr/local/lib/python2.6/dist-packages/celery-3.0.25-py2.6.egg/celery/app/task.py", line 357, in delay
return self.apply_async(args, kwargs)
File "/usr/local/lib/python2.6/dist-packages/celery-3.0.25-py2.6.egg/celery/app/task.py", line 474, in apply_async
**options)
File "/usr/local/lib/python2.6/dist-packages/celery-3.0.25-py2.6.egg/celery/app/amqp.py", line 250, in publish_task
**kwargs
File "/usr/local/lib/python2.6/dist-packages/kombu-2.5.16-py2.6.egg/kombu/messaging.py", line 164, in publish
routing_key, mandatory, immediate, exchange, declare)
File "/usr/local/lib/python2.6/dist-packages/kombu-2.5.16-py2.6.egg/kombu/connection.py", line 470, in _ensured
interval_max)
File "/usr/local/lib/python2.6/dist-packages/kombu-2.5.16-py2.6.egg/kombu/connection.py", line 396, in ensure_connection
interval_start, interval_step, interval_max, callback)
File "/usr/local/lib/python2.6/dist-packages/kombu-2.5.16-py2.6.egg/kombu/utils/__init__.py", line 217, in retry_over_time
return fun(*args, **kwargs)
File "/usr/local/lib/python2.6/dist-packages/kombu-2.5.16-py2.6.egg/kombu/connection.py", line 246, in connect
return self.connection
File "/usr/local/lib/python2.6/dist-packages/kombu-2.5.16-py2.6.egg/kombu/connection.py", line 761, in connection
self._connection = self._establish_connection()
File "/usr/local/lib/python2.6/dist-packages/kombu-2.5.16-py2.6.egg/kombu/connection.py", line 720, in _establish_connection
conn = self.transport.establish_connection()
File "/usr/local/lib/python2.6/dist-packages/kombu-2.5.16-py2.6.egg/kombu/transport/pyamqp.py", line 115, in establish_connection
conn = self.Connection(**opts)
File "/usr/local/lib/python2.6/dist-packages/amqp-1.0.13-py2.6.egg/amqp/connection.py", line 136, in __init__
self.transport = create_transport(host, connect_timeout, ssl)
File "/usr/local/lib/python2.6/dist-packages/amqp-1.0.13-py2.6.egg/amqp/transport.py", line 264, in create_transport
return TCPTransport(host, connect_timeout)
File "/usr/local/lib/python2.6/dist-packages/amqp-1.0.13-py2.6.egg/amqp/transport.py", line 99, in __init__
raise socket.error(last_err)
error: timed out
I ran manage.py celeryev and got console showing workers and tasks.Everything is empty and only getting Connection Error: error(timeout('timed out',),) repeatedly.
It looks like you don't have the virtual host you specified set up on your local RabbitMQ server.
You would first need to add the virtual host.
sudo rabbitmqctl add_vhost vs_vhost
Next you need to add the permissions for your user.
sudo rabbitmqctl set_permissions -p vs_vhost vs_user ".*" ".*" ".*"
Also, make sure that you actually have a user set up, otherwise you can add one using this command.
sudo rabbitmqctl add_user vs_user user01

database error on upgrading the site

I have installed the reviewboard in virtual environment and have created site reviewboard on ubuntu 13.10 using apache2 with mod_wsgi.
when i hit the
http://localhost
i was asked to upgarde the site
The version of Review Board running does not match the version the
site was last upgraded to. You are running 1.7.20 and the site was
last upgraded to 1.7.21.
Please upgrade your site to fix this by running:
and on upgraded
$ rb-site upgrade /home/naveen/venv-review/reviewboard
got
i got following message:
Updating database. This may take a while.
The log output below, including warnings and errors, can be ignored
unless upgrade fails.
------------------ ------------------ Creating tables ... Installing custom SQL ... Installing indexes ... Installed
0 object(s) from 0 fixture(s) No evolution required.
------------------- -------------------
Resetting in-database caches. Traceback (most recent call last):
File "/home/naveen/venv-review/bin/rb-site", line 9, in
load_entry_point('ReviewBoard==1.7.21', 'console_scripts', 'rb-site')() File
"/home/naveen/venv-review/local/lib/python2.7/site-packages/ReviewBoard-1.7.21-py2.7.egg/reviewboard/cmdline/rbsite.py", line 2027, in main
command.run() File "/home/naveen/venv-review/local/lib/python2.7/site-packages/ReviewBoard-1.7.21-py2.7.egg/reviewboard/cmdline/rbsite.py", line 1860, in run
site.run_manage_command("fixreviewcounts") File "/home/naveen/venv-review/local/lib/python2.7/site-packages/ReviewBoard-1.7.21-py2.7.egg/reviewboard/cmdline/rbsite.py", line 562, in run_manage_command
execute_manager(reviewboard.settings, [file, cmd] + params) File
"/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/core/management/init.py", line 459, in execute_manager
utility.execute() File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/core/management/init.py", line 382, in execute
self.fetch_command(subcommand).run_from_argv(self.argv) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/core/management/base.py",
line 196, in run_from_argv
self.execute(*args, **options.dict) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/core/management/base.py",
line 232, in execute
output = self.handle(*args, **options) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/core/management/base.py",
line 371, in handle
return self.handle_noargs(**options) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/ReviewBoard-1.7.21-py2.7.egg/reviewboard/reviews/management/commands/fixreviewcounts.py",
line 16, in handle_noargs
starred_public_request_count=None) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/db/models/manager.py",
line 185, in update
return self.get_query_set().update(*args, **kwargs) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/db/models/query.py",
line 536, in update
rows = query.get_compiler(self.db).execute_sql(None) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/db/models/sql/compiler.py",
line 988, in execute_sql
cursor = super(SQLUpdateCompiler, self).execute_sql(result_type) File
"/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/db/models/sql/compiler.py",
line 818, in execute_sql
cursor.execute(sql, params) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/db/backends/sqlite3/base.py", line 344, in execute
return Database.Cursor.execute(self, query, params) django.db.utils.DatabaseError: attempt to write a readonly database
the sqlite database directory has been given access to server (www-data) like :
sudo chown www-data /home/naveen/venv-review/reviewboard/data
Does www-data should have read/write access of site , reviewboard, if it is the case ?
Update *
checking apache2 user
ps aux | grep apache2
root 1146 0.0 0.0 84208 3928 ? Ss 11:19 0:00 /usr/sbin/apache2 -k start
www-data 3632 0.1 0.6 698464 51056 ? Sl 11:34 0:01 /usr/sbin/apache2 -k start
www-data 3742 0.1 0.6 698480 51032 ? Sl 11:34 0:01 /usr/sbin/apache2 -k start
naveen 7162 0.0 0.0 13652 940 pts/1 S+ 11:53 0:00 grep apache2
The sqlite3 file, not only the directory, have to be owned and have to be writeable by the user running the web server.
so you may try running, from a terminal shell:
sudo chown -R www-data /home/naveen/venv-review/reviewboard/data
sudo chmod -R u+w /home/naveen/venv-review/reviewboard/data/*
the first command recursively change the owner of the files inside the folder, the second one ensures the users have writing permissions on these files.