Páginas

segunda-feira, 28 de março de 2011

Intel lança linha mais barata de SSDs

SSD
Intel anunciou nesta segunda-feira (28/03) sua nova linha de SSDs, nomeada "320 Series", na qual os dispositivos utilizam chips de memória NAND flash MLC (multi-level cell) e podem ter uma capacidade de até 600Gb.

domingo, 27 de março de 2011

Mantenha seu código limpo em desenvolvimento web - Parte 02 – iMasters

Mantenha seu código limpo em desenvolvimento web - Parte 02 – iMasters:

Continuando nossa saga de transformar vocês, jovens padawans, em mestres super sayajins (NullPointerException) da codificação maneira, vamos a mais algumas pérolas de sabedoria...

Mantenha seu código limpo em desenvolvimento web - Parte 01

Um problema comum em quase todas as profissões que podem levar as pessoas completamente a loucura é ter de continuar o trabalho a partir do que alguém começou. A principal razão para isso é o fato de que cada um tem formas diferentes de trabalhar, e às vezes isso pode causar uma bela confusão.

A fim de tornar o código mais limpo e apoiar o trabalho em equipe (o que significa que alguém pode precisar trabalhar com o que foi codificado antes), existem algumas considerações (e dicas) que devem ser levadas em conta.

segunda-feira, 14 de março de 2011

Checklists para proteger sua rede de ataques DDoS

Nada deve dar mais medo a um administrador de redes do que ataques distribuidos de negação de serviço. Nao muito tempo atrás ferramentas como o Tribe Flood Network do Mixter deram trabalho a administradores de redes que sofreram na mão de miúdos do estilo do Mafia Boy, lembro que um provedor Inglês foi mesmo encerrado depois de sucessivos ataques .

Hoje a situação mudou, os sistemas operativos e dispositivos de rede foram melhorados. A Cisco como nao podia deixar de ser possui também varias soluções. Vou deixar aqui 2 documentos que recomendo para administradores de rede preocupados com o risco de ataques desse genero:

Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks
Characterizing and Tracing Packet Floods Using Cisco Routers

Wifite - Ataques a redes Wifi em massa que utilizam WEP ou WPA | Coruja de TI

Wifite - Ataques a redes Wifi em massa que utilizam WEP ou WPA | Coruja de TI: "Todas as redes wi-fi que conhecemos ou acessamos utilizam WPA ou WEP para criptografar o seu acesso, é chover no molhado em afirmar que WPA é n vezes mais seguro que WEP, mas não é 100% seguro.

A ferramenta Wifite foi desenvolvida para automatizar e realizar ataques múltiplos a redes Wi-fi que utilizam uma das criptografias citadas, e na minha opinião é uma das melhores ferramentas já desenvolvidos até então. Ela só roda em mundo Linux e foi inclusa na distribuição de segurança BackTrack 4 RC1.



O que mais chamou a atenção foi a capacidade de realizar ataques múltiplos em múltiplas redes que utilizam WEP ou WPA, fantástico.

Caso você tenha um Linux e deseje utilizar o WiFite, vai ai o Link para download.
"

sexta-feira, 11 de março de 2011

Quer fazer seus próprios aplicativos para o iPhone?

Site facilita o processo, e nem precisa saber programar.

Com o App Makr, até mesmo quem não entende muito de programação pode criar seu aplicativo. Para isso, entre no site e clique em "Create".

Site: http://www.appmakr.com/

quinta-feira, 10 de março de 2011

BASH: O que o #! realmente faz

Certa vez, há muito tempo atrás, o Unix possuia apenas um shell, o Bourne shell, e quando um script era escrito, o shell lia o script e executava os comandos. Então outro shell apareceu, e depois, outro. Cada shell possuia sua própria sintaxe e alguns, como o C shell, eram bastante diferentes do original. Isto significava que, se um script usava os recursos de um shell ou de outro, ele deveria ser executado usando aquele shell. Em vez de escrever:

doit

O usuáiro tinha que escrever:

/bin/ksh doit

ou:

