Archívum

Linux

Ebben a bejegyzésben egy Git szervert fogok létrehozni, ami egy Docker konténeren futó Debian Linuxon fog futni. A Git szervert ssh-n keresztül éri el, ezért kell egy ssh szerver, ami jelen esetben az openssh-server lesz. Telepítsük fel a szükséges csomagokat.

apt install openssh-server openssh-client openssh-known-hosts git

Ha sudo-zott rendszert használunk, akkor a sudo szükséges az elejére. Az openssh-server a telepítéskor létrehozza a szerveren az SSH privár és publikus kulcsokait, de generáljunk újakat.

rm -v /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server

Ezt követően indítsuk el az SSH szerverünket. Mivel ezen a konténeren nincs systemd, ezért a jól bevált init.d szkriptel teszem meg.

/etc/init.d/ssh start
[ ok ] Starting OpenBSD Secure Shell server: sshd.

Ellenőrizzük is a kliensen:

nmap 172.17.0.2 -p 22

PORT STATE SERVICE
22/tcp open ssh

Úgy tűnik működik. Most hozzunk létre a szerveren egy git nevű felhasználót:

useradd git
passwd git
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
mkdir /home/git
chown git.git -R /home/git/

És kész! Próbáljuk is ki működik-e az ssh elérés a git felhasználóval a kliensről:

ssh git@172.17.0.2
git@172.17.0.2's password:
$

Igen! Ha ezzel megvagyunk másoljuk fel a kliens gép publikus SSH kulcsát a ssh szerverre, így jelszó nélkül tudunk belépni és a git szervernek parancsokat kiadni a kliensről. Ez többféle módon megtehető, én most ezt választottam:

scp ~/.ssh/id_rsa.pub git@172.17.0.2:/home/git/uploaded_key.pub
ssh git@172.17.0.2 "mkdir -p ~/.ssh && cat ~/uploaded_key.pub >> ~/.ssh/authorized_keys && rm uploaded_key.pub"

Majd a ha ezzel megvagyunk konfiguráljuk be az SSH szervert, hogy csak publikus kulccsal rendelkező felhasználókat engedjen be. Szerkesszük a /etc/ssh/ssh_config fájlt a szerveren.

PasswordAuthentication no
ChallengeResponseAuthentication no

Ezt követően indítsuk újra az ssh szervert.

/etc/init.d/ssh restart
[ ok ] Restarting OpenBSD Secure Shell server: sshd.

Ezek után már kulccsal fog beengedni. Térjünk vissza eredeti témánkhoz, a Git szerverhez. Ahhoz, hogy a Git szerver repóban parancsokat tudjunk végrehajtani léteznie kell  a szerveren az adott könyvtárnak és ott egy inicializált Git adatbázisnak. hozzunk létre a szerveren egy proba repót.

mkdir -p ~/git-repos/proba
git init --bare ~/git-repos/proba
ls -la ~/git-repos/proba
total 40
drwxr-xr-x 7 git git 4096 Jan 25 13:01 .
drwxr-xr-x 3 git git 4096 Jan 25 13:00 ..
-rw-r--r-- 1 git git 23 Jan 25 13:01 HEAD
drwxr-xr-x 2 git git 4096 Jan 25 13:01 branches
-rw-r--r-- 1 git git 66 Jan 25 13:01 config
-rw-r--r-- 1 git git 73 Jan 25 13:01 description
drwxr-xr-x 2 git git 4096 Jan 25 13:01 hooks
drwxr-xr-x 2 git git 4096 Jan 25 13:01 info
drwxr-xr-x 4 git git 4096 Jan 25 13:01 objects
drwxr-xr-x 4 git git 4096 Jan 25 13:01 refs

A jogosultságoknak és a tulajdonságoknak mindenképpen a git felhasználóhoz kell, hogy rendelve legyenek. Na, OK! Klónozzuk a távoli repót.

git clone ssh://git@172.17.0.2/home/git/git-repos/proba
Cloning into 'proba'...
warning: You appear to have cloned an empty repository.

