![[Photo gallery]](/staff/tp/icons/ico_gallery.png){kind=icon}
Się poprzedni wpis kończył jakoby odtworzenie repozytorium svn
było prostą sprawą, ale w praniu się okazało, że nie do końca:
# zapisanie starego svnadmin dump svnrepo > svnR.out # odtworzenie svnadmin create svnrepo svnadmin load svnrepo < svnR.out
Próba zapisu skutkuje komunikatami o błędach. No tak zachciało
mi się zmienić port na niestandardowy. Żeby svn wiedział jak się połączyć
trzeba dopisać (na koncie
komputera klienta, w sekcji [tunnels]):
vi ~/.subversion/config ssh = $SVN_SSH ssh -q -p PORTNUMBER
# addgroup svn Adding group `svn' (GID 1002) ... # gpasswd -a "tomek" svn ##Adding user tomek to group svn # chgrp -R svn path-to-svnrepo
Teraz
svn info Ścieżka: . Working Copy Root Path: /home/tomek/orgfiles URL: svn+ssh://tomek@umbriel/media/usbstick/svnrepo/tp/orgfiles ... ## Zmień svn+ssh://tomek@umbriel/path-to-repo na nowe: svn relocate svn+ssh://tomek@umbriel/path-to-repo/path-to-project
Jupiter to mój niepubliczny serwer. Podłączona do niego jest stacja pogody, termometry DS18B20, wykonywane są kopie zapasowe oraz założone repozytorium CSV. No i to powodowało że zabierałem się do aktualizacji systemu jak do jeża. Wszystko było tak stare, że już zapomniałem jak działa--a że działało, to teoretycznie nie było potrzeby wymiany.
Z drugiej strony jednak: system był już tak wiekowy, że niepielęgnowany. Nic nie można było ani doinstalować ani uaktualnić. Ponadto na drugiej szewie była inna wersja -- uruchamiany z karty SDHC Debian Lenny. Uruchamianie z karty (zamiast tego co jest wbudowane w komputerek) wydaje mi się bardziej eleganckie after all. No więc sytuacja dojrzała...
Obejrzałem sobie pliki crontab (roota i jedynego użytkownika tomek)
i ustaliłem co trzeba uruchomić: rsync do robienia kopii zapasowych (nie
pamiętam jak); pywwws do pobierania danych ze stacji pogodowej
i wysyłania na wundergroud oraz
jakieś skrypty Perla do prezentowania danych pogodowych na stronie
pinkaccordions.blogspot.org (nie pamiętam jak to było konfigurowane);
wreszcie odtworzenie repozytorium svn, którego używam na potrzeby wewnętrzne.
## Pobranie instalacja: root@umbriel:/home/tomek# pip install pywws Collecting pywws Downloading pywws-17.11.0.tar.gz (465kB) .... ## Testowania czy działa: root@umbriel:/home/tomek# pywws-testweatherstation 10:52:45:pywws.Logger:pywws version 17.11.0, build 1380 (b01d94a) 0000 55 aa 80 10... ## pakiet został umieszczony tutaj: /usr/local/lib/python2.7/dist-packages/pywws ## Inicjalizacja (/media/usbstick/Logs/weather/ to katalg z danymi) python -m pywws.LogData -vvv /media/usbstick/Logs/weather/ ## Tutaj jest plik konfigurujący vi /media/usbstick/Logs/weather/weather.ini ## musiałem dodać typ stacji: ws type = 1080 ## Wpis do Crontaba ## Dane pogodowe z WS1080 ## 9 * * * * /usr/local/bin/pywws-hourly -v /media/usbstick/Logs/weather >> \ ## /media/usbstick/Logs/root/weather/Hourly.log 2>&1
Wszystko działa but the wundergound. Trzeba dokonfigurować plik weather.ini, żeby pywwws wysyłało tam stosowne dane.
[underground] station = IPOMORSK8 password = <PASSWORD> template = default [hourly] services = ['underground'] text = [] plot = []
Dokładnie ma być jak wyżej underground a nie
wunderground, bo tak się nazywa plik
(/usr/local/lib/python2.7/dist-packages/pywws/services/).
Ponieważ mam dwie stacje (druga kupiona w projekcie, który nie został w końcu zrealizowany), to podłączyłem to drugą, do komputera z Debian Lenny (tego uaktualnię za czas jakiś, żeby mieć to samo na obu). Z tym drugim był większy problem bo w systemie nie ma pipa (pipy?)
#http://pywws.readthedocs.io/en/latest/guides/getstarted.html#test-weather-station # stacja #2 :: wget --no-check-certificate https://pypi.python.org/packages/49/ed/cd05eff0177b569c60230db5c13aded51355aada59f7f9d441d2d1353c4f/pywws-17.11.0.tar.gz tar -zxvf pywws-17.11.0.tar.gz cd pywws-17.11.0 python setup.py build python setup.py install wget --no-check-certificate https://pypi.python.org/packages/fc/38/026f001aa0cf2656a3e52556be73cb2a84fc7f6f40ae1bf75099cb6fa3ea/libusb-1.0.21b1.zip unzip libusb-1.0.21b1.zip cd libusb-1.0.21b1 python setup.py build python setup.py install wget --no-check-certificate https://pypi.python.org/packages/ec/5d/4fdac6c53525786fe35cff035c3345452e24e2bee5627893be65d12555cb/libusb1-1.6.4.tar.gz tar -zxvf libusb1-1.6.4.tar.gz cd libusb1-1.6.4 python setup.py build python setup.py install neptune:/home/tomek# mkdir /media/patriot/Logs neptune:/home/tomek# mkdir /media/patriot/Logs/weather neptune:/home/tomek# python -m pywws.LogData -vvv /media/patriot/Logs/weather/ 09:27:28:pywws.Logger:pywws version 17.11.0, build 1380 (b01d94a) 09:27:28:pywws.Logger:Python... ## Na stronie wunderground dodałem drugą stację, po czym ## dopisałem co trzeba do weather.ini vi /media/patriot/Logs/weather/weather.ini [underground] station = ISOPOT14 password = <PASSWORD> template = default
Obie działają
No robię kopie, chociaż nie były mi potrzebne przez 6 lat eksploatacji moich komputerków. Strategia jest taka, że co tydzień robię kopię całego systemu a co 24h wybranych katalogów. Wszystko w sumie prosto ale problem pojawił się w przypadku tworzenia kopii na innym komputrze:
![[Zdjęcie T. Przechlewskiego]](/personal/rysunki/home-icon.jpg){kind=icon}
#!/bin/bash
# Kopią jest cały system na innym komputerze (neptune):
SOURCE=neptune::wholefs/
ROOTLOG=/media/usbstick/Logs/root/RSync/rsync-neptune.log
EXCLUDE=/root/.rsync/backup_exclude_neptune.lst
DESTDIR=/public/sheeva/backup/neptune/rootfs
COPYDIR=/public/sheeva/backup/neptune
rsync -av --bwlimit=500 --exclude-from=${EXCLUDE} --delete ${SOURCE} ${DESTDIR}
## Edytujemy /etc/rsyncd.conf
max connections = 2
log file = /var/log/rsync.log
timeout = 300
[share]
comment = Public Share
path = /home/share
read only = no
list = yes
uid = nobody
gid = nogroup
auth users = tomek
secrets file = /etc/rsyncd.secrets
## Zawartość rsyncd.secrets
/etc/rsyncd.secrets
user:<PASSWORD>
## /etc/hosts
#Dopisane
192.168.1.142 neptune.pinaccordions.org neptune
## na neptune konfiguracja demona
/etc/rsyncd.conf
hosts allow = 192.168.1.121
Sprawdzenie czy działa
rsync neptune::wholefs/
Prosta sprawa
# zapisanie starego svnadmin dump svnrepo > svnR.out # odtworzenie svnadmin create svnrepo svnadmin load svnrepo < svnR.out
Ponieważ mam trzy sheevy, miałem ten komfort że uruchomiłem zapasową, na której wszystko dokonfigurowałem. Ta nowa którą nazwałem umbriel przejęła zadania starej, którą po 6 latach wyłączyłem. Zamiast jupitera jest zatem umbriel (księżyc Urana), bo jupiter się mi już znudził.
Co to jest SheevaPlug? Przodek rapberryPi. Ciągle używam, bo jest niezawodne, a z rapberryPi jest gorzej -- czasami przestaje działać. Rzadko bo rzadko ale się zdarza.)
Ponieważ SheevaPlug (dalej Szewa) jest taka stara to i Debian na niej do nowych nie należy. Sytuacja dojrzała do wymiany. Mam na szczęście rezerwową/testową Szewę, co ułatwia decyzję, bo w razie problemów z aktualizacją nie zostanę z niczym.
Korzystam z tej samej strony co lata temu kiedy zaczynałem z Szewą, tj. Installing Debian on Plug Computers, która opisuje wszystko detalicznie i zawiera wszystko co potrzeba. Procedura jest prosta:
1. Należy uaktualić firmware zwany U-bootem. W tym celu trzeba się
połączyć z Szewą kablem miniUSB-USB i uruchomić na PCcie program cu:
cu -s 115200 -l /dev/ttyUSB0
Teraz trzeba włączyć Szewę, a w terminalu PCta należy szybko nacisnąć dowolny klawisz co przerywa normalną sekwencję startu systemu i U-boot przechodzi do trybu interaktywnego zgłaszając się znakiem zachęty. Polecenie:
Marvell>> version
Pokazuje wersję system. Jeżeli w nazwie jest Marvell albo wersja jest stara (przed 2014/10) to należy dokonać aktualizacji. Przed aktualizację należy koniecznie ustalić MAC adres urządzenia Ja miałem przepisany z dokumentacji na obudowie; jak ktoś nie wie jaki ma adres, to może wydać polecenie:
print ethaddr
Teraz pobieramy stosowny firmware i kopiujemy go na (bootowalny) pendrive. Pendrive wsadzamy do Szewy, po czym wydajemy polecenie:
usb start fatload usb 0:1 0x0800000 u-boot.kwb
Następnie
nand erase 0x0 0x80000 nand write 0x0800000 0x0 0x80000
Restartujemy szewę
reset
Na koniec przywracamy MAC adres
setenv ethaddr 00:50:43:01:c0:ab saveenv reset
Uwaga: przy (re)starcie komputer zawiśnie na etapie ładowania systemu, którego jeszcze nie ma...
2. Poniższy opis zakłada instalowanie systemu z karty SDHC (bo tak
jest najprościej, skoro system ma potem być z tejże karty
uruchamiany). Zatem należy sformatować kartę SDHC jako ext2 (wyłącznie
ext2, nie należy używać innych typu ext4, że niby lepsze).
Do tego użyłem gparted.
3. Pobieramy instalator składający się z 2 plików (SheevaPlug without eSATA:
uImage
and uInitrd).
Pobrane plik kopiujemy na sformatowaną kartę.
Kartę wsadzamy do Szewy, z którą połączymy się kablem miniUSB/USB i programem cu
w sposób identyczny jak w przypadku aktualizacji firmware'a),
wydajemy polecenie
(jeżeli karta jest sformatowana jako vfat
to zamiast ext2load ma być fatload):
ext2load mmc 0:1 0x00800000 /uImage ext2load mmc 0:1 0x01100000 /uInitrd
Uruchamiamy instalator:
setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most bootm 0x00800000 0x01100000
Instalacja trochę trwa, ale jest bezproblemowa. Well, był problem bo zapomniałem wpisać następującej sekwencji (When the installation is done, you have to configure u-boot so it will automatically boot Debian. Interrupt the boot process of u-boot and enter the following commands.):
setenv bootargs_console console=ttyS0,115200
setenv bootcmd_mmc 'ext2load mmc 0:1 0x00800000 /uImage; ext2load mmc 0:1 0x01100000 /uInitrd'
setenv bootcmd 'setenv bootargs ${bootargs_console}; run bootcmd_mmc; bootm 0x00800000 0x01100000'
saveenv
Przyznam się bez bicia, że ponieważ pominąłem ten krok i system zawisł beznadziejnie potrzebna była konsultacja aż samego Marina Michlmayra.
Uwaga: 0:1 to nazwa bootowalnej partycji. Może być inna, można to ustalić
wpisując (pierwsza wypisana jest bootowalna):
Marvell>> usb dev Marvell>> usb part 0
Ostatecznie:
run bootcmd
Znowu dałem D... Nie przywracając MAC-adresu, co objawiło się tym że wprawdzie system się bootował ale instalator nie mógł się połączyć z Internetem. Należy czytać dokumentację uważnie i bez pośpiechu cnd.
Z uwagi na to, że projekt Szewa wydaje sie być dead&burried skopiowałem co trzeba lokalnie tutaj, na wypadek gdyby zniknęło w Internecie.
Problem jest oto taki, że chcę przenieść kopię
bloga (oryginał jest/był na serwerze nazwa.pl) na Sheevaplug (taki rodzaj NAS), która byłaby dostępna
przez Internet. Pierwszy krok do likwidacji bloga na nazwa.pl, bo drogo BTW.
Na Sheevaplug jest zainstalowany Debian w wersji Stretch i nie ma WordPressa.
Rozpocząłem od pobrania narzędzia wp-cli
ze strony wp-cli.org/.
Zainstalowałem toto (prawie) w sposób opisany na ww. stronie, tj.:
https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar php wp-cli.phar --info chmod +x wp-cli.phar sudo mv wp-cli.phar ~/bin/wp
Heurystycznie ustaliłem, że treść tego konkretnego
klonowanego bloga znajduje
się bazie mysql (teksty)
oraz w katalogu wp-content, w którym to w szczególności są
zdjęcia (wp-content/gallery) oraz filmy i chmara jakiś plików .gif
(wp-content/wp-uploads).
Oprócz tego są jeszcze katalogi themes,
upgrade, plugins, ngg oraz languages.
Uprzedzając
wydarzenia wszystko kopiuję
jak leci ze starej instalacji (w obu jest/będzie ta sama wersja WP).
Natomiast teksty z bazy eksportuję (do pliku SQL):
wp db export
Można też to zrobić logując się do URL-BLOGA/wp-admin. Teraz wszystko ściągam
korzystając z rsync (/media/WP-SITE/
oraz /media/WPSQL/ to oczywiście przykłady):
rsync -avzP -e "ssh" USER@BLOG:PATH-TO-WP/wp-content/* /media/WPSITE/ rsync -avzP -e "ssh" USER@BLOG:PATH-TO-WP/_sqldump_/* /media/WPSQL/
Zamiast rsync można użyć ftp albo:
scp -r USER@BLOG:path/to/files/
Teraz pobrałem archiwum WP ze strony wordpress.org/download/ i rozpakowałem je (Uwaga: być może można skopiować po prostu całą starą instalację WP na nowy komputer i będzie działać, ale ja tak nie robiłem.):
wget https://wordpress.org/latest.tar.gz tar -zxvf latest.tar.gz
Za pomocą klienta mysql stworzyłem użytkownika pn. wordpress,
który otrzymał stosowne uprawnienia. Utworzyłem następnie bazę
pn. wordpress:
mysql> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password';
mysql> CREATE DATABASE wordpress;
Query OK, 1 row affected (0.00 sec)
mysql> GRANT ALL PRIVILEGES ON wordpress.* TO 'user'@'localhost'
-> IDENTIFIED BY '*password*';
Query OK, 0 rows affected (0.00 sec)
Następnie wstawiłem stosowne wpisy do wp-config.php
define('DB_NAME', 'wordpress');
define('DB_USER', '**USER**');
define('DB_PASSWORD', '**PASSWORD**');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
Teraz zaimportowałem treść bloga do bazy:
wp db import kopia-bazy.sql --path='/var/www/html/'
Doczytałem, że trzeba zmienić URLe ze starych na nowe:
wp search-replace 'STARY-URL' 'NOWY-URL' --dry-run
Konkretnie w moim przypadku:
wp search-replace 'http://nazwabloga.nazwa.pl/' 'http://oberon.pinkaccordions.org/' \
--path='/var/www/html/' --dry-run
## --dry-run nic nie zmienia ale wyświetla raport
## jeżeli wszystko jest OK:
wp search-replace 'http://nazwabloga.nazwa.pl/' 'http://oberon.pinkaccordions.org/' \
--path='/var/www/html/'
Sprawdzam i nie działa, ale wypisuje, że nie ma jakiegoś theme. No to kopiuję jak leci
ze starej instalacji katalogi
themes, upgrade, plugins, ngg,
languages, o czym już pisałem. Teraz działa.
Jeszcze został problem udostępnienia tego w Interncie poprzez DynDNS. Sprawę komplikuje to, że mam już dwa zarejestrowane serwisy a Tomato wydaje się obsługiwać tylko dwa hosty. Okazuje się wszakże że pole host niekoniecznie musi zawierać pojedynczy wpis, może zawierać listę oddzielonych przecinkami nazw hostów. No to dopisałem następny host z puli, którą mam oraz dopisałem co trzeba w Tomato.
Dodatkowa komplikacja jest taka, że chcę ten sklonowany blog udostępnić na innym komputerze. Konkretnie do tej pory udostępniałem jeden komputer, a teraz będą dwa. Na taką okoliczność oprócz dopisania nazwy hosta do listy trzeba także zmodyfikować wpis w części port forwarding (por. rysunek). Drugi komputer wymaga mianowicie zadeklarowania innego ExPort-u.)
Po tym wszystkim nadal działa:-)