Ubuntu költöztetése új merevlemezre

Vége a kampánynak, lassan újraéled a blog is. Most, hogy az éjjel nappal tartó munkának vége, és  szerverbe tökéletes lesz a 32gb-os ssd, de tévedtem, így pont amire minden összeállt, túrhatom szét a meglévő telepítést. Pontosabban ez lenne a helyzet ha windows szerverem lenne (már vagy 12x telepítettem volna újra), de mivel ez linux, viszonylag egyszerű a dolog.

1. Első körben hozzunk létre partíciókat az új lemezen (ajánlott a GParted erre a célra). Arra kell csak figyelni, hogy azonos típusúak legyenek. Nálam így nézett ki:

  • Primary – ext4
  • Extended – swap

Az új primary partíciót tegyük bootable-vá (Manage Flags – boot legyen kipipálva). Érdemes adni labelt is az új partíciónak (pl.: diskname), így könnyebb lesz megtalálni

2. Mountoljuk fel az új partíciónkat, pl. ide:  /media/diskname (szégyen gyalázat, én rá szoktam nyomni a lemez nevére, a grafikus felületen, és az mountolja jól)

3. Ha ezzel megvagyunk, akkor root-ként másoljuk át az összes fájlt:

cp -ax / /media/diskname

4. A fájlok a helyükön, javítanunk kell az fstab bejegyzéseket, itt a régi disk uuid-et ki kell cserélni az újra (a diskuuid-eket a blkid parancs segítségével tudjuk kilistázni). Az fstab értelemszerűen a /media/diskname/etc/fstab helyen van…

5. kell telepítenünk egy grub-ot, hogy legyen valami a boot sectorba (itt az sdb az új lemez).

sudo grub-install --root-directory=/media/diskname /dev/sdb

Elviekben kész vagyunk. Az új boot után a dropbox-ot újra hozzá kell rendelni az account-unkhoz, mert ő a merevlemezlemez paramétereit veszi figyelembe a kulcsképzés során, így az új lemezzel új dropbox session kulcsunk is lesz.

Ha valaki a meglévő gépe mellé szeretné az újat, akkor érdemes még pár dolgot átírni:

A rendszer neve:

nano /media/diskname/etc/hostname

Régi ssh kulcs:

rm /media/diskname/etc/ssh/ssh_host_*_key*

(az új bootolás során újra kell generálni az ssh kulcsot: dpkg-reconfigure openssh-server)

Hálózati beállítások (ha valaki stat ip-t használ)

nano /media/diskname/etc/network/interfaces

Keyboard and mouse tracking

Réges régen (egy messzi messzi galaxisban) használtam egy olyan alkalmazást, ami mérte, hogy menyit gépeltem, egerésztem, vagy csak úgy ültem a gép előtt. Gondoltam milyen jó lenne egy ilyen online alkalmazás, elvégre szeretem a statisztikákat. Kis keresgélés után rá is leltem erre:

http://whatpulse.org/

Azért nem árt ha az ember elővigyázatos, és nem telepít magának keyloggert (még szép statisztikákért se). Picit megvizsgáltam, szerintem rendben…

Ubuntu disk UUID

Ha fstab-ban szeretnénk mountolni, ajánlott használni az uuid-et. Ebben az esetben, ha átdugják a merevlemezt egy másik vezérlőbe (vagy csak az új kernel összekeveri a vezérlőket), akkor is fel tudja mountolni a rendszer a meghajtót, és mondjuk el is indul, ami nem egy hátrány egy szerver esetén.

Egy lemez uuid-jét a legegyszerűbben az alábbi módon tudhatjuk meg:


root@nas:~# blkid /dev/md1
/dev/md1: UUID="9bf2c0f8-9190-4db0-943e-e747e306a4b1" TYPE="ext4"

Excel file merge

Néha jól jönne, ha sok külön excel fájlt, egy nagy excel fájlban lehetne látni. Erre vannak mindenféle fizetős eszközök (mind lehúzás), az excel is csinál valamit, de egyik sem az igazi.

Ha programozni akarunk írhatunk rá pár nap alatt egy java programot, ha nem akarunk, akkor a lenti script segíthet…

#!/bin/sh

#environment setup: http://software.krimnet.com/xls2csv/guide-converting-xls-files-csv-with-xls2csv-ubuntu.htm

rm result.csv

cat files.txt | tr -d "\015" | while read XLS_FILE
do
if [ $XLS_FILE == "--EOF--" ]
then
break
fi