/bin/csh doit

Para remediar esta situação, uma alteração inteligente foi feita no kernel Unix -- agora um script poderia ser escrito começando com uma combinação hash-bang (#!) na primeira linha, seguida pelo shell que executaria o script. Por exemplo, dê uma olhada no seguinte script, chamado doit:

#!/bin/ksh
#
# do some script here
#

Neste exemplo, o kernel lê o script doit, vê o hash-bang, e continua a ler o resto da linha, onde ele encontra /bin/ksh. O kernel então inicia o Korn shell com doit como um dos argumentos, e passa a ele o script, como se o seguinte comando tivesse sido escrito:

/bin/ksh doit

Quandi o /bin/ksh começa a ler o script, ele vê o hash-bang na primeira linha como um comentário (por que ele começa com um hash), e ignora o mesmo. Para ser executado, o path completo do shel é necessário, já que o kernel não irá examinar sua variável PATH. O manipulador de hash-bang do kernel faz mais que só executar um shell alternativo, ele realmenet pega os argumentos que seguem o hash-bang e usa os mesmos como um comando, e acrescente o nome do arquivo como argumento àquele comando.

Você pode iniciar um script Perl, chamado doperl, usando o hash-bang:

#!/bin/perl

# do some perl script here

Se você escrever doperl, o kernel examina o hash-bang, extrai o comando /bin/perl, e executa o mesmo como se você tivesse escrito:

/bin/perl doperl

Existem dois mecanismos em funcionamento que permitem que isto funcione. O primeiro é a interpretação do kernel do hash-bang, o segundo é que o Perl vê a primeira linha como um comentário e ignora a mesma. Esta técnica não irá funcionar com linguagens de script que não tratam linhas que começam com um hash como comentário -- nestes casos, provavelmente você terá um erro. Você não precisa se limitar a usar este método apenas para executar scripts, apesar que é onde ele é mais útil.

O seguitne script, chamado helpme, apresenta a si mesmo no terminal quando você executa o comando helpme:

#!/bin/cat
vi unix editor
man manual pages
sh Bourne Shell
ksh Korn Shell
csh C Shell
bash Bourne Again Shell

Este truque do kernel irá executar um argumento após o nome do comando. Para esconder a primeria linha, faça que o arquivo use o more, iniciando na segunda linha, mas certifique-se de usar o path correto:

#!/bin/more +2
vi unix editor
man manual pages
sh Bourne Shell
ksh Korn Shell
csh C Shell
bash Bourne Again Shell

Ao escrever o helpme como um comando, o kernel converte isto para:

/bin/more +2 helpme

Tudo a partir da linha dois em diante é mostrado:

helpme
vi unix editor
man manual pages
sh Bourne Shell
ksh Korn Shell
csh C Shell
bash Bourne Again Shell
etc.

terça-feira, 8 de março de 2011

Getting to know Bash

Getting to know Bash: "Getting to know Bash
What is bash?
What is a shell?
Aliases
History
Completion
Globbing
Redirecting input and output
Quoting
Miscellaneous useful commands
For more information
What is bash?
`bash' stands for `Bourne Again SHell'. The Bourne shell was the original shell for UNIX: the ubiquitous `/bin/sh'. Bash is the GNU project's (free) re-implementation of the Bourne shell (with extra features, of course).
What is a shell?
A shell is just a command line interface between the user and the operating system. You type in what programs you want to run, and the shell runs them for you. Of course, shells generally allow you to do much more than this.

Here's an (incomplete) list of shells available for Unix-like operating systems:

sh ash bash csh tcsh ksh zsh rc es sash

bash, tcsh, zsh and ksh are probably the most popular these days. Here we look at bash, but (almost?) all the features covered here can be found in one form or another in the other popular shells.
Aliases
Aliases provide short-cut commands. For example:

alias h=history
alias ls='/bin/ls -CF'
alias cp='/bin/cp -i'
alias mv='/bin/mv -i'
unalias rm

Bash only supports simple substitution in aliases; other shells' aliases can be considerably more complicated. However, the same effect can be achieved in bash by using shell functions. For example:

lm() { /bin/ls -Flag $* | /bin/more }

... but shell programming is a large topic on its own.
History
Most shells (except the truly ancient, such as the original Bourne shell), have some kind of history capability. That is, they can remember the last n commands you entered, and allow you to retrieve and/or modify them for reuse. The last m commands are also saved between shell sessions.

Bash supports two different kinds of history. One comes from its use of the GNU `readline' library. This allows one to scroll up and down the history, searching, copying, modifying, etc. using emacs-like (or vi-like if you prefer) key bindings.

The other is similar to the history expansion provided by `csh' and its derivatives. Some examples:

!! The previous command
!-5 The fifth last command
!372 Command number 372
!foo The last command starting with `foo'
!?bar? The last command containing the string `bar'
^foo^bar The previous command, with `foo' replaced by `bar'
!^ The first argument of the previous command
!$ The last argument of the previous command
!* All the arguments of the previous command
!?foo?:3:h:gs/bar/baz/ Argument 3 of the last command containing the string `foo' with the trailing pathname component stripped off and all occurrences of `bar' replaced by `baz'

The current history list can be displayed with the `history' command.
Completion
Most modern shells allow some form of 'name completion'. In its basic form, it allows the user to type in a partial command or file name, and have the shell attempt to complete it for them. Bash's standard completion facilities can be invoked by hitting the `tab' key at any point on the command line. If the completion is unique, it is added to the command line. Otherwise, as much as possible is completed; hitting tab again results in a list of possible completions being printed.

Bash tries to be smart about its completion. If the word being completed starts with `$', it tries completing it as a shell variable. If it starts with a `~', it tries completing it as a user name. If it starts with a `@', it tries completing it as a host name. When appropriate, it tries completing it as a command (including aliases and functions). When all of the above don't work, it tries filename completion. (Note that there are key bindings for doing all of the above specifically, including just printing the options rather than performing the completion.)
Globbing (pathname expansion)
Expansion of wildcards (`?', `*', etc.) is usually performed by the shell in Unix-like operating systems. This means they are treated consistently across all programs. Some examples:

* All files (except those starting with `.')
foo*bar All files starting with `foo' and ending with `bar'
ba? All three-character files starting with `ba'
foo?*bar All files starting with `foo' and ending with `bar' with at least one character between them
[A-Z]* All files starting with a capital letter
*.[ch] All files ending in `.c' or `.h'
*[^0-9] All files which don't end in a number

If the pattern matches at least one file, it is replaced by the matching file(s) (in sorted order). If there are no matches, the pattern is left as it is.

Related to the above is `brace expansion', though this does not match against files (unless wildcards appear in the result). Examples:

a{b,c,d}e Expands to `abe ace ade'
/usr/{bin,lib,man} Expands to `/usr/bin /usr/lib /usr/man'
/usr/{,local/}{bin,lib,man} Expands to `/usr/bin /usr/lib /usr/man /usr/local/bin /usr/local/lib /usr/local/man'
Redirecting input and output
Normally the shell takes the input for the program from the 'keyboard', and sends the results to the 'screen' (loosely speaking). Bash (and other shells derived from the Bourne shell) has quite sophisticated means for controlling where input comes from and where output goes to, but most of this power is overkill for most interactive use. Here's some relatively simple examples:

foo > bar Redirects the output of `foo' to the file `bar'
foo 2> bar Redirects the error output of `foo' to the file `bar'
foo >> bar Appends the output of `foo' to the file `bar', rather than clobbering it
foo < bar Causes `foo' to read its input from the file `bar'
foo | snafu Takes the output of `foo' and feeds ('pipes') it into `snafu' as input

The `2' in `2>' above refers to a `file descriptor'. Standard file descriptor numbers:

0 Standard input
1 Standard output
2 Standard error

You can also 'copy' file descriptors:

foo 2>&1 Sends the error output to the same place as the standard output (useful for sending both to the same place)

Redirections can be combined, but the order can be important:

foo > bar 2> baz Redirects the output of `foo' to the file `bar', and the error output to the file `baz'
foo > bar 2>&1 Redirects the output of `foo' to the file `bar', and then redirects the error output to the same place
foo 2>&1 > bar Redirects the error output to where the standard output (was) going, and then redirects the standard output (only) to `bar'
foo &> bar Same as `foo > bar 2>&1' (short-cut)
foo 2>&1 | snafu Pipes both the standard output and the error output of `foo' into the input of `snafu' (the pipe redirection is always done first, so when the error output is sent to the same place as the standard output, the standard output is already being sent to the pipe)
Quoting
Some characters have special meaning to the shell:

| & ; ( ) < > $ ` ' ' \ space tab

These have to be 'quoted' if they are not intended to be interpreted by the shell. One way to do this is to precede the character by a backslash (\). Another way is to enclose all or part of a string within quotation marks. Note that the different quotation marks have different meanings.

'...' Everything within the string is kept verbatim
'...' Most things kept verbatim: dollar ($) and backquotes (`) still special
`...` Not to be confused with '...'! This executes the enclosed string as if it were a command and replaces it with the command's output

Compare the following commands:

echo 'rm -rf *' ; sleep 5
echo `rm -rf *` ; sleep 5

Miscellaneous useful commands
pwd Print the current directory
pushd 'Push' the current directory onto the directory stack and change to another directory
popd 'Pop' the current directory off the directory stack
dirs Print the directory stack
tee Copy its input to a file as well as printing it on standard output
echo Print its arguments on standard output
For more information
The `man' page for bash is big and daunting, but it is comprehensive, and quite good compared to many. Pipe it into less or something (`man bash | less') so you can scroll around easily and perform simple searches.

If you're familiar with `info' or `emacs', you may also like to look at the info page (`info bash').

O'Reilly have a book on bash, `Learning the bash Shell' (2nd ed), but I've not seen it so can't really comment.

There are no doubt many net resources around. As an undergrad, I found Zoltan Somogyi's lectures on shell programming quite useful. He has some lecture notes available (slide set #2), as well as some sample shell scripts.


– Enviado usando a Barra de Ferramentas Google"

segunda-feira, 7 de março de 2011

Logical Volume Manager (LVM) Commands for AIX

Logical Volume Manager (LVM) Commands for AIX: "– Varios comandos para trabalhar com o volume manager do AIX."

Manipulando reserva de blocos em sistemas ext3 e ext4

Este é um belo assunto, e que me “iludiu” por muito tempo. Alguém já reparou que sistemas de arquivos ext3 e ext4 com 100% de uso nunca igualavam-se ao tamanho total da unidade ? Explico:

Um sistema de arquivos em um device de 249Gb atingirá 100% de uso aos seus 236Gb. Isso se dá pelo simples motivo que por default, um sistema de arquivos criado via mkfs.ext3 ou mkfs.ext4 possui uma reserva de 5% de seus blocos para o superusuário (vulgo root). Isso pode não ser impactante em sistemas de arquivos pequenos, tais como /var, /usr, /tmp, etc, mas vai com certeza se tornar um inconveniente em um sistema de arquivos de 750Gb usado separadamente do S.O (isso nos custaria 37.5Gb).

Então vamos ao que interessa… Vamos alterar esta reserva de um sistema de arquivos montado e funcional utilizando o tune2fs. No exemplo que segue alterei minha partição de uso pessoal, de 119Gb para ter somente 1% de reserva. Isso me deu um ganho de 5.4Gb.

ext4 com 5% de reserva:

[frank@vostrolab2 tmp]$ df -h /u
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg01-u 119G 78G 35G 69% /u

Vamos à alteração:

[root@vostrolab2 tmp]# tune2fs -m 1 /dev/mapper/vg01-u

tune2fs 1.41.12 (17-May-2010)
Setting reserved blocks percentage to 1% (314572 blocks)

Vejamos o resultado:

[root@vostrolab2 tmp]# df -h /u
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg01-u 119G 78G 40G 67% /u