Language Selection

English French German Italian Portuguese Spanish

New Content/Layout OK?

Varnish Proxy

Silly me, a poll would not work on the new server. I forgot that with the Varnish cache proxy at the front almost all visitors arrive from the same IP address (the proxy), which means that Drupal would allocate just one vote to all (except registered and presently logged in users). With Drupal upgrade we can perhaps find polling software that overcomes this.

rpaf

You must use mod_rpaf to fix this problem that Varnish introduces.
See eg https://www.varnish-cache.org/lists/pipermail/varnish-misc/2008-September/016470.html
mod_rpaf for EL6 64bit here: http://centos.alt.ru/repository/centos/6/x86_64/mod_rpaf-0.6-2.el6.x86_64.rpm

Proxy

Thank, we will look into it. Currently, a lot of stuff other than the poll (e.g. views being counted) are not compatible with Varnish and it makes it look as though not many people visit and can participate in the site.

For sheer stats you could use

For sheer stats you could use an external (i.e. not cached by varnish) service, such as Google Analytics or run your own Piwik.

Piwik

Google Analytics is spyware, but Piwik would be a possibility (Stallman recently told me that it's good). Can it be installed on a cache proxy? I'd have to gain access to it first. Either way, this would not facilitate per-post page request count. Susan had it set up with a module, but it's no longer working correctly. In turn, rating/sorting posts by popularity is no longer possible, and that's the real downside (the front page can no longer list popular items for today).

The problem is not just that IP addresses are not unique. Some requests are never seen by the CMS and Apache.

For the non-unique addresses

For the non-unique addresses look at mod_rpaf, it was made for this situations.
Is this drupal6 or 7? With 6 varnish integration sucks from what I've seen.

See also
https://drupal.org/project/varnish
https://fourkitchens.atlassian.net/wiki/display/TECH/Configure+Varnish+3+for+Drupal+7

Agreed on Google Analytics. You can just install Piwik on the same host and tell Varnish either not to cache it or you can just set its virtualhost on a port other than 80 so it bypasses Varnish completely.

Varnish

Thanks for the pointers.

Yes, it's Drupal 6 and there are other issues that I am beginning to see, such as lack of updates from the RSS feeds around the page (I am currently investigating this, maybe it's related to a cron job or module config although I very much doubt the latter as I haven't changed configs).

Non-unique addresses could be bypassed as an issue even by writing random IP addresses, but that would enable easy poll rigging. I guess it's not essential for operation of the site, but it's a nice-to-have...

From Drupal.org: "This module provides integration between your Drupal site and the Varnish HTTP Accelerator, an advanced and very fast reverse-proxy system. Basically, Varnish handles serving static files and anonymous page-views for your site much faster and at higher volumes than Apache, in the neighborhood of 3000 requests per second."

I have had such issues with Varnish on top of WordPress and MediaWiki (pages served improperly from cache) and it all makes me wonder if removing Varnish altogether is the best way to proceed.

As for Piwik, I have never tried it before, so I will look into it.

I would keep Varnish on for

I would keep Varnish on for static files (css, js, jpeg etc) and to clean up HTTP traffic (Varnish will not forward incomplete or malformed HTTP requests to the backend, it should also be the front line against synfloods etc).

Here's a sample of what I use (test it first, I'm just beginning with Varnish myself)

director default dns {
.list = {
.port = "8080";
.connect_timeout = 5s;
.first_byte_timeout = 600s;
.between_bytes_timeout = 600s;
.max_connections = 10000;
"172.16.1.53"/32;
}
}
sub vcl_recv {
if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
return(lookup);
}
}
sub vcl_fetch {
if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
unset beresp.http.set-cookie;
}
if (req.restarts == 0) {
if (req.http.x-forwarded-for) {
set req.http.X-Forwarded-For =
req.http.X-Forwarded-For + ", " + client.ip;
} else {
set req.http.X-Forwarded-For = client.ip;
}
}
}

Then install mod_rpaf and make sure your Apache is listening on port 8080 and add this to /etc/httpd/conf.d/rpaf.conf:
LoadModule rpaf_module modules/mod_rpaf-2.0.so