Figyelem! Mindig a teljes elérési úttal adjuk meg a repó elérését! Ezt követően nézzük meg a kliensen a repó távoli beállítását.

cd proba
git remote -v
origin	ssh://git@172.17.0.2/home/git/git-repos/proba (fetch)
origin	ssh://git@172.17.0.2/home/git/git-repos/proba (push)

És akkor próbáljuk is ki a kliensről.

[anon117@anon117box proba]$ echo alma >> alma txt
[anon117@anon117box proba]$ git add .
[anon117@anon117box proba]$ git commit -m "commit üzenet"
[master (root-commit) 1b4e9da] commit üzenet
 1 file changed, 1 insertion(+)
 create mode 100644 alma
[anon117@anon117box proba]$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 217 bytes | 108.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://172.17.0.2/home/git/git-repos/proba
 * [new branch]      master -> master

Úgy tűnik működik. A különböző rendszereken lehetnek eltérések, de az alap gondolat ugyanaz.

A SimpleSSHD androidos alkalmazást vizsgáljuk meg. Nem egy nagy kaland. Az ssh szerverre kulccsal tudunk belépni, ezt az sdcard0/ssh mappa alatt tárolja a jól ismert authorized_keys fájlban szereplő publikus kulcs segítségével. Szóval annyi a dolgunk hogy a PC-n lévő publikus kulcsunkat felmásoljuk a telefonra. Ehhez ad segítséget egy egyszer használatos jelszóval. Szóval:

~/.ssh $ scp -P 2222 id_rsa.pub user@192.168.1.212:authorized_keys

Aztán már mehet is a vigadalom:

ssh user@192.168.1.212 -p 2222

Ha már létezik authorized_keys létező kulcsokkal a szerveren, akkor a szerveren kell hozzáfűzni a publikus kulcsunkat az authorized_keys-hez.

~/.ssh $ scp -P 2222 id_rsa.pub user@192.168.1.212:myPubKey
cat myPubKey >> authorized_keys

Ehhez újból be kell majd lépj a telefon SSH szerverére, ezért a RESET KEYS menüpontban kérhetsz újabb egyszer használatos kulcsot. Lényeg, hogy létezzen a kulcsod az authorized_keys fájlban.

Az Androidos ConnectBot ssh klienssel akartam csatlakozni a router-hez publikus kulccsal. Ehhez ugye a kliensen generálni kell egy ssh kulcsot. Ezt a ConnetcBot megteszi.

Screenshot_2017-12-15-14-12-11

Majd ezt követően fel kell másolni a publikus kulcsot a ssh szerverre, jelen esetben a router-re. Ehhez engedélyezni kell a LEDE-ben a root jelszavas ssh elérést. Ezt csak ideiglenesen van nálam, mert minden kliens publikus kulccsal jelentkezik be.

Majd lépj be és másold fel a publikus kulcsot. Itt megjegyzem, hogy a ConnecBot-nak van olyan menüje, ahol a kulcsot vágólapra másolja, így könnyebb az életünk.

echo "PUBLIKUS _KULCS" >> .ssh/authorized_keys

Gyakorlatilag ennyi, ha mégsem tudna belépni, akkor PC-ről másoljuk a publikus kulcsot a LUCI System - Administration menüpontja alatt lévő SSH keys részhez.

Ide…

Megjegyzés! A képen látható kulcsok a /overlay/upper/etc/dropbear/authorized_keys fájlban találhatóak.

És már kész is. Használatra fel.

Figyelem! Javasolt a root felhasználó jelszó elérését mellőzni, ezért továbbiakban ezt az opciót vegyük ki a LEDE-ből. Én magam részéről az egyéb jelszavas elérést is mellőzném. Jelenleg elég a publikus kulcsos elérés is.

LEDE_no-root

 

