I am trying to start Odoo v8 server from Eclipse ide. I have set the debug configurations and have given the config file path in the arguments as
-c /etc/odoo-server.conf.
When I do debug as python run, I do not get any error. The log file also does not show any error. But when I open localhost:8069 from the browser.
I get server not found error. This does not happen when I start the server through the terminal. Can anyone please tell me what could be the problem?
Below is the odoo-server.conf content:
[options]
; This is the password that allows database operations:
admin_passwd = admin
db_host = False
db_port = False
db_user = odoo
db_password = odoo
addons_path = /opt/odoo/addons
logfile = /var/log/odoo/odoo-server.log
Below is the server traceback:
2014-11-15 07:47:06,205 3875 INFO ? openerp: OpenERP version 8.0
2014-11-15 07:47:06,206 3875 INFO ? openerp: addons paths: ['/home/hassan/.local/share/Odoo/addons/8.0', u'/opt/odoo/addons', '/opt/odoo/openerp/addons']
2014-11-15 07:47:06,207 3875 INFO ? openerp: database hostname: localhost
2014-11-15 07:47:06,207 3875 INFO ? openerp: database port: 5432
2014-11-15 07:47:06,207 3875 INFO ? openerp: database user: odoo
2014-11-15 07:47:07,046 3875 INFO ? openerp.service.server: Evented Service (longpolling) running on 0.0.0.0:8072
Try to check whether the configuration file that you have set is having appropriate access rights. And try not to log the errors into a file, instead allow it show it on the console on Eclipse IDE.
There's nothing wrong with your "traceback": is a normal log, with only INFO messages and it tells you that the server is running and waiting for requests on port 8072.
Point a browser at http://localhost:8072 and you should see a login page.
I know my answer is late, but i ran into this problem today, and got the server running, so thought I should share :
Do not start the openerp server as : Debug as -> Python run.
It only starts the longpolling service.
Try running as : Run as -> Python run
This will start the Http service at your defined port or by default at 8069.
Related
CentOS 7
Docker 20.10.5
In my machine run PostgreSQL 9.5 and success open my db:
localhost:5432/sonar
And success open DB by PGAdmin
Nice.
Now in Docker I installed SonarQube 4.5. And want to connect to my db.
I try this:
sudo docker run -e SONARQUBE_JDBC_USERNAME=sonar -e SONARQUBE_JDBC_PASSWORD=sonar -e SONARQUBE_JDBC_URL=jdbc:postgresql://localhost:5432/sonar sonarqube:4.5.7
But I get error:
2021.04.20 11:47:55 INFO web[o.s.s.p.ServerImpl] SonarQube Server / 4.5.7 / e2afb0bff1b8be759789d2c1bc9348de6f519f83
2021.04.20 11:47:55 INFO web[o.s.c.p.Database] Create JDBC datasource for jdbc:postgresql://localhost:5432/sonar
2021.04.20 11:47:55 ERROR web[o.a.c.c.C.[.[.[/]] Exception sending context initialized event to listener instance of class org.sonar.server.platform.PlatformServletContextListener
java.lang.IllegalStateException: Can not connect to database. Please check connectivity and settings (see the properties prefixed by 'sonar.jdbc.').
at org.sonar.core.persistence.DefaultDatabase.checkConnection(DefaultDatabase.java:115) ~[sonar-core-4.5.7.jar:na]
at org.sonar.core.persistence.DefaultDatabase.start(DefaultDatabase.java:73) ~[sonar-core-4.5.7.jar:na]
Try to ask a question because the DB connection in MySQL Workbench continues to fail.
Enter connection information and Test Connection was successful.
However if i select the appropriate DB Connection in workbench home, the connection success window does not appear.
local DB : mysql Ver 15.1 Distrib 10.3.14-MariaDB, for Win64 (AMD64), source revision ab7b9cf9122f6eb02744082db8672a920ae6009f
Server DB : mysql Ver 15.1 Distrib 10.3.14-MariaDB, for Win64 (AMD64), source revision ab7b9cf9122f6eb02744082db8672a920ae6009f
MySQL Workbench Version : mysql-workbench-community-8.0.16-winx64
The same error occurs even if the version of Workbench is changed to 19 or 20.
How to solve it?
Manage Server Connections - screenshot
MySQL Workbench - screenshot
------More details---------
If you check the log file in the top Help tab of Workbench, you can see the log as below.
11:23:15 [INF][SQL Editor Form]: Opened connection 'DB Name' to mariadb.org binary distribution version 10.3.14-MariaDB
11:23:15 [ERR][ WBContext]: Unsupported server version: mariadb.org binary distribution 10.3.14-MariaDB
However, the connection is normally established on the other coworker's PC.
I did following settings on /var/ossec/etc/ossec.conf and after that I restart agent but it's not showing logs on the Kibana dashboard
<localfile>
<log_format>syslog</log_format>
<location>/var/log/mongodb/mongod.log</location>
I performed a basic installation of Wazuh + MongoDB on agent side with the following results:
MongoDB by default writes inside syslog file located at /var/log/syslog.
Inside /var/log/mongodb/mongod.log there are internal mongo daemon logs that are more specific.
We could monitor such logs on Wazuh agent by:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/syslog</location>
</localfile>
This rule is included by default on the agent but anyway is good to remember.
the other one as you point it out:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/mongodb/mongod.log</location>
</localfile>
I only see that you didn't copy the closing tag </location> but it could be copy mistake, whatever is good to take a look at /var/ossec/logs/ossec.log to find some error.
With that configuration we could receive alerts like this:
** Alert 1595929148.661787: - syslog,access_control,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,gpg13_7.8,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
2020 Jul 28 09:39:08 (ubuntu-bionic) any->/var/log/mongodb/mongod.log
Rule: 2501 (level 5) -> 'syslog: User authentication failure.'
2020-07-28T09:39:07.431+0000 I ACCESS [conn38] SASL SCRAM-SHA-1 authentication failed for root on admin from client 127.0.0.1:52244 ; UserNotFound: Could not find user "root" for db "admin"
If we run mongo -u root (with bad password) on agent side.
I am working with Laravel 5.2. I want to add some tables to my database, so I've created a new migration file and tried to run the migration.
When trying to run php artisan migrate I get the following error
[PDOException]
SQLSTATE[HY000] [1045] Access denied for user 'homestead'#'localhost' (using password: YES)
But the password is correct. I can access my DB via Sequel Pro (OS X) and the website itself is working, too (I can create new users etc).
I work with homestead, but changed the default database. I've restarted the VM and tried php artisan config:clear.
My .env:
APP_ENV=local
APP_DEBUG=true
APP_KEY=base64:SDXEyixnQr+qVCH8hbY2bRo3yQtmL8BwEbwY94tDPRc=
APP_URL=http://palabi.dev
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=palabi
DB_USERNAME=homestead
DB_PASSWORD=password
CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=sync
And my Homestead configuration
ip: "192.168.10.10"
memory: 2048
cpus: 1
provider: virtualbox
authorize: ~/.ssh/id_rsa.pub
keys:
- ~/.ssh/id_rsa
folders:
- map: ~/Homesteadprojects/sites
to: /home/vagrant/sites
sites:
- map: test.app
to: /home/vagrant/sites/test
- map: laravel-53.app
to: /home/vagrant/sites/laravel-53/public
- map: palabi.app
to: /home/vagrant/sites/palabi/public
databases:
- homestead
- palabi
What am I doing wrong?
Thanks!
Ok, I've found the problem.
Laravel tried to connect to my local database (where no user homestead exists). But it must connect to the database from the Homestead virtual machine.
In my .env I had to change 127.0.0.1 to the IP from my Homestead configuration file 192.168.10.10.
I am attempting to deploy a Flask app to Heroku. I have pushed to Heroku and can access my login page but any call to the db gives an OperationalError:
2014-01-29T12:12:31.801772+00:00 app[web.1]: OperationalError: (OperationalError) no such table: projects_project u'SELECT
Using Flask-migrate I can successfully run local migrations and upgrades:
INFO [alembic.migration] Context impl PostgresqlImpl.
INFO [alembic.migration] Will assume transactional DDL.
INFO [alembic.migration] Running upgrade None -> 4b56d58e1d4c, empty message
When I try to upgrade on Heroku using heroku run python manage.py db upgrade the upgrade appears to happen, but the Context impl. is now SQLite?:
(dev01)Toms-MacBook-Pro:dev01 kt$ heroku run python manage.py db upgrade
Running `python manage.py db upgrade` attached to terminal... up, run.9069
INFO [alembic.migration] Context impl SQLiteImpl.
INFO [alembic.migration] Will assume non-transactional DDL.
INFO [alembic.migration] Running upgrade None -> 4b56d58e1d4c, empty message
Running Heroku pg:info gives:
=== HEROKU_POSTGRESQL_PINK_URL (DATABASE_URL)
Plan: Dev
Status: available
Connections: 0
PG Version: 9.3.2
Created: 2014-01-27 18:55 UTC
Data Size: 6.4 MB
Tables: 0
Rows: 0/10000 (In compliance)
Fork/Follow: Unsupported
Rollback: Unsupported
The relevant logs for the Heroku upgrade are:
2014-01-29T12:55:40.112436+00:00 heroku[api]: Starting process with command `python manage.py db upgrade` by kt#gmail.com
2014-01-29T12:55:44.638957+00:00 heroku[run.9069]: Awaiting client
2014-01-29T12:55:44.667692+00:00 heroku[run.9069]: Starting process with command `python manage.py db upgrade`
2014-01-29T12:55:44.836337+00:00 heroku[run.9069]: State changed from starting to up
2014-01-29T12:55:46.643857+00:00 heroku[run.9069]: Process exited with status 0
2014-01-29T12:55:46.656134+00:00 heroku[run.9069]: State changed from up to complete
Also, heroku config gives me:
(dev01)Toms-MacBook-Pro:dev01 kt$ heroku config
=== myapp Config Vars
DATABASE_URL: postgres://xxx.compute-1.amazonaws.com:5432/da0jtkatk6057v
HEROKU_POSTGRESQL_PINK_URL: postgres://xxx.compute-1.amazonaws.com:5432/da0jtkatk6057v
where [xxx == xxx]
How is the Context impl. set? Apart from this obvious difference between working local and heroku, I can't work out what's happening or how I should debug. Thanks.
The URL for the database is taken from the SQLALCHEMY_DATABASE_URI configuration in your Flask app instance. This happens in the env.py configuration for Alembic that was created in the migrations folder.
Are you storing the value of os.environ['DATABASE_URL'] in the configuration before you hand over control to Flask-Migrate and Alembic? It seems you have a default SQLite based database that never gets overwritten with the real one provided by Heroku.