How-To Update a Docker Container

  I run numerous docker containers and have had need to update them and maintain the original container names.  The follow steps have worked flawlessly and have allowed me to update the containers within a few minutes.

Tailscale & GL.iNet GLAXT1800

 Scenario: Travel VPN Device that has both WiFi and Lan connectivity with the option of using Tailscale configureed to use an exit node from a home network.  The hardware utilized is the GL.iNet (1800 model) for the Wifi repeater.

Hardware and Software:

• Device: GL.iNet GLAXT1800 
• Slate AX is our first Wi-Fi 6 travel router that comes with IPQ6000 1.2GHz quad-core processor. With the latest Wi-Fi 6 technology, you can enjoy more capacity for connected devices and faster wireless speed on the road or at home.
• This is a highly capable and configurable device if you are willing to get into the advanced settings and understand Firewall and Network configuration.  For those that aren't well versed, the Admin GUI should suffice for most situations and is fairly straitforward.
• TailScale: Tagline - Its a Network that Just Works
• TailScale.com

This is not a full review or tutorial on Tailscale or the GL.iNet device.  This is primarily the steps taken to enable tailscale on the GL.iNet device which is considered beta at this writing. Due to the issues I encountered I chose to document the steps I took to make the GL.inet device functional with Tailscale specifically as this use case warranted having a VPN like connection to a home network.  While an SSLVPN may have worked, it was more ideal to use the Tailscale solution so that anyone who connected to the device (wirelessly or hardwired) would be routed as if they were on their home network.  This would also eliminate the need for a traditional paid VPN service like NordVPN, ProtonVPN, PIA, SurfShark, etc, which all work very well.  

One of the requirements of this exercise was to create a connection that would not necessarily be identified as a VPN.  Most traditional VPN's can be detected (if you question that, please feel free to read up on the matter).  

Tailscale has a substantial set of documentation that covers the nuances of their product.  GL.iNet also has a Tailscale "howto" that I'll reference but did not work when trying to configure it to use an "exit node".  Again the tailscale.com website has a wealth of documentation and tutorials to help educate a first time user.

Prerequisites that are not covered:

