oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: administration

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

2010/02/12 2 comentaris

Reading time: 6 – 10 minutes

L’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.

Turnkey Linux Virtual Appliances

2010/01/13 1 comentari

Reading time: 2 – 3 minutes

Turnkey Linux logo

Ahir comentava que el Carles hem va parlar de ClearOS, doncs bé, també em va comentar que hi havia un projecte opensource anomenat Turnkey Linux que bàsicament es dedica a fer software appliances amb els paquets de codi lliure més famosos, per exemple: LAMP, drupal, joombla, phpBB, dokuwiki, mediawiki, rails, tomcat, mysql, wordpress, etc. actualment diria que hi ha 56 paquets.

De fet, a part de per fer proves sobre certs paquets no trobo massa interessant aquestes software appliances. Però el que si que realment m’ha cridat l’atenció i he estat provant fa uns dies és el Turnkey Core, que en escència és la base del sistema que ells usen per montar les software appliances. Escencialment es tracta d’agafar una Ubuntu 8.04.3 LTS i donar-li suport de:

Target systems:
- CD d’instal·lació optimitzat (instal·lació mínima) i ús com a liveCD
- Màquines virtuals: VMDK HD i OVF (Xen, VMWare, Parallels, VirtualBox)
- Amazon EC2 AMI
Configuration console (feta en python), permet configurar de forma senzilla funcions bàsiques:
- xarxa
- apagar
- reiniciar
Ajax Web Shell (shellinabox): client SSH via web, realment va molt bé!
Web Management via Webmin
Regenera les claus dels certificats durant la instal·lació
- SSL: webmin, apache2, lighttpd
- SSH
Definir el password de root durant la instal·lació

Com podeu imaginar-vos la meva idea és agafar aquesta base de sistema per montar els meus propis servidors ja sigui a nivell privat o professional. De fet, estalvia prou feina i la instal·lació que fa Turnkey Core d’Ubuntu és prou petita com per fer una instal·lació a mida en cada cas. O sigui, que es poden intal·lar els paquets que volem sense haver de tenir coses innecessaries. Això si, pensant sempre en servidors.

clearOS Enterprise

2010/01/12 2 comentaris

Reading time: 3 – 4 minutes

Abans de marxar de vacances tot parlant amb el Carles vaig descobrir el clearOS i després d’un parell de dies fent-hi proves esporàdiques no volia deixar l’oportunitat d’escriure quatre ratlles sobre el que m’ha semblat.

Es tracta d’una distribució de linux especialment orientada a petites empreses amb pocs servidors, malgrat per algunes mitjanes empreses també crec que estaria ben indicada. Basada en Redhat/CentOS i totalment focalitzada a ser usada via una interficie web força amigable.

Incorpora diverses eines sempre gestionables desde web que permeten fer funcions de servidor de xarxa i/o de gateway de comunicacions. Per exemple:

funcions de directori
- LDAP amb usuaris i passwords integrats per la resta de serveis
- gestor de certificats de seguretat
funcions de xarxa
- multi-wan
- VPN, PPTP, IPSec, OpenVPN
- DMZ i NAT 1-1
- funcions de firewall
- servidor DHCP i DNS
- UPnP
funcions de gateway
- antimalware: antivirus, antiphing i antispyware
- antispam
- gestor d’ampla de banda
- detector d’intrusions
- filtres de protocols, fins hi tot P2P
- filtres de continguts
- web proxy
- control d’accés
funcions de servidor
- Windows Networking com a PDC
- serveis de fitxers i impresores
- flexshares (diverses formes de compartir fitxers: SMB, FTP, Web, etc)
- groupware i connector d’outlook
- servidors de correu: POP, IMAP, SMTP, Webmail i recollida de correu
- filtres de correu: antispam, antimalware, greylisting i quarantena
- arxivador automàtic de correu
- gestor de bbdd MySQL
- servidor web amb PHP

A més al estar orientat a un entorn professional l’empresa que desenvolupa clearOS disposa d’un servei anomenat clearSDN, a través del qual es pot obtenir:

Software Updates Priority security and bug updates to the ClearOS software.
Content Updates Required updates to Content Filter, Intrusion Protection, Antispam and Antimalware.
Monitoring Alarms and reporting for bandwidth, resource and security management.
Remote Services Critical services for VPN, DNS and Remote Server Backup.

