Tag Archives: VM

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!