custom php.ini seems impossible

i followed the directions (or at least a modified version that actually half works), and things are just screwy.

first, the directions:

In reply to:

---

mkdir ~/domain.com/cgi-bin/

Then make a file in ~ called php_update containing the following


#/bin/sh

CGIFILE="$HOME/domain.com/cgi-bin/php.cgi"
INIFILE="$HOME/domain.com/cgi-bin/php.ini"

cp /usr/local/bin/php "$CGIFILE"
cp /etc/php/php.ini "$INIFILE"

perl -p -i -e '
s/.*post_max_size.*/post_max_size = 100M/;
s/.*upload_max_filesize.*/upload_max_filesize = 100M/;
' "$INIFILE"

---

ok, now $HOME apparently doesn't work, so i had to change it to /home/myusername. (and yeah i changed domain.com) the stuff below the cp lines doesn't apply to me but i tried this with and without them. i run the php_update from the shell and i get:
command not found2
command not found5
(and when the php.ini file isn't already there in cgi-bin, a no such file or dir)

ok, so that copies the cgi and ini file to my /cgi-bin. but crazy thing: cuteftp (and webftp) shows a php.ini that's 22.53 KB, which i cannot edit or view, plus when i upload my php.ini it doesn't overwrite the other, and even disconnecting from the ftp and reconnecting back it shows BOTH files. at that point trying to view either views my custom one, and trying to delete both only deletes my custom one. i'm unable to delete my cgi-bin folder and start over because it can't delete that weird file.

ok, now third, i upload my .htaccess:
Options ExecCGI
AddHandler php-cgi .php
Action php-cgi /cgi-bin/php.cgi

to my domainname.com folder, and when i run my php script now i get an error 400.

the whole problem i'm having is the script was giving an error, the script author told me to add to the .htaccess:
PHP_FLAG output_buffering on
but that's not doing anything so he said to do php.ini.
i can't figure out why this thing is acting so crazy and i'm getting really aggrevated.



-edit-
oh, my custom php.ini:

output_buffering = On
zend_extension = ../ioncube/ioncube_loader_lin_4.4.so
memory_limit = 100M
include_path=.:/usr/local/lib/php:/usr/bin/pearEdited by gnznroses on 01/30/07 01:47 PM (server time).

You'll have better luck if you stick to the instructions that are posted in the DH wiki. That procedure works.

Why in the world do you need a 100MB memory limit? That is *not* a very nice thing to pull on a shared server.

--rlparker

well, no those on the wiki don't work. i hafta change $HOME for it to do anything. other than that tho i followed the directions, except some steps for setting up a cron file which i'm not worried about.

as for the MB limit i have no clue what that even does or anything. i'm sure it's not actually using 110 MB of memory tho....

In reply to:

---

i have no clue what that even does or anything

---

And you're using a custom php.ini file?

"The instructions provided in this article or section are considered advanced."

That means don't mess with it if you don't know what you are doing.

In reply to:

---

well, no those on the wiki don't work

---

Yes, they *do*, and there are *many* DH users who have followed those instructions with success.

In reply to:

---

i hafta change $HOME for it to do anything.

---

No, you *don't*, if you are following the instructions correctly and *understand what you are doing in the shell*.

In reply to:

---

as for the MB limit i have no clue what that even does or anything. i'm sure it's not actually using 110 MB of memory tho....

---

Then you have *no* business modifying the php.ini Dreamhost has installed for use on your shared server.

--rlparker

ok, i'm sorry but you all are just retarded. do i know what exactly that line does? no. but the dude who wrote the commercial script obviously does. the script is not resource intensive, it ain't gonna use no 100 megs of ram or anything, i'd say he just stuck a high figure on there because the actual amount doesn't matter, so long as the setting is changed from off to on.
i know what i'm doing, with the shell and changing the ini and all, and the code on the wiki DOES NOT work. it aint very freakin hard to type some text into a console window. changing the $HOME variable does the job and should make no different. it's just hard-coding the path instead of using a variable. so for all intents and purposes i follwed the directions.

I'm sorry but, who's the retarded one who can't get it to work?
Good luck finding someone who will help you here (for free), with that kind of attitude.

well the "help" i got ths far was just some jackass telling me i don't know what i'm doing. he's the one with the bad attitude. i know what i'm doing, i know how to freakin type some text into a shell and upload a file, and whatever else i have to do, but something just ain't right. coming on here and telling me i have no business changing things ain't gonna get a friendly response from me. i'm funny like that...

In reply to:

---

ok, i'm sorry but you all are just retarded.

---

Nice! Okay, you have made your point, and your opinion has been noted.

In reply to:

---

but the dude who wrote the commercial script obviously does.

---

The "dude" that wrote the program may very well know what *he* is doing; that does not mean that *you* know what *you* are doing.

In reply to:

---

the script is not resource intensive, it ain't gonna use no 100 megs of ram or anything,

---

Your posts have already made it quite clearly evident that *you* have no idea whether the script is "resource intensive" or not and that you have no idea how much ram the script is likely to use.

In reply to:

---

i'd say he just stuck a high figure on there because the actual amount doesn't matter, so long as the setting is changed from off to on.

---

And now you have proven that you are completely clueless about what is involved with these PHP settings, which is *exactly* why you shouldn't be messing with them.

In reply to:

---

i know what i'm doing, with the shell and changing the ini and all, and the code on the wiki DOES NOT work.

---

No, you *don't* know what you are doing, and your statements in these posts make that crystal clear. There is nothing wrong with not knowing something; it's just lame to act like you do when you don't. You can say those scripts don't work as many times as you like, and it does not change the fact that your inability to understand what those shell and perl scripts are doing does not mean they don't "work". They *do* "work", if you know how to use them. Of course, you never bothered to indicate what instructions you were following, and there is more than one section in the wiki that deals with such stuff - I believe from your code snippets that you were referring to the Wiki article on PHP.ini; those instruction work properly *for what they were intended to do*, which was to change to max upload filesize. Modifying that to make other php.ini changes is *not* covered in that article.

In reply to:

---

it aint very freakin hard to type some text into a console window.

---

That *is* the easy part - knowing what to type, and why, and how to accomplish your goal, is another thing all together, as you have just proven. Since you "know what you are doing", you shouldn't even need the wiki article to solve your problem.

All that said, you could have taken another approach. You *might* have explained what you were trying to install, and what changes you felt needed to be made, and why. You might have even asked how to set up a php.ini to facilitate your application, but instead you decided that "the wiki article doesn't work", took it upon yourself to follow the directions "for all intents and purposes" and then come on here and complain that it didn't work as expected. You might want to take the time to review How To Ask Questions The Smart Way...and maybe you will learn something. Or not.

The "bottom line" is pretty clear here: since we are retarded and you know what you are doing, you obviously *don't* need any help - so knock yourself out! Good Luck with that.

--rlparker

In reply to:

---

i know what i'm doing, i know how to freakin type some text into a shell and upload a file, and whatever else i have to do, but something just ain't right.

---

Right! Did it ever dawn on you that you need to know something more than you do?

In reply to:

---

coming on here and telling me i have no business changing things ain't gonna get a friendly response from me. i'm funny like that...

---

You may think that you are "funny like that", but to others it just makes you look the fool. You do *not* have any business changing security and performance related options installed by your hosting provider, on a shared server, if you *do not understand the things you are changing*.

If you can't understand that, then you are too ignorant or stupid to be allowed to change *anything* on a server where your actions can result in the degradation of performance for others.

--rlparker

well just so ya know i got it all working, figured it out myself. wanna know the problem? the php.ini line that references the ioncube loader. it's not needed as ioncube can be loaded without it, so i tried removing it and all is fine now.
i'm sure you woulnd't have figured that one...

Good Deal! And hopefully that 100MB memory limit won't get regularly used by your script, and all will be well for your neighbors on your server.

I'm glad you got it "sorted"

--rlparker (aka "jackass")

i can remove that line if it makes you feel better. i seriously don't think it's a problem as it usually isn't even needed. usually php.ini doesn't have to be changed, but since i couldn't turn on that buffering setting through htaccess i had to edit php.ini. so it's not a needed line so i can remove it. i can ask what the purpose of it is, but trust me, if my site starts hogging memory like crazy DH will let me know...

In reply to:

---

but trust me, if my site starts hogging memory like crazy DH will let me know...

---

You can bank on that.

Remember, there *is* a limit imposed by DreamHost on the amount of memory a single user can consume, regardless of any limit you set for PHP. Running into this latter limit can result in your site throwing errors when under heavy use.

Mark

In reply to:

---

i can remove that line if it makes you feel better.

---

In a perfect world, it should not make any difference; a properly written script should manage it's own memory and fail gracefully upon unexpected error rather than "running away". There is a good chance that, Dreamhost running PHP as CGI under SuEXEC will result in their prockiller just aborting it if it gets out of hand.

The reason I was concerned is that just because a script is "commercial" does not necessarily mean it is well coded, and some such poorly coded applications will take, and use, all the RAM you give them. This is one of the reasons that memory limits on shared servers, where folks are allowed to run their own and 3rd party scripts, are usually set with a much lower memory limit - usually in the neighborhood of 12-16 MB.

In reply to:

---

if my site starts hogging memory like crazy DH will let me know

---

That is true enough also. You certainly do not need to remove the line for my sake (you are not on the same server as me, so I'm only "generally" interested ). The lower limit is only there as a safety mechanism - since DH lets you change it, the responsibility that goes with a higher setting lies with you. I just wanted you to know what was involved. Actually, if you review the thread, I was just curious to know why your application thought it needed that much RAM.

It could be that it doesn't, but that the developer figured "I'll take all I can so it will run faster" - which is *great* if you are on a dedicated server and have lots of RAM but "not so great" if a lot of other users are sharing the RAM in a box.

--rlparker

In reply to:

---

the "help" i got ths far was just some jackass telling me i don't know what i'm doing. he's the one with the bad attitude.

---

I've got to agree with you there. SC "Jackass" Jessey sounds better to me than RL "Jackass" Parker, but YMMV. Alliteration, or something, you know.

In reply to:

---

I've got to agree with you there. SC "Jackass" Jessey sounds better to me than RL "Jackass" Parker, but YMMV. Alliteration, or something, you know.

---

It looks like you might be losing track of your various personnae, Bob. This is really much more of an "Anonymous2" type post than an "Ardco" post. Are you having some difficulty keeping the various personalities/puppets sorted?

--rlparker

In reply to:

---

It looks like you might be losing track

---

Look who's the troll searching for "dirt" now, Mark.

The only troll I see in this thread is you.
Take it to PM if you're going to be an idiot, your pointless bickering has nothing to do with the OP's topic nor is it helping him with this issue.

In reply to:

---

Look who's the troll searching for "dirt" now, Mark.

---

Considering the number of times rlparker and myself seem to post simultaneously to a thread, I think the likelihood of us being the one person is remote, but I am flattered you would think that.


Mark

If you could actually explain what trouble your having in understanding the wiki's instructions, which to me is what it appears to be, I think most of us would be happy to help you.
It just seems you're more interested in blaming someone/something (the wiki) for your own inability or lack of experience.
I personally don't mind helping you, if you can get around that, and preferably explain in detail which portion of the wiki you had problems with. Your original post, as it currently stands, doesn't honestly help me figure out where you went wrong in the wiki.

Actually, I'm also flattered that you think Mark and I might be a single person...he often gives better answers than I do, and I'd love to take credit for them.

*Plus* that would mean that "rlparker/raz2133" would have (now) 4,029 posts on this forum..and that *would* be a lot more impressive that "98 posts to go to DreamMaster!"

--rlparker

In reply to:

---

your pointless bickering has nothing to do with the OP's topic nor is it helping him with this issue.

---

Yeah, this from you was much more on target:

In reply to:

---

I'm sorry but, who's the retarded one who can't get it to work?

---

Sorry to come along and butt in late in your name calling fest, after the OP solved their own problem. Didn't know it was a private party.

In reply to:

---

....after the OP solved their own problem

---

..a problem which had nothing to do with the scripts in the wiki not working, and a thread which had already evolved *past* name calling to productive discussion...till you showed up and uncapped your "poison pen". Good Job, there, stirring up a resolved thread.

You really don't need to be a dick to participate in a thread; people will still exchange posts with you even if you aren't (a dick).

--rlparker

In reply to:

---

I'm also flattered that you think Mark and I might be a single person

---

Mark, Mike, Sam Adams, whatever. Glad I could flatter you, Norm. Single, married, fast typer, whatever.

i figured it out now. the problem was that the wiki was down off and on and i couldn;t access it, but i found a post on the forums that apparently helped someone fix thir problem, but it didn't work for me. after the wiki came up i saw a difference and changed it and it got that part working (i think it was working anyways tho cause all i needwas to copy the cgi/ini files which it, despite the error the shell gave me). the problem i had afterwards was due to a line in the php.ini. but the strange "ghost" files are still there. they ain't hurting nothing but it's odd.

In reply to:

---

Telling someone "Don't be a dick" is something of a dick-move in itself, so don't bandy the criticism about lightly.

---

Sorry, but Guns n roses reminds me of the jungle. Say Goodnight, Dick.

Goodnight Dick.

-- Dick

In reply to:

---

Telling someone "Don't be a dick" is something of a dick-move in itself, so don't bandy the criticism about lightly.

---

Good! I see you read it, which was my goal with the post. I only noted that you "didn't have to be a dick" to be involved in discussions, and even *that* was not done "lightly" - you earned it by "stirring up" a "becalmed" thread.

--rlparker

In reply to:

---

Considering the number of times rlparker and myself seem to post simultaneously to a thread,

---

One word - Tabs!

In reply to:

---

I think the likelihood of us being the one person is remote

---

So the best way to disguise puppets is to post simultaneously in the same thread. But that's one of the most objectionable, offensive uses...

In reply to:

---

which was my goal with the post.

---

Manipulative, Dick. Hey, Jackass and you earned it by stirring up a yet to be stirred thread.

In reply to:

---

Manipulative, Dick. Hey, Jackass and you earned it by stirring up a yet to be stirred thread.

---

Hey, I've been called a whole lot worse than "dick" and "jackass" by people whose opinions mattered...I even acknowledged the OP"s use of that term, accepted it, and signed my next post accordingly. You calling me names here means little to me, so if it helps you reach your "posting goal" of attaining that (apparantly) coveted "DreamMaster!" forum title..go go!

As for "stirring up" a "yet to be stirred thread", I stand by my posts; the fact that something might be unpleasant to hear does not mean it isn't valid, and if such posting is "stirring up" a thread, then..oh well.

--rlparker

In reply to:

---

"dick" and "jackass"

---

FTR, I called you Dick, not dick. I forgot the smilie, but it's like calling you Mark, plus a possible double meaning score. There's no point in me, you and Dick discussing whether the other guy is a Jackass.

Go read your own link, Dick, I mean dick-link. It doesn't matter if you're right.

"For those who believe, no explanation is necessary; for those who don't, none will suffice."

Jokes that require explanation aren't funny.

Yeah, oh well.

Good points, all.

--rlparker

well, if anyone wants to help me out i got another very odd problem which i'd say is attributed to using the custom php.ini somehow. i set up a subdomain, but instead of keeping the usual username/sub.domain.com structure, i changed it to username/domain.com/sub (a requirement of my php script it seems). ok, if i upload an index.html to domain.com/sub, it works fine. but, if i put an index.php in there instead, i get an error 404. oddly, if i tpye in sub.domain.com/index.php i still get an error 404, yet something like sub.domain.com/index2.html works fine. what does work is domain.com/sub/index.php. what kinda sense does that make?
i have no idea how to fix it, but i'd guess maybe an htaccess file can do something about it.


-edit-
btw, this would be so much easier if the "PHP_FLAG output_buffering on" setting would just work from .htaccess, so i don't need a custom ini, but apparently that's not possible? it didn't work for me at least.
but anyways, this subdomain thing has me stumped.

-edit-
realized my post is kinda confusing, so to sum it up:

doesn't work:
sub.domain.com (when using index.php)
sub.domain.com/index.php

works:
sub.domain.com/index.html
sub.domain.com (when using an index.html file only)
domain.com/sub/index.phpEdited by gnznroses on 01/31/07 02:48 PM (server time).

In reply to:

---

i set up a subdomain, but instead of keeping the usual username/sub.domain.com structure, i changed it to username/domain.com/sub (a requirement of my php script it seems).

---

Have you also installed a custom PHP for this sub-domain? Remember, even though you have set the web-directory as a sub-directory in domain.com, Apache will still see the web-root directory as domain.com/sub/ for this sub-domain, not domain.com.

Mark

i'm not 100% sure what you're saying, but no i have not set up any custom ini for the subdomain. i only did that process once, for the main "domain.com" directoy.

do i need to set up another php.ini? i think you're saying even tho sub.domain actually resides in domain.sub that it still has to have it's own custom php.ini. is that correct?

it is allowed to set it up the way i did, right? setting the web directory to domain.com/sub instead of the way it enters it as you type in the "domain to host" url?

Edited by gnznroses on 01/31/07 03:45 PM (server time).

In reply to:

---

i think you're saying even tho sub.domain actually resides in domain.sub that it still has to have it's own custom php.ini. is that correct?

---

Well, I don't have any sub-domains setup as you have done, so I can't say for sure, but normally yes, if the sub-domain needed changes to the php.ini settings then it would require it's own custom PHP install, it would not automatically have access to the custom install from the parent domain. Although, there is a method detailed in the wiki for installing a custom PHP into your home directory and 'sharing' it between (sub)domains.

The fact that php files are not working at all in your sub-domain is strange, I would have expected the sub-domain to use the default DreamHost PHP install. Perhaps there is some strange .htaccess interaction going on.

Mark

hmm, i searched the wiki but the only page with subdomain and php.ini both is something about "trac" and i didn't find the info on that page. i wonder if i need to do some kind of complicated mod_rewrite or something? cause i basically need the opposite of what the remap sub-dir feature does.

since i couldn't find how to share the custom ini with subdomains, i copied the php.ini/cgi to a cgi-bin in my /dubdomain folder. now, instead of getting an error 404, i get an error 500. checked the permissions on those and they're same as the first set of custom files i have on the main domain. not sure what's wrong.

In reply to:

---

now, instead of getting an error 404, i get an error 500.

---

Have you added the required lines to the .htaccess file in the sub-domain web-directory?

Is it throwing the error when you browse directly to the sub-domain, or when you browse to it from a reference on your parent domain? If the latter, how are you referencing the sub-domain? It is probably wise to reference it as sub-domain.yourdomain.com, not yourdomain.com/sub-domain/

Mark

i figured it out just now. in order to copy the custom files, i had copied them from the ftp to my comp and then back again into the other folder (since ftp doesn't support Copy, or so cuteftp tells me). well i guess that changed the linbreaks or did something, as running a shell script as before got it working :)

In reply to:

---

as running a shell script as before got it working :)

---

Excellent. I am glad to hear you got it sorted, hopefully things will go smoothly for you from here.

Good luck.

Mark

thanks everyone for the help, even tho i solved both my problems myself, lol

In reply to:

---

thanks everyone for the help, even tho i solved both my problems myself, lol

---

Thanks for the vote of confidence.

To be fair, we *did* point you in the right direction re: the sub-domain requiring it's own PHP install.

Anyway, what does it matter, the problem(s) are solved, enjoy.

Mark

ah, right you are :)