Ez egy Kecs.es blog webfejlesztési ötletek, tanácsok, észrevételek

19feb/120

iOmega StorCenter ix2-200 magyar ékezetes karakterek kezelése WinSCP alatt

Ha szeretnél az iOmega StorCenter ix2-200 tárolóhoz biztonságosan kapcsolódni, akkor nagy valószínűséggel te is a beépített SFTP lehetőséget fogod használni. Ezzel viszont az a gond, hogy a WinSCP nem kezeli le a magyar ékezetes könyvtárneveket. Vagyis lekezeli, csak alapból hibásan. Mindenféle kriksz-kraksz jelenik meg helyettük. Ezt könnyen lehet orvosolni, ha a WinSCP Login ablakban az Environment (környezet) alatt az UTF-8 encoding for filenames (fájlnevek UTF-8 kódolásban) lehetőséget nem Auto értéken hagyjuk, hanem kézzel biztosítjuk, hogy bekapcsolva legyen. Tehát az On (Be) értékre állítjuk!

Ezek után a magyar ékezetes fájl és könyvtárnevek máris tökéletesen megjelennek!

15jan/120

Hogyan töltsünk le egy teljes weboldalt wget segítségével

wget --recursive --page-requisites --html-extension --convert-links --restrict-file-names=windows --limit-rate=500k --user-agent="Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1" --output-file download.log --domains example.com http://www.example.com

Az utasítássor értelmezése:

--recursive: A teljes weboldalt töltse le, minden hivatkozást bejárva
--page-requisites: Minden elemet töltsön le ami szükséges az oldalhoz (képek, CSS, stb.)
--html-extension: Minden lapot alakítson át .html kiterjesztésre, így bármelyik lap visszanézhető
--convert-links: Átalakítja a linkeket, hogy offline is lehessen böngészni
--restrict-file-names=windows: Az átalakítást windows fájlrendszerrel kompatibilis módon végzi el
--limit-rate=500k: A letöltési sebességet 500Kb/s-re korlátozza a túlterhelés elkerülése miatt
--user-agent="Mozilla/5.0...": Beállítható a User Agent, így normál böngészésként szimulálható a letöltés
--output-file download.log: A megadott napló állományba rögzíti a letöltés minden mozzanatát
--domains example.com: Megadható, hogy csak ebből a tartományból kövesse a hivatkozásokat

Tagged as: No Comments
7jan/120

iOmega StorCenter ix2-200 NFS Share csatolása routeren keresztül Citrix XenServer 6.0 kiszolgálóra

A feladat nem tűnik bonyolultnak, viszont abban a pillanatban, hogy a két eszköz közé egy routert teszünk, máris nem olyan barátságos, hiszen a változó RPC (rpc.mountd, rpc.statd, rpc.rquotad) portokat fixálni kell. Valamint az sem elhanyagolható tényező, hogy a megosztásunk a lehetőségekhez mérten a legbiztonságosabb legyen. Tehát a cikk erre is megpróbál majd kitérni.

NFS Share létrehozása az iOmega StorCenter ix2-200 eszközön:

  1. Lépjünk be a webfelületre (http://<IPofNAS>)
  2. Kapcsoljuk be az NFS megosztását (Network -> Protocols ->NFS = ON)
  3. Hozzunk létre egy új megosztást (Storage -> Shares ->Add a Share)
  4. Mivel még nem kapcsoltuk be a Security-t emiatt jelenleg az összes megosztás elérhető NFS protokoll segítségével
  5. Az NFS nagyon sok portot használ, amelyeket random választ ki a port mapper. Ez nekünk nem jó, mert egy cím fordított (NAT) hálózaton keresztül szeretnénk elérhetővé tenni az NFS megosztást. Emiatt kell a portmaper-t átkonfigurálni. Ehhez mindenképp SSH hozzáférésre lesz szükségünk, amelyet már leírtam, hogyan szerezhetünk meg. Ha beléptünk, akkor az 'rpcinfo -p' parancs segítségével állapíthatjuk meg, hogy jelenleg a mely portokon hallgatnak az RPC szolgáltatások, amelyeket át kell állítani.Az átállításhoz az következő parancsok lesznek segítségünkre:
    - rpc.mountd -p <port>
    - rpc.rquotad -p <port>
    - rpc.statd -p <port>

    Ezzel csak annyi a gond, hogy a következő újraindításig jegyzi meg a beállítást, tehát nem valami életképes a megoldás. Sajnálatos módon, a hivatalos konfigurációs állomány a /etc/sysconfig/nfs nem létezik és ha kézzel létrehozzuk, sem használja a rendszer így másik megoldáshoz kell folyamodnunk. Gondoltam, hogy akkor meglovagolom a rendszerindítást. Először is ezért le kell menteni a parancsokat egy fájlba:
    cat <<EOF > /etc/rc.nfs
    rpc.mountd -p <port>
    rpc.rquotad -p <port>
    rpc.statd -p <port>
    EOF

  6. Ez az ötletem sem nyert, mert hiába vannak meg a /etc/rc.local és /etc/rc<x>.d/ könyvtárak, akkor sem futott le a rendszerindítás után a parancsom...  Csak két megoldást sikerült kitalálnom, amelyek közül az egyik rosszabb mint a másik, de ez van. Nem valami szép megoldás, de legalább működnek. Az első, hogy eltávolítjuk a merevlemezeket és egy linux alapú rendszerre felcsatoljuk, ugyanis az md0 kötet rejti a /mnt/apps könyvtárat, amely tartalmazza a rendszerpartíciót, ahol módosítani kellene a betöltést. De ezt nem tudjuk az iOmega eszközben megtenni, mivel a partíció read only és újracsatolni sem tudjuk, mert device is busy. Ehhez egy leírást itt találtok.Mivel én nem szeretem megbontani az eszközt és piszkálni a rendszer, ami garancia vesztéshez vezethet, így inkább egy másik megoldást kerestem a problémára, ami talán egy picit humánusabb. Újraindítottam a rendszert és megnéztem, hogy mi zajlik le a boot folyamat során. Hátha találok egy olyan állományt, ami később inicializálódik mint az RPC (hiszen csak ezután lehet a portokat átállítani) és az az állomány talán egy szerkeszthető  partíción lesz. Ennek megállapításához a '/var/log/messages' állományt használtam. meg is találtam benne, hogy az RPC inicializálódása után az egyetlen folyamat ami elindul még az a stls_all.sh állomány. Ezt meg is kerestem, hol található:

    find / -name 'stls_all.sh' 2>/dev/null

    Megtaláltam, hogy az otthona a  /mnt/system/opt/apps/axis/stls/stls_dist/bin/ könyvtárban leledzik.

    Így már gyorsan módosítható is a fájl. Először az állomány legvégén hívtam meg a beállításomat, de rá kellett jönnöm, hogy korábban kilép a szkript, így ott nem hajtódik végre. Emiatt a legelejére betettem, hogy /etc/rc.nfs.
    Tehát most már minden rendszerindításnál meghívásra kerül az állományom, és az összes szolgáltatás már fix porton hallgat. Így képes leszek a port-forwarding konfigurálásra a routeren.

  7. Kapcsoljuk be a Security-t hogy tényleg csak azt osszuk meg amit szeretnénk és kontrollálni tudjuk azt, ki férhet hozzá a megosztáshoz. Ehhez navigáljunk a System -> Security felületre és kapcsoljuk be (ON). Adjuk meg az rendszergazdai fiók nevét valamint a jelszavát. Javaslom, hogy a titkosítást is pipáljuk be.
  8. Hozzunk létre a rendszerünk számára a megfelelő felhasználói accountokat. (Common -> Users)
  9. A megosztásnál tiltsuk meg a publikus megosztást. Ehhez navigáljunk a Storage -> Shares alá, ahol válasszuk ki a megosztást és az Access Permissions alatt az Everyone user read és write jogán vonjuk meg.
  10. Engedélyezzük, hogy a megosztáshoz csak és kizárólag a Citrix XenServer férhessen hozzá. Ehhez maradjunk ahol voltunk, csak az Access Permissions alatt található NFS blokkot válasszuk ki. Itt kattintsunk az Add an NFS Rule gombra. A Hostname mezőbe pedig beírható, hogy mely állomásokról engedélyezzük a hozzáférést. A minta lehet IP vagy domain, de akár egy teljes címtartomány, ha <IP>/<MASZK> módban írjuk le. A rendszer elfogadja a teljes 255.255.255.0 maszkot illetve a /24 formát is.
  11. Opcionális észrevétel, ha több megosztást is használunk, akkor mindenhol tiltsuk le a hozzáférést az Everyone felhasználónak, ugyanis ha az bármelyik megosztás esetében bent marad, akkor az távolról NFS segítségével szabadon felcsatolható. Valamint jelen pillanatban a megosztást lokálisan nem lehet elérni, mert nincs senkinek sem joga hozzá. Így érdemes egy felhasználót / csoportot hozzáadni az Access Permissions alatt, aki lokálisan is képes a Repository-t szerkeszteni.
  12. Az NFS szervert állítsuk be, hogy minden felhasználót kezeljen vendégként, azaz ne legyen teljes hozzáférése. Ehhez navigáljunk a Network -> Protocols alá, majd az NFS mellett található fogaskerékre kattintsunk, amellyel lekérhető a beállítása (settings). Itt pedig válasszuk ki a 'Treat client users as guest (all_squash)' lehetőséget.

NFS Port-Forwarding konfigurálása routeren:

  1. Jelentkezz be a routered admin felületén
  2. Keresd meg a port-forwarding opciót, vagy a portrange-forwarding lehetőséget, ha van
  3. Állítsd be a portokat:
    - 111 TCP & UDP -> IPofNAS (portmap)
    - 2049  TCP & UDP -> IPofNAS (NFS)
    - TCP & UDP RPC.Mountd -> IPofNAS
    - TCP & UDP RPC.Statd-> IPofNAS
    - UDP RPC.Rquotad -> IPofNASSzemély szerint javaslom, hogy az RPC portokat 2050-2052 közé állítsd be, mert akkor az NFS portal együtt, mint portrange forwarding lehet beállítani, így 1 db bejegyzéssel leírható, a normális 4db helyett.
  4. Hogy kívülről is hozzá tudjunk férni hálózatunkhoz, szükségünk lesz egy FIX IP címre. Ha ilyet nem tudunk / nek akarunk bérelni a szolgáltatótól, akkor pedig a routeren egy DDNS accountot kell készíteni. Ennek menetét nem írom le, de javaslom a dyndns.org használatát.

NFS Share csatolása a Citrix XenServer 6.0 szerveren:

  1. Csatlakozzunk a szerverhez / poolhoz a XenCenter segítségével.
  2. Hozzunk létre egy új Storage-t (Storage tab -> New SR)
  3. A varázsló segítségével adjuk meg, milyen storage-ot szeretnénk csatolni (ISO Library or NFS VHD)
  4. Adjunk nevet a megosztásnak.
  5. Majd a Location résznél a megosztás elérhetőségét kell megadni. Ez két részből áll. Első a szerver elérhetősége IP címmel vagy domain névvel. A második az NFS megosztás elérhetősége a szerveren.
    <PublicIPofNAS>:<NFSLocation>
    Az IP címet vagy tudjuk, vagy dyndns segítségével naprakészen tartjuk. Az NFS megosztás helyét pedig az iOmega eszköz pontosan megadja, csak navigáljunk a webes felületen a Storage -> Shares alá. Itt válasszuk ki a megosztásunk nevét, majd alatta lesz egy NFS block, amelyre ha kattintunk, előjön a megosztás helye.
    Locaton:<NFSLocation>
  6. A megszerzett információkkal sikeresen csatolható az NFS megosztás.
6jan/120

Citrix XenServer 5.6 SP2 frissítése 6.0 kiadásra

Ez a post is a szerver üzemeltetőknek kedvez, de ez van :)

