Introduction

Having the ability to run a Kernel Basd Virtual Machine (KVM) on a hosted solution is a luxury you won’t easily find on most cloud providers (Amazon, Google, Azure). On my hosting provider, I can get a quad core i7 32gb RAM server for less than 70 euros / month, a fraction of the cost that you would pay with a cloud provider.

I tought it might be interesting to see what kind of virtualization options I had on Centos and stumbled upon KVM, LibVRT and Qemu.

Introduction

In this post we’ll be looking at several ways to use NiFi to interact with HTTP resources, both from a client and from a server perspective.

Nifi comes with a set of core processors allowing you to interact with filesystems, MQTT brokers, Hadoop filesystems, Kafka, ……. It also comes bundled with a set of HTTP processors that you can use to either expose or consume HTTP based resources.

We’ll be looking at the following processors that ship with Nifi:

For each processor we’re going to take a closer look at

  • Flow definition (how a typical NiFi flow would look like with this processor)
  • Processor configuration (how the processor can be configured)
  • Scheduling (how the processor is scheduled)
  • Data flow (how the data flows within the flow)
  • Thoughts and use-cases

Introduction

This is a small tip on getting your networking service up and running in Centos.

If you’ve ever wondered why you’re not getting an IP address on your CentOS VM in VirtualBox, even with the Bridged network adapter, then look no further….

Notice how you’re not getting an IP on the main enp0s3 interface.

[root@localhost ~]# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:db:6f:94 brd ff:ff:ff:ff:ff:ff

Introduction

I’m sure most of you have experienced this scenario : A server is put online, and although you’ve secured it properly, you still see people attempting to brute force attack your server by attempting to login via SSH.

sshd[25808]: input_userauth_request: invalid user ubnt [preauth]
sshd[25808]: Received disconnect from 91.224.161.103: 11:  [preauth]
sshd[25810]: Invalid user test from 91.224.161.103
sshd[25810]: input_userauth_request: invalid user test [preauth]
sshd[25810]: Received disconnect from 91.224.161.103: 11:  [preauth]
sshd[25812]: Invalid user tech from 91.224.161.103
sshd[25812]: input_userauth_request: invalid user tech [preauth]
sshd[25812]: Received disconnect from 91.224.161.103: 11:  [preauth]
sshd[25814]: Received disconnect from 91.224.161.103: 11:  [preauth]

Although you’ve setup your server to only allow SSH key based authentication (and as such nobody can login with a password), people are still trying to find their way in. You can dramatically recude these number of attacks by switching your SSH daeon to a non standard port.

In this post, I’ll show you how to change that port,

Introduction

Another attempt at creating a blog :)