Lecciones Prácticas

Archive for the ‘Informática – Sistemas y servidores’ Category

De cara al desarrollo de aplicaciones es muy interesante tener algún software de control de versiones, tipo Subversion o GIT.

Os comento a modo de “chuleta” cómo hacer esto desde las fuentes.

Para ello, algunas consideraciones preliminares:

Servidor y SO: Linux myserver.com 2.6.18-194.3.1.el5 #1 SMP Sun May 2 04:17:42 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Archivos de código: /soft/cds-invenio
Versión de GIT: git-1.6.6.2 (instalado desde las fuentes)

Asumo que la instalación de GIT es simple y podéis hacerla vosotros mismos sin ayuda. Hay muchísimos manuales indicando cómo hacerlo (usad google).

Una vez instalado GIT, procedemos:

# Creamos el archivo de configuracion del gitweb....
[root@aneto cds-invenio]#vi /etc/gitweb.conf
# ----------------------------------------------------------------------------
#
# gitweb.conf
#
# Configuration file for the web interface to GIT.
#
# This file is a Perl script that is executed by the gitweb interface
# after the defaults are set.  To override a setting, just uncomment
# it here and set it to the appropriate value.
#
 
# Core git executable to use.
# This can just be "git" if your webserver has a sensible PATH.
#our $GIT = "/path/to/git";
 
# Absolute fs-path which will be prepended to the project path.
# This is where your GIT repositories live in.
# ESTA VARIABLE ES FUNDAMENTAL!!!
our $projectroot = "/soft/git";
 
# Target of the home link on top of all pages.
#our $home_link = $my_uri || "/";
 
# String of the home link on top of all pages.
our $home_link_str = "view projects";
 
# Name of your site or organization to appear in page titles.
# Replace this with something more descriptive for clearer bookmarks.
#our $site_name = ""
 
# Filename of HTML text to include at top of each page.
# Must be an absolute filename (i.e., not relative to htdocs).
#our $site_header = "";
# HTML text to include at home page.
# Must be an absolute filename (i.e., not relative to htdocs).
#our $home_text = "/gitweb/indextext.html";
# Filename of HTML text to include at bottom of each page.
# Must be an absolute filename (i.e., not relative to htdocs).
#our $site_footer = "";
 
# URI of the stylesheet to use.
our $stylesheet = "/git/gitweb.css";
# URI of GIT logo (72x27 size).
our $logo = "/git/git-logo.png";
# URI of GIT favicon, assumed to be image/png type.
our $favicon = "/git/git-favicon.png";
 
# URI and label (title) of GIT logo link.
#our $logo_url = "http://git.or.cz/";
#our $logo_label = "git homepage";
 
# Source of projects list.
#our $projects_list = "";
 
# Show repository only if this file exists.
# Only effective if this variable evaluates to true.
#our $export_ok = "";
 
# Only allow viewing of repositories also shown on the overview page.
#our $strict_export = "";
 
# List of git base URLs used for URL to where fetch project from,
# i.e. full URL is "$git_base_url/$project"
#our @git_base_url_list = grep { $_ ne '' } ("/some/url");
# --------------------------------------------------------------------------------

Entonces añadimos al archivo de configuración de Apache algunas líneas útiles (el directorio /var/www/cgi-git/gitweb y /var/www/html/git deben existir):

[root@aneto cds-invenio]# vi /etc/httpd/conf/httpd.conf
# Añadir:
Alias /gitweb "/var/www/cgi-bin/gitweb/"
<Directory "/var/www/cgi-bin/gitweb">
            Options Indexes FollowSymlinks ExecCGI
            AllowOverride None
            Order allow,deny
            Allow from all
</Directory>
Alias /git "/var/www/html/git"
<Directory "/var/www/html/git">
            Options None
            AllowOverride None
            Order allow,deny
            Allow from all
</Directory>

Y procedemos a reinicar apache y crear el nuevo repositorio GIT…

[root@aneto cds-invenio]#/etc/init.d/httpd restart
 
[root@aneto cds-invenio]# cd /soft/cds-invenio
[root@aneto cds-invenio]# git init
[root@aneto cds-invenio]# git add .
[root@aneto cds-invenio]# git commit -m "inicialización del repositorio"

Una vez hecho esto, editamos algunos archivos de los que GIT ha creado (añadir información a ‘description’ y a ‘config’).

