Android 4.4.2 i wyświetlanie zawartości flash na stronach

Opisywałem wcześniej jak można uzyskać dostęp dla treści flash przez przeglądarkę internetową dla Androida oficjalnie nie wspierającego tej technologii, ale ten sposób nie zadziałał mi na Androidzie 4.4.2. Znalazłem inny i w moim przypadku zadziałał. W pierwszej kolejności odinstalowujemy Flash Playera jeśli mamy go zainstalowanego. Następnie ściągamy ze Sklepu Play: Dolphin Browser i instalujemy apkę. Z adresu: www.mediafire.com/download/p2tp0h8xy8o7f86/KitKat.Adobe.Flash.Player.11.1.apk ściągamy flash`a. W ustawieniach zaznaczamy możliwość instalacji aplikacji spoza Sklepu Play (Ustawienia -> Zabezpieczenia -> Nieznane źródła mają być zaznaczone). Jak to mamy sprawdzone instalujemy Flash. Uruchamiamy przeglądarkę Dolphin i w niej zmieniamy ustawienia (Menu -> Ustawienia -> Zawartość -> Flash Player) na nam odpowiadające. Po wszystkim wchodzimy na stronę z obsługa flash i sprawdzamy czy działa jak powinno.

Samsung Galaxy Core Plus (SM-G3500) czyszczenie partycji Cache i dodawanie uprawnień root

Z czasem staje się tak, że telefon staje się zamulony aplikacje fiksują itp. Zanim wyczyścimy nasz telefon od nowa i będziemy męczyć się z konfiguracją i instalacją aplikacji, to w pierwszej kolejności warto wyczyścić partycje Cache. Ta operacja nie wiąże się z utratą danych. Żeby wykonać czyszczenie należy:

1. Wyłączyć telefon
2. Wcisnąć i przytrzymać przyciski: "Volume Up", "Home" and "Power" naraz
3. Trzymamy je do czasu jak się pojawi logo Samsung, wtedy puszczamy przycisk "Power"
4. Po chwili powinien ukazać się obrazek robocika z wykrzyknikiem i wtedy puszczamy wszystkie wciśnięte przyciski
5. Wciskamy przycisk "Volume Up", "Home" i pojawia nam się Menu Recovery
6. Za pomocą przycisku "Volume Down" zaznaczamy "wipe cache partition"
7. Wciskamy przycisk "Power" żeby potwierdzić wybór
8. Telefon po wykonanej operacji sam się zrestartuje

Zostaje nam tylko sprawdzić czy po tej operacji uzyskaliśmy żądany przez na efekt. Jeśli nie i dalej mamy problemy powtarzamy powyższą procedurę, lecz zamiast "wipe cache"  wybieramy opcje formatu partycji cache i factory reset.
Lecz jeśli jednak ciągle żal nam danych i chcielibyśmy jednak zarchiwizować WSZYSTKIE dane, aplikacje i ustawienia, to potrzebujemy uprawnień root, żeby można było skorzystać z Titanium Backup.

Żeby zainstalować roota (szczególnie w najnowszej wersji systemu) to w pierwszej kolejności w systemie (Ustawienia -> Zabezpieczenia -> Nieznane źródła) zezwalamy na instalację aplikacji z poza Sklepu Play. Następnie ze strony: http://www.mgyun.com/m/en ściągamy aplikację iRoot i wgrywamy ją na kartę pamięci urządzenia i następnie instalujemy. Powita nas ekran z  azjatyckimi znaczkami i klikamy na przycisk w którym pojawia się słowo "ROOT" i czekamy jak skończy i buźka będzie uśmiechnięta to znaczy, że się udało. Można doinstalować aplikację "SuperSu" do kompletu jakby się okazało, że jakaś aplikacja jej potrzebuje. Po tym instalujemy Titanium Backup i możemy sobie wykonać kopie danych (pamiętajmy, żeby pliki backupu wykonywały się na Karcie SD, więc trzeba to w programie ustawić), aplikacji i ustawień przed przywróceniem telefonu do ustawień fabrycznych. Po wyczyszczeniu telefony ponownie instalujemy iRoot i Titanium backup i odzyskujemy dane i aplikacje z backupu.
I cieszymy się odmuloną komórką

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