Inside the cpanel -> python app i have tried several time to create super user. when I tried to execute this commad inside Execute python script
manage.py createsuperuser
then it will return this error
Superuser creation skipped due to not running in a TTY. You can run `manage.py createsuperuser` in your project to create one manually.
How to solve this problem, or any manuall solution, i found several solution but all the solution for local server.
There is no difference between creating superuser on local server and production server. You have to do next:
Enter your server via ssh.
Go to your project root folder (with manage.py file)
Type python manage.py createsuperuser (use your virtual environment or system interpreter, depends on).
Related
I have a django docker container for the backend on my website. There is a volume for the database so i can save the database even if i change the backend configuration.
I have tried to put the createsuperuser in my Dockerfile and in a script launched with "command" in docker-compose. In the Dockerfile, the problem is the prompt is not connected to the database...
In the script, the command is re-run each time the container is started
I would like this command to be run only once, but i dont know how to proceed.
The problem is the container is rebuilt in my ci/cd pipeline if i change the configuration files, and so the command is re-run.
I have seen this post Run command in Docker Container only on the first start but that also works only if the container is not rebuilt.
A workaround with a createsuperuser command that would fail would work and that seemed to be the case with django previous versions (before version 4) but i now have "django.db.utils.IntegrityError: UNIQUE constraint failed: auth_user.username" error which tells me the command seems to be run multiple times and gives me errors in the database...
You can use environment variables to run createsuperuser based on those variables.
If you ignore the return value of the command, it doesn't matter whether the superuser already exists or not. Additionally, you would benefit from being sure that the defined superuser always exists.
And if you change the environment variables, the superuser will be recreated with the changed values.
See similar question here: run initial commands in a docker-compose service
I already have a django project and all files created, but I am trying to deploy to a server. I moved files over to server using FileZilla and I am in putty now trying to django-admin startproject practice ~/practice but I get a command error stating that this already exists which obviously it does but then if I want to manage.py makemigrations I get a -bash: Permission denied and I am guessing that is because I have not started django project here on putty??? I hope there is enough info here to explain my issue. Any help is appreciated
You need run python manage.py runserver in the correct folder with admin permisions.
I made some updates to a project: add 1 admin model, add 1 template
I'm using wagtail. I pulled the updates to my server, ran migrations, got success. I restart nginx and gunicorn, I even rebooted the server.
When I go to the wagtail admin, my adminmodel is missing (it exists locally). when I go to create a new page, my template is available, but when I select it I get taken to a wagtail 404 page.
Ubuntu 20.04
ngnix
gunicorn
django/wagtail
digital ocean vpc
digital ocean postgres database cluster
The site works like normal, only a template is available I can't select, and the Model, that migrated, isn't available and isn't showing up in admin. my local version is working perfectly, with no differences. it seems like the server is both updating and not updating. I don't get it. running makemigrations or migrate returns no changes. even when running on the specific app. Do I need to do something to rebot the database?
Listen it looks like caching issue with Nginx. Try clearing the cache.
I have 2 settings files: dev.py, production.py
dev.py is connected to a sqlite3 db and production is connected to the digitalocean postgres cluster.
python manage.py automatically uses dev.py (at least in my setup) so my migrations were working, but they were targeting an old copy of the sqlite.db I had on the server, or perhaps created one as it does when one doesn't exist. Either way, the live site runs on the production.py settings and this is why the changes were being made but not reflecting.
The correct way to run migrations when you have a production.py file is similar to:
python manage.py migrate --settings=<settings app>.<settings folder>.production
I'm also going to add that I found that you need to collectstatic each time you update your css stylesheet. that is a little tedious, and maybe I am missing an automation step, but considering that is the case, just to be safe, I run like this:
python manage.py collectstatic --settings=<settings app>.<settings folder>.production
It doesn't cause any issues and it works, so I use the --settings flag to be safe.
git pull
python manage.py migrate --settings=app.settings.production
python manage.py collectstatic --settings=app.settings.production
sudo systemctl restart ngix
sudo systemctl restart gunicorn
I don't know that restarting ngix is necessary except it solved something with my static files updating I believe.
I know there are a lot of questions floating around there relating to similar issues, but I think I have a specific flavor which hasn't been addressed yet. I'm attempting to create my local postgresql database so that I can do local development in addition to pushing to Heroku.
I have found basic answers on how to do this, for example (which I think is a wee bit outdated):
'#DATABASES = {'default': dj_database_url.config(default='postgres://fooname:barpass#localhost/dbname')}'
This solves the "ENGINE" is not configured error. However, when I run 'python manage.py syncdb' I get the following error:
'OperationalError: FATAL: password authentication failed for user "foo"
FATAL: password authentication failed for user "foo"'
This happens for all conceivable combinations of username/pass. So my ubuntu username/pass, my heroku username/pass, etc. Also this happens if I just try to take out the Heroku component and build it locally as if I was using postgresql while following the tutorial. Since I don't have a database yet, what the heck do those username/pass values refer to? Is the problem exactly that, that I need to create a database first? If so how?
As a side note I know I could get the db from heroku using the process outlined here: Should I have my Postgres directory right next to my project folder? If so, how?
But assuming I were to do so, where would the new db live, how would django know how to access it, and would I have the same user/pass problems?
Thanks a bunch.
Assuming you have postgres installed, connect via pgadmin or psql and create a new user. Then create a new database and with your new user as the owner. Make sure you can connect via psql with the new user into to the database. you will then need to set up an env variable in your postactivate file in your virtualenv's bin folder and save it. Here is what I have for the database:
export DATABASE_URL='postgres://{{username}}:{{password}}#localhost:5432/{{database}}'
Just a note: adding this value to your postactivate doesn't do anything. The file is not run upon saving. You will either need to run this at the $ prompt, or simply deactivate and active your virtualenv.
Your settings.py should read from this env var:
DATABASES = {'default': dj_database_url.config()}
You will then configure Heroku with their CLI tool to use your production database when deployed. Something like:
heroku config:set DATABASE_URL={{production value here}}
(if you don't have Heroku's CLI tool installed, you need to do it)
If you need to figure how exactly what that value you need for your production database, you can get it by logging into heroku's postgresql subdomain (at the time this is being written, it's https://postgres.heroku.com/) and selecting the db from the list and looking at the "Connection Settings : URL" value.
This way your same settings.py value will work for both local and production and you keep your usernames/passwords out of version control. They are just env config values.
On my project i have an app : my_app with Managment command : my_command.py
On SSH i try :
my/folder/project/and/app/python2.4 manage.py my_command all is ok
but if i try : python2.4 /my/folder/project/and/app/manage.py my_command, manage.py doesn't know my command...
i try to run my command on a crontab..
Thx
laurent
In my experience I had this kind of issues for several reasons.
I'd check first the python interpreter used. If you are using virtualenv or something like that you should ensure you are using the correct python executable.
If your server has selinux, you should ensure it's not denying the cron to read some files.
I also had an issue like this because the settings file (I used a separate setting file to make it less verbose) didn't exist.