[root@aneto cds-invenio]# vi /soft/cds-invenio/description 
[root@aneto cds-invenio]# vi /soft/cds-invenio/config
--------------------------------------------------------
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        worktree = /soft/cds-invenio
        owner = "Miguel Martin"

A continuación clonamos sólo los datos de GIT en un fichero .git:

[root@aneto cds-invenio]# cd /soft/cds-invenio/
[root@aneto cds-invenio]# git clone --bare cdsinvenio cdsinvenio.git

Podemos probar a cargar en nuestro servidor esta url: http://myserver.com/cgi-bin/gitweb.cgi y ver si aparece algo… Puede que se produzcan fallos con gitweb.js si está en el directorio /cgi-bin/gitweb… si es el caso podemos editar gitweb.cgi y modificar la RUTA al gitweb.js.

# Editamos el gitweb.cgi porque hay fallos en el JS:
[root@aneto cds-invenio]# vi /var/www/cgi-bin/gitweb/gitweb.cgi
 
 # URI of stylesheets
 our @stylesheets = ("/var/www/cgi-bin/gitweb/gitweb.css");
 # URI of a single stylesheet, which can be overridden in GITWEB_CONFIG.
 our $stylesheet = undef;
 # URI of GIT logo (72x27 size)
 our $logo = "/var/www/cgi-bin/gitweb/git-logo.png";
 # URI of GIT favicon, assumed to be image/png type
 our $favicon = "/var/www/cgi-bin/gitweb/git-favicon.png";
 # URI of gitweb.js (JavaScript code for gitweb)
 our $javascript = "/git/gitweb.js";
 
 # URI and label (title) of GIT logo link
 #our $logo_url = "http://www.kernel.org/pub/software/scm/git/docs/";
 #our $logo_label = "git documentation";
 our $logo_url = "http://git-scm.com/";
 our $logo_label = "git homepage";

Y ahora copiamos el js a su lugar…

#Copiamos el Js a /var/www/html/git
cp /var/www/cgi-bin/gitweb.js /var/www/html/git/

# Hacemos un PUSH de todo…
[root@aneto teresa]# git push –all /soft/git/cdsinvenio.git

Y voilá! Nuestro repositorio git con todo accesible desde http://myserver.com/cgi-bin/gitweb.git

Algunos enlaces interesantes…
link 1 (en)
link 2 (en)
link 3 (es)
link 4 (es)

In Windows 2008 Active Directory Users and Computers Microsoft activated new feature “Protect Container from accidential deletion”
During OU (organizational unit) creation you have the ability to mark OU as protected from accidental deletion , and if you try to delete OU you will receive the following error “You do not have sufficient privileges to delete “OU Name” , or this object is protected from accidential deletion”

To unlock OU from accidential deleting protection do the following actions
* Open Active Directory Users and Computers
* Go to View
* Mark with “V” ” Advanced Features”
* Right click protected OU
* Go to Properties
* Navigate to “Object” Tab
* Remove the “V” from “Protect object from accidental deletion “

You could also achieve this by not protecting the OU’s in the moment of creation.

Via: kreslavsky.com

Imagine your server crashes (due to some hardisk I/O error, for instance). Then if you reboot your machine, it’ll spit out something like:

Checking filesystems...
   e2fsck: Cannot continue, aborting
   Type root password for maintenance mode or CTRL+D to continue

Lets suppose the culprit of this is some HDD (for instance, /dev/mapper/Vt31-p1 which should be mounted in /software).

Then if you read the contents of /etc/fstab you will see one line like:

/dev/mapper/Vt31-p1    /t31                    ext3    defaults        1 2

If you try to comment this line, your editor will complain and tell "changes cannot be written" or something like that. Why is this? Well, your /etc files have been mounted on a non writable partition (maintenance mode, you remember?). So you will have to remount this partition in RW mode. Just like this:

mount -o remount,rw /

Then edit fstab, save your changes and reboot.

¿Qué es BackupPC?

El otro día tuve la ocasión de ver en funcionamiento una herramienta estupenda para gestionar copias de seguridad mediante un interfaz web (o por via de comandos). Se llama BackupPC y es libre.

Las opciones de personalización son infinitas, no sólo a nivel de compresión de los backups, sino también la posibilidad de gestionar de forma cómoda los privilegios de acceso, quién puede hacer cada backup, cómo se hace cada backup (rsync sobre ssh, samba…).

