free 1and1 webhosting install issue

Quote from: indie at Apr 13, 2006, 12:55 AM

Quote from: Spike at Apr 12, 2006, 11:13 PM

Quote from: indie at Apr 12, 2006, 10:40 PM

So are you saying that in your ftp client the files And directory all read as 777 but the script says they’re not?

Or will the changes not "stick" in the ftp client either?

---Indie

I wish it was that simple I actually use an ssh shell and see the files/directories all read 777.

So the changes are staying, hopefully. Could you not verify the chmod of those files with a garden variety ftp client though or am I missing something? The only things I can think of that could cause this are 1. a windows server, forget that one, and 2. I’ve seen weirdness with chmodding if the ownership of the file gets changed. You could check the chown of them just for a hoot.

Very odd problem if some files/folders will change and others won’t.

---Indie

yes the changes are staying. yeah i checked the chown and they are fine.

Quote from: vbrilon at Apr 13, 2006, 02:53 AM

Hi Spike, please post the output of ’ls -l’ on each directory that the installer complains about

The two lines that I get an error are:

Checking if assets/cache/siteCache.idx.php file is writable: Failed!
Checking if assets/cache/sitePublishing.idx.php file is writable: Failed!

Here is the ls -l for the directory:

u35878210:~/modx/assets > ls -alt
total 68
drwxr-xr-x 5 u3587821 ftpusers 4096 Apr 13 10:36 ..
drwxr-xr-x 16 u3587821 ftpusers 4096 Dec 23 18:10 .
drwxrwxrwx 2 u3587821 ftpusers 4096 Dec 23 18:10 cache
drwxr-xr-x 2 u3587821 ftpusers 4096 Dec 23 18:10 docs
drwxr-xr-x 2 u3587821 ftpusers 4096 Dec 23 18:10 files
drwxr-xr-x 2 u3587821 ftpusers 4096 Dec 23 18:10 flash
drwxr-xr-x 2 u3587821 ftpusers 4096 Dec 23 18:10 images
drwxr-xr-x 2 u3587821 ftpusers 4096 Dec 23 18:10 import
drwxr-xr-x 2 u3587821 ftpusers 4096 Dec 23 18:10 js
drwxr-xr-x 3 u3587821 ftpusers 4096 Dec 23 18:10 modules
drwxr-xr-x 3 u3587821 ftpusers 4096 Dec 23 18:10 plugins
drwxr-xr-x 2 u3587821 ftpusers 4096 Dec 23 18:10 site
drwxr-xr-x 3 u3587821 ftpusers 4096 Dec 23 18:10 snippets
drwxr-xr-x 3 u3587821 ftpusers 4096 Dec 23 18:10 templates
drwxr-xr-x 2 u3587821 ftpusers 4096 Dec 23 18:10 export
drwxr-xr-x 2 u3587821 ftpusers 4096 Dec 23 18:10 media
-rw-r--r-- 1 u3587821 ftpusers 71 Apr 21 2005 index.html

Here is the ls-al for the cache directory:

u35878210:~/modx/assets/cache > ls -alt
total 20
drwxrwxrwx 2 u3587821 ftpusers 4096 Dec 23 18:10 .
drwxr-xr-x 16 u3587821 ftpusers 4096 Dec 23 18:10 ..
-rwxrwxrwx 1 u3587821 ftpusers 10 Jul 14 2005 sitecache.idx.php
-rwxrwxrwx 1 u3587821 ftpusers 29 Jul 14 2005 sitepublishing.idx.php
-rwxrwxrwx 1 u3587821 ftpusers 70 Apr 21 2005 index.html


By the way, thanks to all the people that responded to this thread. Talk about community! You guys rock and do a great service to modx and opensource. Once again deep thanks to all.

That’s odd. The naming is different caps-wise. I’ll take a look at it.

Quote from: vbrilon at Apr 14, 2006, 03:16 AM

That’s odd. The naming is different caps-wise. I’ll take a look at it.

WOW! Duh, I feel like an idiot. Looks like the naming of the files vs. what was the setup/index.php were different. I just changed the name and the install continued!

And then I got another error! But thankfully it was another filename difference error. It was looking for sqlParser.class.php and if you look at the default install under the index directory, it is sqlparser.class.php (no capital P in Parser). I just changed that filename to what it was looking for, and INSTALL WAS A SUCCESS!

And then another error popped up when I tried to go into the manager login. It errored out due to another filename difference. Looking for phpSniff.class.php & phpSniff.core.php. But the default install has the filenames as phpsniff.class.php & phpsniff.core.php (No capital S in Sniff). Changed that it ran fine.

Thanks vbrilon for that overlooked piece of info and thanks to all the rest for aiding in my install problem.

MODX rocks!

EDIT: PS - after further investigating, it looks like it might be the version of unzip on the linux box that I was using. The same modx-0.9.1.zip file unzips differently on a windows box than on the linux box I’m using. I’m guessing that the unzip on the linux box doesn’t extract the same file names for some reason (changing the caps to lowercase maybe). Anyways, here is the unzip version info on the linux box:

u35878210:~/cms2/install > unzip -v
UnZip 5.50 of 17 February 2002, by Info-ZIP. Maintained by C. Spieler. Send
bug reports to the authors at [email protected]; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 2.95.4 20011002 (Debian prerelease) for Unix (Linux ELF) on Aug 20 2003.

UnZip special compilation options:
ACORN_FTYPE_NFS
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
LZW_CLEAN (PKZIP/Zip 1.x unshrinking method not supported)
SET_DIR_ATTRIB
TIMESTAMP
USE_EF_UT_TIME
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
VMS_TEXT_CONV
[decryption, version 2.9 of 05 May 2000]

UnZip and ZipInfo environment options:
UNZIP: [none]
UNZIPOPT: [none]
ZIPINFO: [none]
ZIPINFOOPT: [none]

i’ve just had the same experience

with ’unzip -U modx-0.9.2.zip’ the -U modifier did keep the right case in the filenames. too bad -U is obsolete (according to the man page it’s scheduled to be removed) and its replacement, -L, doesn’t do the trick.

well, we can always use the tar.gz file or ftp the uncompressed files