Fins hi tot tenen uns dispositius anomenats clearBOX que porten el sistema operatiu integrat i ja disposen d’uns quants ports ethernet, ideals per fer de gateway o fins hi tot de switch.

Com no podia ser d’altre forma tot plegat té un bon manual de suport pels usuaris més novells, ja que només amb una mica d’experiència en l’administració de sistemes tot plegat es fa molt intuitiu.

En general m’ha quedat un bon gust de boca pel que fa a l’eina, potser on més he trobat que coixeja el sistema és en detalls de configuració més avançats, per exemple, del servidor d’OpenVPN i cosetes similars. Però per empreses petites i mitjanes com ja deia abans és més que suficient en la majoria de casos.

Problemes de rendiment OpenFiler amb VMWare Server [solucionat]

2008/09/14 2 comentaris

Reading time: 3 – 4 minutes

Després de molts mesos amb un greu problema de rendiment al servidor SAN/NAS de casa que tinc montat en una màqina virtual d’VMWare Server sobre Ubuntu 8.04 LTS, per fi m’he decidit a arreglar el problema. En algún altre post havia comentat el problema, la qüestió és que el rendiment dels 1.5Tb que tinc al servidor des del sistema operatiu de Host és d’uns 70MB/s però les mateixes proves des dels discos gestionats per la màquina Guest, o sigui l’OpenFiler, donaven uns patetis 3, 4 o com a molt 5MB/s. O sigui, que quan s’accedia per NFS o SMB als recursos compartits el rendiment era insuficient i d’altres servidors o màquines que usen aquests recursos se’n veien repercutits.

Finalment després de buscar una mica vaig veure que el problema venia de les interrupcions del sistema que es perdien degut a que el clock rate del servidor Host no era capaç de processar tantes interrupcions. Així doncs, investigant sobre el tema vaig veure que el que cal fer és donar suport HPET, en el meu cas perquè això funcioni ho he hagut d’activar també a la BIOS del HP ML110 que uso com a servidor físic. Amb aquests canvis els tests de velocitat de la màquina virtual amb OpenFiler m’han millorat substancialment i ara mateix donen resultats al voltant de 50MB/s. Obviament, encara estic lluny d’un rendiment òptim però ja no sé si això és tema de configuració o si el problema és més profund i ja depèn de la propia gestió interna que fa l’VMWare amb els mòduls que fan d’interficies entre el hardware real i el virtual.

Si voleu saber si teniu el HPET activat o no al kernel és tan senzill com mirar al dmesg:

root@vm0:~# dmesg |grep hpe
[  120.210408] hpet clockevent registered
[  120.210412] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[  120.210416] hpet0: 3 64-bit timers, 14318180 Hz

En cas de no tenir-lo activat, cal que activeu el següent al fitxer .config del kernel:

CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_RTC=y

A part d’això hi ha d’altres opcions per tal d’acotar aquest tipus de problemes, algunes que permeten estabilitzar les màquines virtuals malgrat no les expremem al màxim ens poden permetre funcionar millor si el rendiment no és el màxim dels nostres problemes i no saturem el Host. Per exemple, es pot afegir al fitxer .vmx de la màquina virtual la següent opció:

host.useFastClock = FALSE

Per cert, si voleu identificar el problema el kernel de la màquina Host dona errors de l’estil:

Aug 21 12:56:11 dey kernel: rtc: lost some interrupts at 2048Hz.

o també coses així:

select() to /dev/rtc to wait for clock tick timed out.

Com sempre a google podeu trobar moltíssima informació de com ajustar el vostre Linux perquè rendeixi al màxim amb VMWare. Per la meva part, ara hem queda posar en marxa mil i una coses que depenien d’aquest servidor de fitxers que mica en mica anava obligant-me a parar serveis per manca de rendiment. Espero que properament ja pugui posar en marxa funcions com l’album de fotografies i d’altres similars.

spacewalk – el RedHat Network Satellite alliberat

2008/07/02 No hi ha comentaris

Reading time: 4 – 6 minutes

No sóc un gran coneixedor dels productes de RH, ni tampoc de Fedora ni CentOS. Malgrat això per temes de Kerberos, LDAP i d’altres similars m’estic endinsant força en aquest món. Doncs bé, el dia 20 de juny la gent de RH van alliberar el codi del RedHat Network Satellite al project l’han anomenat spacewalk. Després d’una bona estona llegint la seva documentació volia comentar que la idea que proposen i el nivell d’integració que té l’eina és molt bona, malgrat això he de dir que no hem serveix de gran cosa degut a que esta massa orientat a distribucions amb sistemes de paquets .rpm, o sigui, la propia RH i Fedora sobretot, de CentOS i la resta en parla ben poc.

