Xulen | Julián Fernández

Desde hace algunas semanas o poco más, la industria del entretenimiento esta siendo hackeada sistematicamente. El primer caso más resonante fue el de PSN, no recuerdo cuanto tardaron en restablecer el servicio pero se que no fue un asunto de pocos días. Rápidamente se sumaron Epic, Eidos, Codemasters y en estos días Bethesda. Me sorprendió lo virulenta de la reacción de gamers de a pie en sitios como gamespot donde piden poco menos que la cabeza de los hackers. Pensé entonces que sería exagerado de mi parte interpretar con alarma tanta manifestación de odio y frustración porque después de todo los niños son propensos a la ira cuando frustran sus deseos. Aún cuando el promedio de edad de los consumidores de videojuegos crece y no puede pensarse en la típica cuestión vegetativa me incomodaba la profusión discursiva pentagonal que reclamaba la tipificación terrorista para acciones de este estilo. En fin, resulta que el asunto parece ser de discusión pública porque el WSJ publicó el 31 de mayo un artículo que discute al hacking como acto de guerra (ver) y entonces claro, el mensaje empieza a funcionar como un meme y si además lo instalás sobre individuos con un factor multiplicador bastante interesante como el de estos sujetos hiperconectados ya podemos esperar que una parte significativa de la opinión pública acepte con naturalidad parangonar hackers con terroristas. Ojo, no quiero decir con esto que los alcances de una acción disruptiva y de sabotaje como el hackeo no pueda tener un impacto significativo, solo me preocupa la extensión de las etiquetas ( o las etiquetas a secas).

Quizá la tactica más económica para ganar adeptos respecto de la posición "anti-terrorismo-cibernetico" sea hackear sistematicamente unos cuantas empresas de entretenimiento y después sentarse a esperar un poco.

Hace un tiempo que estoy probando diferentes paneles de control para mis servidores. Básicamente Kloxo y un poco de webmin. Dejo acá para encontrarlo fácil.

En kloxo

Conecto a la terminal usando putty

Voy al directorio script

ejecuto:

útil. Lo encontré por ahí y me sirvió para liberar memoria ociosa en un servidor.

Fuente: http://www.linuxtutorialblog.com/post/tutorial-disabling-unused-daemons-to-speed-up-your-boot-sequence

Many Linux distros usually start a lot of daemons when booting, resulting in a long wait before you can get to work after powering on your machine. Some of those daemons are rarely used (or even not al all) by the majority of users. This tutorial describes how to disable unused or rarely used daemons in a proper way, resulting in faster boot sequences and less CPU load.

Note: Although this tutorial aims to be system-friendly and not dangerous, please do not disable any service if you don't know what you are doing. Especially on server systems, (accidently) disabling an important service can have serious consequences. This tutorial is provided as-is, without any warranty and so on. Just be careful, ok? =)

Another note: This tutorial uses the words "service" and "daemon". These words have an almost identical meaning, although service focuses a bit more on what a process does, or, in other words, which service a process provides. The word daemon refers to the "physical" (how could software ever be physical?) process.

First Part: The how-to (or howto)

Indeed, this tutorial is splitted in two parts to allow easy reading. The first part explains how to disable those services (and which services to disable) in a short and clear way. The second part (the tutorial part) explains what's behind it, and allows deeper insight in Linux booting. If you don't want and/or need that deeper insight, don't read the second part =).

Finding out what's running on your system

Most distros feature some kind of tool which allows you to manage the daemons that are started on your computer when booting. The most common one is chkconfig, which features a commandline interface. You can list all processes that are started when booting to graphical mode with the following command:

[rechosen@localhost ~]$ /sbin/chkconfig --list | grep "5:on"

When running a text-mode system, you will usually boot to runlevel 3. To see the processes that are started at boot time on these systems, use this command:

[rechosen@localhost ~]$ /sbin/chkconfig --list | grep "3:on"

