Posted: Thu 24 May 2007, 15:49 Post subject:
XAMPP not using symlink correctly in multisessionSubject description: Works ok from 2.16 installed on hd

I've had a persistnent problem with installing XAMPP on a mulit-session CD. It doesn't seem to find images and stylesheets in the htdocs directory for localhost applications ( both PHP and static HTML ).

I've already put "root/my-applications" in every XAMPP configuration file I can find. Doesn't seem to help. It seems to involve something about the Document Root, but that's only a guess at this point.

In fact, I realized it didn't make much sense to do in the first place, because XAMPP is obviously following the main symlink or it wouldn't find the PHP application ( minus style sheets and images ). However, multi-session makes it so easy to tamper with the system internals that it's hard to resist tampering tempation to do wild things that I'd never dream of doing anywhere else. After an extended config file orgy, all I have to do is "just say "no". The best of both worlds, like a morning-after pill.

As I understand it, there is a symlink from /opt to the root/my-applications directory. Is there somethig about symlinks and XAMPP on multi-seesion CD that is different from a disk install ? It works fine on hard disk.

I've looked at some of the other threads on the subject and other people have had problems with XAMPP as well, but I didn't understand some of their comments, particularly about how XAMPP treats symbolic links.

Does anyone have any suggestions for next steps ? Would it help to install a more recent version of XAMPP ?

- Bill Breitmayer

BTW, I've been hacking away at Puppy multi-session CDs since pre version 2 and think they are the most alpha top dog in the linux universe. The remastering process in 2.16 is soooo easy that it's become a personal priority ( some might say obsession ) to get the beast to behave itself. I really want to get XAMPP running. Are there debugging files or montioring tools I should be looking at to try to catch the varmint in the act ?

Anyway, part of your problem is the unique workings of the live CD, which if I understood it right, stops reading certain files when RAM is exhausted. So if you are using XAMPP, you must have lots of RAM.

That project of your is interesting. Let's see if your problem goes away._________________Puppy user since Oct 2004. Want FreeOffice? Get the sfs (English only).

Not sure which files, but if you mean http.conf and other config files they live in the lampp/etc directory, depending on the version of XAMPP and the target machine. The Windows version of XAMPP is very different ( bye bye IIS ). However, there may well be other important files that are not where I expect them to be.

[Raffy] Anyway, part of your problem is the unique workings of the live CD, which if I understood it right, stops reading certain files when RAM is exhausted. So if you are using XAMPP, you must have lots of RAM.

[Flash] Multisession Puppy will use swap memory if available.

Good point and a definitely a candidate for dropped path problems. My machine has 640 meg and a 512 meg swap partition. When I run "free", there usually about 300+ meg availible and the swap file never gets any activity. But that doens't eliminate the possibility of something dropping out of memory during a demand spike fo some sort. Something to keep an eye on.

XAMPP/Puppy works fine as a disk install so I may be able to remaster a good multi-session from disk. I still need to check how it behaves as a frugal install and other permutations in the configuration to see if I can detect a clues of some sort.

[Raffy] That project of your is interesting. Let's see if your problem goes away.

[Flash] I don't have a clue what you're talking about, quasimodal, but it sounds like you're having too much fun.

I've been nibbling away at this since last fall, but I'm getting pro-active about it now.

The remastering process was pretty good before version 2.16, but now it's vastly simplified. The whole package worked well in the past, but now it works so well that it's really a quite viable alternative to hard disk or network installation, a third force as it were. Combined with the fact that a good CD/DVD drive runs about as fast as an low-end ATA disk ( about 3 meg/sec ) and one has a winning technology. For spam-less and spyware-less browsing, nothing beats it.

The ony fly in the soup is that either the CD/DVD drive works with multisession or it doesn't. I've never found a way to get a non-working drive to work. I heartly recommend HP drives, never had a problem of any sort.

Perhaps you don't miss this, but simple remaster requires manual copying of changed files in /root. Any chance those files are left out during the remaster?_________________Puppy user since Oct 2004. Want FreeOffice? Get the sfs (English only).