Van egy ősrégi integrált nvidia VGA-s gép és szerettem volna már régen KDE 5 Plasma felületet rajta. Igazság szerint elég reménytelen volt eddig, mert még elindulni se nagyon akart. Viszont most neki kezdtem, hátha lesz valami. Lett is. Címszavakban elmesélem mi a helyzet.

  1. lépésként kapcsold ki az összes Asztal effektust. Rendszerbeállítások – Asztal működés: Aszal effektusok. Így már kevésbé omlott össze a kép.
  2. Aztán próbálkozhatsz a kompozítor állítgatásával. Rendszerbeállítások – Kijelző és monitor: Összeállító. Itt kipróbálhatod a Szakadás megelőzése (VSinc): Soha beállítást. Aztán ha még nem az igazi kikapcsolhatod a Kompozítor bekapcsolása induláskor pipát.
  3. Aztán ugye jó lenne nvidia driver is, mert a nouveau ugyan eldöcögött, de jó lenne egy kis sebesség. Először megnéztem milyen legacy driverek vannak a 304-hez.
    sudo apt show -a nvidia-304 | grep Version
    Version: 304.135-0ubuntu0.16.04.1
    Version: 304.131-0ubuntu3

    Először a 131.el próbálkoztam:

    sudo apt install nvidia-304=304.131-0ubuntu3

    Ez nem ment, csak fekete képernyő volt meg kurzor. Nézzük a másikat:

    sudo apt install nvidia-304=304.135-0ubuntu0.16.04.1

    Ez már ment. Siker!

    Ha neked nem működne, akkor rakd vissza a nouveau drivert:

    sudo apt remove --purge nvidia-304=304.135-0ubuntu0.16.04.1
  4. Igazából a feliratoknál is volt gond, sok helyen fura fekete foltok jelentek meg a tálcán. Ezen úgy segítettem, hogy a Noto betűtípust lecseréltem Dejavu Sans-ra, ezt már valamivel jobban rendereli.

Egy próbát megér.

Környezet: nvidia 7050, Linux Mint 18.2 (KDE 5)

Ha például MATE terminál programmal akarunk 256 színű Midnight Commander témát használni (más néven borítás), akkor be kell állítani egy-két dolgot

~/.bashrc elejére:

TERM=xterm-256color

Aztán ha új terminált nyitsz már élnie kell.

tput colors
256

Itt találtam az infót.

Az új MC színtémádat másold be a /home/anon117/.local/share/mc/skin könyvtáradba, majd nyisd meg a /home/anon117/.config/mc/ini fájlt. Ott keresd a [Midnight Commander] részt, és azon belül a skin=default sort. Ezt írd át a saját témádra. Pl:

skin=/home/anon117/.local/share/mc/skin/gray.ini

Természetesen anon117 helyett a saját felhasználói nevedet add meg. A fentieket Linux Mint 18 alatt csináltam, más rendszereken lehetnek eltérések.

Ilyen volt…

eredeti_mc

Ilyen lett…

szurke_mc

skin link

A zenity egy olyan eszköz, amellyel GTK+ dialógus ablakokat hozhatunk létre. Ezeket legegyszerűbben parancssorból idomíthatjuk. A dialógus ablakok jól jönnek grafikus felületen BASH script interakciókhoz.

A dialógus ablakok széles tárháza áll rendelkezésre, erről meggyőződhetünk a zenity –help parancs kimenetéből is.

Megjegyzés: A barna színnel írt parancsot egy sorba kell írni!

Alkalmazás kapcsolói:
--calendar Naptár párbeszédablak megjelenítése
--entry Szövegbeviteli párbeszédablak megjelenítése
--error Hibára figyelmeztető párbeszédablak megjelenítése
--info Információs párbeszédablak megjelenítése
--file-selection Fájlválasztó párbeszédablak megjelenítése
--list Lista párbeszédablak megjelenítése
--notification Értesítés megjelenítése
--progress Folyamatkijelző párbeszédablak megjelenítése
--question Kérdező párbeszédablak megjelenítése
--warning Figyelmeztető párbeszédablak megjelenítése
--scale Nagyítás párbeszédablak megjelenítése
--text-info Szöveges információs párbeszédablak megjelenítése
--color-selection Színválasztó párbeszédablak megjelenítése
--password Jelszó párbeszédablak megjelenítése
--forms Űrlapok párbeszédablak megjelenítése
--display=DISPLAY X display to use

Nézzünk egy egyszerű példát amivel beleláthatunk a dolgokba.

zenity --info --title="Törlés" --text="Törölve!"

zenity1

Itt egy sima információt közöl velünk a dialógus ablak. Az –info meghatározza a dialógus fajtáját, a –title az ablak címkéjét, a –text pedig értelemszerűen az ablakban lévő szöveget jelenti.

Következő fontos dialógus típus a –question, azaz kérdező ablak. Itt egy egyszerű eldöntésről van szó, akarunk-e valamit vagy nem.

zenity --question --title="Törlés" --text="Akarod törölni a fájlt?"

zenity2

Ugye itt az ablak típusa –question, azaz kérdező ablakról van szó. A zenity lefutása után a „válasz”, azaz a visszatérési érték bekerül a $? shell változóba. Ha a Yes-re kattintunk, akkor 0, ha a No-ra, akkor 1 lesz a visszatérési érték.

Ezt egy egyszerű BASH script-tel le is kezelhetjük.

#!/bin/bash

zenity --question --title="Törlés" --text="Akarod törölni a fájlt?"
if [ $? = 0 ]; then
  rm $HOME/ez_egy_proba.txt
else
  exit
fi

Természetesen lehet finomítani, de itt a működési elv bemutatása volt a lényeg.

Következő hasznos dialógus a naptár –calendar, itt értelemszerűen egy kiválasztott dátumot kapunk, amit a standard kimenetre ír ki.

zenity --calendar --title="Kezdés dátuma" --text="Válassz dátumot"
2016-04-12

zenity3

Kezeljük le a dátumot egy script-tel.

#!/bin/bash

DATUM=$(zenity --calendar --title="Kezdés dátuma" 
--text="Válassz dátumot")
if [ -n "$DATUM" ]; then
  zenity --info --title="Dátum" --text="$DATUM"
else
  zenity --info --title="Dátum" --text="Nem adott meg dátumot!"
fi

Opcionálisan megadhatunk pontos év, hónap, nap kiindulási dátumot, de ennek bemutatásától most eltekintek.

Másik hasznos dialógus az –entry, a beviteli mező, aminek segítségével szöveges választ adhatunk. A működés lekezelése hasonló a naptáréhoz.

zenity4

#!/bin/bash
COLOR=$(zenity --entry --title "Kedvenc szín" 
--text "Mi a kedvenc színed?" --entry-text "Bíbor")
if [ -n "$COLOR" ]; then
 zenity --info --title="Kedvenc szín" --text="$COLOR"
else
 zenity --info --title="Kedvenc szín" --text="Nem adott meg színt!"
fi

Az –entry-text kapcsolóval megadhatunk alapértelmezett értéket.

Egy fájl kiválasztása is dialógussal történhet, neve a –file-selection.

zenity5

Hogyan is kezeljük le. A dialógus alapvetően a standard kimenetre írja ki a kiválasztott fájl elérési útját, emellett az ablak visszatérési értéket is ad, amit a $? shell változóba rak.

#!/bin/bash
FAJL=$(zenity --file-selection --title="Válaszd ki a fájlt")
case $? in
0) zenity --info --title="Sikeres választás" --text="Fájl: $FAJL";;
1) zenity --info --title="Sikertelen választás" --text="Nincs kiválasztva";;
-1) zenity --error --text "Hiba történt!";;
esac

zenity6

Hasznos tud lenni a –scale, azaz skála dialógus, ahol egy szám értéket adhatjuk meg.

zenity7

Lekezelése hasonló a fenti skálához.

#!/bin/bash
MEKKORA=$(zenity --scale --title "Mekkora legyen?" 
--text "Add meg az értéket" --min-value=30 --max-value=200 --value=60)
case $? in
0) zenity --info --title="Sikeres választás" --text="Méret: $MEKKORA";;
1) zenity --info --title="Sikertelen választás" --text="Nem adtál meg értéket";;
-1) zenity --error --text "Hiba történt!";;
esac

