Linux

Sometimes you need something that can kick a host a bit harder than the standard reboot command. Even if you include the -f switch to force, a hung task can prevent your host from rebooting.

Try this - first enable the sysrq setting, then trigger. Your host should reboot immediately.

sudo echo 1 > /proc/sys/kernel/sysrq
sudo echo b > /proc/sysrq-trigger

Note : This is effectively a hard reset which does not cleanly shut services or tasks down. You may need to check your disk on some operating systems.

Previously to take down this wordpress site all you needed to do was hold down F5 for about 20 seconds then the site would take about 5 mins to recover.

There were a few factors causing this and quite a few different methods to solving the problem. Wordpress itself is run on php / apache, apache has an evasive mod which can block certain IPs depending on the defined abusive behavior (typical DDOS attack). Since i like to run a few websites behind a single IP i looked at fixing the issue closer to the perimeter….

I use angry IP scanner in windows, linux has a good util for port scanning an ip range called nmap;

Grab nmap from usual repositories

sudo nmap -sP 192.168.9.0/24 (will show hosts up and resolve mac addresses to vendors)

sudo nmap -v -sT 192.168.9.0/24 (will show hosts up and the various open ports)

sudo nmap -v -sT 192.168.9.104 (will show particular host and the various open ports)

Starting Nmap 6.00 ( http://nmap.org ) at 2013-07-12 11:48 NZST Initiating ARP Ping Scan at 11:48 Scanning 192.168.9.104 [1 port] Completed ARP Ping Scan at 11:48, 0.00s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 11:48 Completed Parallel DNS resolution of 1 host. at 11:48, 0.00s elapsed Initiating Connect Scan at 11:48 Scanning win2012-veeam.fritz.box (192.168.9.104) [1000 ports] Discovered open port 111/tcp on 192.168.9.104 Discovered open port 445/tcp on 192.168.9.104 Discovered open port 3389/tcp on 192.168.9.104 Discovered open port 135/tcp on 192.168.9.104 Discovered open port 139/tcp on 192.168.9.104 Discovered open port 49155/tcp on 192.168.9.104 Discovered open port 1063/tcp on 192.168.9.104 Discovered open port 2049/tcp on 192.168.9.104 Discovered open port 3260/tcp on 192.168.9.104 Completed Connect Scan at 11:48, 4.21s elapsed (1000 total ports) Nmap scan report for win2012-veeam.fritz.box (192.168.9.104) Host is up (0.00059s latency). Not shown: 991 filtered ports PORT STATE SERVICE 111/tcp open rpcbind 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 1063/tcp open kyoceranetdev 2049/tcp open nfs 3260/tcp open iscsi 3389/tcp open ms-wbt-server 49155/tcp open unknown MAC Address: 00:50:56:9C:68:FA (VMware)

I’m using the following crontab script to renice my squid process….

Put following in script and  call via cron (i’m doing every 10 mins)

*/10 * * * * /home/user/renice.sh

(renice.sh)

renice -15 $(ps -C squid3 -o pid=) renice -15 $(ps -C unlinkd -o pid=)

fire up the vm, then run the following after initiating a vmware tools install…

mount /dev/cdrom /mnt/cdrom cd /tmp tar zxf /mnt/cdrom/VMwareTools-x.x.x.gz cd vmware-tools-disstrib ./vmware-install.pl

Then just follow the prompts through to the end.

If your running fedora or similar make sure your’ve got gcc and kernel headers…. (you’ll probably have to update kernel too)

yum update shutdown -r now yum install -y gcc make kernel-devel perl

Ubuntu 12.x

apt-get install open-vm-tools

I’ve had some problems since my upgrade to virtualbox 2.2.0 on OpenSolaris. After some time all of my linux boxes seem to just die. The virtual machine just stops responding. Strangely there was no problem with my windows vms after the update.

From what i can tell it looks like the upgrade turned off “IO APIC” - this is the bit that seemed to cause the problem. Re-enabling this on all of my linux boxes seems to have fixed the problem. I’ll continue testing for another week and update this post if any problems re-occur.

How to install DHCP and DNS on Fedora / Centos / Redhat box;

yum -y install dhcp.i386 bind.i386

Set services to auto start using ntsysv – services are called “dhcpd” and “named”.

How to configure dhcp;

nano /etc/dhcpd.conf — configure as per sample provided. The sample is usually located in the same directory. service dhcpd restart - should start without problem if done correctly

Note: dhcp range has to be on the same network as your adapter. You can run dhcpd from the command line to diagnose any issues.

The following works on CentOs / Fedora / redhat etc… 

Logon to your distro. The packages you need are the kernel-devel.i686, kernel.i686 (if not the latest), and gcc.i386 (complier)

yum -y install kernel.i686 gcc.i386

reboot as the kernel needs to load, then logon again install the kernel dev; 

yum -y install kernel-devel.i686

Now you want to present the virtualbox additions to the cdrom drive on your distro. Click “install additions” on the virtualbox guest console. 

Time to schedule some tasks!

First you need to make sure your in the /etc/cron.d/cron.allow file. If you are not SU to root and add yourself into it.

Now to create your new crontab file;

crontab -e

You are in vi in your newly created crontab file (note if you do not have access to do this it will say so)

Now, i’m no expert at using vi, but if you press i you will go into insert mode. Do this, then type the cron job details. A typical cron job will look like this

Or lack of.

You must insure that your drives are using the sata driver (if they are sata disks), quickest way to check is that they will be called sda sdb etc…. and not hda hdb, as this is the default IDE driver and will slow down the performance majorly.

How to check performance;

hdparm -tT /dev/hda

Modern drives should be getting over 50MB/s easily. If your getting about 5MB/s you have the problem.

How to set the time in Linux; (from a command line)

date -s “09/21/2007 09:20:00”

hwclock –systohc

the second command links the time back to the hardware clock.

Note: within a vm guest it is always advised to install the guest additions as the time on a guest can slowly move away from the correct time.

these are tested from experience…. (the following is true on vmware server 1.0.6 on a linux host)

• Always use only 1 Virtual CPU - i have found that most times even if you have heaps of cores to spare on the host, a single virtual core is faster.
• Set the memory to the recommended level when possible - 256Mb sounds shit when you have 4gb, doesn’t matter - set it to 256Mb (increase only if excessive paging on the guest). Let linux and vmware manage the memory, in most cases it does a much better job than windows. Do not disable memory page trimming on any of the guests, this gives more memory back to the host to cache other more important activity (disk etc)
• Never use 2gb split files for the virtual disk unless you have to transfer the vm onto a file system that doesn’t support larger files.
• Load the latest drivers for your NIC on the host
• Be nice to your physical disk - do not load all your VM’s on a single drive - the HDD is the slowest part of the system, dont saturate it. I use either a raid 0 running multiple vm’s (with backups) or dedicated drives per set of vm’s. This excludes enterprise level raids which can handle much higher level of simultaneous requests.
• Install vmware tools on all guest machines

watch your pings - ping your guests… they should never loose a ping. If they do you are loading the cpu to high and the host cannot process the network queries. As above use only one virtual cpu. Also ensure you have the latest network driver loaded for your NIC on the host.