FirstServed Tech Blog - FirstServed and the Art of Server Tuning

If your Windows FTP is working correctly, but some users are reporting "550 Cannot STOR." errors.
It may be a good idea to check your logs for the filenames they are using.

We encountered the same problem on one of our shared Windows servers.
The problem was an illegal filename.

The user was using a mac computer, which allows a filename to contain ":".
The ":" is an illegal character to Windows and will finally result in a "550 Cannot STOR." error.

Due to the raising support questions about mobile internet settings, we felt that to provide better service to our customers we should take a deeper look into these systems and try to at least help people out.

Of course these systems aren’t ours, but since we sell dedicated servers, hosting and mail services we will get in contact with every device present on the internet. And at the moment the amount of cell phones connected to the internet is rising.
This is partly due to the iPhone, but also due to the raising numbers of smart phones available.
We will get into details (as far as we can) about phone or operating system specific settings later.
(Please know that we do not have every phone available so most of these settings were mainly gathered by our own support calls, research on the internet etc.)

On top of that we will only look at GPRS (EDGE) settings. This is because we think GSM-data (WAP) is now obsolete (like 56K modems are) and 3G is not widely adopted enough.

First of all, where is GRPS situated on the GSM network?

When we talk about cell phone technologies we talk about generations, most of these generations have nice names so they are more easy to remember, there’s a small list:

• 1G (first generation): mainly analogues, but wireless phones
• 2G: GSM as we know it on the 850, 900, 1800, 1900 frequencies (includes WAP)
  • 2.5G: GPRS
  • 2.75G: EDGE (EGPRS)
• 3G: UMTS
  • HSDPA
  • HSUPA
  • LTE
• 4G: WiMAX(?) – future

As you can see, GPRS is a step between 2G and 3G, to provide better data transport. Edge was an upgrade to GPRS, it gave us better access and didn’t mean a serious adaption to the carrier network which would be needed for a switch to 3G UMTS.
GSM-data (WAP) fits under 2G, since this was just a data-call between you and the access server, just like our early 56K lines used our phone lines (non-adapted voice-spectrum, ADSL uses the same lines but with other frequencies etc but that’s a bit out of scope here).

Now we know what WAP, GPRS and EDGE means, so when you encounter EDGE settings in your freshly purchased iPhone, know that your are facing a variant of GPRS which you can try to configure. Knowing this can be particularly useful if the salesmen in the shop tell you to configure GPRS.

The second step is to configure your connection.
You can find services and data about the connection on the site of your provider (which is without doubt the most reliable source), but for your convenience we’ve compiled a small list for the 3 major Belgian operators (BASE, Mobistar & Proximus):

Base
APN: gprs.base.be
Username: base
Password: base
Provider URL: http://www.base.be/base/nl/home/private/mobile_internet/base_data/settings/manual_settings/page.aspx/4359