Ha nem adunk meg opcionális beállításokat, akkor a 0 és 100 között választhatunk.

Kicsit bonyolultabb, de annál hasznosabb a –list, azaz lista dialógus, ahol kétféle is létezik. Van rádiógombos és jelölőnégyzetes változat. Nézzük a rádiógombosat először.

zenity8

#!/bin/bash
COLOR=$(zenity --list --title "Színválasztó" --text "Mi a kedvenc színed" --radiolist --column "Gomb" 
--column "Válasz" TRUE Bíbor FALSE Kék FALSE Zöld FALSE "Nem tudom")
case $? in
0) zenity --info --title="Sikeres választás" --text="Szín: $COLOR";;
1) zenity --info --title="Sikertelen választás" --text="Nem adtál meg értéket";;
-1) zenity --error --text "Hiba történt!";;
esac

Lássuk a másik lehetőséget a jelölőnégyzetes listát.

zenity9

#!/bin/bash
COLOR=$(zenity --list --title "Színválasztó" --text "Válaszd ki a kedvenc színeidet" --checklist 
--column "Válasz" --column "Színek" FALSE "Piros" TRUE "Zöld" FALSE "Fehér" TRUE "Narancs" --separator=":")
case $? in
0) zenity --info --title="Sikeres választás" --text="Szín: $COLOR";;
1) zenity --info --title="Sikertelen választás" --text="Nem adtál meg értéket";;
-1) zenity --error --text "Hiba történt!";;
esac

Mivel itt több értéket is kiválaszthatunk, ezért a –separator segítségével elválasztó karaktert definiálhatunk.

A barna színnel írt parancsot egy sorba kell írni!

zenity10

Még akad néhány érdekes dialóg, de ezeket találtam egyelőre fontosaknak.

Ha szeretnénk elérni ssh protokolon keresztül a rúterünket, de nem akarunk minden egyes alkalommal jelszókat beirosgatni, akkor használjuk a megszokott ssh kulcsot.

anon117@anon117box:~$ ssh root@192.168.1.1 -p 2211
The authenticity of host '[192.168.1.1]:2211 ([192.168.1.1]:2211)' can't be established.
RSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[192.168.1.1]:2211' (RSA) to the list of known hosts.
Permission denied (publickey).

Generálni kell egy kulcsot

anon117@anon117box:~$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/anon117/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/anon117/.ssh/id_rsa.
Your public key has been saved in /home/anon117/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx anon117@anon117box
The key's randomart image is:
+---[RSA 4096]----+
d[ o_0 ]b
+----[SHA256]-----+

Majd a tartalmát jelenítsük meg:

cat /home/anon117/.ssh/id_rsa.pub

Majd menjünk az OpenWRT Luci-ban a System – Administration menüben és ott az SSH-Keys résznél másoljuk be a fenti parancs kimenetét, Vagyis a publikus kulcsot. Majd Save & Apply.

És már működik is. Ugye ez más hasonló elven működő rendszereken is így megy, csak OpenWRT-n mutatom be. Sok sikert.

anon117@anon117box:~$ ssh root@192.168.1.1 -p 2211
BusyBox v1.23.2 (2015-07-25 15:09:46 CEST) built-in shell (ash)

_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
CHAOS CALMER (15.05, r46767)
-----------------------------------------------------
* 1 1/2 oz Gin Shake with a glassful
* 1/4 oz Triple Sec of broken ice and pour
* 3/4 oz Lime Juice unstrained into a goblet.
* 1 1/2 oz Orange Juice
* 1 tsp. Grenadine Syrup
-----------------------------------------------------
root@OpenWrt:~#

Ha szeretnénk egy karbantartási oldal készíteni az oldalunkhoz, akkor ezt szintén megtehetjük a RedirectRule szabály segítségével, íme:

# Karbantartas
RewriteCond %{REQUEST_URI} !^/karbantartas\.php$
RewriteRule ^(.*)$ /karbantartas.php [R=307,L]
Figyelem! Az átírányitás veszélyes is lehet. ha 301-es Redirect-et használsz, akkor azt a böngésző cache-be rakja. Ez permanens átírányitás, azaz tartós marad. Csak a böngésző cache-ének (gyorsítótárának) törlésével szabadulsz meg tőle. Ha ezt nem akarod, akkor használj 307-es Redirect-et, ez ideiglenes átirányítás, tehát ha kitörlöd a RewriteRule szabályt, utána megszűnik az átirányítás.

Figyelem! Helytelenül megadott feltétel vagy szabály esetén redirect loop, azaz átirányitási körbe eshet a böngésző.

hwc

Elég nagy téma, még a htaccess-en belül is, ezért inkább csak a lehetőségekről beszélnék. Dehogy miről is van szó:

Az Apache webszervernek van egy mod_rewrite modulja. Ezzel a modullal az URL-eket tudjuk manipulálni. Egyik legkedveltebb felhasználási területe a keresőbarát URL-ek kialakítása. De alkalmas átírányításra, süti kezelésre, és még sok másra is. Ahhoz, hogy használni tudjuk az Apache-nak be kell töltenie ezt a modult. Hogy ezt megtette-e, erről magunk is meggyőződhetünk.

<php
if(in_array('mod_rewrite',apache_get_modules())) {
  echo "A Rewrite modul elérhető.";
} else {
  echo "A Rewrite modul nem elérhető.";
}

vagy a phpinfo() függvény kimenetéből is kikereshető.

Készítsük elő a dolgot. A RewriteRule szabályokat egy .htaccess fájlba kell majd írnunk, ami alaphelyzetben rakjunk a DocumentRoot-ba. Hogy a szabályok működjenek be kell kapcsolni a motort:

RewriteEngine On

Néhány szó a RewriteRule felépítéséről:

RewriteRule minta helyetesítés flagek

Szemfülesek a minta szóból már gyaníthatják, hogy mintaillesztésről lesz szó, és igen. A RewriteRule használatához szükség van a reguláris kifejezések használatára. A működés lényege, hogy a szerver minden lekérdezéskor megvizsgálja az URL-t , és ha mintaegyezést talál, akkor helyettesítésben lévő URL-t használja a lekérdezésben lévő helyett. Nézzünk egy példát:

RewriteRule ^szam/([0-9]{1,2})/?$ hosszu_fajlnev_de_nagyon.php?szam=$1

htaccess1

<?php
echo $_GET['szam'];

Az URL-ből jól látszik a minta: http://localhost/szam/5, a minta egy egy vagy két jegyű számot vár.

Megadhatunk több mintát is ugyanarra a helyetesítésre is:

RewriteRule ^szam/([0-9]{1,2})/?$ hosszu_fajlnev_de_nagyon.php?szam=$1
RewriteRule ^szam/([A-Z]{1,2})/?$ hosszu_fajlnev_de_nagyon.php?szam=$1

Viszont ha nincs egyezés egyik mintára sem, akkor a rewrite modul Object not found – error 404 hibával leáll.

No de elemezgessünk egy kicsit.

^ – a minta eleje
() – csoport
[] – az itt felsoroltakra illeszkedés
{} – minimum, maximum előfordulás
? – mohóság ellen
$ – a minta vége

(Nem szándékozom reguláris kifejezéseket magyarázni ebben a bejegyzésben, az egy külön téma lenne, s elég nagy.)

A kerek zárójelekben lévő mintákra illeszkedő találatokat továbbvisszük a helyettesítés részbe, és ott $1, $2, … hivatkozunk rájuk. Tehát a fenti

http://localhost/szam/5

helyett a

http://localhost/hosszu_fajlnev_de_nagyon.php?szam=5

fogja az webszerver lefuttatni. Nézzünk egy másik példát:

RewriteRule ^city/([a-z0-9\-]+)/([a-z0-9\-]+)/?$ citycucc.php?megye=$1&varos=$2

Itt egy

http://localhost/city/bacskiskun/baja

URL illeszkedhet, amit erre cserél:

http://localhost/citycucc.php?megye=bacskiskun&varos=baja

