Linux

I had a Linux server with two physical network interfaces which were separated into two network namespaces. Security was set up like two machines with single network card in each connected to different physical networks.

At one day, someone found out, that a process runs in the ‘red’ network namespace needs to connect to a remote machine, reachable via the physical network interface connected to the other namespace we call as host namespace. How to do so?

Pár héttel ezelőtt írtam a MySQL replikációról, majd most úgy tűnik egy PowerDNS alapokon nyugvó DNS kiszolgálóhoz szükség is van rá némi kiegészítéssel.

Ami miatt úgy tűnik használni kell, az a PowerDNS supermaster/superslave funkciójának egy hiányossága.

A domain név szervereket (DNS) elsősorban a megfelelő hibatűrés érdekében többszörözni szokás. Ilyenkor egy-egy zónához (például a halacs.hu vagy a .hu TLD) nem csak egy authoritatív (mérvadó) kiszolgálót tartunk számon, hanem legalább kettőt. Ezeket szokták legtöbbször elsődleges és másodlagos névszerverekként is említeni (feltéve, hogy csak kettő van).

Ahogy már egy előbbi bejegyzésben is írtam elkezdtem VPS szolgáltatásokat tesztelni. A most következőkben is erről lesz szó, azonban itt már nem vServer alapú izolációs megoldást, hanem egy manapság egyre divatosabbnak számító felhőt (Cloud Computing) vizsgáltam. Egész konkrétan a HP Private Beta Cloud szolgáltatását.

A szolgáltatáshoz hozzáférést egyéni elbírálásos alapon lehetett szerezni, ahol többek közt azt is meg kellett adni, hogy mire szeretném használni a szolgáltatást. Az igénylésemet késő délután adtam le, majd másnap délelőtt már az elfogadásról szóló e-mail várt a postafiókomban. Sajnos egy kollégám már nem volt ennyire szerencsés, őt csak több hét és egy telefonos elbeszélgetés után hagyták jóvá.

Néha felmerült, hogy milyen jó lenne tudni egy-egy webszervernél, hogy péládul egy PHP oldal kiszolgálása során mennyi időt emészt fel a szkriptek feldolgozása és mennyit a webszerver futása. Erre a problémára lehet többek közt megoldás a New Relic szolgáltatása, mely egész tetszetős és részletes grafikonokkal, táblázatokkal segíti az informálódást.

A New Relic használatáshoz telepíteni kell annak agent alkalmazásait, melyet követően többek közt lehetőség van az egyes futó folyamatok valós idejű memória, CPU, hálózat és disk használatát is monitorozni, melyekre alapvető riasztások is beállíthatóak.

Az utóbbi időben többször és több dolog kapcsán is felmerül, hogy ideje lenne beszerezni egy komolyabb sávszélességgel rendelkező szervert, vagy egy túlnyomórészt hasonló képességekkel bíró, de olcsóbb virtuális szervert (VPS). Ennek kapcsán kezdtünk vizsgálódni mik érhetőek el jelenleg a piacon. Így jutottam el az Alvotech nevű német céghez is, aminek volt szerencsém tesztelni az Amszterdami szerverükön futtatott VPS szolgáltatását, egész pontosan egy vServer L csomagot.

Erről a szolgáltatásról elsősorban azt kell tudni, hogy nem teljes virtualizált gépet, hanem egy Linux vServer alapú izolált környezetet nyújtanak, mely bár nagyrészt azonos képességekkel bír mint a Xen vagy más virtualizált megoldások, rendelkezik pár komolyabb megkötéssel. Ilyen megkötés például, hogy nincs lehetőség tűzfalat állítani (pl. ufw), gépet újraindítani vagy a kernelt kicserélni, mivel a vServer esetében az alkalmazott izolációs technológiának köszönhetően a kernel minden VPS esetében megegyezik. --- Mivel a következőkben leírt tesztből ez nem derül ki, itt említeném meg, hogy tűzfal állításra ebben az esetben egy külön webes felületen van lehetőség, melyhez azonban én nem kaptam (nem is kértem) hozzáférést.

