El primer pas serà comprovar els vostres coneixements en linux, xarxes, etc.

Disclaimer: això podria ser utilitzat per trencar xarxes wireless de veïns i similars. És per això que introdueixo voluntàriament un error en el què posaré a partir d’ara. Vull que entengueu lo vulnerables que poden ser aquestes xarxes i com hem de mirar de protegir les xarxes wifi nostres i dels nostres clients, aquest és l’objectiu d’aquesta sessió, no faig això perquè després la gent vagi fent coses que no toquen…

Comentari: l’any 2009, a punt de començar el 2010 trobo ABSURD el provar d’anar trencant xarxes wireless dels veïns. Tenim accés gratuït a internet a biblioteques i similars (alguns centres cívics, bars, etc). El cost d’un notebook s’ha rebaixat notablement: es poden veure coses mínimament presentables per 200€ a grans magatzems. L’accés via mòdem de telefonia mòbil és molt més econòmic que fa uns anys. Si no tens calés, una alternativa plausible és et compres pel cost d’una ADSL durant 7 mesos un notebook, vas tirant de biblioteques, descarregant-te via lector de feeds rss i client de correu les webs i els correus, els llegeixes a casa i guardes les respostes, tornes cada X temps (o amb mòdem)  a respondre només quan calgui.

I si entrem a discutir les connotacions legals doncs molt pitjor encara, en el sentit que si fas servir l’ADSL del veí, això vol dir que et connectes amb la IP del veí, si tu et descarregues coses via la IP del veí, això vol dir que quan prohibeixin i penalitzin aquestes coses el marrón s’ho emportarà ell. No és només una qüestió legal, és també una qüestió MORAL.

Per seguir aquesta sessió farem servir el programa aircrack-ng. Podeu trobar un bon tutorial sobre la qüestió a la pàgina dels companys de SomGNU.cat.

Tot això ho faré via linux, concretament les instruccions les posaré de tal manera que serveixin tant per Ubuntu com per Debian (les dues distribucions que em conec més). He tornat a provar i comprovar que això funciona, i m’ha funcionat amb dues menes de tarjes diferents, tant pel fixe, amb un pinganillo USB wifi, com amb la wifi integrada del notebook.

El primer pas pels usuaris d’Ubuntu serà:

sudo su 

i introduir la nostra password. Així ja podrem treballar tota l’estona com a superusuari. A Debian serà directament:

su 

I lo mateix, introduïm la nostra password.

Un cop fet això, instal·larem els paquets que ens interessen:

aptitude install aircrack-ng wireless-tools

Per poder configurar el maquinari, el segon pas serà fer un iwconfig:

iwconfig 

I ens sortirà una cosa semblant a això:

chryse-feina:/home/feina# iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wmaster0  no wireless extensions.

wlan0     IEEE 802.11bg  ESSID:"xavinet"
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:13:F7:E1:19:F2
          Bit Rate=1 Mb/s   Tx-Power=12 dBm
          Retry min limit:7   RTS thr:off   Fragment thr:off
          Encryption key:B00F-D7DD-C3D9-2F25-A4DF-E9F3-EC61-32CE-ECFA-E05B-D2B9-FFF8-2750-D7BE-15C6-9AC3 [3]   Security mode:open
          Power Management:off
          Link Quality=42/70  Signal level=-68 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

chryse-feina:/home/feina# 

I ens ensenyarà quines són les tarjes de xarxa que en tenim i quina connexió tenim a internet. La que ens interessa quina és? la que posa wlan0, que ens dona tremenda informació sobre com és la nostra connexió.

Què ens hauria sortit si no en tinguéssim de connexió associada? doncs una cosa així:

ath0      IEEE 802.11g  ESSID:""  Nickname:""
          Mode:Managed  Frequency:2.437 GHz  Access Point: Not-Associated
          Bit Rate:0 kb/s   Tx-Power:14 dBm   Sensitivity=1/1
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=0/70  Signal level=-96 dBm  Noise level=-96 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
 

Evidentment, canviant ath0 per wlan0. AVÍS: les tarjes de xarxa ath0 solen donar problemes, si voleu com resoldre’ls, en teniu una petita guia aquí (somgnu.cat):

Llavors, un cop fet tot això, podrem posar la nostra tarja en mode monitor, i ens sortirà una cosa així:

 iwconfig wlan0 mode monitor 

Preparem un directori aircrack per guardar tota la informació capturada:

mkdir /home/feina/aircrack

cd /home/feina/aircrack/

I llavors podrem començar a escannejar xarxes fent servir la comanda airodump-ng

airodump-ng -w capturapaquets wlan0

I ens sortirà una cosa així:

O bé, en un altre exemple més interessant (crec):

Primer anem a entendre el què estem fent:

Estem capturant paquets (beacons). Aquests paquets no són estrictament paquets TCP/IP, sinó, per entendre’ns una mena de senyals que va enviant l’access point per tal de donar la seva presència. D’aquests els paquets que ens interessaran seran els Data, són aquests els paquets que ens interessaran per adquirir quanta més informació possible sobre la xarxa de la que volem adquirir aquesta informació.

Quan trobem la xarxa d’internet en la què estem interessats el següent pas és centrar-nos en la xarxa en particular de la que volem adquirir més informació. Per tant:

 airodump-ng --bssid XX:XX:XX:XX:XX:XX --channel N -w capturapaquets ath10

Sent el bssid XX:XX:XX:XX:XX:XX la MAC de la xarxa i el channel N el canal wifi per on es comunica.

Llavors veurem en la part de baix de la terminal els ordinadors que es connecten a aquell router. Això ens pot afavorir molt el nostre procés. Exemple.

El pas següent serà injectar tràfic entre l’ordinador que hem vist i el router. Això farà que s’incrementi el nombre de paquets DATA que rebem. Això ho farem mitjançant la comanda aireplay-ng

aireplay-ng --arpreplay -b XX:XX:XX:XX:XX:XX -h YY:YY:YY:YY:YY:YY ath10

Sent XX:XX:XX:XX:XX:XX la mac del router i YY:YY:YY:YY:YY:YY la mac de l’ordinador connectat.

En paraules dels companys de somgnu.cat:

“Podreu comprovar que la columna Data comença a pujar ràpidament.

I ara?. Doncs ara hem d’esperar a aconseguir un total de 100.000 – 500.000 paquets de data (no beacons). Una vegada fet, tindrem un fitxer amb el nom “rita” (en el nostre cas) a dins del directori /home/pau/aircrack amb extensió .cap que és el que ens servirà per obtindre la contrasenya. ”

El següent procés serà llençar el programa aircrack-ng pròpiament dit. Què farà aircrack? Amb la informació que hem obtingut i que s’ha anat guardant al directori que li hem dit farà un atac matemàtic i estadístic fins obtenir la pass adient de la xarxa. Això es farà amb la comanda següent:

aircrack-ng  fitxercaptura

I ens sortirà la pass sobre la pantalla de la terminal.

Comentaris sobre la qüestió:

1.- Triga molt? depén del número de paquets, de la complexitat de la password i particularment del mètode d’encriptació en que circul·len les dades dintre de la xarxa. Servidor, amb l’exemple que us comento, vaig trigar aproximadament una hora i mitja en capturar els paquets de la xarxa de casa meva (li havia posat el nom i la password que tenia per defecte). I aproximadament una altra hora en llençar el programa aircrack fins que va trobar-la. Sobre el notebook que és un ordinador amb un gran processador de baix consum però no gaire rendiment en comparació amb un ordinador de sobretaula.

2.- Per més inri lesoperadores telefòniques d’aquest país inclouen unes passwords per defecte que són com per riure. Mirem-nos aquest text del company Alex Castán Salinas.

3.- I perquè és tant fàcil, doncs perquè el protocol WEP és molt insegur. Hi han pàgines a internet on explica com carregar-se aquestes passwords …en només deu minuts, que no sé jo fins a quin punt això és possible, però sí que és molt més fàcil del què sembla. I no és que WEP sigui un mal protocol, simplement és que els temps, la capacitat de processament dels ordinadors i la qualitat dels routers i de les tarjes inalàmbriques han fet que capturar un nombre mínim de paquets sigui molt més fàcil que en el passat.

Conclusió: És molt important que quan gestionem una xarxa wireless (si és empresarial en la meva opinió a aquestes alçades és obligatori, i si és domèstica molt recomanable):

1.- Li canviem el nom d’origen i la pass d’origen i li posem alguna cosa que no ens identifiqui i que no sigui vulnerable a un atac per diccionari. Bon exemple de pass seria: “f31n44act1v43sunp0rt4ld3tr3b4ll” A veure quin és el diccionari que ho troba.

2.- Entrem al nostre router i li canviem el protocol d’encriptació per WPA o WPA2. Explicar aquests protocols se’ns faria molt feixug ara, però sí que vull que entenguem que fan molt més complicat l’obtenir la password via atacs com els d’aircrack. S’ha d’incrementar el nombre de paquets capturats, s’ha de fer diccionaris i etcètera. Com configurar el nostre router (depén del model) Com entrar al nostre router 2.

3.- En la meva opinió la millor política de seguretat és anar canviant la contrassenya del WIFI cada X temps. Quan més petit sigui aquest període X més assegurem la nostra xarxa.

4.- I sinó, si tot plegat falla, evidentment a grimpar cable i tirar cable i cablejar

Aquesta sessió tindrà quatre parts.

1.- Abans de parlar de programari lliure, parlarem una mica d’informàtica:

Tipus d’ordinadors

D’ordinadors n’hi ha de moltes menes, però pels usuaris finals jo en distingeixo principalment 3 tipus, que serien els ordinadors tradicionals “fixos” o de torre, els ordinadors portàtils i els ordinadors ultraportàtils.

Els ordinadors fixos o de torre, tenen avantatges i inconvenients. Entre els avantatges figuraria que són ordinadors que a igualtat de preu amb un ordinador portàtil o ultraportàtil en tenen moltes més prestacions que els portàtils i els ultraportàtils, que són més fàcilment reparables i se’ls hi pot ampliar la capacitat de memòria, de disc dur, posar targes de so o de vídeo per ampliar aquestes capacitats amb molta més facilitat que en un ordinador portàtil, on sovint ni tant sols es pot arribar a plantejar.  Els desavantatges serien que són ordinadors que consumeixen més energia que un ordinador portàtil i que a més, hi ha el tema de la manca de mobilitat. No és el mateix portar a la motxil·la un portàtil o ultraportàtil que haver de fer tot el muntatge de muntar i desmuntar un fixe. Si tens un ordinador portàtil o ultraportàtil igual no et cal connexió en aquell mas o finca aïllada on estàs, si dos cops a la setmana baixes a la biblioteca del poble (amb connexió wifi) amb un portatil o ultraportatil… Per tal que ens fem una idea dels preus d’aquests ordinadors val més que rumiem en que un de nou pot costar-nos a partir d’entre 300 i 400 €, pantalla, teclat, ratolí i impressora a banda (uns altres 120€ tot plegat). A l’hora de comprar aquests últims components cal que tinguem en compte de no comprar ni teclat ni ratolí a piles (sempre et deixen tirat a l’últim moment a banda d’elementals complicacions mediambientals) i que no ens deixem enganyar mai pel preu de les impressores, doncs tot i que ens semblin relativament econòmiques s’ho cobren després en els recanvis dels cartutxos (un element per cert dels més contaminants que n’hi ha -metalls pesants- i sempre sempre sempre s’han de portar a reciclar).

Sobre com tocar, muntar i desmuntar ordinadors fixes n’hi han centenars de llocs web a internet. Jo recomano aquest, tot i ser antic: PC World step by step, i aquestes transparències del company Àlex Castán (a partir pàgina 17). També podeu consultar aquesta documentació sobre maquinari del CFGM d’Explotació de Sistemes Informàtics de l’Institut Obert de Catalunya (mogollón de documentació que ens pot ser útil)

Els ordinadors portàtils tenen evidentment com a gran avantatge la seva portabilitat i la possibilitat de funcionar sense connexió directa a la xarxa elèctrica. Aquestes dues coses evidentment s’han de mirar amb una certa prevenció, davant l’arribada dels ultraportàtils aquests ordinadors serien com una mena d’estadi a mig camí entre una cosa i l’altra: és veritat que són portables, però si cada cop que t’has de posar un a l’esquena penses “segur que me l’haig d’emportar?” perquè pesa dos kilos i pico, si la seva autonomia real és inferior a dos o tres hores, doncs igual tampoc és la solució per la gent que necessita portabilitat extrema. Per un altre cantó, tot i que a igualtat de preu tenen menys potència que un ordinador fixe, estan més a prop d’aquesta potència que un ordinador ultraportàtil. Per tal que ens fem una idea de preu, podem trobar coses més o menys decents ara a partir de 300-400€. Com veiem els ordinadors portàtils s’han abaratit en els darrers anys, d’igual manera que la nostra disponibilitat de calés. Són per tant, una solució de compromís entre un ordinador potent que puguem baixar de quan en quan a una biblioteca o similar, on tampoc no ens calgui massa autonomia.

Els ordinadors ultraportàtils, són aquells com aquest que tinc al davant en aquest moment. Aquests ordinadors tenen tres avantatges principals que se’n diuen: preu, portabilitat i autonomia. Són l’opció més econòmica, a partir de 200-250€ en pots trobar a grans magatzems i similars. Pesen molt poc, sobre la meitat d’un portàtil estàndard i l’últim avantatge és que tenen molta autonomia, fins a 9 hores o així, depenent del model i del sistema operatiu (malauradament si fas servir gnu/linux la teva autonomia és un xic inferior a la dels sistemes windows). Si vius en un mas aïllat sense gaire corrent elèctric i vols un ordinador d’extremadament baix consum, el teu ordinador és aquest. És cert que són models menys potents que un ordinador fixe o portàtil nou econòmic actual, però també és veritat que són ordinadors comparables en prestacions als ordinadors de fa tres o quatre anys, no són carraques. I en realitat nosaltres tenim ordinadors molt més potents del què necessitem per les nostres tasques quotidianes.

