Weblog Tomasza Przechlewskiego [Zdjęcie T. Przechlewskiego]


scrum
random image [Photo gallery]
Zestawienie tagów
1-wire | 18b20 | 1wire | 2140 | 3rz | alsamixer | amazon | anniversary | antypis | apache | api | applebaum | arm | armenia | astronomy | asus | atom.xml | awk | aws | bakłażan | balcerowicz | balta | bash | berlin | bibtex | bieszczady | biznes | blogger | blogging | blosxom | borne-sulinowo | breugel | bt747 | budapeszt | canon | cedewu | chello | chiller | chillerpl | chown | chujowetaśmy | ciasto | cmentarz | contour | cron | css | csv | curl | d54250wykh | dbi | debian | dejavu | dhcp | dht22 | dia | docbook | dom | ds18b20 | dyndns | dynia | ebay | economy | ekonomia | elka | elm | emacs | emacs23 | english | ess | eu | excel | exif | exiftool | f11 | fc | fc11 | fc15 | fc5 | fc8 | fedora | fedora21 | fenix | ffmpeg | finepix | firefox | flickr | fontforge | fontspec | fonty | food | fop | foto | france | francja | fripp | fuczki | fuji | fuse | gammu | garmin | gawk | gazwyb | gdańsk | gdynia | gender | geo | georgia | gft | git | github | gmail | gnokii | gnus | google | googlecl | googleearth | googlemaps | gotowanie | gphoto | gphoto2 | gps | gpsbabel | gpsphoto | gpx | gpx-viewer | greasemonkey | gruzja | grzyby | haldaemon | handbrake | historia | history | hitler | holocaust | holokaust | hpmini | humour | iblue747 | ical | iiyama | ikea | imap | inkscape | inne | internet | j10i2 | javascript | jhead | k800i | kajak | kamera | kleinertest | kml | kmobiletools | knuth | kod | kolibki | komorowski | konwersja | krutynia | kuchnia | kurski | latex | latex2rtf | latex3 | lcd | legend | lenny | lesund | lewactwo | liberation | linksys | linux | lisp | lisrel | litwa | lizbona | logika | ltr | lubowla | lwp | m2wś | mapsource | marvell | math | mathjax | mazury | mbank | mediolan | mencoder | mh17 | michalak | michlmayr | microsoft | monitor | mp4box | mplayer | ms | msc | mssql | msw | mtkbabel | museum | muzyka | mymaps | mysql | nanopi | natbib | navin | nekrolog | neo | neopi | netbook | niemcy | niemieckie zbrodnie | nikon | nmea | nowazelandia | nuc | nxml | oauth | oauth2 | obituary | okular | olympus | ooffice | ooxml | opera | otf | otftotfm | other | overclocking | panoramio | pdf | pdfpages | pdftex | pdftk | perl | photo | photography | picasa | picasaweb | pim | pine | pis | pit | plotly | pls | plugin | po | politics | polityka | polsat | portugalia | postęp | powerpoint | prelink | problem | propaganda | pstoedit | putin | python | r | radio | random | raspberry pi | refugees | relaxng | ridley | router | rower | rowery | rpi | rsync | rtf | ruby | rugby | russia | rwc | rwc2007 | rwc2011 | rzym | samba | sem | sernik | sheevaplug | sienkiewicz | signature | sks | skype | skytraq | smoleńsk | sqlite | srtm | ssl | staszek wawrykiewicz | statistics | stats | statystyka | stix | stretch | suwałki | svg | svn | swornegacie | szwajcaria | słowacja | tbilisi | terrorism | tex | texgyre | texlive | thunderbird | tomato | totalnaopozycja | tourism | tramp | trang | truetype | ttf | turystyka | tusk | tv | tv5monde | twitter | typetools | ubuntu | uchodźcy | udev | ue | umap | unix | upc | updmap | ups | utf8 | varia | video | vienna | virb edit | vostro | wammu | wdc | wdfs | webcam | webdav | wh2080 | wiedeń | wikicommons | wilno | windows | windows8 | wine | wioślarstwo | word | wordpress | wrt54gl | ws1080 | wtyczka | ww2 | www | wybory | wybory2015 | włochy | węgry | xemex | xetex | xft | xhtml | xine | xml | xmllint | xsd | xslt | xvidtune | youtube | yum | zakopane | zakupy | zdf | zdrowie | łeba | świdnica | żywność
Archiwum
O stronie
wykorzystywany jest blosxom plus następujące wtyczki: tagging, flatarchives, rss10, lastbuilddatexhtmlmime. Niektóre musiałem dopasować nieco do swoich potrzeb. Więcej o blosxom jest tutaj
Subskrypcja
RSS 1.0
Migracja do Debian Stretch na jupiterze (svn)

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

url | Wed, 14/02/2018 09:14 | tagi: , , ,
Migracja do Debian Stretch na jupiterze

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

