Archiwum kategorii: Serwer

WebSVN 2 i problemy z generowaniem feedów

Jeśli używasz WebSVN 2 i chcesz udostępnić użytkownikom możliwość śledzenia zmian poprzez feed RSS, nie zapomnij nadać serwerowi www uprawnień do zapisu do katalogu cache. W przeciwnym wypadku możesz się spotkać z następującym błędem:

Błąd parsowania XML: niezrozumiała seria znaków po elemencie dokumentu Obszar: http://xxx/websvn/rss.php?repname=xxx&path=%2Ftags%2F&rev=0&sc=0&isdir=1 Numer linii: x, kolumna x:<br /><b>Error creating feed file, please check write permissions.</b><br /><?xml version="1.0" encoding="UTF-8"?> ------^

Są to tak naprawdę dwa błędy: jeden, wygenerowany przez WebSVN (problem z uprawnieniami), oraz drugi wygenerowany przez przeglądarkę, która spodziewała się prawidłowego pliku XML.

Dziwy panie, dziwy

Próbuję się dostać na stronę VHCS, a dostaję localhosta. Hmm,
interesujące. Sprawdźmy co się dzieje:

zen@dragonfly:~$ ping vhcs.net PING vhcs.net (127.0.0.1) 56(84)
bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1
ttl=64 time=0.039 ms 64 bytes from localhost (127.0.0.1):
icmp_seq=2 ttl=64 time=0.036 ms

No tak, ale przynajmniej szybko odpowiada 😉

Sprawdźmy dalej:

zen@dragonfly:~$ dig vhcs.net ; <<>> DiG 9.3.2
<<>> vhcs.net ;; global options: printcmd ;; Got
answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 9721 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,
ADDITIONAL: 0 ;; QUESTION SECTION: ;vhcs.net. IN A ;; ANSWER
SECTION: vhcs.net. 86279 IN A 127.0.0.1 ;; Query time: 60 msec ;;
SERVER: 84.203.255.34#53(84.203.255.34) ;; WHEN: Sat Sep 9 12:39:12
2006 ;; MSG SIZE rcvd: 42

Odpowiedź prawidłowa, z prawidłowego serwera. A może mój lokalny
serwer DNS zwariował? No to zobaczmy, kto odpowiada za tę strefę i
sprawdźmy u źródeł:

zen@dragonfly:~$ dig vhcs.net NS ; <<>> DiG
9.3.2 <<>> vhcs.net NS ;; global options: printcmd ;;
Got answer: ;; ->>HEADER<<- opcode: QUERY, status:
NOERROR, id: 504 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2,
AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;vhcs.net. IN NS
;; ANSWER SECTION: vhcs.net. 37935 IN NS
dns1.sys.liberty-hosting.de. vhcs.net. 37935 IN NS
dns2.sys.liberty-hosting.de. ;; Query time: 62 msec ;; SERVER:
84.203.255.34#53(84.203.255.34) ;; WHEN: Sat Sep 9 12:45:09 2006 ;;
MSG SIZE rcvd: 86
zen@dragonfly:~$ dig
@dns1.sys.liberty-hosting.de vhcs.net ; <<>> DiG 9.3.2
<<>> @dns1.sys.liberty-hosting.de vhcs.net ; (1 server
found) ;; global options: printcmd ;; Got answer: ;;
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9829
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2,
ADDITIONAL: 2 ;; QUESTION SECTION: ;vhcs.net. IN A ;; ANSWER
SECTION: vhcs.net. 86400 IN A 127.0.0.1 ;; AUTHORITY SECTION:
vhcs.net. 38400 IN NS dns2.sys.liberty-hosting.de. vhcs.net. 38400
IN NS dns1.sys.liberty-hosting.de.

A jednak przenieśli się na localhosta 😉

Bind umarł po zainstalowaniu poprawek

W ostatnich dniach wszystkie maszyny z RHEL4 były intensywnie
update’owane (RedHat chyba ostro się wziął za łatanie po ostatnich
raportach). Na jednej z nich zainstalowany jest
panel kontrolny Ensim, i ta maszyna mi dzisiaj fiknęła – bind nie
wstał po restarcie (swoją drogą, to strasznie męczące musieć
restartować NS po każdej manipulacji danymi stref, dlatego polecam
PowerDNS – wiele backendów, niezła wydajność i
stosunkowo bezpieczny). W logach enigmatyczne:

Aug 14 15:00:19 www9 named[647]: listening on IPv4 interface eth0, xxx.xxx.xxx.xxx#53
Aug 14 15:00:19 www9 named[647]: zone version.bind/CH: has 0 SOA records
Aug 14 15:00:19 www9 named[647]: zone version.bind/CH: has no NS records
Aug 14 15:00:19 www9 named[647]: view.c:347: REQUIRE((&view->references)->refs > 0) failed
Aug 14 15:00:19 www9 named[647]: exiting (due to assertion failure)

Co się okazało? Ponieważ konfiguracja binda została zmieniona
przez panel Ensim, up2date nie zainstalował jego nowej wersji:

Fetching Obsoletes list for channel: rhel-i386-es-4...

Fetching rpm headers...
########################################

Name                                    Version        Rel
----------------------------------------------------------

The following Packages were marked to be skipped by your configuration:

Name                                    Version        Rel  Reason
-------------------------------------------------------------------------------
bind                                    9.2.4          16.EL4Config modified

Wystarczyła opcja -f (force) i po sprawie: #up2date
-f -u bind

Dell PowerEdge 1855 + Ubuntu = brak jakichkolwiek problemów ;)

Posiadamy w firmie jedną sympatyczną szafkę zawierającą serwery
blade Dell PowerEdge 1855. Jakiś czas
temu okazało się, że jeden z nich niby ma zainstalowany system, ale
jest kompletnie nie używany (wygląda zatem na to, że mam jedną
licencję SLES 9.0 na zbyciu). Niezłe
marnotrawstwo, prawda? Spytacie dlaczego wcześniej nie został do
niczego użyty? Bo mój szef jest bardzo niezdecydowany i ciężko
podejmuje decyzje. Więc podjąłem go za niego i przeznaczyłem do
implementacji testowej XEN. Cóż, Irlandia po prostu.

Pamiętając, że kilka miesięcy wcześniej szukając informacji na
temat Debiana na PE1855 natknąłem się raczej na opisy problemów niż
rozwiązań chciałem zostawić SLES na tym serwerze. Ostatecznie – i
dobrze – postanowiłem zaryzykować instalację Ubuntu Server. Całość operacji przebiegła bez
żadnego problemu.

Dla ciekawskich kilka informacji:

xxx@hostvps1:~$ lspci
0000:00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 09)
0000:00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 09)
0000:00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 09)
0000:00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 09)
0000:00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
0000:00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
0000:00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
0000:00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
0000:03:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09)
0000:03:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09)
0000:03:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09)
0000:03:00.3 PIC: Intel Corporation 6700PXH I/OxAPIC Interrupt Controller B (rev 09)
0000:04:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)
0000:05:04.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
0000:05:04.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
0000:06:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]

oraz

xxx@hostvps1:~$ lsmod
Module                  Size  Used by
dm_mirror              19712  0
bridge                 52128  0
ipv6                  264064  14
dm_mod                 51536  3 dm_mirror
parport_pc             28008  0
lp                     12880  0
parport                37516  2 parport_pc,lp
e1000                 108980  0
hw_random               6440  0
e752x_edac             11392  0
edac_mc                14080  1 e752x_edac
sg                     34992  0
sr_mod                 17060  0
ext3                  124944  2
jbd                    55336  1 ext3
ehci_hcd               31880  0
uhci_hcd               32288  0
mptspi                  8584  3
mptscsih               34944  1 mptspi
mptbase                48992  2 mptspi,mptscsih
thermal                13456  0
processor              20796  1 thermal
fan                     5000  0

Obecnie na serwerze zainstalowany jest kernel z bianarnej wersji
XEN i działa 😉 Pozostało mi tylko zainstalować Dell OpenManage. Nie będzie to
z pewnością trywialne, bo Dell udostępnia to jedynie dla
wspieranych przez siebie dystrybucji, czyli RHEL i SLES.