I'm trying to build apache from source on debian. The only reason I'm not using spt-get install is because in the apache cookbook, they recommend installing from source.I get the following error when I ./configure:
configure: error: invalid variable name: ' --with-mpm'
I also saw some warnings when I ./buildconf Is this something I should be concerned about? This is my first attempt at compiling from source, and I'd really appreciate any help.
I'm using the ./configure arguments directly from the apache cookbook:
./configure --prefix=/usr/local/apache --with-layout=Apache --enable-modules=most --enable-mods-shared=all \ --with-mpm=prefork
I'm running a minimum debian install in virtual box to train myself for deploying in the rackspace cloud soon.
EDIT: I'm building Apache 2.2.16
I suspect you are typing that entire build line you provided on one line, complete with the '\' in the middle.
You should get rid of '\', which in bash either treats the following as part of the same string, but the slash has to immediately follow a non-whitespace character. It is also used for special escape sequences, which I think is the case here and generating that message.
This should be the correct line in your case.
./configure --prefix=/usr/local/apache --with-layout=Apache --enable-modules=most --enable-mods-shared=all --with-mpm=prefork
On a side note, doesn't the Apache Cookbook say that building from source is one possibility for installing it, in addition to installing from a pre-packaged build like you can get from Debian's repositories? I suppose if you really wanted a far newer build or a more repeatable process to ensure consistency across a variety of distributions, building from scratch will do that for you, but otherwise I would try to utilize the distribution's package management as much as possible. Building from source removes you from the security patches and ease-of-upgrade path that Debian APT gives you.
Related
I found this repo with a systemtap script for letting me use QWERTY ctrl-shortcuts on my dvorak layout. Unfortunately, I can't get it to work, but I don't think it has to do with the script itself. I'm running Pop OS and I think that it's because the linux-image I need with all the debug symbols doesn't exist.
The script says I need to install linux-headers-$(uname -r) linux-image-$(uname -r)-dbg
For me, this turns into linux-headers-5.11.0-7620-generic linux-image-5.11.0-7620-generic-dbg
linux-headers-5.11.0-7620-generic exists and I'm able to download it using apt-get.
linux-image-5.11.0-7620-generic-dbg can't be installed using apt-get. I can install
linux-image-5.11.0-7620-generic, but that's not the same thing. I've spent time looking online for it and adding different keys to apt-get, but I haven't been able to find anything with that name. If the problem is not having the correct linux-image package installed, I need help being pointed in the right direction as to where I can get it.
I tried following the directions here, and I've also searched this to no avail. I tried downloading and installing linux-image-4.4.0-142-generic-dbgsym_4.4.0-142.168_amd64.ddeb but that also didn't work.
If this isn't the problem, I've provided the output of the script. Any help is appreciated.
peyton#pop-os:~/scripts$ sudo stap -g -v dvorak-qwerty.stp
Pass 1: parsed user script and 477 library scripts using 116428virt/91336res/7612shr/83628data kb, in 140usr/30sys/168real ms.
semantic error: resolution failed in DWARF builder
semantic error: resolution failed in DWARF builder
semantic error: while resolving probe point: identifier 'module' at dvorak-qwerty.stp:152:7
source: probe module("evdev").function("evdev_events") {
^
semantic error: no match
semantic error: resolution failed in DWARF builder
Pass 2: analyzed script: 2 probes, 0 functions, 1 embed, 0 globals using 119016virt/94812res/8680shr/86216data kb, in 10usr/0sys/7real ms.
Pass 2: analysis failed. [man error::pass2]
Tip: /usr/share/doc/systemtap/README.Debian should help you get started.
Yes, debuginfo downloading has been a pain on many distros. However, if you're running Debian kernels, see: https://wiki.debian.org/Debuginfod for instructions on using a new automated system. Generally: https://sourceware.org/elfutils/Debuginfod.html .
I've posted this issue on the google groups area for mapnik already, so I'm just going to c/p from there:
I've been troubleshooting this issue for a couple days, now. Bear with me for context:
Starting from a freshly-untarred source of mapnik 2.2.0 on RHEL 6.5:
First off, running "./configure" (which just calls scons/scons.py) works great. Finishes correctly, then I run make + make install and I get exactly what I want built and installed.
My goal has been to create a mapnik 2.2.0 RPM for internal use. Please do not suggest using an "official" mapnik RPM instead (or any other already-built mapnik RPM), as my entire purpose here is to build mapnik from source and create my own RPM.
That being said, when my RPM gets to its %build phase and runs ./configure, it freezes while scons checks for freetype-config. I've let it sit for hours, and nothing happens.
After I looked at the generated config.log file, it would appear that configure is failing on an "awk" command that goes something like this:
awk '{print $\(NF-1\)}'
The command is performed on the string that results from the command:
/usr/bin/freetype-config --libs --cflags
I'm wondering, first of all, how to fix this, but second of all why this would work manually, but fail when the rpmbuild process gets to the ./configure command. I've made sure that the same user (myself) is running both ./configure commands on the exact same files.
My third question would be: why does the configure step freeze on this issue, instead of throwing some sort of error and stopping?
Note that the problem with the "awk" command is the backslashes--the error is:
awk: {print $\(NF-1\)}
^ backslash not last character on line
When I remove the backslashes, the command succeeds. Whether or not removing the backslashes is the correct thing to do in the long run, I do not know.
It would seem this is some sort of python string-parsing / encoding issue, but I'm unsure. What really confuses me is why this works manually and fails when the rpmbuild tries to do it.
My only thought is that there's some difference between the rpmbuild environment and my shell that I configured on. What it is, I do not know.
Thank you for any assistance you can provide. If I can provide any more context, please let me know.
UPDATE: an svn command runs after the awk failure, but is missing whatever number gets passed after the -r option. I'm wondering if this could be causing the hang...thoughts?
I'm having a hell of a time deploying matplotlib on AWS Elastic Beanstalk. I gather that my issue comes from some dependencies and the way that EB deploys packages installed with PIP, and have attempted to follow the instructions here on SO for resolving the issue.
I first tried incrementally deploying, as suggested in the linked answer, by adding pieces of the matplotlib package stack to my requirements.txt file in stages. But this takes forever (for each stage) and is prone to failure and timing out (which seems to leave build directories behind that stall subsequent package installations).
So the simple solution mentioned off-handedly at the end of the answer appeals to me: just eb ssh, activate the virtialenv with
source /opt/python/run/venv/bin/activate
and pip install packages manually. But I can't get this to work either. First I'm often confronted with left-beind build directories (as mentioned above)
pip can't proceed with requirement 'xxxx' due to a pre-existing build directory.
location: /opt/python/run/venv/build/xxxx
This is likely due to a previous installation that failed.
pip is being responsible and not assuming it can delete this.
Please delete it and try again.
But even after removing these, I consistently get
Exception:
Traceback (most recent call last):
File "/opt/python/run/venv/lib/python2.7/site-packages/pip/basecommand.py", line 122, in main
status = self.run(options, args)
File "/opt/python/run/venv/lib/python2.7/site-packages/pip/commands/install.py", line 278, in run
requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
File "/opt/python/run/venv/lib/python2.7/site-packages/pip/req.py", line 1197, in prepare_files
do_download,
File "/opt/python/run/venv/lib/python2.7/site-packages/pip/req.py", line 1375, in unpack_url
self.session,
File "/opt/python/run/venv/lib/python2.7/site-packages/pip/download.py", line 582, in unpack_http_url
unpack_file(temp_location, location, content_type, link)
File "/opt/python/run/venv/lib/python2.7/site-packages/pip/util.py", line 625, in unpack_file
untar_file(filename, location)
File "/opt/python/run/venv/lib/python2.7/site-packages/pip/util.py", line 533, in untar_file
os.makedirs(location)
File "/opt/python/run/venv/lib64/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/opt/python/run/venv/build/xxxx'
in response to pip install xxxx (and sudo pip fails with sudo: pip: command not found).
What can I do to get this working on AWS-EB? In particular, what do I need to do to get the simple SSH+PIP approach working; or is there some other better — simpler! — approach I should try.
FWIW, I have a .ebextensions/software.config with
packages:
yum:
gcc-c++: []
gcc-gfortran: []
python-devel: []
atlas-sse3-devel: []
lapack-devel: []
libpng-devel: []
freetype-devel: []
zlib-devel: []
and a requirements.txt that ends with
pytz==2014.10
pyparsing==2.0.3
python-dateutil==2.4.0
nose==1.3.4
six>=1.8.0
mock==1.0.1
numpy==1.9.1
matplotlib==1.4.2
After about 4 hours, I've gotten far as numpy (as reported by pip list in the EB virtualenv).
And (in case it matters) the user who is SSHing is part in a group with the policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticbeanstalk:*",
"ec2:*",
"elasticloadbalancing:*",
"autoscaling:*",
"cloudwatch:*",
"s3:*",
"sns:*",
"cloudformation:*",
"rds:*",
"sqs:*",
"iam:PassRole"
],
"Resource": "*"
}
]
}
I have used many approaches to build and deploy numpy/scipy/matplotlib, on Windows as well as Linux systems. I have used system-provided package managers (aptitude, rpm), 3rd-party package managers (pypm), Python package managers (easy_install, pip), source releases, used different build environments/tools (GCC, but also Intel MKL, OpenMP). While doing so, I have run into many many quite annoying situations, but have also learned a lot about the pros and cons of each approach.
I have no experience with Elastic Beanstalk (EB), but I have experience with EC2. I see that you can SSH into an instance and poke around. So, what I suggest further below is based on
above-stated experiences and on
the more or less obvious boundary conditions regarding Beanstalk and on
your application scenario, described in another question here on SO and on
the fact that you just want to get things running, quickly
My suggestion: start off with not building these things yourself. Do not use pip. If possible, try to use the package manager of the Linux distribution in place and let it handle the installation of everything required for you, with a single command (e.g. sudo apt-get install python-matplotlib).
Disadvantages:
possibly old package versions, depending on the Linux distro in use
non-optimized builds (e.g. not built against e.g. Intel MKL or not leveraging OpenMP features or not using special instruction sets)
Advantages:
it quickly downloads, because packages are most likely cached near your machine
it quickly installs (these packages are pre-built, no compilation involved)
it just works
So, I hope you can just use aptitude or rpm or whatever on these machines and inherit the great work that the distribution package maintainers do for you, behind the scenes.
Once you are confident in your application and identified some bottleneck or issue, you might have reason to use a newer version of numpy/matplotlib/... or you might have reason to have a faster version of these, by creating an optimized build.
Edit: EB-related details of outlined approach
In the meantime we have learned that EB by default runs Amazon Linux which is based on Red Hat Enterprise Linux. Likewise, it uses yum as package manager and packages are in RPM format.
Amazon provides documentation about available packages. In Amazon Linux 2014.09, these packages are available: http://aws.amazon.com/de/amazon-linux-ami/2014.09-packages/
In this list we find
numpy-1.7.2
python-matplotlib-0.99.1.2
This version of matplotlib is very old, according to the changelog it is from September 2009: "2009-09-21 Tagged for release 0.99.1".
I did not anticipate it to be so old, but still, it might be sufficient for your needs. So we proceed with our plan (but I'd understand if that's a blocker).
Now, we have learned that system Python and EB Python are isolated from each other. That does not mean that EB Python cannot access system Python site packages. We just need it to tell so. A simple and clean method is to set up a proper directory structure with the packages that should be accessible to EB Python, and to communicate this directory to EB Python via sys.path.
Clearly, we need to customize the bootstrapping phase of EB containers. The available tools are documented here: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html
Obviously, we want to make use of the packages approach, and tell EB to install the numpy and python-matplotlib packages via yum. So the corresponding config file section should contain:
packages:
yum:
numpy: []
python-matplotlib: []
Explicitly mentioning numpy might not be necessary, it likely is a dependency of python-matplotlib.
Also, we need to make use of the commands section:
You can use the commands key to execute commands on the EC2 instance.
The commands are processed in alphabetical order by name, and they run
before the application and web server are set up and the application
version file is extracted.
The following three commands create above-mentioned directory, and set up symbolic links to the numpy/mpl installation paths (these paths hopefully are available in the moment these commands become executed):
commands:
00-create-dir:
command: "mkdir -p /opt/py26-selected-site-packages"
01-link-numpy:
command: "ln -s /usr/lib64/python2.6/site-packages/numpy /opt/py26-selected-site-packages/numpy"
02-link-mpl:
command: "ln -s /usr/lib64/python2.6/site-packages/matplotlib /opt/py26-selected-site-packages/matplotlib"
Two uncertainties: the AWS docs to not clarify that packages are processed before commands are executed. You have to try. It it does not work, use container_commands. Secondly, it is just an educated guess that /usr/lib64/python2.6/site-packages/matplotlib is available after installing python-matplotlib. It should be installed to this place, but it may end up somewhere else. Needs to be tested. Numpy should end up where specified as inferred from this article.
[UPDATE FROM SEB]
AWS documentation says "The cfn-init helper script processes these configuration sections in the following order: packages, groups, users, sources, files, commands, and then services."
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html
So, your approach is safe
[/UPDATE]
The crucial step, as pointed out in the comments to this answer, is to tell your Python app where to look for packages. Direct modification of sys.path before attempting to import is a reliable method to take control of this. The following code adds our special directory to the selection of directories in which Python looks out for packages, and then attempts to import matplotlib:
sys.path.append("/opt/py26-selected-site-packages")
from matplotlib import pyplot
The order in sys.path defines priorities, so in case there is any other matplotlib or numpy package available in one of the other directories, it might be a better idea to
sys.path.insert(0, "/opt/py26-selected-site-packages")
However, this should not be necessary if our whole approach was well thought-through.
To add to Jan-Philip Answer :
AWS Elastic Beanstalk is using Amazon Linux distribution (except for .Net environments). Amazon Linux uses the yum package manager. MatPlotLib is available in Amazon's software repository.
[ec2-user#ip-1-1-1-174 ~]$ yum list | grep matplot
python-matplotlib.x86_64 0.99.1.2-1.6.amzn1 amzn-main
If this version is the one you need for your application, I would try to simply modify your .ebextensions/software.config file and to add the package to the yum section of it:
packages:
yum:
python-matplotlib: []
python-devel: []
atlas-sse3-devel: []
lapack-devel: []
libpng-devel: []
freetype-devel: []
zlib-devel: []
A last note about AWS Elastic BeansTalk and SSH.
While Amazon gives you the possibility to SSH to your Elastic Beanstalk instances, you should use this possibility only for debugging purposes, to understand why your app failed or is not installing as suggested.
Other than that, your deployment must be 100% automatic. When Elastic Beanstalk (Auto Scaling to be precise) will scale out your infrastructure (add more instances) or scale it in (terminate instances) depending on your application workload, all your manual configuration will be lost.
Best practices is to not install SSH keys on your production environment, it further reduces the surface of attacks.
I might be a bit late to this question, but as AWS and a lot of the cloud service providers are moving into Docker and taking into consideration that you haven't specified the platform . I have a fast solution to your question:
Use the generic docker platform.
I created some images with Python, Numpy, Scipy and Matplotlib preinstalled, so you can directly pull and start using them with one line of code.
Python 2.7(This one also has the versions that you were specifying for numpy and matplotlib)
sudo docker pull chuseuiti/pynuscimat2.7
Python 3.4
sudo docker pull chuseuiti/pynusci
However you can create your own image or modify existing images.
In case you want to automate your instances, you can pass a Dockerfile to AWS with the definition of your image.
Tip, in case you don't know about docker:
It is need to login before been able to pull:
sudo docker login
After pulling the image, you can generate and work in a container created from an image with the next code:
sudo docker run -i -t chuseuiti/pynuscimat2.7 bash
PS. At least with the free tier AWS is always complaining about running out of time with scipy and matplotlib, it takes too much time to install them, that is why I use this option.
I have a basic Ubuntu server setup and I am attempting to run a CGI script on it but receiving the following error whenever I try running the script via the command line:
CGI will be removed from the Perl core distribution in the next major release. Please install the separate libcgi-pm-perl package. It is being used at /etc/perl/RABX.pm, line 583.
CGI::Util will be removed from the Perl core distribution in the next major release. Please install the separate libcgi-pm-perl package. It is being used at /usr/share/perl/5.20/CGI.pm, line 29.
Status: 400 Bad Request
Content-Type: application/octet-stream
Content-Length: 98
E1:0,3:513,82:No REQUEST_METHOD in environment; this script must be run in a CGI/FastCGI context,N
If I attempt to run the script in the browser I just get a 500 Internal Server Error.
I'm cautious about installing the libcgi-pm-perl package as the CGI script is part of a much larger legacy application that I'm worried will be incompatible with newer packages. I have no idea if this is a real error or more of a warning though.
The bit that really confuses me is the last line. Any advice would be greatly appreciated!
The full script can be seen here: https://github.com/mysociety/writetothem/blob/master/web/services/queue.cgi
Also, apologies if this question is better suited to ServerFault - I wasn't sure where was more appropriate.
whenever I try running the script via the command line
...
this script must be run in a CGI/FastCGI context
You get the error "No REQUEST_METHOD in environment" because you are not running within a CGI context but instead on the command line.
Please install the separate libcgi-pm-perl package
I'm cautious about installing the libcgi-pm-perl package as the CGI script is part of a much larger legacy application that I'm worried will be incompatible with newer packages. I have no idea if this is a real error or more of a warning though.
This is a warning, that you better install libcgi-pm-perl, because CGI.pm will not be included in core perl in the future. The CGI.pm in this package is the same as it was in core perl, so you don't need to worry about having a different module. Of course, it is probably a newer version than you used before. But this was also the case in the past when you used a new perl version.
php -v gives this
PHP Warning: PHP Startup: memcache: Unable to initialize module
Module compiled with module API=20060613
PHP compiled with module API=20090626
These options need to match in Unknown on line 0
PHP Warning: PHP Startup: memcache: Unable to initialize module
Module compiled with module API=20060613
PHP compiled with module API=20090626
These options need to match in Unknown on line 0
bogus test name tests/
ps. i've upgraded from php 5.2 to 5.3. before this everything worked okay.
When you update the version of PHP (especially when going from version X.Y to version X.Z), you must update the PHP extensions as well.
This is because PHP extensions are developped in C, and are "close" to the internals of PHP -- which means that, if the APIs of those internals change, the extension must be re-compiled, to use the new versions.
And, between PHP 5.2 and PHP 5.3, for what I remember, there have been some modifications in the internal data-structures used by the PHP engine -- which means extensions must be re-compiled, in order to match that new version of those data-structures.
How to update your PHP extensions will depend on which system you are using.
If you are on windows, you can find the .dll for some extensions here : http://downloads.php.net/pierre/
For more informations about the different versions, you can take a look at what's said on the left-sidebar of windows.php.net.
If you are on Linux, you must either :
Check what your distribution provides
Or use the pecl command, to re-download the sources of the extensions in question, and re-compile them.
just
pecl uninstall module_name
then
pecl install module_name
Your problem is within the php5-dev package. I guess you went from php5.2 on an older linux version to php5.3. I did the same thing, and when I managed to install php 5.3 there was a conflict with php5-dev. For some reason it doesn't get upgraded to the new version. Dunno why is that and I don't care, however this makes your extension compiled with the older API version, while php ofc is with the newer api version. What I did to solve this problem was:
I removed php5-dev with
sudo apt-get remove php5-dev, then I ran sudo apt-get autoremove to get rid of the leftovers that were giving me the trouble, and after that I just installed php5-dev again.
sudo apt-get install php5-dev.
Once that was done, I removed my memcache with sudo pecl uninstall memcache and installed it again sudo pecl install memcache. Now both the module and the php had the same api version so I knew right away that I had the issue solved :)
Hope it helps.
It's possible that the modules are installed, but your PHP.ini still points to an old directory.
Check the contents of /usr/lib/php/extensions. In mine, there were two directories: no-debug-non-zts-20060613 and no-debug-non-zts-20060613. Around line 428 of your php.ini, change:
extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613"
to
extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20090626"
Then restart apache. This should resolve the issue.
I struggled with this issue for a long time and found out that when you run configure, just pass it the path to the correct php-config tool.
In my case, it was
./configure --with-php-config=/usr/local/zend/bin/php-config
... If you're unsure, run a locate php-config on your machine and find the right one amongst the different versions installed.
Hope this helps somebody in the future.
PS. My default php-config was set to 20090926 which is PHP 5.3. The one I manually entered as a param for ./configure was for PHP 5.4 (2010...)
I had this part enabled in my php.ini
extension=php_memcache.dll
[Memcache]
memcache.allow_failover = 1
memcache.max_failover_attempts=20
memcache.chunk_size =8192
memcache.default_port = 11211
After commenting these lines composer was installed in my windows 10
I had a similar issue after upgrading from PHP 5.5 to PHP 5.6. The phpize and php-config libraries being used to compile the phalcon extension were still the ones from PHP 5.5. I had to run the command below:
sudo apt-get install php5.6-dev
There will be a long stacktrace, the key information I saw was this:
update-alternatives: using /usr/bin/php-config5.6 to provide /usr/bin/php-config (php-config) in auto mode
update-alternatives: using /usr/bin/phpize5.6 to provide /usr/bin/phpize (phpize) in auto mode
I hope this helps someone.
Before you phpize, make sure to update your path ($PS1) to point to the new PHP! phpize uses your environment, and if you still have vestiges of your old PHP in your path or other parts of the environment, things will get hairy!
I'd the same error even after recompiling the modules.
But I solved it you just have to specify the absolute path of your phpize.
Here is the one that works with php 5.5. Download xampp 1.8.3 from here and download memcache dll from here
In my case in php.ini
[CLDbg]
extension=php_cl_dbg_5_3_VC9.dll
clport=6000
I removed Codelobster which support different PHP version, so need to update to:
[CLDbg]
;extension=php_cl_dbg_5_3_VC9.dll
;clport=6000
This problem has just happened to me and has been solved simply by increasing
memory_limit from 32 M to 64 M
You can adjust the value on the file where php.ini exists
locate php.ini
then choose the right file and search for memory_limit and after modifying it
you must reboot the apache
/etc/init.d/httpd restart
All the best.
In my case, I used lnmp to install php with version 5.4.45. But maybe because I installed php5-dev after lnmp (which I guess is not necessary if you installed lnmp), my phpize and php-config both point to older version tools than php.
I solved this by change the soft link of /etc/alternatives/phpize and /etc/alternatives/php-config to /usr/local/php/bin/phpize and /usr/local/php/bin/php-config.
Hopes this is helpful.
What worked for me was simply to do the following:
open the php.ini file.
Under the DYNAMIC EXTENSIONS heading, comment out the following line as
;extension=php_java.dll
Restarted Apache and all was fine