we are working with an ioncube encrypted webshop system. I'm evaluating how to setup continues deployment with this system.
Propably my assumtions are basically wrong. If this is the case I would be very gratefull if you have tips or corrections for me.
I would like to use an paas-provider like Heroku for the deployment. Heroku offers the possibility to load PHP-Modules like GD with composer. So I thought there might be a way to use Composer for loading Ioncube. But I can't find any introduction for composer that mentions .so or .dll files, which normally would be included in the php.ini configuration file.
If it doesn't work with Heroku, do you know any good paas-provider/hoster matching those reqiurements:
PHP 5.4 and greater
GDLib, Imagick, mod_rewrite, curl
editable PHP-configuration (safe_mode off, register_globals off, memory_limit, max_file_size, max transfer size (Post))
Suitable for continuous delivery (e.g. usage of git)
horizontal scaling available
backup & load balancing available by default
MySQL database
Ideally the paas-provider/hoster should offer a managed mail server
Thanks right now for you help.
Ioncube is not available/loadable on Heroku.
I suspect you must search for an alternative Hoster yourself. Such questions do not have a good stand on Stackoverflow as they are mostly subjective, attract advertisement and one can google oneself.
Related
I created an extension for djondb, it's a wrapper of the library which is a C++ Library, I compiled it and it's available to be downloaded from djondb site, I'm not an expert on PHP and I've been having some problems with the distribution, mainly I realize that I need to do each compilation for each platform and create an installer for each one, which is time consuming, what I want it's a to ditribute the source code and allow the user to install it in the easiest way,
What I already tried:
Using phpize, configure, make, sudo make install the user can install the library very easy on Linux and Mac, the problem with this is that users need to have g++, make, etc installed on their computers, and this process of installation does not work on Windows.
Compile for each platform (Linux x86, x64, Mac, Windows, etc), and upload each tar.gz to the site, the user download it and place each file in the correct folder. the problem here is that the configuration is too manual and the users tend to miss some step, and it's not user friendly. The other problem is that I need to compile each version using a virtual machine and that's time consuming. (Now I'd to include versions for PHP 5.3 and 5.4, this means 8 virtual machines to create all the binaries)
I tried to create an account on PEAR but the registration screen always said that I dont need an account for the purpose I'm creating... (seems that it's a common problem in PEAR system but didnt find how to create the account to propose the package).
Did a proposal on PECL but nobody answered to the mailing list, seems that it's very common too.
So I'm stuck at this moment with the 1 and 2 ways to distribute, what is the best way to distribute a PHP extension that is created using C++ in a user friendly manner and easy to install?
Thanks in advance, you can see the code of the project at https://github.com/djondb/djondb_phpext if you have more questions about how the project is structured or the full explanation of the phpize/configure/make process.
Take the middle road: Distribute the source for Linux / OS X users, who can build it themselves, and offer compiled DLLs for Windows users. That will at least limit the number of versions you need to compile.
As a PHP developer who maintains the extensions we use in our company, it is PERFECTLY fine to give only the source code and expect the users to compile it on their machines.
If you want to be nice, compiling a version for each machine you support yourself, is also an accepted way (See Zend for example) and leave it somewhere easy to download (like sourceforge/github etc).
Then, just listen to the users and improve your (release) system as you go.
I have been compiling PHP for years with the configuration options I want. I compile extensions I use from source. Is there an advantage to doing this versus installing it from a package manager like apt-get or yum. I assumed it would also give me a leaner binary. I noticed that their are PHP modules in the repos such as "php53-gd". What if there wasn't a package available for something I wanted such as cURL for PHP?
I understand the disadvantages of compiling such as needing to download/install dependencies based on my configuration options. I'm not really concerned with that.
So the question is:
Compile PHP on Linux or just use apt-get / yum? Can I get all the things I need from the repos? Does anyone out there still compile it from source?
Any insight is appreciated! Thanks.
I compile from source every time. It's not hard to corral the mentioned issues with regards to compiling manually. For example, my ./configure settings are saved to a file which is version controlled, so when a new version of PHP is stable and I am ready to make the switch, I download and extract the file, then run this command:
./configure `sh /path/to/my/configure/php.sh`
Not too difficult. And because it's in version control, I can add notes as to why a module was added or removed.
Another benefit of manual compilation is it allows me to keep the PHP footprint as minimal as possible. I pass the --disable-all flag, then add the modules I need. However, there is a downside to this minimalist approach, recently I needed to install Magento, so I had to recompile with --enable-hash and --with-mcyrpt flags. Even though I needed to add new flags, it wasn't difficult to add to the configure file and recompile.
Compiling from source has a few quirks:
There are hundreds of config parameters and flags. And you might not know the optimal ones that need to be used.
if you rely on apt-get's PHP, then you can be assured that you will get the latest patches and security updates if you set up auto-upgrade on your server.
the configuration of php.ini varies a lot. Sometimes your OS may decide some defaults for you which may work better with the rest of the system.
installing extensions like xdebug or other packages are a lot easier with apt.
However, it's worth compiling php from scratch if you want to learn. Also if you don't use some portions of it, you can always disable them in configuration - but then again it might not make much difference to performance.
I compiled php for specific needs only, like :
very small hard disk space so required a minimalist php version
and/or
need only a few specific modules or extensions
and/or
needed for a specific application
and/or
needed to optimize performances: when compiling on the machine where it's used, this allows some performance improvements, if using compile options to get a real tuned version for your system,
and/or
needed multiple and different php versions on the same machine.
and/or
I had a specific nux distro like only a busybox, so no other options than compiling.
But for common usage, e.g. in 80% of the cases, it's not worth spending time to compile and better using the repository version. But I learned a lot by compiling.
Personally, it's a matter of opinion. If you are in a hurry, apt-get it, if you have time to learn and possibly need to reinstall 20 times...compile it.
There are tons of guides out there for PHP compiling. It has a ton of flags for configuration, especially for GD and other libraries. Personally if this is for learning and development, just get LAMP or use apt-get...especially if you need to use Apache
I feel the primary reason for compiling is to have latest version binary (stable or nightly). package managers (most distors) are often annoyingly slow in this respect.
The other reason is that its very common problem that production systems are not wholesale upgraded using package managers. Even if that can be easy. Since package managers create dependency chains and you may not want to upgrade those items. So just to pick one item, compiling is an option. It keeps everything else as it is. You ofcourse have to always study the upgrade issues and make sure nothing else will fail.
For one website, I need to add a litle script who resize images in php. For that, I used the GD functions. That worked very well in the dev machine, the problem is that in production doesn't work because php GD support isn't installed.
The things is, I'am not expert in server configurations and maintenance (my experience is mostly develop, and in others jobs other people were in charge of the servers, but this company is very small, so...), and I have a little fear that, if simple I install php-gd support, something wrong could happens to the productions server.
Any advice would be greatly appreciate.
While there is the possibility of something going wrong during the install, this can be mitigated by backups. Only thing I could imagine on the php side is concerning method definition - if somebody defined a method with the exact same name of a predefined mod_gd one, it will break.
If you want to be really sure: get a full backup of the production server, install it in a VM and test adding the GD support to it. If it doesn't break the VM install, it won't break the production server either.
I currently purchased a dedicated server hosted at iWeb and got it administered by them.
I recently asked after registration to add php_apc and php_imagick to the available libraries. It seems according to them that it is not possible as it is not supported with cPanel.
I would apparently need to do that myself... is there any risks to install those two libraries ? What kind of problem could it raise if there is any ? In case I would have to debug this myself.
Installing Imagemagick to your system in itself won't be too much of a problem.
However, adding support for it and APC to PHP may be a tricky procedure; it may be best for you to just no longer use the PHP provided by cPanel and install PHP yourself, which will go into /usr/local, and run the configure script for it yourself, compiling in whatever extensions you need. It'll mean that you'll need to keep PHP up to date yourself, but it'll also mean that you won't have all your customisations to it wiped the next time cPanel upgrades it.
If there are better suggestions I'd also be interested to hear them.
So my group is trying to set up a shared-server environment for various and sundry web services. I think we've settled on setting disable_functions and disable_classes site wide in php.ini and php_admin_value to force open_basedir in each app's httpd.conf
for php scripts, and passenger's user switching for ruby scripts.
We still need to find something for python though. Passenger does support python, but not for per-application security for specific sub-directories (it's all or nothing at the domain level).
Any suggestions?
(And if any of the previous doesn't make sense - well, I'm the guy who's supposed to set up the python support, not the guy who set up the php or ruby support, so there's still some "and then some magic happens" steps in there from my perspective).
Well, there is a system called virtualenv which allows you to run Python in a sort of safe environment, and configure/load/shutdown these environments on the fly. I don't know much about it, but you should take a serious look into it; here is the description from its web page (just Google it and you'll find it):
The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.4/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.
Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.
Also, what if you can't install packages into the global site-packages directory? For instance, on a shared host.
In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't use the globally installed libraries either).