On command line I get connection and desired entities, no driver error here:
php bin/console dbal:run-sql 'select * from ourtest'
But on web i get error:
$this->connection->fetchAll('SELECT * FROM ourtest');
Handling
"App\Application\Command\DocumentUpload\DocumentUploadCommand" failed:
An exception occurred in driver: could not find driver
i tried
php -m display among others PDO, pdo_mysql, mysqli, mysqlnd
connection url from .env:
DATABASE_URL=mysql://xxx:xxx#mysql-db:3306/db_test_01?serverVersion=8.0
doctrine.yaml:
doctrine:
dbal:
dbname: db_test_01
host: mysql-db
port: 3306
user: xxx
password: xxx
driver: pdo_mysql
version: 8.0
My guess is the command line and your webserver use different configurations of PHP or different installations altogether.
Here's how to find out: Put a phpinfo() call in a file on your webserver (Do not do that on production as it will expose sensitive data to anyone with access to this file!). Open that file in your browser and check where your PHP installation is located.
On the command line, you can run which php to see where the PHP binary is located.
Compare the two and see whether you are running on the same binary. If it is indeed the same, then you should check which .ini file is used by the web server. In that .ini file you should find the name of the mysql extension (pdo_mysql.so) and it should not be commented out (no preceding ;).
Related
Background:
I am only able to get past the ansible console install/config tasks by adding --region localhost to anywhere in: /usr/share/eucalyptus-ansible/roles/cloud-post/tasks/console.yml wherever it calls tools that take that argument.
Otherwise each sub task fails like this: ["euca-describe-images: error: connection error (('Connection aborted.', gaierror(-2, 'Name or service not known')))"]
Running the commands from that playbook directly on the euca server being configured gives the same result unless I specify --region localhost
Problem:
I'm stuck here: [cloud-post : update console route53 system domain for eucalyptus-cloud authentication]
Error: "euform-update-stack: error (ValidationError): No updates are to be performed.", "stderr_lines": ["euform-update-stack: error (ValidationError): No updates are to be performed."]
All services are running except the ImagingBackend is Not Ready
No instances are running according to euca-describe-instances
Images are available:
IMAGE ami-5be483c81cf8bd65c eucalyptus-console-image-5-0-823/eucalyptus-console-image-5-0-823.raw.manifest.xml 000216594841 available private x86_64 machine instance-store hvm
TAG image ami-5be483c81cf8bd65c type eucalyptus-console-image
TAG image ami-5be483c81cf8bd65c version 5.0.823
IMAGE ami-f31092ddb73e29af9 eucalyptus-service-image-v5.0.100/eucalyptus-service-image.raw.manifest.xml 000216594841 available privatx86_64 machine instance-store hvm
TAG image ami-f31092ddb73e29af9 provides imaging,loadbalancing
TAG image ami-f31092ddb73e29af9 type eucalyptus-service-image
TAG image ami-f31092ddb73e29af9 version 5.0.100
---
all:
hosts:
exp-euca.lan.com:
exp-enc-[01:02].lan.com:
vars:
vpcmido_public_ip_range: "192.168.100.5-192.168.100.254"
vpcmido_public_ip_cidr: "192.168.100.1/24"
cloud_system_dns_dnsdomain: "cloud.lan.com"
cloud_public_port: 443
eucalyptus_console_cloud_deploy: yes
cloud_service_image_rpm: no
cloud_properties:
services.imaging.worker.ntp_server: "x.x.x.x"
services.loadbalancing.worker.ntp_server: "x.x.x.x"
children:
cloud:
hosts:
exp-euca.lan.com:
console:
hosts:
exp-euca.lan.com:
node:
hosts:
exp-enc-[01:02].lan.com:
EDIT:
Solved. Details are in the comments of the marked answer.
The name error most likely means that DNS for the domain cloud.lan.com is not being correctly delegated to your deployment. To test this, check if the nameserver is found:
dig +short NS cloud.lan.com
you should see "ns1.cloud.lan.com" and then should be able to use that nameserver to resolve services, e.g.
dig +short ec2.cloud.lan.com #ns1.cloud.lan.com
which should be the IP of the host for the compute service.
The second item is a bug in the ansible playbook that occurs when the stack is already present and up to date. To work around it, you can either update your playbook or delete the stack before running the playbook. Depending on how far the playbook progressed you may have a script to do this:
/usr/local/bin/console-manage-stack -a delete
the related playbook change is https://github.com/AppScale/ats-deploy/pull/36
Older Versions of Contao (till 4.3) working like expected with sending emails via sendmail.
After upgrade to Contao 4.9 I got some errors at Providers like 1u1 / ionos or mittwald.
The error in the logs sound like:
"Expected response code 220 but got an empty response"
Sending Mails from CLI of the Server (means if logged in via SSH) working like expected:sendmail test" |
/usr/sbin/sendmail -t -v -f sender#domain.com reciepient#otherOne.com
The solution is to add this to config/config.yml
swiftmailer:
default_mailer: default
mailers:
default:
url: '%env(MAILER_URL)%'
transport: sendmail
command: '/usr/sbin/sendmail -t -i'
After that, clear the Contao-Cache (e.g. via contao-manager.phar) and give it a try.
The reason for that issue is, that by default the swiftMailer use sendmail -bs as command, which means that sendmail run as standalone Service.
Depending at the way your provider configure it's sendmail, this will be the cause of the error.
If you update symfony/swiftmailer-bundle to version 3.5.0, then the default value used for the sendmail command will be read from the PHP configuration. See https://github.com/symfony/swiftmailer-bundle/pull/302
So provided the PHP configuration of your hosting environment contains the correct command in sendmail_path, sending emails should work without any changes.
I need to read the host entries from pillar file and update the /etc/hosts file accordingly
This is my simple sls file to update the /etc/hosts file.
#/srv/salt/splunk_dep/hosts.sls
dnsutil:
dnsutil.hosts-append:
- hostsfile: '/etc/hosts'
- ip_addr: '10.10.10.10'
- entries: 'hostname'
when i execute the sls file
salt Minion-name state.apply splunk_dep/hosts
Getting the following error
ID: dnsutil
Function: dnsutil.hosts-append
Result: False
Comment: State 'dnsutil.hosts-append' was not found in SLS 'splunk_dep/hosts'
Reason: 'dnsutil.hosts-append' is not available.
Started:
Duration:
Changes:
If i execute through command line its working fine
salt 'DS-110' dnsutil.hosts_append /etc/hosts 10.10.10.10 hostname
I need to update the /etc/hosts file through sls file. Can someone please help me on this.
I am using the salt version : salt 2015.8.3 (Beryllium)
dnsutil is a Salt module, and not a Salt state. Therefore it can be used from the command line, but not directly via SLS state file.
To run modules from state file you'll need module.run. Please note that in this case you'll need to put an underscore in hosts_append, not a hyphen.
dnsutil:
module.run:
- name: dnsutil.hosts_append
- hostsfile: '/etc/hosts'
- ip_addr: '10.10.10.10'
- entries: 'hostname'
Some caveats with modules: even if they don't change your system, they will be reported as "changed" in the summary of your salt call. Please consider using file.blockreplace for managing hosts file instead to avoid this.
Recently I started working with Symfony. I created a project with the terminal/composer under the name "symfony" and also created a database on phpmyadmin (MAMP) which I called "symfony". I installed the project, and except a error of my timezone, my project was succesfully created and was running at my localhost.
After that I created a bundle called "SymfonyCinemaBundle" and my bundle was generated succesfully. I also tried to generate a entity but that is not working for me, and also the problem. After I open up the generator with the command, It asks for a shortcut name and I tried to use "SymfonyCinemaBundle:Movie" but that isn't working and gives me the following error:
*The Entity shortcut name: SymfonyCinemaBundle:Movie
[Doctrine\DBAL\Exception\ConnectionException]
An exception occured in driver: SQLSTATE[HY000] [2002] Connection refused
[Doctrine\DBAL\Driver\PDOException]
SQLSTATE[HY000] [2002] Connection refused
[PDOException]
SQLSTATE[HY000] [2002] Connection refused
doctrine:generate:entity [--entity ENTITY] [--fields FIELDS] [--format FORMAT] [--with-repository]*
I checked my parameters.yml but thats seems to be right. I've looked on the internet but nothing seems to help unfortunately. Does anyone has a solution for me?
Note: I'm using MAMP. The difference between normal and developers mode has no difference.
Solved:
I've changed the host in parameters.yml to localhost instead of 127.0.0.1. I also added the right port number (normally it doesn't matter) and that solves the problem but has given me another error instead: "No such file or directy". It had to do with my mysql.sock so I used the following commands in my terminal:
sudo mkdir /var/mysql
sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock /var/mysql/mysql.sock
sudo chown _mysql /var/mysql/mysql.sock
sudo chmod 777 /var/mysql/mysql.sock
How can one configure Symfony's DoctrineMigrationsBundle to use different database authentication credentials to its DoctrineBundle—or at very least, a different DoctrineBundle connection to that used elsewhere in the app?
We would like the app to connect to the database with only limited permissions, e.g. no ability to issue DDL commands such as CREATE, ALTER or DROP. However, migrations will need to execute such DDL commands and so should connect as a user with elevated permissions. Is this possible?
I know it's a very old post, but as it is the one which shows on a Google search on the subject, I add my solution, working with Symfony 4.
First, you just have to define a new database connection in config/doctrine.yml (a new entity manager is NOT needed):
doctrine:
dbal:
default_connection: default
connections:
default:
# This will be the connection used by the default entity manager
url: '%env(resolve:DATABASE_URL)%'
driver: 'pdo_pgsql'
server_version: '11.1'
charset: UTF8
migrations:
# This will be the connection used for playing the migrations
url: '%env(resolve:DATABASE_MIGRATIONS_URL)%'
driver: 'pdo_pgsql'
server_version: '11.1'
charset: UTF8
orm:
# As usual...
You also have to define the DATABASE_MIGRATIONS_URL with the admin credentials in the .env file or in environnement variables:
###> doctrine/doctrine-bundle ###
# Format described at http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#connecting-using-a-url
DATABASE_URL=postgresql://app_user:app_user_pass#localhost:5432/db
# Database url used for migrations (elevated rights)
DATABASE_MIGRATIONS_URL=postgresql://admin_user:admin_user_pass#localhost:5432/db
###< doctrine/doctrine-bundle ###
Then, just execute your migrations with the --db option, passing the name of your new connection:
php bin/console doctrine:migrations:migrate --db=migrations
Yes. Just define a new entity manager with the correct connection details and then use that entity manager when running migration commands
$ php app/console doctrine:migrations:version --em=new_entity_manager