Many distros also feature a GUI for daemon startup configuration. A well-known one is serviceconf. You will usually find such a GUI in areas like "System" or "Configuration", named like "Services" or "Boot configuration" or "Daemons" (note that the second one can also be a configuration GUI for the bootloader, like GRUB or lilo, which is not what we're dealing with right now). Using a GUI configurator is recommended, because they usually are more tuned for your distro than chkconfig.

The following section contains a list of daemons that can be disabled in certain cases. Compare the list of daemons that are started on your system to the list below, read the descriptions and determine whether or not it would be a good idea to disable it. Once you made up your mind on which services you're going to disable, continue to Disabling Daemons.

Common unused / rarely used daemons

The following list contains daemons that may not be used by a 'normal' end-user. You can compare the list of daemons started up on your system to this list, and see if you could safely disable some of those daemons.

Bluetooth
• hcid, sdpd and hidd (These daemons provide Bluetooth services and are unnecessary if you don't have any Bluetooth hardware)

Disabling daemons

When using a GUI to manage the daemons started at boot-time, you will usually be able to disable them by simply unchecking a checkbox. When using chkconfig, you can use the following syntax:

[rechosen@localhost ~]$ /sbin/chkconfig name off

Replace "name" with the name of the daemon you want to disable. If you accidently disabled a wrong daemon, you can turn it on again this way:

[rechosen@localhost ~]$ /sbin/chkconfig name reset

You might think this is illogical, that it should be:

[rechosen@localhost ~]$ /sbin/chkconfig name on

Well, it shouldn't. The above command would turn on the starting of the daemon for a fixed set of runlevels, no matter what the previous values were. That's not exactly what we want, as we want it to switch it back to the old state. The word "reset" tells chkconfig to restore the values specified in the init script that contains the instructions on how to start the daemon. These values are (or should be) the defaults. Remember that the default values are not always equal to the old values, but they will mostly be closer to them than the values that "on" implies. You might need to modify a select amount of runlevels to correct it. You can do this by specifying which runlevels should be altered, like this:

[rechosen@localhost ~]$ /sbin/chkconfig --level 35 name on

The above command would turn on the startup of the daemon "name" for the runlevels 3 and 5. The argument for "--level" is just a string of runlevel number, without separation. Another example:

[rechosen@localhost ~]$ /sbin/chkconfig --level 235 name on

Second part: The tutorial

This part will explain what's behind all the commands above. If you want to know how Linux "knows" what to start at boot time, what a "runlevel" is and why there usually are 7 of them (or, arguably, 8), read on.

Note: This part will not be right for every distro. There are a lot of differences between distros at this point, so I tried to expose the most default configuration.

How Linux "knows" what to start at boot time

When you boot up a Linux computer, you'll usually see the bootloader (after the BIOS has done its part of the booting process). The bootloader, usually Lilo orGRUB, is configured to load the kernel of the Linux into the memory of your computer. The kernel then leaves the bootloader behind and continues booting on its own, initializing hardware and making itself ready to start running init. And init is the process we're looking for: it is the first process run, and it spawns all other processes. But where does init look to know which processes to start? The short answer is: in /etc/rc*.d/ (usually). But that's not the full answer. To understand how it uses the files in those directories, we will first need to understand what runlevels are.

Runlevels

A runlevel is the process state in which a system can reside. For example: runlevel 1 usually is the rescue mode, it boots the system starting as few processes as possible, providing the user with a root-access console, without networking functionality and without any GUI. On the other hand, runlevel 5 usually is the full-fledged graphical multi-user mode. There also are special runlevels that you shouldn't boot to, but that you could switch to after booting: for example, switching to runlevel 0 (zero) shuts down your computer (don't try this until you read the full tutorial) and switching to runlevel 6 will make your system reboot itself. Now for the full list of runlevels and their common configuration:

• 0: Shuts down the system (to be switched to after booting)
• 1: Boots the system to a rescue mode
• 2: Boots the system to a multi-user mode without networking functionality (some systems, like Debian, use this as a full-fledged mode)
• 3: Boots the system to a multi-user mode with networking functionality (some systems, like Debian, use this as a full-fledged mode)
• 4: Generally not used (sometimes it is the same as runlevel 5 or 3)
• 5: Boots the system to a full-fledged graphical multi-user mode (with networking, of course)
• 6: Reboots the system (to be switched to after booting)
• (s or S: Usually similar or equal to runlevel 1)

As the last runlevel is not always considered a real runlevel (it is then called an alias), the number of runlevels is usually seven, but arguably eight. You can switch between all runlevels after having booted, although 0 and 6 will (of course) require you to boot again before you can switch again. Switching between runlevels is usually done with the init command, like this:

[rechosen@localhost ~]$ init 3

The above command would (run as root or with root permissions) switch your system to runlevel 3, unless it's already running in runlevel 3 (replace the 3 with an other digit if you want to switch to an other runlevel). When switching between runlevels, init terminates the processes that were running in the old runlevel which should not run in the new one (these are zero processes when booting and all processes when shutting down or rebooting) and starts the processes that were not running in the old runlevel which should run in the new runlevel (these are zero processes when shutting down or rebooting, but when booting, it depends on the runlevel you're booting to). And now we can go on to the way init "knows" what to start and what to stop.

