How to keep ImageMagick up-to-date on Heroku-18 stack? - security

At time of writing, the ImageMagick version installed on the Heroku-18 stack is a few years out-of-date (version 6.9.7-4 released 14/Jan/2017).
How would you recommend keeping ImageMagick up-to-date on the Heroku-18 stack?

Heroku support suggested a couple of options: either install ImageMagick via the apt-get buildpack (https://elements.heroku.com/buildpacks/heroku/heroku-buildpack-apt), or use one of the ImageMagick buildpacks (https://elements.heroku.com/search/buildpacks?q=imagemagick).
Buildpacks have access to your environment and if compromised would pose a significant risk. So I'll add that if you do use a third-party, non-Heroku buildpack, you should consider forking that buildpack's repo and use your trusted fork instead of relying on a third-party's repo that could be modified maliciously without your knowledge.

Related

How does haskell-platform use Stack?

The page: https://www.haskell.org/platform/ claims that haskell-platform comes with the Stack tool. However, on my Debian system after installing the haskell-platform package, I do not have the command stack available to me (which I would if I followed the instructions for installing Stack from the Stack website).
I can't find any information on how Stack is included in haskell-platform. It seems to be mentioned on the front page of the site, and no where else.
So, in what way is Stack "included" with the haskell-platform?
Haskell platform 2014.2.0 version doesn't come up with Stack. You can verify it from here: https://www.haskell.org/platform/contents.html
Haskell platform 8.0.1 is the first version which supports Stack. Also the versioning scheme of the platform seemed to change after 2014.2.0.
In my opinion, you should generally not try installing from Debian's package manager as it is usually quite old. Also, these days I would just recommend you to use Stack and install it from here.

Update the local debian packages using ansible

I am trying to come up with a deployment strategy in developer environments using Ansible.
I have a few builds (node.js) coming out every day usually in the form of debian packages.
Eg: my_product_1.0.0_33.deb is the corresponding debian for build#33.
I am trying to automate the deployment on existing as well as new environments using Ansible. So what is the preferred way of updating the build packages using Ansible?
Eg: my_product_1.0.0_44.deb is my new build with build id #44 which I want to install on top of the existing build.
I am going through the Ansible documentation and below mentioned is the way I think will work for now.
Check if any package of "my_product" is installed and if not installed, install the latest debian.
If yes, check if the right build id of my_product is installed
If yes, don't restart the service and leave as is
If no, uninstall the existing package, install the new build debian and restart the service.
Is this the preferred approach of updating the debian packages in an environment or is there a better way to do this in Ansible?
The debian packages I receive are not hosted in any repository and are local .deb files.
Is this the preferred approach of updating the debian packages in an
environment or is there a better way to do this in Ansible?
This is a reasonably common approach. It could be simplified a bit by hosting your debs on an internal repo, but that's not necessary.
In general, you don't need to do things like "check if a package is installed and if not, install the latest version". You just specify the package name to the apt module and it handles the conditional logic for you.
For restarting the service if a new version has been deployed, look into handlers.

Git/Egit configs

I am trying to migrate to git and would like to stay inside my familiar IDE (Eclipse), and apparently Egit is the plugin to use.
A few questions:
Does Egit require git? Meaning, do I need to first install git on my machine, prior to installing the Egit plugin?; and
If the answer to #1 above is "yes", and I do need to first install git, then after I install git, are there any system-level configurations, or git commands (to be ran from the shell) that I need to perform before I install Egit? Note I do plan on using a private repo on GitHub which I believe uses SSL keys...if that changes the answer to this question at all...
Also I'm on Ubuntu Desktop 12.04 - just fyi in case there are linux-specific settings, etc.
Thanks in advance!
No, EGit does not require Git as it is based JGit, which is a pure Java implementation of Git.

Port a debian package to YUM for CentOS

I have a project that runs on Debian and uses many packages provided from the Debian repositories.
Because of demand, I've looked into porting the project to CentOS, but found that many of the packages I require are completely missing - at least 10 dependencies would have to be compiled manually at install time on the users machine.
My question is, what is the best way to create an installer for the user's machine? Should I use automake tools (with the standard ./configure, make, make install), to compile the required libraries, or is this a non-standard approach. Note that my app doesn't actually need to be compiled since it is written in Python, so is it weird to do a "make", when you're not compiling your own app?
Should the configure script just warn the user that package X is missing, and let them handle the rest?
Should I roll my own dependency checker by runng pkg-config manually a few times for each library required, and exit if something is missing?
I'm quite new to this, so any tips to get me moving in the right direction are appreciated.
Edit: I am familiar with RPM and yum for red hat base distros, but CentOS is missing many multimedia packages that I require. An example of one of my package dependencies is "liquidsoap" which is a programmable audio engine: http://savonet.sourceforge.net/
This is available on Debian, but not Redhat/Centos
See this link on CentOS package management.
http://wiki.centos.org/PackageManagement/Yum
CentOS is redhat based and does not use .deb packages by default. However apt package management has been ported to tons of platforms, you may be able to use a port for centOS
If you use YUM whatever packages you need will be there for your application as redhat distros need all the same things that any other distro does.
EDIT: To get the details out of comments
Packages not available on the target platform either have to be built (possibly as a port) on the target platform and then shipped in the ported package (in this case YUM), or code needs to be modified and forked to use packages which already are available on the target platform. The choice depends on which is worse, or which is even possible given your constraints.

Upgrading a package whose newest version is not still in the distribution repository [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I need to upgrade libpng from version 1.2 to 1.5. I need to do so because of this: libpng warning: Application built with libpng-1.2.26 but running with 1.5.2. I am using Lubuntu 11.10 and in the Canonical repositories libnpg 1.5 is not still released although at Debian ones there are testing packages (http://packages.debian.org/search?keywords=libpng) that at first they would fit to me. I added the Debian repositories to Synaptec and I was able to install libpng15, but those packages do not replace libpng12, son when it comes to compile some source code the IDE uses libpng12 instead of libpng15.
To try to solve this I downloaded the libpng15 deb package, uncompressed it and changed the Replaces, Conflicts and Provides tags of the control file with the libpng15 text. Then, I executed the modified deb, but what I only got was a GDebi error and a general system failure because (I think) libpng12 was uninstalled with no replacement and Lubuntu heavily depends on it, which forced me to reinstall Lubuntu because the computer did not boot again in Linux. Yes, this solution is not the neatest way I think.
So, is there any way to upgrade a package and replace the old version whose newer version exists but it is not still in the distribution repository? I found ubuntu repository for libpng and How to upgrade a package in linux that was built from source?. Although not very determinant so far.
I have not found out how to upgrade and replace a package whose newer version is not still in the distribution repository. But I have realized that if some library X relies on a given version of other library Y, there is no way to change the version of that dependence unless you make some change onto the source code of X, that is it, the library X is recompiled to point to the desired version (usually with the help of some configuration tag). Even though some trick could be done as by modifying the symlink of the library Y to point to the newer version. Then, the compiler will complain and ask for the old version.
Maybe this looks obvious now. But if the software that has to be recompiled requires many hours, has unresolved dependences or gives built errors you will try to avoid the compilation no matter if you are violating thermodynamics laws.
So in my case I had to recompile Qt and by using the -system-libpng configuration tag Qt understood it had to use system libpng libraries, not in-built ones. And after 8 hours of compiling I got a successfully built which solved this libpng problem.
Thanks everyone for the comments and suggests.
For all of the trouble you're going through, it might be easier to simply compile from source, and install to /usr/local (instead of /usr, as debs do). I've done this for several library dependencies for programs I've compiled (with make build systems) without any trouble. However, it sounds like the program(s) you're compiling are having trouble choosing the right version of the package. In my opinion, that is the real issue. Having multiple versions of a library installed simultaneously is supported, but perhaps not by apt in the case of mixing Debian and Ubuntu repos.
When you compile your program, use gcc -lpng15 instead of -lpng. According to the gcc info manual, an option of -lname causes the linker to look for libname.a in the lib folders. On my system (Ubuntu 10.04), libpng.a is a symlink to libpng12.a. This is why your program is choosing the wrong lib.
Try adding this ppa: https://launchpad.net/~linaro-maintainers/+archive/overlay. It contains libpng1.5 for Oneiric.
You can install it by running
sudo add-apt-repository ppa:linaro-maintainers/overlay
sudo apt-get update
sudo apt-get install libpng1.5
To properly link against libpng15, you will also need to install libpng15-dev.

Resources