Archive for March, 2009
Apache web server slow to respond, Poor performance Ubuntu Linux
by swicknire on Mar.14, 2009, under linux/ubuntu
If you’re finding that when going to your web page it’s taking a little too long to make the connection, or its just running sluggsih – it may be trying to resolve your ip via a DNS lookup.
There are many performance tweaking options to tune your apache configuration, but I’m going to start by handling just this one.
Now by default HostnameLookups should be Off. And can be found in
/etc/apache2/apache2.conf
HostnameLookups Off
But you may also want to add it to the httpd.conf
/etc/apache2/httpd.conf
And restart apache
sudo /etc/init.d/apache2 restart
This may or may not fix your performance issues, but it sure did help me greatly! (Even though it was set to off in the apache2.conf file, adding it to the httpd.conf file increased my performance)
An interesting article you may find useful HERE
SSH Slow to respond for password input (timeout problems) Ubuntu Linux
by swicknire on Mar.14, 2009, under linux/ubuntu
If you find your SSH client is taking too long to connect (and ask you for the password), or you’re trying to SFTP and it’s timing out before the password prompt. It’s probably trying to do a DNS lookup!
It’s a quick and easy fix! Just edit the following file:
/etc/ssh/sshd_config
And add or change the following:
UseDNS no
Restart SSH
sudo /etc/init.d/ssh restart
SSL Certificates (ssl_error_rx_record_too_long) Ubuntu Linux
by swicknire on Mar.14, 2009, under linux/ubuntu
It seems obvious you’ve come across the following error while trying to setup SSL certificates on apache.
Error code: ssl_error_rx_record_too_long
Well more often than not, you have something mis-configured! (Likely the listening port: 443). What you might want to do is check that your firewall or iptables allows incoming connections on 443.
Ubuntu:
#sudo ufw allow 443
Ok, wonderful – that probably didn’t fix your problem. But now try going to the following address
http://www.domain.tld:443
If you’ve successfully seen something at the above page, it means your sites are listening on that port for non-ssl. I’ll assume that your apache virtual host file has something along the lines of:
NameVirtualHost *
<VirtualHost *>
What you’re going to want to do is force your vhosts to listen specifically on the proper ports. Changing to the following:
NameVirtualHost *:80
<VirtualHost *:80>
If you’re using ubuntu your ports.conf file should likely have 443 enabled on the listening port, and you may also have default-ssl listed in your /etc/apache2/sites-available/ folder. In which case you may want to enable that.
#sudo a2ensite /etc/apache2/sites-available/default-ssl
Basically that file has the following inside of it
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
…… your server name / document root …..
SSLEngine on
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key</VirtualHost>
</IfModule>
While you can use a single “shared” SSL certificate for multiple hosts, if each host needs it’s own SSL, they will need static ip addresses.
Adding a static route in ubuntu linux
by swicknire on Mar.05, 2009, under linux/ubuntu
You may come across the circumstance where you have one ip subnet with a gateway ip on a different subnet.
Lets say for instance your static ip is 10.10.0.1 and you need to set the gateway as 9.9.0.1. After your initial setup of static ip, you may notice the destination is unreachable.
configure your static ip via command line
sudo nano /etc/netowork/interfaces
if you hapen to be using centos or fedora, you may use something similar to
system-config-network
(or)
setup
in ubuntu using the /etc/network/interfaces file
auto eth0
iface eth0 inet static
address 10.10.0.1
netmask 255.255.255.0
gateway 9.9.0.1
now while all looks right, you probably won’t be able to get online. You can restart your interface with
sudo /etc/init.d/network restart
if you add a custom route to the host and set the default gateway you should then be able to access something
sudo route add -host 9.9.0.1 eth0
sudo route add default gw 9.9.0.1
hopefully everything should be good to go! Make sure that your /etc/resolve.conf file has proper name servers for your isp.
nameserver 123.123.123.123
Now in order to make these changes persistant on startup/reboot you may add them to the /etc/network/interfaces file, but typically that has never worked for me across any distro.
What I do is add them to my rc.local file (which is executed after all other system modules are brought online).
sudo nano /etc/rc.d/rc.local
/sbin/route add -host 9.9.0.1 eth0
/sbin/route add default gw 9.9.0.1
This should help bring your network back online in case of power outage or reboot. Keep in mind that if you /etc/init.d/network restart you will likely have to manually add those routes by hand again. (no biggie).
To check your routing table just simply
route -n
The Problem with openDNS nameservers
by swicknire on Mar.05, 2009, under The Web
First and foremost, openDNS sucks! They’re trying to offer an advantage over how regular DNS works… but to be honest… there is no advantage other than you’re regular run of the mill DNS. When I type something wrong, I want an error! When I type something right and you spit back something wrong, that pisses people off!
Name resolutions are totally wack! If you use openDNS with ubuntu, centos, or most any other linux distro – you may notice you cannot update your systems! Total crap! And who’s to say they don’t inject their own DNS record so that when you mange to update your system – you’re actually installing a root kit embedded into a package you think is legit.
Using openDNS is the absolute biggest security hole you can possibly think of. All those phishing scams you’re afraid of… well they become 100% transparant when you’re relaying off their servers… they can send you to any page they wish to grab facebook passwords, email passwords, whatever! And guess what, you’re none the wiser! Your address bar still has the address you think it is, but you could very well be connected to a different server.