Minap megpróbáltam frissíteni egy Citrix XenServer 5.6 SP2 kiadást a 6.0 verzióra, mondván vannak benne olyan új funkciók amelyeket ki tudnék alkalmazni. Majd amikor elkezdtem keresni a frissítést jöttem rá, hogy ez nem a megszokott töltsd le a .xsupdate állományt, hanem annál egy kicsit bonyolultabb.

Nézzük sorra, mit kell csinálni, hogy te is sikerrel járj:

  1. Amennyiben csak 1 hostod van, akkor állítsd le vagy hibernáld az összes virtuális gépet. Amennyiben több és pool-ba kapcsoltad őket, akkor a XenMotion elvileg megoldja hogy folyamatosan átkapcsolja egy aktív node-ra a virtuális gépeket ameddig az aktuális host frissít.
  2. Készíts mentést minden virtuális gépről (biztos ami biztos).
  3. Töltsd le a XenCenter 6.0 Windows Management Console alkalmazást a www.citrix.com oldalról.
  4. Csatlakozz a szerverhez vagy pool-hoz, majd a Tools menüpont alól válaszd ki a Rolling Pool Update varázslót.
  5. Válaszd ki a poolt vagy a hostot.
  6. Határozd meg a frissítés módját. Ami lehet automatikus vagy manuális. Személy szerint automatikussal végeztem el.
  7. A következő lapon futtassuk le a tesztet, ha minden rendben van akkor indítható a frissítés. Ha nem akkor a hibaüzenet alapján kezdjük meg az elhárítást. Nálam csak egy patch-et kellett feltelepíteni.
  8. Adjuk meg a telepítés forrását. Ezt lehet NFS/FTP/HTTP. Gyakorlatilag ez annyit jelent, hogy a XenServer-6.0.0-install-cd.iso lemez tartalmát a korábban említett 3 protokoll segítségével a hálózaton keresztül elérhetővé kell tenni.
  9. Ha mindent jól csináltunk a szerver sikeresen frissíti magát 6.0 verzióra.
  10. Ellenőrizzük a szerver verzióját, a General fül alatt található Version details boxban. A XenServer version: 6.0 értéket kell viszontlátni!