What to start and what to stop?

When the init process is started by the kernel, it first looks in the /etc/inittab file to see what to do in case of a certain runlevel. This file usually tells init to look in the corresponding /etc/rcX.d/ directory, where X is the runlevel. For example, when booting to runlevel 5, init will run the scripts in /etc/rc5.d/ (please note (again) that this does not apply to all distros). These "scripts" usually are symlinks to the corresponding service management scripts in /etc/init.d/ (or /etc/rc.d/init.d/). But how can such a script understand whether init wants it to start or stop the service? Well, when init wants the script to start the process, it will run the script with "start" as the first argument. When wanting the script to stop the service, init will pass "stop" as the first argument. You can also do this yourself if you want to start or stop a service. For example:

[rechosen@localhost ~]$ /etc/init.d/ntpd stop

The above example would stop the ntpd daemon. To start it again use the following command:

[rechosen@localhost ~]$ /etc/init.d/ntpd start

Stopping and starting can usually be combined in the following way.

[rechosen@localhost ~]$ /etc/init.d/ntpd restart

This is useful in case you want a daemon to re-read its config files. Depending on the service the script was written for (and the script itself), other arguments may also be supplied.

Anyway, let's get back to the /etc/rcX.d/ directory. This directory is filled with files named like "K59somedaemon" and "S10anotherdaemon". I'll give a short explanation:

• "K" means "kill" and "S" means "start": The symlinks starting with "K" will be executed with a "stop" argument by init, and the symlinks starting with "S" will be executed with a "start" argument.
• The two digits after "K" or "S" don't mean anything really special, they are just used for sorting. Symlinks that need to be run before certain other ones should have a lower number than the other ones.
• The name of the daemon after it is actually not necessary for init, but it's good practice for sysadmins so they can instantly see what the symlink is for.

Finally, you should know that pretty much any distro has got some check somewhere to ensure that already running processes are not started again (which would result into two interferring processes, unless the daemon itself checks if there isn't an other instance running) and that already terminated processes will not be "reterminated". This is usually done by some special program or script that is called to do the actual starting.

Final words

Well, I hope this tutorial helped you cutting on the CPU load and boot time of your computer and understanding what makes a Linux system come up after you turned your computer on. If you have any suggestions (for example: another daemon that seems to be unnecessary in certain cases or another way to manage the startup of daemons) please leave a comment. Thanks for reading and God bless! =)

Para chequear que distro tenés usa:

Esto básicamente pretende ser una colección de URLs que cargo con rapidminer para crawlear el contenido de esas URLs e identificar términos interesantes a la hora de utilizar como keywords de alta rentabilidad en adwords.

http://www.clarin.com/politica/Bloquean-Congreso-facilidades-jubilarse_0_464953520.html

http://www.clarin.com/politica/Gobierno-ampliaria-regimen-jubilarse-aportes_0_464953519.html

http://www.clarin.com/politica/Jubilaciones-incluiran-pagos-remunerativos_0_437356321.html

http://www.lanacion.com.ar/1354379-la-corte-contra-los-pagos-en-negro

Crontab – Quick Reference

Setting up cron jobs in Unix and Solaris

cron is a unix, solaris utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon. These tasks are often termed as cron jobs in unix , solaris.  Crontab (CRON TABle) is a file which contains the schedule of cron entries to be run and at specified times.

This document covers following aspects of Unix cron jobs
1. Crontab Restrictions
2. Crontab Commands
3. Crontab file – syntax
4. Crontab Example
5. Crontab Environment
6. Disable Email
7. Generate log file for crontab activity

1. Crontab Restrictions
You can execute crontab if your name appears in the file /usr/lib/cron/cron.allow. If that file does not exist, you can use
crontab if your name does not appear in the file /usr/lib/cron/cron.deny.
If only cron.deny exists and is empty, all users can use crontab. If neither file exists, only the root user can use crontab. The allow/deny files consist of one user name per line.

