Mikrotik scripts for keeping configuration synced between two different Mikrotik routers.

Ten post jest dostępny jedynie w języku angielskim.

I've faced problem how to setup backup router that can be easily (but manually) switched to act as main. I have two routers - RB1000 and RB750. They are different platforms and I can't just backup config on RB1000 and restore it on RB750. Additionally RB750 have one more ethernet interface which I use to detect if router acts as main router. If additional interface (configurable in script) is running (cable is connected) router will act in "backup" mode, otherwise it will be in "running" mode. My solution consists of two separate scripts - 1. mikrotik-sync-config.py 2. set-backup-mode Ad.1 This script cares about config on backup router to be the same (as much as possible) as on main router (RB1000). It's configurable - you can setup what from main router config to omit, while importing on backup router. Ad.2 This script runs on scheduler on backup router. It detects cable at specified interface (SI) and setups router in "backup" or "running" mode. In "backup" mode all interfaces except SI and all schedules are disabled. When cable is removed from SI, script switches router into "running" mode what means it's enabling interfaces and schedules You can find scripts here -> https://github.com/codepill/script-utilities/tree/master/mikrotik

Mikrotik script for monitoring Internet connection and using backup connection when primary is dead

Ten post jest dostępny jedynie w języku angielskim.

Idea is simple. Script (I run it every 2 minutes via scheduler) sends ping to 3 defined locations. When all 3 locations are dead it supposses that connection is broken somewhere outside. In this case script enables firewall mangle rule that marks packets with 'failover' label. In routing table you have to add routing for 'failover' label using your backup interface. You have to add 'failover' routing for all your local interfaces - otherwise you local routing won't work when main connection will be dead.

You have to setup few variables at the beginning of the script and 'backupinterfacename' in the script body.

You can find script here -> https://github.com/codepill/script-utilities/blob/master/mikrotik/connection-watch

Backuping and restoring repositories in GitHub

If you lack of free private repositories in GitHub you have two options - buy higher plan or delete one of existing repositories. Second option isn't bad (you can reimport repostiory in future from local copy) but you will loose all addtional information - wiki, issues etc. Facing this problem I've written scripts for backup and restore almost all informations from GitHub that can be obtained. Theses scripts use GitHub API v 3 and 'git' command. You can find them here:

https://github.com/codepill/script-utilities/tree/master/github-repository-tools

Please read README file before use.

Jeśli brakuje Ci wolnych prywatnych repozytoriów w Githubie masz dwie możliwości - zakupić wyższy plan lub usunąć jedno z istniejących repozytoriów. Opcja druga nie jest zła (możesz potem zaimportować repozytorium z lokalnej kopii) ale stracisz wtedy wszystkie dodatkowe informacje powiązane z repozytorium - wiki, issues itd. Stojąc przed tym problemem napisałem w Pythonie skrypty do backupowania i przywracania większości informacji o repozytorium z Githuba. Skrypty te korzystają z API w wersji 3 oraz z polecenia 'git'. Skrypty możesz znaleźć tutaj:

https://github.com/codepill/script-utilities/tree/master/github-repository-tools

Przed skorzystaniem przeczytaj plik README.

MIUI i kolorowy bash

This post is available only in polish language

UWAGA! Wszystkie operacje wykonujesz na własne ryzyko.

Korzystam czasem z terminala w MIUI i wkurzał mnie domyślny shell - nie ma kolorów, uzupełniania składni po naciśnięciu TAB-a itd. To wszystko jest dostępne jeśli odpalimy konsolę w Open Recovery. Postanowiłem wykorzystać powłokę bash z OR tak, żeby była dostępna po odpaleniu terminala. Plik powłoki jest dostępny w katalogu /sdcard/OpenRecovery/sbin (zakładając domyślny katalog, do którego wypakowaliśmy OR), ale ten system plików jest zamontowany w sposób uniemożliwiający wykonywanie plików, które są na nim umieszczone. Tak też powinno zostać, dlatego skopiujemy sobie potrzebny plik do głównego systemu plików. W tym celu wykonujemy następujące operacje (zakładam, że używamy Terminal Emulatora i mamy zrootowany telefon):
- wchodzimy na roota
  su
- przemontowujemy system plików /system w trybie odczytu/zapisu
  mount -o remount,rw /system
- kopiujemy plik powłoki
  cp /sdcard/OpenRecovery/sbin/bash /system/xbin/
- przemontowujemy system plików /system w tryb domyślny - czyli tylko do odczytu
  mount -o remount,ro /system
