how-to

These are some of the basic things I do when I setup a new server

Get the latest directadmin.conf values

With each version of DirectAdmin, new configuration values are introduced that you may not know about. To see ALL these values do the following:

/usr/local/directadmin/directadmin c | sort -n

You can essentially copy/paste the entire results into your /usr/local/directadmin/conf/directadmin.conf replacing anything else in there.

Setup DirectAdmin with an SSL certificate

source: http://help.directadmin.com/item.php?id=15

If you don't own a certificate, you can create your own with letsencrypt.com:

Alright... So APC has been pretty unstable for me on 2 separate servers running PHP 5.3.x and PHP 5.4.x. So I figured I'd give XCache a try after reading about similar problems with APC.

Anyhow...

Here's how to install XCache 3.X from source on CentOS

Get the latest version of XCache from here: http://xcache.lighttpd.net/#Downloads

Latest version at the time of this writing is XCache 3.0.1


cd /usr/local/src
wget http://xcache.lighttpd.net/pub/Releases/3.0.3/xcache-3.0.3.tar.gz
tar xvfz xcache-3.0.3.tar.gz
cd xcache-3.0.3
phpize
./configure --enable-xcache
make
make install


Note the installation path. Example here are my paths:

If your disk is starting to run out of space due to an excess of mysql-bin.XXXXXXXX files here's what to do to fix that.


vi /etc/my.cnf


under 'log-bin=mysql-bin' (the destination could be different in your my.cnf) put:


expire_logs_days = 10


Change 10 to whatever you're comfortable with.

or you can simply disable the binary log files by uncommenting the line:


# log-bin=mysql-bin


You'll also want to remove all the excessive binary log files like so:


mysql -u root -p -e "PURGE BINARY LOGS BEFORE '2012-02-15 09:00:00';"


TROUBLESHOOTING

In case you can't shutdown mysqld do the following:


pidof mysqld
kill -9 NUMBEROFPROCESS

create a new file called 'drop_all_tables.sh'


vi drop_all_tables.sh


Here's how we do it on RHEL:

Logged in as root:

* Create file at /etc/cron.hourly/clockset
* with these two lines only:

rdate -s time-a.nist.gov > /dev/null
hwclock --systohc > /dev/null

source: http://www.directadmin.com/forum/showthread.php?s=78bb4e8b8b5deb41fdc7275bb87a051a&threadid=13173&perpage=20&pagenumber=1

http://www.directadmin.com/forum/showthread.php?s=70864a5c335e7705f268e661e0a6d78f&threadid=14285

Source

SSL Location:

SSH to the old server and go to /usr/share/ssl/certs/, here you find the www.domain.com.crt (SSL Certificate) and the www.domain.com.cabundle (Cabundle), You will find the key www.domain.com.key at /usr/share/ssl/private/ path.

source: http://www.ahinc.com/linux101/users.htm

Source: http://www.webhostgear.com/321.html

For those of you who check your nameservers and other DNS related issues using the popular site dnsreport you're probbaly seeing Fail Open DNS Servers. We'll show you have to fixed named to close open dns servers.

source: www.eth0.us: How-To: Secure your temp directories

Every system needs temporary folders that any user is able to read and write BUT these directories should not be able to execute programs or scripts. Though this will only protect you from somebody running the script directly it will help with a large portion of the automated rootkits and trojans that script kiddies use. They will still be able to put the files on the system but they will be unable to execute them and create the back door. One of the biggest problems is php injection via apache in which people will have apache download and then run an exploit. Securing the temp directories is probably the single biggest thing you can do towards securing your server.