Archive for the ‘Server’ Category

How to Copy Files with SCP between Linux Servers

Saturday, July 19, 2014 posted by Till

1.1 SCP Command Line-An Overview

 

The SCP command line is commonly used to copy files over SSH, and between popular Operating systems like Linux, Mac and Windows in a secure fashion. SCP is used to copy files to/from a remote server. It also allows you to copy files from one remote server to another remote server, without passing traffic through your PC.

 

1.2 Configuring the System of the Virtual Machine

 

At the outset, for sending files to the virtual machines, you would require a specific set of configuration, as explained below:

1. Open VirtualBox

2. Please select the virtual machine where your target system is running.

3. Open Settings > Network

4. Please select the correct Adapter tab (it will be the first one in case you have not made any changes so far)

5. You must select Bridged Adapterfrom the Attached to dropdown menu.

6. Now, you can run your virtual machine.

 

1.3 Initiating File Copy between Linux Servers Using SCP

 

Once begun, you must open a terminal and key in the following:

sudo apt-get install openssh-server
ifconfig

The ifconfig will throw up a few blocks, like the one titled eth0.

 ctest@ctest-System-Product-Name ~ $ ifconfig
eth0		Link encap:Ethernet  HWaddr f4:6d:04:94:8f:17
inet addr:192.168.0.11  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::f66d:4ff:fe94:8f17/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:234392 errors:0 dropped:0 overruns:0 frame:0
          TX packets:128835 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:332109021 (332.1 MB)  TX bytes:11758082 (11.7 MB)
          Interrupt:43 Base address:0x6000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:39 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2424 (2.4 KB)  TX bytes:2424 (2.4 KB)

ctest@ctest-System-Product-Name ~ $

The IP address exhibited on inet adress: is the one your machine would have in your internal network, and it will be the one you are going to access the machine under. Here, you must revisit the sender system now that you are aware of the IP of the receiver. If you possess the files to be sent, in addition to the directory for storing these on your virtual machine ready, you may simply go ahead and send the file by using the following command:

scp [path of file to send] root@[receiver's IP]:[target directory]

In the above command, you must replace the items in brackets [] with actual values.

For instance, if you wish to send a file titled MyVideo.mp4 housed in the /home/ctest/Videosdirectory to the /home/cooldude/Videos directory of the system that has an internal IP of 191.167.1.61, you must use the following command line:

scp /home/ctest/Videos/MyVideo.mp4 root@191.167.1.61:/home/cooldude/Videos

 

1.4 Fixing Errors

 

Post entering the basic SCP command, you may encounter the following message:

 

ctest@ctest-System-Product-Name ~ $ scp /home/ctest/Videos/MyVideo.mp4 root@191.167.1.61:/home/cooldude/Videos
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@  WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
4e:c0:50:9a:cf:b6:bc:45:ed:9b:54:97:d8:11:21:a8.
Please contact your system administrator.
Add correct host key in /home/ctest/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/ctest/.ssh/known_hosts:4
  remove with: ssh-keygen -f "/home/ctest/.ssh/known_hosts" -R 191.167.1.61
ECDSA host key for 191.167.1.61has changed and you have requested strict checking.
Host key verification failed.
lost connection
ctest@ctest-System-Product-Name ~ $

More often than not, this is caused when the system with the given IP is no longer the same as it was when you last connected to the same IP. For instance, if you happened to host a new virtual machine that subsequently took the same IP as the old one.
To fix this one, you must follow the commands given in the message to remove the offending key (as shown below):

ssh-keygen -f "/home/ctest/.ssh/known_hosts" -R 191.167.1.61

You must ensure that you replace the path and the IP with the ones matching your specific inputs. You may also remove the key manually by opening the known_host file with the help of a texteditor, and removing the key (obviously as root).

 

1.5 Completing the Process

 

If, however, you do not come across any such issue, or you have managed to tackle the same, you would be asked if you really wish to proceed. You must key in yesand hit Enter to confirm the same.

Next, you’ll be asked for the root password of the receiver, which you must key in and before hitting Enter once again.

Now, the copied file must be accessible on the intended directory of the receiver, although you must not have any permissions to write/execute the same. If, however, you are seeking full permissions, please use the following command:

sudo chmod 777 /home/cooldude/Videos/MyVideo.mp4

Here, you must remember to change the path value to the one corresponding to your file, and you are good to go!

If your mail server stops working (neither incoming nor outgoing email works) and you find the following error message in the mail.log file:

fatal: open database /var/lib/postfix/smtpd_scache.db: File exists

then the smtpd_scache.db might got corrupted. Postfix will recreate this file, if it does not exist. So it can be removed to solve the issue:

/etc/init.d/postfix stop
rm -f /var/lib/postfix/smtpd_scache.db
/etc/init.d/postfix start

Thanks to Alexander Fox for sending me this FAQ.

Dovecot is watching the whole server filesystem for modifications and removed or added sub filesystems. If you get errors similar to this one on your server:

Aug 30 09:10:23 server1 dovecot: master: Warning: /var/www/clients/client1/web1/log is no longer mounted. If this is intentional, remove it with doveadm mount

 (the directory path may vary), then you can fix it by excluding the path from being watched by dovecot. In my case, dovecot shall not watch my website directories as they do not contain any mailboxes

Run the following command on the shell as root user:

doveadm mount add '/var/www/*' ignore

To exclude all files and folders in /var/www from deovecot monitoring.

 

If you get error messages from amavisd similar to the one posted below on a server which is virtualized with OpenVZ:

Mar  5 09:09:02 v100 amavis[17378]: (17378-14) (!!)TROUBLE in process_request: Error writing a SMTP response to the socket: Broken pipe at (eval 100) line 987, <GEN44> line 31.

then the issue can be caused by the NUMTCPSOCK value in the openvz limits. Even if the barrier of this limit was never met in /proc/user_beancounters, the above error occurs when more then 25% of all TCP sockets were used. The solution is to set the NUMTCPSOCK barrier and limit to a high value in the openvz container configuration file. Here a value that worked for me on a moderately used mailserver:

NUMTCPSOCK="2000:2000"

Finally restart the OpenVZ VM to apply the new limit value.

 

Apache mod_security settings for WordPress and ModX

Monday, January 7, 2013 posted by Till

If you use the apache mod_security module on your apache server, you might encounter wrong 403 errors for several URL's of the cms systems. Here are some exception rules to avoid that:

For WordPress Blogs

<locationmatch "/wp-admin/admin-ajax.php">
SecRuleRemoveById 300013
SecRuleRemoveById 300015
SecRuleRemoveById 300016
SecRuleRemoveById 300017
</locationmatch>

<locationmatch "/wp-admin/page.php">
SecRuleRemoveById 300013
SecRuleRemoveById 300015
SecRuleRemoveById 300016
SecRuleRemoveById 300017
</locationmatch>

<locationmatch "/wp-admin/post.php">
SecRuleRemoveById 300013
SecRuleRemoveById 300015
SecRuleRemoveById 300016
SecRuleRemoveById 300017
</locationmatch>

For the ModX CMS

<LocationMatch "/manager/index.php">
SecRuleRemoveById 300016
</LocationMatch>

<LocationMatch "/connectors/resource/index.php">
SecRuleRemoveById 300013 300014 300015 300016
</LocationMatch>

<LocationMatch "/connectors/element/tv.php">
SecRuleRemoveById 300013 300016
</LocationMatch>

Add these rules inside the vhost file of the website. If you use ISPConfig to manage the server, then add the rules in the apache directives field of the website settings in ispconfig.

Many thanks to PlanetFox for providing the rules.

The following guide shows how to disable and remove mysql replication from two or more mysql servers. These steps can be used for master/slave and master/master mysql setups. The following SQL commands have to be be executed in phpmyadmin or with the mysql commandline program. It is just important that you are logged in as mysql root user. Below I will use the mysql commandline client.

Login into mysql as root user from commandline:

mysql -u root -p

the mysql command will ask for the mysql root password.

Then execute these commands if the installed mysql version is < 5.5.16:

STOP SLAVE;
RESET SLAVE;
QUIT

use the commands below instead if the mysql version is > 5.5.16

STOP SLAVE;
RESET SLAVE ALL;
QUIT

Now edit the my.cnf file (/etc/mysql/my.cnf) and add a # in front of all lines that start with "replicate-" or "master-". Example:

# replicate-same-server-id = 0
# master-host = 192.168.0.105
# master-user = slaveuser
# master-password = akst6Wqcz2B
# master-connect-retry = 60

Then restart mysql:

/etc/init.d/mysql restart

 

Setting up email routing to gmail / google apps via ISPConfig 3

Thursday, November 29, 2012 posted by Till

The following guide describes the steps to add DNS records that route emails from a domain managed in ISPConfig 3 to google apps / gmail. The guide assumes that you have already setup the dns zone for your domain in ispconfig.

Login to ISPConfig, click on the DNS module icon in the upper navigation bar, then open the settings of the DNS zone that you want to redirect to google and click on the "records" tab. You should see a record list similar to this:

Now Delete the existing MX record and the "mail" A-Record. Then add the following new records:

CNAME Record:

Hostname: mail
Target: ghs.google.com.

MX Records:

example.com. ASPMX.L.GOOGLE.COM. 10
example.com. ALT1.ASPMX.L.GOOGLE.COM. 20
example.com. ALT2.ASPMX.L.GOOGLE.COM. 30
example.com. ASPMX2.GOOGLEMAIL.COM. 40
example.com. ASPMX3.GOOGLEMAIL.COM. 50

IMPORTANT: All full domain names like "ghs.google.com." have to end with a dot, if the dot is missing, the name is treated as subdomain of the zone.

The resulting record list should look like this:

Install BIND nameserver in a chroot on Debian 6

Wednesday, October 17, 2012 posted by Till

This tutorial is about chrooting a BIND (named) installation on Debian 6. Chrooting is used for security reasons, in case that BIND gets hacked on the server, the hacker is jailed into the chroot and can not get access to other services.

 

Installation

 

apt-get install bind9

to install BIND9.

For security reasons we want to run BIND chrooted so we have to do the following steps:

/etc/init.d/bind9 stop

Edit the file /etc/default/bind9 so that the daemon will run as the unprivileged user bind, chrooted to /var/lib/named. Modify the line: OPTIONS="-u bind" so that it reads OPTIONS="-u bind -t /var/lib/named":

vi /etc/default/bind9

# run resolvconf?
RESOLVCONF=yes

# startup options for the server
OPTIONS="-u bind -t /var/lib/named"
Create the necessary directories under /var/lib:

mkdir -p /var/lib/named/etc
mkdir /var/lib/named/dev
mkdir -p /var/lib/named/var/cache/bind
mkdir -p /var/lib/named/var/run/bind/run

Then move the config directory from /etc to /var/lib/named/etc:

mv /etc/bind /var/lib/named/etc

Create a symlink to the new config directory from the old location (to avoid problems when BIND gets updated in the future):

ln -s /var/lib/named/etc/bind /etc/bind

Make null and random devices, and fix permissions of the directories:

mknod /var/lib/named/dev/null c 1 3
mknod /var/lib/named/dev/random c 1 8
chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random
chown -R bind:bind /var/lib/named/var/*
chown -R bind:bind /var/lib/named/etc/bind

We need to create the file /etc/rsyslog.d/bind-chroot.conf...

vi /etc/rsyslog.d/bind-chroot.conf

... with the following line so that we can still get important messages logged to the system logs:

$AddUnixListenSocket /var/lib/named/dev/log

Restart the logging daemon:

/etc/init.d/rsyslog restart

Start up BIND, and check /var/log/syslog for errors:

/etc/init.d/bind9 start

Thanks to Falko Timme from Howtoforge.com for this tutorial.

 

If you get a 500 error in a webpage hosted on Debian Linux (6.0) with apache webserver and fastcgi, take a look into the apache error.log file. This can either be the global error.log or the error.log of the website where you got the error. If you find a error similar to this one:

[Fri Apr 10 15:18:05 2012] [warn] [client 192.168.0.55] mod_fcgid: HTTP request length 134926 (so far) exceeds MaxRequestLen (131072), referer: http://www.example.tld/administrator/index.php?option=com_installer

then the MaxRequestLen setting of mod_fccgid is too low. To fix that, edit the file /etc/apache2/mods-available/fcgid.conf

vi /etc/apache2/mods-available/fcgid.conf

and add or edit the line "MaxRequestLen 15728640" to set the Request Limit to 15MB. The resulting file should contain these settings:

AddHandler fcgid-script .fcgi
FcgidConnectTimeout 20
MaxRequestLen 15728640

Save the changes and restart apache:

/etc/init.d/apache2 restart

Apache mod-security installation on Debian 6.0 (squeeze)

Monday, January 2, 2012 posted by Till

Install the apache mod-security 2 module with apt from the Debian repositories

apt-get install libapache-mod-security

Create the folder for the mod-security configuration files

mkdir /etc/apache2/mod-security
chmod 600 /etc/apache2/mod-security

Download and unpack the mod-security rules

cd /tmp
wget http://www.modsecurity.org/download/modsecurity-core-rules_2.5-1.6.1.tar.gz
tar fvx modsecurity-core-rules_2.5-1.6.1.tar.gz
mv *.conf /etc/apache2/mod-security/
ln -s /var/log/apache2 /etc/apache2/logs

Configure apache to load the activated mod-security rules

vi /etc/apache2/conf.d/mod-security.conf

Include /etc/apache2/mod-security/*.conf

To enable mod-security, edit the file

vi /etc/apache2/mod-security/modsecurity_crs_10_config.conf

and remove the # in front of the line:

SecDefaultAction "phase:2,log,deny,status:403,t:lowercase,t:replaceNulls,t:compressWhitespace"

Then reload apache.

/etc/init.d/apache2 force-reload

Mod security will now start to block hack attempts to your websites and log the actions in the file /var/log/apache2/modsec_audit.log.

tail /var/log/apache2/modsec_audit.log

You will see very likely some falsely blocked URL's. To whitelist them, you can add the ID's of the rules that should not be used in the whitelist file.

Example:

vi /etc/apache2/mod-security/modsecurity_crs_99_whitelist.conf

SecRuleRemoveById 960015
SecRuleRemoveById 960016