Symfony cloud MPDF temp files can't be stored in /tmp - mpdf

Our project is going to be on Linux, and we want to have the temp files be stored in /tmp/mpdf. I have the following MPDF constructor:
$mpdf = new Mpdf(['mode' => 'en',
'default_font_size' => 8,
'margin_left' => 9.5,
'margin_right' => 0,
'margin_bottom' => 37,
'margin_header' => 0,
'margin_footer' => 2,
'fontDir' => array_merge((new ConfigVariables())->getDefaults()['fontDir'], [realpath(getenv('DOCUMENT_ROOT')) . '/../assets/fonts']),
'fontdata' => (new FontVariables())->getDefaults()['fontdata'] + [
'arialuni' => [
'R' => 'arialuni.ttf',
'B' => 'arialuni.ttf'
]
],
'tempDir' => sys_get_temp_dir()
]);
However, I end up getting the following error:
"[prod] Feb 26 10:40:30 |CRITICA| REQUES Uncaught PHP Exception Mpdf\MpdfException: "Temporary files directory "/app/vendor/mpdf/mpdf/src/Config/../../tmp/mpdf" is not writable" at /app/vendor/mpdf/mpdf/src/Cache.php line 21"
From what I understand, it still tries to use the following folder:
/app/vendor/mpdf/mpdf/tmp/mpdf
It should however use the /tmp folder which was recommended by the symfony cloud support (the /tmp folder of Linux)

