There's a known issue with the security settings when you use the wacsimport and (probably) wacsxmlin. Once these have created the icons, they change the permissions of the owning directory to be accessible only by the user and group. This is not the correct strategy on a web hosting provider as their apache web server is not a member of any unix group in common with the shell user account. The quick solution to this is to run the following on the web document tree (usually under ~/public_html/ after each importation has taken place:

# cd ~/public_html
# chmod -R o+rX bigicons cache modicons images wacs
#

Another issue, with one web hosting provider we worked on, we found that the wacspop command wouldn't work due their using MySQL 5.0 and an earlier version of the interface routine. This problem manifested itself in an error from the column_info - changing the empty string specifiction from '' to a wildcard '%' in the final parameter worked around this problem.

Unfortunately there can be further issues when trying to use the WACS system in that many web hosting providers do not install all of the infra-structure that it needs, including packages like the netpbm tools which provide the image scaling and thumbnailing facilities we use extensively within WACS. It is quite possible to copy both the binary programs and the necessary shared libraries from another Linux host of similar architecture onto your space on the web hosting provider. The alternative approach is to compile the netpbm suite from source code and then statically link the resulting binaries. This is what we had to do to make the PinkMetallic.com site work. The commands below show what we did - the first command being to determine the CPU/runtime architecture being used - in this case standard 64-bit AMD/Intel EMT architecture, and the second to determine the distribution being used:

# uname -p
x86_64
# uname -r
2.6.18-128.1.6.el5
# mkdir ~/lib
# export LD_LIBRARY_PATH=/home/yoursite/lib
#

	Tip
	We understand this step is non-trivial and confusing and there's very little we can do about this other than to invite you to post on the wacs-users mailing list for help and advice. Each web hosting provider probably has a different combination and there is little else we can do other than offer to help as best we can.

This tells us (from experience) that we're dealing with a RedHat Enterprise Linux distribution running on a 64-bit AMD-style architecture processor. We might also see i686 if the hosting company are using 32-bit Intel architecture servers. You can also try the following for more details if it looks like it might be either a redhat-based (CentOS,RHEL,Oracle Unbreakable,etc) or debian-based (Ubuntu,Debian,etc) Linux distribution they're using:

# cat /etc/redhat-release
CentOS release 5.5 (Final)
# cat /etc/debian_version
cat: /etc/debian_version: No such file or directory
#

For CentOS or RHEL, centos.org is the best place to find suitable packages for download - we selected two RPMs from one of their mirror sites: netpbm-10.35.58-8.el5.x86_64.rpm for the libraries and netpbm-progs-10.35.58-8.el5.x86_64.rpm for the tool binaries. These can usual be found starting at the release number, say 5.5 , then choosing os then choosing the architecture either x86_64 or i386 (an alias for i686) as appropriate. The package files themselves are then usual found in the CentOS directory. We then used the rpm2cpio command to covert these rpm archives into more standard archive formats and then the cpio command itself to unpack the result.

	Tip
	If the webhosting company is using an older version of CentOS and you can't find the appropriate binaries on the mirror site, try vault.centos.org

# wget http://www.mirrorservice.org/sites/mirror.centos.org/5.4/o
s/x86_64/CentOS/netpbm-10.35.58-8.el5.x86_64.rpm
[...]
# rpm2cpio netpbm-10.35.58-8.el5.x86_64.rpm > netpbm-10.35.cpio
# cpio -ivudB < netpbm-10.35.cpio
[...]
# wget http://www.mirrorservice.org/sites/mirror.centos.org/5.4/o
s/x86_64/CentOS/netpbm-progs-10.35.58-8.el5.x86_64.rpm
[...]
# rpm2cpio netpbm-progs-10.35.58-8.el5.x86_64.rpm > netpbm-progs-
10.35.cpio
[...]
# cpio -iuvdB < netpbm-progs-10.35.cpio
[...]
#

Having done this we have the entire netpbm tree contained in a directory called usr under the current directory. The first command the wacs program we were trying to run (actually it was generate) complained about was pnmscale so we fetch the pnmscale binary from usr/bin/pnmscale and transfer that up to the web hosting provider and place it in our ~/bin directory. Once we've done that we run the ldd command on it which says:

# cd ~/bin
# ldd pnmscale
	libm.so.6 => /lib64/libm.so.6 (0x000000365ee00000)
	libnetpbm.so.10 => not found
	libc.so.6 => /lib64/libc.so.6 (0x000000365e200000)
	/lib64/ld-linux-x86-64.so.2 (0x000000365de00000)
#

The pertinent thing here is that libnetpbm.so.10 is the only library we need for pnmscale to work that isn't there. If we check back in our unpacked package, we should have that file as usr/lib64/libnetpbm.so.10.35. Since it's libnetpbm.so.10 that it's asking for, we transfer our local usr/lib64/libnetpbm.so.10.35 up to the hosting provider server as libnetpbm.so.10 using the ftp/sftp put command as follows:

sftp> put usr/lib64/libnetpbm.so.10.35 libnetpbm.so.10
Uploading usr/lib64/libnetpbm.so.10.35 to /home/yoursite/lib/libnetpbm.so.10
usr/lib64/libnetpbm.so.10.35                  100%  187KB  93.3KB/s   00:02
sftp>

If we now re-run the ldd command on pnmscale, we should now see that all the dependencies are resolved. The final test is to run the command itself, and it this case it's default action is to complain that you didn't ask it to do anything. All that remains now is to do the same procedure of copying up the other files from usr/bin that Wacs is asking for. We found we needed the following: pbmtext, pnmcat, pnmscale, pnmtojpeg, pnmtopng, ppmtogif, pngtopnm, giftopnm and jpegtopnm.

The first of the two final things we have to do is to check that everything under the ~/public_html/cache tree is publicly writeable (gulp!) because we share no groups in common with the web server. The second is to add the LD_LIBRARY_PATH variable to the environment used by the web server so that the netpbm commands actually work when invoked by the wacs commands themselves. Fortunately the dbienvvar and dbienvvalue variables originally added to enable Oracle to be supported can be used for this purpose. In the wacs.cfg file, set dbienvvar to LD_LIBRARY_PATH and dbienvvalue to the path to your library directory where you placed the libnetpbm.so.10 file; it's probably something along the lines of /home/yoursite/lib. If you're using our sample WebHosting configuration file as a basis, we may have already set this one up for you. You will also need to add a suitable entry in your .bashrc or .cshrc to set LD_LIBRARY_PATH for your shell.