Cal dir però que les funcionalitats que ofereix són relment una font d’inspiració per d’altres productes que algún dia algú haurà de dissenya per distribucions basades en .deb, o sigui, debian i ubuntu bàsicament.

Llistat de funcionaltats de l’spacewalk:

Inventory your systems (hardware and software information)
Install and update software on your systems
Collect and distribute your custom software packages into manageable groups
Provision (kickstart) your systems
Manage and deploy configuration files to your systems
Monitor your systems
Provision and start/stop/configure virtual guests
Distribute content across multiple geographical sites in an efficient manner.

A continució ús dono una petita llista d’eines que malgrat no estar tan ben integrades com l’spacewalk i sovint no disposar de bones interficies poden ser un bon punt per començar a solucionar alguns problemes:

puppet: basada en un llenguatge ruby com a llenguatge d’scripting per llençar funcions remotament contra sistemes remots, l’eina és realment potent però la veig poc integrada amb el sistema operatiu i es basa molt en funcions com expect per capturar les sortides de les comandes de sistema executades remotament. A més considero que no té un bon sistema d’informes per saber com ha anat el deploy.
capistrano: molt semblant a puppet, tan és així que usa també ruby com a llenguatge d’scripting i tots els problemes comentats antiriorment els hi veig també a aquest. Té una mica més ben resolt el tema del feedback dels deploys però sota el meu punt de vista no acaba de ser suficient.
func: projecte que també ve de RH i que té el codi alliberat, actualment en fan el manteniment la gent de Fedora. Es basa en Python com a llenguatge d’scripting i ofereix tota una API per la gestió de comandes remotes, ben pensat per xarxes grans ja que permet llençar comandes de forma asícrona. Disposa d’una molt bona integració amb el sistema operatiu gràcies a la gran quantitat de bindings que te Python. Per exemple, com que és un producte de fedora només disposa de binding genèric de yum per instal·lar paquets remotament, però gràcies a que el llenguatge d’scripting és Python és molt senzill crear un mòdul de func que enllaci amb python-apt i permetre instal·lar paquets a una ubuntu. Aquesta bona integració permet controlar els feedbacks d’una forma molt eficients malgrat no disposa d’eines d’informes pròpies.
fai: és una eina pensada per fer instal·lacions automàtiques de distribucions linux o de sistemes de clusters, ja siguin virtualitzats o amb màquines reals. El projecte té uns grans avals i porta moltíssims anys online i actiu. Per tant, dona moltíssima confiança. El dolent és que no sembla trivial d’usar i malgrat té una eina per monitoritzar l’estat del deploy és basa moltíssim en CLI. No he vist cap GUI que en faciliti l’ús excepte GOSA, el qual és un projecte molt ampli d’LDAP bàsicament usat per la migració a Linux de l’ajuntament de Berlin.
cobbler: una eina molt semblant a fai, però de la gent de RH i amb el codi alliberat. Té molt bona pinta i a més s’integra amb func. No l’he estudiat a fons encara per saber on té els punts febles, ja que com sempre el que més por fa és la dependència de paquets .rpm; malgrat això disposa d’una interficie web per la gestió, línia de comandes i API en python per extendre les seves funcionalitats i sempre es podria lligar una instal·lació cobbler amb func perquè fos compatible amb ubuntu tal com havia comentat abans.

openfiler: potent i complicat de configurar

2008/03/15 6 comentaris

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.

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í:

original size

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.

Rendiment OpenFiler virtual

2008/03/15 No hi ha comentaris

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:

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.

QGRUBEditor – Editor gràfic del fitxer menu.lst del Grub

2007/06/28 No hi ha comentaris

Reading time: < 1 minute

Sempre va bé tenir una referència d’aquestes aprop per quan hem de modificar el fitxer i no volem anar consultant el man. La veritat és que no l’he provat encara i potser ni el provi mai perquè ja tinc els menu.lst molt per la mà. Però no sé sap mai quan pot fer falta algo així.

Si voleu més informació del aplicatiu: QGRUBEditor web site.

Postfix: relay contra un altre mailserver

2007/02/03 No hi ha comentaris

Reading time: 2 – 2 minutes

