PostgreSQL ozyskanie miejsca po updacie

W wyniku updejtu postgresa zjadło miejscie go nie oddało. Baza nagle zajmuje jeszcze raz tyle ile zajmowała. Na full vacuum nie mamy miejsca co robić, jak z tym żyć? Sposobem na odzyskanie miejsca jest poniższa procedura

1. Backup wszystkich baz na serwerze postgresql

Upewnij się, że posiadasz odpowiednią ilość miejsca na serwerze, jeśli nie podmapuj zasób sieciowy, dysk usb, itp. 

su - postgres

pg_dumpall | gzip -9 > /some/partition/all.dbs.out.gz

2. Backup plików konfiguracyjnych

Sprawdzamy nasz data_directory

sudo -u postgres psql

postgres=# SHOW data_directory;

Output

       data_directory       

------------------------------

/var/lib/postgresql/9.x/main

(1 row)

Kopiujemy pliki konfiguracyjne (mogą także być w /etc/postgesql)

cp /path/to/postgresql/data_directory/*.conf /some/partition/

3. Stop Postgresql

pg_ctl -D /path/to/postgresql/data_directory stop

lub

/etc/init.d/postgresql stop

W tym miejscu warto sobie zrobić wcześniej backup plików w katalogu data_directory na wszelkie zaś:

tar -zcfv  /path/to/destination/data_dierctory.tar.gz /path/to/postgresql/data_directory

4. Wymazanie zawartości data directory

rm -Rf /path/to/postgresql/data_directory/*

5. Uruchomienie initdb to reinicjowania data directory

su - postgres

/usr/lib/postgresql/9.x/bin/initdb -D /path/to/postgresql/data_directory

6. Przywrócenie plików konfiguracyjnych

(jeśli wcześniej  były w /etc/postgresql to wystarczy)

cp /some/partition/*.conf /path/to/postgresql/data_directory/*.conf

7. Start Postgresql

pg_ctl -D /path/to/postgresql/data_directory start

lub

/etc/init.d/postgresql start

8. Przywrócenie bazy danych z backupu

su - postgres

gunzip /some/partition/all.dbs.out.gz

psql -f /some/partition/all.dbs.out

Jeśli mamy problem i nie chce przyjąć hasła dla użytkownika postgres robimy tak:

Kopiujemy plik pg_hba.conf

cp pg_hba.conf pg_hba.conf-backup

Umieszczamy/odhaszowujemy poniższą linie jako pierwszą nie zahaszowaną

local all all trust

restart  PostgreSQL server

/etc/init.d/postgresql restart

Łączymy się jako użytkownik postgres:

psql -U postgres

Resetujemy hasło:

ALTER USER postgres with password 'my_secure_password';

Przywracamy pg_hba.conf:

cp pg_hba.conf-backup pg_hba.conf

Restartujemy PostgreSQL

sudo /etc/init.d/postgresql restart

Sprawdzamy czy baza zajmuje tyle co powinna i koniec tematu.

Reset hasła root MYSQL

Zdarzyło się zapomnieliśmy hasła root`a do Mysql`a i co teraz? Spokojna głowa chwila przestoju i mamy ustawione nowe hasło do zarządzania serwerem.

Zatrzymujemy mysql`a

/etc/init.d/mysql stop

Sprawdzamy, czy jakieś procesy Mysql jeszcze żyją:

ps aux | grep mysql

root      6539  0.0  0.0   4336  1496 ?        S    11:05   0:00 /bin/sh /usr/bin/mysqld_safe
mysql     6888 14.2  4.8 886556 191748 ?       Sl   11:05   2:39 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306

Zabijamy uruchomione procesy:

kill -9 6539 6888

Uruchamiamy mysql`a w trybie pomijania uprawnień

mysqld_safe --skip-grant-tables

160712 11:03:51 mysqld_safe Can't log to error log and syslog at the same time.  Remove all --log-error configuration options for --syslog to take effect.
160712 11:03:51 mysqld_safe Logging to '/var/log/mysql/error.log'.
160712 11:03:51 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql


Jeśli pojawiło się to co powyżej  logujemy się do Mysql`a i zmieniamy hasło:

mysql --user=root mysql

update user set Password=PASSWORD('nowe-haslo') where user='root';
flush privileges;

Sprawdzamy PIDy procesów mysql`a

ps aux | grep mysql
root      6111  0.0  0.0   4336  1504 pts/3    S+   11:03   0:00 /bin/sh /usr/bin/mysqld_safe --skip-grant-tables
mysql     6473  0.3  1.1 493628 46328 pts/3    Sl+  11:03   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --skip-grant-tables --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306


Zabijamy uruchomione procesy:

kill -9 6111 6473

Uruchamiamy demona w normalnym trybie

/etc/init.d/mysqld restart

Sprawdzamy, czy możemy się zalogować nowym hasłem

mysql -p

Jeśli wszystko zrobiliśmy dobrze, to właśnie zalogowaliśmy się zmienionym hasłem.

APACHE, PHP i MYSQL brak polskich znaków po przeniesieniu na inny serwer

Przenosimy stronę ot taka fanaberia. Pliki skopiowane i przeniesione w miejsce docelowe, baza danych zaimportowana, virualka skonfigurowana. Pierwszy test. Wyświetla się strona, dane z bazy wyświetla, lecz polskie znaki się nie wyświetlają. Szybka instrukcja naprawy.
Edytujemy dwa pliki i zastępujemy na podkreślone wpisy fragmenty konfiguracji:

/etc/apache2/conf-available/charset.conf

# Read the documentation before enabling AddDefaultCharset.
# In general, it is only a good idea if you know that all your files
# have this encoding. It will override any encoding given in the files
# in meta http-equiv or xml encoding tags.

#AddDefaultCharset UTF-8
AddDefaultCharset ISO-8859-2

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Następnie:

/etc/php5/apache2/php.ini

..

; PHP's default character set is set to UTF-8.

; http://php.net/default-charset

;default_charset = "UTF-8"

default_charset = "ISO-8859-2"

..

Następnie przeładowujemy apache:

/etc/init.d/apache2 restart

Odświeżamy stronę i mamy już polskie znaki prawidłowo wyświetlone.

Automatyczna archiwizacja konfiguracji mikrotików z wielu lokalizacji

Mamy lokalizację główną + lokalizacje zdalne na lokalizacjach zdalnych mamy mikrotiki, które zarządzają całym bałaganem sieciowym. Chcemy mieć pewność, ze nasza konfiguracja w razie awarii, lub jakieś zmiany będzie do odzyskania. W takim razie robimy automatyczny backup konfiguracji mikrotików w dowolnej ilości lokalizacji.

W pierwszej kolejności konfigurujemy mikrotiki, żeby codziennie robiły backup swojej konfiguracji. Logujemy się do mikrotika  z poziomu wiersza poleceń wykonujemy następujące kroki.

Dodajemy do scheludera zadanie wykonania backupu o nazwie LOK1.backup (każą linijkę wklejamy oddzielnie):

/system scheduler
add name="backup" on-event="system backup save name=LOK1.backup" \
start-date=jan/01/1970 start-time=00:00:00 interval=10h comment="" \
disabled=no

Wykonujemy pierwszy backup ręcznie:

/system backup save name=LOK1.backup

Sprawdzamy, czy mamy serwis ftp aktywny (brak X znaczy że jest ok, w przeciwnym razie musimy go odblokwać):

/ip service print
Flags: X - disabled, I - invalid 
 #   NAME      PORT ADDRESS                                        CERTIFICATE   
 0   telnet      23
 1   ftp         21
 2   www         80
 3   ssh         22
 4 X www-ssl    443                                                none          
 5 X api       8728
 6   winbox    8291
 7   api-ssl   8729                                                none        

Dodajemy Grupę, politykę i użytkownika backup z hasłem i zezwalamy mu się łączyć z naszego adresu IP lub sieci (192.168.0.13/32):

/user group
add name="ftp" policy=ftp,!local,!telnet,ssh,!reboot,read,write,!policy,!test,!winbox,!password,web,!sniff,sensitive
/user
add address=192.168.0.13/32 comment="FTP backup" disabled=no group=ftp name="backup"
set [find name="backup"] password="Backup_Password"


Po stronie serwera, na który chcemy wykonać backup tworzymy plik z adresami ip i nazwą lokalizacji:

----------------------------------mikrotik.txt ----------------------------------
121.121.121.121 LOK1
122.122.122.122 LOK2
..
..
..
130.130.130.130 LOK
EOF
-----------------------------------END-OF-FILE---------------------------------

Pamiętajmy, żeby po EOF już nie było pustej linii. Pierwsza kolumna jest adresami ip naszych mikrotików, a druga nazwami lokalizacji, a także nazwami katalogów, gdzie backup trafi,oraz nazwami plików z backupem znajdujących się na mikrotikach. Następnie w tym samym katalogu (domyślnie jest to /backup/mikrotik. jak będzie inny wystarczy zmienić ścieżkę w zmiennej) umieszczamy poniższy skrypt i nadajemy mu prawa do wykonywania chmod +x nazwa_skryptu.sh


#!/bin/bash
echo "##########################################################################"
echo "##########################################################################"
echo "########                                                          ########"
echo "########                  MIKROTIK BACKUP SCRIPT                  ########"
echo "########                           V1.0                           ########"
echo "########                        13.05.2015                        ########"
echo "########                   by: Grzegorz Zalewski                  ########"
echo "########          http://informatycznezycie.blogspot.com          ########"
echo "########                                                          ########"
echo "##########################################################################"
echo "##########################################################################"

#Zmienne
USER=backup
PASSW=Backup_Password
data=`date +%F`
date=`date +%Y-%m-%d_%H_%M`
dir=/backup/mikrotik

#utwórz katalog z datą
cd $dir
mkdir $data
cd $dir/$data


#utwórz plik lokalizacji z pliku mikrotik.txt
awk '{print $2}' < $dir/mikrotik.txt > $dir/lokalizacja.tmp

#utwórz katalogi w pętli z pliku oddzialów
while read line
do
mkdir $line
#plik z jakiego ma petla korzytstać
done <$dir/lokalizacja.tmp

#połącz sie z oddziałami i pobierz pliki pętla
while read line
do
#wyciągnij pojedynczą linie z pliku mikrotik
echo $line > line.tmp
#utworz plik z adresem ip
awk '{print $1}' < line.tmp > ip.tmp
#utworz plik z nazwa lokalizacji
awk '{print $2}' < line.tmp > lok.tmp
#stwórz zmienne
ip=$(< ip.tmp)
odd=$(< lok.tmp)

#skrypt ftp
#passive - niektóre mikrotiki w trybie aktywnym nie listuja katalogow-wymuszamy tryb passive
#get * - pobierz plik i zapisz go w danej lokalizacji
ftp -v -n $ip >> $dir/$data.transfer.log <<SCRIPT
user $USER $PASSW
binary
passive
dir
get $lok.backup $dir/$data/$lok/$lok.backup.$date
quit
SCRIPT
#plik z jakiego ma petla korzytstać
done < $dir/mikrotik.txt

#usuń pliki tymczasowe
cd $dir
rm *.tmp
cd $dir/$data
rm  *.tmp

Jeśli wszystko wykonaliśmy poprawnie, to w katalogu (w naszym przypadku /backup/mikrotik)

powinien powstać katalog DATY np.: 2016-05-13 a w nim katalogi LOK1, LOK2, LOK3 itp, Wewnątrz powinny znajdować się pliki z backupem w nazwie zgodne z lokalizacja i ze znacznikiem czasowym ściągnięcia w nazwie. Jeśli plików brakuje, to w pierwszej kolejności sprawdzamy plik logu i szukamy informacji, co się stało. Następnie najlepiej spróbować połączyć się ręcznie z linii komend ftpem do mikrotika. Jeśli to nie pomoże należny jeszcze po stronie mikrotika sprawdzić:

- czy jest włączony conntrac i reguły do niego (established,related) 

- czy"Service ports" FTP jest zaznaczony

- czy pomiędzy klientem i serwerem jest stosowany jakiś NAT, albo szyfrowane połączenie

Gdy ostatecznie dopniemy kwestie konfiguracyjne i wszystko zadziała jak należny wystarczy dodać skrypt do crona. Ot cała robota.

Oczywiście skrypt można wykorzystać nie tylko do archiwizacji backupu konfiguracji mikrotików. Po niewielkich modyfikacjach może mieć różnorakie zastosowanie.

Hurtowa zmiana praw do plików i katalogów

Instalujemy sobie stronkę np. wordpress`a i musimy globalnie dla wszystkich katalogów ustawić prawa 775, a dla plików 664 . Ręcznie to robiąc katalog po katalogu zajmie nam mnóstwo czasu. Za pomocą tych dwóch komend zrobimy to w kilka sekund. Przechodzimy do katalogu, w którym chcemy dokonać zmian.

Dla katalogów w folderze, w którym się znajdujemy
find . -type d -exec chmod 775 {} \;

Dla plików w folderze, w którym się znajdujemy
find . -type f -exec chmod 664 {} \;

Przenoszenie danych/migracja z uwzględnieniem hardlinków i właścicieli

Trzeba zmigrować serwer, lub przenieść dane (wyrównać) ze starej maszyny na nową. Podczas kopiowania wychodzi na maszynie docelowej więcej objętościowo danych, niż na źródłowej. Okazuje się, że winnymi są hard linki w systemie plików. Standardowo rsync lub scp traktuje hard linki jako pliki. Pomocny w kopiowaniu tego lub nawet do backupu przychodzi rsync. Za pomocą polecenia skopiujemy hard linki jako powiązania, a nie jako osobny plik:

rsync -az -H --delete --progress --numeric-ids /sciezka_kat/folderXYZ user@serwerzdalny:/sciezka_kat/

gdzie:

-a jest używane w trybie archiwizującym. Na stronie man jest ona wyjaśniona jako “sposób na zrobienie kopii zapasowej rekursywnie i na zachowanie 'prawie' wszystkiego". Wspomina się jeszcze, że nie są zachowane hard linki ze względu na złożoność przetwarzania.
-z jest używany, aby kompresować dane, które musi “przenieść” lub skopiować, opcja czyni
proces kopiowania szybszym, ponieważ dane przenoszone są mniejsze niż ich rzeczywisty rozmiar.
-H kopiuje hard linki jako hard linki
--delete jest używane, aby usunąć docelowe pliki, które już nie istnieją na źródłowym systemie. W tym przypadku utrzymujemy lustrzaną kopie pomiędzy kopiowanymi folderami
--numeric-ids kopiuje grupy i użytkowników do plików i katalogów
--progress pokazuje postęp kopiowania

Kopiowanie może potrwać trochę wolniej niż standardowo, lecz mamy skopiowane katalogi 1:1 i nie mnożą nam się nadprogramowe gigabajty na dysku. A jeśli mamy wcześniej skopiowany "spuchnięty" docelowy folder, to to nam posprząta :)

Postfix przekierowanie maili od danego nadawcy do innego odbiorcy

Pojawiła się potrzeba, żeby maile wysyłane przez xyz@nadawca.jakaś.domena.pl trafiały tylko i wyłącznie na adres abc@odbiorca.mojadomena.pl. Potrzeba potrzebą, ale chciałem, żeby było to zrobione w najprostszy sposób, bez zbyt dużej kombinacji i żeby na przyszłość można dopisywać więcej takich wyjątków. Znalazłem kilka sposobów, lecz tylko jeden spełnił moje wymagania.
Zaczynamy od dodania wpisu (ew sprawdzenia czy taki wpis już jest) do pliku main.cf:

nano /etc/posttfix/main.cf

smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access

tworzymy/modyfikujemy plik sender_access

touch /etc/postfix/sender_access
nano /etc/postfix/sender access

dodajemy wpis do sender_access:

xyz@nadawca.jakaś.domena.pl redirect abc@odbiorca.mojadomena.pl

wydajemy polecenia:
postmap  /etc/postfix/sender_access
/etc/init.d/postfix restart


Testujemy czy działa. Jeśli przyjdzie taka potrzeba dodajemy następne wpisy w pliku /etc/postfix/sender_access. 

HP laserJet 1020 i Raspberry PI jako serwer wydruku

Mamy sobie Raspberry PI jest tam sobie zainstalowany Raspbian, OSMC, czy Rasbmc. Chcielibyśmy także drukować po sieci, a nasza drukarka takowej opcji nie ma, a na dedykowane urządzenie do tych zadań szkoda nam kasy. Wykorzystajmy do tego zadania Raspberry PI. W pierwszej kolejności musimy zainstalować niezbędne rzeczy:

sudo aptitude update
sudo aptitude install tix groff cups

Następnie pobieramy i kompilujemy foo2zjs żeby nasza drukarka mogła skorzystać z cups:

wget -O foo2zjs.tar.gz http://foo2zjs.rkkda.com/foo2zjs.tar.gz
tar zxf foo2zjs.tar.gz
cd foo2zjs
make

W tym momencie musimy pobrać firmware do drukarki i bez tego kroku nic z drukowania nie będzie:

./getweb 1020

W tym momencie przystępujemy do instalacji CUPS:

make install install-hotplug cups

Teraz przystępujemy do konfiguracji CUPS. Musimy zedytować plik konfiguracyjny:

/etc/cups/cupsd.conf

 Listen localhost:631 zamieniamy na Port 631

oraz w selcjach <Location> dodajemy wpis:
Allow @LOCAL

Restartujemy CUPS:

/etc/init.d/cups restart

Dodajemy użytkownika uprawnionego do drukowania do grupy lpadmin:


sudo usermod -a -G lpadmin osmc



Podłączamy nasza drukarkę HP do Raspberry. Następnie w przeglądarce internetowej wpisujemy adres: adres.ip.raspberry:631 (np. 192.168.1.234:631). Przechodzimy do zakładki Administration/Administracja (zostaniemy poproszeni o użytkownika systemowego i hasło -> w tym przypadku bedzie to osmc) i wybieramy Drukarki . Klikamy na "Wyszukiwanie drukarek" i powiśmy zobaczyć naszą drukarkę  na liście do wyboru. Teraz wystarczy kliknąć „Dodaj drukarkę” by przejść do kreatora/ustawień. Pojawi się lista Sterowników do wyboru to wybieramy "HP LaseJet 1020 Foomatic/foo2zjs (recommended) en". N Następnym ekranie będziemy mieli listę opcji do wyboru na ekranie . Zostawiamy ustawienia domyślne. I mamy drukarkę dodaną. Teraz z poziomy www spróbujmy wydrukować stronę testową. Jeśli się udało to możemy dodać drukarkę w Windowsie, jeśli nie to zaglądamy do liku laga i szukamy co mamy źle. Jeśli wszystko jest ok to pozostało dodać drukarkę w Windowsie:  Dodaj dukarkę -> Dodaj drukarkę sieciową, bezprzewodową, lub Bluetooth -> Drukarki, której szukam nie ma na liście -> Wybierz drukarkę udostępnioną według nazwy -> wpisujemy adres drukarki (np: http:\\192.168.1.234:631\printers\printer_name a najprościej - kopiujemy adres z przeglądarki internetowej z konf. cups po wejściu na drukarkę. Pamiętajmy o ew zamienieniu https na http). System poprosi nas o wybranie sterownika - trzeba mieć drukarkę wczesniej zainstalowana w systemie. Po dodaniu drukarki powinniśmy bez problemu móc drukować. Jesli jednak wydruk nie wychodzi, to zaglądamy do pliku logu cups i googlujemy problem. Bezstresowego drukowania z sieci :)

DELL PowerEdge 2850 - stary kontroler RAID LSI MEGARAID - ocena stanu RAID i monitoring NAGIOS

Kontynuując kwestię kontroli statusu kontrolerów RAID. Warto wspomnieć o starszych rozwiązaniach stosowanych w serwerach np. DELL POWEREDGE 2850 kontroler MEGARAID, który poznamy po module (lsmod):
megaraid_mbox

Żeby zobaczyć jaki jego jest stan to skorzystamy z narzędzia megarc, do ściągniecia ze strony LSI:
http://www.lsi.com/search/pages/Results.aspx?k=megarc

Ściągamy plik i rozpakowujemy go, a następnie nadajemy plikom prawa do wykonania:

chmod +x megarc*

Do ocenienia statusu RAIDU jak i stanu dysków wystarcza nam te dwie komendy:

./megarc -dispCfg -a0
**********************************************************************
              MEGARC MegaRAID Configuration Utility(LINUX)-1.11(12-07-2004)
              By LSI Logic Corp.,USA
        **********************************************************************
          [Note: For SATA-2, 4 and 6 channel controllers, please specify
          Ch=0 Id=0..15 for specifying physical drive(Ch=channel, Id=Target)]

        Type ? as command line arg for help


        Finding Devices On Each MegaRAID Adapter...
        Scanning Ha 0, Chnl 1 Target 15
**********************************************************************
              Existing Logical Drive Information
              By LSI Logic Corp.,USA
        **********************************************************************
          [Note: For SATA-2, 4 and 6 channel controllers, please specify
          Ch=0 Id=0..15 for specifying physical drive(Ch=channel, Id=Target)]

          Logical Drive : 0( Adapter: 0 ):  Status: OPTIMAL
        ---------------------------------------------------
        SpanDepth :01     RaidLevel: 1  RdAhead : Adaptive  Cache: DirectIo
        StripSz   :064KB   Stripes  : 2  WrPolicy: WriteBack

        Logical Drive 0 : SpanLevel_0 Disks
        Chnl  Target  StartBlock   Blocks      Physical Target Status
        ----  ------  ----------   ------      ----------------------
        0      00    0x00000000   0x0887c000   ONLINE
        0      01    0x00000000   0x0887c000   ONLINE
**********************************************************************
              Existing Logical Drive Information
              By LSI Logic Corp.,USA
**********************************************************************
          [Note: For SATA-2, 4 and 6 channel controllers, please specify
          Ch=0 Id=0..15 for specifying physical drive(Ch=channel, Id=Target)]

          Logical Drive : 1( Adapter: 0 ):  Status: OPTIMAL
        ---------------------------------------------------
        SpanDepth :01     RaidLevel: 1  RdAhead : Adaptive  Cache: DirectIo
        StripSz   :064KB   Stripes  : 2  WrPolicy: WriteBack

        Logical Drive 1 : SpanLevel_0 Disks
        Chnl  Target  StartBlock   Blocks      Physical Target Status
        ----  ------  ----------   ------      ----------------------
        1      02    0x00000000   0x22ec0000   ONLINE
        1      03    0x00000000   0x22ec0000   ONLINE
Oraz polecenie:
./megarc -AllAdpInfo

Wyciąga nam informacje, na temat fizycznych dysków w razie problemów z RAIDem (reszta informacji łatwo dostępna w GOOGLE).

Teraz, jak już wiemy jak stan RAID wygląda dodajemy nasza maszynę do NAGIOS`a.
Musimy pliki megarc i megarc.bin wrzucić do kalalogu pluginów nagiosa /usr/lib64/nagios/plugin (w przypadku 64 bitowych systemów). Następnie ze strony:
http://exchange.nagios.org/directory/Plugins/Hardware/Storage-Systems/RAID-Controllers/LSI-Mega-RAID-plugin-for-32-2Dbit-and-64-2Dbit-systems/details

Ściągamy plugin i umieszczamy w tym samym katalogu co powyżej i nadajemy mu nazwę chek_lsi_megaraid i prawo do wykonywania. Do pliku konfiguracyjnego NRPE /etc/nagios/nrpe.cfg dodajemy taki wpis:
command[check_raid]=/usr/bin/sudo /usr/lib64/nagios/plugins/check_lsi_megaraid

Restartujemy NRPE:
service nrpe restart

Żeby prawidłowo zadziałał plugin musimy w sudoers dodać mu odpowiednie wpisy:
visudo
Defaults:nagios !requiretty
nagios  ALL=(ALL)       NOPASSWD:  /usr/lib64/nagios/plugins/

Następnie po stronie serwera NAGIOS`a w pliku konfiguracyjnym hosta dodajemy:
define service{
        use                             graphed-service         ; Name of service template to use
        host_name                       hostname
        service_description             Raid Status
        check_command                   check_nrpe!5666!check_raid

Restart serwera NAGIOS:
service nagios restart

I mamy na bieżąco podgląd do statusu naszego RAID`a.

Wyciągamy LDAPem dane z AD

Odkopałem stary nieopublikowany post :). Cała operacja w tym przypadku była przydatna przy migracji z LDAP do AD. Posłużyłem się skryptem, który importował użytkowników do Zimbry. Zmodyfikowany skrypt ldap.sh, wyciąga nazwy użytkowników z AD do pliku, a następnie, za pomocą nazw użytkowników wyciąga dane nt. każdego usera. Bazowałem na skrypcie znalezionym na stronie

http://forums.zimbra.com/administrators/30856-active-directory-script-import-users-zimbra.html

--------------------ldap.sh--------------------

##DATA MODYFIKACJI 19.04.2014
#ZMIENNE
LDAPSEARCH=/usr/bin/ldapsearch
DOMAIN_NAME="przyklad.pl"
TMP_DIR=/root/ldap_acc
ADS_TMP=$TMP_DIR/users.lst
ADS_TMP2=$TMP_DIR/WYNIK.TXT
# Server values
LDAP_SERVER="ldap://xxx.xxx.xxx.xxx"
BASEDN="dc=przyklad,dc=pl"
BINDDN="CN=user,CN=Users,DC=przyklad,DC=pl"
BINDPW="haslo"
FILTER="(&(sAMAccountName=*)(objectClass=user)(givenName=*))"
#FILTER="(&(sAMAccountName=*))"
FIELDS="sAMAccountName"
FILTER2="(&(sAMAccountName=*)(objectClass=user)(givenName=*))"
FIELDS2="sAMAccountName mail carLicense"

# CZYSZCZENIE ZAWARTOŚCI KARALOGU  /root/ldap_acc/
echo "Czyszczenie zawartosci katalogu ze starych wynikow ..."
rm -f $ADS_TMP $ADS_TMP2
sleep 3s

# POBIERANIE UZYTKOWNIKÓW Z AD i zapisanie ich w /root/ldap_acc/users.lst
echo -n "Odpytywanie AD... "
$LDAPSEARCH -x -H $LDAP_SERVER -b $BASEDN -D "$BINDDN" -w $BINDPW "$FILTER" $FIELDS | \
#  grep "@$DOMAIN_NAME" | \
   grep "sAMAccountName:" | \
  awk '{print $2}' | \
 cat  > $ADS_TMP
sleep 2s
echo "Znaleziono `cat $ADS_TMP | wc -l` użytkowników ($ADS_TMP)"
sleep 3s

#$LDAPSEARCH -x -H $LDAP_SERVER -b $BASEDN -D "$BINDDN" -w $BINDPW "$FILTER2" $FIELDS2 | \
#grep $i | \
cat > $ADS_TMP2
#echo "Znaleziono `cat $ADS_TMP2 | wc -l` wpisów ($ADS_TMP2)"
echo "Odpytuje o kolejnego użytkownika ...."
done
sleep 1s
echo "Wyniki zapisane w ($ADS_TMP2)"
------------------------------------END--------------------------

Monitoring macierzy LSI MEGARAID SAS w Nagiosie.

Wracamy do kwestii macierzy RAID, teraz zajmiemy się rozwiązaniem firmy LSI MEGARAID SAS. Mamy już wcześniej zainstalowane MegaCli i chcemy teraz na bieżąco monitorować stan dysków w Nagiosie. Mega Cli może my poprać, ze strony: http://www.thomas-krenn.com/de/download.html I instalujemy. Instalacje jest prosta, więc nie będę opisywał tu tej procedury.
Pierwsze próby podpięcia wtyczki check_megaraid_sas zakończyły się tym, że po stronie serwera monitorowanego dostajemy prawidłowy output, lecz po stronie serwera nagiosa wynik się nie pokrywa (pokazuje, że jest ok, ale nie pokazuje stanu kontrolerów). Winne temu jest sudo. Musimy zmodyfikować odpowiednio plik sudoers.
Dodajemodpowiednie wpisy do sudo (pamiętajmy o sprawdzeniu ścieżki do MegaCli/MegaCli64):

visudo

Defaults:nagios !requiretty
nagios  ALL=(ALL)       NOPASSWD: /usr/lib/nagios/plugins/
nagios  ALL=(ALL)       NOPASSWD: /opt/MegaRAID/MegaCli/MegaCli64
Następnie instalujemy plugin do nagiosa z:

wget http://www.techno-obscura.com/~delgado/code/check_megaraid_sas


Żeby prawidłowo nam zadziałał musimy zmodyfikować w nim linię:

my $megaclibin = '/opt/MegaRAID/MegaCli/MegaCli64';  # the full path to your MegaCli binary

na taką jak powyżej, lub inną ścieżkę w zależności, gdzie znajduje się plik MegaCli64/Megacli.

Wgrywamy go do katalogu pluginów Nagios`a /usr/lib/nagios/plugins/ lub /usr/lib64/nagios/plugins (w zależności od architektury)

W pliku /etc/nagios/nrpe.cfg na kliencie dodajemy (pamiętajmy, żeby nazwa użytkownika w tym pliku zgadzała się z nazwą użytkownika w sudoers, no i oczywiście prawidłowa ścieżka do pluginu):

command[check_megaraid_sas]=/usr/lib/nagios/plugins/check_megaraid_sas



Jeśli są pokazywane jakiekolwiek błędy dysków, a nie chcemy, żeby wiecznie wisiały w Nagiosie musimy w poleceniu użyć przełącznika, za pomocą którego je zignorujemy:

Usage: [-s number] [-m number] [-o number]
-s is how many hotspares are attached to the controller
-m is the number of media errors to ignore
-p is the predictive error count to ignore
-o is the number of other disk errors to ignore

Teraz po stronie serwera Nagios`a tworzymy/modyfikujemy plik konfiguracyjny hosta i zamieszczamy w nim wpis::

define service{
        use             graphed-service     ; Name of service template to use
        host_name         Nasza_Nazwa
        service_description    Raid Status
        check_command     check_nrpe!5666!check_megaraid_sas
        }

Może się jeszcze po stronie serwera nagios pojawić taka niespodzianka:

NRPE: Unable to read output

Po sprawdzeniu plików konfiguracyjnych, sudoers i pliku pluiginu i tam jest ok, to problem może tkwić po stronie sellinuxa to polecenie powinno naprawić (jak zwykle zwracamy uwagę na ścieżke do pliku):

restorecon -R -v /usr/lib64/nagios/plugins/check_megaraid_sas


Po tych zabiegach wszytko u mnie wróciło do normy i Nagios prawidłowo odczytuje wyniki z pluginu.
Następnym razem opisze w jaki sposób diagnozować dyski, w których pojawiają się błędy, a także jak rozwiąże jeden przypadek braku chęci współpracy sudo z pluginem.
       
       

Apache + Tomcat + Cartyfikaty SSL (+ ew Alfresco) + htaccess = łatwo

Mamy już zainstalowane Alfresco (w tym przypadku wersja 5 Community Edition + system operacyjny CentOS 7), więc nie będę zagłębiał się w szczegóły instalacji i jego wstępnej konfiguracji. Na chwile obecną chcemy to ustawić, żeby wyglądało po ludzku i dodatkowo to zabezpieczyć, oraz nie męczyć się z zawiłościami konfiguracyjnymi certyfikatów i zabezpieczenia katalogów w Tomcat.
W pierwszej kolejności wywalamy zawartość katalogu /opt/alfresco/tomcat/webapps/ROOT i tworzymy tam plik index.jsp o następującej zawartości:

<%@ page import="java.io.*,java.util.*" %>
<html>
<head>
<title>Page Redirection</title>
</head>
<body>
<center>
<h1>Page Redirection</h1>
</center>
<%
   // New location to be redirected
      String site = new String("https://alfresco.domain.com");
     response.setStatus(response.SC_MOVED_TEMPORARILY);
    response.setHeader("Location", site);.
%>
</body>
</html>

Co przekieruje nam każde zapytanie z głównego katalogu Tomcata na wskazaną przez nas lokalizację.

Następnie instalujemy apache i konfigurujemy https i mod_jk.so, które pełni role łącznika pomiędzy Apachem a Tomcatem

To instalujemy z paczki:
yum install httpd httpd-devel mod_ssl gcc

A to musimy teraz ściągnąć i skompilować - tomcat connectors:
wget http://ftp.ps.pl/pub/apache/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.40-src.tar.gz

rozpakowywujemy:
tar xzf tomcat-connectors-1.2.40-src.tar.gz
cd tomcat-connectors-1.2.40-src
cd native

i kompilujemy (warto sprawdzic wcześniej lokalizacje pliku apxs):
./configure --with-apxs=/usr/bin/apxs
make
cd apache-2.0

Kopiujemy skompilowany moduł do odpowiedniej lokalizacji:
cp mod_jk.so /etc/httpd/modules/

Następnie konfigurujemy Apache tak, żeby nasza instalacja Alfresco działała w bezpiecznym połączeniu. Musimy dodać następujące wpisy do /etc/htps/conf.d/ssl.conf:

LoadModule    jk_module  /etc/httpd/modules/mod_jk.so
JkWorkersFile /opt/alfresco/tomcat/conf/workers.properties
JkLogFile     /var/log/httpd/mod_jk.log
JkLogLevel    info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
LoadModule auth_basic_module modules/mod_auth_basic.so


<VirtualHost alfresco.domain.com:443>

    ServerName alfresco.domain.com
    SSLEngine on
    SSLCertificateFile /etc/httpd/ssl/certyfikat.cert
    SSLCertificateKeyFile /etc/httpd/ssl/certyfikat.key
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
              #   JkOptions indicate to send SSL KEY SIZE,
                  JkOptions +ForwardKeySize -ForwardDirectories

                   JkMount /* tomcat
                   JkMount / tomcat

                   <Location "/share">
                       Order allow,deny
                       Allow from all
                       AuthType Basic
                       AuthName "Restricted Files"
                       AuthUserFile /opt/alfresco/tomcat/webapps/share/users
                       Require user some_user
                     </Location>.

                   JkMount /share/* tomcat
                   JkMount /share tomcat

                   <Location "/alfresco">
                       Order allow,deny
                       Allow from all
                       AuthType Basic
                       AuthName "Restricted Files"
                       AuthUserFile /opt/alfresco/tomcat/webapps/alfresco/users
                       Require user some_user
                     </Location>.

                   JkMount /alfresco tomcat
                   JkMount /alfresco/* tomcat

</VirtualHost>



Tworzymy plik workera dla Tomcata(trzeba zwrócić uwagę na port czy wpisujemy odpowiedni):
/opt/alfresco/tomcat.conf/worker.properties:

worker.list=tomcat
worker.tomcat.port=8009
worker.tomcat.host=localhost
worker.tomcat.type=ajp13
worker.tomcat.lbfactor=1

Tworzymy pliki users w lokalizacjach:
/opt/alfresco/tomcat/webapps/share/
/opt/alfresco/tomcat/webapps/alfresco/

A jego zawartość powinna wyglądać:
some_user:haslo_htpasswd

Restartujemy Apache:
service https restart
 
Teraz za pomocą ulubionej przeglądarki sprawdzamy, czy nasza konfiguracja działa tak jak potrzeba i jak chcieliśmy. W ten sposób mamy działającego Tomcat`a na warunkach Apache. Możemy teraz np. dodatkowo ustawić firewalla i przepuścić ruch tylko dla portów 80 i 443 i całkowicie odciąć od świata porty Tomcat`a.

Problem z sshd - no such device

Siedzimy sobie grzebiemy w pliku sshd_config np zezwalamy nowemu userowi korzystać z dobrodziejstw logowania się przez demona sshd. Zapisujemy plik wydajemy polecenie:

/etc/init.d/sshd restart

Demon niby wstaje , ale ......... ssh nie działa. Patrzymy w logi a tam widzimy:

server sshd[11115]: fatal: daemon() failed: No such device

Sprawdzamy plik konfiguracyjny, cuda nie widy ...... ciągle nic.

Po małym rekonesansie w sieci znajdujemy winowajcę. Jest nim /dev/null.
Zeby naprawic problem wystarczy go skasowac i na nowo wygenerować:

rm /dev/null
mknod /dev/null c 1 3

sprawdżmy jeszcze czy plik ma odpowiednie prawa:

ls -l /dev/null
crw-rw-rw-. 1 root root 1, 3 Sep 11 13:54 /dev/null

to jest ok. Następnie restartujemy demona SSHD.

/etc/init.d/ssdh restart

Sprawdzamy czy proces sie odpalił np:

ps auxf | grep sshd

I jeśli mamy go na liście to problem z głowy.

Jak wykonać polecenie w danym dniu tygodnie bez zaprzęgania Crona

Czasem zdarza się taka potrzeba, że przydało by się naszemu skryptowi działającemu w cronie, żeby bez dodatkowych skryptów zewnętrznych i następnych wpisów w crontabie zrobił coś dodatkowo np. we wtorek. Może przydać się przy np. skryptach backupowych, bądź innych wynalazkach. Poniżej mały skrypcik, który w środę będzie zmieniał nazwę pliku:

#!/bin/sh
TUE=`date | cut -c 1-3`
DATE=`date +%F`
DZIEN=`echo "Tue"`
    if
              [ "$TUE" == "$DZIEN" ]; then
              mv test.txt test_$DATE.txt
        exit 0;
    else
        echo "dzis nie Tue"
    fi

Logowanie Apache na zdalnym serwerze rsyslog

Mamy sobie serwer na którym za pomocą rsysloga logujemy sobie ze zdalnych maszyn logi. Ale oprócz standardowych logów chcielibyśmy jeszcze, żeby w logu znajdowały się dodatkowo zdarzenia z Apache. Musimy na maszynie, z której chcemy zbierać logi z Apache do pliku konfiguracyjnego rsysloga dodać następujące linijki:

# Apache access file:
$ModLoad imfile
$InputFileName /var/log/apache2/access.log
$InputFileTag apache-access:
$InputFileStateFile stat-apache-access
$InputFileSeverity info
$InputRunFileMonitor

#Apache Error file:
$InputFileName /var/log/apache2/error.log
$InputFileTag apache-errors:
$InputFileStateFile stat-apache-error
$InputFileSeverity error
$InputRunFileMonitor

Następnie na tej samej maszynie w pliku konfiguracyjnym /etc/rsyslog.conf dopisujemy zdalny serwer rsyslog`a na który chcemy wrzucić logi:

*.*            @123.123.123.123

Wykonujemy restart demona rsysloga i sprawdzamy na zdalnej maszynie czy logi apache się dopisują do pliku loga naszej maszyny.

Instalacja kontroli stanu macierzy RAID w linuxie (na przykładzie CentOS`a) dla kontrolera Adaptec.

Jest sobie serwer już leciwy np jakiś Dell PowerEdge2650 mamy na nim linuxa w tym przypadku CentOS`a i podejrzewamy, że może coś złego się dziać z naszym RAIDem, a nie mamy narzędzi, ani sposobności, żeby to sprawdzić. Nawet nie wiemy jaki mamy kontroler.
Zaczynamy od małego reserczu :)

Sprawdzamy jaki mamy ADAPTER RAID w systemie:
[root@xxx]# lspci
00:00.0 Host bridge: Broadcom CMIC-WS Host Bridge (GC-LE chipset) (rev 13)
00:00.1 Host bridge: Broadcom CMIC-WS Host Bridge (GC-LE chipset)
00:00.2 Host bridge: Broadcom CMIC-LE
00:04.0 Class ff00: Dell Embedded Remote Access or ERA/O
00:04.1 Class ff00: Dell Remote Access Card III
00:04.2 Class ff00: Dell Embedded Remote Access: BMC/SMIC device
00:0e.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
00:0f.0 Host bridge: Broadcom CSB5 South Bridge (rev 93)
00:0f.1 IDE interface: Broadcom CSB5 IDE Controller (rev 93)
00:0f.2 USB Controller: Broadcom OSB4/CSB5 OHCI USB Controller (rev 05)
00:0f.3 ISA bridge: Broadcom CSB5 LPC bridge
00:10.0 Host bridge: Broadcom CIOB-X2 PCI-X I/O Bridge (rev 03)
00:10.2 Host bridge: Broadcom CIOB-X2 PCI-X I/O Bridge (rev 03)
00:11.0 Host bridge: Broadcom CIOB-X2 PCI-X I/O Bridge (rev 03)
00:11.2 Host bridge: Broadcom CIOB-X2 PCI-X I/O Bridge (rev 03)
03:06.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)
03:08.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)
04:08.0 PCI bridge: Intel Corporation 80303 I/O Processor PCI-to-PCI Bridge (rev 01)
04:08.1 RAID bus controller: Dell PowerEdge Expandable RAID Controller 3/Di (rev 01) <<<--- nasz kontroler
05:06.0 SCSI storage controller: Adaptec RAID subsystem HBA (rev 01)
05:06.1 SCSI storage controller: Adaptec RAID subsystem HBA (rev 01)następnie sprawdzamy jakie moduły mamy zainstalowane:

[root@xxx]# lsmod
Module                  Size  Used by
..
aacraid                67657              <<<---- nasz sterownik od RAID
..

Jeśli nie mamy takiego modułu załadowanego, to musimy wyszukać moduł odpowiedzialny za RAID i sprawdzić za jakiego producenta odpowiada :).
Teraz musimy ściągnąć i zainstalować potrzebne nam oprogramowanie:

Dla systemu 32bit:
wget www.thomas-krenn.com/redx_tools/mb_download.php/mid.065102097066087081055088074052107061/StorageManager_Adaptec_Linux_x86_v6.10.18359_20090.rpm
 
Dla systemu 64bit:
wget www.thomas-krenn.com/redx_tools/mb_download.php/mid.104098115056084084089102070050065061/StorageManager_Adaptec_Linux_x64_v6.10.18359_20090.rpm

Instalujemy ściągniętą paczkę:
[root@xxxi]# rpm -i StorageManager_Adaptec_Linux_x86_v6.10.18359_20090.rpm

Adaptec Storage Manager
Version 6.10

starting Adaptec Storage Manager agent ...


Installation completed successfully.
The application can be started by running: /usr/StorMan/StorMan.sh
Teraz sprawdzamy czy nam działa wszystko:
cd /usr/StorMan
./arcconf getconfig 1
w tym miejscu może wystąpić poniższy błąd
./arcconf: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
jeśli wystąpi to sprawdzamy jaki pakiet odpowiada, za brakującą bibilotekę:
 yum whatprovides libstdc++.so.5
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * addons: mirror-pl.kielcetechnologypark.net
 * base: mirror-pl.kielcetechnologypark.net
 * epel: ftp.icm.edu.pl
 * extras: mirror-pl.kielcetechnologypark.net
 * rpmforge: mirror1.hs-esslingen.de
 * updates: mirror-pl.kielcetechnologypark.net
compat-libstdc++-33-3.2.3-61.i386 : Compatibility standard C++ libraries
Repo        : base
Matched from:
Other       : libstdc++.so.5

StorMan-6.10-18359.i386 : Adaptec Storage Manager
Repo        : installed
Matched from:
Other       : Provides-match: libstdc++.so.5

i doinstalowujemy brakującą paczkę:
yum install compat-libstdc++-33-3.2.3-61.i386
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * addons: mirror-pl.kielcetechnologypark.net
 * base: mirror-pl.kielcetechnologypark.net
 * epel: ftp.icm.edu.pl
 * extras: mirror-pl.kielcetechnologypark.net
 * rpmforge: mirror1.hs-esslingen.de
 * updates: mirror-pl.kielcetechnologypark.net
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package compat-libstdc++-33.i386 0:3.2.3-61 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================================================================
 Package                                             Arch                                 Version                                  Repository                            Size
==============================================================================================================================================================================
Installing:
 compat-libstdc++-33                                 i386                                 3.2.3-61                                 base                                 232 k

Transaction Summary
==============================================================================================================================================================================
Install       1 Package(s)
Upgrade       0 Package(s)

Total download size: 232 k
Is this ok [y/N]: y
Downloading Packages:
compat-libstdc++-33-3.2.3-61.i386.rpm                                                                                                                  | 232 kB     00:00
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : compat-libstdc++-33                                                                                                                                    1/1

Installed:
  compat-libstdc++-33.i386 0:3.2.3-61

Complete!




Następnie wydajemy ponownie polecenie:
/usr/StoreMan/arcconf getconfig 1
Dostaniemy wynik ze statusem naszego RAIDu i dysków do niego podłączonych.

Powodzenia