search

webp-sh / webp_server_go

Go version of WebP Server. A tool that will serve your JPG/PNG/BMP/SVGs as WebP/AVIF format with compression, on-the-fly.
https://docs.webp.sh
GNU General Public License v3.0
1.83k stars 175 forks source link

The log cannot show the real IP of the client #236

Closed ac169 closed 1 year ago

ac169 commented 1 year ago

Jun 26 03:31:02 co webp-server[553824]: 03:31:01 | 200 | 1ms | 127.0.0.1 | GET | /image/cache/P-DJI-T30-010-560x560.jpg Jun 26 03:31:03 co webp-server[553824]: 03:31:03 | 200 | 2ms | 127.0.0.1 | GET | /image/catalog/P-DJI-T30-010.jpg Jun 26 03:32:30 co webp-server[553824]: 03:32:29 | 200 | 0s | 127.0.0.1 | GET | /image/cache/catalog/P-DJI-T30-011-100x100.jpg

When the webp_server_go is used as the Nginx back end, even if the proxy_set_header X-Real-IP $ remote_addr, etc. are added to the nginx configuration file, there is no real IP in the log in the log. Not support Is there a problem with the real IP of the client? If the webp_server_go log itself does not support the significance of displaying the real IP of the client, what is the significance of the log?

BennyThink commented 1 year ago 
var app = fiber.New(fiber.Config{
    ServerHeader: "WebPPT",
    ProxyHeader:  "X-Real-IP", 
    AppName:      "WebPPT",
})

I think we should set that ProxyHeader.

ac169 commented 1 year ago 
var app = fiber.New(fiber.Config{
  ServerHeader: "WebPPT",
  ProxyHeader:  "X-Real-IP", 
  AppName:      "WebPPT",
})

I think we should set that ProxyHeader.

I haven't learned and used Golang, so I can't understand the code. Nginx configuration is as follows:


 ......

 location ~* (\.(jpg|jpeg|bmp|png))$ {
        proxy_pass http://127.0.0.1:6666;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_hide_header X-Powered-By;
        proxy_set_header HOST $http_host;
        expires max;
        access_log off;
    }

 ......

Excuse me, is it caused by the error of the true IP of the client?

BennyThink commented 1 year ago

Your configuration is correct, nginx will set header X-Real-IP with $remote_addr. We'll add this header soon.

BennyThink commented 1 year ago

this issue will be resolved by merging this PR https://github.com/webp-sh/webp_server_go/pull/220

ac169 commented 1 year ago

/lib64/libc.so.6: version `GLIBC_2.34' not found

In addition, I suggest that the Release version of the Release version of the Release version is compatible with the older system and GLIBC version. Of course, users can also compile them by themselves, but after all, the high version can be compiled by the low version GLIBC, and the low version GLIBC cannot run the high version of GLIBC Application of compilation. So I always feel less perfect

BennyThink commented 1 year ago

Yes you're right. We're planning to change the release_binary workflow to a lower version of distros.

Current considerations:

Personally I would prefer to use debian buster. Of course we would be appreciated if you can help us to resolve dependencies issues for stretch.

@n0vad3v what's your idea on this?

BennyThink commented 1 year ago

Update:

ac169 commented 1 year ago

The installation of libvips on the old version of the system is not complicated. You can refer to the connection https://tufora.com/tutorials/linux/general/install-vips-vips-tools-and-vips-devel-libvips-on-centos-7. In fact, this problem with libvips installation is secondary. The main problem is: if the Golang code is compiled, if the parameter does not specify the default, the GLIBC library that is dynamically referenced by the current compilation environment will be referenced and associated with its version, then an error will be reported when the actual run. Users can compile on their own platform to solve the GLIBC library version problem. This is only a suggestion for compatibility.

n0vad3v commented 1 year ago

@ac169 Thanks for suggestion, indeed using an older version of OS for compile should make the binary work on more OSs.

If you have any ideas on how to archive this, free feel to help us by contributing to https://github.com/webp-sh/webp_server_go/blob/master/.github/workflows/release_binary.yaml .

Currently on our tests on CentOS 7 with the article you've suggested, we've meet the following errors:

--> Finished Dependency Resolution
Error: Package: vips-devel-8.14.2-1.el7.remi.x86_64 (remi-safe)
           Requires: pkgconfig(libwebpmux) >= 0.6
           Available: libwebp-devel-0.3.0-7.el7.i686 (base)
               pkgconfig(libwebpmux) = 0.3.0
           Available: libwebp-devel-0.3.0-10.el7_9.i686 (updates)
               pkgconfig(libwebpmux) = 0.3.0
           Available: libwebp-devel-0.3.0-11.el7.i686 (updates)
               pkgconfig(libwebpmux) = 0.3.0
Error: Package: vips-devel-8.14.2-1.el7.remi.x86_64 (remi-safe)
           Requires: pkgconfig(libwebpdemux) >= 0.6
Error: Package: vips-devel-8.14.2-1.el7.remi.x86_64 (remi-safe)
           Requires: pkgconfig(libwebp) >= 0.6
           Available: libwebp-devel-0.3.0-7.el7.i686 (base)
               pkgconfig(libwebp) = 0.3.0
           Available: libwebp-devel-0.3.0-10.el7_9.i686 (updates)
               pkgconfig(libwebp) = 0.3.0
           Available: libwebp-devel-0.3.0-11.el7.i686 (updates)
               pkgconfig(libwebp) = 0.3.0
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Since playing with different types of OS is a little bit time consuming, our current primary goal now might be fixing bugs and continue our refactor, as there are two bugs are waiting to be fixed and a feature created by @bugfest (https://github.com/webp-sh/webp_server_go/pull/226) haven't been reviewed and discussed.

We'll mark this a low-priority but important task now, and will be take in to consideration after we've done things above, and currently it's suggested to use Docker for running if your system has an older GLIBC.

ac169 commented 1 year ago

CentOS 7.9.2009 5.4.246-1.el7.elrepo.x86_64 GLIBC_2.17

The method introduced before is that I have verified it myself, and now the application is running on the old version system!

The problem should be on the libwebp library. You use the official libwebp-devel-0.3.0-7.el7 library. I automatically installed the libwebp7-devel-1.0.3-1.el7.remi.x86_64 library from the Remi source in the previous way.

The reason may be that the libwebp library has been installed before installing the vips-devel library

BennyThink commented 1 year ago

Key points:

  1. we need libvips 8.10+
  2. we need libwebp 0.6.0+, required by libvips
  3. we want to support both amd64 and arm64, but remi's repo only supports amd64

I create an experimental repo https://github.com/webp-sh/libvips . It runs on CentOS 7 with ancient version of glibc. However, even if you get the binary built by that system, you'll still need to install libvips on your own system, and its version should be above 8.10.

In conclusion:

  1. we will use CentOS 7 to build binary @n0vad3v , user still need to figure out how to install or build libvips.
  2. it's strongly recommended to run it in docker
n0vad3v commented 1 year ago

We've written a blog post for this: libvips, CGO, and purego: How to Compile and Run Go Applications on different platforms.

bugfest commented 1 year ago

Kudos for the blog post, it's a master piece! Have you considered providing srpm / spec files for these users so they can easily build these required packages?

n0vad3v commented 1 year ago

Glad you like it @bugfest , I think currently we probably aren't going to provide srpm / spec files for them as we want to keep the release simple, so we're going to prioritize support for multi-platform binaries and docker images for now.