CentOS 7 problem z autostartem klienta NRPE z innym użytkownikiem niż nrpe

CentOS 7 momentami przekleństwo, bo coś co zawsze działało nie działa wcale, albo od d***y strony. Jak zwykle coś musi być nie tak. Mamy zainstalowanego nrpe na hoście wszystko ładnie działa Nagios zbiera wszystko tak jak trzeba , ale .... do momentu restartu maszyny. Okazuje się, że usługa nie wstaje automatycznie. Sprawdzamy co się dzieje:

[root@localhost ~]# service nrpe start
[root@localhost ~]# systemctl status  nrpe.service
nrpe.service - NRPE
   Loaded: loaded (/usr/lib/systemd/system/nrpe.service; enabled)
   Active: active (running) since Tue 2014-10-21 08:02:23 CEST; 1 day 1h ago
 Main PID: 31220 (nrpe)
   CGroup: /system.slice/nrpe.service
           └─31220 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d

Oct 21 08:02:22 localhost.localdomain nrpe[31220]: Starting up daemon
Oct 21 08:02:23 localhost.localdomain nrpe[31220]: Warning: Could not set effective GID=997
Oct 21 08:02:23 localhost.localdomain nrpe[31220]: Warning: Unable to change supplementary groups using initgroups()
Oct 21 08:02:23 dlocalhost.localdomain nrpe[31220]: Warning: Could not set effective UID=998
Oct 21 08:02:23 localhost.localdomain nrpe[31220]: Server listening on xxx.xxx.xxx.xxx port 5666.
Oct 21 08:02:23 localhost.localdomain nrpe[31220]: Listening for connections on port 0
Oct 21 08:02:23 localhost.localdomain nrpe[31220]: Allowing connections from: xxx.xxx.xxx.xxx
Oct 21 08:02:23 localhost.localdomain systemd[1]: Started NRPE.

Wychodzi na to, że NRPE nie może sobie poradzić, z uruchomieniem z innym użytkownikiem niż nrpe. Odpalmy wtakim razie nrpe z poziomu xinetd:

yum install xinetd
cd /etc/xintetd.d

Tworzymy plik startowy dla nrpe:
 vi nrpe

service nrpe
{
        flags           = REUSE
        socket_type     = stream
        port            = 5666
        wait            = no
        user            = nagios
        group           = nagios
        server          = /usr/sbin/nrpe
        server_args     = -c /etc/nagios/nrpe.cfg --inetd
        log_on_failure  += USERID
        disable         = no
        only_from       = 127.0.0.1 xxx.xxx.xxx.xxx
}

Musimy dodać jeszcze odpowiedni wpis w /etc/services, żeby xinetd odpowiedniouruchomił
vi /etc/services

Szukamy takiej linijki:

###UNAUTHORIZED USE: Port 5666 used by SAIC NRPE############

Jeśli jest to pod nią wpisujemy (jak nie to wpisujemy na wysokości, gdzie nasz port powinien się znaleźć):
nrpe<--><------>5666/tcp<------><------>#NRPE


Wyłączamy klasyczne startowanie nrpe i uruchamiamy je z poziomu xinetd, oraz automatyczny jej start:

chkconfig nrpe off
chkconfig xinetd on
service xinetd start

Sprawdzamy czy usługa odpowiednio wstała:
netstat -tulpn

jak pokazuje się wpis:
tcp6       0      0 :::5666                 :::*                    LISTEN      807/xinetd

jest ok. Profilaktycznie można zrestartować maszynę i sprawdzić, czy wszystko działa tak jak potrzeba.

Nowy adres bloga

Został uruchomiony nowy, dodatkowy adres bloga (stary pozostaje bez zmian).

Nowy adres:

http://blog.pokrak.com.pl

Uruchomię jeszcze z kilku domen dostęp, ale to później.

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

Aktualizacja CentOS 6.5 na 7

Powinno zadziałać na każdym CentOS 6.x

W pierwszej kolejności instalujemy Redhat upgrade tool:

Jako, że redhat-upgrade-tool nie są dostępne w standardowych repozytozytoriach musimy je dodać:

# vi /etc/yum.repos.d/upgrade.repo

I wklejamy to:

[upgrade]
name=upgrade
baseurl=http://dev.centos.org/centos/6/upg/x86_64/
enabled=1
gpgcheck=0

Instalujemy następujące paczki

# yum -y install preupgrade-assistant-contents redhat-upgrade-tool preupgrade-assistant

Uruchamiamy preupg w celu zdiagnozowania ewentualnych problemów, które mogą się pojawić w związku z aktualizacją.

# preupg

 Importujemy potrzebny klucz GPG:

# rpm --import http://centos.excellmedia.net/7.0.1406/os/x86_64/RPM-GPG-KEY-CentOS-7

Ścigamy niezbędne paczki do zainicjowania aktualizacji:

# redhat-upgrade-tool --network 7.0 --instrepo http://centos.excellmedia.net/7.0.1406/os/x86_64/

Jeśli w tym miejscu natrafimy na problemy wymuśmy siłowe zaciągniecie:




# redhat-upgrade-tool --network 7.0 --force --instrepo http://centos.excellmedia.net/7.0.1406/os/x86_64/

rpm transaction 100% [=========================================================]
rpm install 100% [=============================================================]
setting up system for upgrade
Finished. Reboot to start upgrade.

Po wszystkim rebootujemy system i podczas startu nastąpi aktualizacja.

#reboot

System po tym może się jeszcze z raz lub dwa razy zrestartować i po pojawieniu się zachęty do logowania mamy już CentOS 7

Testowanie ustawień fail2ban lub logowanie do pliku

Temat fail2ban powraca :). Czasem zamiast banować niewiadomo w jaki sposób potrzebujemy tylko informacji, żeby sobie ogarnąć co i jak, a po kilku dniach działania, np, żeby nie zastosować zbyt represyjnej reguły docelowej. Żeby to osiągnąć to w pierwszej kolejności modyfikujemy naszą regułę w pliku:

/etc/fail2ban/jail.conf


np.:
[smtpauth-iptables]

Akcję ustawiamy ustawaiamy na log:

action = log

i tworzymy plik konfiguracyjny akcji, który ma znaleźć się w pliku:
/etc/fail2ban/action.d/log.conf
kopiujemy poniższą zawartość i umieszczamy ww pliku
--------------------KOPIUJ-PONIZEJ----------------------------
# Fail2Ban configuration file
#
# Author: Grzegorz Zalewski
# Modified :
#
# $Revision:.
#


[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart =.


# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop =.


# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck =.


# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
actionban = echo `date` BAN <ip> >> /var/log/fail2ban_iplog.txt


# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
actionunban = echo `date` UNBAN <ip> >> /var/log/fail2ban_iplog.txt

[Init]

# Option:  port
# Notes.:  specifies port to monitor
# Values:  [ NUM | STRING ]
#
port =

# Option:  localhost
# Notes.:  the local IP address of the network interface
# Values:  IP
#
localhost = 127.0.0.1
--------------------KOPIUJ-POWYZEJ----------------------------

Jeśli chcemy, żeby zamiast logować zaczął banować, to dajemy #action = log w pliku jail.conf
i usuwamy # z

#action   = iptables[name=SMTP, port=smtp, protocol=tcp]

Jeśli chcemy to i to action modyfikujemy na:

action = iptables[name=SMTP, port=smtp, protocol=tcp]
     log

Przyjemnego zbierania logów

Fail2ban i exim czyli jak zaprzęgnąć kombajn do walki ze spamerami.

Na przykładzie Centos.
Spamerzy to zmora każdego admina trzeba sprawdzać co jakiś czas czy nowe adresy się nie pojawiły i je blokować, co na dłuższą metę jest upierdliwe. Postanowiłem zaprząc do tego zadania fail2ban (posiada on już domyślnie wiele opcji więc polecam pokombinować z innymi - tu opisze tylko pod exima konfigurację). Fail2ban ma za zadanie przeglądać logi i na ich podstawie zablokować na określony czas za pomocą iptables delikwenta który chce na siłę zrobić coś, czego akurat nie chcemy, żeby robił.
W pierwszej kolejności instalujemy fail2ban
yum install fail2ban
następnie go konfigurujemy /etc/faul2ban/jail.conf:

[DEFAULT]
ignoreip = 127.0.0.1/8 # adresacja ip do wykluczenia z reguł
bantime  = 600 # jak długo ma trwać
findtime  = 600 # czas w którym muszą nastąpić błędne logowania określone w Maxretry w ilości bantime, żeby reguła się załączyła
maxretry = 20 # ilośc prób do zabanowania
backend = auto

[smtpauth-iptables] #Reguła dla exim
enabled  = true
filter   = smtpauth
action   = iptables[name=SMTP, port=smtp, protocol=tcp]
logpath  = /var/log/exim/main.log
maxretry = 3


Następnie musimy stworzyć regułę smtpauth
nano /etc/fail2ban/filterd/smtpauth.conf:

# Fail2Ban configuration file
#
# Author: Christoph Haas
# Modified by: Cyril Jaquier
#
# $Revision: 510 $
#

[Definition]

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>\S+)
# Values:  TEXT
#

