This manual refers to Linux Mint 16, kernel 3.11, Wine 1.7.11 and Office 2010!
How to do it the easiest way:
1. install python-software-properties package
> sudo apt-get install python-software-properties
2. add Wine repository
> sudo apt-add-repository ppa:ubuntu-wine/ppa
> sudo apt-get update
3. install Wine package
> sudo apt-get install wine1.7 winetricks
4. install winbind package - without it Office setup fails
> sudo apt-get install winbind
5. setup variables for Wine
> export WINEPREFIX=~/.wine_office_2010
> export WINEARCH=win32
of course you can set another folder as WINEPREFIX
6. install required files
> winetricks dotnet20 msxml6 corefonts
7. mount Office iso as a device
> sudo mount -o loop Office2010.iso /mnt
8. enter Wine shell
> wine cmd
9. change drive and run setup
> F:
F:\>setup.exe
WARNING! drive letter visible in windows cli can be different
10. That's all - setup should go without problems
CRS IT BLOG
różne bardziej lub mniej banalne porady z dziedziny IT
środa, 29 stycznia 2014
środa, 17 października 2012
Icinga z repozytoriów na CentOS 6
This post is available only in polish language.
Poniżej przedstawiam krótki tutorial jak postawić system monitoringu oparty o Centosa 6, Icingę i pnp4nagios. Można oczywiście instalować całość ze źródeł/pakietów dostarczanych przez twórców oprogramowania, ale ten sposób jest bardziej czasochłonny i problematyczny jeśli chodzi o aktualizację do nowszych wersji.
1. Instalujemy czysty system - tego punktu nie będę rozwijał ;)
2. Dodajemy repozytoria RPM Forge i Epel
rpm -Uvh http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
rpm -Uvh http://ftp.ps.pl/pub/Linux/fedora-epel/6/i386/epel-release-6-7.noarch.rpm
3. Instalujemy pakiety
4. Modyfikujemy uprawnienia
usermod -G nagios icinga
chmod -R g+w /var/log/pnp4nagios
chmod -R g+w /var/lib/pnp4nagios
5. Startujemy MySQL-a
/etc/init.d/mysqld start
6. Tworzymy bazę dany Icingi
/usr/share/doc/icinga-idoutils-libdbi-mysql-1.7.2/db/scripts/create_mysqldb.sh
7. Tworzymy bazę danych Icingi-Web (z poziomu wiersza poleceń mysql)
create database icinga_web;
use icinga_web;
\. /usr/share/doc/icinga-web-1.7.2/schema/mysql.sql
grant all privileges on icinga_web.* to 'icinga_web'@'localhost' identified by 'icinga_web';
8. Konfigurujemy Icingę do korzystania z pnp4nagios
- modyfikujemy plik /etc/icinga/icinga.cfg
sed -i '/^process_performance_data=0/ s/0/1/' /etc/icinga/icinga.cfg
sed -i '/^enable_environment_macros=0/ s/0/1/' /etc/icinga/icinga.cfg
sed -i '/^#host_perfdata_command/ s/#//' /etc/icinga/icinga.cfg
sed -i '/^#service_perfdata_command=/ s/#//' /etc/icinga/icinga.cfg
- dodajemy do pliku /etc/icinga/objects/commands.cfg poniższe linie zastępując istniejące
-- cut here --
# 'process-host-perfdata' command definition
define command {
command_name process-host-perfdata
command_line /usr/bin/perl /usr/libexec/pnp4nagios/process_perfdata.pl -d HOSTPERFDATA
}
# 'process-service-perfdata' command definition
define command {
command_name process-service-perfdata
command_line /usr/bin/perl /usr/libexec/pnp4nagios/process_perfdata.pl
}
-- cut here --
9. W pliku /etc/icinga/objects/commands.cfg konfigurujemy polecenia nrpe (odpalanie modułów na zdalnym serwerze)
-- cut here --
# CHECK_NRPE
# this command runs a program $ARG1$ with arguments $ARG $
define command {
command_name check_nrpe_args
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}
# this command runs a program $ARG1$ with no arguments
define command {
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}
-- cut here --
10. Odpalamy usługi i ustawiamy je do uruchamiania przy starcie systemu
/etc/init.d/npcd start
/etc/init.d/ido2db start
/etc/init.d/icinga start
/etc/init.d/httpd start
/etc/init.d/postfix start
chkconfig httpd on
chkconfig npcd on
chkconfig mysqld on
chkconfig icinga on
chkconfig ido2db on
chkconfig postfix on
11. Wyłączamy SElinux
1. vi /etc/selinux/config
zamieniamy
SELINUX=enforcing
na
SELINUX=disabled
2. echo 0 > /selinux/enforce
12. Konfigurujemy firewalla
vi /etc/sysconfig/iptables
dodajemy linię poniżej :OUTPUT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
13. Domyślne adresy i hasła
icinga - http://127.0.0.1/icinga - icingaadmin / icingaadmin
icinga-web - http://127.0.0.1/icinga-web - root / password
pnp4nagios - http://127.0.0.1/pnp4nagios - nagiosadmin / nagiosadmin
Właściwie na początek to wszystko, ale żeby wszystko było jak należy to trzeba sobie dokonfigurować system, zmienić hasła do autoryzacji HTTP, ustawić hasło na roota MySQL-a itp. Nie pisałem tu o tym bo nie jest to celem tego tutorialu. Należy też oczywiście skonfigurować sobie cele do monitorowania dla Icingi, sposób powiadomień itp., bo domyślnie monitorowany jest jedynie system lokalny.
1. Instalujemy czysty system - tego punktu nie będę rozwijał ;)
2. Dodajemy repozytoria RPM Forge i Epel
rpm -Uvh http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
rpm -Uvh http://ftp.ps.pl/pub/Linux/fedora-epel/6/i386/epel-release-6-7.noarch.rpm
3. Instalujemy pakiety
yum install icinga-web.noarch icinga.x86_64 icinga-gui.x86_64 icinga-idoutils-libdbi-mysql.x86_64 mysql-server nagios-plugins.x86_64 nagios-plugins-nrpe.x86_84 php-mysql icinga-web-module-pnp.noarch postfix telnet
usermod -G nagios icinga
chmod -R g+w /var/log/pnp4nagios
chmod -R g+w /var/lib/pnp4nagios
5. Startujemy MySQL-a
/etc/init.d/mysqld start
6. Tworzymy bazę dany Icingi
/usr/share/doc/icinga-idoutils-libdbi-mysql-1.7.2/db/scripts/create_mysqldb.sh
7. Tworzymy bazę danych Icingi-Web (z poziomu wiersza poleceń mysql)
create database icinga_web;
use icinga_web;
\. /usr/share/doc/icinga-web-1.7.2/schema/mysql.sql
grant all privileges on icinga_web.* to 'icinga_web'@'localhost' identified by 'icinga_web';
8. Konfigurujemy Icingę do korzystania z pnp4nagios
- modyfikujemy plik /etc/icinga/icinga.cfg
sed -i '/^process_performance_data=0/ s/0/1/' /etc/icinga/icinga.cfg
sed -i '/^enable_environment_macros=0/ s/0/1/' /etc/icinga/icinga.cfg
sed -i '/^#host_perfdata_command/ s/#//' /etc/icinga/icinga.cfg
sed -i '/^#service_perfdata_command=/ s/#//' /etc/icinga/icinga.cfg
- dodajemy do pliku /etc/icinga/objects/commands.cfg poniższe linie zastępując istniejące
-- cut here --
# 'process-host-perfdata' command definition
define command {
command_name process-host-perfdata
command_line /usr/bin/perl /usr/libexec/pnp4nagios/process_perfdata.pl -d HOSTPERFDATA
}
# 'process-service-perfdata' command definition
define command {
command_name process-service-perfdata
command_line /usr/bin/perl /usr/libexec/pnp4nagios/process_perfdata.pl
}
-- cut here --
9. W pliku /etc/icinga/objects/commands.cfg konfigurujemy polecenia nrpe (odpalanie modułów na zdalnym serwerze)
-- cut here --
# CHECK_NRPE
# this command runs a program $ARG1$ with arguments $ARG $
define command {
command_name check_nrpe_args
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}
# this command runs a program $ARG1$ with no arguments
define command {
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}
-- cut here --
10. Odpalamy usługi i ustawiamy je do uruchamiania przy starcie systemu
/etc/init.d/npcd start
/etc/init.d/ido2db start
/etc/init.d/icinga start
/etc/init.d/httpd start
/etc/init.d/postfix start
chkconfig httpd on
chkconfig npcd on
chkconfig mysqld on
chkconfig icinga on
chkconfig ido2db on
chkconfig postfix on
11. Wyłączamy SElinux
1. vi /etc/selinux/config
zamieniamy
SELINUX=enforcing
na
SELINUX=disabled
2. echo 0 > /selinux/enforce
12. Konfigurujemy firewalla
vi /etc/sysconfig/iptables
dodajemy linię poniżej :OUTPUT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
13. Domyślne adresy i hasła
icinga - http://127.0.0.1/icinga - icingaadmin / icingaadmin
icinga-web - http://127.0.0.1/icinga-web - root / password
pnp4nagios - http://127.0.0.1/pnp4nagios - nagiosadmin / nagiosadmin
Właściwie na początek to wszystko, ale żeby wszystko było jak należy to trzeba sobie dokonfigurować system, zmienić hasła do autoryzacji HTTP, ustawić hasło na roota MySQL-a itp. Nie pisałem tu o tym bo nie jest to celem tego tutorialu. Należy też oczywiście skonfigurować sobie cele do monitorowania dla Icingi, sposób powiadomień itp., bo domyślnie monitorowany jest jedynie system lokalny.
środa, 12 września 2012
Synchronizacja plików pomiędzy dwoma serwerami przy wykorzystaniu lsyncd
This post is available only in polish language.
Tworząc aplikacje webowe często zdarza się, że chcemy uruchamiać je na większej ilości serwerów, czy to w celu redundancji czy rozłożenia obciążenia. O ile z bazami danych sytuacja jest prosta i możemy skorzystać z wbudowanej w MySQL-a replikacji danych, o tyle z plikami zapisywanymi w systemie jest już nieco gorzej. Pierwsze co przychodzi na myśl to rsync, ale musi być on odpalany np. na cronie co zadany interwał, co niepotrzebnie zabiera zasoby systemowe. Skuteczniej było by podejmować akcję synchronizacji, dopiero w momencie jakichkolwiek zmian w plikach z interesujących nas lokalizacji. Taką funkcjonalność zapewnia lsyncd. Działa on jako demon i wykorzystuje system zdarzeń inotify do monitorowania zmian w plikach i podejmowania ewentualnej akcji. Synchronizacja plików może być w ramach tego samego serwera lub mogą być one synchronizowane z systemem zdalnym. Konfiguracja tego oprogramowania jest bardzo prosta i sprowadza się do kilku kroków:
lsyncd /etc/lsyncd.conf
Należy zwrócić uwagę na parametr "delete" i opcję rsyncOpts. Pierwszy z nich wyłącza usuwanie plików nieistniejących na drugim serwerze. Jest to o tyle ważne, że w przypadku kiedy mamy działający serwer i dostawiamy drugi, konfigurując go od zera, może zaistnieć sytuacja, że na nowym serwerze nie mamy plików w ścieżce synchronizacji, ponieważ są one na bieżąco uploadowane na serwer nr 1. Wtedy odpalenie lsyncd na drugim serwerze spowoduje usunięcie plików na serwerze nr 1. Oczywiście możemy zatroszczyć się o pliki i przegrać je z serwera 1 na 2 i dopiero wtedy odpalić lsyncd - wtedy opcja "delete" nie jest nam potrzebna. Uważam jednak, że taka konfiguracja nie jest bezpieczna. Z kolei parametr "rsyncOpts" ustawia opcję z jakimi będzie odpalony rsync (w podanej konfiguracji jest on wykorzystywany do synchronizacji). Domyślnie ma on wartość "-lts" natomiast dodatkowe "u" powoduje, że pliki z nowszymi czasami modyfikacji nie będą nadpisywane starszymi wersjami. Wspomnę jeszcze parametr "delay" - odpowiada on za opóźnienie z jakim lsyncd zacznie synchronizować pliki.
Lsyncd może też działać w trybie nie-demona oraz przyjmuje parametry z linii poleceń. Pozwala to na łatwe zdebugowanie problemów. Aby zapoznać się ze szczegółami polecam sięgnąć do dokumentacji.
- zainstalowanie, właściwymi dla systemu poleceniami, pakietu lsyncd w wersji >=2.06
- wygenerowanie na obu serwerach kluczy ssh
- dopisanie klucza publicznego przeciwnego serwera do zaufanych w pliku ~/.ssh/authorized_keys2
- wykonanie połączenia ssh do przeciwnego serwera w celu zaakceptowania kluczy (zostaną dopisane do pliku ~/.ssh/known_hosts)
- wyedytowania pliku /etc/lsyncd.conf i dopisania do niego zawartości:
sync {
default.rsync,
source = "/home/user/files/",
target = "root@192.168.1.1:files/",
rsyncOpts = "-ltus",
delete = false,
delay = 5,
}
na drugim serwerze tworzymy taki sam plik tylko z oczywistych względów ustawiamy IP pierwszego serwera w polu "target"
- uruchomienia na obu serwerach demona lsyncd:
lsyncd /etc/lsyncd.conf
Należy zwrócić uwagę na parametr "delete" i opcję rsyncOpts. Pierwszy z nich wyłącza usuwanie plików nieistniejących na drugim serwerze. Jest to o tyle ważne, że w przypadku kiedy mamy działający serwer i dostawiamy drugi, konfigurując go od zera, może zaistnieć sytuacja, że na nowym serwerze nie mamy plików w ścieżce synchronizacji, ponieważ są one na bieżąco uploadowane na serwer nr 1. Wtedy odpalenie lsyncd na drugim serwerze spowoduje usunięcie plików na serwerze nr 1. Oczywiście możemy zatroszczyć się o pliki i przegrać je z serwera 1 na 2 i dopiero wtedy odpalić lsyncd - wtedy opcja "delete" nie jest nam potrzebna. Uważam jednak, że taka konfiguracja nie jest bezpieczna. Z kolei parametr "rsyncOpts" ustawia opcję z jakimi będzie odpalony rsync (w podanej konfiguracji jest on wykorzystywany do synchronizacji). Domyślnie ma on wartość "-lts" natomiast dodatkowe "u" powoduje, że pliki z nowszymi czasami modyfikacji nie będą nadpisywane starszymi wersjami. Wspomnę jeszcze parametr "delay" - odpowiada on za opóźnienie z jakim lsyncd zacznie synchronizować pliki.
Lsyncd może też działać w trybie nie-demona oraz przyjmuje parametry z linii poleceń. Pozwala to na łatwe zdebugowanie problemów. Aby zapoznać się ze szczegółami polecam sięgnąć do dokumentacji.
poniedziałek, 6 sierpnia 2012
Konwersja maszyny wirtualnej HVM na PVM w Citrix XenServer
This post is available only in polish language.
Jeśli posiadamy uruchomione na serwerze wirtualne maszyny korzystające ze sprzętowej wirtualizacji, może zajść potrzeba ich konwersji na wersję parawirtualizowaną. Np. w celu przeniesienia ich na serwer nie posiadający wsparcia dla sprzętowej wirtualizacji. Poniżej opis jak to zrobić dla Citrixa XenServer w wersji 6 (przynajmniej na takiej testowałem)
1. znajdujemy uid maszyny do konwersji
xe vm-list name-label=<nazwa>
2. edytujemy bootloader partycji z poziomu Dom0
xe-edit-bootloader -u <uuid> -p <numer partycji np=1>
lub z poziomu systemu
vi /boot/grub/grub.conf
3. tworzymy wpis z jądrem linuxa przygotowanym pod xena (należy najpierw zainstalować odpowiedni pakiet) i ustawiamy parametr "default" na ten wpis
title Xen Kernel
root (hd0,0)
kernel /boot/vmlinuz-2.6.24-19-xen ro root=LABEL=/ quiet splash
initrd /boot/initrd.img-2.6.24-19-xen
quiet
4. wykonujemy następujące polecenia z poziomu Dom0
xe vm-param-set uuid=<uuid> HVM-boot-policy=
xe vm-param-set uuid=<uuid> PV-bootloader=pygrub
xe vm-param-set uuid=<uuid> PV-args="console=hvc0"
5. ustawiamy dysk maszyny wirtualnej jako botowalny
xe vm-disk-list uuid=<uuid>
xe vbd-param-set uuid=<vbd uuid> bootable=true
6. odinstalowujemy "zwykły" kernel - w moim przypadku po aktualizacji był on ustawiany jako domyślny, system nie startował i trzeba było edytować parametry gruba (jak w pkt.2)
1. znajdujemy uid maszyny do konwersji
xe vm-list name-label=<nazwa>
2. edytujemy bootloader partycji z poziomu Dom0
xe-edit-bootloader -u <uuid> -p <numer partycji np=1>
lub z poziomu systemu
vi /boot/grub/grub.conf
3. tworzymy wpis z jądrem linuxa przygotowanym pod xena (należy najpierw zainstalować odpowiedni pakiet) i ustawiamy parametr "default" na ten wpis
title Xen Kernel
root (hd0,0)
kernel /boot/vmlinuz-2.6.24-19-xen ro root=LABEL=/ quiet splash
initrd /boot/initrd.img-2.6.24-19-xen
quiet
4. wykonujemy następujące polecenia z poziomu Dom0
xe vm-param-set uuid=<uuid> HVM-boot-policy=
xe vm-param-set uuid=<uuid> PV-bootloader=pygrub
xe vm-param-set uuid=<uuid> PV-args="console=hvc0"
5. ustawiamy dysk maszyny wirtualnej jako botowalny
xe vm-disk-list uuid=<uuid>
xe vbd-param-set uuid=<vbd uuid> bootable=true
6. odinstalowujemy "zwykły" kernel - w moim przypadku po aktualizacji był on ustawiany jako domyślny, system nie startował i trzeba było edytować parametry gruba (jak w pkt.2)
To właściwie wszytko co mi było potrzebne, żeby zmienić tryb wirtualizacji dla moich maszyn Linuxowych. W przypadku problemów więcej informacji można znaleźć pod poniższymi adresami:
poniedziałek, 21 maja 2012
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
poniedziałek, 16 kwietnia 2012
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
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
środa, 11 kwietnia 2012
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.
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.
https://github.com/codepill/script-utilities/tree/master/github-repository-tools
Przed skorzystaniem przeczytaj plik README.
Subskrybuj:
Posty (Atom)