En aquest article Set Up Postfix For Relaying Emails Through Another Mailserver de HowtoForge s’explica com configurar un Postfix per fer relaying contra un servidor extern. O sigui, perquè el servidor de correu (MTA) envii sempre els correus contra (MTA) un altre servidor de correu via SMTP. Potser el més iteressant és que explica com fer-ho a través d’un SMTP autenticat.

Intentant resumir els passos explicats a l’article comentat.

En l’exemple farem relay contra el sevidor smtp.example.com. A part d’usar l’ordre postconf per fer això, també podem editar el fitxer /etc/postfix/main.cf i afegir-hi les comandes indicades entre cometes.

postconf -e 'relayhost = smtp.example.com'
postconf -e 'smtp_sasl_auth_enable = yes'
postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
postconf -e 'smtp_sasl_security_options ='

Guardarem l’usuari i el password a usar contra el servidor smtp.example.com al fitxer /etc/postfix/sasl_passwd. Aquest fitxer ha de ser propietat de l’usuari root i ningú més hi ha de tenir accés (perms: 600). Finalment creem el seu arxiu .db.

echo "smtp.example.com   someuser:howtoforge" > /etc/postfix/sasl_passwd
chown root:root /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd

Finalment només cal reiniciar el postfix:

/etc/init.d/postfix restart

Script: entrar en un servidor protegit amb iptables

2006/11/23 No hi ha comentaris

Reading time: 3 – 4 minutes

Un fenòmen molt humà i per tant habitual, quan estem configurant un firewall amb iptables contra un servidor remot al que no tenim accés, posem per cas que esta als EUA, és el de fer-nos fora a nosaltres mateixos al executar l’script que llença les regles de filtrat. Llavors podem reiniciar la màquina a través del panell de control que ens ofereix l’ISP, o qualsevol altre procediment. El problema esta en que si aquest script s’executa només iniciar la màquina en el rc.local o qualsevol altre procés d’arrencada serà impossible que ens autentiquem per SSH després de que arrenqui el servidor.

Però… com tots els que hem vist arrencar un servidor en linux sabem, entre crida el servidor SSH i es llença l’script de les regles del firewall, pot passar 1s (~aprox) segons el ràpid que sigui el servidor. Si fossim prou ràpids autenticant-nos a la màquina podriem llençar un procés que es llencés després de l’script de les iptables i aquest script ens podria tornar a donar accés a la màquina, per exemple, netejant les regles del firewall i canviant la política per defecte.

Doncs bé, després de provar de fer-ho a mà vaig arribar a la conclusió que malgrat haver fet un curs de mecanografia quan era petit, encara era massa lent i l’enllaç es tallava abans no pogués recuperar el control de la màquina. Així doncs, vaig decidir comprovar si la màquina disposava d’un llenguatge que s’anomena expect i que es basa en TCL/TK. Aquest llenguatge com ja he comentat algún cop al blog ens permet automatitzar processos intereactius. Així doncs, vaig fer-me aquest petit script:

#!/usr/bin/expect -f
	spawn /usr/bin/ssh root@ip_del_servidor
expect "ssword: $" { send "password_de_root\n" }
expect "#" { send "echo \"sleep 30;iptables -F;iptables -P INPUT
ACCEPT;iptables -P FORWARD ACCEPT;iptables -P OUTPUT ACCEPT\" > rest.sh
\nchmod 700 rest.sh\nnohup ./rest.sh\nsleep 5\n./rest.sh" }
interact

Fixeu-vos que és molt senzill, el que fa és connectar-se per SSH amb el servidor remot, enviar el password de root; després crea un script molt senzill que es guarda a rest.sh li dona permisos d’execusió i l’executa amb un nohup perquè si la nostre consola perd la connexió amb el servidor l’script no deixi d’executar-se. El contingut d’aquest petit script que es crea és tan senzill com esperar-se 30s perquè així s’assegura que la màquina ha acabat el procés d’arrencada i després neteja les regles del firewall i posa les polítiques en ACCEPT. Així doncs, ja podem entrar sense problemes.

Doncs bé amb això un ping que vigili quan s’ha aixecat la targeta de xarxa i després executant aquest script que us he posat aquí, jo el dimarts vaig aconseguir ressussitar un servidor remot al que no tenia accés físic, només forçant reboots a través del panell de control que em van facilitar. El senzill que hagués estat tenir una consola d’administració remota i tot llest amb un segon. Però suposo que la necessitat desperta l’enginy, no?