eAccelerator and open_basedir: open_basedir restriction in effect. File() is not within the allowed path(s):
After installing eAccelerator on a CentOS 5.5 server running PHP 5.2.10, a bunch of websites began failing with open_basedir errors like so:
[Fri Jul 16 17:53:50 2010] [error] [client XX.XX.XXX.XXX] PHP Warning: require() [function.require]: open_basedir restriction in effect. File() is not within the allowed path(s): (/home/username/) in /home/username/public_html/wp-settings.php on line 19, referer: http://www.server.com/
After doing some research it turns out that a default option that is compiled into eAccelerator is incompatible with open_basedir. The fix is easy enough, simply re-compile with the --without-eaccelerator-use-inode option like so:
make clean
phpize
./configure --without-eaccelerator-use-inode
make
make install
After re-compiling and installing, make sure you clear out the existing eAccelerator files before restarting Apache:
rm -rf /var/cache/eaccelerator/*
apachectl restart
eAccelerator states that the next version will have this compile option set by default.
Reference:
Slicehost: Setting up a Tor relay on Fedora to help keep Iran connected #IranElection
As many of you know, most of the information from within Iran is coming from on-the-ground new-media and social networking sites such as Twitter, YouTube, and Facebook. This is happening despite crackdowns on communications networks by the Iranian government. The way this information is able to escape the firewalls of Iran is via proxies which relay and "hide" the destination of the communications so that it becomes difficult to block. This allows those on the ground in Iran to communicate with the world instantly and effectively, without fear of government crackdown. But it is a constant arms race. As soon as a relay becomes known by the Iranian government it gets shut down. The only way to keep the lines of communication open are to strengthen the distributed Tor network by adding more relays and bridges, making it more difficult for the Iranian government to block them all.
There have already been great write-ups on how you can contribute to the distributed proxy network Tor:
http://anonygreen.wordpress.com/2009/06/18/how-to-setup-a-tor-relay-or-tor-bridge/
http://smokingfish.blogspot.com/2009/06/brief-introduction-to-tor-and-why-its.html
Please read over those documents for an overview. I wanted to provide detailed instructions on how to get a Tor network set up quickly, easily, and cheaply for those of you who would like to contribute. You can provide invaluable assistance to the people of Iran for as little as 15 minutes of your time and $20/month.
First off, this document assumes you have some system administration knowledge with Linux (Fedora) and are comfortable installing and configuring packages from the command line. If that's you, you can have a Tor relay up and running in about 15 minutes.
Key:
Shell commands are in purple
Config file settings are in blue
-
Register at Slicehost
Slicehost is a VPS provider that allows you to quickly build/deploy webservers very cheaply. Sign up here and purchase the cheapest $20 slice to get started. Pick Fedora 10 as your Linux Distribution. Do not pick Fedora 11, as it is incompatible with the current version of Tor. Once you are registered, Slicehost will email you your IP and root password. It can take a few minutes to build your new slice, so be patient.
-
Slice Security
Log in to your new slice. Please note that this document covers the bare minimum of commands to get Tor up and running. You should follow due diligence when it comes to securing your new slice, something which is outside the scope of this document. Common practice security configurations are recommended. Security is your own responsibility, and I will not be held liable for any security issues with your slice. There are a few bare-minimum security things you should do to your slice:
Change the root password:
passwd rootCreate your own account & set password:
adduser yourusername
passwd yourusernameDisable root login to ssh
vim /etc/ssh/sshd_config
Change to this: PermitRootLogin no
service sshd restartThese steps are the BARE MINIMUM you should do to secure your slice.
-
Update Your System
yum -y update
-
Install Prerequisites
yum install wget vim-enhanced gcc make libevent libevent-devel openssl openssl-devel zlib zlib-devel rpm-build
-
Download Tor & Signature
wget https://www.torproject.org/dist/rpm/tor-0.2.1.16.rc-tor.0.fc10.src.rpm
wget https://www.torproject.org/dist/rpm/tor-0.2.1.16.rc-tor.0.fc10.src.rpm.asc
-
Verify Packages
Follow directions at http://www.torproject.org/verifying-signatures.html.en to verify that you have an authentic RPM and not a fake.
-
Build & Install Tor
rpmbuild --rebuild tor-0.2.1.16.rc-tor.0.fc10.src.rpm
rpm -i rpmbuild/RPMS/x86_64/tor-0.2.1.16.rc-tor.0.fc10.x86_64.rpm
-
Configure Tor
vim /etc/tor/torrc
Change the following settings, substituting your own values for Nickname and Address:
DataDirectory /var/lib/tor
ORPort 9001
DirPort 9030
Nickname YOUR_NICKNAME
Address YOUR.IP.ADDRESS.XX
Save & Exit -
Set Bandwidth Limits for Tor
These settings are largely dependent on which slice you have purchased. The ones you see below are for a 20GB slice, and they allow 2GB of transfer per day, so you should be well within the 20GB slice limit of 100GB/month. If you have purchased a larger slice, these settings can be increased accordingly. Be careful here, incorrect settings can push you over your monthly bandwidth limit very quickly! I did over 12GB of transfer in a little over 8 hours before limiting bandwidth with these settings.
vim /etc/tor/torrc
RelayBandwidthRate 64 KBytes
RelayBandwidthBurst 128 KBytes
AccountingStart day 12:00
AccountingMax 2 GB
Save & Exit. The AccountingStart and AccountingMax settings will limit 2GB max transfer per day, resetting at 12:00 every day. The RelayBandwidthRate and RelayBandwidthBurst settings throttle the bandwidth so that you don't reach AccountingMax after only a few hours. Normally AccountingStart and AccountingMax would be enough to stay within your bandwidth limits, but I want my relay to be available all day rather than reaching AccountingMax and shutting down after a few hours. -
Configure Your Firewall
iptables-save > /etc/sysconfig/iptables.default
iptables-save > /etc/sysconfig/iptables.test
vim /etc/sysconfig/iptables.test
Insert the following settings:
# tor ORPort & DirPort
-A INPUT -p tcp --dport 9001 -j ACCEPT
-A INPUT -p tcp --dport 9030 -j ACCEPT
# tor Allow all outbound traffic
-A OUTPUT -j ACCEPT
Save & Exit.
iptables-restore < /etc/sysconfig/iptables.test
iptables -L (verify the rules are correct)
iptables-save > /etc/sysconfig/iptables
-
Increase the number of open file descriptors
vim /etc/security/limits.conf
Add this line:
_tor hard nofile 32768
Save & Exit
-
Start up the Tor Service
service tor start
If everything starts correctly, you should see output like this:
Starting tor: Jun 21 15:44:04.219 [notice] Tor v0.2.1.15-rc. This is experimental software. Do not rely on it for strong anonymity. (Running on Linux x86_64)
Jun 21 15:44:04.219 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Jun 21 15:44:04.223 [notice] Initialized libevent version 1.4.5-stable using method epoll. Good.
Jun 21 15:44:04.223 [notice] Opening OR listener on 0.0.0.0:9001
Jun 21 15:44:04.223 [notice] Opening Directory listener on 0.0.0.0:9030
Jun 21 15:44:04.223 [notice] Opening Socks listener on 127.0.0.1:9050
/usr/bin/torctl start: tor started [ OK ]
Also, you should view the tor.log and verify that you see the following (after 20-minutes):
cat /var/log/tor/tor.log
Jun 21 15:44:13.835 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jun 21 15:44:13.835 [notice] Bootstrapped 100%: Done.
Jun 21 15:44:13.835 [notice] Now checking whether ORPort XXX.XXX.XXX.XXX:9001 and DirPort XXX.XXX.XXX.XXX:9030 are reachable.. (this may take up to 20 minutes -- look for log messages indicating success)
Jun 21 15:44:18.492 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Jun 21 15:44:18.492 [notice] Not advertising DirPort (Reason: AccountingMax enabled)
Jun 21 15:44:26.804 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jun 21 15:44:43.813 [notice] Performing bandwidth self-test.. done.
If you see some errors or it doesn't start correctly, post in the comments and I'll see if I can help you out. Here are some references to help you get it going:
http://www.torproject.org/docs/tor-doc-unix.html.en#installing
http://www.torproject.org/docs/tor-doc-relay.html.en
That's it! You now have a fully functioning Tor Relay and are helping the Iranian people get news and information out to the rest of the world. The cool thing about Slicehost is that you can easily upgrade your Slice with the click of a button to allow more bandwidth, RAM, and other resources. They also have a Clone option so that once you have your initial Tor slice running, you can clone it multiple times so that you can have multiple Tor servers at a time.
More good reads on Tor and its effect in Iran:
http://blog.torproject.org/blog/measuring-tor-and-iran
http://p10.hostingprod.com/@spyblog.org.uk/blog/2009/06/tor-relays-and-exit-nodes-for-iran-and-for-the-rest-of-us.html
Update 1 - Preventing Abuse by BitTorrent Users
A couple of days after setting up my Tor slice, I received a Digital Millennium Copyright Act (“DMCA”) notice that my relay was hosting copyrighted material and that I would be required to remove it or face having my Slice shut down. Turns out that there are people out there using BitTorrent over the Tor network to transfer copyrighted material. Philosophical debates about BitTorrent and copyright law aside, the whole reason why I am running Tor is to help those in Iran stay connected -- not to assist in the distribution of copyrighted material. So, after a few minutes of research, I found out we can prevent Tor being used by BitTorrent by adjusting your ExitPolicy:
vim /etc/tor/torrc
Add the following:
ExitPolicy reject *:1214
ExitPolicy reject *:4661-4666
ExitPolicy reject *:6346-6429
ExitPolicy reject *:6881-6999
Save & Exit
Restart Tor: service tor restart
You should also probably follow the advice at http://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment
References:
http://www.torproject.org/faq.html.en#ExitPolicies - Exit Policies in Tor
https://www.torproject.org/eff/tor-dmca-response.html - DCMA Response Template
http://www.orient-lodge.com/node/3622?dsq=11687593 - A Slicehost user who also received a DCMA notice
http://www.chrisbrunner.com/?p=119 - Why You Shouldn’t Run BitTorrent Over Tor
Update 2 - Slicehost Responds
After making the adjustments above, I notified Slicehost of my changes and they have responded:
Thank you for your response. We will go ahead and consider this matter resolved. Thank you for your attention to this matter.
Gotta give them credit for understanding that we're trying to help people in Iran -- not to pirate movies. Thanks Slicehost!
Update 3 - Upgraded to 0.2.1.16 & Config Adjustments
I received some configuration recommendations from Andrew Lewman of The Tor Project, and have updated the steps above accordingly.
Apache: Address already in use: make_sock: could not bind to address 0.0.0.0:80
Every now and then my Apache webserver becomes un-responsive, and attempting to restart it with apachectl graceful gives me the following error:
Address already in use: make_sock: could not bind to address 0.0.0.0:80
This error means that there is already a process running that is using port 80, so Apache is unable to start up and use it. To solve this problem, we need to figure out what process is currently using the port in question and kill it so that Apache can start. Use lsof to find out what is using our port:
shell> lsof -i :80
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
httpd 23506 apache 3u IPv6 1206927465 TCP *:http (LISTEN)
You can see from the output of lsof that an httpd process already exists under PID 23506. This is simple enough to get rid of:
shell> kill -9 23506
shell> lsof -i :80
shell> apachectl start
I run lsof again after issuing the kill command to make sure that whatever was using port 80 is gone.
PHP & ionCube Loader: ‘The Loader must appear as the first entry in the php.ini file in Unknown on line 0′
I received the following in my Apache error_log when attempting to load the ionCube loader in my php.ini file:
PHP Fatal error: [ionCube Loader] The Loader must appear as the first entry in the php.ini file in Unknown on line 0
This is because ionCube must be loaded before any of the Zend extensions are. So if you have the Zend extension/optimizer loaded, your php.ini should look like this to get ionCube to work:
[Zend]
zend_extension=/usr/local/ioncube/ioncube_loader_lin_5.1.so
zen_extension_ts=/usr/local/ioncube/ioncube_loader_lin_5.1_ts.so
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.0
zend_optimizer.version=3.3.0a
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so
----------------
Now playing: Tommy McCook & The Aggrovators - A Loving Melody
via FoxyTunes
Cacti on Fedora: Blank Graphs
After getting Cacti up and running successfully on Fedora Core 5, I had a problem with the graphing. Caci was receiving the SNMP data correctly (the graph legends would show the proper data values), but the actual neato colors and lines were absent in the graph image. After some research I found a fix: Everything in the rra file must be owned by the cacti user, or the user running the poller crontab. Pretty simple:
chown -R cacti.cacti /usr/share/cacti/rra
Once the rra files were owned by the cacti user, the graphs started to appear in all their colored and lined splendor!
Apache VirtualHost on Ubuntu
Here's a quickie tutorial on how to add Virtual Hosts to Apache on Ubuntu. This tutorial assumes that you have a basic understanding of Apache configuration and that your Apache is installed and able to serve websites.
- cd /etc/apache2/sites-available
- sudo vim yourdomain.com.conf and enter your VirtualHost directive. Below I've put the most basic example, see Apache docs for details and additional features:
<VirtualHost *>
ServerName yourdomain.com
DocumentRoot /home/youruser/public_html
</VirtualHost>
Save & exit. - sudo vim /etc/hosts and add your new domain to the 127.0.0.1 localhost line so it looks like this:
127.0.0.1 localhost yourdomain.com
Save & exit. - Enable your new virtualhost:
sudo a2ensite yourdomain.com.conf - Reload the Apache configuration:
sudo /etc/init.d/apache2 reload
That's it! Repeat for each of your VirtualHosts.
----------------
Now playing: Alèmayèhu Eshèté - Tchero Adari Nègn
via FoxyTunes
Installing Ubuntu Server on a Dell Inspiron 530
I recently purchased a cheapie Dell Inspiron 530 to use as a new local devbox with the intent of installing Fedora 7 on it (the machine came with Ubuntu Desktop pre-installed). Foolish me, I just assumed that if Ubuntu was compatible with the hardware, then Fedora surely would be as well. WRONG. Fedora was unable to detect/install both the SATA controller and the integrated ethernet port. After a few hours trying to get Fedora to install, I decided to give up and give Ubuntu Server a try. Of course it wasn't easy, so here are some of my notes in getting Ubuntu Server installed onto the Dell Inspiron 530.
I wanted to keep it simple so I just installed all of the defaults presented by the installer, including the LAMP package. Everything installed fine, however, the Integrated Network card was not detected/installed, so here's how to get it up and running by compiling and installing the driver.
- First we need to install some prerequisites that are required in order to compile the driver. Make sure your Ubuntu Server CD is in the CD drive and run the following:
sudo apt-get install linux-headers-2.6.20-15-server
sudo apt-get install gcc - Download the ethernet driver from Intel. The one I used is e1000-7.6.5.tar.gz. If you can't find it at Intel, just Google the filename and I'm sure you'll be able to find it somewhere.
- Burn the driver to a CD, mount it on your Ubuntu machine, and copy it to a local dir:
sudo mkdir /mnt/cdrom
sudo mount /dev/cdrom /mnt/cdrom
sudo cp /mnt/cdrom/e1000-7.6.5.tar.gz /usr/src - Compile and install the driver:
cd /usr/src
tar xfvz e1000-7.6.5.tar.gz
cd e1000-7.6.5/src
sudo make install
sudo modprobe e1000 - Now configure your network card:
sudo vim /etc/network/interfaces and your file should look like this (substitute your IP of choice):
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# This is a list of hotpluggable network interfaces.
# They will be activated automatically by the hotplug subsystem.
mapping hotplug
script grep
map eth0
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.66
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1 - Setup your DNS servers:
sudo vim /etc/resolv.conf and it should look like this (I am using OpenDNS here but you can substitute your own):
nameserver 208.67.222.222
nameserver 208.67.220.220 - Restart the network:
sudo /etc/init.d/networking restart - Upgrade your system for good measure:
sudo apt-get upgrade
That should be enough to get your Ubuntu Server up and running on the Dell Inspiron 530 with full network connectivity. Once you're up and running, here are some other tweaks I did, although some of these may be personal preference.
- I don't like Ubuntu's sudo setup (I prefer log in in as root when needed). Out of the box the root account is disabled and your default account is given admin rights to run commands via sudo. To get around this, simply reset root's password:
sudo passwd root
Now you will be able to su - and log in as root directly. - Install SSH
sudo apt-get install ssh - Disable root login to SSH:
sudo vim /etc/ssh/sshd_config and set the following:
PermitRootLogin no - Change the MySQL root password:
mysqladmin -u root password "newpassword" - Enable Apache's mod_rewrite:
sudo a2enmod rewrite
sudo /etc/init.d/apache2 force-reload - Install some other useful goodies:
sudo apt-get install vim
sudo apt-get install php5-mcrypt
sudo apt-get install php5-curl
sudo apt-get install php5-gd
sudo apt-get install php-pear
sudo pear upgrade-all
sudo pear install mdb2
sudo pear install pear/MDB2#mysqli
----------------
Now playing: Apparat - Steinholz (Monolake Remix)
via FoxyTunes