Add possibility to install additional drivers (or to run custom init scripts)

[theyo-tester]

Hi to all maintainers!

I like your work! It is well thought through!👍

I have a suggestion for an improvement though:
Some printers need extra drivers, f.i. a few from Canon. The package offered by the vendor is a .sh script which checks some dependencies, installs them, if needed (over apt), and then it installs the driver package (as .deb).
I tried to install this after the container was up and running. I mounted a volume with the extra files and then from inside, I started the script. The problem is that this .sh script will try to restart cups at some point, which doesn't go well and the container crashes. From there on, dpkg is in a not-done state and apt doesn't work either. Every time you would try to resume the dpkg reconfiguration, it would restart cups, which crashes again.....
The next thing I tried (also to make it more automated), was to add a further init-script as a command directive in my docker-compose.yaml file, but this will never be run, because the entrypoint script will run first, and this script will never get a chance to run. At least, this is what happens with my compose version.

Long story short, the dirty workaround was to:

• copy your start-cups.sh and save it in a volume, externally
• overwrite the default entrypoint with my script (by mounting a volume on that path). The script first installs the extra stuff, and finally starts the default start-cups.sh

This works now, but as I mentioned, this is a dirty workaround. Why ? It is a long term issue:
Now I'm stuck with the static start-cups.sh, which doesn't get updated as soon as this gets changes/improvements on github.

I was also thinking about your suggestions in the readme, to create my own Dockerfile and adapt the image as needed, but I'm not a fan of this approach either; for the same Reason: I try to make every docker service updatable. As soon as there are updates online, I want to be able to automatically update them, without any manual intervention on my part (in best case).

Does my train of thought make sense?

So my suggestion is to add to the image some points of customization.

1. One easy solution would be to replace the ENTRYPOINT directive with the CMD directive. Thus, the startup command can be overwritten when starting the container, and we don't have to touch or save the default script from the repo somewhere else. The custom command can than call the default startup script afterwards.
2. Another solution would be to add some ENV variables, that hold the path to the scripts. Those will be evaluated and exectuted in the entry point,. For instance a var named "PRE_INIT_SCRIPT"

BR

[DrPsychick]

I like the idea of adding "hooks" that can point to additional scripts (PRE_INIT, ...), I'll have to think a bit on where to put them in the entrypoint.sh and how to call them. The variables would be empty by default and no change to the existing image.
Feel free to provide a suggestion via PR!

[DrPsychick]

@theyo-tester do you feel like contributing a suggestion via PR?

[theyo-tester]

Hi!
Yes
I just have to find some time in the next days/week :)