HTTP Blog

We have been experiencing updating problems on SLES 10 SP 2 box and here is the error we got:

ERROR: Failed to download XML metadata: Download failed: (https://nu.novell.com/repo/repoindex.xml) Invalid certificate received form server.

To fix the problem do the following.

Open /etc/zmd/zmd.conf file that will look something like this:

[Advanced]
run-transaction-test=False
security-level=signature

[Server]
bind-ip=127.0.0.1
software-inventory-enabled=False
refresh-interval=86400
remote-enabled=false
require-verified-certs=True
hardware-inventory-enabled=False

[Network]
proxy-url=
proxy-password=
proxy-username=

[Cache]
cache-max-size-in-mb=300

[Debug]
log-soap-xml=False
log-exception-traces=False

and replace

require-verified-certs=True

with

require-verified-certs=False

For one project we are currently implementing ethernet channel bonding on Suse SLES 10 SP 2. It works like a wonder and Yast2 doesn’t interfere or re-configure the ethernet card configuration. More information with detailed howto paper will follow.

Many folks have been getting the error message sending email using php’s mail() function on Fedora, Red Hat Enterprise and Centos boxes, possible many others.

This error usually happens if you are using Postfix or Sendmail MTA. The error shows up in the maillog file as follows:

postfix/sendmail: fatal: Recipient addresses must be specified on the command line or via the -t option

You can fix this problem by editing sendmail_path value in php.ini file and uncommenting the following line (possible, making the changes to it as shown below)

sendmail_path = /usr/sbin/sendmail -t

Restart Apache and see if it works. It does for me

Nowadays there are many providers offering unmanaged dedicated servers with 1000’s GBs of data transfer, but not many say what bandwidth measurement system they have in place.

Over 80% providers use 95% industry burstable bandwidth method that usually not work for all web sites. 95% method is where top 5% burst rate bandwidth are cut off from your monthly bandwidth (usually MRTG) bill. This may sound fine at the beginning but if your web site bursts for more than 36 hours then you will pay for the bandwidth you actually didn’t use. However, 95% method is good when you have a short burst of bandwidth, for example, 25 hours of using full 100Mbps assuming top 5% is removed from the port readings and not counted towards your monthly bandwidth usage. 95% method also counts the highest traffic in or out, but doesn’t not sum it up.

Actual bandwidth method counts all bytes coming in and going out to the switch port your server is connected. Works very well - you pay for the bandwidth you actually use. No more, no less.

So always remember to ask your dedicated server provider what bandwidth method they are using to monitor your bandwidth usage and how much additional transfer will cost.

There are hundreds of quality dedicated server providers around the world. Some dedicated server offers come with 10Mbps and some with 100Mbps up link port speed - what should I chose when ordering a dedicated server?

In order to understand network speed, let’s look at the following transfer speeds and calculations:
1024Kbps = 1Mbps (316GB per month if used 24/7).
10Mbps used 24/7 can transfer 3164GB per month or 105.4GB per day.
100Mbps can transfer 31640GB per month or that is roughly around 1054GB per day.

And that is just in one direction - the server has incoming and outgoing bandwidth. Before you sign-up with a new dedicated server company, ask their sales how they calculate the bandwidth. Is it the highest from incoming or outgoing bandwidth or it’s incoming plus outgoing (in+out).

For the web server or ftp hosting, the highest will be the outgoing bandwidth, unless your clients are uploading ftp files to your server all around the clock, or your server is getting a flood (incoming bandwidth).

Of course the network latency will be much less and files served much faster with 100Mbps up link, comparing to overloaded 10Mbps up link connectivity in peak times. For example 9 users downloading at around 1024Kbps (1Mbps) files from your server will use the 10Mbps up link around 90% of the total capacity or only 9-10% of 100Mbps uplink capacity. This clearly shows that some of the users (or users who will connect to the server) will get some packet loss and transfer speed will decrease on the 10Mbps port, but not on the 100Mbps up link. We believe in our example that there is no packet loss in the upstream providers.

However, if your dedicated server comes with 1000GB of monthly traffic you can easily burn it if you have 100Mbps up link in around 23 hours, or in 12 hours if there is a lot of incoming traffic activity. With 10Mbps up link port you can use your 1000GB allocated monthly traffic only in around 9 days, or 4.5 days if you have 10Mbps of constant incoming and outgoing activity. Real life tests show that your server physically can use around 90Mbps on a 100Mbps up link and 95-100% on 10Mbps up link, however, this really depends on the hardware, including your server and switching/routing fabrics that your upstream is using. We also assume that upstream connectivity is no problem and not oversold.

My suggestion is to use 10Mbps at the start, unless the server comes with 100Mbps up link at the beginning and review your MRTG or RRDTOOL graphs. If you are never reaching 10Mbps or using it very shortly, why do you need to pay $10-$20 for upgrading your port to 100Mbps. If your web site is getting flooded a lot, I would suggest not upgrading to 100Mbps unless you really want it to keep it online, but prepare to pay extra dollars for used bandwidth fees (if incoming bandwidth is not counted towards your dedicated server bandwidth usage, it’s better for you!).

The blue bar above shows average usage of 9.47Mbps incoming bandwidth. That is very close to 10Mbps usage and depending on the traffic patterns I suggest 100Mbps port unless it’s a flood attack (incoming bandwidth!). The outgoing traffic maximum was only 930Kbps, that is below 1Mbps. So I guess no need to upgrade, unless you offer FTP upload service that requires low-latency and speedy incoming bandwidth to the server.

Above graph clearly shows that outgoing bandwidth (the green color bar) went over 20Mbps, actually 21.23Mbps (see the Maximum Inbound value). This will require 100Mbps up link port to serve files without packet loss.

Incoming bandwidth in the above graph shows a bit over of 5Mbps usage. You will be fine with a 10Mbps up link port speed in this case.

Please note: the 95% bandwidth counting method still shows very low usage on the traffic images above. We generated bandwidth bursts to show the traffic patterns and how to read bandwidth usage and examples from RRDTOOL generated logs. Remember, to use 1000GB of monthly bandwidth your outgoing bandwidth should be around 3Mbps on 95% bandwidth billing method.

We used 1024Mb=1GB for bandwidth calculation tables. Some providers use 1000Mb=1GB.