Some time ago I’ve noticed that Skype UI on my Ubuntu machine was insisting on the need to apply updates constantly, and required message was in place in spite of running sudo apt update / sudo apt upgrade. After looking more carefully at sudo apt update output it turned out to be an issue with repository signature:
Exact error message text was the following:
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://repo.skype.com/deb stable InRelease: The following signatures were invalid: EXPKEYSIG 1F3045A5DF7587C3 Skype Linux Client Repository <se-um@microsoft.com>
W: Failed to fetch https://repo.skype.com/deb/dists/stable/InRelease The following signatures were invalid: EXPKEYSIG 1F3045A5DF7587C3 Skype Linux Client Repository <se-um@microsoft.com>
W: Some index files failed to download. They have been ignored, or old ones used instead.
To resolve this problem it is necessary to perform the following steps:
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:
Creating VirtualBox VM – Name and OSCreating VirtualBox VM – Memory SizeCreating VirtualBox VM – Hard diskCreating VirtualBox VM – Hard disk file typeCreating VirtualBox VM – Storage on physical hard diskCreating VirtualBox VM – File location and size
After creating VM I’ve started mounting CentOS iso file and selecting Install CentOS Linux 8
Starting CentOS 8 installation process
For my purposes it was OK to accept defaults for almost everything. English US for language settings:
CentOS 8 installation – 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:
CentOS 8 installation – Installation Summary
Setting up weak root password (which is OK for test box) requires you to click Done twice:
CentOS 8 installation – Root Password
And for disk option it is OK to just accept defaults:
CentOS 8 installation – Installation Destination
With all settings in place we just hit begin Installation and wait/taking a coffee break 🙂
CentOS 8 installation – Installation Summary
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:
yum check-update – no connectivity
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:
Network connection status (nmcli general)
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):
Checking connection status after running dhclient -v
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:
Running yum with working connection
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:
Using vi to edit network configuration scriptsConfiguration with ONBOOT option changed to yes
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:
Changing and viewing hostname
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:
It sets Running=0 for node you want to remove in Server.Server table, and then updates all references to the server ID of the server you want to delete with ID of server which you keep.
You run this stored procedure specifying IDs (note: IDs not sever names) from Server.Server table as a parameters:
@ServerID = NEW SERVERID / ID OF THE SERVER WHICH STAYS IN YOUR FARM @ClusterServerID = OLD SERVERID / ID OF THE SERVER WHICH YOU REMOVE FROM YOUR FARM @ServerDownTimeout = 0
As usual before attempting any direct modifications on K2 system database you should back it up beforehand.