1jan/120

IE6 float és a margin bug

Tudom, hogy az IE6 halott és már el is temették. Sőt a jelenlegi kereskedelmi honlapokon amelyeket üzemeltetünk az IE6 előfordulása aránya kisebb mint 1%, de akkor is előfordulhat, hogy valaki egy olyan speciális környezetre kell, hogy optimalizáljon ahol még mindig IE6 a menő.

Ha ilyennel feladattal találkozol, akkor ez a post igen hasznos lesz számodra. Ismeretes ugyanis, ha IE6 alatt egy elemet float:left tulajdonsággal látunk el, akkor valami miatt a margint megduplázza a böngésző. Ezt nevezzük IE6 floating bug-nak. Ennek kivédésére a régebbi és általam ismert módszer az IE6-ra optimalizált CSS volt (minden úsztatott elem margin értéke az eredeti fele), azaz feltételhez kötött stíluslapot használtunk:

<!--[if IE 6]>
<style type="text/css" rel="stylesheet" media="screen" href="theme.ie6.css" />
<![endif]-->

Ezzel szemben ma egy új és sokkal egyszerűbb megoldást találtam. Egyszerűn az úsztatandó elemnek meg kell adni, hogy innentől legyen inline elem. A modern böngészőkben ennek semmi hatása, viszont IE6 esetén megjavítja a box modellt!
.float {
  float: left;
  display: inline;
}

1jan/120

PHP osztályok egységtesztelése

A weblabor oldalán találtam a következő cikksorozatot, ami szerintem igen hasznos. A PHP osztályok egységteszteléséről szól. Ez egy fontos és kicsit elhanyagolt témakör, így gondoltam megosztom itt is. Hátha sokkal jobban elterjed.

