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.
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
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.
I just upgraded Spamassassin, and low, after I restarted it I received an error message while trying to start Spamassassin. [root]# /etc/init.d/spamassassin start Starting spamd: child process  exited or timed out without signaling production of a PID file: exit 255 at /usr/bin/spamd line 2588. [FAILED] Per the article below, a simple sa-update at the command line updated the Spamassassin rules. Then it would start like normal. Resources: http://www.elehost.com/faq/web-tool-tips-and-fixes/54-spamassassin/172-fix-for-sa-spamd-error-qchild-process-exited-or-timed-out-without-signaling-production-of-a-pid-fileq
umask is linux’s way of determining default file/folder permissions when new files and folders are created. It’s a little odd in that the umask is subtracted from 777 for folders and 666 for files to get the correct permissions. I don’t claim to understand fully, but it just is. What is your current umask? umask 0002 By default, normal users will get a umask of 0002 = 775 on a folder and 664 on a file.
I have a program that needs to talk to another server, but to secure the traffic I’ve set up a port forwarding SSH tunnel. The only problem is that this tunnel needs to be kept alive and started when the server boots up. Here is how, using /etc/inittab For the server you want to make connections from follow these instructions. Open up /etc/inittab and insert this code somewhere near the bottom `
Running out of space on the backup drive, I added another 1.5TB drive to the existing one to hold the company backup files. We do rsync style snapshots with a linux server and it was at 80% capacity. So I added another Seagate SATA to the simple Hardware RAID SATA card in the machine. Everything went well. Ran fdisk to partition the drive, ran mke2fs -f /dev/hde1 to format in EXT3 format.
Interesting that since moving to a new ISP my login times to a particular Linux server is 20-30 seconds. I figured it had to do with reverse DNS somehow. Sure enough…. /etc/ssh/sshd_config UseDNS no That made the logins quick again and that makes me HAPPY! Credit: http://www.netadmintools.com/art605.html
When I launched some larger sites on Magento in August 2009 I was sold on the slight performance increase that memcache provided the cart. However, I ran into a few bugs and other anomalies that have caused me to abandon the use of memcache with Magento. Please note, it could be my implementation that was causing the problem since it was my first foray into memcache. Two problems Magento and Memcache caused
Some pages in Magento were giving just a white page, with no indication of errors in Zend Server console or log files. This was apparently a memory issue, so I restarted the web server and all was fine. One issue I noticed was the server “setroubleshoot” was taking 12% of the systems memory. This program just logs issues with SELinux and it seems SELinux doesn’t like my Magento install. I have SELinux just set to ‘warn’, but I may want to disable it all together.