2. Crontab Commands

export EDITOR=vi ;to specify a editor to open crontab file.

crontab -e    Edit your crontab file, or create one if it doesn’t already exist.
crontab -l      Display your crontab file.
crontab -r      Remove your crontab file.
crontab -v      Display the last time you edited your crontab file. (This option is only available on a few systems.)

3. Crontab file
Crontab syntax :
A crontab file has five fields for specifying day , date and time followed by the command to be run at that interval.

*     *     *   *    *        command to be executed
-     -     -   -    -
|     |     |   |    |
|     |     |   |    +----- day of week (0 - 6) (Sunday=0)
|     |     |   +------- month (1 - 12)
|     |     +--------- day of        month (1 - 31)
|     +----------- hour (0 - 23)
+------------- min (0 - 59)

* in the value field above means all legal values as in braces for that column.
The value column can have a * or a list of elements separated by commas. An element is either a number in the ranges shown above or two numbers in the range separated by a hyphen (meaning an inclusive range).
Notes
A. ) Repeat pattern like /2 for every 2 minutes or /10 for every 10 minutes is not supported by all operating systems. If you try to use it and crontab complains it is probably not supported.

B.) The specification of days can be made in two fields: month day and weekday. If both are specified in an entry, they are cumulative meaning both of the entries will get executed .

4. Crontab Example
A line in crontab file like below removes the tmp files from /home/someuser/tmp each day at 6:30 PM.

30     18     *     *     *         rm /home/someuser/tmp/*

Changing the parameter values as below will cause this command to run at different time schedule below :

Note : If you inadvertently enter the crontab command with no argument(s), do not attempt to get out with Control-d. This removes all entries in your crontab file. Instead, exit with Control-c.

5. Crontab Environment
cron invokes the command from the user’s HOME directory with the shell, (/usr/bin/sh).
cron supplies a default environment for every shell, defining:
HOME=user’s-home-directory
LOGNAME=user’s-login-id
PATH=/usr/bin:/usr/sbin:.
SHELL=/usr/bin/sh

Users who desire to have their .profile executed must explicitly do so in the crontab entry or in a script called by the entry.

6. Disable Email
By default cron jobs sends a email to the user account executing the cronjob. If this is not needed put the following command At the end of the cron job line .

>/dev/null 2>&1

7. Generate log file
To collect the cron execution execution log in a file :

30 18 * * * rm /home/someuser/tmp/* > /home/someuser/cronlogs/clean_tmp_dir.log

Resulta que estoy montando un sitio de ecommerce y tengo que testear el sistema de programas de afiliados. Para ello necesito derivar ventas desde otro sitio  y el programa de afiliados le otorga una comisión al afiliado cuyo tráfico concreta una compra. Esta es una prueba :)

Link de progrma afiliado :)

• Red Hat Enterprise Linux 5 / i386:

  rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

• Red Hat Enterprise Linux 5 / x86_64:

  rpm -Uhv http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS//rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm

• Red Hat Enterprise Linux 4 / i386:

  rpm -Uhv http://apt.sw.be/redhat/el4/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el4.rf.i386.rpm

• Red Hat Enterprise Linux 4 / x86_64:

  rpm -Uhv http://apt.sw.be/redhat/el4/en/x86_64/rpmforge/RPMS/rpmforge-release-0.3.6-1.el4.rf.x86_64.rpm

• Red Hat Enterprise Linux 3 / i386:

  rpm -Uhv http://apt.sw.be/redhat/el3/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el3.rf.i386.rpm

• Red Hat Enterprise Linux 3 / x86_64:

  rpm -Uhv http://apt.sw.be/redhat/el3/en/x86_64/rpmforge/RPMS/rpmforge-release-0.3.6-1.el3.rf.x86_64.rpm

• Red Hat Enterprise Linux 2 / i386:

  rpm -Uhv http://apt.sw.be/redhat/el2.1/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el2.rf.i386.rpm

• Red Hat Linux 9 / i386:

  rpm -Uhv http://apt.sw.be/redhat/9/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.rh9.rf.i386.rpm

• Red Hat Linux 7.3 / i386:

  rpm -Uhv http://apt.sw.be/redhat/8.0/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.rh7.rf.i386.rpm

Para activar mod_rewrite en sh404 con acceso a .htaccess editás lighttpd.conf (en etc/lighttpd) y agregas la siguiente línea como error-handler: