Dude 6.x sprzątanie bazy danych

Ostatnio zacząłem mieć kłopoty z tworzeniem się kopii zapasowej. W logach pojawiały się wpisy na czerwono „timeout” w odniesieniu do skryptów. Sprawdziłem maszynę i rozmiar dude.db wynosił ponad 200MB. Faktycznie, z poziomu konsoli backup dało się zrobić, ale już aby skrypt wykonał kopię nie.

Przeglądając internet i stare wpisy na temat Dude 3.6 i 4.0 trafiłem na czyszczenie bazy. http://www.mtin.net/blog/cleaning-the-dude-database/

Dane w Dude trzymane są w bazie danych SQLite, można taką bazę otworzyć poprzez klienta i edytować. W czyszczeniu bazy najczęściej chodzi o usunięcie danych historycznych: czasów awarii oraz danych do wykresów.

Niestety pierwsze podejście było połowicznie udane, z 200MB udało mi się zmniejszyć bazę do 2,5MB. Polegało to na przekonwertowaniu bazy na plik tekstowy .sql, utworzenie w Dude nowej bazy dude.db i przeniesienie do niej tylko wpisów urządzeń. Są to linie zaczynające się od:

INSERT INTO “objs”

Wszystko wyglądało dobrze, Dude wstał z nową, lekką bazą. Nic nie zwiastowało problemów. Nastały one w północy, kiedy tworzy się kopia. Nie problemem było, że się nie zrobiła, problemem było, że zrobiła się na kilka tysięcy procent. Zapełniła całe dostępne miejsce na maszynie i zablokowała zapisywanie nowych zmian w bazie. Sprawdziłem kilkukrotnie, czy to ręcznie czy skryptem. Tak samo. Export mija magiczne 100% i przebiega dalej.

Powrót do starej bazy i dalsza analiza problemu. Jeżeli możemy dokonać obróbki bazy z poziomu wiersza poleceń sqlite, to zamiast edytować w notatniku plik sql wielkości ponad 600MB, zróbmy to tam.

Podejście numer dwa. Nowy jail na FreeBSD, dodanie pakietu sqlite3 i przesłanie pliku dude.db do niego.

Marcin@dude:/mnt# sqlite3 dude.db
SQLite version 3.30.1 2019-10-10 20:19:45
Enter ".help" for usage hints.
sqlite> .tables
chart_values_10min  chart_values_2hour  objs
chart_values_1day   chart_values_raw    outages

Jak widać, mamy tabele objs gdzie są nasze urządzenia, tabelę outages gdzie mamy wpisy z awariami naszych urządzeń oraz tabele chart_* gdzie są dane do wykresów. Choć możemy nie korzystać z wykresów to dane są i tak automatycznie zbierane dla wszystkich interfejsów, procesorów itp.

sqlite> delete from chart_values_10min;
sqlite> delete from chart_values_2hour;
sqlite> delete from chart_values_1day;
sqlite> delete from chart_values_raw;
sqlite> delete from outages;

Pozbywamy się niechcianych danych z tabel, jeżeli chcemy zostawić wpisy o awariach to nie usuwamy danych z tabeli outages.

Na koniec wykonujemy czyszczenie bazy poleceniem vacuum i zamykamy wiersz poleceń sqlite:

sqlite> vacuum;
sqlite> .quit;

Po tych zabiegach baza dude.db zajmowała tyle samo miejsca co według poradnika, ale nie stwarzała problemów z eksportem z linii poleceń czy poprzez skrypt.

Nie muszę chyba pisać o wykonaniu kopii zapasowej aby w razie niepowodzenia mieć plik dude.db sprzed zmian.

Dodatkowo można testować nową bazę danych zmieniając katalog główny Dude.

[Marcin@Dude] > dude set data-directory=dude2

26 marca 2020 Add Comment

FreeBSD + Rancid + ViewVC = Backup

FreeBSD czyli NAS4Free ciąg dalszy, czyli jak wykorzystać możliwości systemów BSD, zamiast wirtualizować całe systemy można oddzielać środowiska od siebie.

Potrzebujemy NAS4Free + The Brig, czyli manager jaili, albo surowy system FreeBSD zainstalowany na maszynie fizycznej lub w ostateczności na wirtualnej.

Do zapoznania się czym jest RANCID zapraszam na stronę autora: http://www.shrubbery.net/rancid/

1.Instalacja i konfiguracja RANCID

Tworzymy naszego jaila, w większości sprowadza się to do podania jego ID, nazwy oraz przydzielenia adresu IP na wybrany interfejs. Startujemy go i łączymy się po IP jaila albo IP systemu podając dane user/pass z systemu głównego. Podnosimy uprawnienia komendą su, listujemy jaile komendą jls, i łączymy się do wybranego poleceniem jexec:

nas4free.local: /# jls
   JID  IP Address      Hostname                      Path
     1  10.0.0.3     rancid.local                  /mnt/ZFS/jails/rancid
nas4free.local: /# jexec 1 /bin/csh
root@rancid:/ #

Jesteśmy zalogowani jako root w naszym podsystemie. Pierwsze co to potrzebujemy pobrać zarządcę pakietami pkg:

root@rancid:/ # pkg
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:11:amd64/quarterly, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
[rancid.local] Installing pkg-1.10.1...
[rancid.local] Extracting pkg-1.10.1: 100%
pkg: not enough arguments
Usage: pkg [-v] [-d] [-l] [-N] [-j <jail name or id>|-c <chroot path>|-r <rootdir>] [-C <configuration file>] [-R <repo config dir>] [-o var=value] [-4|-6] <command> [<args>]

For more information on available commands and options see 'pkg help'.
root@rancid:/ #

Uaktualniamy bazę poleceniem pkg update:

root@rancid:/ # pkg update
Updating FreeBSD repository catalogue...
pkg: Repository FreeBSD load error: access repo file(/var/db/pkg/repo-FreeBSD.sqlite) failed: No such file or directory
[rancid.local] Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
[rancid.local] Fetching packagesite.txz: 100%    6 MiB 498.7kB/s    00:12
Processing entries: 100%
FreeBSD repository update completed. 26289 packages processed.
All repositories are up to date.

Instalujemy RANCID poleceniem pkg install rancid3, zostanie pobrany pakiet łącznie ze wszystkimi zależnościami.

Kopiujemy plik konfiguracyjny posiłkując się dołączonym samplem takiego pliku przez autora:

cp /usr/local/etc/rancid/rancid.conf.sample /usr/local/etc/rancid/rancid.conf

Z przyzwyczajenia używam edytora nano, jeżeli nie masz go w systemie możesz go doinstalować poleceniem pkg install nano, albo korzystać z wbudowanego w system vi.

RANCID może tworzyć grupy urządzeń i katalogować je w osobnych miejscach, na potrzeby poradnika skupimy się na razie na przypadku jednej grupy. W pliku /usr/local/etc/rancid/rancid.conf odnajdujemy, zmieniamy i usuwany znak # komentarza:

#LIST_OF_GROUPS="sl joebobisp" => LIST_OF_GROUPS="backup"

Teraz logujemy się poprzez su rancid na użytkownika rancid aby utworzyć poprawnie struktury katalogów i konfigurację z poprawnymi uprawnieniami

root@rancid:/ # su rancid
$

Tworzymy plik z loginami i hasłami do urządzeń. Niestety w pliku RANCID przechowuje je otwartym tekstem, jeżeli to tylko możliwe warto stosować logowanie za pomocą kluczy SSH, jak nie ma możliwości bo urządzenie obsługuje tylko telnet, odseparować sieć aby nie było możliwe przechwycenie transmisji hasła. Zawartość pliku wygląda następująco:

$ touch /usr/local/var/rancid/.cloginrc
$ nano /usr/local/var/rancid/.cloginrc

add user 10.0.0.5 admin # dla urządzenia 10.0.0.5 dodajemy użytkownika admin
add password 10.0.0.5 hasło hasłogłówne # dla urządzenia 10.0.0.5 dodajemy hasło logowania i hasło podniesienia uprawnień jak w urządzeniach Cisco
add method 10.0.0.5 ssh # dla urządzenia 10.0.0.5 dodajemy metodę logowania, tutaj ssh
add user 10.0.0.* admininny # możemy wykorzystać gwiazdkę aby rozszerzyć zakres na więcej urządzeń, tutaj cała podsieć /24
add method mikrotik1 ssh # możemy używać nazw bardziej ludzkich albo domenowych, urządzenia muszą być albo dopisane w pliku /etc/hosts albo rozwiązywane przez serwer DNS

$ chmod 600 /usr/local/var/rancid/.cloginrc

