6 ms·

Why is this so much upvoted? This is old news. IMHO ngxpagespeed is a good option if you have a lot of old legacy stuff which cannot be converted for a good web

Why is this so much upvoted? This is old news. IMHO ngxpagespeed is a good option if you have a lot of old legacy stuff which cannot be converted for a good web compression nowadays. But compiling your own nginx is not trivial and I would not recommend it for everyone. It would be great if there would be a great precompiled nginx with newest security fixes for my Ubuntu which can enable ngxpagespeed or the new brotli compression: This is missing in the open source world.

tomlongson 11y ago
I have the same issue. Alternatively a Docker ubuntu base image with nginx + pagespeed would be wonderful. [Edit] Found these links: https://github.com/laurisvan/docker-pagespeed/blob/master/Dockerfile https://github.com/laurisvan/docker-pagespeed/blob/master/Do... https://github.com/lewg/docker-nginx-pagespeed https://github.com/lewg/docker-nginx-pagespeed https://github.com/namshi/docker-node-nginx-pagespeed https://github.com/namshi/docker-node-nginx-pagespeed
tedmiston 11y ago
I haven't compiled from source myself, but it doesn't seem too bad from the official guide. https://developers.google.com/speed/pagespeed/module/build_ngx_pagespeed_from_source https://developers.google.com/speed/pagespeed/module/build_n...
theli0nheart 11y ago
Compiling nginx is actually pretty easy. With the defaults, it's just a three-liner (./configure, make, sudo make install).
- falsedan 11y ago
  I actually did it live on prod boxes in last job and then used the in-place binary upgrade signal to seamlessly restart nginx. A dev who'd never touched prod and I wrote an ansible playbook for it.
  - noir_lord 11y ago
    You had development tools on production machines notably a compiler? Interesting, lots of places I've worked that would have been a no go (security risk).
    - takeda 11y ago
      This is something I noticed at my previous job (removing user access to gcc, make, ld etc so only root can run it[1]) and never understood. It reminds me of blocking ping to improve security or worse blocking all ICMP. Compiler, and especially make are harmless by themselves. They aren't setuid all it's used for is translate file from one format (source code) to another (machine code). One might as well block sed, because it could be used to modify /etc/passwd or /etc/shadow. A someone who would want to compromise hosts if they need binaries, they would precompile them statically, that way is a single file, no need for libraries and no need extra development packages with header files and more likely to work across wide range of systems. [1] because, there were chef recipes that were compiling things :> Also, it decreases security, because now you need to run compiler as root, so you could be compromised through things like this: http://securitytracker.com/id/1004374 http://securitytracker.com/id/1004374
      - deleted 11y ago
        [deleted]
      - noir_lord 11y ago
        Never said it made sense, just that at lots of places that was the rule. For your what its worth I agree with you, if you are at the point where an attacker is executive a compiler you are already hosed.
      - vidarh 11y ago
        Imagine an attacker is able to inject small files onto the system via a channel that would not let them transmit arbitrary binary data, and that the system is otherwise sufficiently firewalled to prevent them from just downloading their own tools without first further compromising the system. Having a compiler available can make it substantially easier to bootstrap a toolchain to compromise the system fully. Another issue is that it presents a privilege escalation concern. If you compile stuff in a user account on the production machines that will be run with root privileges, if someone compromises that user account they can now put in place a compiler wrapper to embed their own code. Even if you don't do anything else in that account (e.g. sudo) that'd let them e.g. capture passwords the compilation presents another risk. (As an extension to this: Your dev and build environments are security critical; but in your production environment is often far more vulnerable - not least because it's far more visible) I don't think these are very high on the list of things you should worry about as your system needs to be very locked down before an attacker that is able to make use of them won't have other just as good opportunities, but the more stuff you run in your production environment, the more opportunities you give an attacker.
nikolay 11y ago
It's old news, but underused. This is a life savior especially when you have to deal with software that you don't control, which spits out unoptimized assets. If you have compilophobia, use EasyEngine [0] or Centminmod [1]! [0]: https://easyengine.io/ https://easyengine.io/ [1]: https://centminmod.com/ https://centminmod.com/
- vbtechguy 11y ago
  Yup Centmin Mod LEMP stack installer maintains and integrates ngx_pagespeed with Nginx installs http://centminmod.com/nginx_ngx_pagespeed.html http://centminmod.com/nginx_ngx_pagespeed.html along with handy command line shortcuts to enable and disable pagespeed via pscontrol command :)
  - nikolay 11y ago
    Thank you for doing an outstanding job!
cbr 11y ago
compiling your own nginx is not trivial and I would not recommend it for everyone Yes, this is frustrating as an nginx module developer as well. Apache has a loadable module system and we can ship binaries, but to add a module to nginx you have to recompile. Nginx's developers have been hinting that they're going to add support for loading .so modules, and I really hope they do!
- tuananh 11y ago
  tengine (a fork of nginx) fixes this problem.
  - nikolay 11y ago
    But is, unfortunately, a few generations behind.
- btown 11y ago
  Also, runtime behavior depends on the order of --add-module compilation flags! Got bitten by this when sub_filters weren't working... and then I realized that the order in which [un]gzip and sub_filters are applied isn't driven by the order of the directives in the config file, but by the compilation string - the substitution filtering was being done on gzipped gibberish! This was probably a Good Idea (tm) for performance reasons - filtration is just a compile-time linked list of function calls. But it's barely documented at all!
- theli0nheart 11y ago
  Looks like your wish has finally been granted. Nginx released dynamic module support in nginx-1.9.11 today! http://mailman.nginx.org/pipermail/nginx-announce/2016/000170.html http://mailman.nginx.org/pipermail/nginx-announce/2016/00017...
deathanatos 11y ago
> compiling your own nginx is not trivial and I would not recommend it for everyone. It's still pretty easy. For those that have never done it, it's a configure-like script, make, make install. That's it. It's almost your standard autoconf package routine of ./configure && make && make install, except the configure script is oddly in a subdir and not from autofoo. But it is all covered in the documentation, IIRC.
- therealmarv 11y ago
  yes compilation itself is not the problem here. Problem is more maintaining the whole stuff. Keep e.g. sure OpenSSL is up to date linked in your nginx is a good example (what a nightmare). Also getting nginx running and configuring like a standard Ubuntu one is not out of the box. This are all extra step which not everybody wants to deal with.
  - deathanatos 11y ago
    IIRC, OpenSSL is dynamically linked by default in a custom compiled nginx — the same as it would be if you didn't custom compile it, and you have the same amount of work either way maintaining OpenSSL. I maintain a custom compile of nginx, but the custom ends at the boundary of nginx: it uses Ubuntu's libssl, so OpenSSL patches that make it to Ubuntu apply normally to my custom build. The config for nginx is the same: /etc/nginx/…. I can tell you it's exactly the same, as we transitioned from a config from Ubuntu stock nginx to my custom build (and went up a version) with zero issues. The only real thing that is different is the binary itself, and the installation location. (But I did the latter on purpose, because I didn't want to collide with apt/dpkg's management of /usr/bin.)
    - therealmarv 11y ago
      Thanks for the information! I will keep this in mind next time. It was some time ago the last time I used custom compiled nginx. Seemed I used a statically linked OpenSSL (which had this downsides). I informed myself a littlebit more here https://www.nginx.com/blog/nginx-and-the-heartbleed-vulnerability/ https://www.nginx.com/blog/nginx-and-the-heartbleed-vulnerab...
LinuxBender 11y ago
Compiling nginx would be a lot easier if they would stop hard coding so many things in the makefile. Enabling libc hardening (aslr, pie, full relro for example) requires manually editing generated files before compiling and overriding his ldflags, cflags, etc. I have reported this multiple times but Maxim didn't agree with me that this is a priority.

tomlongson 11y ago

I have the same issue. Alternatively a Docker ubuntu base image with nginx + pagespeed would be wonderful. [Edit] Found these links: https://github.com/laurisvan/docker-pagespeed/blob/master/Dockerfile https://github.com/laurisvan/docker-pagespeed/blob/master/Do... https://github.com/lewg/docker-nginx-pagespeed https://github.com/lewg/docker-nginx-pagespeed https://github.com/namshi/docker-node-nginx-pagespeed https://github.com/namshi/docker-node-nginx-pagespeed

tedmiston 11y ago

I haven't compiled from source myself, but it doesn't seem too bad from the official guide. https://developers.google.com/speed/pagespeed/module/build_ngx_pagespeed_from_source https://developers.google.com/speed/pagespeed/module/build_n...

theli0nheart 11y ago

Compiling nginx is actually pretty easy. With the defaults, it's just a three-liner (./configure, make, sudo make install).

falsedan 11y ago
I actually did it live on prod boxes in last job and then used the in-place binary upgrade signal to seamlessly restart nginx. A dev who'd never touched prod and I wrote an ansible playbook for it.
- noir_lord 11y ago
  You had development tools on production machines notably a compiler? Interesting, lots of places I've worked that would have been a no go (security risk).
  - takeda 11y ago
    This is something I noticed at my previous job (removing user access to gcc, make, ld etc so only root can run it[1]) and never understood. It reminds me of blocking ping to improve security or worse blocking all ICMP. Compiler, and especially make are harmless by themselves. They aren't setuid all it's used for is translate file from one format (source code) to another (machine code). One might as well block sed, because it could be used to modify /etc/passwd or /etc/shadow. A someone who would want to compromise hosts if they need binaries, they would precompile them statically, that way is a single file, no need for libraries and no need extra development packages with header files and more likely to work across wide range of systems. [1] because, there were chef recipes that were compiling things :> Also, it decreases security, because now you need to run compiler as root, so you could be compromised through things like this: http://securitytracker.com/id/1004374 http://securitytracker.com/id/1004374
    - deleted 11y ago
      [deleted]
    - noir_lord 11y ago
      Never said it made sense, just that at lots of places that was the rule. For your what its worth I agree with you, if you are at the point where an attacker is executive a compiler you are already hosed.
    - vidarh 11y ago
      Imagine an attacker is able to inject small files onto the system via a channel that would not let them transmit arbitrary binary data, and that the system is otherwise sufficiently firewalled to prevent them from just downloading their own tools without first further compromising the system. Having a compiler available can make it substantially easier to bootstrap a toolchain to compromise the system fully. Another issue is that it presents a privilege escalation concern. If you compile stuff in a user account on the production machines that will be run with root privileges, if someone compromises that user account they can now put in place a compiler wrapper to embed their own code. Even if you don't do anything else in that account (e.g. sudo) that'd let them e.g. capture passwords the compilation presents another risk. (As an extension to this: Your dev and build environments are security critical; but in your production environment is often far more vulnerable - not least because it's far more visible) I don't think these are very high on the list of things you should worry about as your system needs to be very locked down before an attacker that is able to make use of them won't have other just as good opportunities, but the more stuff you run in your production environment, the more opportunities you give an attacker.

nikolay 11y ago

It's old news, but underused. This is a life savior especially when you have to deal with software that you don't control, which spits out unoptimized assets. If you have compilophobia, use EasyEngine [0] or Centminmod [1]! [0]: https://easyengine.io/ https://easyengine.io/ [1]: https://centminmod.com/ https://centminmod.com/

vbtechguy 11y ago
Yup Centmin Mod LEMP stack installer maintains and integrates ngx_pagespeed with Nginx installs http://centminmod.com/nginx_ngx_pagespeed.html http://centminmod.com/nginx_ngx_pagespeed.html along with handy command line shortcuts to enable and disable pagespeed via pscontrol command :)
- nikolay 11y ago
  Thank you for doing an outstanding job!

cbr 11y ago

compiling your own nginx is not trivial and I would not recommend it for everyone Yes, this is frustrating as an nginx module developer as well. Apache has a loadable module system and we can ship binaries, but to add a module to nginx you have to recompile. Nginx's developers have been hinting that they're going to add support for loading .so modules, and I really hope they do!

tuananh 11y ago
tengine (a fork of nginx) fixes this problem.
- nikolay 11y ago
  But is, unfortunately, a few generations behind.
btown 11y ago
Also, runtime behavior depends on the order of --add-module compilation flags! Got bitten by this when sub_filters weren't working... and then I realized that the order in which [un]gzip and sub_filters are applied isn't driven by the order of the directives in the config file, but by the compilation string - the substitution filtering was being done on gzipped gibberish! This was probably a Good Idea (tm) for performance reasons - filtration is just a compile-time linked list of function calls. But it's barely documented at all!
theli0nheart 11y ago
Looks like your wish has finally been granted. Nginx released dynamic module support in nginx-1.9.11 today! http://mailman.nginx.org/pipermail/nginx-announce/2016/000170.html http://mailman.nginx.org/pipermail/nginx-announce/2016/00017...

deathanatos 11y ago

> compiling your own nginx is not trivial and I would not recommend it for everyone. It's still pretty easy. For those that have never done it, it's a configure-like script, make, make install. That's it. It's almost your standard autoconf package routine of ./configure && make && make install, except the configure script is oddly in a subdir and not from autofoo. But it is all covered in the documentation, IIRC.

therealmarv 11y ago
yes compilation itself is not the problem here. Problem is more maintaining the whole stuff. Keep e.g. sure OpenSSL is up to date linked in your nginx is a good example (what a nightmare). Also getting nginx running and configuring like a standard Ubuntu one is not out of the box. This are all extra step which not everybody wants to deal with.
- deathanatos 11y ago
  IIRC, OpenSSL is dynamically linked by default in a custom compiled nginx — the same as it would be if you didn't custom compile it, and you have the same amount of work either way maintaining OpenSSL. I maintain a custom compile of nginx, but the custom ends at the boundary of nginx: it uses Ubuntu's libssl, so OpenSSL patches that make it to Ubuntu apply normally to my custom build. The config for nginx is the same: /etc/nginx/…. I can tell you it's exactly the same, as we transitioned from a config from Ubuntu stock nginx to my custom build (and went up a version) with zero issues. The only real thing that is different is the binary itself, and the installation location. (But I did the latter on purpose, because I didn't want to collide with apt/dpkg's management of /usr/bin.)
  - therealmarv 11y ago
    Thanks for the information! I will keep this in mind next time. It was some time ago the last time I used custom compiled nginx. Seemed I used a statically linked OpenSSL (which had this downsides). I informed myself a littlebit more here https://www.nginx.com/blog/nginx-and-the-heartbleed-vulnerability/ https://www.nginx.com/blog/nginx-and-the-heartbleed-vulnerab...

LinuxBender 11y ago

Compiling nginx would be a lot easier if they would stop hard coding so many things in the makefile. Enabling libc hardening (aslr, pie, full relro for example) requires manually editing generated files before compiling and overriding his ldflags, cflags, etc. I have reported this multiple times but Maxim didn't agree with me that this is a priority.