I'm currently having a problem with the fonts when I generate a PDF with wkhtmltopdf in Centos 7 on a normal hosting account. However, when I create the PDF in root I get no errors.
The error that I'm getting is:
Fontconfig error: Cannot load default config file
I checked the /etc/fonts/fonts.conf and it exists and it also has read privileges for everyone and I dont know what else coould be going on taking in account that it is working for root and not for the sub accounts.
The code I am using to generate the PDF:
wkhtmltopdf /rout/to/my.html /rout/to/my.pdf
The main problem is that the fonts aren't rendering and we always get the "Sans Serif" font as default. But the funny thing is that if I put the font as bold, it does render with the type of font that I need. In this case it's "Verdana".
Thanks in advance.
I had faced this problem with AWS Lambda today which is AWS Linux but cent OS from inside. Also, I found and successfully solved this problem so I think I should contribute to the community by answering this here.
First, it can be checked that if the font are available for that user, if not you can give path and provide your app fonts.
An easy to deploy implementation of HTML-pdf for AWS Lambda
But any phantom/wkhtmltopdf code throws Error: write EPIPE Next on this link all the required dependencies are posted which I think should be listed somewhere but aren't except this one. Also, the configuration is clearly explained
Aws Lambda PhontomJS dependencies for amazon Linux 2
Ok, so in my particular problem, it was not working because the hosting account had a "Jailed Shell" instead of a "Normal Shell".
This option can be changed in WHM for any specific account in the option "Manage Shell Access".
Hope this helps people in the future.
Related
I'm currently trying to set up an Airflow environment via MWAA. I've gone through the create environment steps twice with both ending at the page listing Airflow environments with a banner saying I was successful. However, for the past 2 days, this environments page has just shown Loading Environments, as shown below. I also see a (0) for the environment number.
So far, I've added 2 interfaces for ECR and VPC for the API and the environment but no luck. Has anyone else run into this issue or have any clue what might be happening? Thanks!
Were you able to find the solution to this issue? I had similar issues when I tried to set up the first-time MWAA on AWS Account.
https://github.com/awslabs/aws-support-tools/tree/master/MWAA
Here's a link to how to verify if all the resources are set up correctly for MWAA. If you run the script mentioned on the repo you should be able to see where the issue lies.
I have several Lambdas deployed to AWS, all created as single file function in the console. All was working fine until I flushed my caches and cookies in chrome. Then the function codes will no longer show up in the browser, any browser, I tried 3. Also all the Lambda functions think they are all zip file based so I cannot reenter the code from my git repo. The functions still operate properly, I just cannot edit them.
All new functions I create are also not in console editing mode. Something general / global has changed, not specific to any one function.
What can cause this? And across all browsers?
Most importantly how can I fix this?
You can download your code as a zip file if you click right on Actions > Export Function and then Download deployment package. Maybe re-uploading the packages will fix your issue.
My Serverless image handler was working fine till now and now i'm getting the following error.
start_thumbor error: pycurl: libcurl link-time ssl backend (openssl) is different from compile-time ssl backend (nss)
This looks like a problem with the version of pycurl.
Please help me resolve it.
Tried changing the pythong version to 3.6 in ServerlessImageHandler lambda function configuration.
I found a discussion about that issue on https://forums.aws.amazon.com/thread.jspa?messageID=909444, which sent me to https://github.com/awslabs/serverless-image-handler/issues/127#issuecomment-514757029.
Github user timkelty has the solution:
go to my CloudFormation Stack
click Update
"replace template"
paste in https://cf-templates-nestrom.s3-eu-west-1.amazonaws.com/serverless-image-handler/1.0/serverless-image-handler.template
so far has worked for me in us-east-1 and us-west-1
AWS has released a new version of Serverless Image Handler this is why everybody suffers now because Thumbor functionalities fail in the new version.
In the new version, SharpJS is used instead of Thumbor API calls.
You can check the new version and download it from here.
Even though you are able to construct urls in old style, images in subfolders are not possible to access anymore without encoding the url.
Old way:
abcdef.cloudfront.net/team/team1.png
New way:
abcdef.cloudfront.net/{base64encodedPath}
Note 1: If your images are in the root directory of the bucket, you are still able to access them old style like this:
abcdef.cloudfront.net/team1.png
Note 2: If you update your existing CloudFormation stack, you will have your old cloudfront domain (which is a good part).
You can also follow the current fixes from here.
I have an icon assets located on s3, and have a page in angular that looks like this
<img alt="Some Logo" src="assets/icons/logo.svg" width="200">
It used to always work properly.
But recently after I apply AWS WAF for network restriction. It works for 1 day and then it never work again (never show the image anymore).
If I take a look at the developer tools, it showed up as binary/octet-stream
Instead of svg (this is back when I did not apply AWS WAF)
Any advice on how to fix this? I'm pretty sure it works even with AWS WAF at least for a day, unless there's some caching issue happening that I did not know of.
On old versions of python, the python library mimetypes didnt have a definition for svg file types.
See this issue: https://bugs.python.org/issue19377
I added '.svg' : 'image/svg+xml', into the types_map in mimetypes.py and then the aws cli got the correct type for SVGs.
I'm trying to install some packages on Sitecore 6.2 solution. I'm receiving a strange packager error:
“Package generation failed: Root element is missing" . I checked logs and nothing appear.
Sitecore’s packager wasn't able to generate a package.
It appears that in the process of generating the zip, it needs to access the temp folder during the creating process.
I meet this error few times and it doesn't work allways to give access just for AppPoolIdentity.If it's not working give access for role Everyone.
Here you find a nice article about this error .
I think a probable reason for this failure could be that you created package of an item or a number of items, but its template might be missing.
Alternatively, please check that your AppPoolIdentity, (ideally Network Service, to check AppPoolIdentity Name, goto IIS Manager, Application Pools and select the AppPool of your website, and in Action Pane on right side, say Advanced Settings, you will be able to see the Name of Process Model -> Identity) has read-write rights on C:\Windows\Temp directory.
Do let me know after trying the above two things on your solution
Hope this helps!
Regards,
Varun Shringarpure