Introduction

Tar and Gzip are command line utilities usually associated with Unix systems, so why would you want to backup the data on your Windows machine with these tools.

Well there are several reasons why you might want to choose a command line utility as part of your backup strategy, the first being that you don’t need to install a Windows program onto a new machine to restore your files. You can simply insert your CD-ROM containing your latest backup (and a copy of the command line utilities) and restore the files you need in a matter of seconds.
(more…)

Tags: cd, cd-rom, Command Line, download, IDE, Plesk, RAM, server, Sites, Unix, Windows

qmail is an alternative to sendmail. Plesk servers use qmail, and it may be installed on other Linux servers as well. Here are some tips and other general information on how to use and maintain qmail.* The author of qmail, D. J. Bernstein, has a web page at http://cr.yp.to . Links are provided here to software Bernstein has written, including qmail, djbdns (an alternative to BIND), daemontools (programs for supervising persistent processes such as network daemons), and ucspi-tcp (an alternative to inetd and xinetd).* The most-accepted method of installing and running qmail is defined by “Life with qmail�, or LWQ. Visit http://www.lifewithqmail.org for more details. Plesk generally has its own way of installing qmail, but LWQ will still be an excellent reference even for troubleshooting qmail on Plesk servers.

* Other qmail tips and tools are available at http://www.qmail.org/top.html . Also provided here are links to searchable archives of the qmail mailing list.

* To see how many messages are currently in the queue, use /var/qmail/bin/qmail-qstat (/usr/local/psa/qmail/bin/qmail-qstat on Plesk 2.5 servers).

* For more detailed information about the messages currently in the queue, use /var/qmail/bin/qmail-qread (/usr/local/psa/qmail/bin/qmail-qread on Plesk 2.5 servers). This command is similar to the sendmail mailq command.

* qmail’s configuration files are kept in /var/qmail/control (or /usr/local/psa/qmail/control). Together these files are equivalent to the sendmail.cf file (but much easier to read IMNSHO). LWQ provides an explanation of what each of these files is for, and so does “man qmail-control�. You may need to add the qmail man directory to the MANPATH environment variable for this man page to be found; if so, the directory is usually /var/qmail/man.

* The qmail queue directory is typically /var/qmail/queue (or /usr/local/psa/qmail/queue). Do NOT manipulate the files in this directory UNLESS you know exactly what you are doing, and UNLESS qmail is not running! Otherwise, you WILL break the queue! There are several programs listed at qmail.org designed to allow safe manipulation of the queue. In particular, Charles Cazabon, the author of memtester, has also written a qmail queue repair program, available at http://www.qcc.ca/~charlesc/software/queue_repair/ .

* Cazabon’s queue_repair program is particularly handy for wiping out qmail queues of servers being abused by spammers (usually courtesy of Plesk’s “open relay� option). The general steps are: stop qmail, move or delete the queue directory, run queue_repair with the appropriate options, then restart qmail. On Plesk 5 and 6 servers, the queue directory is /var/qmail/queue and qmail_repair should be run like so: “qmail_repair.py -c -s 23 -b�. For other servers, the queue directory will most likely be /var/qmail/queue (/usr/local/psa/qmail/queue for Plesk 2.5 servers), and qmail_repair will be run as either “qmail_repair.py -c -s XX -b /path/to/queue� or “qmail_repair.py -c -s XX -n /path/to/queue�. XX is the number of subdirectories within the queue’s info and mess directories; the “-b� option is used if there are subdirectories within the queue’s todo directory, and the “-n� option is used otherwise; “/path/to/queue� is optional if the queue directory is /var/qmail/queue.

 

Tags: age, Mail, Plesk, process

Reset Plesk admin Password via SSH (Linux Server).#cat /etc/psa/.psa.shadow
(This holds psa admin password)
#/etc/rc.d/init.d/psa stop
(This stops Plesk and everything it runs.)
#/usr/local/psa/mysql/bin/safe_mysqld –skip-grant-tables &
or
#/usr/bin/safe_mysqld –skip-grant-tables &
(This starts up MySQL, bypassing the grant [password] tables.)
#/usr/local/psa/mysql/bin/mysql mysql
(You’re now in a mysql command line.)
#use mysql;
#FLUSH PRIVILEGES;
(This flushes everything out - too long to explain.)
#SET PASSWORD FOR admin=PASSWORD(’your-password-here’);
(Type that exactly as above, where ‘your-password-here’ is, put the password you entered in the Rackshack order

form when ordering your server.)
#exit
(You exit the mysql command line and return to root.)
#killall mysqld
or
#/etc/rc.d/init.d/mysqld restart
(Shuts down the mysql daemon.)
#/etc/rc.d/init.d/psa start
(Starts Plesk back up, which restarts the mysql daemon which has your new password in it.)

Tags: Linux, MySql, Plesk, server

To update webstats on Plesk use this command./usr/bin/webalizer -n domain name -o /home/httpd/vhosts/domain name/webstat/ /home/httpd/vhosts/domain name/logs/access_logalso note that in webalizer.conf which is in /etc/webalizer.conf this entry should be commented dns_cache.dbThe above command will update stats for only one domain but if you want to update stats for the whole server then use
/usr/local/psa/admin/sbin/statistics.

———————————————-

To update webstats for specific domain use following command.
Replace DOMAINNAME.COM with clients domain name.

/usr/local/plesk/webstats DOMAINNAME.COM

To update stats for all the domains on that server use
/usr/local/plesk/webstats

If you face any problem or get an error like below:
Error: Unable to restore run data (99)

Then take the following steps to resolve this problem:

1. cd /usr/local/plesk/apache/htdocs/stats/domain.com
2. remove files webalizer.current and webalizer.hist
3. /usr/local/plesk/webstats DOMAINNAME.COM

