Uncategorized

Dyski WD EADS/EARS wysoki Load Cycle Count

1 komentarz

Dyski WD EADS/wczesne EARS mają buga (lub ficzer), jeśli są nieużywane przez 8 sekud to głowice są parkowane. Jeśli dysku używa windows, to nie jest to żaden problem, ale jeśli dysk jest mocniej wykorzystywany, w szczególności w macierzy raid, to częste parkowania nie są dobre. Podobno dysk wytrzymuje około miliona parkowań, niektórzy mówią o 300000, a smartmon monituje gdy przekroczy 600000.

Liczbę można sprawnić wywołując smartctl (doinstalować można przez apt-get install smartmontools):
smartctl -a /dev/sda |grep Load_Cycle
193 Load_Cycle_Count 0x0032 066 066 000 Old_age Always – 347125
Liczba 347125 to aktualna liczba parkowań od początku życia dysku.

W innych dyskach można wyłączyć parkowanie poprzez:
hdparm -B 255 /dev/sda (lub 254, czasem działa jedno czasem drugie) ale przy dyskach WD EADS/EARS nie działa ta metoda. Dyski mają w firmware zaprogramowane wyłączanie. Jedyną metodą obejścia jest przeprogramowanie firmware. Robi się to przy użyciu programu DOS
o nazwie WDIDLE3.exe (do pobrania ze strony http://www.synology.com/support/faq_images/enu/wdidle3.zip

OpenVPN

Openvpn point-to-point

Generujemy klucz dla obu stron:
openvpn --genkey --secret klucz.key

Plik konfiguracyjny serwera: /etc/openvpn/pi.conf
dev tun
ifconfig 10.10.1.1 10.10.1.2
port 31415
proto tcp-server
secret klucz.key

Plik konfiguracyjny klienta: /etc/openvpn/ro.conf
dev tun
proto tcp-client
remote 195.64.175.x
ifconfig 10.10.1.2 10.10.1.1
port 31415
ping 180
ping-restart 420

uruchamiamy:
ro# /etc/init.d/openvpn start pi
pi# /etc/init.d/openvpn start ro

MySQL

Kilka instancji mysql na jednym serwerze

useradd mysql2
mkdir /var/run/mysqld2
chown mysql2.mysql2 /var/run/mysqld

do /etc/mysql/my.cnf należy dodać sekcję:
[mysqld_multi]
mysqld = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin
user = root
password = haslo

oraz sekcję [mysql] zmienić na [mysql1] oraz dodać kolejną [mysql2], itd.

W każdej sekcji należy ustawić:
[mysql2]
user = mysql2
pid-file = /var/run/mysqld2/mysqld.pid
socket = /var/run/mysqld2/mysqld.sock
port = 3307
basedir = /usr
datadir = /srv/db/mysql2

startujemy wybrane mysql, np.
/etc/init.d/mysql start 2

MySQL

Error 2020: Got packet bigger than ‚max_allowed_packet’ bytes when dumping table

Podczas zrzutu bazy pojawia się error:
mysqldump -u user -phaslo baza >plik
mysqldump: Error 2020: Got packet bigger than ‚max_allowed_packet’ bytes when dumping table `lex_tresci` at row: 38566

Należy ustawić max_allowed_packet na wyższą wartość. Nie pomaga ustawienie w my.cnf. Należy dodać do wywołania mysqldumpa:
mysqldump –max_allowed_packet=512M -u user -phaslo baza >plik

X11

Xserver: (EE) VESA: Kernel modesetting driver in use, refusing to load

Po upgrade Linux Lenny do Squeeze, przestał uruchamiać się Xserver. Występował następujący błąd:

(II) VESA: driver for VESA chipsets: vesa
(II) Primary Device is: PCI 01@00:00:0
(EE) VESA: Kernel modesetting driver in use, refusing to load
(WW) Falling back to old probe method for vesa
(EE) No devices detected.

Fatal server error:
no screens found

Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

Pomogło usunięcie pliku /etc/X11/xorg.conf

Router, Shell

Generowanie dhcpd.conf fixed ip

Mamy plik postaci: IP MAC w każdej linii, np:
192.168.10.2 [tab] 00:00:00:00:00:01, chcemy wygenerować wpisy statyczne dla dhcpd.conf.
Używamy skryptu:
for i in `cat ip_mac_dhcp.txt|sed 's/\\t/#/g'`; do
IP=`echo $i|cut -d '#' -f1`
MAC=`echo $i|cut -d '#' -f2`
echo "host $IP {";
echo " hardware ethernet $MAC;"
echo " fixed-address $IP;"
echo "}"
done

Uncategorized

Remote Insight error

Brak możliwości dostępu przez www do karty zdalnego zarządzania, przy próbie połączenia pod adres pojawia się:

Error code: ssl_error_no_cypher_overlap

Oznacza to, że przeglądarka i serwer nie mogą uzgodnić wspólnego szyfrowania.

Pomaga upgrade firmware karty, z 2.30 na 2.5x, ten zawiera 128-bit SSL.

RAID / Storage, Shell

Odzyskiwanie danych

Z uszkodzonego dysku/partycji.
Nie należy pracować, montować itp. uszkodzonego dysku, pierwsze co należy zrobić, to pełną kopię uszkodzonych partycji lub dysków, np.:
dd noerror
ddrescue zrodlo cel (bez in= out=)
(próbuje kilka razy odczytać błędne sektory)

albo:
dd in=plik1 out=plik2 conv=noerror,sync

Program, który potrafi odzyskać dane z urządzenia, nawet jeśli na nim jest już inny system plików, ale nie są nadpisane wszystkie sektory:
http://foremost.sourceforge.net/

RAID / Storage

Stan dysków w macierzy sprzętowej RAID

Jak sprawdzać, czy dyski pracują w macierzy poprawnie, czy może któryś jest uszkodzony?
Jeśli to macierz Serveraid*, to ładujemy moduł mptctl i używamy programu mptstatus
# mpt-status -i 1
ioc0 vol_id 1 type IM, 2 phy, 68 GB, state OPTIMAL, flags ENABLED
ioc0 phy 0 scsi_id 1 IBM-ESXS DTN073C3UCDY10FN S27P, 68 GB, state ONLINE, flags NONE
ioc0 phy 1 scsi_id 5 IBM-ESXS DTN073C3UCDY10FN S29C, 68 GB, state ONLINE, flags NONE

Status „OPTIMAL” mówi nam, że wszystko jest ok.

Jeśli mamy macierz niekompletną i włożymy czysty dysk widzimy, że zaczyna się odbudowywać:
Sep 29 12:48:37 c1 kernel: [50303.570505] mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=1
Sep 29 12:48:37 c1 kernel: [50303.570515] mptbase: ioc0: PhysDisk is now online, out of sync
Sep 29 12:48:37 c1 kernel: [50303.573240] mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=1
Sep 29 12:48:37 c1 kernel: [50303.573248] mptbase: ioc0: PhysDisk is now initializing, out of sync
Sep 29 12:48:37 c1 kernel: [50303.852611] mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=1
Sep 29 12:48:37 c1 kernel: [50303.852619] mptbase: ioc0: PhysDisk is now online, out of sync
Sep 29 12:48:37 c1 kernel: [50303.866114] scsi host2: mptspi: ioc0: Integrated RAID detects new device 1
Sep 29 12:48:37 c1 kernel: [50304.261578] mptbase: ioc0: RAID STATUS CHANGE for VolumeID 1
Sep 29 12:48:37 c1 kernel: [50304.261588] mptbase: ioc0: volume is now degraded, enabled, resync in progress

Odbudowa trwa jakiś czas i po nim widzimy, że:
Sep 29 23:26:34 c1 kernel: [88580.917523] mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=1
Sep 29 23:26:34 c1 kernel: [88580.917533] mptbase: ioc0: PhysDisk is now online
Sep 29 23:26:34 c1 kernel: [88580.918436] mptbase: ioc0: RAID STATUS CHANGE for VolumeID 1
Sep 29 23:26:34 c1 kernel: [88580.918444] mptbase: ioc0: volume is now optimal, enabled, resync in progress
Sep 29 23:26:34 c1 kernel: [88580.921791] mptbase: ioc0: RAID STATUS CHANGE for VolumeID 1
Sep 29 23:26:34 c1 kernel: [88580.921804] mptbase: ioc0: volume is now optimal, enabled
Macierz się odbudowała. Odbudowa RAID1 2*73GB w IBM x345 trwała 10.5 godziny.

Jeśli korzystamy z cciss, korzystając z smatrctl możemy sprawdzić stan poszczególnych dysków:
smartctl -d cciss,0 -a /dev/cciss/c0d0
smartctl -d cciss,1 -a /dev/cciss/c0d0
Device: IBM-ESXS BBD073C3ESTT0ZFN Version: JP86
Serial number: K407DKQK
Device type: disk
Transport protocol: Parallel SCSI (SPI-4)
Local Time is: Thu Sep 30 00:24:47 2010 CEST
Device supports SMART and is Enabled
Temperature Warning Enabled
SMART Health Status: OK

Current Drive Temperature: 34 C
Current start stop count: 44 times
Elements in grown defect list: 0

Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 590731 17 0 0 0 4913.778 0
write: 0 0 0 0 0 3478.495 0
Non-medium error count: 187
Last n error events log page
No self-tests have been logged
Long (extended) Self Test duration: 1440 seconds [24.0 minutes]