url | Sat, 03/02/2018 17:31 | tagi: , ,
Instalowanie Debiana Stretch na SheevaPlug

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.

url | Wed, 22/11/2017 08:31 | tagi: , , , ,
Przeniesienie bloga zarządzanego przez WordPress na inny komputer

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

url | Mon, 20/11/2017 11:26 | tagi: , , , ,
Wysyłanie maila z raspberry Pi/Sheevaplug przez gmail

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

url | Sat, 12/07/2014 20:20 | tagi: , ,
Great uptime of pinkaccordions.homelinux.org server

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.

url | Sun, 29/06/2014 13:50 | tagi: , ,
3rd anniversary of pinkaccordions.homelinux.org

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

url | Sun, 19/05/2013 20:05 | tagi: , , ,
1000 days online for pinkaccordions.homelinux.org

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)

url | Wed, 13/02/2013 07:52 | tagi: , ,
Running old Debian on a new Plug computer

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.

url | Tue, 07/08/2012 16:57 | tagi: , , , , ,
My sheevaplug seems to be broken

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

url | Tue, 17/07/2012 17:23 | tagi:
Sheevaplug half anniversary

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

url | Thu, 17/05/2012 08:36 | tagi: , ,
Niepotrzebne mlocate

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

url | Thu, 23/06/2011 17:49 | tagi: , , , ,
Rocznica pinkaccordions.homelinux.org

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

url | Wed, 25/05/2011 19:56 | tagi: , , , ,
Weather station

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 BifferBoardpywwsWatson W8681 Wireless Weather Station ReviewPersonal Weather Station.

Example pages generated with pywws: www.jump.me.ukwww.lauritsnielsen.dkmy page.

url | Fri, 08/04/2011 20:53 | tagi: , , ,
WDC MyBook Essential USB 3.0 i problem z kompatybilnością

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

url | Thu, 17/02/2011 18:48 | tagi: , , ,
Przestał działać youtube-dl

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.

url | Wed, 16/02/2011 19:48 | tagi: , ,
Wadliwy zasilacz w Sheevaplug
SheevaPlug PSU
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

url | Sat, 05/02/2011 09:40 | tagi: , , ,
Dodanie paru rzeczy do Sheeva #2

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//var/) więc może aż tak szybko to nie nastąpi....

url | Mon, 06/09/2010 15:32 | tagi: , ,
Konfigurowanie Apacha

Rozpoczynam od założenia w serwisie dyndns.org konta. Potem przechodzę do My ServicesHost 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...

Sheevaplug
Tomato: DynDNS

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

url | Thu, 27/05/2010 21:04 | tagi: , , , , , ,
Rekursywne przeglądanie wszystkich plików

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

url | Thu, 27/05/2010 13:50 | tagi: , ,
Kopia zapasowa karty SDHC, rsync i problemy

Uruchomiłem na Szewie #2 serwer WWW, dostępny pod adresem pinkaccordions.homelinux.org (darmowa domena z serwisu dyndys.com -- w moim przypadku konieczność, bo mam tzw. zmienne IP). Jak już jest serwer, to trzeba robić -- w sposób systematyczny, a nie ad hoc -- kopie zapasowe na wypadek gdyby, np. karta padła (co podobno nie jest takie rzadkie...). Po konsultacji z tym co w tym temacie proponują inni postanowiłem robić to za pomocą rsynca, uruchamianego z zewnętrznego komputera.

Sheevaplug
SheevaPlug

SDHC
Pamięć zewnętrzna + kopia

W tym celu trzeba zainstalować rsync na obu komputerach źródłowym i tym, na którym będzie tworzona kopia:

apt-get install rsync

Teraz należy skonfigurować rsync po stronie źródła (czyli tego komputera, z którego mają być kopiowane dane) modyfikując /etc/rsyncd.conf. Zawartość pliku /etc/rsyncd.conf w moim przypadku wygląda następująco:

## http://encodable.com/tech/blog/2005/10/13/Secure_Remote_Backups_via_rsync
uid = 0
gid = 0
hosts allow = *****
transfer logging = no
read only = yes

[wholefs]
path = /
comment whole root fs

[pinkaccordions]
path = /var/www_pinkaccordions/
comment pinkaccordions www

Można sprawdzić czy działa (neptune jest zadeklarowany w /etc/hosts):

rsync neptune::wholefs/ 

Tworzenie kopii realizuje skrypt rsync_neptune.sh uruchamiany po stronie przeznaczenia:

#!/bin/bash
SOURCE=neptune::wholefs/
EXCLUDE=/root/.rsync/backup_exclude.lst
DESTDIR=/backup/neptune/rootfs

echo "=== Syncing ${SOURCE} at `date` ==="
rsync -av --exclude-from=${EXCLUDE} --delete ${SOURCE} ${DESTDIR}