I to tyle. Teraz wpisanie polecenia bash powinno poskutkować odpaleniem tego shella. Możemy też wejść w opcje Terminal Emulatora i zamienić domyślne ustawienie powłoki z

  /system/bin/sh -

na
  /system/xbin/bash -

dzięki czemu będziemy mieli odpalonego basha od razu po uruchomieniu Terminal Emulatora. Niestety po wydaniu polecenia su znów odpali się nam zwykły shell a nie bash i będziemy musieli odpalić go ręcznie. Pewnie da się to zmienić, ale teraz już mi się nie chce z tym walczyć.

 

MIUI 1.9.30 i problem z klawiaturą fizyczną

This post is available only in polish language

W nowej wersji MIUI 1.9.30 dla Milestone popsute zostało mapowanie klawiszy dla klawiatury fizycznej. Żeby to naprawić należy wykonać następujące operacje:

- restartujemy telefon i wchodzimy do OR
- odpalamy konsolę
- wchodzimy w edycję pliku
  vi /system/etc/rootfs/default.prop
- dopisujemy na końcu linię
  persist.sys.keypad_type=euro_qwerty
- zapisujemy i restartujemy

Dla niezaznajomionych z vi kilka pomocnych wskazówek:
- po otwarciu pliku przechodzimy strzałkami na ostatnią linię i naciskamy klawisz 'o' - spowoduje to wejście w tryb edycji przy czym kursor pojawi się w nowej linii
- znak '_' otrzymujemy przytrzymując 'alt' i naciskając 'c'
- wyjście z trybu edycji uzyskamy przytrzymując klawisz 'menu' (ten obok prawego alta) i naciskając znak '?'
- zapisanie zmian uzyskamy naciskając ':' oraz wprowadzając 'x' i naciskając enter
- anulowanie zmian bez zapisywania - ':'  a następnie 'q!' i enter

Problemy z aplikacjami na romie MIUI

This post is available only in polish language

Całkiem niedawno zamieniłem w mojej Motoroli Milestone ROM z defaultowego na MIUI w wersji 1.9.23. Wrażenie po instalacji było super - interfejs użytkownika jest ładny, wszystko chodzi szybko, wbudowane aplikacje są bardzo dobre, jest dostęp do konta root itd. Niestety po zainstalowaniu kilku aplikacji nie było już tak fajnie - system zaczął zamulać, a niektóre aplikacje się zawieszały - szczególnie Google Maps. Zacząłem grzebać po necie, ale nie znalazłem wielu informacji na ten temat, tak więc prawdopodobnie problem dotyczył mojej konfiguracji. Moje podejrzenie padło na dalvik-cache - bez wdawania się w szczegóły jest to mechanizm mający na celu przyśpieszenie działania systemu. Generuje on pliki, które są przechowywane w katalogu /data/dalvik-cache i aktualizowane w razie instalacji nowej softu lub jego aktualizacji. Po instalacji nowego ROM-u należy ten folder wyczyścić (np. z poziomu OpenRecovery), co też uczyniłem. Szukając przyczyny moich problemów z działaniem systemu i aplikacji, pomyślałem, że może jest nią właśnie ten mechanizm, dlatego postanowiłem wyczyścić ten cache. Na zrootowanym telefonie jest to bardzo proste. Odpalamy terminal, wchodzimy na roota przez polecenie su i usuwamy pliki. Całość wygląda tak:

su
rm /data/dalvik-cache/*
exit
exit

Następnie restartujemy telefon, żeby pliki cache wygenerowały się na nowo. Ten restart będzie trwał dłużej niż normalny ale nie należy się tym przejmować. Bez zrestartowania telefonu system zgłaszał mi co chwilę, problemy z aplikacjami, tak więc jest to krok niezbędny.

Teraz słowo na temat efektów tego zabiegu. Wydaje się, że ta operacja rozwiązała moje problemy z aplikacjami, ale jako, że tego posta piszę w miarę "na gorąco", to się tak naprawdę dopiero okaże. W każdym bądź razie na pewno nie zaszkodziło to telefonowi, więc warto spróbować.

Logi Mikrotika na zdalnej maszynie z FreeBSD

This post is available only in polish language

Generalnie sprawa jest dość prosta i sprowadza się do wykonania kilku operacji

1. Konfiguracja Mikrotika

Korzystając z WinBox-a wchodzimy w menu System / Logging / Actions i klikając w ikonę z plusem dodajemy akcję docelową:

• Name: dowolna nazwa
• Type: remote
• Remote Address: adres IP naszego serwera syslog
• Remote Port: 514 (jest to domyślny port UDP, na którym działa syslog)
• Src. Address: opcjonalny IP, z którego będą wychodziły pakiety
• BSD Syslog - zostawiamy odznaczone

Jeśli zaznaczymy BSD Syslog to możemy określić źródło komunikatu i jego ważność z jaką zostaną zapisane do sysloga na maszynie docelowej.


Następnie wchodzimy w menu System / Logging / Rules i klikając w ikonę z plusem dodajemy regułę logowania:

• Topics: opcjonalnie co ma być logowane (możliwe ustawienie kilku warunków, które mają być spełnione, żeby reguła zadziałała). Proponuję ustawić !debug (wszystko oprócz komunikatów debugujących)
• Prefix: prefix z jakim komunikat ma zostać zapisany do sysloga
• Action: nazwa akcji, którą zdefiniowaliśmy w poprzednim kroku

Oczywiście możemy dodać kilka akcji i kilka reguł korzystających z tych akcji, w zależności od źródła komunikatu.

Powyższe operacje możemy też wykonać z linii poleceń, wydając następujące komendy:

/system logging action add bsd-syslog=no name={Name} remote={Remote Address}:{Remote Port} src-address={Src. Address} syslog-facility=daemon syslog-severity=auto target=remote

/system logging add action={Action} disabled=no prefix={Prefix} topics=!debug

2. Konfiguracja serwera syslog

Konfiguracja serwera syslog sprowadza się do dopisania następujących lini do pliku /etc/rc.conf

syslogd_enable="YES"
syslogd_flags="-a moja.domena.pl:* -v -v"

oraz do pliku /etc/syslog.conf

+moja.domena.pl
*.*                                             /var/log/moj.log

Następnie tworzymy plik logu

touch /var/log/moj.log

i restartujemy demona sysloga

/etc/rc.d/syslogd restart

i to wszystko :)

Zamiast nazwy domenowej możemy podać adres IP. Jeśli jednak podajemy domenę, to musi być ona rozwiązywana na adres IP, z którego będą dochodziły pakiety, a ten adres IP musi mieć ustawiony revDNS na tą nazwę domenową. Bez tego nie zadziała, a przynajmniej mi nie chciało. Tak więc jeśli coś się nie zgadza, to należy ustawić odpowiedni IP w polu "Src. Address" w ustawieniach akcji logowania Mikrotika oraz skonfigurować odpowiednio domeny w serwerze DNS (ew. wpisy w pliku /etc/hosts). Druga ważna rzecz to dodanie ":*" po nazwie domeny/IP w pliku /etc/rc.conf w zmiennej syslogd_flags. Bez tego syslogd będzie akceptował jedynie pakiety, które wyszły z portu 514 na urządzeniu źródłowym.


3. Testowanie i rozwiązywanie problemów

Aby przetestować zapis do logu możemy z linii poleceń Mikrotika wydać komendę

:log info "komunikat"

Powinno to poskutować pojawieniem się odpowiedniego wpisu w pliku logu na serwerze. Oczywiście bierzemy pod uwagę czy komunikat o ważności "info" załapie się na naszą regułę.

Po stronie serwera możemy sprawdzić czy pakiety docierają wydając polecenie:

tcpdump -np udp and port 514

Jeśli pakiety docierają ale mimo wszystko nie zapisują się w pliku logu, to należy przede wszystkim sprawdzić czy firewall przepuszcza ruch na tym porcie, oraz czy demon sysloga słucha na porcie 514 UDP. Jak sprawdzić to pierwsze odsyłam do manuala firewalla, natomiast nasłuch na porcie możemy sprawdzić wydając polecenie:

sockstat -4lu | grep syslogd

powinna pojawić się linia w stylu:

root     syslogd    65111 9  udp4   *:514                 *:*

Możemy też sprawdzić czy syslog ma otwarty plik, do którego mają trafiać nasze logi:

lsof | grep syslog

Gdy wszystko zawiedzie można uruchomić demona sysloga w trybie debug, dodając flagę "-d" w zmiennej syslogd_flags w pliku /etc/rc.conf i restartując syslogd

To by było na tyle. To oczywiście najprostsza konfiguracja, ale wystarczająca dla większości potrzeb. Więcej informacji na temat konfiguracji sysloga w systemie FreeBSD jest dostępnych na stronie http://www.freebsd.org/doc/handbook/network-syslogd.html . Oprócz sysloga warto też skonfigurować rotowanie logów, żeby zbyt duże pliki nie zapchały nam dysku. Pamiętajcie też, że przesyłanie logów nie jest szyfrowane a mogą one zawierać potencjalnie niebezpieczne informacje.