Installed version of varnish is 4.1.1 and os is CentOS7.x
varnish version:
varnishd -V
varnishd (varnish-4.1.1 revision 66bb824)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2015 Varnish Software AS
While trying to create some nice logs for varnish, using the varnishncsa tool, i found some flags and fields that i wanted to make use of.
But while trying to use said flags( -b -c ) and some fields( Varnish:side ) the tool complains about them not being available and halts execution.
Example:
varnishncsa -b ...
varnishncsa: invalid option -- 'b'
As seen on docs varnish 4.0 does not have these flags and fields available while 4.1 does.
The VCL that starts with varnishd is declaring a VCL 4.0; at the start. Any chance this has to do with it(i highly doubt that but you never know)? Changing this value to 4.1 or 4.1.1 makes the varnishd fail.
Upgrading varnish to 6.x is a no go from the dev side. But based on docs this should be working right away, unless i am missing something.
So how do i make these flags and fields available to me? What am i missing?
All versions of Varnish 4 and Varnish 5 are end-of-life and no longer receive any updates. As you can see on http://varnish-cache.org/releases/index.html only the following versions of Varnish are supported:
Varnish 6.5
Varnish 6.6
Varnish 6.0 LTS
If you have a look at the news section on http://varnish-cache.org, there have been a number of security vulnerabilities that have been fixed in recent versions of Varnish.
If upgrading from Varnish 4.0 to Varnish 6.0 LTS is not possible, I'm afraid you have far bigger problems than the varnishncsa problem you're reporting here.
I strongly encourage you to upgrade to Varnish 6.0 LTS. Try running a Varnish 6 instance on a separate machine and test the compatibility of your VCL file.
If anything comes up, I'll be glad to assist you in migrating your VCL file.
building varnish 4.1.11 from sources actually works as expected and varnishnsca have all the options available. Installing from packages does not although the version reported is the same but another revision code.
As #Thijs Feryn mentioned it is not suggested to use unsupported versions on production but if anyone is facing the same issue on centos with this then try building from sources.
Related
After installing Symfony 2 and check /config.php I got this notification:
intl ICU version installed on your system is outdated (55.1) and does not match the ICU data bundled with Symfony (57.1)
To get the latest internationalization data upgrade the ICU system package and the intl PHP extension.
How can I upgrade this?
I'm using Ubuntu 16.04
This is just a warning and you can safely ignore the message. I've response to similar questions on this. See this URL for more details:
https://github.com/symfony/symfony/issues/15007
Note: You'll also get the message when you run:
php bin/symfony_requirements
The message will say it's an "Optional recommendation".
EDIT #2
Based on your comments. You need to upgrade ICU. Sounds like you might be on Debian, and it might be possible to upgrade. Try these commands.
yum list available |grep icu
This shows what packages are available and searches for "icu". The second column shows the version. If there is a version that shows "57.1", then you should be able to use yum install to install it. Otherwise you would have to build and install on your system, which is much more difficult to give you a definite answer.
I have CENTOS7 server, with:
Server version: Apache/2.4.6 (CentOS)
.
How can i enable/add HTTP/2 on these Apache ?
I'm trying to send http2 requests from the client via Nghttp, but i get an error in the response (recv RST_STREAM frame ) as a result of server which does not supports Http2.
I saw that i have to enable module_http2 in the apache, but i didn't
found hot can i do this.
Thanks in Advance.
HTTP/2 support was only added in Apache 2.4.18 which is not available in the standard CentOS/Red Hat repos. Though as mod_http2 was (and still is at time of writing) being actively worked on you should go with the latest version (2.4.33 at time of writing - though there are further mod_http2 patches available on top of that).
Additionally HTTP/2 requires OpenSSL 1.0.2 or above which means you need CentOS/RHEL 7.4 or above unless you want to install your own version of OpenSSL as well your own version of Apache. Note you need Apache 2.4.26 or above if you want to go further than that and go to OpenSSL 1.1.0.
So you need to download and compile a later Apache (and possibly OpenSSL) from source - or find another repo with these later versions. This does carry some risks - primarily that you lose the easy security patches that repo versions supply. CentOS Apache 2.4.6 actually includes all the latest security patches of later versions (assuming you regularly run "yum update" to update it) - but not the functionality changes like HTTP/2 (hence why they leave version number at 2.4.6).
If you're interested in installing from source then I've a step by step blog post on how to do that here: https://www.tunetheweb.com/performance/http2/
You can install a newer version of httpd than is included in the base repositories through the httpd24 Software Collection. Once you've enabled the SCL, you need the following packages:
httpd24
httpd24-nghttp2
httpd24-mod_ssl *
* It's best to configure SSL too, because for example Chrome will only do HTTP2 with TLS.
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 recently realized that our servers were vulnerable to CVE-2014-0224 by doing an SSL Labs scan.
We are running a node.js server on our site. I read that the vulnerability was eliminated in node.js version 0.10.29, so I used nvm to install version 0.11.13 on our ubuntu 12 server. However, after restarting the node.js server, the scan still shows we're vulnerable.
Thinking that perhaps node.js was relying on the system installation of openssl rather than using their own, I upgraded that, as well. openssl version -b now shows that we have the version that was built on 1 Oct 2014 ... which should be plenty good by all accounts (upgrading to this version was how I eliminated the vulnerability from another one of our servers that was running a ruby server ... also on ubuntu 12).
However, I haven't been able to find the right combination to eliminate the vulnerabilty from our node.js server. How can I do that? :o)
Aha! I updated one node.js version later (0.11.14), and that solved the problem. No more vulnerabilities for me! :o)
I am running CentOS 6.5 on top of Linux kernel 2.6.32-358.6.1.el6.x86_64
I got a warning from my vserver hoster that I need to upgrade to a Linux kernel > 3.15-rc5 because there is a security breach that would allow my server to be taken over.
I did a yumupgrade, but it wouldn't upgrade the kernel to a higher version than 2.6.32-358.6.1.el6.x86_64.
Currently I am confused about how to go on.
Could anybody tell me what is going on and how he would act in my position?
Thank you!
That kernel is a development kernel and will likely require you compile from source to install it. Upgrading from kernel 2.6 to 3.1n will likely break a bunch of packages also. The upgrade path for 3.1n in CentOS would be to upgrade to CentOS7 and then compile that kernel yourself.
CentOS backports security fixes and I certainly haven't heard anything about any security bug, and we manage like 150 centos servers. I would ask your host to specify what the security bug is and which patch applied in the 3.15-rc5 kernel fixes it. Who's the host?
I'm using CentOS 6.5 and have no problem using the ElRepo Long term kernel (currently 3.10.x).
See http://elrepo.org/tiki/kernel-lt
Upgrading was just a case of
yum --enablerepo=elrepo-kernel install kernel-lt
and rebooting.