Ordinadors de baix consum. En determinades situacions és molt important tenir-ne ordinadors de baix consum. Hem vist que els ordinadors ultraportàtils poden ser una solució bastant interessant en aquest sentit, gràcies als seus processadors interns Intel Atom, un processador no gaire ràpid però realment amb un consum molt baix. En entorns domèstics, amb ordinadors fixes, una opció molt interessant són els ordinadors amb processadors de baix consum. Aquesta tecnologia s’ha desenvolupat principalment per ordinadors pensats com a estació multimèdia pel menjador de casa (ordinadors on tens les pelis, la música, i d’aquí a uns quants anys control·laran la domòtica domèstica), i que, com que han d’estar connectats permanentment doncs consumeixen molt, d’aquí la necesitat de desenvolupar processadors que consumissin poc. Tota aquesta tecnologia de baix consum elèctric informàtic s’ha desenvolupat arran d’aquesta necessitat i també pel tema del soroll: una de les maneres de reduir soroll als ordinadors és reduir l’ús i les velocitats dels ventiladors, una manera de fer això és reduir la necessitat de disipar el calor, per tant baixar el consum, fer servir més dissipadors de coure enlloc de ventiladors, fer servir fonts d’alimentació de baix consum, etc. No m’estendré sobre el tema, aquí teniu més informació d’un processador per ordenador fixe de baix consum molt interessant: l’AMD 5050e. És el que faig servir jo i en sóc molt fan . Més informació ( un i dos) sobre com construir ordinadors silenciosos i de baix consum. Un lloc on podeu comprar els components per internet. Més informació sobre el consum elèctric d’un ordinador.

Ordinadors i medi ambient La importància del reciclatge i la reutilització dels ordinadors. Els ordinadors són de lluny un component que està entre el luxe i la necessitat. Per una banda cada cop es fa més necessari per poder fer-lo servir per treballar, comunicar-se, etcètera. Per una altra banda, la gent realment fa servir ordinadors excessivament potents per les seves necessitats (es va arribar a la lluna amb 40 kB de memoria RAM i ara els ordinadors domèstics tenen 4 Gb de RAM, 100 mil vegades més potents, i els fem servir per llegir el correu i veure vídeos al youtube). Mirem aquestes transparències del company Àlex Castán. (més informació). Més informació sobre la qüestió del coltán (un i dos).

2.- Programari lliure

* En primer lloc estudiarem l’història i evolució del Linux des dels seus inicis fins a l’actualitat:

Per tal de fer això serà necessari entendre els següents conceptes bàsics:

- Dintre de tot ordinador hi ha un sistema operatiu, cada sistema operatiu té una sèrie característiques i hi han diversos tipus.

- Els sistemes operatius i  els programes d’ordinador s’han programat mitjançant els anomenats llenguatges de programació. Un què és bàsic per entendre la història dels sistemes Unix/Linux és el llenguatge de programació C. Si seguim l’enllaç últim veurem el clàssic exemple “hola, món” d’aquest llenguatge de programació. Aquest exemple estarà escrit en l’anomenat codi font del llenguatge.

- L’any 1969 es va crear un sistema operatiu anomenat UNIX amb una sèrie de característiques molt determinades que el van fer molt avançat per la seva època. El sistema operatiu que estudiarem nosaltres, el sistema conegut com a Linux, o millor dit GNU/Linux (que és com l’anomenarem a partir d’ara) deriva  dels sistemes Unix. Mirem un petit exemple. I comprovem que la línea de comandes és molt semblant, que la terminal és molt semblant i que l’arbre de directoris (com comprovarem meś endavant) és molt semblant.

- Una sèrie de persones, com en Richard Stallman van percebre com un problema el fet que el sistema UNIX fos tancat, per tant, que el seu codi no es podés ni examinar ni millorar ni copiar (examinarem més endavant aquestes qüestions). Aquest “tancament” que va ser més aviat tot un procés progressiu que es va anar donant al llarg dels anys, va fer que el sr. Stallman iniciés un projecte anomenat GNU l’any 1983 (qui tingui molt interès es pot llegir el manifest GNU alliberat l’any 1985), amb l’objectiu de crear un sistema que fos completament lliure. Per tal de gestionar tot això, es va crear la Fundació per al Programari Lliure (Free Software Foundation). El sr. Stallman va començar el procés per crear aquest sistema operatiu que fos completament lliure però enlloc de començar pel nucli del sistema va començar per les aplicacions més importants del sistema, com el compilador del llenguatge de programació GCC, o un editor que al seu moment va ser revolucionari: Emacs. De fet GNU continua tirant endavant el desenvolupament d’un nucli propi: GNU/Hurd, un projecte revolucionari (arquitectura de microkernel) …que malauradament fa molts i molts anys que s’està desenvolupant i encara no ha arribat a una versió completament estable.

- Pel camí, mentre el sr. Stallman anava barallant-se amb el tema de crear un sistema GNU, un estudiant d’informàtica finlandés: Linus Torvalds, després d’estar durant 5 anys jugant i familiaritzant-se amb la programació en llenguatge C i últimament amb un Unix (Minix), va crear i alliberar l’any 1991 un petit nucli de sistema que era capaç d’executar alguns programes GNU, com el compilador GCC (necesari per crear més programari) i l’interpret de línia de comandes conegut com a BASH shell. (Qui tingui més interés en conéixer filosofia extrema sobre línia de comandes, li recomano molt aquest enllaç

- El gran salt del kernel Linux va ser quan va començar a fer servir la llicència pública general, coneguda popularment com a GPL, implementada per la GNU del sr. Stallman. Això va ser l’any 1992. De sobte tothom podia com aquell qui diu “ficar-hi les mans”, modificar, distribuir, etc.

- I així va ser com de manera potser una mica inopinada la gent va començar a empaquetar programari junt amb el kernel i les aplicacions GNU/Linux i les van començar a distribuir lliurement. D’aquí el concepte de distribució de GNU/Linux. Entre les primeres van figurar: SLS, Yggdrasil, Slackware… Al ser programari lliure es van multiplicar, moltes distribucions estaven basades en algunes altres amb alguna millora o característica innovadora.

- D’entre aquestes distribucions nosaltres sobretot destacarem tres, tot i que en podríem destacar moltes altres per moltíssimes raons:

* Debian. La distribució Debian neix l’any 1993, amb l’objectiu de crear una distribució que separi clarament el programari lliure del no lliure i que estigui gestionada i administrada mitjançant el treball voluntari dels seus membres. Aquests objectius estaran recollits a l’anomenat Debian Manifesto. Entre les característiques més importants de Debian figurarien: un sistema d’empaquetament del programari que gestiona considerablement bé les dependències del programari, un fort èmfasi en l’estabilitat del sistema, més que en tenir el programari a la última. Aquesta característica la fa un sistema ideal per a muntar servidors (tot i que hi ha també moltes distribucions molt recomanables en aquest sentit com seria la mateixa Red Hat)

* Ubuntu. Ubuntu GNU/Linux és una distribució enfocada a l’usuari final d’escriptori, més que a servidors (tot i que també). Els seus escriptoris (a la versió Ubuntu es tractaria de l’escriptori Gnome) estan molt cuidats i actualitzats, a l’igual que els nuclis que fa servir, tot i que aquesta facilitat relativa d’instal·lació i configuracio si la comparessim amb d’altres distribucions té el problema que inclou programari no lliure en forma de drivers pel nucli. Està basada en Debian i té el mateix sistema de paquets per empaquetar, instal·lar i desinstal·lar programari. Tot i que és un sistema lliure, està patrocinat per l’empresa Canonical.

* Linkat. La Linkat és una distribució potenciada des del departament d’educació de la Generalitat catalana, tot i que tenen la intenció d’estendre el seu ús no únicament a l’àmbit educatiu sinó a tota l’administració autonòmica catalana. Basada en les distribucions Suse, Novell i OpenSuse. Per tant, el sistema de paquets és diferent del de Debian i Ubuntu. En realitat les diferències més importants que tindrà amb les distribucions Debian i Ubuntu serà principalment el sistema de paquets, i, per si de cas, l’estudiarem quan toqui. Les primeres impressions dels usuaris d’aquesta distribució són pel que es veu van ser més aviat positives (més enllà d’algun debat canònic sobre les llicències).

Evidentment tot aquest desenvolupament que ha tingut el programari lliure es deu entre d’altres raons a l’ús de llicències lliures. Veurem a la segona part de la classe les més importants i les seves característiques:

* La primera qüestió quan es parla de programari lliure són les famoses quatre llibertats del programari lliure (com estem entre informàtics evidentment numerat 0,1,2 i 3).

* La primera llicència del pack serà evidentment la GPL, ja mencionada, publicada i mantinguda per la Free Software Foundation. Aquesta llicència va per la versió 3, tot i que encara es fa servir molt la versió 2 (per exemple al kernel, el sr. Torvalds no en vol sentir a parlar de fer servir la versió 3 al kernel Linux).

* Un altre tipus de llicència molt estés serien les llicències de tipus BSD. Es distingiria de les llicències GPL perquè simplement no restringeixen tant la distribució de programari (un podria arribar a apropiar-se del programari sota aquesta llicència).

* Una altra mena de llicències serien les Creative Commons. Aquestes llicències no estarien dirigides només a àmbits informàtics sinó més aviat cap a àmbits acadèmics, culturals i musicals. Permeten una àmplia varietat d’usos i llibertats dels productes que estan llicenciats sota les seves llicències, de més restrictiu i de menys. Teniu més informació aquí.

* En aquest punt hauria d’haver quedat prou clara la història del Linux i una mica l’evolució del programari lliure que ens va portar fins a ell -la història del programari lliure és molt més àmplia que la història d’un kernel i un sistema operatiu associat, però nosaltres arribarem fins aquí, qui en vulgui saber més pot llegir l’excel·lent llibre Codi Rebel-. s’ha de mencionar a un altre personatge en aquesta història: Eric S. Raymond. Programador per exemple del programa fetchmail, escriptor, pensador, assagista, va teoritzar el model de desenvolupament del programari lliure basat en la cultura de la col·laboració a l’assaig “La catedral y el bazar“.

3.- Instal·lació de GNU/Linux Ubuntu

El tema de com instal·lar un sistema Ubuntu GNU/Linux se’n surt una mica de l’àmbit de la sessió, més que res per temps, simplement us recomano que aneu a aquest lloc web on s’explica de manera molt planera com instal·lar-se un sistema GNU/Linux Ubuntu sense problemes.

Això sí, recomanacions prèvies:

a) Còpia de seguretat de tot el contingut que ens pensem que ens pot caldre per treballar. Val més que abans d’esborrar el contingut del disc, agafem paper i boli i en pensem durant una molt bona estona si realment hem fet còpia de tot el que voldríem, fitxers ocults i directoris on guardem correus, bookmarks, certificats del firefox, programes PADRE, etc. Que som tots i jo el primer un pel descuidats.

b) Una altra possibilitat és compartir el disc dur amb un sistema windows previ. Això sempre acaba donant algun que altre problema, per això, de totes maneres i per si de cas, es fa la còpia de seguretat prèvia. I a més, es fa ús de la comanda del windows defrag, per defragmentar el disc dur. Atenció que si el disc dur és massa gran pot trigar molt a defragmentar-se.

Perquè recomano fer servir Ubuntu i no cap altre sistema? per una raó, i és que malgrat que Ubuntu és d’una empresa i no és tant lliure en aquest sentit com Debian, que és una distribució que la porta una fundació sense ànim de lucre, realment està molt cuidada de cara a l’usuari final, d’una manera una mica contradictòria, perquè també inclouen parts de programari propietari, sobretot drivers de cara a l’ús de determinats dispositius (tarja gràfica, wifi, habitualment).Una opció possible (la que jo recomano) és començar amb la Ubuntu i quan tens prou temps d’ús, anar canviant cap a distribucions que en principi cuiden més aquests aspectes (debian, però també gnew sense, etc).

Dintre d’Ubuntu hi han de moltes menes, fluxbuntu, xubuntu, kubuntu, edubuntu, etc. Quina hem de fer servir? jo recomano fer servir la Ubuntu clàssica estàndard i no complicar-se la vida. Si veiem que va massa lenta en un ordinador poc potent, ja podriem inclinar-nos per fluxbuntu o bé per Xubuntu, variants d’Ubuntu que tenen entorns gràfics menys potents però que consumeixen menys recursos. Si ens tira correctament, crec que sobretot per gent que comença millor no complicar-se la vida.

Una possibilitat que no puc deixar de mencionar, els que em coneixeu ja ho sabeu , és com fer una instal·lació xifrada d’ubuntu, primer per un elemental sentit de la nostra privacitat, i segon per una qüestió de seguretat: si al teu ordinador hi tens contrassenyes, o dades personals teves o de clients, doncs igual no és plan que si te’l roben aquestes dades estiguin en mans d’algú altre. Això a la última Ubuntu és una opció que et donen, xifrar el contingut del teu directori personal (ja no cal xifrar tot el sistema). Això ho fem instal·lant el plugin de seahorse.

Més informació sobre la post-configuració d’un sistema Ubuntu i sobre com instal·lar i desinstal·lar programes. Informació també interessant sobre la nova aplicació d’Ubuntu, una mena de disc dur en xarxa on podem tenir les nostres dades: Ubuntu One. Aplicació maxi brutal de comptabilitat per una petita empresa: bulmagés, com instal·lar-la a la ubuntu i un bon manual de bulmagés (en línia).

4.- Xarxes

Conceptes bàsics: què és un router, què és un mòdem… En principi no m’hi vull posar ara amb els grans conceptes superteòrics sobre que és internet o TCP/IP. Nosaltres simplement entendrem això a un nivell pràctic: router serà aquella eina que connecta una xarxa (com internet) amb la nostra xarxa (domèstica, sovint d’un sol ordinador). Un mòdem és simplement una eina que connecta només un ordinador amb la xarxa internet.

Tipus de connexions (ethernet o wifi), internet per mòdem, internet per satèl·lit. Tipus de connexions hi han dos: la connexió per ethernet i la connexió per wifi o sense fils.
Xarxes wifi gratuïtes (biblioteques, ajuntaments, etc)
Xarxes autogestionades (guifi.net)
Construcció d’antenes

5.- Aplicacions de les xarxes. Hem explicat ni que sigui breument com fer una instal·lació de GNU/Linux, com connectar-se a internet (alternatives possibles), però ara parlem-ne, ens cal realment una connexió a internet? I si ens cal serà per

1. llegir correu (evolution)
2. consultar informació (liferea)
3. publicar informació (servidors gratuïts -> blogspot, wordpress, servidors de moviment -> entodaspartes.net, sindominio.net, noblogs.org)
4. fer mailings massius (PHPlist)

Zimbra 5, suite de mensajería y colaboración

fuente: http://linuxsilo.net/articles/zimbra.html

Por Jaume Sabater, publicado el 1 de octubre de 2008.

Índice

1. Introducción

2. Arquitectura

3. Componentes de la arquitectura

   1. Zimbra Core

   2. Zimbra LDAP

   3. Zimbra MTA

   4. Zimbra Store

   5. Zimbra SNMP y Zimbra Logger

4. El cliente web

5. El servidor Zimbra

6. Network Edition

7. Requerimientos

8. Seguridad

9. Instalación en Debian Etch

10. Mejoras en el sistema antispam

