Sometimes one can commit a code with some (relatively) sensitive info into a public git repository. Typical first action in such scenario is to do a new commit with sensitive data removed, but one can be slow to remember that public GitHub repository has its commit history visible to everyone so irrespective of new commit with removed sensitive data it is still exposed. Once you realize that you may want to delete repository commit history. Unfortunately this is not something that you can through GitHub UI with one button click, but you can do this using sequence of git commands shown below.
I’m sure there are other scenarios when you may need to use these commands too, so just sharing it here.
Recently it was necessary for me to prepare couple of VMs with CentOS Linux 8 to do some labs/practice, and in this blog post I just want to share my notes about the process/steps involved into creating CentOS 8 VM using Virtual Box.
My base OS is Ubuntu 20.04, so I first needed grab DEB package with the latest version of Oracle Virtual Box from official downloads page. I then grabbed full x86-64 ISO file of CentOS Linux 8 (CentOS-Stream-8-x86_64-20210427-dvd1.iso) from CentOS downloads page to avoid any potential need for extra downloads during installation process.
After installing DEB package I quickly created new VM using the following options:
After creating VM I’ve started mounting CentOS iso file and selecting Install CentOS Linux 8
For my purposes it was OK to accept defaults for almost everything. English US for language settings:
I only changed installation type from default Server with GUI to Minimal Install and further assigned Root Password and configured Installation Destination with default options:
Setting up weak root password (which is OK for test box) requires you to click Done twice:
And for disk option it is OK to just accept defaults:
With all settings in place we just hit begin Installation and wait/taking a coffee break 🙂
It is now only a question of observing installation progress for some time and hitting Reboot System bottom at the very end of the process:
Once installation is over and system is rebooted we need to logon and install updates/make sure we have Internet connection, but if we run yum check-update immediately after logon we will see that VM has no internet access:
As you can see from the output we cannot connect/resolve host name to check for updates, so let’s check network status with nmcli general command:
As you can see interfaces are enabled but we have no connectivity, basically it is because VM didn’t receive IP configuration from DHCHP and running dhclient -v command should resolve that (v flag only indicates that we need detailed output from this command):
After that we can re-run nmcli general – state should change to connected and yum check-update or yum update commands should work just fine:
But what I noticed is that after every reboot of VM network connection was again getting back to disconnected state, although yum check-update / yum update commands were not reporting connectivity errors, checking with nmcli general or with curl -I https://mikerodionov.com was showing that I can’t connect and dchclient command was helping only until next reboot. I checked network-scripts folder and interface configuration file did had BOOTPROTO=dhcp option which supposed to be responsible for use of DHCP at boot stage, but ONBOOT setting was set to no – changing it to yes made connectivity available immediately after reboot.
To edit these settings you can use vi as shown below:
After that the only basic thing you may want to do is to adjust/verify hostname of VM which you can do with hostamectl command as shown below:
With that we have CentOS 8 VM with internet connectivity and updates and at it is good idea to create baseline snapshot of VM at this stage. I guess these notes may come in handy to somebody else, especially final part on network configuration.
This blog post just lists AWS whitepapers recommended per specific AWS exam. You can find AWS whitepapers recommendations on each AWS exam page, but in this post I just tried to aggregate all of them in one place. So in case you want to convert yourself into AWS guru your summer reading list is ready.
Just a quick note on removal of a node(s) from K2 servers farm. When you run K2 uninstall on one of the nodes, and obviously when you suddenly lose one of your nodes (server failure without ability to restore it), information about it still stored in K2 database and additional steps are required in that scenario.
To reiterate, just running K2 uninstall on the node does not remove references to the node from K2 database.
To clear that up there is a stored procedure Server.kClusterDown which removes references to the node you removing from all the relevant tables:
I recently spend some days having fun with good old on premise software and it really makes one appreciate infra as a code and provisioning everything in the cloud, fast. 🙂 The problem is that most of the vendors of on prem software have more focus on introducing their cloud offerings and do not want to invest heavily into improving their on-prem installers to accommodate for myriad of edge-cases even if you have support contract of some sort, and if you don’t, then you some times doomed to fight all sorts of obscure errors which can drive crazy any normal person, except for those who strive to convert oneself to a guru in a very narrow and obscure details of proprietary software combinations… Such type of expertise makes one shine on some rare occasions/in the specific niche but amount of efforts one has to spent learning how to fight small strange problems with obscure solution can be demotivating as it is normally all edge and isolated cases which eat up your time to discover solutions which are often not reusable. Well if in process of fighting those you have time and enough of supporting materials to get understanding of how it all works it is one story (good learning/reusable knowledge), but if you are in a get this thing provisioned ASAP mode then you probably revert to fix it by all means without time to think through why fix was needed and what is the best solution – that’s a bad use of precious time, but sometimes there are no other options. Cloud apps and services has their own share of little problems but really cloud really removes bulk of initial setup and provisioning issues – and if there are real problem with that then it is something that vendor will be willing to fix in the most of the cases. This is because to qualify for being cloud software supposed to offer you on-demand self-service provisioning capabilities which have to work with no human intervention beyond “I’m requesting XYZ” from the consumer side. Anyhow that was a bit of self reflection after setting up mix of software on a demo box which involved K2 5.4, SQL 2019, SharePoint 2019 with someone putting RPA software and Office 365 on the same box in parallel – amount of strange errors was higher than normal this time. So just a little blogpost to take a note of couple of problem/solution pairs in case I will run into this again or someone else will run into those.
One of the errors I got was this one – “We’re sorry, Microsoft Office installer encountered a problem because you have these Click-to-Run installer based Office programs installed on your computer”:
This error basically blocks SharePoint 2019 or SharePoint 2019 installer – you can’t nor install nor repair, so for the first time I did removed Office 365 to do a SharePoint 2019 repair, but later on with eager RPA developer putting Office 365 installation back in no time I decided to search a way to avoid removing Office 365 to run SharePoint 2019 language pack installer. To remove this blocking warning you need to locate your Office installation registry subkey, which for x64 bit can be found under the following path:
Final part/subkey may vary depending on exact Office version you have, and x86 installation entries can be found under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ subkey. So once you located right registry subkey you will need to add RED_DWORD parameter with name SystemComponent and value of 1 (see screenshot below).
That should suppress blocking warning and it worked for me in my test environment. Surely MSFT introduced this blocking warning for a reason and you are free to investigate when it is better to avoid removing that warning and seek other ways of solving this. I would in my case it was TEST/DEV environment where developer need an office right on the server which IMO should be avoided in any type of PROD deployment, so this fix was OK for my scenario.
In addition to the above mentioned error, at the final stages of SharePoint 2019 apps environment set up I run into the problem where all was seemingly configured correctly but K2 for SharePoint app page was giving me 404 or other connectivity errors (depending on bindings configuration), to get to that stage I made use of my old blogost and this script (it seems some of the required service apps can only be added with PowerShell), but somehow in my previous write ups I’ve missed or did not mentioned requirement of putting a wildcard into host value of IIS site created for a web app which hosts app catalog. I was sure that it can work with require SNI and a host name (vaguely remembering that it should not be possible :)), especially after looking at another environment where it indeed works that way, but after resolving this problem by switching to * host and no SNI binding, I realized that other environment had SharePoint Routing Web Application which was responsible for magic of making it all work. My only problem is that I did setup that environment either and now not even remember this part of config.