Skip to main content

Posts about draft

Zabbix stack with docker-compose.yml

Fully working zabbix server solution with UI and database in seconds

I wanted to install zabbix server quickly with docker but amount of zabbix images (created by zabbix) on dockerhub just overwhelmed me. To set up running zabbix server we need 3 images * choice of sql DB * zabbix-web - web interface * zabbix-server - main zabbix process responsible for polling and trapping data and sending notifications to users.

My choice of database was MySQL so I created docker-compose file to have full stack of running zabbix server:

Notice(you may want to use alpine versions for production env) docker-compose.yml:

version: '3'

services:
  db:
    image: mysql:latest
    restart: always
    expose:
      - '3336'
    environment:
      MYSQL_ROOT_PASSWORD: 'my_secret_password'
      MYSQL_USER: 'zabbixuser'
      MYSQL_PASSWORD: 'zabbixpass'
      MYSQL_ROOT_HOST: '%'
    volumes:
      - 'mysql_data_dir:/var/lib/mysql'


  zabbix-server:
    image: zabbix/zabbix-server-mysql
    links:
      - "db:mysql"
      - "postfix:postfix"
    environment:
      MYSQL_ROOT_PASSWORD: 'my_secret_password'
      MYSQL_USER: 'zabbixuser'
      MYSQL_PASSWORD: 'zabbixpass'
      DB_SERVER_HOST: 'mysql'


  zabbix-web:
    image: zabbix/zabbix-web-nginx-mysql
    ports:
      - '7777:80'
    links:
      - "db:mysql"
      - "zabbix-server:zabbix-server"
      - "postfix:postfix"
    environment:
      MYSQL_ROOT_PASSWORD: 'secret'
      MYSQL_USER: 'zabbixuser'
      MYSQL_PASSWORD: 'myzabbixpass'
      DB_SERVER_HOST: 'mysql'
      ZBX_SERVER_HOST: "zabbix-server"
      PHP_TZ: "Europe/London"
  postfix:
    image: catatnight/postfix
    hostname: support
    environment:
      - maildomain=domain.com
      - smtp_user=admin:password
    ports:
      - "25:25"
    #  - "465:465"
    #  - "587:587"
    expose:
      - "25"
    #  - "465"
    #  - "587"
    volumes:
      - /etc/nginx/ssl/postfix:/etc/postfix/certs
      - /etc/nginx/ssl/postfix:/etc/opendkim/domainkeys
volumes:
  mysql_data_dir:
    driver: local

      #- ./deployment/config_files/main-postfix-live.cf:/etc/postfix/main.cf
    #networks:
    #  - backend
    #entrypoint: /docker-entrypoint.sh

The above solution is just enough to start zabbix server up and running in couple seconds. To run it just put yml file into some directory (directory is important as volume created for mysql will have this dir name as prefix) volumes are usually stored in /var/lib/docker/volumes and run:

sudo docker-compose up

Thats it!!! You now have your zabbix running on port 7777

So what happened here docker-compose up has build and runned 3 containers by running zabbix container it discovered there are no tables in mysql and has built them.

Now you just need to add agents/servers you want to monitor. Check out adding agent in separate post [here]

Versions: (versions I've used in this example Feb 2018):

Docker-compose: 1.17.0, build ac53b73 Docker: 17.09.1-ce, build 19e2cf6 Kernel: 4.13.0-36-generic

Vagrant create your own base box

apt-get install vim sudo update-alternatives --config editor ensure you have sudo installed

apt-get install sudo

add vagrant to sudoers file and passwordless login vagrant ALL=(ALL) NOPASSWD:ALL

mkdir -p /home/vagrant/.ssh wget --no-check-certificate https://raw.github.com/mitchellh/vagrant/master/keys/vagrant.pub -O /home/vagrant/.ssh/authorized_keys Ensure we have the correct permissions set chmod 0700 /home/vagrant/.ssh chmod 0600 /home/vagrant/.ssh/authorized_keys chown -R vagrant /home/vagrant/.ssh

apt-get install -y openssh-server

$ sudo apt-get install -y build-essential linux-headers-server

# Mount guest additions ISO via virtualbox window then run... $ sudo mount /dev/cdrom /media/cdrom $ sudo /media/cdrom/VBoxLinuxAdditions.run $ sudo umount /media/cdrom $ sudo apt-get clean

Make sure that GRUB_TIMEOUT is set to “1”, GRUB_HIDDEN_TIMEOUT_QUIET is set to “true”, and GRUB_CMDLINE_LINUX_DEFAULT is set tp “quiet.” Save & close the file then update GRUB. sudo vi /etc/default/grub $ sudo update-grub

sudo dd if=/dev/zero of=/EMPTY bs=1M

$ sudo rm -f /EMPTY # Shutdown the machine $ sudo shutdown -h now

The next command will actually create our box. The directory where you run this command is where the box file will be created.

$ vagrant package --base vagrant-{distro}-{version}

Postgres connect through ssh tunnel

There is possibility to use local pgadmin3 instance even if remote connection on postgresql server is not granted. To do so powerfull ssh tunneling comes with help : c:w reate ssh connection where $ ssh -L 63333:mad-erp04:5432 greg@mad-erp04.made.com $ ssh -L 63333:localhost:5432 joe@foo.com It is possible to use SSH to encrypt the network connection between clients and a PostgreSQL server. Done properly, this provides an adequately secure network connection, even for non-SSL-capable clients.

First make sure that an SSH server is running properly on the same machine as the PostgreSQL server and that you can log in using ssh as some user. Then you can establish a secure tunnel with a command like this from the client machine:

ssh -L 63333:localhost:5432 joe@foo.com The first number in the -L argument, 63333, is the port number of your end of the tunnel; it can be any unused port. (IANA reserves ports 49152 through 65535 for private use.) The second number, 5432, is the remote end of the tunnel: the port number your server is using. The name or IP address between the port numbers is the host with the database server you are going to connect to, as seen from the host you are logging in to, which is foo.com in this example. In order to connect to the database server using this tunnel, you connect to port 63333 on the local machine:

psql -h localhost -p 63333 postgres To the database server it will then look as though you are really user joe on host foo.com connecting to localhost in that context, and it will use whatever authentication procedure was configured for connections from this user and host. Note that the server will not think the connection is SSL-encrypted, since in fact it is not encrypted between the SSH server and the PostgreSQL server. This should not pose any extra security risk as long as they are on the same machine.

In order for the tunnel setup to succeed you must be allowed to connect via ssh as joe@foo.com, just as if you had attempted to use ssh to create a terminal session.

You could also have set up the port forwarding as

ssh -L 63333:foo.com:5432 joe@foo.com but then the database server will see the connection as coming in on its foo.com interface, which is not opened by the default setting listen_addresses = 'localhost'. This is usually not what you want.

If you have to "hop" to the database server via some login host, one possible setup could look like this:

ssh -L 63333:db.foo.com:5432 joe@shell.foo.com Note that this way the connection from shell.foo.com to db.foo.com will not be encrypted by the SSH tunnel. SSH offers quite a few configuration possibilities when the network is restricted in various ways. Please refer to the SSH documentation for details.