So I had the same issue recently and it is caused by the Mpdf library not having enough permission to write to the vendors folder, (which frankly it shouldn't have).
The solution for me was to update the tmp_dir in ConfigVariables.php to use PHP's temp dir instead of the one it tries to use.
Made a fork => https://packagist.org/packages/tevli/mpdf
Github => https://github.com/tevli/mpdf

Related

ignite odbc SQLSTATE [01000] error How do I fix it?

I've installed ignite 2.7 , nginx, php7.0-fpm.
I also installed unixodbc, unixodbc-dev, libtool, automake, libssl-dev, and m4.
The odbc installation looked at the official homepage and followed up, but there was a problem.
cat odbc.ini // odbcinst.ini // .odbc.ini (all same)
[Apache Ignite]
Description=Apache Ignite
DSN=Apache Ignite
Driver=/usr/local/lib/libignite-odbc.so
Setup=/usr/local/lib/libignite-odbc.so
DriverODBCVer=03.00
FileUsage=0
UsageCount=1
tail /etc/profile
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export LD_LIBRARY_PATH=/usr/local/lib/
ldd /usr/local/lib/libignite-odbc.so
linux-vdso.so.1 => (0x00007ffef07c0000)
libignite-binary-2.7.0.33575.so.0 => /usr/local/lib/libignite-binary-2.7.0.33575.so.0 (0x00007fd8b8d4d000)
libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 (0x00007fd8b8b3b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd8b87b9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd8b83ef000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd8b81d9000)
libignite-common-2.7.0.33575.so.0 => /usr/local/lib/libignite-common-2.7.0.33575.so.0 (0x00007fd8b7fc2000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007fd8b7db8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd8b7b9b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd8b7892000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd8b9227000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd8b768e000)
ex.php
<?php
try {
// Connecting to Ignite using pre-configured DSN.
$dbh = new \PDO('odbc:Driver=Apache Ignite;ADDRESS=127.0.0.1:10800;Cache =default');
// Changing PDO error mode.
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
// Preparing query.
$dbs = $dbh->prepare('INSERT INTO city (id, name) VALUES (?, ?)');
// Declaring parameters.
$key = 777;
$firstName = "James";
// Binding parameters.
$dbs->bindParam(1, $key);
$dbs->bindParam(2, $firstName);
// Executing the query.
$dbs->execute();
} catch (PDOException $e) {
print "Error!: " . $e->getMessage() . "\n";
die();
}
?>
localhost/ex.php
Error!: SQLSTATE[01000] SQLDriverConnect: 0 [unixODBC][Driver Manager]Can't open lib '/usr/local/lib/libignite-odbc.so' : file not found
I do not know what to try.
Thank you for your help.
Try to use PHP Thin Client instead which requires fewer configuration efforts:
https://apacheignite.readme.io/docs/php-thin-client
If PHP PDO is still required then Ignite ODBC experts should step in.

Qt - Module "QtQuick.Controls" is not installed

I try to deploy a QT application which works fine on a PC. The application is deployed in an image of a yocto installation, based on ASEM, with release "morty".
I receive the error message "qml: ERROR loading component: qrc:/GUI/InputDialog.qml:3 module "QtQuick.Controls" version 2.0 is not installed"
However, I don't see any trouble in the LDD output:
ldd $clientApp
linux-vdso.so.1 (0x7ed4b000)
libquazip.so.1 => /usr/lib/libquazip.so.1 (0x76f72000)
libQt5QuickWidgets.so.5 => /usr/lib/libQt5QuickWidgets.so.5 (0x76f64000)
libQt5Quick.so.5 => /usr/lib/libQt5Quick.so.5 (0x76c5e000)
libQt5Widgets.so.5 => /usr/lib/libQt5Widgets.so.5 (0x7674c000)
libQt5Gui.so.5 => /usr/lib/libQt5Gui.so.5 (0x762dd000)
libQt5Qml.so.5 => /usr/lib/libQt5Qml.so.5 (0x75f8d000)
libQt5Network.so.5 => /usr/lib/libQt5Network.so.5 (0x75e3d000)
libQt5Xml.so.5 => /usr/lib/libQt5Xml.so.5 (0x75e0d000)
libQt5Sql.so.5 => /usr/lib/libQt5Sql.so.5 (0x75dc1000)
libQt5Test.so.5 => /usr/lib/libQt5Test.so.5 (0x75d8c000)
libQt5Core.so.5 => /usr/lib/libQt5Core.so.5 (0x75861000)
libpthread.so.0 => /lib/libpthread.so.0 (0x75839000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x756f3000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x756c7000)
libc.so.6 => /lib/libc.so.6 (0x7558b000)
libGLESv2.so.2 => /usr/lib/libGLESv2.so.2 (0x75492000)
libm.so.6 => /lib/libm.so.6 (0x75414000)
libz.so.1 => /lib/libz.so.1 (0x753f2000)
libpng16.so.16 => /usr/lib/libpng16.so.16 (0x753ba000)
libmysqlclient.so.18 => /usr/lib/libmysqlclient.so.18 (0x750e9000)
libdl.so.2 => /lib/libdl.so.2 (0x750d6000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x74fd7000)
librt.so.1 => /lib/librt.so.1 (0x74fc0000)
/lib/ld-linux-armhf.so.3 (0x76faa000)
libGAL.so => /usr/lib/libGAL.so (0x74ebc000)
libEGL.so.1 => /usr/lib/libEGL.so.1 (0x74e9d000)
libVSC.so => /usr/lib/libVSC.so (0x74ddb000)
libpcre.so.1 => /usr/lib/libpcre.so.1 (0x74d8c000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x74d7a000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x74d66000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x74d48000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x74c2e000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x74c01000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x74bef000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x74bdb000)
The offending line in the qml code is:
import QtQuick.Controls 2.0
Without any success, I have already added the following code to the recipe:
+IMAGE_INSTALL_append = " qtquickcontrols"
The directory /usr/lib/qt5/qml/QtQuick is present and contains libqtquick2plugin.so
Adding this directory to the LD_LIBRARY_PATH prior to starting the application does not solve the issue though.
I have exported:
export LD_LIBRARY_PATH=/usr/lib/qt5/qml/QtQuick.2:/usr/lib/qt5/qml/QtQuick
I wonder what file could be missing.
Can please somebody provide pointers on how to debug this?
To test Amfasis idea, I now also export
export QML2_IMPORT_PATH="/usr/lib/qt5/qml"
prior to starting the application in the same shell.
ls /usr/lib/qt5/qml/
Qt
QtGraphicalEffects
QtLocation
QtPositioning
QtQml
QtQuick
QtQuick.2
QtTest
QtWebChannel
QtWebEngine
builtins.qmltypes
Nevertheless, the error stays the same.
Looks as if I was missing libQt5QuickControls.so
I'll dig into this...
For future reference:
The idea is to explicitly state a dependency in yocto.
This can be achieved by adding
RDEPENDS_${PN} = "qtquickcontrols2 \
qtquickcontrols2-mkspecs \
"
Then, the dependency will be compiled and installed.
It is not enough, though, to add the following (which I had before already):
DEPENDS = "qtquickcontrols2"
I followed this answer:
sudo apt install qml-module-qtquick-controls2
Note the 2 at the end. By default minuet package installs qml-module-qtquick-controls.
And fixed the errors running minuet 19.12.3-0ubuntu1 on Ubuntu 20.04:
[...]
QQmlApplicationEngine failed to load component
qrc:/Main.qml:24 module "QtQuick.Controls" version 2.0 is not installed

Drush 9 sql:sync error: no database record could be found for source #local

I just installed a new Drupal 8 and it comes with Drush 9, and I was trying to set up everything to use the command sql:sync or config:pull to have my local and staging syncronized but everytime I run the command 'drush sql:sync #local #stage' I get the following error
In SqlSyncCommands.php line 86:
[Exception] Error: no database record could be found for source
#local
Here's my self.site.yml
local:
host: localhost
user: root
root: /var/www/html/new-drupal
uri: http://new-drupal.local
stage:
host: XX.XX.XX.XX
user: root
root: /var/www/html/new-drupal
uri: http://new-drupal.my-staging.com
Searching around I found old versions of the aliases file that included this option:
'databases' =>
array (
'default' =>
array (
'default' =>
array (
'driver' => 'mysql',
'username' => 'sqlusername',
'password' => 'sqlpassword',
'port' => '',
'host' => 'localhost',
'database' => 'sqldbname',
),
),
),
But checking the example file of the 9 version there's nothing about it: https://github.com/drush-ops/drush/blob/master/examples/example.site.yml
Did someone had the same problem and found a solution?
It's been a while since my conversion. I had similar issues and went with a least-configuration approach.
First, compare the results of the following commands to see if it exposes any problems:
drush site:alias
drush site:alias #self
drush site:alias #local
I don't have a self.site.yml file. I've named mine drush/sites/remote.site.yml and only have remote aliases in it. I do not define a #local alias and use the built-in #self alias instead.
In drush/drush.yml I have:
drush:
paths:
config:
- ../docroot/sites/default/local.drush.yml
In docroot/sites/default/local.drush.yml I only have
options:
uri: 'http://localhost:port'
With this configuration the results of drush site:alias #self is
'#self':
root: /var/www/docroot
uri: 'http://localhost:port'
And assuming I have a valid #stage alias in drush/sites/remote.site.yml I would just run
drush sql:sync #self #stage
If you want a #local alias maybe you should move it over to the local drush config instead.

ldd: Library cannot be found

I am running ldd command on libqqnx.so on my target board. This list few certain dependent libraries and then throw error called ldd: Library cannot be found. If I do same on libcpp.so.4 of qnx then it does not show such errors.
My question is, the file libqqnx.so is corrupted or should it be listing some more dependent lib files?
output1:
# ldd /opt/qt/plugins/platforms/libqqnx.so:
libqqnx.so => /opt/qt/plugins/platforms/libqqnx.so (0x78000000)
libscreen.so.1 => /proc/boot/libscreen.so.1 (0x78040000)
libpps.so.1 => /opt/qt/lib/libpps.so.1 (0x78031000)
libm.so.2 => /proc/boot/libm.so.2 (0x78060000)
libfreetype.so.1 => /usr/lib/libfreetype.so.1 (0x78090000)
libQt5DBus.so.5 => /opt/qt/lib/libQt5DBus.so.5 (0x780e0000)
libQt5Gui.so.5 => /opt/qt/lib/libQt5Gui.so.5 (0x78200000)
libQt5Core.so.5 => /opt/qt/lib/libQt5Core.so.5 (0x78600000)
libGLESv2.so.1 => /usr/lib/graphics/iMX6X/libGLESv2.so.1 (0x78037000)
libEGL.so.1 => /proc/boot/libEGL.so.1 (0x78053000)
libcpp.so.5 => /opt/qt/lib/libcpp.so.5 (0x78140000)
libz.so.2 => /proc/boot/libz.so.2 (0x781a0000)
libslog2.so.1 => /proc/boot/libslog2.so.1 (0x78083000)
libicui18n.so.49 => /opt/qt/lib/libicui18n.so.49 (0x78a00000)
libicuuc.so.49 => /opt/qt/lib/libicuuc.so.49 (0x78b10000)
libicudata.so.49 => /opt/qt/lib/libicudata.so.49 (0x78c00000)
ldd: Library cannot be found
output2:
# ldd /proc/boot/libcpp.so.4:
libcpp.so.4 => /proc/boot/libcpp.so.4 (0x78000000)
#
It looks for me that ldd is looking for more libraries but it doesn't find them.
If you know another directory that has other libraries (.so* files) allow qnx to search on it for the missing libraries. You can use LD_LIBRARY_PATH.
For example: export LD_LIBRARY_PATH=/opt/qt/some_dir
More info here

Puppet syncing dir

Still does not work
In/etc/puppet/manifests/site.pp
file { "/home/render/installation/":
ensure => "directory",
owner => "render",
group => "render",
recurse => "true",
mode => "0750",
source => "puppet:///files/installation/",
}
Dir still is empty on client
ls /etc/puppet/files/installation/
1 2 3 4 5
On puppet client in log
Mar 21 12:28:12 lw-003 puppet-agent[28098]: (/File[/home/render/installation/]) Failed to generate additional resources using 'eval_generate: Error 400 on SERVER: Not authorized to call search on /file_metadata/files/installation with {:checksum_type=>"md5", :recurse=>true, :links=>"manage"}
Mar 21 12:28:12 lw-003 puppet-agent[28098]: (/File[/home/render/installation/]) Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/files/installation Could not retrieve file metadata for puppet:///files/installation: Error 400 on SERVER: Not authorized to call find on /file_metadata/files/installation
Mar 21 12:28:12 lw-003 puppet-agent[28098]: Finished catalog run in 0.28 seconds
I had the same issue and found this question on Google. I had to change the path to the files for the manifests (modulename/manifests/init.pp):
"puppet:///files/installation/",
to:
"puppet:///modules/files/installation/",
The notation without /modules/ was deprecated in 2.7 and no longer supported in newer versions:
DEPRECATION NOTICE: Files found in modules without specifying 'modules' in file path will be deprecated in the next major release. Please fix module 'modulename' when no 0.24.x clients are present
try this example,
file {
"/scratch/usern/testmod" :
ensure => directory,
source => "puppet:///files/testmod",
recurse => true,
owner => "usern",
group => "groupn",
mode => "0775",
backup => false,
}
You have to specify 'files' and if you are doing a recursive copy, specify 'recurse => true'. That might be the solution to your problem.
the 'fileserver.conf' should look something like the following :
]# cat /etc/puppet/fileserver.conf
[files]
path /etc/puppet/files
allow *

Resources