I got a problem with an API (PHP) I created. The API should create a pdf document depending on the data that is sent. The script works perfectly, running it directly on Ubuntu, Plesk is running on.
The part that is not working is the following:
$cmd = sprintf("pdflatex -interaction nonstopmode %s", escapeshellarg(file));
exec($cmd, $foo, $ret);
The tex-file seems not to be touched... no log files or anything.
Any ideas about this?
Thank you
Latex is usually run by experienced users either raw on the command line or via IDE with console interaction, since there is often the need to see from console feedback why a compilation may fail.
The Simplest check for checking is PdfLaTex installed? is at the system console to enter pdflatex --version this should confirm at least a minimal pdflatex has been found in the environment path and show the variant after a rough value for the level of pi.
So in this case responded pdfTeX 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian)
When trying to run unseen it is not easy to get feed back so the smallest test with a small known sample is again at the console to run in a current working directory with batch mode :-
pdflatex -interaction=nonstopmode sample.tex
This should run with little need for checks, however if the paths to pdflatex are not configured you may need to add the location of the pdflatex executable. Thus you discovered needed /usr/bin/pdflatex -interaction=nonstopmode file.tex
There are many different dependencies in LaTeX packages and modules that require the "env" settings be well defined in terms of inter-related paths (e.g. to support files etc.) so it is worth checking those out from the extensive documentation.
Some modules may require elevation to escape shell restrictions via -shell-escape and the above command may need temporary elevation for one run (it should not be needed constantly) so only include when you know exactly from documentation why a module requires it.
It is tempting for TeX novices to think there is an advatage to use sub folder in a working directory for "chapter and verse", since the working directory may "look" cluttered by potentially dozens of runtime files, however much of LaTeX depends on very specific relative pathing and the best way to avoid errors is not need to keep redefining images or other components by variables, simply say it is in the same folder.
Likewise for the packages they should also be set to a fixed location by means of env variables i.e. for bin folder and fonts and other modular supporting components. It is worth reviewing https://tug.org/texlive/quickinstall.html and note the section about minimal path definition but there is much more than that basic setting required by post installed components
Related
I ran composer in order to use guzzle. It resulted in these directories:
composer
gabrieldarezzo
guzzlehttp
psr
ralouphie
symfony
I noticed the file car.png in the gabrieldarezzo/colorizzar/. That whole directory seemed useless for guzzle so I deleted it and the code still works. I tried deleting some of the other directories, one at a time, but to code failed. Is there a way to know which files are actually required?
Edited after comments:
The purpose of this question is to ask if all of the files composer adds are necessary. I re-ran composer to a new location and it installed version 6.5.8. The gabrieldarezzo was not included so I must have ran composer for some other package at some point. From all of the replies I can see that the answer to my question is yes, they are required. I appreciate all of the replies to this.
That whole directory seemed useless for guzzle so I deleted it and the code still works.
This statement is meaningless without talking about what code still worked - in other words, which files are required depends on what you're actually doing.
If you ask Composer to install Guzzle and then write a PHP file that just says echo 'Hello world'; then you could delete the whole of the vendor directory, and clearly nothing would break. Or you could write echo \GuzzleHttp\RequestOptions::ALLOW_REDIRECTS; and delete everything except for vendor/guzzle/guzzlehttp/src/RequestOptions.php where that constant is defined.
Is there a way to know which files are actually required?
In theory, you could statically analyze a piece of code, recursively identifying which pieces of code were reachable, and therefore what the minimum set of files used would be. You could also monitor a running application and see which files it opened, at the PHP autoloader level or even at the OS / file system level.
But the question is why do you care?
It's important to understand that no file will actually be read and loaded into memory unless it is referenced in some way. This is the purpose of autoloading. So deleting files will not make any difference to the compilation or execution speed of your application.
Deleting the files will reduce the disk space needed to store the application, but it would be rare for the space involved to be a significant proportion of what you have available. It would also reduce the bandwidth needed to deploy it, but source code generally compresses well, so once bundled into something like a tar.gz, this saving is generally also insignificant.
A final note which might be relevant is that none of these files should be committed in your version history. You should commit composer.json and composer.lock, and mark the entirety of the vendor directory as "ignored" (e.g. in a .gitignore file). You can then get the exact dependencies used by any version by running composer install, which reads the versions from composer.lock.
Whenever you require third-party packages without deeply reviewing and track-listing every single file with cryptographically secure content hashes of the reviews outcome, you can easily run into the situation you describe.
The problem with "randomly" deleting such directories is that it does not replace proper dependency checking, but merely prevents the (now removed) code from being loaded onto production systems to be analysed and executed in memory (or in the case of the car.png for some other reason?).
Now between those two poles there is a lot of room and commonly development projects and the people running them aren't important enough that dependencies actually get reviewed thoroughly albeit most of them come without fitness for a particular purpose and a disclaimer in very bold letters.
However if that is a project you look into and you find that some files look fishy, report the issue to the project if you care and it means something to you.
Sometimes projects do not make (extended) use of the dist distribution of a Composer Package (concept) and there is room for improvement (it should go without saying that this is with no judgement of any of those projects practices). E.g. to exclude development resources in production use. This has the benefit that you don't need to remove files "randomly" but you cooperate with actual developers and software distributors.
If I would like to distribute PHP application with installer(package system of OS) how should I proceed? I don't want PHP files to be there, just working application, so when I type 'app' into console, it ends up being launching application, without need to install PHP on system(no php installation on host required). I would also like the application to have patch-able byte-code, so it's in parts, loaded when needed and only part needs to be replaced on update.
What I would do now is following:
->Compile PHP with extensions for specific platform.
->Make binary application which launches '/full/php app' when app is launched.
->Pack it in installer in a way, that there would be binary added to path when added, launching specific installation of PHP which is alongside the app with argument of start point->App would be running.
Problem is:
Maybe I don't want my PHP files to be exposed(in application, there will be available source anyway) is there some ready made stuff to do this? Is there some better way than I proposed?
Alternative: Modifying OP Cache to work with "packing" application to deliver byte codes to modified OP Cache which just reads the cache.
My suggestion would be a tiny tool I just finished, for almost exactly the same problem. (Oh yes I tried all the others but they're old and rusty, sometimes they're stuck with 4.x syntax, have no support, have no proper documentation, etc)
So here's RapidEXE:
http://deneskellner.com/sw/rapidexe
In the classical way, it's not a really-real compiler, just a glorified packer, but does exactly what you need: the output exe will be standalone, carrying everything with it and transparently building an ad-hoc runtime environment. Don't worry, it all happens very fast.
It uses PHP 7.2 / Win64 by default but has 5.x too, for XP compatibility.
It's freeware, obviously. (MIT License.)
(Just telling this because I don't want anyone to think I'm advertising or something. I just took a few minutes to read the guidelines about own-product answers and I'm trying to stay within the Code of the Jedi here.)
However...
I would also like the application to have patch-able byte-code, so it's in parts, loaded when needed and only part needs to be replaced on update.
It's easier to recompile the exe. You can extract the payload pieces of course but the source pack is one big zip; there seems to be no real advantage of handling it separately. Recompiling a project is just one command.
Maybe I don't want my PHP files to be exposed(in application, there will be available source anyway)
In this case, the exe contains your source compressed but eventually they get extracted into a temp folder. They're deleted immediately after run but, well, this is no protection whatsoever. Obfuscation seems to be the only viable option.
If something goes wrong, feel free to comment or drop me a line on developer-at-deneskellner-dot-com. (I mean, I just finished it, it's brand new, it may misbehave so consider it something like a beta for now.)
Happy compiling!
PHP doesn't do that natively, but here are a few ideas:
Self-extracting archive
Many archival programs allow you to create a self-extracting archive and some even allow to run a program after extraction. Configure it so that it extracts php.exe and all your code to a temp folder and then runs ir from there; deleting after the script has complete.
Transpilers/compilers
There's the old HPHC which translates PHP code to C++, and its wikipedia age also contains links to other, similar projects. Perhaps you can take advantage of those.
Modified PHP
PHP itself is opensource. You should be able to modify it withot too much difficulty to take the source code from another location, like some resource compiled directly inside the php.exe.
Use Zend Guard tool that compiles and converts the plain-text PHP scripts into a platform-independent binary format known as a 'Zend Intermediate Code' file. These encoded binary files can then be distributed instead of the plain text PHP. Zend Guard loaders are available for Windows and Linux platform that enables PHP to run the scripts encoded by Zend Guard.
Refer to http://www.zend.com/en/products/zend-guard
I would like to add another answer for anyone who might be Googling for answers.
Peach Pie compiler/runtime
There is an alternative method to run (and build apps from) .php source codes, without using the standard php.exe runtime. The solution is based on C#/.NET and is actually able to compile php source files to .NET bytecode.
This allows you to distribute your program without exposing its source code.
You can learn more about the project at:
https://www.peachpie.io/
You've got 3 overlapping questions.
1. Can I create a stand-alone executable from a PHP application?
Answered in this question. TL;DR: yes, but it's tricky, and many of the tools you might use are semi-abandoned.
2. Can I package my executable for distribution on client machines?
Yes, though it depends on how you answer question 1. If you use the .Net compiler, your options are different to the C++ option.
3. Can I protect my source code once I've created the application?
Again, depends on how you answer question 1. Many compilers include an "obfuscator" option which makes it hard to make sense of any information you get from decompiling the app. However, a determined attacker can probably get through that (this is why software piracy is possible).
Is there a way to dynamically find a user's cgi-bin path using PHP and write a file to it?
For instance, I want to write a PHP application that also uses a Perl script for additional functionality (will not break without it), and on first run I want to get the path for cgi-bin or whatever the user's directory is named, and write the script into the directory so that it can be invoked by the application, with minimal installation required by the user (i.e. upload application to a directory, then run index.php).
Is this possible? Or am I dreaming far beyond what I can actually do?
The simplest solution I see to this would be to use a regex to check for a directory named /cgi/ starting at the user's root directory, however, this doesn't seem like an entirely reliable method
__FILE__ gives you under both Perl and PHP the name of the currently executed file.
There is no sane way.
A server can be configured to execute CGI programs in zero, one or many different locations, none of which have to have "cgi" in the name.
You could try parsing the server configuration to identify which (if any) locations are set up that way, but you would have to write a separate parser for each server, and each one would be very complex. Even if you limit things to Apache, then you would have to deal with filtering based on virtual hosts, <file>, <directory>, <location>, ScriptAlias, .htaccess, etc.
I am developing (solo web developer) a rather large web based system which needs to run at various different locations. Unfortunately, due to some clients having dialup, we have had to do this and not have a central server for them all. Each client is part of our VPN, and those on dialup/ISDN get dialed on demand from our Cisco router. All clients are accessable within a matter of seconds.
I was wondering what the best way to release an update to all these clients at once would be. Automation would be great as their are 23+ locations to deploy the system to, each of which is used on a very regular basis. Because of this, when deploying, I need to display a 'updating' page so that the clients don't try access the system while the update is partially complete.
Any thoughts on what would be the best solution
EDIT: Found FileSyncTask which allows me to rsync with Phing. Going to use that.
There's also a case here for maintaining a "master" code repository (in SVN, CVS or maybe GIT). This isn't your standard "keep editions of your code in the repo and allow roll backs"... this repo holds your current production code (only). Once an update is ready you check the working updated code into the master repo. All of your servers check the repo on a scheduled bases to see if it's changed, downloading new code if a change is found. That check process could even include turning on the maintenance.php file (that symcbean suggested) before starting the repo download and removing the file once the download is complete.
At the company I work for, we work with huge web-based systems which are both Java and PHP. For all systems we have our development environments and production environments.
This company has over 200 developers, so I guess you can imagine the size of the products we develop.
What we have done is use ANT and RPM build archives for creating deployment packages. This is done quite easily. I haven't done this myself, but might be worth for you to look into.
Because we use Linux systems we can easily deploy RPM packages, the setup scripts within a RPM package can make sure everything gets to the correct place. Also you get a more proper version handling and release process.
Hope this helped you.
Br,
Paul
There's 2 parts to this, lets deal with the simple one first:
I need to display a 'updating' page
If you need to disable the entire site while maintaining transactional integrity, and publishing a message to the users from the server being updated, then the only practical way to do this is via an auto-prepend - this needs to be configured in advance (note - I believe this can be done using a .htaccess file without having to restart the webserver for a new PHP config):
<?php
if (file_exists($_SERVER['DOCUMENT_ROOT'] . '/maintenance.php')) {
include_once($_SERVER['DOCUMENT_ROOT'] . '/maintenance.php');
exit;
}
Then just drop maintenance.php into your webroot and that file will be displayed instead of the expected file. Note that it should probably include a session_start() and auto-refresh to ensure the session is not expired. You might want to extend the above to allow a grace period where POSTs will still be processed e.g. by adding a second php file.
In terms of deploying to remote sites, I'd recommend using rsync over ssh for copying content files - which should be invoked via a controlling script which:
Applies the lock file(s) as shown above
runs rsync to replicate files
runs any database deployment script
removes the lock file(s)
If each site has a different set up then I'd recommend either managing the site specific stuff via a hierarchy of include paths, or even maintaining a comlpete image of each site locally.
C.
I'm trying to make a web app that will manage my Mercurial repositories for me.
I want it so that when I tell it to load repository X:
Connect to a MySQL server and make sure X exists.
Check if the user is allowed to access the repository.
If above is true, get the location of X from a mysql server.
Run a hgweb cgi script (python) containing the path of the repository.
Here is the problem, I want to: take the hgweb script, modify it, and run it.
But I do not want to: take the hgweb script, modify it, write it to a file and redirect there.
I am using Apache to run the httpd process.
Ryan Ballantyne has the right answer posted (I upvoted it). The backtick operator is the way to execute a shell script.
The simplest solution is probably to modify the hgweb script so that it doesn't "contain" the path to the repository, per se. Instead, pass it as a command-line argument. This means you don't have to worry about modifying and writing the hgweb script anywhere. All you'd have to do is:
//do stuff to get location of repository from MySQL into variable $x
//run shell script
$res = `python hgweb.py $x`;
You can run shell scripts from within PHP. There are various ways to do it, and complications with some hosts not providing the proper permissions, all of which are well-documented on php.net. That said, the simplest way is to simply enclose your command in backticks. So, to unzip a file, I could say:
`unzip /path/to/file`
SO, if your python script is such that it can be run from a command-line environment (or you could modify it so to run), this would seem to be the preferred method.
As far as you question, no, you're not likely to get php to execute a modified script without writing it somewhere, whether that's a file on the disk, a virtual file mapped to ram, or something similar.
It sounds like you might be trying to pound a railroad spike with a twig. If you're to the point where you're filtering access based on user permissions stored in MySQL, have you looked at existing HG solutions to make sure there isn't something more applicable than hgweb? It's really built for doing exactly one thing well, and this is a fair bit beyond it's normal realm.
I might suggest looking into apache's native authentication as a more convenient method for controlling access to repositories, then just serve the repo without modifying the script.