I installed GitLab 6.6.5 via the omnibus package on Ubuntu 12.04 LTE. My question is will the Ubuntu OpenSSL heartbleed update cover the GitLab's installation? The installation has an embedded nginx that is installed. I have enabled SSL via the GitLab Omnibus Merge Request #66.
Having an embedded NGinX doesn't mean it won't use the /usr/bin/openssl installed on your system. (for instance, the ngx_http_ssl_module does require openssl)
If that openssl is 1.0.1g or 1.0.2, you won't have any issue.
openssl version
If not, it is easy enough to recompile it and install it.
To be sure, you can type:
ldd /path/to/nginx
That will give you the path of the openssl used by the binary nginx.
To get the full path, you can then use
readlink -f /path/to/libssl.so.1.0.0
Bruno adds in the comments:
It's probably more about /lib/*/libssl.so.1.0.0 than /usr/bin/openssl (which ldd should indicate indeed).
In principle, upgrading to the package with the fix and restarting NGinX should fix the issue.
Also note that the version numbers in distribution packages (e.g. Ubuntu) don't necessarily match the official version numbers exactly, because they tend to keep the same version number (for the same features), but backport the security patches
The OP crushedGrass points out in the comments Jacob Vosmaer (jacobvosmaer)'s commit "Update omnibus-software (CVE-2014-0160)", in omnibus-gitlab
so all I had to do was run a reconfiguration.
I believe both your and Bruno's feedback is spot on, there are just more dependencies that have to match up.
GitLab uses Chef cookbooks to configure the setup and I definitely do not know enough about it to modify it downstream.
Just so it is clear:
-> # ldd /opt/gitlab/embedded/sbin/nginx
...
libssl.so.1.0.0 => /opt/gitlab/embedded/lib/libssl.so.1.0.0 (0x00007fe3cf8f9000)
libcrypto.so.1.0.0 => /opt/gitlab/embedded/lib/libcrypto.so.1.0.0 (0x00007fe3cf520000)
...
Gitlab omnibus uses its own bundled OpenSSL. apt-get update will not update and protect an install of gitlab omnibus.
Related
In a server linux Centos 5 64bit, I have compile from the source code the webserver Apache version 2.4.6.
Below, the configure instruction that I have used.
./configure --enable-mods-shared=reallyall --with-suexec-caller=apache --enable-cache --enable-cache-disk --with-ldap --enable-ldap --enable-authnz-ldap
Now, I must recompile the webserver Apache to using the new installed version of openssl (1.0.1e-fips).
What is the correct syntax to reconfigure Apache to using the current version of openssl installed on the server?
Many thanks at all.
As you unfortunately didn't mention how you installed OpenSSL 1.0.1e-fips (and where), this can't be answered. Based on 1.0.1e-fips, I see some chances that you used my openssl101e RPM package from EPEL 5 (even more important: openssl101e-devel). If so, run
export CFLAGS="$CFLAGS -I/usr/include/openssl101e"
export CPPFLAGS="$CPPFLAGS -I/usr/include/openssl101e"
export LDFLAGS="$LDFLAGS -L/usr/include/openssl101e"
before ./configure. Otherwise you first need to reveal more details about your OpenSSL 1.0.1e-fips installation/update.
At present we are on Apache/2.2.15 (UNIX) version. To fix the vulnerabilities we are suggested to upgrade to new version. I got new version from online using "wget" command and followed steps mentioned on this link http://httpd.apache.org/docs/2.2/install.html#download.
Once I am done, checked version using httpd -v. It gives me old version Apache/2.2.15 (UNIX). If I check using /usr/local/apache2/bin/httpd - v. It gives me new version. Did I successfully upgraded the version or not? If not what should I do?
I tried "yum install httpd" - It says "Nothing to do".
You now have two versions of Apache installed. You have the one installed with the system package manager (yum) in /usr/sbin/httpd. You have one installed manually in /usr/local/apache2/....
Which one you get will be determined entirely by which path you use.
In general, mixing system-managed packages with manually installed packages is a recipe for trouble. If you want to stick with the newer version in /usr/local, you should remove the system version, and realize that you will lose some manageability. For example, you will no longer be able to use yum install ... to install new Apache modules, and you will not be able to verify the installed files using tools like rpmverify.
If your distribution currently has Apache 2.2.x, that suggests your distribution is fairly old. For example, RHEL (and CentOS) 7 (and similar variants) have version 2.4.6 packaged, so you may want to update your host to something newer than whatever you're running now.
Yes, its successfully upgraded as per the screenshot.
httpd 2.2.15 is the version with RHEL 6 repository, here HTTPD_HOME is /etc/httpd (Highest version provided for HTTPD via RPM RHEL 6 is 2.2.15)
httpd 2.4.6 is the version with EPEL-HTTPD24 repository, here HTTPD_HOME is /usr/local/apache2/
I can understand 2.1.7 but what is +dfsg-3~94.git954a8d0.pgdg80+1 coming after that ?
I am now build postgis docker container from appropriate/docker-postgis
and am getting error
E: Version '2.1.7+dfsg-3~94.git954a8d0.pgdg80+1' for 'postgresql-9.3-postgis-2.1' was not found
E: Version '2.1.7+dfsg-3~94.git954a8d0.pgdg80+1' for 'postgis' was not found
seems to be a problem of package management?
How could I find fix this? How could I find all "subversions" +dfsg-3~94.git954a8d0.pgdg80+1.
thx
Sometimes using only version number 2.1.7 is not enough, as there are different OS, architectures (or even git branches as you can see), so developers append these specifics to the version to avoid confusion. If you used:
apt-get update postgresq-2.1.7
It would not make sense (or it would and would give you default option), because for this product version-number is not good enough for Docker to set up your environment.
dfsg = Debian Free Software Guidelines (specifies it is for specific version of Debian system, not for redHat for example)
git - version/branch specified
pgdg80 = PostgreSQL packages and backports for Debian/Ubuntu
Take a look here
I have a project that runs on Debian and uses many packages provided from the Debian repositories.
Because of demand, I've looked into porting the project to CentOS, but found that many of the packages I require are completely missing - at least 10 dependencies would have to be compiled manually at install time on the users machine.
My question is, what is the best way to create an installer for the user's machine? Should I use automake tools (with the standard ./configure, make, make install), to compile the required libraries, or is this a non-standard approach. Note that my app doesn't actually need to be compiled since it is written in Python, so is it weird to do a "make", when you're not compiling your own app?
Should the configure script just warn the user that package X is missing, and let them handle the rest?
Should I roll my own dependency checker by runng pkg-config manually a few times for each library required, and exit if something is missing?
I'm quite new to this, so any tips to get me moving in the right direction are appreciated.
Edit: I am familiar with RPM and yum for red hat base distros, but CentOS is missing many multimedia packages that I require. An example of one of my package dependencies is "liquidsoap" which is a programmable audio engine: http://savonet.sourceforge.net/
This is available on Debian, but not Redhat/Centos
See this link on CentOS package management.
http://wiki.centos.org/PackageManagement/Yum
CentOS is redhat based and does not use .deb packages by default. However apt package management has been ported to tons of platforms, you may be able to use a port for centOS
If you use YUM whatever packages you need will be there for your application as redhat distros need all the same things that any other distro does.
EDIT: To get the details out of comments
Packages not available on the target platform either have to be built (possibly as a port) on the target platform and then shipped in the ported package (in this case YUM), or code needs to be modified and forked to use packages which already are available on the target platform. The choice depends on which is worse, or which is even possible given your constraints.
I have installed OpenSUSE 12.1 installed on machine.
and i have postgresql-contrib-8.3.11-0.1.i586.rpm,postgresql-devel-8.3.11-0.1.i586.rpm, postgresql-docs-8.3.11-0.1.i586.rpm,postgresql-libs-8.3.11-0.1.i586.rpm,postgresql-server-8.3.11-0.1.i586.rpm..
I want to installed postgresql 8.3 version based on above packages..but when i installed with this command .it shows an error.
opnsu121:/ # rpm -Uvh postgresql-server-8.3.11-0.1.i586.rpm
error: Failed dependencies:
postgresql = 8.3 is needed by postgresql-server-8.3.11-0.1.i586
Even i am not able to find postgresql 8.3 base version as i think the above one is update.i have gone throgh the download.openSUSE.orf,ftp.openSUSE.org..
http://download.opensuse.org/update/11.0/rpm/i586/..
but not able to find what i need..so please help on this,
If at all possible, use YaST or whatever package manager SuSE uses to install the current version of PostgreSQL. From the repository it looks like that's 9.1.1.
If you specifically need PostgreSQL 8.3, I'd recommend using the distro-independent installer from EnterpriseDB. That should work fine on SuSE 12.2. If your organisation has particularly restrictive and unsafe version policies that force you to use old versions with known bugs, you can get 8.3.14 for 32-bit Linux here and 8.3.11 for 32-bit Linux here.
If you have issues with using the well-tested and known-to-work EnterpriseDB binary installer versions of PostgreSQL, your other option (and a good one) is to install from source code. Download the PostgreSQL 8.3.18 sources from the FTP site, then:
sudo mkdir -p /opt/postgresql93
sudo chown `id -un` /opt/postgresql93
./configure --prefix=/opt/postgresql93
make
make install
after which you can use /opt/postgresql93/bin/initdb (see initdb manual) to create a database and /opt/postgresql93/bin/pg_ctl (see pg_ctl manual) to start/stop it, as per the PostgreSQL documentation.
Don't try to force packages from an old version of SuSE to install on your new version. It'll probably result in an increasing tree of dependencies and end in pain.
If at all possible, try to convince your company that their policy of requiring a specific minor version (eg 8.4.14 not just "8.4.x") of PostgreSQL is unsafe and counterproductive. They're forcing you to do dirty hacks or hand-compile unique, custom installs just for your setup in order to avoid using well tested builds that contain extra bug fixes. Requiring approval before upgrading from 8.3 to 8.4/9.0/9.1/etc makes sense as there are feature and backward compatibility changes that require careful testing, but requiring approval before upgrading from 8.3.14 to 8.3.18 is counterproductive. Minor version upgrades of PostgreSQL are very conservative; you should stay up to date with the latest minor release.
hurray...I got the answer..
I have got the package below:
postgresql-contrib-8.3.11-0.1.i586.rpm, postgresql-devel-8.3.11-0.1.i586.rpm,postgresql-docs-8.3.11-0.1.i586.rpm,postgresql-libs-8.3.11-0.1.i586.rpm,postgresql-server-8.3.11-0.1.i586.rpm from the below link:
http://download.opensuse.org/update/12.1/i586/
and the one more package which i have struggled to get is:
postgresql-8.3.11-0.1.i586.rpm with the following link:
http://rpm.pbone.net/index.php3/stat/4/idpl/17194424/dir/opensuse_11.x/com/postgresql-8.3.11-0.1.i586.rpm.html
with all above packages i have installed using..
rpm -ivh packagename
if there is a dependency then rpm -ivh --nodeps packagename
great..its done..