11. Whitelisting

12. Instalaciones distribuidas (multiservidor)

13. Instalación de un sistema multiservidor

    1. Instalación de LDAP, SNMP y Proxy

    2. Instalación de Store, Logger y Spell

    3. Instalación de Zimbra MTA

    4. Ajustes finales

14. Problemas con Zimbra Logger

15. Uso de memoria RAM y swap

16. Bibliografía

17. Historial de revisiones

Introducción

Zimbra Collaboration Suite (ZCS) es una innovadora suite de mensajería y colaboración de código abierto. Se ofrece bajo la licencia Yahoo! Public License (YPL), versión 1.1, en forma de una versión de código abierto, sin coste de licencias alguno, y otra versión de pago con varios componentes extras de código cerrado y con coste de licencias. Está disponible para diversas plataformas y distribuciones de Linux y para MacOS X.

En muy poco tiempo, Zimbra se ha convertido en la solución de código abierto líder a nivel mundial tanto para empresas como para proveedores de servicio, centros educativos y administraciones públicas. La clave de este éxito se basa en el uso de tecnologías de código abierto y protocolos de comunicación e intercambio de datos estándares y ya consolidados, que han combinado de manera adecuada y completado con características que no estaban cubiertas pero que son claves para las empresas. Una completa documentación y un amplio abanico de comandos de consola específicos dotan a esta suite de enormes capacidades de integración con entornos existentes.

Cuatro son los pilares de la arquitectura del producto:

• Flexibilidad: fácil personalización según las necesidades de la organización.

• Libertad: uso de cualquier navegador web y de aplicaciones de escritorio tradicionales.

• Durabilidad: servidor de correo electrónico y calendario extraordinariamente fiable y ampliable.

• Bajo coste de mantenimiento: gestión muy sencilla, tanto mediante una interfaz gráfica como desde la consola.

ZCS se divide en tres módulos principales:

• Cliente web.

• Servidor.

• Extras.

A continuación se explicarán las características de la Open Source Edition de Zimbra para pasar luego a añadir aquellas propias únicamente de las versiones de pago.

Arquitectura

Zimbra Collaboration Suite está formada por un conjunto de componentes que trabajan juntos para formar una solución completa. El núcleo del servidor está escrito en Java, utilizándose Jetty como servidor de aplicaciones. El servidor se integra con otros sistemas como el MTA, la base de datos y los paquetes de seguridad.

El agente de transferencia de correos (del inglés, Mail Transfer Agent o MTA) enruta los mensajes de correo al servidor de Zimbra. Este servicio está basado en el popular Postfix. Integrado a través de Postfix, Zimbra incorpora varios filtros de seguridad, como antivirus y antispam, entre otros. Asimismo, el MTA puede integrarse con otras tecnologías, como Postgrey para greylisting o Spamhaus para DNSBL, u otras soluciones de seguridad comerciales, como los AV/AS de Barracuda Networks. Asimismo, soporta por defecto los protocolos principales de cifrado de canal, SSL y TLS. Los filtros en el lado del servidor mediante James/Sieve le ponen la guinda al pastel.

También incluido en Zimbra Collaboration Suite hay diversos almacenes de datos para la información de los usuarios: OpenLDAP proporciona la autenticación, MySQL guarda las preferencias y metadatos de los mensajes y el sistema de ficheros guarda directamente los mensajes de correo.

Otro componente integrado en Zimbra es Lucene, un potente motor de indexación y búsquedas que permite a los usuarios y administradores buscar mensajes a través de múltiples carpetas de correo, tanto metadatos como contenidos en el cuerpo del mensaje.

En términos generales, las funcionalidades ofrecidas por Zimbra son muy similares a las de Microsoft Exchange, aunque está mejor preparado para ser utilizado por proveedores de hosting y tiene algunas características de colaboración que Exchange no tiene. Además, una gran diferencia la marcan los bindings de SOAP que permiten integraciones de terceros que amplien las funcionalidades de Zimbra.

Componentes de la arquitectura

La arquitectura del sistema está formada por los siguientes componentes:

Zimbra Core

Zimbra Core incluye las librerías, utilidades, herramientas de monitorización y ficheros básicos de configuración.

Zimbra LDAP

Dada la gran diversidad de servicios y aplicaciones asociadas a los servicios de que suele disponerse hoy en día, tener un directorio de usuarios basado en LDAP es, de cada vez más, una necesidad. Zimbra Collaboration Suite utiliza por defecto OpenLDAP para almacenar y gestionar el almacén de usuarios, integrando de serie el soporte para la replicación. Además, permite fácilmente su configuración para el uso de directorios LDAP externos, incluyendo Active Directory de Microsoft o eDirectory de Novell, entre otros.

El esquema LDAP de Zimbra está disponible por si deseamos utilizarlo en una instalación LDAP ya existente, facilitando de esta manera la gestión centralizada de las cuentas de usuario de nuestra instalación. Cada cuenta tiene un identificador único de buzón de correo, que representa el punto principal de identificación en todo el sistema. El esquema de OpenLDAP ha sido modificado para adaptarlo a las necesidades de ZCS.

Zimbra MTA

Uno de los componentes claves de cualquier solución de mensajería hoy en día, el servidor de correo electrónico de Zimbra está formado, como es habitual, de diversas partes:

• Un MTA (del inglés, Mail Transport Agent).

• Un almacén de buzones de correo accesible por IMAP4 y POP3, con soporte para cifrado del canal mediante (SSL).

• Unos filtros de contenidos (antivirus y antispam).

Zimbra utiliza Amavis como filtro de contenidos y, por defecto, SpamAssassin y ClamAV como filtros antispam y antivirus, respectivamente. De todos modos, es posible configurarlo para que utilice cualquier otro filtro antispam, como Dspam, o antivirus. El correo se recibe mediante SMTP, se enruta mediante una tabla de transportes y se entrega al almacén de correo haciendo uso del protocolo LMTP.

Zimbra Store

Zimbra Store, utilizando Jetty como contenedor de servlets, almacena el correo electrónico. Cada cuenta se configura en un servidor, y esta cuenta está asociada con un buzón de correo que contiene todos los mensajes y ficheros adjuntos. El servidor de buzones está formado por:

• El almacén de datos.

• El almacén de mensajes.

• El almacén de índices.

• Las utilidades de conversión de adjuntos a HTML.

Cada servidor de Zimbra tiene su propio almacén de datos, almacén de mensajes y almacén de índices para los buzones de ese servidor. En cuanto llega un correo, el servidor de Zimbra crea un nuevo proceso para indexar el mensaje. También se crea un hilo para la conversión de adjuntos a formato HTML, que a su vez es indexado por otro hilo.

El almacén de datos es una base de datos MySQL en la cual los los identificadores de mensajes son enlazados con las cuentas de usuario. El almacén de datos relaciona el identificador del buzón con la cuenta de usuario a la que pertenece en el directorio LDAP. Esta base de datos contiene el conjunto de etiquetas definido por el usuario, las carpetas, las citas del calendario y los contactos de los usuarios, así como el estado de cada mensaje de correo (leídos, no leídos, etiquetas asociadas a cada mensaje y la carpeta en la cual reside el mensaje).

El almacén de mensajes guarda todos los mensajes y sus adjuntos en formato MIME (del inglés, Multipart Internet Mail Extension). Los mensajes enviados a múltiples destinatarios dentro del mismo servidor sólo son almacenados una vez.

La tecnología necesaria para indexar y buscar la proporciona Lucene. Se mantienen índices sobre cada buzón.

Zimbra SNMP y Zimbra Logger

La instalación de ambos paquetes es opcional, pero muy recomendada. En cada servidor donde esté instalado, Zimbra SNMP recoge información periódica del estado del sistema. Además, utiliza Swatch para analizar la salida del syslog y generar los traps de SNMP.

Por su parte, Zimbra Logger instala herramientas de agregación de logs, informes y seguimiento de mensajes. Sin este paquete no se podrán utilizar las funcionalidades de seguimiento de mensajes y estadísticas del servidor de la consola gráfica de administracion.

El cliente web

Zimbra incorpora un cliente web que hace un uso extensivo de AJAX (del inglés, Asynchronous Javascript and XML) y que se ejecuta en la mayoría de los navegadores web más habituales, como Firefox, Safari e Internet Explorer. Debido al uso intensivo de Javascript, las diferencias en la experiencia del usuario son enormes dependiendo del navegador, siendo Opera y Safari los mejores e Internet Explorer 6 el peor. En cualquier caso, el cliente web de Zimbra permite utilizar una versión sólo con HTML que es muy recomendable para equipos antiguos pero que, asimismo, ofrece una usabilidad muy buena.

El cliente web de Zimbra ofrece unas avanzadas funcionalidades, casi al mismo nivel que una aplicación de escritorio, pero con la ventaja de poder utilizarlo desde cualquier lugar y desde casi cualquier navegador. Su gestor de correo permite, entre otros:

1. Agrupar los correos por conversación, ahorrando así espacio en la pantalla.

2. Construir, de manera gráfica, búsquedas avanzadas y guardarlas para su posterior reutilización.

3. Etiquetar contenidos.

4. Ver documentos adjuntos sin necesitar ninguna aplicación externa.

La gestión de contactos de Zimbra es muy completa, ya que soporta múltiples libretas de direcciones (tanto personales como de cuentas del sistema), compartición de contactos, autocompletado y creación de listas de distribución personales.

El calendario compartido es una de las características más destacadas de Zimbra, con capacidad para detectar, visualizar y corregir solapamientos. Permite gestión de recursos (salas de reuniones, proyectores, etc.), programación de reuniones en grupo con delegación del aceso, compartición y publicación del calendario con otros usuarios y suscripción a calendarios remotos en formato iCal.

Zimbra incorpora una gestión documental en línea. Mediante una interfaz WYSIWYG es posible crear documentos en un formato de texto tipo RTF a los que adjuntar, por ejemplo, hojas de cálculo o imágenes mediante la tecnología ALE (del inglés, AJAX L¡nking and Embedding). Esta gestión documental puede adquirir la forma de un wiki, permitiendo que los documentos sean creados, actualizados y compartidos entre todos los usuarios.

La publicación y compartición de contenidos es homogénea en todo el sistema tanto para contactos, como para el calendario o los documentos. Esta compartición puede realizarse con usuarios internos y externos del sistema. El cliente de correo permite la gestión de varias identidades y de varias cuentas de correo, incluyendo la agregación de cuentas externas mediante POP3.

La gestión unificada de los mensajes permite una fácil integración con sistemas de telefonía de voz sobre IP para llamadas, conferencias y acceso a buzones de voz. Esto se consigue mediante Zimlets, un potente sistema de Zimbra para extender sus capacidades mediante plug-ins y permitir la integración con otros softwares externos mediante el uso de SOAP y Web Services. Otros ejemplos de integraciones son Yahoo Maps, traductores de idiomas o consultas a bases de datos de la empresa (por ejemplo de un CRM o un ERP).

Zimbra permite personalizar el entorno, incluyendo soporte para temas y una versión sólo HTML para aquellos PCs antiguos o entornos que no puedan hacer uso de Javascript. Además permite la personalización de logos, textos y mensajes (en inglés, branding).

El servidor Zimbra

Zimbra Server (o Zimbra Store) es el núcleo de Zimbra Collaboration Suite. Está diseñado sobre una arquitectura extremadamente estable y modular usando tecnologías de código abierto contrastadas. Este servidor incluye soporte para multitud de protocolos estándares que le permiten interactuar con los clientes de software más populares.

El servidor de Zimbra empaqueta todos los componentes principales en un simple instalador y utiliza, entre otras, tecnologías como Linux, Jetty, Postfix, MySQL, OpenLDAP y Lucene y soporta, entre otros, protocolos tales como SMTP, LMTP, SOAP, XML, IMAP, POP, iCal y CalDAV.

Zimbra es un servidor muy rápido y eficiente que, además, permite escalar de manera horizontal, pues cada host incluye su propio almacén de buzones de correo y de datos de configuración. Zimbra puede crecer añadiendo más máquinas con subdominios diferentes y mantener una gestión centralizada dentro del mismo dominio principal.

Zimbra, por supuesto, soporta múltiples dominios y también perfiles de usuarios, que denomina COS (del inglés, Class Of Service). En estas clases de servicio se pueden definir las cuotas de almacenamiento y las características a las cuales tendrán acceso los usuarios. La siguiente lista presenta las más destacadas en su versión actual:

• Correo electrónico.

• Libreta de direcciones.

• Calendario de citas.

• Tareas.

• Documentos.

• Maletín.

• Mensajería instantánea.

• Preferencias.

• Etiquetado.

• Compartición.

• Cambio de contraseña.

• Elección de tema.

• Redacción de correos en formato HTML.

• Atajos de teclado.

• Acceso al Global Address List (GAL).

• Acceso externo por IMAP4/POP3.

• Creación de una dirección de reenvío automático del correo.

• Creación de una respuesta automática a la recepción de correos.

• Filtros de correo.

• Gestión de calendarios de grupos.

• Búsquedas avanzadas.

• Guardar búsquedas.

Network Edition

En su versión Network Edition, Zimbra incluye toda una serie de características añadidas respecto de la Open Source Edition, como la alta disponibilidad mediante clustering y journaling a nivel de aplicación, las copias de seguridad incrementales y completas con restauración detallada (hasta el nivel de un correo electrónico de una cuenta específica, todo desde la consola gráfica de administración) o el archivado de correos entrantes y salientes (para su posterior consulta o por requerimientos legales) mediante Zimbra Archiving and Discovery.

Otras características que también son exclusivas de su Network Edition son la gestión nativa de la jerarquía de almacenamiento, que le permite mover datos de una cierta antigüedad a otros volúmenes de datos pero presentarlos en conjunto al usuario. Esto permite la clásica configuración de discos SCSI como almacenamiento principal y discos SATA (más lentos pero también más baratos) como almacenamiento secundario. O configuraciones con SAN (del inglés, Storage Area Network) o NAS (del inglés, Network Attached Storage) de ambos tipos de discos.

Respecto del soporte para múltiples dominios, en su versión Network Edition, Zimbra permite la personalización de los logos y textos para cada dominio, así como usuarios administradores diferentes para cada dominio (y usuarios superadministrador) para gestionar el servidor completo.

Gracias a Zimbra Mobile, ZCS consigue la conexión con dispositivos móviles sin cables (bien a través del carrier de telefonía, bien a través de Wi-Fi). Soporta los protocolos Active Sync de Windows y Palm, iSync de Apple y SyncML de Symbian. Otras herramientas como Sync4j/Funambol permiten expandir aún más este tipo de integraciones. Para BlackBerry, Zimbra proporciona un conector para BlackBerry Enterprise Server (BES) que se instala en el servidor y permite la afamada sincronización bidireccional a través del carrier de telefonía móvil.

