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ć.

Przeniesienie środowiska z FC29 na Debian10

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ą

Kopie zapasowe

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/

Svn

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ł.

Stretch zainstalowany

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:

NeoPi

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)

Multiple cameras

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?)

A620 powered with CA-PS500

A620 (side view)

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).

Compiling newest (march 2013) version of gphoto2 on Raspberry Pi

## 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...

Wariant #1: dysk USB podłączony do RPi

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)

Wariant #2: kopia systemu tworzona na innym komputerze

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

Przywracanie systemu z kopii zapasowej

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

Rysunek #1

Rysunek #2

Rysunek #3


Rysunek #4

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.