Dysk nowy kupiłem Samsung Evo 1T msata bo taki mam interfejs w moim NUCu.
Z tej okazji wymyśliłem sobie nie tylko zmienić dysk, ale także używaną wersję Linuksa, bo Fedora, której byłem wierny od początku (od 1999 r czyli 20 lat) ostatnio mnie mocno zaczęła wkurzać niedoróbkami (na przykład kompletnie dupiata obsługa mojej drukarki w wersji FC29, podczas gdy w wersji FC21 było zupełnie dobrze; usunięcie starych całkiem fajnych programów i zastąpienie ich czymś innym ale wcale nie lepszym). Może Debian będzie lepszy? Zresztą o tyle Debian dla mnie nie jest czymś zupełnie nowym, że używam go na serwerach (Sheeva/Raspberry.)
Po krótkiej konsultacji z Internetem, ściągnąłem 64-bitową wersję
pn. netinst (czyli mówiąc konkretnie stosowny plik ze strony https://www.debian.org/CD/netinst/
).
Skopiowałem toto po prostu na USB (cf
Preparing a USB stick
using a hybrid CD or DVD image)
# cp debian.iso /dev/sdX # sync
USB odpalił i bez problemu zainstalował system na dysku. Teraz dociągnąłem programy, z których korzystam:
apt update apt emacs mc texlive evince gimp imagemagick vlc gpsbabel r-base \ r-base-dev gretl sshfs apt install chromium-driver python-selenium python3-selenium apt install dia dia-common fontforge xpdf apt install git gpsprune libclang-dev libxml2-utils apt install mlocate python-tweepy python3-tweepy apt install qgis ## r-cran-ggplot2 spowodowało zainstalowanie prawie wszystkiego ## zaczynającego się od r-cran (i dobrze) apt install r-cran-ggplot2 r-cran-tibble apt install sqlite sqlite3 apt install thunderbird apt install vim apt install xscreensaver apt install xsltproc
Ręcznie doinstalowałem dwa programy, których nie ma w repozytoriach debiana:
## Google chrome dpkg -i google-chrome-stable_current_amd64.deb ## Rstudio dpkg -i rstudio-1.2.5019-amd64.deb
Z jakiś powodów znikły niektóre fonty w Firefoksie (który jest oryginalnie domyślną przeglądarką w systemie) na niektórych stronach (na Twitterze wszystkie, same rysunki wyświetlał). Konsultacje z google w temacie okazały się nieskuteczne więc zrobiłem reinstall:
apt remove firefox-esr apt install firefox-esr
Problem zniknął. Pojawił się też (na etapie instalowania pakietów R na przykład) dziwny komunikat o niemożliwości zainstalowania pakietu, bo cośtam z podpowiedzią żeby wykonać:
apt --fix-broken install
i faktycznie po wykonaniu powyższego, pakiety dały się instalować.
Przenoszę pliki konfiguracyjne i startowe i modlę się żeby nie trzeba było za dużo zmieniać.
Problem #1: inaczej działają pliki startowe basha (.bash_profile
w szczególności
w ogólnie nie jest czytany za to czytany jest .profile
).
Problem #2: emacs w trybie nxml
pluje błędem:
symbol's function definition is void: string-to-int, bo
string-to-int has been an obsolete function since Emacs 22.1, and it was removed in 26.1.
A ja miałem tak skonfigurowanego Emacsa, że nie korzystał z dystrybucyjnej (że tak powiem)
wersji nxml
, tylko ładował starą kopię umieszoną w ~/.emacs-local
Zmieniam i działa. Przy okazji robię niewielki porządek w .emacs
.
Wnioski: pierwsze koty za płoty zachęcające, Zobaczymy co będzie dalej bo jeszcze nie uruchomiłem wszystkiego czego używałem na starym systemie.
BTW: Ten post wysłany jest już z nowego systemu (za pomocą tych samych skryptów, które używałem w starym.)
W moim rpi mam Debiana w wersji Buster:
$sudo apt install python-selenium python3-selenium chromium-browser
Uruchamiam prosty skrypt, którego używam do pobierania zasobów z Internetu:
$selenium_get_www_page.py https://www.google.pl chrome not reachable
Po konsultacji z google znalazłem (radykalne) rozwiązanie. Należy zrobić downgrade relewantnych pakietów:
# Jakie są wersje dostępne: apt-cache madison chromium-chromedriver chromium-browser
Nie ma żadnych innych poza tymi, które mam zainstalowane, więc trzeba doinstalować z wersji Stretch:
# Należy dodać deb http://archive.raspberrypi.org/debian/ stretch main # do /etc/apt/sources.list apt-get update # Jakie są wersje dostępne teraz: apt-cache madison chromium-chromedriver chromium-browser chromium-chromedriver | 74.0.3729.157-rpt5 | \ http://archive.raspberrypi.org/debian buster/main armhf Packages ...
Instaluję stare wersje:
apt-get install chromium-chromedriver=72.0.3626.121-0+rpt4 chromium-browser=72.0.3626.121-0+rpt4 chromium-codecs-ffmpeg-extra=72.0.3626.121-0+rpt4 chromium-browser-l10n=72.0.3626.121-0+rpt4 apt-mark hold chromium-chromedriver chromium-browser chromium-codecs-ffmpeg-extra chromium-browser-l10n
Teraz skrypt selenium_get_www_page.py
działa.
Nafisa to arabskie imię żeńskie (i restauracja uzbecka w Elblągu, którą polecam) oraz nazwa mojego nowego serwerka uruchomionego na Raspberry Pi 3.
Do tej pory moje domowe serwery działały (od lat prawie 10) na sheevaPlug i cechowały się wysoką niezawodnością (uptime idący w setki dni; rekord 650 dni). Kiedyś już chciałem je przenieść na RPi, ale ówczesne modele RPi okazały się niedostatecznie reliable. Po nastu dniach następował zwis albo coś w tym stylu, więc dałem sobie spokój. Daję teraz RPi drugą szansę mając nadzieję, że nowe modele są bardziej niezawodne.
Instalacja przebiegła standardowo: ze strony
https://www.raspberrypi.org/downloads/raspbian/
pobieram Raspbian
Buster with desktop and recommended software. Pobieram też zalecany
program balenaEtcher
(https://www.raspberrypi.org/documentation/installation/installing-images/README.md
)
do utworzenia bootowalnej karty SDHC. Klikam, wybieram, zapisuje się.
Nawet szybko. Teraz teoretycznie jak się utworzy plik (z dowolną zawartością)
o nazwie ssh
w partycji boot to można już wkładać kartę do komputerka
i startować, ale ja chcę po WiFi więc i tak muszę hasło podać (też
można pewnie podać grzebiąc w plikach na karcie ale ja nie wiem jak),
więc podłączam RPi do telewizora, łączę z ruterem, zmieniam hasło
i włączam SSH (które jest domyślnie zablokowane)
Konfiguruję router i wszystko działa. Teraz standardowo apt update
.
Pora na zaistalowanie wszystkiego co używam na starym serwerze, więc sprawdzam co ja tam zainstalowałem:
sudo dpkg-query -l | awk '{print $2}'
Wybieram z listy te, które wyglądają na doinstalowane:
apt-get install sshfs vim mc ## Digitemp bo planuję podłączyć termometry 18B20 apt-get install digitemp flickcurl-utils \ flickrbackup fonts-texgyre fuse gpsbabel gphotofs apt-get install r-base r-base-core r-base-dev \ r-base-html r-cran-boot r-cran-class r-cran-cluster \ r-cran-codetools r-cran-foreign r-cran-kernsmooth r-cran-lattice r-cran-mass r-cran-matrix r-cran-mgcv r-cran-nlme r-cran-nnet \ r-cran-rpart r-cran-spatial r-cran-survival r-doc-html r-recommended apt-get install imagemagick imagemagick-6-common \ imagemagick-6.q16 ## tweepy używam do zdalnego wysłania twitów apt install python3-tweepy python-tweepy ## net::twitter używam do pobierania twitów apt install libnet-twitter-perl apt install texlive-base texlive-binaries \ texlive-extra-utils texlive-font-utils \ texlive-fonts-recommended texlive-generic-extra \ texlive-generic-recommended texlive-latex-base texlive-latex-extra \ texlive-latex-recommended texlive-xetex
Potem się okazuje, że jeszcze trzeba doinstalować
apt install apache2 apt install r-cran-gg1plot2 r-cran-reshape2 r-cran-reshape apt install libgeo-distance-perl libjson-perl libgeo-distance-perl
Sprawdzam czy apache działa (łącząc się z nafisa/). Działa... Kopiuję skrypty ze starego serwera. Modyfikuję. Testuję niektóre i nawet działają...
Plan jest taki żeby teraz mocno potestować RPi i zobaczyć czy działa niezawodnie (BTW testowana z pewnym skryptem w R okazała się prawie 2 razy szybsza.)
Się poprzedni wpis kończył jakoby odtworzenie repozytorium svn
było prostą sprawą, ale w praniu się okazało, że nie do końca:
# zapisanie starego svnadmin dump svnrepo > svnR.out # odtworzenie svnadmin create svnrepo svnadmin load svnrepo < svnR.out
Próba zapisu skutkuje komunikatami o błędach. No tak zachciało
mi się zmienić port na niestandardowy. Żeby svn wiedział jak się połączyć
trzeba dopisać (na koncie
komputera klienta, w sekcji [tunnels]
):
vi ~/.subversion/config ssh = $SVN_SSH ssh -q -p PORTNUMBER
# addgroup svn Adding group `svn' (GID 1002) ... # gpasswd -a "tomek" svn ##Adding user tomek to group svn # chgrp -R svn path-to-svnrepo
Teraz
svn info Ścieżka: . Working Copy Root Path: /home/tomek/orgfiles URL: svn+ssh://tomek@umbriel/media/usbstick/svnrepo/tp/orgfiles ... ## Zmień svn+ssh://tomek@umbriel/path-to-repo na nowe: svn relocate svn+ssh://tomek@umbriel/path-to-repo/path-to-project
Jupiter to mój niepubliczny serwer. Podłączona do niego jest stacja pogody, termometry DS18B20, wykonywane są kopie zapasowe oraz założone repozytorium CSV. No i to powodowało że zabierałem się do aktualizacji systemu jak do jeża. Wszystko było tak stare, że już zapomniałem jak działa--a że działało, to teoretycznie nie było potrzeby wymiany.
Z drugiej strony jednak: system był już tak wiekowy, że niepielęgnowany. Nic nie można było ani doinstalować ani uaktualnić. Ponadto na drugiej szewie była inna wersja -- uruchamiany z karty SDHC Debian Lenny. Uruchamianie z karty (zamiast tego co jest wbudowane w komputerek) wydaje mi się bardziej eleganckie after all. No więc sytuacja dojrzała...
Obejrzałem sobie pliki crontab
(roota i jedynego użytkownika tomek)
i ustaliłem co trzeba uruchomić: rsync
do robienia kopii zapasowych (nie
pamiętam jak); pywwws
do pobierania danych ze stacji pogodowej
i wysyłania na wundergroud oraz
jakieś skrypty Perla do prezentowania danych pogodowych na stronie
pinkaccordions.blogspot.org
(nie pamiętam jak to było konfigurowane);
wreszcie odtworzenie repozytorium svn
, którego używam na potrzeby wewnętrzne.
## Pobranie instalacja: root@umbriel:/home/tomek# pip install pywws Collecting pywws Downloading pywws-17.11.0.tar.gz (465kB) .... ## Testowania czy działa: root@umbriel:/home/tomek# pywws-testweatherstation 10:52:45:pywws.Logger:pywws version 17.11.0, build 1380 (b01d94a) 0000 55 aa 80 10... ## pakiet został umieszczony tutaj: /usr/local/lib/python2.7/dist-packages/pywws ## Inicjalizacja (/media/usbstick/Logs/weather/ to katalg z danymi) python -m pywws.LogData -vvv /media/usbstick/Logs/weather/ ## Tutaj jest plik konfigurujący vi /media/usbstick/Logs/weather/weather.ini ## musiałem dodać typ stacji: ws type = 1080 ## Wpis do Crontaba ## Dane pogodowe z WS1080 ## 9 * * * * /usr/local/bin/pywws-hourly -v /media/usbstick/Logs/weather >> \ ## /media/usbstick/Logs/root/weather/Hourly.log 2>&1
Wszystko działa but the wundergound. Trzeba dokonfigurować plik weather.ini, żeby pywwws wysyłało tam stosowne dane.
[underground] station = IPOMORSK8 password = <PASSWORD> template = default [hourly] services = ['underground'] text = [] plot = []
Dokładnie ma być jak wyżej underground
a nie
wunderground
, bo tak się nazywa plik
(/usr/local/lib/python2.7/dist-packages/pywws/services/).
Ponieważ mam dwie stacje (druga kupiona w projekcie, który nie został w końcu zrealizowany), to podłączyłem to drugą, do komputera z Debian Lenny (tego uaktualnię za czas jakiś, żeby mieć to samo na obu). Z tym drugim był większy problem bo w systemie nie ma pipa (pipy?)
#http://pywws.readthedocs.io/en/latest/guides/getstarted.html#test-weather-station # stacja #2 :: wget --no-check-certificate https://pypi.python.org/packages/49/ed/cd05eff0177b569c60230db5c13aded51355aada59f7f9d441d2d1353c4f/pywws-17.11.0.tar.gz tar -zxvf pywws-17.11.0.tar.gz cd pywws-17.11.0 python setup.py build python setup.py install wget --no-check-certificate https://pypi.python.org/packages/fc/38/026f001aa0cf2656a3e52556be73cb2a84fc7f6f40ae1bf75099cb6fa3ea/libusb-1.0.21b1.zip unzip libusb-1.0.21b1.zip cd libusb-1.0.21b1 python setup.py build python setup.py install wget --no-check-certificate https://pypi.python.org/packages/ec/5d/4fdac6c53525786fe35cff035c3345452e24e2bee5627893be65d12555cb/libusb1-1.6.4.tar.gz tar -zxvf libusb1-1.6.4.tar.gz cd libusb1-1.6.4 python setup.py build python setup.py install neptune:/home/tomek# mkdir /media/patriot/Logs neptune:/home/tomek# mkdir /media/patriot/Logs/weather neptune:/home/tomek# python -m pywws.LogData -vvv /media/patriot/Logs/weather/ 09:27:28:pywws.Logger:pywws version 17.11.0, build 1380 (b01d94a) 09:27:28:pywws.Logger:Python... ## Na stronie wunderground dodałem drugą stację, po czym ## dopisałem co trzeba do weather.ini vi /media/patriot/Logs/weather/weather.ini [underground] station = ISOPOT14 password = <PASSWORD> template = default
Obie działają
No robię kopie, chociaż nie były mi potrzebne przez 6 lat eksploatacji moich komputerków. Strategia jest taka, że co tydzień robię kopię całego systemu a co 24h wybranych katalogów. Wszystko w sumie prosto ale problem pojawił się w przypadku tworzenia kopii na innym komputrze:
#!/bin/bash # Kopią jest cały system na innym komputerze (neptune): SOURCE=neptune::wholefs/ ROOTLOG=/media/usbstick/Logs/root/RSync/rsync-neptune.log EXCLUDE=/root/.rsync/backup_exclude_neptune.lst DESTDIR=/public/sheeva/backup/neptune/rootfs COPYDIR=/public/sheeva/backup/neptune rsync -av --bwlimit=500 --exclude-from=${EXCLUDE} --delete ${SOURCE} ${DESTDIR} ## Edytujemy /etc/rsyncd.conf max connections = 2 log file = /var/log/rsync.log timeout = 300 [share] comment = Public Share path = /home/share read only = no list = yes uid = nobody gid = nogroup auth users = tomek secrets file = /etc/rsyncd.secrets ## Zawartość rsyncd.secrets /etc/rsyncd.secrets user:<PASSWORD> ## /etc/hosts #Dopisane 192.168.1.142 neptune.pinaccordions.org neptune ## na neptune konfiguracja demona /etc/rsyncd.conf hosts allow = 192.168.1.121
Sprawdzenie czy działa
rsync neptune::wholefs/
Prosta sprawa
# zapisanie starego svnadmin dump svnrepo > svnR.out # odtworzenie svnadmin create svnrepo svnadmin load svnrepo < svnR.out
Ponieważ mam trzy sheevy, miałem ten komfort że uruchomiłem zapasową, na której wszystko dokonfigurowałem. Ta nowa którą nazwałem umbriel przejęła zadania starej, którą po 6 latach wyłączyłem. Zamiast jupitera jest zatem umbriel (księżyc Urana), bo jupiter się mi już znudził.
Co to jest SheevaPlug? Przodek rapberryPi. Ciągle używam, bo jest niezawodne, a z rapberryPi jest gorzej -- czasami przestaje działać. Rzadko bo rzadko ale się zdarza.)
Ponieważ SheevaPlug (dalej Szewa) jest taka stara to i Debian na niej do nowych nie należy. Sytuacja dojrzała do wymiany. Mam na szczęście rezerwową/testową Szewę, co ułatwia decyzję, bo w razie problemów z aktualizacją nie zostanę z niczym.
Korzystam z tej samej strony co lata temu kiedy zaczynałem z Szewą, tj. Installing Debian on Plug Computers, która opisuje wszystko detalicznie i zawiera wszystko co potrzeba. Procedura jest prosta:
1. Należy uaktualić firmware zwany U-bootem. W tym celu trzeba się
połączyć z Szewą kablem miniUSB-USB i uruchomić na PCcie program cu
:
cu -s 115200 -l /dev/ttyUSB0
Teraz trzeba włączyć Szewę, a w terminalu PCta należy szybko nacisnąć dowolny klawisz co przerywa normalną sekwencję startu systemu i U-boot przechodzi do trybu interaktywnego zgłaszając się znakiem zachęty. Polecenie:
Marvell>> version
Pokazuje wersję system. Jeżeli w nazwie jest Marvell albo wersja jest stara (przed 2014/10) to należy dokonać aktualizacji. Przed aktualizację należy koniecznie ustalić MAC adres urządzenia Ja miałem przepisany z dokumentacji na obudowie; jak ktoś nie wie jaki ma adres, to może wydać polecenie:
print ethaddr
Teraz pobieramy stosowny firmware i kopiujemy go na (bootowalny) pendrive. Pendrive wsadzamy do Szewy, po czym wydajemy polecenie:
usb start fatload usb 0:1 0x0800000 u-boot.kwb
Następnie
nand erase 0x0 0x80000 nand write 0x0800000 0x0 0x80000
Restartujemy szewę
reset
Na koniec przywracamy MAC adres
setenv ethaddr 00:50:43:01:c0:ab saveenv reset
Uwaga: przy (re)starcie komputer zawiśnie na etapie ładowania systemu, którego jeszcze nie ma...
2. Poniższy opis zakłada instalowanie systemu z karty SDHC (bo tak
jest najprościej, skoro system ma potem być z tejże karty
uruchamiany). Zatem należy sformatować kartę SDHC jako ext2
(wyłącznie
ext2
, nie należy używać innych typu ext4
, że niby lepsze).
Do tego użyłem gparted
.
3. Pobieramy instalator składający się z 2 plików (SheevaPlug without eSATA:
uImage
and uInitrd).
Pobrane plik kopiujemy na sformatowaną kartę.
Kartę wsadzamy do Szewy, z którą połączymy się kablem miniUSB/USB i programem cu
w sposób identyczny jak w przypadku aktualizacji firmware'a),
wydajemy polecenie
(jeżeli karta jest sformatowana jako vfat
to zamiast ext2load
ma być fatload
):
ext2load mmc 0:1 0x00800000 /uImage ext2load mmc 0:1 0x01100000 /uInitrd
Uruchamiamy instalator:
setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most bootm 0x00800000 0x01100000
Instalacja trochę trwa, ale jest bezproblemowa. Well, był problem bo zapomniałem wpisać następującej sekwencji (When the installation is done, you have to configure u-boot so it will automatically boot Debian. Interrupt the boot process of u-boot and enter the following commands.):
setenv bootargs_console console=ttyS0,115200 setenv bootcmd_mmc 'ext2load mmc 0:1 0x00800000 /uImage; ext2load mmc 0:1 0x01100000 /uInitrd' setenv bootcmd 'setenv bootargs ${bootargs_console}; run bootcmd_mmc; bootm 0x00800000 0x01100000' saveenv
Przyznam się bez bicia, że ponieważ pominąłem ten krok i system zawisł beznadziejnie potrzebna była konsultacja aż samego Marina Michlmayra.
Uwaga: 0:1
to nazwa bootowalnej partycji. Może być inna, można to ustalić
wpisując (pierwsza wypisana jest bootowalna):
Marvell>> usb dev Marvell>> usb part 0
Ostatecznie:
run bootcmd
Znowu dałem D... Nie przywracając MAC-adresu, co objawiło się tym że wprawdzie system się bootował ale instalator nie mógł się połączyć z Internetem. Należy czytać dokumentację uważnie i bez pośpiechu cnd.
Z uwagi na to, że projekt Szewa wydaje sie być dead&burried skopiowałem co trzeba lokalnie tutaj, na wypadek gdyby zniknęło w Internecie.
Problem jest oto taki, że chcę przenieść kopię
bloga (oryginał jest/był na serwerze nazwa.pl
) na Sheevaplug (taki rodzaj NAS), która byłaby dostępna
przez Internet. Pierwszy krok do likwidacji bloga na nazwa.pl
, bo drogo BTW.
Na Sheevaplug jest zainstalowany Debian w wersji Stretch i nie ma WordPressa.
Rozpocząłem od pobrania narzędzia wp-cli
ze strony wp-cli.org/.
Zainstalowałem toto (prawie) w sposób opisany na ww. stronie, tj.:
https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar php wp-cli.phar --info chmod +x wp-cli.phar sudo mv wp-cli.phar ~/bin/wp
Heurystycznie ustaliłem, że treść tego konkretnego
klonowanego bloga znajduje
się bazie mysql
(teksty)
oraz w katalogu wp-content
, w którym to w szczególności są
zdjęcia (wp-content/gallery
) oraz filmy i chmara jakiś plików .gif
(wp-content/wp-uploads
).
Oprócz tego są jeszcze katalogi themes
,
upgrade
, plugins
, ngg
oraz languages
.
Uprzedzając
wydarzenia wszystko kopiuję
jak leci ze starej instalacji (w obu jest/będzie ta sama wersja WP).
Natomiast teksty z bazy eksportuję (do pliku SQL):
wp db export
Można też to zrobić logując się do URL-BLOGA/wp-admin
. Teraz wszystko ściągam
korzystając z rsync
(/media/WP-SITE/
oraz /media/WPSQL/
to oczywiście przykłady):
rsync -avzP -e "ssh" USER@BLOG:PATH-TO-WP/wp-content/* /media/WPSITE/ rsync -avzP -e "ssh" USER@BLOG:PATH-TO-WP/_sqldump_/* /media/WPSQL/
Zamiast rsync można użyć ftp
albo:
scp -r USER@BLOG:path/to/files/
Teraz pobrałem archiwum WP ze strony wordpress.org/download/ i rozpakowałem je (Uwaga: być może można skopiować po prostu całą starą instalację WP na nowy komputer i będzie działać, ale ja tak nie robiłem.):
wget https://wordpress.org/latest.tar.gz tar -zxvf latest.tar.gz
Za pomocą klienta mysql
stworzyłem użytkownika pn. wordpress,
który otrzymał stosowne uprawnienia. Utworzyłem następnie bazę
pn. wordpress
:
mysql> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password'; mysql> CREATE DATABASE wordpress; Query OK, 1 row affected (0.00 sec) mysql> GRANT ALL PRIVILEGES ON wordpress.* TO 'user'@'localhost' -> IDENTIFIED BY '*password*'; Query OK, 0 rows affected (0.00 sec)
Następnie wstawiłem stosowne wpisy do wp-config.php
define('DB_NAME', 'wordpress'); define('DB_USER', '**USER**'); define('DB_PASSWORD', '**PASSWORD**'); define('DB_HOST', 'localhost'); define('DB_CHARSET', 'utf8');
Teraz zaimportowałem treść bloga do bazy:
wp db import kopia-bazy.sql --path='/var/www/html/'
Doczytałem, że trzeba zmienić URLe ze starych na nowe:
wp search-replace 'STARY-URL' 'NOWY-URL' --dry-run
Konkretnie w moim przypadku:
wp search-replace 'http://nazwabloga.nazwa.pl/' 'http://oberon.pinkaccordions.org/' \ --path='/var/www/html/' --dry-run ## --dry-run nic nie zmienia ale wyświetla raport ## jeżeli wszystko jest OK: wp search-replace 'http://nazwabloga.nazwa.pl/' 'http://oberon.pinkaccordions.org/' \ --path='/var/www/html/'
Sprawdzam i nie działa, ale wypisuje, że nie ma jakiegoś theme. No to kopiuję jak leci
ze starej instalacji katalogi
themes
, upgrade
, plugins
, ngg
,
languages
, o czym już pisałem. Teraz działa.
Jeszcze został problem udostępnienia tego w Interncie poprzez DynDNS. Sprawę komplikuje to, że mam już dwa zarejestrowane serwisy a Tomato wydaje się obsługiwać tylko dwa hosty. Okazuje się wszakże że pole host niekoniecznie musi zawierać pojedynczy wpis, może zawierać listę oddzielonych przecinkami nazw hostów. No to dopisałem następny host z puli, którą mam oraz dopisałem co trzeba w Tomato.
Dodatkowa komplikacja jest taka, że chcę ten sklonowany blog udostępnić na innym komputerze. Konkretnie do tej pory udostępniałem jeden komputer, a teraz będą dwa. Na taką okoliczność oprócz dopisania nazwy hosta do listy trzeba także zmodyfikować wpis w części port forwarding (por. rysunek). Drugi komputer wymaga mianowicie zadeklarowania innego ExPort-u.)
Po tym wszystkim nadal działa:-)
W ramach testowania nanoPi Neo podłączyłem do niego czujnik 18B20. Tym razem nie za pomocą układu MP00202 (FT232RL/DS2480B) który jest dość drogi (circa 60 PLN), ale wykorzystując USB-UART RS232 PL2303HX (za 4,40 PLN na Allegro + wysyłka.)
Podłączenie czujnika jest banalnie proste, mianowicie: styki oznaczone jako GND oraz +5V (na płytce układu USB-UART) łączy się z odpowiednimi stykami czujnika DS18B20, natomiast styki oznaczone jako RX oraz TX należy ze sobą połączyć a następnie połączyć ze stykiem DATA (środkowym) czujnika DS18B20.
I to wszystko. Korzystając z programu digitemp należy użyć digitemp_DS9097
(FT232RL/DS2480B
działało z wariantem digitemp_DS9097U
).
Nawiasem mówiąc nanoPi Neo działa tak średnio (wyrażając się oględnie), bo już go musiałem reistalować. Na dokładkę przy czytaniu dużych plików z pendrive'a USB się odłączał a system zgłaszał błędy -- powodem było być może zasilanie (jakiś super-wydajny zasilacz by pomógł/aktywny hub?).
Tak czy siak SheevaPlug działa mi bezawaryjnie a nanoPi Neo nie za bardzo.
Działałem według opisu ze strony
NanoPi NEO,
tzn. ściągnąłem
plik nanopi-neo-linux-rootfs-core-qte-sd4g-20160804.img.zip
(BTW downloads: 1632, czyli jestem hipsterem/trendsetterem!). Rozpakowałem,
wsadziłem kartę (micro SDHC 8Gb Toshiba, za +20 PLN BTW) do czytnika kart
i za pomocą dd
wykonałem obraz systemu:
dmesg [10869.916710] sd 1:0:0:0: [sdb] 15196160 512-byte logical blocks: (7.78 GB/7.24 GiB)
Czyli karta jest w urządzeniu /dev/sdb
. Zatem:
dd bs=4M if=nanopi-neo-linux-rootfs-core-qte-sd4g-20160804.img of=/dev/sdb
Kartę wyjąłem z czytnika, wsadziłem do Neo, urządzenie podłączyłem pod ładowarkę
do smartfona i kabel sieciowy RJ45. W instrukcji jest napisane, że po podłączeniu
zasilania nastąpi uruchomienie systemu sygnalizowane świeceniem się niebieskiej diody LED.
I tak było w istocie: dioda świeci jak nie przymierzając kogut na radiowozie MO.
Aby połączyć się z komputerkiem należy
teraz wykonać (,,fabryczne'' hasło to fa
):
ssh -l root@192.168.1.123
Adres 192.168.1.123
ustaliłem łącząc się z routerem
i oglądając device list (w instrukcji jest inny adres,
pod którym urządzenie powinno być podłączone). Teraz:
apt-get update && apt-get upgrade ## dla pewności apt-get install rsync less vim
Instalowanie mc
apt-get install mc # nie ma apt-get install software-properties-common ## teraz zadziała $add-apt-repository ppa:eugenesan/ppa $ sudo apt-get update $ sudo apt-get install mc # dalej kicha $ apt-get install mc-data # jakiś dziwny pakiet bez binarów, rzekomo zastępujący mc # https://mail.gnome.org/archives/mc/2015-December/msg00020.html # chyba jest problem z kompilacją na arma
Stay tuned
Dla nieuświadomionych Sheevaplug to taki dziadek RaspberryPi. Kiedy jeszcze nie sprzedawali Rpi kupiłem Sheevaplug i używam do dzisiaj. Na obu komputerach jest zainstalowany Debian, ale w różnych wersjach.
Listy mam wysyłać skryptem Perla więc
rozpoczynam od zainstalowania stosowego modułu Net::SMTP::TLS
:
sudo apt-cache search TLS | grep perl libnet-smtp-tls-butmaintained-perl - Perl module for providing SMTP... libnet-smtp-tls-perl - Perl SMTP client library supporting TLS and AUTH libwww-curl-perl - Perl bindings to libcurl sudo apt-get install libnet-smtp-tls-perl
W Debianie
działającym na Sheevaplug (Debian Lenny) nie ma gotowego pakietu
więc instaluję co trzeba za pomocą cpan
:
cpan install Net::SMTP::TLS
Skrypt do wysyłania listu (mail-snd.pl
):
#!/usr/bin/perl # http://dipinkrishna.com/blog/2010/12/sending-emails-gmail-smtp-perl/ use Net::SMTP::TLS; my $smtp = new Net::SMTP::TLS( 'smtp.gmail.com', Port => 587, User => 'USER1@gmail.com', Password=> '??PASSWORD??', Timeout => 30 ); # -- Enter email FROM below. -- $smtp->mail('USER1@gmail.com'); # -- Enter recipient mails addresses below -- my @recipients = ('USER2@gmail.com'); $smtp->recipient(@recipients); $smtp->data(); #This part creates the SMTP headers you see $smtp->datasend("To: USER2\@gmail.com\n"); $smtp->datasend("From: USER1\@gmail.com\n"); $smtp->datasend("Content-Type: text/html \n"); $smtp->datasend("Subject: A Test Mail"); # line break to separate headers from message body $smtp->datasend("\n"); $smtp->datasend("This is a test mail body"); $smtp->datasend("\n"); $smtp->dataend(); $smtp->quit;
W Sheevaplug działa i wysyła, a Raspberry Pi nie:
invalid SSL_version specified at /usr/share/perl5/IO/Socket/SSL.pm line 332
Żeby było śmieszniej w Debianie Lenny z Sheevaplug jest
jakaś bardzo stara wersja IO::Socket:SSL
:
## sprawdź numer wersji modułu cpan -D IO::Socket::SSL Installed: 1.16
A na Raspberry Pi znacznie nowsza (ale nie działa):
cpan -D IO::Socket::SSL Installed: 1.76 CPAN: 1.994 Not up to date
Aktualizuję
sudo cpan cpan> install IO::Socket:SSL
Ale to nie pomaga:
invalid SSL_version specified at /usr/local/share/perl/5.14.2/IO/Socket/SSL.pm
Rozwiązanie jest podane tutaj. Należy:
## w pliku SSL.pm sudo nano usr/share/perl5/IO/Socket/SSL.pm ## zmienić m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1[12]?))$}i ## na m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1[12]?))}i
Zamiast rzeźbienia w Perlu można zainstalować gotowe rozwiązanie
pn. sendemail
:
apt-get install sendemail
List wysyłamy w następujący sposób:
sendEmail -f USER1@gmail.com -t USER2@other.com \ -u "Title1" -m "this is a test message" \ -s smtp.gmail.com \ -o tls=yes \ -xu USER1 -xp '??PASSWORD??'
My tiny SheevaPlug ARM-based server has reached 366 days of uptime today. Proof included.
SheevaPlug is a sort of Raspberry Pi. One of the first such computers on the market, killed by Rpi a few years ago.
Three years from now
pinkaccordions.homelinux.org
was created. It runs for 3 years on
sheevaplug Arm-based server running
Debian installed on SDHC 8Gb card (details here).
I have made some progress in accessing still camera with gphoto2
(cf. here).
The detailed description of my set-up will be disclosed within a few weeks (as I am still not sure
if it is 100% success:-). In short:
I changed camera from Canon A620 to Nikon S3000.
I connected camera with active USB hub.
On every capture USB port is reset with usb_reset
utility
(cf here
and here)
I use two Nikon S3000 compact cameras so there is a problem how to identify which is which.
$gphoto2 --auto-detect Model Port ---------------------------------------------------------- Nikon Coolpix S3000 (PTP mode) usb:001,022 Nikon Coolpix S3000 (PTP mode) usb:001,021
So one can use --port usb:001,022
option to access first attached
camera and --port usb:001,021
to access the second one. Of
course hard-coded port numbers are troublesome as they are not fixed and change
if the device is disconnected/connected again.
Better way to identify the camera is to use it's serial number:
## $gphoto2 --get-config serialnumber --port PORT ## example $gphoto2 --get-config serialnumber --port usb:001,022 Label: Serial Number Type: TEXT Current: 000047514512
I have black Nikon with 000041076602 serial number and pink one with 000047514512 serial number. I use the following bash script to access the cameras:
#!/bin/bash PINK_CAM_ID='000047514512' BLACK_CAM_ID='000041076602' while test $# -gt 0; do case "$1" in -b|--black) REQ_CAM="$BLACK_CAM_ID";; -p|--pink) REQ_CAM="$PINK_CAM_ID";; esac shift done ## Picture filename: FILENAME="NIK`date +"%Y%m%d%H%M"`.jpg" ## Scan all attached cameras: while read PORT_ID do ##echo $PORT_ID ## -n means string is non-empty if [ -n "$PORT_ID" ] ; then CAM_ID=`gphoto2 --get-config serialnumber --port $PORT_ID | awk '/Current:/ { print $2 }' ` if [ $CAM_ID = "$REQ_CAM" ] ; then REQ_CAM_PORT="$PORT_ID" ##echo "*** Req Camera ID: #$CAM_ID." fi fi done <<< "`gphoto2 --auto-detect | grep usb | awk '{ print $6}'`" if [ -z "$REQ_CAM_PORT" ] ; then echo "*** Error: Camera $REQ_CAM not found ***" ## sent a SMS cf http://pinkaccordions.homelinux.org/wblog/sms_alerts_with_google_calendar.html sms_reminder.sh exit 1 fi ## reset the USB device REQ_CAM_PORT_DEVNAME=`echo $REQ_CAM_PORT | sed 's/^.*://' | sed 's/,/\//'` usb_reset /dev/bus/usb/${REQ_CAM_PORT_DEVNAME} LANG=C gphoto2 --port "$REQ_CAM_PORT" --force-overwrite --set-config flashmode=1 \ --set-config d002=4 \ --capture-image-and-download --filename "$FILENAME" ## reset the USB device again usb_reset /dev/bus/usb/${REQ_CAM_PORT_DEVNAME}
Property d002
sets picture resolution (4 means 2592x1944).
Value 1 of flashmode
turns-off flash.
It seems that without usb_reset
there are problems with battery charging (why?)
I would like to remote control a still camera via gphoto2
.
After consulting a list of supported cameras I bought (used) Canon A620
from Allegro (local Internet auction site, sort of E-bay).
This camera has many great features (I suspect even too great as Canon stop producing cheap cameras of this sort):
viewfinder, retractable LCD and can be powered with Compact Power Adapter CA-PS500 instead of batteries
(an important feature in my project).
The plan was simple: connect camera via USB cable to computer and power it with PSU. Capture photos periodically with
gphoto2
:
gphoto2 --auto-detect pi@raspberrystar ~/bin $ gphoto2 --auto-detect Model Port ---------------------------------------------------------- Canon PowerShot A620 (PTP mode) usb:001,006
So far, so good.
Now, I tried to capture a photo:
# one shot without flash, download the file and store in a file named as: GPHyyyymmddhhmm.jpg LANG=C gphoto2 --set-config flashmode=0 --capture-image-and-download --filename "GPH%Y%m%d%H%M.jpg"
As the creation time is wrong (due to camera wrong clock) I modified
the above as follows (note that touch
is used to adjust file's timestamp):
#!/bin/basg FILENAME="GPH`date +"%Y%m%d%H%M"`.jpg" LANG=C gphoto2 --set-config flashmode=0 --capture-image-and-download --filename "$FILENAME" touch "$FILENAME"
Unfortunately there are problems: I am able to remotely capture only one photo. Next remote capture try results in an error and the camera has to be hard reset (with power on/off button). The problem is reported by others too.
BTW: when I connected the camera to my PC the reliability is much better (but seems not perfect---I experienced camera disconnection too.)
My first try to resolve the problems was to update gphoto2
(raspbian contains version 2.4.14 of gphoto2
).
## optionally remove old version (there are no dependencies) apt-get remove gphoto2
There is no need to remove gphoto2
as compiled one
will be installed in another directory (/usr/local/
vs
/usr/
).
First install/compile the necessary packages:
apt-get install -y libltdl-dev libusb-dev libexif-dev libpopt-dev ## Download and install newer version of libusb 1.0.11 wget http://ftp.de.debian.org/debian/pool/main/libu/libusbx/libusbx_1.0.11.orig.tar.bz2 tar xjvf libusbx_1.0.11.orig.tar.bz2 cd libusbx-1.0.11/ ./configure && make && sudo make install ## Download and install newer version of libgphoto wget http://garr.dl.sourceforge.net/project/gphoto/libgphoto/2.5.1.1/libgphoto2-2.5.1.1.tar.bz2 tar xjf libgphoto2-2.5.0.tar.bz2 cd libgphoto2-2.5.1.1 ./configure && make && sudo make install
Download and install newer version of gphoto2
wget http://downloads.sourceforge.net/project/gphoto/gphoto/2.5.1/gphoto2-2.5.1.tar.gz tar xzvf gphoto2-2.5.1.tar.gz cd gphoto2-2.5.1 ./configure && make && sudo make install ## run ldconfig sudo ldconfig gphoto2 --version gphoto2 2.5.1 Copyright (c) 2000-2013 Lutz Mueller i inni
BTW compiling gphoto2
on my fedora 14 box requires
to install libtool-ltdl-devel
popt-devel
first:
#configure: error: cannot compile and link against libltdl #libgphoto2 requires libltdl (the libtool dl* library), #but cannot compile and link against it. yum -y install libtool-ltdl-devel popt-devel
Upon installing above two packages, the compilation of
libusb
, libgphoto
and gphoto2
proceeds smoothly.
Unfortunately installing new version of gphoto2
did not help.
The problem will be further examined...
First I find the device with SDHC card mounted:
pi@raspberrypi ~ $ sudo fdisk -l Disk /dev/mmcblk0: 7969 MB, 7969177600 bytes 4 heads, 16 sectors/track, 243200 cylinders, total 15564800 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000108cb Device Boot Start End Blocks Id System /dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA) /dev/mmcblk0p2 122880 15564799 7720960 83 Linux
Now I mount a USB stick for storing a copy of the system:
pi@raspberrypi ~ $ mkdir /media/sda1 ## Assume USB stick is /dev/sda1 pi@raspberrypi ~ $ mount /dev/sda1 /media/sda1
Raw copy with dd
pi@raspberrypi ~ $ sudo dd if=/dev/mmcblk0 | gzip -1 > /media/sda1/sd_backup.img.gz ## w/o compression: pi@raspberrypi ~ $ sudo dd if=/dev/mmcblk0 of=/media/sda1/sd_backup.img ## over ssh in case there is no USB stick at hand: user@othercomputer ~ $ sudo ssh root@raspberrystar dd if=/dev/mmcblk0 | gzip -1 | dd of=sd_backup.img.gz
Note: raspberrystar
is the name of my
system---change it to appropriate IP address or name.
Restoring system image:
pi@raspberrypi ~ $ zcat sd_backup.img.gz > /dev/sdX
Where /dev/sdX
denotes the device with blank SDHC card mounted.
More details can be found here.
Copying over sshfs
:
pi@raspberrypi ~ $ sudo apt-get install sshfs fuse-utils pi@raspberrypi ~ $ mkdir -p ~/Dist/jupiter ## mounting (as user tomek) remote directory /public/raspberry at jupiter; ## mounting point is: ~/Dist/jupiter pi@raspberrypi ~ $ sshfs tomek@jupiter:/public/raspberry/ ~/Dist/jupiter failed to open /dev/fuse: Permission denied
On first try failure (as usual). Only fuse group members can read/write from/to /dev/fuse
.
User pi should be added to group "fuse":
pi@raspberrypi ~ $ sudo usermod -a -G fuse pi
To activate the modifications made in /etc/group
one should log out/log in now.
pi@raspberrypi ~ $ sshfs tomek@jupiter:/public/raspberry/ ~/Dist/jupiter pi@raspberrypi ~ $ ls -l /home/pi/Dist/jupiter total 0 ## Raw copy with dd (with compression): sudo dd if=/dev/mmcblk0 | gzip -1 > /home/pi/Dist/jupiter/raspberrystar.iso
Added 3 Oct 2012:
15564800+0 przeczytanych recordów 15564800+0 zapisanych recordów skopiowane 7969177600 bajtów (8,0 GB), 3504,04 s, 2,3 MB/s
Raw copying of 8Gb SDHC card with compression over sshfs took about 1 hr. The resulting image size is about 1,6 Gb.
It is said to overclock Raspberry Pi one has to upgrade the system:
sudo apt-get update && sudo apt-get install raspberrypi* raspi-config
Then configure it with raspi-config
utility:
sudo raspi-config
It is good anyhow to check the system version first:
uname -a Linux raspberrystar.pinkaccordions.org 3.2.27+ #174 PREEMPT Wed Sep 26 14:09:47 BST 2012 armv6l GNU/Linux
The kernel is up to date. Inspecting raspi-config
I have discovered
it is not updated, but I prefer to configure the system via CLI (command line or console) interface
rather than GUI one (no need to connect the RPi to a TV set which is in another room:-).
So I decided not to upgrade the system but rather manually configure it.
To achieve overclocking one has to add the following lines to
/boot/config.txt
file:
pi@raspberrystar ~ $ sudo vim /boot/config.txt ## add the following: temp_limit=80 arm_freq=900 sdram_freq=500
Now reboot:
pi@raspberrystar ~ $ sudo reboot
Check the dmesg
:
pi@raspberrystar ~ $ dmesg | grep 7000 [ 1.956412] bcm2835-cpufreq: min=700000 max=900000 cur=700000
CPU frequency is still 700Mhz. To increase it one has to
edit scaling_governor
file:
pi@raspberrystar ~ $ sudo bash root@raspberrystar:/home/pi# echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ## check if the above works:-) pi@raspberrystar ~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance # display available options: pi@raspberrystar ~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors conservative ondemand userspace powersave performance
The ondemand
option
allows for adjusting CPU frequency depending
on CPU utilization.
Without any further reboot the new settings work:
# check current CPU frequency pi@raspberrystar ~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 900000
There is even a temperature sensor available so one can check if the CPU is not overheated:
# check processor temperature: pi@raspberrystar ~ $ /opt/vc/bin/vcgencmd measure_temp temp=46.5'C
To boot the system with scaling_governor
set to appropriate
value one has to edit /etc/rc.local
:
pi@raspberrystar ~ $ sudo vim /etc/rc.local # Add the following line # echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
I have performed a simple test:
#!/bin/bash # N=5 START=$(date +%s) for ((i=1;i<=$N;i++ )) ; do echo "**** Iteration $i ****" STARTI=$(date +%s) perl -e 'for ($i=0;$i<=10000000;$i++) { $s .= "xx"; }' ENDI=$(date +%s) ; TOTALI=$(( $ENDI - $STARTI )) echo "*** $TOTALI s." done END=$(date +%s) TOTAL=$(( $END - $START )) MEAN=`awk -v m=$TOTAL -v n=$N 'BEGIN { print m/n }'` echo "total: " $TOTAL "mean: " $MEAN ##
The test uses the following perl program:
perl -e 'for ($i=0;$i<=10000000;$i++) { $s .= "xx"; }'
Because computing time can vary, the program has to be run N
times
and the mean time is reported.
My Rpi runs 28--29s at 700 Mhz, 25,8s at 800 Mhz and 21s at 900 Mhz.
So running at 900 Mhz results in almost 30% reduction of computing time.
W temacie kopii zapasowej na stronach poświęconych Raspberry Pi znaleźć można wyłącznie(?)
opisy jak to zrobić za pomocą dd
. Ten sposób nie podoba mi się
na dłużą metę z uwagi na czas -- kopiowanie karty 8Gb z kompresją przez sshfs zajęło
około 1 godziny. Tworzenie kopii przyrostowych (za pomocą rsync
) wydaje się lepszym pomysłem...
Załóżmy, że do /etc/fstab
wpisano:
/dev/disk/by-id/usb-WD_5000AAV_External_57442D574341535535303634313031-0:0-part1 \ /mnt/external-disk ext4 noauto,user,rw 0 0
Utworzenie kopii systemu sprowadza się wykonania:
rsync -av --exclude=/proc/ --exclude=/sys/ --exclude=/tmp/ \ --exclude=/mnt/ --exclude=/home/pi/Dist/ --delete / /mnt/external-disk/backup/rpi
Opcja --exclude
pomija wymienione pliki/katalogi. W szczególności należy
koniecznie umieścić tam katalogi, w których są/mogą być montowane inne systemy plików,
np. /mnt/
(uniknięcie pętli, bo przecież /mnt/
zawiera zamontowany dysk USB)
oraz /home/pi/Dist/
(moje zwyczajowe miejsce montowania systemów plików przez sshfs
)
Kopia systemu z raspberry będzie tworzona na innym komputerze dostępnym poprzez sieć.
Konfigurowanie rsynca
należy rozpocząć od jego zainstalowania na obu
komputerach (źródłowym i odbiorcy):
apt-get install rsync
Zawartość pliku /etc/rsyncd.conf
po stronie źródła (czyli raspberry):
uid = 0 gid = 0 hosts allow = 192.168.1.*** transfer logging = no read only = yes [wholefs] path = / comment whole root fs
W pliku /etc/default/rsync
(także po stronie źródła,
tj. raspberry) należy wpisać lub ,,odhaszować'':
RSYNC_ENABLE=true
Teraz trzeba wystartować rsync
(po ustawnieniu RSYNC_ENABLE
, rsync
będzie już uruchamiany
w momencie startu systemu -- nie potrzeba
do tego żadnych dodatkowych zabiegów w konfiguracji)
# /etc/init.d/rsync restart
Można sprawdzić czy działa
podając polecenie (moje raspberry nazywa się raspberrystar)
na komputerze odbiorcy (jako root
):
rsync raspberrystar::wholefs/
Jeżeli wszystko jest OK to wyświetlona zostanie zawartość katalogu /
na raspberrystar (czyli źródle).
Utworzenie kopii systemu sprowadza się wykonania:
rsync -av --exclude=/proc/ --exclude=/sys/ --exclude=/tmp/ \ --exclude=/mnt/ --exclude=/home/pi/Dist/ --delete \ raspberrystar::wholefs/ /public/sheeva/backup/raspberrystar/rootfs
W razie potrzeby kopia może być szybko przeniesiona na inną kartę SDHC.
# uwaga: nazwy katalogów odpowiadają wariantowi #2 tworzenia kopii: rsync -av --log-file=rsync_`date +%Y%m%d%H`.log --delete \ /public/sheeva/backup/raspberrystar/rootfs/ /public/sdX
Gdzie /public/sdX
oznacza miejsce zamontowania karty SDHC.
Karta musi być wcześniej sklonowana z ,,pierwszej'' kopii systemu wykonanej za pomocą dd
, tj.:
zcat sd_backup.img.gz > /dev/sdX
Teraz można gdybać czy użycie samego dd
nie będzie prostsze. Być może -- ja wolę korzystać
na co dzień z rsynca
.
Zauważyłem, że przy intensywnych operacjach I/O są problemy z odczytem
danych przez GPIO (temperatura/wilgotność).
Problem nie jest duży, ponieważ tworzenie pierwszej kopii systemu zajęło mi jakieś 20 min
(można się spodziewać, że kolejne będą tworzone w ciągu kilku minut),
ale dla większej pewności dodałem ionice
i --bwlimit
(specjalnie tego nie testując, oprócz sprawdzenia, że działa)
ionice -c3 rsync -av --bwlimit=500 --exclude=/proc/ --exclude=/sys/ --exclude=/tmp/ \ --exclude=/mnt/ --exclude=/home/pi/Dist/ --delete \ raspberrystar::wholefs/ /public/sheeva/backup/raspberrystar/rootfs
Jeżeli powyższe zapisane zostanie do skryptu, np. o nazwie backup_raspberry.sh
,
to teraz aby ten skrypt był uruchamiany raz na tydzień, np. w niedzielę o 4:00
należy wpisac do pliku crontab (na komputerze odbiorcy) coś takiego:
0 4 * * 7 /root/bin/backup_raspberry.sh >> /root/logs/RSync/RSync.log 2>&1
Ustalamy jak nazywa się urządzenie, w którym jest zamontowana karta SDHC:
pi@raspberrypi ~ $ sudo fdisk -l Disk /dev/mmcblk0: 7969 MB, 7969177600 bytes 4 heads, 16 sectors/track, 243200 cylinders, total 15564800 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000108cb Device Boot Start End Blocks Id System /dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA) /dev/mmcblk0p2 122880 15564799 7720960 83 Linux
Teraz można zamontować pendrive'a, na którym zostanie zapisana kopia:
pi@raspberrypi ~ $ mkdir /media/sda1 ## zakładamy że pendrive jest oznaczony jako /dev/sda1 pi@raspberrypi ~ $ mount /dev/sda1 /media/sda1
Kopiowanie za pomocą dd
pi@raspberrypi ~ $ sudo dd if=/dev/mmcblk0 | gzip -1 > /media/sda1/sd_backup.img.gz ## bez kompresji będzie szybciej: pi@raspberrypi ~ $ sudo dd if=/dev/mmcblk0 of=/media/sda1/sd_backup.img ## po sieci, w przypadku gdy nie mamy wolnego pendrive'a ktos@inny-komputer ~ $ sudo ssh root@raspberrystar dd if=/dev/mmcblk0 | gzip -1 | dd of=sd_backup.img.gz
Uwaga: raspberrystar
powinno być zamienione na odpowieni adres IP (lub nazwę).
Przywracanie systemu z kopii zapasowej:
pi@raspberrypi ~ $ zcat sd_backup.img.gz > /dev/sdX
Gdzie /dev/sdX
to nazwa urządzenia z zamontowaną czystą kartą SDHC.
Więcej szczegółów i bardziej detalicznie jest tutaj.
Kopiowanie do pliku zamontowanego za pomocą sshfs
:
pi@raspberrypi ~ $ sudo apt-get install sshfs fuse-utils pi@raspberrypi ~ $ mkdir -p ~/Dist/jupiter ## montuję (jako użytkownik tomek) zdalny katalog /public/raspberry na ## komputerze jupiter; punkt montowania to ~/Dist/jupiter pi@raspberrypi ~ $ sshfs tomek@jupiter:/public/raspberry/ ~/Dist/jupiter failed to open /dev/fuse: Permission denied # Za pierwszym strzałem (jak zwykle) nie wyszło, a to dlatego, że # wyłącznie członkowie grupy "fuse" mogą czytać/pisać do/na /dev/fuse. # Należy zatem dodać użytkownika pi do grupy "fuse": pi@raspberrypi ~ $ sudo usermod -a -G fuse pi ## Teraz trzeba się wy/zalogować żeby zadziałały modyfikacje w /etc/group pi@raspberrypi ~ $ sshfs tomek@jupiter:/public/raspberry/ ~/Dist/jupiter pi@raspberrypi ~ $ ls -l /home/pi/Dist/jupiter razem 0 ## kopiowanie za pomocą dd (z kompresją `w locie'): sudo dd if=/dev/mmcblk0 | gzip -1 > /home/pi/Dist/jupiter/raspberrystar.iso
Dopisane 3 października 2012: 15564800+0 przeczytanych recordów 15564800+0 zapisanych recordów skopiowane 7969177600 bajtów (8,0 GB), 3504,04 s, 2,3 MB/s
Kopiowanie karty 8Gb z kompresją przez sshfs zajęło około 1 godziny. Plik z kopią systemu zajmuje około 1,6Gb
Urządzenie kupiłem w firmie Farnell. Z dostawą z UK wyszło 180 PLN. Do tego obudowa za ca 30 PLN (do kupienia np. na ebay.pl na aukcjach firmy A1 Items Ltd. Akrylowe obudowy oferowane na allegro.pl nie podobają mi się) i ładowarka z wyjściem mikroUSB, też za 30 PLN. No i karta 8GB Toshiba (do kupienia np. na Allegro.pl), przetestowana w Sheevaplugza -- 43 PLN.
Razem jak widać około 300 PLN. Dla porównania, Sheevaplug (plus karta) = 600 PLN.
Zainstalowanie systemu jest tak proste jak:
1. Ściągnięcie obrazu karty:
[tomek@darkstar ~]$ wget http://downloads.raspberrypi.org/images/raspbian/2012-08-16-wheezy-raspbian/2012-08-16-wheezy-raspbian.zip [tomek@darkstar ~]$ sha1sum 2012-08-16-wheezy-raspbian.zip [tomek@darkstar ~]$ unzip 2012-08-16-wheezy-raspbian.zip
2. Nagranie obrazu:
[root@darkstar]# df -h ## wsadzamy kartę do czytnika kart ## w moim przypadku się okazało że system `widzi' kartę jako /dev/sdc1 [root@darkstar]# umount /dev/sdc1 ## w poniższym, koniecznie of=/dev/sdc a nie of=/dev/sdc1 [root@darkstar]# dd bs=1M if=2012-08-16-wheezy-raspbian.img of=/dev/sdc 1850+0 przeczytanych recordów 1850+0 zapisanych recordów skopiowane 1939865600 bajtów (1,9 GB), 499,495 s, 3,9 MB/s [root@darkstar]# sync
3. Powiększenie wielkości partycji w programie gparted
(dla kart
o pojemności większej od 2Gb):
[root@darkstar]# gparted
Za pierwszym razem nie poszło -- nie wiem czemu. Gparted odmawiał stanowczo
powiększenia partycji. Zamontowałem kartę niepowiększoną, uruchomiłem RPi, żeby sprawdzić
czy w ogóle działa (Rysunek 1).
Potem wyłączyłem urządzenie.
Dla świętego spokoju spróbowałem drugi raz z gparted
i tym razem poszło (Rysunek 2).
Połączyć się z RPi można przez ssh, ponieważ raspbian jest tak skonfigurowany, że demon ssh jest uruchamiany przy starcie systemu.
[tomek@darkstar ~]$ ssh -l pi 192.168.1.115
Aby dokończyć konfigurację zalecane jest uruchomienie raspi-config
:
pi@raspberrypi ~ $ sudo raspi-config
Narzędzie to pozwala na (por. rys. 3): 1) powiększenie partycji, 2) ustawienie klawiatury, 3) zmianę hasła użytkownika o nazwie pi, 4) zmianę locale, 5) zmianę strefy czasu, 6) zmianę podziału pamięci (domyślnie 64Mb z dostępnych 256 Mb jest wykorzystywane przez GPU), 7) włączanie/wyłączanie serwera ssh, 8) start systemu w trybie graficznym lub tekstowym (domyślne).
Z powyższych interesowało mnie jedynie 2--5, reszta jest albo wykonana
(punkt jeden wykonałem za pomocą gparted
) albo domyślne nastawy mnie satysfakcjonują
(serwer ssh chcę mieć włączony, start systemu ma być w trybie tekstowym). Narzędzie
raspi-config
można uruchomić zresztą w każdej chwili.
Ponieważ wiem jak ustawić klawiaturę, locale, zmienić strefę czasu oraz hasło
w Debianie ,,tak w ogóle'', bez uciekania się do konfiguratorów, ostatecznie
nie uruchamiałem raspi-config
, tylko wykonałem następujące polecenia:
pi@raspberrypi ~ $ sudo apt-get update pi@raspberrypi ~ $ sudo apt-get install debconf ## zmiana stefy czasowej pi@raspberrypi ~ $ sudo dpkg-reconfigure tzdata ## zmiana locale na pl_PL.UTF-8 pi@raspberrypi ~ $ sudo dpkg-reconfigure locales ## zmiana hasła: pi@raspberrypi ~ $ sudo passwd pi ## klawiatura (nie przewiduję na razie podłączenia klawiatury) pi@raspberrypi ~ $ sudo vi /etc/default/keyboard
Instalowanie serwera apache
pi@raspberrypi ~ $ sudo groupadd www-data groupadd: group 'www-data' already exists pi@raspberrypi ~ $ sudo apt-get install apache2
Instalowanie serwera MySQL
pi@raspberrypi ~ $ sudo apt-get install mysql-server mysql-client php5-mysql
Instalowanie PHP
pi@raspberrypi ~ $ sudo sudo apt-get install php5-cgi php5-mysql \ php5-curl php5-gd php5-idn php-pear php5-imagick php5-imap \ php5-mcrypt php5-memcache php5-mhash php5-ming php5-pspell \ php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc \ php5-xsl php5-fpm php5-cgi php5-cli php5-common
Instalowanie różnych przydatnych rzeczy:
pi@raspberrypi ~ $ sudo apt-get install fuse-utils pi@raspberrypi ~ $ sudo apt-get install make zip unzip ## digitemp -- program do obsługi sensorów temperatury DS18B20 pi@raspberrypi ~ $ sudo apt-get install digitemp pi@raspberrypi ~ $ sudo apt-get install vim pi@raspberrypi ~ $ sudo apt-cache search emacs | grep 23 pi@raspberrypi ~ $ sudo apt-get install emacs23-nox
Apache działa o czym świadczy rysunek 4.
Sprawdzam też czy demon ntpd (synchronizacja czasu) jest uruchomiony:
ps aux | grep ntpd ntp 1840 0.0 0.8 5424 1544 ? \ Ss 20:04 0:03 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 102:104
Okazuje się, że jest...
Dopisane 18 września 2012: Zainstalowałem TeXa i zrobiłem test pt. jak szybki jest RPI. Otóż kompilacja dokumentu o objętości 150 stron zajmuje na RPi (real) 0m36.751s. Ten sam dokument na moim PC 0m2.541s, czyli 14,4 raza szybciej:-)
Although Sheevaplug has appeared to be not particularly reliable piece of hardware (this claim is based on personal experience and numerous reports of other users), it is a great fun as well, so I gave it next (the last one) chance and have bought another new plug to replace the broken one.
I planned to use SDHC card with Debian which worked seamessly with my previous plug computer, so I follow the procedure described below.
Connect PC to Sheevaplug with USB-miniUSB cable
Turn on the plug computer.
Run cu:
cu -s 115200 -l /dev/ttyUSB0
press any key. In response to boot loader prompt type:
Marvel>> version U-Boot 1.1.4 (Dec 27 2009 - 22:03:21) Marvell version: 3.4.27
The u-boot boot loader have to be upgraded before installing Debian
(cf.
http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html
).
Copy the U-Boot binary u-boot.kwb
to a USB stick formated with the FAT filesystem.
Plug the USB stick into a plug computer, connect the serial console and type the following commands:
usb start fatload usb 0:1 0x0800000 u-boot.kwb nand erase 0x0 0x60000 nand write 0x0800000 0x0 0x60000
Regardless of how U-Boot was installed, one have to restart the machine to load the new version of U-Boot:
reset
Boot the system (cf.
http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html
).
Configure the boot loader now. First of all, one has to change a setting so the device will boot the kernel which is used by Debian:
setenv mainlineLinux yes setenv arcNumber 2097 saveenv reset
Restart the device so the changes will take effect. Now configure the machine to boot:
setenv bootargs_console console=ttyS0,115200 setenv bootargs_root 'root=/dev/mmcblk0p2' setenv bootcmd_mmc 'mmc init; ext2load mmc 0:1 0x00800000 /uImage; ext2load mmc 0:1 0x01100000 /uInitrd' setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_mmc; bootm 0x00800000 0x01100000' saveenv
At this point SheevaPlug is ready to boot Debian automatically from SD card.
So, I inserted
my SDHC card with Debian 5.0 installed some 2 years ago and tried to connect via ssh
.
ssh -l <user> 192.168.1.88 Linux neptune.pinkaccordions.org 2.6.30-5-kirkwood #1 Wed Jan 12 15:27:07 UTC 2011 armv5tel
System is up and running so it seems reusing SDHC card with old Debian installation was sucessfull, but shortly I discovered there were problems...
System clock is terribly fast and
there are problems communicating with USB port. Upon consulting google I have discovered
kernel upgrade is recommended (cf.
http://www.cyrius.com/debian/kirkwood/sheevaplug/boot.html
and
http://www.cyrius.com/journal/debian/kirkwood/sheevaplug/
):
apt-get update apt-get dist-upgrade flash-kernel
First command generated lots of 404 errors because Lenny is not supported anymore (I was not aware of that).
I decided not to upgrade
to Lenny
and fixed /etc/apt/sources.list
instead
(cf.
http://superuser.com/questions/404806/did-debian-lenny-repositories-vanish
):
deb http://archive.debian.org/debian/ lenny main non-free contrib deb-src http://archive.debian.org/debian/ lenny main non-free contrib # Volatile: deb http://archive.debian.org/debian-volatile lenny/volatile main contrib non-free deb-src http://archive.debian.org/debian-volatile lenny/volatile main contrib non-free # Backports: deb http://archive.debian.org/debian-backports lenny-backports main contrib non-free # Previously announced security updates: deb http://archive.debian.org/debian-security lenny/updates main
Then, apt-get dist-upgrade
and flash-kernel
was completed
without errors.
After reboot, system works fine. I plan to upgrade it to Squeeze in the nearest future.
The moral from the story is: with God's and Google help one has not to be an expert to cope with running Linux.
My tiny server running on Debian/SDHC card/Sheevaplug has reached 183 days of uptime today.