Archive for the bash Category

pacotes no slackware, parte 1: pkgtools

Posted in bash, slackware, sysadmin with tags , , , , , , , , , , on 23-02-2009 by sirboderafael

o Slackware possui uma visao extremamente simplista de tudo, e como era de se esperar, nao seria diferente com seus pacotes…

irei explicar, atraves exemplos praticos, como funciona seu gerenciamento de pacotes…

vamos verificar a primeira das ferramentas, o pkgtool:
root@bodacious:/home/bode# pkgtool

as opcoes que ele nos oferece sao:

  • Current: se voce tem pacotes alojados no diretorio de onde chamou o pkgtool, ele os identifica e, pacote por pacote, vai perguntando se deve ou nao instalar no sistema
  • Other: busca os pacotes a serem instalados, mas que estejam localizados em outro diretorio, que no caso, voce deve informar… se comporta assim como Current, durante a identificacao e instalacao dos pacotes
  • Floppy: assim como em Current e Other, busca por pacotes a serem instalados, mas espera que estejam localizados dentro de um disquete…
  • Remove: exibe uma lista contendo todos seus pacotes instalados, onde voce pode marcar quais serao removidos (utilizando a barra de espacos) e com certeza os que estiverem marcados irao virar poeira cosmica, caso deseje…
  • View: exibe a lista com todos os pacotes que estao instalados no sistema, mas seu diferencial eh que permite visualizarmos tanto a descricao completa de um pacote quanto quais sao os arquivos contidos no mesmo (junto de sua localizacao no sistema)
  • Setup: opcao interessante… permite executar novamente os scripts de configuracao que sao rodados durante a instalacao do sistema… soh para exemplificar, temos scripts que configuram a rede, o mouse, quais serao os servicos ativados por padrao… etc…
  • Exit: adivinha? sim… ele sai do pkgtool =)

veremos destas opcoes, somente a que visualiza as coisas, por ser algo mais intuitivo de se fazer logo de cara, ao inves de remover ou instalar alguma coisa… para isso, selecione View e observe a tela contendo a listagem de pacotes:

malandramente, irei conduzir as coisas para nosso proximo passo, mostrando um pouco de como as coisas funcionam por dentro… para isso encontre na lista um pacote chamado pkgtools-12.1.0-noarch-7… sim, se voce apertar o “p”, ele jah posiciona a seleçao da lista para onde existem pacotes cujo nome começa com a letra “p”… =) assim que encontra-lo, de um OK e daremos uma passada rapida pelas informacoes que obtemos com isso:

como pudemos observar, existem algumas seçoes distintas, dentre as quais PACKAGE DESCRIPTION e FILE LIST sao, para nos, as mais importantes no momento…

logo de cara olhando na lista de arquivos, podemos identificar que o proprio pkgtool faz parte desse pacote, o pkgtools… hummm, interessante… vemos tambem que existem mais scripts alem do pkgtool, os quais possuem nomes muito sugestivos, tendo como principais figuras estes caras:

  • installpkg: instala novos pacotes
  • upgradepkg: faz o upgrade de um pacote instalado no sistema para um pacote mais novo, substituindo os arquivos contidos no antigo pacote pelos arquivos contidos no novo pacote
  • removepkg: serve para remover pacotes
  • explodepkg: nao, nao eh um comando explosivo, sua funçao eh simples e direta… descompacta o conteudo de todos os pacotes (compativeis com o padrao do Slackware, que eh .tgz == tar + gz) informados para o diretorio corrente… avisa se algum script de instalaçao foi encontrado nesse pacote apos descompacta-lo…
  • makepkg: muito bacana este utilitario… ajuda a montarmos nosso pacote, que ja deve estar com sua hierarquia montada corretamente dentro de um diretorio, apos sua compilaçao ter sido bem sucedida, obviamente… =)

a parte mais legal de tudo isso eh realmente utilizar esses utilitarios de linha de comando, afinal nos somos slackers ou sacos de batatas? …nao responda! hahahaha!

como nosso exemplo pratico de uso, vamos utilizar o htop de cobaia… trata-se de uma versao “mais completa”, “mais rock-n-roll”, e que na minha opiniao, eh mais legal que o top, que jah vem instalado no sistema…

baixaremos do Linux Packages, uma versao do htop que esta defasada, para primeiro treinarmos como funciona o processo de instalaçao, usando o installpkg… depois, iremos atualiza-lo para a versao corrente (pelo menos, ateh a data de publicaçao deste post, eh claro) disponivel no portal italiano Slacky, com o upgradepkg… no final das contas, acionaremos o removepkg que ira manda-lo diretamente para o Pelé… nao restando instalado em nosso sistema, apos este exercicio, um arquivo sequer, proveniente deste teste…

obs.: sim, eu sei que ele eh um pacote de Slackware 12.1 e estamos na versao 12.2, mas este eh apenas um exercicio onde jah averiguei a compatibilidade de versoes entre os pacotes… vai ser mais legal assim, acredite… qualquer coisa, voce vai sentir o removepkg necessario, alem de achar da hora a maneira que o upgradepkg atualiza os pacotes…

vamos lah, em seu diretorio de pacotes, ou em qualquer outro que queira, baixe o htop defasado e renomeie o bicho para que tenha o final .tgz, senao o installpkg nao vai rodar direito com ele, caso voce esteja com o Slackware 12.2 instalado, assim como eu:

bode@bodacious:~/pacotes$ wget http://mirror.slackwarebrasil.org/linuxpackages/Slackware/Slackware-12.1/Console/htop/htop-0.8-i486-1ant

bode@bodacious:~/pacotes$ mv htop-0.8-i486-1ant htop-0.8-i486-1ant.tgz

agora sim… vamos instalar essa bagaça velha?

root@bodacious:/home/bode/pacotes# installpkg htop-0.8-i486-1ant.tgz

beleza na represa… se tudo correu bem, sua saida foi bem parecida como esta:

Installing package htop-0.8-i486-1ant...
PACKAGE DESCRIPTION:
htop: htop 0.8
htop:
htop: This is htop, an interactive process viewer for Linux.
htop:
htop: Package Created By: Anton Dobkin
Executing install script for htop-0.8-i486-1ant...

agora que sabemos como se instala (viram como foi facil?) pacotes, veremos como se atualiza pacotes…

baixe a versao corrente do htop, ainda em seu diretorio de pacotes…

bode@bodacious:~/pacotes$ wget http://repository.slacky.eu/slackware-12.2/hardware/htop/0.8.1/htop-0.8.1-i486-2sl.tgz

mande um upgradepkg no danado para ver que belezinha!
root@bodacious:/home/bode/pacotes# upgradepkg htop-0.8.1-i486-2sl.tgz

se tudo correu bem, sua saida foi essa:

+==============================================================================
| Upgrading htop-0.8-i486-1ant package using ./htop-0.8.1-i486-2sl.tgz
+==============================================================================

Pre-installing package htop-0.8.1-i486-2sl...

Removing package /var/log/packages/htop-0.8-i486-1ant-upgraded-2009-02-23,18:31:13...
--> Deleting /usr/doc/htop-0.8/AUTHORS
--> Deleting /usr/doc/htop-0.8/COPYING
--> Deleting /usr/doc/htop-0.8/ChangeLog
--> Deleting /usr/doc/htop-0.8/INSTALL
--> Deleting /usr/doc/htop-0.8/NEWS
--> Deleting /usr/doc/htop-0.8/README
--> Deleting /usr/doc/htop-0.8/TODO
--> Deleting /usr/share/man/man1/htop.1.gz
--> Deleting empty directory /usr/doc/htop-0.8/

