LinuxBabu ………..

The private key contains a series of numbers. Two of those numbers form the “public key”, the others are part of your “private key”. The “public key” bits are also embedded in your Certificate (we get them from your CSR). To check that the public key in your cert matches the public portion of your private key, you need to view the cert and the key and compare the numbers. To view the Certificate and the key run the commands:

$ openssl x509 -noout -text -in server.crt
$ openssl rsa -noout -text -in server.key

The `modulus’ and the `public exponent’ portions in the key and the Certificate must match. But since the public exponent is usually 65537 and it’s bothering comparing long modulus you can use the following approach:

$ openssl x509 -noout -modulus -in server.crt | openssl md5
$ openssl rsa -noout -modulus -in server.key | openssl md5

And then compare these really shorter numbers. With overwhelming probability they will differ if the keys are different. As a “one-liner”:

$ openssl x509 -noout -modulus -in server.pem | openssl md5 ;\
openssl rsa -noout -modulus -in server.key | openssl md5

And with auto-magic comparison (If more than one hash is displayed, they don’t match):

$ (openssl x509 -noout -modulus -in server.pem | openssl md5 ;\
openssl rsa -noout -modulus -in server.key | openssl md5) | uniq

BTW, if I want to check to which key or certificate a particular CSR belongs you can compute

$ openssl req -noout -modulus -in server.csr | openssl md5

An issue with php/apache is causing apache not to start in FreeBSD. It segfaults and core dumps, logged in the /var/log/httpd/error_log.

Try removing –with-openssl from your configure.php file and recompile php.

cd /usr/local/directadmin/customapache
vi configure.php
#remove –with-openssl from the file, save, exit.
./build clean
./build php n

Possibly a mod_perl issue. Edit the /etc/httpd/conf/httpd.conf
change:

AddModule mod_perl.c

to

#AddModule mod_perl.c

and then restart apache. If you don’t have “AddModule mod_perl.c”, then don’t worry about this entry.
Remove the “LoadModule perl_module /usr/lib/apache/mod_perl.so” if you have it as well.
This won’t affect files in the cgi-bin (I’ve seen very few people actually making use of mod_perl itself).

more info:

Previous workaround for the problem is to remove thp php flags from the httpd.conf files:

cd /usr/local/directadmin/data/templates
cp virtual_host*.conf custom
cd custom
perl -pi -e ‘s/php_admin/#php_admin/’ *
echo “action=rewrite&value=httpd” >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin/dataskq d
/usr/local/etc/rc.d/httpd restart

One user reported that installing zend solved this problem as well, so try:

cd /usr/local/directadmin/customapache
./build zend

Possibly have to downgrade zend to 2.5.7 from 2.6.2 as well as the zend binaries may not be backwards compatible.

To downgrade to apache 1.3.33 and php 4.3.11, run:

cd /usr/local/directadmin/customapache
./build clean
perl -pi -e ‘s/1.3.34/1.3.33/’ build
perl -pi -e ‘s/1.3.34/1.3.33/’ configure.apache_ssl
perl -pi -e ‘s/2.8.25/2.8.24/’ build
perl -pi -e ‘s/4.4.1/4.3.11/’ build
./build update_data
./build all d

For apache 1.3, edit your /etc/httpd/conf/httpd.conf and add

ExtendedStatus On
<Location /httpd-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>

 

 

 

just after the code that says “ServerSignature On”. Save, exit, then restart apache. You can access the stats page by going to http://1.2.3.4/httpd-status where 1.2.3.4 is your server’s IP.

If you’re running apache 2.x , then it’s already in the file:
/etc/httpd/conf/extra/httpd.conf
Change the “Allow from” lines to include your IP.

Under cPanel servers the code is already present but you need to uncomment it or just add the code :

<Location /whm-server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>

This happens with the configure script for apache cannot find the “openssl” (or “ssleay”) binaries in any of
/usr/bin/openssl
/usr/sbin/openssl
/usr/apps/openssl

The usual location for “openssl” is /usr/bin/openssl

On a debian system, run

apt-get install openssl

A few things that could cause that are:

Possible Causes:
1) MaxClients set to a value too low
2) If you have over about 800 sites, the ErrorLog files open too many file descriptors and apache won’t be able to log the errors and may stop responding.

Solutions:
1) edit /etc/httpd/conf/httpd.conf and increase the MaxClients setting to something like 200 or 300.
2)

cd /usr/local/directadmin/data/templates
cp virtual_host*.conf custom
cd custom

# remove all the ErrorLog lines (or comment them out) from the 4 virtual_host*.conf files that are in the custom directory.

echo “action=rewrite&value=httpd” >> /usr/local/directadmin/data/task.queue

Apache should be restarted automatically after a few minutes later (rewrite might take a while with over 800 sites).

3) Other possible information:
Edit /usr/include/bits/typesizes.h and set
#define __FD_SETSIZE 32768 
and then recompile with customapache or custombuild.

On FreeBSD, it’s /usr/include/sys/select.h or /usr/include/sys/types.h
Change:
#define FD_SETSIZE 1024U
to
#define FD_SETSIZE 32768U

then recompile apache/php

4) edit /etc/sysctl.conf and add:
fs.file-max = 32768

and run:

/sbin/sysctl -w fs.file-max=32768

then recompile apache/php

Other possible entires for the sysctl.conf:
kern.maxfiles = 32768
kern.maxfilesperproc = 32768

5) Another way to free up FileDescriptors (FDs) is to disable ssl on any domain that does not require it.
A quck way to check is to type:

ls -la /home/*/domains/*/private_html/index.html

quickly scan the list for any index.html that isn’t betwen 200-300 bytes in size. Any that are not in that range will have been edited and the user is probably using ssl, so take note of those usernames and domains. Now, the quick way to do a mass SSL shutoff for domains is to type:

perl -pi -e ‘s/ssl=ON/ssl=OFF/’ /usr/local/directadmin/data/users/*/domains/*.conf

Then turn ssl=ON back on for any users who need it. Note that this is an end user level setting, so they have the ability to turn it back on themselves via Domain Setup. Then type the action=rewrite&value=httpd command as mentioned in step 2 above.
What this does is reduced the number of FD’s by 50%. Since many people rarely use SSL, disabling it reduceds half of all virtualhosts, since all domains, subdomains, etc.. have 2 virtualhosts each with ssl, and only 1 each without ssl.

6) Openssl bug. Either update openssl and recompile apache, or patch apache 2:
http://issues.apache.org/bugzilla/show_bug.cgi?id=43717

---

Related error messages:
[error] System: Too many open files in system (errno: 23)

host: isc_socket_create: not enough free resources socket.c:2117: REQUIRE(maxfd <= (int)1024) failed.
host: isc_socket_create: not enough free resources

 

DirectAdmin FAQ

Updating Apache to the latest version

You can check the current version of apache by running

httpd -v

If you wish to update your 1.3 version of apache to the most recent, run the following:

cd /usr/local/directadmin/customapache
./build clean
./build update
./build apache_mod_ssl

If you’re using apache 2.x, use “./build apache_2″ isntead of apache_mod_ssl.
This should update both the configure options and the version of apache to the most recent version. Once the update has completed, you’ll need to restart apache:

RedHat:

/sbin/service httpd restart

FreeBSD:

/usr/local/etc/rc.d/httpd restart

How to downgrade from apache 2 back to apache 1.3

If you need to go back to apache 1.3 after installing apache 2, you’ll need to do the following: 1) Restore the old httpd.conf file: cp -f /etc/httpd/conf/httpd.conf.1.3.backup /etc/httpd/conf/httpd.conf 2) Get DirectAdmin to use the old httpd.conf files for the users. Edit the /usr/local/directadmin/conf/directadmin.conf file and change apache_ver=2.0 to apache_ver=1.3. Also, if you were using custombuild, and are going back to customapache, the apache_conf value needs to be reset to: apacheconf=/etc/httpd/conf/httpd.conf Then type echo “action=rewrite&value=ips” >> /usr/local/directadmin/data/task.queue echo “action=rewrite&value=httpd” >> /usr/local/directadmin/data/task.queue echo “action=directadmin&value=restart” >> /usr/local/directadmin/data/task.queue 3) Now you can recompile apache 1.3 rm -f /usr/lib/apache/* cd /usr/local/directadmin/customapache ./build clean ./build all 4) Fix the modules link: cd /etc/httpd rm -f modules ln -s /usr/lib/apache modules 5) Restore the old boot script: FreeBSD: cp -f /usr/local/directadmin/customapache/httpd_freebsd /usr/local/etc/rc.d/httpd chmod 755 /usr/local/etc/rc.d/httpd /usr/local/etc/rc.d/httpd restart RedHat: cp -f /usr/local/directadmin/customapache/httpd /etc/init.d/httpd chmod 755 /etc/init.d/httpd /etc/init.d/httpd restart

This means that the cgi script did not execute properly. There are several causes that can generate this error so a few things would need to be checked.

1) check the /var/log/httpd/suexec_log. It contains any errors that would be as a result of not having correct permissions on the file. The file needs to be in a cgi-bin and must have the owner/group as the username who owns the site. If it’s owned by anyone else, it will not run. Also, the script must have execute permission. The most common chmod permission is 755. Go through all directories from the public_html down to the directory the script is in, and make sure they’re all set to 755 (public_html can be 750 *only* if it has a group of apache).

If the suexec_log only shows the script being run, then the cause may be with the script code itself. The easiest way to figure out script coding problems is to first run the script manually from an ssh prompt.

cd /home/username/domains/domain.com/public_html/cgi-bin
./script.cgi

One common error is to use an incorrect interpreter. The 2 most common interpreters are:

#!/usr/bin/perl

and

#!/usr/local/bin/php

This code must appear on the first line of the script. Somtimes a file is uploaded in windows format so the trailing newline (return) character is formed incorrectly and the file would need to be reuploaded in a different format.

Other errors that would be generated when running the script manually from ssh would be missing perl modules, in which case you’ll need to install them yourself. Cpan is the easiest method to install new perl modules, eg:

perl -e shell -MCPAN
install Bundle::DBD::mysql

Sometimes we may require to remove APF from the server. Here is a guide which shows how to remove APF completely from the server.

Stop the firewall first
service apf stop
/bin/rm -rfv /etc/apf
Remove the cron for APF
/bin/rm -fv /etc/cron.daily/fw
/bin/rm -fv /etc/init.d/apf
lastly disable at startup
chkconfig apf off

This should remove APF completely from the server as we removed the APF daemon, cron and files.

Q. How do I verify that my ISP or my own recursive resolvers are free from DNS cache poisoning bug that is promised full disclosure of the flaw by Dan on August 7 at the Black Hat conference? How do I test my dns server for DNS cache pollution or DNS Cache Poisoning bug?

A. DNS cache poisoning (also known as DNS cache pollution) is a maliciously created or unintended situation that provides data to a Domain Name Server that did not originate from authoritative DNS sources. It occur if DNS “spoofing attack” has been encountered. An attacker will send malicious data / non-secure data in response to a DNS query. For example dns query for www.linuxbabu.net can be redirected to www.redhat.com.

how do I find out if my DNS server is open to such attack or not?

Visit Dan Kaminsky java script page to check your DNS

You can also use following command dig command, enter:
$ dig +short @{name-server-ip} porttest.dns-oarc.net txt
$ dig +short @ns1.example.com porttest.dns-oarc.net txt
$ dig +short @208.67.222.222 porttest.dns-oarc.net txtSample output:

z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"208.67.222.222 is GOOD: 26 queries in 0.1 seconds from 26 ports with std dev 17746.18"

Another test,
$ dig +short @125.22.47.125 porttest.dns-oarc.net txtOutput:

z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"125.22.47.139 is POOR: 42 queries in 8.4 seconds from 1 ports with std dev 0.00"

FIX :

Run yum update
yum updateOpen named.conf file and comment out following two lines:
query-source port 53;
query-source-v6 port 53;Make sure recursion is limited to your LAN only. Set ACL. Restart bind to take effect:
rndc reload 


service named restart