Mobistar
APN:
internet.be (private plan)
web.pro.be (professional plan)
Paswords and IP’s are not required.
If the connection fails: some sources report "mobistar" as username and password.
(unverified source: http://www.intermactivity.be/forum/showthread.php?t=97986)

Proximus
APN: internet.proximus.be
Username: none (leave empty)
Password: none (leave empty)
(Tested by FirstServed)

After entering these settings you should be able to connect to the internet and browse to http://www.firstserved.net or http://www.google.be .
If these 2 sites don’t work, but you can view http://74.125.39.147 (which should show you the Google homepage), then there is something wrong with the DNS settings of your phone. DNS translates names into numbers for example www.google.be becomes 74.125.39.147.
In this case you can try using the OpenDNS systems by manually entering these servers:
Primary DNS: 208.67.222.222
Secondary DNS: 208.67.220.220
With these settings you won’t be using the DNS systems of your provider, but you’ll be using free, publicly available servers.

If you really want to manually set the DNS of your provider, you can use these (unverified) settings:

BASE
Primary DNS: unkown
Secondary DNS: unknown

Mobistar
Primary DNS: 212.65.63.10
Secondary DNS: 212.65.63.145

Proximus
Primary DNS: 195.238.2.21
Secondary DNS: 195.238.2.22

A table of GPRS settings from networks all over the world can be found here: www.taniwha.org.uk/gprs.html .
(Please keep in mind that your provider is still the best place to get these settings, if you want them, contact their support services.)

If you can browse the internet correctly, you are ready to setup your e-mail account on your cell phone.

 

Greets,

Koen

This an easy to implement yet very usefull feature.
For instance, we use it to provide our dedicated servers with a redundant path to the network.

This small walkthrough is based on CentOS, but I’m sure you’ll be able to implement it in other distributions to after having read it.

First of all:
Enable the module in /etc/modprobe.conf and pass the necessary parameters:

alias bond0 bonding
options bond0 mode=balance-alb miimon=100

More information about these parameters and the module can be found here:
http://sourceforge.net/project/showfiles.php?group_id=24692&package_id=146474 (project documentation)
http://surfnet.dl.sourceforge.net/sourceforge/bonding/bonding.txt (direct link)

Now you have actually created your bonding device, the only thing left now is to configure it:

Change directory to the network configuration scripts:

[root@server ~]# cd /etc/sysconfig/network-scripts/

Change the scripts for the underlying interfaces, these should be slaves to the bond:

[root@server network-scripts]# cat ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
MASTER=bond0
SLAVE=yes
[root@server network-scripts]# cat ifcfg-eth1
DEVICE=eth1
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
MASTER=bond0
SLAVE=yes

Now it is time to configure the bond itself, for this example I’ve chosen a DHCP configuration:

[root@server network-scripts]# cat ifcfg-bond0
DEVICE=bond0
BOOTPROTO=dhcp
ONBOOT=yes
[root@server network-scripts]#

You can now restart the network and your bond will be active:

service network restart

 

Greets,

Koen

Hi,

Lately we encountered a network issue with one of our virtualised Windows 2003 servers.
The symptoms:
Long downloads fail, there is no error, the datastream just stops.
Speed drops to zero and stays there.
But not always, it was pretty unpredictable behaviour.

At first we thought this was an IIS issue, so we began to search in that direction.
Changed some parameters, fiddled a bit with the settings…
But no, we were wrong. This was proved by installing Apache on the system and running into the very same problem.
We decided to put a sniffer between our server and another testing machine, only to discover a LOT of bad TCP/IP packets.

A bit demotivated we began a seemingly endless journey on the internet, searching for people who have a problem that resembled ours.
Until we found a post about someone with a Windows 2000 – Xenserver driver issue.
(http://forums.citrix.com/message.jspa?messageID=1337520)
Our attention headed in the direction of the Windows drivers and not to much longer the almighty Google came up with another Citrix post: (http://forums.citrix.com/thread.jspa?threadID=234961&tstart=0).

This issue kind of resembles an old problem we used to have with Xenserver 3.2 and one of your servers… Anyway, that’s not the problem here, but this does kind of prove there is something fishy with these Xen PV drivers. (Citrix people even admitted it in that page!)

So finally, we fixed it by disabling TCP/IP offloading in Windows.

This way not the Xen network card would handle the creation of the TCP checksums, Windows would.
However, this has one downside, it kind of hogs the first CPU.
I managed to get 100% cpu usage on CPU0 only by downloading stuff through IIS, so make sure not to many services are sitting on CPU0 only! (I reconfigured MS SQL to use all the cpu’s but cpu0 to prevent the server from running into problems.)

So, the key to Windows 2003 on XenServer without TCP/IP related headaches is located in the registry at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
DisableTaskOffload=0
(DWORD value. 0 means disable offload, 1 means enable. By default this key will not be there, you can just add it.)

For the real adventurous people out there, you can try RSS (Receive-side Scaling), which should make the other cpu’s available for handling NIC packets.

Personally, I did not test it, but keep in mind that if you DO enable it, this TCP checksum calculation can start having an impact on ALL of your cpu’s.

The key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
EnableRSS=1

If now only  Citrix can fix this out of the box, we can be happy!

Greets,

Koen

So, you are searching for these real old Centos RPMs?
For example for an old kernel module for a machine you can’t reboot.
(Kernel update still means a reboot…)
You can find it here:

vault.centos.org

Hi,

A quick guide on how to create selfsigned certificates using openssl:

Setup Ca environment:

vi /etc/pki/tls/openssl.cnf

dir             = /usr/local/lib/CA     # Where everything is kept

cd /usr/local/lib
mkdir CA
mkdir newcerts private
echo '01' > serial
touch index.txt

cd /usr/local/lib/CA

Generate key:

openssl genrsa -des3 -out server.key 1024

Generating RSA private key, 1024 bit long modulus

......................................++++++

................................................++++++

e is 65537 (0x10001)

Enter pass phrase for server.key:

Verifying - Enter pass phrase for server.key:

Generate self signed root certificate:

openssl req -new -x509 -days 3560 -key server.key -out server.crt

Enter pass phrase for server.key:

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [GB]:BE

State or Province Name (full name) [Berkshire]:Antwerpen

Locality Name (eg, city) [Newbury]:Berchem

Organization Name (eg, company) [My Company Ltd]:FirstServed NV/SA

Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your server's hostname) []:ca.firstserved.net

Email Address []:nospam@firstserved.net

Create client key:

openssl genrsa -out quorumd.key 1024

Generating RSA private key, 1024 bit long modulus

............++++++

.........................................................++++++

e is 65537 (0x10001)

Create the certificate request for the client:

openssl req -new -days 3560 -key quorumd.key -out quorumd.csr

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [GB]:BE

State or Province Name (full name) [Berkshire]:Antwerpen

Locality Name (eg, city) [Newbury]:Berchem

Organization Name (eg, company) [My Company Ltd]:FirstServed NV/SA

Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your server's hostname) []:bemobile

Email Address []:nospam@firstserved.net

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Sign the request using your self-signed certificate:

openssl ca -days 3560 -in quorumd.csr -cert server.crt -keyfile server.key -out quorumd.crt

Using configuration from /etc/pki/tls/openssl.cnf

Enter pass phrase for server.key:

Check that the request matches the signature

Signature ok

Certificate Details:

        Serial Number: 1 (0x1)

        Validity

            Not Before: May 22 10:44:49 2008 GMT

            Not After : Feb 19 10:44:49 2018 GMT

        Subject:

            countryName               = BE

            stateOrProvinceName       = Antwerpen

            organizationName          = FirstServed NV/SA

            commonName                = bemobile

            emailAddress              = nospam@firstserved.net

        X509v3 extensions:

            X509v3 Basic Constraints:

                CA:FALSE

            Netscape Comment:

                OpenSSL Generated Certificate

            X509v3 Subject Key Identifier:

                29:A5:E4:6A:F4:4E:89:35:5D:7D:C6:9A:CE:B9:D0:1B:75:0A:7F:8C

            X509v3 Authority Key Identifier:

                keyid:4B:B2:BA:F6:65:66:60:EB:CC:45:F5:57:34:FB:E9:AB:40:CF:B4:E8

Certificate is to be certified until Feb 19 10:44:49 2018 GMT (3560 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

That should do it.

Koen

Our Mailservers use a separate disk to store the mailboxes.
These are mounted on a folder, but most commonly used via a symbolic link that points to this folder.

This is where bacula gets stuck.
It creates the symbolic link, which is invalid due to the temporaty restore location and then crashes because it cannot create the files and directories.

To solve this, manually create the symbolic link location, but do not create it as a link, create it as a folder.
This is probably a miss-configuration on our side, but it might be a problem nontheless.

Example:
Mail location: /var/spool/mail
Link: /var/mail
Bacula backs up: /var/mail
Manually create /tmp/bacula-restores/var/mail/ to have a successfull restore.

Cisco VPN Client (5.0.01.0600) does work on Vista x86.
It only seems to have problems on localized versions of the OS.

I know this because I installed it on a native english version of Vista and had no problems.
However, my localized (Dutch) version of Viste does throw out some errors during the installation process.

The problem comes from the translations of the user groups in Windows. The installer searches for the "Users" and "INTERACTIVE" usergroups, but is unable to find them because they exist under a different (localized) name. So the solution is to manually make these groups in Vista.
Not a single problem, but Vista Home Premium (the localized version I’m testing on) doesn’t have the GUI components to manage usergroups.
Luckily, we still have the good old "net" command which can do lots of things.
Right before the installation, enter these commands in the command prompt:
    net localgroup Users /add
    net localgroup INTERACTIVE /add
This will create the needed usergroups for the installer.
Now install you VPN client and after installation enter the following commands to remove the groups again. (The client itself works perfectly without these groups.)
    net localgroup Users /delete
    net localgroup INTERACTIVE /delete

The VPN client shouldn’t have any problems running on Vista x86 (tested on Business and Home Premium).

On to the next hurdle! x86_64
(But I’ve heared some rumors on the internet saying I’ll need AnyConnect for that…)

 

You want to use DRBD for mirroring your disks over the network, and put LVM on top of your DRBD disk for flexible disk management?  Try it like this:

1. Setting up DRDB
2. Setting up LVM

However, LVM is rather greedy when it comes to hogging block level devices at boot time.  So, after restarting, it will happily discover your scsi disk, md device, or whatever, and DRBD will spawn some nasty output like:

Starting DRBD resources: [ d0 d1 ioctl(,SET_DISK_CONFIG,) failed:
Invalid argument
Lower device is already mounted.

cmd /sbin/drbdsetup /dev/drbd1 disk /dev/md3 internal -1 failed!

The solution is to edit your lvm.conf to filter out the block devices you've assigned as DRBD devices.  Try modifying your LCM configuration like this ( found in /etc/lvm/lvm.conf on Fedora and Red Hat distros ):

# By default we accept every block device:
# Comment this out:
# filter = [ "a/.*/" ]

# Filter out your DRBD block devices, accept the rest:
filter = [ "r/md3", "a/.*/" ]

After this, rescan your LVM configuration by executing:

pvscan
vgscan
vgchange -a y

And finally start your DRBD daemon:

/etc/init.d drbd start