echo Processing xls $XLS_FILE
XLS_FILE_SNAME=`basename $XLS_FILE`
cat sheets.txt | tr -d "\015" | while read SHEETS
do
if [ $SHEETS == "--EOF--" ]
then
break
fi

xls2csv -x $XLS_FILE -w $SHEETS -b UTF-8 -c tempsheet.csv
cat tempsheet.csv | grep -v "Projekt azonosító" | LANG=hu_HU.UTF-8 sed "s/^.*\$/${XLS_FILE_SNAME};${SHEETS};&/" | LANG=hu_HU.UTF-8 sed "s/\./,/g" >> result.csv
rm tempsheet.csv
done
done

A files.txt fájlból olvassa a konvertálni kívánt fájlok neveit, –EOF– -ig. Pl: :
a.xls
b.xls
–EOF–

Magyar karakterek irssi alatt

Bizonyos linux-okon az irssi alatt furcsán viselkednek az ékezetes karakterek. A megváltást itt is (általában ilyen esetekben mindig) az UTF-8 jelenti.

Az alábbi 2 beállítást kell tenni:
A putty-ban be kell állítani, hogy UTF-8-at használjon:
Putty Configuration: Window - Translation - Recieved data assumed to be in which character set: UTF-8

Irssi alatt:


Q: How to make UTF-8 support work with irssi?

A: Make sure your terminal supports UTF-8 (for example, xterm -u8). If you use screen, you may have to do screen -U. And in Irssi do /SET term_charset utf-8. (for 0.8.9 and older: /SET term_type utf-8)

