Feb 12

eBox – servidor, gateway i d’altres funcionalitats avançades per PIMES

Reading time: 6 – 10 minutes

ebox-logo.pngL’any 2.006 vaig descobrir eBox, fins hi tot vaig escriure un article que parlava d’ell. Doncs a arrel del article que vaig escriure fa unes setmanes sobre clearOS l’Oriol em va fer pensar altre cop amb l’eBox preguntant-me què tal estava. Doncs bé, la curiositat em va picar i el dilluns el vaig instal·lar en una màquina virtual.

Així doncs a estones durant tota la setmana he estat jugant una mica amb l’eina. En linies generals he de dir que ha millorat moltíssim des de que el vaig descobrir i que integra un munt de funcionalitats noves. La usabilitat continua sent un punt fort de l’eina i també la facilitat d’ús. Jo diria que qualsevol administrador de sistemes de linux en té prou amb uns pocs minuts per sentir-se molt còmode usant l’eina.

Per altre banda no vull deixar de destacar que com a backend per la gestió d’usuaris per tots els serveis que té usa LDAP, cosa que m’ha agradat moltíssim. O sigui, que tenim un postfix, squid, dovecot, asterisk, jabberd2, openvpn, etc. De fet, només això en si mateix ja és un bon motiu per tenir-lo instal·lat en algún racó ja que sempre ens pot anar bé per consultar alguna configuració. A més de poder tenir un esquema d’usuaris per LDAP que podem reaprofitar per integrar en la xarxa de servidors o de desktops. Ja sigui per integrar en el PAM dels linux i/o en l’autenticació dels windows ja que el podem fer treballar com a PDC.

Com ja em va passar amb clearOS, potser el més dolent és que es troben a faltar algunes opcions de configuració que al dissenyar una interficie gràfica simple han hagut d’estalviar-se. Malgrat això l’openVPN disposa de moltes més funcions que no pas el clearOS, a més de la possibilitat d’omplir un camp on podem posar els nostres parametres a mida directament contra el fitxer de configuració. El que ja és impressionant és que integra la possibilitat de poder generar fitxers .exe amb el client d’VPN i totes les configuracions pels clients integrades en l’instal·lador. És a dir, podem generar un fitxer d’instal·lador de l’VPN per cada un dels clients.

A més també vull destacar que disposa d’una PKI propia que per gestionar els certificats dels diferents serveis va molt bé. A més de poder-la utilitzar per generar certificats que després usarem en altres aplicacions ofra del eBox.