Hablando de más integraciones, Zimbra proporciona sendos conectores para Outlook de Microsoft e iMail de Apple, con los que se consigue una integración completa y transparente con el servidor. Evolution también tiene un conector, en este caso gratuito.

Finalmente, mediante el uso de Verity, Zimbra Network Edition es capaz de convertir prácticamente cualquier adjunto de correo en HTML y mostrarlo en el mismo cliente web de correo. De este modo es posible evitar la dependencia en aplicaciones externas que pueden o no estar instaladas en el sistema.

Requerimientos

Los requerimientos de Zimbra Collaboration Suite son, en comparación con otros productos similares, bastante bajos. Para entornos de evaluación (hasta 50 cuentas) la siguiente configuración debería ser suficiente:

• CPU Intel/AMD de 32bits a 1.5 GHz o superior.

• 1 GB de RAM.

• 5 GB de espacio libre en disco para el software y los logs (es posible realizar la instalación con menos espacio disponible usando el parámetro –skipspacecheck del script de instalación install.sh).

• Espacio adicional para el almacenamiento del correo y las bases de datos (depende del número de cuentas y de la cuota de disco asignada a cada una).

Para un sistema en producción se recomienda la siguiente configuración:

• CPU Intel/AMD de 32 bits a 2.0GHZ o superior.

• Mínimo 2 GB de RAM.

• 10 GB de disco duro para actualizaciones, logs y software, con RAID para redundancia de datos.

• Espacio de disco adicional para el almacenamiento de los buzones de correo y las bases de datos.

Se recomiendan CPU (del inglés, Central Processing Unit) de doble núcleo o superior, y preferiblemente doble CPU, pues se hará buen uso de éstos por parte de la máquina virtual de Java y por parte de Amavis, SpamAssassin y ClamAV.

Para instalaciones de más de 2000 cuentas de usuario, se recomienda CPU de 64 bits, lo que lleva a la necesidad de duplicar la RAM (mínimo 4 GB). El uso de discos SCSI es siempre recomendado frente a SATA por su fiabilidad y rendimiento. En general, y Zimbra no es una excepción, a mayor cantidad de RAM, mayor rendimiento general debido a la caché del kernel, y mayor fiabilidad.

Finalmente, el uso de una SAN o NAS, si es pertinente y económicamente posible, es siempre bienvenido dado el uso masivo que se hace del correo hoy en día y de la criticidad de este servicio en las empresas.

Por supuesto, todos estos valores son orientativos y únicamente útiles en un caso estándar. Es muy posible que sea preciso aumentarlos en función de los picos de carga que se prevean (por ejemplo si un cierto número, muy elevado, de usuarios acceden a la misma hora a comprobar el correo).

Seguridad

Respecto de la seguridad, en la documentación de Zimbra se aconseja desactivar SELinux (del inglés, Security Enhanced Linux) y el cortafuegos. Desactivar SELinux no tiene porqué suponer un problema, pero trabajar sin un cortafuegos en una máquina con dirección IP pública no es algo que uno pueda o quiera permitirse. La documentación de Zimbra presupone que el servidor se encuentra tras un router que hace NAT de los puertos, pero éste no tiene porqué ser siempre el caso y, aún así, la seguridad no debe enfocarse únicamente hacia el exterior. Debido a que este tema es susceptible de largas discusiones, además de dependiente de cada caso y organización particular, por no hablar de cómo configurar en sí un cortafuegos, a continuación se facilita una lista de puertos que deberán dejarse abiertos para el correcto funcionamiento de Zimbra y se deja a discreción del usuario su uso y su aplicación.

• SMTP, puerto 25 TCP.

• HTTP, puerto 25 TCP.

• HTTPS, puerto 443 TCP.

• POP3, puerto 110 TCP.

• POP3 sobre SSL (POP3S), puerto 995 TCP.

• IMAP4, puerto 143 TCP.

• IMAP4 sobre SSL (IMAPS), puerto 993 TCP.

• LDAP, puerto 389 TCP.

• LDAP sobre SSL (LDAPS), puerto 636 TCP.

• Administración de Zimbra, puerto 7071 TCP.

El acceso a los puertos 389 y 686 permite consultas al GAL de Zimbra, pero no debería abrirse al exterior (quizás filtrarlo sólo a la red local o a la IP pública del gateway/router de la oficina) pues OpenLDAP permite consultas anónimas por defecto. Zimbra 5.0.7 es la primera versión que incluye la posibilidad de permitir sólo consultas autenticadas a LDAP sobre la IP pública, a través de SSL, y que las consultas internas se realicen por la interfaz local.

El acceso al puerto 7071 quizás quiera restringirse también a ciertos direcciones IP.

En el caso de utilizar Zimbra Proxy, también se hará uso de los siguientes puertos:

• Route Lookup Handler, puerto 7072 TCP.

• IMAP, puerto 7143 TCP.

• IMAP sobre SSL, puerto 7993 TCP.

• POP3, puerto 7110 TCP.

• POP3 sobre SSL, puerto 7995 TCP.

A menos que el administrador tenga un motivo específico, no será necesario abrir estos puertos al exterior pues sólo se hace uso de ellos internamente.

Instalación en Debian Etch

Las siguientes instrucciones toman como punto de partida un sistema Debian Etch funcional, plataforma i386 de 32 bits, con las últimas actualizaciones de seguridad y el kernel precompilado de Debian en su versión 686. No se seleccionó ninguna tarea en el selector de tareas durante la instalación. Se configuró la IP estática x.y.z.t durante la instalación. Se tomó zimbra como nombre del equipo (hostname) y zimbra.midominio.com como FQDN (del inglés, Fully Qualified Domain Name).

Todas las sentencias deben ejecutarse como usuario root o mediante sudo, a menos que se indique lo contrario (comandos que se ejecutarán con el usuario zimbra). El primer paso será desinstalar Exim:

apt-get remove --purge exim4 exim4-base exim4-config exim4-daemon exim4-daemon-light

Acto seguido nos aseguraremos de que el fichero /etc/hosts esté configurado correctamente. Debería tener, al menos, las dos entradas siguientes:

127.0.0.1    localhost.localdomain    localhost
x.y.z.t      zimbra.midominio.com     zimbra

A continuación nos cercioraremos de que los registros A y MX de la zona de DNS correspondiente al servidor estén bien configurados. Esto puede variar en función de si nos encontramos en una máquina con IP pública o en una máquina con IP privada (tras un router que haría NAT). Además, puede que usemos un servidor de DNS local con vistas, o directamente uno externo. En cualquier caso, los objetivos son dos:

1. Que zimbra.midominio.com se traduzca correctamente a la dirección IP configurada.

2. Y que el registro MX del dominio midominio.com apunte a dicha dirección IP.

zimbra.midominio.com.    IN A x.y.z.t
zimbra.dominio.com.      IN MX 20 zimbra.dominio.com.
dominio.com.             IN MX 20 zimbra.dominio.com.

Estos aspectos de configuración de DNS son requerimientos de Zimbra para su instalación. Es conveniente, asimismo, tener bien configurado el registro PTR de la dirección IP donde se vaya a instalar Zimbra.

Como último paso antes de iniciar el instalador de ZCS, instalaremos una serie de paquetes que son dependencias necesarias para el correcto funcionamiento (algunos son dependencias de los paquetes DEB de Zimbra, otros son opcionales pero de facto necesarios si queremos que todas las funcionalidades de Zimbra estén activas). También se incluyen paquetes de propósito general de instalación obligada en cualquier servidor:

aptitude install curl sudo libidn11 fetchmail libgmp3c2 libxml2 \
         libstdc++5 libstdc++6 openssl libltdl3 libssl0.9.7 libdb3 \
         libexpat1 libltdl3 libio-socket-ssl-perl libmail-imapclient-perl \
         libmail-pop3client-perl libpcre3 file psmisc libgetopt-mixed-perl \
         libmime-explode-perl sysstat rar lha arj unrar zoo nomarch cpio \
         lzop cabextract zip unzip bzip2 gzip lsof tcpdump sysstat procps \
         pstack strace

Descargamos la última versión disponible de Zimbra (en el momento de escribir este artículo, la 5.0.9), por ejemplo al directorio /usr/local/src/. Para escribir este artículo se ha utilizado la versión 5.0.9 de la Open Source Edition. En el caso de la Network Edition, el procedimiento para una instalación monoservidor es idéntico pero con la posibilidad de instalar más paquetes (aparecen más opciones a las que decir sí durante la instalación).

Tras descomprimir el archivo TGZ, encontraremos en su interior un fichero install.sh, que ejecutaremos. Debian Etch por defecto no instala SELinux pero, en el caso de que se hubiera hecho, será necesario cambiarlo a modo permissive o disabled para el correcto funcionamiento de Zimbra (SELINUX=permissive en /etc/selinux/config) y reiniciar el servidor para que el cambio surja efecto.

El instalador realizará diversas preguntas, todas muy sencillas de responder. Para unas pruebas iniciales, se recomienda instalar todos los paquetes excepto Zimbra Proxy.

Install zimbra-ldap [Y]
Install zimbra-logger [Y]
Install zimbra-mta [Y]
Install zimbra-snmp [Y]
Install zimbra-store [Y]
Install zimbra-apache [Y]
Install zimbra-spell [Y]
Install zimbra-proxy [N]

Nota: la versión Network Edition preguntará, además, por la instalación de Zimbra Archiving (estaríamos usando la versión para Ubuntu 6 y deberemos confirmar al instalador que somos conscientes de estar instalando sobre Debian 4 y que queremos proceder).

Al final de la instalación se mostrará un menú de texto con varios puntos pendientes (marcados con asterisco). Será necesario corregir estos puntos antes de aplicar los cambios y terminar el proceso. Como mínimo será necesario ir a la opción 3 para establecer la contraseña de administrador y cambiar el modo del servidor web a https). El resultado final debería de ser el siguiente:

1. Common Configuration.
2. zimbra-ldap: Enabled
3. zimbra-store: Enabled
   * Create Admin User: yes
   * Admin user to create: admin@zimbra.midominio.com
   * Admin Password:
   * Enable automated spam training: yes
   * Spam training user: spam.n2xvfp2a@zimbra.midominio.com
   * Non-spam(Ham) training user: ham.htr37bbj@zimbra.midominio.com
   * Global Documents Account: wiki@zimbra.midominio.com
   * SMTP host: zimbra.midominio.com
   * Web server HTTP port: 80
   * Web server HTTPS port: 443
   * Web server mode: https
   * IMAP server port: 143
   * IMAP server SSL port: 993
   * POP server port: 110
   * POP server SSL port: 995
   * Use spell check server: yes
   * Spell server URL: http://zimbra.midominio.com:7780/aspell.php
4. zimbra-mta: Enabled
5. zimbra-snmp: Enabled
6. zimbra-logger: Enabled
7. zimbra-spell: Enabled
8. Default Class of Service Configuration.
r. Start servers after configuration: yes
s. Save config to file
x. Expand menu
q. Quit

A partir de este momento ya deberíamos ser capaces de acceder al webmail de Zimbra en:

https://zimbra.midominio.com

