apt get life

Docker WordPress Increase PHP Max File Size

2020/07/21 by sudo 1 Comment

I’ve recently been working with WordPress inside docker containers and discovered that file uploads are limited to 2MB, the apache default when using the official WordPress docker image. I don’t know of any sites that I’ve worked on that can actually work with only 2MB (possibly that is an indication of how abused WordPress is to turn it into something beyond a simple blogging platform). This brief guide provides you with one possible way of increasing the WordPress maximum file upload size in docker.

Firstly, create an uploads.ini file, content is defined below

upload_max_filesize = 16M
post_max_size = 16M

Now either mount the file using volumes in docker, or using docker compose. Below is an example except using docker-compose

wordpress:
  image: wordpress:latest
  ports:
    - "80:80"
  volumes:
    - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
    - ./wp-content:/var/www/html/wp-content/

Injecting inbound request headers with Traefik v2

2020/06/30 by sudo Leave a Comment

I’m using Traefik v2.2 as a reverse proxy for my docker containers. Basically all HTTP or HTTPS traffic is handled by Traefik as an ingress container and then routing according to rules defined in my docker-compose file to the appropriate internal container.

Something that I’ve needed to do for a project is add a header to an inbound request in order to identify that the request has been processed by traefik. I tried to follow the documentation but found it… lacking. For anyone interested in the official documentation for adding headers to Traefik you can find it here: https://docs.traefik.io/middlewares/headers/

What I’ve ended up with is a service container (nginx in my case) that looks like this:

nginx:
        image: nginx:stable-alpine
        volumes:
            - ./src:/var/www
            - ./.docker/nginx/default.conf:/etc/nginx/conf.d/default.conf
        labels:
            - "traefik.enable=true"
            - "traefik.http.routers.router1.rule=Host(`localhost`)"
            - "traefik.http.middlewares.testHeader.headers.customrequestheaders.test-header=new-header"
            - "traefik.http.routers.router1.middlewares=testHeader"
    php:
        image: php:7.4-fpm
        volumes:
            - ./src:/var/www

Now something that threw me was the header “test_header” doesn’t exist in requests handled by nginx. A linked PHP container simply running print_r($_SERVER) dumps all the variables to the page. It’s only at this point I discovered that Traefik adds HTTP_ to the header. So instead of :

test-header = new-header

you get:

HTTP_TEST_HEADER = new-header

I think this is one of those things that you can waste alot of time on if you don’t know that Traefik is re-writing the header values in this way.

Looking back at the Traefik configuration, to add a header you basically have two steps:

First, create a new header. This is done in the following format:

traefik.http.middlewares.{your header group name}.headers.customrequestheaders.{header key}={header value}

As an example:

- "traefik.http.middlewares.testHeader.headers.customrequestheaders.test-header=new-header"

This creates a header `HTTP_TEST_HEADER` and assigns it to the `testHeader` middleware group.

Secondly, assign this middleware group to the router you’re using for your service. In my case that’s an nginx container on a router `router1`. This takes the following format:

traefik.http.routers.{router name}.middlewares={middleware name}

As an example:

- "traefik.http.routers.router1.middlewares=testHeader"

If you’re not sure what this looks like in the context of the other containers check the first, more complete example or see the entire docker-compose file below (NOTE: this file exposes the Traefik API for debugging purposes, so don’t blindly deploy it to production):

version: '3'

services:
    proxy:
        image: traefik:v2.2
        command:
            - "--providers.docker=true"
            - "--providers.docker.exposedbydefault=false"
            - "--entrypoints.web.address=:80"
            - "--api.insecure=true"
        ports:
            - "80:80"
            - "8080:8080"
        volumes:
            - "/var/run/docker.sock:/var/run/docker.sock:ro"

    nginx:
        image: nginx:stable-alpine
        volumes:
            - ./src:/var/www
            - ./.docker/nginx/default.conf:/etc/nginx/conf.d/default.conf
        labels:
            - "traefik.enable=true"
            - "traefik.http.routers.router1.rule=Host(`localhost`)"
            - "traefik.http.middlewares.testHeader.headers.customrequestheaders.test-header=new-header"
            - "traefik.http.routers.router1.middlewares=testHeader"
            - "traefik.http.middlewares.test-ratelimit.ratelimit.average=1"
            - "traefik.http.middlewares.test-ratelimit.ratelimit.period=1m"

    php:
        image: php:7.4-fpm
        volumes:
            - ./src:/var/www

Setting up Display Link drivers on Ubuntu 20.04

2020/06/23 by sudo Leave a Comment

I’ve purchased a Dell “universal” USB 3/USB C docking station featuring Display Link, essentially allowing you to use it to drive external displays with the intention of using it for my laptop when sat at a desk with external monitor, mouse and keyboard. Since I run Ubuntu or Linux Mint as my primary operating system, some extra steps were required to install the Display Link drivers.

The first thing you need to do is download the Display Link drivers from the official website: https://www.displaylink.com/downloads/ubuntu

Once downloaded, it’s a reasonably straight forward process to install the drivers. First thing that’s required is to install pre-requisites

sudo apt-get install dkms libdrm-dev

Next run the downloaded file replacing the version number with whatever the one you downloaded is. (Note, this command assumes you’re in the appropriate directory already):

sudo ./displaylink-driver-5.3.1.34.run

Once finished you should have a message asking if you are running xorg and if you want to reboot. It’s actually best to reboot regardless of your display driver, so select Y for yes and let your machine reboot. Then you should be able to plug in your USB dock and your external devices with them all working.

For more information, the Display Link website actually has some good resources. Checkout their Ubuntu setup guide here: https://support.displaylink.com/knowledgebase/articles/684649

Setting up a bond and a bridge in Netplan on Ubuntu Server 20.04

2020/06/03 by sudo 1 Comment

I’m in the process of updating my KVM servers from Ubuntu 18.04 to Ubuntu 20.04. Along with the new version of Ubuntu there’s been some changes in netplan.

What I’ve done is edit the default file created after the Ubuntu Server installation /etc/netplan/00-installer-config.yaml and setup the following:

network:
  bonds:
    bond0:
      interfaces:
      - eno1
      - eno2
      parameters:
        mode: active-backup
  ethernets:
    eno1: {}
    eno2: {}
  version: 2
  bridges:
    br0:
      dhcp4: true
      interfaces:
        - bond0
      mtu: 1500
      parameters:
        stp: false
        forward-delay: 4

This has my two interfaces eno1 and eno2 and created bond0 as an active backup. There’s a few different networking modes you can chose from:

Bond Mode	Description
balance-rr	Round robin network configuration. Packets are send in sequential order from the first connection listed, going down the chain
active-backup	Only the first connection is used, unless it fails, in which case another connection is used
balance-xor	This uses a transmission policy to route between interfaces and provides both load balancing and fault tolerance
broadcast	Not sure why you’d use this – sends data on all interfaces
802.3ad	This is an IEEE standard. It does require switches to support the same protocol. This mode aggregates the connection to provide the benefit of bandwidth from all configured interfaces.
balance-tlb	Manages load between the the network adapters based on demand and availability
balance-alb	Includes both transmission load balancing (balance-tlb) and receive load balancing.

Then, the bridge br0 connects to bond0. This is where you configure the network type – DHCP or static IP. In this case I’m using DHCP as the firewall I have in place manages IP address assignments and it has the server set to a static address. If you want to specify a static IP address in this configuration file, you can do it like below:

network:
  bonds:
    bond0:
      interfaces:
      - eno1
      - eno2
      parameters:
        mode: active-backup
  ethernets:
    eno1: {}
    eno2: {}
  version: 2
  bridges:
    br0:
      addresses:
        - 192.168.10.30/24
      dhcp4: false
      gateway4: 192.168.10.1
      nameservers:
        addresses:
          - 192.168.10.1
          - 192.168.10.2
        search: []
      interfaces:
        - bond0

You can find out more information here:
https://netplan.io/examples

There’s a version of this post for 18.04 here (see the comments with suggested fixes):
https://www.aptgetlife.co.uk/setting-up-a-bond-and-bridge-in-netplan-on-ubuntu-18-04/

Iiyama 34″ IPS Ultra-Wide Monitor XUB3493WQSU Review

2020/04/26 by sudo Leave a Comment

The Iiyama XUB3493WQSU is a low cost, reasonable quality IPS screen with a few minor issues that shouldn’t detract from the ultrawide experience. If you’re looking for a good quality, budget ultrawide, this should be near the top of your list!

Background

Ultrawide monitors. They’re the current “big thing” in the monitor industry, with big brands producing 49″ super ultrawides. Much as I’d like to own such screens, I really don’t have that kind of money (or space)! So I spent many months investigating ultrawide monitors with just a few specifications:

It must have an IPS panel, in my mind they’re generally superior in terms of colour and quality
It must be at least 34″ in size, otherwise it’s smaller than my current work monitor I’d be replacing it with
It must be at least 3440 by 1440, again to make it practical as a replacement
It must be flicker free. I’m really sensitive to some types of light flickering; they give me migraines
Ideally, it shouldn’t make me regret the purchase too much afterwards! (because money).

After dreaming of a number of the LG utltrawides for some time, but not being able to justify £700+ for a screen, I discovered the Iiyama 34″ XUB3493WQSU, an IPS panel with flicker free technology. I have to admit, when I found this I thought it was too good to be true and passed it by a few times. The listing on Ebuyer and Amazon were not clear about it’s flicker free credentials and there were no reviews of it anywhere online (this has since changed). Having interrogated the Iiyama website about this screen, I decided to give it a go and below are my impressions.

Initial Impressions

I purchased the screen from Ebuyer, a UK based company. They shipped the monitor in its original packaging (no extra box, so that the shipping label was stuck onto the actual Iiyama packaging). It’s large, but as a result is well packaged, with polystyrene cutouts protecting the screen. It comes with a few cables and power lead. It’s reasonably easy to remove from the packaging.

The first thing this screen reminded me of was a Dell Ultrasharp. It’s got a similar bezel to the 2015 models and has a stand that provides some tilt, pivot and height adjustment. Note: there is a sticker on the stand stating that the pivot function is not supported; this makes sense, since the monitor is so wide it can’t really go anywhere!

The size of this monitor does not come across very well in the photos I’ve taken, but it certainly makes an impression of being big!

Iiyama XUB3493WQSU and Dell u2514h from above for size comparison

Iiyama XUB3493WQSU rear input ports

The screen feels well built, as well built as the Dell monitor, which is impressive given they were almost the same price! The stand offers significant height adjustment – a little over 12CM total movement. Pivot and (unsupported) tilt is also quite impressive.

Ultra-Wide, Ultra-Good?

The monitor is really easy to set up (with the slight exception of its sheer size on my desk). I did find my old display port and HDMI cables didn’t work – the screen wouldn’t display anything but black. It’s possible that due to their age they don’t support modern standards used by this monitor. The included cables felt a little cheap, but the monitor worked perfectly after swapping the cables out.

I did find that there’s a lot of light bleed with the screen – something that plagues IPS screens. This is something that’s hopefully visible in the pictures below, notice that the light bleed from the bottom left hand side of the screen is significantly worse than the right hand side.

Iiyama XUB3493WQSU light bleed right hand side

Iiyama XUB3493WQSU light bleed left hand side

Iiyama XUB3493WQSU running Tomb Raider benchmark

Iiyama XUB3493WQSU running Orville simulator

As you can hopefully make out the Tomb Raider screen is darker and shows a lot more light bleed than a brighter screen as seen in the Orville simulator. If this is the kind of thing that bothers you, then re-consider buying this screen! I actually find that it’s not too noticeable when properly engaged in a game.

The actual game play on this screen is reasonably good (coming from the Dell u2514h, which is not a gaming monitor in itself). I did get some screen tearing, but my graphics card is a reasonably (7 years) old Nvidia Zotac 770 so it can’t take advantage of the freesync support this monitor provides. I would suggest getting a better graphics card than I have for any reasonable game players out there! It’s okay for older games such as counter strike source, but the newer Tomb Raider games really struggle (as you may have noticed from my 17 frames per second). Game play is actually surprisingly immersive, I cannot describe the experience, but once you’ve used an ultrawide you likely won’t want to go back!

Working on the screen is reasonably easy to do, and I can comfortably have a Libre Office Writer and Firefox window open side by side at the same time. It’s also reasonably good for coding, although I would say that a two or three screen setup is better supported with window snapping than the single display. This is important if you code like I do with about 5 different windows in active use! The text is clear and sharp, really to the extent that I would say it is the same as the Dell Ultrasharp.

The main problems with the Iiyama XUB3493WQSU are reasonably supervicial. First is of course the light bleed. It’s an IPS screen and to some extent you need to live with it. My next biggest complaint is the delay both in turning on and switching inputs. The input switch lag is crazy; we’re not talking a couple of seconds, it’s more like 8! There’s a lot of hesitation in the monitor when using the input buttons as well and the menu can be almost impossible to use. Once you’ve got the monitor configured as you want I would advise never touching the input buttons again for fear of messing something up and getting stuck in the menu somewhere! One last complaint is there’s a noticeable polarization effect on the left and right hand edge of the screen. I couldn’t get a good picture of this, but I’ve noticed that with a scroll bar for a web browser on the right hand side, I sometimes have to move my head to the left to stop the polarizing filter from “hiding” it behind blackness.

Overall, I think this screen has ticked all the boxes for me. I really like it. I like using lots of windows at once and my work layout is actually far easier to make dynamic based on activity with the extra real-estate to play with. I think it’s pitfalls are worth putting up with given the value of the screen, especially if you’re after an ultrawide!

Note: it does have picture in picture for multiple inputs at the same time, but I haven’t really used this feature. Given the clumsy on screen menu input, I’ve set the monitor up how I wanted it and then dared not touch it again!

Share this:

Share this:

Share this:

Share this:

Background

Initial Impressions

Ultra-Wide, Ultra-Good?

Share this: