Tag Archives: virtual machines

SALT: PILLARS & GRAINS

GOAL:

Use Salt pillars & grains.
Setup Salt master – minion

Time elapsed: approx 3h.

SETUP:

Three virtual machines.
VM1: Running Mint 17.2, Salt master || specs
VM2: Running Mint 17.2, Salt minion
VM3: Running Mint 17.2, Salt minion

All VMs are set to bridged connections.

INSTALLING SALT

VM1

This is the same machine I used in the previous article. Salt is already installed. Here’s how the machine is configured: last article

I only uninstalled the Salt minion from this machine using the command:

sudo apt-get remove salt-minion

 

VM1 & VM2

For the slaves, I installed Salt using the same steps as used in the last article:

First I imported the SaltStack repository key

wget https://repo.saltstack.com/apt/ubuntu/ubuntu14/latest/SALTSTACK-GPG-KEY.pub | sudoapt-key add SALTSTACK-GPG-KEY.pub

Opened the sources list

sudoedit /etc/apt/sources.list

I Added the following line to the list:

deb http://repo.saltstack.com/apt/ubuntu/ubuntu14/latest trusty main

Next I ran apt-get update

sudo apt-get update

Installed only minion and SSH -components for the minions.

sudo apt-get install salt-minion salt-ssh

And there, installation completed!

Before proceeding I checked the installation status by running

$ sudo salt-call --version

Capture5

Capture4

SETTING UP SALT MASTER AND MINIONS

I started setting up my master and minions following the walk-through in doc.saltstack. 

First I started the salt master -service.

sudo service salt-master start

Capture6

For the minion – master needs to be defined. So I added my master VMs IP to the minions /etc/salt/minion -file.
Capture7

I started the minion with

sudo salt-minion -d

This will generate a minion id, which will be stored in /etc/salt/ as shown in the pictures bellow

Capture8 Capture9

Now when I ran sudo salt-key -L on the master VM:
Capture10

I accepted the pending key with

sudo salt-key -A

And ran the sudo salt-key -L again:
Capture11

Capture12

I verified that the keys do match by running salt-key -F master on the master VM and salt-call key.finger --local on the minion VM.
Capture13Capture14

I verified that the master can ping the minion by running the test.ping command:
Capture15

Yay! The master can now start sending command to the minion! Installation successful!

Grains

I want to make my slaves run a website that states their basic info, such as IP, hostname, role.. etc. To test this out I will do this on the VM1. I will create a new state, that will install Apache and define a template engine for the website. In the template, I will create a simple webpage, that will fetch the grains.

First I begin with checking what kind on grains I can actually utilize on my minion machines.

$ sudo salt-call --local grains.items

This command returns a huge list of grains that can be utilized. I’m interested in the “host” and “ip4_interfaces” -grains.
Capture1

To make the state, I first created a new folder for it and called it “status”

$ sudo mkdir /srv/salt/status

Inside the folder I created a new sls. -file and called it “init.sls”.

$ sudoedit init.sls

First I used #!pyobjects to install Apache and define the template engine:

#!pyobjects

with Pkg.installed("apache2")
File.managed("/var/www/html/index.html",
source="salt://status/index.html.jinja", template="jinja")

I tested if my state works:

$ sudo salt-call --local state.sls status

Capture2

Next I wrote the template file.

 

Hostname: {{ grains['host']}}
IP: {{ grains['ip4_interfaces']}
MAC: {{ grains['hwaddr_interfaces']}}

Then, I ran the state again and opened http://localhost in Firefox.

Capture3

Worked as expected, with minor formatting flaws.

 

PILLARS

I created a basic pillar following the doc.saltstack walk-through.

So first I created a directory for the pillars in /srv/

sudo mkdir /srv/pillar

And in the pillar-directory I created the top.sls -file.

sudoedit /srv/pillar/top.sls

And in the top.sls file, I just created a very simple file to test the pillar.

base:
'*':
- info

After this I created the info.sls -file and added some data into it.

info: testing pillar

Now that the test pillar files are created, I tested them out using these commands:

sudo salt '*' saltutils.refresh_pillar

sudo salt '*' pillar.items

Getting these results:
Capture16

Basic pillar test completed, worked without problems.

  • Copying, modifying and redistributing this and all the other documents in this blog is allowed according to the GNU General Public License (versio 2 or newer).http://www.gnu.org/licenses/gpl.html
  • Based on the Linux course by Tero Karvinen 2015: terokarvinen.com
Advertisements

SAMBA SERVER SETUP IN VIRTUAL NETWORK || ASSIGNMENT

The platform for this assignment varies a little. It was started at the campus using a comp with these specs, and carried on with my home PC.
The virtual environment, i.e. the virtual machines were exported and imported to a USB-stick, which allowed the handy usage of the virtual machine(s).

THE ASSIGNMENT:

  • Install a new machine, running Ubuntu Server, to the virtual environment. Install the Samba server and the SSH-server to this machine.
  • Install a new machine, running Windows 7, to the virtual environment.
    (unfortunately I was unable to transfer the Windows machine within the USB-stick, the time it took to export this machine was measured in hours, and I really did not have the time or the patience to wait for this.)
  • Using the Ubuntu Server Guide and the Samba-HOWTO-collection, test and configure the Samba server. Do not setup a printing server, only the file server.
  • Setup disk quotas for the users, i.e. give them Samba -server accounts.

Step 1. Installing the new machine

Firstly, I installed the new Ubuntu Server machine. During installation I selected the Samba server and Open-SSH server to be included in the installation. After the installation was completed I proceeded in configuring the Samba server.

I also installed a new Linux desktop to the environment, running Kubuntu 14.04 LTS, to kind of replace the Windows desktop.

Step 2. Configuring the Samba server

Telling Samba what to do is rather simple. The configurations will change during the setup progress, since I’m proceeding in a step by step manner.

First we need to edit some key/value pairs in the Samba-configuration file. It can be accessed using this command:

sudo nano /etc/samba/smb.conf

Here we will want to look into the [global] -section first. We will need to give our workgroup a name, and give a basic security declaration. My conf-file’s [global] looks like this: globalconf

Next I created a new section to the bottom of the conf-file called “[share]”. This section will define the sharing policies of the file server. You might want to add these lines to it:

[share]
comment = Samba File Server #just a friendly reminder
path = /srv/samba/share #we will create this later
browsable = yes
guest only = yes
read only = no
create mask = 0755

My section looks similar to the one above:
sambashare

Now Samba is configured.

We will now need to create the shared directory, so run these command:

sudo mkdir -p /srv/samba/share
sudo chown exmpl.nogrp /srv/samba/share/

Samba needs to be restarted in order for the configurations to apply:

sudo restart smbd
sudo restart nmbd

You can also run a command “testparm” to check if the configuration file syntax is correct.

testparm

There you go. Local network configuration is done!
Your machines in your local network should now detect the Samba file server.

Step 2. Detecting the server

This really isn’t a step at all. Just log into one of your desktops, also connected to the internal network and go check the “Network” (if debian) folder.
kubuntu1
In my Kubuntu, I could find the “Samba Shares” folder without any further configurations. Clicked it and:
kubuntu2
I can find a few shared networks here, since other people were doing the same stuff in the same network. I could find my network “Example.lan” on the top.
kubuntu3
Two folders here, “data” and “share”. We just created the “share” folder. And I also made a text-file there on the server machine, for testing purposes.
kubuntu4
Looks like it works!

If you have problems accessing the folders, you might not have permission to them. Try checking the [share] settings. If that doesn’t work, try using chmod to see if the problem is there.

sudo chmod -c -rwxrwxrwx /share

This of course is not very good considering data security, but we just want to see if this is the problem.

Step 3. Users

Users need both accounts on the server and accounts in Samba. So create the users into your server machine. After that let’s make them in Samba as well.

Users are already created in the server, they are valid Samba users. So we only need to give them Samba specific passwords. That is done with the command:

sudo smbpasswd -a user

This how it will look in the terminal:
sambaa
As we can see here, Samba really doesn’t appreciate my security settings. I also ran into this while checking the Samba status with:

smbstatus

Now this is how it looked. (the server is not working properly yet, we’re on it)
smbstatuserrro

I brute forced this error out, no one likes error:
sharefixstatus
Messy work around, but it does the job for now. The status looks much better now too:
fixederror

Let’s see if we can log into our Samba server.
Root login:
lookmomidiit

sudo smbclient //172.28.9.225/share

If you want to log in with a account is is done with this command:

smbclient //172.28.9.225/share U-usrname/pw

artopäässisää

Server status

We can check the server status using this command:

smbclient -l samba -u%

sambastatus-u

Looks alright.

The users have now been created and the server configured. The next step is to mess around with disk quotas.

Step 4. Disk quotas

Let’s set up disk quotas for our users.  Install the software using this command:

sudo apt-get install quota

After installation take a copy of the conf -file located: /etc/fstab. After open the conf -file.

sudo nano /etc/fstab

By default the file looks as follows:
quotadefautl
Add ,usrquota after the errors=remount,ro -part. Don’t remove anything. This file is extremely picky with the syntax.
The modified file will look something like this:
quotamod

Run a remount to apply the settings:

sudo mount -o remount /

Now, be sure to have your quota turned off before running the check commands. Execute the commands as follows:

sudo quotaoff /
sudo quotacheck -cum /
sudo quotaon /

Now we can set quotas for our users using the sudo edquota

sudo edquota juhotest

edquota
We can set the usable disk space etc here. Like this:
edquotareals

After we’ve set quotas as wanted we can see if they are applying. Checking for user quotas can be done with the command:

quota userhere

quotacheck

And there we have it!

DHCP & DNS // CREATING A LOCAL NETWORK BETWEEN VIRTUAL MACHINES // ASSIGNMENT III

So, my external hard drive is a brick. To summarise the problem; It just won’t boot. So I am will run this assignment on a Windows desktop, since my laptop is not strong enough to run so many virtual machines at once.

Specs:
Windows 7 Enterprise 64-bit
Intel Core i5-2400 @ 3.10GHz
Some integrated Intel HD graphics GPU
8GB of RAM

Assignment:

Create four virtual machines:

## Machine A: Linux desktop, I’ll be using Mint 17. This machine will receive its network address from the DHCP -server.  Eth0 in the local network (intnet). ## Machine A not used in this post

Machine B: Master, running Ubuntu server. This machine will work as a DHCP – server. Static IP, Eth0 in local network.

Machine C: Bridge, running Ubuntu server. This machine works as a NAT -distributor (If it works..) between the local and public network. Static IP, Eth0 in public network (bridged), Eth1 in local network (intnet).

Machine D: Running Ubuntu server. Receives IP from the DHCP -server. Address reserved before hand using MAC -address. Eth0 in local network. Calling this machine ‘Aku’ on this post.

Step 1.

Creating and installing the virtual machines will be the first step. I begun with installing all the machines using Ubuntu server. I gave them all 512 MB of RAM and 8 GB of space on the hard drive, the desktop client gets a bit more RAM etc, but servers will manage with less.

During the installation, I also installed the OpenSSH -client. Machine B also got the DNS-server package during installation.

Bridged network setting is necessary here, since we still need to access public network, in order to make a few installations here.

Machine C – the bridge, will need two network adapters here. It will work as a gateway to the public network for the other machines. Set Eth0 to public network setting – Bridged, and Eth0 to internal network. Primary network adapter = Eth0.

After setting up Machine C – the bridge, run this command:
ls /sys/class/net/
This should list you the following adapters: eth0, eth1 and lo.

Step 1.2 DHCP-server installation

After the machines are setup, installing the DHCP -server on the master machine is necessary. It can be done with the following command:

sudo apt-get install isc-dhcp-server

Be sure to have bind9 installed before doing this. (sudo apt-get install bind9)

This will install and start the DHCP -server. However, it still needs go through the process of configuration.

After the installation is completed, everything that needs to be installed on this machine has been installed. Now we can change the IP to a static IP.

sudo nano /etc/networks/interfaces

This will open up the configuration file in which you can tweak your IP setting. It will look a bit like this:
Selection_001
You will need to change a few lines in order to make your IP static. Add these changes into the file:

auto eth0
iface eth0 inet static
address 10.5.5.1
netmask 255.255.255.0
network 10.5.5.0
broadcast 10.5.5.255
#dns-nameservers 10.5.5.1

For now, leave the dns-nameservers commented out.
masterinterfaceconf

Save the file and run these commands:

sudo ifdown eth0
sudo ifup eth0

This will apply the changes made and give you a new IP. Now if you run ifconfig your IP should display as 10.5.5.1 – you now have a static IP.

Configuring the /etc/hosts -file might not be necesary, but I’d say do it just to be sure. Capture
We will want to change the IP here to our own static IP and fill in the host’s name – master.

Step 1.2 Gateway//Bridge

Before testing, make sure all your other machines have also got the appropriate IP settings in /etc/network/interfaces:
Capture2
On the bridge machine, we will want to leave the eth0 -setting untouched and make a similar configuration for the eth1 -adapter.
Eth1 – adapter is in the internal network, so we will want to give it static IP and other configurations as seen above.

Remember, for the settings to apply, you will need to run ifdown and ifup -commands.

Step 2. Testing the work done so far

At this point we can test if that the machines can find each other using SSH.
We can start by trying to connect from MASTER —> BRIDGE

ssh juho@10.5.5.2

You should get similar results:
sshtest

Step 3. Configuring the DHCP -Server

Configuration here is done in a similar way to the prior part of the assignment. You will need to access the .conf file and tweak it a bit.

sudo nano /etc/dhcp/dhcpd.conf

This is how it will look by default:
Selection_003

You will need to add these lines into the .conf -file:

subnet 10.5.5.0 netmask 255.255.255.0 {
range 10.5.5.10 10.5.5.30;
option domain-name-servers 10.5.5.1, 8.8.8.8; 
## 8.8.8.8 is google's name server, which work as a backup here
option domain-name "yournetwork'snamehere.example";
option broadcast-address 10.5.5.255;
#option routers 10.5.5.1 #if you need this 
}

After adding this to the file, it should look a bit like this:
dhcp3

Depending on how you want to build your network, you might want to set fixed addresses to your machines. This is done using MAC-addresses and the configuration is done to the same file we’re in now. Here’s how you’ll do it.

 host hostname {
      hardware ethernet 08:00:27:ff:03:57; 
      fixed-address 10.5.5.40;
      } #remember to close the script

“hardware ethernet” is the mac-address of the machine whose IP you want to set as fixed. It can be found in ifconfig.
“fixed-address” is the IP you want to set. Preferably set it outside the range set above, to avoid overlaps.

My conf-file looks like this:
dhcp4
I gave all my machines fixed-addresses.

Now we need to restart the DHCP -server. It is done with this command:

sudo /etc/init.d/isc-dhcp-server restart

You should get similar results:
Selection_005
Now the DHCP -server has been configured.

Now the other machines should receive a fixed address, if their network is set to internal. Let’s test this. Machine D, aka Aku, let’s refresh the connection with ifdown and up, and see what kind of IP will we get. It’s supposed to be 10.5.5.40.
akutest
Looks like it worked!  We can also see from the messages on the terminal, that the DHCP-server is working properly.

Next step is to configure the server so, that the machines in internal network can also access public network. That will be done in the next post.