I wrote a WSGI script that depends on importing files in the same directory. Does WSGI use paths differently? Could my (mod_wsgi apachae) server be insane?
The current working directory for a WSGI server could be anything and for different WSGI servers could be different. Further, command line Python interpreter will by default look in the current working directory where as for an embedded system it will not.
End result is that relying on being able to import modules from the same directory as a WSGI script file is not portable. You will need to set sys.path or PYTHONPATH as appropriate for the WSGI server being used to ensure that modules from a specific location can be imported. You cannot rely on a default of looking in the current working directory as may occur for command line Python.
Related
I have found that:
When I type the following on terminal:
php -i | grep php.ini
I get the output:
The Loaded Configuration file is # /etc/php5/cli/php.ini
However, from phpinfo(), I get to see:
The loaded ini file is # /etc/php5/apache2/php.ini
Which one of these is working right now? How is it possible to have two php.ini files ?
Depends on where you are running PHP from. If you run it from command line, it uses the cli/php.ini and apache2/php.ini when run through apache.
You are executing phpinfo() through the browser, hence you get /etc/php5/apache2/php.ini as the answer. Running php -r "phpinfo();" | grep "Loaded Configuration" from the terminal should output the CLI ini. Same function, context changes.
The advantage of this system is obviously to allow different configurations depending on the context. For a simplified example, you might want to have safe_mode on in apache but it's unnecessary in CLI mode.
Your .ini paths are actually quite unusual. Normally, the default .ini is just php.ini and CLI .ini is called php-cli.ini and they reside in the same folder.
I'm no expert on the subject but this should be the basic idea. If anyone has any corrections, I'd be happy to hear them.
This is kind of embarassing because of how simple and common this problem is but I feel I've checked everything.
WSGI file is located at: /var/www/igfakes/server.wsgi
Apache is complaining that I can't import the module of my project, so I decided to start up a Python shell and see if it's any different - nope.
All the proof is in the following screenshot, I'll walk you through it.
First, see I cannot import my project
Then I import sys and check the path
Note /var/www in the path
Leave python
Check the directory, then confirm my project is in that same directory
My project is exactly where I'm specifying. Any idea what's going on?
I've followed a few different tutorials, all with the same instructions, like this one.
Linux Driver question.
I have an application effectively calling into my kernel module.
The kernel module has to read files from a specific absolute path, during the call from the application.
This all works fine under normal conditions.
The problem occurs when the application is being run from a chroot.
At that point, running within the context of the application that is running from chroot, my driver no longer has access to the absolute path for the file it must read.
The driver is using filp_open() to open the file, which fails when application is running from chroot.
Is there way for me to specify the root for my file opens to use without disturbing the application's chroot, or causing races with the application accessing other files within the chroot.
The Linux version is centos 7.1 kernel 3.10.0-229-el7.x86_64
Any info greatly appreciated.
This took a lot of crawling around through the kernel code, but I figured out how to this.
First I needed to use get_fs_root(init_task.fs, &realrootpath)
This gets the real root path, not the chroot path.
Then I needed to lookup the file name using filename_lookup() setting namei data to my rootpath and passing in the LOOKUP_ROOT flag so it looks it up from the real root path.
Finally I had to use dentry_open() to open the file using the path I looked up.
At this point I could access and read a file that outside the current tasks chroot environment.
Using a .user.ini file with extension=geoip.so (or mysqli.so) I'm trying unsuccessfully to load the relevant module: in the phpinfo() page of Php 7.1 (or even Php5.4) the module is never shown.
1) The .user.ini file is working correctly because I'm able to modify the variable memory_limit.
2) The phpinfo() function correctly shows the extension_dir folder containing .so extensions that I want to load (in the php.ini file this variable is not present, however).
3) The php error log contains no message.
Every suggestion is welcome.
The .user.ini files can only set certain PHP ini settings. It just so happens that the extension setting is not one of them. In fact, according to the manual, the extension setting is only valid in the core php.ini file. So put the extension=geoip.so in your main php.ini file.
As a side note: I use Ubuntu/Debian for most of what I do with PHP. The standard PHP distro that is available through the Debian package archives has extra code compiled into it that allows for a distributed configuration. The way this works is the SAPI module scans a conf.d directory and includes any ini files. Typically when you package an external PHP extension for Debian (which I might add is a pain - I've done it for my own extensions) you include a little ini file that includes the extension (e.g. extension=myext.so). The package installs it in the distributed config directory and it is included into the php.ini file when PHP spins up. Perhaps you meant to install a Debian-based config like this?
Another side note: Since you are probably using a CGI SAPI and might want different sites to load different modules (exclusively), you could perhaps look into getting the Web server to point the CGI PHP at a different php.ini file. I'm just presuming you want to achieve something like this. However loading modules for certain directories using .user.ini files is just not possible.
Try disable or configure selinux. Check selinux audit log.
I recently modify the "include_path" var in my php.ini file. Before you ask, I restarted the apache service. The change work for every pages we access from a web browser.
The problem is the cron jobs doesn't seems to consider that change. When I do a phpinfo() inside the cron job, it uses the same php.ini file than the web server and it is the one I changed, but the value beside "include_path" is the old one.
So is there a way to "restart" crontab?
Or maybe there is another problem?
Several systems use a separate php.ini file for web and CLI. You will need to make changes in that one as well: How to find the php.ini file used by the command line?
The easiest way to find this file is to run this at the command line: php --ini which will result in output like this:
user#computer:~$ php --ini
Configuration File (php.ini) Path: /etc/php5/cli
Loaded Configuration File: /etc/php5/cli/php.ini
Scan for additional .ini files in: /etc/php5/cli/conf.d
What you see as "Loaded Configuration File:" is where you need to add your changes.
EDIT: Another option, is in your CRON script use set_include_path() to make the change at runtime.
PHP generally has two .ini files. One for in-webserver (SAPI) and one for command-line (CLI) usage. If you modified only the SAPI one, then anything running from CLI (e.g. cron jobs) will not see the change.
do a php -i at the command line to see where PHP is looking for its ini file while in that mode.