Több előző bejegyzésemhez hasonlóan ez a "projekt" is szorosan kapcsolódik a BME-hez, azonban az eddigi mobilos témákkal ellentétben, melyek szegről-végről az Automatizálási és Alkalmazott Informatikai Tanszékhez ködődtek, most a Közigazgatási és Informatikai Központbeli munkatársaimnak az eredetileg szerverek megfigyelésére szánt ötletét valósítottam meg itthoni külső-belső hőmérséklet megfigyelésre. A cél a lakás három fontosabb pontján és egy külső ponton mért hőmérsékleti adatok meghatározott időnkénti mintavételezésével egyszerűbb energiagazdálkodási következtetések levonása, illetve természetesen a szórakozás, kíváncsiság volt.

Már egy ideje foglalkoztat a gondolat, hogy a home.halacs.hu szerveremen lévő email szolgáltatáshoz érdmes lenne beállítani egy tartalék levelező szervert, ami az elsődleges gép elérhetetlensége esetén is tudná fogadni és átmenetileg tárolni a leveleket.

Figyelembe véve a kiszolgáló minimális e-mail forgalmát (szűk baráti kör), a dolog gyakorlati jelentőssége nem túl nagy (különösen az smtp-k "próbálkozós" működését ismerve), mégis a megvalósítás mellett döntöttem. Talán elsősorban kíváncsiságból.

A backup mail exchanger végül egy Ubuntu Serveren futó Postfix e-mail kiszolgáló alklamazás lett.

A virtuális hosztok használata webes környezetben egy elterjeden használt megoldás, annak érdekében, hogy egy IP címmel több, eltérő domain név alatt üzemelő weboldal is kiszolgálható legyen. Ennek használatakor a web szerver a HTTP kérésben utazó HOST mező alapján azonosítja azt a virtuális kiszolgálót, amelyet használnia kell a kérés feldolgozához.

Ennek kapcsán még valamikor régebben foglalkoztatott a kérdés, hogy vajon lehetne-e ilyen virtuális hosztokat (named virtual host) csinálni HTTPS-t használó oldalakanál is, azonban akkor még sajnos nem volt rá a válasz.

Néha bárkivel előfordulhat, hogy jelszó probléma miatt nem sikerül belépnie egy Ubuntu Linux operációs rendszerre.

Ilyenkor egy kézenfekvő megoldás a problémás felhasználó jelszavának a törlése. Feltételezve, hogy az adott géphez fizikai (de legalább valamilyen konzolos) hozzáférésünk van, ez egyáltalán nem jelent problémát, sőt szerencsés esetben még csak CD-t, vagy egyéb bootolható eszközt sem kell használnunk.

Jelen esetben én a Nemzeti Információs Infrastruktúra Fejlesztési Intézet (NIIFI) tagintézményei számára nyújtott cloud szolgáltatás használata során botlottam ebbe a problémába (erről részletesen később). Mivel rövid keresgélés után nem sikerült megtalálni milyen felhasználónévvel és jelszóval lehet belépni a frissen létrehozott VM-re, ezért két út állt előttem: megoldom magam, vagy megkérdezem a jelszót valamely cloud adminisztrátortól. Praktikus okoból (és mert egyébként is szórakoztatóbb) én az első megoldást választottam.

Mindenki tudja, hogy a tűzfalak jók, a tűzfalak kellenek, a tűzfalak remek szabályokat tudnak kikényszeríteni amikkel sokkal biztonságosabbá tehetjük a hálózatunkat. Természetesen azonban a biztonságnak ára is van. Ez az ár esetemben egy többszörösen eltűzfalazott linux gép internet felőli elérhetetlenségét jelenti, ami időnként elég kellemetlen tud lenni. Mit lehet ilyenkor tenni?

Az egyik kézenfekvő megoldás a reverse SSH tunnel. Emellett meg kell említeni a VPN lehetőségét is, de engem most nem ez izgatott, így reverse SSH tunnel lett. Ez a következő képpen néz ki egy Fedora 22-t futtató "védett" gép és egy Ubuntut futtató "külső" gép esetén.