The FrontPage hit counter for a site was not working. I kept on getting the following error in the log file of a domain that has FrontPage enabled:
Incorrect permissions on webroot “/var/www/vhosts/example.com/httpdocs/_vti_pvt” and webroot’s _vti_pvt directory in FrontPageAlias().
Changing to the website’s httpdocs directory and running the command below, fixed the problem.
chgrp psaserv _vti_pvt
Thank you goes to zymsys
It may become necessary to redirect some outgoing traffic to a different IP address from time to time ….
Recently the route to a mail server became unreachable from our mail server and we had to route traffic via an alternative relay server.
I achieved this using the trusty old iptables.
Here is the rule:
iptables -t nat -A OUTPUT -d <OriginalDestinationIPAaddress> -p tcp –dport <OriginalDestinationPort> -j DNAT –to-destination <NewDestinationIPAddress>:<NewDestinationPort>
It seems straight forward if you read the PHP manual …. just do a pecl install sqlite …. but most things in live is not that simple. 
The above command gave me the following error:
../SQLite-1.0.3/sqlite.c:56: error:
‘BYREF_NONE’ undeclared here (not in a function)
../SQLite-1.0.3/sqlite.c:56: error:
‘BYREF_FORCE’ undeclared here (not in a function)
../SQLite-1.0.3/sqlite.c:125: warning:
initialization from incompatible pointer type
../SQLite-1.0.3/sqlite.c:126: warning:
initialization from incompatible pointer type
make: *** [sqlite.lo] Error 1
ERROR: `make’ failed
Thanks to a post I found on phpbuilder.com, I can post the solution below:
PHP 5 is compiled with “–without sqlite”.
Start with installing php-pecl-sqlite
$ pear download sqlite
OR
$ wget -q http://pecl.php.net/get/SQLite-1.0.3.tgzthen unpacked and began to compile it
$ tar zxvf SQLite-1.0.3.tgz
$ cd SQLite-1.0.3
$ phpize
$ ./configure
$ makemake failed here with some offset error
edit sqlite.c, comment out the following line:
/* static unsigned char arg3_force_ref[] = {3, BYREF_NONE, BYREF_NONE, BYREF_FORCE }; */And then change these lines
function_entry sqlite_functions[] = {
PHP_FE(sqlite_open, arg3_force_ref)
PHP_FE(sqlite_popen, arg3_force_ref)
to:
function_entry sqlite_functions[] = {
PHP_FE(sqlite_open, third_arg_force_ref)
PHP_FE(sqlite_popen, third_arg_force_ref)$ make
$ make install
$ service httpd restart
I installed a copy of Ubuntu 8.04 tonight. It is a lovely piece of software to say the least. Almost everything worked out-of-the-box. Unfortunately it did not want to print to my HP LJ 1020. Luckily a search on Google quickly revealed a solution:
On Hardy Heron isn’t more necessary to install the drivers from http://foo2zjs.rkkda.com/ since that the it installs the correct drivers and hp programs. It’s only necessary to download the printer’s firmware since that Ubuntu can’t delivery it cause of license and/or patent restriction. At terminal and as root (or using sudo), just type:
# hp-setup (as root)
OR
$ sudo hp-setup (as sudoer)
and follow-up the wizard. It’s straightforward.
A big thank you goes to Danpros for the info in this post.
I was reading an article on some site and read the following phrase. I thought it is so appropriate that I had to include it in my blog.
Law of Logical Argument:
Anything is possible if you don’t know what you are talking about.
Oops, the latest version of PHP breaks a few things on Plesk 8.1.x and Plesk 8.2.x installations. It propably affects other installations as well, but I stopped testing since I was only interested in Plesk 8.2.x and later.
According to atomicrocketturtle the problem will be fixed in Plesk 8.3. We will just have to wait and see.
On rackerhacker’s blog I found a very elegant solution to the problem that was provided by Kevin M.
I repeat the entry from rackerhacker’s blog:
There’s a few issues with PHP 5.2.5 and the version of Horde that is bundled with Plesk 8.1.x and 8.2.x. The PHP include paths that appear in the Apache configuration generated by Plesk conflict with the PHP installation, and that causes the Horde webmail interface to segmentation fault.
To fix the problem, create a file called /etc/httpd/conf.d/zz050a_horde_php_workaround.conf and put the following inside it:
<DirectoryMatch /usr/share/psa-horde>
php_admin_value include_path "/usr/share/psa-horde/lib:/usr/share/psa-horde:/usr/share/psa-horde/pear:."
</DirectoryMatch>
Reload the Apache configuration and your Horde installation should work properly with PHP 5.2.5.
Finally, SWSoft has come to the party and added piped logging into the Plesk configuration. This is simply fantastic since it has enabled me to run many more websites on a shared hosting server. Yay!!
To enable piped Apache logs, do the following:
# mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "replace into misc (param,val) values ('apache_pipelog', 'true');"
# /usr/local/psa/admin/sbin/websrvmng -v -a
A big “thank you” goes to Racker Hacker for this piece of information.
You are welcome to access this blog via your WAP browser on your cellphone.
The WAP URL is: http://www.swart.org.za/wordpress/wap.php (This link will not work in a normal non-WAP enabled browser.)
10 December 2007: I have not been able to get this solution to work at all, even though mod_frontpage is compiled against Apache 2.2.
20 December 2007: I have found enough time to spend hours on debugging the problem and I have successfully been able to get mod_frontpage working on my CentOS 5 server running Plesk 8.2.1 and Apache 2.2. I have updated the article below where needed.
As most of you are aware, Microsoft FrontPage (FP) has long ago reached its end-of-life. Microsoft no longer distributes FrontPage or FrontPage Server Extensions (FPSE). Now, this may be all well enough and most us understand why. The problem unfortunately lies with the user base. Many people still use and rely on the old outdated versions of Microsoft FrontPage.
SWSoft stopped shipping FPSE as of Plesk version 8.1.0. The last version of FPSE that I could locate was in version 8.0.1 of Plesk.
Version 8.0.1 was also never released for CentOS5 or Red Hat Enterprise Linux 5 (RHEL5), which means that there are effectively no RPMs for FPSE, that was compiled against Apache 2.2.x.
This effectively meant that you had to search for an OLD copy of fp50.lin.tar.gz and compile it yourself. Not the most ideal solution.
Enter, crash. crash provided the solution to the problem on SWSoft’s forum. I will be repeating most of crash’s post below.
You will need one of the older SWSoft FPSE RPM’s. I used frontpage-5.0-72psa.centos4.2 and frontpage-5.0-72psa.rhel4. The RPMs are located in the Plesk 8.0.1 .tar.gz file, in the ./opt/fp directory.
You will need to install one of the above RPM’s onto your system.
Once installed, do the following:
cd ~
mkdir frontpage-5.0
cd frontpage-5.0
cp -afr /usr/local/frontage .
cd ..
tar -cvf frontpage-5.0.tgz ./frontpage-5.0/
You should now have a frontpage-5.0.tgz file, that will be used.
crash provided the following patches to have mod_frontpage compile against Apache 2.2.x. (The patches should allow you to compile mod_frontpage against Apache 2.0.x or Apache 2.2.x [There are a few tiny differences])
Download the patches: FrontPage Server Extension Patches for CentOS5 and Apache 2.2.x (The file was updated on 20 December 2007)
You need to have the httpd-devel RPM installed. yum install httpd-devel, will usually be sufficient.
Now do the following:
cd /usr/src/redhat
tar zxvf mod_frontpage-patches.tgz
cd SPECS
rpmbuild -bb frontpage.spec
If all goes well, the RPM build process should complete without any errors and you will have a brand new RPM to install FPSE with on CentOS5/RHEL5.
Credit to crash’s post. I discovered a few bugs in the patches originally provided by crash.
A few tips:
With every major enterprise Linux release, Red Hat adds a number of new daemons to the startup of the server. Most of these daemons has a very clear function. I have however pondered what all the daemons are for. Although nice to have many of the daemons simply eats away at your resources and if not needed should really be disabled.
Red Hat was kind enough to release the following information in the Red Hat Magazine article, with the heading: “Understanding your (Red Hat Enterprise Linux) daemons“.
Of course the above information is very handy for CentOS, which is based on Red Hat Enterprise Linux.
Dr.Web and CentOS5 does not like each other by default.
The version of Dr.Web used in Plesk 8.2.x, is linked against older versions of libstdc++ and openssl.
To get Dr.Web to run on CentOS5, you need to install the some compatibility libraries.
The following should get you sorted:
yum install compat-libstdc++-33.i386 openssl097a.i386
After a very long time I had to revert back to my blog and saw it needed a bit of TLC so I upgraded it to the latest available version of WordPress.
The old theme is broken in the new version so I reverted to the “WordPress Default”, for the time being.
Recently I ran into a problem where my primary IP address on the server was blacklisted. This had the negative effect that mail being sent from the server to other servers that use the blacklist, blocked our emails.
In a shared hosting environment, one user can easily get a server blacklisted.
All our servers have at least 2 publicly accessible IP addresses. I thought that it would be great if I could get the mail to appear to be from one of the secondary IP addresses.
Below is a iptables rule, that achieves just this:
iptables -t nat -A POSTROUTING -o eth0 \
-s <primaryIPAddress>/32 -p tcp --dport 25 \
-j SNAT --to-source <secondaryIPAddress>
Yes, SWsoft decided that our users should be bombarded with news feeds. This may be a feature that certain users like or desire, but as the system administrator you are not given a choice.
I believe choice is important, especially in a product that costs many dollars.
Here is some perl code to disable the newsfeeds:
For clients:
$query = "SELECT id FROM clients WHERE login='$client'";
@cID = $queryDBpsa->($query);
$query = "REPLACE INTO cl_param (param, val , cl_id) VALUES ('news_dismissed', '1', '$cID[0]');";
$queryDBpsa->($query);
For domains:
$query = "SELECT id FROM domains WHERE name='$domain'";
@dID = $queryDBpsa->($query);
$query = "REPLACE INTO dom_param (param, val , dom_id) VALUES ('news_dismissed', '1', '$dID[0]');";
$queryDBpsa->($query);
SWSoft decided that the wise thing to do is to start advertising their products in the control panel, effectively spamming the clients that pay a lot of money for the licenses.
To disable the promo, edit the language file, located here:
/usr/local/psa/admin/plib/locales/en-US/messages_en-US.php
Search for the following string:
virtuozzo__promotion or virtuozzo__promotion_top
SWSoft promised that it will remove the advertising from future versions. Let’s hope they do.
Remember, you may need to edit different files for different languages.
Edit: This also works in versions 8.1.1, 8.2.0 and 8.2.1
To redirect all http:// traffic to the corresponding https:// traffic, we make use of a bit of mod_rewrite magic.
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]
Replace www.example.com with your own SSL URL.
To force SSL for a particular folder (not the entire site), use the following instead:
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} somefolder
RewriteRule ^(.*)$ https://www.example.com/somefolder/$1 [R,L]
Replace somefolder with your folder path and www.example.com with your SSL URL.
Problem,
Fatal error: Unable to logon user (EV1SERVE-01UIT2\Plesk Administrator): (1327) Logon failure: user account restriction. Possible reasons are blank passwords not allowed, logon hour restrictions, or a policy restriction has been enforced. in C:\Program Files\SWsoft\Plesk\admin\htdocs\login_up.php3 on line 3
Solution,
In the C:\Program Files\SWsoft\Plesk\admin\bin\ folder run the papswd.exe file with the following values,
papswd –set –password=’NewPassword’
Please be aware that certain servers running stock standard kernel 2.6.9-34, 2.6.9-34.0.1 or 2.6.9-34.0.2 may experience problems with high IO wait times. You will also notice that not all the memory on the server is used.
A patch was included in the above kernels that caused the kernel to start swapping to disk long before all the memory was used. This caused serious performance issues on some servers, running the above kernel versions.
The patch was removed from the 2.6.9-42 kernel and bliss has returned to all the servers.
kernel 2.6.9-42 is also included in the RHEL 4 Update 4 and will hopefully be included in CentOS 4.4.
Since Plesk 8 for Unix, SW-Soft, changed the backup utility from the old psadump/psarestore utilities available in Plesk 7.5.4 and earlier to the new pleskbackup/pleskrestore utilities.
I have read a lot of posts from unhappy people about the new utilities. I can honestly say that my only complaint is that SW-Soft decided to break compatibility between the pre-Plesk 8.0 and the post-Plesk 8.0 backup utilities.
That being said, the first version of the backup utilities that I tried was for Plesk 8.0.1, with at least one, maybe 2 hotfixes applied.
I have found the new Plesk 8.0.1 backup utilities to be a lot faster and a lot easier to use than their predecessors.
Yes, the backup file is still a gzipped, MIME encoded file but at least the backup utilities now add the filenames to each MIME part, making it possible to extract the backup archive into multiple clearly named files. Then it is a simple untar of the correct part to get your data.
All in all, not too bad.
By default, the new backup utilities will split your backup file into 1GB chunks. You may change this behaviour, by setting the following variable before running the backup:
PLESKX_SPLIT_SIZE=2147483648
/usr/local/psa/bin/pleskbackup –all /path/to/file/FILENAMEHERE -verbose
The PLESKX_SPLIT_SIZE variable expects a number of bytes as input. In the above example we set the chunk size to 2GB.
To be able to work with the MIME files, you will need a MIME decoder. You may want to search for mpack or get ripmime.
By default all the Plesk servers runs mod_php for speed. This has one major drawback and that is that if a clients creates files via PHP, they are owned by the webserver user under which mod_php runs. The solution to the problem seems to enable suPHP for the clients that needs to create files via PHP.
Below is the procedure that I found to work:
wget http://dag.wieers.com/packages/mod_suphp/mod_suphp-0.6.1-2.1.el3.rf.i386.rpm
rpm -Uvh mod_suphp-0.6.1-2.1.el3.rf.i386.rpm
AddHandler in /etc/httpd/conf.d/suphp.conf
LoadModule suphp_module modules/mod_suphp.so
LoadModule php4_module modules/libphp4.so
suPHP_Engine off
Putting the above into your config will default to PHP pages being run by mod_php.
<Directory /home/httpd/vhosts/<VHOST>/httpdocs>
<IfModule sapi_apache2.c>
<IfModule mod_suphp.c>
RemoveHandler x-httpd-php
php_admin_flag engine Off
suPHP_AddHandler x-httpd-php .php
suPHP_Engine on
AddHandler x-httpd-php .php
suPHP_UserGroup <USER> <GROUP>
</IfModule>
</IfModule>
</Directory>
The config above will only activate if both mod_php and mod_suphp is loaded. Remember to replace the <VHOST>, <USER> and <GROUP> entries with the correct virtual host, Unix user and Unix group.
EDIT: In later versions of PHP, the CLI and CGI version are 2 separate binaries. You now need to edit the /etc/suphp.conf file to reflect the correct binary in the x-httpd-php=php:/usr/bin/php-cgi entry. To determine which binary you need to add, simple do a php -v on the command line. The binary that outputs the cgi information as part of the version information, is the correct binary.