Installing package htop-0.8.1-i486-2sl...
PACKAGE DESCRIPTION:
htop: Htop (Process Viewer)
htop:
htop: This is htop, an interactive process viewer for Linux. It is a text-mode
htop: application (for console or X terminals) and requires ncurses.
htop: Tested with Linux 2.4 and 2.6.
htop:

Package htop-0.8-i486-1ant upgraded with new package ./htop-0.8.1-i486-2sl.tgz.

viu soh? divertido saber que o upgradepkg reconheceu que estamos lidando com uma versao mais nova do pacote htop e substituiu os arquivos velhos pelos novos… ele olha o nome dos pacotes (que devem ser iguais e no nosso caso eh htop mesmo), depois ele olha o numero da versao entre os pacotes… caso os numeros de versao sejam iguais, ele ira decidir qual eh o pacote mais novo baseando-se no numero da compilacao do mesmo, que no caso, em nosso novo pacote chama-se: 2sl… e se estivessemos com htop 0.8.1 instalado e sua versao de compilaçao fosse 1sl, este seria substituido da mesma maneira como foi substituido, pois o upgradepkg iria saber como proceder…

prontos para remover nosso recem-instalado pacote, htop?

ah, se fosse voce dava uma olhadinha esperta no htop para ver como ele eh… tah ai um utilitario legal:

bom, se mesmo assim voce estiver realmente empenhado em metralhar o infeliz, basta fazer o seguinte com o coitado:

root@bodacious:/home/bode/pacotes# removepkg htop

a saida da remoçao eh a seguinte:

Removing package /var/log/packages/htop-0.8.1-i486-2sl...
Removing files:
--> Deleting /usr/bin/htop
--> Deleting /usr/doc/htop-0.8.1/COPYING
--> Deleting /usr/doc/htop-0.8.1/INSTALL
--> Deleting /usr/doc/htop-0.8.1/NEWS
--> Deleting /usr/doc/htop-0.8.1/README
--> Deleting /usr/doc/htop-0.8.1/htop.SlackBuild
--> Deleting /usr/doc/htop-0.8.1/slack-desc
--> Deleting /usr/man/man1/htop.1.gz
--> Deleting /usr/share/applications/htop.desktop
--> Deleting /usr/share/pixmaps/htop.png
--> Deleting empty directory /usr/doc/htop-0.8.1/

chegamos facilmente a conclusao de que as funcoes do pkgtool sao baseadas em varios scripts independentes… e realmente, lidar com pacotes no Slackware eh algo simples de se fazer… ao contrario do que reza a lenda em alguns cantos sombrios da web…

ainda nao falei sobre os problemas de resoluçao de dependencias entre pacotes, pois pretendo escrever isso em um futuro post…

sendo o primeiro da saga, acredito que esteja de bom tamanho o que vimos ateh agora e em breve estaremos destrinchando as inumeras possibilidades e assuntos relacionados ao gerenciamento e criacao de pacotes para o Slackware! ufa! =D

sussa na montanha russa galera?
[]’s!
t++!

Anúncios

tunelamento ssh direto no proxy com o corkscrew

Posted in bash, seguranca, sysadmin with tags , , , , , , , , , , , , , , , , on 21-02-2009 by sirboderafael

vamos supor que seu administrador de rede nao seja um cara legal… e que por isso ele passou a permitir somente o trafego de dentro pra fora na porta 80, ou 8080, como se faz normalmente quando se tem um proxy…

soluçao? hahahaha! nada de utilizar programinhas amadores para fazer isso… vamos “sacar essa rolha” logo… apresento a voces meu mais novo amigo, conhecido como corkscrew!

sem mais delongas, vamos ao que interessa… baixe logo essa paçoca!
bode@bodacious:~/pacotes$ wget http://www.agroman.net/corkscrew/corkscrew-2.0.tar.gz

extraia:
bode@bodacious:~/pacotes$ tar vxzf corkscrew-2.0.tar.gz

entre no diretorio onde ele foi extraido e faça o “metodo padrao” para compilar seu pacote:

bode@bodacious:~/pacotes$ cd corkscrew-2.0
bode@bodacious:~/pacotes/corkscrew-2.0$ ./configure && make

se deu tudo certo, o make apos compilar o corkscrew, gerou um binario cujo nome eh… adivinha? corkscrew!

voce tem duas opcoes agora, ou criar seu pacote ou instala-lo dentro de seu filesystem… vou adotar a maneira mais simples que é instalar direto do filesystem, afinal, é um binariozinho de nada e nao um catatau de arquivos, mas quem quiser, basta fazer o pacote como descrito aqui. Claro, o link trata da criaçao de um pacote para Slackware Linux

instalando no filesystem (ira cair em /usr/local/bin):
root@bodacious:/home/bode/pacotes/corkscrew-2.0# make install
observaçao: sim, estou ciente que /usr/local/bin nao eh o local padrao de instalacao no Slackware (/usr/bin), no entanto estou somente “copiando” um unico binario para lah, ou seja, nao estou instalando um pacote inteiro, portanto eh perfeitamente aceitavel coloca-lo neste local, pois assim ele irah se diferenciar dos demais, “gerenciados pelo sistema”, e se voce quiser pode simplesmente remove-lo “na unha”, isso nao ira prejudicar seu sistema….

utilizando o corkscrew:
beleza, ele ja esta instalado em seu sistema, entao para realizarmos o tal do tunelamento via proxy basta configurar alguns aspectos de seu cliente de SSH:

arquivo ~/.ssh/conf.ssh/config:
adicione as seguintes linhas:

Host *
ProxyCommand corkscrew seu-proxy-http 8080 %h %p

teste:
root@bodacious:/home/bode/pacotes/corkscrew-2.0# ssh usuario@host.com

se rolar certinho, maravilha! mande um Pedro de Lari que esta tudo de boa e voce pode viver como se as regras de firewall para ssh nao existissem…

meu proxy requer autenticacao: entao voce precisa alterar o arquivo ~/.ssh/conf.ssh/config para que fique como:

Host *
ProxyCommand corkscrew seu-proxy-http 8080 %h %p ~/.ssh/proxyauth

crie o arquivo ~/.ssh/proxyauth com o seguinte conteudo:

usuario:senha

e agora sim voce pode mandar um Pedro de Lari nessas restricoes que soh nos atrapalham!

segundo o site do projeto, o corkscrew funciona para os seguintes proxys:

  • gauntlet
  • cacheflow
  • junkbuster
  • apache’s mod_proxy
  • squid

eu particularmente, testei no squid e funcionou na maior tranquilidade!

[]’s a todos!
t++!

monitorando os sensores instalados com o ‘lm_sensors’

Posted in bash, kernel, sysadmin with tags , , , , , on 06-11-2008 by sirboderafael

falhas de hardware podem acontecer por diversos motivos, mas temos a opcao de monitorar o sistema e tomar as providencias quando necessario.

as informacoes de monitoramento de sensores chegam ateh nos devido a captura de seus status, o que eh fornecido por alguns modulos que sao carregados junto ao kernel mas que muitas vezes nao estao rodando…

assumindo que em seu sistema ja encontra-se devidamente instalado o pacote lm_sensors, partiremos para sua configuracao…

o primeiro passo, consiste em detectar quais modulos seu kernel deve carregar… isso obviamente depende do hardware instalado e se este oferece a capacidade de ser monitorado…

para isso, execute no shell o utilitario sensors-detect com uma conta privilegiada:
bode@bodacious:~$ sudo sensors-detect

ele ira perguntar quais partes de seu hardware deverao serao escaneadas, responda Yes para as que achar importantes… essa eh a maneira tipica de se perguntar qual o hardware em questao que deve ser escaneado:


This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.


We can start with probing for (PCI) I2C or SMBus adapters.
Do you want to probe now? (YES/no):

considere escanear completamente seu hardware e responda Yes para todos os testes… sao muito raros os casos onde pode ocorrer alguma falha durante a execucao dos testes…

ao final da deteccao, sera gerado um arquivo de configuracao em /etc/sysconfig/lm_sensors, que contem os nomes dos modulos que devem ser carregamentos no kernel…

uma vez gerado o arquivo, voce eh lembrado que os modulos devem ser carregados atraves de um script de inicializacao, que no caso pode ser tanto /etc/init.d/lm_sensors.init (RedHat’s) quanto /etc/rc.d/rc.lm_sensors (Slack’s)… no entanto, eh comum nao se encontrar esse script instalado na raiz do sistema, mesmo que o pacote lm_sensors esteja instalado… neste caso faca o download do script e o armazene em /etc/rc.d/rc.lm_sensors (esse eh o padrao do Slack, adapte ele para o local onde sua distro o organizaria normalmente)… e nao se esqueca de marca-lo como executavel:
bode@bodacious:~$ sudo chmod +x /etc/rc.d/rc.lm_sensors

coloque a seguinte entrada no arquivo /etc/rc.d/rc.local:
/etc/rc.d/rc.lm_sensors
assim, durante a proxima inicializacao do sistema, logo que o rc.local rodar, tambem serao carregados os modulos que foram detectados… a vantagem desse script eh a separacao do instante de carregamento com relacao aos dos demais modulos… observe que nele uma serie de checagens especiais sao realizadas antes do carregamento de cada modulo (atraves de um processo iterativo), o que certamente nos pouparia de eventuais distracoes se nossa escolha fosse carrega-los diretamente com o modprobe

agora, assumindo que os modulos estao carregados apos uma reinicializacao, ou simplesmente pela execucao de nosso novo script, podemos monitorar o status dos sensores executando:
bode@bodacious:~$ sensors

voce ira obter informacoes do tipo:

Adapter: SMBus ALI1535 adapter at e800
VCore 1: +1.73 V (min = +1.49 V, max = +1.90 V)
VCore 2: +1.74 V (min = +1.49 V, max = +1.90 V)
+3.3V: +3.26 V (min = +2.96 V, max = +3.63 V)
+5V: +5.03 V (min = +4.49 V, max = +5.51 V)
+12V: +12.04 V (min = +9.55 V, max = +14.41 V)
-12V: -2.03 V (min = -4.07 V, max = -0.32 V)
-5V: -5.39 V (min = -1.76 V, max = -0.82 V)
fan1: 0 RPM (min = 61363 RPM, div = 2)
fan2: 3479 RPM (min = 18243 RPM, div = 2)
fan3: 0 RPM (min = 56250 RPM, div = 2)
M/B Temp: +31°C (high = +21°C, hyst = +6°C)
CPU Temp: +32.0°C (high = +100°C, hyst = +92°C)
temp3: -0.5°C (high = +80°C, hyst = +75°C)
vid: +1.700 V (VRM Version 8.2)
alarms:
beep_enable:
Sound alarm enabled

dessa maneira, eh possivel realizar o monitoramento dos sensores instalados em seu hardware via shell e se for o caso, pode ser instalado algum monitor grafico dessas mesmas informacoes de status e deixa-lo rodando no desktop para uma maior comodidade…

pipes e redirecionamento de entrada/saida

Posted in bash with tags , , , , , , , , , on 20-04-2008 by sirboderafael

iremos verificar o funcionamento dos pipes e dos redirecionamento de entrada/saida de uma maneira simples e guiada por exemplos praticos.

em sistemas unix-like, eh comum utilizar-se de pipes para concatenar a saida de um programa imediatamente na entrada de outro programa…

quando executamos o comando:
bode@bodacious:~$ dmesg

gera uma saida de ~20KB em alguns sistemas… o que eh o suficiente para que do texto exibido tenhamos informacoes iniciais perdidas, pois mesmo rolando o texto todo para cima (com varios shift+page_up’s seguidos) notamos que faltam muitas das informacoes iniciais (caso nosso terminal suporte um buffer menor que o tamanho da saida retornada)…

