In recent versions of K2 installer team introduced a feature which blocks installation in case of critical failure leaving you no choice but address the issue and perform repair. It basically blocks all the other options leaving you with Recover as an only available option as shown below:
This option is here for a reason and unless you 100% sure that you need to exit out of this mode you should analyze error and perform repair, if necessary involving vendor support. But in case of throw away test box or initial installation you may want to unblock all the other option, let’s say to perform removal and start from scratch. To do that you just need to delete contents of the Setup State folder (default location is “C:\Program Files\K2\Setup\State”) which in this case will contain json files with the state of failed installation. Those files contain sections like “ComponentActions”, “FailedTarget”, “CompletedTargets”, but to the best of my knowledge support will ask you for installer trace to investigate any type of installer failures.
Like I said in case you understand what you are doing and need to exit out of “Recover” mode you can just use folder clear up approach explained above.
I’ve recently updated macOS Big Sur to version 11.2.2, and it seems that after this update I run into issues with running my Python programs from PyCharm, which started to give me the following error on attempt to execute any program:
Error running 'P3-2': Cannot run program "/Users/User_Name/PycharmProjects/Project_Name/venv/bin/python" (in directory "/Users/User_Name/PycharmProjects/Project_Name"): error=2, No such file or directory
I’ve looked into relevant venv directory which contained symbolic link to Python executable which, in turn, by the looks of it in Finder, was broken (path/target cannot be found). I found that strange as Python 3 was installed and working for quite some time, so I tried to run python3 from terminal and saw the following error:
Recently it was necessary for me to enable XRDP service on Ubuntu 20.04 VM, so I followed the steps outlined in one of my old posts and get it working quickly. Unfortunately I run into some new issue with not being able to reset or shutdown Hyper-V VM for some reason, which I ignored for now, but after couple of power offs I realized that I cannot connect via XRDP until I open session locally. I then decided to check on the service status with sudo systemctl status xrdp command and got the output shown below:
Full error message says: [ERROR] Cannot read private key file /etc/xrdp/key.pem and I’m pretty sure that it didn’t show up when I used the same status command after initial configuration, though people tend to forget and miss things 🙂
Anyhow to clear up this the following command has to be executed:
sudo adduser xrdp ssl-cert
Abovementioned error occurs when the default user for XRDP’s service lacks access to the directory to which /etc/xrdp links, and with the command above you allow the user xrdp access through ssl-cert group membership. I hope that this information may come in handy to some one else 🙂
I’ve recently migrated this blog to Amazon Lightsail along with moving some of my domains to AWS Route 53. Since I’ve started this blog I had it hosted in different places – Synolgy NAS device at my home, SiteGround, Gandhi… As I recently dived into AWS certifications it gave me extra incentive to use and explore AWS services and in course of preparation for AWS Certified Cloud Practitioner I had to look at Amazon Lightsail and realized that that was exactly I was looking for while struggling with excessive complexity and enterprise level pricing of AWS service offering.
Amazon Lightsail intended use case is to offer AWS for developers who need to start quickly and have no expertise nor desire to deal with complexity and plethora of functions of standard AWS service offering which can scare away any newcomer by sheer number of services and additional features. So for AWS exams test takers this service shows up only in scenarios where they ask you which service you need to recommend for developers who don’t have AWS expertise or any advanced AWS features. So it is kind of “AWS made easy”.
I was not following AWS offering to closely, as I worked for MSFT-house company where everything was run either with on-premise MSFT stack or with Azure with a tiny bit of exposure/use of AWS stack, so I’ve missed this service, which was announced back in 2016, until I stumbled on it while preparing to AWS exams.
Actually to name things properly Lightsail is, basically VPS offering from AWS, and it features its own, separate, management console which will look somewhat familiar to you if worked with DigitalOcean or Linode:
But as you can imagine this VPS offering powered by ginormous and battletested AWS infrastructure which ensures that console is super streamlined and responsive, instances can be provisioned in just a few clicks and, no surprises there, price tag is very good, and not only if compared against running the same workload using EC2 or Elastic Beanstalk. IMO pricing is compelling enough to consider migration from other VPS services (especially if you have just small/individual instances scattered across different VPS providers). I guess after migrating my blog to Lightsail, I’ll soon be migrating my Django app VPS which so far is hosted on DigitalOcean.
Just a few notes on WordPress migration experience. I don’t have time to write comprehensive step by step guide, so I just jot down some points / steps I did:
I’ve created Amazon Lightsail WordPresss 5.6.0 instance (WordPress Certified by Bitnami and Automattic 5.6.0) with desired specs (instance plan) and assigned a static IP to it.
For migration itself I used All-in-One WP Migration plugin which allows you to download your WordPress blog as a single file and later on import it to a newly created WordPress blog on your new server.
Main problem which blocks some people to do migrations with this plugin is a default 40 MB upload limit which some people try to resolve through installing different versions of plugin. Actually all you need to do is to connect to your VPS instance and adjust PHP File Upload Limit in php.ini file (see some details on how to do this here) but it is basically as simple as running sudo nano/opt/bitnami/php/etc/php.ini command and increasing post_max_filesize and upload_max_filesize settings and restarting services with sudo /opt/bitnami/ctlscript.sh restart command. After that you should be able increased limit value in plugin UI.
I’ve also migrated my domain names to Route 53 and for WordPress domains all you need to do is create a hosted zone for domain and next create A record which will resolve domain name into Lightsail instance static IP along with CNAME record which translated www.domain.com into domain.com (be sure to also update name servers to AWS ones in case you did domain transfer).
I was a little bit confused as to whether it is possible to use Route 53 SSL certificate for Lightsail WordPress instance (it didn’t work for me after first attempt) so I end up using Bitnami bncert-tool to provision SSL certificate from Let’s Encrypt for my instance. Some details on how to do that can be found here and here.
Another little adjustment I did is removal of Bitnami banner. which can be done by running sudo /opt/bitnami/apache2/bnconfig –disable_banner 1 and restarting Apache with sudo /opt/bitnami/ctlscript.sh restart apache command.
There were probably some other minor config changes I did, but all in all migration was fast and easy and it seems that my blog become a bit more responsive now, and if I need to improve its performance I still can leverage Lightsail CDN and load balancing features.
One confusing thing about AWS services is their naming prefix – some of the services names are prefixed with Amazon and other with AWS, and while Lightsail tries to be a bit differentiated from all the other AWS services, and it is natural to call it Amazon Lightsail and not an AWS Lightsail because of that, I see that all the other AWS services are prefixed either with “Amazon” or with “AWS” without any apparent logic. But for a company with 175 services portfolio naming system is more than OK, as I saw much more confusing and disorganized naming employed by a vendors with less than 10 products or services 🙂 Luckily enough cloud services do not get that major/minor versioning in their names which sometimes gets too creative for on-premise products where version plays an important role of vehicle to wrap up certain number of features into it and make a “new product” which client supposed to buy/or upgrade to. I guess in that interim period between “boxed”/COTS/buy once software and cloud/SaaS that recurring major version concept went too far in attempt to ensure recurring revenue for software vendors 🙂
So that was just an announcement of this blog hosting change along with a few notes on WordPress migration process and Lightsail in general, I hope that it may come in handy/interesting for some of my blog readers too.