A szabályok kiértékelését feltételekhez köthetjük,  amit a RewriteCond kulcsszóval használhatunk, felépítése:

RewriteCond tesztszöveg minta

Ha a tesztszövegben talált karaktersorozat illeszkedik a mintára (vagyis a feltétel igaz), akkor az alatta lévő szabály lefut.

RewriteCond %{HTTP_HOST} ^localhost
RewriteRule ^city/([^\/]*)/([^\/]*)/?$ citycucc.php?megye=$1&varos=$2

Mi is ez a %{HTTP_HOST}, elsődlegesen egy változó, aminek a formája ez:

%{valtozo}

másrészt a HTTP_HOST az ugye az Apache környezeti változója, ezeket sűrűn használjuk feltételek megadásánál. Néhány változó:

HTTP_HOST – localhost
HTTP_USER_AGENT – Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36
SERVER_NAME - localhost
QUERY_STRING – megye=bacskiskun&varos=baja
REQUEST_URI – /city/bacskiskun/baja
REQUEST_SCHEME – http

S így tovább. A többit lekérdezhetjük a PHP apache_getenv függvényével, phpinfo()-val.

Megadhatunk több RewriteCond feltételt is, ezeket egymás alá írjuk. Alapértelmezetten és kapcsolat van a feltételek között, de egy [OR] flag segítségével vagy kapcsolatot is használhatunk.

RewriteCond %{HTTP_HOST} ^localhost [OR]
RewriteCond %{REQUEST_SCHEME} ^https
RewriteRule ^city/([^\/]*)/([^\/]*)/?$ citycucc.php?megye=$1&varos=$2

Nem életszerű, de a lényeg látszik.

Mik azok a flag-ek. A Flag-ekkel megváltoztathatjuk a RewriteRule szabályok viselkedését. Mindenek előtt nézzünk egy példát.

RewriteCond %{HTTP_HOST} ^localhost [OR]
RewriteCond %{REQUEST_SCHEME} ^https
RewriteRule ^city/([^\/]*)/([^\/]*)/?$ citycucc.php?megye=$1&varos=$2 
[NC,L,CO=key01:true:%{HTTP_HOST}:1440:/]

(Az utolsó két sor egy sor, csak wordpress kutyulás miatt két sorba írtam.) A flag-eket vesszővel válasszuk el egymástól. Előjáróban néhány Flag:

CO – azaz cookie flag, ezzel süti kulcs-érték párokat állíthatunk be.
NC – kis- és nagybetű között nem tesz különbséget
L – Megállítja a feldolgozást. Ha a szabályra egyezés történt, akkor további szabályok már nem futnak le.
QSA – ha a REQUEST_URI-ban QUERY_STRING-et talál, akkor a helyettesítést megfelelően map-olja.

RewriteRule ^pages/(.+) page.php?page=$1 [QSA]

htaccess2

További flag-ek itt.

A bitbucket.org hasonló szolgáltatást nyújt mint a github.com. Én most egy példán keresztül mutatom meg a használatát.

A bitbucketet egy ssh kulcs segítségével fogjuk elérni. Ehhez léteznie kell a repo-nak a bitbucket-en.  Ezt létrehozva a megszokott módon használhatjuk.

git.2

A fenti rész különbséget tesz üres helyi repó, és már meglévő helyi repó között. Én a távoli (remote) repó hozzáadását ssh://git@ módszerrel szoktam elkövetni.

ssh1

Ahogy a halványpiros kijelölés mutatja is.

Ha ezeket beállítottuk el kell készíteni az SSH kulcsot.

ssh-keygen -t rsa -b 4096

Elkészült a privát és publikus kulcsunk, a publikust töltsük fel a bitbucket.org-ra. Ezt a Manage Accounts -> SSH keys menü résznél, és ott az Add keys gombra adhatjuk meg. A lenti tartalmat:

cat ~/.ssh/id_rsa.pub

Ha ez megvan ellenőrizzük, hogy látja-e a bitbucket.org?

ssh-keyscan -t rsa bitbucket.org

Kb. ennyi a történet.