WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Those who regularly build and rebuild machines or virtual machines on a dhcp network will probably be faced with this quite often, this is due to the known fingerprint for the previous host being different to a new one which has aquired the same IP address.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is c5:ab:00:3c:88:7e:18:8f:46:49:1d:af:f1:8b:4e:98. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /root/.ssh/known_hosts:66 ECDSA host key for 192.168.1.165 has changed and you have requested strict checking. Host key verification failed.

The recent release of the Raspberry Pi 2 uses a newer version of the ARM architecture spec, the ARM Cortex-A7 uses ARMv7 whereas the previous model ARM11 uses ARMv6. The great thing about this is the majority of Linux distros already provide an Image for this architecture. More importantly, Fedora already have images.

There is a slight caveat to the above statement however, that being they won’t just work with the Pi 2. The process isn’t that difficult either just a few steps:

Monit is an application I’ve been meaning to setup for a while, I was first made aware of it from a chap I had the pleasure of talking to at OggCamp this year, he seemed to use it to the n’th degree to monitor files and services within docker containers to ensure a development environment was as it should be. This was far more than I really needed, but the monitoring of services definitely caught my attention so I set about installing and configuring. I was pleasantly surprised with the result, and how simple the whole process was.

I’ve been meaning to write this post for some time, but things have been a little hectic recently. That said I really wanted to write something, even if it is a little short, about Barcamp Manchester. The event took place over the weekend of 18th & 19th October and was just a fantastic weekend.

After a fairly decent break from the Barcamp scene, Manchester really came back and did it justice. Set in the fantastic SpacePort building on Lever street which is a meet and workspace, I arrived earlyish on the Saturday morning with fellow members of RossLUG. Carting in my bundle of swag I was shown my table in the main space and setup the Fedora table. As most will know I am a proud ambassador for the Fedora project and more proud of the fact we were able to sponsor the event.

A while ago I put together a post detailing the installation and configuration of 2 hosts running glusterfs, which was then presented as CIFS based storage.

http://jonarcher.info/2014/06/windows-cifs-fileshares-using-glusterfs-ctdb-highly-available-data/

This post gained a bit of interest through the comments and social networks, one of the comments I got was from John Mark Walker suggesting I look at the samba-gluster vfs method instead of mounting the filesystem using fuse (directly access the volume from samba, instead of mounting then presenting). On top of this I’ve also been looking quite a bit at ZFS, whereas previously I had a Linux RAID as the base filesystem. So here is a slightly different approach to my previous post.

I decided to try the upgrade process from EL 6 to 7 on the servers I used in my previous blog post “Windows (CIFS) fileshares using GlusterFS and CTDB for Highly available data”

Following the instructions here I found the process fairly painless. However there were 1 or two little niggles which caused various issues which I will detail here.

The servers were minimal CentOS 6.5 installs, with Gluster volumes shared via CTDB. The extra packages installed had mostly come from the EPEL or Glusterfs repositories, and I believe this is where the issues arise - third party repositories.

This tutorial will walk through the setup and configuration of GlusterFS and CTDB to provide highly available file storage via CIFS. GlusterFS is used to replicate data between multiple servers. CTDB provides highly available CIFS/Samba functionality.

Prerequisites:

2 servers (virtual or physical) with RHEL 6 or derivative (CentOS, Scientific Linux). When installing create a partition for root of around 16Gb, but leave a large amount of disk space available for the shared data (you can add this in the installer but ensure the partition type is XFS and that the mountpoint is /gluster/bricks/data1) Once you have an installed system, ensure networking is configured and running, in this example the two servers will be:

A while ago I built a Raspberry Pi based nature camera, sometimes known as a trail camera. Normally I cover most of my projects on here but this one has been a little different as it was featured in this months Linux Voice magazine. For this very reason I won’t feature a write-up here, just a few images and videos captured using it and a couple of pointers to the software used in the project.

Gone are the days where we install nslookup for DNS resolution testing, the new(ish) kid on the block is dig. Although maybe not installed by default, it can be installed quite easily from yum, however it comes bundled with a number of tools so the package name isn’t all that obvious.

[root@server ~]# yum install bind-utils

Will do the trick, now how to use it?

[root@server ~]# dig @nameserver address.com