VMware, OVA eta "Failed to deploy OVF package: The task was canceled by a user"

Azkenengo egunotan frogak egiten hasi naiz VMware vSphere Hypervisor-ekin (bere garaian VMware ESXi zena). Birtualizazio ingurune guztietan makina birtualen babeskopiak egin ahal izatea, edo template delakoak sortzea garrantzitsutsat jotzen dut, hori egiten saiatu naiz gaurkoan.

VMware, VirtualBox eta antzeko beste produktu batzuk, OVA/OVF formatua onartzen dute. OVF (Open Virtualization Format) estandar irekia da makina birtualak edo haien arteko softwarea banatu ahal izateko. OVF formatua berez direktorio bat da, non XML fitxategi bat dagoen, beste fitxategi batzuei erreferentzia egiten, adibidez diska irudi bat eta zertifikatu bat. Aipatutako OVA, OVF direktorioa da, tar-rekin artxibatuta fitxategi bakar batean.

VMwarek, OVA fitxategiak sortzen ditu makina birtual bat esportatzean, vSphere client bezeroarekin oso erraz egiten da, eta minutu batzuetan gure OVA fitxategia izango dugu, ederto! Erraza baino errazago…

Ondo, ezaugarri hau frogatzen dudan lehenengo aldia denez, saiatu naiz sortutako OVA fitxategi hori berriro inportatzen, vSphere client bezeroan “Deploy OVF template” laguntzailea aukeratu, pausu guztiak egin eta… justu inportatzen hasi denean akats bat! : “Failed to deploy OVF package: The task was canceled by a user” Ziur nago ez dudala ezer ukitu, baina badaezpada berriro exekutatu dut eta arazo bera!

Arazo bat zegoela argi ikusi dut, baina zein? VirtualBox-ekin OVA fitxategi bera inportatzea lortu dut arazo barik, beraz…

OVA fitxategiaren barruan zer zegoen erabaki dut, eta deskonprimatu ostean hiru fitxategiekin topo egin dut, espero nuen bezala:

• makina.ova -> OVFren deskripzioa XMLan, horretan hardwareko eskakizunak agertzen dira, adibidez diska gogorra eta bere izena


• makina.vmdk -> Makina birtualaren diska gogorra


• makina.mf -> .ova eta .vmdk fitxategien checksuma (SHA1 formatuan)

Interneten bilatu ostean, XML fitxategian .iso fitxategi batera errerentzia bat bilatu behar nuela ikusi dut, hori aldatzeko edo ezabatzeko… Antza VMwarek askotan gehitzen du antzeko sarrera bat fitxategi horretara, eta horixe da arazoak ematen dituena. Ba bai, vmware.cdrom.iso sarrera bat zegoen XML fitxategian, garrantzitsua ez zela ematen zuenez (kasurik okerrenean cd unitatea gehitzeko aukera izango nuke instalatu ostean) ezabatzea erabaki dut. vSpheretik berriro “Deploy OVF template” aukeratu…. eta “Checksum Invalid” akats polit bat jaso dut :( Zorionez dena ez zegoen galduta, SHA1 checksuma aldatu behar nuen edo… antza .mf fitxategi hori ez da horren garrantzitsua, eta ez egotekotan VMwarek ez du checksuma kontuan hartzen, beraz…

Fitxategi hori ezabatu, berriro “Deply OVF template” aukeratu eta… eureka! Makina birtuala arazo barik inportatu da!

Zelan ikusi talde politiken mezuak Windows 7 abiaraztean

Windows 7 argitaratu zutenetik faltan bota dut abiaratze azkenengo fasean informazio gehiago izatea. Nolabait Windows XP-k erakusten zuen informazioa izatea.

Informazio falta hau nabaria da software instalatzeko Talde Politikak erabiltzen ditugunean, zein paketea instalatzen ari den ez baitakigu, nahiko larria nire ustez instalaketa horrek huts egiten badu.

Zorionez, defektuzko portaera hori aldatzeko aukera daukagu Talde Politiken bitartez, bai gure domeinu osorako, bai makina konkretu baterako.

Aldatu behar dugun politika hauxe da:

Ingelesez:

Computer Configuration -> Policies -> Administrative Templates -> System -> Scripts -> Run Startup Scripts Visible

Gazteleraz:

Configuración del equipo -> Plantillas Administrativas -> Sistema -> Scripts -> Ejecutar scripts de inicio de forma visible

Zelan sortu kaiola bat (jail) FreeBSDn ezjail tresnarekin

FreeBSDn jail tresna esan dezakegu sistema eragile mailako birtualizazioa dela, gure FreeBSD sistema beste sistema txikiago batzuetan zatituz.

Asmoen artean sekuritatea da nagusi, sistema txikiago hauek (kaiolak) isolatuta baitaude host sistematik edo beste kaioletatik.

Jail mekanismoa nahiko ezaguna da FreeBSDn eta askotan erabiltzen da Virtual Hosting inguruetan. Nahiz eta FreeBSDk kudeatzeko tresnak dituen oinarrizko sisteman, beste tresna erosoagoak daude, ezjail eta warden, besteak beste.

Gure kasuan ezjail tresna erabiliko dugu, orduan instalatuko dugu:

# portmaster -d /usr/ports/sysutils/ezjail

Behin ezjail instalatuta, gure oinarrizko kaiola (basejail) sortuko dugu:

# ezjail-admin update -p -i

• -p aukerarekin portuak ere instalatuko ditugu gure oinarrizko kaiolan


• -i aukerarekin ez dugu make buildworld exekutatuko, horregatik komeni da gure kaiolak sortu baino lehen sistema erabat eguneratuta izatea.

Inoiz ez badugu ‘make buildworld’ exekutatu ftp zerbitzarietatik jaitsi dezakegu sistema, honela:

# ezjail-admin install

Ondo, gure oinarrizko kaiola sortu dugu (hau da, gure kaiola guztiek erabiliko duten fitxategi sistema), orain gure lehenengo kaiola sortuko dugu, imajina dezagun web zerbitzari bat (www.example.com) izango dela.

Lehenik eta behin sare txartel birtuala sortuko dugu, errazena alias bat sortzea da:

# ifconfig em0 192.168.66.2 netmask 255.255.255.255 alias

/etc/rc.conf fitxategian hau jarriko dugu berrabiaraztean sare txartel 'berria’ izateko:

# ifconfig_em0_alias0="inet 192.168.66.2 netmask 255.255.255.255"

Ez dugu ahaztu behar dugu sare maskara 255.255.255.255 izan behar dela beti alias bat sortzean. Orain bai, gure kaiola sortuko dugu!

# ezjail-admin create www.example.com 192.168.66.2

Ikusiko dugu nola ezjail-ek sortuko duen gure kaiola berria eta agian kexatu egingo dela zerbitzu batzuk IP helbide guztietan entzuten ari direla, hori ekiditeko gure zerbitzu horiek egokitu beharko ditugu banan-banan, beharrezkoa dela uste badugu.

Egokituko dugu gure kaiola berriko konfigurazioa /usr/local/etc/ezjail/www_example_com fitxategian, batez ere hostname eta ip helbideak.

Orain frogatuko dugu gure kaiola ondo dabilen, lehenengo ta behin rc.conf-era ezjail zerbitzua gehituko dugu:

# echo 'ezjail_enable="YES"' >> /etc/rc.conf

Eta…

# /usr/local/etc/rc.d/ezjail start

Ados, badirudi martxan dagoela,… eta orain? Zelan sartu kaiolan? Ikusteko gure kaiola guztiak eta zein egoeratan dauden:

# ezjail-admin list

Gure kaiola berrian sartzeko:

# ezjail-admin console www.example.com

Gure kaiola berrian gaude, eta behar dugun software instalatzeko aukera daukagu, sistema arrunt bat izango balitz moduan. Beste gauza batzuen artean kaiolako /etc/resolv.conf fitxategia egokitu beharko dugu, sistema arrunt batean bezalaxe. Ssh zerbitzari bat aktibatzea ere ez da ideia txarra, kaiolan sartu ahal izateko sisteman lehenago sartu barik.

Berezitasun batzuk ere egon badaude kaiolekin ibiltzean. Adibide gisa, ezin dugu ping egin kaiola batetik, instalatu berri dugunean raw socket-ak desaktibatuta daudelako (dig eta whois ondo badabiltza sare konexioa badaukagu). Aktibatzeko hauxe egingo genuke gure host sisteman (ez kaiolan bertan).

# sysctl security.jail.allow_raw_sockets=1

sysctl aukera guzti hauek jail(8)-n topa ditzakegu, baina kontuan izan behar dugu erabat beharrezkoak ez badira hobe dela jatorrizko aukerak mantentzea, aldatzean. sekuritate maila jaisten baita.

Azkenik, kaiolak eguneratuko ditugu host sistema eguneratzen dugunean, orduan gure host sisteman 'make installworld’ egin ostean:

# /usr/local/etc/rc.d/ezjail stop

# ezjail-admin update -i

# /usr/local/etc/rc.d/ezjail start

Kaiolek eskuragarri daukaten portuen zuhaitza eguneratzeko hau egingo dugu host sisteman:

# ezjail-admin update -P

Ta ale, zerbitzuak kaiolatzera!!!

Zelan aldatu apurtutako diska bat gmirror batean

  Zerbitzari bat konfiguratzen dudanean, sistemako diskak RAID batean sartzeko ohitura daukat. Segun zenbat diska eta zein konfigurazio mota behar dudan RAID maila bat edo bestea aukeratzen dut, baina askotan RAID1 erabiltzen dut. Eskarmentuagatik RAID kontrolatzaileak (hardware) ez dira beti oso bateragarriak izaten eta askotan software RAID erabili nahiago dut, horretarako FreeBSDn gmirror(8) erabiltzen dut.

Aurreko astean bat-batean zerbitzari batek arazoak zeuzkala zirudien, mirror hori apurtuta zegoenaren abisua jasotzen bainuen… Diska bat apurtuta agian? SMART frogak dena ondo zegoela zioen, baina gehiegi fidatzen ez nintzenez (batez ere portaera ikusita, mirror-a berreraiki, dena ondo eta berriro apurtu egun pare bat pasa…) diska sakontasunean aztertzea erabaki nuen, eta horretarako gehienetan ez ditugu tresna konplexuegiak behar, irakurtze froga besterik ez, horrela egin nuen:

# dd if=/dev/da1 of=/dev/null

Eureka! dd ez zen bukatzeko gai izan, frogaren erdian i/o arazo bat zegoela esan eta bertan behera uzten zuen prozesua, berdin SMARTek zer zioen, diska hori txarto zegoela argi zegoen. Beraz aldatzera…

Horretarako pausu sinple batzuk eman behar. Lehendabizikoa apurtutako diska makinatik atera eta gure gmirror estrukturatik ezabatu:

# gmirror forget ispilua ('ispilua' nire gmirror RAIDeko izena da)

Gmirror bat izango dugu diska bakarrarekin, orain diska berria sartuko dugu makinan eta izan dezakeen informazioa ezabatu:

# gpart destroy -F /dev/ad1

Eta azkenik sartu berri dugun diska gure gmirror estrukturan sartu:

# gmirror insert ispilua /dev/da1

Eta listo! Zelan berregiten den RAID1a ikusi nahi badugu hurrengoa besterik ez dugu egin beharko:

# gmirror status

Erraza oso, ezta?

Zelan aktibatu SPDY/HTTPv2 protokoloa Nginx web zerbitzarian

Aurreko post batean Nginx zerbitzaria konfiguratu genuen PHP eta SSLrekin. Nginx zerbitzariko azkenengo bertsioak (1.4.0 bertsiotik hain zuzen ere) SPDY moduloa dakar. Baina zer da SPDY?

SPDY sare protokolo “berri” bat da, Googlek garatuta gehienbat. SPDY eta HTTP nahiko antzekoak dira. SPDYren helburua webguneetako karga latentzia jaistea da, sekuritatea hobetzen aldi berean. Horretarako, besteak beste konpresioa eta multiplexaketa erabiltzen ditu.

Interesgarria dirudi, ezta? Gainera ia-ia arakatzaile guztiek onartzen dute, Chrome, Firefox eta Opera esanguratsuenak izanik. Beraz, bateragarria denez HTTP protokoloarekin ez dugu ezer galtzen gure nginx web zerbitzarian gaitzeagatik.

Aktibatzeko Nginx portuan SPDY edo HTTPv2 aukera gaituko dugu (nginx bertsioaren arabera), ikusten dugunez HTTP_SSL ere gaitu behar dugu, beharrezkoa baita SPDY erabili ahal izateko. Konfigurazioa aurreko post horretan bezala baldin badaukagu, SPDY erabili ahal izateko, hurrengo direktiba besterik ez dugu aldatu behar:

listen 443;

Nginx 1.9.5 bertsiotik HTTPv2 moduloak SPDY ordezkatu du, beraz, bertsioaren arabera hau gehituko diogu aurreko lineari:

1.9.5 bertsioa baino lehenago:

listen 443 spdy;

1.9.5 bertsioan eta ondorengoetan:

listen 443 http2;

Eta listo! Martxan daukagu SPDY/HTTPv2 gure Nginx zerbitzarian. Gure nabigatzailearekin konprobatu nahi badugu, gehigarri bat instala dezakegu:

• Firefox: SPDY indicator


• Chrome: SPDY indicator

Zelan eguneratu FreeBSD-ko iturburua subversion erabiliz

Urteak dira FreeBSD erabiltzen hasi nintzenetik (14 gutxi gorabehera) eta hasieratik gustukoen izan dudan ezaugarria izan da sistemaren eguneraketa mota. Iturburua jaitsi, nire beharretara egokitu, konpilatu..(ezagun batek esan dit behin bahino gehiagotan Matrix filman bezala letrak ikusi nahi ditudala nire pantailan mugitzen etengabe… batek daki, izan leike!)

FreeBSDko iturburua jaisteko beti erabili izan dut cvsup tresna, eta ostean bere berrinplementazioa csup… baina denbora aurrera doan heinean proiektuak aldaketa batzuk egin ditu, eta haien artean eguneraketa mota, subversion sistemara aldatu. Saiatuko naiz azaltzen egun zelan egiten ditudan eguneraketak (eguneratzeko beste era batzuk egon badaude, ziurrenik errazagoak, baina nik hau nahiago dut, askotan letra gehiago ikusten baitira teminalean ;-) )

Hasi baino lehen argi izan behar dugu direktorio honetan sistemaren tresnak (userland) eta kernela daudela, arkitektura ezberdinentzako. FreeBSDko garapen modeloa ere ezagutu behar dugu, berez hiru adar nagusi topatuko ditugu:

• FreeBSD-CURRENT: Adar horretan azkenengo garapen eta frogak egiten dira. Aldaketa hauek hurrengo bertsioan (RELEASE) izango daitezke, baina ez beti. Batzutan kode hau konpilatu daiteke arazo barik, eta bestetan akatsak direla eta ezinezkoa da, garatzileek konpondu arte. Ingelesez esaten den bezala, adar hau “bleeding edge” da, amildegi ertzean ibiltzea bezala da, batzutan eror zaitezke, beraz nik behintzat ez nuke inoiz adar hau erabiliko produkzioan, baina aldi berean oso dibertigarria da frogak egiteko makina batean (etxekoan be bai, noski, inporta ez bazaizu noizean behin aldaketa sakonak egiten egotea)


• FreeBSD-STABLE: Adar hau esan dezakegu RELEASE baten ondorengo garapenak sartzen direla, hurrengo RELEASE prestatzeko asmoz. Egun adibidez FreeBSD 9.1 bertsioan dago (hauxe izango litzateke gure RELEASE bertsioa), STABLEa esan dezakegu 9.1-RELEASE iturburuaren fork bat dela, 9.2-RELEASE prestatzeko. Batzutan akats txiki batzuk egon daitezke, baina orokorrean nahiko egonkorra da, eta ez dira akats larriak izaten, beraz aproposa da mahaingain bezala erabiltzen dugun makina baterako. Zerbitzarietan ere erabil dezakegu, baina nik behintzat normalean ez dut erabiltzen RELEASE adarrean ez dagoen kontrolatzaile bat erabili behar ez badut.