(forrás: http://irssi.org/documentation/faq)

Ezek után irssi-be érdemes még mondani egy /save és kész is vagyunk…

Ubuntu too many open files

Ha túl sok a megnyitott fájl (enterprise és java alkalmazások előnyben), akkor az alábbit kell tenni:

Ide kell írni a limiteket:

/etc/security/limits.conf

Az alábbi módon:

* soft nofile 65535
* hard nofile 65535

Ezek után ellenőrizhetjük a beállításunkat:

ulimit -n

Ha 1024-et ír ki a 65535 helyett, akkor annak az az oka, hogy nincs benn a megfelelő pam modul, amit az alábbi módon tudunk betenni.

/etc/pam.d/common-session

session required pam_limits.so

Levélküldés tesztelése

Manapság már nem nagy dolog olyan alkalmazást fejleszteni ami emailt tud küldeni. Ellenben fejlesztés alatt egyáltalán nem biztos, hogy szerencsés, ha a valódi felhasználók a fejlesztők viccesebbnél viccesebb tárgyú leveleit kapják kézhez (pl. szerződését díjrendezettség hiányában töröltük, stb). Ezt elkerülendő lehet mindenféle if-eket írni a kódba, de ez sajnos megváltoztatja a program működését, és ezzel a metódussal elég sok potenciális hibaforrást elrejthetünk a kódban. Célszerűbb csinálni egy saját smtp szervert, ami e leveleket fogadja, de nem küldi ki, hanem lementi egy könyvtárba.

Erre a legegyszerűbb megoldás linux alatt a fakemail nevű program, ami a phytonnal együtt jön.

Tehát a telepítés

sudo apt-get install python

Az indítás (pl. init.d-ből)

sudo su -c ‘fakemail.py –host=voji.hu –port=10025 –path=/var/samba/servers/smtp –background’ voji

A lényeg a ‘ ‘ jelek közötti rész, a su -c csak azért felel, hogy voji userként fusson a szerver.

A paraméterek:

  • host – a cím, ahol a szerver fut
  • port – port ahol hallgatózik majd az smtp szerverünk
  • path – könyvtár ahova a leveleket lementi amit a szerveren keresztül küldenek.
  • background – háttérben fusson, ne a konzolon

Mindenkinek saját dns szervert

Amennyiben az otthoni számítógépünk nem rendelkezik fix ip-címmel, sokat segíthet a DynDNS szolgáltatás. Ennek segítségével beregisztrálhatunk magunknak egy tetszőleges domain nevet (ingyen) és a szolgáltatáshoz adott kis kliens program segítségével (linux alatt ddclient apt-get-tel telepíthető) az otthoni gépünk mindig frissítheti a saját dns-éhez tartozó ip címét (tehát akkor is elérhetjük a gépünket, ha a gonosz szolgáltató más ip-t adott neki).

Tegyük fel, adott Lajos, aki szeretné a számítógépét elérni otthonról. Beregisztrálja magának a lajos.homeip.net címet. Ezek után az otthoni számítógépét mindig eléri ezen a címen, aminek nagyon örül. Ellenben ha Lajos belső hálózatot is használ, akkor két dolgot tapasztalhat:

1. Olyan szerencsés, hogy a routere támogatja a nat loopback funkciót, és ha beírja otthon, hogy lajos.homeip.net akkor minden működik

2. Nem szerencsés

A nem szerencsés esetet két féle képpen orvosolhatjuk. Ha beírjuk a hostfile-ba, hogy lajos.homeip.net az a szerver lokális ip címe (pl 192.168.2.1). Ez jó, de ha Lajos hazamegy, midnig át kell írnia a host-fájlt, ha meg elmegy otthonról midnig vissza kell írni. Lássuk be ez nem a legelegánsabb megoldás.

Másik alternatíva, hogy Lajos saját dns szervert csinál. Ez azért is hasznos, mert megismeri a DNS szerverek működését, és felépítését (persze csak nagyon felületesen) és mert lát ilyet is…

Linux alatt dns szerverre a bind nevű csomagot szokták használni, amit az alábbi módon telepíthetünk:

sudo apt-get install bind9

Ezekután már van jól működő DNS szerverünk, ami a 67-68 udp portokon üzemel már csak konfigurálni kell. A dns szerver konfigurációját az alábbi helyen találjuk: /etc/bind

Ide kell két fájlt létrehoznunk, ami alapján a dns szerver megoldja majd a név-ip és ip-név fordítást.
db.1.168.192
;
$TTL 604800
@ IN SOA localhost. lajos.homeip.net. (
28 ; Serial
604800 ; Refresh
86400 ; Retry
241920 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
2 IN PTR lajos.homeip.net.

db.homeip.net
;
$TTL 604800
@ IN SOA homeip.net. lajos.homeip.net. (
28 ; Serial
604800 ; Refresh
86400 ; Retry
241920 ; Expire
604800 ) ; Negative Cache TTL
;

@ IN NS dns1.hu.
@ IN NS dns2.hu.

@ IN A 204.13.248.119
www IN A 204.13.248.119
lajos IN A 192.168.1.2

Az db.1.168.192 nevű fájl megmondja, hogy a 192.168.1 tartományban a 2 ip cím (192.168.1.2) az nem más mint a lajos.homeip.net.

A második db.homeip.net nevű fájl pedig megmondja, hogy a homeip.net domainban a sima hivatkozás nemmás mint a homeip.net szerver neve (ezt ping homeip.net-el meg lehet tudni), és a lajos.homeip.net pedig nemmás mint a 192.168.1.2 ami a szerverünk címe…

Ezek után már csak használni kell ezeket a fájlokat, a named.conf.local fájlba fel kell venni az alábbi két sort:

include “/etc/bind/zones.rfc1918”;

zone “1.168.192.in-addr.arpa” {
type master;
file “/etc/bind/db.1.168.192”;
};

zone “homeip.net” {
type master;
file “/etc/bind/db.homeip.net”;
};

Ezek után kell egy bind újraindítás (/etc/init.d/bind9 restart), ha elrontottunk valamit arról a var/log/syslog-ban fogunk kapni infót.

Az eredményről magunk is meggyőződhetünk:

dig @localhost lajos.homeip.net

Értelemszerűen a dhcp szervernek meg kell adni, hogy a DNS szerver címe a lokális szerver (192.168.1.2) legyen.

Trac upgrade után nincs wiki editing toolbár

Kijött egy újabb LTS ubuntu release is, és frissítés után majdnem minden működött, csak a trac-ból tűnt el a toolbar (igazából az tűnt fel, hogy a wyswyg editor tűnt el, az csak később esett le, hogy egyébként is kellene ott lennie még másnak is). A napló fájl a barátunk (bár kerestem azért a hibát majdnem 1 óráig, aztán jutott eszembe, hogy csekkolni kellene), és láthatjuk is mi a baj:

2010-05-01 16:15:31,606 Trac[chrome] WARNING: File js/jquery.js not found in any of ['/usr/lib/python2.6/dist-packages/trac/htdocs']
2010-05-01 16:15:31,621 Trac[main] WARNING: HTTPNotFound: 404 Not Found (File js/jquery.js not found)

Nincs nagy trükk, itt megvan a fájl: /usr/share/pyshared/trac/htdocs/js/

Itt pedig nincs: /usr/lib/python2.6/dist-packages/trac/htdocs

A megoldás innen már elég egyértelmű:
ln -s /usr/share/pyshared/trac/htdocs/js/jquery.js /usr/lib/python2.6/dist-packages/trac/htdocs/js/jquery.js