• GL.iNet device (or similar device.
• Configure Network Mode as a router
• Connect to a local WiFi or Lan and verify connectivity and functionality.
• Upgrade the Firmware.
• Tailscale
• Create an account (free) and setup/configure
• Install client on at least two machines and connect to your account.
• They should be visible in the tailscale admin portal immediately.
• One machine to use for testing the connection and another that will act as an Exit Node.
• On my MacPro and iPhone the configuration took less than 2 min.

• Tailscale.com documents how to install the client on numerous platforms, even your AppleTV. Roku users, sorry no app for you (yet).
• Create an Exit Node.
• This is essentially one of the machines connected to your tailscale account that you then configure as an Exit Point for any traffic from another machine.  AND this machine should be one that you can leave on so that it is accessible as an Exit Node.
• Note:  You must not only setup the client software as an Exit Node, but you also log into the Admin Portal for Tailscale, click the 3 dots on the end of the corresponding device, choose "edit route settings" and then select "use as Exit Node"
• In my experience you can't select this in the admin portal until you've actually configured the client,  on the machine in question" to be an exit node.  The machine will not function as an exit node unless both client and admin portal are set.
• Verify that you have a working account and know how to configure a device to use an "Exit Node".  
• Troubleshooting any issues will be much easier if you have completed these steps and have verified the functionality.
• Configure a device with Tailscale and set it to use your "exit node".  (Critical that you know this is working)

Advanced Steps:

1. Enable tailscale from the Applications section with in the GL.iNet.
• Tailscale Howto https://docs.gl-inet.com/router/en/4/interface_guide/tailscale/
• Note that when you enable it, you still need to "connect" it to your account.  There is link provided that will authenticate and associate the GL.iNet device to your account.  You can easily verify that it is listed in Tailscale portal under "Machines".
• Within the Tailscale Admin Portal, Select the APPROVE the listed routes associated with the GL.iNet device.  They make it easy and have pre populated it.
• Select the 3 dots at the end of the corresponding device.
• Choose "edit route settings" and then check the route box(s) and approve. 
• Once the above steps are complete, go back into the admin console of the GL.iNet device ->Applications -> Tailscale.
• Choose "Use Exit Node"
• Select the corresponding IP address from the drop down list.
• choose apply.

At this Step/Phase of the setup, the GL.iNet device appears to be configured to use Tailscale and the corresponding configuration of the app seems to be done.  However, this is where the extra steps are required for it to be functional. Right now the device is actually connected to the Exit Node but no Client that connects to the GL.iNet will get an internet connection.  

Interestingly enough, if you have enabled SSH and you connect to the device (linux under the covers), you will find that doing a "curl ifconfig.me" will resolve and report back the External IP of the Exit Node device.  You can also ping various IPs and websites.  

**The GL.iNet device itself is working as expected, but no client connected to it is getting routed to/through the Exit Node.  This is why the following steps are required.

• Log into GL.iNet admin 
• Typically 192.168.8.1
• Go to the Advanced Section.


• Follow the link provided for a secondary Advanced Admin Portal 
• Typically 192.168.8.1/cgi-bin/luci
• https://docs.gl-inet.com/router/en/4/interface_guide/advanced_settings/
• Go to Firewall -> WAN ZONE -> Edit -> Advanced Settings (Tab) -> select Tailscale0 from the list of "covered devices"
• there shouldn't be any others selected, but a tailscale0 option should be selectable.
• Save
• on the next screen Save/Apply again.
• Clients connected to the GL.iNet device will now route traffic as expected

This appears to be a common problem, identified over a year ago that I couldn't find much documentation on.  I'm surprised it hasn't been fixed at this point as it is apparently a bug in the configuration.

Wordpress Error - There has been a critical error on this website.

 Two of my sites went down with the following message:

"There has been a critical error on this website"

No other information was given on the page.  Typically this has been an issue with a plug-in and I've just gone into the /wp-content/plugins directory and renamed the plug-ins one at a time to see which one was miss-behaving.  That didn't work this time, nor did moving the current themes directory and only leaving one "default" theme in place.  

What I did find in the logs was this error:

Got error 'PHP message: PHP Fatal error:  Array and string offset access syntax with curly braces is no longer supported

It is my understanding that this is a php compatibility issue going from 7.4 to 8.1.  I don't recall this happening at the time of install and maybe I was running two versions of PHP at that time.

In order to resolve this error I took the following steps and it was successful for my install, which was 6.4. Your results may vary.

From a working 6.5.2 install, I copied a file and one directory to my site.

• Copied the index.php file from /var/www/website/wp-includes/blocks/index.php
• This got the site to come back up, but I could not access the /wp-admin login page.
• Renamed the wp-admin folder and copied the wp-admin folder from the 6.5.2 version.
• This gave me access to my Admin Console and I then initiated a WordPress upgrade.  On one site I had to do a "reinstall 6.5.2" and on the other it just prompted to do an upgrade.  Both sites are now up and fully functional.

Apache2 Config & .htaccess Problems

 While assisting a friend with an OwnCloud install, I found that while the .htaccess file existed, it initially appeared that it wasn't being used.  The web server was essentially allowing access to all folders and files without authentication. 

Overveiw:

• Apache2 w/SSL
• 'AllowOverride All' (was set in apache config)
• .htaccess file was found in the directory with the necessary and expected syntax 
• deny from all
• IndexIgnore *

Resolution:

While there was an 'AllowOverride All' instead of the default 'AllowOverride None' in the Apache config file, and no syntax errors were noted, it was NOT in the correct location for Apache to read it and enable as expected.  It MUST be contained within the <Directory> </Directory> section or one needs to be added.  

Once the syntax in the Apache config file was corrected, the site was secured.

    Example:  

    <Directory /var/www/>

        Options Indexes FollowSymLinks

        AllowOverride All

        Require all granted

   </Directory>