Strona rootnodestatus.net w całości znajduje się poza infrastrukturą Rootnode. Nawet w przypadku totalnej katastrofy ta strona powinna być dostępna z informacją co się dzieje i kiedy wrócimy do żywych. Polecam zapamiętać adres, zasubskrybować RSS lub dodać stronę do zakładek.
Bardzo proszę o odśmiecenie standardowego serwera WWW (Venema), ponieważ brakuje miejsca. Niepotrzebne rzeczy do śmietnika. Przypominam, że nie wolno trzymać tam warezu – wszystkie filmy, software, pościągane torrenty, pliki dla znajomych i inne rzeczy do kosza.
Bardzo proszę też nie przechowywać obrazów ubuntu, gier i innych rzeczy, które z łatwością można ściągnąć w dowolnym momencie z Internetu.
Właściwie to już ponad połowa stron powinna działać na Fastwebie, który jest czterokrotnie szybszy od Venemy i ma dwa razy więcej miejsca. Proszę migrować swoje strony.
Udostępniliśmy serwery torrentowe po HTTP, aby pozbyć się warezu z Venemy. Udostępniliśmy nowe serwery WWW. Jest też nowy serwer shellowy z mnóstwem miejsca. Po skończeniu się miejsca na Venemie część stron, która zapisuje dane na dysku przestanie działać poprawnie. Niestety nic więcej nie jesteśmy w stanie zrobić w tym zakresie.
Maszyna znów działa, jednak filesystem musiał zostać utworzony ponownie. Dotychczasowe pliki zniknęły. Należy ponownie zarejestrować się za pomocą komendy dowhatyouwantcauseapirateisfree i uruchomić proces rtorrent.
Został rozwiązany problem z basic auth na serwerze wall konfigurowany za pomocą pliku conf/auth. Do tej pory w przypadku istnienia tego pliku aplikacje zwracały błąd 403 Forbidden.
Aby temu zapobiec należy utworzyć pusty plik conf/auth – jego wielkość powinna wynosić 0 bajtów. Wtedy uwierzytelnienie zostanie konfigurowane dla całego vhosta, a nie jak to miało miejsce do tej pory, tylko dla location /.
Nie wdając się zbytnio w szczegóły, ustawić uwierzytelnianie i połączenie SSL można na dwa sposoby:
tworzymy pusty plik conf/auth oraz conf/ssl oraz przeładowywujemy vhosta za pomocą pliku conf/reload
tworzymy plik conf/nginx z zawartością: <nginx><ssl/><auth/></nginx>
Przy okazji został dodany automatyczny redirect na HTTPS w przypadku istnienia pliku conf/ssl.
Zmiany dotyczą jedynie serwera wall obsługującego aplikacje Ruby i Python.
Zakończyło się kopiowanie danych z korna i stallmana na maszynę stallman2. Proszę sprawdzić czy wszystko jest i ewentualnie dosynchronizować sobie rsynciem dane.
Zasoby stallmana2 są dostępne przez katalog /stallman2/<twój_login> na obu maszynach shellowych. Wszystkich obecnych użytkowników z korna i stallmana przerzucamy na maszynę stallman2 i do tej maszyny nie będą dorzucani żadni nowi użytkownicy. Taki prezent za to, że korzystacie z Rootnode
Stallman2 to nowa maszyna z dwoma procesorami Intel QuadCore 2.13GHz i 12GB pamięci RAM. Do tego 4 dyski 1.5TB SATA. System operacyjny to Debian Squeeze (testing), w której przeważnie dostępne są najświeższe wersje softu. W porównaniu z Debianem Stable jest to skok technologiczny. Pakiety na stallmanie2 mają pełną zgodność z pakietami na serwerach fastwebowych.
Niebawem na stallmanie2 pojawi się szatan. Co do reszty usług z oryginalnego stallmana to zostaną rozproszone na inne maszyny, ponieważ shellowa jednostka będzie służyć jedynie do obsługi shella i jako brama do pozostałych usług (w postaci podmontowanych zasobów NFS oraz FTP). Tak więc:
poczta dostanie dedykowaną maszynę + backupowy MX poza naszą infrastrukturą
VPN zostanie przerzucony gdzieś indziej
PostgreSQL będzie obsługiwany przez inną maszynę. Będzie to postgres w najnowszej wersji niedeveloperskiej, czyli 8.4.4.
Korn po reinstalacji systemu posłuży jako druga maszyna shellowa do obsługi nowych użytkowników. Stallman zostanie chwilowo wyłączony z naszej infrastruktury ze względu na problemy sprzętowe. Konieczna jest wymiana kontrolera dyskowego, co zostanie uczynione przy najbliższym wyjeździe do Amsterdamu.
Migracja użytkowników nie powinna potrwać dłużej niż 2 miesiące. Proszę zacząć się już zaprzyjaźniać z nowym środowiskiem, a potrzeby zgłaszać za pomocą mailisty. Wkrótce zostanie wysłany e-mail do wszystkich użytkowników z prośbą o przeniesienie. Następnie dostęp do maszyn shellowych zostanie zablokowany na pewien okres czasu. Jeśli ktoś sobie przypomni o przenosinach dostęp będzie udzielany na żądanie.
Pracy jest dużo. W międzyczasie zostanie dorzucona jeszcze obsługa Javy na fastweb2.
Miejmy nadzieję, że wszystko zakończy się sukcesem i pójdzie zgodnie z planem.
Wkradł się błąd w opisie aplikacji Ruby i Python, który jest dosyć istotny. Katalog public w żadnym wypadku nie powinien linkować do katalogu aplikacji. Można sobie utworzyć ten katalog (mkdir public) i trzymać w nim pliki statyczne lub linkować do katalogu public znajdującego się aplikacja (jeśli ta takowy posiada).
W przypadku podlinkowania katalogu public do katalogu aplikacji możliwe będzie obejrzenie dowolnego pliku poprzez www, np. trac.ini itp.
Przeglądnąłem katalogi wszystkich aplikacji i zmieniłem o dwóch osób symlinka na katalog. Proszę pamiętać o tym tworząc nowe aplikacje. Opisy na wiki są już poprawione.
Serwery to w większości jednostki dwuprocesorowe quad-core, więc load na poziomie 10 nie jest niczym strasznym.
Zgłoś problem SMSem
Zgłoś problem via SMS
Poniższy formularz nie służy do zgłaszania problemów z konfiguracją, problemów lokalnych i wysyłania pytań jak skonfigurować serwer gier. Każda wiadomość oznacza wysłanie wiadomości SMS na telefon administratora, więc proszę stosować z rozwagą i nie robić sobie jaj.