failregex = \[<HOST>\]: 535 Incorrect authentication data

Jak już mamy to skonfigurowane uruchamiamy fail2ban:

service fail2ban start

jeśli wszystko jest ok (trzeba sobie wyeksperymentować optymalne ustawienia), to uruchamiamy fail2ban na stałe:
chkconfig fail2ban on

Następnie obserwujemy sobie działanie programu w celu analizy konfiguracji:

tail -f /var/log/fail2ban.conf
2014-06-09 08:19:11,343 fail2ban.actions: WARNING [smtpauth-iptables] Ban 190.117.212.81
2014-06-09 08:19:12,355 fail2ban.actions: WARNING [smtpauth-iptables] Ban 178.127.149.245
2014-06-09 08:19:35,374 fail2ban.actions: WARNING [smtpauth-iptables] Ban 112.163.8.4
2014-06-09 08:19:47,389 fail2ban.actions: WARNING [smtpauth-iptables] Ban 110.175.241.141
2014-06-09 08:19:49,417 fail2ban.actions: WARNING [smtpauth-iptables] Ban 122.163.1.132
2014-06-09 08:19:52,436 fail2ban.actions: WARNING [smtpauth-iptables] Ban 36.238.173.119
2014-06-09 08:20:07,454 fail2ban.actions: WARNING [smtpauth-iptables] Ban 113.165.209.9
2014-06-09 08:20:10,470 fail2ban.actions: WARNING [smtpauth-iptables] Ban 190.226.38.61
2014-06-09 08:20:14,485 fail2ban.actions: WARNING [smtpauth-iptables] Ban 115.242.158.139
2014-06-09 08:20:14,504 fail2ban.actions: WARNING [smtpauth-iptables] Ban 118.165.207.142
2014-06-09 08:20:59,531 fail2ban.actions: WARNING [smtpauth-iptables] Unban 202.72.245.42
2014-06-09 08:21:53,558 fail2ban.actions: WARNING [smtpauth-iptables] Ban 113.172.20.62
2014-06-09 08:21:55,584 fail2ban.actions: WARNING [smtpauth-iptables] Unban 188.115.204.36
2014-06-09 08:21:55,596 fail2ban.actions: WARNING [smtpauth-iptables] Unban 115.74.75.131
2014-06-09 08:22:00,605 fail2ban.actions: WARNING [smtpauth-iptables] 92.47.46.222 already banned
2014-06-09 08:22:12,608 fail2ban.actions: WARNING [smtpauth-iptables] Ban 151.74.66.254
2014-06-09 08:22:24,624 fail2ban.actions: WARNING [smtpauth-iptables] Unban 113.186.89.228
2014-06-09 08:22:25,634 fail2ban.actions: WARNING [smtpauth-iptables] Ban 46.62.246.30
2014-06-09 08:22:25,645 fail2ban.actions: WARNING [smtpauth-iptables] Ban 222.254.10.105
2014-06-09 08:22:36,658 fail2ban.actions: WARNING [smtpauth-iptables] Ban 59.176.64.47
2014-06-09 08:22:42,671 fail2ban.actions: WARNING [smtpauth-iptables] Ban 201.255.40.43
2014-06-09 08:22:53,688 fail2ban.actions: WARNING [smtpauth-iptables] Ban 87.236.233.68
2014-06-09 08:22:58,702 fail2ban.actions: WARNING [smtpauth-iptables] Unban 81.21.97.199
2014-06-09 08:23:04,721 fail2ban.actions: WARNING [smtpauth-iptables] Ban 120.61.190.243
2014-06-09 08:23:11,737 fail2ban.actions: WARNING [smtpauth-iptables] Unban 182.68.65.167
2014-06-09 08:23:13,754 fail2ban.actions: WARNING [smtpauth-iptables] Ban 171.255.47.104
2014-06-09 08:23:33,772 fail2ban.actions: WARNING [smtpauth-iptables] Ban 183.81.45.125
2014-06-09 08:23:36,788 fail2ban.actions: WARNING [smtpauth-iptables] Ban 117.0.161.53
2014-06-09 08:23:44,812 fail2ban.actions: WARNING [smtpauth-iptables] Unban 123.21.192.65
2014-06-09 08:23:47,836 fail2ban.actions: WARNING [smtpauth-iptables] Unban 14.163.236.24
2014-06-09 08:24:09,856 fail2ban.actions: WARNING [smtpauth-iptables] Ban 181.66.156.21








