lazy

1) Cookie: session_id=5163f3xxxxxxxxxae17733e6f2; pass_hash=babb1xxxxxxxxxxxxxxx; topicsread=a%3A6%3A%7Bi%3A14507%3Bi%3A1229460779%3Bi%3A5229%3Bi%3A1229460100%3Bi%3A15601%3Bi%3A1229460442%3Bi%3A11938%3Bi%3A1229460699%3Bi%3A15599%3Bi%3A1229460729%3Bi%3A15573%3Bi%3A1229460862%3B%7D 2) GET /xannstat/stats.php?href=http%3A//www.webhostingtalk.pl/index.php%3Fshowtopic%3D15573%26hl%3D&referer=http%3A//www.webhostingtalk.pl/index.php%3Fact%3DSearch%26nav%3Dlv%26CODE%3Dshow%26searchid%3Dacab2fd2f195cf333b3b7b4373e6f978%26search_in%3Dtopics%26result_type%3Dtopics%26lastdate%3D0 HTTP/1.1 Host: www.webhostingtalk.pl Referer: http://www.webhostingtalk.pl/index.php?showtopic=15573&hl= Cookie: .. GLOWNA=1; ... ODWIEDZINY=1; ... session_id=5163f3fddxxxxxxxx5eed8eae17733e6f2; pass_hash=babb1e68ba4xxxxxxxxxxxx; topicsread=a%3A6%3A%7Bi%3A14507%3Bi%3A1229460779%3Bi%3A5229%3Bi%3A1229460100%3Bi%3A15601%3Bi%3A1229460442%3Bi%3A11938%3Bi%3A1229460699%3Bi%3A15599%3Bi%3A1229460729%3Bi%3A15573%3Bi%3A1229460862%3B%7D HTTP/1.1 200 OK Date: Tue, 16 Dec 2008 20:54:23 GMT Set-Cookie: PHPSESSID=616d59b61bce38c29162d7b978a5e7f4; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Set-Cookie: ODWIEDZINY=1 Set-Cookie: 7fbb8cb489c0cbb412b7ca5cdfa1349ae09a514c=1 3) GET /index.php?showtopic=15573&st=20 HTTP/1.1 Host: www.webhostingtalk.pl Referer: http://www.webhostingtalk.pl/index.php?showtopic=15573&hl= Cookie: topicsread=a%3A6%3A%7Bi%3A14507%3Bi%3A1229460779%3Bi%3A5229%3Bi%3A1229460100%3Bi%3A15601%3Bi%3A1229460442%3Bi%3A11938%3Bi%3A1229460699%3Bi%3A15599%3Bi%3A1229460729%3Bi%3A15573%3Bi%3A1229460862%3B%7D; PHPSESSID=616d59b61bce38c29162d7b978a5e7f4 HTTP/1.1 200 OK Date: Tue, 16 Dec 2008 20:54:27 GMT Set-Cookie: session_id=xxxxxxxxxxxxxffae77298305e; path=/; domain=.webhostingtalk.pl; httponly Set-Cookie: topicsread=a%3A6%3A%7Bi%3A14507%3Bi%3A1229460779%3Bi%3A5229%3Bi%3A1229460100%3Bi%3A15601%3Bi%3A1229460442%3Bi%3A11938%3Bi%3A1229460699%3Bi%3A15599%3Bi%3A1229460729%3Bi%3A15573%3Bi%3A1229460867%3B%7D; path=/; domain=.webhostingtalk.pl Set-Cookie: modpids=deleted; expires=Mon, 17-Dec-2007 20:54:26 GMT; path=/; domain=.webhostingtalk.pl wyglada na to ze miedzy 2 a 3 session_id jest uwalane, moze jakas interakcja z PHPSESSID ? -- http://lazy.digart.pl/

OPTIONSE="-e ssh -p 666" OPTIONS="-avz" rsync "$OPTIONSE" $OPTIONS ... albo dodac sobie odpowiedni port do ssh_config -- Lazy

przeciazony dysk na glownej maszynie -- lazy.digart.pl to nie mówi niczego o naturze dysku

przecież xeony z serii X3xxx to rebrandowane core 2 duo/quad -- Lazy

zbieranie statystyk w taki sposob nie jest najlepszym pomyslem sugeruje zapoznac sie z tym http://www.linuxjournal.com/article/6144 -- Lazy

jesli zalezy Ci glownie na tresci to wygodniejszy od tcpdump bedzie ngrep (http://ngrep.sourceforge.net/) -- http://lazy.digart.pl

zarezerwowane dla roota 5%, wylaczyc mozna tune2fs -m 0 /dev/sda2 (nie trzeba przemontowywac) -- http://lazy.digart.pl/

ja pamietam np. przywrocenie baz z chyba 2 dniowego backupu na nowym serwerze w Polsce i link na stronie glownej do starego serwera gdzie klienci mogli sobie pobrac aktualna wersje bazy, na darmowym hostingu takich numerow chyba nawet nie robia -- Lazy

moze masz tam jakiegos firewalla iptables -L -vn najlepiej sie skontaktuj z supportem by sprawdzili czy te adresy dzialaja poprawnie bo z tracert widac ze to nie vps odrzuca raczej pakiety -- Lazy

twoje dnsy czyli ns1.solojuve.com. 172800 IN A 194.24.175.18 ns2.solojuve.com. 172800 IN A 194.24.175.19 nie odpowiadaja nawet na ping obecnie, to poprawne adresy ? jesli nie to musisz zmienic te ipki w panelu az domeny

hmm a dig +trace domena.pl

klej wydaje sie dzialac a co pokazuje whois domena.pl jest wydelegowana na ns1.domena.pl, ns2.... ? -- Lazy

Ale megi pisze o szczegolnym przypadku, kiedy ns-y sa w tej samej domenie ktora obsluguja. Wtedy przy delegacji trzeba dodac tzw. klej czyli rekord A odpowiadajacy w tym przypadku ns1.domena.pl itp. do odpowiednich root serverow. W wiekszosci paneli sprowadza sie to do opcjonalnego dodania adresu ip serwerow dns i mozna to nazwac rejestracja serwerow dns. -- Lazy

pomysleli http://www.proftpd.org/docs/directives/lin...efaultRoot.html w auth.log powinnoc cos o tym byc -- Lazy

ne ten pomysl chyba Sun wpadl pierwszy http://en.wikipedia.org/wiki/Project_Blackbox -- Lazy

google define:unsolicited -> unasked: not asked for; "unasked advice"; "unsolicited junk mail" czyli niechciana, twoj newsletter nie powinien wpadac w ta kategorie, najlepiej ich zawczasu uprzedzic bo moga to uznac za spam i zablokowac -- Lazy

moze maja o taki plan na czas awarii -- Lazy

z chello gdansk round-trip min/avg/max/stddev = 112.155/118.058/145.241/9.441 ms task rtt min/avg/max/mdev = 107.404/107.486/107.562/0.213 ms wiec niezle -- Lazy

http://dominia.org/djao/limitipconn2.html -- Lazy

phpmyadmin chyba ma problemy z ustawianiem odpowiedniego kodowania polaczenia, najprosciej ustaw kodowanie strony (jezyk) na latin2 czyli tak jak jest ustawione kodowanie polaczenia, i edytuj dane w latin2, i tak wszystko zostanie przekodowane na utf8 -- lazy

to sa tylko kodowania domyslne, i tak set names w zrzucie ustawi sobie co chce wazna jest tylko 1 rzecz 1) na poczatku zrzutu za pomoca set names musi byc oznaczone kodowanie pliku w twoim przypadku zrob tak 1) zrzut z set names latin2, by uzyskac poprawny tekst utf8 2) zamien set names lain2 na set names utf8 i zaimportuj ponownie, najlepiej do jakies 2giej bazy 3) pododawaj wszedzie gdzie chcesz uzywac utf8 set names utf8 zaraz po nawiazaniu polaczenia -- Lazy

sprobój set names latin2; na localhoscie, masz prawdopodobnie źle zakodowane znaki w bazie, ustawiajac set names tak jak na phpmyadminie powinienes dostac poprawe poprawne znaki w utf-8 trzeba pamietac o tym ze ustawienie kodowania bazy nie wpływa na kodowanie z jakim bedzie sie odbywac komunikacja z mysql i pewnie wrzuciles utf8 do bazy mimo ze polaczenie bylo ustawione na latin2 -- Lazy

nazwa ma duze znaczenie bo rozkladanie obciazenia na kilka systemow a budowa jednego komputera to cos zupełnie innego autor watku pisze "Nie do końca oto mi chodzi. W tym artykule opisane jest jak wykorzystać moc obliczeniową kilku komputerów. A mi chodzi o zbudowanie jednego komputera." wiec rozwiazania klastrowe w stylu mosix odpadaja nie polaczysz w zaden sposob 2 plyt i nie stworzysz z tego jednego wiekszego systemu SMP, nie ma to sensu o wiele prosciej jest zbudowac 1 płyte wielosocketową, lub uzywac oprogramowania klastrowego ktore umozliwi nam równoległe wykonanie obliczen na wielu osobnych maszynach takie dokladanie kolejnych płyt z procesorami udać by się mogło dopiero przy architekturze NUMA, ale to juz nie ta klasa rozwiazan co pcty (http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access) tam mozemy mowic ze to jest jeden komputer -- Lazy

nie dzialaja jako jedna jednostka, oba maja osobne kernele, dyski, pamiec i inne zasoby, mozliwa jest wyłacznie migracja procesow miedzy maszynami, ale nie moga one uzywac np. pamieci dzielonej oraz nie ma mowy o migracji pojedynczych watków wiec ani mysql ani apache nie beda w stanie skozystac z tego autor watku pisze o tuningu, tworzeniu komputera z 1 dyskiem 1 karta graficzna z polaczenia kilku plyt i uruchamianiu windowsa, mosix ma sie do tego nijak -- Lazy

misioo moze dzialal na czyms w stylu mosixa wiec procesy mogly tam sobie z pewnymi ograniczeniami migrowac na mniej obciazona maszyne co podwyzszlo wydajnosc, ale nijak to sie ma do kumulowania mocy "możliwość połączenia kilku płyt głównych i skumulowania jej mocy" wspoldzielenia karty graficznej, dysku i budowy 1 komputera -- Lazy