Jump to content
  • Criando um media server com Debian

       (1 review)

    Configurar um servidor de mídia pode ser uma boa maneira de aproveitar um PC de baixo desempenho (mas de razoável capacidade de armazenamento). Além de centralizar suas músicas, fotos e vídeos, torná-los acessíveis a dispositivos como smart TVs, smartphones, tablets, video games e outros que possam atuar como clientes de streaming é realmente interessante.

    Tudo que precisamos para configurar este servidor é de uma LAN ou WLAN e o Debian GNU/Linux. Sem complicação, sem custo.

    Configurar o Debian com IP fixo

    No media server, configuramos um Debian Wheezy com IP fixo. A máquina que eu utilizei acessa a WLAN através de um adaptador wireless USB, então eu coloquei uma reserva de IP (através do MAC address) no próprio roteador wireless, fazendo com que o mesmo IP seja entregue ao servidor, mas você configurar de acordo com a topologia da sua rede. A configuração de IP no Debian fica em /etc/network/interfaces. Lembrando que não precisamos de ambiente gráfico.

    Criando o diretório de mídia

    Tendo o IP, é hora de criar um diretório que mídia que vai armazenar seus arquivos. Escolhi /home/share, mas poderia ser qualquer outro. Dentro dele vamos criar diretórios separados para, por exemplo, filmes, shows e músicas:

    $ sudo mkdir -p /home/share/{filmes,shows,mp3}

    Eu optei por não compartilhar fotos por questões de privacidade.;)

    Agora é hora de colocar arquivos nos diretórios, de modo a popular o media server. Para poder gerenciar os arquivos sem privilégios de root, é interessante tornar seu usuário comum dono do diretório share. No meu caso, o nome de usuário é fernando:

    $ sudo chown -R fernando: /home/share

    Certifique-se de que os arquivos e diretórios possuem permissões para serem visualizados, mas nada de 777 hein. Se necessário, aplique as permissões padrão neles:

    $ find /home/share -type d -exec chmod 0755 {} ;
    $ find /home/share -type f -exec chmod 0644 {} ;

    Instalando e configurando o minidlna

    O minidlna [1] é um servidor de mídia para clientes DLNA/UPnP. Resumidamente, enquanto o UPnP é um conjunto de protocolos que permitem dispositivos compatíves se encontrarem numa rede (auto-discovery), o DLNA é um serviço que utiliza UPnP para streaming de mídia. Algumas pessoas preferem usar o MediaTomb, que tem mais recursos que o minidlna, mas este último é bem modesto e simplista.:)

    Para instalar é bem difícil:

    $ sudo apt-get install minidlna

    Após a instalação, vamos configurar três parâmetros em /etc/minidlna.conf:

    media_dir=/home/share
    root_container=B
    friendly_name=Debian Home Server

    A opção root_container=B faz com que os dispositivos vejam os três diretórios que criamos abaixo de /home/share, por padrão. Eu configurei assim porque não gosto de localizar mídia por artista, gênero, ano etc já que não mantenho tags IDv3 e similares atualizadas. Se não é o seu caso, pode comentar essa opção para que ela seja configurar com seu valor padrão.

    Em friendly_name você configura um nome pelo qual os dispositivos clientes reconhecerão seu media server.

    E por fim, a única opção realmente necessária para o servidor entrar em funcionamento, media_dir, define qual o diretório raiz de mídia.

    Após salvar o arquivo, é preciso forçar que o banco de dados de mídia (em /var/lib/minidlna) seja recriado:

    $ sudo /etc/init.d/minidlna force-reload

    Por padrão, as portas UDP 1900 e TCP 8200 são utilizadas. Se você configurou um firewall no servidor, deve liberá-las.

    Isto é tudo que você precisa fazer para ter um media server funcional. Vamos agora para o lado cliente.

    Usando clientes no Linux e Windows

    Em minha humilde opinião, tá pra nascer um player melhor que o VLC [2]. Além de fazer café, ele é multiplataforma (apt-get install vlc) e age como cliente UPnP tranquilamente. Para isso, instale-o numa máquina que está na mesma rede que o servidor e faça o seguinte:

    • Abra o VLC e vá em “View -> Playlist”.
    • Na navegação do lado esquerdo, expanda “Local Network” e vá em “Universal Plug’n’Play”.

    O friendly_name do seu media server deve aparecer do lado direito em alguns segundos e você já pode começar o streaming.

    vlc.png.4d869863010af3a2d5459dc67e249eec.png

    Usando cliente no Android

    Usuários de smartphones Samsung já possuem um clinte instalado chamado AllShare. Na verdade ele é um servidor também, e você pode compartilhar os arquivos de mídia do seu aparelho na rede, se for de seu interesse.

    O VLC para Android [3]  suporta UPnP, mas os testes foram feitos com uma alternativa para a época que ainda não havia suporte. A ferramenta utilizado foi o UPnPlay [4], que é gratuito e dá conta do recado. Depois de instalar, basta abri-lo e começar o streaming:

    upnplay1.png.8684d698cdeca4f8e14578de51fc6200.png

     upnplay2.png.372c82ac24db897487972cfa560b5e5e.png

    upnplay3.png.e913ad1155d8b4115af71d46eba6619e.png

    upnplay4.png.a3db0d8d128d21577f46b333c475e378.png

     

    Outros clientes

    Qualquer dispositivo compatível com o UPnP na sua rede vai encontrar seu servidor. Smart TVs, DVD/Blu-ray players, video games (como o PS3) e outros. No caso de outros smartphones como iPhone ou Blackberry, pode ser necessário instalar algum aplicativo, mas duvido que seja difícil. Segue uma lista com vários softwares servidores e clientes [5]. Agora não tem desculpa.:)

     

    Referências

    [1] http://sourceforge.net/projects/minidlna/
    [2] http://www.videolan.org/vlc/
    [3] https://www.videolan.org/vlc/download-android.html
    [5] http://en.wikipedia.org/wiki/List_of_UPnP_AV_media_servers_and_clients#Android


    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest

    • This will not be shown to other users.
    • Add a review...

      ×   Pasted as rich text.   Paste as plain text instead

        Only 75 emoji are allowed.

      ×   Your link has been automatically embedded.   Display as a link instead

      ×   Your previous content has been restored.   Clear editor

      ×   You cannot paste images directly. Upload or insert images from URL.



  • Similar Content

    • By Felipe.Silva
      A heap é uma estrutura especial de memória usada pelo processo. O que tem de especial nela é o fato de seu tamanho ser variável, já que sua memória pode ser alocada ou desalocada dinamicamente pelo processo. Isso pode ser feito usando syscalls do sistema operacional e o mesmo é responsável por alocar mais páginas de memória para a seção caso seja necessário.
      No Linux o segmento de dados pode ser aumentado ou diminuído usando a syscall brk, e é esse espaço de memória que os programas normalmente usam para a heap. Em C nós normalmente não usamos a heap diretamente e, ao invés disso, usamos a função malloc() e semelhantes para lidar com a alocação dinâmica de memória. O que alguns não sabem é que na verdade chamadas para a função malloc() ou free() não necessariamente irão resultar na alocação ou desalocação de memória para o processo. Isso se dá porque é a libc quem de fato gerencia a heap e nós não estamos diretamente solicitando ou liberando memória para o sistema operacional.
      *libc é a biblioteca padrão da linguagem C que contém funções essenciais para tarefas básicas como: Manipulação de strings e arquivos, entrada e saída de dados, funções básicas de matemática etc.
      A função malloc(), de acordo com a implementação da glibc, usa o segmento de dados, o dividindo em uma ou mais regiões de memória que eles chamam de “arenas”. A arena principal corresponde à heap original do processo, porém outras arenas também podem ser alocadas para o processo. Inicialmente cada thread criada no processo tem uma arena individual até atingir um certo limite pré-definido de arenas que podem ser alocadas no processo. Atingindo esse limite, as threads posteriores passam a compartilhar a mesma arena. Em cada arena de memória existem divisões da memória que são chamadas de maneira homônima de heap, e são nessas heaps que a função malloc() de fato aloca memória para o usuário da libc.
      Cada bloco de memória que malloc() aloca na heap é chamado de chunk, e cada chunk contém metadados usados pelo sistema interno de malloc para organizar a heap como uma lista duplamente encadeada. Para fins de ilustração, abaixo está a estrutura de um chunk, usada na glibc:
      struct malloc_chunk { INTERNAL_SIZE_T mchunk_prev_size; INTERNAL_SIZE_T mchunk_size; struct malloc_chunk* fd; struct malloc_chunk* bk; /* Only used for large blocks: pointer to next larger size. */ struct malloc_chunk* fd_nextsize; struct malloc_chunk* bk_nextsize; O valor mchunk_prev_size seria o tamanho do chunk anterior e mchunk_size o tamanho do chunk atual. Os ponteiros *fd e *bk são usados somente quando o chunk está livre, e seriam ponteiros usados para a lista circular duplamente encadeada de chunks que apontam para o chunk posterior e anterior, respectivamente. No entanto, essa estrutura não representa muito claramente como o chunk é de fato usado pelo sistema de malloc, na figura abaixo isso é ilustrado com mais precisão.

      O ponteiro que malloc() retorna não aponta para o início do chunk mas sim para o início do espaço de memória que pode ser usado pelo usuário. O tamanho do espaço de memória de um chunk é alinhado pelo tamanho de um double word na arquitetura. Caso malloc() seja chamado passando um tamanho desalinhado como argumento, um espaço extra é alocado para manter o alinhamento. Por exemplo, se o alinhamento está sendo feito para 8 bytes e malloc é chamada com 9 como argumento, malloc irá te devolver um chunk com 16 bytes de espaço de memória usável. Além do alinhamento no tamanho do chunk, também existe um alinhamento no endereço de memória retornado por malloc() que é sempre alinhado para o tamanho de uma word. Isso é feito porque em algumas arquiteturas esse alinhamento de memória é necessário para se evitar uma exceção. Em outras arquiteturas (x86, por exemplo) o alinhamento melhora a performance do processador no acesso à memória.
      Como existe esse alinhamento no tamanho de um chunk isso garante que os três bits menos significativos de mchunk_size não sejam necessários para definir o tamanho do chunk. Se aproveitando disso, os três últimos bits são usados como flags para determinar alguns metadados usados pelo sistema de chunks.

      O bit M indica que o chunk não pertence a nenhuma arena e, ao invés disso, foi alocado dinamicamente em uma memória mapeada. Caso este bit esteja ligado, os outros dois são ignorados. No contexto de um chunk livre este bit está sempre desligado, tendo em vista que a lista encadeada de chunks livres somente se aplica a chunks que estão em alguma arena.
      Os chunks diretamente mapeados na memória (com bit M ligado) são criados para chunks muito grandes. Esses chunks quando liberados com a função free() são imediatamente liberados da memória. Por outro lado, usar free() em um chunk comum não necessariamente irá liberar memória para o sistema operacional. O que free() faz nesse caso é marcar o chunk como livre o adicionando de volta à lista de chunks livres. Assim como é indicado nesse trecho da glibc:
      /* Mark the chunk as belonging to the library again. */ (void)tag_region (chunk2mem (p), memsize (p)); Repare como o comentário descreve a ação como “marcar o chunk como pertencente à biblioteca novamente”, e é efetivamente isso que a função free() faz, não sendo necessariamente uma liberação de memória para o sistema operacional. Inclusive um recurso de otimização que a glibc usa é o que eles chamam de tcache (Thread Local Cache), que se trata de uma lista de chunks existente em cada thread individualmente. Quando você aloca um novo chunk na thread e posteriormente o libera, ele é adicionado ao tcache daquela thread e pode ser reutilizado em uma nova alocação posterior.
      Um adendo que a função free() pode efetivamente liberar memória para o sistema operacional se houver vários chunks livres no topo do segmento de dados (o que raramente acontece). Ela faz isso chamando a função interna systrim(), que por sua vez (no Linux) usa a syscall brk para diminuir novamente o segmento de dados.
      Um detalhe interessante que vale citar aqui é que na glibc (no Linux) existem as funções brk e sbrk que servem como wrappers para aumentar/diminuir o segmento de dados. O sistema de liberação de memória do systrim() espera que essas funções não sejam utilizadas diretamente para poder fazer a liberação de memória apropriadamente. Se você usá-las em seu código por algum motivo, irá “quebrar” o sistema de liberação de memória automático do free(), o fazendo não mais liberar memória quando é usado em chunks de arenas. Logo, não é recomendável que você use essas funções diretamente a menos que você esteja implementando seu próprio sistema de gerenciamento de memória dinâmica.
      O código abaixo é um experimento a fim de vermos na prática os metadados do chunk no Linux:
      // gcc test.c -o test #include <stdio.h> #include <stdlib.h> int main(void) { size_t *content = malloc(8); size_t chunk_size = content[-1] & ~0b111; size_t chunk_flags = content[-1] & 0b111; printf("size: %zu\nflags: %zu\n", chunk_size, chunk_flags); return 0; } No meu Linux é retornado 32 como tamanho do chunk e 1 como flag, indicando que somente o bit P está ligado. Sugiro ao leitor variar o tamanho passado para malloc a fim de comprovar que o alinhamento do tamanho do chunk de fato ocorre. Também sugiro passar um número grande para malloc() a fim de ver a partir de qual tamanho malloc() irá deixar de usar uma arena e irá alocar o chunk com mmap(). Caso isso ocorra o bit M será ligado e o número 2 (decimal) será indicado como flags.
      Nota: Esse código propositalmente não utiliza free() antes de finalizar o programa. É redundante e desnecessário usá-la quando o programa é finalizado, tendo em vista que todas as páginas de memória usadas pelo processo serão liberadas pelo sistema operacional.
      Referências
      https://man7.org/linux/man-pages/man2/brk.2.html https://sourceware.org/glibc/wiki/MallocInternals https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=e2d7b1b58396906375ba0e953a20ac57f0904378;hb=refs/heads/master http://c-faq.com/malloc/freeb4exit.html
    • By Bruna Chieco
      O Cisco Talos, grupo global de inteligência de ameaças de cibersegurança da Cisco, descobriu uma vulnerabilidade de divulgação de informações no kernel do Linux.
      A vulnerabilidade, rastreada como CVE-2020-28588, pode permitir que um invasor visualize a pilha de memória do kernel, o que significa que dados ou informações que não deveriam ser vistas possam ser acessadas. O problema foi visto pela primeira vez pelo Cisco Talos em um dispositivo Azure Sphere (versão 20.10), um dispositivo ARM de 32 bits que executa um kernel do Linux corrigido.
      O kernel do Linux é o núcleo livre e de código aberto dos sistemas operacionais do tipo Unix. A vulnerabilidade existe especificamente na funcionalidade /proc/pid/syscall de dispositivos ARM de 32 bits executando Linux.
      Um invasor pode explorá-la lendo /proc/<pid>/syscall, um arquivo legítimo do sistema operacional Linux, podendo aproveitar esse vazamento de informações para explorar com êxito vulnerabilidades adicionais não corrigidas.
      O Cisco Talos trabalhou com o Linux para garantir que esse problema seja resolvido e uma atualização já está disponível para os clientes afetados. Os usuários são incentivados a atualizar esses produtos afetados o mais rápido possível para o Kernel Linux versões 5.10-rc4, 5.4.66 e 5.9.8.
    • By Bruna Chieco
      Três vulnerabilidades foram encontradas no subsistema iSCSI do kernel do Linux, permitindo que invasores locais com privilégios básicos de usuário obtenham privilégios de root em sistemas Linux sem patch. Segundo o BleepingComputer, os bugs de segurança só podem ser explorados localmente, o que significa que invasores em potencial terão que obter acesso a dispositivos vulneráveis explorando outra vulnerabilidade ou usando um vetor de ataque alternativo.
      O mais impressionante é que essas vulnerabilidades já existem há 15 anos. A descoberta foi feita por pesquisadores do GRIMM. "Ao contrário da maioria das coisas que encontramos acumulando poeira, esses bugs revelaram-se ainda bons, e um acabou sendo utilizável como um escalonamento de privilégio local (LPE) em vários ambientes Linux", diz publicação feita no blog do GRIMM.
      De acordo com o pesquisador de segurança do GRIMM, Adam Nichols, as falhas afetam todas as distribuições Linux, mas felizmente o módulo de kernel scsi_transport_iscsi vulnerável não é carregado por padrão. No entanto, dependendo da distribuição do Linux que os atacantes estejam focando, o módulo pode ser carregado e explorado para escalonamento de privilégios.
      Saiba mais sobre as vulnerabilidades: 
      CVE-2021-27363: vazamento do ponteiro do kernel (vazamento de informações) CVE-2021-27364: leitura fora dos limites (vazamento de informações, negação de serviço) CVE-2021-27365: estouro de buffer de heap (escalonamento de privilégio local, vazamento de informações, negação de serviço)
    • By Fernando Mercês
      Batizado com nome herdado da estrela binária VV Cephei, o Linux.Cephei é provavelmente o primeiro file infector para executáveis ELF (utilizados nos sistemas baseados em Linux, entre outros) escrito na linguagem Nim. Isso mesmo, o autor é um tanto excêntrico e disse em seu blog que o Linux.Cephei é inofensivo (por enquanto) e fez somente para participar de um concurso de programação.
      O vírus é do tipo que chamamos de prepender, ou seja, ele adiciona algo "antes" da execução de um programa saudável, no caso, de um binário ELF. A técnica para isso é a alteração de seu entrypoint. 
      Nos testes que fizemos aqui, o Linux.Cephei só funcionou com binários compilados estaticamente: 
      $ uname -a Linux malinux 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux $ cat /etc/debian_version 9.2 $ cat h.c #include <stdio.h> int main(void) { printf("ola mundo do bem!\n"); return 0; } $ gcc -static -o hello h.c $ ./hello ola mundo do bem! $ chmod +x linux.cephei $ ./linux.cephei $ ./hello Did you know that VV Cephei, also known as HD 208816, is an eclipsing binary star system located in the constellation Cepheus, approximately 5,000 light years from Earth? It is both a B[e] star and shell star. Awesome! https://en.wikipedia.org/wiki/VV_Cephei The more you know... :) ola mundo do bem! $ gcc -o hello h.c $ ./linux.cephei $ ./hello ola mundo do bem!  Perceba que ele injetou seu código com sucesso no binário hello, mas somente quando foi compilado estaticamente.  
      Além da linguagem exótica, ultimamente não se vê muitos file infectors já que a moda de infectar executáveis passou. De qualquer forma, é bom ficar de olho. Com códigos como o do Linux.Ceiphei, vírus podem permanecer ocultos num sistema por muito tempo. E pouca gente usa antivírus no Linux, mesmo tendo uma alternativa livre como o ClamAV.
    • By julio neves
      Livro do Julio Cezar Neves com dicas importantes (e raras de serem encontradas) sobre shell, incluindo sincronismo de processos, novidades do Bash 4.0, uso do ImageMagik e YAD (o melhor da categoria dos dialog da vida). Vale ler cada palavra. ?
       
      E se quiser ver se tem turma aberta do curso dele é só clicar aqui. ?
×
×
  • Create New...