Home » pracownia

Archiwa

    pracownia

    klawiaturki.blogspot.com

    EPOPTES

    • Na komputerze nauczyciela instalujemy: sudo apt-get install epoptes
    • Na komputerach uczniów: apt-get install epoptes-client
    • Na komputerze nauczyciela dodaj nazwę swojego użytkownika do grupy epoptes komendą gpasswd -a username epoptes Umożliwia to prawo do otwierania programu epoptes. Musisz się wylogować i ponownie zalogować, aby uzyskać dostęp
    • Na swoim routerze ustaw stałe IP dla komputera nauczycielskiego
    • Na komputerach klientów w pliku /etc/hosts dodaj linię opisującą ip komputera nauczycielskiego: NAZWAHOSTA ADRES_IP (np.: Serwer 10.0.0.2)
    • Na komputerze klientów w pliku: /etc/default/epoptes-client dodać lub odkomentować linę SERVER=NAZWAHOSTA_KOMPUTERA_NAUCZYCIELA
    • Na komputerach klientów wywołaj polecenie pobierające certyfikat  ssl  z  serwera  poleceniem: sudo epoptes-client -c

    Ansible – proste i wygodne narzędzie do automatyzacji zarządzania komputerami

    Podejść do tematu zdalnego zarządzania komputerami miałem już kilka. Mając powierzone sobie komputery czy to w salach lekcyjnych czy też w pracowni jakoś nie bardzo chce mi się biegać od komputera do komputera. Stąd poszukiwania jakiegoś wytrychu, którym można by sobie ułatwić życie. Dla pracowni napisałem nawet mały program do zarządzania update’mi i upgrade’ami systemów (w oparciu o Qt4). Pisanie od nowa takiego oprogramowania to jednak dużo pracy i efekt mały w stosunku do włożonego wysiłku. Stąd pomysł, aby wykorzystać coś gotowego. Znanym i szeroko stosowanym narzędziem jest Puppet. Jednak nie podoba mi się pomysł stosowania ciężkiego klienta na komputerach, które ledwo radzą sobie z zainstalowanym już użytkowym oprogramowaniem. Bliżej za to zainteresowałem się CFEnginem. Wydaje mi się lepszym rozwiązaniem niż Puppet. Napisany w C, zarówno klient jak i serwer nie wymaga dużej ilości zasobów, szczególnie po stronie klienta. Niestety ma on spory minus w postaci dość skomplikowanego języka zapisu oczekiwanego stanu zarządzanych komputerów. Nie jest to problem dla kogoś kto chce się zajmować tym na co dzień. Jednak jeśli chcemy zarządzać komputerami od czasu do czasu to wysoki próg wejścia jest dość odstraszający. Istnieje ciekawy projekt Rudder napisany w Scali, który umożliwia zarządzanie CFEnginem za pomocą przeglądarki. Jednak jak dla mnie to rozwiązanie jest za ciężkie. Na szczęście na horyzoncie pojawił się Ansible.
    Ansible jest dość wyjątkowy jak na narzędzie typu “provisionig” ze względu na to, że nie używa dedykowanego programu klienta i wszystkie operacje wykonywane są na klientach za pomocą połączenia ssh. Wystarczy więc zainstalować na zarządzanych komputerach ssh serwer (na serwerach www zazwyczaj już jest) oraz dodać klucz ssh zarządzającego komputera (w pliku ~/.ssh/authorized_keys) . Na komputerze z którego chcemy prowadzić kontrolę instalujemy Ansible i możemy zacząć pracę (może to być inny serwer lub nasz laptop). Sposób działania Ansible dla jednych będzie wadą, a dla innych zaletą. Wykonując zadania widzimy od razu efekty i wiemy czy zaplanowane działania powiodły się czy też nie. W CFEngine piszemy plik “promises” i przy najbliższym połączeniu klient pobiera go i stara się osiągnąć stan zapisany w pliku. Jeśli chcemy uzyskać informacje czy udało się uzyskać to co chcieliśmy to musimy dopisać kod odpowiedzialny za pobranie raportów. Ansible wydaje się więc wygodniejsze do zarządzania serwerami szczególnie gdy nie jest ich bardzo dużo (chociaż radzi sobie również gdy jest ich sporo). Niestety nie obsługuje na razie komputerów z Windows.
    Zarządzanie nie wymaga wiele nauki. Istnieją dwa tryby pracy. Pierwszy to pojedyncze polecenia, przykładowo: ansible all -m ping – pingowanie klientów. Pierwszy parametr all oznacza wybór wszystkich grup hostów zdefiniowanych w pliku /etc/ansible/hosts. Można też osobno odwoływać się do grup lub pojedynczych serwerów (po ip lub domenie).
    ansible all -a “jakieś polecenie bash” –user=administrator -K – uruchomienie polecenia powłoki jako użytkownik administrator gdzie parametr K każe uruchomić polecenie za pomocą sudo i zapytać ansible o hasło (raz dla wszystkich hostów – stąd muszą mieć ustawione te same hasło jeśli chcemy załatwić pracę jednym poleceniem).
    ansible all -m apt -a “pkg=eclipse state=present” –user=administrator -K – użycie modułu apt do instalacji pakietów na systemach debianowych – instalujemy eclipse.
    Drugim sposobem jest wykonywanie wielu działań na raz za pomocą tzw. playbook. Są to pliki w YAML, których składnia jest bardzo prosta:
    - hosts: webservers
      vars:
        http_port: 80
        max_clients: 200
      remote_user: root
      tasks:
      - name: ensure apache is at the latest version
        yum: pkg=httpd state=latest
      - name: write the apache config file
        template: src=/srv/httpd.j2 dest=/etc/httpd.conf
        notify:
        - restart apache
      - name: ensure apache is running
        service: name=httpd state=started
      handlers:
        - name: restart apache
          service: name=httpd state=restarted
    
    Kolejno deklarujemy w nim z jaką grupą hostów pracujemy, dodajemy zmienne, użytkownika na koncie którego będziemy wykonywać polecenia, oraz zadania. Zadanie ma swój opis – komentarz (name) oraz podany moduł (np. yum) i stan. Po kilku minutach nauki składni można zacząć już pracę i tworzyć proste playbooki. Małym problemem Ansible może być fakt, że w pliku hosts wpisujemy IP (lub domeny) i gdy mamy komputery o zmiennym IP z DHCP to nie możemy tego zrobić. W przypadku niepowodzenia polecenie nie jest automatycznie ponawiane.
    Samo Ansible bardzo mi się podoba i decydujące tutaj poza faktem lekkości po stronie klienta (serwer ssh) jest fakt, że od razu wiem jaki skutek odniosły moje działania. Jednak dla osób, które chciałyby zarządzać dużą ilością desktopów lepszym rozwiązaniem może okazać się CFEngine.

    Webansible – interfejs webowy dla ansible

     
    Używanie Ansible za pomocą konsoli jest całkiem proste. Jednak miło byłoby mieć możliwość uruchamiania powtarzalnych operacji za pomocą GUI. A ponieważ w dzisiejszych warto pisać uniwersalnie, więc najlepiej żeby to GUI było uruchamiane w przeglądarce. Zrobienie interfejsu webowego dla ansible miałoby tę zaletę, że w przeciwieństwie do tradycyjnego GUI można by umieścić go nie tylko na własnym laptopie, ale też na serwerze z którego można by zarządzać po połączeniu przeglądarką. Dzięki temu nie byłby konieczny dostęp do określonego komputera z zainstalowanymi Ansible, do którego wszystkie zarządzanie hosty posiadają klucze. Niestety AnsibleWorks, firma zajmująca się rozwojem Ansible, przygotowała wersję interfejsu webowego, który jest oprogramowaniem komercyjnym. Istnieje możliwość używania go bezpłatnie dla grupy do 10 komputerów. Dla potrzeb np. szkoły jest to niewystarczające, zaś cena $100 za komputer rocznie jest zaporowa. Ponieważ od dłuższego czasu kombinowałem z wdrożeniem jakiegoś systemu do zarządzania komputerami, zdecydowałem się napisać taki interfejs samodzielnie. Tym bardziej, że potrzebny jest mi również sposób na wykrywanie IP komputerów w sieci wewnętrznej pracujących w oparciu o DHCP.

    Wymagania:

    1. Praca z apt-get: update, upgrade
    2. Dodawanie i usuwanie źródeł oprogramowania
    3. Wybór oprogramowania do instalacji i usunięcia z listy oprogramowania
    4. Możliwość tworzenia grup komputerów i zarządzania nimi osobno
    5. Edycja i kopiowanie plików konfiguracyjnych na hosty
    6. Uruchamianie pojedynczego polecenia z konsoli w przeglądarce
    7. Edycja i uruchamianie playbooków
    8. Rejestrowanie komputerów o zmiennym IP i dodawanie ich do pliku hosts
    9. Zapisywanie historii ostatnich operacji
    10. Małe zużycie zasobów systemowych przez oprogramowanie
    Plany realizacji:
    Rozwiązania takie jak SpaceWalk czy Rudder są bardzo fajne, jednak jak dla mnie zbyt ciężkie. Jeżeli ten drugi zadowala się 1GB pamięci RAM,to w tym pierwszym potrzeba, aż 2GB. W moim oprogramowaniu powinno wystarczyć 50 – 100MB, a tylko w większych systemach konieczne byłoby więcej. No i z tego powodu używany przeze mnie do tej pory Lift odpada. Co prawda gdzieś na forum David Pollack pisał, o możliwości uruchomienia Lifta na 32-64MB, ale jakoś nie chce mi się w to wierzyć widząc na dotychczasowe moje aplikacje). Przeanalizowałem kilka możliwych rozwiązań. Teoretycznie Scalatra powinna być lżejsza do Lifta. Jednak patrząc nawet po rozmiarze pliku war nie widać wielkiej różnicy i być może byłoby to wydajniejsze rozwiązanie, ale nie sądzę aby była duża różnica. Mógłbym pokusić się o napisanie samodzielnie prostego serwera www w oparciu o HTTPServer. Jednak wymagałoby to pewnie dużo czasu, a i skalowalność byłaby słaba. Zastanawiałem się nad Socko Web Server. Na koniec zdecydowałem się na Spray.io. Socko wydaje się bardzo podobne do Spray jednak ten drugi projekt jest o wiele dojrzalszy, jak również o wiele więcej projektów z niego korzysta. Poznanie Spray może mi się przydać w przyszłości do innych projektów, więc warto chociażby z tego powodu go wybrać. Spray posiada możliwość uruchamiania aplikacji z wbudowanych serwerem (spray-can). Jest bardzo modularny i nie ma dużych wymagań. Po stronie przeglądarki zamierzam użyć Bootstrap Twitter (wygląd strony) oraz frameworka AngularJS. Po stronie serwera za szablony HTML ma odpowiadać Twirl (ponieważ jako jedyny jest dobrze zintegrowany ze Spray).
    Stan obecny
    Aby zapewnić wykrywanie IP hostów napisałem prostą aplikację w języku Vala, która pinguje serwer (z użyciem libsoup). Serwer odbiera pingowanie i uaktualnia adres IP hosta i na żądanie tworzy plik /etc/ansible/hosts. W zasadzie ta funkcjonalność jest już wystarczająca, aby przejść do konsoli i zarządzać komputerami co wykorzystuje już w pracowni.
    Najbliższe plany
    W pierwszej kolejności uruchamianie poleceń ansible bez konieczności przechodzenia do konsoli. Następnie wykonywanie update, upgrade i instalacja pakietu według nazwy oraz dodawanie źródeł oprogramowania.

    LejOS na Lego MIndstorm ev3

     
    Ze strony: https://sourceforge.net/projects/ev3.lejos.p/files/ pobieramy pakiet spakowany tar.gz i rozpakowujemy. System LejOS na ev3 uruchamiany jest z karty MicroSD. Na kartę wgrywamy system poprzez przywrócenie obrazu z sd500.img (najpierw rozpakować zip). Wgrywamy rozpakowany zip. lejosimage do katalogu głównego, a następnie ściągamy oracle javę dla Mindstorma (tylko wersja 7 jest obsługiwana) i wgrywamy paczkę tar.gz do głównego katalogu na karcie. Usuwamy kartę i wsadzamy do LEGO. Po bootowaniu z karty LejOS zainstaluje javę i utworzy własną partycję na dane. Zajmie to sporo czasu ok 10 minut. Do Eclipse instalujemy wtyczkę wyszukując w Eclipse Marketplace o nazwie Lejos ev3. Dodajemy w Properties projektu Build Path z rozpakowanego archiwum lib/ev3 pliki .jar Podać adres IP (po USB) kostki.
    Instrukcja instalacji: https://sourceforge.net/p/lejos/wiki/Installing%20leJOS/?version=9
    Parowanie bluetooth: http://www.ev3dev.org/docs/tutorials/connecting-to-the-internet-via-usb/
    Zrobić to dla komputera, dla ev3 powinno samo zadziałać. Adres IP będzie na wyświetlaczu Mindstorma

    Skip to content