RPAFenable On
RPAFproxy_ips 127.0.0.1 IPs_OF_THE_SERVER
RPAFsethostname On
RPAFheader X-Forwarded-For

PS: looks like drupal is messing with my comments, here's a text version http://fpaste.org/74672/raw/

Thanks

Thanks, I will look at it and into it in the weekend.

RSS feeds

The Piwik demo looks impressive, I have just given them a word of endorsement.

I am still trying to resolve some other issues we've identified.

I think I found the source of the issue above (RSS feeds). It seems like any external site access is denied by default, which helps explain why RSS feeds cannot be retrieved by the Drupal part of the site:


[root@tuxmachines ~]# wget lxer.com
--2014-02-05 04:34:37--  http://lxer.com/
Resolving lxer.com... 108.166.170.174
Connecting to lxer.com|108.166.170.174|:80... failed: Connection refused.
[root@tuxmachines ~]# wget linuxtoday.com
--2014-02-05 04:34:54--  http://linuxtoday.com/
Resolving linuxtoday.com... 70.42.23.121
Connecting to linuxtoday.com|70.42.23.121|:80... failed: Connection refused.

Looks like a firewall issue

Looks like a firewall issue at the first glance.

Firewall

Nux wrote:

Looks like a firewall issue at the first glance.

Yes, it was a simply issue to tackle. It works now.

Pageview count and polls

I'll have a look and see if configuration can solve not just the polling issue but also pageview count. The site of this module is down and it seems like it may require configuration on the cache server too.

More in Tux Machines

Security Leftovers

  • Linux Fixes Spectre V1 SWAPGS Mitigation After Being Partially Borked Since Last Year - Phoronix

    This week's set of "x86/urgent" changes for the Linux 5.16-rc4 kernel due out later today has some Spectre V1 fixes after kernel commits last year ended up partially messing things up around its SWAPGS handling. These fixes in turn will also likely be back-ported to relevant stable kernel series. Thanks to an Alibaba engineer, Lai Jiangshan, are some important fixes around the Spectre V1 SWAPGS mitigation that are landing today in the mainline kernel.

  • Reproducible Builds: Reproducible Builds in November 2021

    As a quick recap, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is therefore to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. If you are interested in contributing to our project, please visit our Contribute page on our website.

  • Reproducible Builds (diffoscope): diffoscope 195 released

    The diffoscope maintainers are pleased to announce the release of diffoscope version 195. This version includes the following changes:

    [ Chris Lamb ]
    * Don't use the runtime platform's native endianness when unpacking .pyc
      files to fix test failures on big-endian machines.
    

Linux 5.16-rc4

Fairly small rc4 this week. Three areas stand out in the diff: some
kvm fixes (and tests), network driver fixes, and the tegra SoC sound
fixes.

The rest is fairly spread out: drm fixes, some filesystem stuff,
various arch updates, and some smattering of random driver fixes.

Nothing looks all that scary, although I certainly hope the kvm side
will calm down.

                  Linus
Read more Also: Linux 5.16-rc4 Released - "Nothing Looks All That Scary"

EFF Argument in Patent Troll Case to Be Livestreamed on Monday

At 10 am Monday, FOSS folks and others interested in software patent litigation will have a chance to have a firsthand look at how our courts address patent cases. The case involves a “notorious patent troll,” according to Electronic Frontiers Foundation, that is trying to hide information from Apple, which it’s suing. “At a federal appeals court hearing that will be livestreamed, attorney Alexandra H. Moss, Executive Director at Public Interest Patent Law Institute, who is assisting EFF in the case, will argue that a judge’s order to unseal all documents and preserve public access in the case of Uniloc USA, Inc. v. Apple Inc. should be upheld,” EFF said in a statement on Thursday. “Uniloc is entitled to resolve its patent dispute in publicly-funded courts, Moss will argue, but it’s not entitled to do so secretly.” EFF said that this is the second time the plaintiff, Uniloc, has appealed an order to be more transparent in this case. Read more

Gnuastro 0.16 released

