kernel – Cayu

PROXMOX VE – Virtualizacion empresarial con Software Libre

proxmox_main

PROXMOX Virtual Environment es una solución de virtualización de servidores basada en Debian GNU/Linux. Permite la virtualización tanto sobre KVM como contenedores OpenVZ, gestiona máquinas virtuales, almacenamiento, redes virtualizadas y clústeres HA.

Basicamente es una distribución Linux que viene sólo con los servicios mínimos para de esta forma obtener un mejor rendimiento. Cuenta además con una interfaz gráfica muy sencilla vía Web para realizar todas las operaciones y como extra una API via REST.

Al utilizar OpenVZ se puede cambiar tanto la asignación de memoria RAM como la asignación de espacio en disco en caliente.

Además contamos con un listado de plantillas para generar maquinas virtuales tanto para Contenedores como para KVM.

Para instalarlo se nos presenta una interfaz gráfica la cual realiza pocas preguntas y en menos de 10 minutos lo tenemos instalado.

Apenas lo instalamos debemos ingresar por https a la ip en cuestión puerto 8006

Proxmox_virtualizar_sistemas_operativos_foto_1_th

Proxmox_virtualizar_sistemas_operativos_foto_2Este post lo habia dejado en borrador un monton de tiempo, nunca tuve tiempo de terminarlo, pero la version nueva de Proxmox esta muy buena, es muy simple, con una PC no muy nueva que tenga una buena cantidad de memoria RAM, discos rápidos (lo probe con discos de 15K) se puede hacer de todo y muy fácil, nos armamos nuestrar propias plantillas de Debian o lo que usemos y va como piña !

Seguime :

Vuelve Kernel.org (parcialmente)

Después del grave problema de seguridad vuelve Kernel.org, aunque con cosas parciales, estuve bajando el código del Kernel últimamente de github, pero no es muy cómodo que digamos

aca un mail de recomendación para los desarrolladores del núcleo de la lista de correo de LKML (es bueno también como recomendación para tener en cuenta para todos los días en la computadora de casa)

The compromise of kernel.org and related machines has made it clear that
some developers, at least, have had their systems penetrated.  As we
seek to secure our infrastructure, it is imperative that nobody falls
victim to the belief that it cannot happen to them.  We all need to
check our systems for intrusions.  Here are some helpful hints as
proposed by a number of developers on how to check to see if your Linux
machine might be infected with something:


0. One way to be sure that your system is not compromised is to simply
   do a clean install; we can all benefit from a new start sometimes.
   Before reinstalling any systems, though, consider following the steps
   below to learn if your system has been hit or not.

1. Install the chkrootkit package from your distro repository and see if it
   reports anything.  If your distro doesn't have the chkroot package,
   download it from:
	http://www.chkrootkit.org/

   Another tool is the ossec-rootcheck tool which can be found at:
	http://www.ossec.net/main/rootcheck

   And another one is the rkhunter program:
   	http://www.rootkit.nl/projects/rootkit_hunter.html
   [Note, this tool has the tendancy to give false-positives on some
   Debian boxes, please read /usr/share/doc/rkhunter/README.Debian.gz if
   you run this on a Debian machine]

2. Verify that your package signatures match what your package manager thinks
   they are.

   To do this on a rpm-based system, run the following command:
   	rpm --verify --all
   Please read the rpm man page for information on how to interpret the
   output of this command.

   To do this on a Debian based system, run the following bash snippet:
	dpkg -l \*|while read s n rest; do if [ "$s" == "ii" ]; then echo $n;
	fi; done > ~/tmp.txt
	for f in `cat ~/tmp.txt`; do debsums -s -a $f; done
   If you have a source-based system (Gentoo, LFS, etc.) you presumably
   know what you are doing already.

3. Verify that your packages are really signed with the distro's keys.

   Here's a bash snippet that can do this on a rpm based system to
   verify that the packages are signed with any key, not necessarily
   your distro's key.  That exercise is left for the reader:

	for package in `rpm -qa`; do
		sig=`rpm -q --qf '%{SIGPGP:pgpsig}\n' $package`
		if [ -z "$sig" ] ; then
			# check if there is a GPG key, not a PGP one
			sig=`rpm -q --qf '%{SIGGPG:pgpsig}\n' $package`
			if [ -z "$sig" ] ; then
				echo "$package does not have a signature!!!"
			fi
		fi
	done
   Unfortunately there is no known way of verifying this on Debian-based
   systems.

4. To replace a package that you find suspect, uninstall it and install
   it anew from your distro.  For example, if you want to reinstall the
   ssh daemon, you would do:
	$ /etc/init.d/sshd stop
	rpm -e openssh
	zypper install openssh	# for openSUSE based systems
	yum install openssh	# for Fedora based systems

   Ideally do this from a live cdrom boot, using the 'rpm --root' option
   to point rpm at the correct location.


5. From a liveCD environment, look for traces such as:
   a. Rogue startup scripts in /etc/rc*.d and equivalent directories.
   b. Strange directories in /usr/share that do not belong to a package.
      This can be checked on an rpm system with the following bash snippet:
	for file in `find /usr/share/`; do
		package=`rpm -qf -- ${file} | grep "is not owned"`
		if [ -n "$package" ] ; then
			echo "weird file ${file}, please check this out"
		fi
	done
6. Look for mysterious log messages, such as:
   a. Unexpected logins in wtmp and /var/log/secure*, quite possibly
      from legitimate users from unexpected hosts.
   b. Any program trying to touch /dev/mem.
   c. References to strange (non-text) ssh version strings in
      /var/log/secure*.  These do not necessarily indicate *successful*
      breakins, but they indicate *attempted* breakins which means your
      system or IP address has been targeted.

7. If any of the above steps show possible signs of compromise, you
   should investigate further and identify the actual cause.  If it
   becomes clear that the system has indeed been compromised, you should
   certainly reinstall the system from the beginning, and change your
   credentials on all machines that this machine would have had access
   to, or which you connected to through this machine.  You will need
   to check your other systems carefully, and you should almost
   certainly notify the administrators of other systems to which you
   have access.

Finally, please note that these hints are not guaranteed to turn up
signs of a compromised systems.  There are a lot of attackers out there;
some of them are rather more sophisticated than others.  You should
always be on the alert for any sort of unexpected behavior from the
systems you work with.


thanks,
Seguime :

Webcam Virtual para amsn

Bueno resulta que quiero mostrarle a alguien un video por medio de amsn
por que subirlo a youtube etc etc tarda mucho y bueno pense se podra
usar una webcam virtual o algo por el estilo ? y bueno como buen usuario
empeze a googlear y encontre varias cosas en diferentes lugares y en el
foro de amsn

el que probe fue ( http://allonlinux.free.fr/Projets/AVLD/ ) AVLD

cargo un modulo y con el mplayer redirijo la salida de video y en el
amsn lo toma como webcam 🙂

una vez compilado el modulo lo cargo de la siguiente manera en mi ubuntu
gutsy :p jaj tire chivo

modprobe avld width=640 height=480 fps=25

los parametros son los mismos que los del video a reproducir, mas que
nada la resolucion, los fps mucho no importan

y si quiero cambiar la resolucion

echo “width=800 height=600 fps=25? > /dev/video0

y para reproducir

mencoder video.avi -nosound -ovc raw -vf format=bgr24 -of rawvideo -o /dev/video0

y listop

otras cosas interesantes de como usar cam virtual para por ejemplo
aplicarle efectos con effectv, aca

http://spike23.blogspot.com/2008/01/amsn-effectv-nueva-lap-acer-9410z.html

una explicacion con la misma logica, usa otro modulo de kernel pero
puede utilizarse la misma tecnica con el modulo que use yo.

Saludos 🙂

Seguime :
Facebook