Per no seguir fent una valoració desordenada dels serveis que té l’eBox a continuació enganxo la llista de funcionalitats que he trobat a la seva web i al costat hi posaré un comentari a les que ho cregui pertinent.

  • Networking
    • Firewall and routing- bons i simples sistemes de monitorització per la xarxa cosa que sovint es troba a faltar.
      • Filtering – integració força bona de les iptables
      • NAT and port redirections
      • VLAN 802.1Q
      • Support for multiple PPPoE and DHCP gateways – ideal per tenir diverses ADSL en monopuesto.
      • Multi-gateway rules, load balancing and automatic failover – trivialitza aquesta tasca a més de poder-ho configurar fins a un detall força decent.
      • Traffic shaping (with application layer support)
      • Graphical traffic rate monitoring
      • Network intrusion detection system
      • Dynamic DNS client
    • Network infraestructure
      • DHCP server
      • NTP server
      • DNS server
        • Dynamic updates via DHCP
      • RADIUS server – molt agraït el tenir aquesta capacitat per integrar amb linksys o d’altres similars a l’hora de montar un hotspot o per montar autenticacions segures wifi
    • VPN support – molt decent la integració.
      • Dynamic routes autoconfiguration
    • HTTP proxy – forma senzilla de tenir tot el que cal en proxies.
      • Internet cache
      • User authentication
      • Content filtering (with categorized lists)
      • Transparent antivirus
    • Intrusion Detection System – integra SNORT!!! (el vaig usar al meu PFC)
    • Mail Server – un 9!!! una integració molt aconseguida i que fa tot el que li cal a una PIME i més
      • Virtual domains
      • Quotas
      • SIEVE support
      • External account retrieval
      • POP3 and IMAP with SSL/TLS
      • Spam and antivirus filtering
        • Greylisting, blacklisting, whitelisting
      • Transparent POP3 proxy filter
      • Catch-all account
  • Webmail
  • Web server – aquí és on més coixeja el tema sota el meu punt de vista perquè no et deixa tocar pràcticament res del servidor web, o almenys jo no ho he sabut trobar.
    • Virtual hosts
  • Certification authority – realment útil i simple
  • Workgroup
    • Centralized users and groups management
      • Master/slave support
      • Windos Active Directory Synchronization
    • Windows PDC
      • Password policies
      • Support for Windows 7 clients
    • Network resource sharing
      • File server
        • Antivirus
        • Recycle bin
      • Print server
    • Groupware: calendar, address book, webmail, wiki, etc. – personalment no m’agrada gens aquesta eina.
    • VoIP server – poc configurable pel meu gust, però a destacar el ben integrada que esta amb el LDAP, no he sabut veure si tb ho esta amb el XMPP/jabber2.
      • Voicemail
      • Conference rooms
      • Calls through an external provider
      • Call transfers
      • Call parking
      • Music on hold
      • Queues
      • Logs
  • Jabber/XMMP server – això no m’ho esperava, però felicitats per haver-hi pensat.
    • Conference rooms
  • eBox User Corner for self users info updating – va molt bé pq els usuaris s’ajustin el que els cal sense molestar l’administrador.
  • Reporting and monitoring
    • Dashboard for centralized service information
    • Monitor CPU, load, disk space, thermal, memory
    • Disk usage and RAID status
    • Summarized and full system reports
    • Event notification via mail, RSS or Jabber – molt interessant totes les possibilitats de monitorització que té, això val un imperi.
  • Software updates
  • Backups (configuration and remote data backup) – molt simplificada la tasca, no sé què copiara però si ho fa bé, això és brutal.
  • Control Center to easily deploy and administrate several machines running eBox Platform – aquí és on entren les funcionalitats de pagament, ho trobo molt raonable i molt bona idea.

Per acabar he de dir que clearOS hem va agradar moltíssim, potser trobaria algunes coses que les fa millor que l’eBox però he de dir que aquest és realment molt millor que l’altre. En faig una valoració realment positiva i el recomano moltíssim. Això si, si hagués de montar-ne algún en una empresa primer montaria clearOS faria un o dos dies de proves i després montaria eBox per acabar d’estar-ne content. Encara que hagués de pagar aquests dies de feina de la meva butxaca crec que estarien molt ben invertits.

NOTA: Que no se m’oblidi eBox es basa en Ubuntu i clearOS en centOS, malgrat estic familiaritzat amb els .rpm gràcies a Fedora, he de dir que hem sento molt més còmode amb eBox i això pesa molt.

Jun 24

Microfon intern del Dell XPS m1330 funciona amb Linux

Reading time: < 1 minute

No m’havia posat a provar mai el microfon intern del portàtil ja que sempre havia llegit que no funcionava. Però ahir vaig actualitzar el kernel a la verisó 2.6.25-gentoo-r5 i hem vaig decidir a provar a veure què tal. Doncs bé la veritat és que oli en un llum. Ja que només he hagut de canviar la font d’entrada de gravacions i ha funcionat a la primera així és com l’he de deixar:

gnome volume manager

La veritat és que he tingut molta sort 😉

Apr 05

Rack Tables: inventari dels servidors que tenim als racks

Reading time: 2 – 3 minutes
racktables.png

A primer com de vista i pel que puc veure en la demo, ja que no l’he usat mai encara, m’agrada molt el que preten fer el Rack Tables. Bàsicament la idea és mantenir un inventari de què hi tenim montat a cada un dels armaris rack que tenim destribuits per tot el món. Això quan tens un garbuix al cap del que té cada client com em passa a mi sovint pot ser molt útil. Sobretot perquè s’hi poden adjuntar fotografies o portar un control exahustiu de les U’s que hi tenim lliures, dels ports de switch ocupats, etc. Per tant, diria que és una eina molt recomanable per administradors de sistemes. Fins hi tot diria que imprescindible per admins d’empreses de serveis que no tenen contacte diari amb els datacenters dels clients.

També permet portar un registre dels espais d’IPv4 en això s’assembla una mia al IPplan malgrat les funcions d’aquest aplicatiu són molt més simples i es redueixen a funcions purament d’inventari. Al estar orientat a servidors ens permet mantenir un registre dels serveis virtuals que tenim corrent, pools de màquines i fins hi tot algunes funcions de monitorització a nivell de gràfiques sobretot. Per cert, m’agradaria descatar que potm ostrar l’estat dels balancejadors de carrega web, per exemple.

És important recordar que és una eina d’inventari, en això vull dir que el que aquí interessa no és pas veure com les coses canvien en temps real. Sinó poder mantenir un registre de com tenim o volem tenir montada l’infraestructura. És a dir quelcom més proper a una ajuda per mantenir la documentació que no pas una eina de supervisió. Per això ja tenim nagios, no?

No ho havia comentat però l’aplicació funciona via web i malgrat no m’hi he fixat massa diria que és la típica aplicació feta amb PHP i MySQL. Potser per ser una aplicació web la trobo una mica massa anticuada tan en el disseny com en la poca introducció de funcionalitats AJAX que la facin més usable i atractiva a l’usuari.

Mar 31

SMB per FUSE (fusesmb)

Reading time: 2 – 2 minutes

FUSE com segur que ja sabeu es carrega com un mòdul del kernel i ens permet accedir al sistema de fitxers a través des d’una aplicació d’usuari, és a dir a una aplicació que no necessariament ha de tenir permisos d’administrador. Doncs bé en aquest cas es tracta de navegar pels WORKGROUPS, hosts, shared folders i impresores publicades a la xarxa a través del protocol SMB. Perquè ens entenguem el protocol que usa windows de tota la vida per compartir recursos de xarxa. Doncs amb el petit aplicatiu del que parlo podrem navegar per tots aquests recursos de xarxa com si es tractés de directoris del nostre sistema de fitxers linux. Realment útil i còmode això de poder accedir a recursos de xarxa sense haver de montar aquests recursos des de la nostre CLI.

Si els recursos de xarxa compartits ho estan sota autenticació al accedir al directori que representa el recurs en denegarà l’accés. Perquè això no passi cal passar com a paràmetres del fusesmb el nostre usuari i paraula de pas del recurs de xarxa. El dolent, és que si tenim diversos usuaris per autenticar-nos segons el recurs no ho podrem expresar des d’una mateixa instància del programa. Així doncs, pel meu gust li falta algun petit workaround que ens llenci interactivament la pregunta d’usuari i paruala de pas a l’entrar a un recurs protegit.

Malgrat això el fusesmb considero que és una eina molt còmode per accedir als recursos de xarxa sobretot si hi podem accedir amb el mateix usuari i password, o sigui, el que acostuma a passar si la xarxa a la que estem és la nostre.

Mar 27

python trick: compartir directori via HTTP

Reading time: 1 – 2 minutes

A vegades estant en la propia LAN, suem tinta per dir-li a un usuari de windows com ho ha de fer per agafar un fitxer d’un directori del nostre linux. Si teniu python instal·lat, normalment totes les distribucions l’instal·len per defecte a més del paquet HTTP. Podeu fer una cosa tan simple com posar al .bashrc:

alias quickweb='python -c "import SimpleHTTPServer;SimpleHTTPServer.test()"'

Ara aneu al directori on voleu compartir els fitxers i escriviu: quickweb. Això obrirà el vostre port 8000 i qualsevol usuari de la xarxa podrà connectar-se amb el navegador a la vostre IP pel port 8000. Allà es pot veure i descarregar els fitxers que hi teniu. Quan volgueu deixar de compartir el directori només cal fer un Control+C i llestos.

Realment una xorrada molt i molt útil, no? si voleu comprovar què esteu compartint ja ho sabeu: http://127.0.0.1:8000. Més senzill impossible.

Mar 15

openfiler: potent i complicat de configurar

Reading time: 4 – 6 minutes

M’ha costat deu i ajuda posar a funcionar l’openfiler al final ja era una qüestió d’honor. Després de provar amb la versió pre-instal·lada com appliance i amb dues versions instal·lades per mi no hi havia manera de que funcionés tot plegat com volia.

Problema reconeixer volums lògics pre-creats

El primer gran problema ha estat que jo ja tenia un volume group creat, amb dos logic volumes (unitats lògiques d’informació usades per LVM). Doncs bé malgrat el linux me’ls retornava sense problemes amb el vgdisplay i lvdisplay quan anava a l’interficie de l’openfiler no hi havia manera que apareguessin els volums lògics. El grup de volums si que sortia però els lògics no. Doncs bé la solució l’he trobat després de molt buscar pels forums a aquest thread: How to get volumes back after reinstallation without config backup.

La gràcia esta en un script que bàsicament genera un fitxer XML de configuració que usa l’openfiler per saber quins volums hi ha al sistema: /opt/openfiler/etc/volumes.xml. El fitxer és força simple i només té una llista de volums lògics relacionats a un grup de volums. L’script també afegeix al /etc/fstab les línies necessaries perquè aquests volums lògics es montin a l’arrancar el sistema.

Còpia de l’script que he trobat al forum: remake_vol_info.

Problema LDAP amb tots els serveis i especialment amb el SMB

Doncs bé, aprofitant que openfiler porta un servidor LDAP volia gestionar les comptes de tots els serveis a través d’un únic punt. Així doncs, el primer problema ha estat saber com activar el servidor que porta internament perquè la documentació no ho explica massa bé, ja que si anem a serveis i li fem un enable sense donar cap error no s’aixeca ni a la de tres. Aprofito per comentar que la interficie gràfica de l’openfiler és realment pèssima i difícil d’entendre. A més, l’experiència d’usuari esta molt poc cuidada perquè moltes coses donen errors i no ho explica retorna enlloc. Així doncs t’hs de buscar la vida monitoritzant els fitxers de logs del linux que té per darrera.

Llavors he intentat actualitzar el sistema a través de la funció d’update que porta la pròpia interficie. Doncs be, també fallava així doncs ho he provat des de la línia de comandes amb un simple:

conary updateall

La cosa fallava amb el mateix error:

...
Warning: Unhandled exception occured when invoking callback
/user/lib/pgthon2.4/site-packages/conary/streams.py:416
...

Després de googlejar una bona estona, la solució ha estat:

conary update conary --replace-files
conary updateall --replace-files

Amb això he aconseguit finalment fer update. Però el problema amb LDAP continuava igual. Al final he deduit que si posava la informació a accounts -> authentication. Amb el password que he posat al fer la instal·lació per l’usuari de configuració del web la part d’usuaris i grups semblava que s’activa i el LDAP server començava a funcionar tot solet.

ldap.png

Així doncs, he pogut accedir a la gestió de comptes i crear un grup d’usuaris i un usuari de proves. Doncs bé, després de suar tinta per entendre tot el tema de gestió de shares i de veure que no hi havia manera d’accedir als recursos compartits de forma autenticada, he decidit aprofitar la meva experiència en linux per veure com estava tot configurat.

La qüestió és que he vist que tan el SMB, com el FTP, HTTP/WebDav, etc. anaben contra PAM però aquest no tenia configurat cap enllaç cap a LDAP, per tant, per molt que estigués funcionant era impossible que mai autentiques cap usuari.

Llavors he executat el authconfig per configurar l’autenticació PAM contra LDAP, i l’he deixat així:

Al marcar l’autenticació LDAP per SMB, no ús ho perdeu m’ha dit que faltava el paquet pam_smb, o sigui, el pàquet de PAM que té el handler capaç de gestionar la connexió contra LDAP pel samba. Algú em pot explicar com pretenien la gent d’openfiler autenticar samba amb LDAP si no hi havia això instal·lat? aquí ja he arribat a la conclusió que això de l’openfiler esta verdíssim.

Bé doncs, després de suar una mica amb tot això que comento ja funciona tot contra LDAP a la perfecció!!! realment he de reconeixer que sóc una persona obstinada,eh!? perquè n’hi ha per deixar-ho correr. Després de tot el que he explicat i les hores que he hagut d’invertir per descobrir-ho.

Mar 15

Rendiment OpenFiler virtual

Reading time: 2 – 2 minutes

Porto tot el dia fent proves amb l’OpenFiler com a màquina virtual dins del servidor HP que estic montant. Doncs, bé apart dels detalls tècnics volia fer una simple i interessant prova que després de veure el resultat encara em té estorat. He fet un test de velocitat amb el hdparm per saber la velocitat de transferència entre l’ubuntu que fa de servidor d’VMWare i un disc dur de 750Gb:

root@vm0:~# hdparm -t /dev/sdc1
/dev/sdc1:
 Timing buffered disk reads:  314 MB in  3.02 seconds = 104.11 MB/sec

Després des de la màquina virtual amb OpenFiler (basat en linux Red Hat) he fet la màteixa prova:

[root@nas0 ~]# hdparm -t /dev/sdb1
/dev/sdb1:
 Timing buffered disk reads:   66 MB in  3.05 seconds =  21.65 MB/sec

Malgrat el nom del dispositiu surti diferent el dispositiu és el mateix, això passa perquè en la màquina virtual el dispositiu no és el tercer dispositiu ‘SATA‘, sinó el segon. La màquina virtual té capturat el dispositiu físic, així doncs trobo que la diferència de velocitat és exagerada. També s’ha de comentar que l’OpenFiler no m’ha deixat instal·lar-se en 64bits sobre VMWare i ho he hagut de fer amb 32bits, no sé pas si aquesta diferència tan brutal pot ser deguda a això.

Els recursos que tinc assignats a l’OpenFiler són:

nas0.png

Si algú té la possibilitat de fer alguna prova semblant, o l’ha fet que avisi. De totes formes, diria que amb màquines virtuals de 64bits no puc capturar el dispositiu real o això m’ha semblat llegir que deia el VMWare. Gran defecte sota el meu punt de vista.

Mar 10

Recuperant disc dur de 750Gb

Reading time: 1 – 2 minutes

Fa unes setamens vaig comprar un disc dur de 750Gb SATA II pel server nou que estic montat per casa. Doncs en plena migració de dades em vaig adonar que el disc es quedava fregit i em penjava el servidor. Avui m’han donat un altre disc de 750Gb per posar-hi les dades i ara mateix acabo de fer un dd if=/dev/sda of=/dev/sdb. Germans preguem! 😉 no sé si podré aguantar tan de temps amb els dits creuats esperant a que passin totes les dades sense problemes. Esperem que així sigui… la foto de l’espectacle:

750gb-dd.png

Update1: no s’ha completat el dd, pel que he observat l’error pot venir del cable. Ja que ha cascat el nou disc dur durant la còpia no el qu jo em pensava que fallava. Ja que tenia el nou disc dur amb el cable del que teoricament fallava. Aquesta tarda ho provaré amb un cable SATA nou i a veure què passa.

Update2: des d’ahir a la tarda tinc el disc dur amb un cable nou i de moment no ha petat i ja li he enviat uns quants gigues via sftp. A veure si tindrem sort.

Update3 (i final?) segueix funcionant bé, de moment podem dir que era el cable. Ja informaré si canvia algo.

Feb 26

mikrotik: failover gateway

Reading time: 4 – 6 minutes

Avui he refrescat una mica la meva memòria, feia algún que altre mes que no jugava amb els mikrotik. Doncs bé, per un client havia de montar un failover gateway i com que ja sabeu que sóc un fan declarat dels mikrotik per fer això he usat un RB150. Per si això ús sona a xinès segur que amb una petita explicació ho trobareu molt útil. Doncs bé, cada cop més empreses tenen dos sortides a internet i el que volen és que quan alguna de les dues sortides caigui l’altre sortida assumeixi tot el tràfic sense haver de tocar res.

Obviament per fer això el que hem de tenir és un element que s’encarregui de redirigir tot el tràfic cap a un router o cap a l’altre segons si la sortida a internet esta fallant o no. La solució que plantejo és molt simple i pot perfeccionar-se moltíssim. Per exemple, l’únic que explicaré és a usar un dels dos routers i quan aquest falla enviar el tràfic cap a l’altre però no és gaire difícil crear unes policy routes per balancejar tràfic entre els dos routers mentre aquests estiguin operatius. Però per no liar la cosa em quedaré amb l’exemple bàsic. A partir d’aquí, la base estarà més que feta perquè feu coses més xules.

routerboard-inabox-02.png

escenari

El RB150 tindrà a l’ethernet 1 la xarxa LAN. A la ethernet 4 la WAN1 i a la ethernet 5 la WAN2. Amdues interficies tenen el router ADSL en monopuesto. O sigui, que tinc la IP pública a l’interficie del router.

funcionament

Per defecte, sortirem per la WAN1 i quan aquesta falli sortirem per la WAN2.

configuració

Assumeixo que les configuracions bàsiques ja estan fetes, o sigui, assignació d’IPs a interficies i l’enmascarament d’IP internes cap a internet. Això suposo que no té cap dificultat si algú necessita ajuda que avisi.

Creem dos scripts a llençar quan s’hagi de llençar la connexió via WAN1 i l’altre via WAN2:

Script per la WAN1:

:log info wan_1
/ip route set [/ip route find dst-address="0.0.0.0/0"] gateway=IP_GW_WAN1

Script per la WAN2:

:log info wan_2
/ip route set [/ip route find dst-address="0.0.0.0/0"] gateway=IP_GW_WAN2

Si ens interessa en cada un dels scripts hi podem afegir el que calgui. Per si no esteu habituats a treballar amb scripts al mikrotik els heu de colocar a /system scripts. Allà afegiu dues entrades i llestos. Com sempre això serà molt més còmode fer-ho des del winbox que no pas des de la cli.

Ara només cal que creem una entrada a l’eina netwatch, això es fa a /tool netwatch. A l’entrada li direm que faci pings cada un interval de temps que decidirem i que tingui un timeout fixe i si els pings no tornen llavors s’executarà l’script indicat. Bàsicament le entrades de netwatch tenen dos estats el up i el down i podem associar un script a llençar en cas de que hi hagi una oscil·lació cap a un dels dos estats. Això es fa així:

add host=208.67.222.222 timeout=10s interval=1m up-script=wan1 down-script=wan2 \
comment="Failover Gateway Script" disabled=no

El que fem és mirar si arribem a un dels servidors d’OpenDNS cada 1minut i ens esperem com a molt 10s perquè el ping torni. Després fixeu-vos com associem cada un dels scripts que em programat abans als estats d’aquesta prova.

Com podeu veure això és ben senzill, la gràcia esta en que jugueu amb els ECMP i els policy routing i feu del RB150 tot un balencejador de càrrega amb suport de fallides de línia. També és molt senzill que balancegeu el tràfic d’entrada d’internet cap a una ADSL o cap a l’altre, per fer això ús recomano que jugueu amb el DDNS que podeu actualitzar a través dels scripts comentats, només cal que li llenceu la petició d’actualitzar la IP associada al DDNS i els usuaris remots entraran per una o altre línia.