¿Que tan seguro es hacer esto? nada que el usuario pueda ingresar es
ejecutado, sólo creo un archivo y lo borro.
¿O existe otra manera más conveniente? ya que si cae apache no habría manera
de acceder al servicio remoto tampoco...
--
Gustavo Guillermo Pérez
Compunauta uLinux
www.compunauta.com
No lo digo en mal plan ! si suena agresivo no fue mi intención.
Saludos
Max
--
<?php
$signautre = null;
echo $signature;
Entonces, no es php,apache para ssh, sino que era cerrar un servicio más,
estaba pensando también cambiar de puerto el servicio a algo nada común.
Saludos.
No es tan complicado lo de una vpn, no te asustes, pero usar SSH y una
buena política de claves es más que suficiente para casí cualquier
caso.
> Adicionalmente, podrías configurar portsentry, para detectar barrido
> de puertos en tu server, denegando el acceso a aquellos curiosos que
> lo hagan.
Buena idea, e incluso un brute-force detector, no? y que solo se
autentifique con llave, no con password.
--
----------------------------------------------------------------------------------------------------
¿Cuando fue la última vez que hiciste algo por primera vez?
----------------------------------------------------------------------------------------------------
Fernando Barajas Díaz-Lozano ICQ: 7237681
fbar...@nuestroweb.com MSN: fbar...@sistec.com.mx
www.nuestroweb.com Y!: barajasfernando
Cel: (044-55) 1474-1866 JABBER: fbar...@jabber.org
Skype: barajasfernando
Teléfono (DF): (01-55) 5905-5229
Un ataque por fuerza bruta solo va a ser exitoso si el servidor tiene
políticas terribles para las claves y además está mal configurado.
Si realmente necesitas muchas seguridad, teniendo apache y php en el
servidor le estás dando al traste a cualquier política estricta.
Es mucho más probable que entren al servidor a través de una
aplicación web, o por una vulnerabilidad de php o apache, a que entren
a través del SSH, ahí es donde entiendo porque es muy importante que
Sandino de su platica de "tu peor enemigo", la seguridad es tan fuerte
como tu punto más debil, eso es algo que no deben olvidar.
Pero si es algo que no requiere mucha seguridad y la solución va a ser
para simples mortales (entiendase usuarios comunes) es más fácil para
ellos usar una aplicación web que aprender a usar ssh
Y más aún, siendo usuarios comunes y corrientes, si les sueltas un
usuario ssh aun con los privilegios al mínimo siempre tendrás el riesgo
de que revelen contraseñas o información que comprometa tu server.
En mi caso me pidieron una aplicación que buscara algunos archivos y los
enviara por FTP. Al principio hice un script en bash y para activarlo
una cuenta accesada por ssh para que los usuarios lo corrieran por sí
mismos cuando fuera necesario.
Ahora mismo pienso en esos aspectos de seguridad y mejor pienso hacer un
script en PHP accesible solo para redinterna con un login separado del
sistema (ya se que ssh puede usar otro sistema de login también) y que
active el script con un simple click.
Sin necesidad de instalar clientes ssh ni estar capacitando.
A final de cuentas todos los sistemas cuentan con un componente
extremadamente ineficiente y peligroso llamadoi usuario. Entre menor sea
la intervención y dependencia de este componente las cosas funcionarán
mejor.
Es diferente cuando necesitas "subir y bajar" archivos a cuando
necesitas accesar a una máquina.
Pero si, el usuario es peligroso, por eso hay que capacitarlos y
definir políticas, sin eso no hay como protegerse contra problemas
potenciales.
Esto es cierto, tengo terror que aquel que tenga acceso al servicio ssh haga
operaciones que no son correctas, bueno lamentablemente no se puede cubrir
todo, pero al menos las contraseñas son bloques aleatorios de mayúsculas
minúsculas que mezclan números.
Asi que por el momento ya no quiero jugar con eso hasta que termine los demás
módulos de acceso.
...Que, como son imposibles de memorizar, terminan escritas en un
post-it, pegado en el monitor, a la vista de cualquier persona que
pasa por ahí. ¿Te gusta? ¿No es mejor tal vez dejar que elijan
contraseñas no-triviales a su antojo? ¿No es mejor contraseña, por
decirlo, «la bella y graciosa moza marchose a lavar la ropa» [1] que
«aQg54b%TYY»?
Saludos,
[1] http://www.icsi.berkeley.edu/~chema/luthiers/059.html
--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Pero por política la clave del sistema web solo tiene 8 caracteres "la
bella " no parece demasiado complicado :P </broma burlona>
Para eso usas las primeras letras de cada frase, con alguna forma de
elegir mayúsculas y minúsculas. Así, podría ser:
lbygMmal (iniciales de la misma frase de Les Luthiers)
Si gustas, puedes semi-convertirla a leet... 13ygMma1
Y a pesar de la limitante de 8 caracteres, ya es algo más segura :-)
Apto para tí y para mí, pero... ¿Para nuestros usuarios?
Pero si usas autentificación por llave pública con tu SSH tienes la
posibilidad de que los usuarios autorizados protejan su llave con un
passphrase y, mejor aún, tienes la posibilidad de que nadie pueda usar
autentificación por contraseña para conectarse remotamente y así
disminuyes el riesgo de exponer esas débiles contraseñas de 8 caracteres
alfanuméricos.
> Saludos
> Max
>
>
--
Sandino Araico Sánchez
http://sandino.net
Tengo frente a mi un problema con el que necesito algo de orientación.
Estoy haciendo una aplicación en PHP para rellenar un formulario que
reemplace a un formato impreso. El detalle es que una vez guardado
necesito que el formulario se imprima desde el servidor incluyendo
logotipos e imágenes de fondo, esto es debido a que es un formato de
operación interna y quieen que quede exáctamente igual al formato actual
que llenan a mano.
Estaba pensando usar las funciones "printer" de PHP, pero estaba viendo
que al parecer solo se puede imprimir texto tal cual, la verdad es que
aun no he visto bien los manuales.
También estaba viendo la posibilidad de guardar el HTML generado en un
archivo temporal y después ejecutar algún comando del sistema para
mandar la impresión.
Alguno de ustedes sabe que comandos puedo usar para que el documento
HTML pueda ser impreso desde consola tal cual?
O bien alguna librería de PHP que me permita mandar la impresión desde
el servidor?.
La impresora ya la tengo instalada en el servidor por medio de CUPS y
funciona correctamente.
Nota: Si alguien se pregunta el porque a fuerza desde el servidor, es
porque quieren que un callcenter llene el formato, pero no quieren que
tengan la única impresora de red instalada en sus máquinas.
Claro podrías hacer que no se visualice en línea el pdf, sino que lo
guarde en una ruta y de ahí mandarlo a impresión.
Saludos.
--
Atte.
Héctor Bautista Flores
User Linux # 200509
hbautista at usoli.org
hbautista at gmail.com
Jabber: hbau...@jabber.org
AIM: hectorb02
http://usoli.org
http://hbautista.usoli.org
Por otro lado, no sería más sencillo cambiar de formato esos archivos
"dbase" ?? por lo que entiendo no es muy complicado el formato, y con
eso te quitas de encima el problema de estar soportando algo tan
"legacy".
Saludos
Max
--
$ echo "scale=1000000; 4*a(1)" | bc -l
No puedo convertir porque necesito que la aplic
GaRaGeD Style escribió:
Lo malo es que estaba funcionando correctamente, y despues de tanto
ajetreo fue que perdí las funciones para dbase.
No puedo convertir porque necesito que la aplicación se conecte a bases
de datos en dbf que están cambiando constantemente, por lo que no es
conveniente importar cada 3 o 4 horas.
Estaba viendo que puedo instalar el soporte para dbase usando pecl...
pero al intentarlo me dice que no tengo php instalado con soporte para
zlib... alguien sabe como lo puedo habilitar sin tener que recurrir
nuevamente a las fuentes?
Carlos Manuel Escalona Villeda escribió:
El paquete en cuestión no es -hasta donde puedo ver- un paquete
independiente, sino que forma parte de php-db:
$ apt-cache show php-db
Package: php-db
(...)
Description: PHP PEAR Database Abstraction Layer
DB is a database abstraction layer providing:
(...)
Drivers for the following extensions pass the complete test suite and
provide interchangeability when all of the database's portability
options are enabled:
fbsql, ibase, informix, msql, mssql,
mysql, mysqli, oci8, odbc, pgsql,
sqlite and sybase.
.
There is also a driver for the dbase extension, but it can't be used
interchangeably because dbase doesn't support many standard DBMS
features.
El comentario al final básicamente indica que el paquete _cuenta_ con
la funcionalidad para abrir archivos de DBase:
$ dpkg -L php-db|grep dbase
/usr/share/php/DB/dbase.php
Tengo la fortuna de no haberme aún visto forzado a aprender más que lo
muy básico de PHP, así que no puedo ayudarte más allá de esto... Pero
el soporte está ahí ;-)
Contestando un poco más de lado a la pregunta original: No, en Debian
no hay ni ha habido nada por el estilo de los use-flags. Es una
distribución orientada a paquetes binarios.
> Por otro lado, no sería más sencillo cambiar de formato esos archivos
> "dbase" ?? por lo que entiendo no es muy complicado el formato, y con
> eso te quitas de encima el problema de estar soportando algo tan
> "legacy".
La base de datos DBase es completamente obsoleta, cierto... Sin
embargo, el valor de los DBF está mucho más allá de DBase - Es un
formato de intercambio muy bueno. Es un formato orientado a una tabla
por archivo (es bastante complicado implementar semántica de RDBMS
sobre de ellos - pero puedes asomarte al módulo de Perl DBD::XBase
como ejemplo). Y comparado con otros tipos de archivo ampliamente
utilizados para este mismo fin:
- CSV: XBase implementa una estructura real. Tienes renglones y
columnas, y cada columna tiene un tipo claro. Si tienes datos
corruptos, tienes un archivo corrupto, y fin del cuento. Soporta el
indexado y el marcado de renglones como eliminados (lo cual hace que
puedas usarlo como archivo de trabajo y pasarlo entre programas
diferentes más fácilmente que CSVs, con mucho mejor rendimiento)
- XLS: Bueno... Además de que obviamente Excel no sigue estándares
sino que los impone, este formato de archivo tiene demasiadas
complicaciones para un intercambio simple: Es orientado a tabla,
pero soporta muchas (los "libros"). Permite meter mucha información
relativa a formato, que luego termina confundiéndote. Y si recibes
archivos XLS generados por tus usuarios, no faltará el ingenioso que
se le ocurra meter fórmulas y referencias que no son representables
con un enfoque de juego de datos (requieren procesamiento). Además,
está el mismo problema que con los CSVs: El tener una retícula
definida no impide que mezcle tipos de datos, deje renglones o
columnas en blanco, etc.
Y espero que no me pongas a hablar de por qué creo que XML es doloroso
para casi cualquier tipo de intercambio de información no expresamente
diseñado para ello ;-)
¿Tienes PHP instalado desde fuentes? Eso lo explicaría... Te
recomiendo de corazón sólo compilar cuando tienes una razón clara para
no usar los paquetes precompilados.
$ apt-cache show libapache2-mod-php5
Package: libapache2-mod-php5
(...)
Depends: libbz2-1.0, libc6 (>= 2.7-1), libcomerr2 (>= 1.01), libdb4.6, libkrb53 (>= 1.6.dfsg.2), libpcre3 (>= 7.4), libssl0.9.8 (>= 0.9.8f-5), libxml2 (>= 2.6.28), zlib1g (>= 1:1.1.4), mime-support, apache2-mpm-prefork (>> 2.0.52) | apache2-mpm-itk, apache2.2-common, php5-common (= 5.2.6-5), libmagic1, ucf, tzdata
(...)
The following extensions are built in: bcmath bz2 calendar ctype date dba
dom exif filter ftp gettext hash iconv json libxml mbstring mime_magic
openssl pcre posix Reflection session shmop SimpleXML soap sockets SPL
standard sysvmsg sysvsem sysvshm tokenizer wddx xml xmlreader xmlwriter zip
zlib.
(y claro, la misma lista de módulos está disponible para los otros
sabores disponibles de PHP)
Ahora, permíteme refrasear mi primer párrafo: Algunos usuarios
avanzados sí pueden exprimir las ventajas de instalar algunos paquetes
desde fuentes. Y sí, de rato en rato yo lo he hecho también. Pero las
ventajas de tener los paquetes precompilados y probados típicamente
son mayores... En mis servidores, normalmente no tengo más de unos 10
o 15 archivos dentro de /usr/local, y tienden a ser scripts escritos
por mí mismo. Incluso para su uso en una sóla computadora, siempre
prefiero armar paquetes para cualquier cosa que tenga que instalar a
patita. Ayudan a mantener la sanidad a largo plazo.
Saludos,
$dsn = 'dbase:////home/max/dbase.db?mode=0666';
$options = array(
'debug' => 2,
'portability' => DB_PORTABILITY_ALL,
);
$db =& DB::connect($dsn, $options);
if (PEAR::isError($db)) {
die($db->getMessage());
}
// ...
$db->disconnect();
?>
max@garaged ~ : php dbase.php
DB Error: extension not found
El paquete es una capa de abstracción, pero todavía necesita que
tengas el "módulo/driver" (dbase.so) correspondiente para cada base de
datos.
No debería ser demasiado difícil agregar el "módulo", manualmente, o
incluso crear el .deb, pero yo no tengo una máquina decente para
compilar lo necesario y probarlo (me da hueva invertirle unas horas al
proceso con mi procesador de 1.7Ghz).
Y podrás invertir en portar la aplicación, o parte de ella a perl ??
libdbd-xbase-perl - Perl module to access xbase files (optionally through DBI)
Ummm... A saber qué es lo que tienes ahí. Por acá funciona sin
broncas:
0 gwolf@lafa[11]~$ php /usr/share/php/DB/dbase.php
0 gwolf@lafa[12]~$
Y no tengo en mi sistema ningún dbase.so; el paquete php-db sólo
depende de php-pear (y no recomienda ni sugiere nada), y php-pear
depende de php5-cli | php4-cli, php5-common (>= 5.2.0-8+etch13),
recomienda gnupg y sugiere php5-dev | php4-dev. Ergo, hasta donde
entiendo, está completo.
Saludos,
Gunnar
Lo que yo corrí fué un script mínimo que intenta abrir una base de
datos dbase vacía (la va a crear automágicamente, pq no existe).
Si corres /usr/share/php/DB/dbase.php, simplemente estás cargando una
clase, pero ni siquiera estas creando una instancia de ella, por lo
que no puedes saber si va a funcionar o no (magia php-era).
Sí es necesario tener un driver para dbase, así como es necesario
tener uno para mysql o cualquier otra base de datos que desees accesar
a través de el módulo php-db de pear.
Ya pude instalar con pear un agregado llamado "DB" y se me creó
/usr/share/php/DB/dbase.php
Para que funcionara tuve que buscar el archivo dbase.so en un RPM para
mandriva y copiarlo a /usr/lib/php5/20060613+lfs/
Ahora el detalle es que necesito documentación para aprender a usar
dbase.php, pero parece que la misma es inexistente, solo están los
comentarios incluidos dentro del fichero.
La aplicación que estoy haciendo es para un CallCenter que graba todo en
un sistema basado en Clipper. La utilidad era llenar un formato (que
actualmente llenan a mano) de forma automática a partir de los DBF en
donde capturan la información y mandar a imprimir el formato completo,
con miras a convencerlos para tirar a la basura a clipper y hacer una
aplicación de verdad....
De momento creo que me olvidaré del llenado automático a partir de los
DBF en lo que encuentro la manera de poder leer nuevamente estos
archivos desde PHP ahora que mis preciosas funciones ya no sirven....
Que mala leche.
GaRaGeD Style escribió:
UGH...
Una razón más para odiar a PHP. Chale, yo supondría que con compilar
dbase.php debería tener la inteligencia suficiente para ver si es
aplicable en el mundo real...
Gr, vo'a revisar esto un poquito, y... bueno, por lo menos merecería
meter un reporte de bug!
Pos... Como podrán darse cuenta, reporté el bug. A ver qué nos
responden.
Saludos,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504889
Saludos
Max
p.d. en teoría no es un duplicado, sino que ambas cosas deberían
corregirse, aunque ya no es totalmente posible pq ya no hay manera de
mantener separado el módulo php-dbase.
Bueno, es el mismo problema, por tanto podría verse como un sólo bug
;-) Pero bueno, veo que ya te respondió el buen Raphael, y estructuró
los bugs de manera correcta (el tuyo y #341420 se refieren al mismo
problema por lo que los unió - "merge"), e indicó que el bug que yo
reporté depende de la resolución del tuyo.
Pero bueno, por lo visto la parte medular es lo reportado en #341420 -
La licencia de dbase.so menciona:
Permission is granted to distribute and use the source,
documentation files and/or compiled binaries associated with dbf
for non-commercial use. No charges may be made for such
distributions.
Por lo que no puede ser considerado libre.
En un momento más le aviso a Raphael Geissert para ver si revisa el
archivo y corrige el problema para la siguiente version/revision de
php.
Orale, que buenas cosas salen de un problema práctico no ?
Saludos
Max
Bueno, Raphael no es el mantenedor de PHP, es un chavo (residente en
Jalapa, para más señas) muy metido en QA en general - en todo caso,
responde al reporte mismo, donde lo verá quien deba verlo.
Oye, ¿y dónde encontraste eso? Porque en Sid, el problema sigue
presente. El encabezado de dbase.php sigue diciendo:
* The PEAR DB driver for PHP's dbase extension
* for interacting with dBase databases
*
* PHP versions 4 and 5
(...)
* @copyright 1997-2007 The PHP Group
* @license http://www.php.net/license/3_0.txt PHP License 3.0
No se si te referías a esa licencia - Sí, dbase.php es libre, pero no
dbase.so :-/
> Orale, que buenas cosas salen de un problema práctico no ?
Es divertido. Y reportar bugs también!
El archivo dbase.c incluye todavía unos archivo dbf_* que mantienen el
problema de licenciamiento, y bueno, ya le escribí al autor para saber
de buena fuente si tiene interés en relicenciar o no los archivo para
que sean incluidos en Debian.
A ver que responde.
Gunnar:
Lo vi en ./ext/dbase/dbase.c, en los sources de php5, le dí una
revisada rápida, y como ví que implementaba todo, pensé que había sido
totalmente sustituido, pero resulta que si incluye el archivo "dbf.h"
que a su vez incluye los otros archivos con licencia desconocida.
HOWTO Novia <http://paynalton.blogspot.com/2008/11/howto-novia.html>
Introducción:
Existen muchos debates sobre la utilidad y conveniencia de tener NOVIA.
y es que si bien NOVIA puede traer muchas ventajas si se sabe utilizar
adecuadamente, también es cierto que NOVIA acapara muchísimos recursos
y, en ocasiones, simplemente se cuelga sin ninguna explicación lógica y
es necesario meter mano en todo el sistema para que vuelva andar, por lo
que muchos terminan desinstalando el paquete y todo rastro de su existencia.
En algunos foros y listas podemos ver usuarios complacidos por tenerle,
aseguran que los problemas se compensan de sobra con las ventajas. Lo
cierto es que al principio todos siempre están felices de tener NOVIA,
aunque la gran mayoría comienza a quejarse después de un tiempo.
Si a pesar de todo quieres tener NOVIA, entonces comencemos:
Preparativos.
Lo primero que necesitamos es tener el soporte adecuado en el Kernel,
toma en cuenta que hay ciertas incompatibilidades entre NOVIA y algunas
cosas que seguramente tienes ya compiladas, pero que te traerían
problemas si las mantienes junto con NOVIA.
#cd /usr/src/linux
#make --menuconfig
Primero habrás de quitar el soporte en el kernel de los módulos siguientes:
<>Borrachera
<>Largas horas en el WOW
<>Pláticas sobre tecnología que solo tu entiendes.
<>Criticar a artistas famosos por lo estúpidos que son.
<>Mirar a otras mujeres.
<>Deseos de ahorrar.
<>Intenciones de querer meterle Linux a todo aparato que caiga en tus manos.
Y Debes habilitar el soporte para lo siguiente:
<*>Paciencia
<*>Capacidad de alejarse más de 15 min de la computadora
<M>Deseos de socializar
<*>Capacidad para aguantar largas charlas en las que no se mencione a
Linuz Tovars ni una sola vez.
Nota: Si realmente no deseas retirar por completo el soporte a lo que
mencionamos anteriormente, puedes colocarlos como módulos y activarlos
con modprobe cuando NOVIA no esté en uso. Pero ten cuidado pues a veces
NOVIA se activa de improviso y si están activos estos módulos cuando lo
haga puede colgarse todo el sistema (sobre todo si tienes activo "mirar
a otras mujeres").
#make && make modules_install
#make install.
Instalando NOVIA
Primero descarga a NOVIA desde el repositorio de tu preferencia, existen
muchos repositorios, algunos libres y otros privativos, elige bien a la
NOVIA que deseas y descárgarla.
Los repositorios que te puedo recomendar son:
$wget http://cafeteria.escuela.edu/novia.deb
$wget http://salondeclases.escuela.edu/novia.deb
$wget http://antromascercano.com/novia.deb
$wget http://forodeencuentros.com/novia.deb
$wget http://citaaciegas.mama.org/novia.deb
$wget http://amiga.hermana.net/novia.deb
$wget http://novia.mejoramigo.net/novia.deb
$wget http://amiga.infancia.org/novia.deb
$wget http://desconocida.concierto.com/novia.deb
$wget http://vecinita.vecindario.net/novia.deb
Estate preparado para satisfacer las dependencias con los siguientes
paquetes:
#apt-get install baño-diario peinado-decente mira-sus-ojos-y-no-sus-pechos
#apt-get purge hablar-estupideces wow-adicción
Y también es recomendable contar con los siguientes paquetes:
#apt-get install flores chocolates cena-romantica cine
Una vez que tengas todo listo, como root:
#dpkg -i novia.deb
Es importante que no intentes instalar mas de un NOVIA al mismo tiempo,
pero si tienes dos o más procura tener solo un módulo activo o se te
colgará el sistema.
Reinicia el sistema y tendrás a NOVIA totalmente operativo
Utilizando NOVIA
Puedes levantar el servicio con el comando:
#/etc/init.d/llamaportelefono start
Esto arrancará a novia cada vez que la necesites, para detenerla
necesitas el siguiente comando:
#/etc/init.d/llevalaacasa stop
Si no vas a hacer uso seguido de NOVIA, usa con frecuencia:
$/usr/bin/llamaparasaludar
De lo contrario pudiera ser que NOVIA ya no responda cuando intentes
levantar el servicio.
También procura no usar en exceso este último comando, pues al parecer
algunas versiones de NOVIA tienen un bug que hace que se cuelguen
definitivamente, sobre todo si lo utilizas más de 5 veces al día.
Resolviendo problemas con NOVIA
Si en algún momento NOVIA se cuelga, puedes usar el siguiente comando:
#echo "Te Quiero" >> /etc/novia/oido.conf
#cat /sbin/besotierno >> /etc/novia/mejilla.conf
#/etc/init.d/llamaportelefono forcereload
Y si no resulta, puedes intentar:
#cat /sbin/regalocaro >> /etc/novia/mano.conf
#/etc/init.d/llamaportelefono forcereload
Si notas que NOVIA se cuelga muy seguido, revisa si no te falta alguna
dependencia. También sería conveniente que tengas estos paquetes si no
los tenías instalados con anterioridad:
#apt-get install ponte-desodorante lavate-bien-la-boca
pon-atencion-cuando-habla
Paquetes Extras
Entre otras cosas, los usuarios avanzados de NOVIA recomiendan los
siguientes paquetes:
#apt-get install novia-gusto-por-el-wow novia-usa-linux novia-vuelvete-geek
El paquete "sexo" es bastante recomendado, pero se recomienda haber
tenido ya un poco de tiempo en el manejo de NOVIA, pues muchos usuarios
novatos quieren instalar "sexo" apenas terminan de configurar a NOVIA,
lo cual casi siempre lleva a un bug que hace que NOVIA se desinstale a
si mismo y te arroje todos los logs de error sobre tu /home de un solo
golpe.
Si quieres instalarlo, es recomendable que en tu kernel actives como módulo
<M> condón
O, si no quieres estar levantando el módulo cada vez que quieras usar
"sexo" con NOVIA, puedes poner de forma permanente:
<*> vasectomía
Ninguno de estos dos es obligatorios, pero si no lo haces tarde o
temprano NOVIA ejecutará el comando:
wget https://cigüeña.paris.org/bebe.tar.gz
Este paquete privativo ocupa gran cantidad de espacio (tarda
aproximadamente 9 meses en descargar el tar comprimido y unos 18 años en
descomprimirse y compilar), y en algunos países es obligatorio instalar:
#apt-get novia-matrimonio
lo cual no siempre es lo que el usuario desea.
En estos casos algunos han encontrado la solución corriendo uno de los
tres siguientes comandos:
#killall bebe
#killall embarazo
#/sbin/NOVIA --aborto
Pero está demás decir que por licencia esto es ilegal en muchos países.
Conclusiones
Bien, ahora que están mejor informados disfruten de NOVIA si encuentran
el paquete apropiado y recuerden que NOVIA es solo una versión de prueba
que pueden elevar a ESPOSA si corren el script:
#/usr/bin/boda -i /sbin/NOVIA -o /sbin/ESPOSA
Solo mis 2 centavos
Cualquiera que ponga como "repositorio" un archivo.deb es un wanabe en vez de un verdadero geek :) Solo mis 2 centavos Max
Si ánimo de ofender ni nada, en esencia no se puede evitar ser geek,
simplemente lo eres, como cuando eres don juan, o webon, lo eres y ya
:), así que muy evitable no lo es. Y no es que lo necesites,
simplemente lo eres, así de simple.
Checa el wikimedia, con lo que hacen wikipedia, es lo máximo de lo
máximo en wikis, hay muchas otras opciones, pero dificilmente vas a
encontrar algo mejor que eso.
Saludos