ionCube

http://www.ioncube.com/

For better or worse, ionCube is an encryption method for those that want to protect their code. A pain the neck for system admins, but some want to protect their PHP code, whatever.

Problem… Zend Optimizer +

Zend Optimizer+ does not play well with ionCube for whatever reason, so it’s really picky on what order they get loaded during startup. It’s important to put the configurations in the correct order, or it will just error out during start up.

Installing ionCube

You’ll want to grab the loader files from here

http://www.ioncube.com/loaders.php

I downloaded and unzipped them to

/usr/local/ioncube

Edit php.ini file

Since ionCube is a Zend Extension and not a Zend Module (what’s the difference? I couldn’t tell you, but there is a different) we need to open up the file

/usr/local/zend/etc/php.ini

and at the very bottom it should look something like this.

; Local Variables:
; tab-width: 4
; End:
[Zend]
zend_extension=/usr/local/ioncube/ioncube_loader_lin_5.2.so
zend.install_dir=/usr/local/zend
zend.conf_dir=/usr/local/zend/etc
zend.ini_scandir=conf.d


Of course the important line is the ioncube line, it’s important that it appears before the other lines.

Big Note about versions

It wasn’t immediately obvious to me, but you need to match your PHP version with the version of ionCube (You can tell I’m using PHP version 5.2).

Verify install

After it’s done you can restart the web server (if the web server doesn’t start check your log files for clues). Then go to the Zend admin panel to see the PHP INFO page. You should see a section that looks like this….

BD… BD.. BD.. That’s all folks

Every server administrator likes to sleep at night and every server admin knows server updates could prove disastrous. Just found out that RPM and Yum allow you the ability to rollback an update if some how it sent your system into a choking fit.

In your /etc/yum.conf add this in there somewhere

tsflags=repackage


This will repackage all your old files from the package (including config files) and store them in /var/spool/repackage

Also add the file /etc/rpm/macros and place this in that new file

%_repackage_all_erasures 1


When things go wrong

If you want to rollback changes to a certain time, then just issue commands like


rpm -Uhv --rollback '9:00 am'
rpm -Uhv --rollback '4 hours ago'
rpm -Uhv --rollback 'december 25'


Untested Yet

This is just stuff I’m reading, I have yet to test this under fire, maybe I’ll play around on a test server

Resources

http://dailypackage.fedorabook.com/index.php?/archives/17-Wednesday-Why-Repackaging-and-Rollbacks.html

This summarizes how I currently set up my servers so that I can have multiple developers accessing certain client files, but retain control on which clients. The key to this whole process is groups.

Users

Create user accounts for your developers.

# useradd developer1
# passwd developer1
# useradd developer2
# passwd developer2


Groups

Create groups that section off your clients. For example.

# groupadd client1
# groupadd client2


Add apache to your groups

The web server is going to need access to the files so we will add apache to any groups we create for this purpose.

# usermod -a -G client1 apache
# usermod -a -G client2 apache

This will add apache to the groups client1 and client2.

Add developers to your groups

Your developers need to access your client files as well so we assign them to the groups. This will assign developer1 -> client1 and developer2 -> client2. Fun stuff.

# usermod -a -G client1 developer1
# usermod -a -G client2 developer2

Note: the “-a” appends, if you don’t have this option, then it overwrites the users groups list, not good.

You could also section off your groups in other ways, such as by website.

DocumentRoot Folders

The web server folders will be located at /var/www/. So you will have :


/var/www/client1
/var/www/client2


Setting the setgid bit


# chmod 2770 /var/www/client1
# chmod 2770 /var/www/client1


Assigning User and Group ownership to the directories

This will have to be done by root, because you cannot assign ownership to another person unless you are root. Also, I created a dummy user of “www” to be the user owning the files, it doesn’t matter who owns the files because we are not relying on that part of the permissions.

# chown www:client1 /var/www/client1
# chown www:client2 /var/www/client2


The permissions on these folders will now look like

#ls -l /var/www/
drwxrws--- 6 www client1 4.0K Apr 14 15:28 client1
drwxrws--- 6 www client2 4.0K Apr 14 15:28 client2


This will ensure that all files and folders created below this directory

Result

Developer1 can access Client1′s files, change them, create new folders/files, but cannot get to Client2′s files. Developer2 has the visa-vers result.

NOTE: any new file created by the developers will be owned by the developer and the group (e.g. the ownership will be developer1:client1). This is not a problem since we are not really checking user level permissions.

Helpful commands

Set the setgid on all folders.


# find ./* -type d -print0 | xargs -0 chmod 2775


Set all files to appropriate permissions


# find ./* -type f -print0 | xargs -0 chmod g+rw