Ha Linuxon szeretnél adminisztrátori jogosultsággal futtatni utasításokat, gyakran egy nem adminisztrátor felhasználóval lépsz be, majd a sudo paranccsal szerzel az adott utasítás futtatásának idejére adminisztrátori jogosultságot, avagy root jogot. Ugyancsak gyakori, hogy egy program elég nagyra nő, hogy a sok-sok shell script mellett, azokban függvényeket is írsz. A nagy kérdés, hogy mi van, ha ezek közül az egyik függvénynek adminisztrátori jogokkal kell működnie, de az azt meghívó szkriptnek nem. Egy részt, talán itt az ideje újratervezni, de talán megvan az okod rá és kioktatás helyett okításra van szükséged, ezért a következőkben megosztok veled pár lehetőséget. Az alábbiak megértéséhez érdemes elolvasni a Bash argumentumok és titkaik című cikket is.

A Bash egy népszerű Linux shell, amit ugyan kényelmi szempontból sokan leváltanak a termináljukban egy másfajta alapértelmezett shellre, például Z shellre, de a szkriptek továbbra is Bash-hez készülnek. Van egy-két sajátossága a Bash-nek, de az olyan alap funkció, mint az argumentumok átadásának működése néha úgy tűnik, kevés figyelmet kap, hiszen más shellekben is hasonlóan működik, nincsen benne semmi különleges. De vajon valóban így van? Ki mered jelenteni, hogy mindent tudsz róluk? Ha igen, a cikk talán nem neked készült. Régóta írok Bash szkripteket is, de mégis volt, aminek én sem voltam teljesen tudatában. Olvasd tovább a cikket és teszteld le a saját tudásodat is.

Ahogy sok más területen, az informatikában is nagyon fontos az angol nyelv ismerete. Tetszik vagy sem, elterjedtsége miatt rengeteg információ angol nyelven érhető el, vagy angolul beszélsz ügyfelekkel, vagy adott esetben akár a kollégákkal még akkor is, ha nem utazol külföldre. Jómagam sok év német nyelv tanulása után tanfolyamok segítségével letettem az angol nyelvvizsgát, de ez nem jelentette azt, hogy magabiztosan tudnék beszélni angolul, vagy megérteném az angol filmeket folyamatos visszapörgetés nélkül. Elhatároztam, hogy ezen változtatok, de az időbeosztásom miatt elsősorban online lehetőségek után nézek. Így jutottam el a Youtube-ra. A cikkben bemutatom az általam követett oktatókat.

Az előző cikkben kaphattál egy átfogó képet az Ansible 2.8-ról, és a példák segítségével bele is kóstolhattál a használatába. Nagyon fontos viszont tudnod, hogyan használhatsz változókat és egyáltalán milyen változók vannak milyen precedenciával, avagy prioritással, illetve mi közöttük a különbség. Fontos azért, mert a dinamikus beállításokkal rugalmasabbá teszed a konfigurációt, de a helytelen alkalmazásukkal sok bosszúságot okozhatsz magadnak. Továbbra is a 2.8-as Ansible-nél maradva olyan ismeretekhez juthatsz a cikk segítségével, amivel már bátran készíthetsz dinamikusabb Ansible playbookokat is. A cikk-ben bemutatott példákat az itsziget/ansible-examples GitHub projektben is megtalálhatod. Ügyelj arra, hogy a cikkből kattintva jutsz el a projekthez, hogy biztosan a megfelelő verziót találd meg javítás esetén is.

Többször írtam már a Dockerről, aminek sok előnyét lehet említeni, de ez nem jelenti azt, hogy ne maradna olyan feladat, amit ettől függetlenül meg kellene oldani. Elég csak arra gondolni, hogy már a Dockert is telepíteni kell. Nem beszélve az egyéb nem, vagy nehezen konténerizálható szolgáltatásokról és azok függőségeiről, illetve az éppen a Docker miatt felmerülő további feladatokról.

Természetesen ez a két szoftver egymástól függetlenül használható, de ha a Docker szóba kerül, nagyon gyakran felmerül az Ansible is, mint eszköz. A segítségével azok a műveletek is leírhatók és verziózhatók, amik nem spórolhatók meg Docker image-ek létrehozásával.

Ez persze még nem minden, ráadásul alternatívák is vannak az Ansible-re, én viszont ebben a cikkben az Ansible 2.8 alapjairól fogok írni.

Az Apache HTTPD egyik jellemzője, hogy ".htaccess" fájlokban is lehet bizonyos szerverkonfigurációs paramétereket módosítani. Ezek a fájlok bármely könyvtárba letehetők és az adott könyvtárszinten belül érvényesek csak. Sok alkalmazás eleve tartalmaz egy vagy akár több .htaccess-t, de előfordulhat, hogy te magad szeretnél egyes paramétereken, a szerver viselkedésén változtatni. De hova érdemes és adott esetben hova lehet tenni ezeket a változtatásokat? Tényleg csak egy jó megoldás létezik, vagy árnyaltabb a probléma? Erre próbálok választ adni a cikkben.

Minden szoftvernek biztosítani kell egy tesztkörnyezetet. Ez néha nagyon egyszerű, néha pedig igazán elgondolkodtató. Mi van, ha a tesztelendő szoftvernek egy olyan eszközzel kell kommunikálnia, amit nem lehet minden sarkon beszerezni, ráadásul helyhez kötött, a fejlesztés viszont nem? Ebben a cikkben nyomtatókkal történő SNMP kommunikációról fogok mesélni Docker környezetben. Mivel tud segíteni és mi okoz némi fejtörést a konténerek világában.

A programozás világában vannak olyan eszközök vagy megoldások, amiket csak egy bizonyos réteg használ vagy akár ismer. A többi programnyelven vagy adott szintű feladat esetén nincsen rá szükség. A verziókezelés nem ilyen. Gyakorlatilag a legalacsonyabb szinteken is használunk valamilyen verziókezelő szoftvert hosszú évek óta, és bár a verziókezelés a szoftverfejlesztésből indult ki, más területeken is alkalmazzák, például szöveges dokumentumok verzióinak követésére. Nem azt mondom, hogy ez az első dolog, amivel mindenkinek kezdenie kell egy fejlesztést, de leginkább nem arra kell okot keresnem, hogy miért használjam, hanem arra, hogy miért ne. Utoljára 2011-ben írtam cikket a témában, de azzal ellentétben, ebben a cikkben a verziókezelés szükségességét és értelmét próbálom körüljárni, ezzel motivációt próbálva adni azok számára, akik még mindig azt a kérdést teszik fel, hogy "mi ez és miért kezdjek neki?"