Zimbra es una herramienta muy completa y potente, por lo que lleva su tiempo acostumbrarse, ver de qué es capaz y empezar a sacarle verdadero provecho más allá del uso básico como servidor de correo, anotación de citas y gestión de contactos. A continuación se presentan una serie de utilidades varias que son de frecuente uso (todas deberán ejecutarse como usuario zimbra, normalmente accedido mediante sudo su – zimbra al hacer login:

• zmcontrol status: obtener el estado de los diversos daemons que forman el sistema Zimbra.

• zmcontrol start/stop: arrancar/parar el sistema Zimbra.

• zmcontrol -v: mostrar la versión (en este artículo, Release 5.0.9_GA_2533.DEBIAN4.0 DEBIAN4.0 FOSS edition).

• zmtlsctl [mixed|both|http|https|redirect]: cambiar el tipo de acceso permitido al webmail.

  • mixed realizará la validación sobre HTTPS y luego volverá al modo HTTP.

  • both permitirá indistintamente uno y otro.

  • redirect cambiará al usuario al modo https y lo mantendrá en ese modo (recomendado).

  • http forzará que se trabaje sólo sobre HTTP.

  • https forzará que se trabaje únicamente sobre HTTPS (recomendado).

• El fichero de configuración principal de Zimbra es /opt/zimbra/conf/localconfig.xml. Cualesquiera cambios que querramos hacer sobre el sistema para que sobrevivan a las actualizaciones deberán realizarse en éste fichero y en los demás dentro del directorio /opt/zimbra/conf.

• zmzimletctl listZimlets: mostrará un listado de los Zimlets instalados.

• zmzimletctl deploy zimlet.zip: instalrá el Zimlet zimlet.zip, que deberá encontrarse dentro del subdirectorio /opt/zimbra/zimlets-extra/.

• zmlocalconfig: permite realizar cambios sobre la configuración local guardada en el fichero /opt/zimbra/conf/localconfig.xml.

• zmprov: aprovisionamiento de cuentas. zmprov es un comando que permite interactuar con casi cualquier parte del sistema desde la consola de comandos, por ejemplo para crear o borrar cuentas desde un script. Puede actuar sobre los siguientes sistemas:

  • Cuentas.

  • Calendario.

  • Configuración.

  • COS (Class Of Service).

  • Dominios.

  • Listas de distribución.

  • Buzones de correo.

  • Wiki.

  • Búsquedas.

  • Servidores.

  • Otros (misceláneos).

Los comandos de consola disponibles se encuentran en /opt/zimbra/bin. Además, un gran conjunto de utilizadades del sistema en forma de scripts de Perl están disponibles en /opt/zimbra/libexec.

Mejoras en el sistema antispam

Zimbra viene por defecto con SpamAssassin como filtro antispam. Si bien la efectividad de SpamAssassin es elevada, su consumo de CPU también lo es. Además, existen maneras más eficientes, con menor consumo tanto de CPU como de ancho de banda, para combatir el spam que, en conjunción con SpamAssassin, disparan la eficiencia del sistema en esta lucha. A continuación se explica como instalar Postgrey, un conocido sistema de greylisting, y como enlazar el Postfix de Zimbra con Spamhaus. Además, se añaden algunas restricciones más a Postfix.

En primer lugar, como root, instalaremos Postgrey en la máquina:

aptitude install postgrey

En segundo lugar, como usuario zimbra, editaremos el fichero /opt/zimbra/conf/postfix_recipient_restrictions.cf:

reject_non_fqdn_recipient
reject_unknown_recipient_domain
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
reject_unlisted_recipient
%%contains VAR:zimbraMtaRestriction reject_invalid_hostname%%
%%contains VAR:zimbraMtaRestriction reject_non_fqdn_hostname%%
%%contains VAR:zimbraMtaRestriction reject_non_fqdn_sender%%
%%contains VAR:zimbraMtaRestriction reject_unknown_client%%
%%contains VAR:zimbraMtaRestriction reject_unknown_hostname%%
%%contains VAR:zimbraMtaRestriction reject_unknown_sender_domain%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client dnsbl.njabl.org%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client cbl.abuseat.org%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client bl.spamcop.net%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client sbl.spamhaus.org%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client xbl.spamhaus.org%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client sbl-xbl.spamhaus.org%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client relays.mail-abuse.org%%
reject_rbl_client zen.spamhaus.org
check_policy_service inet:127.0.0.1:60000
permit

Finalmente, también como usuario zimbra, recargaremos Postfix con postfix reload para que surjan efecto los cambios.

Whitelisting

En un plano teórico, los seis checkboxes que aparecen en la opción de “Configuración general: MTA” de la consola gráfica de administración de Zimbra deberían de estar marcados. Estas seis restricciones no deberían de causar problema alguno con servidores de correo bien configurados, pero esto no siempre es posible, sobre todo en empresas que dependen del correo para trabajar y cuyos proveedores tienen servidores de correo mal configurados.

Estas comprobaciones se reparten en dos grupos, de protocolo y de DNS. Las de protocolo son las siguientes:

• reject_invalid_hostname (el nombre del servidor en el inicio de la comunicación infringe RFC). Si está activa, Postfix rechazará las peticiones de los clientes cuyos comandos HELO o EHLO tengan una sintaxis incorrecta del nombre de host. El valor por defecto del error que se devuelve es el 501 (definible con invalid_hostname_reject_code).

• reject_non_fqdn_hostname (el cliente debe iniciar la comunicación con un nombre de servidor totalmente cualificado). Si está activa, Postfix rechazará las peticiones de los clientes cuyo nombre de host en el comando HELO o EHLO no sea un FQDN. El valor por defecto del error que se devuelve es el 504 (definible con non_fqdn_reject_code).

• reject_non_fqdn_sender (la dirección del remitente debe estar totalmente cualificada). Si está activa, Postfix rechazará las peticiones de los clientes que no faciliten un FQDN en el comando MAIL FROM durante la conexión. El valor por defecto del error que se devuelve es el 504 (definible con non_fqdn_reject_code).

Y las de DNS son las siguientes:

• reject_unknown_client (dirección IP del cliente). Si está activa, Postfix rechazará las peticiones de los clientes cuyas direcciones IP no tengan un registro PTR configurado, o si dicho registro PTR no tiene un registro A configurado que coincida (es decir, que coincida con el FQDN aportado en el comando HELO o EHLO). El valor por defecto del error que se devuelve es el 450 (definible con unknown_client_reject_code).

• reject_unknown_hostname (nombre del servidor en el inicio de la comunicación). Si está activa, Postfix rechazará las peticiones de los clientes cuyos nombres de host presentados en el comando HELO o EHLO no tengan un registro de DNS tipo A o tipo de MX. El valor por defecto del error que se devuelve es el 450 (definible con unknown_hostname_reject_code).

• reject_unknown_sender_domain (dominio del remitente). Si está activa, Postfix rechazará las peticiones de los clientes que, al mandar el comando MAIL FROM, aporten un nombre de dominio en la dirección de correo que no tenga un registro de DNS de tipo A o de tipo MX. El valor por defecto del error que se devuelve es el 450 (definible con unknown_address_reject_code). En el caso de un error temporal de resolución en el DNS, el error retornado es siempre el 450.

Como puede observarse, estas restricciones no son, en absoluto, tan restrictivas como se pueda pensar. Ahora bien, la realidad es la que es y no siempre se puede hacer lo que se debe. Para poder mantener estas seis restricciones activas pero poder trabajar con un cierto número de servidores de los cuales dependamos o confiemos, podemos utilizar las listas blancas. Las listas blancas (del inglés, whitelists), son unas listas con direcciones de remitentes o dominios completos para los cuales Postfix se saltará estas comprobaciones. Para activarlas, editaremos el fichero /opt/zimbra/conf/postfix_recipient_restrictions de forma que quede como sigue:

reject_non_fqdn_recipient
reject_unknown_recipient_domain
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
reject_unlisted_recipient
check_client_access hash:/opt/zimbra/conf/postfix_client_access
check_sender_access hash:/opt/zimbra/conf/postfix_sender_access
%%contains VAR:zimbraMtaRestriction reject_invalid_hostname%%
%%contains VAR:zimbraMtaRestriction reject_non_fqdn_hostname%%
%%contains VAR:zimbraMtaRestriction reject_non_fqdn_sender%%
%%contains VAR:zimbraMtaRestriction reject_unknown_client%%
%%contains VAR:zimbraMtaRestriction reject_unknown_hostname%%
%%contains VAR:zimbraMtaRestriction reject_unknown_sender_domain%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client dnsbl.njabl.org%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client cbl.abuseat.org%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client bl.spamcop.net%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client sbl.spamhaus.org%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client xbl.spamhaus.org%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client sbl-xbl.spamhaus.org%%
%%contains VAR:zimbraMtaRestriction reject_rbl_client relays.mail-abuse.org%%
reject_rbl_client zen.spamhaus.org
check_policy_service inet:127.0.0.1:60000
permit

A continuación, como usuario zimbra, haremos un postfix reload para que se hagan efectivos los cambios. Si decidimos marcar o desmarcar algunos de los checkboxes arriba mencionado, basta con pulsar sobre el botón guardar y el propio Zimbra ya se encarga de hacer dicha recarga de los parámetros de configuración.

Luego deberemos crear el fichero /opt/zimbra/conf/postfix_sender_access, asegurándonos de que el usuario zimbra tiene permisos de lectura sobre el mismo, y añadirle el contenido que queramos, del estilo de lo que sigue:

# Email/dominio          Valor    Comentario
reservas@proveedor.es    OK       Reservas proveedor A
@dominio.com             OK       Todo el dominio del proveedor B

Acto seguido deberemos crear el fichero /opt/zimbra/conf/postfix_client_access, asegurándonos de que el usuario zimbra tiene permisos de lectura sobre el mismo, y añadirle el contenido que queramos, del estilo de lo que sigue:

# Direccion IP   Valor    Comentario
x.y.z.t          OK       Proveedor A
a.b.c.d          OK       Proveedor B

Finalmente, como usuario zimbra, ejecutaremos el comando postmap /opt/zimbra/conf/postfix_whitelist, que creará el fichero /opt/zimbra/conf/postfix_whitelist.db y hará efectivos los cambios en el Postfix en ejecución.

Nótese que sólo se han aplicado las listas blancas a Postfix, no a Amavis ni a SpamAssassin. El motivo es que, en mi opinión particular, si bien es cierto que ambos pueden llegar a consumir muchísima CPU, por un lado nadie puede asegurarnos de los PCs tras esas direcciones no puedan estar algún día infectados y, por otro, la cantidad de correos que pasan las seis restricciones, el greylisting y la consula a Spamhaus es tan pequeño que vale la pena dejar que SpamAssassin y Clam AntiVirus verifiquen todos los correos.

Instalaciones distribuidas (multiservidor)

Además de la solución de clustering con Red Hat Enterprise, Zimbra soporta una instalación distribuida de cada uno de los dominios que hospede, centralizando la administración en una sola consola gráfica y ofreciendo un punto de entrada único a los usuarios.

Para lograrlo se instalan 2 o más sistemas con Zimbra, todos con un subdominio diferente del mismo dominio. Uno de los servidores actúa como maestro y los demás como esclavos de éste. Durante la instalación, que se empezará, como es lógico, por el maestro, se especifica en cada esclavo los datos del maestro que debe replicar. Las características principales de este tipo de instalación serían las siguientes:

• Gestión centralizada de las cuentas de los usuarios en el servidor maestro.

• Replicación del directorio LDAP del maestro a los esclavos. Esto permite mantener copias locales de las cuentas que cada nodo gestiona y el acceso al GAL (del inglés, Global Address List) completo de empleados.

• Ejecución remota de comandos en los servidores esclavos mediante el uso de un par de claves SSH.

• Monitorización del estado de todos los nodos a través de SNMP y presentación de los datos estadísticos en el maestro (en la consola gráfica de administración).

• Cada nodo tendrá su registro de DNS tipo A y tipo MX.

• Mediante la tabla de transportes de Postfix, el correo se enrutará al host pertinente.

• Mediante el uso del proxy de Zimbra (basado en Nginx y Memcached) se distribuirán las conexiones HTTP, IMAP y POP3 (y sus equivalentes sobre canal cifrado).

• Cada cuenta de usuario de un dominio pertenece a un servidor concreto, permitiendo un acceso más eficiente a los usuarios.

Un caso donde este modelo tiene una gran aplicación práctica es el de una empresa con diversas delegaciones distribuidas geográficamente. Con este modelo se consigue que los usuarios de cada delegación tengan un acceso local a sus datos, mejorando la experiencia de usuario, pero a la vez la gestión del sistema se hace de manera centralizada, reduciendo los costes. Además, en el caso de caída de alguno de los nodos del sistema, el resto de nodos pueden seguir trabajando con normalidad (los correos destinados a los usuarios del nodo caído quedarían a la espera de ser entregados).

Por ejemplo, para la empresa “Mi empresa” con dominio miempresa.com y sedes en Madrid, Barcelona y Sevilla, obtendríamos una configuración con tres subdominios, madrid.miempresa.com, barcelona.miempresa.com y sevilla.miempresa.com, y un único punto de entrada para los usuarios zimbra.miempresa.com (HTTP, IMAP y POP3). Para las peticiones externas, el flujo de información para el acceso de los usuarios sería el siguiente:

• El cliente final se conecta al proxy de Zimbra usando los puertos estándar de IMAP y POP3.

• Cuando el proxy de Zimbra recibe una conexión, Nginx manda una petición HTTP al componente de Zimbra encargado de encontrar la ruta adecuada (Zimbra Proxy Route Lookup Handler).

• Éste encuentra la información de la ruta a seguir para encontrar la cuenta y la devuelve a Nginx.

• El componente Memcached almacena la información para que no tenga que volver a consultarse mientras no caduque la caché (por defecto la guarda una hora).

• Nginx usa esta información para acceder al buzón del usuario.

• El proxy de Zimbra se conecta al buzón de correo e inicia la sesión de proxy de correo. El cliente final se comporta como si se estuviera conectando directamente a su buzón.

Instalación de un sistema multiservidor

En este apartado se hace un breve resumen de los principales pasos a seguir para la instalación distribuida de un sistema Zimbra. La instalación es muy directa y sencilla de llevar a cabo. Se ejecuta el mismo script de instalación en cada servidor, empezando por el maestro, se seleccionan los componentes adecuados y se utiliza el menú para configurar el sistema. Las instalaciones se realizarán sobre un sistema base idéntico al descrito en el apartado de instalación de un servidor estándar de este artículo.

Tras la instalación se deberán ejecutar dos pasos adicionales, uno para habilitar el par de claves SSH, el otro para habilitar la funcionalidad de monitorización del sistema.

Es muy importante instalar los servidores siguiendo este orden:

• Servidor LDAP.

• Servidores de mailboxes de Zimbra (Zimbra Store).

• Servidores de Zimbra MTA.

Puede instalarse Zimbra Proxy en cualquiera de los servidores, o instalarlo en un servidor aparte. En este ejemplo de instalación se instalará Zimbra Proxy en el mismo servidor que el LDAP maestro. Es importante verificar que los relojes de los diferentes servidores estén sincronizados. Para ello se recomienda el uso del daemon NTP.

Instalación de LDAP, SNMP y Proxy

El primer paso de la instalación, como se ha dicho anteriormente, será arrancar el instalador de Zimbra y seleccionar únicamente el paquete Zimbra LDAP, el paquete Zimbra Proxy y el paquete Zimbra SNMP. Zimbra Core se instalará como dependencia.

Una vez instalados los paquetes, llegaremos al menú de texto del final del proceso de instalación, donde deberemos configurar el sistema a nuestra medida. La configuración se hace de la misma manera que se ha descrito en el apartado de instalación de este artículo, salvo por la configuración de LDAP.

Main menu
1. Common Configuration
2. zimbra-ldap: Enabled
3. zimbra-snmp: Enabled
r. Start servers after configuration yes
s. Save config to file
x. Expand menu
q. Quit

Usaremos la opción “1″ para acceder al submenú y luego la opción “4″ para configurar la contraseña de administrador de LDAP. Será necesario anotar el nombre de host, el puerto y la contraseña ya que deberemos usarla cuando instalemos el Zimbra Store y el Zimbra MTA más adelante.

Main menu
1. Common Configuration:
    1. Hostname: zimbra.midominio.com
    2. Ldap master host: zimbra.midominio.com
    3. Ldap port: 389
    4. Ldap Admin password: set
    5. TimeZone: (GMT+01.00) Brussels / Copenhagen / Madrid / Paris
    6. Require secure interprocess communications: Yes

Con la opción “5″ podremos cambiar la zona horaria. Luego volveremos atrás con la opción “r” y entraremos en la opción “2″ para cambiar los ajustes de LDAP. Cambiaremos también las contraseñas de replicación de LDAP, de Amavis y de Postfix, si así lo queremos. La contraseña de administrador de LDAP, de Postfix y de Amavis debe ser la misma. Cuando el servidor LDAP ya esté configurado, volveremos al menú principal usando la opción “r” y aplicaremos los cambios usando la opción “a”. Y finalizaremos la instalación con la opción “q”.

Instalación de Store, Logger y Spell

Llega la hora de instalar el Zimbra Mailbox Server, que puede hacerse sobre la misma máquina o sobre una máquina diferente. Se puede tener más de un servidor de buzones de correo y se pueden añadir nuevos servidores siempre que se quiera.

Nota: Zimbra Logger se instala en la máquina donde se instale el primer Zimbra Store.

Ejecutaremos de nuevo el instalador y, a la hora de elegir los paquetes a instalar, seleccionaremos únicamente zimbra-store, zimbra-logger y zimbra-spell (como dependencias se instalarán también zimbra-apache y zimbra-core). Seguiremos el proceso habitual hasta llegar al menú del final de la instalación, donde aparecerán varios puntos con asteriscos (sin configurar). Para expandir el menú podemos usar la opción “x”.

Además de puntos anteriormente configurados, como la zona horaria, que deberán volver a configurarse si se trata de una máquina diferente, los siguientes puntos deberán forzosamente ajustarse adecuadamente.

En la configuración de LDAP tendremos que introducir el valor del nombre de host y de contraseña introducidos en la instalación anterior del paquete zimbra-ldap. El servidor intentará contactar inmediatamente con el servidor LDAP y, si no le es posible, no nos dejará seguir.

El siguiente paso será configurar la contraseña de la cuenta de administrador, el host SMTP y establecer el modo del servidor web (http, https, both, redirect o mixed). Las opciones a usar son la “4″, la “9″ y la “10″.

Si se instaló zimbra-proxy en la vez anterior, ahora deberemos habilitarlo. Para ello iremos a la opción “13″. Al habilitar el proxy sobre los puertos POP3 e IMAP, tanto éstos como los propios puertos del proxy se cambian a los valores por defecto de Zimbra (ver apartado de seguridad y cortafuegos en este mismo artículo). Volveremos atrás con la opción “r”, aplicaremos los cambios y finalizaremos la instalación igual que la vez anterior.

Instalación de Zimbra MTA

Es necesario que, al empezar la instalación de zimbra-mta, sepamos ya el nombre de host, el puerto y la contraseña de administrador del LDAP. Sino, el MTA no será capaz de contactar con el LDAP y no se podrá finalizar la instalación.

Los pasos iniciales son los mismos que las veces anteriores, debiéndose, en esta ocasión marcar únicamente el paquete zimbra-mta y el paquete zimbra-snmp y dejar desmarcados todos los demás.

Al llegar al menú del final de la instalación, será preciso que modifiquemos, al menos, los valores “LDAP master host” y “LDAP admin password” de la opción “1″, y “MTA auth host”, “Bind password for Postfix LDAP user” y “Bind password for Amavis ldap user” en la opción “2″. Todos estos valores los obtendremos de las instalaciones anteriores. La contraseña de administrador de LDAP, de Postfix y de Amavis debe ser la misma.

Una vez configurados estos valores, aplicaremos la configuración y finalizaremos la instalación de la misma manera que en las ocasiones anteriores.

Ajustes finales

Una vez el servidor de LDAP, de buzones y el MTA están instalados y configurados en una instalación multinodo, quedan dos funciones pendientes de configurar:

• Para que la gestión remota y el acceso a las colas de correo funcione, es necesario propagar manualmente el par de claves a todos los nodos.

• Si se ha instalado el logger, habrá que configurar los ficheros del syslog en cada servidor para habilitar las estadísticas que se muestran en la consola de administración, y luego habilitar el host donde se ha instalado Zimbra Logger.

Para propagar el par de claves, en cada nodo ejecutaremos, como usuario zimbra (su – zimbra o sudo su – zimbra), el comando zmupdateauthkeys. La clave se actualiza en el fichero /opt/zimbra/.ssh/authorized_keys.

Para que se muestren las estadísticas en la consola de administración, hay que modificar los ficheros de configuración del syslog. En cada servidor, como usuario root, ejecutaremos /opt/zimbra/bin/zmsyslogsetup.

En el host donde se haya instalado Zimbra Logger (en este artículo, en el host maestro), debemos habilitar la recogida de logs de máquinas externas. Para ello, como usuario root:

• Editamos el fichero /etc/default/syslogd y modificamos la variable SYSLOGD para que quede tal que SYSLOGD=”-r -m 0″.

• Paramos el daemon con /etc/init.d/syslog stop.

• Arrancamos de nuevo el daemon con /etc/init.d/syslog start.

• Para verificar que cada nodo instalado está funcionando correctamente, entraremos en cada nodo y, como usuario zimbra, ejecutaremos zmcontrol status.

Problemas con Zimbra Logger

De vez en cuando Zimbra Logger deja de generar las estadísticas visibles en la consola gráfica de administración. Las causas principales suelen ser algún daemon que no se cerró o no arrancó adecuadamente durante una parada del sistema o una actualización, o la corrupción de tablas en la base de datos de MySQL. A continuación se detallan algunos procedimientos útiles a seguir en caso de encontrarse en tal situación.

Para comprobar si tenemos tablas corruptas, como usuario zimbra entraremos en la consola de MySQL de la base de datos zimbra_logger y, una vez dentro, visualizaremos las tablas, comprobaremos su estado y ejecutaremos un repair table en todas aquellas que nos den errores. El siguiente código ilustra este caso (el código no muestra los checks hechos sobre tablas que no retornaron error):

$ sudo su – zimbra
$ logmysql zimbra_logger
mysql> show tables;
+-------------------------+
| Tables_in_zimbra_logger |
+-------------------------+
| amavis                  |
| amavis_aggregate        |
| config                  |
| disk_aggregate          |
| disk_status             |
| mta                     |
| mta_aggregate           |
| processing_history      |
| raw_logs                |
| service_status          |
+-------------------------+
10 rows in set (0.00 sec)

mysql> check table mta;
+-------------------+-------+----------+---------------------------------------------------+
| Table             | Op    | Msg_type | Msg_text                                          |
+-------------------+-------+----------+---------------------------------------------------+
| zimbra_logger.mta | check | warning  | Table is marked as crashed and last repair failed |
| zimbra_logger.mta | check | error    | Found 8482310 keys of 11353731                    |
| zimbra_logger.mta | check | error    | Corrupt                                           |
+-------------------+-------+----------+---------------------------------------------------+
3 rows in set (5 min 26.80 sec)

mysql> repair table mta;
+-------------------+--------+----------+----------+
| Table             | Op     | Msg_type | Msg_text |
+-------------------+--------+----------+----------+
| zimbra_logger.mta | repair | status   | OK       |
+-------------------+--------+----------+----------+
1 row in set (6 hours 34 min 51.95 sec)

mysql> check table processing_history;
+----------------------------------+-------+----------+----------------------------------------------------------+
| Table                            | Op    | Msg_type | Msg_text                                                 |
+----------------------------------+-------+----------+----------------------------------------------------------+
| zimbra_logger.processing_history | check | warning  | 2 clients are using or haven't closed the table properly |
| zimbra_logger.processing_history | check | status   | OK                                                       |
+----------------------------------+-------+----------+----------------------------------------------------------+
2 rows in set (0.00 sec) 

mysql> repair table processing_history;
+----------------------------------+--------+----------+----------+
| Table                            | Op     | Msg_type | Msg_text |
+----------------------------------+--------+----------+----------+
| zimbra_logger.processing_history | repair | status   | OK       |
+----------------------------------+--------+----------+----------+
1 row in set (0.00 sec)

En el caso de ejecutar un zmcontrol status y resultar que alguno de los componentes del logger no se está ejecutando, deberemos revisar lo siguiente:

• Si no se está ejecutando logmysql.server, revisar que exista /opt/zimbra/logger/db/mysql.pid y que el proceso /opt/zimbra/logger/mysql/libexec/mysqld se está ejecutando.

• Si no se está ejecutando zmlogswatchctl, revisar que exista /opt/zimbra/log/logswatch.pid y que hay un único proceso /opt/zimbra/libexec/logswatch ejecutándose.

• Si el logger se está ejecutando, verificar entonces que la conexión a la base de datos de MySQL es posible y realizar las comprobaciones sobre las tablas anteriormente mencionadas.

• Podemos parar y arrancar el logger a voluntad mediante el comando zmloggerctl start/stop como usuario zimbra.

El log del MySQL del logger se encuentra en /opt/zimbra/logger/db/data/zimbra.midominio.com.err. Síntomas inequívocos de que hay tablas corruptas serán mensajes del estilo:

[ERROR] /opt/zimbra/logger/mysql/libexec/mysqld: Table '<nombre_tabla>' is marked as crashed and last (automatic?) repair failed.

La actualización de los logs se produce brevemente cada cinco minutos y durante la noche de forma masiva, pero asimismo tenemos la posibilidad de lanzar manualmente el proceso de análisis de los logs mediante la ejecución del comando /opt/zimbra/libexec/zmlogprocess. La generación de las estadísticas la realiza el script de Perl /opt/zimbra/libexec/zmgengraphs.

Aún así es posible que no seamos capaces de recuperar un estado consistente y fiable de los logs, las estadísticas y los procesos relacionados con Zimbra Logger. Como último recurso tendremos entonces que reiniciar la base de datos de información acumulada. Para ello seguiremos estos pasos.

su - zimbra
zmloggerctl stop
mv /opt/zimbra/logger/db /opt/zimbra/logger/db.bak
source /opt/zimbra/bin/zmshutil
zmsetvars
(nos aseguraremos de que no haya proceso alguno de MySQL ejecutándose)
/opt/zimbra/libexec/zmloggerinit
zmlogswatchctl start

Tras cualquiera de los ajustes realizados en este apartado del artículo deberemos esperar entre varios minutos y la llegada de la siguiente mañana para poder ver las correcciones o recreaciones sobre las estadísticas.

Uso de memoria RAM y swap

El servidor Java de los mailboxes hace un uso extensivo de la caché con el fin de mejorar el rendimiento evitando accesos a disco. Por defecto, Zimbra viene configurado para reservar un 40% de la RAM disponible para este proceso, y un 30% de la RAM para MySQL. En sistemas con más de 4 GB de RAM pueden cambiarse estos valores y reservar una mayor cantidad. La variable de la configuración local que representa el porcentaje de memoria se convierte en la opción -Xmx de la máquina virtual de Java al arrancarla.

En el caso de un sistema pequeño, con pocos dominios, buzones y RAM (1 GB), es también posible que nos encontremos que el sistema usa la swap. Para evitar esto, podemos usar estas mismas variables de configuración para reducir el uso. Como usuario zimbra ejecutaremos los siguientes comandos con el valor deseado:

zmlocalconfig -e mailboxd_java_heap_memory_percent=40
zmlocalconfig -e mysql_memory_percent=30

Tras estos comandos deberemos reiniciar el servidor de buzones.

Bibliografía

• Performance Tuning Guidelines for Large Deployments

• LDAP Mapped Attributes

• Logger

• Monitoring Zimbra Servers

• Managing domains

• Mail backup options for end users

• User Migration

• Firewall Configuration

• Working with Zimbra Proxy

• Full Backups and Restore procedure

• Zindus

• Zimbra Directory Service (LDAP)

• Outlook to iCal Export Utility for Windows

• Zimbra™ Collaboration Suite Single Server Installation Network Edition

• ZCS Administrator’s Guide

• Mail Queue Monitoring

• Split Domain

• GAL not working with Active Directory

• Improving Anti-spam system

• CLI zmlocalconfig (Local Configuration)

• Open Source Edition Backup Procedure

• Migration Wizard Troubleshooting

• Right place for Postfix transport map

• Zimbra + Mailman Howto

• Commercial Certificates

]]> http://targz.net/blog/?feed=rss2&p=1120 0 http://targz.net/blog/?p=1118 http://targz.net/blog/?p=1118#comments Sun, 08 Nov 2009 15:43:28 +0000 joaquin http://targz.net/blog/?p=1118 CONEXION VPN FACIL CON PPTPD

fuente:http://www.linuxparatodos.net/portal/article.php?story=vpn-pptd
Autor: rodmen82 | Lecturas: 552 | | martes, 06 de octubre 2009 @ 09:15 CDT |

Con la herramienta PPTPD es una forma muy sencilla y fácil de crear VPN para la comunicación entre máquinas de ka oficina a equipo remoto. Por medio de PPTPD podremos conectarnos a la red privada para poder obtener algunos recursos de la red local.

1) Lo que tenemos que hacer es instalar el servicio de PPTPD en nuestra distribución preferida.

—- debian/ubuntu y derivados
ascariote:# apt-get install pptpd

—- RHEL/Centos/Fedora y derivados
root@ascariote:~$ yum install pptpd

2) Ya teniendo instalado los paquetes tendremos que hacer las siguientes configuraciones para que nuestro servicio funcione sin problemas.

Tendremos que configurar el siguiente archivo
ascariote:# vim /etc/ppp/options.pptpd

Debe contener los siguientes parámetros:
name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
lock
nodefaultroute
nobsdcomp
novj
novjccomp
nologfd
ms-dns 208.67.222.222
ms-dns 208.67.220.220

3) Ahora configuraremos otro parámetros del PPTPD, en el cual indicaremos la IP que tiene el servidor y reservamos una cantidad de IP que se ocuparan para el servicio PPTPD.
ascariote:# vim /etc/pptpd.conf

localip 192.168.5.1
remoteip 192.168.5.234-240

4) Deberemos agregar las cuentas de usuarios que se van a conectar a la VPN, para esto tendremos configurar el siguiente archivo.
ascariote:# vim /etc/ppp/chap-secrets

En este archivo tendremos que agregar los usuarios, el protocolo a utilizar, contraseña y también podremos asignarle una IP estática

# Secrets for authentication using CHAP

# client server secret IP addresses
clientlpt pptpd 123456 192.168.5.236
djtux pptpd qwerty *
moy pptpd 54321 192.168.5.238
lptpruebas pptpd qwerty12 192.168.5.240

5) Solo queda iniciar el servicio de PPTPD

ascariote:# /etc/init.d/pptpd restart

6) Clientes PPTPD.

Para clientes de S.O GNU/Linux
—- debian/ubuntu/derivados
lucifer:# apt-get install network-manager-pptp

—- RHEL/Centos/Fedora y derivados
root@mantis:~# yum install NetworkManager-pptp

Para clientes del S.O Windows, ya viene agregado solamente tendremos que hacer la conexión desde el asistente de conexión a red e indicarle que es una red del tipo VPN.

Configuración rápida y simple de Postfix

/etc/init.d/sendmail stop
chkconfig --level 345 sendmail off

mydomain = diginet.com.co

myhostname = mail.diginet.com.co

telnet 192.168.1.1 25
220 mail.diginet.com.co ESMTP Postfix

myorigin = $mydomain

myorigin = diginet.com.co

From: Pepito Perez <pepito@diginet.com.co>

myorigin = $myhostname

From: Pepito Perez <pepito@mail.diginet.com.co>

mydestination = $mydomain localhost.localdomain localhost $myhostname

mydestination = diginet.com.co localhost.localdomain localhost mail.diginet.com.co

inet_interfaces = all
inet_interfaces = loopback-only (Postfix 2.2 and later)
inet_interfaces = 127.0.0.1
inet_interfaces = 127.0.0.1, [::1] (Postfix 2.2 and later)
inet_interfaces = 192.168.1.2, 127.0.0.1

127.0.0.1
192.168.1.1
200.1.2.3

.
.
.
tcp        0      0 10.100.0.253:53             0.0.0.0:*                   LISTEN
tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN
.
.

tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN

netstat -anp
netstat -puta (jejeje...está me la pille en pello.info)
netstat -ano  (juas!!!..microsoft.com no deja de impresionarme)

telnet 192.168.1.1 25

220 mail.diginet.com.co ESMTP Postfix
HELO juanmuno.diginet.com.co
250 mail.diginet.com.co
MAIL FROM: mrwolf@pulpfiction.com
250 Ok
RCPT TO: pepito@diginet.com.co
250 Ok
DATA
354 Please start mail input.
HI, MY NAME IS MR WOLF. I SOLVE PROBLEMS...
.
250 Mail queued for delivery.

QUIT
221 Closing connection. Good bye.

Connection to host lost.

10.1.0.254              MASK 255.255.0.0
192.168.1.254   MASK 255.255.255.0
200.1.2.3               MASK 255.255.255.248

mynetworks_style
mynetworks

/etc/init.d/sendmail stop
chkconfig --level 345 sendmail off

mydomain = diginet.com.co

myhostname = mail.diginet.com.co

telnet 192.168.1.1 25
220 mail.diginet.com.co ESMTP Postfix

myorigin = $mydomain

myorigin = diginet.com.co

From: Pepito Perez <pepito@diginet.com.co>

myorigin = $myhostname

From: Pepito Perez <pepito@mail.diginet.com.co>

mydestination = $mydomain localhost.localdomain localhost $myhostname

mydestination = diginet.com.co localhost.localdomain localhost mail.diginet.com.co

inet_interfaces = all
inet_interfaces = loopback-only (Postfix 2.2 and later)
inet_interfaces = 127.0.0.1
inet_interfaces = 127.0.0.1, [::1] (Postfix 2.2 and later)
inet_interfaces = 192.168.1.2, 127.0.0.1

127.0.0.1
192.168.1.1
200.1.2.3

.
.
.
tcp        0      0 10.100.0.253:53             0.0.0.0:*                   LISTEN
tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN
.
.

tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN

netstat -anp
netstat -puta (jejeje...está me la pille en pello.info)
netstat -ano  (juas!!!..microsoft.com no deja de impresionarme)

telnet 192.168.1.1 25

220 mail.diginet.com.co ESMTP Postfix
HELO juanmuno.diginet.com.co
250 mail.diginet.com.co
MAIL FROM: mrwolf@pulpfiction.com
250 Ok
RCPT TO: pepito@diginet.com.co
250 Ok
DATA
354 Please start mail input.
HI, MY NAME IS MR WOLF. I SOLVE PROBLEMS...
.
250 Mail queued for delivery.

QUIT
221 Closing connection. Good bye.

Connection to host lost.

10.1.0.254              MASK 255.255.0.0
192.168.1.254   MASK 255.255.255.0
200.1.2.3               MASK 255.255.255.248

mynetworks_style
mynetworks

Montaje avanzado de un servidor de correo postfix, con filtros antispam, etc.

http://linuxsilo.net/articles/postfix-mysql.html

Aplicaciones para montar tu propio webmail (I)

Fuente: http://www.maestrosdelweb.com/editorial/aplicaciones-para-montar-tu-propio-webmail-i/

$rcmail_config['default_host'] = 'miempresa.com';

Puerto usado para aceptar las conexiones IMAP
$rcmail_config['default_port'] = 143;

Nombre del Producto
$rcmail_config['product_name'] = 'Mi empresa';

Esta variable contiene la versión del webmail:
$config_version = '1.4.0';

Preferencias organizacionales:
$org_name = "SquirrelMail";

Ruta de la imagen que se mostrará:
$org_logo = SM_PATH . 'images/sm_logo.png';

Tamaño de ancho del logo:
$org_logo_width = '308';

Tamaño de alto del logo:
$org_logo_height = '111';

Titulo del webmail:
$org_title = "SquirrelMail $version";

Definimos si utilizaremos Sendmail como servidor de correo.(True=SI, False = NO):
$useSendmail = false;

Configuracion del servidor SMTP y del Puerto:
$smtpServerAddress = 'localhost';
$smtpPort = 25;

Ruta del directorio de sendmail:
$sendmail_path = '/usr/sbin/sendmail';

Nombre o IP del servidor IMAP y Puerto:
$imapServerAddress = 'localhost';
$imapPort = 143;

Dirección del servidor y el puerto SMTP por defecto.
$conf->default_smtp_server = 'hvil.hlg.sld.cu';
$conf->default_smtp_port = 25;

Ruta del directorio temporal
$conf->tmpdir = '/tmp';

Lenguaje por defecto
$conf->default_lang = 'es';

Tema del webmail por defecto
$conf->default_theme = 'standard';

Reporte de errores y alertas
$conf->debug_level = E_ALL & ~E_NOTICE;

Cantidad de mensajes por página
$conf->msg_per_page = '25';

Firma de los mensajes salientes elaborados por los usuarios que utilicen nuestro webmail
$conf->ad = "¨Nuestra Empresa";

Tamaño máximo de los adjuntos
$conf->memory_limit="20M";

]]> http://targz.net/blog/?feed=rss2&p=1115 0 http://targz.net/blog/?p=1112 http://targz.net/blog/?p=1112#comments Fri, 06 Nov 2009 15:34:22 +0000 joaquin http://targz.net/blog/?p=1112

Instalando Linux+Apache+Mysql+Php

Instalar LAMP en Ubuntu 9.04 Server paso a paso

Fuente: http://sliceoflinux.com/2009/06/16/instalar-lamp-en-ubuntu-9-04-server-paso-a-paso/

Hace unos días expusimos cómo instalar un servidor LAMP en una línea. Sin embargo, es posible que al ejecutar esa línea nos encontremos el error “tasksel: aptitude failed (100)” o que simplemente nos interese una forma de instalación más tradicional con aptitude. Por eso vamos a instalar todos los componentes necesarios para instalar un servidor LAMP manualmente paso a paso e incluso comprobando que funciona.

Antes de empezar, hay que recordar que estos pasos no sólo sirven para Ubuntu Server sino también para Ubuntu Desktop.

Los pasos para instalar un servidor LAMP son los siguientes:

1. Instalamos el servidor web, en nuestro caso, Apache2 con el siguiente comando:

   sudo aptitude install apache2-mpm-prefork

1. Al terminar la instalación veremos el siguiente mensaje:
   

   apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName

   Para solucionarlo le indicamos a Apache2 nuestro fqdn con el siguiente comando:

   echo “ServerName localhost” | sudo tee /etc/apache2/conf.d/fqdn

2. Después tenemos que indicarle a Apache2 que use index.php como página de inicio (además de index.html e index.htm). Para hacer esto tendríamos que editar el archivo /etc/apache2/sites-available/default e incluir la línea DirectoryIndex index.php index.html index.htm. Sin embargo, lo podemos solucionar ejecutando el siguiente comando (si haces un copiar y pegar, vuelve a escribir las comillas en tu equipo porque a veces no se copian bien):

   sudo sed -i “s|DocumentRoot /var/www|DocumentRoot /var/www \n\tDirectoryIndex index.php index.html index.htm|” /etc/apache2/sites-available/default

3. Instalamos el gestor de base de datos MySQL con el siguiente comando:

   sudo aptitude install mysql-server

1. Durante la instalación se nos pedirá que introduzcamos una contraseña para el usuario root de MySQL. No es obligatorio  y se podría dejar en blanco pero no os lo recomiendo en absoluto, así que escribimos una contraseña y pulsamos Intro.

1. A continuación volvemos a escribir la contraseña:

1. Instalamos PHP5 y el módulo de MySQL para PHP5 con el siguiente comando:

   sudo aptitude install php5 php5-mysql

1. Para que Apache reconozca estos cambios y muestre los archivos PHP sin problemas debemos reiniciarlo con el siguiente comando:

   sudo /etc/init.d/apache2 restart

2. Una vez instalados todos los componentes del servidor LAMP, el siguiente paso consiste en comprobar que funciona correctamente el servidor web. Para ello tenemos que ir a otro equipo (sólo porque estamos trabajando con Ubuntu Server) y escribir en un navegador web la dirección IP del servidor donde hemos realizado la instalación del LAMP. En mi caso es http://172.16.10.9. Y la señal inequívoca de que Apache está funcionando correctamente es ver la siguiente página web:

1. Por último, para comprobar que funciona correctamente el intérprete de PHP, creamos un archivo de texto en el servidor de nombre info.php en el directorio /var/www con el siguiente comando:

   sudo nano /var/www/info.php

   con el siguiente contenido:

   <? phpinfo() ?>

   Guardamos los cambios pulsando Control+O y salimos con Control+X.

Ahora sólo nos queda acceder a la página web que acabamos de crear con un navegador desde otro equipo: http://172.16.10.9/info.php. Y deberíamos ver una página como la siguiente:

¡A disfrutarlo! Ya tenemos nuestro servidor LAMP instalado, configurado y comprobado. ¿Qué más se puede pedir? ¿Unas vacaciones?

]]> http://targz.net/blog/?feed=rss2&p=1112 0 http://targz.net/blog/?p=1108 http://targz.net/blog/?p=1108#comments Thu, 05 Nov 2009 15:20:52 +0000 joaquin http://targz.net/blog/?p=1108

Cómo configurar un servidor DHCP en una LAN.

Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

Introducción.

DHCP (acrónimo de Dynamic Host Configuration Protocol que se traduce Protocolo de configuración dinámica de servidores) es un protocolo que permite a dispositivos individuales en una red de direcciones IP obtener su propia información de configuración de red (dirección IP; máscara de sub-red, puerta de enlace, etc.) a partir de un servidor DHCP. Su propósito principal es hacer más fáciles de administrar las redes grandes. DHCP existe desde 1993 como protocolo estándar y se describe a detalle en el RFC 2131.

Sin la ayuda de un servidor DHCP, tendrían que configurarse de forma manual cada dirección IP de cada anfitrión que pertenezca a una Red de Área Local. Si un anfitrión se traslada hacia otra ubicación donde existe otra Red de Área Local, se tendrá que configurar otra dirección IP diferente para poder unirse a esta nueva Red de Área Local. Un servidor DHCP entonces supervisa y distribuye las direcciones IP de una Red de Área Local asignando una dirección IP a cada anfitrión que se una a la Red de Área Local. Cuando, por mencionar un ejemplo, una computadora portátil se configura para utilizar DHCP, a ésta le será asignada una dirección IP y otros parámetros de red necesarios para unirse a cada Red de Área Local donde se localice.

Existen tres métodos de asignación en el protocolo DHCP:

Sustento lógico necesario.

Se requiere instalar el paquete dhcp el cual deberá estar incluido en los discos de instalación de la mayoría de las distribuciones.

yum -y install dhcp

Si se utiliza Red Hat™ Enterprise Linux, solo bastará realizar lo siguiente para instalar o actualizar la programática necesaria:

up2date -i dhcp

Fichero de configuración.

Considerando como ejemplo que se tiene una red local con las siguientes características:

NOTA: Es indispensable conocer y entender perfectamente todo lo anterior para poder continuar con este manual.

Puede utilizar el siguiente contenido para crear desde cero el fichero /etc/dhcpd.conf.

ddns-update-style interim;
ignore client-updates;
shared-network miredlocal {
        subnet 192.168.0.0 netmask 255.255.255.0 {
        option routers 192.168.0.1;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.0.255;
        option domain-name "redlocal.net";
        option domain-name-servers 192.168.0.1, 148.240.241.42, 148.240.241.10;
        option netbios-name-servers 192.168.0.1;
        option ntp-servers 66.187.224.4, 66.187.233.4;
        range 192.168.0.11 192.168.0.199;
        default-lease-time 21600;
        max-lease-time 43200;
        }
        host m253 {
                option host-name "m253.redlocal.net";
                hardware ethernet 00:50:BF:27:1C:1C;
                fixed-address 192.168.0.253;
                }
        host m254 {
                option host-name "m254.redlocal.net";
                hardware ethernet 00:01:03:DC:67:23;
                fixed-address 192.168.0.254;
                }
}

Una buena medida de seguridad es hacer que el servicio de dhcpd solo funcione a través de la interfaz de red utilizada por la LAN, esto en el caso de tener múltiples dispositivos de red. Edite el fichero /etc/sysconfig/dhcpd y agregue como argumento del parámetro DHCPDARGS el valor eth0, eth1, eth2, etc., o lo que corresponda. Ejemplo, considerando que eth0 es la interfaz correspondiente a la LAN:

# Command line options here
DHCPDARGS=eth0

Para ejecutar por primera vez el servicio, ejecute:

/sbin/service dhcpd start

Para hacer que los cambios hechos a la configuración surtan efecto, ejecute:

/sbin/service dhcpd restart

Para detener el servicio, ejecute:

/sbin/service dhcpd stop

Para añadir dhcpd al arranque del sistema, ejecute:

/sbin/chkconfig dhcpd on

Hecho lo anterior solo bastará con configurar como interfaces DHCP las estaciones de trabajo que sean necesarias sin importar que sistema operativo utilicen.

]]> http://targz.net/blog/?feed=rss2&p=1108 0 http://targz.net/blog/?p=1103 http://targz.net/blog/?p=1103#comments Wed, 04 Nov 2009 09:55:25 +0000 joaquin http://targz.net/blog/?p=1103

En la sesión de hoy montaremos un servidor de archivos samba, la implementación del protocolo SMB fuera de sistemas de microsoft.

Samba

$sudo aptitude install samba samba-client smbfs smbclient

$sudo nano /etc/samba/smb.conf

workgroup = MSHOME

$sudo mkdir /home/public
$sudo chmod 755 /home/public

$sudo nano /etc/samba/smb.conf

[public]
 comment = Cosas publicas
 path = /home/public
 public = yes
 writable = no

$sudo nano /etc/samba/smb.conf

[CDRom]
 comment = Cd Rom Compartido
 path = /media/cdrom0
 public = yes
 writable = no
 browseable = yes

$sudo chown nobody:nogroup /home/public
$sudo chmod 555 /home/public

$sudo chmod 755 /home/public

;   security = user

security = SHARE

smbpasswd -r WindowsDC -U nombreUsuario

sudo smbpasswd -a tu_usuario

$sudo /etc/init.d/samba restart

\\192.168.3.1\public

smb://192.168.3.1/public/ o smbclient //192.168.3.1/public/

$ sudo useradd -s /sbin/nologin usuario-windows

$ sudo passwd -d usuario-windows

$ sudo smbpasswd -a usuario-windows

$ sudo  /etc/init.d/samba restart

Montar comparticiones remotas usando smbfs y cifs

$ sudo aptitude install smbfs

$ sudo mkdir /media/mountname

//servername/sharename  /media/mountname  smbfs  guest,uid=1000,iocharset=utf8,codepage=unicode,unicode  0  0

$ sudo mount -a

//servername/sharename  /media/mountname  smbfs  username=myusername,password=mypassword  0  0

$ sudo gedit ~/.smbcredentials

username=myusername
password=mypassword

$ sudo chmod 600 ~/.smbcredentials

//servername/sharename  /media/mountname  smbfs  credentials=~/.smbcredentials,dmask=777,fmask=777  0  0

//servername/sharename  /media/mountname  smbfs  credentials=~/.smbcredentials  0  0

//servername/sharename  /media/mountname  smbfs  credentials=~/.smbcredentials,dir_mode=777,file_mode=777  0  0

//servername/sharename  /media/mountname  smbfs  noauto,credentials=~/.smbpasswd  0  0

#!/bin/sh -e
mount /media/mountname
exit 0

//servername/sharename  /media/mountname  smbfs   uid=eguser,credentials=~/.smbcredentials,dmask=777,fmask=777   0       0

//servername/sharename  /media/mountname  smbfs  username=guest,password=,uid=1000,iocharset=utf8,codepage=unicode,unicode  0  0

$ sudo chmod u+s `which smbmnt`
$ sudo chmod u+s `which smbumount`

Compartir impresora con Windows

$ sudo adduser cupsys shadow
$ sudo /etc/init.d/cupsys restart

$ sudo /etc/init.d/cupsys restart

http://*:631/printers/LaserJet-1200

SWAT

$ sudo update-inetd --enable 'swat'

$ sudo -s
$ passwd

http://localhost:901

]]> http://targz.net/blog/?feed=rss2&p=1103 0 http://targz.net/blog/?p=1100 http://targz.net/blog/?p=1100#comments Tue, 03 Nov 2009 09:47:32 +0000 joaquin http://targz.net/blog/?p=1100 En esta sesión veremos como instalar y configurar un servidor de nombre BIND9, lo trastearemos a través de las gadmintools y el webmin si nos deja,  y haremos el seguimiento desde la consola de comandos para ver que es lo que va pasando en el sistema.

Instalar y Configurar un Servidor DNS con BIND9 en Debian Etch con Chroot

En esta oportunidad veremos como instalar y configurar un servidor DNS con Bind9 en Debian 4.0 Etch. El protocolo de DNS (Domain Name System) es el que básicamente permite realizar la traducción entre un nombre de una página Web como lo entendemos nosotros (por ejemplo www.vensign.com) a una dirección IP (172.30.30.1) que es lo que realmente entienden los servidores en Internet. Es un servicio fundamental y sin el simplemente no existiría Internet como la conocemos hoy en día.

BIND9 es un servidor de DNS de código abierto, gratis y que es utilizado por la gran mayoría de los servidores DNS que existen en Internet.

Voy a suponer que tienes un cierto nivel de conocimientos de Linux (no mucho se requiere realmente) solo que sepas abrir un terminal y escribir comandos eso es todo. Te aconsejo que sigas esta guía paso a paso para que le saques el mayor provecho.

Esta instalación fue probada en servidores Debian Etch 4.0. Funciona bien en servidores basados en Debian y en versiones de Ubuntu previas a 8.04.

Vamos a comenzar…

En este caso vamos a hacer la configuración típica de servidores DNS con un servidor primario o maestro con dirección IP 192.168.249.1 y un servidor secundario con dirección IP 192.168.249.2 en caso de que falle el primero. Se utilizará como dominio ejemplo ejemplo.lan

Instalando BIND 9.5

Esta parte aplica tanto para instalar el servidor maestro como el secundario, para esto ejecutamos los siguientes comandos como root:

apt-get update && apt-get upgrade

Para asegurarnos de tener actualizados nuestros repositorios:

apt-get bind9 dnsutils

Con esto se instala el servidor Bind9 y los dnsutils son varias utilidades de DNS que nos serviran más adelante para comprobar nuestro servidor.

Chroot Bind

Cuando se habla de realizar un Chroot a un servicio en Linux se refiere que se va a crear una jaula a su alrededor, esto se hace para medidas de seguridad sobre todo en servidores que están expuestos a Internet como es el caso de nuestros servidores DNS. Esto hace que el servicio se ejecute con su propio usuario dentro de directorios que no tienen privilegios de root para que si llegan a quedar comprometidos el atacante no pueda accesar a otros recursos del sistema.

Para hacer el Chroot de Bind ejecutamos los siguientes pasos:

/etc/init.d/bind9 stop

Para detener el bind

Luego apuntamos el archivo de configuración al directorio que vamos a crear para el Chroot:

vim /etc/default/bind9

Puedes utilizar el editor de tu preferencia en cambio de vim (puede ser nano, emacs, etc)

Y modificamos la línea que dice OPTIONS=”-u bind” por:

OPTIONS="-u bind -t /var/lib/named"

Luego creamos los directorios necesarios para el Chroot

mkdir -p /var/lib/named/etc
mkdir /var/lib/named/dev
mkdir -p /var/lib/named/var/cache/bind
mkdir -p /var/lib/named/var/run/bind/run

Ahora movemos la configuración del Bind de /etc a /var/named/etc:

mv /etc/bind /var/lib/named/etc

Creamos un link simbólico entre la configuración vieja y la nueva para no tener problemas cuando se actualice el Bind:

ln -s /var/lib/named/etc/bind /etc/bind

Luego creamos los dispositivos necesarios para la jaula:

mknod /var/lib/named/dev/null c 1 3
mknod /var/lib/named/dev/random c 1 8

Y por último modificamos los permisos necesarios:

chmod 666 /var/lib/named/dev/*
chown -R bind:bind /var/lib/named/var/*
chown -R bind:bind /var/lib/named/etc/bind

Con esto ya creamos la Jaula y Bind tiene su propio espacio de directorios para sus procesos.

Ahora debemos modificar sysklogd para que se registren (log) los eventos del Bind:

vim /etc/default/syslogd

Puedes utilizar el editor de tu preferencia en cambio de vim (puede ser nano, emacs, etc)

Y modificamos la línea que dice SYSLOGD=”” por:

SYSLOGD="-a /var/lib/named/dev/log"

Ahora debemos modificar el archivo resolv.conf de nuestro servidor:

vim /etc/resolv.conf

Y agregamos la siguientes líneas (recuerda cambiar ejemplo.lan por tu nombre de dominio):

search ejemplo.lan
nameserver 127.0.0.1

Reiniciamos el sysklogd:

/etc/init.d/sysklogd restart

E iniciamos el Bind:

/etc/init.d/bind9 start

Este procedimiento lo tenemos que repetir para el servidor secundario.

Ahora vamos a configurar nuestros servidores.

Configurar Servidor Maestro

Ahora que tenemos el Bind9 instalado vamos a proceder a configurarlo, lo primero que vamos a hacer es decirle que envie las peticiones externas hacia el servidor DNS de nuestro ISP o hacia cualquiera que queramos, yo en lo personal utilizo OpenDNS. Para esto modificamos el archivo /etc/bind/named.conf.options:

vim /etc/bind/named.conf.options

Y descomentamos las líneas que dicen forwarders para que quede de la siguiente forma:

forwarders { 208.67.222.222 };

Recuerda utilizar la IP del DNS de tu ISP, también puedes utilizar la que está en el ejemplo ya que es la de OpenDNS.

Luego vamos a crear nuestra zona que no es más que lo que va a manejar nuestro dominio de ejemplo.lan para esto seguimos los siguientes puntos:

mkdir /etc/bind/zones/
vim /etc/bind/zones/master_ejemplo.lan

Luego dentro de este archivo colocamos la siguiente configuración:

$TTL 3D

@       IN      SOA     ns1.ejemplo.lan. hostmaster.ejemplo.lan. (
                        200808161       ; serial, fecha AAAA-MM-DD + serial
                        8H              ; refrescamiento, en segundos
                        2H              ; reentrar, segundos
                        4W              ; expira, segundos
                        1D )            ; minimo, segundos
;
                TXT     "Ejemplo.LAN, servicio de DNS"
                NS      ns1             ; Direccion Inet del servidor de dominio
                NS      ns2
                MX      10 mail        ; Exchanger de Mail primario
localhost    A    127.0.0.1
ns1          A    192.168.249.1
ns2          A    192.168.249.2
www          CNAME    ns1

Este es un archivo de Zona básico donde declaramos el dominio de ejemplo.lan, los servidores de dominio ns1 y ns2, además declaramos como servidor www (servidor web) a ns1 pero podría ser cualquier otro servidor donde tengas instalado Apache o algún otro servidor Web.

Ahora editamos el archivo /etc/bind/named.conf.local:

vim /etc/bind/named.conf.local

Y escribimos las siguientes líneas:

zone "ejemplo.lan" {
        type master;
        file "/etc/bind/zones/master_ejemplo.lan";
};

Ya con esto podemos probar nuestro servidor master a ver si funciona:

/etc/init.d/bind9 restart

ping ns1.ejemplo.lan

Deberia responder nuestro servidor ns1, recuerda que el servidor debe tener una dirección IP fija y que no debe estar corriendo ningún cliente dhcp.

Tambien podemos probar ejecutando:

host ns1.ejemplo.lan

Debería responder con la dirección de nuestro servidor.

Por útilmo para configurar nuestro servidor master modificamos el archivo /etc/bind/named.conf.options y agregamos la siguiente línea:

dnssec-enable yes;

Creamos una llave segura esto es para que la comunicación entre el servidor master y el secundario sea encriptada.

dnssec-keygen -a hmac-md5 -b 128 -n host ejemplo.lan

Anota el resultado ya que lo utilizaremos tanto en el servidor MASTER como en el SECUNDARIO.

Modificamos el archivo /etc/bind/named.conf y agregamos las siguientes líneas:

include "/etc/bind/rndc.key";

key "TRANSFER" {
        algorithm hmac-md5;
        secret "---HASHKEY---";
};

server 192.168.249.2 {
        keys {
        TRANSFER;
    };
};

Donde dice HASHKEY colocas la clave que generamos anteriormente. Y luego reiniciamos el servidor Bind:
/etc/init.d/bind9 restart

Con esto ya tenemos configurado nuestro servidor master vayamos ahora con nuestro servidor secundario.

Configurar Servidor Secundario o Esclavo DNS

La instalación del servidor Bind en el Secundario es exactamente igual que la del servidor Maestro, voy a mostrar sólo los archivos de configuración que necesitan modificación:

mkdir /etc/bind/zones/
vim /etc/bind/zones/slave_ejemplo.lan

Luego dentro de este archivo colocamos la siguiente configuración:

$TTL 3D

@       IN      SOA     ns1.ejemplo.lan. hostmaster.ejemplo.lan. (
                        200808161       ; serial, fecha AAAA-MM-DD + serial
                        8H              ; refrescamiento, en segundos
                        2H              ; reentrar, segundos
                        4W              ; expira, segundos
                        1D )            ; minimo, segundos
;
                TXT     "Ejemplo.LAN, servicio de DNS"
                NS      ns1             ; Direccion Inet del servidor de dominio
                NS      ns2
                MX      10 mail        ; Exchanger de Mail primario
localhost    A    127.0.0.1
ns1          A    192.168.249.1
ns2          A    192.168.249.2
www          CNAME    ns1

Esto es idéntico al master solo que identificamos como slave al archivo. Luego modificamos el archivo:

vim /etc/bind/named.conf.local

Y escribimos:

zone "ejemplo.lan" {
        type slave;
        file "/etc/bind/zones/slave_ejemplo.lan";
        masters { 192.168.249.1; };
        allow-notify { 192.168.249.1; };
};

Luego modificamos:

vim /etc/bind/named.conf

Y agregamos las siguientes líneas

server 192.168.249.1 {
        keys {
        TRANSFER;
    };
};

Y repetimos lo que hicimos de último con el servidor Maestro.

Modificamos el archivo /etc/bind/named.conf y agregamos las siguientes líneas:

include “/etc/bind/rndc.key”;

key “TRANSFER” {
algorithm hmac-md5;
secret “—HASHKEY—”;
};

server 192.168.249.1 {
keys {
TRANSFER;
};
};

Donde dice HASHKEY colocas la clave que generamos anteriormente. Y luego reiniciamos el servidor Bind:

/etc/init.d/bind9 restart

Ya con esto tenemos configurado el servidor Esclavo o Secundario, ahora debes indicarle a tus PC que que estan son las direcciones de servidores DNS primario y secundario que deben utilizar y si quieres probar que uno funciona cuando el otro se cae puedes detener el bind en cualquiera de los dos.

Espero que les haya servido este tutorial, cualquier duda, pregunta o sugerencia puedes dejar tu comentario y lo responderé a la brevedad posible.

Saludos

Olivers

]]> http://targz.net/blog/?feed=rss2&p=1100 0 http://targz.net/blog/?p=1092 http://targz.net/blog/?p=1092#comments Mon, 02 Nov 2009 18:11:08 +0000 joaquin http://targz.net/blog/?p=1092

Herramientas para facilitar la administración de Linux

Para no tener que configurar todos los servicios editando ficheros de configuración, en linux, existen una serie de herramientas gráficas que nos facilitan la configuración de muchos de los servicios que podemos instalar.

Algunas de ellas son:

Webmin es un interface que mediante una conexión segura nos permite configurar el sistema y múltiples servicios via web.

Phpmyadmin, nos permite gestionar bases de datos MySql via web

SWAT: nos permite la configuración del servidor de ficheros SAMBA via web

Las Gadmin tools

Son una serie de herramientas que nos permiten configurar en modo gráfico algunas funciones de servidor como DNS, DHCP, FTP, Proxy, VPN…

Gadmin-tools

http://gadmintools.flippedweb.com/

Un manual para configurar algunas de ellas:

http://patrick.seeling.org/files/fall2008/cis463_GadminToolsd.pdf

dhcp, dns httpd

En el caso de que no pudiéramos instalar uno de los programas con el aptitude o el apt, o despues de hacerlo no funciona, siempre se puede instalar desde el código fuente, bajandolo desde la página oficial del programa gadmintools.com

averiguamos las dependencias con

aptitude show gadmin-tools

Y las instalamos con el apt o a mano

Despues bajamos el tar.gz y lo descomprimimos con

tar -zxvf nombre_del_paquete.tar.gz

Leemos el fichero README y el INSTALL para ver las instrucciones de instalación.

Instalar Webmin en Ubuntu paso a paso

Fuente: http://sliceoflinux.com/2009/09/07/instalar-webmin-en-ubuntu-paso-a-paso/

Administración de servidores Linux/Unix con webmin

fuente: http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=webmin

Mas manuales sobre webmin (en inglés):

http://swelltech.com/support/pdfs/webminguide.pdf

http://www.thededicatedserverhandbook.com/landing/webminbook.php

]]> http://targz.net/blog/?feed=rss2&p=1092 0