One difficulty I've had in tracking down the problem is that I haven't been going about it in a methodical way. I've been mixing versions of CDs with versions of puppy.sfs and sometimes I loose track. So I've gome back to a simple un-reamastered mulit-session CD, built using the xampp150.pup downloader ( 3359 bytes ).

When I go to localhost and get directed to head.php ( etc. ) in htodcs/xampp directory, I get a texty-looking page saying "Welcome to XAMPP for Linux 1.5.0", so far in /localhost/xampp/. It looks for xampp.css and img/head-xampp.gif, both apparently there and get nothing in the page.

When I request the page over from the mulkti-CD server on my little network, I get the same results. Om the other hand, when I make the request from my disk installation, it works fine, same as localhost on the dsik based installation.

I might have suspected something the php.ini file, but I've tried static HTML pages and it seems to be the same for simple /image path names.

In ROXFiler. I click on the lampp icon in /opt and it takes me to ~my-apps/lampp, so the symlink works as far as the file system is concerned.

I've fiffled with http.conf, getting rid of symlinks to /opt/lampp and it didn't seem to change anything.

When I do a negative test referring to an image I know does not exist I get in the /lampp/log/errors file ( for example ) - "Mon May 21 12:27:51 2007] [error] [client 127.0.0.1] File does not exist: /opt/lampp/htdocs/images, referer: http://localhost/test/". So why not an error for the other images "not found" ?

One thing has just occured to me that maybe they are being found and the prolem is permssions, somehow they aren't being extended to the requestor for external page elements, that is "path"/filename. A possibility ? XAMPP is notorious for no password security, but could the beast at the end of the request be in another part of the forest from a simple HTTP/PHP page request ?

Apparently it says they are being gotten. But maybe not ?? Maybe just the request is being gotten and the file itself is not still found ??

Another of my little tactics is comparing the file system on the multi-CD with my disk installation of Puppy 2.0.1, running XAMPP on a Pentium II 200Mz / 128 Meg ( and running very well at that - used 86M, free 40M, 1-2 second repsonse time for simple stuff, with CPU at 100% most of the time of course ). I haven't found any discrepancies, but it's a fairly grueling task and I could easily have missed something.

When I request the page over from the multi-CD XAMPP server over my network from the disk installation of Puppy, I get the same "no sytle no images" results. Om the other hand, when I make the request from my disk installation, it works fine, same as localhost on the dsik based installation.

raffy: Perhaps you don't miss this, but simple remaster requires manual copying of changed files in /root. Any chance those files are left out during the remaster?

I didn't realize that, I thought things had to copied to /root to be saved. The only remastering I've done in earnest is 2.16. and that seems to work very well for Midnight Commander, Foxfire, etc. It seems to me it has be something about XAMPP, that it's writing a configuration file somewhere that isn't being saved.

When I request the page over from the mulkti-CD server on my little network, I get the same results. On the other hand, when I make the request from my disk installation, it works fine, same as localhost on the disk based installation.

This means those files are still outside your document root htdocs. Given that, the error below is likely if the device gets timed out (too slow to respond).

Looking at error 206, this means "Partial content — the requested file wasn't downloaded entirely. This is returned when the user presses the stop button before a page is loaded, for example."

I hope you get all your files together inside the document root to avoid errors._________________Puppy user since Oct 2004. Want FreeOffice? Get the sfs (English only).

" ... the error below is likely if the device gets timed out (too slow to respond)."

I'm still not sure what would be the cause of a "time out". It's on ram disk and the page is being served without a visible delay. Am I missing the point ?

I never ask the question, but do you know of anyone who has gotten XAMPP working on a live-CD ? Or is it just something about the way I am installing it ( or whatever ) ? There doesn't seem to be much about XAMPP in the forums.

Thr good news is that I had time to work on it today. I decided to start a fresh, clean CD from scratch. I renamed all disk based .sfs files, burned a standard 2.16 CD, downloaded XAMPP, installed it. Just a straight boot, download and install, no mulitsession saves or any of that, It didn't work correctly.

I know now that my original idea about the problem was wrong. Symlinks are working fine. I edited the /xampp/head.php file in six ways and moved images into every plausible subdirectory in /htdocs - I couldn't get it to work. So it's not a problem with symlink from the /opt directory to the XAMPP app, it's some problem with the way Apache is accessing images/styles.

The files are probably being found, they just aren't being served up. The access log showed the same 206 errors, but error_log only showed errors for image files that I had deleted and were actually not on disk.

I checked file permissions and they were identical to the disk installation of XAMPP that works. I still need to check out all the interactions of XAMPP "lampp/no password" security in a CD boot environment.

One odd thing I found in the install script, XAMPP places a configuration file and a shell script in the /etc directory, profile.local and xamppsymlinks. But they seemed to be there on ram disk and accessible whatever they were doing.

In any case, something other than the file system is blocking Apache from accessing images and styles. It could also be a caching problem, although caching seems to be happening inside the my-apps/xampp directory. But maybe not. I'll have to check it.

I may be able to compare my configuration to the SLAMPP live-CD ( http://slampp.abangadek.com ) and see if I can find a discrepancy.

I'll keep worrying away at it when I have time. If I can get the bally thing going by investing a few more hours, it'll be worth it. Thanks for your help.

When reading through the XAMPP FAQ pages, I noticed a question about why images weren't showing. The explanation was that with some Linux releases there are "special problems". For some reason, XAMPP has a problem with Puppy mulitsession and but not with a Puppy disk installation ( who knew ? ). The fix is a very simple.

Presto, one has a working XAMPP server running off of a multisession CD remastered from disk. Not only is it an inherently incorrupible server, it's also an installable backup of the disk partition. Basic Puppy, XAMPP, NVu and a few other goodies in an .sfs under 150 Meg. Amazing !

So the bug had nothing to do with symbolic paths and in fact nothing to do with stray XAMPP configuration files being lost. The mastering process seems to pick up almost everything on disk..

I'm going to see if I can install a more recent version of XAMPP, maybe 1.6.2. If some one knows about any special considerations in converting a XAMPP configuration to Puppy, I'd like to hear about it.

Not sure if its of use to you - but I put together a LAMP squash file from slackware binaries of mysql apache and php

ftp://ftp.servage.net/sfs_modules/lamp-301.sfs

username: puppy
password: linux

see

http://www.murga-linux.com/puppy/viewtopic.php?t=28106

You just drop this puppy in and configure the boot to include this squash file - reboot and you are away - the post install script for mysql must be run - mysql_install_db edit /etc/my.cnf to customise your mysql install - then run with

Not sure if its of use to you - but I put together a LAMP squash file from slackware binaries of mysql apache and php

Belated thanks. It worked well. It fiddled around a bit and got it remastered into a multi-session customized ( with no HW detection ) for my main machine. Very slim and fast. I think phpMyAdmin would have been useful and is only about 2Meg ( tar.gz size ).

For a HW detect CD, it would require more work to re-master, copying all the files and directories under /etc and /var, etc.

One of the advantages of XAMPP ( despite the bloat ) is that the whole thing can install into /my-applications. Installing to /root rather than /usr may not be standard Linux, but sometimes it makes applications easier to configure and control. In fact, for newer versions of XAMPP and Puppy, I'm installing directly to /opt with no problems.

You probably have moved to Puppy 4.1 in the intervening months. I've had good luck with installing Slackware packages indirectly using tgz2pet. Often, I've found that if the tgz2pet fails, it probably won't install correctly anyway. But most Slackware packages seem to convert to pets without trouble, so long as there are no unusual libraries to track down.

I think that standard LAMP applications would work as well. although I haven't tried it yet. Probably the easiest way to build a slim LAMP multi-session for Puppy 4.1 is by converting Slackware packages to pets and let the pet package manager do the work.

The are limits however. I tried to replace the Puppy's Bash with Slackware ( installing libtermcap first ! ) and got a kernel panic on the re-mastered CD, although it worked OK on the original. The problem might be fixable, but it's probably better to use the base libraries on dev-411.sfs whenever possible and not mess with Slackware libraries. I'm still working on that one ...

For radical Puppy hacking, multi-session is the best way to go. If I don't like a hardware driver, I delete it. If I think that directory /usr should be called /user, I rename it. With multi-session, I need have no fear of the consequences of my stupidity.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum