Skip to content

Instantly share code, notes, and snippets.

@wavedocs
wavedocs / main.yml
Last active January 11, 2018 12:03
---
- name: Install Common
apt: pkg=makepasswd state=installed update_cache=yes
- name: Generate password
shell: makepasswd --chars=12
register: passwd
- name: Telegram send mysql apps access
@wavedocs
wavedocs / python3-logging.py
Created November 1, 2017 20:12 — forked from Integralist/capture logger output.py
[Python3 Logging] Simple Python3 Logging Configuration #tags: logs, python3
# https://docs.python.org/3/library/logging.html#logrecord-attributes
import logging
log = logging.getLogger() # <logging.RootLogger at 0x107f72f98>
log.setLevel(logging.DEBUG)
log.debug('123') # DEBUG:root:123
log.info('456') # INFO:root:456
# Alternatively...
import logging
import time
import datetime
import asyncio
import aiohttp
domain = 'http://integralist.co.uk'
a = '{}/foo?run={}'.format(domain, time.time())
b = '{}/bar?run={}'.format(domain, time.time())
async def get(url):
@wavedocs
wavedocs / bacula-dir.conf
Created September 28, 2017 09:38 — forked from skarllot/bacula-dir.conf
Bacula configuration to use sendEmail
. . .
Messages {
Name = Standard
mailcommand = "/usr/local/bin/sendEmail-backup \"[BACKUP] %t %e of %n %l\" \"%r\""
operatorcommand = "/usr/local/bin/sendEmail-backup \"[BACKUP] Intervention needed for %j\" \"%r\""
mail = [email protected] = all, !skipped
operator = [email protected] = mount
console = all, !skipped, !saved
append = "/var/log/bacula/bacula.log" = all, !skipped
catalog = all
@wavedocs
wavedocs / jira-behing-nginx-ssl
Created September 22, 2017 20:34 — forked from jtbonhomme/jira-behing-nginx-ssl
Atlassian JIRA behind nginx + SSL
# force HTTP to HTTPS - /etc/nginx/conf.d/nonssl.conf
server {
listen 80;
server_name jira.example.com;
access_log off;
return 301 https://$server_name$request_uri;
}
# /etc/nginx/conf.d/jira.conf
server {

Программа TOP - это одна из основных консольных программ для администрирования, а если выразиться точнее - мониторинга Linux систем. С ее помощью вы сможете мониторить в реальном времени состояние выполниемых процессов, выявлять прожорливые к процессору и памяти процессы, а в случае необходимости вы сможете убить процесс, или изменить его приоритет.

VIRT Virtual Image
RES - Resident memory size
SHR - Shared Memory size
SWAP - Swapped size
DATA -Data + Stack size
CODE - Code size

VIRT Virtual Image

---
- name: Set timestamp
set_fact: timestamp="{{ lookup('pipe', 'date +%Y%m%d%H%M%S') }}"
- name: Set release path
set_fact: release_path="{{ app_path }}/releases/{{ timestamp }}"
- name: Remove old releases
shell: "cd {{ app_path }}/releases && find ./ -maxdepth 1 | grep -G .............. | sort -r | tail -n +{{ keep_releases }} | xargs rm -rf"

#MongoDB 3.2.x Replica Sets on AWS EC2 A MongoDB replica set provides a mechanism to allow for a reliable database services. The basic replica set consists of three servers, a primary, a secondary and an arbitrator. The primary and secondary both hold a copy of the data. The arbitrator is normally a low spec server which just monitors the other servers and help with the failover process. In production, there can be more than three servers.

To setup mongo as a replica set on Amazon Web Services EC2 you need to first setup a security group with ssh on port 22 and mongodb on port 27017. You then need to create three servers. Select Ubuntu 14.04 LTS x64 and a micro (or bigger depending on your database size, ideally you should have enough memory to match your database size) instance for the primary and secondary and a nano instance for the arbitrator.

##Adjust the File System on each Server The operating system by default will update the last access time on a file. In a high data throughput database application

@wavedocs
wavedocs / mongodb_3.2.x_security.md
Created January 25, 2017 10:37 — forked from leommoore/mongodb_3.2.x_security.md
MongoDB 3.2.x Security

#MongoDB 3.2.x Security

##Network Ports The standard ports used by mongo are:

ProcessRoleDefault Port
@wavedocs
wavedocs / mongodb_3.2.x_sharding.md
Created January 25, 2017 10:37 — forked from leommoore/mongodb_3.2.x_sharding.md
MongoDB 3.2.x Sharding

#MongoDB 3.2.x Sharding Sharding is used when the database is too large to run on a single server and you need to spread the load across multiple servers. The name itself refers to the breaking (sharding) of the data into seperate groups of data which will reside on different servers.

##Configuration Server Start the server on your server (myserver0)

mongod --configsvr --dbpath /data

On myserver1 start the shard giving the configuration server as the --configdb option