I currently have a php file which allows the user to upload a file. Once they upload the file, it runs a program with the file using MPI.
The problem is that the script says it cannot find the file .mpd.conf (config file that must be present in users home directory). I'm guessing that this is because it is running as a different user than myself.
I am using apache2 to serve this webpage, can anyone help me get this working? I don't know too much about how PHP works.
Although the user can set a lot of things in their .mpd.conf, the reason it's required is just to have a `secret word' that the launched mpds can agree on -- like (say) erlang machine cookies, it's just so that the various mpd daemons launched only can make sure they're only contacting the right other mpds.
Presumably your php program is launching a script which does the mpirun/mpiexec? If so, you could simply have the script check for the existance of ~/.mpd.conf and if it doesn't exist, create it containing a line of the form MPD_SECRETWORD=[something-unique-here] and then make sure its created with read/write permissions only for that user.
Related
I have a PHP app, which is working fine for me, both on test system and a production system.
But another user of my app wrote me, that it creates a lot of files .nfs00000* on his system and it slows down loading of the page.
My app does not create any files on the filesystem, all datas are stored into MySQL. So I was really surprised by this. But that user removed my PHP app from his website and the problem dissappeared.
I will be honest -- I know nothing about .nfs00000* files and I was not able to google out anything reasonable about them. Can someone please try to give me explanation, what they are, why they are created and if I can do anything to avoid their creation?
Thanx, Honza
Maybe this can help:
Under linux/unix, if you remove a file that a currently running process still has open, the file isn't really removed. Once the process closes the file, the OS then removes the file handle and frees up the disk blocks. This process is complicated slightly when the file that is open and removed is on an NFS mounted filesystem. Since the process that has the file open is running on one machine (such as a workstation in your office or lab) and the files are on the file server, there has to be some way for the two machines to communicate information about this file. The way NFS does this is with the .nfsNNNN files. If you try to remove one of these file, and the file is still open, it will just reappear with a different number. So, in order to remove the file completely you must kill the process that has it open.
If you want to know what process has this file open, you can use 'lsof .nfs1234'. Note, however, this will only work on the machine where the processes that has the file open is running. So, if your process is running on one machine (eg. bobac) and you run the lsof on some other burrow machine (eg. silo or prairiedog), you won't see anything.
(Source)
If your app is deleting or modifying some files it could be the cause of the problem.
We are having some unknown code (virus?) sending out thousands of mails from our server suddenly and though we think we have removed the corresponding malicious PHP file, the mails are still getting sent out.
How can I find out which code is sending out the mails? I tried looking under /var/log/maillog but no pointers there. Any other way of finding it out?
We are using CentOS distro.
The fact that you have removed the corresponding PHP file doesn't mean that that file didn't manage to make copies of itself elsewhere on your system. If you say that these emails are being sent continuously, ie. this was not a single occurance, then it is possible that the script has somehow infiltrated your crontab files and is calling itself periodically.
Take a look at your crontab file for each user (including root) on your system. Make sure to inspect any script the crontab is executing no matter how innocent it looks.
Another option would be an .htaccess file executing a certain script when presented with a specific URL. One could easily hide the execution of a script in this way. Inspect all .htaccess files for strange rules that you have no record of...
Hopefully one or more of these options will shed some light on where these emails are being sent from...
The malicious code was in Wordpress DB and associated PHP files, every time site was getting loaded - it was called with call to header PHP. We cleaned the site and fresh install fixed the problem. I had already checked crontab and there was no infected code there. Thanks for all the pointers.
So I'm a bit confused about what crafty users can and can't see on a site.
If I have a file with a bunch of php script, the user cant see it just by clicking "view source." But is there a way they can "download" the entire page including the php?
If permission settings should pages be set to, if there is php script that must execute on load but that I dont want anyone to see?
Thanks
2 steps.
Step 1: So long as your PHP is being processed properly this is nothing to worry about...do that.
Step 2: As an insurance measure move the majority of your PHP code outside of the Web server directory and then just include it from the PHP files that are in the directory. PHP will include on the file system and therefore have access to the files, but the Web server will not. On the off chance that the Web server gets messed up and serves your raw PHP code (happened to Facebook at one point), the user won't see anything but a reference to a file they can't access.
PHP files are processed by the server before being sent to your web browser. That is, the actual PHP code, comments, etc. cannot be seen by the client. For someone to access your php files, they have to hack into your server through FTP or SSH or something similar, and you have bigger problems than just your PHP.
It depends entirely on your web server and its configuration. It's the web server's job to take a url and decide whether to run a script or send back a file. Commonly, the suffix of a filename, file's directory, or the file's permission attributes in the filesystem are used to make this decision.
PHP is a server side scripting language that is executed on server. There is no way it can be accessed client side.
If PHP is enabled, and if the programs are well tagged, none of the PHP code will go past your web server. To make things further secure, disable directory browsing, and put an empty index.php or index.html in all the folders.
Ensure that you adhere to secure coding practices too. There are quite a number of articles in the web. Here is one http://www.ibm.com/developerworks/opensource/library/os-php-secure-apps/index.html
Hey folks, this question can't be too complicated. Please provide a solution to at least figure out the ultimate root cause of the problem.
I currently write an application, which controls Excel through COM: The app creates a COM-based Excel instance, opens some XLS files and reads their contents.
Scenario I
On Windows 7, I start Apache and mySQL using xmapp-control with system administrator rights. All works as expected. The PHP-based controller script interacts with Excel as expected.
Scenario II
A problem appears, if I start Apache and mySQL as 'background jobs'. Here is how:
I created two jobs using Windows 7 Task Planner. One runs apache_start.bat, the other runs mysql_start.bat.
Both tasks run as SYSTEM with elevated privileges when Windows 7 boots.
Apache and mySQL work as expected. Specifically, Apache serves HTTP request from clients and PHP is able to talk to mySQL.
When I call the PHP controller, which calls and interacts with Excel using COM, I do receive an error.
The error message comes from Excel [not COM itself] and reads like this:
Excel can't read the specified Excel-file
Excel failed to save the file due to an ill-name worksheet
Interestingly, the first during the first run of the PHP-based controller script, it takes a few seconds to render the error message. Each subsequent run immediately renders the error message.
Windows system logs didn't show a single problem report entry.
Note, that the PHP program and the Apache instance didn't change - except the way Apache was started.
At least the PHP controller script is perfectly able to read the file-system, since it provides the pathes to the XLS-file through scandir() of a certain directory.
Concurrency issues can't be the cause of the problem. A single instance of the specific PHP controller interacts with Excel.
Question
Could someone provide details, why this happens? Or provide ways to isolate the ultimate cause of the problem (e.g. by means of a PowerShell 2 script)?
UPDATE-1 :: 2011-11-29
As proposed, I switched the Task Planner job from SYSTEM to a conventional user. Works. Apache and MySQL get started and process request.
Unfortunately, the situation regarding Excel did't change a bit. Still, I see the error.
As assumed earlier, the EXCEL COM server starts. I'm able to change various settings (e.g. suppress dialogs) without a problem through the COM-instance.
The problem happens while calling this:
$excelComObject->Workbooks->Open( 'PathToXLSFile' );
UPDATE-2 :: 2011-11-30
Added the accounts USER, GUEST and EVERYONE with the READABLE right to the access control list of the XLS file . No change.
Modified the app in such a way, that the PHP part creates a copy of the XLS file as a temporary file and moves the contents of the original file into this. Just to ensure, that the problem isn't forced by odd file / path names.
Still, the problem persists.
UPDATE-2 :: 2011-12-05
I'm going to send the EXCEL COM-Server methods in such a way, that Excel creates a blank file and saves it to /tmp. Let's see, if Excel even isn't able to read this file.
Go into the task planner and let everything run as a local user. This will probably require that you enter a password so create one if you don't have one already.
Excel is a user-level application that shouldn't run as SYSTEM. I'm sure there are ways around it, but you should simply let everything run at the correct level.
Having Apache run on the user level isn't a problem.
Try creating the following directories:
C:\Windows\SysWOW64\Config\Systemprofile\Desktop
C:\Windows\System32\Config\Systemprofile\Desktop
it worked for me :-)
http://social.msdn.microsoft.com/Forums/en-US/innovateonoffice/thread/b81a3c4e-62db-488b-af06-44421818ef91
In the past (read: pre Vista) services had an option called "Allow Service to interact with desktop" which allowed services to spawn windows etc. Starting Vista, this is no longer allowed.
I suspect Excel is failing because it can't function under this restriction. Thus, any attempt to run it as a service in your Win7 installation will fail.
You can Windows XP and allow desktop interaction for your Apache process, which I don't really recommend for obvious reasons.
Another approach I would take is to create a PHP script that runs as a regular process and listens on a socket in an infinite loop. Your PHP script that runs under Apache would communicate with the secondary script through the local socket and have the secondary script spawn Excel.
This may sound complicated but in fact it's not a lot of code and it fixes a problem you will soon have anyway: You should only have one instance of Excel running or you may run into problems. The secondary script could queue requests, handing off one by one to Excel then taking the next in the queue.
I am trying to create a script that will display the contents of a folder, onto a newsticker, and I was wondering if anyone had a script that could run this. I was thinking probably php, but it has no been working for me.
Thanks for the help
The software I am using is dreamweaver cs4
I'm guessing that you have written some PHP, but are trying to run it locally without a server - for PHP to work you need a server. XAMPP is a good bet to do this locally, or you'll need to upload your file to some hosting that supports PHP.
I'm thinking why you're having trouble with it is because you just copy and pasted the code in a .html file and opening it on your local environment.
With that said, in order for it to run locally, you have to install php and a http server. The code is done on server side, not client side. So either get a hosting service that supports php or download and install your own server and php.
Also, if you already have the above, the code has to be surrounded by a < ?php and ? > tags(without spaces). If you're running it on cli, then you need to make sure you give it execution permission with the path to php, OR execute php < name of script >.
Last, the code you presented provides major security flaws. The first of which is where will the "$dir_path" variable be set? Will that be user given, or will you specify the variable?
Whenever you allow users to view your file system, always make sure you give limitations to it. For example, let's say you did this:
www.example.com/newsticker.php?path=/www/files/newsticker
looks innocent enough, but a clever hacker could say let me try....
www.example.com/newsticker.php?path=/
And so fort.
So be careful and don't allow users to specify directories or execute code.