sziasztok
Most készülök beüzemelni egy svn (1.5.1) szervert a fejlesztőknek.
150 fejlesztő
13-18.000 kisebb(max 3 MB) fájl verzió követése.
Csatlakozás Apache-n keresztül.
Van valakinek tapasztalata ebben a témában?
köszi
Xen 4 alatt fut néhány HVM masinám, majd elkezdek erre a dom0-ra ssh-val másolni gigás file-t.
Nos, a kernel ezt dobja pár másodperc után : Soft lockup CPU stuck for XX seconds ...majd a gépen minden meghal.
Olvasgatva, ez valamilyen bottleneck lehet...noapic (amit javasolnak a neten) a kernel opcióknál meg nem mehet, mivel a Debian 64bites Xen kernel nem bootol így.
Ha nincs ssh másolás, minden ok.
Valaki találkozott már ilyennel?
Üdv mindenkinek!
A következő gondodba futottam bele.
Van egy kamera rögzítő, amit csatlakoztattam a helyi hálóhoz. Helyi hálózatról tökéletesen elérhető, nézhető, de ha máshonnan be VPN-ezek a szerverre, akkor csak a bejelentkezési oldalig jutok el.
Felhasználóónév és jelszó autentikáció után először kapok egy olyan üzenetet, hogy:
"The requested URL was not found on this server"
egy oldal frissítés után a Squid a következő hibát dobja:
ERROR
The requested URL could not be retrieved
While trying to retrieve the URL: .....
The following error was encountered:
* Zero Sized Reply
Squid did not receive any data for this request.
Próbáltam már a Squidot beállítani, hogy ne cache-je az oldalt, meg minden lehetőséget, de sajnos nem jutottam semmire.
(szerver: SME Server 7.5.1
squid: 2.5.STABLE14)
válaszotokat előre is köszi.
szép napot mindenkinek.
üdv
A 4-es Xen alatt már definiálva van elvileg a "fault tolerance" motor, Remus alapokon.
http://wiki.xen.org/xenwiki/Remus
Gyakorlati tapasztalat valakinél?
Debian 6-ra (64 bit) tenném, iscsi storage-el.
Sziasztok!
Egy Debian Squeeze-en futó exim levelezéssel szenvedtem tegnap...
A kimenő levelek ezen a gépen mennek keresztül, viszont egy levelet sehogy sem akart átvenni tőle az UPC szervere.
A hibaüzenete ez volt: "automated process detected unsolicited content"
Egészen addig nem is ment át, amíg az idézetként csatolt eredeti üzenetet nem töröltem a végéről.
Volt benne egy hivatkozás (egy amúgy rendben lévő oldalra), valószínűleg ez nem tetszett neki.
Ami lényeges, hogy erről a problémáról a feladót nem tudta értesíteni a rendszer, frozen állapotba került a levél.
A feladó e-mail címe gmailes, erről alapvetően valóban nem tud a rendszer, de azonosítást követően hagyja elküldeni az smtp.
Ha közvetlenül a gépen beállított e-mail fiókból küldtem ugyanezt a levelet, a hibaüzenet meg is érkezett, tehát visszatalált rendszeren belül a hibaüzenet a küldőhöz. Más kérdés, hogy valószínűleg a hibaüzenetet sem venné át az UPC smtp-je, de ezt ki sem küldi a rendszer.
Kérdésem, hogy hogyan lehetne a legkorrektebben megoldani, hogy az ilyen jellegű hibaüzenetek visszataláljanak a küldő fiókjába - a legjobb lenne, ha közvetlenül az azt indító felhasználó levelezésébe.
Hogy érdemes ezt csinálni?
Sziasztok!
Egy kérdésem volna, lehet hogy egyszerű de marha régen iptables-eztem/tűzfalaztam gw-ztem, ezért megkérdezem.
Adott egy debianos gép, két hálókártyával (eth0, eth1), természetesen X nélkül. :)
Terv: A gép gateway-ként működne egy belső háló és egy router között.
/etc/network/interfaces:
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
a 192.168.1.1 egy router, amin megy a net. OK. Linuxon emiatt van net. Ez egy gateway lesz, ergo másik hálókártya, kettő közé iptables. OK. Másik hálókártya:
iface eth1 inet static
address 192.168.0.3
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
átjáróként valahogyan viszont az eth0 lenne. Ezt hogy is kell csinálni? Előbb csak transparent proxy lenne, később iptables-es szűrés lenne a dologból.
Valami route add net default gw is rémlik...tudna valaki valami okosat mondani nekem?
Köszi előre is!
ELvileg megvan a "bug":
Lentebb hozzászólásban említettem, hogy Scientific Linuxszal is működik. Ill működött amíg nem toltam egy yum update-t. Reboot után érezhetőbben melegebb lett a gép. Kis játszadozással meglett melyik kernel verziónál kefélődtek el a dolgok:
http://freshmeat.net/articles/red-hat-updated-kernel-packages-fix-sever…
A leírásban két dolog tűnt fel:
The Radeon GPU drivers in the Linux kernel were missing sanity checks for
the Anti Aliasing (AA) resolve register values which could allow a local,
unprivileged user to cause a denial of service or escalate their privileges
on systems using a graphics card from the ATI Radeon R300, R400, or R500
family of cards. (CVE-2011-1016, Important)
Valamint egy bug fix:
680000 - CVE-2011-1016 kernel: drm/radeon/kms: check AA resolve registers on r300
Szerintem ez ugyanaz.
Több ötletem nincs, inkább használom a bugos de hűvösebb gépemet... :(
Viszont nem tudom hogy a JoliOS hogy működhet hűvösen a 2.6.35-ös kernellel. Lehet hogy több új kernelnek is meg kell érkeznie mire egy ilyen bugfix visszakerül az upstreambe? Merthogy 2.6.38-as kerneltől tuti nem jó. Igazából lehetne még mit próbálgatni, de már belefáradtam.
----------------------------------------------------------------------------------
Van nekem egy ati radeon x1300 lapkám a thinkpademben. Ubuntu 11.04 (és egy rövid próba alapján Fedora 15) alatt a kártya elég meleg. Maximum órajelen és üresjáraton 90fok körül szokott alakulni, de egy youtube hd videó könnyen 100 fok fölé is emeli. Éppen ezért általában minimum órajelen használom, így csak 70-75fok körül jár, viszont a csilivili desktopok így már nem mennek túl szépen. Igazából beletörődtem hogy ez ilyen, de tegnap kíváncsiságból feltettem a Joli OS-t.
Rövidre fogom, a számok magukért beszélnek:
Ubuntu/Fedora:
cat /sys/class/drm/card0/device/power_method
profile
cat /sys/class/drm/card0/device/power_profile
high
cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 425000 kHz
current engine clock: 418500 kHz
default memory clock: 352000 kHz
current memory clock: 351000 kHz
Joli OS: detto ugyan ez a beállítás. GPU 70 fok körül, görgetés gyorsabb.
a power_profile-t low-ra állítva gpu 60fok, viszomt görgetés még így sem akad számottevően, pedig ugyanez Fedorán/Ubuntun már elég darabos (és jóval melegebb)
Igyekeztem a lehető leghasonlóbb körülményeket kialakítani, tehát ugyanazok a programok futottak, ugyanazt az oldalt néztem, compiz minden esetben futott.
Ezek után feltettem a natty kernelét JoliOS-re. Az eredmény elég vicces, a hőmérséklet kb pont fél úton állt be, 85 fok körül. Mondjuk a különbséget lehet be lehet tudni a unity/ubuntu erőforrás igényének.
Igazából kérdeznem nincs mit, én megelégszem a JoliOS-szel. Aki esetleg hasonló cipőben jár az ati kártyájával ajánlom neki, kíváncsi vagyok hogy ez minden kártyánál fent áll, vagy csak az én kártyám esetében van akkora kuszaság a kernelek/driverek minőségét illetően.
Aki pedig kicsit jártasabb a linux lelki világában és az angolban, az küldhetne egy bugreportot, esetleg rájöhetne mi okozza a problémát :) Bevallom én ehhez nagyon kevés vagyok.
Sziasztok,
az alábbi dologra lettem figyelmes. A webserveremen minden index.* állományba belekerült egy sor ma 5:00 perckor.
A rendszer Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9.
A beírt sor ehhez hasonló, de a domain mindig változik
< img height="1" width="1" border="0" src="http://psaxfoxl.cz.cc/4897187.jpg" >
Ki mit javasol, mi történt (azt vágom, hogy vírus ami nem létezik linux alá, elnézést a cinizmusért) hogy hárítsam el a jövőben a dolgot?
up: claimscan naponta cronolva fut, nem talált semmit. :)
üdv nhw
UP2:
Megvan! ahogy sokan sejtették. Kolléga csinált a céges hálózathoz egy FTP-t amiben volt 1 virtual directory a webserver www könyvtárához. Van blokkolásunk 3 hibás próbálkozás után, de lopott jelszóval nem kellett próbálkozni. :(
Üdv,
Mint tudjuk, barriers nélkül a fordított sorrendű írás simán adatvesztést okozhat bármilyen átlagos naplózó fájlrendszernél. Az ugye köztudott, hogy a winyók writeback cache-e áramszünet esetén gyakori felelőse a fájlrendszer korrupcióknak.
Most viszont "sima" kernel panic-ok után lett korrupt a RAID6-os XFS fájlrendszerem, pedig semmiféle ''mdadm --force'' -ot nem használtam és áramtalanításról szó sincs. A BSOD oka egy experimental hw driver, de ez más téma. A kérdés, hogy hogy történhetett ez? (nem hiszem, hogy XFS hiba)
A tippem az, hogy az SWRAID[56] barriers nélkül nem figyel arra, hogy az adatok megfelelő sorrendben legyenek kiírva. Emiatt -a szóló winyó WB cache-ével ellentétben- egy rosszkor jött BSOD is elég ahhoz, hogy egy fordított sorrendű írás úgy maradjon félbe, hogy korrumpálja a fájlrendszert. Valaki ezt meg tudja erősíteni?
(Guglival nem találok semmit a témában, pedig biztos ki volt már valahol tárgyalva, egy link is elég lenne. thx)
UPDATE: továbbra se találok tuti infót, de teljesen logikus, hogy felborul a sorrend az SWRAID[56] miatt, hiszen másképp csak sorban írhatnának a diszkek, ami a leglassabb diszk sebességére korlátozná az írás sebességet, ami nyilvánvalóan nem így van.
Üdv!
Van 2 db ibm xseries3200 szerverem LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS (rev 02)
vezérlővel szerelve.
A vezérlő tud RAID1-t
2 db 1T sata disket konfiguráltam raid 1 be
a gondom az hogy nagyon rossz írási teljesítményt kapok (főleg apró fileoknál) és az iowait felmegy akár 90% ra is.
ha a diskek raid1 helyett jbod ban vannak konfigurálva akkor egy disk is nagyságrendben gyorsabb.
mint a hwraid1 ben a kettő.
a rendszert próbáltam openfiler el illetve debian6 al.
a neten sok hasonló problémát láttam megoldás nélkül.
amiről nem találtam infót, a kernelben levő mptsas driver és az LSI által kiadott driver verziószámban különbözik az LSI javára viszont lefordítani debian alatt nem sikerült mivel hibával elszáll.
van valakinek tapasztalata érdemes erőlködni az LSi -s driverrel mert hozhat jelentős javulást vagy felejtős ?
Esetleg megoldás a problémára? a sw raidet a legvégére hagynám mint megoldást
Kösz Robit