entao uma boa maneira de visualizar todo o conteudo da saida do comando dmesg eh atraves da utilizacao de um pipe para um visualizador de textos que aceite uma streaming de dados como entrada:

bode@bodacious:~$ dmesg | most

ira fazer com que a saida do comando dmesg seja visualizada no most, onde podemos rolar o texto livremente e sem perda de informacoes…

curiosidades:
(1) o caractere | eh comumente lido como pipe
(2) o conceito de ter um ‘cano’ ligando a saida de um comando na entrada de outro comando foi criado por douglas mcIlroy e implementado no unix por ken thompson em 1973;
(3) quando a saida de um programa eh produzida, uma quantidade de dados deve ser absorvida pela entrada do outro programa concatenado pelo pipe e assim sucessivamente (caso esteja trabalhando com mais de dois programas ‘concatenados’), no entanto esta saida nao deve ser maior que o buffer (ou fila) de entrada do programa que ira recebe-la… o sistema se encarrega de cuidar disso caso o buffer de entrada se preencha, a execucao do programa que gera a saida eh suspensa e soh eh retomada assim que o buffer de entrada possa receber mais dados… ou seja, o escalonador de processos marca o processo como bloqueado ateh que este esteja apto a assumir o estado de pronto novamente… isso eh muito bacana =)
(4) quando falamos em saida-padrao de um programa nos referimos a stdout e similarmente quando falamos em entrada-padrao de um programa nos referimos a stdin;
(5) quando um erro eh disparado, este eh gerado em sua stderr, abordaremos seu uso mais adiante…

os pipes nao sao limitados a exemplos banais como este, eles podem ser utilizados para se filtrar a saida de um determinado comando quando utilizados em conjunto com algum comando da familia grep por exemplo:

bode@bodacious:~$ ps -A | fgrep swift
2821 ? 00:00:00 swiftfox
2830 ? 00:09:58 swiftfox-bin

fez com que a saida do comando ps -A fosse filtrada pelo comando fgrep em busca da palavra swift (estava realmente executando o swiftfox em meu sistema enquanto editava este post e recebi o numero dos processos gerados relacionados ao mesmo)

ha uma maneira de pipe que consiste em executar um determinado comando dentro de outro comando, passando para o ultimo sua saida, onde eh possivel absorver estes dados de alguma maneira:
bode@bodacious:~$ for diretorio in `ls -1 /home`; do echo "diretorio: ${diretorio}"; done

faz com que todos os diretorios dentro do diretorio /home sejam listados com a palavra diretorio em sua frente… isso eh possivel pois iteramos sobre cada ‘diretorio’ atraves da captura da saida do comando ls -1 envolvido por aspas invertidas ``

existem outras formas de se realizar pipes e estamos entrando em um conceito chamado redirecionamento de entrada/saida… assim como os pipes concatenam o fluxo de dados proveniente da saida de programas com a entrada de outros programas, podemos por exemplo redirecionar a saida de um programa para um arquivo… ou entao capturar os dados de um arquivo e enviar os mesmos para a entrada de um programa:
bode@bodacious:~$ cat /proc/cpuinfo >> ~/status /proc/meminfo >> ~/status

temos que a saida dos comandos cat foram redirecionadas para o arquivo status de maneira que seus conteudos foram concatenados um apos o outro atraves do operador >>
note: mesmo que o arquivo nao exista ele sera criado… caso exista, o conteudo redirecionado sera concatenado imediatamente apos as demais informacoes ja gravadas no interior do arquivo;

tambem podemos capturar informacoes sobre as flags que a cpu instalada em nosso sistema suporta, caso utilizemos:
bode@bodacious:~$ fgrep flags /proc/cpuinfo | cut -f 3 | cut --complement --delimiter=":" -f 1 | uniq > descricao-cpu