Vaya, que me encantó. Paso, por tanto, a comentaros cómo instalar y configurar esta herramienta. He de decir que esta guía la he hecho “para mi” -por si tengo que replicar esta instalación en otras máquinas- por lo que es incompleta, imperfecta y seguro que tiene errores o cosas que se pueden mejorar.

** Nota tras terminar la instalación: habría sido más conveniente instalar la herramienta como usuario apache directamente… pero si seguís las instrucciones que doy, también funcionará asi.

Configurando BackupPC en Red Hat EL 5 – descargando source, instalando pre-requisitos y creando directorios

Asumo que tendréis instalado perl, apache, etc.

En mi caso, lo hago sobre perl 5.8.8 para 64bits.

[root@olmo BackupPC]# perl --version
 
This is perl, v5.8.8 built for x86_64-linux-thread-multi
 
Copyright 1987-2006, Larry Wall
 
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
 
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

Primero descargamos el tar.gz con el instalador. Lo podemos hacer desde:
http://sourceforge.net/projects/backuppc/files/backuppc/3.1.0/BackupPC-3.1.0.tar.gz/download.

[root@olmo BackupPC-3.1.0]# yum install perl-suidperl
[root@olmo BackupPC-3.1.0]# /usr/sbin/adduser backuppc
[root@olmo www]# mkdir /var/www/cgi-bin/BackupPC
[root@olmo cgi-bin]# mkdir /var/www/icons/BackupPC
[root@olmo backuppc-install]# cd /home/miguel/backuppc-install
[root@olmo backuppc-install]# tar zvxf BackupPC-3.1.0.tar.gz

El proceso de instalación (todo el output)

[root@olmo BackupPC-3.1.0]# perl configure.pl
 
Is this a new installation or upgrade for BackupPC?  If this is
an upgrade please tell me the full path of the existing BackupPC
configuration file (eg: /etc/BackupPC/config.pl).  Otherwise, just
hit return.
 
--> Full path to existing main config.pl []?
 
I found the following locations for these programs:
 
    bzip2        => /usr/bin/bzip2
    cat          => /bin/cat
    df           => /bin/df
    gtar/tar     => /bin/gtar
    gzip         => /bin/gzip
    hostname     => /bin/hostname
    nmblookup    => /usr/bin/nmblookup
    par2         =>
    perl         => /usr/bin/perl
    ping         => /bin/ping
    rsync        => /usr/bin/rsync
    sendmail     => /usr/sbin/sendmail
    smbclient    => /usr/bin/smbclient
    split        => /usr/bin/split
    ssh/ssh2     => /usr/bin/ssh
 
--> Are these paths correct? [y]?
 
Please tell me the hostname of the machine that BackupPC will run on.
 
--> BackupPC will run on host [olmo.unizar.es]?
 
BackupPC should run as a dedicated user with limited privileges.  You
need to create a user.  This user will need read/write permission on
the main data directory and read/execute permission on the install
directory (these directories will be setup shortly).
 
The primary group for this user should also be chosen carefully.
The data directories and files will have group read permission,
so group members can access backup files.
 
--> BackupPC should run as user [backuppc]?
 
Please specify an install directory for BackupPC.  This is where the
BackupPC scripts, library and documentation will be installed.
 
--> Install directory (full path) [/usr/local/BackupPC]?
 
Please specify a data directory for BackupPC.  This is where all the
PC backup data is stored.  This file system needs to be big enough to
accommodate all the PCs you expect to backup (eg: at least several GB
per machine).
 
--> Data directory (full path) [/data/BackupPC]? /img/BackupPC
 
BackupPC can compress pool files, providing around a 40% reduction in pool
size (your mileage may vary). Specify the compression level (0 turns
off compression, and 1 to 9 represent good/fastest to best/slowest).
The recommended values are 0 (off) or 3 (reasonable compression and speed).
Increasing the compression level to 5 will use around 20% more cpu time
and give perhaps 2-3% more compression.
 
--> Compression level [3]?
 
BackupPC has a powerful CGI perl interface that runs under Apache.
A single executable needs to be installed in a cgi-bin directory.
This executable needs to run as set-uid backuppc, or
it can be run under mod_perl with Apache running as user backuppc.
 
Leave this path empty if you don't want to install the CGI interface.
 
--> CGI bin directory (full path) []? /var/www/cgi-bin/BackupPC
 
