Padł system na Sheevie #2 w taki tajemniczy sposób, że częściowo działał, ale nie do końca. Mianowicie system wchodził w tryb awaryjny bez jakiś wyraźnych komunikatów czemu tak robi. Karta sprawdzana fsck nie wykazywała żadnych błędów.

Po dłuższej szarpaninie zdecydowałem system odtworzyć na nowej karcie a moje dane przegrać ze starej.

Ponieważ akurat ta Sheeva była czas temu aktualizowana więc miała aktualny firmware. Wystarczyło nagrać co trzeba na czystą kartę (sformatowaną jako ext2) i dalej poszło bezszmerowo w tym sensie, że cała moja instrukcja opublikowana na tym blogu jakiś czas temu okazała się w 100% aktualna.

Po zainstalowaniu systemu takim oto sprytnym skryptem ustaliłem jakie pakiety doinstalowałem z wiersza poleceń (czyli brakuje ich w nowym systemie):

!/bin/bash
#(zcat $(ls -tr /var/log/apt/history.log*.gz); cat /var/log/apt/history.log) 2>/dev/null | \
(zcat $(ls -tr history.log*.gz); cat history.log) 2>/dev/null | \
  egrep '^(Start-Date:|Commandline:)' | \
  grep -v aptdaemon | \
  egrep '^Commandline:'

Jeszcze trzeba się było dopisać do grupy dialout żeby działał pomiar temperatury (który korzysta z /dev/ttyUSB0):

usermod -a -G dialout tomek

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

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

Today is the 1000th day that pinkaccordions.homelinux.org at sheevaplug is online.

During that period the only problem experienced was Sheevaplug's PSU breakdown.

Cf. Kopia zapasowa karty SDHC, rsync i problemy and Konfigurowanie Apacha (in Polish)

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.

Żarło, żarło i zdechło -- odpowiedział chłop na pytanie czemu krowa nie żyje...

Sheevaplug mi padła znienacka doszedłszy do 240 dni uptime'u. Diody w większości się świecą, ale po podłączeniu kablem USB nic się nie dzieje (nie ma /dev/ttyUSB0 ani żadnego innego /dev/tty*) , wzw. z tym nie można się skomunikować z urządzeniem.

My tiny server running on Debian/SDHC card/Sheevaplug has reached 183 days of uptime today.

Dziś wpisując df przeraziłem się widząc, że pozostało mi 17% wolnej przestrzeni na pinkaccordions.homelinux.org (8Gb karta SDHC) bo do niedawna było to ca. 70%. Szukając winnego znalazłem ponad 3Gb plik w katalogu /var/lib/mlocate, który powstał (i powiększał się) ponieważ lekkomyślnie zamontowałem katalog ,,/'' z dugiej szewy poprzez fusermount. Z kolei ta druga szewa ma podłączony 2 Tb dysk (który nie jest przez nią indeksowany dzięki dodaniu czego trzeba do /etc/updatedb.conf).

W pierwszej chwili chciałem zablokować indeksowanie podmontowanego katalogu. Po chwili namysłu zdecydowałem się na bardziej radykalne wywalenie mlocate:

apt-get remove mlocate && rm -rf /var/lib/mlocate/*

Alternatywnie można dodać do /etc/updatedb.conf

vim  /etc/updatedb.conf
# PRUNEPATHS to, które _nie będą_ indeksowane, dodaję /<ssfhs-katalog> żeby
# nie był indeksowany katalog zamontowany via fusermount
# PRUNEPATHS="/tmp /var/spool /<ssfhs-katalog>"

Ale po co mi w ogóle indeksowanie systemu plików na serwerze? Niepotrzebne... A im mniej zapisów tym -- podobno -- karta dłużej wytrzyma.

Przy okazji problemów z szewą: mój sposób synchronizacji czasu nie działa na jednej szewie jeżeli przy starcie systemu ntp nie połączył się z serwerem czasu... Poprawiłem czas (z pomocą kol. Rafiego):

# /etc/init.d/ntp stop 
* Stopping NTP server ntpd [ OK ] 
# ntpdate ntp.ubuntu.com
# /etc/init.d/ntp start

Minął rok odkąd zarejestrowałem w www.dyndns.com adres pinkaccordions.homelinux.org (dokładnie pierwszy wpis w access.log ma datę 23 maja 2010 r.). Działa doskonale....

Przy okazji: dzisiaj przeniosłem anemometr z płotu na dach bloku. Prędkości wiatru od razu wzrosły...

The unit I have bought is Termometerfabriken Viking 02049--a clone of Fine Offset Electronics WS 2080 which in turn is a newer version of the well known WS 1080/1090 models. This weather station measures wind speed and direction, outside temperature and humidity, inside temperature and humidity, rainfall and barometric pressure. It is equipped with 4 outside sensors namely: a thermo-hygrometer (THS), a wind direction sensor, a wind speed sensor, and a rain gauge. Only the temperature and humidity sensor is equipped with radio transmitter unit, so wind & rainfall sensors are connected to THS with telephone cables.

I have decided not to follow mounting as described in the manual. I put THS inside my wooden Stevenson screen which I have built some time ago and which I consider much better than the plastic ersatz included with the station. A rainfall sensor is mounted nearby. A real problem is the wind sensors. I plan to buy 30 m extension cable (original cable is only 2,5 m long) and mount the sensor at the roof of my flat. Complicated, but there are no other viable alternatives :-)

The software included is of no use to me as well. Fortunately there are free alternatives: wview and pywws. I have started with the first one not being aware of pywws existence.

Wview installs w/o problems in Lenny:

apt-get install wview

but fails to work:

/etc/init.d/wview start
/etc/init.d/wview: line 57:  1934 Illegal instruction     $WVIEWD_BIN
htmlgend[1936]: &1302287846673> : system init failed!
wvalarmd[1937]: &1302287846719> : wviewd process is not running - aborting!
wvcwopd[1938]: &1302287846764> : wviewd process not running - aborting!
wvhttpd[1939]: &1302287846807> : wviewd process no running - aborting!
wviewftpd[1940]: &1302287846850> : wview daemon lock file /var/lib/wview/wviewd.pid does not exist - aborting!
wviewsshd[1941]: &1302287846896> : wviewd process not running - aborting!
wvpmond[1942]: &1302287846942> : wviewd process not running - aborting!

Looking via Google how to proceed I have found nothing except the impression that wview is not finely maintained nor top quality software. Fortunately I have discovered pywws which installs and works flawlessly.

Useful links: Personal Weather Station using BifferBoard | pywws | Watson W8681 Wireless Weather Station Review | Personal Weather Station.

Example pages generated with pywws: www.jump.me.uk | www.lauritsnielsen.dk | my page.

Wymieniłem dysk zewnętrzny WDC MyBook 500 Mb na model WDC MyBook Essential 2 Tb (kod producenta: WDBACW0020HBK). Ten model ma już USB w wersji 3.0, które rzekomo jest 100% kompatybilne z 2.0.

Okazało się, że nie do końca. Dysk jest widziany w systemie (Debian Lenny na Sheevaplug) jak podpinam dziada przez przedłużkę z kabla USB 2.0. Jak łączę bezpośrednio grubaśnym kablem USB 3.0, to kicha.

Taka sobie ciekawostka...

Pythonowy skrypy youtube-dl przestał działać pyszcząc: ERROR: unable to download video (format may not be available). Trzeba ściągnąć nową wersję:

http://rg3.github.com/youtube-dl/download.html

Z zapisków wynika, że kiedyś zainstalowałem go aptem, więc może pomógłby jakiś update. Ale to następnym razem. Teraz już nie będę próbował, bo zainstalowałem youtube-dl ręcznie.

PSU starego typu (zepsute)

Popsuł się zasilacz w Sheevaplug co objawiało się tym, że po włączeniu migała tylko żółta dioda i dioda przy porcie RJ45 (także na żółto). Na szczęście problem był mi znany ponieważ jest masa doniesień i żalów co do jakości zasilacza aka PSU (power supply unit). Przykładowo tutaj:

Mine is flickering green and also ethernet port. No blue light. Do you think I have the same problem? Please let me know...

No więc zepsuł się 28. stycznia, tj. w piątek wieczorem. Od razu zamówiłem replacement psu, które wysłane 31. stycznia doszło w piątek... Nawiasem mówiąc dziś (sobota 5. lutego) na stronie jest napis Pre-Order now, due in late February -- musiałem kupić ostatni. Widać mocno schodzący towar:-) i warto mieć zapas ale o tym później...

Teoretycznie zmiana jest prosta, ale po rozkręceniu nie byłem tego już taki pewien. Obudowa tego komputera jest z plastiku a PSU i gniazdo zasilania wsadzone na zicher pomiędzy obudowę a wewnętrzne zaczepy (cf. tutaj). Bojąc się połamania obudowy poszedłem do fachowca (Piotr Strzelczyk) i to był dobry ruch. Zwłaszcza wsadzenie z powrotem gniazda zasilania było trudne.

Szewę kupiłem w październiku 2009 co oznacza, że popsuła się po 15 miesiącach. Not bad -- innym psuje się już po kilku... Mam jeszcze drugą szewę więc dobrze by było mieć zapasowy zasilacz pod ręką na wypadek braków w magazynie. Zamierzam zatem wypróbować procedurę reklamacji opisaną tutaj:

We can of course supply these under your warranty, but first we need to have your failed PSU returned to us (this is a stipulation from Globalscale, we have had to buy the PSU's and will get refunded for the failed PSU's we return to them), before we can send out the replacement. The charge for sending out the replacement PSU will be based on your location:

UK Customers -- GPB 2.50 [and] EU Customers -- GBP 5.00

If you feel you are not confident to do this replacement you can of course send the unit to us for us to carry out the replacement, there will however be a charge for returning the unit to you, this will again be based on your location:

UK Customers -- GBP 7.00 [and] EU Customers -- GBP 10.00

Nawet już napisałem do mr. Jasona, ale mnie olał... No cóż będziemy namolni.

Wygląda na to, że wadliwy PSU Sheevaplug to tzw. pikuś przy problemach z GuruPlug, reklamowanym jako następca Sheevaplug, który się nadmiernie grzeje. Niektórzy wprawdzie twierdzą, że nie ale problem chyba jest skoro producent [w desperacji] wyposażył GuruPlug w wiatrak, który:

makes a sound resembling that of a hair dryer...

Innym przypomina to odkurzacz (They are ridiculously noisy, similar to a high powered vacuum cleaner) Anyway, sprawa wygląda kiepsko. Kiedyś chciałem kupić GP, ale teraz już nie chcę...

Potencjalnym rozwiązaniem może być zewnętrzny zasilacz. Przykładowo tutaj jest opisane takie rozwiązanie. Jak się nowy [podobno lepszy] zepsuje, to może też się zdecyduję na zewnętrzny...

Dopisane 19 lutego 2011: Problem jest wałkowany in extenso w tym wątku na forum plugcomputer.org

Doinstalowałem kilka rzeczy, które mam na Szewie #1 (Ubuntu pamięć NAND) a do tej pory nie było ich na Szewie #2 (Debian na karcie), mianowicie: 1) esniper, 2) digitemp/pomiar temperatury, 3) różne moje skrypty Perla, 4) program youtube-upload.py.

#1. Kompilowanie esnipera wymaga doinstalowania curla:

apt-get install curl
apt-get install curlftpfs

Skrypt ./configure dalej kończy się błędem, zatem:

## http://www.linuxquestions.org/questions/linux-newbie-8/libcurl-and-curl-config-problems-453166/
apt-get install libcurl3-dev libwww-curl-perl python2.4-pycurl

Teraz działa i można skompilować esnipera.

#2. Przełączyłem kabel od termometrów ze starej Szewy na nową. Oprócz zainstalowania digitemp należało dodać do katalogu /etc/udev/rules.d/, plik np. 85-ttyusb.rules, zawierający:

# relax the permissions just for ttyUSB0
KERNEL=="ttyUSB0",              MODE="0666"

bo inaczej zwykły user nie ma dostępu do /dev/ttyUSB0. Teraz należy ponownie wyjąć/włożyć kabel USB. Ponieważ do tworzenia wykresu temperatury używam biblioteki perl-GD trzeba także dociągnąć:

apt-get install libgd-graph-perl

#3. Różne moje skrypty Perla (flickr/ebay) instalują ręcznie w katalogu:

/usr/local/share/perl/

Wreszcie instalują paczkę python-gdata na potrzeby skryptu youtube-upload.py do wysyłania moich filmików na YTube poprzez API:

wget http://gdata-python-client.googlecode.com/files/gdata-2.0.11.final.tar.gz

Powyższe zabiegi mają/miały na celu unifikację tego co jest na jednym i drugim komputerku... Mówiąc konkretnie chciałem żeby zamiast Ubuntu na Szewie #1 też była karta z Debianem. Ale, ale w trakcie naszły mnie wątpliwości: w sumie na cholerę? kupować jeszcze jedną kartę... Jak się pamięć zużyje to się będę martwił. A ponieważ katalogi, które nie są prawie-że-wyłącznie czytane przeniosłem poza pamięć NAND (tj. /home/ i /var/) więc może aż tak szybko to nie nastąpi....

Rozpoczynam od założenia w serwisie dyndns.org konta. Potem przechodzę do My Services→Host services, wybieram nazwę hosta (w moim przypadku pinkaccordions) i domeny (homelinux.org). Typ usługi: Host with IP address. Resztę pól można zostawić niewypełnione. Darmowe konto pozwala na przydzielenie 5 adresów...

Tomato: DynDNS

Tomato: port forwarding

Teraz w menu Tomato klikam w Basic→DDNS. Jako service wybieram DynDNS -- static, Username/Password to dane z rejestracji w serwisie DynDNS, hostname to z kolei wybrana przez nas nazwa hosta, tj. w moim przypadku pinkaccordions.homelinux.org. Więcej niczego nie trzeba wpisywać wystarczą dane domyślne. Można ustawić w ten sposób dwa adresy... Por też notatki tutaj.

Pozostaje wreszcie uruchamienie usługi port forwarding na routerze z działającym Tomato. Jest to bardzo proste i sprowadza się do wypełnienia pól Proto, Ext Ports, Int Address oraz opcjonalnie Description (por. ekran obok).

Instalacja serwera apache oraz php w systemie Debian Lenny.

apt-get install apache2  apache2-mpm-prefork apache2-utils apache2.2-common 
apt-get install php5 libapache2-mod-php5 php5-common php5-curl
apt-get install php5-dev php5-gd  php5-imagick php5-mcrypt php5-memcache php5-mhash \
    php5-mysql php5-pspell php5-snmp php5-sqlite php5-xmlrpc php5-xsl

W pliku /etc/apache2/ports.conf umieszczam komentarz przed dyrektywą NameVirtualHost:

#NameVirtualHost *:80

Zaś powyższą dyrektywę umieszczam w /etc/apache2/httpd.conf.

Konfiguracja wirtualnego hosta; plik /etc/apache2/sites-available/pinkaccordions powstaje przez skopiowanie pliku domyślnego:

cd /etc/apache2/sites-available/ ; cp default pinkaccordions

Następnie plik modyfikuję dopisując ServerName i ServerAlias

<VirtualHost *:80>
        ServerAdmin webmaster@localhost

        ServerName pinkaccordions.homelinux.org
        ServerAlias pinkaccordions.homelinux.org

        DocumentRoot /var/www_pinkaccordions/
   <!-- dalej w zasadzie niezmienione -->
</VirtualHost>

Teraz:

cd /etc/apache2/sites-enabled && ln -s ../sites-available/pinkaccordions pinkaccordions

To samo dla drugiego i ewentualnie kolejnych hostów. Innych plików za wyjątkiem opisanych wyżej httpd.conf, ports.conf oraz plików z katalogu ./sites-available/ i linków z katalogu ./sites-enabled/ nie ruszam. Teraz

/etc/init.d/apache2 restart
# albo apache2ctl graceful

No i powinno działać...

Dopisane 15 września 2010: Aby logrotate nie usuwał najstarszego przechowywanego pliku modyfikuję /etc/logrotate.d/apache2 i dodając stosowane prerotate...endscript:

sharedscripts
prerotate
  if [ -f "/path2logs/access.log.52.gz" ] ; then  
     cp /path2logs/access.log.52.gz /path2archive/access.`date +%Y%m%d`.log.gz ; fi
  if [ -f "/path2logs/access.fabians.log.52.gz" ] ; then
     cp /path2logs/access.log.52.gz /path2logs/access.`date +%Y%m%d`.log.gz ; fi
endscript

Teraz (mam nadzieję), plik access.log.52.gz przed skasowaniem zostanie skopiowany w inne miejsce i ocaleje. Pewnie można by prościej, przykładowo brutalnie wpisując po prostu rotate 156.

Na potrzeby dostosowana adresów URL do innej konfiguracji innego serwera wykorzystałem następujący skrypt:

#!/usr/bin/perl -w
use strict;
undef $/; ## na potrzeby czytania każdego pliku (process_file)

sub recurse($) {
  my($path) = @_;

  ## append a trailing / if it's not there
  $path .= '/' if($path !~ /\/$/);
  ## print the directory being searched
  print STDERR $path,"\n";

  ## loop through the files contained in the directory
  for my $eachFile (glob($path.'*')) {

    ## if the file is a directory
    if( -d $eachFile) {
      ## pass the directory to the routine ( recursion )
      recurse($eachFile);
    } else {

      ## przetwarzaj plik
      process_file ($eachFile);
    }
  }
}

sub process_file {
 my $file = shift;
 ## Tylko pliki .html i .php
 if ($file =~ /\.html|\.php$/) {
     my $tmp_file = "$file.temp";
     rename($file, $tmp_file);

     open (F, $tmp_file); open (FO, ">$file");
     my $ff = <F>;

     ## zamień bezwględne URLe na lepsze
     $ff =~ s/href=(["'])http:\/\/gnu.univ.gda.pl\/~tomasz/href=$1/g; ## zamień
     $ff =~ s/src=(["'])http:\/\/gnu.univ.gda.pl\/~tomasz/src=$1/g; ## zamień

     print STDERR "-> $file\n";
     print FO $ff;
     close(F); 
     close (FO);
 }
}

## initial call ... $ARGV[0] is the first command line argument
recurse($ARGV[0]);

Wymieniając procedurę process_file można oczywiście ww. skrypt zaadaptować do innych zadań, np. poprawienia zepsutej daty modyfikacji plików:-)