Tag: perl
Apache won’t start after update on FreeBSD
by admin on Sep.07, 2009, under DirectAdmin
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
Apache won’t start and there is nothing in the logs
by admin on Sep.07, 2009, under DirectAdmin
Chance are, if apache isn’t starting and isn’t logging anything, the error_log is full preventing apache from starting. To double check that, run:
cd /var/log/httpd
ls -lS | less
If any file is around 2-3 gig (or more), then chances are, that’s the problem.
The solution is to remove the logs, restart apache, and then implement preventative measures.
1)
cd /var/log/httpd/
rm -f error_log
rm -f access_log
rm -f suexec_log
rm -f fpexec_log
/sbin/service httpd restart ("/usr/local/etc/rc.d httpd restart" for FreeBSD)
2) Get logrota to rotate daily
perl -pi -e ‘s/weekly/daily/’ /etc/logrotate.conf
perl -pi -e ‘s/rotate 4/rotate 2/’ /etc/logrotate.conf
If apache still doesn’t start, check /var/log/messages and try recompiling apache.
Apache stops responding but is running
by admin on Sep.07, 2009, under DirectAdmin
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 VirtualHost entries (domains, subdomain, ssl, etc.. ), the ErrorLog files open too many file descriptors and apache won’t be able to log the errors and may stop responding. This number can vary per box depending on the limit, and setup of the system. (lower/higher)
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.
perl -pi -e ‘s/Error/#Error/’ virtual_host*.conf
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).
If that’s not enough to lower the limit and the problem persists, also try commenting out the CustomLog entries:
perl -pi -e ‘s/CustomLog/#CustomLog/’ virtual_host*.conf
and repeat the above echo command to rewrite the httpd.conf files.
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
/sbin/sysctl -w kern.maxfiles=32768
/sbin/sysctl -w kern.maxfilesperproc=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
cgi files generate Internal Server Error
by admin on Sep.07, 2009, under DirectAdmin
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. Sometimes a file is uploaded in windows format so the trailing newline (return) character is formed incorrectly and the file would need to be re uploaded 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, e.g.:
perl -e shell -MCPAN
install Bundle::DBD::mysql
LXAdmin Administrator Tutorial
by admin on Feb.16, 2009, under Tutorial
LXadmin “Host in a box” is the only control panel that makes use of Lighttpd and DJBDNS which only uses 8 MB of RAM with a freshly installed system. The control panel itself uses 1 MB of RAM when idle. LXadmin “Host in a box” is part of LXadmin, the leading light-weight control panel in the industry. The only difference between the two is the use of different daemons.
This lightweight control panel has all of the features included in all leading control panels such as mail, spam filter, PHP, CGI, Perl, SUexec, FTP, MySQL and much much more. You will get to find out more in this document as you read.
2a. Accessing the control panel
|
There are several ways to access LXadmin: http://yourdomain:7778 – You can access the control panel through any hosted domain by putting :7778 at the end of the domain. https://yourdomain:7777 - You can access the control panel securly using SSL through any hosted domain by putting :7777 at the end of the domain. http://192.168.0.1:7778 or https://192.168.0.1:7777 - You can access the control panel through any IP address allocated to the server. This is useful when your domain transfer has not yet propagated. A window (top right image) will appear. Enter your username and password and you should have successfully logged in. |
|

To change your password, click client home and then on the top right corner, you will see the password tab. Click on it and fill in your existing password and the new password twice and click Update.
You have to add a DNS template initially. DNS template is the DNS configuration which will be copied to your domain’s DNS when a new domain is created. For adding a DNS template, you have to basically specify the primary and secondary nameservers for the domains you are planning to create on this server. For instance: ns1.lxlabs.com and ns2.lxlabs.com . The name is simply an identifier which will be used later when creating the domain.
For creating a new DNS template,
go to “Client Home” page and under “Domains“, click the “DNS Templates” icon

In the DNS Templates page, you can see the list of existing DNS templates. If you do not have any existing DNS template, create a new DNS template by clicking the “Add DNS Template” tab on the top.

In the next page, enter the DNS information for the template:

Click the “Add” button and the new DNS template is created. You can see the new DNS template in the list of DNS Templates

Click on the new DNS Template name to edit DNS records like NS, A, CNAME, MX and TXT

Before you proceed to add a new Reseller, you have to add a new plan for the new client/reseller
To add a new plan,
To add a new plan, click “Client Plans” icon

In the next page, click the “Add Client Plan” tab.

Here you can enter the plan details like:
Client Plan name)
Description of the plan
Number Of Clients allowed
Number Of Domains allowed
Disk Usage (in MB)
Number Of Subdomains allowed
Mail Disk Usage (in MB) limit
Number Of Autoresponders allowed
Number of Mail Accounts allowed
Number Of Mailing Lists allowed
Traffic (in MB per Month) limit
Maximum number of MySQL Databases
Maximum Number Of Domain Users
Ability to add more domains
Ability to set Disabled URL
Ability to Enable Ssl
Ability to Enable Statistics
Ability to Enable Cgi
Ability to Enable Php
Ability to Enable Asp.net (ignored On Linux)
Allow Scheduler Management or not
Allow Backup Scheduling or not
Allow Backing Up or not
Can Manage DNS or not
Once you have created the plan, go back to the “Client Home” page and click the “Clients” button link

This page will list your existing customers and resellers. If you do not have any, click on either the “Add Reseller” tab that you see on the top.

In the “Add Reseller” page, enter a name for your Reseller, password and email address.
If you enable the “Send Welcome Message” check box, an email with the account details will be sent automatically to the Reseller’s email address.
Select the plan you have created earlier and click “Add” button.
Now in the “Clients” page, you should be able to see the new Reseller that you have created:

