Tag: ubuntu

Posted on

Rancher RKE Kubernetes install notes

Rancher’s RKE is a Kubernetes cluster installer – see more here.

Pre-reqs:

  • Docker must be running on the client machine where you are going to run the rke setup tool
  • The docs are not obvious, but the rke tool is run on a client machine to provision your cluster, it is not run on any of the target cluster nodes 

Notes using Ubuntu 16.04 server.

Remove prior Docker installs:

sudo apt-get remove docker docker-engine docker.io

Create docker group and add user to docker group:

sudo groupadd docker
usermod -aG docker <user_name>

Install per Docker CE install steps here, or use the Rancher provider install script here. 

Supported Docker versions for RKE (as of Dec 2018) are: 1.11.x 1.12.x 1.13.x 17.03.x

Configure Docker daemon to listen for incoming requests on 2376, as per steps here.

Using ‘rke config’ with the default/minimal cluster.yml here, and then install/setup with ‘rke up’

If you didn’t change the name of the cluster.yml file, after the install is complete, you’ll have a kube_config_cluster.yml file in the same dir which you can use with kubectl to interact with you cluster, or add it into your existing ~/.kube/config file

Posted on

Checking iptables filtering for bridge networking on Ubuntu (for Kubernetes setup)

If you’re installing and configuring a Kubernetes cluster on bare metal or in a VM yourself, one of the install steps using kubeadm says to check iptables filtering for bridge networking, but it doesn’t exactly say how to do this per distro.

The setting required is:

net.bridge.bridge-nf-call-iptables=1

There are specific steps in the kubadm docs above for RHEL/CentOS to add this setting. For Ubuntu it seems this is set by default, but you can confirm by:

sysctl net.bridge.bridge-nf-call-iptables

and the expected setting is 1:

net.bridge.bridge-nf-call-iptables = 1

It seems on Ubuntu 16.04 server this is set to 1 by default, but if it’s 0, you can edit this property in /etc/sysctl.conf

Posted on

Increasing VMware ESXi guest desktop resolution for Ubuntu 14.04

By default, my Ubuntu 14.04 desktop guest running under VMware ESXi has a maximum resolution of 1360×768 when accessed with the Remote Client, which although usable is not great on my MacBook Pro:

In the guest settings for my Ubuntu guest, I have rather limited graphics settings:

I tried bumping up the memory and see if that opens up some additional settings but that didn’t change anything, although for higher resolutions it’s most likely I would need more gpu memory, but that’s not the issue with the limited settings here.

Searching for ‘ESXi linux guest maximum resolution’ I found this article:

https://communities.vmware.com/thread/527747

which suggests to install a ‘desktop’ version of the open-vm-tools:

sudo apt-get install open-vm-tools-desktop

Let’s try that. After a reboot, now we’ve got higher resolutions! Awesome!

Posted on

Local Jira server install: Unable to search: “An unknown error occurred while trying to performa search”

On starting up my VM where I have Jira installed, all my logged issues are not displaying, and there’s errors about searching and indexing:

On the Admin / Advanced / Indexing page it shows:

This page on search and indexing issues and a number of other pages and articles talk about deleting the temp Lucene index and cache files, but the docs and other posts miss the important part of stating where these files are.

This page gives a good overview of the file structure of Jira, but doesn’t talk about the Lucene indexes.

This page talks about deleting the Lucene indexed at $JIRA_HOME/caches/ but doesn’t say where $JIRA_HOME points to. It isn’t the /opt/atlassian/jira directory structure mentioned by the previous article, but there isn’t a caches there or anywhere below that directory.

Not knowing where else to look, I just did a find from the root for ‘caches’ and found the location elsewhere here:

$ sudo find . -type d -name caches

./var/atlassian/application-data/jira/caches

Ok. Stopping my server with

sudo /etc/init.d/jira stop

and then moving the caches/indexes folder to indexes-old, retstarting Jira with:

sudo /etc/init.d/jira start

and now there’s a new error about Lucene:

Ok. Clicking the Find out More link shows the results of this health check:

Clicking the How do I resolve this link takes you to this page, which suggests to do a re-index, which is from the Admin / Advanced / Indexing page and where I got the second error originally. Going back there and trying the ‘lock and re-index’ option which was recommended in some of the other index related issus posts:

I then got this:

Ok, no errors! Let’s see if my logged issues are back.

They’re back! Now I’m back in business!

 

Proudly powered by WordPress