Can i (for example) use mod_proxy of version 2.2.10 with an otherwise unchanged 2.2.8 apache distribution under windows?
I think the Apache module ABI is stable across the 2.2 releases, but I wouldn't swear to it. What happens if you try?
Related
I've got a machine running an unsupported OS (rhel6.3). It no longer has access to current repos, and cannot be updated for budget reasons.
It needs to have tzdata updated, but the only version it has access to is from 2014.
tzdata is a noarch package - it's just a bunch of binary files - so it doesn't matter if I grab it from another repo, say, our local yum repo which has the latest tzdata packages for other OSs, like centos7.
I know I can simply download and put the latest tzdata rpm locally on the rhel machine, but I'd like this process to be automated - as in, Puppet checks that tzdata is the latest version - and not have to manually go put it in place whenever the tzdata is updated.
Is it possible for Puppet to specify, use this repo, but use the rpm specified for another OS?
tzdata is a noarch package - it's just a bunch of binary files - so it doesn't matter if I grab it from another repo, say, our local yum repo which has the latest tzdata packages for other OSs, like centos7.
Being a noarch package has no such implication. "Noarch" packages are independent of machine architecture, but not necessarily of OS version. For example, many Python packages are noarch, but the Python2 in EL6 is version 2.6, whereas the Python2 in EL7 is version 2.7. Noarch Python packages for EL7 do not work properly on EL6 if they rely on any of the features introduced in Python 2.7. If they are well packaged then such packages won't even install on EL6.
I suspect you're ok with tzdata in particular, but there is always a possibility that there has been a change or addition to the format of the packaged files that renders them unusable on older OS versions. You should be pretty safe, however, if you go with the CentOS 6.7 package for your EL6.3 system, rather than any EL7 package.
Is it possible for Puppet to specify, use this repo, but use the rpm specified for another OS?
Packages in the same Yum repo are not distinguished by OS or OS version. Where and to the extent that different OS flavors or versions must be served different package collections, it is done by giving them altogether different repos. So no, there is no way to instruct Puppet specifically as you describe, because there is no way to instruct yum that way.
On the other hand, if you have a local repo that is enabled on the target machine, then you can indeed drop a package built for some other RPM-based distro [version] into that repo. Clients will see it, and will (attempt to) use it where appropriate based on its name and epoch-version-release codes. You don't need to do anything special to make that happen.
On the third hand, you could also consider getting the source RPM for the version of tzdata you want, building the binary RPM from it on your EL6.3 machine, and dropping that in your local repo. You can get all manner of source (and binary) RPMs for Fedora and RHEL from Koji.
I'm trying to find cassandra instalation guide and all I've found is installing guide of apache-cassandra-0.6.6 version, I have the latest apache cassandra 2.0.2 version binary files and doesn't include some of the included config files which previous version had. so please can you tell me how to install apache cassandra 2.0.2?
I would recommend you to install DataStax Community edition. Currently DataStax distributes and supports Cassandra. You can find all Cassandra documentation Here
To install DataStax Community edition on various platform (such as - RHEL, Debian, Ubuntu, CentOS, Mac X, Windows, any Linux distribution etc.), use THIS link.
I've compiled a C program under Ubuntu 12.04, built a Debian package out of it, and want to install it on a server running Debian Lenny.
Last time I did that (about two months ago) it worked: I could install the package and run the binary. But now I get the following error message:
(binary's name): /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by (binary's name))
Other than upgrading my machine to Ubuntu 12.4, the only significant change we've brought to the code is a call to strdup(), for which I had to enable the _POSIX_C_SOURCE=200809L feature test macro.
Upgrading the server to the latest Debian version is not my preferred option as it is not under my direct control.
How do I fix this problem?
I think the critical bit of info here is 'upgrading my machine'. So when this worked before, you were building and packaging on something earlier than 12.04? If so, then the issue is that 12.04 now ships with a newer version of libc (apparently 2.14), and your binary now records a dependency on that version of libc. When you try to run on Lenny, which likely uses an older version of libc, the linker detects that the Lenny version does not support the 2.14 API, and fails.
I think the best way forward is probably to do your development and testing on 12.04, and then when you want to create packages for a specific Debian release, use pbuilder or similar to create debs. This will ensure that the libraries used for the packaging build match the target platform.
Sorry I know this is stupid but where is linux libc source code available? What I downloaded from GNU didn't seem to be what I wanted, specifically I could find nothing in the pthreads function family.
Is there an online (hypertexted cross-referenced) version somewhere?
Most linuxes use a libc version named glibc.
The LXR (online cross-reference system) for glibc is e.g. here http://koala.cs.pub.ro/lxr/glibc/ for 2.9 version (link is broken). I must say that something may be not lxr'ed because some sources are generated in the build process, for example - as i can remember - wrappers around a system calls.
Pthreads are in nptl/ folder. Right link to libc sources is http://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.bz2 (or change 2.14 to your version)
Update: After closing of koala's lxr, there are:
Metager with glibc: http://code.metager.de/source/xref/gnu/glibc/ (Served with Sun's OpenGrok, which was originally used to generate online x-ref for Solaris/OpenSolaris)
Google code search (I know that it was closed; but I also know it's other version which is up): http://code.google.com/codesearch and try to search something glibc-specific
UPD (march 2013) They killed codesearch again:
404. That’s an error.
The requested URL /codesearch was not found on this server. That’s all we know.
UPD 2017
Metager with glibc: http://code.metager.de/source/xref/gnu/glibc/
There is online git by glibc authors: https://sourceware.org/git/?p=glibc.git (tree is browserable at https://sourceware.org/git/?p=glibc.git;a=tree)
Glibc git is mirrored to github (which has some searching functions) https://github.com/bminor/glibc Buildroot 2018.05 notably uses this mirror.
There is search like google's codesearch in all debian packages: https://codesearch.debian.net/. It can search in glibc sources by "package:glibc request" request and also have file browser: http://sources.debian.net/src/glibc/
Info on the glibc repository: http://sourceware.org/glibc/wiki/GlibcGit
Clone it to get your own copy and search it however you like:
git clone git://sourceware.org/git/glibc.git
I load it up in an IDE project (using whatever preferred IDE) and the code navigation works quite well to let me find what I'm interested in.
Browse the source online http://sourceware.org/git/?p=glibc.git
If you're on a Debian-derived system, you can use apt-get source libc6. This will unpack a eglibc-2.12.1 directory (version number might differ, of course) in your current working directory, and the pthreads support are in the nptl/ directory below that. linuxthreads/ is for the older threading style, in case you're an archaeologist.
Try the FreeBSD and Linux Kernel Cross-Reference.
Have fun :)
I'm trying to install the mod_xsendfile Apache Module on Windows (7) x64 (using Apache 2.2) -- yes I'm doomed from the get-go, I know :-). Apparently there is :
a) No Win x64 binary for mod_xsendfile, just a Win32 binary from the module's website
b) No Win x64 binary for apxs from ApacheLounge
I've tried the usual LoadModule xsendfile_module modules/mod_xsendfile.so but the semi-obvious error (httpd: Syntax error on line 127 of C:/Apache/conf/httpd.conf: Cannot load C:/Apache/modules/mod_xsendfile.so into
server: The specified module could not be found.) occurs, it's not Win x64 compatible.
The question remains -- how does one build the module for x64, is that even possible ? I have VS and any tools that might be required.
I just wanted to see if this would improve my Rails protected attachment download speed - currently getting quite ghastly speeds for simple images.
Thank you in advance !
I'm the author of mod_xsendfile.
I provide win32 binaries only as a courtesy. I still recommend you build yourself from the source. That way you can be sure the binary isn't tampered with, not even by me :p
There are currently no official Win64 Apache2 (or 2.2) builds from the Apache Foundation. Since I test my builds against the official binaries I cannot be sure the binaries will work once the foundation releases official Win64 binaries. Hence no Win64 builds from me
Building from the source is pretty much straight-forward if you aren't novice to (in the Windows case) Visual Studio. The binaries ZIP and/or my github repo contain project files you may import into your Apache solution. I was told even the free Visual Studio Express should be enough to do working builds. The thing is open source.
Should there be unanticipated portability problems, I welcome patches ;)
As a last resort you can still run the official Win32 apache + mod_xsendfile on a Win64 box.
I was able to load mod_xsendfile in my system.
Here's my setup:
-Windows 7 Ultimate x64
-Apache/2.2.9 (installed via Xampp 1.6.7)
Basically, I just downloaded the module from here:
http://www.apachelounge.com/download/mods/mod_xsendfile-0.9-w32.zip
...extracted it to the "modules" directory of apache, added "LoadModule xsendfile_module modules/mod_xsendfile.so" to httpd.conf, then restarted apache.
After this, I checked the loaded modules using phpinfo(), and mod_xsendfile is already available.
Here are the binaries for both x32 and x64
https://github.com/nmaier/mod_xsendfile