Blog domo

.:.:.Silicon Hill Mirror.:.:.

Już od przynajmniej pół roku korzystam z mirrora http://ftp.sh.cvut.cz/ używając go przede wszystkim jako repozytorium dla paczek dla Arch Linux. Czasem korzystam z niego również do ściągnięcia np iso z Ubuntu itp. Naprawdę szybki i często aktualizowany mirror. Co do transferów, to rzadko kiedy nie osiągam maksimum downloadu swojego łącza, które wynosi ok 25-30Mb/s.

Na szybko, przykładowe adresy:

do wrzucenia do mirrorlist w Arch Linux (dla wersji x86_64)
Server = http://ftp.sh.cvut.cz/MIRRORS/arch/$repo/os/x86_64

ISO Ubuntu
http://ftp.sh.cvut.cz/MIRRORS/ubuntu-releases/

Mirror udostępnia paczki również m.in. dla Ubuntu i Debiana, więc można spróbować dodać go do  sources.list

Na serwerze zainstalowana jest i skonfigurowana Samba w wersji 3.5.6 , przez którą udostępniam sobie kieszeń z dyskiem na USB, a później zasoby samby montuję sobie na laptopie, który korzysta z wifi i AP działającego w trybie b/g/n.

Od dłuższego czasu borykam się ze sporym problemem związanym z bardzo niskim poziomem downloadu, który wynosi ok 1,4MB/s i co dziwne, upload jest ok, bo oscyluje w granicach wydajności karty sieciowej w serwerze, czyli ok 10MB/s. Dodatkowo ważne jest to, że gdy montuję zasób samby na Win7 wszystko jest OK- transfery w obie strony ok 10MB/s. Scp oraz ftp również nie działają prawidłowo.
Mogę w związku z powyższym założyć, że teoretycznie nie jest to problem sprzętowy i raczej serwer samby działa OK. Próbowałem różnych opcji samby, ale bez zmian. Starałem się znaleźć również jakieś ustawienia związane  z systcl po stronie klienta (ARCH Linux), które mogłyby wpływać na tę sytuację. Niestety bez skutku. Podarowałem sobie sambę. Spróbuję w najbliższym czasie uruchomić liveCd z Ubuntu, aby zobaczyć czy sytuacja będzie kształtować się w identyczny sposób.

Skonfigurowałem nfs i z niego będę korzystać- tu wszystko działa prawidłowo pod względem transferów. Do wrzucania plików na serwer będę wykorzystywać scp oraz ftp, które również działają wyśmienicie.

Okazuje się, że to o czym pisałem w poprzednim wpisie,  nie było powodem zawieszania się serwera, a jedynie objaw tego, że się coś złego zaczyna dziać ze sprzętem. Szkoda, że kacpid nie był bardziej zrozumiały . Co się okazało?

Stwierdziłem, że w końcu wyczyszczę sprężonym powietrzem wnętrze serwera, co też i uczyniłem. W trakcie oględzin środka obudowy, rzuciły mi się w oczy w pewnym momencie dość znacznie napuchnięte kondensatory- było ich chyba z 4-5. No to już wiedziałem, że to koniec żywota płyty głównej…

Na początku miałem zamiar zakupić samą płytę główną, ale znalazłem na allegro identyczny do mojego komputer, w którym brakowało RAM i HDD a koszt był niemal identyczny co samej płyty gł. Jak widać serwer już działa .

Od jakiegoś czasu borykałem się ze sporym problemem- zawieszającym się serwerem, na którym zainstalowany jest Debian. Dziś w końcu (mam nadzieję) odkryłem tego przyczynę. Wcześniej nie znajdowałem uzasadnienia tych wybryków systemu, bo z komputerem miałem styczność dopiero w momencie, gdy już system całkowicie nie odpowiadał, a w logach była zupełna pustka.

Okazało się, że problem dotyczył acpi i procesów kacpid i kacpi-notify, które dosłownie pożerały zasoby systemowe- wykorzystanie procesora ponad 90%. Po kilku minutach system zawieszał się i nic się nie dało zrobić. Tym razem problem był o tyle nieciekawy, że po resecie komputera od razu działo się to samo, a samych procesów „zabić” się nie udawało. Spędziłem sporo czasu na szukaniu rozwiązania problemu, ale nic sensownego w google nie znalazłem, poza utwierdzeniem się w przekonaniu, że jest to jakiś większy bug.

Niestety, jedyne co mogłem zrobić w tej sytuacji, to zmodyfikować skrypty startowe, aby acpid nie uruchamiał się przy bootowaniu  oraz dorzuciłem do gruba wpis „acpi=off”. Z racji tego, że mam grub2, musiałem sprawdzić gdzie to dodać, bo gruba2 mam od niedawna i jeszcze nie poznałem go zbyt dobrze.

modyfikujemy: /etc/default/grub
dodając:  GRUB_CMDLINE_LINUX=”acpi=off”
na koniec: update-grub2

Wolałbym rozwiązać ten problem w inny sposób, ale na szczęście w moim przypadku nie ma tragedii, bo acpi na tym kompie nie potrzebuję.

Tuż przed wyjazdem na urlop, dosłownie jakieś 2h przed zjawieniem się na lotnisku, rzutem na taśmę odebrałem nowy telefon, na który swoją drogą „chwilę” poczekałem… Warto było.

Skupię się póki co na jednej rzeczy związanej z telefonem, rzeczy która dość znacznie zmniejszyła moje wydatki na połączenia wychodzące z zagranicy oraz tak naprawdę wpłynęła, na możliwość dzwonienia momentami bez zwracania uwagi na koszty. Resztę aspektów związanych z telefonem opiszę później.

Dość szybko znalazłem w Markecie (darmową) aplikację, która umożliwia wykonywanie połączeń przez VOIP, a dokładniej przez protokół SIP. Aplikacja nazywa się Sipdroid i w zasadzie jest pierwszą i jedyną, którą do tej pory przetestowałem, ale mogę powiedzieć, że spisuje się co najmniej zadowalająco. Po zainstalowaniu aplikacji i wpisaniu danych serwera VOIP, dodaniu konta użytkownika, zmieniłem jedną rzecz w opcjach zaawansowanych- włączyłem opcję „używaj serwera STUN„. Bez tej opcji miałem problemem z wykonywaniem połączeń. No i działa . Potem wystarczyło znaleźć niezabezpieczoną sieć np. w Maroku, albo taką o której ktoś myślał, że jest zabezpieczona i można było dzwonić do PL na stacjonarne za 5 groszy lub na  komórkę za 35 groszy .

Czasem bywały co prawda problemy z działaniem programu i podejrzewam, że było to związane ze STUN, bo zdarzało się że jedna ze stron nie słyszała drugiego rozmówcy, ale miało to miejsce na tyle rzadko, iż uznaję to rozwiązanie i tak za świetne. Hmmm, a tak naprawdę to świetny jest Android i Linux . Co do softu, to jak będę mieć więcej czasu, to może uda mi się znaleźć bardziej niezawodny. W każdym razie rozwiązanie Android vs. VOIP (SIP) to bez wątpienia totalna rewelacja w ograniczeniu płatności za telefon.