cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
65536

Takže je povoleno max 65536 v conntrack tabulce. Změnu provedete jednoduše

echo "131072" > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

A stačí již jen ověřit, zda to hodnotu přijalo

beta:/var/log# sysctl -p
net.ipv4.tcp_syncookies = 1
net.ipv4.netfilter.ip_conntrack_max = 131072

Server se mi znatelně urychlil a hlášení z logu zmizely. Nicméně se mi tam stále objevují ještě jiné potvůrky:
Jan 23 22:58:30 Beta kernel: [161748.974581] TCPv6: Possible SYN flooding on port 80. Sending cookies.
… na to mrknu později, pokud mi někdo nedá tip :D

Vytvořil jsem spustitelný shell script /script/system_updates.sh

PATH=/usr/bin:/bin:/usr/sbin:/sbin
/usr/bin/apt-get update -y
/usr/bin/apt-get upgrade  --yes upgrade -y
/usr/bin/apt-get clean

a poté udělal nový soubor v /etc/cron.d system_updates obsahující:

PATH=/usr/bin:/bin:/usr/sbin:/sbin
30 5     * * *     root /script/system_updates.sh >>/var/log/system_updates.log >/dev/null 1>/dev/null 2>/dev/null

No a hotovo. Cesta (PATH) je tam 2x protože chci mít jistotu :D :D Joke, stačí jen jednou….

vmkfstools -i PikoGuestApp02.vmdk Fantager.vmdk

Pokud je třeba převést rovnou thick na thin, stačí přidat

-d 'thin'

Celý příkaz potom vypadá následovně:

vmkfstools -i PikoGuestApp02.vmdk Fantager-thin.vmdk  -d 'thin' -a lsilogic

Pokud shrinknutí nepomohlo, je třeba odmazat data, která tam zůstaly ale přitom jsou “smazané”. Zatím nejjednodušší řešení, které jsem objevil, je při vypnutém stroji udělat kopii disku.

Časem si sem budu přidávat další parametry, které se mi nechce nosit v hlavě :D

sp_helpfile

Dostaneme výpis ve tvaru (osobně jsem zapoměl zálohvoat trans log WSUS DB – má 30GB :D)

SUSDB	1	D:\SUSDB.mdf	PRIMARY	878784 KB	Unlimited	1024 KB	data only
SUSDB_log	2	L:\SUSDB.ldf	NULL	33507264 KB	2147483648 KB	10%	log only

Potom stačí zadat to následujícího příkazu ID souboru a požadovanou velikost v MB (je možno zadat i co nejmenší, příkaz potom provede maximální zmenšení ale nedojde ke ztrátě dat)

dbcc shrinkfile (2,5000)

A je hotovo :D

No a když chceme na linux, stačí SSH klient a to např. ConnectBot (je zdarma na marketu).

Stručný popis funkce:

1. každý den v 10:00 vytvoření reportu Dataprotectorem
2. každý den v 11:00 hledání VBSkem v txt reportu, pokud není nalezen text že je vše bez chyb, dojde k odeslání reportu na specifikované emaily
3. každý den v 18:00 dojde k přepsání reportu (kdyby spadl DataProtector, nebude report přepisován, nebude nalezen text o proběhlých jobech a report nám bude zaslán s chybou)

Nejdříve je nutné si vytvořit adresářovou strukturu pro lokální ukládání reportů a uložení scriptů.

mkdir c:\scripts
mkdir c:\scripts\dp

Poté si v DP uděláme report, který následně nashedulujeme
DP-> Reporting -> Reports -> Add Report Group a přidat “Report to email” skupinu. V ní vytvořit “Add report”, vybrat “Reports on sessions in a timeframe”, název “Session Errors”, type Session Errors

Potom next, nastavit “Relative time” na 24h za poslednich 24h

Potom samé next až na obrazovku, kde je “Message level” a volbu na “Critical”

Next a nastavit, v jakým formátu a kam se to má ukládat

Stačí už jen danou skupinu jobů nashedulovat, a to 1x denně v 10h

Nyní můžeme mrknout na to, zda to funguje – pravé tlačítko na Skupinu a Start

V cestě C:\scripts\dp bude vygenerovaný soubor errors.txt, který buď bude obsahovat chyby nebo obsah souboru bude obsahovat text “No error messages”  - podle toho bude logika následujícího scriptu rozhodovat o tom, zda nám pošle email či nikoliv.

Vytvoříme VBS script na zasílání reportu v případě nalezených chyb, nazveme ho c:\scripts\check_and_send_errors.vbs. V souboru je nutne zamenit NUTNO_ZADAT_SMTP_SERVER a EMAIL@EMAIL.CZ (význam nebudu popisovat :D), který dáme do Win shedule každý den v 11:00

Option Explicit
Dim objFSO, objSouborPikodrak, strObsahSouboru, intKdeJeHlaska
Const FOR_READING = 1
Const strFileName = "C:\scripts\dp\errors.txt"
Set objFSO = CreateObject ("Scripting.FileSystemObject")
Set objSouborPikodrak = objFSO.OpenTextFile (strFileName,FOR_READING,0,-1)
strObsahSouboru = objSouborPikodrak.ReadAll
intKdeJeHlaska = InStr (strObsahSouboru,"No error messages")
If intKdeJeHlaska = 0 Then
'WScript.Echo "Nenasel jsem hlasku - No error Messages - na pozici " & intKdeJeHlaska
Dim objEmail, iAttachmenCount, aAttachment
Const sSMTPserver = "NUTNO_ZADAT_SMTP_SERVER"
Set objEmail = CreateObject("CDO.Message")
objEmail.To = "EMAIL@EMAIL.CZ, EMAIL2@EMAIL.CZ"
objEmail.ReplyTo = "EMAIL@EMAIL.CZ"
objEmail.Sender = "EMAIL@EMAIL.CZ"
objEmail.Subject = "ERROR BACKUP"
objEmail.Textbody = strObsahSouboru</code>
objEmail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2
objEmail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserver") = sSMTPserver
objEmail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25
objEmail.Configuration.Fields.Update
objEmail.Send
End If
objSouborPikodrak.Close
Set objFSO = Nothing

Dále vytvoříme v C:\scripts\ soubor empty_dp_info_file.bat, který dáme do Win shedule každý den v 18:00

echo Soubor vyprazdnen > E:\scripts\dp\errors.txt

A to je vše přátelé, snad jsem na nic nezapomněl.

DP -> Backup -> MS Volume Shadow Copy Writers -> Add Backup

Poté pouze specifikujeme Exchange server

Next, Next, Vybereme Microsoft Exchange Writer a zaškrtneme celý store (pokud jej celý chceme zálohovat)

Potom standardně nastavíme zbytek jobu (kdy a kam se má zálohovat, to rozebírat není třeba). Následuje spuštění jobu, aby bylo co obnovovat a vrhneme se na testovací obnovu. Z našeho mailboxu smažeme nějaké nedůležité emaily.

DP -> Restore Objects ->MS Volume Shadow Copy Writers -> Nazev serveru -> MS Volume Shadow Copy Writers  a vpravém okně překlikneme “Restore mode” na “Restore files to temporary location” a zaškrtneme store, kde je náš email uložen.

V záložce Options je nutné nastavit cestu, kam mají být soubory obnoveny

Pak stačí jen kliknout na Restore a počkat na obnovení hlavní DB a logů. Následuje oprava DB, přimapování do recovery módu, obnovení mailboxu do adresáře daného uživatele a odmapování a smazání obnovy.

Pro přehlednost jsem rozdělil DB a LOGy do 2 adresářů. Následující příkazy jsou samozřejmě pro PS EX konzoli.

Zjistíme stav DB –

Eseutil /mh C:\RESTORE\MailboxDatabases\MDB01\DATABASE\MDB01.edb

Zjistíme stav logů kde E01 je prefix (bude se lišit) -

Eseutil /ml C:\RESTORE\MailboxDatabases\MDB01\LOGS\E01

Provedeme opravu DB z logů –

Eseutil /r E01 /l C:\RESTORE\MailboxDatabases\MDB01\LOGS /d C:\RESTORE\MailboxDatabases\MDB01\DATABASE

Oprava 29.8.11 – vyskytlo se mi, že pro obnovu jsem na konec musel přidat parametr /s a /a, viz kod

Eseutil /r E01 /l C:\RESTORE\MailboxDatabases\MDB01\LOGS /d C:\RESTORE\MailboxDatabases\MDB01\DATABASE /sC:\RESTORE\MailboxDatabases\MDB01 /a 

(V Exchange 2007 je možné obnovit mailbox přes klikátko – ExTRA)

Přejmenujeme DB na jiný název (u mě to bylo MDB01.edb na RecoverDB.edb)
Následující příkazy je nutné spouštět v Exchange Power Shellu.
Nastavíme namapujeme nový recovery store do Exchange –

New-MailboxDatabase -Recovery -Name RecoverDB -Server SLC-DC01 -EDBFilePath C:\RESTORE\MailboxDatabases\MDB01\DATABASE\RecoverDB.edb -LogFolderPath C:\RESTORE\MailboxDatabases\MDB01\LOGS\E01

Namountuje v Exchange DB –

Mount-Database RecoverDB

Podíváme se na namountovanou DB (a zároveň na názvy mailboxů, které můžeme obnovit) –

Get-MailboxStatistics -Database RecoverDB

Provedeme obnovu mailboxu uživatele do jeho podsložky –

Restore-Mailbox -Identity PikoDrak -RecoveryDatabase RecoverDB -RecoveryMailbox "Piko Drak" -TargetFolder "Restored content 20101111"

Nebo do jiného mailboxu

Restore-Mailbox -Identity "restore" -RecoveryDatabase RecoverDB -RecoveryMailbox "Fikr, Štěpán" -TargetFolder "Restored content lamo"

Zkontrolujeme v Outlooku obnovená data a uklidíme po sobě.

Dobrý den,
v pondělí 18. 10. 2010 došlo k aktualizaci modulu Antivirus a Antispyware (verze 1288) v našich produktech ESET Smart Security a ESET NOD32 Antivirus, která může způsobit zamrznutí počítače během přihlašování do systému Windows. K tomuto jevu může u některých zákazníků dojít až zítra, tedy 19.10. 2010. Již pracujeme na řešení situace a budeme vás průběžně informovat.Kontakty na technickou podporu naleznete na http://www.eset.cz/podpora Za možné komplikace se velice omlouváme.
Igor Hák
Technical Director

————

Dobrý den,
na adrese http://www.eset.cz/modul naleznete podrobný návod, jak odstranit “zamrznutí” počítače po přihlášení do doménového prostředí, ke kterému může za určitých okolností dojít pokud si vaši zákazníci stáhli aktualizaci modulu Antivirus a Antispyware verze 1288.
Na http://www.eset.cz/modul naleznete i návod, jak postupovat v rámci firemní sítě za použití nástroje ESET Remote Administrator.
Kontakty na technickou podporu naleznete na http://www.eset.cz/podpora Za možné komplikace se velice omlouváme.
Igor Hák
Technical Director

Zadání:
- uživatel root na novém serveru musí mít přístup bez hesla na všechny pobočky (ssh, scp), ale pobočky na něj zpět přístup nemají
- uživatel agent na novém serveru musí mít též všude přístup, uživatel agent z pobočky musí mít povolen přístup na nový server

Manuálně to opravdu dělat nebudu :D takže jako vždy – scriptem. Asi bude nejjednodušší script ukázat a okomentovat. K běhu scriptu přepokládám, že máme vygenerované klíče jak pro roota, tak pro agenta a na serverech již existují authorized_hosts apod (komunikace tam již probíhala, ale s jiným serverem).

#!/bin/sh

if [ ! "$1" ] ; then
echo "Zadejte lokalitu."
exit 1
fi

### nejdriv pridame ROOT klic z HLAVNI_SERVER na POBOČKA (pokud již nebyl přidán)
if (ssh "$1" "cat /root/.ssh/authorized_keys | grep root@HLAVNI_SERVER" >> /dev/null );
    then
        echo "INFO: $1: ROOT klic root@HLAVNI_SERVER v authorized keys jiz obsazen";
    else
        echo "OK: $1: pridavam ROOT klic root@HLAVNI_SERVER do authorized keys";
        cat /root/keys/HLAVNI_SERVER_root.id_dsa.pub  | ssh "$1" "cat - >> /root/.ssh/authorized_keys"
fi;

### potom pridame AGENT klic z HLAVNI_SERVER na pobočku (pokud již nebyl přidán)
if (ssh "$1" "cat /home/agent/.ssh/authorized_keys | grep agent@HLAVNI_SERVER" >> /dev/null );
    then
        echo "INFO: $1: AGENT klic agent@HLAVNI_SERVER v authorized keys jiz obsazen";
    else
        echo "OK: $1: pridavam AGENT klic agent@HLAVNI_SERVER do authorized keys";
        cat /root/keys/HLAVNI_SERVER_agent.id_dsa.pub  | ssh "$1" "cat - >> /home/agent/.ssh/authorized_keys"
fi;

### nakonec pridame na HLAVNI_SERVER klic AGENT z POBOČKA (pokud již nebyl přidán)
if (ssh  "HLAVNI_SERVER" "cat /home/agent/.ssh/authorized_keys | grep $1" >> /dev/null );
    then
        echo "INFO: HLAVNI_SERVER: AGENT klic s obsahem $1 v authorized keys jiz obsazen";
    else
        echo "OK: HLAVNI_SERVER: pridavam AGENT klic pobocky $1 do authorized keys";
        ssh "$1" "cat /home/agent/.ssh/id_dsa.pub" | ssh "HLAVNI_SERVER" "cat - >> /home/agent/.ssh/authorized_keys"
fi;

Potom stačí udělat druhý script s jednoduchým cyklem, kde v souboru máme seznam serverů:

#!/bin/sh
echo "Spoustim script na pridani klicu SSH na pobocky
cat /data/pobocky.lst | while read line; do
    echo Pridavam na server$line.local
    prvni-script.sh $line
done

Základ je vědět, že každá modrá smrt vygeneruje minidump soubor, který se ukládá (ve Win7) do C:\Windows\Minidump

Tyto soubory se špatně analyzují, proto jsem si stáhnul BlueScreenView. Stačí rozbalit, spustit a případně upravit složku s minidumpy (pokud analyzujete např. dumpy z jiné stanice/serveru).

Takže jsem si stáhnil minidumpy z 2 modrých smrtí jednoho serveru a otevřel u sebe na notebooku (v nastavení stačí změnit cestu k minidumpům):

Podle chyby DRIVER_POWER_STATE_FAILURE jsem vygooglil, že se jedná pravděpodobně problém s ovladačem při usínání (možná ne :D). Zkusil jsem tedy přenastavit power management (na obrázku původní nastavení), aby nic nespalo (proč taky v serveru)

Vzhledem k tomu, že se chyba vyskutuje 1x za 1/4 roku, tak uvidím výsledek na podzim :D.