Plik $EXCLUDE zawiera te katalogi, które nie powinny -- z oczywistych względów -- być kopiowane (zawartości katalogów /proc, /sys oraz /tmp):

## Exclude
- /proc/*
- /sys/*
- /tmp/*

Skrypt rsync_neptune.sh jest zaś uruchamiany poprzez crona:

0 4 * * 7 /root/bin/rsync_neptune.sh >> /root/logs/RSync/RSync.log 2>&1

Idea jest taka: kopia całego rootfs z karty SDHC ma być wykonywana na dysk USB raz w tygodniu (z innego komputera, konkretnie Szewy #1). W razie potrzeby (awarii karty SDHC) kopia ta może być szybko przeniesiona na inną kartę SDHC... Można też kopiować bezpośrednio na kartę SDHC wsadzoną na zicher w czytnik kart, ale nie widzę sensu podłączania czytnika wyłącznie i tylko po to, żeby w razie awarii, mieć kopię karty od razu a nie po 3 minutach.

Zatem:

#!/bin/bash
EXCLUDE=/root/.rsync/backup_exclude.lst
SOURCE=/public/sheeva/backup/neptune/rootfs/
DESTDIR=/media/sd_backup

# http://www.cyberciti.biz/tips/shell-root-user-check-script.html
# Make sure only root can run our script
if [ "$(id -u)" != "0" ]; then
   echo "This script must be run as root" 1>&2 ; exit 1
fi

## sprawdz czy karta jest w czytniku i jest zamontowana
if [ -d "$DESTDIR" ]  ; then 
    echo "** OK: $DESTDIR!"
else
    echo "** ERROR: $DESTDIR not mounted!"; exit 1;
fi

rsync -av --exclude-from=${EXCLUDE} --delete ${SOURCE} ${DESTDIR}

No i tu porażka:

rsync: readlink_stat("/media/sd_backup/etc/shadow") failed: Input/output error (5)
rsync: readlink_stat("/media/sd_backup/etc/resolv.conf") failed: Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/etc/resolv.conf": Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/etc/shadow": Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/etc/network/run/ifstate": Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/var/lib/urandom/random-seed": Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/var/log/lastlog": Input/output error (5)
rsync: recv_generator: failed to stat "/media/sd_backup/var/run/dhclient.eth0.pid": Input/output error (5)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1058) [sender=3.0.5]

Trefne pliki (w liczbie sześciu, jak widać) mają długość 0 bajtów, a próba np. ls -li /media/sd_backup/etc/shadow powoduje komunikat I/O error. Usunąć tego też się nie da (rm -f nie daje rady)...

Wobec powyższego, sformatowałem partycję i wykonałem kopię za pomocą następującego polecenia wykorzystując tara:

tar cf - . | (cd /media/sd_backup/; tar xvpf - ) 2> ../../tar.log

Po wsadzeniu kopii zamiast oryginału do Szewy, system wydaje się działać. Czemu rsync zawiódł nie wiem (na razie)...

Dopisane 27 maja 2010 (po południu): Log tara (2> ../../tar.log) zawierał masę wpisów: implausibly old time stamp 1960-04-13 04:17:36. Data jest absurdalna. Żeby było śmieszniej w systemie była inna (w przód 2028 rok -- licznik się przekręcił tarowi?). Pliki z błędnym czasem modyfikacji były głównie w katalogach /dev/ /var/ oraz /etc/; wygląda jakby w czasie inicjalizacji, przed uruchomieniem ntpdate ,,fabryczny'' zegar Szewy wskazywał coś dziwacznego.

Czasy poprawiłem touchem. Zrobiłem rsync na dysk, a potem z dysku na kartę zapasową. Tym razem błędów nie było...

Dopisane 10 Kwietnia 2011: Poprawiłem skrypt rsync_neptune.sh na możliwą okoliczność wykonania kopii z uszkodzonych danych. W nowej wersji tworzone są trzy kopie z dwutygodniowym horyzontem czasowym:

#!/bin/bash
# rsync_neptune.sh (wersja poprawiona)
SOURCE=neptune::wholefs/

EXCLUDE=/root/.rsync/backup_exclude.lst
DESTDIR=/public/sheeva/backup/neptune/rootfs
COPYDIR=/public/sheeva/backup/neptune

### Zachowaj stara kopie pod inna nazwa:
cp -f ${COPYDIR}/1week.tar.gz ${COPYDIR}/2week.tar.gz

### Zachowaj stare dane (sprzed tygodnia):
tar -zcPf ${COPYDIR}/1week.tar.gz ${DESTDIR}

echo "=== Syncing ${SOURCE} at `date` ==="
rsync -av --exclude-from=${EXCLUDE} --delete ${SOURCE} ${DESTDIR}

Powinienem w ciągu dwóch tygodni się połapać, że coś jest nie tak, np. z kartą.

url | Tue, 25/05/2010 12:38 | tagi: , , , ,