A cikket nem írom le újra, mert jelenleg semmivel sem tudnám kibővíteni az írást. Így most csak meghivatkozom a leírásokat, remélve, hogy a weblaborral nem történik semmi és a cikk megmarad nagyon sokáig a jelenlegi helyén.

http://weblabor.hu/cikkek/php-osztalyok-egysegtesztelese

http://weblabor.hu/cikkek/php-osztalyok-egysegtesztelese-2

1jan/120

Parkolás Budapesten

Ez a cikk sem kötődik konkréten a blog témájához, de úgy gondolom sokaknak lehet hasznos, akik autóval közlekednek a városban. A parkolás mindig is problémás volt városunkban, de a fizetéssel aztán meg teljesen kaotikus lett. Melyik zóna is ahol este 8-ig kell fizetni és melyik ahol csak 6-ig? Hol van vakfolt a rendszerben? Illetve tudtad, ha két utcával tovább mész, akkor már csak fele a parkolási díj? Na ezek a kérdések amik engem sokszor az őrületbe kergettek, így kutakodtam egy kicsit. Találtam két nagyon jól használható megoldást. Az egyik gy PC-s, a másik egy Andriod-os. Tehát ha otthonról indulok akkor a gép elől is megtudom nézni, hol kéne letenni a kicsi kocsit. Illetve ha úton vagyok akkor pedig az okostelefon segíthet. Javaslom mind a két program megtekintését:

PC-s Budapesti parkolási térkép: (de az ország nagyvárosait is tartalmazza)

http://picipenz.com/parking_zones.php

Android alapú parkolást segítő alkalmazás:

https://market.android.com/details?id=eu.appround.parkingportal

1jan/120

Virtualizáció és az Openfiler hálózata

Aki komolyabban elmerült már a virtualizációban az szinte biztosan találkozott már az Openfiler névre hallgató ingyenes NAS/SAN Appliance megoldással. Egy nagyon jó termékről van szó, azt az egyedüli problémát leszámítva, hogy virtualizált környezetben néha elég kényes. Főleg arra gondolok, hogyha a virtuális gépet mozgatjuk (másoljuk, áthelyezzük, esetleg mentésből visszaállunk) akkor a hálózat teljesen használhatatlan lesz. Ennek az az oka, hogy a virtualizációs környezet egy új MAC address-t generál a hálókártyának, amely eltér a régitől. Mivel a régi MAC Address el van tárolva az Openfiler konfigurációs állományában, ezért detektálja a turpisságot és közli velünk, hogy gond van. Na innentől az eth0 interfészt többet nem lehet online állapotba kapcsolni, tehát a hálózatnak lőttek. Emiatt sokszor gondot okozhat egy Openfiler rendszerre alapozott környezet kialakítása amit utána ki kell küldeni a hálózat gépeire.

A megoldást több helyről is közelíthetjük. Ha például VMware rendszert használunk, akkor .vmx állományt kézzel is megszerkeszthetjük, hogy statikus MAC címet használjon. Bár ez nehézkes, mert ez rendszerenként eltérhet, sőt nem is lenne valami jó, egy kiküldött image miatt több gép ugyan azt a MAC címet használná...

A másik megközelítés az Openfiler konfigurációs fájl módosítása:

vi /etc/sysconfig/network-scripts/ifcfg-eth0

Első lépésben pedig #-el kommenteljük ki a HWADDR mezőt. Ez gyakorlatilag meg is oldja a problémánkat.

De ha már itt járunk, gondoltam egyszerűbb leírni, hogyan állítsunk be FIX IP címet:

DEVICE=eth0
BOOTPROT=static
IPADDR=192.168.1.201
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
ONBOOT=yes
TYPE=Ethernet

Tagged as: , No Comments
1jan/120

Hogyan engedélyezzünk utólagosan Thin Provisioning-et a lokális Storage-on Citrix XenServer 5.5 és 6.0 esetén

