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
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
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
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
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
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.
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/
Przy tworzeniu trzeba ustalić jaki bufor zarezerwować na zmiany:
lvcreate -s -n snap_ns2 -L5G /dev/ce/ns2root
mount /dev/ce/snap_ns2 /mnt/
Teraz można korzystać, a na końcu odmontować i usunąć (ważne, bo zmniejsza wydajność).
umount /mnt
lvremove /dev/mapper/ce-snap_ns2
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]
Od niedawna, po przełożeniu dysku z linuksem do innego komputera, lub zmianie karty sieciowej zmienia się numer interfejsu używanego przez system. Zamiast eth0 mamy eth1, zamiast eth1 eth2, itd. Jest to spowodowane zapamiętaniem adresu MAC interfejsu sieciowego i przypisaniem do niego odpowiedniego interfejsu. Przypisania są zapisane w pliku /etc/udev/rules.d/z25_persistent-net.rules, np.:
SUBSYSTEM==”net”, DRIVERS==”?*”, ATTRS{address}==”00:09:6b:58:57:63″, NAME=”eth0″
Wystarczy usunąć powyższy wpis, wyładować moduł od karty i ponownie mamy interfejs eth0.