Jeśli wszystko działa tak jak powinno to mamy święty spokój i "ajzatyckimi" spamerami.
Powodzenia.

Jak wyciągnąc jakie grupy mają uprawnienia do jakich katalogów w Windows (na przykładzie W2008)

Np. mamy sobie domenę w tej domenie serwer plików, na którym mamy kilka, kilkanaście i nawet kilkadziesiąt grup. Mamy także foldery, które im udostępniamy. Po pewnym czasie pojawia się zagwozdka, która grupa do czego ma dostęp. Na szczęście w kilka sekund możemy zlistować cały folder i uzyskać ta odpowiedź. Wystarczy wydać polecenie:

cacls x:\scieżka\* -> wyświetli nam w konsoli
cacls x:\scieżka\* >> x:\plik.txt -> zapisze nam wynik do pliku

I tym sposobem unikamy długiego przeklikiwania folderów i sprawdzania ich dostępów.  
Dobry admin to leniwy admin.

Jak włączyć obsługę Flash na nowych Androidach (4.0 i nowsze).

Każdy użytkownik Androida 4.0 i wyższego zdaje sobie sprawę, że domyślnie może pożegnać się z obsługa flash na swojej komórce, ponieważ Google stwierdziło, że nie jest to potrzebne. Na szczęście okazuje się, że to nie jest prawdą i nie musimy rezygnować ze swoich ulubionych seriali online na komórce (Sprawdzone na Androidzie 4.2.2). Jest na to proste rozwiązanie i szybkie. W pierwszej kolejności ściągamy na swoja komórkę oprogramowanie flash dla Androida 4.0 ze strony Adobe:
http://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html
i szukamy wersji dla systemu Android np.: Flash Player 11.1 for Android 4.0 (11.1.115.81).  
Następnie w naszej komórce musimy ustawić w menu zezwolenie na instalowanie "Nieznanych urządzeń". Teraz możemy zainstalować ściągniętą aplikacje Flash, oraz ze sklepu Play instalujemy przeglądarkę, "Next Browser". Po instalacji uruchamiamy ją i konfigurujemy. Żeby Flash działał poprawnie ja ustawiłem to tak: Ustawienia -> User Agent-> Komputer, Ustawienia -> Wyświetlanie -> Flash Player -> Zawsze włączony. I możemy na nowych Androidach od teraz cieszyć się z obsługi Flash`a. Przyjemnego oglądania :)