Először is szögezzük le, hogy ez az írás nem a webfejlesztéssel kapcsolatos, hanem a virtualizációval. Konkrétan a Citrix által készített XenServer környezethez. A magyarországi kkv-k többsége nem engedheti meg magának, hogy hatalmas szerverparkokat tartson karban, sőt sokszor egy szerveren túl nem tudnak többre beruházni. Tehát az adatokat nem egy külön Storage-ra helyezik, hanem nagy valószínűséggel a szerverben található merevlemezekből készítenek egy tárolót, jó esetben egy RAID5/10 tömbbel. Így ez a kicsinyke leírás főként nekik lesz hasznos, ha elfelejtették volna a thin provisioning-et bekapcsolni.

De mi is ez ha már így szóba került. Alap esetben ha készítünk egy virtuális szervert, akkor annak allokálni kell egy merevlemez kapacitást. Legyen ez mondjuk 10GB. Abban az esetben, ha egy debiant telepítünk fel, akkor kb 1-2 GB helyet használunk fel. Ha pedig egy Windows 7-et, majdnem az egészet. Mindegy melyik történik, alap esetben a 10GB-ot fizikailag lefoglaltuk a tárolóban a virtuális gép számára. Ha kihasználja, ha nem. Ezt nevezzük tick provisioning-nek. Látható, hogy ez csak akkor működik jól, ha pontosan meg tudjuk saccolni mekkora lesz a végső virtuális szerver tárkapacitása.

Ezzel szemben a thin provisioning lehetővé teszi, hogy virtuálisan allokáljuk a 10GB-ot, de a merevlemezből ténylegesen csak a felhasznált 1-2 GB kerüljön lefoglalásra. Ez sokkal gazdaságosabb, mivel ha van egy 2TB-os Storage-om, akkor ezzel a módszerrel nyugodtan ki lehet ajánlani akár több merevlemez kapacitást a virtuális szervereknek, mint amivel rendelkezünk hiszen csak annyit foglalnak a valós tárolón mint amennyi tényleges adatot foglalna. Így nem lesz baj, ha a későbbi igények növekednek egy virtuális gép esetén, mert nem kell a teljes allokációt újragondolni. Természetesen ennek a megoldásnak nem csak előnyei vannak, hanem egy kicsi árnyoldala, hiszen mindig számon kell tartani a szabad és használt kapacitást a szerveren. Ennek van egy minimális Overhead-je. De ez, a kapott előnyökkel szemben minimális. Tehát ha mindenek előtt a performancia számít, akkor használjunk thick provisionong-et, de ha inkább a gazdaságosság a szempont akkor pedig thin provisioning-et.

De ne szaporítsuk a szót, nézzük hogyan kell utólagosan beállítani a thin provisioning-et Citrix XenServer 5.5 esetén, ha ezt a telepítés során elfelejtettük volna.

1) Állítsunk le minden virtuális gépet és készítsünk róluk másolatot.

Ez azért fontos, mert a lokális Storage-ot meg kell szüntetni, így amit rajta tárolunk az elveszik. Emiatt mindenről készítsünk egy mentést, amelyeket a művelet elvégzése után visszamásolhatunk a Storage-ra.

2) Keressük meg, hogy a Storage Repository melyik partíción található.

cat /etc/xensource-inventory | grep "DEFAULT_SR_PHYSDEVS"
DEFAULT_SR_PHYSDEVS='/dev/sda3'

XenServer 6.0 esetén:
fdisk -l utasítással megkeressük melyik device használ LVM kötetet (alapból ilyen lenne)
fdisk -l | grep "LVM" | awk {'print $1'}
/dev/sda3

3) Szerezzük meg az UUID számát a Storage Repository-nak.

xe sr-list type=lvm
uuid ( RO) : 42080775-542e-5ad9-72a6-a3e483dbd880
name-label ( RW): Local storage
name-description ( RW):
host ( RO): xs-tarenz01
type ( RO): lvm
content-type ( RO): user

