Lifehacker és chrome kiegészítők

Néha néha felbukkan egy egy gyöngyszem a lifehacker-en, amiért megéri olvasgatni. Ilyen a Lineman Splice, vagy a Lace Lock. IT területen sok újdonságot nem szoktam találni, de azért az érdekesebb cikkeket mindig átfutom. Nem rég jelent meg egy cikk, ami a google chrome memóriahasználatát, és ennek okait taglalta. Már ezért a kijelentésért önmagában is érdemes volt elolvasni a cikket: “free RAM is useless RAM”

Viszont ebben a cikkben került említésre a The Great Suspender kiegészítő, ami nekem új volt. Ez egy nagyon jó cucc, és az én örökérvényű böngésző kiegészítők listámról még hiányzott. Azt tudja, hogy a rég nem használt tab-okat egyszerűen kidobja a memóriából, de a helyét meghagyja, így ha kell akkor bármikor visszatölthetjük a tartalmát. Kötelező darab, semmi többet nem tudok elmondani 🙂

És ha már kiegészítők, akkor itt az ideje, hogy a 2007-es Firefox-os listát frissítsem egy 2015-ös chrome-os listára:

Google Chrome Extensions:

Google Chrome Apps:

A lista a Chrome Extensions Share kiegészítővel készült.

Postfix + google apps

Google apps-ban van lehetőség SMTP Relay szerver engedélyezésére. Ez akkor jó, ha például olyan helyről szeretnénk levelet küldeni, ami nem rendelkezik Google Apps felhasználóval, például szerverekről.

Ezt a Google Apps adminisztrátori felületén lehet megtenni:

Google Apps -> Settings for Gmail -> Advanced Settings -> General Settings

SMTP relay service

Itt érdemes bekapcsolni az alábbi két opciót:

Only accept mail from the specified IP addresses – csak megadott helyekről fogadjon el leveleket

Allowed senders: Any addresses (not recommended) – onnan viszont bármilyen címről

 

Be is állítottam mindent, de a google SMTP szervere folyamatosan eldobálta a levelet, mert valamiért a postfix mindig csak a szerver nevét (pl. root@server) rakta bele a feladó mezőbe, amit a google annak ellenére sem szeret, hogy beállítottuk, hogy szeresse…

A végső megoldást az alábbi hack jelentette:

A /etc/postfix könyvtár alá létrehoztam egy sender_canonical nevű fájlt, aminek a tartalma:

/^(.*@).*$/     ${1}server.voji.hu

Módosítottam továbbá a /etc/postfix/main.cf-et:

sender_canonical_maps = regexp:/etc/postfix/sender_canonical
relayhost = smtp-relay.gmail.com:25

Ezek után már csak ki kellett generálni a sender_canonical-hoz tartozó .db fájlt:

postmap sender_canonical

valamint újrarúgni a postfix-et:

sudo postfix reload

 

És már csak egy gyors teszt volt hátra:

echo "Test mail from postfix" | mail -s "Postfix test" voji@voji.hu

 

Mindeközben a /var/log/mail.log fájlban:

Sep 10 14:44:20 server postfix/smtp[11752]: 98D866567C3: to=<voji@voji.hu>, relay=smtp-relay.gmail.com[173.194.65.28]:25, delay=0.7, delays=0.34/0/0.26/0.09, dsn=2.0.0, status=sent (250 2.0.0 OK 1410353060 q15sm45749wij.3 – gsmtp)

Sep 10 14:44:20 adsrv2 postfix/qmgr[11744]: 98D866567C3: removed


Tadaaam.

 

Ui: azt, hogy a postfix által küldött levelek normális feladóval rendelkezzenek biztos el lehet érni ennél kultúráltabb módon  is, de egyenlőre ennél jobb megoldást nem találtam (pedig próbálkoztam midnenféle myorigin = /etc/mailname-el és társaival is)

 

 

Rar fájlok kitömörítése

find . -name "*.rar" -exec unrar x '{}' \;

Let me explain what this does. 
"find ." - will find files within the current directory and any subdirectories
"-name "*.rar" - will only find *.rar files
"-exec " - will perform an external command on the results found by the "find" command. 
"unrar x" - is the command to extract the rar archives
"'{}'" - tells find to append the found result to the end of the exec'd command.
"\;" - signifies the end of the exec'd command.  forrás

Plex – Videót a világnak

Réges régen egy messzi messzi galaxisban… még másolgattam a filmeket, mindenféle eszközökre, mindenféle formátumban, és állandóan komoly fejtörést okozott, hogy mit másoltam fel, mit láttam már, és mik azok a tartalmak, amik ezen másolgatások közben elvesztek, és soha többé nem kerültek elő többet.

Azt gondoltam, kell lennie erre ennél korrektebb megoldásnak is, mert hihetetlen, hogy ezt emberek tömegével így csinálják. Elég sok szabványt, és még több implementációt találtam, de végül is a Plex mellett döntöttem. Nem ez a legokosabb lejátszó, és valószínű nem is ez a legjobb, de egyben van, működik, és folyamatosan fejlesztik.

Mivel többen nem hallottak még róla, én pedig már így is túl sokszor meséltem el, túl sok mindenkinek, gondoltam inkább leírom, hogy mi is ez, és mire jó.

A Plex mint olyan két fő részből áll. A plex média szerver, ami a tartalmakat szolgáltatja a másik komponens felé, ami maga a plex média player ami ezeket a tartalmakat tudja lejátszani. A szerver komponens nem csak szolgáltatja a tartalmakat, hanem azokhoz mindenféle metaadatot is letöltöget innen onnan, így a média könyvtárunkban jó eséllyel megjelennek a filmekhez, sorozatokhoz tartozó borítók, leírások, főcímzenék, és minden ilyen nyalánkság (itt fontos megjegyezni, hogy az esélyeket nagyban növeli a helyesen megválasztott könyvtár és fájl nevek). És ami még fontos, nyilvántartja azt is, mit néztünk meg, mit hagytunk félbe, és hol hagytuk félbe. Ha pl. a vonaton belenézek egy filmbe, otthon a tv-n folytathatom ha úgy tartja kedvem onnan, ahol abbahagytam. Ha megnézek egy epizódot a sorozatból, akkor látom, hogy miket néztem meg, és mi az amit még nem láttam. Ha pedig kevés lenne a sávszélesség (pl. mobilnet miatt) akkor a szerver újra is tudja kódolni a tartalmakat, hogy akadás nélkül le lehessen játszani azzal a sávszélességgel ami rendelkezésre áll.

A player egy kúltúrált médialejátszó (tv-re optimalizálva), aminek a segítségével lehet válogatni a szerveren található tartalmak között. Ha egy plex lejátszót elindítunk, akkor a lokális hálózaton alapból észreveszi az ott található plex szervereket.

A plexhez lehet csinálni egy online accountot (itt) amit ha megadunk a szerveren, és a lejátszón is, akkor bárhonnan elérhetjük a tartalmainkat az internetről. Sőt, ismerőseink a plex account ismeretében megoszthatják velünk a saját plex szerverüket, tehát amit ők kiraknak, azt mi is megnézhetjük.

A Plex szerver, és a desktop lejátszó ingyenes, a mobil kliensekért fizetni kell nagyságrendileg 5 dollárt.

http://www.plexapp.com/

Linux es a media

Egy kissebb hardware upgrade utan (intel d2700mud) ujra mukodik a szerverem.

Mar mukodik rajta a letfontossagu dolgok, mint a plex media server, az openvpn, stb.

Viszont komoly problemat jelntett, hogy a plex szervernek symlinkelt zenek kozott akadtak flac fajok, amit bizonyos eszkozok (pl csoda android) nem tamogat.

El is kezdtem konvertalni a flac fajlokat mp3-ba, de a konvertalas alatt ratalaltam az mp3fs-re.

Az mp3fs egy olyan read only virtualis fajlrendszer, aminek egyik felen a flac fajlok vannak, a masik felen pedig mp3-nak mutatott flac fajlok, ha megnyitunk egy ilyen filet akkor lekonvertalja nekunk runtime…

Bovebb info itt.

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"

Javadoc generálás statikus adatokkal

A javadoc fontos, főleg ha publikus szolgáltatásokat készítünk. Néha viszont szükség van olyan algoritmus alapján előállított adatokra, amiket nem esik túl jól kézzel beírni…

Ilyenkor nyújthat nagy segítséget egy két shell script, amikkel az ilyen módosítások elég hatékonyan elvégezhetőek.
A scriptet nem hiszem, hogy bárki is tudja majd használni ebben a formában, de kiindulásnak (és nekem memó-nak) még jól jöhet…

A lenti dolog mit is csinál:
– kigyűjti az összes /services/ könyvtár alatti package-info.java-t
– kikalkulálja, hogy mi lesz a kiajánlott szolgáltatás neve (pl TestWebSzolgService.java – TestWebSzolg)
– csinál belőle egy javadoc szöveget, amit beszúr az összes package-info első sorába

Tadamm… Pár óra szolgai gépeléstől megint megmentett a bash.

#!/bin/sh
find . -name "package-info.java" | grep "/services/" | while read line;
do
#teljes eleres
PACKAGE_INFO_PATH=$line
#csak a konyvtar ahol a packageinfo van
CURR_DIR=${PACKAGE_INFO_PATH%/*}
#a valamiService.java fajl teljes elerese (de mar Service.java nelkul)
CURR_SERVICE_PATH=`find $CURR_DIR -name "*?Service.java" | sed 's/Service.java//'`
#csak a szolgaltatas neve
CURR_SERVICE_NAME=${CURR_SERVICE_PATH##*/}

echo $PACKAGE_INFO_PATH
echo $CURR_DIR
echo $CURR_SERVICE_NAME

FIRST_LINE="/** WSDL: https://webservice.aaa.hu/da/hs/services/${CURR_SERVICE_NAME}*/"

sed -i 1i"$FIRST_LINE" $PACKAGE_INFO_PATH
done

SCP scriptből

Normál esetben az scp-t kulcsokkal használjuk (mint minden mást), és nincs szükség jelszóra… Bizonyos esetekben erre nincs mód, és ilyenkor problémát okozhat a jelszóbekérés kezelése. A példa értelemszerűen nem csak scp-re működik, gyakorlatilag minden adatbekérő parancs wrap-elhető expect-el

#!/usr/bin/expect -f

eval spawn scp felhasznalonevem@[lindex $argv 0]:[lindex $argv 1] [lindex $argv 2]

expect {
"password:" {
send "titkosjelszavam\n"
} "(yes/no)?" {
send "yes\n"
} eof {
exit
}
}

expect "$ $"