Nie wiem jak to wygląda w waszym przypadku ale ja całkiem często korzystam z połączeń SSH, wynika to z charakteru mojej pracy. Może się jednak okazać, że będziecie musieli takie połączenie nawiązać. Nic prostszego! W systemie OS X wystarczy do tego nasz wszechpotężny Terminal, po uruchomieniu którego będziemy mogli wykonać wymaganą czynność. Składnia wymagana do użycia tego protokołu w standardowej formule wygląda następująco:
ssh adres_hosta
Oczywiście możemy się posłużyć parametrami uściślającymi charakterystykę naszego połączenia. Nie widzę sensu przybliżania ich wszystkich, więc wybrałem te, których sam używam:
–p – parametr ten pozwala na zdefiniowanie niestandardowego portu za pomocą którego będziemy łączyli się ze zdalną maszyną. Domyślnie polecenie bez użycia tego parametru nawiązuje połączenie za pomocą portu 22.
–l – parametr ten pozwala na zdefiniowanie nazwy użytkownika, którego poświadczenia posłużą nam do zalogowania się. Domyślnie komenda ssh będzie nas logowała zgodnie z nazwą naszego użytkownika jakiej używamy lokalnie.
–i – parametr ten pozwala nam wskazać plik identyfikacji (klucz prywatny) z jakiego chcemy skorzystać do celów autentykacji w trakcie nawiązywania połączenia.
Przyjmijmy więc, że chcemy uzyskać połączenie z serwerem o adresie IP 192.168.1.105 gdzie protokół SSH są obsługiwany na porcie 66, zalogować się jako użytkownik root oraz dokonać poświadczenia przy użyciu klucza prywatnego o nazwie klucz.cert znajdującego się w lokalizacji ~/.ssh/id_rsa. Polecenie takie miałoby następującą formę:
Istnieje jeszcze inny – w mojej opinii wygodniejszy – sposób na podanie nazwy logującego się użytkownika, mianowicie wystarczy przed adresem hosta dodać wartość nazwa_użytkownika@. W tym przypadku polecenie będzie miało następującą postać:
Polecenie ping to jedna z najbardziej znanych i wykorzystywanych komend wśród użytkowników, nie wspominając o administratorach sieci dla których to często pierwszy krok w przypadku problemów. Użycie jej w systemie OS X nie różni się znacznie od tego jak wygląda to pod kontrolą systemów Windows. Przy standardowej składni ping adres_hosta jedyną odmianą jest liczba wykonywanych zapytań. Implementacja występująca w systemach Windows wysyła cztery pakiety, w przypadku OS X domyślnie pakiety wysyłane są bez przerwy aż do zakończenia działania komendy przy użyciu kombinacji klawiszy ctrl+c. Oczywiście możemy wykorzystać sporą liczbę parametrów precyzujących zachowanie tej komendy. Poniżej przedstawię te, które w mojej opinii mogą okazać się najbardziej przydatne.
Jak już wspomniałem najprostsza i najczęściej używana składnia polecenia ma postać:
ping adres_hosta
Oczywiście możemy ją wzbogacić o następujące parametry, które umieszczamy pomiędzy poleceniem a adresem hosta do którego zamierzamy wykonać pingowanie:
-c – parametr ten pozwala ustalić liczbę pakietów jakie zostaną wysłane przy użyciu polecenia ping
-t – w przypadku tego parametru możemy określić czas wykonywania polecenia podany w sekundach i niezależny od liczby wykonanych zapytań
-i – parametr ten pozwala nam ustalić interwał pomiędzy wysyłaniem kolejnych pakietów, domyślnie pakiety wysyłane są co sekundę. Warto pamiętać, że emisja częstsza niż co 0,1 sekundy jest dostępna jedynie dla użytkowników o podniesionym poziomie uprawnień. Dodatkowo dla wartości nie całkowitych stosujemy tutaj kropkę zamiast przecinka.
-o – parametr ten pozwala na zakończeniu pracy polecenia po otrzymaniu pierwszego właściwego pakietu zwrotnego.
-q – parametr ten pozwala na tak zwane ciche wykonanie, polega to na uruchomieniu komendy i otrzymaniu jedynie dwóch informacji: pierwszej o starcie wykonywania oraz drugiej, która zawiera wynik jej przeprowadzenia, nie są w tym przypadku wyświetlane poszczególne transmisje pakietów.
Czas wykorzystać wiedzę w praktyce. Przyjmijmy, że chcemy wykonać ping do hosta o adresie IP 10.13.0.1, gdzie zapytania będą wysyłane co 0,25 sekundy, liczba zapytań będzie wynosiła 25 i jednocześnie interesuje nas jedynie wynik wykonywania. W takim przypadku nasza komenda będzie miała następującą składnie:
ping -i 0.25 -c 25 -q 10.13.0.1
Wynik takiego polecenia będzie wyglądał następująco:
Zachęcam Was do testowania polecenia ping przy użyciu poszczególnych parametrów. Jeżeli wcześniej go nie używaliście, to gwarantuje Wam że w razie problemów z siecią pozwala wyeliminować kilka oczywistych kwestii.
Dzisiejszy wpis nie będzie – dla odmiany – ani o AirPlay ani o appkach dla iOS. Mimo, swojego wieloletniego doświadczenia z Maczkami oraz OS X, stosunkowo rzadko opisuję aplikacje bądź rozwiązania problemów na tej platformie. Jest to spowodowane m.in. tym, że:
nie mam właściwie jakichś większych problemów ani z komputerem ani systemem (odpukać!) – być może mój workflow jest tak zoptymalizowany lub tak prosty, że nie ma wielu sytuacji, które zmuszają mnie do większego wysiłku umysłowego i wgryzania się w temat,
wiele rzeczy, które robiłem wcześniej na iMacu, obecnie wykonuję na iUrządzeniach, a co za tym idzie – rzadziej korzystam z komputera,
bardzo często rozwiązanie problemu wydaje mi się na tyle banalne, że jestem (prawdopodobnie błędnie) przekonany, że wszyscy inni już sobie poradzili z tym dawno, albo temat jest trywialny i nie warto zaśmiecać bloga czymś tak oczywistym.
Tym razem jednak, “wdepnę” na teren, który do tej pory eksploatował mocno Kuba i opiszę wyjście z sytuacji, zasygnalizowanej przez znajomego zajmującego się zawodowo usługami w branży poligraficznej. Oczywiście rozwiązanie ma swoje wady, i właściwie to taka trochę partyzantka i prowizorka, ale – co istotne – koszt realizacji jest niewielki (nie napiszę, że zerowy, bo jakby nie patrzeć czas spędzony na instalacji, konfiguracji, weryfikacji, itp. też ma swoją cenę).
Aby nie przedłużać przedstawiam opis problemu: klient posiada nowego MacBooka z procesorem i5 oraz OS X 10.8.3. Ponadto stare maczki oraz legalne licencje oprogramowania przeznaczonego dla starszych komputerów z procesorami PowerPC (np. Freehand MX). I wiele prac w nich stworzonych. Chciałby, rzecz jasna, móc wykorzystać te programy i dokumenty na nowym MacBooku. Jednak jak się domyślacie, skok technologiczny oraz zmiany jakie zaszły przez tyle lat w software i w hardware, uniemożliwiają taką bezbolesną podróż z przeszłości do teraźniejszości. Sposobów na zmianę tego stanu rzeczy jest kilka:
aktualizacja posiadanego zaplecza programowego do nowszych/najnowszych wersji – dość kosztowny zabieg,
próba konwersji dokumentów do formatu “zjadliwego” przez inne, nowe (również darmowe) programy – duże prawdopodobieństwo, że jeśli w ogóle się to uda, to zawartość dokumentów nie będzie zachowana w 100% w identycznej postaci,
zakup używanego komputera, z systemem w wersji wspierającej kod przeznaczony dla procesorów PPC – rozwiązanie tańsze niż aktualizacja wszystkich programów, ale dość kontrowersyjne, w sytuacji gdy chwilę wcześniej nabyło się (niestety bez wcześniejszego rozeznania) nowego, ślicznego i szybkiego MacBooka…
uruchomienie systemu ze wsparciem dla PPC, na wcześniej wspomnianym komputerze oraz instalacja leciwego softu.
Jak się domyślacie, zdecydowałem się na karkołomną próbę realizacji tego ostatniego.
Wiedziałem, że istnieje możliwość wirtualizacji systemu Mac OS X. Bliższa weryfikacja potwierdziła, że praktycznie każde z istniejących rozwiązań, czyli Parallels Destop, VMware Fusion oraz Oracle VirtualBox potrafią stworzyć i obsłużyć maszynę wirtualną z systemem Mac OS X… w wersji Server (dokładnie wersje 10.5/10.6). Ostatnia wersja systemu dla Maców, która wspiera wykonywanie kodu PowerPC to 10.6 czyli Snow Leopard. Pomimo faktu, że samego systemu nie da się zainstalować na komputerze z takim procesorem, to instalowany dodatkowo komponent o historycznie uzasadnionej nazwie – Rosetta, pozwala systemowi uruchomionemu na maszynie z procesorem Intela na wykonanie kodu programu stworzonego dla platformy PPC.
Niestety system Mac OS X w wersji serwerowej jest zabezpieczony kluczem, i nie jest tak popularny i łatwo dostępny. Krótkie sprawdzenie podaży tej wersji systemu na najpopularniejszym portalu aukcyjnym tylko potwierdziło, że nie będzie łatwo. Owszem, teoretycznie mógłbym ściągnąć obraz płyty z sieci, ale co z licencją/numerem seryjnym?
Postanowiłem więc sprawdzić czy da radę zainstalować system w wersji desktopowej. A jako oprogramowanie do wirtualizacji wybrałem darmowego VirtualBoksa. Okazało się, że mam płytę z systemem Mac OS X 10.6 zakupioną jak tylko ów się pojawił (moje iMadło przyszło do mnie fabrycznie bodajże z 10.5.2).
Początki były dziecinnie proste – instalacja VB, tworzenie nowej maszyny wirtualnej przebiega właściwie bez jakichkolwiek zakłóceń i zaklęć, większość opcji można pozostawić w ustawieniu domyślnym. Ja poza wyborem systemu (typ: Mac OS X, wersja: 64 bity), zostawiłem sugerowany przydział pamięci RAM (2 GB), zalecaną przestrzeń dyskową i jej rodzaj (dynamicznie alokowany wirtualny dysk o pojemności do 20 GB, format VDI).
Następnie dokonałem modyfikacji pewnych bardziej zaawansowanych ustawień po kliknięciu Settings dla właśnie utworzonego profilu maszyny wirtualnej. Na karcie System odhaczyłem napęd dyskietek w sekcji Boot Order. Zwiększyłem również na karcie Display ilość pamięci dla VM do 64 MB oraz włączyłem akcelerację 3D (w sumie to nie mam przekonania, że akurat te opcje robią jakąś odczuwalną różnicę, ale skoro karta graficzna ma 256 MB VRAM i nie najgorsze GPU, to postanowiłem zaryzykować).
Na karcie Storage w sekcji Attributes wskazałem wcześniej zrzuconą do obrazu DMG, płytę z instalką systemu Snow Leopard (zrobiłem tak, ponieważ mój napęd optyczny jest kapryśny i hałasuje, skorzystałem więc z opisywanego wcześniej tu patentu płyty zdalnej – z wykorzystaniem czytnika w pececie).
Start maszyny, bootujemy z wirtualnego obrazu CD/DVD, pojawiają się napisy :P białe na czarnym i po chwili wszystko staje na takim etapie:
Aha, cytując klasyka: Huston mamy problem. Gdyby to był Mac OS X Server to pewnie bazowy system by ruszył i instalacja została zainicjowana. Ale mamy system w wersji desktop, więc musimy znaleźć sposób by oszukać VirtualBoksa. Przejrzenie ustawień nie wniosło wiele ale postanowiłem wyłączyć opcję Enable EFI (special OSes only).
W efekcie po restarcie VM powitało mnie tym razem poniższe okienko:
Ewidentnie trop był dobry, więc zacząłem przeglądać zasoby internetu w poszukiwaniu rozwiązania bądź podpowiedzi, która naprowadzi mnie na właściwą ścieżkę. Kilkadziesiąt minut wnikliwego surfowania przyniosło skutek. Okazało się, że najbardziej pomocne były nie strony i fora związane z wirtualizacją a te poświęcone… hackintoshom.
Faktycznie problem leży (upraszczając nieco temat) po stronie tzw. boot loadera i zanim dokona się instalacji systemu, należy wystartować VM z boot loadera w odpowiedniej wersji, tak by “oszukać” VirtualBoksa, że ma do czynienia z system we właściwym wydaniu. Okazało się, że istnieją dwa (o komercyjnie dystrybuowanym kiedyś Rebel EFI z Psystara pisać tu nie będę) takie alternatywne boot loadery w postaci obrazów .iso. Jeden to EasyEFI (wersja testowana przeze mnie to v.2.2 ver.3) a drugi The Empire EFI. Do gustu przypadł mi zdecydowanie pierwszy, mimo świetnego logo nawiązującego do Gwiezdnych Wojen, którym wita użytkownika The Empire EFI. Niestety, ale ten ostatni chyba dłużej startuje, poza tym oferuje domyślnie niższą rozdzielczość ekranu.
Należy wskazać alternatywny boot loader jako “płytę startową” (karta Storage), uruchomić VM, zaczekać chwilkę aż pojawi się poniższy ekran (EasyEFI):
a następnie wejść w menu VirtualBox -> Devices -> CD/DVD Devices -> Choose a virtual CD/DVD disk file… i wskazać obraz .dmg z instalką systemu. Wcisnąć klawisz funkcyjny F5, ikonka znajdująca się na środku ekranu powinna zmienić podpis z “EasyEFI” na “Mac OS X Install DVD”. Już tylko wciśnięcie klawisza Enter dzieli nas od rozpoczęcia procesu instalacji!
Po wybraniu języka głównego systemu nim rozpoczniemy właściwą instalację, musimy jeszcze sformatować plikopartycję, na której 10.6 ma być zainstalowany, bez tego instalator nie znajdzie dysku:
Jako, że system “gościa” ma służyć właściwie tylko jako launcher, środowisko pozwalające na uruchomienie starszych programów, odznaczyłem zbędne składniki, i zahaczyłem opcjonalny komponent, kluczowy w naszym zadaniu:
Teraz był test cierpliwości. Początkowe zakładane 19 minut przedłużyło się do około pół godziny, a zwieńczeniem całego procesu był poniższy komunikat:
Na szczęście okazuje się, że ten typ tak ma i podjęte czynności wcale nie zakończyły się niepowodzeniem. Niestety, wybranie przycisku Uruchom ponownie, nie restartuje poprawnie VM, w związku z czym należy dokonać tego wybierając opcję Reset w menu Machine VirtualBoksa. Co więcej, najprawdopodobniej powita nas znane już oko z komunikatem: “Fatal! No bootable medium found. System halted.”
Raz jeszcze musimy wskazać wirtualny plik .iso z alternatywnym boot loaderem nim wystartujemy VM “od zera”. W przypadku EasyEFI ujrzymy następujący ekran:
Wybranie ikonki jabłuszka i zatwierdzenie Enterem spowoduje uruchomienie zainstalowanego systemu. Działa nawet pod Mavericksem :) (10.9 DP4).
Właściwie można by uznać, że problem jest rozwiązany. Dla potwierdzenia ściągnąłem pod zwirtualizowanym Snow Leopardem program viJournal w wersji Universal i wymusiłem uruchomienie kodu PowerPC. Poniżej efekt:
No tak, ale wypadałoby jeszcze usprawnić komunikację między gospodarzem (host) i gościem (guest). Niestety z uwagi na brak oficjalnego wsparcia systemu Mac OS X w wersji desktop, nie ma dla niego zestawu “sterowników” zwanych VirtualBox Guest Additions. To oprogramowanie zapewnia m.in. działanie drag&drop, wspólny schowek (Shared Clipboard), udostępnione foldery (Shared Folders) i inne udogodnienia. Pierwsza myśl jaka mi przeszła przez głowę: użyję pendrive’a jako nośnika między oboma systemami! Fajnie, tylko… nie działa. Pendrive się nie montuje w systemie gościa, więc nie mamy dostępu do jego zawartości. Zapewne Guest Additions załatwiłyby ten problem rownież… Zonk.
Kolejna myśl: sieć lokalna. Oczywiście najpierw upewniłem się, że w obu systemach załączone jest Udostępnianie plików (Preferencje systemowe -> Udostępnianie), dodane katalogi i przyznane odpowiednie prawa użytkownikom. W dodatkowych opcjach na wszelki wypadek załączone zostało udostępniane przy użyciu obu protokołów, tj. AFP oraz SMB. Cóż… na wirtualnym 10.6 przeglądanie sieci nie wyświetla żadnych zasobów sieciowych, zaś próba podłączenia się do widocznego z poziomu gospodarza wirtualnego Snow Leoparda, zwraca komunikat błędu.
No tak, czyli mamy zwirtualizowany system, na który dane możemy wrzucić z fizycznej płyty CD/DVD, obrazu takowej w postaci pliku .dmg/.iso oraz ściągając je z Internetu! Chwila kontemplacji podbródka a chytry i przebiegły plan skrystalizował się w meandrach zwojów mózgowych. Przecież mogę zainstalować na obu systemach DropBoksa i w ten sposób, trochę na około, za pośrednictwem Internetu wymieniać dane między dyskami gospodarza i gościa. No tak, ale “na dzień dobry” DropBox to liche 2 GB za darmo…
Czas wrócić do sieci lokalnej. Sprawdzam adresy IP maszyny fizycznej i wirtualnej. Są inne :) I tak ma być! Ale przynależą również do innych podsieci. W takim razie wciskam Command+K wywołując polecenie Połącz z serwerem… z menu Idź Findera. Podaje adres maszyny wirtualnej i… błąd! Czas zobaczyć czy może w drugą stronę zadziała?
Jest dobrze, pada monit o nazwę użytkownika i hasło. Udało się! Mogę teraz spokojnie podmontować dowolny zasób iMaca (oraz również dysk z peceta) pod wirtualnym systemem:
Pozostaje jeszcze kwestia uruchamiania systemu. Na chwilę obecną każde ponowne uruchomienie VM wymaga sprawdzenia w ustawieniach Storage, czy obraz alternatywnego boot loadera jest wskazany jako wirtualny dysk CD/DVD; inaczej zainstalowany system się nie uruchomi. Lipa, żonglowanie podmontowanymi obrazami i/lub fizycznymi dyskami CD/DVD z napędu hosta, to mało atrakcyjne zajęcie. Na szczęście na dysku EasyEFI.iso znajdziemy pakiet Chameleon:
Instalacja tegoż, powoduje wgranie bootloadera oraz rozszerzeń systemowych (kext) do naszego zwirtualizowanego Snow Leoparda.
Na koniec procesu uruchamia się Terminal, w którym należy podać hasło oraz program Kext Utility, którego zadaniem jest naprawa przywilejów modułów. U mnie aktywność instalatora zaowocowała zgłoszeniem błędów z instalacją kilku rozszerzeń, zaś Kext Utility zakończyło pracę z radosnym kelnerem panikarzem (ale tylko za pierwszym razem) ;) Dzięki bogom wszelakim, VM uruchamia się i póki co nie zauważyłem by stabilność systemu została w jakikolwiek sposób zachwiana. Nie da się jednak ukryć, że dobór rozszerzeń wymaga rozwagi i… odwagi. Tak czy inaczej, dzięki „kameleonowi”, 10.6 wstaje o wlasnych siłach, bez pośrednictwa EasyEFI w wirtualnym napędzie!!!
Reasumując: mamy działający system 10.6 z dostępem do Internetu oraz zasobów sieci lokalnej, zdolny do egzekucji programów pisanych na procesory PowerPC. Pełen sukces? W zasadzie tak, są jednak drobne “ale”:
jeśli chcemy skorzystać z fizycznej płyty w napędzie komputera musimy z menu VirtualBox (Devices -> CD/DVD Devices) wybrać opcję Host Drive ‘nazwa napędu’, niestety nie działa nagrywarka pod VM, zatem napęd optyczny tylko do odczytu (być może da się to zmienić, ja temat odpuściłem),
zdaża się, że nie działa poprawne zamykanie systemu 10.6, po wybraniu tej opcji i tak trzeba ręcznie wyłączyć VM, najlepiej klikając przycisk zamknięcia okna i wybierając opcję: Power off the machine,
restartowanie zdaje się działać od czasu do czasu również wybiórczo – jeśli “zamieszamy” zbytnio, niektóre procesy systemowe mogą przestać funkcjonować poprawnie; w takim wypadku postępujemy jak w przypadku zamykania, można ew. wykonać jeszcze Reset z menu Machine VirtualBoksa,
gdy pod wirtualnym 10.6 zechcemy wybrać opcję Ten Mac… z menu Jabłko – Finder się restartuje,
zamiast wyłączania VM możemy ją zahibernować, klikając przycisk zamknięcia okna i wybierając opcję: Save the machine state, jednak zdarza się, że po przywróceniu maszyny, występują sporadyczne kłopoty z siecią lokalną,
nie działa drag&drop, wspólny schowek, współdzielone foldery, obsługa USB i wiele innych rzeczy,
nie polecam aktualizacji zwirtualizowanego Snow Leoparda do najnowszej wersji (10.6.8) – przynajmniej bez zrobienia kopii zapasowej dysku wirtualnego,
last but not least: nie można wybrać z poziomu VM innej niż domyślna rozdzielczości ekranu; jak wcześniej wspomniałem dla The Empire EFI jest to 1024 x 768, zaś dla EasyEFI 1280 x 1024; oczywiście w sieci można znaleźć kilka różnych przepisów, jak tę sytuację zmienić, niestety u mnie udało się – próbując wymusić rozdzielczość 1440 x 900 x 32 – osiągnąć w trybie okienkowym tylko 1152 x 864…; mimo zmian ustawień panelu preferencji Chameleon, nie udało mi się uruchomić na pełnym ekranie VM w natywnej rozdzielczości mojego iMaca, tj. 1680 x 1050. W trybie okienkowym dobrym wyjściem jest też korzystanie z opcji Switch to Scale Mode znajdującej się w menu View VirtualBoksa, aczkolwiek zdaje się ona zniekształcać proporcje ekranu (wysokość zwiększona w stosunku do szerokości).
Nie jestem pewien czy czegoś nie pominąłem, jeśli podany wyżej przepis Wam nie zadziała, lub znacie/znajdziecie sposoby na wyeliminowanie opisanych ograniczeń – będę wdzięczny za wszelkie pytania, sugestie i wskazówki.
Spotify to serwis, który w głównej mierze w swoim działaniu wykorzystuje streaming danych. Jednak dla zapewnienia maksymalnej wygody i szybkości działania przechowuje on na dyskach naszych komputerów cache zawierający ostatnio jak i najczęściej odtwarzane utwory. Zapewnia to oszczędność pasma zarówno dla nas jako użytkowników jak i serwerów, które dystrybuują dane. Domyślnie wielkość takiego katalogu jest ograniczona do 10% pojemności naszego dysku twardego. Ja osobiście nie przepadam za sytuacjami kiedy jakiejkolwiek maści dane tymczasowe okupują cenne megabajty mojego dysku SSD więc staram się takie pliki systematycznie usuwać. Podobny zabieg dla iOS opisywał na łamach Applesauce mantis30 w jednym ze swoich artykułów. Poniżej recepta na usuwanie plików tymczasowych Spotify w OS X.
Jeżeli również macie taką potrzebę, to wejdźcie w Preferencje Spotify i w zakładce Pamięć podręczna skopiujcie podaną tam ścieżkę. W tym miejscu możecie też zmienić domyślną wartość dopuszczalnej wielkości katalogu tymczasowego.
Następnie uruchomcie nowe okno Findera i użyjcie kombinacji klawiszy Shift+cmd+G, która pozwoli wam wkleić ścieżkę do katalogu i po kliknięciu Idź otworzy podaną lokalizację. Teraz nic nie szkodzi na przeszkodzie aby usunąć wszystkie widoczne katalogi. W moim przypadku było to blisko 2,5 GB danych. Zdecydowanie polecam ten zabieg dla „oszczędnych”.
Jakiś czas temu stanąłem przed koniecznością zaopatrzenia się w adapter Mini DisplayPort pozwalający podłączyć się do zewnętrznego monitora lub projektora. Ceny takiej przejściówki są różne w zależności od producenta jednak nie łudźcie się, jaka kwota taka jakość i nie obyło się bez wydania odrobiny większej ilości złotówek chociaż i tak parę groszy zostało w kieszeni. Zanim postanowiłem dokonać zamówienia naszła mnie cwaniacka myśl aby obejść ograniczenie do jednego rodzaju złącza i zakupić taką, która zakończona jest wyjściem DVI i w razie potrzeby posiłkować się przejściówką do VGA. Ostatecznie w komputerach stacjonarnych takie rozwiązanie to codzienność. Jeżeli macie podobną do mnie koncepcje, to możecie podarować ją sobie już na starcie. Dlaczego? Już śpieszę z wyjaśnieniem.
Złącza DVI występują w trzech odmianach DVI-I, DVI-D oraz DVI-A. To które stosowane jest w adapterach przeznaczonych dla Maczków to DVI-D i tutaj pojawia się kwintesencja naszego problemu. Poniżej możecie zobaczyć jak wyglądają różnice w konstrukcji poszczególnych rodzajów złącz.
Ten typ złącza pozbawiony jest pinów odpowiedzialnych za przesyłanie sygnału analogowego. Zapytacie pewnie – tak jak i ja – dlaczego więc nie znaleźć takiego adaptera, który posiada owe piny czyli konkretnie zakończonego typem DVI-I. Wynika to z prostego faktu, Mini DisplayPort nie pozwala na jednoczesne wysyłanie sygnału analogowego i cyfrowego. Oczywiście występują na rynku urządzenia typu dual display, które rozwiązują tę niedogodność jednak ich cena nie należy do najbardziej atrakcyjnych. Niestety musimy pogodzić się z tym ograniczeniem i pozostaje nam wybór jednej z dwóch dostępnych opcji: VGA lub DVI.
Ja osobiście zaopatrzyłem się w wersję zakończoną złączem VGA. Powód był prosty, większość urządzeń jakie miałem zamiar podłączać pozwalało na takie właśnie rozwiązania a niestety DVI ograniczyłoby mnie w dwóch przypadkach. Nie będę ukrywał, że trochę szkoda mi cyfrowego sygnału, jednak nie mogę narzekać na jakość jaką zapewnia mi mój zakup. Myślę, że to dobre miejsce aby polecić wam mój wybór, a mianowicie adapter iAdapt firmy Kanex.
Jakość jego wykonania nie budzi najmniejszych zastrzeżeń a obudowa stylizowana na aluminium idealnie komponuje się z MacBookiem. Co najprzyjemniejsze, kupując go zaoszczędzicie kilkadziesiąt złotych w porównaniu z oryginalnym akcesorium od Apple. Polecam, zwłaszcza że występuje on również w wersji DVI.
Po pobraniu plików za pomocą Safari, są one domyślnie otwierane w katalogu Pobrane Rzeczy. Dla przykładu, w mojej pracy często zdarza się, że pobieram pakiety .zip, które potrzebuję dokładnie w takiej formie w jakiej ściągnąłem je z sieci. Najczęściej są to paczki aktualizacji dla modułów serwerowych i tym podobnych szkaradztw. Jednak dobroduszny mechanizm bez pytania rozpakowuje takie archiwum usuwając jednocześnie oryginalną paczkę z danymi. Podobnie zachowuje się w przypadku plików PDF, dźwiękowych, video oraz plików tekstowych – tutaj oczywiście ich nie usuwa. Jeżeli tak jak mi nie odpowiada Wam takie działania to wystarczy wejść w Preferencje Safari i odznaczyć opcję Otwieraj „bezpieczne” pliki po pobraniu.
Zdaję sobie sprawę, że jest to banalna porada, jednak ja osobiście przyznaję bez bicia, że podejrzewałem o takie zachowanie Finder. Okazało się, że to mechanizm Safari. Teraz przynajmniej nie musicie się zastanawiać.
Nie tak dawno opisywałem na łamach applesauce swoje boje z klimatyzatorem. Jedną z kwestii, która mnie pozytywnie zaskoczyła, było to, że dzięki dedykowanej aplikacji oraz posiadaniu konta w serwisie producenta, mogę zdalnie urządzenie wyłączać – a co ważniejsze – również je włączać. Postanowiłem sprawdzić, jak wygląda sprawa uruchamiania, bądź wybudzania komputerów, na odległość. I temu właśnie tematowi poświęcam niniejszy wpis.
Na samym początku zdradzę, że finalne efekty są dość zdywersyfikowane i zależą od wielu czynników, które nie omieszkam się opisać. Temat potraktowałem raczej ambicjonalnie, ponieważ jak dotąd udawało mi się funkcjonować bez takich udogodnień, ale jak wiadomo, apetyt rośnie w miarę konsumpcji, a z oczekiwaniami dotyczącymi wygody, jest identycznie :)
Większość z Was, drodzy czytelnicy jeśli nie miała do czynienia, to słyszała pojęcie: WOL – Wake On LAN, czyli wybudzanie po sieci lokalnej. Oczywiście określenie to, używane jest obecnie także do opisania innych metod, ale po kolei. Załóżmy, że mamy komputer i chcemy go zdalnie obudzić, w takiej sytuacji pojawiają się następujące problemy do rozwiązania:
platforma: Mac / PC
sposób podłączenia do sieci: Ethernet / WiFi
dostęp do sieci, lokalnie lub z Internetu: LAN / WAN
stan komputera: uśpiony / wyłączony
Z powyższymi wiążą się kolejne komplikacje. Spędziłem kilka długich dni na testach i poszukiwaniach, a sprawę utrudniały dość często sprzeczne informacje, dostępne u wielu źródeł.
Całą tajemnicę budzenia na odległość, można uprościć do dwóch, koniecznych warunków:
z urządzenia nadawczego (komputera/smartfona/tabletu/itp.) wysyłamy specjalnie spreparowane dane, zwane Magic Packet,
odbiorca pakietu musi mieć aktywny interfejs sieciowy, bym móc ten magiczny pakiet przyjąć.
Rzecz jasna, „od kuchni” jest to znacznie bardziej skomplikowanie…
STAN KOMPUTERA
Niezależnie od tego, czy komputer jest uśpiony czy wyłączony, by zagwarantować odbiór magicznego pakietu, karta sieciowa komputera MUSI być zasilana. Wyłączony interfejs oznacza komputer odłączony od sieci.
Sytuacja I – Komputer uśpiony
Sprawdzamy odpowiednie preferencje systemowe. Dla OS X weryfikujemy, czy „zaptaszkowana” jest opcja Budź przy dostępie przez sieć, którą znajdziemy w kategorii Oszczędzanie energii.
Pod Windowsem natomiast, musimy sprawdzić właściwości karty sieciowej, w dwóch miejscach:
Zarządzanie energią (tu warto zaznaczyć wszystkie opcje, lub ew. pominąć pierwszą, związaną z oszczędzaniem energii)
Zaawansowane (tutaj warto dla każdej właściwości związanej z budzeniem, przełączyć wartość na Włączone)
Może się okazać, że mamy pecha i akurat nasz sprzęt nie posiada interfejsów sieciowych wspierających Wake On LAN… Kolejna sprawa to notebooki i laptopy – może się okazać, że aby wybudzić uśpiony taki komputer, musi być on podłączony do prądu, inaczej mówiąc zasilany z sieci energetycznej, a nie oczekujący na zasilaniu bateryjnym. Z drugiej strony, komputer przenośny częściej mamy pod ręką, zatem zapewne rzadziej zachodzi potrzeba zdalnego wybudzenia.
Sytuacja II – Komputer wyłączony
Tutaj niestety muszę zmartwić wszystkich użytkowników jabłuszek – na chwilę obecną nie ma możliwości zdalnego zastartowania wyłączonego Maczka :/ Trudno powiedzieć, co odpowiada za taki stan rzeczy, czy „Think Different”, czy wyjście z założenia, że macuserzy nie wyłączają swoich komputerów, tylko je usypiają? Nawet jeśli OS X jest stabilny jak skała, to jednak wyjeżdżając na dwutygodniowe wakacje, zostawiać go uśpionego (zwłaszcza, gdy brak UPSa) nie będziemy. A los bywa tak perfidny i dowcipny, że akurat w tym właśnie czasie, możemy potrzebować dostępu do istotnych plików…
Tak czy inaczej, jedyne wyjście na to by Mac dał się obudzić (i dotyczy to zarówno budzenia w sieci lokalnej jak i przez Internet), to przełączyć w tryb sleep. W tym stanie podtrzymywana jest pamięć, karty sieciowe i inne niezbędne komponenty. Nie wiem, z jakim poborem mocy należy się w takiej sytuacji liczyć, będzie to zdecydowanie więcej niż gdyby komputer był wyłączony (no, nie całkowicie). Z drugiej strony możemy śmiało założyć, że z uwagi na przyjazność środowisku, produkty Apple, nie są aż tak łakomymi pożeraczami energii.
Z pecetem jest tu nieco lepiej, ale za pełen sukces odpowiada „szczęście egzemplarza”. To od możliwości płyty głównej oraz dostępnych ustawień w BIOSie/EFI zależy czy nasz komputer włączymy zdalnie czy nie. Pecet w moim domu, bazuje na starej już płycie głównej Asus P8P67LE, ze zintegrowanym Gigabit Ethernetem firmy Realtek (PCIe). W BIOSie, w trybie zaawansowanym, w menu Advanced i kategorii zwanej APM załączyłem „Power On By PCIE”. Tak po prawdzie, z lenistwa, to załączyłem prawie wszystkie dostępne tam opcje Power On :)
Bardzo często przy złączu RJ-45, na tylnym panelu, znajduje się dioda sygnalizująca pracę karty sieciowej, jeśli się świeci przy wyłączonym komputerze, to oznacza, że ten interfejs jest podtrzymywany, a Magic Pocket powinien uruchomić urządzenie.
PODŁĄCZENIE DO SIECI
Według praktycznie wszystkich źródeł, komputer, który chcemy wybudzić zdalnie, powinien być podłączony do sieci po kablu. Informacje takie, znajdziemy również w appkach dla iPhone, które potrafią wysłać magiczny pakiet (opiszę je nieco dalej). Śmiem twierdzić, że nie jest to stuprocentowa prawda, i zależy to od konkretnego modelu komputera, płyty głównej, bezprzewodowej karty sieciowej, oraz systemowego wparcia. Mój stacjonarny pecet nie posiada karty WiFi, ale sprawdziłem możliwość wybudzenia bezprzewodowego w służbowym laptopie (Asus K52JC), niestety próby zakończyły się całkowitym niepowodzeniem.
Okazuje się, że – dla odmiany – z komputerami Apple jest tu lepiej. Firma, jak ma w zwyczaju, wdrożyła własną implementację WOL zwaną WOD – Wake On Demand. Nie będę tu przepisywać specyfikacji, streszczę tylko wyjaśniając, że funkcja ta działa oczywiście tylko z uśpionymi komputerami, oraz wykorzystuje technologię Bonjour a dokładnie usługę Bonjour Sleep Proxy, oraz działa również z kartami bezprzewodowymi AirPort! Czy nasz komputer posiadający taką kartę WiFi obsługuje WOD, należy sprawdzić w aplikacji Informacje o systemie (dawniej Profil systemu).
O dziwo mój stary iMac wspiera Wake On Demand i przewodowo i bezprzewodowo.
BUDZENIE W SIECI LOKALNEJ
To przysłowiowa bułka z masłem, o ile nasze komputery spełniają wyżej opisane warunki. Potrzebujemy jedynie „prowodyra”, czyli urządzenia które wyśle Magic Packet. Ja oczywiście od samego początku myślałem o iPhone, urządzeniu, które mam praktycznie 99% czasu przy sobie, jako inicjatorze pobudki pozostałych gratów. W tym celu przeprowadziłem szybkie poszukiwania odpowiedniej aplikacji. App Store „wypluł” pokaźną listę, którą zgrubnie odfiltrowałem, zostawiając na polu bitwy tylko darmowe appki. Poniżej przedstawię dwie, moim zdaniem najlepsze.
NetAwake – program autorstwa Power of Two Software to, szybkie proste i estetyczne i estetyczne rozwiązanie WOL. Przewagą NetAwake nad innymi programami jest to, że wykorzystuje Bonjour, do wyszukiwania możliwych do wybudzenia maszyn w sieci.
Inaczej mówiąc, jesteśmy zwolnieni z odnajdywania i wpisywania fizycznych adresów interfejsów, tzw. adresów MAC, które to stanowią kluczową informację determinującą odbiorcę magicznego pakietu.
W przypadku innych platform trzeba ręcznie dodać wpis zawierający nazwę i MAC adres. Myślałem, że instalacja tego, rozwiąże sprawę, jednak NetAwake nie chce, z automatu, mojego peceta zobaczyć…
Chyba jedyną wadą NetAwake jest fakt, że nie ma możliwości podania adresu IP, co przy budzeniu z sieci zewnętrznej (WAN) jest elementem niezbędnym.
Ograniczenia tego, nie ma druga z polecanych przeze mnie appek.
Mocha WOL – to produkt MochaSoft znanego z wielu innych programów wspierających zabawy w sieci.
Nie jest może idealny, ale posiada wystarczające możliwości konfiguracyjne i jest również darmowy.
Pozwala również na zmianę domyślnego (9) portu usługi!
Gdy mamy już ściągniętą i zainstalowaną taką aplikację na iPhone, dodaliśmy komputery, są uśpione (lub wyłączone, w przypadku PC wspierającego Power On…), możemy śmiało rozpocząć pobudkę na odległość!
To zdecydowanie najtrudniejsza w realizacji sprawa, właściwie to możliwa do osiągnięcia w bardzo specyficznych warunkach.
Na pierwszy rzut oka, wygląda na to, że jedynym problemem jest dostarczyć pakiet z sieci rozległej WAN do lokalnej LAN. Ale to zaledwie początek góry lodowej…
Po pierwsze musimy uświadomić sobie, że nasza sieć lokalna, jest widoczna w Internecie pod publicznym adresem IP, przypisywanym naszemu modemowi, przez dostawcę usługi (ISP). Problem w tym, że większość popularnych usług (Neostrada, Net24, itp.) przypisuje ten adres dynamicznie, czyli zmienia się on co jakiś czas, a zmiana ta może być inicjowana przez operatora, bądź wynikać np. z restartu modemu (po zmianie ustawień lub przerwie w zasilaniu). Gdy adres się zmieni, to go nie znamy, więc trudno z zewnątrz dostać się do swojej sieci.
Najlepszym rozwiązaniem jest posiadanie stałego publicznego (zewnętrznego) adresu IP. Niektórzy operatorzy (np. w sieciach kablowych) oferują taką możliwość za dodatkową opłatą, u innych wiąże się to ze zmianą „taryfy”, z indywidualnej na firmową.
Alternatywnym rozwiązaniem są serwisy DDNS, jak no-ip.com czy dyn.com które pozwalają na rejestrację domeny powiązanej ze zmiennym publicznym adresem naszej sieci. Niestety, aby móc aktualizować to przypisanie, musimy:
„poświęcić” jeden z komputerów w naszej sieci lokalnej, zainstalować na nim oprogramowanie klienckie, które po każdej zmianie adresu IP wyśle notyfikacje to naszego konta w serwisie DDNS, lub
posiadać router wspierający usługę Dynamic Domain Name System, a urządzenie włączone 24 godziny na dobę, samo będzie wysyłać aktualizacje do serwisu.
Niestety, Time Capsule nie wspiera DDNS w taki sposób, by możliwe było skorzystanie w wyżej wymienionych serwisów.
Próbowałem zgłębić temat iCloud i usługi Zdalnie na moim Macu (Back To My Mac), bo przecież tą drogą aktualizacje zmian adresu IP również się dokonują. Jednak, jak się okazało, Apple korzysta tu z protokołu i adresacji IPv6, co sprawę komplikuje na tyle, że się w końcu poddałem.
Gdy się uporamy ze zmiennym publicznym adresem IP, będziemy musieli się zmierzyć z kolejnym problemem – przekierowanie portu, na którym działa usługa WOL (domyślnie 9, ale często też wykorzystywany jest port o numerze 7). Znów, wygląda to trywialnie i właściwie w przypadku znakomitej większości routerów, to prosta sprawa. Sęk w tym, że przekierowanie powinniśmy ustawić na tzw. adres rozgłoszeniowy (ang. broadcast address) naszej sieci lokalnej! Dlaczego? Ano dlatego, że interfejsy sieciowe, nawet jeśli są podtrzymywane „przy życiu”, to gdy komputery są uśpione bądź wyłączone, nie mają przypisanych prywatnych adresów IP. Dlatego magiczny pakiet wysyłany musi być do wszystkich potencjalnych odbiorców, czyli po całej puli adresowej sieci lokalnej. Lecz tylko odbiorca, posiadający właściwy adres MAC, przesyłkę odbierze i zinterpretuje.
Tu pojawia się kolejna wada Time Capsule – nie pozwala na przekierowanie portu na adres rozgłoszeniowy (np. 192.168.1.255).
Próbowałem partyzantki, tj. ręcznej edycji pliku konfiguracyjnego TC, bez skutku. Utworzyłem podsieć, czyli ograniczyłem o połowę pulę DHCP, zmieniłem maskę podsieci na 255.255.255.128, tak by broadcast był pod adresem 192.168.1.127 – to również nie zadziałało.
Przeprowadziłem też zabawę z przypisywaniem adresów statycznych komputerom, i utworzyłem przekierowania portów dla tych konkretnych IP.
I… nawet to poskutkowało, ale tylko przez kilka minut po uśpieniu/wyłączeniu komputerów. Dokładnie trwało to tyle czasu, ile funkcjonowały wpisy w tablicy ARP routera. Wpisy tworzone są dynamicznie i przechowywane w pamięci podręcznej, oraz usuwane/odświeżane po upłynięciu tzw. czasu życia odwzorowania.
No to mamy trzecią już wadę Time Capsule – brak możliwości utworzenia statycznych odwzorowań w tablicy ARP.
No to by było chyba na tyle :) Jeśli macie jakieś pytania, lub własne doświadczenia, podzielcie się nimi w komentarzach. Mam nadzieję, że to mini-kompendium, zebrane w jednym artykule, mimo że dotyczy konfiguracji mojego „parku maszynowego”, pomoże zainteresowanym, w rozwiązaniu podobnych problemów.
Ja, chcąc nie chcąc, muszę zakceptować niedoskonałości TC i zrezygnować z budzenia komputerów przez Internet. Bardziej mnie jednak irytuje fakt, że wciąż nie wiem, jak rozwiązali ten problem magicy z Samsunga…
Zapraszam Cię do innych ciekawych wpisów dotyczących sieci, które ukazały się na applesaue.pl:
VideoLAN Client (VLC) Media Player to według mnie, jeden z najlepszych odtwarzaczy multimedialnych dostępnych na wiele platform. Nigdy nie grzeszył bajeranckim wyglądem. Ani prostotą obsługi (jeśli oczywiście użytkownik miał większe potrzeby niż: odtwarzanie, pauza/zatrzymanie, przyspieszenie/spowolnienie czy wybranie pliku/napędu). Ale w przeciwieństwie do wielu innych playerów, radzi sobie ze znakomitą większością formatów kompresji audio/wideo. Za darmo. I nie trzeba doinstalowywać jakichś dziwnych pakietów kodeków niewiadomego pochodzenia!
Okazuje się jednak, że wersja dla OS X, nie radzi sobie zbyt dobrze w sytuacji, gdy odtwarzamy plik wideo na komputerze, a jednocześnie przekierowujemy dźwięk np. na bezprzewodowe głośniki. Problem polega na opóźnieniu odtwarzania ścieżki audio w stosunku do obrazu. Nie wnikam tu w szczegóły, bo sam odtwarzam filmy na Apple TV, dzięki Air Video. Tak więc trudno mi napisać, czy problem dotyczy każdego rozwiązania pozwalającego na streamowanie audio po AirPlay (systemowe, Airfoil, Air Parrot, itp.).
Klawiatura jakiej używa się do obsługi komputera Mac nie posiada klawiszy typowo Windowsowych typu Page Up, Page Down, Delete oraz Print Screen, który jest bohaterem niniejszej porady. Mając zainstalowany na swojej maszynie za pomocą BootCamp system Windows oczywiście istnieje możliwość robienia zrzutów ekranu pomimo fizycznego braku klawisza. Nie potrzeba również do tego dodatkowego oprogramowania. Wymaga to jedynie znajomości dwóch skrótów klawiaturowych. Wyglądają one następująco:
fn+shift+F11 – powoduje zapisanie zrzutu całego wyświetlanego ekranu do schowka systemowego
fn+shift+alt+F11 – powoduje zapisanie zrzutu ekranowego aktualnie aktywnego okna do systemowego schowka
Jedną z funkcji dostępnych dla w miarę nowych komputerów Apple z systemem OS X w wersji 10.7 i wyższej jest AirDrop. Tak się składa, że mój iMaczek oficjalnie nie wspiera tego rozwiązania, ale istnieje pewien trick, który pozwala aktywować AirDrop na starszych komputerach, choć już tylko w sieci Ethernet (do działania w sieci bezprzewodowej wymagana jest nowsza karta WiFi wspierająca tzw. protokół PAN). Wystarczy wkleić poniższe wyrażenie w wierszu poleceń terminala:
Szczegóły bardzo dobrze opisał MacWyznawca, więc nie będę tu niczego powielać :)
AirDrop to nie jedyna możliwość wygodnego przesyłania plików w sieci lokalnej. Właściwie, to gdy mamy odpowiednio skonfigurowane konta użytkowników i opcje udostępniania, to przesyłanie plików nie jest (na ogół) problematyczne. Tylko właśnie, trzeba najpierw wszystko odpowiednio poustawiać, a do tego potrzeba chęci, czasu i uprawnień. Więc często warto poszukać innego, prostszego rozwiązania. I bardziej intuicyjnego, dla mniej rozgarniętych userów ;)
Muszę tu przy okazji wspomnieć o genialnej aplikacji Teleport, opisywanej na blogu jakiś czas temu, która również pozwala na intuicyjne i sprawne kopiowanie plików między wieloma Maczkami.
Zarówno AirDrop jak i Teleport mają jednak jedną, ale dość irytującą wadę – występują tylko na platformie OS X. Czyli w sytuacji jaką mam w domu ja (a myślę, że również całkiem znaczna grupa czytelników), by przesłać pliki między Maczkiem i pecetem, muszę korzystać z rozwiązania systemowego lub…
…użyć Filedrop
Ta darmowa (jak dotąd) aplikacja dostępna zarówno na Windowsa jak i OS X pozwala wygodnie przesyłać pliki między komputerami z wykorzystaniem drag&drop. Po instalacji aplikacji należy ją uruchomić (nie działa jako usługa systemowa niestety) na każdej maszynie. Najpierw pojawi się okno oczekujące na uruchomienie Filedrop na innym komputerze w sieci, a później przedstawiające miniaturkę zdalnego pulpitu.
Teraz wystarczy przeciągnąć na ten mikropulpit plik lub folder, a w oknie zaczną latać świetliki oczekujące akceptacji przyjęcia „ładunku” po drugiej stronie.
Gdy odbiorca się zgodzi to następuje transfer, który niestety trwa znacznie (4-5 razy) dłużej niż gdy robimy to klasycznym sposobem.
Dane lądują domyślnie w folderach Downloads/Pobrane – ale nic nie stoi na przeszkodzie by zmienić ścieżkę miejsca docelowego.
Niestety nie ma róży bez kolców a dymu bez ognia. Aplikacja musi być cały czas uruchomiona, a przypadkowe zamknięcie okna nie jest czynem, którego łatwo się wystrzec. Wydaje mi się również, za jej powolność odpowiada korzystanie ze środowiska Adobe AIR…
Mimo to, warto dać temu rozwiązaniu szansę, tym bardziej, że autor obiecuje również wersje dla urządzeń pracujących pod systemami iOS oraz Android. Dodatkowo mają pozwalać na wykorzystanie tychże jako bezprzewodowe pendrive’y, oraz umożliwić streaming zdjęć, a nawet muzyki z takich smartfonów/tabletów!
Ciekaw jestem, czy appki na urządzenia mobilne też będą darmowe…?
Ja jestem gorącym zwolennikiem rozwiązań bezprzewodowych a do tego multiplatformowych, więc będę śledzić rozwój Filedrop, do czego Was również zachęcam.