• FreeBSD-RELEASE: Hauxe da FreeBSDko adar egonkorrena, honetan segurtasun konponketak besterik ez da sartzen, beraz egokiena da zerbitzarietan erabiltzeko. Esan dezakegu momentu batean FreeBSD-STABLE-ko adarraren snapshot bat egiten dela eta hori da argitaratzen dena, egun 9.1-RELEASE bertsioan dago FreeBSD.

Orain gutxi gorabehera zertxobait ulertzen dugula FreeBSDko garapenari buruz, has gaitezen eguneraketekin. Subversion erabiliko dugunez ba… ohikoa den moduan:

# portmaster -d /usr/ports/devel/subversion

Jatorrizko aukerak erabiliko ditugu eta konpilatzen utzi ondoren, erabiliko dugun tresna badaukagu.

/usr/src (hemen FreeBSDko world (userland) eta kernela dago)

Lehenengo aldia subversion erabiliko dugu iturburua jaisteko, segun zein adar erabili nahi dugun hauetako bat aukeratuko dugu:

CURRENT
# svn checkout https://svn0.eu.freebsd.org/base/head /usr/src

STABLE
# svn checkout https://svn0.eu.freebsd.org/base/stable/9 /usr/src

RELEASE
# svn checkout https://svn0.eu.freebsd.org/base/releng/9.1 /usr/src

Beste zerbitzari bat aukeratu nahi badugu dagokion Handbook-eko atalean begiratuko dugu, eta beste bertsio bat kontsultatu nahi badugu FreeBSDko subversion web interfazean bilatuko dugu ( http://svnweb.freebsd.org/ )

Baina beno, badaukagu gure /usr/src datuekin, eta eguneratu nahi badugu? Erraza baino errazagoa:

# svn up /usr/src

/usr/ports

FreeBSDko portuetako sistemak beti erabiltzen du HEAD adarra (CURRENT antzekoa) beraz, /usr/src atalean azaldu dugunez:

# svn checkout https://svn0.eu.freebsd.org/ports/head /usr/ports

Eta eguneratzeko aurreko kasuan bezalaxe:

# svn up /usr/ports

/usr/doc

Eta azkenik, FreeBSDko dokumentazioak beti erabiliko du HEAD adarra (CURRENT antzekoa), ports sistemak bezala, orduan:

# svn checkout https://svn0.eu.freebsd.org/doc/head /usr/doc

Eta eguneratzeko…

# svn up /usr/doc

 … eta azkenik

Sarrera honetan aipatu dudan bezala, beste era batzuk daude FreeBSD eguneratzeko. Adibidez ports sistema eguneratzeko normalean portsnap(8) tresna erabiltzen dut, FreeBSD sistema bera (World eta Kernela) eguneratzeko beste batzuk freebsd-update(8) erabiltzen dute… Zure esku!

Zelan konpondu 'Unknown error code during application install: "-24"' akatsa Androiden

Gutako askok ohitura daukagu ROM “ez ofizialak” instalatzeko gure Android dispositiboetan, bai fabrikatzaileak eguneraketak eskuragarri jartzen ez dituelako, edo ROM hoietako batek nahi dugun kapazitate bat daukalako.

Askotan ROM hauekin izenburuko akatsa izaten dugu aplikazio bat eguneratzen saiatzean, konponbidea nahiko erraza da:

Hauxe ekiditeko ROM horri dagozkion Google Apps-ak instalatu ostean “Factory reset” egin beharko dugu edo bestela aplikazio batekin akats hori jasotzen dugunean, /data/data direktorioan (root baimenak behar ditugu) aplikazio horren direktorioa ezabatu.

Zelan berezarri software instalaketak talde politiken bitartez

Onartu behar dut Windowseko Active Directory-k daukan zerbait oso erabilgarria talde politikak direla (Group Policies), batez ere gure Windows sarean software instalatu behar badugu automatikoki, ordu nahikotxo aurreztu ditzakegu (Samba 4 bertsioarekin frogatu behar dut ea posiblea den…)

Baina… zer gertatzen da instalaketa hauek txarto doazenean? Edo kontrol paneletik desinstalatzen badugu? Microsoft-ek ez du aukerarik ematen software hori berrinstalatzeko!

Baina jakina, zer instalatu den eta zer ez nonbait ezarrita gelditu behar da, eta… jakina, Windowseko erregistroan!

Interesatzen zaigun sarrera hauxe da:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt

Horretan sarrera bat izango dugu talde politiken bitartez instalatutako software bakoitzeko, berrinstalatu nahi duguna ezabatu eta shell batean gpupdate /force exekutatu beharko dugu… ostean ordenagailua berrabiaraziko dugu eta… :)

Squid proxy gardena FreeBSDn

Proxyak berez, bitartekariak dira, eta haien artean webeko proxyak ezagunenak dira. Kasu honetan web proxya instalatuko dugu gure sarean, proxy gardena, hain zuzen ere, bezeroek inolako konfigurazioa behar ez dezaten.

Ezagunenen artean Squid daukagu eta hori da erabiliko duguna, beraz… Has gaitezen:

# portmaster -d /usr/ports/www/squid (squid-3.5.12)

Port konfigurazioan agertuko zaizkigun aukeren artean hauek erabiliko ditugu:

ARP_ACL (Gaitzen dugu ARP/MAC/EUI autentikazioa, ez dugu beharko)
DOCS (Dokumentazioa eskura izatea beti izaten da ideia ona)
EXAMPLES (Dokumentazioa bezalakoa)
FS_AUFS (IO Asinkronoa erabiliko dugu diska sarbidea arinagoa izateko)
HTCP (HTCP Protokoloa)
ICAP (Honekin ICAP bezero ezaugarriak gehituko dizkiogu gure proxy-ri, etorkizunean adibidez ClamAV gehitzeko)
IDENT (Ident bilaketak, RFC 931)
KQUEUE (Kqueue)
SNMP (SNMP bidez estatistikak har ditzakegu)
TP_PF (Proxy gardena montatzeko PF suebakia erabiliko dugu)
WCCP (Web Cache Coordination Protocol)
WCCPV2 (Web Cache Coordination Protocol v2)

Behin instalatuta gure proxy-a konfiguratzen hasiko gara, lehenik eta behin, kontuan izan behar dugu squid proxy garden bezala erabiltzeko, honek irakurtzeko baimena izan behar duela /dev/pf “fitxategian” (Gogoratu PF erabiliko dugula berbideraketak egiteko). Horretarako /etc/devfs.conf fitxategia aldatuko dugu, honako hau gehituz:

# Eman baimena Squid-i /dev/pf irakurri ahal izateko
own pf root:squid
perm pf 0640

devfs zerbitzua berrabiaraziko dugu:

# /etc/rc.d/devfs restart

Port aukeretan komentatu dugu IO asinkronoa erabiliko dugula, horretarako modulo bat kargatu behar dugu FreeBSDn:

### Moduloa /boot/loader.conf
aio_load="YES"

Ondo! Prest gaude gure /usr/local/etc/squid.conf fitxategia gure beharretara egokitzeko!

Ikusiko dugu /usr/local/etc/squid direktorioan defektuzko squid.conf fitxategia badaukagula, aldaketa txiki batzuk egingo ditugu horretan

### IPv6 erabiliko ez dugunez, komentatuko ditugu hurrengo bi lerroak
#acl localnet src fc00::/7 # RFC 4193 local private network range
#acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines

### Gure proxy gardena izango da, beraz hurrengoa gehituko dugu
http port 3128 #lerro hau badago jatorrizko fitxategian
http_port 3129 intercept #portu honetara berbideratuko dugu http trafikoa

# Gure katxe tipo eta tamaina. aufs erabiliko dugu diskorako
# sarbidea asinkronoa izateko, gure katxea non izango dugun
# eta bere tamaina (MBtan, eredu honetan 2GBkoa izango da),
# eta direktorio estruktura
cache_dir aufs /var/squid/cache/squid 2048 16 256

# Onartuko ditugun datuen tamaina
minimum_object_size 0 KB
maximum_object_size 200 MB

cache_mgr proxymgr@example.com
visible_hostname proxy.example.com
unique_hostname proxy.example.com

# Zelan ordeztu behar dituen datu zaharrak gure proxy-ak
cache_replacement_policy heap LFUDA

Beste direktiba batzuk alda ditzakegu, adibidez gure sare lokalaren tarteak, baina kasu gehienetan honekin nahikoa izango dugu.

Konfigurazio fitxategiaren direktiben azalpen zehatzagoa (askoz zehatzagoa) topatuko ditugu /usr/local/etc/squid/squid.conf.documented fitxategian, eta ez da ideia txarra hara jotzea benetan zer egiten ari garen jakiteko, badakizu, RTFM!

/etc/rc.conf fitxategian hurrengoa gehituko dugu Squid abiarazteko sistemarekin batera:

# /etc/rc.conf
squid_enable="YES"

Ondo, squid abiarazi baino lehen katxe direktorioak sortu behar ditugu, horretarako:

# squid -z

Beno, itxura polita dauka honek, baina azken pausu batzuk falta dira. Gure Squid zoragarria gateway bezala arituko da gure sarean, beraz, FreeBSD-n router gaitasuna aktibatu behar dugu:

# /etc/rc.conf
gateway_enable="YES"

Efektu bera lor dezakegu hurrengo honekin, baina berrabiaraztean… badakizu, ezta?:

sysctl net.inet.ip.forwarding=1

Ondo, squid konfiguratuta, FreeBSD badabil gateway moduan… baina… http trafikoa ez doa proxy-tik! Gogoratu Squid 3128 eta 3129 portuetan ari dela entzuten, ez 80an, beraz PF erabiliko dugu trafiko hori berbideratzeko joan behar den lekura:

# /etc/pf.conf
# $int_if gure barneko sare txartela (edo sare txartelen taldea) # izango da
rdr pass on $int_if inet proto tcp from any to any port www -> 127.0.0.1 port 3129

PF erabiliko dugunez, gure rc.conf fitxategian…:

# /etc/rc.conf
pf_enable="YES"
pf_rules="/etc/pf.conf"

Azkenik zerbitzu guztiak martxan jarriko ditugu eta… Squid garden bat izango dugu martxan gure sarean

Zelan babestu webguneak htpasswd fitxategiekin nginx zerbitzarian

Askotan babestu behar dugu gure webgunea pasahitz batekin, nginxek (apache bezala) hau onartzen du era erraz batean.

Horretarako gure webguneko konfigurazioan hurrengoa ezarriko dugu babestu nahi dugun atalean (adibide honetan webgune osoa babestuko dugu):

location  /  {
  auth_basic            "Sarrera mugatua";
  auth_basic_user_file  htpasswd;
}

htpasswd fitxategia sortuko dugu apacheko htpasswd tresna erabiliz edo esteka honetan agertzen diren tresnekin.

Sortutako fitxategia /usr/local/etc/nginx direktorioan utziko dugu. Ez ahaztu baimenak (400) eta jabea aldatzea (www:www)!!!

nginx.org-eko dokumentazio ofiziala

FreeBSD + nginx + php + ssl

Gehienetan web zerbitzari bat montatu behar dudanean Apache erabiltzen dut, batez ere erabiliena delako eta sarean dokumentazioa topatzea nahiko erraza baita. Dena den, batzutan beste arrazoiengatik, batez ere web zerbitzua emango duen makina nahiko zaharra denean beste zerbitzari bat erabiltzen dut, nginx.

Gidatxo honetan php eta ssl-rekin instalatuko dut, horren gainean beste zerbitzuak montatu ahal izateko…

Hasiko naiz, beraz, nginx instalatzen nire gustukoa den portmaster tresnarekin:

# portmaster -d /usr/ports/www/nginx

nginx port konfigurazioa agertuko zaigu modulu gehigarriak aukeratzeko, defektuzko konfigurazioa erabiliko dut, HTTP_SSL_MODULE gehituz (barruko zerbitzuetarako SSL erabiltzen dut beti). Dependentzietan defektuzko konfigurazioa erabiliko dut, eta ale, konpilatzera!

Nginx zerbitzarian PHP erabiliko dugu, beraz portu hau instalatuko behar:

# portmaster -d /usr/ports/lang/php5

php5 portu konfigurazioan FPM aukera markatu behar dugu, hori erabiliko baitugu nginx zerbitzarian, beste guztia defektuzko aukerekin.

Badaukagu beraz PHP eta nginx instalatuta, zerbitzuak rc.conf-era gehituko ditugu:

# echo 'php_fpm_enable="YES"' >> /etc/rc.conf
# echo 'nginx_enable="YES"' >> /etc/rc.conf

Honelako zerbitzari bat montatzean normalean VirtualHosts sortzen ditut, etorkizunean moldagarriago izateko, beraz direktorio estruktura sortuko dut honela:

# mkdir /usr/local/www/conf
# mkdir /usr/local/www/sites

conf azpidirektorioan gure webguneetako konfigurazioa jarriko dut, webgune bakoitzak bere konfigurazio artxiboa izanik. example.org webgunea sortuko dut orain:

# mkdir /usr/local/www/sites/example.org
# mkdir /usr/local/www/sites/example.org/data
# mkdir /usr/local/www/sites/example.org/logs
# mkdir /usr/local/www/sites/example.org/ssl

Data direktorioan gure webgunea izango dugu, logs eta ssl direktorioetan ba… azaldu behar da?

Gure webgunerako estruktura sortuta daukagu dagoeneko, webgune honek PHP erabiliko duenez, index.php artxibo bat sortuko dugu dena ondo dabilen ziurtatzeko:

# echo "<?php phpinfo(); ?>" > /usr/local/www/sites/example.org/data/index.php

Ondo, badaukagu gure webgunea, baina ez dugu oraindik nginx konfiguratu! Oraintxe egingo dugu. Horretarako /usr/local/etc/nginx/nginx.conf artxiboa editatuko dugu:

worker_processes  1;
events {
    worker_connections  1024;
}
http {
        include                     mime.types;
        default_type                application/octet-stream;
        server_tokens               off;
        sendfile                    on;
        keepalive_timeout           65;
        client_body_timeout         10;
        client_header_timeout       10;
        send_timeout                10;
        client_body_buffer_size     1K;
        client_header_buffer_size   1k;
        client_max_body_size        1M;
        large_client_header_buffers 2 1k;
        include /usr/local/www/conf/*.conf;
}

Azter dezagun zeintzuk diren direktiba garrantzitsuenak:

• server_tokens off: Hau nginx-eko bertsioa ez argitaratzeko erabiltzen dugu.


• ‘include /usr/local/www/conf/*.conf’ : Hemen izango ditugu gure Virtual Hosts-etako konfigurazioa.

Ondo, badaukagu gure nginx konfiguratuta, baina zerbait faltan daukagu, gure Virtual Host!!!

/usr/local/www/conf/example.org.conf

server {
	listen       80;
	server_name  example.org www.example.org;
        access_log /usr/local/www/sites/example.org/logs/access.log;
	error_log /usr/local/www/sites/example.org/logs/error.log error;
	error_page   500 502 503 504  /50x.html;
	location = /50x.html {
	    root   /usr/local/www/nginx-dist;
	}
	location / {
	    root   /usr/local/www/sites/example.org/data;
	    index  index.php index.html index.htm;
	}
	location ~ \.php$ {
	    root           html;
	    fastcgi_pass   127.0.0.1:9000;
            #fastcgi_pass   unix:/var/run/php_fpm.sockets;
	    fastcgi_index  index.php;
	    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
	    include        fastcgi_params;
	}
}

Orain zerbitzuak abiaraziko ditugu:

[root@nginxjail ~]# /usr/local/etc/rc.d/php-fpm start
[root@nginxjail ~]# /usr/local/etc/rc.d/nginx start

Badabil? :)

Baina… ez dugu esan ssl erabiliko dugula? Aurreko konfigurazioan ez da inon agertzen ssl-i buruzko ezer!

Aldaketa txiki batzuk egin behar dizkiogu konfigurazio horri:

/usr/local/www/conf/example.org.conf

server {
        listen 80;
        server_name  example.org www.example.org;
        rewrite ^ https://$server_name$request_uri? permanent;
}
server {
        listen 443;
        server_name  example.org www.example.org;
        access_log /usr/local/www/sites/example.org/logs/access.log;
        error_log /usr/local/www/sites/example.org/logs/error.log error;
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }
        location / {
            root   /usr/local/www/sites/example.org/data;
            index  index.php index.html index.htm;
        }
        location ~ \.php$ {
            root           html;
            fastcgi_pass   127.0.0.1:9000;
            #fastcgi_pass   unix:/var/run/php_fpm.sockets;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include        fastcgi_params;
        }
        ssl                  on;
        ssl_certificate /usr/local/www/sites/example.org/ssl/server.crt;
        ssl_certificate_key /usr/local/www/sites/example.org/ssl/server.key;
}

Aztertzen badugu konfigurazio artxibo berri hau, ikusiko dugu gure zerbitzariak 80 eta 443 ataketan entzuten duela. Rewrite horrekin 80 atakara heltzen diren eskaera guztiak berbideratuko ditugu 443 atakara, ssl behartuz… Aparte ssl modea aktibatu eta gure zertifikatuak azaldu behar ditugu.

Erraza, ezta? Ba…

# /usr/local/etc/rc.d/nginx restart

Orain bai! On egin!

Zelan abiarazi Mac OS X single user eran

1. Amatatu Mac ordenagailua.


2. Mac ordenagailua abiarazi power botoia sakatzen.


3. Sakatu Command tekla (sagarra daukana) eta hurrengoetako bat aldi berean:

• “s” tekla single user eran abiarazteko.


• “v” tekla verbose eran abiarazteko.

Zergatik FreeBSD?

Urteak dira Unix eta “Unix-alike” sistemak erabiltzen hasi nintzenetik, 15 urte gutxi gorabehera txarto gogoratzen ez badut. Denbora guzti honetan honelako sistema asko erabili ditut, haien artean SCO Unix, Solaris, Linux mota ezberdinak (Slackware, RedHat, Debian, Ubuntu, RHEL, CentOs eta antzekoak…). Egun sistema bati erabat lotuta dagoen zerbitzu bat erabili behar ez badut, sistema eragilea hautatzean nire erabakia oso argia da, FreeBSD.

Orain dela aste batzuk, lagunen artean (Affligem kupelatxo batekin lagunduta), haietako batek honelako galdera egin zuen: “Zergatik erabiltzen duzu FreeBSD?” (hauxe dena gertatu zen beste lagun baten portatila eguneratzen ari nintzen bitartean freebsd-update tresnarekin ;-) )

Hasiera batean nire erantzuna honelakoa izan zen: “Eroso nagoelako, gauzak bere lekuan daudelako, estrukturatuta, ports sistema…”

Aste hauetan galdera horri buelta batzuk eman dizkiot, erantzun zehatzagoa emateko asmoarekin. Galdera hori Linux erabiltzaile-administrari batek egin zuen, beraz nire burutazio batzuetan Linux hartu dut kontrapuntu gisa.

FreeBSD erabiltzeko arrazoi gehiago badaukat, baina nagusienak honako hauek dira:

• Egonkortasuna: FreeBSDk ospe handia dauka bere egonkortasunagatik, eta hau eskarmentuak baieztatu dit. 12 urtez erabili dut FreeBSD eta ez dut inoiz sistemari leporatuta egonkortasun arazorik izan (hardware arazoak izan ezik). Hau zoritxarrez ezin dut esan beste sistema eragileei buruz, ospetsuak diren “Enterprise” bertsio horiek barne… (Solaris izan da antzeko lasaitasuna eskaini didan bakarra). Honetan ziurrenik zerikusi handia dauka FreeBSDko garapenak, Kernela eta oinarrizko sistema batera garatzen baitira.


• FreeBSD oso ondo antolatuta dagoen sistema bat da, arlo guztietan. Fitxategi sistema (oinarrizko sistema leku batean dago, eta instalatutako programak beste leku batean, ez dena nahastuta!), kernela, konfigurazioak… gauzak bere lekuan azken finean. Ez naiz ibili behar leku batetik bestera konfigurazio fitxategiak bilatzen, eta jakina, xaman jantzia ez dut jantzi behar zerbitzu bat zelan abiarazi jakiteko!


• Ports sistema: Onartu behar dut hasieratik maiteminduta nagoela software hedapen sistema honekin. Batzutan ez dut eskuragarri izango ‘x’ softwareko azkenengo bertsioa, baina egonkortasuna da helburu nagusia. Nahiago dut ondo dabilen programa bat, nahiz eta bertsioa pixkat zaharkituta izan (oso gutxitan gertatzen da hau), akats pilo dauzkan oso eguneratutako beste bertsio bat baino.


• Dokumentazioa: Honi buruz zer esan, oso jende gutxi ezagutzen dut FreeBSDko dokumentazioaren kalitatea zalantzan jartzen duenik. Ondo sailkatuta, irakurtzeko erraza… FreeBSD Handbookak eredua izan beharko luke beste proiektu askotarako.


• FreeBSD eta orokorrean BSD komunitateentzat teknologia da helburu nagusia, ez lizentziak edo nolabaiteko aktibismo politikoa, askatasunak (mota ezberdinak daude, antza, gero eta mota gehiago esango nuke nik…) eta horrelakoak. Jakina, Linux munduan dena ez da horrelakoa, baina askotan bai nabaritzen direla aspektu hauek, eta integrismoa sortzen da. Onartzen dut batzutan neuri ere gustatzen zaidala lizentziei buruz eztabaidatzea, baina normalean hori gertatzen denean garagardo batzuk daude tartean… (bale, beste batzuk sabelean dagoeneko!)


• … eta azkenik, eta ziurrenik arrazoi garrantzitsuena… nahi dudalako :)