But keep in mind that doing this is going to lose ALL previous stats too… but that is because the stats program became corrupted on this domain… but this will fix it

than update stats as i shown you before and you should not get any error

even this does not works, I mean to say, if the webstat stops itself, then check the following

Check the root user’s crontab (crontab -l when logged in as root) and see if statistics is enabled, or even present. The line SHOULD be:

07 4 * * * /usr/local/psa/admin/sbin/statistics > /dev/null 2>&1

That may not be the only way this was disabled, but it’s a likely way.

Check that one or more of your log files is larger than 2 Gig, in which case the statistics program will not run (which is probably why it was disabled in the first place).

Also, check your webalizer.conf setting to make sure that it is not set to ‘quiet’ mode, this will allow you to see any error messages that webalizer may have
BTW, the ’statistics’ program does a lot more than just trigger webalizer. Amongst other things, it also takes care of the web log file rotations and PSA usage calculations. It would suggest to anyone wanting to disable webstats that they do NOT disable the ’statistics’ program, but rather that they simply rename the webalizer program (and perhaps drop an empty ‘true’ script in it’s place to avoid any errors).

Other than the 2 Gig file limit that causes the ’statistics’ program to crash, I don’t know what it could be.

BTW, the reason ’statistics’ crashes is because it attemts to append the ‘access_log’ to the ‘access_log.processed’ file. So, if your situation is such that the sum of these two files for any one domain exceeds 2 Gig (which could be the case given the numbers you indicated), then it could still be the root of the problem.

If that is the case, then manually rotate the ‘access_log.processed’ file(s) so that statistics will create a new one from the ‘access_log’ file. Since the hit data in the ‘procesed’ log file(s) has already been processed by the ’statistics’ program, you could in theory simply delete them. However, I like to keep these files just in case I need to go back and look for any problems. If you do not currently have log rotation turned on, you can use the following command to manually rotate the processed file(s):

mv access_log.processed access_log.processed.1
gzip -9 access_log.processed.1

If you have log rotation turned on, you will need to rename your existing logs first (increment each file by one).

I also want to mention that the 2 Gig file problem is with the ’statistics’ program and not webalizer. The statistics program sends the hit data to webalizer via the ‘/dev/stdin’ so webalizer never actually accesses any log file directly. So, basically, I don’t think webalizer has anything to do with the actual problem, but is merely a symptom.

If you still want to disable webalizer (just to prove that it has nothing to do with your current problem), you could do the following:

Change to the directory with webalizer:

cd /usr/bin

Rename the original webalizer program:

mv webalizer webalizer.bak

Then create a dummy file in it’s place:

touch webalizer

And finally change the priviledges so that it is an ‘executable’ file:

chmod 755 webalizer

Now, just to confirm, you should be able to run the new webalizer program, and it will put you instantly back at the prompt.

/usr/bin/webalizer

This is what will happen when statistics calls it. Now run trigger the statistics program and see what you get:

/usr/local/psa/admin/sbin/statistics

So, this concludes the chapter on how to disable webalizer on a server without disabling the ’statistics’ program.

Additionally, you may want to try running webalizer on a site manually to see what it comes up with. Although the ’statistics’ program calls webalizer 6 times for each domain (once to populate the DNS cache and once to create the actual statistics for each of the services - http, https and ftp), the example below is all you need to do to run it for the http log. You could also run it for the https and ftp logs if you have these options enabled for the site. Since you will be triggering webalizer based on a log file (as opposed to passing the data via /dev/stdin like ’statistics does), you do NOT have to do a separate call to populate the DNS cache.

/usr/bin/webalizer -n [d] -D /usr/local/psa/var/webalizer.cache -p -N 15 -o [r] -F clf [log]

Notes:
- the command above is a single line
- replace [d] with your domain name (ex: mydomain.com)
- replace [r] with the webstat dir for that domain (ex: /home/httpd/vhosts/mydomain/webstat)
- replace [log] with the log file you want to process (ex: /home/httpd/vhosts/mydomain/logs/access_log.processed)

One important thing to keep in mind is that webalizer uses the ‘current’ and ‘hist’ files to do incremental processing. In order for this to work, it will skip any hit data prior to the last data it has already processed (to avoid double-processing). This means that you MUST process your hit data in chronological order or you will have missing chunks of data. Also, this means that you can re-process already processed log files without worring about screwing up your stats. So, I would start with the ‘access_log.processed’ file first, and then the ‘access_log’ file just to be safe. Then you should have current statistics for that domain.

ERROR: I rotated all but logs but now when running statistics manually I get several errors :

Webalizer V2.01-10 (Linux 2.4.20-18.7) English
Using logfile STDIN (clf)
DNS Lookup (15): Error: Unable to open DNS cache file /usr/local/psa/var/webalizer.cache

DNS Lookup (15): Error: Unable to open DNS cache file /usr/local/psa/var/webalizer.cache
Webalizer V2.01-10 (Linux 2.4.20-18.7) English
Using logfile STDIN (clf)

********************************************
Try this:

stat /usr/local/psa/var/webalizer.cache

And post the results. Hopefully there will be something in there that will stand out.

———————————————

The stats are freezing due to oversize file of access_log for domains.
/home/httpd/vhosts/domain.com/logs/access_log.processed

Please either trim them or empty those access logs so that webstats can update for all the domains smoothly. If it seems that these sites are most visited sites on server, then enable the log rotation for those domains. Please check the log rotation settings and make changes as per required(size wise or time wise).

To manually update the logs on the server please use the following command.
/usr/local/psa/admin/sbin/statistics

Tags: Free, Plesk, process