Dear all,

I am happy to announce the 16th official release of GNU Astronomy
Utilities (Gnuastro version 0.16).

Gnuastro is an official GNU package, consisting of various
command-line programs and library functions for the manipulation and
analysis of (astronomical) data. All the programs share the same basic
command-line user interface (modeled on GNU Coreutils). For the full
list of Gnuastro's library, programs, and a comprehensive general
tutorial (recommended place to start using Gnuastro), please see the
links below respectively:

https://www.gnu.org/s/gnuastro/manual/html_node/Gnuastro-library.html
https://www.gnu.org/s/gnuastro/manual/html_node/Gnuastro-programs-list.html
https://www.gnu.org/s/gnuastro/manual/html_node/General-program-usage-tutorial.html

For a complete review of the new/changed features in this release,
please see [1] below (also available in the 'NEWS' file within the
source code tarball).

Here is the compressed source and the GPG detached signature for this
release. To uncompress Lzip tarballs, see [2]. To check the validity
of the tarballs using the GPG detached signature (*.sig) see [3]:

  https://ftp.gnu.org/gnu/gnuastro/gnuastro-0.16.tar.lz    (3.7MB)
  https://ftp.gnu.org/gnu/gnuastro/gnuastro-0.16.tar.gz    (5.9MB)
  https://ftp.gnu.org/gnu/gnuastro/gnuastro-0.16.tar.gz.sig (833B)
  https://ftp.gnu.org/gnu/gnuastro/gnuastro-0.16.tar.lz.sig (833B)

Here are the SHA1 and SHA256 checksums (other ways to check if the
tarball you download is what we distributed). Just note that the
SHA256 checksum is base64 encoded, instead of the hexadecimal encoding
that most checksum tools default to.

fe1f84bf1be270f1a62091e9a5f89bb94b182154  gnuastro-0.16.tar.lz
B4hftfYuyc7x3I6aEJ2SQlkp6x7zOOrPz/bK2koGuR8  gnuastro-0.16.tar.lz
1ae00673648fe8db5630f1de9d70b49fadb42d7d  gnuastro-0.16.tar.gz
kMEdJbsFrRNxDLX4EXntgXNgikJv3/2LIEWGLV/e4i0  gnuastro-0.16.tar.gz

For this release, Pedram Ashofteh Ardakani, Natáli D. Anzanello,
Sepideh Eskandarlou, Raúl Infante-Sainz, Vladimir Markelov and Zahra
Sharbaf directly contributed to the source of Gnuastro, I am very
grateful to all of them. I should also thank Alejandro Serrano
Borlaff, Fernando Buitrago, Mark Calabretta, Zohreh Ghaffari, Giulia
Golini, Leslie Hunt, Raúl Infante-Sainz, Matthias Kluge, Juan Miro,
Juan Molina Tobar, Markus Schaney, Zahra Sharbaf, Vincenzo Testa,
Ignacio Trujillo and Aaron Watkins for their very good suggestions or
bug reports that have been implemented in Gnuastro 0.16.

If any of Gnuastro's programs or libraries are useful in your work,
please cite _and_ acknowledge them. For citation and acknowledgment
guidelines, run the relevant programs with a `--cite' option (it can
be different for different programs, so run it for all the programs
you use). Citations _and_ acknowledgments are vital for the continued
work on Gnuastro, so please don't forget to support us by doing so.

This tarball was bootstrapped (created) with the tools below. Note
that you don't need these to build Gnuastro from the tarball, these
are the tools that were used to make the tarball itself. They are only
mentioned here to be able to reproduce/recreate this tarball later.
  Texinfo 6.8
  Autoconf 2.71
  Automake 1.16.4
  Help2man 1.48.5
  ImageMagick 7.1.0-9
  Gnulib v0.1-4944-g7fc3219bc
  Autoconf archives v2021.02.19-29-g0fbee2a

The dependencies to build Gnuastro from this tarball on your system
are described here:
  https://www.gnu.org/s/gnuastro/manual/html_node/Dependencies.html

Best wishes,
Mohammad
Read more