Niestety nie pomyślałem wcześniej żeby zrobić zdjęcie przed porządkami, ale wyglądało to mniej więcej tak (to jedna z szaf którą dopiero mamy się zająć od tego roku):

Miejmy nadzieję, że ze wszystkim się wyrobimy i od nowego semestru wszyscy będą mogli korzystać na zajęciach i poza nimi z nowej infrastruktury. Jedną z nowości są nowe switche dla sal laboratoriów:

Dzięki nim mogliśmy pożegnać wysłużone huby 3com-a które tak dzielnie nam przez te wszystkie lata służyły:

Do czasu rozwiązania problemów z nim – mogą się zdażyć chwilowe przestoje w dostępności wydziału ze świata i odwrotnie Chyba że padnie na dobre – wtedy przestój będzie dłuższy.

W każdym razie – w razie niedostępności wydziału z świata – nie denerwować się, zrobić herbatkę – po chwili powinno samo wstać.

(Aktualizacja: odpukać – jak na razie działa)

Jak zapewne niektórzy zauważyli – zdażyło się ostatnio kilka awarii

Od początku:

1. W sobotę(8.12.2007), po zawodach mwpz – padł sobie dysk w kronosie. Cóż – po prostu padł. Podobnie jak i poprzedni dyszczek nagle przestał się kręcić. Można by sie temu dziwić, gdyby nie to że kronos ma już kilka swoich latek, a blisko 7 lat nieprzerwanej pracy to dosyć nawet jak dla dysku scsi.
2. Na kronosie stało kilka maszyn wirtualnych (opartych o linux-vserver), a na tym miedzy innymi sprawdzarka acm-u jak również vserver z wiki.

Z tego też powodu przez jakiś czas część usług była niedostępna. Co prawda starałem się wszystko jak najszybciej przywrócić, ale.. wyszło jak zwykle.

Szczegóły pominę – w każdym razie obecnie wszystko zostało z kronosa wyniesione na hypnosa i jak na razie działa.

Dlaczego na razie?

Przyszła nowa, długo oczekiwana macierz z dyskami. Tak, problem z brakującym miejscem zmierza ku końcowi. Mniej przyjemnym aspektem tego była konieczność rekonfiguracji obecnego systemu. Z uwagi na problemy z windows(atlas), nowa macierz została podłączona przed starą macierzą z dyskami systemowymi. Efektem tego jest niestety to, że linuksowe serwery, do tej pory korzystające z starej macierzy – obecnie przed dyskami z niej wykrywają dyski z nowej macierzy. Co wyklucza możliwość korzystania z nazw typu /dev/sda itepe.

Rozwiązanie jest niby proste – użycie LABEL-i albo UID-ów. Tylko że:

• pld używany na hypnosie i omedze nie obsługuje  przy starcie użycia root=LABEL ani root=UID. Nikt tego jeszcze nie miał okazji zaimplementować – wymaga toto wykrycia przez blkid albo coś w tym stylu etykiet dysków i użycia ich… Albo bootowanie tegoż w inny sposób (jeszcze się może kiedyś bardziej na ten temat rozpiszę…)
• centos na najnowszym jajku nie wykrywa dysku. hgw dlaczego, nieszczegolnie jak mam to diagnozować… po downgradzie do 2.6.18-8.1.15 jakoś działa (obsługując labele/uidy).

Potencjalne problemy typu konflikt labeli jak gdzieś indziej jakiś inny dysk wykryje – pomijam…

Obecnie calosc jest jako tako poskejana i do rebootu chodzi. A jak się rebootnie – to się zobaczy W każdym razie wszystko co stoi na hypnosie – może się zdażyć że przez kilka h będzie niedostępne.

Oczywiście w wolnych chwilach pracuję nad rozwiazaniem problemu, ale – wolnych chwil za dużo nie ma, więc całość się może przeciągnąć….

Męczyć się i zapisywać toto w htmlu? Mordęga. Pisać w texu i eksportować? Ciężko.

Ktoś kiedyś też miał ten problem i wynalazł mathtex (i wcześniejszy projekt mimetex). To prosty skrypt cgi który wywołując latexa dla zadanej komendy generuje odpowiedni obrazek. Który od razu można wstawić za pomocą htmla do strony www

Na wydziale testowo postawiłem taki serwerek – jak ktoś potrzebuje korzystać – miłej zabawy

Prosty przykład?

http://mathtex.fmcs.amu.edu.pl/mathtex.cgi?x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}

generuje

Więc wystarczy tylko to wstawić przez

<img src=”http://mathtex.fmcs.amu.edu.pl/mathtex.cgi?x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}”>

na stronie by cieszyć się ładnym i zrozumiałym równaniem

(całość na razie jest dostępna bez ograniczeń – w przypadku zbyt dużego obciążenia/wykorzystania – zostanie obcięta do obsługi wyłącznie wydziałowych domen)

A tym samym zazwyczaj skutecznie utrudnia pracę innym użytkownikom serwera.

O ile w przypadku atosa sprawa jest oczywista – uruchamianie procesów obliczeniowych jest łamaniem regulaminu, więc czy to nieudolnie napisany programy robiący fork w for(;;), czy to ważny program liczący jakieś grafy… powodował że autor trafia do specjalnie przygotowanej grupy abusers gdzie przestaje mieć możliwość szkodzenia, to już jeżeli chodzi o hypnosa zaczynam mieć wątpliwości. W sumie serwer jest o wiele potężniejszy. I to co na atosie powodowało niemal natychmiastowy alarm na naszym nagiosie i problemy z zalogowaniem, to tutaj jako tako przechodzi.

I zaczyna pojawiać się problem – czy 8 procesów “cośtam_client” to ważny proces obliczeniowy, który może sobie lecieć, czy też to nieudalnie 8-krotnie odpalone for(;;) o których autor nie ma zielonego pojęcia – odpalił i nie zdaje sobie sprawy że kapeczke utrudnia prace innym użytkownikom, albo co gorsza uniemożliwia np zrealizowanie jakis tam obliczeń przez kogoś innego.

Sprawę załatwiłoby rejestrowanie się gdzieś osób które chcą realizować obliczenia. Wtedy wszystko co by nie było zgłoszone byłoby ubijane jako przypadkowo uruchomiony proces o którym autor nic nie wie. Tylko że to powoduje automatyczny problem z osobami które zapomną się “zarejestrować” a robią jakieś arcyważne obliczenia które muszą być gotowe na 8-ą rano. A wstrętny admin je ubije 5 minut przed ich zakończeniem.

Albo też założenie że do np obliczeń trwających ponad godzinę czasu procesora służy klaster obliczeniowy, a wszystko odpalone na atosie/hypnosie po zbyt długiej chwili będzie ubijane. Ale tu znowu jest problem z uzyskaniem zgody WK na założenie konta.. co może nie być trywialne gdy np delikwentowi przypomni się w piątek o północy że na poniedziałek ma ostateczny termin oddania projektu do którego potrzebuje wyników jakiś tam obliczeń…

Ale z drugiej strony – może to niepotrzebne formalizowanie wszystkiego? Może rzeczywiście założyć że hypnos jest do “obliczeń” i pozwolić na różnorakie psucie? W sumie nie było chyba jeszcze sytuacji by maszynka była tak “zaforkowana” by nie dało się na niej pracować…