observacoes:
(1) a saida do comando eh direcionada ao arquivo descricao-cpu
(2) a diferenca basica entre utilizar o operador >> ao inves de utilizar o operador > para o redirecionamento de saida dos programas consiste em:
>> concatena a saida ao final do arquivo especificado, caso este nao exista ele sera criado, similar ao modo append de escrita em arquivos comumente encontrado em grande parte das linguagens de programacao
> simplesmente descarrega a saida para o arquivo especificado… tambem cria o arquivo caso este nao exista e no caso de existir, sobrescreve todo seu conteudo pela saida do programa que precede seu uso

tambem temos o caso de quando queremos efetuar o direcionamento de algum arquivo para um programa… exemplo classico que abre um streamming de dados do arquivo /proc/meminfo para o programa cat:
bode@bodacious:~$ cat < /proc/meminfo

agora uma mistura entre pipe e redirecionadores de entrada/saida:
bode@bodacious:~$ cat < /proc/modules | sort > informacoes

le o arquivo /proc/modules atraves do redirecionador de entrada < e o programa cat, passa a saida para a entrada do programa sort atraves do pipe | que armazena as informacoes geradas no arquivo informacoes atraves do redirecionador de saida >

aproveitando que estamos tratando do termo redirecionador de saida devemos saber que existem duas saidas que sao frequentemente utilizadas: stdout e stderr:

stdout nos lembra algo relacionado a saida ja que seu proprio nome eh standard output… eh utilizada pelos programas para imprimirem mensagens na saida padrao… ja viu em alguns lugares que a impressora pode ser sua saida padrao? pois eh, ela pode… mas somente caso queira, porque o padrao eh que seja em seu terminal (ou console) por motivos bem obvios =)
nos referenciamos a este descritor de arquivo (este eh o termo correto) por um numero que no caso eh 1

bode@bodacious:~# /etc/rc.d/rc.httpd start > saida_httpd 2>&1
ira iniciar o servidor apache enviando sua saida para o arquivo saida_httpd e os eventuais erros serao redirecionados para a saida padrao:
2 eh o numero do stderr que eh redirecionado para &1, a saida-padrao stdout (o simbolo & funciona aqui como um meio de referenciarmos a saida-padrao)…. eh interessante notar que se nao tivessemos feito isso, os erros nao seriam reportados no mesmo meio que a saida-padrao (no caso, redirecionada para o arquivo saida_httpd)… nao que todos os erros devam ir para a saida padrao soh porque eu queira… no entanto um bom exemplo de quando isso se faz util eh o caso de estarmos analisando em conjunto a saida que um programa produz junto de suas mensagens de erro…

podemos facilmente ter uma versao modificada do comando anterior, onde stdout e stderr sao redirecionadas para arquivos distintos saida_httpd e erros_httpd respectivamente:
bode@bodacious:~# /etc/rc.d/rc.httpd start 1>saida_httpd 2>erros_httpd

sim… se voce acompanhou a conclusao do funcionamento destes descritores de arquivo, provavelmente chegou a conclusao (ou nao…) de que < eh uma abreviacao de <0… sim, isto eh verdade, o descritor de arquivo 0 equivale a stdin (standard input) que naturalmente eh a entrada para nosso programa a ser executado… podemos brincar bastante com as entradas, no entanto na maioria esmagadora das vezes utilizamos somente os pipes e os redirecionadores de saida… entao chega de fritacao por enquanto!!! =D

bom, pra terminar listei abaixo algumas referencias que utilizei para pesquisa e que podem ateh quem sabe clarificar alguma coisa que passou batido:
http://en.wikipedia.org/wiki/Pipeline_(Unix)
http://www.december.com/unix/tutor/pipesfilters.html
http://www.livefirelabs.com/unix_tip_trick_shell_script/june_2003/06092003.htm
http://www.softpanorama.org/Scripting/pipes.shtml