PDF Export, Access from outside

Question

PDF Export, Access from outside

jonaswoehl opened this issue 5 years ago · 7 comments

(Writing since the contact form at your website doesn't seem to be working at the moment)
Hi!

First of all: thank you for your awesome work. I stumbled across your alpine-akaunting docker image searching for an idiot(me)-friendly way to install akaunting as a docker. Yours seems to be the best way for me. I installed it after couple of hours finding out how to solve the timeout issue when the database is setup during the setup. While I can use the app in general i find myself running in some further issues. I hope you can help since I'm not too much into using linux and webhosting.

First of all the system i'm running at:

docker using a synology diskstation
installed your alpine-akaunting docker image
database is a second docker container running mariadb where also all other databases of my other dockers are stored to
i want to access akaunting from outside having setup a subdomain

My issues:

the subdomain points to the local port of the docker container. so if i open the site the initial index.html of your package is showing. to access akaunting i need to enter sub.domain.de/akaunting. i tried to copy the files to the www folder but this doesn't seem to the trick (gives me "whoops something went wrong"). how can i achieve to the dockerimage pointing to the akaunting folder and not to www?
when i entered an invoice in akaunting and want to export or print it gives me "whoops something went wrong". i already checked the official akaunting docker repo but it seems that it's working fine for the current version so i assume it's something about your image which i overlooked. Do you know this issue or can tell me a fix? Please let me know which log-files you might need to see where the issue is originated from

Thank you in advance for your help! Akounting and your automated docker solution to get future updates seems optimum for me.
I'd really appreciate you helping me.

All the best regards,
Jonas

Answer 1 · 2019-07-14T16:15:07.000Z

Hey,

Firstly, thanks for using the image.

Your first issue seems easy enough, the default nginx configuration (check the root/defaults/default for starters) points to /config/www as document root, and the default path is set as /akaunting in it. To get it in /, you'll need to mount your modified nginx configuration at /config/nginx/site-confs/default at runtime, that has the root set as /config/www/akaunting and the locations modified accordingly.

The second one is going to be bit trickier as I don't have a setup ready to test right now, last I heard about the PDF generation issue was in #1 where some dependencies were missing, but they've been added since. If you could add the error that shows up below the "whoops something went wrong" header, that'd be helpful. Till then I could look around a bit, will update if I find something.

BTW, the mail(s) did get sent. I should also get on to fixing that bug :)

Answer 2 · 2019-07-15T13:46:15.000Z

Hi!

Thank you for your reply which seemed to be promising but made my situation worse. I'm sure i did not get something right.
I edited the default file under /config/nginx/site-confs/default and replaced /config/www; in line 3 with '/config/www/akaunting' and in line 57 also.
I saved the changes and from that point on the website wasn't accessible anymore (showing an errorpage of my server saying that the searched site can't be found). I tried to revert the changes in the 'default' file but the situation stays the same.

What did I do wrong? Right now I can't access the page on any way.

Thank you for your time and help!

EDIT:
I found a partly solution. My diskstation creates in every folder where manual file changes are made a hidden folder called "@eadir". The docker console showed this as an error message. I deleted the folder and now the old configuration is working again. Changing the root paths as described in the original post didn't work though and results in an "404 not found nginx" error message. I'm afraid I missed something you meant by writing "(...) and the locations modified accordingly." Can you specify this a bit more? Thank you!

The .pdf export problem was "solved" yesterday. It seems like Akaunting couldn't handle the resoultion of the company logo i used. So i tried a downscaled version and then it was working fine. So no need for investigation here. :)

Answer 3 · 2019-07-15T14:08:07.000Z

No worries you're halfway there.
Now that that root is set to the app dir, there's no path /akaunting/index.php so you also need to modify the locations. Try this on the http block of your custom configuration:

comment out the locations /secure and /, we don't need them.
change the /akaunting location like below, i.e remove akaunting from the location and file search path.

        # /akaunting is now /
	location / { 
		try_files $uri $uri/ /index.php?$args;
	}

Are you accessing the site using http or https? Https has a couple more locations that work the same way.

Let me know if the above fix worked.

Edit:
Good to know. :)

Answer 4 · 2019-07-15T14:19:25.000Z

Hi !

It worked, thank you very much!
I'm accessing the page via https and have a let's encrypt certificate for my subdomain on my diskstation installed. do i have to adjust further things in order to set it up correctly?

One thing i noticed is that there seems to be an issue with the company logo graphics and the graphs on the landing page of akaunting displaying the cash flow and so on.
The inspector of my browser tells me

[Warning] The page at (URL) was allowed to display insecure content from (URL)/uploads/3. (accounting.jonaswoehl.de, line 609)
[Warning] [blocked] The page at (URL) was not allowed to run insecure content from (URL)/public/js/chartjs/Chart.min.js.

When i'm on a page other than the landing page with the graphs and delete the company logo the ssl certificate is recognized and there are no warning messages. However the warning message concerning the company logo is prominent on all pages since it is always displayed in the upper left corner.
Do you know this particular issue and also have a solution on this one?

All the best and thank you once again

Answer 5 · 2019-07-15T14:40:06.000Z

Assuming you updated the access-blocking locations in the https block as well, you should be all set for now.

Most of the time, the insecure content problem occurs probably because you're fetching the logo or some other asset via its http url instead of https. Can't do that.

Answer 6 · 2019-07-16T13:04:02.000Z

If possible, i would like to add one more question for now.

How is updating intended to work? Should i use just the the akaunting inbuilt updater in the gui?
Or do I have to pull a new docker image? If the second is the case: how do i deal with my custom set files (for example changed invoice layouts, .css etc.). Because, if i understand right, the mounted paths will overwrite the content of an updated docker image since the whole (old) akaunting version will be mounted "back"?

Best regards

Answer 7 · 2019-07-20T06:29:26.000Z

Not a problem at all, happy to help. :)

You can use whichever way you'd be comfortable with, it just checks if you already have an installation mounted at /config/www/akaunting or extracts the latest archive that's embedded into the image to that place. On non-dev deploys, it's supposed to stay out of your way of managing the scripts so as long as you keep a backup of the additional files (or the whole dir) before doing any updating, you should always have the last working version of the application to rollback to in case something goes wrong.