BackupPC's CGI script needs to display various GIF images that
should be stored where Apache can serve them.  They should be
placed somewhere under Apache's DocumentRoot.  BackupPC also
needs to know the URL to access these images.  Example:
 
    Apache image directory:  /usr/local/apache/htdocs/BackupPC
    URL for image directory: /BackupPC
 
The URL for the image directory should start with a slash.
 
--> Apache image directory (full path) []? /var/www/icons/BackupPC
--> URL for image directory (omit http://host; starts with '/') []? /icons/BackupPC
 
Ok, we're about to:
 
  - install the binaries, lib and docs in /usr/local/BackupPC,
  - create the data directory /img/BackupPC,
  - create/update the config.pl file /etc/BackupPC/config.pl,
  - optionally install the cgi-bin interface.
 
--> Do you want to continue? [y]?
Created /usr/local/BackupPC/bin
Created /usr/local/BackupPC/doc
Created /usr/local/BackupPC/lib/BackupPC/CGI
Created /usr/local/BackupPC/lib/BackupPC/Config
Created /usr/local/BackupPC/lib/BackupPC/Lang
Created /usr/local/BackupPC/lib/BackupPC/Storage
Created /usr/local/BackupPC/lib/BackupPC/Xfer
Created /usr/local/BackupPC/lib/BackupPC/Zip
Created /img/BackupPC
Created /img/BackupPC/pool
Created /img/BackupPC/cpool
Created /img/BackupPC/pc
Created /img/BackupPC/trash
Created /etc/BackupPC
Created /var/log/BackupPC
Installing binaries in /usr/local/BackupPC/bin
Installing library in /usr/local/BackupPC/lib
Installing images in /var/www/icons/BackupPC
Making init.d scripts
Installing docs in /usr/local/BackupPC/doc
Installing config.pl and hosts in /etc/BackupPC
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.140 ms
 
--- localhost.localdomain ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.140/0.140/0.140/0.000 ms
Installing cgi script BackupPC_Admin in /var/www/cgi-bin/BackupPC
 
Ok, it looks like we are finished.  There are several more things you
will need to do:
 
  - Browse through the config file, /etc/BackupPC/config.pl,
    and make sure all the settings are correct.  In particular,
    you will need to set $Conf{CgiAdminUsers} so you have
    administration privileges in the CGI interface.
 
  - Edit the list of hosts to backup in /etc/BackupPC/hosts.
 
  - Read the documentation in /usr/local/BackupPC/doc/BackupPC.html.
    Please pay special attention to the security section.
 
  - Verify that the CGI script BackupPC_Admin runs correctly.  You might
    need to change the permissions or group ownership of BackupPC_Admin.
    If this is an upgrade and you are using mod_perl, you will need
    to restart Apache.  Otherwise it will have stale code.
 
  - BackupPC should be ready to start.  Don't forget to run it
    as user backuppc!  The installation also contains an
    init.d/backuppc script that can be copied to /etc/init.d
    so that BackupPC can auto-start on boot.  This will also enable
    administrative users to start the server from the CGI interface.
    See init.d/README.
 
Enjoy!

Los pasos post-instalación

*Comprobar en /etc/httpd/modules/ que tenemos mod_perl.so

* Ahora en la configuracion del apache vemos que esté cargado el mod_perl

[root@olmo cgi-bin]# more /etc/httpd/conf/httpd.conf | grep mod_perl
LoadModule perl_module modules/mod_perl.so

* Añadir la configuración necesaria de apache…

Alias /bpc/ "/var/www/cgi-bin/BackupPC/"
        <Directory "/var/www/cgi-bin/BackupPC/">
            Options All
 
            SetHandler perl-script
            PerlResponseHandler ModPerl::Registry
            PerlOptions +ParseHeaders
            Options +ExecCGI
 
            AddHandler perl-script .pl
            AddType application/x-perl-httpd .pl
            PerlHandler ModPerl::Registry
            PerlSendHeader On
        </Directory>

Si seguimos estos pasos lo normal es que al invocar la url del backuppc nos salgan errores:

Error: Unable to read config.pl or language strings!!
 
Note: $ENV{REMOTE_USER} is not set, which could mean there is an installation problem. BackupPC_Admin expects Apache to authenticate the user and pass their user name into this script as the REMOTE_USER environment variable. See the documentation.

Esto pasa por los permisos del /etc/BackupPC/... porque el usuario apache no es capaz ni de leer ni de ejecutar el /etc/BackupPC/config.pl

Por tanto vamos a cambiar estos permisos…

[root@olmo cgi-bin]# chmod o+rx /etc/BackupPC/
[root@olmo cgi-bin]# chmod o+rx /etc/BackupPC/config.pl

Ahora la web ya carga, aunque pone:

"Error: Wrong user: my userid is 48, instead of 502(backuppc) 
This script needs to run as the user specified in $Conf{BackupPCUser}, which is set to backuppc.
 
This is an installation problem. If you are using mod_perl then it appears that Apache is not running as user backuppc. If you are not using mod_perl, then most like setuid is not working properly on BackupPC_Admin. Check the permissions on /var/www/cgi-bin/BackupPC/BackupPC_Admin and look at the documentation. "

Vamos al config.pl y cambiamos la $Conf{BackupPCUser} al usuario apache.

F5 en la web y da este error…

[root@olmo cgi-bin]# 2010-03-23 12:33:32 Can't create a test hardlink between a file in /img/BackupPC/pc and /img/BackupPC/cpool.  Either these are different file systems, or this file system doesn't support hardlinks, or these directories don't exist, or there is a permissions problem, or the file system is out of inodes or full.  Use df, df -i, and ls -ld to check each of these possibilities. Quitting...
 
[1]+  Exit 1                  sudo -u apache /usr/bin/perl /usr/local/BackupPC/bin/BackupPC -d

Esto pasaba porque estaban a cargo de backuppc y los cambiamos a apache:

[root@olmo cgi-bin]# ll /img
total 44
drwxr-x---  6 backuppc backuppc  4096 Mar 23 12:05 BackupPC
 
[root@olmo cgi-bin]# chown -R apache:apache /img/BackupPC/

Ahora ya nos quita la segunda parte del error, pero no tenemos configurado el fichero host… Lo configuramos con nuestros hostnames, si estos tienen IP estática o dinámica (0 ó 1) y los user “encargados” de cada host. ¡Ojo al editar este fichero si lo hacemos como root, que se macharán los permisos!

vi /etc/BackupPC/hosts

Para que arranque con cada boot de la máquina sigue las instrucciones:

RedHat Linux:
============
 
When configure.pl is run, the script linux-backuppc is created. It
should be copied to /etc/init.d/backuppc:
 
    cp /home/miguel/backuppc-install/BackupPC-3.1.0/init.d/linux-backuppc /etc/init.d/backuppc
 
After copying it, you can test it by running these commands as root:
 
    /etc/init.d/backuppc start
    /etc/init.d/backuppc status
    /etc/init.d/backuppc stop
 
You should then run the following commands as root:
 
    chkconfig --add backuppc
    chkconfig --level 345 backuppc on
    chkconfig --list backuppc
 
This will auto-start backuppc at run levels 3, 4 and 5.

¡Notar que en el fichero /etc/init.d/backuppc hay que cambiar el usuario backuppc por apache para que funcione todo!

Luego hemos cambiado en el config.pl dónde loggea (lo hemos pasado al /usr/local/BackupPC/log) y lo hemos creado con apache:apache.

Ahora arrancamos el asunto:

/etc/init.d/backuppc start

Sale más o menos, pero vemos en el log que hay problemas…

Backup failed on olmo.unizar.es (File::RsyncP module doesn't exist)

Vamos a instalar ese módulo de perl con CPAN:
Como root ejecutar:

cpan
cpan> install File::RsyncP

Luego restart apache y backuppc:

/etc/init.d/httpd restart
/etc/init.d/backuppc restart

Pasos opcionales post-instalación

Un plus: se puede colocar el LDAP para validar el acceso por web. Además se permite configurar en el config.pl qué usuarios acceden a administrar cada servidor.

Editamos estas variables en el fichero config.pl (si ponemos * lo dejamos a todos los usuarios, sino solo a user1, user2, p ejemplo):

$Conf{CgiAdminUserGroup} = '';
$Conf{CgiAdminUsers}     = 'user1, user2';

Además en la config del apache habrá que meter las siguientes líneas dentro del directory:

              # autenticar contra el LDAP
               AuthType Basic
               AuthBasicProvider ldap
               AuthName "Autenticacion OpenLDAP "
               AuthzLDAPAuthoritative off
               AuthLDAPURL "ldap://ldapmail.unizar.es/ou=Accounts,dc=unizar,dc=es?uid?sub?(objectClass=person)"
               Require valid-user

Y restartar todo, como siempre

Ajustar SSH para rsync root

Se puede consultar http://backuppc.sourceforge.net/faq/ssh.html

Más documentación (oficial) por si esto te supera

http://backuppc.sourceforge.net/faq/debugCGI.html#i_get_the_error_error__unable_to_read_config_pl_or_language_strings____how_do_i_fix_this

http://backuppc.sourceforge.net/faq/BackupPC.html

http://backuppc.sourceforge.net/faq/ssh.html

If your web server uses PHP and you need to use IMAP take a look at this post.

When do i need to install IMAP support for PHP

If you want to use imap_open function you need to do it.

How do I check if my PHP is actually configured to use IMAP?

Two ways:
- Check the output of phpinfo(); info. More precisely, the additional .ini files parsed part. There should be something like /etc/php.d/imap.ini if you already have imap in your php.

- Make a doihaveimap.php like the following and run it:

<?php
if(!function_exists('imap_open'))
    echo "I DO have it installed";
else
    echo "I do NOT";
?>

I need to install it: how do I proceed?

My system is a
Linux 2.6.18-164.11.1.el5 #1 SMP Wed Jan 6 13:26:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux.

So I proceed with the installation using yum.

yum install libc-client.x86_64
yum install libc-client-devel.x86_64
yum install php-imap.x86_64
/etc/init.d/httpd restart

Does it work? How to check it

Write a simple php program like the following and run it.

Been there, done that… it does not work!

Most of us get this error:

Array ( [0] => [CLOSED] IMAP connection broken (server response) )

You should make a

telnet yourimapserver 143

If it does not connect, there you have the problem. Fix it before continue reading. If you are kind of desperate, read this post.

Well, lets suppose it connects but the “Invalid credentials” error message pops. Common mistakes are typos when defining username/password. Also check if the username must contain “@yourdomain.com”. Again, telnet is your friend. If it does not work in telnet it won’t work in php either…

Would you like to read more about PHP-IMAP? Check this link.

Do you need to install php-imap in another platform? Check this FTP

osTicket is a widely-used open source support ticket system. It seamlessly integrates inquiries created via email, phone and web-based forms into a simple easy-to-use multi-user web interface. Manage, organize and archive all your support requests and responses in one place while providing your customers with accountability and responsiveness they deserve.

osTicket is configured by default like the following: the client (user) fills in a form with information related to the issue he is having and then submits it. osTicket processes that info and shows it to the staff team so that the support can be given.

In our institution people are used to tell about their tech issues using email (suppose this email is support@yourinstitution.com) and we did not want to change this. So we thought there might be a trick to forward all the support@yourinstitution.com mails to osticket. And there is indeed!

There are two ways of achieving this:

1. Use pipes to forward the mails to osTicket system (original post talking about this and another post talking about this).

2. Configure osTicket to use POP/IMAP (check this post)

I have tried both options. The steps you should follow are:

OSTicket with pipes

Enable Email Piping:
Admin Panel -> Preferences -> Email Settings -> Enable Email Piping

chmod the file pipe.php in the api folder:

# cd /var/www/html/osticket/buz/api/
# chmod 764 pipe.php

Edit your aliases file

# vi /etc/aliases

and add the pipe line (supportusername is the name of the user to which the email will be forwarded):

supportusername: "|/usr/bin/php -q /var/www/html/osticket/buz/api/pipe.php"

Regenerate aliases file

# newaliases

Find php:

# whereis php
php: /usr/bin/php

Configure your email program (mine is sendmail). Spanish readers can refer to this sendmail guide

Enable your supportusername to run php:

#chmod 764 /usr/bin/php

Send an email to check it works:

# mail -s "Checking osticket piping" supportusername
This is a test
.
CC:

If something does not work as expected check the logs (tail -f -n 100 /var/log/maillog)

When everything is working as expected…
Forward your support@yourinstitution.com email to the server hosting osticket.

** Edit: I have noticed several problems with this configuration. When the emails are piped to osticket the headers are rewriten so the support staff does not know the client’s email!!

So I decided to try the IMAP configuration.

The IMAP/POP configuration

First of all, configure php-imap.

Then go to Settings -> Email Settings and:
For Incoming Emails:
* disable Enable email piping (You pipe we accept policy)
* enable Enable POP/IMAP email fetch (Global setting which can be disabled at email level)
For Outgoing Emails my config is like:
* Use PHP mail function

Now go to Email tab.
Create a new email account. Mine is configured as shown in the image:

I just noticed my apache.err file was throwing tons of errors like the following:

[error] [client 67.195.37.164] File does not exist: /soft/cds-invenio/var/www/incunables

I did not know which was causing this error because everything seemed to be working fine. I searched the FAQ, read the Documentation, even tried to search both my website (which generated errors) and tried a google search or two to see if I could find anything related to this issue. No such luck.

I went through /etc/httpd/conf/httpd.conf and other config files but I could not find where there was any reference to /incunables. Weird. Then I figured it out:

My VirtualHosts (invenio-apache-vhost.conf) were defined like:

1
2
3
4
5
6
7
8
9
10
11
12

AddDefaultCharset UTF-8
ServerSignature Off
ServerTokens Prod
NameVirtualHost *:80
<Files *.pyc>
   deny from all
</Files>
<Files *~>
   deny from all
</Files>
<VirtualHost *:80>
# blablabla... a lot of not-related stuff here

By now you should have guessed the error had to be with lines 4 and 11. That *:80 was responsible for the errors. Now I changed those lines to:

NameVirtualHost 155.210.5.35:80
# blablabla
<VirtualHost 155.210.5.35:80>
#blablabla

Then just restart your apache server:

/etc/init.d/httpd restart

And, at last, got rid of those errors

*** TIP for CDS Invenio users:
You should also change these values in /lib/python/invenio/inveniocfg.py
And then run:

inveniocfg --update-all; /etc/init.d/httpd restart

My previous post talked about an attack we had suffered in one of our servers.

This attack is based in the remote execution of code (it affects old versions of phpMyAdmin).

For a full documentation about the exploit, please read this article.

Once you’ve noticed your server has been attacked you should follow these steps in order to stop the hacker and prevent future damages.

General tips:

• Calm down. Relax. Proceed.
• Unplug the ethernet cable. This is VERY important and must be done ASAP.
• Make a copy of your full filesystem to another hard drive and keep a virgin copy of the attacked disk.
• Inform the authorities.
• Do NOT trust the modification dates of files. They can be altered.
• Unistall or update the program with the bug (in our case, phpMyAdmin).
• Begin the audit:
  • Inspection of /etc/passwd, /etc/group and /etc/gshadow. Look for recently created / suspicious accounts.
  • Change the passwords for root and other privileged users.
  • Take a look at the /etc/sudoers file. Look for modifications in privileges.
  • Take a close look at iptables (usually under

    /etc/sysconfig/iptables

    ). Make sure there are no new open ports (specially ports from 19 to 25). Make sure you absolutely need the ports defined there to be open.

  • Open your system logs and apache logs and read them (if you still have them…). In our case the hacker had changed the /sbin/syslogd program for another one so that no new logs were generated, and he had deleted every system log. He had done the same with /sbin/ifconfig (still wondering why). The corrupted syslogd and ifconfig were protected with special attributes. For being able to delete them I had to change this special attributes with

    lsattr -suiAdc

    .
    Refer to lsattr help for further information.

  • Look at the processes that are being executed:

    ps -ef

    . Search processes with a lot of threads. Kill them, if you can. If you can’t, just rename the executable file or change its location in your hard drive. Look for keyloggers.

  • Verify that /etc/hosts.allow is not corrupted or changed.
  • Check your mail daemon (sendmail in my server) and its logs. It is possible that your machine is being used to send spam. Our server was trying to send messages to cavelos@hotmail.com, gogosharz@gmail.com and other mail accounts. These mails contained server information (kernel versions, installed programs, paths, java versions, disk usage, etc).
  • Check the integrity of your apache server. Make sure it is your server and not another one installed by the hacker.
  • Reboot the machine and take a look at the boot logs. Look for

    [FAILED]

    messages and write them down.

  • Take another look at the output of

    ps -ef

    . If new suspicious processes are present, go back and check everything again.

  • Re-plug the ethernet cable. Call ifconfig and check everything is as it should.
  • Search for suspicious connections using

    netstat -an

    . You should pay attention to connections in ports 19, 20, 21, 22, 23, 25 and 80. There might be also weird connections to mysql default port (3306) and/or oracle.
  • If you are connecting to the server via ssh make sure your connection is being monitorized (type netstat -an and your IP should be in the output. If it is not, uninstall your ssh server and reinstall it because it has been corrupted. Perform similar actions with FTP /SFTP servers you might have.
  • Update, if available, your kernel to the last one. Update apache, mysql, oracle and other programs you might be using.

  Final tips

  • Keep yourself posted in security issues. Visit milw0rm every day or two.
  • Update your kernel and programs as soon as they have new stable versions
  • Check and re-check your firewall.

Los routers de telefónica vienen preparados, por defecto, para trabajar con sistema de seguridad WEP. Las deficiencias de este sistema son ampliamente conocidas (googlea wifislax y auditoría wireless). Por eso hoy voy a explicar cómo securizar nuestra conexión wireless.

El router que me ha proporcionado Telefónica es el XAVI 7868r

Cambiando WEP por WPA
WPA realemente no es un sistema de encriptación, sino de autentificación de usuarios en la red. Con este sistema el usuario debe identificarse para conectarse, y además las comunicaciones están encriptadas. Utilizaremos el sistema WPA-PSK y encriptación TKIP. Es mejor la AES, pero este router no la soporta. Volvemos a la configuración de la red inalámbrica.

- Entra a la configuración del router (abre el navegador y ve a 192.168.1.1). Si no has cambiado los datos por defecto, accederás con: usuario=1234/password=
- Entra a Configuration - Ports - Wireless y cambiamos los siguientes parámetros:

Web Encryption - disable
WPA - true
WPA Enable PSK - true
WPA Enable EAP - false

Obtendrás algo asi:

- Ahora ve a Configuration - WPA y escribe la passphrase (la contraseña) que desees (Son buenas las contraseñas “largas” que contienen caracteres alfanuméricos y símbolos)

- Por último accede a Configuration - 802.1x y marca Auth Control Enabled - true

Ahora guarda los cambios (Configuration - Save config) y usa tu cliente para conectarte a la nueva red. ¿Por qué recalco que uses tu cliente? Windows XP viene con su propia utilidad de configuración de redes inalámbricas. Esta utilidad tiene un fallo desde el SP1, ampliamente documentado, que se produce cuando se utiliza WPA-PSK y encriptación TKIP, y que Microsoft a día de hoy no se ha molestado en solucionar. El fallo consiste en que la red conecta y desconecta continuamente. La solución es no usar la utilidad de Windows e instalar la que traen los dispositivos inalámbricos en el cd de drivers. Solamente hay que desmarcar la casilla “Usar Windows para establecer ni configuración de red inalámbrica”, instalar la utilidad del cd y utilizarla para la configuración.

En mi caso utilizo Intel Set Pro Wireless y la configuración queda tal que así:

Seguridad empresarial
Autenticación de redes - WPA2Personal
Codificación de datos - AES/CCMP


Debería quedaros asi:

Filtrar las MAC
Una medida añadida de seguridad pasa por el filtrado de las MAC. El filtrado MAC es un mecanismo de seguridad, que se utiliza para configurar qué tarjetas de red pueden conectarse a nuestro router y cuáles no. Para ello utiliza la dirección MAC de la tarjeta (un número que la identifica y que -en teoría, ya que existen programas con los que se puede falsear este dato- es único en el mundo). El MAC viene en una etiqueta en los dispositivos, pero si no aparece, con el dispositivo inalámbrico conectado, vamos a Inicio – Ejecutar – cmd y escribimos ipconfig /ally nos aparecerán las MAC de todas las tarjetas de red que tengamos instaladas.

Una vez conocidas las MAC de los equipos que deseamos que accedan, únicamente falta añadirlas en el menú de configuración del router. Pongamos que la MAC a añadir es 00-1C-BF-51-C2-17. Entonces vamos al menú de Mac Filtering y añadimos nuestra MAC (sin guiones) y pulsamos Apply.

Espero que os haya resultado útil

En caso de que OphCrack LiveCD para Windows Vista no haya sido capaz de obtener las contraseñas del sistema se puede utilizar Offline NT Password Recovery and Registry Editor para recuperar la contraseña del Administrador u otros usuarios (es válido para Windows XP y Vista).

Solamente se necesita grabar la imagen que bajarás en un CD-R/RW para lograr un disco capaz de arrancar desde el Inicio una vez encendido el PC.

Desde luego se necesita tener activada en la BIOS la opción de arranque desde CD-ROM en primer lugar.

Y desde allí podréis activar cuentas inactivas, resetear las contraseñas de las cuentas deseadas, etc…

Esta imagen muestra el arranque de la utilidad:

Y aquí una vez arrancada, veréis algo como esto: