Clearing cache manifest via CLI - php

I've automated the deploying of my site and I have a script that runs framework/sake /dev/build "flush=1" This works however it clears the cache directory of the user who runs it, which is different from the apache user (which I can't run it from).
I've read a few bug reports and people talking about it on the SS forum however either there is no answer or it doesn't work for example
define('MANIFEST_FILE', TEMP_FOLDER . "/manifest-main");
I thought about just deleting the cache directory however it's a randomised string so not easy to script.
Whats the best way to clear the cache via command line?

To get this to work you need to first move the cache from the default directory to within the web directory by creating a folder silverstripe-cache at the web root. Also make sure the path is read/write (SS default config blocks this being readable by the public)
Then you can script:
sudo -u apache /path/to/web/root/framework/sake dev/build "flush=1"

Related

How can I find the real location of the tmp dir for a specific program on Ubuntu?

Ubuntu creates a separate /tmp directory for each user, so when Apache asks for /tmp it actually gets /tmp/systemd-private-654e145185f84f6ba097649873c88a9c-apache2.service-uUyzNh/tmp. (That code is different each time.) This is generally a good thing, but it’s annoying me now.
I want to create a bunch of PDF files (using TCPDF in PHP) in /tmp, then use shell_exec() in PHP to run the pdfunite script to create a single output PDF, then load that PDF into memory to serve it to the browser. My problem is that the pdfunite script doesn’t work, which I presume is because it’s not seeing the same path as the files are actually in.
Does PHP’s shell_exec() run code as the Apache user (www-data)? If so, I would assume that it would see the same /tmp dir, but in that case the pdfunite script should work. Is there a sensible workaround here, other than using a different directory and doing the cleanup myself?

Calling Go using PHP's shell_exec is changing GOPATH

I have a Go app that must run from a PHP script with shell_exec()/exec(). The problem is when I call the Go script that way, the GOPATH changes or can't be found, and the imports from go get can't be found too. Everything is fine when I call it manually on terminal.
Trying to solve it, the GOPATH was set to /var/www on .bashrc and updated with source ~/.bashrc), but when I use go env under apache's user (www-data), the folders act like the Apache user can't read the environment variables and read the default values but the root folder from Go's view is /var/www, not /.
How can I make apache/PHP run Go properly?

Where can I find WP_CONTENT_DIR in Wordpress structure?

I am using Query Monitor plugin, but it didn't create db.php symlink in path/to/wordpress/wp-content/db.php, even if I changed permission of the wp-content folder. My changing permission is restricted to one folder or file each time.
I can't do Linux nor Windows command-line queries. There is only one db.php inside query-monitor folder.
This is a quote from Query Monitor plugin:
When Query Monitor is unable to symlink its db.php file into place
Occasionally PHP won't have the correct permissions to put this
symlink in place. Query Monitor will still work fine in this
situation, but you won't see extended information that makes Query
Monitor much more useful.
You can manually create the symlink by running the following command
on the command line:
Linux / OS X:
ln -s
/path/to/wordpress/wp-content/plugins/query-monitor/wp-content/db.php
/path/to/wordpress/wp-content/db.php
Windows (requires administrator privileges):
mklink C:\path\to\wordpress\wp-content\db.php
C:\path\to\wordpress\wp-content\plugins\query-monitor\wp-content\db.php
> Alternatively, you can relax the file permissions on the
WP_CONTENT_DIR directory and then de-activate and re-activate the
plugin and it'll attempt to create the symlink again.
Changing query-monitor or wp-content folder to 777 and de-activate + re-activate plugin has no effect. I don't think I can change permissions in phpMyAdmin, but no idea if I can or not on a table, and no idea how to find and change permissions on that table neither.
Is WP_CONTENT_DIR a php file or line in a file or a table or something else and where is it?
In case it's a line in a php file, how can I change permissions on a php line ?
After many tries, I found out. One thing important: needs a path that begins with /home and can't be done offline else you'll get a conflict because it points to your computer.
No need to download nothing.
Cpanel may have Cron Jobs, which allows one linux bash shell command line as seen in this article (they don't host me). SSH client can also do this but it's more complicated.
Go to Advanced then Cron Jobs then set Once per minute:
ln -s /home/YOUR_HOST_USER_OR_ID/public_html/YOUR_BLOG_FOLDER/wp-content/plugins/query-monitor/wp-content/db.php /home/YOUR_HOST_USER_OR_ID/public_html/YOUR_BLOG_FOLDER/wp-content/db.php
Refresh till file is created, then delete Cron Job immediately after, to avoid repetition x2 on the 2nd minute.
So like that you avoid both errors:
Extended query information such as the component and affected rows is not available. Query Monitor was unable to symlink its db.php file into place. See this wiki page for more information.
Extended query information such as the component and affected rows is not available. A conflicting db.php file is present. See this wiki page for more information.

PHP exec("sudo ...") doesn't seem to work when called over the web?

I have a script write_get.php that I would like to execute via users remotely loading a web page. This script in turn runs
exec("sudo php save_file.php ".$arg1)
to do some file writing that requires sudo permissions. This works fine when I run write_get.php from the command line on my web server as a non-privileged user, but it doesn't work fine when I invoke the script by loading it in a web browser. The web browser presents the same message, making it appear as though there is no error, but the file created by save_file.php is never created. Everything else that needs to happen (another temp file creation that doesn't require sudo + a database insert) work fine, but everything else is in write_get rather than in the sudo-requiring save_file.
I assume the server somehow blocks this call to exec("sudo... when it's made remotely? Or if not, what's happening here? Most importantly, how can I work around this?
p.s. I understand there are probably major security concerns here, but please know there is no sensitive data/anything on this server and that the files created in the sudo-requiring script don't even contain user input, so for the moment I am more concerned with trying to do the above than with creating a safer file structure/alternate way of doing this.
What you're trying to do is a bad idea because you would need to give paswordless root access to the Apache user, which is essentially like making the Apache user equal to root. All it would take to gain root access to your server would be to upload a malicious PHP script and have that script executed by the Apache user. Instead just make the files you are writing to writable by the Apache user by executing:
chown -R www-data:www:data /var/www/html
And then instead of doing exec() just include the other PHP file in your main script.

executing suphp from memory

I manage a server on linux that has apache with php and suphp. Like most setups, all program files are currently stored on disk.
I want to run suphp from ram. I then copied everything in the suphp folder (config files, folders, and program totaling about 2.8MB) to ram. Then on disk, I renamed the folder so the old version doesn't get accessed. I used the -a switch with cp to preserve the permissions and such.
I then made two attempts which both led to failure.
First, I make a link (using ln -s) named suphp that points to the suphp folder in ram. Then when I browsed the file/folder structure, everything else looks identical as if the setup was ready to work.
Since that didn't work, I made another attempt by removing the suphp symbolic link, then creating an empty suphp folder and mount-binding it (using mount --bind) to the suphp folder in ram. That did not even work.
I then looked at my apache error_log, and during the time I tried this steps and until I restored the original setup, I received various error messages with the text similar to this in common in all of them:
"(2)No such file or directory: couldn't create child process: (suphp folder location)/sbin/suphp for (full path to php file on website)".
What baffles me is, why would it report no such file or directory instead of some other error...
suPHP will be loaded into RAM by Apache since it is an Apache module (mod_suPHP). There is no reason to move the actual files/executables to the system's "ram" directory and set up symlinks like you have done.
If your intent is to keep PHP scripts in memory, consider using an opcache like the one built into 5.5 or apc, see How to use PHP OPCache?

Categories