kézzel gzippelt tartalom

A mod_gzip és a hasonló on-the-fly tartalomtömörítéssel az a gondom, hogy a processzort eszi (ha nem is nagyon de azért jobban mintha nem tenné). Statikus tartalom esetén is jó ha sávszélességet spórolunk. Ez a megoldás pont ezt a tartalomtípust veszi célba. Ha létezik tömörítve az eredeti helyett azt szolgálja ki, így spórolva a processzoridővel és a sávszélességgel. A megoldás bővíthető a végtelenségig bármilyen fájltípusra.

AddType image/jpg jpg jpgz
AddEncoding gzip jpgz

RewriteEngine on
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_URI} ^(.*).jpg$
RewriteCond %{DOCUMENT_ROOT}%{SCRIPT_FILENAME}.jpgz -f
RewriteRule ^(.*)$ $1.jpgz [L]

mj: ModRewrite debuggolás.
RewriteLog “logpath.log”
RewriteLogLevel 9

ledprogram, és a frissítés

Várnagy György minden frissítés után belefut a hibába, hogy a ledvillogtató programom a /sys mappa struktúrájának változása miatt elromlik. És minden alkalommal lelkiismeretesen el is küldi a megoldást. Ím az utolsó:

A trükk az, hogy az elérési út megváltozott és ezt kell kijavítani az /etc/rc.local-ban és a szkriptedben.

A régi elérési út :
/sys/devices/virtual/leds/asus:mail/brightness

Az új pedig :
/sys/devices/virtual/leds/asus::mail/brightness

Az utóbbiban van egy plusz kettőspont a mail előtt.

A Mail Notification program is frissült már korábban. A frissítés óta a beállító grafikus felületen nincsenek meg a mezők amibe be lehetne írni, hogy mi történjen, ha új mail érkezett és ha a mailt már elolvasták. Én ezt úgy oldottam meg, hogy a régi verzió beállításait tartalmazó rejtett fájlokat átmásoltam az új verziójú program rejtett könyvtárába. Így az új Mail Notification program továbbra is indítja a led_on és exit_led_on szkripteket.

Ha az általam leírt megoldás nálad is működik és arra érdemesnek tartod, kitehetnéd az oldaladra hátha mást is érdekel a megoldás.

Gyuri

Köszi! 🙂

raid1 és 3 merevlemez

Cél: szoftveres raid1 (tükrözés) megoldása.
Adott hardver:

  • 1db 40 gigás merevlemez, rajta a hardy rendszerrel. (sda)
  • 2db 160 gigás merevlemez, ezekre kerül a raid és a rendszer kissé átméretezve. (sdb és sdc)

Következők történtek első nekifutásra:
Itthon csak 6.10-es ubuntu cd-t találtam, de mivel elméletileg teljesen mindegy milyen verzióval csinálom, így azt tettem be (persz a gparted miatt nem teljesen mindegy). Gparteddel létrehoztam az egyik új merevlemezen a partíciókat és a meglévőket átmásoltam/átméreteztem. A grub-ot az fstabot és a grub menu.lst-t beállítottam majd megnéztem, hogy betölt-e a rendszer. Itt kezdődtek a bonyodalmak. Egy érdekes ata bugba futottam ami az eredeti hardy telepítést érinti. Bejegyzések alapján azt javasolták hogy frissítsem, intrepidet már nem érinti a hiba. Ezt már nem akartam a régi live cd-ről megcsinálni, ezért leszedtem egy intrepid-et. Viszont itthon csak dvd van, munkahelyen van cd. K3b probléma nélkül kiírta a cd imaget dvd-re. Végre valami ami működik. Intrepid betölt, a root és a boot partíciókat felcsatoltam, majd chroot-olva a környezetet jött a dist upgrade. Probléma nélkül. Feltettem az mdadm-ot, majd létrehoztam a raid tömböket. Ekkor követtem el a végzetes hibát, nem hoztam létre a fájlrendszert a raiden is, hanem rögtön megkezdtem a szinkronizálást. Az mdadm viszont nem hoz létre superblockot és betöltéskor az fsck be is szólt hogy ez így nem lesz jó… Éjjel egy. S láttam hogy mindez nem jó. Alvás. Ma új lappal, zsibbadó arcszerkezettel (pofánrúgott a fogtündér délelőtt), megnézzük hogyan is kellett volna tegnap…

Raid vs Connor második menet:
Intrepid korong be. Partíciók legyalulása. Új szerkezet létrehozása. Így néz ki per winyó:


/dev/sdb5 /boot: 2 giga
/dev/sdb6 swap: 3 giga
/dev/sdb7 /root: 20 giga
/dev/sdb8 /home: maradék

Ugyan így az sdc is. Mindegyik raid flag-et, a /boot boot flag-et kap.
Hozzuk létre a raid-eket. Ehhez mdadm kell majd ami alapból nincs fenn, tehát feltesszük:
apt-get install mdadm


boot:
mdadm --create /dev/md0 --level=1 --raid-disks=2 /dev/sdb5 /dev/sdc5
swap:
mdadm --create /dev/md1 --level=1 --raid-disks=2 /dev/sdb6 /dev/sdc6
root:
mdadm --create /dev/md2 --level=1 --raid-disks=2 /dev/sdb7 /dev/sdc7
home:
mdadm --create /dev/md3 --level=1 --raid-disks=2 /dev/sdb8 /dev/sdc8

A háttérben megkezdődik a resync ezt várjuk meg (avagy nézzük a macskát ahogy játszik az mdstat-al).

watch cat /proc/mdstat

Hozzuk létre a fájlrendszert a raiden:

mkfs.ext2 /dev/md0
mkswap /dev/md1
mkfs.ext3 /dev/md2
mkfs.ext3 /dev/md3

Most pedig mindent szépen átpakolunk a régiről az újra. Ehhez felcsatolunk mindent és létrehozzuk a szükséges struktúrát:


mkdir /mnt/new /mnt/old
mount -t ext3 /dev/md2 /mnt/new
mount /dev/sda6 /mnt/old
mount /dev/sda7 /mnt/old/home

mkdir /mnt/new/home /mnt/new/boot
mount -t ext2 /dev/md0 /mnt/new/boot
mount -t ext3 /dev/md3 /mnt/new/home

Kezdődhet a másolgatás:


cd new
tar -C ../old -clspf - . | tar -xlspvf -
cd ..

umount /mnt/old/home
umount /mnt/old

Mivel nálam frissítés kell (hardy nem bootolna), ezért ezt most elvégzem:


chroot /mnt/new
mount -t proc proc /proc
cat /etc/apt/sources.list | sed s/hardy/intrepid/ > new; mv new /etc/apt/sources.list
apt-get update
apt-get dist-upgrade

Újabb szünet.
Ezek részek megint általánosak, mindenki számára el kell végezni. Írjuk át a szükséges fájlokat:

  • vim new/etc/fstab
  • vim new/boot/grub/menu.lst

    root=/dev/md2 md1,/dev/sda7,/dev/sdb7
  • vim new/etc/initramfs-tools/modules

    md
    raid1

Fstabnál md esetén uuid helyett /dev/md[0-9] formátumban adjuk meg, grubnál a root-t kell átírni a megfelelőre. Esetemben /dev/md2. Az initramfs-tools modules fájlába md és raid1 sorok kellenek, hiszen szükséges hogy az initramfs tartalmazza ezeket a kernelmodulokat.

Megnézzük, hogy a grub megtalálja-e amit kell:


grub

root (hd1,4)
setup (hd1)

root (hd2,4)
setup (hd2)

Elméletileg mindent megcsináltunk, leválaszthatjuk a régi merevlemezt. Gép kikapcs, régi winyó leköt, gép elindít. Újra a livecd-t indítsuk. Hozzuk létre a tömböket újra. Mivel a winchester leválasztása után már átrendeződtek, így ennek megfelelően paraméterezzük:

mdadm --create /dev/md0 --level=1 --raid-disks=2 /dev/sda5 /dev/sdb5
mdadm --create /dev/md1 --level=1 --raid-disks=2 /dev/sda6 /dev/sdb6
mdadm --create /dev/md2 --level=1 --raid-disks=2 /dev/sda7 /dev/sdb7
mdadm --create /dev/md3 --level=1 --raid-disks=2 /dev/sda8 /dev/sdb8

Csatoljuk fel a boot és a root partíciókat majd lépjünk be a chroot-ba. Erre azért van szükség mert az update-initramfs parancs livecd-n nem fut, ami meg fut az meg nem úgy fut ahogy kéne. Hozzáadjuk az mdadm-hoz, az elkészített tömböket és újrageneráljuk az initramfs-t (initramfs csomagolja az mdadm.conf-ot is, ezért szükséges, hogy a tömb benne legyen!!!):
mdadm --detail --scan >> /mnt/etc/mdadm/mdadm.conf
update-initramfs -u

Reboot és betöltés a merevlemeről.

Megjegyzések:

  • mdadm: metadata format 00.90 unknown, ignored.

    /etc/mdadm/mdadm.conf fájlban a metadata=00.90 -t cseréljük le metadata=0.90 -re

  • Talán egyszerűbben is létre lehet hozni a rendszert. Különös tekintettel a második “tömblétrehozásra”. A neten leginkább olyan megoldások vannak amiknél a felét hozzák létre, arról töltenek be majd hozzácsapják a másik felét. Ez még tesztelést igényel részemről. A másik elképzelés aminek nem tudtam utánajárni, hogy uuid-t adok meg a régi típusú megadás helyett. Bár az initramfs pillanatában még ahogy elnéztem nem létezik a /dev/disk/by-uuid, így ez az elképzelés necces.
  • id változtatása parancssorból:
    sfdisk --change-id /dev/sdb 1 fd
  • Ha nem lenne éles irodai rendszer akkor most jönne az a játék hogy lehúzom az egyiket és úgy bootolok.

Következő (számomra) érdekes dolog a virtualbox xp partíció átméretezése.

partíció uuid-je

Egy adott partíció UUID-jét az fstab számára a vol_id paranccsal lehet megkapni:

sudo vol_id -u /dev/neve

Variációk egy témára:

for i in $(mount | grep ^/dev.*ext | awk '{ print $1 }'); do echo -n "$i: "; vol_id -u $i; done

for i in $(fdisk -l | grep '/dev.*[832].*Linux' | awk '{ print $1 }'); do echo -n "$i: "; vol_id -u $i; done

for i in $(fdisk -l | grep '/dev.*[832].*Linux' | awk '{ print $1 }')
do
  uuid=$(vol_id -u $i)
  cat /etc/fstab | sed "s|^$i|UUID=$uuid|" > /etc/fstab.tmp
  mv /etc/fstab.tmp /etc/fstab
done

</bloghelp>

több fájl figyelése tail-al

Fejlesztés közben sokszor van hogy több fájt figyelek egyszerre (access log, apache error és/vagy php error log, debug logok stb). A minap véletlenül jöttem rá hogy a tail -f parancsnak több fájlt is meg lehet adni, ilyenkor szépen egymás alá listázza őket. Ha valamelyikbe új sor kerül arról a fájl névvel együtt informál.

(mj: Ha kicsi lenne a gnome terminál ctrl+ és ctrl- gombokkal lehet változtatni a felbontást (?))

odt2png

Az unoconv és az imagemagick csomagok segítségével egészen egyszerűen lehet ezt a problémát megoldani. Ím a script ami elvégzi az átalakítást.


#!/bin/sh

if [ ! -f $1 ]; then exit; fi
unoconv -f pdf $1
convert -density 300x300 $(basename $1 odt)pdf $(basename $1 odt)png
rm $(basename $1 odt)pdf

emesene login error

Tegnap óta az emesene 1.0 nem engedett be, visszadobott “Server error 911” üzenettel. Pidgin viszont minden további nélkül beengedett. Átmeneti megoldást az jelentette hogy megváltoztattam az a-zA-Z0-9 jelszavamat, a-zA-Z jelszóra. Most beenged.

mail led

Hardy-n a mail ledes megoldást két dologgal kell kiegészíteni:

/etc/rc.local -ba beírni exit elé:

chown userneve:usergroupja /sys/devices/virtual/leds/asus:mail/brightness

A villogtatást a /sys/devices/virtual/leds/asus:mail/brightness -be való 0, 1 beírása végzi.

A T-mobile, a 3g és a E220 HSDPA Modem esete…

… Ubuntu-n.

Végre sikerült kölcsönkérni egy, a címben megnevezett modemet, amit kis bütykölés után be is tudtam állítani.
A következő volt a telepítés nálam:

Csatlakoztatás után az usb háttértár része feljött jelezvén, hogy észlelte a csatlakoztatást. Ezt egy lsusb-vel még meg is erősítettem, melynek a kimenete a következőképpen nézett ki:

Bus 002 Device 002: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem

/etc/modules fájlhoz hozzáfűztem ezt a két sort:

options usbserial vendor=0x12d1 product=0x1003
post-install usbcore modprobe usbserial

Gép restart (elég lenne a modulokat kiszedni majd újra betölteni, de most lusta üzemmódban üzemelek). Újraindulás után azért győződjünk meg arról, hogy a /dev/ttyUSB0 létrejött.

Rendszer -> Adminisztráció -> Hálózat, Modem beállítása

http://workshop.connor.hu/tmp/screen_20080126211148.png (jelszó web)
http://workshop.connor.hu/tmp/screen_20080126211156.png
http://workshop.connor.hu/tmp/screen_20080126211204.png

Utolsó fül beállításait jóérzés és a felhasználói igények szerint tessék.
Majd csatlakozás és ha minden jól megy a kék led felvillan a modemen.

Akitől kölcsönkértem a modemet mutogatta a wines felületet amit a Tcégnél írtak és volt benne egy statisztika ami azt mutatta (volna), hogy mennyi volt az adott hónapban a forgalom. Ez egy jó dolog lenne ha működne, viszont nem működött.
Kicsit bogarásztam a témában hogy mit lehetne alkotni linuxon és erre jutottam:
/etc/ppp/ip-down.d mappába egy 01stat-save fájlt létrehoztam, majd futtatás joggal láttam el.
A tartalma pedig ez lett:

#!/bin/sh

bytes=$(ifconfig ppp0 | grep RX\ by)

RX=$(echo $bytes | cut -d: -f2 | awk '{ print $1 }')
TX=$(echo $bytes | cut -d: -f3 | awk '{ print $1 }')

DATE=$(date "+%Y%m%d")

echo $DATE $RX $TX >> /tmp/ppp-transferstat

Persze ehhez még valami jól kinéző grafikonos cucc kéne ami összesíti a számokat mert így kicsit fejszámolós a téma 🙂
De kezdetnek legalább működik. (nem úgy mint a hivatalos cucc :))
Ha szerény akarnék lenni, azt mondanám: connor t-mobil 1:0 😉