4) Szerezzük meg a Physical Block Device UUID azonosítóját, amihez az előbb megismert SR UUID-t használjuk fel.

xe pbd-list sr-uuid=42080775-542e-5ad9-72a6-a3e483dbd880
uuid ( RO) : 8e4c6231-2460-7380-c904-150a31c9bd63
host-uuid ( RO): ba3d140c-3de5-499b-b831-7c40d82958a9
sr-uuid ( RO): 42080775-542e-5ad9-72a6-a3e483dbd880
device-config (MRO): device: /dev/disk/by-id/scsi-SATA_Hitachi_HDT7250_VFA100R1C0GKTB-part3
currently-attached ( RO): true

5) Válasszuk le a PBD eszközt a szerverről, így a XenCenter-ben egy felkiáltó jelet kell majd látnunk a Local Storage mellett.

xe pbd-unplug uuid=8e4c6231-2460-7380-c904-150a31c9bd63

6) Semmisítsük meg a Local Storage-t. (Ehhez már a Local SR UUID-t használjuk)

xe sr-destroy uuid=42080775-542e-5ad9-72a6-a3e483dbd880

XenServer 6.0 esetén:
Az sr-destroy utasítás nem működik, mondván VDi merevlemez található a köteten, pedig mindent eltávolítottam. Ezért helyette az sr-forget utasítást használtam.
xe sr-forget uuid=42080775-542e-5ad9-72a6-a3e483dbd880

7) Hozzuk létre a Storage-t újra, csak már Thin Provisioning-el. Ehhez szükség lesz a Host-UUID-re és a Partícióra.

xe sr-create host-uuid=ba3d140c-3de5-499b-b831-7c40d82958a9 content-type=user type=lvm device-config:device=/dev/sda3 shared=false name-label="Local storage" sm-config:allocation=thin

8) Másoljuk vissza a virtuális gépeket, majd ellenőrizzük a tároló kapacitását.

Az eredeti cikk ami alapján ez a leírás is született a xendesktopmaster.com oldalon megtalálható.

30dec/112

Külső linkek mindig új ablakban nyíljanak meg

A jelenlegi postom arról szól ami a címe :) Egy weboldalon elég sok link lehet, ezeket két kategóriába sorolhatjuk: belső és külső linkek. A belső linkeket nem kellene piszkálni, hiszen azok úgy jók ahogy vannak. Viszont a külső oldalakra mutató linkek általában elviszik a látogatót a mi honlapunkról, mert ugyan abban az ablakban halad a látogató tovább. Ez nem biztos hogy mindig szerencsés. Talán jobb megoldás ha a látogató marad a mi honlapunkon és minden külső link amit mi biztosítunk, az egy új lapban jelenik meg a böngészőjében. Így ha a külső oldalt megtekintette és bezárta, akkor a mi honlapunk már várja is szeretettel.

Most mindenki mondhatja jó oké ezt ismerjük... Nem nagy újdonság... csak target="blank" és kész is. Természetesen igazatok is lenne, akkor ha nem arról lenne szó, hogy portolj egy weboldal 200-300 belső lappal, amelyeken átlagban 2 külső link található. Megnézném ki szeretne közel 4-600 linket egyesével átírni, mert elég unalmas egy munka lenne.

Ehhez egy gyors és univerzális megoldást nyújt a következő jQuery alapú JavaScript. A megoldást természetesen bármikor lehet natív JS-re portolni, de mivel az oldalon a jQuery adott volt, így a szkript megírása is kényelmesebb volt.

 
function getDomain(url) {
       if( url.substr(0, 7).toLowerCase() == "http://" )  { url = url.substr(7); }
  else if( url.substr(0, 8).toLowerCase() == "https://" ) { url = url.substr(8); }
  return url.substr(0, url.indexOf("/"));
}

$(document).ready(function(){
  var url = getDomain(top.location.href);
  $("a").each(function(){
    var link = getDomain($(this).attr("href"));
    if( url != link ) {
      $(this).attr("target","_blank");
    }
  });
});