Racker Hacker

If you need to change to a different primary IP in Plesk, here’s the easiest way:

In Plesk 7 there is no concept of the Primary IP address for the server. From the Control panels point of view all IP addresses are equal. The only difference between the main IP address and aliases is that the main IP address can not be deleted from the control panel.

To change the main IP address you need to first remove this address from all IP pools. Then stop Plesk and manually change the IP address on the server from the backend as root. Then start Plesk again and restore the list of IP addresses through SERVER -> IP Aliasing and click on Re-read button.

To disable SSLv2 server-wide on a Plesk server, add this in your /etc/httpd/conf.d/ssl.conf:

SSLCipherSuite ALL:!ADH:!LOW:!SSLv2:!EXP:+HIGH:+MEDIUM
SSLProtocol all -SSLv2

Put the directive very high in the file, outside the VirtualHost directive, preferably right below the Listen directive. This will work for all SSL VirtualHosts.

How can I ensure that Apache does not allow SSL 2.0 protocol that has known weaknesses?

To send e-mail properly to AOL and Hotmail, three things must match:

• Your IP must have reverse DNS.
• If you ask for the forward DNS record for the reverse, it must match.
• Your mail server’s HELO must match the DNS records.

If you need to test your setup, use these commands.

$ host mhtx.net
mhtx.net has address 209.61.157.17
$ host 209.61.157.17
17.157.61.209.in-addr.arpa domain name pointer mhtx.net.
$ telnet 209.61.157.17 25
Trying 209.61.157.17…
Connected to mhtx.net.
Escape character is ‘^]’.
220 mhtx.net ESMTP Postfix

You can edit /etc/drweb/drweb_qmail.conf to eliminate receiving notification messages when Dr. Web has an issue:

[VirusNotifications]
SenderNotify = no
AdminNotify = no
RcptsNotify = no

Then just restart Dr. Web with:

/etc/init.d/drwebd restart

Plesk has a KB article about this issue as well.

If you want to hide the current version of Apache and your OS, just replace

ServerTokens OS

with

ServerTokens Prod

and restart Apache.

As you may or may not know, there’s new Daylight Savings Time changes in 2007. It starts earlier this year on March 11th. There’s already new packages available for Redhat, Gentoo (more), and Debian (more).

For a tubload of other OSes, check here.

A really really strange issue randomly appears with ProFTPD and Plesk occasionally. On the filesystem, a file will have a correct creation/modification date, but then when you view it over FTP, it’s always off by the amount of hours you differ from GMT.

For example, if the server is on Central Time, all of the files will seem to be created 6 hours after they were really created. The filesystem will show something like 10AM, but the FTP client will say 4PM. Luckily, there is a fix!

Add the following to your /etc/proftpd.conf file and you should be good to go:

TimesGMT off
SetEnv TZ :/etc/localtime

If you’ve ever worked on a linux system, chances are that you’ve used chmod many times. However, the quickest way to stump many linux users is to ask how many octets a full permissions set has. Many people think of this and say three:

chmod 777 file

But what you’re actually saying:

chmod 0777 file

The first octet works the same way as the other three as it has 3 possible values that add to make the octet (for the letter-lovers, i’ve included those too):

4 - setuid (letter-style: s)
2 - setgid (letter-style: s)
1 - sticky bit (letter-style: t)

Remember - your first octet will always be reset to 0 when using chown or chgrp on files.

Setuid
If you setuid on a binary, you’re telling the operating system that you want this binary to always be executed as the user owner of the binary. So, let’s say the permissions on a binary are set like so:

# chmod 4750 some_binary
# ls -al some_binary
-rwsr-x--- 1 root users 0 Feb 13 21:43 some_binary

You’ll notice the small ’s’ in the user permissions blocks - this means that if a user on the system executes this binary, it will run as root with full root permissions. Obviously, anyone in the users group can run this binary since the execute bit is set for the group, but when the binary runs, it will run with root permissions. Be smart with setuid! Anything higher than 4750 can be very dangerous as it allows the world to run the binary as the root user. Also, if you allow full access plus setgid, you will be opening yourself up for something mighty nasty:

# chmod 4777 some_binary
# ls -al some_binary
-rwsrwxrwx 1 root users 0 Feb 13 21:43 some_binary

Not only can every user on the system execute this binary, but they can edit it before it runs at root! It goes without saying, but this could be used to beat up your system pretty badly. If you neglect to allow enough user permissions for execution, linux laughs at you by throwing the uppercase ‘S’ into your terminal:

# chmod 4400 some_binary
# ls -al some_binary
-r-S------ 1 root users 0 Feb 13 21:43 some_binary

Since no one can execute this script anyways (except root), you get the big capital ‘S’ for ‘Silly’. (It probably doesn’t stand for silly, but whatever.)

Setgid
Setgid is pretty much the exact same as setuid, but the binary runs with the privileges of the owner group rather than the user’s primary group privileges. This isn’t quite so useful in my opinion, but in case you need it, here’s how the permissions come out:

# chmod 2750 some_binary
# ls -al some_binary
-rwxr-s--- 1 root users 0 Feb 13 21:43 some_binary

And if you enjoy being made fun of:

# chmod 2400 some_binary
# ls -al some_binary
-r----S--- 1 root users 0 Feb 13 21:43 some_binary

Sticky Bit
This is such a giggly term for a linux file permission, but it’s rather important, and it best applies to your tmp directory (or any other world writable location). Since world writable locations allow users to go hog-wild with creating, editing, appending, and deleting files, this can get annoying if certain users share a common directory.

Let’s say users work in an office and they work on files in a world writeable directory. One user gets mad because another user got a raise, so they trash all of the files that belong to that recently promoted user. Obviously, this could lead to a touchy situation. If you apply the sticky bit on the directory, the users can do anything they want to files they create, but they can’t write to or delete files which they didn’t create. Pretty slick, er, sticky, right? Here’s how to set the sticky bit:

#chmod 1777 /tmp
# ls -ld /tmp
drwxrwxrwt 3 root root 4096 Feb 13 21:57 /tmp

And again, linux will laugh at you for setting sticky bits on non-world writable directories, but this time it does so with a capital ‘T’:

#chmod 1744 /tmp
# ls -ld /tmp
drw-r--r-T 3 root root 4096 Feb 13 21:57 /tmp

Setuid + Setgid on Directories
Setting the setgid bit on a directory means any files created in that directory will be owned by the group who owns the directory. No matter what your primary group is, any files you make will be owned by the group who owns the directory.

Setting the setuid bit on a directory has no effect in almost all Linux variants. However, in FreeBSD, it acts the same as the setgid (except it changes the ownership of new files as the user who owns the folder).

LVM is handy when you want additional flexibility to grow or shrink your storage space safely without impacting filesystems negatively. It’s key to remember that LVM provides flexibility - not redundancy. The best way to understand LVM is to understand four terms: physical volumes, physical extents, volume groups and logical volumes.

Physical volumes are probably the easiest to understand for most users. The stuff you deal with all day, /dev/hda2, /dev/sd3 - these are physical volumes. They’re real hard drive partitions which are finitely defined. LVM comes along and chops those physical volumes up into little pieces called physical extents. Extents are simply just pieces of a regular system partition, and the size of the extent is determined by the OS.

So what happens with these extents? You can pool a group of extents together to form a volume group. From there, you can carve out chunks of the extents from the volume group to make logical volumes.

Confused? You should be! Let’s try an example:

You have two system partitions: /dev/sda2 and /dev/sda3. Let’s say that /dev/sda2 has 1,000 extents and /dev/sda3 has 2,000 extents. The first thing you’ll want to do is initialize the physical volumes, which basically tells LVM you want to chop them up into pieces so you can use them later:

# pvcreate /dev/sda2
# pvcreate /dev/sda3

Graphically, here’s what’s happened so far:

  +-----[ Physical Volume ]——+
  | PE | PE | PE | PE | PE | PE  |
  +——————————+

Now, LVM has split these physical volumes (partitions) into small pieces called extents. So, we should have 3,000 extents total once we create the physical volumes with LVM (1,000 for sda2 and 2,000 for sda3). Now, we need to take all of these extents and put them into a group, called the volume group:

vgcreate test /dev/sda2 /dev/sda3

Again, here’s what we’ve done:

  +------[ Volume Group ]—————–+
  |  +–[PV]——–+  +–[PV]———+  |
  |  | PE | PE | PE |  | PE | PE | PE  |  |
  |  +————–+  +—————+  |
  +—————————————+

So what’s happened so far? The physical volumes (partitions) are unchanged, but LVM has split them into extents, and we’ve now told LVM that we want to include the extents from both physical volumes in a volume group called test. The volume group test is basically a big bucket holding all of our extents from both physical volumes. To move on, you need to find out how many extents we have in our volume group now:

vgdisplay -v test

We should see that Total PE in the output shows 3,000, with a Free PE of 3,000 since we haven’t done anything with our extents yet. Now we can take all these extents in the volume group and lump them together into a 1,500 extent partition:

lvcreate -l 1500 -n FIRST test

What did we just do? We made a real linux volume called /dev/test/FIRST that has 1,500 extents. Toss a filesystem onto that new volume and you’re good to go:

mke2fs -j /dev/test/FIRST

So, this new logical volume contains 1,500 extents, which means we have 1,500 left over. Might as well make a second volume out of the remaining extents in our volume group:

lvcreate -l 1500 -n SECOND test
mke2fs -j /dev/test/SECOND

Now you have two equal sized logical volumes whereas you had one small one (sda2) and one large one (sda3) before. The two logical volumes use extents from both physical volumes that are both held within the same volume group. You end up with something like this:

  +------[ Volume Group ]—————–+
  |  +–[PV]——–+  +–[PV]———+  |
  |  | PE | PE | PE |  | PE | PE | PE  |  |
  |  +–+—+—+—+  +-+—-+—-+—+  |
  |     |   |   | +—–/     |    |      |
  |     |   |   | |           |    |      |
  |   +-+—+—+-+      +—-+—-+–+   |
  |   |  Logical  |      |  Logical   |   |
  |   |  Volume   |      |   Volume   |   |
  |   |           |      |            |   |
  |   |  /FIRST   |      |   /SECOND  |   |
  |   +———–+      +————+   |
  +—————————————+

Okay, so we know it’s easy to measure web, ftp and mail traffic, right? You can just parse the logs, sum it all up, and move on with your day. However, what do you do about users with SFTP or RSYNC privileges? This can create a problem when the bandwidth on your server keeps cranking up, but your web/ftp/mail traffic stats don’t show an increase.

Need a solution? Enjoy:

First, create an OUTPUT rule for your user, which in this case will be root. Why no INPUT rule? Many hosts don’t charge for incoming bandwidth, so why bother?
# iptables -A INPUT -j ACCEPT -m owner --uid-owner=root

Now check this out:
# /sbin/iptables -v -xL -Z
Chain OUTPUT (policy ACCEPT 1287 packets, 221983 bytes)
pkts bytes target prot opt in out source destination
437 59684 ACCEPT all -- any any anywhere anywhere OWNER UID match root

The number in the ‘bytes’ column is the count of bytes that this user sent out of your server since the last time you ran that iptables command. If you don’t want to zero out the bytes each time you run the command, just drop the Z flag from the iptables command.

You can go wild with awk if you desire:
# /sbin/iptables -v -xL | grep root | awk '{ print $2 }'
59684