OK first of all, I am a PHP programmer but I have never done anything with CGI and don't know what it is. I know it stands for Common Gateway Interface, but I do not know what it does or what its for.
I was just told that I can upload a shell script to my cgi-bin folder and execute it.
I made a shell script myscript.sh and uploaded it to my cgi-bin folder. The first thing I noticed was my cgi-bin folder is a sibling to my root directory not a child. So I do not know how I would access it?
So I created a directory under my root called cgi-bin2 and put my script there (and chmod them to 755). Then I accessed it from my browser, and all it did was download the file.
Am I missing something?
CGI should send a Content-Type header:
#!/bin/sh
printf "Content-Type: text/plain\n\n"
your_commands_here
Save as anything.sh (extension does not matter) in your cgi-bin folder and chmod 755.
cgi-bin does not have to be a child of your public html folder, it can be an alias.
Related
When you generate Yii 1.x auto-generated application, app's private yiic is placed in protected folder. However, when I use it to execute yiic help shell, I see following message:
It is recommended that you execute this command under
the directory that contains the entry script file of
the Web application.
And then:
* entry-script | config-file: optional, the path to
the entry script file or the configuration file for
the Web application. If not given, it is assumed to be
the 'index.php' file under the current directory.
What am I missing? The protected folder is not the same folder as entry script's one (index.php). Should I move my yiic there for the purpose of executing console commands?
If yes, then why yiic is placed protected folder by default, not there, where entry script is?
If not, then why yiic assumes, that index.php exists in the same folder as yiic itself and why do I have to change this every time with using entry-script flag? This just doesn't make any sense!
I think, the answer is to keep yiic in protected folder, which is secured from web access by .htaccess file. Entry script's folder is not secured that way and is web accessible. I would personally be very worried about moving yiic to root folder, where index.php file exists. If this is the correct answer, then what is the purpose of this confusing message, cited above?
This answer seems to be supporting my idea, as it shows that CRON call should point to yiic placed in protected folder, not to the one in root folder.
Why Yii developers put yiic, where it is not supposed to be (it is looking for index.php in the same folder, so in default auto-generated application, it will fail, not finding it)? How should I understand this situation? Why I'm forced to use extra flag every time? Why default folder structure and file placement does not replicate, what yiic assumes as default?
What the help message means is that you should execute the yiic command from the WebRoot folder (where your index.php is) like so:
% cd WebRoot
% YiiRoot/framework/yiic shell
So yii will take automatically your index.php file to do its things...
But if you want to call another file like index-test.php to get yii executed instead of the default index.php you can:
% cd WebRoot
% YiiRoot/framework/yiic shell index-test.php
http://www.yiiframework.com/doc/guide/1.1/en/topics.console
I am not root. I have written and placed a script in the cgi-bin of my apache server. The code is too long for here, but in a nutshell, the script is called from a browser and a filename argument is also passed as a URL parameter. The script takes the filename, locates the file and reads it. The file contains a simple list of files/locations to be copied. The script iterates through each line of the file and copies the file on that line from the current server to a remote server using ssh and standard rsync commands. It's all pretty standard stuff.
The script runs perfectly from command line, all files are copied correctly. When launched from the browser, the script appears to function perfectly. It throws no errors and debug logs tell me everything was copied fine, only the actual files themselves are not actually copied.
I'm assuming it has something to do with the script being run by apache (or wwwroot) in the cgi-bin, which is not the script owner, as I am. As I am not root, I cannot change ownership or use sudo. Any ideas on getting this to work?
My situation is I only have execute permission from some folder:
Lets say, I would like to backup entire folder and exclude some folder and files with exclude.txt
Here is path I would like to backup:
/pdf/data/pdfnew/2014
And I only have permission to execute from this folder (main):
/pdf/data/pdfnew/2014/public/main
I put exclude.txt in same folder which I can execute the command (main)
I execute this command in (main folder):
tar -cjvf -X exclude.txt 2014.tar.bz2 /pdf/data/pdfnew/2014
The result is it still included folder that I dont want to backup.
Is there a correct way doing this?
Do you have a user/home directory on that server? You should, so you should just place exclude.txt in your user/homedirectory on that server & run it like this from that directory:
tar -cjvf -X ~/exclude.txt ~/2014.tar.bz2 /pdf/data/pdfnew/2014
The ~/ is a shorthand for your user/home directory so in this case it is explicitly stating, “Read exclude.txt from the user/home directory & write ~/2014.tar.bz2 to the user/home directory.
But you also ask this:
Is there a correct way doing this?
There is never one canonical best way of doing something like this. It is all based on your final/end goal. Nothing more. Nothing less. That said, if I were you I would do it like this instead using the -C option:
tar -cjvf -X ~/exclude.txt ~/2014.tar.bz2 -C /pdf/data/pdfnew/ 2014
The uppercase -C option allows tar to internally change the working directory to /pdf/data/pdfnew/ so you can then create an archive of 2014 without having to have the whole directory tree retained in the backup. I find this is easier to work with because many times I want to backup the contents of a directory but have no use to retain the parent structure. That way the archive is more like a traditional ZIP archive which I find is easer to understand & work with.
I want to creat a folder for all user connect and include if use php command.
Example:
/folder/file.php
I can use php command to include in php file
My file: /home/user/public_html/test.php
PHP Code:
include('/folder/file.php');
Please help me
I try with root permission and chmod 0777 for all folder and file but can not include
try checking the apache logs
tail -f /etc/httpd/logs/error_log
While you are loading the page test.php in browser. See what you gets.
Also where is the file test.php is located .
I recently had to reinstall Ubuntu and everything else as my SSD crashed.
I've got Apache/MySQL/PHP set up and can access localhost/ without problems. Running PHP and MySQL works fine as well.
I keep my projects in a Dropbox folder (since the crash) located at /home/powerbuoy/Dropbox/Projects/ and have set up VHOSTs that point to some of the projects in there. I've also set up /etc/hosts so that I can access my projects through http://project-name.dev.
However, when I try to visit http://any-project.dev all I get is 403 forbidden. I've run chmod -R 777 Projects/ and all the files and folders are now green in the terminal. That didn't help.
I checked the error-logs and they say:
[crit] [client 127.0.0.1] (13)Permission denied: /home/powerbuoy/Dropbox/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
But there isn't even supposed to be a .htaccess file anywhere there.
I even set up a completely empty project (/home/powerbuoy/Dropbox/Projects/test/index.php with just <?php phpinfo() inside), set up a VHOST and a http://test.dev URL. I get the same error here.
Any ideas?
Thanks
Edit: I tried moving my test project to the desktop (/home/powerbuoy/Desktop/test/) and now it works :P
Perhaps it has something to do with the projects being located inside the Dropbox folder??
Most probably this is a chmod issue. You must change all trees chmod settings. If you have ssh access you can try this commands:
chmod 755 $(find /home/user/public_html -type d)
chmod 644 $(find /home/user/public_html -type f)
Please replace /home/user/public_html part to 'your real path'.
Apparently simply chmoding the directory the project is in wasn't enough. I had to chmod all the directories higher up in the tree as well.
So even though my VHOST pointed to /home/powerbuoy/Dropbox/Projects/AProject/ simply chmoding /AProject/ is not enough but it has to be done all the way from /home/powerbuoy/ it seems.
The reason you had to chmod the permission going up the directory tree is that Linux doesn't permit you to simply access a folder such as /home/jsmith/my_folder directly. You have to also have execute permissions to / /home/ and /home/jsmith . The execute bit allows the affected user to enter the directory, and access files and directories within it.