$ ls -l /usr/local/var/rancid/.cloginrc
-rw-------  1 rancid  rancid  88 May 20 20:33 /usr/local/var/rancid/.cloginrc

Zawartość chronimy ustawiając prawa tylko do odczytu i zapisu przez właściciela pliku. Jeżeli używany swoich nazw dopisanych do pliku /etc/hosts to zalecam stosowanie tylko małych liter.

Tworzymy pliki i katalogi ręcznie uruchamiając polecenia:

$ /usr/local/bin/rancid-run
$ /usr/local/bin/rancid-cvs

No conflicts created by this import

cvs checkout: Updating backup
Directory /usr/local/var/rancid/CVS/backup/configs added to the repository
cvs commit: Examining configs
cvs add: scheduling file `router.db' for addition
cvs add: use 'cvs commit' to add this file permanently
RCS file: /usr/local/var/rancid/CVS/backup/router.db,v
done
Checking in router.db;
/usr/local/var/rancid/CVS/backup/router.db,v  <--  router.db
initial revision: 1.1
done

Przechodzimy do katalogu gdzie pojawiły się nasze pliki, nazwa będzie różna, w zależności od nazwy grupy czy grup jakie podawaliśmy w pliku /usr/local/etc/rancid/rancid.conf.

$ cd /usr/local/var/rancid/backup

Edytujemy plik router.db, gdzie podajemy urządzenia które mają odpytane o konfigurację. Ma on składnię IP;rodzaj_urządzenia;status(up,down)

10.0.250.1;mikrotik;up # urządzenie typu mikrotik, kopia będzie wykonana
10.0.250.2;Cisco;up # urządzenie typu Cisco, kopia będzie wykonana
10.0.250.3;mikrotik;down # urządzenie typu mikrotik, kopia nie będzie wykonana

Ostatnim krokiem będzie dodanie wpisu do crona, aby kopie były tworzone regularnie o równej godzinie co godzinę:

$ crontab -e
Wciskamy klawisz i
Wklejamy zawartość poniżej:
0 * * * * /usr/local/bin/rancid-run

Wciskamy klawisz ESC
Wpisujemy :wq i zatwierdzamy ENTER
/tmp/crontab.pcMtf5FHDq: 1 lines, 36 characters.
crontab: installing new crontab
$

Log dla odpowiedniej grupy znajduje się w katalogu: /usr/local/var/rancid/logs/, gdzie można sprawdzić jak przebiega proces tworzenia kopii zapasowych i rozwiązywać występujące problemy.

2.Instalacja ViewVC do przeglądania konfiguracji poprzez przeglądarkę WWW.

Aby wygodniej przeglądać zmiany w konfiguracji zainstalujemy w systemie ViewVC poleceniem pkg install viewvc.

root@rancid:~ # pkg install viewvc

Doinstaluje się nam serwer WWW apache jako zależność, jednak w zupełności wystarczy nam serwer WWW wbudowany.

Konfiguracja ViewVC znajduje się w pliku: /usr/local/viewvc/viewvc.conf edytujemy go i zmieniamy podane linie.

root@rancid:~ # nano /usr/local/viewvc/viewvc.conf

cvs_roots = backup: /usr/local/var/rancid/backup/CVS/
root_parents = /usr/local/var/rancid/CVS/ : cvs
default_root = backup
use_localtime = 1

Dodajemy do pliku /etc/rc.conf polecenia dla ViewVC:

root@rancid:~ # nano /etc/rc.conf

viewvc_enable="YES"
viewvc_user="rancid"
viewvc_flags="-h 10.0.0.3 -p 10080"

Czyli uruchamiamy ViewVC jako użytkownik rancid, serwer WWW będzie uruchomiony na IP 10.0.0.3 i porcie 10080

ViewVC startujemy poleceniem:

root@rancid:~ # /usr/local/etc/rc.d/viewvc start
Starting viewvc.

I uruchamiamy przeglądarkę i przechodzimy na adres: http://10.0.0.3:10080/viewvc

20 maja 2017 1 Comment

Backup Cacti cz.2

Część druga to kopia zapasowa bazy danych.

#!/bin/bash
# Database credentials
 user="cacti"
 password="password"
 host="127.0.0.1"
 db_name="cacti"
# Other options
 DESDIR="/home/marcin/cacti"
 TIME=$(date +"%d-%m-%Y")
# Wait 20s for cacti pooling
echo "Wait 20s for cacti pooling"
sleep 20s
# Dump database into SQL file
echo "Dump database into SQL file"
mysqldump --user=$user --password=$password --host=$host $db_name > $DESDIR/$db_name-$TIME.sql
sleep 1s
# gzip database
echo "gzip database"
gzip $DESDIR/$db_name-$TIME.sql
# SCP file to backup server
echo "SCP file to backup server"
scp $DESDIR/$db_name-$TIME.sql.gz cacti@10.0.0.10:/mnt/cacti/$db_name-$TIME.sql.gz
# Log to syslog
logger MySQL Backup Complete

Zapis w crontabie:

0 0 * * * /home/marcin/cactidb.sh

Ścieżkę DESDIR zmienić sobie wg własnego uznania, tak samo jak wysyłanie przez scp i kluczy SSH na serwer w sieci czy internecie. Tak samo jak dane user,password oraz ip hosta gdzie stoi baza danych MySQL.

22 sierpnia 2016 3 komentarze

Backup Cacti cz.1

Backup najlepszym przyjacielem admina. Pierwszym krokiem jest kopia zapasowa plików Cacti. Często dodanie nowych funkcji czy poprawienie istniejących wiąże się z edycją plików w katalogu programu.

Skrypt dodany do crona uruchamia się co dobę, jednak częstotliwość zależna jest od częstotliwości zmian jakie dokonujemy w systemie.

#!/bin/bash
#START
TIME=$(date +"%d-%m-%Y")            # This Command will add date in Backup File Name.
FILENAME=files-$TIME.tar.gz         # Here i define Backup file name format.
SRCDIR=/usr/share/cacti/site/       # Location of Important Data Directory (Source of backup).
DESDIR=/home/marcin/cacti           # Destination of backup file.
# Wait 10s for cacti pooling
echo "Wait 10s for cacti pooling"
sleep 10
# Tar cacti folder
echo "Tar cacti folder"
tar -hcpzf $DESDIR/$FILENAME $SRCDIR
# SCP File to backup server
echo "SCP File to backup server"
scp $DESDIR/$FILENAME cacti@10.0.0.10:/mnt/cacti/$FILENAME
# Log to syslog
logger Cacti Backup Complete
#END

Zapis w crontabie:

0 0 * * * /home/marcin/cacti.sh

Ścieżkę DESDIR zmienić sobie wg własnego uznania, tak samo jak wysyłanie przez scp i kluczy SSH na serwer w sieci czy internecie.

21 sierpnia 2016 Add Comment

Mikrotik i backup codzienny

Tak jak w przypadku The Dude tak samo przydaje się mieć backup ustawień z urządzeń Mikrotik rozsianych po sieci. Po co utrudniać sobie życie jak można ułatwić, wykorzystując do tego samo urządzenie i automatyzując sam proces. Sam backup polega na wygenerowaniu pliku binarnego .backup oraz pliku tekstowego .rsc. Osobiście wolę mieć oba, pierwszy wgrywam, drugi mam do podglądu wszystkich ustawień.

/system script
add name=FTPBackup owner=admin policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive source=":log info \"\
    Starting Automatic Backup Script Configure By cr0c0dil3\"\r\
    \n:log info \"Modyfikowany przez Marcin Morawiec\"\r\
    \n:global thisdate [/system clock get date]\r\
    \n:global datetimestring ([:pick \$thisdate 4 6] .\"-\" . [:pick \$thisdate 0 3\
    ] .\"-\" . [:pick \$thisdate 7 11])\r\
    \n\r\
    \n/system backup save name=\"\$[/system identity get name]_\$datetimestring\" \
    \r\
    \n:log info \"Backup Please wait...!!!\"\r\
    \nexport compact file=\"\$[/system identity get name]_\$datetimestring\"\
    \_\r\
    \n:log info \"Export Please wait...!!!\"\r\
    \n:delay 5s\r\
    \n:log info \"Sending Backup Mikrotik to FTP Server.............\"\r\
    \n/tool fetch address=ip_address src-path=\"\$[/system identity get name]_\$\
    datetimestring.backup\" user=user password=password port=21 upload=yes \
    ascii=no mode=ftp dst-path=\"/backup/\$[/system identity get name]_\$datetimest\
    ring.backup\"\r\
    \n:log info \"Sending Export Mikrotik to FTP Server.............\"\r\
    \n/tool fetch address=ip_address src-path=\"\$[/system identity get name]_\$\
    datetimestring.rsc\" user=user password=password port=21 upload=yes asc\
    ii=no mode=ftp dst-path=\"/backup/\$[/system identity get name]_\$datetimestrin\
    g.rsc\"\r\
    \n:delay 5s\r\
    \n:log info \"Deleting Backup Files\"\r\
    \n/file remove \"\$[/system identity get name]_\$datetimestring.rsc\"\r\
    \n/file remove \"\$[/system identity get name]_\$datetimestring.backup\"\r\
    \n:log info message=\"Successfully removed Temporary Backup Files\"\r\
    \n:delay 1\r\
    \n:log info \"Finished Backup Script...!!!!\""
  
/system scheduler
add interval=1d name=FTPBackupMT on-event="/system script run FTPBackup" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=\
    apr/01/2016 start-time=00:00:15

Skrypt wzorowany jest na znalezionym w internecie tutaj. Przejrzysty, składa się z kilku poleceń. Łatwo można dostosować go do siebie. Pamiętać należy o podaniu swojego IP serwera FTP, użytkownika i hasła oraz ścieżki na serwerze gdzie ma być składowany backup. U mnie backup ląduje na serwerze NAS4FREE gdzie w odstępach tygodniowych protokołem rsync wędrują na kolejnego NASa. W planach jest jeszcze opcja szyfrowania archiwum i wysyłania go na pocztę aby mieć kolejną kopię w innej lokalizacji.

18 kwietnia 2016 7 komentarzy

DudeRC i backup codzienny

Są admini którzy robią backup, i tacy którzy zaczną robić. Bardzo prawdziwe słowa, doceni je admin z tej drugiej grupy. Straciłem kiedyś bazę danych Mikrotikowego The Dude, normalna w świecie awaria sprzętu, dysk odmówił działania. Monitorowana sieć jest rozmiaru 300 hostów, syslog z kilkunastu urządzeń. Teraz The Dude stoi na maszynie wirtualnej, dysk jest na macierzy. Jednak przezorny zawsze ubezpieczony, w chwili wolnego czasu wolałem zabezpieczyć się przed jakimś błędem, który skasuje mi dane w programie. Zabezpieczenie przez awarią sprzętu to jedno, awaria przed utratą danych to drugie.

/system script
add name=Dude_backup owner=admin policy=\
 ftp,reboot,read,write,policy,test,password,sniff,sensitive source=":log in\
 fo \"Dude Backup Script by Marcin Morawiec\"\r\
 \n:global thisdate [/system clock get date]\r\
 \n:global datetimestring ([:pick \$thisdate 4 6] .\"-\" . [:pick \$thisdat\
 e 0 3] .\"-\" . [:pick \$thisdate 7 11])\r\
 \n\r\
 \n/dude export-db backup-file=\"Dude_\$datetimestring.backup\" \r\
 \n:log info \"Backup Please wait...!!!\"\r\
 \n:delay 30s\r\
 \n:log info \"Sending Dude Backup to FTP Server.............\"\r\
 \n/tool fetch address=10.0.0.10 src-path=\"Dude_\$datetimestring.backup\
 \" user=Dude password=zaq12wsxcde3 port=21 upload=yes ascii=no mode=ftp ds\
 t-path=\"Dude_\$datetimestring.backup\"\r\
 \n:delay 5s\r\
 \n:log info \"Deleting Backup Files\"\r\
 \n/file remove \"Dude_\$datetimestring.backup\"\r\
 \n:log info message=\"Successfully removed Temporary Backup Files\"\r\
 \n:delay 1\r\
 \n:log info \"Finished Backup Script...!!!!\""

Bazę danych na nowym The Dude w wersji na platformę ROS można optymalizować z racji tego, że jest to baza danych SQLite3, codziennie przed północą mam zaplanowaną optymalizację, a 30min później robiony jest export.

/system scheduler
add interval=1d name=Dude_vacuum-db on-event="/dude vacuum-db" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=\
    apr/01/2016 start-time=23:00:00
add interval=1d name=Dude_Backup on-event="/system script run Dude_backup" \
    policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive \
    start-date=apr/01/2016 start-time=23:30:00

Wyedytować trzeba sobie tylko skrypt aby łączyć się do swojego serwera FTP, podać IP, użytkownika i hasło. Oraz do jakiego katalogu ma być wrzucany plik.

14 kwietnia 2016 Add Comment